Subject: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11)

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Jun 2013 15:23:14 +0200

Hello participants to the ITS email list,

The potential modifications on the use of IPv6 over 802.11p (beyond the
way IPv6-over-80211 already works) may be:

(1) issued by the fact that the BSSID is always 48 1 bits,
(2) on the NTP and/or frequency of RA for timestamps, because
     Timestamps are required by 802.11p for being in synch,
(3) on MIB, because 802.11p has EDCA parameters for STA QoS.
(4) do ND security (or other layer?) because 802.11p does not do
     Authentication Req/Resp.

(5) have a means for a mobile node to distinguish between two different
     802.11p Access Routers, because 802.11p works outside the context
     of an BSS.  This would facilitate the handover procedure of
     protocol Mobile IPv6.

In detail, below:

The modifications needed for a driver to go from 802.11 to 802.11p are
the following.  This is for a driver like Atheros 5K for linux.

- work 'outside a BSS', i.e. use the BSSID as 48 1 bits.  This is
   present in every MAC header of data and control frames, in the field
   BSSID.  It is not the dst MAC address.  This may or may not have an
   influence on the way ND, ICMP and MLD use the multicast addresses
   (typically they assume 33::1 instead of 48 1s, but that's only for
    dst, BSSID being not used by these protocols).

- send periodic timestamps.  This could have a relationship on the way
   NTP works, or maybe send RAs containing a timestamp.

- EDCA parameter set for STAs transmitting QoS frames - maybe have
   entries in MIB.

- do not do Authentication Request, and no other Auth message.

- modify the 'regulatory domain' such as the PHY works on the vehicular
   frequencies valid in the respective country.  This is typically
   somewhere between 5860MHz to 5920MHz.  These frequencies are
   dedicated to only vehicular settings.

- half-rate (or half-clocking) - the band width must be 10MHz, instead
   of the typical 802.11 20MHz.

- Tx Power - go to as high as 33dBm in some countries (instead of 20dBm
   of 802.11).

- deactivate emission of Beacons.

Thoughts on these aspects?

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jun 2013 13:26:40 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> Hello participants to the ITS email list,

    Alexandru> The potential modifications on the use of IPv6 over 802.11p (beyond the
    Alexandru> way IPv6-over-80211 already works) may be:

    Alexandru> (1) issued by the fact that the BSSID is always 48 1 bits,

that, from the IPv6-over-802.11 point of view, is a layer-2 issue.

    Alexandru> (2) on the NTP and/or frequency of RA for timestamps, because
    Alexandru> Timestamps are required by 802.11p for being in synch,

I don't understand.

    Alexandru> (3) on MIB, because 802.11p has EDCA parameters for STA QoS.

Maybe, but first, can you show me who has a MIB on client side 802.11 device?
(11p has no access point...)

    Alexandru> (4) do ND security (or other layer?) because 802.11p does not do
    Alexandru> Authentication Req/Resp.

seems like a layer-3 (IPv6) issue, not an IPv6-over-foo issue.

    Alexandru> (5) have a means for a mobile node to distinguish between two different
    Alexandru> 802.11p Access Routers, because 802.11p works outside the context
    Alexandru> of an BSS.  This would facilitate the handover procedure of
    Alexandru> protocol Mobile IPv6.

I don't see how this has anything to do with anything.
Mobile IPv6 cares about the IP address of Home Agents.

    Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bits.  This is
    Alexandru> present in every MAC header of data and control frames, in the field
    Alexandru> BSSID.  It is not the dst MAC address.  This may or may not have an
    Alexandru> influence on the way ND, ICMP and MLD use the multicast addresses
    Alexandru> (typically they assume 33::1 instead of 48 1s, but that's only for
    Alexandru> dst, BSSID being not used by these protocols).

huh?  The BSSID is not the MAC header.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Jun 2013 12:15:45 +0200

Le 11/06/2013 19:26, Michael Richardson a écrit :
> Alexandru> The potential modifications on the use of IPv6 over
> 802.11p (beyond the Alexandru> way IPv6-over-80211 already works) may
> be:
>

Yes, there's a layer 2 issue, and layer 3 may map to it.  E.g. map an
IPv6 multicast address into a link-layer multicast address.

It may be that the BSSID 48 1 bits (ff:ff:ff:ff:ff:ff) may be needed for
something that IP needs, at which time there would be a need for a
mapping method.

> Alexandru> (2) on the NTP and/or frequency of RA for timestamps,
> because Alexandru> Timestamps are required by 802.11p for being in
> synch,
>
> I don't understand.

By spec, 802.11p (as opposed to 802.11) needs to transmit periodically a
Timestamp.  That is a link-layer message.  Its goal is for the stations
around to synchronize their time.

To program that in the 802.11p driver is difficult, because it is very
low level.  I havent seen this Timestamp 802.11p message, despite having
access to some 802.11p stacks.

But it may be easier to do it at IP layer.  This could be done in
various ways: maybe have a timestamp field in a RA?  (there isnt
currently any).  Maybe have NTP protcol realize that?

> Maybe, but first, can you show me who has a MIB on client side 802.11

Good question - I dont know.  I can only suppose there could exist.  I
think MIBs exist on end nodes, not necessarily routers or managed access
points.

> (11p has no access point...)

Well yes, 11p does not have managed mode, nor adhoc mode, nor any
meaningful form of BSS.

However, nothing stops somebody from putting a 802.11p and a Ethernet
interface on a Router.  That is an Access Router.  There are some
products on the market named RSU (Road-Side Unit) which are built that way.

The RSUs all send data on a particular frequency at 5.9GHz range,
without first forming a BSS.  Everybody hears everybody else, and
everybody talks to everybody else.

> Alexandru> (4) do ND security (or other layer?) because 802.11p does
> not do Alexandru> Authentication Req/Resp.
>

Well, security being still important, the fact that 802.11p does not
have security (no Auth Req/Resp, no Probe Req/Resp, no Ass'n Req/Resp)
means that upper layer security is even more important than before.

Before 802.11p, we were saying that ND security (e.g. SeND) may not be
needed because 802.11 already had WEP and WPA.  But now, since 802.11p
does not have neither WEP nor WPA, ND security is even more important.

The problem here is: which ND security?  SeND?  Other?

> Alexandru> (5) have a means for a mobile node to distinguish between
> two different Alexandru> 802.11p Access Routers, because 802.11p
> works outside the context Alexandru> of an BSS.  This would
> facilitate the handover procedure of Alexandru> protocol Mobile
> IPv6.
>
> I don't see how this has anything to do with anything. Mobile IPv6
> cares about the IP address of Home Agents.

By RFC, the movement detection of Mobile IPv6 relies on the comparison
of prefixes received in Router Advertisements.  But in implementation,
often this detection is guided by the change in ESSID (provoke a
different Ass'n Req to a different ESSID, then receive RA, then compare
to old prefix).

But with 802.11p we don't have Ass'n Req.  Basically a Mobile Node
receives RAs from all other Access Routers who send RAs on that 5900MHz
frequency (802.11p is all 'outside a BSS').  With the current movement
detection of RFC Mobile IPv6 and without a BSS, it's hard for a Mobile
Node to detect movement consistently.  The end result is that the Mobile
Node may choose the default route to an Access Router which may  not
necessarily be the good one (not the closest, not the approaching, etc.).

> Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bits.
> This is Alexandru> present in every MAC header of data and control
> frames, in the field Alexandru> BSSID.  It is not the dst MAC
> address.  This may or may not have an Alexandru> influence on the way
> ND, ICMP and MLD use the multicast addresses Alexandru> (typically
> they assume 33::1 instead of 48 1s, but that's only for Alexandru>

Right, the BSSID is in the 802.11 header (not the Ethernet header).

It may be that this BSSID all 1s may not have any influence on IPv6.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jun 2013 10:43:22 -0400

>> 802.11p (beyond the Alexandru> way IPv6-over-80211 already works) may
    Alexandru> (1) issued by the fact that the BSSID is always 48 1
    >> bits,

    Alexandru> Yes, there's a layer 2 issue, and layer 3 may map to it.  E.g. map an
    Alexandru> IPv6 multicast address into a link-layer multicast
    Alexandru> address.

No, it does not. The BSSID is not used by layer3, and is not even
visible to it.

---

From: John Kenney <[email-masked]>
Date: Tue, 18 Jun 2013 17:06:48 -0700

Hi,
Just a small clarification that 802.11p does not require a timestamp to be
sent.  It defines an optional Timing Advertisement frame, but I'm not aware
that it has been implemented.  Most DSRC devices will get time estimates
from GPS.

Best Regards,
John
On Wed, Jun 12, 2013 at 3:15 AM, Alexandru Petrescu <
[email-masked]> wrote:

> ______________________________**_________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/its<https://www.ietf.org/mailman/listinfo/its>
>

-- 
John Kenney
Sr. Research Manager
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Jun 2013 09:13:31 +0200

Hi John,

Thank you for the clarification on the absence of requirement for
timestamp presence.

Indeed, the 802.11p implementations I am aware of do not send that
Timing Advertisement, nor any other periodic advertisements.  (just that
the ETSI ITS implementation sends a 1second periodic advertisement.)

Getting time estimates from GPS is a good alternative, although not sure
how well it would  work in uncovered areas (e.g. tunnel).

I can only suppose that 802.11p continues working in tunnels,
underground, etc. and that its reliance on synchronized time is not
critical.

Alex

Le 19/06/2013 02:06, John Kenney a écrit :
> Hi, Just a small clarification that 802.11p does not require a
> timestamp to be sent.  It defines an optional Timing Advertisement
> frame, but I'm not aware that it has been implemented.  Most DSRC
> devices will get time estimates from GPS. Best Regards, John On Wed,
> Jun 12, 2013 at 3:15 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> "Alexandru" == Alexandru Petrescu <[email-masked]
> <mailto:[email-masked]>> writes:
>
> 802.11p (beyond the Alexandru> way IPv6-over-80211 already works)
> may be:
>
> Yes, there's a layer 2 issue, and layer 3 may map to it.  E.g. map
> an IPv6 multicast address into a link-layer multicast address.
>
> It may be that the BSSID 48 1 bits (ff:ff:ff:ff:ff:ff) may be needed
> for something that IP needs, at which time there would be a need for
> a mapping method.
>
>
> By spec, 802.11p (as opposed to 802.11) needs to transmit
> periodically a Timestamp.  That is a link-layer message.  Its goal is
> for the stations around to synchronize their time.
>
> To program that in the 802.11p driver is difficult, because it is
> very low level.  I havent seen this Timestamp 802.11p message,
> despite having access to some 802.11p stacks.
>
> Good question - I dont know.  I can only suppose there could exist.
> I think MIBs exist on end nodes, not necessarily routers or managed
> access points.
>
>
> However, nothing stops somebody from putting a 802.11p and a
> Ethernet interface on a Router.  That is an Access Router.  There are
> some products on the market named RSU (Road-Side Unit) which are
> built that way.
>
> have security (no Auth Req/Resp, no Probe Req/Resp, no Ass'n
> Req/Resp) means that upper layer security is even more important than
> before.
>
> Before 802.11p, we were saying that ND security (e.g. SeND) may not
> be needed because 802.11 already had WEP and WPA.  But now, since
> 802.11p does not have neither WEP nor WPA, ND security is even more
> important.
>
> By RFC, the movement detection of Mobile IPv6 relies on the
> comparison of prefixes received in Router Advertisements.  But in
> implementation, often this detection is guided by the change in ESSID
> (provoke a different Ass'n Req to a different ESSID, then receive RA,
> then compare to old prefix).
>
> receives RAs from all other Access Routers who send RAs on that
> 5900MHz frequency (802.11p is all 'outside a BSS').  With the current
> movement detection of RFC Mobile IPv6 and without a BSS, it's hard
> for a Mobile Node to detect movement consistently.  The end result is
> that the Mobile Node may choose the default route to an Access Router
> which may  not necessarily be the good one (not the closest, not the
> approaching, etc.).
>
>
> address.  This may or may not have an Alexandru> influence on the
> way ND, ICMP and MLD use the multicast addresses Alexandru>
> _________________________________________________ its mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/__listinfo/its
> <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
> -- John Kenney Sr. Research Manager Toyota InfoTechnology Center,
> USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160.
> Mobile: 650-224-6644