BGP Next Hop MTU Attribute

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 (, ) and IPv6 Packet Too Big handling (). 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 (, , ). BGP-LS can carry per-link MTU in a topology (, ); this attribute attaches the promise to an ordinary unicast NLRI. This document uses the BGP terminology of and . 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.

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 when, and only when, they appear in all capitals, as shown here.

NEXT_HOP_MTU Attribute NEXT_HOP_MTU is optional and non-transitive. IANA assigns the type code (TBD; ). The attribute applies to every NLRI in the UPDATE that carries it. It is a path attribute, not part of the NLRI encoding (, ). 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.

Encoding The attribute uses the three-octet header of followed by a four-octet value. The Extended Length bit is clear.

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 (). 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 ). This is a link / IP MTU, not the Jumbo Payload Length field of . For IPv4 NLRI the value MUST be in the range 68 to 65535 inclusive (). 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: 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.

Procedures

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.

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:

Let L be the boundary IP MTU. If L cannot be determined, or is outside the range in for the address family, the speaker MUST NOT attach the attribute.
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.
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.

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 (). The border speaker that attached the value in 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 . The receiving speaker may still attach from its own side whether or not the originator sent the attribute.

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 (). NEXT_HOP_MTU MUST NOT by itself change the BGP Decision Process (). Path MTU Discovery and IPv6 Packet Too Big handling remain required for the minimum MTU of a full path (, ). 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).

Example In , 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 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.

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 (): 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.

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 (), IPv4 Path MTU Discovery (), or Packetization Layer Path MTU Discovery () behavior.

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 . The RFC Editor is asked to replace TBD throughout this document with the assigned code point. BGP Path Attributes registry addition

Value	Code	Reference
TBD	NEXT_HOP_MTU	This document

Notes on Adjacent Work This note records adjacent work encountered while preparing this document. It is not normative. 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 . 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.

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.