Why reading books is still important
I finally got around to reading my copy of IPv6 Network Administration and in chapter 4 there's a section that deals with transition mechanisms which covers the kinds of problems I've been trying to solve with STFL. When I was first digging around the net to see what people had done about allowing IPv6 clients to connect to IPv4 only applications, I found some elusive references to something from the KAME project called faithd. All I could find out about it at the time was that it seemed to be half implemented in user space, and half in the kernel of FreeBSD, but it seems to have been lost in the mists of time. While the book also refers to it, there is also mention of RFC 3142 which describes something called TRT, or Transport Relay Translation. I now have a proper name for what I'm trying to do! That's why reading books is still important.
The solution described in the RFC is pretty much exactly what I've been thinking of, except for the following differences:
Name Resolution
Or the way the DNS is configured for the service. The approach I've been thinking of is pretty simple - assign an IPv6 address to the service you want to offer, add an AAAA record to DNS for that service, run STFL on that IPv6 address and forward the requests to the IPv4 address and port where the application server actually runs. While RFC 3142 does allude to doing it this way, it also talks about using a custom resolver library or DNS server to automatically convert the IPv4 address into an IPv6 address (the don't mention it specifically, but I guess they're talking about 6to4 which is described in RFC 3056).
Service Granularity
My philosophy is simple. You have one application (in my personal case it's Apache 1.3 on OpenBSD) that is not IPv6 compatible but you want to serve IPv6 clients with. So all you do is spark up an application on an equivalent port on an IPv6 address and just ferry the TCP packets back and forth. If you have more than one application you want to do this for, then you simply fire up additional STFL instances. The RFC seems to suggest making an entire IPv4 address and all its TCP and UDP services available on the same IPv6 address (hence the need for mangling resolver). I guess this is why the reference implementation need a kernel level component, and is probably why it never seemed to get off the ground - that's some pretty complicated stuff you need to do!
The solution described in the RFC is pretty much exactly what I've been thinking of, except for the following differences:
Name Resolution
Or the way the DNS is configured for the service. The approach I've been thinking of is pretty simple - assign an IPv6 address to the service you want to offer, add an AAAA record to DNS for that service, run STFL on that IPv6 address and forward the requests to the IPv4 address and port where the application server actually runs. While RFC 3142 does allude to doing it this way, it also talks about using a custom resolver library or DNS server to automatically convert the IPv4 address into an IPv6 address (the don't mention it specifically, but I guess they're talking about 6to4 which is described in RFC 3056).
Service Granularity
My philosophy is simple. You have one application (in my personal case it's Apache 1.3 on OpenBSD) that is not IPv6 compatible but you want to serve IPv6 clients with. So all you do is spark up an application on an equivalent port on an IPv6 address and just ferry the TCP packets back and forth. If you have more than one application you want to do this for, then you simply fire up additional STFL instances. The RFC seems to suggest making an entire IPv4 address and all its TCP and UDP services available on the same IPv6 address (hence the need for mangling resolver). I guess this is why the reference implementation need a kernel level component, and is probably why it never seemed to get off the ground - that's some pretty complicated stuff you need to do!
posted by Chris Read at 13:25
0 comments
