doc: Add RFC documents

1 files changed, 171 insertions, 0 deletions

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]
+