One document matched: draft-baker-ipv6-isis-automatic-prefix-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of 
<cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section, 
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as 
<29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents, but idnits insists on a ToC 
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-ipv6-isis-automatic-prefix-00"
     ipr="trust200902">
  <front>
    <title abbrev="Automated Prefix Management">Automated prefix allocation in
    IS-IS</title>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street></street>

          <city>Santa Barbara</city>

          <code>93117</code>

          <region>California</region>

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

        <email>fred@cisco.com</email>
      </address>
    </author>

    <date year="2013" />

    <area>Internet Engineering Task Force</area>

    <workgroup></workgroup>

    <abstract>
      <t>This note describes a TLV and associated mechanisms for the
      allocation of /64 prefixes from a less specific prefix.</t>
    </abstract>

    <!--		
<note title="Foreword">
</note>
		-->

    <!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
      Every cell then has a "c" element for its content.
</preamble>
<ttcol align="center">ttcol #1
</ttcol>
<ttcol align="center">ttcol #2
</ttcol>
<c>c #1
</c>		
<c>c #2
</c>
<c>c #3
</c>		
<c>c #4
</c>
<c>c #5
</c>		
<c>c #6
</c>
<postamble>which is a very simple example.
</postamble>
</texttable>
    -->
  </front>

  <middle>
    <!--		
<t>There are multiple list styles: "symbols", "letters", "numbers", 
"hanging", "format", etc.
</t>
<t>
<list style="symbols">
<t>First bullet
</t>
<t>Second bullet
</t>
</list>
</t>
-->

    <!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
	ASCII artwork goes here... 
]]>
</artwork>
</figure>
-->

    <section title="Introduction">
      <t>This note recommends an approach to the automated allocation of /64
      prefixes within a network. This not something that will be done in a
      heavily-managed network, but may be appropriate in networks with light
      management, such as residential and SOHO networks.</t>

      <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">
        </xref>.</t>
      </section>
    </section>

    <section anchor="extensions" title="Theory of Operation">
      <t>The premise is that some party allocates a prefix to a network, such
      as a PA /48 or /56. The obvious way is using <xref
      target="RFC3633">DHCP-PD </xref>, although that is not actually
      required.</t>

      <t><xref target="ISO.10589.1992">IS-IS </xref> represents those
      destinations as a type-length-value field that identifies an address.
      For CLNS, it was designed to the ISO NSAP; by various extensions, it
      also handles IPv4 and IPv6 prefixes and their counterparts for other
      protocols. In this model, we add a TLV to advertise the delegated
      prefix, with the expectation that routers in the network (including
      pseudo-nodes) will allocate more specific prefixes from that prefix.</t>

      <t>In short, some specified system in the network, potentially a
      configuration management system or the CPE router facing an upstream
      network, is configured with an autoconfiguration prefix, and manages the
      use of that prefix in the network.</t>

      <section anchor="advertisement"
               title="Autoconfiguration TLV Advertisement ">
        <t>Upon recognizing that it has been configured with a prefix and that
        the network management policy is for autoconfiguration, the system in
        question advertises the autoconfiguration prefix described in <xref
        target="tlv"> </xref> within the intended area or network.</t>
      </section>

      <section anchor="allocation"
               title="Subnet prefix allocation and announcement">
        <t>Each router advertising a <xref target="RFC5308">Reachability TLV
        </xref>, including a pseudonode on a LAN, when it receives the
        Autoconfiguration TLV Advertisement, calculates and announces a more
        specific prefix from the advertised autoconfiguration prefix in a
        Reachability TLV. This prefix is chosen at random, but may not collide
        with any prefix currently advertised within the network and therefore
        in the LSP database.</t>

        <t>There are obvious caveats here: if the autoconfiguration prefix is
        too long and as a result there are more LANs than there are prefixes
        to allocate to them, the procedure breaks down badly, and if there are
        just exactly enough, it may take time to converge. Hence, from an
        operational perspective, the autoconfiguration prefix should have
        enough /64 more specific prefixes, and from an implementation
        perspective, the randomization function must be sufficiently robust,
        that independent choices are unlikely to collide.</t>

        <t>In the event of collision, which is likely to happen from time to
        time, it is up to the nodes advertising the prefix in question to
        detect and resolve the situation. Upon receiving an LSP containing its
        "own" prefix advertised by another router, each router waits
        CollisionDetect (10) seconds, to give the network ample opportunity to
        detect the issue. It then waits an additional random interval between
        zero and CollisionDetect seconds, to randomize the recovery process
        and maximize the chance that replacement prefixes do not collide. It
        then allocates a new prefix following the procedure described in this
        section, and re-announces its LSP, removing (and therefore
        withdrawing) the offending reachability TLV, and instead announcing
        the new one.</t>

        <t>Subsequent procedures, such as the advertisement of Router
        Advertisement using the allocated prefix or DHCPv6 allocation of
        addresses, may start CollisionDetect seconds after the LSP has been
        announced if no collision has been detected. At this point, routers
        MAY store their /64s in non-volatile storage.</t>
      </section>

      <section anchor="withdrawal" title="Autoconfiguration TLV Withdrawal">
        <t>When the prefix advertised in the Autoconfiguration TLV expires or
        is withdrawn, the Autoconfiguration TLV is withdrawn from the network.
        Upon detection of the withdrawal, each router in the network MUST
        withdraw any addresses or prefixes dependent on it. If those prefixes
        are stored in non-volatile storage, they MUST also be removed.</t>
      </section>

      <section anchor="renumber" title="Renumbering using autoconfiguration">
        <t><xref target="RFC4192"></xref> describes the process of renumbering
        in some detail. The discussion here is somewhat simplistic; refer to
        that for a more detailed discussion.</t>

        <t>In short, "renumbering" a network is a special case of "numbering"
        a network. If there is one prefix in use in a network and it is
        withdrawn, the network will experience an outage. Hence, it is
        generally advisable to ensure that there are at least two prefixes in
        use in a network when one of them is removed. This might be
        accomplished by simply using multiple prefixes in the network; it
        might also be accomplished by deploying a second autoconfiguration
        prefix minutes or hours before the "old" one is removed. During that
        time, DNS and DHCP databases need to be updated as described in <xref
        target="RFC4192"></xref> to reflect the new prefix.</t>

        <t>If an outage is acceptable, it is also possible to renumber using
        the same prefix. For this, the administration withdraws the prefix as
        described in <xref target="withdrawal"></xref> and waits until the
        process is complete. There are two obvious ways to determine
        completion: <list style="symbols">
            <t>Wait long enough that it is highly unlikely to have not
            completed, which might be the number of routers in the network
            diameter times the LSP update retransmission interval, or</t>

            <t>Wait until the managing router's LSP database contains no
            Reachability TLVs that depend on the prefix.</t>
          </list></t>

        <t>At this point, any systems that are only using that prefix are now
        unreachable using global addressing.</t>

        <t>At this point, the managing system may re-advertise the prefix as
        described in <xref target="advertisement"></xref>, and the routers in
        the network will re-allocate prefixes as described in <xref
        target="withdrawal"></xref>.</t>
      </section>
    </section>

    <section anchor="tlv" title="IPv6 Autoconfiguration TLV">
      <t>The structure of the Autoconfiguration TLV is as follows:</t>

      <figure anchor="autoconfiguration-tlv" title="Autoconfiguration TLV">
        <artwork align="center"><![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 = IANA  |    Length     |U|X|   Reserve |  Prefix Len   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * - if present
   U - up/down bit
   X - external original bit

]]></artwork>
      </figure>

      <t>As is described in <xref target="RFC5305"></xref>: "The up/down bit
      SHALL be set to 0 when a prefix is first injected into IS-IS. If a
      prefix is advertised from a higher level to a lower level (e.g. level 2
      to level 1), the bit SHALL be set to 1, indicating that the prefix has
      traveled down the hierarchy. Prefixes that have the up/down bit set to 1
      may only be advertised down the hierarchy, i.e., to lower levels".</t>

      <t>If the prefix was distributed into IS-IS from another routing
      protocol, the external bit SHALL be set to 1. This information is useful
      when distributing prefixes from IS-IS to other protocols.</t>

      <t>The prefix is "packed" in the data structure. That is, only the
      required number of octets of prefix are present. This number can be
      computed from the prefix length octet as follows: <list>
          <t>prefix octets = integer of ((prefix length + 7) / 8)</t>
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This section will request an identifying value for the TLV defined.
      This is deferred to the -01 version of the draft.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>To be considered.</t>
    </section>

    <section anchor="Privacy" title="Privacy Considerations">
      <t>To be considered.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>

    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">February 2013</t>
        </list></t>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.ISO.10589.1992" ?>

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

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

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

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

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

    <references title="Informative References">
      <?rfc include="reference.I-D.draft-baker-fun-routing-class-00" ?>

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

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

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

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

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

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

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

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

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