-
Notifications
You must be signed in to change notification settings - Fork 11
IPv6
With 6to4, totally a cleaner alternative to NatBusting.
First steps have been made, by separating out the sender_addr from the zuid, and making clients aware that if it's 16 bytes long, it's an ipv6 address. zwgc already uses getnameinfo for reverse lookups.
Things that still need to happen:
- The code needs to be swept for places that only refer to a sockaddr_in, or only transmit a sockaddr_in, etc.
- The client needs to work out that it has a routable ipv6 address and all the servers it wants to talk to
do as well.
- In ipv6 mode, the zuid, instead of including the address verbatim, needs to xor the address down to four bytes.
- The server should rebroadcast the observed origin of the packet rather than where the client thinks it is.
A discussion between myself(kcr) (odd depths) and raeburn (even depths), that started with IPv6 and wandered into NatBusting:
>>>>> How much thought have you given to zephyr over ipv6? >>>>> Specifically, how would you handle the z_uid field? >>>> >>>> I thought about it a bit while the sourceforge project still seemed >>>> viable, but not much recently. >>>> >>>> The options I recall depend on whether we want to be able to keep >>>> treating the uid field as containing the source address. >>>> >>>> Eventually we could push out new software permitting a 16-byte IPv6 >>>> address (or, make a real "UID" field of random bytes, and additional >>>> fields for timestamp and address?), but older clients won't go away >>>> immediately and will need the server to translate the message format >>>> to hold just four bytes of address, which still have to work as part >>>> of a UID field. A hash or random value would confuse clients trying >>>> to display senders' addresses or host names, but a fixed 0.0.0.0 (or >>>> whatever) would increase the chance of UID collisions. And the server >>>> would have to keep track of the type of each subscribed client. (If >>>> the latest code supports both krb4 and krb5 clients -- does it? -- >>>> then I assume something like that would already have to be in place.) >>>> >>>> A quicker approach is just to deprecate the notion of the uid >>>> containing the actual sender's address, and make them just four bytes >>>> randomly chosen by the sender and unchecked by the server. I don't >>>> remember if the brain-dump protocol makes use of that field for the >>>> actual client address. But some clients like zwgc already have built >>>> in the notion that you can get the sender's address out, so that would >>>> be a downgrade in functionality and would annoy people who display >>>> that info. >>> >>> My tentative plan is to add a real z_sender_addr packet field, and >>> deprecate the address in z_uid.zuid_addr. It would remain the same for >>> ipv4 clients, and be a xor of the four 32 bit fields of the address in the >>> ipv6 case. >> >> Sounds good. >> >>> This will slightly break old clients, but I would anticipate many people >>> updating their clients in the near future... >> >> If updates for krb5 are still needed, sure, but if the krb5 code has >> already gotten out there, what additional incentive would they have to >> update? > > It's not terribly widespread as of yet; the people who've gotten it are the > sort of people we know who are comfortable pulling from a subversion > repository. > > Anyway, the final "release" of the krb5 code will probably include simple > IPv4 support for a real address field. > >> >>> (library-wise, I would add a z_sender_addr_family into the struct, >>> determined by the size of the Z-coded address) >>> >>>> Using IPv6 also makes it more likely that the client will have >>>> multiple addresses available -- in fact, it'll typically have an IPv4 >>>> address and one or more IPv6 addresses, in an -- so client processes >>>> should probably ask zhm what local address (and address family) is >>>> being used to contact the Zephyr servers in a given galaxy when >>>> sending via zhm, if it's not happening already. (Does Then zhm would >>>> also be the place to drop in a little hack to, oh, for example, >>>> provide clients with the local address from your VPN even though the >>>> Cisco driver fails to associate that address with any visible >>>> interface. (I once worked out the gdb breakpoint actions necessary to >>>> get Adium to use the correct address while I was on a VPN.) In many >>>> cases it may wind up being the same address for all Zephyr servers, >>>> but if IPv6 works better to some (or some are IPv6-only), and some are >>>> IPv4 only (which will probably be true for a while), you might not >>>> want to rely on that. >>> >>> Secretly i think z_sender_addr gets filled in server side. I think the VPN >>> stuff can just be made to start working if you take the approach of just >>> assuming that you can contact the client on the address that it came from. >> >> This might work. I'd be a little concerned it could mess things up in >> the NAT case (e.g., register an address/port and user location for a >> client that is not reachable, but keep showing the user as logged in). > > Does a UDP port unreachable propagate back to userspace? Keeping track of > whether there's anyone home is going going to be a necessary part of > dealing with NATs
It can. I think you need to use connected sockets, though. So zephyrd could do it if it suspected a problem with a particular client, but probably couldn't do it separately for every client. And I don't recall if you can easily have both a wildcard listener and a connected socket using the same local port number.
Perhaps if you listened for raw IP packets you could collect the data too.
>>>> How do we tell if a galaxy supports IPv6? Perhaps we could look up >>>> SRV records and see if the hosts listed have IPv6 addresses, but if >>>> some of the server hosts are IPv6 capable and some not, the admins >>>> would have to invent new names with IPv4 addresses only, but that's >>>> probably fine. >>> >>> [SRV] >>> >>> Well, we find out what our servers are via some mechanism, and then we do >>> DNS lookups on them. If they return AAAA records... >>> >>> I don't think a mixed ipv4-ipv6 server configuration makes any sense at all >>> and I'm fine not supporting that. >> >> You mean some servers supporting IPv6 and some not? I could see >> wanting to set it up (e.g., an offsite server that doesn't have IPv6 >> access), but no really strong argument for it, and I don't think it's >> worth the effort. > > If you're mostly supporting ipv6 and you choose to place your offsite > server somewhere that not only doesn't have ipv6 connectivity but _also_ > blocks 6to4, I have _no_ sympathy. > >> I can certainly imagine mixed IPv6-capable and -incapable clients >> spread across the net, so each server would have to support both >> address families. > > Oh, sure. > >>>> How do we manage the transition and testing, once the IPv6-capable >>>> zephyrd code is distributed? If we turn on IPv6 on one server and not >>>> on another, clients sending from the second cannot contact subscribers >>>> using the first via IPv6. We could say "don't advertise IPv6 until >>>> it's fully enabled", but do we need a testing strategy that allows for >>>> turning on one at a time? >>> >>> I need to think some more about that. There may be something of a leap of >>> faith involved. >>> >>>> What do we do about servers with multiple IPv6 addresses (or multiple >>>> addresses in general)? I doubt the clients are checking addresses, >>>> but exchanges between zephyrd processes might care about the source >>>> addresses. >>> >>> Well, assuming kerberos works in that case... >>> >>>> Only tangentially related: I'd like to see zhm and zephyrd >>>> periodically refresh their ideas of the servers available -- looking >>>> up SRV records if hostnames aren't configured locally or re-reading a >>>> config file if they are, and re-mapping the names to addresses. That >>>> would allow for more dynamic updating of the set of Zephyr servers, >>> >>> Probably a good idea. >>> >>>> and for running a Zephyr server on a machine with an address that >>>> might change (e.g., using a provider-supplied IPv6 block that gets >>>> renumbered, either explicitly by the provider or by using 6to4 and an >>>> ISP-provided single IPv4 address). Using SRV records could >>> >>> oog. >>> >>>> conceivably allow for port number changes if desirable too, e.g., when >>>> running multiple zephyrd processes on a machine for testing or other >>>> reasons, or if a firewall config issue means you can forward a port to >>>> the machine running zephyrd, but maybe the port number you'd want is >>>> in use on the firewall already; I haven't thought about that too much. >>>> >>>> I'd really like to see IPv6+krb5 Zephyr happen. It probably won't >>>> help as many people any time soon as, say, incorporating some NAT >>>> traversal technology (upnp?) would, though I haven't thought about how >>>> to deal with zhm in that sort of case, if you've got multiple client >>>> systems behind one NAT. (There are other NAT workarounds, mostly >>> >>> Well, presumably different clients get natted to different ports. >> >> Sure, but we'd also have multiple hostmanagers hiding behind one IP >> address. If one system reboots and sends an HM_FLUSH message, the >> others could lose. > > I think real support for NAT requires ignoring HM_FLUSH messages. >
I suppose we could do something like probing all the clients on the "host" to see if they're still there, and only discard those that aren't responding.
>> And there are places where the code cares about the host manager >> port number. > > Removed in all but the earliest krb5 code drops. >
Oh, good. I was looking at the old Athena sources.
>>>> involving ssh, but the ones I've seen all have problems.) In the long >>>> term ... I don't know, if Zephyr survives the long term, maybe we'll >>>> have to do both IPv6 and NAT traversal... >>> >>> In the long term, hopefully IPv4 will wither away. And 6to4 and teredo >>> make awfully good nat traversal mechanisms... >> >> They do, but I don't think they're going to catch on terribly well for >> a while -- certainly not with basic router boxes from the cable >> company or bought off the shelf at Radio Shack. Setting up Teredo >> requires code in the client stack, if I recall correctly, not just a >> standard IPv6 stack. > > "apt-get install miredo" suggests that the support for teredo is already > there in the linux ipv6 stack; and rumor has it that 6to4 support has been > shipping in the apple airport for some time.
It wouldn't surprise me if miredo installs some kind of tunnel device or hooks in through an existing generic tunnel device, but it's good that the support is there. I haven't tried using an airport base station in a long time. If you can turn on 6to4, that'd be kind of cool...