One document matched: draft-ietf-6lo-ethertype-request-01.xml
<?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-ietf-6lo-ethertype-request-01" 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 LoWPAN Encapsulation">
Assignment of an Ethertype for IPv6 with
LoWPAN Encapsulation</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 LoWPAN encapsulation as defined in RFC 4944
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 encapsulation
<xref target="RFC4944" /> ("LoWPAN encapsulation"). This
document regards any IPv6 datagram using the Dispatch octet as
defined in section 5.1 of RFC 4944 to be using LoWPAN
encapsulation. LoWPAN encapsulation as defined in RFC 4944 has
been updated by <xref target="RFC6282" />, and
may be extended and modified by future IETF standards
document. The intended layer 2 technology for IPv6 datagrams
using LoWPAN encapsulation 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 supporting Ethertype based protocol
dispatch for LoWPAN encapsulated IPv6 datagrams:
<list style="symbols">
<t>Usage of LoWPAN encapsulation 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 LoWPAN encapsulation frames to upper stack layers. As
specified in IEEE 802.15.9, dispatch of LoWPAN encapsulation frames will
require an Ethertype be assigned for LoWPAN encapsulation.</t>
<t>LoWPAN encapsulation 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 LoWPAN encapsulation to properly interpret
IPv6 datagrams that use LoWPAN encapsulation.</t>
<t>Any existing or future Layer 2 technology, incorporating
Ethertype based upper layer dispatch, can use the Ethertype
proposed in this document to dispatch LoWPAN encapsulated
IPv6 datagrams.</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 LoWPAN encapsulation.
</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 LoWPAN encapsulation. 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>
| PAFTECH AB 2003-2026 | 2026-04-22 02:59:02 |