<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" >
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3756 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml">
<!ENTITY RFC3971 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC4861 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6059 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6059.xml">
<!ENTITY MCAST-NOT-EFFICIENT PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.vyncke-6man-mcast-not-efficient.xml'>
<!ENTITY ND-M2M PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.garneij-6man-nd-m2m-issues'>
<!ENTITY RESILIENT-RS PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-resilient-rs.xml'>
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>

<rfc category="std" ipr="trust200902" updates="4861,6059"
     docName="draft-ietf-6man-rs-refresh-02">

  <front>
    <title abbrev="Optional RS/RA Refresh">
      IPv6 Neighbor Discovery Optional RS/RA Refresh
    </title>

    <author initials="E" surname="Nordmark" fullname="Erik Nordmark">
      <organization>Arista Networks</organization>
      <address>
	<postal>
	  <street></street>
	  <city>Santa Clara, CA</city>
	  <country>USA</country>
	</postal>
	<email>nordmark@acm.org</email>
      </address>
    </author>

    <author fullname="Andrew Yourtchenko" initials="A" surname="Yourtchenko">
      <organization>Cisco</organization>
      <address>
        <postal>
      <street>7a de Kleetlaan</street>
      <city>Diegem</city>
      <region>1831</region>
<!-- <code/> -->
      <country>Belgium</country>
        </postal>
      <phone>+32 2 704 5494</phone>
<!-- <facsimile/> -->
      <email>ayourtch@cisco.com</email>
<!-- <uri/> -->
      </address>
    </author>

    <author fullname="Suresh Krishnan" initials="S" surname="Krishnan">
      <organization>Ericsson</organization>
      <address>
	<postal>
	  <street>8400 Decarie Blvd.</street>
	  <city>Town of Mount Royal, QC</city>
	  <country>Canada</country>
	</postal>
	<phone>+1 514 345 7900 x42871</phone>
	<email>suresh.krishnan@ericsson.com</email>
      </address>
    </author>

    <date month="Oct" year="2016"/>
    <area>Internet</area>
    <workgroup>6man WG</workgroup>
    <keyword>6MAN</keyword>
    <keyword>IPv6</keyword>

    <abstract>
      <t>IPv6 Neighbor Discovery relies on periodic multicast Router Advertisement messages to update timer values and to distribute new information (such as new prefixes) to hosts. On some links the use of periodic multicast messages to all host becomes expensive, and in some cases it results in hosts waking up frequently. Many implementations of RFC 4861 also use multicast for solicited Router Advertisement messages, even though that behavior is optional.</t>

<t>This specification provides an optional mechanism for hosts and routers where instead of periodic multicast Router Advertisements the hosts are instructed (by the routers) to use Router Solicitations to request refreshed Router Advertisements. This mechanism is enabled by configuring the router to include a new option in the Router Advertisement in order to allow the network administrator to choose host behavior based on whether periodic multicast are more efficient on their link or not. The routers can also tell whether the hosts are capable of the new behavior through a new flag in the Router Solicitations.</t>
    </abstract>
  </front>

  <middle>

<section title="Introduction">
  <t>IPv6 Neighbor Discovery <xref target="RFC4861"/> was defined at a time when local area networks had different properties than today. A common link was the yellow-coax shared wire Ethernet, where a link-layer multicast and unicast worked the same - send the packet on the wire and the interested receivers will pick it up. Thus the network cost (ignoring any processing cost on the receivers that might not completely filter out Ethernet multicast addresses that they did not want) and the reliability of sending a link-layer unicast and multicast was the same. Furthermore, the hosts at the time was always on and connected. Powering on and off the workstation/PC hosts at the time was slow and disruptive process.</t>

  <t>Under the above assumptions it was quite efficient to maintain the shared state of the link such as the prefixes and their lifetimes using periodic multicast Router Advertisement messages. It was also efficient to use multicast Neighbor Solicitations for address resolution as a slight improvement over the broadcast use in ARP. And finally, checking for a potential duplicate IPv6 address using multicast was efficient and natural.</t>

  <t>There are still links, such a satellite links, where periodic multicast advertisements is the most efficient and reliable approach to keep the hosts up to date. However other links have different performance and reliability for multicast than for unicast (see for instance <xref target="I-D.vyncke-6man-mcast-not-efficient" /> which discusses WiFi links). On some of those links the performance and reliability is dependent on the direction e.g., with host to network multicast having the same characteristics as unicast, but network to host being different. Cellular networks which employ paging and support sleeping hosts have different issues (see e.g., <xref target="I-D.garneij-6man-nd-m2m-issues" /> that would benefit from having the hosts wake up and request information from the routers instead of the routers periodically multicasting the information.</t>

  <t>Since different links types and deployments have different needs, this specification provides mechanism by which the routers can determine whether all the hosts support the RS refresh, and the hosts only employ the RS refresh when instructed by the routers using an option in the Router Advertisement.</t>

  <t>The operator retains the option to use unsolicited multicast Router Advertisement to announce new or removed information. That can be useful for uncommon cases while allowing using a higher refresh time for normal network operations.</t>

  <t>Hosts that sleep without waking up due to multicast Router Advertisements need to send a RS refresh when they wake up in order to receive configuration changes that took place while the host was sleeping.</t>

  <t>The specification does not assume that all hosts on the link implement the new capability. As soon as there are router(s) on a link which supports these optimizations, then the updated hosts on the link can sleep better, while co-existing on the same link with unmodified hosts.</t>

</section>

<section title="Goals and Requirements">
  <t>The key goal is to allow the operator to choose whether RS refresh is more efficient than periodic multicast RAs, while preserving the timely and scalable reconfiguration capabilities that a periodic RA model provides.</t>

  <t>The approach should allow for hosts that sleep on a schedule i.e., that do not wake up due to unsolicited RA messages.</t>

  <t>In general a link can have multiple routers hence the RS messages should be multicast to find new routers. But for networks which do not there operator should be able to choose unicast RS behavior.</t>

  <t>In addition, an operator might want to be notified whether the link includes hosts that do not support the new mechanism. Potential router implementations can react dynamically to that information, or can log events to system management when hosts appear which do not implement this new capability.</t>

  <t>The assumption is that host which implement this specification also implement <xref target="I-D.ietf-6man-resilient-rs"/> as that ensures resiliency to packet loss.</t>
 
</section>

<section title="Definition Of Terms">
  <t>The keywords "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 title="Protocol Overview">
  <t>The hosts include a new flag in the Router Solicitation message, which allows the routers to report to system management whether there are hosts that do not support the RS refresh on the link.</t>

  <t>If the network administrator has configured the routers to send the new Refresh Time option, then the option will be included in all the Router Advertisements. This option includes the time interval when the hosts should send Router Solicitations refresh messages.</t>

  <t>The host maintains the value of the Refresh Time option (RTO) by recording it in the default router list. A value of zero can be used to indicate that a router did not include a Refresh Time option.</t>

  <t>The host calculates a timeout after it has received a RTO - either per router or per link. If it is maintained per link then the host SHOULD use the minimum Refresh Time it has received from the routers on the link. The timeout is a random value uniformly distributed between 0.5 and 1.5 times the Refresh Time value (in order to avoid synchronization of the timers across hosts <xref target="SYNC"/>.) When this timer fires the host sends one Router Solicitation.</t>
</section>

<section title="New Neighbor Discovery Flags and Options">

  <t>This specification introduces a new option used in the RAs which both indicates that the router can handle RS refresh by immediately responding with a unicast RA, and a flag for the RS that indicates to the router that the host will do RS refresh if the router so wishes.</t>

<section title="Introducing a Router Solicitation Flag">

<t>A node which implements this specification sets the R flag in all the Router Solicitation messages it sends. That allows the router to determine whether there are legacy hosts on the link.</t>
  <figure>
    <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|                          Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
  </figure>
  <t>New fields:
  <list style='hanging' hangIndent='15'>
    <t hangText="R-flag:"> When set indicates that the sending node is capable of doing unicast RS refresh.</t>
    <t hangText="Reserved:"> Field is reduced from 32 bits to 31 bits.
    It MUST be initialized to zero by the sender and MUST be ignored by the
    receiver.</t>
  </list>
  </t>
</section>

<section title="Refresh Time option">

<t>A router which implements this specification can be configured to instruct hosts to use RS refresh. When the operator configures this mode of operation, then the router MUST include this new option in the RA. If the operator has a single router (or single VRRP router) on the link, then the operator MAY set the Unicast flag in the option.</t>
  <figure>
    <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length=1    |          Refresh Time         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|                          Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
  </figure>
  <t>Fields:
  <list style='hanging' hangIndent='15'>
    <t hangText="Type:"> TBD ND option code value (IANA)</t>
    <t hangText="Length:"> 8-bit unsigned integer.
    The length of the option (including the type and length fields) in units of 8 bytes. The value 0 is invalid. Value is 1 for this option.</t>
    <t hangText="Refresh Time:"> 16-bit unsigned integer.
    Units is seconds. The value zero is invalid and make the receiver ignore the option.</t>
    <t hangText="U-flag:"> 1 bit flag to indicate that the host should unicast the RS
    refresh.</t>
    <t hangText="Reserved:"> 31 bits. This field is unused.
    It MUST be initialized to zero by the sender and MUST be ignored by the
    receiver.</t>
  </list>
  </t>

</section>

</section>

<section title="Conceptual Data Structures">
  <t>In addition to the Conceptual Data structures in <xref target="RFC4861"/> a host records the received Refresh Time value and the Unicast flag in the default router list. It also maintains a timeout - either per link or per default router. If the timeout is per link it is set to the minimum of the received Refresh Time values.</t>

</section>

<section title="Host Behavior">
  <t>See Protocol Overview section above.</t>

  <t>A host implementing this specification SHOULD also implement <xref target="I-D.ietf-6man-resilient-rs"/>. That ensures that if there is packet loss and/or the periodic router advertisements are very infrequent, the host will always receive a timely RA as part of its initialization.</t>

  <t>If there is no RTO in the received Router Advertisements or there is an RTO with a zero Refresh Time, then the host behavior does not change. However, if RTOs start appearing in RAs after the initial RAs, the host SHOULD start performing RS refresh. As the last router that included RTO options time out from the default router list, the host SHOULD stop sending RS refresh messages.</t>

  <t>The host MUST join the all-nodes multicast address as in <xref target="RFC4861"/> since the routers MAY send multicast RAs for important changes.</t>

  <t>Some links might have routers with different configuration where some router includes RTO in the RA and others do not. Hosts MAY make the simplifying assumption that if any router on the link includes RTO then the host can use RS refresh to all the routers in the default router list. Also, the routers might advertise different Refresh Time, and hosts MAY use the minimum of the time received from any router that remains in the default router list, or use a separate timer for each router in the default router list. Note that <xref target='consistency'/> says that routers SHOULD report such inconsistencies to system management. </t>

  <t>A RTO option with a Refresh Time value of zero is silently ignored, that is, the RA is handled the same way as if it did not contain an RTO option.</t>

  <t>If the U-flag is zero for at least one of the routers in the default router list, then the host will send each refresh RS to the all-routers multicast address. Otherwise the host will unicast the RS refresh to each router in the default router list. The host can either maintain the Refresh Time and Unicast flag per router or per link. If they are maintained per router then the host MUST NOT multicast an RS for every default router list entry but instead multicast once when the minimum (across the default router list for the interface) Refresh Time expires. If they are maintained per link, then the host would determine an effective Unicast bit for the link; set if all the routers which sent RTO set the Unicast bit.</t>

  <t>If there is no response to a refresh RS, the host follows the same retransmit behavior as in resilient-rs <xref target="I-D.ietf-6man-resilient-rs"/>.</t>

  <section title="Sleep and Wakeup">
    <t>The protocol allows the sleepy nodes to complete its sleep schedule without waking up due to multicast Router Advertisement messages and the host is not required to wake up solely for the purposes of performing RS refresh. Such a host SHOULD send a RS refresh upon wakeup even if the Refresh Time has not yet expired, in order to receive any updated RA information.</t>

<t>Hosts that do wake up due to multicast RAs only needs to perform a refresh on wakeup if the Refresh timeout has expired while the host was sleeping.</t>
  </section>

  <section title="Movement">

    <t>When a host wakes up or thinks it might have moved to a different link (new L2 association, lost and required L2 connectivity, etc) it can combine DNA (Detecting Network Attachment - DNA <xref target="RFC6059"/>), NUD, and refreshing its prefixes etc by sending a unicast RS to each of its existing RTO default router(s). If it receives unicast RA from a router, then it can mark the router as REACHABLE.</t>

    <t>Note that DNA specifies using NS messages since many IPv6 routers delay (and multicast) solicited RAs and DNA wants to avoid that delay. Routers which implement this specification and send RTO SHOULD unicast solicited RAs, hence if a router included the RTO then the host can use RS for DNA without incurring additional delay. Thus the host would not need to use a unicast NS as part of DNA for RTO routers. For non-RTO routers the host MAY choose to use NS for DNA as in <xref target="RFC6059"/>.</t>

  </section>
</section>

<section title="Router Behavior">
  <t>See Protocol Overview section.</t>

  <t>A router implementing this specification (and including the RTO in the RAs) SHOULD also respond to unicast RS messages (that do not have an unspecified source address) with unicast RAs. If a RS message has an unspecified source address then the router MAY respond with a RA unicast at layer 2 (sent to the link-layer source address of the RS), or it MAY follow the rate-limited multicast RA procedure in <xref target="RFC4861"/>.</t>

  <t>The RECOMMENDED default configuration for routers is to have RTO disabled. When RTO is enabled the RECOMMENDED default configuration is to have the Unicast flag disabled.</t>

  <section title="Router and/or Interface Initialization">
    <t>This specification does not change the initialization procedure. Thus a router multicasts some initial Router Advertisements (MAX_INITIAL_RTR_ADVERTISEMENTS) at system startup or interface initialization as specified in <xref target="RFC4861"/> and its updates.</t>
  </section>

  <section title="Periodic Multicast RA for unmodified hosts" anchor='no-periodic'>
    <t>By default a router MUST send periodic multicast RAs as specified in <xref target="RFC4861"/>. A router can be configured to omit those, which can be used in particular deployments. If they are omitted, then there MUST be a mechanism to prevent or detect the existence of unmodified hosts on the link. That could be performed at deployment time (e.g., only hosts which are known to support RTO are configured with the layer 2 security keys), or the routers could either detect any RSs which do not include the R-flag and report this to system management or dynamically enable periodic multicast RAs when observing at least one RS without the R-flag.</t>

    <t>Note that such dynamic detection of "legacy" hosts is not bullet proof, in particular when there is packet loss on the link. If a host does not implement resilient RS <xref target="I-D.ietf-6man-resilient-rs"/>, then the host might receive a multicast RA (from router initialization or the periodic multicast RAs) without the router ever receiving a RS from the host. Such a host would function as long as the routers are sending periodic multicast RAs. However, hosts without resilent RS do not operate well in the presence of packet loss. They might be without service (no default router and no prefixes) for one or more multiples of the RA advertisement interval (MaxRtrAdvInterval), which currently can be as high as 30 minutes.</t>

  </section>

  <section title="Unsolicited RAs to share new information">
    <t>When a router has new information to share (new prefixes, prefixes that should be immediately deprecated, etc) it MAY multicast up to MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements.</t>

    <t>On links where multicast is expensive the router MAY instead unicast up to MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements to the hosts in its neighbor cache.</t>

    <t>Note that such new information is not likely to reach hosts sleeping on a schedule until those hosts refresh by sending a RS. However, as such hosts are recommended to send a RS refresh when they wake up, they will receive the updated information and not use the potentially stale information to send packets.</t>

  </section>

  </section>

  <section title="Router Advertisement Consistency" anchor='consistency'>
    <t>The routers follows section 6.2.7 in <xref target="RFC4861"/> by receiving RAs from other routers on the link. In addition to the checks in that section, the routers SHOULD verify that the RTO have the same Refresh Time, and report to system management if they differ. While the host will pick the lowest time and operate correctly, it is not useful to use different Refresh Times for different routers.</t>
  </section>

<section title="Security Considerations">
  <t>These optimizations are not known to introduce any new threats against Neighbor Discovery beyond what is already documented for IPv6 <xref target="RFC3756"/>.</t>

  <t>Section 11.2 of <xref target="RFC4861"/> applies to this document as well. </t>

  <t>The mechanisms in this document work with SeND <xref target="RFC3971"/>.</t>

</section>

<section title="IANA Considerations">

  <t>A new flag (R-flag) in the Router Solicitation message has been introduced by carving out a bit from the Reserved field. There is currently no IANA registry for RS flags. Perhaps one should be created?
  </t>

  <t>This document needs a new Neighbor Discovery option type for the RTO.</t>
</section>

<section title="Acknowledgements">
  <t>The original idea came up in a discussion with Suresh Krishnan.
  Comments from Samita Chakrabarti, Lorenzo Colitti, and Erik Kline have helped 
  improve the document.
  </t>

  <t>This document has been discussed in the efficient-nd design team.
  </t>
</section>

<section title="Change Log">
  <t>Changes since the draft-nordmark-6man-rs-refresh-00 version of the draft:
    <list style='symbols'>
      <t>Removed any suggestion that periodic RAs would not be needed. The remain required.</t>
      <t>Made Refresh Time zero be reserved and RTOs with this value ignored by
      the receiver.</t>
      <t>Removed notion that all-ones refresh time means infinite lifetime. It now means 65535 seconds.</t>
      <t>Changed default to be multicast RS refresh, with the option to specify unicast in the RTO. This enables discovering new routers on the link.</t>
      <t>Clarified the normative behavior for hosts that sleep on a schedule.</t>
      <t>Clarified the updated DNA behavior.</t>
      <t>Editorial fixes.</t>
    </list>
  </t>
</section>

</middle>


<back>
<references title="Normative References">
&RFC2119;
&RFC2460;
&RFC4861;
&RESILIENT-RS;
</references>

<references title="Informative References">
&RFC3756;
&RFC3971;
&RFC6059;
&MCAST-NOT-EFFICIENT;
&ND-M2M;
      <reference anchor="SYNC"
                 target="http://ee.lbl.gov/papers/sync_94.pdf">
        <front>
          <title>The Synchronization of Periodic Routing Messages</title>
	  <author fullname="Sally Floyd" initials="S" surname="Floyd"/>
	  <author fullname="Van Jacobson" initials="V" surname="Jacobson"/>
          <date year="April 1994"/>
        </front>
        <seriesInfo name="IEEE/ACM Transactions on Networking" value=""/>
      </reference>
</references>

</back>
</rfc>


