On Jun 12, 2016, at 18:27 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 13 June 2016 at 02:05, Owen DeLong <owen@delong.com> wrote:
2. Consistent and easier comparisons for equality or ranges In iPv4, this was useful. In IPv6, it’s essential.
You could also normalize your IPv6 text representation. There is even RFC 5952 for that. Abbreviated the rule is:
1) lower case 2) as short as possible, except do not shorten just one :0: into ::. 3) if there is more than one possible :: block that results in the same shortest length, choose the first block as ::.
I am not quite sure why they put in the exception not to shorten one zero, but otherwise this is what most people would naturally come up with.
Actually, it isn’t. Consider the case of 2001:0:0::/48 and the resultant subnet 2001:0:0:406::/64. Now consider the static address of a host within that subnet 2001:0:0:406:0:0:0:302. Most people would naturally tend to write this as 2001:0:0:406::302. However, your ruleset would write it as 2001::406:0:0:0:302. Yes, you can use a standardized text representation, but the easiest way to produce this in most cases is to first convert to an integer then convert back to a representation of the integer. If you’re going to go to all the trouble to convert to an integer to begin with, isn’t it easier to just shovel things around as a 128-bit integer which has the advantage of also being fixed-length and more compact in memory?
Also, technically there is more than one IPv4 representation too. I have in the past poked security holes through this as most people forget (or don't know):
Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 PING 100000000 (5.245.225.0): 56 data bytes
Yes, I believe I made examples of those and stated that it made more sense to store IPv4 addresses as integers as well. Owen