Address Selection Using Source Address Specific Routing Tables
draft-axu-addr-sel-pre00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 17, 2009.

Abstract

RFC 3484 has several shortcomings as specified in RFC 5220 and more_references_here for example. RFC 5221 lists some requirements for any attempts to update the original RFC. This document tries to fulfill them.

$Id: draft-axu-addr-sel-pre00.html,v 1.1 2009-06-15 02:14:26 ams Exp $

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Filter Algorithm
    2.1.  Link Local Scope
    2.2.  Autoconfiguration
    2.3.  Site Local Scope
    2.4.  Additional Filter Constraints
    2.5.  Forwarding
    2.6.  Dynamic Routing Protocols
    2.7.  Interaction with MPLS?
3.  Precedences and Labels
4.  RFC5221 Requirements
    4.1.  Effectiveness
        4.1.1.  Multiple Routers on a Single Interface
        4.1.2.  Ingress Filtering Problem
        4.1.3.  Half-Closed Network Problem
        4.1.4.  Combined Use of Global and ULA
        4.1.5.  Site Renumbering
        4.1.6.  Multicast Source Address Selection
        4.1.7.  Temporary Address Selection
        4.1.8.  IPv4 or IPv6 Prioritization
        4.1.9.  ULA and IPv4 Dual-Stack Environment
        4.1.10.  ULA or Global Prioritization
    4.2.  Timing
    4.3.  Dynamic Behavior Update
    4.4.  Node-Specific Behavior
    4.5.  Application-Specific Behavior
    4.6.  Multiple Interface
    4.7.  Central Control
    4.8.  Next-Hop Selection
    4.9.  Compatibility with RFC 3493
    4.10.  Compatibility and Interoperability with RFC 3484
    4.11.  Security
5.  Implementation Issues and Other Concerns
    5.1.  Low Memory and Power Concerns
    5.2.  Differing Larger Scopes
    5.3.  Connection Pooling
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
    8.1.  RFC5220 Considerations
    8.2.  RFC5221 Requirements
        8.2.1.  List of threats introduced by new address-selection mechanism
        8.2.2.  List of recommendations in which security mechanism should be applied
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Routing Table Example
    A.1.  Before
    A.2.  After Conversion
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

[RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.) defines default address selection rules for IPv6 and IPv4. Several shortcomings in the original address selection rules have been identified in [RFC5220] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules,” July 2008.) and its sister document [RFC5221] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Requirements for Address Selection Mechanisms,” July 2008.) specifies some requirements for any attempts to update the original address selection algorithm.

A further concern comes from multipath protocols. When SCTP (Stone, J., Stewart, R., and D. Otis, “Stream Control Transmission Protocol (SCTP) Checksum Change,” September 2002.) [RFC3309], for example, finds that its active source destination address pair is no longer functional, it will need to start searching for a new one.

The hosts may both have a dozen addresses so it might take unacceptably long to iterate through all combinations before finding a functional pair. On the other hand, many of the invalid combinations could be filtered out using this algorithm, making the process noticeably faster.

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Filter Algorithm

Addresses that the host has SHOULD have routing tables attached. When selecting source and destination addresses, the first stage is to filter out combinations where the routing table attached with the source address does not have a valid route for the destination address. In other words, if a destination address can't be found from the routing table for a given source address the system MUST discard that destination address for that source address.

If none of the possible destination addresses can be found in the routing table for a source address, then that source address MUST be discarded for those destination addresses.

2.1.  Link Local Scope

The routing table associated with a link local address (e.g. 169.254.123.45%le0) SHOULD only have one route, the link local network for that link (e.g. 169.254.0.0/16 %le0).

2.2.  Autoconfiguration

When addresses are assigned to interfaces dynamically through stateless or stateful autoconfiguration the process usually also yields a default route. That default route SHOULD be placed only into the routing table associated with that address.

This usually means that the next hop of that default route will only be useable with the source address learned from that default router.

DHCP can be used to communicate other routes in addition to the default route. Those routes SHOULD likewise be added only into the routing table associated with the address configured using that same DHCP interchange.

2.3.  Site Local Scope

The routing tables for site local addresses SHOULD have routes for site local address space. They SHOULD NOT have the default route, so that they would be automatically eliminated when selecting address pairs for site external communication.

2.4.  Additional Filter Constraints

The address selection algorithm MAY also be given additional filter constraints, such as "use only link#3" or "do not use next-hop 10.0.0.1". This feature requires more elaboration.

2.5.  Forwarding

If a host is forwarding packets between networks, it SHOULD combine the routing tables for the networks in question into one. Link local scope tables MUST NOT be combined.

If the host has multiple addresses from different global scope prefixes then system administration MAY specify which addresses are combined to form routing tables. The resulting functionality resembles the VRF functionality found in some modern routers.

2.6.  Dynamic Routing Protocols

Dynamic routing protocol instances are usually bound to links or interfaces. With this algorithm network administrators MAY bind routing protocol instances to specific addresses or prefixes on a link. The routing protocol instance MUST update only the routing table it is associated with.

A reasonable default setting is that all addresses that are not link local are associated with the routing protocol instance. Thus, they will share a routing table.

If the network administration wants to separate traffic belonging to different upstream operator prefixes, it may wish to run separate routing protocol instances throughout the network for different prefixes.

2.7.  Interaction with MPLS?

Should there be some?

3.  Precedences and Labels

TBD

My original thought was to follow the metrics systems of the original RFC here, since candidate filtering and proper next hop selection were my primary concerns. However, it might be a good idea to just rethink the issue one more time.

Perhaps it might be a good idea to associate preferences with individual routes and/or whole routing tables. In that case, the routing table lookup performed in the filtering phase would also yield the precedence of the address in addition to next-hop information.

The label abstraction used by the original RFC loosely corresponds to the routing table abstraction in this algorithm. That is, different scopes had different labels in [RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.) but in this algorithm different scopes SHOULD have their own routing tables.

4.  RFC5221 Requirements

[RFC5221] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Requirements for Address Selection Mechanisms,” July 2008.) defines a set of requirements for the address selection algorithm. The subsection headings used in that document have been copied here and an explanation of how this algorithm deals with each issue is given.

4.1.  Effectiveness

This section is subdivided into sections addressing issues presented in [RFC5220] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules,” July 2008.).

4.1.1.  Multiple Routers on a Single Interface

This problem was one of the starting points for the development of this algorithm. This algorithm solves the problem by having separate routing tables for addresses learned from different routers.

4.1.2.  Ingress Filtering Problem

This problem was one of the starting points for the development of this algorithm. This algorithm solves the problem by having separate routing tables for different addresses.

4.1.3.  Half-Closed Network Problem

This problem was one of the starting points for the development of this algorithm. This algorithm solves the problem by having separate routing tables for different addresses.

System or network administration MUST specify allowed or disallowed connections by modifying the routing tables.

4.1.4.  Combined Use of Global and ULA

This algorithm solves the problem by having separate routing tables for different addresses.

Implementations MAY recognize ULA addresses and other site local addresses as scopes of their own, and treat them properly when autogenerating the routing tables.

System or network administration MUST specify allowed or disallowed address pair selection by modifying the routing tables.

4.1.5.  Site Renumbering

TBD

4.1.6.  Multicast Source Address Selection

TBD

4.1.7.  Temporary Address Selection

TBD

Conceivably temporary addresses could be associated with routing tables of their own, instead of sharing routing tables with the addresses used to generate the temporary addresses.

4.1.8.  IPv4 or IPv6 Prioritization

TBD

Connection pooling, as specified in Section 5.3 (Connection Pooling), could mitigate this problem.

4.1.9.  ULA and IPv4 Dual-Stack Environment

TBD

4.1.10.  ULA or Global Prioritization

Already covered in Section 4.1.4 (Combined Use of Global and ULA).

4.2.  Timing

TBD

4.3.  Dynamic Behavior Update

From the point of view of this algorithm, this problem is a feature of autoconfiguration methods. If the autoconfiguration methods rewrite routing tables, the address selection algorithm will use updated information when it's invoked.

4.4.  Node-Specific Behavior

These challenges are met well by this algorithm.

4.5.  Application-Specific Behavior

TBD

Additional filter constraints from Section 2.4 (Additional Filter Constraints) can be used to influence address selection per application.

4.6.  Multiple Interface

This algorithm doesn't differenciate between cases where a host has multiple interfaces and where it has multiple prefixes on a single interface. If it solves a problem satisfactorily for one case, it solves it identically for the other case as well.

4.7.  Central Control

TBD

4.8.  Next-Hop Selection

The next-hop and interface used is a side product of the source address specific routing table lookup, which is performed in the filtering stage.

A very pleasing feature of this algorithm is that there can be multiple routers advertising different prefixes on the same subnet, and this algorithm will still select proper address pairs and next-hops to satisfy any SAVI requirements.

4.9.  Compatibility with RFC 3493

This might require some more thinking.

On first impression, this algorithm shouldn't have any impact on the Socket API. Then again, routing table index could be referenced as part of some process.

Solaris, for example, creates new alias-interfaces for each new address assigned to a physical interface. So if_index could also be used to uniquely identify a source address specific routing table on that platform. Other operating systems do not work the same way.

4.10.  Compatibility and Interoperability with RFC 3484

When a host implementing this address selection algorithm and a host implementing the [RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.) algorithm interact, this algorithm will become constrained by the choices made by the peer.

4.11.  Security

Security issues raised in [RFC5221] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Requirements for Address Selection Mechanisms,” July 2008.) are covered by Section 8.2 (RFC5221 Requirements).

5.  Implementation Issues and Other Concerns

Some popular operating systems already implement all the features required to implement this algorithm. In such cases all that is required is to integrate the features together.

The trickiest feature required by this algorithm is probably support for multiple routing tables. This may also create backward compatibility issues in some implementations. More discussion may be required here.

5.1.  Low Memory and Power Concerns

The biggest worry is that creating lots of routing tables will waste memory and power. However, when compared to the old way (see Appendix A (Routing Table Example)), memory consumption doesn't explode. Every route that was present in the monolithic routing table will usually be present in only one source address specific routing table.

CGAs (ADD XREF) MAY reuse the same routing table.

5.2.  Differing Larger Scopes

The default route for global scope addresses is 0::0/0, but this route will also cover addresses of potentially incompatible scopes. For example, the basic algorithm would accept a link local destination address with a global scope source address.

One way to prevent this would be to add blackhole routes into the routing tables of global scope addresses for address space belonging to incompatible scopes. The filter algorithm SHOULD treat a blackhole route as an indication that no valid route was found for addresses matching the blackhole in that table.

5.3.  Connection Pooling

When trying to establish a new connection, the stack MAY send open packets to all source/destination/nexthop combinations that pass the filter stage at a pace of three per second until it receives a response.

When the connection is established the addresses are fixed (for non-multipathing protocols, such as TCP).

If the peer also responds to the other connection attempts, those connections MAY either be reset immediately, or the stack MAY pool them for a short while in an incomplete handshake state, in case some application tries to open an identical socket.

This would benefit applications such as web browsers, mail transfer agents and database clients, which routinely result in more than one connection between the same two hosts and the same destination port.

6.  Acknowledgements

This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project.

7.  IANA Considerations

This memo includes no request to IANA.

All drafts are required to have an IANA considerations section (see the update of RFC 2434 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.) [I‑D.narten‑iana‑considerations‑rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

8.  Security Considerations

All drafts are required to have a security considerations section. See RFC 3552 (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552] for a guide. This reference may be removed once this section is complete?

8.1.  RFC5220 Considerations

Section 4 of [RFC5220] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules,” July 2008.) raises a concern that a malicious attacker can gather information about addresses connected to the target host by triggering the address selection algorithm on the target host by various methods and listening to what candidates it produces.

This algorithm doesn't completely remove that possibility, but due to the filtering stage, the attacker can only gain information on addresses routable to the address used by the attacker.

8.2.  RFC5221 Requirements

Section 3 of [RFC5221] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Requirements for Address Selection Mechanisms,” July 2008.) lists two security concerns which are dealt with in subsections below.

8.2.1.  List of threats introduced by new address-selection mechanism

This specification relies on existing autoconfiguration methods and routing protocols to distribute address selection hints. Each of those SHOULD have their own methods to combat leakage hijacking and denial of service.

8.2.2.  List of recommendations in which security mechanism should be applied

This specification relies on existing autoconfiguration methods and routing protocols to distribute address selection hints. Each of those SHOULD have their own methods to combat leakage hijacking and denial of service.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Routing Table Example

This section demonstrates how this algorithm affects the routing table of a multi-homed host. Appendix A.1 (Before) shows the routing table using only methods without this algorithm. Appendix A.2 (After Conversion) shows the routing tables produced on the same host if this algorithm is applied.

A.1.  Before

TBD

A.2.  After Conversion

TBD

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2009).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.