From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 19:54:40 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 A489C16A400 for ; Fri, 13 Jul 2007 19:54:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 8718713C428 for ; Fri, 13 Jul 2007 19:54:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id 74E15BA90E9; Fri, 13 Jul 2007 12:54:40 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 5F1C629C003; Fri, 13 Jul 2007 12:54:40 -0700 (PDT) X-AuditID: 11807123-a573dbb000000b34-23-4697d8808b75 Received: from [17.214.13.96] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id 415CD30400D; Fri, 13 Jul 2007 12:54:40 -0700 (PDT) In-Reply-To: <20070713152725.6ae40056.wmoran@collaborativefusion.com> 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> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 13 Jul 2007 12:54:40 -0700 To: Bill Moran X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org, David DeSimone 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 19:54:40 -0000 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. 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... -- -Chuck