Netflix banning HE tunnels

Mon Jun 13 08:56:27 UTC 2016

> On Jun 12, 2016, at 18:27 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> On 13 June 2016 at 02:05, Owen DeLong <owen at delong.com> wrote:
> 
>> 2.      Consistent and easier comparisons for equality or ranges
>>                In iPv4, this was useful. In IPv6, it’s essential.
>> 
> 
> 
> You could also normalize your IPv6 text representation. There is even RFC
> 5952 for that. Abbreviated the rule is:
> 
> 1) lower case
> 2) as short as possible, except do not shorten just one :0: into ::.
> 3) if there is more than one possible :: block that results in the same
> shortest length, choose the first block as ::.
> 
> I am not quite sure why they put in the exception not to shorten one zero,
> but otherwise this is what most people would naturally come up with.

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.

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?

> 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.

Owen