<?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 RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY IEEE802154 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml6/reference.IEEE.802.15.4_2011.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 -->
<?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="info" docName="draft-droms-6lo-ethertype-request-00" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    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="Ethertype for IPv6 with 6LoWPAN Encoding">
          Assignment of an Ethertype for IPv6 with
          RFC 4944, RFC 6282 Header Encoding</title>

    <author fullname="Ralph Droms" initials="R." surname="Droms">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>55 Cambridge Parkway</street>

          <city>Cambridge</city>

          <region>Massachusetts</region>

          <code></code>

          <country>US</country>
        </postal>

        <phone>+1 617 621 1904</phone>

        <email>rdroms.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Paul Duffy" initials="P." surname="Duffy">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>1414 Massachusetts Ave.</street>

          <city>Boxborough</city>

          <region>Massachusetts</region>

          <code>01719</code>

          <country>US</country>
        </postal>

        <phone>+1 978 204 9993</phone>

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

    <date year="2016" />

   <area>Internet</area>

   <workgroup>6lo Working Group</workgroup>

   <keyword>6lowpan, header compression, ethertype</keyword>

    <abstract>
      <t>When carried over layer 2 technologies such as Ethernet, IPv6
      datagrams using datagram encoding as defined in RFC 4944 and
      RFC 6282 must be identified so the receiver can correctly
      interpret the encoded IPv6 datagram.  This document requests
      the assignment of an Ethertype for that purpose.</t> 
    </abstract>

 </front>

 <middle>
    <section title="Introduction">

      <t>The IETF has defined a format for IPv6
      <xref target="RFC2460" /> datagram encoding in
      <xref target="RFC4944" /> and <xref target="RFC6282" />
      (6loENC).  6loENC as defined in RFC 4944 and RFC 6282 may be
      extended and modified by future IETF standards document. The
      intended layer 2 technology for IPv6 datagrams using 6loENC as
      originally defined is <xref target="IEEE.802.15.4_2011" />,
      which does not provide for a protocol switch in its layer 2
      headers.</t>

      <t>There is interest in carrying IPv6 datatgrams over layer 2
      technologies that do include a protocol switch field:
         <list style="symbols">

	   <t>Usage of 6loENC in conjunction with IEEE 802.15.9
	   Multiplexed Data Service <xref target="IEEE802159" />,
	   which provides the ability to perform upper layer protocol
	   dispatch for IEEE 802.15.4 networks.  Wi-SUN Alliance
	   intends to use the 15.9 Multiplexed Data Information
	   Element to dispatch 6loENC frames to upper stack layers. As
	   specified in IEEE 802.15.9, dispatch of 6loENC frames will
	   require an Ethertype be assigned for 6loENC.</t>

	   <t>6loENC will likely be needed for WiFi Alliance's <xref
	   target="HALOW"> HaLoW </xref> standard (low power operation
	   in the 900 MHz band) </t>

	   <t>Other layer 2 technologies such as Ethernet and
	   debugging tools such as Wireshark require a
	   unique protocol type field for 6loENC to properly interpret
	   IPv6 datagrams that use 6loENC.</t>
	 </list>
      </t>
    </section>

     <section title="Request to IEEE for assignment of an Ethertype">
      <t>When this document is published, the IETF will formally
      submit a request to IEEE for assignment of an Ethertype for IPv6
      datagrams using 6loENC.
      </t>
     </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document is intended only to request assignment of an
      Ethertype for IPv6 datagrams using 6loENC.  It has no incremental
      implications for security beyond those in the relevant
      protocols.</t>
    </section>

 </middle>

 <!--  *****BACK MATTER ***** -->

 <back>

   <references title="Normative References">

     &RFC2460;
     &RFC4944;
     &RFC6282;

     &IEEE802154;
<!--
      <reference anchor="IEEE802154">
         <front>
            <title>
              IEEE standard for Information Technology, IEEE std.
              802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications for Low-Rate
              Wireless Personal Area Networks
            </title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date month="" year=""/>
         </front>
      </reference>
-->
<!--
  [802.15.9] - ", IEEE P802.15.9/D04, May
        2015.
-->

      <reference anchor="HALOW">
	<front>
	  <title>Wi-Fi HaLow</title>
	  <author>
	    <organization>Wi-Fi Alliance</organization>
	  </author>
	  <date month="" year="" />
	</front>
	<seriesInfo value =""
	    name="http://www.wi-fi.org/discover-wi-fi/wi-fi-halow" />
      </reference>

      <reference anchor="IEEE802159">
         <front>
            <title>
	      IEEE Draft Recommended Practice for Transort of Key
	      Management Protocol (KMP) Datagrams
            </title>
            <author>
               <organization>IEEE</organization>
            </author>
            <date month="May" year="2015"/>
         </front>
	 <seriesInfo name="IEEE" value="P802.15.9/D04" />
      </reference>

   </references>

<!--
   <section anchor="appendix"
	    title="Request for Assignment of an Ethertype">
     <t>This becomes an Appendix.</t>
   </section>
-->
 </back>
</rfc>
