From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1668.txt | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc1668.txt (limited to 'doc/rfc/rfc1668.txt') diff --git a/doc/rfc/rfc1668.txt b/doc/rfc/rfc1668.txt new file mode 100644 index 0000000..0c9668e --- /dev/null +++ b/doc/rfc/rfc1668.txt @@ -0,0 +1,171 @@ + + + + + + +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 + + + +Estrin, Li & Rekhter [Page 1] + +RFC 1668 Unified Routing Requirements for IPng August 1994 + + + 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. + + + +Estrin, Li & Rekhter [Page 2] + +RFC 1668 Unified Routing Requirements for IPng August 1994 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + +Estrin, Li & Rekhter [Page 3] + -- cgit v1.2.3