Archive for August, 2009

NAT-PT is dead, let the translation race begin

Monday, 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.

Tuesday, 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 …

Tuesday, 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.