Allow me to discuss your initial assumption a bit more. Is the user part of your organization, as used in rfc1918? If you're not in the same organization as each other, then this sort of sharing of non-routable IP addresses across organization boundaries is not really anticipated by rfc1918. If you can claim that the endpoint devices are part of your organization, then perhaps an argument can be made. But that implies there is no collaborative coordination of IP space, but rather direct control by a controlling authority. This kind of control does happen when an SP like Comcast/twtelecom assigns an rfc1918 IP to the EMTA at a customer premise. The customer has no control at all, and can actually safely reuse any private IP address he wishes without interfering with the SP. Collaboration breaks down if you don't have a unified way to guarantee uniqueness across BOTH organizations. And I've seen this fail. Rfc1918 itself gives examples of the limitations of using private IP address space. If you cannot control the use of the rfc1918 space in both organizations, it's better to use public IPs on the inter-organization interfaces, with ALG or quality NAT on the endpoints.
mark at ecg.co +12293160013 http://ecg.co/lindsey
On Aug 13, 2013, at 10:19, Bob Hancock <bobhancock205 at gmail.com> wrote:
I have a project in which a user is interesting in interconnecting and deploying ATAs for VoIP services but wants to use private IP addressing on the devices.