Companies are developing different solutions for IPv6 deployment – here is a blog from a Microsoft Engineer that explains a bit about the approach they have chosen. How is your organization implementing IPv6?

Guest blog post by Gregg O’Brien

It’s no secret by now that IPv6 is the way of the future. Many IT/Network administrators know that they will inevitably be required to start moving towards IPv6 sooner or later, but the idea of migrating servers, applications, and network infrastructure is a large undertaking.

Fortunately, along with IPv6 came a series of transition technologies including ISATAP to make the switch to IPv6 easier.

ISATAP stands for Intra Site Automatic Tunneling Address Protocol and is defined in RFC 5214. ISATAP is an interface that hosts can use to pass IPv6 traffic over IPv4 networks. It does this by taking an IPv6 frame and applying headers to the frame with IPv4 network information. The hosts can then send this frame over the network to an IPv6 host, which can then process the IPv6 frame contained therein.

ISATAP is pretty easy to recognize. Its addresses are formatted in a very unique way. Here is an example of an ISATAP address:
2002:9D36:1:2:0:5EFE:192.168.12.9

If you look closely, you will notice that the first portion of the address, 2002:9D36:1:2:0:5EFE: is formatted like a typical IPv6 address. The subsequent portion of the address looks like an IPv4 address – 192.168.12.9. The format of this address provides some key information:

1) It is a valid IPv6 address that can be used for IPv6 communication

2) The presence of the IPv4 address indicates the IPv4 information that will be used to shuttle the IPv6 traffic over the IPv4 network.

But why would we want to transport IPv6 traffic over the IPv4 network? Why not just continue using IPv4 then?

Well, the idea here is to facilitate transition to IPv6. Consider the following scenario:

An existing IPv4 network in place with several hosts and applications.

Investing in overhauling the infrastructure to accommodate IPv6 is a longer term project, but the goal is to do as much with IPv6 now, to save work later.

ISATAP can help here allowing IPv6 networks and IPv4 networks to talk to each other. So as the network expands, new hosts and network gear can deployed with IPv6 instead of IPv4, but still communicate with the legacy IPv4 portions of the network.

Here we now have two segments of the network, one running IPv4, the other running IPv6. With the use of an ISATAP router and by enabling ISATAP on the hosts present in the IPv4 network, native IPv6 can be deployed on the new network segment. As time passes and hardware/applications are decommissioned, the IPv4 network can be phased out until the organization is fully operational on IPv6.

Hopefully that gives you some ideas about how to get an IPv6 project started in your own environment using IPv6!

Guest blog post by Tim Rooney

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.
 

Tim Rooney

Guest blog post by Nish Vamadevan

The future of the Internet Backbone solely depends on IPv6, there is no doubt that IPv6 will eventually be the de-facto Internet routing protocol of the 21st century. Since the start of IPv6 evolution, we took for granted the real need for an enhanced IP Protocol and continued to concentrate on developing IPv4 networks. Sadly, it is still the case that a significant number of operators are still concentrating on developing IPv4 networks. Over the years, ARIN and a number of organizations have promoted the need for IPv6 adoption; and there has been tremendous success in getting the majority of the Internet community to consider and transition their core networks to IPv6.

Transitioning a core network to IPv6 is not an easy task. It takes great planning and implementation. Once it is done, the network will be solid, and for the major part of it there is no need for a redesign. When it comes to IPv6 implementation, it is better to go with the statement “plan thrice, implement once”. Planning any network is crucial, but when it comes to IPv6 deployment, there are a few aspects that need to be looked into.

The first thing one should look at is the IPv6 Deployment Guide by 6net and go over and understand the concept of IPv6 from a vendor independence point of view along with having a look at ARIN’s IPv6 Info Center.

https://www.arin.net/knowledge/ipv6_info_center.html

http://www.6diss.org/publications/info/deployment-guide.pdf

This is a critical part of design, because when it comes to implementation, all vendors have their own way of looking at things. A company or a service provider, who wants to deploy IPv6, should pick the approach that is best for them rather than taking the vendor’s suggestion. This falls into the category of “Planning Ahead”. If you take the wrong approach in planning, you are definitely going to end up facing problems in the future.

A major aspect to think about when it comes to IPv6 design is the interoperability with the IPv4 networks. In an ideal world, everyone will run on IPv6 backbone and there is no need for a 6to4 infrastructure, but in reality that is not the case. Therefore, one should consider and evaluate how they are going to talk to the IPv4 network. This is an interesting part of design. As time goes by, you can gradually take down chunks of networks that handle IPv6 to IPv4 traffic as the networks evolve towards an IPv6 core. In the long run, you will end up cutting costs.

All these cannot be done without having solid background knowledge and experience in deploying IPv6 networks from a practical point of view. Companies and service providers should encouraging their technical staff to participate in courses and special training so when it comes to deploying their network, it will be a smooth and easy transition.

Nish Vamadevan

Guest blog post by Chris Grundemann

On a cool but clear Dearborn evening in October of 2009, several members of the NANOG and ARIN community walked from our hotel to share a meal at a nearby restaurant. The large party was forced to split across two tables. The deciding factor of which table to sit at? Those who wished to talk shop at one and those who did not at the other. I chose shop talk, along with Igor Gashinsky, Aaron Hughes, Lee Howard, and Jason Schiller. As is typical of a dinner shared among friends and colleagues in this industry, conversation wandered as the meal, and the night, wore on. As is even more typical of this particular group of Internet experts and evangelists (not counting myself, the token newb), the conversation reliably returned to methods for improving the Internet.

On this bright night the topic de jour was creating an information repository, for engineers by engineers, to collect and distribute living documents containing best practices for designing, building and operating an IP network. The IETF BCP process was too slow and inflexible for this purpose and there were no other existing mechanisms that came as close to fitting the bill. So it became clear that if this were to materialize, it was up to us. Many napkin notes, email messages, shared meals, cigarette breaks, cocktail hours, BoFs and Tracks later; we have carved out a foundation for this library to be built upon.

http://www.ipbcop.org/ houses that foundation and is also the home of the grand library created in theory that fateful night and now being constructed in reality: BCOP – Best Current Operational Practices.

The premise is simple; virtually all network-engineering tasks have been performed and perfected by someone, but those practices also change over time as more experience is gained and new tools become available. This leads to two overarching goals:

1) Collect current information from active and experienced engineers. The best place to seek operational advice is from a network engineer who has learned from their mistakes and the mistakes of those who came before them. Someone who has done well what you now seek to do. Not everyone (especially new engineers, working on new networks) has access to an accomplished sage of network engineering however. Gathering the advice of these experts into a common pool gives everyone, all around the world, equal access to this previously very “tribal” knowledge. This open access to the very best current operational practices helps put more networks and more engineers on a more equal footing, creating a better Internet for all of us (less mistakes and less bad habits equals less hassles for everyone).

2) Maintain living documents, flexible to change over time. Technology changes. It’s changing faster every day. Network and Internet technology is no exception. In order for the advice gathered to stay relevant, it must stay current. The documents that contain these best current operational practices must be living; they must be open to new information, additional experience and changes in the underlying technologies. They must embrace flexibility or face eventual insignificance.

Now that a foundation embracing and upholding these goals has been built, it’s up to you to ensure the success of the BCOP library. How? Well, here are a few starters:

1) Use the existing BCOPs as references, for yourself, those who work with you, and elsewhere in your network. Link to them and tell other network engineers about them!

2) Join the BCOP mailing list and comment on the current draft BCOPs under development.

3) Create a new BCOP and work with the Global Network Engineering Community (GNEC) to complete it and have it ratified as an official BCOP!

All three of these tasks are of vital importance for the success of this new but crucial effort. Doing any one of these things ensures your place as an active member of the GNEC, and as an influencer on the future of network engineering. I also encourage you to follow BCOP on Twitter, Facebook, and/or Google+ and engage in the conversation there. Let’s grow this valuable resource together!

Guest blog post by Megan Kruse

There are two kinds of people in this world: those who have already deployed the latest and greatest technologies, and those who need to.

Lots of folks (ARIN and the Internet Society included) have been touting the joys of IPv6 and DNSSEC for a long time, so I won’t bore you with the details of why they are so vitally important. Maybe you’ve already done it, in which case you have tons of hard-earned knowledge to share with the rest of the world. Or maybe you haven’t done it yet, and you’ve just been waiting for someone to ask you what you need and then cater to those needs.

We’re here to play matchmaker. Launched in January, the Internet Society Deploy360 Programme provides real-world IPv6 and DNSSEC deployment information to continue the conversation from “why do I need to do this” to “how, specifically, do I do this?” We cover both IPv6 and DNSSEC topics in a web portal with detailed, technical how-to documents, tutorials, case studies, etc., and follow that up with four ION Conferences a year, speaking engagements around the world, and constant social media interaction.

Through all of these channels, industry experts answer your specific questions and we, the Deploy360 team, then turn these real-world issues into guidance and technical resources for others to follow. We encourage direct feedback on what resources need to be added to the Deploy360 web portal and continue the ongoing dialogue about IPv6 and DNSSEC deployment.

And YOU can help!

If you’ve already deployed IPv6 or DNSSEC on your network, we’d love to chat with you to link to, or create, the following types of information:

1. Case Studies: We’d be happy to work with you on a written and/or video case study on how you deployed the new technology, your challenges, the business case you presented to management, results, benefits, etc.
2. Tutorials: Do you have a tutorial you made for your systems administrators/network engineers/etc. to walk them through the process? We’d love to share it to help others on their path.
3. Other Resources: Do you have training documents, best practices guidelines, videos, websites, or anything else you’d like to share to help others deploy new technologies faster?

If you haven’t deployed IPv6 or DNSSEC on your network yet, we’d love to chat with you, too! We already have a lot of in-depth resources for you to view and put into practice, but only you can tell us what’s missing.

1. Still need the basics, why these new technologies are important, and why you need to start today?
2. What do you need to get started? Is there a knowledge gap we can fill to help you on your way?
3. Are you stuck somewhere in the middle of the process? What technical how-to resources would get you moving again?

You’re busy. We get it. This industry moves fast and you’ve got your hands full keeping your networks updated and secure from the threat of the day. But these standards are the future of the Internet, and your organization must prepare if it wants to stay competitive in tomorrow’s IT world. Join us to help define how the global, nonprofit Internet Society can best serve your deployment information needs. We are here to listen and WILL produce the resources you need.

Talk to us in the comments below, talk to us on social media, talk to us at an ION Conference, talk to us in person; just let us know how we can help!

Today we kick off our first guest blog of the year. Thanks Anurag. Enjoy!

Guest blog post by Anurag Bhatia

The Domain Names System (DNS) remains one of the most central and essential parts of the Internet because of the simple and efficient way in which it converts domain names that we can read (like teamarin.net) into machine-friendly IP addresses (like 65.49.79.131).

This blog post discusses about how DNS works in the case of next version of Internet Protocol i.e IPv6.

As many of you already know, there are address records known as “A records“ in DNS which help to connect a host-name with an IPv4 address. Just like A records in IPv4, IPv6 features quad A records which are written as AAAA records.

One core feature of a contemporary IPv6 site is its ability to “dual stack” (to connect to both IPv4 & IPv6 networks). In dual stack mode, IPv6 is preferred if it’s available, but if it isn’t, the connection will fall back to IPv4. What this means is that each domain or sub-domain name with dual stack support will need both an A record and AAAA record.

IPv6 has been available from quite some time, and most DNS hosting services offered by registrars, hosting companies and independent players support AAAA records. If you try adding a new record, you will very likely find AAAA record in the “record type“ list.

If you are running your own DNS server (say on BIND), you can add an AAAA record in the host’s file just like you add an A record.

For example:

teamarin.net. 3600 IN AAAA 2001:470:1:97::4131:4f83


These components are the host-name, the TTL for record, followed by class (IN), type of record – AAAA, and IPv6 Address of the host.

Once setup, you can also look these records up using “AAAA” with dig or nslookup.

Using dig:

anurag@laptop:~$ dig teamarin.net aaaa +short
2001:470:1:97::4131:4f83

Using nslookup:

anurag@laptop:~$ nslookup
> set type=aaaa
> teamarin.net
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
teamarin.net has AAAA address 2001:470:1:97::4131:4f83

This gives the IPv6 address associated with domain name TeamARIN.net.

There is no difference in the way the CNAME records work. If you have the www.domain.com CNAME as domain.com – creating AAAA records for domain.com will also support IPv6 for www.domain.com because it acts like an alias for the main domain. You can still, however, create an AAAA record for www.domain.com if you’d like. TeamARIN.net has created a record for both.

anurag@laptop:~$ dig teamarin.net aaaa +short
2001:470:1:97::4131:4f83

anurag@laptop:~$ dig www.teamarin.net aaaa +short
2001:470:1:97::4131:4f83

So far this blog post has looked at forward DNS in IPv6.

Reverse DNS can be set up in a similar manner. If you are running your own email server, you must setup reverse DNS that points IP address to host-names used by an email server. This plays an important part in SMTP authentication.

Just like in IPv4 reverse DNS, an in-addr.apra. zone is used, in IPv6, an ip6.arpa. zone is used. Therefore, the IPv6 address 2001:470:1:97::4131:4f83 rDNS PTR record points to TeamARIN.net.

This is accomplished by simply adding an entry for ipv6.arpa. zone:

3.8.f.4.1.3.1.4.0.0.0.0.0.0.0.0.7.9.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. PTR teamarin.net.


You can do a reverse DNS lookup for IPv6 address by using dig -x, just like in IPv4.

Using dig:

anurag@laptop:~$ dig -x 2001:470:1:97::4131:4f83 +short
teamarin.net.

Using nslookup:

anurag@laptop:~$ nslookup
> set type=ptr
> 2001:470:1:97::4131:4f83
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
3.8.f.4.1.3.1.4.0.0.0.0.0.0.0.0.7.9.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa name = teamarin.net.

This is how forward and reverse DNS works in IPv6. I hope you will find this post useful.

Anurag Bhatia,
System & Network Administrator
Cloudaccess.net
http://anuragbhatia.com

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements made by a guest blog post. ARIN shall not be liable for any representations, omissions or errors contained in a guest blog post.