New service decision: IPv6 or IPv4?
Solution 1:
Both of course. IPv4 will stay a long time, and it's way past time to start with IPv6.
Solution 2:
IPv4 and IPv6 are separate protocols that don't talk to each other. You'll have to support both protocols for now.
Getting IPv4 addresses is getting more difficult and expensive, but you'll have to make your service available over it because not all users will have IPv6. On the other side there will be users who don't have full IPv4 anymore. They might have to share their IPv4 address with many others, they only have IPv6 and need a translation service to reach IPv4 services etc. For those users and for future users you want to offer your service over IPv6 so that they can reach it in the most optimal way.
And hopefully in the not-so-distant future everybody will have IPv6 and we can get rid of IPv4 and the hacks and costs required to keep it working.
One way you could start your new service is to build everything for IPv6-only and put a translator (SIIT-DC or reverse proxy) next to it to translate incoming requests over IPv4 to IPv6. You'll be able to handle both protocols for now, and it will also be easy to clean up and remove the obsolete IPv4 stuff later.
This strategy is especially useful if your service runs on a cluster of servers. The whole cluster can run IPv6-only and you need only one IPv4 address on your translator. It's easier to only have to maintain one protocol on the majority of your machines and requiring less IPv4 addresses can also save you money. That's why companies like Facebook are doing this as well.
Solution 3:
While hosting new service these days, what would be best decision. IPv4 or IPv6 ?
Assuming this is a service intended for use over the public internet by clients on machines or networks outside your control you should support both.
How easy/difficult to get IPv4 address (considering they getting exhausted out soon)?
For individual addresses you generally rent them from your hosting provider, most providers still include one with each server, but some are starting to charge extra for it. As the market price of IPv4 addresses rises we can expect the rental fees charged by service providers to rise too.
If you need blocks to run your own network things get harder. There is a market in IP blocks but AIUI it's more like buying real eastate than buying servers. In Europe it's also possible to register as a LIR and get a "final allocation" from RIPE, the downside of that approach is the ongoing fees (fees for a LIR are much higher than for "provider-independent" allocations).
Update: RIPE's pool for "final allocations" is now exhausted too.
Can it be ported easily to IPv6 in coming future?
IPv6 addresses are bigger than IPv4 ones so anything that stores IPs in a fixed-size field (whether text or binary) is problematic. Similarly IPv6 addresses in text form use colons rather than dots so anything that stores IP addresses in a structured text format is potentially problematic.
It is almost certainly easier to support both from the start than to try and track down every place IP addresses are stored and processed after the fact.
How can existing IPv6 users be able to communicate with it?
Currently a large proportion of the Internet is v4 only, so providers have to provide some means for their clients to access v4 only resources. Increasingly as IPv4 addreses get more expensive and harder to obtain they will be looking for mechanisms that allow them to do this without giving each customer a dedicated public IPv4 address.
There are a variety of approaches to this, including conventional IPv4 NAT at the ISP level, DS-Lite which tunnels IPv4 packets to a special IPv4 NAT over IPv6 and NAT64 which translates IPv6 packets to IPv4 packets. All of them will come at a cost in performance, reliability and ability to trace abuse.
How can existing IPv4 users be able to communicate with it?
Unlike in the previous case this is mostly your problem. Some clients may use teredo but windows disables teredo by default when it detects a domain controller and most other operating systems didn't support it out of the box at all. Even when teredo is enabled it's not exactly the most reliable mechanism.
So if you want your service to work for the majority of Internet users you need to offer it on IPv4.
That doesn't necessarily mean your servers have to support IPv4 though. For example if you front with a CDN like Cloudflare or Akamai then the CDN can receive the traffic over IPv4 and forward it to you over IPv6. I am also aware of one hosting provider that offers a free reverse proxy service for this customers. I expect such things to become more common as the price of IPv4 addresses and the proportion of clients supporting IPv6 both rise.