From owner-IPv6-jp@jp.freebsd.org  Fri Dec 17 01:20:51 1999
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id BAA33648;
	Fri, 17 Dec 1999 01:20:51 +0900 (JST)
	(envelope-from owner-IPv6-jp@jp.FreeBSD.org)
Received: from tortoise.jp.freebsd.org (root@tortoise.jp.FreeBSD.ORG [210.157.158.41])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id BAA33643
	for <IPv6-jp@jp.freebsd.org>; Fri, 17 Dec 1999 01:20:51 +0900 (JST)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from shuttle.wide.toshiba.co.jp (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by tortoise.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP/IPv6 id BAA12765
	for <IPv6-jp@jp.freebsd.org>; Fri, 17 Dec 1999 01:20:13 +0900 (JST)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from localhost ([3ffe:501:100f:13ff::e])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA11639;
	Fri, 17 Dec 1999 01:09:56 +0900 (JST)
Date: Fri, 17 Dec 1999 01:22:32 +0900
Message-ID: <y7v902ukg8n.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: snap-users@kame.net, 6bone-jp@wide.ad.jp, v6@wide.ad.jp,
        IPv6-jp@jp.freebsd.org
Cc: ipng@sunroof.eng.sun.com
User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 56
Reply-To: IPv6-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+990727
X-Sequence: IPv6-jp 405
Subject: [IPv6-jp 405] transition from RFC2292 to 2292bis
Errors-To: owner-IPv6-jp@jp.freebsd.org
Sender: owner-IPv6-jp@jp.freebsd.org
X-Originator: jinmei@isl.rdc.toshiba.co.jp

To KAME users, especially to those who develop applications on the
KAME kernel:
(I cc'ed this mail to the ipng ML for those who are intersted in
 implementing rfc2292bis, but I apologize in advance if it's too
 noisy.)

I've started implementing the new advanced API in KAME according to
<draft-ietf-ipngwg-rfc2292bis-01.txt>. Though the specification is
still an internet-draft (i.e. not an RFC yet), I believe we should
eventually move to the new API since it reflects recent changes and
operational experiences of IPv6.

However, one big problem of 2292bis is that it does not ensure
complete backward compatibility with RFC2292. For example, the
semantics of the IPV6_PKTINFO socket option is changed:

In RFC2292, the option takes an integer as an argument, and its value
is a switch of whether or not the kernel should pass the receiving
interface and the destination address of incoming packets to the
application.

In 2292bis, the option takes an in6_pktinfo strucutre as an argument,
and the structure specifies the source address and/or the outgoing
interface of outgoing packets. The option does not have any meaning
for incoming packets. If you need information of incoming packets, you
should use a separate option IPV6_RECVPKTINFO.

(Unfortunately) it doesn't seem (at least to me) very easy to support
both semantics in a single code base. Although we could introduce a
trick like `#ifdef COMPAT_RFC2292', the result would make the kernel
code very complicated and we would have hard time to maintain the
code.

So my question to developers is:
Basically I'd like to discard the old API and concentrate on the new
one, but it may force you to adjust your applications to 2292bis. Do
you mind if we take such an approach? If so, which part of the old API
do you want to remain? If there is some parts of the old API that
several people want to keep, I'll try to keep them. Otherwise, I'll
discard the entire old API if it conflicts with new one.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

p.s. FYI:
The semantics of (at least) the following socket options is changed in
2292bis:
IPV6_PKTINFO, IPV6_HOPLIMIT, IPV6_RTHDR, IPV6_HOPOPTS, and
IPV6_DSTOPTS.

If you use these options according to the semantics of RFC2292, you'll
have to adjust your code when we discard the old (RFC2292) behavior.
