Unintuitive CIDR + Port rule inout

[ignoramous]

Doesn't work: 192.168.0.0/16:443

Incorrect: 192.168/16 => 192.0.0.168/16 (should be, 192.168.0.0/16)

[ignoramous]

Apparently, the current behaviour is in line with how popular apps (incl browsers) interpret string representations of IP addresses. Closing...

[Rhys-T]

Just ran into this (although I wasn't trying to include a port number). In the context of single IPv4 addresses, the current behavior (putting the zeros in the middle - or more accurately, treating the last number as several bytes stuck together) is 'correct', though I gather it's basically "something that BSD's inet_aton() made up and everyone else copied" rather than an officially-specified syntax.

For a range of IPv4 addresses in CIDR notation, though… I'm not sure. RFC 4632, which seems to contain the official definition for that syntax, says nothing about being able to leave numbers out of the 'address' part. Common usage seems to be that if there are fewer than four numbers in the address part, you add zeros on the right until there are enough (so 192.168/16 would be 192.168.0.0/16). And in particular, RFC 1918 - which defines that 192.168.* range - uses it that way, referring to the three private address ranges as 10/8, 172.16/12, and 192.168/16. That seems to me like the more useful interpretation, because otherwise the last number would tend to fall into the unused/variable bits of the address. But none of that necessarily makes it the correct interpretation - if there even is one…

[ignoramous]

Yeah, I guess you've a point... but the library we use, follows the BSD model. Also, I believe there's an rfc for string representation of IP addresses. I can't find it now, but I (probably incorrectly) recall it preferred the BSD style.

btw, BSD also did ruin multipath TCP (ref)... so they've a lot of blood on their hands ;)

[ignoramous]

Impl in v055b: 38cb9ec