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

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Apr 2018 03:21:50 +0000

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

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. 

Thanks
Suresh

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Apr 2018 17:42:21 +0900

On Thu, Apr 19, 2018 at 12:21 PM, Suresh Krishnan <[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
>
> 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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Apr 2018 11:11:44 +0200

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>
>
>     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.
>
>
> 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: Sat, 21 Apr 2018 12:21:06 +0900

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]> wrote:

> 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.
>
>   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?
>   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).
> - 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: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Apr 2018 14:12:28 +1200

> case, then the document should clearly state it.

The draft seems to say that even if address assignment succeeds,
neighbour discovery won't work, since multicast doesn't work either:
" In OCB, the link layer
 does not ensure that all associated members receive all messages,
 because there is no association operation."
I agree with Lorenzo: this doesn't make sense. RFC4861 works on
media that support multicast, and apparently 802.11-OCB doesn't
support multicast. So we need to be told how neighbours are
discovered, preferably before the next traffic light turns red.
Saying it's out of scope won't do.

It is also very odd that RFC4862 is not cited. I assume DAD
will fail for the same reason as ND.

The statement "IPv6 works fine directly over 802.11-OCB" seems
to be fake news. Sending unicast packets to a known MAC address
may work fine, but that is not even half the story.

   Brian

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Apr 2018 13:22:35 +0200

Hi Lorenzo,

Thanks for the message.

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"

YEs, it says so.

> and "on this link type, IPv6 ND is unspecified".

Well, the draft says "The operation of ND over 802.11-OCB is not
specified in this document."  It does not say "on this link type, IPv6
ND is unspecified".

The operation of ND over 802.11-OCB could be laid in another document.
That document could specify the values for ReachableTime and
RetransTimer of ND.

What do you think?

> 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.

No, that is not the case.

IPv6 over 802.11 OCB does use NS and NA for IP-MAC address mapping.  It
works.

Maybe we should say: "ND over 802.11 OCB works, but the precise values
of variables ReachableTime and RetransTimer have not been identified".

What do you think?

Alex

> 
> On Fri, Apr 20, 2018 at 6:11 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> Hi Lorenzo,
> 
>> On Thu, Apr 19, 2018 at 12:21 PM, Suresh Krishnan 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 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
>> 
>> 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.
> 
>  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)?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Apr 2018 08:59:29 +1200

> 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. If so this is an NBMA network and normal ND does not work.

    Brian