RFC 1668 (rfc1668) - Page 2 of 3

Unified Routing Requirements for IPng

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