Internet Area M.Hui Internet Draft H.Deng Intended status: Informational China Mobile Expires: May 3, 2009 November 4, 2008 Scenario and Solution: Simple IP Multi-homing of the Host draft-hui-ip-multiple-connections-01.txt 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. This document may not be modified, and derivative works of it may not be created. This document may not be modified, and derivative works of it may not be created, other than to extract section XX as-is for separate use. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English, other than to extract section XX as-is for separate use. This document may only be posted in an Internet-Draft. 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 Hui & Deng Expires May 4, 2009 [Page 1] Internet-Draft IP Multiple Connections November 2008 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 3, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Current host routing mechanism doesn't allow simple IP multi-homing for the default gateway consideration. This document proposes a solution to make multiple connections can work simultaneously. Table of Contents 1. Introduction................................................3 2. Scenario....................................................4 3. Solution....................................................5 3.1. Routing policy.........................................5 3.2. DHCP extension.........................................5 3.3. Configuration procedure.................................6 4. Security Considerations......................................8 5. IANA Considerations.........................................9 6. References.................................................10 6.1. Normative References...................................10 6.2. Informative References.................................10 Author's Addresses............................................11 Intellectual Property Statement................................12 Disclaimer of Validity........................................12 Copyright Statement...........................................12 Hui&Deng Expires May 4, 2009 [Page 2] Internet-Draft IP Multiple Connections November 2008 1. Introduction Simple IP Multi-homing means the host connects to more than one physical network through different network interfaces, and assigns different network flows to each interface, and ensure all the interfaces can deliver the flow simultaneously. Current the operating systems only allow one default network connection. 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 May 4, 2009 [Page 3] Internet-Draft IP Multiple Connections November 2008 2. Scenario Simple IP Multi-homing is a necessary part of daily life. For example, Mike must connect with the VPN by Ethernet interface when he is at work, at the same time he wants to watch the stock market, which is prohibited in the VPN, so he needs another connection to the GPRS network simultaneously. The problem is Mike can not use two connections at the same time for his different service requirement, because all the IP flows go to the same interface which is related to the default gateway in the host routing table. That is the point need to be solved in simple IP multi-homing. Hui&Deng Expires May 4, 2009 [Page 4] Internet-Draft IP Multiple Connections November 2008 3. Solution The default gateway problem can be solved by applying routing policy in the host. 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 polices. 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. To carry the host routing information, DHCP should make an extension in the DHCP option field. The format is showed as follow: Hui&Deng Expires May 4, 2009 [Page 5] Internet-Draft IP Multiple Connections November 2008 Code Len Destination 1 Mask 1 +-----+-----+-----+-----+-----+-----+-----+ | x | n | d1 | d2 | d3 | d4 | m1 | +-----+-----+-----+-----+-----+-----+-----+ TOS1 Router1 +-----+-----+-----+-----+-----+-----+-----+ | m2 | m3 | m4 | t1 | r1 | r2 | r3 | +-----+-----+-----+-----+-----+-----+-----+ Destination 2 Mask2 +-----+-----+-----+-----+-----+-----+-----+ | r4 | d1 | d2 | d3 | m1 | m2 | m3 | +-----+-----+-----+-----+-----+-----+-----+ TOS2 Router2 +-----+-----+-----+-----+-----+-----+----- | m4 | t2 | t1 | t2 | t3 | t4 | ... +-----+-----+-----+-----+-----+-----+----- Figure 1 DHCP extension format. Code is a 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. Destination is the Destination IP address of the datagram, occupying 4 byte. Mask field represents the subnet mask of the destination. TOS 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. Either the router interface address or the corresponding host interface address is suitable. 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. Hui&Deng Expires May 4, 2009 [Page 6] Internet-Draft IP Multiple Connections November 2008 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 May 4, 2009 [Page 7] Internet-Draft IP Multiple Connections November 2008 4. Security Considerations This document doesn't propose any new protocol. Hui&Deng Expires May 4, 2009 [Page 8] Internet-Draft IP Multiple Connections November 2008 5. IANA Considerations This document requires a new number for DHCP option code x described in section 3.2. Hui&Deng Expires May 4, 2009 [Page 9] Internet-Draft IP Multiple Connections November 2008 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, . Hui&Deng Expires May 4, 2009 [Page 10] Internet-Draft IP Multiple Connections November 2008 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 May 4, 2009 [Page 11] Internet-Draft IP Multiple Connections November 2008 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Hui&Deng Expires May 4, 2009 [Page 12]