Subject: Re: IPv6 over Wireless

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 May 2019 13:49:52 +0200

0. the Subject line is IPv6-over-Wireless but the message contents is
    about ND-over-Wireless (WiND - Wireless ND).

    Do you think an IPv6-over-WiFi mechanism could be useful for WiND?

Le 30/04/2019 à 17:59, Pascal Thubert (pthubert) a écrit :
> Dear all:
> 
> Following the discussion with Phil and Ole I added description on 
> what models WiND supports and why it cannot just be P2P, with example
> use cases and constraints.
> 
> https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/
>
>  > Comments welcome (as always),

Pascal,

Thank you for this draft.

I have read it.

1. it's good that you referred to the mbone WG draft about multicast
    problems draft-ietf-mboned-ieee802-mcast-problems-05.

2. I take advantage of this review to ask you again: 802.1 describes an
    Adaptation Layer between Ethernet II headers and
    802.11 headers?  I am trying to find the 802.1 document to find an
    answer myself, but cant.  I do have access to IEEE Xplore by my
    organisation.

3. it would be good if the draft said that 802.11 media does not have
    messages for multicast subscription (a 'message' is an 802.11
    mangement frame like Association Request; a 'multicast subscription'
    is like in IP an 'MLD REPORT').

4. saying 'IPv6 ND broadcasts' may have a problem in semantics since
   'broadcast' in IP terms does not exist in IPv6.  Probably more precise
    is to write 'IPv6 ND multicasted to all-nodes'.

5. by 'broadcast operation' in 'WiND avoids the use of broadcast
    operation for Address Lookup and Duplicate Address Detection' do you
    mean 'radio broadcast', like in 'TV broadcast'?  Casting a message
    broadly?  In IPv6 casting a message broadly is achieved by sending a
    message to a multicast group named 'all-nodes'.

6. 'A to B but not practically not B to A.': I have never witnessed
    a situation in which a wireless node A can send datagrams to B
    but not vice-versa.  The worst I noticed was a difference in
    bandwidth: 16mbit/s vs 1mbit/s in the other direction.  Your
    experience may be different.

7.
> At the physical (PHY) Layer, a broadcast domain is the set of all 
> peers that may receive a datagram that one sends over an interface.
> 
[...]
> 
> We define MAC-Layer Direct Broadcast (DMC) a transmission mode where 
> the broadcast domain that is usable at the MAC layer is directly the 
> physical broadcast domain.

Do you mean that - other than DMC - there is a transmission mode where
the broadcast domain that is usable at the MAC layer is _not_ directly
the physical broadcast domain?

What does 'DMC' stand for?  Is it short for MAC-Layer Direct Broadcast?

Or is it Direct MultiCast?

> IEEE 802.11p, which operates Out of the Context of a BSS (DMC radios)
> is an example of a network that does not have a MAC- Layer broadcast
> domain emulation,

True - OCB does not have a MAC-layer broadcast domain emulation, and
that is to the better.  OCB mode wants to have as little Management
Frames and headers as possible (ideally zero).  Broadcast domain
emulation as described in the draft seems to need dedicated messages and
headers (VLAN, etc.)

But I dont think I have seen OCB to be called DMC up to now.  Maybe this
qualification as DMC of OCB is something new.

On another hand, this is a point where I feel more and more that the
term 'Infrastructure-less' mode, or 'ad-hoc' mode of 802.11 should have
been used too in the draft.

Infrastructure-less mode and OCB mode are similar, but not precisely the
same.

In Infrastructure-less mode (ad-hoc) one may see some Probe Request/Resp
Management Frame messages, some layer 2 security frames, whereas in OCB 
no.

The ad-hoc is at 2.4, or 5.4GHz whereas OCB is at 5.9 - no mix.

> which means that it will exhibit mostly reflexive and mostly 
> non-transitive transmission properties.

I would like to ask you: the non-transitive transmission properties are
relative to ad-hoc mode or to OCB mode?

> lack of a Layer-2 multicast operation that could handle a possibly 
> [...]

Half true: there is indeed lack of layer-2 multicast messages, but there
_are_ layer 2 multicast addresses.  There are at least two kinds of them
(the IETF's IEEE 48bit 33:33::1 but also some other IEEE 48bit groups
for ISO that dont start with 33 hexa).

> Wireless Neighbor Discovery (WiND) 
> [RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd] 
> defines a new ND operation that is based on 2 major paradigm changes,
> proactive address registration by hosts to their attachment routers
> and routing to host routes (/128) within the subnet.  This allows
> WiND to avoid the classical ND expectations of transit links and
> Subnet-wide broadcast domains.

Pascal - is WiND a new term that I never heard about?  I like it.

> WiND is also compatible with DHCPv6 and other forms of address 
> assignment in which case it can still be used for DAD.

This make ask you the following: why is IPv6 over Wireless (presumably
WiND) based on ND and not on DHCPv6?  DHCPv6 already has some mechanisms
to register an address to a server.  If you did that, then we could say
that WiDHCP was compatible with ND.

> The recommended alternate is to use the IPv6 Registration method 
> speficied in

Is the the address registration method covered by IPR?

> DMC radios do not provide MAC level broadcast emulation.  An example 
> of that is OCB (outside the context of a BSS), which uses IEEE Std. 
> 802.11 transmissions but does not provide the BSS functions.

Again, it is worth stressing - I am not sure OCB is DMC.

> If special deployment care is taken [for OCB] so that the physical 
> broadcast domains of a collection of the nodes fully overlap, then it
> is also possible to build an IP Subnet within that collection of 
> nodes and operate IPv6 ND.

Yes, true.  That means subnets for OCB are formed carefully and there
are 2, more than 2 or 3 nodes in it.  It works.

> Router and Hosts respectively send a compressed RA/NA

Why compressed?

> If available, the message can be transported in a compressed form in
> a beacon, e.g., in OCB Basic Safety Messages (BSM) that are nominally
> sent every 100ms.  An active beaconing mode is possible whereby the
> Host sends broadcast RS messages to which a router can answer with a
> unicast RA.

Well yes and no.   YEs the BSM messages as specified and implemented 
today are directly on 802.11 headers (no network layer headers).  It's a 
standard at SAE J2735 and at IEEE 1609.something.  It is widely deployed 
on the Road-Side Units, although a little less in cars.

But no, I myself do not consider that BSM on 802.11 to be right.

The BSM should be carried in an IP message - presumably an UDP payload.

BSM transmitted without IP, but just with 802.11 headers in OCB mode has 
several problems.  One of them is interoperability - it only works in 
some countries.  In other countries CAMs are used.  CAM and BSM are 
incompatible.  These are safety messages.  The worst could happen if one 
brings an EU car to America and it does not understand BSMs telling some 
safety worning.

There are other problems of BSM on OCB (without IP) that relate to 
Cellular V2X: the same BSM cant be transmitted both on OCB and on 
cellular because it has no IP header.  The Cellular V2X only works with 
IP headers.

There are also other problems related to scalability of the 
communication system.

>    A router that has Internet connectivity and is willing to serve as an
>    Internet Access may advertise itself as a default router [RFC4191] in
>    its RA.

Well, yes: the router may send more specific routes RFC4191 all while 
presenting self as a default router and also a prefix in the RA's PIO.

However, that does not mean that implementations allow a router to just 
send more specific routes, _without_ presenting self as a default router 
and advertising a prefix for others to form an address.

And that is precisely what is needed in practice: an IP-RSU (Road-Side 
Unit) router is connected to the Traffic Lights controller, but not to 
the Internet.  It does not own a prefix that is globally routable.  This 
IP-RSU wants to give access to cars nearby, access to the Traffic Lights 
controller.  So it's not a default router (no Internet), and it has no 
Globally Unique prefix to advertise to other cars.

Neither RFCs nor implementations of more specific routes allow for this 
behaviour.  The RFC4191 only allows for Router-to-Host, whereas here the 
IP-RSU is a Router and the car's device is a Router too.  The 
implementations of more specific routes break if one doesnt put a GU 
prefix (Globally Unique) in the RA.

These are some problems with RFC4191 more specific routes in vehicular 
networks.

Is WiND a tool for these problems?

Finally,

8. the Problem Statement draft of the IPWAVE
    WG will have something about the A-B-C transitivity problem.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 May 2019 12:03:32 +0000

Hello Alex

The encapsulation piece for IPv6 over Wi-Fi is already done, not usre what else could be achieves. What can be improved is IPv6 ND.

All the best,

Pascal

> -----Original Message-----
> From: Alexandre Petrescu <[email-masked]>
> Sent: jeudi 2 mai 2019 13:50
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: IPv6 over Wireless
> 
> > Following the discussion with Phil and Ole I added description on what
> > models WiND supports and why it cannot just be P2P, with example use
> > cases and constraints.
> >
> Do you mean that - other than DMC - there is a transmission mode where the
> broadcast domain that is usable at the MAC layer is _not_ directly the physical
> broadcast domain?
> 
> True - OCB does not have a MAC-layer broadcast domain emulation, and that
> is to the better.  OCB mode wants to have as little Management Frames and
> headers as possible (ideally zero).  Broadcast domain emulation as described in
> the draft seems to need dedicated messages and headers (VLAN, etc.)
> 
> On another hand, this is a point where I feel more and more that the term
> 'Infrastructure-less' mode, or 'ad-hoc' mode of 802.11 should have been used
> too in the draft.
> 
> I would like to ask you: the non-transitive transmission properties are relative
> to ad-hoc mode or to OCB mode?
> 
> Half true: there is indeed lack of layer-2 multicast messages, but there _are_
> layer 2 multicast addresses.  There are at least two kinds of them (the IETF's
> IEEE 48bit 33:33::1 but also some other IEEE 48bit groups for ISO that dont
> start with 33 hexa).
> 
> > and routing to host routes (/128) within the subnet.  This allows WiND
> > to avoid the classical ND expectations of transit links and
> WiND) based on ND and not on DHCPv6?  DHCPv6 already has some
> mechanisms to register an address to a server.  If you did that, then we could
> say that WiDHCP was compatible with ND.
> 
> > is also possible to build an IP Subnet within that collection of nodes
> > and operate IPv6 ND.
> 
> Yes, true.  That means subnets for OCB are formed carefully and there are 2,
> more than 2 or 3 nodes in it.  It works.
> 
> > If available, the message can be transported in a compressed form in a
> > beacon, e.g., in OCB Basic Safety Messages (BSM) that are nominally
> standard at SAE J2735 and at IEEE 1609.something.  It is widely deployed on
> the Road-Side Units, although a little less in cars.
> 
> several problems.  One of them is interoperability - it only works in some
> countries.  In other countries CAMs are used.  CAM and BSM are incompatible.
> These are safety messages.  The worst could happen if one brings an EU car to
> America and it does not understand BSMs telling some safety worning.
> 
> There are other problems of BSM on OCB (without IP) that relate to Cellular
> V2X: the same BSM cant be transmitted both on OCB and on cellular because
> it has no IP header.  The Cellular V2X only works with IP headers.
> 
> There are also other problems related to scalability of the communication
> system.
> 
> However, that does not mean that implementations allow a router to just send
> more specific routes, _without_ presenting self as a default router and
> advertising a prefix for others to form an address.
> 
> Unit) router is connected to the Traffic Lights controller, but not to the
> Internet.  It does not own a prefix that is globally routable.  This IP-RSU wants
> to give access to cars nearby, access to the Traffic Lights controller.  So it's not
> a default router (no Internet), and it has no Globally Unique prefix to advertise
> to other cars.
> 
> behaviour.  The RFC4191 only allows for Router-to-Host, whereas here the IP-
> RSU is a Router and the car's device is a Router too.  The implementations of
> more specific routes break if one doesnt put a GU prefix (Globally Unique) in
> the RA.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 May 2019 14:22:36 +0200

After this I limit the rate.

Le 02/05/2019 à 14:03, Pascal Thubert (pthubert) a écrit :
> Hello Alex
> 
> The encapsulation piece for IPv6 over Wi-Fi is already done,

Where?

I do not understand what do you mean.

There is no specification IPv6-over-WiFi.

Alex

  not usre
> what else could be achieves. What can be improved is IPv6 ND.
> 
> All the best,
> 
> Pascal
> 
>> -----Original Message----- From: Alexandre Petrescu
>> <[email-masked]> Sent: jeudi 2 mai 2019 13:50 To:
>> Pascal Thubert (pthubert) <[email-masked]> Cc: 6man WG
>> <[email-masked]> Subject: Re: IPv6 over Wireless
>> 
>> 0. the Subject line is IPv6-over-Wireless but the message contents
>> is about ND-over-Wireless (WiND - Wireless ND).
>> 
>>> what models WiND supports and why it cannot just be P2P, with
>>> example use cases and constraints.
>>> 
>>> https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless
>>>
>>> 
/
>> 1. it's good that you referred to the mbone WG draft about
>> multicast problems draft-ietf-mboned-ieee802-mcast-problems-05.
>> 
>> 2. I take advantage of this review to ask you again: 802.1
>> describes an Adaptation Layer between Ethernet II headers and 
>> 3. it would be good if the draft said that 802.11 media does not
>> have messages for multicast subscription (a 'message' is an 802.11 
>> mangement frame like Association Request; a 'multicast
>> subscription' is like in IP an 'MLD REPORT').
>> 
>> 4. saying 'IPv6 ND broadcasts' may have a problem in semantics
>> since 'broadcast' in IP terms does not exist in IPv6.  Probably
>> more precise is to write 'IPv6 ND multicasted to all-nodes'.
>> 
>> operation for Address Lookup and Duplicate Address Detection' do
>> you mean 'radio broadcast', like in 'TV broadcast'?  Casting a
>> message broadly?  In IPv6 casting a message broadly is achieved by
>> sending a message to a multicast group named 'all-nodes'.
>> 
>> 6. 'A to B but not practically not B to A.': I have never
>> witnessed a situation in which a wireless node A can send datagrams
>> to B but not vice-versa.  The worst I noticed was a difference in 
>>> At the physical (PHY) Layer, a broadcast domain is the set of
>>> all peers that may receive a datagram that one sends over an
>>> interface.
>>> 
>> [...]
>>> 
>>> We define MAC-Layer Direct Broadcast (DMC) a transmission mode
>>> where the broadcast domain that is usable at the MAC layer is
>>> directly the physical broadcast domain.
>> 
>> Do you mean that - other than DMC - there is a transmission mode
>> where the broadcast domain that is usable at the MAC layer is _not_
>> directly the physical broadcast domain?
>> 
>>> IEEE 802.11p, which operates Out of the Context of a BSS (DMC
>>> radios) is an example of a network that does not have a MAC-
>>> Layer broadcast domain emulation,
>> 
>> True - OCB does not have a MAC-layer broadcast domain emulation,
>> and that is to the better.  OCB mode wants to have as little
>> Management Frames and headers as possible (ideally zero).
>> Broadcast domain emulation as described in the draft seems to need
>> dedicated messages and headers (VLAN, etc.)
>> 
>> But I dont think I have seen OCB to be called DMC up to now.  Maybe
>> this qualification as DMC of OCB is something new.
>> 
>> On another hand, this is a point where I feel more and more that
>> the term 'Infrastructure-less' mode, or 'ad-hoc' mode of 802.11
>> should have been used too in the draft.
>> 
>> Infrastructure-less mode and OCB mode are similar, but not
>> precisely the same.
>> 
>> In Infrastructure-less mode (ad-hoc) one may see some Probe
>> Request/Resp Management Frame messages, some layer 2 security
>> frames, whereas in OCB no.
>> 
>> I would like to ask you: the non-transitive transmission properties
>> are relative to ad-hoc mode or to OCB mode?
>> 
>>> lack of a Layer-2 multicast operation that could handle a
>>> possibly [...]
>> 
>> Half true: there is indeed lack of layer-2 multicast messages, but
>> there _are_ layer 2 multicast addresses.  There are at least two
>> kinds of them (the IETF's IEEE 48bit 33:33::1 but also some other
>> IEEE 48bit groups for ISO that dont start with 33 hexa).
>> 
>>> proactive address registration by hosts to their attachment
>>> routers and routing to host routes (/128) within the subnet.
>>> This allows WiND to avoid the classical ND expectations of
>>> transit links and Subnet-wide broadcast domains.
>> 
>> This make ask you the following: why is IPv6 over Wireless
>> (presumably WiND) based on ND and not on DHCPv6?  DHCPv6 already
>> has some mechanisms to register an address to a server.  If you did
>> that, then we could say that WiDHCP was compatible with ND.
>> 
>>> DMC radios do not provide MAC level broadcast emulation.  An
>>> example of that is OCB (outside the context of a BSS), which uses
>>> IEEE Std. 802.11 transmissions but does not provide the BSS
>>> functions.
>> 
>>> If special deployment care is taken [for OCB] so that the
>>> physical broadcast domains of a collection of the nodes fully
>>> overlap, then it is also possible to build an IP Subnet within
>>> that collection of nodes and operate IPv6 ND.
>> 
>> Yes, true.  That means subnets for OCB are formed carefully and
>> there are 2, more than 2 or 3 nodes in it.  It works.
>> 
>>> If available, the message can be transported in a compressed form
>>> in a beacon, e.g., in OCB Basic Safety Messages (BSM) that are
>>> nominally sent every 100ms.  An active beaconing mode is possible
>>> whereby the Host sends broadcast RS messages to which a router
>>> can answer with a unicast RA.
>> 
>> Well yes and no.   YEs the BSM messages as specified and
>> implemented today are directly on 802.11 headers (no network layer
>> headers).  It's a standard at SAE J2735 and at IEEE 1609.something.
>> It is widely deployed on the Road-Side Units, although a little
>> less in cars.
>> 
>> BSM transmitted without IP, but just with 802.11 headers in OCB
>> mode has several problems.  One of them is interoperability - it
>> only works in some countries.  In other countries CAMs are used.
>> CAM and BSM are incompatible. These are safety messages.  The worst
>> could happen if one brings an EU car to America and it does not
>> understand BSMs telling some safety worning.
>> 
>> cellular because it has no IP header.  The Cellular V2X only works
>> with IP headers.
>> 
>>> A router that has Internet connectivity and is willing to serve
>>> as an Internet Access may advertise itself as a default router
>>> [RFC4191] in its RA.
>> 
>> Well, yes: the router may send more specific routes RFC4191 all
>> while presenting self as a default router and also a prefix in the
>> RA's PIO.
>> 
>> However, that does not mean that implementations allow a router to
>> just send more specific routes, _without_ presenting self as a
>> default router and advertising a prefix for others to form an
>> address.
>> 
>> And that is precisely what is needed in practice: an IP-RSU
>> (Road-Side Unit) router is connected to the Traffic Lights
>> controller, but not to the Internet.  It does not own a prefix that
>> is globally routable.  This IP-RSU wants to give access to cars
>> nearby, access to the Traffic Lights controller.  So it's not a
>> default router (no Internet), and it has no Globally Unique prefix
>> to advertise to other cars.
>> 
>> Neither RFCs nor implementations of more specific routes allow for
>> this behaviour.  The RFC4191 only allows for Router-to-Host,
>> whereas here the IP- RSU is a Router and the car's device is a
>> Router too.  The implementations of more specific routes break if
>> one doesnt put a GU prefix (Globally Unique) in the RA.
>> 
>> These are some problems with RFC4191 more specific routes in
>> vehicular networks.
>> 
>> 8. the Problem Statement draft of the IPWAVE WG will have something
>> about the A-B-C transitivity problem.
>> 
>> Alex
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 May 2019 14:06:25 +0000

That's because we use the IEEE 802.3 Distribution System that is connected to the 802.11 by a portal at L2.
The IEEE designed this system and the infrastructure mode to enable a rapid adoption of Wi-Fi and apparently they did succeed.
It's fine for everything logical like the IP encapsulation but shows limits on the physical properties, in particular with broadcast.
This is where WiND comes in.

All the best,

Pascal

> Sent: jeudi 2 mai 2019 14:23
> >> 2. I take advantage of this review to ask you again: 802.1 describes
> >> an Adaptation Layer between Ethernet II headers and
> >> 'broadcast' in IP terms does not exist in IPv6.  Probably more
> >> precise is to write 'IPv6 ND multicasted to all-nodes'.
> >>
> >> 6. 'A to B but not practically not B to A.': I have never witnessed a
> >> situation in which a wireless node A can send datagrams to B but not
> >> vice-versa.  The worst I noticed was a difference in
> >>> radios) is an example of a network that does not have a MAC- Layer
> >>> broadcast domain emulation,
> >>
> >> Frames and headers as possible (ideally zero).
> >> term 'Infrastructure-less' mode, or 'ad-hoc' mode of 802.11 should
> >> have been used too in the draft.
> >>
> >> Infrastructure-less mode and OCB mode are similar, but not precisely
> >> the same.
> >>
> >> Request/Resp Management Frame messages, some layer 2 security frames,
> >> whereas in OCB no.
> >>
> >>> and routing to host routes (/128) within the subnet.
> >>> This allows WiND to avoid the classical ND expectations of transit
> >>> links and Subnet-wide broadcast domains.
> >>
> >> (presumably WiND) based on ND and not on DHCPv6?  DHCPv6 already has
> >> some mechanisms to register an address to a server.  If you did that,
> >> then we could say that WiDHCP was compatible with ND.
> >>
> >>> broadcast domains of a collection of the nodes fully overlap, then
> >>> it is also possible to build an IP Subnet within that collection of
> >>> a beacon, e.g., in OCB Basic Safety Messages (BSM) that are
> >>> whereby the Host sends broadcast RS messages to which a router can
> >>> answer with a unicast RA.
> >>
> >> It is widely deployed on the Road-Side Units, although a little less
> >> in cars.
> >>
> >> BSM transmitted without IP, but just with 802.11 headers in OCB mode
> >> has several problems.  One of them is interoperability - it only
> >> works in some countries.  In other countries CAMs are used.
> >>> A router that has Internet connectivity and is willing to serve as
> >>> an Internet Access may advertise itself as a default router
> >>> [RFC4191] in its RA.
> >>
> >> default router (no Internet), and it has no Globally Unique prefix to
> >> advertise to other cars.
> >>
> >> this behaviour.  The RFC4191 only allows for Router-to-Host, whereas
> >> here the IP- RSU is a Router and the car's device is a Router too.
> >> The implementations of more specific routes break if one doesnt put a
> >> GU prefix (Globally Unique) in the RA.
> >>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 May 2019 10:19:24 +0200

Le 02/05/2019 à 16:06, Pascal Thubert (pthubert) a écrit :
> That's because we use the IEEE 802.3 Distribution System that is
> connected to the 802.11 by a portal at L2. The IEEE designed this
> system and the infrastructure mode to enable a rapid adoption of
> Wi-Fi and apparently they did succeed. It's fine for everything
> logical like the IP encapsulation but shows limits on the physical
> properties, in particular with broadcast. This is where WiND comes
> in.

I would like to have more details about the portal at L2.

I could not find any documentation about it.

You and another knowledgeable person talk mention bridging; you 
nowmention bridging.  But to me bridging is what 802.1 does.  I could 
not find the 802.1 document even though I do have access to IEEE Xplore 
by my organisation.

On another hand, as fas as I can suppose, 802.1 bridging is about 
Ethernet and Ethernet, not between Ethernet and 802.11.

Finally, this portal at L2, as you name it, is something happening on a 
computer with just one real interface - the 802.11 interface.  There are 
no virtual interfaces on it.  I assume the 802.1 bridging seems to 
happen on a computer with two interfaces.

It is for these reasons that I ask you whether you can give more hints 
about an existing specification of what is the portal at L2.

I more detail, I am looking for an existing specification that says how 
the Ethernet II headers (802.3) are mapped into WiFi (802.11) headers.

Alex

>> <[email-masked]> Sent: jeudi 2 mai 2019 14:23 To:
>>>> <[email-masked]> Sent: jeudi 2 mai 2019 13:50
>>>> To: Pascal Thubert (pthubert) <[email-masked]> Cc: 6man WG 
>>>> 0. the Subject line is IPv6-over-Wireless but the message
>>>> contents is about ND-over-Wireless (WiND - Wireless ND).
>>>> 
>>>>> Following the discussion with Phil and Ole I added
>>>>> description on what models WiND supports and why it cannot
>>>>> just be P2P, with example use cases and constraints.
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wirele
>>>>>
>>>>> 
ss
>>>> multicast problems
>>>> draft-ietf-mboned-ieee802-mcast-problems-05.
>>>> 
>>>> 802.11 headers?  I am trying to find the 802.1 document to find
>>>> an answer myself, but cant.  I do have access to IEEE Xplore by
>>>> my organisation.
>>>> 
>>>> 3. it would be good if the draft said that 802.11 media does
>>>> not have messages for multicast subscription (a 'message' is an
>>>> 802.11 mangement frame like Association Request; a 'multicast
>>>> 5. by 'broadcast operation' in 'WiND avoids the use of
>>>> broadcast operation for Address Lookup and Duplicate Address
>>>> Detection' do you mean 'radio broadcast', like in 'TV
>>>> broadcast'?  Casting a message broadly?  In IPv6 casting a
>>>> message broadly is achieved by sending a message to a multicast
>>>> group named 'all-nodes'.
>>>> 
>>>> witnessed a situation in which a wireless node A can send
>>>> datagrams to B but not vice-versa.  The worst I noticed was a
>>>> difference in bandwidth: 16mbit/s vs 1mbit/s in the other
>>>> direction.  Your experience may be different.
>>>> 
>>>> 7.
>>>>> We define MAC-Layer Direct Broadcast (DMC) a transmission
>>>>> mode where the broadcast domain that is usable at the MAC
>>>>> layer is directly the physical broadcast domain.
>>>> 
>>>> Do you mean that - other than DMC - there is a transmission
>>>> mode where the broadcast domain that is usable at the MAC layer
>>>> is _not_ directly the physical broadcast domain?
>>>> 
>>>>> IEEE 802.11p, which operates Out of the Context of a BSS
>>>>> (DMC radios) is an example of a network that does not have a
>>>>> MAC- Layer broadcast domain emulation,
>>>> 
>>>> True - OCB does not have a MAC-layer broadcast domain
>>>> emulation, and that is to the better.  OCB mode wants to have
>>>> as little Management Frames and headers as possible (ideally
>>>> zero). Broadcast domain emulation as described in the draft
>>>> seems to need dedicated messages and headers (VLAN, etc.)
>>>> 
>>>> But I dont think I have seen OCB to be called DMC up to now.
>>>> Maybe this qualification as DMC of OCB is something new.
>>>> 
>>>> On another hand, this is a point where I feel more and more
>>>> that the term 'Infrastructure-less' mode, or 'ad-hoc' mode of
>>>> 802.11 should have been used too in the draft.
>>>> 
>>>> I would like to ask you: the non-transitive transmission
>>>> properties are relative to ad-hoc mode or to OCB mode?
>>>> 
>>>> Half true: there is indeed lack of layer-2 multicast messages,
>>>> but there _are_ layer 2 multicast addresses.  There are at
>>>> least two kinds of them (the IETF's IEEE 48bit 33:33::1 but
>>>> also some other IEEE 48bit groups for ISO that dont start with
>>>> 33 hexa).
>>>> 
>>>>> WiND is also compatible with DHCPv6 and other forms of
>>>>> address assignment in which case it can still be used for
>>>>> DAD.
>>>> 
>>>> (presumably WiND) based on ND and not on DHCPv6?  DHCPv6
>>>> already has some mechanisms to register an address to a server.
>>>> If you did that, then we could say that WiDHCP was compatible
>>>> with ND.
>>>> 
>>>>> The recommended alternate is to use the IPv6 Registration
>>>>> method speficied in
>>>> 
>>>>> example of that is OCB (outside the context of a BSS), which
>>>>> uses IEEE Std. 802.11 transmissions but does not provide the
>>>>> BSS functions.
>>>> 
>>>>> overlap, then it is also possible to build an IP Subnet
>>>>> within that collection of nodes and operate IPv6 ND.
>>>> 
>>>>> If available, the message can be transported in a compressed
>>>>> form in a beacon, e.g., in OCB Basic Safety Messages (BSM)
>>>>> that are nominally sent every 100ms.  An active beaconing
>>>>> mode is possible whereby the Host sends broadcast RS messages
>>>>> to which a router can answer with a unicast RA.
>>>> 
>>>> implemented today are directly on 802.11 headers (no network
>>>> layer headers).  It's a standard at SAE J2735 and at IEEE
>>>> 1609.something. It is widely deployed on the Road-Side Units,
>>>> although a little less in cars.
>>>> 
>>>> mode has several problems.  One of them is interoperability -
>>>> it only works in some countries.  In other countries CAMs are
>>>> used. CAM and BSM are incompatible. These are safety messages.
>>>> The worst could happen if one brings an EU car to America and
>>>> it does not understand BSMs telling some safety worning.
>>>> 
>>>> There are other problems of BSM on OCB (without IP) that relate
>>>> to Cellular V2X: the same BSM cant be transmitted both on OCB
>>>> and on cellular because it has no IP header.  The Cellular V2X
>>>> only works with IP headers.
>>>> 
>>>>> A router that has Internet connectivity and is willing to
>>>>> serve as an Internet Access may advertise itself as a default
>>>>> router [RFC4191] in its RA.
>>>> 
>>>> while presenting self as a default router and also a prefix in
>>>> the RA's PIO.
>>>> 
>>>> However, that does not mean that implementations allow a router
>>>> to just send more specific routes, _without_ presenting self as
>>>> a default router and advertising a prefix for others to form
>>>> an address.
>>>> 
>>>> controller, but not to the Internet.  It does not own a prefix
>>>> that is globally routable.  This IP-RSU wants to give access to
>>>> cars nearby, access to the Traffic Lights controller.  So it's
>>>> not a default router (no Internet), and it has no Globally
>>>> Unique prefix to advertise to other cars.
>>>> 
>>>> Neither RFCs nor implementations of more specific routes allow
>>>> for this behaviour.  The RFC4191 only allows for
>>>> Router-to-Host, whereas here the IP- RSU is a Router and the
>>>> car's device is a Router too. The implementations of more
>>>> specific routes break if one doesnt put a GU prefix (Globally
>>>> Unique) in the RA.
>>>> 
>>>> 8. the Problem Statement draft of the IPWAVE WG will have
>>>> something about the A-B-C transitivity problem.
>>>> 
>>>> Alex
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 3 May 2019 14:24:47 -0400

Pascal

IPv6 over WIFI is supported by mostWIFI vendors today with code upgrades to support.

We use Aruba WIFI solution for IPv6 for a long time now which requires tunnel mode GRE tunnel from AP to WiFi controller and as the traffic is all bridged their is not anything other then security rules if we want to add on the controllers.  The WIFI user once authenticated to an SSID the IPv6 address in tunnel mode comes from a router upstream from the controller Vlan with /64 pool is from which the IPv6 address is doled out so its pretty seamless and IPv6 works pretty much the same as IPv4 from a a WiFi perspective.

Is there any RFC or draft that for IPv6 over WIFI.

Gyan

Sent from my iPhone

> On May 2, 2019, at 8:22 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
>>> describes an Adaptation Layer between Ethernet II headers and 802.11 headers?  I am trying to find the 802.1 document to find an answer myself, but cant.  I do have access to IEEE Xplore by my organisation.
>>> have messages for multicast subscription (a 'message' is an 802.11 mangement frame like Association Request; a 'multicast
>>> 5. by 'broadcast operation' in 'WiND avoids the use of broadcast operation for Address Lookup and Duplicate Address Detection' do
>>> to B but not vice-versa.  The worst I noticed was a difference in bandwidth: 16mbit/s vs 1mbit/s in the other direction.  Your experience may be different.
>>> 7.
>>>> which means that it will exhibit mostly reflexive and mostly non-transitive transmission properties.
>>>> Wireless Neighbor Discovery (WiND) [RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd]
>>>> 
>>>> WiND is also compatible with DHCPv6 and other forms of address assignment in which case it can still be used for DAD.
>>>> The recommended alternate is to use the IPv6 Registration method speficied in
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------