Netflix banning HE tunnels

Baldur Norddahl baldur.norddahl at gmail.com
Mon Jun 13 09:16:58 UTC 2016


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.

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