NAT-PT is dead, let the translation race begin

August 24th, 2009

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.

IPv6… more than half Top Level Domains not really on top.

August 11th, 2009

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

Commerical Providers Launching IPv6 Project - Looking at Long Timelines …

August 11th, 2009

August 7th, 2009

Commercial service providers are all - or mostly all - considering their IPv6 implementation strategies.  Not what kind of advanced peer-to-peer services they can launch, or how they can revolutionize their product and service offerings (that will come later), but the “straightforward” provisioning of IPv6 within their networks and out to the customers.  Simple high-speed Internet, either for organizations or individuals (broadband providers - cable, DSL, and fiber).  Enterprise-focused providers are also looking at their L3 VPN offerings and preparing for IPv6-capable services.  Multicast, and mobility, certainly, offer attractive capabilities for launching next-generation services. 

The providers I have talked to, and worked with, are at different points along the implementation path.  Some are in the design phase, others are conducting pilots on secondary networks, and some have big deployments. 

If there is one overriding realization that all these providers have come to it is that IPv6 implementation is a big project, and a lengthy process - especially the “getting off the ground” phase. 

1) Resolving to launch the project, when there are so many other important projects competing for resources (DSG, IPTV) 

2) Evaluating the hardware and software platforms for IPv6 capability, and putting together a coherent upgrade strategy that does not conflict with upgrades in progress or planned to support other projects (L3 VPN, Voice Services, DOCSIS 3.0, etc.) 

3) Capital budgeting 

4) Breaking down the project into phases, and rationalizing all that into a timeline that provides the right capabilities at the right time 

5) Doing the design work - again within a changing environment - addressing, routing, management, security, peering 

6) Doing the implementation, in a no-downtime environment - again within a changing environment 

7) Provisioning, back-end systems - there are a lot of applications, systems, and process to upgrade as well 

Like any long journey, getting started is the hardest step.  It requires some foresight (likely IPv4 exhaustion - mid-2012), and there are many pressing projects for ISPs - and it is not a great economic climate.  But, the truth is, 2-3 years is not a long time to get as much done as must be done, and what happens in the “late innings” of IPv4 runout is unclear.  Hoping for more time if things get tight is not a strategy. 

So - my advice - start now.  Start slow - but start.  A few people, a modest budget, and a lot of the ground can be prepared for a successful project when it becomes clear a more serious, concerted “push” is required.

U.S. Government IPv6 Milestones and Progress Q3 2009

June 3rd, 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.

A Quick Explaination of IPv6

April 14th, 2009

 

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!

New: Cisco IPv6 Video Accelerated Training Course

April 13th, 2009

 

Hi,

 

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

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

 

 

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 Improvements - The Plain Truth

April 12th, 2009

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…

Service Provider IPv6 Adoption - Part 2 - Prefix Announcement

March 8th, 2009

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.

CyberSecurity Threatened by Slow Move to IPv6

February 23rd, 2009

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.

Sharing an IPv4 Address Across Multiple Subscribers – Part Two – Inbound Services

December 16th, 2008

In the last discussion, we talked about service providers using a single IPv4 address shared between subscribers.  Carriers may well do this not as an alternative to IPv6 deployment – which pretty much everyone (finally) agrees is the “real” solution – but as a stopgap measure to allow them more time to complete their IPv6 deployments.  Many providers have done a poor job of preparing their businesses for the “post ready availability of IPv4 routable addresses world”.  Additionally, and as an aside, not all in-home platforms are IPv6 ready and on-by-default (Windows XP, for example, have IPv6 but it is not on by default.  So, there are a number of reasons why providers need to be able to provision IPv4 to existing and new subscribers for another few years.

In the “shared IPv4 address” schemes, rather than have “one IPv4 address per subscriber” there would be a new practice – “one IPv4 address per multiple subscribers”.  There are several implementation schemes under discussion for how the provider would actually do this.  One schemes call for “double NAT”, where the subscriber (with a NAT router at the edge) uses RFC1918 internally, does NAT at the edge, and then the provider does NAT *again*.  Another scheme simply moves the NAT function from the subscriber edge router into the provider cloud, leaving it still “single NAT”, but no longer in the subscriber device.  More about these another time.

The issue left on the table last time was “what do we do about inbound services”?  Suppose a subscriber wants to run a webserver, for example.   Suppose another subscriber sharing that routable IPv4 address also wants to run a webserver?  Clearly, both cannot receive traffic inbound destined for “IPv4_Addr:80” – the standard HTTP TCP service port.  What do we do in this situation?

I think the answer is the simple one – “don’t do that”.

The most likely implementation will be for the “standard” subscriber service offered to home users (“consumer class”) to indeed be a “shared IPv4 address” scheme.   These addresses are probably most often, for almost all carriers, assigned via DHCPv4 anyway, and are dynamic.  Someone using the standard service would not be expected to run services requiring specific inbound ports.  These subscribers would only be expected to run “NAT-friendly” applications – as most subscribers do today.

For subscribers hosting services, or using more advanced applications, however, the provider will offer a “premium service” – a dedicated IPv4 address.  That will be the solution.  A “normal” subscriber gets a shared IPv4 address.  A “premium” subscriber pays a little extra, gets a dedicated IPv4 address (and probably a static IPv4 address, which some carriers offer today as a premium service), and is not subject to NAT within the carrier cloud.  If the subscriber does NAT locally, within their home edge device, that is up to them. 

In some ways, this is a simple solution.  It only appears simple from the subscriber view.  They pay a little extra.  For the provider – not simple.  Remember that solutions only work for providers that are scalable.  Think about the impact on the provisioning and billing systems or the provider.  Think about the network impacts of implementing the “shared IPv4 address” scheme.  Lots of challenges, lots of work to do, and – look around – in a pretty challenging business environment.

I always say it is not easy being a provider.  This is another example.  But what choice do the providers have?  They need to keep signing up new customers, and not all subscribers are ready for IPv6 today (nor will they be in 2009, when the IPv4 address shortage really will begin to constrain their business).

Ahead, we’ll talk about applications that will not work (or as well) in a double-NAT environment, and also about some of the more popular “shared address” schemes.