> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Joe Touch > Sent: Tuesday, June 25, 2013 11:13 AM > To: Carlos Pignataro (cpignata) > Cc: Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt > > > > On 6/25/2013 10:22 AM, Carlos Pignataro (cpignata) wrote: > > Joe, > > > > On Jun 25, 2013, at 12:50 PM, "Joe Touch" <[email protected]> wrote: > > > >> > >> > >> On 6/25/2013 7:04 AM, Linda Dunbar wrote: > >>> Ron, > >>> > >>> Your draft recommends that the ingress node discards the frame and > >>> sends ICMP msg to the source node when the size of GRE encapsulated > >>> frame exceeds link MTU. > >>> We experienced that Window XP doesn't adjust frame size after > >>> receiving ICMP message. Many Linux based applications don't do > anything > >>> either with the MTU ICMP message. I think your draft should point > those > >>> issues out and recommend fragmentation approach under those > circumstances. > >> > >> Do these apps set DF=1? If so, they ought to be prepared to handle > ICMP PTB messages. If not, they shouldn't be setting PTB. > >> > >> However, my view remains that PTB is for when a link cannot handle a > packet - not when it chooses not to do so electively. The only packet > that ought to be too big for GRE is one that exceeds the max payload of > IP after encapsulation. Others ought to be fragmented at the GRE > ingress and reassembled at the GRE egress at the outer IP layer, > exactly because IP *can* do this. > > > > If a physical link has an MTU of 1500, can you configure it and set > it to be 1300, despite the hardware being able to do 1500? > > > > Are you suggesting that a GRE tunnel has a Tunnel MTU of 65535 - > encap always? > > A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is. > > I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. > Beyond that it *cannot* reassemble.
I have a slightly different view, but one that still involves fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU of 1280 bytes. But, to uphold the de facto Internet cell size of 1500 bytes we should extend this up to 1500. So, if the MTU within the tunnel is unknown and/or unknowable, then the ingress MUST use fragmentation to make sure that packets no larger than 1500 bytes get through - the egress then gets to reassemble. Packets larger than 1500 can be admitted into the tunnel unfragmented and allowed to sink or swim on their own. The ingress may or may not get ICMP PTBs if one of these is dropped, but the source should be using RFC4821 when it sends packets larger than 1500 bytes anyway, so loss of PTBs should not affect the hosts. Thanks - Fred [email protected] > Joe > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
