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

[Nabil Benamar <[e-mail]>]

Hi Jaehoon,

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

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

On Mon, Apr 4, 2016 at 10:55 PM, Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> 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.*
>>
>
​Indeed, site local have already been replaced by ULAs​


>
>> *“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 mean that when you use DHCPv6 that means that your DHCP sever will send
all the configuration ​details needed (IPv6@ + prefix length +gw + @DNS) if
the M flag is enabled, which means that there is no "auto" configuration!
So the term "auto" in this case should be removed.

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