Jump to content

Maximum transmission unit: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
No edit summary
Tags: Reverted Visual edit Mobile edit Mobile web edit Disambiguation links added
m Reverted edits by 2806:263:482:15A8:7562:F5AA:AADA:C116 (talk) to last version by Dandorid
 
(17 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Short description|Size of largest allowed packet on a network segment|pagetype = DNS}}
{{Short description|Size of largest allowed packet on a network segment}}


In [[computer networking]], the '''maximum transmission unit''' ('''MTU''') is the size of the largest [[protocol data unit]] (PDU) that can be [[Communicate|communicated]] in a [[Single transferable vote|single]] [[network layer]] transaction.<ref>{{cite IETF |rfc=791 |page=25}}</ref> The MTU relates to, but is not identical to the maximum [[Frame (networking)|frame]] size that can be transported on the [[data link layer]], e.g., [[Ethernet frame]].
In [[computer networking]], the '''maximum transmission unit''' ('''MTU''') is the size of the largest [[protocol data unit]] (PDU) that can be communicated in a single [[network layer]] transaction.{{Ref RFC|791|rp=25}} The MTU relates to, but is not identical to the maximum [[Frame (networking)|frame]] size that can be transported on the [[data link layer]], e.g., [[Ethernet frame]].


Larger MTU is [[Associated state|associated]] with reduced [[overhead (computing)|overhead]]. Smaller MTU values can reduce [[network delay]]. In many cases, MTU is dependent on underlying network [[Capabilities Maturity Model|capabilities]] and must be adjusted [[Manually Coded Malay|manually]] or [[Automatically switched optical network|automatically]] so as to not [[exceed]] these capabilities. MTU parameters may appear in association with a [[Communications satellite|communications]] interface or standard. Some [[Systems Network Architecture|systems]] may decide MTU at [[connect]] time, e.g. using [[Path MTU Discovery]].
Larger MTU is associated with reduced [[overhead (computing)|overhead]]. Smaller MTU values can reduce [[network delay]]. In many cases, MTU is dependent on underlying network capabilities and must be adjusted manually or automatically so as to not exceed these capabilities. MTU parameters may appear in association with a communications interface or standard. Some systems may decide MTU at connect time, e.g. using [[Path MTU Discovery]].


==Applicability==
==Applicability==
Line 13: Line 13:
A larger MTU brings greater efficiency because each [[network packet]] carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means an improvement in bulk protocol throughput. A larger MTU also requires processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation.
A larger MTU brings greater efficiency because each [[network packet]] carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means an improvement in bulk protocol throughput. A larger MTU also requires processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation.


However, this gain is not without a downside. Large packets occupy a link for more time than a smaller packet, causing greater delays to subsequent packets, and increasing [[network delay]] and [[Packet delay variation|delay variation]]. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer, ties up a [[14.4k modem]] for about one second.
However, this gain is not without a downside. Large packets occupy a link for more time than a smaller packet, causing greater delays to subsequent packets, and increasing [[network delay]] and [[delay variation]]. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer, ties up a [[14.4k modem]] for about one second.


Large packets are also problematic in the presence of communications errors. If no [[forward error correction]] is used, corruption of a single bit in a packet requires that the entire packet be retransmitted, which can be costly. At a given [[bit error rate]], larger packets are more susceptible to corruption. Their greater payload makes retransmissions of larger packets take longer. Despite the negative effects on retransmission duration, large packets can still have a net positive effect on end-to-end TCP performance.<ref>{{cite book|last=Murray|first=David |author2=Terry Koziniec |author3=Kevin Lee |author4=Michael Dixon |doi=10.1109/HPSR.2012.6260832 |isbn=978-1-4577-0833-6 |chapter=Large MTUs and internet performance |title=2012 IEEE 13th International Conference on High Performance Switching and Routing |pages=82–87 |year=2012 |s2cid=232321 |chapter-url=http://researchrepository.murdoch.edu.au/id/eprint/9920/ }}</ref>
Large packets are also problematic in the presence of communications errors. If no [[forward error correction]] is used, corruption of a single bit in a packet requires that the entire packet be retransmitted, which can be costly. At a given [[bit error rate]], larger packets are more susceptible to corruption. Their greater payload makes retransmissions of larger packets take longer. Despite the negative effects on retransmission duration, large packets can still have a net positive effect on end-to-end TCP performance.<ref>{{cite book|last=Murray|first=David |author2=Terry Koziniec |author3=Kevin Lee |author4=Michael Dixon |doi=10.1109/HPSR.2012.6260832 |isbn=978-1-4577-0833-6 |chapter=Large MTUs and internet performance |title=2012 IEEE 13th International Conference on High Performance Switching and Routing |pages=82–87 |year=2012 |s2cid=232321 |chapter-url=http://researchrepository.murdoch.edu.au/id/eprint/9920/ }}</ref>
Line 29: Line 29:


===MTUs for common media===
===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 an [[protocol overhead|overhead]] of 18 bytes, or 22 bytes with an [[IEEE 802.1Q]] tag for VLAN tagging or [[class of service]].
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 that all hosts must be prepared to accept. This is 576 bytes for [[IPv4]]<ref>{{cite IETF |rfc=791 |page=24 |quote=Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled.}}</ref> and of 1280 bytes for [[IPv6]].<ref>{{cite IETF |rfc=2460 |page=13}}</ref>
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"
{| class="wikitable sortable"
|-
|-

! Media for IP transport
! Media for IP transport
! Maximum transmission unit (bytes)
! Maximum transmission unit (bytes)
Line 41: Line 40:
|-
|-
| [[Internet]] IPv4 path MTU
| [[Internet]] IPv4 path MTU
| At least 68,{{Ref RFC|791|rp=24}} max of 64&nbsp;KiB{{Ref RFC|791|rp=12}}
| At least 68,<ref>{{cite IETF |rfc=791 |page=24 |quote=Every internet module must be able to forward a datagram of 68 octets without further fragmentation.}}</ref> max of 64&nbsp;KiB<ref>{{cite IETF |rfc=791 |page=12 |quote=Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets.}}</ref>
| Systems may use [[Path MTU Discovery]]<ref name="RFC 1191">{{cite IETF |rfc=1191}}</ref> to find the actual path MTU. Routing from larger MTU to smaller MTU causes [[IP fragmentation]].
| 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
| [[Internet]] IPv6 path MTU
| At least 1280,{{Ref RFC|8200}} max of 64&nbsp;KiB, but optional [[jumbogram]]s go up to 4&nbsp;GiB{{Ref RFC|2675}}
| At least 1280,<ref>{{IETF RFC|2460}}</ref> max of 64&nbsp;KiB, but up to 4&nbsp;GiB with optional [[jumbogram]]<ref>{{IETF RFC|2675}}, p. 1, "The IPv6 header [IPv6] has a 16-bit Payload Length field and, therefore, supports payloads up to 65,535 octets long. This document specifies an IPv6 hop-by-hop option, called the Jumbo Payload option, that carries a 32-bit length field in order to allow transmission of IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in length. Packets with such long payloads are referred to as 'jumbograms'."</ref>
| Systems must use Path MTU Discovery<ref>{{IETF RFC|6145}}</ref> to find the actual path MTU.
| 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]]
| [[X.25]]
| Minimal 576 (sending) or 1600 (receiving)<ref>{{IETF RFC|1356}}</ref>
| Minimal 576 (sending) or 1600 (receiving){{Ref RFC|1356}}
|
|
|-
|-
| [[Ethernet II framing|Ethernet v2]]
| [[Ethernet II framing|Ethernet v2]]
| 1500<ref>
| 1500{{Ref RFC|894}}
Network Working Group of the IETF,
{{IETF RFC|894}}: A Standard for the Transmission of IP Datagrams over Ethernet Networks,
Page 1,
"The maximum 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.",
[http://www.rfc-editor.org/errata_search.php?rfc=894 ERRATA]
⚫
</ref>
| Nearly all IP over Ethernet implementations use the [[Ethernet frame#Ethernet II|Ethernet II frame format]].
| Nearly all IP over Ethernet implementations use the [[Ethernet frame#Ethernet II|Ethernet II frame format]].
|-
|-
Line 68: Line 61:
|-
|-
| Ethernet [[jumbo frame]]s
| 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>
| 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
| 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
| url = https://www.stsauver.com/~joe/jumbos/jumbo-frames.pdf
Line 76: Line 69:
| author = Joe St Sauver | publisher = uoregon.edu
| author = Joe St Sauver | publisher = uoregon.edu
| page = 67
| page = 67
⚫
}}</ref>
}}</ref> Jumbo frames are usually only seen in special-purpose networks.
|-
|-
| [[Point-to-point protocol over Ethernet|PPPoE v2]]
| [[Point-to-point protocol over Ethernet|PPPoE v2]]
| 1492{{Ref RFC|2516}}
| 1492<ref>{{IETF RFC|2516}} with the standard Ethernet MTU of 1500 bytes; extensions exist</ref>
| Ethernet II MTU (1500) less PPPoE header (8)
| Ethernet II MTU (1500) less PPPoE header (8); extensions exist
|-
|-
| [[DS-Lite]] over PPPoE
| [[DS-Lite]] over PPPoE
Line 87: Line 80:
|-
|-
| PPPoE jumbo frames
| PPPoE jumbo frames
| 1493 – 9190 or more<ref>{{IETF RFC|4638}}</ref>
| 1493–9190 or more{{Ref RFC|4638}}
| Ethernet Jumbo Frame MTU (1501 - 9198) less PPPoE header (8)
| Ethernet Jumbo Frame MTU (1501–9198) less PPPoE header (8)
|-
|-
| [[IEEE 802.11]] Wi-Fi (WLAN)
| [[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>
| 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 [[MAC service data unit|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.
|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)]]
| [[IEEE 802.5|Token Ring (802.5)]]
Line 98: Line 91:
|
|
|-
|-
| [[Fiber Distributed Data Interface|FDDI]]
| [[FDDI]]
| 4352<ref name="RFC 1191"/>
| 4352{{Ref RFC|1191}}
|
|
|}
|}
Line 112: Line 105:
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.
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 [[Internet Protocol version 4|IPv4]]{{Ref RFC|1191}} and [[Internet Protocol version 6|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.
''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 [[Point-to-Point Protocol over Ethernet|PPPoE]] will reduce this. Path MTU Discovery exposes the difference between the MTU seen by Ethernet end-nodes and the Path MTU.
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.
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.

Latest revision as of 06:43, 1 January 2025

In computer networking, the maximum transmission unit (MTU) is the size of the largest protocol data unit (PDU) that can be communicated in a single network layer transaction.[1]: 25  The MTU relates to, but is not identical to the maximum frame size that can be transported on the data link layer, e.g., Ethernet frame.

Larger MTU is associated with reduced overhead. Smaller MTU values can reduce network delay. In many cases, MTU is dependent on underlying network capabilities and must be adjusted manually or automatically so as to not exceed these capabilities. MTU parameters may appear in association with a communications interface or standard. Some systems may decide MTU at connect time, e.g. using Path MTU Discovery.

Applicability

[edit]

MTUs apply to communications protocols and network layers. The MTU is specified in terms of bytes or octets of the largest PDU that the layer can pass onwards. MTU parameters usually appear in association with a communications interface (NIC, serial port, etc.). Standards (Ethernet, for example) can fix the size of an MTU; or systems (such as point-to-point serial links) may decide MTU at connect time.

Underlying data link and physical layers usually add overhead to the network layer data to be transported, so for a given maximum frame size of a medium, one needs to subtract the amount of overhead to calculate that medium's MTU. For example, with Ethernet, the maximum frame size is 1518 bytes, 18 bytes of which are overhead (header and frame check sequence), resulting in an MTU of 1500 bytes.

Tradeoffs

[edit]

A larger MTU brings greater efficiency because each network packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means an improvement in bulk protocol throughput. A larger MTU also requires processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation.

However, this gain is not without a downside. Large packets occupy a link for more time than a smaller packet, causing greater delays to subsequent packets, and increasing network delay and delay variation. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer, ties up a 14.4k modem for about one second.

Large packets are also problematic in the presence of communications errors. If no forward error correction is used, corruption of a single bit in a packet requires that the entire packet be retransmitted, which can be costly. At a given bit error rate, larger packets are more susceptible to corruption. Their greater payload makes retransmissions of larger packets take longer. Despite the negative effects on retransmission duration, large packets can still have a net positive effect on end-to-end TCP performance.[2]

Internet protocol

[edit]

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 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 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 layers 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

[edit]

In the context of Internet Protocol, MTU refers to the maximum size of an IP 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[1]: 24  and 1280 bytes for IPv6.[3]: 25 

Media for IP transport Maximum transmission unit (bytes) Notes
Internet IPv4 path MTU At least 68,[1]: 24  max of 64 KiB[1]: 12  Systems may use Path MTU Discovery[4] to find the actual path MTU. Routing from larger MTU to smaller MTU causes IP fragmentation.
Internet IPv6 path MTU At least 1280,[3] max of 64 KiB, but optional jumbograms go up to 4 GiB[5] Systems should use Path MTU Discovery[3] to find the actual path MTU, unless the minimum MTU (1280 bytes) is not exceeded.
Jumbograms are packets with a 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)[6]
Ethernet v2 1500[7] Nearly all IP over Ethernet implementations use the Ethernet II frame format.
Ethernet with LLC and SNAP 1492[8]
Ethernet jumbo frames 1501–9202[9] or more[10] 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.[11]
PPPoE v2 1492[12] 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[13] Ethernet Jumbo Frame MTU (1501–9198) less PPPoE header (8)
IEEE 802.11 Wi-Fi (WLAN) 2304[14] 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.
Token Ring (802.5) 4464
FDDI 4352[4]

Ethernet maximum frame size

[edit]

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 frames 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

[edit]
Main article: Path MTU Discovery

The Internet Protocol defines the path MTU of an Internet transmission path as the smallest MTU supported by any of the hops 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[4] and IPv6[15]. 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 (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 drop ICMP traffic (for example, to prevent denial-of-service attacks), which prevents path MTU discovery from working. Packetization Layer Path MTU Discovery[16][17] 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, congestion, 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 firewalls 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 (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 TCP connection at one's firewall.

In other contexts

[edit]

MTU is sometimes used to describe the maximum PDU sizes in communication layers other than the network layer.

The transmission of a packet on a physical network segment that is larger than the segment's MTU is known as jabber. This is almost always caused by faulty devices.[23] Network switches and some repeater hubs have a built-in capability to detect when a device is jabbering.[24][25]

References

[edit]
  1. ^ a b c d J. Postel, ed. (September 1981). INTERNET PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION. IETF. doi:10.17487/RFC0791. STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Internet Standard 5. Obsoletes RFC 760. Updated by RFC 1349, 2474 and 6864.
  2. ^ Murray, David; Terry Koziniec; Kevin Lee; Michael Dixon (2012). "Large MTUs and internet performance". 2012 IEEE 13th International Conference on High Performance Switching and Routing. pp. 82–87. doi:10.1109/HPSR.2012.6260832. ISBN 978-1-4577-0833-6. S2CID 232321.
  3. ^ a b c S. Deering; R. Hinden (July 2017). Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. doi:10.17487/RFC8200. STD 86. RFC 8200. Internet Standard 86. Obsoletes RFC 2460.
  4. ^ a b c J. Mogul; S. Deering (November 1990). Path MTU Discovery. Network Working Group. doi:10.17487/RFC1191. RFC 1191. Draft Standard. Obsoletes RFC 1063.
  5. ^ D. Borman; S. Deering; R. Hinden (August 1999). IPv6 Jumbograms. Network Working Group. doi:10.17487/RFC2675. RFC 2675. Proposed Standard. Obsoletes RFC 2147.
  6. ^ A. Malis; D. Robinson; R. Ullmann (August 1992). Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. Network Working Group. doi:10.17487/RFC1356. RFC 1356. Draft Standard. Obsoletes RFC 877.
  7. ^ C. Hornig (April 1984). A Standard for the Transmission of IP Datagrams over Ethernet Networks. Network Working Group. doi:10.17487/RFC0894. STD 41. RFC 894. Internet Standard 41.
  8. ^ IEEE 802.3[page needed]
  9. ^ Scott Hogg (2013-03-06), Jumbo Frames, Network World, retrieved 2013-08-05, Most network devices support a jumbo frame size of 9216 bytes.
  10. ^ Juniper Networks (2020-03-23), Physical Interface Properties, retrieved 2020-05-01
  11. ^ Joe St Sauver (2003-02-04). "Practical Issues Associated With 9K MTUs" (PDF). uoregon.edu. p. 67. Retrieved 2016-12-15. you still need to insure that ALL upstream Ethernet switches, including any switches in your campus core, are ALSO jumbo frame capable
  12. ^ L. Mamakos; K. Lidl; J. Evarts; D. Carrel; D. Simone; R. Wheeler (February 1999). A Method for Transmitting PPP Over Ethernet (PPPoE). Network Working Group. doi:10.17487/RFC2518. RFC 2518. Informational.
  13. ^ P. Arberg; D. Kourkouzelis; M. Duckett; T. Anschutz; J. Moisand (September 2006). Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE). Network Working Group. doi:10.17487/RFC4638. RFC 4638. Informational.
  14. ^ 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."
  15. ^ J. McCann; S. Deering; J. Mogul (July 2017). R. Hinden (ed.). Path MTU Discovery for IP version 6. Internet Engineering Task Force. doi:10.17487/RFC8201. STD 87. RFC 8201. Internet Standard 87. Obsoletes RFC 1981.
  16. ^ M. Mathis; J. Heffner (March 2007). Packetization Layer Path MTU Discovery. Network Working Group. doi:10.17487/RFC4821. RFC 4821. Proposed Standard. Updated by RFC 8899.
  17. ^ G. Fairhurst; T. Jones; M. Tüxen; I. Rüngeler; T. Völker (September 2020). Packetization Layer Path MTU Discovery for Datagram Transports. Internet Engineering Task Force. doi:10.17487/RFC8899. ISSN 2070-1721. RFC 8899. Proposed Standard. Updates RFC 4821, 4960, 6951, 8085 and 8261.
  18. ^ "Configure and Verify Maximum Transmission Unit on Cisco Nexus Platforms". Cisco. 2016-11-29. Document ID:118994. Retrieved 2017-01-04.
  19. ^ "MTU in RouterOS". MikroTik. 2022-07-08. Retrieved 2022-09-02.
  20. ^ "How to configure MTU (Maximum Transmission Unit) for Jumbo Frames on Dell Networking Force10 switches". Dell. 2016-06-02. Article ID: HOW10713. Retrieved 2017-01-06.
  21. ^ "Jumbo Frames". HP Networking 2910al Switches Management and Configuration Guide. Hewlett-Packard. November 2011. P/N 5998-2874.
  22. ^ "SRX Series Services Gateways for the Branch Physical Interface Modules Reference: MTU Default and Maximum Values for Physical Interface Modules". Juniper. 2014-01-03. Retrieved 2017-01-04.
  23. ^ jabber, The Network Encyclopedia, retrieved 2016-07-28
  24. ^ show interfaces, Juniper Networks, retrieved 2016-07-28
  25. ^ IEEE 802.3 27.3.1.7 Receive jabber functional requirements
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Maximum_transmission_unit&oldid=1266568638"