Date: Tue, 01 Aug 2000 21:56:29 -0400 From: Ping Pan <pingpan@research.bell-labs.com> To: itojun@iijlab.net Cc: freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets Message-ID: <39877FCD.AC968B74@research.bell-labs.com> References: <19654.965020987@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39877FCD.AC968B74>