lcr_gw table has:
ip_addr varchar(47)
trusted table has:
src_ip varchar(50)
address table has:
ip_addr varchar(48)
why is it that they are not all the same? also, why the common length is not 8 * 4 + 7 = 39 (http://en.wikipedia.org/wiki/IPv6#Address_format)?
-- juha
On 10/22/12 4:11 PM, Juha Heinanen wrote:
if you take in consideration the ipv4 tunneling address format, then it is 45, plus square bracket representation [...] results in 47.
For safety, i would use 48, to allow zero termination -- not sure it is actually needed, just that we have some custom db backend that might require it it, like dbtext. Anyhow, varchar(x) is well known db systems allocate only what is needed.
Cheers, Daniel
Richard Fuchs writes:
why would someone use such a format when there is canonical format specified in http://tools.ietf.org/html/rfc5952?
in this rfc and in http://en.wikipedia.org/wiki/IPv6_address i was not able to find anything about the format you gave example above. where is it specified?
-- juha
On 10/22/12 14:14, Juha Heinanen wrote:
I don't know why, but http://en.wikipedia.org/wiki/Robustness_principle
Under "dotted-quad notation", minus "leading zeroes" and minus "groups of zeroes" (note the little word "may" in both of these sections), plus "Literal IPv6 addresses in network resource identifiers".
cheers
22 okt 2012 kl. 19:59 skrev Juha Heinanen jh@tutpro.com:
It's hard to judge the max length of IPv6, since there are many notations. With IPv4 embedded IPv6 the text is expanded. With scoped addresses where the interface name is added, it grows again.
/O
Olle E. Johansson writes:
ipv6 is even bigger mesh than what i ever thought.
as i wrote, there is the canonical rfc. why to support all kind of custom formats?
to me it makes sense to store addresses only in canonical format to database in order to make sure that address comparison can be made uniquely.
-- juha
On 10/22/12 14:19, Juha Heinanen wrote:
Using the string representation of an address for anything other than to provide a human readable version of it is not a good idea. That's true not only for IPv6 addresses: http://3239475010/ (doesn't work in IE IIRC).
If you want to compare addresses in code, use raw 128-bit addresses.
cheers
On 10/22/12 8:19 PM, Juha Heinanen wrote:
ipv6 addresses can be safely compared only in binary format, never as text representation -- in config you can use ipops module.
As long as a format is valid, it is pretty much a bug not supporting it. Otherwise why not requiring binary value in storage...
On the other hand, I see no drawback in having varchar(50) or varchar(60) -- the stored value does not take a longer byte than needed in database and, at least for address, comparison is done in memory.
Cheers, Daniel
On 10/22/12 7:59 PM, Juha Heinanen wrote:
text representation can use ipv4 format for last 4 bytes:
http://tools.ietf.org/html/rfc4291#page-4
common for cases when tunneling ipv4 over ipv6.
That is:
(6 * 4 + 5) + 1 + (4 * 3 + 3) = 45
Then add 3 for the square brackets and the ending 0.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Then add 3 for the square brackets and the ending 0.
where are square brackets specifies? there is nothing about them in http://tools.ietf.org/html/rfc4291.
-- juha
On 10/22/12 8:23 PM, Juha Heinanen wrote:
I gave the link to show the ipv4 representation. Square brackets are commonly used in ipv6 representations, specially in url/uri -- wikipedia link you provided mentions that..
Being a code read by machine and being required to support them in kamailio (as we get ipv6 from headers/uri), I see no problem in being flexible enough to deal with both cases.
Cheers, Daniel
Daniel-Constantin Mierla writes:
yes, but when they are used in url, square brackets are not part of the address. they just delimiting the address.
are you sure that kamailio lcr and permissions modules are able handle all those non-canonical ipv6 addresses (including square brackets that are not part of the address) when tables are reloaded?
to me it would make sense to canonize user given addresses before management system stores them to database.
-- juha
On 10/22/12 8:36 PM, Juha Heinanen wrote:
that's why I said ipv6 address representation.
many times the management system sits between chair and keyboard :-) , being able to read/add human representation is really crucial in this case.
The fact is that canonical format works just fine, it's all ok if you want to use it always.
All modules should support all variants if they use the ipv6 address parser from core. The functionality related to address checking from permissions module does it for sure, I have no idea if lcr implements custom parser. I think trusted from permissions has an issue, iirc, because the comparison was done via string comparison --not using it I am not sure if anyone change it.
Cheers, Daniel
Daniel-Constantin Mierla writes:
leaving out square brackets, which are not specified in ipv6 address rfc, should not be an overwhelming task for any address writer.
lcr module uses str2ipv6 from core that does not support embedded ipv4 format. if it is not supported by core, it doesn't make sense to support them in tables either.
-- juha
On 10/22/12 9:01 PM, Juha Heinanen wrote:
Representation with square brackets is defined in a RFC and I see no real benefits in not supporting it.
I am not sure anymore the reason of the debate here. Saving two optional bytes which are not allocated if not used in a db varchar field?
Overall the point should be: either binary value for the very compressed data storage or allow all human-friendly possible variants. Forcing one specific human friendly format is not an optimized/safe option from any point of view.
It is the other way around, the function has to be enhanced, because it lacks support for a valid format. Again, dealing with ipv6 can happen when parsing header fields, it is not matter of using in lcr module.
In most of written discussion I recall now, people use square brackets representation, because it is clear delimitation of the address. I think a 24/7 first line support sysop that receive some log messages regarding some DoS attack from [x:y:z:w]:5060 will just copy and paste to ban the traffic via permissions.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I am not sure anymore the reason of the debate here. Saving two optional bytes which are not allocated if not used in a db varchar field?
it started because there is three different lengths of ip address field in three different tables, which does not make any sense and is very confusing to a ipv6 newcomer.
now i don't anymore care what the length is as long as all tables use the same length via an entities variable.
-- juha
On 10/22/12 9:37 PM, Juha Heinanen wrote:
Go ahead and add such entity.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Richard Fuchs