Re: [RAM] Tunneling overheads and fragmentation

Thanks for these great responses!

This message also concerns my argument for making the tunneled
packet's outer source address be the same as the inner source
address (outer SA = inner SA), as discussed in my second message
in the thread:  "ETRs checking src & dest addresses":

http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html

The following is part of my To-Do list for Ivip:

  http://www.firstpr.com.au/ip/ivip/to-do/

Read these I-Ds and RFCs (I use these /html/ links because the
indicate later versions at the top of the page, and print with
proper page breaks):

  Link Adaptation for IPv6-in-(foo)*-in-IPv4 Tunnels

    http://tools.ietf.org/html/draft-templin-linkadapt-06

  MTU and Fragmentation Issues with In-the-Network Tunneling

    http://tools.ietf.org/html/rfc4459

  Packetization Layer Path MTU Discovery

    http://tools.ietf.org/html/rfc4821

  TCP Problems with Path MTU Discovery

    http://tools.ietf.org/html/rfc2923

  IPv6 Extensions for Multi-MTU Subnets

    http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-00

  IP Tunneling Optimization in a Mobile Environment

http://tools.ietf.org/html/draft-haddad-mip6-tunneling-optimization-01

  Generic Routing Encapsulation (GRE)

    http://tools.ietf.org/html/rfc2784

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

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram