The RFC Archive
 The RFC Archive   RFC 1668   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1668

Unified Routing Requirements for IPng

Last modified on Friday, August 5th, 1994

Permanent link to RFC 1668
Search GitHub Wiki for RFC 1668
Show other RFCs mentioning RFC 1668







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 top


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 top

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 top

Unified Routing Requirements for IPng RFC TOTAL SIZE: 5106 bytes PUBLICATION DATE: Friday, August 5th, 1994 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1668: The IETF Trust, Friday, August 5th, 1994
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement