RE: too many routes

Please people, we must stop abstructions to keep the market open and
competitive.

Can you spell "economies of scale"? Or "using fiber at cost means
owning the fiber"? If you want to play the backbone game you've
got to own long-haul transmission facilities.

A small backbone provider simply cannot be competitive; no more than
neighbour garage can compete with Chrysler.

There are backbone providers and there are providers of specialized
ISP or hosting or security etc. services that need independent* IP
address space and do not have to waste resources on building a private
"backbone".

I had thought predicting consolidation in the Internet services
market was an exclusive realm of only the clueless "market research"
firms. Even they seem to be wisening up.

Sanjay Dani <sanjay@professionals.com> writes:

There are backbone providers and there are providers of specialized
ISP or hosting or security etc. services that need independent* IP
address space and do not have to waste resources on building a private
"backbone".

NAT.

  Sean. (read an old message by Paul Vixie prior to
    some NANOG that wasn't worth going to
    really where I think he might have said
    pretty much the same things he wrote)

P.S.:

I had thought predicting consolidation in the Internet services
market was an exclusive realm of only the clueless "market research"
firms. Even they seem to be wisening up.

"Internet services" is a rather broad term. I think the
"consolidation is coming" crowd is looking more at
transport. People watching UUWHO recently might see some
justification for the "consolidation is coming"
predictions.

On the other hand there are models which are attractive
beyond the "we run a backbone and dialup and web hosting
and this and that and this and that and what else is on
your checklist, oh yah, we do that too or are buying up a
company that does it already" as such a model
tends to scale poorly vs. the number of working brain cells
in any given organization needed to offer reliable and
coherent service over time.

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.

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
problem.

Cheers,
-- jra

Please, let's think this through carefully before making such
pronouncements. If the problem to be solved is providing flexibility of
choice, then Sean is quite right and NAT (plus other renumbering
technologies) is the solution for most people. If you use NAT and
renumbering technologies then you don't give a darn what your IP address is
or who gave it to you as long as it is globally routable. You still have
flexibility of choice in that you can switch upstream providers on a whim
and use Paul Vixie's BSD tricks to multihome if that matters.

NAT may not be the solution to every problem but it certainly does provide
flexibility of choice which is one of the reasons many companies use it
today.

You can't give everyone globally routable and portable address space on the
Internet. To do so would be tantamount to making everyone equal and
flattening the hierarchy of the network. But this creates an unmanageble
mess in which the network becomes a sort of amorphous blob with no
discernable internal structure like some sort of slime mode. What we are
trying to do is evolve the network into an organism that is strong and
resilient. This requires that the network have discernable internal
structure and that requires hierarchy and layering and a thick skin to
protect the organism from the outside world. Hierarchy means that some
addresses are better than others, i.e. portable, but it also allows us to
carve the network up into manageable pieces and then to manage it in a
reasonably stable and reliable way.

Routing problems involve how to design, manage and operate this internal
traffic distribution hierarchy and are essentially engineering problems,
not policy problems or social problems. I think that the desire for
portable address space is not a routing problem.

"Jay R. Ashworth" <jra@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
protocol levels.

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
communicating endpoints.

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
small scale.

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
address space.

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 :slight_smile: ).

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
problem.

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).

  Sean.

> Sanjay Dani <sanjay@professionals.com> writes:
> > There are backbone providers and there are providers of specialized
> > ISP or hosting or security etc. services that need independent* IP
> > address space and do not have to waste resources on building a private
> > "backbone".
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.

Thats the position I find myself in, hosting/specialized ISP, who needs a
large enough independent block to be fully routable and multi-homed....
but don't have a /19 or mores worth of hosts yet... Seems the standard
answer for what to do in this situation is "tell the internic (now arin?)
what you have to then, even if its partially lies, to get the block
and AS number".....

This isn't a network numbering problem, it's a routing problem.

Precisely, its only a numbering problem in the sense of how that affects
routing/routablility....at least in my case...

-David Mercer
infiNETways, Inc.
Tucson, AZ

Ok so this turns NANOG into Big-Internet... mutter... but
it's more interesting than television, and people here
really ought to be thinking about things like this anyway.

Oh yeah, I just realized I can add an
ob. ops. postscript. So there. Nyah.

Michael Dillon <michael@priori.net> writes:

If you use NAT and renumbering technologies then you
don't give a darn what your IP address is or who gave it
to you as long as it is globally routable.

No, all you care about is that two endpoints can talk to
each other.

You emphatically must NOT care what your IP address is, as
you say, but this also means that you must not care about
the scope of the address itself, nor about the scope of
its routability.

In any piece of the evolving Internet, a datagram may
undergo transformation from one address to another. In
some cases it may undergo transformation into a prefix
which is expressly not globally routable (e.g., an RFC
1918 address), yet which is routable within the scope of
the address's visibilty.

That is, between any pair or cluster of NATs (for
instance, at the edges of a network) you require
routability of all addresses valid within the scope
delineated by those NATs. Outside that scope, the
addresses (and indeed the protocol(s) under the end-to-end
protocol) may be undefined.

Routing problems involve how to design, manage and operate this internal
traffic distribution hierarchy and are essentially engineering problems,
not policy problems or social problems. I think that the desire for
portable address space is not a routing problem.

PI space is already being remapped by NATs around the
world; the next steps in the evolution of the Internet
seek to push that remapping closer to the edge of the PI
space, so that the PI addresses ultimately are visible
only within the administrative scope of the user of the PI
addresses.

This done, the whole PI vs PA address argument will simply
cease to be relevant, and the principal flaw of the
post-CIDR IPv4 addressing scheme will be no more.

Note that scoping address meaning within a subset of the
global topology also increases the address lifetime of
IPv4 itself substantially, even ignoring such things as
overloading single addresses and the like.

The one piece that is unfortunately missing is more an API
issue than anything else, and that is that getservbyname(3)
should take an FQDN as a third argument and should find
its answer in the DNS rather than in /etc/services (hi Paul).

  Sean.

P.S.: The neat thing about this is that suddenly no
  operator really would need to worry much about ARIN and
  addressing politics, since addresses would only be
  valid within paritcular scopes, which could be the
  individual provider or a collection of providers,
  with or without downstream customers.

  (I hope there is no operator who thinks that
  killing off silly addressing politics and the
  endless arguments about filtering and so forth would be a
  Bad Thing.)

Ok; I've taken this private, because I'm only close to getting what
you're saying, and my feet are too big.

[ reads, thinks, chnages mind ]

Oh.

Shit.

<thunk>

Number the internal stuff privately and use NAT to renumber the
external appearances when necessary. Fix the DNS when you do.

Forgive me, all; I'm climbing back under my rock now.

Cheers,
-- jr '/24' a