1. INTRODUCTION
1.1 Reading this Document
1.1.1 Organization
This memo emulates the layered organization used by [INTRO:2] and [INTRO:3]. Thus, Chapter 2 describes the layers found in the Internet architecture. Chapter 3 covers the Link Layer. Chapters 4 and 5 are concerned with the Internet Layer protocols and
forwarding algorithms. Chapter 6 covers the Transport Layer.
Upper layer protocols are divided between Chapter 7, which discusses the protocols which routers use to exchange routing information with each other, Chapter 8, which discusses network management, and Chapter 9, which discusses other upper layer protocols. The final chapter covers operations and maintenance features. This organization was chosen for simplicity, clarity, and consistency with the Host Requirements RFCs. Appendices to this memo include a bibliography, a glossary, and some conjectures about future directions of router standards.
In describing the requirements, we assume that an implementation strictly mirrors the layering of the protocols. However, strict layering is an imperfect model, both for the protocol suite and for recommended implementation approaches. Protocols in different layers interact in complex and sometimes subtle ways, and
particular functions often involve multiple layers. There are many design choices in an implementation, many of which involve creative breaking of strict layering. Every implementor is urged to read [INTRO:4] and [INTRO:5].
In general, each major section of this memo is organized into the following subsections:
(1) Introduction
(2) Protocol Walk-Through - considers the protocol specification documents section-by-section, correcting errors, stating requirements that may be ambiguous or ill-defined, and providing further clarification or explanation.
(3) Specific Issues - discusses protocol design and
implementation issues that were not included in the through.
Under many of the individual topics in this memo, there is
parenthetical material labeled DISCUSSION or IMPLEMENTATION. This material is intended to give a justification, clarification or
explanation to the preceding requirements text. The
implementation material contains suggested approaches that an implementor may want to consider. The DISCUSSION and
IMPLEMENTATION sections are not part of the standard.
1.1.2 Requirements
In this memo, the words that are used to define the significance of each particular requirement are capitalized. These words are:
o MUST
This word means that the item is an absolute requirement of the specification.
o MUST IMPLEMENT
This phrase means that this specification requires that the item be implemented, but does not require that it be enabled by default.
o MUST NOT
This phrase means that the item is an absolute prohibition of the specification.
o SHOULD
This word means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
o SHOULD IMPLEMENT
This phrase is similar in meaning to SHOULD, but is used when we recommend that a particular feature be provided but does not necessarily recommend that it be enabled by default.
o SHOULD NOT
This phrase means that there may exist valid reasons in particular circumstances when the described behavior is
acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
o MAY
This word means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example;
another vendor may omit the same item.
1.1.3 Compliance
Some requirements are applicable to all routers. Other requirements are applicable only to those which implement
particular features or protocols. In the following paragraphs, Relevant refers to the union of the requirements applicable to all routers and the set of requirements applicable to a particular router because of the set of features and protocols it has implemented.
Note that not all Relevant requirements are stated directly in this memo. Various parts of this memo incorporate by reference sections of the Host Requirements specification, [INTRO:2] and [INTRO:3]. For purposes of determining compliance with this memo, it does not matter whether a Relevant requirement is stated
directly in this memo or merely incorporated by reference from one of those documents.
An implementation is said to be conditionally compliant if it satisfies all of the Relevant MUST, MUST IMPLEMENT, and MUST NOT requirements. An implementation is said to be unconditionally compliant if it is conditionally compliant and also satisfies all of the Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT
requirements. An implementation is not compliant if it is not conditionally compliant (i.e., it fails to satisfy one or more of the Relevant MUST, MUST IMPLEMENT, or MUST NOT requirements).
For any of the SHOULD and SHOULD NOT requirements, a router may provide a configuration option that will cause the router to act other than as specified by the requirement. Having such a
configuration option does not void a router’s claim to
unconditional compliance as long as the option has a default
setting, and that leaving the option at its default setting causes the router to operate in a manner which conforms to the
requirement.
Likewise, routers may provide, except where explicitly prohibited by this memo, options which cause them to violate MUST or MUST NOT requirements. A router which provides such options is compliant (either fully or conditionally) if and only if each such option has a default setting which causes the router to conform to the requirements of this memo. Please note that the authors of this memo, although aware of market realities, strongly recommend against provision of such options. Requirements are labeled MUST or MUST NOT because experts in the field have judged them to be particularly important to interoperability or proper functioning in the Internet. Vendors should weigh carefully the customer
support costs of providing options which violate those rules.
Of course, this memo is not a complete specification of an IP router, but rather is closer to what in the OSI world is called a profile. For example, this memo requires that a number of
protocols be implemented. Although most of the contents of their protocol specifications are not repeated in this memo,
implementors are nonetheless required to implement the protocols according to those specifications.