The Year 2000 Bug

I really didn't want to write about this but people keep asking me so
here's the document....

The Best Thing Written on the Y2K Problem

My favorite Year 2000 Bug cartoon is Gary Kasparov agreeing to a rematch
with IBM's Deep Blue chess computer. His condition: the match has to
start on December 31, 1999.

My Own Year 2000 Bug

I built a site at Hearst Corporation for selling magazine subscriptions.
One little program processed a Web form where people would type their
credit card numbers and expiration dates. Hearst asked me to modify the
program to check and make sure that the expiration date was later than
the current date. I resisted, saying that checking of this kind was
likely to lead to rejecting valid orders. They persisted. My program
made sure that the expiration year was greater than or equal to the
current year. So 06/99 is good right now because 99 is greater than 98
(the current year). But 06/97 would be rejected because 97 is less than
98. I tested a couple more cases and pronounced the program working. A
woman at Hearst tested the program with 07/01, a card expiring in the
year 2001. Since 01 is less than 96, the year that we were installing
this check, my program rejected the card.

What do we conclude from this? You shouldn't hire MIT nerds to write
business data processing software!

Don't Worry, People Test Stuff

Major business applications, e.g., in banking, usually go through at
least six months of testing before deployment. Big companies have
departments in place right now with a separate test computer. They
generate some large test data sets. They set the clock to June 1, 1999,
then June 1, 2000, then June 1, 2001 and see what breaks. If there is a
problem with a mainframe-style application, chances are that it will be
noticed long before the year 2000.

Don't Worry, Stuff Doesn't Work Anyway

What kind of a society would we have if everyone's computer crashed on
January 1, 2000? The same kind that we have now. Computer software
does not work. Macintoshes and Windows 3.1 machines crash every few
hours. Windows 95 machines crash every day. Windows NT machines crash
every week. Unix and mainframe applications very seldom are truly
operated 24x7 (Web service is a strange exception that has everyone hot
and bothered about 24x7 uptime but the systems on which society truly
depends usually are taken down 6-8 hours/day).

Hardware engineers are brilliant. The great strides they've made have
almost obscured the stagnation in the software world. Microsoft has a
monopoly and Bill Gates has a lot of money. But that doesn't change the
fact that Microsoft programs don't work well enough for anything that
matters. The airlines run on software that was written in the 1960s
(before MIT kids realized that you could make more money going
to medical school or getting an MBA than by programming).

Society pays hundreds of thousands of people to keep our computing
systems together with chewing gum and baling wire. Year 2000 bugs will
be subsumed into the sea of bugs that these folks fight every day anyway.

Embedded Controllers

Most Unix programs compute time in terms of seconds since 1970. It
turns out that these programs will all fail in the year 2038 because the
quantity will be too long to represent in a 32-bit integer. I guess the
vendors think that by then you'll have upgraded to a 64-bit machine,
capable of easily storing numbers that are 4 billion times larger. But
of course 32-bit processors are being put into cars right now. Many of
them use similar systems for measuring time. An antique buff in the
year 2039 who wants to drive his mint 1998 Hyundai Excel might be in for
a rude shock.

How likely is this to happen? It has already happened. Tektronix makes
extremely high quality products, mostly test equipment for engineers.
Allegedly a Tek digital storage scope built in the mid-1970s failed in
the mid-1980s because it couldn't store the date anymore in the allotted
24 bits.

I'm personally more worried about these kinds of embedded computers
failing than mainframe computers. There are computers in your car, in
your microwave oven, in the gas pipeline, in the electric power grid.
Some of these may fail or behave irrationally on January 1, 2000. Some
may fail at unpredictable times related to how many seconds will fit in
the computer's word size and when they started counting. All of these
computers are harder to find and test than the mainframes in
Corporate America's glass-walled computer rooms.

Inspiration

If your experience of computers is using Microsoft products then you
might get depressed. A Microsoft program will do the things that users
wanted two years ago. When their marketing department figures out there
is a new need, the Internet, for example, Microsoft has to throw
engineers at the problem and rewrite everything.

Why don't I just leave the software field?

There is a guy upstairs from me at MIT: Dave Clark. He basically wrote
the spec for TCP/IP, the standard by which computers talk to each other
over the Internet. The Internet started out with two computers on his
desk and scaled to the current 20 million machines. Dave Clark did not
have to go out and rewrite TCP/IP every time another million machines
were hooked up or when people started to broadcast radio sound or video
clips over the Internet.

Reader's Comments

On TCP/IP: your tale about Dave Clark is
roughly accurate, but there are a few
inaccuracies.

Dave Clark did not by any means design TCP/IP
by himself.

When the Internet was two computers, back in 1969,
it did not use TCP/IP. The NCP protocol became
stable sometime in the 1970s (I don't know when --
I wasn't there, and I haven't read the RFCs that
far back) and had some minor problems, like 8-bit
host addresses. TCP/IP in its current form was
stabilized about 1980, when there were a hundred
or two machines on the Internet. It broke down
completely about 1986. Van Jacobson and some
smart guys at Berkeley figured out how to fix
this, by having TCP work a little differently and
slow down when the network got too congested.
This way, you would get worse service, but
everybody else would get better service. Since
the Berkeley guys were maintaining BSD, which was
by that time the dominant OS on the Internet, they
could mandate that every computer on the Internet
use their congestion-avoidance algorithms.

Now we're running out of host addresses again, and
you can't send radio sound or video clips over TCP
very well -- a single lost packet in the middle
means that the whole sound or video stops for
several seconds waiting for a resend -- so people
are going back to UDP and not building in
congestion-avoidance stuff. The heart of the
Internet, the backbones, can't figure out how to
route reliably, and the best solutions they've
come up with so far result in every router on the
backbone having to know which direction tens of
thousands of networks are in. The Internet still
isn't handling a fraction of the data the phone
system is, which is partly because every packet is
routed independently, and it's not handling it
anywhere near as reliably.

The current TCP/IP protocols don't work well for
distributing the same information to many people
at once. That's why Phil Greenspun has a 1300-kg
HP K460 with four gigabytes of RAM, four
processors, and a 250-kg 6000-watt power supply in
his closet, and he doesn't have a hundredth of the
number of readers that CNN does. TCP is
fundamentally unicast, and IP in its original form
didn't have any provision for multicasting --
where you send out one packet that goes to several
other people. In fact, most routers *still* don't
support multicasting.

It's a royal pain in the neck to run a TCP/IP LAN.
This is because TCP/IP was not designed for LANs
-- it was designed for the Internet, which was a
bunch of big multi-user mainframes and
minicomputers connected by long-haul leased lines.
As a result, adding a Mac to an Appletalk LAN
consists of plugging it in, but adding a computer
to a TCP/IP LAN consists of plugging it in,
assigning it a unique IP address, telling it its
IP address and telling it the IP addresses of DNS
servers to use, and if I want to use it on the
Internet, it also needs to know the local
network's netmask (so it can tell which addresses
are on the local network and which ones aren't)
and the name of the default router. These are not
problematic if you're setting up a new machine
every year or two, but it's a pain when you're
reinstalling Windows several times a day.

TCP/IP is not designed for security. Anyone in
between you and someone you're talking to can see
everything you send and receive, and if you're
using TCP, they can insert arbitrary bytes into
the bytestream; anyone on the Internet can crash
your computer if its implementation of IP hasn't
been updated in more than about a year, and
probably even if it has; anyone who can get hold
of some minimal information about any particular
TCP connection you're talking on can close it at
any time; anyone on the Internet can "smurf" you
and flood your connection to the Internet with
garbage, by making it appear that you're
requesting lots of ping replies; if you're
following the TCP sequence number generation as it
was originally specified, then someone else can
fake a TCP connection from you to somewhere else,
from anywhere on the Internet. If someone can get
physical access to your Ethernet, they can make
everybody else on the LAN think that they are
everybody else, so all data traffic goes to their
machine, which can, of course, do whatever it
wants with it.

The Internet Protocol version 6, or IPv6,
previously known as IPng, solves most of these
problems. It has 128-bit host addresses, so we'll
never run out again; it has a better priority
scheme to distinguish real-time traffic like sound
and video from reliable traffic like telnet and
the Web, and to allow routers in the middle to
keep too much sound and video from stopping the
telnet and Web traffic; it mandates support for
multicast; it includes built-in mandatory support
for encryption; and it provides a way you can plug
a machine into your network and have it just work
without having to configure it, just like
Appletalk, only worldwide. IPv6 is currently
supported in several operating systems, and
there's a network called the 6bone where IPv6 is
in use right now by several hundred people.
There's no telling how long it'll take to switch
completely. They haven't solved the routing
problem or the reliability problem, as far as I
can tell;
http://snad.ncsl.nist.gov/~ipng/NIST-6bone-status.
html seems to say that between half and
three-fourths of the 6bone is unreachable from
NIST as I write this.

So, in summary:
- TCP/IP has gone through at least two major
redesigns;
- TCP/IP has a lot of scaling problems and a lot
of problems being applied to new problems, like
multicast, voice, operation in a hostile network,
and local area networking;
- Dave Clark didn't do TCP/IP by himself.

Now, don't think I hate TCP/IP. I love it. It's
the best networking protocol in the world. It's
more flexible than any other networking system.
It's reasonably fast (although the
packet-by-packet routing means that it will be
limited by router silicon speeds, instead of wire
speeds, for a long time to come) and it's
reasonably secure, assuming nobody can snoop on
your packets. It's not hard to configure,
although it's a long way from AppleTalk, and it's
robust enough that it keeps on going even when
there are 90% packet loss rates on the backbones.

Does anyone really design anything by themselves? This is quibbling IMO.

> Now we're running out of host addresses again

Actually, CIDR really pushed this issue off a fair distance into the future. All it took was a little self discipline. Of course, if things got really tight some institutions (ie: MIT) that have sizable allocations (ie: an entire Class A) could always renumber and share the wealth, but that's a pain and probably unnecessary.

> the best solutions they've come up with so far result in every router on the backbone having to know which direction tens of thousands of networks are in

This is mainly because doing the kind of baling-wire fix you describe turned out to be rediculously easy with the advent of better block allocation and almost-free memory. If what you have works, you don't fix it.

> The current TCP/IP protocols don't work well for distributing the same information to many people at once. That's why Phil Greenspun ...doesn't have a hundredth of the number of readers that CNN does.

In my opinion (and from reading the articles, I believe its philg's as well) this isn't a big deal. We've become accustomed to multicast services (ie: TV, radio) because for a very long time they were the only game in town. While I agree that they have their place, there's no reason to dismiss TCP/IP just because it doesn't service an area that already has substantial support. In information gathering and distribution, I think that the peer-to-peer model is much nicer anyway.

> It's a royal pain in the neck to run a TCP/IP LAN...

The comments in this section have nothing whatsoever to do with TCP/IP. The example given regarded setting up multiple intances of Windows machines; ironically Windows' support of DHCP is about as good as you could ask for and solves every issue discussed in this section.

> TCP/IP is not designed for security

No it isn't. Who cares? Why insist that security is put in place at the transport level? This issue has been addressed in most critical areas (https, ssh, etc). Anyway, the Internet is a global cooperative network. If we relied on TCP/IP to provide security, the US parts of it would have a hard time communicating with the rest of the planet.

> IPv6 has 128-bit host addresses, so we'll never run out again

Can I quote you on this in a few decades? The real answer would be to make a protocol that could accept expansion. However many addresses we specifiy (and yes, I'm aware that 340282366920938463463374607431768211456 is a long number) we will eventually find a way to use them
up.

It is possible that the IPv6 technology mentioned above may not provide an adequete number of IP addresses. However, this technology will provide enough IP addresses for a world covered by computers (today's size) stacked 500 high.
Probably enough to give every leaf an IP address.

I was born in 1969. In 2038, when the time counters wrap around on 32-bit Unix systems, I will be ... near retirement age.

Surely, forty years from now, 32-bit computers will be obsolete, and every computer that could seriously affect my life is going to have, at the very least, a 64-bit processor and an OS that uses 64-bit dates. So I have nothing to worry about. Right?

Maybe I should spend the next few decades stockpiling canned foods and working on my target shooting....

The RFC for TCP (RFC 793) was written by Jon Postel. So was the one for IP (RFC 791). In fact a serch for Postel in the authors field of RFCs at www.rfc-editor.org comes up with 231 results. The earliest RFC authored by Postel is RFC 0045.

A similar search for Clark comes up with 19 results. Of these 4 are for Clarks other than D. The earliest RFC attributed to D. Clark is RFC 0813 which deals with implementation as opposed to design issues.

CONCLUSION: Dave Clark is not the creator of TCP/IP.

The foregoing does not mean that Postel is the creator of TCP/IP either. The good work was started long before he (and quite a bit earlier than Dave Clark) arrived on the scene. There were quite a few illustrious predecessors. The name of Vint Cerf comes most easily to mind. However Jon Postel's contributions to the Internet are immense; much more so than most.
Attachment: a

> Can I quote you on this in a few decades? The real answer would be
to make a protocol that could accept expansion. However many
addresses we specifiy (and yes, I'm aware that
340282366920938463463374607431768211456 is a long number) we will
eventually find a way to use them up.

> It is possible that the IPv6 technology mentioned above may not
provide an adequete number of IP addresses. However, this
technology will provide enough IP addresses for a world covered by
computers (today's size) stacked 500 high. Probably enough to give
every leaf an IP address.

First, if exploration of other planets (much less other solar systems) ever gets underway, the available address space would start getting split up immediately.

Second, suppose Internet connections become simple enough (remember that many things that were considered difficult or impossible 25 or 50 years ago are considered simple today) to put a small client/server into every piece of equipment connected to a phone line or electrical line (signals can be sent over electrical lines), so that it can regularly report its' status upstream. As a trivial example, suppose a light socket in hotel room 72 on the 17th floor could report a burned-out bulb; someone on the maintenance staff could come up to replace the bulb in minutes.

Can I quote you on this in a few decades? The real answer would be
to make a protocol that could accept expansion. However many
addresses we specifiy (and yes, I'm aware that
340282366920938463463374607431768211456 is a long number) we will
eventually find a way to use them up.

However, this technology will provide enough IP addresses for a
world covered by computers (today's size) stacked 500 high.
Probably enough to give every leaf an IP address.

The first comment above is right on the money. The second comment
above (by another correspondent) is an often-made argument that
completely misses the point that rarely, if ever, do you want to
assign addresses sequentially, and especially so in heterogeneous
systems. Look at phone numbers, as a common example.