From mike-nanog at tiedyenetworks.com  Sun May  1 13:07:56 2011
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sun, 01 May 2011 11:07:56 -0700
Subject: Amazon diagnosis
In-Reply-To: <BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
Message-ID: <4DBDA17C.2040303@tiedyenetworks.com>

On 04/29/2011 12:35 PM, Joly MacFie wrote:
> *http://aws.amazon.com/message/65648/*<http://aws.amazon.com/message/65648/>
>
> ___


So, in a nut shell, Amazon had a single point of failure which touched 
off this entire incident.

I am still waiting for proof that single points of failure can 
realistically be completely eliminated from any moderately complicated 
network environment / application. So far, I think murphy is still 
winning on this one.

Good job by the AWS team however, I am sure your new procedures and 
processes will receive a shakeout again, and it will be interesting to 
see how that goes. I bet there will be more to learn along this road for 
us all.

Mike-



From jra at baylink.com  Sun May  1 13:10:40 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 1 May 2011 14:10:40 -0400 (EDT)
Subject: Amazon diagnosis
In-Reply-To: <4DBDA17C.2040303@tiedyenetworks.com>
Message-ID: <15828685.467.1304273440150.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Mike" <mike-nanog at tiedyenetworks.com>

> On 04/29/2011 12:35 PM, Joly MacFie wrote:
> > *http://aws.amazon.com/message/65648/*<http://aws.amazon.com/message/65648/>
> 
> So, in a nut shell, Amazon had a single point of failure which touched
> off this entire incident.
> 
> I am still waiting for proof that single points of failure can
> realistically be completely eliminated from any moderately complicated
> network environment / application. So far, I think murphy is still
> winning on this one.

Well, in fairness to Amazon, let's ask this: did the failure occur *behind
a component interface they advertise as Reliable*?  Either way, was it possible
for a single customer to avoid that possible failure, and at what cost in
expansion of scope and money?

Cheers,
-- jra



From trelane at trelane.net  Sun May  1 13:18:47 2011
From: trelane at trelane.net (Andrew Kirch)
Date: Sun, 01 May 2011 14:18:47 -0400
Subject: Amazon diagnosis
In-Reply-To: <4DBDA17C.2040303@tiedyenetworks.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
Message-ID: <4DBDA407.1010002@trelane.net>

On 5/1/2011 2:07 PM, Mike wrote:
> I am still waiting for proof that single points of failure can
> realistically be completely eliminated from any moderately complicated
> network environment / application. So far, I think murphy is still
> winning on this one.

Sure they can, but as a thought exercise fully 2n redundancy is
difficult on a small scale for anything web facing.  I've seen a very
simple implementation for a website requiring 5 9's that consumed over
$50k in equipment, and this wasn't even geographically diverse.  I have
to believe that scaling up the concept of "doing it right" results in
exponential cost increases.  To illustrate the problem, I would give you
the first step in the thought exercise:  first find two datacenters with
diverse carriers, that aren't on the same regional power grid (As we've
learned in the (iirc) 2003 power outage, New York and DC won't work, nor
will Ohio, so you need redundant teams to cover a very remote site).



From jsw at inconcepts.biz  Sun May  1 14:29:54 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Sun, 1 May 2011 15:29:54 -0400
Subject: Amazon diagnosis
In-Reply-To: <4DBDA407.1010002@trelane.net>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
Message-ID: <BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>

On Sun, May 1, 2011 at 2:18 PM, Andrew Kirch <trelane at trelane.net> wrote:
> Sure they can, but as a thought exercise fully 2n redundancy is
> difficult on a small scale for anything web facing. ?I've seen a very
> simple implementation for a website requiring 5 9's that consumed over
> $50k in equipment, and this wasn't even geographically diverse. ?I have

What it really boils down to is this: if application developers are
doing their jobs, a given service can be easy and inexpensive to
distribute to unrelated systems/networks without a huge infrastructure
expense.  If the developers are not, you end up spending a lot of
money on infrastructure to make up for code, databases, and APIs which
were not designed with this in mind.

These same developers who do not design and implement services with
diversity and redundancy in mind will fare little better with AWS than
any other platform.  Look at Reddit, for example.  This is an
application/service which is utterly trivial to implement in a cheap,
distributed manner, yet they have failed to do so for years, and
suffer repeated, long-duration outages as a result.  They probably buy
a lot more AWS services than would otherwise be needed, and truly have
a more complex infrastructure than such a simple service should.

IT managers would do well to understand that a few smart programmers,
who understand how all their tools (web servers, databases,
filesystems, load-balancers, etc.) actually work, can often do more to
keep infrastructure cost under control, and improve the reliability of
services, than any other investment in IT resources.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From gbonser at seven.com  Sun May  1 14:50:37 2011
From: gbonser at seven.com (George Bonser)
Date: Sun, 1 May 2011 12:50:37 -0700
Subject: Amazon diagnosis
In-Reply-To: <4DBDA17C.2040303@tiedyenetworks.com>
References: <602316126.1304085701368.JavaMail.nobody@james2><BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3031@RWC-EX1.corp.seven.com>

> I am still waiting for proof that single points of failure can
> realistically be completely eliminated from any moderately complicated
> network environment / application. So far, I think murphy is still
> winning on this one.
> 
> Good job by the AWS team however, I am sure your new procedures and
> processes will receive a shakeout again, and it will be interesting to
> see how that goes. I bet there will be more to learn along this road
> for
> us all.
> 
> Mike-

>From my reading of what happened, it looks like they didn't have a
single point of failure but ended up routing around their own
redundancy.

They apparently had a redundant primary network and, on top of that, a
secondary network.  The secondary network, however, did not have the
capacity of the primary network.

Rather than failing over from the active portion of the primary network
to the standby portion of the primary network, they inadvertently failed
the entire primary network to the secondary.  This resulted in the
secondary network reaching saturation and becoming unusable.

There isn't anything that can be done to mitigate against human error.
You can TRY, but as history shows us, it all boils down the human that
implements the procedure.  All the redundancy in the world will not do
you an iota of good if someone explicitly does the wrong thing.  In this
case it is my opinion that Amazon should not have considered their
secondary network to be a true secondary if it was not capable of
handling the traffic.  A completely broken network might have been an
easier failure mode to handle than a saturated network (high packet loss
but the network is "there").

This looks like it was a procedural error and not an architectural
problem.  They seem to have had standby capability on the primary
network and, from the way I read their statement, did not use it.





From paul at paulgraydon.co.uk  Sun May  1 15:03:49 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Sun, 01 May 2011 10:03:49 -1000
Subject: Amazon diagnosis
In-Reply-To: <BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>	<4DBDA17C.2040303@tiedyenetworks.com>	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
Message-ID: <4DBDBCA5.9000107@paulgraydon.co.uk>

On 5/1/2011 9:29 AM, Jeff Wheeler wrote:
> On Sun, May 1, 2011 at 2:18 PM, Andrew Kirch<trelane at trelane.net>  wrote:
>> Sure they can, but as a thought exercise fully 2n redundancy is
>> difficult on a small scale for anything web facing.  I've seen a very
>> simple implementation for a website requiring 5 9's that consumed over
>> $50k in equipment, and this wasn't even geographically diverse.  I have
> What it really boils down to is this: if application developers are
> doing their jobs, a given service can be easy and inexpensive to
> distribute to unrelated systems/networks without a huge infrastructure
> expense.  If the developers are not, you end up spending a lot of
> money on infrastructure to make up for code, databases, and APIs which
> were not designed with this in mind.
>
> These same developers who do not design and implement services with
> diversity and redundancy in mind will fare little better with AWS than
> any other platform.  Look at Reddit, for example.  This is an
> application/service which is utterly trivial to implement in a cheap,
> distributed manner, yet they have failed to do so for years, and
> suffer repeated, long-duration outages as a result.  They probably buy
> a lot more AWS services than would otherwise be needed, and truly have
> a more complex infrastructure than such a simple service should.
>
> IT managers would do well to understand that a few smart programmers,
> who understand how all their tools (web servers, databases,
> filesystems, load-balancers, etc.) actually work, can often do more to
> keep infrastructure cost under control, and improve the reliability of
> services, than any other investment in IT resources.
If you want a perfect example of this, consider Netflix.  Their 
infrastructure runs on AWS and we didn't see any downtime with them 
throughout the entire affair.
One of the interesting things they've done to try and enforce 
reliability of services is an in house service called Chaos Monkey who's 
sole purpose is to randomly kill instances and services inside the 
infrastructure.  Courtesy of Chaos Monkey and the defensive programming 
it enforces, nothing is dependent on each other, you will always get at 
least some form of a service.  For example if the recommendation engine 
dies, then the application is smart enough to catch that and instead 
return a list of the most popular movies, and so on.  There is an 
interesting blog from their Director of Engineering about what they 
learned on their migration to AWS, including using less chatty APIs to 
reduce the impact of typical AWS latency:
http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

Paul



From rbf+nanog at panix.com  Sun May  1 15:32:07 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Sun, 1 May 2011 15:32:07 -0500
Subject: Amazon diagnosis
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3031@RWC-EX1.corp.seven.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3031@RWC-EX1.corp.seven.com>
Message-ID: <20110501203207.GA4959@panix.com>

On Sun, May 01, 2011 at 12:50:37PM -0700, George Bonser wrote:
> 
> From my reading of what happened, it looks like they didn't have a
> single point of failure but ended up routing around their own
> redundancy.
> 
> They apparently had a redundant primary network and, on top of that, a
> secondary network.  The secondary network, however, did not have the
> capacity of the primary network.
> 
> Rather than failing over from the active portion of the primary network
> to the standby portion of the primary network, they inadvertently failed
> the entire primary network to the secondary.  This resulted in the
> secondary network reaching saturation and becoming unusable.
> 
> There isn't anything that can be done to mitigate against human error.
> You can TRY, but as history shows us, it all boils down the human that
> implements the procedure.  All the redundancy in the world will not do
> you an iota of good if someone explicitly does the wrong thing.
>   [ ... ]
> 
> This looks like it was a procedural error and not an architectural
> problem.  They seem to have had standby capability on the primary
> network and, from the way I read their statement, did not use it.

The procedural error was putting all the traffic on the secondary
network.  They promptly recognized that error, and fixed it.  It's
certainly true that you can't eliminate human error.

The architectural problem is that they had insufficient error recovery
capability.  Initially, the system was trying to use a network that was
too small; that situation lasted for some number of minutes; it's no
surprise that the system couldn't operate under those conditions and
that isn't an indictment of the architecture.  However, after they put
it back on a network that wasn't too small, the service stayed
down/degraded for many, many hours.  That's an architectural problem. 
(And a very common one.  Error recovery is hard and tedious and more
often than not, not done well.)

Prodecural error isn't the only way to get into that boat.  If the
wrong pair of redundant equipment in their primary network failed
simultanesouly, they'd have likely found themselves in the same boat: a
short outage caused by a risk they accepted: loss of a pair of
rundundant hardware; followed by a long outage (after they restored the
network) caused by insufficient recovery capability.

Their writeup suggests they fully understand these issues and are doing
the right thing by seeking to have better recovery capability.  They
spent one sentence saying they'll look at their procedures to reduce
the risk of a similar procedural error in the future, and then spent
paragraphs on what they are going to do to have better recovery should
something like this occur in the future.

(One additional comment, for whoever posted that NetFlix had a better
architecture and wasn't impacted by this outage.  It might well be that
NetFlix does have a better archiecture and that might be why they
weren't impacted ... but there's also the possibility that they just
run in a different region.  Lots of entities with poor architecture
running on AWS survived this outage just fine, simply by not being in
the region that had the problem.)

     -- Brett



From bonomi at mail.r-bonomi.com  Sun May  1 16:22:04 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 1 May 2011 16:22:04 -0500 (CDT)
Subject: Amazon diagnosis
In-Reply-To: <4DBDA17C.2040303@tiedyenetworks.com>
Message-ID: <201105012122.p41LM4b0053184@mail.r-bonomi.com>


> Date: Sun, 01 May 2011 11:07:56 -0700
> From: Mike <mike-nanog at tiedyenetworks.com>
> To: nanog at nanog.org
> Subject: Re: Amazon diagnosis
>
> On 04/29/2011 12:35 PM, Joly MacFie wrote:
> > http://aws.amazon.com/message/65648/
> >
> > ___
>
>
> So, in a nut shell, Amazon had a single point of failure which touched 
> off this entire incident.
>
> I am still waiting for proof that single points of failure can 
> realistically be completely eliminated from any moderately complicated 
> network environment / application. So far, I think murphy is still 
> winning on this one.

this was a classical case of _O'Brien's_Law_ in action -- which states,
rather pithily: 

    "Murphy...
    
     was an OPTIMIST!!"





From Valdis.Kletnieks at vt.edu  Sun May  1 16:28:33 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 01 May 2011 17:28:33 -0400
Subject: Amazon diagnosis
In-Reply-To: Your message of "Sun, 01 May 2011 11:07:56 PDT."
	<4DBDA17C.2040303@tiedyenetworks.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
Message-ID: <42779.1304285313@localhost>

On Sun, 01 May 2011 11:07:56 PDT, Mike said:

> I am still waiting for proof that single points of failure can 
> realistically be completely eliminated from any moderately complicated 
> network environment / application. So far, I think murphy is still 
> winning on this one.

For starters, you almost always screw up and have one NOC full of
chuckle-headed banana eaters. And if you have two NOCs, that implies
one entity deciding which one takes lead on a problem. ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110501/fcc3395d/attachment.bin>

From bonomi at mail.r-bonomi.com  Sun May  1 16:35:29 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 1 May 2011 16:35:29 -0500 (CDT)
Subject: Amazon diagnosis
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3031@RWC-EX1.corp.seven.com>
Message-ID: <201105012135.p41LZTjH053244@mail.r-bonomi.com>


> Subject: RE: Amazon diagnosis
> Date: Sun, 1 May 2011 12:50:37 -0700
> From: George Bonser <gbonser at seven.com>
>
> They apparently had a redundant primary network and, on top of that, a
> secondary network.  The secondary network, however, did not have the
> capacity of the primary network.
>
> Rather than failing over from the active portion of the primary network
> to the standby portion of the primary network, they inadvertently failed
> the entire primary network to the secondary.  This resulted in the
> secondary network reaching saturation and becoming unusable.
>
> There isn't anything that can be done to mitigate against human error.
> You can TRY, but as history shows us, it all boils down the human that
> implements the procedure.  All the redundancy in the world will not do
> you an iota of good if someone explicitly does the wrong thing.  ...
>
> This looks like it was a procedural error and not an architectural
> problem.  

A sage sayeth sooth: 

      "For any 'fool-proof' system, there exists 
       a *sufficiently*determied* fool capable of
       breaking it."

It would seem that the validity of that has just been re-confirmed.  <wry grin>


It is worthy of note that it is considerably harder to protect against
accidental stupidity than it is to protect againt intentional malice.
('malice' is _much_ more predictable, in general.  <wry grin>)





From netfortius at gmail.com  Sun May  1 17:59:52 2011
From: netfortius at gmail.com (Stefan)
Date: Sun, 1 May 2011 17:59:52 -0500
Subject: Amazon diagnosis
In-Reply-To: <BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
Message-ID: <BANLkTikAd2uJxaPEn=0n0cMdPGkor6USfA@mail.gmail.com>

On Fri, Apr 29, 2011 at 2:35 PM, Joly MacFie <joly at punkcast.com> wrote:
> *http://aws.amazon.com/message/65648/*<http://aws.amazon.com/message/65648/>
>
> ___
> --
> ---------------------------------------------------------------
> Joly MacFie ?218 565 9365 Skype:punkcast
> WWWhatsup NYC - http://wwwhatsup.com
> ?http://pinstand.com - http://punkcast.com
> ?VP (Admin) - ISOC-NY - http://isoc-ny.org
> --------------------------------------------------------------
> -
>

http://storagemojo.com/2011/04/29/amazons-ebs-outage/

***Stefan Mititelu
http://twitter.com/netfortius
http://www.linkedin.com/in/netfortius



From david.oramas at aptel.com.au  Sun May  1 20:42:28 2011
From: david.oramas at aptel.com.au (David Oramas)
Date: Mon, 2 May 2011 11:42:28 +1000
Subject: Multitenant FWs
Message-ID: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>

Hi,
What do you guys recommend for Multitenant Firewalls with support for over 1,000+ users/contexts?
I have looked at Centrinet's Accessmanager and Barracuda NG Firewall. Any other players/products?
Many Thanks in advance for the input,





From MGauvin at dryden.ca  Sun May  1 20:46:25 2011
From: MGauvin at dryden.ca (Mark Gauvin)
Date: Sun, 1 May 2011 20:46:25 -0500
Subject: Multitenant FWs
In-Reply-To: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>
References: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>
Message-ID: <4DEA063ACE629740877D59B74D6FB26423FF0E0B7B@exchange.citydryden.local>

Paloalto Networks build some nice gear
________________________________________
From: David Oramas [david.oramas at aptel.com.au]
Sent: Sunday, May 01, 2011 8:42 PM
To: nanog at nanog.org
Subject: Multitenant FWs

Hi,
What do you guys recommend for Multitenant Firewalls with support for over 1,000+ users/contexts?
I have looked at Centrinet's Accessmanager and Barracuda NG Firewall. Any other players/products?
Many Thanks in advance for the input,






From sfouant at shortestpathfirst.net  Sun May  1 22:05:48 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Sun, 1 May 2011 23:05:48 -0400
Subject: Multitenant FWs
In-Reply-To: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>
References: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>
Message-ID: <009f01cc0875$d75d3ef0$8617bcd0$@net>

> -----Original Message-----
> From: David Oramas [mailto:david.oramas at aptel.com.au]
> Sent: Sunday, May 01, 2011 9:42 PM
> To: nanog at nanog.org
> Subject: Multitenant FWs
> 
> Hi,
> What do you guys recommend for Multitenant Firewalls with support for
> over 1,000+ users/contexts?
> I have looked at Centrinet's Accessmanager and Barracuda NG Firewall.
> Any other players/products?
> Many Thanks in advance for the input,

When I worked on building out Verizon's Network Based Firewall solution many
years ago, I chose Juniper NS-5400 platforms due to their multitenancy
capabilities and ability to support literally thousands of virtual firewall
contexts and many times that for users.  This decision was made after an
exhaustive analysis of competing solutions from Checkpoint, Cisco, and
Juniper.  Juniper's SRX line of products might make a good fit, but they
currently don't have full Logical System support which would certainly be a
requirement for any multi-tenant offering.  However, Logical System support
is on the roadmap so you might want to look into this depending on your
timeframe for deployment.

As the other list member pointed out, Palo Alto does make some really nice
gear and I have really been impressed with their Application Layer
Firewalling capability (Application Identification, Web Firewalling, etc),
however, I was suitably unimpressed with their multitenant capability and
think you might be hard pressed to offer such an offering to more than one
customer using such a device. 

Stefan Fouant





From morrowc.lists at gmail.com  Sun May  1 22:56:31 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 1 May 2011 23:56:31 -0400
Subject: Multitenant FWs
In-Reply-To: <009f01cc0875$d75d3ef0$8617bcd0$@net>
References: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>
	<009f01cc0875$d75d3ef0$8617bcd0$@net>
Message-ID: <BANLkTiky6kNvEetSkqjpe2_-WbCA=QMOSg@mail.gmail.com>

On Sun, May 1, 2011 at 11:05 PM, Stefan Fouant
<sfouant at shortestpathfirst.net> wrote:
>> -----Original Message-----
>> From: David Oramas [mailto:david.oramas at aptel.com.au]
>> Sent: Sunday, May 01, 2011 9:42 PM
>> To: nanog at nanog.org
>> Subject: Multitenant FWs
>>
>> Hi,
>> What do you guys recommend for Multitenant Firewalls with support for
>> over 1,000+ users/contexts?
>> I have looked at Centrinet's Accessmanager and Barracuda NG Firewall.
>> Any other players/products?
>> Many Thanks in advance for the input,

one thing to keep in mind is that as near as I can tell no vendor (not
a singl eone) has actual hard limits configurable for each tenant
firewall instance. So, one can use all of the 'firewall rule'
resources, one can use all of the 'route memory' ... leaving other
instances flailing :(

In my mind, unless you have very loose sla's or are highly
overprovisioned... until vendors treat this basic problem this model
is a failure.

> When I worked on building out Verizon's Network Based Firewall solution many
> years ago, I chose Juniper NS-5400 platforms due to their multitenancy
> capabilities and ability to support literally thousands of virtual firewall
> contexts and many times that for users. ?This decision was made after an

yup.. too bad no actual customers showed up :( (well, not any in real
numbers... though not due to the tech on the FW side, nor the
engineering work)

> As the other list member pointed out, Palo Alto does make some really nice
> gear and I have really been impressed with their Application Layer
> Firewalling capability (Application Identification, Web Firewalling, etc),
> however, I was suitably unimpressed with their multitenant capability and
> think you might be hard pressed to offer such an offering to more than one
> customer using such a device.

no support for actual limits on resources, eh? :( nothing on at least:

memory dedicated to a tenant
routing resources
packet processing resources
inspection rule resources
bandwidth/through-put
management operations

(I'm sure I left some off, but the above would be an excellent thing
to see vendors support with hard limits THAT I CAN CONFIGURE!!)

-chris



From sfouant at shortestpathfirst.net  Sun May  1 23:20:55 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 2 May 2011 00:20:55 -0400
Subject: Multitenant FWs
In-Reply-To: <BANLkTiky6kNvEetSkqjpe2_-WbCA=QMOSg@mail.gmail.com>
References: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>	<009f01cc0875$d75d3ef0$8617bcd0$@net>
	<BANLkTiky6kNvEetSkqjpe2_-WbCA=QMOSg@mail.gmail.com>
Message-ID: <00c301cc0880$55526100$fff72300$@net>

> -----Original Message-----
> From: christopher.morrow at gmail.com
> [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
> 
> one thing to keep in mind is that as near as I can tell no vendor (not
> a singl eone) has actual hard limits configurable for each tenant
> firewall instance. So, one can use all of the 'firewall rule'
> resources, one can use all of the 'route memory' ... leaving other
> instances flailing :(

Ahem, actually ScreenOS does support just such a thing through the use of
resource profiles - with this you can limit the amount of CPU, Sessions,
Policies, MIPs and DIPs (used for NAT), and other user defined objects such
as address book entries, etc. that each VSYS can avail.  This was one of the
primary drivers behind our decision to utilize the NS-5400 for Verizon's
NBFW (you remember that place right Chris, heh')

Stefan Fouant





From morrowc.lists at gmail.com  Mon May  2 00:35:46 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 2 May 2011 01:35:46 -0400
Subject: Multitenant FWs
In-Reply-To: <00c301cc0880$55526100$fff72300$@net>
References: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>
	<009f01cc0875$d75d3ef0$8617bcd0$@net>
	<BANLkTiky6kNvEetSkqjpe2_-WbCA=QMOSg@mail.gmail.com>
	<00c301cc0880$55526100$fff72300$@net>
Message-ID: <BANLkTik+i6YVN=X9jn4PTtr1WAV-kEhjXg@mail.gmail.com>

On Mon, May 2, 2011 at 12:20 AM, Stefan Fouant
<sfouant at shortestpathfirst.net> wrote:
>> -----Original Message-----
>> From: christopher.morrow at gmail.com
>> [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
>>
>> one thing to keep in mind is that as near as I can tell no vendor (not
>> a singl eone) has actual hard limits configurable for each tenant
>> firewall instance. So, one can use all of the 'firewall rule'
>> resources, one can use all of the 'route memory' ... leaving other
>> instances flailing :(
>
> Ahem, actually ScreenOS does support just such a thing through the use of
> resource profiles - with this you can limit the amount of CPU, Sessions,
> Policies, MIPs and DIPs (used for NAT), and other user defined objects such
> as address book entries, etc. that each VSYS can avail. ?This was one of the

good to know... I wonder how well it isolates.

> primary drivers behind our decision to utilize the NS-5400 for Verizon's
> NBFW (you remember that place right Chris, heh')

i do, occasionally via the twitching :)

> Stefan Fouant
>
>
>



From sfouant at shortestpathfirst.net  Mon May  2 00:40:55 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 2 May 2011 01:40:55 -0400
Subject: Multitenant FWs
In-Reply-To: <BANLkTik+i6YVN=X9jn4PTtr1WAV-kEhjXg@mail.gmail.com>
References: <83AD98028495F940A7228E43CEC97D860473D0F62F@APMAIL.1QR.COM.AU>	<009f01cc0875$d75d3ef0$8617bcd0$@net>	<BANLkTiky6kNvEetSkqjpe2_-WbCA=QMOSg@mail.gmail.com>	<00c301cc0880$55526100$fff72300$@net>
	<BANLkTik+i6YVN=X9jn4PTtr1WAV-kEhjXg@mail.gmail.com>
Message-ID: <00d501cc088b$8290b620$87b22260$@net>

> -----Original Message-----
> From: christopher.morrow at gmail.com
> [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
> >
> > Ahem, actually ScreenOS does support just such a thing through the
> use of
> > resource profiles - with this you can limit the amount of CPU,
> Sessions,
> > Policies, MIPs and DIPs (used for NAT), and other user defined
> objects such
> > as address book entries, etc. that each VSYS can avail. ?This was one
> of the
> 
> good to know... I wonder how well it isolates.

Ask the Vz marketing folks... oh, wait, 1 customer isn't really enough to
demonstrate how well it isolates after all I guess ;)

> > primary drivers behind our decision to utilize the NS-5400 for
> Verizon's
> > NBFW (you remember that place right Chris, heh')
> 
> i do, occasionally via the twitching :)

Hehe...

Stefan Fouant





From arien+nanog at ams-ix.net  Mon May  2 03:26:50 2011
From: arien+nanog at ams-ix.net (Arien Vijn)
Date: Mon, 2 May 2011 10:26:50 +0200
Subject: Wire-rate Packet Capture on 10gbE
In-Reply-To: <DF7BBBEE-F391-45C2-84BB-B173C06938F1@ams-ix.net>
References: <BANLkTimr+sFRHXOpDD5pSB4ZP=W6+f-bnA@mail.gmail.com>
	<DF7BBBEE-F391-45C2-84BB-B173C06938F1@ams-ix.net>
Message-ID: <6ED358E5-8F10-43F0-A974-13AFEC298619@ams-ix.net>


On 29 Apr 2011 (18), at 3:59 PM, Attilla de Groot wrote:

> 
> On Apr 29, 2011, at 3:55 PM, Kyle Creyts wrote:
> 
>> How is this being done? I've looked at looked at PF_RING and TNAPI... is
>> there anything better out there?
> 
> http://events.ccc.de/congress/2006/Fahrplan/attachments/1225-23c3-slides-av.pdf
> 
> That should give you some answers. :-)

The paper that I wrote for this talk might give you a bit more information than the just the slides:

http://events.ccc.de/congress/2006/Fahrplan/attachments/1153-23C3_ArienVijn.pdf

This solution filters at full line rate. I am happy to tell more if you are interested.

-- Arien







From dsparro at gmail.com  Mon May  2 09:11:34 2011
From: dsparro at gmail.com (David Sparro)
Date: Mon, 02 May 2011 10:11:34 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <201104300057.p3U0vgg2039413@mail.r-bonomi.com>
References: <201104300057.p3U0vgg2039413@mail.r-bonomi.com>
Message-ID: <4DBEBB96.3030404@gmail.com>

On 4/29/2011 8:57 PM, Robert Bonomi wrote:
> Those royalties are based on the_actual_number_  of persons
> tuning in to each such work.  No 'averaging', no 'estimating', nothing
> based on 'ratings', or other 'sampling techniques -- you have to count
> the_actual_number_  of people tuned in.  It gets messy, but you have to
> have 'auditable' records of when each person 'tuned in', and when they
> 'tuned out'.  One_has_  to be able to detect the latter condition under
> all possible circumstances.

Really?  How do they detect the number of people that were gathered 
around my screen while I was watching?
Does that mean I'll be able to get a refund (pro-rated of course) for 
falling asleep during UFC 129 this weekend?

-- 
Dave



From straterra at fuhell.com  Mon May  2 09:12:41 2011
From: straterra at fuhell.com (Thomas York)
Date: Mon, 2 May 2011 10:12:41 -0400
Subject: Bright House residential IPv6
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAADyRgjJeItxBrNW6QTBSBKkBAAAAAA==@fuhell.com>

I'm a new Bright House residential customer and I have their new 40/5
'Lightning' service, which is rumored to have free native IPv6. I've called
them, but of course no one I talked to knew anything about IPv6. Do any of
you have this service and have native? If you do, what did you do to get it
activated for your line?

 

 

Thomas York

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6400 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110502/9863566a/attachment.bin>

From dwhite at olp.net  Mon May  2 10:08:32 2011
From: dwhite at olp.net (Dan White)
Date: Mon, 2 May 2011 10:08:32 -0500
Subject: Summary: Youtube Geolocation
Message-ID: <20110502150832.GE15032@dan.olp.net>

A couple of weeks ago, I posted (http://tinyurl.com/3btmf55) the following
question to the list asking for assistance:

>We're experiencing very poor quality with You Tube, and it appears we're
>subject to a bad entry within a geolocation database somewhere.
>
>When we attempt to view videos, the contact comes back to us from IPs
>like:
>
>208.117.226.21 (traceroute's through Frankfurt)
>173.194.50.47
>74.125.100.29
>
>All of those IPs are >125ms away from us (67.217.144.0/20, and
>216.14.144.0/20).
>
>However, we've never experienced redirection problems with Google before
>(we always land at www.google.com), so I'm not sure where to take our
>trouble.
>
>The page at:
>
>http://www.google.com/support/websearch/bin/request.py?contact_type=ip
>
>isn't of much help as it assumes the problem is google.com redirection.
>
>Are there any contacts at Youtube who could provide some assistance?

And received the following comments on and off list:

Carl Rosevear confirmed that he had experienced the same issue, and had
been attempting to work through the problem for some time.

Mike Schoenfeld suggested verifying the information at:
http://www.quova.com/what/request-ip-update/

Harry Strongburg posted that he had experienced similar problem over IPv6,
and suggested increasing MTU values as a possible fix.

Aaron Hopkins, Blake Hudson, and a private response, pointed towards DNS
resolution as being a possible problem.

I received private contact from a Google engineer requesting more
information.

The following test was used to confirm that the issue was indeed due to a
DNS resolution problem:

dig +trace v1.lscache1.c.youtube.com.
ping <returned IP>
traceroute <returned IP>

While the problem was happening, v1.lscache1.c.youtube.com resolved to an
address that was 129ms and 12 hops away from our network.

With the assistance of irc://irc.freenode.net/#bind, we instituted the
following temporary work around within our local resolvers, which provided
instant relief for our end-users:

zone "youtube.com" {
         type forward;
         forwarders { x.x.x.x; };
};

Where x.x.x.x is a geographically-near nameserver of one of our upstream
providers.

As of this morning, we have noticed that the problem has been resolved, and
we've removed the temporary workaround within our local resolvers. It took
approximately 2 weeks to achieve a resolution on this issue, which is
within the time frame indicated here:

http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873

After this fix, v1.lscache1.c.youtube.com is now resolving to an address
that's about 8ms and 6 hops away from our network.

I'd like to publicly thank those responsible for correcting this problem,
and for all those offering sympathy and tips for trouble shooting.

-- 
Dan White



From bill at herrin.us  Mon May  2 11:01:06 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 2 May 2011 12:01:06 -0400
Subject: trouble with .gov dns?
Message-ID: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>

Hi Folks,

Anyone else having trouble with .gov DNS failing with edns-udp-size set to 512?

Here's what I'm seeing:

No edns-udp-size setting.
tcpdump -n -s 0 -vv -i eth1 host 209.112.123.30 or host 69.36.157.30
nslookup www.nsf.gov 127.0.0.1

11:42:36.574916 IP (tos 0x0, ttl 64, id 21833, offset 0, flags [none],
proto UDP (17), length 68) 71.246.241.146.10399 > 69.36.157.30.53:
[udp sum ok] 56983 [1au] A? www.nsf.gov. ar: . OPT UDPsize=4096 OK
(40)
11:42:36.659636 IP (tos 0x0, ttl 249, id 54334, offset 0, flags
[none], proto UDP (17), length 598) 69.36.157.30.53 >
71.246.241.146.10399: [udp sum ok] 56983- q: A? www.nsf.gov. 0/7/5 ns:
nsf.gov. NS swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov. NS
cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS, nsf.gov.
DS, nsf.gov. RRSIG ar: swirl.nsf.gov. A 198.181.231.15, whirl.nsf.gov.
A 198.181.231.16, cyclone.nsf.gov. A 204.14.134.227, twister.nsf.gov.
A 198.181.231.17, . OPT UDPsize=1472 (570)

edns-udp-size 512
tcpdump -n -s 0 -vv -i eth1 host 209.112.123.30 or host 69.36.157.30
nslookup www.nsf.gov 127.0.0.1
11:53:01.604105 IP (tos 0x0, ttl 64, id 21834, offset 0, flags [none],
proto UDP (17), length 68) 71.246.241.146.58103 > 69.36.157.30.53:
[udp sum ok] 10320 [1au] A? www.nsf.gov. ar: . OPT UDPsize=512 OK (40)
11:53:01.690414 IP (tos 0x0, ttl 249, id 28744, offset 0, flags
[none], proto UDP (17), length 534) 69.36.157.30.53 >
71.246.241.146.58103: [udp sum ok] 10320- q: A? www.nsf.gov. 0/7/1 ns:
nsf.gov. NS swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov. NS
cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS, nsf.gov.
DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (506)
11:53:01.695000 IP (tos 0x0, ttl 64, id 20662, offset 0, flags [none],
proto UDP (17), length 70) 71.246.241.146.23911 > 209.112.123.30.53:
[udp sum ok] 18982% [1au] A? whirl.nsf.gov. ar: . OPT UDPsize=512 OK
(42)
11:53:01.695489 IP (tos 0x0, ttl 64, id 20663, offset 0, flags [none],
proto UDP (17), length 70) 71.246.241.146.63892 > 209.112.123.30.53:
[udp sum ok] 3675% [1au] AAAA? whirl.nsf.gov. ar: . OPT UDPsize=512 OK
(42)
11:53:01.695931 IP (tos 0x0, ttl 64, id 20664, offset 0, flags [none],
proto UDP (17), length 70) 71.246.241.146.37019 > 209.112.123.30.53:
[udp sum ok] 36777% [1au] A? swirl.nsf.gov. ar: . OPT UDPsize=512 OK
(42)
11:53:01.696274 IP (tos 0x0, ttl 64, id 20665, offset 0, flags [none],
proto UDP (17), length 70) 71.246.241.146.15021 > 209.112.123.30.53:
[udp sum ok] 13755% [1au] AAAA? swirl.nsf.gov. ar: . OPT UDPsize=512
OK (42)
11:53:01.696653 IP (tos 0x0, ttl 64, id 20666, offset 0, flags [none],
proto UDP (17), length 72) 71.246.241.146.38082 > 209.112.123.30.53:
[udp sum ok] 14449% [1au] A? cyclone.nsf.gov. ar: . OPT UDPsize=512 OK
(44)
11:53:01.697045 IP (tos 0x0, ttl 64, id 20667, offset 0, flags [none],
proto UDP (17), length 72) 71.246.241.146.28219 > 209.112.123.30.53:
[udp sum ok] 38858% [1au] AAAA? cyclone.nsf.gov. ar: . OPT UDPsize=512
OK (44)
11:53:01.699294 IP (tos 0x0, ttl 64, id 20668, offset 0, flags [none],
proto UDP (17), length 72) 71.246.241.146.50745 > 209.112.123.30.53:
[udp sum ok] 53248% [1au] A? twister.nsf.gov. ar: . OPT UDPsize=512 OK
(44)
11:53:01.700257 IP (tos 0x0, ttl 64, id 20669, offset 0, flags [none],
proto UDP (17), length 72) 71.246.241.146.21482 > 209.112.123.30.53:
[udp sum ok] 56185% [1au] AAAA? twister.nsf.gov. ar: . OPT UDPsize=512
OK (44)
11:53:01.780833 IP (tos 0x0, ttl 251, id 9453, offset 0, flags [none],
proto UDP (17), length 536) 209.112.123.30.53 > 71.246.241.146.23911:
[udp sum ok] 18982- q: A? whirl.nsf.gov. 0/7/1 ns: nsf.gov. NS
swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov. NS
cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS, nsf.gov.
DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (508)
11:53:01.781284 IP (tos 0x0, ttl 251, id 24142, offset 0, flags
[none], proto UDP (17), length 536) 209.112.123.30.53 >
71.246.241.146.63892: [udp sum ok] 3675- q: AAAA? whirl.nsf.gov. 0/7/1
ns: nsf.gov. NS swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov.
NS cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS,
nsf.gov. DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (508)
11:53:01.781999 IP (tos 0x0, ttl 251, id 9454, offset 0, flags [none],
proto UDP (17), length 536) 209.112.123.30.53 > 71.246.241.146.37019:
[udp sum ok] 36777- q: A? swirl.nsf.gov. 0/7/1 ns: nsf.gov. NS
swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov. NS
cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS, nsf.gov.
DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (508)
11:53:01.782136 IP (tos 0x0, ttl 251, id 24143, offset 0, flags
[none], proto UDP (17), length 536) 209.112.123.30.53 >
71.246.241.146.15021: [udp sum ok] 13755- q: AAAA? swirl.nsf.gov.
0/7/1 ns: nsf.gov. NS swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov.,
nsf.gov. NS cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov.
DS, nsf.gov. DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (508)
11:53:01.782552 IP (tos 0x0, ttl 251, id 9455, offset 0, flags [none],
proto UDP (17), length 538) 209.112.123.30.53 > 71.246.241.146.38082:
[udp sum ok] 14449- q: A? cyclone.nsf.gov. 0/7/1 ns: nsf.gov. NS
swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov. NS
cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS, nsf.gov.
DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (510)
11:53:01.782937 IP (tos 0x0, ttl 251, id 24144, offset 0, flags
[none], proto UDP (17), length 538) 209.112.123.30.53 >
71.246.241.146.28219: [udp sum ok] 38858- q: AAAA? cyclone.nsf.gov.
0/7/1 ns: nsf.gov. NS swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov.,
nsf.gov. NS cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov.
DS, nsf.gov. DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (510)
11:53:01.785168 IP (tos 0x0, ttl 251, id 9456, offset 0, flags [none],
proto UDP (17), length 538) 209.112.123.30.53 > 71.246.241.146.50745:
[udp sum ok] 53248- q: A? twister.nsf.gov. 0/7/1 ns: nsf.gov. NS
swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov., nsf.gov. NS
cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov. DS, nsf.gov.
DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (510)
11:53:01.786251 IP (tos 0x0, ttl 251, id 24145, offset 0, flags
[none], proto UDP (17), length 538) 209.112.123.30.53 >
71.246.241.146.21482: [udp sum ok] 56185- q: AAAA? twister.nsf.gov.
0/7/1 ns: nsf.gov. NS swirl.nsf.gov., nsf.gov. NS whirl.nsf.gov.,
nsf.gov. NS cyclone.nsf.gov., nsf.gov. NS twister.nsf.gov., nsf.gov.
DS, nsf.gov. DS, nsf.gov. RRSIG ar: . OPT UDPsize=1472 (510)


So with edns-udp-size set to 512 it looks like the .gov servers
(a.gov-servers.net, b.gov-servers.net) refuse to ever return the
necessary glue for the nsf.gov DNS servers. Am I reading this right?

Thanks,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From fw at deneb.enyo.de  Mon May  2 12:13:11 2011
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 02 May 2011 19:13:11 +0200
Subject: trouble with .gov dns?
In-Reply-To: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com> (William
	Herrin's message of "Mon, 2 May 2011 12:01:06 -0400")
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
Message-ID: <878vupuiu0.fsf@mid.deneb.enyo.de>

* William Herrin:

> Anyone else having trouble with .gov DNS failing with edns-udp-size
> set to 512?

You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
section 3.  A query that advertises a smaller buffer size is
non-compliant.  BIND will send such queries, but this is a
controversial feature.

This has been noted before, for example:

From: Mark Andrews <marka at isc.org>
Subject: [dnsext] Failure to add glue MUST cause TC to be set.
To: dnsext at ietf.org
Date: Sun, 20 Feb 2011 08:07:15 +1100
Message-Id: <20110219210716.72943A5602B at drugs.dv.isc.org>



From bill at herrin.us  Mon May  2 12:23:19 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 2 May 2011 13:23:19 -0400
Subject: trouble with .gov dns?
In-Reply-To: <878vupuiu0.fsf@mid.deneb.enyo.de>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
Message-ID: <BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>

On Mon, May 2, 2011 at 1:13 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * William Herrin:
>> Anyone else having trouble with .gov DNS failing with edns-udp-size
>> set to 512?
>
> You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
> section 3. ?A query that advertises a smaller buffer size is
> non-compliant. ?BIND will send such queries, but this is a
> controversial feature.

Hi Florian,

I have "dnssec-enable no;" in my bind config. Were you able to
determine from the tcpdump output that DNSSEC was being requested?
How?

Thanks,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From fw at deneb.enyo.de  Mon May  2 12:31:07 2011
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 02 May 2011 19:31:07 +0200
Subject: trouble with .gov dns?
In-Reply-To: <BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com> (William
	Herrin's message of "Mon, 2 May 2011 13:23:19 -0400")
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
Message-ID: <87zkn5t3fo.fsf@mid.deneb.enyo.de>

* William Herrin:

> On Mon, May 2, 2011 at 1:13 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>> * William Herrin:
>>> Anyone else having trouble with .gov DNS failing with edns-udp-size
>>> set to 512?
>>
>> You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
>> section 3. ?A query that advertises a smaller buffer size is
>> non-compliant. ?BIND will send such queries, but this is a
>> controversial feature.

> I have "dnssec-enable no;" in my bind config.

It does not seem to have the intended effect.

> Were you able to determine from the tcpdump output that DNSSEC was
> being requested?

[udp sum ok] 10320 [1au] A? www.nsf.gov. ar: . OPT UDPsize=512 OK (40)
11:53:01.690414 IP (tos 0x0, ttl 249, id 28744, offset 0, flags

"OK" means that DO=1 was set.



From bill at herrin.us  Mon May  2 12:46:59 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 2 May 2011 13:46:59 -0400
Subject: trouble with .gov dns?
In-Reply-To: <87zkn5t3fo.fsf@mid.deneb.enyo.de>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
Message-ID: <BANLkTikM+mKTEdukbgm4ALZi9GP41bNM-g@mail.gmail.com>

On Mon, May 2, 2011 at 1:31 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * William Herrin:
>
>> On Mon, May 2, 2011 at 1:13 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> * William Herrin:
>>>> Anyone else having trouble with .gov DNS failing with edns-udp-size
>>>> set to 512?
>>>
>>> You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
>>> section 3. ?A query that advertises a smaller buffer size is
>>> non-compliant. ?BIND will send such queries, but this is a
>>> controversial feature.
>
>> I have "dnssec-enable no;" in my bind config.
>
> It does not seem to have the intended effect.

Hmm. You're right. Bind won't disable DNSSEC unless you turn edns off
completely with:

server 0.0.0.0/0 {
  edns no;
};

Thanks for the info!

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From joey.liuyq at gmail.com  Mon May  2 13:16:41 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Mon, 2 May 2011 13:16:41 -0500
Subject: Suspecious anycast prefixes
Message-ID: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>

Hi all,

I found the following prefixes are often originated by many ASNs more than
five, wonder if they provide global anycast service, if so what specific
service they provide?

12.64.255.0/24
70.37.135.0/24
198.32.176.0/24
199.7.49.0/24
199.7.80.0/24
199.16.93.0/24
199.16.94.0/24
199.16.95.0/24
206.223.115.0/24

Thanks,
Yaoqing


From bonomi at mail.r-bonomi.com  Mon May  2 13:40:16 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 2 May 2011 13:40:16 -0500 (CDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <4DBEBB96.3030404@gmail.com>
Message-ID: <201105021840.p42IeGJh060051@mail.r-bonomi.com>


> Date: Mon, 02 May 2011 10:11:34 -0400
> From: David Sparro <dsparro at gmail.com>
> Subject: Re: How do you put a TV station on the Mbone?
>
> On 4/29/2011 8:57 PM, Robert Bonomi wrote:
> > Those royalties are based on the_actual_number_  of persons
> > tuning in to each such work.  No 'averaging', no 'estimating', nothing
> > based on 'ratings', or other 'sampling techniques -- you have to count
> > the_actual_number_  of people tuned in.  It gets messy, but you have to
> > have 'auditable' records of when each person 'tuned in', and when they
> > 'tuned out'.  One_has_  to be able to detect the latter condition under
> > all possible circumstances.
>
> Really?  

Yeah, _really_.  That is what the law says.

>   How do they detect the number of people that were gathered 
> around my screen while I was watching?
> Does that mean I'll be able to get a refund (pro-rated of course) for 
> falling asleep during UFC 129 this weekend?

There is an 'assumption' built into the applicable implementation rules
issued by the government that 'one active display device' == 'one viewer'.

How close that  assumption is to 'objective reality' is irrelevant to
the legalities involved in calculating royalties due.




From sfouant at shortestpathfirst.net  Mon May  2 13:44:16 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 2 May 2011 14:44:16 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
Message-ID: <011a01cc08f8$f0ecbca0$d2c635e0$@net>

> -----Original Message-----
> From: Yaoqing(Joey) Liu [mailto:joey.liuyq at gmail.com]
> Sent: Monday, May 02, 2011 2:17 PM
> To: nanog at nanog.org
> Subject: Suspecious anycast prefixes
> 
> Hi all,
> 
> I found the following prefixes are often originated by many ASNs more
> than
> five, wonder if they provide global anycast service, if so what
> specific
> service they provide?
> 
> 12.64.255.0/24
> 70.37.135.0/24
> 198.32.176.0/24
> 199.7.49.0/24
> 199.7.80.0/24
> 199.16.93.0/24
> 199.16.94.0/24
> 199.16.95.0/24
> 206.223.115.0/24

Most of those are for Verisign's DNS resolution services.  Definitely
nothing to be suspicious about here.  Move along.  These aren't the droids
you are looking for.

Stefan Fouant





From patrick at ianai.net  Mon May  2 13:53:35 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 2 May 2011 14:53:35 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com>
	<4DBB0D68.40108@bogus.com>
	<BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com>
	<8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
Message-ID: <0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>

On Apr 29, 2011, at 8:46 PM, Jared Mauch wrote:

> I think this is sadly the truth.  There are some problems that can be solved by multicast, but I've seen the number of customer requests for v4 multicast go by the wayside over the years.  The only people that are generally interested are the conference venues for technical things, e.g.: RIPE, ARIN/NANOG, APRICOT, etc.  
> 
> Plus, conferences like NANOG have beamed the video back to some other site for fanout as well, for both unicast and multicast.
> 
> The problems at Layer7 and below are solvable with market forces.  They're all 8/9 issues, about the content providers wanting to be paid-per-subscriber/viewer.  They don't want to know how few people are actually tuned in at that moment in some cases.  I'm sure they want to be paid some fraction of that cost that goes to your TV Transport conduit provider.

I'm not at all certain that this is a political problem.  I believe it is more of a user need / want problem (which I guess you could classify as "layer > 7" if you want).

The occasional large live "event" - and when I say occasional, I mean not a few per year - likely could be helped if there were a magic wand to wave which made multicast work for no CapEx or OpEx and perfectly billed.  But the vast majority of traffic cannot be served by multi-cast.

The real cost of multi-cast (when it works at all!) may be too great for the small benefit, even ignoring the billing mechanism.

People's proclivities change.  As a vendor / supplier / company who gets paid, we have to adjust to the wishes of the people paying us as best we can.  Or someone else will.

-- 
TTFN,
patrick




From bicknell at ufp.org  Mon May  2 14:08:13 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 2 May 2011 12:08:13 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com>
	<4DBB0D68.40108@bogus.com>
	<BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com>
	<8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
	<0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
Message-ID: <20110502190813.GA14060@ussenterprise.ufp.org>

In a message written on Mon, May 02, 2011 at 02:53:35PM -0400, Patrick W. Gilmore wrote:
> I'm not at all certain that this is a political problem.  I believe it is more of a user need / want problem (which I guess you could classify as "layer > 7" if you want).

The users don't care if the content arrives via unicast, multicast,
ipv4, ipv6, or any other method.  They just care when they click
on the link that it works.

I think the multicast issues have been largely discovered and solved
in small to medium deployments, but for some reason there is no
desire to work on them at Internet scale.

In small deployments the multicast is treated as unidirectional, with a
small number of fixed sources and lots of receivers.  This takes out a
lot of technical obsticals to any-to-any multicast, and simplifies a lot
of the business relationship issues.  Billing for multicast is seen as
"hard" for instance, and if anyone can dynamically put up or tear down
sessions I can see how that's true.  But compare to a TV model which has
a fixed, 24x7 broadcaster and it is easy.

It's not a solution to every problem for sure.  However it is a way to
bring 24x7 TV like service to the Internet _very_ efficiently.  I'm sure
sites like cnn.com would rather pay to multicast their traffic to the
end user providers than to build the infrastructure for all the unicast
streams if the service was reliable and offered by all.

How do you get the business people to deal with it though?  With
unicast every new viewer is more traffic, and traffic is a proxy
for revenue.  Is it not the same problem as your electric company
not being incentivised to help you conserve?  Why would companies
who make money selling megabits and gigabits want to give their
largest content customers a way to do things for a fraction of the
cost?

That I think is the real issue.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110502/0d89779b/attachment.bin>

From jeroen at mompl.net  Mon May  2 14:27:34 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Mon, 02 May 2011 12:27:34 -0700
Subject: Amazon diagnosis
In-Reply-To: <BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>	<4DBDA17C.2040303@tiedyenetworks.com>	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
Message-ID: <4DBF05A6.40503@mompl.net>

Jeff Wheeler wrote:
> IT managers would do well to understand that a few smart programmers,
> who understand how all their tools (web servers, databases,
> filesystems, load-balancers, etc.) actually work, can often do more to

I fully agree.

But much to my dismay and surprise I have learned that developers know 
very little above and beyond their field of interest, say java 
programming. And I bet this is vice versa.

It surprised me because I, perhaps naively, assumed IT workers in 
general have a rather broad knowledge because in general they're 
interested in many aspects of IT, try to find out as much as possible 
and if they do not know something they make an effort learning it. Also 
considering many (practical) things just aren't taught in university, 
which is to be expected since the idea is to develop an academic way of 
thinking.

Maybe this "hacker" mentality is less prevalent than I, naively, assumed.

So I believe it's just really hard to find someone who is smart and who 
understands all or most of the aspects of IT, i.e. servers, databases, 
file systems, load balancers, networks etc. And it's easier and cheaper 
in the short term to just open a can of <insert random IT job> and hope 
for the best.

Regards,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From jabley at hopcount.ca  Mon May  2 14:35:20 2011
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 2 May 2011 22:35:20 +0300
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
Message-ID: <ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>


On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:

> I found the following prefixes are often originated by many ASNs more than
> five, wonder if they provide global anycast service, if so what specific
> service they provide?
> 
> 12.64.255.0/24

CERNET.

> 70.37.135.0/24

Microsoft/Hotmail.

> 198.32.176.0/24

Yahoo!

> 199.7.49.0/24

VeriSign.

> 199.7.80.0/24

VeriSign.

> 199.16.93.0/24

VeriSign.

> 199.16.94.0/24

VeriSign.

> 199.16.95.0/24

VeriSign.

> 206.223.115.0/24

Yahoo!

These to me are all organisations that might reasonably be distributing services using anycast. It's difficult to tell whether all the origin ASes you see for those prefixes are legitimate, of course.

It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.


Joe


From Valdis.Kletnieks at vt.edu  Mon May  2 14:46:12 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 02 May 2011 15:46:12 -0400
Subject: Amazon diagnosis
In-Reply-To: Your message of "Mon, 02 May 2011 12:27:34 PDT."
	<4DBF05A6.40503@mompl.net>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
	<4DBF05A6.40503@mompl.net>
Message-ID: <24489.1304365572@localhost>

On Mon, 02 May 2011 12:27:34 PDT, Jeroen van Aart said:

> It surprised me because I, perhaps naively, assumed IT workers in 
> general have a rather broad knowledge

No, the average IT worker is always a mere 3 keystrokes away from getting their
latest creation listed on www.thedailywtf.com. They're lucky they can manage to
get stuff done in their own area of competency, much less develop broad
knowledge.

Sorry to break it to you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110502/1d9bede9/attachment.bin>

From paul at paulgraydon.co.uk  Mon May  2 15:05:38 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Mon, 02 May 2011 10:05:38 -1000
Subject: Amazon diagnosis
In-Reply-To: <4DBF05A6.40503@mompl.net>
References: <602316126.1304085701368.JavaMail.nobody@james2>	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>	<4DBDA17C.2040303@tiedyenetworks.com>	<4DBDA407.1010002@trelane.net>	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
	<4DBF05A6.40503@mompl.net>
Message-ID: <4DBF0E92.3040000@paulgraydon.co.uk>

On 05/02/2011 09:27 AM, Jeroen van Aart wrote:
> Jeff Wheeler wrote:
>> IT managers would do well to understand that a few smart programmers,
>> who understand how all their tools (web servers, databases,
>> filesystems, load-balancers, etc.) actually work, can often do more to
>
> I fully agree.
>
> But much to my dismay and surprise I have learned that developers know 
> very little above and beyond their field of interest, say java 
> programming. And I bet this is vice versa.
>
> It surprised me because I, perhaps naively, assumed IT workers in 
> general have a rather broad knowledge because in general they're 
> interested in many aspects of IT, try to find out as much as possible 
> and if they do not know something they make an effort learning it. 
> Also considering many (practical) things just aren't taught in 
> university, which is to be expected since the idea is to develop an 
> academic way of thinking.

   I work with a bunch of developers, we're a primarily java based 
company, but I've got more than enough on my plate trying to keep up 
with everything practical as a sysadmin, from networks to hardware to 
audit needs, to even start to think about adding in Java skills to my 
repertoire!  Especially given I'm the only sysadmin here and our 
infrastructure needs are quite diverse.  I've learned to interpret java 
stack traces that get sent to me 24x7 on our critical mailing list so 
that I can identify whether is code or infrastructure but that's as far 
as I go with java.  I don't particularly see that I need to either.  I 
strive to work with//developers, no 'them vs us' attitudes, no arrogant 
"my way or the highway".  I can't conceive why anyone would even 
consider maintaining those kind of attitudes but unfortunately have seen 
them frequently, and it seems so often to be the normal rather than the 
abnormal.
   Programming is not something I'd consider myself to be any good at.  
I'll happily and reasonably competently script stuff in perl, python or 
bash for sysadmin purposes, but I'd never make any pretence at it being 
'good' and well done scripting.  It's just not the way my mind works.  I 
have my specialisms and they have theirs, more productive use of time is 
to work with those who excel at that kind of thing.  Here they don't 
make assumptions about my end of things, and I don't make assumptions 
about theirs.  We ask each other questions, and work together to figure 
out how best to proceed.  Thankfully we're a relatively small enough 
operation that management isn't too much of a burden.

   Smart IT managers, in my book, work to take advantage of all the 
skills that their workers have and provide an efficient framework for 
them to work together.  What it seems we see more often than not are IT 
managers that persist in seeing Sysadmin and Development as 'ops' and 
'dev' separately rather than combined, perpetuating the 'them' vs 'us' 
attitudes rather than throwing them out for the inefficient, financially 
wasteful things they are.

Paul


From nick at flhsi.com  Mon May  2 15:29:13 2011
From: nick at flhsi.com (Nick Olsen)
Date: Mon, 2 May 2011 16:29:13 -0400
Subject: Bright House residential IPv6
Message-ID: <5211f936$7a711db5$e89139a$@com>

Bright House does Not provide any IPv6 on any service at this time. It 
looks like they are allocated a prefix from ARIN, But They do not announce 
it. Expect them to be the last to support it.

Nick Olsen
Network Operations (855) FLSPEED  x106

----------------------------------------
 From: "Thomas York" <straterra at fuhell.com>
Sent: Monday, May 02, 2011 10:17 AM
To: nanog at nanog.org
Subject: Bright House residential IPv6

I'm a new Bright House residential customer and I have their new 40/5
'Lightning' service, which is rumored to have free native IPv6. I've 
called
them, but of course no one I talked to knew anything about IPv6. Do any of
you have this service and have native? If you do, what did you do to get 
it
activated for your line?

Thomas York




From straterra at fuhell.com  Mon May  2 15:27:49 2011
From: straterra at fuhell.com (Thomas York)
Date: Mon, 2 May 2011 16:27:49 -0400
Subject: Bright House residential IPv6
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAADyRgjJeItxBrNW6QTBSBKkBAAAAAA==@fuhell.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAADyRgjJeItxBrNW6QTBSBKkBAAAAAA==@fuhell.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAHKWGYlkj1JEugzXdqd+lq4BAAAAAA==@fuhell.com>

As per an off list topic, I'm in downtown Indianapolis. If anyone has a
residential contact for this region, I'd much appreciate it. Thanks!

Thomas York

-----Original Message-----
From: Thomas York [mailto:straterra at fuhell.com] 
Sent: Monday, May 02, 2011 10:13 AM
To: nanog at nanog.org
Subject: Bright House residential IPv6

I'm a new Bright House residential customer and I have their new 40/5
'Lightning' service, which is rumored to have free native IPv6. I've called
them, but of course no one I talked to knew anything about IPv6. Do any of
you have this service and have native? If you do, what did you do to get it
activated for your line?

 

 

Thomas York

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6400 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110502/b37f9ab2/attachment.bin>

From jeroen at mompl.net  Mon May  2 16:04:27 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Mon, 02 May 2011 14:04:27 -0700
Subject: Amazon diagnosis
In-Reply-To: <24489.1304365572@localhost>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
	<4DBF05A6.40503@mompl.net> <24489.1304365572@localhost>
Message-ID: <4DBF1C5B.9030908@mompl.net>

Valdis.Kletnieks at vt.edu wrote:
> On Mon, 02 May 2011 12:27:34 PDT, Jeroen van Aart said:
> 
>> It surprised me because I, perhaps naively, assumed IT workers in 
>> general have a rather broad knowledge

> Sorry to break it to you.

That's ok, the past tense in my story testifies to the fact I was 
already aware of it. But thanks. ;-)


Greetings,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From george.herbert at gmail.com  Mon May  2 16:11:51 2011
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 2 May 2011 14:11:51 -0700
Subject: Amazon diagnosis
In-Reply-To: <4DBF1C5B.9030908@mompl.net>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
	<4DBF05A6.40503@mompl.net> <24489.1304365572@localhost>
	<4DBF1C5B.9030908@mompl.net>
Message-ID: <BANLkTi=GHYmjJ9zqhBqz_eH+i7tcxZ9XSg@mail.gmail.com>

On Mon, May 2, 2011 at 2:04 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
> Valdis.Kletnieks at vt.edu wrote:
>>
>> On Mon, 02 May 2011 12:27:34 PDT, Jeroen van Aart said:
>>
>>> It surprised me because I, perhaps naively, assumed IT workers in general
>>> have a rather broad knowledge
>
>> Sorry to break it to you.
>
> That's ok, the past tense in my story testifies to the fact I was already
> aware of it. But thanks. ;-)


There was a significant decline in knowledge as the .com era peaked in
the 90s; less CS background required as an entry barrier, the
employment pool grew fast enough that community knowledge
organizations (Usenix, etc) didn't effectively diffuse into the new
community, etc.

The number of people who "get" computer architecture, ops, clusters,
networking, systems architecture and engineering, etc...  Not good.

Sigh.


-- 
-george william herbert
george.herbert at gmail.com



From dot at dotat.at  Mon May  2 18:47:15 2011
From: dot at dotat.at (Tony Finch)
Date: Tue, 3 May 2011 00:47:15 +0100
Subject: trouble with .gov dns?
In-Reply-To: <87zkn5t3fo.fsf@mid.deneb.enyo.de>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
Message-ID: <alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>

Florian Weimer <fw at deneb.enyo.de> wrote:
>
> > I have "dnssec-enable no;" in my bind config.
>
> It does not seem to have the intended effect.

BIND's interpretation of the DO bit is "I understand DNSSEC RRs so it is
OK to send them" not "I would like you to send DNSSEC RRs". This is why it
always sets the DO bit when it can, i.e. when the request contains an EDNS
OPT pseudo-RR.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.



From morrowc.lists at gmail.com  Mon May  2 19:40:01 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 2 May 2011 20:40:01 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
Message-ID: <BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>

On Mon, May 2, 2011 at 3:35 PM, Joe Abley <jabley at hopcount.ca> wrote:
>
> On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
>
>> I found the following prefixes are often originated by many ASNs more than
>> five, wonder if they provide global anycast service, if so what specific
>> service they provide?
>>
>> 12.64.255.0/24
>
> CERNET.
>
>> 70.37.135.0/24
>
> Microsoft/Hotmail.
>
>> 198.32.176.0/24
>
> Yahoo!

as a note, this is bmanning/ep.net exchange space, no? so this could
be just people leaking this into their table/global-table by mistake?



From marka at isc.org  Mon May  2 20:19:49 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 03 May 2011 11:19:49 +1000
Subject: trouble with .gov dns?
In-Reply-To: Your message of "Mon, 02 May 2011 19:13:11 +0200."
	<878vupuiu0.fsf@mid.deneb.enyo.de>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
Message-ID: <20110503011949.A8448E69621@drugs.dv.isc.org>


In message <878vupuiu0.fsf at mid.deneb.enyo.de>, Florian Weimer writes:
> * William Herrin:
> 
> > Anyone else having trouble with .gov DNS failing with edns-udp-size
> > set to 512?
> 
> You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
> section 3.  A query that advertises a smaller buffer size is
> non-compliant.  BIND will send such queries, but this is a
> controversial feature.
> 
> This has been noted before, for example:
> 
> From: Mark Andrews <marka at isc.org>
> Subject: [dnsext] Failure to add glue MUST cause TC to be set.
> To: dnsext at ietf.org
> Date: Sun, 20 Feb 2011 08:07:15 +1100
> Message-Id: <20110219210716.72943A5602B at drugs.dv.isc.org>

And nameservers that don't set TC when they can't fit glue are
broken RFC 1034.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From thepacketmaster at hotmail.com  Mon May  2 22:30:38 2011
From: thepacketmaster at hotmail.com (James Smith )
Date: Tue, 3 May 2011 03:30:38 +0000
Subject: Amazon diagnosis
Message-ID: <BAY157-ds12359EAEE58FA0B653310CA29E0@phx.gbl>

It's always interesting (in a sad way) when a programmer or DBA comes to me with a basic networking or Unix question that any CCNA or RedHat candidate could answer.  Then I get a very safe feeling about my job security when they start asking me if I could look at their code.  This has happened too many times in my career.  

People seem to equate broad knowledge to mean you're a jack-of-all-trades-and-master-of-none.  These are usually the same Comp Sci PhDs that have no clue why they just got fired for saying something totally inappropriate in front of HR. 

The more knowledge you have about anything and everything that your systems interact with then the better you will be at your specialty.



Sent from my "contract free" BlackBerry? smartphone on the WIND network.

-----Original Message-----
From: Jeroen van Aart <jeroen at mompl.net>
Date: Mon, 2 May 2011 19:27:34 
To: <nanog at nanog.org>
Subject: Re: Amazon diagnosis

Jeff Wheeler wrote:
> IT managers would do well to understand that a few smart programmers,
> who understand how all their tools (web servers, databases,
> filesystems, load-balancers, etc.) actually work, can often do more to

I fully agree.

But much to my dismay and surprise I have learned that developers know 
very little above and beyond their field of interest, say java 
programming. And I bet this is vice versa.

It surprised me because I, perhaps naively, assumed IT workers in 
general have a rather broad knowledge because in general they're 
interested in many aspects of IT, try to find out as much as possible 
and if they do not know something they make an effort learning it. Also 
considering many (practical) things just aren't taught in university, 
which is to be expected since the idea is to develop an academic way of 
thinking.

Maybe this "hacker" mentality is less prevalent than I, naively, assumed.

So I believe it's just really hard to find someone who is smart and who 
understands all or most of the aspects of IT, i.e. servers, databases, 
file systems, load balancers, networks etc. And it's easier and cheaper 
in the short term to just open a can of <insert random IT job> and hope 
for the best.

Regards,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From gbonser at seven.com  Mon May  2 22:33:05 2011
From: gbonser at seven.com (George Bonser)
Date: Mon, 2 May 2011 20:33:05 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com><4DBB0D68.40108@bogus.com><BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com><8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
	<0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E305B@RWC-EX1.corp.seven.com>

> 
> I'm not at all certain that this is a political problem.  I believe it
> is more of a user need / want problem (which I guess you could
classify
> as "layer > 7" if you want).
> 
> The occasional large live "event" - and when I say occasional, I mean
> not a few per year - likely could be helped if there were a magic wand
> to wave which made multicast work for no CapEx or OpEx and perfectly
> billed.  But the vast majority of traffic cannot be served by multi-
> cast.
> 
> The real cost of multi-cast (when it works at all!) may be too great
> for the small benefit, even ignoring the billing mechanism.
> 
> People's proclivities change.  As a vendor / supplier / company who
> gets paid, we have to adjust to the wishes of the people paying us as
> best we can.  Or someone else will.
> 
> --
> TTFN,
> patrick
> 

Hi, Patrick.

It takes some coordination but imagine someone like Comcast or
Roadrunner or AT&T says "hey, want to watch the March Madness games or
the Masters or the Olympics or the World Series?  Here, download this
application and watch it with much better performance than streaming on
a web browser."

They would rather easily know how many customer ports are watching the
broadcast.  As I mentioned earlier, Verizon Wireless already uses it in
their mobile network.  It would take some coordination between the
content providers and the large consumer networks but the benefits would
be pretty substantial for the customers.  So the provider could go to
the cable news network and make an offer to provide live content via
multicast to their subscribers that would not eat a huge amount of
resources for either the content provider or the network provider.

It doesn't make sense for a lot of on-demand access but makes a lot of
sense for live content like radio talk shows, news, sports, etc.  Even
webcams could be upgraded to provide streaming content rather than
individual frames without chewing up a lot of resources. It wouldn't
matter if 1 or 1 million people are watching, the bandwidth resource
requirement would remain the same.

If there are 10,000 Comcast subscribers watching exactly the same live
event on the net, sending 10,000 streams of exactly the same data is
dumb and it doesn't have to be that way.




From bmanning at vacation.karoshi.com  Mon May  2 23:20:53 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 3 May 2011 04:20:53 +0000
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
Message-ID: <20110503042053.GA3478@vacation.karoshi.com.>

On Mon, May 02, 2011 at 08:40:01PM -0400, Christopher Morrow wrote:
> On Mon, May 2, 2011 at 3:35 PM, Joe Abley <jabley at hopcount.ca> wrote:
> >
> > On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
> >
> >> I found the following prefixes are often originated by many ASNs more than
> >> five, wonder if they provide global anycast service, if so what specific
> >> service they provide?
> >>
> >> 12.64.255.0/24
> >
> > CERNET.
> >
> >> 70.37.135.0/24
> >
> > Microsoft/Hotmail.
> >
> >> 198.32.176.0/24
> >
> > Yahoo!
> 
> as a note, this is bmanning/ep.net exchange space, no? so this could
> be just people leaking this into their table/global-table by mistake?


	used to be.  ep.net has fragmented into little bits.  most of the prefixes have
	been transfered to the clients who were using them, the ones who are still around
	are outside the ARIN region and there is no clean way to move them given ARIN and
	other RIR policy.   

This particular prefix was used as a public exchange, operated by Switch & Data. Not sure 
what they have done w/ it since then.

Switch and Data Management Company LLC NET-PAIX-V4 (NET-198-32-175-0-1) 198.32.175.0 - 198.32.177.255
EP.NET, LLC. NET-EP-176 (NET-198-32-176-0-1) 198.32.176.0 - 198.32.176.255


/bill




From jra at baylink.com  Mon May  2 23:42:08 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 3 May 2011 00:42:08 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E305B@RWC-EX1.corp.seven.com>
Message-ID: <7376724.545.1304397728441.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "George Bonser" <gbonser at seven.com>

> It doesn't make sense for a lot of on-demand access but makes a lot of
> sense for live content like radio talk shows, news, sports, etc. Even
> webcams could be upgraded to provide streaming content rather than
> individual frames without chewing up a lot of resources. It wouldn't
> matter if 1 or 1 million people are watching, the bandwidth resource
> requirement would remain the same.
> 
> If there are 10,000 Comcast subscribers watching exactly the same live
> event on the net, sending 10,000 streams of exactly the same data is
> dumb and it doesn't have to be that way.

And, more to the point, as we proceed more and more into a live-tweet,
social TV world, *having all your viewers within a second or two of 
each other* becomes more and more important.

My experience is that that's *much* easier to manage in a multicast 
environment, than with live-unicast streaming -- especially when there
are multiple server clusters in different places for load balancing.

Cheers,
-- jra



From fw at deneb.enyo.de  Tue May  3 00:19:21 2011
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 03 May 2011 07:19:21 +0200
Subject: trouble with .gov dns?
In-Reply-To: <alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>
	(Tony Finch's message of "Tue, 3 May 2011 00:47:15 +0100")
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
	<alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>
Message-ID: <874o5c1huu.fsf@mid.deneb.enyo.de>

* Tony Finch:

> Florian Weimer <fw at deneb.enyo.de> wrote:
>>
>> > I have "dnssec-enable no;" in my bind config.
>>
>> It does not seem to have the intended effect.
>
> BIND's interpretation of the DO bit is "I understand DNSSEC RRs so
> it is OK to send them" not "I would like you to send DNSSEC
> RRs". This is why it always sets the DO bit when it can, i.e. when
> the request contains an EDNS OPT pseudo-RR.

I would go even further---the DO bit is not about DNSSEC at all.  The
resolver just promises to ignore any ancillary record sets it does not
understand.  If DO were about DNSSEC, a new flag would have been
introduced along with DNSSECbis, where the record types changed so
that for resolvers implementing the older protocol, the DNSSECbis
records just looked like garbage.



From fw at deneb.enyo.de  Tue May  3 00:20:55 2011
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 03 May 2011 07:20:55 +0200
Subject: trouble with .gov dns?
In-Reply-To: <20110503011949.A8448E69621@drugs.dv.isc.org> (Mark Andrews's
	message of "Tue, 03 May 2011 11:19:49 +1000")
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<20110503011949.A8448E69621@drugs.dv.isc.org>
Message-ID: <87y62oz7ew.fsf@mid.deneb.enyo.de>

* Mark Andrews:

>> You need an UDP size of at least 1220 for DNSSEC, see RFC 3226,
>> section 3.  A query that advertises a smaller buffer size is
>> non-compliant.  BIND will send such queries, but this is a
>> controversial feature.
>> 
>> This has been noted before, for example:
>> 
>> From: Mark Andrews <marka at isc.org>
>> Subject: [dnsext] Failure to add glue MUST cause TC to be set.
>> To: dnsext at ietf.org
>> Date: Sun, 20 Feb 2011 08:07:15 +1100
>> Message-Id: <20110219210716.72943A5602B at drugs.dv.isc.org>
>
> And nameservers that don't set TC when they can't fit glue are
> broken RFC 1034.

Only if they produce such answers in response to compliant queries. 8-)



From andrew.koch at gawul.net  Tue May  3 00:54:13 2011
From: andrew.koch at gawul.net (Andrew Koch)
Date: Tue, 3 May 2011 00:54:13 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <20110503042053.GA3478@vacation.karoshi.com.>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
Message-ID: <BANLkTinCDas43CLhRcKegzbp0nKUNVoVew@mail.gmail.com>

On Mon, May 2, 2011 at 23:20,  <bmanning at vacation.karoshi.com> wrote:

>> >> 198.32.176.0/24
>> >
>> > Yahoo!

> This particular prefix was used as a public exchange, operated by Switch & Data. Not sure
> what they have done w/ it since then.
>
> Switch and Data Management Company LLC NET-PAIX-V4 (NET-198-32-175-0-1) 198.32.175.0 - 198.32.177.255
> EP.NET, LLC. NET-EP-176 (NET-198-32-176-0-1) 198.32.176.0 - 198.32.176.255
>

Still in-use at the Equinix Palo Alto exchange (former PAIX)

https://www.peeringdb.com/private/exchange_view.php?id=7
https://www.peeringdb.com/dns-scan/198-32-176-0-24.txt

Andy



From young at jsyoung.net  Tue May  3 02:49:16 2011
From: young at jsyoung.net (Jeff Young)
Date: Tue, 3 May 2011 17:49:16 +1000
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E305B@RWC-EX1.corp.seven.com>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com><4DBB0D68.40108@bogus.com><BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com><8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
	<0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
	<5A6D953473350C4B9995546AFE9939EE0C9E305B@RWC-EX1.corp.seven.com>
Message-ID: <770785CF-F492-4820-B9ED-5FDEC8661067@jsyoung.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 03/05/2011, at 1:33 PM, George Bonser wrote:

> f there are 10,000 Comcast subscribers watching exactly the same live
> event on the net, sending 10,000 streams of exactly the same data is
> dumb and it doesn't have to be that way.

IMHO, 

It's pretty likely that those 10,000 streams will originate in as few as 5 but
as many as 40 or so individual CDN-type devices imbedded deep in 
Comcast local networks.  Therefore, the consumption of bandwidth that
seems wasteful is limited and in proportion to the distance between the
viewers and these devices.  The same devices can be used to originate
long-tail (not often watched) content, Video on Demand content, time-
shifted content and so forth.  

Multicast is an elegant solution to a dwindling problem set.  Patrick rightly
points out that enabling multicast to the end user may just not be worth the 
operational cost.  Multicast as a tool the provider uses on the other hand
is well worth the expense.  You might use it to broadcast content to your 
CDN-like devices or keep your trading desks up to date with the latest ticker 
feeds.  AT&T uses multicast to push video channels (the IP equivalent of 
broadcast TV) down to and through DSLAMs for UVerse.  

But viewing habits dictate technology used.  For instance, AT&T might use
multicast to 'broadcast' television channels but for an "instant channel 
change" feature hoards of unicast servers stand ready to feed UVerse
users who haven't figured out how to use a program guide to navigate
their sets and can't bear the latency of a S,G join.  :-)  

jy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iF4EAREIAAYFAk2/s4AACgkQxvthcni5E2/naQD+PHifzWPC2mhknrzhIIjqstT+
HoBJ2/Lk4ZpktX+00osA/0OEDL5SQHeg++c9wo40hJuxMRn66ViPOXNq8T7ckWdZ
=yeYh
-----END PGP SIGNATURE-----



From woody at pch.net  Tue May  3 05:17:20 2011
From: woody at pch.net (Bill Woodcock)
Date: Tue, 3 May 2011 03:17:20 -0700
Subject: Suspecious anycast prefixes
In-Reply-To: <ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
Message-ID: <3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On May 2, 2011, at 12:35 PM, Joe Abley wrote:
> It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.

I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice for me to originate my address space from more than 8,000 different ASNs, when I currently do just fine advertising it from three.  I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common.

                                -Bill




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk2/1jEACgkQGvQy4xTRsBH89wCfSD9h/1v/jNtKwk18XP4In6cE
Z3wAniPsu6QvtMfHLlz/Jn7tGUwRzQvX
=iuXT
-----END PGP SIGNATURE-----




From dmiller at tiggee.com  Tue May  3 08:42:14 2011
From: dmiller at tiggee.com (David Miller)
Date: Tue, 03 May 2011 09:42:14 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
Message-ID: <4DC00636.5070100@tiggee.com>

On 5/3/2011 6:17 AM, Bill Woodcock wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On May 2, 2011, at 12:35 PM, Joe Abley wrote:
>> It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see<http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.
> I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice for me to originate my address space from more than 8,000 different ASNs, when I currently do just fine advertising it from three.  I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common.
>
>                                  -Bill

+1

We are not convinced and are not planning on implementing this draft either.

-DM




From drc at virtualized.org  Tue May  3 09:23:56 2011
From: drc at virtualized.org (David Conrad)
Date: Tue, 3 May 2011 07:23:56 -0700
Subject: trouble with .gov dns?
In-Reply-To: <874o5c1huu.fsf@mid.deneb.enyo.de>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
	<alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>
	<874o5c1huu.fsf@mid.deneb.enyo.de>
Message-ID: <46B4B8DD-9C1A-4CC1-8C10-814CA5F249C9@virtualized.org>

On May 2, 2011, at 10:19 PM, Florian Weimer wrote:
> I would go even further---the DO bit is not about DNSSEC at all.

Err, yes it is.

> The
> resolver just promises to ignore any ancillary record sets it does not
> understand.

How people implement RFC 3225 does differ from the intent of the author, however I would be surprised if this is what DO is taken to mean in any resolver.

> If DO were about DNSSEC, a new flag would have been
> introduced along with DNSSECbis, where the record types changed so
> that for resolvers implementing the older protocol, the DNSSECbis
> records just looked like garbage.

You're suggesting RFC 3225 should have predicted DNSSECbis?  Would it help if the interpretation of DO is that indicates the resolver supports "DNSSEC as defined at the time"?

This probably isn't the right venue for this discussion.

Regards,
-drc




From jason at thebaughers.com  Tue May  3 09:41:41 2011
From: jason at thebaughers.com (Jason Baugher)
Date: Tue, 03 May 2011 09:41:41 -0500
Subject: Amazon diagnosis
In-Reply-To: <BANLkTi=GHYmjJ9zqhBqz_eH+i7tcxZ9XSg@mail.gmail.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>	<4DBDA17C.2040303@tiedyenetworks.com>	<4DBDA407.1010002@trelane.net>	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>	<4DBF05A6.40503@mompl.net>
	<24489.1304365572@localhost>	<4DBF1C5B.9030908@mompl.net>
	<BANLkTi=GHYmjJ9zqhBqz_eH+i7tcxZ9XSg@mail.gmail.com>
Message-ID: <4DC01425.4080501@thebaughers.com>

On 5/2/2011 4:11 PM, George Herbert wrote:
> On Mon, May 2, 2011 at 2:04 PM, Jeroen van Aart<jeroen at mompl.net>  wrote:
>> Valdis.Kletnieks at vt.edu wrote:
>>> On Mon, 02 May 2011 12:27:34 PDT, Jeroen van Aart said:
>>>
>>>> It surprised me because I, perhaps naively, assumed IT workers in general
>>>> have a rather broad knowledge
>>> Sorry to break it to you.
>> That's ok, the past tense in my story testifies to the fact I was already
>> aware of it. But thanks. ;-)
>
> There was a significant decline in knowledge as the .com era peaked in
> the 90s; less CS background required as an entry barrier, the
> employment pool grew fast enough that community knowledge
> organizations (Usenix, etc) didn't effectively diffuse into the new
> community, etc.
>
> The number of people who "get" computer architecture, ops, clusters,
> networking, systems architecture and engineering, etc...  Not good.
>
> Sigh.
>
>
Unfortunately we see this when we interview candidates. Even those who 
have certifications generally only know how to do specific things within 
a narrow field. They don't have the base understanding of how things 
work, such as TCP/IP, so when they need to do something a little outside 
of the normal, they flounder.

Jason





From bill at herrin.us  Tue May  3 09:54:27 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 3 May 2011 10:54:27 -0400
Subject: trouble with .gov dns?
In-Reply-To: <46B4B8DD-9C1A-4CC1-8C10-814CA5F249C9@virtualized.org>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
	<alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>
	<874o5c1huu.fsf@mid.deneb.enyo.de>
	<46B4B8DD-9C1A-4CC1-8C10-814CA5F249C9@virtualized.org>
Message-ID: <BANLkTim_2Gp-V0-idv5w+zOp36aNDOCPEA@mail.gmail.com>

On Tue, May 3, 2011 at 10:23 AM, David Conrad <drc at virtualized.org> wrote:
> This probably isn't the right venue for this discussion.

Hi David,

I'm going to go with Mark's answer: "nameservers that don't set TC
[truncated bit] when they can't fit glue are broken RFC 1034." When
that happens to be both TLD servers for a particular TLD (.gov), I'm
calling that an operational issue.

I have a workaround. I'm happy. But the folks running gov-servers.net
*really* ought to have a discussion with their vendor.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From gbonser at seven.com  Tue May  3 10:54:14 2011
From: gbonser at seven.com (George Bonser)
Date: Tue, 3 May 2011 08:54:14 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <770785CF-F492-4820-B9ED-5FDEC8661067@jsyoung.net>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com><4DBB0D68.40108@bogus.com><BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com><8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
	<0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
	<5A6D953473350C4B9995546AFE9939EE0C9E305B@RWC-EX1.corp.seven.com>
	<770785CF-F492-4820-B9ED-5FDEC8661067@jsyoung.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3064@RWC-EX1.corp.seven.com>

> 
> Multicast is an elegant solution to a dwindling problem set.  

And that is fundamentally where we disagree.  I see this as not
"elegant" at all.  It is a fundamental part of the protocol suite.  It
is no more "elegant" than unicast.  I also believe that it will be the
wireless operators that bring this back to widespread use as wireless
devices are used for more than simply placing phone calls.  Time will
tell, but it looks like the total use of multicast for content delivery
is currently increasing.  It just isn't increasing in the realm of home
internet providers, yet, but I believe it will as people use home
internet for things that they had traditionally used other services for
such as broadcast radio and tv.




From fw at deneb.enyo.de  Tue May  3 11:53:21 2011
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 03 May 2011 18:53:21 +0200
Subject: trouble with .gov dns?
In-Reply-To: <46B4B8DD-9C1A-4CC1-8C10-814CA5F249C9@virtualized.org> (David
	Conrad's message of "Tue, 3 May 2011 07:23:56 -0700")
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
	<alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>
	<874o5c1huu.fsf@mid.deneb.enyo.de>
	<46B4B8DD-9C1A-4CC1-8C10-814CA5F249C9@virtualized.org>
Message-ID: <87k4e7pvy6.fsf@mid.deneb.enyo.de>

* David Conrad:

> On May 2, 2011, at 10:19 PM, Florian Weimer wrote:
>> I would go even further---the DO bit is not about DNSSEC at all.
>
> Err, yes it is.

I know you think it is, but you're wrong if you look at the overall
protocol.

>> If DO were about DNSSEC, a new flag would have been
>> introduced along with DNSSECbis, where the record types changed so
>> that for resolvers implementing the older protocol, the DNSSECbis
>> records just looked like garbage.
>
> You're suggesting RFC 3225 should have predicted DNSSECbis?

Not quite.  If DO was about DNSSEC in the strictest possible sense,
then it would not have been possible to reuse the flag for DNSSECbis,
which hasn't got anything in common with DNSSEC as far as the wire
types are concerned.  For a original-DNSSEC-supporting resolver, they
look like garbage, just as the original DNSSEC records for some of the
resolvers back then.  So if DO referred to a specific set of record
types (the original DNSSEC ones), you'd need a new flag for DNSSECbis.
But this wasn't done, so DO does not cover a specific set of record
types, and it is therefore not tied to a particular DNS protocol
extension, including DNSSEC.



From Ed.Lewis at neustar.biz  Tue May  3 12:11:10 2011
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Tue, 3 May 2011 13:11:10 -0400
Subject: trouble with .gov dns?
In-Reply-To: <87k4e7pvy6.fsf@mid.deneb.enyo.de>
References: <BANLkTikdC9hyi8eh5uX_-2yD2V_xCF2OHA@mail.gmail.com>
	<878vupuiu0.fsf@mid.deneb.enyo.de>
	<BANLkTikyAsT4unG12ae0GPd0TfAx0XLcVw@mail.gmail.com>
	<87zkn5t3fo.fsf@mid.deneb.enyo.de>
	<alpine.LSU.2.00.1105030042390.31133@hermes-2.csi.cam.ac.uk>
	<874o5c1huu.fsf@mid.deneb.enyo.de>
	<46B4B8DD-9C1A-4CC1-8C10-814CA5F249C9@virtualized.org>
	<87k4e7pvy6.fsf@mid.deneb.enyo.de>
Message-ID: <a06240800c9e5e5b71c85@[10.31.203.194]>

At 18:53 +0200 5/3/11, Florian Weimer wrote:
>* David Conrad:
>
>>  On May 2, 2011, at 10:19 PM, Florian Weimer wrote:
>>>  I would go even further---the DO bit is not about DNSSEC at all.
>>
>>  Err, yes it is.
>
>I know you think it is, but you're wrong if you look at the overall
>protocol.

This is becoming a thread-to-the-death over a general weakness in the 
DNS protocol.  (Realizing this mailing list is NANOG, not an IETF 
one.) Like it or not, "versioning" and "negotiation" are 
poor-to-non-existent in DNS.  What's happening here is a document 
author (David) meant one thing and implementations (e.g., BIND) 
interpreting the document another way.  It doesn't matter that David 
is right (in that he meant it another way, and the way is what the WG 
meant), it more matters that the ship has sailed on "fixing" this in 
implementations.  And frankly, the fix isn't that important in 
retrospect because what the implementers did is actually ok, we can 
and we do live nicely with it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"



From lstewart at superb.net  Tue May  3 13:38:13 2011
From: lstewart at superb.net (Landon Stewart)
Date: Tue, 3 May 2011 11:38:13 -0700
Subject: Looking for contact from either ATT.net (@txt.att.net) or T-Mobile
	(@tmomail.net)
In-Reply-To: <BANLkTinwr1UDP7w8qj8qdAh6rHL4s-qTng@mail.gmail.com>
References: <BANLkTinwr1UDP7w8qj8qdAh6rHL4s-qTng@mail.gmail.com>
Message-ID: <BANLkTi=4jNr2nR5sJ4oFQ_cZVZRW6LMw6g@mail.gmail.com>

Hi Folks,

I'm seeing TXT messages leaving our network to @txt.att.net and
@tmomail.netusers.  The messages look very spammy.  I'm wondering if
there have been any
complaints of TXT spam from the IP address 66.36.240.39 (messages are From:
DavidBanks at tmsg4.com).

I have examples if you are interested in seeing them.  Please contact me
off-list.

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From phil.pierotti at gmail.com  Tue May  3 17:20:56 2011
From: phil.pierotti at gmail.com (Phil Pierotti)
Date: Wed, 4 May 2011 08:20:56 +1000
Subject: Amazon diagnosis
In-Reply-To: <4DC01425.4080501@thebaughers.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
	<4DBF05A6.40503@mompl.net> <24489.1304365572@localhost>
	<4DBF1C5B.9030908@mompl.net>
	<BANLkTi=GHYmjJ9zqhBqz_eH+i7tcxZ9XSg@mail.gmail.com>
	<4DC01425.4080501@thebaughers.com>
Message-ID: <BANLkTinr968Ss62+whAQ-G+M8=KfVzR4Jg@mail.gmail.com>

Unlike the US of A, here in Australia the industry has gone *very* heavily
down the path of requiring/expecting certification. They have bought into
the faith that unless your resume includes CC?? you're worthless.

There are "colleges" (er, I mean training businesses) who will *guarantee*
you will pass your exam at the end of the course. Amazingly enough for some
of them you never actually touch a router console (not even a virtual one)
through the entire course.

Unfortunately the end result has been an entire generation of potential
employees who are perfectly capable of passing an exam and thereby becoming
'certified', but cannot be trusted to touch a production network. They have
no understanding of what they're doing, why things work (or not) the way
they do, no real troubleshooting skills and certainly not an ounce of real
world production-network common sense.

Not *all* of them, but by far the vast overwhelming majority of candidates
have the "I'm certified so gimme a job and pay me big bucks" attitude
despite having *no real skills* worth mentioning.

PhilP


On Wed, May 4, 2011 at 12:41 AM, Jason Baugher <jason at thebaughers.com>wrote:

> On 5/2/2011 4:11 PM, George Herbert wrote:
>
>> On Mon, May 2, 2011 at 2:04 PM, Jeroen van Aart<jeroen at mompl.net>  wrote:
>>
>>> Valdis.Kletnieks at vt.edu wrote:
>>>
>>>> On Mon, 02 May 2011 12:27:34 PDT, Jeroen van Aart said:
>>>>
>>>>  It surprised me because I, perhaps naively, assumed IT workers in
>>>>> general
>>>>> have a rather broad knowledge
>>>>>
>>>> Sorry to break it to you.
>>>>
>>> That's ok, the past tense in my story testifies to the fact I was already
>>> aware of it. But thanks. ;-)
>>>
>>
>> There was a significant decline in knowledge as the .com era peaked in
>> the 90s; less CS background required as an entry barrier, the
>> employment pool grew fast enough that community knowledge
>> organizations (Usenix, etc) didn't effectively diffuse into the new
>> community, etc.
>>
>> The number of people who "get" computer architecture, ops, clusters,
>> networking, systems architecture and engineering, etc...  Not good.
>>
>> Sigh.
>>
>>
>>  Unfortunately we see this when we interview candidates. Even those who
> have certifications generally only know how to do specific things within a
> narrow field. They don't have the base understanding of how things work,
> such as TCP/IP, so when they need to do something a little outside of the
> normal, they flounder.
>
> Jason
>
>
>
>


From nanogwp at gmail.com  Wed May  4 03:43:53 2011
From: nanogwp at gmail.com (Robert Lusby)
Date: Wed, 4 May 2011 09:43:53 +0100
Subject: OT: Server Cabinet
Message-ID: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>

Sorry to start the day OT, but I'm sure you lovely lot will have some
tips/experience! ;)

We have a HP Server Cabinet (42U 10842 G2), that we've stripped down to the
bare-bones chassis. It now measures 750mm wide.

We have a door-way that said server cabinet must fit through, measuring up
at 620mm.

The cabinet chassis is welded at all four corners, so can't be taken apart
any more without being cut.

Can you see where this is leading yet? Three obvious questions:

1) Have you ever had to fit a cabinet through a doorway that's too small?
2) How did you do it? Cut cabinet, demolish wall ...?
3) If you cut the cabinet, any tips?

Thanks.
Rob


From leigh.porter at ukbroadband.com  Wed May  4 03:53:25 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 4 May 2011 09:53:25 +0100
Subject: Server Cabinet
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>


This may be a silly question but.. How did it get in there?

--
Leigh Porter


-----Original Message-----
From: Robert Lusby [mailto:nanogwp at gmail.com]
Sent: Wed 5/4/2011 9:43 AM
To: nanog at nanog.org
Subject: OT: Server Cabinet
 
Sorry to start the day OT, but I'm sure you lovely lot will have some
tips/experience! ;)

We have a HP Server Cabinet (42U 10842 G2), that we've stripped down to the
bare-bones chassis. It now measures 750mm wide.

We have a door-way that said server cabinet must fit through, measuring up
at 620mm.

The cabinet chassis is welded at all four corners, so can't be taken apart
any more without being cut.

Can you see where this is leading yet? Three obvious questions:

1) Have you ever had to fit a cabinet through a doorway that's too small?
2) How did you do it? Cut cabinet, demolish wall ...?
3) If you cut the cabinet, any tips?

Thanks.
Rob

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

From tom at ninjabadger.net  Wed May  4 03:58:43 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Wed, 04 May 2011 09:58:43 +0100
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <1304499523.1866.6.camel@teh-desktop>

On Wed, 2011-05-04 at 09:43 +0100, Robert Lusby wrote:
> 
> Can you see where this is leading yet? 

Is there no other entrance that's wider, perhaps a window/skylight? 

Cutting-up a cabinet (only to find that it's pretty impossible to make
it sturdy again) or demolishing the wall may well be more costly than
hiring a fork lift/crane, etc.

Just musing..

Tom




From jhma at mcvax.org  Wed May  4 04:06:15 2011
From: jhma at mcvax.org (James Aldridge)
Date: Wed, 04 May 2011 11:06:15 +0200
Subject: Server Cabinet
In-Reply-To: <B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
Message-ID: <4DC11707.7060509@mcvax.org>

On 04/05/2011 10:53, Leigh Porter wrote:
> This may be a silly question but.. How did it get in there?

I'm assuming that it's not yet "in there" :-)

I'd probably knock the wall down and fit a more reasonably sized door -
620mm (2') seems a bit narrow for a door anyway.

One could of course get a 600mm wide rack instead ...

Regards,
James



From woody at pch.net  Wed May  4 04:08:24 2011
From: woody at pch.net (Bill Woodcock)
Date: Wed, 4 May 2011 11:08:24 +0200
Subject: Server Cabinet
In-Reply-To: <4DC11707.7060509@mcvax.org>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
	<4DC11707.7060509@mcvax.org>
Message-ID: <29A17C26-04D5-4F72-BBBF-BD473152B4D4@pch.net>

I've removed the doorframe before, and usually replaced with a wider doorframe later. 

    
                -Bill


On May 4, 2011, at 11:07, James Aldridge <jhma at mcvax.org> wrote:

> On 04/05/2011 10:53, Leigh Porter wrote:
>> This may be a silly question but.. How did it get in there?
> 
> I'm assuming that it's not yet "in there" :-)
> 
> I'd probably knock the wall down and fit a more reasonably sized door -
> 620mm (2') seems a bit narrow for a door anyway.
> 
> One could of course get a 600mm wide rack instead ...
> 
> Regards,
> James
> 




From nanogwp at gmail.com  Wed May  4 04:09:33 2011
From: nanogwp at gmail.com (Robert Lusby)
Date: Wed, 4 May 2011 10:09:33 +0100
Subject: OT: Server Cabinet
In-Reply-To: <1304499523.1866.6.camel@teh-desktop>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<1304499523.1866.6.camel@teh-desktop>
Message-ID: <BANLkTin1qSUj_knOaMc4N+yaMe0odz3ROQ@mail.gmail.com>

Not a silly question my fault for not making clear - cabinet is still
outside the room ... yet to go in.

And, no other entrance points. Room is below ground level, with a stupidly
narrow door frame. Old client building, with a room not originally designed
for purpose.

Short of scrapping this cabinet, and looking for one where the chassis
unbolts also?

Rob


On Wed, May 4, 2011 at 9:58 AM, Tom Hill <tom at ninjabadger.net> wrote:

> On Wed, 2011-05-04 at 09:43 +0100, Robert Lusby wrote:
> >
> > Can you see where this is leading yet?
>
> Is there no other entrance that's wider, perhaps a window/skylight?
>
> Cutting-up a cabinet (only to find that it's pretty impossible to make
> it sturdy again) or demolishing the wall may well be more costly than
> hiring a fork lift/crane, etc.
>
> Just musing..
>
> Tom
>
>
>


From lists at internetpolicyagency.com  Wed May  4 04:22:04 2011
From: lists at internetpolicyagency.com (Roland Perry)
Date: Wed, 4 May 2011 10:22:04 +0100
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <4RknGwm8qRwNFApn@perry.co.uk>

In article <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w at mail.gmail.com>, Robert 
Lusby <nanogwp at gmail.com> writes
>1) Have you ever had to fit a cabinet through a doorway that's too small?

Yes, but it was height not width

>2) How did you do it? Cut cabinet, demolish wall ...?

by taking the fan tray off the top and the wheels off the bottom (I 
realise you've already stripped it down as far as you can go).

>3) If you cut the cabinet, any tips?

Also - do you ever want to get the cabinet back out (in one piece)?

ps My solution would be to buy a similar sized cabinet (assuming a 
slimmer one won't do) that needs assembling, and feed the parts through 
the door, rather than the complete item.
-- 
Roland Perry



From lists at internetpolicyagency.com  Wed May  4 04:34:26 2011
From: lists at internetpolicyagency.com (Roland Perry)
Date: Wed, 4 May 2011 10:34:26 +0100
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin1qSUj_knOaMc4N+yaMe0odz3ROQ@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<1304499523.1866.6.camel@teh-desktop>
	<BANLkTin1qSUj_knOaMc4N+yaMe0odz3ROQ@mail.gmail.com>
Message-ID: <zxTl+tni2RwNFArB@perry.co.uk>

In article <BANLkTin1qSUj_knOaMc4N+yaMe0odz3ROQ at mail.gmail.com>, Robert 
Lusby <nanogwp at gmail.com> writes

>Short of scrapping this cabinet

If you have no other use for it - sell on eBay! That's where my spare 
cabinet went last year.
-- 
Roland Perry



From woody at pch.net  Wed May  4 05:06:09 2011
From: woody at pch.net (Bill Woodcock)
Date: Wed, 4 May 2011 03:06:09 -0700
Subject: PCH survey on peering
Message-ID: <50D5AA5E-E467-4AC8-A765-DF7FBA9813FE@pch.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Over the past several months, Packet Clearing House has been working on a survey of peering agreements, to which many of you responded.  We are very grateful for your participation, and would like to share the resulting report:

    https://pch.net/resources/papers/peering-survey/PCH-Peering-Survey-2011.pdf

I anticipate that we will repeat this exercise in the future, perhaps a year from now, perhaps five years from now, depending upon how much demand we get for updates in the future.  If you feel that your perspective was insufficiently represented in our dataset, we would be very happy to include your information in future iterations.

Thank you all very much,

                                -Bill Woodcock
                                 Research Director
                                 Packet Clearing House





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk3BJREACgkQGvQy4xTRsBEzrgCgqt1kk2UXALiYByXrDt+UIs5s
GC8AoIbJNJZZ8h4mM9ybPVrKGCzOO2zX
=aXGo
-----END PGP SIGNATURE-----




From joly at punkcast.com  Wed May  4 06:09:48 2011
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 4 May 2011 07:09:48 -0400
Subject: =?windows-1252?Q?Tonight=3A_ISOC=2DNY_Event=3A_Cyrus_Farivar_=96_The_Intern?=
	=?windows-1252?Q?et_of_Elsewhere_=2D_NYU?=
In-Reply-To: <BANLkTi=Xk1==G-F5KPGWtq4yxvO_=zSD0w@mail.gmail.com>
References: <BANLkTimSqScuzJ3c5GDMSvfo7umA_JnvDA@mail.gmail.com>
	<BANLkTi=Xk1==G-F5KPGWtq4yxvO_=zSD0w@mail.gmail.com>
Message-ID: <BANLkTimomPkUggWQBrkzH97YvN_3Xi4sMg@mail.gmail.com>

You may have seen the recent Freedom House report on Internet
Freedom<http://www.freedomhouse.org/template.cfm?page=664>that cited
Estonia as the most free Internet in the world, and Iran as among
the least. As we know Korea has some of the fastest, while Senegal is
rapidly developing.  SO this should be an interesting talk about the
contrasts.. And there's bound to be some talk about infrastructure. I will
be webcasting. Questions can be asked via the backchannel.

On May 4 2011 the Internet Society?s New York Chapter (ISOC-NY) will present
broadcaster, author & journalist Cyrus Farivar reading and discussing his
imminent (May 8 ) book ?The Internet of
Elsewhere<http://internetofelsewhere.com/blog/>?
(Rutgers University Press). All welcome. There will be a live webcast.

In the book Farivar explores the Internet?s history and effects in four
distinct and, to some, surprising societies ? Iran, Estonia, South Korea,
and Senegal. He profiles Web pioneers in these countries and, at the same
time, surveys the environments in which they each work. After all, contends
Farivar, despite California?s great success in creating the Internet and
spawning companies like Apple and Google, in some areas the United States is
still years behind other nations.

*What*: Cyrus Farivar ? The Internet of Elsewhere
*When*: Wednesday 4 May 2011 7pm-9pm EDT (1100-0100 UTC)
*Where*: Warren Weaver Hall, rm 201, 251 Mercer Street, NY NY 10012
*Who*: Free. All welcome. Capacity limited. No RSVP reqd.
*Webcast*: http://livestream.com/internetsocietychapters
*Hashtags*: #isocny <http://search.twitter.com/search?q=isocny>;
#farivar<http://search.twitter.com/search?q=farivar>
*Back Channel*: http://backchan.nl/meetings/view/786

Homepage: http://isoc-ny.org/p2/?p=1934
-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From tshaw at oitc.com  Wed May  4 06:30:32 2011
From: tshaw at oitc.com (TR Shaw)
Date: Wed, 4 May 2011 07:30:32 -0400
Subject: Server Cabinet
In-Reply-To: <4DC11707.7060509@mcvax.org>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
	<4DC11707.7060509@mcvax.org>
Message-ID: <4081BC5D-A591-4A41-A032-0435F46C793C@oitc.com>


On May 4, 2011, at 5:06 AM, James Aldridge wrote:

> On 04/05/2011 10:53, Leigh Porter wrote:
>> This may be a silly question but.. How did it get in there?
> 
> I'm assuming that it's not yet "in there" :-)
> 
> I'd probably knock the wall down and fit a more reasonably sized door -
> 620mm (2') seems a bit narrow for a door anyway.
> 
> One could of course get a 600mm wide rack instead ...

I agree. Put the too big rack up on ebay and get a smaller one (or one you can get through the door.  This is gotta be cheaper than knocking down, dust abatement and rebuilding a wall. I am not big on cutting the rack unless you know a ME and a really good welder and that may still not be cheaper than sell and buy new.

Tom


From young at jsyoung.net  Wed May  4 06:40:32 2011
From: young at jsyoung.net (Jeffrey S. Young)
Date: Wed, 4 May 2011 21:40:32 +1000
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3064@RWC-EX1.corp.seven.com>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com>
	<4DBB0D68.40108@bogus.com>
	<BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com>
	<8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net>
	<0FEA65B1-76AA-4B57-B70A-70CE57AF628A@ianai.net>
	<5A6D953473350C4B9995546AFE9939EE0C9E305B@RWC-EX1.corp.seven.com>
	<770785CF-F492-4820-B9ED-5FDEC8661067@jsyoung.net>
	<5A6D953473350C4B9995546AFE9939EE0C9E3064@RWC-EX1.corp.seven.com>
Message-ID: <2488B066-C050-42EA-8DC5-D51AB220457E@jsyoung.net>



On 04/05/2011, at 1:54 AM, George Bonser <gbonser at seven.com> wrote:

>> 
>> Multicast is an elegant solution to a dwindling problem set.  
> 
> And that is fundamentally where we disagree.  I see this as not
> "elegant" at all.  It is a fundamental part of the protocol suite.  It
> is no more "elegant" than unicast.  I also believe that it will be the
> wireless operators that bring this back to widespread use as wireless
> devices are used for more than simply placing phone calls.  Time will
> tell, but it looks like the total use of multicast for content delivery
> is currently increasing.  It just isn't increasing in the realm of home
> internet providers, yet, but I believe it will as people use home
> internet for things that they had traditionally used other services for
> such as broadcast radio and tv.
> 
> 
I dunno,

I think it's elegant, in think Deering did an incredible job to
create it and some many years ago I played a role to bring
multicast to the Internet at large.  I believed that multicast
would play a huge role in the delivery of content, then.  

Trouble was that the way that people want to consume
video means most of it is time-shifted.  Folks in charge of
networks didn't understand the technology and marketing
people thought turning on multicast meant giving something 
away.  I finally settled on the notion that multicast is a tool
for service providers/enterprises to use but that it wouldn't 
ever be as pervasive as I'd hoped.

As for wireless operators?  The wireless medium itself is a 
broadcast network, why bother with multicast?

jy



From bonomi at mail.r-bonomi.com  Wed May  4 07:27:27 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 4 May 2011 07:27:27 -0500 (CDT)
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <201105041227.p44CRRO6073574@mail.r-bonomi.com>


> Date: Wed, 4 May 2011 09:43:53 +0100
> Subject: OT: Server Cabinet
> From: Robert Lusby <nanogwp at gmail.com>
>
> Sorry to start the day OT, but I'm sure you lovely lot will have some
> tips/experience! ;)
>
> We have a HP Server Cabinet (42U 10842 G2), that we've stripped down to the
> bare-bones chassis. It now measures 750mm wide.
>
> We have a door-way that said server cabinet must fit through, measuring up
> at 620mm.
>
> The cabinet chassis is welded at all four corners, so can't be taken apart
> any more without being cut.
>
> Can you see where this is leading yet? Three obvious questions:
>
> 1) Have you ever had to fit a cabinet through a doorway that's too small?
> 2) How did you do it? Cut cabinet, demolish wall ...?
> 3) If you cut the cabinet, any tips?

Comment:  you need to recognize that you are 'making trouble'.  At _some_
point in the future, there will be a need to remove said cabinet from that
location, and the issue will rear it's ugly head *again*.

Suggestion: If there is no alternative to that narrow doorway, consider:
   a) getting a *different* cabinet -- one that _will_ dis-assemble.
   b) if 'all else fails', _widen_ the doorway.  Thus permanently resolving
      the issue.

Option (a) _is_ going to be less time/effort/money than any other alternative.





From jgreco at ns.sol.net  Wed May  4 07:58:51 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 4 May 2011 07:58:51 -0500 (CDT)
Subject: OT: Server Cabinet
In-Reply-To: <201105041227.p44CRRO6073574@mail.r-bonomi.com>
Message-ID: <201105041258.p44Cwpif083198@aurora.sol.net>

> > Can you see where this is leading yet? Three obvious questions:
> >
> > 1) Have you ever had to fit a cabinet through a doorway that's too small?
> > 2) How did you do it? Cut cabinet, demolish wall ...?
> > 3) If you cut the cabinet, any tips?
> 
> Comment:  you need to recognize that you are 'making trouble'.  At _some_
> point in the future, there will be a need to remove said cabinet from that
> location, and the issue will rear it's ugly head *again*.
> 
> Suggestion: If there is no alternative to that narrow doorway, consider:
>    a) getting a *different* cabinet -- one that _will_ dis-assemble.
>    b) if 'all else fails', _widen_ the doorway.  Thus permanently resolving
>       the issue.
> 
> Option (a) _is_ going to be less time/effort/money than any other alternative.

Good comments so far.  I didn't see this one though:

It's admittedly far from ideal in some ways, but a great way to deal
with this sort of situation can be to get a pair of two-post open
frame relay racks; most of them bolt together and can be put just
about anywhere.  Many times we forget that these can be used as the 
front and back of a single rack.  Remember to tie them together if 
you go that route, attachment to a wall or up top highly recommended
as well.

Of course, this only works if you didn't really need doors on your
rack, etc.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.



From dorn at hetzel.org  Wed May  4 08:04:03 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 4 May 2011 09:04:03 -0400
Subject: OT: Server Cabinet
In-Reply-To: <201105041258.p44Cwpif083198@aurora.sol.net>
References: <201105041227.p44CRRO6073574@mail.r-bonomi.com>
	<201105041258.p44Cwpif083198@aurora.sol.net>
Message-ID: <BANLkTinsMRVW20X6Pq0sJjioKts9q3R4sA@mail.gmail.com>

>
> It's admittedly far from ideal in some ways, but a great way to deal
> with this sort of situation can be to get a pair of two-post open
> frame relay racks; most of them bolt together and can be put just
> about anywhere.  Many times we forget that these can be used as the
> front and back of a single rack.  Remember to tie them together if
> you go that route, attachment to a wall or up top highly recommended
> as well.
>
> I've gone this route.  Plusses are you can have pretty much any depth you
want.  If you can bolt them to the floor they're really stable.


From rcarpen at network1.net  Wed May  4 08:15:55 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Wed, 04 May 2011 09:15:55 -0400 (EDT)
Subject: OT: Server Cabinet
In-Reply-To: <201105041258.p44Cwpif083198@aurora.sol.net>
References: <201105041258.p44Cwpif083198@aurora.sol.net>
Message-ID: <5B8FAD10-1ABE-4376-AFF5-0F00E63FBB52@network1.net>

If you have a need for a 4-post rack, do not accomplish that by using 2 2-post racks. You will likely find that rack rails that are designed for a 4-post rack will not fit.

Get an open-frame 4-post rack. It will come unassembled. It will also likely be no more costly that 2 2-post racks.


-Randy

On May 4, 2011, at 8:59, Joe Greco <jgreco at ns.sol.net> wrote:

>>> Can you see where this is leading yet? Three obvious questions:
>>> 
>>> 1) Have you ever had to fit a cabinet through a doorway that's too small?
>>> 2) How did you do it? Cut cabinet, demolish wall ...?
>>> 3) If you cut the cabinet, any tips?
>> 
>> Comment:  you need to recognize that you are 'making trouble'.  At _some_
>> point in the future, there will be a need to remove said cabinet from that
>> location, and the issue will rear it's ugly head *again*.
>> 
>> Suggestion: If there is no alternative to that narrow doorway, consider:
>>   a) getting a *different* cabinet -- one that _will_ dis-assemble.
>>   b) if 'all else fails', _widen_ the doorway.  Thus permanently resolving
>>      the issue.
>> 
>> Option (a) _is_ going to be less time/effort/money than any other alternative.
> 
> Good comments so far.  I didn't see this one though:
> 
> It's admittedly far from ideal in some ways, but a great way to deal
> with this sort of situation can be to get a pair of two-post open
> frame relay racks; most of them bolt together and can be put just
> about anywhere.  Many times we forget that these can be used as the 
> front and back of a single rack.  Remember to tie them together if 
> you go that route, attachment to a wall or up top highly recommended
> as well.
> 
> Of course, this only works if you didn't really need doors on your
> rack, etc.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
> With 24 million small businesses in the US alone, that's way too many apples.
> 
> 



From jlewis at lewis.org  Wed May  4 08:20:10 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 4 May 2011 09:20:10 -0400 (EDT)
Subject: OT: Server Cabinet
In-Reply-To: <201105041258.p44Cwpif083198@aurora.sol.net>
References: <201105041258.p44Cwpif083198@aurora.sol.net>
Message-ID: <Pine.LNX.4.61.1105040918180.5148@soloth.lewis.org>

On Wed, 4 May 2011, Joe Greco wrote:

> Good comments so far.  I didn't see this one though:
>
> It's admittedly far from ideal in some ways, but a great way to deal
> with this sort of situation can be to get a pair of two-post open
> frame relay racks; most of them bolt together and can be put just
> about anywhere.  Many times we forget that these can be used as the
> front and back of a single rack.  Remember to tie them together if
> you go that route, attachment to a wall or up top highly recommended
> as well.

I was about to suggest that.  Chatsworth actually makes hardware just for 
this.

http://www.chatsworth.com/uploadedFiles/Files/50110_CUT.pdf

We have a number of these which we've used to convert left over 2-post 
relay racks into sturdy 4-post racks.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From bill at herrin.us  Wed May  4 08:14:25 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 4 May 2011 09:14:25 -0400
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <BANLkTinJwusoYpX15aXvFc9nq420FpDv4A@mail.gmail.com>

On Wed, May 4, 2011 at 4:43 AM, Robert Lusby <nanogwp at gmail.com> wrote:
>We have a HP Server Cabinet (42U 10842 G2), that we've stripped down to the
>bare-bones chassis. It now measures 750mm wide.
>
> We have a door-way that said server cabinet must fit through, measuring up
> at 620mm.

Hi Rob,

My first reaction on hearing that you have a two-foot doorway to move
this cabinet through is: what else is wrong with the room that makes
it entirely unsuitable for hosting a server cabinet? There's adequate
power behind a home bathroom-size doorway? Adequate cooling? Adequate
clearance around the cabinet once past the doorway?

An HP 10642 cabinet is 597mm wide. Ditch the extra-wide cabinet and
use 1U power strips instead of the so-called zero-U jobbies. A 10636
cabinet is shorter too, making it easier to fit in small spaces.

-Bill


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From jgreco at ns.sol.net  Wed May  4 09:21:00 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 4 May 2011 09:21:00 -0500 (CDT)
Subject: OT: Server Cabinet
In-Reply-To: <5B8FAD10-1ABE-4376-AFF5-0F00E63FBB52@network1.net>
Message-ID: <201105041421.p44EL0rN084318@aurora.sol.net>

> If you have a need for a 4-post rack, do not accomplish that by using 2 2-po=
> st racks. You will likely find that rack rails that are designed for a 4-pos=
> t rack will not fit.

Why?  With *any* rack, there are always scenarios where the rack rails for
some random item don't end up fitting right.  That's certainly not a problem
inherent to two 2-post racks.  You can find 2-post racks in any number of
interesting and unusual post/flange configurations.  It's certainly true 
that picking any old random 2-post rack has certain hazards associated with
it - the solution is don't pick "any old random" one, not "don't pick a 
2-post rack."  But the look-before-buying rule applies to any rack you buy,
doesn't it?

> Get an open-frame 4-post rack. It will come unassembled.

Most of the open-frame 4-post racks I've seen are actually less sturdy
than two 2-post racks; the 2-post racks are generally designed to hold
a Lot Of Stuff.  In other words, many 4-post racks are not really 
designed for that much weight.  For example, look at the Middle Atlantic
Slim 5, which only has a weight capacity of 400 pounds.

http://www.middleatlantic.com/enclosure/knock/slim5.htm

The RL10-45, on the other hand, has a 1600 lb weight capacity,

http://www.middleatlantic.com/dcm/rack/rl.htm

so double that for two of them and then reduce it for a safety margin
and you have maybe 2000 lb capacity.  I can probably *find* four-post
units with greater weight capacity, but I suspect that two 2-post racks
will tend to have greater capacity just because the design of a 2-post
unit is more likely to allow for heavy gear being mounted on it.

Now of course we have no idea what's going to be mounted in this, but
it's an HP rack so I assume maybe HP servers, which tend towards the
heavy.

http://h18000.www1.hp.com/products/servers/proliantstorage/racks/10000series-g2/index.html

suggests a 2000lb maximum static load requirement.

> It will also likely=
>  be no more costly that 2 2-post racks.

Hm.  Maybe.

Distributor:

SLIM 5 KNOCK DOWN 37 SP, 20" DEEP			$275.99
MIDDLE ATLANTIC - U.S.

Found online:
http://salestores.com/apwmay2273.html			$90.78

So I'm a little skeptical about that too.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.



From bicknell at ufp.org  Wed May  4 09:27:11 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 4 May 2011 07:27:11 -0700
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin1qSUj_knOaMc4N+yaMe0odz3ROQ@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<1304499523.1866.6.camel@teh-desktop>
	<BANLkTin1qSUj_knOaMc4N+yaMe0odz3ROQ@mail.gmail.com>
Message-ID: <20110504142711.GA26628@ussenterprise.ufp.org>

In a message written on Wed, May 04, 2011 at 10:09:33AM +0100, Robert Lusby wrote:
> And, no other entrance points. Room is below ground level, with a stupidly
> narrow door frame. Old client building, with a room not originally designed
> for purpose.

I think folks can help you find a bolt together rack, but I urge
you to think one step further.

I'm making an assumption that this is a fairly small room, a closet
or similar.  I do that because even in an old building a room would
not likely have a 2' doorway.  This raises several questions:

Would you be able to get to both sides of the rack and side things
all the way out to service them in this space?

How are you going to cool the space?

Are the power circuits in that room up to powering a full rack of
equipment?

Will fan and equipment noise annoy adjacent rooms?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110504/fa3ffed1/attachment.bin>

From cmadams at hiwaay.net  Wed May  4 09:33:20 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 4 May 2011 09:33:20 -0500
Subject: OT: Server Cabinet
In-Reply-To: <201105041421.p44EL0rN084318@aurora.sol.net>
References: <5B8FAD10-1ABE-4376-AFF5-0F00E63FBB52@network1.net>
	<201105041421.p44EL0rN084318@aurora.sol.net>
Message-ID: <20110504143320.GB29720@hiwaay.net>

Once upon a time, Joe Greco <jgreco at ns.sol.net> said:
> Now of course we have no idea what's going to be mounted in this, but
> it's an HP rack so I assume maybe HP servers, which tend towards the
> heavy.

One thing about using a 2-post rack for servers that can be a problem is
that most 2-post racks I've seen have tapped holes, ready for screws,
and some server rails (such as Dell) pretty much require square hole or
round hole racks instead.  You can get third-party server rails that
will work with a tapped hole rack, but that's an extra expense (and
irritation).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From jgreco at ns.sol.net  Wed May  4 09:44:35 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 4 May 2011 09:44:35 -0500 (CDT)
Subject: OT: Server Cabinet
In-Reply-To: <20110504143320.GB29720@hiwaay.net>
Message-ID: <201105041444.p44EiZ5u084762@aurora.sol.net>

> Once upon a time, Joe Greco <jgreco at ns.sol.net> said:
> > Now of course we have no idea what's going to be mounted in this, but
> > it's an HP rack so I assume maybe HP servers, which tend towards the
> > heavy.
> 
> One thing about using a 2-post rack for servers that can be a problem is
> that most 2-post racks I've seen have tapped holes, ready for screws,
> and some server rails (such as Dell) pretty much require square hole or
> round hole racks instead.  You can get third-party server rails that
> will work with a tapped hole rack, but that's an extra expense (and
> irritation).

That's a good point.  Without knowing the intended equipment load, it
is difficult to give good advice on this part.

However, since it's an HP rack, an obvious guess might be HP servers,
and I will note that the HP rails I've seen, while designed for square
or round hole racks, do allow the little peglets to be removed, and
are then compatible with most racks I've seen.  Unfortunately they 
have a thread-lock compound on them, so be prepared to sit down with
a flat blade power screwdriver and some pliers; removal is about 2
minutes per set of rails that way.

I've come to like the HP server gear a whole lot more than Dell over 
the years.  Little things like that are one of the reasons.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.



From jakari at bithose.com  Wed May  4 09:58:33 2011
From: jakari at bithose.com (Jameel Akari)
Date: Wed, 4 May 2011 10:58:33 -0400 (EDT)
Subject: OT: Server Cabinet
In-Reply-To: <201105041421.p44EL0rN084318@aurora.sol.net>
References: <201105041421.p44EL0rN084318@aurora.sol.net>
Message-ID: <alpine.LRH.2.02.1105041035020.6008@zed.bithose.com>


On Wed, 4 May 2011, Joe Greco wrote:

>> If you have a need for a 4-post rack, do not accomplish that by using 2 2-po=
>> st racks. You will likely find that rack rails that are designed for a 4-pos=
>> t rack will not fit.

Possibly, though you can usually order "universal" rails to fit 
tapped-hole racks.  It's a hassle, and usually an unaccounted expense. 
And IME these rails aren't nearly as nice on your hands and sanity as the 
snap-in rails most server mfrs ship standard.

>> Get an open-frame 4-post rack. It will come unassembled.

I'd suggest getting an actual cabinet that you can order unassembled. 
I'm thinking specifically of the excellent CPI Megaframe cabinets.  The 
only parts that don't knock down are the bases, tops, doors and sides - 
and you can carry those easily through the door.  The uprights and braces 
are extruded aluminum, and then your actual mounting rails (in square 
hole, round punched, tapped threads, or any combination) are steel, bolted 
inside of those.

When we closed one datacenter and found we had to scrap 40 of these things 
(!!!) I took apart four and they all fit inside my normal-sized car.  They 
were very easy to then carry down the winding narrow staircase to my 
basement. ;)

If you're very tight on space inside the room, you can get different door 
options, or just omit them entirely.  This changes your thermal and 
acoustical management, but I'm guessing you already have some challenges 
there, if your door is any indication.

These CPI cabinets are not cheap, but they are very nice, can be carried 
through tight/low doorways in lightweight sections, and have considerable 
load ratings.  2000 pounds I think.

All that said, I have removed and disassembled door frames, ceilings, 
walls, whatever to deal with whatever issues where we couldn't take racks 
apart or otherwise spend our way through it.  This doesn't work so well 
when you have concrete walls, welded doorframes, or unforgiving landlords. 
;)

-- 
Jameel Akari



From lowen at pari.edu  Wed May  4 10:00:20 2011
From: lowen at pari.edu (Lamar Owen)
Date: Wed, 4 May 2011 11:00:20 -0400
Subject: [c-nsp] 7600 SXF and IPv6
In-Reply-To: <alpine.DEB.2.02.1105031246010.31041@seatpost.its.uiowa.edu>
References: <BANLkTikc6XuOsA6=X4rBw8VPUQ0JrPPn0g@mail.gmail.com>
Message-ID: <201105041100.20766.lowen@pari.edu>

On Tuesday, May 03, 2011 01:54:00 PM Jay Ford wrote:
> On Tue, 3 May 2011, vince anton wrote:
> > Anyone has experiemces to share or known v6 issues with SXF (or v4 issues
> > with v6 enabled for that matter), or should I be looking at SRC/SRD/SRE for
> > 7600 ?

> I have 9 6500+SUP720-3BXL boxes with a mix of CFCs & DFCs running 
> ADVIPSERVICESK9_WAN-M 12.2(33)SXI1, 12.2(33)SXI4a, & 12.2(33)SXI5 

While the hardware capabilities are essentially the same, he is on a 7600, not a 6500.  With SXF it didn't matter; with later it does, and he can't use SXI, but must derail that train to pick up the SRx train, which has different capabilities and issues.

To Anton, the OP, you need to look at the SXF and rebuilds release notes and see what they say; there are a lot of things to look at, and going SRx is going to change things for you; since I'm on Sup2 with SXF I can't go SRx with our 7600's anyway (chassis won't take Sup720 anyway; these are the OSR7609-branded (and epromed) clones of the 6509NEBS chassis that needs the special high speed fan upgrade that is so hard to find these days....).  

And be sure to peruse the NANOG mailing list archives and read about the 6500-7600 split, especially the comments fom Gert.....



From chaim.rieger at gmail.com  Wed May  4 10:07:36 2011
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Wed, 4 May 2011 08:07:36 -0700
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <BANLkTin20xcQxVSf5J448bu-uU7=n7qT2Q@mail.gmail.com>

Do you have any kids ?
If yes ask them to do it, leave and come back a few hours later


From jason at thebaughers.com  Wed May  4 10:22:01 2011
From: jason at thebaughers.com (Jason Baugher)
Date: Wed, 04 May 2011 10:22:01 -0500
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin20xcQxVSf5J448bu-uU7=n7qT2Q@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<BANLkTin20xcQxVSf5J448bu-uU7=n7qT2Q@mail.gmail.com>
Message-ID: <4DC16F19.1050600@thebaughers.com>

On 5/4/2011 10:07 AM, Chaim Rieger wrote:
> Do you have any kids ?
> If yes ask them to do it, leave and come back a few hours later
>
At last, a helpful answer!

Seriously, disregarding all the helpful comments from everyone 
questioning your judgment in trying to move a large cabinet through a 
small door...

    * cut the cabinet into smaller pieces, move through door,
      re-assemble via your preferred method, be it welder, chewing gum
      or duct tape
    * make the door bigger, which would mean that if you decide at some
      point you want to move the cabinet again, you won't have this issue
    * bend the very fabric of space and time itself to place the cabinet
      inside the room without going through the door


I'd pick the second one, but if you go with the third let me know so I 
can watch.

Jason


From jra at baylink.com  Wed May  4 11:04:03 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 4 May 2011 12:04:03 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <2488B066-C050-42EA-8DC5-D51AB220457E@jsyoung.net>
Message-ID: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeffrey S. Young" <young at jsyoung.net>

> I think it's elegant, in think Deering did an incredible job to
> create it and some many years ago I played a role to bring
> multicast to the Internet at large. I believed that multicast
> would play a huge role in the delivery of content, then.
> 
> Trouble was that the way that people want to consume
> video means most of it is time-shifted. Folks in charge of
> networks didn't understand the technology and marketing
> people thought turning on multicast meant giving something
> away. I finally settled on the notion that multicast is a tool
> for service providers/enterprises to use but that it wouldn't
> ever be as pervasive as I'd hoped.

I think that George's POV -- which is also mine -- is that as the world
shifts, the percentage of video distribution which is amenable to multicast,
and not well served by unicast, is likely to grow, and it would be a Good
Idea to be ready for that situation already when it arrives.

Cheers,
-- jra



From jra at baylink.com  Wed May  4 11:09:55 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 4 May 2011 12:09:55 -0400 (EDT)
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin20xcQxVSf5J448bu-uU7=n7qT2Q@mail.gmail.com>
Message-ID: <32480192.587.1304525395322.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Chaim Rieger" <chaim.rieger at gmail.com>

> Do you have any kids ?
> If yes ask them to do it, leave and come back a few hours later

And the Webby for Best Short Answer to a NANOG Question goes ... to.

What's your 5 word acceptance speech, Chaim?

Cheers,
-- jra



From tim at pelican.org  Wed May  4 11:26:10 2011
From: tim at pelican.org (Tim Franklin)
Date: Wed, 04 May 2011 17:26:10 +0100 (BST)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
Message-ID: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>

> I think that George's POV -- which is also mine -- is that as the
> world shifts, the percentage of video distribution which is
> amenable to multicast, and not well served by unicast, is likely
> to grow, and it would be a Good Idea to be ready for that
> situation already when it arrives.

Really?  If anything, I'd say quite the opposite.  Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot.  (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning).  I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.

I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.

Regards,
Tim.



From leigh.porter at ukbroadband.com  Wed May  4 11:45:32 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 4 May 2011 17:45:32 +0100
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
Message-ID: <B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>

> 
> > I think that George's POV -- which is also mine -- is that as the
> > world shifts, the percentage of video distribution which is
> > amenable to multicast, and not well served by unicast, is likely
> > to grow, and it would be a Good Idea to be ready for that
> > situation already when it arrives.
> 
> Really?  If anything, I'd say quite the opposite.  Watching media in
> the time-slot that someone else has decided on is *so* 20th-century - I
> can't remember the last time I sat down to actively watch a programme
> in its original transmission slot.  (As opposed to having the TV on as
> background, e.g. 15 minutes of breakfast news in the morning).  I guess
> multicast to a recording application (or appliance) might work - but
> essentially my requirement is strongly skewed towards video-on-demand.

Agreed, it seems the only demand really for this live viewing is sport, news 
and background programming like the mentioned breakfast television.

But there is still the demand to just have something on in the background, 
whatever that may be. 

> I have absolutely zero interest in sport of any kind though - I'm given
> to understand there's quite a high demand for live viewing of that.

Apparently so.. 

--
Leigh Porter



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

From khelms at ispalliance.net  Wed May  4 11:53:08 2011
From: khelms at ispalliance.net (Scott Helms)
Date: Wed, 04 May 2011 12:53:08 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
References: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
Message-ID: <4DC18474.2080902@ispalliance.net>

On 5/4/2011 12:26 PM, Tim Franklin wrote:
>> I think that George's POV -- which is also mine -- is that as the
>> world shifts, the percentage of video distribution which is
>> amenable to multicast, and not well served by unicast, is likely
>> to grow, and it would be a Good Idea to be ready for that
>> situation already when it arrives.
> Really?  If anything, I'd say quite the opposite.  Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot.  (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning).  I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
>
> I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
>
> Regards,
> Tim.
>
>

I agree, I think less and less content will be multicast with live 
events (like sports) being the notable exception.  Having said that I 
think that multicast will increase in importance as more live events 
move into the remotely viewable venue.  There is a huge market for 
concerts, live pays, comedy, and other content that just isn't available 
right now.  The viewing market will continue to fragment requiring more 
sources of content than are available today.  In short the percentage of 
video sent as multicast will decrease (IMO) over time but the overall 
volume will increase as total video content as IP greatly expands.


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------




From bzs at world.std.com  Wed May  4 12:59:45 2011
From: bzs at world.std.com (Barry Shein)
Date: Wed, 4 May 2011 13:59:45 -0400
Subject: Server Cabinet
In-Reply-To: <B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
Message-ID: <19905.37905.856294.132318@world.std.com>


https://www.facebook.com/photo.php?fbid=142997624312&set=a.131293284312.94985.507204312&type=1&theater


-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*



From jsw at inconcepts.biz  Wed May  4 13:07:33 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 4 May 2011 14:07:33 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
Message-ID: <BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>

On Wed, May 4, 2011 at 12:45 PM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
> Agreed, it seems the only demand really for this live viewing is sport, news
> and background programming like the mentioned breakfast television.

I disagree with the general notion that multicast is not useful except
for live content.  Allow me to give a couple of examples that would
probably be implemented if we really had a multicast-enabled Internet,
end-to-end:

WINDOWS UPDATES
Most of us have some number of Windows machines on our networks,
probably a large number.  These updates are pervasive, and yet they
are largely delivered to end-users as unicast downloads.  If we all
had mcast, the latest and greatest Windows Update would probably be
available via mcast, and your PC would join the appropriate group,
receive the update, and be able to install it, without any unicast
traffic at all.  There may be several groups for users who have
different access network speeds, and your machine may need to
fall-back to unicast to retrieve last week's updates or get
packets/chunks that it missed, but this is far from difficult to
implement.

ON-DEMAND MOVIES
While on-demand movies are unicast today, there's no reason a content
provider couldn't take advantage of multicast for the most popular
movies, let's say "new releases."  We know that the latest movies are
more popular than older titles, because they consume much more shelf
space at Blockbuster, and more storage slots in the corner RedBox.  I
might receive the first few minutes of my on-demand movie by unicast,
and "catch up" to a high-speed multicast stream which repeatedly
"plays" the same movie, faster than the real-time data rate, for users
with sufficient access speed to download it.  My set-top-box would
transition from unicast to cached data it received via mcast,
resulting in a large bandwidth savings for popular titles.

As you can see, multicast can be useful for distribution of popular
time-shifted content and data, not just sports, news, and traditional
live programming.  Whether or not we ever see wide adoption of
multicast support on end-user access networks, well, that seems
increasingly unlikely given the consolidation of ISP/last-mile and
content producers/owners.  The less ISP networks look like "common
carriers" from a business perspective, the less motive they have to
act like a common carrier, and provide efficient, cost-effective
access to anything users wish to download.

For someone like Comcast, multicast is the ultimate "boogie man."
End-users being able to originate content at low cost to anyone and
everyone, without expensive CDNs or network connectivity?  I could
start my own movie channel, license some indie films I want to stream,
throw some ads over them, and be in competition with traditional
television networks who pay for satellite transponders, negotiate for
carriage, etc.  There is no way a Comcast/NBC Universal would ever
make the mistake of giving their users unfettered access to multicast.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From khelms at ispalliance.net  Wed May  4 13:22:20 2011
From: khelms at ispalliance.net (Scott Helms)
Date: Wed, 04 May 2011 14:22:20 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>	<B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
Message-ID: <4DC1995C.20202@ispalliance.net>

On 5/4/2011 2:07 PM, Jeff Wheeler wrote:
> On Wed, May 4, 2011 at 12:45 PM, Leigh Porter
> <leigh.porter at ukbroadband.com>  wrote:
>> Agreed, it seems the only demand really for this live viewing is sport, news
>> and background programming like the mentioned breakfast television.
> I disagree with the general notion that multicast is not useful except
> for live content.  Allow me to give a couple of examples that would
> probably be implemented if we really had a multicast-enabled Internet,
> end-to-end:
>
> WINDOWS UPDATES
> Most of us have some number of Windows machines on our networks,
> probably a large number.  These updates are pervasive, and yet they
> are largely delivered to end-users as unicast downloads.  If we all
> had mcast, the latest and greatest Windows Update would probably be
> available via mcast, and your PC would join the appropriate group,
> receive the update, and be able to install it, without any unicast
> traffic at all.  There may be several groups for users who have
> different access network speeds, and your machine may need to
> fall-back to unicast to retrieve last week's updates or get
> packets/chunks that it missed, but this is far from difficult to
> implement.

Local caching is MUCH more efficient than having the same traffic 
running in streams and depending on everyone's PC to try and update in 
the same time frame.
> ON-DEMAND MOVIES
> While on-demand movies are unicast today, there's no reason a content
> provider couldn't take advantage of multicast for the most popular
> movies, let's say "new releases."  We know that the latest movies are
> more popular than older titles, because they consume much more shelf
> space at Blockbuster, and more storage slots in the corner RedBox.  I
> might receive the first few minutes of my on-demand movie by unicast,
> and "catch up" to a high-speed multicast stream which repeatedly
> "plays" the same movie, faster than the real-time data rate, for users
> with sufficient access speed to download it.  My set-top-box would
> transition from unicast to cached data it received via mcast,
> resulting in a large bandwidth savings for popular titles.

Same issue as above, even if I am watching the latest popular movie 
moving between a multicast and unicast stream everytime I pause it to 
get another beer isn't realistic.  The chances that there will be a 
multicast stream that will be in synch with me is not high at all.
> As you can see, multicast can be useful for distribution of popular
> time-shifted content and data, not just sports, news, and traditional
> live programming.

I don't think your examples demonstrate that nor do I think the service 
providers, even the folks that understand what is meant by the term, 
fear multicast at all.  They do feel threatened by the increase in 
unicast OTT video but multicast in large amounts without the layer 1/2 
service provider being engaged is a long way off.

-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------




From darcy at druid.net  Wed May  4 13:22:59 2011
From: darcy at druid.net (D'Arcy J.M. Cain)
Date: Wed, 4 May 2011 14:22:59 -0400
Subject: Server Cabinet
In-Reply-To: <19905.37905.856294.132318@world.std.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
	<19905.37905.856294.132318@world.std.com>
Message-ID: <20110504142259.0b3134ce.darcy@druid.net>

On Wed, 4 May 2011 13:59:45 -0400
Barry Shein <bzs at world.std.com> wrote:
> https://www.facebook.com/photo.php?fbid=142997624312&set=a.131293284312.94985.507204312&type=1&theater

"You must log in to see this page."

Please don't post links that require passwords.	

-- 
D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.



From alex at corp.nac.net  Wed May  4 13:26:13 2011
From: alex at corp.nac.net (Alex Rubenstein)
Date: Wed, 4 May 2011 14:26:13 -0400
Subject: Server Cabinet
In-Reply-To: <20110504142259.0b3134ce.darcy@druid.net>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
	<19905.37905.856294.132318@world.std.com>
	<20110504142259.0b3134ce.darcy@druid.net>
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8010860292E@EXCHMBX.hq.nac.net>

Or:

This content is currently unavailable
The page you requested cannot be displayed right now. It may be temporarily unavailable, the link you clicked on may have expired, or you may not have permission to view this page.



> -----Original Message-----
> From: D'Arcy J.M. Cain [mailto:darcy at druid.net]
> Sent: Wednesday, May 04, 2011 2:23 PM
> To: Barry Shein
> Cc: nanog at nanog.org
> Subject: Re: Server Cabinet
> 
> On Wed, 4 May 2011 13:59:45 -0400
> Barry Shein <bzs at world.std.com> wrote:
> >
> https://www.facebook.com/photo.php?fbid=142997624312&set=a.1312932843
> 12.94985.507204312&type=1&theater
> 
> "You must log in to see this page."
> 
> Please don't post links that require passwords.
> 
> --
> D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
> http://www.druid.net/darcy/                |  and a sheep voting on
> +1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.



From gbonser at seven.com  Wed May  4 13:37:23 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 4 May 2011 11:37:23 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com><3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org><B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>

> 
> I disagree with the general notion that multicast is not useful except
> for live content.

Oh, there are all SORTS of things it would be well-suited for.  Live
content is just the lowest hanging fruit.


> WINDOWS UPDATES
> Most of us have some number of Windows machines on our networks,
> probably a large number.  These updates are pervasive, and yet they
> are largely delivered to end-users as unicast downloads.  If we all
> had mcast, the latest and greatest Windows Update would probably be
> available via mcast, and your PC would join the appropriate group,
> receive the update, and be able to install it, without any unicast
> traffic at all.  There may be several groups for users who have
> different access network speeds, and your machine may need to
> fall-back to unicast to retrieve last week's updates or get
> packets/chunks that it missed, but this is far from difficult to
> implement.

As anyone can send packets to a multicast group, I would be very wary of
such a thing. However, notification that an update is available could be
multicast which would greatly reduce polling.

> I
> might receive the first few minutes of my on-demand movie by unicast,
> and "catch up" to a high-speed multicast stream which repeatedly
> "plays" the same movie, faster than the real-time data rate, for users
> with sufficient access speed to download it.  My set-top-box would
> transition from unicast to cached data it received via mcast,
> resulting in a large bandwidth savings for popular titles.

Interesting notion assuming you decided to watch shortly enough into the
movie to do this.  Another alternative would be to simply have regularly
scheduled show times ... but that isn't exactly "on demand" but a "your
movie will begin in 5 minutes" while additional users are lined up on a
multicast group would still have some potential value.  Or maybe even
some hybrid of the two approaches.

Generally, any content that might be of interest to multiple users at
the same time can generally take advantage of multicast, even if it is
only a notification of something.  Say twitter used a multicast group to
broadcast tweets with the most popular hashtags.  A large number of
clients could pick up those tweets without having to poll for them.
Others would catch up using the conventional poll but it would have the
potential to greatly reduce the amount of information that would
transfer on such polls.

There is a security aspect to such things, though, as how do you know
the content is from a trusted source?  That is the bugaboo with
multicast.  It needs to be information that isn't going to hurt anything
if it is bogus.  Also, it opens up a DoS possibility with noise traffic
sent to the multicast group.




From ken at sizone.org  Wed May  4 14:23:54 2011
From: ken at sizone.org (Ken Chase)
Date: Wed, 4 May 2011 15:23:54 -0400
Subject: Server Cabinet
In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB8010860292E@EXCHMBX.hq.nac.net>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B8200339AFCB@ukbb3.ukbroadband.com>
	<19905.37905.856294.132318@world.std.com>
	<20110504142259.0b3134ce.darcy@druid.net>
	<2D0AF14BA6FB334988BC1F5D4FC38CB8010860292E@EXCHMBX.hq.nac.net>
Message-ID: <20110504192354.GV21636@sizone.org>

On Wed, May 04, 2011 at 02:26:13PM -0400, Alex Rubenstein said:
  >Or:
  >
  >This content is currently unavailable
  >The page you requested cannot be displayed right now. It may be temporarily unavailable, the link you clicked on may have expired, or you may not have permission to view this page.

gated-community internet FAIL

/kc

  >
  >
  >
  >> -----Original Message-----
  >> From: D'Arcy J.M. Cain [mailto:darcy at druid.net]
  >> Sent: Wednesday, May 04, 2011 2:23 PM
  >> To: Barry Shein
  >> Cc: nanog at nanog.org
  >> Subject: Re: Server Cabinet
  >> 
  >> On Wed, 4 May 2011 13:59:45 -0400
  >> Barry Shein <bzs at world.std.com> wrote:
  >> >
  >> https://www.facebook.com/photo.php?fbid=142997624312&set=a.1312932843
  >> 12.94985.507204312&type=1&theater
  >> 
  >> "You must log in to see this page."
  >> 
  >> Please don't post links that require passwords.
  >> 
  >> --
  >> D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
  >> http://www.druid.net/darcy/                |  and a sheep voting on
  >> +1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.



From jsw at inconcepts.biz  Wed May  4 14:37:48 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 4 May 2011 15:37:48 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <4DC1995C.20202@ispalliance.net>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<4DC1995C.20202@ispalliance.net>
Message-ID: <BANLkTi==PYvidmnmiyFEp6C3sikLVQd1KA@mail.gmail.com>

On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms at ispalliance.net> wrote:
> Local caching is MUCH more efficient than having the same traffic running in
> streams and depending on everyone's PC to try and update in the same time

This only works, of course, if there is a local cache which PCs are aware of.

> Same issue as above, even if I am watching the latest popular movie moving
> between a multicast and unicast stream everytime I pause it to get another
> beer isn't realistic. ?The chances that there will be a multicast stream
> that will be in synch with me is not high at all.

You must have skipped over the word "cache" when reading my post.
I'll explain again in a little more detail, so you can understand why
the consumer who pauses the film to go get a snack is actually an
advantage for this system.

Let's say your typical movie is 5Mb/s and you want to start watching
it right away; you aren't willing to wait several minutes (or longer)
until the next "multicast loop" begins.  You press play and begin
receiving a 5Mb/s unicast stream, but your STB also joins an mcast
group for that movie, because it is very popular and being watched by
a huge number of users during peak time.  The mcast stream is 20Mb/s,
or 400% of real-time.  No matter what point the loop is at when you
join, you will cache the multicast data and eventually reach a point
in the movie where you no longer need the unicast stream.

Given a 2 hour movie, the worst-case is that you'll join just a minute
after the stream/loop started, in which case it will be about 30
minutes before you start viewing from multi-casted, STB-cached data,
instead of unicast streamed data.  With two subscribers watching the
movie given worst-case circumstances, there is a bandwidth
conservation of: (users - 1) * 5Mb/s * 90min, or a mean savings around
37%, for only two users.  If ten users are watching, your worst-case
bandwidth savings will be greater, 33.7Mb/s, or about 67%.

If, on the other hand, you start watching the movie, then realize it
would be more enjoyable with some popcorn, your STB is already
listening to the mcast stream and caching the movie for you.  The
longer it takes your popcorn to cook, the greater the chance that the
STB will start receiving mcast data for the beginning of the movie
before you un-pause it, which means you would not need the unicast
stream at all.

In fact, if you include the probability that some users will be able
to receive data via mcast earlier than 30 minutes into the movie,
because they didn't get unlucky and press play at the worst-case
moment, your bandwidth savings for a group of ten viewers and a 400%
real-time mcast stream will be about 80%.

The potential savings is limited by the over-speed of the mcast stream
vs real-time, and the density of mcast listener groups.  Given that
access network speeds continue to increase, yet ISPs are really not
increasing "bandwidth caps," it is reasonable to assume that an ISP
might like to allow its subscribers to receive a very fast mcast
stream for a short period of time, instead of all of those subscribers
receiving many, slow mcast streams.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From lstewart at superb.net  Wed May  4 14:40:30 2011
From: lstewart at superb.net (Landon Stewart)
Date: Wed, 4 May 2011 12:40:30 -0700
Subject: Rwhois not serving all records - it is almost working though.
In-Reply-To: <AANLkTim1ELk8P2jAcmA+gsUkuCwk0oqM-UywgJcypszt@mail.gmail.com>
References: <AANLkTinVRCQ4kcOCDE1jQDiE-V6Ays8TzTqUYUrLh15w@mail.gmail.com>
	<AANLkTim1ELk8P2jAcmA+gsUkuCwk0oqM-UywgJcypszt@mail.gmail.com>
Message-ID: <BANLkTi=jrZFtUoVi6hHVpxyXfsGiXMCgoQ@mail.gmail.com>

Hello NANOG,

I sent this information to the rwhoisd mailing list originally but I've been
informed that the mailing list is mostly dead now.  I hope this is not too
far off-topic for NANOG.  One person replied to me off-list from the rwhois
mailing list and had some help but I haven't found a solution yet.
Scrapping our entire rwhois implementation and starting from scratch would
be a shame since I don't have that many free cycles these days.  If anyone
has any info or can offer some information/help that'd be super duper
appreciated.

Someone else installed this copy of rwhoisd and then that service was moved
to a new server.  The rwhois server we maintain is rwhois.hopone.net on port
4321.  All of this used to work until the rwhois service and its directories
were moved to a new server a few months ago.  It hasn't worked quite right
since then.  I'm really not sure how it all works - I'm jumping into the
middle of this since the person who set it up isn't around any more.  I've
checked for things as simple as permissions and file formatting but I can't
find any problems.

Anyway - The data files are exported from our customer database and look
OK.  By "OK" I mean they are getting exported, I'm not sure if there's a
formatting issue or not.  The files are generated regularly on another
server that hasn't had any changes made to it so they should, in theory, be
fine.

For this example I'll use 66.36.235.19 as the IP address in question.  This
is our address.

When doing a lookup I see the following which is incomplete.  Actually I'd
like it to not display this at all personally.  I'd like the customer
information to be displayed instead but multiple records is fine (ours for
the netblock and theirs for their allocation).  See below for more
information about the data files.

# whois 66.36.235.19
[Querying whois.arin.net]
[Redirected to rwhois.hopone.net:4321]
[Querying rwhois.hopone.net]
[rwhois.hopone.net]
%rwhois V-1.5:003fff:00 rwhois.hopone.net (by Network Solutions, Inc.
V-1.5.9.5)
network:Class-Name:network
network:ID:66.36.224.0/19
network:Auth-Area:66.36.224.0/19
network:Network-Name:Superb Internet Corporation
network:IP-Network:66.36.224.0/19
network:Organization;I:Superb_Internet_Corporation
network:Tech-Contact:hostmaster at superb.net
network:Admin-Contact:hostmaster at superb.net
network:Created:20050124
network:IP-Total:8192
network:IP-Used:3578
network:IP-Available:4614
network:IP-Usage:43.68
network:Updated:20110317
network:Updated-By:rwhois at hopone.com

%referral rwhois://root.rwhois.net:4321/auth-area=.
%ok

The data files for this 66.36.231.147 are in a directory called
/usr/local/rwhoisd/net-66.36.224.0-19.  The directory looks like this:
# pwd
/usr/local/rwhoisd/net-66.36.224.0-19
# ls -la
total 40
drwxr-xr-x  3 www    wheel  4096 Mar 17 00:03 .
drwxr-xr-x 26 rwhois rwhois 4096 Mar 17 00:03 ..
drwxr-xr-x  3 www    wheel  4096 Mar 17 00:05 data
-rw-r--r--  1 www    wheel   125 Mar 17 00:03 schema
-rw-r--r--  1 www    wheel   181 Mar 17 00:03 soa

When changing into /usr/local/rwhoisd/net-66.36.224.0-19/data/network I see
the data file that contains the information that should be served which is:
# cat 1230-bakertrg.txt
ID: 1230.66.36.224.0/19
Auth-Area: 66.36.224.0/19
Network-Name: bakertrg
Network-Block: 66.36.235.19-66.36.235.19
Organization: Baker_TRG__Inc.
IP-Used: 1
Created: 20050124
Updated: 20110317
Updated-By: rwhois at hopone.net

The local.db file at
/usr/local/rwhoisd/net-66.36.224.0-19/data/network/local.db contains the
following for this which I assume is correct
type:DATA
file:net-66.36.224.0-19/data/network/1230-bakertrg.txt
file_no:0
size:220
num_recs:1
lock:OFF

Does anyone on this list have any idea why this data is not being served as
expected through rwhois anymore?  Some ideas on what to check would be
helpful.  I'd like to avoid resetting this up from scratch if there's an
easy fix somewhere since it seems like its *almost* working.

Thanks for taking the time to read this.  I appreciate any help anyone can
suggest on or off list.

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From smb at cs.columbia.edu  Wed May  4 14:46:25 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Wed, 4 May 2011 15:46:25 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTi==PYvidmnmiyFEp6C3sikLVQd1KA@mail.gmail.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<4DC1995C.20202@ispalliance.net>
	<BANLkTi==PYvidmnmiyFEp6C3sikLVQd1KA@mail.gmail.com>
Message-ID: <FA3B33E0-7735-459A-A645-2518A6B9843A@cs.columbia.edu>


On May 4, 2011, at 3:37 48PM, Jeff Wheeler wrote:

> On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms at ispalliance.net> wrote:
>> Local caching is MUCH more efficient than having the same traffic running in
>> streams and depending on everyone's PC to try and update in the same time
> 
> This only works, of course, if there is a local cache which PCs are aware of.
> 
>> Same issue as above, even if I am watching the latest popular movie moving
>> between a multicast and unicast stream everytime I pause it to get another
>> beer isn't realistic.  The chances that there will be a multicast stream
>> that will be in synch with me is not high at all.
> 
> You must have skipped over the word "cache" when reading my post.
> I'll explain again in a little more detail, so you can understand why
> the consumer who pauses the film to go get a snack is actually an
> advantage for this system.
> 
> Let's say your typical movie is 5Mb/s and you want to start watching
> it right away; you aren't willing to wait several minutes (or longer)
> until the next "multicast loop" begins.  You press play and begin
> receiving a 5Mb/s unicast stream, but your STB also joins an mcast
> group for that movie, because it is very popular and being watched by
> a huge number of users during peak time.  The mcast stream is 20Mb/s,
> or 400% of real-time.  No matter what point the loop is at when you
> join, you will cache the multicast data and eventually reach a point
> in the movie where you no longer need the unicast stream.
> 
> Given a 2 hour movie, the worst-case is that you'll join just a minute
> after the stream/loop started, in which case it will be about 30
> minutes before you start viewing from multi-casted, STB-cached data,
> instead of unicast streamed data.  With two subscribers watching the
> movie given worst-case circumstances, there is a bandwidth
> conservation of: (users - 1) * 5Mb/s * 90min, or a mean savings around
> 37%, for only two users.  If ten users are watching, your worst-case
> bandwidth savings will be greater, 33.7Mb/s, or about 67%.
> 
> If, on the other hand, you start watching the movie, then realize it
> would be more enjoyable with some popcorn, your STB is already
> listening to the mcast stream and caching the movie for you.  The
> longer it takes your popcorn to cook, the greater the chance that the
> STB will start receiving mcast data for the beginning of the movie
> before you un-pause it, which means you would not need the unicast
> stream at all.
> 
> In fact, if you include the probability that some users will be able
> to receive data via mcast earlier than 30 minutes into the movie,
> because they didn't get unlucky and press play at the worst-case
> moment, your bandwidth savings for a group of ten viewers and a 400%
> real-time mcast stream will be about 80%.
> 
> The potential savings is limited by the over-speed of the mcast stream
> vs real-time, and the density of mcast listener groups.  Given that
> access network speeds continue to increase, yet ISPs are really not
> increasing "bandwidth caps," it is reasonable to assume that an ISP
> might like to allow its subscribers to receive a very fast mcast
> stream for a short period of time, instead of all of those subscribers
> receiving many, slow mcast streams.
> 
A crucial point here is the cost ratio between bandwidth and disk space,
since ultimately consumers pay for both.  My own STB can cache the
movie -- but that requires local disk.  On the other hand, as you point
out, it saves on bandwidth.  (Note that I'm interpreting "cost" broadly
to include not just the capital cost of, say, the disk, but all of the
associated operational costs, including what ISPs need to spend on
provisioning and operating multicast, consumer reactions to local disks
being full or dying, etc.

Of course, I don't know what the answer is now, let alone over time...


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From raj.singh at demandmedia.com  Wed May  4 15:10:57 2011
From: raj.singh at demandmedia.com (Raj Singh)
Date: Wed, 4 May 2011 13:10:57 -0700
Subject: Tech writer in Seattle
Message-ID: <58915E42F7F5414598BE6A3C1AF18BFD10794C134D@BLV91WEXVS01.corp.dm.local>

Do anyone know of any good technical writer in Seattle/Bellevue area that we can contract for a month?


Thanks

Raj

________________________________
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.


From joey.liuyq at gmail.com  Wed May  4 15:11:18 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Wed, 4 May 2011 15:11:18 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <20110503042053.GA3478@vacation.karoshi.com.>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
Message-ID: <BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>

Thanks for clarifying this, actually I have a few more blocks with four
origin ASNs that I'm not positive if they are anycast prefixes. Please help
distinguish them if the provide anycast service.

27.130.0.0/16

58.147.0.0/20
58.147.0.0/17
58.147.16.0/20
58.147.64.0/20
58.147.80.0/20
58.147.96.0/20
58.147.112.0/20

61.237.224.0/20
65.61.188.0/24
69.20.95.0/24

110.164.0.0/16
110.164.48.0/20
110.164.64.0/20
110.164.80.0/20
110.164.176.0/20

112.142.0.0/16
112.143.0.0/16

180.183.0.0/16

198.32.64.0/24
198.32.136.0/24
198.32.175.0/24

202.69.136.0/21
202.99.58.0/24
202.122.116.0/24

203.119.30.0/24
204.79.195.0/24
204.79.197.0/24
206.51.38.0/24
206.223.116.0/24
207.231.241.0/24
208.67.239.0/24

222.35.0.0/18
222.35.248.0/21
222.123.0.0/16
223.204.0.0/16
223.205.0.0/16

Yaoqing

On Mon, May 2, 2011 at 11:20 PM, <bmanning at vacation.karoshi.com> wrote:

> On Mon, May 02, 2011 at 08:40:01PM -0400, Christopher Morrow wrote:
> > On Mon, May 2, 2011 at 3:35 PM, Joe Abley <jabley at hopcount.ca> wrote:
> > >
> > > On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
> > >
> > >> I found the following prefixes are often originated by many ASNs more
> than
> > >> five, wonder if they provide global anycast service, if so what
> specific
> > >> service they provide?
> > >>
> > >> 12.64.255.0/24
> > >
> > > CERNET.
> > >
> > >> <http://70.37.135.0/24>70.37.135.0/24
> > >
> > > Microsoft/Hotmail.
> > >
> > >> 198.32.176.0/24
> > >
> > > Yahoo!
> >
> > as a note, this is bmanning/ep.net exchange space, no? so this could
> > be just people leaking this into their table/global-table by mistake?
>
>
>         used to be.  ep.net has fragmented into little bits.  most of the
> prefixes have
>        been transfered to the clients who were using them, the ones who are
> still around
>        are outside the ARIN region and there is no clean way to move them
> given ARIN and
>        other RIR policy.
>
> This particular prefix was used as a public exchange, operated by Switch &
> Data. Not sure
> what they have done w/ it since then.
>
> Switch and Data Management Company LLC NET-PAIX-V4 (NET-198-32-175-0-1)
> 198.32.175.0 - 198.32.177.255
> EP.NET, LLC. NET-EP-176 (NET-198-32-176-0-1) 198.32.176.0 - 198.32.176.255
>
>
> /bill
>
>


From jabley at hopcount.ca  Wed May  4 15:15:30 2011
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 4 May 2011 23:15:30 +0300
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
Message-ID: <28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>


On 2011-05-04, at 23:11, Yaoqing(Joey) Liu wrote:

> Thanks for clarifying this, actually I have a few more blocks with four origin ASNs that I'm not positive if they are anycast prefixes. Please help distinguish them if the provide anycast service.

You could probably get a good distance towards the answer to this by looking up the prefixes yourself using appropriate whois servers. Enumerating every prefix you see with more than one apparent origin and asking NANOG to type whois for you does not scale very well.


Joe


From joey.liuyq at gmail.com  Wed May  4 15:20:59 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Wed, 4 May 2011 15:20:59 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
Message-ID: <BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>

On Wed, May 4, 2011 at 3:15 PM, Joe Abley <jabley at hopcount.ca> wrote:

>
> On 2011-05-04, at 23:11, Yaoqing(Joey) Liu wrote:
>
> > Thanks for clarifying this, actually I have a few more blocks with four
> origin ASNs that I'm not positive if they are anycast prefixes. Please help
> distinguish them if the provide anycast service.
>
> You could probably get a good distance towards the answer to this by
> looking up the prefixes yourself using appropriate whois servers.
> Enumerating every prefix you see with more than one apparent origin and
> asking NANOG to type whois for you does not scale very well.
>

This is definitely a good idea, I'll do it right now. Thanks.

Yaoqing

>
>
> Joe


From tony at lavanauts.org  Wed May  4 16:12:57 2011
From: tony at lavanauts.org (Antonio Querubin)
Date: Wed, 4 May 2011 11:12:57 -1000 (HST)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com><3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org><B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>
Message-ID: <alpine.LRH.2.02.1105041111060.29599@slimemold.creativedynamo.com>

On Wed, 4 May 2011, George Bonser wrote:

> There is a security aspect to such things, though, as how do you know
> the content is from a trusted source?  That is the bugaboo with
> multicast.  It needs to be information that isn't going to hurt anything
> if it is bogus.  Also, it opens up a DoS possibility with noise traffic
> sent to the multicast group.

SSM with encryption?

-- 
Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com



From jra at baylink.com  Wed May  4 16:43:04 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 4 May 2011 17:43:04 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTi==PYvidmnmiyFEp6C3sikLVQd1KA@mail.gmail.com>
Message-ID: <13954169.601.1304545384725.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeff Wheeler" <jsw at inconcepts.biz>

> The potential savings is limited by the over-speed of the mcast stream
> vs real-time, and the density of mcast listener groups. Given that
> access network speeds continue to increase, yet ISPs are really not
> increasing "bandwidth caps," it is reasonable to assume that an ISP
> might like to allow its subscribers to receive a very fast mcast
> stream for a short period of time, instead of all of those subscribers
> receiving many, slow mcast streams.

You know what would make this work *well*?  If IAPs *didn't include mcast 
traffic in your cap*.  Since the reason for their caps is, in the final
analysis *to limit THEIR transit costs*, multicast would seem to be a 
really good means toward that end, unless my final analysis is contradicted
by something better justified and documented...

This would turn multicast into a Consumer-pull technology.

Cheers,
-- jra



From lesmith at ecsis.net  Wed May  4 16:53:19 2011
From: lesmith at ecsis.net (Larry Smith)
Date: Wed, 4 May 2011 16:53:19 -0500
Subject: Rwhois not serving all records - it is almost working though.
In-Reply-To: <BANLkTi=jrZFtUoVi6hHVpxyXfsGiXMCgoQ@mail.gmail.com>
References: <AANLkTinVRCQ4kcOCDE1jQDiE-V6Ays8TzTqUYUrLh15w@mail.gmail.com>
	<AANLkTim1ELk8P2jAcmA+gsUkuCwk0oqM-UywgJcypszt@mail.gmail.com>
	<BANLkTi=jrZFtUoVi6hHVpxyXfsGiXMCgoQ@mail.gmail.com>
Message-ID: <201105041653.19177.lesmith@ecsis.net>

Landon,

  By no means an expert in rwhoisd, but my net directory has the 
following:

atrribute_defs directory
data directory
schema file
soa file

and the DATA directory contains the following:

network directory
org directory
referral directory

From what you describe it sounds like things might not be in the
right places for rwhoisd to find them (but depends upon how heavily
your copy has been modified also)...

-- 
Larry Smith
lesmith at ecsis.net

On Wed May 4 2011 14:40, Landon Stewart wrote:
> Hello NANOG,
>
> I sent this information to the rwhoisd mailing list originally but I've
> been informed that the mailing list is mostly dead now.  I hope this is not
> too far off-topic for NANOG.  One person replied to me off-list from the
> rwhois mailing list and had some help but I haven't found a solution yet.
> Scrapping our entire rwhois implementation and starting from scratch would
> be a shame since I don't have that many free cycles these days.  If anyone
> has any info or can offer some information/help that'd be super duper
> appreciated.
>
> Someone else installed this copy of rwhoisd and then that service was moved
> to a new server.  The rwhois server we maintain is rwhois.hopone.net on
> port 4321.  All of this used to work until the rwhois service and its
> directories were moved to a new server a few months ago.  It hasn't worked
> quite right since then.  I'm really not sure how it all works - I'm jumping
> into the middle of this since the person who set it up isn't around any
> more.  I've checked for things as simple as permissions and file formatting
> but I can't find any problems.
>
> Anyway - The data files are exported from our customer database and look
> OK.  By "OK" I mean they are getting exported, I'm not sure if there's a
> formatting issue or not.  The files are generated regularly on another
> server that hasn't had any changes made to it so they should, in theory, be
> fine.
>
> For this example I'll use 66.36.235.19 as the IP address in question.  This
> is our address.
>
> When doing a lookup I see the following which is incomplete.  Actually I'd
> like it to not display this at all personally.  I'd like the customer
> information to be displayed instead but multiple records is fine (ours for
> the netblock and theirs for their allocation).  See below for more
> information about the data files.
>
> # whois 66.36.235.19
> [Querying whois.arin.net]
> [Redirected to rwhois.hopone.net:4321]
> [Querying rwhois.hopone.net]
> [rwhois.hopone.net]
> %rwhois V-1.5:003fff:00 rwhois.hopone.net (by Network Solutions, Inc.
> V-1.5.9.5)
> network:Class-Name:network
> network:ID:66.36.224.0/19
> network:Auth-Area:66.36.224.0/19
> network:Network-Name:Superb Internet Corporation
> network:IP-Network:66.36.224.0/19
> network:Organization;I:Superb_Internet_Corporation
> network:Tech-Contact:hostmaster at superb.net
> network:Admin-Contact:hostmaster at superb.net
> network:Created:20050124
> network:IP-Total:8192
> network:IP-Used:3578
> network:IP-Available:4614
> network:IP-Usage:43.68
> network:Updated:20110317
> network:Updated-By:rwhois at hopone.com
>
> %referral rwhois://root.rwhois.net:4321/auth-area=.
> %ok
>
> The data files for this 66.36.231.147 are in a directory called
> /usr/local/rwhoisd/net-66.36.224.0-19.  The directory looks like this:
> # pwd
> /usr/local/rwhoisd/net-66.36.224.0-19
> # ls -la
> total 40
> drwxr-xr-x  3 www    wheel  4096 Mar 17 00:03 .
> drwxr-xr-x 26 rwhois rwhois 4096 Mar 17 00:03 ..
> drwxr-xr-x  3 www    wheel  4096 Mar 17 00:05 data
> -rw-r--r--  1 www    wheel   125 Mar 17 00:03 schema
> -rw-r--r--  1 www    wheel   181 Mar 17 00:03 soa
>
> When changing into /usr/local/rwhoisd/net-66.36.224.0-19/data/network I see
> the data file that contains the information that should be served which is:
> # cat 1230-bakertrg.txt
> ID: 1230.66.36.224.0/19
> Auth-Area: 66.36.224.0/19
> Network-Name: bakertrg
> Network-Block: 66.36.235.19-66.36.235.19
> Organization: Baker_TRG__Inc.
> IP-Used: 1
> Created: 20050124
> Updated: 20110317
> Updated-By: rwhois at hopone.net
>
> The local.db file at
> /usr/local/rwhoisd/net-66.36.224.0-19/data/network/local.db contains the
> following for this which I assume is correct
> type:DATA
> file:net-66.36.224.0-19/data/network/1230-bakertrg.txt
> file_no:0
> size:220
> num_recs:1
> lock:OFF
>
> Does anyone on this list have any idea why this data is not being served as
> expected through rwhois anymore?  Some ideas on what to check would be
> helpful.  I'd like to avoid resetting this up from scratch if there's an
> easy fix somewhere since it seems like its *almost* working.
>
> Thanks for taking the time to read this.  I appreciate any help anyone can
> suggest on or off list.



From DStaal at usa.net  Wed May  4 17:04:05 2011
From: DStaal at usa.net (Daniel Staal)
Date: Wed, 04 May 2011 18:04:05 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <13954169.601.1304545384725.JavaMail.root@benjamin.baylink.com>
References: <13954169.601.1304545384725.JavaMail.root@benjamin.baylink.com>
Message-ID: <911B68EEC3D257279F760DCA@mac-pro.magehandbook.com>

--As of May 4, 2011 5:43:04 PM -0400, Jay Ashworth is alleged to have said:

> You know what would make this work *well*?  If IAPs *didn't include mcast
> traffic in your cap*.  Since the reason for their caps is, in the final
> analysis *to limit THEIR transit costs*, multicast would seem to be a
> really good means toward that end, unless my final analysis is
> contradicted by something better justified and documented...
>
> This would turn multicast into a Consumer-pull technology.

--As for the rest, it is mine.

Assuming that is the actual reason for traffic caps, instead of just the 
stated reason.  In many cases it seems like traffic caps are being rolled 
out in an effort to stymie the streaming-content services (Hulu, Youtube, 
etc.) that compete with the ISP's other business of selling TV/Cable 
service.

If that is the case, multicast is just a way for the services the ISPs are 
trying to interfere with to lower their costs and increase their quality. 
So not including that traffic in their cap is the last thing they would 
want to do.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------



From young at jsyoung.net  Wed May  4 17:15:15 2011
From: young at jsyoung.net (Jeff Young)
Date: Thu, 5 May 2011 08:15:15 +1000
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <4DC18474.2080902@ispalliance.net>
References: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<4DC18474.2080902@ispalliance.net>
Message-ID: <AF1A5103-1060-4BBE-B180-F3079A57714B@jsyoung.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 05/05/2011, at 2:53 AM, Scott Helms wrote:

> On 5/4/2011 12:26 PM, Tim Franklin wrote:
>>> I think that George's POV -- which is also mine -- is that as the
>>> world shifts, the percentage of video distribution which is
>>> amenable to multicast, and not well served by unicast, is likely
>>> to grow, and it would be a Good Idea to be ready for that
>>> situation already when it arrives.
>> Really?  If anything, I'd say quite the opposite.  Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot.  (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning).  I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
>> 
>> I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
>> 
>> Regards,
>> Tim.
>> 
>> 
> 
> I agree, I think less and less content will be multicast with live events (like sports) being the notable exception.  Having said that I think that multicast will increase in importance as more live events move into the remotely viewable venue.  There is a huge market for concerts, live pays, comedy, and other content that just isn't available right now.  The viewing market will continue to fragment requiring more sources of content than are available today.  In short the percentage of video sent as multicast will decrease (IMO) over time but the overall volume will increase as total video content as IP greatly expands.
> 
> 
> -- 

Many years ago I was the MCI side of the Real Broadcast Network.  Real Networks arranged to broadcast a 
Rolling Stones concert.  We had the ability to multicast on the Mbone and unicast from Real Networks caches.
We figured that we'd get a hit rate of 70% multicast (those who wanted to see the event as it happened) and
30% unicast (those who would wait and watch it later).  

The data we got back was the exact opposite of what we'd expected (30% multicast, 70% unicast) with an 
average skew being around 30 minutes (on average unicasters started viewing less than 30 minutes after
the event began).  

Events like these formed my opinion that while multicast wouldn't be a ubiquitous transport, it would be a very 
important (our Real Networks caches picked the event up off the Mbone) tool for providers to use.  

The most ambitious use of multicast I'm aware of is AT&T's UVerse network which multicasts (SS) from two
head-ends all the way to the set top box in a home.  But this is confined to the AT&T network and UVerse is
arguably a "me-too" offering to compete with Time Warner Cable and others.

jy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iF4EAREIAAYFAk3Bz/gACgkQxvthcni5E28/zgD/Rn/+ow/ibdZ3k2MyDiWv0TJt
Mnj4wcbLpCjSaweCsywBAIIHGy9XLRjCI/R1A82qiocx4uSuqXmWU9CQ/kyWn85c
=9nb5
-----END PGP SIGNATURE-----



From bill at herrin.us  Wed May  4 17:20:09 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 4 May 2011 18:20:09 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com>
	<4DBB0D68.40108@bogus.com>
	<BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com>
Message-ID: <BANLkTi=yzh5qUdYRYP0dGnTO6dz9D3z-Ug@mail.gmail.com>

On Fri, Apr 29, 2011 at 4:40 PM, Tim Durack <tdurack at gmail.com> wrote:
> Multicast is a great technical solution in search of a good business problem.

It's a useful replacement for broadcast on a local link. It's of
limited utility elsewhere.



On Fri, Apr 29, 2011 at 5:21 PM, George Bonser <gbonser at seven.com> wrote:
> Multicast is perfect for a live event.  Unicast is best for "on demand"
> viewing of something.

A layered cache implemented via unicast would work better and enable
local fills for lost packets too. More, it sits to the side of the
routers rather than in line, so it allows your routers to focus on
what they do well: routing unicast packets.

Some time ago I sketched out a notion for a layered opportunistic
caching system that finds its nearest caches via anycast and validates
the cached data via a very small signature stream from the original
source. Even if your viewing is off-sync with others using the caches
in your hierarchy the probability of bandwidth savings increases
rapidly with the popularity of the content.

The idea is that you deploy these caches as deep in your system as is
cost effective. Regionally. The local CO. In the box with the
neighborhood fiber terminal if you find the traffic savings beats the
equipment cost.

And of course such a cache system could work well for popular
non-streamed content as well.

Never quite linked up with someone interested in seeing an
implementation though...

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From jra at baylink.com  Wed May  4 17:20:38 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 4 May 2011 18:20:38 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <911B68EEC3D257279F760DCA@mac-pro.magehandbook.com>
Message-ID: <31551047.607.1304547638733.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Daniel Staal" <DStaal at usa.net>

> --As of May 4, 2011 5:43:04 PM -0400, Jay Ashworth is alleged to have
> said:
> > You know what would make this work *well*? If IAPs *didn't include mcast
> > traffic in your cap*. Since the reason for their caps is, in the final
> > analysis *to limit THEIR transit costs*, multicast would seem to be a
> > really good means toward that end, unless my final analysis is
> >  contradicted by something better justified and documented...
> >
> > This would turn multicast into a Consumer-pull technology.
> 
> Assuming that is the actual reason for traffic caps, instead of just the
> stated reason. In many cases it seems like traffic caps are being rolled
> out in an effort to stymie the streaming-content services (Hulu, Youtube,
> etc.) that compete with the ISP's other business of selling TV/Cable
> service.
> 
> If that is the case, multicast is just a way for the services the ISPs are
> trying to interfere with to lower their costs and increase their quality.
> So not including that traffic in their cap is the last thing they would
> want to do.

Sure.  What better way to expose them for that?  :-)

No business is entitled to protection of its business model.

Cheers,
-- jra



From Valdis.Kletnieks at vt.edu  Wed May  4 17:42:52 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 04 May 2011 18:42:52 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: Your message of "Wed, 04 May 2011 18:20:09 EDT."
	<BANLkTi=yzh5qUdYRYP0dGnTO6dz9D3z-Ug@mail.gmail.com>
References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com>
	<4DBB0D68.40108@bogus.com>
	<BANLkTinKPOg0FgHNuShzn-MB2aWL5WcgzA@mail.gmail.com>
	<BANLkTi=yzh5qUdYRYP0dGnTO6dz9D3z-Ug@mail.gmail.com>
Message-ID: <26568.1304548972@localhost>

On Wed, 04 May 2011 18:20:09 EDT, William Herrin said:

> And of course such a cache system could work well for popular
> non-streamed content as well.
> 
> Never quite linked up with someone interested in seeing an
> implementation though...

I suspect to generate interest, it would have to be demonstrably
better than just plopping a BitTorrent cache in your network.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110504/f3c5176d/attachment.bin>

From tdurack at gmail.com  Wed May  4 18:19:29 2011
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 4 May 2011 19:19:29 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <31551047.607.1304547638733.JavaMail.root@benjamin.baylink.com>
References: <911B68EEC3D257279F760DCA@mac-pro.magehandbook.com>
	<31551047.607.1304547638733.JavaMail.root@benjamin.baylink.com>
Message-ID: <BANLkTimC7ckx-7NLJ7SgMviPfVDufs87jg@mail.gmail.com>

On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra at baylink.com> wrote:

> No business is entitled to protection of its business model.

Unless it has a market monopoly, deep pockets, and lobbyist friends.

-- 
Tim:>



From jra at baylink.com  Wed May  4 18:21:46 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 4 May 2011 19:21:46 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTimC7ckx-7NLJ7SgMviPfVDufs87jg@mail.gmail.com>
Message-ID: <28444194.613.1304551306362.JavaMail.root@benjamin.baylink.com>

----- Original Message -----

> On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra at baylink.com> wrote:
> > No business is entitled to protection of its business model.
> 
> Unless it has a market monopoly, deep pockets, and lobbyist friends.

That does not mean they're *entitled* to it... just that they can *get*
it.

Cheers,
-- jra



From jeremyparr at gmail.com  Wed May  4 18:48:43 2011
From: jeremyparr at gmail.com (Jeremy Parr)
Date: Wed, 4 May 2011 19:48:43 -0400
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <BANLkTi=o3h7f_AKD=Q-tt1TN8cRdjE2xJA@mail.gmail.com>

On 4 May 2011 04:43, Robert Lusby <nanogwp at gmail.com> wrote:

> Sorry to start the day OT, but I'm sure you lovely lot will have some
> tips/experience! ;)
>
> We have a HP Server Cabinet (42U 10842 G2), that we've stripped down to the
> bare-bones chassis. It now measures 750mm wide.
>
> We have a door-way that said server cabinet must fit through, measuring up
> at 620mm.
>
> The cabinet chassis is welded at all four corners, so can't be taken apart
> any more without being cut.
>
> Can you see where this is leading yet? Three obvious questions:
>
> 1) Have you ever had to fit a cabinet through a doorway that's too small?
> 2) How did you do it? Cut cabinet, demolish wall ...?
> 3) If you cut the cabinet, any tips?
>
> Thanks.
> Rob
>

I've seen some suggestions for Middle Atlantic racks, avoid these, as they
are junk (and rather expensive). APC builds some cabinets that will knock
down, as does Commscope. I bet Chatsworth has something as well.


From joey.liuyq at gmail.com  Wed May  4 22:23:12 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Wed, 4 May 2011 22:23:12 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
Message-ID: <BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>

Hi NANOG,

I manually extracted the origins and their org info for the announced
block of prefixes. All these prefixes were observed being originated
by at most four ASNs simultaneously. I suspect they provide anycast or
IXP service, but not positive. Please confirm my conjecture if you
know them. Thanks!

27.130.0.0/16
58.147.0.0/20
58.147.0.0/17
58.147.16.0/20
58.147.64.0/20
58.147.80.0/20
58.147.96.0/20
58.147.112.0/20
110.164.0.0/16
110.164.48.0/20
110.164.64.0/20
110.164.80.0/20
110.164.176.0/20
112.143.0.0/16
180.183.0.0/16
202.69.136.0/21
223.204.0.0/16
223.205.0.0/16
AS24326: as-name:TTT-AS-AP|descr:Maxnet, Internet Service Provider,
Bangkok|country:TH
AS38550: as-name:TTGN-INTER-AS-AP|descr:TTGN , INTERNATIONAL INTERNET
GATEWAY, THAILAND|country:TH
AS45629: as-name:JASTEL-NETWORK-TH-AP|descr:Jasmine International
Tower|country:TH
AS45758: as-name:TRIPLETNET-AS-AP|descr:TripleT Internet Internet
service provider Bangkok|country:TH

61.237.224.0/20
AS4808:as-name:CHINA169-BJ|descr:CNCGROUP IP network China169 Beijing
Province Network|country:CN
AS4847:as-name:CNIX-AP|descr:China Networks Inter-Exchange
AS9819:as-name:BZNET|descr:Beijing Bozhiruihai Network Technology Co.,
Ltd.|country:CN
AS17772:as-name:CHINACOM|descr:CHINA COMMUNICATIONS SYSTEM Co.,Ltd.|country:CN
AS17964: as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network
Technologies Co., Ltd.|country:CN
AS24138:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong
Telecommunication Corporation|CN
AS38356:as-name:NETEON|descr:Beijing Neteon Tech Co, Ltd.|country:CN
AS45114:as-name:CNNIC-SUNINFO-MDC-AP|descr:Beijing Sunrise Technology
Co. Ltd.|country:CN

65.61.188.0/24
69.20.95.0/24
AS10532:ASName: RACKSPACE;OrgName:Rackspace Hosting
AS15395:as-name:UNSPECIFIED|descr:UK Rackspace|descr:LONDON office
AS27357:ASName: RACKSPACE;OrgName:Rackspace Hosting
AS33070:ASName: RMH-14;OrgName:Rackspace Hosting

112.142.0.0/16
222.123.0.0/16
AS24326: as-name:TTT-AS-AP|descr:Maxnet, Internet Service Provider,
Bangkok|country:TH
AS38550: as-name:TTGN-INTER-AS-AP|descr:TTGN , INTERNATIONAL INTERNET
GATEWAY, THAILAND|country:TH
AS45629: as-name:JASTEL-NETWORK-TH-AP|descr:Jasmine International
Tower|country:TH
AS45758: as-name:TRIPLETNET-AS-AP|descr:TripleT Internet Internet
service provider Bangkok|country:TH
AS45626:as-name:TOPL-AU-AS|descr:Travelex Outsourcing Pty Ltd 5/504
Pacific Highway St Leonards NSW AUS 2065|country:AU


198.32.64.0/24
AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
AS42909: as-name:         COMMUNITYDNS;descr:           Internet
Computer Bureau Ltd

198.32.136.0/24
AS195:OrgName:San Diego Supercomputer Center
AS293:OrgName:ESnet|OrgId:ENSN-Z
AS1239:OrgName:Sprint
AS2914:OrgName:NTT America, Inc.
AS7018:OrgName:AT&T Services, Inc.

198.32.175.0/24
AS2497:as-name:IIJ|descr:Internet Initiative Japan Inc.
AS2914:OrgName:NTT America, Inc.|
AS4323:OrgName:tw telecom holdings, inc.
AS5650:OrgName:Frontier Communications of America, Inc.
AS6461:OrgName:Abovenet Communications, Inc

202.99.58.0/24
AS4808:as-name:CHINA169-BJ|descr:CNCGROUP IP network China169 Beijing
Province Network|country:CN
AS6619:as-name:SAMSUNGNETWORKS-AS-KR|descr:Samsung Networks Inc.
AS17431:as-name:TONET|descr:Beijing TONEK Information Technology
Development Company|country:CN
AS17964:as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network
Technologies Co., Ltd.|country:CN

202.122.116.0/24
AS17775:as-name:STN-CN|descr:SHANGHAI Guangdian Electronics Group
Co.,Ltd|country:CN
AS18118:as-name:CITICNET-AP|descr:CITIC Networks Management Co.,Ltd.
AS24142:as-name:CNNIC-BennalongNet-AP|descr:Shanghai Bennalong Network
Technology Co.,LTD
AS38356:as-name:NETEON|descr:Beijing Neteon Tech Co,
Ltd.|descr:Room203-204, No.1,737,CaoXi Road
North,Shanghai,China|country:CN
AS38814:as-name:ASIAMAX-HK-EA-AP|descr:Asiamax Technology Limited VPN
Service Provider Hong Kong|country:HK

203.119.30.0/24
AS24151:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center
AS24406:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center
AS24408:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center
AS24410:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center


204.79.195.0/24
AS8068:OrgName:Microsoft Corp
AS8069:OrgName:GRYPHON NETWORKS
AS8071:OrgName:Microsoft Corp
AS8075:OrgName:Microsoft Corp

204.79.197.0/24
AS8068:OrgName:Microsoft Corp
AS8069:OrgName:GRYPHON NETWORKS
AS8071:OrgName:Microsoft Corp
AS8075:OrgName:Microsoft Corp
AS12076:OrgName:Hotmail Corporation

206.51.38.0/24
AS3549:OrgName:Hotmail Corporation
AS6453:OrgName:Tata Communications
AS7911:OrgName:Level 3 Communications, Inc.
AS25973:OrgName:Mzima Networks, Inc.

206.223.116.0/24
AS293:OrgName:ESnet
AS1280:OrgName:Internet Systems Consortium, Inc.
AS2914:OrgName:NTT America, Inc.
AS6461:OrgName:Abovenet Communications, Inc
AS23352:OrgName:Server Central Network

207.231.241.0/24
AS101:OrgName:University of Washington
AS226:OrgName:Los Nettos
AS293:OrgName:ESnet
AS14221:OrgName:University of Washington

208.67.239.0/24
AS11588:OrgName:Highwinds Network Group, Inc.
AS23148:OrgName:TERRENAP DATA CENTERS, INC.
AS29045:IT ACTION - Managed Hosting
AS40009:OrgName:BitGravity, Inc.

222.35.0.0/18
AS4808:as-name:CHINA169-BJ|descr:CNCGROUP IP network China169 Beijing
Province Network|country:CN
AS4847:as-name:CNIX-AP|descr:China Networks Inter-Exchange|descr:Using
International Link at Beijing
AS9819:as-name:BZNET|descr:Beijing Bozhiruihai Network Technology Co.,
Ltd.|country:CN
AS17964:as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network
Technologies Co., Ltd.|country:CN
AS24138:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong
Telecommunication Corporation|descr:Beijing branch IDC
network|country:CN
AS38356:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong
Telecommunication Corporation|descr:Beijing branch IDC
network|country:CN
AS45114:as-name:CNNIC-SUNINFO-MDC-AP|descr:Beijing Sunrise Technology Co. Ltd.

222.35.248.0/21
AS4847:as-name:CNIX-AP|descr:China Networks Inter-Exchange|descr:Using
International Link at Beijing
AS9802:as-name:CHINA-ABITCOOL|descr:Abitcool(China) Inc.|country:CN
AS9803:as-name:JINGXUN|descr:Beijing Jingxun Public Information
Technology Co., Ltd|country:CN
AS17964:as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network
Technologies Co., Ltd.|country:CN
AS18118:as-name:CITICNET-AP|descr:CITIC Networks Management Co.,Ltd.
AS24138:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong
Telecommunication Corporation|descr:Beijing branch IDC
network|country:CN
AS38356:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong
Telecommunication Corporation|descr:Beijing branch IDC
network|country:CN:


Yaoqing



On Wed, May 4, 2011 at 3:20 PM, Yaoqing(Joey) Liu <joey.liuyq at gmail.com> wrote:
>
>
> On Wed, May 4, 2011 at 3:15 PM, Joe Abley <jabley at hopcount.ca> wrote:
>>
>> On 2011-05-04, at 23:11, Yaoqing(Joey) Liu wrote:
>>
>> > Thanks for clarifying this, actually I have a few more blocks with four origin ASNs that I'm not positive if they are anycast prefixes. Please help distinguish them if the provide anycast service.
>>
>> You could probably get a good distance towards the answer to this by looking up the prefixes yourself using appropriate whois servers. Enumerating every prefix you see with more than one apparent origin and asking NANOG to type whois for you does not scale very well.
>
> This is definitely a good idea, I'll do it right now. Thanks.
>
> Yaoqing
>>
>>
>> Joe



From gbonser at seven.com  Thu May  5 00:55:54 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 4 May 2011 22:55:54 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <alpine.LRH.2.02.1105041111060.29599@slimemold.creativedynamo.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com><3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org><B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>
	<alpine.LRH.2.02.1105041111060.29599@slimemold.creativedynamo.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>

> > There is a security aspect to such things, though, as how do you
know
> > the content is from a trusted source?  That is the bugaboo with
> > multicast.  It needs to be information that isn't going to hurt
> anything
> > if it is bogus.  Also, it opens up a DoS possibility with noise
> traffic
> > sent to the multicast group.
> 
> SSM with encryption?

Well, certainly, but source address can be very easily spoofed with a
UDP multicast stream.  Now that could be mitigated with a lot of network
configuration rules but something is needed that just works without all
that.

So using multicast for things like software updates to computers over
the general internet to the general public probably isn't going to work.
Encryption is also an issue because it doesn't really work well over
multicast. How do I encrypt something in a way that anyone can decrypt
but nobody can duplicate?  If I have a separate stream per user, that is
easy.  If I have one stream for all users, that is harder.  The answer
is probably in some sort of digital signature but not really encryption.

Using public/private key encryption over multicast, I would have to
distribute the private key so others could decrypt the content.  If they
have the private key, they can generate a public key to use to generate
content.

Encryption is probably overkill anyway.  What is needed is a mechanism
simply to say that the content is certified to have come from the source
it claims to come from.  So ... basically ... better not to use
multicast for anything you really might have any security issues with.
Fine for broadcasting a video, not so fine for a kernel update.





From jsw at inconcepts.biz  Thu May  5 01:42:45 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Thu, 5 May 2011 02:42:45 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>
	<alpine.LRH.2.02.1105041111060.29599@slimemold.creativedynamo.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
Message-ID: <BANLkTim=XPndbP5HBefg1VCSyn=WqyqaeA@mail.gmail.com>

On Thu, May 5, 2011 at 1:55 AM, George Bonser <gbonser at seven.com> wrote:
> multicast. How do I encrypt something in a way that anyone can decrypt
> but nobody can duplicate? ?If I have a separate stream per user, that is

Have you ever seen a CableCARD?  That's pretty much what it does,
except not "anyone" can decrypt it -- you need to subscribe to some TV
channels.  There has been quite a bit of work in "black-boxing" the
decryption of broadcast/multicast streams to make it difficult for
end-users to pirate the content.  That's why you see HDCP logos in the
marketing fluff for displays and graphics cards, etc.

> Encryption is probably overkill anyway. ?What is needed is a mechanism
> simply to say that the content is certified to have come from the source
> it claims to come from. ?So ... basically ... better not to use
> multicast for anything you really might have any security issues with.
> Fine for broadcasting a video, not so fine for a kernel update.

This is a solved problem.  Not only are you able to verify the
computed checksum of a downloaded file against the distributor's
published checksum, there are plenty of applications that do this for
you -- torrent programs check each chunk and throw away
malicious/erroneous ones.

There are certainly things that need work before I can start up Jeff's
Internet Movie Channel and go into competition with HBO, but for the
most part, these are solvable if networks decided to do it.  The big
limitation is there can't be infinite groups -- FIB is only so big and
there is no agreeable mechanism for sharing the number that can be
made to exist, given current (and foreseeable) routers.  Since so many
"eyeballs" are sitting on ISPs that also own television networks and
other media properties, though, I don't think we will get multicast
anytime soon.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From woody at pch.net  Thu May  5 02:35:23 2011
From: woody at pch.net (Bill Woodcock)
Date: Thu, 5 May 2011 00:35:23 -0700
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
Message-ID: <2C504293-8647-46B3-B316-537D110BE5FC@pch.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On May 4, 2011, at 8:23 PM, Yaoqing(Joey) Liu wrote:

> Hi NANOG,
> 
> I manually extracted the origins and their org info for the announced
> block of prefixes. All these prefixes were observed being originated
> by at most four ASNs simultaneously. I suspect they provide anycast or
> IXP service, but not positive. Please confirm my conjecture if you
> know them. 

The IXP subnets are here:

http://www.pch.net/ixpdir/ip_city_country.pl

                                -Bill




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQIcBAEBCAAGBQJNwlM7AAoJEG+kcEsoi3+HXD8P/0Ufpu3KDRZsAzbV6PVcUjIU
HtGl2aTTkPntLcaEZgItRA1m9GBbiIdDBRsQrR2IDU9K9py5MEhnllmC+JojJpJ9
xtrxEnisLNiZfCHhy0AHHhHZfbvu9UWpXbHVTuezL1HyRTCscmdyQWJtGYug59p6
beI9kVlP7laOY6pyrb2rXCDPs0zaVqof4XwWlD5HQMQJcdw5GyyON9ddz7WXROk5
Q4be9G7w79L164r4nkDDTreZ7yWGqUFSGwXYTRpkItbBgHQtW3fnWKIrVbRl5a3X
t/3og2OmysYY5g05IjP7Afg0+IPopyS9Kwa1SvgVe+Qu0SX8nZAjhOcSKtMgmPwP
CdzyK6Mv20+CkwcmAejG44dZ4NWY/Zog8iJ4fDDmgX8CxqGduoG0cLmvXPg9iqz9
qpxuD6EpqYOXKVFYRy3BOao72PJJgURpd2JGYHw2OiWkOTBP/KkJkOWb4pawDR2B
q06Zt/XyHqQhFwu4oUq63wOFcsUHn3poEjEtG2kPyYH4R4gUsZJvdXGOXpw3kq52
z3437Nf0fMnGeu+SKpINQ14GXKWzpxTtwRxDrDBlxyweLsA8ZTgzDxgCljkmO4wc
XF67uAGlHdu3eXCFHslW8tTrizjWl4fe95qej5oDuNi4okmkU6E6po6ohfphvxPP
Uu2gSRvFtzCmZGUypu9P
=BV20
-----END PGP SIGNATURE-----




From woody at pch.net  Thu May  5 02:51:39 2011
From: woody at pch.net (Bill Woodcock)
Date: Thu, 5 May 2011 00:51:39 -0700
Subject: Suspecious anycast prefixes
In-Reply-To: <2C504293-8647-46B3-B316-537D110BE5FC@pch.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<2C504293-8647-46B3-B316-537D110BE5FC@pch.net>
Message-ID: <D5DF6876-B76C-4CBA-9681-29A141119F74@pch.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On May 5, 2011, at 12:35 AM, Bill Woodcock wrote:
>> I suspect they provide ? IXP service, but not positive. 
> 
> The IXP subnets are here:
> http://www.pch.net/ixpdir/ip_city_country.pl

It has been pointed out to me that not _all_ IXP subnets are there, which is quite true.  That list is the subset of the full list of IXPs ( http://pch.net/ixpdir ) for which we have the IPv4/IPv6 subnet information.  If anyone spots an IXP that's missing from that list, it's because we don't have the IP subnets.  We would love to be as complete as possible, so if anyone has any corrections or additions, we'd be very grateful to hear them.

Thanks,

                                -Bill




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQIcBAEBCAAGBQJNwlcLAAoJEG+kcEsoi3+H4P8P/Rp6y2Vtch2nEmfT1NwVgDlQ
GaBG323c2P1yFSPxnbznunAi2em9nBMI9ub+ubBAAKVlTVTg4boFT5XeCHVbhN79
Y7IUZx9CUMNpPz1REMD3b5Vmox79zEwi8R43WGsohLkATClclujtNiE9IByjFhYH
DmVI567HbV9VamcZMnoX8u78snJ580GXIbB2crq6skcCtml5xhsNgpTzC29vBuVN
RQODgJOHa8zNVLvQWO4jvgGd2Uy7/lMfhy0qoe9TOizJ3oZOAKK5tPWnnhdo1Q30
/Jm49heT3HJ8RgT/i/Q7eFJYgLaecvRN9/F6UlYSK2OAyc/FIDg2IhGWiPHBu1v9
MgAgSa9fjY+oVzac3ZppcE9moyur1cajlUt3QVEMFXX7uaEeDKWvAuKqeH5qpw9l
D5x8aIUSlXAHfPVVNhNiifX6RNQ/WEDxQBrW9FuKp77b0MPPjXK6DWSZfW07UMq1
T5mdvdIuXg5hodSYIvMGsiJ/B5U7pVmCmfZdCP9fWDQjyWs/cp2tJAJ71Wefr2cO
QEDuJ+X9wEJBkfMuZiNZlJH25MncspBq7GtxaYNttUoZnOTD3apmwzZia4doJNJR
bCa3P5SQNwyMLqTP08DHBEZQQTd29cY6ORCtuDxqrkYCTh6QpAIxDLVlHrAYPuBG
8GZ9yGcQ4pJXak+4KRbD
=q4ag
-----END PGP SIGNATURE-----




From bmanning at vacation.karoshi.com  Thu May  5 03:46:54 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 5 May 2011 08:46:54 +0000
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
Message-ID: <20110505084654.GA5266@vacation.karoshi.com.>

On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
> Hi NANOG,
> 
> 198.32.64.0/24
> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
> AS42909: as-name:         COMMUNITYDNS;descr:           Internet
> Computer Bureau Ltd
> 

	according to Filip, this is -NOT- supposed to be
	anycast.  the only legal origin ASN is 4555.

	these other ASNs have hijacked the prefix.

/bill



From jabley at hopcount.ca  Thu May  5 03:54:17 2011
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 5 May 2011 11:54:17 +0300
Subject: Suspecious anycast prefixes
In-Reply-To: <20110505084654.GA5266@vacation.karoshi.com.>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
Message-ID: <31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>


On 2011-05-05, at 11:46, bmanning at vacation.karoshi.com wrote:

> On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
>> 198.32.64.0/24
>> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
>> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
>> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
>> AS42909: as-name:         COMMUNITYDNS;descr:           Internet
>> Computer Bureau Ltd
> 
> 	according to Filip, this is -NOT- supposed to be
> 	anycast.  the only legal origin ASN is 4555.
> 
> 	these other ASNs have hijacked the prefix.

The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.

Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.


Joe


From smb at cs.columbia.edu  Thu May  5 05:46:06 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Thu, 5 May 2011 06:46:06 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com><3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org><B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>
	<alpine.LRH.2.02.1105041111060.29599@slimemold.creativedynamo.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
Message-ID: <A33A7BDC-CD34-4819-A996-59FA1A392161@cs.columbia.edu>


On May 5, 2011, at 1:55 54AM, George Bonser wrote:

>>> There is a security aspect to such things, though, as how do you
> know
>>> the content is from a trusted source?  That is the bugaboo with
>>> multicast.  It needs to be information that isn't going to hurt
>> anything
>>> if it is bogus.  Also, it opens up a DoS possibility with noise
>> traffic
>>> sent to the multicast group.
>> 
>> SSM with encryption?
> 
> Well, certainly, but source address can be very easily spoofed with a
> UDP multicast stream.  Now that could be mitigated with a lot of network
> configuration rules but something is needed that just works without all
> that.
> 
> So using multicast for things like software updates to computers over
> the general internet to the general public probably isn't going to work.
> Encryption is also an issue because it doesn't really work well over
> multicast. How do I encrypt something in a way that anyone can decrypt
> but nobody can duplicate?  If I have a separate stream per user, that is
> easy.  If I have one stream for all users, that is harder.  The answer
> is probably in some sort of digital signature but not really encryption.
> 
> Using public/private key encryption over multicast, I would have to
> distribute the private key so others could decrypt the content.  If they
> have the private key, they can generate a public key to use to generate
> content.
> 
> Encryption is probably overkill anyway.  What is needed is a mechanism
> simply to say that the content is certified to have come from the source
> it claims to come from.  So ... basically ... better not to use
> multicast for anything you really might have any security issues with.
> Fine for broadcasting a video, not so fine for a kernel update.
> 
See the work of the IETF MIKEY working group.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From danny at tcb.net  Thu May  5 07:59:00 2011
From: danny at tcb.net (Danny McPherson)
Date: Thu, 5 May 2011 08:59:00 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
Message-ID: <3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>


On May 3, 2011, at 6:17 AM, Bill Woodcock wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On May 2, 2011, at 12:35 PM, Joe Abley wrote:
>> It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.
> 
> I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice

'A', not 'the', for the reasons conveyed in the draft (e.g., control 
plane discriminator, RPKI foundations, etc..).  If you don't like it, 
don't do it, it's certainly easier to not do it.
 
> for me to originate my address space from more than 8,000 different ASNs,

8000 is a very large number.

> when I currently do just fine advertising it from three.

"You" as a service operator do just fine, and it's surely much 
simpler from a configuration and provisioning standpoint.  But 
what about those folks that consume the service, and have no 
indication of which node they may be utilizing from an Internet 
control plane perspective, or all the associated derivatives?

>  I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common.

'clueless people' wouldn't care which node they utilize, where 
it resides, or what other attributes might exist and be associated 
with it.  Providing a discriminator in the control plane for the 
consumer of critical network services might well be of utility to 
some.  

-danny






From jtk at cymru.com  Thu May  5 08:10:31 2011
From: jtk at cymru.com (John Kristoff)
Date: Thu, 5 May 2011 08:10:31 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
Message-ID: <20110505081031.3e3bb508@t61p>

On Thu, 5 May 2011 11:54:17 +0300
Joe Abley <jabley at hopcount.ca> wrote:

> Perhaps I'm misunderstanding the original question, but the assertion
> that anybody is hijacking that particular prefix seems false.

Furthermore, that exchange prefixes may often appear to be anycast is
not unusual.  Those prefixes are often originated by multiple disparate
networks who are connected to the exchange.  In a lightning talk I did
at NANOG 41, I talked about mapping peering relationships at exchanges.
When I noted that these prefixes are often announced by exchange
participants, Louie Lee explained that some of his participants often
announce the space to their transit customers so that monitoring and
troubleshooting tools don't cause confusion (e.g. traceroutes).

John



From dmiller at tiggee.com  Thu May  5 08:43:52 2011
From: dmiller at tiggee.com (David Miller)
Date: Thu, 05 May 2011 09:43:52 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
	<3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>
Message-ID: <4DC2A998.7080000@tiggee.com>

On 5/5/2011 8:59 AM, Danny McPherson wrote:
> On May 3, 2011, at 6:17 AM, Bill Woodcock wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On May 2, 2011, at 12:35 PM, Joe Abley wrote:
>>> It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see<http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.
>> I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice
> 'A', not 'the', for the reasons conveyed in the draft (e.g., control
> plane discriminator, RPKI foundations, etc..).  If you don't like it,
> don't do it, it's certainly easier to not do it.
>
>> for me to originate my address space from more than 8,000 different ASNs,
> 8000 is a very large number.
>
>> when I currently do just fine advertising it from three.
> "You" as a service operator do just fine, and it's surely much
> simpler from a configuration and provisioning standpoint.  But
> what about those folks that consume the service, and have no
> indication of which node they may be utilizing from an Internet
> control plane perspective, or all the associated derivatives?

In a properly functioning system - folks that consume the service don't 
need to know which node they are utilizing.

Providing the capability for well behaved customers to select/prefer a 
particular node over another would also allow evildoers to select/prefer 
a particular node over others - thereby increasing the attack surface of 
this node, yes?

Not a fan.

>>   I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common.
> 'clueless people' wouldn't care which node they utilize, where
> it resides, or what other attributes might exist and be associated
> with it.  Providing a discriminator in the control plane for the
> consumer of critical network services might well be of utility to
> some.
>
> -danny
>
>
>
>




From joey.liuyq at gmail.com  Thu May  5 09:36:50 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Thu, 5 May 2011 09:36:50 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
Message-ID: <BANLkTik-7WLe56LZtYDfHB55+DhZCwG5EQ@mail.gmail.com>

On Thu, May 5, 2011 at 3:54 AM, Joe Abley <jabley at hopcount.ca> wrote:
>
> On 2011-05-05, at 11:46, bmanning at vacation.karoshi.com wrote:
>
>> On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
>>> 198.32.64.0/24
>>> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
>>> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
>>> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
>>> AS42909: as-name: ? ? ? ? COMMUNITYDNS;descr: ? ? ? ? ? Internet
>>> Computer Bureau Ltd
>>
>> ? ? ? according to Filip, this is -NOT- supposed to be
>> ? ? ? anycast. ?the only legal origin ASN is 4555.
>>
>> ? ? ? these other ASNs have hijacked the prefix.
>
> The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.

This is based on last four year's data(2007-2010)collected from more
than 120 peers around the world. Today it may be not announced
anymore, but it used to be announced by the four ASNs simultaneously.
I just checked the detailed info about this prefix, here it is about
the prefix:
198.32.64.0/24
(ASN: average peers announcing this prefix:existing period:total
appearing days: MOAS period: total appearing days)
4555:4.94:20080318-20080506:50:20080318-20080506:50
9584:3.07:20080402-20080513:42:20080402-20080513:42
20144:79.44:20070101-20080501:487:20071215-20080501:138
42909:26.39:20071215-20080515:152:20071215-20080513:150
>
MY source data
> Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
>
This needs to do further analysis to confirm if it was hijacked

Yaoqing
>
> Joe



From ljakab at ac.upc.edu  Thu May  5 10:36:03 2011
From: ljakab at ac.upc.edu (=?ISO-8859-1?Q?Lor=E1nd_Jakab?=)
Date: Thu, 05 May 2011 17:36:03 +0200
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <AF1A5103-1060-4BBE-B180-F3079A57714B@jsyoung.net>
References: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>	<4DC18474.2080902@ispalliance.net>
	<AF1A5103-1060-4BBE-B180-F3079A57714B@jsyoung.net>
Message-ID: <4DC2C3E3.80202@ac.upc.edu>

On 05/05/11 00:15, Jeff Young wrote:
> The most ambitious use of multicast I'm aware of is AT&T's UVerse
> network which multicasts (SS) from two
> head-ends all the way to the set top box in a home.  But this is
> confined to the AT&T network and UVerse is
> arguably a "me-too" offering to compete with Time Warner Cable and others.

Telefonica has a similar multicast deployment in its Spanish network,
marketed as Imagenio, so this proves that multicast can be quite useful
within a provider's own network. Too bad the economic incentives are not
so clear/inexistent for transit networks.

-Lorand Jakab

>
> jy




From danny at tcb.net  Thu May  5 10:39:32 2011
From: danny at tcb.net (Danny McPherson)
Date: Thu, 5 May 2011 11:39:32 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <4DC2A998.7080000@tiggee.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
	<3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>
	<4DC2A998.7080000@tiggee.com>
Message-ID: <0C0ECC3C-76A5-4029-AE4A-E2CF783ED62E@tcb.net>


On May 5, 2011, at 9:43 AM, David Miller wrote:

> In a properly functioning system - folks that consume the service don't need to know which node they are utilizing.

Right, it doesn't matter IF things are functioning properly.  If they're not, however...

> Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes?

This isn't expressly about the capability to allow consumers to select one node of another, it's about transparency in which nodes they're using being visible in the control plane - there's no indication of that today.

As for attack surface expanse, no.  You could largely already accomplish something of this sort today in the elements of the forwarding path you influence if you were an evildoer aiming to do such a thing.

-danny


From dmiller at tiggee.com  Thu May  5 10:58:27 2011
From: dmiller at tiggee.com (David Miller)
Date: Thu, 05 May 2011 11:58:27 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <0C0ECC3C-76A5-4029-AE4A-E2CF783ED62E@tcb.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>	<3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>	<4DC2A998.7080000@tiggee.com>
	<0C0ECC3C-76A5-4029-AE4A-E2CF783ED62E@tcb.net>
Message-ID: <4DC2C923.80200@tiggee.com>

On 5/5/2011 11:39 AM, Danny McPherson wrote:
> On May 5, 2011, at 9:43 AM, David Miller wrote:
>
>> In a properly functioning system - folks that consume the service don't need to know which node they are utilizing.
> Right, it doesn't matter IF things are functioning properly.  If they're not, however...

IF things are not functioning properly and the operator of the service 
is depending on end consumers of the service to notify them of which 
node is malfunctioning, then it is time for the operator of the service 
to go back to the drawing board and improve their monitoring and failure 
resolution systems.

>> Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes?
> This isn't expressly about the capability to allow consumers to select one node of another, it's about transparency in which nodes they're using being visible in the control plane - there's no indication of that today.

...but it *is* expressly about selection of nodes...

 From the Introduction of - 
http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00.txt :

"Furthermore, control plane discriminators should exist to enable 
operators to know toward which
of a given set of instances a query is being directed, and to enable
detection and alerting capabilities when this changes. Such
discriminators may also be employed to enable anycast node preference
or filtering keys, should local operational policy require it."

> As for attack surface expanse, no.  You could largely already accomplish something of this sort today in the elements of the forwarding path you influence if you were an evildoer aiming to do such a thing.
>

I disagree (see above).

-DM




From danny at tcb.net  Thu May  5 11:27:04 2011
From: danny at tcb.net (Danny McPherson)
Date: Thu, 5 May 2011 12:27:04 -0400
Subject: Suspecious anycast prefixes
In-Reply-To: <4DC2C923.80200@tiggee.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>	<3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>	<4DC2A998.7080000@tiggee.com>
	<0C0ECC3C-76A5-4029-AE4A-E2CF783ED62E@tcb.net>
	<4DC2C923.80200@tiggee.com>
Message-ID: <7A8579A6-AD03-4BF0-B32E-F97BA6303CDD@tcb.net>


On May 5, 2011, at 11:58 AM, David Miller wrote:
> 
> IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.

Hehh..  As you well know, there are many folks that invest 
enormous time and money into this, and yet realize, that ultimately, 
there are influencers in the routing system and data path between 
the client and the service node that the service operators can't 
control.  All they can do is best enable service consumers to 
identify and incorporate controls that are optimal for their operating 
environments.

> ...but it *is* expressly about selection of nodes...

It enables visibility and transparency which can be employed to 
inform measurement and detection systems.  IF / how an operator 
chooses to apply controls based on that information (e.g., drop 
a prefix originated from an unauthorized origin AS or leaked via 
a known bad path) that's certainly their prerogative.

-danny




From tony at lavanauts.org  Thu May  5 11:26:48 2011
From: tony at lavanauts.org (Antonio Querubin)
Date: Thu, 5 May 2011 06:26:48 -1000 (HST)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com><3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org><B925B320C2655641ADBBFC00B1F0B82004687A7D@ukbb3.ukbroadband.com>
	<BANLkTikqrXvmhTRveNXU1nnamhniCh3rDA@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30BC@RWC-EX1.corp.seven.com>
	<alpine.LRH.2.02.1105041111060.29599@slimemold.creativedynamo.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
Message-ID: <alpine.OSX.2.00.1105050615510.145@antonio-querubins-imac-g5-9.local>

On Wed, 4 May 2011, George Bonser wrote:

>> SSM with encryption?
>
> Well, certainly, but source address can be very easily spoofed with a
> UDP multicast stream.  Now that could be mitigated with a lot of network
> configuration rules but something is needed that just works without all
> that.

It's harder to effectively use spoofed source addresses in multicasting 
because of RPF.  When you couple it with SSM you're forcing the attacker 
to either use multiple injection points, or gain access to a router close 
to the real source address.  Couple that with encryption and you're 
denying spoofed addresses as an effective intrusion venue for large groups 
of viewers listening to a specific SSM source.

Perfect is the enemy of good.

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com



From joey.liuyq at gmail.com  Thu May  5 11:42:31 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Thu, 5 May 2011 11:42:31 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <2C504293-8647-46B3-B316-537D110BE5FC@pch.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<2C504293-8647-46B3-B316-537D110BE5FC@pch.net>
Message-ID: <BANLkTikxitPwsq51PBcyZU=o+F8pOCgfSg@mail.gmail.com>

On Thu, May 5, 2011 at 2:35 AM, Bill Woodcock <woody at pch.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> On May 4, 2011, at 8:23 PM, Yaoqing(Joey) Liu wrote:
>
>> Hi NANOG,
>>
>> I manually extracted the origins and their org info for the announced
>> block of prefixes. All these prefixes were observed being originated
>> by at most four ASNs simultaneously. I suspect they provide anycast or
>> IXP service, but not positive. Please confirm my conjecture if you
>> know them.
>
> The IXP subnets are here:
>
> http://www.pch.net/ixpdir/ip_city_country.pl

We're using these IXP prefixes and they are very helpful, but I'm
afraid they are not complete. For example, I couldn't find any IXP
prefix from the mainland of China, such as Beijing and Shanghai.

Yaoqing
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-Bill
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (Darwin)
>
> iQIcBAEBCAAGBQJNwlM7AAoJEG+kcEsoi3+HXD8P/0Ufpu3KDRZsAzbV6PVcUjIU
> HtGl2aTTkPntLcaEZgItRA1m9GBbiIdDBRsQrR2IDU9K9py5MEhnllmC+JojJpJ9
> xtrxEnisLNiZfCHhy0AHHhHZfbvu9UWpXbHVTuezL1HyRTCscmdyQWJtGYug59p6
> beI9kVlP7laOY6pyrb2rXCDPs0zaVqof4XwWlD5HQMQJcdw5GyyON9ddz7WXROk5
> Q4be9G7w79L164r4nkDDTreZ7yWGqUFSGwXYTRpkItbBgHQtW3fnWKIrVbRl5a3X
> t/3og2OmysYY5g05IjP7Afg0+IPopyS9Kwa1SvgVe+Qu0SX8nZAjhOcSKtMgmPwP
> CdzyK6Mv20+CkwcmAejG44dZ4NWY/Zog8iJ4fDDmgX8CxqGduoG0cLmvXPg9iqz9
> qpxuD6EpqYOXKVFYRy3BOao72PJJgURpd2JGYHw2OiWkOTBP/KkJkOWb4pawDR2B
> q06Zt/XyHqQhFwu4oUq63wOFcsUHn3poEjEtG2kPyYH4R4gUsZJvdXGOXpw3kq52
> z3437Nf0fMnGeu+SKpINQ14GXKWzpxTtwRxDrDBlxyweLsA8ZTgzDxgCljkmO4wc
> XF67uAGlHdu3eXCFHslW8tTrizjWl4fe95qej5oDuNi4okmkU6E6po6ohfphvxPP
> Uu2gSRvFtzCmZGUypu9P
> =BV20
> -----END PGP SIGNATURE-----
>
>



From joey.liuyq at gmail.com  Thu May  5 11:48:31 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Thu, 5 May 2011 11:48:31 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <20110505081031.3e3bb508@t61p>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
	<20110505081031.3e3bb508@t61p>
Message-ID: <BANLkTinqU0yN2NcXS1zn=M5c2HvwNiWwTA@mail.gmail.com>

On Thu, May 5, 2011 at 8:10 AM, John Kristoff <jtk at cymru.com> wrote:
> On Thu, 5 May 2011 11:54:17 +0300
> Joe Abley <jabley at hopcount.ca> wrote:
>
>> Perhaps I'm misunderstanding the original question, but the assertion
>> that anybody is hijacking that particular prefix seems false.
>
> Furthermore, that exchange prefixes may often appear to be anycast is
> not unusual. ?Those prefixes are often originated by multiple disparate
> networks who are connected to the exchange.
You mean that many different exchange points are using the same set of
prefixes as anycast service in different physical locations?
That sounds interesting to me.

Yaoqing

?In a lightning talk I did
> at NANOG 41, I talked about mapping peering relationships at exchanges.
> When I noted that these prefixes are often announced by exchange
> participants, Louie Lee explained that some of his participants often
> announce the space to their transit customers so that monitoring and
> troubleshooting tools don't cause confusion (e.g. traceroutes).
>
> John
>



From jtk at cymru.com  Thu May  5 11:54:48 2011
From: jtk at cymru.com (John Kristoff)
Date: Thu, 5 May 2011 11:54:48 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTinqU0yN2NcXS1zn=M5c2HvwNiWwTA@mail.gmail.com>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
	<20110505081031.3e3bb508@t61p>
	<BANLkTinqU0yN2NcXS1zn=M5c2HvwNiWwTA@mail.gmail.com>
Message-ID: <20110505115448.4a738615@t61p>

On Thu, 5 May 2011 11:48:31 -0500
"Yaoqing(Joey) Liu" <joey.liuyq at gmail.com> wrote:

> > Furthermore, that exchange prefixes may often appear to be anycast
> > is not unusual. ?Those prefixes are often originated by multiple
> > disparate networks who are connected to the exchange.

> You mean that many different exchange points are using the same set of
> prefixes as anycast service in different physical locations?

No, just that you see route announcements for the exchange prefix
coming from multiple different origins and paths.  So it may appear to
be anycast, but in reality would function as if it were multihomed with
the route originating from multiple providers.  Additionally
reachability to addresses within the prefix may differ as a result of
the peering relationships from the perspective of the path taken to get
there.

John



From malayter at gmail.com  Thu May  5 12:45:10 2011
From: malayter at gmail.com (Ryan Malayter)
Date: Thu, 5 May 2011 10:45:10 -0700 (PDT)
Subject: Amazon diagnosis
In-Reply-To: <BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
Message-ID: <a5e145b8-10ad-4d1f-96e5-c4d1866d3331@s2g2000yql.googlegroups.com>



On May 1, 2:29?pm, Jeff Wheeler <j... at inconcepts.biz> wrote:

> What it really boils down to is this: if application developers are
> doing their jobs, a given service can be easy and inexpensive to
> distribute to unrelated systems/networks without a huge infrastructure
> expense. ?If the developers are not, you end up spending a lot of
> money on infrastructure to make up for code, databases, and APIs which
> were not designed with this in mind.

Umm... see the CAP theorem. There are certain things, such as ACID
transactions, which are *impossible* to geographically distribute with
redundancy in a performant and scalable way because of speed of light
constraints.

Of course web-startups like Reddit have no excuse in this area: they
don't even *need* ACID transactions for anything they do, as what they
are storing is utterly unimportant in the financial sense and can be
handled with eventually-consistent semantics. But asynchronous
replication doesn't cut it for something like stock trades, or even
B2C order taking.

I like to bag on my developers for not knowing anything about the
infrastructure, but sometimes you just can't do it right because of
physics. Or you can't do it right without writing your own OS,
networking stacks, file systems, etc., which means it is essentially
"impossible" in the real world.



From george.herbert at gmail.com  Thu May  5 12:52:19 2011
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 5 May 2011 10:52:19 -0700
Subject: Amazon diagnosis
In-Reply-To: <a5e145b8-10ad-4d1f-96e5-c4d1866d3331@s2g2000yql.googlegroups.com>
References: <602316126.1304085701368.JavaMail.nobody@james2>
	<BANLkTinsgstkBQS3vgVfTyLiBFH1te1i2A@mail.gmail.com>
	<4DBDA17C.2040303@tiedyenetworks.com>
	<4DBDA407.1010002@trelane.net>
	<BANLkTikzktQhXiQvmy0mbLQUB4E__AW+9Q@mail.gmail.com>
	<a5e145b8-10ad-4d1f-96e5-c4d1866d3331@s2g2000yql.googlegroups.com>
Message-ID: <BANLkTimLzFHiZP8cEiFKGtFLO6+my2KvAA@mail.gmail.com>

On Thu, May 5, 2011 at 10:45 AM, Ryan Malayter <malayter at gmail.com> wrote:
>
>
> On May 1, 2:29?pm, Jeff Wheeler <j... at inconcepts.biz> wrote:
>
>> What it really boils down to is this: if application developers are
>> doing their jobs, a given service can be easy and inexpensive to
>> distribute to unrelated systems/networks without a huge infrastructure
>> expense. ?If the developers are not, you end up spending a lot of
>> money on infrastructure to make up for code, databases, and APIs which
>> were not designed with this in mind.
>
> Umm... see the CAP theorem. There are certain things, such as ACID
> transactions, which are *impossible* to geographically distribute with
> redundancy in a performant and scalable way because of speed of light
> constraints.

That specific example depends on how order-dependent your consistency
constraint is; you can have time-asynchronous locally ACID changes
across databases which are widely separate.  If your consistency
requires order synchronicity across the geographic DB cluster then
this is a potential epic fail, of course.

The general point is valid.

Being able to tell if your application *really* does require strict
consistency or not, and if it requires strict ordering or not if it
requires strict consistency, is unfortunately beyond most line-level
system designers.  A lot of people guess wrong in both directions, and
either cripple the app's performance unnecessarily or end up with
dangerous failure modes inherent in the architecture.


-- 
-george william herbert
george.herbert at gmail.com



From michael.holstein at csuohio.edu  Thu May  5 13:03:12 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Thu, 05 May 2011 14:03:12 -0400
Subject: OT: Server Cabinet
In-Reply-To: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
Message-ID: <4DC2E660.6000703@csuohio.edu>


> We have a door-way that said server cabinet must fit through, measuring up
> at 620mm.
>
>   

A 24" door? .. dang, that's tiny. Did someone mix up OD and ID when
considering what a 19" rack meant?


> 1) Have you ever had to fit a cabinet through a doorway that's too small?
>   

Yes. I will say up front that it's cheaper and easier to just buy one
that fits (a knockdown, etc.) .. unless you're doing it yourself and
don't assign value to your time, consider you'll be removing at least 1
stud, floor-to-ceiling, and any associated wiring that runs through it,
along with the drywall on both sides. Refitting that, taping, sanding,
painting, etc. If this is a commercial building and you're obligated to
use tradesman, you've got at least 2 (carpentry and electrical), plus
maybe a building permit, etc.

> 2) How did you do it? Cut cabinet, demolish wall ...?
>   

The cabinet will be easier than the wall, but the wall will need less
specialized tools (drywall work is easier than welding).

> 3) If you cut the cabinet, any tips?
>
>   

Anything that will produce a weldable edge will do (sawzall, etc.) but
consider that you will then have to grind the paint and fire up a mig
welder (EMI issues) in your data closet, then grind (and paint) the
results if you want it to look pretty. All I'll say about that is you'd
better be darn sure everything is grounded. Also .. wear a respirator.

Cutting/grinding the welds at the opposed corners top/bottom (to produce
two triangular pieces that can swivel around and in) will be the easiest
to weld back together (using a new triangular piece of steel as a brace
if needed).

If you don't know how to weld (and own a welder), or finish drywall
(also harder than it looks) the costs associated with hiring out either
of your two choices will easily equal just buying one that'd fit.

Also, as someone else mentioned .. what happens next time it needs to move?

Regards,

Michael Holstein
Cleveland State University



From bmanning at vacation.karoshi.com  Thu May  5 13:16:45 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 5 May 2011 18:16:45 +0000
Subject: Suspecious anycast prefixes
In-Reply-To: <31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
Message-ID: <20110505181645.GC1798@vacation.karoshi.com.>

On Thu, May 05, 2011 at 11:54:17AM +0300, Joe Abley wrote:
> 
> On 2011-05-05, at 11:46, bmanning at vacation.karoshi.com wrote:
> 
> > On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
> >> 198.32.64.0/24
> >> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
> >> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
> >> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
> >> AS42909: as-name:         COMMUNITYDNS;descr:           Internet
> >> Computer Bureau Ltd
> > 
> > 	according to Filip, this is -NOT- supposed to be
> > 	anycast.  the only legal origin ASN is 4555.
> > 
> > 	these other ASNs have hijacked the prefix.
> 
> The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
> 
> Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
> 
> 
> Joe

	back in the olden days, this prefix was in active use and for a period of time was anycast.
	methinks Joey was refering to routing -today-...

	one might ask the question, how can you tell when an un-authorized party originates routes
	(yours), from your ASN - their router of course....

/bill



From george.herbert at gmail.com  Thu May  5 13:17:34 2011
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 5 May 2011 11:17:34 -0700
Subject: OT: Server Cabinet
In-Reply-To: <4DC2E660.6000703@csuohio.edu>
References: <BANLkTin4qhFifiTeFcnZ+EU_02-h=wDf+w@mail.gmail.com>
	<4DC2E660.6000703@csuohio.edu>
Message-ID: <BANLkTimF9bZ=0XTRgbeRm1q+xW_8vmtZUg@mail.gmail.com>

On Thu, May 5, 2011 at 11:03 AM, Michael Holstein
<michael.holstein at csuohio.edu> wrote:
>
>> We have a door-way that said server cabinet must fit through, measuring up
>> at 620mm.
>>
>>
>
> A 24" door? .. dang, that's tiny. Did someone mix up OD and ID when
> considering what a 19" rack meant?
>
>
>> 1) Have you ever had to fit a cabinet through a doorway that's too small?
>>
>
> Yes. I will say up front that it's cheaper and easier to just buy one
> that fits (a knockdown, etc.) .. unless you're doing it yourself and
> don't assign value to your time, consider you'll be removing at least 1
> stud, floor-to-ceiling, and any associated wiring that runs through it,
> along with the drywall on both sides. Refitting that, taping, sanding,
> painting, etc. If this is a commercial building and you're obligated to
> use tradesman, you've got at least 2 (carpentry and electrical), plus
> maybe a building permit, etc.
>
>> 2) How did you do it? Cut cabinet, demolish wall ...?
>>
>
> The cabinet will be easier than the wall, but the wall will need less
> specialized tools (drywall work is easier than welding).
>
>> 3) If you cut the cabinet, any tips?
>>
>>
>
> Anything that will produce a weldable edge will do (sawzall, etc.) but
> consider that you will then have to grind the paint and fire up a mig
> welder (EMI issues) in your data closet, then grind (and paint) the
> results if you want it to look pretty. All I'll say about that is you'd
> better be darn sure everything is grounded. Also .. wear a respirator.
>
> Cutting/grinding the welds at the opposed corners top/bottom (to produce
> two triangular pieces that can swivel around and in) will be the easiest
> to weld back together (using a new triangular piece of steel as a brace
> if needed).
>
> If you don't know how to weld (and own a welder), or finish drywall
> (also harder than it looks) the costs associated with hiring out either
> of your two choices will easily equal just buying one that'd fit.
>
> Also, as someone else mentioned .. what happens next time it needs to move?

I own stick and MIG welders; I would not recommend this route for a
new welder.  The racks tend to be thin enough material that getting
welds right is tough for new welders.

Also - if you have proper fire suppression in the room, it's likely to
have a fit at the welding fumes.  12 years ago while I was partially
under the raised floor at Frontier Globalcenter in Sunnyvale, a
Liebert repair guy welding up a frame crack in a air unit set off the
stage 1 fire alarm for the second floor room, and it nearly got to the
stage-2-discharge-all-the-FM200 point (I was far out of the room by
that point, but the FGC facilities guy said it was low single digit
seconds remaining in the countdown when he disarmed).

I recommend another room, or the knockdown rack models and sell this
one on eBay...


-- 
-george william herbert
george.herbert at gmail.com



From rcarpen at network1.net  Thu May  5 13:19:00 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Thu, 05 May 2011 14:19:00 -0400 (EDT)
Subject: OT: Server Cabinet
In-Reply-To: <201105041421.p44EL0rN084318@aurora.sol.net>
Message-ID: <f1c67373-dd87-43aa-acec-ecd88298dbd3@zimbra.network1.net>

----- Original Message -----
> > If you have a need for a 4-post rack, do not accomplish that by
> > using 2 2-po=
> > st racks. You will likely find that rack rails that are designed
> > for a 4-pos=
> > t rack will not fit.
> 
> Why?  With *any* rack, there are always scenarios where the rack
> rails for
> some random item don't end up fitting right.  That's certainly not a
> problem
> inherent to two 2-post racks.  You can find 2-post racks in any
> number of
> interesting and unusual post/flange configurations.  It's certainly
> true
> that picking any old random 2-post rack has certain hazards
> associated with
> it - the solution is don't pick "any old random" one, not "don't pick
> a
> 2-post rack."  But the look-before-buying rule applies to any rack
> you buy,
> doesn't it?

The major issue is that 2-post rack rails are generally U-shaped, and have tapped holes.

Server rack rails are L-shaped and generally have square holes.

The vast majority of mounting rails I have seen in server equipment, in the last few years especially, will not fit because of the extra inside rails. Been there, done that, had to buy a real 4-post rack.

Is it really a big deal to spend $500 for the proper rack?

I do agree that some 4-post racks tend to be flimsier than the 2-post racks, but when properly assembled, any decent brand should work fine. Just make sure to double check the weight capacities.

-Randy



From bmanning at vacation.karoshi.com  Thu May  5 13:24:33 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 5 May 2011 18:24:33 +0000
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTik-7WLe56LZtYDfHB55+DhZCwG5EQ@mail.gmail.com>
References: <ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
	<BANLkTik-7WLe56LZtYDfHB55+DhZCwG5EQ@mail.gmail.com>
Message-ID: <20110505182433.GD1798@vacation.karoshi.com.>

On Thu, May 05, 2011 at 09:36:50AM -0500, Yaoqing(Joey) Liu wrote:
> On Thu, May 5, 2011 at 3:54 AM, Joe Abley <jabley at hopcount.ca> wrote:
> >
> > On 2011-05-05, at 11:46, bmanning at vacation.karoshi.com wrote:
> >
> >> On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
> >>> 198.32.64.0/24
> >>> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
> >>> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
> >>> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
> >>> AS42909: as-name:         COMMUNITYDNS;descr:           Internet
> >>> Computer Bureau Ltd
> >>
> >>       according to Filip, this is -NOT- supposed to be
> >>       anycast.  the only legal origin ASN is 4555.
> >>
> >>       these other ASNs have hijacked the prefix.
> >
> > The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
> 
> This is based on last four year's data(2007-2010)collected from more
> than 120 peers around the world. Today it may be not announced
> anymore, but it used to be announced by the four ASNs simultaneously.
> I just checked the detailed info about this prefix, here it is about
> the prefix:
> 198.32.64.0/24
> (ASN: average peers announcing this prefix:existing period:total
> appearing days: MOAS period: total appearing days)
> 4555:4.94:20080318-20080506:50:20080318-20080506:50
> 9584:3.07:20080402-20080513:42:20080402-20080513:42
> 20144:79.44:20070101-20080501:487:20071215-20080501:138
> 42909:26.39:20071215-20080515:152:20071215-20080513:150
> >
> MY source data
> > Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
> >
> This needs to do further analysis to confirm if it was hijacked
> 
> Yaoqing
> >
> > Joe


	in that period, it was originated by these parties, most of whom were authorized to
	announce it.  at this time, only one ASN is authorized to announce, and its not.

	not sure how you expect to determine, with simple routing data, if the prefix was 
	hijacked.  you would need to see the letters of authorization or contracts of service/carriage
	to determine if an ASN was impropperly announcing.  

	for that matter, why do you care what occured years ago?  the Internet is an evolving, fluid media
	and things change all the time.  if you want particulars on this prefix, i should have the 
	authoritative data, since I was the registered contact for both the prefix and the ASN in that 
	period and can pull the records.  Contact me offline for details on access.

/bill



From bmanning at vacation.karoshi.com  Thu May  5 13:32:14 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 5 May 2011 18:32:14 +0000
Subject: Suspecious anycast prefixes
In-Reply-To: <7A8579A6-AD03-4BF0-B32E-F97BA6303CDD@tcb.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
	<3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>
	<4DC2A998.7080000@tiggee.com>
	<0C0ECC3C-76A5-4029-AE4A-E2CF783ED62E@tcb.net>
	<4DC2C923.80200@tiggee.com>
	<7A8579A6-AD03-4BF0-B32E-F97BA6303CDD@tcb.net>
Message-ID: <20110505183214.GE1798@vacation.karoshi.com.>

On Thu, May 05, 2011 at 12:27:04PM -0400, Danny McPherson wrote:
> 
> On May 5, 2011, at 11:58 AM, David Miller wrote:
> > 
> > IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.
> 
> Hehh..  As you well know, there are many folks that invest 
> enormous time and money into this, and yet realize, that ultimately, 
> there are influencers in the routing system and data path between 
> the client and the service node that the service operators can't 
> control.  All they can do is best enable service consumers to 
> identify and incorporate controls that are optimal for their operating 
> environments.
> 
> > ...but it *is* expressly about selection of nodes...
> 
> It enables visibility and transparency which can be employed to 
> inform measurement and detection systems.  IF / how an operator 
> chooses to apply controls based on that information (e.g., drop 
> a prefix originated from an unauthorized origin AS or leaked via 
> a known bad path) that's certainly their prerogative.
> 
> -danny


	hum...  from the service operator perspective, it seems that the operating mode is to reduce latency
	for the requesting client.  from the client perspective, latency may not be the most important thing

	too bad the anycast fabrics only take the needs of the service operator into account... :(

/bill



From bmanning at vacation.karoshi.com  Thu May  5 13:34:10 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 5 May 2011 18:34:10 +0000
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTinqU0yN2NcXS1zn=M5c2HvwNiWwTA@mail.gmail.com>
References: <BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
	<20110505081031.3e3bb508@t61p>
	<BANLkTinqU0yN2NcXS1zn=M5c2HvwNiWwTA@mail.gmail.com>
Message-ID: <20110505183410.GF1798@vacation.karoshi.com.>

On Thu, May 05, 2011 at 11:48:31AM -0500, Yaoqing(Joey) Liu wrote:
> On Thu, May 5, 2011 at 8:10 AM, John Kristoff <jtk at cymru.com> wrote:
> > On Thu, 5 May 2011 11:54:17 +0300
> > Joe Abley <jabley at hopcount.ca> wrote:
> >
> >> Perhaps I'm misunderstanding the original question, but the assertion
> >> that anybody is hijacking that particular prefix seems false.
> >
> > Furthermore, that exchange prefixes may often appear to be anycast is
> > not unusual.  Those prefixes are often originated by multiple disparate
> > networks who are connected to the exchange.
> You mean that many different exchange points are using the same set of
> prefixes as anycast service in different physical locations?
> That sounds interesting to me.

	that has been a fairly common practice for nearly 15 years.

/bill

> 
> Yaoqing
> 
>  In a lightning talk I did
> > at NANOG 41, I talked about mapping peering relationships at exchanges.
> > When I noted that these prefixes are often announced by exchange
> > participants, Louie Lee explained that some of his participants often
> > announce the space to their transit customers so that monitoring and
> > troubleshooting tools don't cause confusion (e.g. traceroutes).
> >
> > John
> >



From jgreco at ns.sol.net  Thu May  5 13:50:25 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Thu, 5 May 2011 13:50:25 -0500 (CDT)
Subject: OT: Server Cabinet
In-Reply-To: <f1c67373-dd87-43aa-acec-ecd88298dbd3@zimbra.network1.net>
Message-ID: <201105051850.p45IoP0D005919@aurora.sol.net>

> > > If you have a need for a 4-post rack, do not accomplish that by
> > > using 2 2-po=
> > > st racks. You will likely find that rack rails that are designed
> > > for a 4-pos=
> > > t rack will not fit.
> > 
> > Why?  With *any* rack, there are always scenarios where the rack
> > rails for
> > some random item don't end up fitting right.  That's certainly not a
> > problem
> > inherent to two 2-post racks.  You can find 2-post racks in any
> > number of
> > interesting and unusual post/flange configurations.  It's certainly
> > true
> > that picking any old random 2-post rack has certain hazards
> > associated with
> > it - the solution is don't pick "any old random" one, not "don't pick
> > a
> > 2-post rack."  But the look-before-buying rule applies to any rack
> > you buy,
> > doesn't it?
> 
> The major issue is that 2-post rack rails are generally U-shaped,
> and have tapped holes.

Which some of us prefer, unless we're mounting lots of servers or
something like that.  When you're working with various odd bits of
networking gear, square holes just mean you get to do lots of cage
nuts until your eyes go crossed and you finally realize when putting
in that eighth screw on a big bit of equipment that you misaligned
the last cage nut.  And you know it's always the last one, and you
can't slide it because it's too tight.

> Server rack rails are L-shaped and generally have square holes.

Many are, yes.

> The vast majority of mounting rails I have seen in server 
> equipment, in the last few years especially, will not fit because
> of the extra inside rails. Been there, done that, had to buy a
> real 4-post rack.

I guess that could be.  My own experience in the last few years is
that it hasn't been a problem.  An old Cisco AccessPath rack I use
here in the shop for testing took several HP DLnnn servers with the
HP rails no problem; it's a tapped-hole beast but the HP rails just
needed the pegs removed and they worked fine, no worries about any
hangouts on the sides or anything else that I can recall.

> Is it really a big deal to spend $500 for the proper rack?

I believe we were making suggestions as to what the "proper rack"
might be, and that we haven't really heard any guidance as to what
the rack will be used for, so this is all speculation.

Myself, I kind of took a wild stab at "HP servers" because normally
one doesn't buy an HP rack for Dell servers.  Of course, there are
almost certainly HP servers with rails that won't work well in a
pair of relay racks.  I also didn't bother to duplicate suggestions
that others had already made; my listing of a single suggestion 
wasn't meant to imply that mine was the best recommendation or 
anything like that.

Speaking as someone who's had POP's in very small closet-like rooms,
I feel compelled to note that tales of various options, including
the good and the bad, would have been welcome many years ago.  Alas,
NANOG didn't exist back then.  As it stands, I don't think that one
can reach a conclusion as to what the "proper rack" for this guy is,
but I can say that from my own experience, folks have provided a 
very comprehensive set of options and a wealth of practical 
experience that ought to move things in the right direction.  It's 
been enjoyable to read, too...  you realize that many others have 
had some of those same cursing, swearing bad days out on the floor.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.



From bill at herrin.us  Thu May  5 13:58:15 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 5 May 2011 14:58:15 -0400
Subject: OT: Server Cabinet
In-Reply-To: <201105051850.p45IoP0D005919@aurora.sol.net>
References: <f1c67373-dd87-43aa-acec-ecd88298dbd3@zimbra.network1.net>
	<201105051850.p45IoP0D005919@aurora.sol.net>
Message-ID: <BANLkTineNYVkNOMnb0v_6v9om3EtqAHyrA@mail.gmail.com>

On Thu, May 5, 2011 at 2:50 PM, Joe Greco <jgreco at ns.sol.net> wrote:
> I guess that could be. ?My own experience in the last few years is
> that it hasn't been a problem. ?An old Cisco AccessPath rack I use
> here in the shop for testing took several HP DLnnn servers with the
> HP rails no problem; it's a tapped-hole beast but the HP rails just
> needed the pegs removed and they worked fine, no worries about any
> hangouts on the sides or anything else that I can recall.

Dell is the main offender here. HP mostly figured this one out five
years ago though some of their rebranded equipment still suffers.

Regards,
Bill Herrin






-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From jra at baylink.com  Thu May  5 14:45:06 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 5 May 2011 15:45:06 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E30EF@RWC-EX1.corp.seven.com>
Message-ID: <32240115.645.1304624706000.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "George Bonser" <gbonser at seven.com>

> So using multicast for things like software updates to computers over
> the general internet to the general public probably isn't going to
> work.
> Encryption is also an issue because it doesn't really work well over
> multicast. How do I encrypt something in a way that anyone can decrypt
> but nobody can duplicate? If I have a separate stream per user, that
> is
> easy. If I have one stream for all users, that is harder. The answer
> is probably in some sort of digital signature but not really
> encryption.

Um, yeah; that'd be private key digital signature.

> Using public/private key encryption over multicast, I would have to
> distribute the private key so others could decrypt the content. If
> they have the private key, they can generate a public key to use to
> generate content.


> Encryption is probably overkill anyway. What is needed is a mechanism
> simply to say that the content is certified to have come from the
> source it claims to come from. So ... basically ... better not to use
> multicast for anything you really might have any security issues with.
> Fine for broadcasting a video, not so fine for a kernel update.

Nah; you're overthinking it.  Signed updates solve the problem just fine.

Note that Linux (SuSE/YAST/YOU) does this already.

But you *are* expanding the attack surface, and the signature/PKI 
infrastructure has to be correspondingly more robust.

Cheers,
-- jra



From jra at baylink.com  Thu May  5 14:47:12 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 5 May 2011 15:47:12 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTim=XPndbP5HBefg1VCSyn=WqyqaeA@mail.gmail.com>
Message-ID: <10552384.647.1304624832356.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeff Wheeler" <jsw at inconcepts.biz>

> There are certainly things that need work before I can start up Jeff's
> Internet Movie Channel and go into competition with HBO, but for the
> most part, these are solvable if networks decided to do it. The big
> limitation is there can't be infinite groups -- FIB is only so big and
> there is no agreeable mechanism for sharing the number that can be
> made to exist, given current (and foreseeable) routers. Since so many
> "eyeballs" are sitting on ISPs that also own television networks and
> other media properties, though, I don't think we will get multicast
> anytime soon.

Unless (what I assert is) Google's plan to engender muni fiber last-mile
really catches fire -- at which point it will become logistically practical
for people like Chris Adams to compete with people like Road Runner... and
you'll have your end-user transport.

Bet me cash Google City will be multicast capable.

Cheers
-- jra



From jra at baylink.com  Thu May  5 14:48:56 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 5 May 2011 15:48:56 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <A33A7BDC-CD34-4819-A996-59FA1A392161@cs.columbia.edu>
Message-ID: <1340322.651.1304624936615.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Steven Bellovin" <smb at cs.columbia.edu>

> > Encryption is probably overkill anyway. What is needed is a mechanism
> > simply to say that the content is certified to have come from the source
> > it claims to come from. So ... basically ... better not to use
> > multicast for anything you really might have any security issues
> > with. Fine for broadcasting a video, not so fine for a kernel update.
> >
> See the work of the IETF MIKEY working group.

He won't like it.  He hates everything.

Cheers,
-- jra



From cmadams at hiwaay.net  Thu May  5 14:59:04 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 5 May 2011 14:59:04 -0500
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <10552384.647.1304624832356.JavaMail.root@benjamin.baylink.com>
References: <BANLkTim=XPndbP5HBefg1VCSyn=WqyqaeA@mail.gmail.com>
	<10552384.647.1304624832356.JavaMail.root@benjamin.baylink.com>
Message-ID: <20110505195904.GD14900@hiwaay.net>

Once upon a time, Jay Ashworth <jra at baylink.com> said:
> Unless (what I assert is) Google's plan to engender muni fiber last-mile
> really catches fire -- at which point it will become logistically practical
> for people like Chris Adams to compete with people like Road Runner... and
> you'll have your end-user transport.

Yay, I'm an example on NANOG! :-)

I wish Huntsville had been chosen by the GOOG.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From jbaino at gmail.com  Thu May  5 15:34:38 2011
From: jbaino at gmail.com (Jeremy)
Date: Thu, 5 May 2011 15:34:38 -0500
Subject: ASR 1006 question
Message-ID: <BANLkTinAhsgejQjdugFhc-91XvLM6U=PiQ@mail.gmail.com>

Hey All,

I think i may be noobing this one here, any help would be appreciated. We
have an ASR1006 with a SIP and a 2x1gbps SPA. Right now we have:

 2800 g0/0<----- -> ASR1006 g1/0/0

All we're trying to do is set an IP address on each interface so we can ping
(192.168.1.1 on the 2800, 192.168.1.2 on the ASR). We have the IPs
configured on both but it's just not working. The 2800 is fine, if we attach
a laptop to it and ping it works as expected. However when we attach the
laptop to the ASR no ARP or ICMP messages are sent from the ASR, wireshark
shows no traffice what so ever. The Interface is up/up and it was a fresh
config, all we've done is add the IP address. Any thoughts? This shouldn't
be this hard so I must be overlooking something silly.

Thanks!
-Jeremy


From fredr at geexology.org  Thu May  5 15:39:12 2011
From: fredr at geexology.org (Fred Richards)
Date: Thu, 5 May 2011 16:39:12 -0400
Subject: ASR 1006 question
In-Reply-To: <BANLkTinAhsgejQjdugFhc-91XvLM6U=PiQ@mail.gmail.com>
References: <BANLkTinAhsgejQjdugFhc-91XvLM6U=PiQ@mail.gmail.com>
Message-ID: <BANLkTimSnOrr54_rrJnBozBYcZ1Lkd+4Ew@mail.gmail.com>

Show the output of a "show interface" command.

On Thu, May 5, 2011 at 4:34 PM, Jeremy <jbaino at gmail.com> wrote:

> Hey All,
>
> I think i may be noobing this one here, any help would be appreciated. We
> have an ASR1006 with a SIP and a 2x1gbps SPA. Right now we have:
>
>  2800 g0/0<----- -> ASR1006 g1/0/0
>
> All we're trying to do is set an IP address on each interface so we can
> ping
> (192.168.1.1 on the 2800, 192.168.1.2 on the ASR). We have the IPs
> configured on both but it's just not working. The 2800 is fine, if we
> attach
> a laptop to it and ping it works as expected. However when we attach the
> laptop to the ASR no ARP or ICMP messages are sent from the ASR, wireshark
> shows no traffice what so ever. The Interface is up/up and it was a fresh
> config, all we've done is add the IP address. Any thoughts? This shouldn't
> be this hard so I must be overlooking something silly.
>
>
Copy/Paste the output of a "show interface" command.


-- 
                      Fred


From jra at baylink.com  Thu May  5 15:51:11 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 5 May 2011 16:51:11 -0400 (EDT)
Subject: Amazon diagnosis
In-Reply-To: <a5e145b8-10ad-4d1f-96e5-c4d1866d3331@s2g2000yql.googlegroups.com>
Message-ID: <31515005.659.1304628671744.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ryan Malayter" <malayter at gmail.com>

> I like to bag on my developers for not knowing anything about the
> infrastructure, but sometimes you just can't do it right because of
> physics. Or you can't do it right without writing your own OS,
> networking stacks, file systems, etc., which means it is essentially
> "impossible" in the real world.

"Physics"?

Isn't that an entirely inadequate substitute for "desire"?

Cheers,
-- jra



From cmorris at cs.odu.edu  Fri May  6 08:34:34 2011
From: cmorris at cs.odu.edu (Charles Morris)
Date: Fri, 6 May 2011 09:34:34 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>
	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
Message-ID: <BANLkTikoqLp39y_BHRFm7Ksj2hzDSxAbTg@mail.gmail.com>

On Wed, May 4, 2011 at 12:26 PM, Tim Franklin <tim at pelican.org> wrote:
>> I think that George's POV -- which is also mine -- is that as the
>> world shifts, the percentage of video distribution which is
>> amenable to multicast, and not well served by unicast, is likely
>> to grow, and it would be a Good Idea to be ready for that
>> situation already when it arrives.
>
> Really? ?If anything, I'd say quite the opposite. ?Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. ?(As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). ?I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
>
> I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
>
> Regards,
> Tim.
>
>

Content can still be multicasted to the edge caching servers, for
near-real-time updates,
that you then may visit/view on-demand with your favorite unicast client

Charles



From khelms at ispalliance.net  Fri May  6 08:58:14 2011
From: khelms at ispalliance.net (Scott Helms)
Date: Fri, 06 May 2011 09:58:14 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTikoqLp39y_BHRFm7Ksj2hzDSxAbTg@mail.gmail.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com>	<3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<BANLkTikoqLp39y_BHRFm7Ksj2hzDSxAbTg@mail.gmail.com>
Message-ID: <4DC3FE76.9070609@ispalliance.net>

Absolutely, multicast inside of a provider network is critical for 
feeding local caches.  This is a common approach in IPTV networks 
supporting VOD via multiple headends.
> Content can still be multicasted to the edge caching servers, for
> near-real-time updates,
> that you then may visit/view on-demand with your favorite unicast client
>
> Charles
>
>


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------




From malayter at gmail.com  Fri May  6 09:35:46 2011
From: malayter at gmail.com (Ryan Malayter)
Date: Fri, 6 May 2011 07:35:46 -0700 (PDT)
Subject: Amazon diagnosis
In-Reply-To: <31515005.659.1304628671744.JavaMail.root@benjamin.baylink.com>
References: <31515005.659.1304628671744.JavaMail.root@benjamin.baylink.com>
Message-ID: <b1e7383b-732d-46e0-9128-39a73484c5e7@v8g2000yqb.googlegroups.com>



On May 5, 3:51?pm, Jay Ashworth <j... at baylink.com> wrote:
> ----- Original Message -----
> > From: "Ryan Malayter" <malay... at gmail.com>
> > I like to bag on my developers for not knowing anything about the
> > infrastructure, but sometimes you just can't do it right because of
> > physics. Or you can't do it right without writing your own OS,
> > networking stacks, file systems, etc., which means it is essentially
> > "impossible" in the real world.
>
> "Physics"?
>
> Isn't that an entirely inadequate substitute for "desire"?

Not really. For some applications, it is physics:
   1) You need two or more locations separated by say 500km for
disaster protection (think Katrina, or Japan Tsunami).
   2) Those two locations need to be 100% consistent, with in-order
"serializable" ACID semantics for a particular database entity. An
example would be some sort of financial account - the order of
transactions against that account must be such that an account cannot
go below a certain value, and debits to and from different accounts
must always happen together or not at all.

The above implies a two-phase commit protocol. This, in turn, implies
*at least* two network round-trips. Given a perfect dedicated fiber
network and no switch/router/CPU/disk latency, this means at least
10.8 ms per transaction, or at most 92 transactions per second per
affected database entity. The reality of real networks, disks,
databases, and servers makes this perfect scenario unachievable -
often by an order of magnitude.

I don't have inside knowledge, but I suspect this is why Wall Street
firms have DR sites across the river in New Jersey, rather than
somewhere "safer".

Amazon's EBS service is network-based block storage, with semantics
similar to the financial account scenario: data writes to the volume
must happen in-order at all replicas. Which is why EBS volumes cannot
have a replica a great distance away from the primary. So any
application which used the EBS abstraction for keeping consistent
state were screwed during this Amazon outage. The fact that Amazon's
availability zones were not, in fact, very isolated from each other
for this particular failure scenario compounded the problem.



From jra at baylink.com  Fri May  6 09:42:13 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 6 May 2011 10:42:13 -0400 (EDT)
Subject: Amazon diagnosis
In-Reply-To: <b1e7383b-732d-46e0-9128-39a73484c5e7@v8g2000yqb.googlegroups.com>
Message-ID: <26372183.681.1304692933171.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ryan Malayter" <malayter at gmail.com>

> On May 5, 3:51 pm, Jay Ashworth <j... at baylink.com> wrote:
> > ----- Original Message -----
> > > From: "Ryan Malayter" <malay... at gmail.com>
> > > I like to bag on my developers for not knowing anything about the
> > > infrastructure, but sometimes you just can't do it right because
> > > of
> > > physics. Or you can't do it right without writing your own OS,
> > > networking stacks, file systems, etc., which means it is
> > > essentially
> > > "impossible" in the real world.
> >
> > "Physics"?
> >
> > Isn't that an entirely inadequate substitute for "desire"?
> 
> Not really. For some applications, it is physics:

You misinterpreted me.  I was making fun of people who think "I want
it, and therefore it WILL be so" trumps physics, of whom there are
altogether too many in positions of power these days to suit me.

> I don't have inside knowledge, but I suspect this is why Wall Street
> firms have DR sites across the river in New Jersey, rather than
> somewhere "safer".

You don't need inside knowledge; that issue's the subject of much
general press lately; that's exactly why they do it.

And they think it's good enough.

I truly wish that their finding out it's not wouldn't be so massively
disrupting for the rest of us poor slobs...
 
> Amazon's EBS service is network-based block storage, with semantics
> similar to the financial account scenario: data writes to the volume
> must happen in-order at all replicas. Which is why EBS volumes cannot
> have a replica a great distance away from the primary. So any
> application which used the EBS abstraction for keeping consistent
> state were screwed during this Amazon outage. The fact that Amazon's
> availability zones were not, in fact, very isolated from each other
> for this particular failure scenario compounded the problem.

Oh, so maybe "letting someone else do the cloud for you"'s a bad idea?

Whod'a thunk *that*?  :-)

Cheers,
-- jra



From gbonser at seven.com  Fri May  6 11:03:39 2011
From: gbonser at seven.com (George Bonser)
Date: Fri, 6 May 2011 09:03:39 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTikoqLp39y_BHRFm7Ksj2hzDSxAbTg@mail.gmail.com>
References: <11118197.585.1304525043428.JavaMail.root@benjamin.baylink.com><3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<BANLkTikoqLp39y_BHRFm7Ksj2hzDSxAbTg@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E312B@RWC-EX1.corp.seven.com>

> Content can still be multicasted to the edge caching servers, for
> near-real-time updates,
> that you then may visit/view on-demand with your favorite unicast
> client
> 
> Charles

Yep.  That gives a hybrid approach that still greatly reduces the load
on the ultimate content source.  One stream for all.  Individual
providers could then hold the content for unicast distribution within
their net or the broadcast provider could even provide the server
collocated at the eyeball network.  And as you mention, as people shift
to using the Internet for stuff that was traditionally the domain of
broadcast traffic anyway, the same broadcast concepts would still apply
as being a good means of sending the traffic.  

It would actually be rather simple with tools that are available right
now.  Maybe content distribution using UFTP
http://www.tcnj.edu/~bush/uftp.html and then unicast to the end user
from those systems.

But for major events or things like content that is normally a broadcast
channel (e.g. cable news), straight multicast all the way to the user is
probably best, in my opinion.





From cscora at apnic.net  Fri May  6 14:00:30 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 7 May 2011 05:00:30 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201105061900.p46J0U9s005571@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfs at cisco.com>.

Routing Table Report   04:00 +10GMT Sat 07 May, 2011

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              356623
    Prefixes after maximum aggregation:                          161219
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     176188
Total ASes present in the Internet Routing Table:                 37501
    Prefixes per ASN:                                              9.51
Origin-only ASes present in the Internet Routing Table:           31368
Origin ASes announcing only one prefix:                           15102
Transit ASes present in the Internet Routing Table:                5082
Transit-only ASes present in the Internet Routing Table:            139
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               592
    Unregistered ASNs in the Routing Table:                         299
Number of 32-bit ASNs allocated by the RIRs:                       1333
Number of 32-bit ASNs visible in the Routing Table:                1051
Prefixes from 32-bit ASNs in the Routing Table:                    2383
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            147
Number of addresses announced to Internet:                   2423268544
    Equivalent to 144 /8s, 112 /16s and 36 /24s
    Percentage of available address space announced:               65.4
    Percentage of allocated address space announced:               65.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               90.7
Total number of prefixes smaller than registry allocations:      148140

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    89329
    Total APNIC prefixes after maximum aggregation:               29919
    APNIC Deaggregation factor:                                    2.99
Prefixes being announced from the APNIC address blocks:           85712
    Unique aggregates announced from the APNIC address blocks:    36913
APNIC Region origin ASes present in the Internet Routing Table:    4437
    APNIC Prefixes per ASN:                                       19.32
APNIC Region origin ASes announcing only one prefix:               1235
APNIC Region transit ASes present in the Internet Routing Table:    707
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:     48
Number of APNIC addresses announced to Internet:              612912416
    Equivalent to 36 /8s, 136 /16s and 77 /24s
    Percentage of available APNIC address space announced:         77.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
                       55296-56319, 131072-132095
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    140234
    Total ARIN prefixes after maximum aggregation:                71250
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           112594
    Unique aggregates announced from the ARIN address blocks:     45335
ARIN Region origin ASes present in the Internet Routing Table:    14357
    ARIN Prefixes per ASN:                                         7.84
ARIN Region origin ASes announcing only one prefix:                5492
ARIN Region transit ASes present in the Internet Routing Table:    1499
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               800024832
    Equivalent to 47 /8s, 175 /16s and 105 /24s
    Percentage of available ARIN address space announced:          63.6

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     83935
    Total RIPE prefixes after maximum aggregation:                48029
    RIPE Deaggregation factor:                                     1.75
Prefixes being announced from the RIPE address blocks:            77374
    Unique aggregates announced from the RIPE address blocks:     51246
RIPE Region origin ASes present in the Internet Routing Table:    15569
    RIPE Prefixes per ASN:                                         4.97
RIPE Region origin ASes announcing only one prefix:                7811
RIPE Region transit ASes present in the Internet Routing Table:    2452
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          36
Number of RIPE region 32-bit ASNs visible in the Routing Table:     777
Number of RIPE addresses announced to Internet:               468167936
    Equivalent to 27 /8s, 231 /16s and 173 /24s
    Percentage of available RIPE address space announced:          75.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   32749
    Total LACNIC prefixes after maximum aggregation:               7494
    LACNIC Deaggregation factor:                                   4.37
Prefixes being announced from the LACNIC address blocks:          31794
    Unique aggregates announced from the LACNIC address blocks:   16628
LACNIC Region origin ASes present in the Internet Routing Table:   1450
    LACNIC Prefixes per ASN:                                      21.93
LACNIC Region origin ASes announcing only one prefix:               430
LACNIC Region transit ASes present in the Internet Routing Table:   268
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   209
Number of LACNIC addresses announced to Internet:              83079680
    Equivalent to 4 /8s, 243 /16s and 178 /24s
    Percentage of available LACNIC address space announced:        55.0

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   7778
    Total AfriNIC prefixes after maximum aggregation:              1857
    AfriNIC Deaggregation factor:                                  4.19
Prefixes being announced from the AfriNIC address blocks:          6135
    Unique aggregates announced from the AfriNIC address blocks:   1917
AfriNIC Region origin ASes present in the Internet Routing Table:   447
    AfriNIC Prefixes per ASN:                                     13.72
AfriNIC Region origin ASes announcing only one prefix:              134
AfriNIC Region transit ASes present in the Internet Routing Table:   97
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             23038208
    Equivalent to 1 /8s, 95 /16s and 137 /24s
    Percentage of available AfriNIC address space announced:       34.3

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2436       9490         906   Korea Telecom (KIX)
17974     1813        515          29   PT TELEKOMUNIKASI INDONESIA
 7545     1565        301          86   TPG Internet Pty Ltd
 4755     1461        634         167   TATA Communications formerly 
 7552     1204       1064           7   Vietel Corporation
24560     1151        336         184   Bharti Airtel Ltd., Telemedia
 9583     1057         77         492   Sify Limited
 9829     1039        874          51   BSNL National Internet Backbo
 4808     1036       2087         294   CNCGROUP IP network: China169
17488      938        164         100   Hathway IP Over Cable Interne

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3644       3822         258   bellsouth.net, inc. 
 4323     2582       1087         399   Time Warner Telecom
 1785     1785        681         127   PaeTec Communications, Inc.
18566     1782        354         219   Covad Communications 
 6478     1667        313          52   AT&T Worldnet Services 
20115     1531       1536         636   Charter Communications 
19262     1496       4949         298   Verizon Global Networks 
 7018     1359       6927         887   AT&T WorldNet Services
22773     1329       2897          87   Cox Communications, Inc.
 2386     1265        536         908   AT&T Data Communications Serv

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6830      519       1780         321   UPC Distribution Services
34984      508        106         184   BILISIM TELEKOM
 3292      457       1997         391   TDC Tele Danmark
20940      446        131         342   Akamai Technologies European 
 8866      444        134          26   Bulgarian Telecommunication C
29049      443         33          43   AzerSat LLC.
 3320      423       7609         368   Deutsche Telekom AG
12479      419        577           6   Uni2 Autonomous System
 8551      406        355          45   Bezeq International
 8402      401        320          11   Corbina telecom

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1458        270         155   TVCABLE BOGOTA 
 8151     1366       2698         364   UniNet S.A. de C.V. 
28573     1298        990          89   NET Servicos de Comunicao S.A
 7303      926        467         149   Telecom Argentina Stet-France
 6503      801        354          73   AVANTEL, S.A. 
14420      665         53          91   CORPORACION NACIONAL DE TELEC
22047      557        310          15   VTR PUNTO NET S.A. 
 3816      518        226          99   Empresa Nacional de Telecomun
11172      495         84          83   Servicios Alestra S.A de C.V 
13489      487        233         116   Orbitel S.A. E.S.P. 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452      881        445          11   TEDATA
24863      782        147          37   LINKdotNET AS number
15475      421         90           8   Nile Online
36992      287        331          17   Etisalat MISR
 3741      267        985         227   The Internet Solution 
 6713      240        215          13   Itissalat Al-MAGHRIB
33776      214         12          11   Starcomms Nigeria Limited
24835      209         78          10   RAYA Telecom - Egypt
29571      161         17          11   Ci Telecom Autonomous system 
16637      149        441          86   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3644       3822         258   bellsouth.net, inc. 
 4323     2582       1087         399   Time Warner Telecom
 4766     2436       9490         906   Korea Telecom (KIX)
23456     2383        666        1288   32-bit ASN transition
17974     1813        515          29   PT TELEKOMUNIKASI INDONESIA
 1785     1785        681         127   PaeTec Communications, Inc.
18566     1782        354         219   Covad Communications 
 6478     1667        313          52   AT&T Worldnet Services 
 7545     1565        301          86   TPG Internet Pty Ltd
20115     1531       1536         636   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 4323      2582        2183      Time Warner Telecom
17974      1813        1784      PT TELEKOMUNIKASI INDONESIA
 1785      1785        1658      PaeTec Communications, Inc.
 6478      1667        1615      AT&T Worldnet Services 
18566      1782        1563      Covad Communications 
 4766      2436        1530      Korea Telecom (KIX)
 7545      1565        1479      TPG Internet Pty Ltd
10620      1458        1303      TVCABLE BOGOTA 
 4755      1461        1294      TATA Communications formerly 
11492      1262        1247      Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
31.210.248.0/21      35706     Net at Once
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
45.127.0.0/16        13767     NetworkTwo Communications Gro

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:20       /9:12      /10:28      /11:78      /12:223     
/13:458     /14:790     /15:1389    /16:11689   /17:5747    /18:9693    
/19:19273   /20:25574   /21:25731   /22:33992   /23:32787   /24:185889  
/25:1096    /26:1273    /27:707     /28:158     /29:8       /30:2       
/31:0       /32:6       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2245          3644      bellsouth.net, inc. 
18566     1744          1782      Covad Communications 
 6478     1621          1667      AT&T Worldnet Services 
10620     1348          1458      TVCABLE BOGOTA 
 4323     1289          2582      Time Warner Telecom
11492     1211          1262      Cable One 
23456     1182          2383      32-bit ASN transition
 7011     1062          1162      Citizens Utilities 
 1785     1054          1785      PaeTec Communications, Inc.
22773      846          1329      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:265       2:61        4:14        5:1         6:3         8:353    
  12:1992     13:1        14:452      15:15       16:3        17:8      
  20:10       23:6        24:1627     27:734      31:296      32:63     
  33:3        34:2        37:1        38:765      40:101      41:2485   
  42:4        44:3        46:906      47:4        49:172      50:388    
  52:13       55:4        56:2        57:30       58:843      59:482    
  60:387      61:1254     62:995      63:1926     64:3927     65:2308   
  66:4319     67:1873     68:1079     69:2966     70:699      71:346    
  72:1884     73:1        74:2339     75:299      76:338      77:838    
  78:688      79:454      80:1079     81:813      82:494      83:446    
  84:630      85:1076     86:577      87:747      88:323      89:1596   
  90:192      91:3707     92:511      93:1062     94:1266     95:804    
  96:482      97:255      98:823      99:35      101:69      103:9      
 107:6       108:85      109:946     110:583     111:710     112:318    
 113:399     114:532     115:657     116:949     117:678     118:818    
 119:1143    120:305     121:672     122:1619    123:1080    124:1254   
 125:1221    128:259     129:163     130:165     131:564     132:109    
 133:19      134:217     135:49      136:214     137:143     138:302    
 139:105     140:480     141:239     142:400     143:398     144:486    
 145:50      146:436     147:210     148:595     149:243     150:171    
 151:187     152:310     153:179     154:3       155:396     156:190    
 157:352     158:130     159:384     160:315     161:205     162:279    
 163:164     164:498     165:349     166:513     167:426     168:699    
 169:153     170:784     171:77      172:1       173:1538    174:538    
 175:373     177:119     178:859     180:818     181:19      182:434    
 183:208     184:260     185:1       186:1153    187:800     188:847    
 189:941     190:4853    192:5792    193:4827    194:3466    195:2966   
 196:1201    197:16      198:3564    199:3921    200:5526    201:1504   
 202:8357    203:8448    204:4137    205:2327    206:2747    207:3038   
 208:3960    209:3481    210:2721    211:1372    212:1978    213:1718   
 214:721     215:64      216:4893    217:1657    218:565     219:371    
 220:1204    221:484     222:342     223:146    

End of report



From chipps at chipps.com  Fri May  6 14:43:28 2011
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Fri, 6 May 2011 14:43:28 -0500
Subject: Amazon diagnosis
In-Reply-To: <26372183.681.1304692933171.JavaMail.root@benjamin.baylink.com>
References: <b1e7383b-732d-46e0-9128-39a73484c5e7@v8g2000yqb.googlegroups.com>
	<26372183.681.1304692933171.JavaMail.root@benjamin.baylink.com>
Message-ID: <000c01cc0c25$e17bec20$a473c460$@chipps.com>

I am preparing a graduate level course for network managers. As part of this course I would like to use a series of case studies looking at problems such as described in the report from Amazon. If anyone has something similar or knows where I could find such things, I would appreciate a copy or a link to it.

Kenneth M. Chipps Ph.D.




From francois at menards.ca  Fri May  6 15:41:12 2011
From: francois at menards.ca (Francois Menard)
Date: Fri, 6 May 2011 16:41:12 -0400
Subject: IPv6 implementation NANOG list
In-Reply-To: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com>
References: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com>
Message-ID: <D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>

Folks,

I am looking at rolling out IPv6 in the access.

My platform does DHCP Option 82 for geolocating customer MACs to certain ports of multi-port layer 2 demarcation devices.

What is the IPv6 version of that ?

F.


From francois at menards.ca  Fri May  6 15:43:59 2011
From: francois at menards.ca (Francois Menard)
Date: Fri, 6 May 2011 16:43:59 -0400
Subject: open source DPI suggestions?
In-Reply-To: <BANLkTimjGkASY8AVx88qXji9XjRwwu_o6Q@mail.gmail.com>
References: <BANLkTikgdZUrOLLa+E3L-WT5o7czrheUWA@mail.gmail.com>
	<9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org>
	<09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net>
	<BANLkTimjGkASY8AVx88qXji9XjRwwu_o6Q@mail.gmail.com>
Message-ID: <C083B1E0-E72F-4AE6-9FE3-D72788B61433@menards.ca>


How about RouterOS from Mikrotik ?

You cannot beat a $70 RB750G for doing P2P hijacking.

F.

On 2011-04-29, at 8:59 AM, Kornelijus Survila wrote:

> Snort (http://www.snort.org/) is also a nice IDS. They provide paid and free
> rules/signatures.
> 
> -k
> 
> On Fri, Apr 29, 2011 at 7:55 AM, Raymond Burkholder <ray at oneunified.net>wrote:
> 
>>>> Can anyone suggest any open source DPI (deep packet inspection)
>>> projects?
>>> 
>>> 
>>> I'll recommend Bro-IDS (http://www.bro-ids.org/) as it's what I spend my
>>> days working on.  It's essentially a programming language for long term
>>> network traffic monitoring which is focused on doing deep decoding of
>>> application layer protocols.  (and it's BSD licensed!)
>>> 
>> 
>> http://l7-filter.sourceforge.net/ might be another candidate.
>> 
>> 
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>> 
>> 
>> 




From owen at delong.com  Fri May  6 15:53:51 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 6 May 2011 13:53:51 -0700
Subject: IPv6 implementation NANOG list
In-Reply-To: <D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>
References: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com>
	<D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>
Message-ID: <C076ABAF-6B34-4BE1-85FD-B48910FAE449@delong.com>

I'm honestly not sure, but, check RFCs:

	3315 (OPTION_RELAY_MSG)
	4580 (Relay Agent Subscriber-ID)
	5007 (Various LQ related Options, including OPTION_LQ_RELAY_DATA)

Owen

On May 6, 2011, at 1:41 PM, Francois Menard wrote:

> Folks,
> 
> I am looking at rolling out IPv6 in the access.
> 
> My platform does DHCP Option 82 for geolocating customer MACs to certain ports of multi-port layer 2 demarcation devices.
> 
> What is the IPv6 version of that ?
> 
> F.




From r.boissat at gmail.com  Fri May  6 15:59:20 2011
From: r.boissat at gmail.com (Romain Boissat)
Date: Fri, 6 May 2011 22:59:20 +0200
Subject: IPv6 implementation NANOG list
In-Reply-To: <C076ABAF-6B34-4BE1-85FD-B48910FAE449@delong.com>
References: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com>
	<D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>
	<C076ABAF-6B34-4BE1-85FD-B48910FAE449@delong.com>
Message-ID: <20110506205920.GA21677@gnaea.lv0.in>

On Fri, May 06, 2011 at 01:53:51PM -0700, Owen DeLong wrote:
> I'm honestly not sure, but, check RFCs:
> 
> 	3315 (OPTION_RELAY_MSG)
> 	4580 (Relay Agent Subscriber-ID)
> 	5007 (Various LQ related Options, including OPTION_LQ_RELAY_DATA)

Or even 3315 (INTERFACE ID). It seems to suit here.

-- 
Romain Boissat
chroot-me.in
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110506/3704a6b6/attachment.bin>

From ben at bjencks.net  Fri May  6 16:14:39 2011
From: ben at bjencks.net (Ben Jencks)
Date: Fri, 6 May 2011 17:14:39 -0400
Subject: IPv6 implementation NANOG list
In-Reply-To: <20110506205920.GA21677@gnaea.lv0.in>
References: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com>
	<D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>
	<C076ABAF-6B34-4BE1-85FD-B48910FAE449@delong.com>
	<20110506205920.GA21677@gnaea.lv0.in>
Message-ID: <BANLkTinhfRLykbWn5oMCUoxei5fYmYsX7A@mail.gmail.com>

On Fri, May 6, 2011 at 16:59, Romain Boissat <r.boissat at gmail.com> wrote:
> On Fri, May 06, 2011 at 01:53:51PM -0700, Owen DeLong wrote:
>> I'm honestly not sure, but, check RFCs:
>>
>> ? ? ? 3315 (OPTION_RELAY_MSG)
>> ? ? ? 4580 (Relay Agent Subscriber-ID)
>> ? ? ? 5007 (Various LQ related Options, including OPTION_LQ_RELAY_DATA)
>
> Or even 3315 (INTERFACE ID). It seems to suit here.

This Cisco whitepaper makes it look like it's Remote-ID (See section
Useful DHCPv6 deployment features and options):

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_C11-472610.html

-Ben



From cidr-report at potaroo.net  Fri May  6 17:00:01 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 6 May 2011 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201105062200.p46M01FP085638@wattle.apnic.net>

BGP Update Report
Interval: 28-Apr-11 -to- 05-May-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            39333  2.9%      56.6 -- BSNL-NIB National Internet Backbone
 2 - AS19743           31657  2.3%    4522.4 -- 
 3 - AS17974           28594  2.1%      17.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 4 - AS14434           22442  1.6%    1870.2 -- 
 5 - AS32528           17741  1.3%    4435.2 -- ABBOTT Abbot Labs
 6 - AS35819           16835  1.2%      62.6 -- MOBILY-AS Etihad Etisalat Company (Mobily)
 7 - AS21826           16506  1.2%      54.7 -- Internet Cable Plus C. A.
 8 - AS27738           14198  1.0%      42.0 -- Ecuadortelecom S.A.
 9 - AS35931           13892  1.0%    4630.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
10 - AS33475           13725  1.0%      77.5 -- RSN-1 - RockSolid Network, Inc.
11 - AS6458            12607  0.9%      44.5 -- Telgua
12 - AS14420           12564  0.9%      19.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
13 - AS11992           12441  0.9%      27.3 -- CENTENNIAL-PR - Centennial de Puerto Rico
14 - AS1660            11635  0.8%     147.3 -- ANS-CORP-NY - ANS Communications
15 - AS11492           11545  0.8%      24.1 -- CABLEONE - CABLE ONE, INC.
16 - AS9498            10604  0.8%      25.2 -- BBIL-AP BHARTI Airtel Ltd.
17 - AS24560           10290  0.8%      10.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
18 - AS24534           10040  0.7%    2510.0 -- TRANSHYBRID-AS-ID PT. Transhybrid Communication
19 - AS15475            9993  0.7%      22.9 -- NOL
20 - AS24757            9813  0.7%     223.0 -- EthioNet-AS


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS35931           13892  1.0%    4630.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 2 - AS19743           31657  2.3%    4522.4 -- 
 3 - AS32528           17741  1.3%    4435.2 -- ABBOTT Abbot Labs
 4 - AS18704            4334  0.3%    4334.0 -- T-SYSTEMS-NA - T-Systems North America, Inc.
 5 - AS17408            3550  0.3%    3550.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 6 - AS44609            9297  0.7%    3099.0 -- FNA Fars News Agency Cultural Arts Institute
 7 - AS24534           10040  0.7%    2510.0 -- TRANSHYBRID-AS-ID PT. Transhybrid Communication
 8 - AS14434           22442  1.6%    1870.2 -- 
 9 - AS49600            1488  0.1%    1488.0 -- LASEDA La Seda de Barcelona, S.A
10 - AS50324             938  0.1%     938.0 -- ORCO-GSG GSG Asset GmbH & Co. Verwaltungs KG
11 - AS27771            1731  0.1%     865.5 -- Instituto Venezolano de Investigaciones Cientificas
12 - AS48731             791  0.1%     791.0 -- VSAU-AS Federal State Educational Institution of Higher Professional Education Voronezh State Agricultural University of K.D.Glinka
13 - AS3454             6308  0.5%     788.5 -- Universidad Autonoma de Nuevo Leon
14 - AS11915            3715  0.3%     743.0 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
15 - AS27667            1190  0.1%     595.0 -- Universidad Autonoma de la Laguna
16 - AS49508             480  0.0%     480.0 -- NEOS1-AS KS-Telecom ltd
17 - AS13610             480  0.0%     480.0 -- PROVOCRAFT-NOVELTY - Provo Craft & Novelty, Inc.
18 - AS10445            2351  0.2%     470.2 -- HTG - Huntleigh Telcom
19 - AS3                 447  0.0%     735.0 -- GIGABIT-NET LLC Gigabit
20 - AS3                 433  0.0%    1083.0 -- GIGABIT-NET LLC Gigabit


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.92.235.0/24    9609  0.7%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 2 - 130.36.35.0/24     8872  0.6%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.34.0/24     8867  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 63.211.68.0/22     7597  0.5%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 5 - 65.122.196.0/24    6272  0.4%   AS19743 -- 
 6 - 198.140.43.0/24    6232  0.4%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 7 - 200.23.202.0/24    6148  0.4%   AS3454  -- Universidad Autonoma de Nuevo Leon
 8 - 66.248.160.0/22    5650  0.4%   AS14434 -- 
 9 - 66.248.170.0/23    5650  0.4%   AS14434 -- 
10 - 221.121.96.0/19    5594  0.4%   AS7491  -- PI-PH-AS-AP PI-PHILIPINES
11 - 66.248.172.0/23    5566  0.4%   AS14434 -- 
12 - 66.248.168.0/24    5560  0.4%   AS14434 -- 
13 - 66.238.91.0/24     5077  0.3%   AS19743 -- 
14 - 66.89.98.0/24      5077  0.3%   AS19743 -- 
15 - 72.164.144.0/24    5077  0.3%   AS19743 -- 
16 - 65.162.204.0/24    5076  0.3%   AS19743 -- 
17 - 65.163.182.0/24    5076  0.3%   AS19743 -- 
18 - 178.22.72.0/21     4689  0.3%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
19 - 178.22.79.0/24     4601  0.3%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
20 - 64.43.0.0/16       4334  0.3%   AS18704 -- T-SYSTEMS-NA - T-Systems North America, Inc.

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From cidr-report at potaroo.net  Fri May  6 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 6 May 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201105062200.p46M00N4085633@wattle.apnic.net>

This report has been generated at Fri May  6 21:12:10 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        29-04-11    359398      210528
        30-04-11    359141      210245
        01-05-11    359150      210332
        02-05-11    359477      210568
        03-05-11    359727      210958
        04-05-11    359799      211320
        05-05-11    360266      210489
        06-05-11    359540      210997


AS Summary
         37602  Number of ASes in routing system
         15851  Number of ASes announcing only one prefix
          3647  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      110377472  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 06May11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     360041   210977   149064    41.4%   All ASes

AS6389      3647      260     3387    92.9%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4323      2574      403     2171    84.3%   TWTC - tw telecom holdings,
                                               inc.
AS4766      2451      927     1524    62.2%   KIXS-AS-KR Korea Telecom
AS6478      1667      207     1460    87.6%   ATT-INTERNET3 - AT&T Services,
                                               Inc.
AS22773     1329       96     1233    92.8%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS19262     1496      298     1198    80.1%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS18566     1782      659     1123    63.0%   COVAD - Covad Communications
                                               Co.
AS10620     1458      348     1110    76.1%   Telmex Colombia S.A.
AS4755      1461      377     1084    74.2%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1204      128     1076    89.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS1785      1788      763     1025    57.3%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS28573     1298      416      882    68.0%   NET Servicos de Comunicao S.A.
AS18101      935      145      790    84.5%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS7545      1567      788      779    49.7%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS24560     1151      415      736    63.9%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1368      636      732    53.5%   Uninet S.A. de C.V.
AS4808      1040      333      707    68.0%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS3356      1116      452      664    59.5%   LEVEL3 Level 3 Communications
AS7303       927      273      654    70.6%   Telecom Argentina S.A.
AS17488      938      308      630    67.2%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS11492     1262      638      624    49.4%   CABLEONE - CABLE ONE, INC.
AS17676      660       70      590    89.4%   GIGAINFRA Softbank BB Corp.
AS855        634       56      578    91.2%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS14420      665       99      566    85.1%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS3549       948      399      549    57.9%   GBLX Global Crossing Ltd.
AS4780       745      196      549    73.7%   SEEDNET Digital United Inc.
AS22047      557       30      527    94.6%   VTR BANDA ANCHA S.A.
AS22561      863      341      522    60.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS6503       802      297      505    63.0%   Axtel, S.A.B. de C.V.
AS17974     1813     1311      502    27.7%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia

Total      40146    11669    28477    70.9%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        24.48.0.0/14         AS5769  VIDEOTRON - Videotron Telecom Ltee
        24.225.128.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/23      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.224.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.237.0/24      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.248.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        31.210.248.0/21      AS35706 NAO Net at Once Sweden AB
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        45.127.0.0/16        AS13767 DBANK - DataBank Holdings, Ltd.
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS16626 GNAXNET-AS - Global Net Access, LLC
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        69.6.81.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.22.32.0/19        AS33150 
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        80.88.12.0/24        AS33779 wataniya-telecom-as
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        115.42.28.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.40.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.42.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.44.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.47.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.48.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.49.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.50.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.51.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.52.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.53.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.54.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.55.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.56.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.57.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.58.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.59.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.61.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.62.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.63.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        158.222.70.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.72.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.224.0/20     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.224.0/22     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.229.0/24     AS19864 O1COMM - O1 COMMUNICATIONS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc
        192.64.85.0/24       AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.69.108.0/24      AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.101.46.0/24      AS6503  Axtel, S.A.B. de C.V.
        192.101.64.0/21      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.72.0/24      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.124.252.0/22     AS680   DFN-IP service G-WiN
        192.131.233.0/24     AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        192.145.251.0/24     AS10026 PACNET Pacnet Global Ltd
        192.154.32.0/19      AS81    NCREN - MCNC
        192.154.64.0/19      AS81    NCREN - MCNC
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        196.2.224.0/22       AS24863 LINKdotNET-AS
        196.6.108.0/24       AS5713  SAIX-NET
        196.13.201.0/24      AS2018  TENET-1
        196.13.202.0/24      AS2018  TENET-1
        196.13.203.0/24      AS2018  TENET-1
        196.13.204.0/24      AS2018  TENET-1
        196.110.105.0/24     AS8513  SKYVISION SkyVision Network Services
        196.202.224.0/21     AS8818  TELE Greenland Autonomous System
        198.1.2.0/24         AS4761  INDOSAT-INP-AP INDOSAT Internet Network Provider
        198.15.4.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.15.5.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.
        198.73.210.0/24      AS21570 ACI-1 - Accelerated Connections Inc.
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.99.241.0/24      AS11797 AC-NIELSEN-AS AC NIELSEN
        198.161.87.0/24      AS6539  GT-BELL - Bell Canada
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited
        198.167.0.0/16       AS7456  INTERHOP - Interhop Network SERVICES Inc.
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        198.175.231.0/24     AS19262 VZGNI-TRANSIT - Verizon Online LLC
        198.180.198.0/24     AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services
        198.182.235.0/24     AS3356  LEVEL3 Level 3 Communications
        199.16.32.0/19       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        199.33.84.0/22       AS9911  CONNECTPLUS-AP Singapore Telecom
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.185.130.0/23     AS19662 UNISERVE-ONLINE - Uniserve On Line
        199.202.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        199.202.216.0/21     AS577   BACOM - Bell Canada
        199.246.116.0/24     AS813   UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.133.73.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.146.186.0/24     AS23655 SNAP-NZ-AS Snap Internet Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.160.158.0/23     AS2764  AAPT AAPT Limited
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        203.18.156.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        203.190.32.0/22      AS24564 
        204.9.216.0/23       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        204.10.232.0/21      AS33150 
        204.19.14.0/23       AS577   BACOM - Bell Canada
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.189.134.0/24     AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.188.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.189.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.190.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.191.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.78.165.0/24      AS16565 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.92.196.0/22      AS10929 NETELLIGENT - Netelligent Hosting Services Inc.
        208.92.199.0/24      AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc.
        209.54.123.0/24      AS6062  NETPLEX - NETPLEX
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.165.239.0/24     AS209   ASN-QWEST - Qwest Communications Company, LLC
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.5.128.0/20       AS4837  CHINA169-BACKBONE CNCGROUP China169 Backbone
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.10.235.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.10.236.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.21.196.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.201.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.202.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.206.0/23      AS12251 INVISION - Invision.com, Inc.
        216.58.192.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.197.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.105.192.0/23     AS7385  INTEGRATELECOM - Integra Telecom, Inc.
        216.105.196.0/23     AS7385  INTEGRATELECOM - Integra Telecom, Inc.
        216.105.200.0/21     AS7385  INTEGRATELECOM - Integra Telecom, Inc.
        216.172.198.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.172.199.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From frnkblk at iname.com  Fri May  6 17:22:27 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 6 May 2011 17:22:27 -0500
Subject: IPv6 implementation NANOG list
In-Reply-To: <D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>
References: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com>
	<D3EA30AD-A454-4480-921F-D97CB548D8CB@menards.ca>
Message-ID: <00c101cc0c3c$14acecf0$3e06c6d0$@iname.com>

Perhaps LDRA (Lightweight DHCP relay agent)?

Frank

-----Original Message-----
From: Francois Menard [mailto:francois at menards.ca] 
Sent: Friday, May 06, 2011 3:41 PM
To: Jay Ashworth
Cc: NANOG
Subject: IPv6 implementation NANOG list

Folks,

I am looking at rolling out IPv6 in the access.

My platform does DHCP Option 82 for geolocating customer MACs to certain
ports of multi-port layer 2 demarcation devices.

What is the IPv6 version of that ?

F.




From randy at psg.com  Sat May  7 00:33:36 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 07 May 2011 07:33:36 +0200
Subject: Suspecious anycast prefixes
In-Reply-To: <3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>
References: <BANLkTim9xzaThOSk5t=tigzi8EKZr_0GqQ@mail.gmail.com>
	<ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<3EFFFC7D-08A3-42B3-8CD9-C06C935CB0D2@pch.net>
	<3C9D1E48-D9A2-44D4-B783-D4F4C26A9CD1@tcb.net>
Message-ID: <m2liyj6pn3.wl%randy@psg.com>

>>> It's perhaps worth noting that there is work in the IETF to
>>> recommend that every prefix originated as part of an anycast cloud
>>> uses a unique origin AS (see
>>> <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm
>>> not personally convinced of the arguments in the draft, but
>>> mentioning it in this thread seems reasonable.
>> I'm also not convinced of the arguments in the draft, since it argues
>> that it would be a best-practice
> 'A', not 'the', for the reasons conveyed in the draft (e.g., control 
> plane discriminator, RPKI foundations, etc..).

danny,

could you explain why this has anything to do with the rpki and origin
validation?

randy



From leigh.porter at ukbroadband.com  Sat May  7 02:50:22 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sat, 7 May 2011 08:50:22 +0100
Subject: open source DPI suggestions?
In-Reply-To: <C083B1E0-E72F-4AE6-9FE3-D72788B61433@menards.ca>
References: <BANLkTikgdZUrOLLa+E3L-WT5o7czrheUWA@mail.gmail.com>
	<9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org>
	<09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net>
	<BANLkTimjGkASY8AVx88qXji9XjRwwu_o6Q@mail.gmail.com>
	<C083B1E0-E72F-4AE6-9FE3-D72788B61433@menards.ca>
Message-ID: <FCD4A834-EADB-46E6-89B9-E486FE8FD767@ukbroadband.com>

I gotta say that those microtik boxed are pretty impressive. I have quite a few that give me Layer 2 VPN in the lab and they have been faultless so far.


-- 
Leigh Porter


On 6 May 2011, at 21:46, "Francois Menard" <francois at menards.ca> wrote:

> 
> How about RouterOS from Mikrotik ?
> 
> You cannot beat a $70 RB750G for doing P2P hijacking.
> 
> F.
> 
> On 2011-04-29, at 8:59 AM, Kornelijus Survila wrote:
> 
>> Snort (http://www.snort.org/) is also a nice IDS. They provide paid and free
>> rules/signatures.
>> 
>> -k
>> 
>> On Fri, Apr 29, 2011 at 7:55 AM, Raymond Burkholder <ray at oneunified.net>wrote:
>> 
>>>>> Can anyone suggest any open source DPI (deep packet inspection)
>>>> projects?
>>>> 
>>>> 
>>>> I'll recommend Bro-IDS (http://www.bro-ids.org/) as it's what I spend my
>>>> days working on.  It's essentially a programming language for long term
>>>> network traffic monitoring which is focused on doing deep decoding of
>>>> application layer protocols.  (and it's BSD licensed!)
>>>> 
>>> 
>>> http://l7-filter.sourceforge.net/ might be another candidate.
>>> 
>>> 
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>> 
>>> 
>>> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From tom at ninjabadger.net  Sat May  7 06:37:30 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Sat, 07 May 2011 12:37:30 +0100
Subject: open source DPI suggestions?
In-Reply-To: <BANLkTimjGkASY8AVx88qXji9XjRwwu_o6Q@mail.gmail.com>
References: <BANLkTikgdZUrOLLa+E3L-WT5o7czrheUWA@mail.gmail.com>
	<9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org>
	<09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net>
	<BANLkTimjGkASY8AVx88qXji9XjRwwu_o6Q@mail.gmail.com>
Message-ID: <1304768250.2110.0.camel@teh-desktop>

On Fri, 2011-04-29 at 07:59 -0500, Kornelijus Survila wrote:
> Snort (http://www.snort.org/) is also a nice IDS. They provide paid
> and free rules/signatures.

And if you would like 64bit and/or IPv6 support, try Suricata:

http://www.openinfosecfoundation.org/


Tom




From askoorb+nanog at gmail.com  Sat May  7 06:59:06 2011
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Sat, 7 May 2011 12:59:06 +0100
Subject: open source DPI suggestions?
In-Reply-To: <1304768250.2110.0.camel@teh-desktop>
References: <BANLkTikgdZUrOLLa+E3L-WT5o7czrheUWA@mail.gmail.com>
	<9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org>
	<09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net>
	<BANLkTimjGkASY8AVx88qXji9XjRwwu_o6Q@mail.gmail.com>
	<1304768250.2110.0.camel@teh-desktop>
Message-ID: <BANLkTim17y0S9x6u+FE_URFLfOstWpux5w@mail.gmail.com>

On Sat, May 7, 2011 at 12:37 PM, Tom Hill <tom at ninjabadger.net> wrote:
> On Fri, 2011-04-29 at 07:59 -0500, Kornelijus Survila wrote:
>> Snort (http://www.snort.org/) is also a nice IDS. They provide paid
>> and free rules/signatures.
>
> And if you would like 64bit and/or IPv6 support, try Suricata:
>
> http://www.openinfosecfoundation.org/
>

Another good open-source one with IPv6, Sourcefire rules support,
stateful firewall and filtering at traffic and web address level etc
is Vyatta (http://www.vyatta.org and http://www.vyatta.com).  They're
also rather nice routers if I do say so myself.

Do let us know which one you end up picking and how you go with it.

Cheers

Alex



From support at comgw.co.uk  Sat May  7 08:49:12 2011
From: support at comgw.co.uk (Support)
Date: Sat, 07 May 2011 14:49:12 +0100
Subject: Current recommendations for 2 x full bgp feed
Message-ID: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>

Can anyone give me their recommendation for current hardware to take 2 x 
full BGP feeds over 1Gb/s ports with a third Gb port for the local network?

I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM 
but I'm guessing things have moved on???

Thanks,
Chris







From rmaunier at neotelecoms.com  Sat May  7 08:52:42 2011
From: rmaunier at neotelecoms.com (Raphael MAUNIER)
Date: Sat, 7 May 2011 13:52:42 +0000
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
Message-ID: <0632CA7B-6A4C-44FA-A0BE-4FFC9D8240D4@neotelecoms.com>

A simple M7i can handle this.

But this will depend on the type of trafic ( pps, filtering or not, ... )

regards,
-- 
Rapha?l Maunier
NEO TELECOMS
CTO / Responsable Ing?nierie
AS8218

On May 7, 2011, at 3:49 PM, Support wrote:

> Can anyone give me their recommendation for current hardware to take 2 x 
> full BGP feeds over 1Gb/s ports with a third Gb port for the local network?
> 
> I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM 
> but I'm guessing things have moved on???
> 
> Thanks,
> Chris
> 
> 
> 
> 
> 




From rcarpen at network1.net  Sat May  7 09:34:08 2011
From: rcarpen at network1.net (Randy Carpenter)
Date: Sat, 07 May 2011 10:34:08 -0400 (EDT)
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
Message-ID: <ec51b9fb-5381-4966-9400-784423c30f07@zimbra.network1.net>

I do it currently with Cisco 2821 routers with 1 GB of RAM, so it doesn't take all that much for just the BGP. It all depends on the throughput. I have sites that have 7200VXR routers with NPE-G2 and 2GB of RAM that handle 2x 1 Gig feeds, albeit not fully loaded.

For new hardware, I would look at the Juniper M or MX series (depending on your needs) or, if you are wanting Cisco, the ASR series is what to look for. The Juniper routers are going to be less expensive per performance.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----

----- Original Message -----
> Can anyone give me their recommendation for current hardware to take
> 2 x
> full BGP feeds over 1Gb/s ports with a third Gb port for the local
> network?
> 
> I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM
> but I'm guessing things have moved on???
> 
> Thanks,
> Chris
> 
> 
> 
> 
> 
> 
> 



From bblackford at gmail.com  Sat May  7 09:46:34 2011
From: bblackford at gmail.com (Bill Blackford)
Date: Sat, 7 May 2011 07:46:34 -0700
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <ec51b9fb-5381-4966-9400-784423c30f07@zimbra.network1.net>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
	<ec51b9fb-5381-4966-9400-784423c30f07@zimbra.network1.net>
Message-ID: <BANLkTi=2Yeo2P6RP9iOhcaiP9sADzTj6jQ@mail.gmail.com>

>> 2 x
>> full BGP feeds over 1Gb/s ports with a third Gb port for the local
>> network?

> For new hardware, I would look at the Juniper M or MX series (depending on your needs) or, if you are wanting Cisco, the ASR series is what to look for. The Juniper routers are going to be less expensive per performance.

I use both ASR and MX80 in my environment. If your needs are only a
few ge interfaces then I would recommended the ASR1002. If you need a
few more interfaces, look the the new MX80-5G bundle or the standard
MX80 with a 20 port MIC. Adding capacity to the ASR gets exponential
especially going up to 10G.

-b


-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.....



From jlewis at lewis.org  Sat May  7 10:02:54 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Sat, 7 May 2011 11:02:54 -0400 (EDT)
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
Message-ID: <Pine.LNX.4.61.1105071054350.4318@soloth.lewis.org>

On Sat, 7 May 2011, Support wrote:

> Can anyone give me their recommendation for current hardware to take 2 x
> full BGP feeds over 1Gb/s ports with a third Gb port for the local network?
>
> I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM
> but I'm guessing things have moved on???

The NPE300 won't handle full routes anymore or the volume of traffic 
you're likely to want to move with multiple gig ports.

You mentioned 3 1gb ports, but not how much traffic you expect to be 
moving (or what sorts of features you need).  A 7200VXR with NPEG1 or G2 
might do.  A 6506 with Sup720-3bxl (or better) and a 6408A or 6516-GE-TX 
(depending on your cabling needs) would easily do it.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From support at comgw.co.uk  Sat May  7 11:57:05 2011
From: support at comgw.co.uk (Support)
Date: Sat, 07 May 2011 17:57:05 +0100
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <Pine.LNX.4.61.1105071054350.4318@soloth.lewis.org>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>,
	<Pine.LNX.4.61.1105071054350.4318@soloth.lewis.org>
Message-ID: <4DC579E1.1247.4AE7C80@support.comgw.co.uk>

On 7 May 2011 at 11:02, Jon Lewis wrote:

> On Sat, 7 May 2011, Support wrote:
> 
> > Can anyone give me their recommendation for current hardware to take 2 x
> > full BGP feeds over 1Gb/s ports with a third Gb port for the local network?
> >
> > I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM
> > but I'm guessing things have moved on???
> 
> The NPE300 won't handle full routes anymore or the volume of traffic 
> you're likely to want to move with multiple gig ports.
> 
> You mentioned 3 1gb ports, but not how much traffic you expect to be 
> moving (or what sorts of features you need).  A 7200VXR with NPEG1 or G2 
> might do.  A 6506 with Sup720-3bxl (or better) and a 6408A or 6516-GE-TX 
> (depending on your cabling needs) would easily do it.

We've guestimated around 150Mb/s total transit to start, probably moving 
up to 300Mb/s as a maximum, so nothing too drastic. Minimum is 3 x 1Gb/s 
ports, but will probably want to expand that later and add another two gig 
ports.

Feature wise, BGP (and later iBGP with OSPF) is the most important as it's 
a border router. The ability to put access lists in to block unwanted traffic, 
IPv6 capability and trunked VLANs are all desireable.

Thanks to all who have responded so far.

Chris




From gbonser at seven.com  Sat May  7 13:14:51 2011
From: gbonser at seven.com (George Bonser)
Date: Sat, 7 May 2011 11:14:51 -0700
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3151@RWC-EX1.corp.seven.com>

> 
> Can anyone give me their recommendation for current hardware to take 2
> x
> full BGP feeds over 1Gb/s ports with a third Gb port for the local
> network?
> 
> I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM
> but I'm guessing things have moved on???
> 
> Thanks,
> Chris

Things are about to get very different very quickly.  Assuming by full
BGP feed you mean both IPv4 and IPv6, you are soon going to need
something that takes >500,000 routes.  There are two reasons for this.
First as the larger blocks of v4 space become unavailable due to runout,
allocations of space will likely come as crumbs of smaller space.  For
example if someone requests a /16 they might get an equal amount of
space in a bundle of smaller blocks that are not contiguous and can't be
aggregated.  This is going to lead to an explosion of routes in the v4
table.

At the same time the number of v6 allocations is growing.  An IPv6 route
will require the resources of anywhere from two to four times the router
resources of an IPv4 route depending on vendor and configuration (some
will, by default, use out to 64-bits for routes but can be configured to
use the entire 128-bits).

I currently have 5642 IPv6 routes and 349979 IPv4 "best" routes
installed on one of my border routers.  Any router in a default-free
environment that will require dual-stacking will be required to support
the equivalent of 500,000 ipv4 routes soon. The >500,000 route
capability is a significant price point for many vendors.  How you
respond to this will depend on what kind of network you are (do you
provide transit services or are you an end network that uses multiple
transit providers for reliability?).





From streiner at cluebyfour.org  Sat May  7 16:51:35 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sat, 7 May 2011 17:51:35 -0400 (EDT)
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3151@RWC-EX1.corp.seven.com>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
	<5A6D953473350C4B9995546AFE9939EE0C9E3151@RWC-EX1.corp.seven.com>
Message-ID: <Pine.LNX.4.64.1105071749210.17312@whammy.cluebyfour.org>

On Sat, 7 May 2011, George Bonser wrote:

> Things are about to get very different very quickly.  Assuming by full
> BGP feed you mean both IPv4 and IPv6, you are soon going to need
> something that takes >500,000 routes.  There are two reasons for this.
> First as the larger blocks of v4 space become unavailable due to runout,
> allocations of space will likely come as crumbs of smaller space.  For
> example if someone requests a /16 they might get an equal amount of
> space in a bundle of smaller blocks that are not contiguous and can't be
> aggregated.  This is going to lead to an explosion of routes in the v4
> table.

This is already starting to happen.  Starting in February, shortly after 
the last of the free IPv4 /8s were allocated, my historical graphs of the 
v4 and v6 routes we receive shows a slight, but noticeable uptick in 
growth rate.




From wavetossed at googlemail.com  Sun May  8 00:56:49 2011
From: wavetossed at googlemail.com (Michael Dillon)
Date: Sat, 7 May 2011 22:56:49 -0700
Subject: Rwhois not serving all records - it is almost working though.
In-Reply-To: <201105041653.19177.lesmith@ecsis.net>
References: <AANLkTinVRCQ4kcOCDE1jQDiE-V6Ays8TzTqUYUrLh15w@mail.gmail.com>
	<AANLkTim1ELk8P2jAcmA+gsUkuCwk0oqM-UywgJcypszt@mail.gmail.com>
	<BANLkTi=jrZFtUoVi6hHVpxyXfsGiXMCgoQ@mail.gmail.com>
	<201105041653.19177.lesmith@ecsis.net>
Message-ID: <BANLkTikfHc3vcbtJ4fHfB660rAZFq070_g@mail.gmail.com>

>> I sent this information to the rwhoisd mailing list originally but I've
>> been informed that the mailing list is mostly dead now.

This is normal.

rwhoisd is very old software that has had no development attention for
many, many years.
Years ago I gave up trying to figure out why it would not serve all
the records in the database because ARIN was quite happy to take
database dumps of the data in other formats when applying for
additional blocks.

These days it is probably smarter to put your effort into putting all
your data into ARIN's whois directory database and use the new RESTful
interface to do it. https://www.arin.net/knowledge/roadmap.html

As long as you are only submitting adds, changes and deletes, this
should work fine.



From wavetossed at googlemail.com  Sun May  8 01:10:15 2011
From: wavetossed at googlemail.com (Michael Dillon)
Date: Sat, 7 May 2011 23:10:15 -0700
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <AF1A5103-1060-4BBE-B180-F3079A57714B@jsyoung.net>
References: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<4DC18474.2080902@ispalliance.net>
	<AF1A5103-1060-4BBE-B180-F3079A57714B@jsyoung.net>
Message-ID: <BANLkTin2sOq7P2MBq9M2onq=hm4Pubp=tg@mail.gmail.com>

> Many years ago I was the MCI side of the Real Broadcast Network. ?Real Networks arranged to broadcast a
> Rolling Stones concert. ?We had the ability to multicast on the Mbone and unicast from Real Networks caches.
> We figured that we'd get a hit rate of 70% multicast (those who wanted to see the event as it happened) and
> 30% unicast (those who would wait and watch it later).

You do realize that unicast from Real Networks caches *IS* multicast,
just not IP Multicast. Akamai runs a very large and successful multicast
network which shows that there is great demand for multicast services,
just not the low level kind provided by IP Multicast.

In fact, the most important use for IP Multicast is to work around the
problem of the "best route". In the financial industry, they don't want
their traffic to take the best route, because that creates a chain
of single points of failure. So instead, they build two multicast trees,
send a copy of each packet into each tree, and arrange that the
paths which the trees use are entirely separate. That means
separacy of circuits and routers and switches.

-- Michael Dillon



From young at jsyoung.net  Sun May  8 03:09:51 2011
From: young at jsyoung.net (Jeffrey S. Young)
Date: Sun, 8 May 2011 18:09:51 +1000
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTin2sOq7P2MBq9M2onq=hm4Pubp=tg@mail.gmail.com>
References: <3fcb6598-053a-4f62-9eec-6ad8ece7d55c@jennyfur.pelican.org>
	<4DC18474.2080902@ispalliance.net>
	<AF1A5103-1060-4BBE-B180-F3079A57714B@jsyoung.net>
	<BANLkTin2sOq7P2MBq9M2onq=hm4Pubp=tg@mail.gmail.com>
Message-ID: <38177CF7-6EF4-4A74-9901-1FC608B33582@jsyoung.net>


On 08/05/2011, at 4:10 PM, Michael Dillon <wavetossed at googlemail.com> wrote:

>> Many years ago I was the MCI side of the Real Broadcast Network.  Real Networks arranged to broadcast a
>> Rolling Stones concert.  We had the ability to multicast on the Mbone and unicast from Real Networks caches.
>> We figured that we'd get a hit rate of 70% multicast (those who wanted to see the event as it happened) and
>> 30% unicast (those who would wait and watch it later).
> 
> You do realize that unicast from Real Networks caches *IS* multicast,
> just not IP Multicast. Akamai runs a very large and successful multicast
> network which shows that there is great demand for multicast services,
> just not the low level kind provided by IP Multicast.
> 
> In fact, the most important use for IP Multicast is to work around the
> problem of the "best route". In the financial industry, they don't want
> their traffic to take the best route, because that creates a chain
> of single points of failure. So instead, they build two multicast trees,
> send a copy of each packet into each tree, and arrange that the
> paths which the trees use are entirely separate. That means
> separacy of circuits and routers and switches.
> 
> -- Michael Dillon
> 

In 1997, Real Networks caches were sending unicast.  If they now operate
differently I'm not aware (Real dumped the relationship in the DSL heyday
to chase eyeballs -- iMCI was a backbone).  

But you've got one over on me, I've never heard of Akamai's "multicast"
and given that they don't run a backbone to my knowledge it sounds as if
they're using their server installs to route packets or have an interesting 
way of source routing or tunneling multiple streams of the same data 
through ISP networks.  

As for the financial industry I was only aware of some of the reliable mcast
software in use to push ticker information to trading desks.

All very interesting but the point was that the world of entertainment video
consumption has long since become on-demand; many of the points being 
made for the use of IP multicast as a pseudo-broadcast mechanism have 
been made before (and will be made again).  I personally think P2P is a much
more interesting topic for (legally) distributing video these days and P4P
may even solve the inter provider problem that multicast never seemed to
crack.

jy


From jra at baylink.com  Sun May  8 10:48:01 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 8 May 2011 11:48:01 -0400 (EDT)
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTin2sOq7P2MBq9M2onq=hm4Pubp=tg@mail.gmail.com>
Message-ID: <31567254.737.1304869681576.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Michael Dillon" <wavetossed at googlemail.com>

> You do realize that unicast from Real Networks caches *IS* multicast,
> just not IP Multicast. Akamai runs a very large and successful multicast
> network which shows that there is great demand for multicast services,
> just not the low level kind provided by IP Multicast.

We're gonna have to agree to disagree on the definition of "multicast" then,
I guess, Mike.  Cause my definition is "only one stream of it passes through
each interface of a given router", and I expect that doesn't fit the 
situation you're talking about.

Cheers,
-- jra



From brent at servuhome.net  Sun May  8 17:41:24 2011
From: brent at servuhome.net (Brent Jones)
Date: Sun, 8 May 2011 15:41:24 -0700
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
Message-ID: <BANLkTinx5JdP+qsjfMZ=KpnJ1Z7xXibgbA@mail.gmail.com>

On Sat, May 7, 2011 at 6:49 AM, Support <support at comgw.co.uk> wrote:
> Can anyone give me their recommendation for current hardware to take 2 x
> full BGP feeds over 1Gb/s ports with a third Gb port for the local network?
>
> I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM
> but I'm guessing things have moved on???
>
> Thanks,
> Chris
>

You could look at rolling your own box, if you budget/needs are small.
Quagga/Zebra running on Linux, or a more professional/supported side
you could go with Vyatta.

I personally have a handful of Vyatta boxes in two sites, taking
several full BGP feeds and works well.

Juniper is also making small enterprise routers based on the MX80
platform, but with reduced number of interfaces. They should be out
soon


-- 
Brent Jones
brent at servuhome.net



From bross at pobox.com  Sun May  8 18:45:16 2011
From: bross at pobox.com (Brandon Ross)
Date: Sun, 8 May 2011 19:45:16 -0400 (EDT)
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <BANLkTinx5JdP+qsjfMZ=KpnJ1Z7xXibgbA@mail.gmail.com>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
	<BANLkTinx5JdP+qsjfMZ=KpnJ1Z7xXibgbA@mail.gmail.com>
Message-ID: <Pine.OSX.4.64.1105081938240.320@cevin-2.local>

On Sun, 8 May 2011, Brent Jones wrote:

> Juniper is also making small enterprise routers based on the MX80
> platform, but with reduced number of interfaces. They should be out
> soon

They are effectively already out in that they have a deep discount on 
"restricted" bundles.  Basically the bundles license only some or none of 
the 10GbE ports or only 1 of the MIC slots (there's like 3 or 4 of them). 
The price is pretty darn good considering what you get.

-- 
Brandon Ross                                              AIM:  BrandonNRoss
                                                                ICQ:  2269442
                                    Skype:  brandonross  Yahoo:  BrandonNRoss



From george.herbert at gmail.com  Sun May  8 21:06:21 2011
From: george.herbert at gmail.com (George Herbert)
Date: Sun, 8 May 2011 19:06:21 -0700
Subject: Current recommendations for 2 x full bgp feed
In-Reply-To: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
References: <4DC54DD8.4094.4027BB1@support.comgw.co.uk>
Message-ID: <BANLkTinyMtZrkS1wyp_5wyF8e9mEXh=dZw@mail.gmail.com>

On Sat, May 7, 2011 at 6:49 AM, Support <support at comgw.co.uk> wrote:
> Can anyone give me their recommendation for current hardware to take 2 x
> full BGP feeds over 1Gb/s ports with a third Gb port for the local network?
>
> I did this about 6/7 years ago with a Cisco 7200VXR NPE300 256MB RAM
> but I'm guessing things have moved on???

Question -

How sure are you that the number of incoming BGP feeds is and will
permanently remain 2 and only two?

I.e., do you need, or conceive of needing, a moderate expansion margin
for the hardware selected?


-- 
-george william herbert
george.herbert at gmail.com



From fmartin at linkedin.com  Mon May  9 01:54:31 2011
From: fmartin at linkedin.com (Franck Martin)
Date: Mon, 9 May 2011 06:54:31 +0000
Subject: Yahoo and IPv6
Message-ID: <C9EDE811.A0C8%fmartin@linkedin.com>

http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
"Will IPv6 become a permanent change on June 8, 2011?
No. World IPv6 day is a 24-hour trial period in which we will publish our content on both the IPv4 and IPv6 servers. Yahoo! is participating in order to help prepare our services (as well as your hardware) to help ensure a smooth transition for when the IPv4 addresses run out. "

Huh? I thought IPv4 addresses had run out already?.

At IANA level and now for anyone in the AP region at least.


From tvhawaii at shaka.com  Mon May  9 03:19:11 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 8 May 2011 22:19:11 -1000
Subject: Yahoo and IPv6
References: <C9EDE811.A0C8%fmartin@linkedin.com>
Message-ID: <4971A562CCBE4745ABB36A408632E3F4@DELL16>

Franck Martin wrote:
> http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
> "Will IPv6 become a permanent change on June 8, 2011?
> No. World IPv6 day is a 24-hour trial period in which we will publish our content on both the IPv4 and IPv6 servers. 
> Yahoo! is
> participating in order to help prepare our services (as well as your hardware) to help ensure a smooth transition for 
> when the
> IPv4 addresses run out. "
>
> Huh? I thought IPv4 addresses had run out already?.
>
> At IANA level and now for anyone in the AP region at least.

http://www.apnic.net/policy/add-manage-policy#9.10 




From trejrco at gmail.com  Mon May  9 07:06:49 2011
From: trejrco at gmail.com (TJ)
Date: Mon, 9 May 2011 08:06:49 -0400
Subject: Yahoo and IPv6
In-Reply-To: <4971A562CCBE4745ABB36A408632E3F4@DELL16>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
	<4971A562CCBE4745ABB36A408632E3F4@DELL16>
Message-ID: <BANLkTinUnrcerjjOQMMsTAFsBdY765_5rQ@mail.gmail.com>

Unfortunately, I suspect many organizations will be following that approach.


I hope that some will instead see this as a great opportunity for the last
step in making their public services IPv6 reachable *... and that they also
start/continue/complete taking IPv6 within their internal networks as well.*


/TJ


On Mon, May 9, 2011 at 04:19, Michael Painter <tvhawaii at shaka.com> wrote:

> Franck Martin wrote:
>
>> http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
>> "Will IPv6 become a permanent change on June 8, 2011?
>> No. World IPv6 day is a 24-hour trial period in which we will publish our
>> content on both the IPv4 and IPv6 servers. Yahoo! is
>> participating in order to help prepare our services (as well as your
>> hardware) to help ensure a smooth transition for when the
>> IPv4 addresses run out. "
>>
>> Huh? I thought IPv4 addresses had run out already?.
>>
>> At IANA level and now for anyone in the AP region at least.
>>
>
> http://www.apnic.net/policy/add-manage-policy#9.10
>
>


From joey.liuyq at gmail.com  Mon May  9 09:05:36 2011
From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu)
Date: Mon, 9 May 2011 09:05:36 -0500
Subject: Suspecious anycast prefixes
In-Reply-To: <20110505182433.GD1798@vacation.karoshi.com.>
References: <ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
	<20110503042053.GA3478@vacation.karoshi.com.>
	<BANLkTinms81A-oQckWC_ym8F-YXfzOVtNA@mail.gmail.com>
	<28745737-E7D7-408A-9051-0BEB340FD8B0@hopcount.ca>
	<BANLkTi=yMJU8+tCTtydsoqgvLd96PPFo3g@mail.gmail.com>
	<BANLkTi=zciJaqx8izkCTa8WnWDkdw7MOPg@mail.gmail.com>
	<20110505084654.GA5266@vacation.karoshi.com.>
	<31E0CDD1-AC16-4E5A-843E-C670F9148E84@hopcount.ca>
	<BANLkTik-7WLe56LZtYDfHB55+DhZCwG5EQ@mail.gmail.com>
	<20110505182433.GD1798@vacation.karoshi.com.>
Message-ID: <BANLkTika=CG=0H_c6+spoCE-2X02c_AoYQ@mail.gmail.com>

On Thu, May 5, 2011 at 1:24 PM,  <bmanning at vacation.karoshi.com> wrote:
> On Thu, May 05, 2011 at 09:36:50AM -0500, Yaoqing(Joey) Liu wrote:
>> On Thu, May 5, 2011 at 3:54 AM, Joe Abley <jabley at hopcount.ca> wrote:
>> >
>> > On 2011-05-05, at 11:46, bmanning at vacation.karoshi.com wrote:
>> >
>> >> On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
>> >>> 198.32.64.0/24
>> >>> AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC.
>> >>> AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK
>> >>> AS20144:ASName: L-ROOT;Comment:distributed using Anycast.
>> >>> AS42909: as-name: ? ? ? ? COMMUNITYDNS;descr: ? ? ? ? ? Internet
>> >>> Computer Bureau Ltd
>> >>
>> >> ? ? ? according to Filip, this is -NOT- supposed to be
>> >> ? ? ? anycast. ?the only legal origin ASN is 4555.
>> >>
>> >> ? ? ? these other ASNs have hijacked the prefix.
>> >
>> > The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
>>
>> This is based on last four year's data(2007-2010)collected from more
>> than 120 peers around the world. Today it may be not announced
>> anymore, but it used to be announced by the four ASNs simultaneously.
>> I just checked the detailed info about this prefix, here it is about
>> the prefix:
>> 198.32.64.0/24
>> (ASN: average peers announcing this prefix:existing period:total
>> appearing days: MOAS period: total appearing days)
>> 4555:4.94:20080318-20080506:50:20080318-20080506:50
>> 9584:3.07:20080402-20080513:42:20080402-20080513:42
>> 20144:79.44:20070101-20080501:487:20071215-20080501:138
>> 42909:26.39:20071215-20080515:152:20071215-20080513:150
>> >
>> MY source data
>> > Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
>> >
>> This needs to do further analysis to confirm if it was hijacked
>>
>> Yaoqing
>> >
>> > Joe
>
>
> ? ? ? ?in that period, it was originated by these parties, most of whom were authorized to
> ? ? ? ?announce it. ?at this time, only one ASN is authorized to announce, and its not.
>
> ? ? ? ?not sure how you expect to determine, with simple routing data, if the prefix was
> ? ? ? ?hijacked. ?you would need to see the letters of authorization or contracts of service/carriage
> ? ? ? ?to determine if an ASN was impropperly announcing.
>
> ? ? ? ?for that matter, why do you care what occured years ago? ?the Internet is an evolving, fluid media
> ? ? ? ?and things change all the time. ?if you want particulars on this prefix, i should have the
> ? ? ? ?authoritative data, since I was the registered contact for both the prefix and the ASN in that
> ? ? ? ?period and can pull the records. ?Contact me offline for details on access.

I might not explain the background clearly and confused people. We're
doing research on multiple origin AS issue, and we want to confirm if
our inference is correct based on history data we collected. For
example, we found several hundreds of prefixes with multiple origins
more than two, some of them were inferred as anycast using our
methodology, but we're not positive with the conjecture, so we want to
find the ground truth from operators. Thanks for the detailed
explanations.

Thanks,
Yaoqing
>
> /bill
>



From joelja at bogus.com  Mon May  9 10:01:47 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 09 May 2011 08:01:47 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTinUnrcerjjOQMMsTAFsBdY765_5rQ@mail.gmail.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>	<4971A562CCBE4745ABB36A408632E3F4@DELL16>
	<BANLkTinUnrcerjjOQMMsTAFsBdY765_5rQ@mail.gmail.com>
Message-ID: <4DC801DB.5080007@bogus.com>

On 5/9/11 5:06 AM, TJ wrote:
> Unfortunately, I suspect many organizations will be following that approach.
>
> I hope that some will instead see this as a great opportunity for the last
> step in making their public services IPv6 reachable *... and that they also
> start/continue/complete taking IPv6 within their internal networks as well.*

my ipv6 peering with yahoo came up like 8 months ago...

I don't think there's anything particularly unfortunate about what major
content providers are doing with ipv6, give them customers and they wil
support them.

joel

> 
> /TJ
> 
> 
> On Mon, May 9, 2011 at 04:19, Michael Painter <tvhawaii at shaka.com> wrote:
> 
>> Franck Martin wrote:
>>
>>> http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
>>> "Will IPv6 become a permanent change on June 8, 2011?
>>> No. World IPv6 day is a 24-hour trial period in which we will publish our
>>> content on both the IPv4 and IPv6 servers. Yahoo! is
>>> participating in order to help prepare our services (as well as your
>>> hardware) to help ensure a smooth transition for when the
>>> IPv4 addresses run out. "
>>>
>>> Huh? I thought IPv4 addresses had run out already?.
>>>
>>> At IANA level and now for anyone in the AP region at least.
>>>
>>
>> http://www.apnic.net/policy/add-manage-policy#9.10
>>
>>
> 




From trejrco at gmail.com  Mon May  9 10:09:17 2011
From: trejrco at gmail.com (TJ)
Date: Mon, 9 May 2011 11:09:17 -0400
Subject: Yahoo and IPv6
In-Reply-To: <4DC801DB.5080007@bogus.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
	<4971A562CCBE4745ABB36A408632E3F4@DELL16>
	<BANLkTinUnrcerjjOQMMsTAFsBdY765_5rQ@mail.gmail.com>
	<4DC801DB.5080007@bogus.com>
Message-ID: <BANLkTik_xwvjt5j8VsmZ41TkgQ3RLWOxRw@mail.gmail.com>

On Mon, May 9, 2011 at 11:01, Joel Jaeggli <joelja at bogus.com> wrote:

> On 5/9/11 5:06 AM, TJ wrote:
> > Unfortunately, I suspect many organizations will be following that
> approach.
> >
> > I hope that some will instead see this as a great opportunity for the
> last
> > step in making their public services IPv6 reachable *... and that they
> also
> > start/continue/complete taking IPv6 within their internal networks as
> well.*
>
> my ipv6 peering with yahoo came up like 8 months ago...
>

Sure, but peering is not the same as publicly/universally reachable
services.  I hope that World IPv6 Day raises enough awareness, and yields
enough success stories, that we make some noticeable progress in the near
future.



> I don't think there's anything particularly unfortunate about what major
> content providers are doing with ipv6, give them customers and they wil
> support them.
>

It is unfortunate (to me), because content providers being accessible is an
important step in breaking this chicken-egg scenario.
We need the service providers and content providers to make this "IPv6
thing" usable/relevant - and (just IMHO) the sooner the better.


/TJ


From ariev at vayner.net  Mon May  9 10:16:20 2011
From: ariev at vayner.net (Arie Vayner)
Date: Mon, 9 May 2011 18:16:20 +0300
Subject: Yahoo and IPv6
In-Reply-To: <C9EDE811.A0C8%fmartin@linkedin.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>
	<C9EDE811.A0C8%fmartin@linkedin.com>
Message-ID: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>

Actually, I have just noticed a slightly more disturbing thing on the Yahoo
IPv6 help page...

I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
(the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
it says:
"We detected an issue with your IPv6 configuration. On World IPv6 Day, you
will have issues reaching Yahoo!, as well as your other favorite web sites.
We recommend disabling
IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>,
or seeking assistance in order to fix your system's IPv6 configuration
through your ISP or computer manufacturer."

What disturbs me is the piece saying "We recommend disabling
IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
", with a very easy link...

Arie


On Mon, May 9, 2011 at 9:54 AM, Franck Martin <fmartin at linkedin.com> wrote:

> http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
> "Will IPv6 become a permanent change on June 8, 2011?
> No. World IPv6 day is a 24-hour trial period in which we will publish our
> content on both the IPv4 and IPv6 servers. Yahoo! is participating in order
> to help prepare our services (as well as your hardware) to help ensure a
> smooth transition for when the IPv4 addresses run out. "
>
> Huh? I thought IPv4 addresses had run out already?.
>
> At IANA level and now for anyone in the AP region at least.
>


From cb.list6 at gmail.com  Mon May  9 11:04:45 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 9 May 2011 09:04:45 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <BANLkTinJb7tpAtPK2OvHeAjJVwYH5FoBOQ@mail.gmail.com>

On Mon, May 9, 2011 at 8:16 AM, Arie Vayner <ariev at vayner.net> wrote:
> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> IPv6 help page...
>
> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
> it says:
> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
> will have issues reaching Yahoo!, as well as your other favorite web sites.
> We recommend disabling
> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>,
> or seeking assistance in order to fix your system's IPv6 configuration
> through your ISP or computer manufacturer."
>
> What disturbs me is the piece saying "We recommend disabling
> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
> ", with a very easy link...
>

No IPv6 is better than broken* IPv6.

*broken being defined as: you go to www.yahoo.com with your broken
IPv6 connection (6to4?) and www.yahoo.com fails to load within your
margin of acceptable latency, then you go to a competitor's web site.

The point of IPv6 day is that we "shake out" the issues together as
one community.  If it works great, that is great and we can make solid
decisions based on real world data on how to fix and move forward.

As an operator of a soon to be production launched IPv6-only + NAT64
service, nobody is more eager for native IPv6 content than me.  That
said, this is the right path for the content guys to dip their toes
in.

=================================
T-Mobile USA IPv6 Beta http://bit.ly/9s0Ed3
=================================



From bross at pobox.com  Mon May  9 11:25:09 2011
From: bross at pobox.com (Brandon Ross)
Date: Mon, 9 May 2011 12:25:09 -0400 (EDT)
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <Pine.OSX.4.64.1105091221180.320@cevin.lv.enet.interop.net>

On Mon, 9 May 2011, Arie Vayner wrote:

> What disturbs me is the piece saying "We recommend disabling
> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
> ", with a very easy link...

Even more disturbing than that is that when I run a test from here it says 
that I have broken v6.  But I don't have broken v6 and test-v6.com proves 
it with a 10/10.  This Yahoo tool doesn't seem to even give a hint as to 
what it thinks is broken.

Can anyone from Yahoo shed some light on what this tool is doing and how 
to get it to tell us what it thinks is broken?

-- 
Brandon Ross                                              AIM:  BrandonNRoss
                                                                ICQ:  2269442
                                    Skype:  brandonross  Yahoo:  BrandonNRoss



From Valdis.Kletnieks at vt.edu  Mon May  9 11:25:55 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 09 May 2011 12:25:55 -0400
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Mon, 09 May 2011 18:16:20 +0300."
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <11723.1304958355@localhost>

On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> IPv6 help page...
> 
> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
> it says:
> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
> will have issues reaching Yahoo!, as well as your other favorite web sites.

The *really* depressing part is that it says the same thing for me, on a *known*
working IPv6 network.

And then when I retry it a few minutes later, with a tcpdump running, it works.

And then another try says it failed, though tcpdump shows it seems to work.

For what it's worth, the attempted download  file is:

% wget http://v6test.yahoo.com/eng/test/eye-test.png
--2011-05-09 11:44:39--  http://v6test.yahoo.com/eng/test/eye-test.png
Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [image/png]
Saving to: `eye-test.png.1'

    [ <=>                                   ] 2,086       --.-K/s   in 0s      

2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]

Looking at the Javascript that drives the test, it appears the *real* problem
is that they set a 3 second timeout on the download - which basically means
that if you have to retransmit either the DNS query or the TCP SYN, you're
dead as far as the test is concerned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110509/5fb13263/attachment.bin>

From oberman at es.net  Mon May  9 11:34:12 2011
From: oberman at es.net (Kevin Oberman)
Date: Mon, 09 May 2011 09:34:12 -0700
Subject: Yahoo and IPv6 
In-Reply-To: Your message of "Mon, 09 May 2011 12:25:55 EDT."
	<11723.1304958355@localhost> 
Message-ID: <20110509163412.A4F4A1CC09@ptavv.es.net>

> From: Valdis.Kletnieks at vt.edu
> Date: Mon, 09 May 2011 12:25:55 -0400
> 
> On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
> > Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> > IPv6 help page...
> > 
> > I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
> > (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
> > run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
> > it says:
> > "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
> > will have issues reaching Yahoo!, as well as your other favorite web sites.
> 
> The *really* depressing part is that it says the same thing for me, on a *known*
> working IPv6 network.
> 
> And then when I retry it a few minutes later, with a tcpdump running, it works.
> 
> And then another try says it failed, though tcpdump shows it seems to work.
> 
> For what it's worth, the attempted download  file is:
> 
> % wget http://v6test.yahoo.com/eng/test/eye-test.png
> --2011-05-09 11:44:39--  http://v6test.yahoo.com/eng/test/eye-test.png
> Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
> Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [image/png]
> Saving to: `eye-test.png.1'
> 
>     [ <=>                                   ] 2,086       --.-K/s   in 0s      
> 
> 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]
> 
> Looking at the Javascript that drives the test, it appears the *real* problem
> is that they set a 3 second timeout on the download - which basically means
> that if you have to retransmit either the DNS query or the TCP SYN, you're
> dead as far as the test is concerned.

I have talked to Yahoo engineers about this and they say that their
testing has shown that, if it takes more than 3 seconds for a site to
load, they start to lose significant traffic. Hence the 3 second
timeout.

Sadly, I'm afraid that they have a point, but at the same time I suspect
that they are assuring failure for almost everyone. A 5 second timeout
would probably be more reasonable, but is probably unacceptable to Yahoo
management.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From khelms at ispalliance.net  Mon May  9 11:38:43 2011
From: khelms at ispalliance.net (Scott Helms)
Date: Mon, 09 May 2011 12:38:43 -0400
Subject: Yahoo and IPv6
In-Reply-To: <11723.1304958355@localhost>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>	<C9EDE811.A0C8%fmartin@linkedin.com>	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
Message-ID: <4DC81893.3010009@ispalliance.net>

I believe the problem Yahoo is talking about in regards to "broken" IPv6 
networks.  It really comes down to your network would break for 0.078% 
of the people trying to reach their site via IPv6.  Broken in this case 
means;

...."the user has a broken home gateway, or a broken firewall or his Web 
browser has a timeout that's between 21 and 186 seconds, which we 
consider to be broken. That's a lot of breakage, and that is a very big 
barrier for content providers to support IPv6."

http://www.pcworld.idg.com.au/article/341178/yahoo_proposes_really_ugly_hack_dns/



On 5/9/2011 12:25 PM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
>> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
>> IPv6 help page...
>>
>> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
>> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
>> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
>> it says:
>> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
>> will have issues reaching Yahoo!, as well as your other favorite web sites.
> The *really* depressing part is that it says the same thing for me, on a *known*
> working IPv6 network.
>
> And then when I retry it a few minutes later, with a tcpdump running, it works.
>
> And then another try says it failed, though tcpdump shows it seems to work.
>
> For what it's worth, the attempted download  file is:
>
> % wget http://v6test.yahoo.com/eng/test/eye-test.png
> --2011-05-09 11:44:39--  http://v6test.yahoo.com/eng/test/eye-test.png
> Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
> Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [image/png]
> Saving to: `eye-test.png.1'
>
>      [<=>                                    ] 2,086       --.-K/s   in 0s
>
> 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]
>
> Looking at the Javascript that drives the test, it appears the *real* problem
> is that they set a 3 second timeout on the download - which basically means
> that if you have to retransmit either the DNS query or the TCP SYN, you're
> dead as far as the test is concerned.


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------



From jfesler at gigo.com  Mon May  9 12:03:26 2011
From: jfesler at gigo.com (Jason Fesler)
Date: Mon, 9 May 2011 10:03:26 -0700 (PDT)
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1105091001180.19724@goat.gigo.com>

> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> IPv6 help page...

Not speaking in any official capacity, but .. thanks.

The location that's affecting the results is pending removal from DNS;
and ASAP we hope to have the name moved to the geo-LB that suppors v6,
instead of the round robin it is today.




From sethm at rollernet.us  Mon May  9 12:12:41 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 09 May 2011 10:12:41 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <4DC82089.4090208@rollernet.us>

On 5/9/2011 08:16, Arie Vayner wrote:
> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> IPv6 help page...
> 
> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
> it says:
> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
> will have issues reaching Yahoo!, as well as your other favorite web sites.
> We recommend disabling
> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>,
> or seeking assistance in order to fix your system's IPv6 configuration
> through your ISP or computer manufacturer."
> 


It says the same thing for me; however it is most certainly wrong. All
my IPv6 connectivity is native - no tunnels.

~Seth



From jared at puck.nether.net  Mon May  9 12:27:21 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 9 May 2011 13:27:21 -0400
Subject: Yahoo and IPv6 
In-Reply-To: <20110509163412.A4F4A1CC09@ptavv.es.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
Message-ID: <4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>


On May 9, 2011, at 12:34 PM, Kevin Oberman wrote:

> I have talked to Yahoo engineers about this and they say that their
> testing has shown that, if it takes more than 3 seconds for a site to
> load, they start to lose significant traffic. Hence the 3 second
> timeout.
> 
> Sadly, I'm afraid that they have a point, but at the same time I suspect
> that they are assuring failure for almost everyone. A 5 second timeout
> would probably be more reasonable, but is probably unacceptable to Yahoo
> management.

I have done some other 'observational' looks at some IPv6 related data recently that others may have seen on ipv6-ops.

A few notes:

1) Somewhere 0.5-0.8% of sites in a list of domains (about 1 million 'top' sites) have some form of broken DNS

2) Some DNS providers (eg: OpenDNS, Google, Comcast, and those that run ISC-BIND) have varying responses with these queries.  The one I find most interesting is OpenDNS, they seem to never take more than 1 second for a dns query.  Seems to stick within this 3-5 second overall load rule.  I've not detailed what nameservers have different operations, but BIND is certainly most likely to return a SERVFAIL while others return NOERROR.  It appears BIND is just more strict about enforcing strict cname -> cname mapping with proper SOA.  You can see this all over bind-users.

There seems to be some other interesting data that could be inferred regarding the sites.

I do want to present this data and some details regarding IPv6 day and our observations at the upcoming NANOG meeting, but not sure I'm going to have it all together.  If you are on the PC, expect a lightning talk from me :)

I do feel the bar that Yahoo is setting is too high.  There are a lot of network elements that are broken, either DNS servers, home 'gateway/nat' devices, or other elements in the delegation chain.  This leaves out any of the network elements of the packet forwarding path that may be suboptimal.  While not directly comparable as one is the CPE side vs Content side, if 0.6% of sites are unreachable from a BIND resolver on a properly IPv6 enabled network, the number of sites that will appear broken will be high in aggregate.  These folks need to fix their problems, 6714 of the 1 million sites are broken.  If you are talking about 6714 people that are going to place a helpdesk call that day, I hope everyone is ready to work their phones.  I think this is the point of Yahoo, but if nobody fixes it, it will just be permanently broken.  If that's the case, it should be addressed vs papered over by not serving up for the remainder of the 99.4% that are properly maintained.

While 2 9's is not that great, aiming for 5 9's is a goal, not something I feel is realistic in the next 24 months.

- Jared


From goemon at anime.net  Mon May  9 12:54:59 2011
From: goemon at anime.net (goemon at anime.net)
Date: Mon, 9 May 2011 10:54:59 -0700 (PDT)
Subject: aster.pl unwise abuse policy
Message-ID: <Pine.LNX.4.64.1105091053540.10524@sasami.anime.net>

Anyone with contacts at aster.pl advise them of their unwise policies?

Thanks.

-Dan

From: Abuse ASTER <abuse at aster.pl>

=======================================================
This email was send automatically !
Do not reply to this email.
-------------------------------------------------------

Dear Sir or Madam,
We kindly inform you that reports of violations of the Rules and Regulations
of detailed benefits of internet access by ASTER Sp. z o.o based in Warsaw
made by ASTER subscribers can only be sent by the help of the form available
on the website: http://abuse.aster.pl.

Reports sent via E-Mail will not be processed.

Sincerely,
Departament of Customer Service ASTER
http://www.aster.pl/ebok/
tel: 0-801-014-014 lub 022 4-014-014



From jra at baylink.com  Mon May  9 13:58:57 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 9 May 2011 14:58:57 -0400 (EDT)
Subject: Cent OS migration
In-Reply-To: <4DC8306E.3090108@steelerubber.com>
Message-ID: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Walter Vaughan" <wvaughan at steelerubber.com>

> You most definately will want to make sure your user id's are
> identical between the two systems, otherwise stuff like @CB will have wrong information.

Excellent point.

> Also, do you have any expertise maintaing a linux box? If you want
> something closer
> to SCO in mentality, FreeBSD and SCO have the same grandparents. Linux
> is like
> the cute girl that moved into town. Stuff isn't always where you
> expect
> to find it,
> and you may get a surprise if you reach into the wrong place.

Oh, don't *even* send him to BSD.

CentOS and SuSE 11 are the only rational free Linuces for business use.

*Any* of the BSDs are so much less well supported that they'll drive you
straight up a wall.

Cheers,
-- jra



From dougb at dougbarton.us  Mon May  9 14:11:07 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 09 May 2011 12:11:07 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
Message-ID: <4DC83C4B.5080703@dougbarton.us>

On 05/09/2011 10:27, Jared Mauch wrote:
> I do feel the bar that Yahoo is setting is too high.  There are a lot of network elements that are broken, either DNS servers, home 'gateway/nat' devices, or other elements in the delegation chain.

Publicly held corporations are responsible to their shareholders to get 
eyeballs on their content. *That* is their job, not promoting cool new 
network tech. When you have millions of users hitting your site every 
day losing 1/2000 is a large chunk of revenue. The fact that the big 
players are doing world IPv6 day at all should be celebrated, promoted, 
and we should all be ready to take to heart the lessons learned from it.

The content providers are not to be blamed for the giant mess that IPv6 
deployment has become. If 6to4 and Teredo had never happened, in all 
likelihood we wouldn't be in this situation today.


-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/




From alh-ietf at tndh.net  Mon May  9 14:40:50 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Mon, 9 May 2011 12:40:50 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DC83C4B.5080703@dougbarton.us>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
Message-ID: <120501cc0e81$0222b1e0$066815a0$@net>

> -----Original Message-----
> From: Doug Barton [mailto:dougb at dougbarton.us]
> Sent: Monday, May 09, 2011 12:11 PM
> To: Jared Mauch
> Cc: nanog at nanog.org; Arie Vayner
> Subject: Re: Yahoo and IPv6
> 
> On 05/09/2011 10:27, Jared Mauch wrote:
> > I do feel the bar that Yahoo is setting is too high.  There are a lot
> of network elements that are broken, either DNS servers, home
> 'gateway/nat' devices, or other elements in the delegation chain.
> 
> Publicly held corporations are responsible to their shareholders to get
> eyeballs on their content. *That* is their job, not promoting cool new
> network tech. When you have millions of users hitting your site every
> day losing 1/2000 is a large chunk of revenue. The fact that the big
> players are doing world IPv6 day at all should be celebrated, promoted,
> and we should all be ready to take to heart the lessons learned from
> it.
> 
> The content providers are not to be blamed for the giant mess that IPv6
> deployment has become. If 6to4 and Teredo had never happened, in all
> likelihood we wouldn't be in this situation today.

Which situation ??? The one where the content can demonstrate how broken the
networks really are? Or the one where the content sites are exposed for
their lack of prior planning? 

The entire point of those technologies you are complaining about was to
break the stalemate between content and network, because both sides will
always wait and blame the other. The fact that the content side chose to
wait until the last possible minute to start is where the approach falls
down. Expecting magic to cover for lack of proactive effort 5-10 years ago
is asking a bit much, even for the content mafia. 

In any case, the content side can mitigate all of the latency related issues
they complain about in 6to4 by putting in a local 6to4 router and publishing
the corresponding 2002:: prefix based address in DNS for their content. They
choose to hold their breath and turn blue, blaming the network for the lack
of 5-9's access to the eyeballs when they hold at least part of a solution
in their own hands.

We are about the witness the most expensive, complex, blame-fest of a
transition that one could have imagined 10 years ago. This is simply due to
the lack of up-front effort that both sides have demonstrated in getting to
this point. Now that time has expired, all that is left to do is sit back
and watch the fireworks.

Tony

> 
> 
> --
> 
> 	Nothin' ever doesn't change, but nothin' changes much.
> 			-- OK Go
> 
> 	Breadth of IT experience, and depth of knowledge in the DNS.
> 	Yours for the right price.  :)  http://SupersetSolutions.com/





From jra at baylink.com  Mon May  9 14:41:47 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 9 May 2011 15:41:47 -0400 (EDT)
Subject: Cent OS migration
In-Reply-To: <C9EDBA97.17B04%branto@networking-architecture.com>
Message-ID: <21253760.797.1304970107909.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Brant I. Stevens" <branto at networking-architecture.com>

> >CentOS and SuSE 11 are the only rational free Linuces for business
> >use.
> 
> Don't forget Scientific Linux as well. Same heritage as CentOS.

"Scientific Linux?  What's that?"  :-)

And while there's probably nothing wrong with the OS or its pedigree, 
that (semi-amusing) question is pertinent, I think, for someone in his
position: he doesn't know much Linux, and is willing to do some of his
own legwork on the support front, in exchange for not having to pay a 
fairly sizable yearly support charge.

In that situation, the more public resources there are on which you can 
draw, the better off you are.

For you and I, something like SL (which I do remember seeing go by on LWN
a few months ago) would be a good bet.  I'm not sure that's true for 
someone like our OP here.

Cheers,
-- jr 'deja vu all over again' a



From ljakab at ac.upc.edu  Mon May  9 14:54:16 2011
From: ljakab at ac.upc.edu (Lori Jakab)
Date: Mon, 09 May 2011 21:54:16 +0200
Subject: Cent OS migration
In-Reply-To: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
References: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
Message-ID: <4DC84668.3040607@ac.upc.edu>

On 05/09/2011 08:58 PM, Jay Ashworth wrote:
> CentOS and SuSE 11 are the only rational free Linuces for business use.

With the uncertainty surrounding the future of CentOS, it's not
something I would recommend for business use at the moment. See the
following article for a collection of links why that's the case:

http://evilrouters.net/2011/04/11/its-time-to-move-on-from-centos/

Regards,
Lori Jakab



From joelja at bogus.com  Mon May  9 14:57:33 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 09 May 2011 12:57:33 -0700
Subject: Cent OS migration
In-Reply-To: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
References: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
Message-ID: <4DC8472D.3070100@bogus.com>

On 5/9/11 11:58 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Walter Vaughan" <wvaughan at steelerubber.com>
> 
>> You most definately will want to make sure your user id's are
>> identical between the two systems, otherwise stuff like @CB will have wrong information.
> 
> Excellent point.
> 
>> Also, do you have any expertise maintaing a linux box? If you want
>> something closer
>> to SCO in mentality, FreeBSD and SCO have the same grandparents.

if you mean they forked  from a common tree around 1976, sure but beyond
that the similarities are superficial.

http://www.levenez.com/unix/unix.pdf

> Linux
>> is like
>> the cute girl that moved into town. Stuff isn't always where you
>> expect
>> to find it,
>> and you may get a surprise if you reach into the wrong place.

If one's introduction to operating systems was less than 35 years ago
maybe not, the analogy posed is completely mysterious me.

> Oh, don't *even* send him to BSD.
> 
> CentOS and SuSE 11 are the only rational free Linuces for business use.

that's an opinion, certainly there are a diversity of opinions to the
contrary with sufficient scale to disprove that handily.

> *Any* of the BSDs are so much less well supported that they'll drive you
> straight up a wall.

Start with, "what is the most appropriate tool for the problem I am
trying to solve"

> Cheers,
> -- jra
> 




From dougb at dougbarton.us  Mon May  9 14:58:39 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 09 May 2011 12:58:39 -0700
Subject: Yahoo and IPv6
In-Reply-To: <120501cc0e81$0222b1e0$066815a0$@net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
Message-ID: <4DC8476F.2070905@dougbarton.us>

On 05/09/2011 12:40, Tony Hain wrote:
>> -----Original Message-----
>> From: Doug Barton [mailto:dougb at dougbarton.us]
>> Sent: Monday, May 09, 2011 12:11 PM
>> To: Jared Mauch
>> Cc: nanog at nanog.org; Arie Vayner
>> Subject: Re: Yahoo and IPv6
>>
>> On 05/09/2011 10:27, Jared Mauch wrote:
>>> I do feel the bar that Yahoo is setting is too high.  There are a lot
>> of network elements that are broken, either DNS servers, home
>> 'gateway/nat' devices, or other elements in the delegation chain.
>>
>> Publicly held corporations are responsible to their shareholders to get
>> eyeballs on their content. *That* is their job, not promoting cool new
>> network tech. When you have millions of users hitting your site every
>> day losing 1/2000 is a large chunk of revenue. The fact that the big
>> players are doing world IPv6 day at all should be celebrated, promoted,
>> and we should all be ready to take to heart the lessons learned from
>> it.
>>
>> The content providers are not to be blamed for the giant mess that IPv6
>> deployment has become. If 6to4 and Teredo had never happened, in all
>> likelihood we wouldn't be in this situation today.
>
> Which situation ??? The one where the content can demonstrate how broken the
> networks really are? Or the one where the content sites are exposed for
> their lack of prior planning?

I disagree with your attempt to scope the problem. :)

> The entire point of those technologies you are complaining about was to
> break the stalemate between content and network,

I also disagree with this statement, but there is very little point in 
arguing about it at this stage.

> because both sides will
> always wait and blame the other. The fact that the content side chose to
> wait until the last possible minute to start is where the approach falls
> down. Expecting magic to cover for lack of proactive effort 5-10 years ago
> is asking a bit much, even for the content mafia.

One could also argue that the fact that the IPv6 protocol is still not 
fully mature, and that the IPv6 intelligentsia are only recently coming 
to the point where they are willing to give both the content and eyeball 
networks what they've been asking for all along (PI and robust DHCPv6 
being top of the respective lists) has led to the situation we're in 
now. Of course the truth is probably somewhere in the middle, but it's 
definitely not all on one side.

> In any case, the content side can mitigate all of the latency related issues
> they complain about in 6to4 by putting in a local 6to4 router and publishing
> the corresponding 2002:: prefix based address in DNS for their content. They
> choose to hold their breath and turn blue, blaming the network for the lack
> of 5-9's access to the eyeballs when they hold at least part of a solution
> in their own hands.

Looking at that from the content provider side for a second, what is 
their motivation for doing it? The IETF created 6to4, and some foolish 
OS and/or hardware vendors enabled it by default. So you're saying that 
it's up to the content providers to spend money to fix a problem they 
didn't create, when the easy/free solution is simply not to turn on IPv6 
at all? I completely fail to see an incentive for the content providers 
to do this, but maybe I'm missing something.

And can we please stop pretending that this is an easy thing for the 
content providers to do? Big content networks like Yahoo! have dozens of 
POPs, and hundreds of address ranges. The IETF is *still* working on 
tweaking 6to4, so even if the content providers put up these relays 
today, and somehow figure out how to test them, their work is not done.

I do agree with you that pointing fingers at this stage is really not 
helpful. I continue to maintain that being supportive of those content 
networks that are willing to wade in is the right answer.


Doug (mafia? seriously?)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/




From michael.holstein at csuohio.edu  Mon May  9 15:07:23 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Mon, 09 May 2011 16:07:23 -0400
Subject: Cent OS migration
In-Reply-To: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
References: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
Message-ID: <4DC8497B.7030104@csuohio.edu>


> *Any* of the BSDs are so much less well supported that they'll drive you
> straight up a wall.
>   

If by "less supported" you mean that your local strip mall doesn't offer
a "BSD-certified-systems-engineer" class, then yeah .. but like anything
else, experience in the tricker stuff is going to come at a premium.

There are plenty of commercial support options (if that's your cup of
tea) for the various *BSD offerings.

IME, the BSD flavors (and versions of Linux like Slackware) are the
tools of choice by people who will support themselves. These are also
the people I trust when they come back and say "won't work, need to buy $x".

My $0.02.

Michael Holstein
Cleveland State University

PS: I'm not making a business judgment on going either route .. there's
a case to be made for "free, but takes 3 weeks to configure" versus
"costs WHAT? .. but you get 24x7 support". It's just that sometimes
nobody multiplies the 3wks * salary_of_person (and discovers that it
often is >= "WHAT?").



From jsw at inconcepts.biz  Mon May  9 15:26:47 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 9 May 2011 16:26:47 -0400
Subject: Yahoo and IPv6
In-Reply-To: <4DC8476F.2070905@dougbarton.us>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
Message-ID: <BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>

On Mon, May 9, 2011 at 3:58 PM, Doug Barton <dougb at dougbarton.us> wrote:
> I do agree with you that pointing fingers at this stage is really not
> helpful. I continue to maintain that being supportive of those content
> networks that are willing to wade in is the right answer.

Frankly, I think the finger is simply pointing in the wrong direction.
 I have zero choices for native IPv6 at home, and I'm sure that is
true for the majority of us.  SOHO CPE support barely exists because
access networks haven't been asking for it.  Call centers are
certainly not equipped to evaluate "traceroute tickets" or assist
users in any practical way, which is why we see "disable IPv6 and try
again" as the cookie-cutter answer to any problem when the end-user
has IPv6.

The expectation that content providers should rush to publish AAAA
records by default (instead of white-listing, etc.) at a time when
even motivated end-users can't get IPv6 without resorting to tunnels
is ridiculous.  Let's be glad that these content providers have done
all the necessary prep work, such as deploying appropriate network
infrastructure and updating their software, so that they can choose to
send AAAA responses when they want to.

This problem is, and always has been, on the access side.  Point your
fingers that way.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From jeroen at mompl.net  Mon May  9 15:31:15 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Mon, 09 May 2011 13:31:15 -0700
Subject: Cent OS migration
In-Reply-To: <4DC84668.3040607@ac.upc.edu>
References: <19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com>
	<4DC84668.3040607@ac.upc.edu>
Message-ID: <4DC84F13.5060407@mompl.net>

Lori Jakab wrote:
> following article for a collection of links why that's the case:
> 
> http://evilrouters.net/2011/04/11/its-time-to-move-on-from-centos/

That article perfectly illustrates why using or moving to debian makes a 
lot of sense.

Greetings,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From patrick at ianai.net  Mon May  9 15:40:03 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 9 May 2011 16:40:03 -0400
Subject: Finger pointing [was: Yahoo and IPv6]
In-Reply-To: <BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
Message-ID: <BFCE3674-8149-4073-93C3-CE3C3EB06989@ianai.net>

On May 9, 2011, at 4:26 PM, Jeff Wheeler wrote:
> On Mon, May 9, 2011 at 3:58 PM, Doug Barton <dougb at dougbarton.us> wrote:
>> I do agree with you that pointing fingers at this stage is really not
>> helpful. I continue to maintain that being supportive of those content
>> networks that are willing to wade in is the right answer.

[...]

> This problem is, and always has been, on the access side.  Point your
> fingers that way.

While I agree with Jeff, I agree with Doug more.  Unfortunately, finger-pointing will not fix the problem.  We have identified many of the problems, and hopefully June 8 will shine a very bright light on any that are left.  Let's work on fixing the problems, and let the historians figure out whose "fault" it was.

-- 
TTFN,
patrick

P.S. As an aside, and since the finger was pointed in my general direction, I'd just like to say chicken and egg problems always suck.  However, when the largest sites on the 'Net have enabled v6, yet are forced to whitelist or lose millions of dollars because the other end is broken, I don't see how any rational person can seriously call this the "content mafia's" fault.



On May 9, 2011, at 4:26 PM, Jeff Wheeler wrote:

> On Mon, May 9, 2011 at 3:58 PM, Doug Barton <dougb at dougbarton.us> wrote:
>> I do agree with you that pointing fingers at this stage is really not
>> helpful. I continue to maintain that being supportive of those content
>> networks that are willing to wade in is the right answer.
> 
> Frankly, I think the finger is simply pointing in the wrong direction.
> I have zero choices for native IPv6 at home, and I'm sure that is
> true for the majority of us.  SOHO CPE support barely exists because
> access networks haven't been asking for it.  Call centers are
> certainly not equipped to evaluate "traceroute tickets" or assist
> users in any practical way, which is why we see "disable IPv6 and try
> again" as the cookie-cutter answer to any problem when the end-user
> has IPv6.
> 
> The expectation that content providers should rush to publish AAAA
> records by default (instead of white-listing, etc.) at a time when
> even motivated end-users can't get IPv6 without resorting to tunnels
> is ridiculous.  Let's be glad that these content providers have done
> all the necessary prep work, such as deploying appropriate network
> infrastructure and updating their software, so that they can choose to
> send AAAA responses when they want to.
> 
> This problem is, and always has been, on the access side.  Point your
> fingers that way.
> 
> -- 
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts
> 




From jared at puck.nether.net  Mon May  9 15:41:50 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 9 May 2011 16:41:50 -0400
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
Message-ID: <A674A144-70BA-495B-BC4C-38886160495D@puck.nether.net>


On May 9, 2011, at 4:26 PM, Jeff Wheeler wrote:

> This problem is, and always has been, on the access side.  Point your
> fingers that way.

<aol>+1</aol>

I think we're in a stage where the access networks are playing catch-up.

The CPE marketplace is going to see some significant growth in sales in the short term as well.

I'll say that enabling IPv6 in the datacenter and the core is "easy".  Any modern hardware worth the cash you spend on it does native IPv6.  (If the hardware does not, eg: firewalls, etc, please re-read the prior statement).

Putting IPv6 in a datacenter or on a lan is easy.  You put a /64 there, let the host use SLAAC and let the RA magic work.  You talk to the nameserver over your dual-stack (IPv4) side and it's all set.

While there are concerns about people sending bogus RA's and other things, the same is true for anyone putting the router IP address on the main ethernet of a server too.  These all cause problems.

The routing protocols are all there, either with ISIS or OSPFv3.  BGP is there too.  You can even skip over non-IPv6 enabled nodes by doing 6PE if you have MPLS in your network.

I'm hopeful that nobody will see the problems out there on IPv6 day.  They've been dealt with in the 99%+ of the cases already.

The fact that we're talking about something past the decimal point is good IMHO.  I've observed that the top-million sites can't get it better than 99.4% right for a DNS query.  I can break that out by the top-10, 100, 1k, 10k, 100k and show a graph if that's useful.  I think it's "good enough".  I'd like to call out those with broken network elements and suggest they fix them.

I'd like to have native IPv6 at home, but my provider is not ready yet.  "Soon" is my hope.

The fact that it's there in many other places means it's possible.  I'd like to see more progress getting there than finger pointing.  I expect the next 30 days to be a lot of fun getting to IPv6 day, and it to be far less eventful than we worry it will be.

- Jared


From oberman at es.net  Mon May  9 15:45:36 2011
From: oberman at es.net (Kevin Oberman)
Date: Mon, 09 May 2011 13:45:36 -0700
Subject: Cent OS migration 
In-Reply-To: Your message of "Mon, 09 May 2011 14:58:57 EDT."
	<19066495.787.1304967537350.JavaMail.root@benjamin.baylink.com> 
Message-ID: <20110509204536.779081CC09@ptavv.es.net>

> Date: Mon, 9 May 2011 14:58:57 -0400 (EDT)
> From: Jay Ashworth <jra at baylink.com>
> 
> ----- Original Message -----
> > From: "Walter Vaughan" <wvaughan at steelerubber.com>
> 
> > You most definately will want to make sure your user id's are
> > identical between the two systems, otherwise stuff like @CB will have wrong information.
> 
> Excellent point.
> 
> > Also, do you have any expertise maintaing a linux box? If you want
> > something closer
> > to SCO in mentality, FreeBSD and SCO have the same grandparents. Linux
> > is like
> > the cute girl that moved into town. Stuff isn't always where you
> > expect
> > to find it,
> > and you may get a surprise if you reach into the wrong place.
> 
> Oh, don't *even* send him to BSD.
> 
> CentOS and SuSE 11 are the only rational free Linuces for business use.
> 
> *Any* of the BSDs are so much less well supported that they'll drive you
> straight up a wall.

Depends on what he is doing. BSDs tend to be far more mature than any
Linux. They are poor systems for desktops or anything like that. They
are heavily used as servers by many vary large providers and as the
basis for many products like Ironport (Cisco) and JunOS (Juniper). (I'll
admit that I run FreeBSD on my laptop with great success, but you have
to REALLY want it.)

That said, the BSD community is smaller and the addition of features and
the latest hardware support is slower on BSDs.

If you are very concerned with security, I'd never hesitate to recommend
OpenBSD. For more general use, FreeBSD. For an "unusual" platform,
NetBSD. For a walk on the wild side, try DragonFly and Hammer.

That said, I run both Linux and FreeBSD regularly and they both have
their place. You want the right tool for the job. 

The one Linux distro I don't recommend for experienced users is
Ubuntu. I don't like Windows because it presumes it know how I want to
do things better than I do and Ubuntu does the same. If my sister was
planing to play with Linux, I'd send her directly to Ubuntu, though.
(Tool...job. She does not get along well with computers.)
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From jra at baylink.com  Mon May  9 15:52:50 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 9 May 2011 16:52:50 -0400 (EDT)
Subject: Apologies, NANOG
Message-ID: <4639692.805.1304974370614.JavaMail.root@benjamin.baylink.com>

I appear to have somehow cross-posted a reply that was meant to go
to a different list entirely; no clue how I did that.

Now I understand the vehemence of the BSD-supporters.  :-)

Nothing to see here.  Move along.

Cheers,
-- jra



From lowen at pari.edu  Mon May  9 16:14:06 2011
From: lowen at pari.edu (Lamar Owen)
Date: Mon, 9 May 2011 17:14:06 -0400
Subject: Cent OS migration
In-Reply-To: <20110509204536.779081CC09@ptavv.es.net>
References: <20110509204536.779081CC09@ptavv.es.net>
Message-ID: <201105091714.06966.lowen@pari.edu>

On Monday, May 09, 2011 04:45:36 PM Kevin Oberman wrote:
> Depends on what he is doing. BSDs tend to be far more mature than any
> Linux. They are poor systems for desktops or anything like that. They
> are heavily used as servers by many vary large providers and as the
> basis for many products like Ironport (Cisco) and JunOS (Juniper). 

Cisco had an RHEL rebuild (internal) at one time, called, refreshingly enough, Cisco Enterprise Linux.  Cisco also uses/used a Linux base for their Content Engines and subsequent ACNS-running boxen.

The rather high-priced ADVA-sourced Cisco  Metro 1500 DWDM boxes used a 486 ISA single-board computer running off of DiskOnChip SSD for control and SNMP.

Having said that, I'd be just about as comfortable with a BSD as with a Linux.

And I do, and will continue to, run CentOS in production. 



From jra at baylink.com  Mon May  9 16:22:19 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 9 May 2011 17:22:19 -0400 (EDT)
Subject: Apologies, NANOG
In-Reply-To: <4639692.805.1304974370614.JavaMail.root@benjamin.baylink.com>
Message-ID: <33257988.807.1304976139430.JavaMail.root@benjamin.baylink.com>

> I appear to have somehow cross-posted a reply that was meant to go
> to a different list entirely; no clue how I did that.

Since people actually wanted to know, it was a reply to a "what might I
encounter when migrating from SCO Unix to CentOS thread", which (mirabile
visu) drifted somewhat in topic, on the mailing list for the filePro 4GL/
not-really-quite-a-DBMS (you may remember it as Profile, from the early
TRS-80 days.  Yes, it's still around, after 5 buyouts, the latest by its
employees, and yes, it's still recognizably the same package; there's a 
*scary* amount of legacy code written in it out there, largely due to
a Seattle company called Fourgen who wrote an entire accounting system in
it in the early 90s.  I know, cause I helped rewrite most of it.  Several
times.  :-)

It, in turn, spawned a C-language replacement menuing system called Menu
Master, which made up for a lot of shortcomings filePro eventually fixed on
its own... and we're *still* trying to find the source code for that, so we
can pay someone to recompile it for Linux.  iBCS never got ported to 2.6, and 
ABCI(?) never did work quite right with it.

Cheers,
-- jra



From jsw at inconcepts.biz  Mon May  9 16:48:34 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 9 May 2011 17:48:34 -0400
Subject: Finger pointing [was: Yahoo and IPv6]
In-Reply-To: <BFCE3674-8149-4073-93C3-CE3C3EB06989@ianai.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
	<BFCE3674-8149-4073-93C3-CE3C3EB06989@ianai.net>
Message-ID: <BANLkTimUv-s9yZ297rvBOZu9_=87i8Qajg@mail.gmail.com>

On Mon, May 9, 2011 at 4:40 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> Unfortunately, finger-pointing will not fix the problem.

Actually, finger-pointing is very helpful at this stage.  I was able
to change my local ISP's tune from "we have enough IPv4 addresses for
our customers, so we aren't going to support IPv6" (ever) to "we will
start employee beta testing soon."  It ultimately took the threat of
running an Op-Ed in the business section of the local paper to get
them to realize they can't continue with their plan to offer no IPv6
support at all.

With 800,000 SOHO CPE units deployed that have no IPv6 support and no
remote firmware upgrade option on the horizon, I can understand why
they hoped they could avoid ever supporting v6 -- it will cost them,
literally, a hundred million dollars to fix their CPE situation and
deploy native IPv6 if their CPE vendor can't provide a remote update.
This is also why tunneled solutions are receiving so much effort and
attention -- truck rolls and CPE replacement are huge expenses.

If we don't start pointing fingers at these access networks, they
won't "get it" until the pain of IPv4 depletion lands squarely on
content networks who may eventually be unable to get any IPv4
addresses for their services, or who may be forced to buy transit from
networks who have large, legacy IPv4 pools sitting around just to get
a provider allocation.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From jsw at inconcepts.biz  Mon May  9 16:57:18 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 9 May 2011 17:57:18 -0400
Subject: Yahoo and IPv6
In-Reply-To: <A674A144-70BA-495B-BC4C-38886160495D@puck.nether.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
	<A674A144-70BA-495B-BC4C-38886160495D@puck.nether.net>
Message-ID: <BANLkTinO7+FJWz2_7cbTDwRJqPoGzapmCQ@mail.gmail.com>

On Mon, May 9, 2011 at 4:41 PM, Jared Mauch <jared at puck.nether.net> wrote:
> I'd like to see more progress getting there than finger pointing.

I would, too; but one harsh reality is that vendors are driven by
RFPs, not by what they consciously know their customers will need in
the near future.  Why should vendors invest money in features that
aren't needed to sell routers?  If customers are dumb enough to buy
them anyway, they'll buy *another* router to get those features in the
future.

I do take issue with your suggestion that /64 LANs are in any way
smart in the datacenter.  They are not.  I have some slides on this
topic: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From nenolod at systeminplace.net  Mon May  9 17:54:11 2011
From: nenolod at systeminplace.net (William Pitcock)
Date: Mon, 9 May 2011 17:54:11 -0500
Subject: Cent OS migration
In-Reply-To: <201105091714.06966.lowen@pari.edu>
References: <20110509204536.779081CC09@ptavv.es.net>
	<201105091714.06966.lowen@pari.edu>
Message-ID: <20110509175411.199f4c87@petrie>

On Mon, 9 May 2011 17:14:06 -0400
Lamar Owen <lowen at pari.edu> wrote:

> On Monday, May 09, 2011 04:45:36 PM Kevin Oberman wrote:
> > Depends on what he is doing. BSDs tend to be far more mature than
> > any Linux. They are poor systems for desktops or anything like
> > that. They are heavily used as servers by many vary large providers
> > and as the basis for many products like Ironport (Cisco) and JunOS
> > (Juniper). 
> 
> Cisco had an RHEL rebuild (internal) at one time, called,
> refreshingly enough, Cisco Enterprise Linux.  Cisco also uses/used a
> Linux base for their Content Engines and subsequent ACNS-running
> boxen.
> 
> The rather high-priced ADVA-sourced Cisco  Metro 1500 DWDM boxes used
> a 486 ISA single-board computer running off of DiskOnChip SSD for
> control and SNMP.
> 
> Having said that, I'd be just about as comfortable with a BSD as with
> a Linux.
> 
> And I do, and will continue to, run CentOS in production. 

I'd rather run Scientific Linux over CentOS.  Infact, I'd rather this so
much that we run SL instead of CentOS even on our cPanel boxes now.

Mind, for anything where we *don't* have to run CentOS, we use Debian
or Alpine.

Anyway, I was just wondering what the general consensus of NANOG is
regarding CentOS vs Scientific Linux.  SL generally has faster security
updates and people are *paid* to work on it fulltime.  CentOS on the
other hand is supported out-of-the-box by most software.

William



From jason at i6ix.com  Mon May  9 18:45:27 2011
From: jason at i6ix.com (Jason Bertoch)
Date: Mon, 09 May 2011 19:45:27 -0400
Subject: aster.pl unwise abuse policy
In-Reply-To: <Pine.LNX.4.64.1105091053540.10524@sasami.anime.net>
References: <Pine.LNX.4.64.1105091053540.10524@sasami.anime.net>
Message-ID: <4DC87C97.7080509@i6ix.com>

On 5/9/2011 1:54 PM, goemon at anime.net wrote:
> Reports sent via E-Mail will not be processed. 

Those are considered authorization to block by CIDR, as needed, here.  
No need to advise the already-unwilling recipient.

/Jason



From owen at delong.com  Mon May  9 19:40:11 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 17:40:11 -0700
Subject: Yahoo and IPv6
In-Reply-To: <C9EDE811.A0C8%fmartin@linkedin.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
Message-ID: <69E27392-E4B7-49F0-9C7C-31A0C99B9FC6@delong.com>


On May 8, 2011, at 11:54 PM, Franck Martin wrote:

> http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
> "Will IPv6 become a permanent change on June 8, 2011?
> No. World IPv6 day is a 24-hour trial period in which we will publish our content on both the IPv4 and IPv6 servers. Yahoo! is participating in order to help prepare our services (as well as your hardware) to help ensure a smooth transition for when the IPv4 addresses run out. "
> 
> Huh? I thought IPv4 addresses had run out already?.
> 
> At IANA level and now for anyone in the AP region at least.

IANA is out of IPv4.
APNIC is into their austerity policy which covers their entire last /8.
RIPE-NCC is probably next and I expect they will likely run out next month.
I suspect ARIN's free pool will probably last until October-ish, give or take.

LACNIC and AfriNIC are kind of wildcards. If consumption remains within their
regions, they probably have addresses for some time.

If organizations from the other regions start pillaging their address space, it
could evaporate in weeks, depending on how they react.

Owen




From matthew at matthew.at  Mon May  9 20:08:26 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 9 May 2011 18:08:26 -0700
Subject: Yahoo and IPv6
In-Reply-To: <69E27392-E4B7-49F0-9C7C-31A0C99B9FC6@delong.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
	<69E27392-E4B7-49F0-9C7C-31A0C99B9FC6@delong.com>
Message-ID: <5BD539CD-2D96-4FEE-8E5E-3DC471D04CB0@matthew.at>


On May 9, 2011, at 5:40 PM, Owen DeLong wrote:

> 
> On May 8, 2011, at 11:54 PM, Franck Martin wrote:
> 
>> http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html
>> "Will IPv6 become a permanent change on June 8, 2011?
>> No. World IPv6 day is a 24-hour trial period in which we will publish our content on both the IPv4 and IPv6 servers. Yahoo! is participating in order to help prepare our services (as well as your hardware) to help ensure a smooth transition for when the IPv4 addresses run out. "
>> 
>> Huh? I thought IPv4 addresses had run out already?.
>> 
>> At IANA level and now for anyone in the AP region at least.
> 
> IANA is out of IPv4.
> APNIC is into their austerity policy which covers their entire last /8.
> RIPE-NCC is probably next and I expect they will likely run out next month.
> I suspect ARIN's free pool will probably last until October-ish, give or take.
> 
> LACNIC and AfriNIC are kind of wildcards. If consumption remains within their
> regions, they probably have addresses for some time.
> 
> If organizations from the other regions start pillaging their address space, it
> could evaporate in weeks, depending on how they react.


It'd certainly be interesting to watch and see how many things that might be in the APNIC region are actually getting ARIN assignments over the next few weeks/months.

Matthew Kaufman


From owen at delong.com  Mon May  9 20:10:19 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 18:10:19 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTinJb7tpAtPK2OvHeAjJVwYH5FoBOQ@mail.gmail.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<BANLkTinJb7tpAtPK2OvHeAjJVwYH5FoBOQ@mail.gmail.com>
Message-ID: <47ECE844-D2F4-4EA4-85F5-35EBED405D14@delong.com>


On May 9, 2011, at 9:04 AM, Cameron Byrne wrote:

> On Mon, May 9, 2011 at 8:16 AM, Arie Vayner <ariev at vayner.net> wrote:
>> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
>> IPv6 help page...
>> 
>> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
>> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
>> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
>> it says:
>> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
>> will have issues reaching Yahoo!, as well as your other favorite web sites.
>> We recommend disabling
>> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>,
>> or seeking assistance in order to fix your system's IPv6 configuration
>> through your ISP or computer manufacturer."
>> 
>> What disturbs me is the piece saying "We recommend disabling
>> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
>> ", with a very easy link...
>> 
> 
> No IPv6 is better than broken* IPv6.
> 
For production, yes. However, in terms of recommendations to prepare for
IPv6 day, uh, no... The better recommendation would be to explain the
exact issue detected and suggest ways for the user to resolve it.

Owen




From owen at delong.com  Mon May  9 20:14:01 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 18:14:01 -0700
Subject: Yahoo and IPv6
In-Reply-To: <11723.1304958355@localhost>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
Message-ID: <24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>


On May 9, 2011, at 9:25 AM, Valdis.Kletnieks at vt.edu wrote:

> On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
>> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
>> IPv6 help page...
>> 
>> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
>> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
>> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
>> it says:
>> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
>> will have issues reaching Yahoo!, as well as your other favorite web sites.
> 
> The *really* depressing part is that it says the same thing for me, on a *known*
> working IPv6 network.
> 
FWIW, it is happy with my connection and consistently reports positive results.

I'm running my own addresses through HE tunnels and tunnels
to Layer42.

The tunnels ride over Comcast and Raw Bandwidth DSL.

> And then when I retry it a few minutes later, with a tcpdump running, it works.
> 
> And then another try says it failed, though tcpdump shows it seems to work.
> 
> For what it's worth, the attempted download  file is:
> 
> % wget http://v6test.yahoo.com/eng/test/eye-test.png
> --2011-05-09 11:44:39--  http://v6test.yahoo.com/eng/test/eye-test.png
> Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
> Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [image/png]
> Saving to: `eye-test.png.1'
> 
>    [ <=>                                   ] 2,086       --.-K/s   in 0s      
> 
> 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]
> 
> Looking at the Javascript that drives the test, it appears the *real* problem
> is that they set a 3 second timeout on the download - which basically means
> that if you have to retransmit either the DNS query or the TCP SYN, you're
> dead as far as the test is concerned.

Well, if you're having to retransmit those intermittently, then, it does seem you
have some level of brokenness with your network, no?

Owen




From millnert at gmail.com  Mon May  9 20:17:10 2011
From: millnert at gmail.com (Martin Millnert)
Date: Mon, 9 May 2011 21:17:10 -0400
Subject: Yahoo and IPv6
In-Reply-To: <69E27392-E4B7-49F0-9C7C-31A0C99B9FC6@delong.com>
References: <C9EDE811.A0C8%fmartin@linkedin.com>
	<69E27392-E4B7-49F0-9C7C-31A0C99B9FC6@delong.com>
Message-ID: <BANLkTikqa2BGhq60GAi4RJzr3BVOj+HKJQ@mail.gmail.com>

Owen,

On Mon, May 9, 2011 at 8:40 PM, Owen DeLong <owen at delong.com> wrote:
> RIPE-NCC is probably next and I expect they will likely run out next month.

Seems a bit improbable to me, considering:
http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph

Regards,
Martin



From marka at isc.org  Mon May  9 20:28:42 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 10 May 2011 11:28:42 +1000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Mon, 09 May 2011 18:14:01 MST."
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
Message-ID: <20110510012842.94DB2E9C03E@drugs.dv.isc.org>


In message <24499CC4-64A1-419C-AB06-08A82D535B10 at delong.com>, Owen DeLong write
s:
> Well, if you're having to retransmit those intermittently, then, it does
> seem you have some level of brokenness with your network, no?

No.  The point of retransmission is to provide reliable service
over a unreliable transport.  Some level of retransmission is normal.

> Owen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From cb.list6 at gmail.com  Mon May  9 20:46:47 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 9 May 2011 18:46:47 -0700
Subject: Yahoo and IPv6
Message-ID: <BANLkTikPrDoxd+JY3GPvVJnHFy_LEqRrDQ@mail.gmail.com>

On May 9, 2011 6:11 PM, "Owen DeLong" <owen at delong.com> wrote:
>
>
> On May 9, 2011, at 9:04 AM, Cameron Byrne wrote:
>
> > On Mon, May 9, 2011 at 8:16 AM, Arie Vayner <ariev at vayner.net> wrote:
> >> Actually, I have just noticed a slightly more disturbing thing on the
Yahoo
> >> IPv6 help page...
> >>
> >> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6
services
> >> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried
to
> >> run the "Start IPv6 Test" tool at
http://help.yahoo.com/l/us/yahoo/ipv6/ and
> >> it says:
> >> "We detected an issue with your IPv6 configuration. On World IPv6 Day,
you
> >> will have issues reaching Yahoo!, as well as your other favorite web
sites.
> >> We recommend disabling
> >> IPv6<
http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html
>,
> >> or seeking assistance in order to fix your system's IPv6 configuration
> >> through your ISP or computer manufacturer."
> >>
> >> What disturbs me is the piece saying "We recommend disabling
> >> IPv6<
http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html
>
> >> ", with a very easy link...
> >>
> >
> > No IPv6 is better than broken* IPv6.
> >
> For production, yes. However, in terms of recommendations to prepare for
> IPv6 day, uh, no... The better recommendation would be to explain the
> exact issue detected and suggest ways for the user to resolve it.
>

I hope you are not insinuating that ipv6 is not production today, many real
prod sites are ds today :)  If one properly working website fails over ipv6,
they will all fail for that user  (modulo routing table fragmentation). I
would really like the world to treat v6 as real production, and not doing so
is one of the major hurtles to v6 deployment.

Agreed. It would be nice to diagnose and fix, there are web sites for that,
but that is not yahoo's issue or scope to "the masses" who don't know and
should not care about L3 protocols. The only practical solution at scale is
to turn it off at the client to restore service (web page loads ... ).  The
other practical solution, at scale,  is keep v6 off at the server .... which
is, IMHO, worse.

Cb

> Owen
>


From jmaslak at antelope.net  Mon May  9 21:04:42 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Mon, 9 May 2011 20:04:42 -0600
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTinO7+FJWz2_7cbTDwRJqPoGzapmCQ@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
	<A674A144-70BA-495B-BC4C-38886160495D@puck.nether.net>
	<BANLkTinO7+FJWz2_7cbTDwRJqPoGzapmCQ@mail.gmail.com>
Message-ID: <BANLkTimBs6BNCG7L8iqWnhDOe2CMQW=rgg@mail.gmail.com>

On Mon, May 9, 2011 at 3:57 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:

I do take issue with your suggestion that /64 LANs are in any way
> smart in the datacenter.  They are not.  I have some slides on this
> topic: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf



There are ways of mitigating this (the easiest is to use ACLs or firewalls
to limit traffic into a subnet from untrusted sources so that only
legitimate traffic is allowed).

As for IPv6 in general, for other posters, I have a lot more concern about
things like missing routes in routing tables, lack of residential IPv6 (one
place where it would be *very* useful - think VoIP, P2P, etc), and lack of
any good tunnel broker options.

I've also had plenty of trouble getting IPv6 in data centers (4 different
providers of caged data center space, none of which provided it, including
one Tier 1 who advertised that all their business customers got free IPv6
with IPv4 transit from them; I guess they didn't think someone renting caged
space and redundant ethernet in one of their data centers was a business
customer, but I digress...)

I'd settle for a good tunnel at this point.

What do I mean by good tunnel option?  The following:

1) Provider treats it like production, not as a tool for business leverage
or a service only used for "testing"

2) Provider that has full routing table.  A provider couldn't stay in
business in the IPv4 world if they lacked connectivity to one or more
default free networks.  Yet in IPv6, it's the norm.

3) Provider that provides support for it - first through top level

4) Provider has redundancy at all levels

5) Provider makes it quick and simple to sign up, with rates posted on their
website based on bandwidth desired (for residential and small business
customers).  I don't want to talk to a sales guy if I'm just setting up a
tunnel for a DSL site!

6) Provider has an access location somewhere within, say, 1000 miles of my
location.  Ideally at a major exchange point in the metro.

7) Provider's network doesn't route me through Tokyo or Frankfurt to get
from Denver to Chicago - regardless of who's network in Chicago I'm trying
to connect to.

This doesn't exist - it's wishful thinking.  So this leaves native
connectivity.  Of course native connectivity is problematic, as it doesn't
always come with full routing tables, isn't necessarily available on the
circuit you have, and doesn't really give you all that much.  That's
assuming you can find it at all.  After all, it's only been around for most
of the time of the web.


From warren at kumari.net  Mon May  9 21:15:57 2011
From: warren at kumari.net (Warren Kumari)
Date: Mon, 9 May 2011 22:15:57 -0400
Subject: Yahoo and IPv6
In-Reply-To: <24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
Message-ID: <6628BD73-CCC3-4173-8A07-8693E813CE2D@kumari.net>


On May 9, 2011, at 9:14 PM, Owen DeLong wrote:

> 
> On May 9, 2011, at 9:25 AM, Valdis.Kletnieks at vt.edu wrote:
> 
>> On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
>>> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
>>> IPv6 help page...
>>> 
>>> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
>>> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
>>> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
>>> it says:
>>> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
>>> will have issues reaching Yahoo!, as well as your other favorite web sites.
>> 
>> The *really* depressing part is that it says the same thing for me, on a *known*
>> working IPv6 network.
>> 
> FWIW, it is happy with my connection and consistently reports positive results.
> 
> I'm running my own addresses through HE tunnels and tunnels
> to Layer42.
> 
> The tunnels ride over Comcast and Raw Bandwidth DSL.


Yup -- while not perfect, the Yahoo! testing has been working well for me.

Yahoo has to tread a very careful line between giving too little and too much information --  I have tried walking a few non-technical folk through troubleshooting their v6 connectivity by phone and it is really very hard to do, and that is interactively. Writing something that someone can download, print and then follow is nigh impossible. No matter how well this guide is written, a number of folk will manage to screw it up, and of *course* that will be Yahoo's fault....

Jason's page at http://test-ipv6.com/ gives way way more information (and the page at http://ipv6-test.com/ also gives some more), both of these pages are much too complex for the average user.

W
> 
>> And then when I retry it a few minutes later, with a tcpdump running, it works.
>> 
>> And then another try says it failed, though tcpdump shows it seems to work.
>> 
>> For what it's worth, the attempted download  file is:
>> 
>> % wget http://v6test.yahoo.com/eng/test/eye-test.png
>> --2011-05-09 11:44:39--  http://v6test.yahoo.com/eng/test/eye-test.png
>> Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
>> Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: unspecified [image/png]
>> Saving to: `eye-test.png.1'
>> 
>>   [ <=>                                   ] 2,086       --.-K/s   in 0s      
>> 
>> 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]
>> 
>> Looking at the Javascript that drives the test, it appears the *real* problem
>> is that they set a 3 second timeout on the download - which basically means
>> that if you have to retransmit either the DNS query or the TCP SYN, you're
>> dead as far as the test is concerned.
> 
> Well, if you're having to retransmit those intermittently, then, it does seem you
> have some level of brokenness with your network, no?
> 
> Owen
> 
> 




From Valdis.Kletnieks at vt.edu  Mon May  9 21:23:03 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 09 May 2011 22:23:03 -0400
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Mon, 09 May 2011 18:14:01 PDT."
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
Message-ID: <9862.1304994183@localhost>

On Mon, 09 May 2011 18:14:01 PDT, Owen DeLong said:
> Well, if you're having to retransmit those intermittently, then, it does seem you
> have some level of brokenness with your network, no?

So if I retransmit because *your* router is down, it's a brokenness in *my* network?

Given the following posting from earlier this morning:

> The location that's affecting the results is pending removal from DNS;
> and ASAP we hope to have the name moved to the geo-LB that suppors v6,
> instead of the round robin it is today.

I feel pretty damned justified in saying it wasn't *my* network causing the retransmits.

(Oh - and kudos for the person quoted above for 'fessing up, and to the people
that tracked down the actual issue. That always sucks when the test rig itself
has issues. Glad to hear it will be fixed)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110509/2586b34c/attachment.bin>

From owen at delong.com  Mon May  9 21:34:59 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 19:34:59 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DC8476F.2070905@dougbarton.us>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
Message-ID: <AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>


On May 9, 2011, at 12:58 PM, Doug Barton wrote:

> On 05/09/2011 12:40, Tony Hain wrote:
>>> -----Original Message-----
>>> From: Doug Barton [mailto:dougb at dougbarton.us]
>>> Sent: Monday, May 09, 2011 12:11 PM
>>> To: Jared Mauch
>>> Cc: nanog at nanog.org; Arie Vayner
>>> Subject: Re: Yahoo and IPv6
>>> 
>>> On 05/09/2011 10:27, Jared Mauch wrote:
>>>> I do feel the bar that Yahoo is setting is too high.  There are a lot
>>> of network elements that are broken, either DNS servers, home
>>> 'gateway/nat' devices, or other elements in the delegation chain.
>>> 
>>> Publicly held corporations are responsible to their shareholders to get
>>> eyeballs on their content. *That* is their job, not promoting cool new
>>> network tech. When you have millions of users hitting your site every
>>> day losing 1/2000 is a large chunk of revenue. The fact that the big
>>> players are doing world IPv6 day at all should be celebrated, promoted,
>>> and we should all be ready to take to heart the lessons learned from
>>> it.
>>> 
>>> The content providers are not to be blamed for the giant mess that IPv6
>>> deployment has become. If 6to4 and Teredo had never happened, in all
>>> likelihood we wouldn't be in this situation today.
>> 
>> Which situation ??? The one where the content can demonstrate how broken the
>> networks really are? Or the one where the content sites are exposed for
>> their lack of prior planning?
> 
> I disagree with your attempt to scope the problem. :)
> 
>> The entire point of those technologies you are complaining about was to
>> break the stalemate between content and network,
> 
> I also disagree with this statement, but there is very little point in arguing about it at this stage.
> 
>> because both sides will
>> always wait and blame the other. The fact that the content side chose to
>> wait until the last possible minute to start is where the approach falls
>> down. Expecting magic to cover for lack of proactive effort 5-10 years ago
>> is asking a bit much, even for the content mafia.
> 
> One could also argue that the fact that the IPv6 protocol is still not fully mature, and that the IPv6 intelligentsia are only recently coming to the point where they are willing to give both the content and eyeball networks what they've been asking for all along (PI and robust DHCPv6 being top of the respective lists) has led to the situation we're in now. Of course the truth is probably somewhere in the middle, but it's definitely not all on one side.
> 
PI was granted at least in the ARIN region in since August 30, 2006. I know, I wrote
the original policy proposal (2005-1 which was later merged with proposals from
Andrew Dul and Kevin Loch based on a cooperative effort among the three of us).

I doubt that DHCPv6 was standing in the way of content providers.

>> In any case, the content side can mitigate all of the latency related issues
>> they complain about in 6to4 by putting in a local 6to4 router and publishing
>> the corresponding 2002:: prefix based address in DNS for their content. They
>> choose to hold their breath and turn blue, blaming the network for the lack
>> of 5-9's access to the eyeballs when they hold at least part of a solution
>> in their own hands.
> 
> Looking at that from the content provider side for a second, what is their motivation for doing it? The IETF created 6to4, and some foolish OS and/or hardware vendors enabled it by default. So you're saying that it's up to the content providers to spend money to fix a problem they didn't create, when the easy/free solution is simply not to turn on IPv6 at all? I completely fail to see an incentive for the content providers to do this, but maybe I'm missing something.
> 
While we're not directly a content provider, we do host several of them and we do
run the largest network of 6to4 relays that I am aware of. In our experience at HE,
this has dramatically improved the IPv6 experience for our clients. As such, I would
think that providing a better user experience should serve as reasonable motivation
for any rational content provider. It's not like running 6to4 relays is difficult or
expensive.

> And can we please stop pretending that this is an easy thing for the content providers to do? Big content networks like Yahoo! have dozens of POPs, and hundreds of address ranges. The IETF is *still* working on tweaking 6to4, so even if the content providers put up these relays today, and somehow figure out how to test them, their work is not done.
> 
It is relatively easy to do, even with dozens of POPs. There isn't anything special you
have to do for the hundreds of address ranges, really, so I don't buy that as being a
meaningful part of the argument.

> I do agree with you that pointing fingers at this stage is really not helpful. I continue to maintain that being supportive of those content networks that are willing to wade in is the right answer.
> 
Agreed, but, it's also important to point out when they're starting to swim in directions
that are counterproductive, such as having help sites that advise users to turn off
IPv6 with fixing their IPv6 capabilities as a secondary option.

Owen
> 




From owen at delong.com  Mon May  9 22:15:16 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 20:15:16 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTikPrDoxd+JY3GPvVJnHFy_LEqRrDQ@mail.gmail.com>
References: <BANLkTikPrDoxd+JY3GPvVJnHFy_LEqRrDQ@mail.gmail.com>
Message-ID: <29386A18-FCCA-4074-8D56-3B5C4888E208@delong.com>


On May 9, 2011, at 6:46 PM, Cameron Byrne wrote:

> 
> On May 9, 2011 6:11 PM, "Owen DeLong" <owen at delong.com> wrote:
> >
> >
> > On May 9, 2011, at 9:04 AM, Cameron Byrne wrote:
> >
> > > On Mon, May 9, 2011 at 8:16 AM, Arie Vayner <ariev at vayner.net> wrote:
> > >> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> > >> IPv6 help page...
> > >>
> > >> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
> > >> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
> > >> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
> > >> it says:
> > >> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
> > >> will have issues reaching Yahoo!, as well as your other favorite web sites.
> > >> We recommend disabling
> > >> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>,
> > >> or seeking assistance in order to fix your system's IPv6 configuration
> > >> through your ISP or computer manufacturer."
> > >>
> > >> What disturbs me is the piece saying "We recommend disabling
> > >> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
> > >> ", with a very easy link...
> > >>
> > >
> > > No IPv6 is better than broken* IPv6.
> > >
> > For production, yes. However, in terms of recommendations to prepare for
> > IPv6 day, uh, no... The better recommendation would be to explain the
> > exact issue detected and suggest ways for the user to resolve it.
> >
> 
> I hope you are not insinuating that ipv6 is not production today, many real prod sites are ds today :)  If one properly working website fails over ipv6, they will all fail for that user  (modulo routing table fragmentation). I would really like the world to treat v6 as real production, and not doing so is one of the major hurtles to v6 deployment.
> 
Not at all. I work for one of the largest IPv6 prod. networks today.

I would like the world to treat IPv6 as real production, too. Telling users to turn it off
isn't that.

My point was that from the user's perspective, for production networking purposes,
having working IPv4 and no IPv6 is, today, better than having working IPv4 and
broken IPv6.

For purposes of the user preparing for IPv6 day, having both protocols on and identifying
and resolving the problems with IPv6 is better than turning IPv6 off.

Sorry, I assumed everyone here knew that I was a strong IPv6 advocate. I believe there
was effort on this very list to have my name changed to "Mr. IPv6."

> Agreed. It would be nice to diagnose and fix, there are web sites for that, but that is not yahoo's issue or scope to "the masses" who don't know and should not care about L3 protocols. The only practical solution at scale is to turn it off at the client to restore service (web page loads ... ).  The other practical solution, at scale,  is keep v6 off at the server .... which is, IMHO, worse.
> 
At scale, perhaps, but, if you are choosing to provide a "test IPv6" button, then, I think you should take on some
responsibility for putting something better than "meh, failed... Turn it off". behind that.

Owen



From owen at delong.com  Mon May  9 22:28:22 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 20:28:22 -0700
Subject: Yahoo and IPv6
In-Reply-To: <20110510012842.94DB2E9C03E@drugs.dv.isc.org>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
	<20110510012842.94DB2E9C03E@drugs.dv.isc.org>
Message-ID: <C2C6EA39-B9BA-4B6A-8B6A-960088581AAF@delong.com>


On May 9, 2011, at 6:28 PM, Mark Andrews wrote:

> 
> In message <24499CC4-64A1-419C-AB06-08A82D535B10 at delong.com>, Owen DeLong write
> s:
>> Well, if you're having to retransmit those intermittently, then, it does
>> seem you have some level of brokenness with your network, no?
> 
> No.  The point of retransmission is to provide reliable service
> over a unreliable transport.  Some level of retransmission is normal.
> 
>> Owen
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

No, it isn't. The transport is failing if you are having to retransmit more than once in a blue
moon. Yes, retransmission helps overcome such failures in the transport, but, that does
not mean that the transport isn't broken.

Owen




From owen at delong.com  Mon May  9 22:31:07 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 9 May 2011 20:31:07 -0700
Subject: Yahoo and IPv6
In-Reply-To: <6628BD73-CCC3-4173-8A07-8693E813CE2D@kumari.net>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
	<6628BD73-CCC3-4173-8A07-8693E813CE2D@kumari.net>
Message-ID: <2EE6E6B2-D5AB-46FF-8673-B279D91EB97E@delong.com>


On May 9, 2011, at 7:15 PM, Warren Kumari wrote:

> 
> On May 9, 2011, at 9:14 PM, Owen DeLong wrote:
> 
>> 
>> On May 9, 2011, at 9:25 AM, Valdis.Kletnieks at vt.edu wrote:
>> 
>>> On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:
>>>> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
>>>> IPv6 help page...
>>>> 
>>>> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
>>>> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
>>>> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
>>>> it says:
>>>> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
>>>> will have issues reaching Yahoo!, as well as your other favorite web sites.
>>> 
>>> The *really* depressing part is that it says the same thing for me, on a *known*
>>> working IPv6 network.
>>> 
>> FWIW, it is happy with my connection and consistently reports positive results.
>> 
>> I'm running my own addresses through HE tunnels and tunnels
>> to Layer42.
>> 
>> The tunnels ride over Comcast and Raw Bandwidth DSL.
> 
> 
> Yup -- while not perfect, the Yahoo! testing has been working well for me.
> 
> Yahoo has to tread a very careful line between giving too little and too much information --  I have tried walking a few non-technical folk through troubleshooting their v6 connectivity by phone and it is really very hard to do, and that is interactively. Writing something that someone can download, print and then follow is nigh impossible. No matter how well this guide is written, a number of folk will manage to screw it up, and of *course* that will be Yahoo's fault....
> 
Gathering a list of IPv6 resources that people could refer to and publishing them
would be better than saying "Meh, turn it off."

Saying "It's broken, you should work with your ISP to correct the problem. A technical detailed
description of what went wrong is available <here>(should be a link)." would be preferable.

There are lots of better options that don't require Yahoo to actually do more than they are
doing now.

> Jason's page at http://test-ipv6.com/ gives way way more information (and the page at http://ipv6-test.com/ also gives some more), both of these pages are much too complex for the average user.
> 
True... I'm not saying Yahoo should go that way. I'm just taking issue with the idea of them
suggesting users turn off IPv6 as a preferred alternative over fixing it.

Owen

> W
>> 
>>> And then when I retry it a few minutes later, with a tcpdump running, it works.
>>> 
>>> And then another try says it failed, though tcpdump shows it seems to work.
>>> 
>>> For what it's worth, the attempted download  file is:
>>> 
>>> % wget http://v6test.yahoo.com/eng/test/eye-test.png
>>> --2011-05-09 11:44:39--  http://v6test.yahoo.com/eng/test/eye-test.png
>>> Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ...
>>> Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected.
>>> HTTP request sent, awaiting response... 200 OK
>>> Length: unspecified [image/png]
>>> Saving to: `eye-test.png.1'
>>> 
>>>  [ <=>                                   ] 2,086       --.-K/s   in 0s      
>>> 
>>> 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]
>>> 
>>> Looking at the Javascript that drives the test, it appears the *real* problem
>>> is that they set a 3 second timeout on the download - which basically means
>>> that if you have to retransmit either the DNS query or the TCP SYN, you're
>>> dead as far as the test is concerned.
>> 
>> Well, if you're having to retransmit those intermittently, then, it does seem you
>> have some level of brokenness with your network, no?
>> 
>> Owen
>> 
>> 




From jsw at inconcepts.biz  Mon May  9 23:57:04 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 10 May 2011 00:57:04 -0400
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimBs6BNCG7L8iqWnhDOe2CMQW=rgg@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>
	<A674A144-70BA-495B-BC4C-38886160495D@puck.nether.net>
	<BANLkTinO7+FJWz2_7cbTDwRJqPoGzapmCQ@mail.gmail.com>
	<BANLkTimBs6BNCG7L8iqWnhDOe2CMQW=rgg@mail.gmail.com>
Message-ID: <BANLkTinOHFpVjnO37MUGyOTe1ARSPV=Wbg@mail.gmail.com>

On Mon, May 9, 2011 at 10:04 PM, Joel Maslak <jmaslak at antelope.net> wrote:
> On Mon, May 9, 2011 at 3:57 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> I do take issue with your suggestion that /64 LANs are in any way
>> smart in the datacenter. ?They are not. ?I have some slides on this
>> topic: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf
>
> There are ways of mitigating this (the easiest is to use ACLs or firewalls
> to limit traffic into a subnet from untrusted sources so that only
> legitimate traffic is allowed).

Your suggestion has two main disadvantages:
1) it doesn't work on some platforms, because input ACL won't stop ND
learn/solicit -- obviously this is bad
2) it requires you to configure a potentially large input ACL on every
single interface on the box, and adjust that ACL whenever you
provision more IPv6 addresses for end-hosts -- kinda like not having a
control-plane filter, only worse

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From igor at gashinsky.net  Mon May  9 23:58:24 2011
From: igor at gashinsky.net (Igor Gashinsky)
Date: Tue, 10 May 2011 00:58:24 -0400 (EDT)
Subject: Yahoo and IPv6
In-Reply-To: <9862.1304994183@localhost>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
	<9862.1304994183@localhost>
Message-ID: <Pine.LNX.4.64.1105100047300.23905@moonbase.nullrouteit.net>

On Mon, 9 May 2011, Valdis.Kletnieks at vt.edu wrote:

:: Given the following posting from earlier this morning:
:: 
:: > The location that's affecting the results is pending removal from DNS;
:: > and ASAP we hope to have the name moved to the geo-LB that suppors v6,
:: > instead of the round robin it is today.
:: 
:: I feel pretty damned justified in saying it wasn't *my* network causing the retransmits.
:: 
:: (Oh - and kudos for the person quoted above for 'fessing up, and to the people
:: that tracked down the actual issue. That always sucks when the test rig itself
:: has issues. Glad to hear it will be fixed)

In the spirit of full disclosure, I'll "fess up" a little more then :) We 
did have the cname for the help pages point to an old rotation, something 
that is getting rectified, and the timeout in the javascript was a tad too 
aggressive (would lead to some unwanted false negatives), so that timeout 
is going to be up'ed to between 5 and 10 seconds (we are measuring a few 
different things, so which value will be used will depend on what is being 
measured where).

Thank you for catching this -- we are still working on finishing up the 
monitoring component of flag day related content :)

-igor



From igor at gashinsky.net  Tue May 10 01:17:46 2011
From: igor at gashinsky.net (Igor Gashinsky)
Date: Tue, 10 May 2011 02:17:46 -0400 (EDT)
Subject: Yahoo and IPv6
In-Reply-To: <AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net> <4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
Message-ID: <Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>

:: >> In any case, the content side can mitigate all of the latency related issues
:: >> they complain about in 6to4 by putting in a local 6to4 router and publishing
:: >> the corresponding 2002:: prefix based address in DNS for their content. They
:: >> choose to hold their breath and turn blue, blaming the network for the lack
:: >> of 5-9's access to the eyeballs when they hold at least part of a solution
:: >> in their own hands.
:: > 
:: > Looking at that from the content provider side for a second, what is their motivation for doing it? The IETF created 6to4, and some foolish OS and/or hardware vendors enabled it by default. So you're saying that it's up to the content providers to spend money to fix a problem they didn't create, when the easy/free solution is simply not to turn on IPv6 at all? I completely fail to see an incentive for the content providers to do this, but maybe I'm missing something.
:: > 

So, just for the record, I am not speaking for my employer, and am 
speaking strictly for myself here, and I'm going to try to keep this my 
one and only message about finger-pointing :)

The time for finger-pointing is over, period, all we are all trying to do 
now is figure out how to deal with the present (sucky) situation. The 
current reality is that for a non-insignificant percentage of users when 
you enable dual-stack, they are gong to drop off the face of the planet. 
Now, for *you*, 0.026% may be insignificant (and, standalone, that number 
is insignificant), but for a global content provider that has ~700M users, 
that's 182 *thousand* users that *you*, *through your actions* just took 
out.. 182,000 - that is *not* insignificant

*That* is what world ipv6 day is about to me -- getting enough attention 
at the problem so that all of us can try to move the needle in the right 
direction. If enough users realize that they are broken, and end up 
"fixing themselves", then it will be a resounding success. And, yes, to 
me, disabling broken ipv6 *is* "fixing themselves". If they turn broken 
ipv6 into working ipv6, even better, I just hope all the access networks 
staffed up their helpdesk to deal with the call volumes..

And, if the breakage stats remain bad, well, that's what DNS
"whitelists/blacklists" are going to be for..

:: While we're not directly a content provider, we do host several of them and we do
:: run the largest network of 6to4 relays that I am aware of. In our experience at HE,
:: this has dramatically improved the IPv6 experience for our clients. As such, I would
:: think that providing a better user experience should serve as reasonable motivation
:: for any rational content provider. It's not like running 6to4 relays is difficult or
:: expensive.

No, running *return* 6to4 relays is not difficult at all, in fact, some 
content providers have a ton of them up right now. The problem is that 
content providers can't control the forward relays, or protocol 41 
filtering that's out in the wild. Also, not all breakage is caused by 
6to4, there are still quite a few cases of other breakage, and *that* is 
what's pushing us towards whitelisting.

See: http://www.getipv6.info/index.php/Customer_problems_that_could_occur

:: > And can we please stop pretending that this is an easy thing for the content providers to do? Big content networks like Yahoo! have dozens of POPs, and hundreds of address ranges. The IETF is *still* working on tweaking 6to4, so even if the content providers put up these relays today, and somehow figure out how to test them, their work is not done.
:: > 
:: It is relatively easy to do, even with dozens of POPs. There isn't anything special you
:: have to do for the hundreds of address ranges, really, so I don't buy that as being a
:: meaningful part of the argument.

I think this is a red herring - return relays were never *the* problem.

:: > I do agree with you that pointing fingers at this stage is really not helpful. I continue to maintain that being supportive of those content networks that are willing to wade in is the right answer.
:: > 
:: Agreed, but, it's also important to point out when they're starting to swim in directions
:: that are counterproductive, such as having help sites that advise users to turn off
:: IPv6 with fixing their IPv6 capabilities as a secondary option.

"We recommend disabling IPv6 or seeking assistance in order to fix your 
system's IPv6 configuration through your ISP or computer manufacturer"

So, your problem is that a help page gives the user 2 options, 
the first one of them being a quick and easy fix that a user can do 
himself in less then a minute, and suggesting contacting the ISP or 
manufacturer *second* (and possibly spending quite a bit of time on 
hold/troubleshooting, and then saying "screw it")?!? 

Honestly, I think the people who want ipv6 to work, and are willing and 
capable to troubleshoot it, will; and those who don't will just 
turn it off... Seems like the right outcome to me..

-igor
(man, did I pick a good day to be on an airplane, or what)



From randy at psg.com  Tue May 10 02:51:37 2011
From: randy at psg.com (Randy Bush)
Date: Tue, 10 May 2011 09:51:37 +0200
Subject: Suspecious anycast prefixes
In-Reply-To: <BANLkTika=CG=0H_c6+spoCE-2X02c_AoYQ@mail.gmail.com>
References: <ED2AB7F4-9B84-4DC2-87A7-92E2A6EF6D49@hopcount.ca>
	<BANLkTikN_3EX9qiORF0HON3PPJhnKMqCAg@mail.gmail.com>
Message-ID: <m2ei47m1rq.wl%randy@psg.com>

> I might not explain the background clearly and confused people. We're
> doing research on multiple origin AS issue, and we want to confirm if
> our inference is correct based on history data we collected. For
> example, we found several hundreds of prefixes with multiple origins
> more than two, some of them were inferred as anycast using our
> methodology, but we're not positive with the conjecture, so we want to
> find the ground truth from operators. Thanks for the detailed
> explanations.

the ucla obsession with multiple-origin announcements has a long
history.  the problem is that you think you can make something that
looks forward.  but how will you decide if tomorrow's announcement of
P from A0 and A1 is anycast, ops kink, or an actual mis-announcement?

randy



From owen at delong.com  Tue May 10 02:46:34 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 10 May 2011 00:46:34 -0700
Subject: Yahoo and IPv6
In-Reply-To: <Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
Message-ID: <4C5A3E13-895F-4FDA-829E-83C16AED1192@delong.com>

> :: > I do agree with you that pointing fingers at this stage is really not helpful. I continue to maintain that being supportive of those content networks that are willing to wade in is the right answer.
> :: > 
> :: Agreed, but, it's also important to point out when they're starting to swim in directions
> :: that are counterproductive, such as having help sites that advise users to turn off
> :: IPv6 with fixing their IPv6 capabilities as a secondary option.
> 
> "We recommend disabling IPv6 or seeking assistance in order to fix your 
> system's IPv6 configuration through your ISP or computer manufacturer"
> 
> So, your problem is that a help page gives the user 2 options, 
> the first one of them being a quick and easy fix that a user can do 
> himself in less then a minute, and suggesting contacting the ISP or 
> manufacturer *second* (and possibly spending quite a bit of time on 
> hold/troubleshooting, and then saying "screw it")?!? 
> 
Vs. other more useful options which I have spelled out elsewhere in this
thread, yes.

> Honestly, I think the people who want ipv6 to work, and are willing and 
> capable to troubleshoot it, will; and those who don't will just 
> turn it off... Seems like the right outcome to me..
> 
We can agree to disagree. Turning it off really isn't a good outcome because
it just postpones the inevitable. Encouraging people to call their ISPs to
troubleshoot their IPv6 problems accomplishes two things:

	1.	It raises visibility of the need for IPv6 at the eyeball ISPs. It shows
		that there are users encountering things that cause them to care
		about IPv6 working.

	2.	It helps users resolve their IPv6 problems and get working
		IPv6.

I applaud your employer's efforts to get IPv6 deployed and their leadership
in working towards IPv6 day. Hopefully they can eventually take a more
positive leadership position towards successful eyeball transitions as
well.

Owen




From ariev at vayner.net  Tue May 10 03:12:46 2011
From: ariev at vayner.net (Arie Vayner)
Date: Tue, 10 May 2011 11:12:46 +0300
Subject: Yahoo and IPv6
In-Reply-To: <Pine.LNX.4.64.1105100047300.23905@moonbase.nullrouteit.net>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==@vt.edu>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<11723.1304958355@localhost>
	<24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>
	<9862.1304994183@localhost>
	<Pine.LNX.4.64.1105100047300.23905@moonbase.nullrouteit.net>
Message-ID: <BANLkTimy8p40yJ+s0rr3mvu3E2Gt3=SQdw@mail.gmail.com>

Igor,

When testing, you should take into consideration that people from all across
the world may use this tool, and in some places speed is not the same as in
other places... Latency... Bad linkes... Etc.

Arie

On Tue, May 10, 2011 at 7:58 AM, Igor Gashinsky <igor at gashinsky.net> wrote:

> On Mon, 9 May 2011, Valdis.Kletnieks at vt.edu wrote:
>
> :: Given the following posting from earlier this morning:
> ::
> :: > The location that's affecting the results is pending removal from DNS;
> :: > and ASAP we hope to have the name moved to the geo-LB that suppors v6,
> :: > instead of the round robin it is today.
> ::
> :: I feel pretty damned justified in saying it wasn't *my* network causing
> the retransmits.
> ::
> :: (Oh - and kudos for the person quoted above for 'fessing up, and to the
> people
> :: that tracked down the actual issue. That always sucks when the test rig
> itself
> :: has issues. Glad to hear it will be fixed)
>
> In the spirit of full disclosure, I'll "fess up" a little more then :) We
> did have the cname for the help pages point to an old rotation, something
> that is getting rectified, and the timeout in the javascript was a tad too
> aggressive (would lead to some unwanted false negatives), so that timeout
> is going to be up'ed to between 5 and 10 seconds (we are measuring a few
> different things, so which value will be used will depend on what is being
> measured where).
>
> Thank you for catching this -- we are still working on finishing up the
> monitoring component of flag day related content :)
>
> -igor
>


From iljitsch at muada.com  Tue May 10 05:03:44 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 10 May 2011 12:03:44 +0200
Subject: Yahoo and IPv6
In-Reply-To: <120501cc0e81$0222b1e0$066815a0$@net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
Message-ID: <A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>

On 9 mei 2011, at 21:40, Tony Hain wrote:

>> Publicly held corporations are responsible to their shareholders to get
>> eyeballs on their content. *That* is their job, not promoting cool new
>> network tech. When you have millions of users hitting your site every
>> day losing 1/2000 is a large chunk of revenue.

Nonsense. 0.05% is well below the noise margin for anything that involves humans.

>> The fact that the big
>> players are doing world IPv6 day at all should be celebrated, promoted,
>> and we should all be ready to take to heart the lessons learned from
>> it.

I applaud the first step, but I'm bothered by the fact that no second step is planned.

>> The content providers are not to be blamed for the giant mess that IPv6
>> deployment has become. If 6to4 and Teredo had never happened, in all
>> likelihood we wouldn't be in this situation today.

> The entire point of those technologies you are complaining about was to
> break the stalemate between content and network, because both sides will
> always wait and blame the other.

You're both somewhat right: there's nothing wrong with having 6to4 and Teredo available as an option for people who want/need easy IPv6, which is too hard to get otherwise for most people. The big mistake was to enable it by default. That ALWAYS ends badly. (See for instance HTTP pipelining, good idea but it got tainted by buggy implementations on the client side that made it impossible to enable on the server side.)

> The fact that the content side chose to
> wait until the last possible minute to start is where the approach falls
> down. Expecting magic to cover for lack of proactive effort 5-10 years ago
> is asking a bit much, even for the content mafia. 

The content people don't feel the address crunch and they have no incremental deployment: either you AAAA or you don't AAAA. The opposite is true for the eyeball people, so they are the ones that will have to get this ball rolling.

> In any case, the content side can mitigate all of the latency related issues
> they complain about in 6to4 by putting in a local 6to4 router and publishing
> the corresponding 2002:: prefix based address in DNS for their content.

That wouldn't help people behind firewalls that block protocol 41 (which is way too common) and it's harmful to those with non-6to4 connectivity but no (good) RFC 3484 support so they connect to those 2002:: addresses. (I'm looking at you, MacOS. Try for yourself here: http://6to4test3.runningipv6.net/ )

> We are about the witness the most expensive, complex, blame-fest of a
> transition that one could have imagined 10 years ago. This is simply due to
> the lack of up-front effort that both sides have demonstrated in getting to
> this point. Now that time has expired, all that is left to do is sit back
> and watch the fireworks.

I love fireworks.

I don't think it'll be all that bad, though. Pretty much all the pieces are in place now, it's mostly a question of simply enabling IPv6. Yes, people will whine but how else would we know the NANOG list is still working between operational issues?


From jared at puck.nether.net  Tue May 10 07:43:09 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 10 May 2011 08:43:09 -0400
Subject: Banks and IPv6 (was Re: Yahoo and IPv6)
In-Reply-To: <A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
Message-ID: <AF581DBB-3B77-4D93-B562-B61C1DA8DA40@puck.nether.net>


On May 10, 2011, at 6:03 AM, Iljitsch van Beijnum wrote:

> On 9 mei 2011, at 21:40, Tony Hain wrote:
> 
>>> Publicly held corporations are responsible to their shareholders to get
>>> eyeballs on their content. *That* is their job, not promoting cool new
>>> network tech. When you have millions of users hitting your site every
>>> day losing 1/2000 is a large chunk of revenue.
> 
> Nonsense. 0.05% is well below the noise margin for anything that involves humans.

I think it will be interesting when people start to look at the results. Following the delegation of someplace like a bank that has a financial interest in

a) security (ie: modern software)
b) people reaching their site

There's a lot of IPv6 brokeness in their services.

do "dig +trace aaaa www.citibank.co.uk"

You will eventually reach their load balancer dns servers that start giving out bad referrals/authority.

www.citibank.co.uk.	3600	IN	NS	ldefdc-egsl01-7000.nsroot2.com.
www.citibank.co.uk.	3600	IN	NS	lgbrdc-egsl01-7000.nsroot1.com.
;; Received 153 bytes from 192.193.214.2#53(192.193.214.2) in 36 ms

[trimmed]
.			3600000	IN	NS	m.root-servers.net.
;; BAD REFERRAL
;; Received 500 bytes from 199.67.203.246#53(199.67.203.246) in 100 ms


When you look at the top "25" broken sites, it quickly starts to look like something interesting.  The temporary failure shows some error in the resolver library looking for an AAAA record.  If you ask a non-bind nameserver you may have better luck as they seem to have relaxed SOA tracking.

www.capitalone.com.|208.80.48.112|OK|Temporary failure in name resolution
www.priceline.com.|64.6.17.1|OK|Temporary failure in name resolution
www.kitco.com.|66.38.218.33|OK|Temporary failure in name resolution
www.dmm.co.jp.|203.209.147.15|OK|Temporary failure in name resolution
www.lg.com.|174.35.24.66,174.35.24.81|OK|Temporary failure in name resolution
www.theweathernetwork.com.|207.96.160.181|OK|Temporary failure in name resolution
www.ovguide.com.|64.94.88.21|OK|Temporary failure in name resolution
www.alipay.com.|110.75.132.21|OK|Temporary failure in name resolution
www.sznews.com.|210.21.197.161|OK|Temporary failure in name resolution
www.ryanair.com.|193.95.148.90|OK|Temporary failure in name resolution
www.kbb.com.|209.67.183.100|OK|Temporary failure in name resolution
www.royalbank.com.|142.245.1.203|OK|Temporary failure in name resolution
www.opentable.com.|66.151.130.32|OK|Temporary failure in name resolution
www.bookryanair.com.|193.95.148.91|OK|Temporary failure in name resolution
aleadpay.com.|121.14.17.41|OK|Temporary failure in name resolution
www.20minutos.es.|85.62.13.190|OK|Temporary failure in name resolution
www.nzherald.co.nz.|184.154.158.58|OK|Temporary failure in name resolution
www.rbcroyalbank.com.|142.245.1.15|OK|Temporary failure in name resolution
www.hangzhou.com.cn.|218.108.127.43|OK|Temporary failure in name resolution
www.klikbca.com.|202.6.208.8|OK|Temporary failure in name resolution
www.uk.to.|195.144.11.40|OK|Temporary failure in name resolution
www.atdmt.com.|65.203.229.39,65.242.27.40|OK|Temporary failure in name resolution
www.hc360.com.|221.233.134.141,221.233.134.143|OK|Temporary failure in name resolution
www.dmm.com.|203.209.147.53|OK|Temporary failure in name resolution
www.businesswire.com.|204.8.173.52|OK|Temporary failure in name resolution

Aside from the above, it does seem that there are a fair number of sites that have enabled IPv6 and gone without notice.

take www.informationweek.com which (from my view) sits behind AS209 with their IPv6 space, very similar to their v4 address.

I'm optimistic that more people will 'just enable' ipv6.  Hopefully other technical websites will do it as well, perhaps anyone that matches a regex of "ars" can influence the powers that be.  If they can get people to disable adblock, maybe they can serve up some AAAA as well. :)

- Jared


From tme at multicasttech.com  Tue May 10 08:07:11 2011
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 10 May 2011 09:07:11 -0400
Subject: 23,000 IP addresses
Message-ID: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>

A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week. 

I thought that there might be some interest in the list of these addresses :

http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf

If you have IP addresses on this list, expect to receive papers shortly. 

Here is more of the backstory :

http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/

This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
more of this until some sense returns to the legal system. 

Regards
Marshall 




From chip.gwyn at gmail.com  Tue May 10 08:33:15 2011
From: chip.gwyn at gmail.com (chip)
Date: Tue, 10 May 2011 09:33:15 -0400
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w@mail.gmail.com>

Interesting, especially after this:

http://torrentfreak.com/ip-address-not-a-person-bittorrent-case-judge-says-110503/



On Tue, May 10, 2011 at 9:07 AM, Marshall Eubanks <tme at multicasttech.com> wrote:
> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>
> I thought that there might be some interest in the list of these addresses :
>
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
>
> If you have IP addresses on this list, expect to receive papers shortly.
>
> Here is more of the backstory :
>
> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>
> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
> more of this until some sense returns to the legal system.
>
> Regards
> Marshall
>
>
>



-- 
Just my $.02, your mileage may vary,? batteries not included, etc....



From jlewis at lewis.org  Tue May 10 08:37:55 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 10 May 2011 09:37:55 -0400 (EDT)
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>

On Tue, 10 May 2011, Marshall Eubanks wrote:

> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>
> I thought that there might be some interest in the list of these addresses :
>
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf

It wasn't that good a movie, so I guess they need to squeeze every bit of 
$ they can out of anyone who saw it.  I bought it a a Blockbuster 
liquidation sale (having not seen it previously).

> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>
> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
> more of this until some sense returns to the legal system.

I wonder how things go if you challenge them in court.  This is surely a 
topic for another list, but it seems to me it'd be fairly difficult to 
prove unless they downloaded part of the movie from your IP and verified 
that what they got really was a part of the movie.  If they're going after 
any IP that connected to and downloaded from an agent of the studio (and 
thats what it sounds like) who hosted the file, can they really expect to 
prosecute people for downloading something they were giving away?

Wouldn't that be like the RIAA making bootleg copies of audio CDs, giving 
them away, and then prosecuting anyone who accepted one?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From julien at gormotte.info  Tue May 10 08:40:34 2011
From: julien at gormotte.info (Julien Gormotte)
Date: Tue, 10 May 2011 15:40:34 +0200
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <ed11f0a917b3e6f746e67d0440f0061d@mail.gormotte.info>

 On Tue, 10 May 2011 09:07:11 -0400, Marshall Eubanks wrote:
> A Federal Judge has decided to let the "U.S. Copyright Group"
> subpoena ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of;

 Good for you : it was one of the worst films I've ever seen. And I've 
 seen Iron Man 2.

> subpoenas are
> expected to go out this week.
>
> I thought that there might be some interest in the list of these 
> addresses :
>
> 
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf

 Mine is not. These are only US ISPs ?

> If you have IP addresses on this list, expect to receive papers 
> shortly.
>
> Here is more of the backstory :
>
> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>
> This is turning into quite a legal racket (get order $ 3000 for
> sending a threatening letter); I expect to see a lot
> more of this until some sense returns to the legal system.

 And these problems are spreading everywhere in the world.

>
> Regards
> Marshall




From dlc at lampinc.com  Tue May 10 08:53:58 2011
From: dlc at lampinc.com (Dale Carstensen)
Date: Tue, 10 May 2011 07:53:58 -0600
Subject: 23,000 IP addresses 
In-Reply-To: Your message of "Tue, 10 May 2011 09:07:11 EDT."
	<94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com> 
Message-ID: <20110510135348.709ED38D600@lampinc.com>

>A Federal Judge has decided to let the "U.S. Copyright Group" subpoena
>ISPs over 23,000 alleged downloads of some Sylvester Stallone movie I have 
>never heard of [. . .]
>I thought that there might be some interest in the list of these addresses :
>http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pd
f
> [. . .]
>Marshall

There are only 34 unique ISP names, representing somewhat fewer ISPs
(4 or so have Comcast in the name, I think SBC, Bellsouth and AT&T are
all one, Frontier has a couple of names, etc.)  And they probably are
represented proportional to the number of customers they have, mostly
big cable, ILEC, cell carrier:

   5892 Comcast Cable
   3719 Road Runner
   2997 SBC Internet Services
   2331 Verizon Internet Services
   1293 BellSouth.net
   1010 Cox Communications
    977 Charter Communications
    681 Qwest Communications
    656 Optimum Online
    572 Windstream Communications
    334 Clearwire Corporation
    269 Sprint PCS
    258 Frontier Communications of America
    180 Suddenlink Communications
    168 EarthLink
    136 WideOpenWest
    136 Comcast Business Communications
    118 AT&T Services
    111 Insight Communications Company
     98 Fairpoint Communications
     97 Frontier Communications
     92 RCN Corporation
     70 ALLTEL Corporation
     59 Bresnan Communications
     59 AT&T Global Network Services, LLC
     57 Wave Broadband
     55 Midcontinent Communications
     51 Atlantic Broadband
     48 Sprint
     21 HUGHES NETWORK SYSTEMS
     19 Road Runner Business
     14 Verizon Business
      3 Comcast Telecommunications
      2 Comcast - Houston





From mark at amplex.net  Tue May 10 08:54:44 2011
From: mark at amplex.net (Mark Radabaugh)
Date: Tue, 10 May 2011 09:54:44 -0400
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <4DC943A4.40005@amplex.net>

On 5/10/11 9:07 AM, Marshall Eubanks wrote:
> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>
> I thought that there might be some interest in the list of these addresses :
>
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
>
> If you have IP addresses on this list, expect to receive papers shortly.
>
> Here is more of the backstory :
>
> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>
> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
> more of this until some sense returns to the legal system.
>
> Regards
> Marshall
>
>
A good reason why every ISP should have a published civil subpoena 
compliance fee.

23,000 * $150 each should only cost them $3.45M to get the information.

Seems like that would take the profit out pretty quickly.

-- 
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015




From BaklarR at amtrak.com  Tue May 10 08:55:04 2011
From: BaklarR at amtrak.com (Baklarz, Ron)
Date: Tue, 10 May 2011 09:55:04 -0400
Subject: 23,000 IP addresses
In-Reply-To: <Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
Message-ID: <B50EA92790B4F541AB336496A4DEC89B015457A073@phlmbsb01.amtrak.ad.nrpc>

Maybe they can use the Clinton marijuana-non-inhalation defense - I downloaded the movie but I didn't watch it!

Ron Baklarz CISSP, CISA, CISM, NSA-IAM/IEM
Chief Information Security Officer
National Passenger Railroad Corporation
10 G Street, NE  Office 6E606
Washington, DC 20002
BaklarR at Amtrak.com

-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org]
Sent: Tuesday, May 10, 2011 9:38 AM
To: Marshall Eubanks
Cc: NANOG list
Subject: Re: 23,000 IP addresses

On Tue, 10 May 2011, Marshall Eubanks wrote:

> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>
> I thought that there might be some interest in the list of these addresses :
>
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf

It wasn't that good a movie, so I guess they need to squeeze every bit of
$ they can out of anyone who saw it.  I bought it a a Blockbuster
liquidation sale (having not seen it previously).

> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>
> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
> more of this until some sense returns to the legal system.

I wonder how things go if you challenge them in court.  This is surely a
topic for another list, but it seems to me it'd be fairly difficult to
prove unless they downloaded part of the movie from your IP and verified
that what they got really was a part of the movie.  If they're going after
any IP that connected to and downloaded from an agent of the studio (and
thats what it sounds like) who hosted the file, can they really expect to
prosecute people for downloading something they were giving away?

Wouldn't that be like the RIAA making bootleg copies of audio CDs, giving
them away, and then prosecuting anyone who accepted one?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________




From leigh.porter at ukbroadband.com  Tue May 10 08:42:57 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 10 May 2011 14:42:57 +0100
Subject: 23,000 IP addresses
In-Reply-To: <Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
Message-ID: <7F80DD92-98A4-45CC-A4BE-CAB20C12D286@ukbroadband.com>

So are they basing this on you downloading it or on making it available for others?

Apologies for the top post...

-- 
Leigh Porter


On 10 May 2011, at 14:40, "Jon Lewis" <jlewis at lewis.org> wrote:

> On Tue, 10 May 2011, Marshall Eubanks wrote:
> 
>> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
>> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>> 
>> I thought that there might be some interest in the list of these addresses :
>> 
>> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
> 
> It wasn't that good a movie, so I guess they need to squeeze every bit of $ they can out of anyone who saw it.  I bought it a a Blockbuster liquidation sale (having not seen it previously).
> 
>> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>> 
>> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
>> more of this until some sense returns to the legal system.
> 
> I wonder how things go if you challenge them in court.  This is surely a topic for another list, but it seems to me it'd be fairly difficult to prove unless they downloaded part of the movie from your IP and verified that what they got really was a part of the movie.  If they're going after any IP that connected to and downloaded from an agent of the studio (and thats what it sounds like) who hosted the file, can they really expect to prosecute people for downloading something they were giving away?
> 
> Wouldn't that be like the RIAA making bootleg copies of audio CDs, giving them away, and then prosecuting anyone who accepted one?
> 
> ----------------------------------------------------------------------
> Jon Lewis, MCP :)           |  I route
> Senior Network Engineer     |  therefore you are
> Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From alh-ietf at tndh.net  Tue May 10 09:08:08 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Tue, 10 May 2011 07:08:08 -0700
Subject: Yahoo and IPv6
In-Reply-To: <Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
Message-ID: <13ba01cc0f1b$b21bc600$16535200$@net>

Igor Gashinsky wrote:
> :: >> In any case, the content side can mitigate all of the latency
> related issues
> :: >> they complain about in 6to4 by putting in a local 6to4 router and
> publishing
> :: >> the corresponding 2002:: prefix based address in DNS for their
> content. They
> :: >> choose to hold their breath and turn blue, blaming the network
> for the lack
> :: >> of 5-9's access to the eyeballs when they hold at least part of a
> solution
> :: >> in their own hands.
> :: >
> :: > Looking at that from the content provider side for a second, what
> is their motivation for doing it? The IETF created 6to4, and some
> foolish OS and/or hardware vendors enabled it by default. So you're
> saying that it's up to the content providers to spend money to fix a
> problem they didn't create, when the easy/free solution is simply not
> to turn on IPv6 at all? I completely fail to see an incentive for the
> content providers to do this, but maybe I'm missing something.
> :: >
> 
> So, just for the record, I am not speaking for my employer, and am
> speaking strictly for myself here, and I'm going to try to keep this my
> one and only message about finger-pointing :)
> 
> The time for finger-pointing is over, period, all we are all trying to
> do
> now is figure out how to deal with the present (sucky) situation. The
> current reality is that for a non-insignificant percentage of users
> when
> you enable dual-stack, they are gong to drop off the face of the
> planet.
> Now, for *you*, 0.026% may be insignificant (and, standalone, that
> number
> is insignificant), but for a global content provider that has ~700M
> users,
> that's 182 *thousand* users that *you*, *through your actions* just
> took
> out.. 182,000 - that is *not* insignificant
> 
> *That* is what world ipv6 day is about to me -- getting enough
> attention
> at the problem so that all of us can try to move the needle in the
> right
> direction. If enough users realize that they are broken, and end up
> "fixing themselves", then it will be a resounding success. And, yes, to
> me, disabling broken ipv6 *is* "fixing themselves". If they turn broken
> ipv6 into working ipv6, even better, I just hope all the access
> networks
> staffed up their helpdesk to deal with the call volumes..
> 
> And, if the breakage stats remain bad, well, that's what DNS
> "whitelists/blacklists" are going to be for..
> 
> :: While we're not directly a content provider, we do host several of
> them and we do
> :: run the largest network of 6to4 relays that I am aware of. In our
> experience at HE,
> :: this has dramatically improved the IPv6 experience for our clients.
> As such, I would
> :: think that providing a better user experience should serve as
> reasonable motivation
> :: for any rational content provider. It's not like running 6to4 relays
> is difficult or
> :: expensive.
> 
> No, running *return* 6to4 relays is not difficult at all, in fact, some
> content providers have a ton of them up right now. The problem is that
> content providers can't control the forward relays, 

So take the relays out of the path by putting up a 6to4 router and a 2002::
prefix address on the content servers. Longest match will cause 6to4
connected systems to prefer that prefix while native connected systems will
prefer the current prefix. The resulting IPv4 path will be exactly what it
is today door-to-door. Forcing traffic through a third party by holding to a
purity principle for dns, and then complaining about the results is not
exactly the most productive thing one could do.

> or protocol 41
> filtering that's out in the wild. 

Putting 2002:: in dns will not fix this, but it is not clear to me where
this comes from. The argument is that enterprise firewalls are blocking it,
but that makes no sense because many/most enterprises are in 1918 space so
6to4 will not be attempted to begin with, and for those that have public
space internally the oft-cited systems that are domain members will have
6to4 off by default. To get them to turn it on would require the IT staff to
explicitly enable it for the end systems but then turn around and block it
at the firewall ... Not exactly a likely scenario.

The most likely source of public space for non-domain joined systems would
be universities, but no one that is complaining about protocol 41 filtering
has shown that the source addresses are coming from those easily
identifiable places. 

That leaves the case of networks that use public addresses internally, but
nat those at the border. This would confuse the client into thinking 6to4
should be viable, only to have protocol 41 blocked by the nat. These
networks do exist, and the only way to detect them would be to have an
instrumented 6to4 router or relay that compared the IPv4-bits in the source
address between the two headers. They don't have to match exactly because a
6to4 router would use its address as a source, but if the embedded bits said
25.25.25.25 while the external IPv4 header said 18.25.25.25 one might
suspect there was a nat in the path.

> Also, not all breakage is caused by
> 6to4, there are still quite a few cases of other breakage, and *that*
> is
> what's pushing us towards whitelisting.
> 
> See:
> http://www.getipv6.info/index.php/Customer_problems_that_could_occur
> 
> :: > And can we please stop pretending that this is an easy thing for
> the content providers to do? Big content networks like Yahoo! have
> dozens of POPs, and hundreds of address ranges. The IETF is *still*
> working on tweaking 6to4, so even if the content providers put up these
> relays today, and somehow figure out how to test them, their work is
> not done.

Then stop focusing on the relays, as they are only necessary to get between
the 6to4 prefix and the non-6to4 prefix address ranges. They are explicitly
not in the path of any 6to4 -> 6to4 conversation.

In any case the relays should not be the responsibility of the content side,
they are rightly the responsibility of the access networks who wouldn't need
to deploy them if they had native access in place. The 6rd hack is nothing
more than 6to4 in a different prefix to get around the one-liner that should
be ignored in the original RFC that said to only publish the /16 into IPv6
bgp. I can already hear the screams about routing table, but there is no
difference between the impact of a 6rd specific announcement and a
deaggregate of 2002::  

> :: >
> :: It is relatively easy to do, even with dozens of POPs. There isn't
> anything special you
> :: have to do for the hundreds of address ranges, really, so I don't
> buy that as being a
> :: meaningful part of the argument.
> 
> I think this is a red herring - return relays were never *the* problem.
> 
> :: > I do agree with you that pointing fingers at this stage is really
> not helpful. I continue to maintain that being supportive of those
> content networks that are willing to wade in is the right answer.
> :: >
> :: Agreed, but, it's also important to point out when they're starting
> to swim in directions
> :: that are counterproductive, such as having help sites that advise
> users to turn off
> :: IPv6 with fixing their IPv6 capabilities as a secondary option.
> 
> "We recommend disabling IPv6 or seeking assistance in order to fix your
> system's IPv6 configuration through your ISP or computer manufacturer"

It would be most helpful to rearrange that statement to take the focus off
of 'disabling'. When the first thing people see is turn it off they will do
that rather than get to the point that there might be something that is
fixable.

> 
> So, your problem is that a help page gives the user 2 options,
> the first one of them being a quick and easy fix that a user can do
> himself in less then a minute, and suggesting contacting the ISP or
> manufacturer *second* (and possibly spending quite a bit of time on
> hold/troubleshooting, and then saying "screw it")?!?
> 
> Honestly, I think the people who want ipv6 to work, and are willing and
> capable to troubleshoot it, will; and those who don't will just
> turn it off... Seems like the right outcome to me..

I agree with your assessment, but the way the statement is worded make it
look like you would rather have people turn it off. If my wife read that,
should would be telling me that Yahoo said that the recommendation is to
turn it off, not that something might need fixing. 

Tony

> 
> -igor
> (man, did I pick a good day to be on an airplane, or what)





From lists at internetpolicyagency.com  Tue May 10 09:08:41 2011
From: lists at internetpolicyagency.com (Roland Perry)
Date: Tue, 10 May 2011 15:08:41 +0100
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w@mail.gmail.com>
Message-ID: <fOTexpPpbUyNFANV@perry.co.uk>

In article <BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w at mail.gmail.com>, chip 
<chip.gwyn at gmail.com> writes

>Interesting, especially after this:
>
>http://torrentfreak.com/ip-address-not-a-person-bittorrent-case-judge-says-110503/

It depends whether you are suing the subscriber or the downloader (maybe 
both can be liable in some cases). Also whether the subscriber was 
running an open Wifi (normally not recommended), which is a matter of 
evidential fact to be explored in each particular case.

>On Tue, May 10, 2011 at 9:07 AM, Marshall Eubanks <tme at multicasttech.com> wrote:
>> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
>> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>>
>> I thought that there might be some interest in the list of these addresses :
>>
>> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
>>
>> If you have IP addresses on this list, expect to receive papers shortly.
>>
>> Here is more of the backstory :
>>
>> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>>
>> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
>> more of this until some sense returns to the legal system.

Attempts a bit like this have come unstuck in the UK. Search for 
"Davenport Lyons" and "ACS Law"
-- 
Roland Perry



From straterra at fuhell.com  Tue May 10 09:12:57 2011
From: straterra at fuhell.com (Thomas York)
Date: Tue, 10 May 2011 10:12:57 -0400
Subject: VPN tunnels between US and China dropping/slow
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>

At my current place of business, we have several manufacturing plants in
China as well as the United States. All of the plants have an OVPN tunnel to
a datacenter here in Indianapolis which connect all of the plants. Our China
plants pay for the basic 3mbit/3mbit fiber internet connections. I've had a
hell of a time keeping their tunnels up. They're running on port 443 over
TCP now, but every month or so the tunnel degrades so badly I have to switch
the port. I've recently tried tunneling OVPN (UDP) over a GRE tunnel and
that has worked for a few months..but even now is degrading. The interesting
thing is that ONLY the tunnel traffic gets degraded. I've replaced all of
the equipment on both ends of all of the VPN tunnels, which changed nothing.

 

Currently, we're talking to Time Warner and some of our customers who have
plants in China to see what solutions they're using to get around this kind
of issue. One thing we are hearing quite often is that they're using a MPLS
based connection to Hong Kong, then going to the USA from there. We're happy
to try this, but due to cost issues we're (management mostly) considering
this a last resort option. Are there any other options maybe some of you
have to fixing this issue? Thanks

 

Thomas York

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6400 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110510/a8d212ea/attachment.bin>

From scott.brim at gmail.com  Tue May 10 09:15:43 2011
From: scott.brim at gmail.com (Scott Brim)
Date: Tue, 10 May 2011 10:15:43 -0400
Subject: 23,000 IP addresses
In-Reply-To: <7F80DD92-98A4-45CC-A4BE-CAB20C12D286@ukbroadband.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<7F80DD92-98A4-45CC-A4BE-CAB20C12D286@ukbroadband.com>
Message-ID: <BANLkTimZrOuo6xyVYa_jdNOytB-PddiMYg@mail.gmail.com>

On Tue, May 10, 2011 at 09:42, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
> So are they basing this on you downloading it or on making it available for others?

Without knowing the details, I wouldn't assume any such level of
competence or integrity.  It could just be a broad witch hunt.

> Apologies for the top post...

Never apologize for top posting, it just starts the flame war all over again.



From morrowc.lists at gmail.com  Tue May 10 09:22:03 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 10 May 2011 10:22:03 -0400
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTimZrOuo6xyVYa_jdNOytB-PddiMYg@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<7F80DD92-98A4-45CC-A4BE-CAB20C12D286@ukbroadband.com>
	<BANLkTimZrOuo6xyVYa_jdNOytB-PddiMYg@mail.gmail.com>
Message-ID: <BANLkTimuxBJmf_YWrjqDmHYtoK-oD6M-CQ@mail.gmail.com>

On Tue, May 10, 2011 at 10:15 AM, Scott Brim <scott.brim at gmail.com> wrote:
> On Tue, May 10, 2011 at 09:42, Leigh Porter
> <leigh.porter at ukbroadband.com> wrote:
>> So are they basing this on you downloading it or on making it available for others?
>
> Without knowing the details, I wouldn't assume any such level of
> competence or integrity. ?It could just be a broad witch hunt.

I know of a decent sized global ISP that ran (runs?) a large darknet
that was the equivalent of a few /16's routed to a fbsd host running
'tcpdump' (a tad more complex, but essentially this). BayTSP (one of
the 'make legal threats for the mpaa/riaa' firms) sent ~2k notes to
the ISP about downloaders on these ips.

Looking at netflow data (sample 1:1 on that interface) they had
portscanned (from ip space registered in their name) each address in
the range and sent subpoena-material to all ips that they thought they
got a response from.

At least baytsp got theirs? (money I mean)



From MDikkema at postmedia.com  Tue May 10 09:28:25 2011
From: MDikkema at postmedia.com (Dikkema, Michael (Business Technology))
Date: Tue, 10 May 2011 09:28:25 -0500
Subject: L3 ECMP over links with different RTT
Message-ID: <4DD46B838E59A647A9FE326E7552F8361A98E43C4F@WPGMSXMBX02.ca.canwest.com>

Hi,

Is it foolish to build a L3 ECMP connection between 2 iBGP routers with one of the links having a 50% longer RTT? We're building fiber between 2 locations with the option of going both north and south around the great lakes. One link will have a 20ms RTT and one with around 35ms. The majority of our peering and transit will be on one side, with the enterprise datacenter on the other.

The design right now would use OSPF as an IGP over these links with iBGP peering on loopbacks. Both links are 1G.

Any thoughts on doing this different/better would be appreciated.

Thanks.



From nenolod at systeminplace.net  Tue May 10 09:35:33 2011
From: nenolod at systeminplace.net (William Pitcock)
Date: Tue, 10 May 2011 09:35:33 -0500
Subject: VPN tunnels between US and China dropping/slow
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
Message-ID: <20110510093533.20e357c6@petrie>

On Tue, 10 May 2011 10:12:57 -0400
"Thomas York" <straterra at fuhell.com> wrote:

> At my current place of business, we have several manufacturing plants
> in China as well as the United States. All of the plants have an OVPN
> tunnel to a datacenter here in Indianapolis which connect all of the
> plants. Our China plants pay for the basic 3mbit/3mbit fiber internet
> connections. I've had a hell of a time keeping their tunnels up.
> They're running on port 443 over TCP now, but every month or so the
> tunnel degrades so badly I have to switch the port. I've recently
> tried tunneling OVPN (UDP) over a GRE tunnel and that has worked for
> a few months..but even now is degrading. The interesting thing is
> that ONLY the tunnel traffic gets degraded. I've replaced all of the
> equipment on both ends of all of the VPN tunnels, which changed
> nothing.
> 
> 

This is actually caused by the Chinese firewall trying to reset the VPN
connection.  The reason why they are doing this is because people are
buying VPN services to get around the firewall.  As of late, they have
become a lot more clever about VPN blocking.

> 
> Currently, we're talking to Time Warner and some of our customers who
> have plants in China to see what solutions they're using to get
> around this kind of issue. One thing we are hearing quite often is
> that they're using a MPLS based connection to Hong Kong, then going
> to the USA from there. We're happy to try this, but due to cost
> issues we're (management mostly) considering this a last resort
> option. Are there any other options maybe some of you have to fixing
> this issue? Thanks

The only option is to get transport to an endpoint outside China, e.g.
in Hong Kong.

William



From morrowc.lists at gmail.com  Tue May 10 09:34:41 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 10 May 2011 10:34:41 -0400
Subject: VPN tunnels between US and China dropping/slow
In-Reply-To: <20110510093533.20e357c6@petrie>
References: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
	<20110510093533.20e357c6@petrie>
Message-ID: <BANLkTimTbBSRj=CxJqUWt5_mC_vHYrmK6A@mail.gmail.com>

On Tue, May 10, 2011 at 10:35 AM, William Pitcock
<nenolod at systeminplace.net> wrote:

>> Currently, we're talking to Time Warner and some of our customers who
>> have plants in China to see what solutions they're using to get
>> around this kind of issue. One thing we are hearing quite often is
>> that they're using a MPLS based connection to Hong Kong, then going
>> to the USA from there. We're happy to try this, but due to cost
>> issues we're (management mostly) considering this a last resort
>> option. Are there any other options maybe some of you have to fixing
>> this issue? Thanks
>
> The only option is to get transport to an endpoint outside China, e.g.
> in Hong Kong.

or just tunnel without a protocol... or spread-spectrum across more
than one endpoint set



From nenolod at systeminplace.net  Tue May 10 09:37:23 2011
From: nenolod at systeminplace.net (William Pitcock)
Date: Tue, 10 May 2011 09:37:23 -0500
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTimuxBJmf_YWrjqDmHYtoK-oD6M-CQ@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<7F80DD92-98A4-45CC-A4BE-CAB20C12D286@ukbroadband.com>
	<BANLkTimZrOuo6xyVYa_jdNOytB-PddiMYg@mail.gmail.com>
	<BANLkTimuxBJmf_YWrjqDmHYtoK-oD6M-CQ@mail.gmail.com>
Message-ID: <20110510093723.0a63a48f@petrie>

On Tue, 10 May 2011 10:22:03 -0400
Christopher Morrow <morrowc.lists at gmail.com> wrote:

> On Tue, May 10, 2011 at 10:15 AM, Scott Brim <scott.brim at gmail.com>
> wrote:
> > On Tue, May 10, 2011 at 09:42, Leigh Porter
> > <leigh.porter at ukbroadband.com> wrote:
> >> So are they basing this on you downloading it or on making it
> >> available for others?
> >
> > Without knowing the details, I wouldn't assume any such level of
> > competence or integrity. ?It could just be a broad witch hunt.
> 
> I know of a decent sized global ISP that ran (runs?) a large darknet
> that was the equivalent of a few /16's routed to a fbsd host running
> 'tcpdump' (a tad more complex, but essentially this). BayTSP (one of
> the 'make legal threats for the mpaa/riaa' firms) sent ~2k notes to
> the ISP about downloaders on these ips.
> 
> Looking at netflow data (sample 1:1 on that interface) they had
> portscanned (from ip space registered in their name) each address in
> the range and sent subpoena-material to all ips that they thought they
> got a response from.
> 
> At least baytsp got theirs? (money I mean)
> 

Do you have any links to evidence of this?  I would love to just be
able to automatically throw BayTSP mails in the garbage, but I can't
just blindly do it if there is any chance of them being legitimate.

William



From iljitsch at muada.com  Tue May 10 09:37:08 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 10 May 2011 16:37:08 +0200
Subject: L3 ECMP over links with different RTT
In-Reply-To: <4DD46B838E59A647A9FE326E7552F8361A98E43C4F@WPGMSXMBX02.ca.canwest.com>
References: <4DD46B838E59A647A9FE326E7552F8361A98E43C4F@WPGMSXMBX02.ca.canwest.com>
Message-ID: <7BB25957-1B2F-477C-AE04-1D3DD6C538F2@muada.com>

On 10 mei 2011, at 16:28, Dikkema, Michael (Business Technology) wrote:

> Is it foolish to build a L3 ECMP connection between 2 iBGP routers with one of the links having a 50% longer RTT?

No problem at all as long as you don't do per-packet load balancing but something that makes sure a single flow only goes over a single link. There are many ways to skin that particular cat, best practice is based on the 5-tuple (source and dest addresses and ports and the protocol number) which will give you the best chance of having a similar load on both links as long as you have at least some 1000 flows at any given time. With less granular load balancing there's a much bigger risk that one link will be full and the other more or less idle unless you have very, very many flows. You may want to use VLANs so you can load balance some stuff as per the above and manually balance some other stuff to go over the faster link.


From michael.holstein at csuohio.edu  Tue May 10 09:38:20 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Tue, 10 May 2011 10:38:20 -0400
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <4DC94DDC.4000809@csuohio.edu>


> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
>   

The dates in the timestamps are back in February. We deleted those logs
"..in the regular course of business.."
a LONG TIME AGO.

If you didn't do that, you really ought to ask yourself why.

Regards,

Michael Holstein
Information Security Administrator
Cleveland State University



From Valdis.Kletnieks at vt.edu  Tue May 10 09:36:40 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 10 May 2011 10:36:40 -0400
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Tue, 10 May 2011 02:17:46 EDT."
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
Message-ID: <9099.1305038200@localhost>

On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:

> The time for finger-pointing is over, period, all we are all trying to do 
> now is figure out how to deal with the present (sucky) situation. The 
> current reality is that for a non-insignificant percentage of users when 
> you enable dual-stack, they are gong to drop off the face of the planet. 
> Now, for *you*, 0.026% may be insignificant (and, standalone, that number 
> is insignificant), but for a global content provider that has ~700M users, 
> that's 182 *thousand* users that *you*, *through your actions* just took 
> out.. 182,000 - that is *not* insignificant

At any given instant, there's a *lot* more than 182,000 users who are cut off
due to various *IPv4* misconfigurations and issues.

Let's keep a sense of proportion, shall we?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110510/0f13bcd2/attachment.bin>

From morrowc.lists at gmail.com  Tue May 10 09:38:21 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 10 May 2011 10:38:21 -0400
Subject: 23,000 IP addresses
In-Reply-To: <20110510093723.0a63a48f@petrie>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<7F80DD92-98A4-45CC-A4BE-CAB20C12D286@ukbroadband.com>
	<BANLkTimZrOuo6xyVYa_jdNOytB-PddiMYg@mail.gmail.com>
	<BANLkTimuxBJmf_YWrjqDmHYtoK-oD6M-CQ@mail.gmail.com>
	<20110510093723.0a63a48f@petrie>
Message-ID: <BANLkTinVpsj_-R2VepNh0XqF+pJXy2_EMw@mail.gmail.com>

On Tue, May 10, 2011 at 10:37 AM, William Pitcock
<nenolod at systeminplace.net> wrote:
> On Tue, 10 May 2011 10:22:03 -0400
> Christopher Morrow <morrowc.lists at gmail.com> wrote:
>> At least baytsp got theirs? (money I mean)
>>
>
> Do you have any links to evidence of this? ?I would love to just be
> able to automatically throw BayTSP mails in the garbage, but I can't
> just blindly do it if there is any chance of them being legitimate.

sadly I do not have evidence anymore... I do know that the isp
essentially stopped replying to baytsp though. some form of monitoring
netflow on your network + matching baytsp requests against that
pattern would likely be enough I suspect (ask lawyer-cat of course)

-chris



From mike at sentex.net  Tue May 10 09:39:20 2011
From: mike at sentex.net (Mike Tancsa)
Date: Tue, 10 May 2011 10:39:20 -0400
Subject: VPN tunnels between US and China dropping/slow
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
Message-ID: <4DC94E18.5070608@sentex.net>

On 5/10/2011 10:12 AM, Thomas York wrote:
> At my current place of business, we have several manufacturing plants in
> China as well as the United States. All of the plants have an OVPN tunnel to
> a datacenter here in Indianapolis which connect all of the plants. Our China
> plants pay for the basic 3mbit/3mbit fiber internet connections. I've had a
> hell of a time keeping their tunnels up. They're running on port 443 over
> TCP now, but every month or so the tunnel degrades so badly I have to switch
> the port. I've recently tried tunneling OVPN (UDP) over a GRE tunnel and

Perhaps a DPI issue ?  We make use of OpenVPN a lot here.  When the
local ILEC started rolling out their DPI boxes, our VPN traffic was
initially identified as bit torrent traffic and was being tampered with.
 Of course they said that was impossible... It took a good month before
I was able to get to the right people to actually look at the pcaps that
demonstrated the issue.  I setup an openvpn tunnel between the two
impacted sites (A,B)

>From A, I would do a straight up icmp ping to B. It would get to the
other side 100% clean.

At the same, time, I would do a ping inside the VPN tunnel.  It would
show dropped packets.

I then used hping to generate UDP packets of the same size or bigger of
the VPN packets, but with all FF as the payload, so it didnt look like
anything to the DPI boxes. This too would get to the other side 100% of
the time.  But the VPN UDP packets would experience loss.  The DPI
vendor then made some patches and/or config changes to stop messing up
our traffic and we have been ok since.

Not sure what you can do on the China side to test things, but perhaps
setup an OpenVPN instance in one of those free test instances in Amazon
and see if you see the loss from there to China.


	---Mike

-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/



From blake at ispn.net  Tue May 10 09:45:06 2011
From: blake at ispn.net (Blake Hudson)
Date: Tue, 10 May 2011 09:45:06 -0500
Subject: Cent OS migration
In-Reply-To: <20110509175411.199f4c87@petrie>
References: <20110509204536.779081CC09@ptavv.es.net>	<201105091714.06966.lowen@pari.edu>
	<20110509175411.199f4c87@petrie>
Message-ID: <4DC94F72.9010503@ispn.net>



William Pitcock wrote:
> Anyway, I was just wondering what the general consensus of NANOG is
> regarding CentOS vs Scientific Linux.  SL generally has faster security
> updates and people are *paid* to work on it fulltime.  CentOS on the
> other hand is supported out-of-the-box by most software.
>
> William

The two teams have different goals. Scientific Linux is designed to
create a common install base for labs. Which helps ensure repeatable
results and reduces the need for schools to develop and maintain their
own independent OS/software projects. SL uses RHEL as a base, but has a
different build environment, and may build against different versions of
libraries, as well as include packages which add or change functionality.

The goal of CentOS is to create a 100% compatible version of RHEL. Cent
tries to replicate the build environment of RHEL as closely as possible.
This ensures 100% compatible programs - bugs, regressions, and all.

For most, I suspect this difference in philosophy results in negligible
difference. However, some may need this. Especially if they test with
CentOS, and use RHEL in production, relying on the two to function and
perform identically.


I support CentOS, and hope the project resolves some of these problems
that have been lingering for the last year. As long as there are
individuals who support the project, there will still be a CentOS.

--Blake



From luis.marta at gmail.com  Tue May 10 09:53:34 2011
From: luis.marta at gmail.com (Luis Marta)
Date: Tue, 10 May 2011 15:53:34 +0100
Subject: Fwd: 23,000 IP addresses
In-Reply-To: <BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC94DDC.4000809@csuohio.edu>
	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
Message-ID: <BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>

 On Tue, May 10, 2011 at 3:38 PM, Michael Holstein <
michael.holstein at csuohio.edu> wrote:

>
> >
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
> >
>
> The dates in the timestamps are back in February. We deleted those logs
> "..in the regular course of business.."
> a LONG TIME AGO.
>
> If you didn't do that, you really ought to ask yourself why.
>
> Regards,
>
> Michael Holstein
> Information Security Administrator
> Cleveland State University
>


In the EU you have Directive 2006/24/EC:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:105:0054:0063:EN:PDF

Article 6 - Periods of retention
Member States shall ensure that the categories of data specified in Article
5 are retained for periods of not less than six months and not more than two
years from the date of the communication.

Article 5 - Categories of data to be retained
1. Member States shall ensure that the following categories of data are
retained under this Directive:
(a) data necessary to trace and identify the source of a communication:
(...) the name and address of the subscriber or registered user to whom an
Internet Protocol (IP) address, user ID or telephone number was allocated at
the time of the communication;


Each member state creates its own law, according to the directive. In
Portugal, you have to retain the data for one year.

Best Regards,
Lu?s Marta.


From tme at americafree.tv  Tue May 10 11:01:54 2011
From: tme at americafree.tv (Marshall Eubanks)
Date: Tue, 10 May 2011 12:01:54 -0400
Subject: 23,000 IP addresses
In-Reply-To: <fOTexpPpbUyNFANV@perry.co.uk>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w@mail.gmail.com>
	<fOTexpPpbUyNFANV@perry.co.uk>
Message-ID: <19793C47-C26E-4400-9514-A96928088951@americafree.tv>


On May 10, 2011, at 10:08 AM, Roland Perry wrote:

> In article <BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w at mail.gmail.com>, chip <chip.gwyn at gmail.com> writes
> 
>> Interesting, especially after this:
>> 
>> http://torrentfreak.com/ip-address-not-a-person-bittorrent-case-judge-says-110503/
> 
> It depends whether you are suing the subscriber or the downloader (maybe both can be liable in some cases). Also whether the subscriber was running an open Wifi (normally not recommended), which is a matter of evidential fact to be explored in each particular case.
> 

And, perhaps most critically, which judge you come before. (It will take a while, and maybe a visit to the Supreme Court, before you can
expect legal consistency here.) 

Note also that these generally do not go to trial.

Regards
Marshall 


>> On Tue, May 10, 2011 at 9:07 AM, Marshall Eubanks <tme at multicasttech.com> wrote:
>>> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
>>> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week.
>>> 
>>> I thought that there might be some interest in the list of these addresses :
>>> 
>>> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
>>> 
>>> If you have IP addresses on this list, expect to receive papers shortly.
>>> 
>>> Here is more of the backstory :
>>> 
>>> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
>>> 
>>> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
>>> more of this until some sense returns to the legal system.
> 
> Attempts a bit like this have come unstuck in the UK. Search for "Davenport Lyons" and "ACS Law"
> -- 
> Roland Perry
> 
> 




From Brian.Rettke at cableone.biz  Tue May 10 11:09:50 2011
From: Brian.Rettke at cableone.biz (Rettke, Brian)
Date: Tue, 10 May 2011 09:09:50 -0700
Subject: L3 ECMP over links with different RTT
In-Reply-To: <7BB25957-1B2F-477C-AE04-1D3DD6C538F2@muada.com>
References: <4DD46B838E59A647A9FE326E7552F8361A98E43C4F@WPGMSXMBX02.ca.canwest.com>
	<7BB25957-1B2F-477C-AE04-1D3DD6C538F2@muada.com>
Message-ID: <96CA80CDCD822B4F9B41FB3A109C9359A444AFCA4C@E2K7MAILBOX1.corp.cableone.net>

Per flow is generally the best method, and allows the employ of CEF (or the equivalent).

I've done load balancing in this method, and in others I've configured active/standby for the reasons specified.  It depends on whether you need true link redundancy more than the latency will affect traffic.

Another option, of course, is to apply PBR to get your low latency queues to use the preferred link. I've done that as well, using EEM to remove the forced next hop if the interface drops.

Sincerely,

Brian A . Rettke
RHCT, CCDP, CCNP, CCIP
Network Engineer, CableONE Internet Services

-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch at muada.com]
Sent: Tuesday, May 10, 2011 7:37 AM
To: Dikkema, Michael (Business Technology)
Cc: nanog at nanog.org
Subject: Re: L3 ECMP over links with different RTT

On 10 mei 2011, at 16:28, Dikkema, Michael (Business Technology) wrote:

> Is it foolish to build a L3 ECMP connection between 2 iBGP routers with one of the links having a 50% longer RTT?

No problem at all as long as you don't do per-packet load balancing but something that makes sure a single flow only goes over a single link. There are many ways to skin that particular cat, best practice is based on the 5-tuple (source and dest addresses and ports and the protocol number) which will give you the best chance of having a similar load on both links as long as you have at least some 1000 flows at any given time. With less granular load balancing there's a much bigger risk that one link will be full and the other more or less idle unless you have very, very many flows. You may want to use VLANs so you can load balance some stuff as per the above and manually balance some other stuff to go over the faster link.



From igor at gashinsky.net  Tue May 10 11:32:53 2011
From: igor at gashinsky.net (Igor Gashinsky)
Date: Tue, 10 May 2011 12:32:53 -0400 (EDT)
Subject: Yahoo and IPv6
In-Reply-To: <9099.1305038200@localhost>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net> <4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>           
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
Message-ID: <Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>

On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:

:: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
:: 
:: > The time for finger-pointing is over, period, all we are all trying to do 
:: > now is figure out how to deal with the present (sucky) situation. The 
:: > current reality is that for a non-insignificant percentage of users when 
:: > you enable dual-stack, they are gong to drop off the face of the planet. 
:: > Now, for *you*, 0.026% may be insignificant (and, standalone, that number 
:: > is insignificant), but for a global content provider that has ~700M users, 
:: > that's 182 *thousand* users that *you*, *through your actions* just took 
:: > out.. 182,000 - that is *not* insignificant
:: 
:: At any given instant, there's a *lot* more than 182,000 users who are cut off
:: due to various *IPv4* misconfigurations and issues.

Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
and you are asking *me* to break them through *my* actions. Sorry, that's 
simply too many to break for me, without a damn good reason to do so.

Doing that on world ipv6 day, when there is a lot of press, and most other 
large content players doing the same, *is* a good reason - it may actually 
has a shot of accomplishing some good, since it may get those users to 
realize that they are broken, and fix their systems, but outside of flag 
day, if I enabled AAAA by default for all users, all I'm going to do is 
send those "broken" users to my competitors who chose not to enable AAAA 
on their sites. 

This is why I think automatic, measurement-based whitelisting/blacklisting 
to minimize the collateral damage of enabling AAAA is going to be 
inevitable (with the trigger set to something around 99.99%), and about 
the only way we see wide-scale IPv6 adoption by content players, outside 
events like world ipv6 day.

-igor



From igor at gashinsky.net  Tue May 10 11:37:49 2011
From: igor at gashinsky.net (Igor Gashinsky)
Date: Tue, 10 May 2011 12:37:49 -0400 (EDT)
Subject: Yahoo and IPv6
In-Reply-To: <A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
Message-ID: <Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>

On Tue, 10 May 2011, Iljitsch van Beijnum wrote:

:: On 9 mei 2011, at 21:40, Tony Hain wrote:
:: 
:: >> Publicly held corporations are responsible to their shareholders to get
:: >> eyeballs on their content. *That* is their job, not promoting cool new
:: >> network tech. When you have millions of users hitting your site every
:: >> day losing 1/2000 is a large chunk of revenue.
:: 
:: Nonsense. 0.05% is well below the noise margin for anything that involves humans.

I assure you, it is not. 0.005% might be "in the noise", but 0.05% is 
quite measurable given a large enough audience.

:: >> The fact that the big
:: >> players are doing world IPv6 day at all should be celebrated, promoted,
:: >> and we should all be ready to take to heart the lessons learned from
:: >> it.
:: 
:: I applaud the first step, but I'm bothered by the fact that no second step is planned.

Just because it's not public, doesn't mean that it hasn't been planned :)

Most of us want to see the data that we get from the first step, before 
making the decision on which second step to take, I'm sure most people 
can understand that.

-igor



From lists at internetpolicyagency.com  Tue May 10 11:45:50 2011
From: lists at internetpolicyagency.com (Roland Perry)
Date: Tue, 10 May 2011 17:45:50 +0100
Subject: 23,000 IP addresses
In-Reply-To: <fOTexpPpbUyNFANV@perry.co.uk>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<BANLkTimA-ZpM3bKXoDtxMgXySJ_FKYS+0w@mail.gmail.com>
	<fOTexpPpbUyNFANV@perry.co.uk>
Message-ID: <g4mxsAf+uWyNFAIk@perry.co.uk>

In article <fOTexpPpbUyNFANV at perry.co.uk>, Roland Perry <lists at internetp
olicyagency.com> writes
>Attempts a bit like this have come unstuck in the UK. Search for
>"Davenport Lyons" and "ACS Law"

And this ruling (and fine) have appeared from the UK's privacy regulator
today (note especially that the fine would have been ~$300k if the
company was still trading):

<http://www.ico.gov.uk/~/media/documents/library/Data_Protection/Notices
/acs_law_monetary_penalty_notice.pdf>
-- 
Roland Perry



From asr at latency.net  Tue May 10 12:10:46 2011
From: asr at latency.net (Adam Rothschild)
Date: Tue, 10 May 2011 13:10:46 -0400
Subject: VPN tunnels between US and China dropping/slow
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
Message-ID: <BANLkTi=zTySGA9QAhrpQFzdHM15im77WEA@mail.gmail.com>

Realize also that China Telecom is congested both internally and on
certain peering interfaces.

While DPI is a likely culprit, be sure to not overlook a good
old-fashioned inability to manage capacity, combined with certain
hashing algorithms...

-a



From joelja at bogus.com  Tue May 10 12:17:32 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 10 May 2011 10:17:32 -0700
Subject: VPN tunnels between US and China dropping/slow
In-Reply-To: <BANLkTi=zTySGA9QAhrpQFzdHM15im77WEA@mail.gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAF14xRJYlm1EkOxD1AqQStBCgQAAEAAAAColMwoxwv1Dm+TBnWagJ14BAAAAAA==@fuhell.com>
	<BANLkTi=zTySGA9QAhrpQFzdHM15im77WEA@mail.gmail.com>
Message-ID: <4DC9732C.20708@bogus.com>

On 5/10/11 10:10 AM, Adam Rothschild wrote:
> Realize also that China Telecom is congested both internally and on
> certain peering interfaces.
> 
> While DPI is a likely culprit, be sure to not overlook a good
> old-fashioned inability to manage capacity, combined with certain
> hashing algorithms...

if you're measuring the end-to-end path you'll likely see evidenced of
the latency climbing on a near daily cycle.

my median rtt from the us east coast is 268ms sometimes it's north of
370 with essentially the same loss properties.

> -a
> 




From straterra at fuhell.com  Tue May 10 12:19:34 2011
From: straterra at fuhell.com (Thomas York)
Date: Tue, 10 May 2011 13:19:34 -0400
Subject: VPN tunnels between US and China dropping/slow
Message-ID: <kgp8jcdbf8l2v7os9gpvs8m4.1305047952247@email.android.com>

I tried to tell my bosses that and I got a blank stare.

-- Thomas York

Adam Rothschild <asr at latency.net> wrote:

>Realize also that China Telecom is congested both internally and on
>certain peering interfaces.
>
>While DPI is a likely culprit, be sure to not overlook a good
>old-fashioned inability to manage capacity, combined with certain
>hashing algorithms...
>
>-a

From deepak at ai.net  Tue May 10 12:28:10 2011
From: deepak at ai.net (Deepak Jain)
Date: Tue, 10 May 2011 13:28:10 -0400
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>

> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena
> ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of; subpoenas are expected
> to go out this week.
> 
> I thought that there might be some interest in the list of these
> addresses :
> 
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddre
> sses.pdf

This will stop when a 80+ yr old is taken to court over a download her 8 year old grandkid might have made when visiting for the weekend. The media will make the case that technologists can't.

For examples, see the RIAA's attempts and more recently the criminal investigations of child porn downloads from unsecured access points. From what I understand (or wildly guess) is that ISPs with remote diagnostic capabilities are being asked if their provided access point is secure or unsecure BEFORE they serve their warrants to avoid further embarrassments. [It'll probably take another 6 months and more goofs before they realize that customers are perfectly capable of poorly installing their own access points behind ISP provided gear].

The torrent stuff is fundamentally no different in that a single IP can and is shared by lots of people as common practice and the transient nature of it (e.g. airport access point, starbucks, etc) reasonably makes the lawyer's case much, much harder. 

There is a real theft/crime here in many cases, but whether there is actually any value in prosecution of movie downloads will depend... but most likely, the outcome will be iMovies or similar and the movie industry will shrink the way the music industry has.

DJ



From smb at cs.columbia.edu  Tue May 10 12:56:51 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 10 May 2011 13:56:51 -0400
Subject: 23,000 IP addresses
In-Reply-To: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
Message-ID: <ED76A11A-F4AA-4525-AEE7-C4747E300CAE@cs.columbia.edu>


On May 10, 2011, at 9:07 11AM, Marshall Eubanks wrote:

> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena ISPs over 23,000 alleged downloads of some
> Sylvester Stallone movie I have never heard of; subpoenas are expected to go out this week. 
> 
> I thought that there might be some interest in the list of these addresses :
> 
> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddresses.pdf
> 
> If you have IP addresses on this list, expect to receive papers shortly. 

Has anyone converted that file to some useful format like ASCII?  You know
-- something greppable?

> 
> Here is more of the backstory :
> 
> http://www.wired.com/threatlevel/2011/05/biggest-bittorrent-case/
> 
> This is turning into quite a legal racket (get order $ 3000 for sending a threatening letter); I expect to see a lot
> more of this until some sense returns to the legal system. 
> 
There's amazing slime behind some similar efforts -- in another case,
of people charged with downloading "Nude Nuns with Big Guns" (yes, you
read that correctly), there are two different that each claim the rights
to the movie and hence the right to sue (alleged) downloaders:
http://www.wired.com/threatlevel/2011/05/nude-nuns-brouhaha/

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From straterra at fuhell.com  Tue May 10 13:00:20 2011
From: straterra at fuhell.com (Thomas York)
Date: Tue, 10 May 2011 14:00:20 -0400
Subject: VPN tunnels between US and China dropping/slow
Message-ID: <rggb7ep6kyss4xjaacb3wjbb.1305050355315@email.android.com>

Yes. Every day at roughly 2AM EDT the latency climbs to 700ms+ with about 25% packet loss and fluctuates until about 6-7AM.

-- Thomas York

Joel Jaeggli <joelja at bogus.com> wrote:

>On 5/10/11 10:10 AM, Adam Rothschild wrote:
>> Realize also that China Telecom is congested both internally and on
>> certain peering interfaces.
>> 
>> While DPI is a likely culprit, be sure to not overlook a good
>> old-fashioned inability to manage capacity, combined with certain
>> hashing algorithms...
>
>if you're measuring the end-to-end path you'll likely see evidenced of
>the latency climbing on a near daily cycle.
>
>my median rtt from the us east coast is 268ms sometimes it's north of
>370 with essentially the same loss properties.
>
>> -a
>> 
>

From wschultz at bsdboy.com  Tue May 10 13:10:10 2011
From: wschultz at bsdboy.com (Wil Schultz)
Date: Tue, 10 May 2011 11:10:10 -0700
Subject: 23,000 IP addresses
In-Reply-To: <ED76A11A-F4AA-4525-AEE7-C4747E300CAE@cs.columbia.edu>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<ED76A11A-F4AA-4525-AEE7-C4747E300CAE@cs.columbia.edu>
Message-ID: <0BE48F1B-56F0-49AE-83BB-A63E66A5F365@bsdboy.com>

On May 10, 2011, at 10:56 AM, Steven Bellovin wrote:

> 
> On May 10, 2011, at 9:07 11AM, Marshall Eubanks wrote:
> 
> 
> Has anyone converted that file to some useful format like ASCII?  You know
> -- something greppable?
> 

I've converted it to ascii, but I don't have a place to host it.

I can send to anyone that would like it.

-wil 




From nanog-02 at jeremykister.com  Tue May 10 13:19:15 2011
From: nanog-02 at jeremykister.com (Jeremy Kister)
Date: Tue, 10 May 2011 14:19:15 -0400
Subject: .io registrar
Message-ID: <4DC981A3.7060402@jeremykister.com>

Does anyone know of a competent .io registrar who charges in the <= 
$75/yr area ?

I've been using tierra.net (domaindiscover.com) but they continually 
break my domains.

this year, although their website says my domain expires 4/2012, my 
domain stopped working today.  the .io servers aren't serving records, 
and nic.io says the domain expired 4/8/2011.

i got a hold of them this morning got a ticket -- but after 4 hours 
still no response.


also, although nic.io lists a bunch of .io registrars, when I called 
them they almost all say "we don't register .io" :D


-- 

Jeremy Kister
http://jeremy.kister.net./



From owen at delong.com  Tue May 10 13:22:54 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 10 May 2011 11:22:54 -0700
Subject: Yahoo and IPv6
In-Reply-To: <Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
Message-ID: <CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>


On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:

> On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:
> 
> :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
> :: 
> :: > The time for finger-pointing is over, period, all we are all trying to do 
> :: > now is figure out how to deal with the present (sucky) situation. The 
> :: > current reality is that for a non-insignificant percentage of users when 
> :: > you enable dual-stack, they are gong to drop off the face of the planet. 
> :: > Now, for *you*, 0.026% may be insignificant (and, standalone, that number 
> :: > is insignificant), but for a global content provider that has ~700M users, 
> :: > that's 182 *thousand* users that *you*, *through your actions* just took 
> :: > out.. 182,000 - that is *not* insignificant
> :: 
> :: At any given instant, there's a *lot* more than 182,000 users who are cut off
> :: due to various *IPv4* misconfigurations and issues.
> 
> Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
> and you are asking *me* to break them through *my* actions. Sorry, that's 
> simply too many to break for me, without a damn good reason to do so.
> 
In other words, Igor can't turn on AAAA records generally until there are
182,001 IPv6-only users that are broken from his lack of AAAA records.

Given IP address consumption rates in Asia and the lack of available IPv4
resources in Asia, with a traditional growth month to month of nearly
30 million IPv4 addresses consumed, I suspect it will not be long before
the 182,001 broken IPv6 users become relevant.

> Doing that on world ipv6 day, when there is a lot of press, and most other 
> large content players doing the same, *is* a good reason - it may actually 
> has a shot of accomplishing some good, since it may get those users to 
> realize that they are broken, and fix their systems, but outside of flag 
> day, if I enabled AAAA by default for all users, all I'm going to do is 
> send those "broken" users to my competitors who chose not to enable AAAA 
> on their sites. 
> 
Agreed. I think IPv6 day is a great plan for this very reason. I also hope that
a lot of organizations that try things out on IPv6 day will decide that the
brokenness that has been so hyped wasn't actually noticeable and then
leave their AAAA records in place. I do not expect Yahoo or Google to
be among them, but, hopefully a lot of other organizations will do so.

> This is why I think automatic, measurement-based whitelisting/blacklisting 
> to minimize the collateral damage of enabling AAAA is going to be 
> inevitable (with the trigger set to something around 99.99%), and about 
> the only way we see wide-scale IPv6 adoption by content players, outside 
> events like world ipv6 day.
> 
This will be interesting. Personally, I think it will be more along the lines
of when there are more IPv6 only eye-balls with broken IPv4 than there
are IPv4 eye-balls with broken IPv6, AAAA will become the obvious
solution.

In my opinion, this is just a matter of time and will happen much sooner than
I think most people anticipate.


Owen




From smb at cs.columbia.edu  Tue May 10 13:46:23 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 10 May 2011 14:46:23 -0400
Subject: 23,000 IP addresses
In-Reply-To: <0BE48F1B-56F0-49AE-83BB-A63E66A5F365@bsdboy.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<ED76A11A-F4AA-4525-AEE7-C4747E300CAE@cs.columbia.edu>
	<0BE48F1B-56F0-49AE-83BB-A63E66A5F365@bsdboy.com>
Message-ID: <EBF421FC-614A-4F39-97FA-80DA63B85282@cs.columbia.edu>


On May 10, 2011, at 2:10 10PM, Wil Schultz wrote:

> On May 10, 2011, at 10:56 AM, Steven Bellovin wrote:
> 
>> 
>> On May 10, 2011, at 9:07 11AM, Marshall Eubanks wrote:
>> 
>> 
>> Has anyone converted that file to some useful format like ASCII?  You know
>> -- something greppable?
>> 
> 
> I've converted it to ascii, but I don't have a place to host it.
> 
> I can send to anyone that would like it.
> 

Thanks.  I've uploaded it as https://www.cs.columbia.edu/~smb/23000.txt.gz and
https://www.cs.columbia.edu/~smb/23000-clean.txt.gz ; the latter has page breaks,
headers, etc., stripped out; nothing but data.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From michael.holstein at csuohio.edu  Tue May 10 13:49:46 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Tue, 10 May 2011 14:49:46 -0400
Subject: Fwd: 23,000 IP addresses
In-Reply-To: <BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC94DDC.4000809@csuohio.edu>	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
Message-ID: <4DC988CA.903@csuohio.edu>


> In the EU you have Directive 2006/24/EC:
>   

But I'm not, and neither are most of the ISPs in the linked document.

Regards,

Michael Holstein
Information Security Administrator
Cleveland State University



From mantel at gmail.com  Tue May 10 13:57:52 2011
From: mantel at gmail.com (Niall Kearney)
Date: Tue, 10 May 2011 19:57:52 +0100
Subject: .io registrar
In-Reply-To: <4DC981A3.7060402@jeremykister.com>
References: <4DC981A3.7060402@jeremykister.com>
Message-ID: <BANLkTineucQAZdejHZDgfirOagnWJF1Orw@mail.gmail.com>

Although its not in your price range ive found blacknight.ie to be reliable
for registering domians and they do .io but for 80 euro a year. If the
currency rates change it could be more viable for you.
On May 10, 2011 7:20 p.m., "Jeremy Kister" <nanog-02 at jeremykister.com>
wrote:
> Does anyone know of a competent .io registrar who charges in the <=
> $75/yr area ?
>
> I've been using tierra.net (domaindiscover.com) but they continually
> break my domains.
>
> this year, although their website says my domain expires 4/2012, my
> domain stopped working today. the .io servers aren't serving records,
> and nic.io says the domain expired 4/8/2011.
>
> i got a hold of them this morning got a ticket -- but after 4 hours
> still no response.
>
>
> also, although nic.io lists a bunch of .io registrars, when I called
> them they almost all say "we don't register .io" :D
>
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>


From owen at delong.com  Tue May 10 14:02:33 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 10 May 2011 12:02:33 -0700
Subject: 23,000 IP addresses
In-Reply-To: <4DC988CA.903@csuohio.edu>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC94DDC.4000809@csuohio.edu>	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
Message-ID: <8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>


On May 10, 2011, at 11:49 AM, Michael Holstein wrote:

> 
>> In the EU you have Directive 2006/24/EC:
>> 
> 
> But I'm not, and neither are most of the ISPs in the linked document.
> 
> Regards,
> 
> Michael Holstein
> Information Security Administrator
> Cleveland State University

In the US, I believe that CALEA requires you to have those records for 7 years.

Owen




From jblaum02 at gmail.com  Tue May 10 14:14:45 2011
From: jblaum02 at gmail.com (Jeff Blaum)
Date: Tue, 10 May 2011 12:14:45 -0700
Subject: .io registrar
In-Reply-To: <4DC981A3.7060402@jeremykister.com>
References: <4DC981A3.7060402@jeremykister.com>
Message-ID: <BANLkTins_XWZDr7d2LmTw_NgvqK-PNPAdA@mail.gmail.com>

Moniker.com ftw

On Tue, May 10, 2011 at 11:19 AM, Jeremy Kister
<nanog-02 at jeremykister.com>wrote:

> Does anyone know of a competent .io registrar who charges in the <= $75/yr
> area ?
>
> I've been using tierra.net (domaindiscover.com) but they continually break
> my domains.
>
> this year, although their website says my domain expires 4/2012, my domain
> stopped working today.  the .io servers aren't serving records, and nic.iosays the domain expired 4/8/2011.
>
> i got a hold of them this morning got a ticket -- but after 4 hours still
> no response.
>
>
> also, although nic.io lists a bunch of .io registrars, when I called them
> they almost all say "we don't register .io" :D
>
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
>
>


From santino.codispoti at gmail.com  Tue May 10 14:43:18 2011
From: santino.codispoti at gmail.com (Santino Codispoti)
Date: Tue, 10 May 2011 15:43:18 -0400
Subject: Gas Company?
In-Reply-To: <BANLkTind5s4=CbGobw2oSh5XrngdzOO-JA@mail.gmail.com>
References: <BANLkTind5s4=CbGobw2oSh5XrngdzOO-JA@mail.gmail.com>
Message-ID: <BANLkTineSUpidd7TW06SGGrWFnMYbVHRiA@mail.gmail.com>

I know this is a bit of an odd request but does anyone on the list
work at a Gas company such has BP or Mobile?



From smb at cs.columbia.edu  Tue May 10 14:44:31 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 10 May 2011 15:44:31 -0400
Subject: 23,000 IP addresses
In-Reply-To: <8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC94DDC.4000809@csuohio.edu>	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
Message-ID: <A69666F9-C0EC-4886-A551-26A3E7DE6938@cs.columbia.edu>


On May 10, 2011, at 3:02 33PM, Owen DeLong wrote:

> 
> On May 10, 2011, at 11:49 AM, Michael Holstein wrote:
> 
>> 
>>> In the EU you have Directive 2006/24/EC:
>>> 
>> 
>> But I'm not, and neither are most of the ISPs in the linked document.
>> 
>> Regards,
>> 
>> Michael Holstein
>> Information Security Administrator
>> Cleveland State University
> 
> In the US, I believe that CALEA requires you to have those records for 7 years.
> 
Source, please -- I've never heard of this, nor can I find anything like it
at askcalea.com.  All I've found is that you have to keep records of 
*interceptions*.  I've also seen numerous news stories about how the FBI
wants that to be added to the law, thus implying that it isn't there now.
See, for example, http://news.cnet.com/8301-13578_3-10448060-38.html


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From oberman at es.net  Tue May 10 14:48:02 2011
From: oberman at es.net (Kevin Oberman)
Date: Tue, 10 May 2011 12:48:02 -0700
Subject: 23,000 IP addresses 
In-Reply-To: Your message of "Tue, 10 May 2011 12:02:33 PDT."
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com> 
Message-ID: <20110510194802.8434C1CC3E@ptavv.es.net>

> From: Owen DeLong <owen at delong.com>
> Date: Tue, 10 May 2011 12:02:33 -0700
> 
> On May 10, 2011, at 11:49 AM, Michael Holstein wrote:
> 
> > 
> >> In the EU you have Directive 2006/24/EC:
> >> 
> > 
> > But I'm not, and neither are most of the ISPs in the linked document.
> > 
> > Regards,
> > 
> > Michael Holstein
> > Information Security Administrator
> > Cleveland State University
> 
> In the US, I believe that CALEA requires you to have those records for
> 7 years.

Owen,

Afraid not. As of this time there are no data retention requirements in
CALEA. There is a proposal to add data retention to CALEA this year, but
I can't even find anything indicating the legislation has been
introduced.

According to an article in the NY Times last fall, the FBI will be asking
for several new tools in CALEA that include data retention requirements,
requiring P2P software to allow intercept and requiring that providers
dong encryption (e.g. Blackberry) to provide the ability for the
government to decrypt the data. I don't know that legislation has
actually been introduced, though.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From streiner at cluebyfour.org  Tue May 10 14:48:29 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 10 May 2011 15:48:29 -0400 (EDT)
Subject: 23,000 IP addresses
In-Reply-To: <8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC94DDC.4000809@csuohio.edu>
	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
Message-ID: <Pine.LNX.4.64.1105101544030.9772@whammy.cluebyfour.org>

On Tue, 10 May 2011, Owen DeLong wrote:

> In the US, I believe that CALEA requires you to have those records for 
> 7 years.

Some universities have taken the position that they do not meet the 
criteria for being "communications service providers" under CALEA, and 
therefore not subject to the intercept and data retention requirements. 
Whether or not that has been tested in court yet, I don't 
know.

jms



From michael.holstein at csuohio.edu  Tue May 10 14:51:32 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Tue, 10 May 2011 15:51:32 -0400
Subject: 23,000 IP addresses
In-Reply-To: <8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC94DDC.4000809@csuohio.edu>	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
Message-ID: <4DC99744.3070405@csuohio.edu>


> In the US, I believe that CALEA requires you to have those records for 7 years.
>   

No, it doesn't (records *of the requests* are required, but no
obligation to create subscriber records exists).

Even if it did .. academic institutions are exempt (to CALEA) as private
networks.*

There are various legislative attempts afoot to create one here in the
US .. but none have passed.

Regards,

Michael Holstein
Information Security Administrator
Cleveland State Unviersity

(*): US Court of Appeals, District of Columbia, 50-1504.




From clapidus at gmail.com  Tue May 10 14:58:39 2011
From: clapidus at gmail.com (Claudio Lapidus)
Date: Tue, 10 May 2011 16:58:39 -0300
Subject: 23,000 IP addresses
In-Reply-To: <8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC94DDC.4000809@csuohio.edu>
	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
Message-ID: <BANLkTim=gFmtyZchESe=C8mcyeKadEKHyQ@mail.gmail.com>

Hello,

On Tue, May 10, 2011 at 4:02 PM, Owen DeLong <owen at delong.com> wrote:

>  In the US, I believe that CALEA requires you to have those records for 7
> years.
>
FWIW, in Argentina there is a requirement to hold all records for a full ten
years. A sweet bite for the storage folks here...

regards,
cl.


From oberman at es.net  Tue May 10 15:01:01 2011
From: oberman at es.net (Kevin Oberman)
Date: Tue, 10 May 2011 13:01:01 -0700
Subject: 23,000 IP addresses 
In-Reply-To: Your message of "Tue, 10 May 2011 15:51:32 EDT."
	<4DC99744.3070405@csuohio.edu> 
Message-ID: <20110510200101.DC1AA1CC3E@ptavv.es.net>

> Date: Tue, 10 May 2011 15:51:32 -0400
> From: Michael Holstein <michael.holstein at csuohio.edu>
> 
> 
> > In the US, I believe that CALEA requires you to have those records for 7 years.
> >   
> 
> No, it doesn't (records *of the requests* are required, but no
> obligation to create subscriber records exists).
> 
> Even if it did .. academic institutions are exempt (to CALEA) as private
> networks.*
> 
> There are various legislative attempts afoot to create one here in the
> US .. but none have passed.

There is a great deal of uncertainty about the issue of academic
institutions being exempt. I know tha that the opinion of the
University of California's Counsel was that the wording in the last
CALEA update a few years ago removed that exemption and a representative
of the FBI, speaking on CALEA requirements, was explicit in saying that
they were not exempt. (Of course, that would be the FBI's position.)

In any case, get your own legal opinion about this. Don't rely on NANOG
for legal advice.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From warren at kumari.net  Tue May 10 15:31:17 2011
From: warren at kumari.net (Warren Kumari)
Date: Tue, 10 May 2011 16:31:17 -0400
Subject: Yahoo and IPv6
In-Reply-To: <Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
Message-ID: <3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>


On May 10, 2011, at 12:37 PM, Igor Gashinsky wrote:

> On Tue, 10 May 2011, Iljitsch van Beijnum wrote:
> 
> :: On 9 mei 2011, at 21:40, Tony Hain wrote:
> :: 
> :: >> Publicly held corporations are responsible to their shareholders to get
> :: >> eyeballs on their content. *That* is their job, not promoting cool new
> :: >> network tech. When you have millions of users hitting your site every
> :: >> day losing 1/2000 is a large chunk of revenue.
> :: 
> :: Nonsense. 0.05% is well below the noise margin for anything that involves humans.
> 
> I assure you, it is not. 0.005% might be "in the noise", but 0.05% is 
> quite measurable given a large enough audience.
> 
> :: >> The fact that the big
> :: >> players are doing world IPv6 day at all should be celebrated, promoted,
> :: >> and we should all be ready to take to heart the lessons learned from
> :: >> it.
> :: 
> :: I applaud the first step, but I'm bothered by the fact that no second step is planned.
> 
> Just because it's not public, doesn't mean that it hasn't been planned :)
> 
> Most of us want to see the data that we get from the first step, before 
> making the decision on which second step to take, I'm sure most people 
> can understand that.


Argck, I cannot believe that I am going to do this, let alone publicly, but here goes...

Igor is right on both counts here -- 0.05% is definitely noticeable at these sorts of scale, and I'd be shocked if Yahoo didn't have a set of alerts that fire if projections differ from actual traffic by this amount. I'm also a little surprised that you figured that there were no plans past the event -- much of the point of this is for data gathering -- did you figure folk were just going to gather the data and then ignore it?

Ok, that fully used up my "agreeing with Igor" quota for the year...

W

> 
> -igor
> 




From smb at cs.columbia.edu  Tue May 10 15:31:35 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 10 May 2011 16:31:35 -0400
Subject: 23,000 IP addresses
In-Reply-To: <4DC99744.3070405@csuohio.edu>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC94DDC.4000809@csuohio.edu>	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
	<4DC99744.3070405@csuohio.edu>
Message-ID: <796EDCBC-D377-4EF2-9852-608910E37687@cs.columbia.edu>


On May 10, 2011, at 3:51 32PM, Michael Holstein wrote:

> 
>> In the US, I believe that CALEA requires you to have those records for 7 years.
>> 
> 
> No, it doesn't (records *of the requests* are required, but no
> obligation to create subscriber records exists).
> 
> Even if it did .. academic institutions are exempt (to CALEA) as private
> networks.*
> 
> There are various legislative attempts afoot to create one here in the
> US .. but none have passed.
> 
> Regards,
> 
> Michael Holstein
> Information Security Administrator
> Cleveland State Unviersity
> 
> (*): US Court of Appeals, District of Columbia, 50-1504.
> 
> 
If I've found the right case, it was 05-1404, and published as 451 F.3d 226 (2006);
see http://law.justia.com/cases/federal/appellate-courts/F3/451/226/627290/
I have no idea if it's still good law.
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From bogstad at pobox.com  Tue May 10 15:41:43 2011
From: bogstad at pobox.com (Bill Bogstad)
Date: Tue, 10 May 2011 16:41:43 -0400
Subject: 23,000 IP addresses
In-Reply-To: <796EDCBC-D377-4EF2-9852-608910E37687@cs.columbia.edu>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC94DDC.4000809@csuohio.edu>
	<BANLkTikX-jRY2XKpdNvXoR2KDgVRooE1EQ@mail.gmail.com>
	<BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<4DC988CA.903@csuohio.edu>
	<8646C832-CDB8-4DA1-904B-6F49EA2ABDC5@delong.com>
	<4DC99744.3070405@csuohio.edu>
	<796EDCBC-D377-4EF2-9852-608910E37687@cs.columbia.edu>
Message-ID: <BANLkTik7VQWBtYMRgA_EOZYKCzeDZzUQxw@mail.gmail.com>

On Tue, May 10, 2011 at 4:31 PM, Steven Bellovin <smb at cs.columbia.edu> wrote:

>>
>>
> If I've found the right case, it was 05-1404, and published as 451 F.3d 226 (2006);
> see http://law.justia.com/cases/federal/appellate-courts/F3/451/226/627290/
> I have no idea if it's still good law.

According to EDUCAUSE the appellate decision was complex:

http://www.educause.edu/Policy+Analysis+%26+Advocacy/PressReleases/CALEACourtDecisionMixedforHigh/17136

This status page indicates that 'most' campus networks would be exempt:

http://www.educause.edu/Resources/Browse/CALEA/30781

Definitely a case of 'talk to your lawyers' to be sure.

Bill Bogstad
bogstad at pobox.com



From iljitsch at muada.com  Tue May 10 15:58:51 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 10 May 2011 22:58:51 +0200
Subject: Yahoo and IPv6
In-Reply-To: <3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
Message-ID: <C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>

On 10 mei 2011, at 22:31, Warren Kumari wrote:

>> :: I applaud the first step, but I'm bothered by the fact that no second step is planned.

> Igor is right on both counts here -- 0.05% is definitely noticeable at these sorts of scale,

Ok, removed my infamatory reply. But tell me how 0.05% is visible in the up/down motions of traffic as it starts raining, there is something especially good/bad on TV, people have to reboot because of a Windows update or whatever.

Earlier today I tracerouted the top 1000 websites as per Alexa. I couldn't resolve the DNS for 6 of them. The internet is never 100% up.

> I'm also a little surprised that you figured that there were no plans past the event -- much of the point of this is for data gathering -- did you figure folk were just going to gather the data and then ignore it?

I asked the ISOC press people about this after they sent me their press release but they never replied (they may have replied to my message but not with an answer to the question). There is nothing on the ISOC site that mentions anything happening after june 8.

Of course I'm assuming individual participants will do stuff, but that doesn't change that this IPv6 day as it stands now is a one-off event, not the first step towards the Ultimate Goal.


From mmanning at us.ntt.net  Tue May 10 16:01:25 2011
From: mmanning at us.ntt.net (Mitchell Manning)
Date: Tue, 10 May 2011 14:01:25 -0700
Subject: Removal from mailing list
Message-ID: <006701cc0f55$6db866a0$492933e0$@ntt.net>

Can I please get taken off all nanog mailing list.

 

Thanks,

 

Mitch



From swhyte at gmail.com  Tue May 10 16:47:38 2011
From: swhyte at gmail.com (Scott Whyte)
Date: Tue, 10 May 2011 14:47:38 -0700
Subject: Yahoo and IPv6
In-Reply-To: <C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
Message-ID: <BANLkTin+uXemEU+W5MQTDsMNWZi5_dkkbg@mail.gmail.com>

On Tue, May 10, 2011 at 13:58, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
> On 10 mei 2011, at 22:31, Warren Kumari wrote:
>
>>> :: I applaud the first step, but I'm bothered by the fact that no second step is planned.
>
>> Igor is right on both counts here -- 0.05% is definitely noticeable at these sorts of scale,
>
> Ok, removed my infamatory reply. But tell me how 0.05% is visible in the up/down motions of traffic as it starts raining, there is something especially good/bad on TV, people have to reboot because of a Windows update or whatever.

Its the delta between v4 and v6 that is visible and significant.  If
some machine's addresses are all down hard, that is no problem in this
scenario.

-Scott



From mjwise at kapu.net  Tue May 10 16:48:51 2011
From: mjwise at kapu.net (Michael J Wise)
Date: Tue, 10 May 2011 14:48:51 -0700
Subject: Removal from mailing list
In-Reply-To: <006701cc0f55$6db866a0$492933e0$@ntt.net>
References: <006701cc0f55$6db866a0$492933e0$@ntt.net>
Message-ID: <cedf32074b80a291031da42aa350fe58.squirrel@secure.kapu.net>


> Can I please get taken off all nanog mailing list.

Some email programs will spell it out, but ...
In the full headers, we see this:

List-Unsubscribe: <https://mailman.nanog.org/mailman/listinfo/nanog>,
     <mailto:nanog-request at nanog.org?subject=unsubscribe>

Aloha mai Nai`a.
-- 
" So this is how Liberty dies ...
" To Thunderous Applause.





From nick at flhsi.com  Tue May 10 16:52:39 2011
From: nick at flhsi.com (Nick Olsen)
Date: Tue, 10 May 2011 17:52:39 -0400
Subject: Downstream Usage-BGP Communites
Message-ID: <46995f17$60226696$3726a033$@com>

Greetings NANOG,
Was hoping to gain some insight into common practice with using BGP 
Communities downstream.

For instance:
We peer with AS100 (example)
AS100 peers with TW Telecom (AS4323).
Since I happen to know that AS100 doesn't sanitize the communities I send 
with my routes. I can take advantage of TW Telecom's BGP communities for 
traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this 
be something that is generally frowned upon? Still under the assumption 
that the communities aren't scrubbed off my routes. Could I do this with 
other AS's beyond TW Telecom? Such as TW's peering with Global Crossing 
(AS3549)?

Nick Olsen
Network Operations (855) FLSPEED  x106

 


From m.hallgren at free.fr  Tue May 10 17:07:13 2011
From: m.hallgren at free.fr (Michael Hallgren)
Date: Wed, 11 May 2011 00:07:13 +0200
Subject: Downstream Usage-BGP Communites
In-Reply-To: <46995f17$60226696$3726a033$@com>
References: <46995f17$60226696$3726a033$@com>
Message-ID: <1305065233.3193.15.camel@home>

Le mardi 10 mai 2011 ? 17:52 -0400, Nick Olsen a ?crit :
> Greetings NANOG,
> Was hoping to gain some insight into common practice with using BGP 
> Communities downstream.
> 
> For instance:
> We peer with AS100 (example)
> AS100 peers with TW Telecom (AS4323).
> Since I happen to know that AS100 doesn't sanitize the communities I send 
> with my routes. I can take advantage of TW Telecom's BGP communities for 
> traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this 
> be something that is generally frowned upon? Still under the assumption 
> that the communities aren't scrubbed off my routes. Could I do this with 
> other AS's beyond TW Telecom? Such as TW's peering with Global Crossing 
> (AS3549)?

It's quite common, in my experience, that we remove (or at least filter;
usually looking at geo-origin ones only) BGP community values from peers
and filter them (modulo some set of agreed ones) from customers. 

In other words, don't generally expect transitivity.

mh

> 
> Nick Olsen
> Network Operations (855) FLSPEED  x106
> 
>  





From ken at sizone.org  Tue May 10 17:23:31 2011
From: ken at sizone.org (Ken Chase)
Date: Tue, 10 May 2011 18:23:31 -0400
Subject: Removal from mailing list
In-Reply-To: <cedf32074b80a291031da42aa350fe58.squirrel@secure.kapu.net>
References: <006701cc0f55$6db866a0$492933e0$@ntt.net>
	<cedf32074b80a291031da42aa350fe58.squirrel@secure.kapu.net>
Message-ID: <20110510222331.GG23277@sizone.org>

On Tue, May 10, 2011 at 02:48:51PM -0700, Michael J Wise said:
  >
  >> Can I please get taken off all nanog mailing list.
  >
  >Some email programs will spell it out, but ...
  >In the full headers, we see this:
  >
  >List-Unsubscribe: <https://mailman.nanog.org/mailman/listinfo/nanog>,
  >     <mailto:nanog-request at nanog.org?subject=unsubscribe>

Oh god how did this get here? I am not good with computers.

Shouldnt getting on the list be a lot harder than getting off? Skill
testing questions?

20 years ago, when we were young whippersnappers on nm-list ('new
[forms of] music' list), we had much spam of this type, so we'd manually unsub
them, then sub them to 'blackhole-list', which had a very clear daily email of
instructions of how to get off the list.

That didnt help.

Some still people posting, even daily, to that list, asking to be taken off...
sometimes arguing with eachother, even to the point of flame wars (!) - others
even cooperating on trying to figure it out once and for all. Like a bunch of
drunken sheep bouncing off eachother in a pen with the gate wide open, but no
one ever bounces into the right spot for escape...

Then some kids decided to take it over and discuss and trade commodore-64
juarez on it (and then, seeming to having a shred of clue, they were
harassed by others for help to get off the list) til we noticed and figured we
were abetting piracy, so we shut it down.

Ah those were the days. (nods to old nm-listers, be ye out there.)

/kc
-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.



From ras at e-gerbil.net  Tue May 10 17:25:22 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 10 May 2011 17:25:22 -0500
Subject: Downstream Usage-BGP Communites
In-Reply-To: <46995f17$60226696$3726a033$@com>
References: <46995f17$60226696$3726a033$@com>
Message-ID: <20110510222522.GD18302@gerbil.cluepon.net>

On Tue, May 10, 2011 at 05:52:39PM -0400, Nick Olsen wrote:
> Greetings NANOG,
> Was hoping to gain some insight into common practice with using BGP 
> Communities downstream.
> 
> For instance:
> We peer with AS100 (example)
> AS100 peers with TW Telecom (AS4323).
> Since I happen to know that AS100 doesn't sanitize the communities I send 
> with my routes. I can take advantage of TW Telecom's BGP communities for 
> traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this 
> be something that is generally frowned upon? Still under the assumption 
> that the communities aren't scrubbed off my routes. Could I do this with 
> other AS's beyond TW Telecom? Such as TW's peering with Global Crossing 
> (AS3549)?

Well first off, if you're using the words "peers with" in the normal 
sense, your routes would never propagate to AS4323 in the first place. 
Assuming what you actually mean is that at least one of those sessions 
is a transit feed, essentially all (non-stupid) networks will filter 
their own TE communities from their transits/peers, so the odds of this 
working are almost non-existant.

You also have about a 50/50 shot of AS100 stripping your communities 
before they even make it to AS4323 (or any other network). Personally my 
belief is that this is a bad thing, and you should only filter 
communities in your own name-space (i.e. $YOURASN:*), but this doesn't 
stop a large number of obnoxious networks from doing it anyways. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From streiner at cluebyfour.org  Tue May 10 17:27:27 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 10 May 2011 18:27:27 -0400 (EDT)
Subject: Downstream Usage-BGP Communites
In-Reply-To: <46995f17$60226696$3726a033$@com>
References: <46995f17$60226696$3726a033$@com>
Message-ID: <Pine.LNX.4.64.1105101806350.9772@whammy.cluebyfour.org>

On Tue, 10 May 2011, Nick Olsen wrote:

> Was hoping to gain some insight into common practice with using BGP
> Communities downstream.

Generally, the transitive BGP attribute you have the most direct control 
over is AS_PATH, though it's not impossible for a provider to munge the 
AS_PATH on routes they receive from their transits and peers, beyond your 
control.

Some providers might have communities that let you pass things along to 
their transit providers and peers, or influence traffic patterns / route 
propagation.

For example, if I buy transit from ISP X, and they get transit from 
Level3 and Sprint, they might offer a community that lets me selectively 
prepend to Sprint (or Level3), I can affect how traffic flows to my 
network.  In your example, AS100 might have a community that you can 
set on your announcements that will cause them to set 4323:666 on that 
prefix when it's passed to TWTC.  If they don't offer a community, then 
doing what you're looking for would require one of their network people to 
put something manual in place.  Many large networks don't like to (or 
won't) do that because one-off requests don't scale very well, and it can 
add complexity when troubleshooting a connectivity problem, or when 
someone fat-fingers an access-list/distribute-list/prefix-list.

This varies greatly, based on the level of control your direct BGP 
neighbors are willing or able to offer to you.  Also, in general, the 
farther away a network is from you (in terms of AS hops), the less likely 
you are to have control over how they propagate and act upon your 
announcements.

jms



From lyle at lcrcomputer.net  Tue May 10 17:40:43 2011
From: lyle at lcrcomputer.net (Lyle Giese)
Date: Tue, 10 May 2011 17:40:43 -0500
Subject: Removal from mailing list
In-Reply-To: <20110510222331.GG23277@sizone.org>
References: <006701cc0f55$6db866a0$492933e0$@ntt.net>	<cedf32074b80a291031da42aa350fe58.squirrel@secure.kapu.net>
	<20110510222331.GG23277@sizone.org>
Message-ID: <4DC9BEEB.60402@lcrcomputer.net>


> Then some kids decided to take it over and discuss and trade commodore-64
> juarez on it (and then, seeming to having a shred of clue, they were
> harassed by others for help to get off the list) til we noticed and figured we
> were abetting piracy, so we shut it down.
>
> Ah those were the days. (nods to old nm-listers, be ye out there.)
>
> /kc

Yep, the good ole days...  Back then I started my business doing chip 
level repairs on Commodore 64's.

You know you can buy a C-64 now?  Someone bought the name and created a 
PC in a case that looks identical to a C-64.

Lyle Giese
LCR Computer Services, Inc.




From nick at flhsi.com  Tue May 10 17:47:11 2011
From: nick at flhsi.com (Nick Olsen)
Date: Tue, 10 May 2011 18:47:11 -0400
Subject: Downstream Usage-BGP Communites
Message-ID: <24fe796b$74b5933f$2953abcf$@com>

Ah, Sorry for the confusion. 
We have a mutual agreement with AS100 (call it transit or peering) we send 
them full routes, They send us full routes.
AS100 is a transit customer of AS4323.
I understand I would be at the mercy of how people have things setup. I do 
know for a fact I'm not filtered by AS100 as I've already tested it.
Thanks to everyone for the info so far.

Nick Olsen
Network Operations (855) FLSPEED  x106

----------------------------------------
 From: "Richard A Steenbergen" <ras at e-gerbil.net>
Sent: Tuesday, May 10, 2011 6:27 PM
To: "Nick Olsen" <nick at flhsi.com>
Subject: Re: Downstream Usage-BGP Communites

On Tue, May 10, 2011 at 05:52:39PM -0400, Nick Olsen wrote:
> Greetings NANOG,
> Was hoping to gain some insight into common practice with using BGP 
> Communities downstream.
> 
> For instance:
> We peer with AS100 (example)
> AS100 peers with TW Telecom (AS4323).
> Since I happen to know that AS100 doesn't sanitize the communities I send 

> with my routes. I can take advantage of TW Telecom's BGP communities for 

> traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this 

> be something that is generally frowned upon? Still under the assumption 
> that the communities aren't scrubbed off my routes. Could I do this with 

> other AS's beyond TW Telecom? Such as TW's peering with Global Crossing 
> (AS3549)?

Well first off, if you're using the words "peers with" in the normal 
sense, your routes would never propagate to AS4323 in the first place. 
Assuming what you actually mean is that at least one of those sessions 
is a transit feed, essentially all (non-stupid) networks will filter 
their own TE communities from their transits/peers, so the odds of this 
working are almost non-existant.

You also have about a 50/50 shot of AS100 stripping your communities 
before they even make it to AS4323 (or any other network). Personally my 
belief is that this is a bad thing, and you should only filter 
communities in your own name-space (i.e. $YOURASN:*), but this doesn't 
stop a large number of obnoxious networks from doing it anyways. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From ken at sizone.org  Tue May 10 17:47:18 2011
From: ken at sizone.org (Ken Chase)
Date: Tue, 10 May 2011 18:47:18 -0400
Subject: Removal from mailing list
In-Reply-To: <4DC9BEEB.60402@lcrcomputer.net>
References: <006701cc0f55$6db866a0$492933e0$@ntt.net>
	<cedf32074b80a291031da42aa350fe58.squirrel@secure.kapu.net>
	<20110510222331.GG23277@sizone.org>
	<4DC9BEEB.60402@lcrcomputer.net>
Message-ID: <20110510224718.GH23277@sizone.org>

On Tue, May 10, 2011 at 05:40:43PM -0500, Lyle Giese said:
>
>> Then some kids decided to take it over and discuss and trade commodore-64
>> juarez on it (and then, seeming to having a shred of clue, they were
>> harassed by others for help to get off the list) til we noticed and figured we
>> were abetting piracy, so we shut it down.
>>
>> Ah those were the days. (nods to old nm-listers, be ye out there.)
>>
>> /kc
>
> Yep, the good ole days...  Back then I started my business doing chip  
> level repairs on Commodore 64's.
>
> You know you can buy a C-64 now?  Someone bought the name and created a  
> PC in a case that looks identical to a C-64.

and runs a C64 emulator at 100x the speed of the original 64, meaning
the games are unplayable without a nullop routine :)

/kc

>
> Lyle Giese
> LCR Computer Services, Inc.
>

-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.



From ras at e-gerbil.net  Tue May 10 18:15:52 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 10 May 2011 18:15:52 -0500
Subject: Downstream Usage-BGP Communites
In-Reply-To: <24fe796b$74b5933f$2953abcf$@com>
References: <24fe796b$74b5933f$2953abcf$@com>
Message-ID: <20110510231552.GF18302@gerbil.cluepon.net>

On Tue, May 10, 2011 at 06:47:11PM -0400, Nick Olsen wrote:
> Ah, Sorry for the confusion. 
> We have a mutual agreement with AS100 (call it transit or peering) we send 
> them full routes, They send us full routes.
> AS100 is a transit customer of AS4323.
> I understand I would be at the mercy of how people have things setup. I do 
> know for a fact I'm not filtered by AS100 as I've already tested it.
> Thanks to everyone for the info so far.

Erm ok, well as long as you're a transit customer of AS100 (for some 
definition of transit customer), and they're a transit customer of 
AS4323, you should have no problems. This is completely different from 
"peering", when money changes hands communities get listened to. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From jfesler at gigo.com  Tue May 10 18:43:44 2011
From: jfesler at gigo.com (Jason Fesler)
Date: Tue, 10 May 2011 16:43:44 -0700 (PDT)
Subject: Yahoo and IPv6
In-Reply-To: <C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
Message-ID: <alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>

> Of course I'm assuming individual participants will do stuff, but that 
> doesn't change that this IPv6 day as it stands now is a one-off event,
> not the first step towards the Ultimate Goal.

The intent is to get folks together after we digest the data, to talk 
about next steps.  Date is not yet picked.

I'm hoping we collectively prove there is no broken user problem.  I 
realistically expect we'll have another "v6d" - either as 24h, or as a 
roll-on-and-stick.   But, until we get through the day, and analyze the 
data, any decisions on what to do next are premature.

The NANOG following v6d should be interesting; I'm hoping a number of 
folks from both access and content are willing to share any early stats 
they have.



From DStaal at usa.net  Tue May 10 18:55:50 2011
From: DStaal at usa.net (Daniel Staal)
Date: Tue, 10 May 2011 19:55:50 -0400
Subject: 23,000 IP addresses
In-Reply-To: <Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
Message-ID: <41A477543C481FC8B6326A5C@mac-pro.magehandbook.com>

--As of May 10, 2011 9:37:55 AM -0400, Jon Lewis is alleged to have said:

> I wonder how things go if you challenge them in court.  This is surely a
> topic for another list, but it seems to me it'd be fairly difficult to
> prove unless they downloaded part of the movie from your IP and verified
> that what they got really was a part of the movie.  If they're going
> after any IP that connected to and downloaded from an agent of the studio
> (and that's what it sounds like) who hosted the file, can they really
> expect to prosecute people for downloading something they were giving
> away?

--As for the rest, it is mine.

Typically the response (from what media coverage I've read) is that they'll 
put up a token defense to see if you are really interested, and then drop 
it at the first opportunity if you continue.  Keeping them in court once 
they have dropped the prosecution is tricky, and they will resist that with 
all available resources.

Actually paying court costs and spending billable time on these cuts into 
their business model.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------



From marka at isc.org  Tue May 10 19:19:17 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 11 May 2011 10:19:17 +1000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Tue, 10 May 2011 16:43:44 MST."
	<alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
	<alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>
Message-ID: <20110511001917.A4B22EA2778@drugs.dv.isc.org>


In message <alpine.BSF.2.00.1105101608140.19724 at goat.gigo.com>, Jason Fesler wr
ites:
> > Of course I'm assuming individual participants will do stuff, but that 
> > doesn't change that this IPv6 day as it stands now is a one-off event,
> > not the first step towards the Ultimate Goal.
> 
> The intent is to get folks together after we digest the data, to talk 
> about next steps.  Date is not yet picked.
> 
> I'm hoping we collectively prove there is no broken user problem.  I 
> realistically expect we'll have another "v6d" - either as 24h, or as a 
> roll-on-and-stick.   But, until we get through the day, and analyze the 
> data, any decisions on what to do next are premature.
> 
> The NANOG following v6d should be interesting; I'm hoping a number of 
> folks from both access and content are willing to share any early stats 
> they have.

What I would like OS and application vendors to do is test every
network product they ship with 3 sets dual stack servers which are
configured:

* With the service on both IPv4 and IPv6.
* With the service on IPv4 and the IPv6 service silently blocked.
* With the service on IPv6 and the IPv4 service silently blocked.

If the product is designed to work on a dual stack client it should
work correctly though perhaps slowly with the server configured in
all three of these states.  This isn't hard and is just basic quality
control.  And for Apple, don't forget to prime the address cache
so that both A and AAAA records are present.  There is no excuse
for any vendor to be currently shipping products that fail such a
test.

For the record Apple's current iChat (the OS (10.6.7) is completely
up to date) fails such a test.  It will try IPv6 and not fallback
to IPv4.  End users shouldn't be seeing these sorts of errors.

Yes, this is name and shame.
Yes, I have reported this to Apple through their web site.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From mysidia at gmail.com  Tue May 10 19:30:17 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 10 May 2011 19:30:17 -0500
Subject: 23,000 IP addresses
In-Reply-To: <4DC943A4.40005@amplex.net>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC943A4.40005@amplex.net>
Message-ID: <BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>

On Tue, May 10, 2011 at 8:54 AM, Mark Radabaugh <mark at amplex.net> wrote:
> On 5/10/11 9:07 AM, Marshall Eubanks wrote:
> A good reason why every ISP should have a published civil subpoena
> compliance fee.
> 23,000 * $150 each should only cost them $3.45M to get the information.
> Seems like that would take the profit out pretty quickly.

+1.
But don't the fees actually have to be reasonable?

If you say your fee is  $150 per IP address,  I think they might bring
it to the judge
and claim the ISP is attempting to avoid subpoena compliance by charging an
unreasonable fee.

They can point to all the competitors charging $40 per IP.

This would be very interesting with IPv6 though,  and customers assigned /56s.

"You want all the records for every IP in this /56,  really?"


--
-JH



From kauer at biplane.com.au  Tue May 10 19:39:45 2011
From: kauer at biplane.com.au (Karl Auer)
Date: Wed, 11 May 2011 10:39:45 +1000
Subject: Yahoo and IPv6
In-Reply-To: <20110511001917.A4B22EA2778@drugs.dv.isc.org>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us> <120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
	<alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>
	<20110511001917.A4B22EA2778@drugs.dv.isc.org>
Message-ID: <1305074385.18376.566.camel@karl>

On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:
> For the record Apple's current iChat (the OS (10.6.7) is completely
> up to date) fails such a test.  It will try IPv6 and not fallback
> to IPv4.  End users shouldn't be seeing these sorts of errors.

Is that possibly a failure of the underlying resolver library? Do other
applications on the same platform behave correctly?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110511/14d4c4bf/attachment.bin>

From tshaw at oitc.com  Tue May 10 19:49:53 2011
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 10 May 2011 20:49:53 -0400
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <A5D976BF-5156-45F9-9150-06F7F9B95747@oitc.com>


On May 9, 2011, at 11:16 AM, Arie Vayner wrote:

> Actually, I have just noticed a slightly more disturbing thing on the Yahoo
> IPv6 help page...
> 
> I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services
> (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to
> run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and
> it says:
> "We detected an issue with your IPv6 configuration. On World IPv6 Day, you
> will have issues reaching Yahoo!, as well as your other favorite web sites.
> We recommend disabling
> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>,
> or seeking assistance in order to fix your system's IPv6 configuration
> through your ISP or computer manufacturer."
> 

Weird as I also use the HE tunnel and the yahoo report for me was clean.

Tom





From mpalmer at hezmatt.org  Tue May 10 20:03:23 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Wed, 11 May 2011 11:03:23 +1000
Subject: Yahoo and IPv6
In-Reply-To: <CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
Message-ID: <20110511010323.GD10306@hezmatt.org>

On Tue, May 10, 2011 at 11:22:54AM -0700, Owen DeLong wrote:
> On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:
> > On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:
> > :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
> > :: > The time for finger-pointing is over, period, all we are all trying to do 
> > :: > now is figure out how to deal with the present (sucky) situation. The 
> > :: > current reality is that for a non-insignificant percentage of users when 
> > :: > you enable dual-stack, they are gong to drop off the face of the planet. 
> > :: > Now, for *you*, 0.026% may be insignificant (and, standalone, that number 
> > :: > is insignificant), but for a global content provider that has ~700M users, 
> > :: > that's 182 *thousand* users that *you*, *through your actions* just took 
> > :: > out.. 182,000 - that is *not* insignificant
> > :: 
> > :: At any given instant, there's a *lot* more than 182,000 users who are cut off
> > :: due to various *IPv4* misconfigurations and issues.
> > 
> > Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
> > and you are asking *me* to break them through *my* actions. Sorry, that's 
> > simply too many to break for me, without a damn good reason to do so.
> > 
> In other words, Igor can't turn on AAAA records generally until there are
> 182,001 IPv6-only users that are broken from his lack of AAAA records.

There may be something stupid I haven't considered about this, but wouldn't
a v6-only end user be making their DNS requests over v6 (at least to their
ISP's resolver), and if their provider was nice enough to continue that
v6ness up the chain, wouldn't it be fairly simple (to the point of "I'd be
stunned if everyone wasn't already doing this") to say to
Yahoo/Google/whatever's ultra-smart whitelisting DNS servers, "v6-whitelist
all v6 DNS requests"?

That way, v6-only people are guaranteed to get the AAAA records they so
badly crave, without making an excessive mess for anyone else.

I know this falls down if your v6-only-providing ISP takes your recursive
DNS requests on IPv6 and sends them out via IPv4 even if AAAA records were
available, but why would anyone be that dumb?  Since the initial request
would come in via v6, anything whitelisting in this fashion would be sending
the AAAA records out, so you should never have to fall back to v4 unless
someone isn't providing DNS via v6 at all, and who would willingly have
their site v6 enabled without v6 enabling the DNS?  (Yes, I'm aware of
registrars who don't accept v6 glue, but get your whacking sticks out and
keep whackin' 'til they fix it -- and kudos to gkg.net for having that
sorted *before* I put my first v6 site up).

- Matt

-- 
Ruby's the only language I've ever used that feels like it was designed by a
programmer, and not by a hardware engineer (Java, C, C++), an academic
theorist (Lisp, Haskell, OCaml), or an editor of PC World (Python).
		-- William Morgan



From owen at delong.com  Tue May 10 20:18:12 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 10 May 2011 18:18:12 -0700
Subject: Yahoo and IPv6
In-Reply-To: <20110511010323.GD10306@hezmatt.org>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<20110511010323.GD10306@hezmatt.org>
Message-ID: <ACE1B9AA-23A2-40CE-95B1-3421777E7275@delong.com>


On May 10, 2011, at 6:03 PM, Matthew Palmer wrote:

> On Tue, May 10, 2011 at 11:22:54AM -0700, Owen DeLong wrote:
>> On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:
>>> On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:
>>> :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
>>> :: > The time for finger-pointing is over, period, all we are all trying to do 
>>> :: > now is figure out how to deal with the present (sucky) situation. The 
>>> :: > current reality is that for a non-insignificant percentage of users when 
>>> :: > you enable dual-stack, they are gong to drop off the face of the planet. 
>>> :: > Now, for *you*, 0.026% may be insignificant (and, standalone, that number 
>>> :: > is insignificant), but for a global content provider that has ~700M users, 
>>> :: > that's 182 *thousand* users that *you*, *through your actions* just took 
>>> :: > out.. 182,000 - that is *not* insignificant
>>> :: 
>>> :: At any given instant, there's a *lot* more than 182,000 users who are cut off
>>> :: due to various *IPv4* misconfigurations and issues.
>>> 
>>> Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
>>> and you are asking *me* to break them through *my* actions. Sorry, that's 
>>> simply too many to break for me, without a damn good reason to do so.
>>> 
>> In other words, Igor can't turn on AAAA records generally until there are
>> 182,001 IPv6-only users that are broken from his lack of AAAA records.
> 
> There may be something stupid I haven't considered about this, but wouldn't
> a v6-only end user be making their DNS requests over v6 (at least to their
> ISP's resolver), and if their provider was nice enough to continue that
> v6ness up the chain, wouldn't it be fairly simple (to the point of "I'd be
> stunned if everyone wasn't already doing this") to say to
> Yahoo/Google/whatever's ultra-smart whitelisting DNS servers, "v6-whitelist
> all v6 DNS requests"?
> 
Not necessarily and almost entirely irrelevant. Yahoo may or may not get
the query from the ISP's resolver directly. An IPv6-only client might
have a private IPv4 address that reaches an IPv4 resolver within their
local network that may or may not have public IPv4 connectivity.

There is no clean or reliable way to infer anything about the protocol
stack on the client from an authoritative DNS server.

> That way, v6-only people are guaranteed to get the AAAA records they so
> badly crave, without making an excessive mess for anyone else.
> 
Another beautiful theory murdered by a brutal gang of facts.

> I know this falls down if your v6-only-providing ISP takes your recursive
> DNS requests on IPv6 and sends them out via IPv4 even if AAAA records were
> available, but why would anyone be that dumb?  Since the initial request
> would come in via v6, anything whitelisting in this fashion would be sending
> the AAAA records out, so you should never have to fall back to v4 unless
> someone isn't providing DNS via v6 at all, and who would willingly have
> their site v6 enabled without v6 enabling the DNS?  (Yes, I'm aware of
> registrars who don't accept v6 glue, but get your whacking sticks out and
> keep whackin' 'til they fix it -- and kudos to gkg.net for having that
> sorted *before* I put my first v6 site up).
> 
It's not a matter of dumb. There are all kinds of reasons this might occur.
For example, an IPv6-only host behind an HE Tunnel on a network that
gets IPv4 only service from another ISP, but, is out of IPv4 addresses.

Owen




From mpetach at netflight.com  Tue May 10 20:52:53 2011
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 10 May 2011 18:52:53 -0700
Subject: Yahoo and IPv6
In-Reply-To: <C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
Message-ID: <BANLkTikt2O=Z9c9kfyPdxwYoFWa==Kf0+g@mail.gmail.com>

On Tue, May 10, 2011 at 1:58 PM, Iljitsch van Beijnum
<iljitsch at muada.com> wrote:
> On 10 mei 2011, at 22:31, Warren Kumari wrote:
>> I'm also a little surprised that you figured that there were no plans past the event -- much of the point of this is for data gathering -- did you figure folk were just going to gather the data and then ignore it?
>
> I asked the ISOC press people about this after they sent me their press release but they never replied (they may have replied to my message but not with an answer to the question). There is nothing on the ISOC site that mentions anything happening after june 8.
>
> Of course I'm assuming individual participants will do stuff, but that doesn't change that this IPv6 day as it stands now is a one-off event, not the first step towards the Ultimate Goal.
>

Speaking only for myself, and not for anybody at all, I wouldn't be terribly
surprised if the 24 hour experiment goes smoothly to see it followed up
by a week-long trial round the next time.

If it doesn't go well, I imagine there will be much data analysis, figuring
out what needs to be fixed, and a "24 hour trial, take 2" once a sufficient
level of fixage has occurred.

Matt



From tvhawaii at shaka.com  Tue May 10 20:53:16 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Tue, 10 May 2011 15:53:16 -1000
Subject: 23,000 IP addresses
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>
Message-ID: <2050F838A26343E989A09DD14EBC908E@DELL16>

Deepak Jain wrote:
> For examples, see the RIAA's attempts and more recently the criminal investigations of child porn downloads from 
> unsecured access
> points. From what I understand (or wildly guess) is that ISPs with remote diagnostic capabilities are being asked if 
> their
> provided access point is secure or unsecure BEFORE they serve their warrants to avoid further embarrassments. [It'll 
> probably
> take another 6 months and more goofs before they realize that customers are perfectly capable of poorly installing their 
> own
> access points behind ISP provided gear].

Exactly...what about those who choose WEP/WPA-TKIP for their 'secured' access point?
I can just imagine being in front of a judge/jury after having been arrested for, as you say, "child porn downloads " and 
listening to my law^H^H^H public defender explain the mechanisms of how the access point was 'cracked' and may have been 
used by someone sitting in their car down the street.<shudder> 




From ongbh at ispworkshop.com  Tue May 10 20:56:56 2011
From: ongbh at ispworkshop.com (Ong Beng Hui)
Date: Wed, 11 May 2011 09:56:56 +0800
Subject: 23,000 IP addresses
In-Reply-To: <D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>
Message-ID: <4DC9ECE8.10307@ispworkshop.com>

Hi?

I am not an US citizen and I don't live in US. But I am interested to 
know how the case progress, because we have similar such cases in my 
country. :P

But seriously, are they after the end-user or making the ISP responsible 
for their end-user ?

while, I am not a lawyer, so what after they know who is using that 
broadband connection for that IP. So, they have identified the 80yr old, 
what next ? and what if i have a free-for-all wireless router in my 
house which anyone can tap on, which i regularly switch off during 
nighttime for energy saving reason. :)

On 5/11/11 1:28 AM, Deepak Jain wrote:
>> A Federal Judge has decided to let the "U.S. Copyright Group" subpoena
>> ISPs over 23,000 alleged downloads of some
>> Sylvester Stallone movie I have never heard of; subpoenas are expected
>> to go out this week.
>>
>> I thought that there might be some interest in the list of these
>> addresses :
>>
>> http://www.wired.com/images_blogs/threatlevel/2011/05/expendibleipaddre
>> sses.pdf
> This will stop when a 80+ yr old is taken to court over a download her 8 year old grandkid might have made when visiting for the weekend. The media will make the case that technologists can't.
>
> For examples, see the RIAA's attempts and more recently the criminal investigations of child porn downloads from unsecured access points. From what I understand (or wildly guess) is that ISPs with remote diagnostic capabilities are being asked if their provided access point is secure or unsecure BEFORE they serve their warrants to avoid further embarrassments. [It'll probably take another 6 months and more goofs before they realize that customers are perfectly capable of poorly installing their own access points behind ISP provided gear].
>
> The torrent stuff is fundamentally no different in that a single IP can and is shared by lots of people as common practice and the transient nature of it (e.g. airport access point, starbucks, etc) reasonably makes the lawyer's case much, much harder.
>
> There is a real theft/crime here in many cases, but whether there is actually any value in prosecution of movie downloads will depend... but most likely, the outcome will be iMovies or similar and the movie industry will shrink the way the music industry has.
>
> DJ
>




From marka at isc.org  Tue May 10 20:57:35 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 11 May 2011 11:57:35 +1000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Wed, 11 May 2011 10:39:45 +1000."
	<1305074385.18376.566.camel@karl>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
	<alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>
	<20110511001917.A4B22EA2778@drugs.dv.isc.org>
	<1305074385.18376.566.camel@karl>
Message-ID: <20110511015735.51C54EA33A4@drugs.dv.isc.org>


In message <1305074385.18376.566.camel at karl>, Karl Auer writes:
> On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:
> > For the record Apple's current iChat (the OS (10.6.7) is completely
> > up to date) fails such a test.  It will try IPv6 and not fallback
> > to IPv4.  End users shouldn't be seeing these sorts of errors.
> 
> Is that possibly a failure of the underlying resolver library? Do other
> applications on the same platform behave correctly?

It doesn't matter where in the system the fault is.  It's all Apple
components.  If the application doesn't get and try all addresses
it is broken.  The nameservers have all addresses in their caches.
MacOS's local cache have all addresses in it.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From smb at cs.columbia.edu  Tue May 10 21:22:21 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 10 May 2011 22:22:21 -0400
Subject: 23,000 IP addresses
In-Reply-To: <2050F838A26343E989A09DD14EBC908E@DELL16>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>
	<2050F838A26343E989A09DD14EBC908E@DELL16>
Message-ID: <AAFF5040-65D9-4264-BA6C-28CC29F3923D@cs.columbia.edu>


On May 10, 2011, at 9:53 16PM, Michael Painter wrote:

> Deepak Jain wrote:
>> For examples, see the RIAA's attempts and more recently the criminal investigations of child porn downloads from unsecured access
>> points. From what I understand (or wildly guess) is that ISPs with remote diagnostic capabilities are being asked if their
>> provided access point is secure or unsecure BEFORE they serve their warrants to avoid further embarrassments. [It'll probably
>> take another 6 months and more goofs before they realize that customers are perfectly capable of poorly installing their own
>> access points behind ISP provided gear].
> 
> Exactly...what about those who choose WEP/WPA-TKIP for their 'secured' access point?
> I can just imagine being in front of a judge/jury after having been arrested for, as you say, "child porn downloads " and listening to my law^H^H^H public defender explain the mechanisms of how the access point was 'cracked' and may have been used by someone sitting in their car down the street.<shudder> 
> 
> 
It's happened -- here are two cases I know of:
http://news.cnet.com/Wi-Fi-arrest-highlights-security-dangers/2100-1039_3-5112000.html
http://news.nationalpost.com/2010/05/27/ontario-man-accused-of-downloading-child-porn-because-of-free-wifi-connection/


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From mark at amplex.net  Tue May 10 21:35:37 2011
From: mark at amplex.net (Mark Radabaugh)
Date: Tue, 10 May 2011 22:35:37 -0400
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC943A4.40005@amplex.net>
	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
Message-ID: <4DC9F5F9.9090407@amplex.net>

On 5/10/11 8:30 PM, Jimmy Hess wrote:
> On Tue, May 10, 2011 at 8:54 AM, Mark Radabaugh<mark at amplex.net>  wrote:
>> On 5/10/11 9:07 AM, Marshall Eubanks wrote:
>> A good reason why every ISP should have a published civil subpoena
>> compliance fee.
>> 23,000 * $150 each should only cost them $3.45M to get the information.
>> Seems like that would take the profit out pretty quickly.
> +1.
> But don't the fees actually have to be reasonable?
>
Facebook charges $150.00  (not a great link but 
http://lawyerist.com/subpoena-facebook-information/

Finding that on facebook's site is difficult.  Other sites have Facebook 
charging $250 to $500 for civil subpoena fees.

Courts like precedent.  I choose Facebook's precedent.  Seems reasonable 
to me.

Mark




From frnkblk at iname.com  Tue May 10 23:32:12 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 10 May 2011 23:32:12 -0500
Subject: Yahoo and IPv6
In-Reply-To: <CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
Message-ID: <00f701cc0f94$65f233d0$31d69b70$@iname.com>

If I can anticipate Igor's response, he'll say that he'll whitelist those
IPv6-only networks and so he's just help 182,000 people.

Frank

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, May 10, 2011 1:23 PM
To: Igor Gashinsky
Cc: nanog at nanog.org
Subject: Re: Yahoo and IPv6

On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:

> On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:
> 
> :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
> :: 
> :: > The time for finger-pointing is over, period, all we are all trying
to do 
> :: > now is figure out how to deal with the present (sucky) situation. The

> :: > current reality is that for a non-insignificant percentage of users
when 
> :: > you enable dual-stack, they are gong to drop off the face of the
planet. 
> :: > Now, for *you*, 0.026% may be insignificant (and, standalone, that
number 
> :: > is insignificant), but for a global content provider that has ~700M
users, 
> :: > that's 182 *thousand* users that *you*, *through your actions* just
took 
> :: > out.. 182,000 - that is *not* insignificant
> :: 
> :: At any given instant, there's a *lot* more than 182,000 users who are
cut off
> :: due to various *IPv4* misconfigurations and issues.
> 
> Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
> and you are asking *me* to break them through *my* actions. Sorry, that's 
> simply too many to break for me, without a damn good reason to do so.
> 
In other words, Igor can't turn on AAAA records generally until there are
182,001 IPv6-only users that are broken from his lack of AAAA records.

Given IP address consumption rates in Asia and the lack of available IPv4
resources in Asia, with a traditional growth month to month of nearly
30 million IPv4 addresses consumed, I suspect it will not be long before
the 182,001 broken IPv6 users become relevant.

> Doing that on world ipv6 day, when there is a lot of press, and most other

> large content players doing the same, *is* a good reason - it may actually

> has a shot of accomplishing some good, since it may get those users to 
> realize that they are broken, and fix their systems, but outside of flag 
> day, if I enabled AAAA by default for all users, all I'm going to do is 
> send those "broken" users to my competitors who chose not to enable AAAA 
> on their sites. 
> 
Agreed. I think IPv6 day is a great plan for this very reason. I also hope
that
a lot of organizations that try things out on IPv6 day will decide that the
brokenness that has been so hyped wasn't actually noticeable and then
leave their AAAA records in place. I do not expect Yahoo or Google to
be among them, but, hopefully a lot of other organizations will do so.

> This is why I think automatic, measurement-based whitelisting/blacklisting

> to minimize the collateral damage of enabling AAAA is going to be 
> inevitable (with the trigger set to something around 99.99%), and about 
> the only way we see wide-scale IPv6 adoption by content players, outside 
> events like world ipv6 day.
> 
This will be interesting. Personally, I think it will be more along the
lines
of when there are more IPv6 only eye-balls with broken IPv4 than there
are IPv4 eye-balls with broken IPv6, AAAA will become the obvious
solution.

In my opinion, this is just a matter of time and will happen much sooner
than
I think most people anticipate.

Owen





From frnkblk at iname.com  Tue May 10 23:31:33 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 10 May 2011 23:31:33 -0500
Subject: Yahoo and IPv6
In-Reply-To: <CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
Message-ID: <001f01cc0f94$4e7293d0$eb57bb70$@iname.com>

If I can anticipate Igor's response, he'll say that he'll whitelist those
IPv6-only networks and so he's just help 182,000 people.

Frank

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, May 10, 2011 1:23 PM
To: Igor Gashinsky
Cc: nanog at nanog.org
Subject: Re: Yahoo and IPv6

On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:

> On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:
> 
> :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
> :: 
> :: > The time for finger-pointing is over, period, all we are all trying
to do 
> :: > now is figure out how to deal with the present (sucky) situation. The

> :: > current reality is that for a non-insignificant percentage of users
when 
> :: > you enable dual-stack, they are gong to drop off the face of the
planet. 
> :: > Now, for *you*, 0.026% may be insignificant (and, standalone, that
number 
> :: > is insignificant), but for a global content provider that has ~700M
users, 
> :: > that's 182 *thousand* users that *you*, *through your actions* just
took 
> :: > out.. 182,000 - that is *not* insignificant
> :: 
> :: At any given instant, there's a *lot* more than 182,000 users who are
cut off
> :: due to various *IPv4* misconfigurations and issues.
> 
> Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
> and you are asking *me* to break them through *my* actions. Sorry, that's 
> simply too many to break for me, without a damn good reason to do so.
> 
In other words, Igor can't turn on AAAA records generally until there are
182,001 IPv6-only users that are broken from his lack of AAAA records.

Given IP address consumption rates in Asia and the lack of available IPv4
resources in Asia, with a traditional growth month to month of nearly
30 million IPv4 addresses consumed, I suspect it will not be long before
the 182,001 broken IPv6 users become relevant.

> Doing that on world ipv6 day, when there is a lot of press, and most other

> large content players doing the same, *is* a good reason - it may actually

> has a shot of accomplishing some good, since it may get those users to 
> realize that they are broken, and fix their systems, but outside of flag 
> day, if I enabled AAAA by default for all users, all I'm going to do is 
> send those "broken" users to my competitors who chose not to enable AAAA 
> on their sites. 
> 
Agreed. I think IPv6 day is a great plan for this very reason. I also hope
that
a lot of organizations that try things out on IPv6 day will decide that the
brokenness that has been so hyped wasn't actually noticeable and then
leave their AAAA records in place. I do not expect Yahoo or Google to
be among them, but, hopefully a lot of other organizations will do so.

> This is why I think automatic, measurement-based whitelisting/blacklisting

> to minimize the collateral damage of enabling AAAA is going to be 
> inevitable (with the trigger set to something around 99.99%), and about 
> the only way we see wide-scale IPv6 adoption by content players, outside 
> events like world ipv6 day.
> 
This will be interesting. Personally, I think it will be more along the
lines
of when there are more IPv6 only eye-balls with broken IPv4 than there
are IPv4 eye-balls with broken IPv6, AAAA will become the obvious
solution.

In my opinion, this is just a matter of time and will happen much sooner
than
I think most people anticipate.

Owen





From tore.anderson at redpill-linpro.com  Wed May 11 02:24:32 2011
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Wed, 11 May 2011 09:24:32 +0200
Subject: Yahoo and IPv6
In-Reply-To: <13ba01cc0f1b$b21bc600$16535200$@net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<13ba01cc0f1b$b21bc600$16535200$@net>
Message-ID: <4DCA39B0.6050505@redpill-linpro.com>

* Tony Hain

> So take the relays out of the path by putting up a 6to4 router and a
> 2002:: prefix address on the content servers. Longest match will
> cause 6to4 connected systems to prefer that prefix while native
> connected systems will prefer the current prefix. The resulting IPv4
> path will be exactly what it is today door-to-door. Forcing traffic
> through a third party by holding to a purity principle for dns, and
> then complaining about the results is not exactly the most productive
> thing one could do.

If you add a 6to4 AAAA record to your domain name, you'll attract 6to4
traffic from a lot of systems that would earlier have used IPv4. This is
because 6to4<->6to4 is preferred above IPv4<->IPv4 in RFC 3484 (which in
turn is preferred aboue 6to4<->NativeV6).

This in turn results in a net decrease of reliability, as 6to4 is
extremely unreliable, even in the situation where the relays are known
to work correctly - the failure rate in this case has been indepentently
verified by Emile Aben of the RIPE NCC
(https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really) and
Geoff Huston of APNIC
(http://www.potaroo.net/ispcol/2010-12/6to4fail.html) to be in the 15%
ballpark.

Also, I actually tried it myself, by ?triple-stacking? (adding a 6to4
AAAA) the dual-stack measurement point in my own brokenness experiment
(http://fud.no/ipv6). Overall brokenness increased about ten-fold, from
around 0.03% to 0.3%, so the change was reverted the next day.

In conclusion, publishing 6to4 AAAA records is a terrible idea if
you're concerned about reliability.

> The argument is that enterprise firewalls are blocking it, but that
> makes no sense because many/most enterprises are in 1918 space so 
> 6to4 will not be attempted to begin with, and for those that have
> public space internally the oft-cited systems that are domain members
> will have 6to4 off by default. To get them to turn it on would
> require the IT staff to explicitly enable it for the end systems but
> then turn around and block it at the firewall ... Not exactly a
> likely scenario.

Perhaps most enterprises are in 1918 space, but I don't the reasoning
why an enterprise that are not using 1918 space would be more likely to
use Active Directory than those that are using 1918 space. I would have
thought that the use of AD is completely orthogonal the use of 1918 space?

In any case, there's no shortage of 6to4 implementations in the wild that
will happily enable 6to4 from 1918 addresses even though it cannot
possibly work.

> The most likely source of public space for non-domain joined systems
> would be universities,

My data shows that university networks are overrepresented with broken
end-users, yes.

> but no one that is complaining about protocol 41 filtering has shown
> that the source addresses are coming from those easily identifiable
> places.

http://www.fud.no/ipv6/snapshot-20101221/gnuplot/nouninett-t10-historic.png

The red line is the overall internet brokenness I measured. The green
line is the overall brokenness for the internet *except* UNINETT, the
Norwegian University and Research Network, which filters proto-41. So
that particular network with some tens of thousands of end users are
responsible for around one-third of all failed dual-stack connection
attempts, in a country that has around five million citizens.

The sharp drop at the end is when they finally deployed native IPv6 at
certain proto-41-filtered problem spots in their network, by the way.

> That leaves the case of networks that use public addresses
> internally, but nat those at the border. This would confuse the
> client into thinking 6to4 should be viable, only to have protocol 41
> blocked by the nat. These networks do exist,

End users in such networks are likely to increase sharply in numbers,
thanks to IPv4 depletion and the inevitable deployment of CGNs using
bogon or unrouted public addresses.

> The 6rd hack is nothing more than 6to4 in a different prefix to get
> around the one-liner that should be ignored in the original RFC that
> said to only publish the /16 into IPv6 bgp. I can already hear the
> screams about routing table, but there is no difference between the
> impact of a 6rd specific announcement and a deaggregate of 2002::

Only in the case that the 2002::/16-deaggregating ISP only has *one*
IPv4 PA allocation, and that the 6RD using ISP you're comparing it to
gets a *separate* IPv6 PA allocation dedicated to 6RD end users,
something which I don't believe will be granted in the RIPE region at
least.

The only well-known deployment of 6RD (Free.fr / AS12322) currently
originate 18 IPv4 prefixes and a single IPv6 prefix. With your solution
they would need to originate 18 deaggregates of 2002::/16 instead, in
addition to their single IPv6 PA allocation for native deployments.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27



From righa.shake at gmail.com  Wed May 11 03:28:07 2011
From: righa.shake at gmail.com (Righa Shake)
Date: Wed, 11 May 2011 11:28:07 +0300
Subject: Global Crossing Contact
Message-ID: <BANLkTin_aiobs_K0gamKksPxr2rodfymOw@mail.gmail.com>

Kindly would any contact from Global Crossing Please contact me offlist.

Thanks.

Regards,
Righa Shake


From iljitsch at muada.com  Wed May 11 03:53:00 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 11 May 2011 10:53:00 +0200
Subject: Yahoo and IPv6
In-Reply-To: <1305074385.18376.566.camel@karl>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
	<alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>
	<20110511001917.A4B22EA2778@drugs.dv.isc.org>
	<1305074385.18376.566.camel@karl>
Message-ID: <03C70CDE-8169-437B-8394-26F839413893@muada.com>

On 11 mei 2011, at 2:39, Karl Auer wrote:

> On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:
>> For the record Apple's current iChat (the OS (10.6.7) is completely
>> up to date) fails such a test.  It will try IPv6 and not fallback
>> to IPv4.  End users shouldn't be seeing these sorts of errors.

Hm, I've had a very hard time finding any IPv6-capable servers to let my iChat talk to...

> Is that possibly a failure of the underlying resolver library? Do other
> applications on the same platform behave correctly?

Apple's Mail application used to do this, but after many years they fixed this, it will now fall back to IPv4 without trouble. This isn't a resolver issue, as the resolver can't know whether IPv6 connectivity does or doesn't work. The resolver simply gives applications that don't explicitly ask for a particular address type all of the addresses of all types for which the system currently has connectivity, I think as determined by the presence of a default route, maybe the presence of an address also matters.

What applications need to do when they connect to a remote server is to try the next address when the first one fails and cycle through all addresses before giving up. Of course with IPv4 having multiple addresses is extremely rare so IPv4 applications typically don't bother with this, so it has to be addressed when IPv6ifying applications.


From igor at gashinsky.net  Wed May 11 04:12:05 2011
From: igor at gashinsky.net (Igor Gashinsky)
Date: Wed, 11 May 2011 05:12:05 -0400 (EDT)
Subject: Yahoo and IPv6
In-Reply-To: <001f01cc0f94$4e7293d0$eb57bb70$@iname.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net> <4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<001f01cc0f94$4e7293d0$eb57bb70$@iname.com>
Message-ID: <Pine.LNX.4.64.1105110510560.16442@moonbase.nullrouteit.net>

On Tue, 10 May 2011, Frank Bulk wrote:

:: If I can anticipate Igor's response, he'll say that he'll whitelist those
:: IPv6-only networks and so he's just help 182,000 people.

That's a very good guess as to what I was going to say :)

-igor

:: -----Original Message-----
:: From: Owen DeLong [mailto:owen at delong.com] 
:: Sent: Tuesday, May 10, 2011 1:23 PM
:: To: Igor Gashinsky
:: Cc: nanog at nanog.org
:: Subject: Re: Yahoo and IPv6
:: 
:: On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:
:: 
:: > On Tue, 10 May 2011, Valdis.Kletnieks at vt.edu wrote:
:: > 
:: > :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said:
:: > :: 
:: > :: > The time for finger-pointing is over, period, all we are all trying
:: to do 
:: > :: > now is figure out how to deal with the present (sucky) situation. The
:: 
:: > :: > current reality is that for a non-insignificant percentage of users
:: when 
:: > :: > you enable dual-stack, they are gong to drop off the face of the
:: planet. 
:: > :: > Now, for *you*, 0.026% may be insignificant (and, standalone, that
:: number 
:: > :: > is insignificant), but for a global content provider that has ~700M
:: users, 
:: > :: > that's 182 *thousand* users that *you*, *through your actions* just
:: took 
:: > :: > out.. 182,000 - that is *not* insignificant
:: > :: 
:: > :: At any given instant, there's a *lot* more than 182,000 users who are
:: cut off
:: > :: due to various *IPv4* misconfigurations and issues.
:: > 
:: > Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, 
:: > and you are asking *me* to break them through *my* actions. Sorry, that's 
:: > simply too many to break for me, without a damn good reason to do so.
:: > 
:: In other words, Igor can't turn on AAAA records generally until there are
:: 182,001 IPv6-only users that are broken from his lack of AAAA records.
:: 
:: Given IP address consumption rates in Asia and the lack of available IPv4
:: resources in Asia, with a traditional growth month to month of nearly
:: 30 million IPv4 addresses consumed, I suspect it will not be long before
:: the 182,001 broken IPv6 users become relevant.
:: 
:: > Doing that on world ipv6 day, when there is a lot of press, and most other
:: 
:: > large content players doing the same, *is* a good reason - it may actually
:: 
:: > has a shot of accomplishing some good, since it may get those users to 
:: > realize that they are broken, and fix their systems, but outside of flag 
:: > day, if I enabled AAAA by default for all users, all I'm going to do is 
:: > send those "broken" users to my competitors who chose not to enable AAAA 
:: > on their sites. 
:: > 
:: Agreed. I think IPv6 day is a great plan for this very reason. I also hope
:: that
:: a lot of organizations that try things out on IPv6 day will decide that the
:: brokenness that has been so hyped wasn't actually noticeable and then
:: leave their AAAA records in place. I do not expect Yahoo or Google to
:: be among them, but, hopefully a lot of other organizations will do so.
:: 
:: > This is why I think automatic, measurement-based whitelisting/blacklisting
:: 
:: > to minimize the collateral damage of enabling AAAA is going to be 
:: > inevitable (with the trigger set to something around 99.99%), and about 
:: > the only way we see wide-scale IPv6 adoption by content players, outside 
:: > events like world ipv6 day.
:: > 
:: This will be interesting. Personally, I think it will be more along the
:: lines
:: of when there are more IPv6 only eye-balls with broken IPv4 than there
:: are IPv4 eye-balls with broken IPv6, AAAA will become the obvious
:: solution.
:: 
:: In my opinion, this is just a matter of time and will happen much sooner
:: than
:: I think most people anticipate.
:: 
:: Owen
:: 
:: 



From kmedcalf at dessus.com  Wed May 11 06:52:13 2011
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Wed, 11 May 2011 07:52:13 -0400
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
Message-ID: <5f713bd4b694ac42a8bb61aa6001a82f@mail.dessus.com>

Luis Marta wrote on?2011-05-10:


> In the EU you have Directive 2006/24/EC: http://eur-
> lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:105:0054:0063:EN:PDF
 
> Article 6 - Periods of retention
> Member States shall ensure that the categories of data specified in Article
> 5 are retained for periods of not less than six months and not more than two
> years from the date of the communication.
 
> Article 5 - Categories of data to be retained
> 1. Member States shall ensure that the following categories of data are
> retained under this Directive:
> (a) data necessary to trace and identify the source of a communication:
> (...) the name and address of the subscriber or registered user to whom an
> Internet Protocol (IP) address, user ID or telephone number was allocated at
> the time of the communication;

The real problem is in the stupid wording.  The IP Address is not allocated to a "subscriber" or "registered user".  It is handed out for use on an authorized circuit.  That circuit is being paid for by someone.  There is no nexus between a "circuit number" and a "subscriber" or "user" (or there should not be -- and there only is if YOU CHOOSE TO CREATE SUCH).  If network operators behaved rationally, the proper response to any request to divulge information related to an IP address would be limited to the Account Number which was paying for the circuit on which the IP Address was allocated WITH NO IDENTIFICATION OF ANY INDIVIDUAL WHATSOEVER.

The entire problem is being created by Network Operators who are making up answers that they cannot prove are true, and causing grief to their customers.

Eventually some customer will decide to challenge the Network Operator to prove their allegations of misfeasance.  The result will be that the Network Operators will lose, and lose big time.  After all, it is the Network Operators who are the accusers -- not the media mafia.  

> Each member state creates its own law, according to the directive. In
> Portugal, you have to retain the data for one year.
> 
> Best Regards,
> Lu?s Marta.

--- Keith Medcalf
()? ascii ribbon campaign against html e-mail
/\? www.asciiribbon.org







From lists at internetpolicyagency.com  Wed May 11 07:39:10 2011
From: lists at internetpolicyagency.com (Roland Perry)
Date: Wed, 11 May 2011 13:39:10 +0100
Subject: 23,000 IP addresses
In-Reply-To: <5f713bd4b694ac42a8bb61aa6001a82f@mail.dessus.com>
References: <BANLkTi=JibcFVCST7AqDzMuyviMw5Wq=cQ@mail.gmail.com>
	<5f713bd4b694ac42a8bb61aa6001a82f@mail.dessus.com>
Message-ID: <dCyei5OuNoyNFAMs@perry.co.uk>

In article <5f713bd4b694ac42a8bb61aa6001a82f at mail.dessus.com>, Keith 
Medcalf <kmedcalf at dessus.com> writes
>> Article 5 - Categories of data to be retained
>> 1. Member States shall ensure that the following categories of data are
>> retained under this Directive:
>> (a) data necessary to trace and identify the source of a communication:
>> (...) the name and address of the subscriber or registered user to whom an
>> Internet Protocol (IP) address, user ID or telephone number was allocated at
>> the time of the communication;
>
>The real problem is in the stupid wording.  The IP Address is not allocated to a "subscriber" or "registered user".  It is handed out for use
>on an authorized circuit.  That circuit is being paid for by someone.  There is no nexus between a "circuit number" and a "subscriber" or
>"user" (or there should not be -- and there only is if YOU CHOOSE TO CREATE SUCH).

While there's an argument that the circuit number doesn't identify the 
user, it most certainly identifies the Subscriber, who is the person who 
has the legal contract for supply of the circuit.

>If network operators behaved rationally, the proper response to any request to divulge information related to an IP address would be limited to
>the Account Number which was paying for the circuit on which the IP Address was allocated WITH NO IDENTIFICATION OF ANY INDIVIDUAL WHATSOEVER.

So you'd give out the bank/credit card number, but not the name? The 
legislation above asks for the name and address, and in many 
jurisdictions revealing the credit card number or bank account number 
would be regarded as *more* intrusive, not less.
-- 
Roland Perry



From michael.holstein at csuohio.edu  Wed May 11 07:48:26 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Wed, 11 May 2011 08:48:26 -0400
Subject: 23,000 IP addresses
In-Reply-To: <41A477543C481FC8B6326A5C@mac-pro.magehandbook.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<41A477543C481FC8B6326A5C@mac-pro.magehandbook.com>
Message-ID: <4DCA859A.3040205@csuohio.edu>


>> I wonder how things go if you challenge them in court.  This is surely a
>> topic for another list, but it seems to me it'd be fairly difficult to
>> prove unless they downloaded part of the movie from your IP and verified
>> that what they got really was a part of the movie. 

I have the netflow records to prove this is NOT the case. All
MediaSentry (et.al.) do is scrape the tracker. We have also received a
number of takedown notices that have numbers transposed, involve parts
of our netblock that were not in use at the time in question, etc.

I would think that whole "penalty of perjury" thing would have some
weight behind it.

Stanford (in)famously managed to get DMCA notices for all the printers
on campus, just by faking a client into putting the printer's IP into
the tracker as a seed.

Cheers,

Michael Holstein
Cleveland State University



From marka at isc.org  Wed May 11 08:07:26 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 11 May 2011 23:07:26 +1000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Wed, 11 May 2011 10:53:00 +0200."
	<03C70CDE-8169-437B-8394-26F839413893@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<A2CF645C-A565-494A-AE3E-8D0C1D9BA814@muada.com>
	<Pine.LNX.4.64.1105101234020.2651@moonbase.nullrouteit.net>
	<3DC34A9C-2AC6-466E-8895-3601FD7DCCF6@kumari.net>
	<C6AEEC24-AA5D-4B73-88C8-FE644AE8DA94@muada.com>
	<alpine.BSF.2.00.1105101608140.19724@goat.gigo.com>
	<20110511001917.A4B22EA2778@drugs.dv.isc.org>
	<1305074385.18376.566.camel@karl>
	<03C70CDE-8169-437B-8394-26F839413893@muada.com>
Message-ID: <20110511130726.868FAEAA635@drugs.dv.isc.org>


In message <03C70CDE-8169-437B-8394-26F839413893 at muada.com>, Iljitsch van Beijn
um writes:
> On 11 mei 2011, at 2:39, Karl Auer wrote:
> 
> > On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:
> >> For the record Apple's current iChat (the OS (10.6.7) is completely
> >> up to date) fails such a test.  It will try IPv6 and not fallback
> >> to IPv4.  End users shouldn't be seeing these sorts of errors.
> 
> Hm, I've had a very hard time finding any IPv6-capable servers to let my =
> iChat talk to...

Well I found this bug because the jabber server was IPv4 only and
the box it is on got a AAAA address.  The jabber server is now
running dual stack with the IPv6 ports being forwarded to the IPv4
ports.  It's not optimal but it works.

> > Is that possibly a failure of the underlying resolver library? Do =
> other
> > applications on the same platform behave correctly?
> 
> Apple's Mail application used to do this, but after many years they =
> fixed this, it will now fall back to IPv4 without trouble. This isn't a =
> resolver issue, as the resolver can't know whether IPv6 connectivity =
> does or doesn't work. The resolver simply gives applications that don't =
> explicitly ask for a particular address type all of the addresses of all =
> types for which the system currently has connectivity, I think as =
> determined by the presence of a default route, maybe the presence of an =
> address also matters.
 
> What applications need to do when they connect to a remote server is to =
> try the next address when the first one fails and cycle through all =
> addresses before giving up. Of course with IPv4 having multiple =
> addresses is extremely rare so IPv4 applications typically don't bother =
> with this, so it has to be addressed when IPv6ifying applications.=

This is basic RFC 1123 multihome support.

Also see https://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From robert at tellurian.com  Wed May 11 09:08:00 2011
From: robert at tellurian.com (Robert Boyle)
Date: Wed, 11 May 2011 10:08:00 -0400
Subject: Japan electrical power?
Message-ID: <1305122882_1251374@mail1.tellurian.net>

Hello,

This is sort of off-topic, but no where near as much as half of the 
topics on NANOG. It is relevant to netops for anyone who has a 
presence in Japan. Does anyone on NANOG have firsthand in-depth 
knowledge of the electrical system in Japan? I know voltage varies 
from town to town and prefecture to prefecture. It seems most is 
90V-110V. Do most homes and businesses have a single leg or do they 
have 200-220V available? Are most circuit breakers 15A? Do they use 
20A anywhere? What is used in commercial settings? What is the 
typical service to a home? 60A, 100A, 200A? I have searched, but 
haven't found enough definitive info to be useful. I am designing 
some new equipment and Japan is the worst case scenario from a power 
standpoint because they use such a low line voltage. If my gear works 
in rocky & mountainous low-voltage Japan, it will work anywhere. Any 
information or good links would be appreciated. I can't give out any 
info on the new gear yet until some key IP is protected. It doesn't 
compete with anything on the market today. Thanks for any help anyone 
can give. Domo arigato!

-Robert


"Well done is better than well said." - Benjamin Franklin




From ken at sizone.org  Wed May 11 09:32:18 2011
From: ken at sizone.org (Ken Chase)
Date: Wed, 11 May 2011 10:32:18 -0400
Subject: 23,000 IP addresses
In-Reply-To: <4DC9ECE8.10307@ispworkshop.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>
	<4DC9ECE8.10307@ispworkshop.com>
Message-ID: <20110511143217.GN23277@sizone.org>

On Wed, May 11, 2011 at 09:56:56AM +0800, Ong Beng Hui said:

> while, I am not a lawyer, so what after they know who is using that  
> broadband connection for that IP. So, they have identified the 80yr old,  
> what next ? and what if i have a free-for-all wireless router in my  
> house which anyone can tap on, which i regularly switch off during  
> nighttime for energy saving reason. :)

Simple. Just make having clue on configuring your wifi AP a legal requirement. :)

Sides, since WPA is cracked now too, to some extent, i dont think most APs
have any sort of guaranteed protection. Hell, it's better to leave it wide
open, as having the prosecution accuse you of child porn because you used a
hard-but-crackable WPA2 ("it's one in a billion to crack it! beyond a
reasonable doubt! we dont have anyone anywhere in our IT who could possibly
crack it!") instead of WEP or wide open seems like a greater pitfall.

What about projects like http://NoCat.net - will they be made illegal? That's going
to be an awesome can of worms.

/kc
-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.



From lost at l-w.ca  Wed May 11 09:39:43 2011
From: lost at l-w.ca (William Astle)
Date: Wed, 11 May 2011 08:39:43 -0600
Subject: IPv6 foot-dragging
Message-ID: <4DCA9FAF.70409@l-w.ca>

There has been much talk about IPv6 lately, and for good reason.
Whatever your opinion on whether IPv6 is a good solution to IPv4 address
exhaustion, it's the only solution we have. Yet deployment, at least in
North America, has been ridiculously slow.

I have just been informed by a sales rep for AS852 that they are not
deploying IPv4 until 2012. 2012? Really?

I've heard statements that AS701 has deployed IPv6 on their network but
I've yet to see any evidence of that in my area of Canada. Apparently
they "forgot" Canada when they did it. Now I'm informed, unofficially,
that they might maybe have it deployed, if I'm lucky, some time before
the end of 2011.

I think the above two points illustrate precisely why so many networks
in North America simply cannot deploy IPv6 whether they want to or not.
We simply cannot obtain IPv6 transit from our upstreams. It's just not
available. And the old line about "vote with your money" doesn't work
when you have limited choices.



From morrowc.lists at gmail.com  Wed May 11 09:42:33 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 11 May 2011 10:42:33 -0400
Subject: 23,000 IP addresses
In-Reply-To: <4DCA859A.3040205@csuohio.edu>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<41A477543C481FC8B6326A5C@mac-pro.magehandbook.com>
	<4DCA859A.3040205@csuohio.edu>
Message-ID: <BANLkTimJezgd1gjJgCqoeOFfWy3AnObWPw@mail.gmail.com>

On Wed, May 11, 2011 at 8:48 AM, Michael Holstein
<michael.holstein at csuohio.edu> wrote:
>
>>> I wonder how things go if you challenge them in court. ?This is surely a
>>> topic for another list, but it seems to me it'd be fairly difficult to
>>> prove unless they downloaded part of the movie from your IP and verified
>>> that what they got really was a part of the movie.
>
> I have the netflow records to prove this is NOT the case. All
> MediaSentry (et.al.) do is scrape the tracker. We have also received a
> number of takedown notices that have numbers transposed, involve parts
> of our netblock that were not in use at the time in question, etc.

this is exactly the same situation I outlined previously...
darknet/tcdump can't be a bittorrent user.

> I would think that whole "penalty of perjury" thing would have some
> weight behind it.

apparently not :( (I'd say something about lobbyists et.al, but...)

-chris



From kloch at kl.net  Wed May 11 09:47:51 2011
From: kloch at kl.net (Kevin Loch)
Date: Wed, 11 May 2011 10:47:51 -0400
Subject: .io registrar
In-Reply-To: <4DC981A3.7060402@jeremykister.com>
References: <4DC981A3.7060402@jeremykister.com>
Message-ID: <4DCAA197.3080508@kl.net>

Jeremy Kister wrote:
> Does anyone know of a competent .io registrar who charges in the <= 
> $75/yr area ?
> 
> I've been using tierra.net (domaindiscover.com) but they continually 
> break my domains.
> 
> this year, although their website says my domain expires 4/2012, my 
> domain stopped working today.  the .io servers aren't serving records, 
> and nic.io says the domain expired 4/8/2011.
> 
> i got a hold of them this morning got a ticket -- but after 4 hours 
> still no response.
> 
> 
> also, although nic.io lists a bunch of .io registrars, when I called 
> them they almost all say "we don't register .io" :D

I have a .io domain with Moniker and have not had any problems.

- Kevin



From iljitsch at muada.com  Wed May 11 09:50:41 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 11 May 2011 16:50:41 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <4DCA9FAF.70409@l-w.ca>
References: <4DCA9FAF.70409@l-w.ca>
Message-ID: <8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>

On 11 mei 2011, at 16:39, William Astle wrote:

> I think the above two points illustrate precisely why so many networks
> in North America simply cannot deploy IPv6 whether they want to or not.
> We simply cannot obtain IPv6 transit from our upstreams. It's just not
> available. And the old line about "vote with your money" doesn't work
> when you have limited choices.

Apparently the need for IPv6 isn't yet high enough to consider adding a transit provider. I've seen enough press releases from NTT and HE to know there's at least two that can do this out there.




From jeroen at unfix.org  Wed May 11 09:51:00 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 11 May 2011 16:51:00 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <4DCA9FAF.70409@l-w.ca>
References: <4DCA9FAF.70409@l-w.ca>
Message-ID: <4DCAA254.40604@unfix.org>

On 2011-May-11 16:39, William Astle wrote:
[..]
> I think the above two points illustrate precisely why so many networks
> in North America simply cannot deploy IPv6 whether they want to or not.
> We simply cannot obtain IPv6 transit from our upstreams. It's just not
> available. And the old line about "vote with your money" doesn't work
> when you have limited choices.

And you have just found out why transition technologies exist.

They are called 'transition' for a reason: during the time that you
cannot get (proper) native connectivity you can set up a tunnel to an
entity that can provide you with proper IPv6.

The same way you can also set up a IPv6-only transit session with a
party that is located at an IX or such you are at. Might just be to
cover the time till your current transits do support IPv6.

It is just a way around the problem, it might not be nice but it can
work and you can get ready, and might get enough insight on why not to
use that organization any more who is causing all the feet to be dragged.

Greets,
 Jeroen





From michael.holstein at csuohio.edu  Wed May 11 09:59:08 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Wed, 11 May 2011 10:59:08 -0400
Subject: 23,000 IP addresses
In-Reply-To: <20110511143217.GN23277@sizone.org>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<D338D1613B32624285BB321A5CF3DB25134C5118FA@ginga.ai.net>	<4DC9ECE8.10307@ispworkshop.com>
	<20110511143217.GN23277@sizone.org>
Message-ID: <4DCAA43C.9010006@csuohio.edu>


> ("it's one in a billion to crack it! beyond a
> reasonable doubt! we dont have anyone anywhere in our IT who could possibly
> crack it!") 

A billion iterations takes what fraction of a second using a high-end
multi-card gamer rig and CUDA? (or for the cheap/lazy, a S3/Tesla instance).

Even for brute-force, although WPA2 is salted with the SSID, 95% of the
time it's still "Linksys". Rainbow tables for the ~140 most common SSIDs
are already available.

I once used GPS and a wifi analyizer to show a map of how large the
possible "cloud" around a standard WRT54G and 2nd floor installation of
the accused's router really was. To make it dumb enough, I used the
pringle's cantenna (literally) instead of a commercial antenna.

The "CSI effect" works when the defense does it too. Juries love to hear
techie stuff these days, it's just that the defense usually can't afford
it. If a sizable community of technical folks were to pro-bono as expert
witnesses, the "presumption of innocence" would return pretty fast.

Cheers,

Michael Holstein
Cleveland State University



From nanog at jima.tk  Wed May 11 10:00:18 2011
From: nanog at jima.tk (Jima)
Date: Wed, 11 May 2011 10:00:18 -0500
Subject: IPv6 foot-dragging
In-Reply-To: <8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
Message-ID: <4DCAA482.8050305@jima.tk>

On 05/11/2011 09:50 AM, Iljitsch van Beijnum wrote:
> On 11 mei 2011, at 16:39, William Astle wrote:
>
>> I think the above two points illustrate precisely why so many networks
>> in North America simply cannot deploy IPv6 whether they want to or not.
>> We simply cannot obtain IPv6 transit from our upstreams. It's just not
>> available. And the old line about "vote with your money" doesn't work
>> when you have limited choices.
>
> Apparently the need for IPv6 isn't yet high enough to consider adding a transit provider. I've seen enough press releases from NTT and HE to know there's at least two that can do this out there.

  Funny, I was just involved in a discussion on IPv6 in Canada 
yesterday, and this link came up from multiple people: 
http://bgpmon.net/blog/?p=382 .  There's also 
http://www.vyncke.org/ipv6status/detailed.php?country=ca&type=ISP , but 
I've seen some indications that there may be some inaccuracies 
(Allstream announcing 2001:04c8::/33, for instance).

      Jima



From james at jamesstewartsmith.com  Wed May 11 10:03:37 2011
From: james at jamesstewartsmith.com (james at jamesstewartsmith.com)
Date: Wed, 11 May 2011 15:03:37 +0000
Subject: IPv6 foot-dragging
In-Reply-To: <4DCA9FAF.70409@l-w.ca>
References: <4DCA9FAF.70409@l-w.ca>
Message-ID: <1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>

I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed.  These are also some of the more expensive providers on a per Mb basis.  The one provider that was full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)





Sent from my ?contract free? BlackBerry? smartphone on the WIND network.

-----Original Message-----
From: William Astle <lost at l-w.ca>
Date: Wed, 11 May 2011 08:39:43 
To: <nanog at nanog.org>
Subject: IPv6 foot-dragging

There has been much talk about IPv6 lately, and for good reason.
Whatever your opinion on whether IPv6 is a good solution to IPv4 address
exhaustion, it's the only solution we have. Yet deployment, at least in
North America, has been ridiculously slow.

I have just been informed by a sales rep for AS852 that they are not
deploying IPv4 until 2012. 2012? Really?

I've heard statements that AS701 has deployed IPv6 on their network but
I've yet to see any evidence of that in my area of Canada. Apparently
they "forgot" Canada when they did it. Now I'm informed, unofficially,
that they might maybe have it deployed, if I'm lucky, some time before
the end of 2011.

I think the above two points illustrate precisely why so many networks
in North America simply cannot deploy IPv6 whether they want to or not.
We simply cannot obtain IPv6 transit from our upstreams. It's just not
available. And the old line about "vote with your money" doesn't work
when you have limited choices.


From mike at sentex.net  Wed May 11 10:10:41 2011
From: mike at sentex.net (Mike Tancsa)
Date: Wed, 11 May 2011 11:10:41 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
Message-ID: <4DCAA6F1.6020304@sentex.net>

On 5/11/2011 11:03 AM, james at jamesstewartsmith.com wrote:
> I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed.  These are also some of the more expensive providers on a per Mb basis.  The one provider that was full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)

There are a number of networks in Canada that provide v6 transit both
big and small.  I have v6 transit from TATA, HE and Cogent out of
Toronto.  Many Canadian networks peer at Torix which also lists their v6
status.

http://www.torix.net/peers.php



	---Mike


-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/



From william.allen.simpson at gmail.com  Wed May 11 10:16:01 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Wed, 11 May 2011 11:16:01 -0400
Subject: 23,000 IP addresses
In-Reply-To: <4DC9F5F9.9090407@amplex.net>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC943A4.40005@amplex.net>	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
	<4DC9F5F9.9090407@amplex.net>
Message-ID: <4DCAA831.1020902@gmail.com>

On 5/10/11 10:35 PM, Mark Radabaugh wrote:
> Facebook charges $150.00 (not a great link but http://lawyerist.com/subpoena-facebook-information/
>
Sorry, that's old and incorrect.


> Finding that on facebook's site is difficult. Other sites have Facebook charging $250 to $500 for civil subpoena fees.
>
http://www.facebook.com/help/?faq=17159

... you must personally serve a valid California or Federal subpoena on
Facebook. Out-of-state civil subpoenas must be domesticated in California.

...

Facebook charges a mandatory fee of $500.00 per user account. Please
enclose payment with your properly served subpoenas. A custodian
declaration will be included with the return of materials, if any.
Notarized declarations carry an additional $100.00 fee.

http://www.facebook.com/help/?faq=17160

Facebook requires a minimum of 30 days to process a civil subpoena.
Additional time may be required depending on various factors. You may
request your subpoena be expedited by submitting an additional $200.00 fee
with your subpoena.


> Courts like precedent. I choose Facebook's precedent. Seems reasonable to me.
>
That's also roughly in line with Nextel and others for CALEA.



From tme at americafree.tv  Wed May 11 10:19:06 2011
From: tme at americafree.tv (Marshall Eubanks)
Date: Wed, 11 May 2011 11:19:06 -0400
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC943A4.40005@amplex.net>
	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
Message-ID: <2B081DD5-7DBF-41A8-AD55-40FF6395ED02@americafree.tv>


On May 10, 2011, at 8:30 PM, Jimmy Hess wrote:

> On Tue, May 10, 2011 at 8:54 AM, Mark Radabaugh <mark at amplex.net> wrote:
>> On 5/10/11 9:07 AM, Marshall Eubanks wrote:
>> A good reason why every ISP should have a published civil subpoena
>> compliance fee.
>> 23,000 * $150 each should only cost them $3.45M to get the information.
>> Seems like that would take the profit out pretty quickly.
> 
> +1.
> But don't the fees actually have to be reasonable?

> 
> If you say your fee is  $150 per IP address,  I think they might bring
> it to the judge
> and claim the ISP is attempting to avoid subpoena compliance by charging an
> unreasonable fee.
> 
> They can point to all the competitors charging $40 per IP.
> 

I am not a lawyer, and you would be a fool to use NANOG for legal advice, but if I were to charge something for this, I would want
to be able to justify the charge in front of a judge, regardless of what anyone else charges. In other words, something like "we find it typically takes $ 100 to get the backups out of storage, 15 minutes @ $X per minute for a tech to find the right backup disk and 10 minutes at $Y per minute for a network engineer to review the dump." 

Regards
Marshall 



> This would be very interesting with IPv6 though,  and customers assigned /56s.
> 
> "You want all the records for every IP in this /56,  really?"
> 
> 
> --
> -JH
> 
> 




From morrowc.lists at gmail.com  Wed May 11 10:26:16 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 11 May 2011 11:26:16 -0400
Subject: 23,000 IP addresses
In-Reply-To: <4DCAA831.1020902@gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC943A4.40005@amplex.net>
	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
	<4DC9F5F9.9090407@amplex.net> <4DCAA831.1020902@gmail.com>
Message-ID: <BANLkTimu40ATbuMYoefMe-S3CxoYiPBfdw@mail.gmail.com>

On Wed, May 11, 2011 at 11:16 AM, William Allen Simpson
<william.allen.simpson at gmail.com> wrote:

>> Courts like precedent. I choose Facebook's precedent. Seems reasonable to
>> me.
>>
> That's also roughly in line with Nextel and others for CALEA.

Hrm, I had thought that CALEA specifically removed the ability of the
Provider to charge for the 'service'? Though there is always the case
where the Provider can say: "Yes, this doesn't fall into the CALEA
relevant requests, we can do this for you though it will cost
time/materials to do, here's our schedule..."

or that's the stance a previous employer was taking... (at the
direction of their lawyer-catzen)



From lost at l-w.ca  Wed May 11 10:32:40 2011
From: lost at l-w.ca (William Astle)
Date: Wed, 11 May 2011 09:32:40 -0600
Subject: IPv6 foot-dragging
In-Reply-To: <4DCAA6F1.6020304@sentex.net>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCAA6F1.6020304@sentex.net>
Message-ID: <4DCAAC18.6050505@l-w.ca>

On 2011-05-11 09:10, Mike Tancsa wrote:
> On 5/11/2011 11:03 AM, james at jamesstewartsmith.com wrote:
>> I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed.  These are also some of the more expensive providers on a per Mb basis.  The one provider that was full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)
> 
> There are a number of networks in Canada that provide v6 transit both
> big and small.  I have v6 transit from TATA, HE and Cogent out of
> Toronto.  Many Canadian networks peer at Torix which also lists their v6
> status.
> 
> http://www.torix.net/peers.php

That highlights another problem I have. I have no presence in Toronto,
nor do I have a business case (or resources) to build a presence there.
The same applies to Vancouver which is the other popular city for such
things.

I do currently employ a tunnel from HE's tunnel broker and, as a result,
I'm reasonably sure I can make IPv6 work when I have proper transit for
it. However, it would be impolite at best to turn up any sort of
production service over such a tunnel.

Speaking from the perspective of a *small* network with very limited
resources, adding a transit provider, even if one is available, is very
expensive. Installation costs tend to dwarf any business gain, often
running well into the 5 figure range. The same applies to switching
transit providers. (Install costs are the same in either case.)



From mark at amplex.net  Wed May 11 10:48:23 2011
From: mark at amplex.net (Mark Radabaugh)
Date: Wed, 11 May 2011 11:48:23 -0400
Subject: 23,000 IP addresses
In-Reply-To: <2B081DD5-7DBF-41A8-AD55-40FF6395ED02@americafree.tv>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC943A4.40005@amplex.net>
	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
	<2B081DD5-7DBF-41A8-AD55-40FF6395ED02@americafree.tv>
Message-ID: <4DCAAFC7.1060908@amplex.net>

On 5/11/11 11:19 AM, Marshall Eubanks wrote:
> On May 10, 2011, at 8:30 PM, Jimmy Hess wrote:
>
>> On Tue, May 10, 2011 at 8:54 AM, Mark Radabaugh<mark at amplex.net>  wrote:
>>> On 5/10/11 9:07 AM, Marshall Eubanks wrote:
>>> A good reason why every ISP should have a published civil subpoena
>>> compliance fee.
>>> 23,000 * $150 each should only cost them $3.45M to get the information.
>>> Seems like that would take the profit out pretty quickly.
>> +1.
>> But don't the fees actually have to be reasonable?
>> If you say your fee is  $150 per IP address,  I think they might bring
>> it to the judge
>> and claim the ISP is attempting to avoid subpoena compliance by charging an
>> unreasonable fee.
>>
>> They can point to all the competitors charging $40 per IP.
>>
> I am not a lawyer, and you would be a fool to use NANOG for legal advice, but if I were to charge something for this, I would want
> to be able to justify the charge in front of a judge, regardless of what anyone else charges. In other words, something like "we find it typically takes $ 100 to get the backups out of storage, 15 minutes @ $X per minute for a tech to find the right backup disk and 10 minutes at $Y per minute for a network engineer to review the dump."
>
> Regards
> Marshall

Don't forget to include your attorneys time to verify that the subpoena 
is actually legal.  That would add another $100 to the cost at a minimum.

We recently almost released information on a customer in an attempt to 
comply with what appeared to be a valid subpoena.  The subpoena was 
invalid and thankfully our attorney noticed it.   I fully expect the 
bill for the legal advice to be at least $100.00

Really the point though is to charge *some* fee for complying.  It 
doesn't really matter what the fee is.  The reason they sue 10,000 
defendants in one case is to avoid having to pay the $350 (or similar) 
fee to the court for each defendant.   If the ISP's don't charge for 
providing this information a copyright holder can file a civil suit, 
issue subpoena's based on the filing, and intimidate defendants with 
settlement offers before the case gets thrown out of court for 
improperly joining defendants.

http://houstonlawyer.wordpress.com/2011/03/18/over-10000-internet-users-dismissed-from-copyright-infringement-lawsuit-in-a-slight-of-hand-letter-to-the-court/

Add any significant cost to the process of figuring out who the actual 
customers are and the profit motive goes out the window.

-- 
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015




From gbonser at seven.com  Wed May 11 12:01:20 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 11 May 2011 10:01:20 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>

> 
> Apparently the need for IPv6 isn't yet high enough to consider adding
a
> transit provider. I've seen enough press releases from NTT and HE to
> know there's at least two that can do this out there.
> 

I believe the major holdup at this point is lack of v6 eyeballs.  End
user CPE, particularly DSL CPE, has been lagging in v6 capability.

As for v6 upstreams, I have native v6 with both InterNAP (may not be
available at ALL POPs yet) and HE. Savvis has yet to deploy it in the US
at the POP pertinent to our operatons.

The big push for v6 eyeballs at the current time are the mobile
operators.  We are seeing activity that would indicate there are mobile
devices out there that are native v6 at this time.  Content providers
who have a lot of mobile clients might find they have more native v6
eyeballs than they think they have.

A couple of things you can do to check.  First of all look for requests
to your DNS servers for AAAA records and note where those are coming
from.  That doesn't prove a lot but it gives some indication of who
might have v6 someplace in their network. If you are seeing a
significant number of these, the next thing I would do is get a dns
server on your network working with v6 and get that IP address in whois
even if all you are serving is v4 A records.  Then note who is arriving
over v6 asking for AAAA records.  Those are the best candidates for
enabling v6 services.  Note which services those are asking for, pick
one, and if you have gear capable of it (say, for example, a load
balancer), configure a v6 VIP for that service balancing to v4 servers
behind it.  Place the AAAA record for this service in the zone handed
out via v6 AAAA requests (ONLY!) and watch the service VIP and see if
clients are connecting.

So at this point you are handing out AAAA records for a v6 service but
ONLY for DNS requests that arrive via IPv6 asking for it.  Any requests
arriving via v4 asking for an AAAA record would get the NOERROR response
and an A record for the resource (client might have IPv6 internally but
doesn't have v6 all the way to the Internet or their Internet coverage
might be "spotty" and doesn't include you coughCogentcough).






From lowen at pari.edu  Wed May 11 12:02:22 2011
From: lowen at pari.edu (Lamar Owen)
Date: Wed, 11 May 2011 13:02:22 -0400
Subject: Japan electrical power?
In-Reply-To: <1305122882_1251374@mail1.tellurian.net>
References: <1305122882_1251374@mail1.tellurian.net>
Message-ID: <201105111302.22443.lowen@pari.edu>

On Wednesday, May 11, 2011 10:08:00 AM Robert Boyle wrote:
> I know voltage varies 
> from town to town and prefecture to prefecture. It seems most is 
> 90V-110V. 

Also, part of the country is 50Hz and part is 60Hz. 



From iljitsch at muada.com  Wed May 11 12:12:33 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 11 May 2011 19:12:33 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
Message-ID: <41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>

On 11 mei 2011, at 19:01, George Bonser wrote:

> A couple of things you can do to check.  First of all look for requests
> to your DNS servers for AAAA records and note where those are coming
> from.

Firefox has for a long time done both A and AAAA lookups even if the system doesn't have IPv6. I believe MacOS does this too, now. Don't know about other apps/OSes, but for sure you'll see tons of AAAA lookups from people who have no IPv6 connectivity.

> Then note who is arriving
> over v6 asking for AAAA records.  Those are the best candidates for
> enabling v6 services.

Now you're counting DNS servers. Because the provisioning of IPv6 DNS addresses has been such a mess and still is problematic, many dual stack systems do this over IPv4. And the DNS servers they talk to may be IPv4-only, or IPv4-only users may talk to dual stack DNS servers.

In my opinion, looking at this kind of stuff in order to draw conclusions about what you should do is a waste of time. It just means more work for everyone and it doesn't fix any of the broken stuff that's out there.

If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry-wide but this time we don't turn it off again.


From jared at puck.nether.net  Wed May 11 12:27:59 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 11 May 2011 13:27:59 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
Message-ID: <1030E504-8191-42B0-9FB3-A180EAA5345E@puck.nether.net>


On May 11, 2011, at 1:12 PM, Iljitsch van Beijnum wrote:

> On 11 mei 2011, at 19:01, George Bonser wrote:
> 
>> A couple of things you can do to check.  First of all look for requests
>> to your DNS servers for AAAA records and note where those are coming
>> from.
> 
> Firefox has for a long time done both A and AAAA lookups even if the system doesn't have IPv6. I believe MacOS does this too, now. Don't know about other apps/OSes, but for sure you'll see tons of AAAA lookups from people who have no IPv6 connectivity.

It is still a way to measure it, even if it's not that accurate.

>> Then note who is arriving
>> over v6 asking for AAAA records.  Those are the best candidates for
>> enabling v6 services.
> 
> Now you're counting DNS servers. Because the provisioning of IPv6 DNS addresses has been such a mess and still is problematic, many dual stack systems do this over IPv4. And the DNS servers they talk to may be IPv4-only, or IPv4-only users may talk to dual stack DNS servers.
> 
> In my opinion, looking at this kind of stuff in order to draw conclusions about what you should do is a waste of time. It just means more work for everyone and it doesn't fix any of the broken stuff that's out there.
> 
> If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry-wide but this time we don't turn it off again.

I'd like to see a repeat but with a week timescale.  If you parse carefully, if all the $major sites are broken in the same way at the same time, it's easier to justify leaving it broken.  (eg: if Google, Yahoo and Bing all do IPv6 at once, neither has to worry about losing market share to the other due to misbehaving ipv6.  That's how I read igor's email about the 182k users, even if I still think we would be served with a longer test).

The most interesting data for me is looking at the sites that have 'majorly' broken IPv6 dns.  I count 600+ sites that are returning weird things like ::1 or ::ffff: addresses.  My favorites are the .gov site on the list and the city of albany.

Here's a pointer to the list:

http://puck.nether.net/~jared/aaaa/very-broken-dns.txt

- Jared


From tore.anderson at redpill-linpro.com  Wed May 11 12:32:32 2011
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Wed, 11 May 2011 19:32:32 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
References: <4DCA9FAF.70409@l-w.ca>	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
Message-ID: <4DCAC830.2030807@redpill-linpro.com>

* Iljitsch van Beijnum

> Firefox has for a long time done both A and AAAA lookups even if the
> system doesn't have IPv6.

They fixed that in version 4.0, by calling getaddrinfo() with the
AI_ADDRCONFIG flag (like most other browsers do).

https://bugzilla.mozilla.org/show_bug.cgi?id=614526

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27



From gbonser at seven.com  Wed May 11 12:32:54 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 11 May 2011 10:32:54 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>

> Now you're counting DNS servers. Because the provisioning of IPv6 DNS
> addresses has been such a mess and still is problematic, many dual
> stack systems do this over IPv4. And the DNS servers they talk to may
> be IPv4-only, or IPv4-only users may talk to dual stack DNS servers.

Which is why I suggested trying it on ONE service and watching it
closely.  What I have done is selected a "best candidate" for a test.  I
am not implying that "this is guaranteed to work".

 
> If the results of world IPv6 day are as we expect and only 0.1 - 0.2 %
> or less of all people have problems, I think the best way forward
would
> be to have a second world IPv6 day where we again enable IPv6
industry-
> wide but this time we don't turn it off again.

0.1% of users is a HUGE number if you have 1,000,000 subscribers.  Are
you prepared to field 1,000 helpdesk calls or lose 1,000 customers?  Now
imagine 100,000,000 subscribers.  Are you ready for 10,000 support calls
or the loss of 10,000 paying customers? 

It isn't something you just throw out there on a whim and tell people to
like it or lump it if there are potentially a lot of people involved.





From iljitsch at muada.com  Wed May 11 12:44:14 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 11 May 2011 19:44:14 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
Message-ID: <68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>

On 11 mei 2011, at 19:32, George Bonser wrote:

>> If the results of world IPv6 day are as we expect and only 0.1 - 0.2 %
>> or less of all people have problems, I think the best way forward would
>> be to have a second world IPv6 day where we again enable IPv6 industry-
>> wide but this time we don't turn it off again.

> 0.1% of users is a HUGE number if you have 1,000,000 subscribers.  Are
> you prepared to field 1,000 helpdesk calls or lose 1,000 customers?

Apparently "we" are, at least for the former, otherwise there wouldn't be an IPv6 day.

> It isn't something you just throw out there on a whim and tell people to
> like it or lump it if there are potentially a lot of people involved.

So what's the alternative? Never change anything?

Remember, this is al extremely trivial stuff: most things won't even completely stop working. And a few mouseclicks (yes, you have to know which ones so the helpdesks better start figuring that out) and you're back to normal. Compare this to turning off analog TV transmitters that have been running for decades where people have to buy converter boxes and sometimes even install antennas on their roof to keep using the service.


From zeusdadog at gmail.com  Wed May 11 13:21:30 2011
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 11 May 2011 14:21:30 -0400
Subject: Japan electrical power?
In-Reply-To: <1305122882_1251374@mail1.tellurian.net>
References: <1305122882_1251374@mail1.tellurian.net>
Message-ID: <BANLkTik9M2V8wFQ7quPvumCVLHEtcBwPJw@mail.gmail.com>

On May 11, 2011 10:09 AM, "Robert Boyle" <robert at tellurian.com> wrote:
>
> Hello,
> I know voltage varies from town to town and prefecture to prefecture.

No, it doesn't.  Japan has two systems, both 100v, western Japan has 60Hz,
eastern Japan has 50Hz.


From Valdis.Kletnieks at vt.edu  Wed May 11 13:21:59 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 11 May 2011 14:21:59 -0400
Subject: IPv6 foot-dragging
In-Reply-To: Your message of "Wed, 11 May 2011 10:32:54 PDT."
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
Message-ID: <20667.1305138119@localhost>

On Wed, 11 May 2011 10:32:54 PDT, George Bonser said:

> 0.1% of users is a HUGE number if you have 1,000,000 subscribers.  Are
> you prepared to field 1,000 helpdesk calls or lose 1,000 customers?  Now
> imagine 100,000,000 subscribers.  Are you ready for 10,000 support calls
> or the loss of 10,000 paying customers?

Unless you have a captive audience for customers, you probably have a churn
rate higher than 0.1% *anyhow*.  And if you *do* have a captive audience, you
won't lose customers.

I would be interested in knowing if those people who say they can measure these
0.1% dips noticed anything due to the flooding and severe weather in the
midwest and southeast US in the past few weeks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110511/fe081efb/attachment.bin>

From tom at dyn.com  Wed May 11 13:23:51 2011
From: tom at dyn.com (Tom Daly)
Date: Wed, 11 May 2011 14:23:51 -0400 (EDT)
Subject: OT: Jay Adelson Keynote Video?
Message-ID: <10366544.74.1305138228168.JavaMail.tom@Tom-Dalys-MacBook-Pro.local>

Folks,

At NANOG 43, Jay Adelson had a video clip in his presentation which celebrated the hilarity that customers create for network engineers. Does anyone have a link to the video? A review of the abstract (http://nanog.org/meetings/nanog43/abstracts.php?pt=NDMmbmFub2c0Mw==&nm=nanog43) and google'ing high and low yielding no results. I seem to recall it being on BitGravity, but I don't have the URL.

Tom

-- 
Tom Daly, CTO, Dynamic Network Services, Inc.
### We're hiring software engineers, network engineers, and web developers. Learn more at http://dyn.com/why-dyn/careers. ###




From joelja at bogus.com  Wed May 11 13:26:37 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 11 May 2011 11:26:37 -0700
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTimu40ATbuMYoefMe-S3CxoYiPBfdw@mail.gmail.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>	<4DC943A4.40005@amplex.net>	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>	<4DC9F5F9.9090407@amplex.net>
	<4DCAA831.1020902@gmail.com>
	<BANLkTimu40ATbuMYoefMe-S3CxoYiPBfdw@mail.gmail.com>
Message-ID: <4DCAD4DD.2010209@bogus.com>

On 5/11/11 8:26 AM, Christopher Morrow wrote:
> On Wed, May 11, 2011 at 11:16 AM, William Allen Simpson
> <william.allen.simpson at gmail.com> wrote:
> 
>>> Courts like precedent. I choose Facebook's precedent. Seems reasonable to
>>> me.
>>>
>> That's also roughly in line with Nextel and others for CALEA.
> 
> Hrm, I had thought that CALEA specifically removed the ability of the
> Provider to charge for the 'service'? Though there is always the case
> where the Provider can say: "Yes, this doesn't fall into the CALEA
> relevant requests, we can do this for you though it will cost
> time/materials to do, here's our schedule..."
> 
> or that's the stance a previous employer was taking... (at the
> direction of their lawyer-catzen)

A civil subpeona is not a calea request. This thread has done a fair bit
of intermingling of the two things to the detriment of it's utility.

While I'm sure facebook is served with plenty of valid search warrants,
I'm reasonably  unsure that they meet the definition of
telecommunications carrier.

there's some discussion in the light of recent hearings, here:

http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html




From bill at herrin.us  Wed May 11 13:29:18 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 11 May 2011 14:29:18 -0400
Subject: Japan electrical power?
In-Reply-To: <1305122882_1251374@mail1.tellurian.net>
References: <1305122882_1251374@mail1.tellurian.net>
Message-ID: <BANLkTikX_bUt4GMjKj=Osu9kCxStJ1f6NQ@mail.gmail.com>

On Wed, May 11, 2011 at 10:08 AM, Robert Boyle <robert at tellurian.com> wrote:
> Does anyone on NANOG have firsthand in-depth knowledge of the electrical
> system in Japan?

I do not. However:

http://www.japan-guide.com/e/e2225.html
The voltage in Japan is 100 Volt
The frequency of electric current is 50 Hertz in Eastern Japan and 60
Hertz in Western Japan

http://www.japaneselawtranslation.go.jp/law/detail/?ft=1&re=01&dn=1&co=01&ky=%E9%9B%BB%E6%B0%97%E7%94%A8%E5%93%81%E5%AE%89%E5%85%A8%E6%B3%95&page=2
Electrical Appliance and Material Safety Act (Japan)

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From dougb at dougbarton.us  Wed May 11 13:30:23 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 11 May 2011 11:30:23 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <20667.1305138119@localhost>
References: <4DCA9FAF.70409@l-w.ca>	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
	<20667.1305138119@localhost>
Message-ID: <4DCAD5BF.5040107@dougbarton.us>

On 05/11/2011 11:21, Valdis.Kletnieks at vt.edu wrote:
> Unless you have a captive audience for customers, you probably have a churn
> rate higher than 0.1%*anyhow*.

This argument has already been refuted many times. Let's assume that 
you're right about the churn rate. The issue is enterprises not wanting 
to take affirmative steps to knock N% *more* customers off the site than 
whatever the current churn rate is by enabling IPv6.


-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/




From kris.foster at gmail.com  Wed May 11 13:35:01 2011
From: kris.foster at gmail.com (kris foster)
Date: Wed, 11 May 2011 11:35:01 -0700
Subject: OT: Jay Adelson Keynote Video?
In-Reply-To: <10366544.74.1305138228168.JavaMail.tom@Tom-Dalys-MacBook-Pro.local>
References: <10366544.74.1305138228168.JavaMail.tom@Tom-Dalys-MacBook-Pro.local>
Message-ID: <A635B470-86D9-4C47-976C-8947C736908F@gmail.com>

http://bitcast-b.bitgravity.com/bitgravity/nanog_5Mbit_720p_30fps.mov

I believe this is it

--
kris

On May 11, 2011, at 11:23 AM, Tom Daly wrote:

> Folks,
> 
> At NANOG 43, Jay Adelson had a video clip in his presentation which celebrated the hilarity that customers create for network engineers. Does anyone have a link to the video? A review of the abstract (http://nanog.org/meetings/nanog43/abstracts.php?pt=NDMmbmFub2c0Mw==&nm=nanog43) and google'ing high and low yielding no results. I seem to recall it being on BitGravity, but I don't have the URL.
> 
> Tom
> 
> -- 
> Tom Daly, CTO, Dynamic Network Services, Inc.
> ### We're hiring software engineers, network engineers, and web developers. Learn more at http://dyn.com/why-dyn/careers. ###
> 
> 




From gbonser at seven.com  Wed May 11 13:39:00 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 11 May 2011 11:39:00 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
	<68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>

> So what's the alternative? Never change anything?

Of course not.  But the best course forward is going to be different for
different folks.  What might work best for me might not (probably WILL
not) work best for everyone else.  One has to look at their situation
and plan the best path for their business with their architecture and
the resources they have available to them.  I suggested one option but
that might not work for others.  Others might see a strict white
listing, or maybe some combination of the two.  But there is so much
brokenness out there right now that I would hesitate to trust an AAAA
request that arrives over v4 when there is a v6 name server available.

> 
> Remember, this is al extremely trivial stuff: most things won't even
> completely stop working. And a few mouseclicks (yes, you have to know
> which ones so the helpdesks better start figuring that out) and you're
> back to normal. Compare this to turning off analog TV transmitters
that
> have been running for decades where people have to buy converter boxes
> and sometimes even install antennas on their roof to keep using the
> service.

It depends.  There are other things to take into account.  If you
increase the time it takes a mobile device to complete a transaction by
only a couple of seconds,  if you multiply those couple of seconds by
all of the users in a large metro area, you end up with devices
increased use of network resources (and increased battery drain on the
devices themselves).  Anything that can be done to speed transactions up
and get those transmitters shut off as quickly as possible is a win.  If
you don't have a lot of mobile clients hitting your site, then maybe
that isn't a problem.  Every network has their own set of resources and
their own set of challenges and all of that has to fit within the
network architecture they have deployed and their business model.

Basically, there is no "magic bullet".




From joelja at bogus.com  Wed May 11 13:48:53 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 11 May 2011 11:48:53 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>	<68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
Message-ID: <4DCADA15.1030807@bogus.com>

 On 5/11/11 11:39 AM, George Bonser wrote:
> It depends.  There are other things to take into account.  If you
> increase the time it takes a mobile device to complete a transaction by
> only a couple of seconds,  if you multiply those couple of seconds by
> all of the users in a large metro area, you end up with devices
> increased use of network resources (and increased battery drain on the
> devices themselves).  Anything that can be done to speed transactions up
> and get those transmitters shut off as quickly as possible is a win.  If
> you don't have a lot of mobile clients hitting your site, then maybe
> that isn't a problem.  Every network has their own set of resources and
> their own set of challenges and all of that has to fit within the
> network architecture they have deployed and their business model.

So in our environment reducing the load time on an application by a
couple seconds nets out to several human lifetimes a month, so people
count seconds and fractions of seconds like they're precious.

> Basically, there is no "magic bullet".

indeed, it has to be applied systemically.

> 
> 




From morrowc.lists at gmail.com  Wed May 11 13:54:45 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 11 May 2011 14:54:45 -0400
Subject: 23,000 IP addresses
In-Reply-To: <4DCAD4DD.2010209@bogus.com>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<4DC943A4.40005@amplex.net>
	<BANLkTi=jUPG+uAA37rV-nShdGOFRiR1QwA@mail.gmail.com>
	<4DC9F5F9.9090407@amplex.net> <4DCAA831.1020902@gmail.com>
	<BANLkTimu40ATbuMYoefMe-S3CxoYiPBfdw@mail.gmail.com>
	<4DCAD4DD.2010209@bogus.com>
Message-ID: <BANLkTimM47RXdDbS+N0qvSVCjK8Zpt7i3w@mail.gmail.com>

On Wed, May 11, 2011 at 2:26 PM, Joel Jaeggli <joelja at bogus.com> wrote:
> On 5/11/11 8:26 AM, Christopher Morrow wrote:
>> On Wed, May 11, 2011 at 11:16 AM, William Allen Simpson
>> <william.allen.simpson at gmail.com> wrote:
>>
>>>> Courts like precedent. I choose Facebook's precedent. Seems reasonable to
>>>> me.
>>>>
>>> That's also roughly in line with Nextel and others for CALEA.
>>
>> Hrm, I had thought that CALEA specifically removed the ability of the
>> Provider to charge for the 'service'? Though there is always the case
>> where the Provider can say: "Yes, this doesn't fall into the CALEA
>> relevant requests, we can do this for you though it will cost
>> time/materials to do, here's our schedule..."
>>
>> or that's the stance a previous employer was taking... (at the
>> direction of their lawyer-catzen)
>
> A civil subpeona is not a calea request. This thread has done a fair bit
> of intermingling of the two things to the detriment of it's utility.

yes, sorry... I got confused by william's interjection of calea...

> While I'm sure facebook is served with plenty of valid search warrants,
> I'm reasonably ?unsure that they meet the definition of
> telecommunications carrier.
>
> there's some discussion in the light of recent hearings, here:
>
> http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html

there's been a push (or was a while ago) to change the calea
requirements such that 'service provider' was the application service
provider as well. AOL IM, Facebook, Google-Search... etc. with
calea-like exfil of relevant data in 'near realtime' and 'at no cost
to LEA'.

-chris



From bonomi at mail.r-bonomi.com  Wed May 11 14:10:31 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 11 May 2011 14:10:31 -0500 (CDT)
Subject: Japan electrical power?
In-Reply-To: <BANLkTik9M2V8wFQ7quPvumCVLHEtcBwPJw@mail.gmail.com>
Message-ID: <201105111910.p4BJAVBx019558@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Wed May 11 13:22:18 2011
> Date: Wed, 11 May 2011 14:21:30 -0400
> Subject: Re: Japan electrical power?
> From: Jay Nakamura <zeusdadog at gmail.com>
> To: Robert Boyle <robert at tellurian.com>
> Cc: nanog at nanog.org
>
> On May 11, 2011 10:09 AM, "Robert Boyle" <robert at tellurian.com> wrote:
> >
> > Hello,
> > I know voltage varies from town to town and prefecture to prefecture.
>
> No, it doesn't.  Japan has two systems, both 100v, western Japan has 60Hz,
> eastern Japan has 50Hz.

'Nominal' voltage, that is.  with relatively poor regulation.  'local'
variation +/-10% (or more) is the norm.  Handling +/-15% will cover 
practically all 'routine' volatage excursions.  If I was designing, I'd
spec for at least 25%, and probably "30% plus", variance.





From nicholas.hatch at gmail.com  Wed May 11 14:25:56 2011
From: nicholas.hatch at gmail.com (nick hatch)
Date: Wed, 11 May 2011 12:25:56 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
	<68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
Message-ID: <BANLkTikKKA6GJoHop6FUXOxeQXM3_aT7pQ@mail.gmail.com>

On Wed, May 11, 2011 at 11:39 AM, George Bonser <gbonser at seven.com> wrote:

> There are other things to take into account.  If you
> increase the time it takes a mobile device to complete a transaction by
> only a couple of seconds,  if you multiply those couple of seconds by
> all of the users in a large metro area, you end up with devices
> increased use of network resources (and increased battery drain on the
> devices themselves).  Anything that can be done to speed transactions up
> and get those transmitters shut off as quickly as possible is a win.
>

I agree that seconds sometimes matters, but the latency of a transaction
doesn't have a linear relationship with radio or battery usage on a mobile
device. Because of the timers involved in the state transitions (eg
CELL_FACH -> CELL_DCH), a few seconds of extra latency often is
inconsequential because there is a minimum duration for which the radio will
stay awake anyways. Coalescing techniques like Android's setInexactRepeating
method of the Alarm Manager also optimize radio access across multiple apps.

And if I'm not mistaken, it's the transition to/from CELL_DCH which is the
most expensive resource-wise for network operators, not the duration of
keeping this state.

The argument that IPv6-induced latency is going to affect mobile devices
disproportionally doesn't seem especially compelling.

-Nick


From gbonser at seven.com  Wed May 11 14:36:00 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 11 May 2011 12:36:00 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <BANLkTikKKA6GJoHop6FUXOxeQXM3_aT7pQ@mail.gmail.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
	<68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
	<BANLkTikKKA6GJoHop6FUXOxeQXM3_aT7pQ@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E31E7@RWC-EX1.corp.seven.com>

 

 


I agree that seconds sometimes matters, but the latency of a transaction
doesn't have a linear relationship with radio or battery usage on a
mobile device. Because of the timers involved in the state transitions
(eg CELL_FACH -> CELL_DCH), a few seconds of extra latency often is
inconsequential because there is a minimum duration for which the radio
will stay awake anyways. Coalescing techniques like Android's
setInexactRepeating method of the Alarm Manager also optimize radio
access across multiple apps.



Not every device out there is an android.  Not every OS on every device
handles connections the same way.  Problems can compound if several
different names must be looked up in order to get a complete page view.
Are your images served from a different name?  Do you have short TTLs
that require names to be looked up frequently?   Again, every network is
going to have their own unique sets of issues.  But until there are more
eyeballs out there that are native v6, we aren't going to see a lot of
movement.

 



From iljitsch at muada.com  Wed May 11 14:43:01 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 11 May 2011 21:43:01 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<8DF11306-06C7-4600-A8D4-5F9835CBB882@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31D5@RWC-EX1.corp.seven.com>
	<41E7BFA1-9BE9-4421-9F37-2D5D5A0F270A@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31DC@RWC-EX1.corp.seven.com>
	<68A5431F-8F79-442D-BC93-A7E8B4EED1F5@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E31E3@RWC-EX1.corp.seven.com>
Message-ID: <D47734FE-A5BF-4E92-AB52-DF4A53E3D57A@muada.com>

On 11 mei 2011, at 20:39, George Bonser wrote:

>> So what's the alternative? Never change anything?

> Of course not.  But the best course forward is going to be different for
> different folks.  What might work best for me might not (probably WILL
> not) work best for everyone else.  One has to look at their situation
> and plan the best path for their business with their architecture and
> the resources they have available to them.  I suggested one option but
> that might not work for others.

I find it strange that you approach this issue as one of the great questions of our time. If you don't want to enable IPv6 for your service at this time, then don't enable IPv6 for your service at this time. But you'll have to do it at some point, so doing it together with your competitors and/or big players seems like a good choice. Going through huge lengths to optimize for a problem that will only exist for a couple of years or so doesn't make sense to me. Also, all this special case logic has a nasty tendency to create all kinds of unexpected problems down the road. I'm sure that the people at Microsoft thought it was a swell idea to enable 6to4 by default. If they hadn't done that, they'd saved us all a lot of wasted time.




From tdurack at gmail.com  Wed May 11 19:15:15 2011
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 11 May 2011 20:15:15 -0400
Subject: How do you put a TV station on the Mbone?
In-Reply-To: <BANLkTimC7ckx-7NLJ7SgMviPfVDufs87jg@mail.gmail.com>
References: <911B68EEC3D257279F760DCA@mac-pro.magehandbook.com>
	<31551047.607.1304547638733.JavaMail.root@benjamin.baylink.com>
	<BANLkTimC7ckx-7NLJ7SgMviPfVDufs87jg@mail.gmail.com>
Message-ID: <BANLkTimgLN7o7YuB2Q7R3LVrvJRkjQkDkQ@mail.gmail.com>

On Wed, May 4, 2011 at 7:19 PM, Tim Durack <tdurack at gmail.com> wrote:
> On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra at baylink.com> wrote:
>
>> No business is entitled to protection of its business model.
>
> Unless it has a market monopoly, deep pockets, and lobbyist friends.
>

http://arstechnica.com/tech-policy/news/2011/05/after-approving-comcastnbc-deal-fcc-commish-becomes-comcast-lobbyist.ars

I rest my case.

-- 
Tim:>



From mysidia at gmail.com  Wed May 11 19:33:21 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 11 May 2011 19:33:21 -0500
Subject: 23,000 IP addresses
In-Reply-To: <4DCA859A.3040205@csuohio.edu>
References: <94BA24FC-D987-4464-98C4-89978BF3CBF0@multicasttech.com>
	<Pine.LNX.4.61.1105100929530.4318@soloth.lewis.org>
	<41A477543C481FC8B6326A5C@mac-pro.magehandbook.com>
	<4DCA859A.3040205@csuohio.edu>
Message-ID: <BANLkTi=t8innXcUftchtgfQFjzr=Ch84tg@mail.gmail.com>

On Wed, May 11, 2011 at 7:48 AM, Michael Holstein
<michael.holstein at csuohio.edu> wrote:

> I have the netflow records to prove this is NOT the case. All
> MediaSentry (et.al.) do is scrape the tracker. We have also received a
> number of takedown notices that have numbers transposed, involve parts
Seems really prone to failure.

I wonder....  does IANA frequently receive legal papers  demanding the
name and street address of the customer at  127.0.0.1  ?  :)

--
-JH



From tvhawaii at shaka.com  Wed May 11 19:41:12 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Wed, 11 May 2011 14:41:12 -1000
Subject: How do you put a TV station on the Mbone?
References: <911B68EEC3D257279F760DCA@mac-pro.magehandbook.com><31551047.607.1304547638733.JavaMail.root@benjamin.baylink.com><BANLkTimC7ckx-7NLJ7SgMviPfVDufs87jg@mail.gmail.com>
	<BANLkTimgLN7o7YuB2Q7R3LVrvJRkjQkDkQ@mail.gmail.com>
Message-ID: <95966C8C2A5E41809BC9156A5A2BAFF2@DELL16>

Tim Durack wrote:
> On Wed, May 4, 2011 at 7:19 PM, Tim Durack <tdurack at gmail.com> wrote:
>> On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra at baylink.com> wrote:
>>
>>> No business is entitled to protection of its business model.
>>
>> Unless it has a market monopoly, deep pockets, and lobbyist friends.
>>
>
> http://arstechnica.com/tech-policy/news/2011/05/after-approving-comcastnbc-deal-fcc-commish-becomes-comcast-lobbyist.ars
>
> I rest my case.

Check out the movie, 'Casino Jack', about Jack Abramoff.
My favorite line is when he's in the slammer and telling another inmate what he does for a living, the inmate says, 
"Lobbyist... is that illegal?". 




From valas at gatech.edu  Wed May 11 20:43:45 2011
From: valas at gatech.edu (Vytautas Valancius)
Date: Wed, 11 May 2011 21:43:45 -0400
Subject: Routing study
Message-ID: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>

Hi NANOG,

>From May 18th to June 18th Georgia Tech will conduct an Internet
routing study using AS-PATH poisoning. We will insert AS numbers into
one of our announcements to route around some networks.

The study will *only* affect the the Georgia Tech prefix
168.62.16.0/24. The prefix serves *no active users* for the duration
of study. We will always start AS-PATH with our own AS 47065. We will
limit ourselves to 10 announcement changes per hour.

If, for any reason, you want us not to poison our prefix with you AS
number, please opt-out at any time at:
http://www.surveymonkey.com/s/WGLV6QR

Regards,
Vytautas Valancius
http://valas.gtnoise.net/
Georgia Tech



From ml at kenweb.org  Wed May 11 22:14:25 2011
From: ml at kenweb.org (ML)
Date: Wed, 11 May 2011 23:14:25 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
Message-ID: <4DCB5091.4050904@kenweb.org>

On 5/11/2011 11:03 AM, james at jamesstewartsmith.com wrote:
> I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed.  These are also some of the more expensive providers on a per Mb basis.  The one provider that was full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)
>

The same Cogent that asked me to pay extra for IPv6 and in return I get 
an incomplete IPv6 routing table?



From hank at efes.iucc.ac.il  Thu May 12 00:00:54 2011
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 12 May 2011 08:00:54 +0300
Subject: Routing study
In-Reply-To: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
Message-ID: <5.1.0.14.2.20110512080040.036671e8@efes.iucc.ac.il>

At 21:43 11/05/2011 -0400, Vytautas Valancius wrote:
>Hi NANOG,
>
> >From May 18th to June 18th Georgia Tech will conduct an Internet
>routing study using AS-PATH poisoning. We will insert AS numbers into
>one of our announcements to route around some networks.
>
>The study will *only* affect the the Georgia Tech prefix
>168.62.16.0/24. The prefix serves *no active users* for the duration
>of study. We will always start AS-PATH with our own AS 47065. We will
>limit ourselves to 10 announcement changes per hour.
>
>If, for any reason, you want us not to poison our prefix with you AS
>number, please opt-out at any time at:
>http://www.surveymonkey.com/s/WGLV6QR

Kudos for doing the right thing.

-Hank


>Regards,
>Vytautas Valancius
>http://valas.gtnoise.net/
>Georgia Tech




From fmartin at linkedin.com  Thu May 12 01:10:10 2011
From: fmartin at linkedin.com (Franck Martin)
Date: Thu, 12 May 2011 06:10:10 +0000
Subject: Yahoo and IPv6
In-Reply-To: <20110511010323.GD10306@hezmatt.org>
Message-ID: <C9F1D05B.A87A%fmartin@linkedin.com>

I think the yahoo test should just differentiate between no IPv6 and IPv6
is slow (test between 3s and 10s). Like:

We have detected that you have IPv6 and will be able to access our site on
IPv6 day, but your user experience may not be as good as with IPv4, you
may consider disabling IPv6.




From ristic.sasa at gmail.com  Thu May 12 03:00:18 2011
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Thu, 12 May 2011 10:00:18 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <4DCB5091.4050904@kenweb.org>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
Message-ID: <BANLkTimVdSeN7zMwkfAJWgU737JV9tLpZw@mail.gmail.com>

On Thu, May 12, 2011 at 05:14, ML <ml at kenweb.org> wrote:
> On 5/11/2011 11:03 AM, james at jamesstewartsmith.com wrote:
>>
>> I have had similar problems with our providers, and these are tier 1
>> companies that should have already been full deployed. ?These are also some
>> of the more expensive providers on a per Mb basis. ?The one provider that
>> was full IPv6 ready was Cogent. ?HE is also IPv6 (although we don't use them
>> atm.)
>>
>
> The same Cogent that asked me to pay extra for IPv6 and in return I get an
> incomplete IPv6 routing table?

Hi all,

I can confirm this also, from HE I get 5411 routes on BGPv6, but only
4293 from Cogent... Although, they didn't charge me extra for v6
session...


-- 
Ristic Sasa
VeratNet ISP
Serbia



From owen at delong.com  Thu May 12 05:06:41 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 May 2011 03:06:41 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <4DCB5091.4050904@kenweb.org>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
Message-ID: <BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>


On May 11, 2011, at 8:14 PM, ML wrote:

> On 5/11/2011 11:03 AM, james at jamesstewartsmith.com wrote:
>> I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed.  These are also some of the more expensive providers on a per Mb basis.  The one provider that was full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)
>> 
> 
> The same Cogent that asked me to pay extra for IPv6 and in return I get an incomplete IPv6 routing table?

We will happily provide you with a  more complete IPv6 routing table, though we do, admittedly lack
routes from Cogent and a couple of other players that are having difficulty realizing that IPv6 peering
is somewhat different from IPv4.

Owen DeLong
Hurricane Electric




From anthony at handynetworks.com  Thu May 12 05:15:09 2011
From: anthony at handynetworks.com (Anthony Francis - Handy Networks LLC)
Date: Thu, 12 May 2011 10:15:09 +0000
Subject: IPv6 foot-dragging
In-Reply-To: <BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
Message-ID: <0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>

I can confirm full IPV6 connectivity from HE.

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Thursday, May 12, 2011 4:07 AM
To: ml at kenweb.org
Cc: nanog at nanog.org
Subject: Re: IPv6 foot-dragging


On May 11, 2011, at 8:14 PM, ML wrote:

> On 5/11/2011 11:03 AM, james at jamesstewartsmith.com wrote:
>> I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed.  These are also some of the more expensive providers on a per Mb basis.  The one provider that was full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)
>> 
> 
> The same Cogent that asked me to pay extra for IPv6 and in return I get an incomplete IPv6 routing table?

We will happily provide you with a  more complete IPv6 routing table, though we do, admittedly lack
routes from Cogent and a couple of other players that are having difficulty realizing that IPv6 peering
is somewhat different from IPv4.

Owen DeLong
Hurricane Electric






From iljitsch at muada.com  Thu May 12 05:21:26 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu, 12 May 2011 12:21:26 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
Message-ID: <A4287014-5BE1-4707-AA69-B4CB5AF03479@muada.com>

On 12 mei 2011, at 12:06, Owen DeLong wrote:

> IPv6 peering
> is somewhat different from IPv4.

How is it different?



From berni at birkenwald.de  Thu May 12 05:27:38 2011
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Thu, 12 May 2011 10:27:38 +0000 (UTC)
Subject: IPv6 foot-dragging
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
Message-ID: <iqgcmq$t9o$1@dough.gmane.org>

Anthony Francis - Handy Networks LLC <anthony at handynetworks.com> wrote:

> I can confirm full IPV6 connectivity from HE.

How can you confirm that when HE just admitted to be lacking IPv6 routes
from Cogent and a couple of other players?

Bernhard




From bmanning at vacation.karoshi.com  Thu May 12 05:30:08 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 12 May 2011 10:30:08 +0000
Subject: Routing study
In-Reply-To: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
Message-ID: <20110512103008.GB3902@vacation.karoshi.com.>

 er...

 this is not a GATech prefix and I would appreciate it if they
 would at least notify me ahead of time if they want to futz around
 with prefixes that are not registered to them.  


NetRange:       168.61.0.0 - 168.63.255.255
CIDR:           168.62.0.0/15, 168.61.0.0/16
OriginAS:
NetName:        JAM
NetHandle:      NET-168-61-0-0-1
Parent:         NET-168-0-0-0-0
NetType:        Direct Assignment
RegDate:        1995-02-09
Updated:        2009-07-21
Ref:            http://whois.arin.net/rest/net/NET-168-61-0-0-1

OrgName:        EP.NET, LLC.
OrgId:          EPB-Z
Address:        PO 12317
City:           Marina del Rey
StateProv:      CA
PostalCode:     90295
Country:        US
RegDate:        2007-11-29
Updated:        2007-11-29
Ref:            http://whois.arin.net/rest/org/EPB-Z

OrgTechHandle: WM110-ARIN
OrgTechName:   Manning, Bill
OrgTechPhone:  +1-310-322-8102
OrgTechEmail:  bmanning at vacation.karoshi.com
OrgTechRef:    http://whois.arin.net/rest/poc/WM110-ARIN

/bill


On Wed, May 11, 2011 at 09:43:45PM -0400, Vytautas Valancius wrote:
> Hi NANOG,
> 
> >From May 18th to June 18th Georgia Tech will conduct an Internet
> routing study using AS-PATH poisoning. We will insert AS numbers into
> one of our announcements to route around some networks.
> 
> The study will *only* affect the the Georgia Tech prefix
> 168.62.16.0/24. The prefix serves *no active users* for the duration
> of study. We will always start AS-PATH with our own AS 47065. We will
> limit ourselves to 10 announcement changes per hour.
> 
> If, for any reason, you want us not to poison our prefix with you AS
> number, please opt-out at any time at:
> http://www.surveymonkey.com/s/WGLV6QR
> 
> Regards,
> Vytautas Valancius
> http://valas.gtnoise.net/
> Georgia Tech



From jloiacon at csc.com  Thu May 12 08:14:23 2011
From: jloiacon at csc.com (Joe Loiacono)
Date: Thu, 12 May 2011 09:14:23 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <iqgcmq$t9o$1@dough.gmane.org>
References: <4DCA9FAF.70409@l-w.ca>	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
Message-ID: <OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>

Bernhard Schmidt <berni at birkenwald.de> wrote on 05/12/2011 06:27:38 AM:

> Anthony Francis - Handy Networks LLC <anthony at handynetworks.com> wrote:
> 
> > I can confirm full IPV6 connectivity from HE.
> 
> How can you confirm that when HE just admitted to be lacking IPv6 routes
> from Cogent and a couple of other players?

Anyone know roughly the current default-free routing table size for IPv6?

Or, who holds the record for the largest IPv6 routing table at this point?

Joe

From jeroen at unfix.org  Thu May 12 08:19:21 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 12 May 2011 15:19:21 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
References: <4DCA9FAF.70409@l-w.ca>	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>	<4DCB5091.4050904@kenweb.org>	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
Message-ID: <4DCBDE59.2000001@unfix.org>

On 2011-May-12 15:14, Joe Loiacono wrote:
> Bernhard Schmidt <berni at birkenwald.de> wrote on 05/12/2011 06:27:38 AM:
> 
>> Anthony Francis - Handy Networks LLC <anthony at handynetworks.com> wrote:
>>
>>> I can confirm full IPV6 connectivity from HE.
>>
>> How can you confirm that when HE just admitted to be lacking IPv6 routes
>> from Cogent and a couple of other players?
> 
> Anyone know roughly the current default-free routing table size for IPv6?

http://www.sixxs.net/tools/grh/status/

3668 good/required prefixes
Minimum of 271 prefixes (-3397)
Average of 5322 prefixes (+1654)
Maximum of 5917 prefixes (+2249)

As you can see, some folks seem to carry HALF of the table EXTRA than
they need.... let alone that poor ISP which is carrying almost 2/3s
more, I don't have time to check into it, but I wonder how much junk is
in there....

> Or, who holds the record for the largest IPv6 routing table at this point?

Having more routes does not mean that the routes are useful... far from
actually...

Greets,
 Jeroen



From berni at birkenwald.de  Thu May 12 08:20:50 2011
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Thu, 12 May 2011 15:20:50 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
References: <4DCA9FAF.70409@l-w.ca>	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>	<4DCB5091.4050904@kenweb.org>	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
Message-ID: <4DCBDEB2.3040602@birkenwald.de>

Hi,

> Bernhard Schmidt <berni at birkenwald.de> wrote on 05/12/2011 06:27:38 AM:
> 
>> Anthony Francis - Handy Networks LLC <anthony at handynetworks.com> wrote:
>>
>> > I can confirm full IPV6 connectivity from HE.
>>
>> How can you confirm that when HE just admitted to be lacking IPv6 routes
>> from Cogent and a couple of other players?
> 
> Anyone know roughly the current default-free routing table size for IPv6?

grh.sixxs.net shows around 5600 prefixes for most participants. But it
depends on filters as well, I run strict filters (no more than /35 in PA
space) and have around 4300 prefixes.

> Or, who holds the record for the largest IPv6 routing table at this point?

I don't think the absolute number of prefixes is a valid metric. There
is too many more-specific junk with partial visibility floating around.

Bernhard



From swmike at swm.pp.se  Thu May 12 08:30:57 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 12 May 2011 15:30:57 +0200 (CEST)
Subject: IPv6 foot-dragging
In-Reply-To: <4DCBDE59.2000001@unfix.org>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
Message-ID: <alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>

On Thu, 12 May 2011, Jeroen Massar wrote:

> As you can see, some folks seem to carry HALF of the table EXTRA than 
> they need.... let alone that poor ISP which is carrying almost 2/3s 
> more, I don't have time to check into it, but I wonder how much junk is 
> in there....

A lot. I see /48 breakouts from /32 PA blocks for instance, announced by a 
customer AS of the PA holder AS.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se



From jloiacon at csc.com  Thu May 12 08:41:31 2011
From: jloiacon at csc.com (Joe Loiacono)
Date: Thu, 12 May 2011 09:41:31 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <4DCBDE59.2000001@unfix.org>
References: <4DCA9FAF.70409@l-w.ca>	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
Message-ID: <OF81F394AD.9E5D67EB-ON8525788E.004A7BFE-8525788E.004B364C@csc.com>

Jeroen Massar <jeroen at unfix.org> wrote on 05/12/2011 09:19:21 AM:

> On 2011-May-12 15:14, Joe Loiacono wrote:
> > Anyone know roughly the current default-free routing table size for 
IPv6?
> 
> http://www.sixxs.net/tools/grh/status/

Awesome web-site. The world of IPv6 routing on one page.


> 3668 good/required prefixes
> Minimum of 271 prefixes (-3397)
> Average of 5322 prefixes (+1654)

Is this saying that poor aggregation has crept in already (to the tune of 
45%)?

Given the RIR IPv6 allocation strategies, any estimate on the ultimate 
size of the DFR IPv6 table and how much memory will be required?

> > Or, who holds the record for the largest IPv6 routing table at this 
point?
> 
> Having more routes does not mean that the routes are useful... far from
> actually...

Right. But isn't that dependent on peer's good aggregation and suppression 
of bogons?

Joe

From gbonser at seven.com  Thu May 12 10:41:04 2011
From: gbonser at seven.com (George Bonser)
Date: Thu, 12 May 2011 08:41:04 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
References: <4DCA9FAF.70409@l-w.ca><1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry><4DCB5091.4050904@kenweb.org><BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com><0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com><iqgcmq$t9o$1@dough.gmane.org><OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com><4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>

> A lot. I see /48 breakouts from /32 PA blocks for instance, announced
> by a
> customer AS of the PA holder AS.
> 
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se

Which is kinda sad.  If those customer AS are multihomed or plan to be
multihomed, they can get their own allocation out of PI space. If they
are not multihomed outside of the provider AS, there is no need for the
provider to "leak" that /48 out of their AS to their peers.





From greg.whynott at oicr.on.ca  Thu May 12 11:02:55 2011
From: greg.whynott at oicr.on.ca (Greg Whynott)
Date: Thu, 12 May 2011 12:02:55 -0400
Subject: Routing study
In-Reply-To: <20110512103008.GB3902@vacation.karoshi.com.>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
Message-ID: <E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>

On May 12, 2011, at 6:30 AM, <bmanning at vacation.karoshi.com> <bmanning at vacation.karoshi.com> wrote:

> er?
> d I would appreciate it if they
> would at least notify me ahead of time if they want to futz around
> with prefixes that are not registered to them.


er?.   isn't that exactly what they just did,  notified you ahead of time?  the test starts on the 18th.

helps to read before you jump!

-g


--

This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.



From swhyte at gmail.com  Thu May 12 11:06:24 2011
From: swhyte at gmail.com (Scott Whyte)
Date: Thu, 12 May 2011 09:06:24 -0700
Subject: Yahoo and IPv6
In-Reply-To: <C9F1D05B.A87A%fmartin@linkedin.com>
References: <20110511010323.GD10306@hezmatt.org>
	<C9F1D05B.A87A%fmartin@linkedin.com>
Message-ID: <BANLkTimNZEsoweALVowyAcRWmuHjf=_3pg@mail.gmail.com>

On Wed, May 11, 2011 at 23:10, Franck Martin <fmartin at linkedin.com> wrote:
> I think the yahoo test should just differentiate between no IPv6 and IPv6
> is slow (test between 3s and 10s). Like:
>
> We have detected that you have IPv6 and will be able to access our site on
> IPv6 day, but your user experience may not be as good as with IPv4, you
> may consider disabling IPv6.
>

Measurements during the experiment won't be directly comparable to
those before/after, at least as far as I can see.  So they will be
informative, but its the slope of the brokenness line before/after
that will determine when IPv6 is not an impediment to itself.

-Scott



From stb at lassitu.de  Thu May 12 11:38:11 2011
From: stb at lassitu.de (Stefan Bethke)
Date: Thu, 12 May 2011 18:38:11 +0200
Subject: Routing study
In-Reply-To: <E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
	<E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
Message-ID: <A4890B44-B985-4718-B027-10BE58A5AAB5@lassitu.de>

Am 12.05.2011 um 18:02 schrieb Greg Whynott:

> helps to read before you jump!

I think he might be referring to the fact that the prefix supposedly used to conduct the test is his, not Georgia Tech's.

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811






From jmaslak at antelope.net  Thu May 12 11:42:17 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Thu, 12 May 2011 10:42:17 -0600
Subject: IPv6 foot-dragging
In-Reply-To: <4DCBDEB2.3040602@birkenwald.de>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDEB2.3040602@birkenwald.de>
Message-ID: <5075EEBD-4E2E-4407-B092-A3902626F594@antelope.net>

Who sees the most AS's?





From Greg.Whynott at oicr.on.ca  Thu May 12 11:45:29 2011
From: Greg.Whynott at oicr.on.ca (Greg Whynott)
Date: Thu, 12 May 2011 12:45:29 -0400
Subject: Routing study
In-Reply-To: <A4890B44-B985-4718-B027-10BE58A5AAB5@lassitu.de>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
	<E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
	<A4890B44-B985-4718-B027-10BE58A5AAB5@lassitu.de>
Message-ID: <9EC09253-2D3F-43F0-866C-1BDADD6A701C@oicr.on.ca>



On May 12, 2011, at 12:38 PM, Stefan Bethke wrote:

> Am 12.05.2011 um 18:02 schrieb Greg Whynott:
>
>> helps to read before you jump!
>
> I think he might be referring to the fact that the prefix supposedly used to conduct the test is his, not Georgia Tech's.
>
> --
> Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811
>
>



perhaps.  i should of reframed and not said anything since it added nothing.

sorry bmanning.

-g

>

Gregory Whynott
Networks and Storage

Ontario Institute for Cancer Research
MaRS Centre, South Tower
101 College Street, Suite 800
Toronto, Ontario, Canada M5G 0A3

647-294-2813 | www.oicr.on.ca


--

This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.



From millnert at gmail.com  Thu May 12 11:46:31 2011
From: millnert at gmail.com (Martin Millnert)
Date: Thu, 12 May 2011 12:46:31 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
	<5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
Message-ID: <BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>

George,

On Thu, May 12, 2011 at 11:41 AM, George Bonser <gbonser at seven.com> wrote:
>> A lot. I see /48 breakouts from /32 PA blocks for instance, announced
>> by a
>> customer AS of the PA holder AS.
>>
>> --
>> Mikael Abrahamsson ? ?email: swmike at swm.pp.se
>
> Which is kinda sad.

It's reality.

> If those customer AS are multihomed or plan to be
> multihomed, they can get their own allocation out of PI space. If they
> are not multihomed outside of the provider AS, there is no need for the
> provider to "leak" that /48 out of their AS to their peers.

In the RIPE region, being multihomed or planning to be it is not a
sufficient condition for getting a PI prefix.  And even if it was, the
hit on DFZ is the same as from getting allocation from LIR. Even if
they get their own /32, the hit would be the same (modulo individual
FIB/RIB implementations).
Consequently, there's work in progress to modernize RIPE IPv6 address policy.
http://ripe62.ripe.net/presentations/148-wg.pdf p. 19 and forward.

Cheers,
Martin



From sjs at princeton.edu  Thu May 12 11:58:32 2011
From: sjs at princeton.edu (Steve Schultze)
Date: Thu, 12 May 2011 12:58:32 -0400
Subject: Pirate Bay suffering unreachable errors
Message-ID: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>

Anybody on this list have any insights on the reports of Pirate Bay unreachability?

http://torrentfreak.com/comcast-blocked-the-pirate-bay-110512/
http://www.fastcompany.com/1752986/why-is-comcast-blocking-the-pirate-bay
http://www.engadget.com/2011/05/12/is-comcast-blocking-the-pirate-bay/




From brandon.galbraith at gmail.com  Thu May 12 12:03:46 2011
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Thu, 12 May 2011 12:03:46 -0500
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
Message-ID: <BANLkTinaPqY7gjc1YHMA58fwMmjojav80A@mail.gmail.com>

Comcast customer care via twitter specifically stated they aren't blocking
twitter (@comcastcares).
On May 12, 2011 12:00 PM, "Steve Schultze" <sjs at princeton.edu> wrote:
> Anybody on this list have any insights on the reports of Pirate Bay
unreachability?
>
> http://torrentfreak.com/comcast-blocked-the-pirate-bay-110512/
> http://www.fastcompany.com/1752986/why-is-comcast-blocking-the-pirate-bay
> http://www.engadget.com/2011/05/12/is-comcast-blocking-the-pirate-bay/
>
>


From brandon.galbraith at gmail.com  Thu May 12 12:06:07 2011
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Thu, 12 May 2011 12:06:07 -0500
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <BANLkTinaPqY7gjc1YHMA58fwMmjojav80A@mail.gmail.com>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
	<BANLkTinaPqY7gjc1YHMA58fwMmjojav80A@mail.gmail.com>
Message-ID: <BANLkTimYkDZmUgjF1fQae2-aSSg45RVBpQ@mail.gmail.com>

2nd Twitter instance should've read "The Pirate Bay". Apologies.
On May 12, 2011 12:03 PM, "Brandon Galbraith" <brandon.galbraith at gmail.com>
wrote:
> Comcast customer care via twitter specifically stated they aren't blocking
> twitter (@comcastcares).
> On May 12, 2011 12:00 PM, "Steve Schultze" <sjs at princeton.edu> wrote:
>> Anybody on this list have any insights on the reports of Pirate Bay
> unreachability?
>>
>> http://torrentfreak.com/comcast-blocked-the-pirate-bay-110512/
>> http://www.fastcompany.com/1752986/why-is-comcast-blocking-the-pirate-bay
>> http://www.engadget.com/2011/05/12/is-comcast-blocking-the-pirate-bay/
>>
>>


From owen at delong.com  Thu May 12 12:09:46 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 May 2011 10:09:46 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimNZEsoweALVowyAcRWmuHjf=_3pg@mail.gmail.com>
References: <20110511010323.GD10306@hezmatt.org>
	<C9F1D05B.A87A%fmartin@linkedin.com>
	<BANLkTimNZEsoweALVowyAcRWmuHjf=_3pg@mail.gmail.com>
Message-ID: <EFC82B39-E3C9-45AD-BC5F-74F43583E9DD@delong.com>


On May 12, 2011, at 9:06 AM, Scott Whyte wrote:

> On Wed, May 11, 2011 at 23:10, Franck Martin <fmartin at linkedin.com> wrote:
>> I think the yahoo test should just differentiate between no IPv6 and IPv6
>> is slow (test between 3s and 10s). Like:
>> 
>> We have detected that you have IPv6 and will be able to access our site on
>> IPv6 day, but your user experience may not be as good as with IPv4, you
>> may consider disabling IPv6.
>> 
> 
> Measurements during the experiment won't be directly comparable to
> those before/after, at least as far as I can see.  So they will be
> informative, but its the slope of the brokenness line before/after
> that will determine when IPv6 is not an impediment to itself.
> 
> -Scott

I think it's a little more complex.

I think there are two lines. A line representing brokenness with AAAA records
enabled and a line representing brokenness without AAAA records.

The first line is trending downwards while the second line is trending upwards
and wil soon be making a rather pronounced increase in its slope.

When these two lines cross, I think it will become virtually inevitable that
those who are ready to do so will publish their AAAA records.

Owen




From caldcv at gmail.com  Thu May 12 12:56:51 2011
From: caldcv at gmail.com (Chris)
Date: Thu, 12 May 2011 13:56:51 -0400
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <BANLkTimYkDZmUgjF1fQae2-aSSg45RVBpQ@mail.gmail.com>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
	<BANLkTinaPqY7gjc1YHMA58fwMmjojav80A@mail.gmail.com>
	<BANLkTimYkDZmUgjF1fQae2-aSSg45RVBpQ@mail.gmail.com>
Message-ID: <BANLkTim6mZiGOma4YK51eXBvn5ETegYo6w@mail.gmail.com>

FWIW, most speculation can be eliminated with a simple traceroute:


 6  te-0-2-0-0-cr01.miami.fl.ibone.comcast.net (68.86.93.149)  83.161
ms  25.235 ms  22.264 ms
 7  xe-10-1-0.edge2.Miami1.Level3.net (64.156.8.9)  25.455 ms  31.254
ms  39.878 ms
 8  ae-31-51.ebr1.Miami1.Level3.net (4.69.138.94)  56.394 ms  56.829
ms  61.876 ms
 9  ae-2-2.ebr1.Dallas1.Level3.net (4.69.140.133)  88.305 ms  97.700
ms  101.956 ms
10  ae-81-81.csw3.Dallas1.Level3.net (4.69.151.149)  105.718 ms
112.451 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125)  116.147 ms
11  ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146)  124.239 ms
124.327 ms  127.080 ms
12  ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77)  148.655 ms
83.899 ms  83.441 ms
13  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  97.200 ms  97.450
ms  100.717 ms
14  ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109)  105.675 ms
110.643 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  121.534 ms
15  ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  115.325 ms
ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138)  129.887 ms  130.121 ms
16  ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18)  130.228 ms
ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2)  109.190 ms
ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14)  139.681 ms
17  ae-22-70.car2.SanJose1.Level3.net (4.69.152.68)  118.715 ms
ae-32-80.car2.SanJose1.Level3.net (4.69.152.132)  121.790 ms
ae-42-90.car2.SanJose1.Level3.net (4.69.152.196)  131.790 ms
18  Layer42.car2.SanJose1.Level3.net (4.53.18.242)  91.717 ms  96.110
ms  100.318 ms
19  xe1-3-925.core1.scl.layer42.net (69.36.239.126)  147.051 ms
149.223 ms  149.706 ms
20  ro2.scl01.appliedops.net (67.218.96.58)  115.829 ms  125.489 ms  132.102 ms
21  ge-0-0-1-4028.ro1.sjc01 (208.83.220.112)  142.292 ms  141.739 ms  98.201 ms
22  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  100.815 ms  105.488
ms  119.839 ms
23  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  227.047 ms
 197.560 ms  201.478 ms
24  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  210.747 ms  220.879
ms  226.355 ms
25  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  233.013 ms
237.760 ms  240.525 ms
26  thepiratebay.piratpartiet.se (194.14.56.29)  246.535 ms  249.101
ms  251.711 ms
27  * * *
28  * * *
29  * * *
30  * * *



From michael.holstein at csuohio.edu  Thu May 12 12:58:56 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Thu, 12 May 2011 13:58:56 -0400
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
Message-ID: <4DCC1FE0.6030802@csuohio.edu>


> Anybody on this list have any insights on the reports of Pirate Bay unreachability?
>   

TPB is constantly on the move .. my traceroute shows this hop

13  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  205.131 ms 
212.424 ms  212.400 ms

Their website :

"We welcome [..] free speech and lulz."

My guess would be routing problems, probably Comcast's. If some of the
whiners would post traceroutes maybe help could be had.

Cheers,

Michael Holstein
Cleveland State University





From valas at gatech.edu  Thu May 12 13:00:45 2011
From: valas at gatech.edu (Vytautas Valancius)
Date: Thu, 12 May 2011 14:00:45 -0400
Subject: Routing study
In-Reply-To: <9EC09253-2D3F-43F0-866C-1BDADD6A701C@oicr.on.ca>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
	<E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
	<A4890B44-B985-4718-B027-10BE58A5AAB5@lassitu.de>
	<9EC09253-2D3F-43F0-866C-1BDADD6A701C@oicr.on.ca>
Message-ID: <BANLkTimPFONG85pLmC5E5pUs3yoyaXFWUw@mail.gmail.com>

>> I think he might be referring to the fact that the prefix supposedly used to conduct the test is his, not Georgia Tech's.

Yes, it's indeed part of Bill's space, but on temporary loan (SWIP)
for GENI/GaTech:

---
whois -h rr.arin.net 168.62.16.0/24
[...]
route:          168.62.16.0/21
descr:          gtnoise.net (research group at GaTech)
origin:         AS47065
mnt-by:         MNT-GIT
source:         ARIN # Filtered
---

Sorry if it caused confusion! I should have synced this with Bill
before announcement.

Regards,
Vytautas Valancius
http://valas.gtnoise.net
Georgia Tech



From caldcv at gmail.com  Thu May 12 13:02:41 2011
From: caldcv at gmail.com (Chris)
Date: Thu, 12 May 2011 14:02:41 -0400
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <4DCC1FE0.6030802@csuohio.edu>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
	<4DCC1FE0.6030802@csuohio.edu>
Message-ID: <BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>

Confirmed on 3 VPS servers in California, Chicago and Scranton:

All the packets die at piratpartiet.se


On 5/12/11, Michael Holstein <michael.holstein at csuohio.edu> wrote:
>
> My guess would be routing problems, probably Comcast's. If some of the
> whiners would post traceroutes maybe help could be had.
>
> Cheers,
>
> Michael Holstein
> Cleveland State University
>


-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton



From michael.holstein at csuohio.edu  Thu May 12 13:15:22 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Thu, 12 May 2011 14:15:22 -0400
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>	<4DCC1FE0.6030802@csuohio.edu>
	<BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>
Message-ID: <4DCC23BA.4030405@csuohio.edu>


> Confirmed on 3 VPS servers in California, Chicago and Scranton:
>
> All the packets die at piratpartiet.se
>   

You're assuming that the webserver permits ICMP. Try "traceroute -T -p
80 thepiratebay.org"

10  as40475.ge-0-2-1.cr1.sfo1.us.nlayer.net (69.22.153.90)  97.411 ms 
97.049 ms  97.207 ms
11  ge-0-0-1-4030.ro1.sjc01 (208.83.220.116)  93.781 ms  93.953 ms 
91.025 ms
12  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  87.828 ms  87.882 ms 
87.867 ms
13  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  204.147 ms 
197.968 ms  198.435 ms
14  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  198.396 ms  198.198
ms  198.017 ms
15  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  191.203 ms 
191.826 ms  191.653 ms
16  thepiratebay.piratpartiet.se (194.14.56.29)  191.103 ms  190.479 ms 
190.453 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  thepiratebay.org (194.71.107.15)  192.677 ms  192.862 ms  192.999 ms





From caldcv at gmail.com  Thu May 12 13:21:10 2011
From: caldcv at gmail.com (Chris)
Date: Thu, 12 May 2011 14:21:10 -0400
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <4DCC23BA.4030405@csuohio.edu>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
	<4DCC1FE0.6030802@csuohio.edu>
	<BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>
	<4DCC23BA.4030405@csuohio.edu>
Message-ID: <BANLkTimqqcnDLBtqZ=VfhTZt_a806JP1Zg@mail.gmail.com>

# traceroute -T -p 80 thepiratebay.org

Chicago:

 3  r1.chi1.us.as5580.net (78.152.63.85)  0.346 ms  0.400 ms  1.383 ms
 4  r1.ash1.us.as5580.net (80.94.64.217)  29.253 ms
r1.nyc1.us.as5580.net (80.94.64.213)  22.749 ms  22.772 ms
 5  r1.ams1.nl.as5580.net (80.94.64.149)  115.317 ms
r1.lon1.uk.as5580.net (80.94.64.141)  94.657 ms r1.ams1.nl.as5580.net
(80.94.64.149)  115.341 ms
 6  10ge-ams-ix.ams1.portlane.net (195.69.145.25)  116.592 ms
ams-ix.tc2-ams.nl.p80.net (195.69.145.52)  116.242 ms 195.66.224.243
(195.66.224.243)  90.884 ms
 7  po41-20g-r85.cr0-r86.hy-sto.se.p80.net (82.96.1.161)  144.107 ms
135.739 ms te-2-1.sto3.se.portlane.net (80.67.4.134)  144.717 ms
 8  as48285-fe-kn1.sthix.net (192.121.80.155)  135.647 ms
te-3-2.sto1.se.portlane.net (80.67.4.128)  134.538 ms
as48285-fe-kn1.sthix.net (192.121.80.155)  143.794 ms
 9  as48285-fe-kn1.sthix.net (192.121.80.155)  142.410 ms
sthix-ix-ge-sth-1500.alltele.se (192.121.80.148)  135.641 ms
as48285-fe-kn1.sthix.net (192.121.80.155)  134.178 ms
10  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  146.133 ms
sthix-ix-ge-sth-1500.alltele.se (192.121.80.148)  142.945 ms
vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  137.692 ms
11  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  136.782 ms
ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  145.971 ms
vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  135.594 ms
12  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  144.054 ms  144.000
ms ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  144.534 ms
13  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  143.294 ms
134.907 ms  143.886 ms
14  * thepiratebay.piratpartiet.se (194.14.56.29)  135.930 ms  144.389 ms
15  thepiratebay.org (194.71.107.15)  145.483 ms  145.418 ms *


Comcast (North FL)


 6  * te-0-2-0-0-cr01.miami.fl.ibone.comcast.net (68.86.93.149)
21.542 ms  24.742 ms
 7  xe-10-1-0.edge2.Miami1.Level3.net (64.156.8.9)  104.518 ms
106.520 ms  108.143 ms
 8  ae-31-51.ebr1.Miami1.Level3.net (4.69.138.94)  49.732 ms  50.156
ms  51.593 ms
 9  ae-2-2.ebr1.Dallas1.Level3.net (4.69.140.133)  87.808 ms  91.518
ms  91.010 ms
10  ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125)  100.321 ms
108.464 ms ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137)  123.269 ms
11  ae-83-83.ebr3.Dallas1.Level3.net (4.69.151.158)  126.642 ms
139.122 ms ae-93-93.ebr3.Dallas1.Level3.net (4.69.151.170)  49.901 ms
12  ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77)  91.881 ms
96.655 ms  101.315 ms
13  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  115.018 ms
123.654 ms  128.822 ms
14  ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  134.523 ms
ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109)  143.657 ms *
15  * * *
16  * * *
17  * * *
18  * * *
19  * xe1-3-925.core1.scl.layer42.net (69.36.239.126)  94.119 ms  92.276 ms
20  ro2.scl01.appliedops.net (67.218.96.58)  103.292 ms  112.557 ms  117.280 ms
21  ge-0-0-1-4028.ro1.sjc01 (208.83.220.112)  123.730 ms  130.364 ms  149.335 ms
22  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  149.940 ms  151.987
ms  155.845 ms
23  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  278.083 ms
 297.589 ms  303.895 ms
24  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  308.448 ms *  213.364 ms
25  * ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  215.563 ms  222.188 ms
26  * thepiratebay.piratpartiet.se (194.14.56.29)  213.583 ms  214.014 ms
27  * * *
28  * * *
29  * * *
30  * * *


California:


 3  209.234.157.201 (209.234.157.201)  1.073 ms  1.134 ms  1.216 ms
 4  lax2-pr1-xe-0-0-0-0.us.twtelecom.net (66.192.253.170)  2.296 ms
2.757 ms  2.809 ms
 5  xe-2-0-0.cr1.sjc1.us.nlayer.net (69.22.142.125)  15.501 ms  15.527
ms  15.552 ms
 6  * * *
 7  as40475.ge-0-2-1.cr1.sfo1.us.nlayer.net (69.22.153.90)  15.352 ms
15.102 ms  14.849 ms
 8  ge-0-0-1-4030.ro1.sjc01 (208.83.220.116)  19.544 ms  18.497 ms  18.240 ms
 9  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  16.336 ms  17.939 ms  17.941 ms
10  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  186.587 ms
 187.003 ms  187.027 ms
11  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  183.391 ms  180.588
ms  181.568 ms
12  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  181.621 ms
181.416 ms  181.602 ms
13  thepiratebay.piratpartiet.se (194.14.56.29)  180.714 ms  180.159
ms  180.224 ms
14  * * *
15  * * *
16  * * *
17  thepiratebay.org (194.71.107.15)  182.664 ms  192.584 ms  192.555 ms


Scranton:


 2  ec0-61.agg04.sctn01.hostnoc.net (96.9.184.62)  0.301 ms  0.346 ms  0.383 ms
 3  xe1-04.gwy02.sctn01.hostnoc.net (96.9.191.13)  0.558 ms  0.632 ms  0.612 ms
 4  xe2-01.gwy01.laca01.hostnoc.net (96.9.191.74)  81.522 ms  81.603
ms  81.648 ms
 5  appliedops.net.any2ix.coresite.com (206.223.143.126)  94.202 ms
94.190 ms  94.800 ms
 6  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  91.912 ms  92.173 ms  92.113 ms
 7  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  189.557 ms
 189.291 ms  189.291 ms
 8  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  191.086 ms  190.428
ms  190.905 ms
 9  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  185.830 ms
185.655 ms  185.577 ms
10  thepiratebay.piratpartiet.se (194.14.56.29)  190.558 ms  190.312
ms  190.021 ms
11  thepiratebay.org (194.71.107.15)  191.733 ms  192.875 ms  191.943 ms



From bblackford at gmail.com  Thu May 12 13:49:31 2011
From: bblackford at gmail.com (Bill Blackford)
Date: Thu, 12 May 2011 11:49:31 -0700
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <BANLkTimqqcnDLBtqZ=VfhTZt_a806JP1Zg@mail.gmail.com>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>
	<4DCC1FE0.6030802@csuohio.edu>
	<BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>
	<4DCC23BA.4030405@csuohio.edu>
	<BANLkTimqqcnDLBtqZ=VfhTZt_a806JP1Zg@mail.gmail.com>
Message-ID: <BANLkTik-YNco+qR43fw=AyFJ78ggj6wcQA@mail.gmail.com>

Portland OR:


 3  sjc1-pr1-xe-0-0-0-0.us.twtelecom.net (66.192.251.170)  15.584 ms
15.674 ms  15.580 ms
 4  ae2-20g.cr1.sfo1.us.nlayer.net (69.22.143.162)  16.651 ms  16.810
ms  16.900 ms
 5  as40475.ge-0-2-1.cr1.sfo1.us.nlayer.net (69.22.153.90)  16.837 ms
17.037 ms  16.812 ms
 6  ge-0-0-1-4030.ro1.sjc01 (208.83.220.116)  420.042 ms  199.832 ms  21.146 ms
 7  ge-0-0.cal-cr-0.srstubes.net (74.116.251.2)  18.427 ms  18.856 ms  18.866 ms
 8  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  196.726 ms
 194.888 ms  197.383 ms
 9  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  198.130 ms  197.935
ms  198.112 ms
10  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  194.774 ms
198.321 ms  196.838 ms
11  thepiratebay.piratpartiet.se (194.14.56.29)  197.033 ms  199.376
ms  197.917 ms
12  * * *
13  * * *
^C



From bonomi at mail.r-bonomi.com  Thu May 12 13:59:18 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 12 May 2011 13:59:18 -0500 (CDT)
Subject: 23,000 IP addresses
In-Reply-To: <BANLkTi=t8innXcUftchtgfQFjzr=Ch84tg@mail.gmail.com>
Message-ID: <201105121859.p4CIxI8e002687@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Thu May 12 11:04:15 2011
> Date: Wed, 11 May 2011 19:33:21 -0500
> Subject: Re: 23,000 IP addresses
> From: Jimmy Hess <mysidia at gmail.com>
> To: Michael Holstein <michael.holstein at csuohio.edu>
> Cc: NANOG list <nanog at nanog.org>
>
> On Wed, May 11, 2011 at 7:48 AM, Michael Holstein
>
> I wonder....  does IANA frequently receive legal papers  demanding the
> name and street address of the customer at  127.0.0.1  ?  :)
>

I know people, well at least one,  that have sent spam complaints to IANA 
claiming junk mail originated from that address. 

Yes, *really*.

And, it was "true".  The 'cron' daemon was sending him e-mails he didn't
want.



From drc at virtualized.org  Thu May 12 14:07:27 2011
From: drc at virtualized.org (David Conrad)
Date: Thu, 12 May 2011 09:07:27 -1000
Subject: 23,000 IP addresses
In-Reply-To: <201105121859.p4CIxI8e002687@mail.r-bonomi.com>
References: <201105121859.p4CIxI8e002687@mail.r-bonomi.com>
Message-ID: <5E0AE064-E97F-4F3D-BB58-ECC0D149FD87@virtualized.org>

On May 12, 2011, at 8:59 AM, Robert Bonomi wrote:
>> I wonder....  does IANA frequently receive legal papers  demanding the
>> name and street address of the customer at  127.0.0.1  ?  :)
> 
> I know people, well at least one,  that have sent spam complaints to IANA 
> claiming junk mail originated from that address. 

I don't recall receiving legal papers for 127.0.0.1, but do recall several demands from law enforcement agencies (and long ago, when I was at APNIC, the US Secret Service) for customer information for RFC 1918 space.

Regards,
-drc




From michael.holstein at csuohio.edu  Thu May 12 14:10:19 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Thu, 12 May 2011 15:10:19 -0400
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <BANLkTik-YNco+qR43fw=AyFJ78ggj6wcQA@mail.gmail.com>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>	<4DCC1FE0.6030802@csuohio.edu>	<BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>	<4DCC23BA.4030405@csuohio.edu>	<BANLkTimqqcnDLBtqZ=VfhTZt_a806JP1Zg@mail.gmail.com>
	<BANLkTik-YNco+qR43fw=AyFJ78ggj6wcQA@mail.gmail.com>
Message-ID: <4DCC309B.5050607@csuohio.edu>


> 11  thepiratebay.piratpartiet.se (194.14.56.29)  197.033 ms  199.376
> ms  197.917 ms
> 12  * * *
>   

At this point, my guess would be that they're doing some sort of DDOS
protection in there somewhere, and haven't gotten it tuned up quite right.

> 13  * * *
>   

~Mike.




From michael.rocco.sabino at gmail.com  Thu May 12 14:53:53 2011
From: michael.rocco.sabino at gmail.com (Michael Sabino)
Date: Thu, 12 May 2011 14:53:53 -0500
Subject: coprorations using BGP for advertising prefixes in mid-1990s
Message-ID: <BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>

If you are a big corporation, and it is 1995, how likely is it that you'll
utilize bgp for advertising your address space to the internet?

Thanks,
Michael Sabino


From matthew at matthew.at  Thu May 12 15:03:18 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 12 May 2011 13:03:18 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>
References: <BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>
Message-ID: <0C72EC5A-CE46-48B9-9918-20CCDFC699E4@matthew.at>


On May 12, 2011, at 12:53 PM, Michael Sabino wrote:

> If you are a big corporation, and it is 1995, how likely is it that you'll
> utilize bgp for advertising your address space to the internet?
> 
> Thanks,
> Michael Sabino

Big? Very.

Matthew Kaufman



From Valdis.Kletnieks at vt.edu  Thu May 12 15:21:59 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 12 May 2011 16:21:59 -0400
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: Your message of "Thu, 12 May 2011 14:53:53 CDT."
	<BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>
References: <BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>
Message-ID: <18828.1305231719@localhost>

On Thu, 12 May 2011 14:53:53 CDT, Michael Sabino said:
> If you are a big corporation, and it is 1995, how likely is it that you'll
> utilize bgp for advertising your address space to the internet?

Well, we got AS1312 sometime before 1996 (the *last changed* timestamp is
19960207), that sort of implies that 1311 other organizations were grabbing AS
numbers before that.  And since an AS number has no real use for anything other
than BGP, that implies some 1,300 organizations doing BGP in the 1995
timeframe.

Look to see who got the first 1000 or 1500 or so AS numbers, that's who was
doing BGP back then.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110512/51e46b65/attachment.bin>

From dorian at blackrose.org  Thu May 12 15:34:42 2011
From: dorian at blackrose.org (Dorian Kim)
Date: Thu, 12 May 2011 16:34:42 -0400
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <18828.1305231719@localhost>
References: <BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>
	<18828.1305231719@localhost>
Message-ID: <20110512203442.GD44081@blackrose.org>

On Thu, May 12, 2011 at 04:21:59PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 12 May 2011 14:53:53 CDT, Michael Sabino said:
> > If you are a big corporation, and it is 1995, how likely is it that you'll
> > utilize bgp for advertising your address space to the internet?
> 
> Well, we got AS1312 sometime before 1996 (the *last changed* timestamp is
> 19960207), that sort of implies that 1311 other organizations were grabbing AS
> numbers before that.  And since an AS number has no real use for anything other
> than BGP, that implies some 1,300 organizations doing BGP in the 1995
> timeframe.

The actual number would be considerably smaller as there were large
(for some definition of large) block assignments of ASNs <~1000 or so 
to various academic networking entities such as NSFNet and regional 
networks as well as other Federal/Military networking organisations.

-dorian



From ebais at a2b-internet.com  Thu May 12 16:02:43 2011
From: ebais at a2b-internet.com (Erik Bais)
Date: Thu, 12 May 2011 23:02:43 +0200
Subject: Pirate Bay suffering unreachable errors
In-Reply-To: <BANLkTik-YNco+qR43fw=AyFJ78ggj6wcQA@mail.gmail.com>
References: <A1EB00F2-82B8-4973-8EE8-09B5A100898D@princeton.edu>	<4DCC1FE0.6030802@csuohio.edu>	<BANLkTinmx60VcGVY8yPfew1FV6S5NROx9Q@mail.gmail.com>	<4DCC23BA.4030405@csuohio.edu>	<BANLkTimqqcnDLBtqZ=VfhTZt_a806JP1Zg@mail.gmail.com>
	<BANLkTik-YNco+qR43fw=AyFJ78ggj6wcQA@mail.gmail.com>
Message-ID: <001701cc10e7$f03fe1f0$d0bfa5d0$@com>

>From Amsterdam :  

traceroute -T -p 80 thepiratebay.org 
traceroute to thepiratebay.org (194.71.107.15), 30 hops max, 60 byte packets
 1  core1-vlan1011.a2b-internet.com (178.249.153.17)  3.401 ms  3.428 ms
3.464 ms
 2  core3-vlan102.a2b-internet.com (178.249.152.35)  1.262 ms  1.320 ms
1.315 ms
 3  10ge-ams-ix.ams1.portlane.net (195.69.145.25)  2.428 ms  2.468 ms  2.515
ms
 4  te-2-1.sto3.se.portlane.net (80.67.4.134)  19.331 ms  19.473 ms  19.373
ms
 5  te-3-2.sto1.se.portlane.net (80.67.4.128)  19.435 ms  19.250 ms  19.465
ms
 6  as48285-fe-kn1.sthix.net (192.121.80.155)  19.085 ms  19.106 ms  18.981
ms
 7  * * *
 8  vlan102.ge-0-3.sth3-core-1.srstubes.net (194.68.0.158)  20.043 ms
19.926 ms  20.218 ms
 9  ge-1-2.sth4-dr-1.srstubes.net (194.68.0.166)  20.823 ms  21.098 ms
22.959 ms
10  ge-0-1.moria-cr-1.piratpartiet.net (194.68.0.146)  21.933 ms  21.955 ms
21.907 ms
11  thepiratebay.piratpartiet.se (194.14.56.29)  23.379 ms  24.555 ms
24.525 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  thepiratebay.org (194.71.107.15)  25.598 ms  24.823 ms  24.714 ms 




From dorn at hetzel.org  Thu May 12 16:15:17 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Thu, 12 May 2011 17:15:17 -0400
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <20110512203442.GD44081@blackrose.org>
References: <BANLkTinxcZB+qa_Wfm5-owT+P1HXccMzHA@mail.gmail.com>
	<18828.1305231719@localhost> <20110512203442.GD44081@blackrose.org>
Message-ID: <BANLkTi=qL8ZExXEOE23iUSu2aDVBUrZ8Hw@mail.gmail.com>

>
>
> The actual number would be considerably smaller as there were large
> (for some definition of large) block assignments of ASNs <~1000 or so
> to various academic networking entities such as NSFNet and regional
> networks as well as other Federal/Military networking organisations.
>
> -dorian
>
>
Well, for one data point, I was issued 3492 around Spring of 1994.


From oberman at es.net  Thu May 12 16:37:07 2011
From: oberman at es.net (Kevin Oberman)
Date: Thu, 12 May 2011 14:37:07 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: Your message of "Thu, 12 May 2011 17:15:17 EDT."
	<BANLkTi=qL8ZExXEOE23iUSu2aDVBUrZ8Hw@mail.gmail.com> 
Message-ID: <20110512213707.2FF721CC2C@ptavv.es.net>

> Date: Thu, 12 May 2011 17:15:17 -0400
> From: Dorn Hetzel <dorn at hetzel.org>
> 
> >
> >
> > The actual number would be considerably smaller as there were large
> > (for some definition of large) block assignments of ASNs <~1000 or so
> > to various academic networking entities such as NSFNet and regional
> > networks as well as other Federal/Military networking organisations.
> >
> > -dorian
> >
> >
> Well, for one data point, I was issued 3492 around Spring of 1994.
> 

Does no one remember EGP? ASNs are MUCH older than BGP. And we were
using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
build saying that we could not expect BGPv4 code over a week old to
work. He felt that we should deploy new code daily.

The big push was to have v4 available before the old PRDB was frozen by
Merit/NSFnet. (And, who remembers the PRDB?)
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From dorn at hetzel.org  Thu May 12 16:58:09 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Thu, 12 May 2011 17:58:09 -0400
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <20110512213707.2FF721CC2C@ptavv.es.net>
References: <BANLkTi=qL8ZExXEOE23iUSu2aDVBUrZ8Hw@mail.gmail.com>
	<20110512213707.2FF721CC2C@ptavv.es.net>
Message-ID: <BANLkTi=k3sE99f2=Z8paBiHZzGEcN1uupQ@mail.gmail.com>

>
> Does no one remember EGP? ASNs are MUCH older than BGP. And we were
> using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
> when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
> build saying that we could not expect BGPv4 code over a week old to
> work. He felt that we should deploy new code daily.
>
> The big push was to have v4 available before the old PRDB was frozen by
> Merit/NSFnet. (And, who remembers the PRDB?)
> --
>

I caught the trailing edge of V3.  I remember announcing 129 prefixes to
Sprintlink, one for our B, and 128 for our /17 from C-space :)


From jra at baylink.com  Thu May 12 17:25:24 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 12 May 2011 18:25:24 -0400 (EDT)
Subject: Routing study
In-Reply-To: <E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
Message-ID: <30954065.104.1305239124656.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Greg Whynott" <greg.whynott at oicr.on.ca>

> On May 12, 2011, at 6:30 AM, <bmanning at vacation.karoshi.com>
> <bmanning at vacation.karoshi.com> wrote:
> > I would appreciate it if they
> > would at least notify me ahead of time if they want to futz around
> > with prefixes that are not registered to them.
> 
> er?. isn't that exactly what they just did, notified you ahead of
> time? the test starts on the 18th.
> 
> helps to read before you jump!

Well, Greg, I'm *pretty* sure Bill meant "ahead of time before they make
a big public announcement".  That said, I can't imagine that this isn't 
a typo, or a record-keeping error.

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From george.herbert at gmail.com  Thu May 12 17:43:00 2011
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 12 May 2011 15:43:00 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <BANLkTi=k3sE99f2=Z8paBiHZzGEcN1uupQ@mail.gmail.com>
References: <BANLkTi=qL8ZExXEOE23iUSu2aDVBUrZ8Hw@mail.gmail.com>
	<20110512213707.2FF721CC2C@ptavv.es.net>
	<BANLkTi=k3sE99f2=Z8paBiHZzGEcN1uupQ@mail.gmail.com>
Message-ID: <BANLkTi=MFyiwaaQYwwqd-OCtXNnQYN=tRg@mail.gmail.com>

On Thu, May 12, 2011 at 2:58 PM, Dorn Hetzel <dorn at hetzel.org> wrote:
>>
>> Does no one remember EGP? ASNs are MUCH older than BGP. And we were
>> using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
>> when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
>> build saying that we could not expect BGPv4 code over a week old to
>> work. He felt that we should deploy new code daily.
>>
>> The big push was to have v4 available before the old PRDB was frozen by
>> Merit/NSFnet. (And, who remembers the PRDB?)
>> --
>>
>
> I caught the trailing edge of V3. ?I remember announcing 129 prefixes to
> Sprintlink, one for our B, and 128 for our /17 from C-space :)

Flashbacks to 1993-4 all over again.



-- 
-george william herbert
george.herbert at gmail.com



From jra at baylink.com  Thu May 12 17:44:22 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 12 May 2011 18:44:22 -0400 (EDT)
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <18828.1305231719@localhost>
Message-ID: <25069460.110.1305240262601.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> On Thu, 12 May 2011 14:53:53 CDT, Michael Sabino said:
> > If you are a big corporation, and it is 1995, how likely is it that
> > you'll utilize bgp for advertising your address space to the internet?
> 
> Well, we got AS1312 sometime before 1996 (the *last changed* timestamp is
> 19960207), that sort of implies that 1311 other organizations were grabbing AS
> numbers before that. And since an AS number has no real use for anything other
> than BGP, that implies some 1,300 organizations doing BGP in the 1995
> timeframe.

I myself inferred that he meant "large end-user corporations whose primary
line of business was *not* being a network provider".

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jra at baylink.com  Thu May 12 17:45:32 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 12 May 2011 18:45:32 -0400 (EDT)
Subject: [rt-users] Work with Google Apps?
In-Reply-To: <BANLkTik5Si=E8+mTYXNz9x4GHsaZgkYONA@mail.gmail.com>
Message-ID: <24746803.112.1305240332095.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Gavin Henry" <gavin.henry at gmail.com>

> Can this be done?

No; it's not possible for people to work with Google Apps.

Cheers,
-- jr 'well, not *wise*, anyway' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From gbonser at seven.com  Thu May 12 17:49:45 2011
From: gbonser at seven.com (George Bonser)
Date: Thu, 12 May 2011 15:49:45 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
References: <4DCA9FAF.70409@l-w.ca><1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry><4DCB5091.4050904@kenweb.org><BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com><0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com><iqgcmq$t9o$1@dough.gmane.org><OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com><4DCBDE59.2000001@unfix.org><alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se><5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>

> In the RIPE region, being multihomed or planning to be it is not a
> sufficient condition for getting a PI prefix.  And even if it was, the
> hit on DFZ is the same as from getting allocation from LIR. Even if
> they get their own /32, the hit would be the same (modulo individual
> FIB/RIB implementations).
> Consequently, there's work in progress to modernize RIPE IPv6 address
> policy.
> http://ripe62.ripe.net/presentations/148-wg.pdf p. 19 and forward.
> 
> Cheers,
> Martin

Martin,

Possibly the hit might be the same, but possibly not.  An organization
that requires a second /48 from their upstream might get one that can't
be aggregated with the previous one.  It is my understanding that ARIN
is attempting to structure their assignments so that if such growth
occurs in PI space, it is likely (though not guaranteed) that the
network will get a subsequent allocation that can be aggregated with the
first.  

George




From george.herbert at gmail.com  Thu May 12 18:03:43 2011
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 12 May 2011 16:03:43 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <25069460.110.1305240262601.JavaMail.root@benjamin.baylink.com>
References: <18828.1305231719@localhost>
	<25069460.110.1305240262601.JavaMail.root@benjamin.baylink.com>
Message-ID: <BANLkTikp=fHom6c392-tVHgnmQ=T4m7FRQ@mail.gmail.com>

On Thu, May 12, 2011 at 3:44 PM, Jay Ashworth <jra at baylink.com> wrote:
> ----- Original Message -----
>> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>
>
>> On Thu, 12 May 2011 14:53:53 CDT, Michael Sabino said:
>> > If you are a big corporation, and it is 1995, how likely is it that
>> > you'll utilize bgp for advertising your address space to the internet?
>>
>> Well, we got AS1312 sometime before 1996 (the *last changed* timestamp is
>> 19960207), that sort of implies that 1311 other organizations were grabbing AS
>> numbers before that. And since an AS number has no real use for anything other
>> than BGP, that implies some 1,300 organizations doing BGP in the 1995
>> timeframe.
>
> I myself inferred that he meant "large end-user corporations whose primary
> line of business was *not* being a network provider".

Large end-user companies generally multihomed by that time, and you
generally did that by BGP4 at the time (post-1994), and before that
BGP3, and before that EGP, and before that... well, there was little
"commercial ISPness" other than NSFNet connectivity and the regional
networks back then so multihoming was somewhat of a moot point.

Thank you again, UUNet/Alternet and PSI!


-- 
-george william herbert
george.herbert at gmail.com



From packetgrrl at gmail.com  Thu May 12 18:24:14 2011
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 12 May 2011 17:24:14 -0600
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <20110512213707.2FF721CC2C@ptavv.es.net>
References: <BANLkTi=qL8ZExXEOE23iUSu2aDVBUrZ8Hw@mail.gmail.com>
	<20110512213707.2FF721CC2C@ptavv.es.net>
Message-ID: <BANLkTinWbT9523P8aaQQWMssfJt4GSkj4g@mail.gmail.com>

My name is Cathy and I used to EGP.  :-)  wow that's a blast from the past.
In the late 80s the NSFNet used EGP.  That's why the RADB came to be.  EGP
only tolerated one route to any destination.  Otherwise lots of fun loops.
 :-)

Kevin, when I configured ESNet to go from EGP to BGP (in the early 90s) we
hit what I call a Yakov limit.  We were like the 64th BGP peer and the
NSFNET shut down completely.  It was a total riot.

Thanks for the memories!
----Cathy

On Thu, May 12, 2011 at 3:37 PM, Kevin Oberman <oberman at es.net> wrote:

> > Date: Thu, 12 May 2011 17:15:17 -0400
> > From: Dorn Hetzel <dorn at hetzel.org>
> >
> > >
> > >
> > > The actual number would be considerably smaller as there were large
> > > (for some definition of large) block assignments of ASNs <~1000 or so
> > > to various academic networking entities such as NSFNet and regional
> > > networks as well as other Federal/Military networking organisations.
> > >
> > > -dorian
> > >
> > >
> > Well, for one data point, I was issued 3492 around Spring of 1994.
> >
>
> Does no one remember EGP? ASNs are MUCH older than BGP. And we were
> using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
> when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
> build saying that we could not expect BGPv4 code over a week old to
> work. He felt that we should deploy new code daily.
>
> The big push was to have v4 available before the old PRDB was frozen by
> Merit/NSFnet. (And, who remembers the PRDB?)
> --
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman at es.net                  Phone: +1 510 486-8634
> Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
>
>


From owen at delong.com  Thu May 12 18:44:57 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 May 2011 16:44:57 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca><1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry><4DCB5091.4050904@kenweb.org><BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com><0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com><iqgcmq$t9o$1@dough.gmane.org><OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com><4DCBDE59.2000001@unfix.org><alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se><5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
Message-ID: <AF330D42-3BC8-4586-B5AC-94BCC6B01B34@delong.com>


On May 12, 2011, at 3:49 PM, George Bonser wrote:

>> In the RIPE region, being multihomed or planning to be it is not a
>> sufficient condition for getting a PI prefix.  And even if it was, the
>> hit on DFZ is the same as from getting allocation from LIR. Even if
>> they get their own /32, the hit would be the same (modulo individual
>> FIB/RIB implementations).
>> Consequently, there's work in progress to modernize RIPE IPv6 address
>> policy.
>> http://ripe62.ripe.net/presentations/148-wg.pdf p. 19 and forward.
>> 
>> Cheers,
>> Martin
> 
> Martin,
> 
> Possibly the hit might be the same, but possibly not.  An organization
> that requires a second /48 from their upstream might get one that can't
> be aggregated with the previous one.  It is my understanding that ARIN
> is attempting to structure their assignments so that if such growth
> occurs in PI space, it is likely (though not guaranteed) that the
> network will get a subsequent allocation that can be aggregated with the
> first.  
> 
> George
> 

Policy dictates that they reserve at least to the /44 for /48 assignments.

Owen




From tony.li at tony.li  Thu May 12 18:47:54 2011
From: tony.li at tony.li (Tony Li)
Date: Thu, 12 May 2011 16:47:54 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: <20110512213707.2FF721CC2C@ptavv.es.net>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
Message-ID: <0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>


On May 12, 2011, at 2:37 PM, Kevin Oberman wrote:

> Does no one remember EGP? ASNs are MUCH older than BGP. And we were
> using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
> when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
> build saying that we could not expect BGPv4 code over a week old to
> work. He felt that we should deploy new code daily.


To be fair, that was for folks on the isp-geeks mailing list, who were effectively doing alpha test with me.  I was fixing about 1 significant bug per day and doing at least one release per day.  10 day old code was missing at least 10 fixes...  ;-)   And that was BGP3.   BGP4 was the next developer.

Regards,
Tony




From jra at baylink.com  Thu May 12 18:50:28 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 12 May 2011 19:50:28 -0400 (EDT)
Subject: Ok, this is getting embarassing.
Message-ID: <20666620.120.1305244228437.JavaMail.root@benjamin.baylink.com>

There's something happening here.  What it is, ain't exactly clear.

I'm hoping it's my mail client rather than my brain.  In any event, I'll
double check my mail headers before hitting send more carefully next time.

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jra at baylink.com  Thu May 12 19:13:55 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 12 May 2011 20:13:55 -0400 (EDT)
Subject: Ok, this is getting embarassing.
In-Reply-To: <20666620.120.1305244228437.JavaMail.root@benjamin.baylink.com>
Message-ID: <33151655.128.1305245635833.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> There's something happening here. What it is, ain't exactly clear.
> 
> I'm hoping it's my mail client rather than my brain.

On reflection, it probably is in my brain.  Check back to the 24/7 thread
earlier this month, and note that I presently working 4p-2a Sat/Sun, 10a-8p
Tue, and 00-10a Thu.  :-}

Cheers,
-- jr 'shutting up now' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From r.engehausen at gmail.com  Thu May 12 19:31:47 2011
From: r.engehausen at gmail.com (Roy)
Date: Thu, 12 May 2011 17:31:47 -0700
Subject: corporations using BGP for advertising prefixes in mid-1990s
Message-ID: <4DCC7BF3.9070202@gmail.com>

On 5/12/2011 4:03 PM, George Herbert wrote:
 > ....
 > Large end-user companies generally multihomed by that time, and you
 > generally did that by BGP4 at the time (post-1994), and before that
 > BGP3, and before that EGP, and before that... well, there was little
 > "commercial ISPness" other than NSFNet connectivity and the regional
 > networks back then so multihoming was somewhat of a moot point.
 >
 > Thank you again, UUNet/Alternet and PSI!
 >

The management of the large end-user company I worked for could barely 
spell Internet at the beginning of 1995.  A few connections to the 
Internet existed and the lab where I worked was experimenting with a 
socks-server.  There was a large intranet allocated from the company's 
class A space.




From mysidia at gmail.com  Thu May 12 19:39:35 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 12 May 2011 19:39:35 -0500
Subject: IPv6 foot-dragging
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
	<5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
Message-ID: <BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>

On Thu, May 12, 2011 at 5:49 PM, George Bonser <gbonser at seven.com> wrote:
> Possibly the hit might be the same, but possibly not. ?An organization
> that requires a second /48 from their upstream might get one that can't
> be aggregated with the previous one. ?It is my understanding that ARIN

A very important distinction. The _immediate_  hit to the DFZ might be
the same as obtaining PI V6 space,
but the _long term_ hit to the DFZ might be much greater;
particularly if the user starts obtaining
multiple non-aggregable /48s  from different sources,  or obtains an
additional PI allocation later, but
keeps using the original /48.

It is a heck of a lot better for network stability that any
multi-homed user get a /32 PI,
and find that they will never need more than a /48 of it,  than it is
to try to "conserve"
 address bits,  and  require the multi-homed user stick it out with a /48.

With IPv6,  bits for addressing networks are not scarce (like they
were with IPv4),
but more importantly, router FIB bits  _are_  scarcer.

With IPv4, we face the certainty of address bit assignment exhaustion.
With IPv6, we face a greater risk of address bit  _router_ assignment
exhaustion.

Because every IPv6 address has 4x  as  many bits as an IPv4 address.
And a /48 prefix has    consumes at least  2x as many bits  as a  /24 prefix.

--
-JH



From brett at the-watsons.org  Thu May 12 19:51:35 2011
From: brett at the-watsons.org (Brett Watson)
Date: Thu, 12 May 2011 17:51:35 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: <0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
Message-ID: <5EAF9DC2-1ECD-4B43-8F31-9984F449D9B7@the-watsons.org>

On May 12, 2011, at 4:47 PM, Tony Li wrote:

> To be fair, that was for folks on the isp-geeks mailing list, who were effectively doing alpha test with me.  I was fixing about 1 significant bug per day and doing at least one release per day.  10 day old code was missing at least 10 fixes...  ;-)   And that was BGP3.   BGP4 was the next developer.

My favorite line/memory was when we'd get an image from you guys, with the tag:

Confidence level: Boots in the lab

:)

-b


From jsw at inconcepts.biz  Thu May 12 21:02:40 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Thu, 12 May 2011 22:02:40 -0400
Subject: IPv6 foot-dragging
In-Reply-To: <BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
	<5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
	<BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>
Message-ID: <BANLkTimpC0AqXWVad7YaixUpM_x=owWmhg@mail.gmail.com>

On Thu, May 12, 2011 at 8:39 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> A very important distinction. The _immediate_ ?hit to the DFZ might be
> the same as obtaining PI V6 space,
> but the _long term_ hit to the DFZ might be much greater;

The real issue is that there are many /48 announcements today which
should be either:
1) not in the DFZ at all, but are because of
  a) accidental pollution/leaks
  b) intentional de-aggregation, which is very often inappropriate
2) should instead be PI allocations to organizations, not delegated PA space

This will only get worse unless we task the RIRs with doing the only
real job they have left in a post-v6-transition world: working to
enable connectivity without unnecessary DFZ bloat.  There is no longer
a need for RIRs to say "no" to allocation requests on the basis that
we will run out of (IPv6) addresses.  The sole reason for technical
barriers in the application/request process at all is to keep the DFZ
in-check.  Yet, our community still refuses to explicitly alter RIR
policy such that controlling DFZ growth is an explicit component of
the RIRs' mission.

We can very easily choose to have one of two scenarios:
1) The bad situation with IPv4, where half the DFZ is accidental leaks
or poorly-designed networks that are essentially on auto-pilot; yet
small businesses and ISPs are not able to acquire PI space for use in
BGP and must use PA blocks from their transit providers
2) An opposite situation, where the DFZ does not contain any
de-aggregates, but contains many PI routes from organizations who have
their PI space announced by their ISP for the purpose of avoiding
re-numbering, not for multi-homing using their own BGP
routers/ASN/etc.

Getting to either one of these two extremes is very easy.  Right now,
we are heading for #1.  If all technical barriers for acquiring IPv6
PI were removed, we would probably have #2.  How do we find a medium
between them, where there aren't ASNs originating 1000+ unnecessary
de-aggregates out of their own carelessness and ineptitude, but also,
there isn't a /32 (or /48) announced for every mom & pop ISP who
themselves do not participate in BGP, or every corporate branch office
who do not want to renumber when they change ISPs?

This is how RIRs are failing us.  Except that the RIRs really can't
fail us, because they do what the members direct them to do through
policy.  If we don't task them to help the community do a better job
at managing the IPv6 DFZ now, we may never be able to go back and fix
it.  The genie is out of the bottle with IPv4; but realistically, IPv6
is young enough that we have plenty of wiggle-room in terms of
allocation policy, typical inter-domain route filters, and so on.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts



From jeroen at mompl.net  Thu May 12 21:09:06 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Thu, 12 May 2011 19:09:06 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
References: <4DCA9FAF.70409@l-w.ca>	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>	<4DCB5091.4050904@kenweb.org>	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
Message-ID: <4DCC92C2.20207@mompl.net>

Anthony Francis - Handy Networks LLC wrote:
> I can confirm full IPV6 connectivity from HE.

I'm using the HE tunnel also and it works fine.

But I have a bit of difficulty getting the right ip6tables (and the 
single iptables) rules to work so that my one server that tunnels ipv6 
can serve as a gateway server.

I used http://madduck.net/docs/ipv6/ as a guide.

Using tcpdump I can see a ping from a server behind the gateway going to 
the gateway server and the gateway server sends it to the tunnel, but 
nothing's coming back.

i.e.:

behind gateway:

# ping6 2620:0:2d0:200::10
PING 2620:0:2d0:200::10(2620:0:2d0:200::10) 56 data bytes
^C
--- 2620:0:2d0:200::10 ping statistics ---
392 packets transmitted, 0 received, 100% packet loss, time 391484ms


gateway:

# tcpdump -t -n -s 512 -vv ip6 or proto ipv6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 
512 bytes
IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 
2001:470:85cd:0:20c:6eff:fed2:1947 > 2620:0:2d0:200::10: [icmp6 sum ok] 
ICMP6, echo request, length 64, seq 317
IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 
2001:470:85cd:0:20c:6eff:fed2:1947 > 2620:0:2d0:200::10: [icmp6 sum ok] 
ICMP6, echo request, length 64, seq 318
IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 
2001:470:85cd:0:20c:6eff:fed2:1947 > 2620:0:2d0:200::10: [icmp6 sum ok] 
ICMP6, echo request, length 64, seq 319


Anything obvious I might have missed? Can post more specifics later if 
needed.

Thanks,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From hank at efes.iucc.ac.il  Thu May 12 22:41:27 2011
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Fri, 13 May 2011 06:41:27 +0300 (IDT)
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: <0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
Message-ID: <alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>

On Thu, 12 May 2011, Tony Li wrote:

> To be fair, that was for folks on the isp-geeks mailing list, who were effectively doing alpha test with me.  I was fixing about 1 significant bug per day and doing at least one release per day.  10 day old code was missing at least 10 fixes...  ;-)   And that was BGP3.   BGP4 was the next developer.

I always liked seeing the string "tli" in the IOS bundle in those days.

-Hank
AS378

>
> Regards,
> Tony



From adrian at creative.net.au  Thu May 12 22:44:30 2011
From: adrian at creative.net.au (Adrian Chadd)
Date: Fri, 13 May 2011 11:44:30 +0800
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
	<alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
Message-ID: <20110513034430.GF24006@skywalker.creative.net.au>

On Fri, May 13, 2011, Hank Nussbacher wrote:

> I always liked seeing the string "tli" in the IOS bundle in those days.

Whoa, you mean Cisco IOS images have "built by" names other than "prod rel team" ?

(heh.)



Adrian




From hank at efes.iucc.ac.il  Thu May 12 22:47:49 2011
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Fri, 13 May 2011 06:47:49 +0300 (IDT)
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: <alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
	<alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
Message-ID: <alpine.LRH.2.00.1105130645490.14965@efes.iucc.ac.il>

On Fri, 13 May 2011, Hank Nussbacher wrote:

> On Thu, 12 May 2011, Tony Li wrote:
>
>>  To be fair, that was for folks on the isp-geeks mailing list, who were
>>  effectively doing alpha test with me.  I was fixing about 1 significant
>>  bug per day and doing at least one release per day.  10 day old code was
>>  missing at least 10 fixes...  ;-)   And that was BGP3.   BGP4 was the next
>>  developer.
>
> I always liked seeing the string "tli" in the IOS bundle in those days.

It also caused me to write up an FAQ to help those corporations:
http://www.gossamer-threads.com/lists/nanog/users/1753?do=post_view_threaded

-Hank

>
> -Hank
> AS378
>
>>
>>  Regards,
>>  Tony
>
>



From packetgrrl at gmail.com  Thu May 12 22:53:07 2011
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 12 May 2011 21:53:07 -0600
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <20110513034430.GF24006@skywalker.creative.net.au>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
	<alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
	<20110513034430.GF24006@skywalker.creative.net.au>
Message-ID: <BANLkTi=qkRXgf11pSJv4KfU8tMLgUR6ZvA@mail.gmail.com>

Yes images had names in them and in 1989 you could call cisco if your box
was broken and Eileen would just send parts.

----Cathy

On Thu, May 12, 2011 at 9:44 PM, Adrian Chadd <adrian at creative.net.au>wrote:

> On Fri, May 13, 2011, Hank Nussbacher wrote:
>
> > I always liked seeing the string "tli" in the IOS bundle in those days.
>
> Whoa, you mean Cisco IOS images have "built by" names other than "prod rel
> team" ?
>
> (heh.)
>
>
>
> Adrian
>
>
>


From bobbyjim at gmail.com  Thu May 12 23:10:59 2011
From: bobbyjim at gmail.com (bobbyjim at gmail.com)
Date: Thu, 12 May 2011 23:10:59 -0500
Subject: coprorations using BGP for advertising prefixes in mid-1990s
Message-ID: <4dccaf53.1074650a.52c2.5994@mx.google.com>

   And if you had a great question or response, would you get a box of
   Smarties?
   Robert

   -- Sent from my Palm Pre
   __________________________________________________________________

   On May 12, 2011 10:54 PM, cja at daydream.com <packetgrrl at gmail.com>
   wrote:
   Yes images had names in them and in 1989 you could call cisco if your
   box
   was broken and Eileen would just send parts.
   ----Cathy
   On Thu, May 12, 2011 at 9:44 PM, Adrian Chadd
   <adrian at creative.net.au>wrote:
   > On Fri, May 13, 2011, Hank Nussbacher wrote:
   >
   > > I always liked seeing the string "tli" in the IOS bundle in those
   days.
   >
   > Whoa, you mean Cisco IOS images have "built by" names other than
   "prod rel
   > team" ?
   >
   > (heh.)
   >
   >
   >
   > Adrian
   >
   >
   >

From brett at the-watsons.org  Thu May 12 23:41:47 2011
From: brett at the-watsons.org (Brett Watson)
Date: Thu, 12 May 2011 21:41:47 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <BANLkTi=qkRXgf11pSJv4KfU8tMLgUR6ZvA@mail.gmail.com>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
	<alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
	<20110513034430.GF24006@skywalker.creative.net.au>
	<BANLkTi=qkRXgf11pSJv4KfU8tMLgUR6ZvA@mail.gmail.com>
Message-ID: <F5EBAE0A-94CE-434B-98C6-09DAD3490CD1@the-watsons.org>

On May 12, 2011, at 8:53 PM, cja at daydream.com wrote:

> Yes images had names in them and in 1989 you could call cisco if your box
> was broken and Eileen would just send parts.

Hell, you knew from the image name wether Toni, Ravi, Dino, etc have built the image. It was quite personal back then :)




From tony.li at tony.li  Fri May 13 00:40:21 2011
From: tony.li at tony.li (Tony Li)
Date: Thu, 12 May 2011 22:40:21 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <F5EBAE0A-94CE-434B-98C6-09DAD3490CD1@the-watsons.org>
References: <20110512213707.2FF721CC2C@ptavv.es.net>
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li>
	<alpine.LRH.2.00.1105130640230.14789@efes.iucc.ac.il>
	<20110513034430.GF24006@skywalker.creative.net.au>
	<BANLkTi=qkRXgf11pSJv4KfU8tMLgUR6ZvA@mail.gmail.com>
	<F5EBAE0A-94CE-434B-98C6-09DAD3490CD1@the-watsons.org>
Message-ID: <73D758EB-492D-4D61-9229-FBDA7D3F47DD@tony.li>


On May 12, 2011, at 9:41 PM, Brett Watson wrote:

> Hell, you knew from the image name wether Tony, Ravi, Dino, etc have built the image. It was quite personal back then :)


And then some bright fellow started hitting on our build engineers and...  that was the end of that.  ;-(

Tony




From kauer at biplane.com.au  Fri May 13 00:52:33 2011
From: kauer at biplane.com.au (Karl Auer)
Date: Fri, 13 May 2011 15:52:33 +1000
Subject: Interested in input on tunnels as an IPv6 transition technology
Message-ID: <1305265953.18376.1032.camel@karl>

Hullo all.

I'm working on a talk, and would be interested to know what people think
is good about tunnels as an IPv6 transition technology, and what people
think is bad about tunnels.

It would probably be best to let me know off-list :-) but I'm happy to
summarise back to the list. Any references you have to useful papers,
articles, discussions etc would also be appreciated.

I'm looking for both general problems and advantages, but also
advantages and disadvantages specific to particular tunnel types. It
would also be helpful to know from what perspective particular things
are good or bad, in so far as it isn't obvious. A carrier has a
different perspective than, say, a home user, who will have a different
perspective again to an enterprise user.

Many thanks in advance for your input.

Regards, K.

PS: Note the all-important words "as an IPv6 transition technology"...


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110513/66a061c3/attachment.bin>

From tad1214 at gmail.com  Fri May 13 01:32:19 2011
From: tad1214 at gmail.com (Thomas Donnelly)
Date: Fri, 13 May 2011 01:32:19 -0500
Subject: Comcast Bulk/Metro Ethernet
Message-ID: <BANLkTikzunjkLsiobMT79MvFoLTcL4OpwQ@mail.gmail.com>

Is there anyone from the Comcast Bulk or Metro Ethernet departments that can
contact me off list?

Thanks
-=Tom


From brandon at rd.bbc.co.uk  Fri May 13 02:26:17 2011
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Fri, 13 May 2011 08:26:17 +0100 (BST)
Subject: Interested in input on tunnels as an IPv6 transition technology
Message-ID: <201105130726.IAA06542@sunf10.rd.bbc.co.uk>

> would be interested to know what people think
> is good about tunnels as an IPv6 transition technology, and what people
> think is bad about tunnels.

The good thing about tunnels is people can build them where there's no
proper network

The bad thing about tunnels is people build them instead of a
proper network

brandon



From iljitsch at muada.com  Fri May 13 02:56:54 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Fri, 13 May 2011 09:56:54 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
	<5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
	<BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>
Message-ID: <5E4A5639-1AA3-4A77-9D92-BC4EB861FF34@muada.com>

On 13 mei 2011, at 2:39, Jimmy Hess wrote:

> if the user starts obtaining
> multiple non-aggregable /48s  from different sources,  or obtains an
> additional PI allocation later, but
> keeps using the original /48.

Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place.

The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.

And that all in case a /48 isn't big enough (which is ridiculously rare in and of itself) to save ONE entry in the global routing table. So by trying to conserve the table we make it impossible to protect our routing tables.

> It is a heck of a lot better for network stability that any
> multi-homed user get a /32 PI,

No, that's completely ridiculous. It's like saying all flights should be flown with 747s just in case 10 football teams show up unexpectedly. That is, if a 747 could carry a million people (64k more than a small 16-seat plane).

Yes, the IPv6 address space is big but by giving people who need more than 65000 subnets a /32 so they can have 4000000000 subnets is unbelievably wasteful for no other reason than laziness.


From iljitsch at muada.com  Fri May 13 03:02:40 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Fri, 13 May 2011 10:02:40 +0200
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: <1305265953.18376.1032.camel@karl>
References: <1305265953.18376.1032.camel@karl>
Message-ID: <10587D52-E49C-44E2-B284-BE7C900C9EBA@muada.com>

On 13 mei 2011, at 7:52, Karl Auer wrote:

> I'm working on a talk, and would be interested to know what people think
> is good about tunnels as an IPv6 transition technology, and what people
> think is bad about tunnels.

Without tunnels we'd have no IPv6 today. Even today many people, especially home users, depend on them. But it would have been impossible to get IPv6 started by running it native-only.

Tunnels can work very well and if they're direct they can be almost as good as native connectivity. However, in the past we saw Europeans get tunneled IPv6 connectivity from Japan. That kind of thing is very bad because it inflates RTTs and thus slows everything down.

Enabling automatic tunneling by default is also a mistake because then you think you have IPv6 even if the automatic tunnel doesn't work because relays are unreachable or stuff is firewalled.

A downside of tunneling is the reduced MTU, but hopefully the fact that tunnels are common makes people fix PMTUD problems rather than blindly send 1500-byte packets and let the chips fall where they may that way too many people do with IPv4.

So... tunnels can be good or can be bad, but native is still better than a good tunnel.


From joe at gonetforward.com  Fri May 13 03:39:38 2011
From: joe at gonetforward.com (Joe Renwick)
Date: Fri, 13 May 2011 01:39:38 -0700
Subject: Need the perspective of a Level3 customer.
Message-ID: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>

Can anyone peering with Level3 directly tell me if they are seeing
63.210.162.0/24 coming from the Level3 peer?

Thanks for the help.

Cheers,

-- 
Joe Renwick
IP Network Consultant, CCIE #16465
GO NETFORWARD!
Direct: 619-800-2055, Emergency Support: 800-719-0504
Is your network moving you forward?


From m.hallgren at free.fr  Fri May 13 03:50:54 2011
From: m.hallgren at free.fr (Michael Hallgren)
Date: Fri, 13 May 2011 10:50:54 +0200
Subject: Need the perspective of a Level3 customer.
In-Reply-To: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
References: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
Message-ID: <1305276654.3193.29.camel@home>

Le vendredi 13 mai 2011 ? 01:39 -0700, Joe Renwick a ?crit :
> Can anyone peering with Level3 directly tell me if they are seeing
> 63.210.162.0/24 coming from the Level3 peer?

Yes, I do.

mh

> 
> Thanks for the help.
> 
> Cheers,
> 





From tom at ninjabadger.net  Fri May 13 03:51:25 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Fri, 13 May 2011 09:51:25 +0100
Subject: Need the perspective of a Level3 customer.
In-Reply-To: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
References: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
Message-ID: <1305276685.3033.3.camel@teh-desktop>

On Fri, 2011-05-13 at 01:39 -0700, Joe Renwick wrote:
> Can anyone peering with Level3 directly tell me if they are seeing
> 63.210.162.0/24 coming from the Level3 peer?
> 
> Thanks for the help.
> 
> Cheers,

Hi Joe,

#show bgp ipv4 unicast 63.210.162.0/24
BGP routing table entry for 63.210.162.0/24, version 26824780
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1         
  3356 16582
    195.50.113.161 from 195.50.113.161 (4.68.0.179)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2002
  6461 3356 16582
    79.141.38.194 from 79.141.38.194 (64.125.0.165)
      Origin IGP, metric 28, localpref 150, valid, external, best
      Community: 6461:5997

Hope this helps. :)

Tom




From joe at gonetforward.com  Fri May 13 03:55:57 2011
From: joe at gonetforward.com (Joe Renwick)
Date: Fri, 13 May 2011 01:55:57 -0700
Subject: Need the perspective of a Level3 customer.
In-Reply-To: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
References: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
Message-ID: <BANLkTikNdH1YRX15tsvPP0oLyJ+usqUFBQ@mail.gmail.com>

Thanks again to all who replied... looks like other Level3 customer are
seeing the /24.  Looks like the issue is specific to San Diego.  Any routing
information from other SD Level3 customer would be appreciated.

Cheers,

Joe

On Fri, May 13, 2011 at 1:39 AM, Joe Renwick <joe at gonetforward.com> wrote:

> Can anyone peering with Level3 directly tell me if they are seeing
> 63.210.162.0/24 coming from the Level3 peer?
>
> Thanks for the help.
>
> Cheers,
>
> --
> Joe Renwick
> IP Network Consultant, CCIE #16465
> GO NETFORWARD!
> Direct: 619-800-2055, Emergency Support: 800-719-0504
> Is your network moving you forward?
>
>
>


-- 
Joe Renwick
IP Network Consultant, CCIE #16465
GO NETFORWARD!
Direct: 619-800-2055, Emergency Support: 800-719-0504
Is your network moving you forward?


From joly at punkcast.com  Fri May 13 04:03:11 2011
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 13 May 2011 05:03:11 -0400
Subject: dot xxx live or not?
Message-ID: <BANLkTi=tgXWrYm-RZJ-NrXzApz7+37Od3Q@mail.gmail.com>

About a month ago it was announced that the xxx sTLD had "gone live" i.e.
been added to the IANA root zone
http://www.domainnamenews.com/registries/xxx-live-root-servers/9191

I recall checking at the time that http://icmregistry.xxx worked

Now it doesn't. Anyone know what's going on?

j


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From randy at psg.com  Fri May 13 04:12:22 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 13 May 2011 11:12:22 +0200
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: <201105130726.IAA06542@sunf10.rd.bbc.co.uk>
References: <201105130726.IAA06542@sunf10.rd.bbc.co.uk>
Message-ID: <m262pf0xs9.wl%randy@psg.com>

> The good thing about tunnels is people can build them where there's no
> proper network

and the result is a network that is broken differently



From bortzmeyer at nic.fr  Fri May 13 04:20:17 2011
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 13 May 2011 11:20:17 +0200
Subject: dot xxx live or not?
In-Reply-To: <BANLkTi=tgXWrYm-RZJ-NrXzApz7+37Od3Q@mail.gmail.com>
References: <BANLkTi=tgXWrYm-RZJ-NrXzApz7+37Od3Q@mail.gmail.com>
Message-ID: <20110513092017.GA11822@nic.fr>

On Fri, May 13, 2011 at 05:03:11AM -0400,
 Joly MacFie <joly at punkcast.com> wrote 
 a message of 19 lines which said:

> I recall checking at the time that http://icmregistry.xxx worked
> 
> Now it doesn't. Anyone know what's going on?

The TLD ".xxx" works. Names like sex.xxx or icmregistry.xxx have
apparently been deleted. nic.xxx or about.xxx are still there in the
DNS and the Web site http://about.xxx/ works.



From blake at ispn.net  Fri May 13 09:44:11 2011
From: blake at ispn.net (Blake Hudson)
Date: Fri, 13 May 2011 09:44:11 -0500
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: <201105130726.IAA06542@sunf10.rd.bbc.co.uk>
References: <201105130726.IAA06542@sunf10.rd.bbc.co.uk>
Message-ID: <4DCD43BB.8030506@ispn.net>


>> would be interested to know what people think
>> is good about tunnels as an IPv6 transition technology, and what people
>> think is bad about tunnels.
> The good thing about tunnels is people can build them where there's no
> proper network
>
> The bad thing about tunnels is people build them instead of a
> proper network
>
> brandon
>
We've used an HE tunnel with BGP for about a year and it has not been
reliable enough for my tastes. However, I think it's great for testing -
I just wouldn't want to rely on it for production. One, it's not ideal
to force traffic over a tunnel that incurs additional processing,
latency, and reliability problems. Second, in the case of a free HE
tunnel, it might be viewed as impolite to send the tunnel provider lots
of data (I don't remember seeing a bandwidth usage policy).

Only in the case where local peers refuse to provide reliable IP6
transit would I consider using a tunnel full time for IP6 traffic. And
even then, probably only if I was paying and had some sort of service
guarantees and support from the tunnel provider. I would look at
switching local peers for transit before relying on a tunnel.

--Blake



From oberman at es.net  Fri May 13 10:09:11 2011
From: oberman at es.net (Kevin Oberman)
Date: Fri, 13 May 2011 08:09:11 -0700
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: Your message of "Thu, 12 May 2011 16:47:54 PDT."
	<0B720675-2E6A-4964-8E6F-C2CF0E97C945@tony.li> 
Message-ID: <20110513150911.033C61CC2C@ptavv.es.net>

> From: Tony Li <tony.li at tony.li>
> Date: Thu, 12 May 2011 16:47:54 -0700
> 
> On May 12, 2011, at 2:37 PM, Kevin Oberman wrote:
> 
> > Does no one remember EGP? ASNs are MUCH older than BGP. And we were
> > using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
> > when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
> > build saying that we could not expect BGPv4 code over a week old to
> > work. He felt that we should deploy new code daily.
> 
> 
> To be fair, that was for folks on the isp-geeks mailing list, who were
> effectively doing alpha test with me.  I was fixing about 1
> significant bug per day and doing at least one release per day.  10
> day old code was missing at least 10 fixes...  ;-) And that was BGP3.
> BGP4 was the next developer.
> 
> Regards,
> Tony
> 

Yes, Tony. It was absolutely fair. It was certainly not your (or
Cisco's) fault. It was a huge effort on the part of a small number of
Cisco engineers (I assume that you and Paul wrote most of the code) to
get a complex protocol stable and ready for implementation in far too
little time. It was utter insanity and it all worked! (Just in time for
the death of the PRDB).

In no way was I criticizing your efforts. I just remember that message
and thinking how much testing and planning we do today before rolling
new code onto production systems. The idea of reloading production
routers with code we absolutely knew would prove buggy on a weekly (or
more than weekly) basis seems so unimaginable today.

I'm looking forward to seeing Milo at NANOG 52 next month in Denver! I'm
sure that he remembers all of this.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From deepak at ai.net  Fri May 13 10:14:14 2011
From: deepak at ai.net (Deepak Jain)
Date: Fri, 13 May 2011 11:14:14 -0400
Subject: Network Equipment Discussion (HP and L2/10G)
Message-ID: <D338D1613B32624285BB321A5CF3DB25134C553950@ginga.ai.net>


Go figure, an actual thread about networking equipment on NANOG. :)

So reading Cisco's announcement, I go look at HP's higher end switching/routing line and I see some pretty beefy looking gear. A12500 and others. Does anyone have any experience with this thing -- is it white labeled from someone else?

Second question -- Does anyone know of a Cascade-style box (old days) for 10G aggregation? What I mean is I need about a number of ports of 10G (pluggable *colored* optics) with just normal L2 stuff (VLANs/dot1q) and I'd like to LACP/Port-channel that back to a pair of 10G ports on a router. The wrinkle here is that I can't use a normal enterprise 10G switch because of the need for DWDM optics (ideally 80km style). For this application, buffers and such are not an issue. Any suggestions?

Thanks in advance,

DJ


From joelja at bogus.com  Fri May 13 10:55:38 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 13 May 2011 08:55:38 -0700
Subject: Network Equipment Discussion (HP and L2/10G)
In-Reply-To: <D338D1613B32624285BB321A5CF3DB25134C553950@ginga.ai.net>
References: <D338D1613B32624285BB321A5CF3DB25134C553950@ginga.ai.net>
Message-ID: <4DCD547A.2020405@bogus.com>

On 5/13/11 8:14 AM, Deepak Jain wrote:
> 
> Go figure, an actual thread about networking equipment on NANOG. :)
> 
> So reading Cisco's announcement, I go look at HP's higher end
> switching/routing line and I see some pretty beefy looking gear.
> A12500 and others. Does anyone have any experience with this thing --
> is it white labeled from someone else?

3com aquisition/ Huawei joint venture

I took a look at the h3c s58xx sometime last year, I can report that
it's an ethernet siwtch.

> Second question -- Does anyone know of a Cascade-style box (old days)
> for 10G aggregation? What I mean is I need about a number of ports of
> 10G (pluggable *colored* optics) with just normal L2 stuff
> (VLANs/dot1q) and I'd like to LACP/Port-channel that back to a pair
> of 10G ports on a router. The wrinkle here is that I can't use a
> normal enterprise 10G switch because of the need for DWDM optics
> (ideally 80km style). For this application, buffers and such are not
> an issue. Any suggestions?
> 
> Thanks in advance,
> 
> DJ
> 




From bruns at 2mbit.com  Fri May 13 11:09:19 2011
From: bruns at 2mbit.com (Brielle Bruns)
Date: Fri, 13 May 2011 10:09:19 -0600
Subject: Need the perspective of a Level3 customer.
In-Reply-To: <BANLkTikNdH1YRX15tsvPP0oLyJ+usqUFBQ@mail.gmail.com>
References: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
	<BANLkTikNdH1YRX15tsvPP0oLyJ+usqUFBQ@mail.gmail.com>
Message-ID: <4DCD57AF.5060303@2mbit.com>

On 5/13/11 2:55 AM, Joe Renwick wrote:
> Thanks again to all who replied... looks like other Level3 customer are
> seeing the /24.  Looks like the issue is specific to San Diego.  Any routing
> information from other SD Level3 customer would be appreciated.




Through Level3 (AS3356) Seattle->SJ->LA->SD->nextlevelinternet (AS1658) 
I can see that announcement.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org



From eric.nowland at wyoming.com  Fri May 13 11:40:22 2011
From: eric.nowland at wyoming.com (Eric Nowland)
Date: Fri, 13 May 2011 10:40:22 -0600
Subject: Need the perspective of a Level3 customer.
In-Reply-To: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
References: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
Message-ID: <4DCD5EF6.40002@wyoming.com>

Here is what I am seeing from both of my Level 3 links, hope it helps:

show ip bgp 63.210.162.0
BGP routing table entry for 63.210.162.0/24, version 139413425
Paths: (2 available, best #1, table Default-IP-Routing-Table)
   Not advertised to any peer
   3356 16582
     4.53.6.25 from 4.53.6.25 (4.68.185.104)
       Origin IGP, metric 25753, localpref 100, valid, external, best
       Community: 3833:601
   3356 16582, (received-only)
     4.53.6.25 from 4.53.6.25 (4.68.185.104)
       Origin IGP, metric 25753, localpref 100, valid, external
       Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2002

show ip bgp 63.210.162.0
BGP routing table entry for 63.210.162.0/24, version 148858770
Paths: (2 available, best #1, table Default-IP-Routing-Table)
   Advertised to update-groups:
      1
   3356 16582
     4.53.6.29 from 4.53.6.29 (4.68.185.104)
       Origin IGP, metric 25753, localpref 100, valid, external, best
       Community: 3833:600
   3356 16582, (received-only)
     4.53.6.29 from 4.53.6.29 (4.68.185.104)
       Origin IGP, metric 25753, localpref 100, valid, external
       Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2002

Thanks
Eric Nowland
Engineering Manager
Wyoming.com

On 5/13/2011 2:39 AM, Joe Renwick wrote:
> Can anyone peering with Level3 directly tell me if they are seeing
> 63.210.162.0/24 coming from the Level3 peer?
>
> Thanks for the help.
>
> Cheers,
>



From mpetach at netflight.com  Fri May 13 11:42:08 2011
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 13 May 2011 09:42:08 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <5E4A5639-1AA3-4A77-9D92-BC4EB861FF34@muada.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
	<5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
	<BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>
	<5E4A5639-1AA3-4A77-9D92-BC4EB861FF34@muada.com>
Message-ID: <BANLkTimcYfE3z+A02nm7945BQy7==f5mjw@mail.gmail.com>

On Fri, May 13, 2011 at 12:56 AM, Iljitsch van Beijnum
<iljitsch at muada.com> wrote:
> On 13 mei 2011, at 2:39, Jimmy Hess wrote:
>
>> if the user starts obtaining
>> multiple non-aggregable /48s ?from different sources, ?or obtains an
>> additional PI allocation later, but
>> keeps using the original /48.
>
> Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place.
>
> The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.
>

Well, that one particular "someone" should at most be announcing 16
/48s (their deaggregated /44).

If they announce a million /48s, they're actively hijacking space from
64,000 other people,
and should be dealt with in an appropriate manner as a hijacker.  :/

People are conflating two different issues here.

RIR policy is not, and never has been, structured to
prevent or punish active, realtime hijacking of IP space.

The *only* thing that will prevent that, in real-time are
techniques like PGBGP or so-BGP.  Not RIR policies.

Now, RIR policies may provide guidelines on what policies
you may use to configure your BGBGP or soBGP rules;
but the enforcement and protection side is up to you
as an ISP, not up to the RIR.

I have always been, and will continue to be, adamantly
opposed to the idea of the RIRs taking on the role
of the "routing table" and "forwarding table" police.  :(

Matt
(as a side note--in order to have your "million /48s"
table explosion happen through *legitimate* holders
of space deaggregating, it would require 64K individual
choices to deaggregate in order to have that happen;
we don't even have that many ASNs out there yet.  I'm
not losing sleep over that at this point.)



From joly at punkcast.com  Fri May 13 11:52:12 2011
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 13 May 2011 12:52:12 -0400
Subject: IPv6 day in NYC?
Message-ID: <BANLkTim4gS8mOkHqmSL-uOnc8pdaKgpsYg@mail.gmail.com>

The Internet Society is organizing IPv6 Day for June 6 2011.
http://isoc.org/wp/worldipv6day/

There isn't currently a NYC event scheduled. If anyone's interested in
making a presentation or just getting together for a discussion ISOC-NY
would be happy to host at NYU.

Feel free to respond off list. joly at punkcast.com

j


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From mpetach at netflight.com  Fri May 13 11:58:40 2011
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 13 May 2011 09:58:40 -0700
Subject: IPv6 day in NYC?
In-Reply-To: <BANLkTim4gS8mOkHqmSL-uOnc8pdaKgpsYg@mail.gmail.com>
References: <BANLkTim4gS8mOkHqmSL-uOnc8pdaKgpsYg@mail.gmail.com>
Message-ID: <BANLkTimhcH=KaeTC-sJZduHN1aP6H9snAw@mail.gmail.com>

On Fri, May 13, 2011 at 9:52 AM, Joly MacFie <joly at punkcast.com> wrote:
> The Internet Society is organizing IPv6 Day for June 6 2011.
> http://isoc.org/wp/worldipv6day/

Uh...unless there's been a sudden change of plans,
I believe the date is still set for June *8th*, 2011.  ^_^;;

Matt



From joly at punkcast.com  Fri May 13 12:11:17 2011
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 13 May 2011 13:11:17 -0400
Subject: IPv6 day in NYC?
In-Reply-To: <BANLkTimhcH=KaeTC-sJZduHN1aP6H9snAw@mail.gmail.com>
References: <BANLkTim4gS8mOkHqmSL-uOnc8pdaKgpsYg@mail.gmail.com>
	<BANLkTimhcH=KaeTC-sJZduHN1aP6H9snAw@mail.gmail.com>
Message-ID: <BANLkTima8UFhGwfZ_Zcq9cRO_Mw0q66TiA@mail.gmail.com>

Oops. Jun 8th 2011.

I had D-Day on the brain.

j

On Fri, May 13, 2011 at 12:58 PM, Matthew Petach <mpetach at netflight.com>wrote:

> On Fri, May 13, 2011 at 9:52 AM, Joly MacFie <joly at punkcast.com> wrote:
> > The Internet Society is organizing IPv6 Day for June 6 2011.
> > http://isoc.org/wp/worldipv6day/
>
> Uh...unless there's been a sudden change of plans,
> I believe the date is still set for June *8th*, 2011.  ^_^;;
>
> Matt
>



-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From iljitsch at muada.com  Fri May 13 12:12:43 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Fri, 13 May 2011 19:12:43 +0200
Subject: IPv6 foot-dragging
In-Reply-To: <BANLkTimcYfE3z+A02nm7945BQy7==f5mjw@mail.gmail.com>
References: <4DCA9FAF.70409@l-w.ca>
	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>
	<4DCB5091.4050904@kenweb.org>
	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>
	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>
	<iqgcmq$t9o$1@dough.gmane.org>
	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>
	<4DCBDE59.2000001@unfix.org>
	<alpine.DEB.2.00.1105121529530.20305@uplift.swm.pp.se>
	<5A6D953473350C4B9995546AFE9939EE0C9E320F@RWC-EX1.corp.seven.com>
	<BANLkTi=JqFKjoY=P4MmhREBSt6nn8ry7Ng@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3242@RWC-EX1.corp.seven.com>
	<BANLkTi=xwPaCeKvUDWUpCXiJwYO=YFZiqw@mail.gmail.com>
	<5E4A5639-1AA3-4A77-9D92-BC4EB861FF34@muada.com>
	<BANLkTimcYfE3z+A02nm7945BQy7==f5mjw@mail.gmail.com>
Message-ID: <4D83D067-1A53-414B-90F3-9F5102438934@muada.com>

On 13 mei 2011, at 18:42, Matthew Petach wrote:

>> The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.

> If they announce a million /48s, they're actively hijacking space from
> 64,000 other people,
> and should be dealt with in an appropriate manner as a hijacker.  :/

It would be mostly unused space. But that doesn't matter much, the point is that your prefix length filters can't stop this.

If, on the other hand, the RIRs only give out /48s from one limited set of address space swaths and /44s from another, /32s from yet another and so on, then if there are 64k /48s that comes from say two /32s and three /33s for a total deaggregation risk of 224k prefixes. This is something your router may be able to handle.

> The *only* thing that will prevent that, in real-time are
> techniques like PGBGP or so-BGP.  Not RIR policies.

See above.

All this BGP security stuff is still vaporware as of today. Hopefully that will change in the future but I'm not holding my breath for the benefits to kick in.

> (as a side note--in order to have your "million /48s"
> table explosion happen through *legitimate* holders
> of space deaggregating, it would require 64K individual
> choices to deaggregate in order to have that happen;
> we don't even have that many ASNs out there yet.  I'm
> not losing sleep over that at this point.)

If you boil it slowly enough the frog will sleep just fine.

I participated in the IETF multi6/shim6 and IRTF RRG efforts for years but I have since come to the conclusion that routing table growth is not a real problem, because if it were people would be more willing to accept the downsides that come with the proposed solutions.




From jmamodio at gmail.com  Fri May 13 12:14:06 2011
From: jmamodio at gmail.com (Jorge Amodio)
Date: Fri, 13 May 2011 12:14:06 -0500
Subject: dot xxx live or not?
In-Reply-To: <BANLkTi=tgXWrYm-RZJ-NrXzApz7+37Od3Q@mail.gmail.com>
References: <BANLkTi=tgXWrYm-RZJ-NrXzApz7+37Od3Q@mail.gmail.com>
Message-ID: <BANLkTi=NhxAmAdC=oT04Z+sUsHVjnrTGow@mail.gmail.com>

TLD is delegated and alive.

pete at tango:~$ dig -t ns xxx

; <<>> DiG 9.7.0-P1 <<>> -t ns xxx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47132
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;xxx.                           IN      NS

;; ANSWER SECTION:
xxx.                    300     IN      NS      a0.xxx.afilias-nst.info.
xxx.                    300     IN      NS      c0.xxx.afilias-nst.info.
xxx.                    300     IN      NS      a2.xxx.afilias-nst.info.
xxx.                    300     IN      NS      b0.xxx.afilias-nst.org.
xxx.                    300     IN      NS      b2.xxx.afilias-nst.org.
xxx.                    300     IN      NS      d0.xxx.afilias-nst.org.

;; Query time: 100 msec
;; SERVER: 10.0.2.24#53(10.0.2.24)
;; WHEN: Fri May 13 12:10:59 2011
;; MSG SIZE  rcvd: 162

Anyway, I'd recommend them to read RFC2182 ...

-J



From alh-ietf at tndh.net  Fri May 13 12:56:11 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Fri, 13 May 2011 10:56:11 -0700
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: <1305265953.18376.1032.camel@karl>
References: <1305265953.18376.1032.camel@karl>
Message-ID: <03a401cc1197$0ceec410$26cc4c30$@net>

Fundamentally tunneling allows you to introduce the new technology while you work through budgeting / amortization-of-legacy / resistance-to-change issues. The Internet as we know it was built as a tunnel overlay to the voice system, and the underlying operators of that time said the overlay couldn't work or was sub-optimal, just like we hear today as a new generation of overlay is deployed.

There is a serious stalemate between the transit/access system which won't/can't invest in something new without a rapid ROI as demonstrated by a wildly popular application, and the application/content world that won't/can't invest in new applications without a delivery mechanism in place. Tunnels help break that stalemate. 

That said, at scale configuring and debugging an array of tunnels is an operational pain which will quickly outstrip the cost for just deploying the new technology natively. In the tunnel-over-voice model, hubs were set up and the end user was expected to configure their end of the tunnel to find the closest hub. Works well enough, and tunnel brokers are doing the same for IPv6 over IPv4 today. The issue is that we left the dial model behind and people just expect their magic CPE thing to take care of it automatically to stay connected at all times. Enter the automated tunnels...

People on this list will complain all day about how bad an idea automated tunnels are, but at the end of the day the point of automated tunnels is to get technology deployed to places where those who are complaining have not done so yet, and then doing that at scale without changing end user expectations of magic in the CPE. To put it a different way, the IPv4 operators have become the lethargic core that they complained about so vehemently 15 years ago, so now the $50 CPE has to find a way past them to stay always-connected no matter what rate their ISP rolls the IPv4 DHCP pool, or how many layers of nat get put in the way. 

For the specific complaint about MSFT putting tunneling in the host, you can complain to me because I drove that model (I have not worked there for over 10 years, but I was the PM for IPv6 in XP). The entire point was to break the stalemate and get apps deployed. People on this list generally are network operators and frequently get myopic about what problems need to be solved. For the specific problem of app development, there has to be a trust that it is worthwhile starting the development, so the API has to work no matter what impediments there are in the network. Given that you have to have an app deployed to demonstrate the need for the network operators to make the investment to improve its performance, making the API work means the host has to originate the tunnel, at least initially. That said, the original XP implementation deferred to any native service and that is the way all implementations of automated tunneling should work (I make the point because the rewrite of the stack for Vista/W7 broke this deferral for the isatap tunnel type, and as of the last time I checked it has not been fixed yet). Making the API work also means that multiple approaches to tunneling are required to deal with the various network topologies that the end system will find itself in. From the app developer perspective, none of that should matter as the OS stack should take care of masking whatever contortions it has to do for bit delivery. That almost works except for RTT and MTU issues which cause performance degradation relative to the underlying legacy protocol.

I can already hear the responses about how people are demonstrating the failure modes of automated tunnels. My response is that those who protest are taking the religious position of 'my content is available via the RIR allocated address and you will come to me', which forces traffic through a 3rd party transit intermediary when they could just as easily add an address for direct support of the automated tunneling world and all of the 3rd party issues they complain about as failures would vaporize. There would still be firewall induced failures, but the entire point of firewalls is to cause a failure for services the firewall operator is not prepared to deal with. There is a simple enough work around for that by daisy chaining automated tunnel technologies with an intermediate firewall, so it doesn't have to be the crisis it is being made out to be.

While IPv4 creates a nice global NBMA network (to pass what from an IPv6 perspective are logically layer-2 frames around), tunnels create a challenge for diagnostics because there may be a divergence between the tunnel and the underlying path. This is amplified when the underlying path it asymmetric, and even further when 3rd parties are introduced in one or both directions. This issue also exposes the disparity between what the applications are trying to do vs. what the native network is capable of. When your job is the underlying network, exposing this difference is going to cause grief, and in turn complaints about the thing that is shining light on the situation.

As to specific technologies:
Tunnel brokers
The modern equivalent of modem-pools. Requires explicit action by the end user, and some degree of technical skill to get configured correctly (more so than a dial modem which used the widely understood paradigm of placing a phone call). Also requires some degree of adaptability by the hub operator to deal with dynamics in the underlying network addressing over time. Primary application issue is reduced MTU.

isatap
designed as an intra-enterprise tool for hosts to reach across an infrastructure that is still being amortized. Use of an IPv4 DNS A record allows network managers to explicitly distribute clients across a set of tunnel termination routers, while the alternative use of an IPv4 anycast allows clients to reach the topologically nearest router. Can be used in conjunction with native external access, or 6to4/6rd by reencapsulating the packet. The triplet of a 6to4/6rd router, native IPv6 firewall, and isatap router allows IPv6 application support between the enterprise end system and the public Internet with the same firewall policies as IPv4, and without the need for deep packet inspection to parse the tunnel packets. 


6to4
designed as a border router to tunnel to other 6to4 routers over public infrastructure that was not ready for native support. Relays to transit between the 6to4 addressed environment and the native environment were an add-on that merged the two. The IPv4 anycast address to further simplify deployment was another add-on which reduces configuration on the client side router. The problematic issue of 6to4 is the misguided one-liner in RFC 3056 5.2 bullet 3 that restricts advertisements into the IPv6 BGP mesh to be the entire 2002::/16. This leads to unwanted traffic patterns, so the relays are not deployed as widely as they could/should be to mitigate latency and asymmetry issues. If the cpe is capable of dealing with the encapsulation, end hosts are unable to distinguish this prefix from any native service that might have been offered to the cpe. When no adjacent router is offering native IPv6 service, an end system with a public IPv4 address might attempt to use this technology, and if encapsulated packets are blocked by a firewall it will fail, but without the firewall the applications will see what appears to be an IPv6 network. 

6rd
designed as a derivative of 6to4 to explicitly remove the /16 restriction in IPv6 BGP advertisements because changing that one line would have taken longer to get agreement on than an entirely new design, implementation, and deployment sequence (note that this will result in just as many IPv6 prefix announcements into BGP as fragmenting 2002:: would have, so the arguments about modifying 3056 are moot). Requires that each provider have a large enough allocation to embed the uniquely identifying parts of their IPv4 space into each 6rd address block, which is a challenge with existing IPv6 allocation policies. It does align the tunnel endpoints with the access infrastructure that is being overlaid, at least at the organizational level. Does require CPE capable of sorting out which set of IPv4 address bits should be concatenated with the IPv6 pop prefix to create the ultimate IPv6 prefix for that CPE. 


teredo/mirado
designed to deal with the reality that most end systems find themselves behind a nat and without an adjacent router offering IPv6 so the above approaches won't work. Has additional overhead compared with the above, further reducing the MTU, and requiring a lengthy call-setup sequence. Works well enough for bulk bit delivery when responsiveness expectations are low and nat traversal is the primary goal.


Tony



> -----Original Message-----
> From: Karl Auer [mailto:kauer at biplane.com.au]
> Sent: Thursday, May 12, 2011 10:53 PM
> To: NANOG List
> Subject: Interested in input on tunnels as an IPv6 transition
> technology
> 
> Hullo all.
> 
> I'm working on a talk, and would be interested to know what people
> think is good about tunnels as an IPv6 transition technology, and what
> people think is bad about tunnels.
> 
> It would probably be best to let me know off-list :-) but I'm happy to
> summarise back to the list. Any references you have to useful papers,
> articles, discussions etc would also be appreciated.
> 
> I'm looking for both general problems and advantages, but also
> advantages and disadvantages specific to particular tunnel types. It
> would also be helpful to know from what perspective particular things
> are good or bad, in so far as it isn't obvious. A carrier has a
> different perspective than, say, a home user, who will have a different
> perspective again to an enterprise user.
> 
> Many thanks in advance for your input.
> 
> Regards, K.
> 
> PS: Note the all-important words "as an IPv6 transition technology"...
> 
> 
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)
> 
> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old
> fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156




From cb.list6 at gmail.com  Fri May 13 13:03:17 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Fri, 13 May 2011 11:03:17 -0700
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: <1305265953.18376.1032.camel@karl>
References: <1305265953.18376.1032.camel@karl>
Message-ID: <BANLkTi=AcNdWXkj0JSOy9vjqe9TH4rJm_w@mail.gmail.com>

On Thu, May 12, 2011 at 10:52 PM, Karl Auer <kauer at biplane.com.au> wrote:
> Hullo all.
>
> I'm working on a talk, and would be interested to know what people think
> is good about tunnels as an IPv6 transition technology, and what people
> think is bad about tunnels.
>
> It would probably be best to let me know off-list :-) but I'm happy to
> summarise back to the list. Any references you have to useful papers,
> articles, discussions etc would also be appreciated.
>
> I'm looking for both general problems and advantages, but also
> advantages and disadvantages specific to particular tunnel types. It
> would also be helpful to know from what perspective particular things
> are good or bad, in so far as it isn't obvious. A carrier has a
> different perspective than, say, a home user, who will have a different
> perspective again to an enterprise user.
>
> Many thanks in advance for your input.

http://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad

http://labs.ripe.net/Members/gih/testing-teredo



From cscora at apnic.net  Fri May 13 13:59:41 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 14 May 2011 04:59:41 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201105131859.p4DIxfvN012575@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfs at cisco.com>.

Routing Table Report   04:00 +10GMT Sat 14 May, 2011

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              356656
    Prefixes after maximum aggregation:                          161598
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     176105
Total ASes present in the Internet Routing Table:                 37552
    Prefixes per ASN:                                              9.50
Origin-only ASes present in the Internet Routing Table:           31389
Origin ASes announcing only one prefix:                           15082
Transit ASes present in the Internet Routing Table:                5092
Transit-only ASes present in the Internet Routing Table:            136
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               626
    Unregistered ASNs in the Routing Table:                         320
Number of 32-bit ASNs allocated by the RIRs:                       1348
Number of 32-bit ASNs visible in the Routing Table:                1071
Prefixes from 32-bit ASNs in the Routing Table:                    2417
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            156
Number of addresses announced to Internet:                   2425507776
    Equivalent to 144 /8s, 146 /16s and 79 /24s
    Percentage of available address space announced:               65.4
    Percentage of allocated address space announced:               65.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               90.7
Total number of prefixes smaller than registry allocations:      148116

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    89380
    Total APNIC prefixes after maximum aggregation:               29933
    APNIC Deaggregation factor:                                    2.99
Prefixes being announced from the APNIC address blocks:           85747
    Unique aggregates announced from the APNIC address blocks:    36599
APNIC Region origin ASes present in the Internet Routing Table:    4441
    APNIC Prefixes per ASN:                                       19.31
APNIC Region origin ASes announcing only one prefix:               1232
APNIC Region transit ASes present in the Internet Routing Table:    705
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:     47
Number of APNIC addresses announced to Internet:              614205216
    Equivalent to 36 /8s, 156 /16s and 7 /24s
    Percentage of available APNIC address space announced:         77.9

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
                       55296-56319, 131072-132095
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    140013
    Total ARIN prefixes after maximum aggregation:                71448
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           112260
    Unique aggregates announced from the ARIN address blocks:     45485
ARIN Region origin ASes present in the Internet Routing Table:    14368
    ARIN Prefixes per ASN:                                         7.81
ARIN Region origin ASes announcing only one prefix:                5485
ARIN Region transit ASes present in the Internet Routing Table:    1497
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               800054528
    Equivalent to 47 /8s, 175 /16s and 221 /24s
    Percentage of available ARIN address space announced:          63.6

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     84162
    Total RIPE prefixes after maximum aggregation:                48126
    RIPE Deaggregation factor:                                     1.75
Prefixes being announced from the RIPE address blocks:            77641
    Unique aggregates announced from the RIPE address blocks:     51249
RIPE Region origin ASes present in the Internet Routing Table:    15589
    RIPE Prefixes per ASN:                                         4.98
RIPE Region origin ASes announcing only one prefix:                7801
RIPE Region transit ASes present in the Internet Routing Table:    2460
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          36
Number of RIPE region 32-bit ASNs visible in the Routing Table:     790
Number of RIPE addresses announced to Internet:               468684800
    Equivalent to 27 /8s, 239 /16s and 144 /24s
    Percentage of available RIPE address space announced:          75.5

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   32698
    Total LACNIC prefixes after maximum aggregation:               7496
    LACNIC Deaggregation factor:                                   4.36
Prefixes being announced from the LACNIC address blocks:          31756
    Unique aggregates announced from the LACNIC address blocks:   16683
LACNIC Region origin ASes present in the Internet Routing Table:   1449
    LACNIC Prefixes per ASN:                                      21.92
LACNIC Region origin ASes announcing only one prefix:               427
LACNIC Region transit ASes present in the Internet Routing Table:   268
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   217
Number of LACNIC addresses announced to Internet:              83360256
    Equivalent to 4 /8s, 247 /16s and 250 /24s
    Percentage of available LACNIC address space announced:        55.2

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   7770
    Total AfriNIC prefixes after maximum aggregation:              1867
    AfriNIC Deaggregation factor:                                  4.16
Prefixes being announced from the AfriNIC address blocks:          6122
    Unique aggregates announced from the AfriNIC address blocks:   1939
AfriNIC Region origin ASes present in the Internet Routing Table:   447
    AfriNIC Prefixes per ASN:                                     13.70
AfriNIC Region origin ASes announcing only one prefix:              137
AfriNIC Region transit ASes present in the Internet Routing Table:   97
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             23095040
    Equivalent to 1 /8s, 96 /16s and 103 /24s
    Percentage of available AfriNIC address space announced:       34.4

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2452       9493         916   Korea Telecom (KIX)
17974     1834        516          32   PT TELEKOMUNIKASI INDONESIA
 7545     1549        301          87   TPG Internet Pty Ltd
 4755     1461        634         167   TATA Communications formerly 
24560     1151        336         184   Bharti Airtel Ltd., Telemedia
 7552     1105       1064           7   Vietel Corporation
 9583     1079         80         510   Sify Limited
 4808     1063       2130         297   CNCGROUP IP network: China169
 9829     1039        874          51   BSNL National Internet Backbo
17488      935        165         103   Hathway IP Over Cable Interne

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3647       3822         255   bellsouth.net, inc. 
 4323     1979       1081         396   Time Warner Telecom
18566     1822        357         232   Covad Communications 
 1785     1775        681         124   PaeTec Communications, Inc.
 6478     1678        314          50   AT&T Worldnet Services 
20115     1535       1539         631   Charter Communications 
19262     1499       4949         299   Verizon Global Networks 
 7018     1357       6911         886   AT&T WorldNet Services
22773     1329       2897          87   Cox Communications, Inc.
11492     1279        240          15   Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6830      519       1780         321   UPC Distribution Services
34984      512        106         182   BILISIM TELEKOM
 3292      459       1998         392   TDC Tele Danmark
20940      447        131         342   Akamai Technologies European 
 8866      442        134          26   Bulgarian Telecommunication C
29049      442         32          44   AzerSat LLC.
12479      430        577           6   Uni2 Autonomous System
 3320      420       7608         367   Deutsche Telekom AG
 8551      406        355          45   Bezeq International
  702      397       1802         310   UUNET - Commercial IP service

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1476        272         154   TVCABLE BOGOTA 
 8151     1370       2702         362   UniNet S.A. de C.V. 
28573     1315        990          86   NET Servicos de Comunicao S.A
 7303      931        470         152   Telecom Argentina Stet-France
 6503      732        354          73   AVANTEL, S.A. 
14420      667         54          91   CORPORACION NACIONAL DE TELEC
22047      555        310          15   VTR PUNTO NET S.A. 
 3816      521        227         100   Empresa Nacional de Telecomun
13489      499        241         121   Orbitel S.A. E.S.P. 
11172      493         84          83   Servicios Alestra S.A de C.V 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452      888        445          11   TEDATA
24863      782        147          37   LINKdotNET AS number
15475      415         90           8   Nile Online
36992      288        331          17   Etisalat MISR
 3741      268        985         228   The Internet Solution 
 6713      241        215          13   Itissalat Al-MAGHRIB
24835      206         78          10   RAYA Telecom - Egypt
33776      200         12          11   Starcomms Nigeria Limited
29571      162         17          11   Ci Telecom Autonomous system 
16637      150        441          86   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3647       3822         255   bellsouth.net, inc. 
 4766     2452       9493         916   Korea Telecom (KIX)
23456     2417        685        1317   32-bit ASN transition
 4323     1979       1081         396   Time Warner Telecom
17974     1834        516          32   PT TELEKOMUNIKASI INDONESIA
18566     1822        357         232   Covad Communications 
 1785     1775        681         124   PaeTec Communications, Inc.
 6478     1678        314          50   AT&T Worldnet Services 
 7545     1549        301          87   TPG Internet Pty Ltd
20115     1535       1539         631   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
17974      1834        1802      PT TELEKOMUNIKASI INDONESIA
 1785      1775        1651      PaeTec Communications, Inc.
 6478      1678        1628      AT&T Worldnet Services 
18566      1822        1590      Covad Communications 
 4323      1979        1583      Time Warner Telecom
 4766      2452        1536      Korea Telecom (KIX)
 7545      1549        1462      TPG Internet Pty Ltd
10620      1476        1322      TVCABLE BOGOTA 
 4755      1461        1294      TATA Communications formerly 
11492      1279        1264      Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
31.134.128.0/18      42668     RIPE Network Coordination Cen
31.220.160.0/19      29072     RDTC Autonomous System ISP at
31.222.96.0/22       29119     ServiHosting Autonomous Syste
31.222.100.0/22      29119     ServiHosting Autonomous Syste

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:20       /9:12      /10:28      /11:78      /12:223     
/13:459     /14:790     /15:1390    /16:11723   /17:5766    /18:9707    
/19:19307   /20:25552   /21:25796   /22:34071   /23:32878   /24:185607  
/25:1092    /26:1271    /27:709     /28:161     /29:8       /30:2       
/31:0       /32:6       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2247          3647      bellsouth.net, inc. 
18566     1784          1822      Covad Communications 
 6478     1632          1678      AT&T Worldnet Services 
10620     1366          1476      TVCABLE BOGOTA 
11492     1225          1279      Cable One 
23456     1188          2417      32-bit ASN transition
 7011     1062          1162      Citizens Utilities 
 1785     1050          1775      PaeTec Communications, Inc.
 4323      888          1979      Time Warner Telecom
22773      846          1329      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:267       2:44        4:14        5:1         6:3         8:352    
  12:1985     13:1        14:456      15:15       16:3        17:8      
  20:10       23:7        24:1639     27:743      31:328      32:60     
  33:4        34:2        37:1        38:731      40:101      41:2501   
  42:5        44:3        46:903      47:4        49:177      50:401    
  52:13       55:6        56:2        57:30       58:848      59:485    
  60:387      61:1254     62:974      63:1925     64:3928     65:2299   
  66:4140     67:1866     68:1093     69:2986     70:706      71:350    
  72:1884     73:1        74:2345     75:306      76:342      77:865    
  78:689      79:463      80:1096     81:817      82:493      83:449    
  84:625      85:1071     86:598      87:746      88:325      89:1566   
  90:202      91:3732     92:512      93:1054     94:1251     95:803    
  96:483      97:246      98:828      99:35      101:59      103:12     
 106:1       107:6       108:85      109:944     110:585     111:711    
 112:319     113:399     114:532     115:666     116:954     117:683    
 118:818     119:1135    120:309     121:678     122:1621    123:1079   
 124:1257    125:1223    128:259     129:166     130:165     131:568    
 132:110     133:19      134:218     135:49      136:214     137:143    
 138:304     139:106     140:480     141:240     142:401     143:402    
 144:487     145:53      146:440     147:210     148:591     149:243    
 150:171     151:187     152:310     153:179     154:3       155:395    
 156:194     157:352     158:131     159:387     160:315     161:207    
 162:279     163:163     164:499     165:352     166:514     167:431    
 168:725     169:153     170:794     171:77      172:1       173:1557   
 174:543     175:370     177:120     178:908     180:840     181:16     
 182:439     183:205     184:262     185:1       186:1169    187:749    
 188:829     189:907     190:4793    192:5783    193:4843    194:3477   
 195:2973    196:1209    197:17      198:3570    199:3893    200:5535   
 201:1494    202:8359    203:8467    204:4111    205:2328    206:2725   
 207:2913    208:3966    209:3423    210:2731    211:1386    212:1973   
 213:1717    214:730     215:69      216:4818    217:1630    218:565    
 219:370     220:1203    221:483     222:342     223:145    

End of report



From jeroen at mompl.net  Fri May 13 14:03:35 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Fri, 13 May 2011 12:03:35 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
Message-ID: <4DCD8087.9020402@mompl.net>

Thanks all for the helpful suggestions.

It looks like I solved the problem by adjusting my forward chain. I have 
a the local network on eth0 and the external network on eth1 and my 
forward chain looked like:

-I FORWARD -i eth0 -o eth1 -s 2001:db8::/64 -j ACCEPT
-I FORWARD -i eth1 -o eth0 -d 2001:db8::/64 -j ACCEPT

Changing it to the following made it work:

-I FORWARD -s 2001:470:85cd::/64 -j ACCEPT
-I FORWARD -d 2001:470:85cd::/64 -j ACCEPT


I am not sure if it'd be less secure to not make it specific to the 
interfaces. How would I change the first set of rules, using the -i 
parameter and still make it work? I also have a 6in4 interface for the 
IPv6 tunnel.

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From jeroen at mompl.net  Fri May 13 14:16:37 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Fri, 13 May 2011 12:16:37 -0700
Subject: IPv6 foot-dragging
In-Reply-To: <OF81F394AD.9E5D67EB-ON8525788E.004A7BFE-8525788E.004B364C@csc.com>
References: <4DCA9FAF.70409@l-w.ca>	<1474311354-1305126222-cardhu_decombobulator_blackberry.rim.net-747476740-@bda346.bisx.prod.on.blackberry>	<4DCB5091.4050904@kenweb.org>	<BB5E551F-EDC4-420D-805A-C44DC3F085E7@delong.com>	<0B3B139B67263843A5D72FD2BF3EBA695AE678@OfficeExch2k7A.exchange.handynetworks.com>	<iqgcmq$t9o$1@dough.gmane.org>	<OF080DF5DA.086DB265-ON8525788E.0048780D-8525788E.0048BAA7@csc.com>	<4DCBDE59.2000001@unfix.org>
	<OF81F394AD.9E5D67EB-ON8525788E.004A7BFE-8525788E.004B364C@csc.com>
Message-ID: <4DCD8395.6030100@mompl.net>

Joe Loiacono wrote:
> Jeroen Massar <jeroen at unfix.org> wrote on 05/12/2011 09:19:21 AM:
> 
>> On 2011-May-12 15:14, Joe Loiacono wrote:
>>> Anyone know roughly the current default-free routing table size for 
> IPv6?
>> http://www.sixxs.net/tools/grh/status/
> 
> Awesome web-site. The world of IPv6 routing on one page.

That is a great overview.

And really, if a conservative institution such as the *catholic church* 
jumped on the IPv6 bandwagon there is really NO excuse for other 
companies to drag their heels, for crying out loud. ;-)

http://www.sixxs.net/tools/whois/?AS8978

Greetings,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From tshaw at oitc.com  Fri May 13 14:32:22 2011
From: tshaw at oitc.com (TR Shaw)
Date: Fri, 13 May 2011 15:32:22 -0400
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: <BANLkTi=AcNdWXkj0JSOy9vjqe9TH4rJm_w@mail.gmail.com>
References: <1305265953.18376.1032.camel@karl>
	<BANLkTi=AcNdWXkj0JSOy9vjqe9TH4rJm_w@mail.gmail.com>
Message-ID: <8CACF4C8-5AB9-42FB-935D-48854CAFD6BC@oitc.com>


> On Thu, May 12, 2011 at 10:52 PM, Karl Auer <kauer at biplane.com.au> wrote:
>> Hullo all.
>> 
>> I'm working on a talk, and would be interested to know what people think
>> is good about tunnels as an IPv6 transition technology, and what people
>> think is bad about tunnels.
>> 
>> It would probably be best to let me know off-list :-) but I'm happy to
>> summarise back to the list. Any references you have to useful papers,
>> articles, discussions etc would also be appreciated.
>> 
>> I'm looking for both general problems and advantages, but also
>> advantages and disadvantages specific to particular tunnel types. It
>> would also be helpful to know from what perspective particular things
>> are good or bad, in so far as it isn't obvious. A carrier has a
>> different perspective than, say, a home user, who will have a different
>> perspective again to an enterprise user.
>> 
>> Many thanks in advance for your input.

All I can say is that if it wasn't for HE tunnels I would be SOL. No provider here in east central Florida can even speak IPv6.  Brighthouse is clueless. ATT told me maybe 2012 or 2013!  So I tunnel to HE's POP in Miami.  With this I can test and become dual stack operational. Yes, it is not as good as a native connection but in my position its the only game in town.

Tom




From jeroen at mompl.net  Fri May 13 15:15:08 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Fri, 13 May 2011 13:15:08 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <4DCD8087.9020402@mompl.net>
References: <4DCD8087.9020402@mompl.net>
Message-ID: <4DCD914C.1040400@mompl.net>

Jeroen van Aart wrote:
> Thanks all for the helpful suggestions.

Obviously I need to do a better job using documentation IPv6 
consistently, so ignore any inconsistencies in that regard.

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From packetgrrl at gmail.com  Fri May 13 15:18:16 2011
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Fri, 13 May 2011 14:18:16 -0600
Subject: coprorations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <4dccaf53.1074650a.52c2.5994@mx.google.com>
References: <4dccaf53.1074650a.52c2.5994@mx.google.com>
Message-ID: <BANLkTimU4ZEN3R7kUyQo5f_WxsbVJvL-kg@mail.gmail.com>

The Smarties in this part of the world don't come in boxes.  :-)

----CJ

On Thu, May 12, 2011 at 10:10 PM, <bobbyjim at gmail.com> wrote:

> And if you had a great question or response, would you get a box of
> Smarties?
>
> Robert
>
>
> -- Sent from my Palm Pre
>
> ------------------------------
> On May 12, 2011 10:54 PM, cja at daydream.com <packetgrrl at gmail.com> wrote:
>
> Yes images had names in them and in 1989 you could call cisco if your box
> was broken and Eileen would just send parts.
>
> ----Cathy
>
> On Thu, May 12, 2011 at 9:44 PM, Adrian Chadd <adrian at creative.net.au>wrote:
>
>
> > On Fri, May 13, 2011, Hank Nussbacher wrote:
> >
> > > I always liked seeing the string "tli" in the IOS bundle in those days.
>
> >
> > Whoa, you mean Cisco IOS images have "built by" names other than "prod
> rel
> > team" ?
> >
> > (heh.)
> >
> >
> >
> > Adrian
> >
> >
> >
>


From bmanning at vacation.karoshi.com  Fri May 13 16:22:06 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 13 May 2011 21:22:06 +0000
Subject: Routing study
In-Reply-To: <E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
	<E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
Message-ID: <20110513212206.GC8201@vacation.karoshi.com.>


their use agreement ended in 2008.  telling the nanog world they are going to reuse it
three years later is not exactly what most would consider prior notice to the registered
holder that they would like to do a research project wiht resources that are not registered
to them.

/bill


On Thu, May 12, 2011 at 12:02:55PM -0400, Greg Whynott wrote:
> On May 12, 2011, at 6:30 AM, <bmanning at vacation.karoshi.com> <bmanning at vacation.karoshi.com> wrote:
> 
> > erb&
> > d I would appreciate it if they
> > would at least notify me ahead of time if they want to futz around
> > with prefixes that are not registered to them.
> 
> 
> erb&.   isn't that exactly what they just did,  notified you ahead of time?  the test starts on the 18th.
> 
> helps to read before you jump!
> 
> -g
> 
> 
> --
> 
> This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.



From jeroen at mompl.net  Fri May 13 16:32:48 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Fri, 13 May 2011 14:32:48 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <4DCD8087.9020402@mompl.net>
References: <4DCD8087.9020402@mompl.net>
Message-ID: <4DCDA380.7020407@mompl.net>

Jeroen van Aart wrote:
> -I FORWARD -i eth0 -s 2001:db8::/64 -j ACCEPT
> -I FORWARD -i eth1 -d 2001:db8::/64 -j ACCEPT

Just in case if anyone'd be using it as an example. It's a good idea to 
make your rules more restrictive.

Something like:
-I FORWARD -j DROP
-I FORWARD -s 2001:db8::/64 -j ACCEPT
-I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT


-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From jyy_99 at yahoo.com  Fri May 13 16:37:21 2011
From: jyy_99 at yahoo.com (Jessica Yu)
Date: Fri, 13 May 2011 14:37:21 -0700 (PDT)
Subject: coprorations using BGP for advertising prefixes in mid-1990s 
In-Reply-To: <20110512213707.2FF721CC2C@ptavv.es.net>
References: Your message of "Thu, 12 May 2011 17:15:17 EDT."
	<BANLkTi=qL8ZExXEOE23iUSu2aDVBUrZ8Hw@mail.gmail.com>
	<20110512213707.2FF721CC2C@ptavv.es.net>
Message-ID: <869390.55993.qm@web121814.mail.ne1.yahoo.com>

>Does no one remember EGP?

Yes, I remember EGP every well.? When we built the NSFNET T1 backbone in 1987, EGP was the only available routing protocol for exterior routing.? We deployed it and used EGP to exchange routing information with the connected regional networks.? Initially, it worked fine but then when the routing table and traffic grew, we observed that every 3 minutes, the network performance got a hit.? After some investigation, we discovered that it was due to the fact that EGP did routing updates every 3 minutes by flooding the whole routing table to the peer and the process overwhelmed router processor. At that time, the processor on the router did both routing and forwarding.? 

Fortunately, Yakov of IBM, Kirk from Cisco and we Merit were working on the development and testing of BGP, which was intended to replace EGP.? BGP does incremental routing updates i.e. it sends its peer the delta whenever routing topology changes rather than flooding its peer with the whole routing table every 3 minutes.? It saved a lot of processing power.? In addition, it reduces routing convergence time since BGP sends its neighbors the updates whenever changes occurs. In the case of EGP, it may take as long as close to 3 minutes after a route change before the routing table got updated.? In addition, BGP has loop detection capability due to its inclusion of AS path information.? These were the technical reasons to replace EGP with BGP at the time.

We worked with regional network reps and started to convert NSFNET to regional peers from EGP to BGP in early 1990s. I also created the BGP Deployment Work Group at IETF to push the deployment of BGP in the whole Internet.


cheers!

--Jessica



________________________________
From: Kevin Oberman <oberman at es.net>
To: Dorn Hetzel <dorn at hetzel.org>
Cc: nanog at nanog.org
Sent: Thursday, May 12, 2011 2:37 PM
Subject: Re: coprorations using BGP for advertising prefixes in mid-1990s 

> Date: Thu, 12 May 2011 17:15:17 -0400
> From: Dorn Hetzel <dorn at hetzel.org>
> 
> >
> >
> > The actual number would be considerably smaller as there were large
> > (for some definition of large) block assignments of ASNs <~1000 or so
> > to various academic networking entities such as NSFNet and regional
> > networks as well as other Federal/Military networking organisations.
> >
> > -dorian
> >
> >
> Well, for one data point, I was issued 3492 around Spring of 1994.
> 

Does no one remember EGP? ASNs are MUCH older than BGP. And we were
using BGPv3 prior to the existence of V4. We used BGPv4 back in the days
when Tony Li would chastise us for reporting a bug in a 10 day old Cisco
build saying that we could not expect BGPv4 code over a week old to
work. He felt that we should deploy new code daily.

The big push was to have v4 available before the old PRDB was frozen by
Merit/NSFnet. (And, who remembers the PRDB?)
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net??? ??? ??? Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4? EADA 927D EBB3 987B 3751

From bmanning at vacation.karoshi.com  Fri May 13 16:39:16 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 13 May 2011 21:39:16 +0000
Subject: Routing study
In-Reply-To: <BANLkTimPFONG85pLmC5E5pUs3yoyaXFWUw@mail.gmail.com>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
	<E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
	<A4890B44-B985-4718-B027-10BE58A5AAB5@lassitu.de>
	<9EC09253-2D3F-43F0-866C-1BDADD6A701C@oicr.on.ca>
	<BANLkTimPFONG85pLmC5E5pUs3yoyaXFWUw@mail.gmail.com>
Message-ID: <20110513213916.GD8201@vacation.karoshi.com.>

 the loan was for a short term project, at least as was explained to me.
 continuing to use it three years later ... not so good.  esp since I
 have other use earmarked for it.  please remove the swip and stop using the
 address space.

/bill


On Thu, May 12, 2011 at 02:00:45PM -0400, Vytautas Valancius wrote:
> >> I think he might be referring to the fact that the prefix supposedly used to conduct the test is his, not Georgia Tech's.
> 
> Yes, it's indeed part of Bill's space, but on temporary loan (SWIP)
> for GENI/GaTech:
> 
> ---
> whois -h rr.arin.net 168.62.16.0/24
> [...]
> route:          168.62.16.0/21
> descr:          gtnoise.net (research group at GaTech)
> origin:         AS47065
> mnt-by:         MNT-GIT
> source:         ARIN # Filtered
> ---
> 
> Sorry if it caused confusion! I should have synced this with Bill
> before announcement.
> 
> Regards,
> Vytautas Valancius
> http://valas.gtnoise.net
> Georgia Tech



From owen at delong.com  Fri May 13 16:46:42 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 13 May 2011 14:46:42 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <4DCDA380.7020407@mompl.net>
References: <4DCD8087.9020402@mompl.net> <4DCDA380.7020407@mompl.net>
Message-ID: <EBF92A02-B7E3-457F-AC5A-87DB19347612@delong.com>


On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote:

> Jeroen van Aart wrote:
>> -I FORWARD -i eth0 -s 2001:db8::/64 -j ACCEPT
>> -I FORWARD -i eth1 -d 2001:db8::/64 -j ACCEPT
> 
> Just in case if anyone'd be using it as an example. It's a good idea to make your rules more restrictive.
> 
> Something like:
> -I FORWARD -j DROP
> -I FORWARD -s 2001:db8::/64 -j ACCEPT
> -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> 

I thought iptables processed rules in order until it found a match. In such a case, wouldn't
you want those in the reverse order?

Owen




From owen at delong.com  Fri May 13 16:45:24 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 13 May 2011 14:45:24 -0700
Subject: Routing study
In-Reply-To: <20110513212206.GC8201@vacation.karoshi.com.>
References: <BANLkTinAMQGGESUT8N-rksMsUO2Jc8upmw@mail.gmail.com>
	<20110512103008.GB3902@vacation.karoshi.com.>
	<E86A27CA-C08D-4ED0-910B-9244EC1F3E85@oicr.on.ca>
	<20110513212206.GC8201@vacation.karoshi.com.>
Message-ID: <9E7F595A-3160-44B8-AB54-1D3A0F6F8609@delong.com>

My guess would be that someone didn't get the memo about the use agreement
ending since they apparently still were listed in whois.

Just a thought. Might have been a legitimate mistake from a position of ignorance,
not knowing that they weren't still the registered resource holder.

Owen

On May 13, 2011, at 2:22 PM, bmanning at vacation.karoshi.com wrote:

> 
> their use agreement ended in 2008.  telling the nanog world they are going to reuse it
> three years later is not exactly what most would consider prior notice to the registered
> holder that they would like to do a research project wiht resources that are not registered
> to them.
> 
> /bill
> 
> 
> On Thu, May 12, 2011 at 12:02:55PM -0400, Greg Whynott wrote:
>> On May 12, 2011, at 6:30 AM, <bmanning at vacation.karoshi.com> <bmanning at vacation.karoshi.com> wrote:
>> 
>>> erb
>>> d I would appreciate it if they
>>> would at least notify me ahead of time if they want to futz around
>>> with prefixes that are not registered to them.
>> 
>> 
>> erb
>> 
>> helps to read before you jump!
>> 
>> -g
>> 
>> 
>> --
>> 
>> This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.




From cidr-report at potaroo.net  Fri May 13 17:00:02 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 13 May 2011 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201105132200.p4DM02kq047627@wattle.apnic.net>

BGP Update Report
Interval: 05-May-11 -to- 12-May-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19743           33082  2.1%    4726.0 -- 
 2 - AS9829            24797  1.6%      26.1 -- BSNL-NIB National Internet Backbone
 3 - AS11492           18070  1.1%      14.1 -- CABLEONE - CABLE ONE, INC.
 4 - AS32528           17052  1.1%    2131.5 -- ABBOTT Abbot Labs
 5 - AS17974           16821  1.1%      12.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 6 - AS24560           15194  1.0%      13.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 7 - AS4274            13652  0.9%     168.5 -- ERX-AU-NET Assumption University
 8 - AS35931           13508  0.9%    2251.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 9 - AS44609           13326  0.8%    4442.0 -- FNA Fars News Agency Cultural Arts Institute
10 - AS9299            13112  0.8%      11.9 -- IPG-AS-AP Philippine Long Distance Telephone Company
11 - AS8402            10875  0.7%      22.3 -- CORBINA-AS Corbina Telecom
12 - AS45595           10421  0.7%      28.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited
13 - AS14420            9295  0.6%      13.9 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
14 - AS27738            9262  0.6%      27.3 -- Ecuadortelecom S.A.
15 - AS3454             8641  0.6%    1080.1 -- Universidad Autonoma de Nuevo Leon
16 - AS9498             8524  0.5%      10.6 -- BBIL-AP BHARTI Airtel Ltd.
17 - AS9808             8204  0.5%      23.4 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.
18 - AS8151             8169  0.5%       6.2 -- Uninet S.A. de C.V.
19 - AS35819            8021  0.5%      19.3 -- MOBILY-AS Etihad Etisalat Company (Mobily)
20 - AS7491             8016  0.5%      81.8 -- PI-PH-AS-AP PI-PHILIPINES


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19743           33082  2.1%    4726.0 -- 
 2 - AS44609           13326  0.8%    4442.0 -- FNA Fars News Agency Cultural Arts Institute
 3 - AS35931           13508  0.9%    2251.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 4 - AS32528           17052  1.1%    2131.5 -- ABBOTT Abbot Labs
 5 - AS49600            1284  0.1%    1284.0 -- LASEDA La Seda de Barcelona, S.A
 6 - AS24534            4928  0.3%    1232.0 -- TRANSHYBRID-AS-ID PT. Transhybrid Communication
 7 - AS27771            2189  0.1%    1094.5 -- Instituto Venezolano de Investigaciones Cientificas
 8 - AS3454             8641  0.6%    1080.1 -- Universidad Autonoma de Nuevo Leon
 9 - AS25170             891  0.1%     891.0 -- PRIVILIS PRIVILIS is an Internet Service Provider in Bordeaux, France
10 - AS13610             584  0.0%     584.0 -- PROVOCRAFT-NOVELTY - Provo Craft & Novelty, Inc.
11 - AS27667            1108  0.1%     554.0 -- Universidad Autonoma de la Laguna
12 - AS3                 551  0.0%     735.0 -- NET-CONNECT Net-Connect s.r.o.
13 - AS9476              456  0.0%     456.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd.
14 - AS44584            1768  0.1%     442.0 -- PTLINE-AS Progress Tehnologiya LLC
15 - AS50759             371  0.0%     371.0 -- DANONEPL-AS Danone Sp. z o.o.
16 - AS5868              368  0.0%     368.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
17 - AS38757             706  0.1%     353.0 -- ICONPLN-ID-AP PT. Indonesia Comnets Plus
18 - AS25516             325  0.0%     325.0 -- INIT-AS init AG fuer digitale Kommunikation
19 - AS18704            3154  0.2%     315.4 -- T-SYSTEMS-NA - T-Systems North America, Inc.
20 - AS35772             287  0.0%     287.0 -- SWAP-AS Swap Technologies SRL


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 200.23.202.0/24    8617  0.5%   AS3454  -- Universidad Autonoma de Nuevo Leon
 2 - 130.36.34.0/24     8518  0.5%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24     8518  0.5%   AS32528 -- ABBOTT Abbot Labs
 4 - 63.211.68.0/22     7234  0.4%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 5 - 202.92.235.0/24    7075  0.4%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 6 - 178.22.72.0/21     6666  0.4%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
 7 - 178.22.79.0/24     6654  0.4%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
 8 - 65.122.196.0/24    6432  0.4%   AS19743 -- 
 9 - 221.121.96.0/19    6290  0.4%   AS7491  -- PI-PH-AS-AP PI-PHILIPINES
10 - 198.140.43.0/24    6126  0.4%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
11 - 72.164.144.0/24    5337  0.3%   AS19743 -- 
12 - 65.163.182.0/24    5329  0.3%   AS19743 -- 
13 - 65.162.204.0/24    5328  0.3%   AS19743 -- 
14 - 66.238.91.0/24     5328  0.3%   AS19743 -- 
15 - 66.89.98.0/24      5327  0.3%   AS19743 -- 
16 - 2.92.85.0/24       5196  0.3%   AS8402  -- CORBINA-AS Corbina Telecom
17 - 202.153.174.0/24   3480  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
18 - 64.43.0.0/16       3141  0.2%   AS18704 -- T-SYSTEMS-NA - T-Systems North America, Inc.
19 - 68.65.152.0/22     2808  0.2%   AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
20 - 144.107.16.0/20    2045  0.1%   AS6006  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From cidr-report at potaroo.net  Fri May 13 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 13 May 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201105132200.p4DM000R047620@wattle.apnic.net>

This report has been generated at Fri May 13 21:12:09 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        06-05-11    359540      210993
        07-05-11    360101      211009
        08-05-11    359995      211087
        09-05-11    360076      211487
        10-05-11    360091      211606
        11-05-11    360431      211602
        12-05-11    360672      211886
        13-05-11    360084      211906


AS Summary
         37650  Number of ASes in routing system
         15845  Number of ASes announcing only one prefix
          3646  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      110450944  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 13May11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     359750   211854   147896    41.1%   All ASes

AS6389      3646      260     3386    92.9%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4323      1980      398     1582    79.9%   TWTC - tw telecom holdings,
                                               inc.
AS4766      2452      927     1525    62.2%   KIXS-AS-KR Korea Telecom
AS6478      1678      320     1358    80.9%   ATT-INTERNET3 - AT&T Services,
                                               Inc.
AS22773     1329       96     1233    92.8%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS19262     1498      298     1200    80.1%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS18566     1822      672     1150    63.1%   COVAD - Covad Communications
                                               Co.
AS4755      1462      373     1089    74.5%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1779      761     1018    57.2%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1105      124      981    88.8%   VIETEL-AS-AP Vietel
                                               Corporation
AS10620     1477      513      964    65.3%   Telmex Colombia S.A.
AS28573     1313      418      895    68.2%   NET Servicos de Comunicao S.A.
AS18101      934      145      789    84.5%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS7545      1549      769      780    50.4%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS24560     1151      391      760    66.0%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS4808      1067      337      730    68.4%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1372      642      730    53.2%   Uninet S.A. de C.V.
AS3356      1118      454      664    59.4%   LEVEL3 Level 3 Communications
AS7303       931      272      659    70.8%   Telecom Argentina S.A.
AS11492     1279      625      654    51.1%   CABLEONE - CABLE ONE, INC.
AS17488      935      314      621    66.4%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS17676      665       70      595    89.5%   GIGAINFRA Softbank BB Corp.
AS855        634       56      578    91.2%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS14420      667       92      575    86.2%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS22561      913      355      558    61.1%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS3549       950      395      555    58.4%   GBLX Global Crossing Ltd.
AS4780       747      195      552    73.9%   SEEDNET Digital United Inc.
AS22047      555       30      525    94.6%   VTR BANDA ANCHA S.A.
AS17974     1834     1316      518    28.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       578       83      495    85.6%   MPX-AS Microplex PTY LTD

Total      39420    11701    27719    70.3%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        24.48.0.0/14         AS5769  VIDEOTRON - Videotron Telecom Ltee
        24.225.128.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/23      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.224.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.237.0/24      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.248.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        31.222.96.0/22       AS29119 SERVIHOSTING-AS ServiHosting Networks S.L.
        31.222.100.0/22      AS29119 SERVIHOSTING-AS ServiHosting Networks S.L.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        45.127.0.0/16        AS13767 DBANK - DataBank Holdings, Ltd.
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS16626 GNAXNET-AS - Global Net Access, LLC
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        69.6.81.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.22.32.0/19        AS33150 
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        80.88.12.0/24        AS33779 wataniya-telecom-as
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        115.42.28.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.40.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.42.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.44.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.47.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.48.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.49.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.50.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.51.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.52.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.53.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.54.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.55.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.56.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.57.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.58.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.59.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.61.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.62.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.63.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        158.222.70.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.72.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.224.0/20     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.224.0/22     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.229.0/24     AS19864 O1COMM - O1 COMMUNICATIONS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        176.8.0.0/16         AS15895 KSNET-AS Kyivstar GSM
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc
        192.64.85.0/24       AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.69.108.0/24      AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.101.46.0/24      AS6503  Axtel, S.A.B. de C.V.
        192.101.64.0/21      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.72.0/24      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.124.252.0/22     AS680   DFN-IP service G-WiN
        192.131.233.0/24     AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        192.145.251.0/24     AS10026 PACNET Pacnet Global Ltd
        192.154.32.0/19      AS81    NCREN - MCNC
        192.154.64.0/19      AS81    NCREN - MCNC
        192.169.15.0/24      AS17444 NWT-AS-AP AS number for New World Telephone Ltd.
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        194.5.87.0/24        AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network
        196.2.224.0/22       AS24863 LINKdotNET-AS
        196.6.108.0/24       AS5713  SAIX-NET
        196.13.201.0/24      AS2018  TENET-1
        196.13.202.0/24      AS2018  TENET-1
        196.13.203.0/24      AS2018  TENET-1
        196.13.204.0/24      AS2018  TENET-1
        196.110.105.0/24     AS8513  SKYVISION SkyVision Network Services
        196.202.224.0/21     AS8818  TELE Greenland Autonomous System
        198.1.2.0/24         AS4761  INDOSAT-INP-AP INDOSAT Internet Network Provider
        198.15.4.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.15.5.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.
        198.73.210.0/24      AS21570 ACI-1 - Accelerated Connections Inc.
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.99.241.0/24      AS11797 AC-NIELSEN-AS AC NIELSEN
        198.161.87.0/24      AS6539  GT-BELL - Bell Canada
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited
        198.167.0.0/16       AS7456  INTERHOP - Interhop Network SERVICES Inc.
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        198.175.231.0/24     AS19262 VZGNI-TRANSIT - Verizon Online LLC
        198.180.198.0/24     AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services
        198.182.235.0/24     AS3356  LEVEL3 Level 3 Communications
        199.16.32.0/19       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        199.33.84.0/22       AS9911  CONNECTPLUS-AP Singapore Telecom
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.185.130.0/23     AS19662 UNISERVE-ONLINE - Uniserve On Line
        199.202.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        199.202.216.0/21     AS577   BACOM - Bell Canada
        199.246.116.0/24     AS813   UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.133.73.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.146.186.0/24     AS23655 SNAP-NZ-AS Snap Internet Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.160.158.0/23     AS2764  AAPT AAPT Limited
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        203.18.156.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        203.190.32.0/22      AS24564 
        204.9.216.0/23       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        204.10.232.0/21      AS33150 
        204.19.14.0/23       AS577   BACOM - Bell Canada
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.189.134.0/24     AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.188.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.189.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.190.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.191.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.78.165.0/24      AS16565 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.92.196.0/22      AS10929 NETELLIGENT - Netelligent Hosting Services Inc.
        208.92.199.0/24      AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc.
        209.54.123.0/24      AS6062  NETPLEX - NETPLEX
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.165.239.0/24     AS209   ASN-QWEST - Qwest Communications Company, LLC
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.5.128.0/20       AS4837  CHINA169-BACKBONE CNCGROUP China169 Backbone
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.10.235.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.10.236.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.21.196.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.201.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.202.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.206.0/23      AS12251 INVISION - Invision.com, Inc.
        216.58.192.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.197.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.105.192.0/23     AS7385  INTEGRATELECOM - Integra Telecom, Inc.
        216.105.196.0/23     AS7385  INTEGRATELECOM - Integra Telecom, Inc.
        216.105.200.0/21     AS7385  INTEGRATELECOM - Integra Telecom, Inc.
        216.172.198.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.172.199.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From prue at usc.edu  Fri May 13 17:33:09 2011
From: prue at usc.edu (Walter Prue)
Date: Fri, 13 May 2011 15:33:09 -0700
Subject: Re. EGP Remembered
Message-ID: <6e00e7b728ea.4dcd4f35@usc.edu>

>Does no one remember EGP?

To add to what Jessica already said about EGP, I can add that there were basically 3 metric values:

0 - directly connected
1-254 - not directly connected
255 unavailable

So there was no concept of hop counts or quality of the route other than directly connected.  I don't recall why the metric
of 255 would ever be used as apposed to just not advertising a route.

Walt



From jeroen at mompl.net  Fri May 13 17:33:04 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Fri, 13 May 2011 15:33:04 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <EBF92A02-B7E3-457F-AC5A-87DB19347612@delong.com>
References: <4DCD8087.9020402@mompl.net> <4DCDA380.7020407@mompl.net>
	<EBF92A02-B7E3-457F-AC5A-87DB19347612@delong.com>
Message-ID: <4DCDB1A0.9030002@mompl.net>

Owen DeLong wrote:
> On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote:

>> -I FORWARD -j DROP
>> -I FORWARD -s 2001:db8::/64 -j ACCEPT
>> -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>>
> 
> I thought iptables processed rules in order until it found a match. In such a case, wouldn't
> you want those in the reverse order?

I think hat's the case with -A, but with -I the above is the right 
order. Or at least it works here.

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From owen at delong.com  Fri May 13 17:41:38 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 13 May 2011 15:41:38 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <4DCDB1A0.9030002@mompl.net>
References: <4DCD8087.9020402@mompl.net> <4DCDA380.7020407@mompl.net>
	<EBF92A02-B7E3-457F-AC5A-87DB19347612@delong.com>
	<4DCDB1A0.9030002@mompl.net>
Message-ID: <24DBC8E4-1E1A-439E-B961-A49B8A257C34@delong.com>


On May 13, 2011, at 3:33 PM, Jeroen van Aart wrote:

> Owen DeLong wrote:
>> On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote:
> 
>>> -I FORWARD -j DROP
>>> -I FORWARD -s 2001:db8::/64 -j ACCEPT
>>> -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> 
>> I thought iptables processed rules in order until it found a match. In such a case, wouldn't
>> you want those in the reverse order?
> 
> I think hat's the case with -A, but with -I the above is the right order. Or at least it works here.
> 

DOH! Arcane syntax failure on the part of my brain's parser.

Of course if you are Inserting rather than Appending.

Owen




From johnl at iecc.com  Fri May 13 18:38:00 2011
From: johnl at iecc.com (John Levine)
Date: 13 May 2011 23:38:00 -0000
Subject: dot xxx live or not?
In-Reply-To: <BANLkTi=NhxAmAdC=oT04Z+sUsHVjnrTGow@mail.gmail.com>
Message-ID: <20110513233800.34273.qmail@joyce.lan>


>;; ANSWER SECTION:
>xxx.                    300     IN      NS      a0.xxx.afilias-nst.info.
>xxx.                    300     IN      NS      c0.xxx.afilias-nst.info.
>xxx.                    300     IN      NS      a2.xxx.afilias-nst.info.
>xxx.                    300     IN      NS      b0.xxx.afilias-nst.org.
>xxx.                    300     IN      NS      b2.xxx.afilias-nst.org.
>xxx.                    300     IN      NS      d0.xxx.afilias-nst.org.
>
>;; Query time: 100 msec
>;; SERVER: 10.0.2.24#53(10.0.2.24)
>;; WHEN: Fri May 13 12:10:59 2011
>;; MSG SIZE  rcvd: 162
>
>Anyway, I'd recommend them to read RFC2182 ...

You might be interested in this cool new technology called multicast.

R's,
John



From jmamodio at gmail.com  Fri May 13 18:58:27 2011
From: jmamodio at gmail.com (Jorge Amodio)
Date: Fri, 13 May 2011 18:58:27 -0500
Subject: dot xxx live or not?
In-Reply-To: <20110513233800.34273.qmail@joyce.lan>
References: <BANLkTi=NhxAmAdC=oT04Z+sUsHVjnrTGow@mail.gmail.com>
	<20110513233800.34273.qmail@joyce.lan>
Message-ID: <BANLkTi=662KAHFFUJy2rCTnhfKN=5J1ZBw@mail.gmail.com>

> You might be interested in this cool new technology called multicast.

in this context you may be probably talking about anycast.

there are few details but without digging in too much, there are at
least two name servers for which the packets are flowing through the
same exact route and end point as12041.xe-6-0-4.ar2.iad1.us.nlayer.net
,

-J



From warren at kumari.net  Fri May 13 19:02:46 2011
From: warren at kumari.net (Warren Kumari)
Date: Fri, 13 May 2011 20:02:46 -0400
Subject: Clearing DF bits...
Message-ID: <ADCD9463-15F9-4C93-BA3D-9CDE67DCEA93@kumari.net>

Hi there all,

Years ago it used to be a somewhat common practice to clear the DF bit on packets, either on all packets, or just on those that that you were going to shove through a tunnel (I think the netscreen command was something like "set vpn foo df-bit clear", cisco had something funky with policy routing IIRC,etc).

This was done both to deal with multiple encapsulations and for the folk that block all ICMP for "security reasons".

Is this practice still common / do you know of anyone still doing it?

W


From jmaslak at antelope.net  Fri May 13 19:07:23 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Fri, 13 May 2011 18:07:23 -0600
Subject: Clearing DF bits...
In-Reply-To: <ADCD9463-15F9-4C93-BA3D-9CDE67DCEA93@kumari.net>
References: <ADCD9463-15F9-4C93-BA3D-9CDE67DCEA93@kumari.net>
Message-ID: <AD5E752F-7319-4BBE-AEB3-375C14520C0D@antelope.net>

On May 13, 2011, at 6:02 PM, Warren Kumari <warren at kumari.net> wrote:

> Years This was done both to deal with multiple encapsulations and for the folk that block all ICMP for "security reasons."

I did it as recently as last month, for the same reasons.


From lorenzo at colitti.com  Fri May 13 21:12:08 2011
From: lorenzo at colitti.com (Lorenzo Colitti)
Date: Fri, 13 May 2011 19:12:08 -0700
Subject: Yahoo and IPv6
In-Reply-To: <CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us> <120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
Message-ID: <BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>

On Tue, May 10, 2011 at 11:22 AM, Owen DeLong <owen at delong.com> wrote:

> In other words, Igor can't turn on AAAA records generally until there are
> 182,001 IPv6-only users that are broken from his lack of AAAA records.
>

There will be no IPv6-only users. There will only be users with better IPv6
connectivity than IPv4 connectivity.


> This will be interesting. Personally, I think it will be more along the
> lines
> of when there are more IPv6 only eye-balls with broken IPv4 than there
> are IPv4 eye-balls with broken IPv6, AAAA will become the obvious
> solution.
>

Agreed. The problem is how to get there. Given that 0.2% of Google users has
IPv6 today, my money is still on this taking a while.


From bzeeb-lists at lists.zabbadoz.net  Fri May 13 23:09:07 2011
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sat, 14 May 2011 04:09:07 +0000
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
Message-ID: <F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>

On May 14, 2011, at 2:12 AM, Lorenzo Colitti wrote:

> On Tue, May 10, 2011 at 11:22 AM, Owen DeLong <owen at delong.com> wrote:
> 
>> In other words, Igor can't turn on AAAA records generally until there are
>> 182,001 IPv6-only users that are broken from his lack of AAAA records.
>> 
> 
> There will be no IPv6-only users. There will only be users with better IPv6
> connectivity than IPv4 connectivity.

My Desktop is not able to make any IPv4 socket connections anymore.  I get
"Protocol not supported". So there are IPv6-only users, already bitten by
no AAAA.  So that's -1 from me.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.




From gbonser at seven.com  Fri May 13 23:23:58 2011
From: gbonser at seven.com (George Bonser)
Date: Fri, 13 May 2011 21:23:58 -0700
Subject: Yahoo and IPv6
In-Reply-To: <F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net><4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net><4DC83C4B.5080703@dougbarton.us><120501cc0e81$0222b1e0$066815a0$@net><4DC8476F.2070905@dougbarton.us><AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com><Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net><9099.1305038200@localhost><Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net><CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com><BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E326E@RWC-EX1.corp.seven.com>

> 
> My Desktop is not able to make any IPv4 socket connections anymore.  I
> get
> "Protocol not supported". So there are IPv6-only users, already bitten
> by
> no AAAA.  So that's -1 from me.
> 

Sounds like a job for NAT64/DNS64





From randy at psg.com  Sat May 14 00:27:43 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 14 May 2011 07:27:43 +0200
Subject: Yahoo and IPv6
In-Reply-To: <F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
Message-ID: <m24o4xzwa8.wl%randy@psg.com>

> My Desktop is not able to make any IPv4 socket connections anymore.  I
> get "Protocol not supported". So there are IPv6-only users, already
> bitten by no AAAA.  So that's -1 from me.

i choose to only run decnet ii, and the world should fix my connectivity
problem.

randy



From mpetach at netflight.com  Sat May 14 00:45:21 2011
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 13 May 2011 22:45:21 -0700
Subject: Yahoo and IPv6
In-Reply-To: <m24o4xzwa8.wl%randy@psg.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<m24o4xzwa8.wl%randy@psg.com>
Message-ID: <BANLkTinx-V7bTju2OLm9ra07cxS=9CB_tQ@mail.gmail.com>

On Fri, May 13, 2011 at 10:27 PM, Randy Bush <randy at psg.com> wrote:
>> My Desktop is not able to make any IPv4 socket connections anymore. ?I
>> get "Protocol not supported". So there are IPv6-only users, already
>> bitten by no AAAA. ?So that's -1 from me.
>
> i choose to only run decnet ii, and the world should fix my connectivity
> problem.
>
> randy

Your search for

"DecNet Phase II to IPv6 gateway"

returned 0 results.



From owen at delong.com  Sat May 14 02:57:46 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 14 May 2011 00:57:46 -0700
Subject: Yahoo and IPv6
In-Reply-To: <F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
Message-ID: <0E8B0ABF-8262-4374-988E-C3023C451488@delong.com>


On May 13, 2011, at 9:09 PM, Bjoern A. Zeeb wrote:

> On May 14, 2011, at 2:12 AM, Lorenzo Colitti wrote:
> 
>> On Tue, May 10, 2011 at 11:22 AM, Owen DeLong <owen at delong.com> wrote:
>> 
>>> In other words, Igor can't turn on AAAA records generally until there are
>>> 182,001 IPv6-only users that are broken from his lack of AAAA records.
>>> 
>> 
>> There will be no IPv6-only users. There will only be users with better IPv6
>> connectivity than IPv4 connectivity.
> 
> My Desktop is not able to make any IPv4 socket connections anymore.  I get
> "Protocol not supported". So there are IPv6-only users, already bitten by
> no AAAA.  So that's -1 from me.
> 
> /bz
> 
> -- 
> Bjoern A. Zeeb                                 You have to have visions!
>         Stop bit received. Insert coin for new address family.

Unfortunately, Igor may not see your message since he doesn't have
an IPv6 AAAA record for his MX. ;-)

Owen




From bzeeb-lists at lists.zabbadoz.net  Sat May 14 08:40:16 2011
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sat, 14 May 2011 13:40:16 +0000
Subject: Yahoo and IPv6
In-Reply-To: <0E8B0ABF-8262-4374-988E-C3023C451488@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<0E8B0ABF-8262-4374-988E-C3023C451488@delong.com>
Message-ID: <9CA07A3F-E320-4CB8-8BA6-108A171B8700@lists.zabbadoz.net>

On May 14, 2011, at 7:57 AM, Owen DeLong wrote:

> On May 13, 2011, at 9:09 PM, Bjoern A. Zeeb wrote:
> 
>> On May 14, 2011, at 2:12 AM, Lorenzo Colitti wrote:
>> 
>>> On Tue, May 10, 2011 at 11:22 AM, Owen DeLong <owen at delong.com> wrote:
>>> 
>>>> In other words, Igor can't turn on AAAA records generally until there are
>>>> 182,001 IPv6-only users that are broken from his lack of AAAA records.
>>>> 
>>> 
>>> There will be no IPv6-only users. There will only be users with better IPv6
>>> connectivity than IPv4 connectivity.
>> 
>> My Desktop is not able to make any IPv4 socket connections anymore.  I get
>> "Protocol not supported". So there are IPv6-only users, already bitten by
>> no AAAA.  So that's -1 from me.
> 
> Unfortunately, Igor may not see your message since he doesn't have
> an IPv6 AAAA record for his MX. ;-)

But s0.nanog.org does, and mailman.nanog.org is v4 exclusively and one of my
MX still has legacy IP as well.  But the message wasn't for Igor anyway.

I was just mumbling about the fact that the IPv6 advocacy activists and people
in charge of v6 rollouts should eat more of their dog-food to make sure that
we'll actually be ready for _more_ IPv6 only users rather than falling into the
same tarpit we hit for DS in the near future.  The web strangely is the least
thing I care about.

/bz

PS: I hope all of the big guys will actually have AAAA glue records for their 
domains in DNS for world IPv6 day.  So far most of them are failing that test
badly which means the brokeness of IPv6 starts at the very beginning:(

-- 
Bjoern A. Zeeb                                 You have to have visions!
        Stop bit received. Insert coin for new address family.


From matthew at matthew.at  Sat May 14 10:41:29 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 14 May 2011 08:41:29 -0700
Subject: Yahoo and IPv6
In-Reply-To: <F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
Message-ID: <E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>


>>> 
>> 
> 
> My Desktop is not able to make any IPv4 socket connections anymore.  I get
> "Protocol not supported". So there are IPv6-only users, already bitten by
> no AAAA.  So that's -1 from me.
> 

Sounds to me like you're not on The Internet any more.

Matthew Kaufman



From bzeeb-lists at lists.zabbadoz.net  Sat May 14 11:27:45 2011
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sat, 14 May 2011 16:27:45 +0000
Subject: Yahoo and IPv6
In-Reply-To: <E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
Message-ID: <8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>

On May 14, 2011, at 3:41 PM, Matthew Kaufman wrote:

>> My Desktop is not able to make any IPv4 socket connections anymore.  I get
>> "Protocol not supported". So there are IPv6-only users, already bitten by
>> no AAAA.  So that's -1 from me.
>> 
> 
> Sounds to me like you're not on The Internet any more.

Haha.  I might still do UUCP and listen to a talk from Eric Allman currently,
yet I can send you Email and that's supposed to be over the Internet only
these days, I just heard.  So I am clearly online.

I assume you don't understand the options some people have or how much content
might be available on IPv6 already and might have been for years.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.




From vixie at isc.org  Sat May 14 11:47:46 2011
From: vixie at isc.org (Paul Vixie)
Date: Sat, 14 May 2011 16:47:46 +0000
Subject: Yahoo and IPv6
Message-ID: <87180.1305391666@nsa.vix.com>

Matthew Kaufman <matthew at matthew.at> writes:

>> My Desktop is not able to make any IPv4 socket connections anymore.  I get
>> "Protocol not supported". So there are IPv6-only users, already bitten by
>> no AAAA.  So that's -1 from me.
>
> Sounds to me like you're not on The Internet any more.

in <http://www.merit.edu/mail.archives/nanog/2001-04/msg00294.html> we see:

(*2)    Q: But what IS the Internet?
        A: "It's the largest equivalence class in the reflexive, transitive,
        symmetric, closure of the relationship 'can be reached by an IP
        packet from'". Seth Breidbart

by which definition, matthew's observation would be correct.  folks who want
to run V6 only and still be "on the internet" will need proxies for a long
while.  folks who want to run V6 only *today* and not have any proxies *today*
are sort of on their own -- the industry will not cater to market non-forces.
-- 
Paul Vixie
KI6YSY



From tme at americafree.tv  Sat May 14 12:02:16 2011
From: tme at americafree.tv (Marshall Eubanks)
Date: Sat, 14 May 2011 13:02:16 -0400
Subject: Yahoo and IPv6
In-Reply-To: <87180.1305391666@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
Message-ID: <6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>


On May 14, 2011, at 12:47 PM, Paul Vixie wrote:

> Matthew Kaufman <matthew at matthew.at> writes:
> 
>>> My Desktop is not able to make any IPv4 socket connections anymore.  I get
>>> "Protocol not supported". So there are IPv6-only users, already bitten by
>>> no AAAA.  So that's -1 from me.
>> 
>> Sounds to me like you're not on The Internet any more.
> 
> in <http://www.merit.edu/mail.archives/nanog/2001-04/msg00294.html> we see:
> 
> (*2)    Q: But what IS the Internet?
>        A: "It's the largest equivalence class in the reflexive, transitive,
>        symmetric, closure of the relationship 'can be reached by an IP
>        packet from'". Seth Breidbart
> 
> by which definition, matthew's observation would be correct.  folks who want
> to run V6 only and still be "on the internet" will need proxies for a long
> while.  folks who want to run V6 only *today* and not have any proxies *today*
> are sort of on their own -- the industry will not cater to market non-forces.

I think that the real question is, when will people who are running IPv4 only not be on the Internet by this
definition ?

Regards
Marshall


> -- 
> Paul Vixie
> KI6YSY
> 
> 




From vixie at isc.org  Sat May 14 12:06:45 2011
From: vixie at isc.org (Paul Vixie)
Date: Sat, 14 May 2011 17:06:45 +0000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Sat, 14 May 2011 13:02:16 -0400."
	<6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>
References: <87180.1305391666@nsa.vix.com>
	<6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>
Message-ID: <88271.1305392805@nsa.vix.com>

> From: Marshall Eubanks <tme at americafree.tv>
> Date: Sat, 14 May 2011 13:02:16 -0400
> 
> I think that the real question is, when will people who are running
> IPv4 only not be on the Internet by this definition ?

is there an online betting mechanism we could use, that we all think will
still be in business decades from now when the truth is known?  if we're
going to start picking the month and year when IPv4 is the new "PDP-11
compatibility mode" (that's a VAX reference), where the winner is whoever
comes closest without going over, my pick is July 2021, and i'm in for $50.



From cb.list6 at gmail.com  Sat May 14 12:19:51 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sat, 14 May 2011 10:19:51 -0700
Subject: Yahoo and IPv6
In-Reply-To: <8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
Message-ID: <BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>

On May 14, 2011 9:28 AM, "Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net>
wrote:
>
> On May 14, 2011, at 3:41 PM, Matthew Kaufman wrote:
>
> >> My Desktop is not able to make any IPv4 socket connections anymore.  I
get
> >> "Protocol not supported". So there are IPv6-only users, already bitten
by
> >> no AAAA.  So that's -1 from me.
> >>
> >
> > Sounds to me like you're not on The Internet any more.
>
> Haha.  I might still do UUCP and listen to a talk from Eric Allman
currently,
> yet I can send you Email and that's supposed to be over the Internet only
> these days, I just heard.  So I am clearly online.
>
> I assume you don't understand the options some people have or how much
content
> might be available on IPv6 already and might have been for years.
>
> /bz
>

Ipv6-only is a highly functional reality when enabled with nat64/dns64,
there are several empirical accounts on the web.

I have be running a beta service of it for over a year and my experience is
that it works very well for web and email and nearly everything I do on
smartphone , but not all things for sure.

Cb
?---------------
http://bit.ly/igQBx4 -- T-Mobile USA ipv6 beta.

> --
> Bjoern A. Zeeb                                 You have to have visions!
>         Stop bit received. Insert coin for new address family.
>
>


From simon.leinen at switch.ch  Sat May 14 12:23:24 2011
From: simon.leinen at switch.ch (Simon Leinen)
Date: Sat, 14 May 2011 19:23:24 +0200
Subject: Network Equipment Discussion (HP and L2/10G)
In-Reply-To: <D338D1613B32624285BB321A5CF3DB25134C553950@ginga.ai.net> (Deepak
	Jain's message of "Fri, 13 May 2011 11:14:14 -0400")
References: <D338D1613B32624285BB321A5CF3DB25134C553950@ginga.ai.net>
Message-ID: <aasjshmc1f.fsf@switch.ch>

Deepak Jain writes:
> The wrinkle here is that I can't use a normal enterprise 10G switch
> because of the need for DWDM optics (ideally 80km style).

80km DWDM optics in SFP+ format should be available now or RSN.  Search
engines turn up a few purported vendors.  The ones I found conform to
the 100GHz grid, but 50GHz ones should be coming too.

Haven't tried any of those myself though.
-- 
Simon.



From Valdis.Kletnieks at vt.edu  Sat May 14 12:26:17 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 14 May 2011 13:26:17 -0400
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Sat, 14 May 2011 13:02:16 EDT."
	<6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>
References: <87180.1305391666@nsa.vix.com>
	<6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>
Message-ID: <41243.1305393977@localhost>

On Sat, 14 May 2011 13:02:16 EDT, Marshall Eubanks said:
> I think that the real question is, when will people who are running IPv4
> only not be on the Internet by this definition ?

Any 36 bit machines left on the net?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110514/ec1c9e13/attachment.bin>

From johnl at iecc.com  Sat May 14 12:27:20 2011
From: johnl at iecc.com (John Levine)
Date: 14 May 2011 17:27:20 -0000
Subject: Yahoo and IPv6
In-Reply-To: <6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>
Message-ID: <20110514172720.26987.qmail@joyce.lan>

>I think that the real question is, when will people who are running
>IPv4 only not be on the Internet by this definition ?

Probably never.  What would be the incentive to turn off the NAT
gateways?

R's,
John





From iljitsch at muada.com  Sat May 14 12:59:55 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sat, 14 May 2011 19:59:55 +0200
Subject: Yahoo and IPv6
In-Reply-To: <87180.1305391666@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
Message-ID: <7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>

On 14 mei 2011, at 18:47, Paul Vixie wrote:

> folks who want
> to run V6 only and still be "on the internet" will need proxies for  
> a long
> while.  folks who want to run V6 only *today* and not have any  
> proxies *today*
> are sort of on their own -- the industry will not cater to market  
> non-forces.

And clearly that situation can be kept that way for a long time by  
simply not serving them anything over IPv6.

But is that wat we want?

Currently IPv4 is pretty good but that's not going to last once 1.5  
NATs on average between any two points grows to 3.8 of them, with 1.7  
starved for address/port combinations*. At that point you can  
technically still be 100% connected using just IPv4, but it won't be  
much fun anymore.

* numbers pulled out of the air by yours truly, but based on two  
consumers with home NAT today and with additional carrier NAT in the  
future.

I've been on IPv6 for a long time. When I started with IPv6, the only  
applications (to use the term loosely) that understood v6 were ping6  
and traceroute6. These days, I think the only thing I wouldn't be able  
to do over IPv6 is print. It used to be that IPv6 pingtimes were 2 - 3  
times worse than IPv4 pingtimes. They're pretty much the same 80% of  
the time now. I used to have 8 IPv4 addresses, enough for most of my  
computers. I have one now, with mandatory NAT. When I move later this  
year I may very well only have a partial IPv4 address.

The times are a-changing.



From matthew at matthew.at  Sat May 14 13:10:00 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 14 May 2011 11:10:00 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
Message-ID: <4DCEC578.9060308@matthew.at>

On 5/14/2011 10:19 AM, Cameron Byrne wrote:
>
>
> Ipv6-only is a highly functional reality when enabled with 
> nat64/dns64, there are several empirical accounts on the web.
>
>

For a version of "highly functional" that does not include Skype, 
BitTorrent, SIP phones, and anything Flash Player app using RTMFP to 
reach peers, sure.

Matthew Kaufman



From jared at puck.nether.net  Sat May 14 13:20:35 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 14 May 2011 14:20:35 -0400
Subject: Yahoo and IPv6
In-Reply-To: <4DCEC578.9060308@matthew.at>
References: <Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
	<4DCEC578.9060308@matthew.at>
Message-ID: <20110514182035.GC12694@puck.nether.net>

On Sat, May 14, 2011 at 11:10:00AM -0700, Matthew Kaufman wrote:
> On 5/14/2011 10:19 AM, Cameron Byrne wrote:
> >
> >
> >Ipv6-only is a highly functional reality when enabled with
> >nat64/dns64, there are several empirical accounts on the web.
> >
> >
> 
> For a version of "highly functional" that does not include Skype,
> BitTorrent, SIP phones, and anything Flash Player app using RTMFP to
> reach peers, sure.

	As has been mentioned here, the lack of reaching any of these can
be seen as a plus, including the various advert networks.  Instead of loading
that flash video iframe you might get content.  And it's much better now
then when you were using wais/gopher/cern httpd in the day.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.



From jg at freedesktop.org  Sat May 14 13:25:08 2011
From: jg at freedesktop.org (Jim Gettys)
Date: Sat, 14 May 2011 14:25:08 -0400
Subject: Yahoo and IPv6
In-Reply-To: <7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
Message-ID: <4DCEC904.1040006@freedesktop.org>

On 05/14/2011 01:59 PM, Iljitsch van Beijnum wrote:
> dditional carrier NAT in the future.
>
> I've been on IPv6 for a long time. When I started with IPv6, the only 
> applications (to use the term loosely) that understood v6 were ping6 
> and traceroute6. These days, I think the only thing I wouldn't be able 
> to do over IPv6 is print.
And I've been able to print using IPv6 on the $200 HP ethernet/wireless 
printer I bought over 18 months ago...

Times are changing.

But we have to get naming squared away.  Typing IPv6 addresses is for 
the birds, and having everyone have to go fuss with a DNS provider isn't 
a viable solution.
             - Jim




From bill at herrin.us  Sat May 14 13:31:29 2011
From: bill at herrin.us (William Herrin)
Date: Sat, 14 May 2011 14:31:29 -0400
Subject: Yahoo and IPv6
In-Reply-To: <88271.1305392805@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
	<6AB25966-663C-4EEC-8CF9-C3D385E83123@americafree.tv>
	<88271.1305392805@nsa.vix.com>
Message-ID: <BANLkTimo+xg4svaZ7OW2VtCihfnEGUrmZg@mail.gmail.com>

On Sat, May 14, 2011 at 1:06 PM, Paul Vixie <vixie at isc.org> wrote:
>> From: Marshall Eubanks <tme at americafree.tv>
>> Date: Sat, 14 May 2011 13:02:16 -0400
>>
>> I think that the real question is, when will people who are running
>> IPv4 only not be on the Internet by this definition ?
>
> is there an online betting mechanism we could use, that we all think will
> still be in business decades from now when the truth is known?

http://longbets.org/

>?if we're
> going to start picking the month and year when IPv4 is the new "PDP-11
> compatibility mode" (that's a VAX reference), where the winner is whoever
> comes closest without going over, my pick is July 2021, and i'm in for $50.

Two suggestions:

1. Predict the condition, not the date. In other words, not "Condition
X will occur at Y" but "At Y, condition X will be true." The problem
with predicting the date is that the bet can't close until the
condition occurs. That leaves an unbounded case.

2. Measurability. How do you measure, "IPv4 is the new PDP-11
compatibility mode?" Try something like, "In the month of July 2021,
X% of the network traffic by packet count on the top 5 Internet
carriers will contain IPv4 packets. "

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From bonomi at mail.r-bonomi.com  Sat May 14 16:38:51 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sat, 14 May 2011 16:38:51 -0500 (CDT)
Subject: Yahoo and IPv6
In-Reply-To: <88271.1305392805@nsa.vix.com>
Message-ID: <201105142138.p4ELcpoK020146@mail.r-bonomi.com>


> From: Paul Vixie <vixie at isc.org>
> To: nanog at nanog.org
> Subject: Re: Yahoo and IPv6
> Date: Sat, 14 May 2011 17:06:45 +0000
>
> > From: Marshall Eubanks <tme at americafree.tv>
> > Date: Sat, 14 May 2011 13:02:16 -0400
> > 
> > I think that the real question is, when will people who are running
> > IPv4 only not be on the Internet by this definition ?
>
> is there an online betting mechanism we could use, that we all think will
> still be in business decades from now when the truth is known?  if we're
> going to start picking the month and year when IPv4 is the new "PDP-11
> compatibility mode" (that's a VAX reference), where the winner is whoever
> comes closest without going over, my pick is July 2021, and i'm in for $50.
>

You could probably interest the University of Iowa College of Business in
it.  See: <http://tippie.uiowa.edu/iem/index.cfm>

The genesis of of this project was a 'futures' exchange on candidates for
the office of President of the United States.  It's had an amazing track-
record of identifying 'winners' there.



From vixie at isc.org  Sat May 14 18:39:24 2011
From: vixie at isc.org (Paul Vixie)
Date: Sat, 14 May 2011 23:39:24 +0000
Subject: Yahoo and IPv6
In-Reply-To: <4DCEC904.1040006@freedesktop.org> (Jim Gettys's message of "Sat, 
	14 May 2011 14:25:08 -0400")
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org>
Message-ID: <8966.1305416364@nsa.vix.com>

Jim Gettys <jg at freedesktop.org> writes:

> ... we have to get naming squared away.  Typing IPv6 addresses is for the
> birds, and having everyone have to go fuss with a DNS provider isn't a
> viable solution.

perhaps i'm too close to the problem because that solution looks quite
viable to me.  dns providers who don't keep up with the market (which means
ipv6 and dnssec in this context) will lose business to those who do.
-- 
Paul Vixie
KI6YSY



From nanog at jima.tk  Sat May 14 20:15:16 2011
From: nanog at jima.tk (Jima)
Date: Sat, 14 May 2011 20:15:16 -0500
Subject: Yahoo and IPv6
In-Reply-To: <4DCEC904.1040006@freedesktop.org>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org>
Message-ID: <4DCF2924.4020807@jima.tk>

On 2011-05-14 13:25, Jim Gettys wrote:
> On 05/14/2011 01:59 PM, Iljitsch van Beijnum wrote:
>> I've been on IPv6 for a long time. When I started with IPv6, the only
>> applications (to use the term loosely) that understood v6 were ping6
>> and traceroute6. These days, I think the only thing I wouldn't be able
>> to do over IPv6 is print.
 >
> And I've been able to print using IPv6 on the $200 HP ethernet/wireless
> printer I bought over 18 months ago...

  And a $100 Samsung laser printer here, sold as long ago as 15 months. 
  (Also an expensive color laser copier Ricoh started producing in 2007, 
although I don't know if it shipped with an IPv6-capable firmware.) 
Even printing isn't the last holdout. :-)

  Home entertainment devices, on the other hand... :-(

      Jima



From nanog at jima.tk  Sat May 14 20:41:48 2011
From: nanog at jima.tk (Jima)
Date: Sat, 14 May 2011 20:41:48 -0500
Subject: Yahoo and IPv6
In-Reply-To: <4DCEC578.9060308@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
	<4DCEC578.9060308@matthew.at>
Message-ID: <4DCF2F5C.8030104@jima.tk>

On 2011-05-14 13:10, Matthew Kaufman wrote:
> On 5/14/2011 10:19 AM, Cameron Byrne wrote:
>> Ipv6-only is a highly functional reality when enabled with
>> nat64/dns64, there are several empirical accounts on the web.
>
> For a version of "highly functional" that does not include Skype,
> BitTorrent, SIP phones, and anything Flash Player app using RTMFP to
> reach peers, sure.

1. There are SIP phones that support IPv6, e.g., 
http://wiki.snom.com/Networking/IPv6

2. Exactly whose fault is it that RTMFP can't reach peers via IPv6? 
(Granted, I'm not sure RTMFP is the best argument for your point anyway, 
since apparently symmetric NAT monkey-wrenches it, too: 
http://forums.adobe.com/message/3602495 )

      Jima



From rdrake at direcpath.com  Sat May 14 22:01:46 2011
From: rdrake at direcpath.com (Robert Drake)
Date: Sat, 14 May 2011 23:01:46 -0400
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTinOHFpVjnO37MUGyOTe1ARSPV=Wbg@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<BANLkTikEzd3Ztto_9GdMsPfsZ7UUbLcBsQ@mail.gmail.com>	<A674A144-70BA-495B-BC4C-38886160495D@puck.nether.net>	<BANLkTinO7+FJWz2_7cbTDwRJqPoGzapmCQ@mail.gmail.com>	<BANLkTimBs6BNCG7L8iqWnhDOe2CMQW=rgg@mail.gmail.com>
	<BANLkTinOHFpVjnO37MUGyOTe1ARSPV=Wbg@mail.gmail.com>
Message-ID: <4DCF421A.4020100@direcpath.com>

On 5/10/2011 12:57 AM, Jeff Wheeler wrote:
> Your suggestion has two main disadvantages:
> 1) it doesn't work on some platforms, because input ACL won't stop ND
> learn/solicit -- obviously this is bad
> 2) it requires you to configure a potentially large input ACL on every
> single interface on the box, and adjust that ACL whenever you
> provision more IPv6 addresses for end-hosts -- kinda like not having a
> control-plane filter, only worse
>

Might need to rewrite some portion of ND to do this, but can't a cookie 
be encoded in the ND packet and no state kept?  That should reduce the 
problem to one of a packet flood which everyone already deals with now.

Sorry if this has been suggested/shot down before.  The ND problems keep 
being mentioned and I never see this proposed and it seems like an 
obvious solution.

Robert




From matthew at matthew.at  Sat May 14 23:29:48 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 14 May 2011 21:29:48 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DCF2F5C.8030104@jima.tk>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>
	<4DCF2F5C.8030104@jima.tk>
Message-ID: <4DCF56BC.8070209@matthew.at>

On 5/14/2011 6:41 PM, Jima wrote:
> On 2011-05-14 13:10, Matthew Kaufman wrote:
>> On 5/14/2011 10:19 AM, Cameron Byrne wrote:
>>> Ipv6-only is a highly functional reality when enabled with
>>> nat64/dns64, there are several empirical accounts on the web.
>>
>> For a version of "highly functional" that does not include Skype,
>> BitTorrent, SIP phones, and anything Flash Player app using RTMFP to
>> reach peers, sure.
>
> 1. There are SIP phones that support IPv6, e.g., 
> http://wiki.snom.com/Networking/IPv6

Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk to 
SIP phones on an IP4-only network.

>
> 2. Exactly whose fault is it that RTMFP can't reach peers via IPv6? 
> (Granted, I'm not sure RTMFP is the best argument for your point 
> anyway, since apparently symmetric NAT monkey-wrenches it, too: 
> http://forums.adobe.com/message/3602495 )

RTMFP can reach peers via IPv6... but it can't talk between an IPv6-only 
peer that is behind a NAT64 and an IPv4-only peer.

And that would be the fault of NAT64, which for all of the applications 
I mentioned (and more) made the seriously wrong assumption that every 
IPv4 address is looked up in a DNS server.

Matthew Kaufman



From eugen at leitl.org  Sun May 15 03:29:13 2011
From: eugen at leitl.org (Eugen Leitl)
Date: Sun, 15 May 2011 10:29:13 +0200
Subject: Backbone operators see IPv6 connectivity demand up, but little traffic
Message-ID: <20110515082913.GL4351@leitl.org>


http://searchtelecom.techtarget.com/news/2240035722/Backbone-operators-see-IPv6-connectivity-demand-up-but-little-traffic

Backbone operators see IPv6 connectivity demand up, but little traffic

Internet backbone and wholesale carriers are anecdotally reporting a rapid
rise in demand from their service provider customers for IPv6 connectivity?an
apparent prelude to the full-scale arrival of the IPv6 Internet as World IPv6
Day looms on the horizon. 

We've seen a tremendous increase in IPv6 traffic. Granted, though, it still
comes nowhere near our traffic on v4.

Reid Fishler, director, Hurricane Electric

Backbone operators, however, acknowledge that the amount of IPv6 traffic
still pales in comparison to that of its predecessor, IPv4, and that it's
still too early to tell how quickly it will grow.

Hurricane Electric, which claims to operate the world's largest IPv6-native
Internet backbone, has established three dual-stack (both IPv4 and IPv6)
points of presence (POPs) at carrier hotels since March. Citing growing
demand from operators for European peering points with IPv6 Internet
connectivity, the wholesale provider connected its backbone to the Equinix
Paris Exchange last week.

When Hurricane Electric offered native dual-stack services to carriers two
years ago, few accepted them, according to Reid Fishler, director of carrier
sales and purchasing at Hurricane Electric. Customers were confused or
disinterested, but now "the vast majority" of service providers that are
buying wholesale access at these Internet peering points are opting for
dual-stack?and in rare cases, IPv6-only connections, he said.

"We've seen a tremendous increase in IPv6 traffic. Granted, though, it still
comes nowhere near our traffic on v4," Fishler said. "But look at any one of
these [Internet] exchange fabrics and compare v6 traffic to v4 traffic. Up
until a year ago, you couldn't even rate [the amount of IPv6 traffic], and
now you're starting to see it [on the Internet], and you definitely see a lot
of the traffic coming in from China and Asia as v6 traffic now."

Hurricane Electric also established dual-stack POPs in Internet exchange
point Telehouse Paris Voltaire and VegasNAP in Las Vegas in March. Late last
year, demand for IPv6 Internet connectivity prompted Hurricane Electric's POP
expansions into peering points Comfluent, in Denver; Equinix Singapore
Exchange; and the Northwest Access Exchange in Portland, Ore.  More on IPv6
connectivity

Get a telecom network architect's view on how to convert IPv4 to IPv6.

Learn why your telecom IPv6 transition plan must include more than upgrading
your routers.

Find out how to make the IPv4 to IPv6 transition work.

If you can get your kids to eat their veggies, you can sell enterprises on
IPv6 migration plans.

Shawn Morris, manager of IP development at NTT America, said IPv6 Internet
traffic is still "a tiny fraction" of all Internet traffic, but NTT America
has seen a steady increase of demand for and questions about IPv6
connectivity from its carrier customers over the past few years. A large
portion of the demand is coming from service providers in Latin America,
which have been slower to adopt IPv6 than carriers in other regions, Morris
said.

Demand for dual-stack peering at public Internet exchanges and at private
peering points has also increased, said Morris, who oversees network
architecture, hardware and software.

"I wouldn't say it's at parity with IPv6, but it's definitely trending in
that direction," he said. "That's a big change. In ?03 and ?04, we went
native [with IPv6 on our backbone] and were ready to peer with any of our
peers, but it took a good six to seven years before we really saw an increase
in demand."

More requests for IPv6 connectivity, but traffic barely materializing

NTT America could not provide any data regarding IPv6 Internet traffic
levels. But in its search for a new network monitoring platform, one of its
requirements was more granular visibility into levels of IPv4 and IPv6
traffic, Morris said.

"We don't have any hard statistics ... but we definitely keep seeing more
customers adding v6 onto their connections and an increase in the v6 routing
table," he said. "But we're also expecting, to be honest, quite a bit of
growth in the IPv4 routing table as people start to split up the address
space in the run-out. So, we're planning for a large amount of growth in both
tables."

Order requests for IPv6 connectivity have doubled every year for the past
three years at Global Crossing, according to Anthony Christie, the backbone
operator's chief technical and information officer. But that hasn't
translated yet into any significant amount of IPv6 Internet traffic on Global
Crossing's network, he said.

"The traffic that we're seeing would need to increase 100 times the current
levels in order for it to be a meaningful percentage in total traffic,"
Christie said. "The content, addresses and infrastructure associated with
[IPv4] is not yet exhausted, so you wouldn't necessarily expect a switch to
flick because someone has decided to order a v6 port on our network."

The American Registry of Internet Numbers (ARIN)?the Regional Internet
Registry (RIR) for the United States, Canada and much of the Caribbean?has
seen similar rates of growth in requests for IPv6 address space blocs,
according to John Curran, president and CEO of ARIN. In 2008, ARIN received
250 requests for IPv6 address blocs from ISPs and hosting providers; in 2009,
that rose to just above 400. Last year, ARIN received 700 requests. Within
the first quarter of 2011, it has received 500 requests for IPv6 address
blocs and expects that to total 1,500 by the end of the year, Curran said. 

"We've seen, for the last three years, the requests for IPv6 address space
double," Curran said. "But that may not result in traffic."

Internet backbone provider Level 3 Communications, which recently announced
its intention to buy Global Crossing, has seen similar IPv6 connectivity and
traffic trends.

"Level 3 has witnessed growth in the number of IPv6 routes that are being
advertised, but IPv6 routes still account for a very small portion of all
Internet routes," said Mark Taylor, vice president of content and media at
Level 3. "Likewise, even as IPv6 Internet traffic is on the rise, it is still
small relative to the growth in address announcements."

What will spur growth of the IPv6 Internet?

Backbone operators don't doubt that the IPv6 Internet will grow?but how
rapidly or under what conditions is anyone's guess.

Hurricane Electric's Fishler said he expects rapid growth will be spurred by
consumer demand for a "killer application" that only functions on the IPv6
Internet.

"If some large Internet-addressable service ... comes out and it needs to
have 10,000 servers or whatever it needs, that next thing is going to
[require] v6," he said. "That next product, whatever it'll be, will be IPv6
primarily and IPv4 secondarily ... and that's when we're going to see IPv6
take off, and that's when customers and service providers are going to be
taken aback [if they can't] do it natively."

Morris, of NTT America, didn't rule out the IPv6 killer app theory but
predicted more conservative, steady growth of the IPv6 Internet.

"We're going to see a more gradual increase in IPv6 traffic as time goes on,
unless something comes along that's a killer app that's only available on
IPv6," he said. "I honestly don't know what that would be ... but something
like that might spurn a really quick uptake in IPv6. But what I think we're
going to see is more and more organic growth."



From cdel at firsthand.net  Sun May 15 08:00:21 2011
From: cdel at firsthand.net (Firsthand)
Date: Sun, 15 May 2011 15:00:21 +0200
Subject: Yahoo and IPv6
In-Reply-To: <20110514172720.26987.qmail@joyce.lan>
References: <20110514172720.26987.qmail@joyce.lan>
Message-ID: <79112846-2345-49EF-AD94-9439503EB8AB@firsthand.net>

When the RIAA and friends in congress and international chapter affiliates make it illegal to share  a network address. 

Sorry that is when we turn them back on!!

Christian de Larrinaga


On 14 May 2011, at 19:27, "John Levine" <johnl at iecc.com> wrote:

>> I think that the real question is, when will people who are running
>> IPv4 only not be on the Internet by this definition ?
> 
> Probably never.  What would be the incentive to turn off the NAT
> gateways?
> 
> R's,
> Joh



From cb.list6 at gmail.com  Sun May 15 08:49:43 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 15 May 2011 06:49:43 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DCF56BC.8070209@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
	<4DCEC578.9060308@matthew.at> <4DCF2F5C.8030104@jima.tk>
	<4DCF56BC.8070209@matthew.at>
Message-ID: <BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>

On May 14, 2011 9:30 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>
> On 5/14/2011 6:41 PM, Jima wrote:
>>
>> On 2011-05-14 13:10, Matthew Kaufman wrote:
>>>
>>> On 5/14/2011 10:19 AM, Cameron Byrne wrote:
>>>>
>>>> Ipv6-only is a highly functional reality when enabled with
>>>> nat64/dns64, there are several empirical accounts on the web.
>>>
>>>
>>> For a version of "highly functional" that does not include Skype,
>>> BitTorrent, SIP phones, and anything Flash Player app using RTMFP to
>>> reach peers, sure.
>>
>>
>> 1. There are SIP phones that support IPv6, e.g.,
http://wiki.snom.com/Networking/IPv6
>
>
> Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk to SIP
phones on an IP4-only network.
>

Right, that is why we have SBC / b2bue for the cases we want to work.

>
>>
>> 2. Exactly whose fault is it that RTMFP can't reach peers via IPv6?
(Granted, I'm not sure RTMFP is the best argument for your point anyway,
since apparently symmetric NAT monkey-wrenches it, too:
http://forums.adobe.com/message/3602495 )
>
>
> RTMFP can reach peers via IPv6... but it can't talk between an IPv6-only
peer that is behind a NAT64 and an IPv4-only peer.
>
> And that would be the fault of NAT64, which for all of the applications I
mentioned (and more) made the seriously wrong assumption that every IPv4
address is looked up in a DNS server.
>

We have agreed to disagree on the value of this before.  Sorry your not so
popular protocol is going the way of EGP .... it's just not fit for the
evolving internet and will be subject to natural deselction. I am sure you
will disagree with that and insist every end user must always support ipv4
because rtmfp is top of mind for so many users .... but we can leave it at
that ....please

Cb

> Matthew Kaufman
>


From matthew at matthew.at  Sun May 15 10:28:54 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 15 May 2011 08:28:54 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
Message-ID: <4DCFF136.8040102@matthew.at>

On 5/15/2011 6:49 AM, Cameron Byrne wrote:
>
>
> On May 14, 2011 9:30 PM, "Matthew Kaufman" <matthew at matthew.at 
> <mailto:matthew at matthew.at>> wrote:
> >
>
> >
> > Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk 
> to SIP phones on an IP4-only network.
> >
>
> Right, that is why we have SBC / b2bue for the cases we want to work.
>

Ok, so you concede that NAT64 requires yet another device at the edge to 
make the SIP phones work...
>
>
> We have agreed to disagree on the value of this before.  Sorry your 
> not so popular protocol is going the way of EGP .... it's just not fit 
> for the evolving internet and will be subject to natural deselction. I 
> am sure you will disagree with that and insist every end user must 
> always support ipv4 because rtmfp is top of mind for so many users 
> .... but we can leave it at that ....please
>
>

...and we'll agree to disagree on this one (RTMFP)... and users will 
just be ok with BitTorrent and Skype not working on the v6-only + NAT64 
networks you're building, I suppose?

Matthew Kaufman


From cb.list6 at gmail.com  Sun May 15 11:00:02 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 15 May 2011 09:00:02 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DCFF136.8040102@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
	<4DCEC578.9060308@matthew.at> <4DCF2F5C.8030104@jima.tk>
	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
Message-ID: <BANLkTikMinmWhoon28Y-wZH6u+wFYEUT1Q@mail.gmail.com>

On May 15, 2011 8:28 AM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>
> On 5/15/2011 6:49 AM, Cameron Byrne wrote:
>>
>>
>> On May 14, 2011 9:30 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>> >
>>
>> >
>> > Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk to
SIP phones on an IP4-only network.
>> >
>>
>> Right, that is why we have SBC / b2bue for the cases we want to work.
>
>
> Ok, so you concede that NAT64 requires yet another device at the edge to
make the SIP phones work...
>

Don't think I have ever disagreed.

>>
>> We have agreed to disagree on the value of this before.  Sorry your not
so popular protocol is going the way of EGP .... it's just not fit for the
evolving internet and will be subject to natural deselction. I am sure you
will disagree with that and insist every end user must always support ipv4
because rtmfp is top of mind for so many users .... but we can leave it at
that ....please
>>
>>
>
> ...and we'll agree to disagree on this one (RTMFP)... and users will just
be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks
you're building, I suppose?
>

Yep.   I have a pretty good model of how most users use their phones. That
said, ipv6-only + nat64 only works well for most users (90+%).  For the long
tail, ipv4 services are not going away.

I believe that the user should be allowed to select their address family
easily ... this is easy in the mobile world.

Most folks (web and email) should not care if they have ipv4 + nat44 or ipv6
+ nat64. For those that do care, there are pros and cons to both. I prefer
the latter since it brings back e2e and is a positive incentive for ipv6
adoption

Cb
> Matthew Kaufman


From joelja at bogus.com  Sun May 15 12:22:56 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Sun, 15 May 2011 10:22:56 -0700
Subject: Backbone operators see IPv6 connectivity demand up,
	but little traffic
In-Reply-To: <20110515082913.GL4351@leitl.org>
References: <20110515082913.GL4351@leitl.org>
Message-ID: <C77F7125-63A5-4C71-8B72-582D31D48AA7@bogus.com>

You've got to get your backbone and transit enabled instrumented and stable before you put customers on it... that's a key in transitioning from an experiemental toy to something that you can actually use.

The current V6 deployement that I'm working on mirrors the previous 4 almost exactly in that regard. 

the v6 workshop at nanog 41 pretty much echoed that observation.

joel

On May 15, 2011, at 1:29 AM, Eugen Leitl wrote:

> 
> http://searchtelecom.techtarget.com/news/2240035722/Backbone-operators-see-IPv6-connectivity-demand-up-but-little-traffic
> 
> Backbone operators see IPv6 connectivity demand up, but little traffic
> 
> Internet backbone and wholesale carriers are anecdotally reporting a rapid
> rise in demand from their service provider customers for IPv6 connectivity?an
> apparent prelude to the full-scale arrival of the IPv6 Internet as World IPv6
> Day looms on the horizon. 
> 
> We've seen a tremendous increase in IPv6 traffic. Granted, though, it still
> comes nowhere near our traffic on v4.
> 
> Reid Fishler, director, Hurricane Electric
> 
> Backbone operators, however, acknowledge that the amount of IPv6 traffic
> still pales in comparison to that of its predecessor, IPv4, and that it's
> still too early to tell how quickly it will grow.
> 
> Hurricane Electric, which claims to operate the world's largest IPv6-native
> Internet backbone, has established three dual-stack (both IPv4 and IPv6)
> points of presence (POPs) at carrier hotels since March. Citing growing
> demand from operators for European peering points with IPv6 Internet
> connectivity, the wholesale provider connected its backbone to the Equinix
> Paris Exchange last week.
> 
> When Hurricane Electric offered native dual-stack services to carriers two
> years ago, few accepted them, according to Reid Fishler, director of carrier
> sales and purchasing at Hurricane Electric. Customers were confused or
> disinterested, but now "the vast majority" of service providers that are
> buying wholesale access at these Internet peering points are opting for
> dual-stack?and in rare cases, IPv6-only connections, he said.
> 
> "We've seen a tremendous increase in IPv6 traffic. Granted, though, it still
> comes nowhere near our traffic on v4," Fishler said. "But look at any one of
> these [Internet] exchange fabrics and compare v6 traffic to v4 traffic. Up
> until a year ago, you couldn't even rate [the amount of IPv6 traffic], and
> now you're starting to see it [on the Internet], and you definitely see a lot
> of the traffic coming in from China and Asia as v6 traffic now."
> 
> Hurricane Electric also established dual-stack POPs in Internet exchange
> point Telehouse Paris Voltaire and VegasNAP in Las Vegas in March. Late last
> year, demand for IPv6 Internet connectivity prompted Hurricane Electric's POP
> expansions into peering points Comfluent, in Denver; Equinix Singapore
> Exchange; and the Northwest Access Exchange in Portland, Ore.  More on IPv6
> connectivity
> 
> Get a telecom network architect's view on how to convert IPv4 to IPv6.
> 
> Learn why your telecom IPv6 transition plan must include more than upgrading
> your routers.
> 
> Find out how to make the IPv4 to IPv6 transition work.
> 
> If you can get your kids to eat their veggies, you can sell enterprises on
> IPv6 migration plans.
> 
> Shawn Morris, manager of IP development at NTT America, said IPv6 Internet
> traffic is still "a tiny fraction" of all Internet traffic, but NTT America
> has seen a steady increase of demand for and questions about IPv6
> connectivity from its carrier customers over the past few years. A large
> portion of the demand is coming from service providers in Latin America,
> which have been slower to adopt IPv6 than carriers in other regions, Morris
> said.
> 
> Demand for dual-stack peering at public Internet exchanges and at private
> peering points has also increased, said Morris, who oversees network
> architecture, hardware and software.
> 
> "I wouldn't say it's at parity with IPv6, but it's definitely trending in
> that direction," he said. "That's a big change. In ?03 and ?04, we went
> native [with IPv6 on our backbone] and were ready to peer with any of our
> peers, but it took a good six to seven years before we really saw an increase
> in demand."
> 
> More requests for IPv6 connectivity, but traffic barely materializing
> 
> NTT America could not provide any data regarding IPv6 Internet traffic
> levels. But in its search for a new network monitoring platform, one of its
> requirements was more granular visibility into levels of IPv4 and IPv6
> traffic, Morris said.
> 
> "We don't have any hard statistics ... but we definitely keep seeing more
> customers adding v6 onto their connections and an increase in the v6 routing
> table," he said. "But we're also expecting, to be honest, quite a bit of
> growth in the IPv4 routing table as people start to split up the address
> space in the run-out. So, we're planning for a large amount of growth in both
> tables."
> 
> Order requests for IPv6 connectivity have doubled every year for the past
> three years at Global Crossing, according to Anthony Christie, the backbone
> operator's chief technical and information officer. But that hasn't
> translated yet into any significant amount of IPv6 Internet traffic on Global
> Crossing's network, he said.
> 
> "The traffic that we're seeing would need to increase 100 times the current
> levels in order for it to be a meaningful percentage in total traffic,"
> Christie said. "The content, addresses and infrastructure associated with
> [IPv4] is not yet exhausted, so you wouldn't necessarily expect a switch to
> flick because someone has decided to order a v6 port on our network."
> 
> The American Registry of Internet Numbers (ARIN)?the Regional Internet
> Registry (RIR) for the United States, Canada and much of the Caribbean?has
> seen similar rates of growth in requests for IPv6 address space blocs,
> according to John Curran, president and CEO of ARIN. In 2008, ARIN received
> 250 requests for IPv6 address blocs from ISPs and hosting providers; in 2009,
> that rose to just above 400. Last year, ARIN received 700 requests. Within
> the first quarter of 2011, it has received 500 requests for IPv6 address
> blocs and expects that to total 1,500 by the end of the year, Curran said. 
> 
> "We've seen, for the last three years, the requests for IPv6 address space
> double," Curran said. "But that may not result in traffic."
> 
> Internet backbone provider Level 3 Communications, which recently announced
> its intention to buy Global Crossing, has seen similar IPv6 connectivity and
> traffic trends.
> 
> "Level 3 has witnessed growth in the number of IPv6 routes that are being
> advertised, but IPv6 routes still account for a very small portion of all
> Internet routes," said Mark Taylor, vice president of content and media at
> Level 3. "Likewise, even as IPv6 Internet traffic is on the rise, it is still
> small relative to the growth in address announcements."
> 
> What will spur growth of the IPv6 Internet?
> 
> Backbone operators don't doubt that the IPv6 Internet will grow?but how
> rapidly or under what conditions is anyone's guess.
> 
> Hurricane Electric's Fishler said he expects rapid growth will be spurred by
> consumer demand for a "killer application" that only functions on the IPv6
> Internet.
> 
> "If some large Internet-addressable service ... comes out and it needs to
> have 10,000 servers or whatever it needs, that next thing is going to
> [require] v6," he said. "That next product, whatever it'll be, will be IPv6
> primarily and IPv4 secondarily ... and that's when we're going to see IPv6
> take off, and that's when customers and service providers are going to be
> taken aback [if they can't] do it natively."
> 
> Morris, of NTT America, didn't rule out the IPv6 killer app theory but
> predicted more conservative, steady growth of the IPv6 Internet.
> 
> "We're going to see a more gradual increase in IPv6 traffic as time goes on,
> unless something comes along that's a killer app that's only available on
> IPv6," he said. "I honestly don't know what that would be ... but something
> like that might spurn a really quick uptake in IPv6. But what I think we're
> going to see is more and more organic growth."
> 




From nanog at jima.tk  Sun May 15 13:03:16 2011
From: nanog at jima.tk (Jima)
Date: Sun, 15 May 2011 13:03:16 -0500
Subject: Yahoo and IPv6
In-Reply-To: <4DCFF136.8040102@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
Message-ID: <4DD01564.5020607@jima.tk>

On 2011-05-15 10:28, Matthew Kaufman wrote:
> On 5/15/2011 6:49 AM, Cameron Byrne wrote:
>> We have agreed to disagree on the value of this before. Sorry your not
>> so popular protocol is going the way of EGP .... it's just not fit for
>> the evolving internet and will be subject to natural deselction. I am
>> sure you will disagree with that and insist every end user must always
>> support ipv4 because rtmfp is top of mind for so many users .... but
>> we can leave it at that ....please
>
> ...and we'll agree to disagree on this one (RTMFP)... and users will
> just be ok with BitTorrent and Skype not working on the v6-only + NAT64
> networks you're building, I suppose?

  BitTorrent tends to be an evolving protocol, with lots of clients 
competing for mindshare; I'm not certain that limitation will remain. 
As for Skype, it seems like that is potentially a business decision on 
Microsoft's behalf.  With the money they may be sinking into the 
technology, I would contend they have something to lose by not making it 
work.
  As has been discussed at length on this list, this is NOT an unfixable 
issue.

      Jima



From iljitsch at muada.com  Sun May 15 14:33:31 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sun, 15 May 2011 21:33:31 +0200
Subject: Yahoo and IPv6
In-Reply-To: <4DCF56BC.8070209@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>
	<4DCF2F5C.8030104@jima.tk> <4DCF56BC.8070209@matthew.at>
Message-ID: <D17FC9C5-F431-476A-92D1-66DEC70B9EF2@muada.com>

On 15 mei 2011, at 6:29, Matthew Kaufman wrote:

> And that would be the fault of NAT64, which for all of the  
> applications I mentioned (and more) made the seriously wrong  
> assumption that every IPv4 address is looked up in a DNS server.

This brings to mind the story of the physicist (but it could easily  
have be an IETF protocol engineer) who was scrambling around under a  
lamp post at night. A passer by asked what he was doing: looking for  
my keys. Are you sure you lost them here? No, but under the light is  
the only place I have a chance at finding them.

It's not that the people involved with NAT64 (full disclosure, I'm one  
of them) thought that every IPv4 address would have a working DNS  
name, but rather that using the DNS made it possible to have a  
transition mechanism that lets unmodified IPv6 hosts talk to  
unmodified IPv4 hosts.

However, all is not lost: you can easily set up sessions through a  
NAT64 if the application (or the system, but that will take longer to  
materialize) learns the other 96 bits and stuffs them in front of the  
IPv4 bits. If the NAT64 uses the well known prefix the 96 bits are  
easy to learn, if it does not you'll need another mechanism, which are  
now being discussed. But an application could easily roll its own by  
looking up a known IPv6-only A record and then taking the 96 bits from  
the resulting AAAA record.



From iljitsch at muada.com  Sun May 15 14:48:38 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sun, 15 May 2011 21:48:38 +0200
Subject: Yahoo and IPv6
In-Reply-To: <4DD01564.5020607@jima.tk>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at> <4DD01564.5020607@jima.tk>
Message-ID: <DC834B58-2280-4ECD-AB43-19ABBF626F20@muada.com>

On 15 mei 2011, at 20:03, Jima wrote:

> BitTorrent tends to be an evolving protocol, with lots of clients  
> competing for mindshare; I'm not certain that limitation will remain.

Two years ago the Pirate Bay got on IPv6 in a way that was  
incompatible with existing clients that were IP version agnostic for  
lengthy reasons. (They decided you should have an IPv4 connection to  
the tracker (central server) to learn IPv4 peer addresses and an IPv6  
connection to learn IPv6 peer addresses.)

Then their legal troubles got serious and I'm guessing they find it  
hard enough to move their IPv4 address(es?) around so they're IPv4- 
only again. They also want to move away from having trackers at all,  
and instead use a peer-to-peer based system (DHT) to find peers.

Until about a year ago I regulary saw 6to4 addresses showing up  
through the DHT but that has stopped. And rarely, if ever, would it be  
possible to connect to those addresses, anyway. Not sure what changed,  
maybe my software is too old, I'm on the wrong DHT or whatever.

Interestingly, BitTorrent can easily be modified to use the IETF NAT  
traversal techniques (STUN/TURN/ICE) and these are also largely  
compatible with NAT64. (Because unlike exiting NAT, NAT64 came about  
through the IETF process rather than organically, it probably has the  
tightest specifications of any type of NAT.) So you could run  
BitTorrent behind a NAT64 and not even exhaust the NAT64's port  
numbers. But for that, the BitTorrent application developers need to  
do some work, which they probably won't be able to do successfully  
until they can test against a fully RFC-conforming NAT64 translator.




From caldcv at gmail.com  Sun May 15 14:58:28 2011
From: caldcv at gmail.com (Chris)
Date: Sun, 15 May 2011 15:58:28 -0400
Subject: GoDaddy abuse contact
Message-ID: <BANLkTimEMeLes8MePABV1UnV2JA01RDmTg@mail.gmail.com>

Does anyone have a better abuse contact for GoDaddy? I'm trying to get
one of those "paste Javascript in your browser address bar" scams on
Facebook shutdown before too many idiots fall for it.


-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton



From askoorb+nanog at gmail.com  Sun May 15 15:11:22 2011
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Sun, 15 May 2011 21:11:22 +0100
Subject: GoDaddy abuse contact
In-Reply-To: <BANLkTimEMeLes8MePABV1UnV2JA01RDmTg@mail.gmail.com>
References: <BANLkTimEMeLes8MePABV1UnV2JA01RDmTg@mail.gmail.com>
Message-ID: <BANLkTi=WgqK3Ey3WdF7TscU-V5KvFYFjnA@mail.gmail.com>

On Sun, May 15, 2011 at 8:58 PM, Chris <caldcv at gmail.com> wrote:
> Does anyone have a better abuse contact for GoDaddy? I'm trying to get
> one of those "paste Javascript in your browser address bar" scams on
> Facebook shutdown before too many idiots fall for it.

The only way I've ever got a response from them is from:
https://supportcenter.godaddy.com/Abuse/SpamReport.aspx though it will
take a few days.

Their abuse@ seems to be ignored by actual people, but that is pretty
standard from the 'big boys' these days.

If it's an emergency, try ringing +1-480-624-2505

Good luck!

Alex



From tammy-lists at wiztech.biz  Sun May 15 15:27:00 2011
From: tammy-lists at wiztech.biz (Tammy A Wisdom)
Date: Sun, 15 May 2011 14:27:00 -0600
Subject: GoDaddy abuse contact
In-Reply-To: <BANLkTi=WgqK3Ey3WdF7TscU-V5KvFYFjnA@mail.gmail.com>
References: <BANLkTimEMeLes8MePABV1UnV2JA01RDmTg@mail.gmail.com>
	<BANLkTi=WgqK3Ey3WdF7TscU-V5KvFYFjnA@mail.gmail.com>
Message-ID: <710CB7F4-8C1D-4F1D-A00B-74ADD6C52F8B@wiztech.biz>

Trying to get them to do anything is a waste of time. They refuse to enforce their TOS and will tell you that if you call.
Tammy of the AHBL


Sent from my iPhone

On May 15, 2011, at 14:11, Alex Brooks <askoorb+nanog at gmail.com> wrote:

> On Sun, May 15, 2011 at 8:58 PM, Chris <caldcv at gmail.com> wrote:
>> Does anyone have a better abuse contact for GoDaddy? I'm trying to get
>> one of those "paste Javascript in your browser address bar" scams on
>> Facebook shutdown before too many idiots fall for it.
> 
> The only way I've ever got a response from them is from:
> https://supportcenter.godaddy.com/Abuse/SpamReport.aspx though it will
> take a few days.
> 
> Their abuse@ seems to be ignored by actual people, but that is pretty
> standard from the 'big boys' these days.
> 
> If it's an emergency, try ringing +1-480-624-2505
> 
> Good luck!
> 
> Alex
> 

******************************************************************************
Disclaimer:

This e-mail may contain trade secrets or privileged, undisclosed or 
otherwise confidential information. If you have received this e-mail 
in error, you are hereby notified that any review, copying or 
distribution of it is strictly prohibited. Please inform us 
immediately and destroy the original transmittal. Thank you for your 
cooperation.

******************************************************************************




From trelane at trelane.net  Sun May 15 15:29:54 2011
From: trelane at trelane.net (Andrew Kirch)
Date: Sun, 15 May 2011 16:29:54 -0400
Subject: GoDaddy abuse contact
In-Reply-To: <710CB7F4-8C1D-4F1D-A00B-74ADD6C52F8B@wiztech.biz>
References: <BANLkTimEMeLes8MePABV1UnV2JA01RDmTg@mail.gmail.com>	<BANLkTi=WgqK3Ey3WdF7TscU-V5KvFYFjnA@mail.gmail.com>
	<710CB7F4-8C1D-4F1D-A00B-74ADD6C52F8B@wiztech.biz>
Message-ID: <4DD037C2.7040208@trelane.net>

On 5/15/2011 4:27 PM, Tammy A Wisdom wrote:
> Trying to get them to do anything is a waste of time. They refuse to enforce their TOS and will tell you that if you call.
> Tammy of the AHBL
>
>
> Sent from my iPhone
Yep, Godaddy abuse = big dark nothing into which complaints enter... and
then are never heard from again.  I suggest sending their traffic to the
same bitbucket your complaints went to.

Andrew



From owen at delong.com  Sun May 15 21:06:54 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 15 May 2011 19:06:54 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>
	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>
	<4DC83C4B.5080703@dougbarton.us>
	<120501cc0e81$0222b1e0$066815a0$@net>
	<4DC8476F.2070905@dougbarton.us>
	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>
	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>
	<9099.1305038200@localhost>
	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>
	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>
	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>
	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>
	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>
	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>
	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>
	<4DCEC578.9060308@matthew.at> <4DCF2F5C.8030104@jima.tk>
	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
Message-ID: <4245C45B-57F4-4D97-AB63-1D0851D36247@delong.com>

> e have agreed to disagree on the value of this before.  Sorry your not so
> popular protocol is going the way of EGP .... it's just not fit for the
> evolving internet and will be subject to natural deselction. I am sure you
> will disagree with that and insist every end user must always support ipv4
> because rtmfp is top of mind for so many users .... but we can leave it at
> that ....please
> 
Which not-so-popular protocol are you referring to here?

SIP?
Skype?
The protocol behind most Flash Players?
Jabber?

I think many of those are relatively popular and are unlikely to experience
this natural deselection of which you speak.

I think deprecation of IPv4 is going to happen simply because it will hit
several walls in terms of scaling and the cost of continuing to support it
will exceed the utility, but, this will have little to do with any particular
subset of IPv4 uses and more to do with the overall picture.

Owen




From owen at delong.com  Sun May 15 21:08:40 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 15 May 2011 19:08:40 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DCFF136.8040102@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
Message-ID: <C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>


On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:

> On 5/15/2011 6:49 AM, Cameron Byrne wrote:
>> 
>> 
>> On May 14, 2011 9:30 PM, "Matthew Kaufman" <matthew at matthew.at <mailto:matthew at matthew.at>> wrote:
>> >
>> 
>> >
>> > Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk to SIP phones on an IP4-only network.
>> >
>> 
>> Right, that is why we have SBC / b2bue for the cases we want to work.
>> 
> 
> Ok, so you concede that NAT64 requires yet another device at the edge to make the SIP phones work...
>> 
>> 
>> We have agreed to disagree on the value of this before.  Sorry your not so popular protocol is going the way of EGP .... it's just not fit for the evolving internet and will be subject to natural deselction. I am sure you will disagree with that and insist every end user must always support ipv4 because rtmfp is top of mind for so many users .... but we can leave it at that ....please
>> 
>> 
> 
> ...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?
> 
> Matthew Kaufman

Uh, BitTorrent works just fine for me on IPv6.

Owen




From matthew at matthew.at  Sun May 15 22:55:39 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 15 May 2011 20:55:39 -0700
Subject: Yahoo and IPv6
In-Reply-To: <C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
	<C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
Message-ID: <4DD0A03B.5080906@matthew.at>

On 5/15/2011 7:08 PM, Owen DeLong wrote:
> On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:
>
>
>> ...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?
>>
>> Matthew Kaufman
> Uh, BitTorrent works just fine for me on IPv6.

And how many v4-only nodes are you reaching from your v6-only client 
through a NAT64?

Matthew Kaufman



From gbonser at seven.com  Sun May 15 23:04:17 2011
From: gbonser at seven.com (George Bonser)
Date: Sun, 15 May 2011 21:04:17 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD0A03B.5080906@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at><BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com><4DCFF136.8040102@matthew.at><C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
	<4DD0A03B.5080906@matthew.at>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E328D@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: Matthew Kaufman [mailto:matthew at matthew.at]
> Sent: Sunday, May 15, 2011 8:56 PM
> To: Owen DeLong
> Cc: nanog at nanog.org
> Subject: Re: Yahoo and IPv6
> 
> On 5/15/2011 7:08 PM, Owen DeLong wrote:
> > On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:
> >
> >
> >> ...and we'll agree to disagree on this one (RTMFP)... and users
will
> just be ok with BitTorrent and Skype not working on the v6-only +
NAT64
> networks you're building, I suppose?
> >>
> >> Matthew Kaufman
> > Uh, BitTorrent works just fine for me on IPv6.
> 
> And how many v4-only nodes are you reaching from your v6-only client
> through a NAT64?

Should be able to reach all of them if it is combined with DNS64




From marka at isc.org  Sun May 15 23:57:52 2011
From: marka at isc.org (Mark Andrews)
Date: Mon, 16 May 2011 14:57:52 +1000
Subject: Interested in input on tunnels as an IPv6 transition technology
In-Reply-To: Your message of "Fri, 13 May 2011 10:56:11 MST."
	<03a401cc1197$0ceec410$26cc4c30$@net>
References: <1305265953.18376.1032.camel@karl>
	<03a401cc1197$0ceec410$26cc4c30$@net>
Message-ID: <20110516045752.B0A1CEC254B@drugs.dv.isc.org>


In message <03a401cc1197$0ceec410$26cc4c30$@net>, "Tony Hain" writes:
> 6rd
> designed as a derivative of 6to4 to explicitly remove the /16 =
> restriction in IPv6 BGP advertisements because changing that one line =
> would have taken longer to get agreement on than an entirely new design, =
> implementation, and deployment sequence (note that this will result in =
> just as many IPv6 prefix announcements into BGP as fragmenting 2002:: =
> would have, so the arguments about modifying 3056 are moot). Requires =
> that each provider have a large enough allocation to embed the uniquely =
> identifying parts of their IPv4 space into each 6rd address block, which =
> is a challenge with existing IPv6 allocation policies. It does align the =
> tunnel endpoints with the access infrastructure that is being overlaid, =
> at least at the organizational level. Does require CPE capable of =
> sorting out which set of IPv4 address bits should be concatenated with =
> the IPv6 pop prefix to create the ultimate IPv6 prefix for that CPE.=20

6rd doesn't have to add any extra routes to the global routing
table.

As for adding more specific routes to 2002::/16, a operator would
need a route for each IPv4 cidr netblock they offer 6to4 on to avoid
the use of 3rd party relays.  That being said ther routes should
only be there between the time the operator brings up the 6to4
relays as a initial transition service and the time they deploy
IPv6 natively.  After that they would most probably still run reverse
path relay covering all of 2002::/16.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From eugen at leitl.org  Mon May 16 01:22:48 2011
From: eugen at leitl.org (Eugen Leitl)
Date: Mon, 16 May 2011 08:22:48 +0200
Subject: reporting Swiss Money Report?
Message-ID: <20110516062248.GC4351@leitl.org>


The notorious fax spammer (Swiss Money Report,
European Money Report, etc; Altanus Ltd.) is
currently residing in 91.223.119/24
(91.223.119.174), which is registered to
Traian Zoran Tariceanu, First Media Service Ltd.

The contacts at @fmsss.info bounce. What is the
proper channel for reporting these people? Thanks!

Regards,
Eugen Leitl



From fweimer at bfk.de  Mon May 16 02:10:34 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 16 May 2011 07:10:34 +0000
Subject: reporting Swiss Money Report?
In-Reply-To: <20110516062248.GC4351@leitl.org> (Eugen Leitl's message of "Mon, 
	16 May 2011 08:22:48 +0200")
References: <20110516062248.GC4351@leitl.org>
Message-ID: <82mxinxgr9.fsf@mid.bfk.de>

* Eugen Leitl:

> The notorious fax spammer (Swiss Money Report,
> European Money Report, etc; Altanus Ltd.) is
> currently residing in 91.223.119/24
> (91.223.119.174), which is registered to
> Traian Zoran Tariceanu, First Media Service Ltd.
>
> The contacts at @fmsss.info bounce. What is the
> proper channel for reporting these people? Thanks!

Ask RIPE NCC, they have the RIPE member who requested the PI space on
record.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99



From owen at delong.com  Mon May 16 02:31:07 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 16 May 2011 00:31:07 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD0A03B.5080906@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
	<C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
	<4DD0A03B.5080906@matthew.at>
Message-ID: <91DA9423-7BCB-4874-A19C-B91BA34DFBA3@delong.com>


On May 15, 2011, at 8:55 PM, Matthew Kaufman wrote:

> On 5/15/2011 7:08 PM, Owen DeLong wrote:
>> On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:
>> 
>> 
>>> ...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?
>>> 
>>> Matthew Kaufman
>> Uh, BitTorrent works just fine for me on IPv6.
> 
> And how many v4-only nodes are you reaching from your v6-only client through a NAT64?
> 
> Matthew Kaufman

I have dual stack, so, I don't bother with NAT64. However, I believe that the BitTorrent clients
are smart enough to discard the IPv4 nodes reached through NAT64 and will, instead, just
use the native IPv6 nodes. I don't see this as a problem and I"m not sure why you do.

Owen




From iljitsch at muada.com  Mon May 16 03:56:34 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 16 May 2011 10:56:34 +0200
Subject: Yahoo and IPv6
In-Reply-To: <91DA9423-7BCB-4874-A19C-B91BA34DFBA3@delong.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
	<C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
	<4DD0A03B.5080906@matthew.at> <91DA9!
	423-7BCB-4874-A19C-B91BA34DFBA3@delong.com>
Message-ID: <CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>

On 16 mei 2011, at 9:31, Owen DeLong wrote:

> I believe that the BitTorrent clients
> are smart enough to discard the IPv4 nodes reached through NAT64 and will, instead, just
> use the native IPv6 nodes. I don't see this as a problem and I"m not sure why you do.

Because that way the IPv4 and IPv6 swarms remain disconnected in the absence of some dual stack peers. (I.e., if the swarm is small and you're the only IPv6 participant.)

It would be much better if you could go from IPv6 to IPv4 through a NAT64.


From gbonser at seven.com  Mon May 16 04:10:12 2011
From: gbonser at seven.com (George Bonser)
Date: Mon, 16 May 2011 02:10:12 -0700
Subject: Yahoo and IPv6
In-Reply-To: <CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at><BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com><4DCFF136.8040102@matthew.at><C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com><4DD0A03B.5080906@matthew.at>
	<91DA9!423-7BCB-487 4-A19C-B91BA
	34DFBA3@delong.com> <CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3290@RWC-EX1.corp.seven.com>

> 
> Because that way the IPv4 and IPv6 swarms remain disconnected in the
> absence of some dual stack peers. (I.e., if the swarm is small and
> you're the only IPv6 participant.)
> 
> It would be much better if you could go from IPv6 to IPv4 through a
> NAT64.

The problem is when the client is handed an explicit address rather than
a host name.  In that case, there needs to be some standard environment
variable for "IPv64 Prefix" that applications can query.

For a browser this might be something like the configured proxy.  Maybe
an OS such as Windows might have a registry value for this.  Maybe Linux
and other unix-like variations could have a sysctl for that.

There should be some standard way for a native v6 host to determine the
v6 to v4 prefix to use in a NAT64 environment.





From caldcv at gmail.com  Mon May 16 05:53:42 2011
From: caldcv at gmail.com (Chris)
Date: Mon, 16 May 2011 06:53:42 -0400
Subject: GoDaddy abuse contact
In-Reply-To: <Pine.LNX.4.64.1105151410140.24138@sasami.anime.net>
References: <BANLkTimEMeLes8MePABV1UnV2JA01RDmTg@mail.gmail.com>
	<BANLkTi=WgqK3Ey3WdF7TscU-V5KvFYFjnA@mail.gmail.com>
	<Pine.LNX.4.64.1105151410140.24138@sasami.anime.net>
Message-ID: <BANLkTiniJzM1rBJ5jR16BHbQYsqgB1c3+Q@mail.gmail.com>

The best abuse contact response I ever got was an under 3 hour reply
to a lesser known domain provider who revoked the domain for the
Facebook scam. It was hilarious and I don't think even GoDaddy
responded within 3 days or so.

A part of me wants to say we should look out for people while another
part wants to chalk it up to survival of the fittest. I just looked,
it's still up and running.

-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton



From joe.abley at icann.org  Mon May 16 06:36:00 2011
From: joe.abley at icann.org (Joe Abley)
Date: Mon, 16 May 2011 11:36:00 +0000
Subject: Root Zone DNSSEC KSK Ceremony 5
Message-ID: <E1QLw5g-000F3C-Ax@monster.hopcount.ca>

KSK CEREMONY 5

The fifth KSK ceremony for the root zone took place in Culpeper,
VA, USA on Wednesday 2011-05-11. The Ceremony Administrator was
Mehmet Akcin.  The ceremony was completed successfully.

Video from Ceremony 5 was recorded for audit purposes.  Video and
associated audit materials will be published in 1 to 2 weeks, and
will be available as usual by following the "KSK Ceremony Materials"
link at <https://www.iana.org/dnssec/>.

Ceremony 5 included processing of a Key Signing Request (KSR)
generated by VeriSign, and the resulting Signed Key Response (SKR)
contains signatures for Q3 2011.


CONTACT INFORMATION
 
We'd like to hear from you. If you have feedback for us, please
send it to rootsign at icann.org.




From arturo.servin at gmail.com  Mon May 16 09:25:15 2011
From: arturo.servin at gmail.com (Arturo Servin)
Date: Mon, 16 May 2011 09:25:15 -0500
Subject: Yahoo and IPv6
In-Reply-To: <4DD0A03B.5080906@matthew.at>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
	<C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
	<4DD0A03B.5080906@matthew.at>
Message-ID: <A18FBCB0-9550-44B9-A563-5F2C40976A24@gmail.com>


On 15 May 2011, at 22:55, Matthew Kaufman wrote:

> On 5/15/2011 7:08 PM, Owen DeLong wrote:
>> On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:
>> 
>> 
>>> ...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?
>>> 
>>> Matthew Kaufman
>> Uh, BitTorrent works just fine for me on IPv6.
> 
> And how many v4-only nodes are you reaching from your v6-only client through a NAT64?
> 
> Matthew Kaufman


	Many.

	For my web access habits it works perfectly fine.

-as





From tlyons at ivenue.com  Mon May 16 10:20:18 2011
From: tlyons at ivenue.com (Todd Lyons)
Date: Mon, 16 May 2011 08:20:18 -0700
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <4DCDA380.7020407@mompl.net>
References: <4DCD8087.9020402@mompl.net>
	<4DCDA380.7020407@mompl.net>
Message-ID: <BANLkTinvqPpZqFMqG0+izZSaTa+fxdgiNg@mail.gmail.com>

On Fri, May 13, 2011 at 2:32 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
>
> Something like:
> -I FORWARD -j DROP
> -I FORWARD -s 2001:db8::/64 -j ACCEPT
> -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Double check the kernel version you have.  IIRC kernels before 2.6.20
didn't have the ability to do RELATED,ESTABLISHED in ipv6.  This hit
me on a CentOS box that I was using as a gateway.  I am unaware if
there is a version of their 2.6.18 that has the patches backported
(googling seemed to indicate it has not been done, and most are just
waiting for new release of CentOS 6).  RH6 works properly.

-- 
Regards...? ? ? Todd
"It is the nature of the human species to reject what is true but
unpleasant and to embrace what is obviously false but comforting."
"You might be a skeptic if you have pedantically argued the topic of pedantry."



From jg at freedesktop.org  Mon May 16 13:37:46 2011
From: jg at freedesktop.org (Jim Gettys)
Date: Mon, 16 May 2011 14:37:46 -0400
Subject: Yahoo and IPv6
In-Reply-To: <8966.1305416364@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>
Message-ID: <4DD16EFA.2020207@freedesktop.org>

On 05/14/2011 07:39 PM, Paul Vixie wrote:
> Jim Gettys<jg at freedesktop.org>  writes:
>
>> ... we have to get naming squared away.  Typing IPv6 addresses is for the
>> birds, and having everyone have to go fuss with a DNS provider isn't a
>> viable solution.
> perhaps i'm too close to the problem because that solution looks quite
> viable to me.  dns providers who don't keep up with the market (which means
> ipv6 and dnssec in this context) will lose business to those who do.
I don't believe it is currently viable for any but the hackers out 
there, given my experience during the Comcast IPv6 trial.  Typing V6 
addresses (much less remembering them) is a PITA.

You are asking people who don't even know DNS exists, to bother to 
establish another business relationship (or maybe DNS services might 
someday be provided by their ISP).

If you get past that hurdle they get to type long IPv6 addresses into a 
web page they won't remember where it was the year before when they did 
this the last time to add a machine to their DNS.

The way this "ought" to work for clueless home users (or cluefull users 
too, for that matter) is that, when a new machine appears on a network, 
it "just works", by which I mean that a globally routeable IPv6 address 
appears in DNS without fussing around using the name that was given to 
the machine when it was first booted, and that a home user's names are 
accessible via secondaries even if they are off line.  And NXDOMAIN 
should work the way it was intended, for all the reasons you know better 
than I.

This is entirely possible ;-).  Just go ask Evan Hunt what he's been up 
to with Dave Taht recently....
                           - Jim


Right now, IPv6 is worse than IPv4 for home users; we need



From vixie at isc.org  Mon May 16 14:13:45 2011
From: vixie at isc.org (Paul Vixie)
Date: Mon, 16 May 2011 19:13:45 +0000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Mon, 16 May 2011 14:37:46 -0400."
	<4DD16EFA.2020207@freedesktop.org>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
Message-ID: <51008.1305573225@nsa.vix.com>

> Date: Mon, 16 May 2011 14:37:46 -0400
> From: Jim Gettys <jg at freedesktop.org>
> 
> > perhaps i'm too close to the problem because that solution looks quite
> > viable to me.  dns providers who don't keep up with the market (which
> > means ipv6+dnssec in this context) will lose business to those who do.
> 
> I don't believe it is currently viable for any but the hackers out there,
> given my experience during the Comcast IPv6 trial.  Typing V6 addresses
> (much less remembering them) is a PITA.

> You are asking people who don't even know DNS exists, to bother to
> establish another business relationship (or maybe DNS services might
> someday be provided by their ISP).

actually, i'm asking the opposite.  only hackers run their own dns mostly;
the vast majority of users who don't know what ipv6 or dnssec are, are
already outsourcing to ultradns/neustar, or verisign, or dyn.com, etc, or
for recursive they're using opendns, google dns, etc.  these companies can
either add the new services and do outreach to their customer bases, or
they can allow their competitors to do so.

of those who still run their own dns, the vast majority actually do know
the dnssec and ipv6 issues facing them.

> If you get past that hurdle they get to type long IPv6 addresses into a web
> page they won't remember where it was the year before when they did this
> the last time to add a machine to their DNS.

i've been using ipv6 dual stack for ten years at ISC and for one year at
home (i was comcast's first north american dual stack native customer) and
the only time i type long ipv6 addresses is when editing dns zone files or
configuring routers and hosts.  i think your experiences may have been
worse than mine and i'll be interested in knowing whether they're common.

> The way this "ought" to work for clueless home users (or cluefull users
> too, for that matter) is that, when a new machine appears on a network, it
> "just works", by which I mean that a globally routeable IPv6 address
> appears in DNS without fussing around using the name that was given to the
> machine when it was first booted, and that a home user's names are
> accessible via secondaries even if they are off line.

this is why ISC DHCP and ISC BIND can communicate using RFC 2136 DNS
dynamic updates, secured with RFC 2845 transaction signatures.  once you
get this running then you don't have to type ipv6 addresses anywhere.  and
i know that infoblox and other BIND Inside appliance vendors have the same
capability, and that Cisco and other DNS/DHCP vendors can also participate
in these open standards pretty much out of the box.  this is what i worked
on when i first found out about IETF back in 1995 or so.  it's all done now
you just have to learn it and deploy it.  (and if you don't think end users
ought to have to learn how to configure their DHCP to talk to their DNS,
i will point them at a half dozen appliance and outsourcing vendors who can
take the ones and zeroes out of this for them.)

> And NXDOMAIN should work the way it was intended, for all the reasons
> you know better than I.

while i agree, i don't think the people who are substituting positive
responses for NXDOMAIN care at all what you think or what i think, so i'm
going to focus on what can be done which is advancing robust solutions.

> This is entirely possible ;-).  Just go ask Evan Hunt what he's been up to
> with Dave Taht recently....

more appliance vendors including open source are definitely welcome.  the
pool is large enough for everybody to swim in it.



From linux.yahoo at gmail.com  Mon May 16 15:02:01 2011
From: linux.yahoo at gmail.com (Manu Chao)
Date: Mon, 16 May 2011 22:02:01 +0200
Subject: 1000BaseT Ethernet keepalives (Ethertype 0x9000)
Message-ID: <BANLkTi=Rq5SWte=X+dTHkot2rn5FH6yEyA@mail.gmail.com>

I am curious to understand how copper Ethernet keepalive are used and work
between a host or router and a switch?

Cisco default keepalive is 10 seconds with 3 or 5 retries, does this mean
30s or 50s to detect copper link failure??

I may miss something, thanks for your help.

The link failure detection doesn't occur with optical links because hardware
detection (Rx < Rx_min) is much more real time than keepalive timeout
expiration.

R/
Manu


From owen at delong.com  Mon May 16 17:43:35 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 16 May 2011 15:43:35 -0700
Subject: Yahoo and IPv6
In-Reply-To: <CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at>
	<BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com>
	<4DCFF136.8040102@matthew.at>
	<C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com>
	<4DD0A03B.5080906@matthew.at> <91DA9!
	! 423-7BCB-4874-A19C-B91BA34DFBA3@delong.com>
	<CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>
Message-ID: <2713A5D4-D4E7-49B3-8C73-3712B074996A@delong.com>


On May 16, 2011, at 1:56 AM, Iljitsch van Beijnum wrote:

> On 16 mei 2011, at 9:31, Owen DeLong wrote:
> 
>> I believe that the BitTorrent clients
>> are smart enough to discard the IPv4 nodes reached through NAT64 and will, instead, just
>> use the native IPv6 nodes. I don't see this as a problem and I"m not sure why you do.
> 
> Because that way the IPv4 and IPv6 swarms remain disconnected in the absence of some dual stack peers. (I.e., if the swarm is small and you're the only IPv6 participant.)
> 
> It would be much better if you could go from IPv6 to IPv4 through a NAT64.

Meh, a very short term problem at worst.

Owen




From owen at delong.com  Mon May 16 17:44:58 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 16 May 2011 15:44:58 -0700
Subject: Yahoo and IPv6
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3290@RWC-EX1.corp.seven.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at><BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com><4DCFF136.8040102@matthew.at><C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com><4DD0A03B.5080906@matthew.at>
	<91DA9!423! -7BCB-487 4-A19C-B91BA 34DFBA3@delong.com>
	<CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3290@RWC-EX1.corp.seven.com>
Message-ID: <C8C180AF-4BC9-44DB-95C8-B52F39019D63@delong.com>


On May 16, 2011, at 2:10 AM, George Bonser wrote:

>> 
>> Because that way the IPv4 and IPv6 swarms remain disconnected in the
>> absence of some dual stack peers. (I.e., if the swarm is small and
>> you're the only IPv6 participant.)
>> 
>> It would be much better if you could go from IPv6 to IPv4 through a
>> NAT64.
> 
> The problem is when the client is handed an explicit address rather than
> a host name.  In that case, there needs to be some standard environment
> variable for "IPv64 Prefix" that applications can query.
> 
> For a browser this might be something like the configured proxy.  Maybe
> an OS such as Windows might have a registry value for this.  Maybe Linux
> and other unix-like variations could have a sysctl for that.
> 
It shouldn't be a sysctl. It should be more like resolv.conf at worst.

> There should be some standard way for a native v6 host to determine the
> v6 to v4 prefix to use in a NAT64 environment.
> 

This assumes some standard way to do NAT64.

Owen




From Bryan.Welch at arrisi.com  Mon May 16 18:15:45 2011
From: Bryan.Welch at arrisi.com (Welch, Bryan)
Date: Mon, 16 May 2011 16:15:45 -0700
Subject: Experience with Open Source load balancers?
Message-ID: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>

Greetings all.

I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use.  We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions.  These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.

Now my "knee jerk" reaction to this is that it's a really bad idea.  It is the heart and soul of our data center network after all.  However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.

Can anyone offer any operational insight and real world experiences with these solutions?

TIA, replies off list are welcomed.


Regards,

Bryan



From owen at delong.com  Mon May 16 18:12:27 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 16 May 2011 16:12:27 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD16EFA.2020207@freedesktop.org>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com> <4DD16EFA.2020207@freedesktop.org>
Message-ID: <2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>


On May 16, 2011, at 11:37 AM, Jim Gettys wrote:

> On 05/14/2011 07:39 PM, Paul Vixie wrote:
>> Jim Gettys<jg at freedesktop.org>  writes:
>> 
>>> ... we have to get naming squared away.  Typing IPv6 addresses is for the
>>> birds, and having everyone have to go fuss with a DNS provider isn't a
>>> viable solution.
>> perhaps i'm too close to the problem because that solution looks quite
>> viable to me.  dns providers who don't keep up with the market (which means
>> ipv6 and dnssec in this context) will lose business to those who do.
> I don't believe it is currently viable for any but the hackers out there, given my experience during the Comcast IPv6 trial.  Typing V6 addresses (much less remembering them) is a PITA.
> 
> You are asking people who don't even know DNS exists, to bother to establish another business relationship (or maybe DNS services might someday be provided by their ISP).
> 
> If you get past that hurdle they get to type long IPv6 addresses into a web page they won't remember where it was the year before when they did this the last time to add a machine to their DNS.
> 
> The way this "ought" to work for clueless home users (or cluefull users too, for that matter) is that, when a new machine appears on a network, it "just works", by which I mean that a globally routeable IPv6 address appears in DNS without fussing around using the name that was given to the machine when it was first booted, and that a home user's names are accessible via secondaries even if they are off line.  And NXDOMAIN should work the way it was intended, for all the reasons you know better than I.
> 
> This is entirely possible ;-).  Just go ask Evan Hunt what he's been up to with Dave Taht recently....
>                          - Jim
> 
> 
> Right now, IPv6 is worse than IPv4 for home users; we need

How so? It's not like you can even reach anything at home now, 
let alone reach it by name.

Owen




From marka at isc.org  Mon May 16 18:19:43 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 17 May 2011 09:19:43 +1000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Mon, 16 May 2011 19:13:45 GMT."
	<51008.1305573225@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org> <51008.1305573225@nsa.vix.com>
Message-ID: <20110516231943.8FADEEC3954@drugs.dv.isc.org>


In message <51008.1305573225 at nsa.vix.com>, Paul Vixie writes:
> > Date: Mon, 16 May 2011 14:37:46 -0400
> > From: Jim Gettys <jg at freedesktop.org>
> > 
> > > perhaps i'm too close to the problem because that solution looks quite
> > > viable to me.  dns providers who don't keep up with the market (which
> > > means ipv6+dnssec in this context) will lose business to those who do.
> > 
> > I don't believe it is currently viable for any but the hackers out there,
> > given my experience during the Comcast IPv6 trial.  Typing V6 addresses
> > (much less remembering them) is a PITA.
> 
> > You are asking people who don't even know DNS exists, to bother to
> > establish another business relationship (or maybe DNS services might
> > someday be provided by their ISP).
> 
> actually, i'm asking the opposite.  only hackers run their own dns mostly;
> the vast majority of users who don't know what ipv6 or dnssec are, are
> already outsourcing to ultradns/neustar, or verisign, or dyn.com, etc, or
> for recursive they're using opendns, google dns, etc.  these companies can
> either add the new services and do outreach to their customer bases, or
> they can allow their competitors to do so.
> 
> of those who still run their own dns, the vast majority actually do know
> the dnssec and ipv6 issues facing them.
> 
> > If you get past that hurdle they get to type long IPv6 addresses into a web
> > page they won't remember where it was the year before when they did this
> > the last time to add a machine to their DNS.
> 
> i've been using ipv6 dual stack for ten years at ISC and for one year at
> home (i was comcast's first north american dual stack native customer) and
> the only time i type long ipv6 addresses is when editing dns zone files or
> configuring routers and hosts.  i think your experiences may have been
> worse than mine and i'll be interested in knowing whether they're common.
> 
> > The way this "ought" to work for clueless home users (or cluefull users
> > too, for that matter) is that, when a new machine appears on a network, it
> > "just works", by which I mean that a globally routeable IPv6 address
> > appears in DNS without fussing around using the name that was given to the
> > machine when it was first booted, and that a home user's names are
> > accessible via secondaries even if they are off line.
> 
> this is why ISC DHCP and ISC BIND can communicate using RFC 2136 DNS
> dynamic updates, secured with RFC 2845 transaction signatures.  once you
> get this running then you don't have to type ipv6 addresses anywhere.  and
> i know that infoblox and other BIND Inside appliance vendors have the same
> capability, and that Cisco and other DNS/DHCP vendors can also participate
> in these open standards pretty much out of the box.  this is what i worked
> on when i first found out about IETF back in 1995 or so.  it's all done now
> you just have to learn it and deploy it.  (and if you don't think end users
> ought to have to learn how to configure their DHCP to talk to their DNS,
> i will point them at a half dozen appliance and outsourcing vendors who can
> take the ones and zeroes out of this for them.)

Or the host can talk directly to the DNS server.  TSIG can scale
up to millions of clients with their own keys which may or may not
be share between machines.  Just because nameservers currently have
the keys in flat configuration files doesn't mean that it has to
stay that way.  The keys could just as easily be in a seperate
database which the nameserver only reads.  Similarly SIG(0) could
be used using KEY records stored in the DNS itself.

I believe MacOS already supports TSIG directly though they don't
call it that.  Windows could also add support to TSIG in addition
to GSS-TSIG for the non enterprise customers.  This really isn't
hard. You just store a keyname/secret pair for the machine to use
at boot time.  MacOS calls is account/password from memory.

The hard part is convincing people to do it by default.  This is
nothing more than what the dynamic DNS vendors have been doing for
the last decade.  If you want a custom zone you pay $X per month
extra otherwise you get the default zone for the ISP which doesn't
have to be the ISP's zone.

	 machine{.subdomain}*.<cust-unique>.example.net

And as the updates are signed you can accept them from anywhere in
the world.

> > And NXDOMAIN should work the way it was intended, for all the reasons
> > you know better than I.
> 
> while i agree, i don't think the people who are substituting positive
> responses for NXDOMAIN care at all what you think or what i think, so i'm
> going to focus on what can be done which is advancing robust solutions.
> 
> > This is entirely possible ;-).  Just go ask Evan Hunt what he's been up to
> > with Dave Taht recently....
> 
> more appliance vendors including open source are definitely welcome.  the
> pool is large enough for everybody to swim in it.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From dmiller at tiggee.com  Mon May 16 18:23:06 2011
From: dmiller at tiggee.com (David Miller)
Date: Mon, 16 May 2011 19:23:06 -0400
Subject: Yahoo and IPv6
In-Reply-To: <51008.1305573225@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>
	<51008.1305573225@nsa.vix.com>
Message-ID: <4DD1B1DA.2010300@tiggee.com>

On 5/16/2011 3:13 PM, Paul Vixie wrote:
>> Date: Mon, 16 May 2011 14:37:46 -0400
>> From: Jim Gettys<jg at freedesktop.org>
>>
>>> perhaps i'm too close to the problem because that solution looks quite
>>> viable to me.  dns providers who don't keep up with the market (which
>>> means ipv6+dnssec in this context) will lose business to those who do.
>> I don't believe it is currently viable for any but the hackers out there,
>> given my experience during the Comcast IPv6 trial.  Typing V6 addresses
>> (much less remembering them) is a PITA.
>> You are asking people who don't even know DNS exists, to bother to
>> establish another business relationship (or maybe DNS services might
>> someday be provided by their ISP).
> actually, i'm asking the opposite.  only hackers run their own dns mostly;
> the vast majority of users who don't know what ipv6 or dnssec are, are
> already outsourcing to ultradns/neustar, or verisign, or dyn.com, etc, or

I think that what you probably meant to say was:
"... outsourcing to Affilias, Amazon Route 53, DNS Made Easy, DNS.com, 
Dyn/Dynect, EasyDNS, GoDaddy, Netriplex, UltraDNS, Verisign, Zerigo, etc."

^^ Those are the commercial anycast DNS services that I know of 
presented in a simple non-preferential alphabetical order.

I happen to know, because I did parts of the implementation, that DNS 
Made Easy provides anycast IPv6 DNS to all customers (available on all 
servers if they like).


> for recursive they're using opendns, google dns, etc.  these companies can
> either add the new services and do outreach to their customer bases, or
> they can allow their competitors to do so.
>
> of those who still run their own dns, the vast majority actually do know
> the dnssec and ipv6 issues facing them.
>
>> If you get past that hurdle they get to type long IPv6 addresses into a web
>> page they won't remember where it was the year before when they did this
>> the last time to add a machine to their DNS.
> i've been using ipv6 dual stack for ten years at ISC and for one year at
> home (i was comcast's first north american dual stack native customer) and
> the only time i type long ipv6 addresses is when editing dns zone files or
> configuring routers and hosts.  i think your experiences may have been
> worse than mine and i'll be interested in knowing whether they're common.
>
>> The way this "ought" to work for clueless home users (or cluefull users
>> too, for that matter) is that, when a new machine appears on a network, it
>> "just works", by which I mean that a globally routeable IPv6 address
>> appears in DNS without fussing around using the name that was given to the
>> machine when it was first booted, and that a home user's names are
>> accessible via secondaries even if they are off line.
> this is why ISC DHCP and ISC BIND can communicate using RFC 2136 DNS
> dynamic updates, secured with RFC 2845 transaction signatures.  once you
> get this running then you don't have to type ipv6 addresses anywhere.  and
> i know that infoblox and other BIND Inside appliance vendors have the same
> capability, and that Cisco and other DNS/DHCP vendors can also participate
> in these open standards pretty much out of the box.  this is what i worked
> on when i first found out about IETF back in 1995 or so.  it's all done now
> you just have to learn it and deploy it.  (and if you don't think end users
> ought to have to learn how to configure their DHCP to talk to their DNS,
> i will point them at a half dozen appliance and outsourcing vendors who can
> take the ones and zeroes out of this for them.)
>
>> And NXDOMAIN should work the way it was intended, for all the reasons
>> you know better than I.
> while i agree, i don't think the people who are substituting positive
> responses for NXDOMAIN care at all what you think or what i think, so i'm
> going to focus on what can be done which is advancing robust solutions.
>
>> This is entirely possible ;-).  Just go ask Evan Hunt what he's been up to
>> with Dave Taht recently....
> more appliance vendors including open source are definitely welcome.  the
> pool is large enough for everybody to swim in it.
>




From wcooper02 at gmail.com  Mon May 16 18:37:22 2011
From: wcooper02 at gmail.com (William Cooper)
Date: Mon, 16 May 2011 19:37:22 -0400
Subject: Experience with Open Source load balancers?
In-Reply-To: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
Message-ID: <BANLkTik8QgKohSKZRoCWFkD87656BKR3AQ@mail.gmail.com>

S/W vs H/W is really a question rooted in performance and feature
needs vs cost... weigh your options carefully.

On Mon, May 16, 2011 at 7:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com> wrote:
> Greetings all.
>
> I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use. ?We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions. ?These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.
>
> Now my "knee jerk" reaction to this is that it's a really bad idea. ?It is the heart and soul of our data center network after all. ?However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.
>
> Can anyone offer any operational insight and real world experiences with these solutions?
>
> TIA, replies off list are welcomed.
>
>
> Regards,
>
> Bryan
>
>



From fabio.mendes at bsd.com.br  Mon May 16 19:26:07 2011
From: fabio.mendes at bsd.com.br (Fabio Mendes)
Date: Mon, 16 May 2011 21:26:07 -0300
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTik8QgKohSKZRoCWFkD87656BKR3AQ@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTik8QgKohSKZRoCWFkD87656BKR3AQ@mail.gmail.com>
Message-ID: <BANLkTiktwQnJT3D3Q3z+UAKf3Qobf_u6rA@mail.gmail.com>

We used Pound (http://www.apsis.ch/pound) on a couple of FreeBSD servers
some years ago.

Configuration is simple and the software has lots of good and interesting
features.

The only problem was that always our traffic had a spike, serving pages
through it became a nightmare.

Eventually we ended up buying a couple of Foundry/Brocade load balancers
(Server Iron).

I don't know what is software's current development state but if they
managed to solve those performance issues it would be an interesting choice,
if you really want to go that way.

HTH


From mysidia at gmail.com  Mon May 16 22:28:14 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 16 May 2011 22:28:14 -0500
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTik8QgKohSKZRoCWFkD87656BKR3AQ@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTik8QgKohSKZRoCWFkD87656BKR3AQ@mail.gmail.com>
Message-ID: <BANLkTi=Uo5gr0Tzb_1cPSBGf_BHKp4GSYA@mail.gmail.com>

On Mon, May 16, 2011 at 6:37 PM, William Cooper <wcooper02 at gmail.com> wrote:
> S/W vs H/W is really a question rooted in performance and feature
> needs vs cost... weigh your options carefully.

Load balancers are _both_ hardware and software.
There's really no such thing as a load balancer solution
that is just hardware or one that's just software (aka Firmware);
it does not exist --  real load balancers are both hardware and software.

And all software has bugs; some of which might (some day) disrupt the intended
operation.

There are packaged solutions  that are integrated hardware and software
sold as a product.

There are do-it-yourself solutions that are off-the-shelf hardware,
and software of your choice,  including open source options on commodity
hardware,  that require manual selection of the software programs used
to facilitate load balancing functions,  and maintain them in case of
exceptions,
hardware failures, or other unexpected exceptions.

Both packaged and custom built have their own advantages and disadvantages,
there are tradeoffs, and no universal best; they both meet different
sets of requirements.

Devices packaged by a load balancer manufacturer; usually have
things like user interfaces, instruction manuals, configuration
guidance, and warranty/support for the entire device, both hardware
and software.

In addition, the whole thing is tested by the manufacturers as one product,
and there may be specially integrated hardware functions supported
by the load balancer,  that are not found in commodity hardware
(e.g. specialized crypto processors for RSA/AES/SSL acceleration,
 ASICs, etc).


The manufacturer's work to deliver their product comes at a high price, so
taking a do-it-yourself  with open source software will have much lower prices
paid to the vendor:  instead of  paying a manufacturer for a product.

Except, if you actually went through the same effort as the manufacturer
of the product, it might be more expensive than buying the product,
so chances are you will do less, and have a less refined result.


Building a load balancer with cheap hardware and open source software,
puts you in the manufacturer's seat.

This provides a huge amount of flexibility, but also  adds complexity,
and gives you a lot of choices about what software to put in the box,
and how to set up each package.

Your engineering team may need a great deal of familiarity with both
the software and hardware, and a lot of patience to achieve
performance equivalent to an integrated unit.

Your exact choices of software and package versions for load balancing
or high availability,  might (or might not) have been tested by someone
with a similar scenario,  on similar hardware.


In case something goes wrong,  you won't be getting a replacement unit
overnighted in by the manufacturer,  ready to plug in and load a 5kb config.
You have only the troubleshooting  and configuration guidance you yourself
developed,  before/during use of that, so if an unexpected condition arises,
chances are you won't have as much guidance for troubleshooting or likely
causes, as a vendor would.

Requiring different procedures for dealing with a failure or
malfunctioning of the
load balancing.

In case you do have hardware/software support, for a commodity
hardware solution,
you may find your vendors pointing fingers at one another.

--
-JH



From Bryan.Welch at arrisi.com  Mon May 16 22:51:10 2011
From: Bryan.Welch at arrisi.com (Welch, Bryan)
Date: Mon, 16 May 2011 20:51:10 -0700
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTi=FPDOcSnn5GBDofDV8t0JuJkr56Q@mail.gmail.com>
References: <AcwUGznkYWI+aJHVRmaJDH1f7jrJ8A==>
	<DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTi=FPDOcSnn5GBDofDV8t0JuJkr56Q@mail.gmail.com>
Message-ID: <DFA5AECDEC85EE4087D45C463C19B375134FFFA2F2@KWAEXMAIL1.ARRS.ARRISI.COM>






?  I have had great success with ha proxy http://haproxy.1wt.eu/ -Randy


Can you elaborate on your config?

On Mon, May 16, 2011 at 7:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com<mailto:Bryan.Welch at arrisi.com>> wrote:
Greetings all.

I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use.  We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions.  These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.

Now my "knee jerk" reaction to this is that it's a really bad idea.  It is the heart and soul of our data center network after all.  However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.

Can anyone offer any operational insight and real world experiences with these solutions?

TIA, replies off list are welcomed.


Regards,

Bryan



From vixie at isc.org  Mon May 16 23:22:54 2011
From: vixie at isc.org (Paul Vixie)
Date: Tue, 17 May 2011 04:22:54 +0000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Mon, 16 May 2011 16:12:27 MST."
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
Message-ID: <80660.1305606174@nsa.vix.com>

> From: Owen DeLong <owen at delong.com>
> Date: Mon, 16 May 2011 16:12:27 -0700
> 
> ... It's not like you can even reach anything at home now, let alone
> reach it by name.

that must and will change.  let's be the generation who makes it possible.



From marka at isc.org  Mon May 16 23:33:05 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 17 May 2011 14:33:05 +1000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Tue, 17 May 2011 04:22:54 GMT."
	<80660.1305606174@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
Message-ID: <20110517043305.38B69EC71AC@drugs.dv.isc.org>


In message <80660.1305606174 at nsa.vix.com>, Paul Vixie writes:
> > From: Owen DeLong <owen at delong.com>
> > Date: Mon, 16 May 2011 16:12:27 -0700
> > 
> > ... It's not like you can even reach anything at home now, let alone
> > reach it by name.
> 
> that must and will change.  let's be the generation who makes it possible.
> 
+1
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From dwing at cisco.com  Tue May 17 00:14:39 2011
From: dwing at cisco.com (Dan Wing)
Date: Mon, 16 May 2011 22:14:39 -0700
Subject: Yahoo and IPv6
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3290@RWC-EX1.corp.seven.com>
References: <20110509163412.A4F4A1CC09@ptavv.es.net>	<4CE8188D-C4F4-4585-8B9B-1F427C8D5689@puck.nether.net>	<4DC83C4B.5080703@dougbarton.us>	<120501cc0e81$0222b1e0$066815a0$@net>	<4DC8476F.2070905@dougbarton.us>	<AB87BBEF-8B7D-46F9-89F0-7EC845072CD8@delong.com>	<Pine.LNX.4.64.1105100116180.23905@moonbase.nullrouteit.net>	<9099.1305038200@localhost>	<Pine.LNX.4.64.1105101221140.2651@moonbase.nullrouteit.net>	<CF3453B6-BB9B-4D0C-A70D-C2B46CFFDCC0@delong.com>	<BANLkTim98q1HmfQ-3beonJBv_xh31V0xsA@mail.gmail.com>	<F7A27746-AAF9-477D-8D84-5C82934BE350@lists.zabbadoz.net>	<E1E3EDD2-F066-45A6-AAEA-5D1BDF2BAFEF@matthew.at>	<8A1E9A51-398A-4C16-A05D-6848890820DC@lists.zabbadoz.net>	<BANLkTimsRCB_91z7oy1dF7xPE1+pTfAerg@mail.gmail.com>	<4DCEC578.9060308@matthew.at>	<4DCF2F5C.8030104@jima.tk>	<4DCF56BC.8070209@matthew.at><BANLkTin_bqUVu6HyVugU9xNeaLgVzL6Byg@mail.gmail.com><4DCFF136.8040102@matthew.at><C2A03F90-F4C3-4C5D-A3BE-D270CFED3026@delong.com><4DD0A03B.5080906@matthew.at>	<91DA9!423-7BCB-487
	4-A19C-B91BA	
	34DFBA3@delong.com> <CBB58C88-50D2-4BA0-9386-54FA10F28624@muada.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3290@RWC-EX1.corp.seven.com>
Message-ID: <004901cc1451$526a5ab0$f73f1010$@com>

> -----Original Message-----
> From: George Bonser [mailto:gbonser at seven.com]
> Sent: Monday, May 16, 2011 2:10 AM
> To: Iljitsch van Beijnum; Owen DeLong
> Cc: NANOG list
> Subject: RE: Yahoo and IPv6
> 
> >
> > Because that way the IPv4 and IPv6 swarms remain disconnected in the
> > absence of some dual stack peers. (I.e., if the swarm is small and
> > you're the only IPv6 participant.)
> >
> > It would be much better if you could go from IPv6 to IPv4 through a
> > NAT64.
> 
> The problem is when the client is handed an explicit address rather
> than
> a host name.  In that case, there needs to be some standard environment
> variable for "IPv64 Prefix" that applications can query.
> 
> For a browser this might be something like the configured proxy.  Maybe
> an OS such as Windows might have a registry value for this.  Maybe
> Linux
> and other unix-like variations could have a sysctl for that.
> 
> There should be some standard way for a native v6 host to determine the
> v6 to v4 prefix to use in a NAT64 environment.

That need is acknowledged and being worked,
http://www.ietf.org/mail-archive/web/behave/current/msg09634.html

-d





From mansaxel at besserwisser.org  Tue May 17 04:07:17 2011
From: mansaxel at besserwisser.org (Mans Nilsson)
Date: Tue, 17 May 2011 11:07:17 +0200
Subject: Yahoo and IPv6
In-Reply-To: <80660.1305606174@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
Message-ID: <20110517090717.GO17325@besserwisser.org>

Subject: Re: Yahoo and IPv6 Date: Tue, May 17, 2011 at 04:22:54AM +0000 Quoting Paul Vixie (vixie at isc.org):
> > From: Owen DeLong <owen at delong.com>
> > Date: Mon, 16 May 2011 16:12:27 -0700
> > 
> > ... It's not like you can even reach anything at home now, let alone
> > reach it by name.
> 
> that must and will change.  let's be the generation who makes it possible.

I'd like to respond to this by stating that I support this fully, but
I'm busy making sure I can reach my machines at home from the IPv6
Internet. By name. ;-) 

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
HELLO KITTY gang terrorizes town, family STICKERED to death!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110517/61d643cb/attachment.bin>

From owen at delong.com  Tue May 17 07:25:29 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 17 May 2011 05:25:29 -0700
Subject: Yahoo and IPv6
In-Reply-To: <20110517090717.GO17325@besserwisser.org>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
	<20110517090717.GO17325@besserwisser.org>
Message-ID: <44145AAB-06CD-4344-9887-CC12C65436C6@delong.com>


On May 17, 2011, at 2:07 AM, Mans Nilsson wrote:

> Subject: Re: Yahoo and IPv6 Date: Tue, May 17, 2011 at 04:22:54AM +0000 Quoting Paul Vixie (vixie at isc.org):
>>> From: Owen DeLong <owen at delong.com>
>>> Date: Mon, 16 May 2011 16:12:27 -0700
>>> 
>>> ... It's not like you can even reach anything at home now, let alone
>>> reach it by name.
>> 
>> that must and will change.  let's be the generation who makes it possible.
> 
> I'd like to respond to this by stating that I support this fully, but
> I'm busy making sure I can reach my machines at home from the IPv6
> Internet. By name. ;-) 

I think my statement has been taken out of context and misunderstood.

I was responding to a claim that having to understand DNS to reach your
IPv6 boxes by name was somehow a step backwards from IPv4.

My point was that at least in IPv6, you can reach your boxes whereas with
IPv4, you couldn't reach them at all (unless you used a rendezvous service
and preconfigured stuff).

To me, pre-configuring DNS through the web interface for one of the free
DNS services with the IPv6 address is not any more difficult than setting
up one of the rendezvous services (most of which you have to pay for
if you want any real utility).

To my mind, IPv6 is a giant leap forward here, not a step backwards.
At least you can reach your stuff, even if the administration of the naming
process isn't 100% automated and perfect just yet.

Owen




From vixie at isc.org  Tue May 17 07:56:37 2011
From: vixie at isc.org (Paul Vixie)
Date: Tue, 17 May 2011 12:56:37 +0000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Tue, 17 May 2011 11:07:17 +0200."
	<20110517090717.GO17325@besserwisser.org>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
	<20110517090717.GO17325@besserwisser.org>
Message-ID: <8212.1305636997@nsa.vix.com>

> Date: Tue, 17 May 2011 11:07:17 +0200
> From: Mans Nilsson <mansaxel at besserwisser.org>
> 
> > > ... It's not like you can even reach anything at home now, let alone
> > > reach it by name.
> > 
> > that must and will change.  let's be the generation who makes it possible.
> 
> I'd like to respond to this by stating that I support this fully, but
> I'm busy making sure I can reach my machines at home from the IPv6
> Internet. By name. ;-)

:-).

to be clear, the old pre-web T1 era internet did not have much content
but what content there was, was not lopsided.  other than slip and ppp
there weren't a lot of networks one would call "access" and a smaller
number of networks one would call "content".  i am not wishing for that,
i like the web, i like content, i know there will be specialized networks
for access and content.  but i also think (as jim gettys does) that we
ought to be able to get useful work done without being able to reach the
whole internet all the time.  that's going to mean being able to reach
other mostly-access networks in our same neighborhoods and multitenant
buildings and towns and cities, directly, and by name.  it does not mean
being able to start facebook 2.0 out of somebody's basement, but it does
mean being able to run a personal smtp or web server in one's basement
and have it mostly work for the whole internet and work best for accessors
who are close by and still work even when the "upstream" path for the
neighborhood is down.



From sclark at netwolves.com  Tue May 17 10:49:47 2011
From: sclark at netwolves.com (Steve Clark)
Date: Tue, 17 May 2011 11:49:47 -0400
Subject: Yahoo and IPv6
In-Reply-To: <8212.1305636997@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>
	<8212.1305636997@nsa.vix.com>
Message-ID: <4DD2991B.6040207@netwolves.com>

On 05/17/2011 08:56 AM, Paul Vixie wrote:
>> Date: Tue, 17 May 2011 11:07:17 +0200
>> From: Mans Nilsson<mansaxel at besserwisser.org>
>>
>>>> ... It's not like you can even reach anything at home now, let alone
>>>> reach it by name.
>>> that must and will change.  let's be the generation who makes it possible.
>> I'd like to respond to this by stating that I support this fully, but
>> I'm busy making sure I can reach my machines at home from the IPv6
>> Internet. By name. ;-)
> :-).
>
> to be clear, the old pre-web T1 era internet did not have much content
> but what content there was, was not lopsided.  other than slip and ppp
> there weren't a lot of networks one would call "access" and a smaller
> number of networks one would call "content".  i am not wishing for that,
> i like the web, i like content, i know there will be specialized networks
> for access and content.  but i also think (as jim gettys does) that we
> ought to be able to get useful work done without being able to reach the
> whole internet all the time.  that's going to mean being able to reach
> other mostly-access networks in our same neighborhoods and multitenant
> buildings and towns and cities, directly, and by name.  it does not mean
> being able to start facebook 2.0 out of somebody's basement, but it does
> mean being able to run a personal smtp or web server in one's basement
> and have it mostly work for the whole internet and work best for accessors
> who are close by and still work even when the "upstream" path for the
> neighborhood is down.
>
This is all very confusing to me. How are meaningful names going to assigned automatically?
Right now I see something like ool-6038bdcc.static.optonline.net for one of our servers, how does this
mean anything to anyone else?


-- 
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com


From matthew at matthew.at  Tue May 17 10:55:18 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 17 May 2011 08:55:18 -0700
Subject: Yahoo and IPv6
In-Reply-To: <44145AAB-06CD-4344-9887-CC12C65436C6@delong.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>
	<44145AAB-06CD-4344-9887-CC12C65436C6@delong.com>
Message-ID: <4DD29A66.5050106@matthew.at>

On 5/17/2011 5:25 AM, Owen DeLong wrote:
>
> My point was that at least in IPv6, you can reach your boxes whereas with
> IPv4, you couldn't reach them at all (unless you used a rendezvous service
> and preconfigured stuff).

Actually almost everyone will *still* need a rendezvous service as even 
if there isn't NAT66 (which I strongly suspect there will be, as nobody 
has magically solved the rest of the renumbering problems) there will 
still be default firewall filters that the average end-user won't know 
how or why to change (and in some cases won't even have access to the CPE).

For the former we can only hope that NAT66 box builders can get guidance 
from IETF rather than having IETF stick its collective head in the 
sand... for the latter the firewall traversal has a chance of being more 
reliable than having to traversal both filtering and address translation.

Matthew Kaufman



From joelja at bogus.com  Tue May 17 10:59:01 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 17 May 2011 08:59:01 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD2991B.6040207@netwolves.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>
	<8212.1305636997@nsa.vix.com> <4DD2991B.6040207@netwolves.com>
Message-ID: <EEE9CF66-BF84-4E78-8EA8-71E551CD6401@bogus.com>


On May 17, 2011, at 8:49 AM, Steve Clark wrote:

> On 05/17/2011 08:56 AM, Paul Vixie wrote:
>>> Date: Tue, 17 May 2011 11:07:17 +0200
>>> From: Mans Nilsson<mansaxel at besserwisser.org>
>>> 
>>>>> ... It's not like you can even reach anything at home now, let alone
>>>>> reach it by name.
>>>> that must and will change.  let's be the generation who makes it possible.
>>> I'd like to respond to this by stating that I support this fully, but
>>> I'm busy making sure I can reach my machines at home from the IPv6
>>> Internet. By name. ;-)
>> :-).
>> 
>> to be clear, the old pre-web T1 era internet did not have much content
>> but what content there was, was not lopsided.  other than slip and ppp
>> there weren't a lot of networks one would call "access" and a smaller
>> number of networks one would call "content".  i am not wishing for that,
>> i like the web, i like content, i know there will be specialized networks
>> for access and content.  but i also think (as jim gettys does) that we
>> ought to be able to get useful work done without being able to reach the
>> whole internet all the time.  that's going to mean being able to reach
>> other mostly-access networks in our same neighborhoods and multitenant
>> buildings and towns and cities, directly, and by name.  it does not mean
>> being able to start facebook 2.0 out of somebody's basement, but it does
>> mean being able to run a personal smtp or web server in one's basement
>> and have it mostly work for the whole internet and work best for accessors
>> who are close by and still work even when the "upstream" path for the
>> neighborhood is down.
>> 
> This is all very confusing to me. How are meaningful names going to assigned automatically?

dynamic dns updates seems like an obvious choice.

> Right now I see something like ool-6038bdcc.static.optonline.net for one of our servers, how does this
> mean anything to anyone else?
> 
> 
> -- 
> Stephen Clark
> *NetWolves*
> Sr. Software Engineer III
> Phone: 813-579-3200
> Fax: 813-882-0209
> Email: steve.clark at netwolves.com
> http://www.netwolves.com
> 




From iljitsch at muada.com  Tue May 17 11:01:53 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 17 May 2011 18:01:53 +0200
Subject: Yahoo and IPv6
In-Reply-To: <4DD29A66.5050106@matthew.at>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>
	<44145AAB-06CD-4344-9887-CC12C65436C6@delong.com>
	<4DD29A66.5050106@matthew.at>
Message-ID: <5AB85066-441F-45BE-A8E3-5A3280361CA3@muada.com>

On 17 mei 2011, at 17:55, Matthew Kaufman wrote:

> firewall traversal

Smells like job security: first install a firewall, then traverse it anyway.




From vixie at isc.org  Tue May 17 11:29:34 2011
From: vixie at isc.org (Paul Vixie)
Date: Tue, 17 May 2011 16:29:34 +0000
Subject: Yahoo and IPv6
In-Reply-To: Your message of "Tue, 17 May 2011 11:49:47 -0400."
	<4DD2991B.6040207@netwolves.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
	<20110517090717.GO17325@besserwisser.org>
	<8212.1305636997@nsa.vix.com> <4DD2991B.6040207@netwolves.com>
Message-ID: <22746.1305649774@nsa.vix.com>

> Date: Tue, 17 May 2011 11:49:47 -0400
> From: Steve Clark <sclark at netwolves.com>
> 
> This is all very confusing to me. How are meaningful names going to assigned
> automatically?

It'll probably be a lot like Apple's and Xerox's various multicast naming
systems if we want it to work in non-globally connected networks.

> Right now I see something like ool-6038bdcc.static.optonline.net for
> one of our servers, how does this mean anything to anyone else?

It wouldn't of course.  I'm sorry if my earlier words on this were useless.

Dave Taht gave a wonderful talk a few weeks ago ("Finishing the Internet",
see http://amw.org/prog11.pdf) during which he had us start an rsync
from his wireless laptop to as many of ours as could run rsync, and then
had the conference organizer turn off the upstream link.  He noted that
those of us using the local resource (a giant file, either an ISO or a
MPEG or similar) were still getting work done whereas those of us trying
to "use the internet" were dead in the water.  Then, referring to his
time in Nicaragua he said that he has a lot of days like this and he'd
like more work to be possible when only local connectivity was available.

Compelling stuff.  Pity there's no global market for localized services
or we'd already have it.  Nevertheless this must and will get fixed, and
we should be the generation who does it.



From mloftis at wgops.com  Tue May 17 12:03:46 2011
From: mloftis at wgops.com (Michael Loftis)
Date: Tue, 17 May 2011 11:03:46 -0600
Subject: Experience with Open Source load balancers?
In-Reply-To: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
Message-ID: <BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>

On Mon, May 16, 2011 at 5:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com> wrote:
> Greetings all.
>
> I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use. ?We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions. ?These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.
>
> Now my "knee jerk" reaction to this is that it's a really bad idea. ?It is the heart and soul of our data center network after all. ?However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.
>
> Can anyone offer any operational insight and real world experiences with these solutions?

Honestly I think to get *all* those features you're much better off
with commercial solutions like the ones you're already using from F5,
or something from Cisco, Coyote Point, Brocade, or others.  You can
absolutely put together a solution based on any number of open source
products, but you won't get the single integrated front end for
management and configuration that any of the commercial options will
provide, you may be missing features, and ultimately, you're on the
hook for making it work.  In particular the stateful failover has been
problematic in open source solutions in my experience.  They've come a
VERY long way, but it is a hard problem to tackle.

I've worked with open source and commercial solutions, and while the
open source systems were almost always far more flexible, and cheaper
up front, they certainly required more work to get going..  Once setup
and running though both types of solutions had pretty equal amounts of
maintenance, with the commercial solutions requiring somewhat less
time/babysitting for upgrades and to enable or use new features or
functionality.



From dot at dotat.at  Tue May 17 12:50:15 2011
From: dot at dotat.at (Tony Finch)
Date: Tue, 17 May 2011 18:50:15 +0100
Subject: Yahoo and IPv6
In-Reply-To: <22746.1305649774@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
	<20110517090717.GO17325@besserwisser.org>
	<8212.1305636997@nsa.vix.com> <4DD2991B.6040207@netwolves.com>
	<22746.1305649774@nsa.vix.com>
Message-ID: <alpine.LSU.2.00.1105171847360.19348@hermes-2.csi.cam.ac.uk>

Paul Vixie <vixie at isc.org> wrote:

> > This is all very confusing to me. How are meaningful names going to assigned
> > automatically?
>
> It'll probably be a lot like Apple's and Xerox's various multicast naming
> systems if we want it to work in non-globally connected networks.

Or perhaps user-relative names.
http://www.brynosaurus.com/pub/net/uia-osdi.pdf

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.



From jneufferjr at gmail.com  Tue May 17 13:05:44 2011
From: jneufferjr at gmail.com (Jeff Neuffer Jr)
Date: Tue, 17 May 2011 14:05:44 -0400
Subject: Experience with Open Source load balancers?
In-Reply-To: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
Message-ID: <BANLkTikv2UzUCEOs4Gq=keikvFLaxNSDzw@mail.gmail.com>

We've use Linux LVS for many many years with success.
http://www.linuxvirtualserver.org/



On Mon, May 16, 2011 at 7:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com>wrote:

> Greetings all.
>
> I've been tasked with comparing the use of open source load balancing
> software against commercially available off the shelf hardware such as F5,
> which is what we currently use.  We use the load balancers for traditional
> load balancing, full proxy for http/ssl traffic, ssl termination and
> certificate management, ssl and http header manipulation, nat, high
> availability of the physical hardware and stateful failover of the tcp
> sessions.  These units will be placed at the customer prem supporting our
> applications and services and we'll need to support them accordingly.
>
> Now my "knee jerk" reaction to this is that it's a really bad idea.  It is
> the heart and soul of our data center network after all.  However, once I
> started to think about it I realized that I hadn't had any real experience
> with this solution beyond tinkering with it at home and reading about it in
> years past.
>
> Can anyone offer any operational insight and real world experiences with
> these solutions?
>
> TIA, replies off list are welcomed.
>
>
> Regards,
>
> Bryan
>
>


-- 
~Jeff

"It is not the critic who counts, nor the man who points how the strong man
stumbled or where the doer of deeds could have done them better. The credit
belongs to the man who is actually in the arena; whose face is marred by
dust and sweat and blood; who strives valiantly...who knows the great
enthusiasms, the great devotions, and spends himself in a worthy cause; who,
at best, knows the triumph of high achievement; and who, at the worst, if he
fails, at least fails while daring greatly, so that his place shall never be
with those cold and timid souls who know neither victory nor defeat."

Theodore Roosevelt (1858 - 1919), "Man in the Arena" Speech given April 23,
1910


From tom at ninjabadger.net  Tue May 17 13:23:21 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Tue, 17 May 2011 19:23:21 +0100
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>
Message-ID: <1305656601.2152.3.camel@teh-desktop>

On Tue, 2011-05-17 at 11:03 -0600, Michael Loftis wrote:
> On Mon, May 16, 2011 at 5:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com> wrote:
> > Greetings all.
> >
> > I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use.  We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions.  These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.
> >
> > Now my "knee jerk" reaction to this is that it's a really bad idea.  It is the heart and soul of our data center network after all.  However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.
> >
> > Can anyone offer any operational insight and real world experiences with these solutions?
> 
> Honestly I think to get *all* those features you're much better off
> with commercial solutions like the ones you're already using from F5,
> or something from Cisco, Coyote Point, Brocade, or others.  You can
> absolutely put together a solution based on any number of open source
> products, but you won't get the single integrated front end for
> management and configuration that any of the commercial options will
> provide, you may be missing features, and ultimately, you're on the
> hook for making it work.  In particular the stateful failover has been
> problematic in open source solutions in my experience.  They've come a
> VERY long way, but it is a hard problem to tackle.

+1. I think the list of features covers more than just one FOSS project.

Whilst I've had no end of good experiences using LVS (as some others
have mentioned), I wouldn't expect it to do all that is requested in the
original post. At least, not by itself.

> I've worked with open source and commercial solutions, and while the
> open source systems were almost always far more flexible, and cheaper
> up front, they certainly required more work to get going..  Once setup
> and running though both types of solutions had pretty equal amounts of
> maintenance, with the commercial solutions requiring somewhat less
> time/babysitting for upgrades and to enable or use new features or
> functionality.

I worry far more about upgrades to proprietary appliances (where it's
often the whole system image), than I do about a few package updates on
a Linux machine (followed by a service restart, or two).

But still, pretty well worded. :)

Tom





From paul at paulgraydon.co.uk  Tue May 17 13:41:22 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Tue, 17 May 2011 08:41:22 -1000
Subject: Experience with Open Source load balancers?
In-Reply-To: <1305656601.2152.3.camel@teh-desktop>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>	<BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>
	<1305656601.2152.3.camel@teh-desktop>
Message-ID: <4DD2C152.4040403@paulgraydon.co.uk>

On 05/17/2011 08:23 AM, Tom Hill wrote:
>> I've worked with open source and commercial solutions, and while the
>> open source systems were almost always far more flexible, and cheaper
>> up front, they certainly required more work to get going..  Once setup
>> and running though both types of solutions had pretty equal amounts of
>> maintenance, with the commercial solutions requiring somewhat less
>> time/babysitting for upgrades and to enable or use new features or
>> functionality.
> I worry far more about upgrades to proprietary appliances (where it's
> often the whole system image), than I do about a few package updates on
> a Linux machine (followed by a service restart, or two).
>
> But still, pretty well worded. :)
>
> Tom

Can't speak for other brands these days but F5s have two hard disks in 
them.  You can upgrade the software on the hot-spare, boot off that and 
confirm everything is working.  If it isn't you can just switch back.

Paul



From nanog at lacutt.com  Tue May 17 13:57:42 2011
From: nanog at lacutt.com (LaDerrick H.)
Date: Tue, 17 May 2011 13:57:42 -0500
Subject: Experience with Open Source load balancers?
In-Reply-To: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
Message-ID: <20110517185742.GL20921@nm.lacutt>

On Mon, May 16, 2011 at 04:15:45PM -0700, Welch, Bryan wrote:
> Greetings all.
> 
> I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use.  We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions.  These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.
> 
> Now my "knee jerk" reaction to this is that it's a really bad idea.  It is the heart and soul of our data center network after all.  However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.
> 
> Can anyone offer any operational insight and real world experiences with these solutions?

I've used LVS and other Open Source solutions in the past.  As others
have alluded to, these require knowledge and experience with the
underlying OS and network stack that's often lacking in many
organizations.  A good hybrid solution which implements all (I think) of
your requirements is Zeus (http://www.zeus.com/)  It's a software
solution which you can deploy on your own hardware.  It's been very
solid in my experience.  You can deploy the software in a clustered
configuration if needed, though I've only used it in an HA pair.

LaDerrick

> 
> TIA, replies off list are welcomed.
> 
> 
> Regards,
> 
> Bryan
> 



From r.engehausen at gmail.com  Tue May 17 17:02:47 2011
From: r.engehausen at gmail.com (Roy)
Date: Tue, 17 May 2011 15:02:47 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other
	Company
Message-ID: <4DD2F087.5050003@gmail.com>


http://e.businessinsider.com/public/184962




From mansaxel at besserwisser.org  Tue May 17 17:03:08 2011
From: mansaxel at besserwisser.org (Mans Nilsson)
Date: Wed, 18 May 2011 00:03:08 +0200
Subject: Yahoo and IPv6
In-Reply-To: <8212.1305636997@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
	<20110517090717.GO17325@besserwisser.org>
	<8212.1305636997@nsa.vix.com>
Message-ID: <20110517220308.GQ17325@besserwisser.org>

Subject: Re: Yahoo and IPv6 Date: Tue, May 17, 2011 at 12:56:37PM +0000 Quoting Paul Vixie (vixie at isc.org):

> :-).
> 
> to be clear, the old pre-web T1 era internet did not have much content
> but what content there was, was not lopsided.  other than slip and ppp
> there weren't a lot of networks one would call "access" and a smaller
> number of networks one would call "content".  i am not wishing for that,
> i like the web, i like content, i know there will be specialized networks
> for access and content.  but i also think (as jim gettys does) that we
> ought to be able to get useful work done without being able to reach the
> whole internet all the time.  that's going to mean being able to reach
> other mostly-access networks in our same neighborhoods and multitenant
> buildings and towns and cities, directly, and by name.  it does not mean
> being able to start facebook 2.0 out of somebody's basement, but it does
> mean being able to run a personal smtp or web server in one's basement
> and have it mostly work for the whole internet and work best for accessors
> who are close by and still work even when the "upstream" path for the
> neighborhood is down.
 
Now I seem to have got time enough to fully agree with you.  

The next facebook will start in a low-price datacenter. These
facilities did not exist as products before, and it can be argued that
the access/content separation does drive that market -- as long as I
had working Internet (as opposed to access class "Internet" ) at home,
I had no use for a colo.

Still, the centralization of content into a few networks does raise a
number of issues -- mostly regarding stability. Do note here that
several factors negatively impact stability, be they technical,
economical or legal. Peter L?thberg long ago advocated a network
interconnection model that was pretty local (and I believe he still
does). Peer often and everywhere.  That would take care of packets
getting through (as long as we all have unique addresses to point at;
v6 fixes this) The services that take the Net from being a graph
problem for nerds with BGP CLI access into what it has become need to
undergo similar fine-graining to keep up.

Oh, sorry, got carried away. 

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
My life is a patio of fun!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110518/57e48938/attachment.bin>

From surfer at mauigateway.com  Tue May 17 17:04:19 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 17 May 2011 15:04:19 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
Message-ID: <20110517150419.B96C57A4@resin16.mta.everyone.net>



--- dot at dotat.at wrote:
Or perhaps user-relative names.
http://www.brynosaurus.com/pub/net/uia-osdi.pdf
--------------------------------------------------


What about privacy concerns; stopping your every move being tracked through the personal name attached to all of your devices?  Did I miss something in the paper?

scott



From Valdis.Kletnieks at vt.edu  Tue May 17 17:25:28 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 17 May 2011 18:25:28 -0400
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: Your message of "Tue, 17 May 2011 15:04:19 PDT."
	<20110517150419.B96C57A4@resin16.mta.everyone.net>
References: <20110517150419.B96C57A4@resin16.mta.everyone.net>
Message-ID: <24376.1305671128@localhost>

On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
 
> What about privacy concerns

"Privacy is dead.  Get used to it." -- Scott McNeely


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110517/7e0df6f2/attachment.bin>

From surfer at mauigateway.com  Tue May 17 18:05:11 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 17 May 2011 16:05:11 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
Message-ID: <20110517160511.B96C4F2A@resin16.mta.everyone.net>



------- Valdis.Kletnieks at vt.edu wrote: ---------
From: <Valdis.Kletnieks at vt.edu>
On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
 
> What about privacy concerns

"Privacy is dead.  Get used to it." -- Scott McNeely
--------------------------------------------------


It doesn't have to be that way.  We can design these things any way we want.  Why give the corpment (corporate/government contraction) an easy time at it?  Just like the early days, security and privacy do not seem to be in folk's mind when things are being designed.

scott





From marka at isc.org  Tue May 17 18:23:20 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 18 May 2011 09:23:20 +1000
Subject: Experience with Open Source load balancers?
In-Reply-To: Your message of "Tue, 17 May 2011 11:03:46 CST."
	<BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>
Message-ID: <20110517232320.14963ECE4FD@drugs.dv.isc.org>


In message <BANLkTimxkNx5=__jXD9056FAO19V1zoKqg at mail.gmail.com>, Michael Loftis
 writes:
> On Mon, May 16, 2011 at 5:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com> wrot=
> e:
> > Greetings all.
> >
> > I've been tasked with comparing the use of open source load balancing sof=
> tware against commercially available off the shelf hardware such as F5, whi=
> ch is what we currently use. =A0We use the load balancers for traditional l=
> oad balancing, full proxy for http/ssl traffic, ssl termination and certifi=
> cate management, ssl and http header manipulation, nat, high availability o=
> f the physical hardware and stateful failover of the tcp sessions. =A0These=
>  units will be placed at the customer prem supporting our applications and =
> services and we'll need to support them accordingly.
> >
> > Now my "knee jerk" reaction to this is that it's a really bad idea. =A0It=
>  is the heart and soul of our data center network after all. =A0However, on=
> ce I started to think about it I realized that I hadn't had any real experi=
> ence with this solution beyond tinkering with it at home and reading about =
> it in years past.
> >
> > Can anyone offer any operational insight and real world experiences with =
> these solutions?
> 
> Honestly I think to get *all* those features you're much better off
> with commercial solutions like the ones you're already using from F5,
> or something from Cisco, Coyote Point, Brocade, or others.  You can
> absolutely put together a solution based on any number of open source
> products, but you won't get the single integrated front end for
> management and configuration that any of the commercial options will
> provide, you may be missing features, and ultimately, you're on the
> hook for making it work.  In particular the stateful failover has been
> problematic in open source solutions in my experience.  They've come a
> VERY long way, but it is a hard problem to tackle.
> 
> I've worked with open source and commercial solutions, and while the
> open source systems were almost always far more flexible, and cheaper
> up front, they certainly required more work to get going..  Once setup
> and running though both types of solutions had pretty equal amounts of
> maintenance, with the commercial solutions requiring somewhat less
> time/babysitting for upgrades and to enable or use new features or
> functionality.

Just make sure the DNS components return valid responses to AAAA
queries as well as valid responses to A queries.  Many load balancers
get this wrong.  They return NXDOMAIN instead of NOERROR, they drop
AAAA queries, they don't return CNAMEs when the A response returns
a CNAME, they return the wrong SOA record (doesn't match the zone
delegated to the box).

Better still would be for them to return AAAA records but until one
is ready to do that the negative responses need to be correct.

If they are returning AAAA queries check NS, SOA, TXT and MX responses
for similar errors.  AAAA is just more visible as browsers make AAAA
queries and the others are done in the background.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From scott.brim at gmail.com  Tue May 17 18:30:57 2011
From: scott.brim at gmail.com (Scott Brim)
Date: Tue, 17 May 2011 19:30:57 -0400
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <24376.1305671128@localhost>
References: <20110517150419.B96C57A4@resin16.mta.everyone.net>
	<24376.1305671128@localhost>
Message-ID: <BANLkTi=rj86s6FDKu9UAzOfdDM4WOmtdtA@mail.gmail.com>

On May 17, 2011 6:26 PM, <Valdis.Kletnieks at vt.edu> wrote:
>
> On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
>
> > What about privacy concerns
>
> "Privacy is dead.  Get used to it." -- Scott McNeely

Forget that attitude, Valdis. Just because privacy is blown at one level
doesn't mean you give it away at every other one. We establish the framework
for recovering privacy and make progress step by step, wherever we can.
Someday we'll get it all back under control.

Scott


From joelja at bogus.com  Tue May 17 18:39:46 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 17 May 2011 16:39:46 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <BANLkTi=rj86s6FDKu9UAzOfdDM4WOmtdtA@mail.gmail.com>
References: <20110517150419.B96C57A4@resin16.mta.everyone.net>
	<24376.1305671128@localhost>
	<BANLkTi=rj86s6FDKu9UAzOfdDM4WOmtdtA@mail.gmail.com>
Message-ID: <290D9CF4-87D0-49D8-9A44-C49122B46EDB@bogus.com>


On May 17, 2011, at 4:30 PM, Scott Brim wrote:

> On May 17, 2011 6:26 PM, <Valdis.Kletnieks at vt.edu> wrote:
>> 
>> On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
>> 
>>> What about privacy concerns
>> 
>> "Privacy is dead.  Get used to it." -- Scott McNeely
> 
> Forget that attitude, Valdis. Just because privacy is blown at one level
> doesn't mean you give it away at every other one. We establish the framework
> for recovering privacy and make progress step by step, wherever we can.
> Someday we'll get it all back under control.

if you put something in the dns you do so because you want to discovered. scoping the nameservers such that they only express certain certain resource records to queriers in a particular scope is fairly straight forward.

> Scott
> 




From Valdis.Kletnieks at vt.edu  Tue May 17 18:44:14 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 17 May 2011 19:44:14 -0400
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: Your message of "Tue, 17 May 2011 16:05:11 PDT."
	<20110517160511.B96C4F2A@resin16.mta.everyone.net>
References: <20110517160511.B96C4F2A@resin16.mta.everyone.net>
Message-ID: <27822.1305675854@localhost>

(And I get flamed by multiple people because I put in the quote and managed to
hit send before adding the commentary. Maybe one of these days I'll learn not
to try to mix replying to e-mail and dealing with vendor engineers doing a tape
library expansion at the same time. :)  Oh well, equivalent text follows as a
reply to Scott...)

On Tue, 17 May 2011 16:05:11 PDT, Scott Weeks said:
> It doesn't have to be that way.  We can design these things any way we want.

True.  The question is whether we get to *deploy* said designs.

> Why give the corpment (corporate/government contraction) an easy time at it?
> Just like the early days, security and privacy do not seem to be in folk's mind
> when things are being designed.

But more importantly, who has more/better lobbyists, you or the people who
want things like COICA and ACTA?

You're going to have to fix *that* problem before trying to address it at the
protocol level will do any real, lasting good.  Either that or we need a *lot* more TOR
relays (while those are still legal).

Oh, and an article that coincidentally popped up since I hit 'send' on the
previous mail:

http://radar.oreilly.com/2011/05/anonymize-data-limits.html

Designing things to evade good data mining is a *lot* harder than it looks.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110517/7e9991d0/attachment.bin>

From mysidia at gmail.com  Tue May 17 19:07:39 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 17 May 2011 19:07:39 -0500
Subject: Experience with Open Source load balancers?
In-Reply-To: <20110517232320.14963ECE4FD@drugs.dv.isc.org>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>
	<20110517232320.14963ECE4FD@drugs.dv.isc.org>
Message-ID: <BANLkTi=6mGUeJ+nwcG38kXs687LaqTAHJg@mail.gmail.com>

On Tue, May 17, 2011 at 6:23 PM, Mark Andrews <marka at isc.org> wrote:
[snip]
>
> Better still would be for them to return AAAA records but until one
> is ready to do that the negative responses need to be correct.

Hm... better would be for  load balancers operate transparently at Layer 3 and
not tamper with the contents of answers from proper DNS servers.

Eating traffic based on application content, or turning  NOERROR,
0 matches into  NXDOMAIN is seriously f***'ed up.


I look forward to more domains having DS records published by TLDs w/
signed zones...
and possibly browsers displaying warnings trying to visit HTTPS
domains without a signed zone.

perhaps load balancers/middle box manufacturers will start to become a
little bit more honest
in what they do with DNS traffic  :)

--
-JH



From surfer at mauigateway.com  Tue May 17 20:09:15 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 17 May 2011 18:09:15 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
Message-ID: <20110517180915.B96C4229@resin16.mta.everyone.net>

--- joelja at bogus.com wrote:
From: Joel Jaeggli <joelja at bogus.com>
On May 17, 2011, at 4:30 PM, Scott Brim wrote:
> On May 17, 2011 6:26 PM, <Valdis.Kletnieks at vt.edu> wrote:
>> On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
>> 
>>> What about privacy concerns
>> 
>> "Privacy is dead.  Get used to it." -- Scott McNeely
> 
> Forget that attitude, Valdis. Just because privacy is blown at one level
> doesn't mean you give it away at every other one. We establish the framework
> for recovering privacy and make progress step by step, wherever we can.
> Someday we'll get it all back under control.

if you put something in the dns you do so because you want to discovered. scoping the nameservers such that they only express certain certain resource records to queriers in a particular scope is fairly straight forward.
--------------------------------------------------------


The article was not about DNS.  It was about "Persistent Personal Names for Globally Connected Mobile Devices" where "Users normally create personal names by introducing devices locally, on a common WiFi network for example. Once created, these names remain persistently bound to their targets as devices move. Personal names are intended to supplement and not replace global DNS names."  

I see a lot of folks on lists designing future networks where an identifier follows you everywhere and we as operators will have to deal with a public hostile to the idea of being followed.  It's happening now.  Just read all the articles on privacy lost.  It's not going to go away.  People like their privacy whether they're doing bad things or not.

scott



From brent at servuhome.net  Tue May 17 20:12:01 2011
From: brent at servuhome.net (Brent Jones)
Date: Tue, 17 May 2011 18:12:01 -0700
Subject: Experience with Open Source load balancers?
In-Reply-To: <20110517185742.GL20921@nm.lacutt>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<20110517185742.GL20921@nm.lacutt>
Message-ID: <BANLkTi=G5ALG6RnVXjvPd3uX_qoSaWR_NA@mail.gmail.com>

On Tue, May 17, 2011 at 11:57 AM, LaDerrick H. <nanog at lacutt.com> wrote:
> On Mon, May 16, 2011 at 04:15:45PM -0700, Welch, Bryan wrote:
>> Greetings all.
>>
>> I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use. ?We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions. ?These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.
>>
>> Now my "knee jerk" reaction to this is that it's a really bad idea. ?It is the heart and soul of our data center network after all. ?However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.
>>
>> Can anyone offer any operational insight and real world experiences with these solutions?
>
> I've used LVS and other Open Source solutions in the past. ?As others
> have alluded to, these require knowledge and experience with the
> underlying OS and network stack that's often lacking in many
> organizations. ?A good hybrid solution which implements all (I think) of
> your requirements is Zeus (http://www.zeus.com/) ?It's a software
> solution which you can deploy on your own hardware. ?It's been very
> solid in my experience. ?You can deploy the software in a clustered
> configuration if needed, though I've only used it in an HA pair.
>
> LaDerrick
>
>>
>> TIA, replies off list are welcomed.
>>
>>
>> Regards,
>>
>> Bryan
>>
>
>

+1 for Zeus. Use it in our production network with great success.
Magnitudes cheaper than a solution from F5, and doesn't hide the inner
workings of the product if you want to do some things outside the
scope of support.
Zeus also does licensing just based on throughput, not arbitrary
transactions per second like F5 does/did. If you're hardware can push
the traffic, theres no limitations on the number of transactions or
sessions.

-- 
Brent Jones
brent at servuhome.net



From jkrejci at usinternet.com  Tue May 17 20:17:48 2011
From: jkrejci at usinternet.com (jkrejci at usinternet.com)
Date: Wed, 18 May 2011 01:17:48 +0000
Subject: Experience with Open Source load balancers?
Message-ID: <1018261266-1305681488-cardhu_decombobulator_blackberry.rim.net-649580830-@b4.c4.bise6.blackberry>

In response to your query on dnssec in the browser, I use this.

https://addons.mozilla.org/en-us/firefox/addon/dnssec-validator/

------Original Message------
From: Jimmy Hess
To: Mark Andrews
Cc: Welch, Bryan
Cc: nanog at nanog.org
Subject: Re: Experience with Open Source load balancers?
Sent: May 17, 2011 7:07 PM

On Tue, May 17, 2011 at 6:23 PM, Mark Andrews <marka at isc.org> wrote:
[snip]
>
> Better still would be for them to return AAAA records but until one
> is ready to do that the negative responses need to be correct.

Hm... better would be for  load balancers operate transparently at Layer 3 and
not tamper with the contents of answers from proper DNS servers.

Eating traffic based on application content, or turning  NOERROR,
0 matches into  NXDOMAIN is seriously f***'ed up.


I look forward to more domains having DS records published by TLDs w/
signed zones...
and possibly browsers displaying warnings trying to visit HTTPS
domains without a signed zone.

perhaps load balancers/middle box manufacturers will start to become a
little bit more honest
in what they do with DNS traffic  :)

--
-JH



Sent via BlackBerry from T-Mobile

From surfer at mauigateway.com  Tue May 17 20:26:10 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 17 May 2011 18:26:10 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
Message-ID: <20110517182610.B96C418F@resin16.mta.everyone.net>


--- Valdis.Kletnieks at vt.edu wrote:
From: Valdis.Kletnieks at vt.edu

> Why give the corpment (corporate/government contraction) an easy time at it?
> Just like the early days, security and privacy do not seem to be in folk's mind
> when things are being designed.

But more importantly, who has more/better lobbyists, you or the people who
want things like COICA and ACTA?

You're going to have to fix *that* problem before trying to address it at the
protocol level will do any real, lasting good.  Either that or we need a *lot* more TOR
relays (while those are still legal).
-----------------------------------------------------------

It's a multi-layered problem and designers at all layers need to keep privacy in mind.  You can't solve the multi-layered privacy problem with a design at one layer.



--------------------------------------------
Oh, and an article that coincidentally popped up since I hit 'send' on the
previous mail:

http://radar.oreilly.com/2011/05/anonymize-data-limits.html

Designing things to evade good data mining is a *lot* harder than it looks.
--------------------------------------------

This article doesn't really address what we're discussing.  It looks at the 'upper' layer only.  I'm just saying that we don't need an ID that follows us everywhere like, I believe, LOC/ID split and "Unmanaged Internet Architecture" (from the "Persistent Personal Names for Globally Connected Mobile Devices" paper) apparently does (I haven't read their paper thoroughly enough to comment in an authoritative manner, though).  There has got to be another way.  RINA (http://www.cs.bu.edu/fac/matta/Papers/rina-security.pdf) addresses privacy/security, but the nanog show-me-the-code folks were unimpressed with the existing code when I asked the list about it in the past.

scott






From scott.brim at gmail.com  Tue May 17 21:10:07 2011
From: scott.brim at gmail.com (Scott Brim)
Date: Tue, 17 May 2011 22:10:07 -0400
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <20110517182610.B96C418F@resin16.mta.everyone.net>
References: <20110517182610.B96C418F@resin16.mta.everyone.net>
Message-ID: <BANLkTi=5_JAMRw8BLYCr0hn_=4zafXZFVw@mail.gmail.com>

Yes indeed.  <http://www.ietf.org/proceedings/79/slides/intarea-3.pdf>

-- sent from a tiny screen


From joelja at bogus.com  Tue May 17 21:30:13 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 17 May 2011 19:30:13 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <20110517180915.B96C4229@resin16.mta.everyone.net>
References: <20110517180915.B96C4229@resin16.mta.everyone.net>
Message-ID: <BFD23017-7D4B-4BB1-9EDD-043CE84555AE@bogus.com>


On May 17, 2011, at 6:09 PM, Scott Weeks wrote:

> --- joelja at bogus.com wrote:
> From: Joel Jaeggli <joelja at bogus.com>
> On May 17, 2011, at 4:30 PM, Scott Brim wrote:
>> On May 17, 2011 6:26 PM, <Valdis.Kletnieks at vt.edu> wrote:
>>> On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
>>> 
>>>> What about privacy concerns
>>> 
>>> "Privacy is dead.  Get used to it." -- Scott McNeely
>> 
>> Forget that attitude, Valdis. Just because privacy is blown at one level
>> doesn't mean you give it away at every other one. We establish the framework
>> for recovering privacy and make progress step by step, wherever we can.
>> Someday we'll get it all back under control.
> 
> if you put something in the dns you do so because you want to discovered. scoping the nameservers such that they only express certain certain resource records to queriers in a particular scope is fairly straight forward.
> --------------------------------------------------------
> 
> 
> The article was not about DNS.  It was about "Persistent Personal Names for Globally Connected Mobile Devices" where "Users normally create personal names by introducing devices locally, on a common WiFi network for example. Once created, these names remain persistently bound to their targets as devices move. Personal names are intended to supplement and not replace global DNS names."  

you mean like mac addresses? those have a tendency to follow you around in ipv6...

> I see a lot of folks on lists designing future networks where an identifier follows you everywhere and we as operators will have to deal with a public hostile to the idea of being followed.  It's happening now.  Just read all the articles on privacy lost.  It's not going to go away.  People like their privacy whether they're doing bad things or not.
> 
> scott
> 




From erikm at buh.org  Tue May 17 21:30:33 2011
From: erikm at buh.org (Erik Muller)
Date: Tue, 17 May 2011 22:30:33 -0400 (EDT)
Subject: IPv6 gateway, was: Re: IPv6 foot-dragging
In-Reply-To: <BANLkTinvqPpZqFMqG0+izZSaTa+fxdgiNg@mail.gmail.com>
References: <4DCD8087.9020402@mompl.net> <4DCDA380.7020407@mompl.net>
	<BANLkTinvqPpZqFMqG0+izZSaTa+fxdgiNg@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1105172205530.6662@minervax>

On Mon, 16 May 2011, Todd Lyons wrote:
>
> Double check the kernel version you have.  IIRC kernels before 2.6.20
> didn't have the ability to do RELATED,ESTABLISHED in ipv6.  This hit
> me on a CentOS box that I was using as a gateway.  I am unaware if
> there is a version of their 2.6.18 that has the patches backported
> (googling seemed to indicate it has not been done, and most are just
> waiting for new release of CentOS 6).  RH6 works properly.

>From my experience, kernels older than 2.6.27 or so are simply to be 
avoided for anything v6 - in addition to no iptables state pre20, there 
were some RA processing bugs that would result in great fun if, for 
example, your upstream MTU ever changed.  Finding usable backports on 
CentOS was an exercise in futility.

-e



From surfer at mauigateway.com  Tue May 17 21:46:06 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 17 May 2011 19:46:06 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
Message-ID: <20110517194606.B96C7851@resin16.mta.everyone.net>



--- scott.brim at gmail.com wrote:
From: Scott Brim <scott.brim at gmail.com>

Yes indeed.  <http://www.ietf.org/proceedings/79/slides/intarea-3.pdf>
---------------------------------------------


Hm, that's a funny correlation to what I have been thinking and talking about lately.  I'll have to read the draft-brim-mobility-and-privacy-00 paper as the pdf-bullet-point-syndrome has overtaken my info absorption abilities.  I looked at the pdf, but bullet points make me have the deer-in-the-headlights look.  ;-)

scott



From surfer at mauigateway.com  Tue May 17 21:51:39 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 17 May 2011 19:51:39 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
Message-ID: <20110517195139.B96C78DD@resin16.mta.everyone.net>



--- joelja at bogus.com wrote:
From: Joel Jaeggli <joelja at bogus.com>

> if you put something in the dns you do so because you want to discovered. scoping the nameservers such that they only express certain certain resource records to queriers in a particular scope is fairly straight forward.
> --------------------------------------------------------
> 
> 
> The article was not about DNS.  It was about "Persistent Personal Names for Globally Connected Mobile Devices" where "Users normally create personal names by introducing devices locally, on a common WiFi network for example. Once created, these names remain persistently bound to their targets as devices move. Personal names are intended to supplement and not replace global DNS names."  

you mean like mac addresses? those have a tendency to follow you around in ipv6...
-----------------------------------------



<disclaimer> 
   Still an IPv6 wussie...  :-) 
</disclaimer>  


Only if you design your network that way.  EUI-64 isn't required.


scott



From joelja at bogus.com  Tue May 17 22:22:23 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 17 May 2011 20:22:23 -0700
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <20110517195139.B96C78DD@resin16.mta.everyone.net>
References: <20110517195139.B96C78DD@resin16.mta.everyone.net>
Message-ID: <2CE23EE9-7BC7-46C6-A2F2-75DDBEFCDBC6@bogus.com>


On May 17, 2011, at 7:51 PM, Scott Weeks wrote:

> 
> 
> --- joelja at bogus.com wrote:
> From: Joel Jaeggli <joelja at bogus.com>
> 
>> if you put something in the dns you do so because you want to discovered. scoping the nameservers such that they only express certain certain resource records to queriers in a particular scope is fairly straight forward.
>> --------------------------------------------------------
>> 
>> 
>> The article was not about DNS.  It was about "Persistent Personal Names for Globally Connected Mobile Devices" where "Users normally create personal names by introducing devices locally, on a common WiFi network for example. Once created, these names remain persistently bound to their targets as devices move. Personal names are intended to supplement and not replace global DNS names."  
> 
> you mean like mac addresses? those have a tendency to follow you around in ipv6...
> -----------------------------------------
> 
> 
> 
> <disclaimer> 
>   Still an IPv6 wussie...  :-) 
> </disclaimer>  
> 
> 
> Only if you design your network that way.  EUI-64 isn't required.

don't much matter, if you move around you're going get them a lot.

> scott
> 




From Valdis.Kletnieks at vt.edu  Tue May 17 22:37:21 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 17 May 2011 23:37:21 -0400
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: Your message of "Tue, 17 May 2011 20:22:23 PDT."
	<2CE23EE9-7BC7-46C6-A2F2-75DDBEFCDBC6@bogus.com>
References: <20110517195139.B96C78DD@resin16.mta.everyone.net>
	<2CE23EE9-7BC7-46C6-A2F2-75DDBEFCDBC6@bogus.com>
Message-ID: <36611.1305689841@localhost>

On Tue, 17 May 2011 20:22:23 PDT, Joel Jaeggli said:
> On May 17, 2011, at 7:51 PM, Scott Weeks wrote:
> > Only if you design your network that way.  EUI-64 isn't required.
> don't much matter, if you move around you're going get them a lot.

Of course, if you're moving around and getting EUI-64 addresses via SLAAC, you
can almost certainly use RFC4941 privacy addresses (instead of/in addition to)
your MAC-address based address.

Unless you end up behind a fascist firewall that actually checks that the
EUI-64 half of the SLAAC address actually matches your MAC address - but we all
know that firewalls are weak at IPv6 support, so probably nobody's actually
doing that checking. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110517/c292dd8e/attachment.bin>

From jmaslak at antelope.net  Tue May 17 23:18:44 2011
From: jmaslak at antelope.net (Joel Maslak)
Date: Tue, 17 May 2011 22:18:44 -0600
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <36611.1305689841@localhost>
References: <20110517195139.B96C78DD@resin16.mta.everyone.net>
	<2CE23EE9-7BC7-46C6-A2F2-75DDBEFCDBC6@bogus.com>
	<36611.1305689841@localhost>
Message-ID: <BANLkTinbBhX8Rw018AZz2=uwTND_3HZbkw@mail.gmail.com>

On Tue, May 17, 2011 at 9:37 PM, <Valdis.Kletnieks at vt.edu> wrote:


> Unless you end up behind a fascist firewall that actually checks that the
> EUI-64 half of the SLAAC address actually matches your MAC address - but we
> all
> know that firewalls are weak at IPv6 support, so probably nobody's actually
> doing that checking. :)
>


Nevermind you can change your MAC address easily on most networks, since
most don't provide any reasonable way of verifying that L2 packets are from
where they claim to be.

FWIW, Windows Vista and 7 default to using privacy addresses with SLAAC.
Even without that, today, in the IPv4 NAT world, it's pretty much possible
to uniquely identify a user nearly almost all of the time anyhow - at least
for web access.  This is thanks to browser fingerprinting - see
https://panopticlick.eff.org/browser-uniqueness.pdf

There's a lot of FUD about IPv6.  Yes, the addresses are longer.  But which
is easier - remembering all the intermediate layers of network translation
(likely two boxes for nearly every residential and small business user) or
an IPv6 address that is the same, regardless of whether you are another
customer on the same ISP, a public internet user, or an internal corporate
user?  Nevermind what it is like to debug IPSEC/PPTP/L2TP, SIP, or P2P
protocols with just one NAT involved.  Imagine doing that with two NAT
devices (CGN + home NAT).  If you haven't had that unfortunate pleasure,
than I envy you!  There's also no reason we should have to remember our IPv6
addresses.  Seriously.  There are about 50 protocols to name things on
networks, many of which are scope aware.  Among other things, it's why we
don't typically have to remember MAC addresses - ARP works and it works
well.  Just because bad design forced us to remember IPv4 addresses doesn't
mean our IPv6 networks should carry over that brokenness.

IPv6 is also already in widespread use (I would guess all 500 of the Fortune
500 have it somewhere on their network, albeit quite likely not
intentionally).  I use it almost daily for my Apple MobileMe account (albeit
typically tunneled over IPv4, all behind-the-scenes).  I also use it when I
stream music around my house (Bonjour will utilize IPv6, AirTunes typically
uses it).  Windows admins might be using it too (DirectAccess; MS Remote
Assistance if firewalls block connectivity then Windows will set up a direct
IPv6 link, tunneling through your firewalls and NAT...).  And Grandma very
well may be using it today (Windows "Home Groups" use IPv6).  I would guess
half of the family members of NANOG list subscribers are using IPv6 on a
daily basis - TODAY.  The danger is in ignoring what is already on your
networks.  Sure, you can't get to most websites via IPv6.  But it's being
used for plenty of useful work today, although mostly as a way around
firewalls and as isolated islands (not connected to the global IPv6
network).


From dudu.meyer at gmail.com  Wed May 18 00:23:19 2011
From: dudu.meyer at gmail.com (Eduardo Meyer)
Date: Wed, 18 May 2011 02:23:19 -0300
Subject: IRRd Add New Maintainer (irr_rpsl_submit ?)
Message-ID: <BANLkTinTSOvZVzAGGb036k3G8bQ0gmHvCA@mail.gmail.com>

Hello,

I have installed IRRd and I am trying to set it up, just for study
purposes. I have successfully mirrored some DBs but I cant handle to
make my very first maintainer creation. irrd-user.pdf seems to be the
only documentation around and it says nothing about "How the admin
creates a maintainer" it only says that the password used in irrd.conf
is the one.

Here's what I am trying:

# cat /tmp/step-1
mntner: MAINT-AS65500
descr: Test Inc
admin-c: Dudu M
tech-c:  Dudu M
upd-to: eduardo.meyer at gmail.com
mnt-nfy: eduardo.meyer at gmail.com
mnt-by: MAINT-AS65500
auth: MAIL-FROM eduardo.meyer at gmail.com
changed: eduardo.meyer at gmail.com 20110518
source: SAMPLEDB

And the command:

# cat /tmp/step-1 | /usr/local/sbin/irr_rpsl_submit -x -D -v -E
"db-admin at testing123.net" -c "23AWrNgTooc32"

I always get the following error:

May 18 04:23:16 [18267] #ERROR: New maintainers must be added by a DB
administrator.
May 18 04:23:16 [18267] Forwarding new request to db-admin at testing123.net

Can someone please help me? I know it seems very simple but I have no
idea how to do that.

Thank you.

-- 
===========
pessoal: dudu.meyer at gmail.com
profissional: ddm.farmaciap at saude.gov.br



From mrz at velvet.org  Wed May 18 00:31:48 2011
From: mrz at velvet.org (matthew zeier)
Date: Tue, 17 May 2011 22:31:48 -0700
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTi=G5ALG6RnVXjvPd3uX_qoSaWR_NA@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<20110517185742.GL20921@nm.lacutt>
	<BANLkTi=G5ALG6RnVXjvPd3uX_qoSaWR_NA@mail.gmail.com>
Message-ID: <B68F4C62-243F-4F64-A410-3E5BC2D97497@velvet.org>

I'll pile on here too - there's very little of Mozilla's web infrastructure that isn't behind Zeus.

> +1 for Zeus. Use it in our production network with great success.
> Magnitudes cheaper than a solution from F5, and doesn't hide the inner
> workings of the product if you want to do some things outside the
> scope of support.






From dudu.meyer at gmail.com  Wed May 18 01:35:50 2011
From: dudu.meyer at gmail.com (Eduardo Meyer)
Date: Wed, 18 May 2011 03:35:50 -0300
Subject: IRRd Add New Maintainer (irr_rpsl_submit ?)
In-Reply-To: <BANLkTinTSOvZVzAGGb036k3G8bQ0gmHvCA@mail.gmail.com>
References: <BANLkTinTSOvZVzAGGb036k3G8bQ0gmHvCA@mail.gmail.com>
Message-ID: <BANLkTikq=XuAjyGi_dD8rWWOTLKaKsEAgQ@mail.gmail.com>

On Wed, May 18, 2011 at 2:23 AM, Eduardo Meyer <dudu.meyer at gmail.com> wrote:
> Hello,
>
> I have installed IRRd and I am trying to set it up, just for study
> purposes. I have successfully mirrored some DBs but I cant handle to
> make my very first maintainer creation. irrd-user.pdf seems to be the
> only documentation around and it says nothing about "How the admin
> creates a maintainer" it only says that the password used in irrd.conf
> is the one.
>
> Here's what I am trying:
>
> # cat /tmp/step-1
> mntner: MAINT-AS65500
> descr: Test Inc
> admin-c: Dudu M
> tech-c: ?Dudu M
> upd-to: eduardo.meyer at gmail.com
> mnt-nfy: eduardo.meyer at gmail.com
> mnt-by: MAINT-AS65500
> auth: MAIL-FROM eduardo.meyer at gmail.com
> changed: eduardo.meyer at gmail.com 20110518
> source: SAMPLEDB
>
> And the command:
>
> # cat /tmp/step-1 | /usr/local/sbin/irr_rpsl_submit -x -D -v -E
> "db-admin at testing123.net" -c "23AWrNgTooc32"
>
> I always get the following error:
>
> May 18 04:23:16 [18267] #ERROR: New maintainers must be added by a DB
> administrator.
> May 18 04:23:16 [18267] Forwarding new request to db-admin at testing123.net
>
> Can someone please help me? I know it seems very simple but I have no
> idea how to do that.
>
> Thank you.

I managed adding the appropriated entries on my .db file by hand but I
believe there's a better way to do so, since this way a restart is
needed.

I am sorry asking it up here but I believe someone will be able to
help be since irrd-discuss mailing list is so quiet.



From randy at psg.com  Wed May 18 01:56:40 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 18 May 2011 08:56:40 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <4DD2F087.5050003@gmail.com>
References: <4DD2F087.5050003@gmail.com>
Message-ID: <m2oc30pkd3.wl%randy@psg.com>

another view might be that netflix's customers are eating the bandwidth

randy



From crosevear at skytap.com  Wed May 18 04:51:07 2011
From: crosevear at skytap.com (Carl Rosevear)
Date: Wed, 18 May 2011 02:51:07 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD2F087.5050003@gmail.com>
References: <4DD2F087.5050003@gmail.com>
Message-ID: <BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>

"Eating Up" sounds so overweight and unhealthy.  Since a good number
of us get paid for delivering bits, isn't this a good thing?  Always
glad to see bits and dollars flowing into the Internet, personally.
However must express severe dissatisfaction with the topic of the
thread a while ago referencing Comcast trying to charge providers for
delivery over their network.  Maybe I'm wrong, but I'm pretty happy
with the current model...  even if it means a $5/month residential
rate hike (or something).

--C



From leigh.porter at ukbroadband.com  Wed May 18 05:06:08 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 18 May 2011 11:06:08 +0100
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	AnyOther Company
In-Reply-To: <BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com>
	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
Message-ID: <B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>



> -----Original Message-----
> From: Carl Rosevear [mailto:crosevear at skytap.com]
> 
> "Eating Up" sounds so overweight and unhealthy.  Since a good number
> of us get paid for delivering bits, isn't this a good thing?  Always
> glad to see bits and dollars flowing into the Internet, personally.
> However must express severe dissatisfaction with the topic of the
> thread a while ago referencing Comcast trying to charge providers for
> delivery over their network.  Maybe I'm wrong, but I'm pretty happy
> with the current model...  even if it means a $5/month residential
> rate hike (or something).
> 
> --C
> 

Well it depends if Netflix pay for the bandwidth they use or if they get
it all for free with non settlement peering. If, suddenly, your business
model breaks because of a huge demand for high bandwidth services by
your customers then either you need to charge your customers more or
Netflix (or whoever) need to share the pie.

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From regnauld at nsrc.org  Wed May 18 05:32:49 2011
From: regnauld at nsrc.org (Phil Regnauld)
Date: Wed, 18 May 2011 12:32:49 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	AnyOther Company
In-Reply-To: <B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
References: <4DD2F087.5050003@gmail.com>
	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
Message-ID: <20110518103249.GF31890@macbook.catpipe.net>

Leigh Porter (leigh.porter) writes:
> 
> Well it depends if Netflix pay for the bandwidth they use

	You mean, customers have to pay for the bandwidth they use.
	I'm sure NetFlix is paying *their* network and other transit providers
	for outgoing bandwidth they consume.

> or if they get it all for free with non settlement peering. If, suddenly,
> your business model breaks because of a huge demand for high bandwidth
> services by your customers then either you need to charge your customers
> more or Netflix (or whoever) need to share the pie.

	Whoever ?  Nah, the consumers.  Bad business model, change business model.

	Phil



From bmanning at vacation.karoshi.com  Wed May 18 05:53:22 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 18 May 2011 10:53:22 +0000
Subject: MITM attacks or the Half/Circuit model - was Netflix Is Eating 
In-Reply-To: <20110518103249.GF31890@macbook.catpipe.net>
References: <4DD2F087.5050003@gmail.com>
	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
	<20110518103249.GF31890@macbook.catpipe.net>
Message-ID: <20110518105322.GA2353@vacation.karoshi.com.>

On Wed, May 18, 2011 at 12:32:49PM +0200, Phil Regnauld wrote:
> Leigh Porter (leigh.porter) writes:
> > 
> > Well it depends if Netflix pay for the bandwidth they use
> 
> 	You mean, customers have to pay for the bandwidth they use.
> 	I'm sure NetFlix is paying *their* network and other transit providers
> 	for outgoing bandwidth they consume.
> 	Phil


	note the classic Man-In-The-Middle attack here.  Or in other words, 
	the ITU half/circuit billing model for traditional telecomunications
	companies.   

	The telecom model is :  "I'll provide you with a tranist path to me,
	and trust me to hand your communications to the other party you wish
	to communicate with."  So GTE / MaBell gets to bill -both- parties
	at their usual usarious rates.  The problem here is that the incumbent
	operators have and are fighting tooth/nail to ensure their near monopoly
	on access.  
	So...
	We either need to re-regulate them to assure equal access at equitable rates
	-or- we need to de-regulate the access market and open up last mile ROW to
	all comers.  What we have done is de-regulate the access and retain the monopoly
	status on last mile ROW.  the incumbents have captive markets and can charge
	whatever the market will bear.  Great work if you can get it.

	If we truely beleived in end-2-end, we might see more systems
	using or trying to find other access paths ...   YMMV of course.

/bill



From askoorb+nanog at gmail.com  Wed May 18 06:10:20 2011
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Wed, 18 May 2011 12:10:20 +0100
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <m2oc30pkd3.wl%randy@psg.com>
References: <4DD2F087.5050003@gmail.com> <m2oc30pkd3.wl%randy@psg.com>
Message-ID: <BANLkTi=Sn_1aDT=SxO8-uO6jmb3OmHKMLQ@mail.gmail.com>

On Wed, May 18, 2011 at 7:56 AM, Randy Bush <randy at psg.com> wrote:
>
> another view might be that netflix's customers are eating the bandwidth
>
> randy
>

One of the UKs large residential ISPs publishes what their customers
use bandwidth for at
http://www.talktalkmembers.com/content/view/154/159/
"Streaming protocols" do use up a large % there, but only 2.9% is
listed as used by BBC iPlayer (like a no advertising version of Hulu,
but only for one broadcaster), Rapidshare and Facebook are 1.9% each,
whilst YouTube is 9.7%. ?It's kind of interesting.



From randy at psg.com  Wed May 18 07:36:10 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 18 May 2011 14:36:10 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	Any	Other Company
In-Reply-To: <BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com>
	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
Message-ID: <m262p8p4n9.wl%randy@psg.com>

> Since a good number of us get paid for delivering bits, isn't this a
> good thing?

at layer eight, having a single very large customer can be a source of
unhappy surprises.

randy



From lear at cisco.com  Wed May 18 07:39:37 2011
From: lear at cisco.com (Eliot Lear)
Date: Wed, 18 May 2011 14:39:37 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than	Any
	Other Company
In-Reply-To: <m262p8p4n9.wl%randy@psg.com>
References: <4DD2F087.5050003@gmail.com>	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
	<m262p8p4n9.wl%randy@psg.com>
Message-ID: <4DD3BE09.7070706@cisco.com>



On 5/18/11 2:36 PM, Randy Bush wrote:
> at layer eight, having a single very large customer can be a source of
> unhappy surprises.

Heh- no matter what layers one through seven are...



From scubacuda at gmail.com  Wed May 18 07:42:03 2011
From: scubacuda at gmail.com (Rogelio)
Date: Wed, 18 May 2011 09:42:03 -0300
Subject: blocking unwanted traffic from hitting gateway
Message-ID: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>

I've got about 1000 people hammering a Linux gateway with http
requests, but only about 150 of them are authenticated users for the
ISP.

Once someone authenticates, then I want their traffic to pass through
okay.  But if they're not an authenticated user, I would like to
ideally block those http requests (e.g. Google updater, AV scanners,
etc) from ever tying up my web server.

Is there some sort of box I could put in front (e.g. OpenBSD pf in
transparency mode) or maybe some sort of filter on the webserver?
This solution would need to be tied into the authentication services
so authenticated users hit the gateway.

-- 
Also on LinkedIn?? Feel free to connect if you too are an open
networker: scubacuda at gmail.com



From rdobbins at arbor.net  Wed May 18 07:54:13 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 18 May 2011 12:54:13 +0000
Subject: blocking unwanted traffic from hitting gateway
In-Reply-To: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
References: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
Message-ID: <F0161C19-B879-4EB3-A6CA-4B92ECB6B937@arbor.net>

On May 18, 2011, at 7:42 PM, Rogelio wrote:

> This solution would need to be tied into the authentication services so authenticated users hit the gateway.


So the attackers can just hammer the authentication subsystem and take it down, instead?

;>

By going the 'authentication' route in the sense you mean it, you'll make it even more trivially easy to DDoS the Web servers than is possible without such a system.

<http://www.mail-archive.com/nanog at nanog.org/msg17914.html>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From mpalmer at hezmatt.org  Wed May 18 07:55:29 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Wed, 18 May 2011 22:55:29 +1000
Subject: blocking unwanted traffic from hitting gateway
In-Reply-To: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
References: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
Message-ID: <20110518125529.GT10306@hezmatt.org>

On Wed, May 18, 2011 at 09:42:03AM -0300, Rogelio wrote:
> I've got about 1000 people hammering a Linux gateway with http
> requests, but only about 150 of them are authenticated users for the
> ISP.

Are you the ISP, or someone else?  Why is the gateway caring that the
requests are HTTP?  Is it also an HTTP server (and if so, does it matter
that it's a gateway?)

> Once someone authenticates, then I want their traffic to pass through
> okay.  But if they're not an authenticated user, I would like to
> ideally block those http requests (e.g. Google updater, AV scanners,
> etc) from ever tying up my web server.

What authentication mechanism are acceptable?  HTTP at the request level,
captive portal, custom app, etc etc etc.

> Is there some sort of box I could put in front (e.g. OpenBSD pf in
> transparency mode) or maybe some sort of filter on the webserver?

What risk or problem are you actually trying to mitigate against?  Sure, you
can put all sorts of things in front of it or on it, but are you just going
to be moving the problem (whatever it may be) to another box, adding
complexity for no good reason?

> This solution would need to be tied into the authentication services
> so authenticated users hit the gateway.

You might want to mention what "authentication services" you're using if you
want any useful recommendation about tying into it.

- Matt

-- 
The hypothalamus is one of the most important parts of the brain, involved
in many kinds of motivation, among other functions. The hypothalamus
controls the "Four F's": 1. fighting; 2. fleeing; 3. feeding; and 4. mating.
		-- Psychology professor in neuropsychology intro course



From wschultz at bsdboy.com  Wed May 18 08:43:55 2011
From: wschultz at bsdboy.com (Wil Schultz)
Date: Wed, 18 May 2011 06:43:55 -0700
Subject: blocking unwanted traffic from hitting gateway
In-Reply-To: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
References: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
Message-ID: <D214904E-ACDA-4B77-8394-5CC5B803ACA3@bsdboy.com>

On May 18, 2011, at 5:42 AM, Rogelio wrote:

> I've got about 1000 people hammering a Linux gateway with http
> requests, but only about 150 of them are authenticated users for the
> ISP.
> 
> Once someone authenticates, then I want their traffic to pass through
> okay.  But if they're not an authenticated user, I would like to
> ideally block those http requests (e.g. Google updater, AV scanners,
> etc) from ever tying up my web server.
> 
> Is there some sort of box I could put in front (e.g. OpenBSD pf in
> transparency mode) or maybe some sort of filter on the webserver?
> This solution would need to be tied into the authentication services
> so authenticated users hit the gateway.
> 
> -- 
> Also on LinkedIn?  Feel free to connect if you too are an open
> networker: scubacuda at gmail.com
> 

I use apache mod_rewrite in front of some stuff, there are a couple of examples where I look for a cookie and make sure it's set to some value before they can do something interesting. 
If the cookie doesn't exist, or if it's not set to the desired value, it goes somewhere else that's easily cacheable.

Here's an example, the cookie name is "loggedin" and the value is "true". If that doesn't match up it proxies over to login.jsp.

RewriteCond	%{HTTP_COOKIE} 	!loggedin=true
RewriteRule	^/(.*)			http://%{HTTP:Host}/login.jsp [P,L]

Good luck.

-wil


From todd at borked.ca  Wed May 18 09:44:25 2011
From: todd at borked.ca (Todd Snyder)
Date: Wed, 18 May 2011 10:44:25 -0400
Subject: IPv6 Conventions
Message-ID: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>

As I start working more and more with IPv6 and find myself having to address
services, I am wondering if there are any sort of written or unwritten
'conventions'/best practices that are being adopted about how to address
devices/servers/services.

Specifically:

1) Is there a general convention about addresses for DNS servers? NTP
servers? dhcp servers?
2) Are we tending to use different IPs for each service on a device?
3) Any common addresses/schemes for other common services?
(smtp/snmp/http/ldap/etc)?

Similarly, I've been referring to
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml for
a list of the 'reserved' space - are there any other blocks/conventions
around addressing that exist?

Finally, what tools do people find themselves using to manage IPv6 and
addressing?  It seems to me that IPAM is almost required to manage IPv6 in
any sane way, even for very small deployments (My home ISP gave me a /56 and
a /64).

I figured this was a fairly operational question/set of questions, so I hope
this is the right venue.

Cheers,

Todd.


From jra at baylink.com  Wed May 18 09:47:39 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 18 May 2011 10:47:39 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than	Any
	Other Company
In-Reply-To: <m262p8p4n9.wl%randy@psg.com>
Message-ID: <15574255.358.1305730059595.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Randy Bush" <randy at psg.com>

> > Since a good number of us get paid for delivering bits, isn't this a
> > good thing?
> 
> at layer eight, having a single very large customer can be a source of
> unhappy surprises.

I have first hand experience, having been laid off from my last IT 
director job because such a monopsony customer yanked 3/5 of its business
from my then employer.

Or ask *hundreds* of 35 year old companies that used to produce, nearly
exclusively, lots of specialized, flight certified parts for the Space
Shuttle Program.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jeroen at unfix.org  Wed May 18 10:04:09 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 18 May 2011 17:04:09 +0200
Subject: IPv6 Conventions
In-Reply-To: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
Message-ID: <4DD3DFE9.8050207@unfix.org>

On 2011-May-18 16:44, Todd Snyder wrote:
> As I start working more and more with IPv6 and find myself having to address
> services, I am wondering if there are any sort of written or unwritten
> 'conventions'/best practices that are being adopted about how to address
> devices/servers/services.
> 
> Specifically:
> 
> 1) Is there a general convention about addresses for DNS servers? NTP
> servers? dhcp servers?
> 2) Are we tending to use different IPs for each service on a device?
> 3) Any common addresses/schemes for other common services?
> (smtp/snmp/http/ldap/etc)?

Depends mostly on personal preference I would say.
Same applies to IPv4 as IPv6.

If you want a service to map always to a specific IP, eg because you
anycast/failover-IP it, then a "service IP" makes sense.

If you have a smaller deployment then just a service per host and/or
using CNAMEs (except for MX :) can make sense.

> Similarly, I've been referring to
> http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml for
> a list of the 'reserved' space - are there any other blocks/conventions
> around addressing that exist?

Only thing you might want to know is that 2000::/3 is global unicast,
that there is ULA and link-local. For the rest you don't need to know
anything about address blocks, just what the address space is that is
routed to you and that is what you get to use.

Except maybe for BGP where you want to limit what you want to
receive/announce. See google(gert ipv6) aka
http://www.space.net/~gert/RIPE/ipv6-filters.html for information on that.

> Finally, what tools do people find themselves using to manage IPv6 and
> addressing?  It seems to me that IPAM is almost required to manage IPv6 in
> any sane way, even for very small deployments (My home ISP gave me a /56 and
> a /64).

Textfiles, SQL databases. Depends on your need.

Greets,
 Jeroen



From iljitsch at muada.com  Wed May 18 10:05:31 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 18 May 2011 17:05:31 +0200
Subject: IPv6 Conventions
In-Reply-To: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
Message-ID: <91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>

On 18 mei 2011, at 16:44, Todd Snyder wrote:

> 1) Is there a general convention about addresses for DNS servers? NTP
> servers? dhcp servers?

There are people who do stuff like blah::53 for DNS, or blah:193:77:81:20 for a machine that has IPv4 address 193.177.81.20.

For the DNS, I always recommend using a separate /64 for each one, as that way you can move them to another location without having to renumber, and make the addresses short, so a ::1 address or something, because those are the IPv6 addresses that you end up typing a lot.

For all the other stuff, just use stateless autoconfig or start from ::1 when configuring things manually although there is also a little value in putting some of the IPv4 address in there. Note that 2001:db8::10.0.0.1 is a valid IPv6 address. Unfortunately when you see it copied back to you it shows up as 2001:db8::a00:1 which is less helpful.

> 2) Are we tending to use different IPs for each service on a device?

No, the same Internet Protocol.

> Finally, what tools do people find themselves using to manage IPv6 and
> addressing?

Stateless autoconfig for hosts, EUI-64 addressing for routers, VLAN ID in the subnet bits. That makes life simple. Simple be good.




From iljitsch at muada.com  Wed May 18 10:14:21 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 18 May 2011 17:14:21 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	AnyOther Company
In-Reply-To: <B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
References: <4DD2F087.5050003@gmail.com>
	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
Message-ID: <1FE42BB8-54BD-400C-B1F2-260E56FBCB52@muada.com>

On 18 mei 2011, at 12:06, Leigh Porter wrote:

> Well it depends if Netflix pay for the bandwidth they use or if they get
> it all for free with non settlement peering.

The whole point of peering is that both sides benefit. A bit like one bringing the traffic to the half way point and the other taking it the other half of the way.

Remember that all bits are paid for by the customers on both sides.

> If, suddenly, your business
> model breaks because of a huge demand for high bandwidth services by
> your customers then either you need to charge your customers more or
> Netflix (or whoever) need to share the pie.

Anyone who builds an internet-related business model without taking into account the bandwidth use graph going straight from bottom left to upper right has no business being in this business. So charge your customers more if you have to.

But charging third parties for the privilige of being able to send them the data your customers, who are already paying you, are trying to retrieve will turn the internet into the next cable or phone network where innovation happens within the confines of what the network owners feel comfortable with. In other words, the end of the internet as we know and love/hate it today. Don't slaughter the goose with the golden eggs.


From cb.list6 at gmail.com  Wed May 18 10:21:06 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 18 May 2011 08:21:06 -0700
Subject: IPv6 Conventions
In-Reply-To: <91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
	<91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
Message-ID: <BANLkTim6tKET9HF5Dn0JrFBH9SaC6O=ocw@mail.gmail.com>

On May 18, 2011 8:07 AM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:
>
> On 18 mei 2011, at 16:44, Todd Snyder wrote:
>
> > 1) Is there a general convention about addresses for DNS servers? NTP
> > servers? dhcp servers?
>
> There are people who do stuff like blah::53 for DNS, or blah:193:77:81:20
for a machine that has IPv4 address 193.177.81.20.
>
> For the DNS, I always recommend using a separate /64 for each one, as that
way you can move them to another location without having to renumber, and
make the addresses short, so a ::1 address or something, because those are
the IPv6 addresses that you end up typing a lot.
>
> For all the other stuff, just use stateless autoconfig or start from ::1
when configuring things manually although there is also a little value in
putting some of the IPv4 address in there. Note that 2001:db8::10.0.0.1 is a
valid IPv6 address. Unfortunately when you see it copied back to you it
shows up as 2001:db8::a00:1 which is less helpful.
>
> > 2) Are we tending to use different IPs for each service on a device?
>
> No, the same Internet Protocol.
>
> > Finally, what tools do people find themselves using to manage IPv6 and
> > addressing?
>
> Stateless autoconfig for hosts, EUI-64 addressing for routers, VLAN ID in
the subnet bits. That makes life simple. Simple be good.
>

You may want to use some randomness to limit address scanning.  Ymmv on how
well this works or applies, I do it.

Cb
>


From bhmccie at gmail.com  Wed May 18 11:01:04 2011
From: bhmccie at gmail.com (Hammer)
Date: Wed, 18 May 2011 11:01:04 -0500
Subject: Experience with Open Source load balancers?
In-Reply-To: <B68F4C62-243F-4F64-A410-3E5BC2D97497@velvet.org>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<20110517185742.GL20921@nm.lacutt>
	<BANLkTi=G5ALG6RnVXjvPd3uX_qoSaWR_NA@mail.gmail.com>
	<B68F4C62-243F-4F64-A410-3E5BC2D97497@velvet.org>
Message-ID: <BANLkTi=0mVCf5tn+UtkHUxnJFkoBQ5zQmQ@mail.gmail.com>

I've worked with everything over the years. BigIP, CSS, CSM, ACE (blows),
NetScaler, say when. I've been thru a few RFPs and bake offs and also
evaluated open source options.

1. If you are looking for simple round robin load balancing with decent load
capabilities then there are several open source options in this thread that
may work. As long as you understand that you are going to be expected to
support them.....

2. If you are pushing features. SSL termination. Header rewrites. Payload
inspection (NetScaler does application firewalling on the same appliance).
Or other complexities and you are having to deal with enterprise traffic
volume you might be better off with one of the big vendors. Applications
these days are more and more complicated and a high end load balancer with a
stable feature set can often rescue your AppDev team and make you a hero.

Recommend: F5 and Citrix Netscaler. If you are looking to combine your L7 FW
into your LB then you might lean towards NetScaler. If you are looking at
seperating those duties you can look at F5. IRules (F5) are the bomb.




 -Hammer-

"I was a normal American nerd."
-Jack Herer





On Wed, May 18, 2011 at 12:31 AM, matthew zeier <mrz at velvet.org> wrote:

> I'll pile on here too - there's very little of Mozilla's web infrastructure
> that isn't behind Zeus.
>
> > +1 for Zeus. Use it in our production network with great success.
> > Magnitudes cheaper than a solution from F5, and doesn't hide the inner
> > workings of the product if you want to do some things outside the
> > scope of support.
>
>
>
>
>


From sthaug at nethelp.no  Wed May 18 11:39:52 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 18 May 2011 18:39:52 +0200 (CEST)
Subject: IPv6 Conventions
In-Reply-To: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
Message-ID: <20110518.183952.48522100.sthaug@nethelp.no>

> 1) Is there a general convention about addresses for DNS servers? NTP
> servers? dhcp servers?

DNS server addresses should be short and easy to tape, as already
mentioned.

> 2) Are we tending to use different IPs for each service on a device?

In many cases yes - because that makes it possible to easily move the
service to a different box.

> Finally, what tools do people find themselves using to manage IPv6 and
> addressing?

Excel spreadsheets, HaCi.

>  It seems to me that IPAM is almost required to manage IPv6 in
> any sane way, even for very small deployments (My home ISP gave me a /56 and
> a /64).

At least as long as you use static addresses. We like static, and tend
to stay away from SLAAC. We do *not* use EUI-64 for router links. For
customer links we use /64, for backbone links we use /124 (ensures
that SLAAC can never ever be used on the link, and also that the two
ends can be numbered ending in 1 and 2 - nice and simple).

Steinar Haug, Nethelp consulting, sthaug at nethelp.no



From mrz at velvet.org  Wed May 18 12:25:26 2011
From: mrz at velvet.org (matthew zeier)
Date: Wed, 18 May 2011 10:25:26 -0700
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTi=0mVCf5tn+UtkHUxnJFkoBQ5zQmQ@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<20110517185742.GL20921@nm.lacutt>
	<BANLkTi=G5ALG6RnVXjvPd3uX_qoSaWR_NA@mail.gmail.com>
	<B68F4C62-243F-4F64-A410-3E5BC2D97497@velvet.org>
	<BANLkTi=0mVCf5tn+UtkHUxnJFkoBQ5zQmQ@mail.gmail.com>
Message-ID: <3DBE6B80-6889-49F8-9689-65667EDE40E5@velvet.org>

>  
> Recommend: F5 and Citrix Netscaler. If you are looking to combine your L7 FW into your LB then you might lean towards NetScaler. If you are looking at seperating those duties you can look at F5. IRules (F5) are the bomb.

Except that under (Mozilla) load, Netscaler fell apart.  F5, at the time, could not handle the logging rate I required.  Mozilla load is typically defined as high connection rate, low traffic per connection and mostly all SSL.  

During the Firefox 4 release, we peaked globally at 12Gbps, a significant portion of which was pushed out of three Zeus clusters with L7 rules and some non-trivial traffic script rules and a heck of a lot of content caching.  Of all the systems seeing increased usage during the Fx4 release, this wasn't where my worries were :)

A slightly older post,

http://blog.mozilla.com/mrz/2008/12/04/load-balancer-performance-issues-fxfeedsmozillaorg-versioncheck/




From jeroen at mompl.net  Wed May 18 14:01:10 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 18 May 2011 12:01:10 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD2991B.6040207@netwolves.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>	<8212.1305636997@nsa.vix.com>
	<4DD2991B.6040207@netwolves.com>
Message-ID: <4DD41776.7020301@mompl.net>

Steve Clark wrote:
> This is all very confusing to me. How are meaningful names going to 
> assigned automatically?
> Right now I see something like ool-6038bdcc.static.optonline.net for one 
> of our servers, how does this
> mean anything to anyone else?

Does http://?????-?????????.???/ mean more to you?

Or http://xn--4gbrim.xn----ymcbaaajlc6dj7bxne2c.xn--wgbh1c which is what 
it translates to in your browser.

Just saying... ;-)

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From andreas at livejournalinc.com  Wed May 18 14:23:12 2011
From: andreas at livejournalinc.com (Andreas Echavez)
Date: Wed, 18 May 2011 12:23:12 -0700
Subject: Experience with Open Source load balancers?
In-Reply-To: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
Message-ID: <BANLkTimVWenfU7fHZPpEWkLCnf0QAEDSCQ@mail.gmail.com>

We're using both an F5 BigIP as well as Nginx (open source software) in a
production environment.

They both have their merits, but when we recently came under some advanced
DDoSes (slowloris, slow POST, and more), we couldn't process certain types
of layer 7 insepction/modification because it was too heavy for the F5 to
handle. Nginx was more cost effective because we could scale laterally with
cheap commodity hardware.

This isn't a knock on the BigIP though; it's a much better piece of
equipment, has commercial support, and a fantastic web interface. With Nginx
you might find yourself compiling modules in by hand and writing config
files.

Ultimately, the open source solution is going to stand the test of time
better. It all depends on who's paying the bills, and what your time is
worth. Nginx was specifically worth the effort for us because we had unique
traffic demands that change too quickly for a commercial solution.

Thanks,
Andreas


On Mon, May 16, 2011 at 4:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com>wrote:

> Greetings all.
>
> I've been tasked with comparing the use of open source load balancing
> software against commercially available off the shelf hardware such as F5,
> which is what we currently use.  We use the load balancers for traditional
> load balancing, full proxy for http/ssl traffic, ssl termination and
> certificate management, ssl and http header manipulation, nat, high
> availability of the physical hardware and stateful failover of the tcp
> sessions.  These units will be placed at the customer prem supporting our
> applications and services and we'll need to support them accordingly.
>
> Now my "knee jerk" reaction to this is that it's a really bad idea.  It is
> the heart and soul of our data center network after all.  However, once I
> started to think about it I realized that I hadn't had any real experience
> with this solution beyond tinkering with it at home and reading about it in
> years past.
>
> Can anyone offer any operational insight and real world experiences with
> these solutions?
>
> TIA, replies off list are welcomed.
>
>
> Regards,
>
> Bryan
>
>


From jeroen at mompl.net  Wed May 18 14:36:35 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 18 May 2011 12:36:35 -0700
Subject: Yahoo and IPv6
In-Reply-To: <22746.1305649774@nsa.vix.com>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>	<8212.1305636997@nsa.vix.com>
	<4DD2991B.6040207@netwolves.com> <22746.1305649774@nsa.vix.com>
Message-ID: <4DD41FC3.9090109@mompl.net>

Paul Vixie wrote:
> time in Nicaragua he said that he has a lot of days like this and he'd
> like more work to be possible when only local connectivity was available.
> 
> Compelling stuff.  Pity there's no global market for localized services
> or we'd already have it.  Nevertheless this must and will get fixed, and
> we should be the generation who does it.

I have found that the general theme is to move services that were 
traditionally available inside an office network (source control, email, 
ticketing/bug tracking systems, storing documents, corporate "wikis" 
etc.) to an external place, perhaps even outsourced to one of the 
virtual server or "software as a service" providers.

I am not a particular fan of that trend, but I can see the pros and cons 
of doing it. It doesn't look like that's going to stop any time soon, 
let alone be (partially) reversed.

Regards,
Jeroen

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From michael.holstein at csuohio.edu  Wed May 18 14:46:14 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Wed, 18 May 2011 15:46:14 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <4DD2F087.5050003@gmail.com>
References: <4DD2F087.5050003@gmail.com>
Message-ID: <4DD42206.20407@csuohio.edu>


> http://e.businessinsider.com/public/184962
>

Somebody should invent a a way to stream groups of shows simultaneously
and just arrange for people to watch the desired stream at a particular
time. Heck, maybe even do it wireless.

problem solved, right?

Cheers,

Michael Holstein
Cleveland State University




From lstewart at superb.net  Wed May 18 14:56:54 2011
From: lstewart at superb.net (Landon Stewart)
Date: Wed, 18 May 2011 12:56:54 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD42206.20407@csuohio.edu>
References: <4DD2F087.5050003@gmail.com>
	<4DD42206.20407@csuohio.edu>
Message-ID: <BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>

On Wed, May 18, 2011 at 12:46 PM, Michael Holstein <
michael.holstein at csuohio.edu> wrote:

>
> > http://e.businessinsider.com/public/184962
> >
>
> Somebody should invent a a way to stream groups of shows simultaneously
> and just arrange for people to watch the desired stream at a particular
> time. Heck, maybe even do it wireless.
>
> problem solved, right?
>
>
There was a lengthy discussion about that on NANOG a week or so ago.  I
don't claim to understand all facets of multicast but it could be a sort of
way to operate "tv station" type scheduled programming for streaming media.
There's no way to pause, rewind or otherwise seek multicasted media though.
It would be going backwards in terms of what consumers want these days.

http://en.wikipedia.org/wiki/Multicast
http://en.wikipedia.org/wiki/Mbone

It seems to me that every provider these days is using a year 2K business
model with 2011 bandwidth requirements and then complaining that consumers
are transferring too much data.

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From dholmes at mwdh2o.com  Wed May 18 15:01:01 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Wed, 18 May 2011 13:01:01 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <4DD42206.20407@csuohio.edu>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
Message-ID: <922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>

I think this shows the need for an Internet-wide multicast implementation. Although I can recall working on a product that delivered satellite multicast streams (with each multicast group corresponding to individual TV stations) to telco CO's. This enabled the telco to implement multicast at the edge of their networks, where user broadband clients would issue multicast joins only as far as the CO. If I recall this was implemented with the old Cincinnati Bell telco. I admit there are a lot of CO's and cable head-ends though for this solution to scale.

-----Original Message-----
From: Michael Holstein [mailto:michael.holstein at csuohio.edu]
Sent: Wednesday, May 18, 2011 12:46 PM
To: Roy
Cc: nanog
Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company


> http://e.businessinsider.com/public/184962
>

Somebody should invent a a way to stream groups of shows simultaneously
and just arrange for people to watch the desired stream at a particular
time. Heck, maybe even do it wireless.

problem solved, right?

Cheers,

Michael Holstein
Cleveland State University



This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.



From morrowc.lists at gmail.com  Wed May 18 15:02:19 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 16:02:19 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
Message-ID: <BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>

On Wed, May 18, 2011 at 3:56 PM, Landon Stewart <lstewart at superb.net> wrote:
> There was a lengthy discussion about that on NANOG a week or so ago. ?I
> don't claim to understand all facets of multicast but it could be a sort of
> way to operate "tv station" type scheduled programming for streaming media.
> There's no way to pause, rewind or otherwise seek multicasted media though.
> It would be going backwards in terms of what consumers want these days.
>

why not permit your users to subscribe to shows/instances, stream them
on-demand for viewing later... and leave truly live content
(news/sports/etc) as is, with only the ability to pause/rewind?

how is this different from broadcast tv today though?



From ryanczak at gmail.com  Wed May 18 15:05:43 2011
From: ryanczak at gmail.com (Matt Ryanczak)
Date: Wed, 18 May 2011 16:05:43 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
Message-ID: <4DD42697.6040308@gmail.com>

On 05/18/2011 04:01 PM, Holmes,David A wrote:
> I think this shows the need for an Internet-wide multicast implementation. Although I can recall working on a product that delivered satellite multicast streams (with each multicast group corresponding to individual TV stations) to telco CO's. This enabled the telco to implement multicast at the edge of their networks, where user broadband clients would issue multicast joins only as far as the CO. If I recall this was implemented with the old Cincinnati Bell telco. I admit there are a lot of CO's and cable head-ends though for this solution to scale.

I don't see how multicast necasarily solves the netflix on-demand video 
problem. you have millions of users streaming different content at 
different times. multicast is great for the world cup but how does it 
solve the video on demand problem?



From jabley at hopcount.ca  Wed May 18 15:05:30 2011
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 18 May 2011 16:05:30 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
Message-ID: <9C6F7172-55E2-4E4C-8596-EDC43D3F14D1@hopcount.ca>


On 2011-05-18, at 16:01, Holmes,David A wrote:

> I think this shows the need for an Internet-wide multicast implementation.

Or perhaps even some kind of new technology that is independent of the Internet! Imagine such futuristic ideas as solar-powered spacecraft in orbit around the planet bouncing content back across massive areas so that everybody can pick them up at once.

Crazy stuff.


Joe




From lstewart at superb.net  Wed May 18 15:07:32 2011
From: lstewart at superb.net (Landon Stewart)
Date: Wed, 18 May 2011 13:07:32 -0700
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
Message-ID: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>

Lets say you had a file that was 1,000,000,000 characters consisting of
8,000,000,000bits.  What if instead of transferring that file through the
interwebs you transmitted a mathematical equation to tell a computer on the
other end how to *construct* that file.  First you'd feed the file into a
cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
equation somehow.  Sure this would take time, I realize that.  The equation
would then be transmitted to the other computer where it would use its
mad-math-skillz to *figure out the answer* which would theoretically be the
same pattern of bits.  Thus the same file would emerge on the other end.

The real question here is how long would it take for a regular computer to
do this kind of math?

Just a weird idea I had.  If it's a good idea then please consider this
intellectual property.  LOL


-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From dorn at hetzel.org  Wed May 18 15:09:57 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 18 May 2011 16:09:57 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD42697.6040308@gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<4DD42697.6040308@gmail.com>
Message-ID: <BANLkTi=WzuLh+bC-i25KYe4GF8rA-2gGLw@mail.gmail.com>

>
>
> I don't see how multicast necasarily solves the netflix on-demand video
> problem. you have millions of users streaming different content at different
> times. multicast is great for the world cup but how does it solve the video
> on demand problem?
>
> I suppose in theory if you have tivo-like devices at the endpoints then
they can capture popular programs at the time of multicast for later
viewing.  Whether this is better than capturing the same programs over a
broadcast medium for later playback, I don't know...


From jna at retina.net  Wed May 18 15:12:05 2011
From: jna at retina.net (John Adams)
Date: Wed, 18 May 2011 13:12:05 -0700
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <BANLkTi===B8pvQJssYWUFHGNj5gjnodp=w@mail.gmail.com>

We call that "Compression."

-j


On Wed, May 18, 2011 at 1:07 PM, Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
>
> The real question here is how long would it take for a regular computer to
> do this kind of math?
>
> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL
>
>
> --
> Landon Stewart <LStewart at SUPERB.NET>
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>


From cb.list6 at gmail.com  Wed May 18 15:13:59 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 18 May 2011 13:13:59 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
Message-ID: <BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>

On Wed, May 18, 2011 at 1:02 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Wed, May 18, 2011 at 3:56 PM, Landon Stewart <lstewart at superb.net> wrote:
>> There was a lengthy discussion about that on NANOG a week or so ago. ?I
>> don't claim to understand all facets of multicast but it could be a sort of
>> way to operate "tv station" type scheduled programming for streaming media.
>> There's no way to pause, rewind or otherwise seek multicasted media though.
>> It would be going backwards in terms of what consumers want these days.
>>
>
> why not permit your users to subscribe to shows/instances, stream them
> on-demand for viewing later... and leave truly live content
> (news/sports/etc) as is, with only the ability to pause/rewind?
>
> how is this different from broadcast tv today though?
>

It's not.  These people need a pair of rabbit ears and a DVR.

CB



From jack at crepinc.com  Wed May 18 15:15:34 2011
From: jack at crepinc.com (Jack Carrozzo)
Date: Wed, 18 May 2011 16:15:34 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>

That's basically what compression is. Except rarely (read: never) does your
Real Data (tm) fit just one equation, hence the various compression
algorithms that look for patterns etc etc.

-J

On Wed, May 18, 2011 at 4:07 PM, Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
>
> The real question here is how long would it take for a regular computer to
> do this kind of math?
>
> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL
>
>
> --
> Landon Stewart <LStewart at SUPERB.NET>
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>


From randy at psg.com  Wed May 18 15:15:40 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 18 May 2011 22:15:40 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	Any	Other Company
In-Reply-To: <BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
Message-ID: <m2ei3v934j.wl%randy@psg.com>

> why not permit your users to subscribe to shows/instances, stream them
> on-demand for viewing later... and leave truly live content
> (news/sports/etc) as is, with only the ability to pause/rewind?
> 
> how is this different from broadcast tv today though?

for some of us, the thing that is wonderful about netflix is the long
tail.  my tastes are a sigma or three out.

randy



From jabley at hopcount.ca  Wed May 18 15:16:01 2011
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 18 May 2011 16:16:01 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=WzuLh+bC-i25KYe4GF8rA-2gGLw@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<4DD42697.6040308@gmail.com>
	<BANLkTi=WzuLh+bC-i25KYe4GF8rA-2gGLw@mail.gmail.com>
Message-ID: <486062D6-59FF-4732-8C31-91A44DECAB46@hopcount.ca>


On 2011-05-18, at 16:09, Dorn Hetzel wrote:

> they can capture popular programs at the time of multicast for later
> viewing.  Whether this is better than capturing the same programs over a
> broadcast medium for later playback, I don't know...

... or a peer to peer medium, which is (as I understand it) how people who really want this to happen today manage to do it. The problem is not the distribution so much as the need to shoe-horn this network efficiency into the content business model.

I heard similar stories about the early days of distributing digital copies of movies to theatres for presentation -- the technology was trivial, even with fairly low-power commodity CPUs, until you insist that the content be encrypted so that nobody can walk off with it without paying.


Joe




From michael.holstein at csuohio.edu  Wed May 18 15:18:37 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Wed, 18 May 2011 16:18:37 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <4DD4299D.8050402@csuohio.edu>


> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.
>   

It's easy .. the zeros are fatter than the ones.

http://dilbert.com/strips/comic/2004-12-09/

~Mike.



From joelja at bogus.com  Wed May 18 15:18:12 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 18 May 2011 13:18:12 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
Message-ID: <623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>


On May 18, 2011, at 1:01 PM, Holmes,David A wrote:

> I think this shows the need for an Internet-wide multicast implementation. 

there's a pretty longtailed distribution on what people might chose to stream. static content is ameniable to distribution via cdn (which is frankly a degenerate form of multicast), but lets face it, how many people watched "Charles Mingus: Triumph of the Underdog" in east palo alto last night at 10pm.  

> Although I can recall working on a product that delivered satellite multicast streams (with each multicast group corresponding to individual TV stations) to telco CO's. This enabled the telco to implement multicast at the edge of their networks, where user broadband clients would issue multicast joins only as far as the CO. If I recall this was implemented with the old Cincinnati Bell telco. I admit there are a lot of CO's and cable head-ends though for this solution to scale.
> 
> -----Original Message-----
> From: Michael Holstein [mailto:michael.holstein at csuohio.edu]
> Sent: Wednesday, May 18, 2011 12:46 PM
> To: Roy
> Cc: nanog
> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
> 
> 
>> http://e.businessinsider.com/public/184962
>> 
> 
> Somebody should invent a a way to stream groups of shows simultaneously
> and just arrange for people to watch the desired stream at a particular
> time. Heck, maybe even do it wireless.
> 
> problem solved, right?
> 
> Cheers,
> 
> Michael Holstein
> Cleveland State University
> 
> 
> 
> This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
> 
> 




From dorn at hetzel.org  Wed May 18 15:18:38 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 18 May 2011 16:18:38 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <BANLkTinOJfADn1gnU9Ue2oU8q+7z6WggYQ@mail.gmail.com>

On Wed, May 18, 2011 at 4:07 PM, Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
>
> The real question here is how long would it take for a regular computer to
> do this kind of math?
>
> The real question is whether this is possible.  And the short answer is No,
at least not in general.

Now if your file has patterns that make it compressible, you can make it
smaller, but not
all files can be compressed this way, at least not in a way that makes them
smaller.

To understand why, consider the case of a file of one byte, or 8 bits.
 There are 256 possible
files of this size, 00000000, 00000001, 00000010, ..., 11111101, 11111110,
1111111.

Since each code we send must generate a unique file (or what's the point, we
need 256 different codes
to represent each possible file), but the shortest general way to write 256
different codes is
still 8 bits long.  Now, we can use coding schemes and say that the one-bit
value 1 represents 11111111
because that file happens a lot.  Then we could use 01 to represent
something else, but
we can't use 1 at the beginning again because we couldn't tell that from the
file named by 1.

Bottom line, for some codes to be shorter than the file they represent,
others must be longer...

So if files have a lot of repetition, you can get a win, but for "random"
data, not so much :(


From sfouant at shortestpathfirst.net  Wed May 18 15:19:26 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Wed, 18 May 2011 16:19:26 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possible	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <007b01cc1598$e32b9bc0$a982d340$@net>

> -----Original Message-----
> From: Landon Stewart [mailto:lstewart at superb.net]
> Sent: Wednesday, May 18, 2011 4:08 PM
> To: nanog
> Subject: Had an idea - looking for a math buff to tell me if it's
> possible with today's technology.
> 
> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through
> the
> interwebs you transmitted a mathematical equation to tell a computer on
> the
> other end how to *construct* that file.  First you'd feed the file into
> a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into
> an
> equation somehow.  Sure this would take time, I realize that.  The
> equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be
> the
> same pattern of bits.  Thus the same file would emerge on the other
> end.

Not exactly the same thing, but application acceleration of this sort has
been around for some time - 

http://www.riverbed.com/us/
http://www.juniper.net/us/en/products-services/application-acceleration/wxc-
series/
http://www.cisco.com/en/US/products/ps5680/Products_Sub_Category_Home.html

Stefan Fouant





From jra at baylink.com  Wed May 18 15:16:21 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 18 May 2011 16:16:21 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
Message-ID: <25696444.392.1305749781219.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Christopher Morrow" <morrowc.lists at gmail.com>

> why not permit your users to subscribe to shows/instances, stream them
> on-demand for viewing later... and leave truly live content
> (news/sports/etc) as is, with only the ability to pause/rewind?
> 
> how is this different from broadcast tv today though?

It's on the Internet.  So it's cooler.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From bonomi at mail.r-bonomi.com  Wed May 18 15:27:14 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 18 May 2011 15:27:14 -0500 (CDT)
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <201105182027.p4IKREWP057007@mail.r-bonomi.com>



Wildly off-topic for the NANOG mailing-list, as it has -zero- relevance to
'network operations'

> Date: Wed, 18 May 2011 13:07:32 -0700
> Subject: Had an idea - looking for a math buff to tell me if it's possible
> 	with today's technology.
> From: Landon Stewart <lstewart at superb.net>
> To: nanog <nanog at nanog.org>
>
> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
>
> The real question here is how long would it take for a regular computer to
> do this kind of math?

I have, on my computer, an encoder/decoder that does _exactly_ that.

Both the encoder and decoder are _amazingly_ fast -- as fast as a file copy,
in fact.

the average size of the tranmsitted files, across all possible input files
is exactly 100% of the size of the input files.  (one *cannot* do better
than that, across all possible inputs -- see the 'counting' problem, in
data-compression theory)

> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL

'Weird' is one word for it.  You might want to read up on the subject
of 'data compression', to get an idea of how things work.

See also "polynominial curve-fitting", for the real-world limits of your
theory.
for the real-world limits of your
theory.






From jeroen at mompl.net  Wed May 18 15:27:50 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 18 May 2011 13:27:50 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <9C6F7172-55E2-4E4C-8596-EDC43D3F14D1@hopcount.ca>
References: <4DD2F087.5050003@gmail.com>
	<4DD42206.20407@csuohio.edu>	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<9C6F7172-55E2-4E4C-8596-EDC43D3F14D1@hopcount.ca>
Message-ID: <4DD42BC6.8030706@mompl.net>

Joe Abley wrote:
> Or perhaps even some kind of new technology that is independent of the Internet! Imagine such futuristic ideas as solar-powered spacecraft in orbit around the planet bouncing content back across massive areas so that everybody can pick them up at once.
> 
> Crazy stuff.

You mean like a sputnik?

Crazy indeed...

-- 
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html



From morrowc.lists at gmail.com  Wed May 18 15:30:28 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 16:30:28 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <m2ei3v934j.wl%randy@psg.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<m2ei3v934j.wl%randy@psg.com>
Message-ID: <BANLkTiniFziKWikb_RtewaUdi16GkfG_Fg@mail.gmail.com>

On Wed, May 18, 2011 at 4:15 PM, Randy Bush <randy at psg.com> wrote:
>> why not permit your users to subscribe to shows/instances, stream them
>> on-demand for viewing later... and leave truly live content
>> (news/sports/etc) as is, with only the ability to pause/rewind?
>>
>> how is this different from broadcast tv today though?
>
> for some of us, the thing that is wonderful about netflix is the long
> tail. ?my tastes are a sigma or three out.

usenet is over ->

in all seriousness, if the content was available and you could request
it be streamed to you 'sometime tomorrow' or 'sometime before Friday',
you and the other people like you coudl get serviced on a singular
'stream'.  I suspect that the vast majority of content is in the 1st
sigma... and again, servicing everyone with a limited number of
multicast'd streams seems like it would be nice. even falling back to
unicast for some set of mathematically/cost-conscious examples seems
like a win here.



From morrowc.lists at gmail.com  Wed May 18 15:31:58 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 16:31:58 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
Message-ID: <BANLkTi=59GT+9i6hgMpdwYZ2tkXQp5Myaw@mail.gmail.com>

On Wed, May 18, 2011 at 4:18 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>
> On May 18, 2011, at 1:01 PM, Holmes,David A wrote:
>
>> I think this shows the need for an Internet-wide multicast implementation.
>
> there's a pretty longtailed distribution on what people might chose to stream. static content is ameniable to distribution via cdn (which is frankly a degenerate form of multicast), but lets face it, how many people watched "Charles Mingus: Triumph of the Underdog" in east palo alto last night at 10pm.

slightly wrong question: "How many people last 'period of time' chose,
early enough, to want to watch CMTotU lastnight at 10."

if the number is greater than X, multicast it with time to deliver
before 10pm pdt start time. If it's less, unicast...



From dorn at hetzel.org  Wed May 18 15:33:14 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 18 May 2011 16:33:14 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
Message-ID: <BANLkTi=BLCYGmQ5zstN_008+d5H5hd8Kxw@mail.gmail.com>

If we're really talking efficiency, the "popular" stuff should probably
stream out over the bird of your choice (directv, etc) because it's hard to
beat millions of dishes and dvr's and no cable plant.

Then what won't fit on the bird goes unicast IP from the nearest CDN.   Kind
of like the "on demand over broadband" on my satellite box.  Their selection
sucks, but the model is valid.

On Wed, May 18, 2011 at 4:18 PM, Joel Jaeggli <joelja at bogus.com> wrote:

>
> On May 18, 2011, at 1:01 PM, Holmes,David A wrote:
>
> > I think this shows the need for an Internet-wide multicast
> implementation.
>
> there's a pretty longtailed distribution on what people might chose to
> stream. static content is ameniable to distribution via cdn (which is
> frankly a degenerate form of multicast), but lets face it, how many people
> watched "Charles Mingus: Triumph of the Underdog" in east palo alto last
> night at 10pm.
>
> > Although I can recall working on a product that delivered satellite
> multicast streams (with each multicast group corresponding to individual TV
> stations) to telco CO's. This enabled the telco to implement multicast at
> the edge of their networks, where user broadband clients would issue
> multicast joins only as far as the CO. If I recall this was implemented with
> the old Cincinnati Bell telco. I admit there are a lot of CO's and cable
> head-ends though for this solution to scale.
> >
> > -----Original Message-----
> > From: Michael Holstein [mailto:michael.holstein at csuohio.edu]
> > Sent: Wednesday, May 18, 2011 12:46 PM
> > To: Roy
> > Cc: nanog
> > Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than
> Any Other Company
> >
> >
> >> http://e.businessinsider.com/public/184962
> >>
> >
> > Somebody should invent a a way to stream groups of shows simultaneously
> > and just arrange for people to watch the desired stream at a particular
> > time. Heck, maybe even do it wireless.
> >
> > problem solved, right?
> >
> > Cheers,
> >
> > Michael Holstein
> > Cleveland State University
> >
> >
> >
> > This communication, together with any attachments or embedded links, is
> for the sole use of the intended recipient(s) and may contain information
> that is confidential or legally protected. If you are not the intended
> recipient, you are hereby notified that any review, disclosure, copying,
> dissemination, distribution or use of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> the sender immediately by return e-mail message and delete the original and
> all copies of the communication, along with any attachments or embedded
> links, from your system.
> >
> >
>
>
>


From smb at cs.columbia.edu  Wed May 18 15:33:19 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Wed, 18 May 2011 16:33:19 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <717D7566-4B99-4C05-AE77-8F964C8BFE41@cs.columbia.edu>


On May 18, 2011, at 4:07 32PM, Landon Stewart wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
> 
> The real question here is how long would it take for a regular computer to
> do this kind of math?
> 
> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL

http://en.wikipedia.org/wiki/Kolmogorov_complexity

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From morrowc.lists at gmail.com  Wed May 18 15:33:34 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 16:33:34 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <4DD4299D.8050402@csuohio.edu>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<4DD4299D.8050402@csuohio.edu>
Message-ID: <BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>

On Wed, May 18, 2011 at 4:18 PM, Michael Holstein
<michael.holstein at csuohio.edu> wrote:
>
>> Just a weird idea I had. ?If it's a good idea then please consider this
>> intellectual property.
>>
>
> It's easy .. the zeros are fatter than the ones.

no no no.. it's simply, since the OP posited a math solution, md5.
ship the size of file + hash, compute file on the other side. All
files can be moved anywhere regardless of the size of the file in a
single packet.


The solution is left as an exercise for the reader.



From aredridel at nbtsc.org  Wed May 18 15:35:17 2011
From: aredridel at nbtsc.org (Aria Stewart)
Date: Wed, 18 May 2011 14:35:17 -0600
Subject: Had an idea - looking for a math buff to tell me if it's
	possible with today's technology.
In-Reply-To: <BANLkTinOJfADn1gnU9Ue2oU8q+7z6WggYQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinOJfADn1gnU9Ue2oU8q+7z6WggYQ@mail.gmail.com>
Message-ID: <D3B2A7BD946C4C6C84A81753E544E74E@nbtsc.org>


On Wednesday, May 18, 2011 at 2:18 PM, Dorn Hetzel wrote: 
> On Wed, May 18, 2011 at 4:07 PM, Landon Stewart <lstewart at superb.net> wrote:
> 
> > Lets say you had a file that was 1,000,000,000 characters consisting of
> > 8,000,000,000bits. What if instead of transferring that file through the
> > interwebs you transmitted a mathematical equation to tell a computer on the
> > other end how to *construct* that file. First you'd feed the file into a
> > cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> > equation somehow. Sure this would take time, I realize that. The equation
> > would then be transmitted to the other computer where it would use its
> > mad-math-skillz to *figure out the answer* which would theoretically be the
> > same pattern of bits. Thus the same file would emerge on the other end.
> > 
> > The real question here is how long would it take for a regular computer to
> > do this kind of math?
> > 
> > The real question is whether this is possible. And the short answer is No,
> at least not in general.
Exactly: What you run up against is that you can reduce extraneous information, and compress redundant information, but if you actually have dense information, you're not gonna get any better.

So easy to compress a billion bytes of JSON or XML significantly; not so much a billion bytes of already tightly coded movie.

----
Aria Stewart




From nenolod at systeminplace.net  Wed May 18 15:40:11 2011
From: nenolod at systeminplace.net (William Pitcock)
Date: Wed, 18 May 2011 15:40:11 -0500
Subject: Had an idea - looking for a math buff to tell me if it's
	possible with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <20110518154011.2bc2e7a2@petrie>

On Wed, 18 May 2011 13:07:32 -0700
Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting
> of 8,000,000,000bits.  What if instead of transferring that file
> through the interwebs you transmitted a mathematical equation to tell
> a computer on the other end how to *construct* that file.  First
> you'd feed the file into a cruncher of some type to reduce the
> pattern of 8,000,000,000 bits into an equation somehow.  Sure this
> would take time, I realize that.  The equation would then be
> transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically
> be the same pattern of bits.  Thus the same file would emerge on the
> other end.
> 
> The real question here is how long would it take for a regular
> computer to do this kind of math?
> 
> Just a weird idea I had.  If it's a good idea then please consider
> this intellectual property.  LOL
> 
> 

I believe they call this 'compression'.

William



From randy at psg.com  Wed May 18 15:38:25 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 18 May 2011 22:38:25 +0200
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTiniFziKWikb_RtewaUdi16GkfG_Fg@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<m2ei3v934j.wl%randy@psg.com>
	<BANLkTiniFziKWikb_RtewaUdi16GkfG_Fg@mail.gmail.com>
Message-ID: <m2boyz922m.wl%randy@psg.com>

>> for some of us, the thing that is wonderful about netflix is the long
>> tail. ?my tastes are a sigma or three out.
> in all seriousness, if the content was available and you could request
> it be streamed to you 'sometime tomorrow' or 'sometime before Friday',
> you and the other people like you coudl get serviced on a singular
> 'stream'.

they do that now.  by a station wagon full of holerith cards.  well, how
about a dvd in the post?

randy



From jllee9753 at gmail.com  Wed May 18 15:39:44 2011
From: jllee9753 at gmail.com (John Lee)
Date: Wed, 18 May 2011 16:39:44 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <BANLkTin+T2Tif0wsuSSpMrrytaOq_aCoDA@mail.gmail.com>

The concept is called fractals where you can compress the image and send the
values and recreate the image. There was a body of work on the subject, I
would say in the mid to late eighties where two Georgia Tech professors
started a company doing it.

John (ISDN) Lee

On Wed, May 18, 2011 at 4:07 PM, Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
>
> The real question here is how long would it take for a regular computer to
> do this kind of math?
>
> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL
>
>
> --
> Landon Stewart <LStewart at SUPERB.NET>
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>


From gbonser at seven.com  Wed May 18 15:44:08 2011
From: gbonser at seven.com (George Bonser)
Date: Wed, 18 May 2011 13:44:08 -0700
Subject: Had an idea - looking for a math buff to tell me if it's
	possiblewith today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3343@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: Landon Stewart [mailto:lstewart at superb.net]
> Sent: Wednesday, May 18, 2011 1:08 PM
> To: nanog
> Subject: Had an idea - looking for a math buff to tell me if it's
> possiblewith today's technology.
> 
> Lets say you had a file that was 1,000,000,000 characters consisting
of
> 8,000,000,000bits.  What if instead of transferring that file through
> the
> interwebs you transmitted a mathematical equation to tell a computer
on
> the
> other end how to *construct* that file.

Congratulations.  You have just invented compression.


 



From jloiacon at csc.com  Wed May 18 15:47:14 2011
From: jloiacon at csc.com (Joe Loiacono)
Date: Wed, 18 May 2011 16:47:14 -0400
Subject: Had an idea - looking for a math buff to tell me if
	it's	possible	with today's technology.
In-Reply-To: <007b01cc1598$e32b9bc0$a982d340$@net>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<007b01cc1598$e32b9bc0$a982d340$@net>
Message-ID: <OF2E7BC9DA.6916EE04-ON85257894.0071D671-85257894.00723117@csc.com>

"Stefan Fouant" <sfouant at shortestpathfirst.net> wrote on 05/18/2011 
04:19:26 PM:

> > Lets say you had a file that was 1,000,000,000 characters consisting 
of
> 
> http://www.riverbed.com/us/
> 
http://www.juniper.net/us/en/products-services/application-acceleration/wxc-

> series/
> 
http://www.cisco.com/en/US/products/ps5680/Products_Sub_Category_Home.html

You also need to include Silver Peak.

http://www.silver-peak.com/

Saw a very interesting presentation on their techniques.

Joe


From bruns at 2mbit.com  Wed May 18 15:53:10 2011
From: bruns at 2mbit.com (Brielle Bruns)
Date: Wed, 18 May 2011 14:53:10 -0600
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=BLCYGmQ5zstN_008+d5H5hd8Kxw@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
	<BANLkTi=BLCYGmQ5zstN_008+d5H5hd8Kxw@mail.gmail.com>
Message-ID: <4DD431B6.3030402@2mbit.com>

On 5/18/11 2:33 PM, Dorn Hetzel wrote:
> If we're really talking efficiency, the "popular" stuff should probably
> stream out over the bird of your choice (directv, etc) because it's hard to
> beat millions of dishes and dvr's and no cable plant.
>
> Then what won't fit on the bird goes unicast IP from the nearest CDN.   Kind
> of like the "on demand over broadband" on my satellite box.  Their selection
> sucks, but the model is valid.



If someone hadn't mentioned already, there used to be a usenet provider 
that delivered a full feed via Satellite.  Anything is feasible, just 
have to find people who actually want/need it and a provider that isn't 
blind to long term benefits.


-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org



From jra at baylink.com  Wed May 18 15:51:05 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 18 May 2011 16:51:05 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
Message-ID: <31470797.396.1305751865067.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Joel Jaeggli" <joelja at bogus.com>

> On May 18, 2011, at 1:01 PM, Holmes,David A wrote:
> > I think this shows the need for an Internet-wide multicast
> > implementation.
> 
> there's a pretty longtailed distribution on what people might chose to
> stream. static content is ameniable to distribution via cdn (which is
> frankly a degenerate form of multicast), but lets face it, how many
> people watched "Charles Mingus: Triumph of the Underdog" in east palo
> alto last night at 10pm.

Of course.  But that's a strawman.  What percentage of available titles, by
*count*, accounts for even 50% of the streamed data, in bytes?  2%?  1?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From morrowc.lists at gmail.com  Wed May 18 15:56:00 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 16:56:00 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD42BC6.8030706@mompl.net>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<9C6F7172-55E2-4E4C-8596-EDC43D3F14D1@hopcount.ca>
	<4DD42BC6.8030706@mompl.net>
Message-ID: <BANLkTi=hTqXP3spLDp8vsZGSC5nStBAC+A@mail.gmail.com>

On Wed, May 18, 2011 at 4:27 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
> Joe Abley wrote:
>>
>> Or perhaps even some kind of new technology that is independent of the
>> Internet! Imagine such futuristic ideas as solar-powered spacecraft in orbit
>> around the planet bouncing content back across massive areas so that
>> everybody can pick them up at once.
>>
>> Crazy stuff.
>
> You mean like a sputnik?

sputnik was VERY low bandwidth though... if you wanted to stream a
current movie, you'd likely have to have started when sputnik actually
launched to be sure you'd be able to watch it next year.



From bicknell at ufp.org  Wed May 18 16:03:18 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 18 May 2011 14:03:18 -0700
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<4DD4299D.8050402@csuohio.edu>
	<BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
Message-ID: <20110518210318.GA61570@ussenterprise.ufp.org>

In a message written on Wed, May 18, 2011 at 04:33:34PM -0400, Christopher Morrow wrote:
> no no no.. it's simply, since the OP posited a math solution, md5.
> ship the size of file + hash, compute file on the other side. All
> files can be moved anywhere regardless of the size of the file in a
> single packet.
> 
> 
> The solution is left as an exercise for the reader.

Bah, you should include the solution, it's so trivial.

Generate all possible files and then do an index lookup on the MD5.
It's a little CPU heavy, but darn simple to code.

You can even stop when you get a match, which turns out to be a HUGE
optimization. :)

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110518/3458f547/attachment.bin>

From lyndon at orthanc.ca  Wed May 18 16:03:53 2011
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX))
Date: Wed, 18 May 2011 14:03:53 -0700
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
Message-ID: <a3227941c4cb1acd09487ff3e206fec8@gandalf.orthanc.ca>

> no no no.. it's simply, since the OP posited a math solution, md5.
> ship the size of file + hash, compute file on the other side. All
> files can be moved anywhere regardless of the size of the file in a
> single packet.

MD5 compression is lossy in this context.  Given big enough files
you're going to start seeing hash collisions.




From smb at cs.columbia.edu  Wed May 18 16:10:39 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Wed, 18 May 2011 17:10:39 -0400
Subject: user-relative names - was:[Re: Yahoo and IPv6]
In-Reply-To: <BFD23017-7D4B-4BB1-9EDD-043CE84555AE@bogus.com>
References: <20110517180915.B96C4229@resin16.mta.everyone.net>
	<BFD23017-7D4B-4BB1-9EDD-043CE84555AE@bogus.com>
Message-ID: <3F1157BB-2A71-46DA-88F6-B47122BE8ED3@cs.columbia.edu>


On May 17, 2011, at 10:30 13PM, Joel Jaeggli wrote:

> 
> On May 17, 2011, at 6:09 PM, Scott Weeks wrote:
> 
>> --- joelja at bogus.com wrote:
>> From: Joel Jaeggli <joelja at bogus.com>
>> On May 17, 2011, at 4:30 PM, Scott Brim wrote:
>>> On May 17, 2011 6:26 PM, <Valdis.Kletnieks at vt.edu> wrote:
>>>> On Tue, 17 May 2011 15:04:19 PDT, Scott Weeks said:
>>>> 
>>>>> What about privacy concerns
>>>> 
>>>> "Privacy is dead.  Get used to it." -- Scott McNeely
>>> 
>>> Forget that attitude, Valdis. Just because privacy is blown at one level
>>> doesn't mean you give it away at every other one. We establish the framework
>>> for recovering privacy and make progress step by step, wherever we can.
>>> Someday we'll get it all back under control.
>> 
>> if you put something in the dns you do so because you want to discovered. scoping the nameservers such that they only express certain certain resource records to queriers in a particular scope is fairly straight forward.
>> --------------------------------------------------------
>> 
>> 
>> The article was not about DNS.  It was about "Persistent Personal Names for Globally Connected Mobile Devices" where "Users normally create personal names by introducing devices locally, on a common WiFi network for example. Once created, these names remain persistently bound to their targets as devices move. Personal names are intended to supplement and not replace global DNS names."  
> 
> you mean like mac addresses? those have a tendency to follow you around in ipv6...
> 
This is why RFC 3041 (replaced by 4941) was written, 10+ years ago.  The problem
is that it's not enabled by default on many (possibly all) platforms, so I
have to have

# cat /etc/sysctl.conf
net.inet6.ip6.use_tempaddr=1

set on my Mac.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From tagno25 at gmail.com  Wed May 18 16:19:15 2011
From: tagno25 at gmail.com (Philip Dorr)
Date: Wed, 18 May 2011 16:19:15 -0500
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<4DD4299D.8050402@csuohio.edu>
	<BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
Message-ID: <BANLkTikXnjXBAzGh-QOHQgswKA3kjw2Z5w@mail.gmail.com>

On Wed, May 18, 2011 at 3:33 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Wed, May 18, 2011 at 4:18 PM, Michael Holstein
> <michael.holstein at csuohio.edu> wrote:
>>
>>> Just a weird idea I had. ?If it's a good idea then please consider this
>>> intellectual property.
>>>
>>
>> It's easy .. the zeros are fatter than the ones.
>
> no no no.. it's simply, since the OP posited a math solution, md5.
> ship the size of file + hash, compute file on the other side. All
> files can be moved anywhere regardless of the size of the file in a
> single packet.
>
>
> The solution is left as an exercise for the reader.
>

You would need a lot of computing power to generate a file of any
decent size.  If you want to be evil then you could send just a md5
hash and a sha512 hash (or some other hash that would not have a
collision at the same time except when correct)



From owenc at hubris.net  Wed May 18 16:22:42 2011
From: owenc at hubris.net (Chris Owen)
Date: Wed, 18 May 2011 16:22:42 -0500
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <20110518210318.GA61570@ussenterprise.ufp.org>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<4DD4299D.8050402@csuohio.edu>
	<BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
	<20110518210318.GA61570@ussenterprise.ufp.org>
Message-ID: <B68D2B2D-951D-45D7-BB38-4BFA20866A18@hubris.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 18, 2011, at 4:03 PM, Leo Bicknell wrote:

> Bah, you should include the solution, it's so trivial.
> 
> Generate all possible files and then do an index lookup on the MD5.
> It's a little CPU heavy, but darn simple to code.

Isn't this essentially what Dropbox has been doing in many cases?

Chris

- --
- -------------------------------------------------------------------------
Chris Owen         - Garden City (620) 275-1900 -  Lottery (noun):
President          - Wichita     (316) 858-3000 -    A stupidity tax
Hubris Communications Inc      www.hubris.net
- -------------------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt
Comment: Public Key ID: 0xB513D9DD

iEYEARECAAYFAk3UOKIACgkQElUlCLUT2d3YoQCfee38nKuXD5O4C2w5VXUWszF1
EjcAmwfyytDgwmQDpJsQZSpl03ddGbVv
=3sX9
-----END PGP SIGNATURE-----



From morrowc.lists at gmail.com  Wed May 18 16:27:37 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 17:27:37 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD431B6.3030402@2mbit.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
	<BANLkTi=BLCYGmQ5zstN_008+d5H5hd8Kxw@mail.gmail.com>
	<4DD431B6.3030402@2mbit.com>
Message-ID: <BANLkTikwJ7_L4Epzoxk=Cm1d9Ln2qXoivg@mail.gmail.com>

On Wed, May 18, 2011 at 4:53 PM, Brielle Bruns <bruns at 2mbit.com> wrote:
> On 5/18/11 2:33 PM, Dorn Hetzel wrote:
>>
>> If we're really talking efficiency, the "popular" stuff should probably
>> stream out over the bird of your choice (directv, etc) because it's hard
>> to
>> beat millions of dishes and dvr's and no cable plant.
>>
>> Then what won't fit on the bird goes unicast IP from the nearest CDN.
>> Kind
>> of like the "on demand over broadband" on my satellite box. ?Their
>> selection
>> sucks, but the model is valid.
>
>
>
> If someone hadn't mentioned already, there used to be a usenet provider that
> delivered a full feed via Satellite. ?Anything is feasible, just have to

doug went out of that business, it wasn't (apparently) actually viable.



From morrowc.lists at gmail.com  Wed May 18 16:29:16 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 17:29:16 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <OF2E7BC9DA.6916EE04-ON85257894.0071D671-85257894.00723117@csc.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<007b01cc1598$e32b9bc0$a982d340$@net>
	<OF2E7BC9DA.6916EE04-ON85257894.0071D671-85257894.00723117@csc.com>
Message-ID: <BANLkTimQAJiQjubP7gmOM-_V5HnWtpu+aQ@mail.gmail.com>

On Wed, May 18, 2011 at 4:47 PM, Joe Loiacono <jloiacon at csc.com> wrote:

> You also need to include Silver Peak.
>

only if you like random failures.



From dorn at hetzel.org  Wed May 18 16:31:50 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 18 May 2011 17:31:50 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <a3227941c4cb1acd09487ff3e206fec8@gandalf.orthanc.ca>
References: <BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
	<a3227941c4cb1acd09487ff3e206fec8@gandalf.orthanc.ca>
Message-ID: <BANLkTimOiuGk3ePW3j2NOq+TF6rJtWc9Ag@mail.gmail.com>

>
>
> MD5 compression is lossy in this context.  Given big enough files
> you're going to start seeing hash collisions.
>
>
> Actually, for a n-bit hash, I can guarantee to find collisions in the
universe of files just n+1 bits in size :)


From lstewart at superb.net  Wed May 18 16:34:32 2011
From: lstewart at superb.net (Landon Stewart)
Date: Wed, 18 May 2011 14:34:32 -0700
Subject: Had an idea - looking for a math buff to tell me if it's
	possiblewith today's technology.
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3343@RWC-EX1.corp.seven.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3343@RWC-EX1.corp.seven.com>
Message-ID: <BANLkTikq+gyQ1_ZWG2quS8eo77ZKEgUmkA@mail.gmail.com>

On Wed, May 18, 2011 at 1:44 PM, George Bonser <gbonser at seven.com> wrote:

>
> Congratulations.  You have just invented compression.
>

Woot.

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From young at jsyoung.net  Wed May 18 16:45:44 2011
From: young at jsyoung.net (Jeffrey S. Young)
Date: Thu, 19 May 2011 07:45:44 +1000
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
Message-ID: <6021663B-C394-481E-87D3-A0D69056E7B7@jsyoung.net>



On 19/05/2011, at 6:01 AM, "Holmes,David A" <dholmes at mwdh2o.com> wrote:

> I think this shows the need for an Internet-wide multicast implementation. Although I can recall working on a product that delivered satellite multicast streams (with each multicast group corresponding to individual TV stations) to telco CO's. This enabled the telco to implement multicast at the edge of their networks, where user broadband clients would issue multicast joins only as far as the CO. If I recall this was implemented with the old Cincinnati Bell telco. I admit there are a lot of CO's and cable head-ends though for this solution to scale.
> 
> -----Original Message-----
> From: Michael Holstein [mailto:michael.holstein at csuohio.edu]
> Sent: Wednesday, May 18, 2011 12:46 PM
> To: Roy
> Cc: nanog
> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
> 
> 
>> http://e.businessinsider.com/public/184962
>> 
> 
> Somebody should invent a a way to stream groups of shows simultaneously
> and just arrange for people to watch the desired stream at a particular
> time. Heck, maybe even do it wireless.
> 
> problem solved, right?
> 
> Cheers,
> 
> Michael Holstein
> Cleveland State University
> 
> 
No matter where you go, there you are.
[--anon?]

or

Those who don't understand history are doomed to repeat it. - 
[heavily paraphrased -- Santayana]

jy
> 



From jlewis at lewis.org  Wed May 18 17:01:05 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 18 May 2011 18:01:05 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD431B6.3030402@2mbit.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>
	<BANLkTi=BLCYGmQ5zstN_008+d5H5hd8Kxw@mail.gmail.com>
	<4DD431B6.3030402@2mbit.com>
Message-ID: <Pine.LNX.4.61.1105181756520.4318@soloth.lewis.org>

On Wed, 18 May 2011, Brielle Bruns wrote:

> If someone hadn't mentioned already, there used to be a usenet provider that 
> delivered a full feed via Satellite.  Anything is feasible, just have to find 
> people who actually want/need it and a provider that isn't blind to long term 
> benefits.

Skycache/Cidera...until it didn't fit anymore in the bandwidth they had. 
IIRC, it was only around 28mbps.

Also, IIRC, that "business" was a sort of after thought after their 
original plan (squid cache pre-population) didn't pan out.

Anyone want to buy some Skycache chopsticks?  I think I still have a few 
unopened sets from whichever late 90s ISPCon I went to in San Jose, 
CA...Skycache rented out some museum for a sushi party.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From paul at paulstewart.org  Wed May 18 17:49:40 2011
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 18 May 2011 18:49:40 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	Any	Other Company
In-Reply-To: <Pine.LNX.4.61.1105181756520.4318@soloth.lewis.org>
References: <4DD2F087.5050003@gmail.com>
	<4DD42206.20407@csuohio.edu>	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>	<623E52CE-9FA9-4DF4-9AE6-4B79267624A1@bogus.com>	<BANLkTi=BLCYGmQ5zstN_008+d5H5hd8Kxw@mail.gmail.com>	<4DD431B6.3030402@2mbit.com>
	<Pine.LNX.4.61.1105181756520.4318@soloth.lewis.org>
Message-ID: <03be01cc15ad$e611e640$b235b2c0$@org>

There was also "Planet Connect" years ago that delivered full Usenet (128K
worth) along with all my Fidonet BBS updates too .. I think I just dated
myself ;)

We still have an old Cidera system on a rooftop that nobody has taken down
yet ...

Paul


-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: May-18-11 6:01 PM
To: Brielle Bruns
Cc: nanog at nanog.org
Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any
Other Company

On Wed, 18 May 2011, Brielle Bruns wrote:

> If someone hadn't mentioned already, there used to be a usenet provider
that 
> delivered a full feed via Satellite.  Anything is feasible, just have to
find 
> people who actually want/need it and a provider that isn't blind to long
term 
> benefits.

Skycache/Cidera...until it didn't fit anymore in the bandwidth they had. 
IIRC, it was only around 28mbps.

Also, IIRC, that "business" was a sort of after thought after their 
original plan (squid cache pre-population) didn't pan out.

Anyone want to buy some Skycache chopsticks?  I think I still have a few 
unopened sets from whichever late 90s ISPCon I went to in San Jose, 
CA...Skycache rented out some museum for a sushi party.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________




From jra at baylink.com  Wed May 18 17:50:36 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 18 May 2011 18:50:36 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other	Company
In-Reply-To: <6021663B-C394-481E-87D3-A0D69056E7B7@jsyoung.net>
Message-ID: <7453348.400.1305759036180.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeffrey S. Young" <young at jsyoung.net>

> > Somebody should invent a a way to stream groups of shows simultaneously
> > and just arrange for people to watch the desired stream at a particular
> > time. Heck, maybe even do it wireless.
> >
> > problem solved, right?
> 
> Those who don't understand history are doomed to repeat it. -
> [heavily paraphrased -- Santayana]

"Those who do not understand broadcasting are doomed to reinvent it.  
Poorly."  --after Henry Spencer.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From hj1980 at gmail.com  Wed May 18 18:26:26 2011
From: hj1980 at gmail.com (Heath Jones)
Date: Thu, 19 May 2011 00:26:26 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>

I wonder if this is possible:

- Take a hash of the original file. Keep a counter.
- Generate data in some sequential method on sender side (for example simply
starting at 0 and iterating until you generate the same as the original
data)
- Each time you iterate, take the hash of the generated data. If it matches
the hash of the original file, increment counter.
- Send the hash and the counter value to recipient.
- Recipient performs same sequential generation method, stopping when
counter reached.

Any thoughts?

Heath


On 18 May 2011 21:07, Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
>
> The real question here is how long would it take for a regular computer to
> do this kind of math?
>
> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL
>
>
> --
> Landon Stewart <LStewart at SUPERB.NET>
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>


From jcdill.lists at gmail.com  Wed May 18 18:35:47 2011
From: jcdill.lists at gmail.com (JC Dill)
Date: Wed, 18 May 2011 16:35:47 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com>
	<4DD42206.20407@csuohio.edu>	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>
Message-ID: <4DD457D3.501@gmail.com>

  On 18/05/11 1:13 PM, Cameron Byrne wrote:
>
> It's not.  These people need a pair of rabbit ears and a DVR.

Roughly 90% of the content I'm interested in watching is not available 
over the air.  E.g. Comedy Central, CNN, Discovery, Showtime/HBO, etc.

jc




From dorn at hetzel.org  Wed May 18 18:42:15 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 18 May 2011 19:42:15 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD457D3.501@gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>
	<4DD457D3.501@gmail.com>
Message-ID: <BANLkTi=rBhD_kTnOpt54=OMQM18-5m0-qw@mail.gmail.com>

On Wed, May 18, 2011 at 7:35 PM, JC Dill <jcdill.lists at gmail.com> wrote:

>  On 18/05/11 1:13 PM, Cameron Byrne wrote:
>
>>
>> It's not.  These people need a pair of rabbit ears and a DVR.
>>
>
> Roughly 90% of the content I'm interested in watching is not available over
> the air.  E.g. Comedy Central, CNN, Discovery, Showtime/HBO, etc.
>
> jc
>
>
> Sure, but I'm guessing that something like that 80% of the content that 80%
of people watch *is* available on some satellite/cable channel.

IP is perfect for the long tail, and yes, some of are mostly consumers of
the tail :), but still, there is a win to be had on the front end of the
beast...


From Valdis.Kletnieks at vt.edu  Wed May 18 18:42:43 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 18 May 2011 19:42:43 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: Your message of "Thu, 19 May 2011 00:26:26 BST."
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
Message-ID: <16314.1305762163@localhost>

On Thu, 19 May 2011 00:26:26 BST, Heath Jones said:
> I wonder if this is possible:
> 
> - Take a hash of the original file. Keep a counter.
> - Generate data in some sequential method on sender side (for example simply
> starting at 0 and iterating until you generate the same as the original
> data)
> - Each time you iterate, take the hash of the generated data. If it matches
> the hash of the original file, increment counter.
> - Send the hash and the counter value to recipient.
> - Recipient performs same sequential generation method, stopping when
> counter reached.

MD5 is a 128 bit hash.

2^128 is 340,282,366,920,938,463,463,374,607,431,768,211,456 - you're welcome
to iterate that many times to find a duplicate. You may get lucky and get a hit
in the first trillion or so attempts - but you may get unlucky and not get a
hit until the *last* few trillion attempts. On average you'll have to iterate
about half that huge number before you get a hit.

And it's lossy - if you hash all the possible 4K blocks with MD5, you'll find
that each of those 2^128 hashes has been hit about 256 times - and no
indication in the hash of *which* of the 256 colliding 4K blocks you have on
this iteration.  (The only reason that companies can do block-level
de-duplication by saving a hash as an index to one copy shared by all blocks
with the same hash value is because you have a *very small* fraction of the
possibilities covered, so if you saved a 4K block of data from somebody's
system32 folder under a given MD5 hash, it's *far* more likely that another
block with that same hash is from another copy of another identical system32
folder, than it is an actual accidental collision.)

Protip:  A good hash function is by definition one-way - given the data, it's
easy to generate the hash - but reversing it to find the "pre-image" (the data
that *generated* the hash) is massively difficult.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110518/92e3234b/attachment.bin>

From jcdill.lists at gmail.com  Wed May 18 18:47:31 2011
From: jcdill.lists at gmail.com (JC Dill)
Date: Wed, 18 May 2011 16:47:31 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=rBhD_kTnOpt54=OMQM18-5m0-qw@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com>	<4DD42206.20407@csuohio.edu>	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>	<BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>	<4DD457D3.501@gmail.com>
	<BANLkTi=rBhD_kTnOpt54=OMQM18-5m0-qw@mail.gmail.com>
Message-ID: <4DD45A93.30100@gmail.com>

  On 18/05/11 4:42 PM, Dorn Hetzel wrote:
>
>
> On Wed, May 18, 2011 at 7:35 PM, JC Dill <jcdill.lists at gmail.com 
> <mailto:jcdill.lists at gmail.com>> wrote:
>
>      On 18/05/11 1:13 PM, Cameron Byrne wrote:
>
>
>         It's not.  These people need a pair of rabbit ears and a DVR.
>
>
>     Roughly 90% of the content I'm interested in watching is not
>     available over the air.  E.g. Comedy Central, CNN, Discovery,
>     Showtime/HBO, etc.
>
>     jc
>
>
> Sure, but I'm guessing that something like that 80% of the content 
> that 80% of people watch *is* available on some satellite/cable channel.

Yes, but most isn't available "over the air" with rabbit ears and a 
DVR.  One of the big appeals of Netflix is the $8/month for all you can 
eat versus ~$40-60 for various cable and satellite packages.

jc




From hj1980 at gmail.com  Wed May 18 19:01:43 2011
From: hj1980 at gmail.com (Heath Jones)
Date: Thu, 19 May 2011 01:01:43 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <16314.1305762163@localhost>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
Message-ID: <BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>

My point here is it IS possible to transfer just a hash and counter value
and effectively generate identical data at the remote end.
The limit that will be hit is the difficulty of generating and comparing
hash values with current processing power.

I'm proposing iterating through generated data up until the actual data.
It's not even a storage issue, as once you have incremented the data you
don't need to store old data or hash values - just the counter. No massive
hash tables.

It's a CPU issue.

Heath

On 19 May 2011 00:42, <Valdis.Kletnieks at vt.edu> wrote:

> On Thu, 19 May 2011 00:26:26 BST, Heath Jones said:
> > I wonder if this is possible:
> >
> > - Take a hash of the original file. Keep a counter.
> > - Generate data in some sequential method on sender side (for example
> simply
> > starting at 0 and iterating until you generate the same as the original
> > data)
> > - Each time you iterate, take the hash of the generated data. If it
> matches
> > the hash of the original file, increment counter.
> > - Send the hash and the counter value to recipient.
> > - Recipient performs same sequential generation method, stopping when
> > counter reached.
>
> MD5 is a 128 bit hash.
>
> 2^128 is 340,282,366,920,938,463,463,374,607,431,768,211,456 - you're
> welcome
> to iterate that many times to find a duplicate. You may get lucky and get a
> hit
> in the first trillion or so attempts - but you may get unlucky and not get
> a
> hit until the *last* few trillion attempts. On average you'll have to
> iterate
> about half that huge number before you get a hit.
>
> And it's lossy - if you hash all the possible 4K blocks with MD5, you'll
> find
> that each of those 2^128 hashes has been hit about 256 times - and no
> indication in the hash of *which* of the 256 colliding 4K blocks you have
> on
> this iteration.  (The only reason that companies can do block-level
> de-duplication by saving a hash as an index to one copy shared by all
> blocks
> with the same hash value is because you have a *very small* fraction of the
> possibilities covered, so if you saved a 4K block of data from somebody's
> system32 folder under a given MD5 hash, it's *far* more likely that another
> block with that same hash is from another copy of another identical
> system32
> folder, than it is an actual accidental collision.)
>
> Protip:  A good hash function is by definition one-way - given the data,
> it's
> easy to generate the hash - but reversing it to find the "pre-image" (the
> data
> that *generated* the hash) is massively difficult.
>
>


From hj1980 at gmail.com  Wed May 18 19:03:46 2011
From: hj1980 at gmail.com (Heath Jones)
Date: Thu, 19 May 2011 01:03:46 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <16314.1305762163@localhost>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
Message-ID: <BANLkTin1oJVUMP5CCYNSKn-gfeVZ+Cte5A@mail.gmail.com>

My point here is it IS possible to transfer just a hash and counter value
and effectively generate identical data at the remote end.
The limit that will be hit is the difficulty of generating and comparing
hash values with current processing power.

I'm proposing iterating through generated data up until the actual data.
It's not even a storage issue, as once you have incremented the data you
don't need to store old data or hash values - just the counter. No massive
hash tables.

It's a CPU issue.

On 19 May 2011 00:42, <Valdis.Kletnieks at vt.edu> wrote:

> On Thu, 19 May 2011 00:26:26 BST, Heath Jones said:
> > I wonder if this is possible:
> >
> > - Take a hash of the original file. Keep a counter.
> > - Generate data in some sequential method on sender side (for example
> simply
> > starting at 0 and iterating until you generate the same as the original
> > data)
> > - Each time you iterate, take the hash of the generated data. If it
> matches
> > the hash of the original file, increment counter.
> > - Send the hash and the counter value to recipient.
> > - Recipient performs same sequential generation method, stopping when
> > counter reached.
>
> MD5 is a 128 bit hash.
>
> 2^128 is 340,282,366,920,938,463,463,374,607,431,768,211,456 - you're
> welcome
> to iterate that many times to find a duplicate. You may get lucky and get a
> hit
> in the first trillion or so attempts - but you may get unlucky and not get
> a
> hit until the *last* few trillion attempts. On average you'll have to
> iterate
> about half that huge number before you get a hit.
>
> And it's lossy - if you hash all the possible 4K blocks with MD5, you'll
> find
> that each of those 2^128 hashes has been hit about 256 times - and no
> indication in the hash of *which* of the 256 colliding 4K blocks you have
> on
> this iteration.  (The only reason that companies can do block-level
> de-duplication by saving a hash as an index to one copy shared by all
> blocks
> with the same hash value is because you have a *very small* fraction of the
> possibilities covered, so if you saved a 4K block of data from somebody's
> system32 folder under a given MD5 hash, it's *far* more likely that another
> block with that same hash is from another copy of another identical
> system32
> folder, than it is an actual accidental collision.)
>
> Protip:  A good hash function is by definition one-way - given the data,
> it's
> easy to generate the hash - but reversing it to find the "pre-image" (the
> data
> that *generated* the hash) is massively difficult.
>
>


From aredridel at nbtsc.org  Wed May 18 19:04:25 2011
From: aredridel at nbtsc.org (Aria Stewart)
Date: Wed, 18 May 2011 18:04:25 -0600
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
	<BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
Message-ID: <5C4FD7C1E83A454CA414C908FBA871C3@nbtsc.org>


On Wednesday, May 18, 2011 at 6:01 PM, Heath Jones wrote: 
> My point here is it IS possible to transfer just a hash and counter value
> and effectively generate identical data at the remote end.
> The limit that will be hit is the difficulty of generating and comparing
> hash values with current processing power.
> 
> I'm proposing iterating through generated data up until the actual data.
> It's not even a storage issue, as once you have incremented the data you
> don't need to store old data or hash values - just the counter. No massive
> hash tables.
> 
> It's a CPU issue.

Google "Birthday paradox" and "hash collision"

----
Aria Stewart




From jhcook at gmail.com  Wed May 18 19:10:04 2011
From: jhcook at gmail.com (Justin Cook)
Date: Thu, 19 May 2011 01:10:04 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
	<BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
Message-ID: <BANLkTimogd=dC1-4zvQswTA9jevo7v8BvQ@mail.gmail.com>

Why is this on nanog?

Yes it is "possible". But the CPU use and time will be absurd compared to
just sending the data across the network.

I would say attempting this with even a small file will end up laughable.
Passwords are just several bytes and have significant lifetimes.

-- 
Justin Cook
On 19 May 2011 01:03, "Heath Jones" <hj1980 at gmail.com> wrote:
> My point here is it IS possible to transfer just a hash and counter value
> and effectively generate identical data at the remote end.
> The limit that will be hit is the difficulty of generating and comparing
> hash values with current processing power.
>
> I'm proposing iterating through generated data up until the actual data.
> It's not even a storage issue, as once you have incremented the data you
> don't need to store old data or hash values - just the counter. No massive
> hash tables.
>
> It's a CPU issue.
>
> Heath
>
> On 19 May 2011 00:42, <Valdis.Kletnieks at vt.edu> wrote:
>
>> On Thu, 19 May 2011 00:26:26 BST, Heath Jones said:
>> > I wonder if this is possible:
>> >
>> > - Take a hash of the original file. Keep a counter.
>> > - Generate data in some sequential method on sender side (for example
>> simply
>> > starting at 0 and iterating until you generate the same as the original
>> > data)
>> > - Each time you iterate, take the hash of the generated data. If it
>> matches
>> > the hash of the original file, increment counter.
>> > - Send the hash and the counter value to recipient.
>> > - Recipient performs same sequential generation method, stopping when
>> > counter reached.
>>
>> MD5 is a 128 bit hash.
>>
>> 2^128 is 340,282,366,920,938,463,463,374,607,431,768,211,456 - you're
>> welcome
>> to iterate that many times to find a duplicate. You may get lucky and get
a
>> hit
>> in the first trillion or so attempts - but you may get unlucky and not
get
>> a
>> hit until the *last* few trillion attempts. On average you'll have to
>> iterate
>> about half that huge number before you get a hit.
>>
>> And it's lossy - if you hash all the possible 4K blocks with MD5, you'll
>> find
>> that each of those 2^128 hashes has been hit about 256 times - and no
>> indication in the hash of *which* of the 256 colliding 4K blocks you have
>> on
>> this iteration. (The only reason that companies can do block-level
>> de-duplication by saving a hash as an index to one copy shared by all
>> blocks
>> with the same hash value is because you have a *very small* fraction of
the
>> possibilities covered, so if you saved a 4K block of data from somebody's
>> system32 folder under a given MD5 hash, it's *far* more likely that
another
>> block with that same hash is from another copy of another identical
>> system32
>> folder, than it is an actual accidental collision.)
>>
>> Protip: A good hash function is by definition one-way - given the data,
>> it's
>> easy to generate the hash - but reversing it to find the "pre-image" (the
>> data
>> that *generated* the hash) is massively difficult.
>>
>>


From dorn at hetzel.org  Wed May 18 19:10:17 2011
From: dorn at hetzel.org (Dorn Hetzel)
Date: Wed, 18 May 2011 20:10:17 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD45A93.30100@gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>
	<4DD457D3.501@gmail.com>
	<BANLkTi=rBhD_kTnOpt54=OMQM18-5m0-qw@mail.gmail.com>
	<4DD45A93.30100@gmail.com>
Message-ID: <BANLkTim4kJdPGUCG++jC08rmS-2VjN9P8g@mail.gmail.com>

>
>
>> Sure, but I'm guessing that something like that 80% of the content that
>> 80% of people watch *is* available on some satellite/cable channel.
>>
>
> Yes, but most isn't available "over the air" with rabbit ears and a DVR.
>  One of the big appeals of Netflix is the $8/month for all you can eat
> versus ~$40-60 for various cable and satellite packages.
>
> jc
>
>
> But it's not really $8/month, it's 8$ plus broadband.


From owen at delong.com  Wed May 18 19:18:57 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 18 May 2011 17:18:57 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD29A66.5050106@matthew.at>
References: <87180.1305391666@nsa.vix.com>	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>	<4DCEC904.1040006@freedesktop.org>
	<8966.1305416364@nsa.vix.com>	<4DD16EFA.2020207@freedesktop.org>	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>	<80660.1305606174@nsa.vix.com>	<20110517090717.GO17325@besserwisser.org>
	<44145AAB-06CD-4344-9887-CC12C65436C6@delong.com>
	<4DD29A66.5050106@matthew.at>
Message-ID: <B4121EA7-4645-4E07-AD6C-D18E49C58CCF@delong.com>


On May 17, 2011, at 8:55 AM, Matthew Kaufman wrote:

> On 5/17/2011 5:25 AM, Owen DeLong wrote:
>> 
>> My point was that at least in IPv6, you can reach your boxes whereas with
>> IPv4, you couldn't reach them at all (unless you used a rendezvous service
>> and preconfigured stuff).
> 
> Actually almost everyone will *still* need a rendezvous service as even if there isn't NAT66 (which I strongly suspect there will be, as nobody has magically solved the rest of the renumbering problems) there will still be default firewall filters that the average end-user won't know how or why to change (and in some cases won't even have access to the CPE).

PI solves the majority of the renumbering problems quite nicely and is readily available for
most orgs. now.

Beyond that, I think you will see firewalls become much easier for the average person to
manage and it will become a simple matter of making an http (hopefully https) connection
to the home gateway and telling it which service (by name, such as VNC, HTTP, HTTPs, etc.
from a pull-down) and which host (ideally by name, but, may have other requirements here)
to permit.

Some firewalls already come pretty close to that.

There is also talk (for better or worse) of having something like UPNP, but, without the NAT
for enabling such services.

No rendezvous server required.

> 
> For the former we can only hope that NAT66 box builders can get guidance from IETF rather than having IETF stick its collective head in the sand... for the latter the firewall traversal has a chance of being more reliable than having to traversal both filtering and address translation.
> 

I'm still hoping that we just don't have NAT66 box builders. So far, it's working out that way.

Owen





From chrisjfenton at btinternet.com  Wed May 18 19:35:59 2011
From: chrisjfenton at btinternet.com (Chrisjfenton)
Date: Wed, 18 May 2011 19:35:59 -0500
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <2706EAC6-73B7-4414-A2BA-D261FBE751DA@btinternet.com>

try itu v.42bis 


Iridescent iPhone 
+1 972 757 8894



On May 18, 2011, at 15:07, Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting of
> 8,000,000,000bits.  What if instead of transferring that file through the
> interwebs you transmitted a mathematical equation to tell a computer on the
> other end how to *construct* that file.  First you'd feed the file into a
> cruncher of some type to reduce the pattern of 8,000,000,000 bits into an
> equation somehow.  Sure this would take time, I realize that.  The equation
> would then be transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically be the
> same pattern of bits.  Thus the same file would emerge on the other end.
> 
> The real question here is how long would it take for a regular computer to
> do this kind of math?
> 
> Just a weird idea I had.  If it's a good idea then please consider this
> intellectual property.  LOL
> 
> 
> -- 
> Landon Stewart <LStewart at SUPERB.NET>
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net



From jcdill.lists at gmail.com  Wed May 18 19:36:05 2011
From: jcdill.lists at gmail.com (JC Dill)
Date: Wed, 18 May 2011 17:36:05 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTim4kJdPGUCG++jC08rmS-2VjN9P8g@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com>	<4DD42206.20407@csuohio.edu>	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>	<BANLkTimwqaScckHidKKxv-N32GLoHbFMeA@mail.gmail.com>	<4DD457D3.501@gmail.com>	<BANLkTi=rBhD_kTnOpt54=OMQM18-5m0-qw@mail.gmail.com>	<4DD45A93.30100@gmail.com>
	<BANLkTim4kJdPGUCG++jC08rmS-2VjN9P8g@mail.gmail.com>
Message-ID: <4DD465F5.8090005@gmail.com>

  On 18/05/11 5:10 PM, Dorn Hetzel wrote:
>
>
>         Sure, but I'm guessing that something like that 80% of the
>         content that 80% of people watch *is* available on some
>         satellite/cable channel.
>
>
>     Yes, but most isn't available "over the air" with rabbit ears and
>     a DVR.  One of the big appeals of Netflix is the $8/month for all
>     you can eat versus ~$40-60 for various cable and satellite packages.
>
>     jc
>
>
> But it's not really $8/month, it's 8$ plus broadband. 

But I have broadband already.  To get Satellite or Cable it's another 
$40-60/month, to get Netflix it's another $8/month.

jc





From morrowc.lists at gmail.com  Wed May 18 19:41:16 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 18 May 2011 20:41:16 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTin1oJVUMP5CCYNSKn-gfeVZ+Cte5A@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
	<BANLkTin1oJVUMP5CCYNSKn-gfeVZ+Cte5A@mail.gmail.com>
Message-ID: <BANLkTikBbbodFSZ5-Ez92ErJcV9sNXdgqw@mail.gmail.com>

On Wed, May 18, 2011 at 8:03 PM, Heath Jones <hj1980 at gmail.com> wrote:
> My point here is it IS possible to transfer just a hash and counter value
> and effectively generate identical data at the remote end.
> The limit that will be hit is the difficulty of generating and comparing
> hash values with current processing power.
>
> I'm proposing iterating through generated data up until the actual data.
> It's not even a storage issue, as once you have incremented the data you
> don't need to store old data or hash values - just the counter. No massive
> hash tables.
>
> It's a CPU issue.
>

i'd note it took you many more packets than my example of roughly the
same thing.

if you really want to save bandwidth, my 1 packet answer is the best answer.



From bzs at world.std.com  Wed May 18 19:54:34 2011
From: bzs at world.std.com (Barry Shein)
Date: Wed, 18 May 2011 20:54:34 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>
Message-ID: <19924.27210.53557.472985@world.std.com>


"Compression" is one result.

But this is sometimes referred to as the "inverse problem": Given a
set of data tell me a function which fits it (or fits it to some
tolerance.) It's important in statistics and all kinds of data
analyses.

Another area is fourier transforms which basically sums sine waves of
different amp/freq until you reach the desired fit. This is also the
basis of a lot of noise filtering algorithms, throw out the
frequencies you don't want, such as 60HZ or 50HZ, or all those smaller
than you consider interesting, high-freq "noise", or low freq noise,
whatever.

Another buzz term is "data entropy", randomness. If the data were
perfectly random then there exists no such function which can be
represented in less bits than the original data, which is why you
can't compress a compressed file indefinitely and also why it's
recommended you compress files before encrypting them, it's hard to
begin cracking a file which is pretty close to random.

And this is what you do when you give something like a MARC or ISBN or
Dewey Decimal index to a librarian and s/he brings you the book you
want. Effectively you've represented the entire book as that small
"number". Imagine if you had to recite the entire text of a book to
find it unambiguously! See: Transfinite Number Systems.

-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*



From Valdis.Kletnieks at vt.edu  Wed May 18 21:21:24 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 18 May 2011 22:21:24 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: Your message of "Thu, 19 May 2011 01:01:43 BST."
	<BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
	<BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
Message-ID: <5673.1305771684@localhost>

On Thu, 19 May 2011 01:01:43 BST, Heath Jones said:

> My point here is it IS possible to transfer just a hash and counter value
> and effectively generate identical data at the remote end.

Nope. Let's use phone numbers as an example.  I want to send you the phone
number 540-231-6000.  The hash function is "number mod 17 plus 5". So
5402316000 mod 17 plus 5 is '7'.  Yes, it's a poor hash function, except it has
two nice features - it can be worked with pencil and paper or a calculator, and
it has similar output distributions to really good hash functions (math geeks
would say it's an "onto function", but not a "one-to-one" function).

http://www.regentsprep.org/Regents/math/algtrig/ATP5/OntoFunctions.htm

Go read that, and get your mind wrapped around onto and one-to-one.  Almost
all good hashes are onto, and almost none are one-to-one.

OK. counter = 0. Hash that, we got 5. increment and hash, we get 6. Increment
and hash, we got 7.  If we keep incrementing and hashing, we'll also get 7 for
19, 36, 53, 70, and roughly 317,783,289 other numbers before you get to my
phone number.

Now if I send you 2 and 7, how do you get that phone number back out, and be
sure you wanted *that* phone number and not 212-555-3488, which *also* ends up
with a hash of 7, so you'd send a counter of 2?  Or a number in Karubadam, Tajikistan
that starts with +992 3772 but also hashes to 7?

The problem is that if the number of input values is longer than the hash output,
there *will* be collisions.  The hash function above generates 17 numbers from 5 to
22 - if you try to hash an 18th number, it *has* to collide with a number
already used. Think a game of musical chairs, which is interesting only because
it's an "onto" function (every chair gets a butt mapped to it), but it's not
one-to-one (not all chairs have *exactly one* butt aimed at them).

(And defining the hash function so that it's one-to-one and every possible
input value generates a different output value doesn't work either - because at
that point, the only counter that generates the same hash as the number you're
trying to send *is that number*.  So if 5552316000 generates a hash value of
8834253743, you'll hash 0, 1, 2,3, ... and only get that same hash again when you get
to the phone number.  Then you send me "5552316000,8834253743" and I hash some
5,552,315,999 other numbers till I reach the phone number.. which you sent me
already as the counter value.

tl;dr:  If the hash function is onto but not one-to-one, you get collisions that
you can't resolve. And if the hash function *is* one-to-one, you end up
sending a counter that's equal to the data.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110518/74c0fa73/attachment.bin>

From hj1980 at gmail.com  Wed May 18 21:42:55 2011
From: hj1980 at gmail.com (Heath Jones)
Date: Thu, 19 May 2011 03:42:55 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <5673.1305771684@localhost>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
	<BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
	<5673.1305771684@localhost>
Message-ID: <BANLkTim2Y+s90Y9zn8_YSVj1ngdsaY7_2w@mail.gmail.com>

> My point here is it IS possible to transfer just a hash and counter value
> and effectively generate identical data at the remote end.

Nope. Let's use phone numbers as an example.  I want to send you the phone
> number 540-231-6000.  The hash function is "number mod 17 plus 5". So
>  5402316000 mod 17 plus 5 is '7'.



> OK. counter = 0. Hash that, we got 5. increment and hash, we get 6.
> Increment
> and hash, we got 7.  If we keep incrementing and hashing, we'll also get 7
> for
> 19, 36, 53, 70, and roughly 317,783,289 other numbers before you get to my
> phone number.
>
> Now if I send you 2 and 7, how do you get that phone number back out, and
> be
> sure you wanted *that* phone number and not 212-555-3488, which *also* ends
> up
>  with a hash of 7, so you'd send a counter of 2?
>

The correct values I would send for that hash function are 7 and the
approximate 317783289, the counter is incremented each time a data value is
reached with a matching hash to the data that is to be communicated, *not
hashing of the counter*..

Example:
I want to send you the number
1000000000000000000000000000000000000000000000000000000000000000000000000000000000000.
The MD5 hash of this is f59a3651eafa7c4dbbb547dd7d6b41d7.
I generate data 0,1,2,3,4,5.. all the way up
to 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000,
observing the hash value of the data just generated each time. Whenever the
hash matches f59a3651eafa7c4dbbb547dd7d6b41d7 , I increment a counter.
Once I have reached the number I want to send you, I send the hash value and
the counter value.

You perform the same function starting at 0 and working your way up until
you have a matching counter value. The number of collisions in the range 0
-> target is represented by the counter value, and as long as both sides are
performing the same sequence this will work.

Obviously this is completely crazy and would never happen with current
processing power... It's just theoretical nonsense, but answers the OP's
question.


From rbf+nanog at panix.com  Wed May 18 21:52:22 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Wed, 18 May 2011 21:52:22 -0500
Subject: Had an idea - looking for a math buff to tell me if it's
	possible with today's technology.
In-Reply-To: <BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
Message-ID: <20110519025221.GA2746@panix.com>

On Thu, May 19, 2011 at 12:26:26AM +0100, Heath Jones wrote:
> I wonder if this is possible:
> 
> - Take a hash of the original file. Keep a counter.
> - Generate data in some sequential method on sender side (for example simply
> starting at 0 and iterating until you generate the same as the original
> data)
> - Each time you iterate, take the hash of the generated data. If it matches
> the hash of the original file, increment counter.
> - Send the hash and the counter value to recipient.
> - Recipient performs same sequential generation method, stopping when
> counter reached.
> 
> Any thoughts?

That will work.  Of course, the CPU usage will be overwhelming --
longer than the age of the universe to do a large file -- but,
theoretically, with enough CPU power, it will work.

For a 8,000,000,000 bit file and a 128 bit hash, you will need a
counter of at least 7,999,999,872 bits to cover the number of possible
collisions.

So you will need at leat 7,999,999,872 + 128 = 8,000,000,000 bits to
send your 8,000,000,000 bit file.  If your goal is to reduce the number
of bits you send, this wouldn't be a good choice.

     -- Brett



From hj1980 at gmail.com  Wed May 18 22:03:46 2011
From: hj1980 at gmail.com (Heath Jones)
Date: Thu, 19 May 2011 04:03:46 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <20110519025221.GA2746@panix.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<20110519025221.GA2746@panix.com>
Message-ID: <BANLkTimafw+eynFjK8he166qDb5mZ3g+5g@mail.gmail.com>

Ha! I was wondering this the whole time - if the size of the counter would
make it a zero sum game. That sux! :)

On 19 May 2011 03:52, Brett Frankenberger <rbf+nanog at panix.com> wrote:

> On Thu, May 19, 2011 at 12:26:26AM +0100, Heath Jones wrote:
> > I wonder if this is possible:
> >
> > - Take a hash of the original file. Keep a counter.
> > - Generate data in some sequential method on sender side (for example
> simply
> > starting at 0 and iterating until you generate the same as the original
> > data)
> > - Each time you iterate, take the hash of the generated data. If it
> matches
> > the hash of the original file, increment counter.
> > - Send the hash and the counter value to recipient.
> > - Recipient performs same sequential generation method, stopping when
> > counter reached.
> >
> > Any thoughts?
>
> That will work.  Of course, the CPU usage will be overwhelming --
> longer than the age of the universe to do a large file -- but,
> theoretically, with enough CPU power, it will work.
>
> For a 8,000,000,000 bit file and a 128 bit hash, you will need a
> counter of at least 7,999,999,872 bits to cover the number of possible
> collisions.
>
> So you will need at leat 7,999,999,872 + 128 = 8,000,000,000 bits to
> send your 8,000,000,000 bit file.  If your goal is to reduce the number
> of bits you send, this wouldn't be a good choice.
>
>     -- Brett
>


From owen at delong.com  Wed May 18 22:21:35 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 18 May 2011 20:21:35 -0700
Subject: IPv6 Conventions
In-Reply-To: <91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
	<91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
Message-ID: <70BC8E23-FF41-4313-AB0C-234B6DCA78DA@delong.com>


On May 18, 2011, at 8:05 AM, Iljitsch van Beijnum wrote:

> On 18 mei 2011, at 16:44, Todd Snyder wrote:
> 
>> 1) Is there a general convention about addresses for DNS servers? NTP
>> servers? dhcp servers?
> 
> There are people who do stuff like blah::53 for DNS, or blah:193:77:81:20 for a machine that has IPv4 address 193.177.81.20.
> 
> For the DNS, I always recommend using a separate /64 for each one, as that way you can move them to another location without having to renumber, and make the addresses short, so a ::1 address or something, because those are the IPv6 addresses that you end up typing a lot.
> 
> For all the other stuff, just use stateless autoconfig or start from ::1 when configuring things manually although there is also a little value in putting some of the IPv4 address in there. Note that 2001:db8::10.0.0.1 is a valid IPv6 address. Unfortunately when you see it copied back to you it shows up as 2001:db8::a00:1 which is less helpful.
> 
>> 2) Are we tending to use different IPs for each service on a device?
> 
> No, the same Internet Protocol.
> 

I believe he meant different IP addresses and I highly recommend doing so.

If you do so, then you can move services around and name things independent of
the actual host that they happen to be on at the moment without having to renumber
or rename.


>> Finally, what tools do people find themselves using to manage IPv6 and
>> addressing?
> 
> Stateless autoconfig for hosts, EUI-64 addressing for routers, VLAN ID in the subnet bits. That makes life simple. Simple be good.
> 

Yep, where that works, those are fine ideas.

Owen




From josmon at rigozsaurus.com  Wed May 18 22:39:19 2011
From: josmon at rigozsaurus.com (John Osmon)
Date: Wed, 18 May 2011 21:39:19 -0600
Subject: NOT Buckaroo (WAS: Re: Netflix Is Eating Up More Of North America's
	Bandwidth Than Any Other	Company)
In-Reply-To: <6021663B-C394-481E-87D3-A0D69056E7B7@jsyoung.net>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
	<6021663B-C394-481E-87D3-A0D69056E7B7@jsyoung.net>
Message-ID: <20110519033919.GA9080@jeeves.rigozsaurus.com>

On Thu, May 19, 2011 at 07:45:44AM +1000, Jeffrey S. Young wrote:
> No matter where you go, there you are.
> [--anon?]

Oliver's Law of Location

Kinda usurped by Buckaroo Banzai in the movie by the same name.  It
always annoys me when attributed to that character.

Go back to your regular programming -- multicast, unicast, or broadcast
it'll proabably be more interesting this this dead end...



From wavetossed at googlemail.com  Wed May 18 22:54:24 2011
From: wavetossed at googlemail.com (Michael Dillon)
Date: Wed, 18 May 2011 20:54:24 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD41776.7020301@mompl.net>
References: <87180.1305391666@nsa.vix.com>
	<7CE9A0ED-D2FA-426B-A8A5-53BE587D739B@muada.com>
	<4DCEC904.1040006@freedesktop.org> <8966.1305416364@nsa.vix.com>
	<4DD16EFA.2020207@freedesktop.org>
	<2AD13289-DD2B-4147-910E-6B5BE638FC48@delong.com>
	<80660.1305606174@nsa.vix.com>
	<20110517090717.GO17325@besserwisser.org>
	<8212.1305636997@nsa.vix.com> <4DD2991B.6040207@netwolves.com>
	<4DD41776.7020301@mompl.net>
Message-ID: <BANLkTi=mYeSABTZdT_SyP6g8LhWCMtJY-w@mail.gmail.com>

>> Right now I see something like ool-6038bdcc.static.optonline.net for one
>> of our servers, how does this
>> mean anything to anyone else?
>
> Does http://?????-?????????.???/ mean more to you?
>
> Or http://xn--4gbrim.xn----ymcbaaajlc6dj7bxne2c.xn--wgbh1c which is what it
> translates to in your browser.

Actually, it translates to
http://xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ in the browser which
then redirects to the URL that you quoted above.

Got to pay attention to these details if you want to keep up your
troubleshooting skills.

--Michael Dillon



From enwpst47 at gmail.com  Wed May 18 23:07:58 2011
From: enwpst47 at gmail.com (Dan Collins)
Date: Thu, 19 May 2011 00:07:58 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
In-Reply-To: <BANLkTim2Y+s90Y9zn8_YSVj1ngdsaY7_2w@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<16314.1305762163@localhost>
	<BANLkTinO5exbdnRd26Cn7EsLjbUxgix2jg@mail.gmail.com>
	<5673.1305771684@localhost>
	<BANLkTim2Y+s90Y9zn8_YSVj1ngdsaY7_2w@mail.gmail.com>
Message-ID: <BANLkTimcKZ31A1reW7OB6=76UNPOoeRCTA@mail.gmail.com>

On Wed, May 18, 2011 at 10:42 PM, Heath Jones <hj1980 at gmail.com> wrote:
> Example:
> I want to send you the number
> 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000.
> The MD5 hash of this is f59a3651eafa7c4dbbb547dd7d6b41d7.
> I generate data 0,1,2,3,4,5.. all the way up
> to 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000,
> observing the hash value of the data just generated each time. Whenever the
> hash matches f59a3651eafa7c4dbbb547dd7d6b41d7 , I increment a counter.
> Once I have reached the number I want to send you, I send the hash value and
> the counter value.
>
> You perform the same function starting at 0 and working your way up until
> you have a matching counter value. The number of collisions in the range 0
> -> target is represented by the counter value, and as long as both sides are
> performing the same sequence this will work.
>
> Obviously this is completely crazy and would never happen with current
> processing power... It's just theoretical nonsense, but answers the OP's
> question.
>

The point here, however, is that for most cases, the hash
f59a3651eafa7c4dbbb547dd7d6b41d7 and the length of the counter will
amount to sending more data than just transmitting the number. For
example, MD5 is a 16 byte hash. For a 20 byte value, you'll need to
transmit a 16 byte hash, plus a counter. On average, of all 20 byte
values, where there are 2^128 hash outputs, each hash output will have
2^32 possible input values, and a counter to store that will need to
be 32 bits long. So you're back where you started. Sometimes this
might even take more space, say if there are 0 strings which hash to
0000...0 and 2^33 which hash to 0000...1 and 2^32 that hash to each
other value, if you're trying to transmit the last item that hashes to
0000...1, you'll actually need more space. Your compression algorithm
just became an inflation algorithm.

--Dan



From frnkblk at iname.com  Wed May 18 23:39:43 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 18 May 2011 23:39:43 -0500
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	Any	Other	Company
In-Reply-To: <922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<922ACC42D498884AA02B3565688AF99531DEADDC02@USEXMBS01.mwd.h2o>
Message-ID: <005401cc15de$c6174ac0$5245e040$@iname.com>

You mean IP TV content products from folks such as SES Americom' IP-PRIME or
IPTV Americas or EchoStart IP TV or Intelsat?

-----Original Message-----
From: Holmes,David A [mailto:dholmes at mwdh2o.com] 
Sent: Wednesday, May 18, 2011 3:01 PM
To: Michael Holstein; Roy
Cc: nanog
Subject: RE: Netflix Is Eating Up More Of North America's Bandwidth Than Any
Other Company

I think this shows the need for an Internet-wide multicast implementation.
Although I can recall working on a product that delivered satellite
multicast streams (with each multicast group corresponding to individual TV
stations) to telco CO's. This enabled the telco to implement multicast at
the edge of their networks, where user broadband clients would issue
multicast joins only as far as the CO. If I recall this was implemented with
the old Cincinnati Bell telco. I admit there are a lot of CO's and cable
head-ends though for this solution to scale.






From iljitsch at muada.com  Thu May 19 02:05:43 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu, 19 May 2011 09:05:43 +0200
Subject: IPv6 Conventions
In-Reply-To: <70BC8E23-FF41-4313-AB0C-234B6DCA78DA@delong.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
	<91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
	<70BC8E23-FF41-4313-AB0C-234B6DCA78DA@delong.com>
Message-ID: <C9704DD4-A288-4002-B552-560F97268B6B@muada.com>

On 19 mei 2011, at 5:21, Owen DeLong wrote:

>>> 2) Are we tending to use different IPs for each service on a device?

>> No, the same Internet Protocol.

> I believe he meant different IP addresses

No, that can't be, he would have said "IP addresses".

> and I highly recommend doing so.

> If you do so, then you can move services around and name things independent of
> the actual host that they happen to be on at the moment without having to renumber
> or rename.

The DNS is already a layer of indirection so in most cases this makes things harder first (having to remember which address is on which host) so they may be easier later (not touching the DNS when services go to a new box). In my opinion, this isn't a good tradeoff most of the time. Only if you want/need addresses to be a particular way (like short for DNS servers) that's helpful.

I was reluctant to do stateless autoconfig for servers at first but it's really rock solid, as long as you're reasonably sure no rogue router advertisements will show up on the subnet in question there's no reason to avoid it.


From sthaug at nethelp.no  Thu May 19 02:30:30 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 19 May 2011 09:30:30 +0200 (CEST)
Subject: IPv6 Conventions
In-Reply-To: <C9704DD4-A288-4002-B552-560F97268B6B@muada.com>
References: <91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
	<70BC8E23-FF41-4313-AB0C-234B6DCA78DA@delong.com>
	<C9704DD4-A288-4002-B552-560F97268B6B@muada.com>
Message-ID: <20110519.093030.74670557.sthaug@nethelp.no>

> >> No, the same Internet Protocol.
> 
> > I believe he meant different IP addresses
> 
> No, that can't be, he would have said "IP addresses".
> 
> > and I highly recommend doing so.
> 
> > If you do so, then you can move services around and name things independent of
> > the actual host that they happen to be on at the moment without having to renumber
> > or rename.
> 
> The DNS is already a layer of indirection so in most cases this makes things harder first (having to remember which address is on which host) so they may be easier later (not touching the DNS when services go to a new box). In my opinion, this isn't a good tradeoff most of the time. Only if you want/need addresses to be a particular way (like short for DNS servers) that's helpful.

Far from it. Running services on separate IP addresses is extremely
important to enable services to move (to a different box) independently.
It has little to do with wanting addresses to be a particular way, and
much more to do with *other* places (e.g. firewalls) where IP addresses
are used and not names.

> I was reluctant to do stateless autoconfig for servers at first but it's really rock solid, as long as you're reasonably sure no rogue router advertisements will show up on the subnet in question there's no reason to avoid it.

Shudder.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no



From owen at delong.com  Thu May 19 02:46:16 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 19 May 2011 00:46:16 -0700
Subject: IPv6 Conventions
In-Reply-To: <C9704DD4-A288-4002-B552-560F97268B6B@muada.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>
	<91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>
	<70BC8E23-FF41-4313-AB0C-234B6DCA78DA@delong.com>
	<C9704DD4-A288-4002-B552-560F97268B6B@muada.com>
Message-ID: <3936B4B6-3B64-44FA-8BD0-867141329533@delong.com>


On May 19, 2011, at 12:05 AM, Iljitsch van Beijnum wrote:

> On 19 mei 2011, at 5:21, Owen DeLong wrote:
> 
>>>> 2) Are we tending to use different IPs for each service on a device?
> 
>>> No, the same Internet Protocol.
> 
>> I believe he meant different IP addresses
> 
> No, that can't be, he would have said "IP addresses".
> 

No, it is not uncommon at least in America for people to refer to IP addresses by the shorter
term "IPs".

>> and I highly recommend doing so.
> 
>> If you do so, then you can move services around and name things independent of
>> the actual host that they happen to be on at the moment without having to renumber
>> or rename.
> 
> The DNS is already a layer of indirection so in most cases this makes things harder first (having to remember which address is on which host) so they may be easier later (not touching the DNS when services go to a new box). In my opinion, this isn't a good tradeoff most of the time. Only if you want/need addresses to be a particular way (like short for DNS servers) that's helpful.
> 

We can agree to disagree. You need to remember which box your particular
services are on anyway, so, I don't see much difference there. Often, the time
delay in DNS changes can be a blocking factor in addressing load issues
by moving things around quickly. IP addresses can be moved with much
greater agility than the DNS abstraction because there are too many broken
browsers and such out there (thank you Micr0$0ft) with ridiculous tendencies
to cache DNS information for a very long time (well beyond the TTL).

> I was reluctant to do stateless autoconfig for servers at first but it's really rock solid, as long as you're reasonably sure no rogue router advertisements will show up on the subnet in question there's no reason to avoid it.

Well, there is one reason... If you have to swap a NIC or any superset of 
a NIC such as an entire machine, you'll have to update
DNS. If you forget to do the DNS update in such a circumstance, you
can blackhole a lot of traffic in the time it takes to figure that out.


Owen




From jnanog at gmail.com  Thu May 19 04:39:58 2011
From: jnanog at gmail.com (Rick Astley)
Date: Thu, 19 May 2011 05:39:58 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <m2ei3v934j.wl%randy@psg.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<m2ei3v934j.wl%randy@psg.com>
Message-ID: <BANLkTi=kVLnfOFJoCTvh7MPEWnQP=Rwwbw@mail.gmail.com>

I think most the points made here are valid about why it isn't an easy
problem to solve with multicast.
Lets say for instance they had a multicast stream that sent the most popular
content (which to Randy's point may not cover much) and 48 hours of that
stream was cached locally on the CPE. What is the additional cost to expand
each of these CPE's to handle this? Will it be HD or SD or both? Are people
willing to Sacrafice their Xbox and PS3 disk space? Does the $60 Roku become
the $400 Roku? Does securing all the content then become more difficult?
What is the hard drive failure rate of these devices with them constantly
writing to disk?

What incentive do users have to to shell out the money for a device that
will handle this caching? Multicasting this type of content seems to create
more problems than it solves.


On Wed, May 18, 2011 at 4:15 PM, Randy Bush <randy at psg.com> wrote:

> > why not permit your users to subscribe to shows/instances, stream them
> > on-demand for viewing later... and leave truly live content
> > (news/sports/etc) as is, with only the ability to pause/rewind?
> >
> > how is this different from broadcast tv today though?
>
> for some of us, the thing that is wonderful about netflix is the long
> tail.  my tastes are a sigma or three out.
>
> randy
>
>


From leigh.porter at ukbroadband.com  Thu May 19 04:53:35 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 19 May 2011 09:53:35 +0000
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=kVLnfOFJoCTvh7MPEWnQP=Rwwbw@mail.gmail.com>
References: <4DD2F087.5050003@gmail.com> <4DD42206.20407@csuohio.edu>
	<BANLkTinagNO0gA6P4BGpPfXKGqTpgME=kw@mail.gmail.com>
	<BANLkTi=begDX46GunOHmdJ4Yyu2rWcQrqg@mail.gmail.com>
	<m2ei3v934j.wl%randy@psg.com>
	<BANLkTi=kVLnfOFJoCTvh7MPEWnQP=Rwwbw@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE0033147864010497@EALPO1.ukbroadband.com>


> From: Rick Astley [mailto:jnanog at gmail.com]
> I think most the points made here are valid about why it isn't an easy
> problem to solve with multicast.
> Lets say for instance they had a multicast stream that sent the most
> popular
> content (which to Randy's point may not cover much) and 48 hours of
> that
> stream was cached locally on the CPE. What is the additional cost to
> expand
> each of these CPE's to handle this? Will it be HD or SD or both? Are
> people
> willing to Sacrafice their Xbox and PS3 disk space? Does the $60 Roku
> become
> the $400 Roku? Does securing all the content then become more
> difficult?
> What is the hard drive failure rate of these devices with them
> constantly
> writing to disk?
> 
> What incentive do users have to to shell out the money for a device
> that
> will handle this caching? Multicasting this type of content seems to
> create
> more problems than it solves.


Lots of people already cache multicast streams to disk at home. I have a Humax digital TV cache (PVR ;-) that caches HD and SD content for me automatically. 

Doing the same over a network is not that much more of a jump really. My Humax box already has Ethernet to my home network, grabbing a multicast feed is no more than a software feature.

So in a way people already pay to do just this. 

Indeed, in the UK, SKY offer a movies service which I believe you can cache locally if you have a SKY+ thing. So, SKY do it now and people pay for it.

--
Leigh




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From kix at kix.es  Thu May 19 05:30:08 2011
From: kix at kix.es (Rodolfo (kix))
Date: Thu, 19 May 2011 12:30:08 +0200
Subject: IPv6 and RDNS
Message-ID: <BANLkTikUg4KmQ7OsLe0Lr=d_F92DFWUH4A@mail.gmail.com>

Hi!

what is the status of the reverse DNS in IPv6? The draft
"http://tools.ietf.org/html/draft-howard-isp-ip6rdns-04" is expired.

What are the network operators doing?

Regards,

kix
-- 
Rodolfo Garc?a "kix"
http://www.kix.es/ ham: EA4ERH @ IN80ER



From newton at internode.com.au  Thu May 19 05:39:59 2011
From: newton at internode.com.au (Mark Newton)
Date: Thu, 19 May 2011 10:39:59 +0000
Subject: IPv6 and RDNS
In-Reply-To: <BANLkTikUg4KmQ7OsLe0Lr=d_F92DFWUH4A@mail.gmail.com>
References: <BANLkTikUg4KmQ7OsLe0Lr=d_F92DFWUH4A@mail.gmail.com>
Message-ID: <47285CFE-E8B2-47CC-A4FC-3AA2C8AF90F7@internode.com.au>


On 19/05/2011, at 8:00 PM, Rodolfo (kix) wrote:

> Hi!
> 
> what is the status of the reverse DNS in IPv6?

Rhymes with "muster duck."

  - mark


--
Mark Newton                               Email:  newton at internode.com.au (W)
Network Engineer                          Email:  newton at atdot.dotat.org  (H)
Internode Pty Ltd                         Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223








From bjorn at mork.no  Thu May 19 07:54:05 2011
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Thu, 19 May 2011 14:54:05 +0200
Subject: IPv6 and RDNS
In-Reply-To: <BANLkTikUg4KmQ7OsLe0Lr=d_F92DFWUH4A@mail.gmail.com> (Rodolfo's
	message of "Thu, 19 May 2011 12:30:08 +0200")
References: <BANLkTikUg4KmQ7OsLe0Lr=d_F92DFWUH4A@mail.gmail.com>
Message-ID: <87liy24zrm.fsf@nemi.mork.no>

"Rodolfo (kix)" <kix at kix.es> writes:

> what is the status of the reverse DNS in IPv6? The draft
> "http://tools.ietf.org/html/draft-howard-isp-ip6rdns-04" is expired.
>
> What are the network operators doing?

For interfaces:
  same as for IPv4 (autogenerate forward and reverse)
For residential sites:  
  nothing
For business sites: 
  same as for IPv4 (rDNS management interface, optional delegation,
  nothing by default)

The assumption is that only mail servers, web servers and other hosts
you'd like to be verifiable within a domain, will need rDNS.  That's the
bare minimum. Having names on interfaces is simple to do (for us at
least), and makes traceroutes etc easier to read, so we do those. For
the rest of the addresses, rDNS really doesn't matter.

Personally I would love to provide delegation and/or some rDNS
management interface for residential sites as well, but time will tell
if we get around to that.  There are plenty of items on the wishlist and
this is not on the top...

We will not auto-generate bulk names like we do for IPv4 pools.  In
theory this could be done using something like e.g.
http://member.wide.ad.jp/~fujiwara/v6rev.pl
but I just don't see the use.  The generated names will provide exactly
no additional value to the address they are supposed to name.

We will not use wildcards either.  They provide no value as long as they
cannot be mapped forward.  In fact, they will rather break than fix any
application actually caring about rDNS.



Bj?rn



From bicknell at ufp.org  Thu May 19 08:08:17 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 19 May 2011 06:08:17 -0700
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <20110519025221.GA2746@panix.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<20110519025221.GA2746@panix.com>
Message-ID: <20110519130817.GB96593@ussenterprise.ufp.org>

In a message written on Wed, May 18, 2011 at 09:52:22PM -0500, Brett Frankenberger wrote:
> That will work.  Of course, the CPU usage will be overwhelming --
> longer than the age of the universe to do a large file -- but,
> theoretically, with enough CPU power, it will work.

You have a different definition of "work" than I do.  If it can't finish
before the universe ends I don't think it works. :)

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110519/5a75160f/attachment.bin>

From leigh.porter at ukbroadband.com  Thu May 19 08:12:03 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 19 May 2011 13:12:03 +0000
Subject: Had an idea - looking for a math buff to tell me if it's
	possible	with today's technology.
In-Reply-To: <20110519130817.GB96593@ussenterprise.ufp.org>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTinBrmzFWi7y=1goAyHrT7dCi5SA8w@mail.gmail.com>
	<20110519025221.GA2746@panix.com>
	<20110519130817.GB96593@ussenterprise.ufp.org>
Message-ID: <D181DDABABE57E4DB72FEE0033147864010799@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org]
> Sent: 19 May 2011 14:10
> To: nanog
> Subject: Re: Had an idea - looking for a math buff to tell me if it's
> possible with today's technology.
> 
> In a message written on Wed, May 18, 2011 at 09:52:22PM -0500, Brett
> Frankenberger wrote:
> > That will work.  Of course, the CPU usage will be overwhelming --
> > longer than the age of the universe to do a large file -- but,
> > theoretically, with enough CPU power, it will work.
> 
> You have a different definition of "work" than I do.  If it can't
> finish before the universe ends I don't think it works. :)

You obviously do not read enough SciFi. By then (whenever then is)  sub picoseconds optical quantum computers will be able to solve such problems before you knew they were problems ;-)

--
Leigh Porter



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From erikm at buh.org  Thu May 19 08:48:21 2011
From: erikm at buh.org (Erik Muller)
Date: Thu, 19 May 2011 09:48:21 -0400
Subject: IPv6 Conventions
In-Reply-To: <3936B4B6-3B64-44FA-8BD0-867141329533@delong.com>
References: <BANLkTi=CW5yXkc9QTycmwwFB6DUFvy31+Q@mail.gmail.com>	<91704ACC-E2F4-4FD9-8F74-1136256E94D3@muada.com>	<70BC8E23-FF41-4313-AB0C-234B6DCA78DA@delong.com>	<C9704DD4-A288-4002-B552-560F97268B6B@muada.com>
	<3936B4B6-3B64-44FA-8BD0-867141329533@delong.com>
Message-ID: <4DD51FA5.4010906@buh.org>

On 5/19/11 3:46 , Owen DeLong wrote:
>  Often, the time
> delay in DNS changes can be a blocking factor in addressing load issues
> by moving things around quickly. IP addresses can be moved with much
> greater agility than the DNS abstraction...

And having persistent IP address-to-service mappings aside from DNS can 
also be useful for other things like firewall/IDS rules that often don't 
use DNS at all.

-e



From jamie at photon.com  Thu May 19 08:48:35 2011
From: jamie at photon.com (Jamie Bowden)
Date: Thu, 19 May 2011 09:48:35 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possiblewith today's technology.
In-Reply-To: <20110518210318.GA61570@ussenterprise.ufp.org>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com><4DD4299D.8050402@csuohio.edu><BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
	<20110518210318.GA61570@ussenterprise.ufp.org>
Message-ID: <275FEA2949B48341A3B46F424B613D857C43@WDC-MX.photon.com>

I know you're having fun with him, but I think what the original poster
had in mind was more like thinking of a file as just a string of
numbers.  Create an equation that generates that string of numbers, send
equation, regenerate string on other end.  Of course, if it was that
easy, someone would already have done it (or who knows, IBM might have
done this decades ago, put it on a virtual shelf in their IP closet, and
forgot about it...apparently they do that sort of thing all the time).
Compression is mathematically akin to cryptography, with the compressed
file being a huge seed with a standard algorithm (and a very weak one by
modern cryptography standards, sure, but imagine someone trying to
figure out a .zip file in the 50s).

Jamie

-----Original Message-----
From: Leo Bicknell [mailto:bicknell at ufp.org] 
Sent: Wednesday, May 18, 2011 5:03 PM
To: nanog
Subject: Re: Had an idea - looking for a math buff to tell me if it's
possiblewith today's technology.

In a message written on Wed, May 18, 2011 at 04:33:34PM -0400,
Christopher Morrow wrote:
> no no no.. it's simply, since the OP posited a math solution, md5.
> ship the size of file + hash, compute file on the other side. All
> files can be moved anywhere regardless of the size of the file in a
> single packet.
> 
> 
> The solution is left as an exercise for the reader.

Bah, you should include the solution, it's so trivial.

Generate all possible files and then do an index lookup on the MD5.
It's a little CPU heavy, but darn simple to code.

You can even stop when you get a match, which turns out to be a HUGE
optimization. :)

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/



From andy-nanog at bash.sh  Thu May 19 09:19:48 2011
From: andy-nanog at bash.sh (Andrew Mulholland)
Date: Thu, 19 May 2011 15:19:48 +0100
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<4DD4299D.8050402@csuohio.edu>
	<BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
Message-ID: <BANLkTi=kv9ynsXTyn+tEX0ii-jkRRBVqBw@mail.gmail.com>

On Wed, May 18, 2011 at 9:33 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:

>
> no no no.. it's simply, since the OP posited a math solution, md5.
> ship the size of file + hash, compute file on the other side. All
> files can be moved anywhere regardless of the size of the file in a
> single packet.

only problem is that of hash collision then.



From lstewart at superb.net  Thu May 19 10:42:09 2011
From: lstewart at superb.net (Landon Stewart)
Date: Thu, 19 May 2011 08:42:09 -0700
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <D51498F0B6E1EF408AC4D63440BFD6F8AA13E7A2CB@skbramsx02.emea.att.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>
	<19924.27210.53557.472985@world.std.com>
	<D51498F0B6E1EF408AC4D63440BFD6F8AA13E7A2CB@skbramsx02.emea.att.com>
Message-ID: <BANLkTin5TB0vA=N88rPKOWNufespqBrVyg@mail.gmail.com>

On Thu, May 19, 2011 at 5:05 AM, Vitkovsky, Adam <avitkovsky at emea.att.com>wrote:

> >"inverse problem"
> This is what I believe Landon meant in his original post
>
> Everybody started talking about compression -but that is I believe sending
> the result of the function -where both nodes know the function
>
> But how hard if at all possible is to figure out a function(or set of
> functions) and variables that describe the given data
>
> And than just send those functions and variables to the other node
> And let it to recompute the original file
>
> Complex function can be represented by simple numbers to shrink down the
> amount of data to be sent over the wire
>
> If the file is: 1048576
>
> -than that coule be represneted via:
> 1*1
> X=2
> Y=10
> Where both nodes would know that 1 = x^y
>

Just wanted to say yes, this is entirely what I meant.  Of course the
smaller the file the more pointless it gets but still...  If the file was
1GB instead of just 7 bytes I'm wondering if a regular old workstation could
put it back together in any reasonable amount of time with the equation.


-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net


From bhmccie at gmail.com  Thu May 19 12:02:51 2011
From: bhmccie at gmail.com (Hammer)
Date: Thu, 19 May 2011 12:02:51 -0500
Subject: Experience with Open Source load balancers?
In-Reply-To: <BANLkTimVWenfU7fHZPpEWkLCnf0QAEDSCQ@mail.gmail.com>
References: <DFA5AECDEC85EE4087D45C463C19B375134FFFA292@KWAEXMAIL1.ARRS.ARRISI.COM>
	<BANLkTimVWenfU7fHZPpEWkLCnf0QAEDSCQ@mail.gmail.com>
Message-ID: <BANLkTin6kBxMdAMQ_5_jngp_cmdQLwGSiA@mail.gmail.com>

Mattew,
      We run high volume SSL but not nearly the 12Gbps you are talking about
so that hasn't been an issue for us. Thanks for the information. Looks like
the Citrix ANG rep owes me another lunch to explain himself. :)

I'm gonna do some research on NGINX...


 -Hammer-

"I was a normal American nerd."
-Jack Herer





On Wed, May 18, 2011 at 2:23 PM, Andreas Echavez <andreas at livejournalinc.com
> wrote:

> We're using both an F5 BigIP as well as Nginx (open source software) in a
> production environment.
>
> They both have their merits, but when we recently came under some advanced
> DDoSes (slowloris, slow POST, and more), we couldn't process certain types
> of layer 7 insepction/modification because it was too heavy for the F5 to
> handle. Nginx was more cost effective because we could scale laterally with
> cheap commodity hardware.
>
> This isn't a knock on the BigIP though; it's a much better piece of
> equipment, has commercial support, and a fantastic web interface. With
> Nginx
> you might find yourself compiling modules in by hand and writing config
> files.
>
> Ultimately, the open source solution is going to stand the test of time
> better. It all depends on who's paying the bills, and what your time is
> worth. Nginx was specifically worth the effort for us because we had unique
> traffic demands that change too quickly for a commercial solution.
>
> Thanks,
> Andreas
>
>
> On Mon, May 16, 2011 at 4:15 PM, Welch, Bryan <Bryan.Welch at arrisi.com
> >wrote:
>
> > Greetings all.
> >
> > I've been tasked with comparing the use of open source load balancing
> > software against commercially available off the shelf hardware such as
> F5,
> > which is what we currently use.  We use the load balancers for
> traditional
> > load balancing, full proxy for http/ssl traffic, ssl termination and
> > certificate management, ssl and http header manipulation, nat, high
> > availability of the physical hardware and stateful failover of the tcp
> > sessions.  These units will be placed at the customer prem supporting our
> > applications and services and we'll need to support them accordingly.
> >
> > Now my "knee jerk" reaction to this is that it's a really bad idea.  It
> is
> > the heart and soul of our data center network after all.  However, once I
> > started to think about it I realized that I hadn't had any real
> experience
> > with this solution beyond tinkering with it at home and reading about it
> in
> > years past.
> >
> > Can anyone offer any operational insight and real world experiences with
> > these solutions?
> >
> > TIA, replies off list are welcomed.
> >
> >
> > Regards,
> >
> > Bryan
> >
> >
>


From smb at cs.columbia.edu  Thu May 19 13:01:20 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Thu, 19 May 2011 14:01:20 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possiblewith today's technology.
In-Reply-To: <275FEA2949B48341A3B46F424B613D857C43@WDC-MX.photon.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com><4DD4299D.8050402@csuohio.edu><BANLkTikvgTR+tUN4WTtc1e8HudoAro=mRg@mail.gmail.com>
	<20110518210318.GA61570@ussenterprise.ufp.org>
	<275FEA2949B48341A3B46F424B613D857C43@WDC-MX.photon.com>
Message-ID: <4EA2B35F-16CE-4C29-941A-29D38FF4FAEA@cs.columbia.edu>


On May 19, 2011, at 9:48 35AM, Jamie Bowden wrote:

> I know you're having fun with him, but I think what the original poster
> had in mind was more like thinking of a file as just a string of
> numbers.  Create an equation that generates that string of numbers, send
> equation, regenerate string on other end.  Of course, if it was that
> easy, someone would already have done it

Yes.  I guess I was too terse with my answer, but this is known as
Kolmogorv complexity.  It's a well-known concept, and in general
you can't construct such equations/programs/what-have-yous.  Wikipedia
even gives a proof of that...


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From bonomi at mail.r-bonomi.com  Thu May 19 13:22:34 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 19 May 2011 13:22:34 -0500 (CDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD431B6.3030402@2mbit.com>
Message-ID: <201105191822.p4JIMYr9065308@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Wed May 18 16:12:17 2011
> Date: Wed, 18 May 2011 14:53:10 -0600
> From: Brielle Bruns <bruns at 2mbit.com>
> To: nanog at nanog.org
> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any
> 	Other Company
>
> On 5/18/11 2:33 PM, Dorn Hetzel wrote:
> > If we're really talking efficiency, the "popular" stuff should probably 
> > stream out over the bird of your choice (directv, etc) because it's 
> > hard to beat millions of dishes and dvr's and no cable plant.
> >
> > Then what won't fit on the bird goes unicast IP from the nearest CDN.   
> > Kind of like the "on demand over broadband" on my satellite box.  Their 
> > selection sucks, but the model is valid.
>
>
>
> If someone hadn't mentioned already, there used to be a usenet provider 
> that delivered a full feed via Satellite. 

There were, at different times, two companies that did that.  Both went
under because expenses exceeded income.

The one that was _much_ more interesting was the one that Lauren Weinstein
had a hand in.  It piggy-backed a Usenet feed in the vertical blanking
interval of several big "independant" TV stations -- ones that were 
carried by practically every cable company in the country.  Distribution
to the cable companies was via satellite, but the USENET feed, being 
_part_ of the video signal, consumed _zero_ additional bandwidth, and
rode the satellite links for free. 

To get the feed, all you needed was a TV tuner with 'video out', and the
purpose-huilt decoder box that extracted the vertical interval data.

This service died as the independants moved to encrypted transmission,
because the encryption did _not_ perserve anything in the 'blanking'
timeslot. only the 'viewable' field-image was trasmitted, _as_ a full-field
image.  Sync, blanking, etc. was _locally_ generated on the receiving end.

An "elegant" idea, done in by changing technology.   *sigh*





From jamie at photon.com  Thu May 19 13:37:27 2011
From: jamie at photon.com (Jamie Bowden)
Date: Thu, 19 May 2011 14:37:27 -0400
Subject: High throughput switches...
Message-ID: <275FEA2949B48341A3B46F424B613D857C45@WDC-MX.photon.com>

I'm looking for people's experiences with Voltaire switches in general
and the Vantage 6048 in particular.

 

We'd like to use a central switch and use 16 10g ports trunked via LACP
to two other switches and a SAN (to clarify, the central switch would
have three data channels, each one consisting of 16 trunked 10g ports,
the two downstream switches would have 10gb clients hanging off of them
and I'm not sure how the SAN is supposed to use 16 10g ports; they
haven't felt the need to give me specs on it, but for now I'm assuming
it either has a built in switch fabric that supports LACP or will have
another switch dedicated to it can handle different L1 media).  Assuming
we can bond that many channels (which I'm not sure about, but none of
the docs I've read on the IEEE protocol involved indicate a limit on the
number ports that can be aggregated, and the manufacturer docs don't
mention it either), how realistic is the expectation of getting a full
160gb throughput?  Are the switches in question up to the task?

 

This is a research project we're building for a customer, so I'm trying
to manage expectations, but this isn't the sort of thing I've personally
ever built before and I'm hoping someone here has done something close
enough and is willing to share experiences.

 

Thanks,

 

Jamie



From james.harr at gmail.com  Thu May 19 14:49:20 2011
From: james.harr at gmail.com (James Harr)
Date: Thu, 19 May 2011 14:49:20 -0500
Subject: High throughput switches...
In-Reply-To: <275FEA2949B48341A3B46F424B613D857C45@WDC-MX.photon.com>
References: <275FEA2949B48341A3B46F424B613D857C45@WDC-MX.photon.com>
Message-ID: <BANLkTimupPZePs8KVJqh71cGS3ZWL2yKgA@mail.gmail.com>

Bonding usually involves some sort of flow-based hashing mechanism for
balancing across the links. The logic behind it being that reordering TCP
packets (among other things) negates the benefit of the aggregation in CPU
costs and retransmissions. So it's important to keep one flow (really one
direction of one flow) on one link to prevent out of order delivery.

So if you want to utilize that bandwidth, you need a lot of flows. I
remember numbers being thrown around that you need at least 1000 flows to
balance two paths. I don't know how many you'd need for that to scale to 16
links. Obviously if this is SAN traffic, the usage patterns are going to be
completely different from desktop, so ymmv.

Also, this information may be out of date and/or irrelevant now, but it's
something I've run into before with link aggregation.

On Thu, May 19, 2011 at 1:37 PM, Jamie Bowden <jamie at photon.com> wrote:

> I'm looking for people's experiences with Voltaire switches in general
> and the Vantage 6048 in particular.
>
>
>
> We'd like to use a central switch and use 16 10g ports trunked via LACP
> to two other switches and a SAN (to clarify, the central switch would
> have three data channels, each one consisting of 16 trunked 10g ports,
> the two downstream switches would have 10gb clients hanging off of them
> and I'm not sure how the SAN is supposed to use 16 10g ports; they
> haven't felt the need to give me specs on it, but for now I'm assuming
> it either has a built in switch fabric that supports LACP or will have
> another switch dedicated to it can handle different L1 media).  Assuming
> we can bond that many channels (which I'm not sure about, but none of
> the docs I've read on the IEEE protocol involved indicate a limit on the
> number ports that can be aggregated, and the manufacturer docs don't
> mention it either), how realistic is the expectation of getting a full
> 160gb throughput?  Are the switches in question up to the task?
>
>
>
> This is a research project we're building for a customer, so I'm trying
> to manage expectations, but this isn't the sort of thing I've personally
> ever built before and I'm hoping someone here has done something close
> enough and is willing to share experiences.
>
>
>
> Thanks,
>
>
>
> Jamie
>
>


-- 
^[:wq^M


From warren at kumari.net  Thu May 19 15:34:11 2011
From: warren at kumari.net (Warren Kumari)
Date: Thu, 19 May 2011 16:34:11 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <BANLkTin5TB0vA=N88rPKOWNufespqBrVyg@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>
	<19924.27210.53557.472985@world.std.com>
	<D51498F0B6E1EF408AC4D63440BFD6F8AA13E7A2CB@skbramsx02.emea.att.com>
	<BANLkTin5TB0vA=N88rPKOWNufespqBrVyg@mail.gmail.com>
Message-ID: <408E2598-0E6F-40AA-96D4-F780199AAF3D@kumari.net>


On May 19, 2011, at 11:42 AM, Landon Stewart wrote:

> On Thu, May 19, 2011 at 5:05 AM, Vitkovsky, Adam <avitkovsky at emea.att.com>wrote:
> 
>>> "inverse problem"
>> This is what I believe Landon meant in his original post
>> 
>> Everybody started talking about compression -but that is I believe sending
>> the result of the function -where both nodes know the function
>> 
>> But how hard if at all possible is to figure out a function(or set of
>> functions) and variables that describe the given data
>> 
>> And than just send those functions and variables to the other node
>> And let it to recompute the original file
>> 
>> Complex function can be represented by simple numbers to shrink down the
>> amount of data to be sent over the wire
>> 
>> If the file is: 1048576
>> 
>> -than that coule be represneted via:
>> 1*1
>> X=2
>> Y=10
>> Where both nodes would know that 1 = x^y
>> 
> 
> Just wanted to say yes, this is entirely what I meant.  Of course the
> smaller the file the more pointless it gets but still...  If the file was
> 1GB instead of just 7 bytes I'm wondering if a regular old workstation could
> put it back together in any reasonable amount of time with the equation.

While many folk have said "You've just invented compression", I'm going to be a little more specific -- "Wavelet compression".

W
> 
> 
> -- 
> Landon Stewart <LStewart at SUPERB.NET>
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
> 




From morrowc.lists at gmail.com  Thu May 19 15:54:13 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 19 May 2011 16:54:13 -0400
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <408E2598-0E6F-40AA-96D4-F780199AAF3D@kumari.net>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>
	<19924.27210.53557.472985@world.std.com>
	<D51498F0B6E1EF408AC4D63440BFD6F8AA13E7A2CB@skbramsx02.emea.att.com>
	<BANLkTin5TB0vA=N88rPKOWNufespqBrVyg@mail.gmail.com>
	<408E2598-0E6F-40AA-96D4-F780199AAF3D@kumari.net>
Message-ID: <BANLkTikNkLsU5+M+itugKbuYVH0cP=uCWw@mail.gmail.com>

On Thu, May 19, 2011 at 4:34 PM, Warren Kumari <warren at kumari.net> wrote:
>> Just wanted to say yes, this is entirely what I meant. ?Of course the
>> smaller the file the more pointless it gets but still... ?If the file was
>> 1GB instead of just 7 bytes I'm wondering if a regular old workstation could
>> put it back together in any reasonable amount of time with the equation.
>
> While many folk have said "You've just invented compression", I'm going to be a little more specific -- "Wavelet compression".

'quantum entanglement'!!



From matthew at matthew.at  Thu May 19 18:21:28 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 19 May 2011 16:21:28 -0700
Subject: Yahoo and IPv6
In-Reply-To: <BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
Message-ID: <4DD5A5F8.8060109@matthew.at>

On 5/9/2011 8:16 AM, Arie Vayner wrote:
> What disturbs me is the piece saying "We recommend disabling
> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
> ", with a very easy link...

And I was just sent this link from our very own NSA: 
http://www.nsa.gov/ia/_files/factsheets/macosx_10_6_hardeningtips.pdf

Disable IPv6 and AirPort when Not Needed
Open the Network pane in System Preferences. For every
network interface listed:
?     If it is an AirPort interface but AirPort is not required,
click "Turn AirPort off."
?     Click "Advanced."  Click on the TCP/IP tab and set
"Configure IPv6:" to "Off" if not needed.  If it is an
AirPort interface, click on the AirPort tab and enable
"Disconnect when logging out."

Matthew Kaufman



From owen at delong.com  Thu May 19 18:26:34 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 19 May 2011 16:26:34 -0700
Subject: Yahoo and IPv6
In-Reply-To: <4DD5A5F8.8060109@matthew.at>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<4DD5A5F8.8060109@matthew.at>
Message-ID: <2AE549BA-01DA-4538-ADB8-C6E3B68B84E0@delong.com>


On May 19, 2011, at 4:21 PM, Matthew Kaufman wrote:

> On 5/9/2011 8:16 AM, Arie Vayner wrote:
>> What disturbs me is the piece saying "We recommend disabling
>> IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>
>> ", with a very easy link...
> 
> And I was just sent this link from our very own NSA: http://www.nsa.gov/ia/_files/factsheets/macosx_10_6_hardeningtips.pdf
> 
> Disable IPv6 and AirPort when Not Needed
> Open the Network pane in System Preferences. For every
> network interface listed:
> ?     If it is an AirPort interface but AirPort is not required,
> click "Turn AirPort off."
> ?     Click "Advanced."  Click on the TCP/IP tab and set
> "Configure IPv6:" to "Off" if not needed.  If it is an
> AirPort interface, click on the AirPort tab and enable
> "Disconnect when logging out."
> 
> Matthew Kaufman

Proving that the NSA is behind the times like any other government institution. No real surprise.

Owen




From mysidia at gmail.com  Thu May 19 19:27:56 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 19 May 2011 19:27:56 -0500
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <4DD2F087.5050003@gmail.com>
References: <4DD2F087.5050003@gmail.com>
Message-ID: <BANLkTi=RnAiiwyJ4dOwra30MENWGhxD1kA@mail.gmail.com>

On Tue, May 17, 2011 at 5:02 PM, Roy <r.engehausen at gmail.com> wrote:
> http://e.businessinsider.com/public/184962

You know...  I say the way the headline characterizes the subject is misleading.
It would be more accurate to say something like....

"North American Internet users utilize more of their available network
capacity to access
Netflix, than any other company's service."
Bandwidth is not "eaten up";   it is utilized.   Bandwidth is not a
scarce, indivisable resource.

Since the article is about "peak downstream bandwidth in North America".
The statistics are about what broadband customers are doing;
according to Sandvine.


The first thought that enters my mind, when I see this headline, and
those charts,
is that the provider of the statistics / chooser of the headline has a
product they
want to sell.   :)

-- 
-JH



From adrian at creative.net.au  Thu May 19 21:39:41 2011
From: adrian at creative.net.au (Adrian Chadd)
Date: Fri, 20 May 2011 10:39:41 +0800
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <408E2598-0E6F-40AA-96D4-F780199AAF3D@kumari.net>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<BANLkTimT=oqzX4e6-6XNTd1aDFAHSo9kPg@mail.gmail.com>
	<19924.27210.53557.472985@world.std.com>
	<D51498F0B6E1EF408AC4D63440BFD6F8AA13E7A2CB@skbramsx02.emea.att.com>
	<BANLkTin5TB0vA=N88rPKOWNufespqBrVyg@mail.gmail.com>
	<408E2598-0E6F-40AA-96D4-F780199AAF3D@kumari.net>
Message-ID: <20110520023941.GZ24006@skywalker.creative.net.au>

On Thu, May 19, 2011, Warren Kumari wrote:

> > Just wanted to say yes, this is entirely what I meant.  Of course the
> > smaller the file the more pointless it gets but still...  If the file was
> > 1GB instead of just 7 bytes I'm wondering if a regular old workstation could
> > put it back together in any reasonable amount of time with the equation.
> 
> While many folk have said "You've just invented compression", I'm going to be a little more specific -- "Wavelet compression".

Well, yes. There's other types of function driven compression rather than
dictionary driven compression (which is just function driven compression :-),
eg iterated function systems.

The problem is finding a method that works for a variety of data. From what I
understand, (lossless) wavelet compression isn't fantastic for arbitrary types
of data.

I'd suggest the original poster pull up some literature introducing them
to information theory and compression techniques in general. Heck, even the
wikipedia article on lossless compression is a good starting point.

I think once the original poster understands some of the basics of information
theory and coding as it relates to representing say 1GB from 7 bytes as given
above, they may be better equipped to ask more specific (and useful!) questions.

HTH,



Adrian




From rfg at tristatelogic.com  Fri May 20 05:25:54 2011
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Fri, 20 May 2011 03:25:54 -0700
Subject: HIJACKED: AS18466, courtesy of Global Crossing (AS3549)
Message-ID: <30315.1305887154@tristatelogic.com>



Abundant evidence indicates that AS18466, allocated by LACNIC, has been
hijacked.

All of the routes currently announced by this AS, i.e.:

    170.25.0.0/19
    170.25.32.0/19
    170.25.160.0/19
    170.25.192.0/19

are currently routing IP blocks, also allocated by LACNIC, which have also
themselves appear to have been hijacked.

As you can see below, AS18466 was first allocated (apparently by ARIN) on
2000-08-31 and its WHOIS record was last updated on 2006-06-16.  Note
however that the domain associated with the contact e-mail address for
this ASN, i.e. "geminicom.net" was apparently re-registered on 2010-11-01,
unboubtedly by the hijacker.  (This is the mostly commonly used approach
to AS and IP block hijacking, i.e. find an abandoned AS or IP block whose
contact domain has become unregistered and then simply re-register it and
then pretend that you are the original party to whom the resource was
allocated.  In short, fraud and identity theft.)

=========================================================================
aut-num:     AS18466
owner:       Geminicommunications Limited
ownerid:     BZ-GELI-LACNIC
address:     13 1/2 Northern Highway
address:     Belize City,
country:     BZ
owner-c:     HC170-ARIN
created:     20000831
changed:     20060616
source:      ARIN-HISTORIC

nic-hdl:     HC170-ARIN
person:      Hans Cardenas
e-mail:      hcardenas at GEMINICOM.NET
address:     13 1/2 Northern Highway
address:     Belize City,
country:     BZ
phone:       501254011
source:      ARIN-HISTORIC
=========================================================================

As shown here:

  http://www.robtex.com/as/as18466.html#graph

AS18466 is connected to the Internet only via Global Crossing.

In my opinion, and based on the available evidence, there appear to me to be
only two possibilities.  Either (1) Global Crossing is consciously and in-
tentionally participating in this fraud and identity theft scheme or else
(2) Global Crossing has allowed itself to be hoodwinked by crooks who con-
vinced one or more decision makers at Global Crossing to allow fradulent
route announcements to pass to the wider Internet via Global Crossing's
network.

I look forward to Global Crossing's clarification of this event.

Additional evidence of this hijacking may be found here:

   ftp://ftp.tristatelogic.com/pub/AS18466-rDNS.txt

and also here:

   ftp://ftp.tristatelogic.com/pub/AS18466-nameservers.txt

Both of these files show an abundance of "snowshoe" spamming domains which
are associated with the IPv4 space currently routed by AS18466.  All of
these domains have been registered in the relatively recent past, and all
of them have been registered either with WHOIS anonymity cloaking or with
clearly fradulent WHOIS information.

Additional supporting evidence of this hijacking is also readily available
in teh form of the following fradulent web site:

   http://geminicom.net/

This false front web site, intended to serve as part of the clever deception
surrounding the miraculous rebirth of "Geminicommunications Limited", is in
fact nothing more than a thin veneer, much of which appears to have been
simply stolen/copied from the web site of a legitimate UK company, i.e.
http://www.8el.com/ (That copying itself represents yet another fradulent
and illegal act, i.e. blatant copyright violation.)

As was true with the prior group of IP hijackings that I reported on back
on April 14th[1], in this case also the majority of the snowshoe spamming
domains involved in this incident (as shown in the AS18466-rDNS.txt file,
see above) have been registered via the ICANN accredited registrar named
Dynamic Dolphin, Inc.

It is, I believe, well and widely know by this time that Dynamic Dolphin,
Inc. is among the past and/or present business interests of the notorious
Scott Richter, interests which include, or which have included bulk e-mail
advertising firm Media Breakaway LLC, aka OptInRealBig.

Other evidence I have in hand also indicates a clear connection between
this hijacked IP space and another of Richter's business interests,
specifically a company called WholesaleBandwidth, Inc.  (I am not dis-
closing this additional evidence publically at the present time.  I have
my reasons.)


FULL DISCLOSURE:  Previously, in 2005, my company filed a legal claim in
the bankruptcy proceeding of Media Breakaway LLC, said bankruptcy having
been largely if not entirely precipitated by a multi-million dollar legal
action initiated by Microsoft against Media Breakaway LLC and Scott Richter
personally for various alleged mass violations of various anti-spam laws.
My company's claim was subsequently dismissed by the bankruptcy judge in
that case (improperly, in my view) and following the later dismissal of
the bankruptcy case, the Richters (Scott and father Steve) sued myself,
my company, and my attorney for alleged "abuse of process", specifically
for having had the gumption to show up in the bankruptcy case and make a
claim not too awfully different from the one that Microsoft had made.  The
Richter's "abuse of process" case against me, my company, and my attorney
was also subsequently dismissed, the judge having found it to be lacking
in merit.

Regards,
rfg


P.S. Those of you who missed it the first time around may wish to review
the following potentially relevant historical reference material:

    http://www.47-usc-230c2.org/chapter2.html
    http://www.47-usc-230c2.org/chapter3.html


P.P.S.  Although I have previously bemoaned ARIN's lack of agressivness in
reclaiming abandoned ASNs and IP blocks that have been hijacked, I feel
compelled to note that at least they (ARIN) do have a proccess in place
for doing so, i.e. when and if they are motivated in that direction.
I have it on good authority however that LACNIC does not even have an
established process for reclaiming abandoned number resources.  Given
that the problem of hijacked number resources, rather than disappearing,
is in fact accelerating, over time, I do believe that it would behove
LACNIC and other RiRs to develop processes for reclaiming abandoned
resources, in particular when and where it becomes evident that these
resources have been hijacked.

=-=-=-=-=
[1] See http://mailman.nanog.org/pipermail/nanog/2011-April/035235.html



From john at sackheads.org  Fri May 20 09:23:15 2011
From: john at sackheads.org (John Payne)
Date: Fri, 20 May 2011 10:23:15 -0400
Subject: corporations using BGP for advertising prefixes in mid-1990s
In-Reply-To: <4DCC7BF3.9070202@gmail.com>
References: <4DCC7BF3.9070202@gmail.com>
Message-ID: <6317D79D-550C-4D75-815D-4EF458FD4E82@sackheads.org>


On May 12, 2011, at 8:31 PM, Roy wrote:

> On 5/12/2011 4:03 PM, George Herbert wrote:
> > ....
> > Large end-user companies generally multihomed by that time, and you
> > generally did that by BGP4 at the time (post-1994), and before that
> > BGP3, and before that EGP, and before that... well, there was little
> > "commercial ISPness" other than NSFNet connectivity and the regional
> > networks back then so multihoming was somewhat of a moot point.
> >
> > Thank you again, UUNet/Alternet and PSI!
> >
> 
> The management of the large end-user company I worked for could barely spell Internet at the beginning of 1995.  A few connections to the Internet existed and the lab where I worked was experimenting with a socks-server.  There was a large intranet allocated from the company's class A space.

But it wasn't long before SOCKS (and proxy in non-US) servers were deployed throughout the entire company, connected behind an ISP owned and operated by that company.  The connectivity was typically static routing to/from the POP in the same building IIRC. 




From euming at comcast.net  Fri May 20 13:46:45 2011
From: euming at comcast.net (Eu-Ming Lee)
Date: Fri, 20 May 2011 18:46:45 +0000 (UTC)
Subject: Had an idea - looking for a math buff to tell me if it's
	=?utf-8?b?cG9zc2libGUJd2l0aA==?= today's technology.
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <loom.20110520T203349-844@post.gmane.org>

To do this, you only need 2 numbers: the nth digit of pi and the number of 
digits.

Simply convert your message into a single extremely long integer. Somewhere, 
in the digits of pi, you will find a matching series of digits the same as 
your integer!

Decompressing the number is relatively easy after some sort-of recent 
advances in our understanding of pi.

Finding out what those 2 numbers are--- well, we still have a ways to go 
on that.


Despite the ridiculousness of this example, it does illustrate to the 
author that there are extremes of compression. The "single mathematical 
formula" compression method is possible, even trivial. However, the 
computation time for compression may be unreasonably large.

Here is another ridiculous way to compress data: Convert your data 
into a series 

of coordinates to a mandelbrot fractal set. The final picture is a 
fixed size, regardless of the size of your starting data set. From that 
final picture, you should be able to retrieve your original starting 
data set.

Good luck!





From rbf+nanog at panix.com  Fri May 20 13:53:27 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Fri, 20 May 2011 13:53:27 -0500
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <loom.20110520T203349-844@post.gmane.org>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>
Message-ID: <20110520185326.GA10716@panix.com>

On Fri, May 20, 2011 at 06:46:45PM +0000, Eu-Ming Lee wrote:
> To do this, you only need 2 numbers: the nth digit of pi and the number of 
> digits.
> 
> Simply convert your message into a single extremely long integer. Somewhere, 
> in the digits of pi, you will find a matching series of digits the same as 
> your integer!
> 
> Decompressing the number is relatively easy after some sort-of recent 
> advances in our understanding of pi.
> 
> Finding out what those 2 numbers are--- well, we still have a ways to go 
> on that.

Even if those problems were solved, you'd need (on average) just as
many bits to represent which digit of pi to start with as you'd need to
represent the original message.

     -- Brett



From cscora at apnic.net  Fri May 20 13:59:34 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 21 May 2011 04:59:34 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201105201859.p4KIxYLj031627@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfs at cisco.com>.

Routing Table Report   04:00 +10GMT Sat 21 May, 2011

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              357743
    Prefixes after maximum aggregation:                          161995
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     176757
Total ASes present in the Internet Routing Table:                 37632
    Prefixes per ASN:                                              9.51
Origin-only ASes present in the Internet Routing Table:           31443
Origin ASes announcing only one prefix:                           15107
Transit ASes present in the Internet Routing Table:                5101
Transit-only ASes present in the Internet Routing Table:            135
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               647
    Unregistered ASNs in the Routing Table:                         338
Number of 32-bit ASNs allocated by the RIRs:                       1366
Number of 32-bit ASNs visible in the Routing Table:                1088
Prefixes from 32-bit ASNs in the Routing Table:                    2459
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            166
Number of addresses announced to Internet:                   2432900032
    Equivalent to 145 /8s, 3 /16s and 27 /24s
    Percentage of available address space announced:               65.6
    Percentage of allocated address space announced:               65.6
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               90.9
Total number of prefixes smaller than registry allocations:      148733

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    89422
    Total APNIC prefixes after maximum aggregation:               30028
    APNIC Deaggregation factor:                                    2.98
Prefixes being announced from the APNIC address blocks:           85798
    Unique aggregates announced from the APNIC address blocks:    36687
APNIC Region origin ASes present in the Internet Routing Table:    4453
    APNIC Prefixes per ASN:                                       19.27
APNIC Region origin ASes announcing only one prefix:               1236
APNIC Region transit ASes present in the Internet Routing Table:    707
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         21
Number of APNIC region 32-bit ASNs visible in the Routing Table:     46
Number of APNIC addresses announced to Internet:              615312672
    Equivalent to 36 /8s, 172 /16s and 237 /24s
    Percentage of available APNIC address space announced:         78.0

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
                       55296-56319, 131072-132095
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    140448
    Total ARIN prefixes after maximum aggregation:                71554
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           112638
    Unique aggregates announced from the ARIN address blocks:     45620
ARIN Region origin ASes present in the Internet Routing Table:    14381
    ARIN Prefixes per ASN:                                         7.83
ARIN Region origin ASes announcing only one prefix:                5494
ARIN Region transit ASes present in the Internet Routing Table:    1498
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               801671424
    Equivalent to 47 /8s, 200 /16s and 137 /24s
    Percentage of available ARIN address space announced:          63.7

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     84534
    Total RIPE prefixes after maximum aggregation:                48247
    RIPE Deaggregation factor:                                     1.75
Prefixes being announced from the RIPE address blocks:            78018
    Unique aggregates announced from the RIPE address blocks:     51632
RIPE Region origin ASes present in the Internet Routing Table:    15619
    RIPE Prefixes per ASN:                                         5.00
RIPE Region origin ASes announcing only one prefix:                7813
RIPE Region transit ASes present in the Internet Routing Table:    2464
Average RIPE Region AS path length visible:                         4.6
    Max RIPE Region AS path length visible:                          36
Number of RIPE region 32-bit ASNs visible in the Routing Table:     805
Number of RIPE addresses announced to Internet:               472636160
    Equivalent to 28 /8s, 43 /16s and 219 /24s
    Percentage of available RIPE address space announced:          76.1

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   32829
    Total LACNIC prefixes after maximum aggregation:               7512
    LACNIC Deaggregation factor:                                   4.37
Prefixes being announced from the LACNIC address blocks:          31866
    Unique aggregates announced from the LACNIC address blocks:   16758
LACNIC Region origin ASes present in the Internet Routing Table:   1456
    LACNIC Prefixes per ASN:                                      21.89
LACNIC Region origin ASes announcing only one prefix:               431
LACNIC Region transit ASes present in the Internet Routing Table:   266
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   220
Number of LACNIC addresses announced to Internet:              83532288
    Equivalent to 4 /8s, 250 /16s and 154 /24s
    Percentage of available LACNIC address space announced:        55.3

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   7836
    Total AfriNIC prefixes after maximum aggregation:              1877
    AfriNIC Deaggregation factor:                                  4.17
Prefixes being announced from the AfriNIC address blocks:          6175
    Unique aggregates announced from the AfriNIC address blocks:   1909
AfriNIC Region origin ASes present in the Internet Routing Table:   448
    AfriNIC Prefixes per ASN:                                     13.78
AfriNIC Region origin ASes announcing only one prefix:              133
AfriNIC Region transit ASes present in the Internet Routing Table:  100
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             23174656
    Equivalent to 1 /8s, 97 /16s and 158 /24s
    Percentage of available AfriNIC address space announced:       34.5

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2457       9494         918   Korea Telecom (KIX)
17974     1832        516          32   PT TELEKOMUNIKASI INDONESIA
 7545     1556        301          87   TPG Internet Pty Ltd
 4755     1472        635         169   TATA Communications formerly 
24560     1153        336         184   Bharti Airtel Ltd., Telemedia
 7552     1123       1064           7   Vietel Corporation
 9583     1082         81         511   Sify Limited
 4808     1080       2141         298   CNCGROUP IP network: China169
 9829     1039        874          51   BSNL National Internet Backbo
18101      935        116         142   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3645       3822         255   bellsouth.net, inc. 
 4323     1976       1081         397   Time Warner Telecom
18566     1860        354         267   Covad Communications 
 1785     1786        681         123   PaeTec Communications, Inc.
 6478     1693        315          55   AT&T Worldnet Services 
20115     1538       1540         635   Charter Communications 
19262     1496       4943         300   Verizon Global Networks 
 7018     1365       7069         890   AT&T WorldNet Services
22773     1330       2897          88   Cox Communications, Inc.
11492     1279        240          15   Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6830      520       1780         321   UPC Distribution Services
34984      514        106         182   BILISIM TELEKOM
 3292      460       2062         395   TDC Tele Danmark
20940      457        134         351   Akamai Technologies European 
29049      453         33          44   AzerSat LLC.
 8866      444        134          26   Bulgarian Telecommunication C
12479      432        577           6   Uni2 Autonomous System
 3320      426       8153         371   Deutsche Telekom AG
 8551      406        355          45   Bezeq International
  702      395       1802         309   UUNET - Commercial IP service

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1481        273         154   TVCABLE BOGOTA 
 8151     1375       2702         362   UniNet S.A. de C.V. 
28573     1314        991          86   NET Servicos de Comunicao S.A
 7303      925        470         151   Telecom Argentina Stet-France
 6503      731        354          73   AVANTEL, S.A. 
14420      670         54          91   CORPORACION NACIONAL DE TELEC
22047      563        310          15   VTR PUNTO NET S.A. 
 3816      522        227         101   Empresa Nacional de Telecomun
13489      511        254         124   Orbitel S.A. E.S.P. 
11172      493         84          83   Servicios Alestra S.A de C.V 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452      894        445          11   TEDATA
24863      787        147          37   LINKdotNET AS number
15475      415         90           8   Nile Online
36992      287        331          17   Etisalat MISR
 3741      268        985         228   The Internet Solution 
 6713      241        215          13   Itissalat Al-MAGHRIB
33776      217         12          11   Starcomms Nigeria Limited
24835      208         78          10   RAYA Telecom - Egypt
29571      163         19          12   Ci Telecom Autonomous system 
16637      150        441          86   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3645       3822         255   bellsouth.net, inc. 
23456     2459        631        1341   32-bit ASN transition
 4766     2457       9494         918   Korea Telecom (KIX)
 4323     1976       1081         397   Time Warner Telecom
18566     1860        354         267   Covad Communications 
17974     1832        516          32   PT TELEKOMUNIKASI INDONESIA
 1785     1786        681         123   PaeTec Communications, Inc.
 6478     1693        315          55   AT&T Worldnet Services 
 7545     1556        301          87   TPG Internet Pty Ltd
20115     1538       1540         635   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
17974      1832        1800      PT TELEKOMUNIKASI INDONESIA
 1785      1786        1663      PaeTec Communications, Inc.
 6478      1693        1638      AT&T Worldnet Services 
18566      1860        1593      Covad Communications 
 4323      1976        1579      Time Warner Telecom
 4766      2457        1539      Korea Telecom (KIX)
 7545      1556        1469      TPG Internet Pty Ltd
10620      1481        1327      TVCABLE BOGOTA 
 4755      1472        1303      TATA Communications formerly 
11492      1279        1264      Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
27.0.128.0/17         7514     Media Exchange, Inc.
41.190.32.0/23       31856     CABSAS
41.190.34.0/23       31856     CABSAS
41.190.36.0/23       31856     CABSAS

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:20       /9:12      /10:28      /11:79      /12:226     
/13:461     /14:793     /15:1393    /16:11769   /17:5810    /18:9731    
/19:19329   /20:25643   /21:25885   /22:34217   /23:32989   /24:186103  
/25:1087    /26:1274    /27:713     /28:165     /29:8       /30:2       
/31:0       /32:6       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2245          3645      bellsouth.net, inc. 
18566     1824          1860      Covad Communications 
 6478     1647          1693      AT&T Worldnet Services 
10620     1371          1481      TVCABLE BOGOTA 
11492     1225          1279      Cable One 
23456     1204          2459      32-bit ASN transition
 7011     1060          1159      Citizens Utilities 
 1785     1051          1786      PaeTec Communications, Inc.
 4323      886          1976      Time Warner Telecom
22773      846          1330      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:279       2:39        4:14        5:1         6:3         8:352    
  12:1985     13:1        14:457      15:15       16:3        17:8      
  20:10       23:7        24:1633     27:753      31:345      32:60     
  33:4        34:2        37:1        38:738      40:101      41:2537   
  42:5        44:3        46:920      47:4        49:194      50:415    
  52:13       55:3        56:2        57:30       58:844      59:481    
  60:387      61:1235     62:960      63:1935     64:3941     65:2292   
  66:4158     67:1846     68:1092     69:2985     70:704      71:352    
  72:1883     73:1        74:2351     75:303      76:340      77:870    
  78:709      79:464      80:1094     81:821      82:490      83:447    
  84:629      85:1069     86:594      87:749      88:328      89:1556   
  90:204      91:3771     92:516      93:1053     94:1279     95:817    
  96:504      97:249      98:835      99:35      101:60      103:12     
 106:1       107:7       108:85      109:950     110:601     111:715    
 112:302     113:401     114:534     115:667     116:956     117:691    
 118:821     119:1145    120:308     121:677     122:1627    123:1001   
 124:1265    125:1228    128:262     129:176     130:164     131:573    
 132:109     133:19      134:218     135:48      136:215     137:143    
 138:305     139:112     140:487     141:239     142:402     143:402    
 144:481     145:54      146:444     147:209     148:589     149:243    
 150:172     151:186     152:306     153:178     154:3       155:396    
 156:194     157:352     158:135     159:387     160:317     161:207    
 162:279     163:163     164:501     165:354     166:516     167:433    
 168:729     169:152     170:794     171:77      172:1       173:1566   
 174:551     175:374     177:128     178:918     180:844     181:17     
 182:446     183:207     184:272     185:1       186:1164    187:735    
 188:842     189:897     190:4805    192:5790    193:4854    194:3482   
 195:2982    196:1210    197:19      198:3584    199:3908    200:5540   
 201:1486    202:8357    203:8427    204:4158    205:2326    206:2730   
 207:2913    208:3964    209:3462    210:2736    211:1392    212:1972   
 213:1734    214:735     215:71      216:4899    217:1623    218:563    
 219:362     220:1200    221:483     222:336     223:148    

End of report



From paul at paulgraydon.co.uk  Fri May 20 14:34:59 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Fri, 20 May 2011 09:34:59 -1000
Subject: Had an idea - looking for a math buff to tell me if
	it's	possible?with today's technology.
In-Reply-To: <20110520185326.GA10716@panix.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>	<loom.20110520T203349-844@post.gmane.org>
	<20110520185326.GA10716@panix.com>
Message-ID: <4DD6C263.6030808@paulgraydon.co.uk>

On 05/20/2011 08:53 AM, Brett Frankenberger wrote:
> On Fri, May 20, 2011 at 06:46:45PM +0000, Eu-Ming Lee wrote:
>> To do this, you only need 2 numbers: the nth digit of pi and the number of
>> digits.
>>
>> Simply convert your message into a single extremely long integer. Somewhere,
>> in the digits of pi, you will find a matching series of digits the same as
>> your integer!
>>
>> Decompressing the number is relatively easy after some sort-of recent
>> advances in our understanding of pi.
>>
>> Finding out what those 2 numbers are--- well, we still have a ways to go
>> on that.
> Even if those problems were solved, you'd need (on average) just as
> many bits to represent which digit of pi to start with as you'd need to
> represent the original message.
>
>       -- Brett
Not quite sure I follow that. "Start at position xyz, carry on for 10000 
bits" shouldn't be as long as telling it all 10000 bits?

Paul



From rbf+nanog at panix.com  Fri May 20 14:43:45 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Fri, 20 May 2011 14:43:45 -0500
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <4DD6C263.6030808@paulgraydon.co.uk>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>
	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk>
Message-ID: <20110520194345.GA23596@panix.com>

On Fri, May 20, 2011 at 09:34:59AM -1000, Paul Graydon wrote:
> On 05/20/2011 08:53 AM, Brett Frankenberger wrote:
> >On Fri, May 20, 2011 at 06:46:45PM +0000, Eu-Ming Lee wrote:
> >>To do this, you only need 2 numbers: the nth digit of pi and the number of
> >>digits.
> >>
> >>Simply convert your message into a single extremely long integer. Somewhere,
> >>in the digits of pi, you will find a matching series of digits the same as
> >>your integer!
> >>
> >>Decompressing the number is relatively easy after some sort-of recent
> >>advances in our understanding of pi.
> >>
> >>Finding out what those 2 numbers are--- well, we still have a ways to go
> >>on that.
> >Even if those problems were solved, you'd need (on average) just as
> >many bits to represent which digit of pi to start with as you'd need to
> >represent the original message.

> Not quite sure I follow that. "Start at position xyz, carry on for
> 10000 bits" shouldn't be as long as telling it all 10000 bits?

I don't know about "should", but it *will* be when "xyz" is greater
than 2^10000 (or about 10^3000).  Your intuition is probably telling
you that "xyz" won't likely be a 3000 digit (or longer) number, but if
so, your intuition is wrong.

     -- Brett



From ken at sizone.org  Fri May 20 14:44:26 2011
From: ken at sizone.org (Ken Chase)
Date: Fri, 20 May 2011 15:44:26 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <4DD6C263.6030808@paulgraydon.co.uk>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>
	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk>
Message-ID: <20110520194426.GJ4257@sizone.org>

On Fri, May 20, 2011 at 09:34:59AM -1000, Paul Graydon said:
> Not quite sure I follow that. "Start at position xyz, carry on for 10000  
> bits" shouldn't be as long as telling it all 10000 bits?

what position # do you think your exact 10000 bits will appear at?

(infact, mathies, whats the probability density function for
string of digits length N appearing in pi's digits per M digits?)

find M/N and there's your answer - might well be cheaper to
express the 10000 bits themselves, than a 100,000 bit long position #
in pi.

you cant exabyte-attack all possible integers, ya know.

/kc
-- 
Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.



From mikea at mikea.ath.cx  Fri May 20 14:48:18 2011
From: mikea at mikea.ath.cx (mikea)
Date: Fri, 20 May 2011 14:48:18 -0500
Subject: Had an idea - looking for a math buff to tell me if it's possible
	with today's technology.
In-Reply-To: <4DD6C263.6030808@paulgraydon.co.uk>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>
	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk>
Message-ID: <20110520194817.GE89304@mikea.ath.cx>

On Fri, May 20, 2011 at 09:34:59AM -1000, Paul Graydon wrote:
> On 05/20/2011 08:53 AM, Brett Frankenberger wrote:
> >On Fri, May 20, 2011 at 06:46:45PM +0000, Eu-Ming Lee wrote:
> >>To do this, you only need 2 numbers: the nth digit of pi and the number of
> >>digits.
> >>
> >>Simply convert your message into a single extremely long integer. 
> >>Somewhere,
> >>in the digits of pi, you will find a matching series of digits the same as
> >>your integer!
> >>
> >>Decompressing the number is relatively easy after some sort-of recent
> >>advances in our understanding of pi.
> >>
> >>Finding out what those 2 numbers are--- well, we still have a ways to go
> >>on that.
> >Even if those problems were solved, you'd need (on average) just as
> >many bits to represent which digit of pi to start with as you'd need to
> >represent the original message.
> >
> >      -- Brett
> Not quite sure I follow that. "Start at position xyz, carry on for 10000 
> bits" shouldn't be as long as telling it all 10000 bits?

This depends strongly on the size of the number expressing "position xyz".
Pi is infinitely long, so there is no guarantee that for some random string
which can be found starting at "position xyz" in, say, the binary, decimal,
or hexadecimal expansion of pi, xyz can be expressed in fewer than 10000
(or indeed any fixed number N) bits.

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin 



From Valdis.Kletnieks at vt.edu  Fri May 20 14:48:52 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 20 May 2011 15:48:52 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: Your message of "Fri, 20 May 2011 09:34:59 -1000."
	<4DD6C263.6030808@paulgraydon.co.uk>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>
	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk>
Message-ID: <21186.1305920932@localhost>

On Fri, 20 May 2011 09:34:59 -1000, Paul Graydon said:

> Not quite sure I follow that. "Start at position xyz, carry on for 10000 
> bits" shouldn't be as long as telling it all 10000 bits?

The problem is that the length of 'xyz' will probably be on the same order of
magnitude as the length of your message - if it's only 2-3 digits long, you'll
probably find a matching location in the first 100 or so digits.  But if you
need a run that's an exact match for an entire 20K email, you're going to have
to go down a long ways to find a match. (protip - compressing the email text
first is a big win here)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110520/294045e5/attachment.bin>

From andrew at andrewcruse.com  Fri May 20 14:57:30 2011
From: andrew at andrewcruse.com (Andrew Cruse)
Date: Fri, 20 May 2011 15:57:30 -0400
Subject: Huawei Symantec Anti-DDOS
Message-ID: <BANLkTimyc1pf7ZChaGqc50JiK5mN6Cn7yA@mail.gmail.com>

Anyone demoed or worked with this in production?

http://bit.ly/lq6eTY

Thoughts on how it stacks up with the usual suspects -- Arbor, etc?  Worth
looking into?

Thanks,

Andrew


From paul at telcodata.us  Fri May 20 15:32:00 2011
From: paul at telcodata.us (Paul Timmins)
Date: Fri, 20 May 2011 16:32:00 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <4DD6C263.6030808@paulgraydon.co.uk>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>	<loom.20110520T203349-844@post.gmane.org>	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk>
Message-ID: <4DD6CFC0.3010802@telcodata.us>

On 05/20/2011 03:34 PM, Paul Graydon wrote:
> On 05/20/2011 08:53 AM, Brett Frankenberger wrote:
>> Even if those problems were solved, you'd need (on average) just as
>> many bits to represent which digit of pi to start with as you'd need to
>> represent the original message.
>>
>>       -- Brett
> Not quite sure I follow that. "Start at position xyz, carry on for 
> 10000 bits" shouldn't be as long as telling it all 10000 bits?

Currently we have a compression algorithm for doing this already in 
widespread use. We create a list of numbers ranging from 1 to 255 and 
then provide an index into that array. We save space by assuming it's a 
single character.



From skhuraijam at liveops.com  Fri May 20 16:16:25 2011
From: skhuraijam at liveops.com (Sudeep Khuraijam)
Date: Fri, 20 May 2011 14:16:25 -0700
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <4DD6CFC0.3010802@telcodata.us>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk> <4DD6CFC0.3010802@telcodata.us>
Message-ID: <8A2C0949-6815-49C1-B760-BBF931E9EDA9@liveops.com>

I could not help but admire nanog in its full form ;)  and I cannot resist anymore.  Allow me to suggest the EPR paradox machine.

The cost of regenerating  unpredictable information is inefficient  by orders of magnitude, but wait... isn't it what we are trying to solve?

On May 20, 2011, at 1:32 PM, Paul Timmins wrote:

On 05/20/2011 03:34 PM, Paul Graydon wrote:
On 05/20/2011 08:53 AM, Brett Frankenberger wrote:
Even if those problems were solved, you'd need (on average) just as
many bits to represent which digit of pi to start with as you'd need to
represent the original message.

     -- Brett
Not quite sure I follow that. "Start at position xyz, carry on for
10000 bits" shouldn't be as long as telling it all 10000 bits?

Currently we have a compression algorithm for doing this already in
widespread use. We create a list of numbers ranging from 1 to 255 and
then provide an index into that array. We save space by assuming it's a
single character.


____________________________________________
Sudeep Khuraijam | Netops | liveops | Office 408 8442511 | Mobile 408 666 9987
skhuraijam at liveops.com<mailto:skhuraijam at liveops.com> | aim: skhuraijam










From cidr-report at potaroo.net  Fri May 20 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 20 May 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201105202200.p4KM00XX065953@wattle.apnic.net>

BGP Update Report
Interval: 12-May-11 -to- 19-May-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            43670  3.4%      63.8 -- BSNL-NIB National Internet Backbone
 2 - AS17974           36301  2.8%      21.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 3 - AS19743           31933  2.5%    5322.2 -- 
 4 - AS11492           27640  2.1%      27.7 -- CABLEONE - CABLE ONE, INC.
 5 - AS14420           23093  1.8%      34.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
 6 - AS32528           17146  1.3%    4286.5 -- ABBOTT Abbot Labs
 7 - AS44609           13732  1.1%    4577.3 -- FNA Fars News Agency Cultural Arts Institute
 8 - AS14522           13539  1.0%      30.8 -- Satnet
 9 - AS45595           10585  0.8%      40.1 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited
10 - AS9498            10005  0.8%      14.8 -- BBIL-AP BHARTI Airtel Ltd.
11 - AS33776            8806  0.7%      80.8 -- STARCOMMS-ASN
12 - AS25543            8678  0.7%     241.1 -- FasoNet-AS
13 - AS24560            8666  0.7%       7.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
14 - AS3454             8618  0.7%    1436.3 -- Universidad Autonoma de Nuevo Leon
15 - AS33475            8588  0.7%      49.4 -- RSN-1 - RockSolid Network, Inc.
16 - AS8151             8406  0.7%       8.5 -- Uninet S.A. de C.V.
17 - AS8402             7599  0.6%      13.1 -- CORBINA-AS Corbina Telecom
18 - AS23966            6636  0.5%      19.9 -- LDN-AS-PK LINKdotNET Telecom Limited
19 - AS12880            6605  0.5%      62.3 -- DCI-AS DCI Autonomous System
20 - AS28573            6209  0.5%       5.5 -- NET Servicos de Comunicao S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19743           31933  2.5%    5322.2 -- 
 2 - AS44609           13732  1.1%    4577.3 -- FNA Fars News Agency Cultural Arts Institute
 3 - AS32528           17146  1.3%    4286.5 -- ABBOTT Abbot Labs
 4 - AS17408            3473  0.3%    3473.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 5 - AS45723            2757  0.2%    2757.0 -- OMADATA-AS-ID Omadata Indonesia, PT
 6 - AS35931            4728  0.4%    1576.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
 7 - AS49367            1573  0.1%    1573.0 -- ASSEFLOW Seflow S.N.C. Di Marco Brame' & C.
 8 - AS3454             8618  0.7%    1436.3 -- Universidad Autonoma de Nuevo Leon
 9 - AS49600            1190  0.1%    1190.0 -- LASEDA La Seda de Barcelona, S.A
10 - AS48640            1068  0.1%    1068.0 -- MAZ-AS MAZ Mutua de Accidentes de Trabajo y Enfermedades
11 - AS27771            1982  0.1%     991.0 -- Instituto Venezolano de Investigaciones Cientificas
12 - AS38388            2486  0.2%     828.7 -- BEN-AS-KR Bukbu District Office of Education in Seoul
13 - AS44967            4603  0.3%     657.6 -- TASIO Tasio Ltd
14 - AS38004             554  0.0%     554.0 -- FASTLINK-ISP FastLink Wireless ISP, DrukCom Pvt. Enterprise.
15 - AS3                 530  0.0%     735.0 -- PARTNERTELEKOM-AS PARTNER TELEKOM Jacek Kwiatkowski, Leszek Kuszka SP.J.
16 - AS21271             494  0.0%     494.0 -- SOTELMABGP
17 - AS34043             494  0.0%     494.0 -- RISS Internet Security Systems SRL
18 - AS50461            1453  0.1%     484.3 -- ALMADINAH-AS Almadinah Ltd
19 - AS33076             391  0.0%     391.0 -- ISC-TGD1 Internet Systems Consortium, Inc.
20 - AS44584            1508  0.1%     377.0 -- PTLINE-AS Progress Tehnologiya LLC


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 200.23.202.0/24    8613  0.6%   AS3454  -- Universidad Autonoma de Nuevo Leon
 2 - 130.36.35.0/24     8572  0.6%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.34.0/24     8570  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 202.92.235.0/24    8471  0.6%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 5 - 178.22.72.0/21     7049  0.5%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
 6 - 178.22.79.0/24     6679  0.5%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
 7 - 65.122.196.0/24    6220  0.5%   AS19743 -- 
 8 - 72.164.144.0/24    5147  0.4%   AS19743 -- 
 9 - 66.238.91.0/24     5142  0.4%   AS19743 -- 
10 - 66.89.98.0/24      5142  0.4%   AS19743 -- 
11 - 65.162.204.0/24    5141  0.4%   AS19743 -- 
12 - 65.163.182.0/24    5141  0.4%   AS19743 -- 
13 - 221.121.96.0/19    4035  0.3%   AS7491  -- PI-PH-AS-AP PI-PHILIPINES
14 - 202.153.174.0/24   3473  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
15 - 202.1.236.0/24     2757  0.2%   AS45723 -- OMADATA-AS-ID Omadata Indonesia, PT
16 - 63.211.68.0/22     2744  0.2%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
17 - 190.15.21.128/26   2569  0.2%   AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA
18 - 204.245.102.0/24   2557  0.2%   AS19262 -- VZGNI-TRANSIT - Verizon Online LLC
19 - 198.140.43.0/24    1876  0.1%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC
20 - 65.181.192.0/23    1752  0.1%   AS11492 -- CABLEONE - CABLE ONE, INC.

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From cidr-report at potaroo.net  Fri May 20 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 20 May 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201105202200.p4KM00lF065948@wattle.apnic.net>

This report has been generated at Fri May 20 21:12:21 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        13-05-11    360084      211757
        14-05-11    359950      211872
        15-05-11    360334      212313
        16-05-11    360575      212286
        17-05-11    360513      212137
        18-05-11    360752      211911
        19-05-11    360924      212120
        20-05-11    360980      212321


AS Summary
         37725  Number of ASes in routing system
         15882  Number of ASes announcing only one prefix
          3644  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      110385408  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 20May11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     361233   212306   148927    41.2%   All ASes

AS6389      3644      260     3384    92.9%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4323      1977      399     1578    79.8%   TWTC - tw telecom holdings,
                                               inc.
AS4766      2457      929     1528    62.2%   KIXS-AS-KR Korea Telecom
AS6478      1693      283     1410    83.3%   ATT-INTERNET3 - AT&T Services,
                                               Inc.
AS22773     1330       97     1233    92.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS19262     1496      300     1196    79.9%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS18566     1860      717     1143    61.5%   COVAD - Covad Communications
                                               Co.
AS4755      1474      371     1103    74.8%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1789      760     1029    57.5%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1139      129     1010    88.7%   VIETEL-AS-AP Vietel
                                               Corporation
AS28573     1314      310     1004    76.4%   NET Servicos de Comunicao S.A.
AS10620     1481      491      990    66.8%   Telmex Colombia S.A.
AS18101      935      147      788    84.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS7545      1556      791      765    49.2%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS4808      1084      333      751    69.3%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1376      646      730    53.1%   Uninet S.A. de C.V.
AS3356      1116      454      662    59.3%   LEVEL3 Level 3 Communications
AS11492     1280      652      628    49.1%   CABLEONE - CABLE ONE, INC.
AS17488      928      305      623    67.1%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS17676      665       70      595    89.5%   GIGAINFRA Softbank BB Corp.
AS7303       922      334      588    63.8%   Telecom Argentina S.A.
AS24560     1153      571      582    50.5%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS14420      670       92      578    86.3%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS22561      917      358      559    61.0%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS3549       950      395      555    58.4%   GBLX Global Crossing Ltd.
AS4780       751      200      551    73.4%   SEEDNET Digital United Inc.
AS22047      563       30      533    94.7%   VTR BANDA ANCHA S.A.
AS855        637      108      529    83.0%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS17974     1829     1317      512    28.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       586       87      499    85.2%   MPX-AS Microplex PTY LTD

Total      39572    11936    27636    69.8%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        24.48.0.0/14         AS5769  VIDEOTRON - Videotron Telecom Ltee
        24.225.128.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/23      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.224.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.237.0/24      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.248.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        27.0.128.0/17        AS7514  MEX Media EXchange, Inc.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        45.127.0.0/16        AS13767 DBANK - DataBank Holdings, Ltd.
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS16626 GNAXNET-AS - Global Net Access, LLC
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        69.6.81.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.22.32.0/19        AS33150 
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        80.88.12.0/24        AS33779 wataniya-telecom-as
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        115.42.28.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.40.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.42.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.44.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.47.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.48.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.49.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.50.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.51.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.52.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.53.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.54.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.55.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.56.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.57.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.58.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.59.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.61.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.62.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.63.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        158.222.70.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.72.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.224.0/20     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.224.0/22     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.229.0/24     AS19864 O1COMM - O1 COMMUNICATIONS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc
        192.64.85.0/24       AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.69.108.0/24      AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.101.46.0/24      AS6503  Axtel, S.A.B. de C.V.
        192.101.64.0/21      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.72.0/24      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.124.252.0/22     AS680   DFN-IP service G-WiN
        192.131.233.0/24     AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        192.145.251.0/24     AS10026 PACNET Pacnet Global Ltd
        192.154.32.0/19      AS81    NCREN - MCNC
        192.154.64.0/19      AS81    NCREN - MCNC
        192.169.15.0/24      AS17444 NWT-AS-AP AS number for New World Telephone Ltd.
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        196.2.224.0/22       AS24863 LINKdotNET-AS
        196.6.108.0/24       AS5713  SAIX-NET
        196.13.201.0/24      AS2018  TENET-1
        196.13.202.0/24      AS2018  TENET-1
        196.13.203.0/24      AS2018  TENET-1
        196.13.204.0/24      AS2018  TENET-1
        196.110.105.0/24     AS8513  SKYVISION SkyVision Network Services
        196.202.224.0/21     AS8818  TELE Greenland Autonomous System
        198.1.2.0/24         AS4761  INDOSAT-INP-AP INDOSAT Internet Network Provider
        198.15.4.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.15.5.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.
        198.73.210.0/24      AS21570 ACI-1 - Accelerated Connections Inc.
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.99.241.0/24      AS11797 AC-NIELSEN-AS AC NIELSEN
        198.161.87.0/24      AS6539  GT-BELL - Bell Canada
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited
        198.167.0.0/16       AS7456  INTERHOP - Interhop Network SERVICES Inc.
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        198.175.231.0/24     AS19262 VZGNI-TRANSIT - Verizon Online LLC
        198.180.198.0/24     AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services
        198.182.235.0/24     AS3356  LEVEL3 Level 3 Communications
        199.16.32.0/19       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        199.33.84.0/22       AS9911  CONNECTPLUS-AP Singapore Telecom
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.185.130.0/23     AS19662 UNISERVE-ONLINE - Uniserve On Line
        199.202.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        199.202.216.0/21     AS577   BACOM - Bell Canada
        199.246.116.0/24     AS813   UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.133.73.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.146.186.0/24     AS23655 SNAP-NZ-AS Snap Internet Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.160.158.0/23     AS2764  AAPT AAPT Limited
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        203.18.156.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        203.190.32.0/22      AS24564 
        204.9.216.0/23       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        204.10.232.0/21      AS33150 
        204.19.14.0/23       AS577   BACOM - Bell Canada
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.189.134.0/24     AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.188.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.189.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.190.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.191.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.78.165.0/24      AS16565 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.92.196.0/22      AS10929 NETELLIGENT - Netelligent Hosting Services Inc.
        208.92.199.0/24      AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc.
        209.54.123.0/24      AS6062  NETPLEX - NETPLEX
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.165.239.0/24     AS209   ASN-QWEST - Qwest Communications Company, LLC
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.5.128.0/20       AS4837  CHINA169-BACKBONE CNCGROUP China169 Backbone
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.10.235.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.10.236.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.21.196.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.201.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.202.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.206.0/23      AS12251 INVISION - Invision.com, Inc.
        216.58.192.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.197.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.172.198.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.172.199.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From dougb at dougbarton.us  Fri May 20 17:13:34 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 20 May 2011 15:13:34 -0700
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <20110520194426.GJ4257@sizone.org>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>	<loom.20110520T203349-844@post.gmane.org>	<20110520185326.GA10716@panix.com>	<4DD6C263.6030808@paulgraydon.co.uk>
	<20110520194426.GJ4257@sizone.org>
Message-ID: <4DD6E78E.8000502@dougbarton.us>

On 5/20/2011 12:44 PM, Ken Chase wrote:
> On Fri, May 20, 2011 at 09:34:59AM -1000, Paul Graydon said:
>> Not quite sure I follow that. "Start at position xyz, carry on for 10000
>> bits" shouldn't be as long as telling it all 10000 bits?
>
> what position # do you think your exact 10000 bits will appear at?
>
> (infact, mathies, whats the probability density function for
> string of digits length N appearing in pi's digits per M digits?)
>
> find M/N and there's your answer - might well be cheaper to
> express the 10000 bits themselves, than a 100,000 bit long position #
> in pi.

Blah. I seriously hate extending this silliness but I can't resist 
pointing out something that might be useful to someone to solve a real 
problem someday.

Who in their right mind would represent a string of 10**3000 numbers as 
the full string in what's supposed to be a compression algorithm? And 
yes, I'm pretty sure I just suggested the proper solution, as did the 
reference to a 255 bit array, but just in case ...

Assume that your string starts at precisely digit number 18,000,000. 
Advance to position 2**24, advance 1,222,784 digits further, begin 
recording. Obviously better/more interesting models could be developed 
by someone who actually cared. :)


Doug (you're welcome)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/




From joe at gonetforward.com  Fri May 20 18:22:45 2011
From: joe at gonetforward.com (Joe Renwick)
Date: Fri, 20 May 2011 16:22:45 -0700
Subject: Need the perspective of a Level3 customer.
In-Reply-To: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
References: <BANLkTim3TKgNe4puFzjr5G7o5boY4g9BuQ@mail.gmail.com>
Message-ID: <BANLkTikHQrKn8tNVMrWj95oyruf2afZ4tA@mail.gmail.com>

Thanks for all who assisted me on this issue.  Was invaluable to get router
output from all over the country.

Bottom line Level3 had some issues with poking a whole in there
summarization filters.  Appeared that the problem was only with peers
connected to the HSA1 and HSA2 routers in San Diego.  That is where our
routers are located so looks like a local issue.  I did not get a clear
answer for them on the root cause but from what I understand they updated
their summarization policy but did not clear the BGP sessions.  Not sure if
anyone else has run into this in the past with Level3.  I have worked with
them a couple times previously doing the same thing and had no issue.

Cheers,

Joe

On Fri, May 13, 2011 at 1:39 AM, Joe Renwick <joe at gonetforward.com> wrote:

> Can anyone peering with Level3 directly tell me if they are seeing
> 63.210.162.0/24 coming from the Level3 peer?
>
> Thanks for the help.
>
> Cheers,
>
> --
> Joe Renwick
> IP Network Consultant, CCIE #16465
> GO NETFORWARD!
> Direct: 619-800-2055, Emergency Support: 800-719-0504
> Is your network moving you forward?
>
>
>


-- 
Joe Renwick
IP Network Consultant, CCIE #16465
GO NETFORWARD!
Direct: 619-800-2055, Emergency Support: 800-719-0504
Is your network moving you forward?


From deric.kwok2000 at gmail.com  Sat May 21 08:37:37 2011
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Sat, 21 May 2011 09:37:37 -0400
Subject: rwhois website
Message-ID: <BANLkTinOu2gGEuqNsUJJAk+DA95YesV4Lw@mail.gmail.com>

Hi all

I am trying to use http://www.rwhois.net/rwhois/prwhois.html  to check
my rwhois server

but it is not reachable now

Do you know why the websie is not in existing?

and how can i check it

Thank you



From jeroen at unfix.org  Sat May 21 08:49:13 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Sat, 21 May 2011 15:49:13 +0200
Subject: rwhois website
In-Reply-To: <BANLkTinOu2gGEuqNsUJJAk+DA95YesV4Lw@mail.gmail.com>
References: <BANLkTinOu2gGEuqNsUJJAk+DA95YesV4Lw@mail.gmail.com>
Message-ID: <4DD7C2D9.2010309@unfix.org>

On 2011-May-21 15:37, Deric Kwok wrote:
> Hi all
> 
> I am trying to use http://www.rwhois.net/rwhois/prwhois.html  to check
> my rwhois server
> 
> but it is not reachable now

DNS is broken it seems.

> Do you know why the websie is not in existing?
> 
> and how can i check it

google(rwhois) for me 2nd hit gave:

http://projects.arin.net/rwhois/prwhois.html

Which is probably what you want.

Greets,
 Jeroen



From sthaug at nethelp.no  Sat May 21 08:54:44 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sat, 21 May 2011 15:54:44 +0200 (CEST)
Subject: rwhois website
In-Reply-To: <BANLkTinOu2gGEuqNsUJJAk+DA95YesV4Lw@mail.gmail.com>
References: <BANLkTinOu2gGEuqNsUJJAk+DA95YesV4Lw@mail.gmail.com>
Message-ID: <20110521.155444.41666060.sthaug@nethelp.no>

> I am trying to use http://www.rwhois.net/rwhois/prwhois.html  to check
> my rwhois server
> 
> but it is not reachable now
> 
> Do you know why the websie is not in existing?
> 
> and how can i check it

As somebody else answered on Nanog a couple of weeks ago,

"rwhoisd is very old software that has had no development attention
for many, many years."

The DNS info for rwhois.net is seriously screwed (NS info points to
ns{1,2}.verisignlabs.com - which don't exist according to the servers
for verisignlabs.com).

Why do you waste your time on rwhois?

Steinar Haug, Nethelp consulting, sthaug at nethelp.no



From tme at americafree.tv  Sat May 21 10:50:53 2011
From: tme at americafree.tv (Marshall Eubanks)
Date: Sat, 21 May 2011 11:50:53 -0400
Subject: Had an idea - looking for a math buff to tell me if it's
	possible?with today's technology.
In-Reply-To: <8A2C0949-6815-49C1-B760-BBF931E9EDA9@liveops.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
	<loom.20110520T203349-844@post.gmane.org>	<20110520185326.GA10716@panix.com>
	<4DD6C263.6030808@paulgraydon.co.uk>
	<4DD6CFC0.3010802@telcodata.us>
	<8A2C0949-6815-49C1-B760-BBF931E9EDA9@liveops.com>
Message-ID: <D692BC74-026B-4198-870A-F7961EA61901@americafree.tv>


On May 20, 2011, at 5:16 PM, Sudeep Khuraijam wrote:

> I could not help but admire nanog in its full form ;)  and I cannot resist anymore.  Allow me to suggest the EPR paradox machine.
> 
> The cost of regenerating  unpredictable information is inefficient  by orders of magnitude, but wait... isn't it what we are trying to solve?
> 
> On May 20, 2011, at 1:32 PM, Paul Timmins wrote:
> 
> On 05/20/2011 03:34 PM, Paul Graydon wrote:
> On 05/20/2011 08:53 AM, Brett Frankenberger wrote:
> Even if those problems were solved, you'd need (on average) just as
> many bits to represent which digit of pi to start with as you'd need to
> represent the original message.
> 
>    -- Brett
> Not quite sure I follow that. "Start at position xyz, carry on for
> 10000 bits" shouldn't be as long as telling it all 10000 bits?

Yes, it will be as long or longer (on average), because you have to represent position XYZ in some fashion, 
and send that representation to the decoder, and it can easily be longer than the original message. Suppose that it takes 20,000 bits to
represent XYZ. How have you saved bits ? Having XYZ be longer than the original message is just as likely as having it be shorter. 

The same problem applies to the original suggestion. You will not (on average) save bits. 

If typical messages are not totally random, you can compress by considering the nature of that non-randomness, and tailoring your compression accordingly. These schemes are using random strings / hashes                                                                                                                                                                                                                        for their compression, and thus will (on average) not save
bits even if a message is highly non-random.

Regards
Marshall

> 
> Currently we have a compression algorithm for doing this already in
> widespread use. We create a list of numbers ranging from 1 to 255 and
> then provide an index into that array. We save space by assuming it's a
> single character.
> 
> 
> ____________________________________________
> Sudeep Khuraijam | Netops | liveops | Office 408 8442511 | Mobile 408 666 9987
> skhuraijam at liveops.com<mailto:skhuraijam at liveops.com> | aim: skhuraijam
> 
> 
> 
> 
> 
> 
> 
> 
> 




From zaid at zaidali.com  Sat May 21 11:46:45 2011
From: zaid at zaidali.com (Zaid Ali)
Date: Sat, 21 May 2011 09:46:45 -0700
Subject: Edgecast?
Message-ID: <100F7694-9DFE-4272-A013-CB52354DE859@zaidali.com>

Anyone from edgecast here? I am seeing peering issues to a particular CDN. Please contact me offline.

Zaid


From scubacuda at gmail.com  Sat May 21 17:34:43 2011
From: scubacuda at gmail.com (Rogelio)
Date: Sat, 21 May 2011 19:34:43 -0300
Subject: blocking unwanted traffic from hitting gateway
In-Reply-To: <D214904E-ACDA-4B77-8394-5CC5B803ACA3@bsdboy.com>
References: <BANLkTikPQkcFNuajh3csxXyOkxNeHa_A3A@mail.gmail.com>
	<D214904E-ACDA-4B77-8394-5CC5B803ACA3@bsdboy.com>
Message-ID: <BANLkTinDETr-cWQNi3rxabq+9Wk8-kLV1A@mail.gmail.com>

For what it's worth, here are some things I did to cut down on
broadcast traffic until I figure out the other pieces

--Putting router in between subscribers and gateway (handles thousands
of ARP requests every minute much better than Linux)
--DCHP relay on one of the northbound interface of the new router
(which points towards subscriber gateway)
--DHCP unicast settings on the CPE devices

Seems to have helped a lot, which leads me to believe it is much more
related to broadcast than I previously thought.



From greg at bestnet.kharkov.ua  Mon May 23 02:46:54 2011
From: greg at bestnet.kharkov.ua (Gregory Edigarov)
Date: Mon, 23 May 2011 10:46:54 +0300
Subject: Had an idea - looking for a math buff to tell me if it's
	possible with today's technology.
In-Reply-To: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
References: <BANLkTimJ==S62Z=RbL+nciPwk-m5RVUWPQ@mail.gmail.com>
Message-ID: <20110523104654.6259b72a@greg.bestnet.kharkov.ua>

On Wed, 18 May 2011 13:07:32 -0700
Landon Stewart <lstewart at superb.net> wrote:

> Lets say you had a file that was 1,000,000,000 characters consisting
> of 8,000,000,000bits.  What if instead of transferring that file
> through the interwebs you transmitted a mathematical equation to tell
> a computer on the other end how to *construct* that file.  First
> you'd feed the file into a cruncher of some type to reduce the
> pattern of 8,000,000,000 bits into an equation somehow.  Sure this
> would take time, I realize that.  The equation would then be
> transmitted to the other computer where it would use its
> mad-math-skillz to *figure out the answer* which would theoretically
> be the same pattern of bits.  Thus the same file would emerge on the
> other end.
> 
> The real question here is how long would it take for a regular
> computer to do this kind of math?
> 
> Just a weird idea I had.  If it's a good idea then please consider
> this intellectual property.  LOL

42 :-)



From shtsuchi at cisco.com  Mon May 23 04:46:25 2011
From: shtsuchi at cisco.com (Shishio Tsuchiya)
Date: Mon, 23 May 2011 18:46:25 +0900
Subject: Fwd: Service Provider Route Flap Damping Deployment Status Survey
Message-ID: <4DDA2CF1.40100@cisco.com>

Dear NANOG
Thanks for a lot of answer and comments to the survey.
We will close this survey in 25th May 17:30 of the UTC time. 
If you could answer the survey,could you open url.

 https://www.surveymonkey.com/s/rfd-survey

We will update our draft,and let you know.

Regards,
-Shishio
-------- Original Message --------
Subject: Service Provider Route Flap Damping Deployment Status Survey
Date: Fri, 18 Mar 2011 01:56:35 +0900
From: Shishio Tsuchiya <shtsuchi at cisco.com>
To: nanog at nanog.org
CC: shtsuchi at cisco.com, kawamucho at mesh.ad.jp, randy at psg.com,  cristel at iij.ad.jp

Dear NANOG,
I'm Shishio,Cisco Systems Japan.
I,Seiichi and Randy did presentation about "BGP topic" on JANOG27 which held 20th & 21st January 2011 in Kanazawa.
http://www.janog.gr.jp/en/index.php?JANOG27%20Programs#qe7ec71d
Randy explained "Route Flap Damping Considered Useable".
http://ripe61.ripe.net/presentations/222-101117.ripe-rfd.pdf
This report explains how to improve today's harmful RFD.
We heard various opinion from bgp operators about RFD.
So we took survey about "Service Provider Route Flap Damping Deployment Status" on janog at janog.gr.jp.
We would like to hear more opinions to analyze current RFD operation,problem and so on.

Could you please open the following url and answer the questionaire?
 https://www.surveymonkey.com/s/rfd-survey

The JAPAN result summary is below.
-----------------------------------
Q1.Do you use Route Flap Damping ?
Yes: 5  No: 13

Q2.If you select No on Q1,why?
Do not have the need: 3
Did not know about the feature: 2
No benefits expected: 3
Customers would complain:1
Because I read RIPE-378 :2
Other: 3

Q3.If you select Yes on Q1,what parameter do you use?
Default parameters: 3
RIPE-178 : 0
RIPE-210 : 0
RIPE-229 : 0
Other: 3

Q4.Do you know Randy Bush et. al's report ''Route Flap Damping Considered Usable?''
Yes: 12 No: 7

Q5.IOS's max-penalty is currently limited to 20K. Do you need this limitation to be relaxed to over 50K?
Yes: 10 No: 9

Q6.If you have any comments, please fill this box.
   -Our peer seems to have damping enabled, and our prefix gets damped sometimes.
   -We do not enable damping because we think that customers want a non-damped route.
   -From the perspective of a downstream ISP, if our upstream told us 
   that an outage occurred because a route was damped, I may call and
   ask "is it written in the agreement that you will do this?"
   -We use damping pretty heavily
   -I had RFD turned on until this morning when I discovered our router
   has CSCtd26215 issues.  I would like to turn on a "useful" RFD.
-----------------------------------

other reference:
https://tools.ietf.org/html/draft-shishio-grow-isp-rfd-implement-survey-01
https://tools.ietf.org/html/draft-ymbk-rfd-usable-00

Best Regards,





From mch-nanog at xs4all.nl  Mon May 23 07:10:56 2011
From: mch-nanog at xs4all.nl (Marco Hogewoning)
Date: Mon, 23 May 2011 14:10:56 +0200
Subject: IPv6 CPE Survey - Initial Results on RIPE Labs 
Message-ID: <F67DF23B-2F44-42B2-92E7-3C144CD47B87@xs4all.nl>

[apologies for duplicates]

Dear colleagues,

Since we published the IPv6 customer premise equipment (CPE) survey during the RIPE 62 meeting, we received more than 100 responses.

This new article on RIPE Labs shows some interesting initial results:

http://labs.ripe.net/Members/marco/ipv6-cpe-survey-results-may-2011

The survey is still open. If you are using an IPv6 capable CPE and have not yet filled in the survey, we would like to encourage you to do so. The survey can be found here:

http://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate

Kind Regards,
Marco Hogewoning & Mirjam Kuehne
RIPE NCC


From mksmith at adhost.com  Mon May 23 09:40:59 2011
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 23 May 2011 14:40:59 +0000
Subject: NANOG 52 - Room block filling up!
Message-ID: <D8CD26287252844898B508C40824D8F43C438F@AD-EXH02.adhost.lan>

Hello All:

NANOG 52 in Denver is fast approaching.  If you're planning on attending and want to get the benefits of the NANOG room rate, you should consider signing up as soon as possible.  We're at 85% of our room block capacity and the cutoff date for the NANOG rate is May 29th at 5:00 PM Denver time (GMT -6).  For more information please see http://www.nanog.org/meetings/nanog52/index.php.

Regards,

Mike

--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)





From bross at pobox.com  Mon May 23 10:00:12 2011
From: bross at pobox.com (Brandon Ross)
Date: Mon, 23 May 2011 11:00:12 -0400 (EDT)
Subject: NANOG 52 - Room block filling up!
In-Reply-To: <D8CD26287252844898B508C40824D8F43C438F@AD-EXH02.adhost.lan>
References: <D8CD26287252844898B508C40824D8F43C438F@AD-EXH02.adhost.lan>
Message-ID: <Pine.OSX.4.64.1105231059430.320@cevin-2.local>

For what it's worth, the hotel appears to be completely booked the nights 
of the 14th and 15th.

On Mon, 23 May 2011, Michael K. Smith - Adhost wrote:

> Hello All:
>
> NANOG 52 in Denver is fast approaching.  If you're planning on attending and want to get the benefits of the NANOG room rate, you should consider signing up as soon as possible.  We're at 85% of our room block capacity and the cutoff date for the NANOG rate is May 29th at 5:00 PM Denver time (GMT -6).  For more information please see http://www.nanog.org/meetings/nanog52/index.php.
>
> Regards,
>
> Mike
>
> --
> Michael K. Smith - CISSP, GSEC, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
>
>
>

-- 
Brandon Ross                                              AIM:  BrandonNRoss
                                                                ICQ:  2269442
                                    Skype:  brandonross  Yahoo:  BrandonNRoss



From bross at pobox.com  Mon May 23 10:08:10 2011
From: bross at pobox.com (Brandon Ross)
Date: Mon, 23 May 2011 11:08:10 -0400 (EDT)
Subject: NANOG 52 - Room block filling up!
In-Reply-To: <Pine.OSX.4.64.1105231059430.320@cevin-2.local>
References: <D8CD26287252844898B508C40824D8F43C438F@AD-EXH02.adhost.lan>
	<Pine.OSX.4.64.1105231059430.320@cevin-2.local>
Message-ID: <Pine.OSX.4.64.1105231107260.320@cevin-2.local>

I take that back, it shows as booked if you go through normal booking 
channels, if you use the starwoodmeetings URL in the NANOG meeting 
information page it shows availability.

On Mon, 23 May 2011, Brandon Ross wrote:

> For what it's worth, the hotel appears to be completely booked the nights of 
> the 14th and 15th.
>
> On Mon, 23 May 2011, Michael K. Smith - Adhost wrote:
>
>> Hello All:
>> 
>> NANOG 52 in Denver is fast approaching.  If you're planning on attending 
>> and want to get the benefits of the NANOG room rate, you should consider 
>> signing up as soon as possible.  We're at 85% of our room block capacity 
>> and the cutoff date for the NANOG rate is May 29th at 5:00 PM Denver time 
>> (GMT -6).  For more information please see 
>> http://www.nanog.org/meetings/nanog52/index.php.
>> 
>> Regards,
>> 
>> Mike
>> 
>> --
>> Michael K. Smith - CISSP, GSEC, GISP
>> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
>> w: +1 (206) 404-9500 f: +1 (206) 404-9050
>> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
>> 
>> 
>> 
>
>

-- 
Brandon Ross                                              AIM:  BrandonNRoss
                                                                ICQ:  2269442
                                    Skype:  brandonross  Yahoo:  BrandonNRoss



From markfarina76 at gmail.com  Mon May 23 10:28:13 2011
From: markfarina76 at gmail.com (Mark Farina)
Date: Mon, 23 May 2011 11:28:13 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
Message-ID: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>

As of April 27th I have started to receive dhcp broadcast requests
originating from the 7.0.0.0/8 network. Based on MAC addresses, it
seems that this is communication between the Rogers border/node
hardware (MAC assigned to Cisco) and my Motorola cable modem.

Is the DoD releasing this range to Rogers? Or has Rogers squatted on
this space due to exhaustion of their 10/8 use? We've seen other
vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s).
Could they not wrap their internal cable modem to node chatter in
IPv6, instead of using assigned address space?

sample chatter ..

MAC=00:14:f1:eb:57:de:08:00  SRC=7.8.12.1 DST=255.255.255.255 LEN=347
TOS=00 PREC=0x00 TTL=255 ID=16 PROTO=UDP SPT=67 DPT=68 LEN=327

IP (tos 0x0, ttl 255, id 15, offset 0, flags [none], proto UDP (17), length 355)
??? 7.8.12.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply,
length 327, xid 0x4, Flags [Broadcast] (0x8000)
????????? Your-IP 7.8.x.x
????????? Server-IP 7.8.x.1
????????? Gateway-IP 7.8.x.1
????????? Client-Ethernet-Address 00:0e:5c:xx:xx:xx
????????? file "xxx"
????????? Vendor-rfc1048 Extensions
??????????? Magic Cookie 0xXX
??????????? DHCP-Message Option 53, length 1: Offer
??????????? Server-ID Option 54, length 4: 64.71.246.x
??????????? Lease-Time Option 51, length 4: 548020
??????????? Subnet-Mask Option 1, length 4: 255.255.252.0
??????????? RN Option 58, length 4: 40
??????????? Time-Zone Option 2, length 4: 0
??????????? Default-Gateway Option 3, length 4: 7.8.x.1
??????????? Time-Server Option 4, length 4: 64.71.x.x
??????????? END Option 255, length 0
??????????? PAD Option 0, length 0, occurs 41

--
MF
gbtel.ca



From oberman at es.net  Mon May 23 11:01:20 2011
From: oberman at es.net (Kevin Oberman)
Date: Mon, 23 May 2011 09:01:20 -0700
Subject: NANOG 52 - Room block filling up! 
In-Reply-To: Your message of "Mon, 23 May 2011 11:08:10 EDT."
	<Pine.OSX.4.64.1105231107260.320@cevin-2.local> 
Message-ID: <20110523160120.A72101CC0B@ptavv.es.net>

> Date: Mon, 23 May 2011 11:08:10 -0400 (EDT)
> From: Brandon Ross <bross at pobox.com>
> 
> I take that back, it shows as booked if you go through normal booking 
> channels, if you use the starwoodmeetings URL in the NANOG meeting 
> information page it shows availability.

Which means our block is not full, but, outside the block, the hotel is
fully booked. If we don't use all of the NANOG block by the 30th, those
rooms will probably be released for general use but it is very likely
that if you don't reserve soon either the block will fill or the few
rooms left will be booked shortly after they are released.

Don't wait too long!
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From dmburgess at linktechs.net  Mon May 23 11:21:59 2011
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Mon, 23 May 2011 11:21:59 -0500
Subject: NANOG 52 - Room block filling up! 
References: <20110523160120.A72101CC0B@ptavv.es.net>
Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50169F43A@ltiserver.lti.local>

Already booked and ready to go! 

-----------------------------------------------------------
Dennis Burgess, Mikrotik Certified Trainer 
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 Website: http://www.linktechs.net
LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"


-----Original Message-----
From: Kevin Oberman [mailto:oberman at es.net] 
Sent: May 23, 2011 11:01 AM
To: Brandon Ross
Cc: nanog at nanog.org
Subject: Re: NANOG 52 - Room block filling up! 

> Date: Mon, 23 May 2011 11:08:10 -0400 (EDT)
> From: Brandon Ross <bross at pobox.com>
> 
> I take that back, it shows as booked if you go through normal booking 
> channels, if you use the starwoodmeetings URL in the NANOG meeting 
> information page it shows availability.

Which means our block is not full, but, outside the block, the hotel is
fully booked. If we don't use all of the NANOG block by the 30th, those
rooms will probably be released for general use but it is very likely
that if you don't reserve soon either the block will fill or the few
rooms left will be booked shortly after they are released.

Don't wait too long!
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751




From drc at virtualized.org  Mon May 23 11:32:09 2011
From: drc at virtualized.org (David Conrad)
Date: Mon, 23 May 2011 09:32:09 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
Message-ID: <5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>

On May 23, 2011, at 8:28 AM, Mark Farina wrote:
> Is the DoD releasing this range to Rogers?

Unlikely, although it might be an interesting case of testing ARIN's transfer policy if it was the case :-).

> Or has Rogers squatted on this space due to exhaustion of their 10/8 use?

Probably. I've heard other large providers having similar issues (resulting in several attempts to designate more RFC 1918, all of which were all shot down).

> We've seen other vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s).

Yes, however at the time those ISPs squatted on those addresses (and others), they had not yet been allocated by IANA pretty much guaranteeing there would be collisions when the IPv4 free pool was exhausted.  In this case, the block has been allocated yet doesn't appear to be in the routing system and I'm not sure it ever has been (at least authorized to be).  I'm guessing Rogers is making the assumption that the chances are probably small that one of their customers will need to communicate with a non-announced US DoD network.  I suspect they aren't the first to make this assumption.

> Could they not wrap their internal cable modem to node chatter in IPv6, instead of using assigned address space?

This would assume their deployed systems can support IPv6.  I suspect they have a few non-upgradeable systems/devices in their network and have chosen to squat on 7/8 rather than raise their rates to cover short-term upgrade costs (or deal with additional operational costs if they used multiple instances of 10/8).  But I'm just guessing...

Regards,
-drc




From owen at delong.com  Mon May 23 12:36:56 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 23 May 2011 12:36:56 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
Message-ID: <61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>



Sent from my iPad

On May 23, 2011, at 11:32, David Conrad <drc at virtualized.org> wrote:

> On May 23, 2011, at 8:28 AM, Mark Farina wrote:
>> Is the DoD releasing this range to Rogers?
> 
> Unlikely, although it might be an interesting case of testing ARIN's transfer policy if it was the case :-).
> 
>> Or has Rogers squatted on this space due to exhaustion of their 10/8 use?
> 
> Probably. I've heard other large providers having similar issues (resulting in several attempts to designate more RFC 1918, all of which were all shot down).
> 

Really? All of them? Are you sure about that?

I believe there is a policy proposal in the ARIN region which, I have it on good authority
is still active.

True, it doesn't technically designate more RFC-1918, but, it does create a /10 of space
for shared use for the purpose of LSN intermediate space or other carrier-level private
network usage.

>> We've seen other vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s).
> 
> Yes, however at the time those ISPs squatted on those addresses (and others), they had not yet been allocated by IANA pretty much guaranteeing there would be collisions when the IPv4 free pool was exhausted.  In this case, the block has been allocated yet doesn't appear to be in the routing system and I'm not sure it ever has been (at least authorized to be).  I'm guessing Rogers is making the assumption that the chances are probably small that one of their customers will need to communicate with a non-announced US DoD network.  I suspect they aren't the first to make this assumption.
> 

More likely they are making the assumption that their private internal use of the address
space won't conflict with DoD's (apparently) private internal use of the address space.

Owen




From joelja at bogus.com  Mon May 23 14:44:33 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 23 May 2011 12:44:33 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
Message-ID: <B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>


On May 23, 2011, at 10:36 AM, Owen DeLong wrote:

> 
> 
> Sent from my iPad
> 
> On May 23, 2011, at 11:32, David Conrad <drc at virtualized.org> wrote:
> 
>> On May 23, 2011, at 8:28 AM, Mark Farina wrote:
>>> Is the DoD releasing this range to Rogers?
>> 
>> Unlikely, although it might be an interesting case of testing ARIN's transfer policy if it was the case :-).
>> 
>>> Or has Rogers squatted on this space due to exhaustion of their 10/8 use?
>> 
> 
> More likely they are making the assumption that their private internal use of the address
> space won't conflict with DoD's (apparently) private internal use of the address space.

if they're numbering cpe out of it they've also decided that breaking 6to4 is no problem either, if they aren't then hey it's just more ipv4 ugliness, and there's alot more where that came from...

joel

From ryan at u13.net  Mon May 23 18:39:45 2011
From: ryan at u13.net (Ryan Rawdon)
Date: Mon, 23 May 2011 19:39:45 -0400
Subject: IPv6 Availability on XO
Message-ID: <835617D6-5709-467B-91F0-91E20448AEA9@u13.net>

I've heard some mixed reports of XO's IPv6 availability - some that they have full deployment/availability, but others like the answer back from our XO reseller that XO does not offer IPv6 on circuits under 45mbit/s.

What is the experience of NANOG on this matter, particularly with XO connectivity under 45mbit/s?




From darren at bolding.org  Mon May 23 20:34:18 2011
From: darren at bolding.org (Darren Bolding)
Date: Mon, 23 May 2011 18:34:18 -0700
Subject: Experiences with "advanced" network taps.
Message-ID: <BANLkTimoLKTBGGG=XqvPEr_JPuukBMJbQA@mail.gmail.com>

We are planning on purchasing some network taps for a couple of locations in
our network, and we expect to make significantly greater use of them in the
next year or two.

Something that is new since I last investigated taps (it has been a while)
is that many of them now allow for functionality I would typically think of
as far outside what a simple tap does.

For example:

Selective forwarding of packets based on MAC address, TCP/UDP port, IP
address range etc.
Selective forwarding/load balancing based on flow, so that you can
distribute traffic across a cluster of devices (e.g. IDS or netflow probes)
Ability to insert a device (firewall, IDS, etc) into the network flow and
via software configuration bypass traffic around the device- e.g. able to
quickly drop a device out of the network path.
- Some have the ability to send network probes, or monitor traffic
downstream of an inline device so they can automatically take the device out
of line if it fails to pass traffic.
- Some can filter which traffic goes through the inline device and merge it
back with the traffic that was not sent to the inline device for downstream
consumption.
Some can be connected and automatically be managed as if one device,
allowing monitor and replication ports to be used across the stack/mesh of
devices.

All of this is very interesting.  Of course these taps cost more than your
basic dumb tap.

More interestingly to me is that these taps are no longer dumb, and that
makes them a bit of a riskier proposition.  In evaluating some we have run
into issues ranging from misconfiguration/user error to what appear to be
crashes (with associated loss of forwarding).

I'm wondering if anyone has had significant experience deploying these more
advanced taps, whether it was good or bad, general comments you might like
to share regarding them, and whether you would recommend particular vendors.

If people reply off-list, I will make a point of summarizing back if I get
any feedback.

Thanks!

--D

-- 
--  Darren Bolding                  --
--  darren at bolding.org           --


From jason at biel-tech.com  Mon May 23 20:36:45 2011
From: jason at biel-tech.com (Jason Biel)
Date: Mon, 23 May 2011 20:36:45 -0500
Subject: Experiences with "advanced" network taps.
In-Reply-To: <BANLkTimoLKTBGGG=XqvPEr_JPuukBMJbQA@mail.gmail.com>
References: <BANLkTimoLKTBGGG=XqvPEr_JPuukBMJbQA@mail.gmail.com>
Message-ID: <BANLkTi=zyojKgKpQiduOf1NSzhQswkteQA@mail.gmail.com>

Look at NetOptics Directors or the VSS 4x24.  I've deployed several.

On Mon, May 23, 2011 at 8:34 PM, Darren Bolding <darren at bolding.org> wrote:

> We are planning on purchasing some network taps for a couple of locations
> in
> our network, and we expect to make significantly greater use of them in the
> next year or two.
>
> Something that is new since I last investigated taps (it has been a while)
> is that many of them now allow for functionality I would typically think of
> as far outside what a simple tap does.
>
> For example:
>
> Selective forwarding of packets based on MAC address, TCP/UDP port, IP
> address range etc.
> Selective forwarding/load balancing based on flow, so that you can
> distribute traffic across a cluster of devices (e.g. IDS or netflow probes)
> Ability to insert a device (firewall, IDS, etc) into the network flow and
> via software configuration bypass traffic around the device- e.g. able to
> quickly drop a device out of the network path.
> - Some have the ability to send network probes, or monitor traffic
> downstream of an inline device so they can automatically take the device
> out
> of line if it fails to pass traffic.
> - Some can filter which traffic goes through the inline device and merge it
> back with the traffic that was not sent to the inline device for downstream
> consumption.
> Some can be connected and automatically be managed as if one device,
> allowing monitor and replication ports to be used across the stack/mesh of
> devices.
>
> All of this is very interesting.  Of course these taps cost more than your
> basic dumb tap.
>
> More interestingly to me is that these taps are no longer dumb, and that
> makes them a bit of a riskier proposition.  In evaluating some we have run
> into issues ranging from misconfiguration/user error to what appear to be
> crashes (with associated loss of forwarding).
>
> I'm wondering if anyone has had significant experience deploying these more
> advanced taps, whether it was good or bad, general comments you might like
> to share regarding them, and whether you would recommend particular
> vendors.
>
> If people reply off-list, I will make a point of summarizing back if I get
> any feedback.
>
> Thanks!
>
> --D
>
> --
> --  Darren Bolding                  --
> --  darren at bolding.org           --
>



-- 
Jason


From marka at isc.org  Mon May 23 21:00:00 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 24 May 2011 12:00:00 +1000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: Your message of "Mon, 23 May 2011 12:44:33 MST."
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
Message-ID: <20110524020000.6FA46EF4A47@drugs.dv.isc.org>


In message <B2100B46-6D93-46A2-8746-5CFB8BE88AE9 at bogus.com>, Joel Jaeggli write
s:
> 
> On May 23, 2011, at 10:36 AM, Owen DeLong wrote:
> 
> >=20
> >=20
> > Sent from my iPad
> >=20
> > On May 23, 2011, at 11:32, David Conrad <drc at virtualized.org> wrote:
> >=20
> >> On May 23, 2011, at 8:28 AM, Mark Farina wrote:
> >>> Is the DoD releasing this range to Rogers?
> >>=20
> >> Unlikely, although it might be an interesting case of testing ARIN's =
> transfer policy if it was the case :-).
> >>=20
> >>> Or has Rogers squatted on this space due to exhaustion of their 10/8 =
> use?
> >>=20
> >=20
> > More likely they are making the assumption that their private internal =
> use of the address
> > space won't conflict with DoD's (apparently) private internal use of =
> the address space.
> 
> if they're numbering cpe out of it they've also decided that breaking =
> 6to4 is no problem either, if they aren't then hey it's just more ipv4 =
> ugliness, and there's alot more where that came from...
> 
> joel=

and other stuff which doesn't work in a double nat environment.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From cb.list6 at gmail.com  Mon May 23 21:38:01 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 23 May 2011 19:38:01 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <20110524020000.6FA46EF4A47@drugs.dv.isc.org>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
Message-ID: <BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>

On Mon, May 23, 2011 at 7:00 PM, Mark Andrews <marka at isc.org> wrote:
>
> In message <B2100B46-6D93-46A2-8746-5CFB8BE88AE9 at bogus.com>, Joel Jaeggli write
> s:
>>
>> On May 23, 2011, at 10:36 AM, Owen DeLong wrote:
>>
>> >=20
>> >=20
>> > Sent from my iPad
>> >=20
>> > On May 23, 2011, at 11:32, David Conrad <drc at virtualized.org> wrote:
>> >=20
>> >> On May 23, 2011, at 8:28 AM, Mark Farina wrote:
>> >>> Is the DoD releasing this range to Rogers?
>> >>=20
>> >> Unlikely, although it might be an interesting case of testing ARIN's =
>> transfer policy if it was the case :-).
>> >>=20
>> >>> Or has Rogers squatted on this space due to exhaustion of their 10/8 =
>> use?
>> >>=20
>> >=20
>> > More likely they are making the assumption that their private internal =
>> use of the address
>> > space won't conflict with DoD's (apparently) private internal use of =
>> the address space.
>>
>> if they're numbering cpe out of it they've also decided that breaking =
>> 6to4 is no problem either, if they aren't then hey it's just more ipv4 =
>> ugliness, and there's alot more where that came from...
>>
>> joel=
>
> and other stuff which doesn't work in a double nat environment.
>

This is the business reality of the IPv4-scarce era.  Diluted IPv4 is
not new to many places and will become common in many more places.
Furthermore, it is a calculated business risk.  IPv4 services
will/have become the 2nd class (NAT444...)  services as IPv6 ascends
to first class status with e2e restored and more and more services
supporting IPv6 (World IPv6 day in a little over 2 week!...).

Don't get me wrong, IPv6 has a long way to go in terms of
availability, peering, and application support.  But make no mistake,
the tide is turning.  Rogers is doing what they have to do proactively
to stay ahead of the curve of complete exhaustion.

As for 6to4, the good folks at Rogers have found a way to make it work
for you ... with yet another NAT :)

http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02

Cameron

 --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org
>
>



From owen at delong.com  Mon May 23 22:34:11 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 23 May 2011 20:34:11 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
Message-ID: <1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>

> 
> This is the business reality of the IPv4-scarce era.  Diluted IPv4 is
> not new to many places and will become common in many more places.
> Furthermore, it is a calculated business risk.  IPv4 services
> will/have become the 2nd class (NAT444...)  services as IPv6 ascends
> to first class status with e2e restored and more and more services
> supporting IPv6 (World IPv6 day in a little over 2 week!...).
> 

Diluted IPv4 is one thing. Hijacking space allocated to another entity
is another. As long as they keep it contained within their network,
it's pretty much up to them to break their own environment however
they see fit, but, if they start leaking 7.0.0.0/8 or subset announcements
on to the internet in general, I wouldn't want to be them or one of the
companies that was accepting their routes.

> Don't get me wrong, IPv6 has a long way to go in terms of
> availability, peering, and application support.  But make no mistake,
> the tide is turning.  Rogers is doing what they have to do proactively
> to stay ahead of the curve of complete exhaustion.
> 
I don't think they have to hijack space from DoD. I think there are a
number of other options available to them. They might cost more, but,
they also come with somewhat lower risks.

Owen




From morrowc.lists at gmail.com  Mon May 23 23:02:24 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 24 May 2011 00:02:24 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
Message-ID: <BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>

On Mon, May 23, 2011 at 11:34 PM, Owen DeLong <owen at delong.com> wrote:
>
> I don't think they have to hijack space from DoD. I think there are a
> number of other options available to them. They might cost more, but,
> they also come with somewhat lower risks

the good thing is 7 exists on networks that will never see the light
of day... so it's just like 10! only lower and cooler! (and lucky, if
you believe the movies and all)



From patrick at ianai.net  Mon May 23 23:09:39 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 24 May 2011 00:09:39 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
Message-ID: <47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>

On May 24, 2011, at 12:02 AM, Christopher Morrow wrote:
> On Mon, May 23, 2011 at 11:34 PM, Owen DeLong <owen at delong.com> wrote:
>> 
>> I don't think they have to hijack space from DoD. I think there are a
>> number of other options available to them. They might cost more, but,
>> they also come with somewhat lower risks
> 
> the good thing is 7 exists on networks that will never see the light
> of day... so it's just like 10! only lower and cooler! (and lucky, if
> you believe the movies and all)

It's not just whether those networks will ever leak 7.  It's whether the DoD will ever announce anything in 7.

If they do, any Rogers customer who wants to talk to it is screwed.  Whether they have a 7 addy or not, Rogers' routers will not let the packet leave Rogers' borders.

-- 
TTFN,
patrick




From drc at virtualized.org  Mon May 23 23:09:58 2011
From: drc at virtualized.org (David Conrad)
Date: Mon, 23 May 2011 21:09:58 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
Message-ID: <67E3E746-545B-4D81-8C64-A91F89303DC1@virtualized.org>

Owen,

On May 23, 2011, at 8:34 PM, Owen DeLong wrote:
> I think there are a number of other options available to them. 


Out of curiosity, what would these options be?

Regards,
-drc




From cb.list6 at gmail.com  Mon May 23 23:14:02 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 23 May 2011 21:14:02 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
Message-ID: <BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>

On Mon, May 23, 2011 at 9:09 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> On May 24, 2011, at 12:02 AM, Christopher Morrow wrote:
>> On Mon, May 23, 2011 at 11:34 PM, Owen DeLong <owen at delong.com> wrote:
>>>
>>> I don't think they have to hijack space from DoD. I think there are a
>>> number of other options available to them. They might cost more, but,
>>> they also come with somewhat lower risks
>>
>> the good thing is 7 exists on networks that will never see the light
>> of day... so it's just like 10! only lower and cooler! (and lucky, if
>> you believe the movies and all)
>
> It's not just whether those networks will ever leak 7. ?It's whether the DoD will ever announce anything in 7.
>
> If they do, any Rogers customer who wants to talk to it is screwed. ?Whether they have a 7 addy or not, Rogers' routers will not let the packet leave Rogers' borders.
>

Now, the onus is on the DoD to make its content available over unique
IPv6 space so that the Roger's customers can get to it using the
6to4-PMT solution.  There is always a solution.

Cameron

> --
> TTFN,
> patrick
>
>
>



From Valdis.Kletnieks at vt.edu  Mon May 23 23:22:36 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 24 May 2011 00:22:36 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: Your message of "Mon, 23 May 2011 21:14:02 PDT."
	<BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>
Message-ID: <17520.1306210956@localhost>

On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said:

> Now, the onus is on the DoD to make its content available over unique
> IPv6 space so that the Roger's customers can get to it using the
> 6to4-PMT solution.  There is always a solution.

Which they should be ready to do already, since didn't the US Govt.
mandate IPv6 support sometime last century? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110524/faf45200/attachment.bin>

From cb.list6 at gmail.com  Mon May 23 23:29:19 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 23 May 2011 21:29:19 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <17520.1306210956@localhost>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>
	<17520.1306210956@localhost>
Message-ID: <BANLkTimMRn1jtbVvS-1V+C8KTRVSPA9qHg@mail.gmail.com>

On Mon, May 23, 2011 at 9:22 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said:
>
>> Now, the onus is on the DoD to make its content available over unique
>> IPv6 space so that the Roger's customers can get to it using the
>> 6to4-PMT solution. ?There is always a solution.
>
> Which they should be ready to do already, since didn't the US Govt.
> mandate IPv6 support sometime last century? ;)
>

The US Govt does actually have a respectable showing for World IPv6
Day including treasury.gov, edu.gov, census.gov and others.

CB



From marka at isc.org  Mon May 23 23:32:05 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 24 May 2011 14:32:05 +1000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: Your message of "Mon, 23 May 2011 21:14:02 MST."
	<BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>
Message-ID: <20110524043205.79E3CEF64CA@drugs.dv.isc.org>


In message <BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg at mail.gmail.com>, Cameron Byrne 
writes:
> On Mon, May 23, 2011 at 9:09 PM, Patrick W. Gilmore <patrick at ianai.net> wro=
> te:
> > On May 24, 2011, at 12:02 AM, Christopher Morrow wrote:
> >> On Mon, May 23, 2011 at 11:34 PM, Owen DeLong <owen at delong.com> wrote:
> >>>
> >>> I don't think they have to hijack space from DoD. I think there are a
> >>> number of other options available to them. They might cost more, but,
> >>> they also come with somewhat lower risks
> >>
> >> the good thing is 7 exists on networks that will never see the light
> >> of day... so it's just like 10! only lower and cooler! (and lucky, if
> >> you believe the movies and all)
> >
> > It's not just whether those networks will ever leak 7. =A0It's whether th=
> e DoD will ever announce anything in 7.
> >
> > If they do, any Rogers customer who wants to talk to it is screwed. =A0Wh=
> ether they have a 7 addy or not, Rogers' routers will not let the packet le=
> ave Rogers' borders.
> >
> 
> Now, the onus is on the DoD to make its content available over unique
> IPv6 space so that the Roger's customers can get to it using the
> 6to4-PMT solution.  There is always a solution.

There is also the option of having customers that need 6to4, etc.
just register on the web site like customers that need port 25/TCP
open register with many ISPs.  Those customers then get addresses
from different pools for which 6to4 works.

> Cameron
> 
> > --
> > TTFN,
> > patrick
> >
> >
> >
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From marka at isc.org  Mon May 23 23:35:29 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 24 May 2011 14:35:29 +1000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: Your message of "Tue, 24 May 2011 00:22:36 -0400."
	<17520.1306210956@localhost>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=i6nSSvj-ah2nbWpiZ_jYhLc3Lsg@mail.gmail.com>
	<17520.1306210956@localhost>
Message-ID: <20110524043529.11A11EF6570@drugs.dv.isc.org>


In message <17520.1306210956 at localhost>, Valdis.Kletnieks at vt.edu writes:
> On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said:
> 
> > Now, the onus is on the DoD to make its content available over unique
> > IPv6 space so that the Roger's customers can get to it using the
> > 6to4-PMT solution.  There is always a solution.
> 
> Which they should be ready to do already, since didn't the US Govt.
> mandate IPv6 support sometime last century? ;)

Which isn't yet a practical solution because it takes two to play.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From mysidia at gmail.com  Mon May 23 23:36:24 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 23 May 2011 23:36:24 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
Message-ID: <BANLkTi=tRT3j71Ty6YVp3c9DvXhS3CnjSQ@mail.gmail.com>

On Mon, May 23, 2011 at 11:09 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> If they do, any Rogers customer who wants to talk to it is screwed. ?Whether they have a 7 addy or not, Rogers' routers will not let the packet leave Rogers' borders.

That could depend on whether Rogers' border routers are adequately configured
to block/filter the announcement,  and whether  whatever the DoD  chose to
announce was a longer prefix than what  Rogers' equipment had
routes/controls for.

In theory;  there exists a possibility that the DoD could announce a
/24  of something
Rogers'  was internally routing as a /16,  then if unfiltered the DoD
announce could win,
causing internal (self-inflicted) issues for Rogers.

The DoD could also eventually use the 7 range for something, resulting
in complaints to Rogers
from users who seem unable to reach (some web site placed in 7/8).


Unofficial use of other organization's IP address space is playing with fire.


It may mark the symbolic start of a new IPv4,  where eventually
many /8s will have tons of unofficial claimaints,  and whoever
threatens more, pays the major providers more, or has more lawyers
(take your pick),  gets their announcement more widely propagated.

Sometimes if enough players start playing with fire, a really bad,
uncontrollable inferno eventually gets ignited.

> TTFN,
> patrick
--
-JH



From patrick at ianai.net  Mon May 23 23:42:14 2011
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 24 May 2011 00:42:14 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTi=tRT3j71Ty6YVp3c9DvXhS3CnjSQ@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=tRT3j71Ty6YVp3c9DvXhS3CnjSQ@mail.gmail.com>
Message-ID: <B2551498-57FB-4679-A6CC-FC06327D4017@ianai.net>

On May 24, 2011, at 12:36 AM, Jimmy Hess wrote:
> On Mon, May 23, 2011 at 11:09 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
>> If they do, any Rogers customer who wants to talk to it is screwed.  Whether they have a 7 addy or not, Rogers' routers will not let the packet leave Rogers' borders.
> 
> That could depend on whether Rogers' border routers are adequately configured
> to block/filter the announcement,  and whether  whatever the DoD  chose to
> announce was a longer prefix than what  Rogers' equipment had
> routes/controls for.
> 
> In theory;  there exists a possibility that the DoD could announce a
> /24  of something
> Rogers'  was internally routing as a /16,  then if unfiltered the DoD
> announce could win,
> causing internal (self-inflicted) issues for Rogers.

We're all just guessing here, until some Rogers engineer speaks up.

However, many networks take active steps to assure that external parties cannot disrupt their internal network.  Anyone on this list with internal prefixes shorter than /24 likely have filters or other mechanisms in place to ensure they do not hear a /24 of their own space from peers & transit providers.  If they do not, then they are at risk, whether they use highjacked space or not.

As a result, while it is possible the DoD could announce a /24 that Rogers routes internally as a /16 and cause Rogers problems; I suspect Rogers ensured the DoD - or anyone else - cannot cause them problems.  Other than putting a web server in 7/8 that Rogers customers want to visit. :)

-- 
TTFN,
patrick


> The DoD could also eventually use the 7 range for something, resulting
> in complaints to Rogers
> from users who seem unable to reach (some web site placed in 7/8).
> 
> 
> Unofficial use of other organization's IP address space is playing with fire.
> 
> 
> It may mark the symbolic start of a new IPv4,  where eventually
> many /8s will have tons of unofficial claimaints,  and whoever
> threatens more, pays the major providers more, or has more lawyers
> (take your pick),  gets their announcement more widely propagated.
> 
> Sometimes if enough players start playing with fire, a really bad,
> uncontrollable inferno eventually gets ignited.
> 
>> TTFN,
>> patrick
> --
> -JH
> 




From cb.list6 at gmail.com  Mon May 23 23:48:53 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 23 May 2011 21:48:53 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTi=tRT3j71Ty6YVp3c9DvXhS3CnjSQ@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=tRT3j71Ty6YVp3c9DvXhS3CnjSQ@mail.gmail.com>
Message-ID: <BANLkTi=phg-yK808Z1o+o4U21QtA1AFG5w@mail.gmail.com>

On May 23, 2011 9:37 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:
>
> On Mon, May 23, 2011 at 11:09 PM, Patrick W. Gilmore <patrick at ianai.net>
wrote:
> > If they do, any Rogers customer who wants to talk to it is screwed.
 Whether they have a 7 addy or not, Rogers' routers will not let the packet
leave Rogers' borders.
>
> That could depend on whether Rogers' border routers are adequately
configured
> to block/filter the announcement,  and whether  whatever the DoD  chose to
> announce was a longer prefix than what  Rogers' equipment had
> routes/controls for.
>
> In theory;  there exists a possibility that the DoD could announce a
> /24  of something
> Rogers'  was internally routing as a /16,  then if unfiltered the DoD
> announce could win,
> causing internal (self-inflicted) issues for Rogers.
>
> The DoD could also eventually use the 7 range for something, resulting
> in complaints to Rogers
> from users who seem unable to reach (some web site placed in 7/8).
>
>
> Unofficial use of other organization's IP address space is playing with
fire.
>
>
> It may mark the symbolic start of a new IPv4,  where eventually
> many /8s will have tons of unofficial claimaints,  and whoever
> threatens more, pays the major providers more, or has more lawyers
> (take your pick),  gets their announcement more widely propagated.
>
> Sometimes if enough players start playing with fire, a really bad,
> uncontrollable inferno eventually gets ignited.
>

Or, ipv6 gets deployed and supported since it will be the effective network
of networks

Cb

> > TTFN,
> > patrick
> --
> -JH
>


From johnl at iecc.com  Mon May 23 23:50:03 2011
From: johnl at iecc.com (John Levine)
Date: 24 May 2011 04:50:03 -0000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <17520.1306210956@localhost>
Message-ID: <20110524045003.64943.qmail@joyce.lan>

>Which they should be ready to do already, since didn't the US Govt.
>mandate IPv6 support sometime last century? ;)

Yeah, it runs over GOSIP.

R's,
John



From owen at delong.com  Tue May 24 00:05:29 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 23 May 2011 22:05:29 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <67E3E746-545B-4D81-8C64-A91F89303DC1@virtualized.org>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<67E3E746-545B-4D81-8C64-A91F89303DC1@virtualized.org>
Message-ID: <E98FD71B-9409-464D-B6DE-AB8596BAE3EE@delong.com>


On May 23, 2011, at 9:09 PM, David Conrad wrote:

> Owen,
> 
> On May 23, 2011, at 8:34 PM, Owen DeLong wrote:
>> I think there are a number of other options available to them. 
> 
> 
> Out of curiosity, what would these options be?
> 

As previously mentioned:

	1.	Obtain RIR space
	2.	Use multiple partitioned copies of RFC-1918
	3.	Free addresses among existing customers through LSN implementation.

There may be others.

Yes, each of these comes with its own tradeoffs and costs. Obviously, option 1 is of
a limited duration.

Owen




From mysidia at gmail.com  Tue May 24 00:21:36 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 24 May 2011 00:21:36 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <B2551498-57FB-4679-A6CC-FC06327D4017@ianai.net>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<BANLkTimG3+TXMZFJyhhuyDnZe2mNf39YiA@mail.gmail.com>
	<47B9E64B-8FF1-46BE-8E45-DD3CB7C3055B@ianai.net>
	<BANLkTi=tRT3j71Ty6YVp3c9DvXhS3CnjSQ@mail.gmail.com>
	<B2551498-57FB-4679-A6CC-FC06327D4017@ianai.net>
Message-ID: <BANLkTimSwb7tijPa3N+4MmEmkYvojjD-fA@mail.gmail.com>

On Mon, May 23, 2011 at 11:42 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> However, many networks take active steps to assure that external parties
> cannot disrupt their internal network. ?Anyone on this list with

And many networks have implemented BCP38 and appropriate prefix
filters + as path filters  with their peers, including upstreams.
Some networks take active steps.   I think as a group you give them a
little too much credit.

I don't mean to speculate about what exactly Rogers is doing. Only
that:  if they just spontaneously decided to start using "7/8" on
their
internal network as unofficial space,  they could be putting
themselves at risk in unanticipated ways.

Even with active protection against that particular risk, it is still
possible the unofficial use will be harmful to the DoD some day, in
some way, resulting in repercussions against the unofficial user....

If you want to use some other organization's IP addresses without
their permission, for any purpose (internal or not);
It seems like the DoD, military commands of other large countries,
along with local law enforcement
organizations should be at the very _bottom_ of the list;   they have
more extreme retaliation/investigative
powers than any private company does.


> internal prefixes shorter than /24 likely have filters or other mechanisms in
> place to ensure they do not hear a /24 of their own space from peers & transit providers.
> ?If they do not, then they are at risk, whether they use highjacked space or not.

--
-JH



From feldman at newnog.org  Tue May 24 01:26:07 2011
From: feldman at newnog.org (Steven Feldman)
Date: Mon, 23 May 2011 23:26:07 -0700
Subject: NANOG transition update
Message-ID: <FFD7AEFE-6DF8-4936-878D-77F974BBF325@newnog.org>

A lot of progress has been made since NANOG 51, so I'd like to share
this update with the community.

* Association management contract

We recently completed our RFP and selection process, and have
contracted with Association Management Solutions (http://www.amsl.com)
to provide association management and meeting support services for
NANOG.  We are excited to be working with AMS, as they have an
excellent set of management and IT services which are very good fits
to our needs.

AMS might already be familiar to some of our community, as they have
providing IETF secretariat services for the past several years.
Representatives from AMS will be with us in Denver to observe the
conference and meet the community.

Over the next couple of months our meeting registration, membership,
mailing list and finance systems will be migrated to AMS
infrastructure.  The transition has already started, and will be
completed in time for the start of registration for the NANOG53
meeting.

We'll share more details of the transition process as they become available.

* NANOG Intellectual Property

All of the NANOG intellectual property originated by Merit Network,
including the name, domain, logos, mailing lists and archives, have
been transferred to NewNOG.  This means that we _are_ NANOG!

We expect that the interim name "NewNOG" will eventually go away.

* Non-profit status

NewNOG, Inc. has been recognized by the IRS as a 501(c)(3) charitable
organization.  (See http://www.newnog.org/docs/IRSletter.pdf for the
IRS determination letter.)  This means that individual donations might
be tax-deductible.

* Future conferences

Work continues on securing hosts and venues for future NANOG
conferences.  The current list of future events is at
http://www.nanog.org/meetings/future/, and we expect to have the
October 2012 meeting ready to announce in the next few weeks.

And if you haven't already registered, please plan to join us at
NANOG52 in Denver next month!  The Program Committee has published a
great agenda, and the hotel block is filling fast.  The hotel group
rate expires on May 29, and the conference registration fee goes up on
June 4, so please register soon!  More information is at
http://www.nanog.org/meetings/nanog52/.

We welcome any questions or comments, and we'll give another update at
the community meeting in Denver.

For the board,
  Steve Feldman, chair



From byron at byronhicks.com  Tue May 24 09:04:41 2011
From: byron at byronhicks.com (Byron L. Hicks)
Date: Tue, 24 May 2011 09:04:41 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
Message-ID: <4DDBBAF9.7010306@byronhicks.com>

On 5/23/2011 10:34 PM, Owen DeLong wrote:

> Diluted IPv4 is one thing. Hijacking space allocated to another entity
> is another. As long as they keep it contained within their network,
> it's pretty much up to them to break their own environment however
> they see fit, but, if they start leaking 7.0.0.0/8 or subset announcements
> on to the internet in general, I wouldn't want to be them or one of the
> companies that was accepting their routes.

I ran into this issue with a service provider that wanted to set up
point of sale terminals on our campus.  They were using DoD address
space in their inside network, and they ordered ISDN connectivity from
our site back to their network.  The point of sale terminals were
connected on our campus network.  They wanted me to set a static route
on my network backbone that pointed all of the hijacked DoD address
space to this ISDN line.  Of course, I told them no.  The university I
was working for at the time had some DoD contracts, and I was afraid
that it might break legitimate traffic.  Plus, I thought this was a
really bad network design.  The service provider was not very happy.  It
is interesting that I'm not the only one that has come across this problem.

-- 
Byron L. Hicks
Google Voice: 972-746-2549
aim/skype: byronhicks



From leigh.porter at ukbroadband.com  Tue May 24 09:13:24 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 24 May 2011 14:13:24 +0000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <4DDBBAF9.7010306@byronhicks.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<4DDBBAF9.7010306@byronhicks.com>
Message-ID: <D181DDABABE57E4DB72FEE0033147864012EE3@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Byron L. Hicks [mailto:byron at byronhicks.com]
> 
> I ran into this issue with a service provider that wanted to set up
> point of sale terminals on our campus.  They were using DoD address
> space in their inside network, and they ordered ISDN connectivity from
> our site back to their network.  The point of sale terminals were
> connected on our campus network.  They wanted me to set a static route
> on my network backbone that pointed all of the hijacked DoD address
> space to this ISDN line.  Of course, I told them no.  The university I
> was working for at the time had some DoD contracts, and I was afraid
> that it might break legitimate traffic.  Plus, I thought this was a
> really bad network design.  The service provider was not very happy.

I see why they may do this. They have likely had issues with overlapping 1918 
space in previous networks, so they thought "Oh, we'll nick this space, it's DoD
and nobody will ever use it..." and it's all fine, until somebody uses it.

It's just a really lazy way of getting things done that is likely to come and bite
you sooner or later.

So you said NO, and what did they do about it ?


--
Leigh Porter





______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From byron at byronhicks.com  Tue May 24 09:17:41 2011
From: byron at byronhicks.com (Byron L. Hicks)
Date: Tue, 24 May 2011 09:17:41 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <D181DDABABE57E4DB72FEE0033147864012EE3@EALPO1.ukbroadband.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<4DDBBAF9.7010306@byronhicks.com>
	<D181DDABABE57E4DB72FEE0033147864012EE3@EALPO1.ukbroadband.com>
Message-ID: <4DDBBE05.1020800@byronhicks.com>

On 5/24/2011 9:13 AM, Leigh Porter wrote:

> So you said NO, and what did they do about it ?

It forced them to put in their own ISDN router, and they put static
routes on the point of sale terminals that pointed the "borrowed" IP
space to the ISDN router.  There was no way I was going to put this in
the routing tables of my campus routers.

-- 
Byron L. Hicks
Google Voice: 972-746-2549
aim/skype: byronhicks



From rubensk at gmail.com  Tue May 24 09:56:40 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 24 May 2011 11:56:40 -0300
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
Message-ID: <BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>

On Mon, May 23, 2011 at 12:28 PM, Mark Farina <markfarina76 at gmail.com> wrote:
> As of April 27th I have started to receive dhcp broadcast requests
> originating from the 7.0.0.0/8 network. Based on MAC addresses, it
> seems that this is communication between the Rogers border/node
> hardware (MAC assigned to Cisco) and my Motorola cable modem.
>
> Is the DoD releasing this range to Rogers? Or has Rogers squatted on
> this space due to exhaustion of their 10/8 use? We've seen other
> vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s).
> Could they not wrap their internal cable modem to node chatter in
> IPv6, instead of using assigned address space?

Squatting resources from an organization that can deploy F/A-18
Hornets, F/A-22 Raptors, Predator drones or Navy SEALs is probably bad
to your health.


Rubens



From joelja at bogus.com  Tue May 24 10:42:45 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 24 May 2011 08:42:45 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
Message-ID: <0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>


On May 24, 2011, at 7:56 AM, Rubens Kuhl wrote:

> On Mon, May 23, 2011 at 12:28 PM, Mark Farina <markfarina76 at gmail.com> wrote:
>> As of April 27th I have started to receive dhcp broadcast requests
>> originating from the 7.0.0.0/8 network. Based on MAC addresses, it
>> seems that this is communication between the Rogers border/node
>> hardware (MAC assigned to Cisco) and my Motorola cable modem.
>> 
>> Is the DoD releasing this range to Rogers? Or has Rogers squatted on
>> this space due to exhaustion of their 10/8 use? We've seen other
>> vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s).
>> Could they not wrap their internal cable modem to node chatter in
>> IPv6, instead of using assigned address space?
> 
> Squatting resources from an organization that can deploy F/A-18
> Hornets, F/A-22 Raptors, Predator drones or Navy SEALs is probably bad
> to your health.

It's been a while since we fought a war with canada.

http://en.wikipedia.org/wiki/Pig_War

> 
> Rubens
> 



From paul at paulgraydon.co.uk  Tue May 24 10:54:58 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Tue, 24 May 2011 05:54:58 -1000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <4DDBBE05.1020800@byronhicks.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>	<4DDBBAF9.7010306@byronhicks.com>	<D181DDABABE57E4DB72FEE0033147864012EE3@EALPO1.ukbroadband.com>
	<4DDBBE05.1020800@byronhicks.com>
Message-ID: <4DDBD4D2.6000904@paulgraydon.co.uk>

On 5/24/2011 4:17 AM, Byron L. Hicks wrote:
> On 5/24/2011 9:13 AM, Leigh Porter wrote:
>
>> So you said NO, and what did they do about it ?
> It forced them to put in their own ISDN router, and they put static
> routes on the point of sale terminals that pointed the "borrowed" IP
> space to the ISDN router.  There was no way I was going to put this in
> the routing tables of my campus routers.
>
So rather than fix the real problem, they added an additional bodge?  
Why am I not surprised?

Paul



From darcy at druid.net  Tue May 24 10:56:14 2011
From: darcy at druid.net (D'Arcy J.M. Cain)
Date: Tue, 24 May 2011 11:56:14 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
	<0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
Message-ID: <20110524115614.fcde3510.darcy@druid.net>

On Tue, 24 May 2011 08:42:45 -0700
Joel Jaeggli <joelja at bogus.com> wrote:
> It's been a while since we fought a war with canada.
> 
> http://en.wikipedia.org/wiki/Pig_War

Should we start locking up our pigs?

Then there was the War of 1812 where both side claimed to have won thus
starting the age of spin doctoring.

-- 
D'Arcy J.M. Cain <darcy at druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.



From mksmith at adhost.com  Tue May 24 10:59:40 2011
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 24 May 2011 15:59:40 +0000
Subject: New vyatta-nsp list
Message-ID: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>

Hello All:

There is a new Vyatta NSP list, sponsored by Jared on puck.nether.net.  If you are running Vyatta hardware and/or software please join and share your questions, comments and experiences.

http://puck.nether.net/mailman/listinfo/vyatta-nsp

Regards,

Mike



From cb.list6 at gmail.com  Tue May 24 11:07:21 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 24 May 2011 09:07:21 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <4DDBD4D2.6000904@paulgraydon.co.uk>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<4DDBBAF9.7010306@byronhicks.com>
	<D181DDABABE57E4DB72FEE0033147864012EE3@EALPO1.ukbroadband.com>
	<4DDBBE05.1020800@byronhicks.com>
	<4DDBD4D2.6000904@paulgraydon.co.uk>
Message-ID: <BANLkTikkwMSBEZZAWq8UUGAoMzEyE-WRqg@mail.gmail.com>

On Tue, May 24, 2011 at 8:54 AM, Paul Graydon <paul at paulgraydon.co.uk> wrote:
> On 5/24/2011 4:17 AM, Byron L. Hicks wrote:
>>
>> On 5/24/2011 9:13 AM, Leigh Porter wrote:
>>
>>> So you said NO, and what did they do about it ?
>>
>> It forced them to put in their own ISDN router, and they put static
>> routes on the point of sale terminals that pointed the "borrowed" IP
>> space to the ISDN router. ?There was no way I was going to put this in
>> the routing tables of my campus routers.
>>
> So rather than fix the real problem, they added an additional bodge? ?Why am
> I not surprised?
>

There is no fixing the lack of IPv4, just more band-aids.  IPv4 has
been scarce for the last 10 years that i have been in this industry.
I remember one of my first jobs was assigning IP addresses to
customers at an ISP .... and people on the other end of the phone
throwing chairs in anger because they can't launch their web site
until i received their detailed justification for more ipv4 addresses.
 That was 10 years ago.

Yes, the issue before was people being lazy and not wanting to do the
paper work or working the system (because IPv4 was scarce then too).
Now, there is legitimately not enough space for folks to deploy IPv4
in fast growing edges of the network like M2M (this includes point of
sale), mobile, cloud, and many other places.... and there is no time
to get in thumb wrestling wars with ARIN over what is used where (boss
wants it done yesterday)

It will get worse before it gets better.

Cameron



From bruns at 2mbit.com  Tue May 24 11:17:02 2011
From: bruns at 2mbit.com (Brielle Bruns)
Date: Tue, 24 May 2011 10:17:02 -0600
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTikkwMSBEZZAWq8UUGAoMzEyE-WRqg@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<5EAD56F4-BB1F-4704-A7A2-283709E7C93F@virtualized.org>
	<61C559FA-FF52-46B2-8CB7-E6D9DD829DFD@delong.com>
	<B2100B46-6D93-46A2-8746-5CFB8BE88AE9@bogus.com>
	<20110524020000.6FA46EF4A47@drugs.dv.isc.org>
	<BANLkTimNQh4iHiDLcEJrgbChtWWFBuPF7Q@mail.gmail.com>
	<1CA19E72-1649-47B1-959A-36EB7C723188@delong.com>
	<4DDBBAF9.7010306@byronhicks.com>
	<D181DDABABE57E4DB72FEE0033147864012EE3@EALPO1.ukbroadband.com>
	<4DDBBE05.1020800@byronhicks.com>
	<4DDBD4D2.6000904@paulgraydon.co.uk>
	<BANLkTikkwMSBEZZAWq8UUGAoMzEyE-WRqg@mail.gmail.com>
Message-ID: <4DDBD9FE.3080008@2mbit.com>

On 5/24/11 10:07 AM, Cameron Byrne wrote:
> There is no fixing the lack of IPv4, just more band-aids.  IPv4 has
> been scarce for the last 10 years that i have been in this industry.
> I remember one of my first jobs was assigning IP addresses to
> customers at an ISP .... and people on the other end of the phone
> throwing chairs in anger because they can't launch their web site
> until i received their detailed justification for more ipv4 addresses.
>   That was 10 years ago.
>
> Yes, the issue before was people being lazy and not wanting to do the
> paper work or working the system (because IPv4 was scarce then too).
> Now, there is legitimately not enough space for folks to deploy IPv4
> in fast growing edges of the network like M2M (this includes point of
> sale), mobile, cloud, and many other places.... and there is no time
> to get in thumb wrestling wars with ARIN over what is used where (boss
> wants it done yesterday)
>
> It will get worse before it gets better.


I think the appropriate phrase here is, "Your lack of planning does not 
constitute an emergency on my part."



-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org



From rubensk at gmail.com  Tue May 24 12:38:01 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 24 May 2011 14:38:01 -0300
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
	<0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
Message-ID: <BANLkTinAnMCPq=N0kCOVC_HU-RED9cPpeQ@mail.gmail.com>

> Is the DoD releasing this range to Rogers? Or has Rogers squatted on
> this space due to exhaustion of their 10/8 use? We've seen other

> Squatting resources from an organization that can deploy F/A-18
> Hornets, F/A-22 Raptors, Predator drones or Navy SEALs is probably bad
> to your health.
>
> It's been a while since we fought a war with canada.
> http://en.wikipedia.org/wiki/Pig_War

I haven't read any formal declaration of war from the US regarding
Pakistan, and that haven't helped an infamous citizen of being killed
there by DoD assets... on the other hand, it's safer for an american
company to squatt DoD number resources than a canadian one, due to
Posse Comitatus.


Rubens



From scubacuda at gmail.com  Tue May 24 12:48:07 2011
From: scubacuda at gmail.com (Rogelio)
Date: Tue, 24 May 2011 14:48:07 -0300
Subject: EAP-SIM authentication for WiFi networks
Message-ID: <BANLkTi=tH55m3rwV2vW=dZa8ei_-XsrHXw@mail.gmail.com>

Can anyone share a working model / solution for EAP-SIM authenticated
smart phones on Wi-Fi networks? (Or even EAP-AKA?)

i.e. instead of having to login a portal with a user / password or
pre-authenticate MAC addresses, have it be seemless if they are
already a subscriber.

AT&T does this with the WISPr client on the iPhones, but I was hoping
for something that worked across the board with Android devices for a
given carrier.

Any suggestions here on who I might talk to?

-- 
Also on LinkedIn?? Feel free to connect if you too are an open
networker: scubacuda at gmail.com



From markk at arin.net  Tue May 24 12:58:56 2011
From: markk at arin.net (Mark Kosters)
Date: Tue, 24 May 2011 17:58:56 +0000
Subject: rwhois website
In-Reply-To: <20110521.155444.41666060.sthaug@nethelp.no>
Message-ID: <CA014EAA.37F03%markk@arin.net>

On 5/21/11 9:54 AM, "sthaug at nethelp.no" <sthaug at nethelp.no> wrote:
>
>The DNS info for rwhois.net is seriously screwed (NS info points to
>ns{1,2}.verisignlabs.com - which don't exist according to the servers
>for verisignlabs.com).
>
>Why do you waste your time on rwhois?

Despite RWhois being really old, creaky, and hard to use; people are using
it and there is no current replacement (Whois-RWS looks extremely
promising). To that end, we are working with VeriSign Inc to migrate the
domain rwhois.net to ARIN. We moved the website to ARIN a couple of years
ago but the domain has not yet made it.

Regards,
Mark
ARIN CTO




From owen at delong.com  Tue May 24 12:59:18 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 24 May 2011 10:59:18 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTinAnMCPq=N0kCOVC_HU-RED9cPpeQ@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
	<0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
	<BANLkTinAnMCPq=N0kCOVC_HU-RED9cPpeQ@mail.gmail.com>
Message-ID: <73AD67C6-CF00-4466-A572-8BE63B11A531@delong.com>


On May 24, 2011, at 10:38 AM, Rubens Kuhl wrote:

>> Is the DoD releasing this range to Rogers? Or has Rogers squatted on
>> this space due to exhaustion of their 10/8 use? We've seen other
> 
>> Squatting resources from an organization that can deploy F/A-18
>> Hornets, F/A-22 Raptors, Predator drones or Navy SEALs is probably bad
>> to your health.
>> 
>> It's been a while since we fought a war with canada.
>> http://en.wikipedia.org/wiki/Pig_War
> 
> I haven't read any formal declaration of war from the US regarding
> Pakistan, and that haven't helped an infamous citizen of being killed
> there by DoD assets... on the other hand, it's safer for an american
> company to squatt DoD number resources than a canadian one, due to
> Posse Comitatus.
> 
> 
> Rubens

I tend to doubt it. I'm pretty sure the DoD has the phone number to
the FBI.

Owen




From Valdis.Kletnieks at vt.edu  Tue May 24 13:09:04 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 24 May 2011 14:09:04 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: Your message of "Tue, 24 May 2011 10:59:18 PDT."
	<73AD67C6-CF00-4466-A572-8BE63B11A531@delong.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
	<0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
	<BANLkTinAnMCPq=N0kCOVC_HU-RED9cPpeQ@mail.gmail.com>
	<73AD67C6-CF00-4466-A572-8BE63B11A531@delong.com>
Message-ID: <14796.1306260544@localhost>

On Tue, 24 May 2011 10:59:18 PDT, Owen DeLong said:

> >> Squatting resources from an organization that can deploy F/A-18
> >> Hornets, F/A-22 Raptors, Predator drones or Navy SEALs is probably bad
> >> to your health.

> I tend to doubt it. I'm pretty sure the DoD has the phone number to
> the FBI.

Yes, but the FBI just shows up with several agents in dark sunglasses and suits
and surgically removed senses of humor.  Bad news, but it still doesn't ruin
your day like a Predator drone suddenly appearing outside your window...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110524/db27055b/attachment.bin>

From carlosm3011 at gmail.com  Tue May 24 13:22:23 2011
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 24 May 2011 13:22:23 -0500
Subject: HIJACKED: AS18466, courtesy of Global Crossing (AS3549)
In-Reply-To: <30315.1305887154@tristatelogic.com>
References: <30315.1305887154@tristatelogic.com>
Message-ID: <BANLkTi=Z5vSPa+=8UyLWR7YJ3N=_AuVgiQ@mail.gmail.com>

Hello Ronald,

<disclaimer>I do work for LACNIC</disclaimer>
<sorry>i'm really late in my NANOG followups</sorry>

> P.P.S. ?Although I have previously bemoaned ARIN's lack of agressivness in
> reclaiming abandoned ASNs and IP blocks that have been hijacked, I feel
> compelled to note that at least they (ARIN) do have a proccess in place
> for doing so, i.e. when and if they are motivated in that direction.
> I have it on good authority however that LACNIC does not even have an
> established process for reclaiming abandoned number resources. ?Given
> that the problem of hijacked number resources, rather than disappearing,
> is in fact accelerating, over time, I do believe that it would behove
> LACNIC and other RiRs to develop processes for reclaiming abandoned
> resources, in particular when and where it becomes evident that these
> resources have been hijacked.

I would like to get in touch with the good authority you mention as
he/she seems to be quite misinformed. LACNIC has, and has applied in
the past, policies and procedures for resource recovery due to
abandonment and other issues.

The original resource recovery policy is LACNIC-2009-06 and the
English text can be found here:
http://www.lacnic.net/en/politicas/manual7-1.html

You can also find the list of recovered prefixes and ASNs here
http://www.lacnic.net/en/registro/revocacion.html

I am not the expert on how the recovery process actually works but I
can get you or the person who mentioned this alleged lack of process
to you in touch with the staff who actually do work with resource
recovery.

regards

Carlos




-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================



From Ed.Lewis at neustar.biz  Tue May 24 13:23:03 2011
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Tue, 24 May 2011 14:23:03 -0400
Subject: Godwin was here ... was Re: Rogers Canada using 7.0.0.0/8
In-Reply-To: <14796.1306260544@localhost>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
	<0E58267B-BA35-4F71-86D1-2D279772A6C2@bogus.com>
	<BANLkTinAnMCPq=N0kCOVC_HU-RED9cPpeQ@mail.gmail.com>
	<73AD67C6-CF00-4466-A572-8BE63B11A531@delong.com>
	<14796.1306260544@localhost>
Message-ID: <a06240800ca01a77228cb@[10.31.200.118]>

In reference to recent messages:

>>  I tend to doubt it. I'm pretty sure the DoD has the phone number to
>>  the FBI.
>
>Yes, but the FBI just shows up with several agents in dark 
>sunglasses and suits
>and surgically removed senses of humor.  Bad news, but it still doesn't ruin
>your day like a Predator drone suddenly appearing outside your window...

http://en.wikipedia.org/wiki/Godwin%27s_Law

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?



From akg1330 at gmail.com  Tue May 24 14:38:04 2011
From: akg1330 at gmail.com (Andrew Gallo)
Date: Tue, 24 May 2011 15:38:04 -0400
Subject: EAP-SIM authentication for WiFi networks
In-Reply-To: <BANLkTi=tH55m3rwV2vW=dZa8ei_-XsrHXw@mail.gmail.com>
References: <BANLkTi=tH55m3rwV2vW=dZa8ei_-XsrHXw@mail.gmail.com>
Message-ID: <4DDC091C.4030609@gmail.com>

On 5/24/2011 1:48 PM, Rogelio wrote:
> Can anyone share a working model / solution for EAP-SIM authenticated
> smart phones on Wi-Fi networks? (Or even EAP-AKA?)
>
> i.e. instead of having to login a portal with a user / password or
> pre-authenticate MAC addresses, have it be seemless if they are
> already a subscriber.
>
> AT&T does this with the WISPr client on the iPhones, but I was hoping
> for something that worked across the board with Android devices for a
> given carrier.
>
> Any suggestions here on who I might talk to?
>
While this may not answer your question directly, I know that JANET &
eduroam just announced EAP-SIM service:

http://billstarnaud.blogspot.com/2011/05/uk-r-network-janet-3g-service.html


Maybe there is some useful information here.



From rhys at rhavenindustrys.com  Tue May 24 14:42:02 2011
From: rhys at rhavenindustrys.com (Rhys Rhaven)
Date: Tue, 24 May 2011 14:42:02 -0500
Subject: New vyatta-nsp list
In-Reply-To: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
Message-ID: <4DDC0A0A.5020304@rhavenindustrys.com>

I had a Juniper sales rep laugh at me when I asked for a comparison of
their SRX series to Vyatta, as he had "never heard of Vyatta."

Anyone have an opinion on Vyatta's software/appliances? Specifically
their 3520 ?


On 05/24/2011 10:59 AM, Michael K. Smith - Adhost wrote:
> Hello All:
>
> There is a new Vyatta NSP list, sponsored by Jared on puck.nether.net.  If you are running Vyatta hardware and/or software please join and share your questions, comments and experiences.
>
> http://puck.nether.net/mailman/listinfo/vyatta-nsp
>
> Regards,
>
> Mike
>




From Valdis.Kletnieks at vt.edu  Tue May 24 14:56:51 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 24 May 2011 15:56:51 -0400
Subject: New vyatta-nsp list
In-Reply-To: Your message of "Tue, 24 May 2011 14:42:02 CDT."
	<4DDC0A0A.5020304@rhavenindustrys.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com>
Message-ID: <20618.1306267011@localhost>

On Tue, 24 May 2011 14:42:02 CDT, Rhys Rhaven said:
> I had a Juniper sales rep laugh at me when I asked for a comparison of
> their SRX series to Vyatta, as he had "never heard of Vyatta."

"Danger, Will Robinson! Danger!" :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110524/924c5128/attachment.bin>

From brent at servuhome.net  Tue May 24 16:26:58 2011
From: brent at servuhome.net (Brent Jones)
Date: Tue, 24 May 2011 14:26:58 -0700
Subject: New vyatta-nsp list
In-Reply-To: <4DDC0A0A.5020304@rhavenindustrys.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com>
Message-ID: <BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>

On Tue, May 24, 2011 at 12:42 PM, Rhys Rhaven <rhys at rhavenindustrys.com> wrote:
> I had a Juniper sales rep laugh at me when I asked for a comparison of
> their SRX series to Vyatta, as he had "never heard of Vyatta."
>
> Anyone have an opinion on Vyatta's software/appliances? Specifically
> their 3520 ?
>
>
> On 05/24/2011 10:59 AM, Michael K. Smith - Adhost wrote:
>> Hello All:
>>
>> There is a new Vyatta NSP list, sponsored by Jared on puck.nether.net. ?If you are running Vyatta hardware and/or software please join and share your questions, comments and experiences.
>>
>> http://puck.nether.net/mailman/listinfo/vyatta-nsp
>>
>> Regards,
>>
>> Mike
>>
>
>
>

Well, with the new Juniper entry level MX devices out now, the cost
difference between Vyatta and Juniper is probably insignificant now,
and with Juniper devices, you have much higher PPS rate.

Granted, I have Vyatta devices now doing BGP, and they work fine, but
you can't argue that ASICs can forward much faster than a general
purpose CPU  :)

To each their own

-- 
Brent Jones
brent at servuhome.net



From joelja at bogus.com  Tue May 24 16:33:31 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 24 May 2011 14:33:31 -0700
Subject: New vyatta-nsp list
In-Reply-To: <20618.1306267011@localhost>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com> <20618.1306267011@localhost>
Message-ID: <A4034337-D61E-455A-94BB-81554F3F026B@bogus.com>


On May 24, 2011, at 12:56 PM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 24 May 2011 14:42:02 CDT, Rhys Rhaven said:
>> I had a Juniper sales rep laugh at me when I asked for a comparison of
>> their SRX series to Vyatta, as he had "never heard of Vyatta."
> 
> "Danger, Will Robinson! Danger!" :)

it's a pretty short drive to redwood city from sunnyvale.




From Vinny_Abello at Dell.com  Tue May 24 16:34:22 2011
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Tue, 24 May 2011 21:34:22 +0000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
Message-ID: <FD9B2CB2B33E394FAE3B7466954760570610073B@DFWX10HMPTC05.AMER.DELL.COM>

I think those within the organization that deploy those vehicles or are Navy
SEALs might sit at different lunch tables than the guys worried about IP
address collisions. ;-)

-Vinny

-----Original Message-----
From: Rubens Kuhl [mailto:rubensk at gmail.com] 
Sent: Tuesday, May 24, 2011 10:57 AM
To: Nanog
Subject: Re: Rogers Canada using 7.0.0.0/8 for internal address space

On Mon, May 23, 2011 at 12:28 PM, Mark Farina <markfarina76 at gmail.com>
wrote:
> As of April 27th I have started to receive dhcp broadcast requests
> originating from the 7.0.0.0/8 network. Based on MAC addresses, it
> seems that this is communication between the Rogers border/node
> hardware (MAC assigned to Cisco) and my Motorola cable modem.
>
> Is the DoD releasing this range to Rogers? Or has Rogers squatted on
> this space due to exhaustion of their 10/8 use? We've seen other
> vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s).
> Could they not wrap their internal cable modem to node chatter in
> IPv6, instead of using assigned address space?

Squatting resources from an organization that can deploy F/A-18
Hornets, F/A-22 Raptors, Predator drones or Navy SEALs is probably bad
to your health.


Rubens

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4991 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110524/3bffb829/attachment.bin>

From joelja at bogus.com  Tue May 24 16:44:23 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 24 May 2011 14:44:23 -0700
Subject: New vyatta-nsp list
In-Reply-To: <BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com>
	<BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
Message-ID: <2CE67B44-690F-440A-8500-4C5BF003F458@bogus.com>


On May 24, 2011, at 2:26 PM, Brent Jones wrote:
> 
> Well, with the new Juniper entry level MX devices out now, the cost
> difference between Vyatta and Juniper is probably insignificant now,
> and with Juniper devices, you have much higher PPS rate.
> 
> Granted, I have Vyatta devices now doing BGP, and they work fine, but
> you can't argue that ASICs can forward much faster than a general
> purpose CPU  :)
> 
> To each their own

So the applications where I've deployed vyatta have a lot to do with having a topological need for a router/firewall/ipsec tunnel termination point in a VM.

Im some cases I'm not particularly proud of the results. but it's not a use case that juniper presently addresses.

devices down in srx210/240/ja2320 land are a rather different keetle of fish in comparision to an mx80/mx240.

 
> -- 
> Brent Jones
> brent at servuhome.net
> 
> 




From jon at nnbfn.net  Tue May 24 16:54:06 2011
From: jon at nnbfn.net (Jon Bane)
Date: Tue, 24 May 2011 17:54:06 -0400
Subject: New vyatta-nsp list
In-Reply-To: <BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com>
	<BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
Message-ID: <BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>

On Tue, May 24, 2011 at 5:26 PM, Brent Jones <brent at servuhome.net> wrote:
>
>
> Well, with the new Juniper entry level MX devices out now, the cost
> difference between Vyatta and Juniper is probably insignificant now,
> and with Juniper devices, you have much higher PPS rate.
>
> Granted, I have Vyatta devices now doing BGP, and they work fine, but
> you can't argue that ASICs can forward much faster than a general
> purpose CPU  :)
>
> To each their own
>
> --
> Brent Jones
> brent at servuhome.net
>
>
I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta
isn't capable of high-end performance.

http://download.intel.com/embedded/processor/solutionbrief/322973.pdf


From if at xip.at  Tue May 24 17:25:06 2011
From: if at xip.at (Ingo Flaschberger)
Date: Wed, 25 May 2011 00:25:06 +0200 (CEST)
Subject: New vyatta-nsp list
In-Reply-To: <BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com>
	<BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
	<BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
Message-ID: <alpine.LRH.2.00.1105250020290.14701@filebunker.xip.at>


> I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta
> isn't capable of high-end performance.
>
> http://download.intel.com/embedded/processor/solutionbrief/322973.pdf

aeh - mpps - mega packets per second - is really low.
and the gbps scale in figure 4 is wrong - factor 10 to high.

1gige linerate:		1,9mpps
10gige linerate:	19mpps

and intel is proud to achieve 1,6mpps at 2 10gige cards?
I have seen higher values at pc hardware - but still not compareable to 
asics.

Kind regards,
 	Ingo Flaschberger




From joelja at bogus.com  Tue May 24 18:31:06 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 24 May 2011 16:31:06 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than
	AnyOther Company
In-Reply-To: <B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
References: <4DD2F087.5050003@gmail.com>
	<BANLkTim6gEyBaZVHd3jVga0gT=ZdRCN9WQ@mail.gmail.com>
	<B925B320C2655641ADBBFC00B1F0B82004754DB5@ukbb3.ukbroadband.com>
Message-ID: <313AD361-7E28-484F-ABD3-696BE310D379@bogus.com>


On May 18, 2011, at 3:06 AM, Leigh Porter wrote:

> 
> 
>> -----Original Message-----
>> From: Carl Rosevear [mailto:crosevear at skytap.com]
>> 
>> "Eating Up" sounds so overweight and unhealthy.  Since a good number
>> of us get paid for delivering bits, isn't this a good thing?  Always
>> glad to see bits and dollars flowing into the Internet, personally.
>> However must express severe dissatisfaction with the topic of the
>> thread a while ago referencing Comcast trying to charge providers for
>> delivery over their network.  Maybe I'm wrong, but I'm pretty happy
>> with the current model...  even if it means a $5/month residential
>> rate hike (or something).
>> 
>> --C
>> 
> 
> Well it depends if Netflix pay for the bandwidth they use or if they get
> it all for free with non settlement peering. If, suddenly, your business
> model breaks because of a huge demand for high bandwidth services by
> your customers then either you need to charge your customers more or
> Netflix (or whoever) need to share the pie.

Netflix is hosted in ec2 and they use a lot of CDN.

not sure that it's germain to the question of access to customers to measure which direction the money changes hands

> --
> Leigh Porter
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> 




From brent at servuhome.net  Tue May 24 18:50:45 2011
From: brent at servuhome.net (Brent Jones)
Date: Tue, 24 May 2011 16:50:45 -0700
Subject: New vyatta-nsp list
In-Reply-To: <BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>
	<4DDC0A0A.5020304@rhavenindustrys.com>
	<BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
	<BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
Message-ID: <BANLkTin8oZe2ZPkBAZVfAxc-QmrBRKdd2A@mail.gmail.com>

On Tue, May 24, 2011 at 2:54 PM, Jon Bane <jon at nnbfn.net> wrote:
> On Tue, May 24, 2011 at 5:26 PM, Brent Jones <brent at servuhome.net> wrote:
>>
>>
>> Well, with the new Juniper entry level MX devices out now, the cost
>> difference between Vyatta and Juniper is probably insignificant now,
>> and with Juniper devices, you have much higher PPS rate.
>>
>> Granted, I have Vyatta devices now doing BGP, and they work fine, but
>> you can't argue that ASICs can forward much faster than a general
>> purpose CPU ?:)
>>
>> To each their own
>>
>> --
>> Brent Jones
>> brent at servuhome.net
>>
>>
> I won't argue that an ASIC isn't faster, but it is hard to argue that Vyatta
> isn't capable of high-end performance.
>
> http://download.intel.com/embedded/processor/solutionbrief/322973.pdf
>

The graphs show near 100% CPU usage at small packet sizes, and low
PPS. That would lead to a pretty easy to launch DDoS against a
software based router platform.
Since there isn't a separation between control plane/forwarding plane,
an attacker could trivially take you offline. I'd imagine due to the
nature of x86 platform, being interrupt based and forwarding table
residing in memory the CPU has to access, theres a finite amount you
can scale this without risking big disruptions from a relatively small
DDoS.

Not saying software platforms can't achieve good throughput, there has
to be a realization of the limits of the platform, and when it
shouldn't be used.
Again, I personally use the Vyatta commercial software, and it works
great, so I'm not knocking it. But I wouldn't consider it high-end
performance when a few million PPS can lead to service disruptions.

-- 
Brent Jones
brent at servuhome.net



From perldork at webwizarddesign.com  Tue May 24 19:12:31 2011
From: perldork at webwizarddesign.com (Max)
Date: Tue, 24 May 2011 20:12:31 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <201105191822.p4JIMYr9065308@mail.r-bonomi.com>
References: <4DD431B6.3030402@2mbit.com>
	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>
Message-ID: <BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>

Was PBS one of the companies you are referring to?  A colleague of
mine worked as a developer on a project at PBS in the 90s that used
the blanking interval for Internet transmissio - very cool stuff.

On 5/19/11, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Wed May 18 16:12:17
>> 2011
>> Date: Wed, 18 May 2011 14:53:10 -0600
>> From: Brielle Bruns <bruns at 2mbit.com>
>> To: nanog at nanog.org
>> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than
>> Any
>> 	Other Company
>>
>> On 5/18/11 2:33 PM, Dorn Hetzel wrote:
>> > If we're really talking efficiency, the "popular" stuff should probably
>> > stream out over the bird of your choice (directv, etc) because it's
>> > hard to beat millions of dishes and dvr's and no cable plant.
>> >
>> > Then what won't fit on the bird goes unicast IP from the nearest CDN.
>> > Kind of like the "on demand over broadband" on my satellite box.  Their
>> > selection sucks, but the model is valid.
>>
>>
>>
>> If someone hadn't mentioned already, there used to be a usenet provider
>> that delivered a full feed via Satellite.
>
> There were, at different times, two companies that did that.  Both went
> under because expenses exceeded income.
>
> The one that was _much_ more interesting was the one that Lauren Weinstein
> had a hand in.  It piggy-backed a Usenet feed in the vertical blanking
> interval of several big "independant" TV stations -- ones that were
> carried by practically every cable company in the country.  Distribution
> to the cable companies was via satellite, but the USENET feed, being
> _part_ of the video signal, consumed _zero_ additional bandwidth, and
> rode the satellite links for free.
>
> To get the feed, all you needed was a TV tuner with 'video out', and the
> purpose-huilt decoder box that extracted the vertical interval data.
>
> This service died as the independants moved to encrypted transmission,
> because the encryption did _not_ perserve anything in the 'blanking'
> timeslot. only the 'viewable' field-image was trasmitted, _as_ a full-field
> image.  Sync, blanking, etc. was _locally_ generated on the receiving end.
>
> An "elegant" idea, done in by changing technology.   *sigh*
>
>
>
>



From robert at gdk.org  Tue May 24 19:16:43 2011
From: robert at gdk.org (Robert Bays)
Date: Tue, 24 May 2011 17:16:43 -0700
Subject: New vyatta-nsp list
In-Reply-To: <alpine.LRH.2.00.1105250020290.14701@filebunker.xip.at>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan>	<4DDC0A0A.5020304@rhavenindustrys.com>	<BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>	<BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
	<alpine.LRH.2.00.1105250020290.14701@filebunker.xip.at>
Message-ID: <4DDC4A6B.9000808@gdk.org>

On 5/24/11 3:25 PM, Ingo Flaschberger wrote:
> 
>> I won't argue that an ASIC isn't faster, but it is hard to argue that
>> Vyatta
>> isn't capable of high-end performance.
>>
>> http://download.intel.com/embedded/processor/solutionbrief/322973.pdf
> 
> aeh - mpps - mega packets per second - is really low.
> and the gbps scale in figure 4 is wrong - factor 10 to high.
> 
> 1gige linerate:        1,9mpps
> 10gige linerate:    19mpps
> 
> and intel is proud to achieve 1,6mpps at 2 10gige cards?
> I have seen higher values at pc hardware - but still not compareable to
> asics.

Intel is capable of more.  See slide 29 from this presentation at IDF
2011 in Beijing.

"New System Approach to Network Platform Architecture"
Yang Tao & Fu Lizheng

https://intel.wingateweb.com/bj11/scheduler/downloadFileCounting.do?sesfid=6DD9DF1ECE719E98767AD5F48E55C119&abb=7638E050E5ED339FE5FB858DB2C16FE9&fn=3649EFF0820DCB079BC4C8A0B1A45ECFDA3BEED134DD5284300AD0E9EA5C516A



From mysidia at gmail.com  Tue May 24 20:29:16 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 24 May 2011 20:29:16 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <FD9B2CB2B33E394FAE3B7466954760570610073B@DFWX10HMPTC05.AMER.DELL.COM>
References: <BANLkTikYoyyO+3kX7V9rP8=VKqVhEECoug@mail.gmail.com>
	<BANLkTimctc9DJ+2z0Urehg6JQwgRqSLBdA@mail.gmail.com>
	<FD9B2CB2B33E394FAE3B7466954760570610073B@DFWX10HMPTC05.AMER.DELL.COM>
Message-ID: <BANLkTikrB6zEDMjk2EMQA0QR5KtQvevFKQ@mail.gmail.com>

On Tue, May 24, 2011 at 4:34 PM,  <Vinny_Abello at dell.com> wrote:
> I think those within the organization that deploy those vehicles or are Navy
> SEALs might sit at different lunch tables than the guys worried about IP
> address collisions. ;-)

The F/A-18  Hornets, F/A-22 Raptors are well, and good, but that's old
technology.
The folks in charge of the MQ-1 predator drones might sit closer to the guys
worried about the IP addresses.

And automated drone strikes can always be blamed on a malfunction caused by
the hijacking


I would speculate they are probably capable of targetting routers improperly
using their subnet, if the right folks feel it's necessary,  and the
routers are located
in the right country.


I suspect they're more likely to attempt the more civilized
professional things any
other government org would though,  such as calling the hijacker's NOC,
calling upstreams to de-peer the hijacker,  sending out field agents
to have a little
'chat'....


> -Vinny
--
-JH



From jra at baylink.com  Tue May 24 20:29:06 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 24 May 2011 21:29:06 -0400 (EDT)
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTikrB6zEDMjk2EMQA0QR5KtQvevFKQ@mail.gmail.com>
Message-ID: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jimmy Hess" <mysidia at gmail.com>

> On Tue, May 24, 2011 at 4:34 PM, <Vinny_Abello at dell.com> wrote:
> > I think those within the organization that deploy those vehicles or
> > are Navy SEALs might sit at different lunch tables than the guys worried
> > about IP address collisions. ;-)
> 
> The F/A-18 Hornets, F/A-22 Raptors are well, and good, but that's old
> technology The folks in charge of the MQ-1 predator drones might sit closer to
> the guys worried about the IP addresses.
> 
> And automated drone strikes can always be blamed on a malfunction
> caused by the hijacking

If packets that control armed drones cross any router that has access even to 
SIPRnet, much less the Internet, someone's getting relieved.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From smb at cs.columbia.edu  Tue May 24 21:48:57 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 24 May 2011 22:48:57 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
References: <4DD431B6.3030402@2mbit.com>
	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>
	<BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
Message-ID: <1B9ED1F9-AA5B-4627-89D6-B0B637344F8A@cs.columbia.edu>

It was TBS, in the 1980s: http://web.archive.org/web/19981203103811/www.stargate.com/history.html

It used TBS because that was one of the first "superstations", distributed 
to cable systems nationwide via satellite.

On May 24, 2011, at 8:12 31PM, Max wrote:

> Was PBS one of the companies you are referring to?  A colleague of
> mine worked as a developer on a project at PBS in the 90s that used
> the blanking interval for Internet transmissio - very cool stuff.
> 
> On 5/19/11, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>>> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Wed May 18 16:12:17
>>> 2011
>>> Date: Wed, 18 May 2011 14:53:10 -0600
>>> From: Brielle Bruns <bruns at 2mbit.com>
>>> To: nanog at nanog.org
>>> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than
>>> Any
>>> 	Other Company
>>> 
>>> On 5/18/11 2:33 PM, Dorn Hetzel wrote:
>>>> If we're really talking efficiency, the "popular" stuff should probably
>>>> stream out over the bird of your choice (directv, etc) because it's
>>>> hard to beat millions of dishes and dvr's and no cable plant.
>>>> 
>>>> Then what won't fit on the bird goes unicast IP from the nearest CDN.
>>>> Kind of like the "on demand over broadband" on my satellite box.  Their
>>>> selection sucks, but the model is valid.
>>> 
>>> 
>>> 
>>> If someone hadn't mentioned already, there used to be a usenet provider
>>> that delivered a full feed via Satellite.
>> 
>> There were, at different times, two companies that did that.  Both went
>> under because expenses exceeded income.
>> 
>> The one that was _much_ more interesting was the one that Lauren Weinstein
>> had a hand in.  It piggy-backed a Usenet feed in the vertical blanking
>> interval of several big "independant" TV stations -- ones that were
>> carried by practically every cable company in the country.  Distribution
>> to the cable companies was via satellite, but the USENET feed, being
>> _part_ of the video signal, consumed _zero_ additional bandwidth, and
>> rode the satellite links for free.
>> 
>> To get the feed, all you needed was a TV tuner with 'video out', and the
>> purpose-huilt decoder box that extracted the vertical interval data.
>> 
>> This service died as the independants moved to encrypted transmission,
>> because the encryption did _not_ perserve anything in the 'blanking'
>> timeslot. only the 'viewable' field-image was trasmitted, _as_ a full-field
>> image.  Sync, blanking, etc. was _locally_ generated on the receiving end.
>> 
>> An "elegant" idea, done in by changing technology.   *sigh*
>> 
>> 
>> 
>> 
> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From lou at metron.com  Tue May 24 21:48:07 2011
From: lou at metron.com (Lou Katz)
Date: Tue, 24 May 2011 19:48:07 -0700
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
References: <4DD431B6.3030402@2mbit.com>
	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>
	<BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
Message-ID: <20110525024807.GA56549@metron.com>

On Tue, May 24, 2011 at 08:12:31PM -0400, Max wrote:
> Was PBS one of the companies you are referring to?  A colleague of
> mine worked as a developer on a project at PBS in the 90s that used
> the blanking interval for Internet transmissio - very cool stuff.
> 
<snip>

> > The one that was _much_ more interesting was the one that Lauren Weinstein
> > had a hand in.  It piggy-backed a Usenet feed in the vertical blanking
> > interval of several big "independant" TV stations -- ones that were
> > carried by practically every cable company in the country.  Distribution
> > to the cable companies was via satellite, but the USENET feed, being
> > _part_ of the video signal, consumed _zero_ additional bandwidth, and
> > rode the satellite links for free.
> >
> > To get the feed, all you needed was a TV tuner with 'video out', and the
> > purpose-huilt decoder box that extracted the vertical interval data.
> >
> > This service died as the independants moved to encrypted transmission,
> > because the encryption did _not_ perserve anything in the 'blanking'
> > timeslot. only the 'viewable' field-image was trasmitted, _as_ a full-field
> > image.  Sync, blanking, etc. was _locally_ generated on the receiving end.
> >
> > An "elegant" idea, done in by changing technology.   *sigh*
> >

As USENIX director I sponsored and sheparded this project, called "Stargate".
We at least got bits into the blanking interval at WTBS in Altanta.

-- 

-=[L]=-
Hand typed on my Remington portable

Real data are normal in the middle and Cauchy in the tails.



From smb at cs.columbia.edu  Tue May 24 21:50:10 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 24 May 2011 22:50:10 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
Message-ID: <9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>


On May 24, 2011, at 9:29 06PM, Jay Ashworth wrote:

> ----- Original Message -----
>> From: "Jimmy Hess" <mysidia at gmail.com>
> 
>> On Tue, May 24, 2011 at 4:34 PM, <Vinny_Abello at dell.com> wrote:
>>> I think those within the organization that deploy those vehicles or
>>> are Navy SEALs might sit at different lunch tables than the guys worried
>>> about IP address collisions. ;-)
>> 
>> The F/A-18 Hornets, F/A-22 Raptors are well, and good, but that's old
>> technology The folks in charge of the MQ-1 predator drones might sit closer to
>> the guys worried about the IP addresses.
>> 
>> And automated drone strikes can always be blamed on a malfunction
>> caused by the hijacking
> 
> If packets that control armed drones cross any router that has access even to 
> SIPRnet, much less the Internet, someone's getting relieved.

http://www.eweek.com/c/a/Security/Militants-Hack-Unencrypted-Drone-Feeds-477219/

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From gbonser at seven.com  Tue May 24 21:52:37 2011
From: gbonser at seven.com (George Bonser)
Date: Tue, 24 May 2011 19:52:37 -0700
Subject: New vyatta-nsp list
In-Reply-To: <BANLkTin8oZe2ZPkBAZVfAxc-QmrBRKdd2A@mail.gmail.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan><4DDC0A0A.5020304@rhavenindustrys.com><BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com><BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
	<BANLkTin8oZe2ZPkBAZVfAxc-QmrBRKdd2A@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3439@RWC-EX1.corp.seven.com>

> The graphs show near 100% CPU usage at small packet sizes, and low
> PPS. That would lead to a pretty easy to launch DDoS against a
> software based router platform.
> Since there isn't a separation between control plane/forwarding plane,
> an attacker could trivially take you offline. I'd imagine due to the
> nature of x86 platform, being interrupt based and forwarding table
> residing in memory the CPU has to access, theres a finite amount you
> can scale this without risking big disruptions from a relatively small
> DDoS.
> 
> Not saying software platforms can't achieve good throughput, there has
> to be a realization of the limits of the platform, and when it
> shouldn't be used.
> Again, I personally use the Vyatta commercial software, and it works
> great, so I'm not knocking it. But I wouldn't consider it high-end
> performance when a few million PPS can lead to service disruptions.
> 
> --
> Brent Jones
> brent at servuhome.net

Every tool has its use.  Also, they have several different sized
appliances.   How much CPU use you get depends on how many cores you
throw at the problem.  They can use multiple cores/processors.  The
result given in one test might not match someone else's test if they
have higher end hardware, maybe better than the appliances Vyatta ships.

But the primary point I am trying to make is if you have an office with
sub-gigabit connectivity and you need NAT and firewalling and VPNs, it
might be a very cost-effective solution.   It might not be a good
solution in a different environment.  It is sort of like pointing out
that your neighbor's Accord doesn't have the performance characteristics
of a Ferrari but your neighbor only drives in rush hour on roads with a
maximum speed of 65 MPH.  The Ferrari would cost much more money, cost
more to support over time, and not get him to work any faster.

If one is never going to pass enough traffic to get anywhere near the
maximum performance of the unit anyway, why spend so much more money?
Besides, on most integrated firewall/NAT/VPN units I have used in the
past, I have run them out of CPU from VPN and NAT long before they ever
reached their maximum traffic throughput.





From morrowc.lists at gmail.com  Tue May 24 22:12:41 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 24 May 2011 23:12:41 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <20110525024807.GA56549@metron.com>
References: <4DD431B6.3030402@2mbit.com>
	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>
	<BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
	<20110525024807.GA56549@metron.com>
Message-ID: <BANLkTim05DFir+ftAP-_nxPnt1o2+X7RQA@mail.gmail.com>

On Tue, May 24, 2011 at 10:48 PM, Lou Katz <lou at metron.com> wrote:
>> >
>> > An "elegant" idea, done in by changing technology. ? *sigh*
>> >
>
> As USENIX director I sponsored and sheparded this project, called "Stargate".
> We at least got bits into the blanking interval at WTBS in Altanta.

So... would this have been feasible today? given the bandwidth
required to send a full feed these days, i suspect likely not, eh?
(even if you were able to do it on all 500+ channels in parallel)



From jra at baylink.com  Tue May 24 22:14:56 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 24 May 2011 23:14:56 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTim05DFir+ftAP-_nxPnt1o2+X7RQA@mail.gmail.com>
Message-ID: <3850133.642.1306293296191.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Christopher Morrow" <morrowc.lists at gmail.com>

> On Tue, May 24, 2011 at 10:48 PM, Lou Katz <lou at metron.com> wrote:
> >> > An "elegant" idea, done in by changing technology. *sigh*
> >
> > As USENIX director I sponsored and sheparded this project, called
> > "Stargate".
> > We at least got bits into the blanking interval at WTBS in Altanta.
> 
> So... would this have been feasible today? given the bandwidth
> required to send a full feed these days, i suspect likely not, eh?
> (even if you were able to do it on all 500+ channels in parallel)

I can't tell you whether it would be feasible from a *quantity* standpoint
unless you specify what your group list is -- big 7 text?  Probably.

Problem is, it depended (as he noted) on a peculiarity of the network TV 
environment at the time: it wasn't part of the signal, but of the *transport*
which -- at the time -- was carried around along with the signal, so you
could piggyback stuff there, and get it right to people's TVs.  MPEG2 and 4
don't carry the vertical interval, so any ride you can get isn't free --
rather similar to our Multicast discussion last week.

Back in the really bad old days, I'm told that the most stable frequency 
source the average civilian could get was the 3.58MHz oscillator in a
color TV set -- but *only* when you were watching *network* programs, at
which time that oscillator was effectively phase-locked to a $50k+ black
burst generator at network master control.

Frame synchronizers shot that plan out of the water.

Never been sure if that's apocryphal or not.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jbaino at gmail.com  Tue May 24 22:22:20 2011
From: jbaino at gmail.com (Jeremy)
Date: Tue, 24 May 2011 22:22:20 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
Message-ID: <BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>

Please excuse my ignorance on this and note that I am not condoning the
hijacking of IP address space.

As long as necessary precautions are taken (route filters, tunnels, VRF's)
shouldn't this be technically feasible without any negative ramifications?

These 7-NET address seem to be assigned to the modem itself, but surely they
aren't what the customer sees at thier WAN IP address right? So as long as
the modem is configured to send ALL traffic, regardless of destination
address (could be a 7NET dst) over a GRE tunnel to some aggregation point
via its acquired 7-net address and all routers were to keep the 7net on a
separate VRF, shouldn't they be able to avoid any IP collisions? Couldn't
you theoretically use anyone's IP space, advertised or not, for this
internal transit? I'm not saying it's a good idea, it's certainly more
complex which leads to its own issues, but shouldn't it be possible?

-Jeremy

On Tue, May 24, 2011 at 9:50 PM, Steven Bellovin <smb at cs.columbia.edu>wrote:

>
> On May 24, 2011, at 9:29 06PM, Jay Ashworth wrote:
>
> > ----- Original Message -----
> >> From: "Jimmy Hess" <mysidia at gmail.com>
> >
> >> On Tue, May 24, 2011 at 4:34 PM, <Vinny_Abello at dell.com> wrote:
> >>> I think those within the organization that deploy those vehicles or
> >>> are Navy SEALs might sit at different lunch tables than the guys
> worried
> >>> about IP address collisions. ;-)
> >>
> >> The F/A-18 Hornets, F/A-22 Raptors are well, and good, but that's old
> >> technology The folks in charge of the MQ-1 predator drones might sit
> closer to
> >> the guys worried about the IP addresses.
> >>
> >> And automated drone strikes can always be blamed on a malfunction
> >> caused by the hijacking
> >
> > If packets that control armed drones cross any router that has access
> even to
> > SIPRnet, much less the Internet, someone's getting relieved.
>
>
> http://www.eweek.com/c/a/Security/Militants-Hack-Unencrypted-Drone-Feeds-477219/
>
>                --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
>


From oberman at es.net  Tue May 24 22:38:16 2011
From: oberman at es.net (Kevin Oberman)
Date: Tue, 24 May 2011 20:38:16 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space 
In-Reply-To: Your message of "Tue, 24 May 2011 00:22:36 EDT."
	<17520.1306210956@localhost> 
Message-ID: <20110525033816.E87C41CC0B@ptavv.es.net>

> From: Valdis.Kletnieks at vt.edu
> Date: Tue, 24 May 2011 00:22:36 -0400
> 
> On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said:
> 
> > Now, the onus is on the DoD to make its content available over unique
> > IPv6 space so that the Roger's customers can get to it using the
> > 6to4-PMT solution.  There is always a solution.
> 
> Which they should be ready to do already, since didn't the US Govt.
> mandate IPv6 support sometime last century? ;)

Not really. "Backbone networks" were required tobe IPv6 capable back
last decade, but no requirement for any end systems or services. (Nor
was "backbone network" defined.)

By October 1, 2012 all public services (web, mail, and DNS) must be IPv6
capable and reachable using native IPv6 via all carriers being used for
public access. By October 1, 2014 all U.S. government services and
networks must support IPv6.

No tunnels. No special names for IPv6 services. It also includes any
government sponsored services that are contracted out and government
laboratories.

Both some DOD and civilian network have been IPv6 capable for some
years, there was no requirement for it.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



From Valdis.Kletnieks at vt.edu  Tue May 24 22:45:27 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 24 May 2011 23:45:27 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: Your message of "Tue, 24 May 2011 22:22:20 CDT."
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
Message-ID: <12236.1306295127@localhost>

On Tue, 24 May 2011 22:22:20 CDT, Jeremy said:
> As long as necessary precautions are taken (route filters, tunnels, VRF's)
> shouldn't this be technically feasible without any negative ramifications?

The types of network designers who are able to cover *every single* little
detail needed to make this sort of thing work are rarely the types of network
designers that would snarf up somebody else's prefix to use for this sort of
thing, and vice versa.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110524/bfde44f1/attachment.bin>

From cb.list6 at gmail.com  Tue May 24 23:04:21 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 24 May 2011 21:04:21 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <12236.1306295127@localhost>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<12236.1306295127@localhost>
Message-ID: <BANLkTi=b5-gM6R4u=fQh3-fUr=jGHKavfQ@mail.gmail.com>

On Tue, May 24, 2011 at 8:45 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 24 May 2011 22:22:20 CDT, Jeremy said:
>> As long as necessary precautions are taken (route filters, tunnels, VRF's)
>> shouldn't this be technically feasible without any negative ramifications?
>
> The types of network designers who are able to cover *every single* little
> detail needed to make this sort of thing work are rarely the types of network
> designers that would snarf up somebody else's prefix to use for this sort of
> thing, and vice versa.

I think you underestimate how truly common this practice is in private
corners of large networks.  I did not say good, but i did say common.
And, it will become increasingly common.  Look down on it as much as
you want, but it is the reality.  Squatting on (currently) unrouted
space is the new NAT.

CB
CB



From perldork at webwizarddesign.com  Tue May 24 23:04:30 2011
From: perldork at webwizarddesign.com (Max)
Date: Wed, 25 May 2011 00:04:30 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <1B9ED1F9-AA5B-4627-89D6-B0B637344F8A@cs.columbia.edu>
References: <4DD431B6.3030402@2mbit.com>
	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>
	<BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
	<1B9ED1F9-AA5B-4627-89D6-B0B637344F8A@cs.columbia.edu>
Message-ID: <BANLkTi=Ji10xQDsNYnYbZXBosHFX6M2J9w@mail.gmail.com>

On Tue, May 24, 2011 at 10:48 PM, Steven Bellovin <smb at cs.columbia.edu> wrote:
> It was TBS, in the 1980s: http://web.archive.org/web/19981203103811/www.stargate.com/history.html
>
> It used TBS because that was one of the first "superstations", distributed
> to cable systems nationwide via satellite.

oops - meant TBS :), that was it.

- Max



From wavetossed at googlemail.com  Wed May 25 00:25:43 2011
From: wavetossed at googlemail.com (Michael Dillon)
Date: Wed, 25 May 2011 06:25:43 +0100
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
Message-ID: <BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>

On 25 May 2011 04:22, Jeremy <jbaino at gmail.com> wrote:
> Please excuse my ignorance on this and note that I am not condoning the
> hijacking of IP address space.
>
> As long as necessary precautions are taken (route filters, tunnels, VRF's)
> shouldn't this be technically feasible without any negative ramifications?

And that is why the US military is unlikely to contact anyone at Rogers.

Lots of other companies have hijacked space like this. As I recall,
Reuters global networks began using 7/8 (along with a whole bunch of
other low numbered /8's), back in the mid 90's and nobody has
complained about that.

This kind of thing is becoming more common as more companies exhaust
the RFC 1918 space, and the DOD addresses are the prime target for
this "borrowing" activity because most folks feel that the DOD isn't
likely to run into any technical networking problems with this
"borrowing".

So we should CONDONE such borrowing and recommend a couple of /8s to
use in North America. Perhaps one could be DOD for those operators
that do not carry any DOD traffic and one could be that /8 from
Softbank Japan, 126/8 if I recall it correctly. People who carry DOD
traffic could borrow the APNIC block.

This actually reduces the pressure on the IPv4 address supply without
expensive carrier grade NAT services and makes the transition to IPv6
less turbulent.

--Michael Dillon



From sthaug at nethelp.no  Wed May 25 01:10:23 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 25 May 2011 08:10:23 +0200 (CEST)
Subject: New vyatta-nsp list
In-Reply-To: <alpine.LRH.2.00.1105250020290.14701@filebunker.xip.at>
References: <BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com>
	<BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
	<alpine.LRH.2.00.1105250020290.14701@filebunker.xip.at>
Message-ID: <20110525.081023.74671208.sthaug@nethelp.no>

<nitpicking>

> 1gige linerate:		1,9mpps
> 10gige linerate:	19mpps
> 
> and intel is proud to achieve 1,6mpps at 2 10gige cards?
> I have seen higher values at pc hardware - but still not compareable to 
> asics.

If you're going to specify line rate pps, please get the figures right.
Line rate on GigE with minimum packet size (84 bytes including Ethernet
headers, FCS, 8 byte preamble and 12 byte IFG) is:

1,000,000,000 / (84 * 8) = 1.488 Mpps

</nitpicking>

Steinar Haug, Nethelp consulting, sthaug at nethelp.no



From surfer at mauigateway.com  Wed May 25 02:23:54 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 25 May 2011 00:23:54 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
Message-ID: <20110525002354.B9629B48@resin18.mta.everyone.net>



--- wavetossed at googlemail.com wrote:
So we should CONDONE such borrowing and recommend a couple of /8s to
use in North America. Perhaps one could be DOD for those operators
----------------------------------------


Yes, so it turns IPv4 into such a big steaming pile that every one goes to IPv6 to "get clean" and get their lives back from all the ugly IPv4 troubleshooting.  

>;-)    <== evil grin
scott



From joly at punkcast.com  Wed May 25 03:00:13 2011
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 25 May 2011 04:00:13 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTi=Ji10xQDsNYnYbZXBosHFX6M2J9w@mail.gmail.com>
References: <4DD431B6.3030402@2mbit.com>
	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>
	<BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>
	<1B9ED1F9-AA5B-4627-89D6-B0B637344F8A@cs.columbia.edu>
	<BANLkTi=Ji10xQDsNYnYbZXBosHFX6M2J9w@mail.gmail.com>
Message-ID: <BANLkTimNZqhrmNVQc+xaKbh4HtLcRyQJog@mail.gmail.com>

See also: UK efforts

http://en.wikipedia.org/wiki/Prestel

<http://en.wikipedia.org/wiki/Prestel>j

On Wed, May 25, 2011 at 12:04 AM, Max <perldork at webwizarddesign.com> wrote:

> On Tue, May 24, 2011 at 10:48 PM, Steven Bellovin <smb at cs.columbia.edu>
> wrote:
> > It was TBS, in the 1980s:
> http://web.archive.org/web/19981203103811/www.stargate.com/history.html
> >
> > It used TBS because that was one of the first "superstations",
> distributed
> > to cable systems nationwide via satellite.
>
> oops - meant TBS :), that was it.
>
> - Max
>
>


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From bonomi at mail.r-bonomi.com  Wed May 25 03:47:31 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 25 May 2011 03:47:31 -0500 (CDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTim05DFir+ftAP-_nxPnt1o2+X7RQA@mail.gmail.com>
Message-ID: <201105250847.p4P8lVH9045399@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Tue May 24 22:12:57 2011
> Date: Tue, 24 May 2011 23:12:41 -0400
> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any
> 	Other Company
> From: Christopher Morrow <morrowc.lists at gmail.com>
> To: nanog at nanog.org
>
> On Tue, May 24, 2011 at 10:48 PM, Lou Katz <lou at metron.com> wrote:
> >> >
> >> > An "elegant" idea, done in by changing technology.   *sigh*
> >> >
> >
> > As USENIX director I sponsored and sheparded this project, called 
> > "Stargate". We at least got bits into the blanking interval at WTBS in 
> > Altanta.
>
> So... would this have been feasible today? given the bandwidth required 
> to send a full feed these days, i suspect likely not, eh? (even if you 
> were able to do it on all 500+ channels in parallel)

On the financial side, it is trivial.

On the engineering side, _impossible_.  Modern satellite feeds of NTSC
(analog) TV signals use compressed digital representations of only the 
image portion of each 'field' of the video stream.  Sync and blanking 
signals are _not_ transmitted; rather they are re-generated locally 
when the satellite stream is converted back to an NTSC analog signal.
Thus, even if you were to inject data in the vertical interval, it 
would be stripped before satellite uplink, and not recoverable at the
receiving side.

It's been a *LONG* time since I dealt with the data bandwith available
in the vertical interval, but, as I recall, the "raw' capacity is on the
same order as a DS-0.  *but* you have to deduct overhead for framing,
FEC, etc, as well as multiple redundant transmissions of each data 'packet'.  

To pick a conservative number, say you get an effective throughput of
2k bytes/sec,  That is roughly 150mbyte/day. That _might_ suffice for
a text-only, 'Big-8' only, feed..

As I understand it, a current USENET 'full feed', including binaries, take
two dedicated 100mbit FDX fast ethernet links, and they are saturated _most_
of the day.  At that rate, A full day of TV vertical interval transmission
wuould handle under _ten_seconds_ worth of the inbound traffic.  You would
around =ten=thousand= analog TV channels to handle a contemporary 'full
feed'.





From bonomi at mail.r-bonomi.com  Wed May 25 04:10:28 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 25 May 2011 04:10:28 -0500 (CDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <3850133.642.1306293296191.JavaMail.root@benjamin.baylink.com>
Message-ID: <201105250910.p4P9ASef045482@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Tue May 24 22:19:18 2011
> Date: Tue, 24 May 2011 23:14:56 -0400 (EDT)
> From: Jay Ashworth <jra at baylink.com>
> To: NANOG <nanog at nanog.org>
> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any
> 	Other Company
>
> ----- Original Message -----
> > From: "Christopher Morrow" <morrowc.lists at gmail.com>
>
> > On Tue, May 24, 2011 at 10:48 PM, Lou Katz <lou at metron.com> wrote:
> > >> > An "elegant" idea, done in by changing technology. *sigh*
> > >
> > > As USENIX director I sponsored and sheparded this project, called
> > > "Stargate".
> > > We at least got bits into the blanking interval at WTBS in Altanta.
> >
> > So... would this have been feasible today? given the bandwidth required 
> > to send a full feed these days, i suspect likely not, eh? (even if you 
> > were able to do it on all 500+ channels in parallel)
>
> I can't tell you whether it would be feasible from a *quantity* 
> standpoint unless you specify what your group list is -- big 7 text?  
> Probably.
>
> Problem is, it depended (as he noted) on a peculiarity of the network TV 
> environment at the time: it wasn't part of the signal, but of the 
> *transport* which -- at the time -- was carried around along with the 
> signal, so you could piggyback stuff there, and get it right to people's 
> TVs.  MPEG2 and 4 don't carry the vertical interval, so any ride you can 
> get isn't free -- rather similar to our Multicast discussion last week.
>
> Back in the really bad old days, I'm told that the most stable frequency 
> source the average civilian could get was the 3.58MHz oscillator in a 
> color TV set -- but *only* when you were watching *network* programs, at 
> which time that oscillator was effectively phase-locked to a $50k+ black 
> burst generator at network master control.
>
> Frame synchronizers shot that plan out of the water.
>
> Never been sure if that's apocryphal or not.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink                       
> jra at baylink.com Designer                     The Things I Think           
>             RFC 2100 Ashworth & Associates     http://baylink.pitas.com   
>       2000 Land Rover DII St Petersburg FL USA      
> http://photo.imageinc.us             +1 727 647 1274
>



From brandon at rd.bbc.co.uk  Wed May 25 04:19:09 2011
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Wed, 25 May 2011 10:19:09 +0100 (BST)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
Message-ID: <201105250919.KAA10689@sunf10.rd.bbc.co.uk>

> > So... would this have been feasible today? given the bandwidth required 
> > to send a full feed these days, i suspect likely not, eh? (even if you 
> > were able to do it on all 500+ channels in parallel)
> 
> On the financial side, it is trivial.

The opposite, the bits were paid for but unused back then so
financially it was worth using them. In digital tv every bit has a use
and so a cost, hence they are used for more TV channels instead for
parasitic services. You end up competing with TV if you want any
quantity so hard to make viable today.

> On the engineering side, _impossible_.

The opposite, completely trivial now. Digital TV is a mux of a number
of bit streams, some with compressed video others with meta data for
epg, alternate sound, interactive apps etc. Adding another stream to
the mux is trivial, you just have to pay for the bandwidth though as
most are stat muxed it's possible to create room at the expense of the
vbr streams where the video encoders reduce the quality of as result of
back pressure from the stat muxer

> To pick a conservative number, say you get an effective throughput of
> 2k bytes/sec

It'd be easy to squeeze that into a normal tv satellite mux

> As I understand it, a current USENET 'full feed', including binaries, take
> two dedicated 100mbit FDX fast ethernet links, and they are saturated _most_
> of the day.  At that rate, A full day of TV vertical interval transmission
> wuould handle under _ten_seconds_ worth of the inbound traffic.  You would
> around =ten=thousand= analog TV channels to handle a contemporary 'full
> feed'.

Or just 3 full muxes at cost of around 10M (probably the same in any
currency) per year

brandon



From jra at baylink.com  Wed May 25 09:10:53 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 25 May 2011 10:10:53 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <201105250847.p4P8lVH9045399@mail.r-bonomi.com>
Message-ID: <1092027.650.1306332653165.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Robert Bonomi" <bonomi at mail.r-bonomi.com>

> As I understand it, a current USENET 'full feed', including binaries, take
> two dedicated 100mbit FDX fast ethernet links, and they are saturated _most_
> of the day. At that rate, A full day of TV vertical interval transmission
> wuould handle under _ten_seconds_ worth of the inbound traffic. You would
> around =ten=thousand= analog TV channels to handle a contemporary 'full
> feed'.

And I remember the month, August 1982 I think it was, when I stopped being 
able to read *all* of Usenet.  At least, everything my junior college took.

:-)

Cheers,
- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jra at baylink.com  Wed May 25 09:15:08 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 25 May 2011 10:15:08 -0400 (EDT)
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <201105250919.KAA10689@sunf10.rd.bbc.co.uk>
Message-ID: <12210349.652.1306332908377.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Brandon Butterworth" <brandon at rd.bbc.co.uk>

> > On the financial side, it is trivial.
> 
> The opposite, the bits were paid for but unused back then so
> financially it was worth using them. In digital tv every bit has a use
> and so a cost, hence they are used for more TV channels instead for
> parasitic services. You end up competing with TV if you want any
> quantity so hard to make viable today.
> 
> > On the engineering side, _impossible_.
> 
> The opposite, completely trivial now. Digital TV is a mux of a number
> of bit streams, some with compressed video others with meta data for
> epg, alternate sound, interactive apps etc. Adding another stream to
> the mux is trivial, you just have to pay for the bandwidth though as
> most are stat muxed it's possible to create room at the expense of the
> vbr streams where the video encoders reduce the quality of as result
> of back pressure from the stat muxer

And sanction means both "approve of" and "order the death of" and academic
means both "very important learning-related" and "doesn't matter".

His assertion, Brandon, had to do with *whether you can still slip it in
without anyone noticing and having to do anything at any other stage of the
transmission chain*, which was Stargate's Unique Selling Proposition.

Yes, we know that its possible to move bits down a digital distribution
channel, Captain Obvious.  :-)

Cheers,
- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From tim.connolly at farecompare.com  Wed May 25 10:49:09 2011
From: tim.connolly at farecompare.com (Tim Connolly)
Date: Wed, 25 May 2011 10:49:09 -0500
Subject: AT&T Opti-man Dallas down
Message-ID: <D72BE7D8-3628-4E8B-8E45-FF9B2E74CB1F@farecompare.com>

	The Dallas area had a round of storms go through last night. Looks like this morning's flaming bag on the front porch was AT&T's "OptiMan" metro-E service was down. Can anyone confirm that this was a wide outage and not just a single customer? Any details released?


From bonomi at mail.r-bonomi.com  Wed May 25 11:01:46 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 25 May 2011 11:01:46 -0500 (CDT)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
Message-ID: <201105251601.p4PG1kEX047661@mail.r-bonomi.com>

> From brandon at rd.bbc.co.uk  Wed May 25 04:21:13 2011
> Date: Wed, 25 May 2011 10:19:09 +0100 (BST)
> From: Brandon Butterworth <brandon at rd.bbc.co.uk>
> To: morrowc.lists at gmail.com, nanog at nanog.org, bonomi at mail.r-bonomi.com
> Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any
> 	Other Company
>
> > > So... would this have been feasible today? given the bandwidth required 
> > > to send a full feed these days, i suspect likely not, eh? (even if you 
> > > were able to do it on all 500+ channels in parallel)
> > 
> > On the financial side, it is trivial.
>
> The opposite, the bits were paid for but unused back then so
> financially it was worth using them. In digital tv every bit has a use
> and so a cost, hence they are used for more TV channels instead for
> parasitic services. You end up competing with TV if you want any
> quantity so hard to make viable today.

You demonstrate you have no understanding of what the word 'feasable'
means.

> > On the engineering side, _impossible_.
>
> The opposite, completely trivial now. 

FALSE TO FACT.

>                                       Digital TV is a mux of a number
> of bit streams, some with compressed video others with meta data for
> epg, alternate sound, interactive apps etc. Adding another stream to
> the mux is trivial, you just have to pay for the bandwidth though as
> most are stat muxed it's possible to create room at the expense of the
> vbr streams where the video encoders reduce the quality of as result of
> back pressure from the stat muxer

Obviously, you misunderstood the 'do this' reference of the prior poster.
The 'elegence' of the original Stargate scheme was that the data was 
injected into the original video signal at the oint of origin, passed 
through _all_ the intermediate points, WITHOUT any special handling (or
even 'awareness' that the 'extra' information is there) and delivered 
to the end-user, where it was extracted by a _standard_ TV receiver to a
normal _video_ signal, from which the extra data was then extracted.

One _cannot_ do this with 'modern' digital TV trasmission, because the
_end-to-end_ technolgy does not support it.

*IF* the signal =originates= as an _analog_ video signal, as many of the
cable-only channels _still_ do, "data" in the vertical interval is lost 
at the analog-to-digital conversion, and simply _cannot_ be recovered at
the end-user's TV reciever output.

OTOH, if the signal originates as a digital stream, while it may be
"possible" to multiplex in an additional data stream, said data stream
will *NOT* survive _intermediate_ transcoding to an analog video stream 
before transmission to the end-user.  And, even if the actual digital
stream is delivered to the end-user, a *STANDARD* digital TV receiver has
no means to deliver that 'additional' information to the end-user in any
usableform.

*GIVEN* the constraints of:
  1) injection at the point of video signal origination (-not- the satellite
     uplink point
  2) "transparent" carriage to the end-user viewer of the video signal,
  3) end-user extraction of data from the output of a commercial off-the-shelf
     TV tuner/receiver
     
Now, 

>
> > To pick a conservative number, say you get an effective throughput of
> > 2k bytes/sec
>
> It'd be easy to squeeze that into a normal tv satellite mux

Sorry, you've got to squeeze _several_times_ that figure 'into the mux',
to provide the 'redundant' transmissions needed to compensate for momentary
LOS events.

So??  what about the _rest_ of the path the signal goes through to get to
the end-user's TV set.  The original methodology was -not- about delivering
a USENET feed to a satellite receiving station with special eqquipment to
extract it, but delivering it _transparently_ (or even 'invisibly' :) ALL 
THE WAY to the _end-user_ consumer/viewer.

>
> > As I understand it, a current USENET 'full feed', including binaries, take
> > two dedicated 100mbit FDX fast ethernet links, and they are saturated _most_
> > of the day.  At that rate, A full day of TV vertical interval transmission
> > wuould handle under _ten_seconds_ worth of the inbound traffic.  You would
> > around =ten=thousand= analog TV channels to handle a contemporary 'full
> > feed'.
>
> Or just 3 full muxes at cost of around 10M (probably the same in any
> currency) per year

*TRIPLE* that, _at_least_, to allow for automatic multiple transmissions of 
everything, to avoid 'lost data' due to data errors and/or momentary signal-
path obstructions.  This is a one-way 'broadcast' link with no ACK/NAK type
responses from the receiving end(s) possible.

Recurring cost for the sat link, more like 30-50 million/year. Plus the costs
_or the dedicated gear at _every_ downlink point. 

Further, that gets it on the satellite -- "Now What??" applies.  _How_ do you 
get it the proverbial 'last mile' to the end-user consumer? And at what kind
of cost for the CPE for _each_ customer?  Or are you 'assuming' that some 
third-party handles that?

Don't forget to add the capital cost for all the CPE, _plus_ the MRC for the
last-mile distribution to the circa 40 million/year for the 'bare' satellite
bandwidth.

The value of 'Stargate' was that it delivered a feed to _anyone_ who could
get the video signal -- with _zero_ action required by any intermediate 
third party who was re-transmitting the signal -- in a form that could be 
extracted with *inexpensive* CPE. There was also an _esisting_ 'standard' 
for the encoding of data into the video signal, so that the same CPE could 
be used to extract data from _any_ video source carrying it.  And, there 
_were_ multiple possible video sources.  If the local cable company carried
a ny of them you were in business.

Yes, you *CAN* engineer a "completely different" methodology for delivering
a full USENET feed to end-users via satellite transmission.  However, doing
so is contrary to the premise of the existing discussion.






From eesslinger at fpu-tn.com  Wed May 25 11:09:34 2011
From: eesslinger at fpu-tn.com (Eric J Esslinger)
Date: Wed, 25 May 2011 11:09:34 -0500
Subject: blocking annoying 'bounce mail' "feature" from customers use.
Message-ID: <D2D37F15EBBD524693E9F3CB32D02080219B775069@exchange.corp.fpu-tn.com>

Mac Mail (and others) have a "feature" that allows my customers to generate a fake NDR message and send it back through my server. I get about a customer every few months that discovers this 'solution' to spam emails, and when it happens they cause delivery problems for my customer mail server by generating backscatter.

Today I just ended up on a list that won't take me off for quite a while (or unless I pay).

Does anyone know of a way for me to block the following, using postfix, either via refusing to accept the mail or by dropping it in /dev/null:
Mail from <> or postmaster that originates within our customer IP blocks/is sent using authentication at the submission port and/or that does not have a valid local recipient.

I can't find any ready made recipies online for this sort of thing in a short dig around for it, and while I think it's possible, I was wondering if anyone else was already dealing with this and could say 'oh yeah just put line blah in header_checks'. I would think it would be simple once you find it but you know how it is.

(I've already dealt with the customer in question but I'm getting tired of this popping up every month or three.)
__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.



From sethm at rollernet.us  Wed May 25 11:17:09 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 25 May 2011 09:17:09 -0700
Subject: blocking annoying 'bounce mail' "feature" from customers use.
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080219B775069@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080219B775069@exchange.corp.fpu-tn.com>
Message-ID: <4DDD2B85.4070802@rollernet.us>

On 5/25/11 9:09 AM, Eric J Esslinger wrote:
> Mac Mail (and others) have a "feature" that allows my customers to generate a fake NDR message and send it back through my server. I get about a customer every few months that discovers this 'solution' to spam emails, and when it happens they cause delivery problems for my customer mail server by generating backscatter.
> 
> Today I just ended up on a list that won't take me off for quite a while (or unless I pay).
> 
> Does anyone know of a way for me to block the following, using postfix, either via refusing to accept the mail or by dropping it in /dev/null:
> Mail from <> or postmaster that originates within our customer IP blocks/is sent using authentication at the submission port and/or that does not have a valid local recipient.
> 
> I can't find any ready made recipies online for this sort of thing in a short dig around for it, and while I think it's possible, I was wondering if anyone else was already dealing with this and could say 'oh yeah just put line blah in header_checks'. I would think it would be simple once you find it but you know how it is.
> 
> (I've already dealt with the customer in question but I'm getting tired of this popping up every month or three.)


You can check for a combination of two or more of these headers:

Auto-Submitted: auto-generated (failure)
X-Mailer: Apple Mail (x)
Content-Type: multipart/report;
	boundary=x;
	report-type=delivery-status

~Seth



From jeroen at unfix.org  Wed May 25 11:18:39 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 25 May 2011 18:18:39 +0200
Subject: blocking annoying 'bounce mail' "feature" from customers use.
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080219B775069@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080219B775069@exchange.corp.fpu-tn.com>
Message-ID: <4DDD2BDF.10208@unfix.org>

On 2011-May-25 18:09, Eric J Esslinger wrote:
[..]
> Does anyone know of a way for me to block the following, using
> postfix, either via refusing to accept the mail or by dropping it in
> /dev/null: Mail from <> or postmaster that originates within our
> customer IP blocks/is sent using authentication at the submission
> port and/or that does not have a valid local recipient.

http://www.postfix.org/header_checks.5.html

But you should be lucky your customers are actually using your SMTP
relay in the first place instead of just bouncing directly to the target MX.

Greets,
 Jeroen



From paul at telcodata.us  Wed May 25 11:38:11 2011
From: paul at telcodata.us (Paul Timmins)
Date: Wed, 25 May 2011 12:38:11 -0400
Subject: Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
In-Reply-To: <BANLkTim05DFir+ftAP-_nxPnt1o2+X7RQA@mail.gmail.com>
References: <4DD431B6.3030402@2mbit.com>	<201105191822.p4JIMYr9065308@mail.r-bonomi.com>	<BANLkTinEC9DGT8Fv75mWs6uah=OS29H0Og@mail.gmail.com>	<20110525024807.GA56549@metron.com>
	<BANLkTim05DFir+ftAP-_nxPnt1o2+X7RQA@mail.gmail.com>
Message-ID: <4DDD3073.2060707@telcodata.us>

On 05/24/2011 11:12 PM, Christopher Morrow wrote:
> On Tue, May 24, 2011 at 10:48 PM, Lou Katz<lou at metron.com>  wrote:
>    
>>>> An "elegant" idea, done in by changing technology.   *sigh*
>>>>
>>>>          
>> As USENIX director I sponsored and sheparded this project, called "Stargate".
>> We at least got bits into the blanking interval at WTBS in Altanta.
>>      
> So... would this have been feasible today? given the bandwidth
> required to send a full feed these days, i suspect likely not, eh?
> (even if you were able to do it on all 500+ channels in parallel)
>    

All you need these days is an MPEG4 decoder and some ATSC tuners, and 
you can regenerate most of the alt. namespace locally. For the rest you 
may need a subscription to netflix a DVD drive, and some ripping software.

I wonder what usenet would take for bandwidth if you ditched all the 
pirated content.

-Paul



From joly at punkcast.com  Wed May 25 12:02:24 2011
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 25 May 2011 13:02:24 -0400
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any Other Company
In-Reply-To: <201105251601.p4PG1kEX047661@mail.r-bonomi.com>
References: <201105251601.p4PG1kEX047661@mail.r-bonomi.com>
Message-ID: <BANLkTinUoCWzFBrRZJQvdTyp5u9x+04Ogw@mail.gmail.com>

While not material to the technical discussion, I would point out that it is
doubtful any large corp. would want to distro full USENET these days given
the legal implications -  see http://isoc-ny.org/?p=252 - mind you Cuomo is
otherwise engaged these days.

j




>
> Yes, you *CAN* engineer a "completely different" methodology for delivering
> a full USENET feed to end-users via satellite transmission.  However, doing
> so is contrary to the premise of the existing discussion.
>
>
>
>
>


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From nikm at cyberflunk.com  Wed May 25 12:14:51 2011
From: nikm at cyberflunk.com (Nikos Mouat)
Date: Wed, 25 May 2011 10:14:51 -0700 (PDT)
Subject: AT&T Opti-man Dallas down
In-Reply-To: <D72BE7D8-3628-4E8B-8E45-FF9B2E74CB1F@farecompare.com>
References: <D72BE7D8-3628-4E8B-8E45-FF9B2E74CB1F@farecompare.com>
Message-ID: <alpine.LFD.2.00.1105251012120.23416@main.cyberflunk.com>


Yes, we lost all our Opteman circuits in Dallas from roughly 8:30AM to 
10:30AM Central. The cause communicated to us from AT&T was:

"the router took a hit and the SUP Card failed which resulted in our outage"

our Opteman circuits in Houston were not impacted.

Nikos


On Wed, 25 May 2011, Tim Connolly wrote:

> 	The Dallas area had a round of storms go through last night. Looks 
> like this morning's flaming bag on the front porch was AT&T's "OptiMan" 
> metro-E service was down. Can anyone confirm that this was a wide outage 
> and not just a single customer? Any details released?
>
>



From drc at virtualized.org  Wed May 25 12:26:56 2011
From: drc at virtualized.org (David Conrad)
Date: Wed, 25 May 2011 10:26:56 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
Message-ID: <DE190E45-BB0B-4673-93F5-875BC67BA6D2@virtualized.org>

On May 24, 2011, at 8:22 PM, Jeremy wrote:
> As long as necessary precautions are taken (route filters, tunnels, VRF's)
> shouldn't this be technically feasible without any negative ramifications?

Any? Debatable. Doing stuff like this has costs, but I suspect the folks at Rogers aren't idiots and actually did a cost/benefit analysis. 

> Couldn't
> you theoretically use anyone's IP space, advertised or not, for this
> internal transit?

Yes.

> I'm not saying it's a good idea, it's certainly more
> complex which leads to its own issues, but shouldn't it be possible?

Of course.  Not even sure it is more complex. 

Regards,
-drc




From cjp at 0x1.net  Wed May 25 13:43:24 2011
From: cjp at 0x1.net (Christopher Pilkington)
Date: Wed, 25 May 2011 14:43:24 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
Message-ID: <BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>

On Wed, May 25, 2011 at 1:25 AM, Michael Dillon
<wavetossed at googlemail.com> wrote:
> So we should CONDONE such borrowing and recommend a couple of /8s to
> use in North America. Perhaps one could be DOD for those operators
> that do not carry any DOD traffic and one could be that /8 from
> Softbank Japan, 126/8 if I recall it correctly. People who carry DOD
> traffic could borrow the APNIC block.

I recommend 44/8.  Does it make sense that ham radio operators have
routable IP address space any longer?  (Seems to be still advertised,
though.)

-cjp (n2mcs)



From jayb at braeburn.org  Wed May 25 13:54:47 2011
From: jayb at braeburn.org (Jay Borkenhagen)
Date: Wed, 25 May 2011 14:54:47 -0400
Subject: where are all the IPv6 tools?
Message-ID: <19933.20599.460714.364886@oz.mt.att.com>

Hi,

I depend on a number of shell tools for manipulating IPv4 addresses,
CIDR blocks, etc. like:

 aggis
 ipsort.pl
 grepcidr
 aggregate

I have not yet found much in terms of similar shell utilities for
IPv6.  I've spoken to authors of some of these tools and they admit
they have not yet produced IPv6-capable versions.  (Not trying to name
and shame: those tools are great, I just want more!)

Do folks here know of IPv6 tools that might provide some of the
functions the above tools provide for IPv4?

Thanks!

                                                       Jay B.








From pixitha.kyle at gmail.com  Wed May 25 14:29:58 2011
From: pixitha.kyle at gmail.com (Kyle Duren)
Date: Wed, 25 May 2011 12:29:58 -0700
Subject: where are all the IPv6 tools?
In-Reply-To: <19933.20599.460714.364886@oz.mt.att.com>
References: <19933.20599.460714.364886@oz.mt.att.com>
Message-ID: <BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>

On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen <jayb at braeburn.org> wrote:
> Hi,
>
> I depend on a number of shell tools for manipulating IPv4 addresses,
> CIDR blocks, etc. like:
>
> ?aggis
> ?ipsort.pl
> ?grepcidr
> ?aggregate
>
> I have not yet found much in terms of similar shell utilities for
> IPv6. ?I've spoken to authors of some of these tools and they admit
> they have not yet produced IPv6-capable versions. ?(Not trying to name
> and shame: those tools are great, I just want more!)
>
> Do folks here know of IPv6 tools that might provide some of the
> functions the above tools provide for IPv4?
>
> Thanks!
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Jay B.
>
>
>
>
>
>
>

I recommend IPv6gen.

http://code.google.com/p/ipv6gen/

Very useful. Granted its not what you were asking for exactly....

>From the site:

"ipv6gen is tool which generates list of IPv6 prefixes of given length
from certain prefix according to RFC 3531. (A Flexible Method for
Managing the Assignment of Bits of an IPv6 Address Block)"

-Kyle



From bonomi at mail.r-bonomi.com  Wed May 25 14:36:32 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 25 May 2011 14:36:32 -0500 (CDT)
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
Message-ID: <201105251936.p4PJaW3F048728@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Wed May 25 13:44:21 2011
> Date: Wed, 25 May 2011 14:43:24 -0400
> Subject: Re: Rogers Canada using 7.0.0.0/8 for internal address space
> From: Christopher Pilkington <cjp at 0x1.net>
> To: Michael Dillon <wavetossed at googlemail.com>
> Cc: NANOG <nanog at nanog.org>
>
> On Wed, May 25, 2011 at 1:25 AM, Michael Dillon
> <wavetossed at googlemail.com> wrote:
> > So we should CONDONE such borrowing and recommend a couple of /8s to
> > use in North America. Perhaps one could be DOD for those operators
> > that do not carry any DOD traffic and one could be that /8 from
> > Softbank Japan, 126/8 if I recall it correctly. People who carry DOD
> > traffic could borrow the APNIC block.
>
> I recommend 44/8.  Does it make sense that ham radio operators have
> routable IP address space any longer?  (Seems to be still advertised,
> though.)

Still advertised, still in (light, limited) use.





From carlosm3011 at gmail.com  Wed May 25 14:37:01 2011
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Wed, 25 May 2011 16:37:01 -0300
Subject: where are all the IPv6 tools?
In-Reply-To: <BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
References: <19933.20599.460714.364886@oz.mt.att.com>
	<BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
Message-ID: <BANLkTin3bE+780G36Wr5M7WuN4sMHZG9jg@mail.gmail.com>

I'm addicted to sipcalc: http://www.routemeister.net/projects/sipcalc/

It's available on standard repositories for MacPorts, Ubuntu, Debian
and Fedora. I guess install is straightforward in other platforms as
well.

regards

Carlos

On Wed, May 25, 2011 at 4:29 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
> On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen <jayb at braeburn.org> wrote:
>> Hi,
>>
>> I depend on a number of shell tools for manipulating IPv4 addresses,
>> CIDR blocks, etc. like:
>>
>> ?aggis
>> ?ipsort.pl
>> ?grepcidr
>> ?aggregate
>>
>> I have not yet found much in terms of similar shell utilities for
>> IPv6. ?I've spoken to authors of some of these tools and they admit
>> they have not yet produced IPv6-capable versions. ?(Not trying to name
>> and shame: those tools are great, I just want more!)
>>
>> Do folks here know of IPv6 tools that might provide some of the
>> functions the above tools provide for IPv4?
>>
>> Thanks!
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Jay B.
>>
>>
>>
>>
>>
>>
>>
>
> I recommend IPv6gen.
>
> http://code.google.com/p/ipv6gen/
>
> Very useful. Granted its not what you were asking for exactly....
>
> >From the site:
>
> "ipv6gen is tool which generates list of IPv6 prefixes of given length
> from certain prefix according to RFC 3531. (A Flexible Method for
> Managing the Assignment of Bits of an IPv6 Address Block)"
>
> -Kyle
>
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================



From mikea at mikea.ath.cx  Wed May 25 14:38:40 2011
From: mikea at mikea.ath.cx (mikea)
Date: Wed, 25 May 2011 14:38:40 -0500
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
Message-ID: <20110525193840.GA21140@mikea.ath.cx>

On Wed, May 25, 2011 at 02:43:24PM -0400, Christopher Pilkington wrote:
> On Wed, May 25, 2011 at 1:25 AM, Michael Dillon
> <wavetossed at googlemail.com> wrote:
> > So we should CONDONE such borrowing and recommend a couple of /8s to
> > use in North America. Perhaps one could be DOD for those operators
> > that do not carry any DOD traffic and one could be that /8 from
> > Softbank Japan, 126/8 if I recall it correctly. People who carry DOD
> > traffic could borrow the APNIC block.
> 
> I recommend 44/8.  Does it make sense that ham radio operators have
> routable IP address space any longer?  (Seems to be still advertised,
> though.)

I'll ask Brian what he thinks. 

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin 



From mike at sentex.net  Wed May 25 14:39:29 2011
From: mike at sentex.net (Mike Tancsa)
Date: Wed, 25 May 2011 15:39:29 -0400
Subject: where are all the IPv6 tools?
In-Reply-To: <BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
References: <19933.20599.460714.364886@oz.mt.att.com>
	<BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
Message-ID: <4DDD5AF1.1040205@sentex.net>

On 5/25/2011 3:29 PM, Kyle Duren wrote:
> On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen <jayb at braeburn.org> wrote:
>>
>> Do folks here know of IPv6 tools that might provide some of the
>> functions the above tools provide for IPv4?
>>
> 
> I recommend IPv6gen.
> 
> http://code.google.com/p/ipv6gen/
> 
> Very useful. Granted its not what you were asking for exactly....

I use it as well. Great tool. (In the FreeBSD ports tree too). I have
also made use of the perl tool Net::IPv6Addr.

	---Mike



-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/



From chip.gwyn at gmail.com  Wed May 25 14:40:06 2011
From: chip.gwyn at gmail.com (chip)
Date: Wed, 25 May 2011 15:40:06 -0400
Subject: where are all the IPv6 tools?
In-Reply-To: <BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
References: <19933.20599.460714.364886@oz.mt.att.com>
	<BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
Message-ID: <BANLkTi=+jWo-Fd4fpgBBGbnGkCtj-q3+Qw@mail.gmail.com>

On Wed, May 25, 2011 at 3:29 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
> On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen <jayb at braeburn.org> wrote:
>> Hi,
>>
>> I depend on a number of shell tools for manipulating IPv4 addresses,
>> CIDR blocks, etc. like:
>>
>> ?aggis
>> ?ipsort.pl
>> ?grepcidr
>> ?aggregate
>>
>> I have not yet found much in terms of similar shell utilities for
>> IPv6. ?I've spoken to authors of some of these tools and they admit
>> they have not yet produced IPv6-capable versions. ?(Not trying to name
>> and shame: those tools are great, I just want more!)
>>
>> Do folks here know of IPv6 tools that might provide some of the
>> functions the above tools provide for IPv4?
>>
>> Thanks!
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Jay B.
>>
>>
>>
>>
>>
>>
>>
>
> I recommend IPv6gen.
>
> http://code.google.com/p/ipv6gen/
>
> Very useful. Granted its not what you were asking for exactly....
>
> >From the site:
>
> "ipv6gen is tool which generates list of IPv6 prefixes of given length
> from certain prefix according to RFC 3531. (A Flexible Method for
> Managing the Assignment of Bits of an IPv6 Address Block)"
>
> -Kyle
>
>


There's also  "sipcalc" which has nothing to do with VOIP....

http://www.routemeister.net/projects/sipcalc/

--chip


-- 
Just my $.02, your mileage may vary,? batteries not included, etc....



From mwalter at 3z.net  Wed May 25 15:04:58 2011
From: mwalter at 3z.net (Mike Walter)
Date: Wed, 25 May 2011 20:04:58 +0000
Subject: where are all the IPv6 tools?
In-Reply-To: <BANLkTi=+jWo-Fd4fpgBBGbnGkCtj-q3+Qw@mail.gmail.com>
References: <19933.20599.460714.364886@oz.mt.att.com>
	<BANLkTik0rNjVYgDsphdDWGjA5w+yMCEvyA@mail.gmail.com>
	<BANLkTi=+jWo-Fd4fpgBBGbnGkCtj-q3+Qw@mail.gmail.com>
Message-ID: <D7092CF606B8964193F248C92106B7816B66E7@zionex01.ZION.local>

We use the IPAM tool by 6connect.net, not sure if that is what you are looking for exactly?

-Mike


-----Original Message-----
From: chip [mailto:chip.gwyn at gmail.com] 
Sent: Wednesday, May 25, 2011 3:40 PM
To: Kyle Duren
Cc: nanog at nanog.org
Subject: Re: where are all the IPv6 tools?

On Wed, May 25, 2011 at 3:29 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
> On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen <jayb at braeburn.org> wrote:
>> Hi,
>>
>> I depend on a number of shell tools for manipulating IPv4 addresses,
>> CIDR blocks, etc. like:
>>
>> ?aggis
>> ?ipsort.pl
>> ?grepcidr
>> ?aggregate
>>
>> I have not yet found much in terms of similar shell utilities for
>> IPv6. ?I've spoken to authors of some of these tools and they admit
>> they have not yet produced IPv6-capable versions. ?(Not trying to name
>> and shame: those tools are great, I just want more!)
>>
>> Do folks here know of IPv6 tools that might provide some of the
>> functions the above tools provide for IPv4?
>>
>> Thanks!
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Jay B.
>>
>>
>>
>>
>>
>>
>>
>
> I recommend IPv6gen.
>
> http://code.google.com/p/ipv6gen/
>
> Very useful. Granted its not what you were asking for exactly....
>
> >From the site:
>
> "ipv6gen is tool which generates list of IPv6 prefixes of given length
> from certain prefix according to RFC 3531. (A Flexible Method for
> Managing the Assignment of Bits of an IPv6 Address Block)"
>
> -Kyle
>
>


There's also  "sipcalc" which has nothing to do with VOIP....

http://www.routemeister.net/projects/sipcalc/

--chip


-- 
Just my $.02, your mileage may vary,? batteries not included, etc....




From bmanning at vacation.karoshi.com  Wed May 25 15:24:52 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 25 May 2011 20:24:52 +0000
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
Message-ID: <20110525202452.GA24806@vacation.karoshi.com.>

On Wed, May 25, 2011 at 02:43:24PM -0400, Christopher Pilkington wrote:
> On Wed, May 25, 2011 at 1:25 AM, Michael Dillon
> <wavetossed at googlemail.com> wrote:
> > So we should CONDONE such borrowing and recommend a couple of /8s to
> > use in North America. Perhaps one could be DOD for those operators
> > that do not carry any DOD traffic and one could be that /8 from
> > Softbank Japan, 126/8 if I recall it correctly. People who carry DOD
> > traffic could borrow the APNIC block.
> 
> I recommend 44/8.  Does it make sense that ham radio operators have
> routable IP address space any longer?  (Seems to be still advertised,
> though.)
> 
> -cjp (n2mcs)

	I recommend (if we are going down the path of being pirates...)
	77.0.0.0/8  - only 0x1.net is in that space as far as I can tell
	and its easy enough to put them behind a NAT...

	NOTE WELL - Just because -you- (for values of you) see no value in
	space assigned, does NOT give you the right to hijack said space
	for your own purposes.   Nor does it look well  for you to advocate
	hijacking someone elses space....

	YMMV of course.

/bill



From lyndon at orthanc.ca  Wed May 25 15:53:24 2011
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 25 May 2011 13:53:24 -0700 (PDT)
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1105251352510.72406@legolas.orthanc.ca>

> Does it make sense that ham radio operators have
> routable IP address space any longer?

Yes.  Keep your mitts off 44!



From cjp at 0x1.net  Wed May 25 16:23:43 2011
From: cjp at 0x1.net (Christopher Pilkington)
Date: Wed, 25 May 2011 17:23:43 -0400
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <20110525202452.GA24806@vacation.karoshi.com.>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
	<20110525202452.GA24806@vacation.karoshi.com.>
Message-ID: <BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>

On Wed, May 25, 2011 at 4:24 PM,  <bmanning at vacation.karoshi.com> wrote:
> ? ? ? ?NOTE WELL - Just because -you- (for values of you) see no value in
> ? ? ? ?space assigned, does NOT give you the right to hijack said space
> ? ? ? ?for your own purposes. ? Nor does it look well ?for you to advocate
> ? ? ? ?hijacking someone elses space....

Indeed, arbitrary is arbitrary, be it ham radio operators or the DoD.
I was trolling hams on the list there, my apologies. FWIW, my box
44.68.16.20 hasn't been up in well over a decade.  Would have been
nice if that packet radio masses kept up with (or ahead of) the
technology of the times.  Our network went to 9600 baud user ports,
then vanished.

-cjp (n2mcs)



From brandon at rd.bbc.co.uk  Wed May 25 20:08:04 2011
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Thu, 26 May 2011 02:08:04 +0100 (BST)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any
	Other Company
Message-ID: <201105260108.CAA15391@sunf10.rd.bbc.co.uk>

> You demonstrate you have no understanding of what the word 'feasable'
> means.

OK, but we actually did this as a commercial service on analogue TV and
we deliver non picture data on digital TV (satellite and terrestrial)
today, it's just not USENET data.

> One _cannot_ do this with 'modern' digital TV trasmission, because the
> _end-to-end_ technolgy does not support it.

Apologies for disagreeing, but this is exactly what the modern
technology does.

Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a
multiplex of a number of independent data streams that can be data,
video or audio. That is carried end to end.

We do this now with other data -

http://en.wikipedia.org/wiki/BBC_Red_Button

It'd be trivial for us to display USENET directly to read on your TV
or deliver it to the STB ethernet port

> OTOH, if the signal originates as a digital stream, while it may be
> "possible" to multiplex in an additional data stream, said data stream
> will *NOT* survive _intermediate_ transcoding to an analog video stream 
> before transmission to the end-user.

Indeed but that is not a digital TV system.

> And, even if the actual digital
> stream is delivered to the end-user, a *STANDARD* digital TV receiver has
> no means to deliver that 'additional' information to the end-user in any
> usableform.

Standard DTV PVR with an ethernet port are a few hundred dollars.

For the people who would actually receive this the box cost is trivial
they just some software. If you have a USB or PCI DTV rx it is trivial
to do whatever you like with the data.

brandon







From jhell at DataIX.net  Wed May 25 20:13:01 2011
From: jhell at DataIX.net (Jason Hellenthal)
Date: Wed, 25 May 2011 21:13:01 -0400
Subject: AT&T Opti-man Dallas down
In-Reply-To: <D72BE7D8-3628-4E8B-8E45-FF9B2E74CB1F@farecompare.com>
References: <D72BE7D8-3628-4E8B-8E45-FF9B2E74CB1F@farecompare.com>
Message-ID: <20110526011301.GA92375@DataIX.net>


Tim,

Don't know exactly how relevant it was but ~1pm EST today we had trouble
contacting Dallas headquarters by our normal VoIP links. Last known it
was still not contactable around ~4pm EST. This was all from West MI,
may be just coincidence though.

On Wed, May 25, 2011 at 10:49:09AM -0500, Tim Connolly wrote:
> 	The Dallas area had a round of storms go through last night. Looks like this morning's flaming bag on the front porch was AT&T's "OptiMan" metro-E service was down. Can anyone confirm that this was a wide outage and not just a single customer? Any details released?

-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110525/b827ffd2/attachment.bin>

From joe at nethead.com  Wed May 25 20:34:31 2011
From: joe at nethead.com (Joe Hamelin)
Date: Wed, 25 May 2011 18:34:31 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
	<20110525202452.GA24806@vacation.karoshi.com.>
	<BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>
Message-ID: <BANLkTin2OQ5nfB3MgCTOoam1+u41ovVuCw@mail.gmail.com>

On Wed, May 25, 2011 at 2:23 PM, Christopher Pilkington <cjp at 0x1.net> wrote:

>
> Indeed, arbitrary is arbitrary, be it ham radio operators or the DoD.
> I was trolling hams on the list there, my apologies. FWIW, my box
> 44.68.16.20 hasn't been up in well over a decade.  Would have been
> nice if that packet radio masses kept up with (or ahead of) the
> technology of the times.  Our network went to 9600 baud user ports,
> then vanished.
>
>
>
DStar systems are using 44/8 now for interconnect.    Mine (K7TUL/B) will be
up as soon as I make a hill trip and fix the antenna.

73

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474


From Valdis.Kletnieks at vt.edu  Wed May 25 20:54:57 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 25 May 2011 21:54:57 -0400
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any Other Company
In-Reply-To: Your message of "Thu, 26 May 2011 02:08:04 BST."
	<201105260108.CAA15391@sunf10.rd.bbc.co.uk>
References: <201105260108.CAA15391@sunf10.rd.bbc.co.uk>
Message-ID: <3790.1306374897@localhost>

On Thu, 26 May 2011 02:08:04 BST, Brandon Butterworth said:

> > One _cannot_ do this with 'modern' digital TV trasmission, because the
> > _end-to-end_ technolgy does not support it.
> 
> Apologies for disagreeing, but this is exactly what the modern
> technology does.

> Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a
> multiplex of a number of independent data streams that can be data,
> video or audio. That is carried end to end.

When Stargate stuck (say) 10% more data into TBS's analog signal by
stashing it in retrace and blanking intervals and the like, TBS's bandwidth
requirement went up zero. Zip. Zilch.

How much does your bandwidth usage on your new miracle boxes go
up if you stick another 10% data stream in there? Probably a measurable
amount more than zero.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110525/8d26b153/attachment.bin>

From jra at baylink.com  Wed May 25 22:07:00 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 25 May 2011 23:07:00 -0400 (EDT)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any	Other Company
In-Reply-To: <14197163.702.1306379200726.JavaMail.root@benjamin.baylink.com>
Message-ID: <7325904.704.1306379220074.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Brandon Butterworth" <brandon at rd.bbc.co.uk>

> > You demonstrate you have no understanding of what the word
> > 'feasable' means.
> 
> OK, but we actually did this as a commercial service on analogue TV and
> we deliver non picture data on digital TV (satellite and terrestrial)
> today, it's just not USENET data.

You demonstrate that you have no understanding of what the words "sneak
along" mean.  :-)

> > One _cannot_ do this with 'modern' digital TV trasmission, because
> > the _end-to-end_ technolgy does not support it.
> 
> Apologies for disagreeing, but this is exactly what the modern
> technology does.

Allow you to sneak in extra data in an otherwise unused place that won't 
affect anything, and no one will have to deal with, but end viewers will 
be able to see it anyway?

No, we're pretty sure you're wrong there, probably because you're 
purposely ignoring our *specific* characterization of the thing which
was actually done.

> Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a
> multiplex of a number of independent data streams that can be data,
> video or audio. That is carried end to end.
> 
> We do this now with other data -
> 
> http://en.wikipedia.org/wiki/BBC_Red_Button
> 
> It'd be trivial for us to display USENET directly to read on your TV
> or deliver it to the STB ethernet port

Sure.  But that wasn't what we were *talking* about. 

> > OTOH, if the signal originates as a digital stream, while it may be
> > "possible" to multiplex in an additional data stream, said data
> > stream will *NOT* survive _intermediate_ transcoding to an analog video
> > stream before transmission to the end-user.
> 
> Indeed but that is not a digital TV system.

Nobody said it was, and what's more: we don't care.  :-)

> > And, even if the actual digital
> > stream is delivered to the end-user, a *STANDARD* digital TV
> > receiver has
> > no means to deliver that 'additional' information to the end-user in
> > any usableform.
> 
> Standard DTV PVR with an ethernet port are a few hundred dollars.
> 
> For the people who would actually receive this the box cost is trivial
> they just some software. If you have a USB or PCI DTV rx it is trivial
> to do whatever you like with the data.

You can't really guarantee that random things injected into a transport
stream mux at the send end will make it to the receive end; everyone in
the transport path very likely thinks they're entitled to pull the 
separate program streams out and fiddle with them however they like --
Hell: local cablecos *reencode* the local station HD signals to compress
them further.

So not only are you not making assertions about the same thing we are, 
there's a very good chance you're incorrect in the general case about the
assertion you *are* making.

I don't know if my understanding of terrestrial network and satellite
broadcasting in the US carries over to the continent, but I'd bet at least
the latter does...

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jra at baylink.com  Wed May 25 23:58:11 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 26 May 2011 00:58:11 -0400 (EDT)
Subject: [outages] Level 3 core router in Chicago down?
In-Reply-To: <4DDDD696.1070701@ifbyphone.com>
Message-ID: <29775339.718.1306385891543.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> On 5/25/2011 11:25 PM, Brooks Bridges wrote:
> > We just lost a bunch of routes out of Chicago over Level 3.
> >
> > Seems to be dying at edge routers right before their core.
> >
> >   1. XXXXXXXXXXXXXXX 0.0% 10 0.5 0.4
> > 0.3 0.6 0.1

> Of course, as soon as I hit send, it comes back...

Well, thanks for fixin' that, Brooks.  Night, now. 

Cheers, 
-- jr 'causation?  what's that?' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From gaurav.taparia at gmail.com  Thu May 26 00:04:42 2011
From: gaurav.taparia at gmail.com (Gaurav Taparia)
Date: Thu, 26 May 2011 10:34:42 +0530
Subject: [outages] Level 3 core router in Chicago down?
In-Reply-To: <29775339.718.1306385891543.JavaMail.root@benjamin.baylink.com>
References: <4DDDD696.1070701@ifbyphone.com>
	<29775339.718.1306385891543.JavaMail.root@benjamin.baylink.com>
Message-ID: <BANLkTi=bwjH-HSajz4-Gx2Myv_ZvPOZGfg@mail.gmail.com>

We saw it too. The paths are back up but the latency is higher suggesting
that it is on a re-routed path. Their helpdesk is saying it is a planned
maintenance.

 - Gaurav



On Thu, May 26, 2011 at 10:28 AM, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
> > On 5/25/2011 11:25 PM, Brooks Bridges wrote:
> > > We just lost a bunch of routes out of Chicago over Level 3.
> > >
> > > Seems to be dying at edge routers right before their core.
> > >
> > >   1. XXXXXXXXXXXXXXX 0.0% 10 0.5 0.4
> > > 0.3 0.6 0.1
>
> > Of course, as soon as I hit send, it comes back...
>
> Well, thanks for fixin' that, Brooks.  Night, now.
>
> Cheers,
> -- jr 'causation?  what's that?' a
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover
> DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647
> 1274
>
>


From owen at delong.com  Thu May 26 00:28:45 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 25 May 2011 22:28:45 -0700
Subject: where are all the IPv6 tools?
In-Reply-To: <19933.20599.460714.364886@oz.mt.att.com>
References: <19933.20599.460714.364886@oz.mt.att.com>
Message-ID: <D9F3D723-E133-4985-B08E-8995ABC7F08E@delong.com>

The PERL Net::IP module provides a basis that would make it fairly
easy to implement most of those and does fully support both IPv4
and IPv6.

IIRC, those tools predated Net::IP, so, re-implementing them from
scratch using Net::IP might be both cleaner and easier.

Owen

On May 25, 2011, at 11:54 AM, Jay Borkenhagen wrote:

> Hi,
> 
> I depend on a number of shell tools for manipulating IPv4 addresses,
> CIDR blocks, etc. like:
> 
> aggis
> ipsort.pl
> grepcidr
> aggregate
> 
> I have not yet found much in terms of similar shell utilities for
> IPv6.  I've spoken to authors of some of these tools and they admit
> they have not yet produced IPv6-capable versions.  (Not trying to name
> and shame: those tools are great, I just want more!)
> 
> Do folks here know of IPv6 tools that might provide some of the
> functions the above tools provide for IPv4?
> 
> Thanks!
> 
>                                                       Jay B.
> 
> 
> 
> 
> 




From owen at delong.com  Thu May 26 00:27:10 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 25 May 2011 22:27:10 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
Message-ID: <01DABF6A-731A-4564-BFB9-FA7EEA7FB00C@delong.com>


On May 25, 2011, at 11:43 AM, Christopher Pilkington wrote:

> On Wed, May 25, 2011 at 1:25 AM, Michael Dillon
> <wavetossed at googlemail.com> wrote:
>> So we should CONDONE such borrowing and recommend a couple of /8s to
>> use in North America. Perhaps one could be DOD for those operators
>> that do not carry any DOD traffic and one could be that /8 from
>> Softbank Japan, 126/8 if I recall it correctly. People who carry DOD
>> traffic could borrow the APNIC block.
> 
> I recommend 44/8.  Does it make sense that ham radio operators have
> routable IP address space any longer?  (Seems to be still advertised,
> though.)
> 
> -cjp (n2mcs)

Why shouldn't they?

Owen DeLong
KB6MER




From owen at delong.com  Thu May 26 00:35:58 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 25 May 2011 22:35:58 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
	<20110525202452.GA24806@vacation.karoshi.com.>
	<BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>
Message-ID: <9195AE30-8641-428E-A052-F41BF46390EA@delong.com>


On May 25, 2011, at 2:23 PM, Christopher Pilkington wrote:

> On Wed, May 25, 2011 at 4:24 PM,  <bmanning at vacation.karoshi.com> wrote:
>>        NOTE WELL - Just because -you- (for values of you) see no value in
>>        space assigned, does NOT give you the right to hijack said space
>>        for your own purposes.   Nor does it look well  for you to advocate
>>        hijacking someone elses space....
> 
> Indeed, arbitrary is arbitrary, be it ham radio operators or the DoD.
> I was trolling hams on the list there, my apologies. FWIW, my box
> 44.68.16.20 hasn't been up in well over a decade.  Would have been
> nice if that packet radio masses kept up with (or ahead of) the
> technology of the times.  Our network went to 9600 baud user ports,
> then vanished.
> 
> -cjp (n2mcs)

Unfortunately, the FCC hasn't really allowed us to since it would be very
hard to produce useful bandwidth by today's standards within the bounds
of the spectrum we are allowed to use and the channel separations we
are allowed to use.

Owen




From matthew at matthew.at  Thu May 26 01:12:23 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 26 May 2011 08:12:23 +0200
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <9195AE30-8641-428E-A052-F41BF46390EA@delong.com>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
	<20110525202452.GA24806@vacation.karoshi.com.>
	<BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>
	<9195AE30-8641-428E-A052-F41BF46390EA@delong.com>
Message-ID: <14BA486E-831A-4FFD-A55D-9B5ED50A31B0@matthew.at>


On May 26, 2011, at 7:35 AM, Owen DeLong wrote:

>> 
> 
> Unfortunately, the FCC hasn't really allowed us to since it would be very
> hard to produce useful bandwidth by today's standards within the bounds
> of the spectrum we are allowed to use and the channel separations we
> are allowed to use.
> 

You just need to move up in frequency a bit. My slowest ham-band link runs at 12 Mbps and my fastest at over 100 Mbps.

Good reminder that I should renumber the IPv4 portion of that network to somewhere in 44.0.0.0/8 however.

Matthew Kaufman




From bonomi at mail.r-bonomi.com  Thu May 26 01:23:27 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 26 May 2011 01:23:27 -0500 (CDT)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any Other Company
In-Reply-To: <201105260108.CAA15391@sunf10.rd.bbc.co.uk>
Message-ID: <201105260623.p4Q6NRMT051662@mail.r-bonomi.com>


> Date: Thu, 26 May 2011 02:08:04 +0100 (BST)
> From: Brandon Butterworth <brandon at rd.bbc.co.uk>
> Subject: Re: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any
> 	Other Company
>
> > You demonstrate you have no understanding of what the word 'feasable'
> > means.
>
> OK, but we actually did this as a commercial service on analogue TV and
> we deliver non picture data on digital TV (satellite and terrestrial)
> today, it's just not USENET data.
>
> > One _cannot_ do this with 'modern' digital TV trasmission, because the
> > _end-to-end_ technolgy does not support it.
>
> Apologies for disagreeing, but this is exactly what the modern
> technology does.

NAME five consumer-grade commercial off the shelf products 
>
> Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a
> multiplex of a number of independent data streams that can be data,
> video or audio. That is carried end to end.

That is *VERY* RARELY true in the U.S., in point of actual fact, as soon as
a 'cable TV'  carrier/distributer gets involved.  *THEY*, the cable companies,
de-multiplex the streams from the originator's composite signal, and
*selectively* re-encode the streams they wish to propogate on _separate_
QAM channels.  

Proof: go to Titantv.com, select the 'digital cable' channel line-up for
'Comcast areas 1, 4 & 5' in zipcode 60640 (chicago north side, lakefront).
and check the comcast channels in the range 340-379.  These  are all 
cable-company _de-multiplized_ video streams extracted from the multiplexed
stream from the originator.  The 'primary' (only!) HD video streams for those
channels can be found, mostly, on channels in the range, 187-194.

I'll simply ask, _which_ of those channels will have that extra data stream
that the head-end inserted?  That the cable compmany doesn't know, or care,
about, and *how* does it survive the de-multiplexing and re-coding that the
cable company did?

> We do this now with other data -
>
> http://en.wikipedia.org/wiki/BBC_Red_Button
>
> It'd be trivial for us to display USENET directly to read on your TV
> or deliver it to the STB ethernet port

You might be able to do it, if you control everything from  the point of  
rigin -through- the STB.

> > OTOH, if the signal originates as a digital stream, while it may be
> > "possible" to multiplex in an additional data stream, said data stream
> > will *NOT* survive _intermediate_ transcoding to an analog video stream 
> > before transmission to the end-user.
>
> Indeed but that is not a digital TV system.

Tell that to all the U.S. cable companies that do _exactly_ that, and sell
it as 'digital' TV -- because they have re-encoded each derived analog video
stream as a QAM "digital" channel.

> > And, even if the actual digital
> > stream is delivered to the end-user, a *STANDARD* digital TV receiver has
> > no means to deliver that 'additional' information to the end-user in any
> > usableform.
>
> Standard DTV PVR with an ethernet port are a few hundred dollars.
>
> For the people who would actually receive this the box cost is trivial
> they just some software. If you have a USB or PCI DTV rx it is trivial
> to do whatever you like with the data.

You apparently have no idea how 'digital TV' is delivered by all the major
cable companies in the U.S. -- demultiplexed, and transcoded to QAM with 
each video stream on a separate QAM channel.  I don't see any _possible_
way for an additional data stream to survive _that_, without explicit 
intervention/support from the cable company.





From brandon at rd.bbc.co.uk  Thu May 26 04:20:26 2011
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Thu, 26 May 2011 10:20:26 +0100 (BST)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any	Other Company
Message-ID: <201105260920.KAA11336@sunf10.rd.bbc.co.uk>

> No, we're pretty sure you're wrong there, probably because you're 
> purposely ignoring our *specific* characterization of the thing which
> was actually done.

I disagreed with two statements:- 

> > On the engineering side, _impossible_.  Modern satellite
> > feeds of NTSC (analog) TV signals use compressed digital
> > representations of only the image portion of each 'field'
> > of the video stream

With my Captain Obvious hat on I said digital systems can carry such
data. The case where some cable companies interfere with the original
broadcasters data doesn't demonstrate it is impossible, they don't
affect the quoted satellite case nor others such as DTT

> > On the financial side, it is trivial.

I don't disagree with the cable cases quoted by others, they
demonstrate why I disagreed that it's financially trivial.

Of course I'm wrong, it is financially trivial as they would carry it
if you paid them. It's just highly unlikely to be financially viable

> You can't really guarantee that random things injected into a transport
> stream mux at the send end will make it to the receive end; everyone in
> the transport path very likely thinks they're entitled to pull the 
> separate program streams out and fiddle with them however they like --
> Hell: local cablecos *reencode* the local station HD signals to compress
> them further.

Yes, that was the case with analogue too, they just hadn't found
someone to sell the data to back then. Cable companies will mess with
anything including netflix.

In our case we sold VBI data so I coudln't make a viable case to offer
a USENET service.

brandon



From brandon at rd.bbc.co.uk  Thu May 26 04:43:26 2011
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Thu, 26 May 2011 10:43:26 +0100 (BST)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any Other Company
Message-ID: <201105260943.KAA12565@sunf10.rd.bbc.co.uk>

> NAME five consumer-grade commercial off the shelf products 

http://lmgtfy.com/?q=STB+PVR+ethernet

> Proof: go to Titantv.com, select the 'digital cable' channel line-up for
> 'Comcast areas 1, 4 & 5' in zipcode 60640 (chicago north side, lakefront).
> and check the comcast channels in the range 340-379.

lol comcast. All bets are off.

> I'll simply ask, _which_ of those channels will have that extra data stream
> that the head-end inserted?  That the cable compmany doesn't know, or care,
> about, and *how* does it survive the de-multiplexing and re-coding that the
> cable company did?

I'm in agreement with you already, I said on digital the b/w had
already been consumed making it financially unviable. If you paid
they'd leave it alone.

> You apparently have no idea how 'digital TV' is delivered by all the major
> cable companies in the U.S. -- demultiplexed, and transcoded to QAM with 
> each video stream on a separate QAM channel.  I don't see any _possible_
> way for an additional data stream to survive _that_, without explicit 
> intervention/support from the cable company.

They make their own choices overiding the original broadcasters. Net
neutrality is old.

brandon



From cjp at 0x1.net  Thu May 26 09:34:46 2011
From: cjp at 0x1.net (Christopher Pilkington)
Date: Thu, 26 May 2011 10:34:46 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
Message-ID: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>

On Thu, May 26, 2011 at 2:12 AM, Matthew Kaufman <matthew at matthew.at> wrote:
> You just need to move up in frequency a bit. My slowest ham-band link runs at 12 Mbps and my fastest at over 100 Mbps.
>
> Good reminder that I should renumber the IPv4 portion of that network to somewhere in 44.0.0.0/8 however.

What hardware/frequencies/technology are you using for these links?
Repurposed commercial microwave gear?

-cjp



From malayter at gmail.com  Mon May 23 22:16:16 2011
From: malayter at gmail.com (Ryan Malayter)
Date: Mon, 23 May 2011 20:16:16 -0700 (PDT)
Subject: IPv6 Availability on XO
In-Reply-To: <835617D6-5709-467B-91F0-91E20448AEA9@u13.net>
Message-ID: <1720317.5836.1306206976927.JavaMail.geo-discussion-forums@yqhc1>

We have 45 Mbps from XO in our downtown Chicago location in the financial district. We have asked for IPv6 every month for a while, and keep hearing "maybe soon" and not much else. Unfortunately, if we can't get it in that very competitive and dense market location, I doubt they offer it anywhere.

Note to anyone clueful from XO listening: the RFP is going out next month, and IPv6 transit is a MUST.

From jack at crepinc.com  Thu May 26 10:03:13 2011
From: jack at crepinc.com (Jack Carrozzo)
Date: Thu, 26 May 2011 11:03:13 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
Message-ID: <BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>

Nope, mostly HF (under 30mhz) gear at 300baud. Yes, you read that right.
I've seen a couple shorter hops of fractional T1 on 900mhz or 9600baud AX.25
on 144mhz, but there just aren't enough links to use line of site
frequencies.

Push mad bits,

-Jack Carrozzo

On Thu, May 26, 2011 at 10:34 AM, Christopher Pilkington <cjp at 0x1.net>wrote:

> On Thu, May 26, 2011 at 2:12 AM, Matthew Kaufman <matthew at matthew.at>
> wrote:
> > You just need to move up in frequency a bit. My slowest ham-band link
> runs at 12 Mbps and my fastest at over 100 Mbps.
> >
> > Good reminder that I should renumber the IPv4 portion of that network to
> somewhere in 44.0.0.0/8 however.
>
> What hardware/frequencies/technology are you using for these links?
> Repurposed commercial microwave gear?
>
> -cjp
>
>


From cjp at 0x1.net  Thu May 26 10:06:23 2011
From: cjp at 0x1.net (Christopher Pilkington)
Date: Thu, 26 May 2011 11:06:23 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
Message-ID: <BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>

On Thu, May 26, 2011 at 11:03 AM, Jack Carrozzo <jack at crepinc.com> wrote:
> Nope, mostly HF (under 30mhz) gear at 300baud. Yes, you read that right.

You are running IP on this?  And I though 1200 bauds half duplex was slow.



From jra at baylink.com  Thu May 26 10:04:27 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 26 May 2011 11:04:27 -0400 (EDT)
Subject: Re Netflix Is Eating Up More Of North America's Bandwidth Than
	Any Other Company
In-Reply-To: <201105260943.KAA12565@sunf10.rd.bbc.co.uk>
Message-ID: <14577087.728.1306422267259.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Brandon Butterworth" <brandon at rd.bbc.co.uk>

> > I'll simply ask, _which_ of those channels will have that extra data
> > stream
> > that the head-end inserted? That the cable compmany doesn't know, or
> > care,
> > about, and *how* does it survive the de-multiplexing and re-coding
> > that the
> > cable company did?
> 
> I'm in agreement with you already, I said on digital the b/w had
> already been consumed making it financially unviable. If you paid
> they'd leave it alone.

Proving that you're *purposefully* not having the same discussion we are.

PDFTT, folks.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From jack at crepinc.com  Thu May 26 10:13:41 2011
From: jack at crepinc.com (Jack Carrozzo)
Date: Thu, 26 May 2011 11:13:41 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
Message-ID: <BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>

Me personally? No, but I have used it. IP over 9600baud serial actually
isn't that bad for IRC when you're in the middle of the woods and all.

You want slow... read about winlink2000, the email/messaging system for hams
and emergency response. It's PSK on HF, meant to be reliable but if you get
more than 400bps you are doing GREAT! It's so slow that you can run the
software on two laptops using the sound cards, and they'll talk across the
room via speakers and mics no problem. It sounds kinda like robots rapping.

-Jack Carrozzo

On Thu, May 26, 2011 at 11:06 AM, Christopher Pilkington <cjp at 0x1.net>wrote:

> On Thu, May 26, 2011 at 11:03 AM, Jack Carrozzo <jack at crepinc.com> wrote:
> > Nope, mostly HF (under 30mhz) gear at 300baud. Yes, you read that right.
>
> You are running IP on this?  And I though 1200 bauds half duplex was slow.
>


From alex-lists-nanog at yuriev.com  Thu May 26 14:03:44 2011
From: alex-lists-nanog at yuriev.com (Alexander O. Yuriev)
Date: Thu, 26 May 2011 15:03:44 -0400
Subject: Folks running DNS for .extranet.microsoft.com
Message-ID: <20110526190344.GA10935@corp.zubrcom.net>

Hello,

If you are or you know whoever operates the DNS for infrastructure for
.extranet.microsoft.com, could you kindly ping me off the list? You have had
some icky bad ju-ju happening there for a few days.

Alex



From owen at delong.com  Thu May 26 15:02:20 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 26 May 2011 13:02:20 -0700
Subject: Rogers Canada using 7.0.0.0/8 for internal address space
In-Reply-To: <14BA486E-831A-4FFD-A55D-9B5ED50A31B0@matthew.at>
References: <12826530.636.1306286946074.JavaMail.root@benjamin.baylink.com>
	<9B78B479-D716-4B59-950C-B180CD2C34F6@cs.columbia.edu>
	<BANLkTimgbgd8sDwC_thYMXfzrta44vypPA@mail.gmail.com>
	<BANLkTimtn8iVFTwGr+dhqFuN++vXZs00tQ@mail.gmail.com>
	<BANLkTinS5C5YFuMwKMzwiQ+2qSfvf-8fng@mail.gmail.com>
	<20110525202452.GA24806@vacation.karoshi.com.>
	<BANLkTikA0_k_xufhgHtg1Woc=Sj0aBX5+A@mail.gmail.com>
	<9195AE30-8641-428E-A052-F41BF46390EA@delong.com>
	<14BA486E-831A-4FFD-A55D-9B5ED50A31B0@matthew.at>
Message-ID: <490EEF91-5052-4181-87FC-702B4E6F964F@delong.com>


On May 25, 2011, at 11:12 PM, Matthew Kaufman wrote:

> 
> On May 26, 2011, at 7:35 AM, Owen DeLong wrote:
> 
>>> 
>> 
>> Unfortunately, the FCC hasn't really allowed us to since it would be very
>> hard to produce useful bandwidth by today's standards within the bounds
>> of the spectrum we are allowed to use and the channel separations we
>> are allowed to use.
>> 
> 
> You just need to move up in frequency a bit. My slowest ham-band link runs at 12 Mbps and my fastest at over 100 Mbps.
> 

Re: 100Mbps...

Yeah, for a modern household LAN, you're at about 1/3rd my minimum bandwidth and 1/10th my current maximum.

For wide area purposes, you're at about 1/100th of the smallest circuits we're running in the modern backbone.

> Good reminder that I should renumber the IPv4 portion of that network to somewhere in 44.0.0.0/8 however.
> 

Yeah, not a bad idea. Wonder if we can get a /32 for AMPR from IETF since it would be prohibitively expensive to
get it from an RIR.

Owen




From crosevear at skytap.com  Thu May 26 15:19:23 2011
From: crosevear at skytap.com (Carl Rosevear)
Date: Thu, 26 May 2011 13:19:23 -0700
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
Message-ID: <BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>

Used to run IP over AX.25 using KA9Q JNOS back in the day.  HF at 300
baud simplex / half-duplex and VHF 144 Mhz at 1200 with similar
characteristics.  I bought some 9600 baud gear at one point but never
got it all put together before moving on to the regular internet and
(somewhat unfortunately) not really looking back.  I remember
transferring some uuencoded gifs via smtp...  a couple of days later,
if you were lucky, it would complete.  I learned about how protocols
communicate watching packet traces in KA9Q JNOS when I was about 14
years old.  It was really easy when there were guaranteed to be
multiple seconds between packets.  I remember being 14 and feeling
pretty suave when I figured out how to telnet into an SMTP server to
send mail...  of course that is old hat but still good common
troubleshooting these days!


de KB7LIG

--Carl


On Thu, May 26, 2011 at 8:13 AM, Jack Carrozzo <jack at crepinc.com> wrote:
> Me personally? No, but I have used it. IP over 9600baud serial actually
> isn't that bad for IRC when you're in the middle of the woods and all.
>
> You want slow... read about winlink2000, the email/messaging system for hams
> and emergency response. It's PSK on HF, meant to be reliable but if you get
> more than 400bps you are doing GREAT! It's so slow that you can run the
> software on two laptops using the sound cards, and they'll talk across the
> room via speakers and mics no problem. It sounds kinda like robots rapping.
>
> -Jack Carrozzo
>
> On Thu, May 26, 2011 at 11:06 AM, Christopher Pilkington <cjp at 0x1.net>wrote:
>
>> On Thu, May 26, 2011 at 11:03 AM, Jack Carrozzo <jack at crepinc.com> wrote:
>> > Nope, mostly HF (under 30mhz) gear at 300baud. Yes, you read that right.
>>
>> You are running IP on this? ?And I though 1200 bauds half duplex was slow.
>>
>



-- 
Carl Rosevear
Manager of Operations
Skytap, Inc.
direct (206) 588-8899



From drc at virtualized.org  Thu May 26 15:54:10 2011
From: drc at virtualized.org (David Conrad)
Date: Thu, 26 May 2011 10:54:10 -1000
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
Message-ID: <0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>

And I just want to point out that a full /8 (worth $188,911,452.16 at the benchmark rate as set by Microsoft/NNI) is dedicated to AMPR... :-)

When I was at IANA, we (where by "we" I mean Leo Vegoda :-)) looked at trying to reclaim this /8 around the same time we were recovering the /8 dedicated to X.25.  The decentralized nature of administration of 44/8 made this somewhat intractable.  It'll be interesting to see how this plays out in the future address markets.

Regards,
-drc

On May 26, 2011, at 10:19 AM, Carl Rosevear wrote:

> Used to run IP over AX.25 using KA9Q JNOS back in the day.  HF at 300
> baud simplex / half-duplex and VHF 144 Mhz at 1200 with similar
> characteristics.  I bought some 9600 baud gear at one point but never
> got it all put together before moving on to the regular internet and
> (somewhat unfortunately) not really looking back.  I remember
> transferring some uuencoded gifs via smtp...  a couple of days later,
> if you were lucky, it would complete.  I learned about how protocols
> communicate watching packet traces in KA9Q JNOS when I was about 14
> years old.  It was really easy when there were guaranteed to be
> multiple seconds between packets.  I remember being 14 and feeling
> pretty suave when I figured out how to telnet into an SMTP server to
> send mail...  of course that is old hat but still good common
> troubleshooting these days!
> 
> 
> de KB7LIG
> 
> --Carl
> 
> 
> On Thu, May 26, 2011 at 8:13 AM, Jack Carrozzo <jack at crepinc.com> wrote:
>> Me personally? No, but I have used it. IP over 9600baud serial actually
>> isn't that bad for IRC when you're in the middle of the woods and all.
>> 
>> You want slow... read about winlink2000, the email/messaging system for hams
>> and emergency response. It's PSK on HF, meant to be reliable but if you get
>> more than 400bps you are doing GREAT! It's so slow that you can run the
>> software on two laptops using the sound cards, and they'll talk across the
>> room via speakers and mics no problem. It sounds kinda like robots rapping.
>> 
>> -Jack Carrozzo
>> 
>> On Thu, May 26, 2011 at 11:06 AM, Christopher Pilkington <cjp at 0x1.net>wrote:
>> 
>>> On Thu, May 26, 2011 at 11:03 AM, Jack Carrozzo <jack at crepinc.com> wrote:
>>>> Nope, mostly HF (under 30mhz) gear at 300baud. Yes, you read that right.
>>> 
>>> You are running IP on this?  And I though 1200 bauds half duplex was slow.
>>> 
>> 
> 
> 
> 
> -- 
> Carl Rosevear
> Manager of Operations
> Skytap, Inc.
> direct (206) 588-8899
> 
> 




From jack at crepinc.com  Thu May 26 16:02:55 2011
From: jack at crepinc.com (Jack Carrozzo)
Date: Thu, 26 May 2011 17:02:55 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
Message-ID: <BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>

On Thu, May 26, 2011 at 4:54 PM, David Conrad <drc at virtualized.org> wrote:

> The decentralized nature of administration of 44/8 made this somewhat
> intractable.  It'll be interesting to see how this plays out in the future
> address markets.
>

I reckon it'd be about as hard to get back 44/8 as 11/8, but with more
neckbeards. Anytime the fcc tries to reclaim frequencies all these guys come
out of the wood work with the magic phrase 'emergency communications' and
some congressmen get on their side about it.

It will be amusing to see, yes.

-Jack Carrozzo


> On May 26, 2011, at 10:19 AM, Carl Rosevear wrote:
>
> > Used to run IP over AX.25 using KA9Q JNOS back in the day.  HF at 300
> > baud simplex / half-duplex and VHF 144 Mhz at 1200 with similar
> > characteristics.  I bought some 9600 baud gear at one point but never
> > got it all put together before moving on to the regular internet and
> > (somewhat unfortunately) not really looking back.  I remember
> > transferring some uuencoded gifs via smtp...  a couple of days later,
> > if you were lucky, it would complete.  I learned about how protocols
> > communicate watching packet traces in KA9Q JNOS when I was about 14
> > years old.  It was really easy when there were guaranteed to be
> > multiple seconds between packets.  I remember being 14 and feeling
> > pretty suave when I figured out how to telnet into an SMTP server to
> > send mail...  of course that is old hat but still good common
> > troubleshooting these days!
> >
> >
> > de KB7LIG
> >
> > --Carl
> >
> >
> > On Thu, May 26, 2011 at 8:13 AM, Jack Carrozzo <jack at crepinc.com> wrote:
> >> Me personally? No, but I have used it. IP over 9600baud serial actually
> >> isn't that bad for IRC when you're in the middle of the woods and all.
> >>
> >> You want slow... read about winlink2000, the email/messaging system for
> hams
> >> and emergency response. It's PSK on HF, meant to be reliable but if you
> get
> >> more than 400bps you are doing GREAT! It's so slow that you can run the
> >> software on two laptops using the sound cards, and they'll talk across
> the
> >> room via speakers and mics no problem. It sounds kinda like robots
> rapping.
> >>
> >> -Jack Carrozzo
> >>
> >> On Thu, May 26, 2011 at 11:06 AM, Christopher Pilkington <cjp at 0x1.net
> >wrote:
> >>
> >>> On Thu, May 26, 2011 at 11:03 AM, Jack Carrozzo <jack at crepinc.com>
> wrote:
> >>>> Nope, mostly HF (under 30mhz) gear at 300baud. Yes, you read that
> right.
> >>>
> >>> You are running IP on this?  And I though 1200 bauds half duplex was
> slow.
> >>>
> >>
> >
> >
> >
> > --
> > Carl Rosevear
> > Manager of Operations
> > Skytap, Inc.
> > direct (206) 588-8899
> >
> >
>
>
>


From jaime at sensoryresearch.net  Thu May 26 17:07:09 2011
From: jaime at sensoryresearch.net (Jaime Magiera)
Date: Thu, 26 May 2011 18:07:09 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
Message-ID: <27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>

On May 26, 2011, at 5:02 PM, Jack Carrozzo wrote:

> I reckon it'd be about as hard to get back 44/8 as 11/8, but with more
> neckbeards. Anytime the fcc tries to reclaim frequencies all these guys come
> out of the wood work with the magic phrase 'emergency communications' and
> some congressmen get on their side about it.
> 
> It will be amusing to see, yes.


<out of the woodwork>
	from our cold dead hands.
</out of the woodwork>

kd8mzn











From lists at memetic.org  Thu May 26 17:48:48 2011
From: lists at memetic.org (Adam Armstrong)
Date: Thu, 26 May 2011 23:48:48 +0100
Subject: Contention/Oversubscription maths
Message-ID: <4DDED8D0.3010806@memetic.org>

Hi All,

Do any of you have any pointers on how to go about predicting usage for 
high-speed ethernet access?

I'm running 1GE links into buildings, and hanging many (100-1000) 100M 
customers off switches in the basement, simple enough.

I'm assuming ~300Kbps average peak usage per customer, but I can't quite 
work out at what point that number becomes more important than the fact 
that each user can peak at 100mbit (and that the backhaul is only 
access-speed * 10).

I'm well versed in the economies of scale of fitting 10,000 8mbit 
customers into 1GE, but this seems altogether a different beast to 
predict. If any of you have similar scenarios I'd be very interested to 
hear on/off list :)

Finally, what do people think of selling a 1G service with 1G backhaul 
(and potentially 10s or 100s of customers buying this service alongside 
n*100s of customers with 100M service)?

Thanks,
adam.



From crosevear at skytap.com  Thu May 26 19:41:09 2011
From: crosevear at skytap.com (Carl Rosevear)
Date: Thu, 26 May 2011 17:41:09 -0700
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
Message-ID: <BANLkTikKDDdhCqnasdqSKgmkctEDSLDXSQ@mail.gmail.com>

Yeah, so...  the thing is there really are benefits to ham radio for
the community.  I 100% believe in that.  And yes, there are a lot of
neck beards but, honestly, look at some pictures from a NANOG meeting!
 ;)

I have been massively inactive in Amateur Radio for some time.  I miss
it.  However I am acutely aware of how ham plays a very valuable,
amazing role in emergency situations.  Even on a small scale, during
the last Seattle snow (which was pretty much a joke by the standards
of any place that gets real snow) I know that Seattle ACS was
coordinating emergency transportation for dialysis patients that could
not find transportation, things like that.  Things that no
right-minded taxpayer wants to pay for the gov to operate on a
continous basis but things that are really absolutely necessary! In
the California earthquakes, ham has often been the only remaining
method of emergency communications.

Now, did 44/8 help in any of that?  I honestly don't know.  Does
ampr.org really need a /8?  That is probably a very reasonable
question.  Honestly I think there are other protocol stacks that
perform much better for digital transmission than IP on ham radio
anyway.  Is it being managed tightly?  I'd say not in some ways...  I
am very glad to see this still exists from a personal perspective but
I haven't used IP over ham in over 15 years and, well:

dhcp182:~ carlr$ dig kb7lig.ampr.org

; <<>> DiG 9.6.0-APPLE-P2 <<>> kb7lig.ampr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45474
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kb7lig.ampr.org.		IN	A

;; ANSWER SECTION:
kb7lig.ampr.org.	14400	IN	A	44.24.100.9

;; Query time: 217 msec
;; SERVER: 10.1.0.248#53(10.1.0.248)
;; WHEN: Thu May 26 17:27:07 2011
;; MSG SIZE  rcvd: 49



But so here is a "system" that is capable of playing a key role in
improving many peoples' lives (if actually used), helping in
emergencies, assisting during armageddon (?), etc.  There are an awful
lot of netblocks that are used for much less valid things (IMHO)...
but since those make money, everyone endorses it and considers it
"proper".

I fully support ham radio retaining a decent block.  Why don't we all
just speed along this IPv6 adoption thing here.  If anyone deserved to
be allowed to avoid IPv6 is is ham radio.  Just the increase in
address size might add another 12 hours to my image transfer!

But seriously.  I am a networking professional but also a ham.  I
could see looking into shrinking the .ampr.org 44/8 allocation, and if
the right decisions were made I could even support it.  But really I
would vote for improved IPv6 adoption by everyone else as well as
better address utilization by commercial entities before trying to
strip this away from ham radio.


As for the note about spectrum:  ham radio has TINY amounts of
spectrum.  I haven't done the math in years / looked at the numbers
but I think a couple of local TV broadcasts take up more spectrum than
all of the worldwide ham bands combined.  So seriously?  Really?

All that said, IPv4 exhaustion is scary, including to me.  I realize
the world won't come crashing down but the potential business
implications are pretty staggering.

Couple of notes:  my opinion, not necessarily my employers.  also, I
have not been involved in .ampr.org politicking since I was a
teen-ager so I prolly don't have all of the facts.  Please convert any
flames to educational status.  :)


Thanks,


--carl KB7LIG



On Thu, May 26, 2011 at 3:07 PM, Jaime Magiera
<jaime at sensoryresearch.net> wrote:
> On May 26, 2011, at 5:02 PM, Jack Carrozzo wrote:
>
>> I reckon it'd be about as hard to get back 44/8 as 11/8, but with more
>> neckbeards. Anytime the fcc tries to reclaim frequencies all these guys come
>> out of the wood work with the magic phrase 'emergency communications' and
>> some congressmen get on their side about it.
>>
>> It will be amusing to see, yes.
>
>
> <out of the woodwork>
> ? ? ? ?from our cold dead hands.
> </out of the woodwork>
>
> kd8mzn
>
>
>
>
>
>
>
>
>
>



-- 
Carl Rosevear
Manager of Operations
Skytap, Inc.
direct (206) 588-8899



From marcus.sachs at verizon.com  Thu May 26 20:00:39 2011
From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc))
Date: Thu, 26 May 2011 21:00:39 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTikKDDdhCqnasdqSKgmkctEDSLDXSQ@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTikKDDdhCqnasdqSKgmkctEDSLDXSQ@mail.gmail.com>
Message-ID: <DC8E31C01757B14EB9DFF2F0B6DA4F0C2BF55D4DC2@FHDP1LUMXC7V21.us.one.verizon.com>

<geez>
Since we are turning the clock back....I launched my first AX.25 node in 1985 when I was living at Ft. Belvoir, VA.  It was part of the 144 MHz "eastlink" network that ran from Maine to Miami.  Somewhere on a 5-1/2" floppy disk I have an ASCII map of that network.  

You really could hear the packets in those days, even at 1200 Baud.  I used to use a pair of 2M rigs plus a couple of TNCs to teach "datacom" as it was called then.  Lots of fun!
</geez>

73 de KJ4WA




From jack at crepinc.com  Thu May 26 20:03:19 2011
From: jack at crepinc.com (Jack Carrozzo)
Date: Thu, 26 May 2011 21:03:19 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <DC8E31C01757B14EB9DFF2F0B6DA4F0C2BF55D4DC2@FHDP1LUMXC7V21.us.one.verizon.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTikKDDdhCqnasdqSKgmkctEDSLDXSQ@mail.gmail.com>
	<DC8E31C01757B14EB9DFF2F0B6DA4F0C2BF55D4DC2@FHDP1LUMXC7V21.us.one.verizon.com>
Message-ID: <BANLkTimL_gdNjPTekxacOQ1bJxCU8zMv=g@mail.gmail.com>

I still have my TNC here on the shelf... not much use for pushing bits, but
still handy to decode SCADA on 900mhz ;-)

-Jack Carrozzo

On Thu, May 26, 2011 at 9:00 PM, Sachs, Marcus Hans (Marc) <
marcus.sachs at verizon.com> wrote:

> <geez>
> Since we are turning the clock back....I launched my first AX.25 node in
> 1985 when I was living at Ft. Belvoir, VA.  It was part of the 144 MHz
> "eastlink" network that ran from Maine to Miami.  Somewhere on a 5-1/2"
> floppy disk I have an ASCII map of that network.
>
> You really could hear the packets in those days, even at 1200 Baud.  I used
> to use a pair of 2M rigs plus a couple of TNCs to teach "datacom" as it was
> called then.  Lots of fun!
> </geez>
>
> 73 de KJ4WA
>
>
>


From Valdis.Kletnieks at vt.edu  Thu May 26 21:12:12 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 26 May 2011 22:12:12 -0400
Subject: Contention/Oversubscription maths
In-Reply-To: Your message of "Thu, 26 May 2011 23:48:48 BST."
	<4DDED8D0.3010806@memetic.org>
References: <4DDED8D0.3010806@memetic.org>
Message-ID: <5904.1306462332@turing-police.cc.vt.edu>

On Thu, 26 May 2011 23:48:48 BST, Adam Armstrong said:

> Finally, what do people think of selling a 1G service with 1G backhaul 
> (and potentially 10s or 100s of customers buying this service alongside 
> n*100s of customers with 100M service)?

Depends what weasel words you put in your SLA, I suppose.  Can they
claim SLA credits for it being down/unusable if they're only getting 1% of
the throughput they paid for?  And are they a captive audience or not?

What do you do on Patch Tuesday?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110526/b6053e4e/attachment.bin>

From david at davidswafford.com  Thu May 26 21:21:28 2011
From: david at davidswafford.com (David Swafford)
Date: Thu, 26 May 2011 22:21:28 -0400
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDED8D0.3010806@memetic.org>
References: <4DDED8D0.3010806@memetic.org>
Message-ID: <BANLkTiniTzsfp6QE1gW=y-JO77DRK1rSMw@mail.gmail.com>

Hi Adam,

>From the perspective of an enterprise customer, if we're talking
strictly Internet circuits, you're over-subscription estimates seem
very conservative to me.  On our 100mb/s Internet circuits, our
average utilization is about 40mb/s down and 15-20mb/s up on any given
day.


David.



On Thu, May 26, 2011 at 6:48 PM, Adam Armstrong <lists at memetic.org> wrote:
> Hi All,
>
> Do any of you have any pointers on how to go about predicting usage for
> high-speed ethernet access?
>
> I'm running 1GE links into buildings, and hanging many (100-1000) 100M
> customers off switches in the basement, simple enough.
>
> I'm assuming ~300Kbps average peak usage per customer, but I can't quite
> work out at what point that number becomes more important than the fact that
> each user can peak at 100mbit (and that the backhaul is only access-speed *
> 10).
>
> I'm well versed in the economies of scale of fitting 10,000 8mbit customers
> into 1GE, but this seems altogether a different beast to predict. If any of
> you have similar scenarios I'd be very interested to hear on/off list :)
>
> Finally, what do people think of selling a 1G service with 1G backhaul (and
> potentially 10s or 100s of customers buying this service alongside n*100s of
> customers with 100M service)?
>
> Thanks,
> adam.
>
>



From rdobbins at arbor.net  Thu May 26 21:45:50 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Fri, 27 May 2011 02:45:50 +0000
Subject: Contention/Oversubscription maths
In-Reply-To: <5904.1306462332@turing-police.cc.vt.edu>
References: <4DDED8D0.3010806@memetic.org>
	<5904.1306462332@turing-police.cc.vt.edu>
Message-ID: <75AF5BDB-E39D-4DAC-8E0A-88EB342B2AC3@arbor.net>

On May 27, 2011, at 9:12 AM, <Valdis.Kletnieks at vt.edu> <Valdis.Kletnieks at vt.edu> wrote:

> What do you do on Patch Tuesday?


For that matter, what do you do when the latest 'cool' YouTube video go viral, or Amazon offer the next Lady GaGa album on sale for $0.99, or people with iDevices download the latest 300MB+ FPS for their devices (there are several of these available now, and they're quite popular)?

This .pdf preso may be relevant:

<https://files.me.com/roland.dobbins/c07vk1>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde




From wschultz at bsdboy.com  Thu May 26 21:50:37 2011
From: wschultz at bsdboy.com (Wil Schultz)
Date: Thu, 26 May 2011 19:50:37 -0700
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
Message-ID: <BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>

On May 26, 2011 3:08 PM, "Jaime Magiera" <jaime at sensoryresearch.net> wrote:
>
>
> <out of the woodwork>
>        from our cold dead hands.
> </out of the woodwork>
>
> kd8mzn
>

I haven't read the entire thread, but since everyone with a call sign is
checking in...

There are some similarities between bands and ipv4 exhaustion, sure... One
major difference is that those using ipv4 have the option of using ipv6,
where if ham bands are taken they're just gone.

-73
af6ss


From drc at virtualized.org  Thu May 26 21:53:57 2011
From: drc at virtualized.org (David Conrad)
Date: Thu, 26 May 2011 16:53:57 -1000
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
Message-ID: <5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>

On May 26, 2011, at 4:50 PM, Wil Schultz wrote:
> There are some similarities between bands and ipv4 exhaustion, sure... One
> major difference is that those using ipv4 have the option of using ipv6,

Out of curiosity, is there an IPv6 stack for ham devices?

Regards,
-drc




From wschultz at bsdboy.com  Thu May 26 22:14:19 2011
From: wschultz at bsdboy.com (Wil Schultz)
Date: Thu, 26 May 2011 20:14:19 -0700
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
	<5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>
Message-ID: <BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>

On May 26, 2011 7:54 PM, "David Conrad" <drc at virtualized.org> wrote:
>
> On May 26, 2011, at 4:50 PM, Wil Schultz wrote:
> > There are some similarities between bands and ipv4 exhaustion, sure...
One
> > major difference is that those using ipv4 have the option of using ipv6,
>
> Out of curiosity, is there an IPv6 stack for ham devices?
>
> Regards,
> -drc
>

Well there's a loaded question.

So a traditional ham device is a radio, so any protocol you want to run on
top of a radio wave is possible. There are some radios that do have ways to
transfer data, like slow scan and psk31, but that's usually done by a device
connected to the radio.

I won't say that there aren't "ham devices" with an IP stack built in, but I
think we're talking about different layers here.

-wil


From drc at virtualized.org  Thu May 26 22:23:10 2011
From: drc at virtualized.org (David Conrad)
Date: Thu, 26 May 2011 17:23:10 -1000
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
	<5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>
	<BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>
Message-ID: <0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>

On May 26, 2011, at 5:14 PM, Wil Schultz wrote:
> > Out of curiosity, is there an IPv6 stack for ham devices?
> Well there's a loaded question.
...
> I won't say that there aren't "ham devices" with an IP stack built in, but I think we're talking about different layers here.

Sorry, poorly worded.  What I was wondering is there is an equivalent of KA9Q for IPv6.  I believe one of the comments we got back when we were trying to reclaim 44/8 was that folks couldn't migrate to IPv6 because no software was available...

Regards,
-drc




From lyndon at orthanc.ca  Thu May 26 22:32:37 2011
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 26 May 2011 20:32:37 -0700 (PDT)
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
	<5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>
	<BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>
	<0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>
Message-ID: <alpine.OSX.1.10.1105262030090.8190@rastawifi.orthanc.ca>

> Sorry, poorly worded.  What I was wondering is there is an equivalent of 
> KA9Q for IPv6.  I believe one of the comments we got back when we were 
> trying to reclaim 44/8 was that folks couldn't migrate to IPv6 because 
> no software was available...

We've come a little way since NOS.  Linux has native AX25, and it's pretty 
simple to write a KISS adapter for any version of UNIX with a tun driver.



From adrian at creative.net.au  Thu May 26 22:40:29 2011
From: adrian at creative.net.au (Adrian Chadd)
Date: Fri, 27 May 2011 11:40:29 +0800
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <alpine.OSX.1.10.1105262030090.8190@rastawifi.orthanc.ca>
References: <BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
	<5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>
	<BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>
	<0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>
	<alpine.OSX.1.10.1105262030090.8190@rastawifi.orthanc.ca>
Message-ID: <20110527034029.GL24006@skywalker.creative.net.au>

On Thu, May 26, 2011, Lyndon Nerenberg wrote:
> >Sorry, poorly worded.  What I was wondering is there is an equivalent of 
> >KA9Q for IPv6.  I believe one of the comments we got back when we were 
> >trying to reclaim 44/8 was that folks couldn't migrate to IPv6 because 
> >no software was available...
> 
> We've come a little way since NOS.  Linux has native AX25, and it's pretty 
> simple to write a KISS adapter for any version of UNIX with a tun driver.

.. except at such low bit rates, the extra IPv6 header size is not insignificant?




Adrian




From owen at delong.com  Thu May 26 23:04:43 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 26 May 2011 21:04:43 -0700
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <BANLkTikKDDdhCqnasdqSKgmkctEDSLDXSQ@mail.gmail.com>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTikKDDdhCqnasdqSKgmkctEDSLDXSQ@mail.gmail.com>
Message-ID: <214533CE-98B7-4CD5-B908-E36CCC39122C@delong.com>


On May 26, 2011, at 5:41 PM, Carl Rosevear wrote:

> Yeah, so...  the thing is there really are benefits to ham radio for
> the community.  I 100% believe in that.  And yes, there are a lot of
> neck beards but, honestly, look at some pictures from a NANOG meeting!
> ;)
> 

Indeed, there is a club call sign for NANOG. ;-)

I have it on good authority that N4NOG is registered as follows:

N4NOG
North American Network Operators' Group ARC
C/o Robert Seastrom, PO BOX 9303
McLean, VA 22102
USA

Source: http://www.qrz.com

> 
> But so here is a "system" that is capable of playing a key role in
> improving many peoples' lives (if actually used), helping in
> emergencies, assisting during armageddon (?), etc.  There are an awful
> lot of netblocks that are used for much less valid things (IMHO)...
> but since those make money, everyone endorses it and considers it
> "proper".
> 

Given this belief you may want to come stand up for it on the ARIN
public policy mailing list where there is currently a policy being
discussed that attempts to remove needs basis from the criteria
to receive an IPv4 netblock through the directed transfer process.

Owen



From archana.devi.sunder.rajan.2011 at anderson.ucla.edu  Fri May 27 02:23:14 2011
From: archana.devi.sunder.rajan.2011 at anderson.ucla.edu (Sunder Rajan, Archana Devi)
Date: Fri, 27 May 2011 00:23:14 -0700
Subject: IT Survey Request: Win an iPad2 or Kindle!
Message-ID: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>

Dear Nanog Members,

I am a student at UCLA Anderson School of Managment and my MBA field study team is working on a research that involves conducting a survey of CIOs, IT Managers/Administrators, IT Engineers to understand challenges in managing IT infrastructure.

Could you please help by filling out this really short survey?  We are giving away an iPad2 in a raffle draw as well as a Kindle to the person who refers the survey to the most number of people.   You could help us by forwarding the link to other IT folks you know and stand a chance to win a Kindle!  The chances of winning are high as this survey will wrap up in a couple of weeks.

The survey consists of 8 questions and should take less than 5 minutes. All the information provided will be treated as confidential.

Here is the survey link: http://tinyurl.com/ipad2winner

We appreciate your help.

Best Regards,
Archana Rajan
UCLA Executive MBA Candidate, Class of 2011


From andris at hpl.hp.com  Fri May 27 02:47:32 2011
From: andris at hpl.hp.com (Andris Kalnozols)
Date: Fri, 27 May 2011 0:47:32 PDT
Subject: where are all the IPv6 tools?
In-Reply-To: <BANLkTin3bE+780G36Wr5M7WuN4sMHZG9jg@mail.gmail.com>;
	from "Carlos Martinez-Cagnazzo" at May 25, 111 12:41 (noon)
Message-ID: <201105270747.AAA12602@nasdaq.hpl.hp.com>

Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote:
> 
> I'm addicted to sipcalc: http://www.routemeister.net/projects/sipcalc/
> 
> It's available on standard repositories for MacPorts, Ubuntu, Debian
> and Fedora. I guess install is straightforward in other platforms as
> well.
> 
> regards
> 
> Carlos
> 
> On Wed, May 25, 2011 at 4:29 PM, Kyle Duren <pixitha.kyle at gmail.com> wrote:
> > On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen <jayb at braeburn.org> wrote:
> >> Hi,
> >>
> >> I depend on a number of shell tools for manipulating IPv4 addresses,
> >> CIDR blocks, etc. like:
> >>
> >> ?aggis
> >> ?ipsort.pl
> >> ?grepcidr
> >> ?aggregate
> >>
> >> I have not yet found much in terms of similar shell utilities for
> >> IPv6. ?I've spoken to authors of some of these tools and they admit
> >> they have not yet produced IPv6-capable versions. ?(Not trying to name
> >> and shame: those tools are great, I just want more!)
> >>
> >> Do folks here know of IPv6 tools that might provide some of the
> >> functions the above tools provide for IPv4?
> >>
> >> Thanks!
> >>
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Jay B.
> >>
> >>
> >
> > I recommend IPv6gen.
> >
> > http://code.google.com/p/ipv6gen/
> >
> > Very useful. Granted its not what you were asking for exactly....
> >
> > >From the site:
> >
> > "ipv6gen is tool which generates list of IPv6 prefixes of given length
> > from certain prefix according to RFC 3531. (A Flexible Method for
> > Managing the Assignment of Bits of an IPv6 Address Block)"
> >
> > -Kyle
> 


A while ago I was having some conceptual barriers dealing with
sanity-checking a given IPv6 network specification, e.g.,
why are

  2620:0:A0::/48
  2620:0:A00::/43
  2620:0:500::/41

valid but 2620:0:510::/41 not valid?  So I coded up something
that would offer a bit of an explanation:

  checknet 2620:0:510::/41
  The network prefix has more bits than the prefix size:
    2620:0000:0510:0000:0000:0000:0000:0000
                ^
  This is the rightmost non-zero hex digit for a /41 prefix.
  If non-zero, the digit must be an 8.

Otherwise, the tool the quite basic compared to the others
that were mentioned.

  http://ftp.hpl.hp.com/pub/andris/tools/checknet

------
Andris





From lists at memetic.org  Fri May 27 04:49:05 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 10:49:05 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <75AF5BDB-E39D-4DAC-8E0A-88EB342B2AC3@arbor.net>
References: <4DDED8D0.3010806@memetic.org>	<5904.1306462332@turing-police.cc.vt.edu>
	<75AF5BDB-E39D-4DAC-8E0A-88EB342B2AC3@arbor.net>
Message-ID: <4DDF7391.3010207@memetic.org>

On 27/05/2011 03:45, Dobbins, Roland wrote:
> On May 27, 2011, at 9:12 AM,<Valdis.Kletnieks at vt.edu>  <Valdis.Kletnieks at vt.edu>  wrote:
>
>> What do you do on Patch Tuesday?
>
> For that matter, what do you do when the latest 'cool' YouTube video go viral, or Amazon offer the next Lady GaGa album on sale for $0.99, or people with iDevices download the latest 300MB+ FPS for their devices (there are several of these available now, and they're quite popular)?
>
> This .pdf preso may be relevant:
>
> <https://files.me.com/roland.dobbins/c07vk1>

I'm talking of 1000 users on the end of a 1GE, not 50,000. I don't think 
either of these scenarios are worrying.

300MB takes <3seconds on 1GE or 30 seconds on 100M. I don't think those 
kinds of events will have an appreciable effect on the platform here. An 
album is what, 100MB? A 5min HD youtube video is going to be a similar 
size. Also too small to care about. These kinds of things don't get 
worse in high speed, they get easier.

Same with patch tuesday, I think even a Win7 SP1-like release wouldn't 
cause major headaches, as streaming SD TV for an hour is more bandwidth 
than SP1 (nevermind HD).

I'm more interested in the levels of traffic that we will see consistently.

adam.



From Valdis.Kletnieks at vt.edu  Fri May 27 07:02:57 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 27 May 2011 08:02:57 -0400
Subject: Contention/Oversubscription maths
In-Reply-To: Your message of "Fri, 27 May 2011 10:49:05 BST."
	<4DDF7391.3010207@memetic.org>
References: <4DDED8D0.3010806@memetic.org>
	<5904.1306462332@turing-police.cc.vt.edu>
	<75AF5BDB-E39D-4DAC-8E0A-88EB342B2AC3@arbor.net>
	<4DDF7391.3010207@memetic.org>
Message-ID: <33547.1306497777@turing-police.cc.vt.edu>

On Fri, 27 May 2011 10:49:05 BST, Adam Armstrong said:
> I'm talking of 1000 users on the end of a 1GE, not 50,000. I don't think 
> either of these scenarios are worrying.
> 
> 300MB takes <3seconds on 1GE or 30 seconds on 100M.

The pont is that it takes a lot longer than 3 seconds if that uplink is already
90% full - it just jumped to 30 seconds.  How long does it take for all 1000 users
to do it, assuming the pipe is 95% full already?

> A 5min HD youtube video is going to be a similar size.

What's the sound of 1000 Netfllix users streaming 1000 different 90 minute
long HD movies?  Why should they limit themselves to 5 minute videos? After
all, you sold them *gigabit*, which we know is 125 times as fast as the 8mit
you're likely to get from that cable company (and that's when you're going to
need those weasel words in your SLA when you can't deliver gigabit).

(You never said if this is a commercial or residential buildout - the traffic patterns,
concerns, and complaints will differ for the two. Good luck in any case)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110527/f1476dd1/attachment.bin>

From lists at memetic.org  Fri May 27 07:14:19 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 13:14:19 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <5904.1306462332@turing-police.cc.vt.edu>
References: <4DDED8D0.3010806@memetic.org>
	<5904.1306462332@turing-police.cc.vt.edu>
Message-ID: <4DDF959B.2050601@memetic.org>

On 27/05/2011 03:12, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 26 May 2011 23:48:48 BST, Adam Armstrong said:
>
>> Finally, what do people think of selling a 1G service with 1G backhaul
>> (and potentially 10s or 100s of customers buying this service alongside
>> n*100s of customers with 100M service)?
> Depends what weasel words you put in your SLA, I suppose.  Can they
> claim SLA credits for it being down/unusable if they're only getting 1% of
> the throughput they paid for?  And are they a captive audience or not?
No SLA, residential customers.

1% is quite unlikely to happen, it would require every customer in a 
very large deployment to be trying to download >1mbit/sec at the same time.

Peak average usage for most UK broadband installations seem to be 
between 20 and 100Kb/sec. I'm working on the basis of 300Kb/sec because 
our access speeds are much higher.

(this would suggest 300Mbit/sec peak for 1000 users, but my question is 
whether we'll see that level of aggregation at 1000 * 100Mb on 1GE, or 
whether it's going to be very 'peaky', and we'll only see that 
smoothness when we aggregate 10-15 buildings onto 10GE)

> What do you do on Patch Tuesday?

Update windows.

adam.




From jared at puck.nether.net  Fri May 27 07:45:36 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 27 May 2011 08:45:36 -0400
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDF959B.2050601@memetic.org>
References: <4DDED8D0.3010806@memetic.org>
	<5904.1306462332@turing-police.cc.vt.edu>
	<4DDF959B.2050601@memetic.org>
Message-ID: <CE2C11B7-1585-4803-90FF-C1CDD1A8F921@puck.nether.net>


On May 27, 2011, at 8:14 AM, Adam Armstrong wrote:

> No SLA, residential customers.

I would watch out for the 'abusers' in this case, and have the capability to rate-limit the ports if necessary.  Some hardware doesn't deal well with 'small' buckets of rate-limiting, eg: taking a 1G port to 1M.

I'm interested in your operational results, as i've had a few general ASSumptions i've offered in this space:

- Most people are going to be limited by their wireless gear (few people care to run wired very far)
- Most servers on the far-end aren't going to be fast enough to cope
- Most people aren't going to spend time debugging network problems
- Some percentage of users are going to run a torrent or something else and flatline their port.  You need to be able to police them at a reasonable bandwidth cap, eg: 10M if they have 1G, but that's 1% and many dumber switches won't go under 10%.

The other solution is to just throw more bandwidth at the problem.  Make sure your switches can easily take a 10G or n*10G uplink.

I'd expect that the single bursty user is going to drown out the rest of them into the noise, as they will likely plug in directly and have no wireless hops that limit their speeds.

One of my friends operates a WISP in this area and has periodic issues with the heavy usage users and wonders what they're doing with that 150GB of data they "download" in a month.

- Jared


From lists at memetic.org  Fri May 27 07:54:11 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 13:54:11 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <1306500275.1709.56.camel@icts-sp-039>
References: <4DDED8D0.3010806@memetic.org>	
	<5904.1306462332@turing-police.cc.vt.edu>	
	<75AF5BDB-E39D-4DAC-8E0A-88EB342B2AC3@arbor.net>	
	<4DDF7391.3010207@memetic.org>
	<1306500275.1709.56.camel@icts-sp-039>
Message-ID: <4DDF9EF3.8080102@memetic.org>

On 27/05/2011 13:44, Jeroen van Ingen wrote:
> Hi Adam,
>
>> I'm talking of 1000 users on the end of a 1GE, not 50,000. I don't think
>> either of these scenarios are worrying.
>>
>> 300MB takes<3seconds on 1GE or 30 seconds on 100M. I don't think those
>> kinds of events will have an appreciable effect on the platform here. An
>> album is what, 100MB? A 5min HD youtube video is going to be a similar
>> size. Also too small to care about. These kinds of things don't get
>> worse in high speed, they get easier.
>>
>> Same with patch tuesday, I think even a Win7 SP1-like release wouldn't
>> cause major headaches, as streaming SD TV for an hour is more bandwidth
>> than SP1 (nevermind HD).
>>
>> I'm more interested in the levels of traffic that we will see consistently.
> Perhaps students are not average users, but our Resnet currently has:
> * Approx 2000 connections, most at 100 Mbps.
> * These are divided into 4 areas, each area is connected with 1 Gbps to
> central location (so on average you could say we have 500 users sharing
> a 1 Gbps link)
> * Central location has 10 Gbps uplink; stats for this link over the last
> 7 days at 10-min average polling interval are:
> in: min 422 Mbps, avg 883 Mbps, max 1570 Mbps, 95th pct 1250 Mbps.
> out: min 48 Mbps, avg 272 Mbps, max 571 Mbps, 95th pct 459 Mbps.
>
> Perhaps these numbers can be used as an indication for your
> sizing/design.
Most useful response so far, thanks very much :)

adam.



From lists at memetic.org  Fri May 27 08:01:46 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 14:01:46 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <CE2C11B7-1585-4803-90FF-C1CDD1A8F921@puck.nether.net>
References: <4DDED8D0.3010806@memetic.org>
	<5904.1306462332@turing-police.cc.vt.edu>
	<4DDF959B.2050601@memetic.org>
	<CE2C11B7-1585-4803-90FF-C1CDD1A8F921@puck.nether.net>
Message-ID: <4DDFA0BA.9020605@memetic.org>

On 27/05/2011 13:45, Jared Mauch wrote:
> On May 27, 2011, at 8:14 AM, Adam Armstrong wrote:
>
>> No SLA, residential customers.
> I would watch out for the 'abusers' in this case, and have the capability to rate-limit the ports if necessary.  Some hardware doesn't deal well with 'small' buckets of rate-limiting, eg: taking a 1G port to 1M.
>
> I'm interested in your operational results, as i've had a few general ASSumptions i've offered in this space:
>
> - Most people are going to be limited by their wireless gear (few people care to run wired very far)
This results in people complaining *about* us, as the crappy performance 
of 802.11g made a lot of people complain about ADSL2+ ISPs (because G 
can't really do 24Mbit!)
> - Most servers on the far-end aren't going to be fast enough to cope
This holds true until you look at services delivered by farms, such as 
Akamai, Usenet or P2P. I'd be interested to see what happens with 1000 
people with 1000Mbit services start torrenting the next major HD movie 
release.
> - Most people aren't going to spend time debugging network problems
Indeed, they just moan about us instead :(
> - Some percentage of users are going to run a torrent or something else and flatline their port.  You need to be able to police them at a reasonable bandwidth cap, eg: 10M if they have 1G, but that's 1% and many dumber switches won't go under 10%.
Policing isn't something we want to do (other than to police 100Mbit 
ports to 20Mbit for those who buy the 20Mbit product. Policing is 
against the ethos of the company.)
> The other solution is to just throw more bandwidth at the problem.  Make sure your switches can easily take a 10G or n*10G uplink.
>
> I'd expect that the single bursty user is going to drown out the rest of them into the noise, as they will likely plug in directly and have no wireless hops that limit their speeds.
This what i see elsewhere in buildings with similar mixes of customers 
as we're expecting. For example in a building with ~1000 2-100Mbit 
customers a single 100mbit customer can pretty much double the peak 
traffic usage of a building if they decide to download a lot.
> One of my friends operates a WISP in this area and has periodic issues with the heavy usage users and wonders what they're doing with that 150GB of data they "download" in a month.

I've been known to download ~1.5TB in  month on my 24Mbit ADSL service.

It's people like *me* that I'm worried about. Our deployment model means 
that individual customers can't chose us, we chose which buildings we 
connect and then are likely to get most people within that building, so 
I'm hoping our hoggers should be fairly spread out. Though, I'm sure 
this won't be the case as certain areas of the city are likely to have 
more of each specific kinds of network user.

Our upgrade plans include 10GE to buildings when the building has a 
large number of occupants (>1000), but before then it's cost prohibitive.

adam.



From shadowedstranger at gmail.com  Fri May 27 08:02:07 2011
From: shadowedstranger at gmail.com (Jacob Broussard)
Date: Fri, 27 May 2011 06:02:07 -0700
Subject: Contention/Oversubscription maths
Message-ID: <BANLkTimAJSJRPEovhCyTqkU5CYF_20ei4A@mail.gmail.com>

I don't use almost any bandwidth outside of Netflix, Steam game downloads,
and getting my daily dose of streaming starcraft videos and ntop tells me I
averaged 1.7mbps over the last month.  Mind you this is on an 8mbps peak
connection.  With peak speeds of 8m I would be pissed if I was getting 500k,
much less if I had a 100m connection and got less than a meg.  I have no
doubt that if I had a faster connection that I would have used even more
bandwidth... With the popularity of streaming video now a 1000:1 or even a
100:1 oversubscription rate is almost definitely just going to cause you
headaches...  Back in my days of noc, 9 out of 10 bandwidth AUP abusers
weren't even using torrents, they were almost all netflix or people that got
rid of cable to watch video online.


From lists at memetic.org  Fri May 27 08:07:49 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 14:07:49 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <BANLkTimAJSJRPEovhCyTqkU5CYF_20ei4A@mail.gmail.com>
References: <BANLkTimAJSJRPEovhCyTqkU5CYF_20ei4A@mail.gmail.com>
Message-ID: <4DDFA225.1030505@memetic.org>

On 27/05/2011 14:02, Jacob Broussard wrote:
>
> I don't use almost any bandwidth outside of Netflix, Steam game 
> downloads, and getting my daily dose of streaming starcraft videos and 
> ntop tells me I averaged 1.7mbps over the last month.  Mind you this 
> is on an 8mbps peak connection.  With peak speeds of 8m I would be 
> pissed if I was getting 500k, much less if I had a 100m connection and 
> got less than a meg.  I have no doubt that if I had a faster 
> connection that I would have used even more bandwidth... With the 
> popularity of streaming video now a 1000:1 or even a 100:1 
> oversubscription rate is almost definitely just going to cause you 
> headaches...  Back in my days of noc, 9 out of 10 bandwidth AUP 
> abusers weren't even using torrents, they were almost all netflix or 
> people that got rid of cable to watch video online.
>
I suspect your average usage is an order of magnitude higher than that 
of the 'average' user.

This is one of the effects that makes it hard for me to imagine the 
traffic profile, as my own usage patterns (and those of my circle of 
friends) is not what one would call typical.

For example if 300KB/sec average peak holds true with only 1000 users, 
that's only 300Mbit usage, giving 700Mbit headroom. I suspect this will 
only become true with 10000 users on 10G though, and that 1G links will 
be much more bursty as a single customer can push 10% of the backhaul speed.

Remeber that 1000:1 contention *doesn't* mean that you only get 1000th 
of the backhaul speed, it means the *peak average* usage of all users 
should be under 1Mbit. Your peak is most likely 8Mbit, but there are 
probably 40 users who use very liuttle for every one of you, and they 
may only double the peak average to 16mbit, thereby giving a much lower 
peak average for all 41 of you (if you see what i mean?)

I suck at maths, and I'm pretty sure I was at home playing Tekken 2 when 
I should have been in statistics class :)

adam.



From joelja at bogus.com  Fri May 27 05:30:38 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 27 May 2011 03:30:38 -0700
Subject: New vyatta-nsp list
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3439@RWC-EX1.corp.seven.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan><4DDC0A0A.5020304@rhavenindustrys.com><BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com><BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
	<BANLkTin8oZe2ZPkBAZVfAxc-QmrBRKdd2A@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3439@RWC-EX1.corp.seven.com>
Message-ID: <ED664CD8-2922-4475-8191-734AF5DFD42C@bogus.com>


On May 24, 2011, at 7:52 PM, George Bonser wrote:

>> The graphs show near 100% CPU usage at small packet sizes, and low
>> PPS. That would lead to a pretty easy to launch DDoS against a
>> software based router platform.
>> Since there isn't a separation between control plane/forwarding plane,
>> an attacker could trivially take you offline. I'd imagine due to the
>> nature of x86 platform, being interrupt based and forwarding table
>> residing in memory the CPU has to access, theres a finite amount you
>> can scale this without risking big disruptions from a relatively small
>> DDoS.
>> 
>> Not saying software platforms can't achieve good throughput, there has
>> to be a realization of the limits of the platform, and when it
>> shouldn't be used.
>> Again, I personally use the Vyatta commercial software, and it works
>> great, so I'm not knocking it. But I wouldn't consider it high-end
>> performance when a few million PPS can lead to service disruptions.
>> 
>> --
>> Brent Jones
>> brent at servuhome.net
> 
> Every tool has its use.  Also, they have several different sized
> appliances.   How much CPU use you get depends on how many cores you
> throw at the problem.  They can use multiple cores/processors.  The
> result given in one test might not match someone else's test if they
> have higher end hardware, maybe better than the appliances Vyatta ships.

It's actually rather hard with current pc hardware to get to multiple cores engaged in paralell per input interfaces. while you can plan for various cases the the one to account for is the small packet performance not overwhelming the capabilities of a single cpu core.

> But the primary point I am trying to make is if you have an office with
> sub-gigabit connectivity and you need NAT and firewalling and VPNs, it
> might be a very cost-effective solution.   It might not be a good
> solution in a different environment.  It is sort of like pointing out
> that your neighbor's Accord doesn't have the performance characteristics
> of a Ferrari but your neighbor only drives in rush hour on roads with a
> maximum speed of 65 MPH.  The Ferrari would cost much more money, cost
> more to support over time, and not get him to work any faster.
> 
> If one is never going to pass enough traffic to get anywhere near the
> maximum performance of the unit anyway, why spend so much more money?
> Besides, on most integrated firewall/NAT/VPN units I have used in the
> past, I have run them out of CPU from VPN and NAT long before they ever
> reached their maximum traffic throughput.
> 
> 
> 
> 




From shadowedstranger at gmail.com  Fri May 27 08:40:02 2011
From: shadowedstranger at gmail.com (Jacob Broussard)
Date: Fri, 27 May 2011 06:40:02 -0700
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDFA225.1030505@memetic.org>
References: <BANLkTimAJSJRPEovhCyTqkU5CYF_20ei4A@mail.gmail.com>
	<4DDFA225.1030505@memetic.org>
Message-ID: <BANLkTikRi96an0Pjt7Hh_u5xEK3tRxPn_Q@mail.gmail.com>

I apologize if you thought I was trying to call you out or correct you; I
was merely trying to provide some perspective.  Sorry if I came off as
hostile.  I understand that a 1000:1 does not mean that you get 1000th the
backhaul speed, no need for the snarky remarks.  I simply stated that it may
cause you headaches as in the past we had a 35:1 ratio and were at capacity
most of the day (12-16 hours). We offer peak speeds of 4mbps, and we have an
extrordinary amount of people using (abusing as some would say) streaming
video for many hours of the day causing headaches for us.  You probably
would be safe to assume that you can use a higher ratio for your higher
speeds as there will be fewer people that can take advantage of the full
connection speed.  Again, not trying to come off as aggressive or hostile,
just trying to provide some more perspective to help you out.
On May 27, 2011 6:07 AM, "Adam Armstrong" <lists at memetic.org> wrote:
> On 27/05/2011 14:02, Jacob Broussard wrote:
>>
>> I don't use almost any bandwidth outside of Netflix, Steam game
>> downloads, and getting my daily dose of streaming starcraft videos and
>> ntop tells me I averaged 1.7mbps over the last month. Mind you this
>> is on an 8mbps peak connection. With peak speeds of 8m I would be
>> pissed if I was getting 500k, much less if I had a 100m connection and
>> got less than a meg. I have no doubt that if I had a faster
>> connection that I would have used even more bandwidth... With the
>> popularity of streaming video now a 1000:1 or even a 100:1
>> oversubscription rate is almost definitely just going to cause you
>> headaches... Back in my days of noc, 9 out of 10 bandwidth AUP
>> abusers weren't even using torrents, they were almost all netflix or
>> people that got rid of cable to watch video online.
>>
> I suspect your average usage is an order of magnitude higher than that
> of the 'average' user.
>
> This is one of the effects that makes it hard for me to imagine the
> traffic profile, as my own usage patterns (and those of my circle of
> friends) is not what one would call typical.
>
> For example if 300KB/sec average peak holds true with only 1000 users,
> that's only 300Mbit usage, giving 700Mbit headroom. I suspect this will
> only become true with 10000 users on 10G though, and that 1G links will
> be much more bursty as a single customer can push 10% of the backhaul
speed.
>
> Remeber that 1000:1 contention *doesn't* mean that you only get 1000th
> of the backhaul speed, it means the *peak average* usage of all users
> should be under 1Mbit. Your peak is most likely 8Mbit, but there are
> probably 40 users who use very liuttle for every one of you, and they
> may only double the peak average to 16mbit, thereby giving a much lower
> peak average for all 41 of you (if you see what i mean?)
>
> I suck at maths, and I'm pretty sure I was at home playing Tekken 2 when
> I should have been in statistics class :)
>
> adam.


From lists at memetic.org  Fri May 27 08:45:28 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 14:45:28 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <BANLkTikRi96an0Pjt7Hh_u5xEK3tRxPn_Q@mail.gmail.com>
References: <BANLkTimAJSJRPEovhCyTqkU5CYF_20ei4A@mail.gmail.com>	<4DDFA225.1030505@memetic.org>
	<BANLkTikRi96an0Pjt7Hh_u5xEK3tRxPn_Q@mail.gmail.com>
Message-ID: <4DDFAAF8.2080909@memetic.org>

On 27/05/2011 14:40, Jacob Broussard wrote:
>
> We offer peak speeds of 4mbps, and we have an extrordinary amount of 
> people using (abusing as some would say) streaming video for many 
> hours of the day causing headaches for us.  You probably would be safe 
> to assume that you can use a higher ratio for your higher speeds as 
> there will be fewer people that can take advantage of the full 
> connection speed.
>
This is pretty much what I expect. If you give a 4Mbit user 40Mbit, he 
tends not to even be able to use 10 times as much, so we can get away 
with much higher ratios.

Statistics and graphs i've seen offlist have been very helpful, and 
suggest that 1000 100mbit customers is doable on 1GE.

Atleast, today. Next year's (decade?) launch of the YouView platform in 
the UK should increase usage a lot, not to mention a service like 
Netflix starting in the UK. We have some movie streaming services, but 
they generally suck and are quite low bitrate.

Thanks for the thoughts :D
adam.



From william.allen.simpson at gmail.com  Fri May 27 09:00:20 2011
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Fri, 27 May 2011 10:00:20 -0400
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>	<5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>	<BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>
	<0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>
Message-ID: <4DDFAE74.5000901@gmail.com>

On 5/26/11 11:23 PM, David Conrad wrote:
> On May 26, 2011, at 5:14 PM, Wil Schultz wrote:
>>> Out of curiosity, is there an IPv6 stack for ham devices?
>> Well there's a loaded question.
> ...
>> I won't say that there aren't "ham devices" with an IP stack built in, but I think we're talking about different layers here.
>
> Sorry, poorly worded.  What I was wondering is there is an equivalent of KA9Q for IPv6.  I believe one of the comments we got back when we were trying to reclaim 44/8 was that folks couldn't migrate to IPv6 because no software was available...
>
Well, I wrote a lot of the original IPv6 stuff (back when it was PIPE -> SIP ->
SIPP) for KA9Q, have the source around here somewhere....

But now I'd just use Linux.  Alan Cox ported the KA9Q AX25 code long ago.

Since everybody and his brother is coming out of the woodwork -- sadly, I've
not done any AX25 since my grandfather Marvin Allen Maten (W8TQP) died; that
was one of the things we did together.  Although he was a ham since circa 1916,
he was always wanting to try the latest!  His QSL contacts went back so far, he
knew Hugo Gernsback and his brother (who actually ran the electronics store).



From jra at baylink.com  Fri May 27 09:23:04 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 27 May 2011 10:23:04 -0400 (EDT)
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDF7391.3010207@memetic.org>
Message-ID: <26560069.836.1306506184408.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Adam Armstrong" <lists at memetic.org>

> I'm more interested in the levels of traffic that we will see
> consistently.

You're planning to engage in Statistical Multiplexing, or what I've always
termed "bandwidth surfing": how hard can I oversubscribe my uplink without
pissing off the paying customers?

As others have suggested, it depends on quite a number of things, primarily:
whether you're offering an SLA to the customers or not.  Whether you have
a caching proxy or not and which CDNs you solicit to provision your node
are also big factors, of course.

In the final analysis, though, it depends on the customer class.

Residence customers will tolerate a lot more oversubscription than business,
enterprise, and server going on down the list of oversubscription, but
happily *up* the list of "how much can I charge".  Remember that QoS and 
load shaping don't work all that will across the internet at large,
but they work pretty decently inside a single switch; you can prioritize
customers who are willing to pay extra for it.  The problem is similar
to airline bookings; it is possible, in the immortal words of Dave Barry,
to envision a situation -- this will happen in your lifetime -- where
no two customers pay exactly the same price.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From michael.holstein at csuohio.edu  Fri May 27 09:24:22 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Fri, 27 May 2011 10:24:22 -0400
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>
Message-ID: <4DDFB416.6040808@csuohio.edu>


> I am a student at UCLA Anderson School of Managment and my MBA field study team is working on a research that involves conducting a survey of CIOs, IT Managers/Administrators, IT Engineers to understand challenges in managing IT infrastructure.
>
> Could you please help by filling out this really short survey? 

A more cynical view would be as an MBA student, you're researching
cheaper ways to recruit contact information and current projects. A
kindle is $139 .. that's pretty cheap for a list of people/projects
considering what that lead information is worth to vendors of the
"solutions" to the challenges you ask about.


Regards,

Michael Holstein
Cleveland State University



From jra at baylink.com  Fri May 27 09:28:41 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 27 May 2011 10:28:41 -0400 (EDT)
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDFAAF8.2080909@memetic.org>
Message-ID: <14894863.840.1306506521760.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Adam Armstrong" <lists at memetic.org>

> Statistics and graphs i've seen offlist have been very helpful, and
> suggest that 1000 100mbit customers is doable on 1GE.

Probably.

> Atleast, today. Next year's (decade?) launch of the YouView platform in
> the UK should increase usage a lot, not to mention a service like
> Netflix starting in the UK. We have some movie streaming services, but
> they generally suck and are quite low bitrate.

The short version is: if you oversubscribe, you *will* eventually have Busy
Hours, just like telcos.  The question is: how often.  Telcos have books
that tell them this...

Cheers,
-- jr 'Royal Wedding' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From sbryant at thepit.org  Fri May 27 09:49:45 2011
From: sbryant at thepit.org (Shaun Bryant)
Date: Fri, 27 May 2011 08:49:45 -0600
Subject: Contention/Oversubscription maths
In-Reply-To: <14894863.840.1306506521760.JavaMail.root@benjamin.baylink.com>
References: <4DDFAAF8.2080909@memetic.org>
	<14894863.840.1306506521760.JavaMail.root@benjamin.baylink.com>
Message-ID: <BANLkTimS7XF-y+5o3V4ZuwoKNOdOVV5z_Q@mail.gmail.com>

I run a WISP, where we have moved customers from 3mb/s to 8mb/s to 20mb/s
over the course of 5 years. We do this one tower at a time (about 150
customers) what we have learned is usage grows overtime not with the
increase in available bandwidth.  Our Per-Customer-Avg (PCA) stayed about
the same with each bump in bandwidth, the avg user does not use more
bandwidth because they have more bandwidth or at least not our 1200
customers.

That said we have had our PCA move up more then 30% in the last 7 months due
mainly to Netflix, the nice thing is this usage is "off peak" for
our business customers and as such has not been a concern.

Shaun



Shaun Bryant
sbryant at thepit.org


From lists at memetic.org  Fri May 27 09:52:08 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 15:52:08 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <BANLkTimS7XF-y+5o3V4ZuwoKNOdOVV5z_Q@mail.gmail.com>
References: <4DDFAAF8.2080909@memetic.org>	<14894863.840.1306506521760.JavaMail.root@benjamin.baylink.com>
	<BANLkTimS7XF-y+5o3V4ZuwoKNOdOVV5z_Q@mail.gmail.com>
Message-ID: <4DDFBA98.20307@memetic.org>

On 27/05/2011 15:49, Shaun Bryant wrote:
> I run a WISP, where we have moved customers from 3mb/s to 8mb/s to 
> 20mb/s over the course of 5 years. We do this one tower at a time 
> (about 150 customers) what we have learned is usage grows overtime not 
> with the increase in available bandwidth.  Our Per-Customer-Avg (PCA) 
> stayed about the same with each bump in bandwidth, the avg user does 
> not use more bandwidth because they have more bandwidth or at least 
> not our 1200 customers.
>
> That said we have had our PCA move up more then 30% in the last 7 
> months due mainly to Netflix, the nice thing is this usage is "off 
> peak" for our business customers and as such has not been a concern.
>

Yeah, I fully expect this.

In previous networks I've generally seen a doubling of traffic every 12 
months. Generally the traffic is static during spring/summer, and then 
doubles over 6 months in autumn/winter.

Though, I'm not sure how this will manifest itself with such high access 
speeds.

adam.



From smb at cs.columbia.edu  Fri May 27 10:14:47 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 27 May 2011 11:14:47 -0400
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <4DDFB416.6040808@csuohio.edu>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>
	<4DDFB416.6040808@csuohio.edu>
Message-ID: <BC90DBDF-6AE0-494A-96DB-EA84796C018A@cs.columbia.edu>


On May 27, 2011, at 10:24 22AM, Michael Holstein wrote:

> 
>> I am a student at UCLA Anderson School of Managment and my MBA field study team is working on a research that involves conducting a survey of CIOs, IT Managers/Administrators, IT Engineers to understand challenges in managing IT infrastructure.
>> 
>> Could you please help by filling out this really short survey? 
> 
> A more cynical view would be as an MBA student, you're researching
> cheaper ways to recruit contact information and current projects. A
> kindle is $139 .. that's pretty cheap for a list of people/projects
> considering what that lead information is worth to vendors of the
> "solutions" to the challenges you ask about.

I know nothing of this student, the school, or the study.  I will say --
as an academic who frequently does research involving human subjects, 
generally including surveys -- that this is a very normal way to
proceed.  Finding enough subjects is always hard; it's the single
biggest obstacle we encounter.  Paying people is the usual approach,
but for a group like this, the usual nominal amount we pay undergrads
($10-25) isn't enough.  Other common approaches -- flyers all over
campus, offers on Mechanical Turk, ads on Facebook or Google Adwords,
etc. -- won't work if you're trying to get people with specialized
knowledge or skills.  What's left?

I might add that by federal law, all government-funded research
involving human subjects has to be approved by an "IRB" -- an
Institutional Review Board -- and many universities (including my
own) impose that requirement on all research, even if no federal
funds are involved.  While it's certainly not rare to do studies that
involve (initial) deceit of the subjects (you want them reacting
normally, rather than giving the answers they think you want), the
IRB has to see the full protocol and experiment design.

You may be right, of course; I can't say.  I haven't contacted the
student's professor nor have I asked to see the IRB protocol.  Given
that any legitimate study of this type would be conducted along the
lines explained in the original post, I'd say that the burden of
proof is on you.  (Of course, as a security guy I know full well
that that notion of "normal behavior" is the best way to hide an
attack.)

References: http://www.usenix.org/events/upsec08/tech/full_papers/garfinkel/garfinkel.pdf
	    https://www.cs.columbia.edu/~smb/papers/wecsr2011-irb.pdf

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








From jcdill.lists at gmail.com  Fri May 27 10:38:39 2011
From: jcdill.lists at gmail.com (JC Dill)
Date: Fri, 27 May 2011 08:38:39 -0700
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <4DDFB416.6040808@csuohio.edu>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>
	<4DDFB416.6040808@csuohio.edu>
Message-ID: <4DDFC57F.2030900@gmail.com>

  On 27/05/11 7:24 AM, Michael Holstein wrote:
>
> > I am a student at UCLA Anderson School of Managment and my MBA
> > field study team is working on a research that involves conducting
> > a survey of CIOs, IT Managers/Administrators, IT Engineers to
> > understand challenges in managing IT infrastructure.
> >
> > Could you please help by filling out this really short survey?
>
>  A more cynical view

The cynic in me wonders how they will track how many people I forwarded 
this to. I plan to win the prize for "the person who refers the survey 
to the most number of people" by forwarding it to millions of people.  :-)

(I suspect that the prize will be won by the person who others (who take 
the survey) claim referred them to the survey, which is different from 
the criteria set for the prize.)

jc




From scott.brim at gmail.com  Fri May 27 10:52:20 2011
From: scott.brim at gmail.com (Scott Brim)
Date: Fri, 27 May 2011 11:52:20 -0400
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <4DDFC57F.2030900@gmail.com>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>
	<4DDFB416.6040808@csuohio.edu> <4DDFC57F.2030900@gmail.com>
Message-ID: <BANLkTi=LE2KOcK8EG7imX1PJ3-W4usvAqg@mail.gmail.com>

On Fri, May 27, 2011 at 11:38, JC Dill <jcdill.lists at gmail.com> wrote:
> The cynic in me wonders how they will track how many people I forwarded this
> to. I plan to win the prize for "the person who refers the survey to the
> most number of people" by forwarding it to millions of people. ?:-)
>
> (I suspect that the prize will be won by the person who others (who take the
> survey) claim referred them to the survey, which is different from the
> criteria set for the prize.)

If you'll say that I'm the one who referred you, I'll enter you in a
drawing for a free iPad.



From lists at memetic.org  Fri May 27 10:58:50 2011
From: lists at memetic.org (Adam Armstrong)
Date: Fri, 27 May 2011 16:58:50 +0100
Subject: Contention/Oversubscription maths
In-Reply-To: <26560069.836.1306506184408.JavaMail.root@benjamin.baylink.com>
References: <26560069.836.1306506184408.JavaMail.root@benjamin.baylink.com>
Message-ID: <4DDFCA3A.9060006@memetic.org>

On 27/05/2011 15:23, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Adam Armstrong"<lists at memetic.org>
>
> Residence customers will tolerate a lot more oversubscription than business,
> enterprise, and server going on down the list of oversubscription, but
> happily *up* the list of "how much can I charge".  Remember that QoS and
> load shaping don't work all that will across the internet at large,
> but they work pretty decently inside a single switch; you can prioritize
> customers who are willing to pay extra for it.  The problem is similar
> to airline bookings; it is possible, in the immortal words of Dave Barry,
> to envision a situation -- this will happen in your lifetime -- where
> no two customers pay exactly the same price.  :-)
We're hoping we don't have to do any QoS or shaping, as we don't want 
any links to be saturated. From the data i've gotten it seems that is 
possible with many hundreds of 100Mbit customers on a 1000Mbit backhaul.

The 1G product is the exception to that, and it's a little unclear where 
that sits, probably in a box labelled "here be failure".

adam.



From archana.devi.sunder.rajan.2011 at anderson.ucla.edu  Fri May 27 11:34:35 2011
From: archana.devi.sunder.rajan.2011 at anderson.ucla.edu (Sunder Rajan, Archana Devi)
Date: Fri, 27 May 2011 09:34:35 -0700
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <BC90DBDF-6AE0-494A-96DB-EA84796C018A@cs.columbia.edu>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>
	<4DDFB416.6040808@csuohio.edu>,
	<BC90DBDF-6AE0-494A-96DB-EA84796C018A@cs.columbia.edu>
Message-ID: <B83BBEA1883107428F511BCEB308FB431BBAF39D80@EM11.ad.ucla.edu>

[Steve Wrote] as an academic who frequently does research involving human subjects, generally including surveys -- that this is a very normal way to proceed.  Finding enough subjects is always hard; it's the single biggest obstacle we encounter.  Paying people is the usual approach, but for a group like this, the usual nominal amount we pay undergrads ($10-25) isn't enough.  Other common approaches -- flyers all over campus, offers on Mechanical Turk, ads on Facebook or Google Adwords, etc. -- won't work if you're trying to get people with specialized knowledge or skills.  What's left?

Steve, thank you - you captured the background and nature of this process very well.  Rest assured that this project is approved by the school and is part of our MBA coursework (we students get graded for this - this is not just a side project).  To provide full disclosure, this academic project is part of UCLA Anderson's Strategic Management Research projects and is sponsored by Cisco.

Mike, to address your concerns:  the survey is part of a primary research to understand what the market needs are directly from people involved in the field.  Like Steve points out, this means finding avenues where the domain experts are available - such as our school Alumni lists, Linkedin and mailing lists like Nanog.  I have been a member of Nanog for a few months now and have found that very well informed discussions take place here.  I would therefore consider it a privilege to have the input from the NANOG group members.  While you are right that the give aways are small compared to the intangible value the research will gain from your insights, this is just a small way we students want to thank our survey participants within the limited budget we have been allocated for this.  I do hope you understand and I really would appreciate your feedback as well as other Nanog members'.

Please let me know if there are any other questions. 

Thank you, 

Best Regards,
Arch


________________________________________
From: Steven Bellovin [smb at cs.columbia.edu]
Sent: Friday, May 27, 2011 8:14 AM
To: Michael Holstein
Cc: Sunder Rajan, Archana Devi; nanog at nanog.org
Subject: Re: IT Survey Request: Win an iPad2 or Kindle!

On May 27, 2011, at 10:24 22AM, Michael Holstein wrote:

>
>> I am a student at UCLA Anderson School of Managment and my MBA field study team is working on a research that involves conducting a survey of CIOs, IT Managers/Administrators, IT Engineers to understand challenges in managing IT infrastructure.
>>
>> Could you please help by filling out this really short survey?
>
> A more cynical view would be as an MBA student, you're researching
> cheaper ways to recruit contact information and current projects. A
> kindle is $139 .. that's pretty cheap for a list of people/projects
> considering what that lead information is worth to vendors of the
> "solutions" to the challenges you ask about.

I know nothing of this student, the school, or the study.  I will say --
as an academic who frequently does research involving human subjects,
generally including surveys -- that this is a very normal way to
proceed.  Finding enough subjects is always hard; it's the single
biggest obstacle we encounter.  Paying people is the usual approach,
but for a group like this, the usual nominal amount we pay undergrads
($10-25) isn't enough.  Other common approaches -- flyers all over
campus, offers on Mechanical Turk, ads on Facebook or Google Adwords,
etc. -- won't work if you're trying to get people with specialized
knowledge or skills.  What's left?

I might add that by federal law, all government-funded research
involving human subjects has to be approved by an "IRB" -- an
Institutional Review Board -- and many universities (including my
own) impose that requirement on all research, even if no federal
funds are involved.  While it's certainly not rare to do studies that
involve (initial) deceit of the subjects (you want them reacting
normally, rather than giving the answers they think you want), the
IRB has to see the full protocol and experiment design.

You may be right, of course; I can't say.  I haven't contacted the
student's professor nor have I asked to see the IRB protocol.  Given
that any legitimate study of this type would be conducted along the
lines explained in the original post, I'd say that the burden of
proof is on you.  (Of course, as a security guy I know full well
that that notion of "normal behavior" is the best way to hide an
attack.)

References: http://www.usenix.org/events/upsec08/tech/full_papers/garfinkel/garfinkel.pdf
            https://www.cs.columbia.edu/~smb/papers/wecsr2011-irb.pdf

                --Steve Bellovin, https://www.cs.columbia.edu/~smb








From michael.holstein at csuohio.edu  Fri May 27 11:50:24 2011
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Fri, 27 May 2011 12:50:24 -0400
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <B83BBEA1883107428F511BCEB308FB431BBAF39D80@EM11.ad.ucla.edu>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>	<4DDFB416.6040808@csuohio.edu>,
	<BC90DBDF-6AE0-494A-96DB-EA84796C018A@cs.columbia.edu>
	<B83BBEA1883107428F511BCEB308FB431BBAF39D80@EM11.ad.ucla.edu>
Message-ID: <4DDFD650.7080400@csuohio.edu>


> sponsored by Cisco.
>   

Uh huh .. "Do you expect to invest in a comprehensive tool that solves
all the challenges identified in question 4?"

Not picking on you personally .. but let's call a spade a spade, shall
we? .. this is market research sponsored by a vendor with a hat in the
game. Not exactly objective, and wasn't disclosed up-front.

Cheers,

Michael Holstein
Cleveland State University




From fred at cisco.com  Fri May 27 13:43:00 2011
From: fred at cisco.com (Fred Baker)
Date: Fri, 27 May 2011 11:43:00 -0700
Subject: IT Survey Request: Win an iPad2 or Kindle!
In-Reply-To: <4DDFD650.7080400@csuohio.edu>
References: <B83BBEA1883107428F511BCEB308FB431BBAF39D7F@EM11.ad.ucla.edu>	<4DDFB416.6040808@csuohio.edu>,
	<BC90DBDF-6AE0-494A-96DB-EA84796C018A@cs.columbia.edu>
	<B83BBEA1883107428F511BCEB308FB431BBAF39D80@EM11.ad.ucla.edu>
	<4DDFD650.7080400@csuohio.edu>
Message-ID: <88DB8F7A-1A47-40B2-B0EA-0220D309073F@cisco.com>


On May 27, 2011, at 9:50 AM, Michael Holstein wrote:

> Not picking on you personally .. but let's call a spade a spade, shall
> we? .. this is market research sponsored by a vendor with a hat in the
> game. Not exactly objective, and wasn't disclosed up-front.


OK, let me step in here. 

This was sponsored under http://www.cisco.com/research, which is a program in which we hand out smalls amounts of money in the form of grants to further the industry. It is done as a grant from and to a 501(3)c. As a result, under US law, we are explicitly precluded from directly benefiting from the research. We can read the paper when it's published, and we might or might not draw conclusions from it, but the paper will at that point be in the open.

Yes, it's Cisco funding. It's UCLA research, and as far as we know it is exactly as described by Sunder - he's gathering data for a paper.


Listen folks. If you want to be involved, Sunder will appreciate it. If you don't, don't be. But don't beat the kid up over unfounded assumptions.


From cscora at apnic.net  Fri May 27 14:01:06 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 28 May 2011 05:01:06 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201105271901.p4RJ16FJ017763@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfs at cisco.com>.

Routing Table Report   04:00 +10GMT Sat 28 May, 2011

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              358362
    Prefixes after maximum aggregation:                          162138
    Deaggregation factor:                                          2.21
    Unique aggregates announced to Internet:                     177469
Total ASes present in the Internet Routing Table:                 37701
    Prefixes per ASN:                                              9.51
Origin-only ASes present in the Internet Routing Table:           31497
Origin ASes announcing only one prefix:                           15121
Transit ASes present in the Internet Routing Table:                5100
Transit-only ASes present in the Internet Routing Table:            139
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      36
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               705
    Unregistered ASNs in the Routing Table:                         376
Number of 32-bit ASNs allocated by the RIRs:                       1389
Number of 32-bit ASNs visible in the Routing Table:                1104
Prefixes from 32-bit ASNs in the Routing Table:                    2503
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            289
Number of addresses announced to Internet:                   2437036992
    Equivalent to 145 /8s, 66 /16s and 59 /24s
    Percentage of available address space announced:               65.8
    Percentage of allocated address space announced:               65.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.0
Total number of prefixes smaller than registry allocations:      149159

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    89221
    Total APNIC prefixes after maximum aggregation:               30038
    APNIC Deaggregation factor:                                    2.97
Prefixes being announced from the APNIC address blocks:           85654
    Unique aggregates announced from the APNIC address blocks:    36698
APNIC Region origin ASes present in the Internet Routing Table:    4461
    APNIC Prefixes per ASN:                                       19.20
APNIC Region origin ASes announcing only one prefix:               1245
APNIC Region transit ASes present in the Internet Routing Table:    703
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         20
Number of APNIC region 32-bit ASNs visible in the Routing Table:     48
Number of APNIC addresses announced to Internet:              616629792
    Equivalent to 36 /8s, 193 /16s and 6 /24s
    Percentage of available APNIC address space announced:         78.2

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
                       55296-56319, 131072-132095
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    140454
    Total ARIN prefixes after maximum aggregation:                71446
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           112718
    Unique aggregates announced from the ARIN address blocks:     45895
ARIN Region origin ASes present in the Internet Routing Table:    14398
    ARIN Prefixes per ASN:                                         7.83
ARIN Region origin ASes announcing only one prefix:                5492
ARIN Region transit ASes present in the Internet Routing Table:    1508
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          23
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               801841408
    Equivalent to 47 /8s, 203 /16s and 33 /24s
    Percentage of available ARIN address space announced:          63.7

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     84958
    Total RIPE prefixes after maximum aggregation:                48453
    RIPE Deaggregation factor:                                     1.75
Prefixes being announced from the RIPE address blocks:            78225
    Unique aggregates announced from the RIPE address blocks:     51823
RIPE Region origin ASes present in the Internet Routing Table:    15639
    RIPE Prefixes per ASN:                                         5.00
RIPE Region origin ASes announcing only one prefix:                7820
RIPE Region transit ASes present in the Internet Routing Table:    2461
Average RIPE Region AS path length visible:                         4.6
    Max RIPE Region AS path length visible:                          36
Number of RIPE region 32-bit ASNs visible in the Routing Table:     815
Number of RIPE addresses announced to Internet:               474301952
    Equivalent to 28 /8s, 69 /16s and 70 /24s
    Percentage of available RIPE address space announced:          76.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   32990
    Total LACNIC prefixes after maximum aggregation:               7492
    LACNIC Deaggregation factor:                                   4.40
Prefixes being announced from the LACNIC address blocks:          32033
    Unique aggregates announced from the LACNIC address blocks:   16834
LACNIC Region origin ASes present in the Internet Routing Table:   1458
    LACNIC Prefixes per ASN:                                      21.97
LACNIC Region origin ASes announcing only one prefix:               427
LACNIC Region transit ASes present in the Internet Routing Table:   263
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   224
Number of LACNIC addresses announced to Internet:              83999744
    Equivalent to 5 /8s, 1 /16s and 188 /24s
    Percentage of available LACNIC address space announced:        55.6

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8016
    Total AfriNIC prefixes after maximum aggregation:              1888
    AfriNIC Deaggregation factor:                                  4.25
Prefixes being announced from the AfriNIC address blocks:          6339
    Unique aggregates announced from the AfriNIC address blocks:   1891
AfriNIC Region origin ASes present in the Internet Routing Table:   452
    AfriNIC Prefixes per ASN:                                     14.02
AfriNIC Region origin ASes announcing only one prefix:              137
AfriNIC Region transit ASes present in the Internet Routing Table:  102
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             23157760
    Equivalent to 1 /8s, 97 /16s and 92 /24s
    Percentage of available AfriNIC address space announced:       34.5

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2461       9500         922   Korea Telecom (KIX)
17974     1852        516          32   PT TELEKOMUNIKASI INDONESIA
 7545     1534        301          85   TPG Internet Pty Ltd
 4755     1473        635         169   TATA Communications formerly 
24560     1155        337         187   Bharti Airtel Ltd., Telemedia
 7552     1140       1064           7   Vietel Corporation
 4808     1081       2141         302   CNCGROUP IP network: China169
 9583     1076         79         507   Sify Limited
 9829     1035        873          54   BSNL National Internet Backbo
18101      931        116         141   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3641       3822         254   bellsouth.net, inc. 
 4323     1972       1081         399   Time Warner Telecom
18566     1875        355         271   Covad Communications 
 1785     1789        681         123   PaeTec Communications, Inc.
 6478     1704        317          50   AT&T Worldnet Services 
20115     1535       1540         633   Charter Communications 
19262     1480       4916         330   Verizon Global Networks 
 7018     1363       7068         887   AT&T WorldNet Services
22773     1335       2897          88   Cox Communications, Inc.
11492     1280        240          15   Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6830      516       1780         319   UPC Distribution Services
34984      516        106         179   BILISIM TELEKOM
 3292      462       2078         397   TDC Tele Danmark
20940      456        133         350   Akamai Technologies European 
29049      451         33          48   AzerSat LLC.
 8866      445        134          26   Bulgarian Telecommunication C
12479      430        577           6   Uni2 Autonomous System
 3320      426       8152         371   Deutsche Telekom AG
 8551      406        355          45   Bezeq International
 3301      398       1839         347   TeliaNet Sweden

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1492        274         156   TVCABLE BOGOTA 
 8151     1379       2710         364   UniNet S.A. de C.V. 
28573     1321        991          88   NET Servicos de Comunicao S.A
 7303      958        504         150   Telecom Argentina Stet-France
 6503      727        354          70   AVANTEL, S.A. 
14420      670         54          91   CORPORACION NACIONAL DE TELEC
22047      565        310          15   VTR PUNTO NET S.A. 
 3816      539        227         101   Empresa Nacional de Telecomun
13489      515        262         121   Orbitel S.A. E.S.P. 
11172      495         84          84   Servicios Alestra S.A de C.V 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452      871        445          11   TEDATA
24863      787        147          37   LINKdotNET AS number
15475      543         90           8   Nile Online
36992      290        315          18   Etisalat MISR
 3741      263        937         226   The Internet Solution 
 6713      241        215          13   Itissalat Al-MAGHRIB
24835      208         78          10   RAYA Telecom - Egypt
33776      202         11           8   Starcomms Nigeria Limited
29571      163         19          12   Ci Telecom Autonomous system 
16637      150        441          86   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3641       3822         254   bellsouth.net, inc. 
23456     2503        631        1363   32-bit ASN transition
 4766     2461       9500         922   Korea Telecom (KIX)
 4323     1972       1081         399   Time Warner Telecom
18566     1875        355         271   Covad Communications 
17974     1852        516          32   PT TELEKOMUNIKASI INDONESIA
 1785     1789        681         123   PaeTec Communications, Inc.
 6478     1704        317          50   AT&T Worldnet Services 
20115     1535       1540         633   Charter Communications 
 7545     1534        301          85   TPG Internet Pty Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
17974      1852        1820      PT TELEKOMUNIKASI INDONESIA
 1785      1789        1666      PaeTec Communications, Inc.
 6478      1704        1654      AT&T Worldnet Services 
18566      1875        1604      Covad Communications 
 4323      1972        1573      Time Warner Telecom
 4766      2461        1539      Korea Telecom (KIX)
 7545      1534        1449      TPG Internet Pty Ltd
10620      1492        1336      TVCABLE BOGOTA 
 4755      1473        1304      TATA Communications formerly 
11492      1280        1265      Cable One 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
26973   UNALLOCATED  12.39.152.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.154.0/23        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.155.0/24        7018       AT&T WorldNet Servic
26973   UNALLOCATED  12.39.159.0/24        7018       AT&T WorldNet Servic
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
27.0.128.0/17         7514     Media Exchange, Inc.
41.190.32.0/23       31856     CABSAS
41.190.34.0/23       31856     CABSAS
41.190.36.0/23       31856     CABSAS

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:20       /9:12      /10:28      /11:79      /12:228     
/13:460     /14:794     /15:1394    /16:11758   /17:5834    /18:9760    
/19:19296   /20:25693   /21:25898   /22:34097   /23:33118   /24:186639  
/25:1090    /26:1269    /27:713     /28:166     /29:8       /30:2       
/31:0       /32:6       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2242          3641      bellsouth.net, inc. 
18566     1838          1875      Covad Communications 
 6478     1658          1704      AT&T Worldnet Services 
10620     1382          1492      TVCABLE BOGOTA 
11492     1226          1280      Cable One 
23456     1220          2503      32-bit ASN transition
 7011     1061          1160      Citizens Utilities 
 1785     1051          1789      PaeTec Communications, Inc.
 4323      885          1972      Time Warner Telecom
22773      850          1335      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:279       2:48        4:16        5:1         6:3         8:353    
  12:1984     13:1        14:461      15:15       16:3        17:8      
  20:10       23:7        24:1645     27:774      31:351      32:60     
  33:4        34:2        37:1        38:739      40:101      41:2527   
  42:5        44:3        46:930      47:3        49:195      50:422    
  52:13       54:2        55:6        56:2        57:30       58:846    
  59:479      60:387      61:1235     62:1044     63:1940     64:3947   
  65:2293     66:4148     67:1873     68:1085     69:2992     70:706    
  71:352      72:1891     73:1        74:2358     75:302      76:341    
  77:870      78:706      79:464      80:1083     81:823      82:494    
  83:437      84:677      85:1061     86:593      87:754      88:330    
  89:1527     90:203      91:3788     92:517      93:1049     94:1280   
  95:802      96:506      97:249      98:850      99:35      101:58     
 103:28      106:1       107:7       108:84      109:949     110:600    
 111:712     112:304     113:400     114:535     115:671     116:946    
 117:693     118:827     119:1146    120:308     121:670     122:1621   
 123:999     124:1262    125:1230    128:262     129:173     130:164    
 131:571     132:109     133:19      134:213     135:48      136:214    
 137:143     138:300     139:112     140:482     141:239     142:403    
 143:400     144:483     145:54      146:447     147:209     148:590    
 149:242     150:168     151:186     152:325     153:177     154:3      
 155:397     156:194     157:354     158:137     159:387     160:317    
 161:207     162:282     163:164     164:498     165:355     166:515    
 167:428     168:733     169:155     170:805     171:77      172:1      
 173:1560    174:550     175:370     176:129     177:135     178:988    
 180:848     181:17      182:453     183:209     184:285     185:1      
 186:1174    187:770     188:842     189:903     190:4816    192:5840   
 193:4893    194:3500    195:2985    196:1224    197:19      198:3576   
 199:3905    200:5537    201:1484    202:8317    203:8405    204:4172   
 205:2328    206:2677    207:2874    208:3966    209:3471    210:2737   
 211:1394    212:1989    213:1735    214:729     215:72      216:4905   
 217:1632    218:565     219:363     220:1201    221:491     222:341    
 223:147    

End of report



From bill at herrin.us  Fri May 27 14:52:47 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 27 May 2011 15:52:47 -0400
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDED8D0.3010806@memetic.org>
References: <4DDED8D0.3010806@memetic.org>
Message-ID: <BANLkTimsfYh3g6wnJUtvEcTc96Eae5dh2w@mail.gmail.com>

On Thu, May 26, 2011 at 6:48 PM, Adam Armstrong <lists at memetic.org> wrote:
> Do any of you have any pointers on how to go about predicting usage for
> high-speed ethernet access?
>
> Finally, what do people think of selling a 1G service with 1G backhaul (and
> potentially 10s or 100s of customers buying this service alongside n*100s of
> customers with 100M service)?

Hi Adam,

I think you better have a PPoE concentrator somewhere or you're going
to deal with a flood of broadcast, virus and other trash traffic. I
also think expecting fewer than 1% of your residential customers to
P2P at once is borrowing trouble.

I've been out of the ISP game too long to give you hard numbers at
today's network speeds, but back when I was in the game, a 100:1
oversubscription ratio for residential DSL was around the boundary of
what customers described as poor quality and slow. That number was
steadily trending downward, not up, though the official villain then
was Bit Torrent instead of Netflix.


On the other hand, it might be an interesting experiment to take a
utility company approach... Sure we'll give you a 200 amp service with
only 1000 amps in the neighborhood, but you don't pay for the 200 amp
service you pay for the consumption of kilowatt hours. On the other
hand, heat pumps don't get hacked and start drawing the full 200 amp
service.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From surfer at mauigateway.com  Fri May 27 15:22:50 2011
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 27 May 2011 13:22:50 -0700
Subject: Contention/Oversubscription maths
Message-ID: <20110527132250.2FD48C45@resin15.mta.everyone.net>


-------- lists at memetic.org wrote: ------------
From: Adam Armstrong <lists at memetic.org>

I'm more interested in the levels of traffic that we will see consistently.
-----------------------------------------


>From experience, one thing's for sure.  No matter how you end up estimating traffic levels, you should optimize it using empirical data.  Make your estimates, set up the connectivity and watch the traffic.  In some areas you will be able to have a larger over-subscription rate because the customers will have lower traffic level internet habits and in other areas the over-subscription rate will be less because you might have a pocket of power users.  

To the point some have made that user's internet surfing habits (thus more traffic) don't change because of an increase in bandwidth, rather they change more gradually, is definitely the case for residential subscribers.  I have seen folks spend way too much time trying to get it right from initial estimates and totally blow it.  

There is no substitute for empirical data!

scott



From cidr-report at potaroo.net  Fri May 27 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 27 May 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201105272200.p4RM00Tf094801@wattle.apnic.net>

BGP Update Report
Interval: 19-May-11 -to- 26-May-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            65222  4.0%      70.1 -- BSNL-NIB National Internet Backbone
 2 - AS14420           33536  2.1%      50.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
 3 - AS19743           31786  1.9%    5297.7 -- 
 4 - AS9498            29521  1.8%      36.4 -- BBIL-AP BHARTI Airtel Ltd.
 5 - AS11492           27677  1.7%      23.6 -- CABLEONE - CABLE ONE, INC.
 6 - AS24560           27213  1.7%      23.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 7 - AS17974           21019  1.3%      12.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 8 - AS18881           19891  1.2%     209.4 -- Global Village Telecom
 9 - AS32528           17721  1.1%    5907.0 -- ABBOTT Abbot Labs
10 - AS17488           12519  0.8%      23.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet
11 - AS25543           10254  0.6%     277.1 -- FasoNet-AS
12 - AS210              9831  0.6%      38.1 -- WEST-NET-WEST - Utah Education Network
13 - AS8402             9498  0.6%      15.4 -- CORBINA-AS Corbina Telecom
14 - AS45595            9329  0.6%      40.6 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited
15 - AS14522            8694  0.5%      41.8 -- Satnet
16 - AS8151             8604  0.5%       9.4 -- Uninet S.A. de C.V.
17 - AS44609            8580  0.5%    2860.0 -- FNA Fars News Agency Cultural Arts Institute
18 - AS3320             8148  0.5%     452.7 -- DTAG Deutsche Telekom AG
19 - AS18002            7814  0.5%      46.2 -- WORLDPHONE-IN AS Number for Interdomain Routing
20 - AS45514            7742  0.5%      25.5 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS49367            7390  0.5%    7390.0 -- ASSEFLOW Seflow S.N.C. Di Marco Brame' & C.
 2 - AS32528           17721  1.1%    5907.0 -- ABBOTT Abbot Labs
 3 - AS19743           31786  1.9%    5297.7 -- 
 4 - AS3454             7648  0.5%    3824.0 -- Universidad Autonoma de Nuevo Leon
 5 - AS17408            3520  0.2%    3520.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 6 - AS44609            8580  0.5%    2860.0 -- FNA Fars News Agency Cultural Arts Institute
 7 - AS37312            1628  0.1%    1628.0 -- Clickatell
 8 - AS49600            1339  0.1%    1339.0 -- LASEDA La Seda de Barcelona, S.A
 9 - AS48640             846  0.1%     846.0 -- MAZ-AS MAZ Mutua de Accidentes de Trabajo y Enfermedades
10 - AS21271             793  0.1%     793.0 -- SOTELMABGP
11 - AS50347             778  0.1%     778.0 -- ZONTERRA-AS Zonterra Corp SRL
12 - AS24919            3349  0.2%     669.8 -- CUBIO-AS Oy Cubio Communications Ltd.
13 - AS34043             491  0.0%     491.0 -- RISS Internet Security Systems SRL
14 - AS56164             468  0.0%     468.0 -- MHM-AS-AP Marriott Hotel Manila
15 - AS50461            1376  0.1%     458.7 -- ALMADINAH-AS Almadinah Ltd
16 - AS3320             8148  0.5%     452.7 -- DTAG Deutsche Telekom AG
17 - AS3                 418  0.0%     735.0 -- ALCAD-SI Alcad podjetje za projektiranje, trgovino in storitve d.o.o.
18 - AS1706             3401  0.2%     377.9 -- UNIV-ARIZ - University of Arizona
19 - AS38789             353  0.0%     353.0 -- IAHGAMES-AS-ID IAHGames Indonesia PT
20 - AS38388            3045  0.2%     338.3 -- BEN-AS-KR Bukbu District Office of Education in Seoul


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.92.235.0/24    9638  0.6%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 2 - 130.36.34.0/24     8860  0.5%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24     8859  0.5%   AS32528 -- ABBOTT Abbot Labs
 4 - 91.217.214.0/24    8068  0.5%   AS3320  -- DTAG Deutsche Telekom AG
 5 - 200.23.202.0/24    7646  0.4%   AS3454  -- Universidad Autonoma de Nuevo Leon
 6 - 95.141.32.0/20     7390  0.4%   AS49367 -- ASSEFLOW Seflow S.N.C. Di Marco Brame' & C.
 7 - 65.122.196.0/24    6196  0.4%   AS19743 -- 
                                     AS5511  -- OPENTRANSIT France Telecom - Orange - Worldwide IP Backbone
 8 - 72.164.144.0/24    5127  0.3%   AS19743 -- 
                                     AS5511  -- OPENTRANSIT France Telecom - Orange - Worldwide IP Backbone
 9 - 66.238.91.0/24     5118  0.3%   AS19743 -- 
                                     AS5511  -- OPENTRANSIT France Telecom - Orange - Worldwide IP Backbone
10 - 65.163.182.0/24    5118  0.3%   AS19743 -- 
                                     AS5511  -- OPENTRANSIT France Telecom - Orange - Worldwide IP Backbone
11 - 65.162.204.0/24    5117  0.3%   AS19743 -- 
                                     AS5511  -- OPENTRANSIT France Telecom - Orange - Worldwide IP Backbone
12 - 66.89.98.0/24      5117  0.3%   AS19743 -- 
                                     AS5511  -- OPENTRANSIT France Telecom - Orange - Worldwide IP Backbone
13 - 178.22.72.0/21     4304  0.2%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
14 - 178.22.79.0/24     4256  0.2%   AS44609 -- FNA Fars News Agency Cultural Arts Institute
15 - 202.153.174.0/24   3520  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
16 - 65.181.192.0/23    3327  0.2%   AS11492 -- CABLEONE - CABLE ONE, INC.
17 - 24.116.2.0/24      2810  0.2%   AS11492 -- CABLEONE - CABLE ONE, INC.
18 - 24.116.1.0/24      2626  0.1%   AS11492 -- CABLEONE - CABLE ONE, INC.
19 - 195.8.34.0/23      2577  0.1%   AS20632 -- PETERSTAR-AS PeterStar
20 - 208.54.82.0/24     2131  0.1%   AS701   -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From cidr-report at potaroo.net  Fri May 27 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 27 May 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201105272200.p4RM00Yk094796@wattle.apnic.net>

This report has been generated at Fri May 27 21:12:07 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        20-05-11    360980      212240
        21-05-11    361159      212080
        22-05-11    360957      212294
        23-05-11    361272      212120
        24-05-11    361057      211953
        25-05-11    361387      212096
        26-05-11    361644      211997
        27-05-11    361620      212303


AS Summary
         37812  Number of ASes in routing system
         15913  Number of ASes announcing only one prefix
          3640  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      110390528  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 27May11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     361920   212303   149617    41.3%   All ASes

AS6389      3640      259     3381    92.9%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4323      1973      401     1572    79.7%   TWTC - tw telecom holdings,
                                               inc.
AS4766      2461      932     1529    62.1%   KIXS-AS-KR Korea Telecom
AS6478      1704      280     1424    83.6%   ATT-INTERNET3 - AT&T Services,
                                               Inc.
AS22773     1335       97     1238    92.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS19262     1490      308     1182    79.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS18566     1875      722     1153    61.5%   COVAD - Covad Communications
                                               Co.
AS4755      1474      386     1088    73.8%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1792      760     1032    57.6%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1140      130     1010    88.6%   VIETEL-AS-AP Vietel
                                               Corporation
AS28573     1321      311     1010    76.5%   NET Servicos de Comunicao S.A.
AS10620     1492      497      995    66.7%   Telmex Colombia S.A.
AS18101      932      147      785    84.2%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS7545      1538      759      779    50.7%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS24560     1155      392      763    66.1%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS4808      1085      337      748    68.9%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1380      651      729    52.8%   Uninet S.A. de C.V.
AS11492     1280      590      690    53.9%   CABLEONE - CABLE ONE, INC.
AS3356      1117      455      662    59.3%   LEVEL3 Level 3 Communications
AS17488      928      310      618    66.6%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS7303       958      349      609    63.6%   Telecom Argentina S.A.
AS17676      658       70      588    89.4%   GIGAINFRA Softbank BB Corp.
AS14420      670       91      579    86.4%   CORPORACION NACIONAL DE
                                               TELECOMUNICACIONES - CNT EP
AS3549       957      402      555    58.0%   GBLX Global Crossing Ltd.
AS22561      910      358      552    60.7%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17974     1852     1301      551    29.8%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4780       750      211      539    71.9%   SEEDNET Digital United Inc.
AS855        643      107      536    83.4%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS22047      565       30      535    94.7%   VTR BANDA ANCHA S.A.
AS15475      544       14      530    97.4%   NOL

Total      39619    11657    27962    70.6%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        24.48.0.0/14         AS5769  VIDEOTRON - Videotron Telecom Ltee
        24.225.128.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/18      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.192.0/23      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.224.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.237.0/24      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        24.225.248.0/21      AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc.
        27.0.128.0/17        AS7514  MEX Media EXchange, Inc.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        62.18.0.0/15         AS12682 
        62.18.252.0/24       AS12682 
        62.19.0.0/18         AS12682 
        62.19.64.0/22        AS12682 
        62.19.248.0/21       AS12682 
        62.19.249.0/24       AS12682 
        62.19.250.0/24       AS12682 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS16626 GNAXNET-AS - Global Net Access, LLC
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        69.6.81.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.22.32.0/19        AS33150 
        76.77.32.0/19        AS2828  XO-AS15 - XO Communications
        80.88.10.0/24        AS33774 DJAWEB
        80.88.12.0/24        AS33779 wataniya-telecom-as
        91.228.101.0/24      AS3.113 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        115.42.28.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.40.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.42.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.44.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.47.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.48.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.49.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.50.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.51.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.52.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.53.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.54.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.55.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.56.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.57.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.58.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.59.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.61.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.62.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        115.42.63.0/24       AS1221  ASN-TELSTRA Telstra Pty Ltd
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        134.175.0.0/16       AS14576 RHNL-NET - Righthosting.com
        134.175.0.0/19       AS12124 THORN - Thorn Communications
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        158.222.70.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.72.0/23      AS6137  SISNA - SISNA, Inc.
        158.222.224.0/20     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.224.0/22     AS19864 O1COMM - O1 COMMUNICATIONS
        158.222.229.0/24     AS19864 O1COMM - O1 COMMUNICATIONS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        181.82.15.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.16.0/24       AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul
        181.82.17.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        181.82.18.0/24       AS38418 SENSD-AS-KR seoul seondong district office of education
        184.164.192.0/19     AS35908 VPLSNET - VPLS Inc. d/b/a Krypt Technologies
        190.102.32.0/20      AS30058 FDCSERVERS - FDCservers.net
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc
        192.64.85.0/24       AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.69.108.0/24      AS1759  TSF-IP-CORE TeliaSonera Finland IP Network
        192.101.46.0/24      AS6503  Axtel, S.A.B. de C.V.
        192.101.64.0/21      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        192.101.72.0/24      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        192.124.252.0/22     AS680   DFN-IP service G-WiN
        192.131.233.0/24     AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        192.145.251.0/24     AS10026 PACNET Pacnet Global Ltd
        192.154.32.0/19      AS81    NCREN - MCNC
        192.154.64.0/19      AS81    NCREN - MCNC
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        196.2.224.0/22       AS24863 LINKdotNET-AS
        196.6.108.0/24       AS5713  SAIX-NET
        196.13.201.0/24      AS2018  TENET-1
        196.13.202.0/24      AS2018  TENET-1
        196.13.203.0/24      AS2018  TENET-1
        196.13.204.0/24      AS2018  TENET-1
        196.110.105.0/24     AS8513  SKYVISION SkyVision Network Services
        196.202.224.0/21     AS8818  TELE Greenland Autonomous System
        198.1.2.0/24         AS4761  INDOSAT-INP-AP INDOSAT Internet Network Provider
        198.15.4.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.15.5.0/24        AS4323  TWTC - tw telecom holdings, inc.
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.
        198.73.210.0/24      AS21570 ACI-1 - Accelerated Connections Inc.
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        198.99.241.0/24      AS11797 AC-NIELSEN-AS AC NIELSEN
        198.161.87.0/24      AS6539  GT-BELL - Bell Canada
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited
        198.167.0.0/16       AS7456  INTERHOP - Interhop Network SERVICES Inc.
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        198.175.231.0/24     AS19262 VZGNI-TRANSIT - Verizon Online LLC
        198.180.198.0/24     AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services
        198.182.235.0/24     AS3356  LEVEL3 Level 3 Communications
        199.16.32.0/19       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        199.33.84.0/22       AS9911  CONNECTPLUS-AP Singapore Telecom
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center
        199.185.130.0/23     AS19662 UNISERVE-ONLINE - Uniserve On Line
        199.202.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        199.202.216.0/21     AS577   BACOM - Bell Canada
        199.246.116.0/24     AS813   UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.76.0/24       AS7195  Telecorp Colombia S.A.
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.9.57.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.133.73.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.146.186.0/24     AS23655 SNAP-NZ-AS Snap Internet Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        203.18.156.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        203.190.32.0/22      AS24564 
        204.9.216.0/23       AS6389  BELLSOUTH-NET-BLK - BellSouth.net Inc.
        204.10.232.0/21      AS33150 
        204.19.14.0/23       AS577   BACOM - Bell Canada
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX
        205.189.134.0/24     AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.72.192.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.72.194.0/23      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.188.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.189.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.190.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.191.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.78.165.0/24      AS16565 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.92.199.0/24      AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc.
        209.54.123.0/24      AS6062  NETPLEX - NETPLEX
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.165.239.0/24     AS209   ASN-QWEST - Qwest Communications Company, LLC
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.5.128.0/20       AS4837  CHINA169-BACKBONE CNCGROUP China169 Backbone
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.10.235.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.10.236.0/24      AS13780 NTNCOMMUNICATIONS - NTN
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.21.196.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.201.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.202.0/24      AS12251 INVISION - Invision.com, Inc.
        216.21.206.0/23      AS12251 INVISION - Invision.com, Inc.
        216.58.192.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.197.0/24      AS22702 X5SOLUTIONS - X5 Solutions, Inc.
        216.58.200.0/24      AS18530 ISOMEDIA-1 - Isomedia Inc.
        216.172.198.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.172.199.0/24     AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org



From frnkblk at iname.com  Sat May 28 00:18:30 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Sat, 28 May 2011 00:18:30 -0500
Subject: Contention/Oversubscription maths
In-Reply-To: <4DDF9EF3.8080102@memetic.org>
References: <4DDED8D0.3010806@memetic.org>		<5904.1306462332@turing-police.cc.vt.edu>		<75AF5BDB-E39D-4DAC-8E0A-88EB342B2AC3@arbor.net>		<4DDF7391.3010207@memetic.org>	<1306500275.1709.56.camel@icts-sp-039>
	<4DDF9EF3.8080102@memetic.org>
Message-ID: <010a01cc1cf6$aec57350$0c5059f0$@iname.com>

Wow, that works out be a per-connect max of 785 kbps.

Frank

-----Original Message-----
From: Adam Armstrong [mailto:lists at memetic.org] 
Sent: Friday, May 27, 2011 7:54 AM
To: Jeroen van Ingen
Cc: nanog at nanog.org
Subject: Re: Contention/Oversubscription maths

On 27/05/2011 13:44, Jeroen van Ingen wrote:
<snip>
> Perhaps students are not average users, but our Resnet currently has:
> * Approx 2000 connections, most at 100 Mbps.
> * These are divided into 4 areas, each area is connected with 1 Gbps to
> central location (so on average you could say we have 500 users sharing
> a 1 Gbps link)
> * Central location has 10 Gbps uplink; stats for this link over the last
> 7 days at 10-min average polling interval are:
> in: min 422 Mbps, avg 883 Mbps, max 1570 Mbps, 95th pct 1250 Mbps.
> out: min 48 Mbps, avg 272 Mbps, max 571 Mbps, 95th pct 459 Mbps.
>
> Perhaps these numbers can be used as an indication for your
> sizing/design.

Most useful response so far, thanks very much :)

adam.





From gbonser at seven.com  Sat May 28 00:24:32 2011
From: gbonser at seven.com (George Bonser)
Date: Fri, 27 May 2011 22:24:32 -0700
Subject: New vyatta-nsp list
In-Reply-To: <ED664CD8-2922-4475-8191-734AF5DFD42C@bogus.com>
References: <D8CD26287252844898B508C40824D8F43C70D2@AD-EXH02.adhost.lan><4DDC0A0A.5020304@rhavenindustrys.com><BANLkTi=RfGKL_M0VU7FadZ47AxGKqf=8Mw@mail.gmail.com><BANLkTikR1FTUKT41AJucRZdC0RsFaWT05w@mail.gmail.com>
	<BANLkTin8oZe2ZPkBAZVfAxc-QmrBRKdd2A@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3439@RWC-EX1.corp.seven.com>
	<ED664CD8-2922-4475-8191-734AF5DFD42C@bogus.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3513@RWC-EX1.corp.seven.com>

> > Every tool has its use.  Also, they have several different sized
> > appliances.   How much CPU use you get depends on how many cores you
> > throw at the problem.  They can use multiple cores/processors.  The
> > result given in one test might not match someone else's test if they
> > have higher end hardware, maybe better than the appliances Vyatta
> ships.
> 
> It's actually rather hard with current pc hardware to get to multiple
> cores engaged in paralell per input interfaces. while you can plan for
> various cases the the one to account for is the small packet
> performance not overwhelming the capabilities of a single cpu core.

Not anymore.  Linux will do processor per flow and it will remember
which processor handed it traffic outgoing and try to route the reply
back to the same CPU so you reduce cache misses.  

If you have multiple queues on the NICS, multiple CPUs can be operating
on the NIC at the same time.  The current servers we are using in
production have eight queues, the older ones had four.  So I can have
eight different cores handing traffic to the NIC and the driver
remembers which CPU it was and when a packet is received on a flow,
sends the interrupt to the CPU that started it.

But again, if you have a 10 or a 100 meg link into an office,  I don't
care how small the packets are, a linux box will handle the traffic just
fine.  Sure, it isn't going to saturate a 10G interface and do
firewalling and VPN and NAT but that isn't what we are talking about
here.  We are talking average office connectivity.  The firewall to the
WAN.

REF: 
http://lwn.net/Articles/382428/  

but it has come a long way in the past year.




From adrian at creative.net.au  Sat May 28 00:32:08 2011
From: adrian at creative.net.au (Adrian Chadd)
Date: Sat, 28 May 2011 13:32:08 +0800
Subject: New vyatta-nsp list
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3513@RWC-EX1.corp.seven.com>
References: <BANLkTin8oZe2ZPkBAZVfAxc-QmrBRKdd2A@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3439@RWC-EX1.corp.seven.com>
	<ED664CD8-2922-4475-8191-734AF5DFD42C@bogus.com>
	<5A6D953473350C4B9995546AFE9939EE0C9E3513@RWC-EX1.corp.seven.com>
Message-ID: <20110528053208.GA9478@skywalker.creative.net.au>

On Fri, May 27, 2011, George Bonser wrote:

> > It's actually rather hard with current pc hardware to get to multiple
> > cores engaged in paralell per input interfaces. while you can plan for
> > various cases the the one to account for is the small packet
> > performance not overwhelming the capabilities of a single cpu core.
> 
> Not anymore.  Linux will do processor per flow and it will remember
> which processor handed it traffic outgoing and try to route the reply
> back to the same CPU so you reduce cache misses.  

FreeBSD is doing much the same, both for TCP flows and for packet
routing.

The real fun will be when open source freebsd/linux stops trying to do
per-flow tracking and optimises their forwarding paths. From what I've
heard on the lists, NICs are certainly doing small packet linerate now.



Adrian




From gbonser at seven.com  Sat May 28 00:38:34 2011
From: gbonser at seven.com (George Bonser)
Date: Fri, 27 May 2011 22:38:34 -0700
Subject: Contention/Oversubscription maths
In-Reply-To: <BANLkTikRi96an0Pjt7Hh_u5xEK3tRxPn_Q@mail.gmail.com>
References: <BANLkTimAJSJRPEovhCyTqkU5CYF_20ei4A@mail.gmail.com><4DDFA225.1030505@memetic.org>
	<BANLkTikRi96an0Pjt7Hh_u5xEK3tRxPn_Q@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3514@RWC-EX1.corp.seven.com>

> We offer peak speeds of 4mbps, and we
> have an
> extrordinary amount of people using (abusing as some would say)
> streaming
> video for many hours of the day causing headaches for us.  

I would bandwidth limit the ports, as someone else already mentioned.  I
would also enable WRED, ECN and everything else I could lay my hands on.
What is that port connected to in the customer's end?  Are they plugging
into a 8 port switch and fanning out that connection to their DVD player
which they use to watch Hulu and Netflix and a bunch of other services?
My Sony DVD player came with about 6 Internet video services programmed
in it and it has an ethernet port.  Do they have a slingbox where they
are going to watch their home TV from work?  And just having all those
users on a flat switched network would be one heck of a security hazard
(again, as someone else mentioned).  But to be honest, I wouldn't deploy
that model at all.  One person can DOS the entire building depending on
how it is deployed and that is without even touching the uplink port.

Now figure about a tenth of those computers will be infected by bot nets
and will sit there sending spam and click fraud all night long, too.

G




From archana.devi.sunder.rajan.2011 at anderson.ucla.edu  Sat May 28 01:34:08 2011
From: archana.devi.sunder.rajan.2011 at anderson.ucla.edu (Sunder Rajan, Archana Devi)
Date: Fri, 27 May 2011 23:34:08 -0700
Subject: IT Survey Request: Win an iPad2 or Kindle!
Message-ID: <B83BBEA1883107428F511BCEB308FB431BBAF39D83@EM11.ad.ucla.edu>

[JC Wrote] A more cynical view The cynic in me wonders how they will track how many people I forwarded this to. I plan to win the prize for "the person who refers the survey
to the most number of people" by forwarding it to millions of people.  :-)
(I suspect that the prize will be won by the person who others (who take the survey) claim referred them to the survey, which is different from the criteria set for the prize.)

Hi JC,
Sorry i missed seeing your message.  The survey has a field to enter "Referred by".  So the people you forward the link to will use your name in the "Referred by" field.  You are right that we rely on the people filling out the survey to be honest in specifying who referred them.  Hopefully, that would be the case as emails are forwarded by people to their trusted contacts.

Thanks,
Arch

________________________________________
From: nanog-request at nanog.org [nanog-request at nanog.org]
Sent: Friday, May 27, 2011 8:52 AM
To: nanog at nanog.org
Subject: NANOG Digest, Vol 40, Issue 103

Send NANOG mailing list submissions to
        nanog at nanog.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
        nanog-request at nanog.org

You can reach the person managing the list at
        nanog-owner at nanog.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

   1. Re: Contention/Oversubscription maths (Adam Armstrong)
   2. Re: Ham Radio Networking (was Re: Rogers Canada using
      7.0.0.0/8 for     internal address space) (William Allen Simpson)
   3. Re: Contention/Oversubscription maths (Jay Ashworth)
   4. Re: IT Survey Request: Win an iPad2 or Kindle! (Michael Holstein)
   5. Re: Contention/Oversubscription maths (Jay Ashworth)
   6. Re: Contention/Oversubscription maths (Shaun Bryant)
   7. Re: Contention/Oversubscription maths (Adam Armstrong)
   8. Re: IT Survey Request: Win an iPad2 or Kindle! (Steven Bellovin)
   9. Re: IT Survey Request: Win an iPad2 or Kindle! (JC Dill)
  10. Re: IT Survey Request: Win an iPad2 or Kindle! (Scott Brim)


----------------------------------------------------------------------

Message: 1
Date: Fri, 27 May 2011 14:45:28 +0100
From: Adam Armstrong <lists at memetic.org>
Subject: Re: Contention/Oversubscription maths
To: Jacob Broussard <shadowedstranger at gmail.com>
Cc: nanog at nanog.org
Message-ID: <4DDFAAF8.2080909 at memetic.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/05/2011 14:40, Jacob Broussard wrote:
>
> We offer peak speeds of 4mbps, and we have an extrordinary amount of
> people using (abusing as some would say) streaming video for many
> hours of the day causing headaches for us.  You probably would be safe
> to assume that you can use a higher ratio for your higher speeds as
> there will be fewer people that can take advantage of the full
> connection speed.
>
This is pretty much what I expect. If you give a 4Mbit user 40Mbit, he
tends not to even be able to use 10 times as much, so we can get away
with much higher ratios.

Statistics and graphs i've seen offlist have been very helpful, and
suggest that 1000 100mbit customers is doable on 1GE.

Atleast, today. Next year's (decade?) launch of the YouView platform in
the UK should increase usage a lot, not to mention a service like
Netflix starting in the UK. We have some movie streaming services, but
they generally suck and are quite low bitrate.

Thanks for the thoughts :D
adam.



------------------------------

Message: 2
Date: Fri, 27 May 2011 10:00:20 -0400
From: William Allen Simpson <william.allen.simpson at gmail.com>
Subject: Re: Ham Radio Networking (was Re: Rogers Canada using
        7.0.0.0/8 for   internal address space)
To: nanog at nanog.org
Message-ID: <4DDFAE74.5000901 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 5/26/11 11:23 PM, David Conrad wrote:
> On May 26, 2011, at 5:14 PM, Wil Schultz wrote:
>>> Out of curiosity, is there an IPv6 stack for ham devices?
>> Well there's a loaded question.
> ...
>> I won't say that there aren't "ham devices" with an IP stack built in, but I think we're talking about different layers here.
>
> Sorry, poorly worded.  What I was wondering is there is an equivalent of KA9Q for IPv6.  I believe one of the comments we got back when we were trying to reclaim 44/8 was that folks couldn't migrate to IPv6 because no software was available...
>
Well, I wrote a lot of the original IPv6 stuff (back when it was PIPE -> SIP ->
SIPP) for KA9Q, have the source around here somewhere....

But now I'd just use Linux.  Alan Cox ported the KA9Q AX25 code long ago.

Since everybody and his brother is coming out of the woodwork -- sadly, I've
not done any AX25 since my grandfather Marvin Allen Maten (W8TQP) died; that
was one of the things we did together.  Although he was a ham since circa 1916,
he was always wanting to try the latest!  His QSL contacts went back so far, he
knew Hugo Gernsback and his brother (who actually ran the electronics store).



------------------------------

Message: 3
Date: Fri, 27 May 2011 10:23:04 -0400 (EDT)
From: Jay Ashworth <jra at baylink.com>
Subject: Re: Contention/Oversubscription maths
To: NANOG <nanog at nanog.org>
Message-ID:
        <26560069.836.1306506184408.JavaMail.root at benjamin.baylink.com>
Content-Type: text/plain; charset=utf-8

----- Original Message -----
> From: "Adam Armstrong" <lists at memetic.org>

> I'm more interested in the levels of traffic that we will see
> consistently.

You're planning to engage in Statistical Multiplexing, or what I've always
termed "bandwidth surfing": how hard can I oversubscribe my uplink without
pissing off the paying customers?

As others have suggested, it depends on quite a number of things, primarily:
whether you're offering an SLA to the customers or not.  Whether you have
a caching proxy or not and which CDNs you solicit to provision your node
are also big factors, of course.

In the final analysis, though, it depends on the customer class.

Residence customers will tolerate a lot more oversubscription than business,
enterprise, and server going on down the list of oversubscription, but
happily *up* the list of "how much can I charge".  Remember that QoS and
load shaping don't work all that will across the internet at large,
but they work pretty decently inside a single switch; you can prioritize
customers who are willing to pay extra for it.  The problem is similar
to airline bookings; it is possible, in the immortal words of Dave Barry,
to envision a situation -- this will happen in your lifetime -- where
no two customers pay exactly the same price.  :-)

Cheers,
-- jra
--
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



------------------------------

Message: 4
Date: Fri, 27 May 2011 10:24:22 -0400
From: Michael Holstein <michael.holstein at csuohio.edu>
Subject: Re: IT Survey Request: Win an iPad2 or Kindle!
To: "Sunder Rajan,      Archana Devi"
        <archana.devi.sunder.rajan.2011 at anderson.ucla.edu>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Message-ID: <4DDFB416.6040808 at csuohio.edu>
Content-Type: text/plain; charset=ISO-8859-1


> I am a student at UCLA Anderson School of Managment and my MBA field study team is working on a research that involves conducting a survey of CIOs, IT Managers/Administrators, IT Engineers to understand challenges in managing IT infrastructure.
>
> Could you please help by filling out this really short survey?

A more cynical view would be as an MBA student, you're researching
cheaper ways to recruit contact information and current projects. A
kindle is $139 .. that's pretty cheap for a list of people/projects
considering what that lead information is worth to vendors of the
"solutions" to the challenges you ask about.


Regards,

Michael Holstein
Cleveland State University



------------------------------

Message: 5
Date: Fri, 27 May 2011 10:28:41 -0400 (EDT)
From: Jay Ashworth <jra at baylink.com>
Subject: Re: Contention/Oversubscription maths
To: NANOG <nanog at nanog.org>
Message-ID:
        <14894863.840.1306506521760.JavaMail.root at benjamin.baylink.com>
Content-Type: text/plain; charset=utf-8

----- Original Message -----
> From: "Adam Armstrong" <lists at memetic.org>

> Statistics and graphs i've seen offlist have been very helpful, and
> suggest that 1000 100mbit customers is doable on 1GE.

Probably.

> Atleast, today. Next year's (decade?) launch of the YouView platform in
> the UK should increase usage a lot, not to mention a service like
> Netflix starting in the UK. We have some movie streaming services, but
> they generally suck and are quite low bitrate.

The short version is: if you oversubscribe, you *will* eventually have Busy
Hours, just like telcos.  The question is: how often.  Telcos have books
that tell them this...

Cheers,
-- jr 'Royal Wedding' a
--
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



------------------------------

Message: 6
Date: Fri, 27 May 2011 08:49:45 -0600
From: Shaun Bryant <sbryant at thepit.org>
Subject: Re: Contention/Oversubscription maths
To: lists at memetic.org
Cc: NANOG <nanog at nanog.org>
Message-ID: <BANLkTimS7XF-y+5o3V4ZuwoKNOdOVV5z_Q at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I run a WISP, where we have moved customers from 3mb/s to 8mb/s to 20mb/s
over the course of 5 years. We do this one tower at a time (about 150
customers) what we have learned is usage grows overtime not with the
increase in available bandwidth.  Our Per-Customer-Avg (PCA) stayed about
the same with each bump in bandwidth, the avg user does not use more
bandwidth because they have more bandwidth or at least not our 1200
customers.

That said we have had our PCA move up more then 30% in the last 7 months due
mainly to Netflix, the nice thing is this usage is "off peak" for
our business customers and as such has not been a concern.

Shaun



Shaun Bryant
sbryant at thepit.org


------------------------------

Message: 7
Date: Fri, 27 May 2011 15:52:08 +0100
From: Adam Armstrong <lists at memetic.org>
Subject: Re: Contention/Oversubscription maths
To: Shaun Bryant <sbryant at thepit.org>
Cc: NANOG <nanog at nanog.org>
Message-ID: <4DDFBA98.20307 at memetic.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 27/05/2011 15:49, Shaun Bryant wrote:
> I run a WISP, where we have moved customers from 3mb/s to 8mb/s to
> 20mb/s over the course of 5 years. We do this one tower at a time
> (about 150 customers) what we have learned is usage grows overtime not
> with the increase in available bandwidth.  Our Per-Customer-Avg (PCA)
> stayed about the same with each bump in bandwidth, the avg user does
> not use more bandwidth because they have more bandwidth or at least
> not our 1200 customers.
>
> That said we have had our PCA move up more then 30% in the last 7
> months due mainly to Netflix, the nice thing is this usage is "off
> peak" for our business customers and as such has not been a concern.
>

Yeah, I fully expect this.

In previous networks I've generally seen a doubling of traffic every 12
months. Generally the traffic is static during spring/summer, and then
doubles over 6 months in autumn/winter.

Though, I'm not sure how this will manifest itself with such high access
speeds.

adam.



------------------------------

Message: 8
Date: Fri, 27 May 2011 11:14:47 -0400
From: Steven Bellovin <smb at cs.columbia.edu>
Subject: Re: IT Survey Request: Win an iPad2 or Kindle!
To: Michael Holstein <michael.holstein at csuohio.edu>
Cc: "nanog at nanog.org" <nanog at nanog.org>, "Sunder Rajan, Archana Devi"
        <archana.devi.sunder.rajan.2011 at anderson.ucla.edu>
Message-ID: <BC90DBDF-6AE0-494A-96DB-EA84796C018A at cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii


On May 27, 2011, at 10:24 22AM, Michael Holstein wrote:

>
>> I am a student at UCLA Anderson School of Managment and my MBA field study team is working on a research that involves conducting a survey of CIOs, IT Managers/Administrators, IT Engineers to understand challenges in managing IT infrastructure.
>>
>> Could you please help by filling out this really short survey?
>
> A more cynical view would be as an MBA student, you're researching
> cheaper ways to recruit contact information and current projects. A
> kindle is $139 .. that's pretty cheap for a list of people/projects
> considering what that lead information is worth to vendors of the
> "solutions" to the challenges you ask about.

I know nothing of this student, the school, or the study.  I will say --
as an academic who frequently does research involving human subjects,
generally including surveys -- that this is a very normal way to
proceed.  Finding enough subjects is always hard; it's the single
biggest obstacle we encounter.  Paying people is the usual approach,
but for a group like this, the usual nominal amount we pay undergrads
($10-25) isn't enough.  Other common approaches -- flyers all over
campus, offers on Mechanical Turk, ads on Facebook or Google Adwords,
etc. -- won't work if you're trying to get people with specialized
knowledge or skills.  What's left?

I might add that by federal law, all government-funded research
involving human subjects has to be approved by an "IRB" -- an
Institutional Review Board -- and many universities (including my
own) impose that requirement on all research, even if no federal
funds are involved.  While it's certainly not rare to do studies that
involve (initial) deceit of the subjects (you want them reacting
normally, rather than giving the answers they think you want), the
IRB has to see the full protocol and experiment design.

You may be right, of course; I can't say.  I haven't contacted the
student's professor nor have I asked to see the IRB protocol.  Given
that any legitimate study of this type would be conducted along the
lines explained in the original post, I'd say that the burden of
proof is on you.  (Of course, as a security guy I know full well
that that notion of "normal behavior" is the best way to hide an
attack.)

References: http://www.usenix.org/events/upsec08/tech/full_papers/garfinkel/garfinkel.pdf
            https://www.cs.columbia.edu/~smb/papers/wecsr2011-irb.pdf

                --Steve Bellovin, https://www.cs.columbia.edu/~smb








------------------------------

Message: 9
Date: Fri, 27 May 2011 08:38:39 -0700
From: JC Dill <jcdill.lists at gmail.com>
Subject: Re: IT Survey Request: Win an iPad2 or Kindle!
To: NANOG list <nanog at nanog.org>
Message-ID: <4DDFC57F.2030900 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

  On 27/05/11 7:24 AM, Michael Holstein wrote:
>
> > I am a student at UCLA Anderson School of Managment and my MBA
> > field study team is working on a research that involves conducting
> > a survey of CIOs, IT Managers/Administrators, IT Engineers to
> > understand challenges in managing IT infrastructure.
> >
> > Could you please help by filling out this really short survey?
>
>  A more cynical view

The cynic in me wonders how they will track how many people I forwarded
this to. I plan to win the prize for "the person who refers the survey
to the most number of people" by forwarding it to millions of people.  :-)

(I suspect that the prize will be won by the person who others (who take
the survey) claim referred them to the survey, which is different from
the criteria set for the prize.)

jc




------------------------------

Message: 10
Date: Fri, 27 May 2011 11:52:20 -0400
From: Scott Brim <scott.brim at gmail.com>
Subject: Re: IT Survey Request: Win an iPad2 or Kindle!
To: JC Dill <jcdill.lists at gmail.com>
Cc: NANOG list <nanog at nanog.org>
Message-ID: <BANLkTi=LE2KOcK8EG7imX1PJ3-W4usvAqg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 27, 2011 at 11:38, JC Dill <jcdill.lists at gmail.com> wrote:
> The cynic in me wonders how they will track how many people I forwarded this
> to. I plan to win the prize for "the person who refers the survey to the
> most number of people" by forwarding it to millions of people. ?:-)
>
> (I suspect that the prize will be won by the person who others (who take the
> survey) claim referred them to the survey, which is different from the
> criteria set for the prize.)

If you'll say that I'm the one who referred you, I'll enter you in a
drawing for a free iPad.



------------------------------

_______________________________________________
NANOG mailing list
NANOG at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog

End of NANOG Digest, Vol 40, Issue 103
**************************************



From simon.leinen at switch.ch  Sat May 28 05:49:50 2011
From: simon.leinen at switch.ch (Simon Leinen)
Date: Sat, 28 May 2011 12:49:50 +0200
Subject: Ham Radio Networking (was Re: Rogers Canada using 7.0.0.0/8 for
	internal address space)
In-Reply-To: <0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org> (David
	Conrad's message of "Thu, 26 May 2011 17:23:10 -1000")
References: <BANLkTiksPaTkANBKdeXqtNTof0i86Z4Wdw@mail.gmail.com>
	<BANLkTikhaeECGku1481NPkOzMjSNwd0DOg@mail.gmail.com>
	<BANLkTimNuLL2O7kRNDFjodYXxF1OJD_2ZQ@mail.gmail.com>
	<BANLkTimFtinGx_zVtthTjgYkBP-T5c2_TA@mail.gmail.com>
	<BANLkTikympd7=o2CwUpw3j5xKeHvKe7K-w@mail.gmail.com>
	<0974974F-8DC3-4CA7-81B0-C784EB56A044@virtualized.org>
	<BANLkTi=U9p7ZT-=wPL=T3A0MV774ttRBLA@mail.gmail.com>
	<27A2757C-0B4E-4359-AA67-594F4B9CE27B@sensoryresearch.net>
	<BANLkTin79UNC05v=mtyNoEtURTrzLwi_CQ@mail.gmail.com>
	<5B71AA52-8041-4A84-91F8-96309D58AAD9@virtualized.org>
	<BANLkTi=bn=m2-OCnxC-u8RL-wu=b3xefaQ@mail.gmail.com>
	<0F21FCD2-BE98-44BF-B6D6-E3527CA0D0A1@virtualized.org>
Message-ID: <aak4db5cc1.fsf@macsl.switch.ch>

David Conrad writes:
> Sorry, poorly worded.  What I was wondering is there is an equivalent
> of KA9Q for IPv6.

But KA9Q is already certified for IPv6!

http://ipv6.he.net/certification/scoresheet.php?pass_name=ka9q

(found on http://www.ka9q.net/)

SCNR.
-- 
Simon.



From tme at americafree.tv  Sat May 28 11:18:37 2011
From: tme at americafree.tv (Marshall Eubanks)
Date: Sat, 28 May 2011 12:18:37 -0400
Subject: $ 90 million fine for cutting Internet services
Message-ID: <46E38C54-1A98-4128-99BE-0575CC34F286@americafree.tv>

I remember some discussion of this outage on NANOG, and on what it was costing Egypt. Well, here is
an estimate - almost $ 20 million USD / day (which actually sounds low to me). 

Regards
Marshall


http://english.aljazeera.net/news/africa/2011/05/201152811555458677.html

An Egyptian court has fined ousted president Hosni Mubarak and former officials more than $90m for cutting off access to internet and mobile phone services during the country's massive protests in January.

A court source told the Reuters news agency on Saturday that Mubarak's fine is $34m, former interior minister Habib al-Adly will owe $53m, and former prime minister Ahmed Nazif has a fine of $7m.

The fine is to be paid from personal assets...


From jof at thejof.com  Sat May 28 12:38:45 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Sat, 28 May 2011 10:38:45 -0700
Subject: IPv6 Availability on XO
In-Reply-To: <835617D6-5709-467B-91F0-91E20448AEA9@u13.net>
References: <835617D6-5709-467B-91F0-91E20448AEA9@u13.net>
Message-ID: <BANLkTimmnriC_VudTPcQiz9xKb2b-kh6sA@mail.gmail.com>

On Mon, May 23, 2011 at 4:39 PM, Ryan Rawdon <ryan at u13.net> wrote:
> I've heard some mixed reports of XO's IPv6 availability - some that they have full deployment/availability, but others like the answer back from our XO reseller that XO does not offer IPv6 on circuits under 45mbit/s.
>
> What is the experience of NANOG on this matter, particularly with XO connectivity under 45mbit/s?

Interesting. Perhaps they haven't plumbed native v6 throughout their network?

For comparison, I'm currently running some native IPv6 over XO in the
San Francisco Bay Area (homed off of an XO router in Fremont, CA).
The circuit is GigE.

Cheers,
jof



From ml at kenweb.org  Sat May 28 14:23:03 2011
From: ml at kenweb.org (ML)
Date: Sat, 28 May 2011 15:23:03 -0400
Subject: $ 90 million fine for cutting Internet services
In-Reply-To: <46E38C54-1A98-4128-99BE-0575CC34F286@americafree.tv>
References: <46E38C54-1A98-4128-99BE-0575CC34F286@americafree.tv>
Message-ID: <4DE14B97.9010005@kenweb.org>

On 5/28/2011 12:18 PM, Marshall Eubanks wrote:
> I remember some discussion of this outage on NANOG, and on what it was costing Egypt. Well, here is
> an estimate - almost $ 20 million USD / day (which actually sounds low to me).
>
> Regards
> Marshall
>
>
> http://english.aljazeera.net/news/africa/2011/05/201152811555458677.html
>
> An Egyptian court has fined ousted president Hosni Mubarak and former officials more than $90m for cutting off access to internet and mobile phone services during the country's massive protests in January.
>
> A court source told the Reuters news agency on Saturday that Mubarak's fine is $34m, former interior minister Habib al-Adly will owe $53m, and former prime minister Ahmed Nazif has a fine of $7m.
>
> The fine is to be paid from personal assets...

Can I fine TEDATA for committing VoIP fraud against my network during 
that same time period?






From zaid at zaidali.com  Sat May 28 15:00:08 2011
From: zaid at zaidali.com (Zaid Ali)
Date: Sat, 28 May 2011 13:00:08 -0700
Subject: $ 90 million fine for cutting Internet services
In-Reply-To: <4DE14B97.9010005@kenweb.org>
References: <46E38C54-1A98-4128-99BE-0575CC34F286@americafree.tv>
	<4DE14B97.9010005@kenweb.org>
Message-ID: <1E21AC56-2EA3-4D4B-A584-1980919F34F4@zaidali.com>

I am a little skeptic that this fine imposed is because the government truly believes in Internet freedom. Many factions of the Egyptian government was to get as much money out of Mubarak as they can and this might be a way to do just that. What would be interesting is if there is a law passed preventing any member of the government from cutting off Internet access.

Zaid

On May 28, 2011, at 12:23 PM, ML wrote:

> On 5/28/2011 12:18 PM, Marshall Eubanks wrote:
>> I remember some discussion of this outage on NANOG, and on what it was costing Egypt. Well, here is
>> an estimate - almost $ 20 million USD / day (which actually sounds low to me).
>> 
>> Regards
>> Marshall
>> 
>> 
>> http://english.aljazeera.net/news/africa/2011/05/201152811555458677.html
>> 
>> An Egyptian court has fined ousted president Hosni Mubarak and former officials more than $90m for cutting off access to internet and mobile phone services during the country's massive protests in January.
>> 
>> A court source told the Reuters news agency on Saturday that Mubarak's fine is $34m, former interior minister Habib al-Adly will owe $53m, and former prime minister Ahmed Nazif has a fine of $7m.
>> 
>> The fine is to be paid from personal assets...
> 
> Can I fine TEDATA for committing VoIP fraud against my network during that same time period?
> 
> 
> 
> 




From belin.daniel at gmail.com  Sat May 28 15:17:47 2011
From: belin.daniel at gmail.com (Daniel Belin)
Date: Sat, 28 May 2011 16:17:47 -0400
Subject: $ 90 million fine for cutting Internet services
In-Reply-To: <1E21AC56-2EA3-4D4B-A584-1980919F34F4@zaidali.com>
References: <46E38C54-1A98-4128-99BE-0575CC34F286@americafree.tv>
	<4DE14B97.9010005@kenweb.org>
	<1E21AC56-2EA3-4D4B-A584-1980919F34F4@zaidali.com>
Message-ID: <57AA8E31-DF34-4DE7-80F3-62A59A29D9B2@gmail.com>

Interesting, there now seems to be a trend of middle eastern countries cutting themselves off from the Internet,

http://blogs.pcmag.com/securitywatch/2011/05/iran_plans_to_cut_off_from_the.php

I think we will see more of this kind of behavior happening in the next few years, as the web has become a real threat to totalitarian and oppressive governments.  

--
Daniel Belin



On May 28, 2011, at 4:00 PM, Zaid Ali <zaid at zaidali.com> wrote:

> I am a little skeptic that this fine imposed is because the government truly believes in Internet freedom. Many factions of the Egyptian government was to get as much money out of Mubarak as they can and this might be a way to do just that. What would be interesting is if there is a law passed preventing any member of the government from cutting off Internet access.
> 
> Zaid
> 
> On May 28, 2011, at 12:23 PM, ML wrote:
> 
>> On 5/28/2011 12:18 PM, Marshall Eubanks wrote:
>>> I remember some discussion of this outage on NANOG, and on what it was costing Egypt. Well, here is
>>> an estimate - almost $ 20 million USD / day (which actually sounds low to me).
>>> 
>>> Regards
>>> Marshall
>>> 
>>> 
>>> http://english.aljazeera.net/news/africa/2011/05/201152811555458677.html
>>> 
>>> An Egyptian court has fined ousted president Hosni Mubarak and former officials more than $90m for cutting off access to internet and mobile phone services during the country's massive protests in January.
>>> 
>>> A court source told the Reuters news agency on Saturday that Mubarak's fine is $34m, former interior minister Habib al-Adly will owe $53m, and former prime minister Ahmed Nazif has a fine of $7m.
>>> 
>>> The fine is to be paid from personal assets...
>> 
>> Can I fine TEDATA for committing VoIP fraud against my network during that same time period?
>> 
>> 
>> 
>> 
> 
> 



From os10rules at gmail.com  Sat May 28 15:21:19 2011
From: os10rules at gmail.com (Greg Ihnen)
Date: Sat, 28 May 2011 15:51:19 -0430
Subject: Cablevision's company line on IPv6 to the home
Message-ID: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>

I just got off the phone with a level 1 tech support guy about an issue with my parents Cablevision/Optimum Online service and decided to ask the fellow if there's any official company news about IPv6 being in the works. His comments were that there is a test coming up (he was referring to World IPv6 Day), though he admitted that Cablevision is choosing not to participate in the "test" because they want to wait to see that IPv6 actually works without problems before they turn it on. He said it with a tone that seemed to express that the World IPv6 Day "test" is an irresponsible diversion. I politely and without any noticeable condescension (I believe) told him "that's what I expected" and bid him adieu.

It's neat how they're going to skip that irresponsible testing phase and just turn it on one day and it's going to work perfectly.

And I wonder how they'll know when IPv6 is done. Maybe is has one of those things that frozen turkeys have, that pops out when it's done.

I've got my HE tunnels up and running on a Mikrotik hardware on the little networks I manage. I can't wait for IPv6 Day.

So someone on the list please let Cablevision/Optonline know when you've finished IPv6. I'm sure they'd appreciate it.

Greg


From swm at emanon.com  Sat May 28 15:25:33 2011
From: swm at emanon.com (Scott Morris)
Date: Sat, 28 May 2011 16:25:33 -0400
Subject: Cablevision's company line on IPv6 to the home
In-Reply-To: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
References: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
Message-ID: <4DE15A3D.7000103@emanon.com>

Since IPv6 is like a frozen turkey....

Just make sure they remember to take the giblets out... Based on
personal...  ummmm...   "experience"...  that will drastically change
when something (if ever) gets done!

;)

Scott

On 5/28/11 4:21 PM, Greg Ihnen wrote:
> I just got off the phone with a level 1 tech support guy about an issue with my parents Cablevision/Optimum Online service and decided to ask the fellow if there's any official company news about IPv6 being in the works. His comments were that there is a test coming up (he was referring to World IPv6 Day), though he admitted that Cablevision is choosing not to participate in the "test" because they want to wait to see that IPv6 actually works without problems before they turn it on. He said it with a tone that seemed to express that the World IPv6 Day "test" is an irresponsible diversion. I politely and without any noticeable condescension (I believe) told him "that's what I expected" and bid him adieu.
>
> It's neat how they're going to skip that irresponsible testing phase and just turn it on one day and it's going to work perfectly.
>
> And I wonder how they'll know when IPv6 is done. Maybe is has one of those things that frozen turkeys have, that pops out when it's done.
>
> I've got my HE tunnels up and running on a Mikrotik hardware on the little networks I manage. I can't wait for IPv6 Day.
>
> So someone on the list please let Cablevision/Optonline know when you've finished IPv6. I'm sure they'd appreciate it.
>
> Greg
>
>




From bedard.phil at gmail.com  Sat May 28 16:06:42 2011
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sat, 28 May 2011 17:06:42 -0400
Subject: Cablevision's company line on IPv6 to the home
In-Reply-To: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
Message-ID: <CA06D6E1.3D758%bedard.phil@gmail.com>

Cablevision (AS6128) does have globally routable IPv6 space
(2001:48a0::/32), but I'm not sure what they are doing with it just yet.
I'm sure a Level 1 tech support individual is not the company spokesman on
IPv6, or anything else.



-Phil






On 5/28/11 4:21 PM, "Greg Ihnen" <os10rules at gmail.com> wrote:

>I just got off the phone with a level 1 tech support guy about an issue
>with my parents Cablevision/Optimum Online service and decided to ask the
>fellow if there's any official company news about IPv6 being in the
>works. His comments were that there is a test coming up (he was referring
>to World IPv6 Day), though he admitted that Cablevision is choosing not
>to participate in the "test" because they want to wait to see that IPv6
>actually works without problems before they turn it on. He said it with a
>tone that seemed to express that the World IPv6 Day "test" is an
>irresponsible diversion. I politely and without any noticeable
>condescension (I believe) told him "that's what I expected" and bid him
>adieu.
>
>It's neat how they're going to skip that irresponsible testing phase and
>just turn it on one day and it's going to work perfectly.
>
>And I wonder how they'll know when IPv6 is done. Maybe is has one of
>those things that frozen turkeys have, that pops out when it's done.
>
>I've got my HE tunnels up and running on a Mikrotik hardware on the
>little networks I manage. I can't wait for IPv6 Day.
>
>So someone on the list please let Cablevision/Optonline know when you've
>finished IPv6. I'm sure they'd appreciate it.
>
>Greg





From aredridel at nbtsc.org  Sat May 28 16:40:44 2011
From: aredridel at nbtsc.org (Aria Stewart)
Date: Sat, 28 May 2011 15:40:44 -0600
Subject: Resilient streaming protocols
Message-ID: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org>

Anyone have any interest in a forward-error-corrected streaming protocol suitable for multicast, possibly both audio and video?

Good for when there's some packet loss.

----
Aria Stewart





From jared at puck.nether.net  Sat May 28 16:50:36 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 28 May 2011 17:50:36 -0400
Subject: $ 90 million fine for cutting Internet services
In-Reply-To: <4DE14B97.9010005@kenweb.org>
References: <46E38C54-1A98-4128-99BE-0575CC34F286@americafree.tv>
	<4DE14B97.9010005@kenweb.org>
Message-ID: <B5CDFA39-8864-4819-8678-A44BA8D62559@puck.nether.net>


On May 28, 2011, at 3:23 PM, ML wrote:

> Can I fine TEDATA for committing VoIP fraud against my network during that same time period?

Running a SIP honeypot will help you identify who the bad actors are here.

There's a few numbers (and countries) to make sure you block.  You should be able to find them within a week or at most four based on their scan patterns.  The sad part is the test numbers they hit are generally in the UK to identify if the call actually makes it out.  Seems like someone should arrest the owners of those numbers.

- Jared


From jackson.tim at gmail.com  Sat May 28 17:29:44 2011
From: jackson.tim at gmail.com (Tim Jackson)
Date: Sat, 28 May 2011 17:29:44 -0500
Subject: Resilient streaming protocols
In-Reply-To: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org>
References: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org>
Message-ID: <BANLkTi=6fFyLeFhDK9N1PTDacvfPPzz3rQ@mail.gmail.com>

You mean like ProMPEG?
On May 28, 2011 4:42 PM, "Aria Stewart" <aredridel at nbtsc.org> wrote:
> Anyone have any interest in a forward-error-corrected streaming protocol
suitable for multicast, possibly both audio and video?
>
> Good for when there's some packet loss.
>
> ----
> Aria Stewart
>
>
>


From feldman at newnog.org  Sat May 28 19:05:04 2011
From: feldman at newnog.org (Steven Feldman)
Date: Sat, 28 May 2011 17:05:04 -0700
Subject: [NANOG-announce] NANOG 52 overflow hotel possibility
Message-ID: <BANLkTimabn4y5zuWiAL+gdhJ77c_r_rRWg@mail.gmail.com>

It appears that the primary hotel in Denver for NANOG 52 is close to
being sold out for the night of Tuesday, June 14.

We are exploring alternate hotels nearby.  It might be possible to get
a small room block with a discounted rate at a hotel a few blocks
away, but NewNOG would need to guarantee a minimum number of room
nights and pay for any shortfall.

So, if you have not yet made hotel reservations for NANOG 52 but plan
to do so, please reply privately to me with your name and the exact
nights you would need.  We will use that information to determine if
there is sufficient demand to guarantee the additional room block.  In
exchange, we'll let you know first if the additional block at the
alternate hotel becomes available.

Thanks,
     Steve

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce



From joly at punkcast.com  Sat May 28 22:20:06 2011
From: joly at punkcast.com (Joly MacFie)
Date: Sat, 28 May 2011 23:20:06 -0400
Subject: Choke Point Project wins Golden Nica
Message-ID: <BANLkTim0_hqZGWLs=VZXzDpq6hby4Gh_JA@mail.gmail.com>

FYI

http://www.voestalpine.com/group/en/press/press-releases/2011-05-26-prix-ars-electronica.html

*2011 winner of [the next idea] voestalpine Art and Technology Grant
**Choke Point Project / P2P Foundation (NL)
*The Choke Point Project addresses the question of who actually exercises
control over the Internet. As a general rule, the Internet is perceived as a
decentralized medium not subject to constraints imposed by power structures
or authoritarian entities. However, recent events have shown this is not so:
in practice, politicians can switch off the Internet for entire countries.
The P2P Foundation's Choke Point Project aims to pinpoint key Internet nodes
and demonstrate the ease with which constraints can be imposed on Internet
connections for entire segments of the population. The goal will be to
create visualizations in the form of "maps of the Internet", and to assemble
a variety of approaches and strategies for sidestepping such constraints.
This will help ensure the Internet is liberated from the grasp of power
structures, and that control passes to the individual.

http://www.chokepointproject.net/
http://blog.p2pfoundation.net

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From pete at altadena.net  Sun May 29 03:31:08 2011
From: pete at altadena.net (Pete Carah)
Date: Sun, 29 May 2011 04:31:08 -0400
Subject: Resilient streaming protocols
In-Reply-To: <BANLkTi=6fFyLeFhDK9N1PTDacvfPPzz3rQ@mail.gmail.com>
References: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org>
	<BANLkTi=6fFyLeFhDK9N1PTDacvfPPzz3rQ@mail.gmail.com>
Message-ID: <4DE2044C.5090909@altadena.net>

On 05/28/2011 06:29 PM, Tim Jackson wrote:
> You mean like ProMPEG?
Or Flute (open-source, streaming protocol only without library
management, the last I saw; also had some of what I'd consider bugs,
like it wouldn't recover from the receiver starting in the middle of a
carousel send.  It has been a couple of years since I've looked at it,
so some of this may be fixed now)
or Kencast Fazzt (expensive, but by far the most popular among satellite
operators from what I've seen, works fine on one-way systems with no
return path and has a nice library manager frontend), or several other
commercial offerings, and several more mostly home-grown software
systems that are run in closed networks that sell file delivery and they
don't sell their software...

-- Pete

> On May 28, 2011 4:42 PM, "Aria Stewart" <aredridel at nbtsc.org> wrote:
>> Anyone have any interest in a forward-error-corrected streaming protocol
> suitable for multicast, possibly both audio and video?
>> Good for when there's some packet loss.
>>
>> ----
>> Aria Stewart
>>
>>
>>




From kmedcalf at dessus.com  Sun May 29 18:24:02 2011
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 29 May 2011 17:24:02 -0600
Subject: $ 90 million fine for cutting Internet services
In-Reply-To: <3dc3602f8175c142af90440c75a36e14@mail.dessus.com>
Message-ID: <e13b220671397e4b99f05a82082867b5@mail.dessus.com>


Daniel Belin wrote on?2011-05-28:

> Interesting, there now seems to be a trend of middle eastern countries
> cutting themselves off from the Internet,

> I think we will see more of this kind of behavior happening in the next
> few years, as the web has become a real threat to totalitarian and
> oppressive governments.

I believe the United States was the first with that idea.

--- Keith Medcalf
()? ascii ribbon campaign against html e-mail
/\? www.asciiribbon.org







From jim at reptiles.org  Mon May 30 09:25:58 2011
From: jim at reptiles.org (Jim Mercer)
Date: Mon, 30 May 2011 10:25:58 -0400
Subject: Verisign Internet Defence Network
Message-ID: <20110530142558.GF95215@reptiles.org>


Heyo,

So, I asked to look into the viability and usefullness of the "Verisign
Internet Defence Network" service.

I don't claim to be any kind of expert in DDoS mitigation, but some of the
claims made by the product descriptions seem suspect to me.

it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event is
detected, Verisign will work with the customer to redirect Internet traffic
destined for the protected service to a Verisign Internet Defense Network
site."

anyone here have any comments on how this works, and how effective it will be
vs. dealing directly with your upstream providers and getting them to assist
in shutting down the attack?

-- 
Jim Mercer        jim at reptiles.org        +1 416 410-5633
You are more likely to be arrested as a terrorist than you are to be
blown up by one. -- Dianora



From rubensk at gmail.com  Mon May 30 09:43:35 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 30 May 2011 11:43:35 -0300
Subject: Verisign Internet Defence Network
In-Reply-To: <20110530142558.GF95215@reptiles.org>
References: <20110530142558.GF95215@reptiles.org>
Message-ID: <BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>

ms made by the product descriptions seem suspect to me.
>
> it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event is
> detected, Verisign will work with the customer to redirect Internet traffic
> destined for the protected service to a Verisign Internet Defense Network
> site."
>
> anyone here have any comments on how this works, and how effective it will be
> vs. dealing directly with your upstream providers and getting them to assist
> in shutting down the attack?

Anyone willing to announce your IP blocks under attack, receive the
traffic and then tunnel the non-attack traffic back to you can provide
such services without cooperation from your upstreams. I don't know
the details about this particular provider, such as if they announce
your blocks from yours or theirs ASN, if they use more specifics,
communities or is simply very well connected, but as BGP on the DFZ
goes, it can work.

You might need to get your upstreams to not filter announcements from
your IP block they receive, because that would prevent mitigation for
attack traffic from inside your upstream AS.

(RPKI could also be a future challenge for such service, but one could
previously sign ROAs to be used in an attack response)

Rubens



From nanogwp at gmail.com  Mon May 30 10:00:49 2011
From: nanogwp at gmail.com (Robert Lusby)
Date: Mon, 30 May 2011 16:00:49 +0100
Subject: HP 42U Cabinet - Caster fitting instructions?
Message-ID: <4DE3B121.9040200@gmail.com>

Hello,

My apologies for the off topic message. Mentioned previously, we have a 
HP Server Cabinet (42U 10842 G2), that was stripped down to the 
bare-bones chassis.

I can't for the life of me figure how the caster wheels are meant to 
attached. We have two bolts for each caster, but what seems like only 
one fitting point for each.

I have the installation instructions for the cabinet, but I believe it 
comes shipped with the casters attached as it makes no reference to how 
to fit these.

Any help on how these attach from someone with a similar cabinet, 
perhaps even a picture, would be much appreciated!

Rob



From sfouant at shortestpathfirst.net  Mon May 30 10:01:35 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Mon, 30 May 2011 11:01:35 -0400
Subject: Verisign Internet Defence Network
In-Reply-To: <20110530142558.GF95215@reptiles.org>
References: <20110530142558.GF95215@reptiles.org>
Message-ID: <000001cc1eda$7946ab00$6bd40100$@net>

> -----Original Message-----
> From: Jim Mercer [mailto:jim at reptiles.org]
> Sent: Monday, May 30, 2011 10:26 AM
> To: nanog at nanog.org
> Subject: Verisign Internet Defence Network
> 
> it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event
> is
> detected, Verisign will work with the customer to redirect Internet
> traffic
> destined for the protected service to a Verisign Internet Defense
> Network
> site."
> 
> anyone here have any comments on how this works, and how effective it
> will be
> vs. dealing directly with your upstream providers and getting them to
> assist
> in shutting down the attack?

It's really very simple.  Verisign advertises your netblock to the Internet
at whole while at the same time you cease to advertise your route to your
ISPs.  Traffic gets redirected into VIDN scrubbing center where the bad
traffic is removed.  The resulting clean traffic is sent via GRE tunnel back
to customer CPE router.

Regarding how effective it will be vs. getting your upstream to assist
really depends on how many upstream providers you have and what their
capabilities are.  Certainly dealing with one company (Verisign) is going to
be a lot easier than dealing with many upstream providers which are likely
to not have uniform offerings and services.  Most providers that are going
to be willing to assist you are only going to null-route traffic towards the
destination netblock thereby completing the DoS attack.  Those that do have
mitigation offerings are going to charge you for it, and then again, it's
not a uniform offering across all your upstream providers.

I personally think the "cloud-based" approach offered by Verisign makes a
whole heckuva lot more sense than trying to deal with heterogeneous
offerings from many disparate providers, much less having to open tickets
with each provider, having to deal with typical response times, etc.  In my
experience, reducing the number of cogs usually results in dramatically
lower mitigation times, which is certainly the end goal in dealing with
these types of attacks.

Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC




From joelja at bogus.com  Mon May 30 10:05:19 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 30 May 2011 08:05:19 -0700
Subject: Verisign Internet Defence Network
In-Reply-To: <BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>
References: <20110530142558.GF95215@reptiles.org>
	<BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>
Message-ID: <0A51200D-1499-4B0E-B4AF-9EE514558E15@bogus.com>

Normally when mitigation is put in place, they advertise a  more specific prefix from as26415, scrub the traffic and hand it back to you over a gre tunnel...

Obviously some design consideration goes into having services in prefixes you're willing to de-agg in such a fashion... I'd also recommend advertising the more specific out your own ingress paths before they pull your route otherwise the churn while various ASes grind through their longer backup routes takes a while.

On May 30, 2011, at 7:43 AM, Rubens Kuhl wrote:

> ms made by the product descriptions seem suspect to me.
>> 
>> it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event is
>> detected, Verisign will work with the customer to redirect Internet traffic
>> destined for the protected service to a Verisign Internet Defense Network
>> site."
>> 
>> anyone here have any comments on how this works, and how effective it will be
>> vs. dealing directly with your upstream providers and getting them to assist
>> in shutting down the attack?
> 
> Anyone willing to announce your IP blocks under attack, receive the
> traffic and then tunnel the non-attack traffic back to you can provide
> such services without cooperation from your upstreams. I don't know
> the details about this particular provider, such as if they announce
> your blocks from yours or theirs ASN, if they use more specifics,
> communities or is simply very well connected, but as BGP on the DFZ
> goes, it can work.
> 
> You might need to get your upstreams to not filter announcements from
> your IP block they receive, because that would prevent mitigation for
> attack traffic from inside your upstream AS.
> 
> (RPKI could also be a future challenge for such service, but one could
> previously sign ROAs to be used in an attack response)
> 
> Rubens
> 




From dmm at 1-4-5.net  Mon May 30 19:56:53 2011
From: dmm at 1-4-5.net (David Meyer)
Date: Mon, 30 May 2011 17:56:53 -0700
Subject: [NANOG-announce] Lightning talks open for NANOG 52
Message-ID: <BANLkTi=7B0x1wN5WCv8W_ssSYQAAQcweNA@mail.gmail.com>

Submit yours now!

Look forward to seeing you in Denver.

Dave

(for the NANOG PC)

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce



From rsnyder at toontown.erial.nj.us  Mon May 30 20:26:22 2011
From: rsnyder at toontown.erial.nj.us (Bob Snyder)
Date: Mon, 30 May 2011 21:26:22 -0400
Subject: Cablevision's company line on IPv6 to the home
In-Reply-To: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
References: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
Message-ID: <BANLkTinfBzys-myuuKZFNGv4GEqL7Fw5DQ@mail.gmail.com>

On Sat, May 28, 2011 at 4:21 PM, Greg Ihnen <os10rules at gmail.com> wrote:
> I just got off the phone with a level 1 tech support guy about an issue with my parents Cablevision/Optimum Online service and decided to ask the fellow if there's any official company news about IPv6 being in the works. His comments were that there is a test coming up (he was referring to World IPv6 Day), though he admitted that Cablevision is choosing not to participate in the "test" because they want to wait to see that IPv6 actually works without problems before they turn it on. He said it with a tone that seemed to express that the World IPv6 Day "test" is an irresponsible diversion. I politely and without any noticeable condescension (I believe) told him "that's what I expected" and bid him adieu.
>
> It's neat how they're going to skip that irresponsible testing phase and just turn it on one day and it's going to work perfectly.

Because when I want to know details of future major architectural
changes to a network, I usually ask a level 1 tech support guy since
he's the one most likely to know, right?

He'll know it's being rolled out when they create a script for him to
follow. One that'll likely say something like "For IPv6 problems,
immediately escalate to someone we've actually training in IPv6."

Bob



From os10rules at gmail.com  Mon May 30 21:33:53 2011
From: os10rules at gmail.com (Greg Ihnen)
Date: Mon, 30 May 2011 22:03:53 -0430
Subject: Cablevision's company line on IPv6 to the home
In-Reply-To: <BANLkTinfBzys-myuuKZFNGv4GEqL7Fw5DQ@mail.gmail.com>
References: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
	<BANLkTinfBzys-myuuKZFNGv4GEqL7Fw5DQ@mail.gmail.com>
Message-ID: <F722BA8B-D811-480F-9492-E6FA861DF2F2@gmail.com>

On May 30, 2011, at 8:56 PM, Bob Snyder wrote:

> On Sat, May 28, 2011 at 4:21 PM, Greg Ihnen <os10rules at gmail.com> wrote:
>> I just got off the phone with a level 1 tech support guy about an issue with my parents Cablevision/Optimum Online service and decided to ask the fellow if there's any official company news about IPv6 being in the works. His comments were that there is a test coming up (he was referring to World IPv6 Day), though he admitted that Cablevision is choosing not to participate in the "test" because they want to wait to see that IPv6 actually works without problems before they turn it on. He said it with a tone that seemed to express that the World IPv6 Day "test" is an irresponsible diversion. I politely and without any noticeable condescension (I believe) told him "that's what I expected" and bid him adieu.
>> 
>> It's neat how they're going to skip that irresponsible testing phase and just turn it on one day and it's going to work perfectly.
> 
> Because when I want to know details of future major architectural
> changes to a network, I usually ask a level 1 tech support guy since
> he's the one most likely to know, right?

Should I answer that? No, that was sarcasm. Nice touch.

See my post where I address the fact that I wanted to know what the company's official public position is, as you said, the "script". In that post I mention I qualified the fact that the fellow was level 1 for obvious reasons. I wasn't trying to say he had technical insight. The official script does possibly say something about the company's desire/willingness/urgency/felt need to deploy IPv6. Does hearing that there's fast and furious work going on in the NOC to bring IPv6 capability mean it will be rolled out to the customer in short order? I'd say the answer to that is "who knows".

It's not an apples to apples comparison with Cablevision's territory but down in my neck of the woods where I live the guys who work the telco's switch in town have been telling me for years that the "banda ancha" (broadband) gear is all installed as is the fiber back to the capitol and they're just waiting for the bureaucratic "OK" to turn it on. They've cut grooves in the town's "perimetral" (perimeter) road and ran fiber in the road ringing the town. That was almost two years ago. Sure seems like broadband could be just around the corner right? And the years drag on, no broadband. Sometimes the company's official public stance (from like... um... the level 1 guys) is highly indicative of what's coming.

I'm surprised that all ISPs aren't trying to glom onto IPv6 the way so many companies now feel the need to claim to be "green" just because you don't want to be the last one in your market place not claiming to be "green".

Then again, maybe you're just trolling. For trolling I like a Rapala lure (negative buoyancy) or live bait with a weight.

Here in the jungle they take an empty jug, tie a line on it and put a big hook on the end with some kind of meat or fish and throw them out in the river and them float down river with the current, mostly for the big catfish. It's the lazy man's trolling.

Greg

> He'll know it's being rolled out when they create a script for him to
> follow. One that'll likely say something like "For IPv6 problems,
> immediately escalate to someone we've actually training in IPv6."
> 
> Bob
> 




From morrowc.lists at gmail.com  Tue May 31 00:53:41 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 31 May 2011 01:53:41 -0400
Subject: Cablevision's company line on IPv6 to the home
In-Reply-To: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
References: <5E16C911-B4B7-43BB-996B-D91DCC091B8E@gmail.com>
Message-ID: <BANLkTi=UmNC7satHr5Ln34L5aSnHGho6KA@mail.gmail.com>

On Sat, May 28, 2011 at 4:21 PM, Greg Ihnen <os10rules at gmail.com> wrote:
> I just got off the phone with a level 1 tech support guy about an issue with my parents Cablevision/Optimum Online service and decided to ask the fellow if there's any official company news about IPv6 being in the works. His comments

comments from techsupport aside.. the cablevision folks did have 2-3
folks at ARIN in ... SanJuan (I think?) who were very interested and
dedicated to pushing v6 to their consumer population. I think they (as
well as every other consumer provider) have a lot of challenges in the
last-mile architecture/etc, but they do seem dedicated to solving
things for users.

I think the gentlemen I ended up chatting with from CV was commenting
on PPML as well at the time... I'm sure a quick perusal of that list
would get you his POC info for queries... which are more likely to get
useful answers than nanog posts will.

-chris



From cabenth at gmail.com  Tue May 31 10:36:50 2011
From: cabenth at gmail.com (eric clark)
Date: Tue, 31 May 2011 08:36:50 -0700
Subject: Deploying IPv6 globally
Message-ID: <BANLkTi=NoP7AyjZ1a2mGXGXYqFAUDOgBQA@mail.gmail.com>

Many North American based organizations operate with their ARIN issued BGP
AS distributed globally.

When I discussed obtaining IPv6 space from ARIN a few years ago, they told
me to submit an individual request  for each of my sites (and they'd issue a
/48 or larger based on the site). This is the process I've been following,
until now, for my North American sites...

My question is, has anyone started deploying ARIN IP space to their global
offices? If so, how are you registering those sites with ARIN?
Or did they tell you something else?

Thanks

-C


From joelja at bogus.com  Tue May 31 10:54:32 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 31 May 2011 08:54:32 -0700
Subject: Deploying IPv6 globally
In-Reply-To: <BANLkTi=NoP7AyjZ1a2mGXGXYqFAUDOgBQA@mail.gmail.com>
References: <BANLkTi=NoP7AyjZ1a2mGXGXYqFAUDOgBQA@mail.gmail.com>
Message-ID: <632478B3-E40A-4FC8-A39E-C47B2F8399AE@bogus.com>

At a previous company my pi assigment request included our overseas sites. the bulk of the assignment and the business unit making the request were based in north america. resulting request was for a /43.

joel

On May 31, 2011, at 8:36 AM, eric clark wrote:

> Many North American based organizations operate with their ARIN issued BGP
> AS distributed globally.
> 
> When I discussed obtaining IPv6 space from ARIN a few years ago, they told
> me to submit an individual request  for each of my sites (and they'd issue a
> /48 or larger based on the site). This is the process I've been following,
> until now, for my North American sites...
> 
> My question is, has anyone started deploying ARIN IP space to their global
> offices? If so, how are you registering those sites with ARIN?
> Or did they tell you something else?
> 
> Thanks
> 
> -C
> 




From JMacleod at alentus.com  Tue May 31 10:51:55 2011
From: JMacleod at alentus.com (John Macleod)
Date: Tue, 31 May 2011 09:51:55 -0600
Subject: Deploying IPv6 globally
In-Reply-To: <632478B3-E40A-4FC8-A39E-C47B2F8399AE@bogus.com>
References: <BANLkTi=NoP7AyjZ1a2mGXGXYqFAUDOgBQA@mail.gmail.com>,
	<632478B3-E40A-4FC8-A39E-C47B2F8399AE@bogus.com>
Message-ID: <060EDFC2221B014B9504AC06B747F58A49A6F31ADB@ex01.alentus.lan>

I have done this several times for NA orgs with global sites with ARIN and for EU orgs with global sites with RIPE.

ARIN were fine, RIPE just excluded any non-RIPE governed locations from the calculation criteria, however they were granted on all counts.

John

________________________________________
From: Joel Jaeggli [joelja at bogus.com]
Sent: Tuesday, May 31, 2011 4:54 PM
To: eric clark
Cc: NANOG list
Subject: Re: Deploying IPv6 globally

At a previous company my pi assigment request included our overseas sites. the bulk of the assignment and the business unit making the request were based in north america. resulting request was for a /43.

joel

On May 31, 2011, at 8:36 AM, eric clark wrote:

> Many North American based organizations operate with their ARIN issued BGP
> AS distributed globally.
>
> When I discussed obtaining IPv6 space from ARIN a few years ago, they told
> me to submit an individual request  for each of my sites (and they'd issue a
> /48 or larger based on the site). This is the process I've been following,
> until now, for my North American sites...
>
> My question is, has anyone started deploying ARIN IP space to their global
> offices? If so, how are you registering those sites with ARIN?
> Or did they tell you something else?
>
> Thanks
>
> -C
>



"Please consider the environment before printing this e-mail

This e-mail (and/or any attachment) contains information, which is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient you must not copy, distribute or use it for any purpose or disclose the contents to any person. If you have received this e-mail in error, please immediately notify the sender. The information contained in this e-mail (and any attachments) is supplied in good faith, but the sender shall not be under any liability in damages or otherwise for any reliance that may be placed upon it by the recipient, nor does it constitute a contract in any way. Any comments or opinions expressed are those of the originator not of Alentus Corporation unless otherwise expressly stated."




From owen at delong.com  Tue May 31 11:41:36 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 31 May 2011 09:41:36 -0700
Subject: Deploying IPv6 globally
In-Reply-To: <BANLkTi=NoP7AyjZ1a2mGXGXYqFAUDOgBQA@mail.gmail.com>
References: <BANLkTi=NoP7AyjZ1a2mGXGXYqFAUDOgBQA@mail.gmail.com>
Message-ID: <5816A43E-7B4C-4DCA-9826-22BCA19FC21E@delong.com>


On May 31, 2011, at 8:36 AM, eric clark wrote:

> Many North American based organizations operate with their ARIN issued BGP
> AS distributed globally.
> 
> When I discussed obtaining IPv6 space from ARIN a few years ago, they told
> me to submit an individual request  for each of my sites (and they'd issue a
> /48 or larger based on the site). This is the process I've been following,
> until now, for my North American sites...
> 
> My question is, has anyone started deploying ARIN IP space to their global
> offices? If so, how are you registering those sites with ARIN?
> Or did they tell you something else?
> 
> Thanks
> 
> -C

Not a problem. As long as you are HQ in the ARIN region, you can obtain
space from ARIN regardless of where you use it. You also have the option
of getting the space from whatever RIR the particular infrastructure is
located within.

Owen




From deepak at ai.net  Tue May 31 14:06:46 2011
From: deepak at ai.net (Deepak Jain)
Date: Tue, 31 May 2011 15:06:46 -0400
Subject: VeriSign Internet Defense Network
In-Reply-To: <0A51200D-1499-4B0E-B4AF-9EE514558E15@bogus.com>
References: <20110530142558.GF95215@reptiles.org>
	<BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>
	<0A51200D-1499-4B0E-B4AF-9EE514558E15@bogus.com>
Message-ID: <D338D1613B32624285BB321A5CF3DB25137BFF1DE1@ginga.ai.net>

Let's not ignore the value of DNS with a short ttl time. It may not be "as quick" as a BGP adjustment, but serves to provide a buttressed front-end IP that can restore service "instantly" [faster than getting someone on the phone to coordinate the change, etc]. 

Disclaimer: We provide a service for our customers that does substantially this sort of DDOS mitigation.

DJ

> 
> Normally when mitigation is put in place, they advertise a  more
> specific prefix from as26415, scrub the traffic and hand it back to you
> over a gre tunnel...
> 
> Obviously some design consideration goes into having services in
> prefixes you're willing to de-agg in such a fashion... I'd also
> recommend advertising the more specific out your own ingress paths
> before they pull your route otherwise the churn while various ASes
> grind through their longer backup routes takes a while.
> 
> On May 30, 2011, at 7:43 AM, Rubens Kuhl wrote:
> 
> > ms made by the product descriptions seem suspect to me.
> >>
> >> it claims to be "Carrier-agnostic and ISP-neutral", yet "When an
> event is
> >> detected, Verisign will work with the customer to redirect Internet
> traffic
> >> destined for the protected service to a Verisign Internet Defense
> Network
> >> site."
> >>
> >> anyone here have any comments on how this works, and how effective
> it will be
> >> vs. dealing directly with your upstream providers and getting them
> to assist
> >> in shutting down the attack?
> >
> > Anyone willing to announce your IP blocks under attack, receive the
> > traffic and then tunnel the non-attack traffic back to you can
> provide
> > such services without cooperation from your upstreams. I don't know
> > the details about this particular provider, such as if they announce
> > your blocks from yours or theirs ASN, if they use more specifics,
> > communities or is simply very well connected, but as BGP on the DFZ
> > goes, it can work.
> >
> > You might need to get your upstreams to not filter announcements from
> > your IP block they receive, because that would prevent mitigation for
> > attack traffic from inside your upstream AS.
> >
> > (RPKI could also be a future challenge for such service, but one
> could
> > previously sign ROAs to be used in an attack response)
> >
> > Rubens
> >
> 




From morrowc.lists at gmail.com  Tue May 31 14:31:01 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 31 May 2011 15:31:01 -0400
Subject: VeriSign Internet Defense Network
In-Reply-To: <D338D1613B32624285BB321A5CF3DB25137BFF1DE1@ginga.ai.net>
References: <20110530142558.GF95215@reptiles.org>
	<BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>
	<0A51200D-1499-4B0E-B4AF-9EE514558E15@bogus.com>
	<D338D1613B32624285BB321A5CF3DB25137BFF1DE1@ginga.ai.net>
Message-ID: <BANLkTinCCmfKau3F8nqtbSQM_H_MPjS1vg@mail.gmail.com>

On Tue, May 31, 2011 at 3:06 PM, Deepak Jain <deepak at ai.net> wrote:
> Let's not ignore the value of DNS with a short ttl time. It may not be "as quick" as a BGP adjustment, but serves to provide a buttressed front-end IP that can restore service "instantly" [faster than getting someone on the phone to coordinate the change, etc].
>
> Disclaimer: We provide a service for our customers that does substantially this sort of DDOS mitigation.
>

also, note that VerizonBusiness ddos-mitigation service was
no-call-required, just send the right community on a configured
session ... and 'cheap'.

-chris

>>
>> Normally when mitigation is put in place, they advertise a ?more
>> specific prefix from as26415, scrub the traffic and hand it back to you
>> over a gre tunnel...
>>
>> Obviously some design consideration goes into having services in
>> prefixes you're willing to de-agg in such a fashion... I'd also
>> recommend advertising the more specific out your own ingress paths
>> before they pull your route otherwise the churn while various ASes
>> grind through their longer backup routes takes a while.
>>
>> On May 30, 2011, at 7:43 AM, Rubens Kuhl wrote:
>>
>> > ms made by the product descriptions seem suspect to me.
>> >>
>> >> it claims to be "Carrier-agnostic and ISP-neutral", yet "When an
>> event is
>> >> detected, Verisign will work with the customer to redirect Internet
>> traffic
>> >> destined for the protected service to a Verisign Internet Defense
>> Network
>> >> site."
>> >>
>> >> anyone here have any comments on how this works, and how effective
>> it will be
>> >> vs. dealing directly with your upstream providers and getting them
>> to assist
>> >> in shutting down the attack?
>> >
>> > Anyone willing to announce your IP blocks under attack, receive the
>> > traffic and then tunnel the non-attack traffic back to you can
>> provide
>> > such services without cooperation from your upstreams. I don't know
>> > the details about this particular provider, such as if they announce
>> > your blocks from yours or theirs ASN, if they use more specifics,
>> > communities or is simply very well connected, but as BGP on the DFZ
>> > goes, it can work.
>> >
>> > You might need to get your upstreams to not filter announcements from
>> > your IP block they receive, because that would prevent mitigation for
>> > attack traffic from inside your upstream AS.
>> >
>> > (RPKI could also be a future challenge for such service, but one
>> could
>> > previously sign ROAs to be used in an attack response)
>> >
>> > Rubens
>> >
>>
>
>
>



From sfouant at shortestpathfirst.net  Tue May 31 14:47:16 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Tue, 31 May 2011 15:47:16 -0400
Subject: VeriSign Internet Defense Network
In-Reply-To: <D338D1613B32624285BB321A5CF3DB25137BFF1DE1@ginga.ai.net>
References: <20110530142558.GF95215@reptiles.org>	<BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>	<0A51200D-1499-4B0E-B4AF-9EE514558E15@bogus.com>
	<D338D1613B32624285BB321A5CF3DB25137BFF1DE1@ginga.ai.net>
Message-ID: <006301cc1fcb$8c95c730$a5c15590$@net>

> -----Original Message-----
> From: Deepak Jain [mailto:deepak at ai.net]
> Sent: Tuesday, May 31, 2011 3:07 PM
> Subject: RE: VeriSign Internet Defense Network
> 
> Let's not ignore the value of DNS with a short ttl time. It may not be
> "as quick" as a BGP adjustment, but serves to provide a buttressed
> front-end IP that can restore service "instantly" [faster than getting
> someone on the phone to coordinate the change, etc].

Heck, if it's good enough for fast-flux, it's good enough for me ;)

Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC




From sfouant at shortestpathfirst.net  Tue May 31 14:51:59 2011
From: sfouant at shortestpathfirst.net (Stefan Fouant)
Date: Tue, 31 May 2011 15:51:59 -0400
Subject: VeriSign Internet Defense Network
In-Reply-To: <BANLkTinCCmfKau3F8nqtbSQM_H_MPjS1vg@mail.gmail.com>
References: <20110530142558.GF95215@reptiles.org>	<BANLkTimQYR79rJvM0PHYk0=1nSqoCfxY-w@mail.gmail.com>	<0A51200D-1499-4B0E-B4AF-9EE514558E15@bogus.com>	<D338D1613B32624285BB321A5CF3DB25137BFF1DE1@ginga.ai.net>
	<BANLkTinCCmfKau3F8nqtbSQM_H_MPjS1vg@mail.gmail.com>
Message-ID: <006601cc1fcc$34f877b0$9ee96710$@net>

> -----Original Message-----
> From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
> Sent: Tuesday, May 31, 2011 3:31 PM
> Subject: Re: VeriSign Internet Defense Network
> 
> also, note that VerizonBusiness ddos-mitigation service was
> no-call-required, just send the right community on a configured
> session ... and 'cheap'.

The downside to their approach is that it only works for sites you actually
have connected to VzB's network.  They could just as easily offer the
service to off-net customers similar to what Verisign and Prolexic do, but
for some reason we could never convince the marketing folks to do just
that...

Agreed though, it is super-easy to use and competitively priced.

Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
GPG Key ID: 0xB4C956EC





From joly at punkcast.com  Tue May 31 16:17:45 2011
From: joly at punkcast.com (Joly MacFie)
Date: Tue, 31 May 2011 17:17:45 -0400
Subject: IPv6 day meetup in NYC?
Message-ID: <BANLkTikceUbzY6=btAyVSidXpghYsdqkqQ@mail.gmail.com>

This is now set for 7pm, June 8, at NYU. An informal meeting (no webcast)
followed by a visit to a nearby drinking establishment.

http://isoc-ny.org/p2/?p=2149

<http://isoc-ny.org/p2/?p=2149>j

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-


From toivo at usf.edu  Tue May 31 16:31:52 2011
From: toivo at usf.edu (Voll, Toivo)
Date: Tue, 31 May 2011 17:31:52 -0400
Subject: Yahoo and IPv6
In-Reply-To: <Pine.OSX.4.64.1105091221180.320@cevin.lv.enet.interop.net>
References: <AQHMDhXyKg2S7/U2QUaQboRIZhbyWg==>
	<C9EDE811.A0C8%fmartin@linkedin.com>
	<BANLkTimrcQ3i85XaVK4T_BstXosMNJf9-A@mail.gmail.com>
	<Pine.OSX.4.64.1105091221180.320@cevin.lv.enet.interop.net>
Message-ID: <C5346EBB3EF3AA4C984D4F0F6D21542739A36501ED@USFMAIL2.forest.usf.edu>

Going to http://help.yahoo.com/l/us/yahoo/ipv6/ and hitting "Start IPv6 Test" I get:
"Your system will continue to work for you on World IPv6 day. However, we found that your server only supports IPv4 at this time. You'll simply continue to use IPv4 to reach your favorite web sites."

Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken. 

Toivo Voll
Network Administrator
Information Technology Communications
University of South Florida

-----Original Message-----
From: Brandon Ross [mailto:bross at pobox.com] 
Sent: Monday, May 09, 2011 12:25
To: Arie Vayner
Cc: nanog at nanog.org
Subject: Re: Yahoo and IPv6

Even more disturbing than that is that when I run a test from here it says 
that I have broken v6.  But I don't have broken v6 and test-v6.com proves 
it with a 10/10.  This Yahoo tool doesn't seem to even give a hint as to 
what it thinks is broken.

Can anyone from Yahoo shed some light on what this tool is doing and how 
to get it to tell us what it thinks is broken?

-- 
Brandon Ross                                              AIM:  BrandonNRoss
                                                                ICQ:  2269442
                                    Skype:  brandonross  Yahoo:  BrandonNRoss