Subject: Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 7 May 2018 21:57:25 +0200

Lorenzo - how do you think we could solve this problem?

Alex

Le 21/04/2018 à 05:21, Lorenzo Colitti a écrit :
> I don't think that explanation changes anything. I think the problem is 
> that this document says "on this link type, the process to map IPv6 
> addresses to MAC addresses are specified in RFC 4861" and "on this link 
> type, IPv6 ND is unspecified". That's a direct contradiction, because 
> RFC 4861 *is* neighbour discovery.
> 
> In effect, what this document is saying is, "on this link type, the 
> process to map IPv6 addresses and MAC addresses are unspecified". If 
> that's the case, then the document should clearly state it.
> 
> On Fri, Apr 20, 2018 at 6:11 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Lorenzo,
> 
>     Thank you for the comment.
> 
>     Le 19/04/2018 à 10:42, Lorenzo Colitti a écrit :
>>     On Thu, Apr 19, 2018 at 12:21 PM, Suresh Krishnan
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>           This document describes the transmission of IPv6 Packets
>>         over IEEE 802.11 OCB networks, and has completed WGLC in the
>>         ipwave working group. When the ipwave working group was
>>         created, the charter was written so that this document would
>>         be reviewed by the 6man working group prior to it getting
>>         advanced. The current version of the draft is available at
>>         this URL
>>
>>         https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22
>>         <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22>
>>
>>         Please take some time to review this draft and send in your
>>         comments to the 6man mailing list by end of day May 2nd 2018.
>>
>>
>>     I read the document but I don't understand how IPv6 over this type
>>     of network will work. The document says that IPv6 ND over this
>>     link type is unspecified. If ND is not specified, then how will
>>     communication work?
>>
>>     This is made worse by the fact that the document says "The
>>     procedure for mapping IPv6 unicast addresses into Ethernet
>>     link-layer addresses is described in [RFC4861]." But RFC 4861 *is*
>>     neighbour discovery, which this document says is unspecified on
>>     this link type.
> 
>     At a small scale, ND works ok over 802.11 set in OCB mode.  It works
>     just like over WiFi.  It was demonstrated in settings with a few
>     cars (2 to 3) and under coverage of one Road-Side Unit in some
>     circumstances.
> 
>     However, there are strong doubts when the scale is larger than 2 or
>     3 vehicles and 1 RSU.  The doubts come from these questions:
>     - are ReachableTime and RetransTimer values of ND different in OCB
>     mode than in ICB (802.11 "In" the Context of a BSSID)?
>        In ICB mode, one would expect these values to match the ones of
>     timers of 802.11 between Association Req, Reply, etc.
>        In OCB mode there is no Ass'n Req/Rep so what should these timer
>     values be?
>     - how can a car implement IP handovers when it has no link-layer
>     triggers?  (OCB mode has no link-layer messages
>        that could be used as triggers).   How can the Mobile IPv6
>     implementation measure signal levels
>        to decide which OCB network is better?  The OCB networks have no
>     distinctive name (ours are called all 'fake').
>        Are the RSUs mandated to MUST send RAs such that cars to measure
>     signal levels? (the link-layer 802.11 periodic TSA message is not
>     implemented at all).
>        Can the RA contain timestamp data such as to replace TSA
>     functionality?
>     - how can the multicast subscription to link-local groups happen
>     correctly when the link-layer does not assure a coherent link?
>     - can new ND extensions help make reachability between two entities
>     in two cars in a set of 10 in line (platoon, convoy)?
> 
>     So, I would say that IPv6 works over OCB, but in details related to
>     scale, we may need to double check.
> 
>     What do you think?
> 
>     Alex
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 May 2018 21:20:24 +0900

I think the next step is to confirm or refute Brian's assertion that since
the link doesn't support multicast, RFC 4861 cannot work as written.

On Tue, May 8, 2018 at 4:57 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> type, IPv6 ND is unspecified". That's a direct contradiction, because RFC
>> 4861 *is* neighbour discovery.
>>
>> process to map IPv6 addresses and MAC addresses are unspecified". If that's
>> the case, then the document should clearly state it.
>>
>> On Fri, Apr 20, 2018 at 6:11 PM, Alexandre Petrescu <
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     Hi Lorenzo,
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 8 May 2018 15:04:21 +0200 (CEST)

On Thu, 19 Apr 2018, Suresh Krishnan wrote:

> Hi all,
>  This document describes the transmission of IPv6 Packets over IEEE 802.11 OCB networks, and has completed WGLC in the ipwave working group. When the ipwave working group was created, the charter was written so that this document would be reviewed by the 6man working group prior to it getting advanced. The current version of the draft is available at this URL
>
> Please take some time to review this draft and send in your comments to the 6man mailing list by end of day May 2nd 2018.

I am a bit late with this comment. This document seems to require lots of 
pre-existing knowledge about "OCB" networks, whatever that is 
("Outside the Context of a Basic Service Set" is perhaps a hint in the 
title, but it doesn't map perfectly).

The document talks about "Management Information Base (MIB)". I have no 
idea what this is? SNMP? The word SNMP doesn't exist in the document.

"802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
    attribute dot11OCBActivited is true."

I tried to figure out how the entire thing is supposed to work, but 
failed. There is text about router advertisement sent from an ANR (Access 
network Router). I have no idea what this is or how it's supposed to be 
deployed. Two cars out on the road in the middle of nowhere, are they not 
going to be able to talk to each other?

Most of the referenced documents are behind IEEE paywall.

I can't tell if the proposal is going to work or not, because the entire 
document requires pre-existing knowledge about the specifics of these 
"OCB" networks. I googled a bit and found:

https://datatracker.ietf.org/meeting/96/materials/slides-96-its-1
https://datatracker.ietf.org/meeting/96/materials/slides-96-its-4

It didn't make me understand more where this RA is coming from. The 
document draft-ietf-ipwave-ipv6-over-80211ocb-22 talks about MAC address 
renumbering. So... without RAs, are link-local addressing used primarily 
for the communication?

These kinds of basic questions in understanding how everything is supposed 
to work is hindering ability to be able to comment on the document in any 
meaningful way.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 May 2018 08:50:30 +1200

> the link doesn't support multicast, RFC 4861 cannot work as written.

And if I'm right, this becomes another NBMA case. I'm not sure that
we really have a general-purpose NBMA solution.

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 May 2018 14:28:34 +0200

Le 24/04/2018 à 22:59, Brian E Carpenter a écrit :
> On 24/04/2018 23:22, Alexandre Petrescu wrote:
> 
>> Maybe we should say: "ND over 802.11 OCB works, but the precise values
>> of variables ReachableTime and RetransTimer have not been identified".
> 
> But, but, but the draft seems to make it clear that layer 2 multicast
> doesn't work.

Brian,

I am not sure which part of the draft makes think that the layer 2 
multicast does not work in 802.11-OCB?

Is it this paragraph in the draft?
>    Transmitting IPv6 packets to multicast destinations over 802.11 links
>    proved to have some performance issues
>    [I-D.perkins-intarea-multicast-ieee802].  These issues may be
>    exacerbated in OCB mode.  Solutions for these problems should
>    consider the OCB mode of operation.

I am asking because:
- link layer multicast does not work fully on 802.11 nor on Ethernet
   either
   (there are no link layer messages to join/leave link-layer groups
    even though there are link-layer group addresses like 33:33::1)
- IPv6 over 802.11 in mode OCB runs ok because it assumes
   the 'all-nodes' or 'solicited-node' IPv6 addresses reach
   everyone tuned to a particular frequency, e.g. 5900 MHz.
   For example, an RS sent to ff02::1 will reach everyone nearby.

> If so this is an NBMA network and normal ND does not work.

802.11 in mode OCB is not an NBMA Non-Broadcast Multi-Access Network. 
802.11-OCB is a Broadcast network and multi-access: many nodes listen 
and talk simultaneously.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 May 2018 14:52:06 +0200

Le 08/05/2018 à 15:04, Mikael Abrahamsson a écrit :
>> Hi all, This document describes the transmission of IPv6 Packets 
>> ipwave working group. When the ipwave working group was created,
>> the charter was written so that this document would be reviewed by
>> the 6man working group prior to it getting advanced. The current 
>> version of the draft is available at this URL
>> 
> I am a bit late with this comment. This document seems to require 
> lots of pre-existing knowledge about "OCB" networks,

Right.  For an introduction to the OCB concept one should read the draft
backwards: start with Appendices B, C and D and only then read the /middle.

> whatever that is ("Outside the Context of a Basic Service Set" is 
> perhaps a hint in the title, but it doesn't map perfectly).

I agree.  The imperfection in the mapping stems from (1) compromises
reached while tinkering with the title and (2) IEEE custom to call it
"OCB" and not "OCBSS".

> The document talks about "Management Information Base (MIB)". I have 
> no idea what this is? SNMP? The word SNMP doesn't exist in the 
> document.

True.

Not only IETF calls MIB a MIB but also IEEE 802 group relies extensively
on MIB.  IEEE defines OCB mode as a value of a particular flag in the
IEEE MIB.

SNMP absent in the document: I dont think we should mention SNMP, but I
do think we should have a Yang model for the IPv6-over-OCB draft.  MIB
is outdated, and we should now do Yang instead.  But unfortunately
nobody until now said would like to write a draft about Yang for
IPv6-over-802.11-OCB.  It should however be very simple.

Would you agree?

> failed. There is text about router advertisement sent from an ANR 
> (Access network Router). I have no idea what this is or how it's 
> supposed to be deployed.

Well, we struggled to use a term to stand for a router along the road to
which the car connects, hands over to, from.  The ANR term is from
RFC3753.  Other proposals were made, like Road-Side Unit, or Router -
each with its own difficulties.

> Two cars out on the road in the middle of nowhere, are they not going
> to be able to talk to each other?

YEs yes, they should.  The presence of an ANR is not mandatory in order
for two cars to talk to each other.

Maybe we should clarify saying: "the presence of an IP-RSU, or an ANR,
is not mandatory in order for two cars to communicate directly"?

> Most of the referenced documents are behind IEEE paywall.

Right.

Just ask which document you want.  There are many IEEE-inclined people
in IPWAVE WG and ready to share under certain confidentiality conditions.

Besides, the basic IEEE 802.11 document is free for all.

> I can't tell if the proposal is going to work or not, because the 
> entire document requires pre-existing knowledge about the specifics 
> of these "OCB" networks. I googled a bit and found:
> 
> It didn't make me understand more where this RA is coming from.

It's from a router in the lab.

Right now there are a few places like that, or trials on the road, that
send such RAs.

> The document draft-ietf-ipwave-ipv6-over-80211ocb-22 talks about MAC 
> address renumbering.

It's an appendix.  The renumbering mechanism is a suggestion, and has no
normative text.

ETSI security applications for ITS-G5 links are required to use such MAC
renumbering, but IPv6-over-802.11-OCB does not make it mandatory.

> So... without RAs, are link-local addressing used primarily for the
> communication?

It could, yes.

There are a few individual submission drafts that describe this.

> These kinds of basic questions in understanding how everything is 
> supposed to work is hindering ability to be able to comment on the 
> document in any meaningful way.

I think this is a request for some sort of addressing architecture
document, with an example deployment?

But, RFC2464 (a classic IPv6-over-foo document) does not describe such
an example.  So why should this IPv6-over-foo document do it?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 9 May 2018 15:27:04 +0200 (CEST)

> backwards: start with Appendices B, C and D and only then read the /middle.

Ok, that could be good text to add for the introduction text.

>> whatever that is ("Outside the Context of a Basic Service Set" is perhaps a 
>> hint in the title, but it doesn't map perfectly).
>

Good text for the document to include.

> IPv6-over-802.11-OCB.  It should however be very simple.

It's my opinion that putting in MIB somewhere in the text without further 
references makes it really hard to understand what's going on. You could 
call it a function or just refer to it as an IEEE MIB. There is no problem 
in my book to refer to SNMP MIBs without defining your own everything. 
Just reference what it is.

>> "802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute 
>> dot11OCBActivited is true."
>> 
>> I tried to figure out how the entire thing is supposed to work, but failed. 
>> There is text about router advertisement sent from an ANR (Access network 
>> Router). I have no idea what this is or how it's supposed to be deployed.
>

That's a good clarification to make in the document, yes.

>> document requires pre-existing knowledge about the specifics of these "OCB" 
>> networks. I googled a bit and found:
>> 

Ok, that would be good to know.

> an example.  So why should this IPv6-over-foo document do it?

Sure, and you do reference section 5 for link-local in the document. In 
4.6 of the OCB document there is talk about forming a subnet. I think 
there should be wider explanation about what this means. Is this like a 
"bubble" around the car? Is it really a subnet then?

Also, all these appendices. Are they supposed to be taken out when this 
thing becomes an RFC?

---

From: NABIL BENAMAR <[email-masked]>
Date: Wed, 9 May 2018 14:33:46 +0000

Hi Mikael,

Regarding the appendices, they are in the current document and they are not
supposed to be removed. They are needed for a better understanding of the
content.

On Wed, May 9, 2018 at 1:27 PM, Mikael Abrahamsson <[email-masked]> wrote:

> whatever that is ("Outside the Context of a Basic Service Set" is perhaps
>>> a hint in the title, but it doesn't map perfectly).
>>>
>>
> in my book to refer to SNMP MIBs without defining your own everything. Just
> reference what it is.
>
>>> deployed.
> 4.6 of the OCB document there is talk about forming a subnet. I think there
> should be wider explanation about what this means. Is this like a "bubble"
> around the car? Is it really a subnet then?
>

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
University Moulay Ismail
Meknes. Morocco

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 May 2018 11:46:22 +1200

On 10/05/2018 00:28, Alexandre Petrescu wrote:
> multicast does not work in 802.11-OCB?> 

No. In https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22#section-4.6
we find:

>>>  In OCB, the link layer
>>>  does not ensure that all associated members receive all messages,
>>>  because there is no association operation.

I can only interpret that to mean that multicast does not work,
and that is why the next sentence says:

>>>  The operation of ND over
>>>  802.11-OCB is not specified in this document.

>     even though there are link-layer group addresses like 33:33::1)

All the 802.11 switches I have met correctly emulate Ethernet
multicast at layer 2 *or* implement MLD.

>    For example, an RS sent to ff02::1 will reach everyone nearby.

If so, the switches are emulating Ethernet multicast (since you
don't mention MLD). What about, say, UDP to ff02::13?

If so, why isn't ND specified for OCB?

Also, what does "nearby" mean? Does multicast suddenly fail if
there is a bus between your car and mine?

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 May 2018 13:20:13 +0900

> I can only interpret that to mean that multicast does not work,

I don't agree with that interpretation. I don't think there is any link
layer that "ensures" that all associated members receive all messages. For
example, regular wifi e.g., (802.11a/b/g/n/ac) certainly doesn't. The AP
sends the packet out on the medium, and if a given STA doesn't hear it or
can't decode it, it just never receives it.

But even Ethernet does not provide these guarantees, due to packet loss.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 May 2018 17:48:41 +1200

> But even Ethernet does not provide these guarantees, due to packet loss.

You're technically correct, of course. That's why we tend to retry
ARP and ND. But the way the draft states things implies to me that
missing packets are guaranteed to occur "because there is no association operation", especially since it is the very next sentence that
says that ND is not available. At best, the text is confusing.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 May 2018 14:58:39 +0900

On Thu, May 10, 2018 at 2:48 PM, Brian E Carpenter <
[email-masked]> wrote:

> missing packets are guaranteed to occur "because there is no association
> operation", especially since it is the very next sentence that

Sorry, I wasn't trying to be argumentative. I agree with you that the text
is ambiguous and confusing. I just wanted to point out that as is, it
doesn't strongly imply that multicast will not work. Of course, there's a
world of difference between "doesn't work 1% of the time" and "doesn't work
50% of the time".

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 13:25:42 +0200

Le 10/05/2018 à 01:46, Brian E Carpenter a écrit :
>>>> Maybe we should say: "ND over 802.11 OCB works, but the precise
>>>> values of variables ReachableTime and RetransTimer have not
>>>> been identified".
>>> 
>>> But, but, but the draft seems to make it clear that layer 2 
>>> multicast doesn't work.
>> 
>> Brian,
>> 
>> multicast does not work in 802.11-OCB?> Is it this paragraph in the
>> draft?
>>> Transmitting IPv6 packets to multicast destinations over 802.11 
>>> links proved to have some performance issues 
> No. In 
> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22#section-4.6
>
>
>
> 
 > we find:
> 
>>>> In OCB, the link layer does not ensure that all associated 
>>>> members receive all messages, because there is no association 
>>>> operation.
> 
> I can only interpret that to mean that multicast does not work, and 
> that is why the next sentence says:
> 
>>>> The operation of ND over 802.11-OCB is not specified in this 
>>>> document.

I agree there is confusion.

These are the two confusing lines:

> The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB
> links is different than over 802.11 links.
[...]
> The operation of ND over 802.11-OCB is not specified in this 
> document.

I suggest we remove the former line.

>> I am asking because: - link layer multicast does not work fully on
>>  802.11 nor on Ethernet either (there are no link layer messages to
>>  join/leave link-layer groups even though there are link-layer 
>> group addresses like 33:33::1)
> 

Well, I am not sure whether Ethernet multicast includes some layer2
signaling to join or leave layer2 groups?  I suppose it is no.  That
means that layer2 multicast is not 'true' multicast like IP multicast is
(which has join/leave messages), and rather is based on local reception
filters.

For switches implementing MLD: as far as I remember, MLD does not allow
to join/leave layer2 multicast address groups, but layer3 multicast
address groups.

In relation to 802.11-OCB: between cars one can not put a switch
(although one does put switches inside each car); some times there are
Road-Side Units along the road that could be switches, but the cars must
be able to talk to each other even in absence of RSUs.

>> - IPv6 over 802.11 in mode OCB runs ok because it assumes the 
>> 'all-nodes' or 'solicited-node' IPv6 addresses reach everyone tuned
>> to a particular frequency, e.g. 5900 MHz. For example, an RS sent
>> to ff02::1 will reach everyone nearby.
> 
> If so, the switches are emulating Ethernet multicast (since you don't
> mention MLD). What about, say, UDP to ff02::13?

I guess ff02::13 is not allocated, and just an example.

Maybe ff02::1:3 is meant.

Section 4.4.2 "Address Mapping -- Multicast" of IPv6-over-OCB draft
refers to RFC2464 which says that address maps to layer2 group address
33-33-00-01-00-03.

All nodes on that link (in Ethernet: same VLAN, or same hub; in WiFi:
same ESSID; in OCB: same frequency) will receive an UDP message sent to
that 33-33-00-01-00-03 address.

As on Ethernet and WiFi, on OCB too the application wishing to receive
that UDP message would have to send an MLD REPORT for that group first.

> If so, why isn't ND specified for OCB?

Because nobody tried to write a document about it.

There are a few people who expressed interest in writing such a
document, but it is still in an interest phase.

> Also, what does "nearby" mean? Does multicast suddenly fail if there
>  is a bus between your car and mine?

'Nearby' is like in 'I see it close'. It means that the emitter puts
enough energy in the air to cover that distance in line of sight and the
receiver is sensitive enough. That 'nearby' excludes the intermediary
bus (an obstacle) and other objects reflecting electro-magnetic waves.
It is true that these cases of obstacles and reflection are very common
in crowded urban roads. It is also true that on other rural roads or
long-distance highways these obstacles and reflections are very rare.

But I dont think we can describe in this document how multicast should
work on each of these two use-cases (rural, urban).

Alex

>> 802.11 in mode OCB is not an NBMA Non-Broadcast Multi-Access 
>> Network. 802.11-OCB is a Broadcast network and multi-access: many 
>> nodes listen and talk simultaneously.
>> 
>> Alex
>> 
>>> 
>>> Brian
>>> 
>>> [email-masked] Administrative Requests: 
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative 
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 13:34:49 +0200

Le 10/05/2018 à 06:20, Lorenzo Colitti a écrit :
> On Thu, May 10, 2018 at 8:46 AM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     No. In
>     <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-22#section-4.6>
>     we find:
> 
>     >>>  In OCB, the link layer
> layer that "ensures" that all associated members receive all messages. 
> For example, regular wifi e.g., (802.11a/b/g/n/ac) certainly doesn't. 
> The AP sends the packet out on the medium, and if a given STA doesn't 
> hear it or can't decode it, it just never receives it.

YEs yes, there is no full ensurance about message reception even in 
802.11abgn/ac.  But let's say there is a little bit more ensurance in 
802.11abgn/ac about receiving a message: there is a layer2 message 
called 'Acknowledgment' for each received packet.  In OCB there is no 
such ack.

> But even Ethernet does not provide these guarantees, due to packet loss.

YEs, but there is more packet loss on OCB than on Ethernet.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 13:46:26 +0200

Le 09/05/2018 à 15:27, Mikael Abrahamsson a écrit :
[...]
>> SNMP absent in the document: I dont think we should mention SNMP,
>> but I do think we should have a Yang model for the IPv6-over-OCB
>> draft.  MIB is outdated, and we should now do Yang instead.  But
>> unfortunately nobody until now said would like to write a draft
>> about Yang for IPv6-over-802.11-OCB.  It should however be very
>> simple.
>> 
>> Would you agree?
> 
> It's my opinion that putting in MIB somewhere in the text without 
> further references makes it really hard to understand what's going
> on. You could call it a function or just refer to it as an IEEE MIB.
> There is no problem in my book to refer to SNMP MIBs without defining
> your own everything. Just reference what it is.

Well, I would like to reference to a MIB of IPv6-over-Ethernet RFC2464, 
but such thing does not exist.  It should be written.  Then there should 
be an IPv6-over-WiFi RFC and a MIB for it.

Until then, maybe the draft can just refer to the dot11OCBActivited flag 
of IEEE.

[...]>>> So... without RAs, are link-local addressing used primarily for
>>> the communication?

E.g. draft-petrescu-autoconf-ra-based-routing-05 talks about the use of 
link-local addresses and link-scoped multicast between vehicles, w/o 
presence of a road-side unit.

>>>  supposed to work is hindering ability to be able to comment on
>>> the document in any meaningful way.
>> 
>> But, RFC2464 (a classic IPv6-over-foo document) does not describe
>> such an example.  So why should this IPv6-over-foo document do it?
> 
> Sure, and you do reference section 5 for link-local in the document.
> In 4.6 of the OCB document there is talk about forming a subnet. I
> think there should be wider explanation about what this means. Is
> this like a "bubble" around the car? Is it really a subnet then?

It's not quite a bubble around the car, because such bubble would belong 
to that particular car.  It's more like a glue that links together a few 
cars nearby.  For example in a large convoy ('platoon') there is one 
such small glue between each pair of cars.  Some small convoy (3 trucks) 
uses a single glue between all cars.

I could describe this, it is a good idea, but not in this draft. 
Because in RFC2464 (a typical IPv6-over-foo document) there is no such 
description of how would the subnet be constructed.

[...]

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 May 2018 12:07:46 +1200

A few final remarks in line, then I will resign from this thread :-).

> I suggest we remove the former line.

That would be better, but then this document's claim to be
an IPv6-over-foo specification fails IMHO.

> signaling to join or leave layer2 groups?  I suppose it is no.

No. But Ethernet is intrinsically broadcast in concept.

> That

Correct. But of course an upper layer just doesn't care about
that distinction.

> I guess ff02::13 is not allocated, and just an example.

It is assigned:
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#link-local

> refers to RFC2464 which says that address maps to layer2 group address

What I understand is that multicast is highly unreliable on OCB
(as opposed to reasonably reliable on classical 802.11).

Because you not specify how neighbours are discovered, I don't
see how an actual IPv6 service could be provided.

   Brian

> .

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 May 2018 10:41:35 +0900

> see how an actual IPv6 service could be provided.

If that's true then that means this document does not actually specify a
feasible scheme to implement IPv6 over this network type. As such, perhaps
the 6man WG should recommend that this document should not be published
until it either documents a working specification or at least clearly and
unambiguously documents what works and what doesn't.

Suresh, chairs - what's the best way forward here? Would it be a good idea
to present this document at the 6man slot in Montreal to solicit input from
other participants and see if together we can come up with better text?

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 16 May 2018 16:37:47 +0000

Hi Lorenzo,

On May 14, 2018, at 9:41 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
What I understand is that multicast is highly unreliable on OCB
(as opposed to reasonably reliable on classical 802.11).

If that's true then that means this document does not actually specify a feasible scheme to implement IPv6 over this network type. As such, perhaps the 6man WG should recommend that this document should not be published until it either documents a working specification or at least clearly and unambiguously documents what works and what doesn’t.

Yep. That would be the right thing to do,

Suresh, chairs - what's the best way forward here? Would it be a good idea to present this document at the 6man slot in Montreal to solicit input from other participants and see if together we can come up with better text?

I’d rather not wait till the Montreal meeting if we can make progress on this document before then. I will have a discussion with the ipwave/6man chairs and the document editor to work out a way forward

Regards
Suresh

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 16 May 2018 17:35:14 +0000

That's de
finitely
the wise
 recommendation Suresh.

Thank you.

Best regards
Nabil

On Wed, May 16, 2018, 16:38 Suresh Krishnan <[email-masked]> wrote:

> Hi Lorenzo,
>
> On May 14, 2018, at 9:41 PM, Lorenzo Colitti <[email-masked]> wrote:
>
> unambiguously documents what works and what doesn’t.
>
>
> I’d rather not wait till the Montreal meeting if we can make progress on
> this document before then. I will have a discussion with the ipwave/6man
> chairs and the document editor to work out a way forward
>
> Regards
> Suresh
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 May 2018 17:40:33 -0700

Dumb question: do we have a proof of concept or reference implementation of the interface?

> On May 16, 2018, at 9:37 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Lorenzo,
> 
>> On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter <[email-masked]> wrote:

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 May 2018 10:12:35 +0200

Hi,

Implementation is an essential question.

Yes, there are several prototypes demonstrating IPv6-over-OCB, some even 
on the road.  There are plans do do more.  There are many packet dumps 
of IPv6-over-OCB available upon request, from various places (Spain, New 
York, Grenoble, more).

There was some experimentation during a recent Hackathon with some IETF 
participants about IPv6-over-OCB on cheap WiFi cards on OCB mode.  I 
would like to learn more about what happened there.

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 17 May 2018 09:52:58 +0000

Dear All,

During the last AIS'18 in Dakar, we organized a Hackathon. There were 3
tracks and I was the facilitator for the IPwave track.

We installed different types of wireless cards that work in OCB mode namely:

Model WLE200NX

Model Fenvi FV8302

We have patched the kernel with the patch available here (but got some
error/warning messages):

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

We got stuck with 5,9 GHz but participants were able to enable the 5.8
Ghz in OCB mode.

I still need to test once again the available patch and use another card,
namely (R11e-5HnD).

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

On Thu, May 17, 2018 at 8:12 AM, Alexandre Petrescu <
[email-masked]> wrote:

> on the road.  There are plans do do more.  There are many packet dumps of
> IPv6-over-OCB available upon request, from various places (Spain, New York,
> Grenoble, more).
>
> participants about IPv6-over-OCB on cheap WiFi cards on OCB mode.  I would
> like to learn more about what happened there.
>
> Alex
>
>
>>>> If that's true then that means this document does not actually specify
>>>> a feasible scheme to implement IPv6 over this network type. As such,
>>>> perhaps the 6man WG should recommend that this document should not be
>>>> published until it either documents a working specification or at least
>>>> clearly and unambiguously documents what works and what doesn’t.
>>>>
>>>
>>>> Suresh, chairs - what's the best way forward here? Would it be a good
>>>> idea to present this document at the 6man slot in Montreal to solicit input
>>>> from other participants and see if together we can come up with better text?
>>>>
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 May 2018 12:05:20 +0200

Le 17/05/2018 à 11:52, Nabil Benamar a écrit :
> Dear All,
>
> During the last AIS'18 in Dakar, we organized a Hackathon. There were 
> 3 tracks and I was the facilitator for the IPwave track.
>
> <https://mailarchive.ietf.org/arch/msg/its/q_r_4YLCadfilc89kIhLuHwuCiw>
>
> I still need to test once again the available patch and use another 
> card, namely (R11e-5HnD).

Hello,

I am very happy to hear that.  We can help you to set the cards at the 
right frequency.

For the Fenvi8302 - its specification on the web seems to be saying it 
can go up to max 5.85GHz 
(https://www.newegg.com/Product/Product.aspx?Item=0XM-00JK-00006). 
Generally speaking, the common parlance "5GHz"  can mean several very 
different bands: at ~5.4 and ~5.8 GHz it is still a wireless LAN, like 
on a desk, inside a building.  At approx. 5.9GHz it is however 
Intelligent Transportation Systems: outdoors, in cars, on roads, etc.  
The patch referred above, and the iw command, can not put a card at 
5.9GHz if the card itself can not run at that frequency - it's a matter 
of antenna size and other Radio Frequency specific electronics inside 
the card.

For the R11e-5HnD: if you ever make it work at 5.9GHz, and in OCB mode, 
and put IP on it: I can assure you it will be a first time ever: IPv6 at 
1GBps on roads :-)
(compared to mostly 16mbit/s used today at 5.9GHz in OCB mode in most 
deployments).

Alex

>
>
>
>
>
>
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
>
>
>
>
>
>
> On Thu, May 17, 2018 at 8:12 AM, Alexandre Petrescu 
>     Yes, there are several prototypes demonstrating IPv6-over-OCB,
>     some even on the road.  There are plans do do more.  There are
>     many packet dumps of IPv6-over-OCB available upon request, from
>     various places (Spain, New York, Grenoble, more).
>
>     There was some experimentation during a recent Hackathon with some
>     IETF participants about IPv6-over-OCB on cheap WiFi cards on OCB
>     mode.  I would like to learn more about what happened there.
>
>     Alex
>
>
>             On May 16, 2018, at 9:37 AM, Suresh Krishnan
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hi Lorenzo,
>
>                 On May 14, 2018, at 9:41 PM, Lorenzo Colitti
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 On Tue, May 15, 2018 at 9:08 AM Brian E Carpenter
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>                 If that's true then that means this document does not
>                 actually specify a feasible scheme to implement IPv6
>                 over this network type. As such, perhaps the 6man WG
>                 should recommend that this document should not be
>                 published until it either documents a working
>                 specification or at least clearly and unambiguously
>                 documents what works and what doesn’t.
>
>
>                 Suresh, chairs - what's the best way forward here?
>                 Would it be a good idea to present this document at
>                 the 6man slot in Montreal to solicit input from other
>                 participants and see if together we can come up with
>                 better text?
>
>
>             I’d rather not wait till the Montreal meeting if we can
>             make progress on this document before then. I will have a
>             discussion with the ipwave/6man chairs and the document
>             editor to work out a way forward
>
>             Regards
>             Suresh
>
>             [email-masked] <mailto:[email-masked]>
>             Administrative Requests:
>             <https://www.ietf.org/mailman/listinfo/ipv6>
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests:
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 17 May 2018 11:53:42 +0000

More details about the hackathon here:

http://hackathon.internetsummitafrica.org/

Best regards
Nabil

On Thu, May 17, 2018, 10:05 Alexandre Petrescu <[email-masked]>
wrote:

> For the Fenvi8302 - its specification on the web seems to be saying it can
> go up to max 5.85GHz (
> https://www.newegg.com/Product/Product.aspx?Item=0XM-00JK-00006).
> different bands: at ~5.4 and ~5.8 GHz it is still a wireless LAN, like on a
> desk, inside a building.  At approx. 5.9GHz it is however Intelligent
> Transportation Systems: outdoors, in cars, on roads, etc.  The patch
> referred above, and the iw command, can not put a card at 5.9GHz if the
> card itself can not run at that frequency - it's a matter of antenna size
> and other Radio Frequency specific electronics inside the card.
>
>>>> I’d rather not wait till the Montreal meeting if we can make progress
>>>> on this document before then. I will have a discussion with the ipwave/6man