IP Convergence: Beyond VoIP, Beyond Cost Savings

In response to the article How Feds are dropping the ball on IPv6 over at Network World, Rich Fisk writes:

Quoted from http://blogs.globalcrossing.com/ipv6-eternal-wait-pt2#comment-928
I just attended the Network World Live Road show here in DC and the chairman of ARIN seemed to have an opposing view to the [statement] that you made in NW.

1. Somewhere in 2010 the IP address space will run out as emerging markets grow.

2. His organization is telling ISP to make plans for IPv6 as there will be a day soon where ARIN will not be handing out more IPv4 space.

3. After #2 happens (no pun intended) there will be the beginnings of two Internets. One IPv4 and one IPv6. While all sites will be reachable with IPv4 clients at first there will come a time where there will be IPv6 only sites.

Yes, we know that IPv4 address will run very low some day, but the sky has been falling for 12, maybe 13 years now.  People are tired of hearing it, in large part because you can still get IPv4 address space today.  Even if an organization starts to run low on addresses they can resort to NAT and RFC1918 (private address space, e.g. 10.x.x.x).  

The way I see it, getting denied for a new IPv4 address and being given an IPv6 address block may be the only catalyst for IPv6 deployment in the LAN.  Early IPv6 deployments in the LAN that are forced due to unavailability of IPv4 addresses only will employ a NAT with external IPv4 addresses (or address), but they will function more or less identically as the use of RFC1918 space would.  IT Network Managers will have decide if they go with an IPv6 implementation over the more familiar private address space.  They will have to use a NAT, because they are going to get stuck in this situation long before the Internetv6 is here.

As of today, finding popular sites that have deployed v6 to their web sites is extremely rare.  I did a little experiment with top of mind web sites.  As one would hope, ipv6.org resovles to an IPv6 address.  From there, I had a little more trouble.  By the way,"traceroute6: Non-recoverable failure in name resolution" means that no AAAA record was found, or in laymans terms, the site is NOT IPv6 ready.  The results are below.

dsiegel@terra:~ >traceroute6 www.ipv6.org
traceroute6 to shake.stacken.kth.se (2001:6b0:1:ea:202:a5ff:fecd:13a6) from 2001:450:1:1001::1e, 64 hops max, 12 byte packets
 1  2001:450:1:1001::1d  39.711 ms  39.317 ms  40.010 ms
 2  sl-bb1v6-rly-t-96.sprintv6.net  113.674 ms  113.480 ms  113.673 ms
 3  sl-bb1v6-nyc-t-1000.sprintv6.net  126.309 ms  126.216 ms  126.633 ms
 4  sl-bb1v6-sto-t-102.sprintv6.net  218.384 ms  215.206 ms  214.051 ms
 5  2001:7f8:d:fb::24  342.243 ms  342.473 ms  342.180 ms
 6  se-tug.nordu.net  343.023 ms  341.761 ms  341.059 ms
 7  c2sth-so-6-0-0.sunet.se  342.812 ms  343.377 ms  344.655 ms
 8  2001:6b0:dead:beef:2::2c6  342.023 ms  342.605 ms  341.990 ms
 9  2001:6b0:1:1200::1  342.148 ms  342.206 ms  343.006 ms
10  clubroom-gw.stacken.kth.se  342.221 ms  342.900 ms  342.158 ms
11  igloo.stacken.kth.se  342.637 ms  344.114 ms  343.147 ms

dsiegel@terra:~ >traceroute6 www.google.com
traceroute6: Non-recoverable failure in name resolution

dsiegel@terra:~ >traceroute6 www.yahoo.com
traceroute6: Non-recoverable failure in name resolution

dsiegel@terra:~ >traceroute6 www.ask.com
traceroute6: hostname nor servname provided, or not known

dsiegel@terra:~ >traceroute6 www.msn.com
traceroute6: Non-recoverable failure in name resolution

dsiegel@terra:~ >traceroute6 www.globalcrossing.com
traceroute6: hostname nor servname provided, or not known

dsiegel@terra:~ >traceroute6 www.verio.net
traceroute6: hostname nor servname provided, or not known

dsiegel@terra:~ >traceroute6 www.sprint.net
traceroute6: hostname nor servname provided, or not known

dsiegel@terra:~ >traceroute6 www.att.net
traceroute6: hostname nor servname provided, or not known

dsiegel@terra:~ >traceroute6 www.sprintv6.net
traceroute6 to www.sprintv6.net (2001:440:1239:4::2) from 2001:450:1:1001::1e, 64 hops max, 12 byte packets
1 2001:450:1:1001::1d 40.637 ms 41.133 ms 41.545 ms
2 sl-bb1v6-rly-t-96.sprintv6.net 113.473 ms 113.064 ms 112.476 ms
3 sl-bb1v6-nyc-t-1000.sprintv6.net 125.839 ms 125.544 ms 126.679 ms
4 sl-s1v6-nyc-t-1004.sprintv6.net 127.108 ms 132.845 ms 128.818 ms
5 www.sprintv6.net 127.799 ms 127.502 ms 127.634 ms



Good going Sprint!  You win a prize! Granted, it's not their main corporate web site and it does little more than check if you are v6 enabled and give you some helpful v6 related links, so it's not a true datapoint for an ordinary site.

In reality, I think that there will be a gap between #2 and #3, or when we run out of IPv4 addresses to assign and when all web sites and other servers have both IPv4 and IPv6 addresses.  Enterprises will deploy NAT to maintain connectivity to the Internetv4 rather than contact every web site admin to request they enable for IPv6, and the Federal networks will satisfy the mandate by being able to run IPv6 rather than take the giant step of actually turning off IPv4.  That, my friends, is the path of least resistance.

Imagine starting your car and seeing that message on your dash.

If this happens, it's not outside of the realm of possibility.  BMW labs is experimenting with the use of IP sub-systems for internal communications, which is a pretty interesting idea!  One of the draw backs of using standard protocols and components is the availability of knowledge around said commonly available technology, but IP can be secured pretty well, so if it's done properly hacking shouldn't be a big concern. 

The author didn't mention the possibility for 3rd party after market add-ons, but one would think they'd be possible if the car has IP packets flowing through it's veins, but then that would reopen the possibility of security threats too, so it might be in BMW's best interest to try and prevent any sort of external tampering with the system.

I think the author of the article is a little confused about IPv6, though.  He says:

Costs drop because fewer specialized components are needed, and the new
version of IPv6 is even better than the more than fine performance from
IPv4.

I would love to know how the new version of IP is even better than the performance of IPv4, especially given that it doesn't perform as well as IPv4, which I noted in a previous post.  In some discussions with members of the IT community from various government agencies, they are leery of deploying IPv6 for security reasons (not because of known issues but more because of the unknown issues that have yet to be discovered because IPv6 is not widely adopted yet).  As a result of these factors as well as overall adoption rate, IPv6 support might actually cost a bit more than IPv4 for several more years.

Despite the erroneous implication of improved performance, if this just a proof of concept and 3rd party after-market add-ons are not a priority, why not design it around IPv6?  IPv6 might even help insure that the system stays a somewhat closed
one...or it might be the killer app that drives further development and
investment in IPv6.  Furthermore, you could do crazy stuff like putting an RFID tag on every nut and bolt in the car, build an RFID-to-IPv6 proxy server, ping every last component on the car, and triangulate their position to make sure they're all where they are supposed to be.  Then when your mechanic ends up with those extra parts and throws them to the side like he did before, you can run the diagnostic before leaving the shop and call him on it.

Better make sure there's an on-board DNS system too, just so we don't have to see the following error message 'Communication Failed with device 2001:450:1999:900:0:670:1708:1920'.  :-)

posted by Dave Siegel

This video came from the RIPE 55 conference.  Gary Feldman of Demon Internet fame performs for the secret-wg in the closing plenary at RIPE 55 in Amsterdam, October 2007.  

For those not knowing what RIPE is - from www.ripe.com - "The RIPE NCC is an independent, not-for-profit membership organisation that supports the infrastructure of the Internet through technical co-ordination in its service region. The most prominent activity of the RIPE NCC is to act as the Regional Internet Registry (RIR) providing global Internet resources and related services (IPv4, IPv6 and AS Number resources) to members in the RIPE NCC service region. The membership consists mainly of Internet Service Providers (ISPs), telecommunication organisations and large corporations located in Europe, the Middle East and parts of Central Asia."

Video here...

Adam "voiploser" Uzelac
DISCLAIMER: The comments here are mine only. They don't necessarily reflect intelligence, refined thoughts, or anything that the reader should take too seriously. Should the reader expect a polished thought process in the content addressed here, then a strong dose of medication should be prescribed to address that misconception.

Very surprised on an article today that China has deployed a dual stack IPv4/IPv6 internet linking Chinese educational institutions to high tech companies.

Also very excited as to what this event will mean to the Global Internet.

Chinese manufacturing has evolved to producing low cost with quality and performance, this capability and the recent annoucement in deploying a Chinese made dual stack internet will place market pressures on both Cisco and Juniper.

These market pressures should produce accelerated deployments at lowered costs.

Increased competition is good for the market, good for the internet and very good for Enterprises Globally!

UPDATE - Both Cisco and Juniper support dual stack, however the size of this Chinese deployment with the opportunity of providing lower price network elements is somethiing we all should take note.

Today the internet is largely defined by a protocol called IPv4 , the forth version of IP and the 1st that was widely deployed.

IPv4 uses 32 bits of binary information to represent a unique IP address, which equals a maximum value of (2 to the power of 32) or just over 4 billion (actually 4,294,967,295).

Compared to IPv4 predecessor’s of using 16 bits of binary information to represent a unique IP address, which equals a maximum value of (2 to the power of 16) or 65,535.

Doubling the amount of bits for an IP address from 16 to 32 resulted in an increase of 5 orders of magnitude.

IPv6 uses 128 bits of binary information to represent a unique IP address, which equals a maximum value of (2 to the power of 128 ) or 340-undecillion or 3.4E38 billion (actually 340,282,366,920,938,000,000,000,000,000,000,000,000 this number is larger than the number of stars that are known to astronomer’s today!!).

Increasing the amount of bits for an IP address from 32 to 128 results in an increase of 29 orders of magnitude against the current maximum in IPv4 of just over 4 billion.

The number 4 billion is quite large considering the world’s population is just over 6 billion , so what is all of the fuss about?

Well, today’s internet relies on a number Request For Comment (RFCs) that help manage a demand that could be larger than the actual size of the number of available IP addresses, such as:
- RFC 1918 defines a group of IPv4 addresses that are consider private and not routable over the internet such as 10.x.x.x , 192.168.x.x or 172.16.0.0 with a netmask of 172.31.255.255.

- RFC 1613 defines the process, terminology and consideration of using Network Address Translation (NAT) that helps manage mapping of an IP address to many (or vise versa). NAT is very useful within an Enterprise that uses RFC 1918 (private non-routable internet addresses).

- RFC 2131 defining the protocol and process by which an IP end point (either public or private) can request a temporary IP address known as DHCP. This grew out of dial-up internet where users needed an IP address only for that specific session.

Although there are a number of RFCs that help us manage the current IPv4 pool of addresses across the internet or within an intranet, they create complexity and will not address the forecasted demand of adding converged services and devices needing IP addresses to just about everything.

What does this mean to you?
- Consider the increased deployment of VoIP, both RFC 1918 and RFC 1613 increase the complexity and reliability of reaching a VoIP end point as it moves from network to network.

- An end point that understands a IPv4 address (32 bit) will not understand a IPv6 address, the IPv4 end point doesn’t have enough fingers and toes to count.

- But an end point that understands a IPv6 address (128 bit) will understand a IPv4 address.

- That the number of available unique addresses in IPv6 will last , at least, our life time and our children's – unless we start assigning a IPv6 address to each star.

It’s a fact the it will take sometime for IPv6 to become as largely deployed as it’s predecessor IPv4, however during this transition it’s important to look at a network provider that can provide dual stack support on internet access so that the access router understands both IPv4 and IPv6 addressing.

I was so busy completing tasks that I couldn't finish this week's articles before leaving for Nova Scotia.

I'll be away on Holiday with new material starting the week of July 31st.

We'll be discussing 2 very cool topics:
1. Storage using IP as a transport, business applications and the need for application awareness within your network infrastructure.

2. Practical IPv6 features.

Looking forward to a 6 day adventure Biking the Seaside and Lighthouses In Nova Scotia .

Good break from this heat wave with temperatures at a comfortable 72F.

Be safe!!

Technorati Profile

In this comment on one of my earlier blogs on IPv6, the person directed me to a blog by Todd Underwood, who recently spoke at the TelecomNEXT show.  His blog is worth a read, and I would draw your attention to the presentation he gave at TelecomNEXT.

It's no wonder that it caused a great stir, babbling all this nonsense that IPv6 would never be deployed and that organizations would be better off for ignoring it.  His presentation makes some great points, however, and I think drawing the conclusion that maybe you shouldn't be concerned about IPv6 for a while is quite valid.

So, when should you worry about deploying IPv6?  The latest statistical analysis from Geoff Huston estimates some time around 2013 we will run out of addresses in the unused pool, and through returns and other trading of IP addresses (black market for IPv4 space?) we could get along until 2023.  These results were corroborated by the guys at JPNIC, Japans IP allocation office, in this article at ipv6style.

I did some of my own searching on IPv6 deployment, it's obvious to me that the existing IPv6 deployment is SMALL.

How do you know the IPv6 deployment is so small, Dave?  Well sir, the fact that you can build a map of it that doesn't look like a large ink blot would be your first clue!  Granted, you're not going to be able to read any of the text because the font is too small, but that's probably just a gimmick to make your little space in the IPv6-verse feel small in comparison to the rest.

There is this one little issue that Todd speaks to that really grabbed my attention.  Todd suggests that we should get to work on a better next generation protocol right away, one that is backward compatible with IPv4 for starters.  I don't think this is realistic in the slightest.  First of all, there was a guy that tried to come up with something better, but unfortunately his IPv8 ideas were met with laughter in the engineering and operations community to the point that many people (myself included) procmail'd the poor fella into /dev/null (Unix-geek-speak for deleting the his emails automatically upon receipt).  I think that if you did get people to think about a new protocol, that they would just redesign something almost identical to IPv6 anyway.  Afterall, it solves the main problems we have remaining...it provides virtually unlimited address space and has what amounts to a variable and extendable header size that makes it almost infinitely future-proof from a feature perspective.

Oh, and then there is the small issue of time. The IETF, while up to the task, does not work especially fast.  It is not like a standard product development cycle in that you can deliver requirements and get a next generation protocol for the worlds communications that will last the next 50 years in a years time.  It will take some time, maybe 5 or more years.  Then you have the unenviable task of getting all the router vendors and all the operating system vendors to  implement your protocol.  How easy is that going to be to convince them to implement it when you also have to convince them that they wasted all money integrating IPv6 functionality?

No, I think the opportunity to create an alternative to IPv6 has passed us by, so suck it up people and put IPv6 migration on your calendar.  In another 5 years, it'll already be everywhere you want to be (just like your Visa), and if you've put it off that long, migration shouldn't be too painful.

Very exciting today and the presentations went well.

My agenda included 4 items of interest:
1. Global Crossing at a Glance
2. Global Crossing and Avaya SIP Interop details
3. Global Crossing VOIP Services
4. Global Crossing Professional Services

I started the discussion by asking the groups how many one them have made the move to a converged voice/video/data network, and not surprising only 1 out 30 said yes.

What better way to start a discussion as to how converged solutions can benefit Enterprises , and how Global Crossing (along with it’s partners) can provide professional services (such as assessment, design, financial justification, migration and implementation ) and management of the platform once transformed.

Every breakout session was about SIP ranging from best practices, do’s and don’ts’ and group learning from collective experience.

The group was very interactive, asked good questions on how Global Crossing could help and what to expect in cost savings and operational efficiencies.

I walked away feeling that our timing is right and that our converged platform’s operational maturity coupled with professional/managed services will only increase the 1 out of 30, to 15 out of 30 in the next few years.

During a magazine interview in 1995 I was asked when I expected the transition to IPv6 to be complete. Based on the current rates of IP address consumption at that time, and after taking the impact of CIDR and NAT into account, I figured we'd get squeezed into beginning deployments around 2000, with a large enough transition complete by 2005 to call it more or less done.

This is one prediction that sure turned out to be wrong. It's 2006, and I don't think we could even say that the transition has begun in earnest. IT managers in the government are questioning the value of moving to IPv6, all while the DoD mandated transition deadline looms in the semi-near future.

It is with some irony that all the barriers that we thought would slow down deployment have been removed, and all the drivers for pushing us into IPv6 have almost dissappeared. We thought that OS support would be a huge barrier, and yet every version of Unix that I know of supports it, not to mention Windows! We thought that carrier support in the core would be a barrier, but Global Crossing, Verio, and a host of other backbones support IPv6.

So the only thing we are missing is a reason to bother with it. Search around for news on IPv6 this week, and you'll hardly find any. I did find the following... Internet2 broke a land-speed record and they used IPv4 and IPv6 for the test...and that's about it for the week. A technorati search on blogs that were specifically tagged with IPv6 turned up 7 searches.

In said Press Release from Internet2, I quote:

Dr. Kei Hiraki, professor at the University of Tokyo and LSR team leader said, "Through these trials, we are now demonstrating that the performance of IPv6 is almost on par with IPv4. For researchers and scientists around the world, this is a positive indication that IPv6 is now ready to be used in prime time for their high-performance applications."

Whoa, wait a minute! You're saying that IPv6 isn't even as fast as IPv4? But those guys at the IPv6 Summit in December of last year told me that IPv6 would be faster than IPv4. They said the stack was more efficient for computers to process and for routers to forward. I read a Juniper white paper that stated that video was more smooth when delivered on IPv6. One presenter claimed that IPv6 was the answer to upgrading the public emergency response communication systems. I daresay that moving to an IP communications model is the answer, but I don't see where IPv6 is necessary to make it work. One army general imagined an IPv6 address for every bullet!

For those of you looking for a business case for your IPv6 transition, watch out for people selling snake oil. The proponents of IPv6 are getting desperate to help people create positive business cases for deployment and are stretching the truth mightily.

In my own personal opinion, I think the best argument for an IPv6 deployment is just to rip the band aid off. All this debating about the value and making BS business cases is just a waste of energy. A transition is inevitable, it's only a question of when. It's not really going to be so expensive now that there's so much support for it, so just get it over with, and do it!

[shameless plug]
And if you want an Internet provider or an IPv6 ready IP-VPN, Global Crossing supports IPv6 across a wide assortment of it's products and services.
[end shameless plug]