Re: [its] Comments for a New Draft of Problem Statement for V2I Networking

[Nabil Benamar <[e-mail]>]

Hi Jaehoon,

Here are some comments:

*Introduction*


*  “ Recently,…..”  This is not recent since the works on VANETs and its
use cases have been done for a while … such as driving safety, efficient
driving, and entertainment! There are a lot of journal papers tackling in
details this topic.*

*This section can be modified as follows: *

*Vehicular Networks have become a popular topic during the last years due
to the important applications that can be realized in such environment.*


*“ … with a consideration of the vehicular network's characteristics such
as a vehicle's velocity and collision avoidance.”*


*Collision avoidance is a consequence and a goal to attend and not a
characteristic of this IEEE standard.*


*“….IPv6 [RFC2460] is suitable for vehicular networks since the protocol
has*

*   abundant address space, autoconfiguration features, and protocol
extension ability through extension headers.”*


*Better to mention the draft
‘https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-03
<https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-03>’   as a
supporting reference here.  *


*“it is assumed that the prefix assignment for each subnet inside*

*   the vehicle's mobile network and the RSU's infra-node network through*

*   a prefix delegation protocol.”*


*Prefex delegation is only possible through DHCPv6-PD, is this what you
mean ?*


*“Also, the DNS naming service should be supported for the*

*   DNS name resolution for a host or server in either the vehicle's*

*   mobile network or the RSU's infra-node network.”*


*So what could be the issue here ? Is DNS an issue? DNS information are
included in RA with the flag “O” enabled.*


*“The former approach is*

*   usually used by Mobile Ad Hoc Networks (MANET) for a separate multi-*

*   link subnet.”*


*Site local addressing is deprecated RFC 3879…so no need to mention it in
the current draft.*


*“DHCPv6 (or Stateless DHCPv6) can be used for the IP address*

*   autoconfiguration [RFC3315][RFC3736] “*


*There is no more autoconfiguration when we use DHCPv6…So this sentence
should be corrected accordingly.*

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

http://nabilbenamar.ipv6-lab.net/

On Wed, Feb 24, 2016 at 8:57 AM, Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> Hi Richard,
> I will check the IOS standards related to ITS, which are pointed by you.
>
> I agree with you that you need to use well-known terminology for our ITS
> work.
>
> For 802.11p, as I know, both industry and academia are considering it as
> Dedicated Short-Range Communications (DSRC) for vehicular networking.
>
> Thanks.
>
> Best Regards,
> Paul
>
>
> On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy <[e-mail]> wrote:
>
>> Alex/Paul,
>>
>> I suspect much of what you are thinking needs standardization below has
>> already been standardized.  You might want to check out ISO 21217 (ITS
>> station/communication architecture), followed by ISO 21210 (IPv6
>> networking
>> for ITS).  If nothing else, we already have terms for all of the
>> configurations you describe below (see ISO 21217).  It would be best to
>> stick with this now well-known terminology.
>>
>> By the way, none of this depends on 802.11 5.9GHz in the data link and
>> physical layers.  I continue to wonder why 802.11p ever comes up.  It
>> could
>> just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or
>> whatever ...
>>
>> Cheers,
>>
>> RR
>>
>> > -----Original Message-----
>> > From: Alexandre Petrescu [mailto:[e-mail]]
>> > Sent: Wednesday, February 17, 2016 4:22 AM
>> > To: Mr. Jaehoon Paul Jeong
>> > Cc: [e-mail]
>> > Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I
>> > Networking
>> >
>> > Hello Paul,
>> >
>> > Thanks a lot for this draft.  This V2I problem statement covers many
>> > things we have discussed in Yokohama.
>> >
>> > What do the others think about this draft?
>> >
>> > I hame some comments, see below.
>> >
>> > Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a écrit :
>> > > Hi ITS Colleagues,
>> > >
>> > > Title: Problem Statement for Vehicle-to-Infrastructure Networking
>> > > I-D: draft-jeong-its-v2i-problem-statement-00 Link:
>> > > https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-00
>> > >
>> > > Abstract This document specifies the problem statement for
>> > > IPv6-based vehicle- to-infrastructure networking.  Dedicated
>> > > Short-Range Communications (DSRC) is standardized as IEEE 802.11p for
>> > > the wireless media access in vehicular networks.  This document
>> > > addresses the extension of IPv6 as the network layer protocol in
>> > > vehicular networks and is focused on the networking issues in
>> > > one-hop communication between a Road-Side Unit (RSU) and vehicle.
>> > > The RSU is connected to the Internet and allows vehicles to have the
>> > > Internet access if connected.  The major issues of including IPv6 in
>> > > vehicular networks are neighbor discovery protocol, stateless
>> > > address autoconfiguration, and DNS configuration for the Internet
>> > > connectivity over DSRC.  Also, when the vehicle and the RSU have an
>> > > internal network, respectively, the document discusses the issues of
>> > > internetworking between the vehicle's internal network and the RSU's
>> > > internal network.
>> > >
>> > > If you have comments or questions, please let me know.
>> >
>> > You can use the documentation prefixes 2001:db8:1000::/63 (instead of
>> > real addresses like 2001:1000::/63).
>> >
>> > The term "RSU infra-node network" is something new and may need to be
>> > present in the definitions section.
>> >
>> > If I understand you correctly, the RSU infra-node network is a network
>> > of IP-addressable devices which are present in the Road-Side Unit -
>> right?
>> >
>> > I am asking because I know some such RSUs on the market which contain
>> > several IP-addressable devices linked together, but we dont have a name
>> > for them.  The "RSU infra-node network" sounds good, I think.
>> >
>> > For the term "mobile network" - we can rather use maybe
>> > "moving network".
>> >
>> > In section 5 "Internetworking between the Vehicle and RSU networks":
>> > > Problems are a prefix discovery and prefix exchange.  The prefix
>> > > discovery is defined as how routers in a mobile network discover
>> > > prefixes in the mobile network.  The prefix exchange is defined as
>> > > how the vehicle and the RSU exchange their prefixes with each other.
>> >
>> > I agree with the problem of prefix exchange.
>> >
>> > For the "prefix discovery", I have some doubts.
>> >
>> > First, the routers inside the moving network can be pre-configured with
>> > the prefixes inside that moving network.  If so, then there can be no
>> > need for these routers to discover the prefixes inside the same moving
>> > network.  But, of course, if they are not preconfigured then they have
>> > to be discovered somehow.
>> >
>> > Second, there is a need for one router (the mobile router?) in the
>> > moving network to discover several parameters of a nearby moving
>> > network, and also the parameters of a "RSU infra-node network".  These
>> > parameters, including the IP prefix of the other network, are listed in
>> > draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem".  It
>> > would be good to use same terminology for this discovery.
>> >
>> > > This section discusses IP addressing for V2I networking.  There are
>> > > two policies for IPv6 addressing in vehicular networks.  The one
>> > > policy is to use site-local IPv6 addresses for vehicular networks
>> > > [RFC4291].
>> >
>> > Since the site-local IPv6 addresses (fec0::) have been deprecated, it
>> > would be appropriate to mention "Unique Local Addresses" (ULAs) which
>> > can somehow play the role that seems to be needed here.  I suggest to
>> > substitute ULA for site-local addresses.
>> >
>> > > The former approach is
>> > >    usually used by Mobile Ad Hoc Networks (MANET) for a separate
>> multi-
>> > >    link subnet.
>> >
>> > MANET has a certain meaning at IETF: it's the WG MANET.  I dont think
>> > there is any MANET draft that recommends ULAs (but maybe they recommend
>> > site-locals?).  Maybe ask the MANET WG what is the MANET IP Addressing
>> > Architecture (do they use ULAs?  do they use GUA - globals?).  If yes
>> > then refer to MANET WG document here.
>> >
>> >  > Sections 7 ND, 8 address autoconf, 9 DNS
>> >
>> > I agree with these sections 7, 8 and 9.
>> >
>> > > 10.  IP Mobility Support
>> > >
>> > >    This section discusses an IP mobility support in V2I networking.
>> In
>> > >    a single subnet per RSU, vehicles keep crossing the communication
>> > >    coverages of adjacent RSUs.  During this crossing, TCP/UDP sessions
>> > >    can be maintained through IP mobility support, such as Mobile IPv6
>> > >    [RFC6275].  Since vehicles move fast along roadways, this high
>> speed
>> > >    should be configured for a parameter configuration in Mobile IPv6.
>> > >
>> > >    To support the mobility of a vehicle's mobile network, Network
>> > >    Mobility (NEMO) protocol can be used [RFC3963].  Like Mobile IPv6,
>> > >    the high speed of vehicles should be considered for a parameter
>> > >    configuration in NEMO.
>> >
>> > I agree.
>> >
>> > I would like to add the following:
>> >
>> > 1. When Mobile IPv6/NEMO is used by the Mobile Router connected to
>> >     the RSU infra-node a tunnel is established between the MR and its
>> >     Home Agent in the TCC (Traffic Control Center).  If a node inside
>> >     the moving network (not the MR) needs to exchange data with a node
>> >     within the RSU infra-node network then that communication must
>> >     go through the Home Agent.  The delays on the path to the HA may be
>> >     too high for the reactivity needed between a vehicle and an RSU, or
>> >     the path can even be blocked.  For this reason it is necessary to
>> >     accommodate direct communications (skip the HA) between a node in
>> >     the moving network and a node in the RSU infra-node network.  This
>> >     can be achieved only if the two networks learn each other's
>> prefixes.
>> >
>> > 2. A new method of connecting the moving network directly to the RSU
>> >     infra-node network may lead to modifying the addressing architecture
>> >     in the moving network.  This can become a problem to the use of
>> >     Mobile IP, because Mobile IP relies on the addressing architecture
>> >     controlled by the Home Agent.  This problem should be solved as
>> well.
>> >
>> >
>> > In section 11 Security Considerations:
>> > > 11.  Security Considerations
>> > >
>> > >    The security is very important in vehicular networks for V2I
>> > >    networking.  Only valid vehicles should be allowed to use V2I
>> > >    networking in vehicular networks.  VIN and a user certificate can
>> be
>> > >    used to authenticate a vehicle and the user.
>> > >
>> > >    This document shares all the security issues of the neighbor
>> > >    discovery protocol.  This document can get benefits from secure
>> > >    neighbor discovery (SEND) [RFC3971]
>> >
>> > Recent works in security for vehicular networks mention two additional
>> > things that are worth considering:
>> >
>> > 1. the use of TLS certificates for vehicle communications
>> >     draft-lonc-tls-certieee1609-01
>> >
>> > 2. privacy considerations: a new ETSI activity may consider privacy
>> >     aspects of identifier generation in vehicular communications.
>> >
>> > It is worth referring to these aspects (give references).
>> >
>> > Yours,
>> >
>> > Alex
>> >
>> >
>> >
>> > >
>> > > Thanks.
>> > >
>> > > Best Regards, Paul -- =========================== Mr. Jaehoon (Paul)
>> > > Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan
>> > > University Office: [phone] Email: [e-mail]
>> > > <mailto:[e-mail]>, [e-mail]
>> > > <mailto:[e-mail]> Personal Homepage:
>> > > http://iotlab.skku.edu/people-jaehoon-jeong.php
>> > > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>> > >
>> > >
>> > > _______________________________________________ its mailing list
>> > > [e-mail] https://www.ietf.org/mailman/listinfo/its
>> > >
>> >
>>
>>
>>
>
>
> --
> ===========================
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software
> Sungkyunkwan University
> Office: [phone]
> Email: [e-mail], [e-mail]
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>
>