<?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>Geoff Huston &#45; CircleID</title>
		<link>http://www.circleid.com/</link>
		<description>Postings from Geoff Huston on CircleID</description>
		<dc:language>en</dc:language>
		<dc:rights>Copyright 2008, unless where otherwise noted.</dc:rights>
		<dc:date>2008-06-24T12:13:00-08:00</dc:date>
		

		
		<item>
			<title> The Future of the Internet: A Political View (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/86241_future_of_internet_political_view</guid>
			<link>http://www.circleid.com/posts/86241_future_of_internet_political_view</link>
			<description><![CDATA[Lets face it, gathering a collection of ministerial delegations to laboriously recite prepared speeches to each other sounds about as exciting as watching paint dry. And observing meetings where the major outcome appears to be limited to the scheduling of the next meeting can become somewhat tedious after a while. It should not be surprising that the level of expectation of tangible outcomes for such governmental meetings is invariably abysmally low. So what's the value of adding yet another meeting to governments' schedule? What makes the OECD-hosted ministerial meeting on the Future of the Internet Economy so unique in the context of the Internet's current political landscape and its political future? Why would a meeting about the dismal science of economics hold any interest at all? <a href="http://www.circleid.com/posts/86241_future_of_internet_political_view">More...</a>]]></description>
			<dc:date>2008-06-24T12:13:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The End of End-to-End? (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_end_of_end_to_end</guid>
			<link>http://www.circleid.com/posts/the_end_of_end_to_end</link>
			<description><![CDATA[One of the major principles of the architecture of the Internet was encapsulated in a paper by Saltzer, Reed and Clark, "End-to-End Arguments in System Design". This paper, originally published in 1981, encapsulated very clearly the looming tension between the network and the application: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible." At the time this end-to-end argument was akin to networking heresy! <a href="http://www.circleid.com/posts/the_end_of_end_to_end">More...</a>]]></description>
			<dc:date>2008-04-24T09:27:00-08:00</dc:date>
		</item>
		
		<item>
			<title> IPv6 Deployment: Just Where Are We? (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/ipv6_deployment_where_are_we</guid>
			<link>http://www.circleid.com/posts/ipv6_deployment_where_are_we</link>
			<description><![CDATA[In this article we'd like to look at some measures of the use of IPv4 and IPv6 protocols in today's Internet and see if we can draw any conclusions about just how far down the track we are with the IPv6 part of <a href="http://en.wikipedia.org/wiki/IPv6#Dual_stack">dual stack</a> deployment. We'll use a number of measurements that have been made consistently since 1 January 2004 to the present, where we can distinguish between the relative levels of IPv4 and IPv6 use in various ways. <a href="http://www.circleid.com/posts/ipv6_deployment_where_are_we">More...</a>]]></description>
			<dc:date>2008-03-31T08:42:00-08:00</dc:date>
		</item>
		
		<item>
			<title> DNSSEC: Once More, With Feeling! (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/dnssec_once_more_with_feeling</guid>
			<link>http://www.circleid.com/posts/dnssec_once_more_with_feeling</link>
			<description><![CDATA[After looking at the state of DNSSEC in some detail a little over a year ago in 2006, I've been intending to come back to DNSSEC to see if anything has changed, for better or worse, in the intervening period... To recap, DNSSEC is an approach to adding some "security" into the DNS. The underlying motivation here is that the DNS represents a rather obvious gaping hole in the overall security picture of the Internet, although it is by no means the only rather significant vulnerability in the entire system. One of the more effective methods of a convert attack in this space is to attack at the level of the DNS by inserting fake responses in place of the actual DNS response. <a href="http://www.circleid.com/posts/dnssec_once_more_with_feeling">More...</a>]]></description>
			<dc:date>2007-12-10T08:29:00-08:00</dc:date>
		</item>
		
		<item>
			<title> On the Hunt for "Critical Internet Resources" (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/critical_internet_resources</guid>
			<link>http://www.circleid.com/posts/critical_internet_resources</link>
			<description><![CDATA[I'm writing this column in November, and that means that it is time for the traveling circus known as the <a href="http://www.intgovforum.org">Internet Governance Forum</a> (IGF) to come down to earth, unpack its tents and sell tickets for its annual song and dance routine. The script for this year's show has been changed, and after being excluded from the main arena last year at the Athens gig, the headline act of "Critical Internet Resources" is taking a starring role this year in Rio. Some folk are even saying that it is the single most contentious issue to be scheduled at this year's IGF show. So what are "Critical Internet Resources" anyway? If folks are going to spend all this time, energy and carbon emissions traveling to Rio to talk on this topic, then wouldn't it be helpful to understand what it means in the first place? There are probably a number of ways to answer this question, so in this heavily opinionated column I'd like to look at the range of possible answers to this question. <a href="http://www.circleid.com/posts/critical_internet_resources">More...</a>]]></description>
			<dc:date>2007-11-12T08:51:00-08:00</dc:date>
		</item>
		
		<item>
			<title> NANOGGING (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/710306_nanog_meeting</guid>
			<link>http://www.circleid.com/posts/710306_nanog_meeting</link>
			<description><![CDATA[There are many network operator group meetings being held these days. Even in the backwater of the South Pacific where I live there is now AUSNOG, and NZNOG is just next door in New Zealand. We now have MENOG in the Middle East and AFNOG in Africa. The original NOG was the <a href="http://www.nanog.org/">North American Network Operators Group</a> (NANOG), and they have the T-Shirts to prove it! NANOG meets three times a year, and I attended NANOG 41 in October 2007. NANOG meetings cover a broad variety of topics, from operational tools, measurement, and peering practices through to a commentary on the state of the Internet industry. Here are my impressions of the meeting. <a href="http://www.circleid.com/posts/710306_nanog_meeting">More...</a>]]></description>
			<dc:date>2007-10-30T18:13:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Transition to IPv6 Address (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/transition_to_ipv6_address</guid>
			<link>http://www.circleid.com/posts/transition_to_ipv6_address</link>
			<description><![CDATA[Last month's <a href="http://www.circleid.com/posts/the_end_of_ipv4_world/">column</a> looked at the exhaustion of the IPv4 unallocated address pool and the state of preparedness in the Internet to grapple with this issue... There has been a considerable volume of discussion in various IPv6 and address policy forums across the world about how we should respond to this situation in terms of development of address distribution policies. Is it possible to devise address management policies that might both lessen some of the more harmful potential impacts of this forthcoming hiatus in IPv4 address supply, and also provide some impetus to industry to move in the originally intended direction to transition into an IPv6 network? <a href="http://www.circleid.com/posts/transition_to_ipv6_address">More...</a>]]></description>
			<dc:date>2007-08-01T18:02:00-08:00</dc:date>
		</item>
		
		<item>
			<title> The End of the (IPv4) World is Nigher! (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/the_end_of_ipv4_world</guid>
			<link>http://www.circleid.com/posts/the_end_of_ipv4_world</link>
			<description><![CDATA[Funny how some topics seem sit on a quiet back burner for years, and then all of a sudden become matters of relatively intense attention. Over the past few weeks we've seen a number of pronouncements on the imminent exhaustion of the IP version 4 address pools. Not only have some of the Regional Internet Registries (RIRs) and some national registry bodies made public statements on the topic, we've now seen <a href="http://www.icann.org/minutes/resolutions-29jun07.htm#n">ICANN also make its pronouncement on this topic</a>... Why the sudden uptake of interest in this topic? I suspect that a small part of this may be my fault! <a href="http://www.circleid.com/posts/the_end_of_ipv4_world">More...</a>]]></description>
			<dc:date>2007-07-01T12:57:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Infrastructure ENUM (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/infrastructure_enum</guid>
			<link>http://www.circleid.com/posts/infrastructure_enum</link>
			<description><![CDATA[After much initial fanfare a couple of years ago ENUM has matured to a state where it is currently yet another under-achiever in the technology deployment stakes. ENUM initially presented itself as a very provocative response to the legacy telco position of monopolising public voice services through their exclusive control over the Public Switched Telephone Network (PSTN) and the associated controlling position over the telephone number space... The perception was that ENUM was going to dismantle these levers of control and open up the voice market to a new wave of competitive carriers. If the address plan was the key to the PSTN, then ENUM was intended unlock this network and position the new wave of Voice Over IP (VOIP) carriers to take over any residual treasures of the traditional voice market. Events have not played out according to these expectations... <a href="http://www.circleid.com/posts/infrastructure_enum">More...</a>]]></description>
			<dc:date>2007-04-05T08:45:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Addressing the Future Internet (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/addressing_the_future_internet</guid>
			<link>http://www.circleid.com/posts/addressing_the_future_internet</link>
			<description><![CDATA[What economic and social factors are shaping our future needs and expectations for communications systems? This question was the theme of a joint National Science Foundation (NSF) and Organisation for Economic Co Operation and Development (OECD) workshop, held on the 31st January of this year. The approach taken for this workshop was to assemble a group of technologists, economists, industry, regulatory and political actors and ask each of them to consider a small set of specific questions related to a future Internet. Thankfully, this exercise was not just another search for the next "Killer App", nor a design exercise for IP version 7. It was a valuable opportunity to pause and reflect on some of the sins of omission in today's Internet and ask why, and reflect on some of the unintended consequences of the Internet and ask if they were truly unavoidable consequences... <a href="http://www.circleid.com/posts/addressing_the_future_internet">More...</a>]]></description>
			<dc:date>2007-02-09T14:14:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Internationalizing the Internet (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/internationalizing_the_internet</guid>
			<link>http://www.circleid.com/posts/internationalizing_the_internet</link>
			<description><![CDATA[One topic does not appear to have a compellingly obvious localization solution in the multi-lingual world, and that is the Domain Name System (DNS). The subtle difference here is that the DNS is the glue that binds all users' language symbols together, and performing localized adaptations to suit local language use needs is not enough. What we need is a means to allow all of these language symbols to be used within the same system, or "internationalization". <a href="http://www.circleid.com/posts/internationalizing_the_internet">More...</a>]]></description>
			<dc:date>2006-11-21T12:40:00-08:00</dc:date>
		</item>
		
		<item>
			<title> A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/dnssec_deployment_and_dns_security_extensions</guid>
			<link>http://www.circleid.com/posts/dnssec_deployment_and_dns_security_extensions</link>
			<description><![CDATA[In looking at the general topic of trust and the Internet, one of the more critical parts of the Internet's infrastructure that appears to be a central anchor point of trust is that of the Domain Name Service, or DNS. The mapping of "named" service points to the protocol-level address is a function that every Internet user relies upon, one way or another. The ability to corrupt the operation of the DNS is one of the more effective ways of corrupting the integrity of Internet-based applications and services. If an attacker can in some fashion alter the DNS response then a large set of attack vectors are exposed. ...The more useful question is whether it is possible to strengthen the DNS. The DNS is a query -- response application, and the critical question in terms of strengthening its function is whether it is possible to authenticate the answers provided by the DNS. DNSSEC provides an answer to this question. <a href="http://www.circleid.com/posts/dnssec_deployment_and_dns_security_extensions">More...</a>]]></description>
			<dc:date>2006-08-10T18:35:00-08:00</dc:date>
		</item>
		
		<item>
			<title> ENUM: Mapping the E.164 Number Space into the DNS (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/enum_mapping_e164_into_dns</guid>
			<link>http://www.circleid.com/posts/enum_mapping_e164_into_dns</link>
			<description><![CDATA[Many communications networks are constructed for a single form of communication, and are ill suited to being used for any other form. Although the Internet is also a specialized network in terms of supporting digital communications, its relatively unique flexibility lies in its ability to digitally encode a very diverse set of communications formats, and then support their interaction over the Internet. In this way many communications networks can be mapped into an Internet application and in so doing become just another distributed application overlayed on the Internet. From this admittedly Internet-centric perspective, voice is just another Internet application. And for the growing population of Voice over IP (VoIP) users, this is indeed the case... <a href="http://www.circleid.com/posts/enum_mapping_e164_into_dns">More...</a>]]></description>
			<dc:date>2006-03-30T17:55:00-08:00</dc:date>
		</item>
		
		<item>
			<title> Examining the Reality of Convergence (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/examining_reality_of_convergence</guid>
			<link>http://www.circleid.com/posts/examining_reality_of_convergence</link>
			<description><![CDATA[If there is one word in the telecommunications that has suffered from over-abuse for many years now, it's convergence. The term has been liberally applied to each successive generation of communications technology for their supposed ability to solve a myriad of service delivery problems within a single unifying converged carriage and service delivery solution. Unfortunately, the underlying reality has always been markedly different from these wondrous promises, and we continue to see an industry that deploys a plethora of service delivery platforms and an equally diverse collection of associated switching and service delivery technologies. One can't help but wonder at the collective gullibility of an industry that continues to herald the convergent attributes of each new generation of communications technology, while at the same time being forced to admit that previous convergent promises have never been realized. <a href="http://www.circleid.com/posts/examining_reality_of_convergence">More...</a>]]></description>
			<dc:date>2006-02-21T17:30:00-08:00</dc:date>
		</item>
		
		<item>
			<title> IPv6: Extinction, Evolution or Revolution? (Featured Blog)</title>
			<guid isPermaLink="true">http://www.circleid.com/posts/ipv6_extinction_evolution_or_revolution</guid>
			<link>http://www.circleid.com/posts/ipv6_extinction_evolution_or_revolution</link>
			<description><![CDATA[For some years now the general uptake of IPv6 has appeared to be "just around the corner". Yet the Internet industry has so far failed to pick up and run with this message, and it continues to be strongly reluctant to make any substantial widespread commitment to deploy IPv6. Some carriers are now making some initial moves in terms of migrating their internet infrastructure over to a dual protocol network, but for many others it's a case of still watching and waiting for what they think is the optimum time to make a move. So when should we be deploying IPv6 services? At what point will the business case for IPv6 have a positive bottom line? It's a tough question to answer, and while advice of "sometime, probably sooner than later" is certainly not wrong, it's also entirely unhelpful as well! <a href="http://www.circleid.com/posts/ipv6_extinction_evolution_or_revolution">More...</a>]]></description>
			<dc:date>2006-01-06T16:14:52-08:00</dc:date>
		</item>
		
	</channel>
</rss>