Wednesday, September 19, 2012
The research project is dubbed the IPv6 Matrix Project, and full details about the project can be found on its website. In a nutshell, the system attempts an "IPv6 crawl" by looking up DNS records for the top one million websites (and then some) according to Alexa. The system uses DNS results to initiate connection attempts to email, web and time servers.
The IPv6 Matrix website home page displays a world map, which I assume displays the very latest measured penetration percentage as you mouse over each country. Mousing over the U.S. today indicates 22.47%, but this particular metric includes only the .us ccTLD, not .com, .net or .org which are included in the report metrics published on the RIPE website.
Interestingly, results in Asia were surprisingly low given the general lack of IPv4 space coupled with tremendous wireless and broadband growth in the region. Perhaps most Internet hosts are behind NAT64 gateways. While the England chapter of the Internet Society plans expand the data analytics over time, additional "crawlers" distributed across the globe may provide more robust sampling. But certainly this is a great start in terms of publishing one measure of IPv6 deployment.
Friday, September 14, 2012
The clock is ticking on IPv4 address space. Unfortunately, it's inevitable. IPv4 space will no longer be available for allocation anywhere at a time in the not too distant future. Even if you have plenty of IPv4 address space, the complexion of the Internet will continue to morph from today's predominantly IPv4-only network to a mixed IPv4-IPv6 network. To reach all Internet users of the future with the ubiquity of today's Internet, you'll need to deploy IPv6 at least for your Internet-facing infrastructure like web and email servers. Of course if your internal users desire to connect to IPv6-only websites that emerge over time, you'll need to consider techniques for enabling this, such as deploying a translation gateway or implementing dual stack on such devices.
There's a lot to think about when deploying IPv6, even on "only" Internet-facing infrastructure. Mike Dooley and I have teamed up to write a forthcoming book on the topic, to be available in early 2013, to help people understand the motivation behind deploying IPv6, the process of assessment, planning, testing and deployment, as well as the technical aspects including consideration of infrastructure, applications, computing devices, security, network management, and of course, IP address planning. More details will follow as we approach publication so stay tuned!
Tuesday, September 11, 2012
On the other hand, if hardly any resolvers (i.e., caching servers) initiating queries on the Internet even perform DNSSEC validation, signing your zones will offer value only to a small number of deployed validators and no value to non-validating resolvers that ignore DNSSEC signatures. Is it worth the effort of implementing and maintaining signed zones?
In an attempt to quantify the number of DNNSEC validators issuing queries on the Internet over time, the Internet Society is asking for help on behalf of Verisign Labs. They are asking webmasters to add one line of code in their HTML files which causes each web browser visiting your site to initiate a DNS query to Verisign Labs' DNS servers authoritative for validatorsearch.verisgnlabs.com. The Verisign Labs DNS servers then attempt to determine if the querying server is configured for DNSSEC validation. In this manner, Verisign Labs hopes to gather a measure of the relative quanitity of DNSSEC validating resolvers making Internet queries.
This data should help DNS administrators decide when DNSSEC zone signing makes sense for them. The preliminary results indicate that 3.66% of resolvers are DNSSEC-validating resolvers. Your participation in this analysis through the addition of one line of HTML can help Verisign Labs and the Internet Society to enlarge the sample size and provide robust measurements over time. These measurements will encourage DNS administrators to implement DNSSEC to secure their namespaces with the assurance that a given percentage of resolvers are utilizing and counting on their published DNSSEC signature data.
Wednesday, September 5, 2012
Many organizations have expressed skepticism about deploying IPv6. But they need to understand that the issue is not how much IPv4 address space they have, but how much is available for global distribution. As IPv4 exhausts around the world over time, a new generation of web users possessing only IPv6 addresses will materialize and grow substantially.
But when will this new generation of Internet users appear in numbers? Many service providers are masking an indeterminate number of these users due to the necessity of providing them access to both IPv6 and IPv4 web content. This makes it difficult to gauge IPv6 client requests on a global scale, but you can actually measure this, albeit coarsely, on your own web presence. Let’s see how.
Presumably, service providers with IPv6-addressed subscribers will attempt to connect using native IPv6 end-to-end if possible, but drop back to using an IPv4-IPv6 co-existence technology such as tunneling or translation should the subscriber’s intended destination be reachable only via IPv4. The means to determine this reachability is initially done via the domain name system (DNS).
An IPv6-addressed device will attempt to resolve a user-selected URL to an IPv6 address by issuing a DNS query for the AAAA resource record type for the URL The service provider’s caching DNS server, to which the subscriber device directs this query, will attempt to locate the DNS server on the Internet that is authoritative for the corresponding domain, then query the server for the AAAA record. Should the query resolve successfully, the result is returned to the subscriber device and it will attempt a native IPv6 connection. If unsuccessful, the caching server may issue a similar DNS query for the A resource record type to determine if the destination is configured with an IPv4 address.
If the subscriber device has only an IPv6 address, configuring the caching DNS server as a DNS64 server provides a standardized method to translate the returned A record query result into an IPv6 address. When this synthesized IPv6 address is returned to the subscriber device in the form of a synthesized AAAA query response, the device will attempt to establish connectivity via a service provider NAT64 gateway, which interconnects the service provider IPv6 network with the IPv4 Internet.
If the subscriber device is dual stacked, with both an IPv6 and an IPv4 address, it should issue both the AAAA and A queries itself, then apply its address selection policy table to determine which source and destination addresses to use. The default policy table implemented by most common operating systems today does favor IPv6 in the event of results returned from the AAAA query. If the AAAA query fails to return results, the device will attempt to initiate the connection via IPv4.
The bottom line is that IPv6 end users may be attempting to connect to your website using IPv6. The best way to determine this is by analyzing your DNS query logs. Review your query logs for AAAA query rates over time to identify increases in AAAA queries. As mentioned, this metric is rather coarse, as caching DNS or DNS64 servers will cache responses received from other DNS servers, but it can serve as a useful indicator of IPv6 connection attempts to your website.
Thursday, July 26, 2012
As IPv4 addresses dwindle in supply, service providers will ultimately need to begin assigning IPv6 addresses to their mobile and broadband subscribers. Nevertheless despite a growing number of IPv6 Internet users, these users will expect and demand ubiquitous Internet access, which requires connectivity to IPv6 and IPv4 websites. Therefore, each service provider will need to accommodate this customer requirement by either assigning both an IPv6 and an IPv4 address in a dual stack configuration, at least until IPv4 addresses run out, or by deploying address translators within their networks to convert IPv6 packets into IPv4 packets to reach IPv4 destinations.
Various IPv6-IPv4 network address translation schemes have been devised to for service providers to enable IPv6-addresss subscribers to access IPv4 websites, including NAT64, CGN, 6rd, DS-Lite, among others. I'll refer to the class of IPv4-IPv6 translators within these schemes as address family translators (AFTs).
Though AFTs are generally designed for scalability, they do have their limits. All IPv6-IPv4 traffic would need to funnel through these devices enroute from the service provider's subscriber devices to destination Internet sites. As the volume of IPv6 addressable subscribers grows, so will the volume of traffic at the expense of available shared IPv4 addresses and ports, and the capacity of daisy-chained AFTs. At the point of reaching such scaling limitations, subscribers' perceived Internet performance will suffer and customer dissatisfaction will rise.
The dual stack approach is the most flexible but by definition requires availability of IPv4 addresses (NAT444 and similar IPv4-IPv4 NATs are likewise scale-limited). AFTs serve as a temporary IPv4 extension technology, but at some point, this dam will burst and barring any new IPv4 extension technologies, the service provider will be faced with a large number of unhappy customers.
While we are perhaps a couple of years from this situation occurring, it makes sense to plan ahead with a concerted Internet community effort for a demand side World IPv6 Launch. This launch would entail service providers decommissioning AFT devices and enabling native IPv6 addressed customers to access IPv6 enabled websites. As unpleasant as this sounds, this would effectively define the dreaded "Y2K date" for organizations to implement IPv6 websites to enable communications with this sudden spike of Internet IPv6 users. Of course organizations missing the date can still catch up later.
As such this launch date would need to be far enough into the future that organizations can plan for it, but not too far that IPv4-extending technologies surpass their capacities. I would defer to a true Internet guru such as Dr. Geoff Huston, who could perhaps extend his IPv4 exhaustion analysis to derive the upper bound of this date.
Compliance with this date would be completely voluntary, but it seems we need a plan to address this Internet transition issue. Without a concerted plan, individual service providers will "hit the wall" independently and subscribers will suddenly face limited Internet access. They may flock to other service providers who still have IPv4 capacity, only to accelerate their IPv4 run-out. With a launch date a year or so out, organizations can make concrete plans and service providers can offer a more consistent Internet experience to subscribers no matter which protocol they are using.
Wednesday, June 6, 2012
Download the survey results to get all the details!
Tuesday, May 8, 2012
But to help you get started in determining where your environment lies on this complexity continuum, I’d propose the following steps to keep it SIMPLE! These steps may be iterative if you split your deployment into phases, but the same basic process should apply on each iteration:
- Scope - The first step is to define the scope of your IPv6 deployment. For example, are you planning to implement IPv6 on Internet-facing infrastructure only or throughout your network? You may plan to implement IPv6 throughout your network eventually but decide to deploy in phases, starting with a small, controlled portion of your network to gain experience and test for any unanticipated side effects. It will likely also be more appealing from the perspective of resource requirements to start small then expand deployment as well.
- Itemize – If you don’t already have complete computing and network inventory, perform network discovery of end user devices, servers, infrastructure, IP subnets and address assignments as well as address pools within your chosen scope. This should also include applications, databases, security and network management products, and those employee “bring your own devices” (BYODs).
- Mitigate – From your itemized list of computing components, identify which are IPv6-ready and which require upgrading or replacement. The latter forms the start of your “to-do” list. Recent vintage routers, switches and device/server operating systems support IPv6 today but it is instructive to take inventory and verify this is the case. Most applications that do not embed IP addresses within screens, configuration files or packet payloads should work with IPv4 as well as IPv6 though this should be verified as well. You may also need to invest in new infrastructure; e.g., DHCPv6 servers, so identify required new items for your “to-do” list, and also consider your security and network management products.
- Plan – Based on your defined mitigation tasks, i.e., your “to-do” list, which identifies what components need to be procured or updated, determine the respective costs and align with the budget process, phasing in any required purchases as the budget permits. Define your IPv6 address plan and identify any IPv4-IPv6 transition technologies you plan to use, such as dual-stack, tunneling and translation techniques. Update your security policy to incorporate IPv6 protection policies, as well as management and change control policies to account for IPv6. Plan for training for personnel involved in IPv6 implementation and support. Integrate all of these planning tasks into an integrated project plan and identify resources required, dependencies, and planning time frames.
- Lab test – The plan should incorporate a testing phase prior to production deployment to verify IPv4-IPv6 operations. To the extent possible, include as many components as possible in the testing, including security and management systems. Identify any issues and update plans or work with respective vendors to resolve.
- Execute and manage – With a solid plan in hand and successful lab testing, the probability of successful plan execution can be maximized. However, even the best plans cannot predict every possible error condition. Carefully manage the deployment in accordance with the plan, invoking contingencies as needed. Communicate feedback to all involved including management to provide status updates and issues. Monitor security logs and management systems to baseline network operation and to identify anomalous conditions.
Monday, May 7, 2012
Monday, April 23, 2012
The survey is similar to last year's, which helps us look for trends, but also features a couple of new questions. One of particular interest asks about the "IPv6 density threshold" people may be waiting for to pull the trigger on deploying IPv6. This density threshold relates to the percentage of Internet users that are IPv6 within the entire Internet. It'd be interesting to see if this "IPv6 audience size" has an influence on people's planning initiatives. Thank you in advance for taking the time to complete this survey! Results will be published in mid-May.
Monday, April 16, 2012
The Internet Engineering Task Force (IETF), which for all intents and purposes is the standards body of the Internet Protocol, has declared that "IPv6 is no longer considered optional." In RFC 6540 officially published late last week as an Internet Best Current Practice, the IETF cites the impending depletion of IPv4 address space with the continued growth of the Internet as drivers for widespread IPv6 deployment. While the RFC defines requirements for all developers of IP nodes, the main target seems to be consumer device vendors, many of whom have delayed implementation of IPv6. With consumers just implementing these IPv4-only devices today, they are likely to remain installed for many years, extending the IPv4 support lifecycle. Of course IPv4 will be around for quite some time, but the more of these devices that are IPv4+IPv6 instead of IPv4-only, the easier co-existence will be to manage.
Among the best practices recommended, the RFC stipulates that all new "IP implementations" must support IPv6, and IPv6 support must be equivalent to or better than corresponding IPv4 feature support and quality, that dual-stack support is required though IPv4 must not be required for operation, and existing hardware and software implementations should be considered for upgrade to IPv6 support.
Another interesting statement from the RFC is that "the term "IP" can now be interpreted to mean IPv4 + IPv6, IPv6-only, or IPv4-only." While separate standards exist for IPv4 and IPv6, the term "IP" now officially encompasses both protocols. Requirements for features specific to a given version should be so indicated, while general "IP" features will be assumed to apply to both.
This IETF statement complements what the Regional Internet Registries have been promoting for some time, and the World IPv6 Launch seven weeks away testifies to Internet heavyweights' participation in supporting IPv6 deployment. The IPAM Worldwide homepage features a graph embedded from the RIPE NCC which illustrates the relative density of IPv6 networks being advertised on the Internet. While the graph certainly shows a growing influence of IPv6, the raw numbers are also of interest. Considering the worldwide average, 5320 IPv6 networks are being advertised as of the end of March, 2012, while only 3594 were in March, 2011. This represents a 48% jump in advertised IPv6 networks. The industry momentum continues to build for IPv6!
Wednesday, April 4, 2012
I recently had the opportunity to preview a market analyst's brief on BT Diamond IP's DHCP/DNS/IPAM (DDI) features and benefits. Among my comments, I indicated that there was no mention of IPv4/IPv6 block management, a core IPAM function for which we are frankly unmatched. To my surprise, I was asked to elaborate about our block management features and benefits.
From my perspective, for any modest sized or larger IP network, DDI starts with block management. If you have to manually type in every subnet address in your network, why not use a spreadsheet? Block management enables entry of a "root" block, such as 10.0.0.0/8, fc00::/7, 2001:db8:a87e::/48, etc. as the root block from which subnets or other "pool" blocks can be allocated. This allocation process should not require re-entry (or cut-and-paste) of a chosen subnet address; if yours does, you're little better off than using spreadsheets which likewise require manual entry. With the Diamond IP solution you simply navigate logically to where the subnet is needed, and a few mouse clicks to select the type of address space (VoIP, wireless, management, etc.) you need, the version (IPv4 or IPv6), and CIDR size then submit!
This simple process ties IPAM directly to business processes. For example:
- "I need a new wireless subnet in the Philly office finance division"...point and click and done
- "I'm planning to open a new branch office next month and need to allocate eight subnets for planning purposes"...our site template feature allows one to meet this business requirement in one click!
And each subnet in turn can have an associated address assignment template, so one can also assign addresses for routers, switches, servers, DHCP pools, etc. as well as automatically generate A/AAAA/PTR resource records for each assigned address, further automating DDI functions! These two simple examples illustrate how block management ties directly to business initiatives, and how BT Diamond IP intuitively and easily maps these business initiatives.
There's a lot of noise out there about IPAM and DDI, and the messaging is understandably blurred. When trying to cut through the hype, don't discount what I consider a core IPAM feature: block management. After all, if you don't get your block management right, your underlying IP assignments and DHCP/DNS configurations won't be right either.
Friday, March 30, 2012
|March 2011||March 2012|
|TLDs in the root zone||306||313|
|% TLDs signed||22.5%||29.1%|
Another boost to DNSSEC deployment was announced last week in the form of a pending FCC recommendation that promotes the deployment of DNSSEC planned by several major ISPs. These ISPs will be implementing DNSSEC validation on their recursive servers, which their customers query for DNS resolution. That is, as their customers issue DNS queries to these ISP recursive servers, the servers will resolve the query and attempt to validate the query signatures up the chain of trust to the root (or other configured trusted key).
This ISP deployment of DNSSEC should protect broadband users from website hijacking and other DNS cache poisoning style attacks. That is if the websites these users are attempting to access are signed. With growing TLD adoption of DNSSEC and an expected jump in recursive servers validating queries via DNSSEC thanks to this ISP initiative, the way forward is clear if your TLD is signed. All you have to do is sign your Internet zones and provide your parent zone registrar with your corresponding Delegation Signer (DS) records to link you into the DNSSEC chain of trust.
I believe the hesitancy with DNSSEC implementation is more deeply rooted in the complexity of DNSSEC configuration and the burden of ongoing management requirements for key rollovers and refreshing signatures than in the lack of widescale DNSSEC deployment. In many cases, this lack of deployment has served as a legitimate barrier to implementation, but this will soon cease to be the case.
As for DNSSEC complexity, BT Diamond IP offers a simple solution to signing your DNS information and ongoing maintenance: the Sapphire Sx20 appliance can be configured with your signing and rollover policies so you can set it and forget it. It will automatically roll keys, update signatures, even auto-update DS records accordingly for your subzones. The barriers to deploying DNSSEC are dwindling. Will you protect the integrity of your web resources?
Thursday, March 29, 2012
I'm interested in what people are thinking about what conditions would hasten their plans to deploy IPv6, so I'm planning to add a question about this from the perspective of the IPv6 user density on the Internet. What would it take for you to consider this critical mass? 1 % of Internet users being IPv6, or 10%, or even 50%? Let me know if you agree this is a good question or if you have a different metric or any additional question ideas!
Friday, February 24, 2012
In response to a recent question asking what happened to IPv5, I offer the following response.
The Internet Assigned Numbers Authority (IANA) maintains a centralized repository of Internet Protocol parameters. This function is critical to assure uniqueness of parameter settings to keep the Internet Protocol operating smoothly and without ambiguity.
Among the parameters maintained by IANA are the assigned values of the version field of the IP header. As you might guess, for IPv4, the version value is 4, and for IPv6, the value is 6. But as new protocols are developed within the Internet community, parameter value assignments are requested of and assigned by IANA. In the case of the IP version parameter, the value of 5 has been assigned to the Internet Stream Protocol an experimental real-time streaming protocol.
In fact, the IP version parameter has not only been assigned values 4, 5 and 6, it has also been assigned values of 7, 8 and 9 as shown in the following table from IANA:
|5||ST||ST Datagram Mode||RFC1190|
|6||IPv6||Internet Protocol version 6||RFC1752|
|7||TP/IX||TP/IX: The Next Internet||RFC1475|
|8||PIP||The P Internet Protocol||RFC1621|
If the next version of IP beyond IPv6 was defined as of today, it would be known as IPv10! But hopefully with plentiful IPv6 address space, we won’t need to go there at least in the next 40 years!
Sunday, January 29, 2012
But this experience struck me later in the day in that we were only able to successfully communicate when we supplemented our verbal attempts at communication with gestures and visual clues. Had they rang me on my phone and asked me the same question, we would gone around in circles with little likelihood of success. This naturally brought me back to one of my favorite topics, IPv6. Speaking French to an English (non-French) speaker is a lot like an IPv6 device trying to communicate with an IPv4 (non-IPv6) device: it will not work!
Of course if I was bi-lingual (analogous to dual-stack) we would have easily and natively communicated. Otherwise, if we had no visual ability, a translator would have been required, analogous to a protocol translation gateway for IPv4-IPv6. But as we know in speech translation, something usually gets "lost in the translation", which is possible in IP communications, especially for sophisticated IP applications like SIP traversing a translation gateway. By the way, the third technology of IPv4-IPv6 co-existence, tunneling, doesn't really apply to our analogy, which would have been more like I had written a note in English, sealed it in an envelope on which delivery instructions were written in French and asked my French friends to deliver it!
The bottom line is that if you want to communicate globally, speak the language! Keep learning and gearing up for IPv6! It's the Internet "language" of the future.
Thursday, January 26, 2012
Had these zones been signed via DNSSEC, perhaps this attack impact would have been minimized. This would have been the case if a) the attacker was unable to "re-sign" each zone after modifying it, which would have depended on the depth of the hack to initiate zone signing or not and b) the resolvers performed DNSSEC validation. While it's debatable that an attacker having file access to a zone file also would have had access to run "dnssec-signzone" (or that auto-signing was configured), it's probably more likely that the resolver would not have been configured to validate DNSSEC signatures in the first place and thereby detect that the signature did not match the returned resolution data.
If you aren't already aware, you should know that configuring DNSSEC validation is relatively simple with BIND 9.8 and above. Simply configure your recursive servers with the DNS root public key within a "managed-keys" statement, and set dnssec-enable and dnssec-vailidation to "yes" within the BIND configuration file. BIND supports additional DNSSEC options to configure recursive servers but the beauty of this is that once setup, it runs on "auto-pilot." The managed-keys statement instructs BIND to detect updates to the root zone key (as defined in RFC 5011) and to automatically update its "trust anchor" accordingly.
Of course DNSSEC validation is only useful if queried zones (and parent zones up to the root) are signed. But BIND releases are also progressing towards making the authoritative side of equation easier as well (recursive servers ask, authoritative servers answer). BIND 9.9 promises some improvements in this area with in-line signing but does not yet automate key re-generation for automated rollovers. If you need an automated authoritative solution, check out BT Diamond IP's Sapphire Sx20 appliance, which enables creation of key, signature and rollover policies once, then it runs on "auto-pilot." DNSSEC cryptography technology is a bit foreign to DNS administrators; an automated solution can help provide the security required but minimize associated administrative support.
Tuesday, January 24, 2012
The question I've been trying to answer is how many of these 513 million users have IPv6 addresses vs. IPv4 addresses? As yet I have been unsuccessful in answering my own question. But I've found that Mike Leber from Hurricane Electric publishes a daily Global IPv6 Deployment Progress Report. This report lists the TLDs with IPv6 (surprisingly only 85.9% have IPv6 addressable name servers today), a summary of A and AAAA records for "next level domains" for each TLD, a summary of advertised autonomous systems (ASes) for IPv6 networks, top websites available over IPv6 and more.
The top websites statistic is an interesting one, which today indicates that about 1.1% of the top 1 million websites as reported by Alexa, publishes at least one AAAA record to advertise IPv6 reachability. I view this statistic as the "supply side" of the IPv6 supply and demand relationship. The "demand side" would be represented by the number of IPv6 user devices, or my as yet unanswered question, not only for China but worldwide. At some point in time, I expect this demand side will reach a level where organizations will want to participate in supplying IPv6 content. But having visibility to this demand curve is necessary to make this decision. So I'll keep fishing around but if anyone has any suggestions, please share them!
Thursday, January 19, 2012
World IPv6 Launch is not a deadline to implement IPv6. It's another means of publicizing the need to consider IPv6 deployment - is it right for you and when? IPv4 space is pretty much gone in Asia so as new IP address consumers in that part of the world comprising over 60% of the world's population begin using broadband and wireless devices, IPv6 address use on the Internet will grow. The homogeneous IPv4 Internet of today will evolve to a mixed IPv4-IPv6 Internet.
How rapidly and to what proportion IPv6 will permeate this mix is unclear. But it makes sense to track this over time and to be ready should the IPv6 density reach a level where substantial potential customers and sellers are unreachable with IPv4-only Internet presence. This is the real decision point for deploying IPv6 for those with plenty of IPv4 address space: at what point will I be missing substantial inbound and outbound sales, collaboration, and partnering opportunities with organizations constrained to only an IPv6 Internet presence? For every organization, this critical "IPv6 density" point will differ - for example, for organizations serving primarily Internet users from Asia, this time will be sooner than those that do not.
I'd recommend estimating that date for you (if you ever believe it will happen) and working backwards to devise a plan to support an IPv6 Internet presence. With a plan at the ready, you can estimate the plan execution time (make sure you add some fudge time due to inevitable unforeseen issues) and be ready to invoke it with enough lead time to complete it by your IPv6 Density or "D-Day."
Where to start? We've put together the IPv6 Resource Center for your perusal of material about IPv6 technology, IPv4-IPv6 co-existence techniques, and even a recorded webinar outlining an IPv6 deployment plan template. Please don't hesitate to contact me with any feedback on the material or suggestions for coverage of additional topics.
Tuesday, January 17, 2012
The goal is to enable IPv6 for enough end users so that at least 1% of wireline residential subscribers' connections to participating websites to use IPv6 by June 6. This may not sound like much but 1% of an estimated 500 million is 5 million users which is substantial. This is an exciting time for Internet companies. The industry is moving deeper into IPv6. Are you ready?
Thursday, January 12, 2012
So what's the big deal? Depending on what gTLDs are accepted, organizations may desire to register subdomains beneath new gTLDs in ASCII or IDN format. Considering that every marketing message from an organization includes a website address, advertisting a fully native lanugage URL (and of course content!) may facilitate marketing communications with audiences in certain parts of the world. For example, if your organization is attempting to reach or attract residents in India and a new gTLD is created using the native language Devanagari alphabet, creating a subdomain using the Devanagari alphabet may facilitate this reachability. Putting your information in your target customers' terms, down to the URL, can help improve communications and provide a competitive advantage.
Configuring DNS with IDNs requires no upgrades of DNS, but it does require conversion of native language characters, represented in Unicode, into ASCII which is required in DNS configuration files and the DNS protocol. This conversion process is a bit complex but the IPControl IPAM system automates this conversion to save time. If you'd like more details on IDN conversion for DNS configuration, please see our IDNA white paper, webinar replay or visit the ICANN gTLD website.