Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: June 20, 2005 December 20, 2004 Multiple protocol support in getnameinfo API draft-itojun-ipv6-getnameinfo-multiproto-02.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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. 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 June 20, 2005. IPR disclosure By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 only 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 HAGINO Expires: June 20, 2005 [Page 1] ^L DRAFT multiprotocol getnameinfo December 2004 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. 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 macros, indicating which protocol (instead of socket type) to be used for getservbyport(3) lookup. Actual values associated to the macros are implementation-dependent. We also define NI_DGRAM to be same as NI_UDP 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 0x000 /* the value can vary by implementation */ #define NI_UDP 0x100 /* the value can vary by implementation */ #define NI_DCCP 0x200 /* the value can vary by implementation */ #define NI_SCTP 0x300 /* the value can vary by implementation */ #define NI_DGRAM NI_UDP If multiple bits are specified (such as NI_UDP | NI_DCCP), getnameinfo(3) should raise EAI_BADFLAGS error if possible (with the above example, it is not possible as NI_UDP | NI_DCCP equals to NI_SCTP). If no flag bits are specified, getnameinfo(3) should treat it as NI_TCP for backward compatibility. HAGINO Expires: June 20, 2005 [Page 2] ^L DRAFT multiprotocol getnameinfo December 2004 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: 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 */ Inside getnameinfo(3) function, 2nd argument to getservbyport(3) will be determined based on NI_xxx bits: HAGINO Expires: June 20, 2005 [Page 3] ^L DRAFT multiprotocol getnameinfo December 2004 const char *p; switch (flags & NI_PROTOBITS) { case NI_TCP: p = "tcp"; break; case NI_UDP: p = "udp"; break; case NI_DCCP: p = "dccp"; break; case NI_SCTP: p = "sctp"; break; default: p = NULL; break; } if (p) { sp = getservbygetnameinfo(port, p); } else { /* numeric case */ } 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. Change history 01 -> 02 State that the NI_xxx values are just exapmles. HAGINO Expires: June 20, 2005 [Page 4] ^L DRAFT multiprotocol getnameinfo December 2004 00 -> 01 Define NI_TCP as a flag bit (00 defined it as 0). Clarify error condition. 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 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. HAGINO Expires: June 20, 2005 [Page 5] ^L