<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4007 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4007.xml">
<!ENTITY I-D.ietf-roll-trickle-mcast SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-trickle-mcast.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. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no"?>
<!-- generate a ToC -->
<!-- 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="std" docName="draft-ietf-6man-multicast-scopes-07.txt"
     ipr="pre5378Trust200902" updates="4007, 4291">
  <!-- 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 MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="IPv6 Multicast Address Scopes">IPv6 Multicast Address Scopes</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Ralph Droms" initials="R."
            surname="Droms">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>1414 Massachusetts Avenue</street>

          <!-- Reorder these if your country does things differently -->

          <city>Boxborough</city>

          <region>MA</region>

          <code>01719</code>

          <country>USA</country>
        </postal>

        <phone>+1 978 936 1674</phone>

        <email>rdroms.ietf@gmail.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2014" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
         in the current day and month for you. If the year is not the current one, it is 
         necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
         purpose of calculating the expiry date).  With drafts it is normally sufficient to 
         specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Internet</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 multicast address scopes</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document updates the definitions of IPv6 multicast
      scopes.  This document updates RFC 4007 and RFC 4291</t> 
    </abstract>
  </front>

  <middle>
    <?rfc needLines="12" ?>

    <section title="Introduction">
      <t><xref target="RFC4291">RFC&nbsp;4291</xref> defines "scop is
      a 4-bit multicast scope value used to limit the scope of the
      multicast group."  scop 3 is defined as "reserved" in RFC 4291.
      The multicast protocol specification in <xref
      target="I-D.ietf-roll-trickle-mcast">draft-ietf-roll-trickle-mcast</xref>
      desires to use multicast scop 3 for transport of multicast
      traffic scoped to a network of nodes connected in a mesh.  The
      use of this scop value is to accommodate a multicast scope that
      is greater than Link-Local but is also automatically determined
      by the network architecture.</t>
    </section>

    <section anchor = "scopedef"
	     title="Definition of IPv6 Multicast Address Scopes
                    (Updates RFC 4291)">
      <t>The following table updates the definitions in RFC 4291:

      <figure>
        <artwork>
<![CDATA[

   +------+--------------------------+-------------------------+
   | scop | NAME                     | REFERENCE               |
   +------+--------------------------+-------------------------+
   |  0   | Reserved                 | [RFC4291],[ RFC-to-be ] |
   |  1   | Interface-Local          | [RFC4291],[ RFC-to-be ] |
   |  2   | Link-Local scope         | [RFC4291],[ RFC-to-be ] |
   |  3   | Realm-Local scope        | [RFC4291],[ RFC-to-be ] |
   |  4   | Admin-Local scope        | [RFC4291],[ RFC-to-be ] |
   |  5   | Site-Local scope         | [RFC4291],[ RFC-to-be ] |
   |  6   | Unassigned               |                         |
   |  7   | Unassigned               |                         |
   |  8   | Organization-Local scope | [RFC4291],[ RFC-to-be ] |
   |  9   | Unassigned               |                         |
   |  A   | Unassigned               |                         |
   |  B   | Unassigned               |                         |
   |  C   | Unassigned               |                         |
   |  D   | Unassigned               |                         |
   |  E   | Global scope             | [RFC4291],[ RFC-to-be ] |
   |  F   | Reserved                 | [RFC4291],[ RFC-to-be ] |
   +------+--------------------------+-------------------------+
]]>
        </artwork>
      </figure>
      </t>

      <t>The following change is applied to section 2.7 of RFC 4291:

      <figure>
        <artwork>
<![CDATA[
OLD:

      Admin-Local scope is the smallest scope that must be
      administratively configured, i.e., not automatically derived
      from physical connectivity or other, non-multicast-related
      configuration.

NEW:

      Interface-Local, Link-Local, and Realm-Local scope
      boundaries are automatically derived from physical
      connectivity or other, non-multicast related configuration.
      Global scope has no boundary.  The boundaries of all other
      non-reserved scopes of Admin-Local or larger are
      administratively configured.  For reserved scopes, the way
      of configuring their boundaries will be defined when the
      semantics of the scope is defined.

      According to RFC 4007 [RFC4007], the zone of a Realm-Local
      scope must fall within zones of larger scope.  Because the
      zone of a Realm-Local scope is configured automatically,
      while the zones of larger scopes are configured manually,
      care must be taken in the definition of those larger scopes
      to ensure that inclusion constraint is met.

      Realm-Local scopes created by different network technologies
      are considered to be independent and will have different zone
      indices (see RFC 4007, section 6).  A router with interfaces
      on links using different network technologies does not forward
      traffic between the Realm-Local multicast scopes defined by
      those technologies.


]]>
        </artwork>
      </figure>
      </t>
    </section>


    <section title="Definition of Realm-Local scopes">

      <t>The definition of any Realm-Local scope for a particular
      network technology should be published in an RFC.  For example,
      such a scope definition would be appropriate for publication in
      an "IPv6-over-foo" RFC.</t>

      <t>Any RFCs that include the definition of a Realm-Local scope
      will be added to the IANA 'IPv6 Multicast Address Scopes'
      registry under the Realm-Local scope entry, and those
      specifications must include such a request in their IANA
      Considerations.</t>

      <t><xref target="RealmDef" /> of this document gives the
      definition of scop 3 for <xref target="IEEE802.15.4">IEEE
      802.15.4</xref> networks.</t>

    </section>

    <section title="Definition of automatic and administratively
                    configured scopes (updates RFC 4007)">
      <t>Section 5 of <xref target="RFC4007">RFC 4007</xref> and
      section 2.7 of RFC 4291 disagree about the way in which
      multicast scope 3 is configured.  To resolve that disagreement,
      change the last bullet in the list in section 5 of RFC 4007 as
      follows:

      <figure>
        <artwork>
<![CDATA[

OLD:

  o  The boundaries of zones of a scope other than interface-local,
     link-local, and global must be defined and configured by network
     administrators.

NEW:

  o  The boundaries of zones of a scope are defined by the IPv6
     addressing architecture [RFC4291] and updated by [RFC-to-be].
]]>
        </artwork>
      </figure>
      </t>

    </section>

    <section anchor="RealmDef" title="Definition of Realm-Local Scope for IEEE 802.15.4">
      <t>  When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined
      to include all interfaces sharing a PAN ID.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">

      <t>IANA is requested to establish a sub-registry titled "IPv6
      Multicast Address Scopes" in the existing "Internet Protocol
      version 6 (IPv6) Multicast Address Allocations" registry.  The
      new registry is to be populated with the scope values given in
      <xref target="scopedef" />. New definitions for scop values will
      be made with "IETF Review" policy.</t>

      <t>IANA is requested to add a reference to the Realm-Local scope
      entry (scop 3) in the "IPv6 Multicast Address Scopes" registry
      for each future RFC that defines a Realm-Local scope for new
      network technologies. Such RFCs are expected to make an explicit
      request to IANA for inclusion in the registry.</t>

      <t>IANA is requested to include a note to the top of the "IPv6
      Multicast Address Scopes" registry:

      <figure>
        <artwork>
<![CDATA[

     The definition of any Realm-Local scope for a particular network
     technology should be published in an RFC.  For example, such a
     scope definition would be appropriate for publication in an
     'IPv6-over-foo' RFC.

     Any RFCs that define a Realm-Local scope will be listed in this
     registry as an additional reference in the Realm-Local scope
     entry.  Such RFCs are expected to make an explicit request to
     IANA for inclusion in this registry.

]]>


        </artwork>
      </figure>
      </t>

    </section>

    <section title="Acknowledgments">
      <t>Robert Cragie, Kerry Lynn, Jinmei Tatuya, Dave Thaler and
      Stig Venaas all contributed text and/or review to ensure that
      the updates to RFC 4007 and RFC 4291 are correct.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document has no security considerations beyond those in
      <xref target="RFC4007">RFC&nbsp;4007</xref> and <xref
      target="RFC4291">RFC&nbsp;4291</xref>.</t>  
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <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">
      <!--?rfc
          include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC4007;
      &RFC4291;
    </references>

    <references title="Informative References">
      &I-D.ietf-roll-trickle-mcast;
      <reference anchor="IEEE802.15.4">
        <front>
          <title>IEEE Standard for Information technology - 
          Telecommunications and information exchange between systems -
          Local and metropolitan area networks - Specific requirements;
          Part 15.4: Wireless Medium Access Control (MAC) and Physical
          Layer (PHY) Specifications for Low-Rate Wireless Personal
          Area Networks (WPANs)</title>

	  <author>
	    <organization>IEEE Std 802.15.4-2006</organization>
	    </author>

          <date month="October" year="2006"/>
        </front>
      </reference>

    </references>
  </back>
</rfc>
