On 12/02/2009, at 2:45 PM, Ian Batterbee wrote:

But wasn't there a big discussion at NZNOG about how applications shouldn't know anything (or care) about the underlying communication protocols being used ?

That'd be nice in theory, however too many applications still expect a particular address family. They will only resolve A records, store an IP address in a 15 character field, or throw around v4 addresses on the wire. Here's a document that started in 1998 about making Unix apps neutral when it comes to the AF. Over 10 years later and apps still make the same mistakes. http://www.kame.net/newsletter/19980604/ Sam.

On Thu, 2009-02-12 at 14:45 +1300, Ian Batterbee wrote:

But wasn't there a big discussion at NZNOG about how applications shouldn't know anything (or care) about the underlying communication protocols being used ?

Yes, and wouldn't it be nice if *libc* didn't want applications to make different calls when using IPv6 addresses vs. IPv4 addresses? So while that's a great theory it first needs people to write libraries that deal with these addresses without having to consider what form they are. One common approach seems to be to switch the application to handle all addresses as IPv6 addresses, mapping IPv4 addresses into their 6-to-4 equivalents. Of course you may still have to maintain an additional bit of information as to whether this is *really* IPv4 or IPv6, but hopefully that can be inside the library rather than outside it, and given the nature of 6-to-4 it can even be stored within the mapped address itself. I believe this is the best approach. Subtleties of behaviour also have effects. An example of one that bit me, is that the Undernet IRC server considers 1 IPv4 address equivalent to 1 IPv6 /64 for rate limiting purposes. While this kind of heuristic works OK with the same values for private and public servers both on NATed LANs and the intartubes for IPv4, for IPv6 everyone on your LAN connecting to your private IRC server will have an IPv6 in the same /64 and rate limiting will kick in unless you completely change the rate limiting values. So that is an example of an application which *needs* to know the type of address in order to be able to make the correct decision. Regards, Andrew McMillan. ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN You can rent this space for only $5 a week. ------------------------------------------------------------------------

On Fri, 2009-02-13 at 12:04 +1300, Perry Lorier wrote:

...

Subtleties of behaviour also have effects. An example of one that bit me, is that the Undernet IRC server considers 1 IPv4 address equivalent to 1 IPv6 /64 for rate limiting purposes. While this kind of heuristic works OK with the same values for private and public servers both on NATed LANs and the intartubes for IPv4, for IPv6 everyone on your LAN connecting to your private IRC server will have an IPv6 in the same /64 and rate limiting will kick in unless you completely change the rate limiting values. So that is an example of an application which *needs* to know the type of address in order to be able to make the correct decision.

Speaking as the person who actually designed that system for Undernet, that behavior was intentional. :)

Sure, which shows how the heuristics used for IPv4 *could* *not* be directly mapped to equally apt heuristics for IPv6, doesn't it? Our server worked fine for years without tuning, right up until the first restart after we added an AAAA record for it. My point is that while it might be a laudable goal to have software that is IPv6/IPv4 agnostic there are still going to be plenty of gotchas out there waiting for people, because the network will behave differently - outside of the fact that the actual addresses happen to be different data types. Many pieces of software, not just IRC servers, imply meaning into a single IPv4 ip address, or a /24, and it is quite likely that those meanings won't have easy equivalents in an IPv6 addressable. Cheers, Andrew. ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN Though a superhero, Bruce Schneier disdains the use of a mask or secret identity as 'security through obscurity'. ------------------------------------------------------------------------

On 12 Feb 2009, at 15:45, Andrew McMillan wrote:

On Thu, 2009-02-12 at 14:45 +1300, Ian Batterbee wrote:

...

But wasn't there a big discussion at NZNOG about how applications shouldn't know anything (or care) about the underlying communication protocols being used ?

Yes, and wouldn't it be nice if *libc* didn't want applications to make different calls when using IPv6 addresses vs. IPv4 addresses?

Surely the bits of libc that are address-family dependent are those that remain entrenched for historical reasons and rely upon data structures that carry endpoint addresses in 32-bit words. That being the case, requiring the use of different APIs seems fairly understandable. It'd be glorious if there was a non-lossy mapping from 128-bit addresses into 32-bit holes in data structures, but if we could do then we could also encode infinite amounts of data into a single bit and travel backwards in time, so perhaps the libc optimisation would not seem so exciting, in context. Joe

...

On Thu, 2009-02-12 at 14:45 +1300, Ian Batterbee wrote:

...

But wasn't there a big discussion at NZNOG about how applications shouldn't know anything (or care) about the underlying communication protocols being used ?

Yes, and wouldn't it be nice if *libc* didn't want applications to make different calls when using IPv6 addresses vs. IPv4 addresses?

Surely the bits of libc that are address-family dependent are those that remain entrenched for historical reasons and rely upon data structures that carry endpoint addresses in 32-bit words. That being the case, requiring the use of different APIs seems fairly understandable.

the BSD sockets layer was designed, from the outset to support multiple address family's (AF's). There is a structure called "struct sockaddr" which represents a "generic" address of some unknown type. It contains a "sa_family" member which tells you what type of address it is (AF_INET meaning IPv4 address, AF_UNIX meaning unix domain socket, and so on). You then cast it to the correct type (struct sockaddr_in for AF_INET, or struct sockaddr_un for AF_UNIX) to get the correct structure for the correct address family. All system calls (bind,connect,accept and so on) take a (struct sockaddr *), and thus can work with any address family. However some of the libc functions didn't consider things in a way that makes IPv6 useful. gethostbyname(3) for instance can return a list of addresses, but they all have to be the same address type (thus you can't get AF_INET and AF_INET6 addresses at the same time), even more annoyingly the programmer doesn't get to ask if they get AF_INET or AF_INET6 sockets back, the call just returns one or the other (ie, only returns AF_INET addresses). This apears to have been "fixed" at some point by 'getipnodebyname' calls which let you specify that you want AF_INET or AF_INET6 (or any other address family) addresses. Not that this really solves the problem. Thus these were all superseeded with getnameinfo(), that given a name can return a list of addresses, in a specific order, of varying address families. So old apps use gethostbyname(), which is a nice trivial interface, that doesn't do what you want. New apps use getnameinfo() which is a useful interface that does what you want, but is slightly more annoying to use (you have to provide a lot more information to it saying what you want), so it involves a lot more typing. Nobody ever uses getipnodebyname(). Things get even more annoying, when you consider (struct sockaddr) was supposed to be big enough to hold any address type. But it's not quite big enough to fit an IPv6 address and all the ancillary information (port number, scopeid and so on), so now there's "struct sockaddr_storage". So if you're allocating space for a generic address you use "sockaddr_storage", if you want to talk about a generic address of unknown type, you use "sockaddr", and if you want ipv4, ipv6 or unix domain sockets, you use sockaddr_in, sockaddr_in6, or sockaddr_un respectively. Then we get into the messy condition of converting addresses to a printable form (not resolving them, just displaying them). The original interface to convert a sockaddr_in to a printable address was to use inet_ntoa(). This does have the problem that it only works on an IPv4 address (sockaddr_in's generally contain an IP address and a port number), and doesn't work with IPv6 addresses at all. Then theres inet_ntop() which can convert an IPv4 or IPv6 address, but you have to figure out if you're talking about IPv4 or IPv6 addresses before you call it, which again, makes it mostly useless and annoying to use. The "modern" way is to use getaddrinfo(), and pass in the AI_PNUMERICHOST flag which then avoids trying to resolve it. If your application specifically wants to talk about just IPv4 addresses it can in theory use "struct in_addr", and struct in6_addr" for IPv6 addresses. Don't do this. :P Converting an application to IPv6 is generally fairly straight forward. Convert the code that called gethostbyname() to getnameinfo(), convert anything that used inet_*to*() to use getnameinfo()/getaddrinfo() with AI_NUMERICHOST. Convert anything that's listen()ing on sockets to also listen on a v6 socket. Things get hairier when you want to step through a list of addresses returned by getnameinfo(). Make sure that some of the "sockaddr"'s become "sockaddr_storages" (But only the ones that allocate space, not ones that refer to a generic address that's allocated elsewhere). And then you have to deal with internal address policies. Where they are displayed, are they stored, or transfered over the network? Are they hashed? are there matches or other bits of code that know about the structure of an IP address being used? Does it use : at the end of an address to represent a port number? Do the internal protocol(s) use : for anything special? This is often where porting an application becomes really difficult.

I don't think I could've found as much insight into the sockets library in a week of searching the intertubes as there is contained in that there email. Bravo! ________________________________ From: Perry Lorier [mailto:perry(a)coders.net] Sent: Mon 16/02/2009 10:58 a.m. To: Joe Abley Cc: NZNOG(a)list.waikato.ac.nz Subject: Re: [nznog] FileMaker Pro 10 - now with IPv6

...

On Thu, 2009-02-12 at 14:45 +1300, Ian Batterbee wrote:

...

But wasn't there a big discussion at NZNOG about how applications shouldn't know anything (or care) about the underlying communication protocols being used ?

Yes, and wouldn't it be nice if *libc* didn't want applications to make different calls when using IPv6 addresses vs. IPv4 addresses?

Surely the bits of libc that are address-family dependent are those that remain entrenched for historical reasons and rely upon data structures that carry endpoint addresses in 32-bit words. That being the case, requiring the use of different APIs seems fairly understandable.

the BSD sockets layer was designed, from the outset to support multiple address family's (AF's). There is a structure called "struct sockaddr" which represents a "generic" address of some unknown type. It contains a "sa_family" member which tells you what type of address it is (AF_INET meaning IPv4 address, AF_UNIX meaning unix domain socket, and so on). You then cast it to the correct type (struct sockaddr_in for AF_INET, or struct sockaddr_un for AF_UNIX) to get the correct structure for the correct address family. All system calls (bind,connect,accept and so on) take a (struct sockaddr *), and thus can work with any address family. However some of the libc functions didn't consider things in a way that makes IPv6 useful. gethostbyname(3) for instance can return a list of addresses, but they all have to be the same address type (thus you can't get AF_INET and AF_INET6 addresses at the same time), even more annoyingly the programmer doesn't get to ask if they get AF_INET or AF_INET6 sockets back, the call just returns one or the other (ie, only returns AF_INET addresses). This apears to have been "fixed" at some point by 'getipnodebyname' calls which let you specify that you want AF_INET or AF_INET6 (or any other address family) addresses. Not that this really solves the problem. Thus these were all superseeded with getnameinfo(), that given a name can return a list of addresses, in a specific order, of varying address families. So old apps use gethostbyname(), which is a nice trivial interface, that doesn't do what you want. New apps use getnameinfo() which is a useful interface that does what you want, but is slightly more annoying to use (you have to provide a lot more information to it saying what you want), so it involves a lot more typing. Nobody ever uses getipnodebyname(). Things get even more annoying, when you consider (struct sockaddr) was supposed to be big enough to hold any address type. But it's not quite big enough to fit an IPv6 address and all the ancillary information (port number, scopeid and so on), so now there's "struct sockaddr_storage". So if you're allocating space for a generic address you use "sockaddr_storage", if you want to talk about a generic address of unknown type, you use "sockaddr", and if you want ipv4, ipv6 or unix domain sockets, you use sockaddr_in, sockaddr_in6, or sockaddr_un respectively. Then we get into the messy condition of converting addresses to a printable form (not resolving them, just displaying them). The original interface to convert a sockaddr_in to a printable address was to use inet_ntoa(). This does have the problem that it only works on an IPv4 address (sockaddr_in's generally contain an IP address and a port number), and doesn't work with IPv6 addresses at all. Then theres inet_ntop() which can convert an IPv4 or IPv6 address, but you have to figure out if you're talking about IPv4 or IPv6 addresses before you call it, which again, makes it mostly useless and annoying to use. The "modern" way is to use getaddrinfo(), and pass in the AI_PNUMERICHOST flag which then avoids trying to resolve it. If your application specifically wants to talk about just IPv4 addresses it can in theory use "struct in_addr", and struct in6_addr" for IPv6 addresses. Don't do this. :P Converting an application to IPv6 is generally fairly straight forward. Convert the code that called gethostbyname() to getnameinfo(), convert anything that used inet_*to*() to use getnameinfo()/getaddrinfo() with AI_NUMERICHOST. Convert anything that's listen()ing on sockets to also listen on a v6 socket. Things get hairier when you want to step through a list of addresses returned by getnameinfo(). Make sure that some of the "sockaddr"'s become "sockaddr_storages" (But only the ones that allocate space, not ones that refer to a generic address that's allocated elsewhere). And then you have to deal with internal address policies. Where they are displayed, are they stored, or transfered over the network? Are they hashed? are there matches or other bits of code that know about the structure of an IP address being used? Does it use : at the end of an address to represent a port number? Do the internal protocol(s) use : for anything special? This is often where porting an application becomes really difficult. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog