< draft-ietf-6lo-nfc-02.txt		draft-ietf-6lo-nfc-03.txt >
	6Lo Working Group Y-G. Hong		6Lo Working Group Y-G. Hong
	Internet-Draft Y-H. Choi		Internet-Draft Y-H. Choi
	Intended status: Standards Track ETRI		Intended status: Standards Track ETRI
	Expires: April 19, 2016 J-S. Youn		Expires: September 22, 2016 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.,
	October 17, 2015		March 21, 2016
	Transmission of IPv6 Packets over Near Field Communication		Transmission of IPv6 Packets over Near Field Communication
	draft-ietf-6lo-nfc-02		draft-ietf-6lo-nfc-03
	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 19, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	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 45 ¶		skipping to change at page 2, line 45 ¶
	4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 11		4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 11
	4.7. Header Compression . . . . . . . . . . . . . . . . . . . 12		4.7. Header Compression . . . . . . . . . . . . . . . . . . . 12
	4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 12		4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 12
	4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 13		4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 13
	4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 13		4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 13
	5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 14		5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 14
	5.1. NFC-enabled Device Connected to the Internet . . . . . . 14		5.1. NFC-enabled Device Connected to the Internet . . . . . . 14
	5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 15		5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	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. 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
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 9 ¶
	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 peer-to-peer
	topology and simple multi-hop topology. Due to this characteristics,		topology and simple multi-hop topology. Due to this characteristics,
	6LoWPAN functionality, such as addressing and auto-configuration, and		6LoWPAN functionality, such as addressing and auto-configuration, and
	header compression, is specialized into NFC.		header compression, is specialized into 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 MAY be formed by utilizing the 6-bit NFC		(IID) for a NFC interface is formed by utilizing the 6-bit NFC LLCP
	LLCP address (i.e., SSAP or DSAP) (see Section 3.3). In the		address (i.e., SSAP or DSAP) (see Section 3.3). In the viewpoint of
	viewpoint of address configuration, such an IID MAY guarantee a		address configuration, such an IID MAY guarantee a stable IPv6
	stable IPv6 address because each data link connection is uniquely		address because each data link connection is uniquely identified by
	identified by the pair of DSAP and SSAP included in the header of		the pair of DSAP and SSAP included in the header of each LLC PDU in
	each LLC PDU in NFC.		NFC.
	Following the guidance of RFC7136 [10], interface Identifiers of all		Following the guidance of RFC7136 [10], interface Identifiers of all
	unicast addresses for NFC-enabled devices are formed on the basis of		unicast addresses for NFC-enabled devices are formed on the basis of
	64 bits long and constructed in a modified EUI-64 format as shown in		64 bits long and constructed in a modified EUI-64 format as shown in
	Figure 6.		Figure 6.
	0 1 3 4 5 6		0 1 3 4 5 6
	0 6 2 8 8 3		0 6 2 8 8 3
	+----------------+----------------+----------------+----------+------+		+----------------+----------------+----------------+----------+------+
	|0000000000000000|0000000011111111|1111111000000000|0000000000| SSAP |		|0000000000000000|0000000011111111|1111111000000000|0000000000| SSAP |
	skipping to change at page 11, line 45 ¶		skipping to change at page 11, line 45 ¶
	followed by payload, as depicted in Figure 8.		followed by payload, as depicted in Figure 8.
	+---------------+---------------+--------------+		+---------------+---------------+--------------+
	| IPHC Dispatch | IPHC Header | Payload |		| IPHC Dispatch | IPHC Header | Payload |
	+---------------+---------------+--------------+		+---------------+---------------+--------------+
	Figure 8: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6		Figure 8: 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 LoBAC functionality.		a single pattern is used to represent current IPv6-over-NFC
			functionality.
	+------------+--------------------+-----------+		+------------+--------------------+-----------+
	| Pattern | Header Type | Reference |		| Pattern | Header Type | Reference |
	+------------+--------------------+-----------+		+------------+--------------------+-----------+
	| 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] |		| 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] |
	+------------+--------------------+-----------+		+------------+--------------------+-----------+
	Figure 9: Dispatch Values		Figure 9: Dispatch Values
	Other IANA-assigned 6LoWPAN Dispatch values do not apply to this		Other IANA-assigned 6LoWPAN Dispatch values do not apply to this
	skipping to change at page 15, line 32 ¶		skipping to change at page 15, line 32 ¶
	can play multi-channel sound of music together. In addition,		can play multi-channel sound of music together. In addition,
	attached three or more mobile phones can make an extended banner to		attached three or more mobile phones can make an extended banner to
	show longer sentences in a concert hall.		show longer sentences in a concert hall.
	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
	The method of deriving Interface Identifiers from 6-bit NFC Link		When interface identifiers (IIDs) are generated, devices and users
	layer addresses is intended to preserve global uniqueness when it is		are required to consider mitigating various threats, such as
	possible. Therefore, it is to required to protect from duplication		correlation of activities over time, location tracking, device-
	through accident or forgery.		specific vulnerability exploitation, and address scanning.
			IPv6-over-NFC is, in practice, not used for long-lived links for big
			size data transfer or multimedia streaming, but used for extremely
			short-lived links (i.e., single touch-based approaches) for ID
			verification and mobile payment. This will mitigate the threat of
			correlation of activities over time.
			IPv6-over-NFC uses an IPv6 interface identifier formed from a "Short
			Address" and a set of well-known constant bits (such as padding with
			'0's) for the modified EUI-64 format. However, the short address of
			NFC link layer (LLC) is not generated as a physically permanent value
			but logically generated for each connection. Thus, every single
			touch connection can use a different short address of NFC link with
			an extremely short-lived link. This can mitigate address scanning as
			well as location tracking and device-specific vulnerability
			exploitation.
			However, malicious tries for one connection of a long-lived link with
			NFC technology are not secure, so the method of deriving interface
			identifiers from 6-bit NFC Link layer addresses is intended to
			preserve global uniqueness when it is possible. Therefore, it
			requires to protect from duplication through accident or forgery and
			to define a way to include sufficient bit of entropy in the IPv6
			interface identifier, such as random EUI-64.
	8. Acknowledgements		8. Acknowledgements
	We are grateful to the members of the IETF 6lo working group.		We are grateful to the members of the IETF 6lo working group.
	Michael Richardson, Suresh Krishnan, Pascal Thubert, Carsten Bormann,		Michael Richardson, Suresh Krishnan, Pascal Thubert, Carsten Bormann,
	and Alexandru Petrescu have provided valuable feedback for this		and Alexandru Petrescu have provided valuable feedback for this
	draft.		draft.
	9. References		9. References
End of changes. 9 change blocks.
	19 lines changed or deleted		44 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/