Subject: transition from RFC2292 to 2292bis

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 Dec 1999 01:22:32 +0900

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

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