[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Netflix banning HE tunnels



> 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