Hi XXXXX,
>Dear authors,
I have cc'd the IETF IPng Working Group with my response. All
co-authors are on this list, except for Richard Stevens who has passed
on.
These comments are my view of the world. I sent it here to get the
working group to provide comments.
>>The Linux IPv6 Users JP, and I would like to comment on your ID
>>entitled "Basic Socket Interface Extensions for IPv6"
>>(draft-ietf-ipngwg-rfc2553bis-00).
>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.
> (it can be used as 3rd argument for connect() or bind() directly;
> otherwise, we must do a "cast" operation.
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?
>* 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.
>* AI_V4MAPPED
> This name is not suitable for getaddrinfo as a protocol-independent
> function. It should be changed to more protocol-independent name;
> for example, AI_MAPPED.
This name has been around a long time. Also the V4 part has a specific
meaning and is NOT protocol independent. So I don't agree and will not
make the change.
> 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. */
Well first I have heard of it and GNU C libray does not rule but POSIX
according to me view of the world and ANSI C.
Change GNU library.
># define AI_PASSIVE 1 /* Socket address is intended for `bind'. */
># define AI_CANONNAME 2 /* Request for canonical name. */
># define AI_NUMERICHOST 4 /* Don't use name resolution. */
Same answer.
>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 ?????
- If the flag bit NI_NUMERICSCOPE is set, the numeric form of the
scope identifier is returned (for example, interface index)
instead of its name. This flag is ignored if the sa argument is
not an IPv6 address.
>* 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 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 ????
> char *sa2host(struct sockaddr *sa, socklen_t salen){
> int gni;
> static char addrbuf[INET6_ADDRSTRLEN + NI_MAXSCOPE];
> gni = getnameinfo(sa, salen,
> addrbuf, sizeof(addrbuf), NULL, 0,
> NI_WITHSCOPE);
> return (gni ? NULL : addrbuf);
> }
>
> Or, we may re-define the value of INET6_ADDRSTRLEN;
> it can be named "NI_MAXNUMHOST".
If you define NI_MAXSCOPE to sin6_scope_id length then it will work.
We were very clear on separating addresses from scopes. Two different
datums.
>* 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.
> This is useful for the following situations:
> - when you logs peer addresses;
> some people want to see "127.0.0.1", not "::ffff:127.0.0.1"
Yes we can put a health warning for this and its an implementation
issue.
>> - 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?
>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.
>4. POSIX Consideration
>
>* 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.
thanks
/jim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
