For your information.
I received the following. I'd apprecaite any comments
back on this Draft RFC by June 25th 2004.
getnameinfo(3) assumes 1-to-1 mapping between socket type (SOCK_xx)
and protocol (IPPROTO_xx, more precisely 2nd arg to getservbyport)
if flags & NI_DGRAM == 0, 2nd arg to getservbyport is "tcp"
if flags & NI_DGRAM != 0, 2nd arg to getservbyport is "udp"
the attached draft intends to correct this 1-to-1 mapping assumption.
regards
Andrew
------------------
Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: August 5, 2004 February 5, 2004
Multiple protocol support in getnameinfo API
draft-itojun-ipv6-getnameinfo-multiproto-01.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 August 5, 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: August 5, 2004 [Page 1]
DRAFT multiprotocol getnameinfo February 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 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 0x100 /* the value can vary by implementation */
#define NI_UDP 0x200 /* the value can vary by implementation */
#define NI_DCCP 0x400 /* the value can vary by implementation */
#define NI_SCTP 0x800 /* 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 no flag bits are
specified, getnameinfo(3) should treat it as NI_TCP for backward
compatibility.
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: August 5, 2004 [Page 2]
DRAFT multiprotocol getnameinfo February 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: August 5, 2004 [Page 3]
DRAFT multiprotocol getnameinfo February 2004
Change history
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: yyyyyy@xxxxxxxxxx
HAGINO Expires: August 5, 2004 [Page 4]
-----
Andrew Josey The Open Group
Austin Group Chair Apex Plaza,Forbury Road,
Email: yyyyyyy@xxxxxxxxxxxxx Reading,Berks.RG1 1AX,England
Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
|