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.