Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11
Note: This ballot was opened for revision 47 and is now closed.
Suresh Krishnan Yes
Deborah Brungard No Objection
Alissa Cooper (was Discuss) No Objection
Comment (2019-08-01 for -51)
Thank you addressing my DISCUSS and COMMENT.
Roman Danyliw (was Discuss) No Objection
Comment (2019-07-25 for -51)
Thank you for addressing my DISCUSS and some of the COMMENTs. (Resolved comments removed) (5) Section 1. Per “The resulting stack inherits from IPv6 over Ethernet [RFC2462], but operates over …”, what exactly is being inherited? What does “inherited” mean in this case? (6) Section 4.3. Per “Among these types of addresses only the IPv6 link-local addresses can be formed using an EUI-64 identifier, in particular during transition time”, the meaning of the “in particular during transition time isn’t clear in the text. Should it say "in particular as all clients are upgraded to this specification?" (9) Section 5. What is “protected 802.11” mentioned in “Such a link is less protected …”? (10) Section 5.2. SHA256 needs a reference. (11) Editorial Nits ** Section 4.5. Typo. s/.A A future/. A future/ ** Section 5.1. Typo. s/Futhermore/Furthermore/ ** Section 5.1. Typo. s/pricavy/privacy/ ** Section 5.2. Typo. s/admninistered/ administered/ ** Appendix H. Duplicate word. s/section Section 2/Section 2/
Warren Kumari No Objection
Mirja Kühlewind (was Discuss) No Objection
Comment (2019-07-26 for -51)
Thanks for addressing my discuss! One editorial high level comment: I seams like all text that was somehow deemed as out fo scope for the main body of this document got stuffed into the appendix. Please consider removing what is really not needed in this document as these pages also take review and RFC Editor time, especially as they seem to have received less review and therefore have more nits. nit: sec 4.5.2 s/in OCB mode.A A future improvement/in OCB mode. A future improvement/
Barry Leiba (was Discuss) No Objection
Comment (2019-07-11 for -49)
A very simple point to fix, and Nabil has already queued it up for the next revision: IEEE-802.11-2016 should be normative because it is the reference for 802.11-OCB and is the subject of a MUST in Section 4.2. These are all editorial comments: — Section 4.4 — For Interface Identifiers for IPv6 address of type 'Link-Local' are discussed in Section 4.3. There’s something wrong with that sentence. Maybe it’s just that the first word needs to be struck? Regardless of how to form the IID, its length is 64 bits, as is the case of the IPv6 over Ethernet [RFC2464]. There’s something wrong with this sentence too, but I don’t know what the fix is: I don’t know what the “as is the case...” part is meant to say. Can you try rephrasing? If semantically opaque IIDs are needed, they MAY be generated using the method for generating semantically opaque IIDs This isn’t wrong with the “MAY”, but I think it really is just a non-keyword “may”. — Section 4.5.2 — The meaning of the value "3333" mentioned in that section 7 of [RFC2464] As you’ve just given the section reference in the previous sentence, I think it reads better to use the context and just say, “The meaning of the value "3333" mentioned there”. — Section 4.6 — A subnet may be formed over 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). At first I tried to understand what the in-vehicle interfaces had to do with the close range. I think it’s clearer with this word order: NEW When vehicles are in close range, a subnet may be formed over 802.11-OCB interfaces (not by their in-vehicle interfaces). END An IPv6 subnet on which Neighbor Discovery protocol (ND) can be mapped on an OCB network if all nodes share a single broadcast Domain, which is generally the case for P2P OCB links; This isn’t a complete sentence: it has a subject, but no verb. What is it trying to say? Also, the semicolon should be a period, as it’s not useful to chain it onto the following sentence. strict (e.g. fast drive through IP-RSU coverage) The “e.g.” needs a comma after it (or change it to “such as with”), and “fast-drive-through” needs to be hyphenated, as a compound modifier. — Section 5 — application-layer mechanisms are out-of- scope of this document. Here, “out of scope” should not be hyphenated (it’s not a modifier). and performs attacks without needing to physically break any wall. “and performs attacks” shoud be “and perform attacks”. The “physically break any wall” part seems kind of odd, as there are clearly no physical walls involved at all. What are you really trying to say? The potential attack vectors are: MAC address spoofing, IP address and session hijacking, and privacy violation Section 5.1. What is “Section 5.1” about? Is that meant to be a citation, like “[Section 5.1]” ? — Section 5.1 — A vehicle embarking an IP- OBU whose egress interface is 802.11-OCB may expose itself to eavesdropping and subsequent correlation of data; this may reveal data considered private by the vehicle owner; there is a risk of being tracked. It’s awkward to chain three sentences with semicolons. I would separate the first one: change the first semicolon into a period. as dynamically changing MAC addresses Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers Section 4.4. The two section references should be bracketed, as “[Section 5.2]”. Futhermore, for pricavy concerns ([RFC8065]) recommends Make it, “Futhermore, for privacy concerns, [RFC8065] recommends“. — Section 5.1.1 — means, or other visual information (car color, others) MAY constitute privacy risks. This “MAY” should definitely be “may”: it’s just a statement of fact. — Section 5.2 — In 802.11-OCB networks, the MAC addresses MAY change during well defined renumbering events. Also a statement of fact, so “may”.
Alexey Melnikov No Objection
Alvaro Retana No Objection
Comment (2019-07-05 for -47)
§4.3: I think that the MAYs used in this section are out of place as they only state facts and not Normative behavior. s/MAY/may §4.5.2: "Future improvement to this specification SHOULD consider solutions for these problems." I understand the interest to consider the problems...but I don't think there's any Normative action that results from using SHOULD. s/SHOULD/should
Adam Roach No Objection
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2019-07-07 for -48)
Thank you for the work put into this document. Interesting use case ;-) Beside the 3 COMMENTs below, I have a question: my understanding is that this is a P2P link, so, layer-3 multicast packets could easily be sent over unicast layer-2 IF the other peer is known with its layer-2 address which is possibly known when forming a OCB "association" (but I am not a WiFi person at all). Just curious here ;-) Regards, -éric == COMMENTS == -- Section 3 -- It is unclear whether a IP-OBU <-> IP-OBU is a use case of this document (it is mentionned in 4.6 though but it would help the reader to have it mentioned in section 3). -- Section 4.4 -- In the discussion of SLAAC, there should be a mention on the presence or absence of Router Advertisement and if RA are used: - which entity sends this RA (probably IP-RSU), - does RA contain PIO ? - what are the recommendation for router lifetime (and PIO timers) ? -- Missing -- Duplicate Address Detection is only mentioned in Appendix I and it is unclear whether optimistic DAD (even for LLA) should/must be used.
Magnus Westerlund No Objection
Benjamin Kaduk No Record
Comment (2019-07-11 for -49)
Remaining at No Record since I am balloting late, but: It may be worth noting in the privacy/security considerations that an attacker may not heed to legal limits for radio power and can use a very sensitive directional antenna; if the attacker wishes to attack a given exchange they do not necessarily need to be in close physical proximity.