Skip to main content

Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-17

Discuss


Yes

(Suresh Krishnan)

No Objection

Alvaro Retana
(Deborah Brungard)

No Record

Andrew Alston
Erik Kline
Francesca Palombini
John Scudder
Lars Eggert
Martin Duke
Murray Kucherawy
Paul Wouters
Robert Wilton
Roman Danyliw
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 8 more YES or NO OBJECTION positions to pass.

Alvaro Retana No Objection

Warren Kumari No Objection

Comment (2019-03-14 for -13)
I apologize - I've read the document, but it doesn't seem like it contains enough information to allow a full implementation.

The document keeps talking about the fact that the range is limited to 10cm, and makes some security assertions from this - from the little that I understand about this technology (and I wasn't able to follow all the references), ISO 15693 tags using NDEF are now part of the NFC specification - these  work up to 1M. I have no idea if this protocol is supposed to work over that, but if so, 1M is greater than 10cm.

Also, I see you did respond to the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-6lo-nfc-12-opsdir-lc-wu-2018-12-19/ -- thank you very much, Qin) , but there are things in these which don't seem fully addressed. As an example, Qin asked:
----
 Section 3.4 said ” the MTU size in NFC LLCP MUST be calculated from the MIU
   value as follows:
                             MIU = 128 + MIUX.”
Can you provide formula to calculate MTU from MIU? Not clear how MTU is related to MIU? 
---

You responded: "YH >> Actually, MIU is the same as MTU. Specifications in NFC forum use 'MIU', and we use 'MTU'. But these two has the same meaning."

I read version 13 of this document and had the exact same question -- how do I calculate the MTU from the MIU? If they really are the same thing (which I'm not sure they are), the document should state that, so readers can more easily implement.

Andrew Alston No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Murray Kucherawy No Record

Paul Wouters No Record

Robert Wilton No Record

Roman Danyliw No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Benjamin Kaduk; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2022-03-22)
I attempted to review the changes from -13 to -17, as well as look at
the -17 in isolation, though I do not really have enough time available
to do a proper review before my term as AD expires.

I'm still worried that in general this document doesn't give a clear
picture of how all the pieces fit together, and which pieces are new
as opposed to reused from other specifications.

I do appreciate many of the updates made to streamline the introductory
text and keep it focused on what is relevant for this document.

I am also happy to see that use of MIUX has been made mandatory so that
the L2CAP FAR is not needed.  However, I do not see much justification
for the MUST-level requirement that the MIUX value be exactly 0x480.
Is there some reason to forbid the negotiation of larger link MTU, if
both parties are capable?  I would have expected only a requirement
that the MIUX value be at least 0x480.

Section 4.3 should probably provide some guidance on choosing the PRF
F().  We are implicitly relying on RFC 7217 for a lot of things, some of
which 7127 doesn't even cover, and the suggested construction in RFC
7127 may not still be best practice.

I think the figure in Section 3.4 that lays out the encoding of the
MIUX TLV is incomplete or inaccurate -- e.g., the third field shows
only four bits but the labels indicate it should occupy six bits,
and the range of values for the fourth field indicates it should occupy
eleven bits but the column labels give it only ten.

A section-by-section point as well:

Section 4.5

   o  When an NFC-enabled 6LN is directly connected to a an NFC-enabled
      6LBR, the NFC 6LN MUST register its address with the 6LBR by

How does the device know that it's talking NFC to a 6LBR as opposed to
some non-border-router peer?

(Eric Rescorla; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2019-03-13 for -13)
I am unable to adequately review this document because the first normative reference and hence this DISCUSS is incomplete (ordinarily this would conflict with the DISCUSS guidelines, but I believe it is necessary in this case).

   [LLCP-1.3]
              "NFC Logical Link Control Protocol version 1.3", NFC Forum
              Technical Specification , March 2016.

Does not appear to be publicly available (the web site contains a single-page PDF which reads in part "To view the complete specification, go to http://nfc-forum.org/our- work/specifications-and-application-documents/specifications/nfc-forum- technical-specifications/. Complete the license agreement, and then download the specification."). Please supply an unencumbered specification and then I can rereview.


I have read S 3.4 repeatedly, but am unable to work out the mapping of an IPv6 datagram to LLCP. Please provide a diagram that shows how this works and then perhaps I can assist you with the text.

(Suresh Krishnan; former steering group member) Yes

Yes (for -13)

                            

(Adam Roach; former steering group member) (was Discuss) No Objection

No Objection (2020-01-23 for -15)
Thanks for addressing my DISCUSS point.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2019-03-13 for -13)
I agree with Benjamin about antenna size. Despite that I have enjoyed reading this document. I have some questions/comments that I would like to discuss before recommending publication of this document as an RFC:

In 3.2:

   The LLCP consists of Logical Link Control (LLC) and MAC Mapping.  The
   MAC Mapping integrates an existing RF protocol into the LLCP
   architecture.  The LLC contains three components, such as Link
   Management, Connection-oriented Transmission, and Connection-less
   Transmission.  The Link Management component is responsible for
   serializing all connection-oriented and connection-less LLC PDU
   (Protocol Data Unit) exchanges and for aggregation and disaggregation
   of small PDUs.  This component also guarantees asynchronous balanced
   mode communication and provides link status supervision by performing
   the symmetry procedure.

Can you translate the last sentence for somebody who is not an expert in this?

In 4.4:

   The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
   network is can be accomplished via DHCPv6 Prefix Delegation

I think "is" before "can be" should be deleted above.

   ([RFC3633]).

In 4.5:

   o  When two or more NFC 6LNs(or 6LRs) meet, there are two cases.  One
      is that three or more NFC devices are linked with multi-hop
      connections, and the other is that they meet within a single hop
      range (e.g., isolated network).  In a case of multi-hops, all of
      6LNs, which have two or more connections with different neighbors,
      MAY be a router for 6LR/6LBR.  In a case that they meet within a
      single hop and they have the same properties, any of them can be a
      router.  When the NFC nodes are not of uniform category (e.g.,
      different MTU, level of remaining energy, connectivity, etc.), a
      performance-outstanding device can become a router.

The last sentence: how can 2 NFC nodes figure out which one has higher level or remaining energy, etc?

In 4.7:

   Therefore, IPv6 header compression in [RFC6282] MUST be implemented.
   Further, implementations MAY also support Generic Header Compression
   (GHC) of [RFC7400].

Will 2 NFC implementations interoperate if one of them supports GHC and the other one doesn't?
If they can't, then "MAY" seems to be too weak here.


In 4.8:

   IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is
   NOT RECOMMENDED in this document as discussed in Section 3.4.

You are using "NOT RECOMMENDED", which is "SHOULD NOT". Why is this not a "MUST NOT" and why implementation of FAR would be Ok if one node supports it and another one doesn't?

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2020-11-25)
Thanks for addressing my DISCUSS points. Original COMMENT below:

= General =

I agree with Benjamin that the marketing-type language in the document should be removed.

I wonder about the claims of security based on proximity in this document. Presumably attacks in which users are induced to tap their device against another node or terminal which has been compromised by an attacker are becoming more common as NFC becomes more common; adding IPV6 connectivity to the terminal stack surely broadens the potential damage done in such a case. This seems worth noting.

= Section 1 =

OLD
It has been used in devices such as mobile phones, running Android operating
   system, named with a feature called "Android Beam".  In addition, it
   is expected for the other mobile phones, running the other operating
   systems (e.g., iOS, etc.) to be equipped with NFC technology in the
   near future.

NEW
At the time of this writing, it had been used in devices such as mobile phones, running Android operating
   system, named with a feature called "Android Beam".  It was expected for the other mobile phones, running the other operating
   systems (e.g., iOS, etc.) to be equipped with NFC technology in the
   near future.

= Section 4.5 =

Per the Gen-ART review, the use of the term "meet" is confusing in this section. Please re-phrase.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -13)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-03-13 for -13)
1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a mismatch between the text and the figure that needs to be resolved or clarified before publication.

2)Use of normative language doesn't always seem quite appropriate, especially SHALL. Benjamin already identified some cases in section 3.3. 

Here is an additional one in sec 4.1:
"The adaptation layer for IPv6 over NFC SHALL support neighbor
   discovery, stateless address auto-configuration, header compression,
   and fragmentation & reassembly."

Also this MAY in sec 5.2:
"In an isolated NFC-enabled device network,
   when two or more LRs MAY be connected with each other, and then they
   are acting like routers, the 6LR MUST ensure address collisions do
   not occur."

Please also check other occurrences.

3) I would have expected to see some discussion about the ability to potentially connect devices over an IP-gateway device to the Internet that were previously not designed to be connected to the Internet. However, maybe that's asked too much as that is certainly something that needs to be addressed by either a higher layer or the device system architecture as a whole.

(Spencer Dawkins; former steering group member) No Objection

No Objection (2019-03-13 for -13)
I support Alissa's second Discuss point about the plan for fragmentation interoperation, and her third Discuss point about connecting unsuspecting devices to the Internet :-) 

Other people have said this, but requiring MIUX would be awesome.