>>>>> On Wed, 2 Oct 2002 14:10:35 -0700,
>>>>> Michael Hunter <[EMAIL PROTECTED]> said:
>> 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.
I admit the point. I should have raised applications that use a
routing header to be fair enough.
>> 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.
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.
> [...]
>> 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.
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 PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
