Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope

From: Richard Draves <[email-masked]>
Date: Tue, 22 Feb 2000 22:50:43 -0800

> [addition:]
>    Moreover, if sa points to a sockaddr_in6 structure for an IPv6
>    scoped address and the sin6_scope_id field of the structure has
>    a non-zero value, the returned numeric form should be in the
>    extended format, that is, the address is followed by a scope
>    identifier according to the value of the sin6_scope_id field with
>    the delimiter character. The scope identifier is either the numeric
>    number of the sin6_scope_id field or an implementation specific
>    string (e.g. an interface name) of the sin6_scope_id field. If sa
>    points to a sockaddr_in6 structure for an IPv6 global address with
>    a non-zero value of the sin6_scope_id field, getnameinfo() simply
>    ignores the sin6_scope_id field and just returns the numeric form
>    of the global address.

I would prefer if sin6_scope_id is stringified independently of the address.
(Or if the scope-id is translated to a non-numeric scope-id name, then do
that for link-local & site-local addresses but otherwise treat the scope-id
& address as opaque.) It's simpler and more open to future evolution.

Rich
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 24 Feb 2000 02:41:28 +0900

>>>>> On Tue, 22 Feb 2000 22:50:43 -0800, 
>>>>> Richard Draves <[email-masked]> said:

>> If sa

> & address as opaque.) It's simpler and more open to future evolution.

I see. Since we let getaddrinfo() treat scope-id and adress as opaque,
it would be natural to apply the same rule to getnameinfo().

If no one opposes this, I'll revise the text. (Sorry for revising so
soon...)

					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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 25 Feb 2000 02:50:04 +0900

>>>>> On Thu, 24 Feb 2000 02:41:28 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> If no one opposes this, I'll revise the text. (Sorry for revising so

Since I've seen no objection, I'd like to revise the text for
getnameinfo() according to the Rich's suggestion. Please use the
following instead of one I posted before. I'd apologize for the
change in a short period.

Thanks,

=== text start =====
   Moreover, if the sin6_scope_id field of the structure has a
   non-zero value, the returned numeric form should be in the extended
   format, that is, the address is followed by a scope identifier
   according to the value of the sin6_scope_id field with the
   delimiter character. The scope identifier is either the numeric
   number of the sin6_scope_id field or an implementation specific
   string (e.g. an interface name) of the sin6_scope_id field. Note
   that this translation is applied to IPv6 global addresses as well,
   although the result would be semantically invalid.
=== text end =====

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 08:18:01 -0500

JINMEI,

>change in a short period.

Its only been two days.  I need to see some consensus or silence on this
for a few more days.  Folks could be offline that I need to be sure have
seen this change.  So far only Richard has sent mail and you agreed.
Not enough for me.

Are you saying here and elsewhere that the ai_addr value will be more
than IPv6 address?  If so I think I disagree.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 08:31:27 -0500

whoops I mean't sin6_addr?

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 11:51:29 -0500

JINMEI,

Here is my issue.

I incorrectly thought you were applying this to AI_NUMERIC too and sorry
for that I was working on the API draft and renumbered the sections in
my formatter by mistake.  Thats why I thought you were doing this for
getaddrinfo.  Have to just look at 2553 now.

But.

Applications that do not understand scopes nor care should not get back
scope+address.  I think if one wants this behavior we need another flag?

Another option is to specify if a "name" is not found then don't return
the address and go use getaddrinfo?

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 26 Feb 2000 02:31:18 +0900

>>>>> On Fri, 25 Feb 2000 08:18:01 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> than IPv6 address?  If so I think I disagree.

Sorry for the lack of context, but I meant the above text was applied
only to returned values of getnameinfo(), that is, a string. For
example, the followings are the intention of the above text:

  struct sockaddr_in6 sa6;

  sa6.sin6_addr = inet_pton("2001::1"); /* just for an example */
  sa6.sin6_scope_id = 100; /* I'm not sure if 100 is valid. */
  getnameinfo(&sa6, buf);  /* this is a conceptual usage of getaddrinfo(). */
  printf("%s\n", buf);

  The result should be:
    2001::1%100

In the previous text, the return value of getnameinfo() would be:
    2001;:1

i.e it should ignore the scope_id part.

Rich's suggestion was that getnameinfo() should treat the
sin6_scope_id field just as opaque, which I agreed. I didn't intend
any changes of the semantics of ai_addr.

======
In any case, I didn't mean that we got a consensus with silence only
in a few days. If anyone would oppose the change, I'd like to listen
to the opinion, and would obey the final result. I sent the revised
text just for convenience of further edition and discussion. I'd
apologize in advance if it was complacent.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 27 Feb 2000 01:42:47 +0900

>>>>> On Fri, 25 Feb 2000 11:51:29 -0500, 

> getaddrinfo.  Have to just look at 2553 now.

I see.

> scope+address.  I think if one wants this behavior we need another flag?

Hmm, I personally think that such applications could use inet_ntop()
instead of getnameinfo() and that getnameinfo() should treat sockaddrs
just as opaque. However, I don't oppose introducing an additional flag
to getnameinfo(), e.g. NI_WITHOUTSCOPE.

> the address and go use getaddrinfo?

Sorry, I can't understand this. What do you mean by "go use
getaddrinfo"?

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Sun, 27 Feb 2000 17:08:48 -0500

Hi JINMEI,

Let me step back here.

getaddrinfo essentially returns an address and other stuff when you give
the function a name.

getnameinfo essentially returns a name from an address.

The issue for getnameinfo is that if NI_NUMERICHOST is set:  

FROM RFC 2553:
   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
be
   located in the DNS, the numeric form of the host's address is
returned
   instead of its name (e.g., by calling inet_ntop() instead of
   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
  returned if the host's name cannot be located in the DNS.

If what comes back is FEC0::1%123 (meaning the address and site
identifier) in char *host field.  

What does an application do with this string now?  It can't be passed as
an address to any application I am aware of running today?

thanks
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 28 Feb 2000 17:27:53 +0900

>>>>> On Sun, 27 Feb 2000 17:08:48 -0500, 

> an address to any application I am aware of running today?

It can, if the applications use the extended getaddrinfo() to handle
the new format for scoped addresses. I think we can assume that if we
had the extended getnameinfo() then getaddrinfo() would also be
extended. So the problematic case would occur in applications that do
not use getaddrinfo() for hostname to address translation.

It is my understanding that we would recommend applications to use
getaddrinfo() in a 2553bis era, thus I don't think it does really
matter. However, if we seriously care about the issue, we could
introduce an additional flag (say, NI_WITHSCOPE) to getnameinfo() and
disable the flag by default.

What do you (and others) think?

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Mon, 28 Feb 2000 11:33:13 -0500

>What do you (and others) think?

But I am still asking another question.  The programmer now has returned
sitting in a string from getnamefino:

FEC0::1%123

This can't be passed to any function as a dst address.  What function
parses the above string so:

sin6_addr = FEC0::1
sin6_scope_id = 123

getaddrinfo?  

/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Feb 2000 02:07:14 +0900

Hello,

>>>>> On Mon, 28 Feb 2000 11:33:13 -0500, 

> getaddrinfo?  

Yes, it's getaddrinfo(). According to the additional text for
getaddrinfo() that I posted here last week:

   If the nodename is a textual IPv6 scoped address with a scope
   identifier, getaddrinfo() sets the appropriate numeric number
   for the scope identifer to the sin6_scope_id field of each returned
   sockaddr_in6 structure. For a zero or positive numeric scope
   identifier, getaddrinfo() simply copies the value to the
   sin6_scope_id field, and lets the kernel validate the value.

Conceptually, the relationship between getaddrinfo() and getnameinfo()
is as the following figure:

            ----getaddrinfo--->
fec0::1%123                    {sin6_addr = fec0::1, sin6_scope_id = 123}
            <---getnameinfo----

I'm afraid the text was unclear enough due to my poor English. If so,
please let me know. Then I'll try to make it clearer.

Thanks,

					JINMEI, Tatuya

---

From: Jim Bound <[email-masked]>
Date: Mon, 28 Feb 2000 12:39:43 -0500

>   sin6_scope_id field, and lets the kernel validate the value.

Understand that.

Nit: Above you say "kernel" I think you mean "user space" I believe KAME
code does DNS processing and get***info calls in user space?  Not the
kernel unless it is BITS.

>fec0::1%123                    {sin6_addr = fec0::1, sin6_scope_id = 123}

Lets take this example:

User types:  telnet FEC0::1%123 (not that I recommend this)

First call will be to getnameinfo or getaddrinfo?

I think getaddrinfo as inet_pton will not work on the above string and
AI_NUMERIC will have to be set?

>please let me know. Then I'll try to make it clearer.

Not at all your english is fine at my end.  It is the sequence.

thanks
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Feb 2000 12:42:14 +0900

>>>>> On Mon, 28 Feb 2000 12:39:43 -0500, 

> code does DNS processing and get***info calls in user space?

Yes, KAME implements get***info in user space, but what I meant in the
above text was that getaddrinfo() does not validate the numeric value of
the <scope_id> portion. For example, even if "123" is not a valid
(e.g. site) scope identifier as a node, getaddrinfo() itself would not
fail and just copy the value to sin6_scope_id field of a sockaddr_in6
structure. The user would notice the invalidity when the structure is
passed to the kernel by a succeeding system call.

So I might have written the text as follows:

   For a zero or positive numeric scope
   identifier, getaddrinfo() simply copies the value to the
   sin6_scope_id field, and lets the kernel validate the value when
   the structure is passed to the kernel by a succeeding system call.

> First call will be to getnameinfo or getaddrinfo?

getaddrinfo().

> AI_NUMERIC will have to be set?

Ah, I think I get your concern. This is the KAME's behavior:

  KAME's getaddrinfo() first tries to translate a given string as a
  numeric form regardless of the AI_NUMERICHOST flag. If the translation
  succeeds, the function just returns the result. Otherwise, it then
  tries to resolve the string as an FQDN unless AI_NUMERICHOST is set.

FEC0::1%123 in the above example would be covered in the first
process. Although the implementation doesn't process the string exactly
as specified in the spec (i.e. it first tries the numeric case), it would
not be a problem because the string "fec0::1%123" (or even just
"fec0::1") is invalid as a domain name.

> Not at all your english is fine at my end.  It is the sequence.

Okay, thanks.

					JINMEI, Tatuya