<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:admin="http://webns.net/mvcb/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		
		<title>CircleID: IPv6</title>
		<link>http://www.circleid.com/topics/</link>
		<description>Latest IPv6 related postings on CircleID</description>
		
		<dc:language>en</dc:language>
		<dc:rights>Copyright 2013, unless where otherwise noted.</dc:rights>
		<dc:date>2013-05-23T16:25:00-08:00</dc:date>
		<image>
			<title>CircleID</title>
			<width>130</width>
			<height>45</height>
			<url>http://www.circleid.com/images/logo_rss.gif</url>
			<link>http://www.circleid.com/</link>
		</image>
		
		<item>
			<title>Removing Need at RIPE</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130523_removing_need_at_ripe/</guid>
			<link>http://www.circleid.com/posts/20130523_removing_need_at_ripe/</link>
			<description><![CDATA[<p>I recently attended <a title="RIPE 66" href="https://ripe66.ripe.net" target="_blank">RIPE 66</a> where Tore Anderson <a title="Video of Tore Anderson's presentation" href="https://ripe66.ripe.net/archives/video/1177/" target="_blank">presented</a> his suggested policy change <a title="RIPE Policy Proposal 2013-03 - No Need" href="https://www.ripe.net/ripe/policies/proposals/2013-03" target="_blank">2013-03</a>, "No Need &ndash; Post-Depletion Reality Adjustment and Cleanup." In his presentation, Tore suggested that this policy proposal was primarily aimed at removing the requirement to complete the form(s) used to document need. There was a significant amount of discussion around bureaucracy, convenience, and "liking" (or not) the process of demonstrating need. Laziness has never been a compelling argument for me and this is no exception. The fact is that any responsible network manager must keep track of IP address utilization in order to design and operate their network, regardless of RIR policy. Filling this existing information into a form really does not constitute a major hurdle to network or business operations. So setting aside the laziness decree, let's move on to the rationale presented.
</p>
<p>
<strong>IPv4 is Dead?</strong>
</p>
<p>
Tore pointed to section 3.0.3 of <a title="IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" href="https://www.ripe.net/ripe/docs/ripe-582" target="_blank">RIPE-582</a>, the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region:"
</p>
<blockquote><p><em>Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks. To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need, and stockpiling must be prevented.</em></p></blockquote>
<p>
According to Mr. Anderson, this is "something that has served us well for quite a long time" but now that IANA and RIPE have essentially exhausted their supply of free/unallocated IPv4 addresses, is obsolete. From the summary of the proposal:
</p>
<blockquote><p><em>Following the depletion of the IANA free pool on the 3rd of February 2011, and the subsequent depletion of the RIPE NCC free pool on the 14th of September 2012, the "lifetime of the public IPv4 address space" in the RIPE NCC region has reached zero, making the stated goal unattainable and therefore obsolete.</em></p></blockquote>
<p>
This argument appears to be the result of what I would consider a very narrow and unjustified interpretation of the goal of conservation. Tore seems to interpret "maximise the lifetime of the public IPv4 address space" to mean "maximise the duration that public IPv4 space remains available at the RIPE NCC." Under this translation, it is possible to believe that a paradigm shift has occurred which calls for a drastic reassessment of the goal of conservation. If, however, we take the goal as written in RIPE NCC policy as a carefully crafted statement meant to convey it's meaning directly and without interpretation or translation; a different conclusion seems obvious. While Tore is correct in his observation that IANA and RIPE NCC (and APNIC and soon ARIN) have all but depleted their reserves of "free" IPv4 addresses, that does not mean that the lifetime of the public IPv4 address space has come to an end. While I would love for everyone to enable IPv6 and turn off IPv4 tomorrow (or better yet, today), that is simply not going to happen all at once. The migration to IPv6 is underway and gaining momentum but there are many legacy devices and legacy networks which will require the use of IPv4 to continue for years to come. Understanding that the useful life of IPv4 is far from over (raise your hand if you have used IPv4 for a critical communication in the past 24 hours) makes it quite easy to see that we still have a need to "maximise the lifetime of the public IPv4 address space."
</p>
<p>
In fact, the IANA and RIR free pools have essentially been a buffer protecting us from those who would seek to abuse the public IPv4 address space. As long as there was a reserve of IPv4 addresses, perturbations caused by bad actors could be absorbed to a large extent by doling out "new" addresses into the system under the care of more responsible folks. Now that almost all of the public IPv4 address space has moved from RIR pools into the "wild," there is arguably a much greater need to practice conservation. The loss of the RIR free pool buffer does not mark the end of "the lifetime of the public IPv4 address space" as Tore suggests but rather marks our entry into a new phase of that lifetime where stockpiling and hoarding have become even more dangerous.
</p>
<p>
<strong>A Paradox</strong>
</p>
<p>
Tore made two other arguments in his presentation, and I have trouble rectifying the paradox created by believing both of them at once. The two arguments are not new, I have heard them both many times before in similar debates, and they invariably go something like this:
</p>
<ol><li>Because IPv4 addresses are now a scarce resource, people will only use what they need, so we don't need to require them to demonstrate need in policy.</li>
<li>Because IPv4 addresses are now a scarce resource, people will lie and cheat to get more addresses than they can justify, so we should remove the incentives for them to lie and cheat.</li></ol>
<p>
I want to look at these arguments first individually, and then examine the paradox they create when combined.
</p>
<p>
Early in his presentation, Tore said something to the effect of <em>because the LIR can not return to RIPE NCC for more addresses, they would never give a customer more addresses than they need</em> and that <em>the folks involved will find ways of assessing this need independently</em>. OK, if this is true then why not make it easy for everyone involved by standardizing the information and process required to demonstrate need? Oh, right, we already have that. Removing this standardization opens the door for abuse, large and small. The most obvious example is a wealthy spammer paying an ISP for more addresses then they can technically justify, in order to carry out their illegal bulk mail operation. The reverse is true as well, with no standard for efficient utilization to point to, it is more possible for an ISP to withhold addresses from a down stream customer (perhaps a competitor in some service) who actually does have justifiable technical need for them.
</p>
<p>
The second argument is more ridiculous. I truly don't understand how anyone can be convinced by the "people are breaking the rules so removing the rules solves the problem" argument. While I am in favor of removing many of the rules, laws, and regulations that I am currently aware of; I favor removing them not because people break them but because they are unjust rules which provide the wrong incentives to society. If you have a legitimate problem with people stealing bread, for example, then making the theft of bread legal does not in any way solve your problem. While it is possible that bread thieves may be less likely to lie about stealing the bread (since they no longer fear legal repercussions) and it is certainly true that they would no longer be breaking the law, law-breaking and lying are not the problem. The theft of bread is the problem. Legalizing bread theft has only one possible outcome: Encouraging more people to steal bread. So the fact that bad actors currently have an incentive to lie and cheat to get more addresses in no way convinces me that making their bad behavior "legal" would solve the problem. If anything it is likely to exacerbate the issue by essentially condoning the bad behavior, causing others to obtain more addresses then they can technically justify.
</p>
<p>
Of course it get's even worse when you try to hold up both of these arguments as true at once. If people can be counted on to take only what they need, why are they lying and cheating to get more? If people are willing to lie and cheat to get around the needs based rules, why would they abide by needs when the rules are removed? I just can't make these two statements add up in a way that makes any sense.
</p>
<p>
<strong> Conclusions</strong>
</p>
<p>
Since we still need IPv4 to continue working for some time, maximizing the lifetime of the public IPv4 address space through conservation is still a noble and necessary goal of the RIRs, perhaps more important than ever. Filling out some paperwork (with information you already have at hand) is a very low burden for maintaining this goal. At this time, there is no convincing rationale for removing this core tenant of the Internet model which has served us so well.
</p><p><em>Written by <a href="http://www.circleid.com/members/6756/">Chris Grundemann</a>, Network Architect, Author, and Speaker</em></p>]]></description>
			<dc:date>2013-05-23T16:25:00-08:00</dc:date>
			<category>internet</category><category>internet_governance</category><category>internet_protocol</category><category>ip_addressing</category><category>ipv6</category><category>policy_regulation</category><category>regional_registries</category>
		</item>
		
		<item>
			<title>IPv6: Penny Wise and Pound Foolish</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130521_ipv6_penny_wise_and_pound_foolish/</guid>
			<link>http://www.circleid.com/posts/20130521_ipv6_penny_wise_and_pound_foolish/</link>
			<description><![CDATA[<p>The theory put forward by the IETF was simple enough&#8230; while there were still enough IPv4 addresses, use transition technologies to migrate to dual stack and then wean IPv4 off over time. All nice and tidy. The way engineers, myself included, liked it. However those controlling the purse strings had a different idea. There was, don't spend a cent on protocol infrastructure improvement until the absolute last minute &#8212; there's no ROI in IPv6 for shareholders. Getting in front of the problem at the expense of more marketable infrastructure upgrades was career suicide.
</p>
<blockquote><p><span style="font-size:85%;line-height:1.3em;color:#666666;margin:20px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7391.gif" border="0" width="600" height="355" style="display:block;margin-bottom:10px;" />Graph from my 2008 sales presentation&#8230; sound but not convincing</span></p></blockquote>
<p>
By considering this a technical issue rather than a business one, it was easier to delay the inevitable but this had unintended consequences. The fewer IPv4 addresses there were, the fewer technical options there were to address the problem. This coupled with a simpler user experience/expense led us to today and the emergence of the so called Carrier Grade NAT (CGN).
</p>
<p>
<em>[For a thorough overview of the various flavors of CGN and the choices in front of us, see Phil's post, <a href="http://www.gogo6.com/profiles/blogs/the-hatred-of-cgn" target="_blank">The Hatred of CGN</a> on gogoNET. Don't let the title fool you.]</em>
</p>
<p>
By deploying CGNs, ISPs are sharing single IPv4 addresses with more and more households and this isn't good. Why? Because two levels of NAT break things and that leads to unhappy customers. Case in point, British Telecom. BT recently put their retail Option 1 broadband customers (lowest tier) behind CGNs and they are now <a href="http://www.pcpro.co.uk/news/broadband/381646/customers-fume-as-bt-introduces-ip-sharing" target="_blank">feeling the pain</a> for a variety of brokenness but mostly because Xbox Live stopped working.
</p>
<p>
Asian fixed line operators were the first to deploy CGN as a Band-Aid to cover over the problem until the rest of the world standardized on a transition solution. Japan and South Korea notwithstanding I suspect the reasons we haven't heard the same outcry earlier are cultural and the result of lower expectations/SLAs. However in a mature broadband market like the UK where customers are vocal and expectations/SLAs are high you are going to hear about it. And since there isn't a steady stream of new customers to offset the churn, this can turn into a PR nightmare resulting in the loss of high acquisition-cost customers.
</p>
<p>
Expect to see more of these reports as more European and North American ISPs follow suit. The irony here is it was the British who coined the term, "Penny wise and pound foolish".
</p>
<p>
Below are a selection of reader comments from the article, "<a href="http://www.thinkbroadband.com/news/5818-bt-retail-in-carrier-grade-nat-pilot.html" target="_blank">BT Retail in Carrier Grade NAT Pilot</a>&#8221;.
</p>
<blockquote><p>Posted by zyborg47 13 days ago:
<br />
<em>This IPv4 should have been sorted out a few years back if the larger ISPs have got off their backside and started to change to IPv6 then we would not have this problem and IPv6 routers/modems would not have stayed at such a high price for so long. The problem is now, we the paying public, will suffer because of this, or the poor sods on Bt option one anyway.</em>
</p>
<p>
Posted by Kushan 13 days ago:
<br />
<em>If you start trialing CGNAT before you trial IPv6, you're doing something wrong.</em>
</p>
<p>
Posted by driz 13 days ago
<br />
<em>Is CGNAT even technically an 'internet connection' anymore?</em></p></blockquote><p><em>Written by <a href="http://www.circleid.com/members/6754/">Bruce Sinclair</a>, CEO, gogo6</em></p>]]></description>
			<dc:date>2013-05-21T13:24:00-08:00</dc:date>
			<category>internet</category><category>ip_addressing</category><category>ipv6</category>
		</item>
		
		<item>
			<title>A Royal Opinion on Carrier Grade NATs</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130519_a_royal_opinion_on_carrier_grade_nats/</guid>
			<link>http://www.circleid.com/posts/20130519_a_royal_opinion_on_carrier_grade_nats/</link>
			<description><![CDATA[<p>There are still a number of countries who have Queen Elizabeth as their titular head of state. My country, Australia, is one of those countries. It's difficult to understand what exactly her role is these days in the context of Australian governmental matters, and I suspect even in the United Kingdom many folk share my constitutional uncertainty. Nevertheless, it's all great theatre and rich pageantry, with great press coverage thrown in as well. In the United Kingdom every year the Queen reads a speech prepared by the government of the day, which details the legislative measures that are being proposed by the government for the coming year. Earlier this month the Queen's speech included the following statement in her speech:
</p>
<blockquote><p><em>"In relation to the problem of matching Internet Protocol addresses, my government will bring forward proposals to enable the protection of the public and the investigation of crime in Cyberspace."</em> [on <a href="http://www.youtube.com/watch?v=UWwK3z3GvzY&amp;feature=youtube_gdata" target="_blank">Youtube</a>, 5:45]</p></blockquote>
<p>
As the Guardian <a href="http://www.guardian.co.uk/politics/2013/may/08/queens-speech-snoopers-charter" target="_blank">pointed out</a>:
</p>
<blockquote><p><em>The text of the Queen's speech gives the go-ahead to legislation, if needed, to deal with the limited technical problem of there being many more devices including phones and tablets in use than the number of internet protocol (IP) addresses that allow the police to identify who sent an email or made a Skype call at a given time.</em></p></blockquote>
<p>
What's the problem here?
</p>
<p>
The perspective of various law enforcement agencies is that the Internet is seen as a space that has been systematically abused, and too many folk are felling prey to various forms of deceit and fraud. If you add to that the undercurrent of concern that the Internet contains a wide range of vulnerabilities from the perspective of what we could generally term "cybersecurity," then it's not surprising to see law enforcement agencies now turning to legislation to assist them in undertaking their role. And part of their desired toolset in undertaking investigations and gathering intelligence is access to records from the public communications networks of exactly who is talking to whom. Such measures are used in many countries, falling under the generic title of "data retention."
</p>
<p>
In the world of telephony the term "data retention" was used to refer to the capture and storage of call detail records. Such records typically contain the telephone numbers used, time and duration of the call, and may also include ancillary information including location and subscriber details. Obviously such detailed use data is highly susceptible to data mining, and such call records can be used to identify an individual's associates and can be readily used to identify members of a group. Obviously, such data has been of enormous interest to various forms of law enforcement and security agencies over the years, even without the call conversation logs from direct wire tapping of targeted individuals. The regulatory measures designed to protect access to these records vary from country to country, but access is typically made available to agencies on the grounds of national security, law enforcement or even enforcement of taxation conformance.
</p>
<p>
So if that's what happens in telephony, what happens on the Internet?
</p>
<p>
Here the story is a continually evolving one, and these days the issues of IPv4 address exhaustion and IPv6 are starting to be very important topics in this area. To see why it is probably worth a looking at how this used to happen and what technical changes have prompted changes to the requirements related to data retention for Internet Service Providers (ISPs).
</p>
<p>
The original model of the analogous data records for the Internet was the registry of allocated addresses maintained by Internet Network Information Centre, or Internic. This registry did not record any form of packet activity, but was the reference data that shows which entity had been assigned which IP address. So if you wanted to know what entity was using a particular IP address, then you could use a very simple "whois" query tool to interrogate this database:
</p>
<blockquote><p><tt>$ whois -h whois.apnic.net 202.12.29.211
</p>
<p>
inetnum: 202.12.28.0 - 202.12.29.255
<br />
netname: APNIC-AP
<br />
descr: Asia Pacific Network Information Centre
<br />
descr: Regional Internet Registry for the Asia-Pacific Region
<br />
descr: 6 Cordelia Street
<br />
descr: PO Box 3646
<br />
descr: South Brisbane, QLD 4101
<br />
descr: Australia</tt></p></blockquote>
<p>
However, this model of the registry making direct allocations to end user entities stopped in the early 1990's with the advent of the ISP. The early models of ISP service were commonly based on the dial-up model, where a customer would be assigned an IP address for the duration of their call, and the IP address would return to the free pool for subsequent reassignment at the end of the call. The new registry model was that the identity of the service provider was described in the public address registry, and the assignment of individual addresses to each of their dial-up customers was information that was private to the service provider. Now if you wanted to know what entity was using a particular IP address you also had to know the time of day as well, and while a "whois" query could point you in the direction of whom to ask, you now had to ask the ISP for access to their Access, Authentication and Accounting (AAA) records, typically the radius log entries, in order to establish who was using a particular IP address at a given time. Invariably, this provider data is private data, and agencies wanting access to this data had to obtain appropriate authorization or warrants under the prevailing regulatory regime.
</p>
<p>
This model of traceback has been blurred by the deployment of edge NATs, where a single external IP address is shared across multiple local systems serviced by the NAT. This exercise can therefore trace back to the NAT device, but no further. So with access to this data you can get to understand the interactions on the network at a level of granularity of customer end points, but not at a level of individual devices or users.
</p>
<p>
We've used this model of Internet address tracking across the wave of cable and DSL deployments. The end customer presents their credentials to the service provider, and is provided with an IPv4 address as part of the session initiation sequence. The time of this transaction, the identity of the customer and the IP address is logged, and when the session is terminated the address is pulled back into the address pool and the release of the address is logged. The implication is that as long as the traceback can start with a query that includes an IP address and a time of day, its highly likely that the end user can be identified from this information.
</p>
<p>
But, as the Guardian's commentary points out, this is all changing again. IPv4 address exhaustion is prompting some of the large retail service providers to enter the Carrier Grade NAT space, and join what has already become a well established practice in the mobile data service world. The same week of the Queen's speech, BT announced a trial of Carrier Grade NAT use in its basic IP service.
</p>
<p>
At the heart of the Carrier Grade NAT approach is the concept of sharing a public IP address across multiple customers at the same time. An inevitable casualty of this approach is the concept of traceback in the internet and the associated matter of record keeping rules. It is no longer adequate to front up with an IP address and a time of day. That is just not enough information to uniquely distinguish one customer's use of the network from another's. But what is required is now going to be dependant on the particular NAT technology that is being used by the ISP. If the CGN is a simple port-multiplexing NAT then you need the external IP address and the port number. When combined with the CGN-generated records of NAT's bindings of internal to external address, this can map you back to the internal customer's IP address, and using the ISP's address allocations records, this will lead to identification of the customer.
</p>
<p>
So traceback is still possible in this context. In a story titled "Individuals can be identified despite IP address sharing, BT says" the newsletter out-law.com (produced by the law firm Pinsent Masons) <a href="http://www.out-law.com/en/articles/2013/may/individuals-can-be-identified-despite-ip-address-sharing-bt-says/" target="_blank">reports</a>:
</p>
<blockquote><p>BT told Out-Law.com that its CGNAT technology would not prevent the correct perpetrators of illegal online activity from being identified.
</p>
<p>
"The technology does still allow individual customers to be identified if they are sharing the same IP address, as long as the port the customer is using is also known," a BT spokesperson said in a statement. "Although the IP address is shared, the combination of IP address and port will always be unique and as such these two pieces of information, along with the time of the activity can uniquely identify traffic back to a broadband line. [...] If we subsequently receive a request to identify someone who is using IP address x, and port number y, and time z we can then determine who this is from the logs," the spokesperson said. [...] "If only the IP address and timestamp are provided for a CGNAT customer then we are unable to identify the activity back to a broadband line," they added.</p></blockquote>
<p>
But port-multiplexing NATs are still relatively inefficient in terms of address utilization. A more efficient form of NAT multiplexing uses the complete 5-tuple of the connection signature, so that the NAT's binding table uses a lookup key of the protocol field and the source and destination addresses and port values. This allows the NAT to achieve far higher address sharing ratios, allowing a single external IP address to be shared across a pool of up to thousands of customers.
</p>
<p>
So what data needs to be collected by the ISP to allow for traceback in this sort of CGN environment? In this case the ISP needs to collect the complete 5-tuple of the external view of the connection, plus the start and stop times at a level of granularity to the millisecond or finer, together with the end-user identification codes. Such a session state log entry takes typically around 512 bytes as a stored data unit.
</p>
<p>
How many individual CGN bindings, or session states, does each user generate? One report I've seen points to an average of some 33,000 connections per end customer each day. If that's the case then the implication is that each customer will generate some 17Mbytes of log information every day. For a very large service provider, with, say, some 25 million customers, that equates to a daily log file of 425Tbytes. If these CGN records were produced at an unrealistically uniform rate per day, that's a constant log data flow of some 40Gbps. At a more realistic estimate of the busy period peaking at 10 times the average, the peak log data flow rate is some 400Gbps.
</p>
<p>
That's the daily load, but what about longer term data retention storage demands? The critical questions here is the prevailing data retention period. In some regimes it's 2 years, while in other regimes it's up to 7 years. Continuing with our example, holding this volume of data for 7 years of data will consume 1,085,875 Terrabytes, or 1.0 Exabytes to use the language of excessively large numbers. And that's even before you contemplate backup copies of the data! And yes, that's before you contemplate an Internet that becomes even more pervasive and therefore of course even larger and used more intensively in the coming years.
</p>
<p>
The questions such a data set can answer also requires a very precisely defined question. It's no longer an option to ask "who used this IP address on this date?" Or even "who used this IP address and this port address in this hour?" A traceback that can penetrate the CGN-generated address overuse fog requires the question to include both the source and destination IP addresses and port numbers, the transport protocol, and the precise time of day, measured in milliseconds. This last requirement, of precise coordinated time records, is a new addition to the problem, as traceback now requires that the incident being tracked be identified in time according to a highly accurate time source running in a known timezone, so that a precise match can be found in the ISP's data logs. It's unclear what it will cost to collect and maintain such massive data sets, but its by no means a low cost incidental activity for any ISP.
</p>
<p>
No wonder the UK is now contemplating legislation to enforce such record keeping requirements in the light of the forthcoming CGN deployments in large scale service provider networks in that part of the world. Without such a regulatory impost its unlikely that any service provider would, of their own volition, embark on such a massive data collection and long term storage exercise. One comment I've heard is that in some regimes it may well be cheaper not to collect this information and opt to pay the statutory fine instead &#8212; it could well be cheaper!
</p>
<p>
This is starting to look messy. The impact of CGNs on an already massive system is serious, in that it alters the granularity of rudimentary data logging from the level of a connection to the Internet to the need to log each and every individual component conversation that every consumer has. Not only is it every service you use and every site you visit, but its even at the level of every image, every ad you download, everything. Because when we start sharing addresses we now can only distinguish one customer from another at the level of these individual basic transactions. Its starting to look complicated and certainly very messy.
</p>
<p>
But, in theory in any case, we don't necessarily have to be in such a difficult place for the next decade and beyond.
</p>
<p>
The hopeful message is that if we ever complete the transitional leap over to an all-IPv6 Internet the data retention capability reverts back to a far simpler model that bears a strong similarity to the very first model of IP address registration. The lack of scarcity pressure in IPv6 addresses allows the ISP to statically assign a unique site prefix to each and every customer, so that the service providers data records can revert to a simple listing of customer identities and the assigned IPv6 prefix. In such an environment the cyber-intelligence community would find that their role could be undertaken with a lot less complexity, and the ISPs may well find that regulatory compliance, in this aspect at least, would be a lot easier and a whole lot cheaper!
</p><p><em>Written by <a href="http://www.circleid.com/members/602/">Geoff Huston</a>, Author & Chief Scientist at APNIC</em></p>]]></description>
			<dc:date>2013-05-19T16:13:00-08:00</dc:date>
			<category>internet</category><category>access_providers</category><category>cybercrime</category><category>internet_governance</category><category>ip_addressing</category><category>ipv6</category><category>policy_regulation</category>
		</item>
		
		<item>
			<title>SIP Network Operators Conference (SIPNOC) Starts Tonight in Herndon, Virginia</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130422_sip_network_operators_conference_sipnoc_tonight_herndon_virginia/</guid>
			<link>http://www.circleid.com/posts/20130422_sip_network_operators_conference_sipnoc_tonight_herndon_virginia/</link>
			<description><![CDATA[<p>Tonight begins the third annual <a href="http://www.sipnoc.org">SIP Network Operators Conference (SIPNOC)</a> in Herndon, Virginia, where technical and operations staff from service providers around the world with gather to share information and learn about the latest trends in IP communications services &#8212; and specifically those based on the Session Initiation Protocol (SIP). Produced by <a href="http://www.sipforum.org/">the nonprofit SIP Forum</a>, SIPNOC is an educational event sharing best practices, deployment information and technology updates. Attendees range from many traditional telecom carriers to newer VoIP-focused service providers and application developers.
</p>
<p>
The <a href="http://www.sipforum.org/content/view/378/278/">SIPNOC 2013 agenda</a> includes talks on:
</p>
<ul><li>VoIP and communications security</li>
<li>Business strategies for service providers</li>
<li>Regulatory and policy issues</li>
<li>Multiple sessions about WebRTC and how that will change IP communications</li>
<li>IPv6 and VoIP</li>
<li>HD audio</li>
<li>Standards relating to VoIP and SIP</li></ul>
<p>
The main sessions begin tomorrow with <a href="http://www.sipforum.org/content/view/411/171/">a keynote presentation from FCC CTO Henning Schulzrinne</a> where I expect he will talk about some of the challenges the FCC has identified as they continue to push the industry to move away from the traditional PSTN to the world of IP communications.
</p>
<p>
I've very much enjoyed the past SIPNOC conferences and will be back there again this year <a href="http://www.internetsociety.org/deploy360/blog/2013/04/speaking-at-sipnoc-next-week-about-ipv6-and-dnssec-with-voip/">leading sessions about: IPv6 and VoIP; how DNSSEC can help secure VoIP; and a couple of sessions related to VoIP security</a>. I'm very much looking forward to the discussions and connections that get made there &#8212; and if any of you are attending I look forward to meeting you there.
</p>
<p>
SIPNOC 2013 will not be livestreamed, but if you are in the DC area (or can easily get there), <a href="http://www.sipforum.org/content/view/369/270/#registration">registration is still open</a> for the event. I suspect you'll also see some of us <a href="https://twitter.com/search?q=%23sipnoc">tweeting with the hashtag #sipnoc</a>.
</p><p><em>Written by <a href="http://www.circleid.com/members/2673/">Dan York</a>, Author and Speaker on Internet technologies</em></p>]]></description>
			<dc:date>2013-04-22T16:03:00-08:00</dc:date>
			<category>internet</category><category>dnssec</category><category>ipv6</category><category>security</category><category>telecom</category><category>voip</category>
		</item>
		
		<item>
			<title>A Primer on IPv4, IPv6 and Transition</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130421_a_primer_on_ipv4_ipv6_and_transition/</guid>
			<link>http://www.circleid.com/posts/20130421_a_primer_on_ipv4_ipv6_and_transition/</link>
			<description><![CDATA[<p>There is something badly broken in today's Internet.
</p>
<p>
At first blush that may sound like a contradiction in terms, or perhaps a wild conjecture intended only to grab your attention to get you to read on. After all, the Internet is a modern day technical marvel. In just a couple of decades the Internet has not only transformed the global communications sector, but its reach has extended far further into our society, and it has fundamentally changed the way we do business, the nature of entertainment, the way we buy and sell, and even the structures of government and their engagement with citizens. In many ways the Internet has had a transformative effect on our society that is similar in scale and scope to that of the industrial revolution in the 19th century. How could it possibly be that this prodigious technology of the Internet is "badly broken?" Everything that worked yesterday is still working today isn't it? In this article I'd like to explain this situation in a little more detail and expose some cracks in the foundations of today's Internet.
</p>
<p>
You see it's all about addresses. In a communications network that supports individual communications it's essential that every reachable destination has its own unique address. For the postal network it's commonly your street address. For the traditional telephone network it's your phone number. This address is not just how other users of the network can select you, and only you, as the intended recipient of their communication. It's how the network itself can ensure that the communication is correctly delivered to the intended recipient. The Internet also uses addresses. In fact the Internet uses two sets of addresses. One set of addresses is for you and I to use. Domain names are the addresses we enter into web browsers, or what we use on the right hand side of the @ in an email address. These addresses look a lot like words in natural languages, which is what makes them so easy for we humans to use. The other set of addresses are used by the network. Every packet that is passing through the Internet has a digital field in its header that describes the network address of the packet's intended delivery address: it's "destination address." This address is a 32 bit value. A 2 bit field has four possible values, a 3 bit field has eight possible values, and by the same arithmetic a 32 bit field has 2 to the power 32, or some 4,294,967,296 unique values.
</p>
<p>
If every reachable device on the Internet needs a unique address in order to receive packets, then does that mean that we can only connect at most some 4 billion devices to the Internet? Well, in general terms, yes! And once we reach that hard limit of the address size, should we expect to encounter problems? Well, in general terms, yes!
</p>
<p>
Running out of addresses in any communications network can pose a massive problem. We have encountered this a number of times in the telephone network, and each time we've managed to add more area codes, and within each area we've added more in-area digits to telephone numbers to accommodate an ever-growing population of connected telephone handsets. Every time we've made this change to the address plan of the telephone network we needed to reprogram the network. Luckily, we didn't needed to reprogram the telephone handsets as well. We just had to re-educate telephone users to dial more digits. With care, with patience, and with enough money this on-the-fly expansion of the telephone system's address plan can be undertaken relatively smoothly. But this approach does not apply to the Internet. The address structure of the Internet is not only embedded into the devices that operate the network itself, the very same address structure is embedded in every device that is attached to the network. So if, or more correctly, when, we run out of these 32 bit addresses on the Internet we are going to be faced with the massive endeavour of not only reprogramming every part of the network, but also reprogramming every single device that is attached to the network. Given that the Internet today spans more than 2.3 billion users and a comparable number of connected devices then this sounds like a formidable and extremely expensive undertaking.
</p>
<p>
<span style="font-size:85%;color:#666666;padding:0 0 2px 7px;margin:0 0 10px 10px;border-left:1px solid #ddd;width:350px;float:right;line-height:1.3em;"><img src="http://www.circleid.com/images/uploads/7327a.gif" border="0" width="350" height="438" style="display:block;margin-bottom:15px;" /><strong>Frank Solensky's Report on Address Depletion</strong>, Proceedings of IETF 18, p. 61, Vancouver, August 1990 (<a href="http://www.ietf.org/proceedings/18.pdf">PDf</a>)</span>If running out of IP addresses is such a problem for the Internet then you'd like to hope that we could predict when the ominous event would occur, and then give ourselves plenty of lead time to dream up something clever as a response. And indeed we did predict this address depletion. Some 23 years ago, in August 1990, when the Internet was still largely a research experiment and not the foundation bedrock of the global communications enterprise we saw the first prediction of address runout. At the time Frank Solensky a participant in the Internet Engineering Task Force (IETF) extrapolated the growth of the Internet from the emerging experience of the US National Science Foundation's NSFNET, and similar experiences in related academic and research projects, and predicted that the pool of addresses would run out in some 6-10 years time.
</p>
<p>
The technical community took this message to heart, and started working on the problem in the early 1990's.
</p>
<p>
From this effort emerged a stop gap measure that while it was not a long term solution, would buy us some urgently needed extra time. At the time the Internet's use of address use was extremely inefficient. In a similar manner to a telephone address that uses an area code followed by a local number part, the Internet's IP address plan divides an IP address into a network identifier and a local host identifier. At the time we were using an address plan that used fixed boundaries between the network identification part and the host identification part. This address plan was a variant of a "one size fits all" approach, where we had three sizes of host addresses within the network: one size was just too big for most networks, one size was too small, and the only one that left was capable of spanning an Internet of just 16,382 networks. It was this set of so-called "Class B" address blocks that Frank Solensky predicated to run out in four year's time.
</p>
<p>
So what was the stop gap measure? Easy. Remove the fixed boundaries in the address plan and provide networks with only as many addresses as they needed at the time. It was hoped that this measure would give us a few more years of leeway to allow us to develop a robust long term answer to this address problem. The new address plan was deployed on the Internet in early 1993, and for a couple of years it looked like we were precisely on track, and, as shown in Figure 2, this small change in the address plan, known as Classless Inter-Domain Routing (CIDR), would buy us around 2 or 3 years of additional time to work on a longer term approach to IP address exhaustion.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327b.gif" border="0" width="644" height="372" style="display:block;margin-bottom:10px;" /><strong>Figure 2</strong> &ndash; CIDR and Address Consumption</span>
</p>
<p>
As things turned out, we were wrong in that 2 &#8212; 3 year estimate.
</p>
<p>
The reason why we were wrong was that a second stop gap measure was also developed in the early 1990's. This new technology cut right to the heart of the architecture of the Internet and removed the strict requirement that every attached device needed its own unique address on the Internet.
</p>
<p>
The approach of Network Address Translators (NATs), allowed a collection of devices to share a single public IP address. The devices that were located "behind" a NAT could not be the a target of a new communication, so that, for example, you could not host a web service if you were behind a NAT, but as long as the devices behind the NAT initiated all communications, then the NAT function became invisible, and the fact that an IP address was being shared across multiple devices was effectively irrelevant. In a model of clients and servers, then as long as you only placed the clients behind a NAT then it was possible to share a single IP address across multiple clients simultaneously.
</p>
<p>
The emerging retail ISP industry took up this NAT technology with enthusiasm. The provisioning model for retail Internet services was for a single IP address provided for each connected service, which was then shared by all the computers in the home using a NAT that was embedded into the DSL or cable modem that interfaced the home network to the service provider network. The IP address consumption levels dropped dramatically, as it was no longer a case of requiring a new IP address for each connected device, but instead requiring a single IP address for each connected service. And as the home collected more connected devices, none of these devices drew additional addresses from the IP address pool.
</p>
<p>
Instead of buying a couple of years of additional breathing space to design a long term solution to address depletion, the result of the combination of classless addressing and NATs was that it looked like we had managed to push the issue of address depletion out by some decades! The most optimistic prediction of address longevity in around 2001 predicted that IPv4 address depletion might not occur for some decades, as the address consumption rate had flattened out, as shown in Figure 3.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327c.gif" border="0" width="644" height="372" style="display:block;margin-bottom:10px;" /><strong>Figure 3</strong> &ndash; CIDR, NATs and Address Consumption</span>
</p>
<p>
Perhaps it may have been an unwarranted over-reaction, but given this reprieve the industry appeared to put this entire issue of IP address depletion in the Internet onto the top shelf of the dusty cupboard down in the basement.
</p>
<p>
As events turned out, that level of complacency about the deferral of address depletion was misguided. The next major shift in the environment was the mobile Internet revolution of the last half of the 2000's. Before then mobile devices were generally just wireless telephones. But one major provider in Japan had chosen a different path, and NTT DOCOMO launched Internet-capable handsets onto an enthusiastic domestic market in the late 1990's. Their year-on-year rapid expansion of their mobile Internet service piqued the interest of many mobile service operators in other countries. And when Apple came out with a mobile device that included a relatively large well-designed screen and good battery life, an impressive collection of applications and of course a fully functional IP protocol engine, the situation changed dramatically. The iPhone was quickly followed by a number of other vendors, and mobile operators quickly embraced the possibilities of this new market for mobile Internet services. The dramatic uptake of these services implied an equally dramatic level of new demand for IP addresses to service these mobile IP deployments, and the picture for IP address depletion one more changed. What was thought to be comfortably far into the future problem of IP address depletion once more turned into a here and now problem.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327d.gif" border="0" width="644" height="372" style="display:block;margin-bottom:10px;" /><strong>Figure 4</strong> &ndash; Address Consumption</span>
</p>
<p>
Even so, we had exceeded our most optimistic expectations and instead of getting a couple of years of additional breathing space from these stop gap measures, we had managed to pull some 15 additional years of life out of the IPv4 address pool. But with the added pressures from the deployment of IP into the world's mobile networks we were once more facing the prospect of imminent address exhaustion in IPv4. So it was time to look at that long term solution. What was it again?
</p>
<p>
During the 1990's the technical community did not stop with these short term mitigations. They took the address depletion scenario seriously, and considered what could be done to define a packet-based network architecture that could span not just billions of connected devices but hundreds of billions of devices or more. Out of this effort came version 6 of the Internet Protocol, or IPv6. The changes to IPv4 were relatively conservative, apart from one major shift. The address fields in the IP packet header were expanded from 32 bits to 128 bits. Now every time you add a single bit you double the number of available addresses. This approach added 96 bits to the IP address plan. Yes, that's 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses!
</p>
<p>
This approach to IPv6 appeared to adequately answer the need for a long term replacement protocol with enough addresses to fuel a rapacious silicon industry that can manufacture billions of processors each and every year. However, there was one residual annoying problem. The problem arises from one of the underlying features of the Internet's architecture: IP is an "end-to-end' protocol. There is no defined role for intermediaries in packet delivery. In the architecture of the Internet, what gets sent in a packet is what gets received at the other end. So if a device sends an IPv4 packet into the network, what comes out is an IPv4 packet, not an IPv6 packet. Similarly, if a device sends an IPv6 packet into the network then what comes out at the other end is still an IPv6 packet. The upshot of this is that IPv6 is not "backward compatible" with IPv4. In other words setting up a device to talk the "new" protocol means that it can only talk to other devices that also talk the same protocol. This device is completely isolated from the existing population of Internet users. What were these technology folk thinking in offering a new protocol that could not interoperate with the existing protocol?
</p>
<p>
What they were thinking was that this was an industry that was supposedly highly risk averse, and that once a long term replacement technology was available then the industry would commence broad adoption well before the crisis point of address exhaustion eventuated. The idea was that many years in advance of the predicted address exhaustion time, all new Internet devices would be configured to be capable of using both protocols, both IPv4 and IPv6. And the idea was that these bilingual devices would try to communicate using IPv6 first and fall back to IPv4 if they could not establish a connection in IPv6. The second part of the transition plan was to gradually convert the installed base of devices that only talked IPv4 and reprogram them to be bilingual in IPv6 and IPv4. Either that, or send these older IPv4-only devices to the silicon graveyard!
</p>
<p>
The transition plan was simple. The more devices on the Internet that were bilingual the more that the conversations across the network would use IPv6 in preference to IPv4. Over time IPv4 would essentially die out and support for this legacy protocol would be no longer required.
</p>
<p>
However one part of this plan was critical. We were meant to embark on this plan well before the time of address exhaustion, and, more critically, we were meant to complete this transition well before we used that last IPv4 address.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327e.gif" border="0" width="644" height="425" style="display:block;margin-bottom:15px;" /><strong>Figure 5</strong> &ndash; The IPv6 Transition Plan</span>
</p>
<p>
And to some extent this is what happened. Microsoft added IPv6 to its operating systems from the mid 2000's with the Windows Vista and Windows Server 2008 products. Apple similarly added IPv6 into their Mac OSX system from around 2006. More recently, IPv6 support has been added into many mobile devices. These days it appears that around one half of all devices connected to the Internet are bi-lingual with IPv6 and IPv4. This is indeed a monumental achievement, and much of the effort in re-programming the devices that are attached to the Internet to speak the new protocol has been achieved. So we are all ready to switch over the Internet to use IPv6, yes? Well, no, not at all.
</p>
<p>
So what's gone wrong?
</p>
<p>
Many things have not gone according to this plan, but perhaps there are two aspects of the situation that deserve highlighting here.
</p>
<p>
Firstly, despite the addition of IPv6 into the popular computer platforms, the uptake of IPv6 in the network is just not happening. While there was a general view that the initial phase of IPv6 adoption would be slow, the expectation was that the use of IPv6 would accelerate along exponentially increasing lines. But so far this has not been all that evident. There are many metrics of the adoption of IPv6 in the Internet, but one of the more relevant and useful measurements is that relating to client behaviour. When presented with a service that is available in both IPv4 and IPv6, what proportion of clients will prefer to use IPv6? Google provide one measurement point, that measures a sample of the clients who connect to Google's service. Their results are shown in Figure 6.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327f.gif" border="0" width="644" height="393" style="display:block;margin-bottom:15px;" /><strong>Figure 6</strong> &ndash; IPv6 Adoption (<a href="http://www.google.com/intl/en/ipv6/statistics/" target="_blank">Source</a>)</span>
</p>
<p>
Over the past four years Google has seen this number rise from less than 1% of users in early 2009 to a current value of 1.2%. It's one of those glass half-full or half-empty stories. Although in this case the glass is either 1% full or 99% empty! If broad scale use of IPv6 is the plan, then right now we seem to be well short of that target. On a country-by-country basis the picture is even more challenging. Only 9 countries have seen the proportion of IPv6 users rise above 1%, and the list has some surprising entries.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327g.gif" border="0" width="644" height="311" style="display:block;margin-bottom:15px;" /><strong>Figure 7</strong> &ndash; IPv6 Adoption (<a href="http://labs.apnic.net/dists/v6dcc.html" target="_blank">Source</a>)</span>
</p>
<p>
It's hard to portray this as evidence of broad based adoption of IPv6. Its perhaps more accurate to observe that a small number of network providers have been very active in deploying IPv6 to their customer base, but these providers are the minority, and most of the Internet remains locked deeply in IPv4. If a significant proportion of the end devices support IPv6 then why are these use metrics so unbelievably small? It appears that the other part of the larger network re-programming effort, that of enabling the devices sitting within the network to be IPv6-capable, has not taken place to any significant extent. It's still the case that a very large number of ISPs do not include IPv6 as part of their service offering, which means that even if an attached computer or mobile device is perfectly capable of speaking IPv6, if the access service does not support IPv6 service then there is effectively no usable way for the device to use IPv6. And even when the service provider supplies IPv6 as part of its service bundle, it may still be the case that the user's own network devices, such as the in-home NAT/modems and other consumer equipment that supports in in-home networks, such as a WiFi base station or a home router may only support IPv4. Until this equipment is replaced or upgraded, then IPv6 cannot happen. The result is as we seen in the IPv6 usage metrics today: when offered a choice between IPv4 and IPv6, some 99% of the Internet's connected devices will only use IPv4.
</p>
<p>
Secondly, we've now crossed into a space that was previously regarded as the unthinkable: we've started to run out of IPv4 addresses in the operating network. This address exhaustion started with the central address pool, managed by the Internet Assigned Numbers Authority (IANA). The IANA handed out its last address block in February 2011. IANA hands out large blocks of addresses (16,777,216 addresses per "block") to the Regional Internet Address Registries (RIRs), and in February 2011 it handed out the last round of address blocks to the RIRs. Each of the five RIRs operates independently, and each will themselves exhaust their remaining pool of IPv4 addresses in response to regional demand. APNIC, the RIR serving the Asia Pacific region, was the first to run out of addresses, and in mid April 2011 APNIC handed out its last block of "general use" IPv4 addresses. (as a side remark here, APNIC still had 17 million addresses held aside at that point, but the conditions associated with allocations from this so-called "final /8" are than each recipient can receive at most an allocation of a total of just 1,024 addresses from this block.) This represented an abrupt change in the region. In the last full year of general use address allocations, 2010, APNIC consumed some 120 million addresses. In 2012, the first full year of operation under this last /8 policy the total number of addresses handed out in the region dropped to 1 million addresses. The unmet address demand from this region appears to be growing at a rate of around 120 &#8212; 150 millions addresses per year.
</p>
<p>
The region of Europe and the Middle East has been the next to run out, and in September 2012 the RIPE NCC, the RIR serving this region, also reached its "last /8" threshold, and ceased to hand out any further general use IPv4 addresses. The process of exhaustion continues, and the registry that serves Northern America and parts of the Caribbean, ARIN, has some 40 million addresses left in its address pool. At the current consumption rate ARIN will be down to its last /8 block 12 months from now, in April 2014. LACNIC, the regional registry serving Latin America and the Caribbean, currently has some 43 million addresses in its pool, and is projected to reach their last /8 slightly later in August 2014. The African regional registry, AFRINIC, has 62 million addresses, and at its current address consumption rate, the registry will be able to service address requests for the coming seven years.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:15px 0 15px 0;display:block;text-align:center;"><img src="http://www.circleid.com/images/uploads/7327h.gif" border="0" width="644" height="445" style="display:block;margin-bottom:15px;" />Figure 8 &ndash; IPv4 Address Depletion (<a href="http://labs.apnic.net/ipv4/report.html" target="_blank">Source</a>)</span>
</p>
<p>
So if the concept was that we would not only commence, but complete the process of transition to use IPv6 across the entire Internet before we got to that last IPv4 address, then for Europe, the Middle East, Asia and the Pacific this is not going to happen. It's just too late. And for North and South America it's also highly unlikely to happen in time.
</p>
<p>
And the slow pace of uptake of IPv6 points to the expectation that this "running on empty" condition for the Internet address plan may well continue for some years to come.
</p>
<p>
We are now entering into a period of potential damage for the Internet. If the objective of this transition from IPv4 to IPv6 was to avoid some of the worse pitfalls of exhaustion of the IPv4 address space in the internet, then we've failed.
</p>
<p>
The consequence of this failure is that we are now adding a new challenge for the Internet. It's already a given that we are meant to sustain continued, and indeed accelerating, growth in terms of the overall size of the network and the population of connected devices. The pace of this growth is expressed as a demand for some 300 million additional IP addresses per year, and the figures from the device manufacturers point to a larger figure of some 500 &#8212; 700 million new devices being connected to the Internet each year. And the number grows each year. We are expanding the Internet at ever faster rates. As if riding this phenomenal rate of growth on the existing infrastructure and existing technology base wasn't challenging enough, we also have the objective not just to maintain, but to accelerate the pace of transition to IPv6. These two tasks were already proving to be extremely challenging, and we've been slipping on the second. But we now have the additional challenge of trying to achieve these two objectives without the supply of any further IPv4 addresses. At this point the degree of difficulty starts to get uncomfortably close to ten!
</p>
<p>
This situation poses some architectural consequences for the Internet. Until now we've managed to push NATs out to the edge of the network, and make address compression something that end users did in their home networks. The consequences of failure of such devices and functions are limited to the edge network served by the NAT. We are now deploying mechanisms that allow this NAT function to be performed in the core of the carriage networks. This introduces a new set of unquantified factors. We've little experience in working with large scale NAT devices. We have no idea of the failure modes, or even the set of vulnerabilities in such an approach. We are still debating the appropriate technical approach in the standards bodies, so there are a variety of these service provider NAT approaches being deployed. Each NAT approach has different operational properties, and different security aspects. But now we don't have the luxury of being able to buy more time to explore the various approaches and understand the relative strengths and weaknesses of each. The exigencies of address exhaustion mean that the need for carrier level NAT solutions is now pressing, and given that this is a situation that we never intended to experience, we find ourselves ill-prepared to deal with the side effects from this subtle change in the network's architecture. The greater the level of complexity we add into the network, and the wider the variation in potential network behaviours as a result, the greater the burden we then place on applications. If the network becomes complex to negotiate then applications are forced to explore the local properties of the network environment in order to provide the user with a robust service.
</p>
<p>
If the hallmark of the Internet was one of efficiency and flexibility based on a simple network architecture, then as we add complexity into the network what we lose is this same efficiency and flexibility that made the Internet so seductively attractive in the first place. The result is a network that is baroquely ornamented, and one that behaves in ways that are increasingly capricious.
</p>
<p>
We are hopelessly addicted to using a network protocol that has now run out of addresses. At this point the future of the Internet, with its projections of trillions of dollars of value, with its projections of billions of connected silicon devices, with its projections of petabytes of traffic, with its projections of ubiquitous fibre optics conduits spanning the entire world is now entering a period of extreme uncertainty and confusion. A well planned path of evolution to a new protocol that could comfortably address these potential futures is no longer being followed. The underlying address infrastructure of the network is now driven by scarcity rather than abundance, and this is having profound implications on the direction of evolution of the Internet.
</p>
<p>
There really is something badly broken in today's Internet.
</p><p><em>Written by <a href="http://www.circleid.com/members/602/">Geoff Huston</a>, Author & Chief Scientist at APNIC</em></p>]]></description>
			<dc:date>2013-04-21T12:57:00-08:00</dc:date>
			<category>internet</category><category>ip_addressing</category><category>ipv6</category>
		</item>
		
		<item>
			<title>Live Today &#45; &quot;IPv4 Exhaustion and the Path to IPv6&quot; from INET Denver</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130417_live_today_ipv4_exhaustion_path_to_ipv6_from_inet_denver/</guid>
			<link>http://www.circleid.com/posts/20130417_live_today_ipv4_exhaustion_path_to_ipv6_from_inet_denver/</link>
			<description><![CDATA[<p><img src="http://www.circleid.com/images/uploads/7314.gif" border="0" width="200" height="84" style="float:right;padding:0 0 5px 15px;" />If you are interested in the current state of IPv4 address exhaustion within North America as well as the current state of IPv6 deployment, there will be a live stream today, April 17, of the sessions happening at <a href="http://www.internetsociety.org/events/inet-denver" title="undefined">INET Denver</a> starting at 1:00pm US Mountain Daylight Time (UTC-6). The event is subtitled "<i>IPv4 Exhaustion and the Path to IPv6</i>&#8221; and you can view the live stream at:
</p>
<p>
<a href="http://www.internetsociety.org/events/inet-denver/inet-denver-livestream" title="undefined">http://www.internetsociety.org/events/inet-denver/inet-denver-livestream</a>
</p>
<p>
Sessions include:
</p>
<ul>
<li>IPv4 Exhaustion Update
<li>IPv4 Exhaustion at ARIN
<li>Address Policy Workshop
<li>Evaluation of Current Transfer Market
<li>TCO of IPv6
<li>Internet Society Initiatives and How To Get Involved
</ul>
<p>
The <a href="http://www.internetsociety.org/events/inet-denver/inet-denver-speakers" title="undefined">list of speakers</a> includes people from ARIN, CableLabs, Internet Society, Time Warner Cable, Google and more.
</p>
<p>
It sounds like a great event and I'm looking forward to watching it remotely.&nbsp; It will be recorded so that you will be able to watch it later if you cannot view it live.
</p><p><em>Written by <a href="http://www.circleid.com/members/2673/">Dan York</a>, Author and Speaker on Internet technologies</em></p>]]></description>
			<dc:date>2013-04-17T09:26:00-08:00</dc:date>
			<category>internet</category><category>internet_protocol</category><category>ip_addressing</category><category>ipv6</category><category>policy_regulation</category>
		</item>
		
		<item>
			<title>What&apos;s the Best IPv6 Transition Option for You?</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130416_what_is_the_best_ipv6_transition_option_for_you/</guid>
			<link>http://www.circleid.com/posts/20130416_what_is_the_best_ipv6_transition_option_for_you/</link>
			<description><![CDATA[<p>After decades of talk, the time for IPv6 has finally arrived. There are several transition options available, but whatever approach you choose, the challenge will be to make sure that your subscribers don't experience a reduction in quality of service.
</p>
<p>
IPv4 is likely to co-exist with IPv6 for some time, so a native dual-stack migration strategy will be the best transition option for most providers. Dual-stack mode allows both IPv4 and IPv6 to run simultaneously over the network, which lets end-user devices communicate via whichever protocol they are equipped for. With dual-stack mode, there is no disruption to the service if a client requests an IPv4 address. Clients that receive both an IPv4 and IPv6 address will prefer to access the IPv6 network, if it's available. The DNS can determine whether the service is reachable over IPv6 or whether to fall back to IPv4.
</p>
<p>
Of course, dual-stack provisioning isn't perfect. Service disruptions can occur if you don't have enough IPv4 addresses to hand out to new subscribers. This is because dual-stack systems require devices to have both an IPv4 and IPv6 address. If this is a problem for you, it may be possible to use a tunneling technique or network address translation (NAT).
</p>
<p>
NAT, however, comes with its own set of problems, including:
</p>
<ul><li>Impaired quality of service for internal and external systems</li>
<li>Increased network complexity and fragmentation</li>
<li>Security concerns when multiple subscribers share a single, public IPv4 address</li>
<li>Difficulty with law enforcement compliance</li></ul>
<p>
Despite these issues, you may find it difficult to implement native dual-stack mode without NAT if you continue to delay your IPv6 preparations. The sooner that you can begin handing out IPv6 addresses to new customers, the sooner you will be able to store IPv4 resources to provide addresses to older subscriber devices. This means you need to start your IPv6 preparations now &#8212; even if you still have plenty of IPv4 resources.
</p>
<p>
<em>If you're interested in learning more about dual-stack migration or want to explore other transition options, download our free ebook: <a href="http://go.incognito.com/l/16142/2013-03-18/5189y" target="_blank">IPv6 eBook Series: Migration</a>.</em>
</p><p><em>Written by <a href="http://www.circleid.com/members/6916/">Stephane Bourque</a>, Founder, CEO and President at Incognito Software</em></p>]]></description>
			<dc:date>2013-04-16T09:58:00-08:00</dc:date>
			<category>internet</category><category>ip_addressing</category><category>ipv6</category>
		</item>
		
		<item>
			<title>Networks Announcing IPv6 Over Time: A Short Update</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130405_networks_announcing_ipv6_over_time_a_short_update/</guid>
			<link>http://www.circleid.com/posts/20130405_networks_announcing_ipv6_over_time_a_short_update/</link>
			<description><![CDATA[<p>We regularly check the status of IPv6 deployment in the RIPE NCC service region, and in other service regions as well. One way to measure IPv6 deployment is to look at the percentage of networks announcing IPv6 prefixes and follow the developments over time.
</p>
<p>
The RIPE NCC's <a href="http://v6asns.ripe.net/">IPv6-ASN graph</a> shows the percentage of networks that announce one or more IPv6 prefixes in the global routing system. Having an IPv6 prefix visible in the global routing system is a required step for a network to actually start exchanging IPv6 traffic with other networks. The interactive graph allows you to specify the countries or service regions you are interested in, which can make for some interesting comparisons.
</p>
<p>
The graph below shows the percentage of networks announcing IPv6 prefixes in each Regional Internet Registry's (RIR) service region over the last few years.
</p>
<p>
<img src="http://www.circleid.com/images/uploads/7291.jpg" border="0" width="644" height="469" style="display:block;" />
</p>
<p>
It is interesting to see that the percentage of networks announcing IPv6 address space in the APNIC and the RIPE NCC service regions continues to increase steadily. Both of these RIRs have reached IPv4 exhaustion (in 2011 and 2012 respectively) and are currently allocating from their last /8 block of addresses.
</p>
<p>
It is also encouraging to see that the percentage of IPv6-enabled networks in the ARIN service region, which is projected to be the third RIR to reach its last /8 of IPv4 addresses, is also increasing. On the other hand, the percentage of IPv6-enabled networks in the Lacnic and the AFRINIC service regions appears to have stopped growing. For the Lacnic service region this number even fell a little over the last few months. Despite the absolute number of IPv6 announcing networks growing from 388 to 399 since the beginning of 2013, this growth was outpaced by the total growth of networks in the service region that are visible in the global routing system, which resulted in a total percentage decrease from 15.5% to 15.0% for this period. Even though this might not be a surprise, it's reassuring to see that in regions where IPv4 exhaustion has occurred, there is a steady growth in the percentage of networks announcing IPv6 address space.
</p>
<p>
If you find other interesting comparisons between countries or regions, please comment below! You can find more information and statistics on <a href="https://labs.ripe.net">RIPE Labs</a>.
</p>
<p>
Note that this article is based on work done by Emile Aben, System Architect at the RIPE NCC.
</p><p><em>Written by <a href="http://www.circleid.com/members/5155/">Mirjam Kuehne</a></em></p>]]></description>
			<dc:date>2013-04-05T03:29:00-08:00</dc:date>
			<category>internet</category><category>ip_addressing</category><category>ipv6</category>
		</item>
		
		<item>
			<title>INET Denver: IPv4 Exhaustion and the Path to IPv6</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130401_inet_denver_ipv4_exhaustion_and_the_path_to_ipv6/</guid>
			<link>http://www.circleid.com/posts/20130401_inet_denver_ipv4_exhaustion_and_the_path_to_ipv6/</link>
			<description><![CDATA[<p>INET Denver is April 17, 2013 &#8212; <a href="http://www.internetsociety.org/form/inet" target="_blank">register today to reserve your spot!</a>
</p>
<p>
You won't want to miss this unique opportunity to join IPv6 networking professionals from across North America, who will attend to learn the latest on IPv4 exhaustion and how to transition to IPv6. The INET Denver agenda will bring together top experts in the networking field to discuss the latest on IPv4 exhaustion in our market, and the TCO of IPv6.
</p>
<p>
<strong>The <a href="http://www.internetsociety.org/events/inet-denver/inet-denver-speakers" target="_blank">line up of speakers</a> includes industry experts like:</strong>
</p>
<blockquote><p>John Curran, <em>President &amp; CEO, ARIN</em>
<br />
Owen DeLong, <em>IPv6 Evangelist, Hurricane Electric</em>
<br />
Lee Howard, <em>Director of Network Technology, Time Warner Cable</em>
<br />
Dr. Patrick Ryan, <em>Public Policy &amp; Government Relations Counsel, Google</em></p></blockquote>
<p>
<strong>When:</strong>
<br />
<blockquote><p> April 17, 2013
<br />
Registration: 12:00 - 1:00 PM
<br />
INET Denver: 1:00 - 6:00 PM
<br />
Refreshments: 6:00 - 7:30 PM</p></blockquote>
<p>
<strong>Where:</strong>
<br />
<blockquote><p>Grand Hyatt Denver
<br />
1750 Welton Street
<br />
Denver, CO 80202</p></blockquote>
<p>
<strong>Additional Details:</strong>
<br />
<blockquote><p><a href="Refreshments" target="_blank">http://www.internetsociety.org/events/inet-denver</a></p></blockquote>
<p>
<strong>Registration:</strong>
<br />
<blockquote><p><a href="Refreshments" target="_blank">http://www.internetsociety.org/form/inet</a></p></blockquote>
<p>
The INET Denver will co-locate with the <a href="http://rmv6tf.org/na-ipv6-summit/2013-north-american-ipv6-summit" target="_blank">2013 North American IPv6 Summit</a>. Take part in this unique opportunity to learn from top experts in the networking field discussing the latest on IPv4 exhaustion in our market and the TCO of IPv6.
</p>
<p>
Don't delay and register today!
</p>]]></description>
			<dc:date>2013-04-01T11:45:00-08:00</dc:date>
			<category>internet</category><category>ip_addressing</category><category>ipv6</category>
		</item>
		
		<item>
			<title>Live Webcast Thursday March 28 of ION Singapore IPv6 and DNSSEC Sessions</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130327_live_webcast_march_28_ion_singapore_ipv6_and_dnssec_sessions/</guid>
			<link>http://www.circleid.com/posts/20130327_live_webcast_march_28_ion_singapore_ipv6_and_dnssec_sessions/</link>
			<description><![CDATA[<p>For those of you interested in IPv6 and/or DNSSEC, we'll have <a href="http://www.internetsociety.org/deploy360/ion/singapore2013/webcast/">a live webcast</a> out of the Internet Society's <a href="http://www.internetsociety.org/deploy360/ion/singapore2013/" title="ION Singapore">ION Singapore conference</a> happening tomorrow, March 28, 2013, starting at 2:00pm Singapore time.
</p>
<p>
<a href="http://www.internetsociety.org/deploy360/ion/singapore2013/agenda/">Sessions on the agenda</a> include:
</p>
<ul style="padding-left:80px;"><li>The Business Case for IPv6 &amp; DNSSEC</li>
<li>Deploying DNSSEC: From End-customer to Content</li>
<li>Industry Collaboration: Working Together to Deploy IPv6</li></ul>
<p>
Joining the sessions are <a href="http://www.internetsociety.org/deploy360/ion/singapore2013/speakers/">a variety of speakers</a> from across the industry and within the Asia Pacific region. Information about the webcast can be found at:
</p>
<p>
<a href="http://www.internetsociety.org/deploy360/ion/singapore2013/webcast/">http://www.internetsociety.org/deploy360/ion/singapore2013/webcast/</a>
</p>
<p>
We'll also be recording the sessions so you can view them later. For example, given that Singapore time is 12 hours ahead of U.S. Eastern time, I don't expect many of the folks I know there to be up at 2am to watch these sessions!
</p>
<p>
The ION Singapore conference is produced by the <a href="http://www.internetsociety.org/deploy360/">Internet Society Deploy360 Programme</a> and is part of the ICT Business Summit taking place this week in Singapore. I just got to meet some of the panelists at a dinner tonight and I think the sessions tomorrow should be quite educational and also quite engaging and fun. Please do feel free to tune in if you are interested and have the chance to do so.
</p>
<p>
P.S. In full disclosure I <em>am</em> employed by the Internet Society to work on the Deploy360 Programme and for once a post of mine at CircleID <em>IS</em> related to my employer.
</p><p><em>Written by <a href="http://www.circleid.com/members/2673/">Dan York</a>, Author and Speaker on Internet technologies</em></p>]]></description>
			<dc:date>2013-03-27T08:00:00-08:00</dc:date>
			<category>internet</category><category>dns</category><category>dnssec</category><category>ipv6</category><category>security</category>
		</item>
		
		<item>
			<title>IPv6: SAVA, Ca va pas?</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130319_ipv6_sava_ca_va_pas/</guid>
			<link>http://www.circleid.com/posts/20130319_ipv6_sava_ca_va_pas/</link>
			<description><![CDATA[<p>Sender Address Validation and Authentication (SAVA) is the silver bullet. It will send to Cyberia all dark forces that make us shiver when we make a purchase on the internet, pose a threat to our very identities and have made DDoS a feared acronym.
</p>
<p>
Some of you will remember the heated debates when Calling Line Identification (CLID) was first introduced in telephony. Libertarians of all stripes called passionately to ban such an evil tool threatening our most precious civil liberties like the impunity of calling home from the bar, pretending to be still at work or with a customer. Today everybody welcomes the decline of crank and obscene calls even if telemarketers can continue to be a nuisance. Will SAVA be for the internet what CLID was for telephony?
</p>
<p>
One of the beauties and at the same time a source of potential vulnerability of the internet design is that it forwards packets connectionless, hop by hop, based on the destination address. This has proven a cornerstone of the amazing resiliency and scalability of the internet. The flip side is that this makes the blue box offspring, address spoofing more prevalent. From making occasional free calls in the 'telephony era', internet address spoofing now substitutes legitimate source addresses to fraudulently obtain personal information from unsuspecting end-users or wreak havoc flooding network hosts, DNS systems and even networks with DDoS attacks. So much so that a number of ISP's now offer 'scrubbing services' to their customers. Zacks Investment sees Cyber Security firms <a href="http://www.zacks.com/stock/news/94992/is-a-cyber-pearl-harbor-looming">as a major investment opportunity</a>. This is surely a growing and lucrative market segment; I might follow their advise.
</p>
<p>
SAVA was first presented at an IEEE conference in 2007 and subsequently <a href="http://www.rfc-editor.org/rfc/rfc5210.txt">proposed as a RFC</a> to the IETF in 2008 with Tsinghua University of Beijing as lead author. The paper addressed the need for source address verification on the access network, intra-AS within a network, and inter-AS between networks across BGP boundaries. This led to the creation of a quite active <a href="http://datatracker.ietf.org/wg/savi/">IETF working group called SAVI</a> to tackle the subject. An <a href="http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/">informational draft</a> issued this February provides a good overview of a variety of 'attack vectors' and threats. How fast some of these RFC will be completed and approved and, more importantly, implemented remains however an open question.
</p>
<p>
China has reported that it is experimenting with a SAVA implementation in its CNGI (China Next Generation Internet) IPv6 only based R&amp;E network, in no less than the United Kingdom's prestigious <a href="http://rsta.royalsocietypublishing.org/content/371/1987/20120387">Philosophical Transactions of the Royal Society</a>. This has in turn triggered some activity in the blogosphere ranging from <a href="http://www.newscientist.com/article/mg21729075.800-chinas-nextgeneration-internet-is-a-worldbeater.html">more factual</a> to a bit <a href="http://www.zmescience.com/research/technology/chinas-next-generation-internet-infrastructure-tightens-security/">more alarming</a>. Concluding yet again that China is light years ahead of the United States in IPv6 deployment remains questionable however. While CNGI has without question been the benchmark for native IPv6 deployment for many years in a Research and Education Networking environment, <a href="http://www.circleid.com/posts/20121128_ipv6_a_2012_report_card/">China has been really lagging</a> so far in the commercial deployment of IPv6. They obviously bide their time.
</p>
<p>
While some will argue that SAVA would undermine their civil liberties and individual freedom especially when they prefer anonymity in whatever they are doing on the internet and others will see it as another step to big brother watching us, the need for better security is undeniable and even more urgent as we accelerate towards a mobile broadband data environment. <a href="http://www.eweek.com/mobile/smartphone-sales-set-to-top-feature-phones-in-2013-idc/">IDC predicts</a> that, this year, smartphone sales will for the first time surpass feature phones. Mobile operators enjoy usage based services and billing; to correctly identify the source will always remain essential to revenue generation and corporate wellbeing. And what would the impact be of a DDoS attack choking a major LTE network?
</p>
<p>
Major ISP's and mobile operators might want to track SAVA more closely; ça va ou ça va pas?
</p><p><em>Written by <a href="http://www.circleid.com/members/2967/">Yves Poppe</a>, Director, Business Development IP Strategy at Tata Communications</em></p>]]></description>
			<dc:date>2013-03-19T13:28:01-08:00</dc:date>
			<category>internet</category><category>ddos</category><category>dnssec</category><category>ipv6</category><category>security</category>
		</item>
		
		<item>
			<title>IPv6: How Do the Top Ranked Tier&#45;One ISP&apos;s Perform?</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130222_ipv6_how_do_the_top_ranked_tier_one_isps_perform/</guid>
			<link>http://www.circleid.com/posts/20130222_ipv6_how_do_the_top_ranked_tier_one_isps_perform/</link>
			<description><![CDATA[<p>A look at the world's dozen or so Tier one ISP's who run global networks and sell wholesale IP transit to national and regional 'tier two ISP's' is quite revealing when taking into account how their ranking evolved over the last five years. They peer with each other at selected locations while competing ferociously in an increasingly commoditized market. Indeed, wholesale IP transit prices continue to plummet as the available international cable capacity is on its way to increase by an order of magnitude with per wavelength capacity upgrades from 10gbps to 40gbps and more recently to 100gbps on a growing number of cables. Needless to say that our dozen tier ones who carry the bulk of the world's intercontinental internet traffic also control substantial amounts of subsea cable capacity.
</p>
<p>
<a href="http://www.renesys.com/">Renesys</a> has been keeping track of the evolution of these top providers for the last five years in its' annual '<a href="http://www.renesys.com/blog/2013/01/a-bakers-dozen-2012-edition.shtml">Bakers Dozen</a>' ranking. This classification has become a key barometer and a must read amongst telecomm companies and investors.
</p>
<p>
A look at the five annual rankings reveals the gradual shifts as some players rose and others declined or were acquired.
</p>
<p>
2008 was a pivotal year as it saw Sprint, who had been leading the pack since the world entered the commercial internet era in the mid nineties, overtaken by Level 3. Holding the crown ever since, Level 3 built a quasi unsurmountable lead when it completed the acquisition of then number two ranked Global Crossing in October 2011.
</p>
<p>
The progressive decline of Sprint and AT&amp;T during these five years might surprise while Verizon's ranking stabilized after a relative decline in the first two years. Qwest and Savvis disappeared from the list as they were acquired by Centurylink who made a first appearance in the 2012 rankings.
</p>
<p>
The rising stars during this period have been NTT, Telianet and Tiscali (now Inteliquent) while Tata Communications and China Telecom also improved their rankings. The last two years have seen a strong upswing for Cogent and Italy's Sparkle.
</p>
<p>
It is interesting to compare the Renesys ranking and the most recent <a href="http://www.telegeography.com/">Telegeography</a> ranking of ISP's serving the Fortune 500 companies. In the latter, the top positions are held by five American ISP's with Verizon in top spot, followed by AT&T;, Level 3, Centurylink and Sprint. Then we see Great Britain's BT and Colt. This illustrates that the more lucrative enterprise market generally favours well established native ISP's who combine high network capillarity in the enterprise's home-country with good international coverage.
</p>
<p>
Just to remain in the Bakers Dozen was no small accomplishment as it required to keep pace with five years of more than 50% CAGR in the volume of international internet traffic which is now zeroing in on 80Tbps.
</p>
<p>
These rankings are all based on IPv4 but what about IPv6? The intersection of ISP's, figuring in both the latest Bakers' Dozen and a reading of today's Renesys IPv6 classification, shows Level3 leading, followed by Inteliquent, Telia, NTT, Global Crossing, Cogent and Tata. This implies a good correlation between IPv6 support and a strong commitment to IP transit wholesale.
</p>
<p>
Another way to rank the these same networks is their degree of IPv6 preference based on <a href="http://labs.apnic.net/ipv6-measurement/">APNIC's Geoff Huston's data</a>. Here we find Tata leading followed by Telia and NTT. Level 3, Cogent and Global Crossing are grouped in a rather distant second cluster while Tinet (AS3257) was not ranked. One reason most of the major American tier ones rank lower on the IPv6 preference scale is probably the still lagging IPv6 penetration in the enterprise sector where they dominate the market. Something worth monitoring going forward.
</p>
<p>
How will international IP wholesale evolve over the coming couple of years? Some further consolidation within the Bakers Dozen is likely. The international IP wholesale transit market continues to evolve rapidly as some major IX's now go intercontinental and connect directly to each other. At the same time major content providers such as Google and Facebook are shifting a growing portion of their ever growing traffic to international Ethernet connections or leased lines and even acquire their own transoceanic capacity on some routes. With the growth of the mobile internet, the growth of internet traffic including its international component will remain staggering for years to come. The latest <a href="http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.html">Cisco forecast</a> was revised upward again and estimates that by the end of 2012, fourteen percent of mobile devices and connections were potentially IPv6 capable, growing to 41% by 2017 .
</p>
<p>
It is safe to bet that the absolute volumes of IPv6 traffic and IPv4 traffic will fit this growth pattern with the proportion of IPv6 traffic growing at a slow but steady pace. The proportion of inquiries in IPv6 in the <a href="http://www.google.com/ipv6/statistics.html">Google ranking</a>, currently at 1.1% should reach the 2% mark twelve months from now. Less than that would be a bit disappointing.
</p><p><em>Written by <a href="http://www.circleid.com/members/2967/">Yves Poppe</a>, Director, Business Development IP Strategy at Tata Communications</em></p>]]></description>
			<dc:date>2013-02-22T08:27:00-08:00</dc:date>
			<category>internet</category><category>access_providers</category><category>ipv6</category>
		</item>
		
		<item>
			<title>CENTR Paper on Fifth World Telecommunication/ICT Policy Forum</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130213_centr_paper_on_fifth_world_telecommunication_ict_policy_forum/</guid>
			<link>http://www.circleid.com/posts/20130213_centr_paper_on_fifth_world_telecommunication_ict_policy_forum/</link>
			<description><![CDATA[<p><span style="font-size:85%;color:#666666;padding:0 0 2px 7px;margin:0 0 10px 10px;border-left:1px solid #ddd;width:300px;float:right;line-height:1.3em;"><a href="http://centr.org/CENTR-Paper-WTPF" target="_blank"><img src="http://www.circleid.com/images/uploads/7178.gif" border="0" width="300" height="427" style="display:block;margin-bottom:10px;" /></a><strong>CENTR Paper</strong> &ndash; Fifth World Telecommunication/ICT Policy Forum (<a href="http://centr.org/CENTR-Paper-WTPF">Download PDF</a>)</span><em>The following is a paper released by <a href="http://www.centr.org/" target="_blank">CENTR</a>, Council of European National Top Level Domain Registries, on ITU's upcoming Fifth World Telecommunication/ICT Policy Forum.</em>
</p>
<p>
<strong>Introduction</strong>
</p>
<p>
Many nations, particularly from the developing world, look to the International Telecommunications Union (ITU) for advice on telecommunications issues and, increasingly, Internet governance issues. The ITU's Fifth World Telecommunication/ICT Policy Forum (WTPF-13), 14-16 May 2013, Geneva, Switzerland, will be the first WTPF to focus exclusively on Internet issues. Positions agreed to by ITU Member States on the management of Internet resources &#8212; including ccTLDs &#8212; and the roles and responsibilities of stakeholders in Internet governance are of particular importance to ccTLD operators due to the close association of ccTLDs to the territorial boundaries of sovereign nations.
</p>
<p>
<strong>WTPF-13</strong>
</p>
<p>
WTPF-13 has been convened to discuss the issues raised in ITU's three key Internet-related resolutions:<sup>1</sup>
</p>
<ul><li>Resolution 101:"Internet Protocol (IP)-based Networks" (Rev. Guadalajara, 2010)<sup>2</sup></li>
<li>Resolution 102: "ITU's role with regard to international public policy issues pertaining to the Internet and the management of Internet resources, including domain names and addresses" (Rev. Guadalajara, 2010)<sup>3</sup></li>
<li>Resolution 133: "Roles of administrations of Member States in the management of Internationalized (multilingual) domain names" (Rev. Guadalajara, 2010)<sup>4</sup></li></ul>
<p>
The main policy outcomes of WTPF-13 will be the "Opinion" documents, which are non-binding on ITU's membership. However, the Opinions and final meeting report will be a good indicator of the Internet issues that may become the focus of ITU discussions, and in turn, more formal resolutions and recommendations, in the near future. In particular, WTPF-13 outcomes will inform the discussions at the Council Working Group on International Internet-Related Public Policy Issues (CWG-Internet), the ITU Plenipotentiary 2014 and the WSIS+10 review process.
</p>
<p>
In preparation for WTPF-13, two meetings of the Informal Experts Group (IEG)<sup>5</sup> have already been held to fine-tune the Secretary- General's report.<sup>6</sup> The report's summary of issues, which includes ccTLD processes, will form the basis of WTPF-13 discussions in May. Draft Opinions have been made available in the fourth, and latest, version of the Secretary-General's report. It is possible that more Draft Opinions will appear in the next and final version of the Secretary General's report, which will be published 1 March 2013.
</p>
<p>
<strong>WTPF-13 Draft Opinions</strong>
</p>
<p>
There are six Draft Opinions in the January 2013 version of the Secretary-General's report. The final WTPF-13 Opinions will be based on these drafts and onsite discussion of the contents of the Secretariat-General's report.
</p>
<p>
<strong><em>Overall model of Internet governance and development</em></strong>
</p>
<p>
There are three Draft Opinions on this topic. Two of the three drafts, submitted by Saudi Arabia, focus on the need for "immediate operationalization of the enhanced cooperation process" via an existing or new intergovernmental organization, in consultation with other stakeholders. The third draft, submitted by the United Kingdom, focuses on open, transparent and accountable Internet development, freedom of expression, universal access, and invites all stakeholders &#8212; not only Member States and Sector Members &#8212; to collaborate towards the ongoing expansion of the Internet.
</p>
<blockquote><p><em>Why these Opinions matter:</em> These three Draft Opinions reflect fundamentally different views on how the Internet should be governed. On one side are States who believe it is important to have a government-only platform to discuss international Internet governance matters (this does not exclude other venues for Internet governance discussions). In many cases, these governments focus on the security risks the Internet can pose and seek an intergovernmental venue that can address these risks. On the other side are States who prefer to maintain the current multi-stakeholder environment, believing that governments already have enough opportunities to participate in Internet governance processes. These States often prefer to focus on the opportunities the Internet offers, such as freedom of expression and the development of an information society for all.</p></blockquote>
<p>
<strong><em>IPv6 deployment</em></strong> Both Draft Opinions on IPv6 encourage Member States to develop policies and incentives for IPv6 deployment within their territories. The Saudi Arabian draft also proposes ITU to develop policies to manage IPv4 address transfers in the wake of the exhaustion of the unallocated IPv4 pool. The United Kingdom's draft emphasizes the need to build human capacity in developing countries to enable IPv6 deployment.
</p>
<blockquote><p><em>Why these Opinions matter:</em> If ITU Member States recommend the ITU should actively develop policy for IP address space management &#8212; an area already served by Regional Internet Registries (RIRs) &#8212; it may open the door for ITU to consider policy development in other areas of Internet resource management. In many cases, such policy development already has a home within existing organizations, such as the ICANN.</p></blockquote>
<p>
<strong><em>IXPs as the long-term solution to better and more robust Internet connectivity</em></strong>
</p>
<p>
The final draft opinion, from the United Kingdom, invites Member States and Sector Members to work collaboratively with developing countries in promoting IXPs.
</p>
<blockquote><p><em>Why this Opinion matters:</em> In contrast to the other Draft Opinions, where views on the same topic are the result of ideological differences, this Draft Opinion is an example of practical ways to develop Internet capacity in developing countries. In addition, an improved Internet quality for regions served by new IXPs, will create new useful locations to host anycasted Root DNS Servers and secondary ccTLDs nameservers.</p></blockquote>
<p>
<strong><em>Internet issues contained in the Secretary-General's WTPF-13 report</em></strong>
</p>
<p>
Any of the topics included in the Secretary-General's report may be included in the final Opinions and meeting report. In particular, the broad scope of the three Draft Opinions on the overall model of Internet governance and development leaves room to add text on a variety of Internet issues summarized in the Secretary-General's report. The issues of most relevance to the ccTLD community in the report are:
</p>
<p>
<u>1. Roles and responsibilities of stakeholders in Internet management</u>
</p>
<p>
While the WSIS Tunis Agenda<sup>7</sup> recognized the multi-stakeholder model as the appropriate global model for Internet governance, the Secretary-General's report summarizes debates on whether the model has been fully implemented. One view maintains that the current Internet governance framework is sufficiently multi-stakeholder and that intergovernmental forums that discuss the Internet, such as the ITU, also need to adopt a multi-stakeholder approach. The ITU has itself been keen to change the world's perceptions of its working methods, publicizing that the WTPF IEG process is open to all stakeholders.<sup>8</sup>
</p>
<p>
The other view is that the role of governments in Internet governance has not been allowed to evolve according to the "enhanced cooperation" text in the Tunis Agenda, which states:
</p>
<p>
"We further recognize the need for enhanced cooperation in the future, to enable governments, on an equal footing, to carry out their roles and responsibilities, in international public policy issues pertaining to the Internet, but not in the day-to-day technical and operational matters, that do not impact on international public policy issues."
</p>
<p>
According to this second view, the failure to operationalize an intergovernmental mechanism for enhanced cooperation has contributed to the world's failure to adequately address ongoing Internet challenges, including spam and cybercrime. States holding this view often also question the adequacy of the ICANN Government Advisory Committee (GAC).
</p>
<p>
<u>2. Management of Internet resources</u>
</p>
<p>
The Secretary-General's report notes concerns with the current Internet infrastructure's ability to support the Internet's continued growth &#8212; in particular, the ability to support security, identity management and multilingualism. Under the topic of Internet resource management are the following topics of interest:
</p>
<ul><li>Internet connectivity &ndash; The high cost of international Internet connectivity for Least Developed Countries (LDCs) is seen to be particularly problematic, with IXPs reported as a long-term solution to the problem. Included in the report are descriptions of some of the main challenges LCDs face in closing the digital divide.</li>
<li>IP addresses &ndash; The ITU has a long history discussing IP address management, which is reflected in the Secretary-General's report. The slow rate of IPv6 deployment, in particular, is a concern, with continued debate about whether today's "first come, first served" IPv6 allocation policies could penalize late adopters. The ITU has issued a number of IP address-related resolutions<sup>9</sup>, so it is a certainty that WTPF 2013 will result in an IP address-related Opinion.</li>
<li>Resource Public Key Infrastructure (RPKI) &ndash; RPKI is still in its infancy but it is hoped it will make the Internet's IP routing system more secure. Given the security implications, RPKI is a topic of interest to ITU Member States and therefore is included in the Secretary-General's report. In particular, the report notes that questions have been raised about whether the operation of the RPKI certifi cate chain by ICANN and RIRs fundamentally changes their role in Internet governance.</li></ul>
<p>
<u>3. gTLDs</u>
</p>
<p>
The new gTLD process is detailed in the report, with the Secretary-General noting discussions about new gTLDs' impact on gTLD market competition and trademark or rights holders, particularly those in developing countries. The report also notes that concerns have been raised about the potential misuse of acronyms reserved for use by intergovernmental organizations (IGOs), geographic names, and cultural and language descriptors.
</p>
<p>
<u>4. ccTLDs</u>
</p>
<p>
The report notes that there is not a one-to-one relationship between a ccTLD string for a "territory" as defined in the ISO-3166 list and the name of a sovereign nation, with some nations having more than one ccTLD string reserved for their use (for example, Finland has both .fi and .ax). The ccTLD re-delegation process is also described in depth, including the need for the US government to evaluate IANA's report on the ccTLD request. The report includes a reference to ITU's role in requesting the re-delegation of .so in 2009 and notes that the Tunis Agenda states that countries should not be involved in decisions regarding another country's ccTLD. It is not clear whether this reference is meant to be compared directly with the earlier reference to the US government's role in overseeing re-delegation. The effect, however, is to highlight the US government's role in the re-delegation process of other nations' ccTLDs.
</p>
<p>
<u>5. DNS security</u>
</p>
<p>
The report describes how DNSSEC works and notes concerns about the processes that create the DNSSEC "chain of trust". However, given the sources of such concerns have not attended IEG meetings, the majority of the text reflects the views of those who support the current DNSSEC trust chain.
</p>
<p>
<u>6. Multilingualism and IDNs</u>
</p>
<p>
The report states that internationalized domain names (IDNs) are seen as an important step in overcoming linguistic barriers to Internet access, while also highlighting views that there are a number of challenges regarding intellectual property and the IDN deployment. The report notes some countries believe the current Unicode-based IDN implementation is "effectively a patch on an ASCII-based system and that the DNS will properly refl ect multilingualism when support is native to the system".
</p>
<p>
<u>7. Regional distribution of Root DNS Servers</u>
</p>
<p>
The report notes that there is a disparity between the geographical distribution of Root DNS Servers and the global distribution of Internet users but does bust the myth that there are only 13 Root Servers by explaining the concept of anycasting. However, the report also points out that only three of the Root Server operators have administrative headquarters outside the USA.
</p>
<p>
<strong>WTPF-13 and other Internet-related discussions at the ITU</strong>
</p>
<p>
The ITU has held many Internet-related discussions in its meetings and Study Groups. Discussion at WTPF-13 will both be informed by these previous discussions as well as inform future discussions on the Internet at the ITU. The key interactions are described below.
</p>
<p>
<strong><em>World Conference on International Telecommunications</em></strong>
</p>
<p>
Many of the proposals submitted during the two-year preparatory process of WCIT<sup>10</sup> contained explicit Internet-related content, including:
</p>
<ul><li>Adding principles for Internet governance</li>
<li>Asserting that "Member States have equal rights to manage the Internet, including in regard to the allotment, assignment and reclamation of Internet numbering, naming, addressing and identification resources"</li></ul>
<p>
Ultimately, the final set of International Telecommunication Regulations (ITRs)<sup>11</sup> produced in Dubai in 2012 did not include the word "Internet" anywhere. However, there are still many traces of Internet-related issues visible in the ITRs. For example, the ITRs' recognition of States' rights to access to international telecommunication services was added in response to trade blockades that prevent Internet-based services, such as electronic payments, being available in some countries. In addition, a new ITR article on accessibility to international telecommunication services is most applicable to Internet-based services (such as web services). There were strong disagreements on Internet-related issues at WCIT, and, following the intergovernmental practice of discarding proposals that cannot reach consensus amongst States, all direct references to the Internet were removed. A number of States, however, chose not to sign the ITRs &#8212; amongst them, the US government. Given the US government provides IANA with the authority to global coordinate the DNS Root and IP addressing systems, the refusal of the USA to sign the ITRs may be seen by a number of States as a sign that the USA "continues" to "control" the Internet. Many of the ideas expressed in Internet-related WCIT proposals have previously appeared in submissions to other ITU meetings, reflecting the fact that some Member States continue to feel strongly that current Internet governance arrangements &#8212; particularly the relationship between the US government and IANA &#8212; are unsatisfactory. Given the "unsatisfactory" Internet governance arrangements were not addressed in the WCIT outcomes, it is highly probable that many of the same issues will be create equally strong discussion at WTPF-13.
</p>
<p>
<strong><em>Council Working Group on International Internet-Related Public Policy Issues</em></strong>
</p>
<p>
Since 2010, the Member States-only CWG-Internet<sup>12</sup> &#8212; previously known as the Dedicated Group (DG) on International Internet- Related Public Policy Issues &#8212; has discussed ccTLDs, gTLDs, IDNs, IP addresses, DNSSEC, and RPKI under the banner of "critical Internet infrastructure". It has also discussed how ICANN and the ICANN GAC work. Although the group discusses many Internet issues that are currently managed under the open multi-stakeholder model of Internet governance, the CWG's documents are available only to Member States. One of the key documents produced by the group, "Internet Governance: Background Information on Mechanisms, Arrangements, Organizations and some Current Topics" is the source of much of the Secretary-General's report for WTPF-13, including information on ccTLD operations and re-delegation procedures. The Opinions produced by WTPF-13 are likely to affect future discussions within the CWG.
</p>
<p>
<strong><em>WSIS, the Tunis Agenda and WSIS+10</em></strong>
</p>
<p>
The World Summit on the Information Society (WSIS)<sup>13</sup> produced the Tunis Agenda, which has become one of the key documents informing intergovernmental discussions on Internet governance. While it clearly stated that the multi-stakeholder model was the appropriate model for global Internet governance, its text on the need for "enhanced cooperation" between governments in relation to Internet governance remains the subject of debate to this day. WTPF-13 discussions on the appropriate way to further implement, if necessary, governments' roles in Internet governance result directly from differing interpretations of this Tunis Agenda text. To mark the tenth anniversary of the WSIS process ("WSIS+10"), there will be a high level event in 2014 or 2015 that will assess the implementation of WSIS goals. As the tenth anniversary of WSIS is only two years ago, governments that have been pushing for an intergovernmental organization to enhance their role in Internet governance are beginning to express their frustration at the lack of progress to date. With the WCIT outcomes not meeting their goals, the WTPF is the next major ITU event at which governments can continue this debate.
</p>
<p>
<strong><em>Plenipotentiary 2014</em></strong>
</p>
<p>
WTPF-13 is based on the Internet-related resolutions that were updated at Plenipotentiary 2010 and will, in turn, influence the Internet-related resolutions developed at the next Plenipotentiary<sup>14</sup>. Resolutions passed at Plenipotentiaries are particularly important as these meetings set the agenda for the following four years of ITU's work.
</p>
<p>
<strong><em>How to participate in WTPF-13</em></strong>
</p>
<p>
The final version of the Secretary-General will be published 1 March 2013. The WTPF-13 will be held 14-16 May 2013, in parallel with ITU's WSIS Forum, in Geneva, Switzerland. Anyone can attend the WTPF and ask for the floor to make statements.
</p>
<p>
Nominet, responsible for .uk, has already made a submission to the IEG process.<sup>15</sup> Stakeholders can also contact their government representatives at ITU to help their government develop positions on the issues under discussion at WTPF-13. Many governments who support the multi-stakeholder model of Internet governance are also happy to place non-government stakeholders on their official delegation at meetings such as WTPF-13.
</p>
<p>
If you are unsure whom to contact within your government, a good place to start is the Participants List from WCIT:
<br />
<a href="http://files.wcitleaks.org/public/S12-WCIT12-ADM-0004!!PDF-E.pdf">http://files.wcitleaks.org/public/S12-WCIT12-ADM-0004!!PDF-E.pdf</a>
</p>
<p>
All information relating to WTPF-13 is posted at:
<br />
<a href="http://www.itu.int/wtpf">http://www.itu.int/wtpf</a>
</p>
<p>
<span class="footNotes"><sup>1</sup> Given the recent WCIT held in Dubai also adopted an Internet-related resolution, it is possible that the issues it raises will also be incorporated in the next version of the Secretary- General's report.
<br />
<br /><sup>2</sup> <a href="http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_101.pdf">http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_101.pdf</a>
<br />
<br /><sup>3</sup> <a href="http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_102.pdf">http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_102.pdf</a>
<br />
<br /><sup>4</sup> <a href="http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_133.pdf">http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_133.pdf</a>
<br />
<br /><sup>5</sup> <a href="http://www.itu.int/en/wtpf-13/Pages/ieg.aspx">http://www.itu.int/en/wtpf-13/Pages/ieg.aspx</a>
<br />
<br /><sup>6</sup> <a href="http://www.itu.int/en/wtpf-13/Pages/report-sg.aspx">http://www.itu.int/en/wtpf-13/Pages/report-sg.aspx</a>
<br />
<br /><sup>7</sup> <a href="http://www.itu.int/wsis/docs2/tunis/off/6rev1.html">http://www.itu.int/wsis/docs2/tunis/off/6rev1.html</a>
<br />
<br /><sup>8</sup> The recent WCIT Resolution 3 (<em>see</em> <a href="http://www.itu.int/en/wcit-12/Documents/final-acts-wcit-12.pdf">http://www.itu.int/en/wcit-12/Documents/final-acts-wcit-12.pdf</a>) also called on Member States to "to engage with all their stakeholders" on "international Internet-related technical, development and public-policy issues within the mandate of ITU" but stopped short of opening ITU meetings to the full participation of all stakeholders.
<br />
<br /><sup>9</sup> For example: WTSA 2008 Resolution 64, <a href="http://www.itu.int/dms_pub/itu-t/opb/res/T-RES-T.64-2008-PDF-E.pdf">http://www.itu.int/dms_pub/itu-t/opb/res/T-RES-T.64-2008-PDF-E.pdf</a>; WTDC 2010 Resolution 63, <a href="http://www.itu.int/osg/csd/intgov/ resoultions_2010/resolution63.pdf">http://www.itu.int/osg/csd/intgov/ resoultions_2010/resolution63.pdf</a>; Plenipotentiary 2010 Resolution 180 <a href="http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_180.pdf">http://www.itu.int/osg/csd/intgov/resoultions_2010/PP-10/RESOLUTION_180.pdf</a>
<br />
<br /><sup>10</sup> <a href="http://www.itu.int/en/wcit-12/Pages/default.aspx">http://www.itu.int/en/wcit-12/Pages/default.aspx</a>
<br />
<br /><sup>11</sup> <a href="http://www.itu.int/en/wcit-12/Pages/itrs.aspx">http://www.itu.int/en/wcit-12/Pages/itrs.aspx</a>
<br />
<br /><sup>12</sup> <a href="http://www.itu.int/council/groups/CWG-internet">http://www.itu.int/council/groups/CWG-internet</a>
<br />
<br /><sup>13</sup> <a href="http://www.itu.int/wsis">http://www.itu.int/wsis</a>
<br />
<br /><sup>14</sup> <a href="http://www.itu.int/en/plenipotentiary/Pages/default.aspx">http://www.itu.int/en/plenipotentiary/Pages/default.aspx</a>
<br />
<br /><sup>15</sup> <a href="http://www.itu.int/md/S12-WTPF13PREP-C-0024/en">http://www.itu.int/md/S12-WTPF13PREP-C-0024/en</a></span>
</p><p><em>Written by <a href="http://www.circleid.com/members/501/">CircleID Reporter</a></em></p>]]></description>
			<dc:date>2013-02-13T11:37:00-08:00</dc:date>
			<category>internet</category><category>access_providers</category><category>broadband</category><category>dnssec</category><category>icann</category><category>internet_governance</category><category>ip_addressing</category><category>ipv6</category><category>multilinguism</category><category>policy_regulation</category><category>regional_registries</category><category>telecom</category><category>top_level_domains</category>
		</item>
		
		<item>
			<title>1,000th /22 Allocated from Last /8</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130207_1000th_22_allocated_from_last_8/</guid>
			<link>http://www.circleid.com/posts/20130207_1000th_22_allocated_from_last_8/</link>
			<description><![CDATA[<p>On 14 September 2012, the RIPE NCC began allocating IPv4 address space from the last /8 we received from the Internet Assigned Numbers Authority (IANA). Nobody was entirely sure what would happen when we reached this point. Would there be a "run on the bank" for this final block of addresses?
</p>
<p>
Last week, we made our 1000th allocation from the final /8 and five months after reaching this point, we can report back on what we've seen so far.
</p>
<p>
Prior to reaching this milestone, the RIPE community had already developed policies to govern how the RIPE NCC would allocate the remaining space. The <a href="https://www.ripe.net/lir-services/resource-management/allocations-and-assignments/request-an-ipv4-22-from-the-last-8">last /8 policy</a> ensures that each member of the RIPE NCC can receive one final /22 of IPv4 address space (1,024 IPs) from the last /8. With approximately 16,000 /22s in a /8, and around 8,800 RIPE NCC members, the RIPE community decided that this approach would give Local Internet Registries (LIRs) some breathing room to make the transition to IPv6, and would also ensure new entrants to the industry could access IPv4 address space.
</p>
<p>
As pointed out in the most recent article <a href="https://labs.ripe.net/Members/wilhelm/ripe-ncc-membership-2012-statistics">RIPE NCC Membership - 2012 Statistics</a>, the number of IPv4 allocations issued since September has remained stable. In Figure 1 below, you can see the number of IPv4 /22 allocations per week since September 2012. The numbers were a little lower in the second half of December but they increased again in January 2013.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:5px 0 20px 0;display:block;"><img src="http://www.circleid.com/images/uploads/7173a.jpg" border="0" width="644" height="480" style="display:block;margin-bottom:10px;" /><strong>Figure 1:</strong> Number of IPv4 allocations since September 2012 on a weekly basis</span>
</p>
<p>
Note that the last bar doesn't show a full week but ends on 31 January &#8212; the day we handed out the 1,000th IPv4 /22.
</p>
<p>
As you can see in Figure 2, most allocations in the first two months were existing LIRs claiming their final /22 (additional allocations). This might be due to those requests that were already ongoing when we started allocating from the last /8.
</p>
<p>
<span style="font-size:85%;line-height:1.3em;color:#666666;margin:5px 0 20px 0;display:block;"><img src="http://www.circleid.com/images/uploads/7173b.jpg" border="0" width="644" height="485" style="display:block;margin-bottom:10px;" /><strong>Figure 2:</strong> Number of /22s as first (blue) vs. additional allocations (red) since reaching the last /8 of IPv4 address space </span>
</p>
<p>
Since November 2012, the majority of /22 allocations were made as first allocations to new LIRs. This indicates that the last /8 policy is ensuring that new entrants in the industry can still receive a small block of IPv4 address space for the foreseeable future. This had been one of the motivations behind the RIPE community putting this policy into place.
</p>
<p>
In summary, we can say that even though the number of IPv4 allocations has been fairly consistent since September, we haven't see a big run on the last block of IPv4 addresses. Considering the fact that we have over 8,800 members, 1,000 /22s allocated over five months is a moderate number. Also, when looking at the distribution of first verses additional allocations, the last /8 policy is working to allow new organisations to enter the market.
</p>
<p>
For more information and additional graphs, please refer to the background article on RIPE Labs: <a href="https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-slash-8">1,000 /22s Allocated from Last /8</a>.
</p><p><em>Written by <a href="http://www.circleid.com/members/5155/">Mirjam Kuehne</a></em></p>]]></description>
			<dc:date>2013-02-07T17:50:00-08:00</dc:date>
			<category>internet</category><category>ip_addressing</category><category>ipv6</category><category>regional_registries</category>
		</item>
		
		<item>
			<title>CircleID&apos; Top Ten Posts of 2012</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/20130110_circleid_top_ten_posts_of_2012/</guid>
			<link>http://www.circleid.com/posts/20130110_circleid_top_ten_posts_of_2012/</link>
			<description><![CDATA[<p>Here are the top ten most popular news, blogs, and industry updates featured on CircleID during 2012 based on the overall readership of the posts for the past 12 months. Congratulations to all the participants whose posts reached top readership and best wishes to the entire community for 2013.
</p>
<p>
<strong>Top Ten <a href="http://www.circleid.com/blogs/">Featured Blogs</a> from the community in 2012:</strong>
<br />
<table border="0" cellspacing="0" cellpadding="0" id="topTen"><tr><td class="rank">#<strong>1</strong></td><td><a href="http://www.circleid.com/members/620/"><img src="/images/member_photos/photo_620.jpg" border="0" width="60" alt="Paul Vixie" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120327_dns_changer/" title="DNS Changer" class="title">DNS Changer</a>by <a href="http://www.circleid.com/members/620/" class="blue">Paul Vixie</a> | Mar 27, 2012 | Viewed 66,094 times</td></tr><tr><td class="rank">#<strong>2</strong></td><td><a href="http://www.circleid.com/members/949/"><img src="/images/member_photos/photo_949.jpg" border="0" width="60" alt="Konstantinos Komaitis" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/trademarking_generics_the_bank_fiasco/" title="Trademarking .generics - the .bank Fiasco!" class="title">Trademarking .generics - the .bank Fiasco!</a>by <a href="http://www.circleid.com/members/949/" class="blue">Konstantinos Komaitis</a> | Jan 18, 2012 | Viewed 17,124 times</td></tr><tr><td class="rank">#<strong>3</strong></td><td><a href="http://www.circleid.com/members/620/"><img src="/images/member_photos/photo_620.jpg" border="0" width="60" alt="Paul Vixie" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/" title="Refusing REFUSED" class="title">Refusing REFUSED</a>by <a href="http://www.circleid.com/members/620/" class="blue">Paul Vixie</a> | Jan 11, 2012 | Viewed 11,860 times</td></tr><tr><td class="rank">#<strong>4</strong></td><td><a href="http://www.circleid.com/members/2459/"><img src="/images/member_photos/photo_2459.jpg" border="0" width="60" alt="Philip S Corwin" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/megabusts_megaquestions_cloud_the_nets_future/" title="MegaBust's MegaQuestions Cloud the Net's Future" class="title">MegaBust's MegaQuestions Cloud the Net's Future</a>by <a href="http://www.circleid.com/members/2459/" class="blue">Philip S Corwin</a> | Feb 13, 2012 | Viewed 10,430 times</td></tr><tr><td class="rank">#<strong>5</strong></td><td><a href="http://www.circleid.com/members/2859/"><img src="/images/member_photos/photo_2859.jpg" border="0" width="60" alt="Terry Zink" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120215_anonymous_plans_to_go_after_dns_root_servers/" title="Anonymous Plans to Go After DNS Root Servers. What Will Be the US's Response?" class="title">Anonymous Plans to Go After DNS Root Servers. What Will Be the US's Response?</a>by <a href="http://www.circleid.com/members/2859/" class="blue">Terry Zink</a> | Feb 15, 2012 | Viewed 9,813 times</td></tr><tr><td class="rank">#<strong>6</strong></td><td><a href="http://www.circleid.com/members/773/"><img src="/images/member_photos/photo_773.jpg" border="0" width="60" alt="Naseem Javed" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120724_why_dot_com_kingdom_will_continue_to_rule_post_new_gtlds/" title="Why the Dot Com Kingdom Will Continue to Rule Post New gTLDs" class="title">Why the Dot Com Kingdom Will Continue to Rule Post New gTLDs</a>by <a href="http://www.circleid.com/members/773/" class="blue">Naseem Javed</a> | Jul 24, 2012 | Viewed 9,771 times</td></tr><tr><td class="rank">#<strong>7</strong></td><td><a href="http://www.circleid.com/members/3296/"><img src="/images/member_photos/photo_3296.jpg" border="0" width="60" alt="Garth Bruen" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120327_fake_bank_site_fake_registrar/" title="Fake Bank Site, Fake Registrar" class="title">Fake Bank Site, Fake Registrar</a>by <a href="http://www.circleid.com/members/3296/" class="blue">Garth Bruen</a> | Mar 27, 2012 | Viewed 8,977 times</td></tr><tr><td class="rank">#<strong>8</strong></td><td><a href="http://www.circleid.com/members/5265/"><img src="/images/member_photos/photo_5265.jpg" border="0" width="60" alt="Wout de Natris" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20121121_why_vint_cerf_is_wrong/" title="Why Vint Cerf is Wrong" class="title">Why Vint Cerf is Wrong</a>by <a href="http://www.circleid.com/members/5265/" class="blue">Wout de Natris</a> | Nov 21, 2012 | Viewed 8,891 times</td></tr><tr><td class="rank">#<strong>9</strong></td><td><a href="http://www.circleid.com/members/1373/"><img src="/images/member_photos/photo_1373.jpg" border="0" width="60" alt="Paul Diaz" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120319_internet_governance_and_the_public_interest/" title="Internet Governance and the Public Interest" class="title">Internet Governance and the Public Interest</a>by <a href="http://www.circleid.com/members/1373/" class="blue">Paul Diaz</a> | Mar 19, 2012 | Viewed 8,384 times</td></tr><tr><td class="rank">#<strong>10</strong></td><td><a href="http://www.circleid.com/members/6756/"><img src="/images/member_photos/photo_6756.jpg" border="0" width="60" alt="Chris Grundemann" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120719_ipv6_subnetting_the_paradigm_shift/" title="IPv6 Subnetting - The Paradigm Shift" class="title">IPv6 Subnetting - The Paradigm Shift</a>by <a href="http://www.circleid.com/members/6756/" class="blue">Chris Grundemann</a> | Jul 19, 2012 | Viewed 8,380 times</td></tr></table>
</p>
<p>
<strong>Top 10 <a href="http://www.circleid.com/news/">News</a> in 2012:</strong>
<br />
<table border="0" cellspacing="0" cellpadding="0" id="topTen"><tr><td class="rank">#<strong>1</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120210_isps_are_not_broadcasters_says_supreme_court_of_canada/" title="ISPs Are Not Broadcasters, Says Supreme Court of Canada" class="title">ISPs Are Not Broadcasters, Says Supreme Court of Canada</a>Feb 10, 2012 | Viewed 35,128 times</td></tr><tr><td class="rank">#<strong>2</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/iran_blocks_https_30_million_reported_losing_email_access/" title="Iran Blocks HTTPS, 30 Million Reported Losing Email Access" class="title">Iran Blocks HTTPS, 30 Million Reported Losing Email Access</a>Feb 11, 2012 | Viewed 11,016 times</td></tr><tr><td class="rank">#<strong>3</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120605_vint_cerf_the_launch_of_a_new_larger_internet/" title="Vint Cerf: The Launch of a New Larger Internet" class="title">Vint Cerf: The Launch of a New Larger Internet</a>Jun 05, 2012 | Viewed 8,257 times</td></tr><tr><td class="rank">#<strong>4</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20121109_digital_marketing_gtld_strategy_congress_announce_keynote_speakers/" title="The Digital Marketing &amp; gTLD Strategy Congress Announces Keynote, Speakers, Initial Partnerships" class="title">The Digital Marketing &amp; gTLD Strategy Congress Announces Keynote, Speakers, Initial Partnerships</a>Jan 08, 2013 | Viewed 7,841 times</td></tr><tr><td class="rank">#<strong>5</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/akamai_reports_460_times_increase_in_ipv6_requests_over_its_platform/" title="Akamai Reports 460 Times Increase in IPv6 Requests Over Its Platform Since Last Year" class="title">Akamai Reports 460 Times Increase in IPv6 Requests Over Its Platform Since Last Year</a>Oct 22, 2012 | Viewed 6,976 times</td></tr><tr><td class="rank">#<strong>6</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/saudi_arabia_objects_to_certain_proposed_new_gtld_strings_such_as_gay/" title="Saudi Arabia Objects to Certain Proposed New gTLD Strings Such as .Gay and .Wine" class="title">Saudi Arabia Objects to Certain Proposed New gTLD Strings Such as .Gay and .Wine</a>Aug 15, 2012 | Viewed 6,764 times</td></tr><tr><td class="rank">#<strong>7</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120309_department_of_commerce_cancels_iana_contract_rfp/" title="Department of Commerce Cancels IANA Contract RFP" class="title">Department of Commerce Cancels IANA Contract RFP</a>Mar 09, 2012 | Viewed 6,343 times</td></tr><tr><td class="rank">#<strong>8</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20121017_special_updates_from_the_icann_meetings_in_toronto/" title="SPECIAL: Updates from the ICANN Meetings in Toronto" class="title">SPECIAL: Updates from the ICANN Meetings in Toronto</a>Oct 17, 2012 | Viewed 5,802 times</td></tr><tr><td class="rank">#<strong>9</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/most_us_agencies_expected_to_miss_ipv6_deadline/" title="Most U.S. Agencies Expected to Miss IPv6 Deadline" class="title">Most U.S. Agencies Expected to Miss IPv6 Deadline</a>Sep 28, 2012 | Viewed 5,411 times</td></tr><tr><td class="rank">#<strong>10</strong></td><td><img src="/images/icon_top_ten_news.gif" border="0" width="60" alt="CircleID Reporter" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/website_go_dark_protesting_sopa_and_pipa_senators_change_course/" title="Websites Go Dark Protesting SOPA and PIPA, Senators Change Course" class="title">Websites Go Dark Protesting SOPA and PIPA, Senators Change Course</a>Jan 18, 2012 | Viewed 5,299 times</td></tr></table>
</p>
<p>
<strong>Top 10 <a href="http://www.circleid.com/industry/">Industry News</a> in 2012 (sponsored posts):</strong>
<br />
<table border="0" cellspacing="0" cellpadding="0" id="topTen"><tr><td class="rank">#<strong>1</strong></td><td><a href="http://www.circleid.com/members/3844/"><img src="/images/member_photos/photo_3844.gif" border="0" width="60" alt="MarkMonitor" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120615_markmonitor_offers_new_gtld_application_database/" title="MarkMonitor Offers New gTLD Application Database" class="title">MarkMonitor Offers New gTLD Application Database</a>by <a href="http://www.circleid.com/members/3844/" class="blue">MarkMonitor</a> | Jun 15, 2012 | Viewed 6,992 times</td></tr><tr><td class="rank">#<strong>2</strong></td><td><a href="http://www.circleid.com/members/6624/"><img src="/images/member_photos/photo_6624.gif" border="0" width="60" alt="DotConnectAfrica" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20121023_dotconnectafrica_participates_in_icann_45_toronto_unveils_new_ibca/" title="DotConnectAfrica Participates in ICANN-45 Toronto, Unveils New IBCA Initiative at ICANN Public Forum" class="title">DotConnectAfrica Participates in ICANN-45 Toronto, Unveils New IBCA Initiative at ICANN Public Forum</a>by <a href="http://www.circleid.com/members/6624/" class="blue">DotConnectAfrica</a> | Oct 23, 2012 | Viewed 6,822 times</td></tr><tr><td class="rank">#<strong>3</strong></td><td><a href="http://www.circleid.com/members/4162/"><img src="/images/member_photos/photo_4162.gif" border="0" width="60" alt="Afilias" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20121025_icann_45_new_gtlds_not_far_away_now/" title="ICANN 45: New gTLDs Not Far Away Now" class="title">ICANN 45: New gTLDs Not Far Away Now</a>by <a href="http://www.circleid.com/members/4162/" class="blue">Afilias</a> | Oct 25, 2012 | Viewed 5,676 times</td></tr><tr><td class="rank">#<strong>4</strong></td><td><a href="http://www.circleid.com/members/3844/"><img src="/images/member_photos/photo_3844.gif" border="0" width="60" alt="MarkMonitor" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120124_markmonitor_to_exhibit_at_internet_tech_policy_exhibition/" title="MarkMonitor to Exhibit at Internet Tech Policy Exhibition and Reception to be Held on Capitol Hill" class="title">MarkMonitor to Exhibit at Internet Tech Policy Exhibition and Reception to be Held on Capitol Hill</a>by <a href="http://www.circleid.com/members/3844/" class="blue">MarkMonitor</a> | Jan 24, 2012 | Viewed 5,355 times</td></tr><tr><td class="rank">#<strong>5</strong></td><td><a href="http://www.circleid.com/members/5387/"><img src="/images/member_photos/photo_5387.gif" border="0" width="60" alt="CentralNic" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120730_centralnic_and_regru_confirm_strategic_partnership/" title="CentralNic and REG.RU Confirm Strategic Partnership" class="title">CentralNic and REG.RU Confirm Strategic Partnership</a>by <a href="http://www.circleid.com/members/5387/" class="blue">CentralNic</a> | Jul 30, 2012 | Viewed 5,244 times</td></tr><tr><td class="rank">#<strong>6</strong></td><td><a href="http://www.circleid.com/members/3844/"><img src="/images/member_photos/photo_3844.gif" border="0" width="60" alt="MarkMonitor" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120217_markmonitor_fraud_intelligence_report_q4_2011/" title="MarkMonitor Fraud Intelligence Report, Q4 2011" class="title">MarkMonitor Fraud Intelligence Report, Q4 2011</a>by <a href="http://www.circleid.com/members/3844/" class="blue">MarkMonitor</a> | Feb 17, 2012 | Viewed 5,037 times</td></tr><tr><td class="rank">#<strong>7</strong></td><td><a href="http://www.circleid.com/members/4162/"><img src="/images/member_photos/photo_4162.gif" border="0" width="60" alt="Afilias" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120628_afilias_participates_in_global_test_of_multilingual_idn_email/" title="Afilias Participates in Global Test of Multilingual IDN Email" class="title">Afilias Participates in Global Test of Multilingual IDN Email</a>by <a href="http://www.circleid.com/members/4162/" class="blue">Afilias</a> | Jun 28, 2012 | Viewed 4,857 times</td></tr><tr><td class="rank">#<strong>8</strong></td><td><a href="http://www.circleid.com/members/4117/"><img src="/images/member_photos/photo_4117.gif" border="0" width="60" alt="Nominum" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120430_implementing_cyber_security_code_of_conduct/" title="Implementing a Cyber-Security Code of Conduct: Real-Life Lessons From Australia (Webinar)" class="title">Implementing a Cyber-Security Code of Conduct: Real-Life Lessons From Australia (Webinar)</a>by <a href="http://www.circleid.com/members/4117/" class="blue">Nominum</a> | Apr 30, 2012 | Viewed 4,665 times</td></tr><tr><td class="rank">#<strong>9</strong></td><td><a href="http://www.circleid.com/members/3844/"><img src="/images/member_photos/photo_3844.gif" border="0" width="60" alt="MarkMonitor" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/201209005_top_level_domain_survey_findings_not_surprising_but_concerning/" title="Top-Level Domain Survey Findings Not Surprising, But Still Concerning" class="title">Top-Level Domain Survey Findings Not Surprising, But Still Concerning</a>by <a href="http://www.circleid.com/members/3844/" class="blue">MarkMonitor</a> | Sep 05, 2012 | Viewed 4,509 times</td></tr><tr><td class="rank">#<strong>10</strong></td><td><a href="http://www.circleid.com/members/1858/"><img src="/images/member_photos/photo_1858.gif" border="0" width="60" alt="PIR" /></a></td><td width="100%"><a href="http://www.circleid.com/posts/20120814_public_interest_registry_releases_bi_annual_domain_name_report/" title="Public Interest Registry Releases Results of Bi-Annual Domain Name Report" class="title">Public Interest Registry Releases Results of Bi-Annual Domain Name Report</a>by <a href="http://www.circleid.com/members/1858/" class="blue">PIR</a> | Aug 14, 2012 | Viewed 4,462 times</td></tr></table>
</p>
<p>
Additionally, you can also check the leaderboards for CircleID's overall top 100 <a href="http://www.circleid.com/community/top_100"><strong>community</strong></a> and <a href="http://www.circleid.com/industry/leaderboard/"><strong>industry</strong></a> participants.
</p><p><em>Written by <a href="http://www.circleid.com/members/501/">CircleID Reporter</a></em></p>]]></description>
			<dc:date>2013-01-10T09:34:00-08:00</dc:date>
			<category>internet</category><category>access_providers</category><category>broadband</category><category>censorship</category><category>cloud_computing</category><category>cyberattack</category><category>cybercrime</category><category>ddos</category><category>dns</category><category>dnssec</category><category>domain_names</category><category>registry_services</category><category>icann</category><category>internet_governance</category><category>ip_addressing</category><category>ipv6</category><category>law</category><category>malware</category><category>mobile</category><category>policy_regulation</category><category>privacy</category><category>security</category><category>telecom</category><category>top_level_domains</category><category>web</category>
		</item>
		
	</channel>
</rss>