Summary: Needs a YES. Has 2 DISCUSSes. Needs 7 more YES or NO OBJECTION positions to pass.
I support Benjamin's DISCUSS point about large antennas. RFC 2119 specifies the keywords "RECOMMENDED" and "NOT RECOMMENDED." This document uses these in verb form ("RECOMMEND" and "NOT RECOMMEND"). Please change these instances so that the actual 2119 keywords are used. = Section 4.8 = I think the Gen-ART reviewer's question about fragmentation is unresolved. How is interoperability achieved if some nodes implement MIUX and not FAR, and some nodes implement FAR and not MIUX? It seems as though IPv6-over-NFC needs to be restricted to nodes that support one or the other (presumably MIUX). = Section 5.1 and 7 = Per the Gen-ART review, one of these sections needs to say something about how connecting to the Internet potentially changes the threat model for devices that were perhaps not originally envisioned to connect to the Internet.
= 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.
In general, I'm worried that this document is so unreadable that I can't give it a proper review. I just don't have a clear picture of how all the pieces fit together, and which pieces are new as opposed to reused from other specifications. That said, here are my notes as they stand at present. If I understand correctly, the statements about "distance of 10 cm or less" and "safe" or "secure communications" apply only for usage compliant with the relevant legal regulations. We cannot expect attackers to abide by such regulations, and large (directional) antennas and/or high-power transmitters should be presumed to expand that distance by some factor, in adversarial environments. 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 don't understand why MIUX is not mandatory (and thus we could get rid of all the "FAR is NOT RECOMMENDED" stuff). Is there known demand for IPv6 over NFC on devices that cannot do MIUX? Some section-by-section points as well: Section 3.1 peer mode is used for ipv6-over-nfc. In addition, NFC-enabled devices can securely send IPv6 packets to any corresponding node on the Internet when an NFC-enabled gateway is linked to the Internet. I don't see anything in the document that justifies the usage of "securely". Section 3.4 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 Either the MIUX occupies 11 bits and there are five unused bits to be set to zero, or the four bits marked in the figure are 1011 and there is only one unused bit (singular) to be marked as zero. This needs to be more clear, as right now I can't tell what's intended. Section 4.4 How does a device know that the link-local address is a public address? Section 4.5 o When an NFC-enabled device (6LN) is directly connected to a 6LBR, an NFC 6LN MUST register its address with the 6LBR by sending a How does the device know that it's talking NFC to a 6LBR as opposed to some non-border-router peer?
A lot of this document reads like marketing material for NFC, which is a bit off-putting in a technical specification. (Some examples: "outstanding performance", "NFC builds upon RFID systems by allowing two-way communication between endpoints, where earlier systems such as contactless smart cards were one-way only", "NFC also has the strongest ability (e.g., secure communication distance of 10 cm) to prevent a third party from attacking privacy", "NFC technology enables simple and safe two-way interactions between electronic devices", "NFC's bidirectional communication ability is ideal for establishing connections with other technologies by the simplicity of touch", etc.) Section 1 Considering the potential for exponential growth in the number of heterogeneous air interface technologies, NFC would be widely used as one of the other air interface technologies, such as Bluetooth Low Energy (BT-LE), Wi-Fi, and so on. nit: I think there's a word missing here or something, maybe "as widely used". Section 3 NFC's bidirectional communication ability is ideal for establishing connections with other technologies by the simplicity of touch. In nit: other technologies, or other devices? Section 3.2 There's no "IPv6 layer" in Figure 1. Section 3.3 Address values between 10h and 1Fh SHALL be assigned by the local LLC to services registered by local service environment. [...] Is this duplicating a requirement from LLCP-1.3 or new to this spec? Section 3.4 MIUX extension parameter within the information field. If no MIUX parameter is transmitted, the default MIU value is 128 bytes. nit: I think this reads better (in context) without "default" here. 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 (Figure 2 is a little confusing because the '|' separator inside the value field occupies a bit position; this type of diagram is frequently laid out "double width", to allow a '| separator between each bit, with '+' characters in the horizontal delimiting lines to mark off bit boundaries.) Also, you say "least significant bits" without specifying network byte order. nit: isn't this "The" 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. How can we use all 128 bytes of MIU when we need to spend four bytes on the MIUX TLV? Section 4.1 It's unclear to me what information I'm supposed to get from Figure 3 that differs from what was in Figure 1. Section 4.2 This document does NOT RECOMMEND using FAR over NFC link due to simplicity of the protocol and implementation. [...] nit: this isn't clear about what is simple. ("If FAR is simple, wouldn't that make it easy to implement and use?") Section 4.3 An NFC-enabled device (i.e., 6LN) performs stateless address autoconfiguration as per [RFC4862]. A 64-bit Interface identifier (IID) for an NFC interface is formed by utilizing the 6-bit NFC LLCP address (see Section 3.3). In the viewpoint of address configuration, such an IID SHOULD guarantee a stable IPv6 address because each data link connection is uniquely identified by the pair of DSAP and SSAP included in the header of each LLC PDU in NFC. (Just to check: these DSAP and SSAP are only unique within the context of the current NFC pairing between two devices?) The writing here is hard to follow -- I'm supposed to utilize the 6-bit NFC LLCP address to form an IID (with nothing about how), but then we see that IIDs for unicast are randomly generated (without using the LLCP address), and only finally at the end do we mention the RFC 7217 PRF (and not even by name!) Section 4.4 Show me where the "Universal/Local" bit is, in the figure. Expand 6LBR (and 6LR) on first use, and/or have a terminology section that mentions that familiarity with the 6LoWPAN RFCs is assumed. Section 4.5 accordingly. In addition, if DHCPv6 is used to assign an address, Duplicate Address Detection (DAD) is not necessary. Not necessary in the DHCPv6 server or some other element? 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 I thought we said that NFC was a two-party thing only. How are we getting multi-hop connections? If I assume that this is talking about the IPv6 layer, how do we guarantee that only NFC-capable devices are participating in the IPv6 network? 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. [...] This seems rather under-specified. Section 4.9 A link to Section 4.6.1 of RFC 4861 and a note that the field descriptions are largely copied therefrom would be helpful. Section 5.1 This section is laying out the physical mechanics of how a NFC node can be connected to the Internet, but does not say why this is "typical" or what the NFC node would be talking to on the Internet. One of the key applications of using IPv6 over NFC is securely transmitting IPv6 packets because the RF distance between 6LN and 6LBR is typically within 10 cm. If any third party wants to hack into the RF between them, it must come to nearly touch them. Or use a big and ungainly high-gain antenna/illegal transmit power, right? Section 5.2 This example does a little better than the previous one at conveying what might motivate such a topology, but it's still pretty vague. What is "outstanding performance"? This doesn't seem actionable. Section 7 IPv6-over-NFC is, in practice, not used for long-lived links for big size data transfer or multimedia streaming, but used for extremely short-lived links (i.e., single touch-based approaches) for ID verification and mobile payment. This will mitigate the threat of correlation of activities over time. This mitigation only occurs if the IID is freshly generated for each link, which isn't mentioned until the next paragraph, so it's an unsupported claim at this point in the text. IPv6-over-NFC uses an IPv6 interface identifier formed from a "Short Address" and a set of well-known constant bits (such as padding with '0's) for the modified EUI-64 format. However, the short address of nit: Is the zero-padding really a "such as" or just a fact, given the protocol specification? NFC link layer (LLC) is not generated as a physically permanent value but logically generated for each connection. Thus, every single touch connection can use a different short address of NFC link with nit: I don't think this is "can use"; I think this is "uses". an extremely short-lived link. This can mitigate address scanning as well as location tracking and device-specific vulnerability exploitation. These last two seem to have high overlap with the "correlation of activities over time" from the previous paragraph. Thus, this document does not RECOMMEND sending NFC packets over the Internet or any unsecured network. I don't see any preceding argument that leads into or supports this claim; why is the word "thus" present? Also, such a recommendation seems like it should be more prominently made near the start of the document and not relegated to the security considerations. This document also does not give any indication of what might be considered to be a "secure" network. Note that per the RFC 3552 threat model, we generally do not place any trust in the network. Section 9.2 Isn't the whole point of this work that you are doing IPv6 over NFC? How do you not need to implement NFC in order to implement this?
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.
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.
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.
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.
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?
Thanks for addressing my DISCUSS point.