On 6/10/10 3:12 PM, Ned Freed wrote:
On 6/10/10 2:48 PM Douglas Otis wrote:
> Disagree. HTTP is a bad example, since it allows canonical names
> to be replaced with a name offered by clients for supporting name
> based virtual hosts. In other words, a single port supports
> thousands of websites. :^)
True but irrelevant. The issue isn't support for multiple web sites,
it's support for multiple servers. Virtual hosts are fine as long as
everything you've got runs under the same web server and on the same
hardware. But in many cases things don't work this way. Let's see.
I'm running at least seven different pieces of software right now
that include a web server component. Now, not all of them provide
public services, and for those it doesn't matter that they're not on
port 80. But three of them do provide public services.
Of course redirects and proxies provide a means of getting around
these limitations. But now you're talking about a substantial
increase in application and configuration complexity. Multiple IPs
are a lot simpler and easier to manage.
A Pareto complaint scenario does not require every possible
configuration be accommodated, when it also accommodates existing
configurations. Only a small percentage of customers receive multiple
IPv4 addresses from their provider. Of those, only a few run
incompatible services on different systems. While those who participate
within the IETF likely represent an exceptional population, it seems
unlikely special accommodations for minor portions of a market is
necessary before progress is possible. Those who wish to retain their
current configurations can do so, forgoing IPv6 connectivity. For them,
this becomes a question of what overcomes their current equilibrium
(their PITA factor). Indirectly this is being answered when large
providers internally route Internet services using IPv6 when lacking
adequate IPv4 address space.
From a security standpoint, direct routing to a device reduces
complexity and operational issues. Whether a device is an LP tank
sensor in the backyard, a power meter on the side of the house, or a
heat pump in the basement, direct routing offers enhanced functionality
and security for those who opt-in. Currently, low-end routers are
commonly 0wned and are untrustworthy, and often lack adequate logs,
assuming these logs could be trusted. Direct routes allow packets to
arrive unaltered, where only its source is being trusted.
> The impetus to change occurs after IPv6 becomes an imperative, such
> as doing business with a region dependent upon IPv6. After that,
> complaints related to NATs will fade, and support for IPv4 will be
> seen as the PITA. The inflection point for this may move faster
> than imagined.
In other words, the way you see this unfolding is that once there's
a significant IPv6-connected base somewhere, probably in some
emerging market, somebody will view it as practical to deploy
services that can only be reached by IPv6. As more and more of this
happens, it will create a need for everyone to have IPv6
connectivity, which will then lead to more IPv6-only services, and so
on.
If this is accurate, I think you need to go back and reread John
Klensin's recent messages for why this scenario really isn't all that
likely to unfold the way you think.
Region might mean a market segment or a geographic area, whether the
impetus results from a lack of IPv4 address space, a lack of IP
security, or a lack of functionality.
Do you have a reference to one of John's messages? Over the years, this
economic reference has been raised. Adding complexity to commodity
devices for a minor portion of a market makes little sense. Higher-end
routers offer a solution, but this means considering available
alternatives when price does not seem justified. I don't see any
strategy being proposed to force those not wishing to participate. For
years I have had access to multiple static IP addresses, but never used
more than one, nor would the services you seem to describe meet most
residential AUPs.
-Doug
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
