draft-ietf-6lo-nfc-12.txt   draft-ietf-6lo-nfc-13.txt 
6Lo Working Group Y. Choi, Ed. 6Lo Working Group Y. Choi, Ed.
Internet-Draft Y-G. Hong Internet-Draft Y-G. Hong
Intended status: Standards Track ETRI Intended status: Standards Track ETRI
Expires: May 9, 2019 J-S. Youn Expires: August 14, 2019 J-S. Youn
Dongeui Univ Dongeui Univ
D-K. Kim D-K. Kim
KNU KNU
J-H. Choi J-H. Choi
Samsung Electronics Co., Samsung Electronics Co.,
November 5, 2018 February 10, 2019
Transmission of IPv6 Packets over Near Field Communication Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-12 draft-ietf-6lo-nfc-13
Abstract Abstract
Near field communication (NFC) is a set of standards for smartphones Near field communication (NFC) is a set of standards for smartphones
and portable devices to establish radio communication with each other and portable devices to establish radio communication with each other
by touching them together or bringing them into proximity, usually no by touching them together or bringing them into proximity, usually no
more than 10 cm. NFC standards cover communications protocols and more than 10 cm. NFC standards cover communications protocols and
data exchange formats, and are based on existing radio-frequency data exchange formats, and are based on existing radio-frequency
identification (RFID) standards including ISO/IEC 14443 and FeliCa. identification (RFID) standards including ISO/IEC 14443 and FeliCa.
The standards include ISO/IEC 18092 and those defined by the NFC The standards include ISO/IEC 18092 and those defined by the NFC
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 9, 2019. This Internet-Draft will expire on August 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6 3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6
3.4. MTU of NFC Link Layer . . . . . . . . . . . . . . . . . . 6 3.4. MTU of NFC Link Layer . . . . . . . . . . . . . . . . . . 6
4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 7 4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 7
4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 7 4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 7
4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 9 4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 9
4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10
4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 11 4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 11
4.7. Header Compression . . . . . . . . . . . . . . . . . . . 11 4.7. Header Compression . . . . . . . . . . . . . . . . . . . 11
4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 4.8. Fragmentation and Reassembly Considerations . . . . . . . 12
4.9. Unicast and Multicast Address Mapping . . . . . . . . . . 12 4.9. Unicast and Multicast Address Mapping . . . . . . . . . . 12
5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 13 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 13
5.1. NFC-enabled Device Connected to the Internet . . . . . . 13 5.1. NFC-enabled Device Connected to the Internet . . . . . . 13
5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 14 5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
skipping to change at page 4, line 34 skipping to change at page 4, line 34
simple touch. simple touch.
NFC's bidirectional communication ability is ideal for establishing NFC's bidirectional communication ability is ideal for establishing
connections with other technologies by the simplicity of touch. In connections with other technologies by the simplicity of touch. In
addition to the easy connection and quick transactions, simple data addition to the easy connection and quick transactions, simple data
sharing is also available. sharing is also available.
3.1. Peer-to-peer Mode of NFC 3.1. Peer-to-peer Mode of NFC
NFC-enabled devices are unique in that they can support three modes NFC-enabled devices are unique in that they can support three modes
of operation: card emulation, peer-to-peer, and reader/writer. Peer- of operation: card emulation, peer-to-peer, and reader/writer. Only
to-peer mode enables two NFC-enabled devices to communicate with each peer-to-peer in the three modes enables two NFC-enabled devices to
other to exchange information and share files, so that users of NFC- communicate with each other to exchange information and share files,
enabled devices can quickly share contact information and other files so that users of NFC-enabled devices can quickly share contact
with a touch. Therefore, an NFC-enabled device can securely send information and other files with a touch. Therefore, the peer-to-
IPv6 packets to any corresponding node on the Internet when an NFC- peer mode is used for ipv6-over-nfc. In addition, NFC-enabled
enabled gateway is linked to the Internet. devices can securely send IPv6 packets to any corresponding node on
the Internet when an NFC-enabled gateway is linked to the Internet.
3.2. Protocol Stacks of NFC 3.2. Protocol Stacks of NFC
IP can use the services provided by the Logical Link Control Protocol IP can use the services provided by the Logical Link Control Protocol
(LLCP) in the NFC stack to provide reliable, two-way transport of (LLCP) in the NFC stack to provide reliable, two-way transmission of
information between the peer devices. Figure 1 depicts the NFC P2P information between the peer devices. Figure 1 depicts the NFC P2P
protocol stack with IPv6 bindings to LLCP. protocol stack with IPv6 bindings to LLCP.
For data communication in IPv6 over NFC, an IPv6 packet MUST be For data communication in IPv6 over NFC, an IPv6 packet MUST be
passed down to LLCP of NFC and transported to an Information (I) and passed down to LLCP of NFC and transported to an Information (I) and
an Unnumbered Information (UI) Field in Protocol Data Unit (PDU) of an Unnumbered Information (UI) Field in Protocol Data Unit (PDU) of
LLCP of the NFC-enabled peer device. LLCP does not support LLCP of the NFC-enabled peer device. LLCP does not support
fragmentation and reassembly. For IPv6 addressing or address fragmentation and reassembly. For IPv6 addressing or address
configuration, LLCP MUST provide related information, such as link configuration, LLCP MUST provide related information, such as link
layer addresses, to its upper layer. The LLCP to IPv6 protocol layer addresses, to its upper layer. The LLCP to IPv6 protocol
skipping to change at page 5, line 41 skipping to change at page 5, line 42
| | | | | |
| RF Analog | | | RF Analog | |
| | | | | |
+----------------------------------------+ <------------------ +----------------------------------------+ <------------------
Figure 1: Protocol Stacks of NFC Figure 1: Protocol Stacks of NFC
The LLCP consists of Logical Link Control (LLC) and MAC Mapping. The The LLCP consists of Logical Link Control (LLC) and MAC Mapping. The
MAC Mapping integrates an existing RF protocol into the LLCP MAC Mapping integrates an existing RF protocol into the LLCP
architecture. The LLC contains three components, such as Link architecture. The LLC contains three components, such as Link
Management, Connection-oriented Transport, and Connection-less Management, Connection-oriented Transmission, and Connection-less
Transport. The Link Management component is responsible for Transmission. The Link Management component is responsible for
serializing all connection-oriented and connection-less LLC PDU serializing all connection-oriented and connection-less LLC PDU
(Protocol Data Unit) exchanges and for aggregation and disaggregation (Protocol Data Unit) exchanges and for aggregation and disaggregation
of small PDUs. This component also guarantees asynchronous balanced of small PDUs. This component also guarantees asynchronous balanced
mode communication and provides link status supervision by performing mode communication and provides link status supervision by performing
the symmetry procedure. The Connection-oriented Transport component the symmetry procedure. The Connection-oriented Transmission
is responsible for maintaining all connection-oriented data exchanges component is responsible for maintaining all connection-oriented data
including connection set-up and termination. The Connectionless exchanges including connection set-up and termination. The
Transport component is responsible for handling unacknowledged data Connectionless Transmission component is responsible for handling
exchanges. unacknowledged data exchanges.
3.3. NFC-enabled Device Addressing 3.3. NFC-enabled Device Addressing
According to NFC Logical Link Control Protocol v1.3 [LLCP-1.3], NFC- According to NFC Logical Link Control Protocol v1.3 [LLCP-1.3], NFC-
enabled devices have two types of 6-bit addresses (i.e., SSAP and enabled devices have two types of 6-bit addresses (i.e., SSAP and
DSAP) to identify service access points. The several service access DSAP) to identify service access points. The several service access
points can be installed on a NFC device. However, the SSAP and DSAP points can be installed on a NFC device. However, the SSAP and DSAP
can be used as identifiers for NFC link connections with the IPv6 can be used as identifiers for NFC link connections with the IPv6
over NFC adaptation layer. Therefore, the SSAP can be used to over NFC adaptation layer. Therefore, the SSAP can be used to
generate an IPv6 interface identifier. Address values between 00h generate an IPv6 interface identifier. Address values between 00h
skipping to change at page 6, line 38 skipping to change at page 6, line 40
PDU) of LLCP of the NFC-enabled peer device. PDU) of LLCP of the NFC-enabled peer device.
The information field of an I PDU contains a single service data The information field of an I PDU contains a single service data
unit. The maximum number of octets in the information field is unit. The maximum number of octets in the information field is
determined by the Maximum Information Unit (MIU) for the data link determined by the Maximum Information Unit (MIU) for the data link
connection. The default value of the MIU for I PDUs is 128 octets. connection. The default value of the MIU for I PDUs is 128 octets.
The local and remote LLCs each establish and maintain distinct MIU The local and remote LLCs each establish and maintain distinct MIU
values for each data link connection endpoint. Also, an LLC MAY values for each data link connection endpoint. Also, an LLC MAY
announce a larger MIU for a data link connection by transmitting an announce a larger MIU for a data link connection by transmitting an
MIUX extension parameter within the information field. If no MIUX MIUX extension parameter within the information field. If no MIUX
parameter is transmitted, the default MIU value of 128 MUST be used. parameter is transmitted, the default MIU value is 128 bytes.
Otherwise, the MTU size in NFC LLCP MUST be calculated from the MIU Otherwise, the MTU size in NFC LLCP MUST be calculated from the MIU
value as follows: value as follows:
MIU = 128 + MIUX. MIU = 128 + MIUX.
According to [LLCP-1.3], Figure 2 shows an example of the MIUX According to [LLCP-1.3], Figure 2 shows an example of the MIUX
parameter TLV. Each of TLV Type and TLV Length field is 1 byte, and parameter TLV. Each of TLV Type and TLV Length field is 1 byte, and
TLV Value field is 2 bytes. TLV Value field is 2 bytes.
0 0 1 2 3 0 0 1 2 3
skipping to change at page 10, line 35 skipping to change at page 10, line 35
as mesh topology. NFC does not support a complicated mesh topology as mesh topology. NFC does not support a complicated mesh topology
but only a simple multi-hop network topology or directly connected but only a simple multi-hop network topology or directly connected
peer-to-peer network. Therefore, the following aspects of RFC 6775 peer-to-peer network. Therefore, the following aspects of RFC 6775
are applicable to NFC: are applicable to NFC:
o When an NFC-enabled device (6LN) is directly connected to a 6LBR, o When an NFC-enabled device (6LN) is directly connected to a 6LBR,
an NFC 6LN MUST register its address with the 6LBR by sending a an NFC 6LN MUST register its address with the 6LBR by sending a
Neighbor Solicitation (NS) message with the Address Registration Neighbor Solicitation (NS) message with the Address Registration
Option (ARO) and process the Neighbor Advertisement (NA) Option (ARO) and process the Neighbor Advertisement (NA)
accordingly. In addition, if DHCPv6 is used to assign an address, accordingly. In addition, if DHCPv6 is used to assign an address,
Duplicate Address Detection (DAD) MAY not be required. Duplicate Address Detection (DAD) is not necessary.
o When two or more NFC 6LNs(or 6LRs) meet, there MAY be two cases. o When two or more NFC 6LNs(or 6LRs) meet, there are two cases. One
One is that they meet with multi-hop connections, and the other is is that three or more NFC devices are linked with multi-hop
that they meet within a sigle hop range (e.g., isolated network). connections, and the other is that they meet within a single hop
In a case of multi-hops, all of 6LNs, which have two or more range (e.g., isolated network). In a case of multi-hops, all of
connections with different neighbors, MAY be a router for 6LNs, which have two or more connections with different neighbors,
6LR/6LBR. In a case that they meet within a single hop and they MAY be a router for 6LR/6LBR. In a case that they meet within a
have the same properties, any of them can be a router. When the single hop and they have the same properties, any of them can be a
NFC nodes are not of uniform category (e.g., different MTU, level router. When the NFC nodes are not of uniform category (e.g.,
of remaining energy, connectivity, etc.), a performance- different MTU, level of remaining energy, connectivity, etc.), a
outstanding device can become a router. Also, they MUST deliver performance-outstanding device can become a router. Also, they
their MTU information to neighbors with NFC LLCP protocols during MUST deliver their MTU information to neighbors with NFC LLCP
connection initialization. The router MAY also communicate other protocols during connection initialization. The router MAY also
capabilities which is out of scope of this document. communicate other capabilities which is out of scope of this
document.
o For sending Router Solicitations and processing Router o For sending Router Solicitations and processing Router
Advertisements, the NFC 6LNs MUST follow Sections 5.3 and 5.4 of Advertisements, the NFC 6LNs MUST follow Sections 5.3 and 5.4 of
[RFC6775]. [RFC6775].
o When a NFC device becomes a 6LR or a 6LBR, the NFC device MUST o When a NFC device becomes a 6LR or a 6LBR, the NFC device MUST
follow Section 6 and 7 of [RFC6775]. follow Section 6 and 7 of [RFC6775].
4.6. Dispatch Header 4.6. Dispatch Header
skipping to change at page 12, line 17 skipping to change at page 12, line 17
zeros as shown in Figure 8. zeros as shown in Figure 8.
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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: NFC short address format Figure 8: NFC short address format
4.8. Fragmentation and Reassembly 4.8. Fragmentation and Reassembly Considerations
IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is
NOT RECOMMENDED in this document as discussed in Section 3.4. The NOT RECOMMENDED in this document as discussed in Section 3.4. The
NFC link connection for IPv6 over NFC MUST be configured with an NFC link connection for IPv6 over NFC MUST be configured with an
equivalent MIU size to fit the MTU of IPv6 Packet. The MIUX value is equivalent MIU size to fit the MTU of IPv6 Packet. The MIUX value is
0x480 in order to fit the MTU (1280 bytes) of a IPv6 packet if NFC 0x480 in order to fit the MTU (1280 bytes) of a IPv6 packet if NFC
devices support extension of the MTU. However, if the NFC device devices support extension of the MTU. However, if the NFC device
does not support extension, IPv6-over-NFC uses FAR with default MIU does not support extension, IPv6-over-NFC uses FAR with the default
(128 bytes), as defined in [RFC4944]. MTU (128 bytes), as defined in [RFC4944].
4.9. Unicast and Multicast Address Mapping 4.9. Unicast and Multicast Address Mapping
The address resolution procedure for mapping IPv6 non-multicast The address resolution procedure for mapping IPv6 non-multicast
addresses into NFC link-layer addresses follows the general addresses into NFC link-layer addresses follows the general
description in Section 7.2 of [RFC4861], unless otherwise specified. description in Section 7.2 of [RFC4861], unless otherwise specified.
The Source/Target link-layer Address option has the following form The Source/Target link-layer Address option has the following form
when the addresses are 6-bit NFC link-layer (node) addresses. when the addresses are 6-bit NFC link-layer (node) addresses.
 End of changes. 15 change blocks. 
39 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/