Subject: [ipwave] RFC8505 and 802.11 headers

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Apr 2019 21:04:20 +0200

Pascal,

Is RFC 8505 applicable on links on which 802.11 headers are used?

I understand RFC 8505 is applicable on links on which 802.15.4 headers 
are used (not 802.11).

In IPv6-over-OCB only the 802.11 headers are used and there are some 
particular values in some of its fields that must be used (e.g. the 
Traffic Identifier subfield of the QoS control field).

I am afraid if we try RFC 8505 then it comes with 802.15.4 headers...

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 6 Apr 2019 10:25:13 +0200

I agree with you Alex, I add we need to focus this work with its
objectives, and I am not sure what is the objective of using rfc8505 here.

AB

On Fri, Apr 5, 2019 at 9:05 PM Alexandre Petrescu <
[email-masked]> wrote:

> I understand RFC 8505 is applicable on links on which 802.15.4 headers are
> used (not 802.11).
>
> particular values in some of its fields that must be used (e.g. the Traffic
> Identifier subfield of the QoS control field).
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Pascal Thubert <[email-masked]>
Date: Sat, 6 Apr 2019 13:21:02 +0200

In short: The objective is to provide a version of ND that is adapted to the type of link. 

The problems: you are voicing two misconceptions and we need to fix that.

1)  The fact is that the original IPv6 ND RFCs depend on a reliable multicast below. A BSS is at least an attempt to provide that, but by definition OCB doesn’t have it. So OCB is explicitly not in scope for RFC4861, which is the wrong tool for you. IOW, Using RFC 4861/2 on OCB is like using a hammer to punch a screw. It is a misunderstanding of the nature of the screw and of the function of a hammer. If you punch hard enough it may seem to work.

2)  Spreading the idea that RFC 8505 is limited to WPAN is an alternative truth that can be damaging to the work by your peers. Please stop doing that. RFC 8505 is not designed exclusively for WPANs. Even the original 6LoWPAN ND was not. RFC 8505 is the result of 6lo which operates on all sorts of MAC/PHYs. IEEE 802.11 was clearly in scope for the design. Some key design points relate to the type of connectivity that we can expect from the radio link: non transitive (NBMA) and intermittent. My understanding is that OCB shares those properties and I see that RFC 8505 is perfectly appropriate there. It even provides you with a way to build subnets of global and ULAs. IOW The IETF just produced a screwdriver and it’s time to raise awareness about it. The concept of a screw is not dependent on the type of wood but it is radically different from that of a nail. 

Bottom line OCB should RECOMMEND using RFC 8505. It came out just in time for this spec, a piece of luck if you ask me...

Cheers,

Pascal

> Le 6 avr. 2019 à 10:25, Abdussalam Baryun <[email-masked]> a écrit :
> 
> I agree with you Alex, I add we need to focus this work with its objectives, and I am not sure what is the objective of using rfc8505 here.
> 
> AB
> 
>> On Fri, Apr 5, 2019 at 9:05 PM Alexandre Petrescu <[email-masked]> wrote:
>> Pascal,
>> 
>> I understand RFC 8505 is applicable on links on which 802.15.4 headers are used (not 802.11).
>> 
>> In IPv6-over-OCB only the 802.11 headers are used and there are some particular values in some of its fields that must be used (e.g. the Traffic Identifier subfield of the QoS control field).
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 6 Apr 2019 14:59:07 +0000

The focus of this document is about transmission of IPv6 packets over 802.11-OCB links. We had extensive amount of discussions and we agreed to keep ND support out of scope for this document, and that separate document will address those ND issues. Any discussions around ND in this document will be limited to issue identification and not about solutions. That was the agreement in the WG and so I am failing to understand why we are departing from that and bringing RFC 8505 discussions into this  and post IETF last call.

Sri

On Apr 6, 2019, at 1:25 AM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

AB

On Fri, Apr 5, 2019 at 9:05 PM Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Pascal,

Alex

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its
_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 17:28:30 +0200

On Apr 6, 2019, at 16:59, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> The focus of this document is about transmission of IPv6 packets over 802.11-OCB links.

RFC 4861 says:

   Unless specified otherwise (in a document that covers operating IP
   over a particular link type) this document applies to all link types.

So it is the job of an IP-over-foo document to say whether ND-classic applies or a variant form that works better over wireless.

> We had extensive amount of discussions and we agreed to keep ND support out of scope for this document, and that separate document will address those ND issues.

You can do that, but RFC 4861 does not leave you the option of not addressing the issue of whether ND-classic applies unchanged.

> Any discussions around ND in this document will be limited to issue identification and not about solutions. That was the agreement in the WG and so I am failing to understand why we are departing from that and bringing RFC 8505 discussions into this  and post IETF last call.

Maybe that consensus was reached without a close reading of RFC 4861?

Grüße, Carsten

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 6 Apr 2019 08:42:45 -0700

Hello Carsten,

RFC 4861 was completed long before the IETF and IESG had a more complete 
understanding of the issues surrounding wireless multicast. Pascal is 
correct that RFC 8505 is not intended to be restricted to WPAN or WiFi.  
And it would be wrong to require, for each type "foo" of wireless 
medium, a separate "ND-over-foo" document, when the issues are general 
to wireless and not specific to "foo".

I hope that anyone reading this thread would also consider reading 
[draft-ietf-mboned-ieee802-mcast-problems] which is heading for WG Last 
Call soon.

Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 6 Apr 2019 16:08:10 +0000

Hello Charlie,

If I may comment on this thread.

I do not want to blindly assume that RFC 8505 was designed for vehicular
environments and that all the properties of low-power lossy networks are
the only relevant attributes of a vehicular network. While the ideas in
RFC 8505 may be applicable here, I do not think its a good idea to
mandate/recommend RFC 8505 as the solution for this work, without
establishing that. 

There are two issues here. This is a procedural aspect here where we
clearly decided not to bring ND solutions into this draft and we are doing
that now after post IETC LC, which I strongly object. The other thing is
lack of technical analysis before we insist that 8505 must be applied for
IPWAVE environments. While, I do agree with you, we should refrain from
designing new protocols for every variant of wireless networks, but its
also incorrect to take the view of using a single hammer for everything.

Sri

On 4/6/19, 8:42 AM, "its on behalf of Charlie Perkins"
<[email-masked] on behalf of [email-masked]> wrote:

>> So it is the job of an IP-over-foo document to say whether ND-classic
>>applies or a variant form that works better over wireless.
>>
>>> We had extensive amount of discussions and we agreed to keep ND
>>>support out of scope for this document, and that separate document will
>>>address those ND issues.
>> You can do that, but RFC 4861 does not leave you the option of not
>>addressing the issue of whether ND-classic applies unchanged.
>>
>>> Any discussions around ND in this document will be limited to issue
>>>identification and not about solutions. That was the agreement in the
>>>WG and so I am failing to understand why we are departing from that and
>>>bringing RFC 8505 discussions into this  and post IETF last call.

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 6 Apr 2019 09:19:36 -0700

Hello Sri,

I didn't read the draft in question, and I should have been clear that I 
was responding to a suggestion about "ND-over-foo" documents without 
specific reference to vehicular 802.11 OCB. Thanks for pointing out the 
procedural problem.

If it was decided to avoid the inclusion of ND solutions in that draft, 
then you are right that RFC 8505 should not be specified as a solution 
in that draft.   In particular for vehicular, some timing analysis is 
needed.

I don't often get to write sentences that rhyme so well.  Maybe I'll 
write a song.

Regards,
Charlie P.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 18:28:37 +0200

Hi Charlie,

> On Apr 6, 2019, at 17:42, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Carsten,
> 
> RFC 4861 was completed long before the IETF and IESG had a more complete understanding of the issues surrounding wireless multicast.

Yes, but its designers, who considered ND to be universally applicable to IPv6, did have the foresight to leave each IP-over-foo document leeway to deviate from the original form that I call ND-classic.  So that leeway is what we are using when making use of RFC 6775/8505.  It just has to be called out in each IP-over-foo needing those deviations.  An IP-over-foo document cannot not decide; if it doesn’t address ND, it opts for ND-classic.

> Pascal is correct that RFC 8505 is not intended to be restricted to WPAN or WiFi.  And it would be wrong to require, for each type “foo" of wireless medium, a separate "ND-over-foo" document, when the issues are general to wireless and not specific to "foo".

I do not have an opinion at this point whether OCB needs any further tweaks beyond those of RFC 6775/8505, but it certainly fits any link better than ND-classic that has non-trivial packet loss rates and reachability issues, in particular for multicast.

> I hope that anyone reading this thread would also consider reading [draft-ietf-mboned-ieee802-mcast-problems] which is heading for WG Last Call soon.

Absolutely.

Grüße, Carsten

---

From: Nabil Benamar <[email-masked]>
Date: Sat, 6 Apr 2019 17:28:39 +0100

+1 Sri

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Sat, Apr 6, 2019 at 3:59 PM Sri Gundavelli (sgundave) <[email-masked]>
wrote:

> The focus of this document is about transmission of IPv6 packets over
> 802.11-OCB links. We had extensive amount of discussions and we agreed to
> keep ND support out of scope for this document, and that separate document
> will address those ND issues. Any discussions around ND in this document
> will be limited to issue identification and not about solutions. That was
> the agreement in the WG and so I am failing to understand why we are
> departing from that and bringing RFC 8505 discussions into this  and post
> IETF last call.
>
> Sri
>
>
> On Apr 6, 2019, at 1:25 AM, Abdussalam Baryun <[email-masked]>
> wrote:
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 6 Apr 2019 23:35:37 +0200

I only support having another draft discussing IP over low power
wireless subnets for ITS, and I think low power communication is in
minority of the ITS communications (IEEE802.11p is majority).

comments below,

> correct that RFC 8505 is not intended to be restricted to WPAN or WiFi.

I read the RFC8505 again and noticed that it objective is only of 6LoWPAN
Neighbor Discovery, so it is only for LLN networks as it is only for
WIRELESS NETWORKS that are LOW POWER. Our work is about High power not low,
and not short ranges discovery.

RFC8505 is not for WiFi nor is it for our draft, actually WiFi is IEEE x.11
technology and our work as well but the 8505 is for IEEE x.15 and they
technologies are far different.

RFC8505 is for low power wireless communication inside the Vehicle, but we
are discussing communication I our draft communication outside the Vehicle,
so having a separate draft is best for outside. You and Pascal have
authored RFC8508 but it is focused on Low power networks not other
wireless. Even if it may be written by authors in a general consideration,
but it was not examined for all wireless networks by IESG. So why we delay
this draft so we can update such unrelated RFC that is for LOWPAN
discovery and LLN networks.

AB

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 23:44:13 +0200

On Apr 6, 2019, at 23:35, Abdussalam Baryun <[email-masked]> wrote:
> 
> RFC8505 is for low power wireless communication

That’s what it says on the label, but that label is there for historical reasons and actually is not true.
I’ve told the authors of this and related drafts repeatedly, but the term “LLN” doesn’t want to get fixed even though it is entirely misleading.

(Again, I’m not taking a position here on whether RFC 6775/8505 can or should be used for OCB.  Just trying to correct some misconceptions.)

Grüße, Carsten

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 6 Apr 2019 23:51:20 +0200

> reasons and actually is not true.

things usually are examined by the labels and headers in technologies and
in human life/work,  so IESG has examined it as it is described, so if it
is not true, then the authors need to update RFC8505 or even IESG need to
contact the IETF Area director and he/she SHOULD do their work to correct
wrong labels that mislead engineers.

> I’ve told the authors of this and related drafts repeatedly, but the term
> “LLN” doesn’t want to get fixed even though it is entirely misleading.
>

Thanks for your clarification but there is a possibility that the IETF WG
responsible of such RFC don't agree with you,

>
> (Again, I’m not taking a position here on whether RFC 6775/8505 can or
> should be used for OCB.  Just trying to correct some misconceptions.)
>

ok thanks

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 7 Apr 2019 00:13:51 +0200

> mandate/recommend RFC 8505 as the solution for this work, without

I agree that we in IPWAVE should not recommend RFC8505 of low power subnet
of IEEE802.15.

> IPWAVE environments.

The RFC8505 is not related to our work only if IPWAVE WG agrees to adopt it
into our work. We in IPWAVE WG can examine it and discuss it another time
and we can discuss with the authors/other_WG and examine that RFC in ITS
environment. Participants of WGs outside  IPWAVE should not delay our work
just to consider other WG RFCs which may be labelled wrongly or maybe
examined wrongly.

> While, I do agree with you, we should refrain from

In my opinion we need to design new ITS protocols per this WG (under the
charter), not per variant networks. In IETF any WG can from the beginning
consider some RFCs and ignore others while designing their work.  It is the
way we work in IETF to focus our work in groups, and if any author/WG which
owns an RFC wants to make such protocol used by such WG then it needs to be
examined and discussed by the WG if they want/agree.

AB

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 7 Apr 2019 17:59:10 +0800

Hello Sri 

The reason is that I was asked to review the document for int dir and that is not a intra WG activity. Actually I was not aware of what you’re indicating. 

If the scope excludes ND then the first thing is to say so explicitly in the introduction, which the current version doesn’t. 

The reading of the current version is that classical ND is to be used, and doesn’t document where it falls short. I object to that. 

I understand RFC 8505 quite well and see an excellent fit with OCB. I fail to see why we would not mention it and object to the publication of a spec that would just indicate a much less suited version of ND.

I was ask to suggest text and just did that, cc the ML. Can we review that text? Maybe a consensus can be built rapidly on that basis...

All the best,

Pascal

> Le 6 avr. 2019 à 22:59, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> On Apr 6, 2019, at 1:25 AM, Abdussalam Baryun <[email-masked]> wrote:
>

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 7 Apr 2019 18:10:31 +0800

I agree with Carsten and Charlie.

I have to add that due to the lack of a multicast emulation (which is an AP function) OCB is in fact a much worse case for RFC 4861 than BSS is. This could be an interesting new section to the mboned draft.

The cool part is that a group next door has been looking at that problem for roughly a decade and actually solved it. 

Now if IPWave publishes this RFC, we can hope that other SDOs will consider the document as a reference. Due to that visibility, it is not acceptable that we fail to expose the problem and its solution as they exist today.

It is also unreasonable to only present a version of ND that was designed before Wi-Fi even existed and for which NBMA is ATM or Frame Relay...

All the best,

Pascal

> Le 6 avr. 2019 à 23:42, Charlie Perkins <[email-masked]> a écrit :
> 
> Hello Carsten,
> 
> RFC 4861 was completed long before the IETF and IESG had a more complete understanding of the issues surrounding wireless multicast. Pascal is correct that RFC 8505 is not intended to be restricted to WPAN or WiFi.  And it would be wrong to require, for each type "foo" of wireless medium, a separate "ND-over-foo" document, when the issues are general to wireless and not specific to "foo".
>

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 7 Apr 2019 18:19:02 +0800

Then let’s not use an old hammer when screws have replaced nails!

I understand the piece where you claim that the group did not get a chance to evaluate RFC 8505 on OCB. 

The group may not yet fully understand why RFC 8505 is suitable for the job but at least we all understand that RFC 4861 is not, based on the own words in the RFC. 

You may decide not to mention ND at all. But what’s left in the spec? 

Pascal

> Le 7 avr. 2019 à 00:08, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> Hello Charlie,
>

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 7 Apr 2019 18:38:08 +0800

Hi Abdussalam,

The discussion is not about low power. It is about the type of connectivity. Who can reach whom and when. Please keep Low-Power out of the discussion, it can get people confused.

Cheers,

Pascal

> Le 7 avr. 2019 à 05:35, Abdussalam Baryun <[email-masked]> a écrit :
> 
> 
> 
> I only support having another draft discussing IP over low power wireless subnets for ITS, and I think low power communication is in minority of the ITS communications (IEEE802.11p is majority).
> 
> comments below,
> 
>> On Sat, Apr 6, 2019 at 5:43 PM Charlie Perkins <[email-masked]> wrote:
>> Hello Carsten,
>> 
> I read the RFC8505 again and noticed that it objective is only of 6LoWPAN Neighbor Discovery, so it is only for LLN networks as it is only for WIRELESS NETWORKS that are LOW POWER. Our work is about High power not low, and not short ranges discovery.
> 
> RFC8505 is not for WiFi nor is it for our draft, actually WiFi is IEEE x.11 technology and our work as well but the 8505 is for IEEE x.15 and they technologies are far different.
> 
> RFC8505 is for low power wireless communication inside the Vehicle, but we are discussing communication I our draft communication outside the Vehicle, so having a separate draft is best for outside. You and Pascal have authored RFC8508 but it is focused on Low power networks not other wireless. Even if it may be written by authors in a general consideration, but it was not examined for all wireless networks by IESG. So why we delay this draft so we can update such unrelated RFC that is for LOWPAN discovery and LLN networks.
> 
> AB
> 
> 
> 
>

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 7 Apr 2019 19:20:21 +0800

Hello Carsten 

I’m now presenting the suite as WiND (for wireless ND) to get rid of the misconception you’re rightfully pointing out here.

Arguably the coverage extends outside of wireless; e.g., powerline has similar transient and non transitive reachability. And satellites that are wireless are yet a very different beast.

Still wireless carries an intuition that is more proper than 6LoWPAN or LLN to characterize the type of connectivity that we are addressing.

All the best,

Pascal

> Le 7 avr. 2019 à 05:44, Carsten Bormann <[email-masked]> a écrit :
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 7 Apr 2019 18:23:03 +0200

Hi Pascal,

I think your recommendation of RFC8505 made me and authors confused, I just
replied to Alex messages, so please don't make things out of discussion, I
know what to discuss and what to not.

AB

On Sun, Apr 7, 2019 at 12:38 PM Pascal Thubert <[email-masked]>
wrote:

> Hi Abdussalam,
>
> The discussion is not about low power. It is about the type of
> connectivity. Who can reach whom and when. Please keep Low-Power out of the
> discussion, it can get people confused.
>
> Cheers,
>
> Pascal
>
> RFC8505 is not for WiFi nor is it for our draft, actually WiFi is IEEE
> x.11 technology and our work as well but the 8505 is for IEEE x.15 and they

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 7 Apr 2019 19:14:28 +0200

Le 07/04/2019 à 12:10, Pascal Thubert a écrit :
> I have to add that due to the lack of a multicast emulation (which is
> an AP function) OCB is in fact a much worse case for RFC 4861 than
> BSS is. This could be an interesting new section to the mboned
> draft.

Pascal - multicast at IP layer works ok on OCB links.  Sending RSs, NSs, 
RSs an RAs on IP multicast groups, and their mapping on link-layer 
multicast groups - works fine - in V2V mode (no IP-RSU) and in V2I mode 
(with an IP-RSU present).  We use it extensively in both ways.

I do not understand what do you mean by multicast emulation.

I suspect the follozing: in many cases where the link-layer does not 
provide proper link-layer multicast function (e.g. link-layer subscribe 
operations, or fine-grained groups such as 'all-hosts'), the IP layer 
uses filters to replace subscribe operations, and mappings between 
fined-grained groups and all-encompassing groups (e.g. both all-hosts 
and all-routers groups are mapped into a single value 'everyone').

This kind of implementation is not specific to presence or absence of 
Access Point.

This kind of implementation exists everywhere where IPv6 needs multicast 
support and the link-layer does not provide.

The specification of this link-layer multicast behavior does not exist: 
neither IEEE documents dont describe, nor IETF documents.

This behaviour is not specific to OCB.

Is this what you call 'multicast emulation'?

> 
> The cool part is that a group next door has been looking at that
> problem for roughly a decade and actually solved it.

Implementation of RFC8505 with 802.11 headers please?

The IPv6-over-OCB document is implemented.  Adding RFC8505 would only 
draw it back.

> Now if IPWave publishes this RFC, we can hope that other SDOs will
> consider the document as a reference. Due to that visibility, it is
> not acceptable that we fail to expose the problem and its solution as
> they exist today.
> 
> It is also unreasonable to only present a version of ND that was
> designed before Wi-Fi even existed and for which NBMA is ATM or Frame
> Relay...

In a sense yes, but it is not in the OCB document to solve multicast 
problems.

Alex

> 
> All the best,
> 
> Pascal
> 
>> Le 6 avr. 2019 à 23:42, Charlie Perkins
>> <[email-masked]> a écrit :
>> 
>> Hello Carsten,
>> 
>> RFC 4861 was completed long before the IETF and IESG had a more
>> complete understanding of the issues surrounding wireless
>> multicast. Pascal is correct that RFC 8505 is not intended to be
>> restricted to WPAN or WiFi.  And it would be wrong to require, for
>> each type "foo" of wireless medium, a separate "ND-over-foo"
>> document, when the issues are general to wireless and not specific
>> to "foo".
>> 
>> [draft-ietf-mboned-ieee802-mcast-problems] which is heading for WG
>> Last Call soon.
>> 
>> Regards, Charlie P.
>> 
>> 
>>> Unless specified otherwise (in a document that covers operating
>>> IP over a particular link type) this document applies to all link
>>> types.
>>> 
>>> So it is the job of an IP-over-foo document to say whether
>>> ND-classic applies or a variant form that works better over
>>> wireless.
>>> 
>>>> support out of scope for this document, and that separate
>>>> document will address those ND issues.
>>> You can do that, but RFC 4861 does not leave you the option of
>>> not addressing the issue of whether ND-classic applies
>>> unchanged.
>>> 
>>>> Any discussions around ND in this document will be limited to
>>>> issue identification and not about solutions. That was the
>>>> agreement in the WG and so I am failing to understand why we
>>>> are departing from that and bringing RFC 8505 discussions into
>>>> this  and post IETF last call.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 7 Apr 2019 19:22:00 +0200

> You may decide not to mention ND at all. But what’s left in the spec?

We do mention ND: it is said: ND works fine on OCB.

We did struggle a lot with text about ND with participants in 6MAN.

What's left in the spec: in the spec we say how IPv6 runs on OCB.  ND 
works fine on OCB.   It is a typical IPv6-over-foo document.  It 
specifies some fields containing the EtherType, something about QoS, and 
some new way about Interface Ientifiers in accordance to 6MAN WG.  And, 
because it does not exist elsewhere yet it is implemented: it specifies 
how to transform 802.11 headers into Ethernet II headers (IPv6 only 
knows Ethernet II headers) - this is the Ethernet Adaptation Layer.

This is completely different than what IPv6-over-802154 does: 6lowpan 
adaptation layer, 802.15.4 headers, RFC8505 for address registration, 
and so on.

One may want to consider a merge OCB-802154, but that has to do with 
IEEE: can IEEE use just one kind of header for both WPAN and WLAN? 
(currently IEEE uses 802.11 headers for WLAN and 802.15.4 headers for WPAN).

Recommending RFC8505 for OCB has so many implications that I am afraid 
are not considered.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 7 Apr 2019 19:22:46 +0200

Pascal - Low power Low bandwidth is in the name of 6LoWPAN and 6lo

Le 07/04/2019 à 12:38, Pascal Thubert a écrit :
> connectivity. Who can reach whom and when. Please keep Low-Power out of 
> the discussion, it can get people confused.
> 
> Cheers,
> 
> Pascal
> 
> Le 7 avr. 2019 à 05:35, Abdussalam Baryun <[email-masked] 
> <mailto:[email-masked]>> a écrit :
> 
>>
>>
>> On Sat, Apr 6, 2019 at 5:43 PM Charlie Perkins 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>>     Hello Carsten,
>>
>>     complete
>> I read the RFC8505 again and noticed that it objective is only of 
>> 6LoWPAN Neighbor Discovery, so it is only for LLN networks as it is 
>> only for WIRELESS NETWORKS that are LOW POWER. Our work is about High 
>> power not low, and not short ranges discovery.
>>
>> x.11 technology and our work as well but the 8505 is for IEEE x.15 and 
>> they technologies are far different.
>>
>> RFC8505 is for low power wireless communication inside the Vehicle, 
>> but we are discussing communication I our draft communication outside 
>> the Vehicle, so having a separate draft is best for outside. You and 
>> Pascal have authored RFC8508 but it is focused on Low power networks 
>> not other wireless. Even if it may be written by authors in a general 
>> consideration, but it was not examined for all wireless networks by 
>> IESG. So why we delay this draft so we can update such unrelated RFC 
>> that is for LOWPAN discovery and LLN networks.
>>
>> AB
>>
>>
>>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 7 Apr 2019 19:27:10 +0200

Le 07/04/2019 à 13:20, Pascal Thubert a écrit :
> Hello Carsten
> 
> I’m now presenting the suite as WiND (for wireless ND) to get rid of
> the misconception you’re rightfully pointing out here.
> 
> Arguably the coverage extends outside of wireless; e.g., powerline
> has similar transient and non transitive reachability. And satellites
> that are wireless are yet a very different beast.
> 
> Still wireless carries an intuition that is more proper than 6LoWPAN
> or LLN to characterize the type of connectivity that we are
> addressing.

Pascal - is that an intuition of one particular group of persons, or is 
that intuition something more widely accepted.

In the group where I work, it is considered and practiced that ND works 
ok in this OCB wireless.

(For sake of completess: if I remember correctly, only one very 
knowledgeable person insisted recently about this wireless nature of OCB 
influencing on what the group should do.  There is a long discussion 
about that too, but I suppose you dont know it.  That discussion did 
happen here, and we did conclude and did consensus: the statement is 
that ND does work on OCB).

Alex

>> That’s what it says on the label, but that label is there for
>> historical reasons and actually is not true. I’ve told the authors
>> of this and related drafts repeatedly, but the term “LLN” doesn’t
>> want to get fixed even though it is entirely misleading.
>> 
>> (Again, I’m not taking a position here on whether RFC 6775/8505 can
>> or should be used for OCB.  Just trying to correct some
>> misconceptions.)
>> 
>> Grüße, Carsten
>> 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 7 Apr 2019 17:36:09 +0000

Hi Pascal,

I realize the directorate review is not intended to be a a intra WG review activity, but rather about reviews ensuring consistency across WG’s and elimination of any work overlap. That’s absolutely needed, but at the same time lets ensure these Directorate reviews do not fundamentally alter the shape and structure of the document. A document, say Document-A sent by the WG to IESG, should not get published as Document-B with a totally different structure and incorporating the reviewer’s favorite solutions. ND solutions are out of scope for this document. We can only identify issues, but not solutions.

I do agree with you that a statement explaining the scope would have avoided these discussions. Some thing along the lines would have helped.”

“This document defines the transmission of IPv6 packets over 802.11-OCB links. IPv6 Neighbor Discovery protocol as defined in RFC 4861 is the enabler for IPv6 communications. However, the classical approaches as defined in the base ND specification without optimizations will be in-efficient for IPWAVE based vehicular environments. This document document does not address those ND optimizations, but future work from the IPWAVE working will identify those extensions. Those extensions may leverage published work from other working groups when possible, or in the form of publication of new specifications as needed”.

Sri

From: Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date: Sunday, April 7, 2019 at 2:59 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Abdussalam Baryun <[email-masked]<mailto:[email-masked]>>, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] RFC8505 and 802.11 headers

Hello Sri

All the best,

Pascal

Le 6 avr. 2019 à 22:59, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :

Sri

AB

Pascal,

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 7 Apr 2019 17:38:29 +0000

> The group may not yet fully understand why RFC 8505 is suitable for the job but at least we all understand that RFC 4861 is not, based on the own words in the RFC.

I am fine with the author's assertion that 8505 is a great fit, but the authors have to establish that. I am sympathetic to that view that it can be used, but I cannot take that at its face value.

If I look at RFC 4919 (6LoWPANs: Overview, Assumptions, Problem Statement, and Goals), section 2, where it provides a definition of LoWPAN network, I do not think it includes all the properties of a vehicular network. Vehicular network is about mobility, latency, always-on-connectivity. Latency is one important property which is not even a consideration for low-power devices. The vehicle may be running on a battery, but the stringent low-power constraint may not be applicable for WAVE environments; The compute power available in the vehicle does not put a strict constraints on processing powers, or memory as it does for certain IOT devices.

Therefore, the below text does not make me believe the designers of 6LOWPAN had vehicular networks in mind.  At the same time, I do agree some of the principles may be applicable here and leveraged for IPWAVE, but I cannot agree that this is perfect fit and was designed exactly for this operating environment as I read from this thread.

—————
RFC 4919: Section 2

A LoWPAN is a simple low cost communication network that allows
wireless connectivity in applications with limited power and relaxed
throughput requirements. A LoWPAN typically includes devices that
work together to connect the physical environment to real-world
applications, e.g., wireless sensors. LoWPANs conform to the IEEE
802.15.4-2003 standard [IEEE802.15.4].

Some of the characteristics of LoWPANs are as follows:

1. Small packet size. Given that the maximum physical layer packet
is 127 bytes, the resulting maximum frame size at the media
access control layer is 102 octets. Link-layer security imposes
further overhead, which in the maximum case (21 octets of
overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32
and AES-CCM-64, respectively), leaves 81 octets for data
packets.

2. Support for both 16-bit short or IEEE 64-bit extended media
access control addresses.

3. Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps for
each of the currently defined physical layers (2.4 GHz, 915 MHz,
and 868 MHz, respectively).

4. Topologies include star and mesh operation.

5. Low power. Typically, some or all devices are battery operated.

6. Low cost. These devices are typically associated with sensors,
switches, etc. This drives some of the other characteristics
such as low processing, low memory, etc. Numerical values for
"low" elided on purpose since costs tend to change over time.

7. Large number of devices expected to be deployed during the
lifetime of the technology. This number is expected to dwarf
the number of deployed personal computers, for example.

8. Location of the devices is typically not predefined, as they
tend to be deployed in an ad-hoc fashion. Furthermore,
sometimes the location of these devices may not be easily
accessible. Additionally, these devices may move to new
locations.

9. Devices within LoWPANs tend to be unreliable due to variety of
reasons: uncertain radio connectivity, battery drain, device
lockups, physical tampering, etc.

10. In many environments, devices connected to a LoWPAN may sleep
for long periods of time in order to conserve energy, and are
unable to communicate during these sleep periods.

----------

On 4/7/19, 3:19 AM, "Pascal Thubert" <[email-masked]<mailto:[email-masked]>> wrote:

Pascal

Le 7 avr. 2019 à 00:08, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :
Hello Charlie,
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
    over a particular link type) this document applies to all link

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 8 Apr 2019 03:46:07 +0800

Hello Abdussalam 

I can see from you Alex and Sri why making a RECOMMEND can be premature for the group. OTOH it would make the doc a lot more useful.

Cheers,

Pascal

> Le 8 avr. 2019 à 00:23, Abdussalam Baryun <[email-masked]> a écrit :
> 
> Hi Pascal,
> 
> I think your recommendation of RFC8505 made me and authors confused, I just replied to Alex messages, so please don't make things out of discussion, I know what to discuss and what to not.
> 
> AB
> 
>> On Sun, Apr 7, 2019 at 12:38 PM Pascal Thubert <[email-masked]> wrote:
>> Hi Abdussalam,
>>

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 8 Apr 2019 04:00:16 +0800

Hello Sri

I already suggested to stop confusing RFC 8505 with 6LoWPAN. The RFC has its applicability section which does not limit it to that but rather considers whether multicast is available or not.

Focusing on 6LoWPAN doesn’t help; what helps is understanding the properties of the protocol and the type of connectivity one gets in a vehicle and then consider the matching.

For the rest I mostly agree with you.

All the best,

Pascal

> Le 8 avr. 2019 à 01:38, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> On 4/7/19, 3:19 AM, "Pascal Thubert" <[email-masked]> wrote:
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 7 Apr 2019 20:15:47 +0000

HI Pascal,

Thanks for the clarification on the applicability section of 8505, making it broadly applicable to other environments beyond 6LOWPAN. But, we need to review and decide if such broader applicability can be extended to IPWAVE-based vehicular environments, or we need new extensions matching the properties of vehicular environments. For now, lets try to close the discussion on the current spec, and defer any ND discussions to a a new thread. Thanks!

Sri

From: Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Date: Sunday, April 7, 2019 at 1:00 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Charlie Perkins <[email-masked]<mailto:[email-masked]>>, Carsten Bormann <[email-masked]<mailto:[email-masked]>>, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] RFC8505 and 802.11 headers

Hello Sri

All the best,

Pascal

—————
RFC 4919: Section 2

----------

Pascal

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 8 Apr 2019 04:16:24 +0800

Hello Alexandre;

When should an OCB node do a DAD?
What guarantee do you expect from it?
In particular what set of nodes do you trust will not have a collision?

As I indicated in my review you have to define the link (who is in) and the subnet for link local and global addresses respectively.

Multicast works well for ND if it provides a consistent permanent reliable connectivity between the members of the link/subnet.
When you do not have that you can not claim that multicast works (for ND).

Example: 2 cars form a same link local address when not in range from one another. Is that detected? Then say they meet. Can they talk? What does a RSU do when in range of both?

RFC 8505 takes care of that issue among others. Like the fact that multicast is less reliable than unicast. It has nothing to do with low power and everything to do with the MAC layer and ARQ procedures which are similar in the IEEE protocols we are discussing.

The draft misses explanations on the above and a broad claim that multicast and thus ND just work is not technically correct.

Cheers,

Pascal

> Le 8 avr. 2019 à 04:00, Pascal Thubert <[email-masked]> a écrit :
> 
> Hello Sri
>

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 8 Apr 2019 04:39:02 +0800

Works for me Sri.

I think the thread discussed at length why RFC 4851 is far from perfect and we know circumstances when it will fail because the underlying multicast is missing. This must be clarified in the draft otherwise it will give the wrong impression that we are all set.

Failing to reference RFC 8505 gives the other wrong impression that the IETF is still operating on links from the last century. This is also misleading. 

I provided text as I was asked to about all the above. My text summarizes the issues. This thread went into more details. Do we need that in the draft?

My text recommends to use RFC 8505. If the group needs more work to evaluate that claim then a possible rewording would be to present it as a possibility being studied, work in progress. But ignoring it is another wrong message.

Can you look at the text I posted and suggest amendments?

Pascal

> Le 8 avr. 2019 à 04:15, Sri Gundavelli (sgundave) <[email-masked]> a écrit :
> 
> HI Pascal,
> 
> From: Pascal Thubert <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: Charlie Perkins <[email-masked]>, Carsten Bormann <[email-masked]>, Alexandre Petrescu <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 8 Apr 2019 00:49:01 +0000

Hi Pascal,

I will review the text. But, clearly many folks including me are not comfortable referencing RFC 8505 in this document. I will not agree to referring to 8505 without qualifying its intended scope and before ensuing it meets vehicular requirements.

If we have an agreement on keeping ND out of scope (which I thought we did from your previous mail), then we can only discuss technical issues operating IPv6 on these links with the default baseline ND mechanism, but will be premature to refer to any existing solutions to address those issues. That analysis and optimized ND approaches for 802.11-OCB links should be a separate effort as the WG always believed and we cannot skip that step.

Sri

Date: Sunday, April 7, 2019 at 1:39 PM

Works for me Sri.

Pascal

Le 8 avr. 2019 à 04:15, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> a écrit :

HI Pascal,

Sri

Hello Sri

All the best,

Pascal

—————
RFC 4919: Section 2

----------

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Apr 2019 03:26:31 +0200

On Apr 8, 2019, at 02:49, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> keeping ND out of scope

Broken record mode: You cannot really do that in an IP-over-foo document, as ND-classic then applies automatically.  (Actually, you even do say quite explicitly that ND-classic applies, so ND already is in scope in the current text of the document.  That of course could be changed, except that in effect it can’t because of the above.)

Grüße, Carsten

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 8 Apr 2019 09:39:53 +0800

Hello Alexandre

About broadcast emulation in a BSS:
The AP creates a broadcast domain of all the nodes that are associated to
it. That way you have a closure that you can call a link from which you can
derive a clear determination on who is on link.
The point of a BSS is that the AP can reach every associated nodes, though
individual nodes associated to the AP may or may not be able to reach one
another directly. This is what what we mean by non-transitive link
properties.
To enable IP, the AP *emulates* the Ethernet broadcast the following way: a
node sends the broadcast packet unicast to the AP and then the AP
broadcasts it to all associated nodes, based on the assumption that all
nodes associated will get it. To optimize the chances that all associated
nodes receive it, the broadcast message is sent at the slowest speed and
high energy level, which in turn is broadcast it is detrimental to unicast,
both in terms of bandwidth and interference.
Approximately anyone on link will thus get the broadcast that transports a
multicast. But since there is no ARQ on a broadcast, there are still nodes
which will not get it. This is one of the reasons why DAD by RFC 4861
already fails to discover some address duplication, even on a BSS or an ESS.
All the above is why we are  promoting RFC 8505 on Wi-Fi independently of
the discussion here.

About RFC 8505 over 802.11:
RFC 8505 is a pure Layer 3 protocol. It extends the NS/NA with options and
uses less multicast. It is encapsulated on Wi-Fi through the same code path
as IPv6 ND. The RFC does not specify anything about that why should it?
Bottom line is that it just works.

About OCB and multicast
The IPv6 over OCB document does not have to resolve the multicast problem
but it cannot rely on a service that is not there. IPv6 ND uses multicast
for DAD and AR. RFC 8505 solves the DAD and avoids the AR question by
saying that the prefix is not on link. I believe that RFC 8505 is good
enough for IPWave for DAD. I have in mind that for rapid movements, AR
could be completely avoided by just using MAC level broadcast for all
packets, but that requires more ML discussion.

About low Power
What do you mean by high power? do you need to start the engine before
using OCB?
Isn't there use cases where a vehicle will upload diagnostics while parked
at night? Even devices connected on mains have green options these days.
Even Ethernet. But then again, the low power benefits of RFC 8505 are not
limiting its applicability on OCB and not a reason to dismiss it.

About link scope:
RFC 8505 solves the problem of the link scope for link local uniqueness
determination. Your draft fails to even recognize the problem. Like I said
above, the closure is determined on a BSS by the set of associated nodes
and we can run DAD on that. ESS extends that but the bottom line is the
same. You have a closure that you can call a link, and every broadcast over
that closure is received by everyone so you can d DAD. What is your closure?
If you do not recommend RFC 8505 which IMHO was the simple thing to do,
then you have to take the more complex path of documenting the problem and
proposing a solution that extends RFC 4861. You need to document what your
concept of a link is. My proposed text has an escape by which an
implementation that has only IPv6 ND is acceptable but MUST have an
external technique for DAD, since IPv6 ND will not do that for you.

cheers

Pascal

-- 
Pascal

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 8 Apr 2019 09:55:10 +0800

+ONE

note that if we really take ND off then the resulting document would be
rather empty. Which raises the question of the value of publishing it.
Which would be my next question.

- The discussion on MAC to MAC translation is irrelevant since it is pure
IEEE games that have been there since the inception of 802.11 .
- The document fails to provide a concept of a link and a concept of a
subnet. It doesn't enable Global and ULA. It doesn't provide access to the
internet.
- DAD will work if the parties are in range at the time of DAD and the
packet is not lost in flight. What are the chances for that?
- AR will work if the parties are in range at the time of lookup, including
say 3 retries. What if the destination arrives 2 seconds too late?

And on and on. Which makes endorsing RFC 8505 the easy, easy path. Or
reinvent a wheel which took us almost 10 years to finalize. I'm not saying
that RFC 8505 does it all. Like I said it cares mostly about DAD and IPWave
might want to revisit AR for a number of good reasons which includes
extremely short time of sight and link relaying through the infrastructure.

Note that there are pieces that I really liked as a reviewer, but they are
in appendix.

cheers,

Pascal

Le lun. 8 avr. 2019 à 09:26, Carsten Bormann <[email-masked]> a écrit :

> Broken record mode: You cannot really do that in an IP-over-foo document,
> as ND-classic then applies automatically.  (Actually, you even do say quite
> explicitly that ND-classic applies, so ND already is in scope in the
> current text of the document.  That of course could be changed, except that
> in effect it can’t because of the above.)
>
> Grüße, Carsten
>
>

-- 
Pascal

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 8 Apr 2019 04:15:29 +0000

Sure, IPv6 ND should apply by default and the additional text which
identifies the issues operating in classic ND mode will provide enough
hints. As long as the spec clearly states that there will be future work
from the WG that addresses the ND issue, it should do it.

We cannot just keep insisting that RFC 8505 is the silver bullet and will
address all issues and that it is the solution for IPv6 WAVE networks. Its
indeed a broken record mode, but such applicability needs to be
established. We cannot take a document designed in 6LOWPAN group, for
certain type of environment, which had zero considerations for
802.11-OCB/vehicular networks, and keep arguing that it is the solution
for IPWAVE environments.

Authors can claim any thing, but we don¹t have to agree to it. There is no
text in either the Applicability section or in other sections which makes
be believe that 802.11-OCB based vehicular networks was a consideration
for RFC 8505, or that it can support any type of link. Vehicular networks
have different properties and the considerations are different, lets not
trivialize that.

In the absence of any proper analysis, we cannot force this on the WG.
Again, the discussion on ND optimizations for IPWave environments is a new
effort and in that we will consider RFC 8505 approaches, along with other
approaches, but it cannot be addressed in this spec.

Sri

On 4/7/19, 6:26 PM, "Carsten Bormann" <[email-masked]> wrote:

>as ND-classic then applies automatically.  (Actually, you even do say
>quite explicitly that ND-classic applies, so ND already is in scope in
>the current text of the document.  That of course could be changed,
>except that in effect it can¹t because of the above.)
>
>Grüße, Carsten
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 10:51:49 +0200

> When should an OCB node do a DAD?

When it assigns a new address of its interface.

> What guarantee do you expect from it?

In the context we currently deploy (V2V), the guarantee is from DAD and
from the MAC address.

> In particular what set of nodes do you trust will not have a

A small set of nodes: it is less than 10 nodes in an area of around 100
meters radius.

> As I indicated in my review you have to define the link (who is in)
> and the subnet for link local and global addresses respectively.

The link is defined by also by a frequency.  That is a very strong and
distinguishing linker.  In OCB there are 5 frequencies possible.  For
each of the subnets between the cars we define dynamically which
frequency to be used.

With this set of distinct frequencies (channels), there is less risks of
hearing or talking to somebody not concerned.

> Multicast works well for ND if it provides a consistent permanent 
> reliable connectivity between the members of the link/subnet. When
> you do not have that you can not claim that multicast works (for
> ND).

I agree.

> Example: 2 cars form a same link local address when not in range from
>  one another. Is that detected? Then say they meet. Can they talk?

Yes, it is a good example.

But it (cars moving from out of range to in range) is akin to me
disconnecting an Ethernet plug and inserting it where I am not supposed
to.  Suddenly the DAD initially failing (no duplicates) should be
triggered and succeed (find duplicates).   That triggering is done with
ND timers - not sure which ones, maybe you tell me which ones.

> What does a RSU do when in range of both?

I deployed a couple of IP-RSUs on route following the normal IPv6 ND and 
DAD design.  I used one or two cars at various speeds.  Things work 
well: from IPv6 SLAAC, to Mobile IPv6, youtube IPv6 and more.

Cars dont come in and out of coverage in a completely arbitrary manner. 
  They dont follow trajectories like molecules in Brownian movement. 
Cars follow very constrained paths.  During that, there is plenty of 
time for software to test coverage availability and decide where to connect.

There are some problems in this dynamicity - yes, but too few from 
multicast problems.

One thing I have yet to try is two cars in opposite direction at 110km/h 
under one IP-RSU.  The deployment is there, the road accepts it.  But 
there is need of time to test.

That may tell which are the problems.

> RFC 8505 takes care of that issue among others. Like the fact that 
> multicast is less reliable than unicast. It has nothing to do with
> low power and everything to do with the MAC layer and ARQ procedures
> which are similar in the IEEE protocols we are discussing.

I dont understand what do you mean by 'multicast is reliable than unicast'?

> The draft misses explanations on the above and a broad claim that 
> multicast and thus ND just work is not technically correct.

Have you tried your claims with cars on roads?

Alex

> 
> Cheers,
> 
> Pascal
> 
> Le 8 avr. 2019 à 04:00, Pascal Thubert <[email-masked] 
> <mailto:[email-masked]>> a écrit :
> 
>> Hello Sri
>> 
>> I already suggested to stop confusing RFC 8505 with 6LoWPAN. The
>> RFC has its applicability section which does not limit it to that
>> but rather considers whether multicast is available or not.
>> 
>> Focusing on 6LoWPAN doesn’t help; what helps is understanding the 
>> properties of the protocol and the type of connectivity one gets in
>> a vehicle and then consider the matching.
>> 
>> Le 8 avr. 2019 à 01:38, Sri Gundavelli (sgundave)
>> <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>>>> The group may not yet fully understand why RFC 8505 is suitable
>>>> for
>>> the job but at least we all understand that RFC 4861 is not,
>>> based on the own words in the RFC.
>>> 
>>> I am fine with the author's assertion that 8505 is a great fit,
>>> but the authors have to establish that. I am sympathetic to that
>>> view that it can be used, but I cannot take that at its face
>>> value.
>>> 
>>> If I look at RFC 4919 (6LoWPANs: Overview, Assumptions, Problem 
>>> Statement, and Goals), section 2, where it provides a definition
>>> of LoWPAN network, I do not think it includes all the properties
>>> of a vehicular network. Vehicular network is about mobility,
>>> latency, always-on-connectivity. Latency is one important
>>> property which is not even a consideration for low-power devices.
>>> The vehicle may be running on a battery, but the stringent
>>> low-power constraint may not be applicable for WAVE environments;
>>> The compute power available in the vehicle does not put a strict
>>> constraints on processing powers, or memory as it does for
>>> certain IOT devices.
>>> 
>>> Therefore, the below text does not make me believe the designers
>>> of 6LOWPAN had vehicular networks in mind.  At the same time, I
>>> do agree some of the principles may be applicable here and
>>> leveraged for IPWAVE, but I cannot agree that this is perfect fit
>>> and was designed exactly for this operating environment as I read
>>> from this thread.
>>> 
>>> 
>>> ————— RFC 4919: Section 2
>>> 
>>> wireless connectivity in applications with limited power and
>>> relaxed throughput requirements. A LoWPAN typically includes
>>> devices that work together to connect the physical environment to
>>> real-world applications, e.g., wireless sensors. LoWPANs conform
>>> to the IEEE 802.15.4-2003 standard [IEEE802.15.4].
>>> 
>>> 1.Small packet size. Given that the maximum physical layer
>>> packet is 127 bytes, the resulting maximum frame size at the
>>> media access control layer is 102 octets. Link-layer security
>>> imposes further overhead, which in the maximum case (21 octets
>>> of overhead in the AES-CCM-128 case, versus 9 and 13 for
>>> AES-CCM-32 and AES-CCM-64, respectively), leaves 81 octets for
>>> data packets.
>>> 
>>> 3. Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps
>>> for each of the currently defined physical layers (2.4 GHz, 915
>>> MHz, and 868 MHz, respectively).
>>> 
>>> 6. Low cost. These devices are typically associated with
>>> sensors, switches, etc. This drives some of the other
>>> characteristics such as low processing, low memory, etc.
>>> Numerical values for "low" elided on purpose since costs tend to
>>> change over time.
>>> 
>>> lifetime of the technology. This number is expected to dwarf the
>>> number of deployed personal computers, for example.
>>> 
>>> tend to be deployed in an ad-hoc fashion. Furthermore, sometimes
>>> the location of these devices may not be easily accessible.
>>> Additionally, these devices may move to new locations.
>>> 
>>> 9. Devices within LoWPANs tend to be unreliable due to variety
>>> of reasons: uncertain radio connectivity, battery drain, device 
>>> 10. In many environments, devices connected to a LoWPAN may
>>> sleep for long periods of time in order to conserve energy, and
>>> are unable to communicate during these sleep periods.
>>> 
>>> ----------
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 4/7/19, 3:19 AM, "Pascal Thubert" <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>> 
>>> I understand the piece where you claim that the group did not
>>> get a chance to evaluate RFC 8505 on OCB.
>>> 
>>> The group may not yet fully understand why RFC 8505 is suitable 
>>> for the job but at least we all understand that RFC 4861 is not, 
>>> based on the own words in the RFC.
>>> 
>>> Le 7 avr. 2019 à 00:08, Sri Gundavelli (sgundave) 
>>> <[email-masked] <mailto:[email-masked]>> a écrit : Hello
>>> Charlie, If I may comment on this thread. I do not want to
>>> blindly assume that RFC 8505 was designed for vehicular 
>>> environments and that all the properties of low-power lossy 
>>> networks are the only relevant attributes of a vehicular network.
>>> While the ideas in RFC 8505 may be applicable here, I do not
>>> think its a good idea to mandate/recommend RFC 8505 as the
>>> solution for this work, without establishing that. There are two
>>> issues here. This is a procedural aspect here where we clearly
>>> decided not to bring ND solutions into this draft and we are
>>> doing that now after post IETC LC, which I strongly object. The 
>>> other thing is lack of technical analysis before we insist that
>>> 8505 must be applied for IPWAVE environments. While, I do agree
>>> with you, we should refrain from designing new protocols for
>>> every variant of wireless networks, but its also incorrect to
>>> take the view of using a single hammer for everything. Sri On
>>> 4/6/19, 8:42 AM, "its on behalf of Charlie Perkins" 
>>> <[email-masked] <mailto:[email-masked]> on behalf of
>>> [email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Carsten, RFC 4861 was completed long before the IETF and
>>> IESG had a more complete understanding of the issues surrounding
>>> wireless multicast. Pascal is correct that RFC 8505 is not
>>> intended to be restricted to WPAN or WiFi. And it would be wrong
>>> to require, for each type "foo" of wireless medium, a separate
>>> "ND-over-foo" document, when the issues are general to wireless
>>> and not specific to "foo". I hope that anyone reading this thread
>>> would also consider reading 
>>> [draft-ietf-mboned-ieee802-mcast-problems] which is heading for
>>> WG Last Call soon. Regards, Charlie P.
>>> 
>>> On 4/6/2019 8:28 AM, Carsten Bormann wrote: RFC 4861 says: Unless
>>> specified otherwise (in a document that covers operating IP over
>>> a particular link type) this document applies to all link types. 
>>> agreement in the WG and so I am failing to understand why we are 
>>> departing from that and bringing RFC 8505 discussions into this
>>> and post IETF last call.
>>> 
>>> _______________________________________________ its mailing list 
>>> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 15:02:35 +0200

> About broadcast emulation in a BSS:

(I agree with the description below of what you mean by 'broadcast
emulation'; as a side note, please allow me to correct that you said
'multicast emulation', not 'broadcast emulation'; I think I wished too
much when I thought you meant 'multicast emulation').

> The AP creates a broadcast domain of all the nodes that are 
> associated to it. That way you have a closure that you can call a 
> link from which you can derive a clear determination on who is on 
> link. The point of a BSS is that the AP can reach every associated 
> nodes, though individual nodes associated to the AP may or may not
> be able to reach one another directly.

I agree with this 'broadcast domain' and 'broadcast emulation'.  It may
be that it is because of this 'broadcast emulation' that IPv6 multicast
works very well in the presence of an Access Point.

But I also want to say that IPv6 multicast also works well when the
Access Point is absent - ad-hoc mode.  This is true even if it is not 
'OCB' mode.  The 'ad-hoc' mode (different term than OCB) also supports 
well IPv6 multicast.

One can try to see that IPv6 works ok in ad-hoc mode with three laptops
using IPv6 on their WiFi interface on Windows in mode
computer-to-computer, or ad-hoc.  Knowing that IPv6 does not work if
multicast does not work (RS/RA, DAD, etc. all rely on multicast groups),
and seeing that IPv6 pings ok between computers, one can understand
that multicast works ok without presence of Access Point.

> This is what what we mean by non-transitive link properties.

Well, I will try to understand it.

> To enable IP, the AP _emulates_ the Ethernet broadcast the following 
> way: a node sends the broadcast packet unicast to the AP and then the
> AP broadcasts it to all associated nodes, based on the assumption 
> that all nodes associated will get it. To optimize the chances that 
> all associated nodes receive it, the broadcast message is sent at
> the slowest speed and high energy level, which in turn is broadcast
> it is detrimental to unicast, both in terms of bandwidth and 
> interference. Approximately anyone on link will thus get the 
> broadcast that transports a multicast.

I tend to agree with the figure.

But, how do you then explain that IPv6 and multicast work ok even if the
Access Point is absent?

> But since there is no ARQ on a broadcast, there are still nodes
> which will not get it. This is one of the reasons why DAD by RFC
> 4861 already fails to discover some address duplication, even on a
> BSS or an ESS.

That I dont believe.  I would like to see some examples showing that DAD
fails to identify duplicates in the absence of Access Point.  That
includes description of experiments, packet dumps, etc.

> All the above is why we are  promoting RFC 8505 on Wi-Fi 
> independently of the discussion here.
> 
> About RFC 8505 over 802.11: RFC 8505 is a pure Layer 3 protocol. It 
> extends the NS/NA with options and uses less multicast.

Does RFC8505 send NS to 'all-nodes' IPv6 multicast address which is
further mapped to 0x33 link-layer multicast address?

> It is encapsulated on Wi-Fi through the same code path as IPv6 ND. 
> The RFC does not specify anything about that why should it? Bottom 
> line is that it just works.

I can understand the RFC8505 packets (address registration packets,
etc.) are sent through same code path as IPv6 ND: calling same functions.

> About OCB and multicast The IPv6 over OCB document does not have to 
> resolve the multicast problem but it cannot rely on a service that
> is not there.

The AP is not there but the multicast is there.

> IPv6 ND uses multicast for DAD and AR.

IPv6 ND on Host is from the start (receiving an RA, sending an RS)
dependent on link-layer multicast being present.  DAD comes later.

The very fact that IPv6 Host forms an LL is that it has used link-layer
multicast.  If DAD failed for the LL then we'd never see a LL address on
an interface of a laptop in ad-hoc mode.

> RFC 8505 solves the DAD and avoids the AR question by saying that the
> prefix is not on link. I believe that RFC 8505 is good enough for
> IPWave for DAD. I have in mind that for rapid movements, AR could be
> completely avoided by just using MAC level broadcast for all packets,
> but that requires more ML discussion.
> 
> About low Power What do you mean by high power? do you need to start 
> the engine before using OCB? Isn't there use cases where a vehicle 
> will upload diagnostics while parked at night? Even devices
> connected on mains have green options these days. Even Ethernet. But
> then again, the low power benefits of RFC 8505 are not limiting its 
> applicability on OCB and not a reason to dismiss it.

As you explain, low-power OCB could be indeed a goal.

The IEEE OCB designers may reply that OCB is probably the least
consuming devices, since they already eliminate all chatter like
Association Request/Response.

It's probably further optimizations.

But still, normal-power OCB is what this draft is about.

> About link scope: RFC 8505 solves the problem of the link scope for 
> link local uniqueness determination. Your draft fails to even 
> recognize the problem.

The draft does recognize a few things about multicast: it refers to the
mboned draft which itself has something about 802.11 multicast wireless.

The IP-over-OCB draft says:
> Transmitting IPv6 packets to multicast destinations over 802.11
> links proved to have some performance issues 
> [I-D.ietf-mboned-ieee802-mcast-problems].  These issues may be 
> exacerbated in OCB mode.  Solutions for these problems SHOULD 
> consider the OCB mode of operation.

> Like I said above, the closure is determined on a BSS by the set of
> associated nodes and we can run DAD on that.

In OCB, the closure is determined by the frequency set (channel), not by
the presence of an Access Point.  Different than in 802.11 WiFi, the OCB
channel is manually set (or by some innovative software).

(that says too, that in 802.11 WiFi, where the channel is set
automatically by existing software, there exist risks of interference
that can not be understood by people who dont control that software).

> ESS extends that but the bottom line is the same. You have a closure 
> that you can call a link, and every broadcast over that closure is 
> received by everyone so you can d DAD.

YEs.

> What is your closure?

The closure in my settings is defined by the channel number (frequency)
and distances. (see Appendix C of IPv6-over-OCB, it tells a few words,
but not too many, about the use of channels; many IETF readers dont like
to read about the channels, so much text about it disappeared).

> If you do not recommend RFC 8505 which IMHO was the simple thing to
> do, then you have to take the more complex path of documenting the
> problem and proposing a solution that extends RFC 4861. You need to
> document what your concept of a link is. My proposed text has an
> escape by which an implementation that has only IPv6 ND is acceptable
> but MUST have an external technique for DAD, since IPv6 ND will not
> do that for you.

Thanks for the text.  I will use it to add a few words about some issues.

Alex

> 
> cheers
> 
> Pascal
> 
> 
> Le lun. 8 avr. 2019 à 01:14, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> a écrit :
> 
> 
> 
>> I have to add that due to the lack of a multicast emulation (which 
>> is an AP function) OCB is in fact a much worse case for RFC 4861 
>> than BSS is. This could be an interesting new section to the mboned
>> draft.
> 
> Pascal - multicast at IP layer works ok on OCB links.  Sending RSs, 
> NSs, RSs an RAs on IP multicast groups, and their mapping on 
> link-layer multicast groups - works fine - in V2V mode (no IP-RSU) 
> and in V2I mode (with an IP-RSU present).  We use it extensively in 
> both ways.
> 
>  provide proper link-layer multicast function (e.g. link-layer 
> subscribe operations, or fine-grained groups such as 'all-hosts'), 
> the IP layer uses filters to replace subscribe operations, and 
> mappings between fined-grained groups and all-encompassing groups 
> (e.g. both all-hosts and all-routers groups are mapped into a single 
> value 'everyone').
> 
> This kind of implementation exists everywhere where IPv6 needs 
> multicast support and the link-layer does not provide.
> 
> The specification of this link-layer multicast behavior does not 
> exist: neither IEEE documents dont describe, nor IETF documents.
> 
>>  consider the document as a reference. Due to that visibility, it 
>> is not acceptable that we fail to expose the problem and its 
>> solution as they exist today.
>> 
>> designed before Wi-Fi even existed and for which NBMA is ATM or 
>> Frame Relay...
> 
>>> <[email-masked]
> <mailto:[email-masked]>> a écrit :
>>> 
>>> Hello Carsten,
>>> 
>>>  restricted to WPAN or WiFi.  And it would be wrong to require, 
>>> for each type "foo" of wireless medium, a separate "ND-over-foo"
>>>  document, when the issues are general to wireless and not 
>>> specific to "foo".
>>> 
>>> I hope that anyone reading this thread would also consider 
>>> reading [draft-ietf-mboned-ieee802-mcast-problems] which is 
>>> heading for WG Last Call soon.
>>> 
>>> Regards, Charlie P.
>>> 
>>> 
>>>> IP over a particular link type) this document applies to all
>>>> link types.
>>>> 
>>>>> We had extensive amount of discussions and we agreed to keep 
>>>>> ND support out of scope for this document, and that separate
>>>>> are departing from that and bringing RFC 8505 discussions 
>>>>> into this  and post IETF last call.
> -- Pascal

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Apr 2019 15:08:16 +0200

> rather empty. Which raises the question of the value of publishing it. 

There is value in publishing it, albeit not as high as you seem to fear.

The document specifies more than saying that ND works ok.

The document specifies new things compared to existing art 
(IPv6-over-Ethernet, 6lo RFCs):
- the Ethernet Adaptation Layer
- the QoS values to set in 802.11 headers
- the IID formation and privacy
- some clarifications, like '3333'

It also has extensive Appendices explaining what is OCB, examples of 
packet formats, and other guides to implementation.

Alex

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Apr 2019 17:05:30 -0400

All:

The IPWAVE WG Chairs are suggesting a way forward...

1) draft-ietf-ipwave-ipv6-over-80211ocb should make it clear that ND optimizations are out of the scope.

2) It looks to me like RFC8505 is a good starting point for future work on ND optimizations, but that belongs in _another_ document. It seems like several people on this list are interested in working on that topic.  Ideally, the problem statement document will describe the benefits of those optimizations,

Russ & Carlos

> > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> 
> > a écrit :
> > 
> > 
> > 
> >>> <[email-masked] <mailto:[email-masked]>
> > <mailto:[email-masked] <mailto:[email-masked]>>> a écrit :
> >>> 
> >>> Hello Carsten,
> >>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 8 Apr 2019 22:44:54 +0000

Makes sense to me.

On #2, not a starting point, but the group can review to see if those optimizations done in 6LOWPAN group can be relevant in IPWAVE environments and they can be leveraged in vehicular architectures. But, as you say, that should reflect in the problem statement.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of Russ Housley <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 8, 2019 at 2:05 PM
To: its <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] RFC8505 and 802.11 headers

All:

Russ & Carlos

YEs.

Alex

> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> a écrit :
>
>
>
>>> <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> a écrit :
>>>
>>> Hello Carsten,
>>>

---

From: Pascal Thubert <[email-masked]>
Date: Tue, 9 Apr 2019 14:02:13 +0800

Hello Alexandre

Like I said I liked the appendixes.

But most of your list above is not all is paraphrasing other
specifications, as opposed to specifying anything new, isn't it? Then why
not point on the references and be done, at least you avoid spreading
misconceptions.

e.g., I do not see the point of paraphrasing the IEEE in what you called an
adaptation layer. The operation that your are summarizing appears to be
present in pretty much any 802.11 device where it is easier to do that than
apply IPv6 directly on .11. I have not seen that it is any different in
OCB. If there is a difference, then it is of interest to note it; I failed
to see it in my review. On the same line, privacy addresses are not
specific to OCB. 3333 is 20+ years old.

cheers,

Pascal

-- 
Pascal

---

From: Pascal Thubert <[email-masked]>
Date: Tue, 9 Apr 2019 14:41:55 +0800

Hello Alexandre

please see below

> In the context we currently deploy (V2V), the guarantee is from DAD and
Then you failed

> A small set of nodes: it is less than 10 nodes in an area of around 100

don't you see the problem? ND needs a closure. Sorry I explained if from
all the angles  could see. I will not paraphrase myself again.

> > you do not have that you can not claim that multicast works (for

And this is why you fail to provide DAD

> Yes, it is a good example.

indeed. Hopefully you should see the point

> ND timers - not sure which ones, maybe you tell me which ones.
This is the root of the problem. You do not have an ethernet to plug. You
do not have a DNA. The whole model that sustains ND is gone.
Explain me now when you plug that virtual ethernet, every time a new car is
in range? How do you even know?
And then, how long till your addresses are usable again after you on/off
the interface?
What I'm expecting from you is to realize that you cannot "unplug the
ethernet" every time a car comes into range or goes away, because that
happens more often than it take for your interface to reboot, do DAD,
etc...
And then if you have a collision, what do you do? Your description is that
you stop using your address, which means killing all your other coms with
all the other cars.

Sorry, there is a very long way between the "should be" in your description
and an answer to how you can DAD.

> well: from IPv6 SLAAC, to Mobile IPv6, youtube IPv6 and more.

As expected. If there is no address duplication, the lack of DAD will not
show. This is already discussed in my proposed text as an escape strategy.
Unicast DAD for link local between peers is a better strategy because it is
immediate (no 1s DAD timer) and because a peer-wise DAD failure does not
impact the active connections that use the LL Address with other peers.
this is the sort of things that a valuable IPv6 over foo can indicate.

Another thing which is of importance is the RA interval as described in
Mobile IP. This allows the car to discover the RSU in time. This is not
discussed in your draft. With the default settings a car can be parked 10
minutes in front of a RSU and now see a RA. Also, the draft discusses Link
local communication and excludes global addresses and thus internet access.
So none of the above cannot be done with just following the draft. This
limits the value of the draft dramatically.

> there is need of time to test.

They will be out of range before DAD by RFC 4862 completes (with RFC 4860
it takes  2-3 seconds to bootstrap the interface, DAD a link local and a
global, and do a lookup; more if the lookup fails) at a relative speed of
220 kilometers, the cars will be 150m away before one can send a packet. So
following your own recommendation above, one should use OCB for house to
house, wagon-to-wagon in a train, or stopped car in a parking lot and the
engine still on to get your high power. All this makes no sense to me.

*Note: I will throttle on this thread. I spent all my bandwidth. *

My proposed text is on the table. I told the chairs that my recommendation
is to send the doc back to the WG. I hope they will look carefully at the
points raised in this thread including all the discussion on paraphrasing.
They may agree that RFC 8505 goes a long way solving the ND problem and
decide to build on that basis, or they may do something entirely different.
Note that the discussion on RFC 8505 for Wi-Fi is proposed text for the
rev-to-be-2019. You may download the -2016 for free but there is no time
machine that will update that text with a ref to RFC 8505.

Cheers,

Pascal

-- 
Pascal

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Apr 2019 15:49:12 +0200

Pascal,

One of the key values of this document is in the title itself: it says 
to run IPv6 over OCB.

Probably you are not aware, but at 5.9GHz few people think we should do 
IP, but rather other non-IP things (CAM-over-GeoNetworking, and others).

The poorness gained from not publishing this document is even more lack 
of support of IP deployment on OCB at 5.9GHz.

> Like I said I liked the appendixes.

Good to know.

> specifications, as opposed to specifying anything new, isn't it?

No. The list of distinctive features in IP-over-OCB is not only about 
referring to other specifications.

As far as I know, the Ethernet Adaptation Layer (EAL) is not specified 
in any other specification.  The 802.11-2016 document does not describe 
how to make Ethernet II packets out of 802.11 packets.  The 802.1d 
document is about bridging between Ethernet and Ethernet.

The use of QoS fields in 802.11 headers to transmit IPv6 data at 5.9GHz
is not described anywhere else.

> e.g., I do not see the point of paraphrasing the IEEE in what you 
> called an adaptation layer.

Pascal, to me it seems you think IEEE already describes in an IEEE
document what I describe as a layer.  And you seem to say I just give a
new name to something already existing at IEEE document.

I disagree.

To further this point, I would like to point that making Adaptation 
Layers is common at IETF.

Second, to clarify if I am wrong, I asked you this in private meeting 
face-to-face, I asked you on private email; I now ask you publicly: 
please provide me an IEEE document that describes something akin to what 
our EAL does: make 802.11 headers out of Ethernet II headers and 
vice-versa.  It is not a challenge, it is just a key that may solve an 
issue.

(I have already asked this in the past several IEEE knowledgeable
people; I have no answer.  Maybe the question is wrong, or maybe not.)

(I have searched myself in the 802.11-2016 document the string
'bridg' to find something akin to EAL; maybe my searches are too biased 
to give answers I like, or maybe not).

> The operation that your are summarizing appears to be present in 
> pretty much any 802.11 device where it is easier to do that than 
> apply IPv6 directly on .11.

True.

> I have not seen that it is any different in OCB. If there is a
> difference, then it is of interest to note it;

 From IP perspective, the difference between 802.11 and 802.11 in OCB 
mode is at least in the QoS field:
> the value of the Traffic Identifier (TID) sub-field of the QoS
> Control field of the 802.11 header MUST be set to binary 001 (i.e.
> User Priority 'Background', QoS Access Category 'AC_BK').

Only in OCB mode, only at 5.9GHz and only with IPv6 must the value in 
that field is a MUST.  In non-OCB mode (ad-hoc mode, AP mode), or at 
other frequencies, that value can be absent.

> On the same line, privacy addresses are not specific to OCB. 

Well, indeed, privacy addresses are not specific to OCB.  They are 
important to all 802.11 and 802.15.4 and all other links on which IPv6 runs.

There are many kinds of privacy addresses and many documents.

The generation of MAC addresses is not described anywhere, and this 
document does.

Further, this is probably the only single document where a mix of 
existing MAC-in-IID addresses, MAC address generation (virtual MAC) and 
opaque IDs are described in a single document.

For example, there is no other document that describes how to make IP 
addresses by still using MAC addresses, but generate them instead of 
getting them from manufacturer.

There is no other document that tells to continue to use the existing 
MAC-based IP addresses with MACs from manufacturer, for a while 
(transition time).

> 3333 is 20+ years old.

3333 is 20+ years old but recently somebody asked what does "0 0 1 1 0 0 
1 1 0 0 1 1 0 0 1 1" mean in the picture of rfc2464.

So we clarified what it means.  That bit string means 3333.  3333 is 
clarified in RFC7042, which is more recent.  And we refer to it.

Do you think that clarification is not worth making?

Alex

> 
> cheers,
> 
> Pascal
> 
> Le lun. 8 avr. 2019 à 21:08, Alexandre Petrescu 
> (IPv6-over-Ethernet, 6lo RFCs): - the Ethernet Adaptation Layer -
> the QoS values to set in 802.11 headers - the IID formation and
> privacy - some clarifications, like '3333'
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Apr 2019 21:20:58 +0200

Hi Pascal,

I recommend the authors of 8505 to write what you mention below in a
document and pass it in a WG to accept it and examin it and then examin it
again by iesg.

AB

On Sun, Apr 7, 2019 at 10:00 PM Pascal Thubert <[email-masked]>
wrote:

> Hello Sri
>
> I already suggested to stop confusing RFC 8505 with 6LoWPAN. The RFC has
> its applicability section which does not limit it to that but rather
> considers whether multicast is available or not.
>
> properties of the protocol and the type of connectivity one gets in a
> vehicle and then consider the matching.
>
> > The group may not yet fully understand why RFC 8505 is suitable for the
> job but at least we all understand that RFC 4861 is not, based on the own
> words in the RFC.
>
> I am fine with the author's assertion that 8505 is a great fit, but the
> authors have to establish that. I am sympathetic to that view that it can
> be used, but I cannot take that at its face value.
>
> If I look at RFC 4919 (6LoWPANs: Overview, Assumptions, Problem Statement,
> and Goals), section 2, where it provides a definition of LoWPAN network, I
> do not think it includes all the properties of a vehicular network.
> Vehicular network is about mobility, latency, always-on-connectivity.
> Latency is one important property which is not even a consideration for
> low-power devices. The vehicle may be running on a battery, but the
> stringent low-power constraint may not be applicable for WAVE environments;
> constraints on processing powers, or memory as it does for certain IOT
> devices.
>
> Therefore, the below text does not make me believe the designers of
> 6LOWPAN had vehicular networks in mind.  At the same time, I do agree some
> of the principles may be applicable here and leveraged for IPWAVE, but I
> cannot agree that this is perfect fit and was designed exactly for this
> operating environment as I read from this thread.
>
>
> —————
> RFC 4919: Section 2
>
> The group may not yet fully understand why RFC 8505 is suitable for the
> job but at least we all understand that RFC 4861 is not, based on the own
> words in the RFC.
>
> also incorrect to take the view of using a single hammer for everything..
> Sri