From dc3fe36727c66dfdbc4264efb590eb109dfd66ec Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 20 Sep 2002 22:47:48 +0000 Subject: [PATCH] new draft --- doc/draft/draft-ietf-ipngwg-rfc2553bis-07.txt | 2045 +++++++++++++++++ ...t => draft-ietf-ipv6-dns-discovery-06.txt} | 117 +- 2 files changed, 2104 insertions(+), 58 deletions(-) create mode 100644 doc/draft/draft-ietf-ipngwg-rfc2553bis-07.txt rename doc/draft/{draft-ietf-ipv6-dns-discovery-05.txt => draft-ietf-ipv6-dns-discovery-06.txt} (84%) diff --git a/doc/draft/draft-ietf-ipngwg-rfc2553bis-07.txt b/doc/draft/draft-ietf-ipngwg-rfc2553bis-07.txt new file mode 100644 index 0000000000..84b43bb73e --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-rfc2553bis-07.txt @@ -0,0 +1,2045 @@ + +IPNG Working Group R.E. Gilligan +INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-07.txt Cache Flow +Obsoletes RFC 2553 S. Thomson + Cisco + J. Bound + J. McCann + Hewlett-Packard + W. R. Stevens + September 2002 + + + Basic Socket Interface Extensions for IPv6 + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + This document is a submission by the Internet Protocol IPv6 Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ipng@sunroof.eng.sun.com mailing list. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + +Abstract + + The de facto standard application program interface (API) for TCP/IP + applications is the "sockets" interface. Although this API was + developed for Unix in the early 1980s it has also been implemented on + a wide variety of non-Unix systems. TCP/IP applications written + using the sockets API have in the past enjoyed a high degree of + portability and we would like the same portability with IPv6 + applications. But changes are required to the sockets API to support + IPv6 and this memo describes these changes. These include a new + socket address structure to carry IPv6 addresses, new address + conversion functions, and some new socket options. These extensions + are designed to provide access to the basic IPv6 features required by + TCP and UDP applications, including multicasting, while introducing a + minimum of change into the system and providing complete + compatibility for existing IPv4 applications. Additional extensions + for advanced IPv6 features (raw sockets and access to the IPv6 + extension headers) are defined in another document [4]. + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 1] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +Table of Contents: + +1. Introduction.................................................3 +2. Design Considerations........................................3 +2.1 What Needs to be Changed....................................4 +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.....................6 +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 +3.10 Portability Additions.....................................11 +4. Interface Identification....................................13 +4.1 Name-to-Index..............................................14 +4.2 Index-to-Name..............................................14 +4.3 Return All Interface Names and Indexes.....................14 +4.4 Free Memory................................................15 +5. Socket Options..............................................15 +5.1 Unicast Hop Limit..........................................15 +5.2 Sending and Receiving Multicast Packets....................16 +5.3 IPV6_V6ONLY option for AF_INET6 Sockets....................18 +6. Library Functions...........................................18 +6.1 Protocol-Independent Nodename and Service Name Translation.19 +6.2 Socket Address Structure to Node Name and Service Name.....23 +6.3 Address Conversion Functions...............................25 +6.4 Address Testing Macros.....................................26 +7. Summary of New Definitions..................................27 +8. Security Considerations.....................................29 +Changes from RFC 2553..........................................29 +Acknowledgments................................................29 +References.....................................................30 +Authors' Addresses.............................................31 + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 2] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +1. Introduction + +While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits long. +The socket interface makes the size of an IP address quite visible to an +application; virtually all TCP/IP applications for BSD-based systems +have knowledge of the size of an IP address. Those parts of the API +that expose the addresses must be changed to accommodate the larger IPv6 +address size. IPv6 also introduces new features (e.g., traffic class +and flowlabel), some of which must be made visible to applications via +the API. This memo defines a set of extensions to the socket interface +to support the larger address size and new features of IPv6. It defines +"basic" extensions that are of use to a broad range of applications. A +companion document, the "advanced" API [4], covers extensions that are +of use to more specialized applications, examples of which include +routing daemons, and the "ping" and "traceroute" utilities. + +The development of this API was started in 1994 in the IETF IPng working +group. The API has evolved over the years, published first in RFC 2133, +then again in RFC 2553, and reaching its final form in this document. + +As the API matured and stabilized, it was incorporated into the Open +Group's Networking Services (XNS) specification, issue 5.2, which was +subsequently incorporated into a joint Open Group/IEEE/ISO standard [3]. + +Effort has been made to ensure that this document and [3] contain the +same information with regard to the API definitions. However, the +reader should note that this document is for informational purposes +only, and that the official standard specification of the sockets API is +[3]. + +It is expected that any future standardization work on this API would be +done by the Open Group Base Working Group [6]. + +It should also be noted that this document describes only those portions +of the API needed for IPv4 and IPv6 communications. Other potential +uses of the API, for example the use of getaddrinfo() and getnameinfo() +with the AF_UNIX address family, are beyond the scope of this document. + + + +2. Design Considerations + +There are a number of important considerations in designing changes to +this well-worn API: + + - The API changes should provide both source and binary + compatibility for programs written to the original API. That + is, existing program binaries should continue to operate when + run on a system supporting the new API. In addition, existing + applications that are re-compiled and run on a system supporting + the new API should continue to operate. Simply put, the API + changes for IPv6 should not break existing programs. An additional + mechanism for implementations to verify this is to verify the new + symbols are protected by Feature Test Macros as described in [3]. + (Such Feature Test Macros are not defined by this RFC.) + + - The changes to the API should be as small as possible in order + to simplify the task of converting existing IPv4 applications to + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 3] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + IPv6. + + - Where possible, applications should be able to use this + API to interoperate with both IPv6 and IPv4 hosts. Applications + should not need to know which type of host they are + communicating with. + + - IPv6 addresses carried in data structures should be 64-bit + aligned. This is necessary in order to obtain optimum + performance on 64-bit machine architectures. + +Because of the importance of providing IPv4 compatibility in the API, +these extensions are explicitly designed to operate on machines that +provide complete support for both IPv4 and IPv6. A subset of this API +could probably be designed for operation on systems that support only +IPv6. However, this is not addressed in this memo. + + + +2.1 What Needs to be Changed + +The socket interface API consists of a few distinct components: + + - Core socket functions. + + - Address data structures. + + - Name-to-address translation functions. + + - Address conversion functions. + +The core socket functions -- those functions that deal with such things +as setting up and tearing down TCP connections, and sending and +receiving UDP packets -- were designed to be transport independent. +Where protocol addresses are passed as function arguments, they are +carried via opaque pointers. A protocol-specific address data structure +is defined for each protocol that the socket functions support. +Applications must cast pointers to these protocol-specific address +structures into pointers to the generic "sockaddr" address structure +when using the socket functions. These functions need not 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. This data structure actually includes 8-octets of unused space, +and it is tempting to try to use this space to adapt the sockaddr_in +structure to IPv6. Unfortunately, the sockaddr_in structure is not +large enough to hold the 16-octet IPv6 address as well as the other +information (address family and port number) that is needed. So a new +address data structure must be defined for IPv6. + +IPv6 addresses are scoped [2] so they could be link-local, site, +organization, global, or other scopes at this time undefined. To +support applications that want to be able to identify a set of +interfaces for a specific scope, the IPv6 sockaddr_in structure must +support a field that can be used by an implementation to identify a set +of interfaces identifying the scope for an IPv6 address. + +The IPv4 name-to-address translation functions in the socket interface + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 4] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +are gethostbyname() and gethostbyaddr(). These are left as is, and new +functions are defined which support both IPv4 and IPv6. + +The IPv4 address conversion functions -- inet_ntoa() and inet_addr() -- +convert IPv4 addresses between binary and printable form. These +functions are quite specific to 32-bit IPv4 addresses. We have designed +two analogous functions that convert both IPv4 and IPv6 addresses, and +carry an address type parameter so that they can be extended to other +protocol families as well. + +Finally, a few miscellaneous features are needed to support IPv6. New +interfaces are needed to support the IPv6 traffic class, flow label, and +hop limit header fields. New socket options are needed to control the +sending and receiving of IPv6 multicast packets. + +The socket interface will be enhanced in the future to provide access to +other IPv6 features. These extensions are described in [4]. + + + + +2.2 Data Types + +The data types of the structure elements given in this memo are intended +to track the relevant standards. uintN_t means an unsigned integer of +exactly N bits (e.g., uint16_t). The sa_family_t and in_port_t types +are defined in [3]. + + + +2.3 Headers + +When function prototypes and structures are shown we show the headers +that must be #included to cause that item to be defined. + + + +2.4 Structures + +When structures are described the members shown are the ones that must +appear in an implementation. Additional, nonstandard members may also +be defined by an implementation. As an additional precaution +nonstandard members could be verified by Feature Test Macros as +described in [3]. (Such Feature Test Macros are not defined by this +RFC.) + +The ordering shown for the members of a structure is the recommended +ordering, given alignment considerations of multibyte members, but an +implementation may order the members differently. + + + +3. Socket Interface + +This section specifies the socket interface changes for IPv6. + + + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 5] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +3.1 IPv6 Address Family and Protocol Family + +A new address family name, AF_INET6, is defined in . 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 defined in . +Like most of the other protocol family names, this will usually be +defined to have the same value as the corresponding address family name: + + #define PF_INET6 AF_INET6 + +The AF_INET6 is used in the first argument to the socket() function to +indicate that an IPv6 socket is being created. + + + +3.2 IPv6 Address Structure + +A new in6_addr structure holds a single IPv6 address and is defined as a +result of including : + + struct in6_addr { + uint8_t s6_addr[16]; /* IPv6 address */ + }; + +This data structure contains an array of sixteen 8-bit elements, which +make up one 128-bit IPv6 address. The IPv6 address is stored in network +byte order. + +The structure in6_addr above is usually implemented with an embedded +union with extra fields that force the desired alignment level in a +manner similar to BSD implementations of "struct in_addr". Those +additional implementation details are omitted here for simplicity. + +An example is as follows: + +struct in6_addr { + union { + uint8_t _S6_u8[16]; + uint32_t _S6_u32[4]; + uint64_t _S6_u64[2]; + } _S6_un; +}; +#define s6_addr _S6_un._S6_u8 + + + +3.3 Socket Address Structure for 4.3BSD-Based Systems + +In the socket interface, a different protocol-specific data structure is +defined to carry the addresses for each protocol suite. Each protocol- +specific data structure is designed so it can be cast into a protocol- +independent data structure -- the "sockaddr" structure. Each has a +"family" field that overlays the "sa_family" of the sockaddr data +structure. This field identifies the type of the data structure. + +The sockaddr_in structure is the protocol-specific address data + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 6] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +structure for IPv4. It is used to pass addresses between applications +and the system in the socket functions. The following sockaddr_in6 +structure holds IPv6 addresses and is defined as a result of including +the header: + + struct sockaddr_in6 { + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + +This structure is designed to be compatible with the sockaddr data +structure used in the 4.3BSD release. + +The sin6_family field identifies this as a sockaddr_in6 structure. This +field 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 contains the 16-bit UDP or TCP port number. This +field is used in the same way as the sin_port field of the sockaddr_in +structure. The port number is stored in network byte order. + +The sin6_flowinfo field is a 32-bit field that contains two pieces of +information: the traffic class and the flow label. The contents and +interpretation of this member is specified in [1]. + +The sin6_addr field is a single in6_addr structure (defined in the +previous section). This field holds one 128-bit IPv6 address. The +address is stored in network byte order. + +The ordering of elements in this structure is specifically designed so +that when sin6_addr field is aligned on a 64-bit boundary, the start of +the structure will also be aligned on a 64-bit boundary. This is done +for optimum performance on 64-bit architectures. + +The sin6_scope_id field is a 32-bit integer that identifies a set of +interfaces as appropriate for the scope [2] of the address carried in +the sin6_addr field. The mapping of sin6_scope_id to an interface or +set of interfaces is left to implementation and future specifications on +the subject of scoped addresses. + +Notice that the sockaddr_in6 structure will normally be larger than the +generic sockaddr structure. On many existing implementations the +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 + +The 4.4BSD release includes a small, but incompatible change to the +socket interface. The "sa_family" field of the sockaddr data structure +was changed from a 16-bit value to an 8-bit value, and the space saved +used to hold a length field, named "sa_len". The sockaddr_in6 data +structure given in the previous section cannot be correctly cast into + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 7] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +the newer sockaddr data structure. For this reason, the following +alternative IPv6 address data structure is provided to be used on +systems based on 4.4BSD. It is defined as a result of including the + header. + + struct sockaddr_in6 { + uint8_t sin6_len; /* length of this struct */ + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + +The only differences between this data structure and the 4.3BSD variant +are the inclusion of the length field, and the change of the family +field to a 8-bit data type. The definitions of all the other fields are +identical to the structure defined in the previous section. + +Systems that provide this version of the sockaddr_in6 data structure +must also declare SIN6_LEN as a result of including the +header. This macro allows applications to determine whether they are +being built on a system that supports the 4.3BSD or 4.4BSD variants of +the data structure. + + + +3.5 The Socket Functions + +Applications call the socket() function to create a socket descriptor +that represents a communication endpoint. The arguments to the socket() +function tell the system which protocol to use, and what format address +structure will be used in subsequent functions. For example, to create +an IPv4/TCP socket, applications make the call: + + s = socket(AF_INET, SOCK_STREAM, 0); + +To create an IPv4/UDP socket, applications make the call: + + s = socket(AF_INET, SOCK_DGRAM, 0); + +Applications may create IPv6/TCP and IPv6/UDP sockets (which may also +handle IPv4 communication as described in section 3.7) by simply using +the constant AF_INET6 instead of AF_INET in the first argument. For +example, to create an IPv6/TCP socket, applications make the call: + + s = socket(AF_INET6, SOCK_STREAM, 0); + +To create an IPv6/UDP socket, applications make the call: + + s = socket(AF_INET6, SOCK_DGRAM, 0); + +Once the application has created a AF_INET6 socket, it must use the +sockaddr_in6 address structure when passing addresses in to the system. +The functions that the application uses to pass addresses into the +system are: + + bind() + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 8] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + connect() + sendmsg() + sendto() + +The system will use the sockaddr_in6 address structure to return +addresses to applications that are using AF_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, since all of the "address carrying" functions use an opaque +address pointer, and carry an address length as a function argument. + + + +3.6 Compatibility with IPv4 Applications + +In order to support the large base of applications using the original +API, system implementations must provide complete source and binary +compatibility with the original API. This means that systems must +continue to support AF_INET sockets and the sockaddr_in address +structure. Applications must be able to create IPv4/TCP and IPv4/UDP +sockets using the AF_INET constant in the socket() function, 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 +simultaneously within the same process. + +Applications using the original API should continue to operate as they +did on systems supporting only IPv4. That is, they should continue to +interoperate with IPv4 nodes. + + + +3.7 Compatibility with IPv4 Nodes + +The API also provides a different type of compatibility: the ability for +IPv6 applications to interoperate with IPv4 applications. This feature +uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing +architecture specification [2]. This address format allows the IPv4 +address of an IPv4 node to be represented as an IPv6 address. The IPv4 +address is encoded into the low-order 32 bits of the IPv6 address, and +the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4- +mapped addresses are written as follows: + + ::FFFF: + +These addresses can be generated automatically by the getaddrinfo() +function, as described in Section 6.1. + +Applications may use AF_INET6 sockets to open TCP connections to IPv4 +nodes, or send UDP packets to IPv4 nodes, by simply encoding the +destination's IPv4 address as an IPv4-mapped IPv6 address, and passing +that address, within a sockaddr_in6 structure, in the connect() or + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 9] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +sendto() call. When applications use AF_INET6 sockets to accept TCP +connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the +system returns the peer's address to the application in the accept(), +recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded +this way. + +Few applications will likely need to know which type of node they are +interoperating with. However, for those applications that do need to +know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is +provided. + + + +3.8 IPv6 Wildcard Address + +While the bind() function allows applications to select the source IP +address of UDP packets and TCP connections, applications often want the +system to select the source address for them. With IPv4, one specifies +the address as the symbolic constant INADDR_ANY (called the "wildcard" +address) in the bind() call, or simply omits the 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 cannot +be used in an assignment. Therefore systems provide the IPv6 wildcard +address in two forms. + +The first version is a global variable named "in6addr_any" that is an +in6_addr structure. The extern declaration for this variable is defined +in : + + extern const struct in6_addr in6addr_any; + +Applications use in6addr_any similarly to the way 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 the following +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 and is +defined in . 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 */ + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 10] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + 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 + +Applications may need to send UDP packets to, or originate TCP +connections to, services residing on the local node. In IPv4, they can +do this by using the constant IPv4 address INADDR_LOOPBACK in their +connect(), sendto(), or sendmsg() call. + +IPv6 also provides a loopback address to contact local TCP and UDP +services. Like the unspecified address, the IPv6 loopback address is +provided in two forms -- a global variable and a symbolic constant. + +The global variable is an in6_addr structure named "in6addr_loopback." +The extern declaration for this variable is defined in : + + extern const struct in6_addr in6addr_loopback; + +Applications use in6addr_loopback as they would use INADDR_LOOPBACK in +IPv4 applications (but beware of the byte ordering difference mentioned +at the end of the previous section). For example, to open a TCP +connection to the local telnet server, an application could use the +following code: + + 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 named IN6ADDR_LOOPBACK_INIT and is defined in +. It can be used at declaration time ONLY; for example: + + struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; + +Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to +a previously declared IPv6 address variable. + + + +3.10 Portability Additions + +One simple addition to the sockets API that can help application writers +is the "struct sockaddr_storage". This data structure can simplify +writing code that is portable across multiple address families and +platforms. This data structure is designed with the following goals. + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 11] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + - Large enough to accommodate all supported protocol-specific address + structures. + + - Aligned at an appropriate boundary so that pointers to it can be cast + as pointers to protocol specific address structures and used to + access the fields of those structures without alignment problems. + + +The sockaddr_storage structure contains field ss_family which is of type +sa_family_t. When a sockaddr_storage structure is cast to a sockaddr +structure, the ss_family field of the sockaddr_storage structure maps +onto the sa_family field of the sockaddr structure. When a +sockaddr_storage structure is cast as a protocol specific address +structure, the ss_family field maps onto a field of that structure that +is of type sa_family_t and that identifies the protocol's address +family. + +An example implementation design of such a data structure would be as +follows. + +/* + * Desired design of maximum size and alignment + */ +#define _SS_MAXSIZE 128 /* Implementation specific max size */ +#define _SS_ALIGNSIZE (sizeof (int64_t)) + /* Implementation specific desired alignment */ +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + sa_family_t ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_family */ + /* __ss_pad1, __ss_align fields is 112 */ +}; + +The above example implementation illustrates a data structure which will +align on a 64-bit boundary. An implementation-specific field +"__ss_align" along with "__ss_pad1" is used to force a 64-bit alignment +which covers proper alignment good enough for the needs of sockaddr_in6 +(IPv6), sockaddr_in (IPv4) address data structures. The size of padding +field __ss_pad1 depends on the chosen alignment boundary. The size of +padding field __ss_pad2 depends on the value of overall size chosen for +the total size of the structure. This size and alignment are represented +in the above example by implementation specific (not required) constants +_SS_MAXSIZE (chosen value 128) and _SS_ALIGNSIZE (with chosen value 8). +Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 12] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +112) are also for illustration and not required. The derived values +assume sa_family_t is 2 bytes. The implementation specific definitions +and structure field names above start with an underscore to denote +implementation private namespace. Portable code is not expected to +access or reference those fields or constants. + +On implementations where the sockaddr data structure includes a "sa_len" +field this data structure would look like this: + +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t) + + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + uint8_t ss_len; /* address length */ + sa_family_t ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_len, */ + /* __ss_family, __ss_pad1, __ss_align fields is 112 */ +}; + + + +4. Interface Identification + +This API uses an interface index (a small positive integer) to identify +the local interface on which a multicast group is joined (Section 5.3). +Additionally, the advanced API [4] uses these same interface indexes to +identify the interface on which a datagram is received, or to specify +the interface on which a datagram is to be sent. + +Interfaces are normally known by names such as "le0", "sl1", "ppp2", and +the like. On Berkeley-derived implementations, when an interface is +made known to the system, the kernel assigns a unique positive integer +value (called the interface index) to that interface. These are small +positive integers that start at 1. (Note that 0 is never used for an +interface index.) There may be gaps so that there is no current +interface for a particular positive interface index. + +This API defines two functions that map between an interface name and +index, a third function that returns all the interface names and +indexes, and a fourth function to return the dynamic memory allocated by +the previous function. How these functions are implemented is left up +to the implementation. 4.4BSD implementations can implement these +functions using the existing sysctl() function with the NET_RT_IFLIST +command. Other implementations may wish to use ioctl() for this + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 13] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +purpose. + + + +4.1 Name-to-Index + +The first function maps an interface name into its corresponding index. + + #include + + unsigned int if_nametoindex(const char *ifname); + +If ifname is the name of an interface, the if_nametoindex() function +shall return the interface index corresponding to name ifname; +otherwise, it shall return zero. No errors are defined. + + + +4.2 Index-to-Name + +The second function maps an interface index into its corresponding name. + + #include + + char *if_indextoname(unsigned int ifindex, char *ifname); + +When this function is called, the ifname argument shall point to a +buffer of at least IF_NAMESIZE bytes. The function shall place in this +buffer the name of the interface with index ifindex. (IF_NAMESIZE is +also defined in and its value includes a terminating null +byte at the end of the interface name.) If ifindex is an interface +index, then the function shall return the value supplied in ifname, +which points to a buffer now containing the interface name. Otherwise, +the function shall return a NULL pointer and set errno to indicate the +error. If there is no interface corresponding to the specified index, +errno is set to ENXIO. If there was a system error (such as running out +of memory), errno would be set to the proper value (e.g., ENOMEM). + + + +4.3 Return All Interface Names and Indexes + +The if_nameindex structure holds the information about a single +interface and is defined as a result of including the header. + + struct if_nameindex { + unsigned int if_index; /* 1, 2, ... */ + char *if_name; /* null terminated name: "le0", ... */ + }; + +The final function returns an array of if_nameindex structures, one +structure per interface. + + #include + + struct if_nameindex *if_nameindex(void); + +The end of the array of structures is indicated by a structure with an + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 14] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +if_index of 0 and an if_name of NULL. The function returns a NULL +pointer upon an error, and would set errno to the appropriate value. + +The memory used for this array of structures along with the interface +names pointed to by the if_name members is obtained dynamically. This +memory is freed by the next function. + + + +4.4 Free Memory + +The following function frees the dynamic memory that was allocated by +if_nameindex(). + + #include + + void if_freenameindex(struct if_nameindex *ptr); + +The ptr argument shall be a pointer that was returned by if_nameindex(). +After if_freenameindex() has been called, the application shall not use +the array of which ptr is the address. + + + +5. Socket Options + +A number of new socket options are defined for IPv6. All of these new +options are at the IPPROTO_IPV6 level. That is, the "level" parameter +in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using +these options. The constant name prefix IPV6_ is used in all of the new +socket options. This serves to clearly identify these options as +applying to IPv6. + +The declaration for IPPROTO_IPV6, the new IPv6 socket options, and +related constants defined in this section are obtained by including the +header . + + + +5.1 Unicast Hop Limit + +A new setsockopt() option controls the hop limit used in outgoing +unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and +it is used at the IPPROTO_IPV6 layer. The following example illustrates +how it is used: + + int hoplimit = 10; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, sizeof(hoplimit)) == -1) + perror("setsockopt IPV6_UNICAST_HOPS"); + +When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option +value given is used as the hop limit for all subsequent unicast packets +sent via that socket. If the option is not set, the system selects a +default value. The integer hop limit value (called x) is interpreted as +follows: + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 15] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + +The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine +the hop limit value that the system will use for subsequent unicast +packets sent via that socket. For example: + + int hoplimit; + socklen_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.2 Sending and Receiving Multicast Packets + +IPv6 applications may send multicast packets by simply specifying an +IPv6 multicast address as the destination address, for example in the +destination address argument of the sendto() function. + +Three socket options at the IPPROTO_IPV6 layer control some of the +parameters for sending multicast packets. Setting these options is not +required: applications may send multicast packets without using these +options. The setsockopt() options for controlling the sending of +multicast packets are summarized below. These three options can also be +used with getsockopt(). + + IPV6_MULTICAST_IF + + Set the interface to use for outgoing multicast packets. + The argument is the index of the interface to use. + If the interface index is specified as zero, the system + selects the interface (for example, by looking up the + address in a routing table and using the resulting interface). + + Argument type: unsigned int + + IPV6_MULTICAST_HOPS + + Set the hop limit to use for outgoing multicast packets. + (Note a separate option - IPV6_UNICAST_HOPS - is + provided to set the hop limit to use for outgoing + unicast packets.) + + The interpretation of the argument is the same + as for the IPV6_UNICAST_HOPS option: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 16] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + If IPV6_MULTICAST_HOPS is not set, the default is 1 + (same as IPv4 today) + + Argument type: int + + IPV6_MULTICAST_LOOP + + If a multicast datagram is sent to a group to which the sending host + itself belongs (on the outgoing interface), a copy of the datagram is + looped back by the IP layer for local delivery if this option is set to + 1. If this option is set to 0 a copy is not looped back. Other option + values return an error of EINVAL. + + If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as + IPv4 today). + + Argument type: unsigned int + +The reception of multicast packets is controlled by the two setsockopt() +options summarized below. An error of EOPNOTSUPP is returned if these +two options are used with getsockopt(). + + IPV6_JOIN_GROUP + + Join 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_LEAVE_GROUP + + Leave a multicast group on a specified interface. + If the interface index is specified as 0, the system + may choose a multicast group membership to drop by + matching the multicast address only. + + Argument type: struct ipv6_mreq + +The argument type of both of these options is the ipv6_mreq structure, +defined as a result of including the header; + + 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 to which datagrams will be sent. UDP applications must +also bind the UDP port to which datagrams will be sent. Some processes +also bind the multicast group address to the socket, in addition to the +port, to prevent other datagrams destined to that same port from being +delivered to the socket. + + + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 17] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +5.3 IPV6_V6ONLY option for AF_INET6 Sockets + +This socket option restricts AF_INET6 sockets to IPv6 communications +only. As stated in section <3.7 Compatibility with IPv4 Nodes>, +AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some +applications may want to restrict their use of an AF_INET6 socket to +IPv6 communications only. For these applications the IPV6_V6ONLY socket +option is defined. When this option is turned on, the socket can be +used to send and receive IPv6 packets only. This is an IPPROTO_IPV6 +level option. This option takes an int value. This is a boolean +option. By default this option is turned off. + + Here is an example of setting this option: + + int on = 1; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, + (char *)&on, sizeof(on)) == -1) + perror("setsockopt IPV6_V6ONLY"); + else + printf("IPV6_V6ONLY set\n"); + +Note - This option has no effect on the use of IPv4 Mapped addresses +which enter a node as a valid IPv6 addresses for IPv6 communications as +defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5]. + +An example use of this option is to allow two versions of the same +server process to run on the same port, one providing service over IPv6, +the other providing the same service over IPv4. + + + + +6. Library Functions + +New library functions are needed to perform a variety of operations with +IPv6 addresses. Functions are needed to lookup IPv6 addresses in the +Domain Name System (DNS). Both forward lookup (nodename-to-address +translation) and reverse lookup (address-to-nodename translation) need +to be supported. Functions are also needed to convert IPv6 addresses +between their binary and textual form. + +We note that the two existing functions, gethostbyname() and +gethostbyaddr(), are left as-is. New functions are defined to handle +both IPv4 and IPv6 addresses. + +The commonly used function gethostbyname() is inadequate for many +applications, first because it provides no way for the caller to specify +anything about the types of addresses desired (IPv4 only, IPv6 only, +IPv4-mapped IPv6 are OK, etc.), and second because many implementations +of this function are not thread safe. RFC 2133 defined a function named +gethostbyname2() but this function was also inadequate, first because +its use required setting a global option (RES_USE_INET6) when IPv6 +addresses were required, and second because a flag argument is needed to +provide the caller with additional control over the types of addresses +required. The gethostbyname2() function was deprecated in RFC 2553 and +is no longer part of the basic API. + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 18] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +6.1 Protocol-Independent Nodename and Service Name Translation + +Nodename-to-address translation is done in a protocol-independent +fashion using the getaddrinfo() function. + + #include + #include + + + int getaddrinfo(const char *nodename, const char *servname, + const struct addrinfo *hints, struct addrinfo **res); + + void freeaddrinfo(struct addrinfo *ai); + + struct addrinfo { + int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */ + int ai_family; /* AF_xxx */ + int ai_socktype; /* SOCK_xxx */ + int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ + socklen_t ai_addrlen; /* length of ai_addr */ + char *ai_canonname; /* canonical name for nodename */ + struct sockaddr *ai_addr; /* binary address */ + struct addrinfo *ai_next; /* next structure in linked list */ + }; + + The getaddrinfo() function translates the name of a service location + (for example, a host name) and/or a service name and returns a set of + socket addresses and associated information to be used in creating a + socket with which to address the specified service. + + The nodename and servname arguments are either null pointers or + pointers to null-terminated strings. One or both of these two + arguments must be a non-null pointer. + + The format of a valid name depends on the address family or families. + If a specific family is not given and the name could be interpreted + as valid within multiple supported families, the implementation will + attempt to resolve the name in all supported families and, in absence + of errors, one or more results shall be returned. + + If the nodename argument is not null, it can be a descriptive name or + can be an address string. If the specified address family is AF_INET, + AF_INET6, or AF_UNSPEC, valid descriptive names include host names. + If the specified address family is AF_INET or AF_UNSPEC, address + strings using Internet standard dot notation as specified in + inet_addr() are valid. If the specified address family is AF_INET6 + or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are + valid. + + If nodename is not null, the requested service location is named by + nodename; otherwise, the requested service location is local to the + caller. + + If servname is null, the call shall return network-level addresses + for the specified nodename. If servname is not null, it is a null- + terminated character string identifying the requested service. This + can be either a descriptive name or a numeric representation suitable + for use with the address family or families. If the specified address + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 19] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be + specified as a string specifying a decimal port number. + + If the argument hints is not null, it refers to a structure + containing input values that may direct the operation by providing + options and by limiting the returned information to a specific socket + type, address family and/or protocol. In this hints structure every + member other than ai_flags, ai_family, ai_socktype and ai_protocol + shall be set to zero or a null pointer. A value of AF_UNSPEC for + ai_family means that the caller shall accept any address family. A + value of zero for ai_socktype means that the caller shall accept any + socket type. A value of zero for ai_protocol means that the caller + shall accept any protocol. If hints is a null pointer, the behavior + shall be as if it referred to a structure containing the value zero + for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC + for the ai_family field. + + Note: + + 1. If the caller handles only TCP and not UDP, for example, then the + ai_protocol member of the hints structure should be set to + IPPROTO_TCP when getaddrinfo() is called. + + 2. If the caller handles only IPv4 and not IPv6, then the ai_family + member of the hints structure should be set to AF_INET when + getaddrinfo() is called. + + The ai_flags field to which hints parameter points shall be set to + zero or be the bitwise-inclusive OR of one or more of the values + AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, + AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. + + If the AI_PASSIVE flag is specified, the returned address information + shall be suitable for use in binding a socket for accepting incoming + connections for the specified service (i.e. a call to bind()). In + this case, if the nodename argument is null, then the IP address + portion of the socket address structure shall be set to INADDR_ANY + for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the + AI_PASSIVE flag is not specified, the returned address information + shall be suitable for a call to connect() (for a connection-mode + protocol) or for a call to connect(), sendto() or sendmsg() (for a + connectionless protocol). In this case, if the nodename argument is + null, then the IP address portion of the socket address structure + shall be set to the loopback address. This flag is ignored if the + nodename argument is not null. + + If the AI_CANONNAME flag is specified and the nodename argument is + not null, the function shall attempt to determine the canonical name + corresponding to nodename (for example, if nodename is an alias or + shorthand notation for a complete name). + + If the AI_NUMERICHOST flag is specified, then a non-null nodename + string supplied shall be a numeric host address string. Otherwise, an + [EAI_NONAME] error is returned. This flag shall prevent any type of + name resolution service (for example, the DNS) from being invoked. + + If the AI_NUMERICSERV flag is specified, then a non-null servname + string supplied shall be a numeric port string. Otherwise, an + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 20] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + [EAI_NONAME] error shall be returned. This flag shall prevent any + type of name resolution service (for example, NIS+) from being + invoked. + + If the AI_V4MAPPED flag is specified along with an ai_family of + AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses + on finding no matching IPv6 addresses (ai_addrlen shall be 16). + + For example, when using the DNS, if no AAAA records are found + then a query is made for A records and any found are returned as + IPv4-mapped IPv6 addresses. + + The AI_V4MAPPED flag shall be ignored unless ai_family equals + AF_INET6. + + If the AI_ALL flag is used with the AI_V4MAPPED flag, then + getaddrinfo() shall return all matching IPv6 and IPv4 addresses. + + For example, when using the DNS, queries are made for both AAAA + records and A records, and getaddrinfo() returns the combined + results of both queries. Any IPv4 addresses found are returned + as IPv4-mapped IPv6 addresses. + + The AI_ALL flag without the AI_V4MAPPED flag is ignored. + + Note: + + When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and + AI_ALL flags will only be used if AF_INET6 is supported. + + If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be + returned only if an IPv4 address is configured on the local system, + and IPv6 addresses shall be returned only if an IPv6 address is + configured on the local system. The loopback address is not + considered for this case as valid as a configured address. + + For example, when using the DNS, a query for AAAA records + should occur only if the node has at least one IPv6 address + configured (other than IPv6 loopback) and a query for A records + should occur only if the node has at least one IPv4 address + configured (other than the IPv4 loopback). + + The ai_socktype field to which argument hints points specifies the + socket type for the service, as defined for socket(). If a specific + socket type is not given (for example, a value of zero) and the + service name could be interpreted as valid with multiple supported + socket types, the implementation shall attempt to resolve the service + name for all supported socket types and, in the absence of errors, + all possible results shall be returned. A non-zero socket type value + shall limit the returned information to values with the specified + socket type. + + If the ai_family field to which hints points has the value AF_UNSPEC, + addresses shall be returned for use with any address family that can + be used with the specified nodename and/or servname. Otherwise, + addresses shall be returned for use only with the specified address + family. If ai_family is not AF_UNSPEC and ai_protocol is not zero, + then addresses are returned for use only with the specified address + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 21] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + family and protocol; the value of ai_protocol shall be interpreted as + in a call to the socket() function with the corresponding values of + ai_family and ai_protocol . + + The freeaddrinfo() function frees one or more addrinfo structures + returned by getaddrinfo(), along with any additional storage + associated with those structures (for example, storage pointed to by + the ai_canonname and ai_addr fields; an application must not + reference this storage after the associated addrinfo structure has + been freed). If the ai_next field of the structure is not null, the + entire list of structures is freed. The freeaddrinfo() function must + support the freeing of arbitrary sublists of an addrinfo list + originally returned by getaddrinfo(). + + Functions getaddrinfo() and freeaddrinfo() must be thread-safe. + + A zero return value for getaddrinfo() indicates successful + completion; a non-zero return value indicates failure. The possible + values for the failures are listed below under Error Return Values. + + Upon successful return of getaddrinfo(), the location to which res + points shall refer to a linked list of addrinfo structures, each of + which shall specify a socket address and information for use in + creating a socket with which to use that socket address. The list + shall include at least one addrinfo structure. The ai_next field of + each structure contains a pointer to the next structure on the list, + or a null pointer if it is the last structure on the list. Each + structure on the list shall include values for use with a call to the + socket() function, and a socket address for use with the connect() + function or, if the AI_PASSIVE flag was specified, for use with the + bind() function. The fields ai_family, ai_socktype, and ai_protocol + shall be usable as the arguments to the socket() function to create a + socket suitable for use with the returned address. The fields ai_addr + and ai_addrlen are usable as the arguments to the connect() or bind() + functions with such a socket, according to the AI_PASSIVE flag. + + If nodename is not null, and if requested by the AI_CANONNAME flag, + the ai_canonname field of the first returned addrinfo structure shall + point to a null-terminated string containing the canonical name + corresponding to the input nodename; if the canonical name is not + available, then ai_canonname shall refer to the nodename argument or + a string with the same contents. The contents of the ai_flags field + of the returned structures are undefined. + + All fields in socket address structures returned by getaddrinfo() + that are not filled in through an explicit argument (for example, + sin6_flowinfo) shall be set to zero. + + Note: This makes it easier to compare socket address structures. + + Error Return Values: + + The getaddrinfo() function shall fail and return the corresponding + value if: + + [EAI_AGAIN] The name could not be resolved at this time. Future + attempts may succeed. + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 22] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + [EAI_BADFLAGS] The flags parameter had an invalid value. + + [EAI_FAIL] A non-recoverable error occurred when attempting to + resolve the name. + + [EAI_FAMILY] The address family was not recognized. + + [EAI_MEMORY] There was a memory allocation failure when trying to + allocate storage for the return value. + + [EAI_NONAME] The name does not resolve for the supplied parameters. + Neither nodename nor servname were supplied. At least one + of these must be supplied. + + [EAI_SERVICE] The service passed was not recognized for the specified + socket type. + + [EAI_SOCKTYPE] The intended socket type was not recognized. + + [EAI_SYSTEM] A system error occurred; the error code can be found in + errno. + +The gai_strerror() function provides a descriptive text string +corresponding to an EAI_xxx error value. + + + #include + + const char *gai_strerror(int ecode); + +The argument is one of the EAI_xxx values defined for the getaddrinfo() +and getnameinfo() functions. The return value points to a string +describing the error. If the argument is not one of the EAI_xxx values, +the function still returns a pointer to a string whose contents indicate +an unknown error. + + + +6.2 Socket Address Structure to Node Name and Service Name + +The getnameinfo() function is used to translate the contents of a socket +address structure to a node name and/or service name. + + #include + #include + + int getnameinfo(const struct sockaddr *sa, socklen_t salen, + char *node, socklen_t nodelen, + char *service, socklen_t servicelen, + int flags); + +The getnameinfo() function shall translate a socket address to a node +name and service location, all of which are defined as in getaddrinfo(). + +The sa argument points to a socket address structure to be translated. + +The salen argument holds the size of the socket address structure +pointed to by sa. + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 23] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +If the socket address structure contains an IPv4-mapped IPv6 address or +an IPv4-compatible IPv6 address, the implementation shall extract the +embedded IPv4 address and lookup the node name for that IPv4 address. + + Note: The IPv6 unspecified address ("::") and the IPv6 + loopback address ("::1") are not IPv4-compatible addresses. + If the address is the IPv6 unspecified address ("::"), a + lookup is not performed, and the [EAI_NONAME] error is returned. + +If the node argument is non-NULL and the nodelen argument is nonzero, +then the node argument points to a buffer able to contain up to nodelen +characters that receives the node name as a null-terminated string. If +the node argument is NULL or the nodelen argument is zero, the node name +shall not be returned. If the node's name cannot be located, the numeric +form of the node's address is returned instead of its name. + +If the service argument is non-NULL and the servicelen argument is non- +zero, then the service argument points to a buffer able to contain up to +servicelen bytes that receives the service name as a null-terminated +string. If the service argument is NULL or the servicelen argument is +zero, the service name shall not be returned. If the service's name +cannot be located, the numeric form of the service address (for example, +its port number) shall be returned instead of its name. + +The arguments node and service cannot both be NULL. + +The flags argument is a flag that changes the default actions of the +function. By default the fully-qualified domain name (FQDN) for the host +shall be returned, but: + + - If the flag bit NI_NOFQDN is set, only the node name portion of the + FQDN shall be returned for local hosts. + + - If the flag bit NI_NUMERICHOST is set, the numeric form of the + host's address shall be returned instead of its name, under all + circumstances. + + - If the flag bit NI_NAMEREQD is set, an error shall be returned if the + host's name cannot be located. + + - If the flag bit NI_NUMERICSERV is set, the numeric form of the + service address shall be returned (for example, its port number) + instead of its name, under all circumstances. + + - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the + scope identifier shall be returned (for example, interface index) + instead of its name. This flag is ignored if the sa argument is + not an IPv6 address. + + - If the flag bit NI_DGRAM is set, this indicates that the service is + a datagram service (SOCK_DGRAM). The default behavior shall assume that + the service is a stream service (SOCK_STREAM). + +Note: + + 1. The three NI_NUMERICxxx flags are required to support the "-n" + flags that many commands provide. + 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 port + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 24] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + numbers (for example, [512,514]) that represent different services + for UDP and TCP. + +The getnameinfo() function shall be thread safe. + +A zero return value for getnameinfo() indicates successful completion; a +non-zero return value indicates failure. + +Upon successful completion, getnameinfo() shall return the node and +service names, if requested, in the buffers provided. The returned names +are always null-terminated strings. + +Error Return Values: + +The getnameinfo() function shall fail and return the corresponding value +if: + + [EAI_AGAIN] The name could not be resolved at this time. + Future attempts may succeed. + + [EAI_BADFLAGS] The flags had an invalid value. + + [EAI_FAIL] A non-recoverable error occurred. + + [EAI_FAMILY] The address family was not recognized or the address + length was invalid for the specified family. + + [EAI_MEMORY] There was a memory allocation failure. + + [EAI_NONAME] The name does not resolve for the supplied parameters. + NI_NAMEREQD is set and the host's name cannot be located, or + both nodename and servname were null. + + [EAI_OVERFLOW] An argument buffer overflowed. + + [EAI_SYSTEM] A system error occurred. The error code can be found in + errno. + + + +6.3 Address Conversion Functions + +The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4 +address between binary and text form. IPv6 applications need similar +functions. The following two functions convert both IPv6 and IPv4 +addresses: + + #include + + int inet_pton(int af, const char *src, void *dst); + + const char *inet_ntop(int af, const void *src, + char *dst, socklen_t size); + +The inet_pton() function shall convert an address in its standard text +presentation form into its numeric binary form. The af argument shall +specify the family of the address. The AF_INET and AF_INET6 address +families shall be supported. The src argument points to the string + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 25] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +being passed in. The dst argument points to a buffer into which the +function stores the numeric address; this shall be large enough to hold +the numeric address (32 bits for AF_INET, 128 bits for AF_INET6). The +inet_pton() function shall return 1 if the conversion succeeds, with the +address pointed to by dst in network byte order. It shall return 0 if +the input is not a valid IPv4 dotted-decimal string or a valid IPv6 +address string, or -1 with errno set to EAFNOSUPPORT if the af argument +is unknown. + +If the af argument of inet_pton() is AF_INET, the src string shall be 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. +The inet_pton() function does not accept other formats (such as the +octal numbers, hexadecimal numbers, and fewer than four numbers that +inet_addr() accepts). + +If the af argument of inet_pton() is AF_INET6, the src string shall be +in one of the standard IPv6 text forms defined in Section 2.2 of the +addressing architecture specification [2]. + +The inet_ntop() function shall convert a numeric address into a text +string suitable for presentation. The af argument shall specify the +family of the address. This can be AF_INET or AF_INET6. The src +argument points to a buffer holding an IPv4 address if the af argument +is AF_INET, or an IPv6 address if the af argument is AF_INET6; the +address must be in network byte order. The dst argument points to a +buffer where the function stores the resulting text string; it shall not +be NULL. The size argument specifies the size of this buffer, which +shall be large enough to hold the text string (INET_ADDRSTRLEN +characters for IPv4, INET6_ADDRSTRLEN characters for IPv6). + +In order to allow applications to easily declare buffers of the proper +size to store IPv4 and IPv6 addresses in string form, the following two +constants are defined in : + + #define INET_ADDRSTRLEN 16 + #define INET6_ADDRSTRLEN 46 + +The inet_ntop() function shall return a pointer to the buffer containing +the text string if the conversion succeeds, and NULL otherwise. Upon +failure, errno is set to EAFNOSUPPORT if the af argument is invalid or +ENOSPC if the size of the result buffer is inadequate. + + + +6.4 Address Testing Macros + +The following macros can be used to test for special IPv6 addresses. + + #include + + 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 *); + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 26] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + 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 specified +type, or false otherwise. The last five test the scope of a multicast +address and return true if the address is a multicast address of the +specified scope or false if the address is either not a multicast +address or not of the specified scope. + +Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true +only for the two types of local-use IPv6 unicast addresses (Link-Local +and Site-Local) defined in [2], and that by this definition, the +IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback address +(::1). These two macros do not return true for IPv6 multicast addresses +of either link-local scope or site-local scope. + + + +7. Summary of New Definitions + +The following list summarizes the constants, structure, and extern +definitions discussed in this memo, sorted by header. + + IF_NAMESIZE + struct if_nameindex{}; + + AI_ADDRCONFIG + AI_ALL + AI_CANONNAME + AI_NUMERICHOST + AI_NUMERICSERV + AI_PASSIVE + AI_V4MAPPED + EAI_AGAIN + EAI_BADFLAGS + EAI_FAIL + EAI_FAMILY + EAI_MEMORY + EAI_NONAME + EAI_OVERFLOW + EAI_SERVICE + EAI_SOCKTYPE + EAI_SYSTEM + NI_DGRAM + NI_NAMEREQD + NI_NOFQDN + NI_NUMERICHOST + NI_NUMERICSERV + struct addrinfo{}; + + IN6ADDR_ANY_INIT + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 27] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + + IN6ADDR_LOOPBACK_INIT + INET6_ADDRSTRLEN + INET_ADDRSTRLEN + IPPROTO_IPV6 + IPV6_JOIN_GROUP + IPV6_LEAVE_GROUP + IPV6_MULTICAST_HOPS + IPV6_MULTICAST_IF + IPV6_MULTICAST_LOOP + IPV6_UNICAST_HOPS + IPV6_V6ONLY + SIN6_LEN + extern const struct in6_addr in6addr_any; + extern const struct in6_addr in6addr_loopback; + struct in6_addr{}; + struct ipv6_mreq{}; + struct sockaddr_in6{}; + + AF_INET6 + PF_INET6 + struct sockaddr_storage; + +The following list summarizes the function and macro prototypes +discussed in this memo, sorted by header. + + int inet_pton(int, const char *, void *); + const char *inet_ntop(int, const void *, + char *, socklen_t); + + char *if_indextoname(unsigned int, char *); + unsigned int if_nametoindex(const char *); + void if_freenameindex(struct if_nameindex *); + struct if_nameindex *if_nameindex(void); + + int getaddrinfo(const char *, const char *, + const struct addrinfo *, + struct addrinfo **); + int getnameinfo(const struct sockaddr *, socklen_t, + char *, socklen_t, char *, socklen_t, int); + void freeaddrinfo(struct addrinfo *); + const char *gai_strerror(int); + + int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); + + + + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 28] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +8. Security Considerations + +IPv6 provides a number of new security mechanisms, many of which need to +be accessible to applications. Companion memos detailing the extensions +to the socket interfaces to support IPv6 security are being written. + + + +Changes from RFC 2553 + + 1. Add brief description of the history of this API and its + relation to the Open Group/IEEE/ISO standards. + + 2. Alignments with [3]. + + 3. Removed all references to getipnodebyname() and + getipnodebyaddr(), which are deprecated in favor + of getaddrinfo() and getnameinfo(). + + 4. Added IPV6_V6ONLY IP level socket option to permit nodes + to not process IPv4 packets as IPv4 Mapped addresses + in implementations. + + 5. Added SIIT to references and added new contributors. + + + + +Acknowledgments + +This specification's evolution and completeness were significantly +influenced by the efforts of Richard Stevens, who has passed on. +Richard's wisdom and talent made the specification what it is today. +The co-authors will long think of Richard with great respect. + +Thanks to the many people who made suggestions and provided feedback to +this document, including: + +Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew +Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis +Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, Marc +Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji +Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, +Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, Craig +Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith +Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean +D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl +Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill. + +The getaddrinfo() and getnameinfo() functions are taken from an earlier +Internet Draft by Keith Sklower. As noted in that draft, William Durst, +Steven Wise, Michael Karels, and Eric Allman provided many useful +discussions on the subject of protocol-independent name-to-address +translation, and reviewed early versions of Keith Sklower's original +proposal. Eric Allman implemented the first prototype of getaddrinfo(). +The observation that specifying the pair of name and service would +suffice for connecting to a service independent of protocol details was +made by Marshall Rose in a proposal to X/Open for a "Uniform Network + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 29] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +Interface". + +Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker +made many contributions to this document. Ramesh Govindan made a number +of contributions and co-authored an earlier version of this memo. + + + +References + + [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460 Draft Standard. + + [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998 Draft Standard. + + [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX) + + Open Group Technical Standard: Base Specifications, Issue 6 + December 2001 + + ISO 9945 (pending final approval by ISO) + + http://www.opengroup.org/austin + + [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + + [5] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)" + RFC 2765, February 2000. + + [6] The Open Group Base Working Group + http://www.opengroup.org/platform/base.html + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 30] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-07.txt September 2002 + + +Authors' Addresses + +Bob Gilligan +Cacheflow, Inc. +650 Almanor Ave. +Sunnyvale, CA 94086 +Telephone: 408-220-2084 (voice) + 408-220-2250 (fax) +Email: gilligan@cacheflow.com + +Susan Thomson +Cisco Systems +499 Thornall Street, 8th floor +Edison, NJ 08837 +Telephone: 732-635-3086 +Email: sethomso@cisco.com + +Jim Bound +Hewlett-Packard Company +110 Spitbrook Road ZKO3-3/W20 +Nashua, NH 03062 +Telephone: 603-884-0062 +Email: Jim.Bound@hp.com + +Jack McCann +Hewlett-Packard Company +110 Spitbrook Road ZKO3-3/W20 +Nashua, NH 03062 +Telephone: 603-884-2608 +Email: Jack.McCann@hp.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2553bis-07.txt Expires March 2003 [Page 31] + diff --git a/doc/draft/draft-ietf-ipv6-dns-discovery-05.txt b/doc/draft/draft-ietf-ipv6-dns-discovery-06.txt similarity index 84% rename from doc/draft/draft-ietf-ipv6-dns-discovery-05.txt rename to doc/draft/draft-ietf-ipv6-dns-discovery-06.txt index 63a6979fe1..f814f5b304 100644 --- a/doc/draft/draft-ietf-ipv6-dns-discovery-05.txt +++ b/doc/draft/draft-ietf-ipv6-dns-discovery-06.txt @@ -1,7 +1,7 @@ Network Working Group Alain Durand INTERNET-DRAFT SUN Microsystems, inc. -June 14, 2002 Jun-ichiro itojun Hagino -Expires December 2002 IIJ Research Laboratory +August 21, 2002 Jun-ichiro itojun Hagino +Expires February 2002 IIJ Research Laboratory Dave Thaler Microsoft @@ -9,11 +9,11 @@ Expires December 2002 IIJ Research Laboratory Well known site local unicast addresses for DNS resolver - + - Status of this Memo + Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. @@ -37,16 +37,18 @@ Abstract This documents specifies a method for nodes to find a DNS resolver with minimum configuration in the network and without running a - discovery protocol on the nodes. + discovery protocol on the nodes. This method is to be used in last + resort, when no other information about the addresses of DNS + resolvers is available. -Copyright Notice +Copyright notice Copyright (C) The Internet Society (2002). All Rights Reserved. -1. Introduction +1. Introduction RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or more IPv6 address and default routes. @@ -99,29 +101,41 @@ Copyright Notice participation of the end node in the DNS resolver discovery mechanism. - The mechanism described here is to be used as a last resort, when no - other configuration information is available. + The mechanism described here is to be used as a last resort, in the + absence of any information about the addresses of DNS resolvers. If + other configuration mechanisms are available, they should be tried + first. + + Note to implementors: + + Implementing only the mechanism described in this memo may end up + causing some interoperability problems when operating in networks + where no DNS resolver is configured with the well known addresses. + Thus, it is recommended to implement also other mechanisms for + overriding this default, for example: manual configuration, L2 + mechanisms and/or DHCPv6. -3. Reserved Prefix and addresses - The basic idea of this proposal is to reserve a well known IPv6 site - local prefix and three well known IPv6 addresses for DNS resolvers - and then have the routing system forward the DNS request to those DNS - resolvers. +3. Reserved prefix and addresses - IPv6 nodes will be pre-configured (hard coded) with those three IPv6 - addresses as DNS resolver. + The basic idea of this proposal is to reserve three well known IPv6 + site local addresses for DNS resolvers and then have the routing + system forward the DNS request to them. - Each local DNS resolvers should be configured with one of those three + IPv6 stub-resolvers implementing this proposal are pre-configured + with those three IPv6 addresses as DNS resolver. + + Local DNS resolvers should be configured with one of those three addresses to enable clients to switch from one to the other if one - fails. Host routes for each of those resolvers should be injected in - the local routing system. Example methods for injecting host routes - and a brief discussion of their fate sharing properties is presented - here: + fails. + A solution to enable clients to reach the DNS resolvers is to inject + host routes in the local routing system. Examples of methods for + injecting host routes and a brief discussion of their fate sharing + properties are presented here: a) Manual injection of routes by a router on the same subnet. If the node running the DNS resolver goes down, the router may or @@ -138,10 +152,16 @@ Copyright Notice threads, similar concerns as above are true. d) Having an "announcement" protocol that the DNS resolver could - use to advertize the host route to the nearby router. - Details of such a protocols are out of scope of this document, but - something similar to [MLD] is possible. + use to advertize the host route to the nearby router. Details of + such a protocols are out of scope of this document, but something + similar to [MLD] is possible. + An alternate solution is to configure a link with the well known + prefix and position the three DNS resolvers on that link. The + advantage of this method is that host routes are not necessary , the + well known prefix is advertized to the routing system by the routers + on the link. However, in the event of a problem on the physical link, + all resolvers will become unreachable. IANA considerations for this prefix are covered in Section 6. @@ -162,13 +182,6 @@ Copyright Notice are first sent to a DNS resolver located within the site perimeter increase their likelyhood of success. - Note: there is currently some discussions about the usefulness of - site local addresses in the IPv6 architecture. Depending on the - outcome of this discussion, this section will need to be revisited. - If a global prefix was chosen for this mechanism, concerns raised in - a) could be addressed using a simple access list on the site exit - routers and concerns raised in b) would disappear. - 5. Examples of use @@ -219,8 +232,7 @@ Copyright Notice customers share the same definition of site. In this scenario, the home/small office network is connected to the - ISP router (PE) via an edge router (CPE). Prefix delegation is - performed out of band is is out of scope of this memo. + ISP router (PE) via an edge router (CPE). ------------- / | @@ -255,8 +267,8 @@ Copyright Notice 5.3 DNS forwarder with DHCPv6 interactions - In this variant scenario, DHCPv6 could be used between the PE and CPE - to do prefix delegation [DELEG] and DNS resolver discovery. + In this variant scenario, DHCPv6 is be used between the PE and CPE to + do prefix delegation [DELEG] and DNS resolver discovery. ------------- / | @@ -269,13 +281,12 @@ Copyright Notice ------------- This example will show how DHCPv6 and well known site local unicast - addresses can be used at the same time within a site to discover the - address of the DNS forwarder. + addresses cooperate to enable the internal nodes to access DNS. - The customer router CPE could be configured on its internal interface - with one of the reserved site local addresses and listen for DNS - queries. It would act as a DNS forwarder, forwarding those queries to - the DNS resolver pointed out by the ISP in the DHCPv6 exchange. + The customer router CPE is configured on its internal interface with + one of the reserved site local addresses and listen for DNS queries. + It would act as a DNS forwarder, as in 5.2, forwarding those queries + to the DNS resolver pointed out by the ISP in the DHCPv6 exchange. ------------- / | @@ -288,8 +299,8 @@ Copyright Notice ------------- - The same CPE router could also act as a local DHCPv6 server, - advertising either itself as DNS forwarder. + The same CPE router could also implement a local DHCPv6 server and + advertises itself as DNS forwarder. ------------- / | @@ -305,8 +316,8 @@ Copyright Notice Within the site: - a) DHCPv6 aware clients could use DHCPv6 to obtain the address of - the DNS forwarder... + a) DHCPv6 aware clients use DHCPv6 to obtain the address of the + DNS forwarder... ------------- / | @@ -320,8 +331,8 @@ Copyright Notice (The address of the DNS forwarder is aquired via DHCPv6.) - b) other nodes may simply send their DNS request to the reserved - site local addresses. + b) other nodes simply send their DNS request to the reserved site + local addresses. ------------- / | @@ -347,7 +358,7 @@ Copyright Notice of the site local fec0::/10 prefix. The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 - and fec0:000:0000:ffff::2 are to be reserved for DNS resolver + and fec0:000:0000:ffff::3 are to be reserved for DNS resolver configuration. All other addresses within the fec0:0000:0000:ffff::/64 are reserved @@ -518,16 +529,6 @@ Copyright (C) The Internet Society (2002). All Rights Reserved. - - - - - - - - - -