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

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

Nabil,
I will replace Site-local addresses with ULA in the revision.

For DHCPv6, I will replace autoconfiguration with configuration as follows:

As an alternative protocol, DHCPv6 (or Stateless DHCPv6) can also be used
for the IPv6 host address configuration [RFC3315][RFC3736].

Thanks.

Paul

On Tue, Apr 5, 2016 at 8:28 AM, Nabil Benamar <[e-mail]> wrote:

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


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