Subject: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Jul 2018 11:03:27 -0400

I volunteered (or was volunteered) to review this document during the 
ipwave meeting this week.
Here are my comments and suggested modifications.

Level 0. My assumption is that the OCB interface (in vehicles and 
infrastructure nodes) are attached to a router, and not a host. Is that 
correct?
That assumption has a significant implication on the subnet/ND material.
(And appendix H talks about hosts!)

Section 4.5: "see the privacy considerations described in Appendix F."
I think the key privacy considerations are (or should be if something is 
missing) in the security considerations section and not in an appendix.
Appendix F provides useful background and design considerations, but I 
think this reference to appendix F is confusing.

Section 4.3:
I think the section should explicitly say that at most the link-local 
address can use the EUI-64 based interface identifier, by saying that 
any other IPv6 address should use either RFC8064 or RFC7217. I think 
that is the intent, but the wording doesn't make it clear.

Section 4.6 first paragraph:
I don't understand why there needs to be a subnet prefix assigned to the 
ephemeral connectivity between the vehicles in range. AFAIU that is 
router to router communication which can use link-local IPv6 addresses.
The routing protocols I know can operate using link-local addresses.

Section 4.6 third paragraph:
802.11 does not provide reliability for the ND multicast messages.
Thus I don't think OCB is any different than 802.11 in this respect.
I think this paragraph can be removed. If not, it should say the 
opposite of that it says right now.

Section 4.6 forth paragraph:
I don't know why one would have a mobile host directly attached to the 
OCB link. My understanding is that only routers are attached to the OCB 
link. Is that correct?

In summary I think section 4.6 should say that the OCB link might not 
have any IP address prefix apart from the link-local prefix.

If it does have some other IP prefix, then one would need to determine 
who would advertise that/those prefixes (will the infrastructure nodes 
send RAs with prefixes? Each vehicle??)

After the reference to RFC5889 it might make sense to explicitly restate 
this from that RFC:
    o  no on-link subnet prefix should be configured on such an
       interface.

RFC5889 seems to suggest that it would be useful and in some cases 
required to configure a non-link-local address for the OCB interface. 
But such an address would probably need to be checked for uniqness in 
the routing domain, and it isn't clear to me whether that would fit the 
timing requirements for v2x.

Section 5 IPSec and SeND discussion. I'll defer to security experts on 
this. I suspect it requires a separate draft to specify how IPsec and/or 
SeND can be part of a security solution.

Section 5 last paragraph. I think this section should say at the instant 
the MAC address is changed on the OCB interface, the node needs to also 
change all of the IIDs on the OCB interface (link-local and any globals).

Section 5 last paragraph. I don't understand what this text is trying to 
say and I suggest it be dropped:
    On another hand, it may
    have an impact in the way typical IPv6 address auto-configuration is
    performed for vehicles (SLAAC would rely on MAC addresses and would
    hence dynamically change the affected IP address), in the way the
    IPv6 Privacy addresses were used, and other effects.

The actual policy for when the MAC address is changed on the OCB 
interface is presumably to-be-determined. Might make sense to note that 
in the text. I note there is some mention of this in appendix C thus it 
might make sense to add a reference to that appendix.

Appendix C last paragraph:
The "may have an influence" followed by the reference to 4.6 seems to 
imply that something special is going on in section 4.6 which isn't 
there. That's confusing. I suggest dropping that paragraph.

Appendix F.4 uses the term pseudonyme without ever defining it. Hence it 
isn't clear what the stated requirement is.

Appendix H refers to a geolocation database and a GeoIP, yet the 
changelog claims that those concepts have been removed from the 
document. (I don't know how useful appendix H is to an implementor. It 
isn't about how to implement things but what wireshark will show so 
doesn't match the name of the section.)

Appendix I seems misplaced.
If the reader needs to know these terms, then they should be in the 
terminology section and not in an appendix. If the reader doesn't need 
to know then, then they don't need to be in the document.

Note that the document has a lot more of appendix text than body text. 
It is a 15 page document with 25 pages of appendices.
I don't know how useful those appendices will be to a new reader; they 
might have been useful as part of producing the document. But might want 
to consider which part of the appendices are still needed.

    Erik

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 18 Jul 2018 15:18:45 +0000

> OCB link. My understanding is that only routers are attached to the OCB

Typically it will be a router; a router with the OCB interface as the
egress WAN interface, and with Ethernet (including CAN2IP), Wi-Fi
interfaces on the ingress side.

Though nothing stops an OEM to allow an host with Safety applications
directly using the OCB interface for sending/receiving traffic, but I
would not bother to deal with that case, as that is highly unlikely some
one would do that.

Sri

On 7/18/18, 8:03 AM, "its on behalf of Erik Nordmark"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Jul 2018 13:55:18 -0400

> would not bother to deal with that case, as that is highly unlikely some

As long as that node participates in the routing protocol it is OK, 
since that removes the need to assign a subnet prefix to the OCB interface.

The fact that the node doesn't have any downstream networks or hosts 
doesn't matter.

    Erik

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 18 Jul 2018 11:24:07 -0700

Erik,

You've tripped over an important observation.  And I think you're
right.

A lot of the IEEE 1609 conversation circa a couple years ago tacitly
assumed [host--single-link--host] and ignored even the possibility of a
backside LAN in the vehicle.  This oversimplifies the problem and makes
it look like it can all fit in the ethernet technology.  Every time I
asked about multiple segments, I got layer 2 bridging answers (and not
very articulate ones).  Nobody remembered spanning tree so the ringing
implications of that were never considered in the environment.  The
1609 short stack essentially voids layers 3,4,5 so they have to go
through those contortions for completeness.  
   
IMHO, you should worry primarily about router-router (with lots of
multicast) as the main event.  Presence of hosts directly on the radio-
WAN should be simply a degenerate case.

A little out of scope of your question, but the voiding of the
internetworking layers in 1609 did have one beneficial side effect: it
forced the security problem into layers 6/7 where it belongs.  

b

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Jul 2018 15:32:55 -0400

Dick,

if you are in Montreal it would be quicker to chat in the hallway.
Some responses below.

On 07/18/2018 02:33 PM, Dick Roy wrote:

> [RR] No it is not correct in all cases.  It is entirely possible to have 
> a node that consists of a host with an 802.11 MAC&PHY (OCB is 
> irrelevant) as the ingress/egress interface with no router functionality 
> at all.

Fair enough. It's just that you need a completely different approach to 
support nodes which do not run routing protocols (~hosts) than those 
that do.

That makes the overall system more complex, in particular if most of the 
time there will be a router.

> [RR] OCB links do NOT have network layer addresses. OCB links are layer 
> 2 objects and as such, use layer 2 addressing which for all 802 LANs is 
> 802 MAC addressing. Furthermore, not all nodes in a LAN (or VLAN) need 
> network layer addresses.  Bridged LANs are everywhere and .11ak now 
> provides means for using 802.11 links in such LANs!

Note that the definition of "link" is different in the IETF and IEEE 802.

For the IETF definition we do assign IP subnet prefixes to links, 
whether the link is Ethernet or anything else.

For "link" as defined and used in IEEE 802 I agree with you about the 
layer 2 object.

However, if you are considering bridging things then ipwave isn't the 
right place to work on things.

Regards,
    Erik

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 20 Jul 2018 19:17:39 +0200

Hi Dick,

> right place to work on things.

[Carlos] Fully echoing Erik's comment. Just an excerpt from our
charter: " [...] specify the mechanisms for transmission of IPv6
datagrams over IEEE 802.11-OCB mode. [...]".

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 21 Jul 2018 04:50:29 +0200

Hi Dick,

On Fri, 2018-07-20 at 14:44 -0700, Dick Roy wrote:
> I realize the charter says  "OCB mode" and I have fought against that
> from
> day one when we asked the IETF to look into the issue of rapidly
> varying
> network (LAN) topologies, but they just couldn't free themselves from
> such
> constrained thinking.  Oh well :^(((

Rapid varying topologies is not something exclusive of vehicular
networks using IEEE 802.11-OCB. Current charter of ipwave is about to
specify/describe what needs to be done to support basic IPv6 over IEEE
802.11-OCB as layer-2. Let's get this done, and then, if the community
is interested and show enough energy, we can talk about tackling more
complex networks (and see if the IESG thinks this WG is the right place
to do it).

Thanks,

Carlos

> 
> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
> Sent: Friday, July 20, 2018 10:18 AM
> To: Erik Nordmark; [email-masked]; 'its'
> Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-
> 25
> 
> Hi Dick,
> 
> > > [RR] No it is not correct in all cases.  It is entirely possible
> > > to
> > > have 
> > Fair enough. It's just that you need a completely different
> > approach
> > to 
> > That makes the overall system more complex, in particular if most
> > of
> > the 
> > Note that the definition of "link" is different in the IETF and
> > IEEE
> > 802.
> >