Posts Tagged Internet service provider
This post begins a series that will create a sample IPv6 address plan for a medium sized company with multiple office sites and multiple hosting locations.
In prior posts, I’ve written about IPv6 address plans in general and shown an especially interesting plan from UCSD.EDU. This post begins to “do the math” for a hypothetical company to produce a concrete addressing plan. This company is similar to my employer but I’ve thrown in a few things that we don’t have that many other more typical companies will have.
For the purpose of this thought experiment, we’ll use a company that looks like this:
- six office locations (cities)
- three co-location facilities that host consumer-facing services
- is part of a larger multi-national, but there is no higher-level single global network
For the office locations we’ll use these criteria:
- around 5000 employees total
- some locations have multiple large groups
- most users have at least four devices that need an IP address, many have six and some have 10
- two of the locations have their own Internet connections as well as a connection on the internal WAN
- some locations have multiple Internet connections from multiple providers
The co-location facilities look like this:
- up to 5000 hosts (or instances) per location
- multiple Internet connections from multiple providers
- each location houses sub-facilities that are leased to other business units (separate private clouds and the like)
- each sub-facility needs to be independently routable via separate ISPs (not all use the same ISPs)
- also used for Disaster Recovery (DR) for the offices
With this information, we can begin to create the IPv6 address plan. Creating the plan begins with determining the Assigned Global Routing Prefix and subnet sizes and concludes with subnet numbering and routing plans.
The constraints we have to work within are:
- The assignment of the Global Routing Prefix is gone by an Internet Registrar according to their policies. You must justify the size of the allocation you request.
- Subnets are “always” on a /64 boundary (host identifiers are “always” 64 bits)
- “Sites” are groups of subnets on a /48 boundary
- Only networks with prefixes at /48 or larger are considered “publicly routable” by most ISPs. They won’t announce routing data for anything smaller.
Next time, I’ll look at these constraints and how they factor into the size of a desired Global Routing Prefix and creating a site and subnet plan.
Last year brought us World IPv6 (test) day on June 8. Dozens of content providers, network backbones and other technical groups came together to do a live test of IPv6 in production. Results were very good, and provided enough evidence that planning for a real, permanent cutover to full “dual stack” was practical.
However, there were enough issues that many of the participants took down their IPv6 sites after the experiment.
But this year, it’s gonna be real. June 6 2012 is World IPv6 Launch Day. The same big names and many other are participating. More importantly, some of the major providers of CPE (customer premise equipment) AKA “home routers” are committed as well.
Cisco and D-Link are committed to shipping “home equipment” with compliant IPv6 stacks and Ipv6 enabled by default by this date. Facebook, Google, Bing and Yahoo! will all permanently enable IPv6 for their main sites. In the US, AT&T, Comcast and Time-Warner will activate IPv6 for at “significant” portions of their home wireline customers.
And this time, it’s permanent. Unlike the 24 hour experiment last year, this is a permanent change. I expect that all the participants will have to shake out configuration issues and software bugs after the launch, but at least now they are committed to making IPv6 work for everyone, from now on.
The only thing that might make this better would be commitments from the operating system vendors. Apple, Microsoft and the Linux community already have known issues that will need to be addressed. Having the home router providers commit to some level of IPv6 support (firmware upgrades) for at least some currently shipping products would also be good, but I suspect they would rather sell new gear.
- World IPv6 Launch on June 6, 2012, To Bring Permanent IPv6 Deployment (internetsociety.org)
- The first is to get AAAA (quad-A) records into your DNS system. At that point clients can ask for the AAAA records over IPv4 and everything will work just fine.
- The second is for you to actually serve your DNS zones over IPv6.
- The third is to get hooked into the global IPv6 DNS system, so that you (and others) can resolve your IPv6 addresses.
In this post, we will deal with the third part, ensuring that all the DNS servers needed to resolve my AAAA records are IPv6 capable. This step isn’t strictly necessary since, as I pointed out before, there’s nothing wrong with serving your AAAA records via IPv4.
First, let’s take a look at the symptoms of my problem:
$ dig -6 +short +trace ipv6.thuktun.org aaaa ;; connection timed out; no servers could be reached
What has happened here is that there is no authoritative DNS server that can be reached via IPv6. So, what’s the problem?
One thing that I’ve never mentioned is that “my” local DNS server is a hidden master. It holds all the zone files, but is not advertised. My advertised public DNS servers are elsewhere, and they pick up my zone data via AXFR whenever I make changes and they are sent a NOTIFY. So, while my local server has all the zone data, it will never be queried during a normal DNS lookup. The advertised DNS servers, the slaves, actually serve all the answers.
It turns out that there are two problems here:
- My external slave name servers aren’t IPv6 capable;
- My resolv.conf has no IPv6 name servers listed.
My external nameservers are run by a friend at his organization’s datacenter. They aren’t prepared to serve DNS over IPv6, and won’t be any time soon. The fastest way to fix this is to move my external DNS to a DNS hosting provider that is IPv6 capable. Fortunately, I can get IPv6 DNS from the same place that I get my IPv6 tunnel: Hurricane Electric.
Using their DNS slave server setup page, I can easily make Hurricane’s DNS servers be my public slave DNS servers. I do have to ensure that their DNS servers can do zone transfers from my hidden master, which is mostly handled by using the the allow-transfer statement in my Bind config files, which is left as an exercise for the student.
After setting up the slave servers at Hurricane, I can wait for them to zone transfer my data to their servers. This can take 5-10 minutes for the first transfer.
At this point, there are three completely independent sets of name servers that have correct data for my domain:
- My home hidden master
- The current advertised DNS servers at my friend’s organization
- The as-yet unadvertised DNS servers at Hurricane Electric
All that remains is to remove the advertisements for the “old” servers and to add advertisements for the new servers. This is done at your domain registrar. Fortunately, my registrar is Register4Less, and their DNS system can take IPv6 addresses. In fact, it was easier than I expected. Unlike some other registrars I’ve used in the past, at Register4Less, you enter the names of your DNS servers, not the IP addresses. Register4Less resolved the hostnames ns1-ns5.e.net and created NS records for both the IPv4 and IPv6 addresses.
There’s still one step left, and that’s to add some IPv6 name servers to my resolv.conf file. I could use the five DNS servers that Hurricane Electric has advertised, but I’ll go one step farther. I’ll use the anycast DNS server address that Hurricane gave me when I established my tunnel:
$ more /etc/resolv.conf nameserver 22.214.171.124 ;; IPv4 nameservers from my ISP nameserver 126.96.36.199 nameserver 188.8.131.52 nameserver 2001:470:20::2 ;; IPv6 anycast name server from HE.NET
And now here’s a full “trace” of IPv6 DNS resolution:
$ dig -6 +trace ipv6.thuktun.org aaaa ; <<>> DiG 9.7.3 <<>> -6 +trace ipv6.thuktun.org aaaa ;; global options: +cmd . 79981 IN NS g.root-servers.net. . 79981 IN NS j.root-servers.net. . 79981 IN NS a.root-servers.net. . 79981 IN NS i.root-servers.net. . 79981 IN NS h.root-servers.net. . 79981 IN NS l.root-servers.net. . 79981 IN NS c.root-servers.net. . 79981 IN NS b.root-servers.net. . 79981 IN NS d.root-servers.net. . 79981 IN NS m.root-servers.net. . 79981 IN NS f.root-servers.net. . 79981 IN NS e.root-servers.net. . 79981 IN NS k.root-servers.net. ;; Received 509 bytes from 2001:470:20::2#53(2001:470:20::2) in 31 ms org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS b2.org.afilias-nst.org. ;; Received 436 bytes from 2001:7fe::53#53(i.root-servers.net) in 157 ms thuktun.org. 86400 IN NS ns5.he.net. thuktun.org. 86400 IN NS ns4.he.net. thuktun.org. 86400 IN NS ns2.he.net. thuktun.org. 86400 IN NS ns3.he.net. ;; Received 112 bytes from 2001:500:c::1#53(b0.org.afilias-nst.org) in 188 msipv6.thuktun.org. 28800 IN AAAA 2001:470:67:84::10 ;; Received 62 bytes from 2001:470:500::2#53(ns5.he.net) in 28 ms
And I’m done with DNS. Now I can go on to some other services, like SSH, FTP, HTTP, etc.