Why the Internet only just works
BT Technology Journal • Vol 24 No 3 • July 2006
This may change, as Internet-connected mobile
devices become the norm, but this in turn may simply
serve to create walled gardens for mobile operators
unless the rest of the Internet also deploys IPv6. The
jury is still out on whether IPv6 will replace IPv4 in the
long run. What is certain is that a shortage of IPv4
addresses is unlikely to force the issue for many years
I hope that IPv6 will succeed, but I am concerned
that it may not. If there is not significant application
support by the time addresses do start to become short,
then it will likely be too late — NATs will become
required, and we are likely to see connections that
traverse multiple NATs. This would become a deploy-
ment nightmare for new applications.
The Internet was never designed to be optimal for any
particular problem — its great strength is that it is a
general-purpose network that can support a wide range
of applications and a wide range of link technologies.
The Internet is also a cost-effective network — it does
not make great promises about the quality of service
that it provides. It is good enough for a wide range of
applications, but anyone considering telesurgery or
remote-control of a nuclear power station might well be
advised to look somewhere else. It basically provides
80% of the capability for 20% of the cost. If we wanted
100% of the functionality, so that telesurgery routinely
could be performed over the Internet with very low risk,
then it is highly likely that the network would be too
expensive for the vast majority of users who wish to
exchange e-mail, chat, or surf the Web.
However, the requirements are changing.
Convergence progresses apace, in spite of the
problems, and these changed requirements bring with
them risks. The Internet is going to suffer growing pains
as it progresses from providing 80% of the functionality
to providing 90+% of the functionality, as called for by
the new requirements. The track record is not at all
good — the history of major changes that have been
successful is one of changes implemented at the last
minute. This should not be a surprise — there are
always too many immediate issues to be concerned with
to invest time and money on those that are not currently
critical. And consensus for architectural change is very
hard to reach unless faced with a specific and pressing
To conclude, in many ways the Internet only just
works. The number of ways in which it only just works
seems to be increasing with time, as non-critical
problems build. The main question is whether it will take
failures to cause these problems to be addressed, or
whether they can start to be addressed before they need
to be fixed in an ill co-ordinated last-minute rush.
1 Crocker S: ‘Protocol notes’, RFC 36, Network Working Group,
(Updated by RFC44, RFC 39) (March 1970).
2 Clark D D: ‘The design philosophy of the DARPA internet
protocols’, in Proc ACM SIGCOMM, pp 106—114, Stanford, CA,
3 Kudlick M: ‘Host names on-line’, RFC 608, IETF (January 1974).
4 McQuillan J, Richer I and Rosen E: ‘The New Routing Algorithm for
the ARPAnet’, IEEE Transactions on Communications (May 1980).
5 Rosen E: ‘Exterior Gateway Protocol (EGP)’, RFC 827 (October
6 Jacobson V: ‘Congestion avoidance and control’, in Proc ACM
SIGCOMM, pp 314—329, Stanford, CA (1988).
7 Lougheed K and Rekhter Y: ‘Border Gateway Protocol BGP’, RFC
1105 (June 1989).
8 Rosen E, Viswanathan A and Callon R: ‘Multiprotocol Label
Switching Architecture’, RFC3031, IETF (January 2001).
9 Ramakrishnan K K, Floyd S and Black D: ‘The addition of Explicit
Congestion Notification (ECN) to IP’, RFC 3168, IETF (September
10 Braden R, Clark D and Shenker S: ‘Integrated Services in the
Internet architecture: an overview’, RFC 1633, IETF (June 1994).
11 Carlson M, Weiss W, Blake S, Wang Z, Black D and Davies E: ‘An
architecture for differentiated services’, RFC 2475, IETF
12 Rosen E and Rekhter Y: ‘BGP/MPLS VPNs’, RFC 2547, IETF (March
13 Rosenberg J, Weinberger J, Huitema C and Mahy R: ‘STUN —
simple traversal of user datagram protocol (UDP) through network
address translators (NATs)’, RFC 3489, IETF (March 2003).
14 Rosenberg J, Mahy R and Huitema C: ‘Obtaining relay addresses
from Simple Traversal of UDP Through NAT (STUN)’, Internet-
Draft (February 2006).
15 Kohler E, Handley M and Floyd S: ‘Datagram Congestion Control
Protocol (DCCP)’, RFC 4340, IETF (March 2006).
16 Kohler E, Handley M and Floyd S: ‘Designing DCCP: Congestion
Control without Reliability’, to appear in Proc ACM SIGCOMM
17 Stewart R, Xie Q, Morneault K, Sharp C, Schwarzbauer H, Taylor T,
Rytina I, Kalla M, Zhang L and Paxson V: ‘Stream Control
Transmission Protocol’, RFC 2960, IETF (October 2000).
18 Smirnov A and Chiueh T: ‘Dira: Automatic detection, identification
and repair of control-hijacking attacks’, in NDSS (2005).
19 Kiriansky V, Bruening D and Amarasinghe S P: ‘Secure execution
via program shepherding’, in USENIX Security Symposium (2002).
20 Dunlap G W, King S T, Cinar S, Basrai M A and Chen P M: ‘Revirt:
Enabling intrusion analysis through virtual-machine logging and
replay’, SIGOPS Oper Syst Rev, 36
21 Newsome J and Song D X: ‘Dynamic taint analysis for automatic
detection, analysis, and signature generation of exploits on
commodity software’, in NDSS (2005).
22 Raiciu C, Handley M and Rosenblum D: ‘Exploit Hijacking: Side
Effects of Smart Defenses’, Proc ACM SIGCOMM Workshop on
Large Scale Attack Defence (September 2006).
23 Ferguson P and Senie D: ‘Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing’, RFC 2267 (January 1998).
24 Skype — http://www.skype.com/