[190011] in North American Network Operators' Group
Re: Netflix banning HE tunnels
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jun 13 05:22:29 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPkb-7BbVTRWkR=Nzpuq0bp-o9OXYRw92h5ze64VKYs0__3uRA@mail.gmail.com>
Date: Mon, 13 Jun 2016 02:22:21 -0700
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Jun 13, 2016, at 02:16 , Baldur Norddahl =
<baldur.norddahl@gmail.com> wrote:
>=20
> On 13 June 2016 at 10:56, Owen DeLong <owen@delong.com> wrote:
>=20
>> Actually, it isn=E2=80=99t.
>>=20
>> Consider the case of 2001:0:0::/48 and the resultant subnet
>> 2001:0:0:406::/64.
>>=20
>> Now consider the static address of a host within that subnet
>> 2001:0:0:406:0:0:0:302.
>>=20
>> Most people would naturally tend to write this as 2001:0:0:406::302.
>>=20
>> However, your ruleset would write it as 2001::406:0:0:0:302.
>>=20
>>=20
> 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.
>=20
> 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.
>=20
Fine=E2=80=A6 Consider 2001:0:0:406:0:0:5:302.
Owen
> The full set of rules from the RFC:
>=20
>=20
> 4.1 <https://tools.ietf.org/html/rfc5952#section-4.1>. Handling
> Leading Zeros in a 16-Bit Field
>=20
> 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
>=20
> 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
>=20
> 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 "::"
>=20
> 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
>=20
> The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
> MUST be represented in lowercase.
>=20
>=20
>=20
>=20
>> 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=E2=80=99re going to go to all the trouble to =
convert to an
>> integer to begin
>> with, isn=E2=80=99t 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?
>>=20
>=20
> 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.
>=20
>=20
>>=20
>>> 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):
>>>=20
>>> Baldurs-MacBook-Pro-2:~ baldur$ ping -c1 100000000
>>> PING 100000000 (5.245.225.0): 56 data bytes
>>=20
>> Yes, I believe I made examples of those and stated that it made more =
sense
>> to store
>> IPv4 addresses as integers as well.
>>=20
>=20
> It is also hard to read binary IPv4 addresses in a log file.
>=20
> Other common places to find IPv4/IPv6 addresses is in configuration =
files,
> program code, emails etc.
>=20
> 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.
>=20
> Regards,
>=20
> Baldur
