implemented.
A router connects to two or more logical interfaces, represented by
IP subnets or unnumbered point to point lines (discussed in section
[2.2.7]). Thus, it has at least one physical interface. Forwarding
an IP datagram generally requires the router to choose the address
and relevant interface of the next-hop router or (for the final hop)
the destination host. This choice, called relaying or forwarding
depends upon a route database within the router. The route database
is also called a routing table or forwarding table. The term
"router" derives from the process of building this route database;
routing protocols and configuration interact in a process called
routing.
The routing database should be maintained dynamically to reflect the
current topology of the Internet system. A router normally
accomplishes this by participating in distributed routing and
reachability algorithms with other routers.
Routers provide datagram transport only, and they seek to minimize
the state information necessary to sustain this service in the
interest of routing flexibility and robustness.
Packet switching devices may also operate at the Link Layer; such
devices are usually called bridges. Network segments that are
connected by bridges share the same IP network prefix forming a
single IP subnet. These other devices are outside the scope of this
document.
2.2.4 Autonomous Systems
An Autonomous System (AS) is a connected segment of a network
topology that consists of a collection of subnetworks (with hosts
attached) interconnected by a set of routes. The subnetworks and the
routers are expected to be under the control of a single operations
and maintenance (O&M) organization. Within an AS routers may use one
or more interior routing protocols, and sometimes several sets of
metrics. An AS is expected to present to other ASs an appearence of
a coherent interior routing plan, and a consistent picture of the
destinations reachable through the AS. An AS is identified by an
Autonomous System number.
The concept of an AS plays an important role in the Internet routing
(see Section 7.1).
2.2.5 Addressing Architecture
An IP datagram carries 32-bit source and destination addresses, each
of which is partitioned into two parts - a constituent network prefix
and a host number on that network. Symbolically:
IP-address ::= { <Network-prefix>, <Host-number> }
To finally deliver the datagram, the last router in its path must map
the Host-number (or rest) part of an IP address to the host's Link
Layer address.
2.2.5.1 Classical IP Addressing Architecture
Although well documented elsewhere [INTERNET:2], it is useful to
describe the historical use of the network prefix. The language
developed to describe it is used in this and other documents and
permeates the thinking behind many protocols.
The simplest classical network prefix is the Class A, B, C, D, or E
network prefix. These address ranges are discriminated by observing
the values of the most significant bits of the address, and break the
address into simple prefix and host number fields. This is described
in [INTERNET:18]. In short, the classification is:
0xxx - Class A - general purpose unicast addresses with standard
8 bit prefix
10xx - Class B - general purpose unicast addresses with standard
16 bit prefix
110x - Class C - general purpose unicast addresses with standard
24 bit prefix
1110 - Class D - IP Multicast Addresses - 28 bit prefix, non-
aggregatable
1111 - Class E - reserved for experimental use
This simple notion has been extended by the concept of subnets.
These were introduced to allow arbitrary complexity of interconnected
LAN structures within an organization, while insulating the Internet
system against explosive growth in assigned network prefixes and
routing complexity. Subnets provide a multi-level hierarchical
routing structure for the Internet system. The subnet extension,
described in [INTERNET:2], is a required part of the Internet
architecture. The basic idea is to partition the <Host-number> field
into two parts: a subnet number, and a true host number on that
subnet:
IP-address ::=
{ <Network-number>, <Subnet-number>, <Host-number> }
The interconnected physical networks within an organization use the
same network prefix but different subnet numbers. The distinction
between the subnets of such a subnetted network is not normally
visible outside of that network. Thus, routing in the rest of the
Internet uses only the <Network-prefix> part of the IP destination
address. Routers outside the network treat <Network-prefix> and
<Host-number> together as an uninterpreted rest part of the 32-bit IP
address. Within the subnetted network, the routers use the extended
network prefix:
{ <Network-number>, <Subnet-number> }
The bit positions containing this extended network number have
historically been indicated by a 32-bit mask called the subnet mask.
The <Subnet-number> bits SHOULD be contiguous and fall between the
<Network-number> and the <Host-number> fields. More up to date
protocols do not refer to a subnet mask, but to a prefix length; the
"prefix" portion of an address is that which would be selected by a
subnet mask whose most significant bits are all ones and the rest are
zeroes. The length of the prefix equals the number of ones in the
subnet mask. This document assumes that all subnet masks are
expressible as prefix lengths.
The inventors of the subnet mechanism presumed that each piece of an
organization's network would have only a single subnet number. In
practice, it has often proven necessary or useful to have several
subnets share a single physical cable. For this reason, routers
should be capable of configuring multiple subnets on the same
physical interfaces, and treat them (from a routing or forwarding
perspective) as though they were distinct physical interfaces.
2.2.5.2 Classless Inter Domain Routing (CIDR)
The explosive growth of the Internet has forced a review of address
assignment policies. The traditional uses of general purpose (Class
A, B, and C) networks have been modified to achieve better use of
IP's 32-bit address space. Classless Inter Domain Routing (CIDR)
[INTERNET:15] is a method currently being deployed in the Internet
backbones to achieve this added efficiency. CIDR depends on
deploying and routing to arbitrarily sized networks. In this model,
hosts and routers make no assumptions about the use of addressing in
the internet. The Class D (IP Multicast) and Class E (Experimental)
address spaces are preserved, although this is primarily an
assignment policy.
By definition, CIDR comprises three elements:
o topologically significant address assignment,
o routing protocols that are capable of aggregating network layer
reachability information, and
o consistent forwarding algorithm ("longest match").
The use of networks and subnets is now historical, although the
language used to describe them remains in current use. They have
been replaced by the more tractable concept of a network prefix. A
network prefix is, by definition, a contiguous set of bits at the
more significant end of the address that defines a set of systems;
host numbers select among those systems. There is no requirement
that all the internet use network prefixes uniformly. To collapse
routing information, it is useful to divide the internet into
addressing domains. Within such a domain, detailed information is
available about constituent networks; outside it, only the common
network prefix is advertised.
The classical IP addressing architecture used addresses and subnet
masks to discriminate the host number from the network prefix. With
network prefixes, it is sufficient to indicate the number of bits in
the prefix. Both representations are in common use. Architecturally
correct subnet masks are capable of being represented using the
prefix length description. They comprise that subset of all possible
bits patterns that have
o a contiguous string of ones at the more significant end,
o a contiguous string of zeros at the less significant end, and
o no intervening bits.
Routers SHOULD always treat a route as a network prefix, and SHOULD
reject configuration and routing information inconsistent with that
model.
IP-address ::= { <Network-prefix>, <Host-number> }
An effect of the use of CIDR is that the set of destinations
associated with address prefixes in the routing table may exhibit
subset relationship. A route describing a smaller set of
destinations (a longer prefix) is said to be more specific than a
route describing a larger set of destinations (a shorter prefix);
similarly, a route describing a larger set of destinations (a shorter
prefix) is said to be less specific than a route describing a smaller
set of destinations (a longer prefix). Routers must use the most
specific matching route (the longest matching network prefix) when
forwarding traffic.
2.2.6 IP Multicasting
IP multicasting is an extension of Link Layer multicast to IP
internets. Using IP multicasts, a single datagram can be addressed
to multiple hosts without sending it to all. In the extended case,
these hosts may reside in different address domains. This collection
of hosts is called a multicast group. Each multicast group is
represented as a Class D IP address. An IP datagram sent to the
group is to be delivered to each group member with the same best-
effort delivery as that provided for unicast IP traffic. The sender
of the datagram does not itself need to be a member of the
destination group.
The semantics of IP multicast group membership are defined in
[INTERNET:4]. That document describes how hosts and routers join and
leave multicast groups. It also defines a protocol, the Internet
Group Management Protocol (IGMP), that monitors IP multicast group
membership.
Forwarding of IP multicast datagrams is accomplished either through
static routing information or via a multicast routing protocol.
Devices that forward IP multicast datagrams are called multicast
routers. They may or may not also forward IP unicasts. Multicast
datagrams are forwarded on the basis of both their source and
destination addresses. Forwarding of IP multicast packets is
described in more detail in Section [5.2.1]. Appendix D discusses
multicast routing protocols.
2.2.7 Unnumbered Lines and Networks Prefixes
Traditionally, each network interface on an IP host or router has its
own IP address. This can cause inefficient use of the scarce IP
address space, since it forces allocation of an IP network prefix to
every point-to-point link.
To solve this problem, a number of people have proposed and
implemented the concept of unnumbered point to point lines. An
unnumbered point to point line does not have any network prefix
associated with it. As a consequence, the network interfaces
connected to an unnumbered point to point line do not have IP
addresses.
Because the IP architecture has traditionally assumed that all
interfaces had IP addresses, these unnumbered interfaces cause some
interesting dilemmas. For example, some IP options (e.g., Record
Route) specify that a router must insert the interface address into
the option, but an unnumbered interface has no IP address. Even more
fundamental (as we shall see in chapter 5) is that routes contain the
IP address of the next hop router. A router expects that this IP
address will be on an IP (sub)net to which the router is connected.
That assumption is of course violated if the only connection is an
unnumbered point to point line.
To get around these difficulties, two schemes have been conceived.
The first scheme says that two routers connected by an unnumbered
point to point line are not really two routers at all, but rather two
half-routers that together make up a single virtual router. The
unnumbered point to point line is essentially considered to be an
internal bus in the virtual router. The two halves of the virtual
router must coordinate their activities in such a way that they act
exactly like a single router.
This scheme fits in well with the IP architecture, but suffers from
two important drawbacks. The first is that, although it handles the
common case of a single unnumbered point to point line, it is not
readily extensible to handle the case of a mesh of routers and
unnumbered point to point lines. The second drawback is that the
interactions between the half routers are necessarily complex and are
not standardized, effectively precluding the connection of equipment
from different vendors using unnumbered point to point lines.
Because of these drawbacks, this memo has adopted an alternate
scheme, which has been invented multiple times but which is probably
originally attributable to Phil Karn. In this scheme, a router that
has unnumbered point to point lines also has a special IP address,
called a router-id in this memo. The router-id is one of the
router's IP addresses (a router is required to have at least one IP
address). This router-id is used as if it is the IP address of all
unnumbered interfaces.
2.2.8 Notable Oddities
2.2.8.1 Embedded Routers
A router may be a stand-alone computer system, dedicated to its IP
router functions. Alternatively, it is possible to embed router
functions within a host operating system that supports connections to
two or more networks. The best-known example of an operating system
with embedded router code is the Berkeley BSD system. The embedded
router feature seems to make building a network easy, but it has a
number of hidden pitfalls:
(1) If a host has only a single constituent-network interface, it
should not act as a router.
For example, hosts with embedded router code that gratuitously
forward broadcast packets or datagrams on the same net often
cause packet avalanches.
(2) If a (multihomed) host acts as a router, it is subject to the
requirements for routers contained in this document.
For example, the routing protocol issues and the router control
and monitoring problems are as hard and important for embedded
routers as for stand-alone routers.
Internet router requirements and specifications may change
independently of operating system changes. An administration
that operates an embedded router in the Internet is strongly
advised to maintain and update the router code. This might
require router source code.
(3) When a host executes embedded router code, it becomes part of the
Internet infrastructure. Thus, errors in software or
configuration can hinder communication between other hosts. As
a consequence, the host administrator must lose some autonomy.
In many circumstances, a host administrator will need to disable
router code embedded in the operating system. For this reason,
it should be straightforward to disable embedded router
functionality.
(4) When a host running embedded router code is concurrently used for
other services, the Operation and Maintenance requirements for
the two modes of use may conflict.
For example, router O&M will in many cases be performed remotely
by an operations center; this may require privileged system
access that the host administrator would not normally want to
distribute.
2.2.8.2 Transparent Routers
There are two basic models for interconnecting local-area networks
and wide-area (or long-haul) networks in the Internet. In the first,
the local-area network is assigned a network prefix and all routers
in the Internet must know how to route to that network. In the
second, the local-area network shares (a small part of) the address
space of the wide-area network. Routers that support this second
model are called address sharing routers or transparent routers. The
focus of this memo is on routers that support the first model, but
this is not intended to exclude the use of transparent routers.
The basic idea of a transparent router is that the hosts on the
local-area network behind such a router share the address space of
the wide-area network in front of the router. In certain situations
this is a very useful approach and the limitations do not present
significant drawbacks.
The words in front and behind indicate one of the limitations of this
approach: this model of interconnection is suitable only for a
geographically (and topologically) limited stub environment. It
requires that there be some form of logical addressing in the network
level addressing of the wide-area network. IP addresses in the local
environment map to a few (usually one) physical address in the wide-
area network. This mapping occurs in a way consistent with the { IP
address <-> network address } mapping used throughout the wide-area
network.
Multihoming is possible on one wide-area network, but may present
routing problems if the interfaces are geographically or
topologically separated. Multihoming on two (or more) wide-area
networks is a problem due to the confusion of addresses.
The behavior that hosts see from other hosts in what is apparently
the same network may differ if the transparent router cannot fully
emulate the normal wide-area network service. For example, the
ARPANET used a Link Layer protocol that provided a Destination Dead
indication in response to an attempt to send to a host that was off-
line. However, if there were a transparent router between the
ARPANET and an Ethernet, a host on the ARPANET would not receive a
Destination Dead indication for Ethernet hosts.
2.3 Router Characteristics
An Internet router performs the following functions:
(1) Conforms to specific Internet protocols specified in this
document, including the Internet Protocol (IP), Internet Control
Message Protocol (ICMP), and others as necessary.
(2) Interfaces to two or more packet networks. For each connected
network the router must implement the functions required by that
network. These functions typically include:
o Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and
checksum),
o Sending and receiving IP datagrams up to the maximum size
supported by that network, this size is the network's Maximum
Transmission Unit or MTU,
o Translating the IP destination address into an appropriate
network-level address for the connected network (e.g., an
Ethernet hardware address), if needed, and
o Responding to network flow control and error indications, if
any.
See chapter 3 (Link Layer).
(3) Receives and forwards Internet datagrams. Important issues in
this process are buffer management, congestion control, and
fairness.
o Recognizes error conditions and generates ICMP error and
information messages as required.
o Drops datagrams whose time-to-live fields have reached zero.
o Fragments datagrams when necessary to fit into the MTU of the
next network.
See chapter 4 (Internet Layer - Protocols) and chapter 5
(Internet Layer - Forwarding) for more information.
(4) Chooses a next-hop destination for each IP datagram, based on the
information in its routing database. See chapter 5 (Internet
Layer - Forwarding) for more information.
(5) (Usually) supports an interior gateway protocol (IGP) to carry
out distributed routing and reachability algorithms with the
other routers in the same autonomous system. In addition, some
routers will need to support an exterior gateway protocol (EGP)
to exchange topological information with other autonomous
systems. See chapter 7 (Application Layer - Routing Protocols)
for more information.
(6) Provides network management and system support facilities,
including loading, debugging, status reporting, exception
reporting and control. See chapter 8 (Application Layer -
Network Management Protocols) and chapter 10 (Operation and
Maintenance) for more information.
A router vendor will have many choices on power, complexity, and
features for a particular router product. It may be helpful to
observe that the Internet system is neither homogeneous nor fully
connected. For reasons of technology and geography it is growing
into a global interconnect system plus a fringe of LANs around the
edge. More and more these fringe LANs are becoming richly
interconnected, thus making them less out on the fringe and more
demanding on router requirements.
o The global interconnect system is composed of a number of wide-area
networks to which are attached routers of several Autonomous
Systems (AS); there are relatively few hosts connected directly to
the system.
o Most hosts are connected to LANs. Many organizations have clusters
of LANs interconnected by local routers. Each such cluster is
connected by routers at one or more points into the global
interconnect system. If it is connected at only one point, a LAN
is known as a stub network.
Routers in the global interconnect system generally require:
o Advanced Routing and Forwarding Algorithms
These routers need routing algorithms that are highly dynamic,
impose minimal processing and communication burdens, and offer
type-of-service routing. Congestion is still not a completely
resolved issue (see Section [5.3.6]). Improvements in these areas
are expected, as the research community is actively working on
these issues.
o High Availability
These routers need to be highly reliable, providing 24 hours a
day, 7 days a week service. Equipment and software faults can
have a wide-spread (sometimes global) effect. In case of failure,
they must recover quickly. In any environment, a router must be
highly robust and able to operate, possibly in a degraded state,
under conditions of extreme congestion or failure of network
resources.
o Advanced O&M Features
Internet routers normally operate in an unattended mode. They
will typically be operated remotely from a centralized monitoring
center. They need to provide sophisticated means for monitoring
and measuring traffic and other events and for diagnosing faults.
o High Performance
Long-haul lines in the Internet today are most frequently full
duplex 56 KBPS, DS1 (1.544 Mbps), or DS3 (45 Mbps) speeds. LANs,
which are half duplex multiaccess media, are typically Ethernet
(10Mbps) and, to a lesser degree, FDDI (100Mbps). However,
network media technology is constantly advancing and higher speeds
are likely in the future.
The requirements for routers used in the LAN fringe (e.g., campus
networks) depend greatly on the demands of the local networks. These
may be high or medium-performance devices, probably competitively
procured from several different vendors and operated by an internal
organization (e.g., a campus computing center). The design of these
routers should emphasize low average latency and good burst
performance, together with delay and type-of-service sensitive
resource management. In this environment there may be less formal
O&M but it will not be less important. The need for the routing
mechanism to be highly dynamic will become more important as networks
become more complex and interconnected. Users will demand more out
of their local connections because of the speed of the global
interconnects.
As networks have grown, and as more networks have become old enough
that they are phasing out older equipment, it has become increasingly
imperative that routers interoperate with routers from other vendors.
Even though the Internet system is not fully interconnected, many
parts of the system need to have redundant connectivity. Rich
connectivity allows reliable service despite failures of
communication lines and routers, and it can also improve service by
shortening Internet paths and by providing additional capacity.
Unfortunately, this richer topology can make it much more difficult
to choose the best path to a particular destination.
2.4 Architectural Assumptions
The current Internet architecture is based on a set of assumptions
about the communication system. The assumptions most relevant to
routers are as follows:
o The Internet is a network of networks.
Each host is directly connected to some particular network(s); its
connection to the Internet is only conceptual. Two hosts on the
same network communicate with each other using the same set of
protocols that they would use to communicate with hosts on distant
networks.
o Routers do not keep connection state information.
To improve the robustness of the communication system, routers are
designed to be stateless, forwarding each IP packet independently
of other packets. As a result, redundant paths can be exploited
to provide robust service in spite of failures of intervening
routers and networks.
All state information required for end-to-end flow control and
reliability is implemented in the hosts, in the transport layer or
in application programs. All connection control information is
thus co-located with the end points of the communication, so it
will be lost only if an end point fails. Routers control message
flow only indirectly, by dropping packets or increasing network
delay.
Note that future protocol developments may well end up putting
some more state into routers. This is especially likely for
multicast routing, resource reservation, and flow based
forwarding.
o Routing complexity should be in the routers.
Routing is a complex and difficult problem, and ought to be
performed by the routers, not the hosts. An important objective
is to insulate host software from changes caused by the inevitable
evolution of the Internet routing architecture.
o The system must tolerate wide network variation.
A basic objective of the Internet design is to tolerate a wide
range of network characteristics - e.g., bandwidth, delay, packet
loss, packet reordering, and maximum packet size. Another
objective is robustness against failure of individual networks,
routers, and hosts, using whatever bandwidth is still available.
Finally, the goal is full open system interconnection: an Internet
router must be able to interoperate robustly and effectively with
any other router or Internet host, across diverse Internet paths.
Sometimes implementors have designed for less ambitious goals.
For example, the LAN environment is typically much more benign
than the Internet as a whole; LANs have low packet loss and delay
and do not reorder packets. Some vendors have fielded
implementations that are adequate for a simple LAN environment,
but work badly for general interoperation. The vendor justifies
such a product as being economical within the restricted LAN
market. However, isolated LANs seldom stay isolated for long.
They are soon connected to each other, to organization-wide
internets, and eventually to the global Internet system. In the
end, neither the customer nor the vendor is served by incomplete
or substandard routers.
The requirements in this document are designed for a full-function
router. It is intended that fully compliant routers will be
usable in almost any part of the Internet.
3. LINK LAYER
Although [INTRO:1] covers Link Layer standards (IP over various link
layers, ARP, etc.), this document anticipates that Link-Layer
material will be covered in a separate Link Layer Requirements
document. A Link-Layer Requirements document would be applicable to
both hosts and routers. Thus, this document will not obsolete the
parts of [INTRO:1] that deal with link-layer issues.
3.1 INTRODUCTION
Routers have essentially the same Link Layer protocol requirements as
other sorts of Internet systems. These requirements are given in
chapter 3 of Requirements for Internet Gateways [INTRO:1]. A router
MUST comply with its requirements and SHOULD comply with its
recommendations. Since some of the material in that document has
become somewhat dated, some additional requirements and explanations
are included below.
DISCUSSION
It is expected that the Internet community will produce a
Requirements for Internet Link Layer standard which will supersede
both this chapter and the chapter entitled "INTERNET LAYER
PROTOCOLS" in [INTRO:1].
3.2 LINK/INTERNET LAYER INTERFACE
This document does not attempt to specify the interface between the
Link Layer and the upper layers. However, note well that other parts
of this document, particularly chapter 5, require various sorts of
information to be passed across this layer boundary.
This section uses the following definitions:
o Source physical address
The source physical address is the Link Layer address of the host
or router from which the packet was received.
o Destination physical address
The destination physical address is the Link Layer address to
which the packet was sent.
The information that must pass from the Link Layer to the
Internetwork Layer for each received packet is:
(1) The IP packet [5.2.2],
(2) The length of the data portion (i.e., not including the Link-
Layer framing) of the Link Layer frame [5.2.2],
(3) The identity of the physical interface from which the IP packet
was received [5.2.3], and
(4) The classification of the packet's destination physical address
as a Link Layer unicast, broadcast, or multicast [4.3.2],
[5.3.4].
In addition, the Link Layer also should provide:
(5) The source physical address.
The information that must pass from the Internetwork Layer to the
Link Layer for each transmitted packet is:
(1) The IP packet [5.2.1]
(2) The length of the IP packet [5.2.1]
(3) The destination physical interface [5.2.1]
(4) The next hop IP address [5.2.1]
In addition, the Internetwork Layer also should provide:
(5) The Link Layer priority value [5.3.3.2]
The Link Layer must also notify the Internetwork Layer if the packet
to be transmitted causes a Link Layer precedence-related error
[5.3.3.3].
3.3 SPECIFIC ISSUES
3.3.1 Trailer Encapsulation
Routers that can connect to ten megabit Ethernets MAY be able to
receive and forward Ethernet packets encapsulated using the trailer
encapsulation described in [LINK:1]. However, a router SHOULD NOT
originate trailer encapsulated packets. A router MUST NOT originate
trailer encapsulated packets without first verifying, using the
mechanism described in [INTRO:2], that the immediate destination of
the packet is willing and able to accept trailer-encapsulated
packets. A router SHOULD NOT agree (using these mechanisms) to
accept trailer-encapsulated packets.
3.3.2 Address Resolution Protocol - ARP
Routers that implement ARP MUST be compliant and SHOULD be
unconditionally compliant with the requirements in [INTRO:2].
The link layer MUST NOT report a Destination Unreachable error to IP
solely because there is no ARP cache entry for a destination; it
SHOULD queue up to a small number of datagrams breifly while
performing the ARP request/reply sequence, and reply that the
destination is unreachable to one of the queued datagrams only when
this proves fruitless.
A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast
address.
3.3.3 Ethernet and 802.3 Coexistence
Routers that can connect to ten megabit Ethernets MUST be compliant
and SHOULD be unconditionally compliant with the Ethernet
requirements of [INTRO:2].
3.3.4 Maximum Transmission Unit - MTU
The MTU of each logical interface MUST be configurable within the
range of legal MTUs for the interface.
Many Link Layer protocols define a maximum frame size that may be
sent. In such cases, a router MUST NOT allow an MTU to be set which
would allow sending of frames larger than those allowed by the Link
Layer protocol. However, a router SHOULD be willing to receive a
packet as large as the maximum frame size even if that is larger than
the MTU.
DISCUSSION
Note that this is a stricter requirement than imposed on hosts by
[INTRO:2], which requires that the MTU of each physical interface
be configurable.
If a network is using an MTU smaller than the maximum frame size
for the Link Layer, a router may receive packets larger than the
MTU from misconfigured and incompletely initialized hosts. The
Robustness Principle indicates that the router should successfully
receive these packets if possible.
3.3.5 Point-to-Point Protocol - PPP
Contrary to [INTRO:1], the Internet does have a standard point to
point line protocol: the Point-to-Point Protocol (PPP), defined in
[LINK:2], [LINK:3], [LINK:4], and [LINK:5].
A point to point interface is any interface that is designed to send
data over a point to point line. Such interfaces include telephone,
leased, dedicated or direct lines (either 2 or 4 wire), and may use
point to point channels or virtual circuits of multiplexed interfaces
such as ISDN. They normally use a standardized modem or bit serial
interface (such as RS-232, RS-449 or V.35), using either synchronous
or asynchronous clocking. Multiplexed interfaces often have special
physical interfaces.
A general purpose serial interface uses the same physical media as a
point to point line, but supports the use of link layer networks as
well as point to point connectivity. Link layer networks (such as
X.25 or Frame Relay) use an alternative IP link layer specification.
Routers that implement point to point or general purpose serial
interfaces MUST IMPLEMENT PPP.
PPP MUST be supported on all general purpose serial interfaces on a
router. The router MAY allow the line to be configured to use point
to point line protocols other than PPP. Point to point interfaces
SHOULD either default to using PPP when enabled or require
configuration of the link layer protocol before being enabled.
General purpose serial interfaces SHOULD require configuration of the
link layer protocol before being enabled.
3.3.5.1 Introduction
This section provides guidelines to router implementors so that they
can ensure interoperability with other routers using PPP over either
synchronous or asynchronous links.
It is critical that an implementor understand the semantics of the
option negotiation mechanism. Options are a means for a local device
to indicate to a remote peer what the local device will accept from
the remote peer, not what it wishes to send. It is up to the remote
peer to decide what is most convenient to send within the confines of
the set of options that the local device has stated that it can
accept. Therefore it is perfectly acceptable and normal for a remote
peer to ACK all the options indicated in an LCP Configuration Request
(CR) even if the remote peer does not support any of those options.
Again, the options are simply a mechanism for either device to
indicate to its peer what it will accept, not necessarily what it
will send.
3.3.5.2 Link Control Protocol (LCP) Options
The PPP Link Control Protocol (LCP) offers a number of options that
may be negotiated. These options include (among others) address and
control field compression, protocol field compression, asynchronous
character map, Maximum Receive Unit (MRU), Link Quality Monitoring
(LQM), magic number (for loopback detection), Password Authentication
Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP),
and the 32-bit Frame Check Sequence (FCS).
A router MAY use address/control field compression on either
synchronous or asynchronous links. A router MAY use protocol field
compression on either synchronous or asynchronous links. A router
that indicates that it can accept these compressions MUST be able to
accept uncompressed PPP header information also.
DISCUSSION
These options control the appearance of the PPP header. Normally
the PPP header consists of the address, the control field, and the
protocol field. The address, on a point to point line, is 0xFF,
indicating "broadcast". The control field is 0x03, indicating
"Unnumbered Information." The Protocol Identifier is a two byte
value indicating the contents of the data area of the frame. If a
system negotiates address and control field compression it
indicates to its peer that it will accept PPP frames that have or
do not have these fields at the front of the header. It does not
indicate that it will be sending frames with these fields removed.
Protocol field compression, when negotiated, indicates that the
system is willing to receive protocol fields compressed to one
byte when this is legal. There is no requirement that the sender
do so.
Use of address/control field compression is inconsistent with the
use of numbered mode (reliable) PPP.
IMPLEMENTATION
Some hardware does not deal well with variable length header
information. In those cases it makes most sense for the remote
peer to send the full PPP header. Implementations may ensure this
by not sending the address/control field and protocol field
compression options to the remote peer. Even if the remote peer
has indicated an ability to receive compressed headers there is no
requirement for the local router to send compressed headers.
A router MUST negotiate the Asynchronous Control Character Map (ACCM)
for asynchronous PPP links, but SHOULD NOT negotiate the ACCM for
synchronous links. If a router receives an attempt to negotiate the
ACCM over a synchronous link, it MUST ACKnowledge the option and then
ignore it.
DISCUSSION
There are implementations that offer both synchronous and
asynchronous modes of operation and may use the same code to
implement the option negotiation. In this situation it is
possible that one end or the other may send the ACCM option on a
synchronous link.
A router SHOULD properly negotiate the maximum receive unit (MRU).
Even if a system negotiates an MRU smaller than 1,500 bytes, it MUST
be able to receive a 1,500 byte frame.
A router SHOULD negotiate and enable the link quality monitoring
(LQM) option.
DISCUSSION
This memo does not specify a policy for deciding whether the
link's quality is adequate. However, it is important (see Section
[3.3.6]) that a router disable failed links.
A router SHOULD implement and negotiate the magic number option for
loopback detection.
A router MAY support the authentication options (PAP - Password
Authentication Protocol, and/or CHAP - Challenge Handshake
Authentication Protocol).
A router MUST support 16-bit CRC frame check sequence (FCS) and MAY
support the 32-bit CRC.
3.3.5.3 IP Control Protocol (IPCP) Options
A router MAY offer to perform IP address negotiation. A router MUST
accept a refusal (REJect) to perform IP address negotiation from the
peer.
Routers operating at link speeds of 19,200 BPS or less SHOULD
implement and offer to perform Van Jacobson header compression.
Routers that implement VJ compression SHOULD implement an
administrative control enabling or disabling it.
3.3.6 Interface Testing
A router MUST have a mechanism to allow routing software to determine
whether a physical interface is available to send packets or not; on
multiplexed interfaces where permanent virtual circuits are opened
for limited sets of neighbors, the router must also be able to
determine whether the virtual circuits are viable. A router SHOULD
have a mechanism to allow routing software to judge the quality of a
physical interface. A router MUST have a mechanism for informing the
routing software when a physical interface becomes available or
unavailable to send packets because of administrative action. A
router MUST have a mechanism for informing the routing software when
it detects a Link level interface has become available or
unavailable, for any reason.
DISCUSSION
It is crucial that routers have workable mechanisms for
determining that their network connections are functioning
properly. Failure to detect link loss, or failure to take the
proper actions when a problem is detected, can lead to black
holes.
The mechanisms available for detecting problems with network
connections vary considerably, depending on the Link Layer
protocols in use and the interface hardware. The intent is to
maximize the capability to detect failures within the Link-Layer
constraints.
4. INTERNET LAYER - PROTOCOLS
4.1 INTRODUCTION
This chapter and chapter 5 discuss the protocols used at the Internet
Layer: IP, ICMP, and IGMP. Since forwarding is obviously a crucial
topic in a document discussing routers, chapter 5 limits itself to
the aspects of the protocols that directly relate to forwarding. The
current chapter contains the remainder of the discussion of the
Internet Layer protocols.
4.2 INTERNET PROTOCOL - IP
4.2.1 INTRODUCTION
Routers MUST implement the IP protocol, as defined by [INTERNET:1].
They MUST also implement its mandatory extensions: subnets (defined
in [INTERNET:2]), IP broadcast (defined in [INTERNET:3]), and
Classless Inter-Domain Routing (CIDR, defined in [INTERNET:15]).
Router implementors need not consider compliance with the section of
[INTRO:2] entitled "Internet Protocol -- IP," as that section is
entirely duplicated or superseded in this document. A router MUST be
compliant, and SHOULD be unconditionally compliant, with the
requirements of the section entitled "SPECIFIC ISSUES" relating to IP
in [INTRO:2].
In the following, the action specified in certain cases is to
silently discard a received datagram. This means that the datagram
will be discarded without further processing and that the router will
not send any ICMP error message (see Section [4.3]) as a result.
However, for diagnosis of problems a router SHOULD provide the
capability of logging the error (see Section [1.3.3]), including the
contents of the silently discarded datagram, and SHOULD count
datagrams discarded.
4.2.2 PROTOCOL WALK-THROUGH
RFC791 [INTERNET:1] is the specification for the Internet Protocol.
4.2.2.1 Options: RFC791 Section 3.2
In datagrams received by the router itself, the IP layer MUST
interpret IP options that it understands and preserve the rest
unchanged for use by higher layer protocols.
Higher layer protocols may require the ability to set IP options in
datagrams they send or examine IP options in datagrams they receive.
Later sections of this document discuss specific IP option support
required by higher layer protocols.
DISCUSSION
Neither this memo nor [INTRO:2] define the order in which a
receiver must process multiple options in the same IP header.
Hosts and routers originating datagrams containing multiple
options must be aware that this introduces an ambiguity in the
meaning of certain options when combined with a source-route
option.
Here are the requirements for specific IP options:
(a) Security Option
Some environments require the Security option in every packet
originated or received. Routers SHOULD IMPLEMENT the revised
security option described in [INTERNET:5].
DISCUSSION
Note that the security options described in [INTERNET:1] and RFC
1038 ([INTERNET:16]) are obsolete.
(b) Stream Identifier Option
This option is obsolete; routers SHOULD NOT place this option
in a datagram that the router originates. This option MUST be
ignored in datagrams received by the router.
(c) Source Route Options
A router MUST be able to act as the final destination of a
source route. If a router receives a packet containing a
completed source route, the packet has reached its final
destination. In such an option, the pointer points beyond the
last field and the destination address in the IP header
addresses the router. The option as received (the recorded
route) MUST be passed up to the transport layer (or to ICMP
message processing).
In the general case, a correct response to a source-routed
datagram traverses the same route. A router MUST provide a
means whereby transport protocols and applications can reverse
the source route in a received datagram. This reversed source
route MUST be inserted into datagrams they originate (see
[INTRO:2] for details) when the router is unaware of policy
constraints. However, if the router is policy aware, it MAY
select another path.
Some applications in the router MAY require that the user be
able to enter a source route.
A router MUST NOT originate a datagram containing multiple
source route options. What a router should do if asked to
forward a packet containing multiple source route options is
described in Section [5.2.4.1].
When a source route option is created (which would happen when
the router is originating a source routed datagram or is
inserting a source route option as a result of a special
filter), it MUST be correctly formed even if it is being
created by reversing a recorded route that erroneously includes
the source host (see case (B) in the discussion below).
DISCUSSION
Suppose a source routed datagram is to be routed from source _S to
destination D via routers G1, G2, Gn. Source S constructs a
datagram with G1's IP address as its destination address, and a
source route option to get the datagram the rest of the way to its
destination. However, there is an ambiguity in the specification
over whether the source route option in a datagram sent out by S
should be (A) or (B):
(A): {>>G2, G3, ... Gn, D} <--- CORRECT
(B): {S, >>G2, G3, ... Gn, D} <---- WRONG
(where >> represents the pointer). If (A) is sent, the datagram
received at D will contain the option: {G1, G2, ... Gn >>}, with S
and D as the IP source and destination addresses. If (B) were
sent, the datagram received at D would again contain S and D as
the same IP source and destination addresses, but the option would
be: {S, G1, ...Gn >>}; i.e., the originating host would be the
first hop in the route.
(d) Record Route Option
Routers MAY support the Record Route option in datagrams
originated by the router.
(e) Timestamp Option
Routers MAY support the timestamp option in datagrams
originated by the router. The following rules apply:
o When originating a datagram containing a Timestamp Option, a
router MUST record a timestamp in the option if
- Its Internet address fields are not pre-specified or
- Its first pre-specified address is the IP address of the
logical interface over which the datagram is being sent
(or the router's router-id if the datagram is being sent
over an unnumbered interface).
o If the router itself receives a datagram containing a
Timestamp Option, the router MUST insert the current time
into the Timestamp Option (if there is space in the option
to do so) before passing the option to the transport layer
or to ICMP for processing. If space is not present, the
router MUST increment the Overflow Count in the option.
o A timestamp value MUST follow the rules defined in [INTRO:2].
IMPLEMENTATION
To maximize the utility of the timestamps contained in the
timestamp option, the timestamp inserted should be, as nearly as
practical, the time at which the packet arrived at the router.
For datagrams originated by the router, the timestamp inserted
should be, as nearly as practical, the time at which the datagram
was passed to the Link Layer for transmission.
The timestamp option permits the use of a non-standard time clock,
but the use of a non-synchronized clock limits the utility of the
time stamp. Therefore, routers are well advised to implement the
Network Time Protocol for the purpose of synchronizing their
clocks.
4.2.2.2 Addresses in Options: RFC791