On 09/05/2012 12:36 PM, Jan Cholasta wrote:
> Dne 5.9.2012 12:22, Petr Spacek napsal(a):
>> On 09/05/2012 11:30 AM, Jan Cholasta wrote:
>>> Dne 5.9.2012 10:04, Martin Kosek napsal(a):
>>>> We allowed IP addresses without network specification which lead
>>>> to unexpected results when the zone was being created. We should rather
>>>> strictly require the prefix/netmask specifying the IP network that
>>>> the reverse zone should be created for. This is already done in
>>>> Web UI.
>>>> A unit test exercising this new validation was added.
>>>> https://fedorahosted.org/freeipa/ticket/2461
>>> I don't like this much. I would suggest using CheckedIPAddress and not
>>> forcing
>>> the user to enter the prefix length instead.
>>> CheckedIPAddress uses a sensible default prefix length if one is not
>>> specified
>>> (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for
>>> IPv4,
>>> /128 for IPv6 - this causes the erroneous reverse zones to be created as
>>> described in the ticket).
>> Hello,
>> I don't like automatic netmask guessing. I have met class-based guessing
>> in Windows (XP?) and I was forced to overwrite default mask all the time
>> ...
> If there was no guessing, you would have to write the netmask anyway, so I
> don't see any harm in guessing here.
>> IMHO there is no "sensible default prefix" in real world. I sitting on
>> network with /23 prefix right now. Also, I have never seen 10.x network
>> with /8 prefix.
> While this might be true for IPv4 in some cases, /64 is perfectly sensible for
> IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix.
> Honza

While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks
as Petr already pointed out. I don't think that there will be many people
expecting that a reverse zone of would be created.

And since FreeIPA is mainly deployed to internal networks, I assume this will
be the case of most users.


Freeipa-devel mailing list

Reply via email to