Internet Area M.Hui
Internet Draft H.Deng
Intended status: Informational China Mobile
Expires: February 27, 2010 August 27, 2009
Extension of DHCPv4 for policy routing of multiple interfaces
terminal
draft-hui-mif-dhcpv4-routing-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 February 27, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Hui & Deng Expires February 27, 2010 [Page 1]
Internet-Draft IP Multiple Connections August 2009
Abstract
Current multiple interfaces terminal causes the problem of selecting
a proper interface for a specific application, and this is a new
question which will change the previous internet model. This document
proposes a solution which uses policy routing to map the IP flows to
multiple interfaces.
Hui&Deng Expires February 27, 2010 [Page 2]
Internet-Draft IP Multiple Connections August 2009
Table of Contents
1. Introduction................................................4
2. Scenario....................................................5
3. Solution....................................................6
3.1. Routing policy.........................................6
3.2. DHCP extension.........................................6
3.3. Configuration procedure.................................8
4. Security Considerations......................................9
5. IANA Considerations........................................10
6. References.................................................11
6.1. Normative References...................................11
6.2. Informative References.................................11
Author's Addresses............................................12
Hui&Deng Expires February 27, 2010 [Page 3]
Internet-Draft IP Multiple Connections August 2009
1. Introduction
Currently, the terminal always has multiple interfaces to connect to
different types of access networks. The challenge is how to assign
different IP flows to each interface, and ensure all the interfaces
can deliver the flow simultaneously.
The operating systems only allow one default network connection now.
If there are multiple connections of the host, all the flows will go
to the default gateway based on RFC1122 description. One default
gateway guarantees the host always has one entry to the network, but
lead to the multiple connections be difficult. The most convenient
way to make the host work under several networks at the same time is
to add specific static route in the host route table, so that certain
flow can use the assigned interface while others use the default one,
but it is not easy for the ordinary users to handle it. We analyze
this problem statement in another IETF draft 'draft-hui-ip-multiple-
connections-ps-01'.
In this document we will illustrate the specific scenario and give a
probable solution by extending DHCPv4.
Hui&Deng Expires February 27, 2010 [Page 4]
Internet-Draft IP Multiple Connections August 2009
2. Scenario
The usage of multiple interfaces is common. For example, the user has
several applications run in his mobile terminal, and the terminal has
multiple interfaces for different types of access technology such as
WiFi and 3GPP LTE. It is important for the user to connect right
access network for specific application. The problem is current
internet model and protocol stack are not designed for multiple
interface scenarios, for the mechanism of the mapping between
application and multiple interfaces is lack.
In this draft a solution of policy routing is proposed to map the
application to specific interface based on policies defined by users
or operators.
Hui&Deng Expires February 27, 2010 [Page 5]
Internet-Draft IP Multiple Connections August 2009
3. Solution
In order to direct IP flows of the application to the right interface,
DHCPv4 message can be extended to carry the routing policy, and the
extension is added in the option field of the DHCP message.
3.1. Routing policy
The routing policy can be applied in the host so that different IP
flows can go to different interfaces depending on the policy. To
maintain a simple host routing table, the policy can be allocated by
the network side, i.e. the gateway. The policy is distributed to the
host as soon as it attaches to the gateway, and the policy will be
applied in the initial procedure of the host.
The routing policy information should contain the proper interface
allocation according to IP destination and service type. For doing
this, IP flows can go to the appropriate network, and all connections
can work simultaneously.
3.2. DHCP extension
DHCP is a proper message to carry the host routing policy information,
for DHCP take effect when host first attach to the network, and DHCP
is a universal protocol used in the host IP deployment between
network gateway and host.
In the RFC2132, option 33 is defined as the static route option,
which directs the IP flow to a router depending on the destination IP
address. This is a kind of policy routing, but the destination IP
address is not enough to indicate the relationship of IP flow and
interface in nowadays complicated network deployment situation. More
attributes are needed to determine a binding of application IP flow
and interface.
To carry the host routing information, the extension of the DHCP
option is showed as follow:
Hui&Deng Expires February 27, 2010 [Page 6]
Internet-Draft IP Multiple Connections August 2009
Code Len Destination 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+
| x | n | d1 | d2 | d3 | d4 | m1 |
+-----+-----+-----+-----+-----+-----+-----+
TOS1 Router1 Metric1
+-----+-----+-----+-----+-----+-----+-----+
| t1 | r1 | r2 | r3 | r4 | e1 | d1 |
+-----+-----+-----+-----+-----+-----+-----+
Destination 2 Mask2 TOS2 Router2
+-----+-----+-----+-----+-----+-----+-----+
| d2 | d3 | d4 | m1 | t1 | r1 | r2 |
+-----+-----+-----+-----+-----+-----+-----+
Metric2
+-----+-----+-----+-----+
| r3 | r4 | e1 | ...
+-----+-----+-----+-----+
Figure 1 DHCP extension format.
Code is an 8 bits number represents the specific DHCP option, which
needs to be assigned by IANA.
Len represents the length of the option form the byte after the Len
field, and it takes 8 bit.
Destination is the Destination IP address of the datagram, occupying
4 byte. Mask field represents the subnet mask digit of the destination.
TOS is 8 bit length which follows the definition in RFC1349, and it
represents the requirement of specific IP flow, such as bandwidth and
delay.
Router is the IP address of the network gateway which takes 32 bit
length. Either the router interface address or the corresponding host
interface address is suitable.
Metric is the measurement of the routing performance, it represent
different types of value to measure the route, such as hops. The
length of metric is 8 bit. The metric in host routing table means the
bandwidth of the access network and the route has lower metric
represents better performance. It will be useful when the route
Hui&Deng Expires February 27, 2010 [Page 7]
Internet-Draft IP Multiple Connections August 2009
policies get from different interfaces conflict, if more than one
route items have same destination and TOS but with different router
address, the one has lower metric will be used.
3.3. Configuration procedure
The DHCP routing policy is carried in the DHCP message, when host
requires IP configuration as soon as it first attaches the network,
DHCP server will send the routing policy together with the IP
configuration to the host.
Then the routing policy carried on the DHCP message is obtained by
the host, and applied as the static routing entries in the host
routing table.
When it comes to the source address selection of the datagram, the
host operating system will look up the routing table according to the
destination IP address first, if it finds an available routing, the
interface of this routing will be used to send out the datagram, and
the IP address of this interface is selected to be the source address
of the datagram. The detail of the source address selection is
described in RFC1122 and RFC3484.
So that the static routing entry can constrain specific IP flow to
certain interface. Depending on the destination and TOS, the IP flow
can find a proper router as the next hop, and goes out through the
corresponding interface. Thus different IP flows can use multiple
connections properly and simultaneously.
Hui&Deng Expires February 27, 2010 [Page 8]
Internet-Draft IP Multiple Connections August 2009
4. Security Considerations
This document doesn't propose any new protocol.
Hui&Deng Expires February 27, 2010 [Page 9]
Internet-Draft IP Multiple Connections August 2009
5. IANA Considerations
This document requires a new number for DHCP option code x described
in section 3.2.
Hui&Deng Expires February 27, 2010 [Page 10]
Internet-Draft IP Multiple Connections August 2009
6. References
6.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.
[RFC2132] S. Alexander, Silicon Graphics, Inc., and R. Droms, " DHCP
Options and BOOTP Vendor Extensions ", RFC 2132, March 1997.
[RFC3484] R. Draves, "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC3484, February 2003.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4177] Huston, G., "Architectural Approaches to Multi-homing for
IPv6", RFC 4177, September 2005.
[RFC4191] R. Draves, D. Thaler, ''Default Router Preferences and
More-Specific Routes'', RFC4191, November 2005
6.2. Informative References
[MONAMI6] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and global Addresses", May 2008, <draft-ietf-
monami6-multihoming-motivation-scenario-03(work in
progress)>.
Hui&Deng Expires February 27, 2010 [Page 11]
Internet-Draft IP Multiple Connections August 2009
Author's Addresses
Min Hui
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: huimin.cmcc@gmail.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui02@gmail.com
Hui&Deng Expires February 27, 2010 [Page 12]