>>>>> On Wed, 05 Jul 2000 01:43:09 +0900,
>>>>> Hideaki YOSHIFUJI <[EMAIL PROTECTED]> said:
>> >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
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?
>> >* 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.
(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.)
>> 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?
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 PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
