<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-v6ops-pdhost-02.txt"
     ipr="trust200902" updates="">
  <front>
    <title abbrev="Prefix Delegation for Hosts">IPv6 Prefix Delegation for
    Hosts</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>Boeing Research &amp; Technology</organization>

      <address>
        <postal>
          <street>P.O. Box 3707</street>

          <city>Seattle</city>

          <region>WA</region>

          <code>98124</code>

          <country>USA</country>
        </postal>

        <email>fltemplin@acm.org</email>
      </address>
    </author>

    <date day="27" month="June" year="2016"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>IPv6 prefixes are typically delegated to requesting routers which
      then use them to number their downstream-attached links and networks.
      The requesting router then acts as a router between the
      downstream-attached hosts and the upstream provider network, and can
      also act as a host under the weak end system model. This document
      considers the case when the "requesting router" is actually a simple
      host, and receives a delegated prefix that it can use for
      multi-addressing purposes. The host does not connect any
      downstream-attached networks, and uses the prefix solely for its own
      multi-addressing purposes.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>IPv6 provides a prefix delegation service using the Dynamic Host
      Configuration Protocol for IPv6 (DHCPv6) <xref target="RFC3315"/>. Using
      DHCPv6 Prefix Delegation (PD) <xref target="RFC3633"/>, a requesting
      router asks for a prefix from a delegating router. When the prefix is
      delegated, the requesting router sub-delegates the prefix to its
      downstream-attached links via one or more "LAN" interfaces. The
      requesting router then acts as a router between hosts on the LAN
      interfaces and the upstream provider network (i.e., the "WAN"
      interface), and can also act as a host under the weak end system model
      <xref target="RFC1122"/>. This document considers the case when the
      "requesting router" is actually a simple host, and receives a prefix
      delegation as if it were a router. The host need not have any LAN
      interfaces, and can use the prefix solely for its own multi-addressing
      purpose.</t>
    </section>

    <section anchor="minencaps" title="Multi-Addressing">
      <t>IPv6 allows for assignment of multiple addresses to a single
      interface. <xref target="I-D.ietf-v6ops-host-addr-availability"/>
      discusses options for multi-addressing as well as use cases where
      multi-addressing may be desirable. Multi-addressing options include
      Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862"/> or
      stateful DHCPv6 address delegation <xref target="RFC3315"/>, as well as
      assignment of multiple addresses from a delegated prefix.</t>

      <t>SLAAC and DHCPv6 address delegation typically obtain addresses from
      an on-link prefix configured on the link over which the addresses are
      obtained. When this happens, the address recipient is obliged to use
      Multicast Listener Discovery (MLD) to join the appropriate
      solicited-node multicast group(s) and the Duplicate Address Detection
      (DAD) algorithm <xref target="RFC4862"/> to ensure that no other node on
      the link configures a duplicate address. Alternatively, address
      delegation from a delegated prefix can be used by a node under either
      the weak or strong end system models <xref target="RFC1122"/>. In that
      case, the MLD/DAD procedure is not necessary, since the prefix has been
      delegated to the node for its own exclusive use and the prefix is not
      assigned to the link over which the prefix was obtained.</t>
    </section>

    <section anchor="whentoinsert" title="Multi-Addressing Alternatives">
      <t>When a node receives a prefix delegation, it has many alternatives
      for the way in which it can provision the prefix. <xref
      target="RFC7278"/> discusses alternatives for provisioning a prefix
      obtained by a User Equipment (UE) device under the 3rd Generation
      Partnership Program (3GPP) service model. This document considers the
      more general case when the node receives a prefix delegation in which
      the prefix is delegated for the exclusive use of the prefix
      recipient.</t>

      <t>When the node receives the prefix (e.g., a /64), it can sub-delegate
      the prefix to its LAN interfaces and configure multiple addresses for
      itself on a LAN interface. The node uses link-local-only addressing on
      the WAN interface, and configures a default route that points to a
      router on the WAN link. The node can then act as both a host for its own
      applications and a router for any downstream-attached hosts. This
      approach is often known as the "tethered" configuration.</t>

      <t>When the node does not have any LAN interfaces, it may still wish to
      obtain a prefix solely for multi-addressing purposes. In a first
      alternative, the node can receive the prefix acting as a requesting
      router over the WAN interface but then assign the prefix to an internal
      virtual interface (e.g., a loopback interface) and assign one or more
      addresses taken from the prefix to the virtual interface. In that case,
      applications on the node can use the assigned addresses according to the
      weak end system model.</t>

      <t>In a second alternative, the node can receive the prefix as a
      requesting router over the WAN interface but then assign the prefix to a
      loopback interface and assign one or more addresses taken from the
      prefix to the WAN interface. In that case, applications on the node can
      use the assigned addresses according to the strong end system model.</t>

      <t>In both of these latter two cases, the node acts as a host internally
      even though it behaves as a router from the standpoint of prefix
      delegation and neighbor discovery over the WAN interface. The host can
      configure as many addresses for itself as it wants.</t>
    </section>

    <section anchor="dad" title="MLD/DAD Implications">
      <t>When a node configures addresses for itself using either SLAAC or
      DHCPv6 address delegation from a prefix that is on-link on the WAN
      interface, the node performs MLD/DAD by sending multicast messages to
      test whether another node that configures a duplicate address is on the
      link. When there are many such addresses and/or many such nodes, this
      could result in substantial multicast traffic that affects all nodes on
      the link.</t>

      <t>When a node configures addresses for itself using a delegated prefix,
      the node can configure as many addresses as it wants but does not
      perform MLD/DAD for any of the addresses over the WAN interface. This
      means that arbitrarily many addresses can be assigned without having any
      multicast messaging over the WAN link that could disturb other nodes.
      Note however that nodes that assign the addresses directly to the WAN
      interface must be capable of disabling MLD/DAD on the WAN interface,
      i.e., they must set DupAddrDetectTransmits to zero <xref
      target="RFC4862"/>.</t>
    </section>

    <section anchor="ipv6nd" title="IPv6 Neighbor Discovery Implications">
      <t>The node acts as a simple host to send Router Solicitation messages
      over the WAN interface the same as described in Section 4.2 of <xref
      target="RFC7084"/>.</t>

      <t>In order to maintain the appearance of a router (i.e., even though it
      is acting as a simple host), the node sets the "Router" flag to TRUE in
      any Neighbor Advertisement messages it sends. This ensures that the
      "isRouter" flag in the neighbor cache entries of any neighbors remains
      TRUE.</t>

      <t>The node initially has only a default route pointing to a router on
      the WAN link. This means that packets sent over the node's WAN interface
      will initially go through a default router even if there is a better
      first-hop node on the link. In that case,a Redirect message can update
      the node's neighbor cache, and future packets can take the more direct
      route without disturbing the default router. The Redirect can apply
      either to a singleton destination address, or to an entire destination
      prefix as described in AERO <xref target="I-D.templin-aerolink"/>.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document introduces no IANA considerations.</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>This work was motivated by recent discussions on the v6ops list. Mark
      Smith pointed out the need to consider MLD as well as DAD for the
      assignment of addresses to interfaces.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.0791"?>

      <?rfc include="reference.RFC.2460"?>

      <?rfc include="reference.RFC.3315"?>

      <?rfc include="reference.RFC.3633"?>

      <?rfc include="reference.RFC.7278"?>

      <?rfc include="reference.RFC.1122"?>

      <?rfc include="reference.RFC.4861"?>

      <?rfc include="reference.RFC.4862"?>

      <?rfc include="reference.RFC.7084"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.templin-aerolink"?>

      <?rfc include="reference.I-D.ietf-v6ops-host-addr-availability"?>
    </references>
  </back>
</rfc>
