Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, July 01, 2013 1:05 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt > > Hi, Fred, > > On 7/1/2013 8:34 AM, Templin, Fred L wrote: > >>> OK, but IPv4 also has a limit of minMRU=576. So, we have: > >>> > >>> IPv4 minMTU = 576 (*) > >>> IPv4 minMRU = 576 > >>> IPv6 minMTU = 1280 > >>> IPv6 minMRU = 1500 > >>> > >>> (*) Even though the specs say that IPv4 minMTU = 68, everyone > >>> seems to be saying that for practical purposes it is now 576. > >> > >> There needs to be a difference between the minMTU and the minMRU; if > >> not, then IP-in-IP tunnels will never succeed without a separate > >> fragmentation and reassembly layer - and although SEAL provides > that, > >> we > >> currently do not require anything like that for X-in-X > encapsulation. > > > > With IPv4, there is no difference between minMTU and minMRU. > > Tunnels over IPv4 therefore set DF=0 to allow for in the > > network fragmentation if necessary. > > But then that's useless. Let's say you already send just 576, and set > DF=1, and that packet encounters an IPv4 tunnel. You add 20 bytes of > header, resulting in 596. > > At the tunnel ingress, you can't fragment the inner packet because DF=1 > - and why shouldn't it be set? You're using the minMTU. > > At that ingress, you can't fragment the outer packet because you would > need the egress to reassemble something that is 596 -- larger than the > egress ever expected to reassembly (minMRU). > > So you drop the packet and send an ICMP too-big back to the source, who > drops it because they're already sending minMTU packets and doesn't > think it should have to drop the MTU below that. > > AFAICT, you now have broken the path completely.
For IPv6-within-IPv4 at least, most of these "transition mechanism" tunnels assume a minMRU of 1500 even though the IPv4 specs say that the MRU is 576. Sure, that is broken but it seems to have become the IPv6 transition mechanism "best practice". > > With IPv6, minMTU is smaller than minMRU but that does not > > guarantee that a packet sent by the ingress can be received > > by the egress without fragmentation. > > No, but it does guarantee that the packet can traverse a tunnel and > still make it to its destination. Right, but remember that the IPv6 minMRU is only 1500 bytes. So, we can't assume an unlimited reassembly buffer on the tunnel egress. > The difference between minMTU and minMRU is the amount of accumulated > headers you can accommodate by tunneling. At 1500-1280, that's 5 levels > of nested IPv6 tunnels, or more than a few IPsec tunnel-mode tunnels if > needed. I addressed this point on the IPv6 list, but think for a moment what this means. It means that the fist tunnel ingress would have to configure a 1280 MTU, the second tunnel ingress would need to configure a 1320 MTU (to accept encapsulated packets from the first), the third tunnel ingress would need to configure a 1360 MTU (to accept encapsulated packets from the second), etc. up to 5 levels of nesting. I don't know about you, but I can imagine many situations where it is not possible for a single operator to lay hands on every tunnel ingress so as to carefully set each MTU in this way (I gave one example on the IPv6 list). > That's not as much as I'd like, but it's at least non-zero. I think the maximum acceptable level of nesting is somewhere between 5 and 10 before the nesting would be declared "recursive" (i.e., a routing loop). SEAL allows up to 8 levels of nesting. > > RFC2473 acknowledges > > this by using fragmentation at the ingress as a limiting > > condition for when the MTU within the tunnel becomes too > > small. This can happen for example if there is a 1280 MTU > > link within the tunnel, if there are nested encapsulations > > within the tunnel, etc. > > Yes, but if minMRU == minMTU, then the number of encapsulations > supported is zero. Right. That's why IPv6-in-IPv4 transition mechanisms cheat and assume 1500 when the specs say they can only assume 576. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
