YouTube AS36561 began announcing 1.0.0.0/8

Hello,

I'm hoping to alleviate the "what's going on!?" type messages here this time. :slight_smile:

Here's an except from the APNIC provided LOA I provided to a couple
networks, to carry a new announcement...

"To whom it may concern,

APNIC and YouTube are cooperating in a project to investigate the
properties of unwanted traffic that is being sent to specific
destinations in the address block of 1.0.0.0/8. This address block has
been recently allocated to APNIC from the IANA, and
APNIC and YouTube are wanting to undertake this investigation prior to
the commencement of ordinary allocations.
Accordingly, APNIC authorizes AS36351 to periodically advertise a
route for 1.0.0.0/8 from now until 21 March 2010, and
requests that AS36351's peers and upstreams accept this as a
legitimate routing advertisement."

In a continuation of last weeks experiments... we are now announcing
1.0.0.0/8 instead of 1.1.1.0/24 and 1.2.3.0/24.

Cheers
,N (nathan@youtube.com - AS36561)

<stupid question>
Any IPs we can ping and get a response back from to verify everything is
ok? 1.2.3.4 isn't pingable, for example. :frowning:
</stupid question>

William

Oh, I understand what's going on exactly. YouTube is trying to balance their ratios. :slight_smile:

Hello,

I'm hoping to alleviate the "what's going on!?" type messages here this time. :slight_smile:

<stupid question>
Any IPs we can ping and get a response back from to verify everything is
ok? 1.2.3.4 isn't pingable, for example. :frowning:
</stupid question>

we (nate/steve who're actually doing the work here, for geoff/george)
could probably light up something, but give it 48 hrs?

That might explain why they're only announcing it behind Cogent. :slight_smile:

A trace-route reaches the Youtube border... so everything is ok. The
routes are being ECMP'd to a set of capture hosts for the purpose of
spreading load, aggregating more disk-space for packets, providing
some form of redundancy for the experiment, etc. We're receiving about
175mbps of unsolicited noise. I'll leave the remaining details to be
provided by the official report/article from Geoff and George. Its
amazing how prolific 1.x traffic is.

,N

We've never cared about ratios... its futile!

Level3 is slow to update prefix lists this time. I simply picked a
couple networks that respond to my emails. My laziness to call others
is why the route isn't visible there. :slight_smile:

,N

one reason might also be, that at least T-Mobile Germany uses 1.2.3.*
for their proxies that deliver the content to mobile phones.
And I'm not sure what they are doing when they are going to receive this
route from external. :wink:

Axel Morawietz wrote:

Cisco has an interesting write-up on this:
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-3/103_awkward.html

Marla and I have drafted a document examining the issues associated with designating additional private address space:

http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-03

Please let us know if you have suggestions for improvements to the document.

Leo

There are sizable chunks that are fairly quiet (un-interesting
numbers, luck of the draw, etc). Given that its mostly
mis-configurations, laziness, ignorance, or poor planning... I suspect
the worst ranges will need to be sacrificed, and the remaining 80-90%
of the space used for legitimate allocations. Unfortunately, anyone
who accepts allocations in 1.x will need to be aware that they will
have a slightly lower quality address-space. Accepting 1.1.1.0/24,
for example, will land you with a continuous 50mbps of junk...
seemingly forever... and a respectable chance that some percentage of
the net will never reach you, due to their own misconfigurations.

,N

Axel Morawietz wrote:

[...] Its
amazing how prolific 1.x traffic is.

one reason might also be, that at least T-Mobile Germany uses 1.2.3.*
for their proxies that deliver the content to mobile phones.
And I'm not sure what they are doing when they are going to receive this
route from external. :wink:

If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, perhaps it is time to update rfc1918 to reflect this?

Only by people who don't know how to read RFC's and are probably responsible for screwing a bunch of other stuff up as well :slight_smile:

Brian

The same that they're going to do for all the other unassigned /8s
they're squatting on internally renumber, or blackhole them. every day I
check my phone and as long as I'm in the bay area it's in 14/8.