ietf
[Top] [All Lists]

Re: The point is to change it: Was: IPv4 depletion makes CNN

2010-06-10 10:47:36
On Wed, Jun 9, 2010 at 8:57 PM,  <ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com> 
wrote:

Sorry, this was in reference to an approach based on passed
assumptions.  The inflection point for when multiple IPv4 addresses at
an access point becomes anachronistic will occur with an IPv6
connectivity imperative driven by the lack of IPv4 addresses.

But things have to get to that point first. I for one am not especially
sanguine about IPv4 address scarcity forcing sensible behavior soon enough.
Especially given the major holes in IPv6 device support we've been
discussing.

Try 'desirable'.

Sticking to IPv4 till the last minute and letting everyone else make
the necessary investment to support the transition is the 'sensible'
approach for most parties.

The Internet has a billion users and it is now impossible to change it
without putting a great deal of thought into the incentives for
co-operation.



I note in passing that this might have played out differently had we gotten
SRV
record support in place for all protocols a lot sooner. But without it for
HTTP
in particular you're faced with the need for multiple port 80s in a lot of
cases.

And the number of protocols is exploding due to Web Services. We now
have far more than 64K protocols in use. The only reason we have not
exhausted the ports is that in the modern Internet everything has to
be layered on port 80 or 443.

What I would like to see the IETF do is to produce a new architecture
document that tells application and Web Service designers how they
should be using the Internet. In my view DNS+SRV should become the
only way that Web services are located (I do not think the extra
capabilities of NAPTR are necessary or even useful for service
discovery).

At the moment we have the OpenID people who currently have five
service discovery mechanisms, none of which use the DNS properly. And
they are not the only group that is merrily creating entropy that is
going to have to be serviced.


We also have a similar issue with the use of XML, there the problem is
that there are four different ways to achieve a certain aim and we
spend a year arguing about which one to pick each time we start a
working group. What I like about RFC822 style headers is not that they
are the best way to move metadata but that they are used in the same
way in every protocol.


The inflection point for when multiple IPv4
addresses at an access point become anachronistic occurs with an IPv6
connectivity imperative.

Yes, but the trick is getting things to that point.

Perhaps the US will delay acceptance of this
imperative, long after the rest of the world has embraced IPv6.  After
all, US, Liberia, and Burma have yet to adopt metric measures. :^)

That may indeed be the case, but I must say Hardly a fair comparison for a
lot
of venues. It's always easier to deploy new infrastructure when there's
relatively little old infrastructure that has to coexist or be replaced.

Calling small business use of a small number of IPv4 addresses
"anachronistic"
doesn't change the fact that this is a widespread practice fully
supported by
an ample number of reasonable quality router products. And you're not
going to
get IPv6 deployed in such cases without a drop-in replacement that
adds IPv6
support to what's already there.

Clearly, with skill and non-commodity equipment, a configuration
supporting multiple IPv4 addresses at an access point can be implemented
in conjunction with IPv6.

Of couse it can. But that's precisely the point - neither the skill nor the
non-commodity equipment are available in most cases. And even when they are,
a
lot of people, like myself, run the costs versus benefits and IPv6 ends up
losing.

This could be practical when many within an
organization are affected, but would not involve commodity low-end
routers.  Such configurations will remain rare due to IPv4 resource
consumption, and greater support complexity.  Fortunately, it remains
easy to adopt the resource conservative IPv4 configurations supported by
commodity routers when obtaining IPv6 connectivity.  Why should the IETF
advocate an increased IPv4 use that lacks benefit once a network has
been configured?

More strawmen. We're not talking about increased IPv4 use, but rather decent
support for existing, long-deployed IPv4 use. If you seriously think you can
get people to dump their existing setups in favor of somethign that is  a
major
PITA to deal with and offers no immediate benefit, well, I have a couple of
bridges available at fire sale prices.

                               Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf




-- 
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>