RFC 2133

RFC 2133: Basic Socket Interface Extensions for IPv6 🎀

okay so bestie, this one is RFC 2133, and it's all about giving the sockets API a glow-up so it can handle IPv6 ✨. It was written by R. Gilligan (Freegate), S. Thomson (Bellcore), J. Bound (Digital), and W. Stevens (Consultant). It's an Informational document, dated April 1997 🌸. The header doesn't list anything it obsoletes or updates, so it's just a standalone little gem 💎.

Status of this Memo 📜

This memo is here to give information to the Internet community 🫶. It does not specify an Internet standard of any kind, and it's free to distribute with no limits 🦋.

Abstract ✨

The sockets API is basically the de facto standard way TCP/IP apps talk to the network 💅. It was built for Unix back in the early 1980s, but it's since shown up on a ton of non-Unix systems too. Because of that, TCP/IP apps written with sockets have been super portable, and we want IPv6 apps to have that same portability 🥹.

The catch is that the sockets API needs some changes to support IPv6, and this memo is where those changes are spelled out 🔥. The big ones are a new socket address structure for carrying IPv6 addresses, new address conversion functions, and some new socket options 🧚. The goal is to give TCP and UDP apps access to the basic IPv6 features they need, including multicasting, while changing as little as possible and keeping existing IPv4 apps fully compatible 💖. The more advanced IPv6 stuff (raw sockets and access to the IPv6 extension headers) lives in another document, cited as [5] 📚.

Table of Contents 🍓

1.  Introduction ................................................  2
2.  Design Considerations .......................................  3
2.1.  What Needs to be Changed ..................................  3
2.2.  Data Types ................................................  5
2.3.  Headers ...................................................  5
2.4.  Structures ................................................  5
3.  Socket Interface ............................................  5
3.1.  IPv6 Address Family and Protocol Family ...................  5
3.2.  IPv6 Address Structure ....................................  6
3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
3.5.  The Socket Functions ......................................  8
3.6.  Compatibility with IPv4 Applications ......................  9
3.7.  Compatibility with IPv4 Nodes .............................  9
3.8.  IPv6 Wildcard Address ..................................... 10
3.9.  IPv6 Loopback Address ..................................... 11
4.  Interface Identification .................................... 12
4.1.  Name-to-Index ............................................. 13
4.2.  Index-to-Name ............................................. 13
4.3.  Return All Interface Names and Indexes .................... 14
4.4.  Free Memory ............................................... 14
5.  Socket Options .............................................. 14
5.1.  Changing Socket Type ...................................... 15
5.2.  Unicast Hop Limit ......................................... 16
5.3.  Sending and Receiving Multicast Packets ................... 17
6.  Library Functions ........................................... 19
6.1.  Hostname-to-Address Translation ........................... 19
6.2.  Address To Hostname Translation ........................... 22
6.3.  Protocol-Independent Hostname and Service Name Translation  22
6.4.  Socket Address Structure to Hostname and Service Name ..... 25
6.5.  Address Conversion Functions .............................. 27
6.6.  Address Testing Macros .................................... 28
7.  Summary of New Definitions .................................. 29
8.  Security Considerations ..................................... 31
9.  Acknowledgments ............................................. 31
10.  References ................................................. 31
11.  Authors' Addresses ......................................... 32

---

1. Introduction 🌈

okay so IPv4 addresses are 32 bits long, but IPv6 interfaces get identified by 128-bit addresses 😭. The socket interface makes the size of an IP address really obvious to apps, and basically every TCP/IP app on BSD-based systems knows how big an IP address is 💀. So any part of the API that exposes addresses has to be changed to fit the bigger IPv6 size 🙈. IPv6 also brings new features, like the flow label and priority, and some of those need to be visible to apps through the API ✨. This memo defines a set of extensions to the socket interface that handle the bigger address size and the new IPv6 features 🦋.

2. Design Considerations 💅

There are a few important things to keep in mind when changing an API this well-worn 👑:

• The API changes should give both source and binary compatibility for programs written against the original API 🫶. That means existing program binaries should keep working on a system that supports the new API. Existing apps that get recompiled and run on that system should also keep working. Basically, the IPv6 API changes should not break existing programs 💖.
• The changes should be as small as possible, so converting existing IPv4 apps to IPv6 is easier 🧚.
• Where possible, apps should be able to use this API to talk to both IPv6 and IPv4 hosts 🌸. Apps should not need to know which type of host they're talking to 🙈.
• IPv6 addresses carried in data structures should be 64-bit aligned 🔥. This matters for getting optimum performance on 64-bit machine architectures 💜.

Because providing IPv4 compatibility in the API is so important, these extensions are explicitly designed to run on machines that fully support both IPv4 and IPv6 🎀. A subset of this API could probably be designed for systems that only support IPv6, but this memo doesn't cover that 🦋.

2.1. What Needs to be Changed 🍓

The socket interface API is made up of a few distinct parts:

• Core socket functions.
• Address data structures.
• Name-to-address translation functions.
• Address conversion functions.

The core socket functions are the ones that handle things like setting up and tearing down TCP connections, and sending and receiving UDP packets 🌈. They were designed to be transport independent ✨. When protocol addresses get passed as function arguments, they're carried via opaque pointers 🧚. Each protocol the socket functions support has its own protocol-specific address data structure 📚. When using the socket functions, applications have to cast pointers to those protocol-specific address structures into pointers to the generic "sockaddr" address structure 💅. The socket functions themselves don't need to change for IPv6, but a new IPv6-specific address data structure is needed 👑.

The "sockaddr_in" structure is the protocol-specific data structure for IPv4 🌸. It actually includes 8 octets of unused space, and it's tempting to use that space to stretch sockaddr_in over to IPv6 😭. Unfortunately, sockaddr_in isn't big enough to hold the 16-octet IPv6 address plus the other info it needs, like the address family and port number 💀. So a new address data structure has to be defined for IPv6 🙈.

The name-to-address translation functions in the socket interface are gethostbyname() and gethostbyaddr() 🔥. These must be modified to support IPv6, and the semantics have to provide 100% backward compatibility for existing IPv4 apps while also giving IPv6 support to new apps 💖. On top of that, the POSIX 1003.g work in progress [4] specifies a new, protocol-independent hostname-to-address translation function 🦋. That function can also be used with IPv6 ✨.

The address conversion functions, inet_ntoa() and inet_addr(), convert IPv4 addresses between binary and printable form 🧚. They're pretty specific to 32-bit IPv4 addresses 🫶. So the authors designed two analogous functions that convert both IPv4 and IPv6 addresses, and they take an address type parameter so they can be extended to other protocol families later 🌈.

Finally, a few miscellaneous features are needed to support IPv6 🎀. New interfaces are needed for the IPv6 flow label, priority, and hop limit header fields 💜. New socket options are needed to control sending and receiving IPv6 multicast packets 🔥.

The socket interface will be enhanced in the future to give access to other IPv6 features 👑. Those extensions are described in [5] 📚.

2.2. Data Types 🌸

The data types of the structure elements in this memo are meant to be examples, not absolute requirements 🙈. Wherever possible, POSIX 1003.1g data types are used 💅. Here's the naming scheme: u_intN_t means an unsigned integer of exactly N bits (for example, u_int16_t), and u_intNm_t means an unsigned integer of at least N bits (for example, u_int32m_t) 🦋. The authors also assume the argument data types from 1003.1g when that's possible, like how the final argument to setsockopt() is a size_t value 🧚. Whenever buffer sizes get specified, the POSIX 1003.1 size_t data type is used, such as for the two length arguments to getnameinfo() ✨.

2.3. Headers 📚

When function prototypes and structures are shown, the memo also shows the headers that have to be #included so that the item gets defined 💖.

2.4. Structures 💜

When structures are described, the members shown are the ones that must appear in an implementation 🔥. An implementation may also define additional, nonstandard members 🌈.

The member ordering shown for a structure is the recommended ordering, given alignment considerations of multibyte members 🎀. An implementation may still order the members differently 🦋.

3. Socket Interface 🧚

This section specifies the socket interface changes for IPv6 ✨.

3.1. IPv6 Address Family and Protocol Family 👑

A new address family name, AF_INET6, is defined in <sys/socket.h> 🌸. The AF_INET6 definition distinguishes between the original sockaddr_in address data structure and the new sockaddr_in6 data structure 💅.

A new protocol family name, PF_INET6, is also defined in <sys/socket.h> 🫶. Like most of the other protocol family names, it's usually defined to have the same value as the matching address family name 🍓:

    #define PF_INET6        AF_INET6

PF_INET6 is used as the first argument to the socket() function to indicate that an IPv6 socket is being created 🔥.

---

Part 1 of 6 is done, bestie 🦋 Part 2 picks up at Section 3.2 (the IPv6 Address Structure), so stay tuned 💖🌈

3.2. IPv6 Address Structure ✨

okay so there's a brand new data structure to hold ONE single IPv6 address, and it's giving clean 💅

#include <netinet/in.h>

struct in6_addr {
    u_int8_t  s6_addr[16];      /* IPv6 address */
}

this struct is basically an array of sixteen 8-bit elements, which together make up one 128-bit IPv6 address 🦋 the address is stored in network byte order, so keep that in your head bestie 🧠

---

3.3. Socket Address Structure for 4.3BSD-Based Systems 🎀

okay so in the socket interface, every protocol suite gets its own protocol-specific data structure to carry addresses 💖 the cool part is that each one can be cast into a protocol-independent structure called "sockaddr" 🫶 each of them has a "family" field that overlays the "sa_family" of the sockaddr structure, and that field tells you what type of data structure you're looking at 👑

the sockaddr_in structure is the protocol-specific one for IPv4. applications use it to pass addresses between themselves and the system in the socket functions 🌸 for IPv6, this structure is defined:

#include <netinet/in.h>

struct sockaddr_in6 {
    u_int16m_t      sin6_family;    /* AF_INET6 */
    u_int16m_t      sin6_port;      /* transport layer port # */
    u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
    struct in6_addr sin6_addr;      /* IPv6 address */
};

this structure is designed to be compatible with the sockaddr data structure used in the 4.3BSD release 🍓

the sin6_family field tells you this is a sockaddr_in6 structure. it overlays the sa_family field when the buffer is cast to a sockaddr data structure 🧚 the value of this field must be AF_INET6 💜

the sin6_port field holds the 16-bit UDP or TCP port number 🔥 it's used the same way as the sin_port field of the sockaddr_in structure, and the port number is stored in network byte order ✨

the sin6_flowinfo field is a 32-bit field that holds two pieces of info: the 24-bit IPv6 flow label and the 4-bit priority field 🦋 the contents and interpretation of this member are unspecified at this time, so no drama there 🙈

the sin6_addr field is a single in6_addr structure (the one from the previous section) 💅 it holds one 128-bit IPv6 address, stored in network byte order 🫶

the ordering of elements in this structure is specifically designed so that sin6_addr is aligned on a 64-bit boundary. that's done for optimum performance on 64-bit architectures, which is honestly so iconic 👑

notice that the sockaddr_in6 structure will normally be larger than the generic sockaddr structure 👀 on many existing implementations, sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both being 16 bytes. any existing code that makes this assumption needs to be examined carefully when converting to IPv6 🚨

---

3.4. Socket Address Structure for 4.4BSD-Based Systems 🌈

okay so the 4.4BSD release has a small but incompatible change to the socket interface 🙃 the "sa_family" field of the sockaddr structure went from a 16-bit value to an 8-bit value, and the space that was saved got used for a length field called "sa_len" 💀 this means the sockaddr_in6 structure from the previous section cannot be correctly cast into the newer sockaddr structure 😭 so for systems based on 4.4BSD, there's an alternative IPv6 address structure:

#include <netinet/in.h>

#define SIN6_LEN

struct sockaddr_in6 {
    u_char          sin6_len;       /* length of this struct */
    u_char          sin6_family;    /* AF_INET6 */
    u_int16m_t      sin6_port;      /* transport layer port # */
    u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
    struct in6_addr sin6_addr;      /* IPv6 address */
};

the only differences from the 4.3BSD variant are the length field and the family field changing to an 8-bit data type 🍓 every other field is defined exactly like in the previous section 💖

systems that provide this version of sockaddr_in6 must also declare SIN6_LEN when they include the <netinet/in.h> header 🧚 this macro lets applications tell whether they're being built on a system that supports the 4.3BSD or 4.4BSD variant. main character energy for the macro, honestly 🎀

---

3.5. The Socket Functions 🦋

okay so applications call the socket() function to create a socket descriptor, which represents a communication endpoint 🫶 the arguments to socket() tell the system which protocol to use, and what format address structure will be used in later functions 👑 for example, to create an IPv4/TCP socket, applications make the call:

s = socket(PF_INET, SOCK_STREAM, 0);

to create an IPv4/UDP socket, applications make the call:

s = socket(PF_INET, SOCK_DGRAM, 0);

applications may create IPv6/TCP and IPv6/UDP sockets by simply using the constant PF_INET6 instead of PF_INET in the first argument 🌸 so an IPv6/TCP socket looks like this:

s = socket(PF_INET6, SOCK_STREAM, 0);

and an IPv6/UDP socket looks like this:

s = socket(PF_INET6, SOCK_DGRAM, 0);

once the application has created a PF_INET6 socket, it must use the sockaddr_in6 address structure when passing addresses into the system 💅 the functions the application uses for that are:

bind()
connect()
sendmsg()
sendto()

the system will use the sockaddr_in6 address structure to return addresses to applications that are using PF_INET6 sockets 🧚 the functions that return an address from the system to an application are:

accept()
recvfrom()
recvmsg()
getpeername()
getsockname()

no changes to the syntax of the socket functions are needed to support IPv6 🙌 that's because all of the "address carrying" functions use an opaque address pointer and carry an address length as a function argument. it's giving flexible, no cap ✨

---

3.6. Compatibility with IPv4 Applications 🌷

okay so there's a huge base of applications using the original API, and systems must provide complete source and binary compatibility with that API 💖 which means systems must keep supporting PF_INET sockets and the sockaddr_in address structure 🫶 applications must be able to create IPv4/TCP and IPv4/UDP sockets using the PF_INET constant in socket(), as described in the previous section 🎀

applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets at the same time, all within the same process 🔥 the whole point is that applications using the original API should keep operating as they did on systems that only supported IPv4 🌈 that means they should keep interoperating with IPv4 nodes too. they're not left behind, bestie 🫶

---

3.7. Compatibility with IPv4 Nodes 🦋

okay so the API also has a different kind of compatibility: IPv6 applications can interoperate with IPv4 applications ✨ this uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing architecture specification [2] 🧚 this format lets the IPv4 address of an IPv4 node be represented as an IPv6 address. the IPv4 address gets encoded into the low-order 32 bits, and the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF 💜 IPv4-mapped addresses are written like this:

::FFFF:<IPv4-address>

these addresses are often generated automatically by the gethostbyname() function when the specified host only has IPv4 addresses (as described in Section 6.1) 👑

applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or to send UDP packets to IPv4 nodes 🌸 they do this by encoding the destination's IPv4 address as an IPv4-mapped IPv6 address and passing that address, inside a sockaddr_in6 structure, in the connect() or sendto() call 🍓 when applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or to receive UDP packets from IPv4 nodes, the system returns the peer's address using a sockaddr_in6 structure encoded this way, in the accept(), recvfrom(), or getpeername() call 💖

few applications will likely need to know which type of node they're interoperating with 🙈 but for the ones that do, the IN6_IS_ADDR_V4MAPPED() macro is provided, and it's defined in Section 6.6 🫶

---

3.8. IPv6 Wildcard Address 💅

okay so the bind() function lets applications select the source IP address of UDP packets and TCP connections, but applications often want the system to pick the source address for them 🧚 with IPv4, you specify the address as the symbolic constant INADDR_ANY (called the "wildcard" address) in the bind() call, or you just skip bind() entirely 🌈

since the IPv6 address type is a structure (struct in6_addr), a symbolic constant can be used to initialize an IPv6 address variable, but it can't be used in an assignment 😭 so systems provide the IPv6 wildcard address in two forms ✨

the first version is a global variable named "in6addr_any", which is an in6_addr structure. its extern declaration is defined in <netinet/in.h>:

extern const struct in6_addr in6addr_any;

applications use in6addr_any similarly to how they use INADDR_ANY in IPv4 🦋 for example, to bind a socket to port number 23 but let the system select the source address, an application could use this code:

struct sockaddr_in6 sin6;
 . . .
sin6.sin6_family = AF_INET6;
sin6.sin6_flowinfo = 0;
sin6.sin6_port = htons(23);
sin6.sin6_addr = in6addr_any;  /* structure assignment */
 . . .
if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
        . . .

the other version is a symbolic constant named IN6ADDR_ANY_INIT, defined in <netinet/in.h> 🎀 this constant can be used to initialize an in6_addr structure:

struct in6_addr anyaddr = IN6ADDR_ANY_INIT;

note that this constant can be used ONLY at declaration time 🚨 it can NOT be used to assign a previously declared in6_addr structure. for example, the following code will not work:

/* This is the WRONG way to assign an unspecified address */
struct sockaddr_in6 sin6;
 . . .
sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */

be aware that the IPv4 INADDR_xxx constants are all defined in host byte order, but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx externals are defined in network byte order 🙈💜

3.9. IPv6 Loopback Address 🦋

okay so sometimes apps need to send UDP packets to, or start TCP connections to, services running on the local node 🏠 In IPv4 they just use the constant IPv4 address INADDR_LOOPBACK in their connect(), sendto(), or sendmsg() call.

IPv6 has a loopback address too, for reaching local TCP and UDP services. Like the unspecified address, it comes in two forms: a global variable and a symbolic constant 💅

The global variable is an in6_addr structure named "in6addr_loopback." Its extern declaration is in <netinet/in.h>:

extern const struct in6_addr in6addr_loopback;

Apps use in6addr_loopback the same way IPv4 apps use INADDR_LOOPBACK (but watch out for the byte ordering difference from the end of the previous section 👀). For example, to open a TCP connection to the local telnet server, an app could do this:

struct sockaddr_in6 sin6;
 . . .
sin6.sin6_family = AF_INET6;
sin6.sin6_flowinfo = 0;
sin6.sin6_port = htons(23);
sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
 . . .
if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
        . . .

The symbolic constant is IN6ADDR_LOOPBACK_INIT, defined in <netinet/in.h>. It can ONLY be used at declaration time, like this:

struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;

Just like IN6ADDR_ANY_INIT, this constant can't be used in an assignment to a previously declared IPv6 address variable 🙅‍♀️

---

4. Interface Identification 🌸

This API uses an interface index (a small positive integer) to identify the local interface a multicast group is joined on (Section 5.3). The advanced API [5] also uses these same interface indexes to identify the interface a datagram is received on, or the interface a datagram is sent out of.

Interfaces are usually known by names like "le0", "sl1", "ppp2", and so on. On Berkeley-derived implementations, when an interface is made known to the system, the kernel gives it a unique positive integer called the interface index. These start at 1, and 0 is never used for an interface index. There can be gaps, so a particular positive interface index might not have a current interface attached to it.

This API defines two functions that map between an interface name and index, a third that returns all the interface names and indexes, and a fourth that frees the dynamic memory the third one allocated. How these functions are implemented is up to the implementation 🛠️ 4.4BSD implementations can use the existing sysctl() function with the NET_RT_LIST command. Other implementations might want to use ioctl() for this instead.

4.1. Name-to-Index 🔍

The first function maps an interface name to its corresponding index.

#include <net/if.h>

unsigned int  if_nametoindex(const char *ifname);

If the specified interface doesn't exist, the return value is 0.

4.2. Index-to-Name 🏷️

The second function maps an interface index to its corresponding name.

#include <net/if.h>

char  *if_indextoname(unsigned int ifindex, char *ifname);

The ifname argument must point to a buffer of at least IFNAMSIZ bytes, where the interface name matching the specified index gets returned. (IFNAMSIZ is also defined in <net/if.h>, and its value includes a terminating null byte at the end of the interface name.) That same pointer is the function's return value. If there's no interface matching the specified index, NULL is returned.

4.3. Return All Interface Names and Indexes 📋

The final function returns an array of if_nameindex structures, one structure per interface.

#include <net/if.h>

struct if_nameindex {
  unsigned int   if_index;  /* 1, 2, ... */
  char          *if_name;   /* null terminated name: "le0", ... */
};

struct if_nameindex  *if_nameindex(void);

The end of the array is marked by a structure with an if_index of 0 and an if_name of NULL. The function returns a NULL pointer if there's an error.

The memory for this array of structures, along with the interface names pointed to by the if_name members, is obtained dynamically. The next function is the one that frees it.

4.4. Free Memory 🧹

The following function frees the dynamic memory that was allocated by if_nameindex().

#include <net/if.h>

void  if_freenameindex(struct if_nameindex *ptr);

The argument to this function must be a pointer that was returned by if_nameindex().

---

5. Socket Options ⭐

A bunch of new socket options are defined for IPv6 💖 All of them live at the IPPROTO_IPV6 level, which means the "level" parameter in getsockopt() and setsockopt() calls is IPPROTO_IPV6 when you use them. Every new option uses the IPV6_ prefix, so it's super clear which ones are for IPv6 ✨

The declaration for IPPROTO_IPV6, the new IPv6 socket options, and related constants in this section come from including <netinet/in.h>.

5.1. Changing Socket Type 🔄

Unix lets open sockets get passed between processes through exec() and other means, and it's really common for apps to pass open sockets across exec() calls. So an app using the original API could pass an open PF_INET socket to an app expecting a PF_INET6 socket. Or an app using the extended API could pass an open PF_INET6 socket to an app using the original API, which only knows how to deal with PF_INET sockets. Either of those could cause problems, because the app that gets the open socket might not know how to decode the address structures returned by later socket functions 😭

To fix this, there's a new setsockopt() option that lets an app "convert" a PF_INET6 socket into a PF_INET socket, and vice versa.

An IPv6 app that gets handed an open socket from an unknown process can use the IPV6_ADDRFORM setsockopt() option to "convert" the socket to PF_INET6. Once that's done, the system returns sockaddr_in6 address structures in subsequent socket functions.

An IPv6 app that's about to pass an open PF_INET6 socket to a program that isn't IPv6 capable can "downgrade" the socket to PF_INET before calling exec(). After that, the system returns sockaddr_in address structures to the app that gets exec()'ed. Be aware that you can't downgrade an IPv6 socket to an IPv4 socket unless every nonwildcard address already associated with the IPv6 socket is an IPv4-mapped IPv6 address 🚨

The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and IPPROTO_IPV6 levels. The only valid option values are PF_INET6 and PF_INET. For example, to convert a PF_INET6 socket to PF_INET, a program would call:

int  addrform = PF_INET;

if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
               (char *) &addrform, sizeof(addrform)) == -1)
    perror("setsockopt IPV6_ADDRFORM");

An app can use IPV6_ADDRFORM with getsockopt() to find out whether an open socket is a PF_INET or PF_INET6 socket. For example:

int  addrform;
size_t  len = sizeof(addrform);

if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
               (char *) &addrform, &len) == -1)
    perror("getsockopt IPV6_ADDRFORM");
else if (addrform == PF_INET)
    printf("This is an IPv4 socket.\n");
else if (addrform == PF_INET6)
    printf("This is an IPv6 socket.\n");
else
    printf("This system is broken.\n");

5.2. Unicast Hop Limit 🦘

A new setsockopt() option controls the hop limit used in outgoing unicast IPv6 packets 🎀 It's called IPV6_UNICAST_HOPS and it's used at the IPPROTO_IPV6 layer. Here's how it's used:

int  hoplimit = 10;

if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
               (char *) &hoplimit, sizeof(hoplimit)) == -1)
    perror("setsockopt IPV6_UNICAST_HOPS");

When IPV6_UNICAST_HOPS is set with setsockopt(), the option value you give is used as the hop limit for all subsequent unicast packets sent via that socket. If the option isn't set, the system picks a default value. The integer hop limit value (called x) gets interpreted like this:

x < -1:        return an error of EINVAL
x == -1:       use kernel default
0 <= x <= 255: use x
x >= 256:      return an error of EINVAL

You can use IPV6_UNICAST_HOPS with getsockopt() to check the hop limit value the system will use for subsequent unicast packets sent via that socket. For example:

int  hoplimit;
size_t  len = sizeof(hoplimit);

if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
               (char *) &hoplimit, &len) == -1)
    perror("getsockopt IPV6_UNICAST_HOPS");
else
    printf("Using %d for hop limit.\n", hoplimit);

5.3. Sending and Receiving Multicast Packets 📡

okay so sending multicast over UDP is lowkey the easiest part 💖 An IPv6 app can just drop an IPv6 multicast address into the address argument of sendto() and that's it, no cap 🦋

There are three socket options at the IPPROTO_IPV6 layer that control some of the parameters for sending multicast packets. Setting them is not required, so apps can send multicast packets without touching any of them ✨ Here's the rundown of the setsockopt() options for sending:

• IPV6_MULTICAST_IF
  • Sets the interface to use for outgoing multicast packets. The argument is the index of the interface to use.
  • Argument type: unsigned int
• IPV6_MULTICAST_HOPS
  • Sets the hop limit to use for outgoing multicast packets 🌸 (Side note: there's a separate option, IPV6_UNICAST_HOPS, for setting the hop limit on outgoing unicast packets, so don't mix them up 🙈) The interpretation of the argument is the same as for IPV6_UNICAST_HOPS:

x < -1:        return an error of EINVAL
x == -1:       use kernel default
0 <= x <= 255: use x
x >= 256:      return an error of EINVAL

• Argument type: int

• IPV6_MULTICAST_LOOP
  • Controls whether outgoing multicast packets sent should be delivered back to the local application. It's a toggle 🎀 If the option is set to 1, multicast packets are looped back. If it is set to 0, they are not.
  • Argument type: unsigned int

The reception side is controlled by two setsockopt() options, and they're summarized here 🧚

• IPV6_ADD_MEMBERSHIP
  • Joins a multicast group on a specified local interface. If the interface index is specified as 0, the kernel chooses the local interface. For example, some kernels look up the multicast group in the normal IPv6 routing table and use the resulting interface 👑
  • Argument type: struct ipv6_mreq
• IPV6_DROP_MEMBERSHIP
  • Leaves a multicast group on a specified interface.
  • Argument type: struct ipv6_mreq

The argument type of both of these options is the ipv6_mreq structure, defined as:

#include <netinet/in.h>

struct ipv6_mreq {
    struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
    unsigned int    ipv6mr_interface; /* interface index */
};

Note that to receive multicast datagrams, a process must join the multicast group and bind the UDP port that the datagrams will be sent to. Some processes also bind the multicast group address to the socket, in addition to the port, so that other datagrams destined for that same port don't get delivered to the socket 💅

---

6. Library Functions 📚

New library functions are needed to do a bunch of operations with IPv6 addresses. We need functions to look up IPv6 addresses in the Domain Name System (DNS) 🌈 Both forward lookup (hostname-to-address translation) and reverse lookup (address-to-hostname translation) need to be supported. We also need functions to convert IPv6 addresses between their binary and textual forms, iykyk 🫶

6.1. Hostname-to-Address Translation 🦋

The commonly used function gethostbyname() stays the same, and so does the hostent structure it returns a pointer to 💖 Existing apps that call this function keep getting only IPv4 addresses, which are the result of a query in the DNS for A records. (We assume the DNS is being used. Some environments may use a hosts file or some other name resolution system, and either of those may get in the way of renumbering 🙈 We also assume that the RES_USE_INET6 resolver option is not set, which we'll describe in more detail shortly.)

Two new changes support IPv6 addresses. First, there's a new function:

#include <sys/socket.h>
#include <netdb.h>

struct hostent *gethostbyname2(const char *name, int af);

The af argument specifies the address family. The default behavior of this function is simple:

• If the af argument is AF_INET, a query is made for A records. If successful, IPv4 addresses are returned and the h_length member of the hostent structure will be 4. Otherwise the function returns a NULL pointer.
• If the af argument is AF_INET6, a query is made for AAAA records. If successful, IPv6 addresses are returned and the h_length member of the hostent structure will be 16. Otherwise the function returns a NULL pointer.

The second change, which adds extra functionality, is a new resolver option, RES_USE_INET6. It's defined by including the <resolv.h> header, and it's provided starting with the BIND 4.9.4 release ✨ There are three ways to set this option:

• The first way is:

res_init();
_res.options |= RES_USE_INET6;

and then call either gethostbyname() or gethostbyname2(). This option then affects only the process that is calling the resolver.

• The second way is to set the environment variable RES_OPTIONS, as in RES_OPTIONS=inet6. (This example is for the Bourne and Korn shells.) This method affects any processes that see this environment variable.
• The third way is to set this option in the resolver configuration file (normally /etc/resolv.conf), and then the option affects all applications on the host. This final method should not be done until all applications on the host are capable of dealing with IPv6 addresses 🚨

There's no priority among these three methods. When the RES_USE_INET6 option is set, two changes happen:

• gethostbyname(host) first calls gethostbyname2(host, AF_INET6) looking for AAAA records, and if that fails, it then calls gethostbyname2(host, AF_INET) looking for A records.
• gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 addresses, with the h_length member of the hostent structure set to 16.

An application must not enable the RES_USE_INET6 option until it is prepared to deal with 16-byte addresses in the returned hostent structure. Seriously, don't skip this one 💀

The following table summarizes how the existing gethostbyname() function, the new gethostbyname2() function, and the new RES_USE_INET6 resolver option work together:

+------------------+---------------------------------------------------+
|                  |              RES_USE_INET6 option                 |
|                  +-------------------------+-------------------------+
|                  |          off            |           on            |
+------------------+-------------------------+-------------------------+
|                  |Search for A records.    |Search for AAAA records. |
| gethostbyname    | If found, return IPv4   | If found, return IPv6   |
| (host)           | addresses (h_length=4). | addresses (h_length=16).|
|                  | Else error.             | Else search for A       |
|                  |                         | records.  If found,     |
|                  |Provides backward        | return IPv4-mapped IPv6 |
|                  | compatibility with all  | addresses (h_length=16).|
|                  | existing IPv4 appls.    | Else error.             |
+------------------+-------------------------+-------------------------+
|                  |Search for A records.    |Search for A records.    |
| gethostbyname2   | If found, return IPv4   | If found, return        |
| (host, AF_INET)  | addresses (h_length=4). | IPv4-mapped IPv6        |
|                  | Else error.             | addresses (h_length=16).|
|                  |                         | Else error.             |
+------------------+-------------------------+-------------------------+
|                  |Search for AAAA records. |Search for AAAA records. |
| gethostbyname2   | If found, return IPv6   | If found, return IPv6   |
| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
|                  | Else error.             | Else error.             |
+------------------+-------------------------+-------------------------+

It's expected that when a typical naive app that calls gethostbyname() today gets modified to use IPv6, it simply switches the program to IPv6 sockets and then enables the RES_USE_INET6 resolver option before calling gethostbyname(). That app will then work with either IPv4 or IPv6 peers 🥰

Note that gethostbyname() and gethostbyname2() are not thread-safe, since both return a pointer to a static hostent structure. But several vendors have defined a thread-safe gethostbyname_r() function that takes four additional arguments. We expect these vendors to also define a gethostbyname2_r() function 🧵

6.2. Address To Hostname Translation 🔁

The existing gethostbyaddr() function already requires an address family argument, so it can work with IPv6 addresses 💜

#include <sys/socket.h>
#include <netdb.h>

struct hostent *gethostbyaddr(const char *src, int len, int af);

One possible source of confusion is how IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses get handled. This is addressed in [6] and involves the following logic:

1. If af is AF_INET6, and if len equals 16, and if the IPv6 address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, set af to AF_INET, and set len to 4.
2. If af is AF_INET, then query for a PTR record in the in-addr.arpa domain.
3. If af is AF_INET6, then query for a PTR record in the ip6.int domain.
4. If the function is returning success, and if af equals AF_INET, and if the RES_USE_INET6 option was set, then the single address that is returned in the hostent structure (a copy of the first argument to the function) is returned as an IPv4-mapped IPv6 address and the h_length member is set to 16.

All four steps listed are performed, in order. The same caveats about a thread-safe version of gethostbyname() that were made at the end of the previous section apply here as well 🌸

6.3. Protocol-Independent Hostname and Service Name Translation ✨

Okay bestie, hostname-to-address translation is done in a protocol-independent way 🦋 using the getaddrinfo() function. It's taken from the Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g (Protocol Independent Interfaces) work in progress specification [4].

The official spec for this function will be the final POSIX standard. We're writing our own independent description because POSIX standards aren't freely available the way IETF documents are 🥺. If there's any discrepancy between this description and the POSIX description, the POSIX description takes precedence 👑.

    #include <sys/socket.h>
    #include <netdb.h>

    int getaddrinfo(const char *hostname, const char *servname,
                    const struct addrinfo *hints,
                    struct addrinfo **res);

The addrinfo structure is defined as:

    #include <sys/socket.h>
    #include <netdb.h>

    struct addrinfo {
      int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME */
      int     ai_family;    /* PF_xxx */
      int     ai_socktype;  /* SOCK_xxx */
      int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
      size_t  ai_addrlen;   /* length of ai_addr */
      char   *ai_canonname; /* canonical name for hostname */
      struct sockaddr  *ai_addr; /* binary address */
      struct addrinfo  *ai_next; /* next structure in linked list */
    };

The return value is 0 if it works, or a nonzero error code if it doesn't 💀. These nonzero error codes from getaddrinfo() are defined in <netdb.h>:

    EAI_ADDRFAMILY  address family for hostname not supported
    EAI_AGAIN       temporary failure in name resolution
    EAI_BADFLAGS    invalid value for ai_flags
    EAI_FAIL        non-recoverable failure in name resolution
    EAI_FAMILY      ai_family not supported
    EAI_MEMORY      memory allocation failure
    EAI_NODATA      no address associated with hostname
    EAI_NONAME      hostname nor servname provided, or not known
    EAI_SERVICE     servname not supported for ai_socktype
    EAI_SOCKTYPE    ai_socktype not supported
    EAI_SYSTEM      system error returned in errno

The hostname and servname arguments are pointers to null-terminated strings or NULL 🧚. One or both of these two arguments must be a non-NULL pointer. In the normal client scenario, both the hostname and servname are specified. In the normal server scenario, only the servname is specified. A non-NULL hostname string can be either a host name or a numeric host address string (so a dotted-decimal IPv4 address or an IPv6 hex address). A non-NULL servname string can be either a service name or a decimal port number.

The caller can optionally pass an addrinfo structure, pointed to by the third argument, to give hints about the type of socket the caller supports 💅. In this hints structure, all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer. Here's how the hint fields work:

• A value of PF_UNSPEC for ai_family means the caller will accept any protocol family.
• A value of 0 for ai_socktype means the caller will accept any socket type.
• A value of 0 for ai_protocol means the caller will accept any protocol.

For example, if the caller handles only TCP and not UDP, then ai_socktype in the hints structure should be set to SOCK_STREAM when getaddrinfo() is called. If the caller handles only IPv4 and not IPv6, then ai_family in the hints structure should be set to PF_INET when getaddrinfo() is called. If the third argument to getaddrinfo() is a NULL pointer, it's the same as if the caller had filled in an addrinfo structure initialized to zero with ai_family set to PF_UNSPEC. Main character energy 🎀.

On a successful return, a pointer to a linked list of one or more addrinfo structures comes back through the final argument 🌈. The caller can process each addrinfo structure in this list by following the ai_next pointer, until a NULL pointer is hit. In each returned addrinfo structure, the three members ai_family, ai_socktype, and ai_protocol are the corresponding arguments for a call to the socket() function. In each addrinfo structure, the ai_addr member points to a filled-in socket address structure whose length is given by the ai_addrlen member.

If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, the caller plans to use the returned socket address structure in a call to bind() 🌸. In this case, if the hostname argument is a NULL pointer, the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.

If the AI_PASSIVE bit is not set in the ai_flags member of the hints structure, the returned socket address structure will be ready for a call to connect() (for a connection-oriented protocol), or for either connect(), sendto(), or sendmsg() (for a connectionless protocol) 🦋. In this case, if the hostname argument is a NULL pointer, the IP address portion of the socket address structure will be set to the loopback address.

If the AI_CANONNAME bit is set in the ai_flags member of the hints structure, then on a successful return, the ai_canonname member of the first addrinfo structure in the linked list will point to a null-terminated string containing the canonical name of the specified hostname 🫶.

All of the information returned by getaddrinfo() is dynamically allocated: the addrinfo structures, the socket address structures, and the canonical host name strings pointed to by the addrinfo structures. To give this information back to the system, the function freeaddrinfo() is called:

    #include <sys/socket.h>
    #include <netdb.h>

    void freeaddrinfo(struct addrinfo *ai);

The addrinfo structure pointed to by the ai argument is freed, along with any dynamic storage pointed to by the structure. This operation is repeated until a NULL ai_next pointer is encountered 🧹.

To help applications print error messages based on the EAI_xxx codes returned by getaddrinfo(), the following function is defined 🙈:

    #include <sys/socket.h>
    #include <netdb.h>

    char *gai_strerror(int ecode);

The argument is one of the EAI_xxx values defined earlier, and the return value points to a string describing the error. If the argument isn't one of the EAI_xxx values, the function still returns a pointer to a string whose contents indicate an unknown error 🤷‍♀️.

---

6.4. Socket Address Structure to Hostname and Service Name ✨

The POSIX 1003.1g specification has no function for the reverse conversion from getaddrinfo(): looking up a hostname and service name when you already have the binary address and port 😭. So we define the following function ourselves:

    #include <sys/socket.h>
    #include <netdb.h>

    int getnameinfo(const struct sockaddr *sa, size_t salen,
                    char *host, size_t hostlen,
                    char *serv, size_t servlen,
                    int flags);

This function looks up an IP address and port number the caller provides in the DNS and system-specific database, then returns text strings for both in buffers the caller provides 🌈. It signals success with a zero return value. A non-zero return value means failure.

The first argument, sa, points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address and port number. The salen argument gives the length of the sockaddr_in or sockaddr_in6 structure.

The function returns the hostname associated with the IP address in the buffer pointed to by the host argument. The caller gives the size of this buffer through the hostlen argument. The service name associated with the port number is returned in the buffer pointed to by serv, and the servlen argument gives the length of this buffer. The caller can say "don't return that string" by passing a zero value for the hostlen or servlen arguments. Otherwise, the caller must provide buffers large enough to hold the hostname and the service name, including the terminating null characters 💖.

Real talk: most systems don't provide constants for the maximum size of a fully-qualified domain name or a service name. So to help the application size its buffers for those two returned strings, the following constants are defined in <netdb.h>:

    #define NI_MAXHOST  1025
    #define NI_MAXSERV    32

The first value is actually defined as the constant MAXDNAME in recent versions of BIND's <arpa/nameser.h> header (older versions of BIND define this constant to be 256). The second is a guess based on the services listed in the current Assigned Numbers RFC 🍓.

The final argument is a flag that changes the default actions of this function. By default, the fully-qualified domain name (FQDN) for the host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is set, only the hostname portion of the FQDN is returned for local hosts.

If the flag bit NI_NUMERICHOST is set, or if the host's name can't be found in the DNS, the numeric form of the host's address is returned instead of its name (for example, by calling inet_ntop() instead of gethostbyaddr()). If the flag bit NI_NAMEREQD is set, an error is returned if the host's name can't be found in the DNS 🙅‍♀️.

If the flag bit NI_NUMERICSERV is set, the numeric form of the service address (for example, its port number) is returned instead of its name. The two NI_NUMERICxxx flags are required to support the "-n" flag that many commands provide 💜.

A fifth flag bit, NI_DGRAM, specifies that the service is a datagram service. It causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (512-514) that have different services for UDP and TCP 👑.

These NI_xxx flags are defined in <netdb.h> along with the AI_xxx flags already defined for getaddrinfo() 🔥.

6.5. Address Conversion Functions 💅

okay so the classic inet_addr() and inet_ntoa() pair turns an IPv4 address between binary and text form, but IPv6 apps need the same kind of help 🫶 so these two functions handle both IPv6 and IPv4 addresses:

    #include <sys/socket.h>
    #include <arpa/inet.h>

    int inet_pton(int af, const char *src, void *dst);

    const char *inet_ntop(int af, const void *src,
                          char *dst, size_t size);

inet_pton() takes an address in its standard text presentation form and turns it into numeric binary form ✨ The af argument says which family the address belongs to, and right now AF_INET and AF_INET6 are the two supported families. src points at the string you're handing in, and dst points at a buffer where the numeric address gets stored. The address comes back in network byte order 🌸 inet_pton() returns 1 if the conversion works, 0 if the input isn't a valid IPv4 dotted-decimal string or a valid IPv6 address string, or -1 with errno set to EAFNOSUPPORT if af is unknown. The calling application has to make sure the buffer at dst is big enough for the numeric address, so 4 bytes for AF_INET or 16 bytes for AF_INET6 🎀

If af is AF_INET, the function takes a string in the standard IPv4 dotted-decimal form:

    ddd.ddd.ddd.ddd

where ddd is a one to three digit decimal number between 0 and 255. Heads up, bestie 👀 a lot of existing inet_addr() and inet_aton() implementations happily accept nonstandard input like octal numbers, hexadecimal numbers, or fewer than four numbers. inet_pton() does not accept any of those formats 🙈

If af is AF_INET6, the function accepts a string in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2] 🦋

inet_ntop() goes the other way, turning a numeric address into a text string that's ready for display 💜 The af argument is AF_INET or AF_INET6. src points at a buffer holding an IPv4 address when af is AF_INET, or an IPv6 address when af is AF_INET6. dst is the buffer where the resulting text string gets written, and size tells the function how big that buffer is. The application has to pass a non-NULL dst. For IPv6 addresses the buffer needs to be at least 46-octets, and for IPv4 addresses at least 16-octets. To make life easier when declaring buffers for string-form addresses, <netinet/in.h> defines these two constants:

    #define INET_ADDRSTRLEN    16
    #define INET6_ADDRSTRLEN   46

inet_ntop() returns a pointer to the buffer holding the text string if the conversion works, and NULL otherwise. When it fails, errno is set to EAFNOSUPPORT if af is invalid, or to ENOSPC if the result buffer is too small 🥺

---

6.6. Address Testing Macros 🔥

these macros are the vibe check for special IPv6 addresses 😌

    #include <netinet/in.h>

    int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
    int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
    int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
    int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
    int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
    int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
    int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);

    int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
    int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
    int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
    int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
    int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);

The first seven macros return true if the address is of the type they name, and false otherwise. The last five check the scope of a multicast address. They return true if the address is a multicast address of the named scope, and false if it's either not multicast at all or multicast but in a different scope 💖

---

7. Summary of New Definitions ✨

okay this is the cheat sheet 🧚 it lists the constants, structures, and extern definitions from this memo, sorted by header:

  <net/if.h>      IFNAMSIZ
  <net/if.h>      struct if_nameindex{};

  <netdb.h>       AI_CANONNAME
  <netdb.h>       AI_PASSIVE
  <netdb.h>       EAI_ADDRFAMILY
  <netdb.h>       EAI_AGAIN
  <netdb.h>       EAI_BADFLAGS
  <netdb.h>       EAI_FAIL
  <netdb.h>       EAI_FAMILY
  <netdb.h>       EAI_MEMORY
  <netdb.h>       EAI_NODATA
  <netdb.h>       EAI_NONAME
  <netdb.h>       EAI_SERVICE
  <netdb.h>       EAI_SOCKTYPE
  <netdb.h>       EAI_SYSTEM
  <netdb.h>       NI_DGRAM
  <netdb.h>       NI_MAXHOST
  <netdb.h>       NI_MAXSERV
  <netdb.h>       NI_NAMEREQD
  <netdb.h>       NI_NOFQDN
  <netdb.h>       NI_NUMERICHOST
  <netdb.h>       NI_NUMERICSERV
  <netdb.h>       struct addrinfo{};

  <netinet/in.h>  IN6ADDR_ANY_INIT
  <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
  <netinet/in.h>  INET6_ADDRSTRLEN
  <netinet/in.h>  INET_ADDRSTRLEN
  <netinet/in.h>  IPPROTO_IPV6
  <netinet/in.h>  IPV6_ADDRFORM
  <netinet/in.h>  IPV6_ADD_MEMBERSHIP
  <netinet/in.h>  IPV6_DROP_MEMBERSHIP
  <netinet/in.h>  IPV6_MULTICAST_HOPS
  <netinet/in.h>  IPV6_MULTICAST_IF
  <netinet/in.h>  IPV6_MULTICAST_LOOP
  <netinet/in.h>  IPV6_UNICAST_HOPS
  <netinet/in.h>  SIN6_LEN
  <netinet/in.h>  extern const struct in6_addr in6addr_any;
  <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
  <netinet/in.h>  struct in6_addr{};
  <netinet/in.h>  struct ipv6_mreq{};
  <netinet/in.h>  struct sockaddr_in6{};

  <resolv.h>      RES_USE_INET6

  <sys/socket.h>  AF_INET6
  <sys/socket.h>  PF_INET6

and this second list is the function and macro prototypes from the memo, sorted by header 🎀

<arpa/inet.h>   int inet_pton(int, const char *, void *);
<arpa/inet.h>   const char *inet_ntop(int, const void *,
                                       char *, size_t);

<net/if.h>      char *if_indextoname(unsigned int, char *);
<net/if.h>      unsigned int if_nametoindex(const char *);
<net/if.h>      void if_freenameindex(struct if_nameindex *);
<net/if.h>      struct if_nameindex *if_nameindex(void);

<netdb.h>       int getaddrinfo(const char *, const char *,
                                 const struct addrinfo *,
                                 struct addrinfo **);
<netdb.h>       int getnameinfo(const struct sockaddr *, size_t,
                                char *, size_t, char *, size_t, int);
<netdb.h>       void freeaddrinfo(struct addrinfo *);
<netdb.h>       char *gai_strerror(int);
<netdb.h>       struct hostent *gethostbyname(const char *);
<netdb.h>       struct hostent *gethostbyaddr(const char *, int, int);
<netdb.h>       struct hostent *gethostbyname2(const char *, int);

<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);

---

8. Security Considerations 🔐

this one is serious, bestie 😤 IPv6 brings a bunch of new security mechanisms, and a lot of them need to be reachable from applications. A companion memo describing the socket interface extensions for IPv6 security is still being written [3] 👀

---

9. Acknowledgments 🫶

huge thank yous to everyone who sent suggestions and feedback across the many revisions of this document 💖 that includes Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazuhiko Yamamoto 🌈

The getaddrinfo() and getnameinfo() functions come from an earlier Work in Progress by Keith Sklower 🧚 As that document notes, William Durst, Steven Wise, Michael Karels, and Eric Allman had lots of useful discussions about protocol-independent name-to-address translation, and they reviewed early drafts of Keith Sklower's original proposal. Eric Allman built the first prototype of getaddrinfo() 🔥 The observation that naming a service by its name and service pair is enough to connect to it without caring about protocol details came from Marshall Rose, in a proposal to X/Open for a "Uniform Network Interface" 👑

Craig Metz contributed a ton to this document 💅 Ramesh Govindan made a bunch of contributions and co-authored an earlier version of this memo ⭐

---

10. References 📚

[1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.

[2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995.

[3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets", Work in Progress.

[4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT 6.3, November 1995.

[5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6", Work in Progress.

[6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6", Work in Progress.

---

11. Authors' Addresses 🦋

Robert E. Gilligan (Freegate Corporation):

Robert E. Gilligan
Freegate Corporation
710 Lakeway Dr.  STE 230
Sunnyvale, CA 94086

Phone: +1 408 524 4804
EMail: gilligan@freegate.net

Susan Thomson (Bell Communications Research):

Susan Thomson
Bell Communications Research
MRE 2P-343, 445 South Street
Morristown, NJ 07960

Phone: +1 201 829 4514
EMail: set@thumper.bellcore.com

Jim Bound (Digital Equipment Corporation):

Jim Bound
Digital Equipment Corporation
110 Spitbrook Road ZK3-3/U14
Nashua, NH 03062-2698

Phone: +1 603 881 0400
Email: bound@zk3.dec.com

W. Richard Stevens:

W. Richard Stevens
1202 E. Paseo del Zorro
Tucson, AZ 85718-2826

Phone: +1 520 297 9416
EMail: rstevens@kohala.com