Subject: getnameinfo and various protocol types

From: [email-masked]
Date: Thu, 11 Dec 2003 17:44:21 +0900

getnameinfo(3) specification assumes that there are only two transport
	protocols - tcp and udp.  when performing service name lookup
	it would use "tcp" if NI_DGRAM is not specified, and "udp" when
	NI_DGRAM is specified.

	now we have couple of new transport protocols coming, such as SCTP and
	DCCP.  how can we support service name lookup for those?  i.e.
	how can we tell getnameinfo(3) to use "sctp" or "dccp" for the 2nd
	argument of getservbyport(3)?

	my proposal:
	define NI_UDP as replacement of NI_DGRAM.  deprecate NI_DGRAM (keep
	it as an alias to NI_UDP is okay).  define NI_SCTP, NI_DCCP and such.
	these three are mutually exclusive, and if more than one is specified
	it would cause EAI_FAIL.

itojun

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Andrew White <[email-masked]>
Date: Thu, 11 Dec 2003 23:14:35 +1100

> these three are mutually exclusive, and if more than one is specified

And define NI_TCP, which is also the default if none is specified?  I'd also
propose deprecating the default, to get everyone in the habit of specifying
something.

-- 
Andrew White

---

From: Peter Lei <[email-masked]>
Date: Thu, 11 Dec 2003 12:10:30 -0600

> 	these three are mutually exclusive, and if more than one is specified

Agree!  I assume "and such" implies that NI_TCP will be defined too,
which is still the default if nothing is specified in the call (for
backward compatibility?)

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Dec 2003 11:04:31 -0800 (PST)

> 	these three are mutually exclusive, and if more than one is specified

Since getnameinfo in theory should apply to non-Inet protocols
I think it would be useful to try to abstract from NI_SCTP and NI_DCCP
to something which captures the flavors/attributes of those transports.
I don't know if NI_SEQPACKET is descriptive for SCTP and protocols
of that flavor.
I have no idea what a more abstract name would be descriptive for DCCP.

  Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Dec 2003 11:07:14 +0900 (JST)

> I have no idea what a more abstract name would be descriptive for DCCP.

	SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.
	DCCP should be SOCK_DGRAM only, if i understand correctly.

	therefore, there's no 1-by-1 mapping from SOCK_xx to IPPROTO_xx.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Dec 2003 11:09:11 +0900 (JST)

> which is still the default if nothing is specified in the call (for

	yup, NI_TCP would have a value of 0 and is still a default.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Dec 2003 11:25:44 +0900 (JST)

> propose deprecating the default, to get everyone in the habit of specifying

	deprecating the default would break source-code level backward
	compatibility (code written for RFC2553 would have problem) so we
	need to keep NI_TCP to 0 and make it a default, unfortunately.
	if you have any solution please let me know.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Dec 2003 18:15:02 +0900 (JST)

> 	therefore, there's no 1-by-1 mapping from SOCK_xx to IPPROTO_xx.

	to clarify, i agree there should be some way to support non-inet
	protocols, however i'm not sure how service lookup works for non-inet
	protocols.  do people have any examples (such as appletalk or whatever)?

itojun

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 12 Dec 2003 09:01:56 -0800

> 	protocols.  do people have any examples (such as appletalk or 

AppleTalk is dead. Well, it's not quite dead yet, but it's getting 
there.

AppleTalk used something called NBP (Name Binding Protocol?). There 
were no host names, only service names. Services were discovered by 
type and a service name (an instance of a service) was resolved to an 
AppleTalk address and port. AppleTalk didn't have the notion of 
different sets of port lists for different protocols. The port came 
right after the address. It would be sort of like layering TCP, ICMP, 
and all other IP protocols on top of UDP.

It is unlikely anyone would ever work to support AppleTalk service name 
resolution through the getnameinfo API.

I don't think it is useful to abstract NI_SCTP and friends to support 
non-inet protocols. No matter what you do with getnameinfo, writing 
code to try and abstract out the protocol family with the socket APIs 
is nearly impossible. If someone wants to support some non-inet 
protocol, then they can probably handle an additional lookup or use 
some new vendor specific value that means SCTP or 
ApplesSCTPLikeAppleTalkBasedProtocol. What is there other than IP/IPv6? 
NetBIOS...IPX...AppleTalk...OSI? They're all dying (or should be).

-josh

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 Dec 2003 09:16:25 -0800 (PST)

> 	SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.

SOCK_STREAM sounds odd since SCTP doesn't provide a byte stream service - it
provides a service that has explicit message boundaries.

> 	DCCP should be SOCK_DGRAM only, if i understand correctly.

Also odd; you mean socket(AF_INET, SOCK_DGRAM, 0) might provide a DCCP
socket on systems that support DCCP? Or IPPROTO_DCCP would need to
be explicitly specified?

> 	protocols.  do people have any examples (such as appletalk or whatever)?

I think that is what we need to figure out.

Problem is that the socket() call takes both a type and a protocol argument
and getnameinfo() has a single NI_DGRAM which implementations map to
the single protocol argument in getservbyport().

But this reminds me; doesn't SCTP use the same port number space as TCP?
Will DCCP use the same port number space as either TCP or UDP?
The getnameinfo() man page seems to claim that NI_DGRAM is only needed
because there are a few ports which are used for different protocols in UDP
and TCP:

     A fifth flag bit, NI_DGRAM, specifies that the service is  a
     datagram  service,  and  causes getservbyport(3SOCKET) to be
     called with a  second  argument  of  "udp"  instead  of  the
     default  "tcp".   This  is  required  for the few ports (for
     example, 512-514) that have different services for  UDP  and
     TCP.

If this isn't going to be an issue for SCTP or DCCP maybe we don't
need to change anything.

  Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 13 Dec 2003 04:39:37 +0900 (JST)

> provides a service that has explicit message boundaries.

	SCTP do provide three models (SOCK_xx).
	draft-ietf-tsvwg-sctpsocket-07.txt talks about it more (it talks about
	SOCK_SEQPACKET and SOCK_STREAM only, but the reference implementation
	from rrs@cisco on KAME do provide SOCK_DGRAM too).

> socket on systems that support DCCP? Or IPPROTO_DCCP would need to

	could be, but for backward compatibility's sake i guess 0 would give
	you IPPROTO_UDP socket.

> But this reminds me; doesn't SCTP use the same port number space as TCP?

	basically the same space, but they do have separate entries on
	/etc/services and http://www.iana.org/assignments/port-numbers.
	for instance, http is only defined for http/tcp and http/udp at this
	point of time.  only a limited number of sctp services are defined on
	IANA assignment page.

	and since we have "foo/sctp" on /etc/services, we need to pass
	"sctp" as 2nd arg to getservbyport(3).

> Will DCCP use the same port number space as either TCP or UDP?

	IANA assignment page has no entry for dccp yet, so i'm not sure.

> If this isn't going to be an issue for SCTP or DCCP maybe we don't

	it is going to be an issue.  in fact, it already is.

itojun

---

From: Peter Lei <[email-masked]>
Date: Fri, 12 Dec 2003 22:10:43 -0600

> 	from rrs@cisco on KAME do provide SOCK_DGRAM too).

Yes, our reference implementation on KAME originally used SOCK_DGRAM
for the one-to-many API... that is technically incorrect since the
SCTP socket API calls out SOCK_SEQPACKET and SOCK_STREAM; I'm sure
we'll remove the SOCK_DGRAM use at some point.

The SOCK_STREAM use in the API draft is for backward compatibility
to TCP and a "migration" path for existing applications:

ie. change socket(AF_INET{6}, SOCK_STREAM, 0) to socket(AF_INET{6},
SOCK_STREAM, IPPROTO_SCTP) and you will get an "equivalent" functionality
(from the application perspective at the sockets interface) over SCTP.

> 	"sctp" as 2nd arg to getservbyport(3).

Actualy, RFC2960 explictily states that "All current TCP ports shall be
automatically reserved in the SCTP port address space." in the IANA
considerations section.

--peter

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 15 Dec 2003 16:29:43 +0900 (JST)

> 	as an IAB i was asked to comment on draft-ietf-ipv6-addr-arch-v4-00.txt,
> 	so here it is.  happy holidays.

	one more ;-)

itojun

MINOR
=====
	[email-masked] is no longer valid, so you may want to remove it
	from the draft.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 15 Dec 2003 08:57:22 -0800 (PST)

> automatically reserved in the SCTP port address space." in the IANA

That was what I remebered. If this indeed means that there will not
be any conflicting usage in the future (which the above text doesn't
explicitly say) then I think we at least don't have the problem
of getservbyport() returning different results for SCTP and TCP.

Don't know how significant the problem is that a given port (e.g., 80)
might not be defined for SCTP, even though the port number is
reserved, so that getservbyport() for SCTP should
fail and getservbyport() for TCP would return a service string.

  Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 16 Dec 2003 06:27:55 +0900 (JST)

> fail and getservbyport() for TCP would return a service string.

	(it may not be a IPv6 question, but unix API question)

	based on the RFC2960 statement, what should we do about getservbyport
	2nd argument for SCTP connection, and/or /etc/services entries?

	my guess is that (1) we need to put "foo/sctp" explicitly into 
	/etc/services and (2) 2nd argument must be "sctp".  this is based on
	observation from tcp/udp case (even if there's the same service - such
	as http - on the same port, we put separate entries into /etc/services)

itojun

---

From: Andrew White <[email-masked]>
Date: Tue, 16 Dec 2003 12:37:13 +1100

Jun-ichiro itojun Hagino wrote:
> 
> > And define NI_TCP, which is also the default if none is specified?
> > I'd also propose deprecating the default, to get everyone in the habit
> > of specifying something.
> 

Techically, deprecating would break nothing, since it changes the status to
"supported but discouraged".  The goal is to get programmers into the habit
of specifying something, not to actually remove the functionality.  The
intent is not to actually take the 2nd step of removing the deprecation,
just discourage the usage.

-- 
Andrew White

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 16 Dec 2003 10:57:23 +0900

>>>>> On Mon, 15 Dec 2003 10:13:16 -0800, 
>>>>> Fred Templin <[email-masked]> said:

> Last I heard, Steve Deering had gone walkabout - but
> surely, he must have a new e-mail address by now?

Perhaps the best way is that someone who can contact Steve personally
asks him explicitly, but jus FYI:

When I updated the scope-arch draft in which Steve is a co-author, I
contacted him personally and asked how we should update the author
information for him.  The answer was:

- keep the Cisco address listed with his name, but just delete the
  Phone, Fax, and Email lines.  That way, Cisco will continue
  to get the credit (or blame) for the work he did while employed by them,
  and anyone who wants to ask questions about the document will have to
  contact one of the other author(s).
- he certainly did NOT want to list his new email address, if any, to
  hide the address from spammers.

and I simply followed his advice.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Dec 2003 11:49:47 +0100

[email-masked] wrote:
...
> textual representation
>         2.2 (1) has to state how many digits are permitted as "x"
>         (one component between colon).  my personal preference is that
>         "x" has to be 1 to 4 digits (5 digits or more is invalid).

I think an informative reference to draft-main-ipaddr-text-rep-00.txt
is needed. I agree that the limit should be 4 digits (optionally including 
leading zeros) and the draft-main- syntax specifies that.

   Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 22 Dec 2003 16:29:26 +0900

>>>>> On Tue, 16 Dec 2003 11:49:47 +0100, 
>>>>> Brian E Carpenter <[email-masked]> said:

> is needed.

In Minneapolis, I made a similar comment and Bob said the reference
from addr-arch to ipaddr-text is not necessary (see
http://www.ietf.org/proceedings/03nov/minutes/ipv6.htm and search for
"ABNF")

I myself does not have a particular opinion, but would like to see a
consensus.  I'm currently revising the scoping architecture draft, and
the consensus might affect the references section there, too.

> I agree that the limit should be 4 digits (optionally including 

Regarding this part, I agree.  It should also be noted that we had the
same discussion in this April to June (at the ipngwg ML with the
subject "IPv6 Address validation").  Unfortunately, we did not reach a
consensus at that time as far as I can see.  It's nice if we can make
it this time.

					JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Dec 2003 12:49:11 -0500

> >>But this reminds me; doesn't SCTP use the same port number space
    as TCP?

Not anymore.

> automatically reserved in the SCTP port address space." in the IANA

This was updated, but not documented well. Because it is not clear
that an application that runs over TCP can also run over SCTP (and
vice versa) without some application-specific considerations,
automatically allocating ports from both spaces for an application was
deemed not-so-good an idea. So at this point, the SCTP and TCP port
spaces are not shared.

Thomas