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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Nabil,
Thanks for your good comments.

I answers your questions and comments in lines with "=>" below.

On Sat, Apr 2, 2016 at 5:04 PM, Nabil Benamar <[e-mail]> wrote:

> 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.*
>
*=> Will be reflected on the revision.*
>
> *“ … 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.*
>
> *=> You are right. I will update it as follows: “... with a consideration
> of the vehicular network's characteristics such as a vehicle's velocity and
> its directed movement along a roadway.”*
>
>
>
*“….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.*
>
*=> Will be reflected on the revision.*
>
>
>
*“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 ? *
>


*=> Yes, DHCPv6-PD can be used as a solution. We may invent another one for
  vehicular networks.**  Also, prefix configuration can be manually done at
the manufacturing time as factory default.*

>
> *“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. *
>
*=> We need to consider three issues, such as IPv6 host DNS configuration,
> DNS name resolution, and DNS name autoconfiguration. *
>
*The first is IPv6 host DNS configuration for Recursive DNS Server (RDNSS)
> and DNS Search List (DNSSL) t**hrough RA Options (RFC 6106) and DHCP
> Options (RFC 3646).*
>
> *The second is DNS name resolution through an appropriate RDNSS w**ithin
> a vehicle’s moving network or an RSU’s fixed network. *
>
> *The third is DNS name autoconfiguration of vehicle and in-vehicle devices
> t**hrough DNSNA (draft-jeong-its-iot-dns-autoconf-00), mDNS (RFC 6762),
> and DNS Update (RFC 2136).*
>
>
> *“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. *
>
*=> Yes, Site-local addressing will be replaced by Unique Local IPv6
> Addresses (ULA) in RFC 4193.*
>
>
> *“DHCPv6 (or Stateless DHCPv6) can be used for the IP address*
>
> *   autoconfiguration [RFC3315][RFC3736] “ *
>
*=> **As an alternative protocol, DHCPv6 (or Stateless DHCPv6) can also 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.  *
>
*=> What do you mean by "**There is no more autoconfiguration when we use
> DHCPv6**"? *
>
*I intend that DHCPv6 can be used for an IPv6 host's address
> autoconfiguration instead of RA. *
>
*Thanks. *
>
*Best Regards,*
>
*Paul*
>


> 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
>>
>>
>


-- 
===========================
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>