Hi guys, On Sat, Apr 09, 2016 at 03:38:39PM +0200, Pavlos Parissis wrote: > On 09/04/2016 02:59 ????, Daniel Schneller wrote: > > Hi Pavlos! > > > >> On 09.04.2016, at 11:39, Pavlos Parissis > >> <pavlos.paris...@gmail.com> 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? > > > > No, you are right I am wrong, next time I should read the RFC twice, sorry. > > > > >> 2) In may introduce ambiguity due to #2 > > > > What #2 are you referring to? My 2nd example? How would it introduce > > ambiguity? > > I was referring to my 1st point which is *wrong*, so point #2 can be > ignored. > > Sorry again for hitting enter so quickly. > > /me going to print the RFC4632 and read it twice.
Well, I'm all for improving this but I'm not sure what the best fix is. ACLs not only support networks they also support addresses. And in fact here networks are just an extension of addresses with a mask applied. The problem is that in IPv4, 192.168.42 is host 42 on network 192.168 so it is in fact 192.168.0.42. Thus in cases where we support both addresses and networks, 192.168.42/X is ambigous. For example, someone could have a first LB on 192.168.0.42 and write a rule based on "192.168.42". Then the second host comes and instead of creating a new entry with 192.168.43, he rightfully appends a /31 mask and this gives : 192.168.42/31. The problem is that for the user, this means 192.168.0.42/31 while according to the RFC above it would rather mean 192.168.42.0/31. Also the address parser supports host names. So you can very well have foo/31 where foo resolves to 192.168.0.42 and it will work. Thus I guess the best we can do is emit a warning in the following situation : - a mask was specified - an IP address (not a name) was specified with less than 3 dots And then we warn the user that the syntax is ambiguous. The problem is that the function which parses this is deeply burried in the code and not well placed to emit a warning, it either succeeds or fails :-( At least the doc can easily be improved. Regards, Willy
