Thomas Narten wrote:
Keith Moore <moore(_at_)network-heretics(_dot_)com> writes:
Just think how much easier the IPv4 to IPv6 transition would have
been if nothing above the IP layer cared exactly what an IP
address looks like or how big it is.
It wouldn't have made much difference at all,
Wow. I find this statement simply astonishing.
IMO, one of the biggest challenges surrounding IPv6
adoption/deployment is that all applications are potentially impacted,
and each and everyone one of them needs to be explicitely enabled to
work with IPv6. That is a huge challenge, starting with the
observation that there are a bazillion deployed applications that will
NEVER be upgraded.
There were also a bazillion deployed applications that would never be
upgraded to deal with Y2K. Somehow people managed. But part of how
they managed was by replacing some applications rather than upgrading them.
I certainly won't argue that it's not a significant challenge to edit
each application, recompile it, retest it, update its documentation,
educate tech support, and release a new version. But you'd have all of
those issues with moving to IPv6 even if we had already had a socket API
in place where the address was a variable-length, mostly opaque, object.
Consider also that the real barrier to adapting many applications to
IPv6 (and having them work well) isn't the size of the IPv6 address, or
adapting the program to use sockaddr_in6 and getaddrinfo() rather than
sockaddr_in and gethostbyname(). It's figuring out what it takes to get
the application to work sanely in a world consisting of a mixture of
IPv4 and IPv6, IPv4 private addresses and global addresses and maybe
linklocal addresses (useful on ad hoc networks), IPv6 ULAs and global
addresses and maybe linklocal addresses, the fact that 6to4 traffic is
sometimes blocked (so v6 connections time out), and that 6to4 relay
routers often cause IPv6 connections to work more poorly than native
IPv4 connections, NATs, and so forth.
(size *is* an issue for applications that do referrals, and those are
important cases, but the vast majority of apps don't do that.)
And at least from where I sit, almost all of the applications I use
already support IPv6. (I realize that's not true for everybody, but it
also tells me that it's feasible.) From where I sit, the support
that's missing is in the ISPs, and the SOHO routers, and in various
things that block 6to4. I understand from talking to others that
support is also lagging in firewalls and traffic monitors needed by
enterprise networks.
Boy, wouldn't it be nice of all we had to do was IPv6-enable the
underlying network and stack (along with key OS support routines and
middleware) and have existing apps work over IPv6, oblivious to IPv4
vs. IPv6 underneath.
Sure it would have been nice. But for that to have happened would have
required a lot more than having the API treat addresses as opaque
objects of arbitrary size. It would have required that IPv4 support
variable length addresses in all hosts and routers so that there would
have been no need for applications to try to deal with a mixture of IPv4
and IPv6 hosts that can't talk directly to one another. It would have
required an absence of NATs so that apps wouldn't need to know how to
route around them. It would have required that apps be able to be
unaware of the IPv6 address architecture, and for them to not need to do
intelligent address selection, which basically would have required
solving the routing scalability problem.
Basically if we had had all of that stuff in place in the early 1990s,
we would never have needed to do a forklift upgrade of IPv4 - the net
would have evolved approximately as gracefully as it did with CIDR.
And, if one wants to look back and see "could we have done it
differently", go back to the BSD folk that came up with the socket
API. It was designed to support multiple network stacks precisely
because at that point in time, there were many, and TCP/IP was
certainly not pre-ordained. But that API makes addresses visible to
APIs. And it is widely used today.
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).
No, because one of two things would have happened:
1. the defacto APIs would have long since been abandoned in favor of
sockets APIs that were more flexible at letting apps deal with various
kinds of network brain damage, or
2. if the defacto APIs were the only ones available on most platforms,
then we wouldn't have any of the applications that we have today, that
manage to get around NAT. we'd be stuck with email and
everything-else-over-HTTP, with all servers constrained to be in the
core, and prime IP real estate being even more expensive than it is now.
--
Having said that, I'll grant that every barrier to IPv6 adoption is
significant. The reason is that moving to IPv6 isn't just a matter of
flipping switches at any level. It's one thing for an app to be able to
deal with IPv6 on a small scale when talking to a single peer from a
controlled environment, quite another for the app to be able to deal
with IPv6 on a large scale when running in a customer's environment and
talking with many peers that are in a variety of network environments.
So it's not just a matter of editing and recompiling the app, or
enabling IPv6 in a few routers, or arranging for your ISP to assign you
an IPv6 prefix and start routing it to you. It's a matter of having
several iterations of each of those where you (whatever your role is)
discover significant bugs on each of the first several iterations.
Keith
p.s. If we're going to engage in "what if" discussions (e.g. "what if we
had had a better defacto API in IPv4") we could of course ask "what if"
IPng had been designed as an extension to IPv4 (e.g. IPAE) and we had
worked harder to make that approach work well. And I suspect that with
enough cleverness we could have done so, and in the process eliminated a
few barriers to adoption - or at least, decoupled a few more things from
one another so that upgrades would not have to be in sync to be of
benefit. But we had good reasons for (most of) the decisions that were
made in IPv6, just as there were good reasons for the BSD sockets API.
I'm not sure what purpose there is in second-guessing them now.
Nor do I really see the purpose in trying to clean up the API now, at a
time when applications often do need to be aware of address formats and
such. Maybe once everything uses IPv6 and all of the problems are
solved and we figure out how to make DNS robust it will be possible for
most apps to use a simpler API. But by then, we won't have any need to
change the apps that are using the old one.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf