Hi Willy!
Thanks for looking into this. As mentioned in an earlier post I don’t have any
relevant C skills (but have been writing Java other languages); but still I
went into the code, telling myself “how hard could it be to add a warning for
less than three dots with a mask”. I quickly started to doubt myself when I
tried to understand what’s going on. I am glad you being intimately familiar
with that code come to the same conclusion as I did, namely that it is not
trivial to add that warning :)
I will at least provide a documentation patch then, soon.
However two things I wanted to bring up, still:
> 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.
Is this a serious use case? I can only imagine this is a recipe for disaster.
Starting from multiple A records for a DNS entry to complete intransparency
when doing this with anything other than a /32 mask. So this alone would IMO
warrant a warning to be issued :)
> 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.
Same here: I must admit I just learned from you that this a working notation
for IPv4.
But IMO there is a far smaller chance that this is practically used than the
CIDR notation mentioned above, making the config valid, but much harder to
read.
So while being technically valid (just as 0x3ed63e9f or 1054228127 would be —
both equivalent to one of Google.com’s public IPv4 addresses 62.214.62.159)
more often than not I imagine those will be typos or other accidental mistakes
in config files.
I might be alone here, but I believe a warning (not a failure) about these
rather unorthodox notations being used would improve things :)
Thoughts?
Daniel
--
Daniel Schneller
Principal Cloud Engineer
CenterDevice GmbH | Merscheider Straße 1
| 42699 Solingen
tel: +49 1754155711 | Deutschland
daniel.schnel...@centerdevice.de | www.centerdevice.de
> On 12.04.2016, at 11:59, Willy Tarreau <w...@1wt.eu> wrote:
>
> 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 <mailto: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
