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