Subject: UPDATE rfc2553bis Update for IPv6 Extended address scope

From: Jim Bound <[email-masked]>
Date: Tue, 22 Feb 2000 13:27:06 -0500

Hi JINMEI,

Changed subject so I can identify this mail as different for me.

I am fine with the attached and the referencing of  your draft that is
much wiser.  So I will use this text for 1st draft of 2553bis as we
evolve.

thanks
/jim

--------------------------------------

As for the precise format, we've discussed it with Brian (Zill@MSR),
Rich (Draves@MSR), Francis (Dupont@INRIA), and some KAME guys, and
almost agreed on the following format:
<scoped_address>%<scope_id>
that is,
- the delimiter character is `%'
- the scope_id part is placed after the address with the delimiter.

I'm going to revise our draft with this format and will soon post it
to the list.

6.4 Protocol-Independent Nodename and Service Name Translation

page 27:
   The nodename and servname arguments are pointers to null-terminated
   strings or NULL.  One or both of these two arguments must be a non-
   NULL pointer.  In the normal client scenario, both the nodename and
   servname are specified.  In the normal server scenario, only the
   servname is specified.  A non-NULL nodename string can be either a
   node name or a numeric host address string (i.e., a dotted-decimal
   IPv4 address or an IPv6 hex address,
[addition:]
   which includes an extended address format for a scoped IPv6
   address[Refer to the scopedaddr-format draft]).
...

page 28, 2nd paragraph:
   socket() function.  In each addrinfo structure the ai_addr member
   points to a filled-in socket address structure whose length is
   specified by the ai_addrlen member.

[addition:]
   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. If the
   scope identifier is given as a string (e.g. an interface name),
   getaddrinfo() first translates it into an according numeric number,
   and then sets the number to the sin6_scope_id field. The mapping
   between the string to the numeric number is implementation dependent.
   Getaddrinfo() returns the EAI_NONAME error when the translation
   fails. It also returns the same error code if the scope identifier
   is a negative number.

   If the AI_PASSIVE bit is set in the ai_flags member of the hints
   structure, then the caller plans to use the returned socket address
   ...

6.5 Socket Address Structure to Nodename and Service Name
...

   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()).
[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.
--------------------------------------------------------------------
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:13 +0900

>>>>> On Tue, 22 Feb 2000 13:27:06 -0500, 
>>>>> Jim Bound <[email-masked]> said:

> much wiser.  So I will use this text for 1st draft of 2553bis as we

Thanks. Since some clarifications are still necessary (as you see in
this list), I'll revise the text a bit and post it again. Sorry for
bothering you, but I'll try to do that as soon as possible.

					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]
--------------------------------------------------------------------