BGP Next Hop MTU Attribute
draft-mauch-bgp-nh-mtu-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jared Mauch | ||
| Last updated | 2026-10-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mauch-bgp-nh-mtu-00
Network Working Group J. Mauch
Internet-Draft Akamai
Intended status: Standards Track 28 October 2026
Expires: 1 May 2027
BGP Next Hop MTU Attribute
draft-mauch-bgp-nh-mtu-00
Abstract
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.
Discussion Venues
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/.
Status of This Memo
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.
Mauch Expires 1 May 2027 [Page 1]
Internet-Draft BGP Next Hop MTU October 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. NEXT_HOP_MTU Attribute . . . . . . . . . . . . . . . . . . . 3
2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Network Boundary . . . . . . . . . . . . . . . . . . . . 4
3.2. Attaching on Receipt . . . . . . . . . . . . . . . . . . 4
3.3. Advertisement . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Use of the Value . . . . . . . . . . . . . . . . . . . . 6
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 7
6. Operational Considerations . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Notes on Adjacent Work . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
11. Informative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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]).
Mauch Expires 1 May 2027 [Page 2]
Internet-Draft BGP Next Hop MTU October 2026
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.
1.1. Requirements Language
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.
2. NEXT_HOP_MTU Attribute
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.
2.1. Encoding
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NEXT_HOP_MTU encoding
Mauch Expires 1 May 2027 [Page 3]
Internet-Draft BGP Next Hop MTU October 2026
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.
3. Procedures
3.1. Network Boundary
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.
3.2. Attaching on Receipt
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:
Mauch Expires 1 May 2027 [Page 4]
Internet-Draft BGP Next Hop MTU October 2026
1. Let L be the boundary IP MTU. If L cannot be determined, or is
outside the range in Section 2.1 for the address family, the
speaker MUST NOT attach the attribute.
2. If the received route has a valid NEXT_HOP_MTU value R and local
policy accepts R from that neighbor, the attached value is min(L,
R); otherwise it is L.
3. Local policy MAY further reduce the value and MUST NOT increase
it. The result MUST remain in range for the address family.
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.
3.3. Advertisement
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.
Mauch Expires 1 May 2027 [Page 5]
Internet-Draft BGP Next Hop MTU October 2026
3.4. Use of the Value
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).
4. Example
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.
Mauch Expires 1 May 2027 [Page 6]
Internet-Draft BGP Next Hop MTU October 2026
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 |
+---------------+
Figure 2: AS 65000 and AS 65001 exchange 2001:db8::/48
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.
5. Error Handling
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.
Mauch Expires 1 May 2027 [Page 7]
Internet-Draft BGP Next Hop MTU October 2026
6. Operational Considerations
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.
7. IANA Considerations
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 |
+-------+--------------+---------------+
Table 1: BGP Path Attributes
registry addition
8. Notes on Adjacent Work
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.
Mauch Expires 1 May 2027 [Page 8]
Internet-Draft BGP Next Hop MTU October 2026
9. Security Considerations
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.
10. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
11. Informative References
Mauch Expires 1 May 2027 [Page 9]
Internet-Draft BGP Next Hop MTU October 2026
[I-D.blahaj-idr-bgp-mtu]
Misell, Q., "Signalling Path MTU via BGP Attributes", Work
in Progress, Internet-Draft, draft-blahaj-idr-bgp-mtu,
December 2024, <https://theenbyperor.github.io/draft-
blahaj-idr-bgp-mtu/draft-blahaj-idr-bgp-mtu.html>.
[I-D.ietf-idr-bgp-ls-link-mtu]
Zhu, Y., Hu, Z., Peng, S., and R. Mwehair, "Signaling
Maximum Transmission Unit (MTU) using BGP-LS", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-ls-link-mtu-
12, 20 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-idr-bgp-ls-link-mtu-12>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, DOI 10.17487/RFC2675, August 1999,
<https://www.rfc-editor.org/info/rfc2675>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Author's Address
Jared Mauch
Akamai
Email: jared@akamai.com
Mauch Expires 1 May 2027 [Page 10]