As 2.2.0 is nearing release, I''ve begun to think about what I''ll do for 2.3 and I think that it is time for Shorewall to add support for IPV6. Because of parsing ambiguities, the need to maintain upward compatibility with both Shorewall and 6Wall, and different available functionality in IPV4 and IPV6 Netfilter, I believe that it is going to be necessary for some files to be spit into two (there will be separate IPV4 and IPV6 rules files for example). The questions that I have are: a) Should the IPV4 and IPV6 configurations be in the same directory (I think so) or should there be separate IPV4 and IPV6 configuration directories. b) Should there be a single POLICY for traffic between each ordered pair of zones or should there be separate IPV4 and IPV6 policies? c) If I can resolve parsing and other issues, should I always attempt to have a single file rather than two (I think so)? Any other thoughts are welcome. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> As 2.2.0 is nearing release, I''ve begun to think about what I''ll do for > 2.3 and I think that it is time for Shorewall to add support for IPV6. > > Because of parsing ambiguities, the need to maintain upward > compatibility with both Shorewall and 6Wall, and different available > functionality in IPV4 and IPV6 Netfilter, I believe that it is going to > be necessary for some files to be spit into two (there will be separate > IPV4 and IPV6 rules files for example). The questions that I have are: > > a) Should the IPV4 and IPV6 configurations be in the same directory (I > think so) or should there be separate IPV4 and IPV6 configuration > directories. > > b) Should there be a single POLICY for traffic between each ordered pair > of zones or should there be separate IPV4 and IPV6 policies? > > c) If I can resolve parsing and other issues, should I always attempt to > have a single file rather than two (I think so)? > > Any other thoughts are welcome.imho under most usual cicumstances the v4 and v6 rules are the same. so it''d be useful if all config files apply to both v4 and v6. and if there is any differences then there can be v4 and v6 specifi files which are just the difference between the "general" conf files. eg: rules rules.ipv4 rules.ipv6 and the lat two are empty by default. the intresting question what to do with params file where eg the ip address are defined? and how to substitute this params in this case in eg: rules?:-((( -- Levente "Si vis pacem para bellum!"
On Wed, 2005-01-05 at 20:54 +0100, Farkas Levente wrote:> Tom Eastep wrote: > > As 2.2.0 is nearing release, I''ve begun to think about what I''ll do for > > 2.3 and I think that it is time for Shorewall to add support for IPV6. > > > > Because of parsing ambiguities, the need to maintain upward > > compatibility with both Shorewall and 6Wall, and different available > > functionality in IPV4 and IPV6 Netfilter, I believe that it is going to > > be necessary for some files to be spit into two (there will be separate > > IPV4 and IPV6 rules files for example). The questions that I have are: > > > > a) Should the IPV4 and IPV6 configurations be in the same directory (I > > think so) or should there be separate IPV4 and IPV6 configuration > > directories. > > > > b) Should there be a single POLICY for traffic between each ordered pair > > of zones or should there be separate IPV4 and IPV6 policies? > > > > c) If I can resolve parsing and other issues, should I always attempt to > > have a single file rather than two (I think so)? > > > > Any other thoughts are welcome. > > imho under most usual cicumstances the v4 and v6 rules are the same. so > it''d be useful if all config files apply to both v4 and v6. and if there > is any differences then there can be v4 and v6 specifi files which are > just the difference between the "general" conf files. eg: > rules > rules.ipv4 > rules.ipv6 > and the lat two are empty by default.So you think it is okay for users to have to move all of their DNAT and REDIRECT rules from ''rules'' to ''rules.ipv4'' as part of the upgrade (given that there is no NAT support for IPV6)? What to do with other rules that contain IPV4 addresses? Create equivalent IPV6 rules?> the intresting question what to do > with params file where eg the ip address are defined? and how to > substitute this params in this case in eg: rules?:-((( >It''s worse than that because I used ":" so freely as a separator and IPV6 addresses also use ":" that way. That''s where the parsing ambiguities that I mention above come it. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> On Wed, 2005-01-05 at 20:54 +0100, Farkas Levente wrote: > >>Tom Eastep wrote: >> >>>As 2.2.0 is nearing release, I''ve begun to think about what I''ll do for >>>2.3 and I think that it is time for Shorewall to add support for IPV6. >>> >>>Because of parsing ambiguities, the need to maintain upward >>>compatibility with both Shorewall and 6Wall, and different available >>>functionality in IPV4 and IPV6 Netfilter, I believe that it is going to >>>be necessary for some files to be spit into two (there will be separate >>>IPV4 and IPV6 rules files for example). The questions that I have are: >>> >>>a) Should the IPV4 and IPV6 configurations be in the same directory (I >>>think so) or should there be separate IPV4 and IPV6 configuration >>>directories. >>> >>>b) Should there be a single POLICY for traffic between each ordered pair >>>of zones or should there be separate IPV4 and IPV6 policies? >>> >>>c) If I can resolve parsing and other issues, should I always attempt to >>>have a single file rather than two (I think so)? >>> >>>Any other thoughts are welcome. >> >>imho under most usual cicumstances the v4 and v6 rules are the same. so >>it''d be useful if all config files apply to both v4 and v6. and if there >>is any differences then there can be v4 and v6 specifi files which are >>just the difference between the "general" conf files. eg: >>rules >>rules.ipv4 >>rules.ipv6 >>and the lat two are empty by default. > > > So you think it is okay for users to have to move all of their DNAT and > REDIRECT rules from ''rules'' to ''rules.ipv4'' as part of the upgrade > (given that there is no NAT support for IPV6)? > > What to do with other rules that contain IPV4 addresses? Create > equivalent IPV6 rules?the truth is i don''t know!:-) but i prefere to keep only one rules (masq etc) file in most cases and somehow manage to define ip parameters for both v4 and v6 paralell. in this case the rules files are the same (if there is no difference between the v4 and v6 rules) the rules.ipv{4,6} are empty and the params file is the real questions (and the only difference)! may be there can be two params.ipv{4,6} and both must define the same param names.>> the intresting question what to do >>with params file where eg the ip address are defined? and how to >>substitute this params in this case in eg: rules?:-((( >> > > > It''s worse than that because I used ":" so freely as a separator and > IPV6 addresses also use ":" that way. That''s where the parsing > ambiguities that I mention above come it.here comes the worst part:-((( -- Levente "Si vis pacem para bellum!"
Tom Eastep wrote:> ... > Any other thoughts are welcome.1. Tom is a legend. 2. Keep up the good work, Tom! :-) -- Paul <http://paulgear.webhop.net> -- He who asks is a fool for five minutes, but he who does not ask remains a fool forever. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050106/72b295de/signature.bin
Tom Eastep wrote:> As 2.2.0 is nearing release, I''ve begun to think about what I''ll do for > 2.3 and I think that it is time for Shorewall to add support for IPV6. > > Because of parsing ambiguities, the need to maintain upward > compatibility with both Shorewall and 6Wall, and different available > functionality in IPV4 and IPV6 Netfilter, I believe that it is going to > be necessary for some files to be spit into two (there will be separate > IPV4 and IPV6 rules files for example). The questions that I have are: > > a) Should the IPV4 and IPV6 configurations be in the same directory (I > think so) or should there be separate IPV4 and IPV6 configuration > directories. > > b) Should there be a single POLICY for traffic between each ordered pair > of zones or should there be separate IPV4 and IPV6 policies? > > c) If I can resolve parsing and other issues, should I always attempt to > have a single file rather than two (I think so)?My general approach to any future IPv6 upgrade is that i see IPv6 as a different addressing scheme, but it shouldn''t make my network work much differently. I''ll still have the same zones and the same rules between them, just different addresses in them. Therefore, i think IPv6 should be supported in as similar a manner as possible to IPv4. Thus i think it we should use the same zones, with the same policies and rules, in the same files, as far as practical. I think the most important thing to keep in mind when extending/changing shorewall is its motto: "Making iptables easy". (Perhaps we need to modify that slightly now and call it "Making ip(6)?tables easy"? :-) Shorewall''s strength is that it lets me throw the nuts & bolts in at the beginning, and forget about them after that and concentrate on high-level policies and rules - if you keep that as the goal, then most decisions should make themselves. I''m not aware of any consumer-grade ISPs in Australia that support IPv6, so i''m not anticipating needing to use IPv6 in the medium-term, nonetheless it will be interesting to see how it pans out in shorewall. As an aside, can anyone point me to some doco about the IPv6 equivalents of NAT and ICMP REJECTs? I''m struggling to understand how life can go on without IP masquerading. :-) -- Paul <http://paulgear.webhop.net> -- If at first you don''t succeed, try, try again. If at first you do succeed, carefully check your success metrics for accuracy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050106/897e652a/signature.bin
On Thu, 2005-01-06 at 10:48 -0200, Eduardo Ferreira wrote:> Tom, may be we should have a intermediate version where all these ":" > separators go away as a preparatory for ipv6. > > just my 2?...The problem is that many people don''t read release notes -- they install version 1.2 of some software package then three years later upgrade straight to version 27.3 without reading a word. While one can argue that this is their problem, not ours, it increases our support load none-the-less. Also, IPV6 adoption is not very rapid -- making people change their configurations when it gains them nothing is bad practice. We went through some of these discussions when Eric was creating 6wall; his original idea was to modify Shorewall for IPV6 but I talked him out of it (wasn''t too hard after he''d tried it :-) )> > And above all, what is the schedule to IPV6? >I''ll start work on it after 2.2.0 is released (probably next month). I''ve ordered a couple of books about IPV6 which I will need to digest before I do anything with code. I would expect final release to be about this time next year. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, 2005-01-06 at 19:11 +1000, Paul Gear wrote:> > My general approach to any future IPv6 upgrade is that i see IPv6 as a > different addressing scheme, but it shouldn''t make my network work much > differently. I''ll still have the same zones and the same rules between > them, just different addresses in them. Therefore, i think IPv6 should > be supported in as similar a manner as possible to IPv4. Thus i think > it we should use the same zones, with the same policies and rules, in > the same files, as far as practical.Possibly this isn''t as hard as I''m trying to make it. If I look at the rules file, for example, the SOURCE and DEST columns are the only ones that are problematic. If we allow both ":" and "/" as separators before the IP address *and require the use of "/" if the address is IPV6* then I believe we might be able to keep existing rules.> > As an aside, can anyone point me to some doco about the IPv6 equivalents > of NAT and ICMP REJECTs? I''m struggling to understand how life can go > on without IP masquerading. :-)I''ll let you know after I read the two books I referred to in my previous post :-). Note that there is an IPV6 REJECT target available in Patch-o-matic and I assume that will be part of the kernel.org distributions before I release the Shorewall IPV6 code (it''s in iptables 1.2.11 so it should be in the kernel before too long -- FLW). REJECT options: --reject-with type drop input packet and send back a reply packet according to type: Valid reject types: icmp6-no-route ICMPv6 no route no-route alias icmp6-adm-prohibited ICMPv6 administratively prohibited adm-prohibited alias icmp6-addr-unreachable ICMPv6 address unreachable addr-unreach alias icmp6-port-unreachable ICMPv6 port unreachable port-unreach alias tcp-reset TCP RST packet tcp-reset alias I think that there was some NAT code floating around as well but it may have gotten squashed. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, 2005-01-06 at 07:58 -0800, Tom Eastep wrote:> On Thu, 2005-01-06 at 19:11 +1000, Paul Gear wrote: > > > > > My general approach to any future IPv6 upgrade is that i see IPv6 as a > > different addressing scheme, but it shouldn''t make my network work much > > differently. I''ll still have the same zones and the same rules between > > them, just different addresses in them. Therefore, i think IPv6 should > > be supported in as similar a manner as possible to IPv4. Thus i think > > it we should use the same zones, with the same policies and rules, in > > the same files, as far as practical. > > Possibly this isn''t as hard as I''m trying to make it. If I look at the > rules file, for example, the SOURCE and DEST columns are the only ones > that are problematic. If we allow both ":" and "/" as separators before > the IP address *and require the use of "/" if the address is IPV6* then > I believe we might be able to keep existing rules.I shouldn''t try to do design before my first morning coffee. Using "/" is awkward because it appears in CIDR notation. But another separator, such as ";" would work. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, 2005-01-06 at 14:45 -0200, Eduardo Ferreira wrote:> > Tom wrote on 06/01/2005 14:31:06: > > > On Thu, 2005-01-06 at 07:58 -0800, Tom Eastep wrote: > > > On Thu, 2005-01-06 at 19:11 +1000, Paul Gear wrote: > > > > > > > > > > > I shouldn''t try to do design before my first morning coffee. Using > "/" > > is awkward because it appears in CIDR notation. But another > separator, > > such as ";" would work. > > > > -Tom > Could I humbly suggest using "=" as the separator? I think a rule > like > > ACCEPT loc=192.168.0.1 net tcp 3133 > > is better to read then > > ACCEPT loc;192.168.0.1 net tcp 3133 > > is it not?Actually, I prefer ";". In Shorewall, "=" has its usual Shell meaning (assignment). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> On Thu, 2005-01-06 at 14:45 -0200, Eduardo Ferreira wrote: >> >> Tom wrote on 06/01/2005 14:31:06: >> >> > On Thu, 2005-01-06 at 07:58 -0800, Tom Eastep wrote: >> > > On Thu, 2005-01-06 at 19:11 +1000, Paul Gear wrote: >> > > >> > > > >> > >> > I shouldn''t try to do design before my first morning coffee. Using >> "/" >> > is awkward because it appears in CIDR notation. But another >> separator, >> > such as ";" would work. >> > >> > -Tom >> Could I humbly suggest using "=" as the separator? I think a rule >> like >> >> ACCEPT loc=192.168.0.1 net tcp 3133 >> >> is better to read then >> >> ACCEPT loc;192.168.0.1 net tcp 3133 >> >> is it not? > > Actually, I prefer ";". In Shorewall, "=" has its usual Shell meaning > (assignment).I''m afraid I don''t like the ";" here because it''s usually a separator for a list of things. What about "@"? Like ACCEPT loc@192.168.0.1 net tcp 3133 I''d prefer it. Simon
Simon Matter wrote:>>On Thu, 2005-01-06 at 14:45 -0200, Eduardo Ferreira wrote: >> >>>Tom wrote on 06/01/2005 14:31:06: >>> >>> >>>>On Thu, 2005-01-06 at 07:58 -0800, Tom Eastep wrote: >>>> >>>>>On Thu, 2005-01-06 at 19:11 +1000, Paul Gear wrote: >>>>> >>>>> >>>>I shouldn''t try to do design before my first morning coffee. Using >>> >>>"/" >>> >>>>is awkward because it appears in CIDR notation. But another >>> >>>separator, >>> >>>>such as ";" would work. >>>> >>>>-Tom >>> >>>Could I humbly suggest using "=" as the separator? I think a rule >>>like >>> >>>ACCEPT loc=192.168.0.1 net tcp 3133 >>> >>>is better to read then >>> >>>ACCEPT loc;192.168.0.1 net tcp 3133 >>> >>>is it not? >> >>Actually, I prefer ";". In Shorewall, "=" has its usual Shell meaning >>(assignment). > > > I''m afraid I don''t like the ";" here because it''s usually a separator for > a list of things. What about "@"? Like > > ACCEPT loc@192.168.0.1 net tcp 3133 > > I''d prefer it. >Given the current syntax, there are cases where we need to know where the END of the address or address-list is. How about if we require IPV6 addresses appearing in ":"-separated constructs to be enclosed in [..] or <..>? ACCEPT loc:<::ffff:206.124.146.177> net tcp 25 -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> ... >>As an aside, can anyone point me to some doco about the IPv6 equivalents >>of NAT and ICMP REJECTs? I''m struggling to understand how life can go >>on without IP masquerading. :-) > > > I''ll let you know after I read the two books I referred to in my > previous post :-). Note that there is an IPV6 REJECT target available in > Patch-o-matic and I assume that will be part of the kernel.org > distributions before I release the Shorewall IPV6 code (it''s in iptables > 1.2.11 so it should be in the kernel before too long -- FLW). > ... > I think that there was some NAT code floating around as well but it may > have gotten squashed.So these are netfilter limitations, not IPv6 limitations? -- Paul <http://paulgear.webhop.net> -- Did you know? Using accepted quoting conventions makes your email easier to understand. Learn how at <http://www.netmeister.org/news/learn2quote.html>. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050107/8489bbb8/signature.bin
Tom Eastep wrote:> ... >>>>Could I humbly suggest using "=" as the separator? I think a rule >>>>like >>>>... > Given the current syntax, there are cases where we need to know where > the END of the address or address-list is. How about if we require IPV6 > addresses appearing in ":"-separated constructs to be enclosed in [..] > or <..>? > > ACCEPT loc:<::ffff:206.124.146.177> net tcp 25In light of discussions like this, it seems to me like in the long term it would be more suitable to change the : separator. It''s only going to gain in significance once IPv6 gains prevalence. -- Paul <http://paulgear.webhop.net> -- Did you know? Most email-borne viruses use a false sender address. Therefore you cannot track down the sender using that address. Instead, keep your virus scanning software up-to-date and just delete any suspicious emails you receive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050107/f262ba7d/signature.bin
Paul Gear wrote:> > > So these are netfilter limitations, not IPv6 limitations? >Yes. However, I gather that there''s resistance to the idea of NAT, given the huge address space and the portability of addresses (IPV6 Mobile). Note that I''m still very green myself when it comes to IPV6. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> ... >>Tom, may be we should have a intermediate version where all these ":" >>separators go away as a preparatory for ipv6. >>... > The problem is that many people don''t read release notes -- they install > version 1.2 of some software package then three years later upgrade > straight to version 27.3 without reading a word. While one can argue > that this is their problem, not ours, it increases our support load > none-the-less. > > Also, IPV6 adoption is not very rapid -- making people change their > configurations when it gains them nothing is bad practice.There is going to be a lot of pain in the upgrade to IPv6 anyway - i think preparing people by getting them used to the fact that colon can''t be a separator any more is a "good thing". I would view this something like the "hair principle": the amount of hairy code in any given software system is constant - it''s just a matter of whether it''s spread out or concentrated in one place. Thus my networking corollary to this principle reads: the amount of pain in any network addressing change is constant - it''s just a matter of whether it''s spread out or concentrated in one place. Personally, i prefer spreading the hairy code and spreading the pain - it makes the individual hairballs and stabs of pain easier to understand/deal with. :-) -- Paul <http://paulgear.webhop.net> -- Did you know? Using accepted quoting conventions makes your email easier to understand. Learn how at <http://www.netmeister.org/news/learn2quote.html>. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050107/70bc4700/signature.bin
Paul Gear wrote:> > There is going to be a lot of pain in the upgrade to IPv6 anyway - i > think preparing people by getting them used to the fact that colon can''t > be a separator any more is a "good thing". > >Please try a little exercise -- open up a copy of a complex rules file and experiment with different separators (other than ":") -- find any you like? I haven''t :-( Note that we only have to change the separator in columns that can potentially contain an address. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Could a + work? I am thinking of a feature plus an option or restriction. Maybe a - would work, but it is used in ranges so it might make parsing too hard. ACCEPT $FW loc:192.168.168.3 all all ACCEPT $FW loc+192.168.168.3 all all How hard is it for your parser to be changed from : to another character? Is the separator character a parameter? Maybe extracting it out would be the first step in trying alternates. -- Steve Herber herber@thing.com work: 206-221-7262 Security Engineer, UW Medicine, IT Services home: 425-454-2399 On Thu, 6 Jan 2005, Tom Eastep wrote:> Paul Gear wrote: > > > > There is going to be a lot of pain in the upgrade to IPv6 anyway - i > > think preparing people by getting them used to the fact that colon can''t > > be a separator any more is a "good thing". > > > > > > Please try a little exercise -- open up a copy of a complex rules file > and experiment with different separators (other than ":") -- find any > you like? I haven''t :-( > > Note that we only have to change the separator in columns that can > potentially contain an address. > > -Tom >
Steve Herber wrote:> Could a + work? I am thinking of a feature plus an option or restriction. > Maybe a - would work, but it is used in ranges so it might make parsing > too hard. > > ACCEPT $FW loc:192.168.168.3 all all > > ACCEPT $FW loc+192.168.168.3 all all > > > How hard is it for your parser to be changed from : to another character? > Is the separator character a parameter? Maybe extracting it out would be > the first step in trying alternates. > >Unfortunately, the parser does pattern-matching then extracts the pieces using ${xxx#...} and ${...%...} variable expansion. So it requires several changes for each column for each file :-( Parameterizing the separator would be a tedious exercise in shell programming. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote: > Please try a little exercise -- open up a copy of a complex rules file > and experiment with different separators (other than ":") -- find any > you like? I haven''t :-( Good point - your suggestion about brackets seems reasonable. The only thing i would suggest is that eventually all addresses require the same treatment, i.e. IPv4 would eventually come under the same conventions.> ... > Parameterizing the separator would be a tedious exercise in shell > programming.Indeed. <g> -- Paul <http://paulgear.webhop.net> -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard <http://www.gnupg.org> and Enigmail <http://enigmail.mozdev.org> so you can be sure it comes from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050107/0a1d588b/signature.bin
Paul Gear wrote:> Tom Eastep wrote: >> Please try a little exercise -- open up a copy of a complex rules file >> and experiment with different separators (other than ":") -- find any >> you like? I haven''t :-( > > Good point - your suggestion about brackets seems reasonable. The only > thing i would suggest is that eventually all addresses require the same > treatment, i.e. IPv4 would eventually come under the same conventions. >That''s the way I''m leaning... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, 2005-01-06 at 14:13 -0800, Tom Eastep wrote:> > I''m afraid I don''t like the ";" here because it''s usually a separator for > > a list of things. What about "@"? Like > > > > ACCEPT loc@192.168.0.1 net tcp 3133 > > > > I''d prefer it. > > > > Given the current syntax, there are cases where we need to know where > the END of the address or address-list is. How about if we require IPV6 > addresses appearing in ":"-separated constructs to be enclosed in [..] > or <..>? > > ACCEPT loc:<::ffff:206.124.146.177> net tcp 25 >Looks good to me: please note that those !@#$% V6 addresses are so long that one normally will want to use some kind of variable so there is no need to type the address a number of times. In actual fact I was wondering whether we need some support for the structure in addresses to make things manageble (e.g. prefix a.b.c.d/48, local network part/16 and address/64). This would allow for easy change of prefix (or having more then one prefix), while the local network part could easily map to zones etc. kind regards, Louis -- Louis Lagendijk <louis@lagendijk.xs4all.nl> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050108/fbcd4f5a/attachment.bin
Tom:>a) Should the IPV4 and IPV6 configurations be in the same directoryYes. If you really want to give people flexibility (always good to duck the issue), define a "IPV6_DIR" variable that has an initial value of "." and tell people to put their IPV6 files under that directory. They could define the variable to be "ipv6" and thus all their v6 files would be under /etc/shorewall/ipv6, or they could define it as "/etc/foo", in which case all their v6 files would be under /etc/foo"; but, the default would be "." (under /etc/shorewall). Tom:>c) If I can resolve parsing and other issues, should I always attempt to >have a single file rather than two (I think so)?Yes. Paul said:>My general approach to any future IPv6 upgrade is that i see IPv6 as a >different addressing scheme, but it shouldn''t make my network work much >differently. I''ll still have the same zones and the same rules between >them, just different addresses in them. Therefore, i think IPv6 should >be supported in as similar a manner as possible to IPv4. Thus i think >it we should use the same zones, with the same policies and rules, in >the same files, as far as practical.I agree with that. If people need special rules for V4 or V6, we have two choices: 1) Use separate files. pro: easy to parse con: harder to edit (rules spread among files) 2) Use a prefix on the lines in the current file, e.g. stick "V4" or "V6" in front of lines that don''t apply to both protocols. pro: harder to parse, a bit ugly to look at con: easier to maintain (all rules in one file) I''m liking the prefix concept, with a transition phase where shorewall "assumes" (with a warning) a V4 prefix in front of things that don''t apply to V6. After a few releases, remove the assumption and change the warning to an error, requiring people to use the correct prefixes. Tom:>b) Should there be a single POLICY for traffic between each ordered pair >of zones or should there be separate IPV4 and IPV6 policies?Start with one policy file. Use prefixes if people need to split it up. Tom:>So you think it is okay for users to have to move all of their DNAT and >REDIRECT rules from ''rules'' to ''rules.ipv4'' as part of the upgrade >(given that there is no NAT support for IPV6)?No, shorewall should have a transitional phase where it warns people about things that don''t apply to V4 or V6. (See my comment on prefixes, above.) -- -IAN! Ian! D. Allen Ottawa, Ontario, Canada EMail: idallen@idallen.ca WWW: http://www.idallen.com/ College professor (Linux) via: http://teaching.idallen.com/ Support free and open public digital rights: http://eff.org/