Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 Support #39

Closed
raccettura opened this issue Mar 5, 2012 · 104 comments
Closed

IPv6 Support #39

raccettura opened this issue Mar 5, 2012 · 104 comments

Comments

@raccettura
Copy link

fail2ban doesn't appear to have any IPv6 support. With lots of networks (and thus hosts) trying to turn it on for World IPv6 Launch on June 6[1], this is a blocker.

http://www.worldipv6launch.org/

@yarikoptic
Copy link
Member

oopsy -- we didn't have official "issue" for that yet -- but we had some discussions before:

http://sourceforge.net/mailarchive/message.php?msg_id=27249783

and here is related bug in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470417

I believe that my suggested implementation/approach is here:
https://github.com/yarikoptic/fail2ban/tree/_tent/ipv6_via_aInfo
e.g. this commit gives a summary: 28b44d2

It would be great if discussion was revived to arrive to a logical agreement on format/implementation

@doits
Copy link

doits commented Mar 28, 2012

Really looking forward to see ipv6 supported by fail2ban. The only thing stopping me from activating ipv6 on my production server.

@Malbrouck
Copy link

I'm also willing to have IPv6 support. Fail2ban shall be able to detect IPv4 or v6 addresses and run ipfw/ip6fw accordingly. For names it should try to resolve names with A and AAAA records and ban each IP addresses (v4 or v6) which have been answered.

@yarikoptic
Copy link
Member

@Malbrouck could you review and comment on the suggested implementation which is pointed to in my comment above?

the problematic piece was to decide on how to provide a configuration with a good tradeoff between redundancy and flexibility

@Malbrouck
Copy link

Hi Yaroslav,

Unfortunately I'm not familiar with python language: I looked at your
commit 28b44d2 but I didn't understand what it's doing.

If you have something working which makes fail2ban IPv6 compatible then
try to merge it into the main branch, release it and watch how users
react...

Le 26/04/12 15:24, Yaroslav Halchenko a écrit :

@Malbrouck could you review and comment on the suggested implementation which is pointed to in my comment above?

the problematic piece was to decide on how to provide a configuration with a good tradeoff between redundancy and flexibility


Reply to this email directly or view it on GitHub:
#39 (comment)

@yarikoptic
Copy link
Member

I am trying to be less "experimental" on users -- the problem here that there seems to be no way to avoid modification of actions files and that is what people could have customized/extended with .local, so if we are to jump upon some solution -- it better be agreeed up and somewhat tested...

well -- I will try to get back to it some time to prep fully functional branch for people to give a shout and then we will see

@raccettura
Copy link
Author

Why not just an action and action6 for each entry in jail.conf and leave it up to actions in actions.d/ to have IPv6 flavors. If it's an IPv6 being jailed action6 is invoked, for IPv4 action is invoked.

Then it's just a matter of updating jail.conf to something like:
action = iptables-multiport[name=dovecot, port="pop3,pop3s,imap,imaps", protocol=tcp]
action6 = ip6tables-multiport[name=dovecot, port="pop3,pop3s,imap,imaps", protocol=tcp]

if no action6, nothing is done for IPv6 IP's. That would be backwards compatible and let folks handle IPv6 as needed.

Unifying everything into an action seems like a poor practice since it's possible an admin may want to use iptables for legacy reasons and ip6fw going forward using the IPv6 migration as a point to do it.

@yarikoptic
Copy link
Member

@raccettura as I have expressed myself in the original mail thread - I disliked 1. necessity to double every action file with the one specific for ipv6; 2. doubling interface commands between f2b client/server which would setup jails (e.g. actionstart and actionstart6 etc). Ideally the action backend should be smart enough to know how to handle both ipv4 and ipv6 addresses... may be (just a thought) we just need such a thin wrapper around iptables for that

@raccettura
Copy link
Author

I could see that as a default behavior, it would be very convenient if it were just a wrapper. But I could see the need for a perhaps optional action6, which if existed would cause the action backend to know it's a separate action for IPv6.

That would be pretty flexible and eloquent.

@Th4nat0s
Copy link

Ok, i had started a clean integration of my "poor" patch.

https://github.com/Th4nat0s/fail2ban

It's implement a iptable wrapper solution.

I still need to find a solution for hostnames wich are not ip's in logs, for now i had remove ip validation (evil evil i know)..

What about host resolved in logs ? .. it's another question (but for me a real problem when used with fail2ban).

I had to re-test it ... and i will submit my pull request.

Yaroslav, any comments ? i think i had followed all of your recommandations.

@yarikoptic
Copy link
Member

thanks @Th4nat0s
I will place summary questions here but I might also embed some comments inline

IMHO

  • we should not need a separate action file (e.g. iptables-multiport-46.conf) -- necessary modifications should be done in all iptables*.conf actions to use our wrapper script
  • why not to compose fail2ban-iptwrp (why not more descriptive fail2ban-iptables?) in Python thus avoiding calls to egrep and making it more harmonized with the rest of the project... let me know if I should work on that

@Th4nat0s
Copy link

I agree, it make sense to have fail2ban-iptwrp (ok ok fail2ban-iptables :) ) in python too. I could handle it... it's should be easy todo, a good easy and usefull thinks for me to discover python .).. Allow me to do this.

Adding to this i think we had to implement a global switch in global configuration to allow ipv6 banishment. This switch will be checked when validating ip.

I thinks it's the better solution to avoid any side effects on other systems. What do you think about it ?

@yarikoptic
Copy link
Member

Th4nat0s reply@reply.github.com wrote:

I agree, it make sense to have fail2ban-iptwrp (ok ok
fail2ban-iptables :) ) in python too. I could handle it... it's should
be easy todo, a good easy and usefull thinks for me to discover python
.).. Allow me to do this.

Adding to this i think we had to implement a global switch in global
configuration to allow ipv6 banishment. This switch will be checked
when validating ip.

I thinks it's the better solution to avoid any side effects on other
systems. What do you think about it ?


Reply to this email directly or view it on GitHub:
#39 (comment)

Yes I thought about global switch as well :-)

Sent from a phone which beats iPhone.

@Th4nat0s
Copy link

Well the code seems to works, all in python, (well i could like this language).
it's following your requirements and was tested by my fellow testers.

Now the global switch; Any requirements ?

@gurubert
Copy link

gurubert commented Sep 5, 2012

There is an ipaddr module for Python that can transparently handle IPv4 and IPv6 addresses: http://code.google.com/p/ipaddr-py/

This would remove the need to use regexps and searches. The ipaddr address object has a version attribute (set to 4 or 6).

@yarikoptic
Copy link
Member

@gurubert : thanks for the reference to ipaddr-py, which I actually forgot about while reviewing/working on #88. Funny enough though -- they could not select less fortunate license -- Apache 2.0, which is AFAIK incompatible with fail2ban's GPL v2 (iirc v3 should be compatible with apache 2 and then we could release fail2ban under gpl v3 since it is under original GPL v2 or any later version).
Also I guess I better educate myself first why

*In [35]: ipaddr.IPAddress('2001:1::') in ipaddr.IPNetwork('2001::')
Out[35]: False

? ;-) But I guess we could make some use of it indeed!

meanwhile I have just whined about their GIT repository [1].

[1] https://code.google.com/p/ipaddr-py/issues/detail?id=100&thanks=100&ts=1352501764

@jrosink
Copy link

jrosink commented Nov 20, 2012

*In [35]: ipaddr.IPAddress('2001:1::') in ipaddr.IPNetwork('2001::')
Out[35]: False

Because 2001:: isn't a IPv6 network, try 2001::/64 or 2001::/48 which are the most common prefixes.

@yarikoptic
Copy link
Member

Thanks @Jorgen-Rosink -- I will just excuse myself with "it was late at night and I felt some mighty magic behind IPv6". Specification of the netmask makes total sense and now it is clearer to me ;)

@ache
Copy link
Contributor

ache commented Nov 25, 2012

FYI, FreeBSD ipfw can handle both IPv6 and IPv4 addresses, so only understanding IPv6 in <HOST> and "ignoreip" is needed.
BTW, standard f2b ipfw.conf uses <localhost> which is not desired. Simple and much cleaner setup is using "me" instead:

  1. create via /etc/rc boot stuff ipfw rule "deny ip from table(1) to me"
  2. actionban = ipfw table 1 add <ip>
    actionunban = ipfw table 1 delete <ip>

@Th4nat0s
Copy link

Th4nat0s commented Dec 2, 2012

Sorry I was busy a while..

So to resume, hope everybody will agree

  • We need a general IPv6 switch to enable or disable the feature
  • BSD Doesn't need a "iptable" multiplexer.. but a custom action file
  • IPv6 address should be better checked (more than a simple regex).

Did i miss something ?

@Fantu
Copy link

Fantu commented Dec 13, 2012

I ban with route instead of iptables, will be a problem with IPV6?

@grooverdan
Copy link
Contributor

I'm working on it https://github.com/grooverdan/fail2ban/tree/ipv6 . I've got the lower layers working with test cases. Still debugging the rest of the stack. The comments as to how I was doing it are here #88.

Fantu, I expect I can accommodate the route banning.

@grooverdan
Copy link
Contributor

sample rewritten action rules: https://github.com/grooverdan/fail2ban/tree/ipv6/config/action.d

some same log entries of failures with IPv6 origins on services would be useful. Can people comment those here?

@yarikoptic
Copy link
Member

btw -- grep for '<<<<<<<' -- there were some conflicts I guess

and I am still not sure if going for explicit duplication is the way "to go"...

btw -- why are you introducing ? wouldn't it be more logical then just to embed netmask straight in the action definition? (although yeah -- less flexible)

@grooverdan
Copy link
Contributor

btw -- grep for '<<<<<<<' -- there were some conflicts I guess

thanks. Fixed.

btw -- why are you introducing ?

ipv6banprefix I assume. I thought the ban manager needed to keep track of which things where banned. Without the banmanager being aware of the ipv6banprefix it would be doing ban action more than once when bans come from the same network potentially resulting the same firewall rules. Is this ok? I didn't know if all actions handled this properly.

wouldn't it be more logical then just to embed netmask straight in the action definition? (although yeah -- less flexible)

I can't see using netmask straight in the action definition as less flexible. Its probably just as flexible as a option on the action configuration file. I'm happy to do it either way.

and I am still not sure if going for explicit duplication is the way "to go"...

Embedding netmasks into the actions wouldn't really be possible without explicit duplicate definitions. Lets see what it looks like at the end of development. Most work so far has been coding dnsutils and support for IPv6 from the bottom of the software stack up and adding test cases.

aside:

ipaddr-py has some nice network overlap functions. At the moment I'm getting away with implementing the functions I needed because of the license variation (sometimes based of ipaddr-py concepts). Its going to be fine while fail2ban works on the same bannetmask with IPv6. If this varies for some reason it could get ugly and complicated.

@grooverdan
Copy link
Contributor

and I am still not sure if going for explicit duplication is the way "to go"...

Can we setup an area to list all the requirements, some approaches and the pros and cons of each approach?

My first, potentially biased, draft:
https://gist.github.com/4440936

@yarikoptic
Copy link
Member

Hi @grooverdan

Sorry for being silent on this...

Since you have done so much work already on your ipv6 branch, and fail2ban simply can't stay address-space ignorant, and looks like got a complete working solution already, it would be plain stupid to go with anything else...

Merging it into 0.9 though already would be a good bit of fun (there was development and now there is also the "fail2ban" module) -- but, would you mind preparing a PR with ipv6 having 0.9 merged (better would be "rebased" but that would probably be too much pain than gain)

Also I wonder if it wouldn't be worth making possible to switch any particular address space coverage off? e.g. by

  1. adding an option e.g.
    addresses = ip4, ip6
    by default but allowing to have e.g. only ip4
  2. extending all commands with a diagnostic identifier to signal the space they belong to, e.g.
actionstart = iptables -N fail2ban-<name> # <ip4>
              ip6tables -N fail2ban-<name> # <ip6>

and then executing only commands for "active addresses". e.g. on many boxes I do not have ipv6 enabled (besides local addresses) -- so why should I even bother with calling iptables6 on them?

Also I am already a bit confused with the code in few spots -- but I guess it would be better to discuss in a PR.

@gurubert
Copy link

There is one thing to consider wrt the vast address space in IPv6:

Attackers can use one source address per login attempt.

Detecting an attack is harder. Do we look at the /64, /56 or /48 when comparing source IPs of failed login attempts?

@yarikoptic
Copy link
Member

good point -- probably the same ipv6banprefix should then be in effect to collect offending attempts

@grooverdan
Copy link
Contributor

@yarikoptic wrote:

Sorry for being silent on this...

no problem. bit topic. And it gave me months to finish :)

better would be "rebased" but that would probably be too much pain than gain)

I have re-based a few times. Hopefully most of the pain is over.

adding an option e.g.
addresses = ip4, ip6

Maybe. What benefit does it give?

by default but allowing to have e.g. only ip4

So by default there could be IPv6 errors and alerts and potentially IPv6 capable banning actions but this is disabled by default. Doesn't sound very secure or use friendly to me.

I'd rather the logs be load and noisy at a IPv6 ban command not working.

extending all commands with a diagnostic identifier to signal the space they belong to, e.g.

Purpose? A sysadmin looking at it can see that a command is likely to be IPv6 or not.

and then executing only commands for "active addresses". e.g. on many boxes I do not have ipv6 enabled (besides local addresses)

Even if its link local its still accessible to those on the same network. Protection

-- so why should I even bother with calling iptables6 on them?

protection by default.

Also I am already a bit confused with the code in few spots -- but I guess it would be better to discuss in a PR.

Sure. Either here on in my repo area.

@gurubert wrote:

Detecting an attack is harder. Do we look at the /64, /56 or /48 when comparing source IPs of failed login attempts?

Yeh. Like @yarikoptic said using ipv6banprefix defaulting to /64 is probably the way to go. I've partially done the expansion to take into account prefixes but still have a little more to go.

Ipv6banprefix in my code was the prefix to ban when an IPv6 address is banned. If you think I need a different setting for detection let me now, but I'd want a good reason.

@yarikoptic
Copy link
Member

note that we had experimental branch adopting similar solution which resides in
https://github.com/fail2ban/fail2ban/tree/_tent/ipv6_adapter_cmd branch of this repository... I would need to recall why we decided not to pursue that approach. If someone updates the branch (and does some archeology research into our mailing list etc) to current state of things and send a PR, we might have a clearer view.

Once again -- for proper support of IPv6 we would need allow banning by subnets and accommodate for differences in syntax for the tools/firewalls we use in actions. We can't accept a solution which would later show not to scale properly (leaving some actions without ipv6 support), so half-working solutions shouldn't get merged since supporting it and providing smooth upgrades might become a pain I would not allow to cause upon ourselves ;)

@pdf
Copy link

pdf commented Jul 3, 2015

@yarikoptic this is why there's no IPV6 support. You need to consider merging basic IPv6 support, then adding enhancements like subnet blocking (which should be made available for both IPv6 and IPv4), break the work into manageable chunks.

@leeclemens
Copy link
Contributor

@pdf subnet blocking is necessary for ipv6 support (memory exhaustion).

@neirbowj
Copy link

neirbowj commented Jul 3, 2015

...a host in ipv6 is a /64 and a /64 is the smallest chunk that gets handed to someone.

This is not true. Typically, but by no means exclusively, a /64 is the prefix length for a single link (layer 2 broadcast domain, VLAN...), or, as the ServerFault answer you cited says, "/64: the basic size of a single subnet". There can be a truly staggering number of hosts with addresses covered by a given /64 prefix.

@neirbowj
Copy link

neirbowj commented Jul 3, 2015

...it would be against the current recommendation. a staggering /64 is what each end point is supposed to get.

Where are you getting this information? What do you mean by "end point?" It sounds like you have some misconceptions about IPv6 addressing.

@pdf
Copy link

pdf commented Jul 3, 2015

@neirbowj, Technically yes but it would be against the current recommendation. a staggering /64 is what each end point is supposed to get.

What? That's nonsense. What's an 'end point' in your mind? You don't allocate a /64 to every host, that would be insane.

Even if someone divided up their /64 into smaller chunks, they still have that /64. Can someone explain why you would not block their entire /64?

As an example, VM hosting companies may decide against allocating a /64 for every one of their customers (justifiably?), which means that a single malicious actor on one of their hosts will cause you to block the rest of the legitimate hosts on that subnet.

@reissmann
Copy link

Blocking the /64 will definitely result in problems with the current deployment of IPv6. As an example take this colocation provider: https://contabo.com/?show=servers

They advertise their server products as IPv6 ready. Each server will get 65.535 IPv6 addresses, which definitely is not a /64. Of course the problem is the provider here, but I guess this is not the only provider doing this.

@arekm
Copy link

arekm commented Jul 4, 2015

But what you cited above is all about subnet and NOT single host. Making huge simplification: /64 in ipv6 is like /24 (was few years ago) for ipv4.

@Deshke
Copy link

Deshke commented Jul 4, 2015

so you are arguing at the moment over the default bann prefix ? shouldn't this be a setting in a config file?

@pdf
Copy link

pdf commented Jul 4, 2015

@mgrant0 you have absolutely no idea what you're talking about. Each host most definitely does not get a /64, that's just complete stupidity. You've obviously never deployed (or used?) IPv6, and you've quoted the RFCs that explicitly state the opposite of what you keep saying. Because what you're saying is completely and utterly nonsensical, I mean really just totally batshit. Please stop.

@reissmann
Copy link

@mgrant0 of course contabo is wrong! I'm just saying that this is the current state of implementation - many companies doing it wrong. This can definitely result in unexpected filtering.

From the fail2ban/firewall's point of view, if you do not block the subnet, even in the contabo case with just a /112, you get 65535 * 3 (or whatever you set maxretry to) attempts before getting blocked. Considering this, it is not even enough to block the subnet based on a single IPv6 address. Instead, one could argue that any attempt from the same subnet needs to be considered the "same source", meaning that any attempt from any IPv6 address in the subnet needs to be added and compared to the maxretry parameter.

@pdf
Copy link

pdf commented Jul 4, 2015

@reissmann contabo is not even wrong, the RFCs are talking about routers, and the subnet size minimum is a routing concern - how you distribute the IPs to hosts within the subnet is up to the operator. But yes, the sane way to block subnets is to count IPs in the same subnet against maxfail (and probably increase it to compensate).

@neirbowj
Copy link

neirbowj commented Jul 4, 2015

@pdf wrote

@mgrant0 you have absolutely no idea what you're talking about. Each host most definitely does not get a /64, that's just complete stupidity. You've obviously never deployed (or used?) IPv6, and you've quoted the RFCs that explicitly state the opposite of what you keep saying. Because what you're saying is completely and utterly nonsensical, I mean really just totally batshit. Please stop.

@pdf, please don't take this kind of tone. It harms the central goals of this discussion, and, more broadly, harms the fail2ban project by shutting down participation and driving away contribution.

@mgrant0, I think I understand something about the nature of your misunderstanding. It's hard to boil it down, but let me try.

In IPv4, when you configure a host interface with an address and prefix length, like 192.0.2.33/24, this assigns exactly one address to the host with network address 192.0.2.0/24 and host address 0.0.0.33, and gives the host a way to determine whether any given address belongs to a node attached to the same link or not, or, equivalently, whether the given address is reachable directly or only by way of the host's default gateway. There is nothing all that special about a /24, except that it corresponds to an octet boundary, which makes mental subnet calculations easy, and represents a network of a useful size (1 gateway and 253 hosts) in the context of address scarcity.

In IPv6, the same basic rules hold (see footnote 1), so if a host interface is configured with an address and prefix length, like 2001:db8:d00d:babe::33/64, one can infer corresponding semantics: the host has been assigned exactly one address with prefix 2001:db8:d00d:babe::/64 and interface identifier ::33, and it can tell whether any given address is attached to the same link or not (i.e. contact directly vs. contact by way of router). What's a bit different with IPv6, and where I think you may be getting wrapped around the axle, is that /64 is special. The main reason that it's special is because it divides an address at the only point that is allowable for the operation of SLAAC on Ethernet networks (see "interface identifier" in Section 2 of RFC 4862 IPv6 Stateless Address Autoconfiguration, and Section 4 of RFC 2464 Transmission of IPv6 Packets over Ethernet Networks). That does not mean that the entire /64 piece of address space is allocated for the benefit of a single host for the exclusive, autonomous assignment of any or all addresses within it. It means that the each host on that same network is free to generate an interface identifier that is 64-bits long (see footnote 2).

On links where SLAAC is not enabled—such as on point-to-point links, or virtual loop-back links, both of which are very common for routers and very uncommon for hosts—the 64-bit constraint does not apply, and other considerations (e.g. see RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links) come into play. This is probably why you find phrasing about prefix lengths "for hosts."

It might be an interesting thought experiment to read RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing as if it were titled "Analysis of the 24-bit Boundary in IPv4 Addressing," replacing "subnet prefix" with "network address," "interface identifier" with "host address," and so forth, to see how compatible the conceptual models are.

I hope this helps.

Footnote 1: RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes tries to inject some daylight between any assigned address and the notion of an intrinsic or invariant prefix length that belongs to it, but by far the dominant implementation trend is to encourage operators to treat IPv6 the same way they treated IPv4.

Footnote 2: Because of, e.g., RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6, a single host typically generates and self-assigns more than one interface identifier within the available /64, especially over time. The probability of collision is infinitesimally small though, so there is still no need to reserve a /64 per host.

@yarikoptic
Copy link
Member

ok -- now that we have "disgussed" prefix to a degree sufficient to state that we all agree it is necessary to support configurable prefix length, next topic could be (and that is the actually major stumble point) is how to support tools which require different cmdline tools (possibly with different syntax) to execute actions for ipv4 and ipv6 addresses. Multiple approaches were suggested with different degree of scalability/maintainability

  1. fail2ban-* wrappers

    pros:

    • quick and dirty working solution(s) which might work for both iptables and shorewall (and may be others)
    • efficient in terms of avoiding duplication of commands definitions separately for ipv4 and ipv6

    cons:

    • no way to customize whenever different cmdline arguments are needed for ipv4 vs ipv6 (I can't recall but that is where I believe we decided it would not be the way to go, but forgot which was the example).
    • regexping entire line to decide 4 vs 6 can be fragile, also it is duplication since fail2ban-server process already would know what family of the address it is dealing with!
  2. explicit specification of different commands for ipv4 and ipv6 . @grooverdan has done already lots of work on that implementation: e.g. https://github.com/grooverdan/fail2ban/tree/ipv6_2 (there is few more branches... needs to be recovered if we decide to go that way, also in my clone https://github.com/yarikoptic/fail2ban/tree/ipv6), and then fail2ban process deciding which lines to run depending on what family of address it is (4 vs 6) and looking for <ip4 vs <ip6 (vs <ip> for any) in the cmd to run.

pros

  • semi-explicit (decision based on the tags within the line -- could be taken as cons)
  • tightly integrates with fail2ban-server process knowing the family of the address (no duplication of logic as in wrappers solution)

cons

  • duplication of highly similar cmdlines (besides different executable)

I don't remember what was left to be done to make it a complete perspective solution

  1. we had few more (flexible/fragile) proposals, e.g. ... need to run -- will complete later ;)

@rotanid
Copy link

rotanid commented Jul 4, 2015

in my opinion a "default prefix" which can be changed isn't the best option.
what about raising the size of the blocked subnet slowly as attacks from neighbor-subnets appear (example: /128, /112 (vps providers), /96, /80, /64, /56 (f.e. DTAG-DSL-customers), /48 (datacenter customers))

@mgrant0
Copy link
Contributor

mgrant0 commented Jul 4, 2015

@neirbowj Ok, thanks for the explanation. I think I see my misunderstanding now. It has to do with host sitting in a /64 versus routed a /64 to the host. In the immortal words of Emily Litella, never mind.

@leeclemens leeclemens added the ipv6 label Jul 8, 2015
@grooverdan grooverdan removed their assignment Jul 9, 2015
@thctlo
Copy link

thctlo commented Jul 9, 2015

in comment of : subnet blocking is necessary for ipv6 support (memory exhaustion).
isnt the IP set feature not a solution for that?

@sebres
Copy link
Contributor

sebres commented Jul 9, 2015

@thctlo how the IP-set will help to prevent memory exhaustion in fail2ban (python, sqlite database of f2b etc.)?
The internal merge of multiple tickets with IPs of the same subnet necessary to be made in f2b self. That requires changing some basic structures and algorithms in f2b.

@thctlo
Copy link

thctlo commented Jul 9, 2015

ah ok, sorry for the noice, i mis read the thread.. ,

@yarikoptic
Copy link
Member

yarikoptic commented Jul 22, 2015

This issue grew out of proportions and was "closed" to be continued in #1123 .

DO NOT POST NEW COMMENTS HERE OR THEY WILL GET REMOVED.

Discussion will continue in #1123 and other new tickets and PRd

We have introduced a new branch with IPv6 support: 0.10, and the new PR #1410
The decision is at least firstly - 0.9 will never get IPv6-support.

Everyone interested to test 0.10 is welcome to review resp. try this new vesion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests