Internet Area                                                   M.Hui 
Internet Draft                                                 H.Deng 
Intended status: Informational                           China Mobile 
Expires: Jan 01,2011                                    July 01, 2010 
                                   
 
                                      
       Extension of DHCPv4 for policy routing of multiple interfaces 
                                 terminal 
                    draft-hui-mif-dhcpv4-routing-03.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 Jan 01,2011. 

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

    
 
 
 
Hui & Deng             Expires Jan 01, 2011                [Page 1] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

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 extend DHCPv4 to carry the policy routing to
   map the IP flows to multiple interfaces. 





































 
 
Hui&Deng               Expires Jan 01, 2011                [Page 2] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

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 Jan 01, 2011                [Page 3] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

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-02'. 

   In this document we will illustrate the specific scenario and give a 
   probable solution by extending DHCPv4. 























 
 
Hui&Deng               Expires Jan 01, 2011                [Page 4] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

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 Jan 01, 2011                [Page 5] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

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 Jan 01, 2011                [Page 6] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    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 Jan 01, 2011                [Page 7] 

Internet-Draft         IP Multiple Connections           July 2010 
    

   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 Jan 01, 2011                [Page 8] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

4. Security Considerations 

   This document doesn't propose any new protocol. 









































 
 
Hui&Deng               Expires Jan 01, 2011                [Page 9] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

5. IANA Considerations 

   This document requires a new number for DHCP option code x described 
   in section 3.2. 








































 
 
Hui&Deng               Expires Jan 01, 2011               [Page 10] 

Internet-Draft         IP Multiple Connections           July 2010 
    

    

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, July 1997.  

   [RFC2132] S. Alexander, Silicon Graphics, Inc., and R. Droms, " DHCP 
             Options and BOOTP Vendor Extensions ", RFC 2132, July 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 Jan 01, 2011               [Page 11] 

Internet-Draft         IP Multiple Connections           July 2010 
    

              

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 Jan 01, 2011               [Page 12]