Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Maximum transmission unit
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Internet protocol== The [[Internet protocol suite]] was designed to work over many different networking technologies, each of which may use packets of different sizes. While a host will know the MTU of its own interface and possibly that of its peers (from initial handshakes), it will not initially know the lowest MTU in a chain of links to other peers. Another potential problem is that higher-level protocols may create packets larger than even the local link supports. IPv4 allows [[IP fragmentation|fragmentation]] which divides the [[datagram]] into pieces, each small enough to accommodate a specified MTU limitation. This fragmentation process takes place at the [[internet layer]]. The fragmented packets are marked so that the IP layer of the destination host knows it should reassemble the [[packet (information technology)|packets]] into the original datagram. All fragments of a packet must arrive for the packet to be considered received. If the network drops any fragment, the entire packet is lost. When the number of packets that must be fragmented or the number of fragments is great, fragmentation can cause unreasonable or unnecessary overhead. For example, various tunneling situations may exceed the MTU by very little as they add just a header's worth of data. The addition is small, but each packet now has to be sent in two fragments, the second of which carries very little payload. The same amount of payload is being moved, but every intermediate router has to forward twice as many packets. The Internet Protocol requires that hosts must be able to process IP datagrams of at least 576 bytes (for IPv4) or 1280 bytes (for IPv6). However, this does not preclude [[link layer]]s with an MTU smaller than this minimum MTU from conveying IP data. For example, according to IPv6's specification, if a particular link layer cannot deliver an IP datagram of 1280 bytes in a single frame, then the link layer must provide its own fragmentation and reassembly mechanism, separate from the IP fragmentation mechanism, to ensure that a 1280-byte IP datagram can be delivered, intact, to the IP layer. ===MTUs for common media=== In the context of [[Internet Protocol]], MTU refers to the maximum size of an [[IP packet (disambiguation)|IP packet]]<!--intentional link to disambig, could be either IPv4 or IPv6 packet--> that can be transmitted without fragmentation over a given medium. The size of an IP packet includes IP headers but excludes headers from the link layer. In the case of an [[Ethernet frame]] this adds a [[protocol overhead]] of 18 bytes, or 22 bytes with an [[IEEE 802.1Q]] tag for VLAN tagging or [[class of service]]. The MTU should not be confused with the minimum datagram size (in one piece or in fragments) that all hosts must be prepared to accept. This is 576 bytes for [[IPv4]]{{Ref RFC|791|rp=24}} and 1280 bytes for [[IPv6]].{{Ref RFC|8200|rp=25}} {| class="wikitable sortable" |- ! Media for IP transport ! Maximum transmission unit (bytes) ! Notes |- | [[Internet]] IPv4 path MTU | At least 68,{{Ref RFC|791|rp=24}} max of 64 KiB{{Ref RFC|791|rp=12}} | Systems may use [[Path MTU Discovery]]{{Ref RFC|1191}} to find the actual path MTU. Routing from larger MTU to smaller MTU causes [[IP fragmentation]]. |- | [[Internet]] IPv6 path MTU | At least 1280,{{Ref RFC|8200}} max of 64 KiB, but optional [[jumbogram]]s go up to 4 GiB{{Ref RFC|2675}} | Systems should use Path MTU Discovery{{Ref RFC|8200}} to find the actual path MTU, unless the minimum MTU (1280 bytes) is not exceeded.{{Break}}Jumbograms are packets with a [[IPv6 header#Hop-by-hop options and destination options|Jumbo Payload option]] to allow transmission of payloads between 65,536 and 4,294,967,295 octets in length. |- | [[X.25]] | Minimal 576 (sending) or 1600 (receiving){{Ref RFC|1356}} | |- | [[Ethernet II framing|Ethernet v2]] | 1500{{Ref RFC|894}} | Nearly all IP over Ethernet implementations use the [[Ethernet frame#Ethernet II|Ethernet II frame format]]. |- | Ethernet with [[Logical link control|LLC]] and [[Subnetwork Access Protocol|SNAP]] | 1492<ref>[[IEEE 802.3]]{{page needed|date=January 2019}}</ref> | |- |- | Ethernet [[jumbo frame]]s | 1501β9202<ref>{{citation |url=http://www.networkworld.com/community/blog/jumbo-frames |title=Jumbo Frames |author=Scott Hogg |date=2013-03-06 |access-date=2013-08-05 |publisher=[[Network World]] |quote=Most network devices support a jumbo frame size of 9216 bytes.}}</ref> or more<ref>{{citation |url=https://www.juniper.net/documentation/en_US/junos/topics/topic-map/physical-interface-properties.html#id-physical-interface-damping-overview|title=Physical Interface Properties |author=Juniper Networks |date=2020-03-23 |access-date=2020-05-01}}</ref> | The limit varies by vendor. For correct interoperation, frames should be no larger than the maximum frame size supported by any device on the [[network segment]].<ref>{{Cite web | url = https://www.stsauver.com/~joe/jumbos/jumbo-frames.pdf | title = Practical Issues Associated With 9K MTUs | quote = you still need to insure that ALL upstream Ethernet switches, including any switches in your campus core, are ALSO jumbo frame capable | date = 2003-02-04 | access-date = 2016-12-15 | author = Joe St Sauver | publisher = uoregon.edu | page = 67 }}</ref> |- | [[Point-to-point protocol over Ethernet|PPPoE v2]] | 1492{{Ref RFC|2516}} | Ethernet II MTU (1500) less PPPoE header (8); extensions exist |- | [[DS-Lite]] over PPPoE | 1452 | Ethernet II MTU (1500) less PPPoE header (8) and IPv6 header (40) |- | PPPoE jumbo frames | 1493β9190 or more{{Ref RFC|4638}} | Ethernet Jumbo Frame MTU (1501β9198) less PPPoE header (8) |- | [[IEEE 802.11]] Wi-Fi (WLAN) | 2304<ref>802.11-2012, page 413, section 8.3.2.1; page 381 "The Frame Body field is of variable size. The maximum frame body size is determined by the maximum MSDU size (2304 octets), plus the length of the Mesh Control field (6, 12, or 18 octets) if present, the maximum unencrypted MMPDU size excluding the MAC header and FCS (2304 octets) or the maximum A-MSDU size (3839 or 7935 octets, depending upon the STAβs capability), plus any overhead from security encapsulation."</ref> |The maximum MSDU size is 2304 before encryption. WEP will add 8 bytes, WPA-TKIP 20 bytes, and WPA2-CCMP 16 bytes. See also [[Frame aggregation]] mechanisms in 802.11n. |- | [[IEEE 802.5|Token Ring (802.5)]] | 4464 | |- | [[FDDI]] | 4352{{Ref RFC|1191}} | |} ===Ethernet maximum frame size=== The IP MTU and Ethernet maximum frame size are configured separately. In Ethernet switch configuration, MTU may refer to Ethernet maximum frame size. In Ethernet-based routers, MTU normally refers to the IP MTU. If [[jumbo frame]]s are allowed in a network, the IP MTU should also be adjusted upwards to take advantage of this. Since the IP packet is carried by an Ethernet frame, the Ethernet frame has to be larger than the IP packet. With the normal untagged Ethernet frame overhead of 18 bytes and the 1500-byte payload, the Ethernet maximum frame size is 1518 bytes. If a 1500-byte IP packet is to be carried over a tagged Ethernet connection, the Ethernet frame maximum size needs to be 1522 bytes due to the larger size of an 802.1Q tagged frame. [[802.3ac]] increases the standard Ethernet maximum frame size to accommodate this. ===Path MTU Discovery=== {{Main|Path MTU Discovery}} The Internet Protocol defines the ''path MTU'' of an Internet transmission path as the smallest MTU supported by any of the [[Hop (telecommunications)|hop]]s on the path between a source and destination. Put another way, the path MTU is the largest packet size that can traverse this path without suffering fragmentation. ''Path MTU Discovery'' is a technique for determining the path MTU between two IP hosts, defined for both [[IPv4]]{{Ref RFC|1191}} and [[IPv6]]{{Ref RFC|8201}}. It works by sending packets with the DF (don't fragment) option in the IP header set. Any device along the path whose MTU is smaller than the packet will drop such packets and send back an [[ICMP Destination Unreachable|ICMP Destination Unreachable (Datagram Too Big)]] message which indicates its MTU. This information allows the source host to reduce its assumed path MTU appropriately. The process repeats until the MTU becomes small enough to traverse the entire path without fragmentation. Standard Ethernet supports an MTU of 1500 bytes and Ethernet implementation supporting jumbo frames, allow for an MTU up to 9000 bytes. However, border protocols like [[PPPoE]] will reduce this. Path MTU Discovery exposes the difference between the MTU seen by Ethernet end-nodes and the Path MTU. Unfortunately, increasing numbers of networks [[Black hole (networking)|drop ICMP traffic]] (for example, to prevent [[denial-of-service attack]]s), which prevents path MTU discovery from working. ''Packetization Layer Path MTU Discovery''{{Ref RFC|4821}}{{Ref RFC|8899}} is a Path MTU Discovery technique which responds more robustly to ICMP filtering. In an IP network, the path from the source address to the destination address may change in response to various events ([[load balancing (computing)|load-balancing]], [[Network congestion|congestion]], [[Downtime|outages]], etc.) and this could result in the path MTU changing (sometimes repeatedly) during a transmission, which may introduce further packet drops before the host finds a new reliable MTU. A failure of Path MTU Discovery carries the possible result of making some sites behind badly configured [[Firewall (networking)|firewall]]s unreachable. A connection with mismatched MTU may work for low-volume data but fail as soon as a host sends a large block of data. For example, with [[Internet Relay Chat]] a connecting client might see the initial messages up to and including the initial [[Ping (networking utility)|ping]] (sent by the server as an anti-spoofing measure), but get no response after that. This is because the large set of welcome messages sent at that point are packets that exceed the path MTU. One can possibly work around this, depending on which part of the network one controls; for example one can change the MSS ([[maximum segment size]]) in the initial packet that sets up the [[Transmission Control Protocol|TCP]] connection at one's firewall.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)