Unified Routing Requirements for IPng
What the next Internet design must support for scalable routing
Estrin, D., Li, T., and Y. Rekhter, "Unified Routing Requirements for IPng", RFC 1668, DOI 10.17487/RFC1668, August 1994, <https://www.rfc-editor.org/info/rfc1668>.
@misc{rfc1668,
series = {Request for Comments},
number = 1668,
howpublished = {RFC 1668},
publisher = {RFC Editor},
doi = {10.17487/RFC1668},
url = {https://www.rfc-editor.org/info/rfc1668},
author = {D. Estrin and T. Li and Y. Rekhter},
title = {{Unified Routing Requirements for IPng}},
pagetotal = 3,
year = 1994,
month = aug,
} RFC text
Contents
Network Working Group D. Estrin
Request for Comments: 1668 USC
Category: Informational T. Li
Cisco Systems
Y. Rekhter
T.J. Watson Research Center, IBM Corp.
August 1994
Unified Routing Requirements for IPng
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet@munnari.oz.au mailing list.
1. IPng Requirements
The following list provides requirements on the IPng from the
perspective of the Unified Routing Architecture, as describe in RFC
1322.
1. To provide scalable routing, IPng addressing must provide support
for topologically significant address assignment.
2. Since it is hard to predict how routing information will be
aggregated, the IPng addressing structure should impose as few
preconditions as possible on the number of levels in the hierarchy.
Specifically, the number of levels must be allowed to be different
at different parts in the hierarchy. Further, the levels must not
be statically tied to particular parts (fields) in the addressing
information.
3. Hop-by-hop forwarding algorithm requires IPng to carry enough
information in the Network Layer header to unambiguously determine
a particular next hop. Unless mechanisms to compute
context-sensitive forwarding tables and provide consistent
forwarding are defined, the requirement assumes the presence of
full hierarchical addresses. Therefore, IPng packet format must
provide efficient determination of the full hierarchical
destination address.
4. Hierarchical address assignment should not imply strictly
hierarchical routing. Therefore, IPng should carry enough
information to provide forwarding along both hierarchical and
non-hierarchical routes.
5. The IPng packet header should accommodate a "routing label" or
"route ID". This label will be used to identify a particular FIB
to be used for packet forwarding by each router.
Two types of routing labels should be supported: "strong" and
"weak".
When a packet carries a "strong" routing label and a router does
not have a FIB with this label, the packet is discarded (and an
error message is sent back to the source).
When a packet carries a "weak" routing label and a router does not
have a FIB with this label, the packet should be forwarded via a
"default" FIB, i.e., according to the destination address. In
addition, the packet should carry an indication that somewhere
along the path the desired routing label was unavailable.
6. IPng should provide a source routing mechanism with the following
capabilities (i.e., flexibility):
- Specification of either individual routers or collections of
routers as the entities in the source route.
- The option to indicate that two consecutive entities in a
source route must share a common subnet in order for the
source route to be valid.
- Specification of the default behavior when the route to
the next entry in the source route is unavailable:
- The packet is discarded, or
- The source route is ignored and the packet is forwarded based
only on the destination address (and the packet header will
indicate this action).
- A mechanism to verify the feasibility of a source route.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Deborah Estrin
University of Southern California
Computer Science Department, MC 0782
Los Angeles, California 90089-0782
Phone: (310) 740-4524
EMail: estrin@usc.edu
Tony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
EMail: tli@cisco.com
Yakov Rekhter
T.J. Watson Research Center IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.com
AI ELI5
On this page
§1Requirements for Scalable Routing
This RFC responds to a call for criteria for the next Internet Protocol (IPng) with requirements from the Unified Routing Architecture perspective. As IPv4 addresses become scarce and the Internet grows, the routing system must support much larger scales while remaining efficient.
Six core requirements are presented, each addressing a different aspect of routing scalability: how addresses should be structured, how routing information should be organized, how packets should carry routing information, and how the system should handle special cases like source-specified routes.
As the Internet grows bigger, routers need smarter ways to find where to send packets. Here are six important rules the new design should follow.
§2The Six Key Requirements
Requirement 1: IPng addressing must support topologically significant address assignment, enabling scalable routing based on address structure.
Requirement 2: Addressing must not impose fixed levels of hierarchy. Different parts of the network topology may need different numbers of hierarchy levels, and these levels must not be statically tied to address fields.
Requirement 3: Hop-by-hop forwarding requires the packet header to carry enough information to determine the next hop unambiguously. Unless context-sensitive forwarding is defined, the header must include the full hierarchical destination address.
Requirement 4: Hierarchical addressing should not mandate strictly hierarchical routing. The system must support both hierarchical and non-hierarchical (policy-based) routes.
Requirement 5: Packets should carry a "routing label" or "route ID" to identify which Forwarding Information Base (FIB) to use. Two types should be supported: "strong" labels (packet is discarded if the label is not found) and "weak" labels (fallback to default FIB based on destination address).
Requirement 6: Source routing must support individual routers or groups of routers, subnet constraints, flexible default behavior when routes fail, and mechanisms to verify route feasibility.
The address must match the network shape, routers need enough information in each packet, and there must be ways to override normal routing when needed.
§3Context and Impact
This RFC was submitted to the IETF IPng area in response to RFC 1550, which called for various criteria and white papers on IPng proposals. The publication here does not imply the IPng area's acceptance of all ideas, but rather documents one architecture's perspective on what IPng must support.
The requirements reflect the thinking of researchers from USC, Cisco Systems, and IBM's Watson Research Center as the Internet engineering community debated how to replace IPv4 while meeting diverse routing needs.
This is one expert team's opinion on what IPng needs, sent to the people deciding on the next Internet design.