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]