All.
Here's an update on this document.
regards
Andrew
--- Forwarded mail from (Jun-ichiro itojun Hagino)
Subject: Re: getnameinfo(3) extension for other L4 protocols support
Date: Mon, 27 Dec 2004 22:58:50 +0900 (JST)
> hi,
> We had one comment below
> regards
here's new version of the document. i removed bitmask/value wording
and made it implementation-specific.
itojun
--------------------------------------------------------
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: yyyyyy@xxxxxxxxxx
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
|