<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<!-- <!DOCTYPE rfc SYSTEM "rfc&rfc.number;.dtd"> -->

<!-- 31 mai 2013 -->

<rfc category="exp" ipr="trust200902" docName="draft-kaiser-if-sel-01">

	<front>

		<title abbrev="If-Sel">Interface Selection Mechanism for Multiple Interfaces IPv6 Hosts</title>

		<author initials="A.K." surname="Kaiser" fullname="Arnaud Kaiser">
			<organization abbrev="CEA">Commissariat à l'Energie Atomique</organization>
			<address>
				<postal>
					<street>8 Avenue de la Vauve</street>
					<city>Palaiseau</city>
					<region>Ile-de-France</region>
					<code>91120</code>
					<country>FR</country>
				</postal>
<!--				<phone>+33 1 69 08 07 28</phone> -->
				<email>arnaud.kaiser@cea.fr</email>
<!--				<uri>http://www.google.com/</uri> -->
			</address>
		</author>

		<author initials="A.P." surname="Petrescu" fullname="Alexandru Petrescu">
			<organization abbrev="CEA">Commissariat à l'Energie Atomique</organization>
			<address>
				<postal>
					<street>8 Avenue de la Vauve</street>
					<city>Palaiseau</city>
					<region>Ile-de-France</region>
					<code>91120</code>
					<country>FR</country>
				</postal>
<!--				<phone>+33 1 69 08 92 23</phone> -->
				<email>alexandru.petrescu@cea.fr</email>
<!--				<uri>http://www.google.com/</uri> -->
			</address>
		</author>

		<date/>

		<keyword>Multiple Interface</keyword>
		<keyword>Neighbor Discovery</keyword>
		<keyword>IPv6</keyword>

		<abstract>
			<t>
			This document describes an interface selection mechanism that enables multiple interfaces (multihomed) IPv6 hosts to select their most appropriate egress interface to send data over the network. The mechanism extends the Neighbor Discovery (ND) protocol <xref target="RFC4861"/> with two new Router Advertisement options.
			</t>
		</abstract>

	</front>

	<middle>
		<section title="Introduction">
			<t>
			In the context of multihomed hosts, where hosts are connected to a network with more than only one interface, the selection of a right egress interface to send data is critical. Indeed, selecting a wrong egress interface may lead to a non-optimal routing of data in the network or, in the worst case, the impossibility to reach the destination. In order to cope with the aforementioned issue, this document describes an interface selection mechanism that enables hosts to select their most appropriate egress interface, leading to an optimized end-to-end routing of data.
			</t>
			<t>
			The proposed mechanism is based on the ND protocol. More precisely, two new options are introduced in RS and RA messages: the Link Cost Option (LCO) and the Path Cost Option (PCO).
			</t>
		</section>

		<section title="Requirements">
			<t>The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in <xref target="KEYWORDS"/>.</t>
		</section>

<!--
		<section title="Related works">
			<t>
			To be done.
			</t>
		</section>
-->

		<section title="Description of the mechanism" anchor="descr_mech">
			<t>
			The proposed mechanism is divided into two operations, each one relying on a new ND option:
				<list style="symbols">
					<t>Gathering informations about links costs and selection of a default egress interface using the Link Cost Option</t>
					<t>Gathering informations about the cost of a path to a destination and selection of an egress interface for the specific destination using the Path Cost Option (PCO)</t>
				</list>
			</t>
			<t>
			The following subsections detail each operation as well as the corresponding option.
			</t>
			<section title="Link Cost Option" anchor="h_behav">
				<t>
				The LCO is used to advertise the cost of a link. This option SHOULD be included in all RA messages that are generated by routers. Therefore, a host that connects to a link is informed about the cost of this specific link. By extension, if a host is connected to multiple links in the network, it is informed about the cost of each of those links. Using these informations, the host selects its default interface: the interface connected to the link that has the lowest cost is selected. The host then adds in its routing table an entry that contains the default route as destination, the router that is on the corresponding link as next-hop, the selected interface as outgoing interface and the link cost as metric. Upon reception of other RA messages, the host compares the link costs included in the RAs with the one in its routing table. If the received link cost is better than the one of the default route in the routing table, the latter MUST be updated accordingly.
				<!--If several metrics are available on the link, the LCO contains a list of costs corresponding to the various metrics. The metrics are differentiated using a unique ID that is known by both hosts and routers. This option is included in RA messages.-->
				</t>
				<t>
				The following figure shows the format of the link cost option. This option is only valid in the RA messages and MUST NOT be included in the other ND messages.
				</t>
				<t>
				<figure>
					<artwork>
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Link Cost                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
					</artwork>
				</figure>
				<list style="hanging" hangIndent="16">
					<t hangText="Type:">Identifier of the LCO (TBD by IANA).</t>
					<t hangText="Length:">1. Size of the option as defined in <xref target="RFC4861"/>.</t>
					<t hangText="Reserved:"> Unused field. MUST be set to zero by sender and ignored by recipient.</t>
					<t hangText="Link Cost:">Unsigned integer. The cost of the link.</t>
				</list>
				</t>
			</section>
			<section title="Path Cost Option" anchor="r_behav">
				<t>
				The PCO is used by hosts to ask routers about the total cost of a path to a destination. The routers reply to the request also by using the PCO. Thus, this option MAY be included in RS and RA messages.
				</t>
				<t>
				When a multiple interfaces host wants to send data to a destination node, it starts by checking in its routing table if a specific route to this destination exists. If no route exists, the host sends a RS message with a PCO to the all-routers multicast address on each of its interfaces. The PCO includes the IPv6 address of the destination to which the host wants to send data. Upon reception of such RS message, a router checks in its routing table which route entry it would select to forward data to this specific destination. The router then replies by sending a unicast RA message to the requesting host with a PCO that includes the total cost of the selected path from the router itself to the destination along with a lifetime that defines the validity of the route advertised. Upon reception of these informations, the host computes the total cost of the path from itself to the destination by adding to the path cost advertised by the router the corresponding link cost (which is advertised with the LCO). Once computed, the host selects as egress interface to the specific destination the interface connected to the path that has the lowest end-to-end cost. The host then updates its routing table accordingly with the new computed information.
				</t>
				<t>
				The following figure shows the format of the path cost option. This option is only valid in the RS or RA messages and MUST NOT be included in the other ND messages.
				</t>
				<t>
				<figure>
					<artwork>
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |Transaction ID |  Status Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Reserved                    | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          Destination                          |
|                       Address or Prefix                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Path Cost                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
					</artwork>
				</figure>
				<list style="hanging" hangIndent="26">
					<t hangText="Type:">Identifier of the PCO (TBD by IANA).</t>
					<t hangText="Length:">4. Size of the option as defined in <xref target="RFC4861"/>.</t>
					<t hangText="Transaction ID:">Identifier of the current RS/RA messages exchange between the host and the router.</t>
					<t hangText="Status Code:">Code that provides additionnal informations about the results provided by the router (see <xref target="status_code"/> for more details). MUST be set to zero in RS messages and ignored by recipient.</t>
					<t hangText="Reserved:"> Unused field. MUST be set to zero by sender and ignored by recipient.</t>
					<t hangText="Prefix Length:">Size of the IPv6 prefix that follows. Set to 128 if the following field contains an IPv6 address.</t>
					<t hangText="Dst. addr. or pref.:">IPv6 prefix or address of the destination node to which the path computation is asked.</t>
					<t hangText="Path Cost:">Unsigned integer. The total cost of the path from the advertising router to the destination.</t>
					<t hangText="Lifetime:">The lifetime of the route advertised in this PCO. MUST be set to zero in RS messages and ignored by recipient.</t>
				</list>
				</t>
			</section>
		</section>

		<section title="Status Code" anchor="status_code">
		<t>
		A Status Code is included in the PCO option. It provides additionnal informations to the host about the results of its request. The following codes are considered:
		<list style="hanging" hangIndent="5">
			<t hangText="0">Success: a path to the destination is known by the router and the corresponding path cost is included in the PCO.</t>
			<t hangText="1">No specific route to the destination is known by the router. However, the router has a default route that can be used to forward data to the destination, but with no warranty. In this case, the corresponding path cost MUST be set to the maximum possible value (i.e. all-ones bits).</t>
			<t hangText="2">Failure: the packets to this destination would probably be dropped by this router because no route to reach the destination is known or because of any other reason (firewall rules, policy-related rules, ...). In this case, the path cost value is set to zero.</t>
		</list>
		</t>
		</section>

		<section title="Example use case" anchor="use_case">
		<!--<t>The proposed mechanism can be easily deployed in any kind of "local" network, such as home networks, corporate networks or ad-hoc networks. This section illustrates the mechanism through a simple example.</t>-->
<!--		<t>The proposed mechanism is particularly well-suited for bounded network, such as home networks, corporate networks or ad-hoc networks.</t> -->
		<t>Typical uses cases that can be considered are home networks, corporate network, ad-hoc networks, etc. This section illustrates the mechanism through a simple network topology.</t>
			<section title="Network topology">
			<t>The following figure depicts the network topology used in this example.</t>
			<figure>
				<artwork>
                                      Link1 (4)
                                   2001:db8:1::/64
   Link2 (2)      --+-----------------------------------------+--
 2001:db8:2::/64     |                                         |
 --+--------+--      |                                         |
    |       |        |                                         |
    |       |   /----+----\                               /----+----\
    |       |   |         |                               |         |
+---+---+   +---+ Router1 |                               | Router2 |
|       |       |         |                               |         |
| Host2 |       \----+----/                               \----+----/
|       |            |                                         |
+-------+            | Link3 (5)                     Link4 (3) |
                     | 2001:db8:3::/64         2001:db8:4::/64 |
                   --+----------+--                 --+--------+--
                                |                     |
                                |      +-------+      |
                                |   I1 |       | I2   |
                                +------+ Host1 +------+
                                       |       |
                                       +-------+
				</artwork>
			</figure>
			<t>The figure shows two routers (Router1, Router2) and two hosts (Host1, Host2). Theses nodes are connected to each other through 4 links (Link1, Link2, Link3, Link4). The values in brackets represent the corresponding link costs. Also, Host1 is a multiple interfaces device: it is connected to Link3 via its network interface I1 and to link4 via its network interface I2.</t>
			<t>Let us consider Host1. Its first operation consists of gathering links costs and select a default interface. To this end, Router1 and Router2 send usual periodic RA messages. These messages include a LCO that describes the cost of the link: Router1 advertises that the cost of Link3 is 5 and Router2 advertises that the cost of link4 is 3. As Link4 has a better cost that Link3, Host1 selects I2 as its default interface. Host1 then updates its routing table accordingly, as show in the following figure:</t>
			<figure>
				<artwork>
+---------------------+------------------+------------------+------+
| Destination Network | Next-Hop Address | Output Interface | Cost |
+---------------------+------------------+------------------+------+
|      fe80::/64      |         -        |        I1        |   5  |
+---------------------+------------------+------------------+------+
|      fe80::/64      |         -        |        I2        |   3  |
+---------------------+------------------+------------------+------+
|   2001:db8:3::/64   |         -        |        I1        |   5  |
+---------------------+------------------+------------------+------+
|   2001:db8:4::/64   |         -        |        I2        |   3  |
+---------------------+------------------+------------------+------+
|       Default       |     @Router2     |        I2        |   3  |
+---------------------+------------------+------------------+------+
				</artwork>
			</figure>
			<t>Let us now consider that Host1 wants to communicate with Host2. In a classical scenario, Host1 would send data for Host2 through I2, according to its routing table. Data would thus be forwarded by Router2 and Router1 through Link1 and Link2 respectively, leading to a total path cost of 9. Sending data through I1 would have been a better choice. Indeed, despite the fact that Link3 has a worse cost compared to Link4, the end-to-end path cost would be better (7). However, as Host1 is not a router, it does not have a sufficient vision of the network to make such decision. To this end, before sending data to Host2, Host1 first send a RS message that includes a PCO on all its outgoing interfaces (I1 and I2). The "Destination Address" field is filled with the address of Host2. Upon reception of such message, the routers reply to Host1 with a PCO included in RA message: Router1 replies that its better known path to reach Host2 has a total cost of 2 (Link2) and Router2 replies that its better known path has a total cost of 6 (Link1 + Link2). As Host1 already knows the costs of Link3 and Link4, it computes that sending data through I1 would have an end-to-end cost of 7 (Link3 + Link2) whereas using I2 would lead to an end-to-end cost of 9 (Link4 + Link1 + Link2). Hence, Host1 selects I1 as its egress interface to reach Host2 and updates accordingly its routing table, as shown in the following figure:</t>
			<figure>
				<artwork>
+---------------------+------------------+------------------+------+
| Destination Network | Next-Hop Address | Output Interface | Cost |
+---------------------+------------------+------------------+------+
|      fe80::/64      |         -        |        I1        |   5  |
+---------------------+------------------+------------------+------+
|      fe80::/64      |         -        |        I2        |   3  |
+---------------------+------------------+------------------+------+
|   2001:db8:3::/64   |         -        |        I1        |   5  |
+---------------------+------------------+------------------+------+
|   2001:db8:4::/64   |         -        |        I2        |   3  |
+---------------------+------------------+------------------+------+
|       Default       |     @Router2     |        I2        |   3  |
+---------------------+------------------+------------------+------+
|   2001:db8:2::/64   |     @Router1     |        I1        |   7  |
+---------------------+------------------+------------------+------+
				</artwork>
			</figure>
<!--			<t>In order for Host1 to not restart the path cost operation each time it wants to communicate with Host2, but also to avoid that Host1 routing table grows to much if several different hosts are contacted, a lifetime is associated with the newly added route. That route lifetime is defined by the router that advertised the route. An example of route lifetime would be to use the same value as the Router Lifetime advertised by the router (as described in <xref target="RFC4861"/>, section 4.2). Once the route lifetime expires, Host1 MUST remove the entry from its routing table and thus has to restart the operation if it wants to reach Host2 again.</t> -->
			</section>
			<section title="Messages exchange diagram">
			<t>The following diagram shows the messages exchanges corresponding to the example described above: the first two RA messages correspond to Host1 default interface selection, the following two RS/RA messages exchanges correspond to the selection of Host1 interface to reach Host2 and the lasts messages show the final path used by data to transit from Host1 to Host2 and vice-versa.</t>
			<figure>
				<artwork>
+-------+                    +---------+   +---------+     +-------+
| Host1 |                    | Router1 |   | Router2 |     | Host2 |
+-------+                    +---------+   +---------+     +-------+
    |                             |             |              |
    |    +----+--------------+    |             |              |
    |    | RA | LCO cost = 5 |    |             |              |
    |    +----+--------------+    |             |              |
 I1 o&lt;----------------------------o             |              |
    |                             |             |              |
    |           +----+--------------+           |              |
    |           | RA | LCO cost = 3 |           |              |
    |           +----+--------------+           |              |
 I2 o&lt;------------------------------------------o              |
    |                             |             |              |
    |  +----+------------------+  |             |              |
    |  | RS | PCO dst = @Host2 |  |             |              |
    |  +----+------------------+  |             |              |
 I1 o----------------------------&gt;o             |              |
    |                             |             |              |
    |         +----+------------------+         |              |
    |         | RS | PCO dst = @Host2 |         |              |
    |         +----+------------------+         |              |
 I2 o------------------------------------------&gt;o              |
    |                             |             |              |
    |    +----+--------------+    |             |              |
    |    | RA | PCO cost = 2 |    |             |              |
    |    +----+--------------+    |             |              |
 I1 o&lt;----------------------------o             |              |
    |                             |             |              |
    |          +----+--------------+            |              |
    |          | RA | PCO cost = 6 |            |              |
    |          +----+--------------+            |              |
 I2 o&lt;------------------------------------------o              |
    |                             |             |              |
    |       +----+----------+     |     +---------------+      |
    |       | DATA TO HOST2 |     |     | DATA TO HOST2 |      |
    |       +----+----------+     |     +---------------+      |
 I1 o----------------------------&gt;o---------------------------&gt;o
    |                             |             |              |
    |       +----+----------+     |     +---------------+      |
    |       | DATA TO HOST1 |     |     | DATA TO HOST1 |      |
    |       +----+----------+     |     +---------------+      |
 I1 o&lt;----------------------------o&lt;---------------------------o
    |                             |             |              |
    |                             |             |              |
				</artwork>
			</figure>
			</section>
		</section>

<!--
		<section title="Multimetric variant">
		<t>
		This variant considers the case where several different metrics can be used to route data on a network. In such situations, several costs are assigned to links, each one corresponding to a specific metric. Hence, routers advertise the list of all assigned costs using the following LCO
		</t>
		</section>
-->

		<section title="Security Considerations">
		<t>To be done.</t>
		</section>

		<section title="IANA Considerations">
			<t>IANA is kindly requested by the authors to allocate the following values:
				<list style="symbols">
					<t>The Link Cost Option type, which should be added to the Neighbor Discovery option type space defined in section 13 of <xref target="RFC4861"/></t>
					<t>The Path Cost Option type, which should be added to the Neighbor Discovery option type space defined in section 13 of <xref target="RFC4861"/></t>
				</list>
			</t>
		</section>

<!--
		<section title="Acknowledgements" anchor="Acknowledgements">
      <t>
	This work has been performed in the framework of the french FUI project ECONHOME.
      </t>
    </section>
-->

	</middle>

	<back>
		<references>

			<reference anchor="KEYWORDS">
				<front>
					<title>Key words for use in RFCs to indicate Requirement Levels</title>
					<author initials="S." surname="Bradner"/>
					<date month="March" year="1997"/>
				</front>
				<seriesInfo name="BCP" value="14"/>
				<seriesInfo name="RFC" value="2119"/>
			</reference>

			<reference anchor="RFC4861">
				<front>
					<title>Neighbor Discovery for IP version 6 (IPv6)</title>
					<author initials="T." surname="Narten"/>
					<author initials="E." surname="Nordmark"/>
					<author initials="W." surname="Simpson"/>
					<author initials="H." surname="Soliman"/>
					<date month="September" year="2007"/>
				</front>
				<seriesInfo name="RFC" value="4861"/>
			</reference>

<!--
			<reference anchor="MIF_PRACTICES">
				<front>
					<title>Curent Practices for Multiple-Interface Hosts</title>
					<author initials="M." surname="Wasserman"/>
					<author initials="P." surname="Seite"/>
					<date month="November" year="2011"/>
				</front>
				<seriesInfo name="RFC" value="6419"/>
			</reference>
-->

		</references>

<!--
		<section title="Appendixes">
			<t>IF ANY</t>
		</section>
-->

	</back>

</rfc>
