Subject: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 14 Apr 2020 15:33:56 +0000

Hi, I read this draft and have some comments. In the aviation domain, we are designing
an Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS)
with the goal of having a worldwide IPv6 Internetwork interconnecting aircraft, air traffic
controllers and other authorized entities. This work is focused in the International Civil
Aviation Organization (ICAO), but is now being brought into the IETF:

https://datatracker.ietf.org/liaison/1676/
https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

However, the vehicular network model we have for the airplanes differs significantly from
the vehicular model in this ipwave draft when in fact I think there should be no difference.

In particular, in the ATN/IPS aircraft are statically configured with a Mobile Network
Prefix (MNP) (sort of like a VIN) that travels with the aircraft wherever it goes. It uses
this MNP to form a unique link-local address, then assigns the address to the OMNI
interface which is a virtual interface configured over the wireless data link interfaces.
Then, on the wireless links themselves, there are no on-link prefixes and no PIOs
advertised by access routers. The wireless links therefore carry only link-local or
MNP-addressed IPv6 packets, therefore no two vehicles will appear to be on the
same subnet and no multi-link issues for subnet partitions and merges occur. Also,
DAD is not needed at all due to the unique assignment of MNPs.

This same model could be applied to ipwave vehicles, and would alleviate the problems
stated in Section 5. In particular, the link model could adopt the OMNI link model (see
the OMNI draft) where all nodes within the transportation system are "neighbors" on
a shared NBMA virtual link. IPv6 ND works with no modifications, and the link model is
always connected. So, there would be no need for vehicular extensions to IPv6 and ND.
Likewise, mobility management services would work the same as the ATN/IPS design
and would not require any adaptations for fast-moving vehicles. 

Final comment for now - the document lists only MIPv6 and PMIPv6 as example
mobility services. We are considering them in the aviation domain, but also have
AERO and LISP as candidate services. Since these would also apply in the ipwave
case, it would be good to list them as candidates here also.

Fred

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2020 10:18:51 -0400

> DAD is not needed at all due to the unique assignment of MNPs.

I think that this is a really good use of IPv6 technology.

    > and would not require any adaptations for fast-moving vehicles.

+1

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 15 Apr 2020 23:35:24 +0900

Hi Fred,
I will include your comments on the aviation domain in the revision of our
IPWAVE PS draft.

Thanks for your valuable input.

Best Regards,
Paul

2020년 4월 15일 (수) 오전 12:34, Templin (US), Fred L <[email-masked]>님이
작성:

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Apr 2020 11:37:26 -0400

Paul:

This needs further mail list discussion, especially the point about ND.

Russ

> On Apr 15, 2020, at 10:35 AM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> Hi Fred,
> I will include your comments on the aviation domain in the revision of our IPWAVE PS draft.
> 
> 2020년 4월 15일 (수) 오전 12:34, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>님이 작성:
> https://datatracker.ietf.org/liaison/1676/ <https://datatracker.ietf.org/liaison/1676/>
> https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/ <https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/>
> https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/ <https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/>
> 
> same subnet and no multi-link issues for subnet partitions and merges occur.. Also,
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 16 Apr 2020 10:46:12 +0900

Hi Russ,
Okay.

IPWAVE WG,
Could you say your preference about including the aviation domain in our
IPWAVE PS draft?

The current IPWAVE charter seems to focus on vehicular networking in road
networks.

My personal opinion is to focus on vehicular networking in road networks
and then
we can extend the scope of IPWAVE WG during the rechartering to accommodate
the aviation domain and the ND there.

Please speak up your voice in this thread.

Thanks.

Best Regards,
Paul

On Thu, Apr 16, 2020 at 12:37 AM Russ Housley <[email-masked]> wrote:

> 2020년 4월 15일 (수) 오전 12:34, Templin (US), Fred L <
> [email-masked] <[email-masked]>>님이 작성:
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate 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>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 16 Apr 2020 14:51:45 +0900

Hi Fred,
I have read your email and your suggested drafts carefully.

Your proposed link model seems very good for a single-hop V2I
communications using OMNI interface
configured with a uniqueness-guaranteed IPv6 link local address and
connected to a vehicle's
internal network (as an end user network (EUN)).

However, considering multihop V2I forwarding or multihop V2V forwarding,
the OMNI link model seems
to be hard to use in vehicular networks in road networks.
This is because the multihop routing usually uses global IPv6 addresses
within multiple multi-link subnets.

This is my suggested ND draft for IPWAVE using a shared global IPv6 prefix:
https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor-discovery-08

Without using global IPv6 addresses in multiple multi-link subsets, it is
hard to limit
IPv6 traffic associated with a specific multi-link subnet like a VPN.

In our IPWAVE PS draft, it will be good to include the discussion of the
OMNI link model.

Thanks.

Best Regards,
Paul

On Thu, Apr 16, 2020 at 10:46 AM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> we can extend the scope of IPWAVE WG during the rechartering to
> accommodate the aviation domain and the ND there.
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 16 Apr 2020 14:07:10 +0000

Hi Paul,

You seem to be missing the concept of the SPAN. The SPAN allows ND messages to go
multiple hops without having the Hop Limit decremented. The SPAN is an encapsulation
sub-layer that uses Unique Local Addresses (RFC4193) having the same uniqueness
property as the link-locals, and can route over multiple hops the same as globals. The
SPAN is discussed in both the OMNI and AERO drafts.

Thanks - Fred

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
Sent: Wednesday, April 15, 2020 10:52 PM
To: Templin (US), Fred L <[email-masked]>
Cc: its <[email-masked]>; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hi Fred,

Your proposed link model seems very good for a single-hop V2I communications using OMNI interface
configured with a uniqueness-guaranteed IPv6 link local address and connected to a vehicle's
internal network (as an end user network (EUN)).

However, considering multihop V2I forwarding or multihop V2V forwarding, the OMNI link model seems
to be hard to use in vehicular networks in road networks.
This is because the multihop routing usually uses global IPv6 addresses within multiple multi-link subnets.

Without using global IPv6 addresses in multiple multi-link subsets, it is hard to limit
IPv6 traffic associated with a specific multi-link subnet like a VPN.

In our IPWAVE PS draft, it will be good to include the discussion of the OMNI link model.

Thanks.

Best Regards,
Paul

On Thu, Apr 16, 2020 at 10:46 AM Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Russ,
Okay.

IPWAVE WG,
Could you say your preference about including the aviation domain in our IPWAVE PS draft?

The current IPWAVE charter seems to focus on vehicular networking in road networks.

My personal opinion is to focus on vehicular networking in road networks and then
we can extend the scope of IPWAVE WG during the rechartering to accommodate the aviation domain and the ND there.

Thanks.

Best Regards,
Paul

On Thu, Apr 16, 2020 at 12:37 AM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
Paul:

Russ

On Apr 15, 2020, at 10:35 AM, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Fred,

Best Regards,
Paul

2020년 4월 15일 (수) 오전 12:34, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>님이 작성:

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

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

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 17 Apr 2020 01:17:16 +0900

Fred,
Yes, I may have missed the concept of the SPAN.
I will review it and come back later.

Thanks.

Paul

On Thu, Apr 16, 2020 at 11:07 PM Templin (US), Fred L <
[email-masked]> wrote:

> *From:* Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
> *Sent:* Wednesday, April 15, 2020 10:52 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* its <[email-masked]>; skku-iotlab-members <
> [email-masked]>; Mr. Jaehoon Paul Jeong <
> [email-masked]>
> *Subject:* Re: [ipwave] Comments for
> draft-ietf-ipwave-vehicular-networking-14.txt
>
>
>
> Hi Fred,

---

From: 김증일 글로벌R&D마스터 <[email-masked]>
Date: Fri, 17 Apr 2020 07:30:50 +0000

Hello, Fred

I think you pointed out the good way to ensure uniqueness of link-local address for vehicle.

Using the VIN to create link-local address sounds good and we can get fast connection by skipping DAD process.

I wonder if it's okay when a vehicle need to have multiple addresses for different services.

Isn't it safe to check DAD for double check?

Kim

김증일([email-masked]<mailto:[email-masked]>) 글로벌R&D마스터 / 전력제어시험팀         

ZEUNG IL (Ben) KIM      Global R&D Master / Electric Power Control Test Team

Automotive Research & Development Division, www.hyundai.com<http://www.hyundai.com>

18280 경기도 화성시 남양읍 현대연구소로 150 Tel: +82-31-5172-3134, Mobile: +82-10 -8805-3810
150, Hyundaiyeonguso-ro, Namyang-eup, Hwaseong-si, Gyeonggi-do, 18280, Korea

________________________________________
보낸 사람: Templin (US), Fred L <[email-masked]>
보낸 날짜: 2020년 4월 15일 수요일 오전 12:33:56
받는 사람: its
제목: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Fred

---

From: William Whyte <[email-masked]>
Date: Fri, 17 Apr 2020 11:58:34 +0000

Using the VIN to create the link-local address would have to be done carefully or it could create significant privacy concerns. In IEEE/ETSI/ISO work on this topic, which is being adopted by USDOT and the European Commission, we’re being careful to avoid having (a) identifiers that are directly derived from something unique to the vehicle and (b) long-lived identifiers, as these identifiers can be used to track system participants. In general we’ve favored generating any lower layer identifiers at random and changing them periodically (on a timescale of minutes rather than seconds or hours). This creates occasional disruptions to long-lived sessions but the tradeoff was considered worth it.

Cheers,

William

From: its <[email-masked]> On Behalf Of ??? ???R&D???
Sent: Friday, April 17, 2020 3:31 AM
To: Templin (US), Fred L <[email-masked]>; its <[email-masked]>
Subject: [EXT] Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hello, Fred

Kim

________________________________________
보낸 사람: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
보낸 날짜: 2020년 4월 15일 수요일 오전 12:33:56
받는 사람: its
제목: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 17 Apr 2020 15:47:08 +0000

Hi Kim, the expectation is that the vehicle would be assigned a unique IPv6 prefix
called the Mobile Network Prefix (MNP) for its own exclusive use, e.g. a /64 or
some other prefix length. That gives the vehicle lots of available addresses which
would not need to undergo DAD.

Thanks - Fred

From: its [mailto:[email-masked]] On Behalf Of ??? ???R&D???
Sent: Friday, April 17, 2020 12:31 AM
To: Templin (US), Fred L <[email-masked]>; its <[email-masked]>
Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hello, Fred

Kim

Fred

---

From: William Whyte <[email-masked]>
Date: Fri, 17 Apr 2020 15:55:56 +0000

Hi Fred - would it be possible for this unique prefix to be re-selected from time to time?

William

From: its <[email-masked]> On Behalf Of Templin (US), Fred L
Sent: Friday, April 17, 2020 11:47 AM
To: 김증일 글로벌R&D마스터 <[email-masked]>; its <[email-masked]>
Subject: [EXT] Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Thanks - Fred

From: its [mailto:[email-masked]] On Behalf Of ??? ???R&D???
Sent: Friday, April 17, 2020 12:31 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; its <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hello, Fred

Kim

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 17 Apr 2020 16:14:05 +0000

Hi William,

You indicated a timescale of minutes (not secs or msecs) and I think that might
be feasible yes. But, it does require more thought.

Fred

From: William Whyte [mailto:[email-masked]]
Sent: Friday, April 17, 2020 8:56 AM
To: Templin (US), Fred L <[email-masked]>; 김증일 글로벌R&D마스터 <[email-masked]>; its <[email-masked]>
Subject: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hi Fred – would it be possible for this unique prefix to be re-selected from time to time?

William

From: its <[email-masked]<mailto:[email-masked]>> On Behalf Of Templin (US), Fred L
Sent: Friday, April 17, 2020 11:47 AM
To: 김증일 글로벌R&D마스터 <[email-masked]<mailto:[email-masked]>>; its <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Thanks - Fred

Hello, Fred

Kim

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 18 Apr 2020 16:10:01 +0000

Time varying prefixes with short leases can be managed with DHCPv6-PD, so there
is no need for the mobile to carry around lots of statically allocated prefixes. The
mobile may  need to renumber its internal networks frequently, but that’s OK.

From: Dick Roy [mailto:[email-masked]]
Sent: Friday, April 17, 2020 9:16 PM
To: Templin (US), Fred L <[email-masked]>; 'William Whyte' <[email-masked]>; '김증일 글로벌R&D마스터' <[email-masked]>; 'its' <[email-masked]>
Subject: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

For the addresses to be unique, each unit (vehicle, smart phone, etc.) would have to be issued a set of unique addresses, which begs the question what’s the cardinality of that set, and how much privacy/anonymity will that provide. In a 64-bit space, there would be plenty of addresses; however address management could be an issue.  Another option is of course random address selection; if the RNGs were good enough, it should work w.p.near1.

RR

________________________________
From: its [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
Sent: Friday, April 17, 2020 9:14 AM
To: William Whyte; 김증일 글로벌R&D마스터; its
Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hi William,

Fred

From: William Whyte [mailto:[email-masked]]
Sent: Friday, April 17, 2020 8:56 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; 김증일 글로벌R&D마스터 <[email-masked]<mailto:[email-masked]>>; its <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

William

Thanks - Fred

Hello, Fred

Kim

Fred

---

From: 김증일 글로벌R&D마스터 <[email-masked]>
Date: Tue, 21 Apr 2020 00:25:11 +0000

Hi Fred

There must be something I misunderstand.

I thought that the IPv6 Link local address prefix is fixed by FE80::/10 and only lower 64bit can be assigned by any method to ensure uniqueness.

If the prefix is defined uniquely by each vehicle, how can they communicate each other through local link?

Best wishes

Kim

________________________________
보낸 사람: Templin (US), Fred L <[email-masked]>
보낸 날짜: 2020년 4월 18일 토요일 오전 12:47:08
받는 사람: 김증일 글로벌R&D마스터; its
제목: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Thanks - Fred

Hello, Fred

Kim

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 21 Apr 2020 14:24:08 +0000

Hi Kim, this is addressed in the drafts I posted. The link-local address is derived from
the unique MNP assigned to the mobile node and is therefore also unique. And, the
scope of the (virtual) link spans the entire its domain and is not restricted to just a
single physical link.

Thanks - Fred

From: its [mailto:[email-masked]] On Behalf Of ??? ???R&D???
Sent: Monday, April 20, 2020 5:25 PM
To: Templin (US), Fred L <[email-masked]>; its <[email-masked]>
Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hi Fred

Best wishes

Kim

Hi Kim, the expectation is that the vehicle would be assigned a unique IPv6 prefix
called the Mobile Network Prefix (MNP) for its own exclusive use, e..g. a /64 or
some other prefix length. That gives the vehicle lots of available addresses which
would not need to undergo DAD.

Thanks - Fred

Hello, Fred

Kim

Fred

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 22 Apr 2020 00:57:47 +0900

Hi Fred,
I sincerely appreciate your good suggestion and comments for our IPWAVE PS
draft. .
I put my comments on your input inline.

> the vehicular model in this ipwave draft when in fact I think there
should be no difference.

I think that your link model based on OMNI and SPAN is a good candidate for
as a vehicular link model.
A mobile node (MNM) with an OMNI interface in your OMNI draft plays a role
of a mobile router,
which is named IP-OBU in the IPWAVE PS draft:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14#page-14

The vehicular network architecture in the IPWAVE PS draft is similar to
your architecture in
the OMNI draft in the following mapping:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14#page-11

+-----------------+---------------------------------+
| IPWAVE PS Draft | OMNI Draft                      |
+=================+=================================+
| IP-RSU          | AR (Access Router)              |
+-----------------+---------------------------------+
| IP-OBU          | MN (Mobile Node)                |
+-----------------+---------------------------------+
| Moving Network  | EUN (End User Network)          |
+-----------------+---------------------------------+
| Mobility Anchor | MSE (Mobility Service Endpoint) |
+-----------------+---------------------------------+
| Vehicular Cloud | INET Routing System             |
+-----------------+---------------------------------+

> interface which is a virtual interface configured over the wireless data
link interfaces.

In the IPWAVE PS draft, there is no discussion on Mobile Network Prefix
(MNP) for
a moving network in a vehicle, but the delegation and configuration of the
MNP can be
included in the IPWAVE PS draft in the next revision.

> DAD is not needed at all due to the unique assignment of MNPs.

The usage of ULA (Unique Local Address) for the OMNI interface in the SPAN
is a good solution for the multihop routing in the entire OMNI link of the
SPAN.
However, this is just a candidate for vehicular networks.
As in the IPWAVE PS draft, a global IPv6 address can also be used for the
wireless link
for IP-OBU and IP-RSU.

There are pros and cons of the OMNI draft and the IPWAVE PS draft.
As you said, indeed, the IPv6 address autoconfiguration based on MNP does
not need DAD
because a unique IPv6 can be derived from the MNP and Interface ID (for MN)
and
the MNP and MSID (for AR and MSE).

However, in V2P (Vehicle-to-Pedestrian Communication) scenario, a
pedestrian's smartphone
needs to have an OMNI interface for the communication through the SPAN even
though
it does not have a moving network inside it.

As described in the IPWAVE draft, if the wireless link uses a global IPv6
prefix,
the smartphone does not need the OMNI link to communicate with a host
within a moving
network in a vehicle.

As a requirement for the IPWAVE draft, we can say that the configuration
and control
overhead for V2P or V2X should be minimized.

> and would not require any adaptations for fast-moving vehicles.

As you said, as another requirement in the IPWAVE draft, we can say that
the
vehicular link model needs to minimize the changes of IPv6, ND, and
Mobility Management.

> case, it would be good to list them as candidates here also.

Sure, the IPWAVE PS draft can have AERO and LISP for mobility services.

Thanks for your good input.

Best Regards,
Paul

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 21 Apr 2020 22:21:51 +0000

Hi Paul,

See below for responses:

>Hi Fred,
>I sincerely appreciate your good suggestion and comments for our IPWAVE PS draft. .

OK.

>A mobile node (MNM) with an OMNI interface in your OMNI draft plays a role of a mobile router,
>The vehicular network architecture in the IPWAVE PS draft is similar to your architecture in

Close enough, yes.

>In the IPWAVE PS draft, there is no discussion on Mobile Network Prefix (MNP) for
>a moving network in a vehicle, but the delegation and configuration of the MNP can be

OK.

>is a good solution for the multihop routing in the entire OMNI link of the SPAN.
>As in the IPWAVE PS draft, a global IPv6 address can also be used for the wireless link
>for IP-OBU and IP-RSU.

The OMNI MN model can apply to any category of MN, from large vehicles
down to individual pedestrians with pros and cons to consider as you say.
But, it is not necessarily for vehicles only.

>As you said, indeed, the IPv6 address autoconfiguration based on MNP does not need DAD
>because a unique IPv6 can be derived from the MNP and Interface ID (for MN) and
>However, in V2P (Vehicle-to-Pedestrian Communication) scenario, a pedestrian's smartphone
>needs to have an OMNI interface for the communication through the SPAN even though

The pedestrian's smartphone can act like a MN the same as for an auto,
truck, taxi, bicycle, etc. And, can then use the MNP to number any attached
devices (bluetooth, etc.) and/or any virtual internal networks and/or
applications. So, the MN does not need to have a physical moving network
inside but can still benefit from having a MNP.

>As described in the IPWAVE draft, if the wireless link uses a global IPv6 prefix,
>the smartphone does not need the OMNI link to communicate with a host within a moving
>network in a vehicle.

There can be considered to be two classes of nodes - those that connect to
the OMNI link, and those that connect only to the global IPv6 Internet. The
two classes of devices can communicate with each other via a "gateway"
provided by the OMNI link mobility service, but only those on the OMNI
link are able to benefit from a true multilink capability.

>As a requirement for the IPWAVE draft, we can say that the configuration and control

If so, it would be good to balance it with a discussion of the benefits
offered by the OMNI multilink service.

>As you said, as another requirement in the IPWAVE draft, we can say that the
>vehicular link model needs to minimize the changes of IPv6, ND, and Mobility Management.

OK.

>Sure, the IPWAVE PS draft can have AERO and LISP for mobility services.

OK.

Thanks - Fred

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 23 Apr 2020 00:19:10 +0900

Fred,
I think all your responses below  make sense.
I will try to  address all your comments on the revision of our IPWAVE PS
draft.

Thanks.

Paul