idnits 2.17.1 draft-ietf-6lo-nfc-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA-340' ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group Y. Choi, Ed. 3 Internet-Draft Y-G. Hong 4 Intended status: Standards Track ETRI 5 Expires: January 9, 2020 J-S. Youn 6 Dongeui Univ 7 D-K. Kim 8 KNU 9 J-H. Choi 10 Samsung Electronics Co., 11 July 8, 2019 13 Transmission of IPv6 Packets over Near Field Communication 14 draft-ietf-6lo-nfc-14 16 Abstract 18 Near field communication (NFC) is a set of standards for smartphones 19 and portable devices to establish radio communication with each other 20 by touching them together or bringing them into proximity, usually no 21 more than 10 cm. NFC standards cover communications protocols and 22 data exchange formats, and are based on existing radio-frequency 23 identification (RFID) standards including ISO/IEC 14443 and FeliCa. 24 The standards include ISO/IEC 18092 and those defined by the NFC 25 Forum. The NFC technology has been widely implemented and available 26 in mobile phones, laptop computers, and many other devices. This 27 document describes how IPv6 is transmitted over NFC using 6LowPAN 28 techniques. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 9, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 66 3. Overview of Near Field Communication Technology . . . . . . . 3 67 3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4 68 3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 4 69 3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 5 70 3.4. MTU of NFC Link Layer . . . . . . . . . . . . . . . . . . 6 71 4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 7 72 4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 8 75 4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 76 4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 9 77 4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 10 78 4.7. Header Compression . . . . . . . . . . . . . . . . . . . 10 79 4.8. Fragmentation and Reassembly Considerations . . . . . . . 11 80 4.9. Unicast and Multicast Address Mapping . . . . . . . . . . 11 81 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 12 82 5.1. NFC-enabled Device Connected to the Internet . . . . . . 13 83 5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 13 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 NFC is a set of short-range wireless technologies, typically 93 requiring a distance of 10 cm or less. NFC operates at 13.56 MHz on 94 ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to 95 424 kbit/s [ECMA-340]. NFC always involves an initiator and a 96 target; the initiator actively generates an RF field that can power a 97 passive target. This enables NFC targets to take very simple form 98 factors such as tags, stickers, key fobs, or cards that do not 99 require batteries. NFC peer-to-peer communication is possible, 100 provided both devices are powered. NFC builds upon RFID systems by 101 allowing two-way communication between endpoints. At the time of 102 this writing, it had been used in devices such as mobile phones, 103 running Android operating system, named with a feature called 104 "Android Beam". It was expected for the other mobile phones, running 105 the other operating systems (e.g., iOS, etc.) to be equipped with NFC 106 technology in the near future. 108 Considering the potential for exponential growth in the number of 109 heterogeneous air interface technologies, NFC has been widely used 110 like Bluetooth Low Energy (BT-LE), Wi-Fi, and so on. Each of the 111 heterogeneous air interface technologies has its own characteristics, 112 which cannot be covered by the other technologies, so various kinds 113 of air interface technologies would co-exist together. NFC can 114 provide secured communications with its short transmission range. 116 When the number of devices and things having different air interface 117 technologies communicate with each other, IPv6 is an ideal internet 118 protocol owing to its large address space. Also, NFC would be one of 119 the endpoints using IPv6. Therefore, this document describes how 120 IPv6 is transmitted over NFC using 6LoWPAN techniques. 122 [RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The 123 NFC link also has similar characteristics to that of IEEE 802.15.4. 124 Many of the mechanisms defined in [RFC4944] can be applied to the 125 transmission of IPv6 on NFC links. This document specifies the 126 details of IPv6 transmission over NFC links. 128 2. Conventions and Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Overview of Near Field Communication Technology 138 NFC enables simple and two-way interaction between two devices, 139 allowing consumers to perform contactless transactions, access 140 digital content, and connect electronic devices with a single touch. 141 NFC complements many popular consumer level wireless technologies, by 142 utilizing the key elements in existing standards for contactless card 143 technology (ISO/IEC 14443 A&B and JIS-X 6319-4). NFC can be 144 compatible with existing contactless card infrastructure and it 145 enables a consumer to utilize one device across different systems. 147 Extending the capability of contactless card technology, NFC also 148 enables devices to share information at a distance that is less than 149 10 cm with a maximum communication speed of 424 kbps. Users can 150 share business cards, make transactions, access information from a 151 smart poster or provide credentials for access control systems with a 152 simple touch. 154 3.1. Peer-to-peer Mode of NFC 156 NFC-enabled devices are unique in that they can support three modes 157 of operation: card emulation, peer-to-peer, and reader/writer. Only 158 peer-to-peer in the three modes enables two NFC-enabled devices to 159 communicate with each other to exchange information and share files, 160 so that users of NFC-enabled devices can quickly share contact 161 information and other files with a touch. Therefore, the peer mode 162 is used for ipv6-over-nfc. In addition, NFC-enabled devices can 163 securely send IPv6 packets in wireless range when an NFC-enabled 164 gateway is linked to the Internet. 166 3.2. Protocol Stacks of NFC 168 IP can use the services provided by the Logical Link Control Protocol 169 (LLCP) in the NFC stack to provide reliable, two-way transmission of 170 information between the peer devices. Figure 1 depicts the NFC P2P 171 protocol stack with IPv6 bindings to LLCP. 173 For data communication in IPv6 over NFC, an IPv6 packet MUST be 174 passed down to LLCP of NFC and transported to an Information (I) and 175 an Unnumbered Information (UI) Field in Protocol Data Unit (PDU) of 176 LLCP of the NFC-enabled peer device. LLCP does not support 177 fragmentation and reassembly. For IPv6 addressing or address 178 configuration, LLCP MUST provide related information, such as link 179 layer addresses, to its upper layer. The LLCP to IPv6 protocol 180 binding MUST transfer the SSAP and DSAP value to the IPv6 over NFC 181 protocol. SSAP stands for Source Service Access Point, which is a 182 6-bit value meaning a kind of Logical Link Control (LLC) address, 183 while DSAP means an LLC address of the destination NFC-enabled 184 device. 186 | | 187 | | Application Layer 188 | Upper Layer Protocols | Transport Layer 189 | | Network Layer 190 | | | 191 +----------------------------------------+ ------------------ 192 | IPv6-LLCP Binding | | 193 +----------------------------------------+ NFC 194 | | Logical Link 195 | Logical Link Control Protocol | Layer 196 | (LLCP) | | 197 +----------------------------------------+ ------------------ 198 | | | 199 | Activities | | 200 | Digital Protocol | NFC 201 | | Physical 202 +----------------------------------------+ Layer 203 | | | 204 | RF Analog | | 205 | | | 206 +----------------------------------------+ ------------------ 208 Figure 1: Protocol Stacks of NFC 210 The LLCP consists of Logical Link Control (LLC) and MAC Mapping. The 211 MAC Mapping integrates an existing RF protocol into the LLCP 212 architecture. The LLC contains three components, such as Link 213 Management, Connection-oriented Transmission, and Connection-less 214 Transmission. The Link Management component is responsible for 215 serializing all connection-oriented and connection-less LLC PDU 216 (Protocol Data Unit) exchanges and for aggregation and disaggregation 217 of small PDUs. The Connection-oriented Transmission component is 218 responsible for maintaining all connection-oriented data exchanges 219 including connection set-up and termination. The Connectionless 220 Transmission component is responsible for handling unacknowledged 221 data exchanges. 223 3.3. NFC-enabled Device Addressing 225 According to NFC Logical Link Control Protocol v1.3 [LLCP-1.3], NFC- 226 enabled devices have two types of 6-bit addresses (i.e., SSAP and 227 DSAP) to identify service access points. The several service access 228 points can be installed on a NFC device. However, the SSAP and DSAP 229 can be used as identifiers for NFC link connections with the IPv6 230 over NFC adaptation layer. Therefore, the SSAP can be used to 231 generate an IPv6 interface identifier. Address values between 00h 232 and 0Fh of SSAP and DSAP are reserved for identifying the well-known 233 service access points, which are defined in the NFC Forum Assigned 234 Numbers Register. Address values between 10h and 1Fh are assigned by 235 the local LLC to services registered by local service environment. 236 In addition, address values between 20h and 3Fh are assigned by the 237 local LLC as a result of an upper layer service request. Therefore, 238 the address values between 20h and 3Fh can be used for generating 239 IPv6 interface identifiers. 241 3.4. MTU of NFC Link Layer 243 As mentioned in Section 3.2, an IPv6 packet MUST be passed down to 244 LLCP of NFC and transported to an Unnumbered Information Protocol 245 Data Unit (UI PDU) and an Information Field in Protocol Data Unit (I 246 PDU) of LLCP of the NFC-enabled peer device. 248 The information field of an I PDU contains a single service data 249 unit. The maximum number of octets in the information field is 250 determined by the Maximum Information Unit (MIU) for the data link 251 connection. The default value of the MIU for I PDUs is 128 octets. 252 The local and remote LLCs each establish and maintain distinct MIU 253 values for each data link connection endpoint. Also, an LLC is 254 announce a larger MIU for a data link connection by transmitting an 255 MIUX extension parameter within the information field. If no MIUX 256 parameter is transmitted, the MIU value is 128 bytes. Otherwise, the 257 MTU size in NFC LLCP MUST be calculated from the MIU value as 258 follows: 260 MTU = MIU = 128 + MIUX. 262 According to [LLCP-1.3], Figure 2 shows an example of the MIUX 263 parameter TLV. Each of TLV Type and TLV Length field is 1 byte, and 264 TLV Value field is 2 bytes. 266 0 0 1 2 3 267 0 8 6 2 1 268 +----------+----------+------+-----------+ 269 | Type | Length | Value | 270 +----------+----------+------+-----------+ 271 | 00000010 | 00000010 | 1011 | 0x0~0x7FF | 272 +----------+----------+------+-----------+ 274 Figure 2: Example of MIUX Parameter TLV 276 When the MIUX parameter is encoded as a TLV option, the TLV Type 277 field MUST be 0x02 and the TLV Length field MUST be 0x02. The MIUX 278 parameter MUST be encoded into the least significant 11 bits of the 279 TLV Value field. The unused bits in the TLV Value field MUST be set 280 to zero by the sender and ignored by the receiver. A maximum value 281 of the TLV Value field can be 0x7FF, and a maximum size of the MTU in 282 NFC LLCP is 2176 bytes including the 128 byte default of MIU. This 283 value MUST be 0x480 to cover MTU of IPV6 if FAR is not used in IPv6 284 over NFC. 286 4. Specification of IPv6 over NFC 288 NFC technology also has considerations and requirements owing to low 289 power consumption and allowed protocol overhead. 6LoWPAN standards 290 [RFC4944], [RFC6775], and [RFC6282] provide useful functionality for 291 reducing overhead which can be applied to NFC. This functionality 292 consists of link-local IPv6 addresses and stateless IPv6 address 293 auto-configuration (see Section 4.3), Neighbor Discovery (see 294 Section 4.5) and header compression (see Section 4.7). 296 4.1. Protocol Stacks 298 Figure 3 illustrates IPv6 over NFC. Upper layer protocols can be 299 transport layer protocols (TCP and UDP), application layer protocols, 300 and others capable running on top of IPv6. 302 | | 303 | Upper Layer Protocols | 304 +----------------------------------------+ 305 | IPv6 | 306 +----------------------------------------+ 307 | Adaptation Layer for IPv6 over NFC | 308 +----------------------------------------+ 309 | NFC Link Layer | 310 +----------------------------------------+ 311 | NFC Physical Layer | 312 +----------------------------------------+ 314 Figure 3: Protocol Stacks for IPv6 over NFC 316 The adaptation layer for IPv6 over NFC support neighbor discovery, 317 stateless address auto-configuration, header compression, and 318 fragmentation & reassembly. 320 4.2. Link Model 322 In the case of BT-LE, the Logical Link Control and Adaptation 323 Protocol (L2CAP) supports fragmentation and reassembly (FAR) 324 functionality; therefore, the adaptation layer for IPv6 over BT-LE 325 does not have to conduct the FAR procedure. The NFC LLCP, in 326 contrast, does not support the FAR functionality, so IPv6 over NFC 327 needs to consider the FAR functionality, defined in [RFC4944]. 328 However, the MTU on an NFC link can be configured in a connection 329 procedure and extended enough to fit the MTU of IPv6 packet (see 330 Section 4.8). 332 This document does NOT RECOMMEND using FAR over NFC link. In 333 addition, the implementation for this specification MUST use MIUX 334 extension to communicate the MTU of the link to the peer as defined 335 in Section 3.4. 337 The NFC link between two communicating devices is considered to be a 338 point-to-point link only. Unlike in BT-LE, an NFC link does not 339 support a star topology or mesh network topology but only direct 340 connections between two devices. Furthermore, the NFC link layer 341 does not support packet forwarding in link layer. Due to this 342 characteristics, 6LoWPAN functionalities, such as addressing and 343 auto-configuration, and header compression, need to be specialized 344 into IPv6 over NFC. 346 4.3. Stateless Address Autoconfiguration 348 An NFC-enabled device (i.e., 6LN) performs stateless address 349 autoconfiguration as per [RFC4862]. A 64-bit Interface identifier 350 (IID) for an NFC interface is formed by utilizing the 6-bit NFC SSAP 351 (see Section 3.3). In the viewpoint of address configuration, such 352 an IID should guarantee a stable IPv6 address during the course of a 353 single connection, because each data link connection is uniquely 354 identified by the pair of DSAP and SSAP included in the header of 355 each LLC PDU in NFC. 357 Following the guidance of [RFC7136], interface identifiers of all 358 unicast addresses for NFC-enabled devices are 64 bits long and 359 constructed by using the generation algorithm of random (but stable) 360 identifier (RID) [RFC7217] (see Figure 4). 362 0 1 3 4 6 363 0 6 2 8 3 364 +---------+---------+---------+---------+ 365 | Random (but stable) Identifier (RID) | 366 +---------+---------+---------+---------+ 368 Figure 4: IID from NFC-enabled device 370 The RID is an output which is created by the algorithm, F() with 371 input parameters. One of the parameters is Net_IFace, and NFC Link 372 Layer address (i.e., SSAP) is a source of the NetIFace parameter. 373 The 6-bit address of SSAP of NFC is easy and short to be targeted by 374 attacks of third party (e.g., address scanning). The F() can provide 375 secured and stable IIDs for NFC-enabled devices. In addition, an 376 optional parameter, Network_ID is used to increase the randomness of 377 the generated IID. 379 4.4. IPv6 Link Local Address 381 The IPv6 link-local address for an NFC-enabled device is formed by 382 appending the IID, to the prefix FE80::/64, as depicted in Figure 5. 384 0 0 0 1 385 0 1 6 2 386 0 0 4 7 387 +----------+------------------+----------------------------+ 388 |1111111010| zeros | Interface Identifier | 389 +----------+------------------+----------------------------+ 390 | | 391 | <---------------------- 128 bits ----------------------> | 392 | | 394 Figure 5: IPv6 link-local address in NFC 396 The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC 397 network can be accomplished via DHCPv6 Prefix Delegation ([RFC3633]). 398 The "Interface Identifier" is used the secured and stable IIDs for 399 NFC-enabled devices. 401 4.5. Neighbor Discovery 403 Neighbor Discovery Optimization for 6LoWPANs ([RFC6775]) describes 404 the neighbor discovery approach in several 6LoWPAN topologies, such 405 as mesh topology. NFC does not support a complicated mesh topology 406 but only a simple multi-hop network topology or directly connected 407 peer-to-peer network. Therefore, the following aspects of RFC 6775 408 are applicable to NFC: 410 o When an NFC-enabled device (6LN) is directly connected to a NFC- 411 enabled 6LBR, an NFC 6LN MUST register its address with the 412 6LBR[RFC4944] by sending a Neighbor Solicitation (NS) message with 413 the Address Registration Option (ARO) and process the Neighbor 414 Advertisement (NA) accordingly. In addition, when the 6LN and 415 6LBR are directly connected, DHCPv6 is used for address 416 assignment. Therefore, Duplicate Address Detection (DAD) is not 417 necessary between them. 419 o When two or more NFC 6LNs[RFC4944](or 6LRs) are connected, there 420 are two cases. One is that three or more NFC devices are linked 421 with multi-hop connections, and the other is that they meet within 422 a single hop range (e.g., isolated network). In a case of multi- 423 hops, all of 6LNs, which have two or more connections with 424 different neighbors, is a router for 6LR/6LBR. In a case that 425 they meet within a single hop and they have the same properties, 426 any of them can be a router. 428 o For sending Router Solicitations and processing Router 429 Advertisements, the NFC 6LNs MUST follow Sections 5.3 and 5.4 of 430 [RFC6775]. 432 o When a NFC device becomes a 6LR or a 6LBR, the NFC device MUST 433 follow Section 6 and 7 of [RFC6775]. 435 4.6. Dispatch Header 437 All IPv6-over-NFC encapsulated datagrams are prefixed by an 438 encapsulation header stack consisting of a Dispatch value followed by 439 zero or more header fields. The only sequence currently defined for 440 IPv6-over-NFC is the LOWPAN_IPHC header followed by payload, as 441 depicted in Figure 6. 443 +---------------+---------------+--------------+ 444 | IPHC Dispatch | IPHC Header | Payload | 445 +---------------+---------------+--------------+ 447 Figure 6: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6 448 Datagram 450 The dispatch value is treated as an unstructured namespace. Only a 451 single pattern is used to represent current IPv6-over-NFC 452 functionality. 454 +------------+--------------------+-----------+ 455 | Pattern | Header Type | Reference | 456 +------------+--------------------+-----------+ 457 | 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] | 458 +------------+--------------------+-----------+ 460 Figure 7: Dispatch Values 462 Other IANA-assigned 6LoWPAN Dispatch values do not apply to this 463 specification. 465 4.7. Header Compression 467 Header compression as defined in [RFC6282], which specifies the 468 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 469 REQUIRED in this document as the basis for IPv6 header compression on 470 top of NFC. All headers MUST be compressed according to RFC 6282 471 encoding formats. 473 Therefore, IPv6 header compression in [RFC6282] MUST be implemented. 474 Further, implementations MUST also support Generic Header Compression 475 (GHC) of [RFC7400]. 477 If a 16-bit address is required as a short address, it MUST be formed 478 by padding the 6-bit NFC link-layer (node) address to the left with 479 zeros as shown in Figure 8. 481 0 1 482 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Padding(all zeros)| NFC Addr. | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 8: NFC short address format 489 4.8. Fragmentation and Reassembly Considerations 491 IPv6-over-NFC MUST NOT use fragmentation and reassembly (FAR) for the 492 payloads as discussed in Section 3.4. The NFC link connection for 493 IPv6 over NFC MUST be configured with an equivalent MIU size to fit 494 the MTU of IPv6 Packet. The MIUX value is 0x480 in order to fit the 495 MTU (1280 bytes) of a IPv6 packet if NFC devices support extension of 496 the MTU. However, if the NFC device does not support extension, 497 IPv6-over-NFC uses FAR with the default MTU (128 bytes), as defined 498 in [RFC4944]. 500 4.9. Unicast and Multicast Address Mapping 502 The address resolution procedure for mapping IPv6 non-multicast 503 addresses into NFC link-layer addresses follows the general 504 description in Section 4.6.1 and 7.2 of [RFC4861], unless otherwise 505 specified. 507 The Source/Target link-layer Address option has the following form 508 when the addresses are 6-bit NFC link-layer (node) addresses. 510 0 1 511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length=1 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | | 516 +- Padding (all zeros) -+ 517 | | 518 +- +-+-+-+-+-+-+ 519 | | NFC Addr. | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 9: Unicast address mapping 524 Option fields: 526 Type: 528 1: for Source Link-layer address. 530 2: for Target Link-layer address. 532 Length: 534 This is the length of this option (including the type and 535 length fields) in units of 8 octets. The value of this field 536 is 1 for 6-bit NFC node addresses. 538 NFC address: 540 The 6-bit address in canonical bit order. This is the unicast 541 address the interface currently responds to. 543 The NFC Link Layer does not support multicast. Therefore, packets 544 are always transmitted by unicast between two NFC-enabled devices. 545 Even in the case where a 6LBR is attached to multiple 6LNs, the 6LBR 546 cannot do a multicast to all the connected 6LNs. If the 6LBR needs 547 to send a multicast packet to all its 6LNs, it has to replicate the 548 packet and unicast it on each link. 550 5. Internet Connectivity Scenarios 552 NFC networks can be isolated and connected to the Internet. 554 5.1. NFC-enabled Device Connected to the Internet 556 One of the key applications of using IPv6 over NFC is securely 557 transmitting IPv6 packets because the RF distance between 6LN and 558 6LBR is typically within 10 cm. If any third party wants to hack 559 into the RF between them, it must come to nearly touch them. 560 Applications can choose which kinds of air interfaces (e.g., BT-LE, 561 Wi-Fi, NFC, etc.) to send data depending on the characteristics of 562 the data. 564 Figure 10 illustrates an example of an NFC-enabled device network 565 connected to the Internet. The distance between 6LN and 6LBR is 566 typically 10 cm or less. If there is any laptop computers close to a 567 user, it will become the a 6LBR. Additionally, when the user mounts 568 an NFC-enabled air interface adapter (e.g., portable NFC dongle) on 569 the close laptop PC, the user's NFC-enabled device (6LN) can 570 communicate with the laptop PC (6LBR) within 10 cm distance. 572 ************ 573 6LN ------------------- 6LBR -----* Internet *------- CN 574 | (dis. 10 cm or less) | ************ | 575 | | | 576 | <-------- NFC -------> | <----- IPv6 packet ------> | 577 | (IPv6 over NFC packet) | | 579 Figure 10: NFC-enabled device network connected to the Internet 581 Two or more LNs are connected with a 6LBR, but each connection uses a 582 different subnet. The 6LBR is acting as a router and forwarding 583 packets between 6LNs and the Internet. Also, the 6LBR MUST ensure 584 address collisions do not occur and forwards packets sent by one 6LN 585 to another. 587 5.2. Isolated NFC-enabled Device Network 589 In some scenarios, the NFC-enabled device network may transiently be 590 a simple isolated network as shown in the Figure 11. 592 6LN ---------------------- 6LR ---------------------- 6LN 593 | (10 cm or less) | (10 cm or less) | 594 | | | 595 | <--------- NFC --------> | <--------- NFC --------> | 596 | (IPv6 over NFC packet) | (IPv6 over NFC packet) | 598 Figure 11: Isolated NFC-enabled device network 600 In mobile phone markets, applications are designed and made by user 601 developers. They may image interesting applications, where three or 602 more mobile phones touch or attach each other to accomplish 603 performance. In an isolated NFC-enabled device network, when two or 604 more LRs are connected with each other, and then they are acting like 605 routers, the 6LR MUST ensure address collisions do not occur. 607 6. IANA Considerations 609 There are no IANA considerations related to this document. 611 7. Security Considerations 613 This document does not RECOMMEND sending NFC packets over the 614 Internet or any unsecured network. 616 When interface identifiers (IIDs) are generated, devices and users 617 are required to consider mitigating various threats, such as 618 correlation of activities over time, location tracking, device- 619 specific vulnerability exploitation, and address scanning. 621 IPv6-over-NFC uses an IPv6 interface identifier formed from a "Short 622 Address" and a set of well-known constant bits for the modified 623 EUI-64 format. However, NFC applications use short-lived 624 connections, and the every connection is made with different address 625 of NFC link with an extremely short-lived link. 627 This document does not RECOMMEND sending NFC packets over the 628 Internet or any unsecured network. Especially, there can be a threat 629 model in the scenario of Section 5.1. when the NFC-enabled device 630 links to a NFC-enabled gateway for connectivity with the Internet, 631 the gateway can be attacked. Even though IPv6 over NFC guarantees 632 security between the two NFC devices, there can be another threat 633 during packet forwarding. 635 8. Acknowledgements 637 We are grateful to the members of the IETF 6lo working group. 639 Michael Richardson, Suresh Krishnan, Pascal Thubert, Carsten Bormann, 640 Alexandru Petrescu, James Woodyatt, Dave Thaler, Samita Chakrabarti, 641 and Gabriel Montenegro have provided valuable feedback for this 642 draft. 644 9. Normative References 646 [ECMA-340] 647 "Near Field Communication - Interface and Protocol (NFCIP- 648 1) 3rd Ed.", ECMA-340 , June 2013. 650 [LLCP-1.3] 651 "NFC Logical Link Control Protocol version 1.3", NFC Forum 652 Technical Specification , March 2016. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 660 Host Configuration Protocol (DHCP) version 6", RFC 3633, 661 DOI 10.17487/RFC3633, December 2003, 662 . 664 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 665 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 666 DOI 10.17487/RFC4861, September 2007, 667 . 669 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 670 Address Autoconfiguration", RFC 4862, 671 DOI 10.17487/RFC4862, September 2007, 672 . 674 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 675 "Transmission of IPv6 Packets over IEEE 802.15.4 676 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 677 . 679 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 680 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 681 DOI 10.17487/RFC6282, September 2011, 682 . 684 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 685 Bormann, "Neighbor Discovery Optimization for IPv6 over 686 Low-Power Wireless Personal Area Networks (6LoWPANs)", 687 RFC 6775, DOI 10.17487/RFC6775, November 2012, 688 . 690 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 691 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 692 February 2014, . 694 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 695 Interface Identifiers with IPv6 Stateless Address 696 Autoconfiguration (SLAAC)", RFC 7217, 697 DOI 10.17487/RFC7217, April 2014, 698 . 700 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 701 IPv6 over Low-Power Wireless Personal Area Networks 702 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 703 2014, . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 Authors' Addresses 711 Younghwan Choi (editor) 712 Electronics and Telecommunications Research Institute 713 218 Gajeongno, Yuseung-gu 714 Daejeon 34129 715 Korea 717 Phone: +82 42 860 1429 718 Email: yhc@etri.re.kr 720 Yong-Geun Hong 721 Electronics and Telecommunications Research Institute 722 161 Gajeong-Dong Yuseung-gu 723 Daejeon 305-700 724 Korea 726 Phone: +82 42 860 6557 727 Email: yghong@etri.re.kr 729 Joo-Sang Youn 730 DONG-EUI University 731 176 Eomgwangno Busan_jin_gu 732 Busan 614-714 733 Korea 735 Phone: +82 51 890 1993 736 Email: joosang.youn@gmail.com 737 Dongkyun Kim 738 Kyungpook National University 739 80 Daehak-ro, Buk-gu 740 Daegu 702-701 741 Korea 743 Phone: +82 53 950 7571 744 Email: dongkyun@knu.ac.kr 746 JinHyouk Choi 747 Samsung Electronics Co., 748 129 Samsung-ro, Youngdong-gu 749 Suwon 447-712 750 Korea 752 Phone: +82 2 2254 0114 753 Email: jinchoe@samsung.com