Ittechtips.com’s Blog

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.

A failure to quickly operationalize Internet Protocol version 6 (IPv6) could have a profound effect on the Internet, breaking it up into islands of connectivity and threatening cybersecurity in the process. There are two main issues here – taking too long to activate IPv6 as IPv4 resources dwindle could leave us with a gap in services that affects availability, and failure to quickly upgrade security as many IPv6 devices have been deployed is already leaving us vulnerable to malicious use of IPv6 to compromise integrity and confidentiality. There is a bit of a chicken and egg problem here since planned IPv6 activation is being delayed by a lack of security, and security isn’t being properly addressed because of a lack of deployment. This article will give you a glimpse of both sides of the problem and the effect on cybersecurity.

As the IPv4 free address pool continues to dwindle, enterprises will have to deal with a series of inconvenient “bandaids” that affect service availability as we try to extend the life of IPv4 while upgrading to IPv6 hosts, services, and routing. The use of network translators and proxies, and NATing carrier cores ala “Carrier Grade NAT” will be necessary but this will cause us to break and reengineer many services that today rely on carrier’s ability to provide end-to-end addressing - such as “server-push” messaging to Blackberrys and smart phones. Another scheme to buy IPv4 more time is reclaiming poorly used IPv4 address spaces to split up and redistribute the existing large IPv4 address blocks through some sort of trading market. This splitting and redistributing will “de-aggregate” core routing, causing routers to look through millions of addresses to decide where to route a packet, and slowing down the performance of key services like VOIP and video over the Internet. If the Internet core works poorly, carrier edge networks and enterprise networks will essentially become islands with poor connectivity between them lowering the availability, performance and customer experience for services that users access across the Internet - such as cloud computing, eCommerce & eGov sites, and search portals like Google.

The failure to properly pilot, test, and deploy IPv6 security ahead of all of the IPv6 devices and operating systems already deployed in our networks today currently compromises the integrity and confidentiality of millions of Internet connected computers. The problem is that we don’t yet have proper cybersecurity policy, training, and tools for ensuring that IPv6 networks have security parity with current IPv4 networks. A few people already have the knowledge and tools to properly secure most commercial and unclassified government networks, but we need a concentrated push to disseminate that knowledge. On the classified side, we have the same problems plus we have deploy a lot of specialized security tools, encrypters, and IA devices out of the normal tech refresh cycles – at a higher expense. In order to ensure IPv6 security parity with current networks, some part of the US Federal government or industry is going to have to create a security certification and accreditation (C&A) application toolkit and the guidance for how to use IPv6 testing tools for FISMA, DIACAP and other C&A programs. Tools that are commonly used for C&A audits, like Retina vulnerability scanner, are mostly blind to IPv6 vulnerabilities. Hacker community sites are already offering tools such as relay6, 6tunnel, nt6tunnel, netcat6, VoodooNet, etc. that can be used to create IPv6 covert channels and hacking toolkits such as THC6 for IPv6 hijacking and DOS. As we demonstrated with our smart-phone hacks last year (Ref: Klein IPv6 HOPE), if we don’t properly secure both versions of Internet services installed on million of devices today, we compromise both the current generation and the next-generation of the Internet at the same time.

In order to address these challenges we need a concentrated push to move IPv6 cybersecurity forward so we are ready to extensively activate IPv6 upgrades everywhere in the next few years. If your users interact across the Internet with external servers (WWW, email, DNS) or provides services to customers across the Internet, you need to begin now to dual-stack your servers, client computers, applications, routers, and especially security to address IPv6 before 2012 when the “operational challenges” really begin as we try to stretch IPv4 scaling. The need to continue Internet operations and security in a dual-stacked mode is going to increase the operational cost (+15% in many estimates) and be a drain on our economy until we get the proper security and infrastructure in place to support IPv6-only networks.