I'm not sure that I completely understand the problem you are describing,
but I've run into things along these lines especially when dealing with
mergers, acquisitions, and divestitures. In the longer run, this appears to
be one of the reasons that IPv6 architects are deprecating use of their
equivalents of RFC 1918 space, and giving everyone unique space, especially
in the lower-order parts of an address. The higher-order bits (Top-Level
Aggreggation Identifier and Next-Level Aggregation Identifier; TLA and NLA)
are needed if and only if you need to connect to the public internet, and,
while it isn't always the solution, there is a Router Renumbering Protocol
that will let you acquire the TLA/NLA dynamically when connecting to a new
I simply don't know how well dynamic router renumbering will work with
things like route maps, queueing, etc.
The more you do in DNS, the more you are independent of public/private IPv4
and IPv6 collisions.
While I'm on the issues of dynamic addressing, v4/v6, do remember that it is
almost always best to do dynamic DNS update whenever you assign an address,
so you can find it when troubleshooting. Dynamic DNS update, in turn, needs
to be secure; there are RFCs both for dynamic update and for overall secure
# S. Thomson, Y. Rekhter, J. Bound. (April 1997), P. Vixie, ed., Dynamic
Updates in the Domain Name System (DNS UPDATE), RFC2136
# B. Wellington (November 2000), Secure Domain Name System (DNS) Dynamic
Secure DNS is becoming more and more of a reality; there was a U.S. policy
directive, the details of which aren't fully clear, that there must be some
digital certificates at least for the .gov TLD, and possibly lower level
Anyway, there are a variety of solutions to the problem of traversing
internets with private address space, and they don't always mean natting.
Tunneling and VPNs are other tools that can help. For example, I had a
situation, some years back, where two companies, both using RFC1918 address
space and both in the 10.0.0.0/8 block, merged. In the immediate term, we
established a backbone block in 172.16.0.0/12 that didn't conflict with
either assignment, and put things like Internet access, firewalls, and other
Let's assume that both merged companies had offices in New York and London.
This was before BGP/MPLS VPNs were widely implemented, which could have
helped by using Route Distinguishers to disambiguate the address collision.
One company had been using RIP and the other IGRP, and everyone agreed we
wanted to use OSPF anyway, so we took advantage of OSPF authentication in a
We started converting each company private address space to an OSPF domain,
as well as a third domain for the backbone, with each domain having a
different cleartext authentication password. That was our short-term
equivalent of route distinguishers, so routing data from one domain didn't
leak into the others.
Next, since they did have some Novell and SNA trafic at the time, I used GRE
to interconnect the islands of 10/8-Compamy A, and 10/8-Company B, as tunnel
interfaces running either through the other company address space, and, as
quickly as we could, the 172.16/12 backbone block.
For the interim, this meant that we didn't have to solve every collision in
the short term. A short-term priority, at least for the IP side, was to get
every possible address, including servers, into DHCP so we could minimize
the number of places that addresses needed to be maintained. For routers, we
had to work with config files, but put them into a *N*X server where we
could use make, sccs, tftp, etc., and do global changes over a set of
configuration files. I described some of this in
# H. Berkowiitz. (January 1997), Router Renumbering Guide, RFC2072
The essential thing to remember is NAT, VPN, DNS, DHCP, IPv6, etc., are all
tools. Before selecting the tools to build a house, you have to have plans,
and before you can have plans, you need to describe the end user, probably
business oriented requirements to an architect who matches up the user
requirements with the requirements of construction (yes, this is a very
You are speaking so much in terms of tools, such as NAT and firewalls, that
I can't understand what [connectivity] problems you are trying to solve.
From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx]
Sent: Wednesday, August 27, 2008 8:01 AM
Subject: Re: natting [7:132379]
So does this mean that if 10.x.x.x is natted to 172.16.x.x in the same n/w
it is due to ip address conflict?
Does natting happen only on customer end equipments or does it happen in
provider end euipment also?
John Lopez wrote:
> Usually, we NAT IPs from private IP to public IP. The one that
> traverse a firewall or an internet router device since the
> cannot route RFC1918 IP address space. If we do NAT between
> private to
> private networks then most likely, there's a conflict between
> the two
> segments. It can be a company that just merged or a newly
> company where for example they both have 192.168.0.0/24 network.
> Not all leased lines needs to be NATed. WAN connections in your
> domain can simply just use IGP for full IP routing table and
> routing. Well sometimes, if you have a WAN connection
> connecting to
> another company other than your own then you have to use NAT to
> your internal network addressing to the other company. Well it
> depends on the case.
> whitney Tracey wrote:
> > hi all,
> > Please throw some light on some of my queries
> > If Natting is to convert from private to public ip why some
> ips are natted
> > from private to private or they are not changed ?
> > Does all private ips used in private wan connections [leased
> lines] needs to
> > be natted? or only those private ips travelling on internet
> will be natted?
> > Thanks.
Message Posted at:
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html