Iljitsch, > -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 02, 2007 4:57 AM > To: Templin, Fred L > Cc: Joe Touch; Joe Macker; Fred Baker; Gorry Fairhurst; > Stephen Casner; Internet Area > Subject: Tunneling/MTU BCP, was: Re: Mucking with IP ID > > [to our little ad hoc group AND internet area list] > > On 2-aug-2007, at 1:38, Templin, Fred L wrote: > > > Instead, I have proposed a BCP approach on the int-area > > mailing list. Here's what I said there: > > > + Focusing only on the ULP, can we say that 1500 bytes is > > + the nominal MTU of today's Internet, and therefore all > > + attached devices SHOULD configure a minMRU of 1500? > > We can say that, but is such a statement helpful? I can't remember > ever seeing someone reduce their MTU below 1500 when they are > physically and logically capable of receiving 1500 byte packets.
I believe we can say that the nominal MTU of today's Internet is 1500 bytes, and yes I think that statement is helpful. > > Then, > > + can we also say that applications that send packets larger > > + than 1500 bytes (with DF=1) are RECOMMENDED to use RFC4821? > > RFC 4821 should be recommended whenever path MTU discovery is used, > which is pretty much in all implementations. PMTUD black holes are > often the result of MTUs lower than 1500 in the path so > limiting this > recommendation to 1500+ interfaces makes little sense. I never said the recommendation was limited to 1500+ interfaces. I said that applications (and/or transports) that send 1501+ packets with DF=1 are RECOMMENDED to use RFC4821, but this is *not* to say that other applications/transports are not. > > + Finally, could we also say that tunnel decapsulators SHOULD > > + configure a minMRU of 2048 to account for encapsulations > > + that might extend a 1500 byte ULP out to the IEEE 802.as > > + maximum frame size? > > Not sure what you mean here. Obviously people should be prepared to > receive the largest possible packets supported by the hardware > configuration in use. IMHO, it is perfectly reasonable for MRU to be larger than the largest possible packet supported by the underlying hardware. Think about larger-than-MTU-sized packets sent with DF=0 and/or fragmented by the sending host itself. > That means 1500 bytes for ethernet, or > whatever > jumboframe size is in effect. Trying to receive more than the > hardware will do is an exercise in futility... Disagree; it may be beneficial for MRU to be larger than MTU and perhaps even much larger. Else, how can we support applications that have no way of reducing the size of the packets they send to fit MTU? > However, we CAN recommend that people make their tunnel MRUs > equal to > the size of the largest physical interface MRU - encapsulation size, > even if the tunnel MTU is smaller than that. But I would recommend > making the tunnel MTU equal to that MRU rather than use the IPv6-in- > IPv4 tunneling practice of a 1280 byte MTU to accommodate multiple > levels of encapsulation. The nominal MTU in todays Internet is 1500 bytes, but that is NOT to say that all devices on the Internet configure a 1500 byte MTU because that isn't true. IEEE 802.as may begin to push common device MTUs up to 2048 bytes, so it is not unreasonable that reassemblers will soon need to be able to reassemble larger than 1500 even if senders limit the size of the packets they send to the MTU of their outgoing interface. Fred [EMAIL PROTECTED] _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
