Home / Blogs

Thoughts on IPv6 Day

Jeff Pulver proposed an interesting idea called IPv6 Day:

“Collectivity we should pick a day, at some point in the near and foreseeable future and push everyone to reboot themselves and make it such that from that point forward, IPv6 will be supported on all networks which interact with the public Internet.”

In geeks term, we call this a ‘flag day’. The last time we have a flag day was 1st Jan 1983 when Internet moved from NCP (Network Control Protocol) to IPv4.

So why not do it for IPv6?

Well, first of all, there are far far less hosts connected to the Internet back in 1983. Today, we have all kind of IP devices, some of them requires firmware update or total replacement to go to IPv6. A flag day for IPv6 would potentially cost as much, if not more, then Y2K. (yes, please laugh)

Even if we figure out how to pay for the upgrades, most of the IPv6 routers today are software based except some high-end routers. This means the performance is much less with the IPv6 switch on. This has been one of the major stumbling block in getting ISPs to deploy IPv6. No ISP I talk to is willing to put software routers onto their operational network.

Even with the routers solved (things are looking good in the last couple of months actually), the planning for IPv6 flag day is going to take years. Japan, for instance, has declare that all their network will be IPv6 ready by 2005. All indication so far is they will likely to push back the deadline. A flag day in 2005 is far too aggressive…2010 or 2015 may be more reasonable.

But the most important reason of all, there isn’t a real demand for IPv6 today. While there is significant reasons to move from NCP to IPv4 back in 1983, such reasons does not exists for IPv6. No demand, means no business, means no ISPs will migrate. Ideological appeals like End-to-End are nice but not sufficient to move ISPs who looks at their bottomline.

What about IP address exhaustion? Sorry, that’s a myth. I did a presentation in WTSA in Brazil using Geoff Huston data which projects we don’t run out of IPv4 address until 2020++.

But we do need IPv6. We need to bring back End-to-End so machines can talk to each another Peer-to-Peer, without Man-in-Middle. We need to get NAT out of way so protocol like SIP can be more seamlessly deployed without STUN and other NAT traversing tricks.

As Mao Zedong once said: “Revolution starts from the country side”. Likewise, IPv6 revolution will comes from the edge. More applications should start using IPv6 like Three Degrees. Better yet, have a killer IPv6 SIP application. These will give home users reasons to install IPv6 and use IPv6 on their home network. Create the demand from the users, the rest will follows.

Partial Disclosure: We support one project to create IPv6 SIP. More details later.

By James Seng, Vice President

Filed Under


The Famous Brett Watson  –  Nov 18, 2004 1:21 AM

I don’t particularly want to see the end of NAT. There is something comforting about a routing boundary between the Internet and my own private networks: the assurance that there is no theoretical way for hosts on my private network to be addressed by the big hostile Internet-at-large except when the NAT process causes such a connection to be possible. Sometimes my use of non-Internet-routable addresses is a *feature*, not a compromise. The “man-in-middle” whose presence you lament is sometimes a much-wanted border guard.

It may be that the same effect can be achieved with IPv6 and an appropriate firewall configuration. Be that as it may, there’s an awful lot of upgrading and retraining involved in the transition to IPv6 for no obvious benefit. Assume for the moment that if I make the migration to IPv6, I’ll want to use a firewall to re-create the lack of end-to-end connectivity I had under NAT, just to simplify my security concerns. Now remind me, why do I want IPv6?

I belong to the school of thought which says we should start designing NAT-friendly and proxy-aware protocols, rather than push for universal end-to-end connectivity. This puts me on the other side of an ideological chasm, of course (although it doesn’t hurt for protocols to be proxy-aware even when full end-to-end addressing is possible). My argument is this: I believe in the end-to-end principle for any given network, like the Internet, but I no longer want many of my machines to actually be *on* the Internet directly, because the Internet is a hostile environment. That’s the facet of this problem that the IPv6 end-to-end boosters too often overlook: network segregation is sometimes a feature, not a compromise, and we need to design protocols that don’t *demand* end-to-end in order to work.

By these criteria, most of the VoIP protocols are found wanting and need fixing. Suggesting that we migrate to IPv6 to solve the problem is the wrong answer, because if and when we do that migration, firewalls will still prevent end-to-end connections in many cases. You could, of course, suggest to systems administrators everywhere that their firewalls are hurting the end-to-end principle, and should therefore be removed. Just be sure to have an escape route planned before you suggest it, and be prepared to duck.

James Seng  –  Nov 18, 2004 5:43 AM

At best, NAT = false sense of security.

Security by obscurity does not work. :-)

The Famous Brett Watson  –  Nov 18, 2004 7:00 AM

I’d like to hear a better argument than that. Security by obscurity is where I don’t tell you what my IP address is. NAT is (roughly speaking) where you can’t address a packet to my host unless it contacts you first, even if you *know* what my IP address is. A NATing router would have been a perfectly good defence against the Blaster Worm, for example (until such time as someone brought the worm into the network some other way).

You’ve given me the brush-off, and I’m not impressed by it, smiley notwithstanding.

Mark Smith  –  Nov 19, 2004 10:55 AM


Below are a number of URLs to documents describing the issues that NAT creates, or how it damages the end-to-end model of the Internet and why that damage is worth avoiding.

The first one is the most important - it describes why end-to-end is the best way to implement network based services, and why it is the model that has been followed during the design of the Internet.


The old telephone network was the opposite of the “end-to-end” architecture, as services were implemented in the network, rather than at the edges. There was a reason for that, now that reason has gone. Building services within the network increases the costs of the network, with one of the major ones being the deployment of new, network based services.

The end-to-end argument can be summarised as “dumb network, smart hosts”. This paper describes why the Internet architecture ie. end-to-end is better than the “smart network, dumb hosts” model.

Rise of the Stupid Network

NAT builds both state and application understanding within the network. It moves away from the “dumb network, smart hosts” model. This naturally increases the costs of the network, which the users of that network ultimately end up having to bare. It is not the cheapest or optimal solution to the problem.

There are a number of documents which either wholy or partly address the implications of NAT. They aren’t necessarily only providing theoretical argments against it, they also provide practical examples of where NAT creates costs that would be best avoided :

Architectural Implications of NAT

Why are NATs so popular?

Things that NATs break


IP Network Address Translator (NAT) Terminology and Considerations

Traditional IP Network Address Translator (Traditional NAT)

NAT also fails the simplicity goal - in addition to modifying the destination or source IP address in each IP packet, it also has to modify the TCP checksum (as the TCP checksum covers a pseudo header which includes the IP addressing information carried in the IP packet header). Also, for protocols such as FTP, which carry IP addresses in text format, the NAT box may have to offset TCP sequence numbers if it has to increase the length of the IP address within the payload eg “” being expanded to “” increases the number of characters in the payload, which requires the TCP sequence numbers in the TCP header to be offset / reset as the packet traverses the NAT box. This problem gets real ugly when the “” is split across two TCP segments, which TCP is quite freely permitted to do. All this is assuming that the NAT box understands the application protocol in the first place.

More broadly, NAT is really deployed to directly fix “duplicated” or “overlapping” address spaces. Security is not really the reason - a firewall deployed with public address space is as secure. A couple of good links on why duplicated address spaces are worth avoiding. Note that the second is referring to IPv6 “site local” addresses, which are the IPv6 “version” of RFC1918. The same arguments apply to IPv4/RFC1918. I’ve personally been burnt by the VPN issues identified.

Network 10 Considered Harmful (Some Practices Shouldn’t be Codified)

Deprecating Site Local Addresses

VoIP technology has been around for a long time. Maybe it hasn’t become the next “killer app” because of NAT ? If VoIP could have been deployed just as easily as web browsers were (by end-users downloading it onto their edge-devices, and not having to upgrade their “router” ie. router + NAT box), we may have had cheaper phone calls for the last few years.

(and yes, I’m the Mark Smith you probably think I am)

Mark Smith  –  Nov 19, 2004 11:08 AM

I’ve also written about some of my bad experiences with NAT as a comment to the following article, also on this site :

IP or NAT IP: Mostly IP

Mark Smith  –  Nov 19, 2004 12:39 PM

All this IPv6 / NAT discussion reminded me of something Tony Hain pointed out a while a back on the IPv6 IETF mailing list.

Tony pointed out that IPv6 is inherently better at hiding a users machine than IPv4 NAT, as a users’s PC will typically be connected to a LAN segment which has been allocated a /64. A /64 leaves 64 bits for the node address, giving a total of (2^64) or 18 446 744 073 709 551 616 possible addresses. The user’s PC could be at any one of these addresses, based upon the IEEE MAC address of their LAN card.

If an attacker could probe 100 addresses per second (using a tool such as nmap), and assuming that the attacker would find a machine on average 50% through the address space, it would take an average of 92 233 720 368 547 758 seconds to find the user’s device, or 2 924 712 086.77 years!

If the user still isn’t happy with those odds, their node address could be changed periodically, say once a day, via Privacy Extensions for Stateless Address Autoconfiguration in IPv6.

The current recommendation for IPv6 address allocation, for all users, including those at home, is a /48, which reserves 16 bits for 65 536 subnets of 64 bits (IAB/IESG Recommendations on IPv6 Address Allocations to Sites). The truely paranoid could extend the randomness of their periodic node address selection to including some, if not all of those 16 subnet bits, assuming they are willing to automate their local router’s subnet configuration. Of course, for every subnet bit included, the work the remote attacker has to perform to find the user’s PC doubles.

While I wouldn’t recommend it, I’d almost go so far as saying for a typical home user, IPv6 without a firewall of any sort will be just as effective as IPv4 + NAT is at “hiding” their PC.

In other words, remote attacks which rely on finding a target via an address probe are useless under IPv6, as they aren’t worth the time. Aren’t they the only type of attacks that IPv4 NAT inherently protects against ?

Social engineering attacks will then probably become the alternative to address probing, using techniques such as convincing a user to download something they shouldn’t from an untrusted web site, or sending them a malicious payload in an email. Of course, IPv6 won’t protect against those types of attacks, then again, neither does IPv4 + NAT today.

The Famous Brett Watson  –  Nov 19, 2004 5:38 PM

Thanks, Mark, for that well-considered response. Some of the points you’ve raised are quite interesting. A sparsely populated address space like IPv6 will certainly have an impact on how malicious code propagates.

But in response to your last point, the security offered by a difficult-to-guess IPv6 address is still not quite as strong as NAT. The security offered by IPv6 is more like what James called “security by obscurity”, since anyone who actually knows your IP address can send packets to your computer. With NAT, the knowledge of the address is unhelpful, since the address isn’t routeable. The avenues of attack in NAT are limited to those that can be conducted where the victim host initiates contact with the hostile host.

Now, as you’ve pointed out, IPv6 addresses aren’t really guessable in a useful way, but they’re not what you would call closely guarded cryptographic secrets either. You reveal your IP address to any host with which you initiate contact, and also potentially to anyone in a position to eavesdrop any of that communication. Is there some DNS record pointing at you, perhaps? The surest way to be safe in IPv6 world (without a firewall) is to not talk to any other hosts: that way you can be relatively sure that your address remains unknown. Anything more than this is something of a compromise.

To achieve the security of NAT in an IPv6 environment, you’d need a router which does the NAT-style state management without actually translating addresses. A firewall, essentially, with reduced complexity relative to full NAT, but a man in the middle that deliberately breaks end-to-end connectivity all the same.

This is more or less my point: on the one hand, I think that the end-to-end design of smart hosts and dumb routers is the best thing since sliced bread; but on the other hand, there are strategic points at which we all want to break that model for security reasons. NAT breaks it. Firewalls break it. Even if we disposed of NAT with IPv6, most of us would still create largely isolated sub-networks for security reasons. I think we need to better understand this issue and start thinking about a network model that embraces it. Think of it as networks with customs checkpoints and border guards. The network is still dumb in the middle and smart at the edges, but there may be “border crossings” involved in getting from one point to another, and these count as a form of “intermediate edge”, if you like.

By embracing NAT I’m taking on a sort of “devil’s advocate” role, of course. NAT is a hack, and creates all sorts of problems: I won’t even attempt to deny that. (Some of your references I’ve already seen; the others I’ll be sure to read in future.) Even so, NAT provides useful effects, beyond compensating for IPv4’s address limitations; NAT is not *just* a problem to be eliminated. If we want to work towards a cleaner solution, we must understand this, and incorporate NAT’s benefits into the new way of doing things, while getting rid of its ugliness.

I suspect that such a revised model of networking will also have a thing or two to say about application protocol design. Few of our existing protocols have been designed with security checkpoints in mind, nor do we have much in the way of protocols by which a host can negotiate (with a border guard) right of passage for incoming guests.

But enough speculating about theory for now.

Mark Smith  –  Nov 22, 2004 4:37 AM

Brett Watson wrote :

“To achieve the security of NAT in an IPv6 environment, you’d need a router which does the NAT-style state management without actually translating addresses. A firewall, essentially, with reduced complexity relative to full NAT, but a man in the middle that deliberately breaks end-to-end connectivity all the same.”

Brett, you may also be interested in having a read of Distributed Firewalls by Steve Bellovin -

“Conventional firewalls rely on the notions of restricted topology and controlled entry points to function. More precisely, they rely on the assumption that everyone on one side of the entry point—the firewall—is to be trusted, and that anyone on the other side is, at least potentially,  an enemy. The vastly expanded Internet connectivity in recent years has called that assumption into question. We propose a “distributed firewall”, using IPSEC, a policy language, and system management tools.  A distributed firewall preserves central control of access policy, while reducing or eliminating any dependency on topology.”

A firewall on each end-user edge device sounds a bit over the top, until you realise that that is already happening. I think I read that starting at the low end version, XP has a firewall out of the box, and SP2 for XP enabled some fairly strict default firewalling rules. Of course, many of the *nix distributions, intended to run on end-users PCs, have firewalling out of the box as well. End user firewalling at the edge is happening because of necessity, rather than by design.

Of course, by putting the firewall on the communication end points, rather than in between them, end-to-end is restored. We return to the pure “dumb” network, a stateless, application agnostic bit delivery infrastructure, again returning all the smarts to the edge.

Jothan Frakes  –  Nov 22, 2004 7:15 AM

Many of the changes that have come in paradigm shifts, like vinyl albums to CD, like VCR to DVD, and even in the current drive for Standard PAL, SECAM, and NTSC analog television signals moving to Digital, High Definition broadcasts happen because there is some exciting value proposition in the time/money investments that go along with them.  Digital media offered improvements along with the investment.

Infrastructre based changes are less exciting to the general consumer, as the benefit is not apparent to them.

To the layman, (and I apologize that this is a US-Centric example) the move towards IPV6 is not much different than when we went from 5 digit zip codes (90210) to using the +4 zipcodes (90210-3465).

In the case of IPV6, the motivation has not shown itself in a “Hey, this is completely important!” way to the audience… Those that ultimately make those investments.

There has been one driving push towards IPV6, which is the fear of scarcity in the IPV4 numbering space.  RFC 1918 (NAT), in combination with Masquerading and Proxying created a very strong dent in the argument of scarcity in the IPV4 space. 

While there are values to End-to-End, peer-to-peer that are gained from IPV6 for more seemless SIP (et al.), the fundamental technology has IPV4 compatible workarounds (STUN, DNSproxy, UDP over HTTP, etc.).

I am willing to bet that new uses which inspire people to spend the time and money to upgrade are going to be what truly drive any form of widescale adoption of IPV6.

Sure, there are many cool new applications, threedegrees, toredo, SIP, VOIP, and other technologies are able to utillize IPV6, yet all work with IPV4.

If the next ‘killer app’ were to offer advanced features in the presence of IPV6, or for that matter simply require that IPV6 be used, it would drive more adoption.

Adoption is the key here, and market forces are what will ultimately drive adoption of the technology. 

broken link Stephan Folley  –  Dec 12, 2010 4:35 PM

The link to the IPv4 exhaustion presentation (http://bgp.potaroo.net/ipv4/) is broken :(

Is it still possible to reach it somewhere? It spotted my interest, and I’d like to know what the arguments are. As it was made years ago, do you believe it is still applicable today?

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign


Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign