Hi Mickael,
> MM3: I think setting didMetadataChange to true would make things simpler.
We don't really have a way to perform downgrade checks at the moment, so
you'd need to introduce a new mechanism.
re MM3: Okay. I have updated the KIP.
> When you parse "::ffff:192.168.1.1" with InetAddress.parse(), it returns
an Inet4Address instance. So you should be able to check it against an IPv4
CIDR.
re MM4:
What do you mean by InetAddress.parse()? There is no such method in the
java.net.InetAddress. If you mean, InetAddress.getByName() then
yes getByName("::ffff:192.168.1.1") returns an Inet4Address and I
eventually can check it.
> MM5: Following from MM4, what happens in the opposite scenario, an ACL
with "::ffff:192.168.1.1/24" and a client with an ipv6 address?
re MM5:
::ffff:192.168.1.1/24 is rejected at ACL creation time with an
InvalidRequestException. My method parseCidrAddress strips the prefix and
calls InetAddress.getByName("::ffff:192.168.1.1"), which the JVM normalizes
to a plain Inet4Address. So isIpv6("192.168.1.1") returns false, and we
call new SubnetUtils("::ffff:192.168.1.1/24"), which rejects it because
::ffff: is not valid IPv4 notation.
The deprecated IPv4-compatible form (::192.168.1.1/24) behaves differently.
The JVM does not normalize it and returns an Inet6Address
(0:0:0:0:0:0:c0a8:101), so it passes validation as a regular IPv6 CIDR. A
/24 on a 128-bit IPv6 address masks the top 24 bits, meaning ::
192.168.1.0/24 covers 0:: through 0:ff:ffff:ffff:ffff:ffff:ffff:ffff an
enormous and almost certainly unintended range. It would match an IPv6
client where the first byte is 0x00 (i.e., 0:0:: through 0:ff:ffff:...),
but would not match a plain IPv4 client (e.g., 192.168.1.5) since that goes
through SubnetUtils, not SubnetUtils6.
Cheers,
Maros
st 13. 5. 2026 o 17:52 Mickael Maison <[email protected]> napísal(a):
> Hi Maros,
>
> MM3: I think setting didMetadataChange to true would make things simpler.
> We don't really have a way to perform downgrade checks at the moment,
> so you'd need to introduce a new mechanism.
>
> MM4: When you parse "::ffff:192.168.1.1" with InetAddress.parse(), it
> returns an Inet4Address instance.
> So you should be able to check it against an IPv4 CIDR.
>
> MM5: Following from MM4, what happens in the opposite scenario, an ACL
> with "::ffff:192.168.1.1/24" and a client with an ipv6 address?
>
> Thanks,
> Mickael
>
> On Thu, May 7, 2026 at 8:38 PM Maroš Orsák <[email protected]>
> wrote:
> >
> > Hi,
> >
> > Thanks for the review and feedback.
> >
> > > MM1: Typically in a KIP we are not really interested in the actual
> > code changes but in the APIs and behavior changes.
> > re MM1: Got it. Thanks.
> > re MM2: Correct.
> >
> > re MM3:
> >
> > In my code changes the didMetadataChange is set to false where I checked
> > that, I did not update this KIP sorry (updated). So the downgrade is
> > possible but iff CIDR ACLs are no longer present (previously checked)
> > otherwise it would fail on the message error, which we discussed above
> with
> > Fede.
> >
> > re MM4:
> >
> > In my current version there is no explicit rejection. There are currently
> > two forms of it (i.) current form i.e., ::ffff:<IPv4> so for
> > instance ::ffff:192.168.1.1 and (ii.) the deprecated one <IPv4>
> > e.g., ::192.168.1.1. Inet6Address has a method for detecting these mapped
> > addresses but unfortunately it is package-private. I can add such a
> > check/validation but that would complicate the overall implementation.
> But
> > if you think we need to check such a race scenario I can update KIP with
> > that (and then eventually my implementation).
> >
> > Cheers,
> > Maros
> >
> > Do you want
> >
> > Hi,
> > >
> > > Thanks for the KIP. Just a few comments:
> > >
> > > MM1: Typically in a KIP we are not really interested in the actual
> > > code changes but in the APIs and behavior changes.
> > >
> > > MM2: If I understand correctly an ACL with a CIDR block should behave
> > > exactly the same way as if you create an ACL for each address that
> > > matches the CIDR block
> > > For example if I create an ACL for "1.2.3.4/30", it's like if I create
> > > 4 ACLs for 1.2.3.4, 1.2.3.5, 1.2.3.6 and 1.2.3.7.
> > > So using CIDR blocks allows to reduce the potential number of ACLs
> > > users have to create and manage.
> > >
> > > MM3: In the Downgrades safety section you mention some introducing
> > > some new validation logic.
> > > You define the new metadata version with didMetadataChange set to
> > > true, so I believe downgrade is currently not possible>
> > >
> > > MM4: In the IPv4-mapped IPv6 address section it's stated that
> > > IPv4-mapped IPv6 addresses are not going to be supported. Are they
> > > just ignored?
> > > Could we catch these addresses when they are parsed and reject the
> > > request if we detect one?
> > >
> > > Thanks,
> > > Mickael
> > >
> > > On Thu, Feb 19, 2026 at 5:10 PM Federico Valeri <[email protected]>
> > > wrote:
> > > >
> > > > Hi Maros, thanks for the KIP.
> > > >
> > > > It would be very convenient to have the possibility to use CIDR
> > > > notation when adding ACL rules, but I think we miss quite a few
> > > > details.
> > > >
> > > > FV1: The proposal does not specify what happens when multiple ACLs
> > > > with overlapping CIDR ranges apply to the same request. CIDR
> > > > introduces a new dimension: subnet specificity. The KIP should
> clarify
> > > > whether longest-prefix match apply, or whether CIDR ranges are
> treated
> > > > like wildcards. Without this, users will create overlapping rules
> with
> > > > unpredictable results.
> > > >
> > > > For example:
> > > > - ALLOW 10.0.0.0/8 on topic foo
> > > > - DENY 10.0.1.0/24 on topic foo
> > > >
> > > > Does a client at 10.0.1.5 get allowed or denied?
> > > >
> > > > FV2: How does the proposed matching logic handle IPv4-mapped IPv6
> > > > addresses? For example, if a DENY ACL is set for 192.168.0.0/24,
> does
> > > > it match a client whose address is reported as ::ffff:192.168.0.5?
> > > >
> > > > FV3: Kafka's existing ACL evaluation has precedence rules (DENY wins
> > > > over ALLOW, explicit match over wildcard). How does CIDR matching fit
> > > > into the existing precedence rules?
> > > >
> > > > FV4: I agree that we need a new metadata version because the CIDR
> host
> > > > is stored there (AccessControlEntryRecord). What happens if a
> > > > controller with CIDR support writes these records, then a downgrade
> > > > occurs before all CIDR ACLs are removed?
> > > >
> > > > FV5: You imply that commons-net library needs to be added to the
> > > > existing set of dependencies, but I think it is better to mention
> > > > explicitly. Also, is it really worth adding this full networking
> > > > protocol library for just one unreleased utility class? Have you
> > > > looked at KIP-7 approach?
> > > >
> > > > FV6: It looks like we miss a test plan and maybe some performance
> > > analysis.
> > > >
> > > > Cheers
> > > > Fede
> > > >
> > > >
> > > > On Thu, Jan 29, 2026 at 11:18 AM Maroš Orsák <
> [email protected]>
> > > wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > >
> > > > > I would like to start a discussion about CIDR-based host patterns
> for
> > > ACLs.
> > > > > Details can be found in the cwiki [1].
> > > > >
> > > > >
> > > > > [1] -
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1276%3A+CIDR-based+Host+Patterns+for+ACLs
> > > > >
> > > > >
> > > > > Best regards,
> > > > >
> > > > >
> > > > > Maros Orsak
> > >
>
