From owner-freebsd-net  Tue Aug  1 19: 0: 7 2000
Delivered-To: freebsd-net@freebsd.org
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by hub.freebsd.org (Postfix) with SMTP id 2883837B5E5
	for <freebsd-net@freebsd.org>; Tue,  1 Aug 2000 19:00:03 -0700 (PDT)
	(envelope-from pingpan@research.bell-labs.com)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Aug  1 21:59:01 EDT 2000
Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.37.60])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA15865;
	Tue, 1 Aug 2000 21:58:58 -0400 (EDT)
Message-ID: <39877FCD.AC968B74@research.bell-labs.com>
Date: Tue, 01 Aug 2000 21:56:29 -0400
From: Ping Pan <pingpan@research.bell-labs.com>
Organization: Bell Labs, Lucent
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: itojun@iijlab.net
Cc: freebsd-net@freebsd.org
Subject: Re: Fwd: A new kernel extension to deal with IP option packets
References: <19654.965020987@coconut.itojun.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

itojun@iijlab.net wrote:
> 
> 
>         you want to look at RFC2292, and draft-ietf-ipngwg-2292bis.
>         RFC2292 specifies how you can manipulate IPv6 extension headers
>         (header chains between IP and TCP/UDP header, has similar role to
>         IPv4 options), using ancillary data stream.  it gives you much higher
>         flexibility and control, without additional address family
>         (i think we shouldn't define address family for this).
> 
> itojun
> 

Hello, Itojun,

I could not find you in IETF. So here is my response: after reading
through some of the FrreBSD kernel code on IPv6 and the RFC, it has the
same
problem as in IPv4. That is, the user needs to open a raw socket first
with a protocol family and a protocol type. Only then you may use
setsockopt() to receive the option that you want. This mechanism is
pretty much the same as in IPv4.

The problem that we are trying to solve is to intercept the IP packets
*only* base on their IP option types. The protocol type is irrelevant
here. I don't see this is solved in IPv6 RFC and drafts.

WRT the need of a new socket family, please recommend a better method to
solve the problem. 

Thanks!

- Ping Pan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message