Subject: Re: I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jun 2018 08:46:28 +1200

Hi,

>    The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB
>    links is different than over 802.11 links.  In OCB, the link layer
>    does not ensure that all associated members receive all messages,
>    because there is no association operation.  Neighbor Discovery (ND)
>    is used over 802.11-OCB.

It's different and not all members receive all multicasts? Since ND
assumes that nodes receive multicasts, *how* is it used? Since there
is no reference, does ND actually mean RFC4861? If not, where is the
appropriate form of ND (that does not rely on multicasts) defined?

> 4.5.  Stateless Autoconfiguration
> 
>    The Interface Identifier for an 802.11-OCB interface is formed using
>    the same rules as the Interface Identifier for an Ethernet interface;
>    this is described in section 4 of [RFC2464].  No changes are needed,
>    but some care must be taken when considering the use of the Stateless
>    Address Auto-Configuration procedure.

RFC2464 is no longer the recommended method of IID formation. Also,
since there is no reference to RFC4862, where is the appropriate form
of SLAAC (that does not rely on multicasts) defined?

Regards
   Brian

On 16/06/2018 04:14, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF.
> 
>         Title           : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
>         Authors         : Alexandre Petrescu
>                           Nabil Benamar
>                           Jerome Haerri
>                           Jong-Hyouk Lee
>                           Thierry Ernst
> 	Filename        : draft-ietf-ipwave-ipv6-over-80211ocb-24.txt
> 	Pages           : 39
> 	Date            : 2018-06-15
> 
> Abstract:
>    In order to transmit IPv6 packets on IEEE 802.11 networks running
>    outside the context of a basic service set (OCB, earlier "802.11p")
>    there is a need to define a few parameters such as the supported
>    Maximum Transmission Unit size on the 802.11-OCB link, the header
>    format preceding the IPv6 header, the Type value within it, and
>    others.  This document describes these parameters for IPv6 and IEEE
>    802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
>    similarly to other known 802.11 and Ethernet layers - by using an
>    Ethernet Adaptation Layer.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-24
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-24
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 15 Jun 2018 22:16:50 +0000

Hi Brian,

Which RFC is now the recommended method of IID formation? Are you
suggesting to use rfc8064 (still a proposed standard) instead of RFC2464?

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

On Fri, Jun 15, 2018 at 8:46 PM Brian E Carpenter <
[email-masked]> wrote:

> >         Title           : Transmission of IPv6 Packets over IEEE 802.11
> Networks operating in mode Outside the Context of a Basic Service Set
> (IPv6-over-80211-OCB)
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jun 2018 11:07:54 +1200

> suggesting to use rfc8064 (still a proposed standard) instead of RFC2464?

Of course. It updates RFC2464 and many other IPv6-over-foo standards.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Jun 2018 11:42:33 +0200

Brian,
Thank you very much for the emessage.  I agree with you we could clarify.

Le 15/06/2018 à 22:46, Brian E Carpenter a écrit :
> Hi,
> 
>> The operation of the Neighbor Discovery protocol (ND) over
>> 802.11-OCB links is different than over 802.11 links.  In OCB, the
>> link layer does not ensure that all associated members receive all
>> messages, because there is no association operation.  Neighbor
>> Discovery (ND) is used over 802.11-OCB.
> 

ND assumes that IPv6 multicast addresses are implemented, but does not
assume that nodes always receive multicasts.  ND is more like UDP rather 
than like TCP.  ND has this NUD procedure when something may go wrong. 
ND implementations often send 2 or 3 redundant messages of same content,
just to be sure.

The fact that the link layer does not ensure that all nodes receive
multicasts is not a problem for ND.  In WiFi too some times packets are 
lost, despite being in mode 'associated', yet ND works ok there too.

I propose this change:

OLD:
> The operation of the Neighbor Discovery protocol (ND) over
> 802.11-OCB links is different than over 802.11 links.  In OCB, the
> link layer does not ensure that all associated members receive all
> messages, because there is no association operation.  Neighbor
> Discovery (ND) is used over 802.11-OCB.

NEW:
> The operation of the Neighbor Discovery protocol (ND) over
> 802.11-OCB links is similar as over 802.11 links.  In OCB, even if
> the link layer does not ensure that all associated members receive
> all messages, because there is no association operation, Neighbor
> Discovery (ND) is used over 802.11-OCB.

Do you disagree?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Jun 2018 11:43:11 +0200

[...]
>> The Interface Identifier for an 802.11-OCB interface is formed 
>> using the same rules as the Interface Identifier for an Ethernet 
>> interface; this is described in section 4 of [RFC2464].  No
>> changes are needed, but some care must be taken when considering
>> the use of the Stateless Address Auto-Configuration procedure.
> 
> RFC2464 is no longer the recommended method of IID formation.

What is now the recommended method of IID formation?  Do you think of
RFC8064 "Recommendation of Stable IPv6 Interface Identifiers"?

(as an aside, we do refer to RFC8064 in section 4.3 "Link-Local 
Addresses", conditioned by a 'need').

> Also, since there is no reference to RFC4862, where is the 
> appropriate form of SLAAC (that does not rely on multicasts) 
> defined?

If we see what is the recommended method of IID formation that you mean, 
then I will quickly propose text and that text will refer to RFC4862.

(as an aside, yes, it seems there to be an error: lack of ref to rfc4862 
"slaac"; or maybe it is not an error, thinking of places where I use 
IPv6-over-OCB between cars and rfc4862 is not used).

Alex

> Regards Brian
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories. This draft is a work item of the IP Wireless Access
>> in Vehicular Environments WG of the IETF.
>> 
>> Networks operating in mode Outside the Context of a Basic Service 
>> Set (IPv6-over-80211-OCB) Authors         : Alexandre Petrescu 
>> Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename :
>> draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Pages           : 39 
>> Date            : 2018-06-15
>> 
>> Abstract: In order to transmit IPv6 packets on IEEE 802.11
>> networks running outside the context of a basic service set (OCB,
>> earlier "802.11p") there is a need to define a few parameters such
>> as the supported Maximum Transmission Unit size on the 802.11-OCB
>> link, the header format preceding the IPv6 header, the Type value
>> within it, and others.  This document describes these parameters
>> for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of
>> IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet
>> layers - by using an Ethernet Adaptation Layer.
>> 
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-24
Please note that it may take a couple of minutes from the time of
submission
>> _______________________________________________ I-D-Announce 
>> mailing list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft 
>> directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Ole Troan <[email-masked]>
Date: Sat, 16 Jun 2018 11:55:04 +0200

> On 16 Jun 2018, at 11:42, Alexandre Petrescu <[email-masked]> wrote:
> 
> assume that nodes always receive multicasts.  ND is more like UDP rather than like TCP.  ND has this NUD procedure when something may go wrong. ND implementations often send 2 or 3 redundant messages of same content,
> just to be sure.
> 
> multicasts is not a problem for ND.  In WiFi too some times packets are lost, despite being in mode 'associated', yet ND works ok there too.

And DAD?

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Jun 2018 12:07:22 +0200

>> multicasts is not a problem for ND.  In WiFi too some times packets are lost, despite being in mode 'associated', yet ND works ok there too.

Yes, Duplicate Address Detection is a procedure part of ND.

DAD works OCB as it works on WiFi.

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Sat, 16 Jun 2018 10:08:17 +0000

What we have said about ND is applicable for DAD!

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

On Sat, Jun 16, 2018 at 9:55 AM Ole Troan <[email-masked]> wrote:

> than like TCP.  ND has this NUD procedure when something may go wrong. ND
> implementations often send 2 or 3 redundant messages of same content,
> > just to be sure.
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Sat, 16 Jun 2018 12:40:02 +0200

> On 16 Jun 2018, at 12:08, Nabil Benamar <[email-masked]> wrote:
> 

How so, given that DAD depends on reliable multicast delivery to all nodes to function?

Cheers 
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Jun 2018 14:23:13 +0200

Le 16/06/2018 à 12:40, Ole Troan a écrit :
> 
> 
> On 16 Jun 2018, at 12:08, Nabil Benamar <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Is DAD working on WiFi?

Alex

> 
> Cheers
> Ole
> 
> 
>>
>>
>> Best regards
>> Nabil Benamar
>> -------------------
>> نبيل بنعمرو
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>     > On 16 Jun 2018, at 11:42, Alexandre Petrescu
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     >
>>     > assume that nodes always receive multicasts.  ND is more like
>>     UDP rather than like TCP.  ND has this NUD procedure when
>>     something may go wrong. ND implementations often send 2 or 3
>>     redundant messages of same content,
>>     > just to be sure.
>>     >
>>     > multicasts is not a problem for ND.  In WiFi too some times
>>     packets are lost, despite being in mode 'associated', yet ND works
>>     ok there too.
>>
>>     And DAD?
>>
>>     Ole
>>     [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Jun 2018 13:47:08 +1200

>> How so, given that DAD depends on reliable multicast delivery to all 

Only to the extent that WiFi implements multicast (which is also
true for switched Ethernet). The underlying question here is how
does OCB implement multicast, given that nodes are unregistered
and that radio-frequency barriers between nodes may be normal.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 17 Jun 2018 10:28:30 +0200

Le 17/06/2018 à 03:47, Brian E Carpenter a écrit :
> Only to the extent that WiFi implements multicast (which is also true
> for switched Ethernet).

OCB implements multicast as WiFi and Ethernet does: it offers link-layer
multicast addresses.

I am not aware of some WiFi that does implement link-layer multicast,
and other WiFi that does not implement multicast?

I am aware of some WiFi which, at some point, did not implement
link-layer multicast addressing.  YEt, most WiFi I work with recently
did implement link-layer multicast addressing.

> The underlying question here is how does OCB implement multicast,
> given that nodes are unregistered and that radio-frequency barriers
> between nodes may be normal.

That is a good question.

At this time, I think that in OCB all messages sent to 33:33::1 (a 
link-layer multicast address signifying "all nodes") are sent to all 
nodes that are on the same channel, without necessarily being associated.

In OCB mode, I did not see a need for making distinction between groups 
of nodes on the same link (like IPv6 'all-nodes' vs 'all-hosts' vs 
'all-routers').

I did set up OCB links in vehicle-to-vehicle mode (group of IP Routers 
on same OCB link), and also OCB links in vehicles-to-Road-Side-Unit mode 
(group of IP Hosts and one IP Router on same OCB link).

At the same time, I do agree that whereas there are link-layer specific 
multicast addresses (e.g. 33:33::1) there are no link-layer specific 
messages (e.g. a link layer equivalent of IP MLD Report message).  But 
that lack of link-layer multicast functionality (no link-layer multicast 
messages) is also present in WiFi, Ethernet and in OCB mode.  When IEEE 
makes these messages, IP-over-OCB will take advantage of it.

I do not think that this latter lack of link-layer multicast messages is 
a hurdle in making IPv6 work on OCB links today.

Alex

> 
> Brian
> 
>> Alex
>> 
>>> 
>>> Cheers Ole
>>> 
>>> 
>>>> 
>>>> 
>>>> Best regards Nabil Benamar ------------------- نبيل بنعمرو
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sat, Jun 16, 2018 at 9:55 AM Ole Troan
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> ND assumes that IPv6 multicast addresses are implemented,
>>>>> but
>>>> does not
>>>>> The fact that the link layer does not ensure that all nodes
>>>>> receive multicasts is not a problem for ND.  In WiFi too some
>>>>> times
>>>> packets are lost, despite being in mode 'associated', yet ND
>>>> works ok there too.
>>>> 
>>>> And DAD?
>>>> 
>>>> Ole 
>>>> [email-masked] <mailto:[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: François Simon <[email-masked]>
Date: Sun, 17 Jun 2018 08:27:29 -0400

"At this time, I think that in OCB all messages sent to 33:33::1 (a link-layer multicast address signifying "all nodes") are sent to all nodes that are on the same channel, without necessarily being associated."

Address 1 (Destination) = ff ff ff ff ff ff
Address 2 (source) = random 6 octets
Address 3 (BSS ID) = ff ff ff ff ff ff
Address 4 omitted

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Sunday, June 17, 2018 4:29 AM
To: Brian E Carpenter <[email-masked]>; Ole Troan <[email-masked]>; Nabil Benamar <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND

> Only to the extent that WiFi implements multicast (which is also true 

OCB implements multicast as WiFi and Ethernet does: it offers link-layer multicast addresses.

I am not aware of some WiFi that does implement link-layer multicast, and other WiFi that does not implement multicast?

I am aware of some WiFi which, at some point, did not implement link-layer multicast addressing.  YEt, most WiFi I work with recently did implement link-layer multicast addressing.

That is a good question.

At this time, I think that in OCB all messages sent to 33:33::1 (a link-layer multicast address signifying "all nodes") are sent to all nodes that are on the same channel, without necessarily being associated.

In OCB mode, I did not see a need for making distinction between groups of nodes on the same link (like IPv6 'all-nodes' vs 'all-hosts' vs 'all-routers').

I did set up OCB links in vehicle-to-vehicle mode (group of IP Routers on same OCB link), and also OCB links in vehicles-to-Road-Side-Unit mode (group of IP Hosts and one IP Router on same OCB link).

At the same time, I do agree that whereas there are link-layer specific multicast addresses (e.g. 33:33::1) there are no link-layer specific messages (e.g. a link layer equivalent of IP MLD Report message).  But that lack of link-layer multicast functionality (no link-layer multicast
messages) is also present in WiFi, Ethernet and in OCB mode.  When IEEE makes these messages, IP-over-OCB will take advantage of it.

I do not think that this latter lack of link-layer multicast messages is a hurdle in making IPv6 work on OCB links today.

Alex

>>>> UDP rather than like TCP.  ND has this NUD procedure when something 
>>>> may go wrong. ND implementations often send 2 or 3 redundant 
>>>> messages of same content,
>>>>> just to be sure.
>>>>> 
>>>> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> Administrative Requests:
>> IETF IPv6 working group mailing list [email-masked] <mailto:[email-masked]>  Administrative

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 17 Jun 2018 17:31:28 +0200

Le 17/06/2018 à 14:27, François Simon a écrit :
> "/At this time, I think that in OCB all messages sent to 33:33::1 (a 
> nodes that are on the same channel, without necessarily being 
> associated.//"///
> 
> //
> 
> Address 2 (source) = random 6octets
> 

Thank you for the example.

That ffffffffffff is for a message that is not IPv6.  I suppose it is 
extracted from a BSM or other WSM or 1609 message?

For a message that is IPv6, e.g. an IPv6 ICMPv6 Router Solicitation, the 
Destination MAC address and the Receiver MAC address are both 33:33::2 
(all-hosts).  (see packet capture attached).  I dont have a packet 
capture at hand that shows 33:33::1.

This 33:33::2 is the same in OCB mode and in ICB mode if I can say so 
(ICB: _Inside_ de Context of a BSSID, or otherwise just WiFi).

Alex

> To: Brian E Carpenter <[email-masked]>; Ole Troan 
> <[email-masked]>; Nabil Benamar <[email-masked]>
> Subject: Re: [ipwave] I-D Action: 
> draft-ietf-ipwave-ipv6-over-80211ocb-24.txt - ND
> 
>>>> How so, given that DAD depends on reliable multicast delivery to all 
> 
>>>> nodes to function?
> 
>>> 
> 
>>> Is DAD working on WiFi?
> 
>> 
> 
>>>>> Best regards Nabil Benamar -------------------نبيلبنعمرو
> 
>>>>> 
> 
>>>>> 
> 
>>>>> 
> 
>>>>> 
> 
>>>>> 
> 
>>>>> 
> 
>>>>> 
> 
>>>>>> ND assumes that IPv6 multicast addresses are implemented, but
> 
>>>>> does not
> 
>>>>> -------------------------------------------------------------------
> 
>>>>> -
> 
>>>>>
> 
>>>>> 
> 
>>>>>[email-masked]<mailto:[email-masked]><mailto:[email-masked]> Administrative 
> Requests:
> 
>>>>> -------------------------------------------------------------------
> 
>>>>> -
> 
>>>>>
> 
>>>
> 
>>>
> 
>>>>> 
> 
>>> IETF IPv6 working group mailing [email-masked]<mailto:[email-masked]>Administrative
> 
>>> Requests:https://www.ietf.org/mailman/listinfo/ipv6
> 
> [email-masked]<mailto:[email-masked]>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jun 2018 15:26:07 +0200

I am going to put this:

> the RECOMMENDED method for forming stable Interface Identifiers
> (IIDs) is described in <xref target='RFC8064'/>.  The method of
> forming IIDs described in section 4 of <xref target='RFC2064'/> MAY
> be used during transition time.

Remark RFC2464's "ff:fe" is MAY, during transition time.  Because there
are still many  kernels in the embedded world doing that.  I am afraid
ruling out something that is still in widespread use.

Alex

>>>> 802.11-OCB links is different than over 802.11 links.  In OCB,
>>>> the link layer does not ensure that all associated members
>>>> receive all messages, because there is no association
>>>> operation.  Neighbor Discovery (ND) is used over 802.11-OCB.
>>> 
>>> It's different and not all members receive all multicasts? Since
>>> ND assumes that nodes receive multicasts, *how* is it used? Since
>>> there is no reference, does ND actually mean RFC4861? If not,
>>> where is the appropriate form of ND (that does not rely on
>>> multicasts) defined?
>>> 
>>>> using the same rules as the Interface Identifier for an
>>>> Ethernet interface; this is described in section 4 of
>>>> [RFC2464].  No changes are needed, but some care must be taken
>>>> when considering the use of the Stateless Address
>>>> Auto-Configuration procedure.
>>> 
>>> directories.
>>>> This draft is a work item of the IP Wireless Access in
>>>> Vehicular
>>> Environments WG of the IETF.
>>>> 
>>> Set (IPv6-over-80211-OCB)
>>>> Authors         : Alexandre Petrescu Nabil Benamar Jerome
>>>> Haerri Jong-Hyouk Lee Thierry Ernst Filename        :
>>>> draft-ietf-ipwave-ipv6-over-80211ocb-24.txt Pages           :
>>>> 39 Date            : 2018-06-15
>>>> 
>>>> networks running outside the context of a basic service set
>>>> (OCB, earlier "802.11p") there is a need to define a few
>>>> parameters such as the supported Maximum Transmission Unit size
>>>> on the 802.11-OCB link, the header format preceding the IPv6
>>>> header, the Type value within it, and others.  This document
>>>> describes these parameters for IPv6 and IEEE 802.11-OCB
>>>> networks; it portrays the layering of IPv6 on 802.11-OCB 
>>>> similarly to other known 802.11 and Ethernet layers - by using
>>>> an Ethernet Adaptation Layer.
>>>> 
>>>> 
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or