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 [email protected] 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: [email protected]


  Tony Li
  cisco Systems, Inc.
  1525 O'Brien Drive
  Menlo Park, CA 94025

  EMail: [email protected]


  Yakov Rekhter
  T.J. Watson Research Center IBM Corporation
  P.O. Box 218
  Yorktown Heights, NY 10598

  Phone:  (914) 945-3896
  EMail:  [email protected]

























Estrin, Li & Rekhter                                            [Page 3]