too many routes
Sean M. Doran
smd at clock.org
Thu Sep 11 20:11:59 UTC 1997
"Jay R. Ashworth" <jra at scfn.thpl.lib.fl.us> writes:
> Perhaps I misunderstood Sanjay, Sean, but I believe his concern was
> that the addresses _not be the property of an upstream (ie: backbone)
> provider_ to provide flexibility of connection choice.
Welcome to the new Internet, which is being built.
Two of the fundamental concepts that are important:
-- IP addresses are not forever
-- IP addresses are not end-to-end
I think most people have bought into the concept of
renumbering, and hopefully are realizing that the
temporary nature of IP addresses could involve changes
during the lifetime of a series of transactions at higher
NAT and ALG demonstrate the second point right now, and
are only crude to the extent that there are crufty
protocols which were designed without any flexibility
whatsoever in the two new fundamental concepts above, and
a series of NAT and NAT-like gateways could conceivably
already lead to changes in the IP addresses observed to be
in use across segments of the path between two
Combining the two concepts is very important, and this is
essentially the next big step in the ongoing merge of
routing equipment with address translating equipment.
Ideally this will be done at a huge scale as well as at a
So, to tackle the small-scale problem you refer to, the
general idea is that you have multiple outward-facing
addresses, one per provider, from each provider's PA
As providers come and go talking of Michaelangelo, you
simply add or delete outward-facing addresses from the DNS
advertisements your NAT generates. Your inward-facing
port address of the NAT and all the behind-the-NAT
addresses should never need to change, provided you do a
decent job of assignment (or employ NATs internally :) ).
The tricky part is the first fundamental part of the new
Internet architecture, and that is changing addresses
while conversations are in progress. Unfortunately
IPv4/TCP both have poor facilities for supporting this
without cooperation from higher-level protocols, and the
current set of higher-level protocols are often wed to the
idea of an end-to-end unchanging IP address. Sigh.
However, NAT designers have some clever temporary hacks
while a cleaner set of solutions are being looked into.
These hacks generally involve tunnels, as I pointed out in
a message I wrote just recently.
> NAT will not solve this problem; it resides at too low a level of the
> theoretical architecture, being used primarily to avoid renumbering of
> internetworks. This isn't a network numbering problem, it's a routing
The address at the transport layer (i.e., the IP address)
is utterly and indivisibly wed to the local routing scheme
at any point in any topology.
Renumbering one endpoint of a connection on the fly when
you have multiple outgoing addresses tho choose from (in
the case of a multihomed endpoint with PA addresses from
each upstream connection) directly influences how the rest
of the world will route the other endpoint's traffic.
This is a feature of NAT, not a side-effect. It is also a
crucial feature in the new Internet.
IPv4ever (well until we get proper endpoint identifiers
and variable-length transport addresses so we don't have
to emulate a decently scalable transport protocol using NAT).
More information about the NANOG