ip6tables roadmap

[Kis-Szabo Andras]

Brad Chapman ...................................... (2001. december 05.)

 Hi!

> > > > - common codebase
> > > 	Is this userspace or kernel?
> > both. (But Harald already started it :( )
> 	He did? How? He hasn't said anything to that effect.....
We must choose an architecture for the new version of the iptables.
It will contain the kernel stuffs, 'nf' command, libraries, modules, userspace
stuffs. (libiptc and the old iptables command - well, they may be will lost in
space ...)
If everybody start start to implement something, we will get a big mess at the
end. We decided that we will use a 'common codebase' for ipv4 and ipv6, too.
Harald (as I know) started something - I want to wait the result of his work.

> 	COOL! And does this have anything to do with Jay Schulist's nfnetlink?
Yesterday I started the interpretation of Jay's code. The conntrack6 code is
the future, but the nfnetlink patch can be ported. BUT: not in the old style!

So, I think that the
 - connection tracking
 - common codebase
 - nfnetlink / nf command
 is the future. 
 
But there are some very beautiful extension header! 
 - IPv6 main header: we are using some basic match. Future requirements:
     . traffic class (match/mangle)
     . flow label (match)
     . next header (match)
     . hop limit (match/mangle)
 - Hop-by-Hop 
     . next header, length, options ...
 - Destination options
     . 
 - Routing header
     . next header, length
     . routing type (match)
     . segments left (match)
     . reserved-field checking (must be 0) (match/mangle) [covert channel]
     . there's a rolling list of the internal addressess (end pointer: segments
       left)
 - Fragment hdr
     . reserved fields (match/mangle)
     . next header (match)
     . idetification
 - AH/ESP (can be delivered from IPv4/IPSec)
 - ext hdr options: Pad1 and PadN (in any hdr!)
 - general header match (exists os not - bitmask)
 - IPV6-ICMP It's a very complicated protocol...
    . error and general messages 
    . management messages
      . router solicitation
      . router advertisement
      . neighbor solicitation
      . neighbor advertisement
      . redirect
      . options (in any message)
        . source link-layer address
	. target link-layer address
	. prefix information
	. redirected hdr
	. MTU
      . DOCUMENTATION: usage of these messages!!!
( http://www.sch.bme.hu/~kisza/ipv6.txt )      
( http://www.sch.bme.hu/~kisza/tahi.txt - some example packet (very raw!))      
  So, I think that we have enough work till the new API :) 
 
regards,

	kisza

-- 
    Kis-Szabo Andras            BUTE - Schonherz Dormitory
---------------------------/  Favourite tools: Zorp, NetFilter
      kisza@sch.bme.hu    /---Member of the BUTE-MIS-SEARCHlab--->>>>>.Info