"Dave predicts that computers will be equipped with optical connections instead of pins for networking, and the volume of data transmitted will overwhelm routers, which at best have mixed optical/electrical switching," writes Oram. "Sensor networks, smart electrical grids, and medical applications with genetic information could all increase network loads to terabits per second. When routers evolve to handle terabit-per-second rates, packet-switching protocols will become obsolete. The speed of light is constant, so we'll have to rethink the fundamentals of digital networking."

"To deliver content effectively, Web browsers typically open several dozen parallel TCP connections ahead of making actual requests. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable. Our research shows that the key to reducing latency is saving round trips. We’re experimenting with several improvements to TCP."

Cheng believes the current transport layer badly needs an overhaul to catch up with other (networking) technologies. Read more.

Nixu DDI Software Appliance Platform Awarded Gold Medal for Its IPv6 Support on 21st December 2011

The exhaustion of IPv4 address space in 2011 made IPv6 connectivity an unavoidable reality. While most organizations are yet to face an urgent need for introducing IPv6 support in their networks, they should nonetheless, plan ahead to ensure a smooth transition to a dual-stack environment. The increased complexity of the IPv6 address syntax and the vast size of the available address space mean that DDI services (DNS, DHCP, IPAM) play an even more pivotal role in managing these dual-stack networks.

Having introduced full dual-stack support already in 2004, Nixu Software has been a pioneer in the wide-scale adoption of IPv6 network connectivity. Juha Holkkola, the Managing Director of Nixu Software, said in this regard: "When we started out working with dual-stack environments, there was no strict standard, let alone any certification available. Now that IPv6 is going mainstream, we decided that it was a good time to have Nixu DDI platform's world-class IPv6 support formally acknowledged. Our products sailed through the testing phase in a matter of weeks, which is pretty impressive considering that for some of our competitors it has taken over a year, while for others it seems completely impossible."

To celebrate this achievement, Nixu Software has released a new version of howismydns.com, a free online test tool used to validate the configurations of public DNS servers. This latest version provides complete support for dual-stack networks, allowing fully transparent testing process for IPv4, IPv6 and dual-stack DNS deployments. In addition to IPv6 support, the new toolset also comes with a number of DNSSEC validation tests. To try out the latest IPv6 DNS and DNSSEC testing tools, please visit howismydns.com.

They observe that bots typically live on cable or DSL connections with slow congested upstreams. TCP sessions from bots turn out to be fairly easy to recognize by RTT, window, and retransmits, something that people have known at least since a paper at the 2008 CEAS conference on the topic.

This paper tries to see whether it would be practical to use that info to manage spam in real time. They have a network analyzer called SpamFlow that figures out per-connection characteristics. Then as a proof of concept they wrote a Spamassassin plugin to train on the data from SpamFlow and try and do filtering. They do some sort of hand-wavey load testing to see whether SpamFlow can keep up with a realistic mail load, and if it trains fast enough that it would provide useful data in real time. They claim that their results show that it does both.

It's not obvious how best you would use this in combination with all of the other anti-spam tools people we have, most notably blacklists like the CBL that very accurately identify IPs of botted hosts by looking at the characteristics of mail received at large spamtraps. One thing that occurs to me is this sort of thing might be useful if mail moves to IPv6, since building v6 blacklists will be hard due to the size of the address space, while this lets you estimate the bottiness of each connection directly. Also, rather than accepting or rejecting mail, you might slow down mail reception from hosts that seem to be bots, both to give preference to non-bot senders, and because bots tend to be impatient so if you slow down a dubious connection and it gives up, it was probably a bot. The Turntide appliance did something similar five years ago, although it used different heuristics for deciding what to slow down.

This technique looks only at the characteristics of the TCP session, and not at the contents of the session, which means it also doesn't look at the contents of the messages. It might be useful in contexts where for legal or political reasons the spam filter isn't allowed to look at the messages, but users want spam filtering anyway. The authors point out that it is in principle applicable to any TCP transaction, so it might be useful against web queries from bots, too.

It's hardly a FUSSP, but it's an interesting paper.

Written by John Levine, Author, Consultant & Speaker

I am a big fan of DDI (DNS, DHCP and IPAM) as magical trio to manage all transactions on network infrastructures… Or to say the least: make it possible.

Basically it makes these "Core Network Services" concise, manageable and integrated. It basically makes the network infrastructures of today and the future possible.

There is however one thing that continuously seems to irritate when talking about integrating these services on networks.

Let's have a look at the Microsoft DNS and DHCP, it's the most used, and has by far the largest footprint of them all. But is it "Integrated"? Seems to be with "Active Directory", but not so with IPAM as there is no real administration of "content" on Microsoft DNS/DHCP (just config and "records"). And Excel really doesn't count! :-).

If we look at Non-Microsoft DNS and DHCP, it seems to be more network/unix territory, and administering and configuring IP-Addresses seems to be more embedded due to historical reasons (maybe). IPAM is more of a common cause here.

So it would be logical, if one wants to apply the magical trio, to replace Microsoft DNS/DHCP, de-integrated it from Active Directory and put it closer to the network, right? (well, I would say yes, but lots of peoples are not convinced).

Actually there are a couple of scenario's that seems to appeal, but get little to no attention, let alone implemented.

Scenario 1: Let's replace the lot

Disable Microsoft DNS/DHCP and let Active Directory use the company wide DDI solution. This is actually no problem at all, and give lots of benefits. In most cases it actually gives Active Directory a boost in performance and all kinds of extra logging and statistical information. And of course integrated IPAM, which is key for any IP based network infrastructure and it's services nowadays.

Scenario 2: Delegate a Domain

Have a company wide DDI solution, but just delegate a domain to the Active Directory domain which will run on Microsoft DNS/DHCP services. So the "connection" is just DNS. You will loose some oversight (feedback) from the services. As long as there are procedures from the DDI team on handing out IP's and Names, it is a workable situation. Not perfect in my opinion.

Scenario 3: Integrate with the MS Services

Have a company wide DDI solution, have an Active Directory with their own Microsoft DNS/DHCP services, but manage both with the same DDI solution. This is very flexible and best of both worlds. It will have an added bonus: IPAM.

Scenario 4: No integration

Let everyone have their own island. Prone to lots of political and technical discussions. The biggest question here will be "Reverse Zones", who will own them… Good luck!

And there are many more, but I keep it by these 4 which seems to be most common.

There seems to be two camps revolving around this:

Camp 1: The Network / System Guys

They want an integral DDI solution, providing DHCP and DNS to the whole world, including Active Directory. Strong users of IPAM want all kind of neat features for failover, redundancy and disaster-recover. DNS and DHCP is a "Network Component".

Camp 2: The Microsoft Guys

They just want to do their own DNS and DHCP for Active Directory and really don't want to do anything else. Redundancy is fine (multiple servers, multi-master, etc). DNS and DHCP is an "Application".

There seems to be a lot at stake for both camps. Both will touch the core of networks. One from the bottom-up and the other top-down and can "boss around" when needed. It's a responsibility with power!

Both camps are also guilty (mostly because of knowledge shortage) by not understanding each other requirements and forgetting about the complete picture, trying to cover their own requirements. Making no decision seems to be more common in these cases. "Let it be" is mostly the outcome.

I think either scenario works, at least if integrated IPAM is part of it. IPAM is in most cases a missing part, out-of-date and disciplinary. Integrating all three components (DNS, DHCP and IPAM), respecting the infrastructure and requirements is the way forward and the way to build future proof networks.

And I have not even thrown in IPv6 and DNSSEC for added complexity! :-)

As said… An observation…

Written by Chris Buijs, Senior Product Manager

… guide the FCC's work on technology and engineering issues, together with the FCC's Office of Engineering and Technology. He will advise on matters across the agency to ensure that FCC policies are driving technological innovation, including serving as a resource to FCC Commissioners. He will also help the FCC engage with technology experts outside the agency and promote technical excellence among agency staff. He will be based in the FCC's Office of Strategic Planning and Policy Analysis.

Henning brings an excellent background to this role, having been one of the co-authors of the Session Initiation Protocol (SIP - RFC 3261) and the Real-time Transport Protocol (RTP - RFC 3550 and 1889), the two main standards used in most Voice over IP (VoIP) systems today. Henning is also the author/co-author of over 70 other RFCs and countless Internet-Drafts and has been active with the Internet Engineering Task Force (IETF) since the 1990's. He also served on the Internet Architecture Board (IAB).

Given the recent FCC workshops on the transition of the Public Switched Telephone Network (PSTN) to new technologies, it's great to have someone with Henning's background and knowledge in a prominent role at the FCC. Henning himself noted this in an email to the IETF DISPATCH working group mailing list, where he noted that the FCC is definitely seeking input from technical folks.

Obviously in this new role he'll be working not only with real-time communications but also with the wide range of other areas that the FCC covers. Regardless, it's excellent to have someone with Henning's background providing this level of advice and input to FCC activities.

Prior to joining the FCC, Henning has been a professor and chair of the Computer Science department at Columbia University. In my experience he's also just an all-around decent person and I'm very much looking forward to seeing what he'll do at the FCC.

Written by Dan York, Author and Speaker on Internet technologies for over 20 years

These are domains like w3.org and ietf.org, which host the technical specifications which describe the World Wide Web and the Internet themselves. iana.org hosts a number of critical protocol registries and databases. These domain names appear in XML namespaces and other protocol specifications, and their ongoing resolvability is key to these systems functioning as expected.

There are other examples. At the Domain Names and Persistence Workshop, which took place at the 7th International Digital Curation Conference in Bristol last week, I heard from representatives of organisations such as CNRI (which operates the Handle.net system) and the International DOI Foundation (which runs doi.org). These systems underpin much of the infrastructure of our modern interconnected life: the DOI system, for example, through CrossRef, is the standardised method by which scientists refer to the work of their peers in their papers. These references need to be persistent over the long-term (digital archivists like to think on the scale of centuries) in order for the work of modern academia to continue, and for future generations to access and understand the development of scientific knowledge.

These organisations are worried that their dependence on plain old domain names under traditional gTLDs and ccTLDs presents a threat to the stable operation of these systems: despite doing everything possible to ensure the ongoing function of these domains, they remain at risk from everything from failing to pay renewal fees, domain hijacking, to having their parent TLD shut down. One of the key questions the workshop tried to ask was: how can we make these domains truly persistent over the long term?

Several options were discussed as possible solutions. The first and most obvious solution is to ask ICANN to "gold plate" these domains, to make sure that they're never accidentally deleted, transferred or otherwise interfered with. Anyone who reads CircleID will probably have a good idea exactly how difficult, time-consuming and unlikely to succeed this approach would be.

Furthermore, it would be rightly argued that creating "gold-plated" (or perhaps "armour-plated") domains would be the thin end of the wedge: while it may be reasonable to protect w3.org on the grounds of protecting the infrastructure of the Web, wouldn't it also be legitimate to offer similar protection for google.com? it may be just as critical (if not even more so), and if that is the case, why not also microsoft.com, ibm.com and any of thousands of other corporate domains?

Another solution would be the establishment of a TLD specifically for domains that are "too big to fail". While some of the attendees discussed submitting an application for a generic TLD in the upcoming application round, it was pointed out that such an "infrastructure TLD" already exists: the Address Routing and Parameter Area, .ARPA.

.ARPA was the first ever top-level domain, used to migrate Arpanet hosts onto the modern Internet. After this had been accomplished it was repurposed as the root of the Reverse DNS (i.e. numbers to names) system. It is now also used by the eNUM system and the little-used Whois replacement protocol, IRIS.

Management of .ARPA is governed by RFC 3172, which states:

This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the "arpa" domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used. The operational administration of this domain, in accordance with the provisions described in this document, shall be performed by the IANA under the terms of the MoU between the IAB and ICANN concerning the IANA.

Delegations under .ARPA can only be requested by the publication of a "Standards Track" RFC - a very high barrier to entry. Nevertheless, many of the systems (such as handle.net) which are under consideration are already specified in RFC documents, which could be amended to include an "IANA Considerations" section. In fact, RFC 3172 states that

Any infrastructure domains that are located elsewhere in the DNS tree than as sub-domains of "arpa", for historical or other reasons, should adhere to all of the requirements established in this document for sub-domains of "arpa", and consideration should be given to migrating them into "arpa" as and when appropriate.

Which strongly implies that domains that are critical to the operation of the Internet's infrastructure are expected to migrate to .ARPA.

Enhancing the security and stability of critical elements of the Internet's infrastructure is precisely what .ARPA is intended to do. At the conclusion of the workshop there seemed to be a consensus that such an approach offered the best chance of a workable solution to the issue of domain name persistence.

Written by Gavin Brown, Chief Technology Officer for CentralNic

http://www.fcc.gov/live

The FCC's note about the workshops mentions that people watching the live stream can send in questions to panelists using either of two methods:

• by e-mailing livequestions@fcc.gov
• tweeting on Twitter using the hashtag #FCCLIVE

Given that a video recording was provided for the first workshop, hopefully a video recording of this second session will also be made available.

Today's sessions look to be quite interesting and contain quite a range of participants. The full schedule and list of participants is available on the FCC's web site (click on "Expand" in the lower right corner of the page), but here is the brief list:

* * *

9:30 a.m. — 9:40 a.m. - Welcome Remarks by Zachary Katz, Chief Counsel and Senior Legal Advisor, Office of the Chairman, FCC

9:40 a.m. — 10:45 a.m. - Impact of the Transition on the Technology and Economics of the PSTN
Participants include: University of Colorado, Carnegie Mellon, George Washington University, Massachusetts Institute of Technology (MIT), Gillan Associates, SIP Forum

10:45 a.m. — 11:45 p.m. - Policies of the PSTN (e.g., accessibility, reliability, affordability, and public safety)
Participants include: Tufts University, Consumer Federation of America, University of Wisconsin, Neustar

1:00 p.m. — 2:10 p.m. - Implementing the Transition to New Networks
Participants include: Verizon, Comcast, Carnegie Mellon, National Telecommunications and Information Association (NTIA), XO Communications

2:10 p.m. — 3:20 p.m. - Syncing Expectations, Emerging Technologies and the Public Good
Participants include: Georgetown University, University of Michigan, University of Pennsylvania — Wharton, Acme Packet, Panasonic Systems Networks

3:20 p.m. — 4:30 p.m. - Economic Rationales for PSTN Transition
Participants include: Queens College, Indiana University, Syracuse University, Sanford Bernstein, University of Auckland, NZ

Written by Dan York, Author and Speaker on Internet technologies for over 20 years

http://www.fcc.gov/events/public-switched-telephone-network-transition

Given that the workshop was 4 hours long, you may or may not want to watch the entire session. The workshop was divided into four hour-long panels that consisted of brief presentations by the various panelists followed by questions to each panel from the moderator and attendees. FCC Chairman Julius Genachowski also appeared briefly to provide a few comments.

The order of the workshop panels is as follows (and differs from the planned agenda only in that FCC Chairman Genachowski's comments came between the first two panels):

• The Impact of Broadband Communications on Public Safety and Network Reliability
• Remarks by Julius Genachowski, Chairman, FCC
• Disability Access in Substitute Services
• Technical Capacity, Capabilities, and Challenges Facing Future Rural Networks
• Identifying, Evaluating, and Transitioning Key PSTN Edge Functionalities (e.g., alarm monitoring, medical devices, and consumer equipment)

In his comments, FCC Chairman Genachowski discussed how the world is changing and moving to an IP network. He highlighted that 19% of the nation's telephone connections are already interconnected VoIP and 30% of Americans have cut the cord and moved to wireless. He spoke of the role of IP networks in unleashing innovation, contributing to job creation, education, etc. and indicated he and the commission are seeking answers to questions such as these:

• how do we minimize consumer disruption in the move?
• how do we ensure public safety access?
• how do preserve and promote disability access?
• how do we ensure ubiquitous access?
• how do we ensure access to high quality service?
• how do we best foster innovation?

He emphasized that the current PSTN is reliable and accessible and we don't want to lose benefits of old system. He indicated that he wants to enable the private sector to take the best benefits of PSTN and bring those into the future while taking advantage of new technologies.

The panelists in each section all saw the transition as inevitable, indicated it was already well underway and raised legitimate concerns to be considered with regard to their topic area. For instance, the sheer number of installed devices connected to the PSTN will take quite some time to change over to devices that can work with IP networks. An example was given that a standard for alarm systems over IP was only standardized within the TIA in 2007 and a similar standard for smoke alarms over IP was only standardized in 2010. It will take quite some time for devices with those standards to propagate out into commercial availability and transition options may need to be evaluated. Similarly, while the use of traditional TTY devices continues to decline, there is still a huge installed base. These TTY devices are designed to work over the PSTN and the traditional protocol used does not work well over IP. These devices will need to either be replaced or have a transition device such as a terminal adapter installed to work over IP networks.

All in all it was quite an interesting session and hopefully did provide the FCC with the type of feedback they were seeking. The second FCC workshop on the PSTN transition takes place tomorrow, December 14, 2011.

Written by Dan York, Author and Speaker on Internet technologies for over 20 years

Circuit-switched wireline voice technology has created a high standard for reliability, accessibility, and ubiquity. Consumers will continue to expect and demand these qualities, even as they shift from PSTN services to services provided over different networks. The transition away from the PSTN is already occurring, and is likely to accelerate. Through these workshops, the Commission will seek input on the technical, economic, and policy issues that must be addressed to minimize disruption during this transition, and to protect consumers, public safety, competition, and other important interests.

The first workshop on Tuesday, December 6, will focus on "what obstacles and opportunities the transition may create regarding public safety, accessibility, and ubiquitous service.”

The second workshop on Wednesday, December 14, will focus on "a wide array of economic, technological, and policy issues that need to be addressed as consumers choose to subscribe to, and rely on, new technologies and services.”

More details about attending can be found in the public notice. The document also indicates that the workshops will be streamed live at http://www.fcc.gov/live

Written by Dan York, Author and Speaker on Internet technologies for over 20 years

It has long been argued that this problem will be short-lived or would be avoided altogether by the switch to IPv6 which does not have any problem of scarcity. The same argument continues that this imminent switch to IPv6 removes any need to address the historical imbalances of IPv4 allocation as IPv4 will cease to be of any importance quite soon.

This argument never felt sound and seemed to me to ignore the perception issue that it creates, which is that those responsible for IP allocation policies, largely based in the developed world, don't care about imbalances that are disadvantageous to the developing world and so can't be trusted to stop this happening again.

Of course anyone who understands IPv6 allocation policies knows that these have learnt a lot from the accidents of history that created the current imbalances in IPv4 and are very different policies. So when challenged on the perception issue, those who argue against correcting the historical imbalances point to the IPv6 allocation policies and politely explain that those imbalances won't happen again.

But there is now strong evidence out there that this perception that the IPv6 allocation policies will not be fair, is strongly held and will not be shifted by any amount of polite explanation of how the IPv6 policies differ from the IPv4 policies that led to the imbalances. Top of this list to my mind is proposition 100 (prop-100), a policy proposal in the APNIC RIR that requests the reservation of a /16 block of IPv6 addresses for India and similar reservations for all other countries in the region, from which any allocations to an LIR from that country will be provisioned.

The explicit reason given for prop-100 is:

"The main objective of this proposal is to ensure that all economies (and the different present and future organizations in those economies) can ensure they will get a suitable share of the IPv6 address space, in one or more large contiguous blocks, whether they need it now or at a later date."

It might look like the focus here is on contiguous blocks, but discussions with the author have made it quite clear that it isn't about this, the real concern is:

"planned usage of the IPv6 address space with assurance that every economy will have some address space reserved for it whether it needs now or in the future."

No amount of reasoned explanation that the IPv6 allocation policies will not lead to scarcity that disadvantages some economies, is affecting the views of the authors, nor is any amount of simple mathematics showing just how vast the IPv6 space is and just how small a percentage has been allocated so far. Nor is any amount of rational argument ever going to work so long as the accidental historical imbalances of IPv4 are ignored. Note, I didn't say "corrected", I said "ignored" as this is about perception and trust more than anything else.

So here we are, approaching the worst possible position where our well considered IPv6 allocation policies are untrusted and undermined because of the complete disregard for the historical imbalances of IPv4, when that has nothing to do with IPv6. Rather the IPv6 taking away the problems of those imbalances, those imbalances are now close to seriously disrupting IPv6.

If this proposal for contiguous national blocks sounds familiar then that's because it is telephone numbering all over again. The ITU-T, that dying anachronism, is struggling to reinvent itself in the Internet age and has latched onto IPv6 allocations as a lifeline. The ITU-T IPv6 Group has stated aims almost identical to that of prop-100:

"To draft a global policy proposal for the reservation of a large IPv6 block, taking into consideration the future needs of developing countries ..."

"To further study possible methodologies and related implementation mechanisms to ensure 'equitable access' to IPv6 resource by countries."

The ITU has been touting this nonsense around developing countries and gaining traction using, yes you guessed it, the historical IPv4 imbalances as evidence that they need to step in to ensure fairness in IPv6.

It should be clear by now that the accidental historical imbalances of IPv4 cannot continue to be ignored as this is actually making the situation worse. A very public global policy process needs to begin to tackle these imbalances. In particular, since the biggest issues are with pre-RIR allocations made directly by IANA, it needs to be the Address Supporting Organisation (ASO) of ICANN that initiates this policy process. Those companies that hold large allocations, such as the /8s out there, should be required to demonstrate need as determined by an RIR policy and receive an appropriate number of addresses for that need.

The question I most often get asked is how do we bring the address holders to the table since they are under no obligation to do so? My answer has been the same for years — if they don't follow this policy process then they don't get RPKI and they get shut out of the global routing tables.

I've heard it said that this won't work because RPKI will never be that authoritative, but I'm convinced the push to secure the Internet will make it authoritative fairly quickly. The other argument I've heard against this solution is that RIRs should not be regulators and deny RPKI for policy infringements. Well, if the RIRs don't regulate then either governments or their proxy of the ITU-T will and that is going to be far more damaging to the Internet than the bruises caused by the RIRs stepping up and taking responsibility.

Even if this is not the solution, something still has to be done. This is no longer an historical issue, this is now a struggle for the future that IPv6 represents.

Written by Jay Daley, Chief Executive of .nz Registry Services

Read full story: External Source

Companies must understand that it's sometimes necessary to look for expertise outside of their own organization.

That is where Professional Services come in. Businesses can use a specialty firm with specific expertise in lieu of a single consulting firm (or single person). Companies can also use a firm that will bring in multiple resources with the needed expertise when necessary. For instance, would you go to a general practitioner if you needed knee surgery? Most likely not — you would go see a specialist.

Companies who leverage Professional Services teams are typically able to solve challenges sooner, and at a lower cost, than generalists who have to spend more time and money on research.

For example, the Neustar Professional Services team has great expertise of the DDI (DNS, DHCP and IPAM) and web application and performance spaces:

• DNS performance and reliability
• DNS Security (DDOS and Cache Poisoning/DNSSEC)
• Differences in public and private DNS
• DHCP and IPAM in the private network
• DNS as a core protocol comingles with other technologies, such as DHCP, IPv6, IPAM and VoIP
• Web applications, architectures and protocols
• Web Security

Recently, Neustar Professional Services were called in to help provide Moffat County School District in Colorado with some additional expertise in this area. While, initial discussions were related to Neustar's UltraDDI service, it was soon determined that the product would not solve the specific network performance issues that they were experiencing. From there, Moffat turned to the Professional Services team to help investigate the issues by having them conduct a network assessment.

Often times it is difficult for organizations to understand the value of an assessment; here are some key areas why it's imperative:

• Familiarizes the Professional Services team with the customer environment in the quickest, most economical way possible
• Provides a holistic view of the entire network ensuring nothing is overlooked by the Professional Services team
• Leveraging the Professional Services team's knowledge, possible issues can be identified across the board
• Systematic approach to assessments and troubleshooting
• Customer is provided with a plan for remediation with flexibility (or priorities) in resolution
• Customer gets to see what the end will look like, with a plan to get there
• Customer gets documentation of its infrastructure, which is often times lacking

In this case, the network assessment we conducted not only identified (with root cause) the issues Moffat was experiencing, but also remediated as part of assessment, ultimately improving productivity of all users across the network. Additionally, Moffat found that the cost of degradation issues in time lost, network troubleshooting and other vendors far outweighed the cost of the assessment.

Bringing in the right expertise proved beneficial, to ensure the network stayed in optimal operation. So much so, Moffat requested ongoing strategic support, ensuring the network does not slip back to a point where Moffat begins losing significant productivity again.

Today, with just a few hours a month of consulting time, Moffat knows that they always have access to the necessary level of expertise directly related to its unique tech requirements, services and network operations.

Additional expertise is just one area that Professional Services can help with. Our next post will focus on maximizing service ROI through Professional Services speed to deployment and flexibility — so stay tuned!

Written by James Willett, VP of Professional Services and Sales Engineering at Neustar

Written by James Willett, VP of Professional Services and Sales Engineering at Neustar

Every address prefix that is reachable on the Internet is listed in the routing system, and as the Internet grows so does the number of routes.

There have been a number of efforts to undertake long term measurement of the routing environment, and the RIRs, notably the RIPE NCC and APNIC, have been performing regular measurement of the routing system for many years now.

The figure below shows a plot of the number of entries seen in the routing system every hour since the start of 2011. The particular viewpoint here is taken from APNIC, using a router located in Australia, but much the same picture is available anywhere on the Internet, as the entire objective of the routing system is to broadcast a consistent picture of reachability to all points on the Internet.

So lets look at what we can see in this figure. This is a classic "up and to the right" Internet curve. But it's not quite the curves we've been seeing for many years. In the Internet we've grown used to curves that are strong "J curves." When something is growing very quickly, such as when a metric doubles every year, then this explosive growth generates a curve that grows upwards sharply to the right. In systems that are growing exponentially the majority of the growth happens in the most recent period.

The routing system has grown at exponential rates, and from time to time we have been very concerned about the rate of growth of routing, but these periods of explosive growth have not happened for some time. We saw exponential growth in the routing system from 1997 to 2001, over the time of the first so-called "Internet boom". And it occurred a second time from 2004 to 2007, which corresponded to the transformation of the Internet with the twin pressures of expansion of the Internet into the massively developing Asian economies and the explosive growth of the mobile Internet sector with the uptake of iPhones, Android devices and similar. However, the financial crisis of 2008 saw this second phase of exponential growth come to a stop, and these days the growth of the Internet, and the Internet's routing table in particular, is along a slower and steadier trajectory.

For the first four months of 2011 the routing table has been growing at a steady rate of some 5,000 new routing entries each month. But then at the end of April of this year something changed. And what changed was that in the Asia Pacific region, APNIC, the RIR serving that region, effectively exhausted its stocks of available IPv4 addresses. The impact of this on the regional Internet was immediate, if the routing table is a good indicator.

However, the reaction to exhaustion was not an immediate upward spike in the number of routing table entries, as some folk have been predicting, but the opposite, in that the rate of growth in the routing system has slowed since then. In the ensuing 5 months the routing system has grown by a little over 2,000 new entries each month. But is this all due to the exhaustion of IPv4 addresses in the Asia Pacific region? Perhaps not. In these months we have witnessed round two of a major financial recession in many parts of the world, and the economic uncertainty has disrupted many plans for deployment of new products and services on the Internet.

The continued sluggish rate of routing growth in the Internet in the past few months may have as much to do with the adverse economic conditions in many parts of the world as it has to do with the change of the IPv4 Internet growth model in the Asia Pacific region.

A suite of tools to look at the routing system, both from a large scale perspective and in very minute detail, can be found at the RIPE NCC Routing Information System (RIS): http://ris.ripe.net

This article and other related topics can also be found on RIPE Labs.

Written by Mirjam Kuehne

IP address space is a finite public resource. Traditionally, folk who need IP addresses fill in a simple form documenting how current addresses are used and explaining how the requested IPs will be used. It's a simple process that takes a few minutes to complete, and even less time to process. Having been a Hostmaster at one of the RIRs, I have some experience in this area. Back in the very early days of the IANA, requirements were even more simple and many organisations got lots more IPs than they could actually use due to the classfull nature of addressing at the time. These early Allocations are often called "legacy space", as they were made prior to the formation of the RIR system as we know it.

There seems to be a vocal minority clamoring for the removal of this needs requirement in some of the RIR regions, some of whom are undoubtedly hoping to profit from the sale of IP addresses, while others seem to be guided by free-market philosophies. Unfortunately, neither motivation seems to advance the public interest in IP address distribution, despite their rhetoric to the contrary.

If organisations were allowed to obtain IP blocks from the RIRs (or from other companies) without first demonstrating that they needed them, the Internet would have run out of IPv4 long ago. This would obviously not have been in the public interest, as Internet growth would have stagnated.

Recently, we have seen the Internetgovernanceproject blogging about this issue and they talk about the needs requirement as a "barrier to trade". While this may be the case, a much bigger and more damaging barrier to would be erected if folk were allowed to flog their IP resources (legacy or not) to the highest bidder without any regard for Internet resource stewardship. In the theoretical case that IGP raises, where Asian companies looking for more addresses than they think they can get from their RIR are eyeing legacy IP blocks. IGP seems to think that such organisation should be able to buy legacy blocks without demonstrating that they actually need these resources. In other words, the companies who have the most cash "wins", which is not a philosophy normally associated with public interest outcomes. Many in the RIR policy communities are concerned that this will lead to hoarding and speculation, driving up the cost of doing business for all while enriching the few.

The current RIR system works incredibly well. It is the most respected part of the ICANN system in terms of openness, transparency and true bottom uppity-ness. Normally, IGP decries the heavy influence in ICANN processes by monied interests, but in this case, they seem to be cheerleading for the monied interests due to some deep seated Ayn Rand-ian laissez faire-ness. Inexplicable really, but I digress.

Now that we are faced with the impending run out of IPv4, several RIR policy communities are placing greater restrictions on allocation and assignments as a natural reaction the coming shortage. For example, in the AfriNIC region, consensus was reached at the last AfriNIC meeting on a "Soft Landing" policy, which is now in Last Call. Amongst other things, this policy specifically states that resources allocated to the AfriNIC region are meant to be used in the region, thus precluding inter-region transfers.

Currently the APNIC community is in the process of restoring the justification of need for transfers, which was relaxed just last year.

Asking folk why they need a certain number of addresses has worked to prevent hoarding and speculation of Internet resources for many years. It is even more important now that we are running low on the supply side of IPv4. RIR policies are set by groups of people working together to reach consensus positions. Asking that we allow the "Invisible Hand" to determine policies going forward is not responsible stewardship, it's just crass commercialism.

Written by McTim, Co-Chair of the African Network Information Center Policy Development WG