Ittechtips.com

With the impending countdown to the exhaustion of available IPv4 addresses, the Federal Government, Internet Service Providers and Enterprises are beginning to deploy IPv6 throughout their networks.While IPv4 will not go away immediately, IPv6 capability is being adopted by more companies. IPv6 traffic is increasing at unprecedented rates. Wireless communication providers such as Verizon are requiring device manufacturers to support IPv6. Google has enabled IPv6 on their main search engine (ipv6.google.com) and YouTube. Given the increase in IPv6 devices and the near exhaustion of IPv4 addresses, software applications must now consider porting to IPv6 to support coming onslaught of client IPv6 traffic.Porting to IPv6, What’s the big deal?For many applications, migrating to IPv6 may not require ANY code changes. If the application is behind a firewall and is accessible only to the internal network, there may be no need to port to IPv6. Most hosts on a corporate internal network will have an IPv4 address.If the application is part of a Web Application Suite that does not use IP addressing in its code base, it may not need to be updated. Most web servers today support both IPv4 and IPv6 and most often the application does not need to know about the IP address of its client. For example, Microsoft IIS has supported IPv6 since Windows 2003 Server and IIS 6.0.Most Java and .NET applications do not require porting to IPv6. Java and .NET frameworks shield the developer from the need to use IP protocol-specific socket API calls. By default, the Java runtime will use IPv6 sockets if IPv6 is enabled on the operating system. This feature allows applications deployed in servlet containers like Apache Tomcat to support IPv6 without any modifications. However, applications written using Java or .NET that refer to network IP addresses must be reviewed to make sure they use the non-IPv4 or IPv6 specific calls.The biggest challenge to porting applications involves code that uses the C TCP/IP networking API. If your application uses the C TCP/IP networking API, then you may need to change specific IPv4 function calls to use a common IP function call. Microsoft has provided a good synopsis of porting and testing code. The proof is in the pudding.So what do I do now? Port and test your application. Get started!You will never know what is required to port your application to IPv6 until you get started. The four steps below will help you get there.

While it is a Good Thing that the base/standard IPv6 specifications are stable, for reasons like being able to implement support in devices and operate networks using those devices, it is also a Good Thing that advancements continue …

To the first point, the ability to deploy IPv6, there have been many announcements in the last year or so:

Perhaps most notably, Google has continued their IPv6 progress - adding Youtube to their stable of IPv6-enabled services, along with the majority of their offerings - accessible if you are accepted into their IPv6 “in” crowd :).

Verizon to require IPv6 capability in LTE kit (LTE, Long Term Evolution, is their choice of technologies for their “next generation cellular network”) … also known as 3GPP, and a pre-cursor to so-called “real 4G services” (more here).

Comcast is moving their IPv6 deployment forward (go sign up!) in some great steps, relying on a combination of steps (6RD (see below), Dual-Stack Lite, Native) - and good work on DNSSEC too (but that is a separate conversation!). Dual-Stack Lite was developed (primarily) by Alain Durand, who happens to work at Comcast

We are starting to see more IPv6 capabilities in security-related tools, whether on the “Network-based IPv6 Defense” side (disclaimer: gratuitous self-plug) NEWS) or “IPv6 attack” (or verification, perhaps) side … please continue to encourage (require) all of your vendors to fully implement IPv6 in all facets of their gear, only those purchasing the gear have the power to move them.

China Telecom is moving forward with IPv6 trials this year, with commercial deployments due in 2012.

On the actual, technical advancement side - again an interesting year:

A somewhat modified version of 6to4 (an automatic IPv6 in IPv4 tunneling mechanism based on Protocol41 encapsulation), called 6RD has been moving forward (now an RFC) and has even been appliancized. 6RD is particularly interesting because, while it is a tunneling technique and thus reduces the available payload per packet (MTU), it is entirely transparent to the user and whomever/whatever they are communicating with - oh, and 6RD allowed the second largest ISP in France to go from 0 IPv6 to deployed in LESS THAN 35 days.

And, on an interesting (and perhaps confusing) note:

It also appears that the ITU is attempting to get into the IPv6 Registry game.

In 2007 the IETF deprecated the NAT-PT translation solution (RFC4966) because translation was considered harmful. Less than two years later translation it is back in the IETF and back with force. During the 75th IETF meeting in Stockholm this week translation was one of the big topics and one of the topics with a great sense of urgency. The replacement for NAT-PT is now called NAT64 and offers a translation between IPv6 and IPv4 in much of the same ways as NAT-PT. There are of course differences to address the major issues that were brought up when NAT-PT was deprecated but it doesn’t address the issue with translation being in issue in general and that it might create some of the problems we are seeing today with NAT.
NAT64 is combined with DNS64 to create the complete translation package to allow IPv6 clients to access IPv4 servers. One major issue with NAT-PT was the fact that it broke DNSSec. This has been address with DNS64 which moves the generation of IPv6 addresses into the clients trusted domain.
In addition to NAT64 there are other translation solutions that are more focused on translating IPv4 to provide a greater IPv4 address independence by increasing the use of private IPv4 addresses. This was also considered bad just a few years ago but is now part of the central discussion with the IETF. Large scale NATs, or carrier grade NATs as they were called before people realised that NAT would never become carrier grade, are requested by some operators who aren’t concerned by the operational issues of running large private networks. Other translation proposals such as DS-lite try to run IPv4 on top of IPv6 in order not to have to care about IPv4 addressing.
All this translation is scary but some of it is inevitable as we quickly are getting close to the end of IPv4 and everybody agrees that we need to maintain supports for IPv4 clients at the edge one way or the other. Let’s just hope that the more sensible approaches as DS-lite prevail or we might end up with tons of nested NATs and no IPv6 and no more peer to peer communication.

At the recent ISOC Asia (1) conference in Kuala Lumpur a rather innocuous coffee break question was raised: could any one around the table name some of the major TLD’s still delinquent in their IPv6 support ? Nobody could answer on the spot but the question intrigued me.

A logical place to start looking for an answer was ICANN (2). Their Kim Davies provided a rather revealing perspective in a presentation (3) at ICANN 34 in april. 41% of the 280 existing TLD’s did not provide any IPv6 connectivity and more than 68% did without any diversity. Even for IPv4 it was surprising to see that 7.2% of TLD’s do not provide diversity, contrary to IANA rules. Two name servers separated by geography and topology are required and the same applies for IPv6 (gTLD applicant guidebook) (4).

IANA provides a list (5) of all legitimate TLD’s. including the recent fancy additions like .museum and the like.

Hurricane’s Mike Leber’s IPv6 deployment progress report (6), which is updated daily, provided another piece of the puzzle. When correlated to the IANA list, bingo, the culprits became visible, many obscure but a number of them rather out of place in this set. To refine the model, the title of Top Level Delinquent could be bestowed on the TLD with the largest number of domain names allocated under its ‘top’.

As ICANN and IANA can only do so much to enforce rules and regulations, an independent, up to date shame list, pillory of the cyber age, might help delinquents recognize themselves and also expose potential weak points in the internet. To give recognition to top performers on the other hand, why not create a TTLD honour roll for TLD’s who have 3 or more IPv6 authorities?

Oh yes, 9.6% of TLD’s still had open recursive name servers. Safe bet that some failed the grade in both the IPv6 and open recursivity categories oblivious of another Kaminsky type attack.

Progress is being made but to accelerate on the road of IP convergence and instill more confidence in the ‘public internet’, some additional discipline in the Domain Name area, starting with the top and working its way down, would certainly not hurt.

1. http://www.isoc.org/isoc/conferences/inet/09/kualalumpur.shtml
2. http://www.icann.org/
3. http://www.iana.org/about/presentations/
4. http://www.icann.org/en/topics/new-gtlds/comments-2-en.htm
5. http://data.iana.org/TLD/tlds-alpha-by-domain.txt
6. http://bgp.he.net/ipv6-progress-report.cgi

August 7th, 2009

I’m often asked what’s the latest news on in the US Government’s IPv6 programs since they are the driving force behind preparing US telecommunications infrastructure for the coming IPv4-to-IPv6 changeover. Since we know that the IPv4-based Internet will be having tremendous scaling problems by 2012, it’s an Internet continuity of operations and cybersecurity issue to keep IPv6 transition moving forward in a timely manner. Here are some of the key US Federal Government events from the last few months that are continuing to move the transition forward: 

• Federal Acquisitions Rule (FAR) Mod 2005-41 is in final form and will (hopefully) be signed VERY SOON and should be in effect in FY 2010 requiring ALL US Federal IT acquisitions to be IPv6-capable
• September 2008, NIST published A Profile for IPv6 in the U.S. Government Version 1.0 (Now they are launching a testing program)
• NIST IPv6 lab accreditation and testing program will hold a meeting in May and will HOPEFULLY go into operation immediately after see Special Publication 500-273, “IPv6 Test Methods: General Description and Validation.

• The Federal CIO Council is producing a suite of guidance documents via the Federal Enterprise Architecture PMO to guide to guide Federal IPv6 transitions. One of the key documents that many of us worked on under the leadership of Pete Tseronis is currently in final draft and should be signed and released IMMINENTLY. The “Business_Case_&_Roadmap_for_Completing_IPv6_Adoption in the US Government” document contains information on:

  • -Critical timelines and steps for upgrading Internet architecture and applications to IPv6 to avoid IPv4 scaling issues
  • -Coordinating IPv6 initiatives with the IT infrastructure Line of Business (ITILOB
  • -Utilizing the IT Infrastructure and Information Sharing Segment Architectures to define a “to-be” IPv6 environmen
  • -Reinforcing how EA and Enterprise Transition Plans drive IPv6 Exhibit 300 development
• Multiple DoD IPv6 pilot exercises are taking place in 2009 (Joint Services JUICE exercise, Air Force pilot at Eglin AFB, Army C4ISR OTM, etc)
• The DoD is issuing more detailed and actionable IPv6 procurement guidance to help program managers and network operators understand how to procure and fully implement IPv6 networks, applications, and communications systems
• The DoD and Intelligence community are coordinating security guidance to implement IPv6 networks between operational enclaves
• DoD’s successful IPv6 product testing program at JITC has been shut down, and the IPv6 testing is being transferred to be covered under DoD’s Unified Capabilities Requirements testing. See http://jitc.fhu.disa.mil/apl/dsn.html for information concerning UCR requirements and application procedures.

This video by Charles Ross from ittechtips.com, provides a quick answer to the question; “what is ipv6?”

When you done, watching this video, there are over “20″ IPv6 articles waiting for you on my Free IPv6 Articles page!

Hi,

On the behalf of Ittechtips.com, I’m proud to introduce the Cisco IPv6 Video Accelerated Training Course.

This newly constructed course is simply “the Ultimate source of knowledge” for  understanding and mastering the Cisco IPv6 Network Design and Implementation techniques. It contains over 3,000 videos; and each video is no longer than 3 minutes and packed with extremely useful information, these videos will teach you everything that is currently possible related to designing, building, deploying Cisco IPv6 Networks.

I’m also proud to introduce the IPv6 Video Lab Workbook

It contains over 40 Labs that are designed; to help you “quickly” understand the Cisco IOS Commands and Modes, that are currently being used to configure and implement the most common types of IPv6 networks. To learn more about these two amazing products click here: www.ciscoipv6ittechtips.com

IPv6 multicast shares common features and protocols with IPv4 multicast, but also provides changes and improvements. When even the smallest IPv6 global routing prefix is assigned to an organization, the organization is also assigned the use of 4.2 billion globally routable source-specific IPv6 multicast groups to assign for inner-domain or cross-domain multicast applications [ref: RFC 3306]. In IPv4 it was very difficult for an organization to get even one globally routable cross-domain multicast group assignment and implementation of cross-domain solutions was very arcane [ref: RFC 2908].  IPv6 also supports new multicast solutions, including Embedded Rendezvous Point [ref: RFC 3596] which greatly simplifies the deployment of cross domain solutions. The vast multicast spaces available to IPv6-enabled organizations lead to innovative new applications for multicast communities of interest based on task, function, or geo-location.

What’s something new you can do with IPv6 that you can’t do with IPv4? With the massive IPv6 multicast space you can assign groups by geography or geo-spatial coordinates to establish location-based groups.  Multicast groups defined based on (or including) geographic and/or geo-spatial coordinates can be referred to generically as geo-multicast groups.  Because the multicast groups and network routing for the multicast groups is native to the network protocol employed by IPv6 communications networks, the geo-multicast groups do not require extension of the network routing mechanisms.  In other words, by adding geographic context to IPv6 multicast group identifiers, geographic regions as defined by geo-multicast groups can be overlaid onto the communications network without altering the network routing protocol. Previous geo-multicasting schemes, such as Julio Navas and T. Imielinski’s “Geographic Addressing and Routing” [ref: Communications of the ACM, 1999, vol 42] had to create new experimental geo-routing protocols [ref: RFC 2009]. While previous projects rely on specialized routing to achieve geographic information distribution, IPv6 multicast can provide geo-routing support NATIVELY with no new geo-routing protocols needed…

I’ve updated my brief on the efforts of commercial service providers (SPs) to launch their efforts to integrate IPv6 into their networks. Last posting, we looked at a list of 23 large, well-connected SPs, and found that all 23 have obtained IPv6 prefixes. That is an early step on IPv6 deployment, but requires little real effort on the part of the service provider - it just requires a few forward-looking engineers to go and obtain the prefix.

Now we start to look at deployment indicators that take more effort. In this paper, we follow-up on those 23 providers, and see how many are announcing their prefixes onto the IPv6 backbone. We find that 15 of the 23 providers have taken another step - annoucing their prefix to the world.

One last reminder. Providers that are announcing their prefix may be doing so from a small lab, with no production users (announce a /32, have a single /64 with one router and a PC on it). Others may have large deployments, and many production users. A provider that is not announcing their prefix may have a large, internal deployment - perhaps preparing for production services - and have chosen to “cloak” their efforts by announcing their prefix as a last stage in their deployments. This is a provider than wants to keep the timeline between when it is apparent they have an advanced IPv6 capability quiet until they are close to customer availability.

Morale: It is difficult to tell, looking at the “provider shell”, how advanced (or modest) their IPv6 capability is - we can only infer and make guesses.

Read the “Service Provider IPv6 Adoption - Part 2 - Prefix Announcement” brief.