Saturday, October 29, 2016
Last week I wrote about not being able to route delegated prefixes as none of the servers seemed to have functionality to update the routing table. Shortly after tweeting this, a colleague replied with a way forward. In case Twitter's memory goes a bit hazy, I'll recap here:
Wednesday, October 19, 2016
To delegate a prefix to downstream, a DHCPv6 server must allocate a free prefix from its pool and then update the router configuration with the new target for that prefix. In our case, the DHCPv6 server and the router are the same machine, so no crazy remote updating is needed. We're running ISC DHCPd at the moment. It turns out, there is no way to update the routing table with this software. Someone has already tried to do this! In our case the IPv6 prefix is static, so there was no need to get a dynamic prefix from upstream. However, the crux of the problem is that while ISC makes hook scripts available for the events, they don't provide the target address to create the route. The linked article was written two years ago. I can find no evidence that anything has changed in that time. If someone out there has gotten this to work with existing software that I haven't found, please let me know.
Thursday, October 13, 2016
Of 46 total sponsors, only 6 have IPv6 enabled on their website, or approximately 13%. It should also be noted that this does not indicate whether these companies have IPv6 support in their product, only that they've cleared the simple hurdle of enabling it for their website.
Particularly interesting here is the one site that is hosted on Amazon. Their site is hosted on a legacy load balancer, which new accounts (VPC) cannot use. I am somewhat hopeful that more Amazon hosted sites will begin to leverage the recently announced IPv6 on CloudFront in the near future.
I plan to continue to meet with folk at these sorts of events and explain the benefits of IPv6 for their projects and the future of the Internet. Hopefully next year's numbers will be much improved.
Monday, March 7, 2016
In the IPv4 world, the utility of having addresses resolvable as hostnames in DNS had sufficient demand that someone set up xip.io. Unfortunately I've never seen such an equivalent for IPv6 addresses, leaving folk to use the bracket notation and hope for the best.
Sunday, February 21, 2016
When I first started my journey to learn IPv6, I could not get native IPv6 at home from my residential ISP. Undeterred, I went to Hurricane Electric; HE offers both an IPv6 certification program that's a great place to start to learning how IPv6 works, and free IPv6 tunnels. I still recommend their certification as a first step to learn IPv6. (If you can't get native IPv6, you should start by asking your ISP for their timeline to offer access to the entire Internet before getting a tunnel. I would like to think that the excuse "no one is asking for IPv6" is no longer used, but the only way to be sure of that is to ask for it.)
I had my IPv6 tunnel, and I made sure I knew the security stance of anything on my home network with an IPv6 address, but I didn't use it much when I wasn't at home. During this time, I've gotten more confident with my ability to secure my home network as I intend.
At the same time, I've started to use my home network as a testbed for ideas; it's my "proof of concept lab" before I try it at scale at work.
As my ideas have gotten more complicated, I realized I needed a better system for my notes. At work, we use PmWiki, so I decided to use it for my project notes.
I created a new VM for PmWiki, and started to install it. However, I couldn't download PmWiki! Eeek! A quick check showed me that pmwiki.org only had an IPv4 address, and for some reason this VM didn't get a DHCPv4 lease (behind NAT, of course). I really wanted to finish my task, so I used a host that I knew was properly dual-stacked to download, then transferred the tarball from there. I did have to use an intermediate host for its dual-stack visibility into both IPv4 and IPv6 networks, but it didn't take much longer to do that two-step download, and I quickly had PmWiki installed, configured, and running as I wanted.
In fact, it was running so well that I never made time to go back to troubleshoot why this VM host had not gotten an IPv4 address. I could use it when I was at home because I now have native IPv6 (and NAT'd IPv4) at home. I could use it at work because I have dual-stack (native IPv6 and IPv4) there. I was curious to know why it didn't get an IPv4 DHCP lease as expected, but I don't always want to troubleshoot networks when I get home ... that's what I do at work! Several rounds of patches and reboots later, many months later, I noticed that this VM had picked up a DHCP lease, so whatever was broken before wasn't badly broken. My point, though, is not that I was a lazy troubleshooter at home.
My point is that I barely noticed the lack of IPv4 on one of my hosts at home; all I needed to do everything I wanted to do was IPv6. Notably, the reverse would not have been true! Without an IPv6 address on this host at home, I would not have been able to access it while at work without doing a fair amount of port mapping on my home router. With a global IPv6 address, I was able to firewall it to talk only to my home network and to my work network. IPv6 made this easy; I did not miss IPv4 enough to bother figuring out why it didn't work when this VM was created. I would have freaked out without IPv6, and I didn't care about IPv4.
My, how far IPv6 has come! It used to be shiny, and now it's the thing that makes my network easier to use.
Sunday, October 25, 2015
At the All Things Open conference last year, one of the speakers talked of "dorm room ready software". It's wonderful that this plethora of software has become available, increasing the speed of prototyping. However, the only reason this is still possible is because those dorm rooms still have global IP addresses. The computer sitting on the desk can still serve content to the world. As we run out of IPv4 addresses, more and more of us will be closed off behind NATs beyond our control. Poor college students can ill afford hosting services that still have those scarce IPv4 addresses. This creates another barrier to innovation unless we do something.
Tuesday, September 1, 2015
At work today, I helped someone use
ping6 to figure out what to fix on a server that wasn't reachable over IPv6. I have a pretty basic formula that I thought I would share.
I will use this information for the problem host:
nethope@fixme$ ip -6 address show 1: lo:
mtu 65536 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qlen 1000 inet6 2001:db8:2015:3000::5/64 scope global valid_lft forever preferred_lft forever inet6 fe80::201:2ff:fe03:405/64 scope link valid_lft forever preferred_lft forever nethope@fixme$
When I start troubleshooting, I like to start small and expand to ever-wider scopes. One of my college professors said troubleshooting should start with a simple question to which you know the answer, and take small steps from there.
The smallest scope possible is loopback. Since I usually have multiple network interfaces,
ping6 needs to know which one to use. The syntax will vary between operating systems. I used '
ping6 -c3 -I lo ::1' on my Linux, and '
ping6 -c3 ::1%lo0' on my Mac.
ping6 -c3 -I lo ::1
That should work; it should be the question to which you know the answer. If it doesn't work, IPv6 probably isn't configured yet. This command should also work without specifying the interface; if you need to specify the loopback interface then route selection is broken.
Then I expand the scope ever so slightly, all the way up to another easy one, just so I don’t miss some strange condition. Try the link-local address (HINT: it starts with
fe80) for that interface. This traffic also shouldn't hit the network, just this computer and its network interface card.
ping6 -c3 -I eth0 fe80::201:2eff:fe03:405
If that fails, first bounce the interface (
ifdown; ifup if that's an acceptable outage), and then remove and reconfigure IPv6 for that interface. Again, this task is specific for your operating system. Reconfiguring the interface was the solution today!
The next small step: Try the global address for that interface (still on the same machine). Since it’s a global address, you shouldn’t have to specify the interface, but if you get unexpected results, drop it back in to be sure.
ping6 -c3 -I eth0 2001:db8:2015:3000::5
This should work if the previous two steps worked, but if it doesn't, try the same repair procedure as the previous step.
Now I’m finally ready to move beyond the scope of the NIC, all the way out to the router interface, still within the same VLAN. Again, you shouldn't have to specify which interface to use now, but we're troubleshooting so watch out for oddities. If you know it, start with the router's link-local address.
ping6 -c3 -I eth0 fe80::a8bb:ccff:fedd:eeff
ping6 -c3 -I eth0 2001:db8:2015:3000::1
If that fails, look for a problem within the VLAN. Find other IPv6-enabled hosts in the same VLAN (all of them, right? *grin*), and see if they can reach the default router. If no hosts can reach the router, the router needs to be fixed. (I've had to remove then reconfigure IPv6 on a VLAN on a Cisco router, and magically the very same configuration started working again. It hasn't happened in ages, thankfully.) If most hosts can reach the router, look for reasons why this one has problems. Perhaps it is missing IPv6 router advertisements, and can’t determine its IPv6 default router or thinks it can’t reach it. That would be a problem with ICMPv6 or multicast. Since link-local multicast is generally reliable (multicast querier on the router aside), it's probably the host-based firewall.
Next, if available, look outside your VLAN, but stay on your network. Pick anything.
ping6 -c3 -I eth0 2001:db8:2015:3001::101
If that works, your network is probably fine. If it fails, make sure the router has IPv6 routes. Are all VLANs affected, or just some VLANs? I usually test other VLANs at this step, too.
ping6 -c3 -I eth0 www.yoursite.edu
If you want to be sure that DNS isn't the problem, either don't use hostnames, or validate your hostnames with
dig first. However, we're entering the territory where I always use hostnames because I don't remember the numbers.
If the problem shows up at this scope, poke around. Pick two hosts in two VLANs, and try
traceroute6 in both directions (one to the other and other to the one; I detected an OSPFv3 problem that way). Our F5 load balancers make traceroute look odd, so pay more attention to the simple "good, yes, connected" versus "bad, no, couldn't connect" results at first. Try
mtr (a new enough version to support IPv6) and let it run for a while to look for path instability or intermittent packet loss (one weekend when an intermediate router was losing 60% of IPv6 packets).
And then try hosts that aren't on your network, like:
At what step in this process does
ping6 fail? There’s the scope of your problem, and where to concentrate your analysis.