Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Wed, 05 Jul 2000 01:43:09 +0900

Hi, all,

In article <[email-masked]> (at Mon, 26 Jun 2000 22:19:38 -0400), Jim Bound <[email-masked]> says:

> >1. Section 6.4: Protocol-Independent Nodename and Service Name Translation
> 
> >* struct addrinfo{}
> >  Type of ai_addrlen member should be delcared as socklen_t, 
> >  not size_t.  

> Hmmm.  Works fine for me??? But I do see your point.  We are following
> XNET lead here see code snippet below and tell me why I will not work
> for you?

Though it may be ok without a cast operation, it is not clean, is it?

> >* All paragraphs:
> >  All constants related to ai_family should be PF_* as commented in
> >  the definition of struct addrinfo{}; do not use AF_*.
> 
> I will have to check this in the spec?  I thought we had fixed this?
> If we missed it it was an edit error.  Thanks.

RFC2553 is ok but RFC2553-bis has some errors.

> >* AI_V4MAPPED

> >  Note: Currently, the values of AI_* of the GNU C Library are conflicted:
> >#define AI_V4MAPPED     1       /* IPv4-mapped addresses are acceptable.  */
> >#define AI_ALL          2       /* Return both IPv4 and IPv6 addresses.  */
> >#define AI_ADDRCONFIG   4       /* Use configuration of this host to choose
> >                                   returned address type.  */

> Change GNU library.

I sent a bug report to glibc people.

BTW, RFC2553 and POSIX do not say AI_* must not conflicted, do they?
If they don't, decision of glibc was not illeagal.

> >2. Section 6.5: Socket Address Structure to Nodename and Service Name
> 
> >* NI_WITHSCOPEID
> >  Please define NI_WITHSOCPE.  With this flag, getnameinfo() will return
> >  with scope-identifiers for link-local, site-local, org-local addresses if
> >  NI_NUMERICHOST is supplied; otherwise, no scope-identifier will be 
> >  returned.  Without providing this flag, applications that assumes 
> >  INET6_ADDRSTRLEN maximum length of IPv6 address may be crashed.  
> >  (Even if you re-define the value of INET6_ADDRSTRLEN, we need this 
> >  flag because binaries already compiled may be crashed.)
> 
> Whats wrong with ?????

What I want to get as default is (maybe) what you get with NI_WITHOUTSCOPE
(for backward compatibility).

Note: INET6_ADDRSTRLEN is not large enough to store scoped-address.
      sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255%4294967295") = 57

> >* If sin6_scope_id is filled and the name for id (interface name for 
> >  link-local addresses), what should we do?
> 
> >  Option: raise an error (EAI_NONAME) if called with NI_NAMEREQD;
> >          otherwise, return numeric scope-id.
> >  Option: always raise an error (EAI_NONAME)
> 
> Sounds like a fair implementation choice.  I would argue it will fail
> because one should not be putting link-local addresses in the DNS.

I see.

> >* I want to have a new value "NI_MAXSCOPE" which indicates maximum length of
> >  scope-name including scope-delimiter / excluding terminating null-character.
> >  It already have IF_NAMESIZE for link-local scope-names, but it is not
> >  sufficient; we also have site-local scope identifiers.
> 
> Why?  It can't be larger than uint32_t ????

"No" for numeric identifiers (see below),
but yes for non-numeric identifiers (such as link-local ids);
and IF_NAMESIZE may be larger than IF_NAMESIZE.

> If you define NI_MAXSCOPE to sin6_scope_id length then it will work.

Should we locally defined NI_MAXSCOPE as 
((int)((sizeof(u_int32_t)*CHAR_BIT+2)/3+1)) or so?

> >* I want to have a new flag NI_UNMAPPED not to have "::ffff:127.0.0.1"
> >  but "127.0.0.1" for mapped-addresses.  This is "inverse-function" of 
> >  AI_MAPPED flags.
> 
> I don't agree its the inverse at all?  All you do is request PF_INET.

???  
                       getaddrinfo() with AI_MAPPED
                      ----------------------------->
  IPv4-address string                                IPv4-mapped sockaddr_in6{}
                      <-----------------------------
                      getnameinfo() with NI_UNMAPPED

Please see the following code and imagine ipv4 client 127.0.0.1 connects 
this socket.

  void sample(){
    int sd, newsd;
    struct sockaddr_in6 sin6;
    socklen_t len;
    char addrbuf[NI_MAXHOST];

    memset(&sin6, 0, sizeof(sin6));
    sin6.sin6_family = AF_INET6;
#ifdef SIN6_LEN
    sin6.sin6_len = sizeof(sin6);
#endif
    sin6.port = htons(12345);
    sd = socket(PF_INET6, SOCK_STREAM, 0);
    bind(sd, (struct sockaddr *)&sin6, sizeof(sin6));
    listen(sd, 1);
    len = sizeof(sin6);
    newsd = accept(sd, (struct sockaddr *)&sin6, &len);
    
    getnameinfo((struct sockaddr *)&sin6, len,
                addrbuf, sizeof(addrbuf), NULL, 0,
                NI_NUMERICHOST|NI_NUMERICSCOPE);
    printf("%s\n", addrbuf);
  }

With NI_UNMAPPED flag to getnameinfo(), we do want to get
"127.0.0.1" instead of "::ffff:127.0.0.1".

> >>  - when we use peer-address for authentication.
> >    With this, we are free from a lot of painful work to convert 
> >    ipv4-addresses to ipv4-mapped addresses.  
> 
> Just use PF_INET?

See above.

> >3. Others
> >
> >* I want to have getifaddrs(3) (first implemented by BSDi) standarized
> >  (or documented); ths function is used to get interface addresses.
> 
> I think this should be done in the advanced API.  The reason is 
> it presents a large set of new problems for scoping this spec
> should not be dealing with.  

I see.

> >* Please add "POSIX Consideration"
> >  Glibc people says declarations for some functions (like 
> >  inet_{pton,ntop}() or getnameinf()) in RFC2553 are conflicted 
> >  with ones in POSIX.
> 
> This we need to check.  But realize POSIX will use this spec with XNET
> approval.  They are out of wack now but are in the process of synching
> up.

Current XNS spec is strange.

Thanks.

-- 
Hideaki YOSHIFUJI <[email-masked]>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 05 Jul 2000 01:50:35 +0900

>Current XNS spec is strange.

	I think I have emailed on this more than twice, for me it seems that
	glibc people misunderstood what is meant by "socklen_t".  I *strongly*
	object to make this unnecessary change (size_t -> socklen_t for
	hostnamelen/servnamelen/etc).

itojun

---

From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Wed, 05 Jul 2000 02:13:44 +0900

> 	hostnamelen/servnamelen/etc).

Yes I know, I know!  But they won't change unless XNS changes... (sigh)

XNS 5.2: <http://www.opengroup.org/onlinepubs/009619199/>

---

From: [email-masked]
Date: Wed, 05 Jul 2000 20:40:07 +0900

>XNS 5.2: <http://www.opengroup.org/onlinepubs/009619199/>

	I'm confused, which people are you trying to convince?
	Are you trying to change 2553 to use socklen_t for all the arguments,
	or are you trying to correct glibc?  If the latter, the mailing list
	is a wrong place to ask.

	Some description on current situation should help you...
	The XNS-RFC incompatibility will be solved when 2553bis document
	is finalized.  For the current specification, RFC2553 looks
	more correct (RFC2553 is more closer to 2553bis).  For updated
	specification, words in 2553bis will be directly put into XNS so
	they will become exactly the same. (correct me if my memory is wrong)

	As there is no change between RFC2553 and 2553bis on this particular
	"getnameinfo argument" issue, RFC2553 is the correct specification
	to look at for this particular issue.

	Please try to convince glibc guys, quoting the above if necessary.

itojun

---

From: Hideaki YOSHIFUJI <[email-masked]>
Date: Wed, 05 Jul 2000 22:52:02 +0900

Hi, all.

> 	or are you trying to correct glibc?  If the latter, the mailing list

	Of course, the latter.

> 	they will become exactly the same. (correct me if my memory is wrong)

	When will 2553bis be finalized?
	If it takes much time, new glibc ships with wrong declaration
	because they won't respect RFC2553(bis), but XNS.
	Then, many distributions will ships with incorrect glibc. (bad...)

> 	Please try to convince glibc guys, quoting the above if necessary.

	I've raised an official bug-report:
	<http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full?pr=1805>

	We need comments on this from people other than me to convince them.

	Please, please comment on this directly (not via me) to the 
	glibc people.  We really need it.

---

From: [email-masked]
Date: Wed, 05 Jul 2000 23:19:02 +0900

>	Here's how to append comment onto the above bug report:
>	send email with the following headers.
>	To: [email-masked]
>	Subject: Re: libc/1805

	There will be some delay until the bug report gets updated, so
	DON'T RESEND even if you don't see your email pasted onto the bug
	report.

itojjun

---

From: [email-masked]
Date: Wed, 05 Jul 2000 23:17:47 +0900

To: [email-masked]
	Subject: Re: libc/1805

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Jul 2000 00:14:15 +0900

>>>>> On Wed, 05 Jul 2000 01:43:09 +0900, 
>>>>> Hideaki YOSHIFUJI <[email-masked]> said:

>       sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255%4294967295") = 57

I can understand your motivation, but I personally think that if an
application calls getnameinfo() with sockaddr_in6, NI_NUMERICHOST, and
a hostname buffer of INET6_ADDRSTRLEN in length, the possible breakage
is the application's own fault; it should not assume such a protocol
specific limitation for a protocol independent library function like
getnameinfo().

KAME's implementation locally defines NI_WITHSCOPEID, but I'm not sure
if it sould be incorporated into rfc2553bis.

BTW, I remeber there was a discussion about how getnameinfo() should
do when a given buffer size is too small to store a hostname. But I
don't remember the conclusion (if any)...was this already clarified?

>> >  sufficient; we also have site-local scope identifiers.

(Although this is not directly related to this issue, but) you seem to
be a bit confused about the relationship between the interface scope
and the link scope. According to draft-ietf-ipngwg-scoping-arch-01,
the interface scope is (conceptually) smaller than the link
scope. However, in KAME's implementation, we intentionally assume a
one-to-one mapping between interfaces and links, and thus we use
interface names for link identifiers. But we should not mix up
interfaces with links when we make a general discussion. (Actually,
there is some confusion on this point in rfc2553bis-00, too. But this
is another issue. I'll raise it up later.)

> ((int)((sizeof(u_int32_t)*CHAR_BIT+2)/3+1)) or so?

NI_MAXSCOPE might be useful, but I personally think NI_MAXHOST is
sufficient. And, in any case, we should clarify how getnameinfo()
should do with a short buffer (if we haven't).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Mon, 10 Jul 2000 02:19:27 +0900

>don't remember the conclusion (if any)...was this already clarified?

	the consensus was to raise error (instead of give truncated result).
	2553bis is rather silent about it, it should have more comment on it.

itojun