[6lo] Review of draft-ietf-6lo-nfc-15

[Carles Gomez Montenegro <[e-mail]>]

Dear IPv6 over NFC authors,

As the current shepherd for draft-ietf-6lo-nfc, and after discussion with
our AD, I have reviewed the document, keeping in mind the feedback
received from the IESG regarding the document.

Please find a list of detailed comments and update suggestions at the end
of this message. The comments and suggestions are mostly intended to
improve the document at an editorial level, reduce redundancy, and avoid
some remaining marketing-oriented text.

However, there are also technical comments. The main ones are the following:

- I understand that the document intends to specify use of 6LoWPAN
fragmentation functionality if MIUX is not supported. If my understanding
is correct, then there is contradicting content in the document (please
see below for further details).

- The range of topologies that are supported as per this specification is
not fully clear to me. Are multihop topologies supported? If yes, any of
them? (Note that the topology in Figure 11 is actually a star topology,
even if 2-hop communication would be possible there...) Is a generic mesh
topology intended to be supported?

Thanks,

Carles


---------------------- Comments and suggestions --------------------


1. Abstract: s/Near field communication/Near Field Communication

2. CURRENT:

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
ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to
424 kbit/s [ECMA-340]. NFC always involves an initiator and a
target; the initiator actively generates an RF field that can power a
passive target. This enables NFC targets to take very simple form
factors such as tags, stickers, key fobs, or cards that do not
require batteries. NFC peer-to-peer communication is possible,
provided both devices are powered. NFC builds upon RFID systems by
allowing two-way communication between endpoints. At the time of
this writing, it has been used in devices such as mobile phones,
running Android operating system, named with a feature called
"Android Beam". It is expected for the other mobile phones, running
other operating systems (e.g., iOS, etc.) to be equipped with NFC
technology in the near future.

PROPOSED:

NFC is a set of short-range wireless technologies, typically
requiring a distance between sender and receiver of 10 cm or less. NFC
operates at 13.56 MHz, and at rates ranging from 106 kbit/s to
424 kbit/s, as per the ISO/IEC 18000-3 air interface [ECMA-340]. NFC
builds upon RFID systems by allowing two-way communication between
endpoints. NFC always involves an initiator and a target; the initiator
actively generates an RF field that can power a passive target. This
enables NFC targets to take very simple form factors, such as tags,
stickers, key fobs, or cards, while avoiding the need for batteries. NFC
peer-to-peer communication is possible, provided that both devices are
powered. As of the writing, NFC is supported by the main smartphone
operating systems.


3. CURRENT:

Considering exponential growth in the number of heterogeneous air
interface technologies, NFC has been widely used like Bluetooth Low
Energy (BT-LE), Wi-Fi, and so on. Each of the heterogeneous air
interface technologies has its own characteristics, which cannot be
covered by the other technologies, so various kinds of air interface
technologies would co-exist together. NFC can provide secured
communications with its short transmission range.

PROPOSED:

NFC is often regarded as a secure communications technology, due to its
very short transmission range.


4. CURRENT:

When the number of devices and things having different air interface
technologies communicate with each other, IPv6 is an ideal internet
protocol owing to its large address space. Also, NFC would be one of
the endpoints using IPv6. Therefore, this document describes how
IPv6 is transmitted over NFC using 6LoWPAN techniques.

[RFC4944] specifies the transmission of IPv6 over IEEE 802.15.4. The
NFC link also has similar characteristics to that of IEEE 802.15.4.
Many of the mechanisms defined in [RFC4944] can be applied to the
transmission of IPv6 on NFC links. This document specifies the
details of IPv6 transmission over NFC links.

PROPOSED:

In order to benefit from Internet connectivity, it is desirable for
NFC-enabled devices to support IPv6, considering its large address space,
along with tools for unattended operation, among other advantages. This
document specifies how IPv6 is supported over NFC by using IPv6 over
Low-power Wireless Personal Area Network (6LoWPAN) techniques [RFC4944],
[RFC6282], [RFC6775]. 6LoWPAN is suitable, considering that it was
designed to support IPv6 over IEEE 802.15.4 networks, and some of the
characteristics of the latter are similar to those of NFC.


5. CURRENT:

NFC enables simple and two-way interaction between two devices,
allowing consumers to perform contactless transactions, access
digital content, and connect electronic devices with a single touch.
NFC complements many popular consumer level wireless technologies, by
utilizing the key elements in existing standards for contactless card
technology (ISO/IEC 14443 A&B and JIS-X 6319-4). NFC can be
compatible with existing contactless card infrastructure and it
enables a consumer to utilize one device across different systems.

Extending the capability of contactless card technology, NFC also
enables devices to share information at a distance that is less than
10 cm with a maximum communication speed of 424 kbps. Users can
share business cards, make transactions, access information from a
smart poster or provide credentials for access control systems with a
simple touch.

PROPOSED:

This section presents an overview of NFC, focusing on the characteristics
of NFC that are most relevant for supporting IPv6.

NFC enables simple, two-way, interaction between two devices,
allowing users to perform contactless transactions, access
digital content, and connect electronic devices with a single touch.
NFC utilizes key elements in existing standards for contactless card
Technology, such as ISO/IEC 14443 A&B and JIS-X 6319-4. NFC allows devices
to share information at a distance up to 10 cm with a maximum physical
layer bit rate of 424 kbps.


6. CURRENT:

NFC-enabled devices are unique in that they can support three modes
of operation: card emulation, peer-to-peer, and reader/writer. Only
peer-to-peer in the three modes enables two NFC-enabled devices to
communicate with each other to exchange information and share files,
so that users of NFC-enabled devices can quickly share contact
information and other files with a touch. Therefore, the peer mode
is used for ipv6-over-nfc. In addition, NFC-enabled devices can
securely send IPv6 packets in wireless range when an NFC-enabled
gateway is linked to the Internet.

PROPOSED:

NFC defines three modes of operation: card emulation, peer-to-peer, and
reader/writer. Only the peer-to-peer mode enables two NFC-enabled devices
to communicate with each other to exchange information and share files,
so that users of NFC-enabled devices can quickly share contact
information and other files with a touch. Therefore, the peer mode
is used for ipv6-over-nfc.


7. In the above paragraph, the reason why only the peer-to-peer mode is
suitable for IPv6 over NFC is not clear. It appears that the reason given
might apply as well to the other modes?


8. Section 3.2:

8.a. Title: s/Stacks/Stack

8.b. The protocol stack may be introduced by starting the paragraph with a
sentence like ‘NFC defines a protocol stack for the peer-to-peer mode
(Figure 1)’.

8.c. After the initial sentence suggested in 8.b, a brief overview of the
protocol stack may be added.

8.d. “IP can use the services provided by the Logical Link Control
Protocol (LLCP)”. Do you mean “IPv6” instead of “IP”? Also, is this “IPv6”
or “IPv6, and its underlying adaptation layer”? (Note that it might seem
that IPv6 is placed directly on top of the IPv6-LLCP binding sublayer,
without an adaptation layer.)

8.e. Please place the second paragraph as the third one, and vice versa.

8.f. Please introduce the concepts of SSAP and DSAP before they are used.
Also, please clarify in the document: is the SSAP an LLC address of the
source device, while the DSAP is an LLC address of the destination device?


9. CURRENT:

For data communication in IPv6 over NFC, an IPv6 packet MUST be
passed down to LLCP of NFC and transported to an Information (I) and
an Unnumbered Information (UI) Field in Protocol Data Unit (PDU) of
LLCP of the NFC-enabled peer device.

PROPOSED (*):

In order to send an IPv6 packet over NFC, the packet MUST be
passed down to the LLCP layer of NFC and carried by an Information (I) or
an Unnumbered Information (UI) Field in an LLCP Protocol Data Unit (PDU).

(*) Did you mean what is written in the PROPOSED text above? Also, please
note the “or” instead of “and” above. Is this what was intended?


10. Figure 1.

10.a. Figure caption: s/Protocol Stacks/Protocol Stack

10.b. Is the “NFC Logical Link Layer” in Figure 1 the same as the “NFC
Link Layer” in Figure 3?  If yes, please use the same term throughout the
document.

10.c. It might seem that the IPv6-LLCP Binding sublayer is always present
regardless of the upper layer protocols used... Please try to address
this.


11. Section 3.3.

11.a. s/The several service access points/Several service access points
11.b. “The IPv6 over NFC adaptation layer” is mentioned for the first time
in the document. This concept had not been previously introduced. Perhaps
it needs to be introduced in Section 1, when the use of 6LoWPAN is
introduced.

12. Section 3.4.

CURRENT:
    As mentioned in Section 3.2, an IPv6 packet MUST...

PROPOSED;
    As mentioned in Section 3.2, when an IPv6 packet is transmitted, the
    packet MUST . . .

13. CURRENT:
    Also, an LLC is announce

-- Did you mean “may” instead of “is”?


14. CURRENT:
a larger MIU for a data link connection by transmitting an MIUX

PROPOSED:
a larger MIU for a data link connection by transmitting an optional MIUX


-- Is MIUX an acronym? If yes, please expand it the first time it appears
in the text.



15. CURRENT:
Each of TLV Type and TLV Length field is 1 byte, and TLV Value field is 2
bytes.

PROPOSED:
The Type and Length fields of the MIUX parameter TLV have each a size of 1
byte. The size of the TLV Value field is 2 bytes.


16. CURRENT:
When the MIUX parameter is encoded as a TLV option, the TLV Type
field MUST be 0x02 and the TLV Length field MUST be 0x02. The MIUX
parameter MUST be encoded into the least significant 11 bits of the
TLV Value field. The unused bits in the TLV Value field MUST be set
to zero by the sender and ignored by the receiver. A maximum value
of the TLV Value field can be 0x7FF, and a maximum size of the MTU in
NFC LLCP is 2176 bytes including the 128 byte default of MIU. This
value MUST be 0x480 to cover MTU of IPV6 if FAR is not used in IPv6
over NFC.

PROPOSED:
When the MIUX parameter is used, the TLV Type
field MUST be 0x02 and the TLV Length field MUST be 0x02. The MIUX
parameter MUST be encoded into the least significant 11 bits of the
TLV Value field. The unused bits in the TLV Value field MUST be set
to zero by the sender and ignored by the receiver. The maximum possible
value of the TLV Value field is 0x7FF, and the maximum size of the LLCP
MTU is 2176 bytes. If fragmentation functionality is not used at the
adaptation layer between IPv6 and NFC, the MIUX value MUST be 0x480 to
support the IPv6 MTU requirement (of 1280 bytes).


17. Section 4.1: s/TCP and UDP/e.g. TCP  and UDP

18. Section 4.1: s/capable/capable of

19. Figure 3 caption: s/Protocol Stacks/Protocol Stack

20. CURRENT:
The adaptation layer for IPv6 over NFC support neighbor discovery,
stateless address auto-configuration, header compression, and
fragmentation & reassembly.

PROPOSED:
The adaptation layer for IPv6 over NFC supports neighbor discovery,
stateless address auto-configuration, header compression, and
fragmentation & reassembly, based on 6LoWPAN.

21. Section 4.2

21.a. I’d suggest to remove the first paragraph, as it either focuses on
BT-LE (?) or it discusses fragmentation, for which there is a dedicated
section later.

21.b.  For similar reasons, please remove the second paragraph.

21.c.  From the third paragraph, I’d suggest keeping only the following:

PROPOSED:
The NFC link between two communicating devices is considered to be a
point-to-point link only. An NFC link does not support a star topology or
mesh network topology but only direct connections between two devices. The
NFC link layer does not support packet forwarding in link layer.

22. “An NFC-enabled device (i.e., 6LN)”. Later, the document indicates
that an NFC device could be a 6LN, a 6LR or a 6LBR. Therefore, it seems
that “(i.e., 6LN)” should be removed...

23. Section 4.3. Last paragraph. Are “F()” and “Net_IFace” defined in the
RFCs mentioned in the previous paragraph? If yes, please state so to help
the reader. Also, is it “Net_Iface” or “NetIFace”? Please stick to the
same form of the term in the paragraph.

24. Section 4.4 title: s/Link Local/Link-Local

25. CURRENT:
The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
network can be accomplished via DHCPv6 Prefix Delegation ([RFC3633]).

PROPOSED:
A 6LBR may obtain an IPv6 prefix for numbering the NFC network via DHCPv6
Prefix Delegation ([RFC3633]).

26. “The "Interface Identifier" is used the secured and stable IIDs for
NFC-enabled devices.”  -- I didn’t understand what is intended in this
sentence.

27. CURRENT:
NFC does not support a complicated mesh topology but only a simple
multi-hop network topology or directly connected peer-to-peer network.

-- From the above text, it is not clear what is supported and what is not.
What is meant by “a simple multi-hop network topology”? When is a topology
“simple enough” to fit in that category?

28. CURRENT:
When an NFC-enabled device (6LN) is directly connected to a NFCenabled
6LBR, an NFC 6LN MUST register its address with the
6LBR[RFC4944] by sending a Neighbor Solicitation (NS) message with
the Address Registration Option (ARO) and process the Neighbor
Advertisement (NA) accordingly.

PROPOSED:
When an NFC-enabled 6LN is directly connected to an NFC-enabled
6LBR, the NFC 6LN MUST register its address with the
6LBR by sending a Neighbor Solicitation (NS) message with
the Address Registration Option (ARO), and process the Neighbor
Advertisement (NA) accordingly.


29. CURRENT:
When two or more NFC 6LNs[RFC4944](or 6LRs) are connected, there
are two cases.

PROPOSED:
When two or more NFC devices are connected, there are two cases.


30. CURRENT:
In a case of multihops, all of 6LNs, which have two or more connections
with different neighbors, is a router for 6LR/6LBR.

-- I fail to understand the meaning of the above sentence.

31. “When a NFC device becomes a 6LR or a 6LBR”

-- Wouldn’t it be more simple to replace “becomes” by “is”?  (I think that
“becomes” gives the impression that there is some process that transforms
a device into a 6LR or a 6LBR, and perhaps that process opens additional
questions...)

32. Section 4.6: “a Dispatch value followed by zero or more header fields.”

-- What layer or protocol does “header fields” correspond to in the above
sentence?

33. Section 4.6. Note that different forms are used to refer to the same:
“LOWPAN_IPHC”, and “6LOWPAN_IPHC”. Please stick to just one term.

34. Section 4.6, last sentence.
-- If there is no other 6LoWPAN Dispatch type used, then fragmentation
cannot be used. So either fragmentation Dispatch types can be used, or
fragmentation cannot be used at the adaptation layer.

35. Section 4.8.

35.a: s/MUST NOT/SHOULD NOT  (note: otherwise, the MUST NOT contradicts
the last sentences of the section)

35.b: “does not support extension”. Does this mean “does not support
MIUX”? (Note that the meaning of “extension”, as it is written, is
unclear.)

36. CURRENT:
NFC networks can be isolated and connected to the Internet.

PROPOSED:
NFC networks can either be isolated or connected to the Internet.

37. Section 5.1. The first paragraph still sounds as marketing-oriented
text, and/or not adding actual specification content. I’d suggest removing
it.

38. I think that the content of Section 5 might need to be placed in
Section 4.2 (which has the purpose of presenting the link model).

39. Figure 11 illustrates a star topology network. Is it possible to
support a mesh topology? Or e.g. a 3-hop string topology?

40. I’d suggest removing the whole last paragraph of section 5.2. It does
not appear to be very aligned with Figure 11.

41. Section 7. I’d suggest to start by describing again here the intrinsic
security properties of NFC due to its short link range. Also, does NFC
define any actual security mechanisms? It would be good to state so.

42. Section 7. I’d suggest removing the first sentence, as it contradicts
most of the purpose of this whole document.

43. CURRENT:
However, NFC applications use short-lived
connections, and the every connection is made with different address
of NFC link with an extremely short-lived link.

PROPOSED:
However, NFC applications use short-lived
connections, and a different address is used for each connection, where
the latter is of extremely short duration.

44. Last paragraph of Section 7. Similar concerns as in comment 42.