[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Path MTU Discovery



Dan McDonald writes:
> > Well, wouldn't ignoring the DF bit defeat the original endpoint's
> > PathMTU ?
> 
> DF applies to the IP datagram on which it is set.  DF is not inherited by any
> encapsulating IP headers.

Hate to be picky, but RFC1853 states:

   Don't Fragment   copied from the inner IP header.  This allows the
                    originator to control the level of performance
                    tradeoffs.  See "Tunnel MTU Discovery".

So, in fact, the IP-in-IP header requires that DF bit be set, and
neither AH, nor ESP will touch this part of the header.

Of course, if you would like to tunnel using a protocol other than IP in
IP, that is your prerogative... Are there people who do this?

> <SNIP!>
> > So one can establish multiple tunnels to different (or the same) hosts and
> > use the same ViF. In this case, if you receive an ICMP toobig, you don't
> > know who if "belongs" to until you parse the internal packet a bit and
> > check the destination/SPI of the original packet. And then of course you
> > can't (shouldn't) change the "MTU" of the ViF.
> 
> I question your choice of abstraction.  How do you configure these multiple
> tunnels?  Or are they automatic tunnels ala. IPv6's ::<v4-address> syntax?
> Since you probably have to configure the tunnels, you might as well provide a
> halfway decent abstraction to take into account Path MTU ratcheting down.

Hopefully, if each tunnel properly supports Path MTU and "soft state",
the MTU should propagate upwards.  Personally I wonder what the point is
in requiring Path MTU be done, while only recommending that soft state
be kept.  (Perhaps RFC1853 should be updated to require the keeping of
soft state?)

Then, we would see everything perform nicely, a la:

Host -> Tunnelling Router 1 -> Tunneling Router 2 --A--> ...

Where each router is doing rfc1828 MD5 tunneling (20 byte IP header + 24
bytes of AH = 44 bytes total), and path A has an MTU of 500 bytes.

Packet 1: 1500 bytes, DF set
  Tunneled by R1 (1544 bytes) (Dropped)

Packet 2: 1500 bytes, DF set
  R1 sends ICMP too big with size limit 1456 to host
  Tunneled by R1 (1544 bytes) (Dropped) (An effort to rediscover a
					 "growing" MTU)

Packet 3: 1456 bytes, DF set
  Tunneled by R1 (1500 bytes)
  Tunneled by R2 (1544 bytes) (Dropped)

Packet 4: 1456 bytes, DF set
  Tunneled by R1 (1500 bytes)
  R2 sends ICMP too big with size limit 456 to R1
  Tunneled by R2 (1544 bytes) (Dropped)

Packet 4: 1456 bytes, DF set
  R1 sends ICMP too big with size limit 412 to host
  Tunneled by R1 (1500 bytes) 
  R2 sends ICMP too big with size limit 456 to R1
  Tunneled by R2 (1544 bytes) (Dropped)

Packet 5: 412 bytes, DF set
  Tunneled by R1 (456 bytes)
  Tunneled by R2 (500 bytes)
  Received.



ben





Follow-Ups: