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