No High Link Numbers
A proposal to keep link numbers at or below 63.
Crocker, S.D., "No High Link Numbers", RFC 25, DOI 10.17487/RFC0025, October 1969, <https://www.rfc-editor.org/info/rfc25>.
@misc{rfc25,
series = {Request for Comments},
number = 25,
howpublished = {RFC 25},
publisher = {RFC Editor},
doi = {10.17487/RFC0025},
url = {https://www.rfc-editor.org/info/rfc25},
author = {S.D. Crocker},
title = {{No High Link Numbers}},
pagetotal = 1,
year = 1969,
month = oct,
} RFC text
Network Working Group Steve Crocker
Request for Comments: 25 UCLA
30 October 1969
NO HIGH LINK NUMBERS
Because it may be desirable to reserve one or more link numbers for
instrumentation purposes, and because 256 link numbers are many more
than are needed, we suggest that no link number over 63 be used. At
UCLA, we will implement our tables to take advantage of this limitation.
We also note that 32 may be even more realistic, but 64 is certainly
sufficient.
ISO Plain Language
On this page
§1Why Use Fewer Link Numbers
The note says 256 link numbers are many more than needed. It also says it may be desirable to reserve one or more numbers for instrumentation.
On these grounds, the author suggests that no link number over 63 be used.
The author thinks the protocol allows more link numbers than are needed. Keeping the highest numbers unused could leave some available for instrumentation.
§1Proposed Limit and UCLA's Plan
The proposed rule is that no link number over 63 be used. The note says UCLA will implement its tables to take advantage of this limitation.
It adds that 32 may be a more realistic number, while 64 is certainly sufficient.
The note recommends staying at or below link number 63. UCLA says it will design its tables for that limit, though the author thinks 32 may often be enough.
§1Scope of the Note
RFC 25 gives a short recommendation and says how UCLA plans to implement its tables. It does not specify a formal allocation procedure or report that every site adopted the proposed limit.
This is a brief proposal with an implementation intention from UCLA. The note does not describe a network-wide adoption decision.