Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces
draft-sun-mif-route-config-dhcp6-03

Abstract

Currently, more and more hosts have multiple interfaces such as GPRS, WiFi etc. One key issue is how to make the applications on the host access the network accordingly through the proper interfaces. The approach presented in this document is to define new DHCPv6 option to configure route tables of the hosts. In this way, the hosts can select a appropriate route.

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 January 28, 2011.

Copyright Notice

Copyright (c) 2010 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.  Requirements Notation
2.  Introduction
    2.1.  Background
    2.2.  Scenario Descriptions
3.  Route Information Option Format
4.  Route Information Option Format Usage
    4.1.  DHCPv6 Client Behavior
    4.2.  DHCPv6 Server Behavior
5.  Implementation Considerations
    5.1.  Conflict of Route Rules
    5.2.  Not Limited to DHCPv6 Servers
6.  IANA Considerations
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Requirements Notation

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

2.  Introduction

2.1.  Background

A host such as a laptop or a smart-phone may have multiple interfaces for connections, e.g., a wired Ethernet LAN, a 802.11 LAN, a 3G cellular network, one or multiple VPNs or tunnels. In view of more and more versatile applications, users may expect a host to utilize several interfaces simultaneously. Issues in such scenarios are summarized in [I‑D.blanchet‑mif‑problem‑statement] (Blanchet, M. and P. Seite, “Multiple Interfaces Problem Statement,” July 2010.) .

An application uses certain interface through select the corresponding source IP address. if the application does not specify it, the transport layer must ask the IP layer. According to [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) all the packets whose destination IP addresses are not specified in the route table will be sent to the default gateway for forwarding. Accordingly, the IP address corresponding to the default gateway will be chosen as the source IP address.

To avoid all packets passing through the same interface corresponding to the default gateway, the approach proposed in this document configures certain routes in route tables of the host. The configuration information is obtained through defining a new DHCPv6 option based on [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.).

An optional extension to Router Advertisement messages is described in [RFC4191] (Draves, R. and D. Thaler, “Default Router Preferences and More-Specific Routes,” November 2005.) for communicating default router preferences and more-specific routes from routers to hosts. To address multi-homed problems in a flexible way, [I‑D.hui‑mif‑dhcpv4‑routing‑03] (Hui, M. and H. Deng, “Extension of DHCPv4 for policy routing of multiple interfaces terminal,” March 2010.) through introducing TOS and specific routes into DHCPv4 options. This document considers the situations for IPv6 cases.

2.2.  Scenario Descriptions

The scenario addressed by the approach proposed in this document is illustrated in Figure 1 (The MIF host scenario). In the figure, the MIF host have three interfaces connected to the access network Ethernet, WiFi and 3G respectively.

                    +---------+
                    |   3G    |
                    +---------+
                         |
                      I3 |
                         ^
                         |
+-----------+   I1   +--------+   I2   +-----------+
| Ethernet  |<------>|MIF Host|<------>|   WiFi    |
+-----------+        +--------+        +-----------+

The procedures that an application employs an interface for network access are depicted in Figure 2 (The procedures of updating a routing table and select an interface for an application) as steps a1) to a4).

a1)

An application calls sockets to build IP packets.

a2)

The socket selects source address based on the routing table.

a3)

The socket sends packets to the corresponding interface.

a4)

The interface will forward the packets to the next hop (the corresponding gateway).

                +---------+   b4     +-------+
                |Interface|--------->|Network|
                +---------+          +-------+
                      |
                   b3 |
                      ^
                      |
+-----------+ b1  +------+       +-----------+
|Application|---->|Socket|<------|Route Table|
+-----------+     +------+  b2   +-----------+

Notice that the approach proposed in this document is feasible under the strong ES model as defined in [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.).

3.  Route Information Option Format

The DHCPv6 option is extended to contain multiple pieces of route information. Each piece of route information contains TOS, metric, destination IP address and the next hop IP address. The ROUTE_INFO option is depicted in Figure 3 (The Route Information Option).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     OPTION_ROUTE_INFO         |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Pref. 1   |     TOS 1     |       Metric 1                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-
| Dest.Pref.Len |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
|                        Dest.Pref.                             |
|                                                               |
|               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                        Next Hop Pref.                         |
|                                                               |
|                                                               |
|               -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |
|               |                                               .
+-+-+-+-+-+-+-+-+                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Pref. N   |     TOS N     |       Metric N                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-
| Dest.Pref.Len |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
|                        Dest.Pref.                             |
|                                                               |
|               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                        Next Hop Pref.                         |
|                                                               |
|                                                               |
|               -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |
|               |
+-+-+-+-+-+-+-+-+

option-code:OPTION_ROUTE_INFO (should be defined by IANA).

option-len: length of the route rule field in octets.

Pref.N: An integer to indicate the priority of applying the Nth route rule. The Preference identified the priority of a rule. if there are conflictions, e.g., two rules have the same "Dest. Add. Pref." but different "Next Hop IPv6 Address", the rule with high preference SHOULD be applied by the host.

TOS N: The Nth TOS (Type-of-Service, 8 bits).

Metric N:The Nth route metric, an 16-bit unsigned integer ranging from 1 to 9999.

Dest.Pref.Len: Length of the IPv6 destination subnet prefix, an 8-bit unsigned integer ranging from 0 to 128.

Dest.Pref.: The IPv6 destination address prefix

Next Hop Pref.: A 128-bit IPv6 prefix that will be used as the next hop when forwarding packets.

In the above, the “Preference” of one route rule comes before the “metric.” Namely, if there are conflict routes for one destination, the one with highest preference value should be used. For example, the network administrator may prefer one route in a connection for security or reliability considerations, even though the metric of the route is large.

4.  Route Information Option Format Usage

4.1.  DHCPv6 Client Behavior

The MIF host(DHCPv6 client) supports Route Information extension, SHOULD send Option Request Option that includes OPTION_ROUTE_INFO to indicate that Route Information Option is requested. The Route Information option MUST NOT appear in any messages other than the following ones : Solicit, Request, Renew, Rebind, Information-Request.

If the MIF host receives no route information, it MAY try another server or retransmit the ORO message. In this situation, the host MUST limit the rate of the retransmition.

4.2.  DHCPv6 Server Behavior

The DHCPv6 server MUST NOT send Route Option in messages other than ADVERTISE or REPLY.

The maximum number of routing information in one DHCPv6 message depend on the maximum DHCPv6 message size defined in [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.).

5.  Implementation Considerations

5.1.  Conflict of Route Rules

The host can use such information obtained from the DHCPv6 message to build a "connection manager" on the host or to update the "Policy Table" defined in [RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.). For the situations where a route option conflicts with one previous route rules, the latter one will override the previous rule.

5.2.  Not Limited to DHCPv6 Servers

The solution presented in this document is with the context of DHCPv6 message. It should be pointed out that similar message may not be conveyed by certain node in the network instead of a DHCPv6 server. Such a node, for example in mobile network, may be the "ANDSF (Access Network Discovery and Selection function)" defined in TS 23.402.

6.  IANA Considerations

The option code of OPTION_ROUTE_INFO will be defined by IANA.

7.  Security Considerations

The interface selection is affected by the routing and address selection rules sent from servers. Therefore, incorrect information received by hosts will cause improper interface selection leading to bad user experiences. Attacks such as deny of services (DoS) or man-in-the-middle may redirect host’s solicitation, change the information or flood the host with invalidate messages. Approaches to guarantee the communication securities between hosts and servers should be applied based on the network access types of the interfaces.

DHCP authentication option [RFC3118] (Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” June 2001.) MAY be used for security.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses