One document matched: draft-sun-mif-route-config-dhcp6-03.txt
Differences from draft-sun-mif-route-config-dhcp6-02.txt
MIF Working Group T. Sun
Internet-Draft H. Deng
Intended status: Standards Track D. Liu
Expires: January 28, 2011 China Mobile
July 27, 2010
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
Sun, et al. Expires January 28, 2011 [Page 1]
Internet-Draft Route Configuration by DHCPv6 July 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Scenario Descriptions . . . . . . . . . . . . . . . . . . 4
3. Route Information Option Format . . . . . . . . . . . . . . . 6
4. Route Information Option Format Usage . . . . . . . . . . . . 8
4.1. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . 8
4.2. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . 8
5. Implementation Considerations . . . . . . . . . . . . . . . . 9
5.1. Conflict of Route Rules . . . . . . . . . . . . . . . . . 9
5.2. Not Limited to DHCPv6 Servers . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Sun, et al. Expires January 28, 2011 [Page 2]
Internet-Draft Route Configuration by DHCPv6 July 2010
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].
Sun, et al. Expires January 28, 2011 [Page 3]
Internet-Draft Route Configuration by DHCPv6 July 2010
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] .
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] 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].
An optional extension to Router Advertisement messages is described
in [RFC4191] 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] 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. In the figure, the MIF host have three
interfaces connected to the access network Ethernet, WiFi and 3G
respectively.
Sun, et al. Expires January 28, 2011 [Page 4]
Internet-Draft Route Configuration by DHCPv6 July 2010
+---------+
| 3G |
+---------+
|
I3 |
^
|
+-----------+ I1 +--------+ I2 +-----------+
| Ethernet |<------>|MIF Host|<------>| WiFi |
+-----------+ +--------+ +-----------+
Figure 1: The MIF host scenario
The procedures that an application employs an interface for network
access are depicted in Figure 2 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 +-----------+
Figure 2: The procedures of updating a routing table and select an
interface for an application
Notice that the approach proposed in this document is feasible under
the strong ES model as defined in [RFC1122].
Sun, et al. Expires January 28, 2011 [Page 5]
Internet-Draft Route Configuration by DHCPv6 July 2010
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.
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. |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |
| |
+-+-+-+-+-+-+-+-+
Sun, et al. Expires January 28, 2011 [Page 6]
Internet-Draft Route Configuration by DHCPv6 July 2010
Figure 3: The Route Information Option
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.
Sun, et al. Expires January 28, 2011 [Page 7]
Internet-Draft Route Configuration by DHCPv6 July 2010
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].
Sun, et al. Expires January 28, 2011 [Page 8]
Internet-Draft Route Configuration by DHCPv6 July 2010
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]. 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.
Sun, et al. Expires January 28, 2011 [Page 9]
Internet-Draft Route Configuration by DHCPv6 July 2010
6. IANA Considerations
The option code of OPTION_ROUTE_INFO will be defined by IANA.
Sun, et al. Expires January 28, 2011 [Page 10]
Internet-Draft Route Configuration by DHCPv6 July 2010
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] MAY be used for security.
Sun, et al. Expires January 28, 2011 [Page 11]
Internet-Draft Route Configuration by DHCPv6 July 2010
8. References
8.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
8.2. Informative References
[I-D.blanchet-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", July 2010,
<draft-ietf-mif-problem-statement-05 (work in progress)>.
[I-D.hui-mif-dhcpv4-routing-03]
Hui, M. and H. Deng, "Extension of DHCPv4 for policy
routing of multiple interfaces terminal", March 2010,
<draft-hui-mif-dhcpv4-routing-03(work in progress)>.
Sun, et al. Expires January 28, 2011 [Page 12]
Internet-Draft Route Configuration by DHCPv6 July 2010
Authors' Addresses
Tao Sun
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: suntao@chinamobile.com
Hui Deng
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: denghui@chinamobile.com
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Sun, et al. Expires January 28, 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 06:39:26 |