Most of the VPN protocols in use have evolved to accommodate the very common scenario where one side of the tunnel
is dynamically addressed, and usually Network Address Translated (NAT). However, when both sides are dynamic, or behind NAT, it presents a challenging problem.
The typical answer I hear was repeated on the forum several times, which is to use a third-party service that acts like DNS, resolving IP addresses -- except that it provides a way to keep track of dynamic addresses for people who don't actually own the address (it's owned by their ISP, which prohibits them from using a legitimate DNS domain and regular DDNS). There are several of these services mentioned, and depending on your organization and what your budget is, and support requirements, and tolerance for risk, this can be a good option. However, it's not typically something that would be well-received in an enterprise environment.
There is another way to connect two sites that both have dynamic addressing: Have both of them initiate the connection to a third, static, site. This also has pros and cons, of course. The downside is that you potentially have an additional hop that can be a bottleneck and will almost definitely add latency. If you don't already have a static site on the Internet, then it would be an extra expense, too, although not necessarily a large one. You'll also need a routing protocol, where you could previously get by with static routing.
While this isn't typically a problem for the enterprise space, as they usually have numerous data centers with fixed addresses, VPN services and a traffic model where all the clients talk to the centralized servers, it could become an issue if more of the peer-to-peer technologies gain traction. Even then, an internally controlled DDNS would be a preferable solution. But for smaller organizations on a budget, hopping through a known, fixed address can be a compelling alternative.