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:
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)?
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
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 10/22/12 13:59, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
For safety, i would use 48, to allow zero termination
why 48 when max length of ipv6 addr is 39 chars? did you mean 40?
If you use 4-in-6 mapped format, omit zeroes compression and add square brackets, you get 47 characters:
[0000:0000:0000:0000:0000:ffff:123.123.123.123]
cheers
Richard Fuchs writes:
If you use 4-in-6 mapped format, omit zeroes compression and add square brackets, you get 47 characters:
[0000:0000:0000:0000:0000:ffff:123.123.123.123]
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:
Richard Fuchs writes:
If you use 4-in-6 mapped format, omit zeroes compression and add square brackets, you get 47 characters:
[0000:0000:0000:0000:0000:ffff:123.123.123.123]
why would someone use such a format when there is canonical format specified in http://tools.ietf.org/html/rfc5952?
I don't know why, but http://en.wikipedia.org/wiki/Robustness_principle
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?
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:
Daniel-Constantin Mierla writes:
For safety, i would use 48, to allow zero termination
why 48 when max length of ipv6 addr is 39 chars? did you mean 40?
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:
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.
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:
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.
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:
Olle E. Johansson writes:
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.
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.
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:
Daniel-Constantin Mierla writes:
For safety, i would use 48, to allow zero termination
why 48 when max length of ipv6 addr is 39 chars? did you mean 40?
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:
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.
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:
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..
yes, but when they are used in url, square brackets are not part of the address. they just delimiting the address.
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.
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:
Daniel-Constantin Mierla writes:
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..
yes, but when they are used in url, square brackets are not part of the address. they just delimiting the address.
that's why I said ipv6 address representation.
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.
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.
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:
many times the management system sits between chair and keyboard :-) , being able to read/add human representation is really crucial in this case.
leaving out square brackets, which are not specified in ipv6 address rfc, should not be an overwhelming task for any address writer.
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.
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:
Daniel-Constantin Mierla writes:
many times the management system sits between chair and keyboard :-) , being able to read/add human representation is really crucial in this case.
leaving out square brackets, which are not specified in ipv6 address rfc, should not be an overwhelming task for any address writer.
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.
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.
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.
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:
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.
Go ahead and add such entity.
Cheers, Daniel
Daniel-Constantin Mierla writes:
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) = 45Then add 3 for the square brackets and the ending 0.
i just checked and str2ipv6 function does not support the embedded ipv4 format. also, i still claim that square brackets are delimiters and not part of the address. so 39 plus one more for zero byte would be fine.
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Richard Fuchs