Google IPv4 Addressing
Google Apps co-exists with consumer accounts in a multi-tenant serve environment, meaning the IPv4 addresses for both platforms are shared. At any given time, an IPv4 address for Google Sheets could be the same as the one for Google Photos. In addition, the address used to serve data for a specific hostname like mail.google.com may be delivering data for multiple platforms at the same time. As a result, IPv4 addresses are valid only for their time-to-live (TTL) values returned in the DNS lookup of the hostnames. Some addresses may be valid for a little as two and a half minutes.
Since addresses are not static, it’s not recommended that you use IPv4s to permit access to the Google Apps platform in your network. If you need to set up your mail gateway to accept Google Mail traffic, you can instead use this guide to include all the servers’ subnets. IPv4 addresses can be used for Internet traffic redirection and prioritization if you’re aware of the implications of Google Global Cache.
Using Google Host Names
In order to serve the wide array of platforms Google offers over the Internet, the company owns many different hostnames. The speed and reliability that regular users experience using Google Apps and other tools day after day comes from very advanced network engineering and optimization. Due to this setup, it’s not a good idea to use Google’s hostnames for allowing access. Like IPv4s, hostnames should be used for traffic redirection and prioritization as providing a comprehensive list of hostnames for all Google services is impractical.
Google Global Cache
Google Global Cache, or GGC, is a content delivery system that’s used by many of Google’s services and applications. It’s designed to provide the best service for all users by deploying the knowledge and teachings from Google’s network engineering teams. The participants in GGC, which include network providers and ISPs, serve Google content from inside their own servers. This allows users who are far away from Google’s data centers to access the content they quickly and reliably from a close location. The use of GGC is why it’s not a good idea to configure your network using IPv4s or hostnames as these are dynamically shifted according to network conditions.
Protocols for API, Google Voice and Video
The services delivered with Google Apps are mostly API-based or web-based. Mail, calendar, docs, sites, Sync for Microsoft Office, and Connector for Blackberry Enterprise Server all use TCP on port 443. The migration tools for Microsoft Exchange and Lotus Tools use TCP (API) on port 443. Google Talk voice and video as well as hangouts have special properties.
Google Talk Voice and Video
When a user attempts to make a video or voice call using Google Talk, the plugin tries to make a connection between the caller and the callee using protocols that are optimum for the current network conditions. The software can make the connection using many different protocols and endpoints. In order of preference, they include:
Direct UDP using STUN on random ports
UDP using a NAT-table traversal
UDP through a Google relay server
Direct TCP connection
TCP through a Google relay server
SSL over TCP through a Google relay server
In order to make these connections work on your network, you’ll need to setup your firewall so that it allows outgoing UDP connections. If you have security or other important reasons for not allowing UDP, you need to allow TCP connections on ports 80 and 443. The quality of video and audio over TCP will likely be worse for users than UDP. The code using for establishing and negotiating call through Google Talk comes from the open source libjingle library. You can get detailed information about the library by visiting the Google Code Project Page.
Whenever you need more detailed information about addresses and protocols for Google Apps, you can visit Google’s support network or come to us. In the next post, we’ll go over the things your organization needs to know about network routing.