Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[Alexandre Petrescu <[e-mail]>]

Pascal,

IP over 802.15.4 ('6lowpan' RFC 4944) uses a different adaptation layer 
than the Ethernet Adaptation Layer used by IP over OCB 
(draft-ietf-ipwave-ipv6-over-80211ocb-34)

Why do you want to use IP-over-802154?  It has nothing to do, right?

Alex

Le 05/04/2019 à 19:53, Alexandre Petrescu a écrit :
> PAscal,
> Thank you for the text.  We discussed about submitting text and text is 
> what is needed.
> 
> The beginning sounds good.
> 
> But then it is very long.
> 
> We have to discuss further RFC 8505 before inclusion of that RECOMMENDED.
> 
> Alex
> 
> Le 05/04/2019 à 17:09, Pascal Thubert (pthubert) a écrit :
>> Dear all;
>>
>> As promised I put together some words on using IPv6 ND and then RFC 
>> 8505 for OCB. Please find attached early text. This could become a 
>> section 4.7.
>>
>> Note that RFC 8505 enables a DAD operation for both link local and 
>> global addresses, the associated global prefix being owned by either a 
>> car or a RSU. RSUs connected to the internet can advertise a default 
>> router preference to indicate they are willing to relay packets for 
>> global addresses.
>>
>> The attached text impacts other sections in particular the discussion 
>> on global addresses which is somehow avoided in the current draft and 
>> could be reintroduced.
>>
>> Comments welcome : )
>>
>> Pascal
>>
>> *From:* Pascal Thubert (pthubert)
>> *Sent:* jeudi 28 mars 2019 11:29
>> *To:* Alexandre Petrescu <[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* Re: Intdir early review of 
>> draft-ietf-ipwave-ipv6-over-80211ocb-34
>>
>> Yes Alex. Also as an offer to help...
>>
>> Regards,
>>
>> Pascal
>>
>>
>> Le 28 mars 2019 à 11:08, Alexandre Petrescu 
>> <[e-mail] <mailto:[e-mail]>> a 
>> écrit :
>>
>>     Pascal,
>>
>>     Should we treat these two reviews (iotdir and intdir reviews) as
>>     just one?
>>
>>     The contents appear to me to be the same.
>>
>>     Alex
>>
>>     Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>>
>>         Reviewer: Pascal Thubert
>>
>>         Review result: Not Ready
>>
>>         Reviewer: Pascal Thubert
>>
>>         Review result: Not ready. Need to clarify IEEE relationship, 
>> IOW which SDO
>>
>>         defines the use of L2 fields, what this spec enforces vs. 
>> recognizes as being
>>
>>         used that way based on IEEE work. The use of IPv6 ND requires 
>> a lot more
>>
>>         thoughts, recommendation to use 6LoWPAN ND. The definition of 
>> a subnet is
>>
>>         unclear. It seems that RSUs would have prefixes but that is 
>> not discussed.
>>
>>         I am an assigned INT and IOT directorates reviewer for <
>>
>>         draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were 
>> written
>>
>>         primarily for the benefit of the Internet Area Directors. 
>> Document editors and
>>
>>         shepherd(s) should treat these comments just like they would 
>> treat comments
>>
>>         from any other IETF contributors and resolve them along with 
>> any other Last
>>
>>         Call comments that have been received. For more details on the 
>> INT Directorate,
>>
>>         seehttps://datatracker.ietf.org/group/intdir/about/
>>
>>         Majors issues
>>
>>         -----------------
>>
>>         “
>>
>>         o  Exceptions due to different operation of IPv6 network layer on
>>
>>                802.11 than on Ethernet.
>>
>>         “
>>
>>         Is this doc scoped to OCB or 802.11 in general? Is there an 
>> expectation that an
>>
>>         implementer of IPv6 over Wi-Fi refers to this doc? Spelled as 
>> above, it seems
>>
>>         that you are defining the LLC. Figure 1 shows the proposed 
>> adaptation layer as
>>
>>         IEEE LLC work. Who defines those fields, IETF or IEEE, or 
>> mixed? Who defines
>>
>>         their use? If this spec defines a new LLC header (vs. how to 
>> use an IEEE field)
>>
>>           then it should be very clear, and the newly defined fields 
>> should be isolated
>>
>>         from IEEE fields.
>>
>>         "
>>
>>             The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>>
>>             preceded by a Logical Link Control (LLC) header and an 
>> 802.11 header.
>>
>>         "
>>
>>         Is there anything new or specific to OCB vs. classical 802.11 
>> operations?
>>
>>         If/when this is echoing the IEEE specs then this text should 
>> not use uppercase
>>
>>         but say something like: 'Per IEEE Std 802.11, the IPv6 packet 
>> transmitted on
>>
>>         802.11-OCB is immediately  preceded by a Logical Link Control 
>> (LLC) header and
>>
>>         an 802.11 header ...'
>>
>>         different things? Why define both?
>>
>>         "   An 'adaptation' layer is inserted between a MAC layer and the
>>
>>             Networking layer.  This is used to transform some 
>> parameters between
>>
>>             their form expected by the IP stack and the form provided 
>> by the MAC
>>
>>             layer.
>>
>>         "
>>
>>         Is this different from what an AP does when it bridges Wi-Fi 
>> to Ethernet? Is
>>
>>         this IETF business?
>>
>>         "
>>
>>             The Receiver and Transmitter Address fields in the 802.11 
>> header MUST
>>
>>             contain the same values as the Destination and the Source 
>> Address
>>
>>             fields in the Ethernet II Header, respectively.
>>
>>         "
>>
>>         Same,  this is IEEE game isn't it?
>>
>>         "
>>
>>         Solutions for these problems SHOULD
>>
>>             consider the OCB mode of operation.
>>
>>         "
>>
>>         This is not specific enough to be actionable. I suggest to 
>> remove this sentence.
>>
>>         It would be of interest for the people defining those 
>> solutions to understand
>>
>>         the specific needs of OCB vs. Wi Fi, but I do not see text 
>> about that.
>>
>>         "
>>
>>         The method of forming IIDs
>>
>>             described in section 4 of [RFC2464] MAY be used during 
>> transition
>>
>>             time.
>>
>>         "
>>
>>         Contradicts section 4.3 that says
>>
>>         "
>>
>>         Among these types of
>>
>>             addresses only the IPv6 link-local addresses MAY be formed 
>> using an
>>
>>             EUI-64 identifier.
>>
>>         "
>>
>>         "
>>
>>         This
>>
>>             subnet MUST use at least the link-local prefix fe80::/10 
>> and the
>>
>>             interfaces MUST be assigned IPv6 addresses of type 
>> link-local.
>>
>>         "
>>
>>         If this is conforming IPv6 then the MUST is not needed.
>>
>>         "
>>
>>             A subnet is formed by the external 802.11-OCB interfaces 
>> of vehicles
>>
>>             that are in close range (not by their in-vehicle interfaces).
>>
>>         "
>>
>>         Is the definition transitive? Do we really get a subnet?
>>
>>           A is close to  B who is close to C .... to Z, makes Paris 
>> one subnet! Are you
>>
>>           talking about a link, rather?
>>
>>         "
>>
>>             The Neighbor Discovery protocol (ND) [RFC4861] MUST be 
>> used over
>>
>>             802.11-OCB links.
>>
>>         "
>>
>>         IPv6 ND is not suited for a non-broadcast network. How does 
>> DAD work?
>>
>>         Maybe you could consider RFC 6775 / RFC 8505 instead.
>>
>>         "
>>
>>         In the moment the MAC address is changed
>>
>>             on an 802.11-OCB interface all the Interface Identifiers 
>> of IPv6
>>
>>             addresses assigned to that interface MUST change.
>>
>>         "
>>
>>         Why is that? This is unexpected, and hopefully wrong.
>>
>>         Minor issues
>>
>>         ---------------
>>
>>         "   OCB (outside the context of a basic service set - BSS): A 
>> mode of
>>
>>             operation in which a STA is not a member of a BSS and does 
>> not
>>
>>             utilize IEEE Std 802.11 authentication, association, or data
>>
>>             confidentiality.
>>
>>             802.11-OCB: mode specified in IEEE Std 802.11-2016 when 
>> the MIB
>>
>>             attribute dot11OCBActivited is true.  Note: compliance 
>> with standards
>>
>>             and regulations set in different countries when using the 
>> 5.9GHz
>>
>>             frequency band is required.
>>
>>         "
>>
>>         Are these 2 different things?
>>
>>         "
>>
>>         Among these types of
>>
>>           addresses only the IPv6 link-local addresses MAY be formed 
>> using an
>>
>>            EUI-64 identifier.
>>
>>         "
>>
>>         This text should not be in a LL specific section since it 
>> deals with the other
>>
>>         addresses. Maybe rename the section to "addressing" or something?
>>
>>         "
>>
>>             For privacy, the link-local address MAY be formed 
>> according to the
>>
>>             mechanisms described in Section 5.2.
>>
>>         "
>>
>>         The MAY is not helpful. I suggest to remove the sentence that 
>> does not bring
>>
>>         value vs. 5.2
>>
>>         Could you make sections 4.3 and 4.5 contiguous?
>>
>>         "
>>
>>         If semantically
>>
>>             opaque Interface Identifiers are needed, a potential 
>> method for
>>
>>             generating semantically opaque Interface Identifiers with 
>> IPv6
>>
>>             Stateless Address Autoconfiguration is given in [RFC7217].
>>
>>             Semantically opaque Interface Identifiers, instead of 
>> meaningful
>>
>>             Interface Identifiers derived from a valid and meaningful 
>> MAC address
>>
>>             ([RFC2464], section 4), MAY be needed in order to avoid 
>> certain
>>
>>             privacy risks.
>>
>>         ...
>>
>>             In order to avoid these risks, opaque Interface 
>> Identifiers MAY be
>>
>>             formed according to rules described in [RFC7217].  These 
>> opaque
>>
>>             Interface Identifiers are formed starting from identifiers 
>> different
>>
>>             than the MAC addresses, and from cryptographically strong 
>> material.
>>
>>             Thus, privacy sensitive information is absent from 
>> Interface IDs, and
>>
>>             it is impossible to calculate the initial value from which 
>> the
>>
>>             Interface ID was calculated.
>>
>>         "
>>
>>         Duplicate and mis ordered text, isn't it?
>>
>>         " For this reason, an attacker may realize many
>>
>>             attacks on privacy.
>>
>>         "
>>
>>         Do we attack privacy? Maybe say that privacy is a real 
>> concern, and maybe move
>>
>>         that text to security section?
>>
>>         "
>>
>>             The way Interface Identifiers are used MAY involve risks 
>> to privacy,
>>
>>             as described in Section 5.1.
>>
>>         "
>>
>>         Also duplicate
>>
>>         Nits
>>
>>         ------
>>
>>         "
>>
>>             IP packets MUST be transmitted over 802.11-OCB media as 
>> QoS Data
>>
>>             frames whose format is specified in IEEE Std 802.11.
>>
>>         "
>>
>>         Please add link to the reference
>>
>>         " the 802.11 hidden node"
>>
>>         Do not use 802.11 standalone (multiple occurrences).
>>
>>         => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the 
>> hidden terminal".
>>
>>         BCP 14 text:
>>
>>         Suggest to use this text:
>>
>>         “
>>
>>             The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
>> "SHALL NOT",
>>
>>             "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 
>> "MAY", and
>>
>>             "OPTIONAL" in this document are to be interpreted as 
>> described in
>>
>>             https://tools.ietf.org/html/bcp14  
>> https://tools.ietf.org/html/bcp14
>>
>>             [https://tools.ietf.org/html/rfc2119][RFC8174] when, and 
>> only when, they
>>
>>             appear in all capitals, as shown here.
>>
>>         “
>>
>>         All the best
>>
>>         Pascal
>>
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its