Subject: Re: additional agenda item

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 01 Mar 2004 16:54:25 +0900

>>>>> On Sun, 29 Feb 2004 18:24:33 -0800 (PST), 
>>>>> Erik Nordmark <[email-masked]> said:

> It would be good to ask (e.g. on the appsarea list - [email-masked]
> I think) if there are applications that need other configuration information
> than the list of interfaces/ifindicies (which we already have) and
> a list of all IP address (which is what you are proposing).

Fair enough, but let me make a quick check: is this a direct response
to my request for a slot (positive or negative), or just a general
input on this issue itself?

> Is that all we need to add to avoid having applications use SIOCGIF
> ioctls?

Perhaps this is included in "IP address", but the prefix lengths/net
masks of addresses will also be needed (I know applications that need
this information).  getifaddrs(3) can provide it.

FYI: currently getifaddrs(3) provides the following information:

         char             *ifa_name;         /* Interface name */
         u_int             ifa_flags;        /* Interface flags */
         struct sockaddr  *ifa_addr;         /* Interface address */
         struct sockaddr  *ifa_netmask;      /* Interface netmask */
         struct sockaddr  *ifa_broadaddr;    /* Interface broadcast address */
         struct sockaddr  *ifa_dstaddr;      /* P2P interface destination */
         void             *ifa_data;         /* Address specific data */

     The ifa_data field references address family specific data.  For AF_LINK
     addresses it contains a pointer to the struct if_data (as defined in
     include file <net/if.h>) which contains various interface attributes and
     statistics.  For all other address families, it contains a pointer to the
     struct ifa_data (as defined in include file <net/if.h>) which contains
     per-address interface statistics.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 01 Mar 2004 22:43:23 +0900

>>>>> On Mon, 1 Mar 2004 00:08:54 -0800 (PST), 

> Latter.

> On the former; Getting the API for the list of addresses documented seems 
> quite useful so I think it makes sense spending face time on this.

Understood, and thanks.

> Aren't the flags implementation specific?

I'm not sure, but probably yes, it is implementation specific.

>> statistics.  For all other address families, it contains a pointer to
>> the struct ifa_data (as defined in include file <net/if.h>) which
>> contains per-address interface statistics.

> The actual statistics that are provided might be implementation specific.

Again, probably correct.

> Do we want an API that can be provided for non-BSD IP stacks? Windows?

If we agree on the need for this kind of API, I believe it should be
portable, that is, it should work for non-BSD, Windows, or whatever.
So, the resulting API might lose some of the information that the
current getifaddrs(3) library can provide.  But I'd rather be happier
to have a portable API.

					JINMEI, Tatuya

---

From: YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]>
Date: Tue, 02 Mar 2004 16:55:46 +0900 (JST)

In article <[email-masked]> (at Mon, 01 Mar 2004 17:27:22 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]> says:

> 2. The description for "ifa_flags" is rather bogus.
>    For L3 addresses, it seems to return IFA_xxx (or IN6_IFA_xxx?) flags,
>    instead of IFF_xxx flags for L2.

Sorry, this is not correct.
ifa_flags always describe IFF_xxx flags.
(I don't remember why I did not think so...)
Sorry, again.

-- 
Hideaki YOSHIFUJI @ USAGI Project <[email-masked]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 05 Mar 2004 02:23:10 +0900

>>>>> On Mon, 01 Mar 2004 10:12:41 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> According to the agenda shown at
> http://www.ietf.org/ietf/04mar/ipv6.txt, we will be able to have a few
> more items.  If this is the case, may I ask for a short slot about an
> API extension to get a list of IPv6 addresses (as well as other AF
> addresses) on a node?  This was discussed in the wg list early
> February and I just made a delayed response. (the subject is
> "SIOCGIFaaa ioctls and IPv6 interfaces").

> I don't have a draft on this, and this may not be suitable for this wg
> (or even for the IETF), but some people seem to be interested in this
> topic, I want to have a chance to see if this is worth discussing in
> this group.

My understanding in the meeting was that this wg is not an appropriate
place to discuss the issue though this is a useful topic.  I actually
thought the same concern from the beginning, so I'm fine with the
decision.

Dave mentioned POSIX as a more appropriate place, but I myself have do
not any connection to the community.  As suggested at the meeting, I
thus would like to ask a question here: does anyone have a suggestion
on a further step for this work, including how we can get access to
the community, or a different "appropriate place" that we can easily
cooperate with, etc?  Any comments/suggestions are welcome.

Thanks,

					JINMEI, Tatuya

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 05 Mar 2004 09:36:55 +0900 (JST)

確かにびみょー

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 05 Mar 2004 10:29:17 +0900 (JST)

Please ignore previous mail. I selected incorrect mail to reply.
Sorry for bothering you.

--
SHIRASAKI Yasuhiro

---

From: YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]>
Date: Mon, 01 Mar 2004 17:27:22 +0900 (JST)

Hello.

>          void             *ifa_data;         /* Address specific data */

1. From the viewpoint of protocol independent programming,
   we need to have ifa_addrlen or something like that because
   non-4.4-BSDs (such as Windows, Solaris, Linux, etc...) does not 
   seem to have sa_len field in sockaddr{}.

2. ifa_broadaddr and ifa_dstaddr will conflict on some platforms.
   Linux already has the following #define in <net/if.h>.

     struct ifaddr {
         struct sockaddr ifa_addr;
         union {
             struct sockaddr ifu_broadaddr;
             struct sockaddr ifu_dstaddr;
         } ifa_ifu;
         struct iface *ifa_ifp;
         struct ifaddr *ifa_next;
     };
     #define ifa_broadaddr  ifa_ifu.ifu_broadaddr
     #define ifa_dstaddr    ifa_ifu.ifu_dstaddr

   On Linux, ifaddrs{} is like this:
     struct ifaddrs {
         struct ifaddrs *ifa_next;
         char *ifa_name;
         unsigedint int ifa_flags;
         struct sockaddr *ifa_addr;
         struct sockaddr *ifa_netmask;
         union {
             struct sockaddr ifu_broadaddr;
             struct sockaddr ifu_dstaddr;
         } ifa_ifu;
         void *ifa_data;
     };

   We need to be careful to describe the structure.

3. flags are different from system to system;
   it is not so easy to describe (especially for IFA_xxx).

I'm trying to write some proposals on this...

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 1 Mar 2004 00:08:54 -0800 (PST)

Latter.

  Erik