On 13 June 2016 at 10:56, Owen DeLong <owen@delong.com> wrote:
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.
No. That fails for the rule "as short as possible". It is a common misconception to shorten the first possible :: run, but that is not the rule. The same comment goes to the other person that came with a similar example. The rule not to shorten a single zero means that 2001:db8:0:1:1:1:1:1 can not be shorten to 2001:db8::1:1:1:1:1 even though that is actually one character shorter. The full set of rules from the RFC: 4.1 <https://tools.ietf.org/html/rfc5952#section-4.1>. Handling Leading Zeros in a 16-Bit Field Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1. A single 16- bit 0000 field MUST be represented as 0. 4.2 <https://tools.ietf.org/html/rfc5952#section-4.2>. "::" Usage 4.2.1 <https://tools.ietf.org/html/rfc5952#section-4.2.1>. Shorten as Much as Possible The use of the symbol "::" MUST be used to its maximum capability. For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1. Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce a shorter representation 2001:db8::1. 4.2.2 <https://tools.ietf.org/html/rfc5952#section-4.2.2>. Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. 4.2.3 <https://tools.ietf.org/html/rfc5952#section-4.2.3>. Choice in Placement of "::" When there is an alternative choice in the placement of a "::", the longest run of consecutive 16-bit 0 fields MUST be shortened (i.e., the sequence with three consecutive zero fields is shortened in 2001: 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct representation. 4.3 <https://tools.ietf.org/html/rfc5952#section-4.3>. Lowercase The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address MUST be represented in lowercase.
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?
It is hard to read binary integers dumped to a log file. Hence the need for a normalized format, so you can find what you need in the log file using simple unix tools.
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.
It is also hard to read binary IPv4 addresses in a log file. Other common places to find IPv4/IPv6 addresses is in configuration files, program code, emails etc. If you are going to apply a netmask or do any other computations, you will of course need to convert to binary regardless of protocol version. And then you will probably convert it back again to text before outputting the result, and in this step you should use the rules from RFC 5952. Regards, Baldur