> On Jun 13, 2016, at 02:16 , Baldur Norddahl <baldur.nordd...@gmail.com> wrote: > > On 13 June 2016 at 10:56, Owen DeLong <o...@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. >
Fine… Consider 2001:0:0:406:0:0:5:302. Owen > 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
