nanog mailing list archives

Re: Netflix banning HE tunnels


From: Owen DeLong <owen () delong com>
Date: Mon, 13 Jun 2016 01:56:27 -0700


On Jun 12, 2016, at 18:27 , Baldur Norddahl <baldur.norddahl () gmail com> wrote:

On 13 June 2016 at 02:05, Owen DeLong <owen () 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


Current thread: