To-Do list for Ivip

Dave Meyer wrote:

> Agreed. As mentioned above, there is also the interaction
> with PMTU discovery; basically, it can be nontrivial to
> find the original source of the packet so you can send a
> a "fragmentation needed and DF set" back to the
> source. If indeed you can't find the source (multiple
> encaps or whatever), then the source's packets (those
> that have the DF bit set, i.e., doing PMTU discovery) get
> black-holed. Not sure if that was your question, but in
> any event...

I didn't ask specifically, but it is a really important point: Tunnels upset PMTU discovery.

Here are some diagrams of left-to-right packet flow, with the outer header Source Address and Destination Address, and the inner SA and DA for the part of the path where the original packet is in a tunnel.

The first diagram is for the LISP/eFIT-APT approach of the outer SA being that of the ITR.

           SH-----IR1----ITR~~~~~TR1~~~~~TR2~~~~~ETR----IR2-----RH

Outer SA       SH     SH     ITR     ITR     ITR     SH      SH
      DA       RH     RH     ETR     ETR     ETR     RH      RH

Inner SA                     SH      SH      SH
      DA                     RH      RH      RH

---- Raw
~~~~ Encapsulated

Now I consider where an "ICMP Destination Unreachable - Fragmentation Needed" (DUFN) message might be generated. I don't know enough about this process to know if it is generated at the output of an interface, and/or when arriving at an interface (perhaps due to the innards of the router not being able to handle this length).

If IR1 generates the DUFN message, all will be well - at least it is not affected by the tunneling system.

Likewise if the ITR generates the DUFN when it receives the raw packet. But what if the ITR encapsulates the packet and then when attempting to forward it, generates a DUFN? Does the maximum packet length vary from one outgoing interface to another? How will this part of the router know the problem is the responsibility of a particular sending host and its own internal encapsulation function?

If Transit Router TR1 generates the DUFN, the DUFN will be addressed to the ITR. But the ITR can't know what to do with it, since as far as I know, the DUFN doesn't mention anything about the contents of the packet, which is the only place where the Sending Host's (SH's) address is mentioned.

Likewise if the DUFN arises from arriving at TR2 or the ETR.

If the DUFN is generated at the output of the ETR, it should be OK, because it will be sent to the SH, not the ITR. Likewise if the DUFN is generated at the internal router IR2 or the Destination Host (DH).

The best which could be achieved with the above arrangement is that the ITR has to store state that packets sent to a particular address (the ETR's address) should be fragmented before encapsulation. But how long does it retain this state for? It all depends on the routing path, since it could be a cranky old TR2 which is complaining, and that may not be in the path for long.

Storing this state and burdening the ITR's FIB with looking for it, for every encapsulation operation, and then splitting the packet and sending two encapsulated packets . . . this is really ugly. Also, I am not sure how well LISP's or eFIT-ETR's communications would work with packets being fragmented. There are some pretty fancy protocols for communication, particularly between multiple ITRs and Default Mappers in eFIT-ETR. (See my comparison message.)

Now consider the situation with Ivip's approach of setting the outer SA the same as the inner SA. This would be either with IP-in-IP (which doesn't include the ITR's address) or with UDP encapsulation with explicit mention of the ITRs address, if this was decided to be worth the trouble to help with debugging - which seems quite possible.

           SH-----IR1----ITR~~~~~TR1~~~~~TR2~~~~~ETR----IR2-----RH

Outer SA       SH     SH     SH      SH      SH      SH      SH
      DA       RH     RH     ETR     ETR     ETR     RH      RH

Inner SA                     SH      SH      SH
      DA                     RH      RH      RH

Now wherever the DUFN is generated, it will go back to the Sending Host, which I think is what is required.

The ITR doesn't have to look out for DUFN messages, or store any state, or do any optional fragmentation.

This way, the SA can fine-tune its packet size, per "RH" destination address, to the highest value which avoids fragmentation.

Unless I have made some mistakes, then this looks like a second strong reason for keeping "outer SA = inner SA", in addition to the powerful reason (I think) which I raised in the thread "ETRs checking src & dest addresses".

- Robin