From owner-freebsd-net@FreeBSD.ORG Sun Feb 6 12:40:28 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD2CD106566C; Sun, 6 Feb 2011 12:40:28 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep21.mx.upcmail.net (fep21.mx.upcmail.net [62.179.121.41]) by mx1.freebsd.org (Postfix) with ESMTP id 758FC8FC0A; Sun, 6 Feb 2011 12:40:23 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep14-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110206122456.BZUU1458.viefep14-int.chello.at@edge02.upcmail.net>; Sun, 6 Feb 2011 13:24:56 +0100 Received: from pinky ([213.46.23.80]) by edge02.upcmail.net with edge id 4cQu1g0301jgp3H02cQvdy; Sun, 06 Feb 2011 13:24:56 +0100 X-SourceIP: 213.46.23.80 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Ivo Vachkov" , "Julian Elischer" References: <4D4DCD1E.1050906@freebsd.org> <4D4DFC95.9010804@freebsd.org> Date: Sun, 06 Feb 2011 13:24:54 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4D4DFC95.9010804@freebsd.org> User-Agent: Opera Mail/11.01 (Win32) X-Cloudmark-Analysis: v=1.1 cv=CqMFsqQC4gx7bBgpmnW/wKYuJF/a5pXPeCAfngFtYkU= c=1 sm=0 a=bgpUlknNv7MA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=YMp63OpqK5xru0OnG0kA:9 a=x8VsXwHAeZm_HNgDiqcA:7 a=5UnPsBkWlQmSoYTC6P4Hrr4IkoYA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=rpATFeWpJGt08AtD:21 a=utuwudBhSSpfQb5V:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: FreeBSD Net Subject: Re: divert rewrite X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 12:40:28 -0000 On Sun, 06 Feb 2011 02:42:45 +0100, Julian Elischer wrote: > 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. Aren't there a lot of IPv6 tunnels available? Ronald. > >> /ipv >> >> On Sun, Feb 6, 2011 at 12:20 AM, Julian Elischer >> 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" >>> >> >> > > _______________________________________________ > 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"