Dan York

Just a guy in Vermont trying to connect all the dots...

Author's posts

How Do We Define ‘SIP’ For Telecom In 2014? (Featured Blog)

More...

Facebook Launches IPv6-Only Data Cluster

If you are a Facebook user and are also interested in using IPv6 wherever possible, Facebook’s Paul Saab just announced yesterday that there is now a special link where you can connect to Facebook’s IPv6-ONLY data cluster. In the IPv6 group on Facebook (of course!) he posted:

Back in March I announced we were working towards having IPv6-only clusters. I’m happy to announce that we’ve successfully launched our latest cluster as IPv6-only. If you want to make sure that you’re using the IPv6-only cluster, we’ve redirected traffic for http://www.v6.facebook.com/ so that it uses it

Just to be 100% clear, you have been able to access Facebook over IPv6 ever since World IPv6 Launch back in 2012 just by going to the regular http://www.facebook.com/ URL.  Users of the IPvFoo/IPvFox browser add-ons have been able to see that we’ve been connecting to Facebook over IPv6.  It’s all worked great.

However, while the connection to the main Facebook page has been over IPv6, that page has also still required some connections over the legacy IPv4 network.

With yesterday’s news from Paul Saab, those of us who want to truly do everything over IPv6 can now do so by connecting to http://www.v6.facebook.com/. Admittedly, this may only be of interest to those of us who are advocates of IPv6, but still, it’s pretty cool to have full access to a major site like Facebook entirely over IPv6!

You may recall that back in March, Paul Saab gave an excellent presentation about how Facebook is moving to entirely using IPv6 within their internal networks.

fb-internal-ipv6

 

His slides are available and you’ll note that on his second to last slide he wrote:

  • Plans for first IPv6 only cluster (no RFC1918) by end of 2014

This news yesterday is the completion of those plans (and well before the end of 2014, too!).

Kudos to Paul and his team at Facebook – it’s great to see this work happening and to have a way we can work with Facebook in pure IPv6-only network. Thanks!

What are you waiting for?  Visit our “Start Here” page to find resources available to help you make the move to IPv6 – and let us know if there is anything more we can do to help you!

US DoD’s DREN Will Only Buy Products With An IPv6 Website

Want a good reason for making sure your website works over IPv6?  How about that some companies and organizations may only consider your products if they can get to your website over IPv6?

In a June 10, 2014, presentation, Ron Broersma explained why the US Department of Defense (DoD) Defense Research and Engineering Network (DREN) adopted a policy for acquiring products/services for the DREN III network where they would only consider products where the company website was available over IPv6 (click/tap image for a larger view):

DREN IPv6 product evaluation

The text of the slide says:

  • Our #1 rule:
    • if we can’t get to the company or product website via IPv6, we won’t consider such products.
  • Why this hard line?
    • we learned the hard way that without strong corporate commitment to IPv6 support, it will take forever to get IPv6 bugs fixed or features added.
    • we learned that the corporate website being IPv6Y-enabled was a good indicator of corporate commitment to IPv6.
    • this has been tested many times, and it works.
    • in the process, we encourage industry to IPv6-enable their public facing services.

It sounds like pretty good logic to me! Having a website available over IPv6 certainly is one way of showing a corporate commitment to the production Internet.

Ron’s full slides are available online which explain more about the DREN III build-out that occurred during 2013 and the acquisition process they used for products and services. As Ron notes on his slide 4, vendors will often say that their products support IPv6 but very often the vendors really don’t have an understanding about IPv6.

There are some other good points in the slides, too, such as where Ron notes on slide 9 their pleasant surprise that the “mainstream” customer premise equipment all seemed to work fine with IPv6.  He also notes that all of their network management takes place over IPv6, with none happening over legacy IPv4. It’s also good to see his “vision”:

DREN is identified as an IPv6 network with IPv4 legacy support.

It is an IPv6 network first, with IPv4 support only to get to legacy systems.  The slides are all well worth a read.

What do you think?  Can you adopt this as a requirement in your product acquisition process?

And is your website available over IPv6?   If not, please consider our steps for content providers / website owners and start making your site available over IPv6 today!

P.S. Hat tip to Phil Benchoff for posting about Ron’s slide in the ‘IPv6 Promotion’ community on Google+ (which is, of course, available over IPv6!)

How Do We Define ‘SIP’ For Telecom In 2014?

Sip question"What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?"

A friend asked me that question and my response was:

It depends.

and even more unfortunately:

I don't know.

It turns out to be a challenging question to answer... and it led me to ask:

  • How do we define what "SIP" is for telecommunications in 2014?
  • How do we help vendors move their products/services to be based on SIP?
  • As we talk about "turning off the PSTN" and "moving all telecom to IP", how can we make it easier for companies to switch to using SIP?

The reality is that being "SIP-compliant" does turn out to depend upon where in the larger SIP interconnection ecosystem the vendor is located.

Is the vendor:

  1. a SIP client, in terms of a "hard" phone, a softphone, or other application that is seeking to connect to a SIP server?
  2. a SIP server seeking to connect to a SIP "service provider" to have connectivity out to the PSTN and other SIP networks?
  3. a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
  4. a middlebox such as a firewall or session border controller (SBC) seeking to be in the middle of a SIP communication stream?
  5. an application that interacts with SIP systems in some way? (ex. call recording, IVR, networking monitoring)

To be "SIP-compliant" really means you need to figure out what amount of "SIP" you need to implement to play your part in the larger picture. Particularly when the SIP "architecture" we describe isn't the pretty little picture we use:

Sip architecture

but rather a much more complex reality:

Sip architecture reality

Unfortunately, the "Session Initiation Protocol" (SIP) is no longer just good old RFC 3261 and a few friends. RFC 3261 provided a radical new way to do telecommunications... it was "HTTP for voice"... it was simple, easy and pretty amazing. If you have a moment, go back and read RFC 3261. It's a remarkable document and set of ideas.

However, there were two factors that started to complicate "SIP":

  • the "Internet" community kept thinking of new and innovative ways that they could do more with SIP-based telecommunications; and
  • the traditional telecom companies/vendors kept wanting to bring across more and more legacy PSTN functionality into the world of SIP, typically without changing that PSTN functionality so that they wouldn't have to change their business models or processes.

This combination set SIP up to slowly become more and more of an accretion of various hacks and kludges designed to either enable SIP to unleash new possibilities and/or to take over key functionality from the PSTN.

But in doing so it became so much harder to define what "SIP" was.

Back around 2008/2009, Jonathan Rosenberg tried with his "Hitchiker's Guide to SIP" that was published as RFC 5411 in February 2009:

http://tools.ietf.org/html/rfc5411

Now consider that this contained about 26 pages worth of documents to be referenced... and this was back in 2009! In the 5 years since, the "Realtime Applications and Infrastructure (RAI)" area of the IETF has been extremely busy and a similar document today would be be MUCH longer.

But does such a long list really help?

Going back to to my list of different roles within the SIP ecosystem, do we need more narrower lists for each role? A SIP client connecting to an IP-PBX may not need to implement all of the same specifications as a SIP service provider connecting to the PSTN.

What is the minimum set of SIP specifications for each role?

SIPconnect sipforumThe good news is that for the second role I mention, the SIP server to SIP service provider, the SIP Forum has done some outstanding work with their SIPconnect initiative. You can find more info at:

http://www.sipforum.org/sipconnect

You can download the SIPconnect 1.1 technical specification and see the great amount of work they have done. The idea is that ultimately any "SIPconnect-compliant" IP-PBX or other SIP server can connect to any "SIPconnect-compliant" SIP service provider. It should "just work" with a minimum amount of testing. The goal is to allow the more rapid deployment of SIP-based IP-PBXs and making this part of the interconnection puzzle work that much better.

So if you are a vendor of a SIP server, whether you call it an IP-PBX, a call server, or whatever... or you are a SIP service provider seeking to connect to SIP servers at your customers - in either case you have SIPconnect that you can use to be "SIP-compliant".

But what about the other roles?

What if a vendor has multiple products?

What if a service provider or enterprise is just trying to get "SIP" products to work together? What should they specify beyond the vague statement that a product should support "SIP"?

Now, there are other organizations that have attempted to answer this question. The 3GPP has a list of SIP specifications and the GSMA seems to have similar documents. The ITU-T has many recommendations but since they rename everything it's hard to understand what really links back to SIP - and many of the ITU recommendations are only available to members and so you can't easily view them.

Which brings me back to these questions:

  • Do we need a new IETF document that aims to update RFC 5411 with a newer list and perhaps "profiles" of what would be needed for different roles?
  • Is this something the SIP Forum or some other organization should take on?
  • Has someone else already created a concise list/document/specification and I just haven't yet found it?

And perhaps the even larger question:

  • Do you believe this is an issue that we collectively should be working on as an industry to help make the deployment of SIP easier?

What do you think? How do we define SIP in 2014? What should we do? I'd love to hear your comments either in response to this post here on this blog or out on social media where this is posted. (Thanks!)


An audio commentary on this post is also available:


If you found this post interesting or useful, please consider either:


TDYR #174 – How Do We Define ‘SIP’ For Telecom In 2014

How do we define what it is to be "SIP-compliant" in 2014? Can we even do so? How can we make it easier for companies and vendors to make their systems work with SIP?

TDYR #173 – Apple’s iPhone6 and AppleWatch: Some Initial Thoughts

Some initial thoughts on today's Apple event where the iPhone 6 and AppleWatch were announced...

Any Ideas For A Better Color Scheme For Our DNSSEC Deployment Maps?

Do any of you have any suggestions for a better palette of colors for us to use for our DNSSEC deployment maps?  We generate them every Monday morning and send them out to a public mailing list (to which any of you are welcome to subscribe).  Here is a recent global view (click/tap to see larger image):

2014-09-02-2014-09-02

My issue (and maybe this is just me) is that I’m not entirely fond of the colors used in the “early” stages of a TLD’s deployment.  As we note on the deployment maps page, we track a TLD through five stages of DNSSEC deployment:

  • Experimental – Internal experimentation announced or observed
  • Announced – Public commitment to deploy
  • Partial – Zone is signed but not in operation (no DS in root)
  • DS in Root – Zone is signed and its DS has been published
  • Operational – Accepting signed delegations and DS in root

The most important states are the final two when DNSSEC for the TLD is “working”.  I like the existing green colors for those two states, although the “DS in Root” green is perhaps a bit brighter than I would want.  The point is that we want to use green to show the “good” states of DNSSEC deployment – and over time we’d like to see the whole map go to that darker shade of green.

It is the first three states that bother me a bit.  There is a progression between those three states as it often goes like this:

  • Someone from a TLD says at a conference or on a mailing list that they are experimenting with DNSSEC.  We can then flag them as “Experimental”.
  • Perhaps next someone from that TLD issues a formal statement, publishes a blog post or these days sends out a tweet or posts another social media update saying that they are going to deploy DNSSEC.  We can then flag them as “Announced”.
  • Then at some point the TLD’s zone is actually signed with DNSSEC, but the DS key hasn’t been uploaded to the root.  Now we can put them as “Partial” in the database.

In my ideal world I’d have some color progression that shows the movement along this path.  The orange, yellow and blue we currently use don’t really show a progression.   I’ve tried using different shades of yellow or orange but you also want it to be easy to determine what state a given TLD is in – and for that the current set of colors does work.

Anyway… if anyone has ideas I’d be open to hearing them.  The software we’re using can set the colors to be any of the typical hex-encoded colors used in web pages.  It can’t do shading or lines or anything like that, just colors.

Please feel free to leave suggestions here – or contact me directly at york@isoc.org.  Thanks!

P.S. And if you would like to help get more domains signed with DNSSEC, please see our “Start Here” page to find resources targeted at your type of organization!

Watch ION Belfast Live TODAY To Learn About IPv6, DNSSEC, BGP and more

ION Belfast LogoWant to learn the current state of IPv6 deployment? DNSSEC? Securing BGP and more? If so you can watch LIVE today our ION Belfast event at:

http://uknof.bogons.net/uknof29.html

Today’s ION agenda begins at 1:45 pm British Summer Time (UTC+1) and is packed with information about our topics. Sessions include:

  • Two Years After World IPv6 Launch: Are We There Yet?
  • Why Implement DNSSEC?
  • IPv6 Success Stories – Network Operators Tell All!
  • IETF Update
  • Panel: Routing Around Catastrophe
  • Securing BGP

There are an outstanding set of speakers and we’re very excited to hear their sessions and the conversations that will emerge out of them.

All the sessions will be streamed live and will be recorded for later posting on our Deploy360 YouTube channel.

Please join us as it should be a great event!

NOTE: As we mentioned yesterday, there are also what look to be some excellent sessions happening in the morning UK time as part of the UKNOF agenda.  In particular, these two sessions should be of interest to those concerned about IPv6:

  • 11:30 BST – What went wrong with IPv6?
  • 12:00 BST – IPV6-only Data Centres: What happens when you turn off IPv4

They, too, will be webcast on the same live stream link and will be recorded for later viewing.

Again, it should be an outstanding day at the combined UKNOF / ION Belfast event – we do hope you will join us!

P.S. And if you are motivated to deploy these technologies such as IPv6 and DNSSEC, please visit our Start Here page to find resources to help you get started!

Watch ION Belfast / UKNOF Live Tuesday, Sept 9, for IPv6, DNSSEC, BGP Security and More (Featured Blog)

On Tuesday, September 9, 2014, you have a great opportunity to watch live a very packed agenda full of great sessions about IPv6, DNSSEC, routing/BGP security and other components of Internet infrastructure streaming out of the UKNOF / ION Belfast event in Belfast, UK. All of the sessions can be seen live. More...

Watch ION Belfast / UKNOF Live Tuesday, Sept 9, for IPv6, DNSSEC, BGP, (Featured Blog)

More...