Considerations and Registry for extending IP route lookup
draft-lamparter-rtgwg-routing-extra-qualifiers-00

Abstract

This document describes the behaviour of a routing system that takes additional specifications on routes--extra qualifiers--into account on a hop-by-hop basis, augmenting longest match behaviour.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 23, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Applicability
• 3. Match criteria (informational)
• 3.1. Virtual routers
• 3.2. Policy routing
• 3.3. Destination address longest match
• 3.4. Source address longest match
• 3.5. Flowlabel routing
• 3.6. QoS/DSCP traffic class based routing
• 4. Requirements to extending match behaviour
• 4.1. Match ordering
• 4.2. Compatibility / Interoperability
• 5. IANA Considerations
• 5.1. Initial list
• 6. Security Considerations
• 7. Privacy Considerations
• 8. Acknowledgements
• 9. Change Log
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Author's Address

1. Introduction

IP Routing systems at the time of creation of this document are occasionally already capable of matching more than the packet's destination addresses to lookup routes, preexisting patterns include virtual routers (i.e. keying by routing instance), QoS-aware routing (keying by DSCP bits) and the relatively unspecific "policy routing."

Additional developments extend this field to the point where a lack of well-defined specification may lead to interoperability problems. The intent of this document is to construct a reference framework for extensions on the match aspect of IP routes.

Specifically, since IP Routing includes longest-match route selection, the ordering of all match qualifiers must be the same among all routers to prevent loops or connectivity loss.

While this document is written with IPv6 in mind, it applies to IP router architecture in general, including IPv4 routers.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Applicability

While the conceptually same longest-prefix routing is used not only for routing packets, but also recursive route/nexthop lookups, multicast reverse path forwarding and unicast reverse path filtering. However, while based on the same base principle, these applications may differ in their requirements. For example, multicast RPF cannot use source address discriminators since no source address is known at the time of lookup.

The intent of this specification is only to provide a basic framework; individual extensions to route match behaviour MUST clarify their respective applicability.

3. Match criteria (informational)

3.1. Virtual routers

While not documented to this extent, an implementation capable of partitioning a physical router into multiple virtual routers is an application that essentially has the virtual router identifier as first key in lookup operations. This may not be implemented as such, for example by keeping tables completely separate, however the end behaviour is the same; lookups are made local to the router instance.

3.2. Policy routing

Equally little specified as virtual routers, policy routing usually applies certain qualifiers (source address, traffic class, firewall markers) prior to destination address match.

3.3. Destination address longest match

The conventional destination IP address longest match is included at this point as it is, barring implementation specific extensions mentioned above, the first qualifier used to match packets against the route table.

3.4. Source address longest match

Currently under development, matching on the source address permits routers to choose the correct (in terms of [RFC2827]) exit in smaller multihomed networks. This is distinct from policy routing in that only few select (usually default) routes would be annotated with source prefixes.

Various aspects of this are described in:

[I-D.troan-homenet-sadr]

[I-D.boutier-homenet-source-specific-routing]

[I-D.sarikaya-6man-sadr-overview]

[I-D.baker-rtgwg-src-dst-routing-use-cases]

[I-D.baker-ipv6-isis-dst-src-routing]

[I-D.baker-ipv6-ospf-dst-src-routing]

[I-D.baker-rtgwg-src-dst-routing-use-cases]

3.5. Flowlabel routing

TBD, described in:

[I-D.baker-ipv6-isis-dst-flowlabel-routing]

[I-D.baker-ipv6-ospf-dst-flowlabel-routing]

3.6. QoS/DSCP traffic class based routing

TBD (deprecated, reference only)

4. Requirements to extending match behaviour

4.1. Match ordering

Adding further criteria to be looked up when forwarding packets on a hop-by-hop basis has the very fundamental requirement that all routers behave the same way in choosing the most specific route when there are multiple eligible routes.

This document disambiguates this situation by recording the order of specificness in a registry. This means that the comparison for "more specific", here indicated by A < B (to mean A is more specific than B), is redefined as concatenation for attributes a, b, c as:

A < B :=    Aa <  Ba
        || (Aa == Ba && Ab <  Bb)
        || (Aa == Ba && Ab == Bb && Ac < Bc )

This transfers to a sample situation (using source address, destination address and flowlabel as qualifiers):

Example route table

          destination             source             flowlabel
route A:  2001:db8::/32
route B:  2001:db8:1234::/48      2001:db8:4567::/48
route C:  2001:db8:1234::/48                         abcde
route D:  2001:db8:1234:5678::/64 2001:db8:4567::/48 abcde
route E:  2001:db8:1234:5678::/64

Showing the different results between "destination, source, flowlabel" ("DSF") and "destination, flowlabel, source" ("DFS") ordering:

Example match results

packet to be routed                                       result
#  destination             source             flowlabel  "DSF" "DFS"
1  2001:db8::1             2001:db8:4567::1   abcde       A     A

2  2001:db8:1234::1        2001:db8:4567::1   abcde       B     C
3  2001:db8:1234::1        2001:db8:4567::1   11111       B     B
4  2001:db8:1234::1        2001:db8:1111::1   abcde       C     C
5  2001:db8:1234::1        2001:db8:1111::1   11111       A     A

6  2001:db8:1234:5678::1   2001:db8:4567::1   abcde       D     D
7  2001:db8:1234:5678::1   2001:db8:4567::1   11111       E     E
8  2001:db8:1234:5678::1   2001:db8:1111::1   abcde       E     E

It should be noted that lookup may not result in usage of the most specific element even for the first attribute (destination in the example). As displayed in #5 above, the route used is the most specific one that satisfies all conditions. If a system cannot "back out" to less specific matches on earlier attributes, this MUST be worked around by installing synthetic routes for these cases.

4.2. Compatibility / Interoperability

Since a router implementing extra match qualifiers can have additional, more specific routes than one that doesn't implement these qualifiers, persistent loops can form between these systems. To prevent this from happening, a simple rule must be followed:

The set of qualifiers used to route a particular packet MUST be a subset of the qualifiers supported by the next hop.

This means in particular that a router using extra qualifier A MUST NOT route packets based on a route that checks this qualifier to a system that doesn't support qualifier A (and hence doesn't understand the route).

There are 3 possible approaches to avoid such a condition:

1. discard the packet (treat as destination unreachable)
2. calculate an alternate topology including only routers that support qualifier A
3. if the lookup returns the same nexthop without using qualifier A, use that result (i.e., the nexthop is known to correctly route the packet)

Above considerations require under all circumstances a knowledge of the next router's capabilities. For routing protocols based on hop-by-hop flooding (RIP [RFC2080], BGP [RFC4271]), knowing the peer's capabilities - or simply relying on systems to only flood what they understand - is sufficient. Protocols building a link-state database (OSPF [RFC5340], IS-IS [RFC5308]) have the additional opportunity to calculate alternate paths based on knowledge of the entire domain, but cannot rely on routers flooding only link state they support themselves.

5. IANA Considerations

This document requests creation of a new registry called the "Routing Qualifier Registry." The registry consists of an ordered list of items, no identifier value needs to be assigned. The only purpose of the registry is to document the order in which qualifiers are evaluated.

Registry items must specify the following information:

• Name of the qualifier
• Applicable protocols (IP version 4 and/or IP version 6)
• Specification reference (possibly distinct between IPv4 and IPv6)
• Insertion position, listing both the previous and next entry to avoid confusion

The allocation policy per [RFC5226] is "IETF Review." This is intended to help keep routing systems compatible with each other.

5.1. Initial list

The list is prepropagated with a single entry describing "classical" destination-based routing:

Name: Destination lookup

Applicable to IPv4 and IPv6

Specification references: [RFC4632] for IPv4, [RFC2460] for IPv6

6. Security Considerations

This document specifies only the ordering of lookups. Making no change to the existing situation, there are no security considerations for this document.

7. Privacy Considerations

As with security considerations, no privacy considerations apply to this document.

Introducing additional routing qualifiers has the potential to expose information that was not previously visible, in particular if such information would otherwise be scrubbed by a process like NAT. However, these considerations are left for documents actually introducing new routing qualifiers.

8. Acknowledgements

This document is largely the result of discussions with Fred Baker.

A lot of drafts exists in this general area, refer to the informative references section below.

9. Change Log

Initial Version:

October 2014

10. References

10.1. Normative References

10.2. Informative References

Author's Address