Subject: [its] Confirming direction set at IETF 97 IPWAVE Session

From: Russ Housley <[email-masked]>
Date: Wed, 16 Nov 2016 00:01:54 -0500

During the discussion of draft-petrescu-ipv6-over-80211p-05 at IETF 97, the IPWAVE WG talked about whether the document should include any specification to carry IPv4.  The result of that discussion was that the WG’s document should only specify IPv6.  It was pointed out that a non-WG document could be written to cover IPv4.

Please speak now if you disagree with this direction.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Nov 2016 00:49:36 -0500

During the discussion of draft-petrescu-ipv6-over-80211p-05 at IETF 97, a hum was taken.  Most people in the IPWAVE WG session felt that the next version of the document should be adopted as the starting point for the WG standards track deliverable.  It was assumed that the next version would include updates based on the discussion that took place in the room.

Please speak now if you disagree with the IPWAVE WG adopting the next version of this document.

Russ

---

From: Tony Li <[email-masked]>
Date: Wed, 16 Nov 2016 06:42:10 -0800

I disagree.

IPv4 is pretty important to the Internet. Still. The IPv4 encoding for 802.11p needs to be documented somewhere. Doing so in this document is very efficient since it has so much in common with the IPv6 encoding. Creating a separate document solves no problems, it only creates more work.

Tony

p.s. First reply got queued for moderation as I mistakenly sent it from the wrong email account.  Please pardon any duplicates.

> On Nov 15, 2016, at 9:01 PM, Russ Housley <[email-masked]> wrote:
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Tony Li <[email-masked]>
Date: Wed, 16 Nov 2016 14:23:03 +0000

I disagree.

IPv4 is pretty important to the Internet. Still. The IPv4 encoding for
802.11p needs to be documented somewhere. Doing so in this document is very
efficient since it has so much in common with the IPv6 encoding. Creating a
separate document solves no problems, it only creates more work.

Tony

On Tue, Nov 15, 2016 at 9:02 PM Russ Housley <[email-masked]> wrote:

> During the discussion of draft-petrescu-ipv6-over-80211p-05 at IETF 97,
> the IPWAVE WG talked about whether the document should include any
> specification to carry IPv4.  The result of that discussion was that the
> WG’s document should only specify IPv6.  It was pointed out that a non-WG
> document could be written to cover IPv4.
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 10:20:54 +0900

Tony Li <[email-masked]> wrote:
    > 802.11p needs to be documented somewhere. Doing so in this document is
    > very efficient since it has so much in common with the IPv6
    > encoding. Creating a separate document solves no problems, it only
    > creates more work.

And, I hear terrible things from BobM about how the automotive industry
intends to use IPv4 space for it's control systems for decades to come.
(For a purpose that v6-LL space work just fine, and it's all greenfield.
Given the total greenfield usage with devices not yet built, I'm inclined to
given them a /24 of class E space for play in if they insist on being so stupid)

So, ipwave will need to take this use into account, to the extent that it
will need to block any leaks that develop, and alert about any attempts to
communicate inappropriately.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Nov 2016 10:48:53 +0900

Le 17/11/2016 à 10:20, Michael Richardson a écrit :
>> IPv4 is pretty important to the Internet. Still. The IPv4 encoding
>> for 802.11p needs to be documented somewhere. Doing so in this
>> document is very efficient since it has so much in common with the
>> IPv6 encoding. Creating a separate document solves no problems, it
>> only creates more work.
>
> And, I hear terrible things from BobM about how the automotive
> industry intends to use IPv4 space for it's control systems for
> decades to come. (For a purpose that v6-LL space work just fine, and
> it's all greenfield. Given the total greenfield usage with devices
> not yet built, I'm inclined to given them a /24 of class E space for
> play in if they insist on being so stupid)

:-) "stupid"?  They have their own constraints about this IPv4.  And
these constraints dont come from them, but from device manufacturers,
operators, software houses...

> So, ipwave will need to take this use into account, to the extent
> that it will need to block any leaks that develop, and alert about
> any attempts to communicate inappropriately.

At this point I think it would make sense to write a separate
IPv4-over-802-11-OCB document.  There is interest in that.

I would simply avoid to go against the Charter (which says IPv6 only).

Alex

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 17 Nov 2016 11:35:17 +0100

Hi,

The charter and the AD are clear on this. Our main deliverable (and
only standards track document) in the current charter is IPv6-only, so
let's keep it like that.

This does not mean that the group cannot discuss about IPv4 issues and
raise the need for such a kind of work (if that is the case). If there
is strong support behind considering IPv4, the IESG might allow us to
work on that as well. Besides, it doesn't seem at this time that
significant changes would need to be considered to support IPv4.

But the key message is to focus on our IPv6-only main deliverable for
the time being.

Thanks,

Carlos & Russ

---

From: Nabil BENAMAR <[email-masked]>
Date: Thu, 17 Nov 2016 10:49:02 +0000

Hi,

As a co-author of this draft, I welcome this decision !

Best Regards,
Nabil 

> On Nov 17, 2016, at 10:35 AM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 17 Nov 2016 22:08:54 +0900

Hi IPWAVEers,
I support the opinion that ipwave WG need to focuse on IPv6 according to
the WG milestone.
Once we deliver the expected documents timely, we may work for IPv4 on
ipwave.

Thanks.

Best Regards,
Paul

---

From: Tony Li <[email-masked]>
Date: Thu, 17 Nov 2016 07:41:57 -0800

Ok, ok, I can take a hint. Subtle it was… ;-)

Standing offer: if anyone would like to collaborate on IPv4, please contact me.

Ciao,
Tony

> On Nov 17, 2016, at 2:35 AM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 
> Hi,
>

---

From: Dapeng Liu <[email-masked]>
Date: Thu, 17 Nov 2016 16:09:54 +0000

Hi,

I think this approach makes sense.  We can certainly discuss what is the
IPv4 work need to be done and when we find it out we may have more clear
idea regarding how to move it forward.

Thanks,
Dapeng Liu

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 18 Nov 2016 10:29:04 +0900

Michael,

> communicate inappropriately.

Internal vehicle communications which MUST NOT be accessable outside the 
vehicle is vastly different from WAN communications needs.  In fact, 
IPv6 along with IPv4 on the Infotainment network is a common thread.  
Only a few devices will be accessable via the outside world.  Various 
segmentation mindsets will isolate the networks that control the car 
from the rest of the world.

In IPWAVE you have to look at the size of the 'visable' network. Given 
the channel allocation, how many vehicles on a congested transportation 
area see each other.  Granted, the IEEE 1609 approach to this is NO IP, 
but direct WAVE broadcast messaging.  Still, at any time these many 
vehicles could be using IP.  Scale is important.

Again, in your garage, would there be a 802.11OCB radio on your AP for 
your car to use that?  This is not hard for an EE to do, but still, the 
radio does one channel.  Join into the fun 802.11 discussions on this 
subject.  In My Highly Biased Opinion, in your garage, the communication 
path will be through the regular 802.11 radio on the Infotainment 
system.  The DSRC module could tunnel through the virtual machine that 
controls that radio.

Yes, the car will remain a vary complex machine.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 18 Nov 2016 10:31:27 +0900

I may be able to find a few bodies that are interested in this. Will 
post to the list on this if I can get any to come out in the open.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Nov 2016 15:39:44 +0900

Robert Moskowitz <[email-masked]> wrote:
    >> So, ipwave will need to take this use into account, to the extent that
    >> it will need to block any leaks that develop, and alert about any
    >> attempts to communicate inappropriately.

    > Internal vehicle communications which MUST NOT be accessable outside
    > the vehicle is vastly different from WAN communications needs.  In
    > fact, IPv6 along with IPv4 on the Infotainment network is a common
    > thread.  Only a few devices will be accessable via the outside world.
    > Various segmentation mindsets will isolate the networks that control
    > the car from the rest of the world.

yes, I realize that the internal vehicle communications are intended to be
firewalled off, but there won't be airgap firewalls, and there might be ways
(i.e. bugs) that could cause leakage: we should, in ipwave, perhaps have
default firewalls (belt-and-suspenders) and alerts for what will become well
known IPv4 addresses.  Again, I think we should ask if a class E allocation
could be done, or if automative would like to find an RIR assigned /24 for
this use.

    > subject.  In My Highly Biased Opinion, in your garage, the
    > communication path will be through the regular 802.11 radio on the
    > Infotainment system.  The DSRC module could tunnel through the virtual
    > machine that controls that radio.

If the 802.11OCB chipset between cheap, they will be everywhere, and they
will get turned on, intentionally or not.  We don't know, and we should both
enable innovation here, and prepare for the possible negative affects.

--
]               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: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Nov 2016 17:36:08 -0500

> enable innovation here, and prepare for the possible negative affects.

It does not take much of a firmware change to make an 802.11a radio work 
on the 802.11OCB bands.  The rest is all software.  The early domos I 
saw were just Atheros 11a radios reprogrammed.  I am sure the code for 
Linux is out there somewhere.  The Nexus phone Honda used at their demo 
at ITS World in Detroit a couple years back was a standard Qualcomm 
radio with Qualcomm provided firmware.

So have at it!

Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Nov 2016 16:21:21 +0100

Le 24/11/2016 à 23:36, Robert Moskowitz a écrit :
>>>> it will need to block any leaks that develop, and alert about
>>> the vehicle is vastly different from WAN communications needs.
>>> In fact, IPv6 along with IPv4 on the Infotainment network is a
>>> common thread.  Only a few devices will be accessable via the
>>> outside
>> world.
>> yes, I realize that the internal vehicle communications are
>> intended to be firewalled off, but there won't be airgap firewalls,
>> and there might be ways (i.e. bugs) that could cause leakage: we
>> should, in ipwave, perhaps have default firewalls
>> (belt-and-suspenders) and alerts for what will become well known
>> IPv4 addresses.  Again, I think we should ask if a class E
>> allocation could be done, or if automative would like to find an
>> RIR assigned /24 for this use.
>>
>>> communication path will be through the regular 802.11 radio on
>>> the Infotainment system.  The DSRC module could tunnel through
>>> the
>> virtual
>> If the 802.11OCB chipset between cheap, they will be everywhere,
>> and they will get turned on, intentionally or not.  We don't know,
>> and we should both enable innovation here, and prepare for the
>> possible negative affects.
>
> It does not take much of a firmware change to make an 802.11a radio
> work on the 802.11OCB bands.  The rest is all software.  The early
> domos I saw were just Atheros 11a radios reprogrammed.  I am sure the
> code for Linux is out there somewhere.

There is software available as open source for 802.11 OCB mode for an
older linux kernel and for the 'iw' command at
https://github.com/CTU-IIG/802.11p-linux and
https://gist.github.com/lisovy/80dde5a792e774a706a9

There are more pointers to hardware and open drivers for other OSs like 
BSD at
https://github.com/alexvoronov/geonetworking/blob/master/HARDWARE.md

However, few of these functionalities are integrated in the mainline 
kernel and iw distribution.

Alex

> The Nexus phone Honda used at their demo at ITS World in Detroit a
> couple years back was a standard Qualcomm radio with Qualcomm
> provided firmware.
>
> So have at it!
>
> Bob
>