draft-ietf-6lo-nfc-10.txt   draft-ietf-6lo-nfc-11.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: January 18, 2019 J-S. Youn Expires: April 4, 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.,
July 17, 2018 October 1, 2018
Transmission of IPv6 Packets over Near Field Communication Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-10 draft-ietf-6lo-nfc-11
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 January 18, 2019. This Internet-Draft will expire on April 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
NFC is a set of short-range wireless technologies, typically NFC is a set of short-range wireless technologies, typically
requiring a distance of 10 cm or less. NFC operates at 13.56 MHz on requiring a distance of 10 cm or less. NFC operates at 13.56 MHz on
ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to
424 kbit/s. NFC always involves an initiator and a target; the 424 kbit/s [ECMA-340]. NFC always involves an initiator and a
initiator actively generates an RF field that can power a passive target; the initiator actively generates an RF field that can power a
target. This enables NFC targets to take very simple form factors passive target. This enables NFC targets to take very simple form
such as tags, stickers, key fobs, or cards that do not require factors such as tags, stickers, key fobs, or cards that do not
batteries. NFC peer-to-peer communication is possible, provided both require batteries. NFC peer-to-peer communication is possible,
devices are powered. NFC builds upon RFID systems by allowing two- provided both devices are powered. NFC builds upon RFID systems by
way communication between endpoints, where earlier systems such as allowing two-way communication between endpoints, where earlier
contactless smart cards were one-way only. It has been used in systems such as contactless smart cards were one-way only. It has
devices such as mobile phones, running Android operating system, been used in devices such as mobile phones, running Android operating
named with a feature called "Android Beam". In addition, it is system, named with a feature called "Android Beam". In addition, it
expected for the other mobile phones, running the other operating is expected for the other mobile phones, running the other operating
systems (e.g., iOS, etc.) to be equipped with NFC technology in the systems (e.g., iOS, etc.) to be equipped with NFC technology in the
near future. near future.
Considering the potential for exponential growth in the number of Considering the potential for exponential growth in the number of
heterogeneous air interface technologies, NFC would be widely used as heterogeneous air interface technologies, NFC would be widely used as
one of the other air interface technologies, such as Bluetooth Low one of the other air interface technologies, such as Bluetooth Low
Energy (BT-LE), Wi-Fi, and so on. Each of the heterogeneous air Energy (BT-LE), Wi-Fi, and so on. Each of the heterogeneous air
interface technologies has its own characteristics, which cannot be interface technologies has its own characteristics, which cannot be
covered by the other technologies, so various kinds of air interface covered by the other technologies, so various kinds of air interface
technologies would co-exist together. Therefore, it is required for technologies would co-exist together. Therefore, it is required for
skipping to change at page 4, line 50 skipping to change at page 4, line 50
enabled gateway is linked to the Internet. 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 transport 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 Field in passed down to LLCP of NFC and transported to an Information (I) and
Protocol Data Unit (I PDU) of LLCP of the NFC-enabled peer device. an Unnumbered Information (UI) Field in Protocol Data Unit (PDU) of
LLCP of the NFC-enabled peer device. LLCP does not support
LLCP does not support fragmentation and reassembly. For IPv6 fragmentation and reassembly. For IPv6 addressing or address
addressing or address configuration, LLCP MUST provide related configuration, LLCP MUST provide related information, such as link
information, such as link layer addresses, to its upper layer. The layer addresses, to its upper layer. The LLCP to IPv6 protocol
LLCP to IPv6 protocol binding MUST transfer the SSAP and DSAP value binding MUST transfer the SSAP and DSAP value to the IPv6 over NFC
to the IPv6 over NFC protocol. SSAP stands for Source Service Access protocol. SSAP stands for Source Service Access Point, which is a
Point, which is a 6-bit value meaning a kind of Logical Link Control 6-bit value meaning a kind of Logical Link Control (LLC) address,
(LLC) address, while DSAP means an LLC address of the destination while DSAP means an LLC address of the destination NFC-enabled
NFC-enabled device. device.
| | | |
| | Application Layer | | Application Layer
| Upper Layer Protocols | Transport Layer | Upper Layer Protocols | Transport Layer
| | Network Layer | | Network Layer
| | | | | |
+----------------------------------------+ <------------------ +----------------------------------------+ <------------------
| IPv6-LLCP Binding | | | IPv6-LLCP Binding | |
+----------------------------------------+ NFC +----------------------------------------+ NFC
| | Logical Link | | Logical Link
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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 of 128 MUST be used.
Otherwise, the MTU size in NFC LLCP SHOULD 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
0 8 6 2 1 0 8 6 2 1
skipping to change at page 9, line 37 skipping to change at page 9, line 37
| Random (but stable) Identifier (RID) | | Random (but stable) Identifier (RID) |
+---------+---------+---------+---------+ +---------+---------+---------+---------+
Figure 4: IID from NFC-enabled device Figure 4: IID from NFC-enabled device
The RID is an output which MAY be created by the algorithm, F() with The RID is an output which MAY be created by the algorithm, F() with
input parameters. One of the parameters is Net_IFace, and NFC Link input parameters. One of the parameters is Net_IFace, and NFC Link
Layer address (i.e., SSAP) MAY be a source of the NetIFace parameter. Layer address (i.e., SSAP) MAY be a source of the NetIFace parameter.
The 6-bit address of SSAP of NFC is easy and short to be targeted by The 6-bit address of SSAP of NFC is easy and short to be targeted by
attacks of third party (e.g., address scanning). The F() can provide attacks of third party (e.g., address scanning). The F() can provide
secured and stable IIDs for NFC-enabled devices. secured and stable IIDs for NFC-enabled devices. In addition, an
optional parameter, Network_ID MAY be used to increase the randomness
In addition, the "Universal/Local" bit (i.e., the 'u' bit) of an NFC- of the generated IID.
enabled device address MUST be set to 0 [RFC4291].
4.4. IPv6 Link Local Address 4.4. IPv6 Link Local Address
Only if the NFC-enabled device address is known to be a public Only if the NFC-enabled device address is known to be a public
address, the "Universal/Local" bit be set to 1. The IPv6 link-local address, the "Universal/Local" bit be set to 1. The IPv6 link-local
address for an NFC-enabled device is formed by appending the IID, to address for an NFC-enabled device is formed by appending the IID, to
the prefix FE80::/64, as depicted in Figure 5. the prefix FE80::/64, as depicted in Figure 5.
0 0 0 1 0 0 0 1
0 1 6 2 0 1 6 2
skipping to change at page 10, line 37 skipping to change at page 10, line 37
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) MAY not be required.
o When two or more NFC 6LNs meet, there MAY be two cases. One is o When two or more NFC 6LNs(or 6LRs) meet, there MAY be two cases.
that they meet with multi-hop connections, and the other is that One is that they meet with multi-hop connections, and the other is
they meet within a sigle hop range (e.g., isolated network). In a that they meet within a sigle hop range (e.g., isolated network).
case of multi-hops, all of 6LNs, which have two or more In a case of multi-hops, all of 6LNs, which have two or more
connections with different neighbors, MAY be a router for connections with different neighbors, MAY be a router for
6LR/6LBR. In a case that they meet within a single hop and they 6LR/6LBR. In a case that they meet within a single hop and they
have the same properties, any of them can be a router. When the have the same properties, any of them can be a router. When the
NFC nodes are not of uniform category (e.g., different MTU, level NFC nodes are not of uniform category (e.g., different MTU, level
of remaining energy, connectivity, etc.), a performance- of remaining energy, connectivity, etc.), a performance-
outstanding device can become a router. Also, they MUST deliver outstanding device can become a router. Also, they MUST deliver
their MTU information to neighbors with NFC LLCP protocols during their MTU information to neighbors with NFC LLCP protocols during
connection initialization. The router MAY also communicate other connection initialization. The router MAY also communicate other
capabilities which is out of scope of this document. capabilities which is out of scope of this document.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
| 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
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. If NFC devices equivalent MIU size to fit the MTU of IPv6 Packet. The MIUX value is
support extension of the MTU, the MIUX value is 0x480 in order to fit 0x480 in order to fit the MTU (1280 bytes) of a IPv6 packet if NFC
the MTU (1280 bytes) of a IPv6 packet. devices support extension of the MTU. However, if the NFC device
does not support extension, IPv6-over-NFC uses FAR with default MIU
(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.
skipping to change at page 14, line 14 skipping to change at page 14, line 14
************ ************
6LN ------------------- 6LBR -----* Internet *------- CN 6LN ------------------- 6LBR -----* Internet *------- CN
| (dis. 10 cm or less) | ************ | | (dis. 10 cm or less) | ************ |
| | | | | |
| <-------- NFC -------> | <----- IPv6 packet ------> | | <-------- NFC -------> | <----- IPv6 packet ------> |
| (IPv6 over NFC packet) | | | (IPv6 over NFC packet) | |
Figure 10: NFC-enabled device network connected to the Internet Figure 10: NFC-enabled device network connected to the Internet
Two or more LNs MAY be connected with a 6LBR, but each connection
uses a different subnet. 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 and forwards packets sent
by one 6LN to another.
5.2. Isolated NFC-enabled Device Network 5.2. Isolated NFC-enabled Device Network
In some scenarios, the NFC-enabled device network may transiently be In some scenarios, the NFC-enabled device network may transiently be
a simple isolated network as shown in the Figure 11. a simple isolated network as shown in the Figure 11.
6LN ---------------------- 6LR ---------------------- 6LN 6LN ---------------------- 6LR ---------------------- 6LN
| (10 cm or less) | (10 cm or less) | | (10 cm or less) | (10 cm or less) |
| | | | | |
| <--------- NFC --------> | <--------- NFC --------> | | <--------- NFC --------> | <--------- NFC --------> |
| (IPv6 over NFC packet) | (IPv6 over NFC packet) | | (IPv6 over NFC packet) | (IPv6 over NFC packet) |
Figure 11: Isolated NFC-enabled device network Figure 11: Isolated NFC-enabled device network
In mobile phone markets, applications are designed and made by user In mobile phone markets, applications are designed and made by user
developers. They may image interesting applications, where three or developers. They may image interesting applications, where three or
more mobile phones touch or attach each other to accomplish more mobile phones touch or attach each other to accomplish
outstanding performance. outstanding performance. In an isolated NFC-enabled device network,
when two or more LRs MAY be connected with each other, and then they
are acting like routers, the 6LR MUST ensure address collisions do
not occur.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
7. Security Considerations 7. Security Considerations
When interface identifiers (IIDs) are generated, devices and users When interface identifiers (IIDs) are generated, devices and users
are required to consider mitigating various threats, such as are required to consider mitigating various threats, such as
correlation of activities over time, location tracking, device- correlation of activities over time, location tracking, device-
 End of changes. 12 change blocks. 
39 lines changed or deleted 49 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/