Subject: [v6ops] IPv6 over 802.11p - no modifications required

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Dec 2013 12:09:33 +0100

draft-petrescu-ipv6-over-80211p-01.txt

Hello participants to v6ops,

Running IPv6 over 802.11p requires no modifications to the protocol: it
runs just as IPv6 over Ethernet does - same 0x86DD Ethertype, same
recommended minimal MTU, same formation of the Interface ID, ...

However, in some operational environments, some tweaks may be necessary
due to specificities of the link (e.g. OCB - outside the context of a
BSS id): frequent Router Advertisements to support handover of
high-speed vehicles through distanced Road-Side Units, and IP security
messages because the link layer has no security features.

This is what this draft describes:

"Transmission of IPv6 Packets over IEEE 802.11p Networks"
A. Petrescu, R. Kuntz, P. Pfister, N. Benamar
http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01

What do you think?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Dec 2013 07:57:46 +1300

Hi

1. Surely this should be a 6man document, not v6ops?

2. "5.5. Stateless Autoconfiguration

   The Interface Identifier for an 802.11p interface is formed using the
   same rules as the Interface Identifier for an Ethernet interface;
   this is described in section 4 of [RFC2464]."

Given the discussion of deprecating EUI-64, I think this should be:

   "The Interface Identifier for an 802.11p interface may be formed..."

3. I notice that you cite the RFC 2119 terminology but the draft doesn't
actually use it. If you don't use it, please don't cite it.

Regards
   Brian Carpenter

On 03/12/2013 00:09, Alexandru Petrescu wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 3 Dec 2013 12:03:57 +1100

Hi Alex, 
 
Increased RA rates were investigated for MIPv6, and this was not the preferred solution (though I submitted the text for the initial RFC).
 
Is it applicable to use Detecting Network Attachment procedures (RFC 6059) instead of high rates of beacons?
 
(obviously I have a bias, but that was the evolution which brought about the working group: MIPv6 o 802.11 w/beacons -> basic change detection support in DNA)
 
Sincrerely,
 
Greg Daley
+61 401 772 770
 
> Date: Mon, 2 Dec 2013 12:09:33 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: [v6ops] IPv6 over 802.11p - no modifications required
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Dec 2013 13:40:32 +0100

Hi Brian,

Thanks for the reply.

> 1. Surely this should be a 6man document, not v6ops?

I would say yes, as it is a typical IPv6-over-foo document, and has no
6lowpan adaptation layer.

(If we are to discuss it in 6man, among other things, we may discuss the 
necessity of describing the existing Ethernet Adaptation Layer.)

The v6ops relevance may stem from its operational need in some
deployments (IPv6 802.11p Road-Side Units, local regulation of frequency
use, etc.)

As you can see, we look for a path for this draft.

> The Interface Identifier for an 802.11p interface is formed using
> the same rules as the Interface Identifier for an Ethernet
> interface; this is described in section 4 of [RFC2464]."
>

I agree.  Given that discussion, and if that 'deprecate' draft is 
adopted, we authors of this IPv6-over-11p draft need to change this to a 
MAY.

> 3. I notice that you cite the RFC 2119 terminology but the draft
> doesn't actually use it. If you don't use it, please don't cite it.

Good point, I will have to remember this for future drafts as well.

Alex

> Regards Brian Carpenter
>> Running IPv6 over 802.11p requires no modifications to the
>> protocol: it runs just as IPv6 over Ethernet does - same 0x86DD
>> Ethertype, same recommended minimal MTU, same formation of the
>> Interface ID, ...
>>
>> However, in some operational environments, some tweaks may be
>> necessary due to specificities of the link (e.g. OCB - outside the
>> context of a BSS id): frequent Router Advertisements to support
>> handover of high-speed vehicles through distanced Road-Side Units,
>> and IP security messages because the link layer has no security
>> features.
>>
>> "Transmission of IPv6 Packets over IEEE 802.11p Networks" A.
>> Petrescu, R. Kuntz, P. Pfister, N. Benamar
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Dec 2013 14:07:23 +0100

Hi Greg,

Thank you for the reply.

Le 03/12/2013 02:03, Greg Daley a écrit :
> Hi Alex,
>
> Increased RA rates were investigated for MIPv6, and this was not the
> preferred solution (though I submitted the text for the initial
> RFC).

I do remember the activity, although not clearly about the preference.

Yes, frequent RAs may noise slow/latent wireless links.  In 802.11p they
may lead to undesirable loss of urgent messages.

That said, it may be a matter of finding the right ratio between RA
periodicity, the link bandwidth and mandatory 0 probability of loss (for
a given geometry of the RSU deployments and speed limitations).

Currently, the Mobile IPv6 RFC6275 lowers the timer limits to e.g.
MinRtrAdvInterval 0.03 seconds (as opposed to ND's 3 seconds RFC4861).

However, that is a Mobile IPv6 specification, and it does not update the
ND spec.  Mobile IPv6 specs are not considered in RSUs of some 802.11p
deployments. (although MIP specs are considered for the Router in the
vehicle and in the HA).

This is one of the reasons why we suggest this MIP low limit of
MinRtrAdvInterval in this IPv6-over-80211p document.

> 6059) instead of high rates of beacons?

This is a good question.

Is RFC6059 applicable to Router-to-Router communications (a vehicle
holds a Router which connects to another Router sitting aside the road)?

Second, it seems to me the DNA procedures are all preceded by a
mandatory initial step of 'link-layer indication', or 'link up'.  In
802.11 these indicators seem to be, by RFC4957, the receive of a link
layer message (Ass'n Reply, or Auth Reply, or similar.)

But 802.11p being a stripped-off version of 802.11, there is no Ass'n
Reply, no Auth Reply, and the SSID is always the same (all 1s, 'wildcard
BSSID').

This is the reason why I doubt about the applicability of DNA.  I may be
wrong though.

For the IEEE 802.11p specifications see the web, or otherwise just ask.

> (obviously I have a bias, but that was the evolution which brought
> about the working group: MIPv6 o 802.11 w/beacons -> basic change
> detection support in DNA)

Does basic change detection work without a link up indicator?

Alex

>
> Sincrerely,
>
> Greg Daley +61 401 772 770
>
>> Date: Mon, 2 Dec 2013 12:09:33 +0100 From:
>> [email-masked] To: [email-masked] Subject: [v6ops]
>> IPv6 over 802.11p - no modifications required
>>