One document matched: draft-sun-mif-route-config-dhcp6-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc1122 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY rfc3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc4191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml'>
<!ENTITY rfc3118 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-sun-mif-route-config-dhcp6-03">
<front>
<title abbrev="Route Configuration by DHCPv6">Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces</title>
<author initials="T.S."surname="Sun"fullname="Tao Sun"><organization>China
Mobile</organization><address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave,Xuanwu District</street><city>Beijing
100053</city><country>China</country></postal>
<email>suntao@chinamobile.com</email></address>
</author>
<author initials="H.D."surname="Deng"fullname="Hui Deng"><organization>China
Mobile</organization><address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave,Xuanwu District</street><city>Beijing
100053</city><country>China</country></postal>
<email>denghui@chinamobile.com</email></address>
</author>
<author initials="D.L."surname="Liu"fullname="Dapeng Liu"><organization>China
Mobile</organization><address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave,Xuanwu District</street><city>Beijing
100053</city><country>China</country></postal>
<email>liudapeng@chinamobile.com</email></address>
</author>
<date month="July"year="2010"/><area>Internet</area><workgroup>MIF
Working Group</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section anchor="intro" title="Introduction">
<section title="Background">
<t> 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
<xref target="I-D.blanchet-mif-problem-statement"> </xref> .
</t>
<t> 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 <xref target="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.
</t>
<t> 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 <xref target="RFC3315"/>.
</t>
<t>
An optional extension to Router Advertisement messages is described in
<xref target="RFC4191"> </xref> for communicating default router preferences and
more-specific routes from routers to hosts. To address multi-homed problems in a flexible way,
<xref target="I-D.hui-mif-dhcpv4-routing-03"> </xref> through introducing TOS
and specific routes into DHCPv4 options. This document considers the situations
for IPv6 cases.
</t>
</section>
<section anchor="Scenarios" title="Scenario Descriptions">
<t>
The scenario addressed by the approach proposed in this document is illustrated in <xref target='fig_scenario' />.
In the figure, the MIF host have three interfaces connected to the access network Ethernet, WiFi and 3G respectively.
</t>
<figure align="center" anchor="fig_scenario" title="The MIF host scenario">
<artwork><![CDATA[
+---------+
| 3G |
+---------+
|
I3 |
^
|
+-----------+ I1 +--------+ I2 +-----------+
| Ethernet |<------>|MIF Host|<------>| WiFi |
+-----------+ +--------+ +-----------+
]]></artwork></figure>
<t>
The procedures that an application employs an interface for network access are
depicted in <xref target='fig_1' /> as steps a1) to a4).
<list style="format a%d)">
<t>
An application calls sockets to build IP packets.
</t>
<t>
The socket selects source address based on the routing table.
</t>
<t>
The socket sends packets to the corresponding interface.
</t>
<t>
The interface will forward the packets to the next hop (the corresponding gateway).
</t>
</list>
</t>
<figure align="center" anchor="fig_1" title="The procedures of updating a routing table and select an interface for an application">
<artwork><![CDATA[
+---------+ b4 +-------+
|Interface|--------->|Network|
+---------+ +-------+
|
b3 |
^
|
+-----------+ b1 +------+ +-----------+
|Application|---->|Socket|<------|Route Table|
+-----------+ +------+ b2 +-----------+
]]></artwork></figure>
<t>
Notice that the approach proposed in this document
is feasible under the strong ES model as defined in <xref target="RFC1122"/>.
</t>
</section>
</section>
<section anchor="Define Option" title="Route Information Option Format" >
<t>
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 <xref target="fig_2"> </xref>.
</t>
<figure align="center" anchor="fig_2" title="The Route Information Option"><artwork><![CDATA[
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. |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ |
| |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>
option-code:OPTION_ROUTE_INFO (should be defined by IANA).
</t>
<t>
option-len: length of the route rule field in octets.
</t>
<t>
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.
</t>
<t>
TOS N: The Nth TOS (Type-of-Service, 8 bits).
</t>
<t>
Metric N:The Nth route metric, an 16-bit unsigned integer ranging from 1 to 9999.
</t>
<t>
Dest.Pref.Len: Length of the IPv6 destination subnet prefix,
an 8-bit unsigned integer ranging from 0 to 128.
</t>
<t>
Dest.Pref.: The IPv6 destination address prefix
</t>
<t>
Next Hop Pref.: A 128-bit IPv6 prefix that
will be used as the next hop when forwarding packets.
</t>
<t>
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.
</t>
</section>
<section title="Route Information Option Format Usage" >
<section title="DHCPv6 Client Behavior ">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="DHCPv6 Server Behavior ">
<t>
The DHCPv6 server MUST NOT send Route Option in messages other than ADVERTISE or
REPLY.
</t>
<t>
The maximum number of routing information in one DHCPv6
message depend on the maximum
DHCPv6 message size defined in <xref target="RFC3315"> </xref>.
</t>
</section>
</section>
<section title="Implementation Considerations">
<section title="Conflict of Route Rules">
<t>
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 <xref target="RFC3484"> </xref>. For the situations where
a route option conflicts with
one previous route rules, the latter one will override the previous rule.
</t>
</section>
<section title="Not Limited to DHCPv6 Servers">
<t>
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.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
The option code of OPTION_ROUTE_INFO will be defined by IANA.
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
DHCP authentication option <xref target="RFC3118"> </xref> MAY be used for security.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc1122;
&rfc2119;
&rfc3484;
&rfc3315;
&rfc4191;
&rfc3118;
</references>
<references title='Informative References'>
<reference anchor="I-D.blanchet-mif-problem-statement"
target="draft-ietf-mif-problem-statement-05 (work in progress)">
<front>
<title>Multiple Interfaces Problem Statement</title>
<author initials="M." surname="Blanchet">
<organization></organization>
</author>
<author initials="P." surname="Seite">
<organization></organization>
</author>
<date month="July" year="2010" />
</front>
</reference>
<reference anchor="I-D.hui-mif-dhcpv4-routing-03"
target="draft-hui-mif-dhcpv4-routing-03(work in progress)">
<front>
<title>Extension of DHCPv4 for policy routing of multiple interfaces terminal</title>
<author initials="M." surname="Hui">
<organization abbrev="China Mobile">
China Mobile
</organization>
</author>
<author initials="H." surname="Deng">
<organization abbrev="China Mobile">
China Mobile
</organization>
</author>
<date month="March" year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:34:38 |