Date: Mon, 26 Mar 2001 12:30:15 -0800 From: "Jonathan Graehl" <jonathan@graehl.org> To: "Jun-ichiro itojun Hagino" <itojun@iijlab.net> Cc: "Freebsd-Net" <freebsd-net@freebsd.org> Subject: RE: proper way to test for INET/INET6? Message-ID: <NCBBLOALCKKINBNNEDDLGECKDNAA.jonathan@graehl.org> In-Reply-To: <20010326045902.481FA7E73@starfruit.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> applications should be written so that it would work on both > IPv4-only, IPv6-only and IPv4/v6 dual stack kernels, by using > getaddrinfo(3) and getnameinfo(3). you do not need to check if you > write applications properly. > > itojun Sometimes we want to hash, compare, or serialize the addresses in a repeatable fashion, not just use them with the sockets API. The abstraction provided by getaddrinfo and getnameinfo is wonderful, but incomplete. Scenario: transparent UDP proxy (or other persistent-UDP-session) server. First time you receive a datagram from a particular client (or after session timeout): bind a new socket, connect to destination, and forward datagram, waiting for replies on that socket to send back to this particular client. Second time you receive a datagram from a particular client (before session timeout), use the existing connected socket for that client to forward the datagram. In order to distinguish between the two cases, we need to hash and compare address/port. It is not possible to effectively listen() and accept() UDP "connections" similar to TCP (it would be very nice if the API did allow such a means of handling a UDP socket, especially if you want to fork a child process to handle a persistent-association UDP service), so we must dispatch on the source address/port of datagrams we receive. Such hashing and comparison can be done more efficiently with functions tailored for IPv4 or IPv6 addresses. Generic sockaddr*-taking library functions could maintain this efficiency. I suppose in theory (since the sin6_flowinfo member of sockaddr_in6 is supposed to be zeroed before the application sees it, and likewise for the sin_zero of sockaddr_in) that a protocol independent comparison/hash of sockaddr structures could simply operate on the raw bytes. In order to serialize a global-scope address (or even to hash/compare), we could simply use the provided numeric string representation. Obviously, any IPv6/4 protocol would have to either explicitly specify the address type, or use IPv4-mapped-IPv6 addresses (regardless of whether some hosts participating have no IPv6 support at all). How about a library function to serialize a generic sockaddr* to/from a compact/unique (byte length, byte type, address) representation? Or if not that, a library function to generate an in6_addr from a sockaddr*? (I believe Ethernet and other address types may also be mapped into the IPv6 address space). I do realize that, if possible, transmission of protocol addresses should be avoided because of evils such as NAT (although IPv6 may one day give us a truly global address space). -- Jonathan Graehl http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NCBBLOALCKKINBNNEDDLGECKDNAA.jonathan>