Posts Tagged Internet service provider

IPv6 – creating an IPv6 address plan – the hypothetical company

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:

  1. six office locations (cities)
  2. three co-location facilities that host consumer-facing services
  3. 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.

, ,

1 Comment

IPv6 – World IPv6 Launch Day is coming – June 6 2012

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.

I’m not in any area served by any of those ISPs, so I’ll be keeping my tunnel to Hurricane Electric. But I look forward to seeing more big green 6’s in my browser bar after this summer.

, , , , , , ,

Leave a comment

IPv6 DNS Part 3 (authoritative DNS via IPv6 transport)

In this post I’ll finish off DNS by ensuring that I have publicly accessible IPv6 DNS servers. As I pointed out in the first two IPv6 posts, there are three parts of getting to “IPv6 DNS”:

  1. 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.
  2. The second is for you to actually serve your DNS zones over IPv6.
  3. 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 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:

  1. My external slave name servers aren’t IPv6 capable;
  2. 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:

  1. My home hidden master
  2. The current advertised DNS servers at my friend’s organization
  3. 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 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                     ;; IPv4 nameservers from my ISP
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 aaaa

; <<>> DiG 9.7.3 <<>> -6 +trace aaaa
;; global options: +cmd
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
.            79981    IN    NS
;; Received 509 bytes from 2001:470:20::2#53(2001:470:20::2) in 31 ms

org.            172800    IN    NS
org.            172800    IN    NS
org.            172800    IN    NS
org.            172800    IN    NS
org.            172800    IN    NS
org.            172800    IN    NS
;; Received 436 bytes from 2001:7fe::53#53( in 157 ms        86400    IN    NS        86400    IN    NS        86400    IN    NS        86400    IN    NS
;; Received 112 bytes from 2001:500:c::1#53( in 188    28800    IN    AAAA    2001:470:67:84::10
;; Received 62 bytes from 2001:470:500::2#53( in 28 ms

And I’m done with DNS. Now I can go on to some other services, like SSH, FTP, HTTP, etc.

, , , ,

1 Comment

%d bloggers like this: