Subject: [6lo] NFC Forum feedback on draft-ietf-6lo-nfc-03

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 18 Aug 2016 20:07:20 +0000

Feedback from the NFC Forum on draft-ietf-6lo-nfc-03. Note that the current version is -04, but I believe most of the comments still apply.

Comments on IPv6 over NFC

To:

IETF 6Lo Working Group

Title:

Comments on draft-ietf-6lo-nfc-03

Date:

June 16th, 2016

Source:

NFC Devices WG

Contacts:

Jürgen Böhler

1.     Overview

The NFC Forum Board of Directors has requested the Technical Committee to review a document from IETF on mapping IPv6 to LLCP, available at the following link https://tools.ietf.org/pdf/draft-ietf-6lo-nfc-03.pdf. Further the following unclear points were raised:
*        ipv6-over-nfc adaptation layer generates an interface identifier of an ipv6 address by using a 6-bit value of "SSAP" of NFC LLCP as a node ID in our draft. This would be related to "LLCP binding to ipv6" (section 4.3~4.4 in draft-ietf-6lo-nfc)
*        MTU of a ipv6 datagram is basically 1280 bytes. MIU of NFC LLCP = 128 + MIUX, so MTU of NFC LLCP can be extended up to 2176 bytes. This is related to FAR (Fragmentation and Reassembly) issues. (section 3.4 and section 4.8 in draft-ietf-6lo-nfc)
The Technical Committee requested NFC Devices Working Group to comment the draft IETF document and the unclear points. This document summarizes the comments provided by NFC Devices Working Group.

2.     Previous activities at NFC Forum on IP mapping

NFC Forum Devices Working Group spent some time in 2010-2011 in attempting to define a mapping for IPv4 and IPv6 to LLCP. The work was discontinued for two main reasons:

1.     There was no widespread agreement on how to generate addresses, especially if they need to be routable.

2.     In the meantime, the NFC Forum SNEP specification was developed. This provides a mechanism for transporting any data over LLCP inside an NDEF Message. As a consequence, many protocols can be mapped to the payload of NDEF Messages instead of defining an own mapping mechanism on top of LLCP.
Thus the recommendation from NFC Devices WG is not to attempt to map IPv6 to LLCP, but to focus on the creation of the IPv6 specific application information, and to define how to format this in the payload of an NDEF Message.

3.     Comments on draft-ietf-6lo-nfc-03

If it is necessary to map IPv6 directly to LLCP, NFC Forum Devices Working Group has a number of comments on the document from IETF.

1.     There is a need to make a clear separation between

a.     Generation of IPv6 related information

b.     Mapping of IPv6 information into LLCP PDUs

2.     The document should not repeat structural information from the LLCP specification

a.     Doing so raises concerns over which normative statements would apply, for example in segmentation and reassembly

b.     Future changes to LLCP might require changes in IETF document

c.      Information is at best duplicated and can differ

d.     As a specific example some definitions in draft-ietf-6lo-nfc-03 deviates from the LLCP definition which will cause unnecessary interoperability issues:

                                                    i.     The DSAP/SSAP value range definition in section 3.3  is incorrect

                                                   ii.     The code for the UI-PDU in figure 2 is incorrect

                                                  iii.     The code for the MIUX Parameter TLV in figure 4 is incorrect

3.     The use of DSAP/SSAP is unclear

a.     Section 3.3 implies that an NFC Device is addressed using DSAP/SSAP which is not the case. DSAP/SSAP identifies service access points on NFC devices. A NFC Devices can have several service access points installed.

b.     NFC Forum views the use of LLCP as being different applications/protocols running on top of a single multiplexed layer between two peer devices. Therefore they would expect only a single DSAP/SSAP value used for the transfer of IP packets

c.      Section 4.2 mentions a simple multi-hop, but this is not defined in the current specification

d.     Section 4.3 describes the integration of DSAP/SSAP into the Interface identifier (IID) without considering the DSAP/SSAP value ranges defined by LLCP which forbids the usage of certain value ranges for the creation of IID.

4.     The NFC Forum decision was to use Connectionless rather than Connection Oriented Transport

a.     The belief is that IP provides a connectionless datagram service and hence it does not require a reliable transport

b.     Connectionless Transport has considerably lower overhead than Connection Oriented

5.     Section 4.8 bases the transfer of IPv6 packets on a minimum MIU size of 1280 bytes. LLCP defines a minimum MIU size of 128 bytes at default. IETF 6Lo WG should consider that the maximum supported MIU size is limited to the maximum Link MIU size supported by the LLC. This Link MIU is specific for the LLC and independent of its installed service access points. It cannot be assumed that current devices supports a Link MIU size of 1280 bytes why the connection for the transfer of IPv6 packets cannot rely on this MIU size.

6.     Section 5.2 seems to assume that 3 or more devices can be touched to play multi-channel music; this does not appear to be practical with the current link model

4.     Next steps

Given an appropriate relationship between the two bodies, LLCP experts would be happy to work with IETF on updates to the document.
The NFC Devices Working Group had during the analysis of draft-ietf-6lo-nfc no common understanding about the usage of IPv6 addresses and would like to understand the use cases behind. Therefore the NFC Devices Working Group would appreciate if IETF 6Lo Working Group share some background information for their current approach and use models.