Date: Sun, 06 Feb 2011 13:23:56 +0100 From: "Ronald Klop" <ronald-freebsd8@klop.yi.org> To: "FreeBSD Net" <net@freebsd.org>, "Julian Elischer" <julian@freebsd.org> Subject: Re: divert rewrite Message-ID: <op.vqhd16a28527sy@pinky> In-Reply-To: <4D4DCD1E.1050906@freebsd.org> References: <4D4DCD1E.1050906@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
You could make it a google summer of code project? Ronald. On Sat, 05 Feb 2011 23:20:14 +0100, Julian Elischer <julian@freebsd.org> wrote: > for some time now it has been apparent that the divert socket protocol > was a little too heavily tied to IPv4. > > With IPv6 coming along now, it seems that we should look at how to > extend it. > > I see a couple of possible ways to do this: > > --- the first way: ---- > > One would be to add an IPV6 version of divert sockets, possibly from the > same base code. The ipfw code to call it would pass on whether it was an > ipv4 or ipv6 packet that is passed out (or it can just look) > and the divert packet would pass it to the correct socket if it was > openned. > > From an application point of view, this means you would have to open an > ipv4 divert socket and an ipv6 divert socket. > > if you didn't have the right one open.. you would just never see the > packet. > > Since applications that use divert would probably have to be rewritten > to cope with ipv6 anyhwo this seems to be an > ok solution/cost. > > Any app that was not updated would continue to run with ipv4 but would > never see IPV6 packets even if diverted. > > ------ another way ---- > > Another way to do this would be to recode divert to be its own protocol > family with its own sockaddr type. > > that socket addr would include the family as now, but would have enough > room to support ipv4 and ipv6 addresses, as well as special fields that > are curently not available in divert or are just 'hacked' > (such as the fact that the name of the interface is hidden in the > 'sa_zero' bytes of the ipv4 socket address, and if you keep it and pass > it back you are effectively passing that information back too). > > In this scheme we would allow the socket address structure to have > enough fields to be able to encode some of the more intersting > packet layer information that is in the mbuf. > For example, the FIB, or somefo the other packet flags > or maybe even one or two of the common tags. > > I could see that some of these flags might be useful to a divert agent > that understood the protocol stack it was working with: > > #define M_PROTO1 0x00000010 /* protocol-specific */ > #define M_PROTO2 0x00000020 /* protocol-specific */ > #define M_PROTO3 0x00000040 /* protocol-specific */ > #define M_PROTO4 0x00000080 /* protocol-specific */ > #define M_PROTO5 0x00000100 /* protocol-specific */ > #define M_BCAST 0x00000200 /* send/received as link-level > broadcast */ > #define M_MCAST 0x00000400 /* send/received as link-level > multicast */ > #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ > > #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ > #define M_PROMISC 0x00020000 /* packet was not for us */ > #define M_PROTO6 0x00080000 /* protocol-specific */ > #define M_PROTO7 0x00100000 /* protocol-specific */ > #define M_PROTO8 0x00200000 /* protocol-specific */ > #define M_FLOWID 0x00400000 /* flowid is valid */ > > > If we really wanted to do more, we could also define an OOB format > that could be used with recvmsg() and sendmsg() that would be > extensible enough to really give a lot of information. > > This would be the least compatible, and to tell the truth, I'd be > tempted to leave the old ipv4 interface in place as an upgrade aid. > it could however handle all sorts of protocols, not just ipv4 and ipv6 > but possibly L2 packets etc. as well. > It may also be more work than I hope to do :-) > > ------ > > If anyone else has suggetions or man-power or would like to help.. > pipe up! > > > Julian > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.vqhd16a28527sy>