Noel Chiappa wrote:
IPv6 simply isn't going to get deployed "as a replacement for IPv4". It's
not enough better to make it worth switching - and you can flame all day
how NAT's are preventing deployment of new applications, but I can't run
SMTP or HTTP server in my house because my provider blocks incoming SMTP
connections unless I pay for business service, and I personally find that
lot more problematic than the limitations of NAT.
This sounds more like a point to raise with a regulatory agency than a
technical discussion. Your ISP would make you a prime candidate for a
tunnel-broker that will get you past the blockage:
IPv6's only hope of some modest level of deployment is, as the latter part
your message points out, as the substrate for some hot application(s).
I doubt anything the IETF does or does not do is going to have any affect
whether or not that happens.
You may be right, but that only argues that the IETF is irrelevant to the
development of applications. If that is true, why do we have an applications
area full of working groups? My question was really why they are not
recognizing that at this point IPv4 is a dead end, and stopping any work
that assumes an IPv4 substrate? Yes apps are supposed to be agnostic, but we
all know that apps insist on hooks down the stack, because the app developer
believes he can do a better job of managing the network than the OS.
Of course, that still doesn't get you to the "general replacement for
stage. I don't think that goal is reachable - IPv6 just isn't enough
(i.e. more functionality) than IPv4. It's ironic that one of IPv6's big
concept points ("the IPv4 architecture is fine, we just need to fix a few
details") turns out to be IPv6's Achilles' heel. (Although some of us
predicted that at the time IPv6 was adopted....)
As you may recall, I really don't care about the bit pattern in the header,
as long as it has enough bits. I have been the pragmatist focused on getting
whatever is implemented actually deployed (we could have had TUBA deployed
long ago, as some of us had the routing infrastructure up before the IPv6
decision). IETF internal conflict has had more to do with any delays than
the market could have.
Now if basic IPv6 (and basic IPv6 applications) were reworked so that it's
IMPOSSIBLE to tell, from looking at the packet, what kind of service it's
going to - e.g. by using random TCP ports for applications servers, and
the ICP include a service name (the field for which is encrypted so
middle-boxes can't read it) to do the rendezvous - that would be the kind
thing that might interest a few more people.
As I recall, several people including Peter Ford were arguing that the
transport layer should be reworked at the same time, because making the
stack and application changes would be a big enough job that people would
only want to do it once. There was a vast outcry in the IETF to make the
minimum number of changes and keep the architecture exactly the same. Now we
find continuing efforts to rework the architecture because various groups
didn't get the 'minor' tweak they wanted.
And while we're at it, you probably want to make it impossible for the ISP
even tell if it's a TCP SYN, otherwise they'll probably just filter them
See tunneling comment above.
> Continuing work on IPv4 only creates the illusion that it is a
> protocol for application developers to rely on for future income.
Continuing work on IPv6 only creates the illusion that it is a viable
for the network as a whole to rely on for the provision of ubiquitous
In anything even vaguely like its current form, that goal is completely
unreachable for IPv6, and the continued chanting of "IPv6 is the future"
prevents work on *feasible* upgrades that will allow the continued
of ubiquitous datagram substrate service.
Clearly work on IPv6 is not preventing work on changing the fundamental
Internet architecture (see multi6). Turning your earlier argument around,
there is nothing the IETF does or does not do that precludes the IETF from
doing something else. What the IETF can influence is public perception (read
that average developer on the street) by where it places a clear focus. From
the outside, the IETF is continuing to work on IPv4, therefore the IETF
doesn't believe it is a dead end. The average developer is not going to take
the time to learn something different unless it is clear the market is going
away from what he already knows. We can debate all day about how much
influence the IETF has on the market, but given the current abundance of
vendor participants, there is a clear path from standards focus to products
available to the marketplace.
Like it or not, we are at the end of the IPV4 road, and IPv6 is the only
viable alternative. Anything that comes out of rearchitecting the Internet
will be at least another 10 year process. I realize you would like things to
occur much faster than that, but even IPv4 took over 10 years to make it out
of the lab and into mainstream use (this is easy to overlook if you were so
close to the action that you missed the forest for all those pesky trees).
The market will adopt any technology that seems to solve the perceived
problem cheaper than the alternatives. In a world of apps where consumer
clients connect to publicly operated servers, IPv4 w/NAT is the cheapest
approach. In a world with arbitrary app interactions, the cost of managing
code development and NAT configurations/updates will easily exceed the cost
of changing protocols. At the same time, anyone trying to make a sweeping
one-shot change is just asking for pain. There are tools to make the change
reasonably straight forward for the average network manager. Can the same be
said for a completely new architecture?