Are you looking to learn what IPv6 is all about? Would you like to understand the basics of how IPv6 addresses work? If so, the 6Deploy project has put some great video tutorials online at:
As we mention on our resource page about the training, the seven sections of the course cover the basics of IPv6, the construction of IPv6 addresses and headers, security issues, mobility/routing issues and suggestions for co-existence with IPv4. If you have a few minutes to watch these videos, you may find them a quick way to start your learning about IPv6:
A couple of points in the article are worth calling out. First, they encountered an issue with the immaturity of some IPv6 code:
We found a reference leak in the IPv6 code that wasn’t apparent until you had processed 2^32 packets. Once this counter rolled over it would free active memory and cause the panic. Because we process large amounts of traffic we noticed this almost immediately.
These are the type of “growing pains” that we should expect to see as more and more production services move over into IPv6. Much of the IPv6-related code out there has been developed and extensively tested… but not necessarily in all the cases that actual production usage will expose.
Their rollout strategy was also interesting, in that it provided them a way to slowly ease into providing full deployment with an easy way to revert should a problem arise:
Our DNS provider enables us to resolve hostnames based on the geo-location of the caller. We used this during testing and rollout of IPv6 by starting with a specific geographic region and then expanding. We started with the state of California and monitored metrics for requests coming to us via IPv4 vs. IPv6. We specifically looked for any significant dips in IPv4 traffic that wasn’t accounted for in new IPv6 traffic. In addition, we watched to see if requests arriving via IPv6 were failing in similar or different ways than those via IPv4.
As they note in the post, this DNS-based solution didn’t work perfectly, but it worked well enough for them to be able to accomplish a successful rollout.
The end result is that per at least one study they now have the second largest domain taking IPv6 traffic!
Congratulations to the entire Netflix team – and thank you, too, for providing this technical report!
Via a tweet from the ICANN DNS Ops team this morning, we were reminded that it was two years ago this week when the root zone of DNS was signed with DNSSEC and we could start validating the global “chain of trust” from the very beginning of the DNS tree.
June 16, 2010 – First key signing ceremony at the ICANN data center in Culpeper, Virginia.
July 12, 2010 – Second key signing ceremony at the ICANN data center in El Segundo, California.
July 15, 2010 – The signed root zone was publicly available.
Once the signed root zone was published on July 15, 2010, it made possible all the DNSSEC validation and usage that we are able to do today using the full global chain of trust.
For those interested in what was happening behind the scenes and the intense amount of security put in place around the key ceremonies, the annotated scripts for Ceremony 1 (June 16) and Ceremony 2 (July 12) make for an interesting view into the process. The “script exceptions” at the end of each document, in particular, show the human side of the process and that even with the best of preparations sometimes things go wrong. All in all a rather complete and interesting process.
Last week the US Federal CIO Council released an updated version of their IPv6 planning guide/roadmap. Available as a PDF download from cio.gov, the 73-page document provides a wealth of IPv6 information to both US government agencies and also to operators, enterprises and others seeking to understand exactly what the US government is doing with IPv6.
This July 2012 document updates and replaces the 2009 version of the roadmap. It does not specifically list what has been updated, but provides this note:
This document is the latest version of the Roadmap, and is the key guidance document for supporting Federal agencies in their achievement of the 2012 and 2014 objectives, as well as the strategic vision for beyond 2014. This document has the same foundational elements instituted in the original Roadmap, and has been updated to reflect the three years of experience (from both the public and private sectors) since original publication. The sections of the document comprise all aspects of a successful transition and now include practical experience from those directly engaged in IPv6 activities, combining programmatic (including Clinger-Cohen Act compliance), technical, cybersecurity, and Federal acquisition elements, as well as the suggested interactions with other Federally mandated technical efforts such as the Trusted Internet Connection (TIC).
True to that statement, updated references can be found throughout the document. I found it particularly interesting to see section 1.4, “Our Business Situation,” at the beginning of the document that provided a list from a competitive point of view of what other countries around the world are doing with regard to IPv6.
The sample transition timelines starting at the bottom of page 12 may be of interest to many readers, as they lay out examples of how agencies can meet upcoming September 2012 and September 2014 deadlines. Section 4 on page 22 also outlines where US federal agencies should be in 2012 and 2014.
Readers may also find Section 6 on page 32 very useful with the ideas for transition steps. Obviously, some steps are specific to US government agencies, but the ideas behind those steps could be equally useful in other context.
All in all a very useful document for US government agencies and for others seeking to understand what a large entity needs to do to make the transition.
Are you planning to start using DNSSEC with your domain – and are you planning to start signing your domain yourself? In other words, are you going to be doing all the signing on your own server and/or in your own facilities? (Versus using a service at a DNS hosting provider that does all the DNSSEC-signing for you.)
If you are, then a good place to start your planning is with the creation of what is called a “DNSSEC Practice Statement” or more simply a “DPS”. A DPS is a document that outlines how you are implementing DNSSEC for your domain – and what security measures you are putting in place.
Basically, it is a statement that can help other people understand whether they can trust the security you put in place.
Typically the DPS documents created so far are for Top-Level Domains (TLDs) as they have been the focus of much of the DNSSEC deployment efforts to date. For second-level domains, very often you may be able to use the services of your DNS hosting provider to sign your domains and so a full DPS may not be needed. But if you sign your own domain, a DPS can be a useful way to plan out the security for your signing.
Regardless of what you do, the existing DPS documents make for great reading to help you understand the security you may or may not need to put in place to ensure the security and integrity of our DNSSEC operations.
The place to begin for many of you may be to take a look at this Internet-Draft that explains the rationale for creating a DPS and provides a sample framework:
In particular you may want to start with the “.SE” DPS as the folks from .SE have been very involved with creating the entire DPS framework. As you look through the examples, you’ll see a variety of different styles and lengths, from the very simple to the very complex.
If you have 15 minutes to spare, this video from 2010 offers Anne-Marie Eklund-Löwinder from .SE explaining the value of a DPS and what should be included:
The important aspect of a DNSSEC Practice Statement is to capture in one document how you are implementing DNSSEC and how you are securing the tools, servers and other components involved with DNSSEC. Even if you are an enterprise who might never publicly publish a DPS, writing such a document can be a very useful exercise to ensure you are planning for all the necessary aspects of using DNSSEC to sign your domain.
P.S. If you create and publish a DPS, we’re always looking for more examples to add to our DPS page. Please let us know where your DPS is located online so that we can consider adding it to the page.
As we’ve mentioned previously, today is the last day to let your voice be heard in the 3rd annual “IPv6 Deployment Monitoring Survey” on the current and future use of IPv6. The survey is at:
It will take just a few minutes and will go far in helping the the Number Resource Organization (NRO) (an umbrella organization for the 5 Regional Internet Registries) understand how the Internet community is moving toward widespread adoption of IPv6.
If you have IPv6 deployed in your network and can spare those few minutes, it will help all of us!
Are you responsible for signing your domain with DNSSEC are are looking to understand more of what may be involved? Are you perhaps with registry or top-level domain (TLD) operator looking to implement DNSSEC across your country-code TLD (ccTLD) or new generic TLD (gTLD)? Or are you with an enterprise seeking to understand the legal and security policies you should have in place if you are signing your own domains?
If so, a great place to start is with the idea of a “DNSSEC Practice Statement” or “DPS.” A DPS is a document that simply lays out the policies and procedures related to DNSSEC that an organization chooses to implement. It may be very short and simple – or very long and complex. The idea is that a DPS can give other people an understanding of how much they can trust your DNSSEC signing. For someone new to DNSSEC, looking at existing DPS documents can also provide a clear checklist of what you should be thinking about during your implementation.
The best way to get started may be to look at an Internet-Draft titled “A Framework for DNSSEC Policies and DNSSEC Practice Statements”
This document explains the rationale for a DPS and provides a framework for creating your own.
Alternatively, you may just want to dive into the list of DPS documents below to get an understanding of what these documents are like. The .SE DPS may be a good place to start, primarily because the .SE team are very involved with the Internet-Draft framework document referenced above.
If you prefer to learn from a video, we have included at the end of this page a 15-minute video from training given by the OpenDNSSEC project in April 2010 where Anne-Marie Eklund-Löwinder from .SE explains the value of a DPS and the components that should be included.
A few notes about the lists below:
The lists contain the gTLDs, ccTLDS and RIRs for whom we can find formal DPS documents. Some of the gTLDs, ccTLDs and RIRs who do use DNSSEC are not listed because their domains/zones were signed very early in the DNSSEC rollout before the DPS framework started to become widely used. They may have other DNSSEC deployment information on their sites, but not in the form of a formal DPS.
The root of DNS also has multiple DPS documents but they are not explicitly listed below as the root zone is a special case with special precautions. You may find the documents to be an interesting read, though.
You will note in the list below that the DPS documents have several different names, but newer documents seem to be standardizing on “DNSSEC Practice Statement.”
These lists will continue to be updated as more DPS documents become available. Expect to see them continue to grow as more TLDs sign their domains.
If you are aware of a DPS document we should include, please let us know.
I first experimented with Involver a year or two ago when I was trying to add some interactivity to a Facebook Page for my previous employer. Involver had some useful options and while the fit wasn't there with what I wanted to do, I did keep monitoring how they were evolving.
Time will tell if the pieces do all fit nicely together, but in the meantime Oracle is clearly looking to be a player in helping enterprises connect with their customers over social channels.
Congrats to the Involver team and I do hope this all works out well for them - and for their customers.
What is an "over-the-top" or "OTT" application or service? How does an OTT telecommunications or media app/service differ from a "regular" application?
The answer depends upon your perspective.
For a regular user of the Internet, an "OTT app or service" is something like:
YouTube, Hulu, Netflix or Apple TV for streaming video
Skype or Facetime for voice/video calls
WhatsApp or iMessage for messages on a mobile device
Xbox 360 or World of Warcraft for gaming
Basically, any service you are receiving over the Internet that is NOT provided directly by your Internet Service Provider (ISP).
Of course, for an ISP / telecommunication provider, the critical point about an OTT app/service is the part I emphasized - it is NOT a service you are paying them for.
And they are not happy about this.
It's not clear to me when precisely we in the industry started talking about "over-the-top" applications and services, but I first saw OTT mentioned back in 2008 or 2009 when the term was primarily applied to video services such as those coming from Netflix or Hulu. At the time, major US service providers such as Comcast and AT&T were rolling out their video-on-demand services and were being challenged by these "OTT" providers. Netflix and Hulu provided their service "over-the-top" of your Internet connection, without any interaction whatsoever with your Internet service provider (nor any revenue to that service provider).
Since that time, I've seen "OTT" applied to the zillions of messaging apps that have now sprouted up in the mobile environment to provide an alternative to the costly SMS provided by the traditional telcos. WhatsApp, Apple's iMessage, Blackberry Messenger (BBM), TU Me... and a hundred others that keep popping up on a weekly basis. Some would even lump Twitter and Facebook into this category. (And SMS revenue by telcos are facing a serious decline from the use of these apps. Ovum estimated the decline at $13.9 billon for 2011.)
Recently I saw a document that painted "OTT" even more broadly as a term applying to any "content provider" on the Internet, i.e. basically everyone publishing content in any form.
The key point of all of this is that the OTT apps/services do not come from the traditional telcos or Internet service providers.
The telcos and ISPs are merely providers of the IP connectivity. The OTT apps ride on top of that Internet connection.
The telcos and ISPs are simply big, fat, dumb pipes.
Some of the telcos and ISPs out there are smart enough to see what's going on and are trying to become the biggest, fattest pipe out there and provide the best possible service. Some are launching their own OTT apps/service that are NOT limited to their own customer base.
And some of the telcos are so desperate to hold on to their legacy business models that they are trying to get the International Telecommunication Union (ITU) to regulate OTT apps and service providers through the upcoming World Conference on International Telecommunications (WCIT). They are hoping to use WCIT as a vehicle to re-inject themselves into the revenue stream and somehow start charging "OTT" providers. (But that's a topic for another blog post...)
So when you hear people talking about "OTT apps" or "OTT services," they are typically referring to applications or services that ride on top of your Internet connection - but have no relationship with the provider of your Internet connection.
OTT apps and services are a major component of the ongoing war between "content providers" and "access providers"... a fundamental tension within the Internet that shows no sign of being resolved anytime soon. But more on that another time... :-)
If you found this post interesting or useful, please consider either:
Why should radio and television broadcasters care about IPv6? What potential impact will IPv6 have on broadcasting? How can broadcasters get started learning more about IPv6?
As a broadcaster, if you are providing content to the Internet, IPv6 migration should be considered to enable providing the best Quality of Experience (QoE) to a growing IPv6 content consumer audience without the use of translation schemes. Carriers and Internet service providers utilize translation devices to provide mixed IPv4 and IPv6 interoperability. The various translation schemes are suitable for TCP based applications such as email and web surfing, but can be detrimental to UDP based real-time media used by the broadcaster. In order to provide the best QoE, broadcasters should strive to provide their media content in a native format to IPv6 only users without the need for translation in addition to providing content to the legacy IPv4 users.
Any number of panelists at recent IPv6-related events have discussed the fact that IPv4-to-IPv6 translation services – as well as techniques like carrier-grade-NAT (CGN) to prolong IPv4 usage – introduce latency into the network connection and can degrade the user experience for real-time communications, including streaming media. Making your media available over IPv6 will ensure viewers can see it in the best possible fashion.
Google’s already leading the way with YouTube. Netflix is now offering streaming over IPv6. They will ensure their content is available to users regardless of whether they are on IPv6 or IPv4.
So with that, it’s rather important that other broadcasters understand how they, too, can make their content accessible over IPv6.
This webinar sounds like a great start and we look forward to seeing more broadcasters offering their content over IPv6.
