< draft-hui-ip-multiple-connections-00.txt   draft-hui-ip-multiple-connections-01.txt >
Internet Area M.Hui Internet Area M.Hui
Internet Draft H.Deng Internet Draft H.Deng
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: April 27, 2009 October 27, 2008 Expires: May 3, 2009 November 4, 2008
Scenario and Solution: Simple IP Multi-homing of the Host Scenario and Solution: Simple IP Multi-homing of the Host
draft-hui-ip-multiple-connections-00.txt draft-hui-ip-multiple-connections-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
This document may not be modified, and derivative works of it may not This document may not be modified, and derivative works of it may not
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 27, 2009. This Internet-Draft will expire on May 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Current host routing mechanism doesn't allow simple IP multi-homing Current host routing mechanism doesn't allow simple IP multi-homing
for the default gateway consideration. This document proposes a for the default gateway consideration. This document proposes a
solution to make multiple connections can work simultaneously. solution to make multiple connections can work simultaneously.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 RFC-2119
.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction................................................3
2. Scenario.......................................................3 2. Scenario....................................................4
3. Solution.......................................................3 3. Solution....................................................5
3.1. Routing policy............................................3 3.1. Routing policy.........................................5
3.2. DHCP extension............................................4 3.2. DHCP extension.........................................5
3.3. Configuration procedure...................................5 3.3. Configuration procedure.................................6
4. Security Considerations........................................5 4. Security Considerations......................................8
5. IANA Considerations............................................5 5. IANA Considerations.........................................9
6. References.....................................................5 6. References.................................................10
6.1. Normative References......................................5 6.1. Normative References...................................10
6.2. Informative References....................................6 6.2. Informative References.................................10
Author's Addresses................................................6 Author's Addresses............................................11
Intellectual Property Statement...................................6 Intellectual Property Statement................................12
Disclaimer of Validity............................................7 Disclaimer of Validity........................................12
Copyright Statement...........................................12
1. Introduction 1. Introduction
Simple IP Multi-homing means the host connects to more than one Simple IP Multi-homing means the host connects to more than one
physical network through different network interfaces, and assigns physical network through different network interfaces, and assigns
different network flows to each interface, and ensure all the different network flows to each interface, and ensure all the
interfaces can deliver the flow simultaneously. interfaces can deliver the flow simultaneously.
Current host operating systems allow one default connection at once. Current the operating systems only allow one default network
If there are multiple connections of the host, all the flows will go connection. If there are multiple connections of the host, all the
to the default gateway, although you can find several ''0.0.0.0'' routs flows will go to the default gateway based on RFC1122 description.
in the host route table. One default gateway guarantees the host One default gateway guarantees the host always has one entry to the
always has one exit to the network, but cause the multiple network, but lead to the multiple connections be difficult. The most
connections be impossible. We analyze this problem statement in convenient way to make the host work under several networks at the
another IETF draft ' draft-hui-ip-multiple-connections-ps-01'. 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 In this document we will illustrate the specific scenario and give a
probable solution by extending DHCPv4. probable solution by extending DHCPv4.
2. Scenario 2. Scenario
Simple IP Multi-homing is a necessary part of daily life. For example, 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 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 work, at the same time he wants to watch the stock market, which is
forbidden in the VPN, so he needs another connection to the GPRS prohibited in the VPN, so he needs another connection to the GPRS
network simultaneously. network simultaneously.
The problem is Mike can not use two connections at the same time for 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 his different service requirement, because all the IP flows go to the
same interface which related to the default gateway in the host 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 routing table. That is the point need to be solved in simple IP
multi-homing. multi-homing.
3. Solution 3. Solution
The default gateway problem can be solved by applying routing policy The default gateway problem can be solved by applying routing policy
in the host. in the host.
3.1. Routing policy 3.1. Routing policy
The routing policy can applied in the host so that different IP flows The routing policy can be applied in the host so that different IP
can go to different interfaces depending on the polices. To maintain flows can go to different interfaces depending on the polices. To
a simple host routing table, the policy can be allocated by the maintain a simple host routing table, the policy can be allocated by
network side, i.e. the gateway. The policy is distributed to the host the network side, i.e. the gateway. The policy is distributed to the
as soon as it attaches to the gateway, and the policy will be applied host as soon as it attaches to the gateway, and the policy will be
in the initial procedure of the host. applied in the initial procedure of the host.
The routing policy information should contain the proper interface The routing policy information should contain the proper interface
allocation according to IP destination and service type. For doing allocation according to IP destination and service type. For doing
this, IP flows can go to the appropriate network, and all connections this, IP flows can go to the appropriate network, and all connections
can work simultaneously. can work simultaneously.
3.2. DHCP extension 3.2. DHCP extension
DHCP is a proper message to carry the host routing policy information, 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 for DHCP take effect when host first attach to the network, and DHCP
is a universal protocol used in the host IP deployment between is a universal protocol used in the host IP deployment between
network gateway and host. network gateway and host.
To carry the host routing information, DHCP should make an extension To carry the host routing information, DHCP should make an extension
in the DHCP option field. The format is showed as follow: in the DHCP option field. The format is showed as follow:
Code Len Destination 1 Mask 1 Code Len Destination 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
| x | n | d1 | d2 | d3 | d4 | m1 | | x | n | d1 | d2 | d3 | d4 | m1 |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
TOS1 Router1 Destination 2 TOS1 Router1
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
| t1 | r1 | r2 | r3 | r4 | d1 | d2 | | m2 | m3 | m4 | t1 | r1 | r2 | r3 |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
Mask 2 TOS2 Router2 Destination 2 Mask2
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
| d3 | d4 | m2 | t2 | r1 | r2 | r3 | | r4 | d1 | d2 | d3 | m1 | m2 | m3 |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
TOS2 Router2
+-----+-----+-----+-----+-----+-----+-----
| m4 | t2 | t1 | t2 | t3 | t4 | ...
+-----+-----+-----+-----+-----+-----+-----
+-----+-----
| r4 | ...
+-----+-----
Figure 1 DHCP extension format. Figure 1 DHCP extension format.
Code is a number represents the specific DHCP option, which needs to Code is a number represents the specific DHCP option, which needs to
be assigned by IANA. be assigned by IANA.
Len represents the length of the option form the byte after the Len Len represents the length of the option form the byte after the Len
field. field.
Destination is the Destination IP address of the datagram, occupying Destination is the Destination IP address of the datagram, occupying
4 byte. Mask represents the subnet mask digit of the destination. 4 byte. Mask field represents the subnet mask of the destination.
TOS follows the definition in RFC1349, and it represents the TOS follows the definition in RFC1349, and it represents the
requirement of specific IP flow, such as bandwidth and delay. requirement of specific IP flow, such as bandwidth and delay.
Router is the next hop IP address. Either the router interface Router is the IP address of the network gateway. Either the router
address or the corresponding host interface address is suitable. interface address or the corresponding host interface address is
suitable.
3.3. Configuration procedure 3.3. Configuration procedure
The DHCP routing policy is carried in the DHCP message, when host The DHCP routing policy is carried in the DHCP message, when host
requires IP configuration as soon as it first attaches the network, requires IP configuration as soon as it first attaches the network,
DHCP server will send the routing policy together with the IP DHCP server will send the routing policy together with the IP
configuration to the host. configuration to the host.
Then the routing policy carried on the DHCP message is obtained by Then the routing policy carried on the DHCP message is obtained by
the host, and applied as the static routing entries in the host the host, and applied as the static routing entries in the host
routing table, which constrain specific IP flow to certain interface. routing table.
Depending on the destination and TOS, the IP flow can find a proper
router as the next hop, and goes out through the corresponding When it comes to the source address selection of the datagram, the
interface. Thus different IP flows can use multiple connections host operating system will look up the routing table according to the
properly and simultaneously. 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.
4. Security Considerations 4. Security Considerations
This document doesn't propose any new protocol. This document doesn't propose any new protocol.
5. IANA Considerations 5. IANA Considerations
This document requires a new number for DHCP option code x described This document requires a new number for DHCP option code x described
in section 3.2. in section 3.2.
skipping to change at page 5, line 42 skipping to change at page 10, line 18
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2132] S. Alexander, Silicon Graphics, Inc., and R. Droms, " DHCP [RFC2132] S. Alexander, Silicon Graphics, Inc., and R. Droms, " DHCP
Options and BOOTP Vendor Extensions ", RFC 2132, March 1997. 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- [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003. Multihoming Architectures", RFC 3582, August 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4177] Huston, G., "Architectural Approaches to Multi-homing for [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for
IPv6", RFC 4177, September 2005. IPv6", RFC 4177, September 2005.
[RFC4191] R. Draves, D. Thaler, ''Default Router Preferences and [RFC4191] R. Draves, D. Thaler, "Default Router Preferences and
More-Specific Routes'', RFC4191, November 2005 More-Specific Routes", RFC4191, November 2005
6.2. Informative References 6.2. Informative References
[MONAMI6] Ernst, T., "Motivations and Scenarios for Using Multiple [MONAMI6] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and global Addresses", May 2008, <draft-ietf- Interfaces and global Addresses", May 2008, <draft-ietf-
monami6-multihoming-motivation-scenario-03(work in monami6-multihoming-motivation-scenario-03(work in
progress)>. progress)>.
Author's Addresses Author's Addresses
skipping to change at page 7, line 30 skipping to change at line 306
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 19 change blocks. 
66 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/