Subject: 2292bis ip6_rthdr0 flexible array member

From: Michael Hunter <[email-masked]>
Date: Wed, 11 Sep 2002 15:29:42 -0700

In 2292bis the version 0 routing header is specified in section 2.1.2
as

       /* Type 0 Routing header */
       struct ip6_rthdr0 {
         uint8_t  ip6r0_nxt;       /* next header */
         uint8_t  ip6r0_len;       /* length in units of 8 octets */
         uint8_t  ip6r0_type;      /* always zero */
         uint8_t  ip6r0_segleft;   /* segments left */
         uint32_t ip6r0_reserved;  /* reserved field */
           /* followed by up to 127 struct in6_addr */
       };

It would be easier to use if a c99 flexible array member was the last
element:

       /* Type 0 Routing header */
       struct ip6_rthdr0 {
         uint8_t  ip6r0_nxt;       /* next header */
         uint8_t  ip6r0_len;       /* length in units of 8 octets */
         uint8_t  ip6r0_type;      /* always zero */
         uint8_t  ip6r0_segleft;   /* segments left */
         uint32_t ip6r0_reserved;  /* reserved field */
#if __STDC_VERSION__ >= 199901L
	struct in6_addr ip6r0_addr[0]; /* up to 127 addresses */
#endif
       };

			mph
--------------------------------------------------------------------
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, 20 Sep 2002 14:24:46 +0900

(Sorry for the delayed response)

>>>>> On Wed, 11 Sep 2002 15:29:42 -0700, 
>>>>> Michael Hunter <[email-masked]> said:

> 	struct in6_addr ip6r0_addr[0]; /* up to 127 addresses */

Sorry, but I don't think we should incorporate this to the
specification.  If an application writer assumes the existence of
ip6r0_addr, the source code will not compile with a compiler that
does not support the flexible array member.  However, I don't want to
see conditional compilation tricks like this:

	struct ip6_rthdr0 *r;
	struct in6_addr *in6;

#if __STDC_VERSION__ >= 199901L
	in6 = &r->ip6r0_addr[0];
#else
	in6 = (struct in6_addr *)(r + 1);
#endif

					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: Wed, 25 Sep 2002 22:00:56 +0900

>>>>> On Mon, 23 Sep 2002 13:01:21 -0700, 

> I don't like conditional compilation either.  Its a maintenance
> headache.  That said I think if you don't choose a easy way to access
> the variable length array of addresses you will end up with
> implementers choosing their own direction thus leading to conditional
> compilation anyways.

I don't think just choosing implementors' own direction leads to
conditional compilation, but perhaps the difference of these views is
not main point in this discussion.  (So let's go ahead)

> 1) Leave it as you currently do (KAME does this).  I suspect everybody
> will choose their own way to make this usable.  If you are lucky there
> are not so many implementations that this isn't a problem.  Presonally
> I prefer conditional compilation based on the c standard rev over that
> based on the OS/stack flavor.

> 2) Use a pre c99 length 1 array (2292, Solaris, and USAGI do this).
> Realistically this is most likely to be implemented uniformly.  Its in
> 2292 so you should need strong reason to change it.  It is a little bit
> gross, but I don't think this is strong enough reason to break existing
> applications.

> 3) Use a FAM.  Use a 2+ year old c standard to specify an emerging
> API.  Philosphically this seems like the cleanest thing to do.

> 4) Use a combination of 2 & 3.  People can then use sizeof() as a way
> to determine how to allocate.  This is probably too complex to be used
> correctly by the masses and has the maintenace headaches of conditional
> compilation.

> I hope you will consider 2 or 3.

I didn't remember the reason why the member name was removed, so I
found it from the web.  You'll get the answer from the discussion
starting at the following URL:

http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html

According to the discussion, there seemed to be a clear consensus on
the removal (though this may not be regarded as a "strong reason").

Another thought: most user applications are expected to use
inet6_rth_xxx functions, instead of directly getting access to the
address part following the rthdr[0] structure.  Thus, either 1 nor 2
affects the typical user applications.  In some limited usage, such as
in kernel source, developers may want to choose their own way for
their convenience like ip6r0_addr[0].  However, we do not expect
portability in such limited environments, and I don't care about the
possible differences as long as it is hidden from user applications.

Having thought all of this, I still prefer the current 2292bis
definition.  (I personally could live with (2), but I prefer (1) over
(2) because we had a clear consensus on this.)

Can we agree on this, or do we need more discussion?

					JINMEI, Tatuya

---

From: Michael Hunter <[email-masked]>
Date: Wed, 25 Sep 2002 13:52:58 -0700

On Wed, 25 Sep 2002 22:00:56 +0900
JINMEI Tatuya / 神明達哉 <[email-masked]> wrote:
[...]
> the removal (though this may not be regarded as a "strong reason").

poster +
1 FAM preferred (removal next)
1 removal
1 its nice to have the array member
1 but I don't need the array member

I'm not sure what the overall membership of the interested parties was
but that doesn't sound like a large sample.

[...]
> affects the typical user applications.  

So why create incompatibilities with 2292 if you expect the feature
being broken to be used less in the future?  Whats the gain?

[...]
> Can we agree on this, or do we need more discussion?

I'm not buying the reasons I've seen so far for this incompatibility
with 2292.  I believe you need a reason other then "its ugly" to break
users code.

			mph

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Sep 2002 17:33:30 -0400

Let me see if I can remember the reasons I had
for removing the array.

1.  It would make the structure declaration similar to
the rest of extension headers.

2.  2292 and early 2292bis defined the array of size 1,
but it is valid to have a routing header with 0 segleft
and no IPv6 addresses. This corner case caused a bunch
of small problems for implementations that the new
definition avoided.

3.  Not all compilers understood flexible array member.
It also caused some confusion from users expecting sizeof()
to be different.

Additionally 2292bis has some other incompatibilities with 2292
this one being the least of the problems.  So that argument
doesn't fly.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 Sep 2002 13:03:53 +0900

>>>>> On Wed, 25 Sep 2002 13:52:58 -0700, 

> 1 but I don't need the array member

I could not tell who is who, so please let me be more concrete.

Vlad proposed to remove the member.
Francis agreed.
Tim agreed.
Erik first said the member was useful but then followed the
suggestion anyway.

(correct me if I'm wrong or miss someone.)

> but that doesn't sound like a large sample.

I'm not sure, either.  But API discussions are often like this.

> being broken to be used less in the future?  Whats the gain?

See Vlad's response.

> with 2292.  I believe you need a reason other then "its ugly" to break

I think the fact that we can have a routing header without any address
is a reasonable reason to remove ip6r0_addr[1] other than the style
issue (I guess that's the main reason why Erik added this change in
the 01 version of the draft).

Additionally, I suspect the removal actually breaks user code so much.
As I said before, user applications are usually expected to use
library functions for source routing and to not use the ip6r0_addr
member directly.  In fact, we, the KAME project, do not use the member
name in about 80 IPv6 applications we provide.  I also searched on
recent source code of FreeBSD and NetBSD (which have not supported
2292bis yet).  The only occurrence of ip6r0_addr other than in user
applications is in tcpdump, where no compatibility issue exists since
tcpdump uses its own header definitions.

Of course, I'm not saying the above is all of IPv6 applications, but
it should definitely covers a noticeable part of them, particularly in
the open source area where the compatibility issue is severer.

As Vlad said, 2292bis has already broken compatibility to the old
RFC2292 in many points (I admit this is a weird thing, but this is the
fact and was decided by this community).  And the examples above show
that this is a relatively minor issue among them in the real world.
Thus, I would prefer the new definition in 2292bis because of the
reasons Vlad raised.

I understand your frustration, but I'm afraid no one can "win" in this
kind of discussion.  We just need a compromise, and I hope you kindly
allow us to go with the current definition.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 Sep 2002 14:04:57 +0900

>>>>> On Thu, 26 Sep 2002 13:03:53 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> 2292bis yet).  The only occurrence of ip6r0_addr other than in user
                                                   ^^^^^^^^^^"other
than" should be removed.  sorry for the confusing wording.

					JINMEI, Tatuya