<?xml version="1.0" encoding="iso-8859-1" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
    docName="draft-pfister-6man-sadr-ra-00"
    updates="4191"
    category="std">

<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="Source Address Dependent RIO">Source Address Dependent Route Information Option for Router Advertisements</title>

<author initials="P" surname="Pfister" fullname="Pierre Pfister">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Paris</city>
<country>France</country>
</postal> 		
<email>pierre.pfister@darou.fr</email>
</address>
</author>

<date month="February" year="2015" />

<keyword>IPv6</keyword>
<keyword>ra</keyword>
<keyword>RFC4191</keyword>
<keyword>RIO</keyword>
<keyword>sadr</keyword>

<abstract>
    
    <t>This document defines the Source Address Dependent Route Information option for Router Advertisements, enabling source address dependent routes to be installed in hosts by neighboring routers. It also adds a new flag to the existing Route Information option for backward compatibility purposes.</t>

</abstract>

</front>
<middle>
    
    
<section anchor="intro" title="Introduction">
    <t>Hosts may have multiple non-link-local addresses, possibly provided by different routers located on one or multiple links. In such situations, hosts must make sure packets with a given source address are sent to the right next-hop router. Failing in selecting the right next-hop router may, at best, induce sub-optimal routing and, at worst, cause the packet to be dropped (<xref target="RFC2827"/>). Rules 5 and 5.5 from the default address selection algorithm <xref target="RFC6724"/> make sure that, once the next-hop is chosen, care is taken to pick the right source address. Nevertheless, these rules may fail in some situations, e.g., when the same prefix is advertised on the same link by different routers. Additionally, they don't handle situations where the application picks the source-address before sending the packet.</t>
    
    <t>This document defines the Source Address Dependent Route Information Option for Router Advertisements <xref target="RFC4861"/>, enabling source address dependent routes to be installed in hosts by neighboring routers. It also adds a new flag to the Route Information Option meaning that the option may be ignored by hosts implementing this specification.</t>
</section>
    
<section anchor="SADRIO" title="Source Address Dependent Route Information Option">
    
        <t>This section defines a new Router Advertisement option called the Source Address Dependent Route Information option. Its use is similar to the Route Information option defined in <xref target="RFC4191"/> but also includes additional source prefix fields, allowing source address dependent routes to be installed on hosts receiving the Router Advertisement.</t>
    
        <figure title="Source Address Dependent Route Information Option">
            <preamble></preamble><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     |   Src Length  |   Dst Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Route Lifetime                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resvd|Prf|Resvd|        Source Prefix (Variable Length)        |
+-+-+-+-+-+-+-+-+                                               +
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Destination Prefix (Variable Length)            |
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            </artwork><postamble></postamble>
        </figure>

        <t>
        <list style="hanging">
            <t hangText="Type:">To be defined by IANA.</t>
            <t hangText="Length:">The length of the option (including the Type and Length fields) in units of 8 octets. It ranges from 2 to 6.</t>
            <t hangText="Src Length:">The number of significant bits in the Source Prefix field.</t>
            <t hangText="Dst Length:">The number of significant bits in the Destination Prefix field.</t>
            <t hangText="Route Lifetime:">Time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity.</t>
            <t hangText="Resvd (Reserved):">Bits reserved for futur use. They MUST be set to zero by the sender and ignored by the receiver.</t>
            <t hangText="Prf (Route Preference):">The route preference as specified in <xref target="RFC4191"/>. When the Reserved value (10) is received, the option MUST be ignored.</t>
            <t hangText="Source Prefix:">The source prefix significant bits padded to the next 8-bits boundary.</t>
            <t hangText="Destination Prefix:">The destination prefix significant bits padded to the next 64-bits boundary.</t>
        </list>
        </t>
        
        <t>Note: The alignment is a bit awkward. I am not sure reserving 24 bits for the purpose of aligning the source prefix would be helpful. The destination prefix cannot be aligned neither due to the variable length of the source prefix, unless we add unused bytes in between. Propositions are welcome concerning the best format for this option.</t>
</section>

<section anchor="RIOflag" title="Route Information Option ignore flag">
    
    <t>
        This document adds the Ignore flag to the Route Information option specified in <xref target="RFC4191"/>. It is used in order to configure type C hosts with more specific routes which will be ignored by hosts implementing this specification. Most of the time, such options with the I bit set will be used in conjunction with Source Address Dependent Route Information options including the same or a similar destination prefix.
    </t>
    
    <figure title="Route Information Option">
        <preamble>The option is re-defined with an additional flag.</preamble><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     | Prefix Length |I|Rsv|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Route Lifetime                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Prefix (Variable Length)                    |
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        </artwork><postamble></postamble>
    </figure>
    
    <t>
        <list style="hanging">
            <t hangText="I flag:">Ignore flag. When this flag is set, the option MUST be ignored.</t>
            <t hangText="Other fields:">No changes (see <xref target="RFC4191"/>).</t>
        </list>
    </t>
    
</section>

<section anchor="host" title="Host Behavior">
    
    <t>Hosts implementing this specification MUST behave similarly to type C hosts as specified in <xref target="RFC4191"/>, unless stated otherwise in this section.</t>
    
    <t>Hosts implementing this specification MUST use a Routing Table with source address dependent entries. Such entries have a source prefix, a destination prefix, a preference value, a lifetime, an interface and a next-hop router address.</t>
    
    <t>When sending a packet, hosts MUST select the next-hop router based on the usual source address dependent routing algorithm, i.e., by picking the matching entry with, by order of precedence:
        <list>
            <t>The longest destination address match.</t>
            <t>The longest source address match.</t>
            <t>The highest route preference value.</t>
        </list>
        In case of a tie, hosts MAY either pick one entry or use load-sharing techniques.
    </t>
    
    <section anchor="rSADRIO" title="Receiving Source Address Dependent Route Information option">
    
    <t>
        When receiving a Source Address Dependent Route Information option, a host MUST look for an existing routing entry with:
        <list style="numbers">
            <t>The same source prefix.</t>
            <t>The same destination prefix.</t>
            <t>The next-hop router address equal to the source address of the received Router Advertisement.</t>
            <t>The outgoing interface equal to the interface the Router Advertisement is received on.</t>
        </list>
    </t>
    
    <t>If no routing entry is found and the Route Lifetime is not null, insert a routing entry with the given source prefix, destination prefix, route preference, having as next-hop the source address of the received Router Advertisement, on the interface receiving the packet. If the Route Lifetime is not infinity, set the routing entry timer to the Route Lifetime value.</t>
    <t>If a routing entry is found and the Route Lifetime is not null, cancel the associated timer. If the Route Lifetime is not infinity, set it to the Route Lifetime value. Finally, update the entry preference with the Route Preference value.</t>
    <t>If a routing entry is found and the Route Lifetime is null, remove the routing entry.</t>
    
    <t>If both destination and source prefixes specified by the option are ::/0, the router preference and route lifetime present in the option override the default router lifetime and default router preference present in the header of the Router Advertisement.</t>

    </section>
    
    <section anchor="rRIO" title="Receiving Route Information option">
    <t>
        When receiving a Route Information option, a host MUST behave as follows:
        <list>
            <t>If the I bit is set, ignore the option.</t>
            <t>Otherwise, act as when receiving a Source Address Dependent Route Information option with source prefix length set to zero.</t>
        </list>
    </t>
    </section>

</section>

<section anchor="router" title="Router Behavior">
    <t>Routers MAY send one or multiple Source Address Dependent Route Information options in their Router Advertisements.</t>
    
    <t>Routers MUST NOT send multiple Route Information options with the same Prefix (no matter what the Ignore flag value is) or multiple Source Address Dependent Route Information options with the same Source and Destination Prefixes. Additionally, routers MUST NOT send a Route Information option with the Ignore bit not set and a Source Address Dependent Route Information with the source length equal to zero if the Prefix from the Route Information option is equal to the Destination Prefix from the Source Address Dependent Route Information option.</t>
    
    <t>The Ignore bit is used to configure hosts implementing this specification differently from other types of hosts (A, B or C). Different combinations will result in different behaviors. For instance:
        <list>
        <t>
            When injecting a source address dependent route is desired, a Source Address Dependent Route Information option is sent in every RA. Depending on the context, a Route Information with the same prefix and the Ignore bit set MAY be sent as well in order to inject non source address dependent route into type C hosts. Obviously, Source Address Dependent Route Information options can be used to inject non-source dependent routes as well. This technique and the use of the Ignore bit allow type C hosts and hosts implementing this specification to be configured with independent routes.
        </t>
        <t>
            When injecting a non source address dependent route is desired, the router MAY either use a Route Information option with the Ignore flag not set, in which case type C hosts as well as hosts implementing this specification will be configured, or use a Source Address Dependent Route Information option with a source prefix ::/0, in which case type C hosts will not be configured.
        </t>
        </list>
    </t>
    <t>When a Source Address Dependent Route Information option is removed from the set of advertised options, the router SHOULD send multiple unsolicited Router Advertisements with the Route Lifetime set to zero.</t>
</section>

<section anchor="security" title="Security Considerations">
    <t>This document allows routers to configure neighboring hosts with source address dependent routing entries. Based on <xref target="RFC4191"/>, attackers can inject default routes to type A and B hosts as well as destination address dependent routes to type C hosts. The Source Address Dependent Route Information option adds the ability for attackers to inject even more specific routes, making attacks slightly harder to detect.</t>
</section>

<section title="IANA Considerations">
    <t>IANA is kindly asked to reserve a Router Advertisement option type to be used by the Source Address Dependent Route Information option.</t>
</section>

<section title="Acknowledgments">
    <t>The author would appreciate reviews and comments.</t>
</section>

</middle>

<back>

<references title="Normative References">
  <?rfc include="reference.RFC.4191.xml"?>
  <?rfc include="reference.RFC.4861.xml"?>
</references>

<references title="Informative References">
    <?rfc include="reference.RFC.2827.xml"?>
    <?rfc include="reference.RFC.6724.xml"?>
</references>

</back>
</rfc>
