Please send comments and feedback to Bob Frankston.

A Veneer of Internet

I recently tried to set up a second 802.11b access point in my house since I wasn't getting enough coverage from my first. Since I was knowledgeable I had set a simple key in order to provide a modicum of privacy if not security. But this new 802.11b access point was more sophisticated and offered a large collection of choices for how to setup security.

If I was confused, I could imagine the difficulty a home user faces. It's just easier to ignore the issue and just let the system run in the clear. This does work well enough and has the side-benefit of allowing others to borrow the connection which, so far, has been a social good. When traveling through a city there is a good chance you can use a nearby 802.11 connection.

This works well enough if we simply want to connect to a web server. But many of these access points also share a single connection among many users just like home "routers" for LANs. But once you go beyond the "web-potato" model of just browsing or sending email you find that you need special settings to work around "firewalls" and other barriers. You can't simply participate.

It would be wonderful if we could ignore all the complicated settings and protocols and just connect to the Internet. In fact, that's the way it was ten years ago when organizations that had a direct Internet connection and the net seemed safe.

But as corporations connected their local networks to the larger networks they were afraid of being too accessible and thus erected complex barriers between the company network and the rest of the Internet and allowed only selective access on the assumption that the Internet was like a library in a bad neighborhood.

While corporations often treated their isolation as a form of protection home users faced a similar problem in that their ability to participate was limited to having a single address. Network Address Translation is one technique way to work around this limit by second-guessing Internet protocols. But such approaches work only for a limited set of applications and make it difficult to develop new applications and services.

As long as you don't try to innovate and stick to what already works it seems that the Internet is working very well. But it is really a veneer that gives the illusion of innovation. Instead of simply creating new value all the effort goes into working past the difficulties of simply getting finding and connecting to other systems and we have lost control over what happens to the packets between the two end points.

Each new effort such as web services and P2P finds its own novel solutions which do not add to the synergy we found in the Internet Community. We find ourselves mining the past since those ideas are easy to explain and thus can be funded. New ideas and innovations have become too difficult. Tragically, we can't quantify the opportunities lost and the relatively small value we get from mining the past seems large but only because we don't know better.

Executive Summary

The Internet is not just about e-commerce and the Web is not the Internet. These are simply applications that were created by many individuals around the world who were able to experiment and make new services available to others. This was easy because the Internet was very simple. Each machine had its own IP address and you directly connected with any other machine on the Internet. Perhaps this is a little over-simplified but the essential point is correct.

That Internet has been lost and replaced by a maze of twisting and winding passage through domains with most users having only second class status and unable to create new services. It shouldn't be any surprise that innovation has hit a wall.

If we are to regain the economic momentum we must bring back the simplicity. A key part of this is assuring that every machine on the network can be a full participant. In the "real" world we can no longer be naive. In order to use the Internet for casual connectivity we must assure that these connections are safe. Hence the need for encryption. Encryption is also important. When the Internet was seen as unimportant there was little incentive to "help" out by meddling in packet delivery. We have seen over time that these "favors" tend to optimize the network for old applications and disadvantage new ones. Encryption also acts to protect the Internet from short-sighted optimizations.

This issue reminds me of my experience championing home networking at Microsoft. My big challenge was first to get people to care about networks within the home (because market surveys said that most people had just one machine). My second was to cut through all the reasons networks had to be complicated and say that they had to be simple. But I compromised and had to accept NATs in order to work within the limitations of IPV4. But that was years ago and it's been a long wait...

Key Points

The key points:

• First is why Encrypted V6 is important and urgent
  • While the four billion IPV4 addresses is a real problem, it greatly understates the problem. Most of the potential addresses are reserved because the bit patterns are used for increased efficiency of routing. And within a home, if we look at the current peripheral devices such as printers, let alone the expectation that all devices should be connected, we do not the ability to provide IPV4 addresses and, in fact, have never been able to provide sufficient addresses for most users. This means that we are past the point of crisis and are already unable to make every machine a full network participant and that’s already past the crises point and has already caused the net to stagnate. The Web potato model is very sadly misguided.
  • Encryption is rarely mentioned but the “real” Internet – the one that allowed everyone to participate made the simplifying assumption that the connections were safe. This is increasingly not true. But far more serious is the opportunity posted by wireless connectivity where we can’t have the illusion that the wire is protecting us. All the effort going into link level security is effort that could be adding value to the commons instead of applying temporary patches that have little long term value.
• What is holding up deployment
  • Lack of sufficient urgency as per the previous points.
  • Confusing the backbone agenda with the edge agenda.
    • For those seeing deployment from a policy perspective this makes deployment seem more difficult than it is. Edge deployment should be portrayed as a JDI (Just Do It) rather than a major shift to the Internet. There is no requirement to upset current procedures.
    • The people doing the implementations overlap and can get fixated on projects like the 6bone instead of just using the V4 network as is
    • I contend that the corporate agendas are focused more on the backbone because that’s where the big bucks seem to be.
    • The IETF? I’m trying to be fair but the memos are mostly about backbone issues rather than the edge. There is some edge effort but no one is taking the JDI (Just Do It) approach.

  • To repeat the first point, a lack of appreciation for the power of simplicity and the danger of even well-intentioned meddling.

• Technical and deployment issues. I argue these are solvable if there is a will.

  • Making it just work. Just having a “stack” is not enough. For example, how does one find other V6 machines without requiring all the DNS servers support V6? One can create third party dynamic DNS services and/or create a hybrid syntax that uses a V4 prefix coupled with a local name.

  • Encryption needs to "just work". Encryption must not be confused with authentication. We just need to find a way to share a secret and public key approaches should work but I confess a lack of deep expertise in cryptography but I know enough to be demand that it just works without putting the burden and blame on the users.

Since I’m focusing on the edges I am staying away from pointing out that QoS and MPLS are crypto-bell-head notions that are diverting effort from focusing on more capacity and lower latency.

Introduction

What is IP?

This memo assumes you know the answer. For those who don't the very simple explanation is that the Internet Protocol defines how packets are laid out. To applications an IP packet consists of a header which includes the address of the destination and a payload which contains the data. The IP protocol itself also defines housekeeping packets but these are not of direct concern to most applications.

IPv6 and IP Addresses.

Updating the basic Internet Protocol can be very disruptive. In order to avoid frequent changes it is necessary to address a number of issues at once. For a more complete understanding of IPV6, you should read the IPV6 Charter.

In this essay I am focusing on a particular aspect of IPV6, namely the increase in the number of "IP Addresses" available. The current limitation of 32 bits means that there are four billion addresses. While this seems to be a large number, even if we assign one address per person it isn't sufficient. In practice there are already multiple devices per person. As the Internet has grown, the complexities of routing packets have required partitioning the address in order to facilitate the process. This has exacerbated the problem.

We can loosely separate two agendas:

The backbone agenda is about improving the efficiency of the Internet infrastructure. For the sake of this essay I will only note these issues to the extent they seem to interfere with the edge agenda.

The edge agenda is about making more addresses available so each host can have a public presence. It is about making more addresses available as well as improved protocols for automatically assigning addresses. For simplicity I'm focusing on the increase in the number of addresses. IPV6 can be deployed at the edges of the network using the existing IPV4 network as a transport.

The two agendas are intertwined to the extent that there must be an agreement on the format of an IPV6 packet and the layout of the IP address. But now that there is agreement on the packet format, we can and must deploy IPV6 from the edges.

With and Without

To understand the importance of IPV6 we can compare two scenarios.

Without: If we continue business we will simply accept that the Internet used to be exciting but we have to get back to business as usual. Experiments at public access will have mixed results and all-to-often will fail. Hotels will provide some access but it will be limited and expensive. We will find the Internet is increasingly like television with the transport providers carefully selecting which services will work and how well they will work. To most people this won't seem to be a problem and the economic doldrums will seem to be a higher priority. After all, this is the post Internet era and we should reduce our expectations.

With: I'll have to tone this down to be taken seriously. But think about being able to take your computer anywhere and it would just be connected. But why not? Especially if I could just drop an access point anywhere and connect simply and securely. What might not be obvious is that the kind of "Moore's Law" price/performance improvements that have made email free (once one has paid for a pipe to the rest of the Internet) would operate to make these access points act as part of a common good in the same way that we generally allow others to benefit from porch light or a restaurant doesn't charge for tap water. These aren't free either but it would seem counter-productive to try to charge a passerby who uses that light to read a map. The key to driving this cycle is simplicity. This is not the post-Internet era. We haven't even started to explore the possibilities.

One lesson I've learned with VisiCalc is that seemingly minor decisions can make a big difference. In making home networking a normal retail product I took a step towards demystifying the Internet and making connectivity just another commodity. But I was only able to take the first step. I accepted the evil of NATs (Network Address Translation) as I awaited the deployment of encrypted IPV6.

We have waited too long and there is no reason to wait any more since IPv6 can be deployed from the edges without waiting for any changes to the Internet itself!

The Challenge of 802.11

802.11 is a standard for wireless networking. The 802.11b version is equivalent to a 10 megabit Ethernet without the wire. 802.11 changes the landscape by making it easy to provide network access in public places. But it also renders firewalls ineffective.

802.11 doesn't present us with new problem but it does make preexisting problems harder to ignore. Attempting to solve these problems by creating special mechanisms for 802.11 is difficult and, ultimately, futile. Even if we have perfect security between the access point and the mobile device, we are still exposed to at the access point.

The number of addresses available in IPv4 means that the mobile devices do not have a real presence on the Internet. This is the same problem that we face in home networks and within many corporate networks that assign local address such as 10.x.x.x. As long as one simply uses the Internet for Web browsing or only uses cooperative or peer computing within carefully constructed environments this seems to work. But once you travel you find that you can't just connect back to your server and need to setup a complex set of special "virtual pipes". These too fail as soon as you need to connect to more than one system and, after all, the Internet is about being able to connect to any other system, not just a predefined group of approved systems.

A Simple Solution: Encrypted IPv6

Enough addresses for everyone to be a full participant.

The 32 bit IP address allows just four billion addresses. This might have seemed a lot to a few people in the 1970's (though many of us knew that it was far too small) but we are now paying the price. Since we are unable to assign each computer its own address, most systems cannot be full class participants and must depend on other system to act as their proxies or to use elaborate schemes (such as Network Address Translations). These approaches fall short of allowing systems to be full networking participants.

The version 6 address is 128 bits long. In practice it is implemented as a pair of 64 bit addresses. The first part is used to simplify packet routing (more on this later) and the second part provides each local system with 2⁶⁴ addresses. This means that every system can have a unique IPv6 address and be a first class participant on the network. Peer to peer connectivity can once again become simple and normal.

Making it safe to work together

Actually, they can't unless they can do so securely.

It is hard to start out with insecure systems and then patch them. The early system implementations were done in isolated environments where the priority was on sharing with your colleagues rather than making sure the systems are locked down. The PC implementations were particularly problematic since they would normally share all their services to others on the network. Just clicking on "Network Neighborhood" would show all the systems and let you look at them. This became very obvious with the first cable modem deployments which treated all systems on the same segment as if they were on a common LANs.

A quick fix was to block all ports and only permit selective access. Unfortunately rather than giving each user the ability to better control sharing, these port blockers or firewalls were imbued with seeming magical power to know what sharing was good and what was bad. The result was to frustrate the ability to take advantage of the Internet while leaving systems within the firewall easily exposed to even casual breaches. With 802.11 the IT managers are faced with a choice of trying to police all possible points of access or working to make it safe to fully participate in the Internet.

IPv6 provides an opportunity to build protocols that are secure. Instead of having to put up a wall against a hostile internet we allow individuals the option of sharing. And it is this sharing that creates real value by building a community where everyone contributes. Real security also requires that we also encrypt all traffic. As the problems with 802.11 link-level security demonstrate, we need to provide security along the full path and not really on the benevolence of access points.

Deployment Issues

The edges vs the Backbone

To be fair, I am not in the hot seat and do not have to address all of the technical issues. More to the point I can be very cavalier waving aside the operations concerns of those operating the Internet transports.

Converting the core of the Internet to a new protocol is indeed a major task with high costs and risks.

Deploying IPV6 addresses at the edges over the existing IPV4 infrastructure is a very different proposition. It can be done incrementally. In practice actually getting the code deployed on millions of systems requires strong advocacy but this is still far easier than replacing the core of the Internet while it is running.

The converse is not true. There is little incentive to deploy IPV6 within the backbone of the Internet without a demand from the edges.

Deploying V6 at the Edges

While there has been progress in IPV6 deployment the ultimate test is whether it "just works". It took a long time before PC users could just open up the box and plug the PC into an Ethernet connection (or wireless) and expect it to "just work". With DHCP and full support standard in today's PC users IPV4 has achieved this status. In fact, many of the programs are due to complex instructions written for older systems are that create unnecessarily complexity.

The process of deploying IPV6 requires that the actual protocol be available as soon as possible in order to allow for existing applications to overcome their implicit dependencies on IPV4 such as the use of 32 bits for the Internet address and explicit parsing of the 000.000.000.000 IPV4 address format.

The ability to make use of IPV6 in new applications should not be limited by the difficulties in updating old applications.

The purpose of IPV6 deployment is to encourage and facilitate the development of new applications. The purpose of encrypted IPV6 is to enhance the safety of the Internet and to make it more difficult to hobble innovation.

The essential requirement of the initial deployment of IPV6 is to start a marketplace process. Once IPV6 is usable, it will be used when it is the most effective means for solving pragmatic problems.

Initial deployment requirements.

• There must be an IPV6 implementation for the platform that is available in the default configuration.
• IPV6 deployment cannot depend upon new infrastructure. Any two systems on IPV6 compliant local networks must be able to communicate using public names. Since the current DNS entries support V4, the V6 implementation should be able to build upon this base. V6 also has the additional requirement of being able to access the interior machines. See the "Evolving the DNS" for a proposal on building V6 names using V4 facilities.
• Connections should be encrypted unless otherwise indicated. This is a major change from IPV4. This means that two systems must be able to exchange keys. It does not say that the mechanism should be nor that there be a specific policy for authentication.
• Security is a prime consideration. Unlike the current world of V4, V6 applications must be designed with security in mind and not be promiscuous. This doesn't guarantee safety but it should afford the level of protection offered by today's port-blocking policies since all ports are effectively blocked and opened explicitly when appropriate.

We can speculate on the next steps:

• IPV6 should be the preferred means of implementing P2P connectivity. The DNS can also serve as the default choice of extending the namespace for these new applications (assuming that we have unfettered names as opposed to .COM names as described in my comments on the future of ICANN). Remember the URNs (identifiers and locaters on the Web) as still based on the DNS as a source of unique identifiers).
• While moving legacy applications to V6 is not the highest priority, there is a value in migrating the Web to V6. New browsers and platforms will provide native V6 support. But sites will still need to be accessible from V4 only client platforms. Proxy platforms can provide translation services. This is already done within the V4 world by forwarding HTTP requests. There is some overhead associated with this forwarding requests but this will only be necessary for supporting older clients. Such mixed support will be similar to the problem of supporting the existing mix of browsers.
• Because of the ready availability of V6 addresses we can start to experiment with using addresses rather than ports to support multiple services on a single platform. For example, mail servers are assumed to be on port 25. With IPV6 we can simply have an address per mail server even if on the same machine.
• Once we can assume encrypted connections email delivery becomes much more secure. Most email programs now connect to an ISPs SMTP server which relays the mail to a destination host that holds mail for polling by the destination system. As we begin to assume full time connectivity to the Internet direct delivery of mail should become more common. Since encryption is assumed, direct delivery of mail becomes automatically and simply private. This is much simpler and thus more usable then trying signing and authenticating each letter—an approach that that has failed to catch on.

The real value, however, is in the ability to create new applications that connect a larger number of devices that aren't even accessible now. A trivial example is being able to make a connection with a light switch in my office and a light at home. Of course, such access to a fixture within a home emphasizes the importance of making security fundamental and pervasive.

Technical Issues

Note that there may be technical errors in this section as IPV6 is evolving and there are various draft proposals for how to addresses these issues.

Using the existing IPV4 network

The proliferation of NATs has created a problem in that most systems don't know their public address. The other problem is that the protocols for transporting IPV6 over the existing network requires support of a new packet type and few, if any, of the NAT boxes have a way to process such packets.

Ideally the NATs would be upgraded to act as V6 routers but we can't depend on this and there is little incentive for them to rush and implement this capability. "Shipworm" is the name of one such approach by Microsoft.

Evolving the DNS

In order to make effective use of IPV6 we need to be able to use DNS names for IPV6 connections. But we have a horse/cart problem in that there is no incentive to fully support IPV6 in the DNS until it is widely used. Many of the ISPs, especially those supplying cable modem and DSL access can barely keep their current services functioning let alone provide new capabilities.

We need some creative approaches that can work now without creating too many problems to be cleaned up in the future. Two ideas:

• The Hybrid name. This name contains two identifiers, a global and a local. The global identifier is a V4 address and the local is a local network address. The V4 part would return a normal V4 address that would be used as a 6to4 routing prefix. The local part would be value with a LAN. If I do a local command like "ping rmf19" it will find that machine without requiring a DNS server. If I type myhouse.frankston.com::rmf19 I would get a V6 address for rmf19. If the :: is a problem another syntax like rmf19.v6.myhouse.frankston.com might be need for compatibility. The advantage of this approach is that the only new mechanisms are the name binding system on hosts that already support IPV6 and the support of a standard service within the destination site associated with the prefix. At this stage this might be too much to ask for.
• This party dynamic DNS services. This is, perhaps, a more fruitful approach since these services are already available for V4 users. There is no reason to depend upon one's ISP for a DNS listing. TZO.COM is an example of such a service but it does not (yet) support IPV6. Unlike the hybrid approach, this approach requires that each machine be registered externally and such registrations become problematic when there are large numbers of local devices.

Whether either of these are the best choices, the ability to use names for IPV6 addresses cannot wait until we have a full IPV6 infrastructures.

Encryption

It is important to separate encryption itself form other agendas such as authentication. The most important goal is to prevent third parties from interfering in exchanges between two end points on the network.

In many cases the two systems already have a relationship such as a laptop connecting to a corporate network. Within a home network the systems can share a common secret. For third party connections public key approach can be used.

The main challenge in security is establishing that identity but this should not be necessary for simply encrypting the exchanges. By having a modest goal, it should possible to make encrypted exchanges the norm.

Actual Availability.

Microsoft

Encrypted V6 should be a high priority for Microsoft. At very least it should be a key part of the current focus on security. But, more important encrypted V6 is necessary in order for Microsoft to be the master of its own fate and not be subject to even well meaning meddling from competitors operating the network.

The good news is that Microsoft is including a production version of IPV6 in the next editions of XP (the .Net) series but it is unclear whether the initial implementation will meet the "just work" test and there is no indication that encryption will be any more viable than it is in the current IPV4 world.

While this is a production build it doesn't seem to be in the "just work" mode yet. And Encryption is not yet fully supported and is neither enabled by default nor simple to use. In order to trust the connections the users must be able to assume encryption and be warned when it is not available.

I can sympathize with Microsoft's challenge in simply keeping up with its customers' demands. Deploying IPV6 in order to giving home computers and those within corporations a first class presence on the Internet doesn't seem to be a visible problem. Most users are still in web potato mode since it isn't obvious how to do much more. Gamers and geeks find ways to work around the limitations with special hacks and proxies. Corporate IT departments are reluctant to allow their users direct access to the world. This attitude is changing but the risk of being blamed for problems outweighs the opportunity to create new value.

But now that security is a stated priority for Microsoft, encrypted V6 should be seen as an important part of this mission.

The Danger in the Middle

It also makes those at the edges beholden to those in the middle of the network. As David Reed points out in Attack of the Middleboxes we already see examples of network operators hijacking connections. This may be done in the name of efficiency but even something as seeming innocent as providing a local SMTP server has consequences in not supporting the same protocols (such as authentication) as the intended server. The problem gets worse as we carriers try to second-guess traffic. A favorite topic at billing conferences is how to bill services used over the Internet so we can return to the good old days when the telephone companies in the middle could determine the charges for services rather than the users.

A number of the cable modem providers completely prohibit their subscribers from running servers. This includes calling people who have webcams abusers. ATT Broadband is an interesting case. The portion of their services that was originally @home has such prohibitions in the terms and conditions. But for former MediaOne customers there is not only no such restriction, the terms and conditions explicitly say that they are not responsible for problems when subscribers do run such services. Yet their FAQ (Frequently Asked Questions) is explicit about saying such services are prohibited and the customer support people often make the same statements. Many providers seem to view NATs as being illegal because they give the customer the ability to use the network from more than one computer. The very concept that they decide how one users the connection is abhorrent and very frightening It is an attitude that views the Internet as if it were a television channel and the NAT is a set top box. How can one explain to people who have such a distorted view of Internet and connectivity that one wants to connect devices and services they cannot conceive of? These are people who spent seven billion dollars on Excite in the misguided notion that they had a captive audience!

We already see attempts to censor and thwart the use of the Internet in ways that seem disruptive. Since innovation is generally disruptive this means that the innovation on the Internet gives way to a traditional mode in which one must ask permission and justify every new idea. Such a scenario would indeed be a return to the good old days of slow growth and stagnation.

It is futile to try to reason with those who can exercise absolute control over one's connectivity. It is vital that we deny them the opportunity. Encrypted IPV6 is such a means.

While such statements seem extreme, so did the early promises of the power of the Internet. The Internet was driven by the simple idea of empowering the users of the network rather than making them dependent upon an omniscient and benevolent network operator.

What Can be Done?

Without Microsoft's full support the task of moving to widespread use of encrypted IPV6 will be more difficult but still doable. IPv6 on other platforms needn't have the limitations of the Microsoft implementation and one can still provide alternative implementations on Microsoft's platforms. Or, even simpler, build upon Microsoft's implementation by the automatic configuration of addresses, DNS updates and security features.

While I have a personal interest in such implementations I also realize that there is only so much I can do by myself. For now my goal is to educate a community of user about the importance of both IPV6 and encryption.

Conclusion?

No real conclusion as IPV6 is still an open issue. The biggest challenge is in making people aware of the importance of returning to a simple Internet that can support innovation and exciting new ideas.

Towards this end we must assure that there is a focus on IPV6 at the edges. As users we should demand it of the vendors and as implementers we should make use of IPV6 and, when possible, provide our own implementations.

The ISOC Status Report

ISOC posted a briefing on The Transition to IPv6 dated January 2002. My reaction is that it is focused on the wrong issue and, in fact, illustrates the problem. It is positing a transition to a fully IPV6 network. That is the wrong goal. It is a long process that doesn't focus on the real urgency of making IPV6 available now as a way to enable the deployment of new applications.

Some transition is useful such as making some HTTP transactions interoperable. But the deployment of IPV6 is not about getting the technology right. It is about seeing that the Internet is about a process that is driven by the needs of users at the edges of the network. This is a very powerful idea and, even better, is a far simpler problem.

The first step must be to give the user the capabilities of using IPV6 without being dependent upon any of the current Internet access providers to even have to know how to spell "V6". (No, it is not a vegetable juice, that's V8).

We can build a V6 Internet on top of the existing V4 Internet without having to ask anyone's permission. We don't even need to involve the IETF. Of course, it is far better to work with the IETF and ISOC to focus efforts on creating larger comments. But the triumph of the Internet is that is just a good strategy but not necessary.

But misguiding its efforts into converting the Internet, ISOC is working against its best Interests and making the IPV6 conversion a formidable and, in the end, impossible task. Instead of shifting to IPV6 we will see more effort going into extending NATs and interrealm connectivity (including VPNs). Each such work-around is rewarded with immediate benefit whereas no one can afford to risk the questionable benefits of a slow and difficult IPV6 rollout.

Deploying IPV6 at the edges, however, creates the right incentives. Individual systems get the immediate benefit of connectivity and the connectivity creates IPV6 communities. If ISOC works with this process, it can help to greatly accelerate the deployment.

And, to be responsible, it should also strongly encourage and assist in making sure that encryption is universally available and that the users can rely on their transactions being safe from meddling.