[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: