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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
    docName="draft-lemon-smear64-00"
    category="std">

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

<front>

<title abbrev="Smear64">The Smear64 Mechanism</title>

<author initials="T" surname="Lemon" fullname="Ted Lemon">
<organization>Nominum, Inc.</organization>
<address>
<postal>
<street>800 Bridge Parkway</street>
<city>Redwood City</city>
<region>California</region>
<country>United States of America</country>
<code>94065</code>
</postal>
<phone>+1 650 381 6000</phone>
<email>ted.lemon@nominum.com</email>
</address>
</author>

<date month="April" year="2017" />

<abstract>
  <t>
    This document describes a way of sharing a /64 prefix among multiple links in a leaf network
    scenario, such as a home network or small office network.  This provides a way to provide
    global addressing to all nodes on such a network, allowing for end-to-end communication
    without address translation.
  </t>
</abstract>

</front>
<middle>
<section anchor="Intro" title="Introduction">
  <t>
    The smear64 protocol provides a means for addressing the use case where an ISP provides only a
    single /64 to a CE router.  In this case, if the network behind the router has more than one
    link, there are only two ways to provide addressing on the local network:
    <list style="symbols">
      <t>Advertise the /64 on every link and provide a means for preventing duplicate addresses
      across links, and a means for routing between hosts on the same prefix but on different
      links.</t>
      <t>Number the local network with a ULA and use NAT66 to provide addressing.</t>
    </list>
  </t>
  
  <t>
    The NAT66 solution feels attractive in this case because it seems simple, but in practice the
    two solutions are not really very different.  The requirements for the NAT66 solution are as
    follows:
    <list style="bullets">
      <t>Generate and maintain a ULA for the CP network.</t>
      <t>Provide a means for allocating prefixes for each link on the CP network.</t>
      <t>Discover devices that wish to communicate externally by noticing packets from those
      devices routed to global addresses.</t>
      <t>Maintain a table of such devices, mapping between ULAs and addresses allocated from the
      ISP-provided /64.</t>
      <t>Maintain an in-kernel translator on the router to translate between ULAs and GUAs.</t>
    </list>
  </t>
  <t>
    To solve the problem of sharing a /64 across multiple links, the following need to be done:
    <list style="bullets">
      <t>Announce the shared /64 on all links, with the L bit (See section 4.6.2 of <xref
      target="RFC4861"/>) clear.</t>
      <t>Each link has a single router responsible for advertising
      the shared /64 on that link, so that if two routers are connected to the same link, only
      one announces the prefix.  That router will also be responsible for detecting nodes using
      addresses on the /64 on that link, and maintaining state in the global neighbor table for
      that link.</t>
      <t>Every router must listen for router solicitation messages.  When a
      router solicitation message comes from an address on the advertised /64 that has not been
      seen before, that address, and the link on which it was received, is recorded in a global
      neighbor table, which is quickly propagated amongs all routers on the CP network.</t>
      <t>Every router must listen for neighbor solicitation messages.  When a neighbor
      solicitation message is received for an address which appears in the global neighbor
      table, the router checks to see if the two addresses are on the same link.  If they are
      not, the router responds to the neighbor solicitation message.</t> <t>In addition, when a
      neighbor solicitation comes from a source address on the shared /64 that is not in the
      global neighbor table, it is added to the global neighbor table.</t> <t>Addresses in the
      global neighbor table are maintained as described in section 7.3 of <xref
      target="RFC4861"/>.  Unreachability detection is performed by the router responsible for
      doing unreachability detection on the link to which the node had been communicating.</t>
      <t>When a router receives a message with a destination address on the shared /64, it
      consults the global neighbor table to deliver it.  If the source and destination addresses
      are on the same link, the router sends a redirect to the source of the message, as well as
      [instead of?] forwarding it.</t>
    </list>
  </t>
  <t>
    The difference between these two solutions is that one requires a protocol for maintaining the
    global neighbor table.  This can be done using HNCP <xref target="RFC7788"/>.  HNCP can also
    be used to elect the router responsible for doing node discovery on that link.
  </t>
</section>

</middle>

<back>

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

</back>
</rfc>

  
