From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 20:35:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6ACA16A400 for ; Fri, 13 Jul 2007 20:35:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id CF04A13C442 for ; Fri, 13 Jul 2007 20:35:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 13 Jul 2007 13:35:47 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 8E8B7125B26; Fri, 13 Jul 2007 13:35:46 -0700 (PDT) Message-ID: <4697E234.1070201@elischer.org> Date: Fri, 13 Jul 2007 13:36:04 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net> <20070713152725.6ae40056.wmoran@collaborativefusion.com> <4697DF64.9070203@seclark.us> In-Reply-To: <4697DF64.9070203@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:35:49 -0000 Stephen Clark wrote: > Chuck Swiger wrote: > >> On Jul 13, 2007, at 12:27 PM, Bill Moran wrote: >> >> >>>> I agree with others that MTU means "limit what I transmit". It >>>> does not >>>> mean "limit what someone else can transmit to me." >>>> >>> Interesting viewpoint. I disagree with it, but I can't quote any >>> standard >>> or otherwise to support my view. You didn't either. >>> >>> Does anyone know of a publicised, authoritative standard that would >>> clear this up? >>> >> >> Sure. RFC-791: >> >> "Fragmentation >> >> Fragmentation of an internet datagram is necessary when it >> originates in a local net that allows a large packet size and must >> traverse a local net that limits packets to a smaller size to reach >> its destination. >> >> An internet datagram can be marked "don't fragment." Any internet >> datagram so marked is not to be internet fragmented under any >> circumstances. If internet datagram marked don't fragment cannot be >> delivered to its destination without fragmenting it, it is to be >> discarded instead. >> >> Fragmentation, transmission and reassembly across a local network >> which is invisible to the internet protocol module is called >> intranet fragmentation and may be used [6]." >> >> RFC-879: >> >> " HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY >> HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO >> ACCEPT LARGER DATAGRAMS." >> >> "8. Maximum Packet Size >> >> Each network has some maximum packet size, or maximum transmission >> unit (MTU). Ultimately there is some limit imposed by the >> technology, but often the limit is an engineering choice or even an >> administrative choice. Different installations of the same network >> product do not have to use the same maximum packet size. Even within >> one installation not all host must use the same packet size (this way >> lies madness, though). >> >> Some IP implementers have assumed that all hosts on the directly >> attached network will be the same or at least run the same >> implementation. This is a dangerous assumption. It has often >> developed that after a small homogeneous set of host have become >> operational additional hosts of different types are introduced into >> the environment. And it has often developed that it is desired to >> use a copy of the implementation in a different inhomogeneous >> environment. >> >> Designers of gateways should be prepared for the fact that successful >> gateways will be copied and used in other situation and >> installations. Gateways must be prepared to accept datagrams as >> large as can be sent in the maximum packets of the directly attached >> networks. > Doesn't this imply if a gateway has 2 interfaces, one with an mtu of > 1280 and the other > with an mtu of 1500 it should accept 1500 on either interface? not specifically but I would.. > >> Gateway implementations should be easily configured for >> installation in different circumstances. >> >> A footnote: The MTUs of some popular networks (note that the actual >> limit in some installations may be set lower by administrative >> policy): >> >> ARPANET, MILNET = 1007 >> Ethernet (10Mb) = 1500 >> Proteon PRONET = 2046" >> >> RFC-894: >> >> " The minimum length of the data field of a packet sent over an >> Ethernet is 1500 octets, thus the maximum length of an IP datagram >> sent over an Ethernet is 1500 octets. Implementations are encouraged >> to support full-length packets. Gateway implementations MUST be >> prepared to accept full-length packets and fragment them if >> necessary. If a system cannot receive full-length packets, it should >> take steps to discourage others from sending them, such as using the >> TCP Maximum Segment Size option [4]. >> >> Note: Datagrams on the Ethernet may be longer than the general >> Internet default maximum packet size of 576 octets. Hosts connected >> to an Ethernet should keep this in mind when sending datagrams to >> hosts not on the same Ethernet. It may be appropriate to send >> smaller datagrams to avoid unnecessary fragmentation at intermediate >> gateways. Please see [4] for further information on this point." >> >> And RFCs 1122 and 1191 are also somewhat relevant. My reading of the >> above is that ethernet-capable gateways must be willing to accept >> packets as large as 1500 octets and fragment such traffic to meet the >> MTU settings as needed, except if DF is set. If DF is set, but the >> packet is addressed to the gateway itself, then it should be >> delivered unfragmented even if that packet exceeded the MTU set on >> the receiving interface. >> >> For hosts which are not network gateways, one should not assume them >> to be capable of receiving packets larger than 576 octets, but the >> TCP MSS option is almost universally available to indicate the >> appropriate maximum size that host is willing to receive during the >> 3WHS setup... >> >> >> > >