Date: Sat, 05 Feb 2011 17:42:45 -0800 From: Julian Elischer <julian@freebsd.org> To: Ivo Vachkov <ivo.vachkov@gmail.com> Cc: FreeBSD Net <net@freebsd.org> Subject: Re: divert rewrite Message-ID: <4D4DFC95.9010804@freebsd.org> In-Reply-To: <AANLkTimtDegcGjzXatEOHjQR9GM_hD29ZiKnkT-zG1_S@mail.gmail.com> References: <4D4DCD1E.1050906@freebsd.org> <AANLkTimtDegcGjzXatEOHjQR9GM_hD29ZiKnkT-zG1_S@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/5/11 4:09 PM, Ivo Vachkov wrote: > Hello, > > How can I help? if you have ipv6 connectivity and experience, I have no experience or connectivity, with it so I'll be coding blind and will need a tester. If you have an application for IPV6 testing that would be even better. Divert is often used for NAT but that doesn't seem very useful for IPv6 and natd doesn't support it anyhow. > /ipv > > On Sun, Feb 6, 2011 at 12:20 AM, 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?4D4DFC95.9010804>