draft-ietf-6lo-nfc-05.txt   draft-ietf-6lo-nfc-06.txt 
6Lo Working Group Y-H. Choi 6Lo Working Group Y-H. Choi
Internet-Draft Y-G. Hong Internet-Draft Y-G. Hong
Intended status: Standards Track ETRI Intended status: Standards Track ETRI
Expires: April 14, 2017 J-S. Youn Expires: September 8, 2017 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.,
October 11, 2016 March 7, 2017
Transmission of IPv6 Packets over Near Field Communication Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-05 draft-ietf-6lo-nfc-06
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 14, 2017. This Internet-Draft will expire on September 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 35 skipping to change at page 2, line 35
3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4 3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4
3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 4 3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 4
3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6 3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6
3.4. NFC MAC PDU Size and MTU . . . . . . . . . . . . . . . . 6 3.4. NFC MAC PDU Size and MTU . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 8 4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 8
4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 9 4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 9
4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 9 4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 10
4.7. Header Compression . . . . . . . . . . . . . . . . . . . 10 4.7. Header Compression . . . . . . . . . . . . . . . . . . . 10
4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 11
4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 11 4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 11
4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 12 4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 12
5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 12 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 12
5.1. NFC-enabled Device Connected to the Internet . . . . . . 12 5.1. NFC-enabled Device Connected to the Internet . . . . . . 12
5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 13 5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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. NFC always involves an initiator and a target; the
initiator actively generates an RF field that can power a passive initiator actively generates an RF field that can power a passive
target. This enables NFC targets to take very simple form factors target. This enables NFC targets to take very simple form factors
such as tags, stickers, key fobs, or cards that do not require such as tags, stickers, key fobs, or cards that do not require
skipping to change at page 8, line 36 skipping to change at page 8, line 36
because each data link connection is uniquely identified by the pair because each data link connection is uniquely identified by the pair
of DSAP and SSAP included in the header of each LLC PDU in NFC. of DSAP and SSAP included in the header of each LLC PDU in NFC.
Following the guidance of RFC 7136 [10], interface identifiers of all Following the guidance of RFC 7136 [10], interface identifiers of all
unicast addresses for NFC-enabled devices are 64 bits long and unicast addresses for NFC-enabled devices are 64 bits long and
constructed in a modified EUI-64 format as shown in Figure 3. constructed in a modified EUI-64 format as shown in Figure 3.
0 1 3 4 6 0 1 3 4 6
0 6 2 8 3 0 6 2 8 3
+----------------+----------------+----------------+-----------------+ +----------------+----------------+----------------+-----------------+
|000000u000000000|0000000011111111|11111110RRRRRRRR|RRRRRRRRRRRRRRRRR| |RRRRRRuRRRRRRRRR|RRRRRRRR11111111|11111110RRRRRRRR|RRRRRRRRRRRRRRRRR|
+----------------+----------------+----------------+-----------------+ +----------------+----------------+----------------+-----------------+
Figure 3: Formation of IID from NFC-enabled device address Figure 3: Formation of IID from NFC-enabled device address
The 'R' bits are random values which MAY be created by mechanisms The 'R' bits are output values which MAY be created by mechanisms
like hash function with the SSAP as an input value because the 6-bit like hash functions with input values, i.e., the SSAP and other
address of SSAP is easy and short to be targeted by attacks of third values (e.g., prefix) because the 6-bit address of SSAP is easy and
party (e.g., address scanning). In addition, the "Universal/Local" short to be targeted by attacks of third party (e.g., address
bit (i.e., the 'u' bit) of an NFC-enabled device address MUST be set scanning). Figure 4 shows an example for IID creation. The F()
to 0 RFC 4291 [7]. means a mechanism to make a output value for 64-bit IID, and an
parameter, "offset" is an example input value for making the
different output values.
IID = F( SHA-256(6-bit SSAP, 64-bit Prefix), 'u' bit, offset )
Figure 4: An example of an IID creation mechanism
In addition, the "Universal/Local" bit (i.e., the 'u' bit) of an NFC-
enabled device address MUST be set to 0 RFC 4291 [7].
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 4. 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
0 0 4 7 0 0 4 7
+----------+------------------+----------------------------+ +----------+------------------+----------------------------+
|1111111010| zeros | Interface Identifier | |1111111010| zeros | Interface Identifier |
+----------+------------------+----------------------------+ +----------+------------------+----------------------------+
| | | |
| <---------------------- 128 bits ----------------------> | | <---------------------- 128 bits ----------------------> |
| | | |
Figure 4: IPv6 link-local address in NFC Figure 5: IPv6 link-local address in NFC
The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
network is can be accomplished via DHCPv6 Prefix Delegation (RFC 3633 network is can be accomplished via DHCPv6 Prefix Delegation (RFC 3633
[8]). [8]).
4.5. Neighbor Discovery 4.5. Neighbor Discovery
Neighbor Discovery Optimization for 6LoWPANs (RFC 6775 [4]) describes Neighbor Discovery Optimization for 6LoWPANs (RFC 6775 [4]) describes
the neighbor discovery approach in several 6LoWPAN topologies, such the neighbor discovery approach in several 6LoWPAN topologies, such
as mesh topology. NFC does not support a complicated mesh topology as mesh topology. NFC does not support a complicated mesh topology
skipping to change at page 10, line 5 skipping to change at page 10, line 15
2. For sending Router Solicitations and processing Router 2. 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
RFC 6775. RFC 6775.
4.6. Dispatch Header 4.6. Dispatch Header
All IPv6-over-NFC encapsulated datagrams are prefixed by an All IPv6-over-NFC encapsulated datagrams are prefixed by an
encapsulation header stack consisting of a Dispatch value followed by encapsulation header stack consisting of a Dispatch value followed by
zero or more header fields. The only sequence currently defined for zero or more header fields. The only sequence currently defined for
IPv6-over-NFC is the LOWPAN_IPHC header followed by payload, as IPv6-over-NFC is the LOWPAN_IPHC header followed by payload, as
depicted in Figure 5. depicted in Figure 6.
+---------------+---------------+--------------+ +---------------+---------------+--------------+
| IPHC Dispatch | IPHC Header | Payload | | IPHC Dispatch | IPHC Header | Payload |
+---------------+---------------+--------------+ +---------------+---------------+--------------+
Figure 5: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6 Figure 6: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6
Datagram Datagram
The dispatch value may be treated as an unstructured namespace. Only The dispatch value may be treated as an unstructured namespace. Only
a single pattern is used to represent current IPv6-over-NFC a single pattern is used to represent current IPv6-over-NFC
functionality. functionality.
+------------+--------------------+-----------+ +------------+--------------------+-----------+
| Pattern | Header Type | Reference | | Pattern | Header Type | Reference |
+------------+--------------------+-----------+ +------------+--------------------+-----------+
| 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] | | 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] |
+------------+--------------------+-----------+ +------------+--------------------+-----------+
Figure 6: Dispatch Values Figure 7: Dispatch Values
Other IANA-assigned 6LoWPAN Dispatch values do not apply to this Other IANA-assigned 6LoWPAN Dispatch values do not apply to this
specification. specification.
4.7. Header Compression 4.7. Header Compression
Header compression as defined in RFC 6282 [5], which specifies the Header compression as defined in RFC 6282 [5], which specifies the
compression format for IPv6 datagrams on top of IEEE 802.15.4, is compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED in this document as the basis for IPv6 header compression on REQUIRED in this document as the basis for IPv6 header compression on
top of NFC. All headers MUST be compressed according to RFC 6282 top of NFC. All headers MUST be compressed according to RFC 6282
encoding formats. encoding formats.
Therefore, IPv6 header compression in RFC 6282 [5] MUST be Therefore, IPv6 header compression in RFC 6282 [5] MUST be
implemented. Further, implementations MAY also support Generic implemented. Further, implementations MAY also support Generic
Header Compression (GHC) of RFC 7400 [11]. Header Compression (GHC) of RFC 7400 [11].
If a 16-bit address is required as a short address, it MUST be formed If a 16-bit address is required as a short address, it MUST be formed
by padding the 6-bit NFC link-layer (node) address to the left with by padding the 6-bit NFC link-layer (node) address to the left with
zeros as shown in Figure 7. 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 7: NFC short address format Figure 8: NFC short address format
4.8. Fragmentation and Reassembly 4.8. Fragmentation and Reassembly
NFC provides fragmentation and reassembly (FAR) for payloads from 128 NFC provides fragmentation and reassembly (FAR) for payloads from 128
bytes up to 2176 bytes as mentioned in Section 3.4. The MTU of a bytes up to 2176 bytes as mentioned in Section 3.4. The MTU of a
general IPv6 packet can fit into a single NFC link frame. Therefore, general IPv6 packet can fit into a single NFC link frame. Therefore,
the FAR functionality as defined in RFC 4944, which specifies the the FAR functionality as defined in RFC 4944, which specifies the
fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, MAY fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, MAY
NOT be required as the basis for IPv6 datagram FAR on top of NFC. NOT be required as the basis for IPv6 datagram FAR on top of NFC.
The NFC link connection for IPv6 over NFC MUST be configured with an The NFC link connection for IPv6 over NFC MUST be configured with an
skipping to change at page 11, line 40 skipping to change at page 11, line 52
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 | | Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Padding (all zeros) -+ +- Padding (all zeros) -+
| | | |
+- +-+-+-+-+-+-+ +- +-+-+-+-+-+-+
| | NFC Addr. | | | NFC Addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Unicast address mapping Figure 9: Unicast address mapping
Option fields: Option fields:
Type: Type:
1: for Source Link-layer address. 1: for Source Link-layer address.
2: for Target Link-layer address. 2: for Target Link-layer address.
Length: Length:
skipping to change at page 12, line 29 skipping to change at page 12, line 39
padding on the left with a zero. In addition, the NFC Destination padding on the left with a zero. In addition, the NFC Destination
Address, 0x3F, MUST NOT be used as a unicast NFC address of SSAP or Address, 0x3F, MUST NOT be used as a unicast NFC address of SSAP or
DSAP. DSAP.
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)|1 1 1 1 1 1| | Padding(all zeros)|1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Multicast address mapping Figure 10: Multicast address mapping
5. Internet Connectivity Scenarios 5. Internet Connectivity Scenarios
As two typical scenarios, the NFC network can be isolated and As two typical scenarios, the NFC network can be isolated and
connected to the Internet. connected to the Internet.
5.1. NFC-enabled Device Connected to the Internet 5.1. NFC-enabled Device Connected to the Internet
One of the key applications of using IPv6 over NFC is securely One of the key applications of using IPv6 over NFC is securely
transmitting IPv6 packets because the RF distance between 6LN and transmitting IPv6 packets because the RF distance between 6LN and
6LBR is typically within 10 cm. If any third party wants to hack 6LBR is typically within 10 cm. If any third party wants to hack
into the RF between them, it must come to nearly touch them. into the RF between them, it must come to nearly touch them.
Applications can choose which kinds of air interfaces (e.g., BT-LE, Applications can choose which kinds of air interfaces (e.g., BT-LE,
Wi-Fi, NFC, etc.) to send data depending on the characteristics of Wi-Fi, NFC, etc.) to send data depending on the characteristics of
the data. the data.
Figure 10 illustrates an example of an NFC-enabled device network Figure 11 illustrates an example of an NFC-enabled device network
connected to the Internet. The distance between 6LN and 6LBR is connected to the Internet. The distance between 6LN and 6LBR is
typically 10 cm or less. If there is any laptop computers close to a typically 10 cm or less. If there is any laptop computers close to a
user, it will become the a 6LBR. Additionally, when the user mounts user, it will become the a 6LBR. Additionally, when the user mounts
an NFC-enabled air interface adapter (e.g., portable NFC dongle) on an NFC-enabled air interface adapter (e.g., portable NFC dongle) on
the close laptop PC, the user's NFC-enabled device (6LN) can the close laptop PC, the user's NFC-enabled device (6LN) can
communicate with the laptop PC (6LBR) within 10 cm distance. communicate with the laptop PC (6LBR) within 10 cm distance.
************ ************
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 11: NFC-enabled device network connected to the Internet
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 12.
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 12: 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.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
 End of changes. 22 change blocks. 
27 lines changed or deleted 36 lines changed or added

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