Hi Daniel, On Tue, Apr 12, 2016 at 01:47:25PM +0200, Daniel Schneller wrote: > 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 :)
hehe :-) > I will at least provide a documentation patch then, soon. OK. > 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 :) People doing that obviously don't use DNS. But it's convenient when you want to keep the same configs (or with minimal changes) between preprod and prod for example. Then you put everything you need into /etc/hosts. I'm not saying that <host>/<mask> is widely used though, but it's supported so who knows who's using it ? > > 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. I learned it 18 years ago when QNX was shipping a fully working OS and browser on a single diskette. The browser used to connect to http://127.1/ and since then I don't think I have ever typed 127.0.0.1 anymore. Same for most IP addresses, on test platforms I arrange for setting the networks with zeroes in the middle so that I can have 10.1, 11.1, etc... Very convenient. > 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. Having people used to type short IP addresses put them into configurations doesn't have to be rare. What should be rare is the fact that they pruposely combine them with a mask due to the ambiguity, but when blindly adding /31 after very address, you can easily end up with this. > 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 wouldn't be that sure, I don't even know if I don't have some of them myself. That's what a warning is about anyway : "I noticed you did something that various people understand differently, it's possible I didn't do what you expected so you'd rather clarify it". > I might be alone here, but I believe a warning (not a failure) about these > rather unorthodox notations being used would improve things :) As I said, for short IP addresses combined with the mask sure. For plain addresses without masks, I'll be the first one annoyed. Also, it's support by everything else on the system since it's provided by the libc so there's no reason for making an exception. Look : willy@wtap:haproxy-1.5$ fgrep 127.1 *conf hco.conf: bind 127.1:8080 pp.conf: bind 127.1:8080 sqli.conf: bind 127.1:8001 Regards, Willy
