RFC 1668

RFC 1668: Unified Routing Requirements for IPng 🎀

Okay bestie, let's start with the basics 💅 This is RFC 1668, called Unified Routing Requirements for IPng. Deborah Estrin (USC), Tony Li (Cisco Systems), and Yakov Rekhter (T.J. Watson Research Center, IBM Corp.) wrote it 👑 It's from the Network Working Group, the category is Informational, and the date is August 1994 📅 The title block doesn't list anything it obsoletes or updates, so no drama there ✨

Status of this Memo 🫶

This memo gives information to the Internet community 🌸 It does not specify an Internet standard of any kind, so it's not a standard, bestie. Distribution of this memo is unlimited 🌈

Abstract 🦋

So this doc was submitted to the IETF IPng area as a reply to RFC 1550 💖 Publishing it doesn't mean the IPng area accepted any of the ideas inside, ngl 🙈 If you want to share comments, send them to the big-internet@munnari.oz.au mailing list 📬

1. IPng Requirements ✨

Here's the IPng wishlist from the perspective of the Unified Routing Architecture (the one described in RFC 1322) 🧚 Six things, periodt:

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. The 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 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 🙈

Okay, the big dramatic moment: security issues are not discussed in this memo. Full stop, no cap 💀

Authors' Addresses 💌

Here are the three legends behind this one 🧚

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