Internet-Draft BGP Next Hop MTU October 2026
Mauch Expires 1 May 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-mauch-bgp-nh-mtu-00
Published:
Intended Status:
Standards Track
Expires:
Author:
J. Mauch
Akamai

BGP Next Hop MTU Attribute

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.

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]).

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

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:

  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.

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.

     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.

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.

Table 1: BGP Path Attributes registry addition
Value Code Reference
TBD NEXT_HOP_MTU This document

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.

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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8200>.

11. Informative References

[I-D.blahaj-idr-bgp-mtu]
Misell, Q., "Signalling Path MTU via BGP Attributes", Work in Progress, Internet-Draft, draft-blahaj-idr-bgp-mtu, , <https://theenbyperor.github.io/draft-blahaj-idr-bgp-mtu/draft-blahaj-idr-bgp-mtu.html>.
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, , <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, , <https://www.rfc-editor.org/info/rfc1191>.
[RFC2675]
Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, , <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, , <https://www.rfc-editor.org/info/rfc4456>.
[RFC4821]
Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9552>.

Author's Address

Jared Mauch
Akamai