Subject: [ipwave] Comments on draft-ietf-ipwave-vehicular-networking-04

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

Here are some comments mostly around IP address management, neighbor 
discovery, and routing.

I have not looked at the details for the proposals around geographic 
routing, but our collective experience and discussion of this in the 
IETF seems to indicate that geographic routing is difficult to deploy.
I suspect we can solve this using existing mechanisms (such as PMIP-like 
solutions, or overlay networks, plus existing routing protocols on the 
OCB interfaces.)

Level 0: Section 4 is titled "Analysis for Current Protocols", but it 
doesn't appear to discuss gaps in currently implemented and deployed 
protocols, but discuss some set of proposals for new protocols or 
protocol changes/extensions.

That confusing makes it hard to use this document as input to gap 
analysis and rechartering.

So while it is useful to have an inventory of various proposals, I'd be 
more comfortable with a gap analysis of what can't be done using 
existing RFCs.

---

The document, just like the 80211-OCB document, doesn't state whether 
there is an assumption that only routers have OCB interfaces. That has 
significant impact on address configuration and neighbor discovery (and 
the associated bringup and convergence time when there is a change in 
connectivity.)

I think it would be required to make an explicit and well-motivated 
choice in this space.

Section 4.2.1.2.  V2V-based Internetworking

Shows as an example that 2001:DB8:1:1::/64 is assigned to the OCB link.
I do not think it is useful to assing a global prefix to this very 
ephemeral link. Routing protocols can use link-local addresses.

Section 4.1.5 DNS
This seems to assume that somehow the applications in one vehicle would 
somehow know the names of hosts or services in an adjacent car. That 
doesn't seem realistic.

I suspect that V2V applications will need some multicast or anycast 
discovery of services, and not rely on domain names.

Section 5.1.1.  Link Model

This statement is factually incorrect:
    Also, in an IPv6 link, it is assumed that all interfaces which are
    configured with the same subnet prefix are on the same IP link.

RFC4861 has an on-link bit for each prefix which allows e.g., stateless 
address autoconfiguration while not assuming a subnet prefix per link.
RFC6775 shows an example where there is a subnet prefix spanning 
multiple links.

*If* there is a need to not run routing protocols on the OCB interface, 
then I would strongly suggest that the working group look at RFC6675bis 
as a way to avoid the subnet prefix per link and avoid the 1 second DAD 
delay in RFC4862.
However, if a routing protocol will be used then this isn't needed since 
no prefix (apart from link-local fe80::/64) is needed in that case.

Based on that I'm not convinced of this statement in the section:
    Thus, IPv6 ND should be extended to support the concept of a link for
    an IPv6 prefix in terms of multicast in VANET.

Section 5.1.2.  MAC Address Pseudonym

The draft seems to suggest that after the MAC and IP addresses have been 
changed, existing sessions should exchange their new IP addresses to 
provide session continuity.
If that is done without strong end-to-end confidentiality there is no 
privacy benefit to changing the MAC and IP addresses, since an observer 
can see the change in the IP addresses.

I suspect some VPN or encrypted overlay technology is needed to be able 
to provide these privacy benefits while providing session continuity.

Section 5.1.3.  Prefix Dissemination/Exchange
seems to argue that neighbor discovery should become a routing protocol.
That seems unwise because we already have a large body of routing 
protocols with different characteristics and some security support.

Thus it doesn't seem useful to try to extend neighbor discovery in that 
direction.

Section 5.1.4.  Routing
Note that DAD can be avoided on router-to-router links.
If you do need a faster DAD there is the alternative in RFC6775.

---

    Erik

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 20 Jul 2018 08:27:23 -0400

Erik,
Thanks for your intensive review on this Problem Statement (PS) draft.
I put my answers inline.

On Wed, Jul 18, 2018 at 2:49 PM, Erik Nordmark <[email-masked]> wrote:

> routing, but our collective experience and discussion of this in the IETF
> seems to indicate that geographic routing is difficult to deploy.
> solutions, or overlay networks, plus existing routing protocols on the OCB
> interfaces.)
>

> => Geographic routing is not in the scope of our IPWAVE, but it will be
> useful to route an event or notification
>
         message to vehicles around a geographic position, such as an
accident area.

> protocols, but discuss some set of proposals for new protocols or protocol
> changes/extensions.
>
> That confusing makes it hard to use this document as input to gap analysis
> and rechartering.
>
> more comfortable with a gap analysis of what can't be done using existing
> RFCs

    => The current protocols are about academia research papers rather than
IETF protocols.
          The gap analysis using existing RFCs will be enhanced in the next
revision.

> significant impact on address configuration and neighbor discovery (and the
> associated bringup and convergence time when there is a change in
> connectivity.)
>
> I think it would be required to make an explicit and well-motivated choice
> in this space.
>

    => Both routers as RSUs and vehicles have OCB interfaces for wireless
vehicular networks.
          I will include the assumption explicitly in the next revision.

>     => In pure V2V, you are right. Link-local addresses are enough.
         However, in our vehicular network architecture in Figure 1 in the
PS draft,
         V2V and V2I are supported together, so a global prefix will be
useful.

> somehow know the names of hosts or services in an adjacent car. That

    => If in-vehicle devices use DNSNA protocol (in
draft-jeong-ipwave-iot-dns-autoconf-03) and
          vehicular ND (in draft-jeong-ipwave-vehicular-neighbor-discovery-03),
the DNS names of
         those devices are registered into a DNS server within a vehicle
(or RSU), and the services
         of in-vehicle devices in another vehicle are advertised to other
vehicles.
         In this case, such an assumption is valid.

> discovery of services, and not rely on domain names.

    => In Section 4.1.6 (Service Discovery), DNS-SD and Vehicular ND can be
used for service discovery based on
         multicast. Both port numbers and DNS names for services can be
used for service discovery.
         Eric,
         your comment here is not clear to me.

>    configured with the same subnet prefix are on the same IP link.

     => The statement can be revised as follows:
           Also, in the concept of IPv6 link model, it is assumed that all
interfaces which are
           configured with the same prefix with on-link bit set can
communicate with
           each other on an IP link or extended IP links via ND proxy.

          Is it better?

> RFC6775 shows an example where there is a subnet prefix spanning multiple
> links.
>
> then I would strongly suggest that the working group look at RFC6675bis as
> a way to avoid the subnet prefix per link and avoid the 1 second DAD delay
> in RFC4862.
>

     => Eric,
           I will look at RFC 6775 (RFC6775bis) and RFC 4862 according to
your suggestion
           in non-routing protocol scenario.

>    an IPv6 prefix in terms of multicast in VANET.

    => This statement is clarified as follows:

         Thus, IPv6 ND should be extended to support a multi-link subnet
with the same prefix
         with on-link bit set in a connected VANET, consisting of vehicles
interconnected
         with DSRC communication range.

> privacy benefit to changing the MAC and IP addresses, since an observer can
> see the change in the IP addresses.
>

    => That is a good point.
          I will address this privacy issue of strong end-to-end
confidentiality in the revision.

>
> I suspect some VPN or encrypted overlay technology is needed to be able to
> provide these privacy benefits while providing session continuity.
>
>
>      => You are right, but the consolidation of ND and routing
functionality can help
           the reduction of control traffic in vehicular networks.
           So we need to study how to consolidate them in an efficient way.

> If you do need a faster DAD there is the alternative in RFC6775.

     => I will include this DAD optimization in the revision.

          Thanks.

          Paul

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

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>