Subject: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jul 2016 21:38:10 +0200

Hi,

During our discussion of IPv6 and MAC address multicast I laid down a 
few of comment results of the discussion on this email list, on this 
Internet Draft referred to below.

In my oppinion there is obviously a need to clarify how and what MAC 
multicast addresses to use below IPv6 in IPv6-over-802.11OCB (Out of the 
Context of BSSID, aka 802.11p).

Alex

-------- Message transféré --------
Sujet : [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt
Date : Fri, 8 Jul 2016 21:33:53 +0200
De : Alexandre Petrescu <[email-masked]>
Pour : [email-masked] <[email-masked]>

Hi,

I have just submitted this Internet Draft I co-author with Thierry Ernst.

The distinctive aspect is that it tries to suggest the way MAC and IPv6 
multicast is used on an IPv6-over-80211-OCB links.

Alex

-------- Message transféré --------
Sujet : I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt
Date : Fri, 8 Jul 2016 08:55:47 -0700
De : [email-masked]
Répondre à : [email-masked]
Pour : [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

          Title           : Transmission of IPv6 Packets over IEEE 
802.11-OCB Networks
          Authors         : Thierry Ernst
                            Alexandre Petrescu
	Filename        : draft-ernst-its-ipv6-over-80211ocb-00.txt
	Pages           : 5
	Date            : 2016-07-08

Abstract:
     In this document the mapping of multicast IPv6 addresses to MAC
     addresses of 802.11-OCB is proposed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-00

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

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

---

From: Owen DeLong <[email-masked]>
Date: Fri, 8 Jul 2016 20:12:03 -0700

I fail to see any reason that the mapping would be different in OCB vs. any other 802 style networking.

Owen

> On Jul 8, 2016, at 12:38 , Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> During our discussion of IPv6 and MAC address multicast I laid down a few of comment results of the discussion on this email list, on this Internet Draft referred to below.
> 
> In my oppinion there is obviously a need to clarify how and what MAC multicast addresses to use below IPv6 in IPv6-over-802.11OCB (Out of the Context of BSSID, aka 802.11p).
> 
> Alex
> 
> The distinctive aspect is that it tries to suggest the way MAC and IPv6 multicast is used on an IPv6-over-80211-OCB links.
> 
> Alex
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Transmission of IPv6 Packets over IEEE 802.11-OCB Networks
>         Authors         : Thierry Ernst
>                           Alexandre Petrescu
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jul 2016 11:55:20 +0200

First: which other 802 style networking?  802.3 Ethernet (rfc2464) or
802.11 WiFi (no RFC)?  Destination prefix 33- or 01-?

Second: OCB mode of 802.11 is different than other 802.11bgn/ac/ad.  For
example, a link scope in 802.11bgn/ac/ad is clearly bound by the
Association operations: whoever associates to a BSSID is within that
link scope.  Sending one packet to an IP link-scope destination
naturally gets mapped into a multicast MAC address (be it prefixed by
33- or 01-).

But in Out-of-a-Context-of-a-BSSID mode there are no Association
operations; thus it's hard to say who is within link scope, and what
would an "all-nodes" multicast address mean when there is no scope and
no SSID.

Alex

Le 09/07/2016 à 05:12, Owen DeLong a écrit :
>> During our discussion of IPv6 and MAC address multicast I laid down
>> a few of comment results of the discussion on this email list, on
>> this Internet Draft referred to below.
>>
>> In my oppinion there is obviously a need to clarify how and what
>> MAC multicast addresses to use below IPv6 in IPv6-over-802.11OCB
>> (Out of the Context of BSSID, aka 802.11p).
>>
>> Alex
>>
>> -------- Message transféré -------- Sujet : [its] Fwd: I-D Action:
>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016
>> 21:33:53 +0200 De : Alexandre Petrescu
>> <[email-masked]> Pour : [email-masked] <[email-masked]>
>>
>> Hi,
>>
>> The distinctive aspect is that it tries to suggest the way MAC and
>> IPv6 multicast is used on an IPv6-over-80211-OCB links.
>>
>> Alex
>>
>>
>> -------- Message transféré -------- Sujet : I-D Action:
>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016
>> 08:55:47 -0700 De : [email-masked] Répondre à :
>> [email-masked] Pour : [email-masked]
>>
>>
>> Title           : Transmission of IPv6 Packets over IEEE 802.11-OCB
>> Networks Authors         : Thierry Ernst Alexandre Petrescu
>> Filename        : draft-ernst-its-ipv6-over-80211ocb-00.txt Pages
>> : 5 Date            : 2016-07-08
>>
>> Abstract: In this document the mapping of multicast IPv6 addresses
>> to MAC addresses of 802.11-OCB is proposed.
>>
>>
There's also a htmlized version available at:
>> 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.
>>
>> _______________________________________________ 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
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 11 Jul 2016 19:47:42 +0900

> would an "all-nodes" multicast address mean when there is no scope and

Can "all nodes" be anything other than "best effort" in these
networks?  Akin to "everyone within the sound of my voice and this
particular moment"?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jul 2016 13:49:42 +0200

Le 11/07/2016 à 12:47, Erik Kline a écrit :
>> operations; thus it's hard to say who is within link scope, and
>> what would an "all-nodes" multicast address mean when there is no
>> scope and no SSID.
>

I think there could be a scope within an approximate radio range around
an emitter, during a precise time.

But such scope would not be named like the current "link" scope valid in
a precise ESSID association, during an approximate time length between
association and disassociation.

Then the existing "all-nodes" id could live within this yet-unnamed
scope as it lives within link-scope, or site-scope, or global-scope.

Alex

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 11 Jul 2016 15:06:21 +0000

OK, the chairs are looking for interest from the operators. Speak up, folks!

> On Jul 8, 2016, at 12:38 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 11 Jul 2016 17:15:05 +0200

Hi,

> OK, the chairs are looking for interest from the operators. Speak up, folks!

As far as I can see, IPv6-to-MAC mapping is defined well enough.

Reading the discussion (not having looked into the draft yet, the discussion
was weird enough), I see severe disconnection between reality and this 
discussion.

A document that clarifies the relationship between IEEE and IANA/IETF
regarding MAC address assignment, having pointers to the relevant documents
might be a better use of our time.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 11 Jul 2016 20:03:26 +0000

> On Jul 11, 2016, at 2:55 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11?

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jul 2016 13:20:10 +0200

Le 11/07/2016 à 22:03, Fred Baker (fred) a écrit :
>> First: which other 802 style networking?  802.3 Ethernet (rfc2464)
>> or 802.11 WiFi (no RFC)?  Destination prefix 33- or 01-?
>

Fred,

After quickly skimming through it, the idea of mapping IP fields in
802.11 QoS fields as proposed in the above draft seem attractive to an
IPv6-over-80211-OCB setting too.

Use-cases in vehicular networks do pertain to such differentiation.  For
example an ambulance sending priority presence messages to all vehicles
to make place.

Some trials of vehicular networks in US make use of IEEE 802.11 QoS
Headers (shown in a public website), although they dont yet employ IPv6
networking protocols.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jul 2016 03:32:50 +1200

> IPv6-over-80211-OCB setting too.

That particular wheel certainly only needs inventing once.

> example an ambulance sending priority presence messages to all vehicles

However, don't fall into the trap of believing that IP diffserv is priority-
based. It is more subtle than that.

   Brian

---

From: Baptiste Jonglez <[email-masked]>
Date: Thu, 14 Jul 2016 11:49:52 +0200

> would an "all-nodes" multicast address mean when there is no scope and

This sounds a lot like the ad-hoc mode for regular 802.11, or even Power
Line Communication.  In terms of reachability, these layer-2 links are
generally not transitive (and may not be symmetric either).

There is some previous work: MANET, "mesh-under" vs. "route-over"
architecture [1], Babel [2].

Basically, the sanest way is to define the scope of a link as the set of
nodes reachable via radio broadcast.  You then have to deal with the fact
that this set will change over time (see Babel for unicast dynamic
routing).

I don't see why you would need to change the semantic of multicast
addresses, in particular "all-nodes".  It represents all nodes on the
layer-2 link, and this set can always change over time (even in classical
wired links, where nodes can come and go and bridges can fail).

Baptiste

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.188.2437
[2] https://datatracker.ietf.org/wg/babel/documents/

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jul 2016 18:55:49 +0200

Le 14/07/2016 à 11:49, Baptiste Jonglez a écrit :
>> Second: OCB mode of 802.11 is different than other 802.11bgn/ac/ad.
>> For example, a link scope in 802.11bgn/ac/ad is clearly bound by
>> the Association operations: whoever associates to a BSSID is within
>> that link scope.  Sending one packet to an IP link-scope
>> destination naturally gets mapped into a multicast MAC address (be
>> it prefixed by 33- or 01-).
>>
> This sounds a lot like the ad-hoc mode for regular 802.11, or even
> Power Line Communication.

Yes it sounds a lot like ad-hoc mode.  Both OCB and ad-hoc mode are
"unmanaged".  But OCB is even further relieved from structure.

In ad-hoc mode there is still separation - there is association
messaging, and once in an ad-hoc ESSID (the "MAC address" of the ad-hoc
"cell"), nodes dont here other stations on other ESSIDs.

In OCB there is no such separation at all: everybody hears everybody
else in the same channel.

> In terms of reachability, these layer-2 links are generally not
> transitive (and may not be symmetric either).

YEs.

> architecture [1], Babel [2].

YEs, but it is not satisfactory in vehicular reasons for many other reasons.

> Basically, the sanest way is to define the scope of a link as the set
> of nodes reachable via radio broadcast.  You then have to deal with
> the fact that this set will change over time (see Babel for unicast
> dynamic routing).

Such scope can make sense, but it is still dependent on the user.

There is a different scope for each user.

On another hand, a link scope in AP-mode or ad-hoc mode is the scope 
covering that ESSID: a link scope is different for each ESSID (not 
different for each user).

The fact that within AP-mode or ad-hoc mode link scope some hosts can 
not see each other (non transitivity: A sees B sees C doesnt mean A sees 
C) is commonly understood as a configuration problem: one is not 
supposed to build networks with only one ESSID bigger than the WiFi 
radio range.

To solve this non-transitivity problem in AP-mode or ad-hoc mode one 
should define an "ESSID scope" (not a link scope).  At that point we 
talk about nodes in ESSID scope are agreed to be non-transitive.  And 
routers to forward between link scopes but within same ESSID scope.

But that is not my problem here.  It is an IPv6-over-80211 problem in 
the first place.  And we dont have such an RFC.

My problem here is the scope for OCB-mode, which has no ESSID.

> addresses, in particular "all-nodes".  It represents all nodes on
> the layer-2 link, and this set can always change over time (even in
> classical wired links, where nodes can come and go and bridges can
> fail).

Noted but non implementable.

The "all nodes" Group ID is defined to be able to live within link scope 
(ff02::1), site scope (ff0X::1) and more other scopes.

Nodes that come and go from link scopes can indeed be managed but _only_ 
if we have a solid scope.

In 802.11 there are no bridges (yes there are bridges between 802.11 and 
802.3 but not between different 802.11 ESSIDs).

Alex

>>>> During our discussion of IPv6 and MAC address multicast I laid
>>>> down a few of comment results of the discussion on this email
>>>> list, on this Internet Draft referred to below.
>>>>
>>>> In my oppinion there is obviously a need to clarify how and
>>>> what MAC multicast addresses to use below IPv6 in
>>>> IPv6-over-802.11OCB (Out of the Context of BSSID, aka
>>>> 802.11p).
>>>>
>>>> Alex
>>>>
>>>> -------- Message transféré -------- Sujet : [its] Fwd: I-D
>>>> Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8
>>>> Jul 2016 21:33:53 +0200 De : Alexandre Petrescu
>>>> The distinctive aspect is that it tries to suggest the way MAC
>>>> and IPv6 multicast is used on an IPv6-over-80211-OCB links.
>>>>
>>>> Alex
>>>>
>>>>
>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul
>>>> 2016 08:55:47 -0700 De : [email-masked] Répondre à :
>>>> 802.11-OCB Networks Authors         : Thierry Ernst Alexandre
>>>> Petrescu Filename        :
>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date
>>>> : 2016-07-08
>>>>
>>>> Abstract: In this document the mapping of multicast IPv6
>>>> addresses to MAC addresses of 802.11-OCB is proposed.
>>>>
>>>>
>>>> submission until the htmlized version and diff are available
>>>> at tools.ietf.org.
>>>>
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>> _______________________________________________ its mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Thu, 14 Jul 2016 10:06:26 -0700

> Such scope can make sense, but it is still dependent on the user.

This is an inevitable consequence of your design decision to use OCB.

> On another hand, a link scope in AP-mode or ad-hoc mode is the scope covering that ESSID: a link scope is different for each ESSID (not different for each user).

That is a property difference between OCB and ESSID modes of operation. It has nothing to do with IP or the IP concept of a link.

> The fact that within AP-mode or ad-hoc mode link scope some hosts can not see each other (non transitivity: A sees B sees C doesnt mean A sees C) is commonly understood as a configuration problem: one is not supposed to build networks with only one ESSID bigger than the WiFi radio range.

Or if one, does, one is expected to provide transitivity between APs sharing the same ESSID to overcome this.

However, in OCB mode, you don’t have those facilities, so your link is limited to being different for east combination of station, time, position, and relative position of other stations as well as propagation factors.

> To solve this non-transitivity problem in AP-mode or ad-hoc mode one should define an "ESSID scope" (not a link scope).  At that point we talk about nodes in ESSID scope are agreed to be non-transitive.  And routers to forward between link scopes but within same ESSID scope.

This is completely illogical and is not how any Wireless network I’ve worked with is implemented.

Instead, multiple APs are connected with the same ESSID using bridging and/or other technologies on the wired side to provide this transitivity. In some cases, there are also wireless protocols that can be used to extend an ESSID wirelessly between two or more APs, but these are obviously suboptimal due to spectrum utilization for forwarding between the APs.

However, none of this is relevant to your situation because of your design decision to use OCB.

> But that is not my problem here.  It is an IPv6-over-80211 problem in the first place.  And we dont have such an RFC.

Nor do we have an actual need for one as it is a problem which everyone so far solves at layer 2 using media adapters and bridging.

> My problem here is the scope for OCB-mode, which has no ESSID.

What is the problem? As you have mentioned, each user has a unique link scope.

If you don’t like that, don’t use OCB or don’t use link scope for your application(s).

> Noted but non implementable.

Why not?

> The "all nodes" Group ID is defined to be able to live within link scope (ff02::1), site scope (ff0X::1) and more other scopes.

Sure. Use the scope that best meets your needs.

> Nodes that come and go from link scopes can indeed be managed but _only_ if we have a solid scope.

What do you mean by solid scope? If nodes are arriving and departing from the scope, by definition, it lacks solidity from at least one perspective on the term.

> In 802.11 there are no bridges (yes there are bridges between 802.11 and 802.3 but not between different 802.11 ESSIDs).

Since you are not using ESSIDs to begin with, I’m not sure how that is relevant.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 18:54:35 +0200

Le 14/07/2016 à 19:06, Owen DeLong a écrit :
>>> There is some previous work: MANET, "mesh-under" vs.
>>> "route-over" architecture [1], Babel [2].
>>
>>> Basically, the sanest way is to define the scope of a link as the
>>> set of nodes reachable via radio broadcast.  You then have to
>>> deal with the fact that this set will change over time (see Babel
>>> for unicast dynamic routing).
>>

It is a wise decision in that OCB eliminates much messages and noise
which may provoke interference.  Interference is a risk in jams or high
relative speeds (e.g. mobile to infra, or mobile crossing another
mobile, but not mobile following a mobile).

That decision can not be questioned.

>> On another hand, a link scope in AP-mode or ad-hoc mode is the
>> scope covering that ESSID: a link scope is different for each ESSID
>> (not different for each user).
>
> That is a property difference between OCB and ESSID modes of
> operation. It has nothing to do with IP or the IP concept of a link.

Well.

The ND operation is specified with the full expectation that when an NS
is sent to the link-scope everybody in that link is supposed to be
willing to reply.

But in WiFi-adhoc and in 802-11-OCB for that matter, some hosts in link
scope will not even hear that NS.

This is not normal.  And it is unnormal because link scope is for wires,
not for 802.11-adhoc nor for 802.11-OCB.

>> The fact that within AP-mode or ad-hoc mode link scope some hosts
>> can not see each other (non transitivity: A sees B sees C doesnt
>> mean A sees C) is commonly understood as a configuration problem:
>> one is not supposed to build networks with only one ESSID bigger
>> than the WiFi radio range.
>

Such transitivity has never been provided meaningfully, other than
duplicating packets in the air, which means to generate more noise back
to the emitter.

> However, in OCB mode, you don’t have those facilities, so your link
> is limited to being different for east combination of station, time,
>  position, and relative position of other stations as well as
> propagation factors.

Look, not only OCB mode is different than wires, but 802.11-adhoc is
also different in this respect.  You can not single out OCB mode.

>> To solve this non-transitivity problem in AP-mode or ad-hoc mode
>> one should define an "ESSID scope" (not a link scope).  At that
>> point we talk about nodes in ESSID scope are agreed to be
>> non-transitive.  And routers to forward between link scopes but
>> within same ESSID scope.
>
> Instead, multiple APs are connected with the same ESSID using
> bridging and/or other technologies on the wired side to provide this
>  transitivity.

YEs but in some vehicular networks there is no wired side along the road 
(although almost often there is a wired side inside each vehicle).

One could not imagine bridging a single 'wildcard' ESSID between the 
outside of vehicles and throughout each distinct inside of vehicles. 
Whereas yes, this ESSID could be bridged between each vehicle and the 
wired side along the road (in the rare places where there are linked 
Road-Side Units along road).

> In some cases, there are also wireless protocols that can be used to
> extend an ESSID wirelessly between two or more APs, but these are
> obviously suboptimal due to spectrum utilization for forwarding
> between the APs.

I agree.

>> But that is not my problem here.  It is an IPv6-over-80211 problem
>>  in the first place.  And we dont have such an RFC.
>
> Nor do we have an actual need for one as it is a problem which
> everyone so far solves at layer 2 using media adapters and bridging.

Not in WiFi.

> What is the problem? As you have mentioned, each user has a unique

But in Ethernet the scope is not relative to a particular user - it is 
the scope of the wire if I can say so.

> If you don’t like that, don’t use OCB or don’t use link scope for

That's not an option.  In some vehicles 802.11-OCB is there built in.

>>> I don't see why you would need to change the semantic of
>>> multicast addresses, in particular "all-nodes".  It represents
>>> all nodes on the layer-2 link, and this set can always change
>>> over time (even in classical wired links, where nodes can come
>>> and go and bridges can fail).
>>
>> The "all nodes" Group ID is defined to be able to live within link
>>  scope (ff02::1), site scope (ff0X::1) and more other scopes.
>
> What do you mean by solid scope? If nodes are arriving and departing
>  from the scope, by definition, it lacks solidity from at least one
> perspective on the term.

I meant a solid scope definition.

The scope itself should be more ephemeral.  Hosts sending NS to that
scope would wait more than on a link scope before continuing.

>> In 802.11 there are no bridges (yes there are bridges between
>> 802.11 and 802.3 but not between different 802.11 ESSIDs).
>

Well in OCB there is one single 'wildcard' ESSID whose value is a string
of all 1s (not to be confused with the all 1s MAC broadcast address).
So an ESSID bridge would link together all in that 'wildcard' ESSID.

Alex

>
> Owen
>
>>
>> Alex
>>
>>>
>>> Baptiste
>>>
>>> [1]
>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.188.2437
>>>>> I fail to see any reason that the mapping would be different
>>>>>  in OCB vs. any other 802 style networking.
>>>>>
>>>>> Owen
>>>>>
>>>>>> During our discussion of IPv6 and MAC address multicast I
>>>>>> laid down a few of comment results of the discussion on
>>>>>> this email list, on this Internet Draft referred to below.
>>>>>>
>>>>>> In my oppinion there is obviously a need to clarify how
>>>>>> and what MAC multicast addresses to use below IPv6 in
>>>>>> Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date :
>>>>>> Fri, 8 Jul 2016 21:33:53 +0200 De : Alexandre Petrescu
>>>>>> The distinctive aspect is that it tries to suggest the way
>>>>>>  MAC and IPv6 multicast is used on an IPv6-over-80211-OCB
>>>>>> links.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8
>>>>>> Jul 2016 08:55:47 -0700 De : [email-masked]
>>>>>> Répondre à : [email-masked] Pour :
>>>>>> [email-masked]
>>>>>>
>>>>>>
>>>>>> 802.11-OCB Networks Authors         : Thierry Ernst
>>>>>> Alexandre Petrescu Filename        :
>>>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date :
>>>>>>  2016-07-08
>>>>>>
>>>>>> submission until the htmlized version and diff are
>>>>>> available at tools.ietf.org.
>>>>>>
>>>>>> I-D-Announce mailing list [email-masked]
>>>>>> _______________________________________________ its
>>>>>> mailing list [email-masked]
>>>>>> _______________________________________________ v6ops
>>>>>> mailing list [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jul 2016 10:41:11 -0700

> not for 802.11-adhoc nor for 802.11-OCB. 

Then either:
    - don't present the entire adhoc/OCB net as a single IPv6 "link"
        because you're not flooding NS
    - flood NS and support the requirements of what IPv6 considers a link

Joe

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Jul 2016 11:40:34 -0700

> On Jul 19, 2016, at 09:54 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Fair enough, but like any other decision, it has tradeoffs. Now, you are
here complaining about the tradeoffs inherent in that decision as if it
is somehow up to the IETF and/or IEEE to contort network standards to
address those inherent tradeoffs.

You’ve chosen a networking mechanism with an inherently amorphous definition
of link which is specific to each node. That is what it is and all the 
continued complaints about this will not change that nature. You must
address these issues in your higher level protocols because you have
made this choice.

> not for 802.11-adhoc nor for 802.11-OCB.

No, the ND is sent with the expectation that everyone reachable (that is,
everyone actually on link) will hear it. Since the ND is sent to the
“All Nodes On Link” multicast address, and the definition of “On Link”
is based on the ability to hear that packet, I think it is safe to take
that for granted.

Your complaint isn’t that in 802.11-OCB some hosts in link scope
won’t hear it. Your complaint is that the host that was in link
scope 200 milliseconds or even 20 milliseconds ago may not be on
link now, but may again be on link 20 milliseconds later.

Again, this is a tradeoff you have chosen in your decision to use
this particular networking mechanism.

It does not change the concept, definition, or properties of link-scope.
It simply makes it damn inconvenient for you to use it because of the
high rate of speed at which the definition of link-scope changes in your
particular operating environment.

> duplicating packets in the air, which means to generate more noise back

Either over the air or over a wire, yes. This is true. Those really are
the only two choices available.

Nonetheless, it has worked well in enough installations that I feel
comfortable saying it is a useful thing for many applications.

> also different in this respect.  You can not single out OCB mode.

802.11-adhoc has a somewhat different set of tradeoffs, but it is generally
treated as a point-to-point link or point-to-multipoint link from an
IPv6 perspective and this generally works just fine.

Most actual deployments of adhoc are done as point to point anyway.

> YEs but in some vehicular networks there is no wired side along the road (although almost often there is a wired side inside each vehicle).
> 
> One could not imagine bridging a single 'wildcard' ESSID between the outside of vehicles and throughout each distinct inside of vehicles. Whereas yes, this ESSID could be bridged between each vehicle and the wired side along the road (in the rare places where there are linked Road-Side Units along road).

Again, this is a tradeoff inherent in your particular design choices.
It is yours to deal with and does not require the layer three protocol
to make any special adaptation, rather, you must adapt either in your
higher layers or in providing adequate compensating facilities in the
lower layer network(s).

>> everyone so far solves at layer 2 using media adapters and bridging.

Yes, in WiFi… Most large ESSIDs are deployed with a lot of WAPs bridged
on to a common wired/fiber infrastructure.

> But in Ethernet the scope is not relative to a particular user - it is the scope of the wire if I can say so.

Yes, but we are no longer talking about ethernet because you’ve made
a different design decision to not use Ethernet. So, as a result of
your design decision, you have a very tenuous and constantly fluctuating
definition of “link” that you now have to accept as a tradeoff of your
particular design decision.

> That's not an option.  In some vehicles 802.11-OCB is there built in.

Then accept the tradeoffs of that decision and compensate accordingly
or use something other than “link scope” to scope your multicast packets.

> scope would wait more than on a link scope before continuing.

I would think you’d want the exact opposite in most cases. After all,
at 65MPH, assuming a ~500 foot radio range between vehicles, you’re
talking about 95 feet per second for a closure/departure rate of
roughly 190 feet per second. Therefore, you have roughly 5 seconds
of visibility for two cars approaching head on before they are out
of range of each other.

I would think that in an environment os such transient nature you
would want to reduce delays rather than increase them.

> So an ESSID bridge would link together all in that 'wildcard' ESSID.

Again, I don’t understand the relevance here.

Owen