> On Jun 12, 2016, at 18:27 , Baldur Norddahl <baldur.nordd...@gmail.com> wrote: > > On 13 June 2016 at 02:05, Owen DeLong <o...@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
