22 Oct
2012
22 Oct
'12
10:11 a.m.
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
22 Oct
22 Oct
1:43 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
2:04 p.m.
On 10/22/12 13:59, Juha Heinanen wrote:
Daniel-Constantin Mierla 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]
cheers
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?
2:14 p.m.
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
2:17 p.m.
On 10/22/12 14:14, Juha Heinanen wrote:
Richard Fuchs writes:
I don't know why, but http://en.wikipedia.org/wiki/Robustness_principle
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?
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
2:07 p.m.
22 okt 2012 kl. 19:59 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Daniel-Constantin Mierla 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.
/O
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?
2:19 p.m.
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
2:34 p.m.
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
2:38 p.m.
On 10/22/12 8:19 PM, Juha Heinanen wrote:
Olle E. Johansson writes:
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
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.
2:09 p.m.
On 10/22/12 7:59 PM, Juha Heinanen wrote:
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) = 45
Then add 3 for the square brackets and the ending 0.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
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?
2:23 p.m.
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
2:29 p.m.
On 10/22/12 8:23 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..
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
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.
2:36 p.m.
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
2:46 p.m.
On 10/22/12 8:36 PM, Juha Heinanen wrote:
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Daniel-Constantin Mierla writes:
that's why I said ipv6 address representation.
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.
3:01 p.m.
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
3:29 p.m.
On 10/22/12 9:01 PM, Juha Heinanen wrote:
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Daniel-Constantin Mierla writes:
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.
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.
3:37 p.m.
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
25 Oct
25 Oct
3:27 a.m.
On 10/22/12 9:37 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Go ahead and add such entity.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
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.
22 Oct
22 Oct
2:45 p.m.
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) = 45
Then 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
4445
days inactive
4448
days old
19 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Richard Fuchs