<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-6man-rs-refresh" target="https://datatracker.ietf.org/doc/html/draft-ietf-6man-rs-refresh-02">
   <front>
      <title>IPv6 Neighbor Discovery Optional RS/RA Refresh</title>
      <author initials="E." surname="Nordmark" fullname="Erik Nordmark">
         <organization>Arista Networks</organization>
      </author>
      <author initials="A." surname="Yourtchenko" fullname="Andrew Yourtchenko">
         <organization>Cisco</organization>
      </author>
      <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
         <organization>Ericsson</organization>
      </author>
      <date month="October" day="31" year="2016" />
      <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.

   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>
   <seriesInfo name="Internet-Draft" value="draft-ietf-6man-rs-refresh-02" />
   
</reference>
