< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/