Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: July 15, 2004 January 15, 2004 Multiple protocol support in getnameinfo API draft-itojun-ipv6-getnameinfo-multiproto-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be July 15, 2004. Abstract IPv6 basic API [Gilligan, 2003] defines protocol-independent API for address-to-string conversion, i.e. getnameinfo(3). Current specification, however, assumes that there are two transport-layer protocols - TCP (SOCK_STREAM) and UDP (SOCK_DGRAM), specifically in port number-to-service name conversion. The assumption prohibits getnameinfo(3) from supporting other transport-layer protocols, such as SCTP or DCCP. This document proposes a backward-compatible update to getnameinfo(3) specification to allow the use of other transport-layer protocol in port number-to-service name conversion. This document does not define any new (wire-level) protocol. HAGINO Expires: July 15, 2004 [Page 1] ^L DRAFT multiprotocol getnameinfo January 2004 1. Background getnameinfo(3) API is defined in IPv6 basic API as well as POSIX standard. Under RFC3493 definition, for port number-to-service name conversion, it has two operation modes: the default mode where getservbyport(3) will be called from getnameinfo(3) with "tcp" as 2nd argument, and NI_DGRAM mode where getservbyport(3) will be called with "udp" as 2nd argument. The mode is chosen by the last argument ("flags") to getnameinfo(3). Supposedly, the default mode is for SOCK_STREAM case and NI_DGRAM mode is for SOCK_DGRAM case Here RFC3493 makes a wild assumption - that SOCK_STREAM implies the use of TCP, and SOCK_DGRAM implies the use of UDP. However, the assumption does not hold due to multiple reasons, such as (1) there are other transport protocols coming up like SCTP and DCCP and SOCK_xx and IPPROTO_xx has no 1-by-1 mapping, (2) getnameinfo(3) could be used for non-Internet protocols as well. In this draft we would like to correct the getnameinfo(3) API with respect to the Internet protocol, in a backward-compatible manner. The use of getnameinfo(3) API with non-Internet protocol (and port number- to-service name lookup) needs further study. 2. Updates to getnameinfo(3) API We define the following flag bits, indicating which protocol (instead of socket type) to be used for getservbyport(3) lookup. We also define NI_DGRAM to be same as NI_UDP, and NI_TCP to be 0, for backward compatibility. Note that the value of NI_UDP has to be the same as NI_DGRAM in the past implementation, for backward compatibility reasons. #define NI_TCP 0 #define NI_UDP 0x100 /* the value can vary by implementation */ #define NI_DCCP 0x200 /* the value can vary by implementation */ #define NI_SCTP 0x400 /* the value can vary by implementation */ #define NI_DGRAM NI_UDP The caller of getnameinfo(3) would pass the flag bit. It is encouraged to always specify the proper flag bit, as shown in the following example: HAGINO Expires: July 15, 2004 [Page 2] ^L DRAFT multiprotocol getnameinfo January 2004 int flags, proto; struct sockaddr *sa; char sbuf[NI_MAXSERV]; switch (proto) { case IPPROTO_TCP: flags = NI_TCP; break; case IPPROTO_UDP: flags = NI_UDP; break; case IPPROTO_DCCP: flags = NI_DCCP; break; case IPPROTO_SCTP: flags = NI_SCTP; break; default: flags = NI_NUMERICSERV; break; } if (getnameinfo(sa, sa->sa_len, NULL, 0, sbuf, sizeof(sbuf), flags) != 0) die(); /* error */ /* sbuf has the string representation of service name */ 3. Open issues o How should we handle non-Internet service name lookups? Is it always okay to use NI_NUMERICSRV, or should we provide some way to specify non-Internet service name lookup? (we basically need some example of the usage) 4. Security considerations This document introduces no new security issues. References Gilligan, 2003. R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. R. Stevens, "Basic Socket Interface Extensions for IPv6" in RFC3493 (February 2003). ftp://ftp.isi.edu/in-notes/rfc3493.txt. HAGINO Expires: July 15, 2004 [Page 3] ^L DRAFT multiprotocol getnameinfo January 2004 Change history TBD Acknowledgements This draft was written based on discussions with Japanese IPv6 users and help from the WIDE research group. Author's address Jun-ichiro itojun HAGINO Senior Researcher, Research Laboratory, Internet Initiative Japan Inc. 1-105, Kanda Jinbo-cho, Chiyoda-ku,Tokyo 101-0051, JAPAN Tel: +81-3-5205-6464 Fax: +81-3-5205-6466 Email: itojun@iijlab.net HAGINO Expires: July 15, 2004 [Page 4]