divert rewrite

[Ronald Klop]

On Sun, 06 Feb 2011 02:42:45 +0100, Julian Elischer <julian at freebsd.org>  
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<julian at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>
>>
>>
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"