Movatterモバイル変換

Network Working Group                                          D. EstrinRequest for Comments: 1668                                           USCCategory: Informational                                            T. Li                                                           Cisco Systems                                                              Y. Rekhter                                  T.J. Watson Research Center, IBM Corp.                                                             August 1994Unified Routing Requirements for IPngStatus 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 toRFC1550.  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 inRFC1322.   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 hierarchicalEstrin, 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 1994Authors' 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.comEstrin, Li & Rekhter                                            [Page 3]