RFC 1668 (rfc1668) - Page 2 of 3
Unified Routing Requirements for IPng
Alternative Format: Original Text Document
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