Netflix banning HE tunnels
Owen DeLong
owen at delong.com
Mon Jun 13 09:22:21 UTC 2016
> On Jun 13, 2016, at 02:16 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>
> On 13 June 2016 at 10:56, Owen DeLong <owen at 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
More information about the NANOG
mailing list