Hi Pavlos!
> On 09.04.2016, at 11:39, Pavlos Parissis <[email protected]> wrote:
>
> On 08/04/2016 11:59 πμ, Daniel Schneller wrote:
>> Hi!
>>
>> I noticed that while this ACL matches my source IP of 192.168.42.123:
>>
>> acl src_internal_net src 192.168.42.0/24
>>
>> this one does _not_:
>>
>> acl src_internal_net src 192.168.42/24
>>
>> While not strictly part of RFC 4632 (yet), leaving out trailing .0
>> octets is a very common notation and is probably going to be included
>> in a future RFC update (as per Errata 1577):
>> https://www.rfc-editor.org/errata_search.php?rfc=4632&eid=1577
>>
>> If there are concerns against this notation, the config parser should
>> at least issue a WARNING or even ERROR about this, because I found it
>> it quite confusing. Especially if ACLs are used for actual access
>> control, this can have nasty consequences.
>>
>> What do you think?
>>
>
> I had a similar discussion with a colleague for another software and
> I am against it:
>
> 1) In 2016 it is a bit weird to speak about classful networks
Not sure I understand what you mean. RFC 4632 is called Class*less*
Inter-domain Routing (CIDR).
That’s the whole point, not having fixed A/B/C sized networks. Still,
especially for the RFC 1918 (Private Addresses) even the RFC itself uses the
shorter notation (section 3):
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
This is from 1996, even then talking about class*less*.
But maybe I misunderstood your point?
> 2) In may introduce ambiguity due to #2
What #2 are you referring to? My 2nd example? How would it introduce ambiguity?
Cheers,
Daniel
