nanog mailing list archives
Re: Netflix banning HE tunnels
From: Owen DeLong <owen () delong com>
Date: Mon, 13 Jun 2016 02:22:21 -0700
On Jun 13, 2016, at 02:16 , Baldur Norddahl <baldur.norddahl () gmail com> wrote: 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.
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 haveinthe past poked security holes through this as most people forget (ordon'tknow): Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000 PING 100000000 (5.245.225.0): 56 data bytesYes, 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
Current thread:
- Re: Netflix banning HE tunnels, (continued)
- Re: Netflix banning HE tunnels Mark Foster (Jun 09)
- Re: Netflix banning HE tunnels Mark Andrews (Jun 09)
- Re: Netflix banning HE tunnels tim () pelican org (Jun 09)
- Re: Netflix banning HE tunnels Valdis . Kletnieks (Jun 10)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 12)
- Re: Netflix banning HE tunnels Baldur Norddahl (Jun 12)
- Re: Netflix banning HE tunnels Mark Andrews (Jun 12)
- Re: Netflix banning HE tunnels Valdis . Kletnieks (Jun 12)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 13)
- Re: Netflix banning HE tunnels Baldur Norddahl (Jun 13)
- Re: Netflix banning HE tunnels Owen DeLong (Jun 13)
- Re: Netflix banning HE tunnels Baldur Norddahl (Jun 13)
- Re: Netflix banning HE tunnels Seth Mattinen (Jun 13)
- Re: Netflix banning HE tunnels Michael Brown (Jun 07)
- RE: Netflix banning HE tunnels Chuck Church (Jun 08)
- Re: Netflix banning HE tunnels chris (Jun 12)
- Re: Netflix banning HE tunnels Seth Mattinen (Jun 12)
- Re: Netflix banning HE tunnels Donn Lasher via NANOG (Jun 15)
- RE: Netflix banning HE tunnels Chuck Church (Jun 10)