<?xml version="1.0" encoding="US-ASCII"?>

<!--

NOTES:

    - Add "if you have no better ideas" host behavior recommendation for /64.

    - reduce ND for efficiency:

      https://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00
      https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01

    - Section 5.2.x about NS/NA behaviour

    - PIO-X subprefixes of other PIOs (X and non-X) are invalid

***

    - router's next hop has to be a link-local

    - router SHOULD ignore RSes from ::, in order to get the host to
      retransmit from link-local

***

    - Add section requesting IANA to create registry of PIO flags

-->

<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1122
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
  <!ENTITY RFC1918
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
  <!ENTITY RFC2119
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC3493
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3493.xml">
  <!ENTITY RFC3633
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
  <!ENTITY RFC3879
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3879.xml">
  <!ENTITY RFC4191
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
  <!ENTITY RFC4429
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
  <!ENTITY RFC4861
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
  <!ENTITY RFC5452
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5452.xml">
  <!ENTITY RFC5942
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5942.xml">
  <!ENTITY RFC4862
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
  <!ENTITY RFC6059
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6059.xml">
  <!ENTITY RFC6275
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
  <!ENTITY RFC6418
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6418.xml">
  <!ENTITY RFC7066
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7066.xml">
  <!ENTITY RFC7278
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7278.xml">
  <!ENTITY RFC7559
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7559.xml">
  <!ENTITY RFC7934
    SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7934.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes" ?>
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="exp"
     ipr="trust200902"
     updates="4861,6275"
     docName="draft-pioxfolks-6man-pio-exclusive-bit-02">

  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->


  <front>
    <title abbrev="IPv6 RA PIO eXclusive Flag"
      >IPv6 Router Advertisement Prefix Information Option eXclusive Flag</title>

    <author fullname="Erik Kline"
            initials="E." surname="Kline">
      <organization>Google Japan KK</organization>
      <address>
        <postal>
          <street>6-10-1 Roppongi</street>
          <street>Mori Tower, 44th floor</street>
          <city>Minato</city>
          <region>Tokyo</region>
          <code>106-6126</code>
          <country>JP</country>
        </postal>
        <phone></phone>
        <email>ek@google.com</email>
      </address>
    </author>

    <author fullname="Mikael Abrahamsson"
            initials="M." surname="Abrahamsson">
      <organization>T-Systems Nordic</organization>
      <address>
        <postal>
          <street>Kistagangen 26</street>
          <city>Stockholm</city>
          <country>SE</country>
        </postal>
        <email>Mikael.Abrahamsson@t-systems.se</email>
      </address>
    </author>

    <date/>

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>ipv6</keyword>
    <keyword>6man</keyword>
    <keyword>router</keyword>
    <keyword>advertisement</keyword>
    <keyword>prefix</keyword>
    <keyword>information</keyword>
    <keyword>option</keyword>
    <keyword>exclusive</keyword>

    <abstract>
      <t>
This document defines a new control bit in the IPv6 RA PIO flags octet
that indicates that the node receiving this RA is the exclusive receiver of
all traffic destined to any address within that prefix.
      </t>
      <t>
Termed the eXclusive flag (or "X flag"), nodes that recognize this can perform
some optimizations to save time and traffic (e.g. disable ND and DAD for
addresses within this prefix) and more immediately pursue the benefits of being
provided multiple addresses (vis. <xref target="RFC7934"/> section 3).
Additionally, network infrastructure nodes (routers, switches) can benefit by
minimizing the number of {link layer, IP} address pairs required to offer
network connectivity (vis. <xref target="RFC7934"/> section 9.3).
      </t>
      <t>
Use of the X flag is backward compatible with existing IPv6 standards compliant
implementations.
      </t>
    </abstract>
  </front>


  <middle>
    <section title="Introduction">
      <t>
This document defines a new control flag in the Internet Protocol version 6
(IPv6) Router Advertisement (RA) Prefix Information Option (PIO) flags octet
that indicates that the node receiving this RA is the exclusive receiver of
all traffic destined to any address with that prefix. Subject to the lifetime
constraints within the PIO, the receiving node effectively has exclusive
use of the prefix, and will be the next hop destination for the sending router,
and possibly other routers, for all traffic destined toward the prefix.
      </t>
      <t>
Termed the eXclusive flag (or "X flag"), nodes that recognize this can perform
some optimizations to save time and traffic (e.g. disable Neighbor Discovery (ND)
and Duplicate Address Detection (DAD) for addresses within this prefix) and more
immediately pursue the benefits of being provided multiple addresses
(vis. <xref target="RFC7934"/> section 3).
      </t>
      <t>
Additionally, network infrastructure nodes (routers, switches) can benefit by
minimizing the number of {link layer, IP} address pairs required to offer
network connectivity (vis. <xref target="RFC7934"/> section 9.3). A router,
for example, need not create any {link layer, IP} address pair entries for
IP address within a proffered exclusive-use prefix--it can reliably forward
all traffic to the network node to which it advertised the prefix. This solves
one potential link layer state exhaustion problem, i.e excessive number of
{link layer, IP address pairs}, using IP layer forwarding.
      </t>
      <t>
Use of the X flag is backward compatible with existing IPv6 standards compliant
implementations. <xref target="RFC4861"/>-compliant nodes that do not
understand the X flag are not negatively impacted.  They must ignore it, and
can process the PIO under existing standards, making use of the information
exactly as if the X flag were not set.
      </t>
    </section>

    <section anchor="motivation" title="Motivation">
      <t>
This work is motivated by the pursuit of two categories of benefits: modest
host and network side improvements in efficiency, and support for new
deployment architectures and address space use models.
      </t>

      <section title="Efficiency improvements">
        <t>
If a host knows it has exclusive use of a prefix it can perform some
optimizations to save time and traffic.  It can avoid ND on the receiving
interface for addresses within these prefixes.  Network interfaces can even
drop Neighbor Solicitations for these addresses on the receiving interface to
save power by not waking up more power-hungry CPUs.
        </t>
        <t>
Additionally, a host can save time by not performing DAD for addresses within
an exclusive-use prefix on the receiving interface.  A host that wanted, for
example, to use 2**64 unique IPv6 source addresses for DNS queries in order to
improve resilience against forged answers (as recommended in section 9.2 of
<eref target="RFC5452"/>), could do so without delaying each query from a
newly formed address.  A node could in theory implement the same strategy
using <eref target="RFC4429">Optimistic Duplicate Address Detection</eref>,
but it could be very unfriendly to the network infrastructure
(in terms of {link-layer, IP address} pair state)
to do so without this kind of explicit signal.
        </t>
        <t>
A host that recognizes the X flag might perform other traffic-saving
optimizations, like not attempt Multicast DNS in some cases, or avoid
trying to register addresses with sleep proxies.  Being the only host on
this link these may be of little benefit.
        </t>
      </section>

      <section title="New architectural possibilities">
        <t>
There are several initiatives that propose network side practices that provide
customer isolation, enhanced operational scalability, power efficiency, security
and other benefits in IPv6 network deployments. Some of these involve isolating
a host (or RA accepting client node) so that the host is the only node to
receive a specific prefix, including
          <list style="symbols">
            <t>
DHCPv6 Prefix Delegation to hosts
(<eref target="https://tools.ietf.org/html/draft-templin-v6ops-pdhost"/>), and
            </t>
            <t>
advertising a unique prefix per host via unique RAs.
(<eref target="https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host"/>).
            </t>
          </list>
        </t>
        <t>
Some architectures further isolate the host layers below IPv6, for improved
client node security.
       </t>
       <t>
Regardless of the specific level of isolation, the host can best make
choices about its use of a prefix exclusively forwarded to itself if the host
can be informed of the exclusivity.  (In the case of a DHCPv6 Prefix Delegation
the prefix can be assumed to be of exclusive use by the requesting node, in
accordance with the model in <xref target="RFC3633"/>.)  An implementation can,
for example, safely "bind to an IPv6 subnet" in the style of
<eref target="http://www.potaroo.net/ispcol/2016-09/subnetbind.html"/>, or
start <eref target="RFC7278">64sharing</eref>
(given a prefix of sufficient size).
       </t>
       <t>
This memo documents an additional flag in the IPv6 RA PIO that makes this
information explicit to receiving node.
        </t>
      </section>
    </section>

    <section title="Applicability statement"
             anchor="applicability">
      <t>
Use of the X flag in PIOs is only applicable to networks where the
architecture (i.e. serving infrastructure like routers, link-layer equipment,
et cetera) can collectively guarantee the following criteria are met:
        <list style="numbers">
          <t>
an RA containing a PIO with the X flag set MUST be delivered to
one and only target node (host) such that no two nodes can reasonably expect
exclusive access to the same prefix at the same time
          </t>
          <t>
any router advertising an RA containing a PIO with the X flag set
SHOULD be notified quickly when a node leaves the network
          </t>
        </list>
      </t>
      <t>
The first criterion ensures that the same exclusive use prefix is
not advertised to more than one host at a time (and hence no longer
"exclusive").

This implies that an allocated exclusive-use prefix must be tracked by the
issuing router for at least the minimum of (a) the lifetime of the recipient
node's continuous attachment to the network and (b) the lifetime of the
prefix itself in the PIO, if not longer.
      </t>
      <t>
The second criterion aims to help the prefix allocation
infrastructure reclaim unused prefixes quickly while also helping routers
drop (possibly with appropriate ICMPv6 errors) traffic that can no longer
be delivered.
      </t>
      <t>
It is expected that in practice this primarily describes networks where
the IPv6 infrastructure and the link-layer have a tight integration.
All point-to-point links meet these criteria (e.g. PPPoE and VPNs),
as does the 3GPP architecture <xref target="RFC7066"/> and some
IEEE 802.11 deployment architectures
(<eref target="https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host"/>).
      </t>
    </section>

    <section title="Terminology">
      <section title="Requirements Language">
        <t>
The key words "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">RFC 2119</xref>.
        </t>
      </section>

      <section title="Abbreviations">
        <t>
Throughout this document the following terminology is used purely for the
sake of brevity.
        </t>

        <section title="PIO-X">
          <t>
The term "PIO-X" is used to refer to a Prefix Information Option (PIO)
that has the X flag set.
          </t>
        </section>

        <section title="PIO-X RA">
          <t>
The phrase "PIO-X RA" is used to refer to an IPv6 Router Advertisement (RA)
that contains one or more PIO-X entries (the same RA may also contain one or
more PIOs without the X flag set).
          </t>
        </section>

        <section title="Host">
          <t>
The term "host" may be used interchangeably throughout this document to mean
a network node receiving and processing an RA. The receiving node may itself
be a router, or may temporarily become one by routing all or a portion of an
exclusive use prefix.
          </t>
        </section>
      </section>
    </section>

    <section title="Updated Prefix Information Option">
      <t>
This document updates the Prefix Information Option specification in
<eref target="RFC4861">RFC 4861</eref> section 4.6.2 and
<eref target="RFC6275">RFC 6275</eref> section 7.2
with the definition of a flag from the former Reserved1
field as follows.
      </t>

      <section title="Updated format description">
        <figure align="center">
          <artwork align="left"><![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     | Prefix Length |L|A|R|X| Rsrvd1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Valid Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Preferred Lifetime                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                            Prefix                             +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
          </artwork>
        </figure>

        <texttable align="left" style="none">
          <preamble>Fields:</preamble>
          <ttcol></ttcol>
          <ttcol></ttcol>
          <ttcol></ttcol>
          <c>X</c>
          <c>&nbsp;</c>
          <c>
The eXclusive use indicator flag, defined by this document. When set,
the receiving node can be assured that all traffic destined to any address
within the specified Prefix will be forwarded to itself by, at a minimum,
the router from which the encapsulating RA was received, but possibly other
routers as well.
          </c>

          <c>&nbsp;</c><c>&nbsp;</c><c>&nbsp;</c>

          <c>&nbsp;</c><c>&nbsp;</c><c>
When not set, the receiving node MUST NOT make any assumptions of exclusive
use of the specified Prefix, i.e. processing is unchanged from previous
standards behavior.
          </c>

          <c>&nbsp;</c><c>&nbsp;</c><c>&nbsp;</c>

          <c>Rsrvd1</c>
          <c>&nbsp;</c>
          <c>
Retains the same meaning as Reserved1 from <eref target="RFC4861"/>
section 4.6.2.
          </c>

          <c>&nbsp;</c><c>&nbsp;</c><c>&nbsp;</c>

          <c>All other fields</c>
          <c>&nbsp;</c>
          <c>
Retain their same meaning from <eref target="RFC4861"/> section 4.6.2.
          </c>
        </texttable>
      </section>
      <section anchor="pio-x_processing" title="Receiver processing">
        <t>
Nodes compliant with this specification perform the following additional
processing of RAs and PIO-X options when a PIO-X option is present.
        </t>

        <section title="PIO R flag">
          <t>
If the R flag is set then the X flag MUST be ignored. The R flag indicates
that the PIO includes an address the router has selected for itself from the
prefix. Logically, the prefix cannot exclusively be used by the receiving
node if the router has allocated any addresses for itself from the prefix.
          </t>
        </section>

        <section anchor="pio-x_other_flags"
                 title="(Re)Interpretation of other flags">
<t>
Nodes compliant with this specification, i.e. those that understand the X-flag,
MUST, when the X-flag is set, ignore the actual values of the L and A flags
and instead interpret them as follows:
</t>

<t>
<list style="symbols">
  <t>interpret the L flag as if it were 0 (L=0)</t>
  <t>interpret the A flag as it it were 1 (A=1)</t>
</list>
The rationale for this is as follows.
</t>
            <section title="PIO L flag">
              <t>
Because a PIO-X aware node will know that it has exclusive use of a prefix
with non-zero valid lifetime, the prefix itself cannot be considered to be
on-link with respect to the link on which the PIO-X RA was received.
              </t>
              <t>
Note that a given address from within the prefix may be considered on-link
according to the definition in <eref target="RFC5942"/> section 4, item 1,
should the receiving node chose to configure that address on said link, but
this is in no way synonymous with the entire prefix being considered on-link.
              </t>
            </section>

            <section title="PIO A flag">
              <t>
Because a PIO-X aware node will know that it has exclusive use of a prefix
with non-zero valid lifetime, autoconfiguration of addresses according to
any desired scheme, e.g. <eref target="RFC4862"/>, <eref target="RFC7217"/>,
et cetera, is implicit in the setting of the X flag.
              </t>
              <t>
Accordingly, the A flag can be interpreted as having been set, should the host
choose to apply standard address generation schemes that require the flag to
be set. It is free to assign any address formed from an exclusive prefix to any
available interface; it is not required to configure the address on the link
over which the PIO-X RA was received (i.e. it is under no obligation to form
addresses such that they would be classified as on-link (according to the
definition in <eref target="RFC5942"/> section 4, item 1).
              </t>
            </section>
        </section>
      </section>

      <section anchor="pio-x_transmission" title="Sender requirements">
<t>
When a router transmits an RA containing one or more PIO-X options it SHOULD
unicast the PIO-X RA to its intended recipient at the IPv6 layer and, if
applicable, at the link-layer.
</t>
<t>
It is RECOMMENDED that a PIO with the X-flag set also have the PIO flags
L=0 and A=1 explicitly configured, for backward compatibility (i.e. use
by non X-flag aware nodes).
</t>
<t>
A router transmitting a PIO-X RA MUST NOT configure for itself any address
from with the PIO-X prefix.  (If it did, the prefix would logically no
longer be of exclusive use for the receiving node.)
</t>
      </section>

      <section anchor="pio-x_vs_dchpv6-pd" title="Comparison with DHCPv6 PD">
        <t>
There exists a key difference in semantics between PIO-X and DHCPv6 PD:
with PIO-X the network keeps the client refreshed with its prefix whereas
with DHCPv6 PD the client is responsible for refreshing its prefix from
the server.  This is one reason it is important for the data link layer
to be able to quickly inform routers of client detachment.
        </t>
        <t>
Another difference is that <eref target="RFC3633"/> section 12.1 states:
          <figure align="left">
            <artwork align="left"><![CDATA[
                                       ... the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.
]]>
            </artwork>
          </figure>
In contrast, a node receiving a PIO-X RA is explicitly free to treat the
entire prefix as on-link with respect to the interface via which it was
received.
        </t>
      </section>
    </section>

    <section anchor="host_behavior" title="Host behavior">
      <t>
TODO: This section needs some work.
      </t>

      <section title="PIO-X processing">
        <t>
A receiving node compliant with this document processes an RA with a PIO
entry with the X flag set according the requirements in previous standards
documents (chiefly <eref target="RFC4861"/> section 6.3.4) subject to the
additional requirements documented in <xref target="pio-x_processing"/>.
        </t>
      </section>

      <section title="Neighbor Discovery implications">
        <section title="Duplicate Address Detection (DAD)">
          <t>
Whatever use the host makes of the exclusive prefix during its valid lifetime,
it SHOULD NOT perform Duplicate Address Detection ("DAD",
<eref target="RFC4862"/> section 5.4) on any address it
configures from within the prefix if that address is configured on either the
interface over which the PIO-X RA was received or on a loopback interface.
Note that this does not absolve the host from performing DAD in all scenarios;
if, for example, the host uses the prefix for
<eref target="RFC7278">64sharing</eref> it MUST at a minimum defend via DAD
any addresses it has configured for itself as documented in Requirement 2 of
<eref target="RFC7278"/> section 3.
          </t>
        </section>

        <section title="Router Solicitations (RSes)">
          <t>
Routers announcing PIO-X RAs do so via IPv6 unicast to the intended receiving
node and may note the IPv6 unicast destination address of an RS as the next
hop for the exclusive prefix. As such, hosts compliant with this SHOULD NOT
use the unspecified address (::) when sending RSes; they SHOULD prefer
issuing Router Solicitations from a link-local address.
          </t>

          <t>
It is possible for a node to receive multiple RAs with a mix of exclusive and
non-exclusive PIOs and even non-zero and zero default router lifetimes. While
it is not possible for a host (receiving node) to be sure it has received all
the RA information available to it, hosts compliant with this specification
SHOULD implement Packet-Loss Resiliency for Router Solicitations
<xref target="RFC7559"/> so that the host continues to transmit Router
Solicitations at least until an RA with a non-zero default router lifetime
has been seen.
          </t>
        </section>
      </section>

      <section title="Link-local address behavior">
        <t>
Routers announcing PIO-X RAs may record the source (link-local) address of an
RS as the next hop for the exclusive prefix. A node compliant with this
specification MUST continue to respond to Neighbor Solicitations for the source
address used to send RSes (alternatively: the destination address of unicast
PIO-X RAs received). Hosts that deprecate or even remove this address may
experience a loss of connectivity.
        </t>
      </section>

      <section title="Source address selection">
        <t>
No change to existing source address selection behavior is required or
specified by this document.
        </t>
      </section>

      <section title="Next hop router selection">
        <t>
No change to existing next hop router selection behavior is required or
specified by this document.
        </t>
      </section>

      <section title="Implications for Detecting Network Attachment">
        <t>
TODO: Describe implications for <eref target="RFC6059">Detecting Network
Attachment in IPv6</eref> (DNAv6).  Probably the best that can be done is
(a) no change to RFC6059 coupled with (b) a host MAY send a test packet
(e.g. ICMPv6 Echo Request) with a source and destination address from within
the PIO-X prefix to the PIO-X RA issuing router and verify the packet is
delivered back to itself.  Consistent failure to receive such traffic MAY
be considered a signal that the exclusive prefix should no longer be used by
the host.
        </t>
      </section>

      <section title="Additional guidance">
        <t>
The intent of networks that use PIO-X RAs is not to enable sophisticated
routing architectures that could be far better handled by an actual routing
protocol but rather to propagate a prefix's exclusive use information to
enable the receiving node to make better use of the available addresses.
As such:
          <list>
            <t>
A PIO-X receiving node SHOULD NOT issue ICMPv6 Redirects
(<xref target="RFC4861"/> section 4.5) for any address within an exclusive use
prefix via the link over which the PIO-X RA was received. Redirecting portions
of exclusive prefixes to other "upstream" on-link nodes is not a supported
configuration.
            </t>
            <t>
A PIO-X receiving node SHOULD NOT transmit RAs with any subset of its exclusive
prefixes via the same interface through which the exclusive prefix was learned.
            </t>
          </list>
        </t>
      </section>
    </section>

<!--
        <section anchor="pio-x_sole_recipient"
                 title="Verify sole recipient">
<t>
If an address other than :: (the unspecified address) was used as the source
address for one or more Router Solicitations (RS) on this link, the node MUST
verify that the IPv6 destination address of the PIO-X RA is one of the RS
source addresses in use.  If the link over which this communication takes
place is known to be point-to-point, i.e. the nature of the link ensures that
the node is the only possible recipient of an RA this check SHOULD NOT be
performed.
</t>
        </section>
-->
    <section title="Router behavior">
      <t>
TODO: This section needs some work.
      </t>

      <section title="PIO-X RA destination address">
        <t>
Since the host will not perform DAD for addresses within prefix announced via
PIO-X, it's very important that only a single host receives the PIO-X RA.
Therefore, the router MUST only include PIO-X in RAs that are sent
using unicast RAs to destination unicast link-layer address and IPv6 link-local
unicast address for a specific host. For point-to-point media
without link-layer addresses or where there is guaranteed to only be single
host that will receive the PIO-X RA (e.g. as enforced by link layer mechanisms),
the router MAY send PIO-X RA with multicast destination IPv6 address. Under all
circumstances the router MUST maintain a binding table of state information as
discussed in <xref target="piox_binding_table"/>.
        </t>
      </section>

      <section title="Detecting hosts to send PIO-X RAs to">
        <t>
When the host starts using a network connection it normally sends out an RS
(Router Solicitation) packet. This is one way for the router to detect that
a new host is connected to the network and detects its link-local address. If
the router is configured to use PIO-X, it can now perform necessary
processing/configuration and then send the PIO-X RA.
        </t>
        <t>
For some networks, the host information regarding link-layer and link-local
address might be available through other mechanism(s).  Examples of this are
PPP, 802.1x and 3GPP mobile networks. In that case this information MAY be
used instead of relying on the host to send RS. It is however RECOMMENDED
that these networks also provide indication whether the host is no longer
connected to the network so that the router can invalidate the prefix binding
prior to binding expiration (timeout).
        </t>
      </section>

      <section anchor="piox_binding_table" title="Binding table requirements">
        <t>
Routers transmitting PIO-X RAs have state maintenance and operational
requirements similar to delegating routers in networks where
<xref target="RFC3633">DHCPv6 Prefix Delegation</xref> is used. The state
maintained is describe here in terms of a conceptual binding table.
        </t>

        <t>
          <list counter="reqs" hangIndent="4" style="format R%d">
            <t>
The router SHOULD keep track of which PIO-X prefix has been issued to each
node.
            </t>
            <t>
The router SHOULD keep the binding between prefix and link-local address for
the advertised valid lifetime, plus some operationally determined delay prior
to reissuing a prefix ("grace period"), of the prefix.
            </t>
            <t>
The router MUST monitor the reachability of each node in the binding table via
Neighbor Unreachability Detection ("NUD", <eref target="RFC4861"/> section 7.3)
or an equivalent link-layer mechanism.
            </t>
            <t>
The binding SHOULD be considered refreshed every time a periodic PIO-X RA is
sent to a node.
            </t>
            <t>
If the router is informed by some other mechanism (link-layer indication for
instance) that a node is no longer connected to the link, it MAY immediately
invalidate the prefix binding.
(DISCUSS:
    Is this the correct approach?
    Do we want to point to some definition somewhere else?)
            </t>
          </list>
        </t>
      </section>

      <section title="Preparations before sending a PIO-X RA">
        <t>
When the router intends to send a PIO-X RA, it SHOULD before sending the
PIO-X RA, complete any and all necessary processing for the host to start using
the PIO-X prefix to communicate through the router to other networks. This is
so that the host can start using PIO-X based addresses without delay or error
after receipt of the PIO-X RA.
        </t>
      </section>

      <section title="Implementation considerations">
        <t>
TODO: Out of scope things that are worth careful consideration include...
        </t>
        <t>
Routers SHOULD NOT announce the same prefix to two different nodes within
the valid lifetime of the earlier of the two PIO-X announcements.
        </t>
        <t>
A link may operate in a mode where routers announce RAs to all nodes,
possibly with non-exclusive PIO data, and non-zero default router lifetimes.
Separately, one or more other nodes on the link may announce exclusive PIO
information to nodes along with zero default router lifetimes.
Except in the presence of a non-expired more specific route, e.g. learning from
an <eref target="RFC4191"/> Route Information Option (RIO), the receiving
node should send exclusive use prefix originated or forwarded traffic destined
off-link through routers with non-zero default router lifetimes.
        </t>
        <t>
        </t>
      </section>
    </section>

    <!-- Possibly a 'Contributors' section ... -->
    <section anchor="acks" title="Acknowledgements">
      <t>
      </t>
      <t>
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>
This memo contains no requests of IANA.
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
This document fundamentally introduces no new protocol or behavior
substantively different from existing behavior on a link which guarantees
a unique /64 prefix to every attached host. It only describes a mechanism
to convey that topological reality, allowing the host to make certain
optimizations as well as share the exclusive prefix as it sees fit with
other nodes according to its capabilities and policies.
      </t>
    </section>
  </middle>


  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      &RFC2119;
      &RFC4861;
      &RFC4862;
      &RFC6275;
      &RFC7559;
    </references>

    <references title="Informative References">
      &RFC3633;
      &RFC4429;
      &RFC5452;
      &RFC4191;
      &RFC7066;
      &RFC7934;
    </references>

<!--
    <section anchor="appendix" title="Appendix">
      <t>This becomes an Appendix.</t>
    </section>
-->
  </back>
</rfc>
