Summary

  • A 28 October individual Internet-Draft proposes NEXT_HOP_MTU, an optional, non-transitive BGP path attribute with a four-octet IP MTU value for IPv4 and IPv6 unicast routes. It promises a packet size across one identified boundary, not the minimum for an entire route to a destination.
  • A speaker attaching the value uses its own boundary MTU. It may accept a neighbor's valid value only by taking the smaller number, and local policy may reduce it again. A destination forwarding MTU can be programmed only if every forwarding path carries a valid value.

A border can speak only for its own gate

Suppose a border router learns a route across a link that accepts large IP packets. It advertises the route internally with the proposed NEXT_HOP_MTU attribute. An application may use the number when sending toward that destination across the identified boundary. It must still contend with every other link on the journey. The proposal says the attribute is not Path MTU Discovery and cannot, by itself, change BGP's route-selection process. One router's promise is a useful receipt, not a claim of ownership over the entire road.

The draft's arithmetic is deliberately one-way. Let L be the local boundary interface's IP MTU. If the router accepts a valid R from the neighbor, it attaches min(L,R); otherwise it attaches L. Local policy may cut the result, never raise it. The router cannot swap in a convenient internal-interface MTU for the edge actually crossed. A multihop external session cannot invent a boundary from an unrelated interface; a configured promise must be no greater than the interface that forwards toward the next hop. A generous number cannot be laundered through a small gate.

The proposal also refuses to let silence masquerade as capacity. Attachment and acceptance must be separately switchable per neighbor and address family, with neither required on by default. An absent attribute means no promise. On an internal session, a route reflector with the same next hop should pass the value unchanged. On a different external boundary, the router must take the minimum with that boundary's MTU. An aggregate can carry a value only if every component route has a valid one. A forwarding device may install a destination MTU only when every forwarding path has a valid value, choosing the lowest.

One unmeasured path vetoes a confident forwarding setting.

Bad data does not get to take the route down. A malformed attribute is discarded under the RFC 7606 model; the BGP session stays up and the NLRI is not withdrawn. The draft says a boundary MTU change requires a replacement advertisement. Operators therefore need to see both the new value and the case where the promise disappears. The attribute has a code point marked TBD; IANA's BGP registry is the authority for an actual assignment.

There is an incentive problem as well as a wire format. Overstate the value and packets can be lost. Understate it and capacity goes unused. The draft warns that accepting values from an external peer can propagate an understated promise and says operators should trust those peers first. A peer's low number is easy to pass along; the reason for it is not. IPv6 Path MTU Discovery and Packet Too Big handling still determine the minimum along a full path.

The IETF record lists an individual proposal, with no implementation trace or measured efficiency result. A multi-border test showing each received value, local interface, policy reduction, aggregate and forwarding-path choice would show whether the promise stays attached to the gate that made it.

Sources: draft; IETF status; IANA registry; RFC 7606; RFC 8201.