draft-ietf-6lo-nfc-03.txt   draft-ietf-6lo-nfc-04.txt 
6Lo Working Group Y-G. Hong 6Lo Working Group Y-H. Choi
Internet-Draft Y-H. Choi Internet-Draft Y-G. Hong
Intended status: Standards Track ETRI Intended status: Standards Track ETRI
Expires: September 22, 2016 J-S. Youn Expires: January 9, 2017 J-S. Youn
DONG-EUI Univ DONG-EUI Univ
D-K. Kim D-K. Kim
KNU KNU
J-H. Choi J-H. Choi
Samsung Electronics Co., Samsung Electronics Co.,
March 21, 2016 July 8, 2016
Transmission of IPv6 Packets over Near Field Communication Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-03 draft-ietf-6lo-nfc-04
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 September 22, 2016. This Internet-Draft will expire on January 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 5, line 15 skipping to change at page 5, line 15
3.2. Protocol Stacks of NFC 3.2. Protocol Stacks of NFC
The IP protocol can use the services provided by Logical Link Control The IP protocol can use the services provided by Logical Link Control
Protocol (LLCP) in the NFC stack to provide reliable, two-way Protocol (LLCP) in the NFC stack to provide reliable, two-way
transport of information between the peer devices. Figure 1 depicts transport of information between the peer devices. Figure 1 depicts
the NFC P2P protocol stack with IPv6 bindings to the LLCP. the NFC P2P protocol stack with IPv6 bindings to the LLCP.
For data communication in IPv6 over NFC, an IPv6 packet SHALL be For data communication in IPv6 over NFC, an IPv6 packet SHALL be
received at LLCP of NFC and transported to an Information Field in received at LLCP of NFC and transported to an Information Field in
Protocol Data Unit (I PDU) of LLCP of the NFC-enabled peer device. Protocol Data Unit (I PDU) of LLCP of the NFC-enabled peer device.
Since LLCP does not support fragmentation and reassembly, upper LLCP does not support fragmentation and reassembly. For IPv6
layers SHOULD support fragmentation and reassembly. For IPv6
addressing or address configuration, LLCP SHALL provide related addressing or address configuration, LLCP SHALL provide related
information, such as link layer addresses, to its upper layer. LLCP information, such as link layer addresses, to its upper layer. LLCP
to IPv6 protocol Binding SHALL transfer the SSAP and DSAP value to to IPv6 protocol Binding SHALL transfer the SSAP and DSAP value to
the IPv6 over NFC protocol. SSAP stands for Source Service Access the IPv6 over NFC protocol. SSAP stands for Source Service Access
Point, which is 6-bit value meaning a kind of Logical Link Control Point, which is 6-bit value meaning a kind of Logical Link Control
(LLC) address, while DSAP means a LLC address of destination NFC- (LLC) address, while DSAP means a LLC address of destination NFC-
enabled device. enabled device.
| | | |
| | Application Layer | | Application Layer
skipping to change at page 8, line 18 skipping to change at page 8, line 18
field. The unused bits in the TLV Value field SHALL be set to zero field. The unused bits in the TLV Value field SHALL be set to zero
by the sender and SHALL be ignored by the receiver. However, a by the sender and SHALL be ignored by the receiver. However, a
maximun value of the TLV Value field can be 0x7FF, and a maximum size maximun value of the TLV Value field can be 0x7FF, and a maximum size
of the MTU in NFC LLCP SHALL calculate 2176 bytes. of the MTU in NFC LLCP SHALL calculate 2176 bytes.
4. Specification of IPv6 over NFC 4. Specification of IPv6 over NFC
NFC technology sets also has considerations and requirements owing to NFC technology sets also has considerations and requirements owing to
low power consumption and allowed protocol overhead. 6LoWPAN low power consumption and allowed protocol overhead. 6LoWPAN
standards RFC4944 [1], RFC6775 [4], and RFC6282 [5] provide useful standards RFC4944 [1], RFC6775 [4], and RFC6282 [5] provide useful
functionality for reducing overhead which can be applied to BT-LE. functionality for reducing overhead which can be applied to NFC.
This functionality comprises of link-local IPv6 addresses and This functionality comprises of link-local IPv6 addresses and
stateless IPv6 address auto-configuration (see Section 4.3), Neighbor stateless IPv6 address auto-configuration (see Section 4.3), Neighbor
Discovery (see Section 4.5) and header compression (see Section 4.7). Discovery (see Section 4.5) and header compression (see Section 4.7).
One of the differences between IEEE 802.15.4 and NFC is that the One of the differences between IEEE 802.15.4 and NFC is that the
former supports both star and mesh topology (and requires a routing former supports both star and mesh topology (and requires a routing
protocol), whereas NFC can support direct peer-to-peer connection and protocol), whereas NFC can support direct peer-to-peer connection and
simple mesh-like topology depending on NFC application scenarios simple mesh-like topology depending on NFC application scenarios
because of very short RF distance of 10 cm or less. because of very short RF distance of 10 cm or less.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
address auto-configuration, header compression, and fragmentation & address auto-configuration, header compression, and fragmentation &
reassembly. reassembly.
4.2. Link Model 4.2. Link Model
In the case of BT-LE, Logical Link Control and Adaptation Protocol In the case of BT-LE, Logical Link Control and Adaptation Protocol
(L2CAP) supports fragmentation and reassembly (FAR) functionality; (L2CAP) supports fragmentation and reassembly (FAR) functionality;
therefore, adaptation layer for IPv6 over BT-LE does not have to therefore, adaptation layer for IPv6 over BT-LE does not have to
conduct the FAR procedure. The NFC LLCP, by contrast, does not conduct the FAR procedure. The NFC LLCP, by contrast, does not
support the FAR functionality, so IPv6 over NFC needs to consider the support the FAR functionality, so IPv6 over NFC needs to consider the
FAR functionality, defined in RFC4944 [1]. However, MTU on NFC link FAR functionality, defined in RFC4944 [1] if it is required.
can be configured in a connection procedure and extended enough to However, MTU on NFC link can be configured in a connection procedure
fit the MTU of IPv6 packet. and extended enough to fit the MTU of IPv6 packet. (see Section 4.8)
The NFC link between two communicating devices is considered to be a The NFC link between two communicating devices is considered to be a
point-to-point link only. Unlike in BT-LE, NFC link does not point-to-point link only. Unlike in BT-LE, NFC link does not
consider star topology and mesh network topology but peer-to-peer consider star topology and mesh network topology but direct
topology and simple multi-hop topology. Due to this characteristics, connections between two devices. Furthermore, NFC link layer does
6LoWPAN functionality, such as addressing and auto-configuration, and not support mesh-under protocols. Due to this characteristics,
header compression, is specialized into NFC. 6LoWPAN functionalities, such as addressing and auto-configuration,
and header compression, need to be specialized into IPv6 over NFC.
4.3. Stateless Address Autoconfiguration 4.3. Stateless Address Autoconfiguration
A NFC-enabled device (i.e., 6LN) performs stateless address A NFC-enabled device (i.e., 6LN) performs stateless address
autoconfiguration as per RFC4862 [6]. A 64-bit Interface identifier autoconfiguration as per RFC4862 [6]. A 64-bit Interface identifier
(IID) for a NFC interface is formed by utilizing the 6-bit NFC LLCP (IID) for a NFC interface is formed by utilizing the 6-bit NFC LLCP
address (i.e., SSAP or DSAP) (see Section 3.3). In the viewpoint of address (i.e., SSAP or DSAP) (see Section 3.3). In the viewpoint of
address configuration, such an IID MAY guarantee a stable IPv6 address configuration, such an IID MAY guarantee a stable IPv6
address because each data link connection is uniquely identified by address because each data link connection is uniquely identified by
the pair of DSAP and SSAP included in the header of each LLC PDU in the pair of DSAP and SSAP included in the header of each LLC PDU in
skipping to change at page 17, line 35 skipping to change at page 17, line 35
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <http://www.rfc-editor.org/info/rfc7400>. 2014, <http://www.rfc-editor.org/info/rfc7400>.
9.2. Informative References 9.2. Informative References
[12] "Near Field Communication - Interface and Protocol (NFCIP- [12] "Near Field Communication - Interface and Protocol (NFCIP-
1) 3rd Ed.", ECMA-340 , June 2013. 1) 3rd Ed.", ECMA-340 , June 2013.
Authors' Addresses Authors' Addresses
Yong-Geun Hong Younghwan Choi
ETRI ETRI
161 Gajeong-Dong Yuseung-Gu 218 Gajeongno, Yuseong
Daejeon 305-700 Daejeon 305-700
Korea Korea
Phone: +82 42 860 6557 Phone: +82 42 860 1429
Email: yghong@etri.re.kr Email: yhc@etri.re.kr
Younghwan Choi Yong-Geun Hong
ETRI ETRI
218 Gajeongno, Yuseong 161 Gajeong-Dong Yuseung-Gu
Daejeon 305-700 Daejeon 305-700
Korea Korea
Phone: +82 42 860 1429 Phone: +82 42 860 6557
Email: yhc@etri.re.kr Email: yghong@etri.re.kr
Joo-Sang Youn Joo-Sang Youn
DONG-EUI University DONG-EUI University
176 Eomgwangno Busan_jin_gu 176 Eomgwangno Busan_jin_gu
Busan 614-714 Busan 614-714
Korea Korea
Phone: +82 51 890 1993 Phone: +82 51 890 1993
Email: joosang.youn@gmail.com Email: joosang.youn@gmail.com
Dongkyun Kim Dongkyun Kim
 End of changes. 15 change blocks. 
24 lines changed or deleted 24 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/