Sam Hartman (hartmans) wrote,
Sam Hartman

Better Living Through IPV6

I seem to have found a use for IPV6: better automated tunnel and NAT traversal management. It all started when my mail server ate its disk. I've decided to replace it and I think it likely I'll replace it with a xen box. All too often I've wished to to set up a wiki, or some other web service that is reasonably stable. Running it on the colo box would be fine except for the security issues. Also, xen would provide better staging for upgrades, etc. And besides, the less I have to let go with both hands for a colo box, the better. But the networking for xen is a bitch. The ideal solution would be to allocate global IPV4 addresses for each virtual machine. I might be able to get away with that provided that I did a bunch of ugly routing tricks and provided that I never had several people over to my apartment needing IP addresses. The obvious thing to do would be to assign private-use IP addresses to the xen domains. Thinking about this though, it makes managing them hard. I cannot ssh from outside the xen environment to one of the domains. I could of course play evil NAT tricks, but getting Kerberos and other things like that working would be challenging. I could tunnel that net 10 to my laptop wherever I am and back to my apartment. Hmm, what's a good way of setting up the tunnel. Ugh, that's going to be a messy.

You know, if I were using IPV6 I'd have all the addresses I need, or so I'm told. You know, I actually could do that. I could have a 6-to-4 address on the colo box and assign a subnet to the xen domains. I could destination-NAT through ports for the IPV4 external services like web and mail. But for management I could connect using the domain 0 as a IPV6 router for 6-to-4. Each VM would get its own IPV6 address on a 6-to-4 subnet behind domain 0. Using teredo or 6-to-4 I could guarantee that my laptop always had a useful IPV6 address, even behind a NAT. I could similarly set up 6-to-4 at my apartment so that I could easily connect to management interfaces from there.

I've done most of the work to support this. In particular, I wrote scripts to easily manage 6-to-4 on Linux. I have two prefixes at home. The first is based on the inner tunnel address of my home router. That's nice and stable, but the problem with using that prefix is that traffic goes over the tunnel. So, I created another prefix based on my comcast address. That's somewhat stable as Comcast doesn't renumber often, but not stable enough I want to put it in DNS. It does use moderately efficient routing at least for talking to other 6-to-4 nodes. I mark the stable prefix as not preferred, so that the source selection algorithm will prefer other addresses, but it will still be available for inbound connections.

Tags: hack

  • Making our Community Safe: the FSF and rms

    I felt disgust and horror when I learned yesterday that rms had returned to the FSF board. When rms resigned back in September of 2019, I was Debian…

  • Good Job Debian: Compatibility back to 1999

    So, I needed a container of Debian Slink (2.1), released back in 1999. I expected this was going to be a long and involved process. Things didn't…

  • Forged Email

    Last night, a series of forged emails was sent to a number of places around the Debian, Ubuntu and Free Software communities. The meat of the mail…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.