Subject: Re: 2292bis ip6_rthdr0 flexible array member

From: Michael Hunter <[email-masked]>
Date: Wed, 2 Oct 2002 14:10:35 -0700

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

> >>>>> On Wed, 25 Sep 2002 13:52:58 -0700, 
> >>>>> Michael Hunter <[email-masked]> said:
[4 people's opinions about ip6r0_addr]
> (correct me if I'm wrong or miss someone.)

That is as I read it.

[...]
> > [...]
> >> 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.  
> 
> > So why create incompatibilities with 2292 if you expect the feature
> > being broken to be used less in the future?  Whats the gain?
> 
> See Vlad's response.

So the gain was:
1) it would make it more consistent with the rest of the API
2) it makes handling a corner case cleaner

I personally don't see these as a strong enough reason to break the
API.

I strongly disgree with Vlan'd comment that "Additionally 2292bis has
some other incompatibilities with 2292 this one being the least of the
problems.  So that argument doesn't fly."  Thats a slippery slope
leading you to completely abandoning backwards compatability.  You
should have strong technical reasons for each and every breakage of the
API independent of what else you have broken.

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

I think this is overstating your case.  This is the advanced API.  You
don't expect it to be used in many of you applications.  The real point
is that you don't use it in the less then 5 (ping, telnet, traceroute,
'sniffer') applictions that might need it.

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

Which is telling about the stability and widespread acceptance of this
API.  I think its very likely that one of the reasons they needed
private headers had to do with the variations of API between 2292 and
2292bis.

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

I agree on this point.  I'm tired.  I'm done.  This just isn't THAT
important.  Note my "frustration" and go on.

			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, 04 Oct 2002 02:54:53 +0900

>>>>> On Wed, 2 Oct 2002 14:10:35 -0700, 

> 'sniffer') applictions that might need it.

I admit the point.  I should have raised applications that use a
routing header to be fair enough.

> private headers had to do with the variations of API between 2292 and

Actually, tcpdump uses its own header definitions in many source
files.  Regarding IPv6 related ones, it (re)defines the IPv6 header,
the Hop-by-Hop options header, the Destination options header, the
Fragment header, and the Routing header.

> important.  Note my "frustration" and go on.

Okay, thanks for your kindness, and I'm sorry that I cannot be
productive in this discussion.  

					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: [email-masked]
Date: Fri, 04 Oct 2002 11:15:27 +0900

>Fragment header, and the Routing header.

	this is because tcpdump would like to decode IPv6 frames even when
	it runs on IPv4-only platforms.  the re-definition has nothing to do
	with the acceptance of RFC2292.

itojun