<?xml version="1.0" encoding="US-ASCII"?>
<!--v1-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>

<rfc category="std" number="6969" consensus="yes"
     ipr="trust200902" submissionType="IETF" updates="5838"
     xml:lang="en">
  <front>
    <title abbrev="OSPFv3 Instance ID Registry Update">OSPFv3 Instance ID
    Registry Update</title>

    <author fullname="Alvaro Retana" initials="A." surname="Retana">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>7025 Kit Creek Rd.</street>

          <city>Research Triangle Park</city>

          <region>NC</region>

          <code>27709</code>

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

        <email>aretana@cisco.com</email>

      </address>
    </author>

    <author fullname="Dean Cheng" initials="D." surname="Cheng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>2330 Central Expressway</street>

          <city>Santa Clara</city>

          <region>California</region>

          <code>95050</code>

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

        <email>dean.cheng@huawei.com</email>
      </address>
    </author>

    <date month="July" year="2013"/>

    <abstract>
      <t>This document modifies the "Unassigned" number space in the IANA
      "OSPFv3 Instance ID Address Family Values" registry by dividing it in
      two halves -- one half Unassigned but managed via Standards Action, and
      the other Reserved for Private Use. It updates RFC 5838.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" toc="default">
      <t><xref format="default" pageno="false" target="RFC5838"/> defined the
      "OSPFv3 Instance ID Address Family Values" registry for the purpose of
      mapping OSPFv3 Instance IDs to different address families. The following
table lists the value ranges that were allocated for <xref
      target="RFC5838"/> and Unassigned.</t>

      <texttable align="center" style="full" suppress-title="false" title="">
        <ttcol align="left">Value</ttcol>

        <ttcol align="left">Description</ttcol>

        <ttcol align="left">Reference</ttcol>

        <c>0</c>

        <c>IPv6 unicast AF</c>

        <c><xref target="RFC5838"/></c>

        <c>1 - 31</c>

        <c>Base IPv6 Unicast AF dependent on local policy</c>

        <c><xref target="RFC5838"/></c>

        <c>32</c>

        <c>Base IPv6 Multicast</c>

        <c><xref target="RFC5838"/></c>

        <c>33-63</c>

        <c>IPv6 Multicast AFs dependent on local policy</c>

        <c><xref target="RFC5838"/></c>

        <c>64</c>

        <c>Base IPv4 Unicast AF</c>

        <c><xref target="RFC5838"/></c>

<c>65-95</c>
<c>IPv4 Unicast AFs dependent on local policy</c>
<c><xref target="RFC5838"/></c>

<c>96</c>
<c>Base IPv4 Multicast</c>
<c><xref target="RFC5838"/></c>

<c>97-127</c>
<c>IPv4 Multicast AFs dependent on local policy</c>
<c><xref target="RFC5838"/></c>

<c>128-255</c>
<c>Unassigned</c>
<c><xref target="RFC5838"/></c>
      </texttable>

      <t>In some networks, additional OSPFv3 instances may be required to
      operationally identify specific applications. This need requires a pool
      of Instance IDs that the operator may locally assign for that
      purpose.</t>

      <t>For example, <xref format="default" pageno="false"
      target="OSPF-EMBED"/> describes an
      application in which <xref target="RFC6052">IPv4-embedded IPv6
      addresses</xref> are used to transport IPv4 packets over an IPv6
      network. While the IPv4-embedded IPv6 addresses do in fact represent
      IPv6 destinations, it would be operationally beneficial to be able to
      easily identify the specific application by having a separate space
      to do so. This benefit is enabled by the allocation of a range of
      Private Use Instance IDs.</t>

      <t>
  This document modifies the IANA
  "OSPFv3 Instance ID Address Family Values" registry by designating a
  range as Reserved for Private Use.  For the remaining unassigned values,
  the registration procedure is Standards Action.
</t>
    </section>

    <section anchor="Proposal"
             title="OSPFv3 Instance ID Address Family Values Registry Update"
             toc="default">
      <t>The IANA "OSPFv3 Instance ID Address Family Values" registry has been
updated so that Instance IDs from 192-255 are Reserved for Private Use
<xref target="RFC5226"/>.  For the remaining unassigned values (128-191), the
registration procedure is Standards Action.  The registry now shows:
</t>

      <texttable align="center" style="full" suppress-title="false" title="">
        <ttcol align="left">Value</ttcol>

        <ttcol align="left">Description</ttcol>

        <ttcol align="left">Reference</ttcol>

        <c>128-191</c>

        <c>Unassigned</c>

        <c>192-255</c>

        <c>Reserved for Private Use</c>

        <c>this document</c>

        <c><xref format="default" pageno="false" target="RFC5226">Private
        Use</xref></c>
      </texttable>
    </section>

    <section title="IANA Considerations" toc="default">
      <t>This document requests the modification of the "OSPFv3 Instance ID
      Address Family Values" registry as described in <xref format="default"
      pageno="false" target="Proposal"/>. The reference to <xref
      format="default" pageno="false" target="RFC5838"/> has been removed
      from the registry for the modified ranges.</t>
    </section>

    <section title="Security Considerations" toc="default">
      <t>This document modifies an IANA registry defined in <xref format="default" pageno="false" target="RFC5838"/>. It
      does not introduce any new security issues.</t>

    </section>

    <section title="Acknowledgements" toc="default">
      <t>Many thanks to Acee Lindem, Stewart Bryant, Nevil Brownlee, Pearl
      Liang, Ben Campbell, Adrian Farrel, and Richard Barnes for their review
      and input.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.5226'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5838'?>

<!-- draft-ietf-ospf-ipv4-embedded-ipv6-routing in EDIT -->

<reference anchor='OSPF-EMBED'>
<front>
<title>Routing for IPv4-embedded IPv6 Packets</title>

<author initials='D' surname='Cheng' fullname='Dean Cheng'>
    <organization />
</author>

<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>
    <organization />
</author>

<author initials='A' surname='Retana' fullname='Alvaro Retana'>
    <organization />
</author>

<date month='June' day='10' year='2013' />

<abstract><t>This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.</t></abstract>

</front>
<seriesInfo name="Work" value="in Progress"/>

</reference>

      <?rfc include='reference.RFC.6052'?>
    </references>
  </back>
</rfc>
