| Internet-Draft | BGP Next Hop MTU | October 2026 |
| Mauch | Expires 1 May 2027 | [Page] |
This document defines NEXT_HOP_MTU, an optional non-transitive BGP path attribute (type code TBD). It carries the IP MTU a speaker promises is acceptable for an NLRI across one network boundary. The speaker that receives the NLRI across that boundary may attach the attribute from the boundary interface MTU and advertise it on internal and external sessions. The intent is to communicate network MTU capability so that devices can use that information to improve the efficiency of their communications.¶
This note is to be removed before publishing as an RFC.¶
This document is an individual submission intended for consideration by the Inter-Domain Routing (IDR) Working Group. Discussion takes place on the IDR mailing list (idr@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/idr/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Operators often configure a network boundary to accept IP packets larger than 1500 octets (for example, 9000). Internal hosts and routers can use that size only if they learn it. BGP advertises the NLRI but has no way to carry the boundary IP MTU with the route. Extending the path attributes carried with the NLRI to pass that network-boundary information is useful to mitigate the negative impacts of Path MTU Discovery ([RFC1191], [RFC4821]) and IPv6 Packet Too Big handling ([RFC8201]).¶
NEXT_HOP_MTU is an optional, non-transitive path attribute. The speaker that receives an NLRI across a network boundary may attach a 32-bit IP MTU for that boundary and advertise it with the route. The value is a promise that an IP packet of that size, destined to the NLRI, is acceptable across that boundary. It is not a Path MTU ([RFC8201], [RFC1191], [RFC4821]). BGP-LS can carry per-link MTU in a topology ([RFC9552], [I-D.ietf-idr-bgp-ls-link-mtu]); this attribute attaches the promise to an ordinary unicast NLRI.¶
This document uses the BGP terminology of [RFC4271] and [RFC4760]. IP MTU means the largest IP packet, in octets, that can cross a link in one piece (IP header and payload; link-layer framing excluded). Network boundary means the edge interface across which the route was learned and toward which traffic for the NLRI is forwarded.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
NEXT_HOP_MTU is optional and non-transitive. IANA assigns the type code (TBD; Section 7). The attribute applies to every NLRI in the UPDATE that carries it. It is a path attribute, not part of the NLRI encoding ([RFC4271], [RFC4760]).¶
The attribute is defined for IPv4 unicast (AFI 1, SAFI 1) and IPv6 unicast (AFI 2, SAFI 1). A speaker MUST NOT attach it to any other AFI/SAFI.¶
The attribute uses the three-octet header of [RFC4271] followed by a four-octet value. The Extended Length bit is clear.¶
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Type (TBD) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When attaching the attribute, the flags octet MUST be 0x80 (Optional set; Transitive, Partial, Extended Length, and reserved bits clear). The length is 4. Unrecognized optional non-transitive attributes are ignored and not propagated ([RFC4271]).¶
IP MTU is an unsigned 32-bit integer in network byte order: the maximum acceptable IP packet size across the network boundary for the NLRI (IPv6 header and payload included; see [RFC8200]). This is a link / IP MTU, not the Jumbo Payload Length field of [RFC2675].¶
For IPv4 NLRI the value MUST be in the range 68 to 65535 inclusive ([RFC791]). For IPv6 NLRI the value MUST be in the range 1280 to 4294967295 inclusive. Without the Jumbo Payload option, the largest IPv6 packet is 65575 octets (40-octet IPv6 header plus a Payload Length of 65535). Values from 1280 to 65575 inclusive are therefore ordinary IPv6 IP MTUs. Values greater than or equal to 65576 indicate a jumbogram-capable boundary: [RFC2675] requires a link MTU greater than 65575 before jumbograms can be sent, and such a promise is useful only where nodes will send and receive the Jumbo Payload option.¶
The network boundary is the interface on which the receiving speaker forwards toward the BGP next hop when that interface is the edge the route was learned across. For a directly connected external session, that is the session interface. The boundary IP MTU is that interface's IP MTU for the NLRI address family.¶
A speaker MUST NOT replace NEXT_HOP_MTU with the MTU of an internal interface when readvertising a route learned across a different edge. For multi-hop external sessions, the speaker MUST NOT invent a boundary from an unrelated interface. It MAY attach a configured promissory value for that neighbor; the configured value MUST be less than or equal to the IP MTU of the interface that forwards toward the next hop.¶
A speaker that receives an NLRI across a network boundary MAY attach NEXT_HOP_MTU when installing and when advertising the route, whether or not the route arrived with the attribute. The attached value is computed as follows:¶
All NLRI in one UPDATE that carries NEXT_HOP_MTU MUST share the same value; otherwise they MUST be split across UPDATE messages. Absence of the attribute means no promise.¶
Implementations MUST allow enabling and disabling attachment and acceptance of received values per neighbor and per AFI/SAFI. Neither is required to be enabled by default.¶
On an internal session, a speaker that does not forward the NLRI across a different boundary SHOULD advertise the attribute unchanged when the next hop is unchanged. A route reflector that does not change the next hop SHOULD forward it unchanged ([RFC4456]). The border speaker that attached the value in Section 3.2 SHOULD include that value toward internal peers, including when it sets next hop to self.¶
On an external session, the attached value MUST be the promise for traffic that crosses the boundary with that peer. If the route already has a valid NEXT_HOP_MTU and the speaker knows the facing interface IP MTU, the attached value MUST be the minimum of the two (then reduced by local policy if applicable). A speaker MUST NOT copy a promise for one boundary onto a different boundary without that minimum. If the value cannot be determined, the attribute MAY be omitted.¶
An originating speaker MAY attach NEXT_HOP_MTU using the IP MTU of the boundary it advertises across, subject to Section 2.1. The receiving speaker may still attach from its own side whether or not the originator sent the attribute.¶
Attaching NEXT_HOP_MTU promises that an IP packet destined to a covered NLRI, of size less than or equal to the value, is acceptable across the identified boundary (the interface permits it and the speaker will forward it). Applications MAY use the value when sending toward the NLRI across that boundary. A value greater than or equal to 65576 is a jumbogram-capable promise and is useful only where the sender and the boundary support the Jumbo Payload option ([RFC2675]). NEXT_HOP_MTU MUST NOT by itself change the BGP Decision Process ([RFC4271]). Path MTU Discovery and IPv6 Packet Too Big handling remain required for the minimum MTU of a full path ([RFC8201], [RFC1191]).¶
A speaker MAY program the value as a per-destination forwarding MTU only when every forwarding path for the NLRI carries a valid NEXT_HOP_MTU; the programmed value MUST be the minimum of those path values. Otherwise it MUST NOT program a promissory MTU for the destination.¶
When aggregating, a speaker MAY attach NEXT_HOP_MTU only if every included component has a valid value; the aggregate value MUST be the minimum of the component values. Otherwise omit the attribute from the aggregate.¶
When the boundary IP MTU changes, the speaker that attached NEXT_HOP_MTU from that boundary MUST advertise a replacement route for each affected NLRI with the new value (or omit the attribute if it no longer makes a promise).¶
In Figure 2, Router A in AS 65000 advertises 2001:db8::/48 to Router B in AS 65001. The boundary permits an IP payload of 9000 octets. Router B adds NEXT_HOP_MTU with value 9000 (0x00002328) and advertises it to Router C over iBGP. The same receive-and-attach procedure applies in the reverse direction.¶
AS 65000 AS 65001
+---------------+ +---------------+
| Router A |=== eBGP ===| Router B |
| 2001:db8:1::1 | IP payload | 2001:db8:1::2 |
| advertises | 9000 | receives NLRI |
| 2001:db8::/48 | octets | adds NH-MTU |
+---------------+ | value 9000 |
+---------------+
|
| iBGP
| NH-MTU 9000
v
+---------------+
| Router C |
| internal |
| application |
+---------------+
The boundary addresses (2001:db8:1::1 and 2001:db8:1::2) are outside the advertised prefix. If Router B sets next hop to self toward Router C, NEXT_HOP_MTU remains 9000 because traffic still crosses the same boundary.¶
A NEXT_HOP_MTU attribute is malformed if it appears more than once in the UPDATE, its length is not 4, or its flags are not exactly 0x80. Malformed NEXT_HOP_MTU attributes use attribute discard ([RFC7606]): discard the attribute, process the UPDATE as if it were absent, and MUST NOT session-reset or treat the NLRI as withdrawn.¶
A speaker MUST NOT use a NEXT_HOP_MTU value as a promissory MTU when the value is 0, when the UPDATE carries IPv4 NLRI and the value is outside 68..65535, when the UPDATE carries IPv6 NLRI and the value is less than 1280, or when the UPDATE carries NLRI for an AFI/SAFI other than IPv4 or IPv6 unicast. In those cases the speaker treats the UPDATE as if the attribute were absent.¶
Enable attachment toward the neighbors that should receive the promise, with the boundary interface MTU configured accordingly. If a received value is accepted, the propagated value is min(local boundary MTU, received value). This document makes no changes to IPv6 Packet Too Big ([RFC8201]), IPv4 Path MTU Discovery ([RFC1191]), or Packetization Layer Path MTU Discovery ([RFC4821]) behavior.¶
IANA is requested to assign a code point from the BGP Path Attributes registry for NEXT_HOP_MTU (optional, non-transitive; value field four octets), as shown in Table 1. The RFC Editor is asked to replace TBD throughout this document with the assigned code point.¶
| Value | Code | Reference |
|---|---|---|
| TBD | NEXT_HOP_MTU | This document |
This section is to be removed before publishing as an RFC.¶
This note records adjacent work encountered while preparing this document. It is not normative.¶
[I-D.blahaj-idr-bgp-mtu] proposes signalling Path MTU via a BGP capability and an optional non-transitive Path MTU path attribute. That work accumulates a path-scoped MTU along the route and uses a narrower value field. This document instead attaches a promissory IP MTU for one network boundary to an ordinary unicast NLRI and does not define a path-minimum attribute. An editor's copy is available at https://theenbyperor.github.io/draft-blahaj-idr-bgp-mtu/draft-blahaj-idr-bgp-mtu.html.¶
[I-D.ietf-idr-bgp-ls-link-mtu] carries a per-link MTU in BGP-LS (IANA TLV 1104). That is topology input for controllers, not a path attribute on IPv4/IPv6 unicast routes. The BGP-LS value is two octets and therefore cannot represent jumbogram-sized IP MTUs.¶
An overstated value can cause packet loss; an understated value reduces efficiency. Deriving the attached value from the local interface MTU limits overstatement by a peer. Accepting a received value can only reduce the attached value (via the minimum) but can propagate an understated promise; operators SHOULD accept received values from external peers only when those peers are trusted.¶