Phil Howard wrote:
> possible. Running a provider-side proxy you could
> theoretically have 1 IP address per farm. An
> application layer solution is thus also doable.
But you still need to find an excuse to waste 8000 more addresses so
you can appear to justify getting a /19 address space to get around
route filters so your multi-homing gives a return on investment.
a) Those who put in length dependent route filters have already
shown willingness to change them in view of allocation policies
(viz /19 vs /18 filtering in 195/8 at Sprint)
b) This may be irrelevant anyway. If you are a smaller provider,
you could cascade your application gateways onto those
of your upstream, making the thing a hierarchy. There
are already squid heirarchies which prove this isn't
as lunatic as it might seem.
That's why everyone is abandoning traditionals ISPs and going with proxy
providers like AOL.
I'm not sure whether that comment was intended to be sarcastic
or not. If it was, look at how many providers are currently
looking at forced-caching/forced-proxying technology.
I'm not sure if you are limiting this suggestion to just dialup accounts,
or widening it to include dedicated accounts. The justfications and impact
vary depending on the type of account.
I propose (for the sake of being procative) doing it for every
sort of account. Including downstream ISPs.
How will you be sure that every provider has a telnet gateway? I suspect
that many will just leave it out. And they will leave out many other
protocols/applications, as well.
You aren't. How under the current environment can you ensure
that your route advert gets heard by a distant provider? You
can't. Both are solved in general by market forces.
IPv4 can be translated to IPv6s4 (my term for IPv6 in an address space that
corresponds to IPv4 addresses). Of course if we do this it means we have to
be able to continue to route all this address space even after IPv6 is fully
deployed (I'd not want to by then).
What problem is IPv6 solving? Is lack of IP address space a real
problem? Or is the real problem that communicating hosts need to share
a common address space which is represented at the network layer
(let alone at the network layer in an end to end manner)?
> Sean seems to predicts death of end to end
> network layer addressing. How about the
> death of end to end internet? Instead
> run with a core of IPv4 numbered routers
> and application layer gateways. Run everything
> else in private address space. 10.0.0.0/8
> has pleny of room.
You've just written a new application based on UDP. How will it get
through these application layer gateways? Will you have to write the
gateway module, too, for every one of many dozens of gateway platforms?
Possibly. One can imagine a generalized proxy which is
not much different from tunnelling. Do we actually want arbitrary new
UDP application to have host-host connectivity automatically
if the relevant hosts are internet connected? (remember
the "deliberately provocative" bit). Let's say that application
was "realtime audio broadcast". In my putative world, the
answer would be "no". I'd rather have it carried multicast
and translate to multiple unicast UDPs near the leaf nodes.
I allege most internet users do not want arbitrary protocol
packets turning up on abitrary hosts (viz SMB/NetBios
The end-to-end notion is what makes the network so powerful.
and so dangerous.
that you end up being limited to those few applications that someone
decided there is a business justification for in the gateways.
Not necessarily (viz tunneling) but there is some truth in
what you say. But then the same is true currently at the
protocol layer. What ever happened to the IPX internet?
Before the Internet got started in the research and academic world,
there simply would never have been a business case to build it, based
on the way business does its analysis. Yet, we know what the end
result turned out to be.
Compare and contrast with the telephone network where originally
most if not all signaling functions were available to end users
in the first exchanges. This gradually got hidden (2600 etc.)
and is currently largely inaccessible. If you want to build
a new phone signalling protocol, you have to be a PTT or an
exchange manufacturer, and get broad industry approval. This
does not prevent new phone applications from appearing.