rfc9428.original.xml   rfc9428.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-6lo-nfc-22" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" x
ml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" versi
on="3" consensus="true">
<!-- xml2rfc v2v3 conversion 3.15.2 -->
<?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) -->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<front> std" consensus="true" docName="draft-ietf-6lo-nfc-22" number="9428" ipr="trust20
<!-- The abbreviated title is used in the page header - it is only necessary 0902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRe
if the fs="true" sortRefs="true" version="3">
full title is longer than 39 characters -->
<front>
<title abbrev="IPv6 over NFC">Transmission of IPv6 Packets over Near Field C ommunication</title> <title abbrev="IPv6 over NFC">Transmission of IPv6 Packets over Near Field C ommunication</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6lo-nfc-22"/> <seriesInfo name="RFC" value="9428"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Younghwan Choi" role="editor" surname="Choi"> <author fullname="Younghwan Choi" role="editor" initials="Y." surname="Choi" >
<organization abbrev="ETRI">Electronics and Telecommunications Research In stitute</organization> <organization abbrev="ETRI">Electronics and Telecommunications Research In stitute</organization>
<address> <address>
<postal> <postal>
<street>218 Gajeongno, Yuseung-gu</street> <street>218 Gajeongno, Yuseung-gu</street>
<!-- Reorder these if your country does things differently -->
<street/> <street/>
<city>Daejeon</city> <city>Daejeon</city>
<region/>
<code>34129</code> <code>34129</code>
<country>South Korea</country> <country>South Korea</country>
</postal> </postal>
<phone>+82 42 860 1429</phone> <phone>+82 42 860 1429</phone>
<email>yhc@etri.re.kr</email> <email>yhc@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Yong-Geun Hong" initials="Y-G" surname="Hong"> <author fullname="Yong-Geun Hong" initials="Y-G." surname="Hong">
<organization abbrev="Daejon Univ">Daejon University</organization> <organization abbrev="Daejon Univ">Daejon University</organization>
<address> <address>
<postal> <postal>
<street>62 Daehak-ro, Dong-gu</street> <street>62 Daehak-ro, Dong-gu</street>
<city>Daejeon</city> <city>Daejeon</city>
<region/>
<code>34520</code> <code>34520</code>
<country>South Korea</country> <country>South Korea</country>
</postal> </postal>
<phone>+82 42 280 4841</phone> <phone>+82 42 280 4841</phone>
<email>yonggeun.hong@gmail.com</email> <email>yonggeun.hong@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Joo-Sang Youn" initials="J-S" surname="Youn"> <author fullname="Joo-Sang Youn" initials="J-S." surname="Youn">
<organization abbrev="Dongeui Univ">DONG-EUI University</organization> <organization abbrev="Dongeui Univ">DONG-EUI University</organization>
<address> <address>
<postal> <postal>
<street>176 Eomgwangno Busan_jin_gu</street> <street>176 Eomgwangno Busan_jin_gu</street>
<city>Busan</city> <city>Busan</city>
<region/>
<code>614-714</code> <code>614-714</code>
<country>South Korea</country> <country>South Korea</country>
</postal> </postal>
<phone>+82 51 890 1993</phone> <phone>+82 51 890 1993</phone>
<email>joosang.youn@gmail.com</email> <email>joosang.youn@gmail.com</email>
</address> </address>
</author> </author>
<date day="6" month="March" year="2023"/> <date month="July" year="2023"/>
<!-- If the month and year are both specified and are the current ones, xml2 <area>int</area>
rfc will fill <workgroup>6lo</workgroup>
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 sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>6Lo Working Group</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>Internet-Draft</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. -->
<keyword>Near Field Communication</keyword>
<keyword>NFC</keyword>
<keyword>6LowPAN</keyword>
<keyword>IPv6</keyword>
<keyword>Adaptation Layer</keyword>
<keyword>IoT</keyword>
<keyword>Internet of Things</keyword>
<abstract> <abstract>
<t>Near Field Communication (NFC) is a set of standards for smartphones an <t>Near Field Communication (NFC) is a set of standards for smartphones an
d portable devices to establish radio communication with each other by touching d portable devices to establish radio communication with each other by touching
them together or bringing them into proximity, usually no more than 10 cm apart. them together or bringing them into proximity, usually no more than 10 cm apart.
NFC standards cover communications protocols and data exchange formats, and are NFC standards cover communication protocols and data exchange formats and are b
based on existing radio-frequency identification (RFID) standards including ISO ased on existing Radio Frequency Identification (RFID) standards, including ISO/
/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by t
the NFC Forum. The NFC technology has been widely implemented and available in m he NFC Forum. The NFC technology has been widely implemented and available in mo
obile phones, laptop computers, and many other devices. This document describes bile phones, laptop computers, and many other devices. This document describes h
how IPv6 is transmitted over NFC using 6LoWPAN techniques.</t> ow IPv6 is transmitted over NFC using IPv6 over
Low-Power Wireless Personal Area Network (6LoWPAN) techniques.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>NFC is a set of short-range wireless technologies, typically requiring <t>NFC is a set of short-range wireless technologies, typically requiring
a distance between sender and receiver of 10 cm or less. NFC operates at 13.56 M a distance between a sender and receiver of 10 cm or less. NFC operates at 13.56
Hz, and at rates ranging from 106 kbps to 424 kbps, as per the ISO/IEC 18000-3 a MHz and at rates ranging from 106 kbps to 424 kbps, as per the ISO/IEC 18000-3
ir interface <xref target="ECMA-340" format="default"/>. NFC builds upon RFID sy air interface <xref target="ECMA-340" format="default"/>. NFC builds upon RFID s
stems by allowing two-way communication between endpoints. NFC always involves a ystems by allowing two-way communication between endpoints. NFC always involves
n initiator and a target; the initiator actively generates an RF field that can an initiator and a target; the initiator actively generates a radio frequency (R
power a passive target. This enables NFC targets to take very simple form factor F) field that can power a passive target. This enables NFC targets to take very
s, such as tags, stickers, key fobs, or cards, while avoiding the need for batte simple form factors, such as tags, stickers, key fobs, or cards, while avoiding
ries. NFC peer-to-peer communication is possible, provided that both devices are the need for batteries. NFC peer-to-peer communication is possible, provided tha
powered.</t> t both devices are powered.</t>
<t>NFC has its very short transmission range of 10 cm or less, so the othe <t>NFC has a very short transmission range of 10 cm or less; thus, the oth
r hidden NFC devices behind outside the range cannot receive NFC signals. Theref er hidden NFC devices outside of that range cannot receive NFC signals. Therefor
ore, NFC often regarded as a secure communications technology.</t> e, NFC is often regarded as a secure communications technology.</t>
<t>In order to benefit from Internet connectivity, it is desirable for NFC <t>In order to benefit from Internet connectivity, it is desirable for NFC
-enabled devices to support IPv6, considering its large address space, along wit -enabled devices to support IPv6 because of its large address space and the avai
h tools for unattended operation, among other advantages. This document specifie lability of tools for unattended operation, along with other advantages. This do
s how IPv6 is supported over NFC by using IPv6 over Low-power Wireless Personal cument specifies how IPv6 is supported over NFC by using 6LoWPAN techniques <xre
Area Network (6LoWPAN) techniques [RFC4944], [RFC6282], [RFC6775]. 6LoWPAN is su f target="RFC4944"/> <xref target="RFC6282"/> <xref target="RFC6775"/>. 6LoWPAN
itable, considering that it was designed to support IPv6 over IEEE 802.15.4 netw is suitable, considering that it was designed to support IPv6 over IEEE 802.15.4
orks <xref target="IEEE802.15.4"/>, and some of the characteristics of the latte networks <xref target="IEEE802.15.4"/> and some of the characteristics of the l
r are similar to those of NFC.</t> atter are similar to those of NFC.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions and Terminology</name> <name>Conventions and Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
this document are to be interpreted as described in BCP 14 <xref target="RFC2119 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
" format="default"/> <xref target="RFC8174" format="default"/> when, and only wh NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
en, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
This specification requires readers to be familiar with all the terms and concep be interpreted as
ts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6 described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
LoWPANs): Overview, Assumptions, Problem Statement, and Goals" <xref target="RFC when, and only when, they appear in all capitals, as shown here.
4919"/>, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" <xref target </t>
="RFC4944"/>, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless <t>This specification requires readers to be familiar with all the terms and con
Personal Area Networks (6LoWPANs) <xref target="RFC6775"/>.</t> cepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks
<ul empty="true" spacing="normal"> (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" <xref target="
<li> RFC4919"/>, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" <xref tar
<t>6LoWPAN Node (6LN):</t> get="RFC4944"/>, and "Neighbor Discovery Optimization for IPv6 over Low-Power Wi
<ul empty="true" spacing="normal"> reless Personal Area Networks (6LoWPANs) <xref target="RFC6775"/>.</t>
<li> <dl newline="true" spacing="normal">
A 6LoWPAN node is any host or router participating in a LoW <dt>6LoWPAN Node (6LN):</dt><dd>A 6LoWPAN node is any host or router participati
PAN. This term is used when referring to situations in which either a host or ro ng in a LoWPAN. This term is used when referring to situations in which either a
uter can play the role described. host or router can play the role described.</dd>
</li> <dt>6LoWPAN Router (6LR):</dt><dd>An intermediate router in the LoWPAN that is a
</ul> ble to send and receive Router Advertisements (RAs) and Router Solicitations (RS
</li> s), as well as forward and route IPv6 packets. 6LoWPAN routers are present only
<li> in route-over topologies.</dd>
<t>6LoWPAN Router (6LR):</t> <dt>6LoWPAN Border Router (6LBR):</dt><dd>A border router located at the junctio
<ul empty="true" spacing="normal"> n of separate 6LoWPAN networks or between a 6LoWPAN network and another IP netwo
<li> rk. There may be one or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is th
An intermediate router in the LoWPAN that is able to send a e responsible authority for IPv6 prefix propagation for the 6LoWPAN network it i
nd receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as s serving. An isolated LoWPAN also contains a 6LBR in the network that provides
forward and route IPv6 packets. 6LoWPAN routers are present only in route-over the prefix(es) for the isolated network.</dd>
topologies. </dl>
</li>
</ul>
</li>
<li>
<t>6LoWPAN Border Router (6LBR):</t>
<ul empty="true" spacing="normal">
<li>
A border router located at the junction of separate 6LoWPAN
networks or between a 6LoWPAN network and another IP network. There may be one
or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the responsible authori
ty for IPv6 prefix propagation for the 6LoWPAN network it is serving. An isolat
ed LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for
the isolated network.
</li>
</ul>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overview of Near Field Communication Technology</name> <name>Overview of NFC Technology</name>
<t>This section presents an overview of NFC, focusing on the characteristi cs of NFC that are most relevant for supporting IPv6.</t> <t>This section presents an overview of NFC, focusing on the characteristi cs of NFC that are most relevant for supporting IPv6.</t>
<t>NFC enables simple, two-way, interaction between two devices, allowing users to perform contactless transactions, access digital content, and connect e lectronic devices with a single touch. NFC utilizes key elements in existing sta ndards for contactless card Technology, such as ISO/IEC 14443 A&amp;B and JIS-X 6319-4. NFC allows devices to share information at a distance up to 10 cm with a maximum physical layer bit rate of 424 kbps. </t> <t>NFC enables a simple, two-way interaction between two devices, allowing users to perform contactless transactions, access digital content, and connect electronic devices with a single touch. NFC utilizes key elements in existing st andards for contactless card technology, such as ISO/IEC 14443 A&amp;B and JIS-X 6319-4. NFC allows devices to share information at a distance up to 10 cm with a maximum physical layer bit rate of 424 kbps. </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Peer-to-peer Mode of NFC</name> <name>Peer-to-Peer Mode of NFC</name>
<t>NFC defines three modes of operation: card emulation, peer-to-peer, a <t>NFC defines three modes of operation: card emulation, peer-to-peer, a
nd reader/writer. Only the peer-to-peer mode allows two NFC-enabled devices to c nd reader/writer. Only the peer-to-peer mode allows two NFC-enabled devices to c
ommunicate with each other to exchange information bidirectionally. The other tw ommunicate with each other to exchange information bidirectionally. The other tw
o modes do not support two-way communications between two devices. Therefore, th o modes do not support two-way communication between two devices. Therefore, the
e peer-to-peer mode MUST used for IPv6 over NFC.</t> peer-to-peer mode <bcp14>MUST</bcp14> be used for IPv6 over NFC.</t>
</section> </section>
<section anchor="protocol-stack-sec" numbered="true" toc="default"> <section anchor="protocol-stack-sec" numbered="true" toc="default">
<name>Protocol Stack of NFC</name> <name>Protocol Stack of NFC</name>
<t>NFC defines a protocol stack for the peer-to-peer mode (<xref target= <t>NFC defines a protocol stack for the peer-to-peer mode (<xref target=
"protocol-stack-fig" format="default"/>). The peer-to-peer mode is offered by th "protocol-stack-fig" format="default"/>). The peer-to-peer mode is offered by th
e Activities Digital Protocol at the NFC Physical Layer. The NFC Logical Link La e Activities Digital Protocol at the NFC Physical Layer. The NFC Logical Link La
yer comprises the Logical Link Control Protocol (LLCP), and when IPv6 is used ov yer comprises the Logical Link Control Protocol (LLCP), and when IPv6 is used ov
er NFC, it also includes an IPv6-LLCP Binding. IPv6 and its underlying adaptatio er NFC, it also includes an IPv6-LLCP Binding. IPv6 and its underlying adaptatio
n Layer (i.e., IPv6-over-NFC adaptation layer) are placed directly on the top of n layer (i.e., IPv6-over-NFC Adaptation Layer) are placed directly on the top of
the IPv6-LLCP Binding. An IPv6 datagram is transmitted by the Logical Link Cont the IPv6-LLCP Binding.
rol Protocol (LLCP) with guaranteed delivery, two-way transmission of informatio An IPv6 datagram is transmitted by the LLCP with guaranteed delivery and two-way
n between the peer devices.</t> transmission of information between the peer devices.</t>
<figure anchor="protocol-stack-fig"> <figure anchor="protocol-stack-fig">
<name>Protocol Stack of NFC</name> <name>Protocol Stack of NFC</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------------+ - - - - - - - - - +----------------------------------------+ - - - - - - - - -
| Logical Link Control Protocol | NFC Logical | Logical Link Control Protocol | NFC Logical
| (LLCP) | Link Layer | (LLCP) | Link Layer
+----------------------------------------+ - - - - - - - - - +----------------------------------------+ - - - - - - - - -
| Activities | | Activities |
| Digital Protocol | NFC Physical | Digital Protocol | NFC Physical
+----------------------------------------+ Layer +----------------------------------------+ Layer
| RF Analog | | RF Analog |
+----------------------------------------+ - - - - - - - - - +----------------------------------------+ - - - - - - - - -
]]></artwork> ]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>The LLCP consists of Logical Link Control (LLC) and MAC Mapping. The <t>The LLCP consists of Logical Link Control (LLC) and MAC Mapping.
MAC Mapping integrates an existing RF protocol into the LLCP architecture. The L The MAC Mapping integrates an existing radio frequency (RF) protocol into the LL
LC contains three components (Link Management, Connection-oriented Transmission, CP architecture. The LLC contains three components: Link Management, Connection-
and Connectionless Transmission). The Link Management is responsible for serial oriented Transmission, and Connectionless Transmission.
izing all connection-oriented and connectionless LLC PDU (Protocol Data Unit) ex The Link Management is responsible for serializing all connection-oriented and c
changes and for aggregation and disaggregation of small PDUs. The Connection-ori onnectionless LLC PDU (Protocol Data Unit) exchanges; it is also responsible for
ented Transmission is responsible for maintaining all connection-oriented data e the aggregation and disaggregation of small PDUs. The Connection-oriented Trans
xchanges including connection set-up and termination. However, NFC links do not mission is responsible for maintaining all connection-oriented data exchanges, i
guarantee perfect wireless link quality, so some type of delays or variation in ncluding connection setup and termination. However, NFC links do not guarantee p
delay would be expected in any case. The Connectionless Transmission is responsi erfect wireless link quality, so some types of delay or variation in delay would
ble for handling unacknowledged data exchanges.</t> be expected in any case. The Connectionless Transmission is responsible for han
<t>In order to send an IPv6 packet over NFC, the packet MUST be passed d dling
own to the LLCP layer of NFC and carried by an Information Field in an LLCP Prot unacknowledged data exchanges.</t>
ocol Data Unit (I PDU). The LLCP does not support fragmentation and reassembly. <t>In order to send an IPv6 packet over NFC, the packet <bcp14>MUST</bcp
For IPv6 addressing or address configuration, the LLCP MUST provide related info 14> be passed down to the LLCP layer of NFC and carried by an Information field
rmation, such as link layer addresses, to its upper layer. The LLCP to IPv6 prot in an LLCP Protocol Data Unit (I PDU). The LLCP does not support fragmentation a
ocol binding MUST transfer the Source Service Access Point (SSAP) and Destinatio nd reassembly. For IPv6 addressing or address configuration, the LLCP <bcp14>MUS
n Service Access Point (DSAP) value to the IPv6 over NFC adaptation layer. SSAP T</bcp14> provide related information, such as link-layer addresses, to its uppe
is a Logical Link Control (LLC) address of the source NFC-enabled device with a r layer.
size of 6 bits, while DSAP means an LLC address of the destination NFC-enabled d
evice. Thus, SSAP is a source address, and DSAP is a destination address.</t> IPv6-LLCP Binding <bcp14>MUST</bcp14> transfer the Source Service Access Point (
<t>In addition, NFC links and host do not need to consider IP header bit SSAP) and Destination Service Access Point (DSAP) values to the IPv6-over-NFC Ad
s for QoS signaling, or utilize these meaningfully.</t> aptation Layer. The SSAP is an LLC address of the source NFC-enabled device with
a size of 6 bits, while the DSAP is an LLC address of the destination NFC-enabl
ed device. Thus, the SSAP is a source address and the DSAP is a destination addr
ess.</t>
<t>In addition, NFC links and hosts do not need to consider IP header bi
ts for QoS signaling or utilize these meaningfully.</t>
</section> </section>
<section anchor="nfc-addressing-sec" numbered="true" toc="default"> <section anchor="nfc-addressing-sec" numbered="true" toc="default">
<name>NFC-enabled Device Addressing</name> <name>NFC-Enabled Device Addressing</name>
<t>According to <xref target="LLCP-1.4" format="default"/>, NFC-enabled <t>According to <xref target="LLCP-1.4" format="default"/>, NFC-enabled
devices have two types of 6-bit addresses (i.e., SSAP and DSAP) to identify serv devices have two types of 6-bit addresses (i.e., SSAP and DSAP) to identify serv
ice access points. Several service access points can be installed on a NFC devic ice access points. Several service access points can be installed on an NFC devi
e. However, the SSAP and DSAP can be used as identifiers for NFC link connection ce. However, the SSAP and DSAP can be used as identifiers for NFC link connectio
s with the IPv6 over NFC adaptation layer. Therefore, the SSAP can be used to ge ns with the IPv6-over-NFC Adaptation Layer. Therefore, the SSAP can be used to g
nerate an IPv6 interface identifier. Address values between 00h and 0Fh of SSAP enerate an IPv6 Interface Identifier (IID). Address values between 00h and 0Fh o
and DSAP are reserved for identifying the well-known service access points, whic f SSAP and DSAP are reserved for identifying the well-known service access point
h are defined in the NFC Forum Assigned Numbers Register. Address values between s that are defined in the NFC Forum Assigned Numbers Register. Address values be
10h and 1Fh are assigned by the local LLC to services registered by local servi tween 10h and 1Fh are assigned by the local LLC to services registered by a loca
ce environment. In addition, address values between 0x2 and 0x3f are assigned by l service environment. In addition, address values between 0x2 and 0x3f are assi
the local LLC as a result of an upper layer service request. Therefore, the add gned by the local LLC as a result of an upper-layer service request. Therefore,
ress values between 0x2 and 0x3f can be used for generating IPv6 interface ident the address values between 0x2 and 0x3f can be used for generating IPv6 IIDs.</t
ifiers.</t> >
</section> </section>
<section anchor="nfc-mtu-sec" numbered="true" toc="default"> <section anchor="nfc-mtu-sec" numbered="true" toc="default">
<name>MTU of NFC Link Layer</name> <name>MTU of NFC Link Layer</name>
<t>As mentioned in <xref target="protocol-stack-sec" format="default"/>, <t>As mentioned in <xref target="protocol-stack-sec" format="default"/>,
when an IPv6 packet is transmitted, the packet MUST be passed down to LLCP of N when an IPv6 packet is transmitted, the packet <bcp14>MUST</bcp14> be passed do
FC and transported to an I PDU of LLCP of the NFC-enabled peer device.</t> wn to LLCP of NFC and transported to an I PDU of LLCP of the NFC-enabled peer de
<t>The information field of an I PDU contains a single service data unit vice.</t>
. The maximum number of octets in the information field is determined by the Max <t>The Information field of an I PDU contains a single service data unit
imum Information Unit (MIU) for the data link connection. The default value of t . The maximum number of octets in the Information field is determined by the Max
he MIU for I PDUs is 128 octets. The local and remote LLCs each establish and ma imum Information Unit (MIU) for the data link connection. The default value of t
intain distinct MIU values for each data link connection endpoint. Also, an LLC he MIU for I PDUs is 128 octets. The local and remote LLCs each establish and ma
may announce a larger MIU for a data link connection by transmitting an optional intain distinct MIU values for each data link connection endpoint. Also, an LLC
Maximum Information Unit Extension (MIUX) parameter within the information fiel may announce a larger MIU for a data link connection by transmitting an optional
d. If no MIUX parameter is transmitted, the MIU value is 128 bytes. Otherwise, t Maximum Information Unit Extension (MIUX) parameter within the Information fiel
he MTU size in NFC LLCP MUST be calculated from the MIU value as follows: </t> d. If no MIUX parameter is transmitted, the MIU value is 128 bytes. Otherwise, t
he MTU size in NFC LLCP <bcp14>MUST</bcp14> be calculated from the MIU value as
follows: </t>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
MTU = MIU = 128 + MIUX. MTU = MIU = 128 + MIUX
]]></artwork> ]]></artwork>
<t>According to <xref target="LLCP-1.4" format="default"/>, <xref target ="nfc-format-miux-fig" format="default"/> shows an example of the MIUX parameter TLV. The Type and Length fields of the MIUX parameter TLV have each a size of 1 byte. The size of the TLV Value field is 2 bytes.</t> <t>According to <xref target="LLCP-1.4" format="default"/>, <xref target ="nfc-format-miux-fig" format="default"/> shows an example of the MIUX parameter TLV. The Type and Length fields of the MIUX parameter TLV have each a size of 1 byte. The size of the TLV Value field is 2 bytes.</t>
<figure anchor="nfc-format-miux-fig"> <figure anchor="nfc-format-miux-fig">
<name>Example of MIUX Parameter TLV</name> <name>Example of MIUX Parameter TLV</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 0 1 2 3 0 0 1 2 3
0 8 6 1 1 0 8 6 1 1
+----------+----------+-----+-----------+ +----------+----------+-----+-----------+
| Type | Length | Value | | Type | Length | Value |
+----------+----------+-----+-----------+ +----------+----------+-----+-----------+
| 0x02 | 0x02 | 0x0 | 0x480 | | 0x02 | 0x02 | 0x0 | 0x480 |
+----------+----------+-----+-----------+ +----------+----------+-----+-----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t> <t>
When the MIUX parameter is used, the TLV Type field is 0x02 and the TLV Length f ield is 0x02. The MIUX parameter is encoded into the least significant 11 bits o f the TLV Value field. The unused bits in the TLV Value field is set to zero by the sender and ignored by the receiver. The maximum possible value of the TLV Va lue field is 0x7FF, and the maximum size of the LLCP MTU is 2175 bytes. As per t he present specification <xref target="LLCP-1.4" format="default"/>, the MIUX va lue MUST be 0x480 to support the IPv6 MTU requirement (of 1280 bytes) <xref targ et="RFC8200" format="default"/>.</t> When the MIUX parameter is used, the TLV Type field is 0x02 and the TLV Length f ield is 0x02. The MIUX parameter is encoded into the least significant 11 bits o f the TLV Value field. The unused bits in the TLV Value field are set to zero by the sender and ignored by the receiver. The maximum possible value of the TLV V alue field is 0x7FF, and the maximum size of the LLCP MTU is 2175 bytes. As per the present specification <xref target="LLCP-1.4" format="default"/>, the MIUX v alue <bcp14>MUST</bcp14> be 0x480 to support the IPv6 MTU requirement (1280 byte s) <xref target="RFC8200" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Specification of IPv6 over NFC</name> <name>Specification of IPv6 over NFC</name>
<t>NFC technology has requirements owing to low power consumption and allo <t>NFC technology has requirements owing to low power consumption and allo
wed protocol overhead. 6LoWPAN standards <xref target="RFC4944" format="default" wed protocol overhead. 6LoWPAN standards <xref target="RFC4944" format="default"
/>, <xref target="RFC6775" format="default"/>, and <xref target="RFC6282" format />
="default"/> provide useful functionality for reducing the overhead of IPv6 over <xref target="RFC6775" format="default"/> <xref target="RFC6282" format="default
NFC. This functionality consists of link-local IPv6 addresses and stateless IPv "/> provide useful functionality for reducing the overhead of IPv6 over NFC. Thi
6 address auto-configuration (see <xref target="addr-conf-sec" format="default"/ s functionality consists of link-local IPv6 addresses and stateless IPv6 address
> and <xref target="link-local-addr-sec" format="default"/>), Neighbor Discovery autoconfiguration (see Sections <xref target="addr-conf-sec" format="counter"/>
(see <xref target="nd-sec" format="default"/>) and header compression (see <xre and <xref target="link-local-addr-sec" format="counter"/>), Neighbor Discovery
f target="hc-sec" format="default"/>).</t> (see <xref target="nd-sec" format="default"/>), and header compression (see <xre
f target="hc-sec" format="default"/>).</t>
<section anchor="IPv6-over-NFC-protocol-stack-sec" numbered="true" toc="de fault"> <section anchor="IPv6-over-NFC-protocol-stack-sec" numbered="true" toc="de fault">
<name>Protocol Stack</name> <name>Protocol Stack</name>
<t> <xref target="IPv6-over-NFC-protocol-stack-fig" format="default"/> i llustrates the IPv6 over NFC protocol stack. Upper layer protocols can be trans port layer protocols (e.g., TCP and UDP), application layer protocols, and other s capable of running on top of IPv6. </t> <t> <xref target="IPv6-over-NFC-protocol-stack-fig" format="default"/> i llustrates the IPv6-over-NFC protocol stack. Upper-layer protocols can be trans port-layer protocols (e.g., TCP and UDP), application-layer protocols, and other protocols capable of running on top of IPv6. </t>
<figure anchor="IPv6-over-NFC-protocol-stack-fig"> <figure anchor="IPv6-over-NFC-protocol-stack-fig">
<name>Protocol Stack for IPv6 over NFC</name> <name>Protocol Stack for IPv6 over NFC</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------------+ +----------------------------------------+
| Upper Layer Protocols | | Upper-Layer Protocols |
+----------------------------------------+ +----------------------------------------+
| IPv6 | | IPv6 |
+----------------------------------------+ +----------------------------------------+
| Adaptation Layer for IPv6 over NFC | | Adaptation Layer for IPv6 over NFC |
+----------------------------------------+ +----------------------------------------+
| NFC Logical Link Layer | | NFC Logical Link Layer |
+----------------------------------------+ +----------------------------------------+
| NFC Physical Layer | | NFC Physical Layer |
+----------------------------------------+ +----------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t> The adaptation layer for IPv6 over NFC supports neighbor discovery, <t> The Adaptation Layer for IPv6 over NFC supports Neighbor Discovery,
stateless address auto-configuration, header compression, and fragmentation &am stateless address autoconfiguration, header compression, and fragmentation and
p; reassembly, based on 6LoWPAN. Note that 6LoWPAN Header compression <xref targ reassembly, based on 6LoWPAN. Note that 6LoWPAN header compression <xref target=
et="RFC6282"/> does not define header compression for TCP. The latter can still "RFC6282"/> does not define header compression for TCP.
be supported over IPv6 over NFC, albeit without the performance optimization of The latter can still be supported by IPv6 over NFC, albeit without the performan
header compression. ce optimization of header compression.
</t> </t>
</section> </section>
<section anchor="addr-conf-sec" numbered="true" toc="default"> <section anchor="addr-conf-sec" numbered="true" toc="default">
<name>Stateless Address Autoconfiguration</name> <name>Stateless Address Autoconfiguration</name>
<t>An NFC-enabled device performs stateless address autoconfiguration as <t>An NFC-enabled device performs stateless address autoconfiguration pe
per <xref target="RFC4862" format="default"/>. A 64-bit Interface identifier r <xref target="RFC4862" format="default"/>. A 64-bit IID for an NFC interface
(IID) for an NFC interface is formed by utilizing the 6-bit NFC SSAP (see <xr is formed by utilizing the 6-bit NFC SSAP (see <xref target="nfc-addressing-sec"
ef target="nfc-addressing-sec" format="default"/>). In the viewpoint of address format="default"/>). In the viewpoint of address configuration, such an IID sho
configuration, such an IID should guarantee a stable IPv6 address during the cou uld guarantee a stable IPv6 address during the course of a single connection bec
rse of a single connection, because each data link connection is uniquely identi ause each data link connection is uniquely identified by the pair of DSAP and SS
fied by the pair of DSAP and SSAP included in the header of each LLC PDU in NFC. AP included in the header of each LLC PDU in NFC.</t>
</t> <t>Following the guidance of <xref target="RFC7136" format="default"/>,
<t>Following the guidance of <xref target="RFC7136" format="default"/>, IIDs of all unicast addresses for NFC-enabled devices are 64 bits long and const
interface identifiers of all unicast addresses for NFC-enabled devices are 64 bi ructed by using the generation algorithm of random identifiers (RIDs) that are s
ts long and constructed by using the generation algorithm of random (but stable) table <xref target="RFC7217" format="default"/>.</t>
identifier (RID) <xref target="RFC7217" format="default"/>.</t> <t>The RID is an output created by the F() algorithm with input paramete
<t>The RID is an output which is created by the F() algorithm with input rs. One of the parameters is Net_Iface, and the NFC Link-Layer Address (i.e., th
parameters. One of the parameters is Net_Iface, and NFC Link Layer address (i.e e SSAP) <bcp14>MUST</bcp14> be a source of the Net_Iface parameter. The 6-bit ad
., SSAP) MUST be a source of the Net_Iface parameter. The 6-bit address of SSAP dress of the SSAP of NFC is short and can easily be targeted by attacks from a t
of NFC is short and easy to be targeted by attacks of third party (e.g., address hird party (e.g., address scanning). The F() algorithm with SHA-256 can provide
scanning). The F() algorithm with SHA-256 can provide secured and stable IIDs f secured and stable IIDs for NFC-enabled devices.
or NFC-enabled devices. In addition, an optional parameter, Network_ID is used In addition, an optional parameter, Network_ID, is used to increase the randomne
to increase the randomness of the generated IID with NFC link layer address (i.e ss of the generated IID with the NFC Link-Layer Address (i.e., SSAP). The secret
., SSAP). The secret key SHOULD be of at least 128 bits. It MUST be initialized key <bcp14>SHOULD</bcp14> be at least 128 bits. It <bcp14>MUST</bcp14> be init
to a pseudo-random number <xref target="RFC4086"/>.</t> ialized to a pseudorandom number <xref target="RFC4086"/>.</t>
</section> </section>
<section anchor="link-local-addr-sec" numbered="true" toc="default"> <section anchor="link-local-addr-sec" numbered="true" toc="default">
<name>IPv6 Link-Local Address</name> <name>IPv6 Link-Local Address</name>
<t>The IPv6 link-local address for an NFC-enabled device is formed by ap pending the IID to the prefix fe80::/64, as depicted in <xref target="IPv6-over -NFC-link-addr-fig" format="default"/>.</t> <t>The IPv6 Link-Local Address for an NFC-enabled device is formed by ap pending the IID to the prefix fe80::/64, as depicted in <xref target="IPv6-over- NFC-link-addr-fig" format="default"/>.</t>
<figure anchor="IPv6-over-NFC-link-addr-fig"> <figure anchor="IPv6-over-NFC-link-addr-fig">
<name>IPv6 link-local address in NFC</name> <name>IPv6 Link-Local Address in NFC</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 0 0 1 0 0 0 1
0 1 6 2 0 1 6 2
0 0 4 7 0 0 4 7
+----------+------------------+----------------------------+ +----------+------------------+----------------------------+
|1111111010| zeros | Interface Identifier | |1111111010| zeros | Interface Identifier |
+----------+------------------+----------------------------+ +----------+------------------+----------------------------+
. . . .
. <- - - - - - - - - - - 128 bits - - - - - - - - - - - -> . . <- - - - - - - - - - - 128 bits - - - - - - - - - - - -> .
. . . .
]]></artwork> ]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>The "Interface Identifier" can be a random and stable IID.</t> <t>The "Interface Identifier" can be a random and stable IID.</t>
</section> </section>
<section anchor="nd-sec" numbered="true" toc="default"> <section anchor="nd-sec" numbered="true" toc="default">
<name>Neighbor Discovery</name> <name>Neighbor Discovery</name>
<t>Neighbor Discovery Optimization for 6LoWPANs (<xref target="RFC6775" format="default"/>) describes the neighbor discovery approach in several 6LoWPAN topologies, such as mesh topology. NFC supports mesh topologies, but most of a ll applications would use a simple multi-hop network topology or directly connec ted peer-to-peer network because NFC RF range is very short.</t> <t>Neighbor Discovery Optimization for 6LoWPANs <xref target="RFC6775" f ormat="default"/> describes the Neighbor Discovery approach in several 6LoWPAN t opologies, such as mesh topology. NFC supports mesh topologies, but most applic ations would use a simple multi-hop network topology or directly connected peer- to-peer network because the NFC RF range is very short.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> When an NFC 6LoWPAN Node (6LN) is directly connected to an 6LBR,
the 6LN MUST register its address with the 6LBR by sending Neighbor Solicitation <li> When an NFC 6LN is directly connected to a 6LBR, the 6LN <bcp14>M
(NS) with the Extended Address Registration Option (EARO) <xref target="RFC8505 UST</bcp14> register its address with the 6LBR by sending Neighbor Solicitation
" format="default"/>, and Neighbor Advertisement (NA) is started. When the 6LN a (NS) with the Extended Address Registration Option (EARO) <xref target="RFC8505"
nd 6LBR are linked each other, an address is assigned to the 6LN. In this proces format="default"/>; then Neighbor Advertisement (NA) is started. When the 6LN a
s, Duplicate Address Detection (DAD) is not required.</li> nd 6LBR are linked to each other, an address is assigned to the 6LN. In this pro
<li> When two or more NFC LNs are connected to the 6LBR, two cases of cess, Duplicate Address Detection (DAD) is not required.</li>
topologies can be formed. One is a multi-hop topology, and the other is a star t <li>
opology based on the 6LBR. In multi-hop topology, LNs which have two or more lin When two or more NFC 6LNs are connected to the 6LBR, two cases of topologies can
ks with neighbor nodes may act as routers. In star topology, any of LNs can be a be formed. One is a multi-hop topology, and the other is a star topology based
router.</li> on the 6LBR. In the multi-hop topology, 6LNs that have two or more links with ne
<li>For receiving Router Solicitations and sending Router Advertisemen ighbor nodes may act as routers. In star topology, any of 6LNs can be a router.<
ts, the NFC 6LNs MUST follow Sections 5.3 and 5.4 of <xref target="RFC6775" form /li>
at="default"/>.</li> <li>For receiving RSs and RAs, the NFC 6LNs <bcp14>MUST</bcp14> follow
<li>When a NFC device is a 6LoWPAN Router (6LR) or a 6LBR, the NFC dev Sections <xref target="RFC6775" section="5.3" sectionFormat="bare"/> and <xref
ice MUST follow Section 6 and 7 of <xref target="RFC6775" format="default"/>.</l target="RFC6775" section="5.4" sectionFormat="bare"/> of <xref target="RFC6775"
i> format="default"/>.</li>
<li>When an NFC device is a 6LR or 6LBR, the NFC device <bcp14>MUST</b
cp14> follow Sections <xref target="RFC6775" section="6" sectionFormat="bare"/>
and <xref target="RFC6775" section="7" sectionFormat="bare"/> of <xref target="R
FC6775"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="dh-sec" numbered="true" toc="default"> <section anchor="dh-sec" numbered="true" toc="default">
<name>Dispatch Header</name> <name>Dispatch Header</name>
<t>All IPv6-over-NFC encapsulated datagrams are prefixed by an encapsula tion header stack consisting of a Dispatch value <xref target="IANA-6LoWPAN" for mat="default"/>. The only sequence currently defined for IPv6-over-NFC MUST be t he LOWPAN_IPHC compressed IPv6 header (see <xref target="hc-sec" format="default "/>) header followed by payload, as depicted in <xref target="IPv6-over-NFC-enc ap-format-fig" format="default"/> and <xref target="dispatch-value-fig" format=" default"/>.</t> <t>All IPv6-over-NFC encapsulated datagrams are prefixed by an encapsula tion header stack consisting of a dispatch value <xref target="IANA-6LoWPAN" for mat="default"/>. The only sequence currently defined for IPv6 over NFC <bcp14>MU ST</bcp14> be the LOWPAN_IPHC compressed IPv6 header (see <xref target="hc-sec" format="default"/>) followed by a payload, as depicted in <xref target="IPv6-ov er-NFC-encap-format-fig" format="default"/> and <xref target="dispatchvaluestabl e" format="default"/>.</t>
<figure anchor="IPv6-over-NFC-encap-format-fig"> <figure anchor="IPv6-over-NFC-encap-format-fig">
<name>A IPv6-over-NFC Encapsulated LOWPAN_IPHC Compressed IPv6 Datagra m</name> <name>An IPv6-over-NFC Encapsulated LOWPAN_IPHC Compressed IPv6 Datagr am</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+---------------+---------------+--------------+ +---------------+---------------+--------------+
| IPHC Dispatch | IPHC Header | Payload | | IPHC Dispatch | IPHC Header | Payload |
+---------------+---------------+--------------+ +---------------+---------------+--------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>The dispatch value (length: 1 octet) is treated as an unstructured na <t>The dispatch value (1 octet in length) is treated as an unstructured
mespace. Only a single pattern is used to represent current IPv6-over-NFC functi namespace. Only a single pattern is used to represent current IPv6-over-NFC func
onality.</t> tionality.</t>
<figure anchor="dispatch-value-fig"> <table anchor="dispatchvaluestable">
<name>Dispatch Values</name> <name>Dispatch Values</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <thead>
+------------+--------------------+-----------+ <tr>
| Pattern | Header Type | Reference | <th>Pattern</th>
+------------+--------------------+-----------+ <th>Header Type</th>
| 01 1xxxxx | LOWPAN_IPHC | [RFC6282] | <th>Reference</th>
+------------+--------------------+-----------+ </tr>
]]></artwork> </thead>
</figure> <tbody>
<tr>
<td>01 1xxxxx</td>
<td>LOWPAN_IPHC</td>
<td><xref target="RFC6282"
format="default"/> <xref target="RFC8025"
format="default"/></td>
</tr>
</tbody>
</table>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>Other IANA-assigned 6LoWPAN Dispatch values do not apply to this spec ification.</t> <t>Other IANA-assigned 6LoWPAN dispatch values do not apply to this spec ification.</t>
</section> </section>
<section anchor="hc-sec" numbered="true" toc="default"> <section anchor="hc-sec" numbered="true" toc="default">
<name>Header Compression</name> <name>Header Compression</name>
<t>Header compression as defined in <xref target="RFC6282" format="defau <t>Header compression as defined in <xref target="RFC6282" format="defau
lt"/>, which specifies the compression format for IPv6 datagrams on top of IEEE lt"/>, which specifies the compression format for IPv6 datagrams on top of IEEE
802.15.4, is REQUIRED in this document as the basis for IPv6 header compression 802.15.4, is <bcp14>REQUIRED</bcp14> in this document as the basis for IPv6 head
on top of NFC. All headers MUST be compressed according to RFC 6282 encoding for er compression on top of NFC. All headers <bcp14>MUST</bcp14> be compressed acco
mats. <!--The following text describes the principles of IPv6 address compressio rding to the encoding formats described in <xref target="RFC6282" format="defaul
n on top of NFC.--> </t> t"/>. <!--The following text describes the principles of IPv6 address compressio
<t>Therefore, IPv6 header compression in <xref target="RFC6282" format=" n on top of NFC.--> </t>
default"/> MUST be implemented. Further, implementations MUST also support Gener <t>Therefore, IPv6 header compression in <xref target="RFC6282" format="
ic Header Compression (GHC) of <xref target="RFC7400" format="default"/>.</t> default"/> <bcp14>MUST</bcp14> be implemented. Further, implementations <bcp14>M
<t>If a 16-bit address is required as a short address, it MUST be formed UST</bcp14> also support Generic Header Compression (GHC) as described in <xref
by padding the 6-bit NFC SSAP (NFC link-layer node address) to the left with ze target="RFC7400" format="default"/>.</t>
ros as shown in <xref target="shortaddr-fig" format="default"/>.</t> <t>If a 16-bit address is required as a short address, it <bcp14>MUST</b
cp14> be formed by padding the 6-bit NFC SSAP (NFC Link-Layer Node Address) to t
he left with zeros as shown in <xref target="shortaddr-fig" format="default"/>.<
/t>
<figure anchor="shortaddr-fig"> <figure anchor="shortaddr-fig">
<name>NFC short address format</name> <name>NFC Short Address Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding(all zeros)| NFC Addr. | | Padding(all zeros)| NFC Addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
</section> </section>
<section anchor="FAR-sec" numbered="true" toc="default"> <section anchor="FAR-sec" numbered="true" toc="default">
<name>Fragmentation and Reassembly Considerations</name> <name>Fragmentation and Reassembly Considerations</name>
<t>IPv6-over-NFC MUST NOT use fragmentation and reassembly (FAR) at the adaptation layer for the payloads as discussed in Section 3.4. The NFC link conn ection for IPv6 over NFC MUST be configured with an equivalent MIU size to suppo rt the IPv6 MTU requirement (of 1280 bytes). To this end, the MIUX value is 0x48 0.</t> <t>IPv6 over NFC <bcp14>MUST NOT</bcp14> use fragmentation and reassembl y (FAR) at the adaptation layer for the payloads as discussed in <xref target="n fc-mtu-sec"/>. The NFC link connection for IPv6 over NFC <bcp14>MUST</bcp14> be configured with an equivalent MIU size to support the IPv6 MTU requirement (1280 bytes). To this end, the MIUX value is 0x480.</t>
<t/> <t/>
</section> </section>
<section anchor="unicasting-sec" numbered="true" toc="default"> <section anchor="unicasting-sec" numbered="true" toc="default">
<name>Unicast and Multicast Address Mapping</name> <name>Unicast and Multicast Address Mapping</name>
<t>The address resolution procedure for mapping IPv6 non-multicast addre <t>The address resolution procedure for mapping IPv6 non-multicast addre
sses into NFC link-layer addresses follows the general description in Section 4. sses into NFC Link-Layer Addresses follows the general description in Sections <
6.1 and 7.2 of <xref target="RFC4861" format="default"/>, unless otherwise speci xref target="RFC4861" section="4.6.1" sectionFormat="bare"/> and <xref target="R
fied.</t> FC4861" section="7.2" sectionFormat="bare"/> of <xref target="RFC4861" format="d
<t>The Source/Target link-layer Address option has the following form wh efault"/>, unless otherwise specified.</t>
en the addresses are 6-bit NFC SSAP/DSAP (NFC link-layer node addresses).</t> <t>The Source/Target Link-Layer Address option has the following form wh
en the addresses are 6-bit NFC SSAP/DSAP (NFC Link-Layer Node Addresses).</t>
<figure anchor="unicasting-fig"> <figure anchor="unicasting-fig">
<name>Unicast address mapping</name> <name>Unicast Address Mapping</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | | Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Padding (all zeros) -+ +- Padding (all zeros) -+
| | | |
+- +-+-+-+-+-+-+ +- +-+-+-+-+-+-+
| | NFC Addr. | | | NFC Addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t> <dl spacing="normal" newline="true">
Option fields: <dt>Option fields:</dt>
</t> <dd>
<ul empty="true" spacing="normal"> <dl spacing="normal" newline="true">
<li> <dt>Type:</dt>
<t>Type: <dd>
</t> <dl newline="false" spacing="normal">
<ul spacing="normal"> <dt>1:</dt><dd>This is for the Source Link-Layer Address.</dd>
<li>1: for Source Link-layer address.</li> <dt>2:</dt><dd>This is for the Target Link-Layer Address.</dd>
<li>2: for Target Link-layer address.</li> </dl></dd>
</ul> <dt>Length:</dt><dd>This is the length of this option (including the Type and Le
</li> ngth fields) in units of 8 bits. The value of this field is 1 for 6-bit NFC nod
<li> e addresses.</dd>
<t> <dt>NFC address:</dt><dd>The 6-bit address in canonical bit order. This is the u
Length: nicast address the interface currently responds to.</dd></dl></dd></dl>
</t>
<ul spacing="normal">
<li>This is the length of this option (including the type and leng
th fields) in units of 8 bits. The value of this field is 1 for 6-bit NFC node
addresses.</li>
</ul>
</li>
<li>
<t>
NFC address:
</t>
<ul spacing="normal">
<li>The 6-bit address in canonical bit order. This is the unicast
address the interface currently responds to.</li>
</ul>
</li>
</ul>
<t> The NFC Link Layer does not support multicast. Therefore, packets ar e always transmitted <t> The NFC Link Layer does not support multicast. Therefore, packets ar e always transmitted
by unicast between two NFC-enabled devices. Even in the case where a 6LBR is att unicast between two NFC-enabled devices. Even in the case where a 6LBR is attach
ached to multiple 6LNs, ed to multiple 6LNs,
the 6LBR cannot do a multicast to all the connected 6LNs. If the 6LBR needs to s the 6LBR cannot multicast to all the connected 6LNs. If the 6LBR needs to send a
end a multicast packet to all its 6LNs, it has to replicate the packet and unica multicast packet to all its 6LNs, it has to replicate the packet and unicast it
st it on each link. However, this is not energy-efficient, and the central node, on each link. However, this is not energy-efficient; the central node, which is
which is battery-powered, must take particular care of power consumption. To fu battery-powered, must take particular care of power consumption. To further con
rther conserve power, the 6LBR MUST keep track of multicast listeners at NFC lin serve power, the 6LBR <bcp14>MUST</bcp14> keep track of multicast listeners at N
k-level granularity (not at subnet granularity), and it MUST NOT forward multica FC link-level granularity (not at subnet granularity), and it <bcp14>MUST NOT</b
st packets to 6LNs that have not registered as listeners for multicast groups t cp14> forward multicast packets to 6LNs that have not registered as listeners f
he packets belong to. In the opposite direction, a 6LN always has to send packet or multicast groups the packets belong to. In the opposite direction, a 6LN alwa
s to or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6 multicast ys has to send packets to or through the 6LBR. Hence, when a 6LN needs to trans
packet, the 6LN will unicast the corresponding NFC packet to the 6LBR.</t> mit an IPv6 multicast packet, the 6LN will unicast the corresponding NFC packet
to the 6LBR.</t>
</section> </section>
</section> </section>
<section anchor="connection-scenario-sec" numbered="true" toc="default"> <section anchor="connection-scenario-sec" numbered="true" toc="default">
<name>Internet Connectivity Scenarios</name> <name>Internet Connectivity Scenarios</name>
<section anchor="internet-conn-scenario-sec" numbered="true" toc="default" > <section anchor="internet-conn-scenario-sec" numbered="true" toc="default" >
<name>NFC-enabled Device Network Connected to the Internet</name> <name>NFC-Enabled Device Network Connected to the Internet</name>
<t><xref target="IPv6-over-NFC-Internet-conn-fig" format="default"/> ill <t><xref target="IPv6-over-NFC-Internet-conn-fig" format="default"/> ill
ustrates an example of an NFC-enabled device network connected to the Internet. ustrates an example of an NFC-enabled device network connected to the Internet.
The distance between 6LN and 6LBR is typically 10 cm or less. For example, a lap The distance between 6LN and 6LBR is typically 10 cm or less. For example, a lap
top computer that is connected to the Internet (e.g. via Wi-Fi, Ethernet, etc.) top computer that is connected to the Internet (e.g., via Wi-Fi, Ethernet, etc.)
may also support NFC and act as a 6LBR. Another NFC-enabled device may run as a may also support NFC and act as a 6LBR. Another NFC-enabled device may run as a
6LN and communicate with the 6LBR, as long as both are within each other's range 6LN and communicate with the 6LBR, as long as both are within each other's rang
.</t> e.</t>
<figure anchor="IPv6-over-NFC-Internet-conn-fig"> <figure anchor="IPv6-over-NFC-Internet-conn-fig">
<name>NFC-enabled device network connected to the Internet</name> <name>NFC-Enabled Device Network Connected to the Internet</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
NFC link NFC link
6LN ------------------- 6LBR -------( Internet )--------- CN 6LN ------------------- 6LBR -------( Internet )--------- CN
. . . . . .
. <- - - - Subnet - - -> . < - - - IPv6 connection - - -> . . <- - - - Subnet - - -> . < - - - IPv6 connection - - -> .
. . to the Internet . . . to the Internet .
]]></artwork> ]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>Two or more 6LNs may be connected with a 6LBR, but each connection us es different IPv6 prefix. The 6LBR is acting as a router and forwarding packets between 6LNs and the Internet. Also, the 6LBR MUST ensure address collisions do not occur because the 6LNs are connected to the 6LBR like a start topology, so t he 6LBR checks whether IPv6 addresses are duplicate or not, since 6LNs need to r egister their addresses with the 6LBR.</t> <t>Two or more 6LNs may be connected with a 6LBR, but each connection us es a different IPv6 prefix. The 6LBR is acting as a router and forwarding packet s between 6LNs and the Internet. Also, the 6LBR <bcp14>MUST</bcp14> ensure addre ss collisions do not occur because the 6LNs are connected to the 6LBR like a sta rt topology, so the 6LBR checks whether or not IPv6 addresses are duplicates, si nce 6LNs need to register their addresses with the 6LBR.</t>
</section> </section>
<section anchor="adhoc-conn-scenario-sec" numbered="true" toc="default"> <section anchor="adhoc-conn-scenario-sec" numbered="true" toc="default">
<name>Isolated NFC-enabled Device Network</name> <name>Isolated NFC-Enabled Device Network</name>
<t>In some scenarios, the NFC-enabled device network may permanently be <t>In some scenarios, the NFC-enabled device network may permanently be
a simple isolated network as shown in the <xref target="IPv6-over-NFC-isolated-n a simple isolated network as shown in <xref target="IPv6-over-NFC-isolated-net-f
et-fig" format="default"/>.</t> ig" format="default"/>.</t>
<figure anchor="IPv6-over-NFC-isolated-net-fig"> <figure anchor="IPv6-over-NFC-isolated-net-fig">
<name>Isolated NFC-enabled device network</name> <name>Isolated NFC-Enabled Device Network</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
6LN 6LN - - - - - 6LN 6LN - - - - -
| | . | | .
NFC link - >| NFC link - >| . NFC link - >| NFC link - >| .
| | . | | .
6LN ---------------------- 6LR ---------------------- 6LR Subnet 6LN ---------------------- 6LR ---------------------- 6LR Subnet
. NFC link NFC link | . . NFC link NFC link | .
. | . . | .
. NFC link - >| . . NFC link - >| .
. 6LN - - - - - . 6LN - - - - -
. . . .
. < - - - - - - - - - - Subnet - - - - - - - - - - > . . < - - - - - - - - - - Subnet - - - - - - - - - - > .
]]></artwork>
]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>In multihop (i.e., more complex) topologies, the 6LR can also do the same task, but then Duplicate Address Detection (DAD) requires the extensions f or multihop networks such as the ones in <xref target="RFC6775"/>.</t> <t>In multihop (i.e., more complex) topologies, the 6LR can also do the same task. DAD requires the extensions for multihop networks, such as the ones i n <xref target="RFC6775"/>.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>There are no IANA considerations related to this document.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Neighbor Discovery in unencrypted wireless device networks may be susce ptible to various threats as described in <xref target="RFC3756" format="default "/>.</t> <t>Neighbor Discovery in unencrypted wireless device networks may be susce ptible to various threats as described in <xref target="RFC3756" format="default "/>.</t>
<t>Per the NFC Logical Link Control Protocol <xref target="LLCP-1.4" forma t="default"/>:</t> <t>Per the NFC Logical Link Control Protocol <xref target="LLCP-1.4" forma t="default"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>LLCP of NFC provides protection of user data to ensure confidentia lity of communications. The confidentiality mechanism involves the encryption of user service data with a secret key that has been established during link activ ation.</li> <li>LLCP of NFC provides protection of user data to ensure confidentia lity of communications. The confidentiality mechanism involves the encryption of user service data with a secret key that has been established during link activ ation.</li>
<li>LLCP of NFC has two modes (i.e., ad-hoc mode and authenticated mod <li>LLCP of NFC has two modes (i.e., ad hoc mode and authenticated mod
e) for secure data transfer. Ad-hoc secure data transfer can be established betw e) for secure data transfer. Ad hoc secure data transfer can be established betw
een two communication parties without any prior knowledge of the communication p een two communication parties without any prior knowledge of the communication p
artner. Ad-hoc secure data transfer can be vulnerable to Man-In-The-Middle (MITM artner. Ad hoc secure data transfer can be vulnerable to on-path attacks. Authen
) attacks. Authenticated secure data transfer provides protection against Man-In ticated secure data transfer provides protection against on-path attacks. In the
-The-Middle (MITM) attacks. In the initial bonding step, the two communicating p initial bonding step, the two communicating parties store a shared secret along
arties store a shared secret along with a Bonding Identifier.</li> with a Bonding Identifier.</li>
<li>For all subsequent interactions, the communicating parties re-use <li>For all subsequent interactions, the communicating parties reuse t
the shared secret and compute only the unique encryption key for that session. S he shared secret and compute only the unique encryption key for that session. Se
ecure data transfer is based on the cryptographic algorithms defined in the NFC cure data transfer is based on the cryptographic algorithms defined in the NFC A
Authentication Protocol <xref target="NAP-1.0" format="default"/>.</li> uthentication Protocol <xref target="NAP-1.0" format="default"/>.</li>
</ul> </ul>
<t>Furthermore, NFC is considered by many to offer intrinsic security prop <t>Furthermore, NFC is considered by many to offer intrinsic security prop
erties due to its short link range. When interface identifiers (IIDs) are genera erties due to its short link range. When IIDs are generated, devices and users a
ted, devices and users are required to consider mitigating various threats, such re required to consider mitigating various threats, such as correlation of activ
as correlation of activities over time, location tracking, device-specific vuln ities over time, location tracking, device-specific vulnerability exploitation,
erability exploitation, and address scanning. However, IPv6-over-NFC uses a <xre and address scanning. However, IPv6 over NFC uses an RID <xref target="RFC7217"
f target="RFC7217" format="default">random (but stable) identifier (RID)</xref> format="default"/> as an IPv6 IID; NFC applications use short-lived connections
as an IPv6 interface identifier, and NFC applications use short-lived connection and a different address is used for each connection where the latter is of extre
s, and a different address is used for each connection, where the latter is of e mely short duration.</t>
xtremely short duration.</t>
</section>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>We are grateful to the members of the IETF 6lo working group.</t>
<t> Michael Richardson, Suresh Krishnan, Pascal Thubert, Carsten Bormann,
Alexandru Petrescu, James Woodyatt, Dave Thaler, Samita Chakrabarti, Gabriel Mon
tenegro, Erik Kline and Carles Gomez Montenegro have provided valuable feedback
for this document.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
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.xm
l"?> 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 fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--
&rfc4944;
&rfc2119;
-->
<reference anchor="LLCP-1.4" target="https://nfc-forum.org/build/ specifications"> <reference anchor="LLCP-1.4" target="https://nfc-forum.org/build/ specifications">
<front> <front>
<title>NFC Logical Link Control Protocol, Version 1.4</title> <title>Logical Link Control Protocol Technical Specification</t
<author fullname="" initials="" surname="NFC Forum"/> itle>
<date month="January" year="2021"/> <author>
</front> <organization>NFC Forum</organization>
<seriesInfo name="NFC Forum Technical Specification" value=""/> </author>
</reference> <date month="December" year="2022"/>
<reference anchor="NAP-1.0" target="https://nfc-forum.org/build/s
pecifications">
<front>
<title>NFC Authentication Protocol Candidate Technical Specific
ation, Version 1.0</title>
<author fullname="" initials="" surname="NFC Forum"/>
<date month="December" year="2020"/>
</front>
<seriesInfo name="NFC Forum Technical Specification" value=""/>
</reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/in
fo/rfc4086" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.
xml">
<front>
<title>Randomness Requirements for Security</titl
e>
<author fullname="D. Eastlake 3rd" initials="D."
surname="Eastlake 3rd"/>
<author fullname="J. Schiller" initials="J." surn
ame="Schiller"/>
<author fullname="S. Crocker" initials="S." surna
me="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptogra
phic algorithms that foil pattern analysis attempts. However, the security of th
ese systems is dependent on generating secret quantities for passwords, cryptogr
aphic keys, and similar quantities. The use of pseudo-random processes to genera
te secret quantities can result in pseudo-security. A sophisticated attacker may
find it easier to reproduce the environment that produced the secret quantities
and to search the resulting small set of possibilities than to locate the quant
ities in the whole of the potential number space.</t>
<t>Choosing random quantities to foil a resourcef
ul and motivated adversary is surprisingly difficult. This document points out m
any pitfalls in using poor entropy sources or traditional pseudo-random number g
eneration techniques for generating such quantities. It recommends the use of tr
uly random hardware techniques and shows that the existing hardware on many syst
ems can be used for this purpose. It provides suggestions to ameliorate the prob
lem when a hardware solution is not available, and it gives examples of how larg
e such quantities need to be for some applications. This document specifies an I
nternet Best Current Practices for the Internet Community, and requests discussi
on and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC4919" target="https://www.rfc-editor.org/in
fo/rfc4919" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4919.
xml">
<front>
<title>IPv6 over Low-Power Wireless Personal Area
Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals</title
>
<author fullname="N. Kushalnagar" initials="N." s
urname="Kushalnagar"/>
<author fullname="G. Montenegro" initials="G." su
rname="Montenegro"/>
<author fullname="C. Schumacher" initials="C." su
rname="Schumacher"/>
<date month="August" year="2007"/>
<abstract>
<t>This document describes the assumption
s, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks.
The set of goals enumerated in this document form an initial set only. This mem
o provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4919"/>
<seriesInfo name="DOI" value="10.17487/RFC4919"/>
</reference>
<reference anchor="RFC4944" target="https://www.rfc-editor.org/in
fo/rfc4944" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.
xml">
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks
</title>
<author fullname="G. Montenegro" initials="G." surname="Montene
gro"/>
<author fullname="N. Kushalnagar" initials="N." surname="Kushal
nagar"/>
<author fullname="J. Hui" initials="J." surname="Hui"/>
<author fullname="D. Culler" initials="D." surname="Culler"/>
<date month="September" year="2007"/>
<abstract>
<t>This document describes the frame format for transmission
of IPv6 packets and the method of forming IPv6 link-local addresses and stateles
sly autoconfigured addresses on IEEE 802.15.4 networks. Additional specificatio
ns include a simple header compression scheme using shared context and provision
s for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="4944"/> <refcontent>Version 1.4</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC4944"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/in
fo/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels
</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used t
o signify the requirements in the specification. These words are often capitali
zed. This document defines these words as they should be interpreted in IETF do
cuments. This document specifies an Internet Best Current Practices for the Int
ernet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC6775" target="https://www.rfc-editor.org/info /rfc6775" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xm l"> <reference anchor="NAP-1.0" target="https://nfc-forum.org/build/s pecifications">
<front> <front>
<title>Neighbor Discovery Optimization for IPv6 over Low-Power <title>NFC Authentication Protocol Technical Specification</tit
Wireless Personal Area Networks (6LoWPANs)</title> le>
<author fullname="Z. Shelby" initials="Z." role="editor" surnam <author>
e="Shelby"/> <organization>NFC Forum</organization>
<author fullname="S. Chakrabarti" initials="S." surname="Chakra </author>
barti"/> <date month="December" year="2022"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"
/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="November" year="2012"/>
<abstract>
<t>The IETF work in IPv6 over Low-power Wireless Personal Are
a Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other simi
lar link technologies have limited or no usage of multicast signaling due to ene
rgy conservation. In addition, the wireless network may not strictly follow the
traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was no
t designed for non- transitive wireless links, as its reliance on the traditiona
l IPv6 link concept and its heavy use of multicast make it inefficient and somet
imes impractical in a low-power and lossy network. This document describes simp
le optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and dupl
icate address detection for Low- power Wireless Personal Area Networks and simil
ar networks. The document thus updates RFC 4944 to specify the use of the optim
izations defined here. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6775"/> <refcontent>Verison 1.0</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC6775"/>
</reference> </reference>
<reference anchor="RFC6282" target="https://www.rfc-editor.org/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"
info/rfc6282" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.628 />
2.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml"
<front> />
<title>Compression Format for IPv6 Datagrams over IEEE <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"
802.15.4-Based Networks</title> />
<author fullname="J. Hui" initials="J." role="editor" s <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
urname="Hui"/> />
<author fullname="P. Thubert" initials="P." surname="Th <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"
ubert"/> />
<date month="September" year="2011"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"
<abstract> />
<t>This document updates RFC 4944, "Transmission <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"
of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 h />
eader compression format for IPv6 packet delivery in Low Power Wireless Personal <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"
Area Networks (6LoWPANs). The compression format relies on shared context to a />
llow compression of arbitrary prefixes. How the information is maintained in th <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7136.xml"
at shared context is out of scope. This document specifies compression of multi />
cast addresses and a framework for compressing next headers. UDP header compres <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"
sion is specified within this framework. [STANDARDS-TRACK]</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7400.xml"
</front> />
<seriesInfo name="RFC" value="6282"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml"
<seriesInfo name="DOI" value="10.17487/RFC6282"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
/>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"
info/rfc4862" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.486 />
2.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"
<front> />
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Th
omson"/>
<author fullname="T. Narten" initials="T." surname="Nar
ten"/>
<author fullname="T. Jinmei" initials="T." surname="Jin
mei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes
in deciding how to autoconfigure its interfaces in IP version 6. The autoconfi
guration process includes generating a link-local address, generating global add
resses via stateless address autoconfiguration, and the Duplicate Address Detect
ion procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/
info/rfc4861" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.486
1.xml">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</titl
e>
<author fullname="T. Narten" initials="T." surname="Nar
ten"/>
<author fullname="E. Nordmark" initials="E." surname="N
ordmark"/>
<author fullname="W. Simpson" initials="W." surname="Si
mpson"/>
<author fullname="H. Soliman" initials="H." surname="So
liman"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the Neighbor Discovery
protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery
to discover each other's presence, to determine each other's link-layer addresse
s, to find routers, and to maintain reachability information about the paths to
active neighbors. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4861"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
</reference>
<reference anchor="RFC7136" target="https://www.rfc-editor.org/
info/rfc7136" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.713
6.xml">
<front>
<title>Significance of IPv6 Interface Identifiers</titl
e>
<author fullname="B. Carpenter" initials="B." surname="
Carpenter"/>
<author fullname="S. Jiang" initials="S." surname="Jian
g"/>
<date month="February" year="2014"/>
<abstract>
<t>The IPv6 addressing architecture includes a un
icast interface identifier that is used in the creation of many IPv6 addresses.
Interface identifiers are formed by a variety of methods. This document clarif
ies that the bits in an interface identifier have no meaning and that the entire
identifier should be treated as an opaque value. In particular, RFC 4291 defin
es a method by which the Universal and Group bits of an IEEE link-layer address
are mapped into an IPv6 unicast interface identifier. This document clarifies t
hat those two bits are significant only in the process of deriving interface ide
ntifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="7136"/>
<seriesInfo name="DOI" value="10.17487/RFC7136"/>
</reference>
<reference anchor="RFC7217" target="https://www.rfc-editor.org/
info/rfc7217" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.721
7.xml">
<front>
<title>A Method for Generating Semantically Opaque Inte
rface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
<author fullname="F. Gont" initials="F." surname="Gont"
/>
<date month="April" year="2014"/>
<abstract>
<t>This document specifies a method for generatin
g IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfigur
ation (SLAAC), such that an IPv6 address configured using this method is stable
within each subnet, but the corresponding Interface Identifier changes when the
host moves from one network to another. This method is meant to be an alternati
ve to generating Interface Identifiers based on hardware addresses (e.g., IEEE L
AN Media Access Control (MAC) addresses), such that the benefits of stable addre
sses can be achieved without sacrificing the security and privacy of users. The
method specified in this document applies to all prefixes a host may be employi
ng, including link-local, global, and unique-local prefixes (and their correspon
ding addresses).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7217"/>
<seriesInfo name="DOI" value="10.17487/RFC7217"/>
</reference>
<reference anchor="RFC7400" target="https://www.rfc-editor.org/
info/rfc7400" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.740
0.xml">
<front>
<title>6LoWPAN-GHC: Generic Header Compression for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
<author fullname="C. Bormann" initials="C." surname="Bo
rmann"/>
<date month="November" year="2014"/>
<abstract>
<t>RFC 6282 defines header compression in 6LoWPAN
packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area
Network"). The present document specifies a simple addition that enables the co
mpression of generic headers and header-like payloads, without a need to define
a new header compression scheme for each such new header or header-like payload.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7400"/>
<seriesInfo name="DOI" value="10.17487/RFC7400"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/
info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leib
a"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may b
e used in protocol specifications. This document aims to reduce the ambiguity b
y clarifying that only UPPERCASE usage of the key words have the defined special
meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/in
fo/rfc8200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.
xml">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specif
ication</title>
<author fullname="S. Deering" initials="S." surna
me="Deering"/>
<author fullname="R. Hinden" initials="R." surnam
e="Hinden"/>
<author>
<organization>RFC Publisher</organization>
</author>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Inter
net Protocol (IPv6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/in
fo/rfc8505" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.
xml">
<front>
<title>Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery</title>
<author fullname="P. Thubert" initials="P." role="edito
r" surname="Thubert"/>
<author fullname="E. Nordmark" initials="E." surname="N
ordmark"/>
<author fullname="S. Chakrabarti" initials="S." surname
="Chakrabarti"/>
<author fullname="C. Perkins" initials="C." surname="Pe
rkins"/>
<date month="November" year="2018"/>
<abstract>
<t>This specification updates RFC 6775 -- the Low
-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification
-- to clarify the role of the protocol as a registration technique and simplify
the registration operation in 6LoWPAN routers, as well as to provide enhancemen
ts to the registration capabilities and mobility detection for different network
topologies, including the Routing Registrars performing routing for host routes
and/or proxy Neighbor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
</references> </references>
<references title="Informative References"> <references title="Informative References">
<reference anchor="ECMA-340" target="https://www.ecma-international .org/wp-content/uploads/ECMA-340_3rd_edition_june_2013.pdf"> <reference anchor="ECMA-340" target="https://www.ecma-international .org/wp-content/uploads/ECMA-340_3rd_edition_june_2013.pdf">
<front> <front>
<title>Near Field Communication - Interface and Protocol (NFCIP <title>Near Field Communication - Interface and Protocol (NFCIP
-1) 3rd Ed.</title> -1)</title>
<author/> <author>
<organization>ECMA International</organization>
</author>
<date month="June" year="2013"/> <date month="June" year="2013"/>
</front> </front>
<seriesInfo name="ECMA International" value=""/> <seriesInfo name="ECMA" value="340"/>
<refcontent>3rd Edition</refcontent>
</reference> </reference>
<reference anchor="IEEE802.15.4" target="https://standards.ieee.org /ieee/802.15.4/7029/"> <reference anchor="IEEE802.15.4" target="https://ieeexplore.ieee.or g/document/9144691">
<front> <front>
<title>IEEE Standard for Low-Rate Wireless Networks, IEEE Std. <title>IEEE Standard for Low-Rate Wireless Networks</title>
802.15.4-2020</title> <author>
<author fullname="" initials="" surname="IEEE Computer Society" <organization>IEEE</organization>
/> </author>
<date month="July" year="2020"/> <date month="July" year="2020"/>
</front> </front>
<seriesInfo name="IEEE" value=""/> <seriesInfo name="IEEE Std" value="802.15.4-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
</reference> </reference>
<reference anchor="IANA-6LoWPAN" target="https://www.iana.org/assig nments/_6lowpan-parameters"> <reference anchor="IANA-6LoWPAN" target="https://www.iana.org/assig nments/_6lowpan-parameters">
<front> <front>
<title>IPv6 Low Power Personal Area Network Parameters</title> <title>IPv6 Low Power Personal Area Network Parameters</title>
<author fullname="" initials="" surname="Internet Assigned Numb <author>
ers Authority (IANA)"/> <organization>IANA</organization>
<date day="03" month="December" year="2021"/> </author>
</front> </front>
</reference> </reference>
<reference anchor="RFC3756" target="https://www.rfc-editor.org/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml"
info/rfc3756" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.375 />
6.xml"> </references>
<front>
<title>IPv6 Neighbor Discovery (ND) Trust Models and Th
reats</title>
<author fullname="P. Nikander" initials="P." role="edit
or" surname="Nikander"/>
<author fullname="J. Kempf" initials="J." surname="Kemp
f"/>
<author fullname="E. Nordmark" initials="E." surname="N
ordmark"/>
<date month="May" year="2004"/>
<abstract>
<t>The existing IETF standards specify that IPv6
Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protecte
d with IPsec Authentication Header (AH). However, the current specifications li
mit the security solutions to manual keying due to practical problems faced with
automatic key management. This document specifies three different trust models
and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of
this discussion is to define the requirements for Securing IPv6 Neighbor Discov
ery. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3756"/>
<seriesInfo name="DOI" value="10.17487/RFC3756"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We are grateful to the members of the IETF 6lo Working Group.</t>
<t><contact fullname="Michael Richardson"/>, <contact fullname="Suresh
Krishnan"/>, <contact fullname="Pascal Thubert"/>, <contact
fullname="Carsten Bormann"/>, <contact fullname="Alexandru Petrescu"/>,
<contact fullname="James Woodyatt"/>, <contact fullname="Dave Thaler"/>,
<contact fullname="Samita Chakrabarti"/>, <contact fullname="Gabriel
Montenegro"/>, <contact fullname="Erik Kline"/>, and <contact
fullname="Carles Gomez Montenegro"/> have provided valuable feedback for
this document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 84 change blocks. 
859 lines changed or deleted 425 lines changed or added

This html diff was produced by rfcdiff 1.48.