| < draft-ietf-6lo-nfc-01.txt | draft-ietf-6lo-nfc-02.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: January 6, 2016 J-S. Youn | Expires: April 19, 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., | |||
| July 5, 2015 | October 17, 2015 | |||
| Transmission of IPv6 Packets over Near Field Communication | Transmission of IPv6 Packets over Near Field Communication | |||
| draft-ietf-6lo-nfc-01 | draft-ietf-6lo-nfc-02 | |||
| 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 January 6, 2016. | This Internet-Draft will expire on April 19, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 2, line 35 ¶ | skipping to change at page 2, line 35 ¶ | |||
| 3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4 | 3.1. Peer-to-peer Mode of NFC . . . . . . . . . . . . . . . . 4 | |||
| 3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 5 | 3.2. Protocol Stacks of NFC . . . . . . . . . . . . . . . . . 5 | |||
| 3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6 | 3.3. NFC-enabled Device Addressing . . . . . . . . . . . . . . 6 | |||
| 3.4. NFC MAC PDU Size and MTU . . . . . . . . . . . . . . . . 6 | 3.4. NFC MAC PDU Size and MTU . . . . . . . . . . . . . . . . 6 | |||
| 4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 8 | 4. Specification of IPv6 over NFC . . . . . . . . . . . . . . . 8 | |||
| 4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 8 | 4.1. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 10 | 4.3. Stateless Address Autoconfiguration . . . . . . . . . . . 10 | |||
| 4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 10 | 4.4. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 10 | |||
| 4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11 | 4.5. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 11 | |||
| 4.6. Header Compression . . . . . . . . . . . . . . . . . . . 11 | 4.6. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 4.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 | 4.7. Header Compression . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.8. Unicast Address Mapping . . . . . . . . . . . . . . . . . 12 | 4.8. Fragmentation and Reassembly . . . . . . . . . . . . . . 12 | |||
| 4.9. Multicast Address Mapping . . . . . . . . . . . . . . . . 13 | 4.9. Unicast Address Mapping . . . . . . . . . . . . . . . . . 13 | |||
| 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 13 | 4.10. Multicast Address Mapping . . . . . . . . . . . . . . . . 13 | |||
| 5.1. NFC-enabled Device Connected to the Internet . . . . . . 13 | 5. Internet Connectivity Scenarios . . . . . . . . . . . . . . . 14 | |||
| 5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 14 | 5.1. NFC-enabled Device Connected to the Internet . . . . . . 14 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 5.2. Isolated NFC-enabled Device Network . . . . . . . . . . . 15 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 15 | 9.2. Informative References . . . . . . . . . . . . . . . . . 17 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | 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 | |||
| target. This enables NFC targets to take very simple form factors | target. This enables NFC targets to take very simple form factors | |||
| such as tags, stickers, key fobs, or cards that do not require | such as tags, stickers, key fobs, or cards that do not require | |||
| skipping to change at page 8, line 21 ¶ | skipping to change at page 8, line 21 ¶ | |||
| 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 BT-LE. | |||
| 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.6). | 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. | |||
| 4.1. Protocol Stacks | 4.1. Protocol Stacks | |||
| Figure 5 illustrates IPv6 over NFC. Upper layer protocols can be | Figure 5 illustrates IPv6 over NFC. Upper layer protocols can be | |||
| skipping to change at page 11, line 29 ¶ | skipping to change at page 11, line 29 ¶ | |||
| to 6LBR, A NFC 6LN MUST register its address with the 6LBR by | to 6LBR, A NFC 6LN MUST register its address with the 6LBR by | |||
| sending a Neighbor Solicitation (NS) message with the Address | sending a Neighbor Solicitation (NS) message with the Address | |||
| Registration Option (ARO) and process the Neighbor Advertisement | Registration Option (ARO) and process the Neighbor Advertisement | |||
| (NA) accordingly. In addition, DHCPv6 is used to assigned an | (NA) accordingly. In addition, DHCPv6 is used to assigned an | |||
| address, Duplicate Address Detection (DAD) is not required. | address, Duplicate Address Detection (DAD) is not required. | |||
| 2. For sending Router Solicitations and processing Router | 2. For sending Router Solicitations and processing Router | |||
| Advertisements the NFC 6LNs MUST follow Sections 5.3 and 5.4 of | Advertisements the NFC 6LNs MUST follow Sections 5.3 and 5.4 of | |||
| the RFC6775. | the RFC6775. | |||
| 4.6. Header Compression | 4.6. Dispatch Header | |||
| All IPv6-over-NFC encapsulated datagrams transmitted over NFC are | ||||
| prefixed by an encapsulation header stack consisting of a Dispatch | ||||
| value followed by zero or more header fields. The only sequence | ||||
| currently defined for IPv6-over-NFC is the LOWPAN_IPHC header | ||||
| followed by payload, as depicted in Figure 8. | ||||
| +---------------+---------------+--------------+ | ||||
| | IPHC Dispatch | IPHC Header | Payload | | ||||
| +---------------+---------------+--------------+ | ||||
| Figure 8: A IPv6-over-NFC Encapsulated 6LOWPAN_IPHC Compressed IPv6 | ||||
| Datagram | ||||
| The dispatch value may be treated as an unstructured namespace. Only | ||||
| a single pattern is used to represent current LoBAC functionality. | ||||
| +------------+--------------------+-----------+ | ||||
| | Pattern | Header Type | Reference | | ||||
| +------------+--------------------+-----------+ | ||||
| | 01 1xxxxx | 6LOWPAN_IPHC | [RFC6282] | | ||||
| +------------+--------------------+-----------+ | ||||
| Figure 9: Dispatch Values | ||||
| Other IANA-assigned 6LoWPAN Dispatch values do not apply to this | ||||
| specification. | ||||
| 4.7. Header Compression | ||||
| Header compression as defined in RFC6282 [5] , which specifies the | Header compression as defined in RFC6282 [5] , which specifies the | |||
| compression format for IPv6 datagrams on top of IEEE 802.15.4, is | compression format for IPv6 datagrams on top of IEEE 802.15.4, is | |||
| REQUIRED in this document as the basis for IPv6 header compression on | REQUIRED in this document as the basis for IPv6 header compression on | |||
| top of NFC. All headers MUST be compressed according to RFC6282 | top of NFC. All headers MUST be compressed according to RFC6282 | |||
| encoding formats. | encoding formats. | |||
| Therefore, IPv6 header compression in RFC6282 [5] MUST be | ||||
| implemented. Further, implementations MAY also support Generic | ||||
| Header Compression (GHC) of RFC7400 [11]. A node implementing GHC | ||||
| MUST probe its peers for GHC support before applying GHC. | ||||
| If a 16-bit address is required as a short address of IEEE 802.15.4, | If a 16-bit address is required as a short address of IEEE 802.15.4, | |||
| it MUST be formed by padding the 6-bit NFC link-layer (node) address | it MUST be formed by padding the 6-bit NFC link-layer (node) address | |||
| to the left with zeros as shown in Figure 8. | to the left with zeros as shown in Figure 10. | |||
| 0 1 | 0 1 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Padding(all zeros)| NFC Addr. | | | Padding(all zeros)| NFC Addr. | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 8: NFC short adress format | Figure 10: NFC short adress format | |||
| 4.7. Fragmentation and Reassembly | 4.8. Fragmentation and Reassembly | |||
| NFC provides fragmentation and reassembly (FAR) for payloads from 128 | NFC provides fragmentation and reassembly (FAR) for payloads from 128 | |||
| bytes up to 2176 bytes as mention in Section 3.4. The MTU of a | bytes up to 2176 bytes as mention in Section 3.4. The MTU of a | |||
| general IPv6 packet can fit into a sigle NFC link frame. Therefore, | general IPv6 packet can fit into a sigle NFC link frame. Therefore, | |||
| the FAR functionality as defined in RFC4944, which specifies the | the FAR functionality as defined in RFC4944, which specifies the | |||
| fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, is | fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4, is | |||
| NOT REQUIRED in this document as the basis for IPv6 datagram FAR on | NOT REQUIRED in this document as the basis for IPv6 datagram FAR on | |||
| top of NFC. The NFC link connection for IPv6 over NFC MUST be | top of NFC. The NFC link connection for IPv6 over NFC MUST be | |||
| configured with an equivalent MIU size to fit the MTU of IPv6 Packet. | configured with an equivalent MIU size to fit the MTU of IPv6 Packet. | |||
| However, the default configuration of MIUX value is 0x480 in order to | However, the default configuration of MIUX value is 0x480 in order to | |||
| fit the MTU (1280 bytes) of a IPv6 packet. | fit the MTU (1280 bytes) of a IPv6 packet. | |||
| 4.8. Unicast Address Mapping | 4.9. Unicast 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 [9], unless otherwise | description in Section 7.2 of RFC4861 [9], unless otherwise | |||
| specified. | 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. | |||
| 0 1 | 0 1 | |||
| skipping to change at page 12, line 40 ¶ | skipping to change at page 13, line 27 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length=1 | | | Type | Length=1 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| +- Padding (all zeros) -+ | +- Padding (all zeros) -+ | |||
| | | | | | | |||
| +- +-+-+-+-+-+-+ | +- +-+-+-+-+-+-+ | |||
| | | NFC Addr. | | | | NFC Addr. | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 9: Unicast address mapping | Figure 11: Unicast address mapping | |||
| Option fields: | Option fields: | |||
| Type: | Type: | |||
| 1: for Source Link-layer address. | 1: for Source Link-layer address. | |||
| 2: for Target Link-layer address. | 2: for Target Link-layer address. | |||
| Length: | Length: | |||
| This is the length of this option (including the type and | This is the length of this option (including the type and | |||
| length fields) in units of 8 octets. The value of this field | length fields) in units of 8 octets. The value of this field | |||
| is 1 for 6-bit NFC node addresses. | is 1 for 6-bit NFC node addresses. | |||
| NFC address: | NFC address: | |||
| The 6-bit address in canonical bit order. This is the unicast | The 6-bit address in canonical bit order. This is the unicast | |||
| address the interface currently responds to. | address the interface currently responds to. | |||
| 4.9. Multicast Address Mapping | 4.10. Multicast Address Mapping | |||
| All IPv6 multicast packets MUST be sent to NFC Destination Address, | All IPv6 multicast packets MUST be sent to NFC Destination Address, | |||
| 0x3F (broadcast) and filtered at the IPv6 layer. When represented as | 0x3F (broadcast) and filtered at the IPv6 layer. When represented as | |||
| a 16-bit address in a compressed header, it MUST be formed by padding | a 16-bit address in a compressed header, it MUST be formed by padding | |||
| on the left with a zero. In addition, the NFC Destination Address, | on the left with a zero. In addition, the NFC Destination Address, | |||
| 0x3F, MUST not be used as a unicast NFC address of SSAP or DSAP. | 0x3F, MUST not be used as a unicast NFC address of SSAP or DSAP. | |||
| 0 1 | 0 1 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Padding(all zeros)|1 1 1 1 1 1| | | Padding(all zeros)|1 1 1 1 1 1| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 10: Multicast address mapping | Figure 12: Multicast address mapping | |||
| 5. Internet Connectivity Scenarios | 5. Internet Connectivity Scenarios | |||
| As two typical scenarios, the NFC network can be isolated and | As two typical scenarios, the NFC network can be isolated and | |||
| connected to the Internet. | connected to the Internet. | |||
| 5.1. NFC-enabled Device Connected to the Internet | 5.1. NFC-enabled Device Connected to the Internet | |||
| One of the key applications by using adaptation technology of IPv6 | One of the key applications by using adaptation technology of IPv6 | |||
| over NFC is the most securely transmitting IPv6 packets because RF | over NFC is the most securely transmitting IPv6 packets because RF | |||
| distance between 6LN and 6LBR SHOULD be within 10 cm. If any third | distance between 6LN and 6LBR SHOULD be within 10 cm. If any third | |||
| party wants to hack into the RF between them, it MUST come to nearly | party wants to hack into the RF between them, it MUST come to nearly | |||
| touch them. Applications can choose which kinds of air interfaces | touch them. Applications can choose which kinds of air interfaces | |||
| (e.g., BT-LE, Wi-Fi, NFC, etc.) to send data depending | (e.g., BT-LE, Wi-Fi, NFC, etc.) to send data depending | |||
| characteristics of data. NFC SHALL be the best solution for secured | characteristics of data. NFC SHALL be the best solution for secured | |||
| and private information. | and private information. | |||
| Figure 11 illustrates an example of NFC-enabled device network | Figure 13 illustrates an example of NFC-enabled device network | |||
| connected to the Internet. Distance between 6LN and 6LBR SHOULD be | connected to the Internet. Distance between 6LN and 6LBR SHOULD be | |||
| 10 cm or less. If there is any of close laptop computers to a user, | 10 cm or less. If there is any of close laptop computers to a user, | |||
| it SHALL becomes the 6LBR. Additionally, When the user mounts a NFC- | it SHALL becomes the 6LBR. Additionally, When the user mounts a NFC- | |||
| enabled air interface adapter (e.g., portable small NFC dongle) on | enabled air interface adapter (e.g., portable small NFC dongle) on | |||
| the close laptop PC, the user's NFC-enabled device (6LN) can | the close laptop PC, the user's NFC-enabled device (6LN) can | |||
| communicate the laptop PC (6LBR) within 10 cm distance. | communicate the laptop PC (6LBR) within 10 cm distance. | |||
| ************ | ************ | |||
| 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 11: NFC-enabled device network connected to the Internet | Figure 13: NFC-enabled device network connected to the Internet | |||
| 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 12. | a simple isolated network as shown in the Figure 14. | |||
| 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 12: Isolated NFC-enabled device network | Figure 14: 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. For instance, three or more mobile phones | outstanding performance. For instance, three or more mobile phones | |||
| 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 | |||
| skipping to change at page 15, line 11 ¶ | skipping to change at page 15, line 51 ¶ | |||
| 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 | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [1] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | [1] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | |||
| "Transmission of IPv6 Packets over IEEE 802.15.4 | "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
| Networks", RFC 4944, September 2007. | Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | |||
| <http://www.rfc-editor.org/info/rfc4944>. | ||||
| [2] Bradner, S., "Key words for use in RFCs to Indicate | [2] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | ||||
| <http://www.rfc-editor.org/info/rfc2119>. | ||||
| [3] "Logical Link Control Protocol version 1.1", NFC Forum | [3] "Logical Link Control Protocol version 1.1", NFC Forum | |||
| Technical Specification , June 2011. | Technical Specification , June 2011. | |||
| [4] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, | [4] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | |||
| "Neighbor Discovery Optimization for IPv6 over Low-Power | Bormann, "Neighbor Discovery Optimization for IPv6 over | |||
| Wireless Personal Area Networks (6LoWPANs)", RFC 6775, | Low-Power Wireless Personal Area Networks (6LoWPANs)", | |||
| November 2012. | RFC 6775, DOI 10.17487/RFC6775, November 2012, | |||
| <http://www.rfc-editor.org/info/rfc6775>. | ||||
| [5] Hui, J. and P. Thubert, "Compression Format for IPv6 | [5] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | |||
| Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | |||
| September 2011. | DOI 10.17487/RFC6282, September 2011, | |||
| <http://www.rfc-editor.org/info/rfc6282>. | ||||
| [6] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | [6] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | |||
| Address Autoconfiguration", RFC 4862, September 2007. | Address Autoconfiguration", RFC 4862, | |||
| DOI 10.17487/RFC4862, September 2007, | ||||
| <http://www.rfc-editor.org/info/rfc4862>. | ||||
| [7] Hinden, R. and S. Deering, "IP Version 6 Addressing | [7] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
| Architecture", RFC 4291, February 2006. | Architecture", RFC 4291, DOI 10.17487/RFC4291, February | |||
| 2006, <http://www.rfc-editor.org/info/rfc4291>. | ||||
| [8] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic | [8] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic | |||
| Host Configuration Protocol (DHCP) version 6", RFC 3633, | Host Configuration Protocol (DHCP) version 6", RFC 3633, | |||
| December 2003. | DOI 10.17487/RFC3633, December 2003, | |||
| <http://www.rfc-editor.org/info/rfc3633>. | ||||
| [9] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [9] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
| "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
| September 2007. | DOI 10.17487/RFC4861, September 2007, | |||
| <http://www.rfc-editor.org/info/rfc4861>. | ||||
| [10] Carpenter, B. and S. Jiang, "Significance of IPv6 | [10] Carpenter, B. and S. Jiang, "Significance of IPv6 | |||
| Interface Identifiers", RFC 7136, February 2014. | Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, | |||
| February 2014, <http://www.rfc-editor.org/info/rfc7136>. | ||||
| [11] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for | ||||
| IPv6 over Low-Power Wireless Personal Area Networks | ||||
| (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November | ||||
| 2014, <http://www.rfc-editor.org/info/rfc7400>. | ||||
| 9.2. Informative References | 9.2. Informative References | |||
| [11] "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 | Yong-Geun Hong | |||
| ETRI | ETRI | |||
| 161 Gajeong-Dong Yuseung-Gu | 161 Gajeong-Dong Yuseung-Gu | |||
| Daejeon 305-700 | Daejeon 305-700 | |||
| Korea | Korea | |||
| End of changes. 31 change blocks. | ||||
| 43 lines changed or deleted | 94 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/ | ||||