Re: draft-ietf-ipwave-ipv6-over-80211ocb-38

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Brian,

Le 12/04/2019 à 22:28, Brian E Carpenter a écrit :
On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
If you go back and check 2017 archives, I did raise many of these issues. But, we clearly decided to limit the scope excluding address configuration, DAD, ND aspect, link models. When there is such a scope statement, it should clearly move these comments to the draft that defines how ND works for 802.11-OCB links.

This is of course possible. In general the IETF hasn't done that,
but has followed the lead set by RFC 2464 with the complete
specification of IPv6-over-foo in one document.

However, I don't believe that publishing an RFC about the frame format without *simultaneously* publishing an RFC about ND etc would be a good idea.

Brian - it took us several years to arrive at this IP-over-OCB spec.  I
suspect an ND-over-OCB would take even longer, as it seems more complex
in particular mobility contexts; mobility contexts are hard tot try.
What happens with the IP-over-OCB spec during these additional years?  A
draft expires after 6 months.  Would one update the IP-over-OCB draft
update it every 6 months with just artificial ' ' in it just to keep it
alive?  It does not seem feasible.

That would leave developers absolutely unable to write useful code,
and might easily lead to incompatible implementations. Since we'd
presumably like Fords to be able to communicate with Peugeots, that
seems like a bad idea.

Fords talking to Peugeots in a convoy can work fine today, without additional ND work. ND works fine on PHYs and MACs that are set up properly.

Alex


Regards Brian

https://mailarchive.ietf.org/arch/msg/its/9NvUfRigGd4Klu0Q2Ee-63ziATw




https://mailarchive.ietf.org/arch/msg/its/VcrwNSvNJVIZNcRLNjDY0iSw3CA

Sri




From: its <its-bounces@xxxxxxxx <mailto:its-bounces@xxxxxxxx>> on behalf of Sri Gundavelli <sgundave@xxxxxxxxx <mailto:sgundave@xxxxxxxxx>> Date: Friday, April 12, 2019 at 7:38 AM To: Nabil Benamar <benamar73@xxxxxxxxx <mailto:benamar73@xxxxxxxxx>>, "Pascal Thubert (pthubert)" <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>> Cc:
"ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>" <ietf@xxxxxxxx
<mailto:ietf@xxxxxxxx>>, "its@xxxxxxxx <mailto:its@xxxxxxxx>"
<its@xxxxxxxx <mailto:its@xxxxxxxx>>, "int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx>" <int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx>>, Nabil Benamar <n.benamar@xxxxxxxxxxxxx <mailto:n.benamar@xxxxxxxxxxxxx>>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx>" <draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx>>, Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>> Subject: Re: [ipwave]
Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

I am not following these discussions. From my point of view, many of the discussions are totally out of scope for this document.

Some one needs to moderate these discussions.

Sri



From: its <its-bounces@xxxxxxxx <mailto:its-bounces@xxxxxxxx>> on behalf of Nabil Benamar <benamar73@xxxxxxxxx <mailto:benamar73@xxxxxxxxx>> Date: Friday, April 12, 2019 at 7:34 AM To: "Pascal Thubert (pthubert)" <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>> Cc: "ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>" <ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>>, "its@xxxxxxxx <mailto:its@xxxxxxxx>" <its@xxxxxxxx <mailto:its@xxxxxxxx>>, "int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx>" <int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx>>, Nabil Benamar <n.benamar@xxxxxxxxxxxxx <mailto:n.benamar@xxxxxxxxxxxxx>>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx>" <draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx>>, Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>> Subject: Re: [ipwave]
Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Hello Pascal,

I seconded Akex and would like to suggest you to add the missing text in the draft.

Best regards Nabil



On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>> wrote:

Hello Nabil.____

__ __

You will get a number of IESG reviews as part of the submission process, one per area. This is just a beginning…____

__ __

Cheers,____

__ __

Pascal____

__ __

*From:* NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx <mailto:n.benamar@xxxxxxxxxxxxx>> *Sent:* lundi 8 avril 2019 17:53 *To:* Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>> *Cc:* Pascal Thubert (pthubert) <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>>; int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx>; ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>; its@xxxxxxxx <mailto:its@xxxxxxxx>; draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx <mailto:draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxxxx> *Subject:* Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34____

__ __

Yes definitely Alex....____

__ __

There have been many reviews until now. This should be a late or final review.____

__ __

On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>> wrote:____

As a note: please improve the title of this.____

It is not an early review.____

It is a late review.____

There have been several reviews of this document until here, and two shepherd reviews.____

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,____

see https://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 its@xxxxxxxx <mailto:its@xxxxxxxx> https://www.ietf.org/mailman/listinfo/its







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux