From ulf at alameda.net  Tue May  1 02:16:13 2012
From: ulf at alameda.net (Ulf Zimmermann)
Date: Tue, 1 May 2012 00:16:13 -0700
Subject: Power pricing in San Francisco Bay Area colocations?
Message-ID: <032501cd276a$4a983c80$dfc8b580$@alameda.net>

I am trying to compare some pricing, anyone who has recently priced circuits
such as 208V/30A single and 3-phase (max load factor of 40% for A+B power),
could you tell me what you have been offered? I don't need the names of the
companies the pricing comes from, just trying to see a snapshot of pricing,
as I am currently in negotiation with one provider.

Ulf.




From russw at riw.us  Tue May  1 06:19:52 2012
From: russw at riw.us (Russ White)
Date: Tue, 01 May 2012 07:19:52 -0400
Subject: rpki vs. secure dns?
In-Reply-To: <m27gwx5ikh.wl%randy@psg.com>
References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de>
 <F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net>
 <DB5B6839-CB35-4227-B909-88BB84B54770@tcb.net>
 <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru>
 <m27gwx5ikh.wl%randy@psg.com>
Message-ID: <4F9FC6D8.5040900@riw.us>

Randy:

> as i agree that there is a problem, i *very* eagerly await your proposal

Reality: A few years back there were a half a dozen options proposed.
soBGP, pgBGP, IRR based solutions, etc. Just recently PSVs were
discussed and dismissed as a live option.

Why?

1. Only S-BGP/BGP-SEC will solve the "man in the middle attack," within
the parameter of "I won't ever tell anyone what any of my policies are!"
This single requirement --solving one specific policy issue without
advertising policy-- has been the center pin of the entire discussion
for a number of years.

2. Any time someone proposed something different, long threads ensue
with lots of talk about how these folks don't know what they're talking
about, etc., but which contain very little technical discussion, or
thoughts on tradeoffs, etc. Any technical discussion is limited to
taking out the "man in the middle attack," and beating it over the heads
of those making the proposal --repeatedly.

So the bottom line is this: The current requirements were written around
the ability of one particular solution to solve one particular policy
issue in a way that's acceptable to a very small set of operators.

A single root has been a requirement for a long time, as well --we had
this discussion a very long time ago. No other solution proposed had a
single root, and S-BGP/BGP-SEC didn't have to use a single root. But a
single root somehow made it into the requirements, and it's stayed there
ever since.

If you want honestly more options, go back and rethink your requirements.

Russ



From rdobbins at arbor.net  Tue May  1 06:34:15 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 1 May 2012 11:34:15 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <4F9B181D.30606@isc.org>
References: <4F9B181D.30606@isc.org>
Message-ID: <F0DFCCC6-1604-426D-A31D-7AE7C11989F6@arbor.net>


On Apr 28, 2012, at 5:05 AM, Paul Vixie wrote:

> is anybody taking it seriously?

It's hard to take seriously any proposal which is predicated upon recursive dependencies.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From rdobbins at arbor.net  Tue May  1 06:36:23 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 1 May 2012 11:36:23 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <20120428101710.GA26852@pob.ytti.fi>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
Message-ID: <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>


On Apr 28, 2012, at 5:17 PM, Saku Ytti wrote:

> People might scared to rely on DNS on accepting routes, but is this really an issue? 

Yes, recursive dependencies are an issue.  I'm really surprised that folks are even seriously considering something like this, but OTOH, this sort of thing keeps cropping up in various contexts from time to time, sigh.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From tshaw at oitc.com  Tue May  1 07:01:20 2012
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 1 May 2012 08:01:20 -0400
Subject: Problems getting to Verisign's whois server on IPv6
Message-ID: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>

Anyone else having problems getting to Verisign's whois server on IPv6?

$ host com.whois-servers.net
com.whois-servers.net is an alias for whois.verisign-grs.com.
whois.verisign-grs.com has address 199.7.59.74
whois.verisign-grs.com has IPv6 address 2001:503:3227:1060::74

$ traceroute6 2001:503:3227:1060::74
traceroute6 to 2001:503:3227:1060::74 (2001:503:3227:1060::74) from 2001:470:5:4ed:cabc:c8ff:fea1:560c, 64 hops max, 12 byte packets
 1  2001:470:5:4ed:226:bbff:fe6d:426e  0.311 ms  0.374 ms  0.260 ms
 2  ipv6oitc-1.tunnel.tserv12.mia1.ipv6.he.net  21.128 ms  21.052 ms  17.389 ms
 3  gige-g2-3.core1.mia1.he.net  20.055 ms  16.198 ms  22.699 ms
 4  10gigabitethernet4-3.core1.atl1.he.net  40.166 ms  33.887 ms  32.547 ms
 5  10gigabitethernet6-4.core1.ash1.he.net  49.821 ms  45.999 ms  52.751 ms
 6  2001:504:0:2::2641:1  47.197 ms  46.748 ms  47.289 ms
 7  xe-1-2-0.r1.bb-fo.chi2.vrsn.net  65.094 ms
    xe-0-2-0.r2.bb-fo.chi2.vrsn.net  66.441 ms
    xe-1-2-0.r1.bb-fo.chi2.vrsn.net  66.320 ms
 8  2001:503:3227:14ff::2  66.448 ms
    2001:503:3227:13ff::2  101.761 ms  86.864 ms
 9  2001:503:3227:13ff::2  69.818 ms !P
    2001:503:3227:14ff::2  69.311 ms !P
    2001:503:3227:13ff::2  68.662 ms !P



From ttauber at 1-4-5.net  Tue May  1 07:15:59 2012
From: ttauber at 1-4-5.net (Tony Tauber)
Date: Tue, 1 May 2012 08:15:59 -0400
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
Message-ID: <CAGQUKcfV+TJXQ7hAhJaUwemLTepokDNamEXzZS4v11fkDiAzWg@mail.gmail.com>

Path is not the same, but the last few replies similarly suggest
packet-filters (!X in my case vs. !P).
I can get to the whois port (TCP/43):

$ telnet -6 2001:503:3227:1060::74 whois
Trying 2001:503:3227:1060::74...
Connected to 2001:503:3227:1060::74.
Escape character is '^]'.

Can you?

Tony

On Tue, May 1, 2012 at 8:01 AM, TR Shaw <tshaw at oitc.com> wrote:

> Anyone else having problems getting to Verisign's whois server on IPv6?
>
> $ host com.whois-servers.net
> com.whois-servers.net is an alias for whois.verisign-grs.com.
> whois.verisign-grs.com has address 199.7.59.74
> whois.verisign-grs.com has IPv6 address 2001:503:3227:1060::74
>
> $ traceroute6 2001:503:3227:1060::74
> traceroute6 to 2001:503:3227:1060::74 (2001:503:3227:1060::74) from
> 2001:470:5:4ed:cabc:c8ff:fea1:560c, 64 hops max, 12 byte packets
>  1  2001:470:5:4ed:226:bbff:fe6d:426e  0.311 ms  0.374 ms  0.260 ms
>  2  ipv6oitc-1.tunnel.tserv12.mia1.ipv6.he.net  21.128 ms  21.052 ms
>  17.389 ms
>  3  gige-g2-3.core1.mia1.he.net  20.055 ms  16.198 ms  22.699 ms
>  4  10gigabitethernet4-3.core1.atl1.he.net  40.166 ms  33.887 ms  32.547
> ms
>  5  10gigabitethernet6-4.core1.ash1.he.net  49.821 ms  45.999 ms  52.751
> ms
>  6  2001:504:0:2::2641:1  47.197 ms  46.748 ms  47.289 ms
>  7  xe-1-2-0.r1.bb-fo.chi2.vrsn.net  65.094 ms
>    xe-0-2-0.r2.bb-fo.chi2.vrsn.net  66.441 ms
>    xe-1-2-0.r1.bb-fo.chi2.vrsn.net  66.320 ms
>  8  2001:503:3227:14ff::2  66.448 ms
>    2001:503:3227:13ff::2  101.761 ms  86.864 ms
>  9  2001:503:3227:13ff::2  69.818 ms !P
>    2001:503:3227:14ff::2  69.311 ms !P
>    2001:503:3227:13ff::2  68.662 ms !P
>
>
>

From tshaw at oitc.com  Tue May  1 07:23:17 2012
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 1 May 2012 08:23:17 -0400
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <CAGQUKcfV+TJXQ7hAhJaUwemLTepokDNamEXzZS4v11fkDiAzWg@mail.gmail.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
 <CAGQUKcfV+TJXQ7hAhJaUwemLTepokDNamEXzZS4v11fkDiAzWg@mail.gmail.com>
Message-ID: <B35E1A66-47D6-46A9-9FC5-B0B1FE833434@oitc.com>

Nope sure can't

$  telnet -6 2001:503:3227:1060::74 whois
2001:503:3227:1060::74: nodename nor servname provided, or not known

Tom

On May 1, 2012, at 8:15 AM, Tony Tauber wrote:

> Path is not the same, but the last few replies similarly suggest packet-filters (!X in my case vs. !P).
> I can get to the whois port (TCP/43):
> 
> $ telnet -6 2001:503:3227:1060::74 whois
> Trying 2001:503:3227:1060::74...
> Connected to 2001:503:3227:1060::74.
> Escape character is '^]'.
> 
> Can you?
> 
> Tony
> 
> On Tue, May 1, 2012 at 8:01 AM, TR Shaw <tshaw at oitc.com> wrote:
> Anyone else having problems getting to Verisign's whois server on IPv6?
> 
> $ host com.whois-servers.net
> com.whois-servers.net is an alias for whois.verisign-grs.com.
> whois.verisign-grs.com has address 199.7.59.74
> whois.verisign-grs.com has IPv6 address 2001:503:3227:1060::74
> 
> $ traceroute6 2001:503:3227:1060::74
> traceroute6 to 2001:503:3227:1060::74 (2001:503:3227:1060::74) from 2001:470:5:4ed:cabc:c8ff:fea1:560c, 64 hops max, 12 byte packets
>  1  2001:470:5:4ed:226:bbff:fe6d:426e  0.311 ms  0.374 ms  0.260 ms
>  2  ipv6oitc-1.tunnel.tserv12.mia1.ipv6.he.net  21.128 ms  21.052 ms  17.389 ms
>  3  gige-g2-3.core1.mia1.he.net  20.055 ms  16.198 ms  22.699 ms
>  4  10gigabitethernet4-3.core1.atl1.he.net  40.166 ms  33.887 ms  32.547 ms
>  5  10gigabitethernet6-4.core1.ash1.he.net  49.821 ms  45.999 ms  52.751 ms
>  6  2001:504:0:2::2641:1  47.197 ms  46.748 ms  47.289 ms
>  7  xe-1-2-0.r1.bb-fo.chi2.vrsn.net  65.094 ms
>    xe-0-2-0.r2.bb-fo.chi2.vrsn.net  66.441 ms
>    xe-1-2-0.r1.bb-fo.chi2.vrsn.net  66.320 ms
>  8  2001:503:3227:14ff::2  66.448 ms
>    2001:503:3227:13ff::2  101.761 ms  86.864 ms
>  9  2001:503:3227:13ff::2  69.818 ms !P
>    2001:503:3227:14ff::2  69.311 ms !P
>    2001:503:3227:13ff::2  68.662 ms !P
> 
> 
> 


From Jason_Livingood at cable.comcast.com  Tue May  1 07:26:20 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 1 May 2012 12:26:20 +0000
Subject: Operation Ghost Click
In-Reply-To: <4F99C288.1030705@paulgraydon.co.uk>
Message-ID: <CBC546BF.5C805%jason_livingood@cable.comcast.com>

On 4/26/12 5:47 PM, "Paul Graydon" <paul at paulgraydon.co.uk> wrote:

>Based on conversations on this list a month or so ago, ISPs were
>contacted with details of which of their IPs had compromised boxes
>behind them, but it seems the consensus is that ISP were going to just
>wait for users to phone support when it broke rather than be proactive
>about it.

I doubt most big ISPs would be so reactive (those calls cost real money
after all, and customer satisfaction suffers), but I guess you never know.
At Comcast we have done the following:
- Sent emails
- Send postal mail
- Left voicemail
- Used automated outbound calling
- Used increasingly persistent web browser notifications

We've measured the effectiveness of some of these notification methods,
which we'd not employed previously in our Constant Guard bot notification
program. We're considering writing up a paper about this after the July
date passes.

Jason



From Jason_Livingood at cable.comcast.com  Tue May  1 07:26:21 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 1 May 2012 12:26:21 +0000
Subject: Operation Ghost Click
In-Reply-To: <4F99FE80.6010007@utc.edu>
Message-ID: <CBC547DF.5C80F%jason_livingood@cable.comcast.com>

On 4/26/12 10:03 PM, "Jeff Kell" <jeff-kell at utc.edu> wrote:

>And what about the millions of users unknowingly infected with
>"something else" ??
>
>(We have enough trouble isolating/remediating issues among our
>relatively small user base, I'd hate to be facing a major ISP size
>support/remediation effort...)
>
>Does anyone have a plan?

Well, there's the new botnet code of conduct think (Mike O'Reirdan can
chime in with more info here). Plus ISPs like the one I work at (Comcast)
have been doing bot notification and remediation for some time now. I know
other ISPs have different approaches, and so different bot programs, but
the majority of them are doing something (with a few exceptions).

Jason



From jaap at NLnetLabs.nl  Tue May  1 07:32:08 2012
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 01 May 2012 14:32:08 +0200
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
Message-ID: <201205011232.q41CW8W6011679@bela.nlnetlabs.nl>


    Anyone else having problems getting to Verisign's whois server on IPv6?

whois -h 2001:503:ff39:1060::74 verisign-grs.com

works for me.

	jaap
	


From mike.simkins at sungard.com  Tue May  1 07:33:07 2012
From: mike.simkins at sungard.com (Mike Simkins)
Date: Tue, 1 May 2012 13:33:07 +0100
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <B35E1A66-47D6-46A9-9FC5-B0B1FE833434@oitc.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
 <CAGQUKcfV+TJXQ7hAhJaUwemLTepokDNamEXzZS4v11fkDiAzWg@mail.gmail.com>
 <B35E1A66-47D6-46A9-9FC5-B0B1FE833434@oitc.com>
Message-ID: <260a5e95c95a8c71446ff50b81e73f09@mail.gmail.com>

Seems to work for me....

mps31 at lonsgnsu1:~$ telnet -6 2001:503:3227:1060::74 whois
Trying 2001:503:3227:1060::74...
Connected to 2001:503:3227:1060::74.
Escape character is '^]'.

mps31 at lonsgnsu1:~$ whois -h 2001:503:3227:1060::74 =verisign.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: VERISIGN.COM
   Registrar: NETWORK SOLUTIONS, LLC.
   Whois Server: whois.networksolutions.com
   Referral URL: http://www.networksolutions.com/en_US/
   Name Server: A2.NSTLD.COM
   Name Server: C2.NSTLD.NET
   Name Server: D2.NSTLD.NET
   Name Server: E2.NSTLD.NET
   Name Server: F2.NSTLD.COM
   Name Server: G2.NSTLD.COM
   Name Server: H2.NSTLD.NET
   Name Server: J2.NSTLD.NET
   Name Server: K2.NSTLD.NET
   Name Server: L2.NSTLD.COM
   Name Server: M2.NSTLD.NET
   Status: clientTransferProhibited
   Status: serverDeleteProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited
   Updated Date: 14-apr-2011
   Creation Date: 02-jun-1995
   Expiration Date: 01-jun-2012

>>> Last update of whois database: Tue, 01 May 2012 12:29:12 UTC <<<

Mike Simkins ? Senior Network Engineer , Operations Engineering ? SunGard
Availability Services ? 25 Canada Square, London E14 5LQ

-----Original Message-----
From: TR Shaw [mailto:tshaw at oitc.com]
Sent: 01 May 2012 13:23
To: Tony Tauber
Cc: NANOG list
Subject: Re: Problems getting to Verisign's whois server on IPv6

Nope sure can't

$  telnet -6 2001:503:3227:1060::74 whois
2001:503:3227:1060::74: nodename nor servname provided, or not known

Tom

On May 1, 2012, at 8:15 AM, Tony Tauber wrote:

> Path is not the same, but the last few replies similarly suggest
> packet-filters (!X in my case vs. !P).
> I can get to the whois port (TCP/43):
>
> $ telnet -6 2001:503:3227:1060::74 whois Trying
> 2001:503:3227:1060::74...
> Connected to 2001:503:3227:1060::74.
> Escape character is '^]'.
>
> Can you?
>
> Tony
>
> On Tue, May 1, 2012 at 8:01 AM, TR Shaw <tshaw at oitc.com> wrote:
> Anyone else having problems getting to Verisign's whois server on IPv6?
>
> $ host com.whois-servers.net
> com.whois-servers.net is an alias for whois.verisign-grs.com.
> whois.verisign-grs.com has address 199.7.59.74 whois.verisign-grs.com
> has IPv6 address 2001:503:3227:1060::74
>
> $ traceroute6 2001:503:3227:1060::74
> traceroute6 to 2001:503:3227:1060::74 (2001:503:3227:1060::74) from
> 2001:470:5:4ed:cabc:c8ff:fea1:560c, 64 hops max, 12 byte packets
>  1  2001:470:5:4ed:226:bbff:fe6d:426e  0.311 ms  0.374 ms  0.260 ms
>  2  ipv6oitc-1.tunnel.tserv12.mia1.ipv6.he.net  21.128 ms  21.052 ms
> 17.389 ms
>  3  gige-g2-3.core1.mia1.he.net  20.055 ms  16.198 ms  22.699 ms
>  4  10gigabitethernet4-3.core1.atl1.he.net  40.166 ms  33.887 ms
> 32.547 ms
>  5  10gigabitethernet6-4.core1.ash1.he.net  49.821 ms  45.999 ms
> 52.751 ms
>  6  2001:504:0:2::2641:1  47.197 ms  46.748 ms  47.289 ms
>  7  xe-1-2-0.r1.bb-fo.chi2.vrsn.net  65.094 ms
>    xe-0-2-0.r2.bb-fo.chi2.vrsn.net  66.441 ms
>    xe-1-2-0.r1.bb-fo.chi2.vrsn.net  66.320 ms
>  8  2001:503:3227:14ff::2  66.448 ms
>    2001:503:3227:13ff::2  101.761 ms  86.864 ms
>  9  2001:503:3227:13ff::2  69.818 ms !P
>    2001:503:3227:14ff::2  69.311 ms !P
>    2001:503:3227:13ff::2  68.662 ms !P
>
>
>


From jared at puck.nether.net  Tue May  1 07:35:47 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 1 May 2012 08:35:47 -0400
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <B35E1A66-47D6-46A9-9FC5-B0B1FE833434@oitc.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
 <CAGQUKcfV+TJXQ7hAhJaUwemLTepokDNamEXzZS4v11fkDiAzWg@mail.gmail.com>
 <B35E1A66-47D6-46A9-9FC5-B0B1FE833434@oitc.com>
Message-ID: <D9BBC353-7E8C-4191-98FF-8FDB4B3D6A8F@puck.nether.net>

This looks to be more of an application issue for you.

The rest seems to work for me:

puck:~$ whois -h 2001:503:ff39:1060::74 verisign-grs.com
[Querying 2001:503:ff39:1060::74]
[2001:503:ff39:1060::74]

Whois Server Version 2.0

...

- Jared

On May 1, 2012, at 8:23 AM, TR Shaw wrote:

> Nope sure can't
> 
> $  telnet -6 2001:503:3227:1060::74 whois
> 2001:503:3227:1060::74: nodename nor servname provided, or not known
> 
> Tom
> 
> On May 1, 2012, at 8:15 AM, Tony Tauber wrote:
> 
>> Path is not the same, but the last few replies similarly suggest packet-filters (!X in my case vs. !P).
>> I can get to the whois port (TCP/43):
>> 
>> $ telnet -6 2001:503:3227:1060::74 whois
>> Trying 2001:503:3227:1060::74...
>> Connected to 2001:503:3227:1060::74.
>> Escape character is '^]'.
>> 
>> Can you?
>> 
>> Tony
>> 
>> On Tue, May 1, 2012 at 8:01 AM, TR Shaw <tshaw at oitc.com> wrote:
>> Anyone else having problems getting to Verisign's whois server on IPv6?
>> 
>> $ host com.whois-servers.net
>> com.whois-servers.net is an alias for whois.verisign-grs.com.
>> whois.verisign-grs.com has address 199.7.59.74
>> whois.verisign-grs.com has IPv6 address 2001:503:3227:1060::74
>> 
>> $ traceroute6 2001:503:3227:1060::74
>> traceroute6 to 2001:503:3227:1060::74 (2001:503:3227:1060::74) from 2001:470:5:4ed:cabc:c8ff:fea1:560c, 64 hops max, 12 byte packets
>> 1  2001:470:5:4ed:226:bbff:fe6d:426e  0.311 ms  0.374 ms  0.260 ms
>> 2  ipv6oitc-1.tunnel.tserv12.mia1.ipv6.he.net  21.128 ms  21.052 ms  17.389 ms
>> 3  gige-g2-3.core1.mia1.he.net  20.055 ms  16.198 ms  22.699 ms
>> 4  10gigabitethernet4-3.core1.atl1.he.net  40.166 ms  33.887 ms  32.547 ms
>> 5  10gigabitethernet6-4.core1.ash1.he.net  49.821 ms  45.999 ms  52.751 ms
>> 6  2001:504:0:2::2641:1  47.197 ms  46.748 ms  47.289 ms
>> 7  xe-1-2-0.r1.bb-fo.chi2.vrsn.net  65.094 ms
>>   xe-0-2-0.r2.bb-fo.chi2.vrsn.net  66.441 ms
>>   xe-1-2-0.r1.bb-fo.chi2.vrsn.net  66.320 ms
>> 8  2001:503:3227:14ff::2  66.448 ms
>>   2001:503:3227:13ff::2  101.761 ms  86.864 ms
>> 9  2001:503:3227:13ff::2  69.818 ms !P
>>   2001:503:3227:14ff::2  69.311 ms !P
>>   2001:503:3227:13ff::2  68.662 ms !P
>> 
>> 
>> 
> 



From teun at teun.tv  Tue May  1 07:59:49 2012
From: teun at teun.tv (Teun Vink)
Date: Tue, 01 May 2012 14:59:49 +0200
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
Message-ID: <1335877189.9812.17.camel@moridin>

On Tue, 2012-05-01 at 08:01 -0400, TR Shaw wrote:
> Anyone else having problems getting to Verisign's whois server on IPv6?
> 

Testing it using the NLNOG ring (https://ring.nlnog.net) shows that 3
nodes have routing issues, 92 have no problems reaching Verisign's whois
server on IPv6. So there might be some routing issues.

Here's a (tad too crowded) graph showing the traceroutes from all ring
nodes: https://ring.nlnog.net/paste/p/pqux9kxpzhytnnmx

Regards,
Teun




From drc at virtualized.org  Tue May  1 08:18:50 2012
From: drc at virtualized.org (David Conrad)
Date: Tue, 1 May 2012 06:18:50 -0700
Subject: rpki vs. secure dns?
In-Reply-To: <F0DFCCC6-1604-426D-A31D-7AE7C11989F6@arbor.net>
References: <4F9B181D.30606@isc.org>
 <F0DFCCC6-1604-426D-A31D-7AE7C11989F6@arbor.net>
Message-ID: <06FB1A31-DA5F-4B57-8E4B-BE56FFB163CC@virtualized.org>

On May 1, 2012, at 4:34 AM, Dobbins, Roland wrote:
> On Apr 28, 2012, at 5:05 AM, Paul Vixie wrote:
>> is anybody taking it seriously?
> It's hard to take seriously any proposal which is predicated upon recursive dependencies.

Do you mean the need to be able to use rsync to fetch the data to enable you to use rsync?
Or the need to be able to use bittorrent to fetch the data to enable you to use bittorrent?
Or the need to be able to use the DNS to fetch the data to enable you to use the DNS?

Regards,
-drc



From richard.barnes at gmail.com  Tue May  1 09:25:35 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Tue, 1 May 2012 10:25:35 -0400
Subject: Operation Ghost Click
In-Reply-To: <CBC547DF.5C80F%jason_livingood@cable.comcast.com>
References: <4F99FE80.6010007@utc.edu>
 <CBC547DF.5C80F%jason_livingood@cable.comcast.com>
Message-ID: <CACB24MtAJFD3nXmsszaKf0L3PGdEfYNSqtQ8xPjymnbe_7RuDw@mail.gmail.com>

ISPs in the Netherlands have had a "botnet treaty" in effect since
2009, which calls for blocking, user notification, and inter-ISP
information sharing.
<http://ripe59.ripe.net/presentations/huijbregts-botnet-convenant.pdf>
<http://www.darkreading.com/blog/227700601/dutch-isps-sign-anti-botnet-treaty.html>

I don't have any data about how effective it's been, though.



On Tue, May 1, 2012 at 8:26 AM, Livingood, Jason
<Jason_Livingood at cable.comcast.com> wrote:
> On 4/26/12 10:03 PM, "Jeff Kell" <jeff-kell at utc.edu> wrote:
>
>>And what about the millions of users unknowingly infected with
>>"something else" ??
>>
>>(We have enough trouble isolating/remediating issues among our
>>relatively small user base, I'd hate to be facing a major ISP size
>>support/remediation effort...)
>>
>>Does anyone have a plan?
>
> Well, there's the new botnet code of conduct think (Mike O'Reirdan can
> chime in with more info here). Plus ISPs like the one I work at (Comcast)
> have been doing bot notification and remediation for some time now. I know
> other ISPs have different approaches, and so different bot programs, but
> the majority of them are doing something (with a few exceptions).
>
> Jason
>
>


From rsk at gsp.org  Tue May  1 09:40:57 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Tue, 1 May 2012 10:40:57 -0400
Subject: Operation Ghost Click
In-Reply-To: <CBC546BF.5C805%jason_livingood@cable.comcast.com>
References: <4F99C288.1030705@paulgraydon.co.uk>
 <CBC546BF.5C805%jason_livingood@cable.comcast.com>
Message-ID: <20120501144057.GA6771@gsp.org>

On Tue, May 01, 2012 at 12:26:20PM +0000, Livingood, Jason wrote:
> At Comcast we have done the following:
> - Sent emails
> - Send postal mail
> - Left voicemail
> - Used automated outbound calling
> - Used increasingly persistent web browser notifications

This is a reply to you, but it's intended to be directed at everyone
who runs a consumer network, since zombies are everywhere.

Why haven't you cut these obviously-infected systems off entirely?
They no longer belong to their putative owners in any meaningful sense:
oh, they might be in their homes, sitting on their desktops, but they're
owned, operationally, by parties unknown -- botmasters and anyone that
they're renting them out to.  The only use your customers are making of
them is that which they are *permitted* to do by the largesse of their
new owners, who of course find it convenient to maintain the illusion
because it encourages the former owners to keep them switched on and
plugged into your network.

(And given that your customer is not using their own system any more,
there's no reason to believe that its new owners will permit them to see
any email you send or any web browser notifications you emit.  I'm sure if
these become prevalent, not just at Comcast but among other major ISPs,
the botmasters will pay someone to do the coding necessary to suppress
them, and then propagate that code to all their bots.)

This isn't to say that what you're doing isn't well-intentioned: it is.
And it's a lot more than many others are doing.  But if it was going to
work, it would have worked by now.

---rsk


From morrowc.lists at gmail.com  Tue May  1 09:55:17 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 1 May 2012 10:55:17 -0400
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <1335877189.9812.17.camel@moridin>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
 <1335877189.9812.17.camel@moridin>
Message-ID: <CAL9jLabQg6DqfOiK-pkvo_x_iCATazJgA_3ziwaM5mn01y08cA@mail.gmail.com>

On Tue, May 1, 2012 at 8:59 AM, Teun Vink <teun at teun.tv> wrote:
> On Tue, 2012-05-01 at 08:01 -0400, TR Shaw wrote:
>> Anyone else having problems getting to Verisign's whois server on IPv6?
>>
>
> Testing it using the NLNOG ring (https://ring.nlnog.net) shows that 3
> nodes have routing issues, 92 have no problems reaching Verisign's whois
> server on IPv6. So there might be some routing issues.
>
> Here's a (tad too crowded) graph showing the traceroutes from all ring
> nodes: https://ring.nlnog.net/paste/p/pqux9kxpzhytnnmx

mtu problems perhaps? (I get a connect, but nothing after the initial banner ...

-chris


From jtk at cymru.com  Tue May  1 10:31:11 2012
From: jtk at cymru.com (John Kristoff)
Date: Tue, 1 May 2012 10:31:11 -0500
Subject: rpki vs. secure dns?
In-Reply-To: <m27gwx5ikh.wl%randy@psg.com>
References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de>
 <F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net>
 <DB5B6839-CB35-4227-B909-88BB84B54770@tcb.net>
 <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru>
 <m27gwx5ikh.wl%randy@psg.com>
Message-ID: <20120501103111.6a4b243c@localhost>

On Mon, 30 Apr 2012 11:46:06 -0400
Randy Bush <randy at psg.com> wrote:

> > We need more flexible, distributed architecture behind - no matter -
> > which interests will be lobbied as we have got already.
> 
> as i agree that there is a problem, i *very* eagerly await your
> proposal

As Radia says in her book, we're probably stuck with BGP forever, but I
frequently wonder if she is right in suggesting we could have done
better by having a link state protocol instead.  It trades some set of
problems for another, but I don't find the dread this might instill
reason enough to avoid putting some research effort into it.

John


From rdobbins at arbor.net  Tue May  1 10:49:14 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 1 May 2012 15:49:14 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <06FB1A31-DA5F-4B57-8E4B-BE56FFB163CC@virtualized.org>
References: <4F9B181D.30606@isc.org>
 <F0DFCCC6-1604-426D-A31D-7AE7C11989F6@arbor.net>
 <06FB1A31-DA5F-4B57-8E4B-BE56FFB163CC@virtualized.org>
Message-ID: <732FE83D-E76C-4FB1-B89D-1ECB17934E64@arbor.net>


On May 1, 2012, at 8:18 PM, David Conrad wrote:

> Do you mean the need to be able to use rsync to fetch the data to enable you to use rsync?

A lot more than just rsync is necessary in order to allow rsync transactions to work.  But, you know this already.

;>

> Or the need to be able to use bittorrent to fetch the data to enable you to use bittorrent?

A lot more than just BitTorrent is necessary in order to allow BitTorrent transactions to work.  But, you know this already.

;>

> Or the need to be able to use the DNS to fetch the data to enable you to use the DNS?

A lot more than just DNS is necessary in order to allow DNS transactions to work - in this context, I'm specifically referring to routing.

But, you know this already, too.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From rdobbins at arbor.net  Tue May  1 10:51:15 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 1 May 2012 15:51:15 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <20120501103111.6a4b243c@localhost>
References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de>
 <F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net>
 <DB5B6839-CB35-4227-B909-88BB84B54770@tcb.net>
 <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru>
 <m27gwx5ikh.wl%randy@psg.com> <20120501103111.6a4b243c@localhost>
Message-ID: <CDAE2A78-6694-4B8C-83AD-714E4A4E69C2@arbor.net>


On May 1, 2012, at 10:31 PM, John Kristoff wrote:

> As Radia says in her book, we're probably stuck with BGP forever, but I frequently wonder if she is right in suggesting we could have done
> better by having a link state protocol instead.

At the time, link-state protocols weren't practical for the scale required - even today, it would be problematic.

Ideally, this would be very nice, but I just don't think it's practical, even today.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From khomyakov.andrey at gmail.com  Tue May  1 11:00:38 2012
From: khomyakov.andrey at gmail.com (Andrey Khomyakov)
Date: Tue, 1 May 2012 12:00:38 -0400
Subject: Comcast DNS admin?
Message-ID: <CAB31LONRTCJZ69KPLrgv7HfdotkJwOVw+i+tMGLjQ+cwzUK_xQ@mail.gmail.com>

Is there Comcast DNS person. Please, contact off list

--Andrey

From drc at virtualized.org  Tue May  1 11:10:41 2012
From: drc at virtualized.org (David Conrad)
Date: Tue, 1 May 2012 09:10:41 -0700
Subject: rpki vs. secure dns?
In-Reply-To: <732FE83D-E76C-4FB1-B89D-1ECB17934E64@arbor.net>
References: <4F9B181D.30606@isc.org>
 <F0DFCCC6-1604-426D-A31D-7AE7C11989F6@arbor.net>
 <06FB1A31-DA5F-4B57-8E4B-BE56FFB163CC@virtualized.org>
 <732FE83D-E76C-4FB1-B89D-1ECB17934E64@arbor.net>
Message-ID: <B6C0B633-DFC4-4185-A855-C9CD982A462C@virtualized.org>

Roland,

On May 1, 2012, at 8:49 AM, Dobbins, Roland wrote:
> On May 1, 2012, at 8:18 PM, David Conrad wrote:
>>> It's hard to take seriously any proposal which is predicated upon recursive dependencies.
>> Do you mean the need to be able to use [X] to fetch the data to enable you to use [X]?
> A lot more than just [X] is necessary in order to allow [X] transactions to work.
> ... - in this context, I'm specifically referring to routing.

So, you're saying that the entire RPKI+BGPSEC effort is hard for you to take seriously. OK.

Regards,
-drc



From lathama at gmail.com  Tue May  1 11:17:17 2012
From: lathama at gmail.com (Andrew Latham)
Date: Tue, 1 May 2012 12:17:17 -0400
Subject: Operation Ghost Click
In-Reply-To: <20120501144057.GA6771@gsp.org>
References: <4F99C288.1030705@paulgraydon.co.uk>
 <CBC546BF.5C805%jason_livingood@cable.comcast.com>
 <20120501144057.GA6771@gsp.org>
Message-ID: <CA+qj4S842gN04+iWEvGmS4Nq2VYc7qmfknqYmqfmumUAHZX0tA@mail.gmail.com>

A write up here
http://dyn.com/dns-internet-web-truth-behind-the-fbi-computer-scare/

-- 
~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~


From db at rrbone.net  Tue May  1 11:39:34 2012
From: db at rrbone.net (Dominik Bay)
Date: Tue, 1 May 2012 16:39:34 +0000
Subject: CDNs should pay eyeball networks, too.
Message-ID: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>

Yesterday I received the following mail, from a CDN:

---->8----
Greetings,

Limelight Networks periodically reviews its interconnection strategy to ensure the quality and integrity of its interconnection between all its partners. We have recently updated our requirements for settlement-free peering which are posted at http://www.as22822.net/

This letter is to notify you that yyy no longer meets our minimum requirements. If yyy would like to maintain our current interconnectivity, there will be settlement associated with doing so. If you are interested in pursuing this option, please reply back to this email indicating such.

Should your company decline this option, or if we do not have an agreement regarding the settlement in place prior to May 31st 2012, Limelight Networks will terminate the peering sessions on that day, with this letter serving as 30 day notice.


Sincerely,
----8<----

The same mail was sent out last year, about end of April 2011, to another ISP I'm working with.
They got depeered, but the ISP which received the mail above yesterday didn't meet the requirements last year either.
I totally understand that some companies might not be able to handle sub-5Mbps peering sessions, be it technical or organisational, but >=100Mbps should be worth any effort, as long as it improves the network.

In this particular case I'm talking about >=600Mbps of traffic send out by Limelight to "my" eyeballs, not mentioning their fairly small footprint in Germany in comparison to other CDNs.

These points aside, we are talking about a Content *Delivery* Network here. There are CDNs out there who burn to improve their customer experience (both the content creators and the content receiver) at high cost.
Having a Tier1 attitude and telling eyeball networks with <1Gbps of traffic exchanged to bugger off or pay is not one of the ways to improve this.

At the end of the day I'm going to charge CDNs who want to deliver their customers content to my eyeballs and make me pay (about 2USD per Mbps, with a minimum of 1Gbps).

-dominik


From gourmetcisco at hotmail.com  Tue May  1 11:41:19 2012
From: gourmetcisco at hotmail.com (Hank Disuko)
Date: Tue, 1 May 2012 12:41:19 -0400
Subject: Network diagram app that shows realtime link utilizatin
Message-ID: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>



Hi folks, 

I wonder if anyone can recommend a network diagram tool that can show realtime link utilization via snmp?

Mikrotik's "The Dude" app actually does exactly what I'm looking for, but the snmp support for non-RouterOS devices seems to be lacking, as it simply won't enumerate my switch interfaces in order to capture utilization.

I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds LANsurveyor etc.) but they don't serve this very basic need of mine to see the realtime link util in the diagram.

Thanks,
Hank Disuko
 		 	   		  

From tate at baumrucker.org  Tue May  1 11:46:21 2012
From: tate at baumrucker.org (tate)
Date: Tue, 01 May 2012 12:46:21 -0400
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
Message-ID: <9b9e6bccbef2f4cfbf2c9cac517b1694@baumrucker.org>

InfoVista Vista360 does it.
It's part of a bigger tool set and isn't cheap, but it's pretty cool.
Tate

On Tue, 1 May 2012 12:41:19 -0400, Hank Disuko wrote:
> Hi folks,
>
> I wonder if anyone can recommend a network diagram tool that can show
> realtime link utilization via snmp?
>
> Mikrotik's "The Dude" app actually does exactly what I'm looking for,
> but the snmp support for non-RouterOS devices seems to be lacking, as
> it simply won't enumerate my switch interfaces in order to capture
> utilization.
>
> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds
> LANsurveyor etc.) but they don't serve this very basic need of mine 
> to
> see the realtime link util in the diagram.
>
> Thanks,
> Hank Disuko


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From khomyakov.andrey at gmail.com  Tue May  1 11:47:13 2012
From: khomyakov.andrey at gmail.com (Andrey Khomyakov)
Date: Tue, 1 May 2012 12:47:13 -0400
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
Message-ID: <CAB31LON9Bv5t4qJfQFnpHhpp==GZeiTzEApZQAz8TEfFN33Rvw@mail.gmail.com>

cacti by use of weather maps?
Alternatively, Intermapper is pretty good, but commercial. It's more of an
NMS than a diagram tool though. Everywhere I used it, I was pretty happy
with it.

--Andrey


On Tue, May 1, 2012 at 12:41 PM, Hank Disuko <gourmetcisco at hotmail.com>wrote:

>
>
> Hi folks,
>
> I wonder if anyone can recommend a network diagram tool that can show
> realtime link utilization via snmp?
>
> Mikrotik's "The Dude" app actually does exactly what I'm looking for, but
> the snmp support for non-RouterOS devices seems to be lacking, as it simply
> won't enumerate my switch interfaces in order to capture utilization.
>
> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds
> LANsurveyor etc.) but they don't serve this very basic need of mine to see
> the realtime link util in the diagram.
>
> Thanks,
> Hank Disuko
>
>

From rene.skjoldmose at gmail.com  Tue May  1 11:51:30 2012
From: rene.skjoldmose at gmail.com (Rene Skjoldmose)
Date: Tue, 01 May 2012 18:51:30 +0200
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
Message-ID: <4FA01492.4090800@gmail.com>

On 2012-05-01 18:41, Hank Disuko wrote:
> I wonder if anyone can recommend a network diagram tool that can show realtime link utilization via snmp?
Were i work we do it with perl, rrdtool and graphviz - it's fairly 
simple to put together, and that way, you get exactly what you need.

Cheers,
Ren?


From thegameiam at yahoo.com  Tue May  1 11:53:13 2012
From: thegameiam at yahoo.com (David Barak)
Date: Tue, 1 May 2012 12:53:13 -0400
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <CAB31LON9Bv5t4qJfQFnpHhpp==GZeiTzEApZQAz8TEfFN33Rvw@mail.gmail.com>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
 <CAB31LON9Bv5t4qJfQFnpHhpp==GZeiTzEApZQAz8TEfFN33Rvw@mail.gmail.com>
Message-ID: <BA605483-1B09-401A-BED4-CDA67AF12C1F@yahoo.com>

Netbrain OE does this.


David Barak
Sent from a mobile device, please forgive autocorrection.

On May 1, 2012, at 12:47 PM, Andrey Khomyakov <khomyakov.andrey at gmail.com> wrote:

> cacti by use of weather maps?
> Alternatively, Intermapper is pretty good, but commercial. It's more of an
> NMS than a diagram tool though. Everywhere I used it, I was pretty happy
> with it.
> 
> --Andrey
> 
> 
> On Tue, May 1, 2012 at 12:41 PM, Hank Disuko <gourmetcisco at hotmail.com>wrote:
> 
>> 
>> 
>> Hi folks,
>> 
>> I wonder if anyone can recommend a network diagram tool that can show
>> realtime link utilization via snmp?
>> 
>> Mikrotik's "The Dude" app actually does exactly what I'm looking for, but
>> the snmp support for non-RouterOS devices seems to be lacking, as it simply
>> won't enumerate my switch interfaces in order to capture utilization.
>> 
>> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds
>> LANsurveyor etc.) but they don't serve this very basic need of mine to see
>> the realtime link util in the diagram.
>> 
>> Thanks,
>> Hank Disuko
>> 
>> 


From streiner at cluebyfour.org  Tue May  1 11:57:27 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 1 May 2012 12:57:27 -0400 (EDT)
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA01492.4090800@gmail.com>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
 <4FA01492.4090800@gmail.com>
Message-ID: <Pine.LNX.4.64.1205011254090.7884@whammy.cluebyfour.org>

On Tue, 1 May 2012, Rene Skjoldmose wrote:

> On 2012-05-01 18:41, Hank Disuko wrote:
>>  I wonder if anyone can recommend a network diagram tool that can show
>>  realtime link utilization via snmp?
> Were i work we do it with perl, rrdtool and graphviz - it's fairly simple to 
> put together, and that way, you get exactly what you need.

It's also worth mentioning that most of the tools listed in response to 
the original message show data in near-real-time, such as 1 or 5-minute 
averages.  'real-time' in this case starts to lead down a slippery slope 
of terminology gaps ;)

jms


From snoble at sonn.com  Tue May  1 12:07:31 2012
From: snoble at sonn.com (Steven Noble)
Date: Tue, 1 May 2012 10:07:31 -0700
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
Message-ID: <889B922C-B705-42C5-A332-95B45B89E14F@sonn.com>


On May 1, 2012, at 9:39 AM, Dominik Bay wrote:

> Yesterday I received the following mail, from a CDN:
> 
**snip**
> Should your company decline this option, or if we do not have an agreement regarding the settlement in place prior to May 31st 2012, Limelight Networks will terminate the peering sessions on that day, with this letter serving as 30 day notice.
> 
> 
> Sincerely,


While I can understand having some peering requirements, the goal of any CDN should be to have the best reach possible.  Without knowing if this is PI peering or just across a IX it is hard to judge what their (or your) costs are.  If it is IX it would seem irrational to cut off someone who you are doing meaningful traffic with.

> ----8<----
> In this particular case I'm talking about >=600Mbps of traffic send out by Limelight to "my" eyeballs, not mentioning their fairly small footprint in Germany in comparison to other CDNs.
> 

600Mbps would appear to be meaningful traffic.  Without the other side of the story it's hard to get a full grip on the situation.  It is always possible that these are business (not network) decisions where there is a certain level of income expected from a division.

> These points aside, we are talking about a Content *Delivery* Network here. There are CDNs out there who burn to improve their customer experience (both the content creators and the content receiver) at high cost.
> Having a Tier1 attitude and telling eyeball networks with <1Gbps of traffic exchanged to bugger off or pay is not one of the ways to improve this.

I do agree here, again on an IX level.   They still have the choice to backhaul to you or hot potato your traffic wherever they feel like it.  From the data you have provide it appears to be a lose-lose situation to de-peer you.

> 
> At the end of the day I'm going to charge CDNs who want to deliver their customers content to my eyeballs and make me pay (about 2USD per Mbps, with a minimum of 1Gbps).
> 

That may be what they are doing "if at all possible try to monetize it".



From db at rrbone.net  Tue May  1 12:11:14 2012
From: db at rrbone.net (Dominik Bay)
Date: Tue, 1 May 2012 19:11:14 +0200
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <889B922C-B705-42C5-A332-95B45B89E14F@sonn.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <889B922C-B705-42C5-A332-95B45B89E14F@sonn.com>
Message-ID: <4FA01932.3080203@rrbone.net>

On 05/01/2012 07:07 PM, Steven Noble wrote:
> While I can understand having some peering requirements, the goal of any CDN should be to have the best reach possible.  Without knowing if this is PI peering or just across a IX it is hard to judge what their (or your) costs are.  If it is IX it would seem irrational to cut off someone who you are doing meaningful traffic with.

This is over an IXP, I should've pointed that out.

>> ----8<----
>> In this particular case I'm talking about >=600Mbps of traffic send out by Limelight to "my" eyeballs, not mentioning their fairly small footprint in Germany in comparison to other CDNs.
>>
> 
> 600Mbps would appear to be meaningful traffic.  Without the other side of the story it's hard to get a full grip on the situation.  It is always possible that these are business (not network) decisions where there is a certain level of income expected from a division.
> 
>> These points aside, we are talking about a Content *Delivery* Network here. There are CDNs out there who burn to improve their customer experience (both the content creators and the content receiver) at high cost.
>> Having a Tier1 attitude and telling eyeball networks with <1Gbps of traffic exchanged to bugger off or pay is not one of the ways to improve this.
> 
> I do agree here, again on an IX level.   They still have the choice to backhaul to you or hot potato your traffic wherever they feel like it.  From the data you have provide it appears to be a lose-lose situation to de-peer you.
> 
>>
>> At the end of the day I'm going to charge CDNs who want to deliver their customers content to my eyeballs and make me pay (about 2USD per Mbps, with a minimum of 1Gbps).
>>
> 
> That may be what they are doing "if at all possible try to monetize it".

Agreed on all points. There's at least nothing technical which needs
solving.



From shortdudey123 at gmail.com  Tue May  1 12:20:28 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Tue, 1 May 2012 12:20:28 -0500
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <Pine.LNX.4.64.1205011254090.7884@whammy.cluebyfour.org>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
 <4FA01492.4090800@gmail.com>
 <Pine.LNX.4.64.1205011254090.7884@whammy.cluebyfour.org>
Message-ID: <CAPiURgXU=gtBq0tALVOf+dBz1DYgQw=_wCEXjd0FVyfikkq+uw@mail.gmail.com>

I have discovered ITGuru works pretty good.

http://itnetworkguru.com/

-Grant

On Tue, May 1, 2012 at 11:57 AM, Justin M. Streiner <streiner at cluebyfour.org
> wrote:

> On Tue, 1 May 2012, Rene Skjoldmose wrote:
>
>  On 2012-05-01 18:41, Hank Disuko wrote:
>>
>>>  I wonder if anyone can recommend a network diagram tool that can show
>>>  realtime link utilization via snmp?
>>>
>> Were i work we do it with perl, rrdtool and graphviz - it's fairly simple
>> to put together, and that way, you get exactly what you need.
>>
>
> It's also worth mentioning that most of the tools listed in response to
> the original message show data in near-real-time, such as 1 or 5-minute
> averages.  'real-time' in this case starts to lead down a slippery slope of
> terminology gaps ;)
>
> jms
>
>

From bill at herrin.us  Tue May  1 12:26:07 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 1 May 2012 13:26:07 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
Message-ID: <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>

On 5/1/12, Dominik Bay <db at rrbone.net> wrote:
> Yesterday I received the following mail, from a CDN:
>
> ---->8----
> Greetings,
>
> Limelight Networks [has] recently updated our requirements for
> settlement-free peering
>
> This letter is to notify you that yyy no longer meets our minimum
> requirements.

Proposed solution:

Greetings,

Where settlement-free peering has been offered but rejected, YYY moves
all data traffic transiting that AS through a single minimum-cost
Internet connection (cough Cogent cough) with the attendant impact to
reliability. We appreciate the notice of depeering and will endeavor
to identify and advise those making paid use of our respective
services as to the impending impact to their activities.


On the technical side you can only easily enforce that for outbound
traffic. Essentially filter the routes containing their AS except from
your minimum cost link. Intentionally degraded service can be better
than flat refusal. Communication is two-way so even though the CDN
sends more than it receives this is still a credible threat. Your
customer sees perfectly good connectivity everywhere else and it isn't
a complete disconnect so your customer assumes its "their" Internet
connection rather than his.


> I totally understand that some companies might not be able to handle
> sub-5Mbps peering sessions, be it technical or organisational, but >=100Mbps
> should be worth any effort, as long as it improves the network.

If I'm willing to go to your location, buy the card for your router
and pay you for the staff hours to set it up, there should be *no*
situation in which I'm willing to accept your traffic from an upstream
Internet link but am unwilling to engage in otherwise settlement-free
peering with you.

Your customers have paid you to connect to me and my customers have
paid me to connect to you. Double-billing the activity by either of us
collecting money from the other is just plain wrong.

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 apishdadi at gmail.com  Tue May  1 12:36:21 2012
From: apishdadi at gmail.com (Ameen Pishdadi)
Date: Tue, 1 May 2012 12:36:21 -0500
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
Message-ID: <BE1473AB-B63D-433A-8025-8E96E6286EE6@gmail.com>

Right on

Thanks,
Ameen Pishdadi


On May 1, 2012, at 11:39 AM, Dominik Bay <db at rrbone.net> wrote:

> Yesterday I received the following mail, from a CDN:
> 
> ---->8----
> Greetings,
> 
> Limelight Networks periodically reviews its interconnection strategy to ensure the quality and integrity of its interconnection between all its partners. We have recently updated our requirements for settlement-free peering which are posted at http://www.as22822.net/
> 
> This letter is to notify you that yyy no longer meets our minimum requirements. If yyy would like to maintain our current interconnectivity, there will be settlement associated with doing so. If you are interested in pursuing this option, please reply back to this email indicating such.
> 
> Should your company decline this option, or if we do not have an agreement regarding the settlement in place prior to May 31st 2012, Limelight Networks will terminate the peering sessions on that day, with this letter serving as 30 day notice.
> 
> 
> Sincerely,
> ----8<----
> 
> The same mail was sent out last year, about end of April 2011, to another ISP I'm working with.
> They got depeered, but the ISP which received the mail above yesterday didn't meet the requirements last year either.
> I totally understand that some companies might not be able to handle sub-5Mbps peering sessions, be it technical or organisational, but >=100Mbps should be worth any effort, as long as it improves the network.
> 
> In this particular case I'm talking about >=600Mbps of traffic send out by Limelight to "my" eyeballs, not mentioning their fairly small footprint in Germany in comparison to other CDNs.
> 
> These points aside, we are talking about a Content *Delivery* Network here. There are CDNs out there who burn to improve their customer experience (both the content creators and the content receiver) at high cost.
> Having a Tier1 attitude and telling eyeball networks with <1Gbps of traffic exchanged to bugger off or pay is not one of the ways to improve this.
> 
> At the end of the day I'm going to charge CDNs who want to deliver their customers content to my eyeballs and make me pay (about 2USD per Mbps, with a minimum of 1Gbps).
> 
> -dominik
> 


From galu at packetdam.com  Tue May  1 12:44:19 2012
From: galu at packetdam.com (Vlad Galu)
Date: Tue, 1 May 2012 18:44:19 +0100
Subject: VPN over satellite
In-Reply-To: <000e01cd26b5$8e132d90$aa3988b0$@be>
References: <000e01cd26b5$8e132d90$aa3988b0$@be>
Message-ID: <FA53BF952205481B9DAD65FA6A67FF62@packetdam.com>

Hi Rens, 

I work with one of the leading satellite providers. Depending on the customer type, we deploy a number of solutions (some work better for some, some work better for others).  Most off-the-shelf solutions are more or less designed in a client/server manner (the optimizations they employ are usually asymmetrical, as most clients either just push or just pull data).

It sounds like you need an end to end solution that is not optimizing a particular type of data. Riverbed could be one, but I haven't really tested it in a setup resembling yours. Some of our customers use it, but they mostly pull data so I can't really tell if it works for you. You could contact me off-list to let me know who your satellite provider is. If it's the company I work with, perhaps we can bounce some ideas around.

Cheers
Vlad

-- 
PacketDam: a cost-effective
software solution against DDoS


On Monday, April 30, 2012 at 10:42 AM, Rens wrote:

> Dear,
> 
> 
> Could anybody recommend any hardware that can build a VPN that works well
> over satellite connections? (TCP enhancements)
> 
> I want to setup a L3 VPN between 2 satellite connections
> 
> 
> Even additionally if that hardware would also support WAN bonding even
> better because I also have a scenario to connect 2 times 2 satellites to
> have more capacity for my L3 VPN
> 
> 
> Regards,
> 
> 
> Rens 




From russw at riw.us  Tue May  1 12:46:08 2012
From: russw at riw.us (Russ White)
Date: Tue, 01 May 2012 13:46:08 -0400
Subject: rpki vs. secure dns?
In-Reply-To: <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
Message-ID: <4FA02160.1060504@riw.us>


> Yes, recursive dependencies are an issue.  I'm really surprised that folks are even seriously considering something like this, but OTOH, this sort of thing keeps cropping up in various contexts from time to time, sigh.

There are only a couple of ways to get past recursive dependencies.

You could simply carry everything in one protocol. This really isn't
practical.

You could develop an overlay protocol that carries the additional
information, so that internal routing is all that's needed to get to the
information you need to build external routing. We already have this, to
some degree today, with IGP/BGP.

You could design a system where most service providers who are likely to
be an upstream would be able to hold the information to kick start a
peer or customer's external routing, so the peer or customer only needs
a default to the upstream to get what they need.

#2 is the most desirable overall, but #3 is what we're most likely to
wind up with in the real world, for various reasons. And I don't know
that #3 is a bad result. There are situations where it won't work
(mostly thinking high mobility environments, or complete system
failures), but these don't seem to be big "stoppers," to me....

But again, here is something that should be brought into the
requirements process in the IETF and discussed as fully as possible, and
then that discussion recorded in a requirements document. AFAIK, it's
never really been discussed seriously, with all the options, advantages,
and disadvantages, enumerated and considered.

Russ

-- 
<><
riwhite at verisign.com
russw at riw.us


From gourmetcisco at hotmail.com  Tue May  1 12:49:33 2012
From: gourmetcisco at hotmail.com (Hank Disuko)
Date: Tue, 1 May 2012 13:49:33 -0400
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA01BDB.1020408@nwwnet.net>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>,
 <4FA01BDB.1020408@nwwnet.net>
Message-ID: <BLU156-W503D2619413924DB6F3F8C9290@phx.gbl>


Thanks, I'll see if I can pull the correct OID and try it with the Dude again.

Also, thanks to everyone who has responded.? I realize the term "realtime" is subjective - I'm looking for near-realtime...maybe a 30 second interval.

I've been playing around with Intermapper for about 30 minutes now...i like this tool, but would like to see bitrates represented on the map as opposed to the "crawling ants".? clicking around to see if kind of view is available...

thanks again folks.? Good example, in my case anyway, of NANOG outperforming Google (or at least my crappy attempts at google search terms).

-Hank

----------------------------------------
> Date: Tue, 1 May 2012 13:22:35 -0400
> From: sreed at nwwnet.net
> To: gourmetcisco at hotmail.com
> Subject: Re: Network diagram app that shows realtime link utilizatin
>
> I monitor non-MT devices with the Dude.
> As long as you know the OID, it works just fine.
>
> On 5/1/2012 12:41 PM, Hank Disuko wrote:
> >
> > Hi folks,
> >
> > I wonder if anyone can recommend a network diagram tool that can show realtime link utilization via snmp?
> >
> > Mikrotik's "The Dude" app actually does exactly what I'm looking for, but the snmp support for non-RouterOS devices seems to be lacking, as it simply won't enumerate my switch interfaces in order to capture utilization.
> >
> > I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds LANsurveyor etc.) but they don't serve this very basic need of mine to see the realtime link util in the diagram.
> >
> > Thanks,
> > Hank Disuko
> >
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2012.0.1913 / Virus Database: 2411/4971 - Release Date: 05/01/12
> >
> >
> >
>
> --
> Scott Reed
> Owner
> NewWays Networking, LLC
> Wireless Networking
> Network Design, Installation and Administration
>
>
>
> Mikrotik Advanced Certified
>
> www.nwwnet.net
> (765) 855-1060
> (765) 439-4253
> (855) 231-6239
>
>
 		 	   		  

From joelja at bogus.com  Tue May  1 13:02:14 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Tue, 01 May 2012 11:02:14 -0700
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <BLU156-W503D2619413924DB6F3F8C9290@phx.gbl>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>,
 <4FA01BDB.1020408@nwwnet.net>
 <BLU156-W503D2619413924DB6F3F8C9290@phx.gbl>
Message-ID: <4FA02526.5070201@bogus.com>

we use cacti weathermap plugin, though obviously realtime has a
dependency on your sample interval. I'm presuming your definition
thereof isn't instantaneous monitoring of queue depth.


On 5/1/12 10:49 , Hank Disuko wrote:
> 
> Thanks, I'll see if I can pull the correct OID and try it with the Dude again.
> 
> Also, thanks to everyone who has responded.  I realize the term "realtime" is subjective - I'm looking for near-realtime...maybe a 30 second interval.
> 
> I've been playing around with Intermapper for about 30 minutes now...i like this tool, but would like to see bitrates represented on the map as opposed to the "crawling ants".  clicking around to see if kind of view is available...
> 
> thanks again folks.  Good example, in my case anyway, of NANOG outperforming Google (or at least my crappy attempts at google search terms).
> 
> -Hank
> 
> ----------------------------------------
>> Date: Tue, 1 May 2012 13:22:35 -0400
>> From: sreed at nwwnet.net
>> To: gourmetcisco at hotmail.com
>> Subject: Re: Network diagram app that shows realtime link utilizatin
>>
>> I monitor non-MT devices with the Dude.
>> As long as you know the OID, it works just fine.
>>
>> On 5/1/2012 12:41 PM, Hank Disuko wrote:
>>>
>>> Hi folks,
>>>
>>> I wonder if anyone can recommend a network diagram tool that can show realtime link utilization via snmp?
>>>
>>> Mikrotik's "The Dude" app actually does exactly what I'm looking for, but the snmp support for non-RouterOS devices seems to be lacking, as it simply won't enumerate my switch interfaces in order to capture utilization.
>>>
>>> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds LANsurveyor etc.) but they don't serve this very basic need of mine to see the realtime link util in the diagram.
>>>
>>> Thanks,
>>> Hank Disuko
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1913 / Virus Database: 2411/4971 - Release Date: 05/01/12
>>>
>>>
>>>
>>
>> --
>> Scott Reed
>> Owner
>> NewWays Networking, LLC
>> Wireless Networking
>> Network Design, Installation and Administration
>>
>>
>>
>> Mikrotik Advanced Certified
>>
>> www.nwwnet.net
>> (765) 855-1060
>> (765) 439-4253
>> (855) 231-6239
>>
>>
>  		 	   		  
> 



From patrick at ianai.net  Tue May  1 13:08:24 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 1 May 2012 14:08:24 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
Message-ID: <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>

On May 1, 2012, at 13:26 , William Herrin wrote:
> On 5/1/12, Dominik Bay <db at rrbone.net> wrote:
>> Yesterday I received the following mail, from a CDN:
>> 
>> ---->8----
>> Greetings,
>> 
>> Limelight Networks [has] recently updated our requirements for
>> settlement-free peering

I love the fact Dominik says "from a CDN", then leaves Limelight's name in the text. :)


> If I'm willing to go to your location, buy the card for your router
> and pay you for the staff hours to set it up, there should be *no*
> situation in which I'm willing to accept your traffic from an upstream
> Internet link but am unwilling to engage in otherwise settlement-free
> peering with you.

I disagree with this.  In fact, I can think of several possible cases where this would not hold, both using pure business and pure technical justifications.

Generalizations are difficult in complex situations, and this is most definitely a complex situation.


> Your customers have paid you to connect to me and my customers have
> paid me to connect to you. Double-billing the activity by either of us
> collecting money from the other is just plain wrong.

Wrong?  My rule is: Your network, your decision.  (Anyone who is paying attention knows my decision, but I it would be quite silly to assume my decision is right for all networks in all situations.)  Asking for settlements is not illegal, or even immoral.  Moreover, this is an operational list.  "Right" and "wrong" are not really part of the discussion.

But even if they were, this is not not "just plain wrong".  "It's just business" is a much better way to say it, and in business, trying to make more money is the _point_, not wrong.  Whether this is a good way to make money is left as an exercise to the reader.

Instead, let's focus on the operational impact.  Will the reduced complexity on these networks result in improved performance?  Irrelevant to performance?  Decreased performance?  Maybe even whether that change in performance is an acceptable trade for the lower CapEx/OpEx?  This is relevant since business requirements are the foundation for operational discussions.  Can't buy more 10G ports if the business doesn't support it.

Etc., etc.

But right vs. wrong in a peering dispute?  I think not.

-- 
TTFN,
patrick



From uwcableguy at gmail.com  Tue May  1 13:22:15 2012
From: uwcableguy at gmail.com (Ben Bartsch)
Date: Tue, 1 May 2012 13:22:15 -0500
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA02526.5070201@bogus.com>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
 <4FA01BDB.1020408@nwwnet.net>
 <BLU156-W503D2619413924DB6F3F8C9290@phx.gbl>
 <4FA02526.5070201@bogus.com>
Message-ID: <CAOvEG7PbKvOcnRkGzO_KU9-N2wSycSBDAviu74TJ-8URtNZ=rQ@mail.gmail.com>

on intermapper, simply right click the link, select 'status window' and you
will get all kinds of nice info.  be sure to use the bandwidth command on
the interface if you are not using the default 10/100/1000/10gig.  also,
the links turn yellow and orange as the line becomes more saturated (and
the 'ants' get bigger/smaller as utilization goes up and down).

only thing i don't like about intermapper is that vlans and physical
interfaces are separate from each other.  and their tech support blows.

ben

On Tue, May 1, 2012 at 1:02 PM, Joel jaeggli <joelja at bogus.com> wrote:

> we use cacti weathermap plugin, though obviously realtime has a
> dependency on your sample interval. I'm presuming your definition
> thereof isn't instantaneous monitoring of queue depth.
>
>
> On 5/1/12 10:49 , Hank Disuko wrote:
> >
> > Thanks, I'll see if I can pull the correct OID and try it with the Dude
> again.
> >
> > Also, thanks to everyone who has responded.  I realize the term
> "realtime" is subjective - I'm looking for near-realtime...maybe a 30
> second interval.
> >
> > I've been playing around with Intermapper for about 30 minutes now...i
> like this tool, but would like to see bitrates represented on the map as
> opposed to the "crawling ants".  clicking around to see if kind of view is
> available...
> >
> > thanks again folks.  Good example, in my case anyway, of NANOG
> outperforming Google (or at least my crappy attempts at google search
> terms).
> >
> > -Hank
> >
> > ----------------------------------------
> >> Date: Tue, 1 May 2012 13:22:35 -0400
> >> From: sreed at nwwnet.net
> >> To: gourmetcisco at hotmail.com
> >> Subject: Re: Network diagram app that shows realtime link utilizatin
> >>
> >> I monitor non-MT devices with the Dude.
> >> As long as you know the OID, it works just fine.
> >>
> >> On 5/1/2012 12:41 PM, Hank Disuko wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I wonder if anyone can recommend a network diagram tool that can show
> realtime link utilization via snmp?
> >>>
> >>> Mikrotik's "The Dude" app actually does exactly what I'm looking for,
> but the snmp support for non-RouterOS devices seems to be lacking, as it
> simply won't enumerate my switch interfaces in order to capture utilization.
> >>>
> >>> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds
> LANsurveyor etc.) but they don't serve this very basic need of mine to see
> the realtime link util in the diagram.
> >>>
> >>> Thanks,
> >>> Hank Disuko
> >>>
> >>>
> >>>
> >>> -----
> >>> No virus found in this message.
> >>> Checked by AVG - www.avg.com
> >>> Version: 2012.0.1913 / Virus Database: 2411/4971 - Release Date:
> 05/01/12
> >>>
> >>>
> >>>
> >>
> >> --
> >> Scott Reed
> >> Owner
> >> NewWays Networking, LLC
> >> Wireless Networking
> >> Network Design, Installation and Administration
> >>
> >>
> >>
> >> Mikrotik Advanced Certified
> >>
> >> www.nwwnet.net
> >> (765) 855-1060
> >> (765) 439-4253
> >> (855) 231-6239
> >>
> >>
> >
> >
>
>
>

From db at rrbone.net  Tue May  1 13:23:07 2012
From: db at rrbone.net (Dominik Bay)
Date: Tue, 1 May 2012 20:23:07 +0200
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
Message-ID: <4FA02A0B.7050505@rrbone.net>

On 05/01/2012 08:08 PM, Patrick W. Gilmore wrote:
> Instead, let's focus on the operational impact.  Will the reduced complexity on these networks result in improved performance?  Irrelevant to performance?  Decreased performance?  Maybe even whether that change in performance is an acceptable trade for the lower CapEx/OpEx?  This is relevant since business requirements are the foundation for operational discussions.  Can't buy more 10G ports if the business doesn't support it.

While it would be easier to troubleshoot, I might decrease performance
by the same or likely the same metrics.

Peering via IXP/PNI

pro:
- more, maybe better paths
- more ways to loadbalance traffic over various PNI/IXP
- added redundancy

cons:
- needs grow to maintain sessions
- maintain a contact database for the specific networks
- tools needed to pinpoint issues on node, PNI / IXP, network level


"Feeding" via some bigger peer networks oder classic transit

pro:
- single point of contact
- less sessions to maintain (say 400 sessions for all bigger europe
cities instead of 200 sessions per IXP)
- easier view on traffic flows (depends on your tools though)

cons:
- if a single network breaks, it might have a bigger impact
- not able to (easily) mitigate issues (ceasing announcements to a peer
vs. turning down a transit session)
- troubleshooting mostly outsourced to a 3rd party

It depends on what one needs, and what one wants to pay.

-dominik


From bill at herrin.us  Tue May  1 13:43:50 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 1 May 2012 14:43:50 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
Message-ID: <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>

On 5/1/12, Patrick W. Gilmore <patrick at ianai.net> wrote:
> On May 1, 2012, at 13:26 , William Herrin wrote:
>> If I'm willing to go to your location, buy the card for your router
>> and pay you for the staff hours to set it up, there should be *no*
>> situation in which I'm willing to accept your traffic from an upstream
>> Internet link but am unwilling to engage in otherwise settlement-free
>> peering with you.
>
> I disagree with this.  In fact, I can think of several possible cases where
> this would not hold, both using pure business and pure technical
> justifications.

Hi Patrick,

Please educate me. I'd be happy to adopt a more nuanced view.


>> Your customers have paid you to connect to me and my customers have
>> paid me to connect to you. Double-billing the activity by either of us
>> collecting money from the other is just plain wrong.
>
> Wrong?  My rule is: Your network, your decision.

Yes, wrong. Some decisions fall in to areas covered by general ethics.

You sell a customer a red ball when you know you can only deliver
green balls, it's a lie. Unethical. Wrong.

You work for a company (W2 salary) and in the course of your work
contract something to another company where you're an officer it's a
conflict of interest. Unethical. Wrong.

A customer pays you to build a piece of software by the hour. Another
comes along and asks for the same software. You bill both for each
hour. Double billing. Unethical. Wrong.

A customer pays you to deliver a packet to "the Internet." You talk to
the packet's destination and say, "Hey, I'll deliver it to you
directly but only if you pay me. Otherwise I'll just toss it out in a
random direction and hope it gets there." Double billing. Unethical.
Wrong.

None of these things is necessarily illegal although like spam some of
them are illegal under specific conditions. Yet all of them (and spam)
are Wrong.

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 patrick at ianai.net  Tue May  1 14:06:08 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 1 May 2012 15:06:08 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
Message-ID: <47307F16-391F-4DA1-830E-75FEC730944D@ianai.net>

On May 1, 2012, at 14:43 , William Herrin wrote:
> On 5/1/12, Patrick W. Gilmore <patrick at ianai.net> wrote:
>> On May 1, 2012, at 13:26 , William Herrin wrote:
>>> If I'm willing to go to your location, buy the card for your router
>>> and pay you for the staff hours to set it up, there should be *no*
>>> situation in which I'm willing to accept your traffic from an upstream
>>> Internet link but am unwilling to engage in otherwise settlement-free
>>> peering with you.
>> 
>> I disagree with this.  In fact, I can think of several possible cases where
>> this would not hold, both using pure business and pure technical
>> justifications.
> 
> Hi Patrick,
> 
> Please educate me. I'd be happy to adopt a more nuanced view.

First, define "upstream Internet link" - i.e. upstream to whom?  If I peer with your upstream, then peering with you could easily drop me below their requirements, causing me to lose a much bigger peer for what I may consider no real benefit.

Let's assume you meant upstream to me.  Many people negotiate volume discounts, peering with you may drop me to a lower tier, which may cost me more than your peering saves me.

Let's further assume it is upstream to me.  Perhaps I am trying to turn that upstream into a peer.  This devolves into the first situation.

Irrelevant on what you meant by upstream, I may have operational issues such as space & power, that disallow me from adding another port pointed at you in the location you want the port.  I don't care if you buy the card, if there is no slot or power for the card, buying another rack - if possible in the first place! - may not be worth the benefit of peering with you.  And I haven't even covered the CapEx & OpEx of adding a chassis to deal with your port irrespective of the power & space.

Etc.

Hopefully you get the gist.


>>> Your customers have paid you to connect to me and my customers have
>>> paid me to connect to you. Double-billing the activity by either of us
>>> collecting money from the other is just plain wrong.
>> 
>> Wrong?  My rule is: Your network, your decision.
> 
> Yes, wrong. Some decisions fall in to areas covered by general ethics.
> 
> You sell a customer a red ball when you know you can only deliver
> green balls, it's a lie. Unethical. Wrong.
> 
> You work for a company (W2 salary) and in the course of your work
> contract something to another company where you're an officer it's a
> conflict of interest. Unethical. Wrong.

I see your point here, but neither of those examples are peering related.


> A customer pays you to build a piece of software by the hour. Another
> comes along and asks for the same software. You bill both for each
> hour. Double billing. Unethical. Wrong.

This is far less clear.  Should the second customer get it for free just because you already wrote the code?  Or is it the fact you billed "an hour" instead of "software" that bothers you?

Not that it matters, since this has nothing to do with peering.


> A customer pays you to deliver a packet to "the Internet." You talk to
> the packet's destination and say, "Hey, I'll deliver it to you
> directly but only if you pay me. Otherwise I'll just toss it out in a
> random direction and hope it gets there." Double billing. Unethical.
> Wrong.

I think if you look closely at any transit contract, almost none of them (cough Akamai cough) guarantee delivery t the end user.  They typically only guarantee delivery to the edge of their own network, and make zero promises about _which_ edge they will use to get to the next network.  Plus those "guarantees" are weaker than almost any other guarantee in any industry.

Of course, if someone sold me "full transit" and could not reach a significant fraction of the Internet, I'd claim breach of contract.  But A != B.

So the straw man above _may_ be morally wrong (I'm not 100% certain of it, need to ruminate some more), it doesn't actually exist in the real world.  And certainly is not related to the original post.

Besides, "double billing" is not unethical in your example above.  Using your exact straw man, if I go to the destination, make that threat, and they cave, I haven't harmed my customer at all.  If they don't cave and I send them the packet directly anyway, I still haven't harmed my customer.  Double-billing in-and-of itself is not morally wrong.


All that said, if a provider sucks, change providers.  <Cue discussion about being unable to change providers and how wrong that is. :->


> None of these things is necessarily illegal although like spam some of
> them are illegal under specific conditions. Yet all of them (and spam)
> are Wrong.

We can agree that spam is wrong. :)

-- 
TTFN,
patrick



From bicknell at ufp.org  Tue May  1 14:17:09 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 1 May 2012 12:17:09 -0700
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <4FA02A0B.7050505@rrbone.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net>
Message-ID: <20120501191709.GA17758@ussenterprise.ufp.org>

In a message written on Tue, May 01, 2012 at 08:23:07PM +0200, Dominik Bay wrote:
> "Feeding" via some bigger peer networks oder classic transit

You have made the assumption that their choice is peering with your
network or sending it out transit.  They may in fact peer with your
upstream.

That makes their choice peer with you, or peer with your upstream.
Peering with your upstream may allow them to reach many people like
you for cost of managing only a single peering session, as compared
to maintaining a few dozen.

Also, many networks have minimum volume amounts for peering
relationships.  They may be able to get settlement free peering
with your upstream by having some minimum traffic level that they
would not have if they peer with some of the individual customers
behind that upstream.  Peering with you may drop them below the
threshold, causing them to pay for transit on 10's of Gigs of
traffic.

-- 
       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/20120501/2e3e8d12/attachment.bin>

From millnert at gmail.com  Tue May  1 14:19:21 2012
From: millnert at gmail.com (Martin Millnert)
Date: Tue, 01 May 2012 21:19:21 +0200
Subject: rpki vs. secure dns?
In-Reply-To: <4F9DA9A1.9000301@foobar.org>
References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de>
 <F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net>
 <874ns42ioc.fsf@mid.deneb.enyo.de>
 <E81ED66C-EE27-42B0-866E-F2AD4FF0614B@ripe.net>
 <4F9DA9A1.9000301@foobar.org>
Message-ID: <1335899961.7504.71.camel@davinci.millnert.se>

On Sun, 2012-04-29 at 21:50 +0100, Nick Hilliard wrote:
> -  the RIPE NCC is now funding a project for which there is no
> consensus policy supported by the RIPE community, and is doing this on
> the basis of a hair's breath majority vote amongst its membership.

Not only were the vote extremely narrow, a whopping ~97% of the voters
did not vote at all.

If we incorporate the no-shows, the vote statistics becomes something
like:

120 Yes
114 No
26 Abstain
~7400 No-shows

The membership got a chance to speak on the topic and largely didn't.

Best,
Martin



From Valdis.Kletnieks at vt.edu  Tue May  1 14:19:27 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 01 May 2012 15:19:27 -0400
Subject: Operation Ghost Click
In-Reply-To: Your message of "Tue, 01 May 2012 10:40:57 -0400."
 <20120501144057.GA6771@gsp.org>
References: <4F99C288.1030705@paulgraydon.co.uk>
 <CBC546BF.5C805%jason_livingood@cable.comcast.com>
 <20120501144057.GA6771@gsp.org>
Message-ID: <18010.1335899967@turing-police.cc.vt.edu>

On Tue, 01 May 2012 10:40:57 -0400, Rich Kulawiec said:

> Why haven't you cut these obviously-infected systems off entirely?

There's quite likely multiple systems behind a NAT-ish router, and Comcast
doesn't have any real option but to nuke *all* the systems behind the router.

This can be a tad troublesome if there's one infected box behind the router,
but the customer is also using VoIP of some sort from another box - you may
just have nuked their 911 capability. Or if they have multiple systems, you may
have killed their ability to transact basic business like contact their local
government or pay their utility bills from a box that's not infected.

(Hint - it's the same basic reason why 3-strikes laws for copyright
infringement that turn off the subscriber suck - the unintended collateral
damage tends to break things you really don't want to break...)

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

From db at rrbone.net  Tue May  1 14:31:52 2012
From: db at rrbone.net (Dominik Bay)
Date: Tue, 1 May 2012 21:31:52 +0200
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <20120501191709.GA17758@ussenterprise.ufp.org>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net> <20120501191709.GA17758@ussenterprise.ufp.org>
Message-ID: <4FA03A28.6040809@rrbone.net>

On 05/01/2012 09:17 PM, Leo Bicknell wrote:
> In a message written on Tue, May 01, 2012 at 08:23:07PM +0200, Dominik Bay wrote:
>> "Feeding" via some bigger peer networks oder classic transit
> 
> You have made the assumption that their choice is peering with your
> network or sending it out transit.  They may in fact peer with your
> upstream.

No, I also assume 'bigger peer networks', usually a smaller ISPs
upstream with a bigger regional footprint.

> That makes their choice peer with you, or peer with your upstream.
> Peering with your upstream may allow them to reach many people like
> you for cost of managing only a single peering session, as compared
> to maintaining a few dozen.

Agreed, more reach with a single session, but with pros there are cons,
as mentioned in my last mail. If they choose to accept these
limitations, that's fine for me.
But one should be aware, especially when aiming towards low latency,
high bandwidth connections to eyeballs.

> Also, many networks have minimum volume amounts for peering
> relationships.  They may be able to get settlement free peering
> with your upstream by having some minimum traffic level that they
> would not have if they peer with some of the individual customers
> behind that upstream.  Peering with you may drop them below the
> threshold, causing them to pay for transit on 10's of Gigs of
> traffic.

Agreed, but this is more a monetary optimization, not a technical
optimization.
I don't agree on any peering request, especially if this would force
traffic on paths which are preferred but sub-optimal.
A situation which wouldn't be optimal can be this one:

Say a network in Sweden and Estonia reach them via one of their
upstreams which do have a direct connection.
They are both a member of an IXP in, say, Amsterdam.
Both networks exchange their prefixes, and set localpref at this IXP.
This would make the path worse than before, as traffic takes a detour,
and might cost more due to backhauling traffic.


From Jason_Livingood at cable.comcast.com  Tue May  1 14:41:35 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 1 May 2012 19:41:35 +0000
Subject: Operation Ghost Click
In-Reply-To: <18010.1335899967@turing-police.cc.vt.edu>
Message-ID: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>

On 5/1/12 3:19 PM, "Valdis.Kletnieks at vt.edu<mailto:Valdis.Kletnieks at vt.edu>" <Valdis.Kletnieks at vt.edu<mailto:Valdis.Kletnieks at vt.edu>> wrote:

On Tue, 01 May 2012 10:40:57 -0400, Rich Kulawiec said:

Why haven't you cut these obviously-infected systems off entirely?

There's quite likely multiple systems behind a NAT-ish router, and Comcast doesn't have any real option but to nuke *all* the systems behind the router.
This can be a tad troublesome if there's one infected box behind the router, but the customer is also using VoIP of some sort from another box - you may just have nuked their 911 capability. Or if they have multiple systems, you may have killed their ability to transact basic business like contact their local government or pay their utility bills from a box that's not infected.

All of this above! Plus, the remediation tools to clean up an infection are insufficient to the task right now. Better tools are needed. (See also http://tools.ietf.org/html/rfc6561#section-5.4)


Jason

From bicknell at ufp.org  Tue May  1 14:51:17 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 1 May 2012 12:51:17 -0700
Subject: Operation Ghost Click
In-Reply-To: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
References: <18010.1335899967@turing-police.cc.vt.edu>
 <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
Message-ID: <20120501195117.GA19184@ussenterprise.ufp.org>

In a message written on Tue, May 01, 2012 at 07:41:35PM +0000, Livingood, Jason wrote:
> All of this above! Plus, the remediation tools to clean up an infection are insufficient to the task right now. Better tools are needed. (See also http://tools.ietf.org/html/rfc6561#section-5.4)

Hey Jason, I'm going to put you on the spot with a crazy idea.

Many customers of the major internet providers also have other
services from them, like TV and Phone.  Perhaps expanding the notice
to those areas would be useful?  Turn on your cable box and get a
notice, or pick up the phone and get a notice?

It might really help in cases where one member of the family (e.g.
the children) are doing something bad that the bill payer (e.g. mom
and dad) doesn't know about.  Hit them on a medium they know more
about.

-- 
       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/20120501/038f4609/attachment.bin>

From eyeronic.design at gmail.com  Tue May  1 14:59:32 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Tue, 1 May 2012 12:59:32 -0700
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
Message-ID: <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>

"A customer pays you to build a piece of software by the hour. Another
comes along and asks for the same software. You bill both for each
hour. Double billing. Unethical. Wrong.

A customer pays you to deliver a packet to "the Internet." You talk to
the packet's destination and say, "Hey, I'll deliver it to you
directly but only if you pay me. Otherwise I'll just toss it out in a
random direction and hope it gets there." Double billing. Unethical.
Wrong."

Neither of these is unethical or wrong in any way.  What are you
supposed to do, write software from scratch every time? That's just
silly.

On Tue, May 1, 2012 at 11:43 AM, William Herrin <bill at herrin.us> wrote:
> On 5/1/12, Patrick W. Gilmore <patrick at ianai.net> wrote:
>> On May 1, 2012, at 13:26 , William Herrin wrote:
>>> If I'm willing to go to your location, buy the card for your router
>>> and pay you for the staff hours to set it up, there should be *no*
>>> situation in which I'm willing to accept your traffic from an upstream
>>> Internet link but am unwilling to engage in otherwise settlement-free
>>> peering with you.
>>
>> I disagree with this. ?In fact, I can think of several possible cases where
>> this would not hold, both using pure business and pure technical
>> justifications.
>
> Hi Patrick,
>
> Please educate me. I'd be happy to adopt a more nuanced view.
>
>
>>> Your customers have paid you to connect to me and my customers have
>>> paid me to connect to you. Double-billing the activity by either of us
>>> collecting money from the other is just plain wrong.
>>
>> Wrong? ?My rule is: Your network, your decision.
>
> Yes, wrong. Some decisions fall in to areas covered by general ethics.
>
> You sell a customer a red ball when you know you can only deliver
> green balls, it's a lie. Unethical. Wrong.
>
> You work for a company (W2 salary) and in the course of your work
> contract something to another company where you're an officer it's a
> conflict of interest. Unethical. Wrong.
>
> A customer pays you to build a piece of software by the hour. Another
> comes along and asks for the same software. You bill both for each
> hour. Double billing. Unethical. Wrong.
>
> A customer pays you to deliver a packet to "the Internet." You talk to
> the packet's destination and say, "Hey, I'll deliver it to you
> directly but only if you pay me. Otherwise I'll just toss it out in a
> random direction and hope it gets there." Double billing. Unethical.
> Wrong.
>
> None of these things is necessarily illegal although like spam some of
> them are illegal under specific conditions. Yet all of them (and spam)
> are Wrong.
>
> 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
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From effinjdent at gmail.com  Tue May  1 15:24:54 2012
From: effinjdent at gmail.com (Jerry Dent)
Date: Tue, 1 May 2012 15:24:54 -0500
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <20120501191709.GA17758@ussenterprise.ufp.org>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net>
 <20120501191709.GA17758@ussenterprise.ufp.org>
Message-ID: <CADUFW=WLTLjd12EQ=XH8vSjCmTV5MZnnQoUvFyRWkxhJPiJ8JA@mail.gmail.com>

On Tue, May 1, 2012 at 2:17 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, May 01, 2012 at 08:23:07PM +0200, Dominik Bay wrote:
>> "Feeding" via some bigger peer networks oder classic transit
>
> You have made the assumption that their choice is peering with your
> network or sending it out transit. ?They may in fact peer with your
> upstream.
>
> That makes their choice peer with you, or peer with your upstream.
> Peering with your upstream may allow them to reach many people like
> you for cost of managing only a single peering session, as compared
> to maintaining a few dozen.
>
> Also, many networks have minimum volume amounts for peering
> relationships. ?They may be able to get settlement free peering
> with your upstream by having some minimum traffic level that they
> would not have if they peer with some of the individual customers
> behind that upstream. ?Peering with you may drop them below the
> threshold, causing them to pay for transit on 10's of Gigs of
> traffic.

Lets be honest. There are a million reasons we can all come up with to
try and justify something like this but 99% of the time it is just the
larger isp trying to throw their weight around in the name of greed.
In the end, the customers of both companies are the ones who suffer
and ultimately pay (figuratively and literally) for it.


From patrick at ianai.net  Tue May  1 15:30:37 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 1 May 2012 16:30:37 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CADUFW=WLTLjd12EQ=XH8vSjCmTV5MZnnQoUvFyRWkxhJPiJ8JA@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net> <20120501191709.GA17758@ussenterprise.ufp.org>
 <CADUFW=WLTLjd12EQ=XH8vSjCmTV5MZnnQoUvFyRWkxhJPiJ8JA@mail.gmail.com>
Message-ID: <8D87F508-8198-4ED8-9806-761253FB2E5B@ianai.net>

On May 1, 2012, at 16:24 , Jerry Dent wrote:

> Lets be honest. There are a million reasons we can all come up with to
> try and justify something like this but 99% of the time it is just the
> larger isp trying to throw their weight around in the name of greed.
> In the end, the customers of both companies are the ones who suffer
> and ultimately pay (figuratively and literally) for it.

1) Welcome to business 101.

2) Is that bad?

3) I think your 99% number is very inflated.  But then 99% of stats are made up. :)

-- 
TTFN,
patrick



From vyto at fnal.gov  Tue May  1 15:31:08 2012
From: vyto at fnal.gov (Vytautas V Grigaliunas)
Date: Tue, 1 May 2012 20:31:08 +0000
Subject: IPv6 monitoring...
Message-ID: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>

Greetings...

What are people using for IPv6 monitoring - in particular, for monitoring services such as DNS, Web, E-mail, etc. ?

Nagios seems the people's choice. Any others...open source or commercial ?

TIA...

Vyto


From khomyakov.andrey at gmail.com  Tue May  1 15:32:20 2012
From: khomyakov.andrey at gmail.com (Andrey Khomyakov)
Date: Tue, 1 May 2012 16:32:20 -0400
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <CAOvEG7PbKvOcnRkGzO_KU9-N2wSycSBDAviu74TJ-8URtNZ=rQ@mail.gmail.com>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
 <4FA01BDB.1020408@nwwnet.net>
 <BLU156-W503D2619413924DB6F3F8C9290@phx.gbl> <4FA02526.5070201@bogus.com>
 <CAOvEG7PbKvOcnRkGzO_KU9-N2wSycSBDAviu74TJ-8URtNZ=rQ@mail.gmail.com>
Message-ID: <CAB31LONteH-BFA+8KNV9MDHtDpij9oUaOMSkUAuC9uXHmW2jMw@mail.gmail.com>

About support: I only had good experience with their support, but that were
the days Janice still worked there. Haven't used them in over a year, so
not sure what they are up to right now.

--Andrey


On Tue, May 1, 2012 at 2:22 PM, Ben Bartsch <uwcableguy at gmail.com> wrote:

> on intermapper, simply right click the link, select 'status window' and you
> will get all kinds of nice info.  be sure to use the bandwidth command on
> the interface if you are not using the default 10/100/1000/10gig.  also,
> the links turn yellow and orange as the line becomes more saturated (and
> the 'ants' get bigger/smaller as utilization goes up and down).
>
> only thing i don't like about intermapper is that vlans and physical
> interfaces are separate from each other.  and their tech support blows.
>
> ben
>
> On Tue, May 1, 2012 at 1:02 PM, Joel jaeggli <joelja at bogus.com> wrote:
>
> > we use cacti weathermap plugin, though obviously realtime has a
> > dependency on your sample interval. I'm presuming your definition
> > thereof isn't instantaneous monitoring of queue depth.
> >
> >
> > On 5/1/12 10:49 , Hank Disuko wrote:
> > >
> > > Thanks, I'll see if I can pull the correct OID and try it with the Dude
> > again.
> > >
> > > Also, thanks to everyone who has responded.  I realize the term
> > "realtime" is subjective - I'm looking for near-realtime...maybe a 30
> > second interval.
> > >
> > > I've been playing around with Intermapper for about 30 minutes now...i
> > like this tool, but would like to see bitrates represented on the map as
> > opposed to the "crawling ants".  clicking around to see if kind of view
> is
> > available...
> > >
> > > thanks again folks.  Good example, in my case anyway, of NANOG
> > outperforming Google (or at least my crappy attempts at google search
> > terms).
> > >
> > > -Hank
> > >
> > > ----------------------------------------
> > >> Date: Tue, 1 May 2012 13:22:35 -0400
> > >> From: sreed at nwwnet.net
> > >> To: gourmetcisco at hotmail.com
> > >> Subject: Re: Network diagram app that shows realtime link utilizatin
> > >>
> > >> I monitor non-MT devices with the Dude.
> > >> As long as you know the OID, it works just fine.
> > >>
> > >> On 5/1/2012 12:41 PM, Hank Disuko wrote:
> > >>>
> > >>> Hi folks,
> > >>>
> > >>> I wonder if anyone can recommend a network diagram tool that can show
> > realtime link utilization via snmp?
> > >>>
> > >>> Mikrotik's "The Dude" app actually does exactly what I'm looking for,
> > but the snmp support for non-RouterOS devices seems to be lacking, as it
> > simply won't enumerate my switch interfaces in order to capture
> utilization.
> > >>>
> > >>> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds
> > LANsurveyor etc.) but they don't serve this very basic need of mine to
> see
> > the realtime link util in the diagram.
> > >>>
> > >>> Thanks,
> > >>> Hank Disuko
> > >>>
> > >>>
> > >>>
> > >>> -----
> > >>> No virus found in this message.
> > >>> Checked by AVG - www.avg.com
> > >>> Version: 2012.0.1913 / Virus Database: 2411/4971 - Release Date:
> > 05/01/12
> > >>>
> > >>>
> > >>>
> > >>
> > >> --
> > >> Scott Reed
> > >> Owner
> > >> NewWays Networking, LLC
> > >> Wireless Networking
> > >> Network Design, Installation and Administration
> > >>
> > >>
> > >>
> > >> Mikrotik Advanced Certified
> > >>
> > >> www.nwwnet.net
> > >> (765) 855-1060
> > >> (765) 439-4253
> > >> (855) 231-6239
> > >>
> > >>
> > >
> > >
> >
> >
> >
>

From paul at paulstewart.org  Tue May  1 15:32:55 2012
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 1 May 2012 16:32:55 -0400
Subject: IPv6 monitoring...
In-Reply-To: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
References: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
Message-ID: <00a601cd27d9$987b8230$c9728690$@paulstewart.org>

We are using Solarwinds on our systems..... it's one commercial system to
consider.

Paul


-----Original Message-----
From: Vytautas V Grigaliunas [mailto:vyto at fnal.gov] 
Sent: May-01-12 4:31 PM
To: nanog at nanog.org
Subject: IPv6 monitoring...

Greetings...

What are people using for IPv6 monitoring - in particular, for monitoring
services such as DNS, Web, E-mail, etc. ?

Nagios seems the people's choice. Any others...open source or commercial ?

TIA...

Vyto




From gem at rellim.com  Tue May  1 15:34:43 2012
From: gem at rellim.com (Gary E. Miller)
Date: Tue, 1 May 2012 13:34:43 -0700
Subject: IPv6 monitoring...
In-Reply-To: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
References: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
Message-ID: <20120501133443.668fa0e7.gem@rellim.com>

Yo Vytautas!

On Tue, 1 May 2012 20:31:08 +0000
Vytautas V Grigaliunas <vyto at fnal.gov> wrote:

> Nagios seems the people's choice. Any others...open source or
> commercial ?
 
Icinga.  A fork of nagios

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120501/14671471/attachment.bin>

From nanog-post at rsuc.gweep.net  Tue May  1 15:39:02 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Tue, 1 May 2012 16:39:02 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
Message-ID: <20120501203902.GA97799@gweep.net>

On Tue, May 01, 2012 at 02:43:50PM -0400, William Herrin wrote:
> On 5/1/12, Patrick W. Gilmore <patrick at ianai.net> wrote:
> > On May 1, 2012, at 13:26 , William Herrin wrote:
> >> If I'm willing to go to your location, buy the card for your router
> >> and pay you for the staff hours to set it up, there should be *no*
> >> situation in which I'm willing to accept your traffic from an upstream
> >> Internet link but am unwilling to engage in otherwise settlement-free
> >> peering with you.
> >
> > I disagree with this.  In fact, I can think of several possible cases where
> > this would not hold, both using pure business and pure technical
> > justifications.
> 
> Hi Patrick,
> 
> Please educate me. I'd be happy to adopt a more nuanced view.
> 
> 
> >> Your customers have paid you to connect to me and my customers have
> >> paid me to connect to you. Double-billing the activity by either of us
> >> collecting money from the other is just plain wrong.
> >
> > Wrong?  My rule is: Your network, your decision.
> 
> Yes, wrong. Some decisions fall in to areas covered by general ethics.

You are high. If I've entered into contracts with multiple parties to
deliver their traffic, there is no 'double dipping' or 'double billing'.
Ignore any sort of traffic *type*. To assert that some transit entity 
with two customers paying to reach the universe (happens to include each
party reciprocally) should go out of their way to discount for such 
customer to customer traffic is both madness of bellhead-accounting
level and a quick route to bankruptcy. Stupid and nothing YOU would
certainly do for your customers...?

> You sell a customer a red ball when you know you can only deliver
> green balls, it's a lie. Unethical. Wrong.

Utterly irrelevant to the discussion.

> You work for a company (W2 salary) and in the course of your work
> contract something to another company where you're an officer it's a
> conflict of interest. Unethical. Wrong.

Utterly irrelevant to the discussion.
 
> A customer pays you to build a piece of software by the hour. Another
> comes along and asks for the same software. You bill both for each
> hour. Double billing. Unethical. Wrong.

Utterly irrelevant to the discussion.
 
> A customer pays you to deliver a packet to "the Internet." You talk to
> the packet's destination and say, "Hey, I'll deliver it to you
> directly but only if you pay me. Otherwise I'll just toss it out in a
> random direction and hope it gets there." Double billing. Unethical.
> Wrong.

Mindset of an inexperienced small provider who believes "the Internet" 
is something 'out there' and your infrastructure isn't part of it. Your 
customers give you traffic at your handoff to deliver to/from others. 
Some of those others amy also be your customers; are you giving them 
free traffic customer-to-customer [complex accounting at your egress 
to peers and transit] or are you billing them for traffic transferred 
[port stats facing the customer]?

Discussion of applicability of one model or another to this or that type
of business is an interesting academic exercise, but if you aren't willing
to give your customers free transit across your service to each other, your
position is at best disingenuous. At worst, hypocritical.

Cheers!

Joe

-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG


From axisml at gmail.com  Tue May  1 15:40:57 2012
From: axisml at gmail.com (Chris Stone)
Date: Tue, 1 May 2012 14:40:57 -0600
Subject: IPv6 monitoring...
In-Reply-To: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
References: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
Message-ID: <CA+mO9gEpuh9WLgVtMeGHPRXWL1gZ+REZhhpF4QcVcE0xOc2tPw@mail.gmail.com>

On Tue, May 1, 2012 at 2:31 PM, Vytautas V Grigaliunas <vyto at fnal.gov> wrote:
> What are people using for IPv6 monitoring - in particular, for monitoring services such as DNS, Web, E-mail, etc. ?
>
> Nagios seems the people's choice. Any others...open source or commercial ?

We use a combination of Nagios and Observium




-- 
Chris Stone
AxisInternet, Inc.
www.axint.net


From effinjdent at gmail.com  Tue May  1 15:45:29 2012
From: effinjdent at gmail.com (Jerry Dent)
Date: Tue, 1 May 2012 15:45:29 -0500
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <8D87F508-8198-4ED8-9806-761253FB2E5B@ianai.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net>
 <20120501191709.GA17758@ussenterprise.ufp.org>
 <CADUFW=WLTLjd12EQ=XH8vSjCmTV5MZnnQoUvFyRWkxhJPiJ8JA@mail.gmail.com>
 <8D87F508-8198-4ED8-9806-761253FB2E5B@ianai.net>
Message-ID: <CADUFW=XzX1_ELMFpgkTmj7EhwVjycAsar_2b+yxXtAnMQ9WE+Q@mail.gmail.com>

On Tue, May 1, 2012 at 3:30 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> On May 1, 2012, at 16:24 , Jerry Dent wrote:
>
>> Lets be honest. There are a million reasons we can all come up with to
>> try and justify something like this but 99% of the time it is just the
>> larger isp trying to throw their weight around in the name of greed.
>> In the end, the customers of both companies are the ones who suffer
>> and ultimately pay (figuratively and literally) for it.
>
> 1) Welcome to business 101.
>
> 2) Is that bad?

Can be for the end users if they wind up on a less direct network path.

>
> 3) I think your 99% number is very inflated. ?But then 99% of stats are made up. :)

Probably.


From bicknell at ufp.org  Tue May  1 15:54:05 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 1 May 2012 13:54:05 -0700
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CADUFW=XzX1_ELMFpgkTmj7EhwVjycAsar_2b+yxXtAnMQ9WE+Q@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net> <20120501191709.GA17758@ussenterprise.ufp.org>
 <CADUFW=WLTLjd12EQ=XH8vSjCmTV5MZnnQoUvFyRWkxhJPiJ8JA@mail.gmail.com>
 <8D87F508-8198-4ED8-9806-761253FB2E5B@ianai.net>
 <CADUFW=XzX1_ELMFpgkTmj7EhwVjycAsar_2b+yxXtAnMQ9WE+Q@mail.gmail.com>
Message-ID: <20120501205405.GA20997@ussenterprise.ufp.org>

In a message written on Tue, May 01, 2012 at 03:45:29PM -0500, Jerry Dent wrote:
> Can be for the end users if they wind up on a less direct network path.

"Direct" is not the only measure.

I would take a 4-hop, 10GE, no packet loss path over a 1-hop, 1GE,
5% packet loss path any day of the week.

"Shorter" {hops, latency, as-path} does not mean a higher quality end
user experience.

-- 
       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/20120501/b63805e5/attachment.bin>

From jcdill.lists at gmail.com  Tue May  1 15:56:49 2012
From: jcdill.lists at gmail.com (JC Dill)
Date: Tue, 01 May 2012 13:56:49 -0700
Subject: Operation Ghost Click
In-Reply-To: <20120501195117.GA19184@ussenterprise.ufp.org>
References: <18010.1335899967@turing-police.cc.vt.edu>
 <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <20120501195117.GA19184@ussenterprise.ufp.org>
Message-ID: <4FA04E11.9060105@gmail.com>

On 01/05/12 12:51 PM, Leo Bicknell wrote:
> In a message written on Tue, May 01, 2012 at 07:41:35PM +0000, Livingood, Jason wrote:
>> All of this above! Plus, the remediation tools to clean up an infection are insufficient to the task right now. Better tools are needed. (See also http://tools.ietf.org/html/rfc6561#section-5.4)
> Hey Jason, I'm going to put you on the spot with a crazy idea.
>
> Many customers of the major internet providers also have other
> services from them, like TV and Phone.  Perhaps expanding the notice
> to those areas would be useful?  Turn on your cable box and get a
> notice, or pick up the phone and get a notice?
>
> It might really help in cases where one member of the family (e.g.
> the children) are doing something bad that the bill payer (e.g. mom
> and dad) doesn't know about.  Hit them on a medium they know more
> about.

Upthread Jason posted:

> At Comcast we have done the following:
> - Sent emails
> - Send postal mail
> - Left voicemail
> - Used automated outbound calling
> - Used increasingly persistent web browser notifications

Notice item #2 - postal mail - very unlikely the kids are checking the 
postal mail daily and removing notices from the ISP to keep them from 
Mom and Dad.


For all those who are using automated methods to contact their 
customers, if you have a cell phone number for the customer also try 
sending text to the phone.  I find a significant number of people today:

A)  Have a cell phone but no other phone;
B)  Do not use voicemail on their cell phone.  The VM box may be full, 
may not be setup, may be setup but they never (or rarely) check VM;
C)  Rarely check email!

For this group, text is the way to go.  I have left repeated VMs which 
are not answered, but send one text and get a reply back within 
minutes.  The younger the cell phone user, the more likely they are in 
this group but I also have friends (including one who has worked 
extensively in the ISP industry) who are in their 40s and older who are 
taking up this habit.

jc





From bill at herrin.us  Tue May  1 16:06:39 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 1 May 2012 17:06:39 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
Message-ID: <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>

On 5/1/12, Mike Hale <eyeronic.design at gmail.com> wrote:
> "A customer pays you to build a piece of software by the hour. Another
> comes along and asks for the same software. You bill both for each
> hour. Double billing. Unethical. Wrong.
> [...]
> Neither of these is unethical or wrong in any way.  What are you
> supposed to do, write software from scratch every time? That's just
> silly.

Hi Mike,

If one of the customers happens to be the U.S. Government, it's not
only unethical it's a crime. It's usually a felony. You can do time.
The product was man hours. You've sold them once. You can't sell them
again.

The customers can agree to share the cost up front. But then you're
not billing the same hours twice, you're billing half an hour to one
customer and half to another. When you finish the software you can
sell the software to a second customer. But you *may not* tie your
price to the hours used to produce it for the first.

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 eyeronic.design at gmail.com  Tue May  1 16:13:01 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Tue, 1 May 2012 14:13:01 -0700
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
Message-ID: <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>

"If one of the customers happens to be the U.S. Government, it's not
only unethical it's a crime. It's usually a felony. You can do time.
The product was man hours. You've sold them once. You can't sell them
again."
You're assuming the contract is simply for work hours.  Generally
speaking, and from my experience, it isn't.  The contract is for an
app that does X, not 20 hours toward building an app that does X.

"But you *may not* tie your
price to the hours used to produce it for the first."
Sure you can.  How else do you determine what the software's going to
cost if you're not going to factor in development?

On Tue, May 1, 2012 at 2:06 PM, William Herrin <bill at herrin.us> wrote:
> On 5/1/12, Mike Hale <eyeronic.design at gmail.com> wrote:
>> "A customer pays you to build a piece of software by the hour. Another
>> comes along and asks for the same software. You bill both for each
>> hour. Double billing. Unethical. Wrong.
>> [...]
>> Neither of these is unethical or wrong in any way. ?What are you
>> supposed to do, write software from scratch every time? That's just
>> silly.
>
> Hi Mike,
>
> If one of the customers happens to be the U.S. Government, it's not
> only unethical it's a crime. It's usually a felony. You can do time.
> The product was man hours. You've sold them once. You can't sell them
> again.
>
> The customers can agree to share the cost up front. But then you're
> not billing the same hours twice, you're billing half an hour to one
> customer and half to another. When you finish the software you can
> sell the software to a second customer. But you *may not* tie your
> price to the hours used to produce it for the first.
>
> 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



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From patrick at ianai.net  Tue May  1 16:16:38 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 1 May 2012 17:16:38 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
Message-ID: <A9F2D6BD-F6C2-4B6D-A122-4F039EEA93FF@ianai.net>

Let's keep our eye on the ball, people.  Did the original post have any operational consequences?

IMHO, it has many.  Some are even interesting to the wider audience.  So why are we discussing how you bill the US gov't?

-- 
TTFN,
patrick

P.S. Bill, it is clear you have a point, but you are really stretching it.  And it is not relevant to the discussion at hand.


On May 1, 2012, at 17:13 , Mike Hale wrote:

> "If one of the customers happens to be the U.S. Government, it's not
> only unethical it's a crime. It's usually a felony. You can do time.
> The product was man hours. You've sold them once. You can't sell them
> again."
> You're assuming the contract is simply for work hours.  Generally
> speaking, and from my experience, it isn't.  The contract is for an
> app that does X, not 20 hours toward building an app that does X.

[snip]

From Valdis.Kletnieks at vt.edu  Tue May  1 16:20:53 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 01 May 2012 17:20:53 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: Your message of "Tue, 01 May 2012 14:13:01 -0700."
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
Message-ID: <24340.1335907253@turing-police.cc.vt.edu>

On Tue, 01 May 2012 14:13:01 -0700, Mike Hale said:

> > "But you *may not* tie your
> > price to the hours used to produce it for the first."

The above was William Herrin's comment (quoting level fixed by me).

Mike - please get mail software that does correct quoting. It's 2012, and
proper quoting has been understood since the mid 80s.  There's *really* no
excuse for using software that can't get quoting and citing right.

> Sure you can.  How else do you determine what the software's going to
> cost if you're not going to factor in development?

You missed the point - having given customer #1 an invoice that included
a line item for 1,432 hours of R&D at $221/hour, you're treading on thin
ice if you present another customer an invoice that includes a line item for
the same 1,432 hours of R&D (absent an agreement between the two
customers to share the costs, etc).

And if you've *collected* that $316,472 from the one customer, it's somewhere
between sleazy and skanky to include that $316K in the costs that need to be
amortized over the next N sales of the software.

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

From Valdis.Kletnieks at vt.edu  Tue May  1 16:24:23 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 01 May 2012 17:24:23 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: Your message of "Tue, 01 May 2012 17:16:38 -0400."
 <A9F2D6BD-F6C2-4B6D-A122-4F039EEA93FF@ianai.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
 <A9F2D6BD-F6C2-4B6D-A122-4F039EEA93FF@ianai.net>
Message-ID: <24533.1335907463@turing-police.cc.vt.edu>

On Tue, 01 May 2012 17:16:38 -0400, "Patrick W. Gilmore" said:

> P.S. Bill, it is clear you have a point, but you are really stretching
> it.  And it is not relevant to the discussion at hand.

Oh, I dunno.  Double billing 2 customers for development and double billing
2 customers for transporting packets seem related ;)

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

From eyeronic.design at gmail.com  Tue May  1 16:27:50 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Tue, 1 May 2012 14:27:50 -0700
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <24340.1335907253@turing-police.cc.vt.edu>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
 <24340.1335907253@turing-police.cc.vt.edu>
Message-ID: <CAN3um4w31SzT-ZTfwSOqWDngT==CcRCU_YE-d7q2jtOOU=op3A@mail.gmail.com>

> Mike - please get mail software that does correct quoting. It's 2012, and
> proper quoting has been understood since the mid 80s.  There's *really* no
> excuse for using software that can't get quoting and citing right.
*eye roll*
Really?  You wasted 36 words on this?

> And if you've *collected* that $316,472 from the one customer, it's somewhere
> between sleazy and skanky to include that $316K in the costs that need to be
> amortized over the next N sales of the software.
It's neither sleazy nor skanky.  It's called profit.  I get what
you're saying, but it's a silly argument because, while you're not
going to bill the same "hours" (as a unit) twice, you sure as hell are
going to bill over and over again for the same work...you'd be stupid
not to.

On Tue, May 1, 2012 at 2:20 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 01 May 2012 14:13:01 -0700, Mike Hale said:
>
>> > "But you *may not* tie your
>> > price to the hours used to produce it for the first."
>
> The above was William Herrin's comment (quoting level fixed by me).
>
> Mike - please get mail software that does correct quoting. It's 2012, and
> proper quoting has been understood since the mid 80s. ?There's *really* no
> excuse for using software that can't get quoting and citing right.
>
>> Sure you can. ?How else do you determine what the software's going to
>> cost if you're not going to factor in development?
>
> You missed the point - having given customer #1 an invoice that included
> a line item for 1,432 hours of R&D at $221/hour, you're treading on thin
> ice if you present another customer an invoice that includes a line item for
> the same 1,432 hours of R&D (absent an agreement between the two
> customers to share the costs, etc).
>
> And if you've *collected* that $316,472 from the one customer, it's somewhere
> between sleazy and skanky to include that $316K in the costs that need to be
> amortized over the next N sales of the software.
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From effinjdent at gmail.com  Tue May  1 16:41:59 2012
From: effinjdent at gmail.com (Jerry Dent)
Date: Tue, 1 May 2012 16:41:59 -0500
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <20120501205405.GA20997@ussenterprise.ufp.org>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <4FA02A0B.7050505@rrbone.net>
 <20120501191709.GA17758@ussenterprise.ufp.org>
 <CADUFW=WLTLjd12EQ=XH8vSjCmTV5MZnnQoUvFyRWkxhJPiJ8JA@mail.gmail.com>
 <8D87F508-8198-4ED8-9806-761253FB2E5B@ianai.net>
 <CADUFW=XzX1_ELMFpgkTmj7EhwVjycAsar_2b+yxXtAnMQ9WE+Q@mail.gmail.com>
 <20120501205405.GA20997@ussenterprise.ufp.org>
Message-ID: <CADUFW=Vi5hkFS=MLUuirrGOeUbcTftRw0uPyQ6MJs1VBj_BFTw@mail.gmail.com>

On Tue, May 1, 2012 at 3:54 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, May 01, 2012 at 03:45:29PM -0500, Jerry Dent wrote:
>> Can be for the end users if they wind up on a less direct network path.
>
> "Direct" is not the only measure.
>
> I would take a 4-hop, 10GE, no packet loss path over a 1-hop, 1GE,
> 5% packet loss path any day of the week.
>
> "Shorter" {hops, latency, as-path} does not mean a higher quality end
> user experience.
>

I was using "Direct" as a generic term. And if the issue was link
performance, company A would have sent company B a "shape up or we'll
de-peer" message rather than a "pay up or we'll de-peer" message.


From bill at herrin.us  Tue May  1 16:46:21 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 1 May 2012 17:46:21 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <47307F16-391F-4DA1-830E-75FEC730944D@ianai.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <47307F16-391F-4DA1-830E-75FEC730944D@ianai.net>
Message-ID: <CAP-guGW=KiSzP_ouL=Kw-BJ3W09vrkJYoh9k+a3Ajxm=oXMLcA@mail.gmail.com>

On Tue, May 1, 2012 at 3:06 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> On May 1, 2012, at 14:43 , William Herrin wrote:
>> On 5/1/12, Patrick W. Gilmore <patrick at ianai.net> wrote:
>>> On May 1, 2012, at 13:26 , William Herrin wrote:
>>>> If I'm willing to go to your location, buy the card for your router
>>>> and pay you for the staff hours to set it up, there should be *no*
>>>> situation in which I'm willing to accept your traffic from an upstream
>>>> Internet link but am unwilling to engage in otherwise settlement-free
>>>> peering with you.
>>>
>>> I disagree with this. ?In fact, I can think of several possible cases where
>>> this would not hold, both using pure business and pure technical
>>> justifications.
>>
>> Hi Patrick,
>>
>> Please educate me. I'd be happy to adopt a more nuanced view.
>
> First, define "upstream Internet link" - i.e. upstream to whom?

Hi Patrick,

By "upstream" I meant "via any other path." If we're mutually willing
to talk at all, we should be willing to talk directly.

>?If I peer with your upstream, then peering with you could
> easily drop me below their requirements, causing me to
> lose a much bigger peer for what I may consider no real benefit.

Two wrongs. It's OK for me to behave unreasonably to you because I'm
just passing it on from someone else.

> Let's assume you meant upstream to me. Many people
> negotiate volume discounts, peering with you may drop me
> to a lower tier, which may cost me more than your peering saves me.

I'll have to think about this one.


> I may have
> operational issues such as space & power, that disallow
> me from adding another port pointed at you in the location
> you want the port. ?I don't care if you buy the card, if there
> is no slot or power for the card, buying another rack - if
> possible in the first place! - may not be worth the benefit of
> peering with you. ?And I haven't even covered the CapEx
> & OpEx of adding a chassis to deal with your port
> irrespective of the power & space.

Fair point; I was too specific. If I'm willing to cover the -direct
costs-  (such as an extra router card or man hours, extra rack space,
etc.) associated with peering with me at a location in which you have
already made the choice to peer with others I think it unreasonable of
you to refuse given that each of our respective customers has paid us
to deliver packets to the other.


Here's another one you didn't raise, but I'll throw it out there
anyway: Why should I be able to demand to peer with your entire
network at any location which happens to be convenient for me?

I shouldn't. I should be able to demand to peer with that fraction of
your network which is consistent with any other peering activity you
have at that location. If you peer at 5 geographically dispersed
locations and I only want to peer with you at one, I would think it
imminently reasonable for you to restrict the session to that portion
of your network which ordinarily transits to peers there. I wouldn't
even be offended by an offer for discount transit to the rest in
addition to the settlement free part.



> I think if you look closely at any transit contract, almost none
>of them (cough Akamai cough) guarantee delivery t the end
>user. ?They typically only guarantee delivery to the edge of
>their own network, and make zero promises about _which_

I think that's disingenuous. Customers are buying "Internet" service,
not "the networks we feel like connecting you to" service. Both you
and your customer know it despite any weasel words in the contract.

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 Valdis.Kletnieks at vt.edu  Tue May  1 16:49:11 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 01 May 2012 17:49:11 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: Your message of "Tue, 01 May 2012 14:27:50 -0700."
 <CAN3um4w31SzT-ZTfwSOqWDngT==CcRCU_YE-d7q2jtOOU=op3A@mail.gmail.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
 <24340.1335907253@turing-police.cc.vt.edu>
 <CAN3um4w31SzT-ZTfwSOqWDngT==CcRCU_YE-d7q2jtOOU=op3A@mail.gmail.com>
Message-ID: <25693.1335908951@turing-police.cc.vt.edu>

On Tue, 01 May 2012 14:27:50 -0700, Mike Hale said:
> > Mike - please get mail software that does correct quoting. It's 2012, and
> > proper quoting has been understood since the mid 80s.  There's *really* no
> > excuse for using software that can't get quoting and citing right.
> *eye roll*
> Really?  You wasted 36 words on this?

Wasn't wasted - this time your message included > in the right places.  :)

And yes, proper attribution *is* important.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120501/41d2eb68/attachment-0001.bin>

From dmiller at tiggee.com  Tue May  1 17:03:06 2012
From: dmiller at tiggee.com (David Miller)
Date: Tue, 01 May 2012 18:03:06 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <24340.1335907253@turing-police.cc.vt.edu>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
 <24340.1335907253@turing-police.cc.vt.edu>
Message-ID: <4FA05D9A.7030708@tiggee.com>

On 5/1/2012 5:20 PM, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 01 May 2012 14:13:01 -0700, Mike Hale said:
>
>>> "But you *may not* tie your
>>> price to the hours used to produce it for the first."
> The above was William Herrin's comment (quoting level fixed by me).
>
> Mike - please get mail software that does correct quoting. It's 2012, and
> proper quoting has been understood since the mid 80s.  There's *really* no
> excuse for using software that can't get quoting and citing right.
>
>> Sure you can.  How else do you determine what the software's going to
>> cost if you're not going to factor in development?
> You missed the point - having given customer #1 an invoice that included
> a line item for 1,432 hours of R&D at $221/hour, you're treading on thin
> ice if you present another customer an invoice that includes a line item for
> the same 1,432 hours of R&D (absent an agreement between the two
> customers to share the costs, etc).
>
> And if you've *collected* that $316,472 from the one customer, it's somewhere
> between sleazy and skanky to include that $316K in the costs that need to be
> amortized over the next N sales of the software.
>

>From an accounting perspective, every R&D effort that I have seen or
been a part of was not billed to any customer.  R&D has always, in my
experience, been an internal charge against a company's own profits.

As to hourly software development, I have never seen or been a part of a
software development effort where the final work product was not owned
by the entity paying for the hourly development.  The contract software
developer can't sell the same software twice because they don't own it
to sell it twice.

It is possible that my software development experience, while broad, has
missed a model where R&D is billed to customers or software isn't owned
by those who paid to have it developed...

If a company expends their own resources to develop a piece of software
(i.e. a product) regardless of whether through R&D (internal
development) or contracting with someone else to develop the product
(external development), then they can set the price of that product to
whatever they like.  There is nothing sleazy or skanky if the price of
the product multiplied by the number of copies sold is positive after
subtracting the price of the development of the product - we call that
profit.

-DMM



From Valdis.Kletnieks at vt.edu  Tue May  1 17:18:48 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 01 May 2012 18:18:48 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: Your message of "Tue, 01 May 2012 18:03:06 -0400."
 <4FA05D9A.7030708@tiggee.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
 <24340.1335907253@turing-police.cc.vt.edu>
 <4FA05D9A.7030708@tiggee.com>
Message-ID: <27039.1335910728@turing-police.cc.vt.edu>

On Tue, 01 May 2012 18:03:06 -0400, David Miller said:

> From an accounting perspective, every R&D effort that I have seen or
> been a part of was not billed to any customer.  R&D has always, in my
> experience, been an internal charge against a company's own profits.

RIght - and when pricing the result of the R&D, you take into account the
internal charges and estimated sales volume to determine a target price
point.  R&D was $316K and you estimate you can sell 100 of them, you're
going to have to charge at least $3,160 a copy to make a profit on the
project.  You sank $150M into R&D and think you'll sell a million units, you'll
need to charge $150 to break even.  And so on.

The point is that if you already got *paid* the $316K, it's morally wrong to
include it in the calculation of "sunk costs we need to recoup to turn a profit".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120501/116a0027/attachment.bin>

From bill at herrin.us  Tue May  1 17:21:09 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 1 May 2012 18:21:09 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <4FA05D9A.7030708@tiggee.com>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
 <CAP-guGWsbibkn4gCWxvkY++n_7S+ZziOpxTKTijAnuf7_M-AEA@mail.gmail.com>
 <CAN3um4xGCTWGgrwG4PkB9QWCoNoAUUcbY21u_XbNy2f_0nYfZg@mail.gmail.com>
 <CAP-guGVCPWc3nrUibFjnXryACS7j-bZU75Lc9fwgBfLXGDgYfA@mail.gmail.com>
 <CAN3um4wfneZfw_+5xHtZJz+R-3-TA4fRx0s10gJ+ZGDy6k7RgQ@mail.gmail.com>
 <24340.1335907253@turing-police.cc.vt.edu> <4FA05D9A.7030708@tiggee.com>
Message-ID: <CAP-guGUxdb4NNEeP5znONVqYZw13-rwOOiTAh_hAz36h=__paQ@mail.gmail.com>

On Tue, May 1, 2012 at 6:03 PM, David Miller <dmiller at tiggee.com> wrote:
> From an accounting perspective, every R&D effort that I have seen or
> been a part of was not billed to any customer. ?R&D has always, in my
> experience, been an internal charge against a company's own profits.

Hi David,

That's called "internal" research and development or "IR&D".

It's distinguished from research and prototyping as an exploratory
effort under contract to a customer. For example, all grants under
organizations like NSF, ONR or DARPA the latter type of R&D. They want
to know if something is possible so they pay knowledge domain experts
to find out. Or more commonly, the experts submit a proposal that
says, "We think this is possible. It would be very good for you if it
is. Won't you please pay us to find out?"


> As to hourly software development, I have never seen or been a part of a
> software development effort where the final work product was not owned
> by the entity paying for the hourly development. ?The contract software
> developer can't sell the same software twice because they don't own it
> to sell it twice.

That depends on the contract. By law, the folks who wrote the software
(or the company who paid their salaries) own it. By law, contract !=
salary. Some contracts specify that the copyrights and other IP will
be signed over upon completion. With most of the contracts I've
worked, the customer doesn't get the copyright, but I make no claim
that's typical.

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 alex at corp.nac.net  Tue May  1 17:46:56 2012
From: alex at corp.nac.net (Alex Rubenstein)
Date: Tue, 1 May 2012 18:46:56 -0400
Subject: CDNs should pay eyeball networks, too.
Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB815DD393B4C@EXCHMBX.hq.nac.net>

I can't agree with this. You are assuming a cost-plus model. Many things are market-priced. 

If you are the only game in town, and you have a great product, you sell it for the most you can. You aren't a charity. 

The customer always has the option to not buy your product. 






----- Original Message -----
From: Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu>
To: David Miller <dmiller at tiggee.com>
Cc: nanog at nanog.org <nanog at nanog.org>
Sent: Tue May 01 18:18:48 2012
Subject: Re: CDNs should pay eyeball networks, too.

On Tue, 01 May 2012 18:03:06 -0400, David Miller said:

> From an accounting perspective, every R&D effort that I have seen or
> been a part of was not billed to any customer.  R&D has always, in my
> experience, been an internal charge against a company's own profits.

RIght - and when pricing the result of the R&D, you take into account the
internal charges and estimated sales volume to determine a target price
point.  R&D was $316K and you estimate you can sell 100 of them, you're
going to have to charge at least $3,160 a copy to make a profit on the
project.  You sank $150M into R&D and think you'll sell a million units, you'll
need to charge $150 to break even.  And so on.

The point is that if you already got *paid* the $316K, it's morally wrong to
include it in the calculation of "sunk costs we need to recoup to turn a profit".

From marka at isc.org  Tue May  1 18:25:05 2012
From: marka at isc.org (Mark Andrews)
Date: Wed, 02 May 2012 09:25:05 +1000
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: Your message of "Tue, 01 May 2012 10:55:17 -0400."
 <CAL9jLabQg6DqfOiK-pkvo_x_iCATazJgA_3ziwaM5mn01y08cA@mail.gmail.com>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
 <1335877189.9812.17.camel@moridin>
 <CAL9jLabQg6DqfOiK-pkvo_x_iCATazJgA_3ziwaM5mn01y08cA@mail.gmail.com>
Message-ID: <20120501232505.F1C7B2053A64@drugs.dv.isc.org>


The server doesn't do PMTUD properly.   Verisign were informed of this
a while back.  How hard is it to let ICMPv6 PTB in so that PMTUD works?

% whois -h 2001:503:3227:1060::74 example.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
[stalls here forever]

The message is sent in 3 packet and you see packet 1 and 3, 2 is
lost and despite selective acks it is never seen.
-- 
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  1 19:06:27 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 1 May 2012 19:06:27 -0500
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
References: <A6E26D92FF58FD4EBFE18A27C0780F99023711AE@EXCH-DTM-01.ops.rrbone.net>
 <CAP-guGXKigR+t=gMhzd2z_Who6vTa9yWZt=0=tt16PkMF-RHKQ@mail.gmail.com>
 <90547F1A-5EC0-4500-8C74-AD9490E2BEC4@ianai.net>
Message-ID: <CAAAwwbWzzgQ5xHOHoo52h56Qfkqg8R6c=5GRDzjNv1jSM0M=YA@mail.gmail.com>

On 5/1/12, Patrick W. Gilmore <patrick at ianai.net> wrote:
> I love the fact Dominik says "from a CDN", then leaves Limelight's name in
> the text. :)
[snip]

So a CDN made the mistake of attempting to monetize an existing
peering arrangement without first having a signed peering arrangement
in place for the existing peering with a  Mutual NDA  prohibiting any
dissemination details of any of their communications/ future
negotiations/etc of peering arrangement or traffic exchanged to
unrelated third parties??

The lack of a NDA that would prohibit identifying a CDN and their
e-mail notification of depeering,  whether their name was mentioned or
not,   sounds quite  un-Tier1  like to me.

--
-JH


From Valdis.Kletnieks at vt.edu  Tue May  1 19:08:01 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 01 May 2012 20:08:01 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: Your message of "Tue, 01 May 2012 18:46:56 -0400."
 <2D0AF14BA6FB334988BC1F5D4FC38CB815DD393B4C@EXCHMBX.hq.nac.net>
References: <2D0AF14BA6FB334988BC1F5D4FC38CB815DD393B4C@EXCHMBX.hq.nac.net>
Message-ID: <32084.1335917281@turing-police.cc.vt.edu>

On Tue, 01 May 2012 18:46:56 -0400, Alex Rubenstein said:
> If you are the only game in town, and you have a great product, you sell it for the most you can.

Pay attention.  What I said:

> going to have to charge at least $3,160 a copy to make a profit on the
> project.

*at least*.  You can charge $4K, or $40K, if you think you can get away with
it. Or you can sell it for $2K, if you think you can sell 200 cheaper copies
rather than 100 expensive ones. But unless your sales price times the sales
volume is more than your sunk R&D cost, you're going to lose money on it.

(And yes, there's counter-examples. Sony did the PS/3 as a loss leader.  Which
makes my point - they *knew* that sucker was going to lose money  because there
was no price point at which the expected sales times the price was more than
what they spent in development.  Only reason they did it anyhow was because
they had a business plan to make the money elsewhere...)

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

From morrowc.lists at gmail.com  Tue May  1 20:25:55 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 1 May 2012 21:25:55 -0400
Subject: Problems getting to Verisign's whois server on IPv6
In-Reply-To: <20120501232505.F1C7B2053A64@drugs.dv.isc.org>
References: <53898EDB-D151-4792-BB0D-E7187BCB5740@oitc.com>
 <1335877189.9812.17.camel@moridin>
 <CAL9jLabQg6DqfOiK-pkvo_x_iCATazJgA_3ziwaM5mn01y08cA@mail.gmail.com>
 <20120501232505.F1C7B2053A64@drugs.dv.isc.org>
Message-ID: <CAL9jLaYsvvOfcdd23fTJPTiXNk91W17gpZLWwwUhBwKgS=wjFg@mail.gmail.com>

On Tue, May 1, 2012 at 7:25 PM, Mark Andrews <marka at isc.org> wrote:
>
> The server doesn't do PMTUD properly. ? Verisign were informed of this
> a while back. ?How hard is it to let ICMPv6 PTB in so that PMTUD works?
>
> % whois -h 2001:503:3227:1060::74 example.com
>
> Whois Server Version 2.0
>
> Domain names in the .com and .net domains can now be registered
> with many different competing registrars. Go to http://www.internic.net
> for detailed information.
> [stalls here forever]
>
> The message is sent in 3 packet and you see packet 1 and 3, 2 is
> lost and despite selective acks it is never seen.

that appears to be the case :( setting MSS to 1420 seems to work for
me (at home, on a janky tunneled setup, because you know... ipv6 is
'hard' for vz to do :( )

-chris


From rdobbins at arbor.net  Tue May  1 20:51:28 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 2 May 2012 01:51:28 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <4FA02160.1060504@riw.us>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <4FA02160.1060504@riw.us>
Message-ID: <4E444A59-6254-44D0-B5F3-EB668660A159@arbor.net>


On May 2, 2012, at 12:46 AM, Russ White wrote:

> There are situations where it won't work (mostly thinking high mobility environments, or complete system failures), but these don't seem to be big "stoppers," to me....

Within the next 10 years, everything/everywhere is going to become a 'high-mobility environment', though . . .

<https://files.me.com/roland.dobbins/c07vk1>

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From nanog-poster at axu.tm  Wed May  2 00:06:23 2012
From: nanog-poster at axu.tm (Aleksi Suhonen)
Date: Wed, 02 May 2012 08:06:23 +0300
Subject: CDNs should pay eyeball networks, too.
Message-ID: <4FA0C0CF.1010905@axu.tm>

Morning,

I have no idea what's really going on at LLNW, but I thought I'd still 
share an alternative view on this matter:

My understanding is that LLNW is spending tons of money to upgrade some 
of their IXP connections to 100GbE in Europe. With that in mind, I'm not 
that surprised if they wish to get some new income to cover those costs. 
While content is king, eye balls are kings too. Go figure.

-- 
         Aleksi Suhonen / Axu TM Oy
         Internetworking Consulting
         Cellular: +358 45 670 2048
         World Wide Web: www.axu.tm


From ssm at fnord.no  Wed May  2 03:45:16 2012
From: ssm at fnord.no (Stig Sandbeck Mathisen)
Date: Wed, 02 May 2012 10:45:16 +0200
Subject: IPv6 monitoring...
References: <ED6DC2C1A6D8774D8CB616278360334C511B5D@MAIL01.fnal.gov>
Message-ID: <7x397jgeeb.fsf@fsck.linpro.no>

Vytautas V Grigaliunas <vyto at fnal.gov> writes:

> What are people using for IPv6 monitoring - in particular, for
> monitoring services such as DNS, Web, E-mail, etc. ?
>
> Nagios seems the people's choice. Any others...open source or
> commercial ?

Open source Icinga and Nagios would work fine, and the configurations
should be (mostly) interchangable, with a notable exception.

Icinga's host object type has an "address6" paramter, which Nagios does
not have. For Nagios, a patch is available in http://goo.gl/IHkKE

https://www.icinga.org/2011/07/21/how-to-dual-stack-1pv4-ipv6-monitoring-with-icinga/
shows one way of doing dual stack monitoring of a single service, using
the "check_multi" monitoring plugin.

-- 
Stig Sandbeck Mathisen



From thomas.mangin at exa-networks.co.uk  Wed May  2 03:58:31 2012
From: thomas.mangin at exa-networks.co.uk (Thomas Mangin)
Date: Wed, 2 May 2012 09:58:31 +0100
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <4FA0C0CF.1010905@axu.tm>
References: <4FA0C0CF.1010905@axu.tm>
Message-ID: <D4F63B6B-0AF5-490C-A377-7144F4047625@exa-networks.co.uk>

I (in the UK) had the same letter from LLNW yesterday, word for word. 

When the peering was established, I had transit providers with strict peering policy (TATA/L3), now I have two with more open policy (HE/KPN). I assume LLNW now sees me via what is for them a peer, and see no financial reason to keep a direct session up.

However I must say that the wording of their letter is appalling. Even if they gave me 30 days notice to change my transit arrangement and did not terminate the session without warning, the tone of this mail is simply wrong. I am pretty sure my transit providers are seeing them via the same exchanges I do, so the traffic did, most likely, not even shift from interface. We did not have any issues of capacity and/or outage, so it is not that this change will save them much in opex costs neither. My peering ports are the same size as my transit ports, so they have gained anything in performance by shifting the traffic (and as I do not congest, did not loose anything neither though)

What it tells me is that they do not care about my business and prefer to force me to pay to reach their network (more than I was previously) via transit ... or pay more but less than transit using their "generous" pay peering offer .. I did not bother asking them what the cost was, my answer is NO. I will prefer to pay my transit provider, at least the extra capacity can be put to other use.

If ever I change back my transit provider to one they do not have favourable agreement with, I will think twice about peering again with them, or I may ask them for some pay peering to reflect their saving (no, I would not I am not that kind of scumbag).

As my traffic volume is clearly noise for them, I am sure they do not care at all. However, large rivers are all made of small streams, and all trees starts as seeds ( I am feeling zen this morning ... :D )

Thomas

I am glad they are spending ton of money to upgrade their infrastructure.. but so am I.

On 2 May 2012, at 06:06, Aleksi Suhonen wrote:

> Morning,
> 
> I have no idea what's really going on at LLNW, but I thought I'd still share an alternative view on this matter:
> 
> My understanding is that LLNW is spending tons of money to upgrade some of their IXP connections to 100GbE in Europe. With that in mind, I'm not that surprised if they wish to get some new income to cover those costs. While content is king, eye balls are kings too. Go figure.
> 
> -- 
>        Aleksi Suhonen / Axu TM Oy
>        Internetworking Consulting
>        Cellular: +358 45 670 2048
>        World Wide Web: www.axu.tm
> 



From leigh.porter at ukbroadband.com  Wed May  2 04:32:45 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 2 May 2012 09:32:45 +0000
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <D4F63B6B-0AF5-490C-A377-7144F4047625@exa-networks.co.uk>
References: <4FA0C0CF.1010905@axu.tm>
 <D4F63B6B-0AF5-490C-A377-7144F4047625@exa-networks.co.uk>
Message-ID: <D181DDABABE57E4DB72FEE0033147864546B5C@EALPO1.ukbroadband.com>


> I (in the UK) had the same letter from LLNW yesterday, word for word.

Me too.

> However I must say that the wording of their letter is appalling

Agreed.
 
> I am glad they are spending ton of money to upgrade their
> infrastructure.. but so am I.

Slightly odd though that they are upgrading their network and then de-peering everybody who takes < 1Gb/s from them.
I don't quite understand why a content DELIVERY network would want to do this.

I'm not sure who's content they deliver but this does not seem like a particularly great way to go about delivering it. 

There was a network who commented earlier in the thread that they do 600Mb/s with them, that's not an insignificant level of traffic really, especially coming from a single CDN. I wonder if this not some slightly mis-informed exec at LLNW who thought they found a great way to extract more money to deliver content that they have already been paid to deliver.

--
Leigh


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From patrick at ianai.net  Wed May  2 06:09:36 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 2 May 2012 07:09:36 -0400
Subject: CDNs should pay eyeball networks, too.
In-Reply-To: <4FA0C0CF.1010905@axu.tm>
References: <4FA0C0CF.1010905@axu.tm>
Message-ID: <CCBF0713-80D2-4A93-81A7-912C0D0A30A1@ianai.net>

On May 2, 2012, at 1:06, Aleksi Suhonen <nanog-poster at axu.tm> wrote:

> I have no idea what's really going on at LLNW, but I thought I'd still share an alternative view on this matter:
> 
> My understanding is that LLNW is spending tons of money to upgrade some of their IXP connections to 100GbE in Europe. With that in mind, I'm not that surprised if they wish to get some new income to cover those costs. While content is king, eye balls are kings too. Go figure.

Lots of networks upgrade their infrastructure.  It means they are doing more traffic, which hopefully means their business is doing well.  Very few - in fact, I can't think of a single network - start asking for paid peering just because they are upgrading their ports.  Networks either ask for paid peering, or don't, irrespective of their IX upgrade schedule.  It is based on whether they think they have power over their peers.  I guess we know how LLNW feels now.

The interesting thing to me is the reversal from previous years.  Most content providers have issues with eyeball networks saying "pay me for bits".  Content networks have historically claimed this is silly of the eyeball networks - including LLNW.  Eyeballs get paid by their customers (DSL, cable, whatever) to "reach the Internet".  Content networks pay to bring the content right to the eyeball's door.  Or so the theory goes.

This move belies that argument LLNW has made themselves in the past.   It is not about "your customer pays you, my customer pays me."  It is about who can force whom to pay (or not, as most people who have spoken up said they would not pay).

End of day, this doesn't change the way of the world.  LLNW is a big network, but compared to the whole Internet, they are relatively small.  There will be corner cases like this, and the market will decide who wins & who loses.  <insert comment about "except those with monopoly power" or some such>

-- 
TTFN,
patrick



From Jason_Livingood at cable.comcast.com  Wed May  2 09:37:23 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 2 May 2012 14:37:23 +0000
Subject: Operation Ghost Click
In-Reply-To: <20120501195117.GA19184@ussenterprise.ufp.org>
Message-ID: <CBC6BE6B.5CB79%jason_livingood@cable.comcast.com>

>Hey Jason, I'm going to put you on the spot with a crazy idea.
>
>Many customers of the major internet providers also have other
>services from them, like TV and Phone.  Perhaps expanding the notice
>to those areas would be useful?  Turn on your cable box and get a
>notice, or pick up the phone and get a notice?

We did the phone thing by dropping a voicemail to our voice customers (it
is IP voicemail so it kind of looks like an email server architecture).

Good idea on the TV notification as well and certainly not crazy! ;-)

- Jason



From mehmet at akcin.net  Wed May  2 11:05:50 2012
From: mehmet at akcin.net (Mehmet Akcin)
Date: Wed, 2 May 2012 09:05:50 -0700
Subject: NANOG 55 DNS Track
Message-ID: <796D6922-297A-4AAC-8C16-5EDB85DE1C57@akcin.net>

Hello everyone,

NANOG 55 will take place in Vancouver , Canada June 3-6 , 2012. I will send more information about DNS Track timing and details of the track later.

I am sending this email to ask NANOG attendees to help us organize a better track by letting us know what topics they want to see covered about DNS.

We are also inviting parties who are DNS Software providers,  service providers, experts, and researchers to join and present about what they think is interesting. Please contact me directly if you want to briefly bring something interesting about DNS to this Track's and their attendees attention. 

Since the whole track will be 90mins and we want to allow as much as talks to take a place it would be good idea to limit any specific talk to 15 mins and keeping it really operational , brief and clear would be great idea.

as I said earlier as soon as track details are decided,  I will send a second e-mail to let the community know. thank you for your interest.

mehmet

From nicolai-nanog at chocolatine.org  Wed May  2 12:16:40 2012
From: nicolai-nanog at chocolatine.org (Nicolai)
Date: Wed, 2 May 2012 12:16:40 -0500
Subject: Operation Ghost Click
In-Reply-To: <CAHGyo+-HvF6YJ4FtZKRsHADShHKN9VAUKiAML=rEzeJaVpLXgQ@mail.gmail.com>
References: <4F99C03A.30506@mompl.net>
 <CA+qj4S_My6SMjpgKo0jur962=TCsf94tZBsRGDPCo+ky0SgtuQ@mail.gmail.com>
 <4F99FE80.6010007@utc.edu>
 <B13238AB0CB1514B9509DEEE5F98F2E02E7C4D31@PACDCEXMB13.cable.comcast.com>
 <4F9B30B3.5090000@mompl.net> <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com>
 <3530.1335579430@turing-police.cc.vt.edu>
 <CAHGyo+8j3TNRjtmxpUeEWH5F7P84wskZcaANZsm6Kv6M_KQuXg@mail.gmail.com>
 <7292.1335585345@turing-police.cc.vt.edu>
 <CAHGyo+-HvF6YJ4FtZKRsHADShHKN9VAUKiAML=rEzeJaVpLXgQ@mail.gmail.com>
Message-ID: <20120502171640.GA25262@vectra.student.iastate.edu>

On Fri, Apr 27, 2012 at 11:14:40PM -0500, A. Pishdadi wrote:
> At some point in like 10 years when all the computer illiterate people are
> gone there will be no more excuses for not being educated on malware and
> viruses.

The "non-techies" I know would consider switching from IE to Firefox a
major change, one they think would qualify as a technical achievement.
If you ask people about the underlying technical aspects of the software
or hardware they use, most will know very little, if anything.  Some
won't even understand the question.

On a weirdly related note, here's a story from a friend of mine who is a
high school teacher.  He told me once that a significant number of his
students believe that the *original source* of food is a grocery store.
Not a farm, but the food literally comes into being on a shelf in the
produce section or meat counter.

It all comes down to a lack of interest in what's going on under the
hood, and this disinterest won't be gone in 10, 20, or 50 years.  It's
actually deepening as time goes on.

Nicolai


From jeroen at mompl.net  Wed May  2 14:13:56 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 02 May 2012 12:13:56 -0700
Subject: Operation Ghost Click
In-Reply-To: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
Message-ID: <4FA18774.7090909@mompl.net>

Livingood, Jason wrote:
> you may just have nuked their 911 capability.

Depending on your internet connection to be able to dial 911 is a bit 
foolhardy, to put it nicely. It pays off to have a phone that's only 
powered through the phone line itself, for emergencies (and your 
everyday home phone calls *gasp*). Especially in a country where power 
outages are as frequent as full moons. The good old land line hardly 
ever goes down.

And you may find the audio quality is better too. While you're at it, 
make it a rotary phone. :-)

Regards,
Jeroen

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From Valdis.Kletnieks at vt.edu  Wed May  2 14:32:38 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 02 May 2012 15:32:38 -0400
Subject: Operation Ghost Click
In-Reply-To: Your message of "Wed, 02 May 2012 12:13:56 -0700."
 <4FA18774.7090909@mompl.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
Message-ID: <61490.1335987158@turing-police.cc.vt.edu>

On Wed, 02 May 2012 12:13:56 -0700, Jeroen van Aart said:
> Livingood, Jason wrote:
> > you may just have nuked their 911 capability.

Actually, I said that, not Jason.  Jason just used mail software that *can't get
quoting right* to reply to my message, so your quote of his message got the
attribution wrong.

What *is* it with you people? This is *NANOG*. In *2012*. ;)

(The truly sad part is that based on the User-Agent: headers, Jason appears to
have used a *different* broken mail software package than the last person.  So
at least 2 vendors are doing stupid stuff.)

</rant> ;)

> Depending on your internet connection to be able to dial 911 is a bit
> foolhardy, to put it nicely.

Foolhardy or not, it's probably unwise for an ISP to say "It's OK, *nobody* would
be that foolhardy" and snip the service...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120502/12015732/attachment.bin>

From morrowc.lists at gmail.com  Wed May  2 14:43:27 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 2 May 2012 15:43:27 -0400
Subject: Operation Ghost Click
In-Reply-To: <4FA18774.7090909@mompl.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
Message-ID: <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>

On Wed, May 2, 2012 at 3:13 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
> Livingood, Jason wrote:
>>
>> you may just have nuked their 911 capability.
>
>
> Depending on your internet connection to be able to dial 911 is a bit

<chuckle>

> foolhardy, to put it nicely. It pays off to have a phone that's only powered
> through the phone line itself, for emergencies (and your everyday home phone
> calls *gasp*). Especially in a country where power outages are as frequent
> as full moons. The good old land line hardly ever goes down.

this is nice, but not everywhere has this capability, someplaces DID
have it until the new 'we bring fiber' people showed up, and clipped
the copper below the ground-level.

>
> And you may find the audio quality is better too. While you're at it, make
> it a rotary phone. :-)

wow, 1990 much? are you actually just trolling today perhaps?

> Regards,
> Jeroen
>
> --
> Earthquake Magnitude: 4.0
> Date: Wednesday, May ?2, 2012 12:33:29 UTC
> Location: Vancouver Island, Canada region
> Latitude: 50.6619; Longitude: -129.8861
> Depth: 10.00 km
>


From EWieling at nyigc.com  Wed May  2 14:52:03 2012
From: EWieling at nyigc.com (Eric Wieling)
Date: Wed, 2 May 2012 15:52:03 -0400
Subject: Operation Ghost Click
In-Reply-To: <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
Message-ID: <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>


I doubt the g729 or GSM codecs used by VoIP and Cell phones can compare to a POTS line.

-----Original Message-----
From: Christopher Morrow [mailto:morrowc.lists at gmail.com] 
Sent: Wednesday, May 02, 2012 3:43 PM
To: Jeroen van Aart
Cc: NANOG list
Subject: Re: Operation Ghost Click

wow, 1990 much? are you actually just trolling today perhaps?



From jeroen at mompl.net  Wed May  2 14:52:39 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 02 May 2012 12:52:39 -0700
Subject: Operation Ghost Click
In-Reply-To: <61490.1335987158@turing-police.cc.vt.edu>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net> <61490.1335987158@turing-police.cc.vt.edu>
Message-ID: <4FA19087.70200@mompl.net>

Valdis.Kletnieks at vt.edu wrote:
> Actually, I said that, not Jason.  Jason just used mail software that *can't get
> quoting right* to reply to my message, so your quote of his message got the
> attribution wrong.

Sorry, I don't keep track of who is unable to quote properly. But I do 
always try to make an effort to quote properly. :-)

> Foolhardy or not, it's probably unwise for an ISP to say "It's OK, *nobody* would
> be that foolhardy" and snip the service...

I am not sure about IP phones, but there are laws regulating this for 
mobile phones. So my unlocked simless android phones (I only use smart 
phones as testing tools for development) still are able to dial 911.

Regards,
Jeroen

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From sean at seanharlow.info  Wed May  2 14:57:00 2012
From: sean at seanharlow.info (Sean Harlow)
Date: Wed, 2 May 2012 15:57:00 -0400
Subject: Operation Ghost Click
In-Reply-To: <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
Message-ID: <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>

Then you'll be happy to know that most VoIP phones default to and good VoIP providers gladly support G.711, the exact same codec used in all digital trunks in the POTS network.  Also, an on-the-ball VoIP carrier will be pushing G.722 "HD Voice" devices which offer about double the audio bandwidth in the same data bandwidth (64kbit/sec/stream) as G.711.

If your carrier is forcing G.729 or GSM, they're a joke.
---
Sean Harlow
sean at seanharlow.info

On May 2, 2012, at 15:52, Eric Wieling wrote:

> 
> I doubt the g729 or GSM codecs used by VoIP and Cell phones can compare to a POTS line.
> 
> -----Original Message-----
> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] 
> Sent: Wednesday, May 02, 2012 3:43 PM
> To: Jeroen van Aart
> Cc: NANOG list
> Subject: Re: Operation Ghost Click
> 
> wow, 1990 much? are you actually just trolling today perhaps?
> 
> 



From jeroen at mompl.net  Wed May  2 14:58:16 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 02 May 2012 12:58:16 -0700
Subject: Operation Ghost Click
In-Reply-To: <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>	<4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
Message-ID: <4FA191D8.7070007@mompl.net>

Christopher Morrow wrote:
> wow, 1990 much? are you actually just trolling today perhaps?

No, what is wrong with using a land line, a rotary phone and enjoying a 
reliable service? Plus a superior audio quality as opposed to the 
compressed to hell quality of mobile phones.

Not withstanding that, according to you, in some places the landlines 
"clipped the copper below the ground-level" I believe that vast majority 
of the country has working copper phone lines that continue to work 
during a power outage.

I fail to see why you must call me a troll for saying such a thing, 
alas, maybe it can be attributed to a bad hair day.

Regards,
Jeroen

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From cmadams at hiwaay.net  Wed May  2 15:02:44 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 2 May 2012 15:02:44 -0500
Subject: Operation Ghost Click
In-Reply-To: <4FA191D8.7070007@mompl.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net>
Message-ID: <20120502200244.GH9267@hiwaay.net>

Once upon a time, Jeroen van Aart <jeroen at mompl.net> said:
> Christopher Morrow wrote:
> >wow, 1990 much? are you actually just trolling today perhaps?
> 
> No, what is wrong with using a land line, a rotary phone and enjoying a 
> reliable service? Plus a superior audio quality as opposed to the 
> compressed to hell quality of mobile phones.

As others pointed out, there are many digital codecs that are superior
to the audio quality of a rotary phone.

> Not withstanding that, according to you, in some places the landlines 
> "clipped the copper below the ground-level" I believe that vast majority 
> of the country has working copper phone lines that continue to work 
> during a power outage.

Not so much.  As has been pointed out here many times before, many
people now get POTS lines from remote cabinets that have limited battery
life and fail in a power outage lasting more than a few minutes.

-- 
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 jeroen at mompl.net  Wed May  2 15:10:28 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 02 May 2012 13:10:28 -0700
Subject: Operation Ghost Click
In-Reply-To: <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
Message-ID: <4FA194B4.2070706@mompl.net>

Sean Harlow wrote:
> Then you'll be happy to know that most VoIP phones default to and good VoIP providers gladly support G.711, the exact same codec used in all digital trunks in the POTS network.  Also, an on-the-ball VoIP carrier will be pushing G.722 "HD Voice" devices which offer about double the audio bandwidth in the same data bandwidth (64kbit/sec/stream) as G.711.

Technical specs aside I believe you are mistaken with regards to the 
actual every day reality. My experience (and anyone else I talked to) 
calling to and from mobile phones has been 100% a bad one with regards 
to audio quality. I know the bandwidth allows for better quality, but 
carriers don't do it, they do the opposite.

Why else would a mobile phone carrier feel the need to advertise an "HD" 
(shouldn't it be "HIFI"?) quality line (i.e. a quality that's standard 
with every land line and already suboptimal):

http://www.pcmag.com/article2/0,2817,2402598,00.asp

"Sprint Brings HD Voice Calls to U.S."

Whatever...

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From jared at puck.nether.net  Wed May  2 15:15:26 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 2 May 2012 16:15:26 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
Message-ID: <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>


On May 2, 2012, at 3:52 PM, Eric Wieling wrote:

> 
> I doubt the g729 or GSM codecs used by VoIP and Cell phones can compare to a POTS line.


This is why many people use g711ulaw or other codec.

Personally I would not work with anyone that doesn't do g711ulaw (88.2kbit when IP packet overhead added in).

There are other codecs such as G.722.1 & G.722.2 but the support isn't as broad as g711ulaw/alaw.

Regarding landline service, this can fail for many of the common reasons it does are the same reasons that IP service may fail.  The failure modes can depend on a variety of circumstances from the physical layer (e.g.: audible static on the line) that cause your ear to retrain, which may cause a DSL device to comparably retrain.  The same is true for shared medium such as CATV but this has other problems as well, if not well isolated, somebody can short out the segment or send garbage at the wrong channel, etc.

Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a long-distance from the CO) for something like the Verizon Home Connect box.  Gives a few hours of built-in battery backup, but would fail once the tower loses power (usually 8-12 hours).

I also am concerned about 911 service.  When dialing 911 recently from my mobile, I should have dialed it from my home phone as I was routed a few times to get to the right fire dispatch team.

Oh well.

- Jared

From morrowc.lists at gmail.com  Wed May  2 15:18:11 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 2 May 2012 16:18:11 -0400
Subject: Operation Ghost Click
In-Reply-To: <20120502200244.GH9267@hiwaay.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
Message-ID: <CAL9jLaaz1M5YgNoiEgr7NFmE9nyABnEfhWe3NTsPu6M+B6Fkiw@mail.gmail.com>

On Wed, May 2, 2012 at 4:02 PM, Chris Adams <cmadams at hiwaay.net> wrote:
> Once upon a time, Jeroen van Aart <jeroen at mompl.net> said:
>> Not withstanding that, according to you, in some places the landlines
>> "clipped the copper below the ground-level" I believe that vast majority
>> of the country has working copper phone lines that continue to work
>> during a power outage.
>
> Not so much. ?As has been pointed out here many times before, many
> people now get POTS lines from remote cabinets that have limited battery
> life and fail in a power outage lasting more than a few minutes.

yes, this.

in the last 2 neighborhoods I've lived in... near/around ashburn, va
(home to verizon, mci, lots of telco/bell-shaped-heads) I've always
been serviced from a remote terminal, that has often failed when the
power has cycled... There's a slew of places in the US where you don't
actually go all the way back to the CO on a single copper pair :(

never mind the places where the mini-co bundles you up on some
mpls/ccc/etc link ...

anyway :)


From Valdis.Kletnieks at vt.edu  Wed May  2 15:20:02 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 02 May 2012 16:20:02 -0400
Subject: Operation Ghost Click
In-Reply-To: Your message of "Wed, 02 May 2012 13:10:28 -0700."
 <4FA194B4.2070706@mompl.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
 <4FA194B4.2070706@mompl.net>
Message-ID: <64072.1335990002@turing-police.cc.vt.edu>

On Wed, 02 May 2012 13:10:28 -0700, Jeroen van Aart said:

> Technical specs aside I believe you are mistaken with regards to the
> actual every day reality. My experience (and anyone else I talked to)
> calling to and from mobile phones has been 100% a bad one with regards
> to audio quality.

I look at my Samsung cell phone, and the tiny speaker squeezed in up over the
screen at one end, and then I think of the large speakers in the handset of an
old-school Bell system rotary phone.  Then I think about the fact that my
laptop has pretty damned good sound quality when I plug in a good pair of
Kenwood KPM-410 headphones, and sounds totally crappy over the tiny built-in
speakers that Dell provided.

It may not be the codec that sucks...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120502/c0b16679/attachment.bin>

From bill at herrin.us  Wed May  2 16:33:09 2012
From: bill at herrin.us (William Herrin)
Date: Wed, 2 May 2012 17:33:09 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
Message-ID: <CAP-guGX+1C-TsZ=zMK2rWscKtbR7BnxHOA+vUNvK86sQtKZstQ@mail.gmail.com>

On 5/2/12, Jared Mauch <jared at puck.nether.net> wrote:
> Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a
> long-distance from the CO) for something like the Verizon Home Connect box.
> Gives a few hours of built-in battery backup, but would fail once the tower
> loses power (usually 8-12 hours).

Hi Jared,

Beware that the Verizon ONTs shut down all services *except* POTs when
they lose AC power. Some kind of conservation mode to maximize the
time 911 is available I guess. If you want Internet service (for VOIP)
to continue during a power outage, you'll have to stack another UPS in
front of it.

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 sean at seanharlow.info  Wed May  2 16:40:02 2012
From: sean at seanharlow.info (Sean Harlow)
Date: Wed, 2 May 2012 17:40:02 -0400
Subject: VoIP/Mobile Codecs (was Re: Operation Ghost Click)
In-Reply-To: <4FA194B4.2070706@mompl.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
 <4FA194B4.2070706@mompl.net>
Message-ID: <B9ACFA3F-EC1F-4F2E-B0AA-F2D0B539DF71@seanharlow.info>

On May 2, 2012, at 16:10, Jeroen van Aart wrote:

> Technical specs aside I believe you are mistaken with regards to the actual every day reality. My experience (and anyone else I talked to) calling to and from mobile phones has been 100% a bad one with regards to audio quality. I know the bandwidth allows for better quality, but carriers don't do it, they do the opposite.
> 
> Why else would a mobile phone carrier feel the need to advertise an "HD" (shouldn't it be "HIFI"?) quality line (i.e. a quality that's standard with every land line and already suboptimal):
> 
> http://www.pcmag.com/article2/0,2817,2402598,00.asp
> 
> "Sprint Brings HD Voice Calls to U.S."

Originally, you said VoIP and cellular used bad codecs.  I responded that any decent VoIP provider supports codecs equaling or beating landlines.  I didn't say anything about cellular.  A G.711 call over a solid internet connection will sound entirely identical to any landline telephone call that leaves the local analog facilities and a G.722 call will make G.711 and thus landlines sound like cellular by comparison.

The cellular world works with less bandwidth and more loss than the VoIP world usually deals with, so while us VoIP guys sometimes use their codecs (GSM for example) they don't tend to bother with ours.  That said, the article you link is talking about the same sort of improvements by doubling the sampling rate, so the end result is similar.
---
Sean Harlow
sean at seanharlow.info



From jared at puck.nether.net  Wed May  2 17:00:16 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 2 May 2012 18:00:16 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <CAP-guGX+1C-TsZ=zMK2rWscKtbR7BnxHOA+vUNvK86sQtKZstQ@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <CAP-guGX+1C-TsZ=zMK2rWscKtbR7BnxHOA+vUNvK86sQtKZstQ@mail.gmail.com>
Message-ID: <039A8689-3879-4C1D-8B61-A849C94F4D5D@puck.nether.net>

This device uses cellular only. Don't live in vz territory. Live in AT&T pots only land. No cable here either. 

Jared Mauch

On May 2, 2012, at 5:33 PM, William Herrin <bill at herrin.us> wrote:

> On 5/2/12, Jared Mauch <jared at puck.nether.net> wrote:
>> Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a
>> long-distance from the CO) for something like the Verizon Home Connect box.
>> Gives a few hours of built-in battery backup, but would fail once the tower
>> loses power (usually 8-12 hours).
> 
> Hi Jared,
> 
> Beware that the Verizon ONTs shut down all services *except* POTs when
> they lose AC power. Some kind of conservation mode to maximize the
> time 911 is available I guess. If you want Internet service (for VOIP)
> to continue during a power outage, you'll have to stack another UPS in
> front of it.
> 
> 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 jeroen at mompl.net  Wed May  2 18:36:17 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 02 May 2012 16:36:17 -0700
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
Message-ID: <4FA1C4F1.8070909@mompl.net>

Jared Mauch wrote:
> Regarding landline service, this can fail for many of the common reasons it does are the same reasons that IP service may fail.  The failure modes can depend on a variety of circumstances from the physical layer (e.g.: audible static on the line) that cause your ear to retrain, which may cause a DSL device to comparably retrain.  The same is true for shared medium such as CATV but this has other problems as well, if not well isolated, somebody can short out the segment or send garbage at the wrong channel, etc.

I don't doubt it. However my practical experience is such that 100% of 
the time (I lost count after 20 or so, in a decade) I experienced a 
power failure the phone would still work. I am sure I am not the only one.

And these concern power outages in various locations, from the mountains 
of Coastal Oregon to the Monterey Bay Area. And from trees falling over 
the power lines to exploding transformers (two at once actually :-).

I guess the phone companies just do a better job at keeping up their 
infrastructure. I don't know how often the phone cable is buried 
compared to where the power cables are exposed to the elements. But I 
would think that (more frequently) burying the phone cables is one 
reason it's more reliable.

That's why (burying cables) in the Netherlands you would get a power 
outage maybe once or twice a decade as opposed to every fortnight.

Greetings,
Jeroen

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From jeroen at mompl.net  Wed May  2 18:39:48 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 02 May 2012 16:39:48 -0700
Subject: VoIP/Mobile Codecs (was Re: Operation Ghost Click)
In-Reply-To: <B9ACFA3F-EC1F-4F2E-B0AA-F2D0B539DF71@seanharlow.info>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
 <4FA194B4.2070706@mompl.net>
 <B9ACFA3F-EC1F-4F2E-B0AA-F2D0B539DF71@seanharlow.info>
Message-ID: <4FA1C5C4.1060902@mompl.net>

Sean Harlow wrote:
> Originally, you said VoIP and cellular used bad codecs.  

Yeah, I overlooked that important detail, sorry.

> The cellular world works with less bandwidth and more loss than the VoIP world usually deals with, so while us VoIP guys sometimes use their codecs (GSM for example) they don't tend to bother with ours. 

Agreed.

> That said, the article you link is talking about the same sort of improvements by doubling the sampling rate, so the end result is similar.

Yes, but it shouldn't be necessary to offer these "HD" services as an 
extra. It should be standard.

Greetings,
Jeroen

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From jra at baylink.com  Wed May  2 19:25:00 2012
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 2 May 2012 20:25:00 -0400 (EDT)
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <4FA1C4F1.8070909@mompl.net>
Message-ID: <27645543.1870.1336004700231.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeroen van Aart" <jeroen at mompl.net>

> I don't doubt it. However my practical experience is such that 100% of
> the time (I lost count after 20 or so, in a decade) I experienced a
> power failure the phone would still work. I am sure I am not the only
> one.

Sure.  (We're not really having this conversation here, are we? :-)

Copper POTS service is centrally powered from a battery plant in the wire
center, which is generally something like -52V nominal at 6000-8000ADC 
continuous.

If you get a tool across those busbars uninsulated, it will flash into
plasma much faster than you can blink; this happened at SPBGFLXA89H in
the... mid to late 80s?  I no longer remember the details, but the guy
couldn't hear for several days, and the *entire* CO -- 30klines of GTD-5
and 100klines of 5E Remote -- was No Dial Tone for at least 12 hours
while they cleaned it up; SPPD and PCSO were stationed on streetcorners
to take emergency reports.

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 joe at nethead.com  Wed May  2 19:40:51 2012
From: joe at nethead.com (Joe Hamelin)
Date: Wed, 2 May 2012 17:40:51 -0700
Subject: Operation Ghost Click
In-Reply-To: <64072.1335990002@turing-police.cc.vt.edu>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
 <4FA194B4.2070706@mompl.net>
 <64072.1335990002@turing-police.cc.vt.edu>
Message-ID: <CAO0-hXaoZO3t4dXzRMKdpZWVU5FQ_kzY16m=su-nmEVvU0Btyg@mail.gmail.com>

On Wed, May 2, 2012 at 1:20 PM, <Valdis.Kletnieks at vt.edu> wrote:
> It may not be the codec that sucks...

Yeah, it is.  Sit on hold with some music that is at a low volume and
you'll hear part that turn into white noise at times.  Mobile operators us
codecs that are tuned for human voice.  Get sounds away from voice and they
turn to mush.  Back in a past life when I was a broadcast engineer we would
use dial-up lines for remotes.  If the remote was in the same CO and it was
an analog (mechanical) office we could get 8-10kHz audio through a pair,
and flat if we used a bit of equalization.  S/N was good enough to play
records for an AM station.  Of course, now in the day of cell phones the
term "broadcast quality" has lost all meaning. Field reporters using cell
phones for live broadcast!  There is a reason that the FCC set aside 30kHz
channels for electronic news gathering (ENG.)  At least some stations still
order up ISDN lines for remotes.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From jra at baylink.com  Wed May  2 20:11:24 2012
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 2 May 2012 21:11:24 -0400 (EDT)
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <64072.1335990002@turing-police.cc.vt.edu>
Message-ID: <15844322.1874.1336007484252.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> On Wed, 02 May 2012 13:10:28 -0700, Jeroen van Aart said:
> > Technical specs aside I believe you are mistaken with regards to the
> > actual every day reality. My experience (and anyone else I talked to)
> > calling to and from mobile phones has been 100% a bad one with regards
> > to audio quality.
> 
> I look at my Samsung cell phone, and the tiny speaker squeezed in up over the
> screen at one end, and then I think of the large speakers in the handset of an
> old-school Bell system rotary phone. Then I think about the fact that my
> laptop has pretty damned good sound quality when I plug in a good pair of
> Kenwood KPM-410 headphones, and sounds totally crappy over the tiny built-in
> speakers that Dell provided.
> 
> It may not be the codec that sucks...

Right.

Me and my business partner have both spent quite a number of years involved
with sound reinforcement and other types of audio engineering, and we're 
therefore better positioned to evaluate the transmit and receive audio of
various communications channels and physical interfaces there to.

It is *often* the analog components and housing that make things sound
suboptimal, and if you need proof of this, I call to your attention some
NPR phoners which are done with gear like the JK Audio BlueDriver 3, and
broadcast microphones.  It's possible to get to within about 47% or so of
the sampling rate of the codec using gear like that, and it's pretty easy
(for a sound guy) to spot that combination in a live broadcast.

It's also worth noting that even if the recording format is VHS, it's very
easy to discern the difference between consumer cameras, pro SDTV, and pro
HDTV, in looking at the playback signal -- the differences are subtle, but
they are identifiable.

Now, those codecs *are* specially tuned for spoken word -- if you try
to stuff music down them, it's not gonna work very well at all...

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 frnkblk at iname.com  Wed May  2 20:42:51 2012
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 2 May 2012 20:42:51 -0500
Subject: Operation Ghost Click
In-Reply-To: <20120502200244.GH9267@hiwaay.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
Message-ID: <00c301cd28ce$0d48eef0$27daccd0$@iname.com>

Many states have regulations regarding how long dial tone needs to last
during a power outage.  Iowa's PUC (the IUB) requires at least two hours of
backup power.  We design ours for eight hours.

Frank

-----Original Message-----
From: Chris Adams [mailto:cmadams at hiwaay.net] 
Sent: Wednesday, May 02, 2012 3:03 PM
To: NANOG list
Subject: Re: Operation Ghost Click

<snip>

Not so much.  As has been pointed out here many times before, many
people now get POTS lines from remote cabinets that have limited battery
life and fail in a power outage lasting more than a few minutes.

-- 
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 cmadams at hiwaay.net  Wed May  2 20:44:02 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 2 May 2012 20:44:02 -0500
Subject: Operation Ghost Click
In-Reply-To: <CAL9jLaaz1M5YgNoiEgr7NFmE9nyABnEfhWe3NTsPu6M+B6Fkiw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <CAL9jLaaz1M5YgNoiEgr7NFmE9nyABnEfhWe3NTsPu6M+B6Fkiw@mail.gmail.com>
Message-ID: <20120503014402.GG13290@hiwaay.net>

Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
> in the last 2 neighborhoods I've lived in... near/around ashburn, va
> (home to verizon, mci, lots of telco/bell-shaped-heads) I've always
> been serviced from a remote terminal, that has often failed when the
> power has cycled... There's a slew of places in the US where you don't
> actually go all the way back to the CO on a single copper pair :(

Here in Huntsville, AL, I'm not sure if BellSouth/AT&T has anybody left
on copper.  They rolled out a lot of fiber in the 1990s, slowed down for
the merger, and then picked back up.

Just over a year ago, the whole area lost power when tornadoes nearly
hit the nearby nuclear plant and took out a majority of the high-voltage
transmission lines and towers.  Over the hours after the power failed,
my DSL died, then POTS dialtone died, and then cell service died.
Suprisingly my cable TV stayed working the longest.  My cell phone also
returned to service first.

-- 
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 jared at puck.nether.net  Wed May  2 22:29:19 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 2 May 2012 23:29:19 -0400
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
Message-ID: <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>


On May 2, 2012, at 9:42 PM, Frank Bulk wrote:

> Many states have regulations regarding how long dial tone needs to last
> during a power outage.  Iowa's PUC (the IUB) requires at least two hours of
> backup power.  We design ours for eight hours.

One thing of note that I've been tracking is this:

http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-becoming-obsolete/54321184/1

I'm somewhat dubious about the following claims on the part of the carrier.  This is a carrier that wants to meter your cellular data but provides wifi service inferior to the cellular data to "offload" their wireless network.

-- snip --
"Bill sponsors and phone companies including AT&T say deregulating land-line phone service will increase competition and allow carriers to invest in better technology rather than expand a dying service. Some consumer organizations fear the change will hurt affordable service, especially in rural areas."
-- snip --

- Jared

From nathan at atlasnetworks.us  Wed May  2 23:00:07 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 3 May 2012 04:00:07 +0000
Subject: Network diagram app that shows realtime link utilizatin
Message-ID: <BF445C95-79DD-4BF2-95DE-71B5A7E28C78@atlasnetworks.us>

Php network weathermap works well for me.  The configuration language is pretty straightforward, and it's easy to consume data from either the usual suspects (mrtg), or to write a plugin that uses a custom (sql or other) datasource.

This gets you within 60 seconds of realtime, and the price (time) is right.

Nathan Eisenberg
Sent from my HTC on the Now Network from Sprint!

----- Reply message -----
From: "Hank Disuko" <gourmetcisco at hotmail.com>
Date: Tue, May 1, 2012 9:42 am
Subject: Network diagram app that shows realtime link utilizatin
To: "NANOG" <nanog at nanog.org>



Hi folks,

I wonder if anyone can recommend a network diagram tool that can show realtime link utilization via snmp?

Mikrotik's "The Dude" app actually does exactly what I'm looking for, but the snmp support for non-RouterOS devices seems to be lacking, as it simply won't enumerate my switch interfaces in order to capture utilization.

I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds LANsurveyor etc.) but they don't serve this very basic need of mine to see the realtime link util in the diagram.

Thanks,
Hank Disuko



From ghira at mistral.co.uk  Wed May  2 23:35:13 2012
From: ghira at mistral.co.uk (Adam Atkinson)
Date: Thu, 03 May 2012 05:35:13 +0100
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <15844322.1874.1336007484252.JavaMail.root@benjamin.baylink.com>
References: <15844322.1874.1336007484252.JavaMail.root@benjamin.baylink.com>
Message-ID: <4FA20B01.2010204@mistral.co.uk>

Jay Ashworth wrote:

> Now, those codecs *are* specially tuned for spoken word -- if you try
> to stuff music down them, it's not gonna work very well at all...

It was claimed to me many years ago that the 4kHz cutoff used in POTS 
serves women and children less well than it does adult males. I have
never been aware that I have any greater problems understanding women or 
children on the phone than I do men, but my hearing is not great. I 
can't hear the difference between G.711 and G.729, for example, but some 
people can.

Googling "PCM adult male voice", "4kHz adult male" and similar isn't 
finding me anything. Was I told nonsense?


From michiel at klaver.it  Thu May  3 01:39:48 2012
From: michiel at klaver.it (Michiel Klaver)
Date: Thu, 03 May 2012 08:39:48 +0200
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
References: <BLU156-W155C7050B4DB40D9C06D53C9290@phx.gbl>
Message-ID: <4FA22834.6060005@klaver.it>

At 01-05-2012 18:41, Hank Disuko wrote:
> Hi folks, 
> 
> I wonder if anyone can recommend a network diagram tool that can show realtime link utilization via snmp?
> 

Guess Observium is really up to your alley :)
www.observium.org


From bonomi at mail.r-bonomi.com  Thu May  3 03:29:26 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 3 May 2012 03:29:26 -0500 (CDT)
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <4FA20B01.2010204@mistral.co.uk>
Message-ID: <201205030829.q438TQgM021978@mail.r-bonomi.com>

Adam Atkinson <ghira at mistral.co.uk> wrote;
> Jay Ashworth wrote:
> > Now, those codecs *are* specially tuned for spoken word -- if you try
> > to stuff music down them, it's not gonna work very well at all...
>
> It was claimed to me many years ago that the 4kHz cutoff used in POTS 
> serves women and children less well than it does adult males. I have
> never been aware that I have any greater problems understanding women or 
> children on the phone than I do men, but my hearing is not great. I 
> can't hear the difference between G.711 and G.729, for example, but some 
> people can.
>
> Googling "PCM adult male voice", "4kHz adult male" and similar isn't 
> finding me anything. Was I told nonsense?


Probably.  "sort of."  <grin>

'Way back when', at least in the U.S., the 'voice' passband was 300-3000Hz. 
Later, 300-3300Hz.

For perspective, rf you know anything about music, the 'A' below "Middle C' 
is nominally 440Hz.  300Hz is roughly an octave below Middle C, and 3kHz is
2-1/2 octaves above it.  That's the -high- end of the range for a piccolo, 
or coloratura Soprano.  Now, absent the overtones that give a note it's 
'color', one of those high-pitch sources will sound more than a little bit 
'tinny' over a classical 'voice passband' channel.

*HOWEVER*, the 'fundamental' frequencies for womens/childrens voices -is-
higher than that of adult males.  But you're talking less than an octave
in 'most' cases.  Less than 2 in 'extreme' (a guy with a _deep- bass voice
-- "basso profundo", and a 'squeaky' female/child) cases.  This mean that
one does lose one to two additional 'overtones' of the fundamental on 
women/children, vs.  men. 

This does, in general, *NOT* materially affect the 'intelligibility' of
the voice, although it does have a measurable adverse effect on the 
'identifiability' of one such higher-pitched voice vis-a-vis a different
similarly-pitched voice.  You lose more of the 'color' of their voices
vs the lower-pitched male voice.





From jwbensley at gmail.com  Thu May  3 04:28:33 2012
From: jwbensley at gmail.com (James Bensley)
Date: Thu, 3 May 2012 10:28:33 +0100
Subject: Peering in Brazil
Message-ID: <CAAWx_pV50AFC8arcJ+kJXN-3Wxnzb=7YN3=ywSxkZTNRxJL0iQ@mail.gmail.com>

Hi all,

I have posted this to the LacNOG list but it seems pretty quite and it
involves North America also, so I hope no one minds me reposting here
also;

I am looking for any guidance and advice people have regarding first
time peerings in South America. Currently I am doing some work with a
content provider in North America and I want to get them better
routers into South America, to South American ISPs. I am looking to
get them an interconnect from their NA location to SA, into a PTT IX
location in Sao Paulo (they seem to be up there for top IXs in SA, or
am I mistaken?).

I'm new to the PTT IXs so does anyone have any recommendations about
any aspect here, support horror stories, reason to prefer one location
for peering over another etc? I see Level3 are in the PTT Sao Paulo
location, and we have access to Level 3 already. Is there someone else
I should be looking at who is especially good at private routes down
to SA, enough to digress from Level 3, or are Level 3 a good choice
here? Again, any past experiences are welcome, and recommendations for
a different IX or provider any why.

Many thanks,
James.


From rubensk at gmail.com  Thu May  3 06:18:05 2012
From: rubensk at gmail.com (Rubens Kuhl)
Date: Thu, 3 May 2012 08:18:05 -0300
Subject: [lacnog] Peering in Brazil
In-Reply-To: <CAAWx_pVAQOHH7i6UdG56Nkr7BeDExab+UpRTOq8M3+BjOytazg@mail.gmail.com>
References: <CAAWx_pVAQOHH7i6UdG56Nkr7BeDExab+UpRTOq8M3+BjOytazg@mail.gmail.com>
Message-ID: <CAGFn2k07k1vVOXfaTYnr-ghy7=4dmgpp33x+50-nRa501gxo_g@mail.gmail.com>

> I am looking for any guidance and advice people have regarding first
> time peerings in South America. Currently I am doing some work with a
> content provider in North America and I want to get them better
> routers into South America, to South American ISPs. I am looking to
> get them an interconnect from their NA location to SA, into a PTT IX
> location in Sao Paulo (they seem to be up there for top IXs in SA, or
> am I mistaken?).

First a clarification: PTT stands for "traffic exchange point" in
Portuguese, so people familiar with this acronym related to telco
companies or mobile/

http://ptt.br will only give you routes to Brazil, so you would still
need other locations to reach other south american countries.
If the content provider is already at Miami NOTA (Nap of The
Americas), it's already at one of the best locations to be to reach
all South America, but with if a latency penalty.

> I'm new to the PTT IXs so does anyone have any recommendations about
> any aspect here, support horror stories, reason to prefer one location
> for peering over another etc? I see Level3 are in the PTT Sao Paulo
> location, and we have access to Level 3 already. Is there someone else
> I should be looking at who is especially good at private routes down
> to SA, enough to digress from Level 3, or are Level 3 a good choice
> here? Again, any past experiences are welcome, and recommendations for
> a different IX or provider any why.

PTT.br is a Layer-2 traffic exchange with route-servers, so you need
either to colo a router here and back-haul your traffic (preferred
solution) or to contract a lan-2-lan over MPLS circuit from a
provider. Level 3 is probably your best bet, but one other option
could be the BrT/Oi facility where Globenet (http://globenet.net/) has
its Sao Paulo POP. You would probably prefer to deal with Globenet and
have them hire colo and cross-connect from their sister company
(Globenet is part of the Oi group).

The only fiber cables with available capacity to get to South America
are the ones from Level 3, Globenet and Telef?nica, but Telef?nica
International is not a PTT.br location (although being a member and
provide transit services) and Telef?nica Brazil is so not helpful for
such services. LANautilus has some capacity swap with Level 3 as well.

In short: if you will be installing a router here but not servers,
Level 3 (#1) or Globenet (#2). If you are not installing anything,
Telef?nica and LANautilus are also choices.

If you would be sending a CDN node with servers and will only need
Internet uplink, then you have more choices, but that's not my reading
of your strategy, am I right ?

Disclaimer: I work for the organization who maintains PTT.br.


Rubens


From ralph.brandt at pateam.com  Thu May  3 09:59:47 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 10:59:47 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>

"I also am concerned about 911 service.  When dialing 911 recently from
my mobile, I should have dialed it from my home phone as I was routed a
few times to get to the right fire dispatch team."

I am a "second responder", a member of a Search and Rescue team.  The
reason for "second" is because we are not generally called till other
agencies have tried to find the person. Hazmat falls into the same
category because they are not generally called till another agency sees
the situation and rolls them.  I am also an COML (Communications Leader
- IS-300 is a pre-req for this.) and a member of the South Central (PA)
Task Force AWG.   

I am frightened about the availability of anything that falls into the
category of "emergency services".  

In PA most of the fire services are volunteer.  Funding for everything
is being cut at almost every level.  The 911 hysteria that brought
massive money, some of which was squandered, is over and now it is the
shoe string.  Our SAR team operates on a budget of $2,700 a year, yes,
TWENTY SEVEN HUNDRED DOLLARS. Our team members supply their radios,
clothing, boots, etc and the gas and transportation to searches and
training. Although others get significant dollars it is never enough
even for the most frugal companies and quite frankly, the York,
Lancaster and Lebanon Counties in PA are hard headed Dutchmen
Conservatives that generally get the most out of a buck.

That issue aside a second issue is rampant in the area.  More and more
the Emergency Operations Centers are going to VOIP.  The internet is not
that reliable!  I am not aware of a 911 that has gone to VOIP but
pricing is dictating a look at this.  

During a Peach Bottom (nuclear power plant - one of our two in the area
- the other is Three Mile Island) several of the EOC's lost phone, FAX
and radio connectivity (repeater failures) to County EOC because of
thunderstorms and tornados that blew in during the drill.  The ham radio
operators at these EOC's and County provided communications to the sites
for both the drill and live events. They happened to be on site for the
drill. The site I was at was vacated except the hams, the government
evaluators and the public works guy because of a fire, all of the other
players in the EOC including the EMC were firemen!  A lack of volunteers
means people wear multiple hats. 

But let's get to the big item.  When the bad day comes, cellular is
worthless.  I was at work the day of the earthquake in Virginia, a
couple hundred miles south of us.  The ground shook and some masonry
buildings in the area sustained cracks that needed to be repaired.  Ten
minutes after the quake cellular was either useless or had up to fifteen
minute waits to place a call.  Everyone was on discussing the quake.
And cellular company pronouncements aside, it isn't going to get better,
even if they get more bandwidth that will be eaten up in 2-4 years. The
total migration to cellular, the unlimited use, the tendency for people
to yack when a bad day comes all makes for a disaster.  We need
solutions, not cell company hype, not government catering to special
interests, but real solutions that fix problems without introducing
more. 

One of the first things cellular companies can do is stop overselling
cellular.  The second is end or raise the price significantly on
unlimited plans, both voice and data.  Go to what the landlines called,
USS, that is you pay for every minute....  Even if that charge is small,
it will drive usage down.

Otherwise on a bad day people will die waiting for the yackers to get
off the call phone so they can call 911.  Hopefully it will not be on
VOIP and the internet is down.


Ralph Brandt

-----Original Message-----
From: Jared Mauch [mailto:jared at puck.nether.net] 
Sent: Wednesday, May 02, 2012 4:15 PM
To: Eric Wieling
Cc: NANOG list
Subject: VoIP vs POTS (was Re: Operation Ghost Click)


On May 2, 2012, at 3:52 PM, Eric Wieling wrote:

> 
> I doubt the g729 or GSM codecs used by VoIP and Cell phones can
compare to a POTS line.


This is why many people use g711ulaw or other codec.

Personally I would not work with anyone that doesn't do g711ulaw
(88.2kbit when IP packet overhead added in).

There are other codecs such as G.722.1 & G.722.2 but the support isn't
as broad as g711ulaw/alaw.

Regarding landline service, this can fail for many of the common reasons
it does are the same reasons that IP service may fail.  The failure
modes can depend on a variety of circumstances from the physical layer
(e.g.: audible static on the line) that cause your ear to retrain, which
may cause a DSL device to comparably retrain.  The same is true for
shared medium such as CATV but this has other problems as well, if not
well isolated, somebody can short out the segment or send garbage at the
wrong channel, etc.

Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a
long-distance from the CO) for something like the Verizon Home Connect
box.  Gives a few hours of built-in battery backup, but would fail once
the tower loses power (usually 8-12 hours).

I also am concerned about 911 service.  When dialing 911 recently from
my mobile, I should have dialed it from my home phone as I was routed a
few times to get to the right fire dispatch team.

Oh well.

- Jared


From jra at baylink.com  Thu May  3 10:01:01 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 3 May 2012 11:01:01 -0400 (EDT)
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <4FA20B01.2010204@mistral.co.uk>
Message-ID: <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Adam Atkinson" <ghira at mistral.co.uk>

> Jay Ashworth wrote:
> > Now, those codecs *are* specially tuned for spoken word -- if you
> > try to stuff music down them, it's not gonna work very well at all...
> 
> It was claimed to me many years ago that the 4kHz cutoff used in POTS
> serves women and children less well than it does adult males. I have
> never been aware that I have any greater problems understanding women
> or children on the phone than I do men, but my hearing is not great. I
> can't hear the difference between G.711 and G.729, for example, but
> some people can.
> 
> Googling "PCM adult male voice", "4kHz adult male" and similar isn't
> finding me anything. Was I told nonsense?

No, you weren't.  A 4khz channel is generally good from 3-400hz up to about
3.4khz, and if you look at spectrograms of the various categories of voices
you can see the differences, though they're not always as clear cut as you
might expect:

http://www.dplay.com/tutorial/bands/index.html

In general, though, intelligibility comes from the higher frequencies,
and 3.4kHz is *usually* high enough.  What might be the case is that you'd 
have more trouble *distinguishing* amongst women, or between women and 
children, because the tones necessary for that are more located above the
cutoff frequency.

In short: it depends a lot on what you mean by 'serves well'.  :-)

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 ralph.brandt at pateam.com  Thu May  3 10:06:39 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 11:06:39 -0400
Subject: VoIP/Mobile Codecs (was Re: Operation Ghost Click)
In-Reply-To: <4FA1C5C4.1060902@mompl.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <0081E48B-FBE2-47D6-ABBD-B3C63FBDDD73@seanharlow.info>
 <4FA194B4.2070706@mompl.net>
 <B9ACFA3F-EC1F-4F2E-B0AA-F2D0B539DF71@seanharlow.info>
 <4FA1C5C4.1060902@mompl.net>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECCF8@embgsr24.pateam.com>

I am not worried about the voice quality as long as it is understandable.  What I am concerned about is, "Can someone who needs help get through?



Ralph Brandt


-----Original Message-----
From: Jeroen van Aart [mailto:jeroen at mompl.net] 
Sent: Wednesday, May 02, 2012 7:40 PM
To: NANOG list
Subject: Re: VoIP/Mobile Codecs (was Re: Operation Ghost Click)

Sean Harlow wrote:
> Originally, you said VoIP and cellular used bad codecs.  

Yeah, I overlooked that important detail, sorry.

> The cellular world works with less bandwidth and more loss than the VoIP world usually deals with, so while us VoIP guys sometimes use their codecs (GSM for example) they don't tend to bother with ours. 

Agreed.

> That said, the article you link is talking about the same sort of improvements by doubling the sampling rate, so the end result is similar.

Yes, but it shouldn't be necessary to offer these "HD" services as an 
extra. It should be standard.

Greetings,
Jeroen

-- 
Earthquake Magnitude: 4.0
Date: Wednesday, May  2, 2012 12:33:29 UTC
Location: Vancouver Island, Canada region
Latitude: 50.6619; Longitude: -129.8861
Depth: 10.00 km


From somasundaram.s at alcatel-lucent.com  Thu May  3 10:07:24 2012
From: somasundaram.s at alcatel-lucent.com (S, Somasundaram (Somasundaram))
Date: Thu, 3 May 2012 20:37:24 +0530
Subject: NUD- ipV6.
Message-ID: <7E79416ABDDDFC4E8C85571D0B5CAB3F1390732486@INBANSXCHMBSA1.in.alcatel-lucent.com>

Hi Everyone,
        Would like to hear from you on the significance of IPV6 "Neighbor Unreachability detection (NUD)" specifically on the Router-Router link. While quick failure detection protocols like BFD are already present to detect the liveliness of the neighbor, does the providers/operators find NUD to be useful?

Rgds/
Somasundaram

From ralph.brandt at pateam.com  Thu May  3 10:14:42 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 11:14:42 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <27645543.1870.1336004700231.JavaMail.root@benjamin.baylink.com>
References: <4FA1C4F1.8070909@mompl.net>
 <27645543.1870.1336004700231.JavaMail.root@benjamin.baylink.com>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECCFC@embgsr24.pateam.com>

Yes, those things happen.  But there are several such failure points in the POTS system and hundreds in VOIP.  I support VOIP, ISDN etc.  But I know all too well the failure points...

Ralph Brandt

-----Original Message-----
From: Jay Ashworth [mailto:jra at baylink.com] 
Sent: Wednesday, May 02, 2012 8:25 PM
To: NANOG
Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)

----- Original Message -----
> From: "Jeroen van Aart" <jeroen at mompl.net>

> I don't doubt it. However my practical experience is such that 100% of
> the time (I lost count after 20 or so, in a decade) I experienced a
> power failure the phone would still work. I am sure I am not the only
> one.

Sure.  (We're not really having this conversation here, are we? :-)

Copper POTS service is centrally powered from a battery plant in the wire
center, which is generally something like -52V nominal at 6000-8000ADC 
continuous.

If you get a tool across those busbars uninsulated, it will flash into
plasma much faster than you can blink; this happened at SPBGFLXA89H in
the... mid to late 80s?  I no longer remember the details, but the guy
couldn't hear for several days, and the *entire* CO -- 30klines of GTD-5
and 100klines of 5E Remote -- was No Dial Tone for at least 12 hours
while they cleaned it up; SPPD and PCSO were stationed on streetcorners
to take emergency reports.

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 oscar.vives at gmail.com  Thu May  3 10:15:05 2012
From: oscar.vives at gmail.com (Tei)
Date: Thu, 3 May 2012 17:15:05 +0200
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
Message-ID: <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>

Perhaps cell towers can be made to fail sooner, and enter some
emergency mode where only 911 calls get service.



--
--
?in del ?ensaje.


From ralph.brandt at pateam.com  Thu May  3 10:17:15 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 11:17:15 -0400
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>

Connecticut has such a bill pending. My suggestion to people there, Get
a ham radio license and a 2 meter transceiver with a  car adapter.......




Ralph Brandt
York PA


-----Original Message-----
From: Jared Mauch [mailto:jared at puck.nether.net] 
Sent: Wednesday, May 02, 2012 11:29 PM
To: Frank Bulk
Cc: NANOG list
Subject: POTS Ending (Re: Operation Ghost Click)


On May 2, 2012, at 9:42 PM, Frank Bulk wrote:

> Many states have regulations regarding how long dial tone needs to
last
> during a power outage.  Iowa's PUC (the IUB) requires at least two
hours of
> backup power.  We design ours for eight hours.

One thing of note that I've been tracking is this:

http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-be
coming-obsolete/54321184/1

I'm somewhat dubious about the following claims on the part of the
carrier.  This is a carrier that wants to meter your cellular data but
provides wifi service inferior to the cellular data to "offload" their
wireless network.

-- snip --
"Bill sponsors and phone companies including AT&T say deregulating
land-line phone service will increase competition and allow carriers to
invest in better technology rather than expand a dying service. Some
consumer organizations fear the change will hurt affordable service,
especially in rural areas."
-- snip --

- Jared


From jra at baylink.com  Thu May  3 10:24:07 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 3 May 2012 11:24:07 -0400 (EDT)
Subject: The Compexity Factor (was VoIP v POTS)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECCFC@embgsr24.pateam.com>
Message-ID: <28391289.2018.1336058647596.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ralph Brandt" <ralph.brandt at pateam.com>

> Yes, those things happen. But there are several such failure points in
> the POTS system and hundreds in VOIP. I support VOIP, ISDN etc. But I
> know all too well the failure points...

And here, Ralph puts his finger on what has always been my number one 
concern about the Internet, as cool as it is:

The likelihood of a system's failure (and indeed, it's lack of complete
use) is proportional to -- not solely, but prominentl -- its systemic 
complexity.

There really isn't much that can fail in a current day copper POTS install,
or more to the point: much that *does* fail.  There are probably an order
of magnitude or two more places that a VoIP residential phone line can stop working.

Sure, you get more capability, but does that outweigh the reliability 
you lose?

My answer is Not Always.

Alas, I don't make those decisions.

The same process has affected other disciplines; most notably (for me)
photography: tried to buy a roll of 35mm ultraviolet film lately?  Locally?

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 Valdis.Kletnieks at vt.edu  Thu May  3 10:33:07 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 03 May 2012 11:33:07 -0400
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: Your message of "Thu, 03 May 2012 11:01:01 -0400."
 <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>
References: <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>
Message-ID: <10329.1336059187@turing-police.cc.vt.edu>

On Thu, 03 May 2012 11:01:01 -0400, Jay Ashworth said:

> In general, though, intelligibility comes from the higher frequencies,
> and 3.4kHz is *usually* high enough.  What might be the case is that you'd
> have more trouble *distinguishing* amongst women, or between women and
> children, because the tones necessary for that are more located above the
> cutoff frequency.

I have had more than a few surreal conversations on the phone with my
daughter - once the 3.4kHz filter gets done, I can't distinguish her voice from
her mom's (and yes, I've gotten social-engineered as a result).  Life has
gotten simpler since she got old enough to have her own cell phone. ;)

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

From eyeronic.design at gmail.com  Thu May  3 11:26:12 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Thu, 3 May 2012 09:26:12 -0700
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
Message-ID: <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>

On Thu, May 3, 2012 at 8:15 AM, Tei <oscar.vives at gmail.com> wrote:
** Perhaps cell towers can be made to fail sooner, and enter some
** emergency mode where only 911 calls get service.
**
**
**
** --

Don't cell companies already provide over-ride codes to various
federal agencies to obtain emergency priority access to cell service?

(**** added just to piss off Valdis)

-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From eyeronic.design at gmail.com  Thu May  3 11:32:08 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Thu, 3 May 2012 09:32:08 -0700
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
Message-ID: <CAN3um4y8bDqgTViRNyYJqHBW6Hf_RsP1RS_cVo2ig=VwO3EHqA@mail.gmail.com>

That's precisely where SatCom enters the picture.  Cell companies
aren't ever going to undersell their bandwidth...that simply isn't
profitable.  SatCom is one of the best ways to plan for communications
outages during times of crisis, especially if you choose a provider
that's outside of your area.  Unfortunately, you're going to end up
spending at least one more order of magnitude on *decent* satellite
service than you would spend on cell (unless you only go with a
satphone).

On Thu, May 3, 2012 at 7:59 AM, Brandt, Ralph <ralph.brandt at pateam.com> wrote:
>*SNIP*
>
> During a Peach Bottom (nuclear power plant - one of our two in the area
> - the other is Three Mile Island) several of the EOC's lost phone, FAX
> and radio connectivity (repeater failures) to County EOC because of
> thunderstorms and tornados that blew in during the drill. ?The ham radio
> operators at these EOC's and County provided communications to the sites
> for both the drill and live events. They happened to be on site for the
> drill. The site I was at was vacated except the hams, the government
> evaluators and the public works guy because of a fire, all of the other
> players in the EOC including the EMC were firemen! ?A lack of volunteers
> means people wear multiple hats.
>
> But let's get to the big item. ?When the bad day comes, cellular is
> worthless. ?I was at work the day of the earthquake in Virginia, a
> couple hundred miles south of us. ?The ground shook and some masonry
> buildings in the area sustained cracks that needed to be repaired. ?Ten
> minutes after the quake cellular was either useless or had up to fifteen
> minute waits to place a call. ?Everyone was on discussing the quake.
> And cellular company pronouncements aside, it isn't going to get better,
> even if they get more bandwidth that will be eaten up in 2-4 years. The
> total migration to cellular, the unlimited use, the tendency for people
> to yack when a bad day comes all makes for a disaster. ?We need
> solutions, not cell company hype, not government catering to special
> interests, but real solutions that fix problems without introducing
> more.
>
> One of the first things cellular companies can do is stop overselling
> cellular. ?The second is end or raise the price significantly on
> unlimited plans, both voice and data. ?Go to what the landlines called,
> USS, that is you pay for every minute.... ?Even if that charge is small,
> it will drive usage down.
>
> Otherwise on a bad day people will die waiting for the yackers to get
> off the call phone so they can call 911. ?Hopefully it will not be on
> VOIP and the internet is down.
>
>
> Ralph Brandt
>
> -----Original Message-----
> From: Jared Mauch [mailto:jared at puck.nether.net]
> Sent: Wednesday, May 02, 2012 4:15 PM
> To: Eric Wieling
> Cc: NANOG list
> Subject: VoIP vs POTS (was Re: Operation Ghost Click)
>
>
> On May 2, 2012, at 3:52 PM, Eric Wieling wrote:
>
>>
>> I doubt the g729 or GSM codecs used by VoIP and Cell phones can
> compare to a POTS line.
>
>
> This is why many people use g711ulaw or other codec.
>
> Personally I would not work with anyone that doesn't do g711ulaw
> (88.2kbit when IP packet overhead added in).
>
> There are other codecs such as G.722.1 & G.722.2 but the support isn't
> as broad as g711ulaw/alaw.
>
> Regarding landline service, this can fail for many of the common reasons
> it does are the same reasons that IP service may fail. ?The failure
> modes can depend on a variety of circumstances from the physical layer
> (e.g.: audible static on the line) that cause your ear to retrain, which
> may cause a DSL device to comparably retrain. ?The same is true for
> shared medium such as CATV but this has other problems as well, if not
> well isolated, somebody can short out the segment or send garbage at the
> wrong channel, etc.
>
> Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a
> long-distance from the CO) for something like the Verizon Home Connect
> box. ?Gives a few hours of built-in battery backup, but would fail once
> the tower loses power (usually 8-12 hours).
>
> I also am concerned about 911 service. ?When dialing 911 recently from
> my mobile, I should have dialed it from my home phone as I was routed a
> few times to get to the right fire dispatch team.
>
> Oh well.
>
> - Jared
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From sean at seanharlow.info  Thu May  3 11:35:41 2012
From: sean at seanharlow.info (Sean Harlow)
Date: Thu, 3 May 2012 12:35:41 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
 <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>
Message-ID: <B4DADE17-7BC3-4313-AEB0-26E622001897@seanharlow.info>

On May 3, 2012, at 12:26, Mike Hale wrote:

> Don't cell companies already provide over-ride codes to various
> federal agencies to obtain emergency priority access to cell service?

That would be the Nationwide Wireless Priority Service.  Authorized users can dial *272<destination> to get priority on supported wireless networks.  If the landline networks are also backed up, they can make the call to (710) NCS-GETS which is the gateway number for the Government Emergency Telecommunications System which provides the same priority on POTS lines.

http://en.wikipedia.org/wiki/Nationwide_Wireless_Priority_Service
http://en.wikipedia.org/wiki/Government_Emergency_Telecommunications_Service
---
Sean Harlow
sean at seanharlow.info



From ghira at mistral.co.uk  Thu May  3 11:44:20 2012
From: ghira at mistral.co.uk (Adam Atkinson)
Date: Thu, 03 May 2012 17:44:20 +0100
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>
References: <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>
Message-ID: <4FA2B5E4.9060104@mistral.co.uk>

Jay Ashworth wrote:

>> Googling "PCM adult male voice", "4kHz adult male" and similar isn't
>> finding me anything. Was I told nonsense?
> 

[snippage]

> What might be the case is that you'd 
> have more trouble *distinguishing* amongst women, or between women and 
> children, because the tones necessary for that are more located above the
> cutoff frequency.

Thank you for this and the link. Very interesting stuff. I have never 
tried to check to what extent I / others can distinguish different 
female / young speakers on the phone. I shall try to pay more attention 
to this in the future.

  > In short: it depends a lot on what you mean by 'serves well'.  :-)

Well, just the above seems like enough that you'd think there'd be more 
(justified) grumbling that thanks to a choice made many many decades ago 
it's harder to distinguish young or female speakers than it is adult 
male ones. Maybe there is and I've just not noticed it. Is this one of 
the things pushing adoption of higher bandwidth audio codecs? (My guess: 
no.)


From mehmet at akcin.net  Thu May  3 11:57:07 2012
From: mehmet at akcin.net (Mehmet Akcin)
Date: Thu, 3 May 2012 09:57:07 -0700
Subject: Peering in Brazil
In-Reply-To: <CAAWx_pV50AFC8arcJ+kJXN-3Wxnzb=7YN3=ywSxkZTNRxJL0iQ@mail.gmail.com>
References: <CAAWx_pV50AFC8arcJ+kJXN-3Wxnzb=7YN3=ywSxkZTNRxJL0iQ@mail.gmail.com>
Message-ID: <1C91959E-433D-45F1-ABF2-F317843FC8CE@akcin.net>


On May 3, 2012, at 2:28 AM, James Bensley wrote:

> I'm new to the PTT IXs so does anyone have any recommendations about
> any aspect here, support horror stories, reason to prefer one location
> for peering over another etc? I see Level3 are in the PTT Sao Paulo
> location, and we have access to Level 3 already. Is there someone else
> I should be looking at who is especially good at private routes down
> to SA, enough to digress from Level 3, or are Level 3 a good choice
> here? Again, any past experiences are welcome, and recommendations for
> a different IX or provider any why.

My experience with PTT IXs is great. They are being ran professionally. People who you deal with support is extremely helpful and have knowledge on what they are doing.

Sao Paulo is definitely the biggest but there is significant traffic in other locations as well.

mehmet

From jra at baylink.com  Thu May  3 12:29:42 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 3 May 2012 13:29:42 -0400 (EDT)
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <4FA2B5E4.9060104@mistral.co.uk>
Message-ID: <24392175.2032.1336066182556.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Adam Atkinson" <ghira at mistral.co.uk>

> Well, just the above seems like enough that you'd think there'd be more
> (justified) grumbling that thanks to a choice made many many decades ago
> it's harder to distinguish young or female speakers than it is adult
> male ones. Maybe there is and I've just not noticed it. Is this one of
> the things pushing adoption of higher bandwidth audio codecs? (My guess:
> no.)

Not directly, I don't think, no.  I suspect it's merely "why 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 joelja at bogus.com  Thu May  3 13:03:11 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Thu, 03 May 2012 11:03:11 -0700
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <24392175.2032.1336066182556.JavaMail.root@benjamin.baylink.com>
References: <24392175.2032.1336066182556.JavaMail.root@benjamin.baylink.com>
Message-ID: <4FA2C85F.9000508@bogus.com>

On 5/3/12 10:29 , Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Adam Atkinson" <ghira at mistral.co.uk>
> 
>> Well, just the above seems like enough that you'd think there'd be more
>> (justified) grumbling that thanks to a choice made many many decades ago
>> it's harder to distinguish young or female speakers than it is adult
>> male ones. Maybe there is and I've just not noticed it. Is this one of
>> the things pushing adoption of higher bandwidth audio codecs? (My guess:
>> no.)
> 
> Not directly, I don't think, no.  I suspect it's merely "why not?"

wideband codecs carry music a lot better.

the can have considerably more dynamic range than you can expect from an
8 bit pcm mulaw encoding (about 45bB). that helps a lot in the speaker
phone situation.

if you have the opportunity to compare pstn and mp3 recordings of the
same meeting like I do on occasion the difference is considerable.


> Cheers,
> -- jra



From ralph.brandt at pateam.com  Thu May  3 13:10:57 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 14:10:57 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD39@embgsr24.pateam.com>

The problem with this is, MOST 911 CALLS ARE CELLULAR or soon will be.  



Ralph Brandt
PA 


-----Original Message-----
From: Tei [mailto:oscar.vives at gmail.com] 
Sent: Thursday, May 03, 2012 11:15 AM
To: NANOG list
Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)

Perhaps cell towers can be made to fail sooner, and enter some
emergency mode where only 911 calls get service.



--
--
?in del ?ensaje.


From ralph.brandt at pateam.com  Thu May  3 13:14:25 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 14:14:25 -0400
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <10329.1336059187@turing-police.cc.vt.edu>
References: <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>
 <10329.1336059187@turing-police.cc.vt.edu>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD3B@embgsr24.pateam.com>

As one involved in emergency services I don't gave a rats whether you
can't tell one voice from another.  I do care if someone who is having a
fire, accident, cardiac episode or stroke can get through. 

The cell companies are worrying about your whim and not the safety. 

 

Ralph Brandt


-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: Thursday, May 03, 2012 11:33 AM
To: NANOG
Subject: Re: Cellphones and Audio (was Ghost Click, though I got no idea
why)

On Thu, 03 May 2012 11:01:01 -0400, Jay Ashworth said:

> In general, though, intelligibility comes from the higher frequencies,
> and 3.4kHz is *usually* high enough.  What might be the case is that
you'd
> have more trouble *distinguishing* amongst women, or between women and
> children, because the tones necessary for that are more located above
the
> cutoff frequency.

I have had more than a few surreal conversations on the phone with my
daughter - once the 3.4kHz filter gets done, I can't distinguish her
voice from
her mom's (and yes, I've gotten social-engineered as a result).  Life
has
gotten simpler since she got old enough to have her own cell phone. ;)



From jra at baylink.com  Thu May  3 13:19:22 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 3 May 2012 14:19:22 -0400 (EDT)
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECD39@embgsr24.pateam.com>
Message-ID: <12930047.2088.1336069162661.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ralph Brandt" <ralph.brandt at pateam.com>

> The problem with this is, MOST 911 CALLS ARE CELLULAR or soon will be.

{citation-needed}

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 ralph.brandt at pateam.com  Thu May  3 13:21:13 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 14:21:13 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
 <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD42@embgsr24.pateam.com>

I spent a week in a PEMA conference last fall.  One of the presentations
was from two ILECS and 1 CLEC.  The answer we got was, yes we do but no
we can't.  Got it?

What I understand after grilling the 5 reps from one company and three
for the other, is they have priority of who can make a call but not in
who can get the system attention.  SO till you get the system attention,
you don't go anywhere.  The ILEC is not in cell and admitted they had
problems, were working on them, do not have them all solved, do not know
if they can solve them all - they had some credibility.  I looked at the
other two as snake oil salesmen....

I was the only one who asked any questions.  

Ralph Brandt
York PA 17055


-----Original Message-----
From: Mike Hale [mailto:eyeronic.design at gmail.com] 
Sent: Thursday, May 03, 2012 12:26 PM
To: Tei
Cc: NANOG list
Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)

On Thu, May 3, 2012 at 8:15 AM, Tei <oscar.vives at gmail.com> wrote:
** Perhaps cell towers can be made to fail sooner, and enter some
** emergency mode where only 911 calls get service.
**
**
**
** --

Don't cell companies already provide over-ride codes to various
federal agencies to obtain emergency priority access to cell service?

(**** added just to piss off Valdis)

-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0



From ralph.brandt at pateam.com  Thu May  3 13:35:47 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 14:35:47 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <CAN3um4y8bDqgTViRNyYJqHBW6Hf_RsP1RS_cVo2ig=VwO3EHqA@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com><4FA18774.7090909@mompl.net><CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com><C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe><721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net><51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CAN3um4y8bDqgTViRNyYJqHBW6Hf_RsP1RS_cVo2ig=VwO3EHqA@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD48@embgsr24.pateam.com>

Satcoms are the panacea for every problem until you try them.  They too have limited numbers of channels, far lower than cell.

Check the fiasco in Haiti when sat phones were handed out and it took hours to make calls.  

Sometimes two tin cans and a string are better....

Ralph Brandt


-----Original Message-----
From: Mike Hale [mailto:eyeronic.design at gmail.com] 
Sent: Thursday, May 03, 2012 12:32 PM
To: Brandt, Ralph
Cc: NANOG list
Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)

That's precisely where SatCom enters the picture.  Cell companies
aren't ever going to undersell their bandwidth...that simply isn't
profitable.  SatCom is one of the best ways to plan for communications
outages during times of crisis, especially if you choose a provider
that's outside of your area.  Unfortunately, you're going to end up
spending at least one more order of magnitude on *decent* satellite
service than you would spend on cell (unless you only go with a
satphone).

On Thu, May 3, 2012 at 7:59 AM, Brandt, Ralph <ralph.brandt at pateam.com> wrote:
>*SNIP*
>
> During a Peach Bottom (nuclear power plant - one of our two in the area
> - the other is Three Mile Island) several of the EOC's lost phone, FAX
> and radio connectivity (repeater failures) to County EOC because of
> thunderstorms and tornados that blew in during the drill. ?The ham radio
> operators at these EOC's and County provided communications to the sites
> for both the drill and live events. They happened to be on site for the
> drill. The site I was at was vacated except the hams, the government
> evaluators and the public works guy because of a fire, all of the other
> players in the EOC including the EMC were firemen! ?A lack of volunteers
> means people wear multiple hats.
>
> But let's get to the big item. ?When the bad day comes, cellular is
> worthless. ?I was at work the day of the earthquake in Virginia, a
> couple hundred miles south of us. ?The ground shook and some masonry
> buildings in the area sustained cracks that needed to be repaired. ?Ten
> minutes after the quake cellular was either useless or had up to fifteen
> minute waits to place a call. ?Everyone was on discussing the quake.
> And cellular company pronouncements aside, it isn't going to get better,
> even if they get more bandwidth that will be eaten up in 2-4 years. The
> total migration to cellular, the unlimited use, the tendency for people
> to yack when a bad day comes all makes for a disaster. ?We need
> solutions, not cell company hype, not government catering to special
> interests, but real solutions that fix problems without introducing
> more.
>
> One of the first things cellular companies can do is stop overselling
> cellular. ?The second is end or raise the price significantly on
> unlimited plans, both voice and data. ?Go to what the landlines called,
> USS, that is you pay for every minute.... ?Even if that charge is small,
> it will drive usage down.
>
> Otherwise on a bad day people will die waiting for the yackers to get
> off the call phone so they can call 911. ?Hopefully it will not be on
> VOIP and the internet is down.
>
>
> Ralph Brandt
>
> -----Original Message-----
> From: Jared Mauch [mailto:jared at puck.nether.net]
> Sent: Wednesday, May 02, 2012 4:15 PM
> To: Eric Wieling
> Cc: NANOG list
> Subject: VoIP vs POTS (was Re: Operation Ghost Click)
>
>
> On May 2, 2012, at 3:52 PM, Eric Wieling wrote:
>
>>
>> I doubt the g729 or GSM codecs used by VoIP and Cell phones can
> compare to a POTS line.
>
>
> This is why many people use g711ulaw or other codec.
>
> Personally I would not work with anyone that doesn't do g711ulaw
> (88.2kbit when IP packet overhead added in).
>
> There are other codecs such as G.722.1 & G.722.2 but the support isn't
> as broad as g711ulaw/alaw.
>
> Regarding landline service, this can fail for many of the common reasons
> it does are the same reasons that IP service may fail. ?The failure
> modes can depend on a variety of circumstances from the physical layer
> (e.g.: audible static on the line) that cause your ear to retrain, which
> may cause a DSL device to comparably retrain. ?The same is true for
> shared medium such as CATV but this has other problems as well, if not
> well isolated, somebody can short out the segment or send garbage at the
> wrong channel, etc.
>
> Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a
> long-distance from the CO) for something like the Verizon Home Connect
> box. ?Gives a few hours of built-in battery backup, but would fail once
> the tower loses power (usually 8-12 hours).
>
> I also am concerned about 911 service. ?When dialing 911 recently from
> my mobile, I should have dialed it from my home phone as I was routed a
> few times to get to the right fire dispatch team.
>
> Oh well.
>
> - Jared
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From ralph.brandt at pateam.com  Thu May  3 13:37:37 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 14:37:37 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <B4DADE17-7BC3-4313-AEB0-26E622001897@seanharlow.info>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
 <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>
 <B4DADE17-7BC3-4313-AEB0-26E622001897@seanharlow.info>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD4B@embgsr24.pateam.com>

Sean, do you know anyone who has successfully used either to place a
call?  

I think the weak spot is when the tower overloads nobody can dial
anything, including the bypass..

Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt at pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055


-----Original Message-----
From: Sean Harlow [mailto:sean at seanharlow.info] 
Sent: Thursday, May 03, 2012 12:36 PM
To: Mike Hale
Cc: NANOG list
Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)

On May 3, 2012, at 12:26, Mike Hale wrote:

> Don't cell companies already provide over-ride codes to various
> federal agencies to obtain emergency priority access to cell service?

That would be the Nationwide Wireless Priority Service.  Authorized
users can dial *272<destination> to get priority on supported wireless
networks.  If the landline networks are also backed up, they can make
the call to (710) NCS-GETS which is the gateway number for the
Government Emergency Telecommunications System which provides the same
priority on POTS lines.

http://en.wikipedia.org/wiki/Nationwide_Wireless_Priority_Service
http://en.wikipedia.org/wiki/Government_Emergency_Telecommunications_Ser
vice
---
Sean Harlow
sean at seanharlow.info




From sean at seanharlow.info  Thu May  3 13:43:36 2012
From: sean at seanharlow.info (Sean Harlow)
Date: Thu, 3 May 2012 14:43:36 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <12930047.2088.1336069162661.JavaMail.root@benjamin.baylink.com>
References: <12930047.2088.1336069162661.JavaMail.root@benjamin.baylink.com>
Message-ID: <406BFC45-3536-454E-B7F7-D0C1FAD70265@seanharlow.info>

On May 3, 2012, at 14:19, Jay Ashworth wrote:

> {citation-needed}

I don't have any numbers to offer, but given the near universality of cellular phones these days among the adult population I could easily see a majority going for cellular.  Car accidents, house fires, and a lot of other types of 911 call are probably almost entirely from mobile.  Car accidents and anything else 911-worthy near a busy probably contribute a ton of calls about the same incident (not worthwhile calls, but calls nonetheless).  There are also many people, myself included, who do not have a traditional landline.  If they don't have VoIP or it's not working for some reason, everything becomes a mobile call.

Again not arguing one side or another, just that there's enough mobile usage that it would seem reasonable either way.
---
Sean Harlow
sean at seanharlow.info



From eyeronic.design at gmail.com  Thu May  3 13:53:01 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Thu, 3 May 2012 11:53:01 -0700
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECD48@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CAN3um4y8bDqgTViRNyYJqHBW6Hf_RsP1RS_cVo2ig=VwO3EHqA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B017018ECD48@embgsr24.pateam.com>
Message-ID: <CAN3um4wt-EBU12ZT9ZQrj5XErCoj-iMA1fE4E1F8gi+q7bJpWA@mail.gmail.com>

Absolutely.  Again, it depends on what service you use, what
contention the provider gives you, and so forth.  If you go with a
quality provider and a good service plan, you will not get bumped off
in favor of someone else.  Of course, you're paying much more for
service like that, but you really do get what you pay for, especially
when it comes to satellite.

On Thu, May 3, 2012 at 11:35 AM, Brandt, Ralph <ralph.brandt at pateam.com> wrote:
> Satcoms are the panacea for every problem until you try them. ?They too have limited numbers of channels, far lower than cell.
>
> Check the fiasco in Haiti when sat phones were handed out and it took hours to make calls.
>
> Sometimes two tin cans and a string are better....
>
> Ralph Brandt
>
>
> -----Original Message-----
> From: Mike Hale [mailto:eyeronic.design at gmail.com]
> Sent: Thursday, May 03, 2012 12:32 PM
> To: Brandt, Ralph
> Cc: NANOG list
> Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)
>
> That's precisely where SatCom enters the picture. ?Cell companies
> aren't ever going to undersell their bandwidth...that simply isn't
> profitable. ?SatCom is one of the best ways to plan for communications
> outages during times of crisis, especially if you choose a provider
> that's outside of your area. ?Unfortunately, you're going to end up
> spending at least one more order of magnitude on *decent* satellite
> service than you would spend on cell (unless you only go with a
> satphone).
>
> On Thu, May 3, 2012 at 7:59 AM, Brandt, Ralph <ralph.brandt at pateam.com> wrote:
>>*SNIP*
>>
>> During a Peach Bottom (nuclear power plant - one of our two in the area
>> - the other is Three Mile Island) several of the EOC's lost phone, FAX
>> and radio connectivity (repeater failures) to County EOC because of
>> thunderstorms and tornados that blew in during the drill. ?The ham radio
>> operators at these EOC's and County provided communications to the sites
>> for both the drill and live events. They happened to be on site for the
>> drill. The site I was at was vacated except the hams, the government
>> evaluators and the public works guy because of a fire, all of the other
>> players in the EOC including the EMC were firemen! ?A lack of volunteers
>> means people wear multiple hats.
>>
>> But let's get to the big item. ?When the bad day comes, cellular is
>> worthless. ?I was at work the day of the earthquake in Virginia, a
>> couple hundred miles south of us. ?The ground shook and some masonry
>> buildings in the area sustained cracks that needed to be repaired. ?Ten
>> minutes after the quake cellular was either useless or had up to fifteen
>> minute waits to place a call. ?Everyone was on discussing the quake.
>> And cellular company pronouncements aside, it isn't going to get better,
>> even if they get more bandwidth that will be eaten up in 2-4 years. The
>> total migration to cellular, the unlimited use, the tendency for people
>> to yack when a bad day comes all makes for a disaster. ?We need
>> solutions, not cell company hype, not government catering to special
>> interests, but real solutions that fix problems without introducing
>> more.
>>
>> One of the first things cellular companies can do is stop overselling
>> cellular. ?The second is end or raise the price significantly on
>> unlimited plans, both voice and data. ?Go to what the landlines called,
>> USS, that is you pay for every minute.... ?Even if that charge is small,
>> it will drive usage down.
>>
>> Otherwise on a bad day people will die waiting for the yackers to get
>> off the call phone so they can call 911. ?Hopefully it will not be on
>> VOIP and the internet is down.
>>
>>
>> Ralph Brandt
>>
>> -----Original Message-----
>> From: Jared Mauch [mailto:jared at puck.nether.net]
>> Sent: Wednesday, May 02, 2012 4:15 PM
>> To: Eric Wieling
>> Cc: NANOG list
>> Subject: VoIP vs POTS (was Re: Operation Ghost Click)
>>
>>
>> On May 2, 2012, at 3:52 PM, Eric Wieling wrote:
>>
>>>
>>> I doubt the g729 or GSM codecs used by VoIP and Cell phones can
>> compare to a POTS line.
>>
>>
>> This is why many people use g711ulaw or other codec.
>>
>> Personally I would not work with anyone that doesn't do g711ulaw
>> (88.2kbit when IP packet overhead added in).
>>
>> There are other codecs such as G.722.1 & G.722.2 but the support isn't
>> as broad as g711ulaw/alaw.
>>
>> Regarding landline service, this can fail for many of the common reasons
>> it does are the same reasons that IP service may fail. ?The failure
>> modes can depend on a variety of circumstances from the physical layer
>> (e.g.: audible static on the line) that cause your ear to retrain, which
>> may cause a DSL device to comparably retrain. ?The same is true for
>> shared medium such as CATV but this has other problems as well, if not
>> well isolated, somebody can short out the segment or send garbage at the
>> wrong channel, etc.
>>
>> Personally, I'm thinking of ditching my ISDN (gives clear dial tone at a
>> long-distance from the CO) for something like the Verizon Home Connect
>> box. ?Gives a few hours of built-in battery backup, but would fail once
>> the tower loses power (usually 8-12 hours).
>>
>> I also am concerned about 911 service. ?When dialing 911 recently from
>> my mobile, I should have dialed it from my home phone as I was routed a
>> few times to get to the right fire dispatch team.
>>
>> Oh well.
>>
>> - Jared
>>
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From ralph.brandt at pateam.com  Thu May  3 14:04:54 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 15:04:54 -0400
Subject: Cellphones and Audio (was Ghost Click, though I got no idea why)
In-Reply-To: <10329.1336059187@turing-police.cc.vt.edu>
References: <22621797.1944.1336057261000.JavaMail.root@benjamin.baylink.com>
 <10329.1336059187@turing-police.cc.vt.edu>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD55@embgsr24.pateam.com>

I wanted to mention one other thing here.  In addition to my day job I
am a ham radio operator and a IMT COML.  I deal with UNDERSTANDABILITY.
I sympathize with you on getting bamboozled by the family, have 3
sisters and two daughters.  

But in the real world of communications 2.3 - 2.5 Khz filters for SSB
are the norm, and some guys like it tighter.  

Let me be frank, spectrum space and hence bandwidth is finite.  There is
no silver bullet.  The FCC mandated narrow banding in VHF is costing
public service millions.  AT&T pronouncements aside, I have heard them,
there will be improvements but not quantum ones.  Right now the cell cos
are trying to desperately get more spectrum because they know they are
about to hit the wall.  They already do in places like unHappy Valley
(Penn State) at game time when everyone is on the cells.  

One recent merger/acquisition attempt that failed was for the larger co
to get the smaller one's spectrum space.  They are looking at some
public service spectrum to see if they can offer enough money to get it
- most of that money is spent lobbying. Once it goes to cell, it isn't
coming back no matter what.  The Digital TV was as much about freeing
spectrum space to sell it for government income as better TV signals
which we didn't need and have cost every person in the US at least
$1,000 (new TV's, increased ad costs which increase product prices to
pay for the broadcasting equipment) and we didn't get that back for the
spectrum space when it was sold.  We paid for the industry to upgrade!  


 

Ralph Brandt


-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: Thursday, May 03, 2012 11:33 AM
To: NANOG
Subject: Re: Cellphones and Audio (was Ghost Click, though I got no idea
why)

On Thu, 03 May 2012 11:01:01 -0400, Jay Ashworth said:

> In general, though, intelligibility comes from the higher frequencies,
> and 3.4kHz is *usually* high enough.  What might be the case is that
you'd
> have more trouble *distinguishing* amongst women, or between women and
> children, because the tones necessary for that are more located above
the
> cutoff frequency.

I have had more than a few surreal conversations on the phone with my
daughter - once the 3.4kHz filter gets done, I can't distinguish her
voice from
her mom's (and yes, I've gotten social-engineered as a result).  Life
has
gotten simpler since she got old enough to have her own cell phone. ;)



From sean at seanharlow.info  Thu May  3 14:16:58 2012
From: sean at seanharlow.info (Sean Harlow)
Date: Thu, 3 May 2012 15:16:58 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECD4B@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <CACg3zYHPX6dJv6=f8nkmR4oG1KzfbeVdEaQmM3C-ywzwQwDGLw@mail.gmail.com>
 <CAN3um4zw0oDgfx6=5WYT14ApiaDK+eC+fDYPTtL4C8P-bhRvkg@mail.gmail.com>
 <B4DADE17-7BC3-4313-AEB0-26E622001897@seanharlow.info>
 <51C66083768C2949A7EB14910C78B017018ECD4B@embgsr24.pateam.com>
Message-ID: <AC9D2CC4-01D3-48F1-B9A2-656376B68870@seanharlow.info>

On May 3, 2012, at 14:37, Brandt, Ralph wrote:

> Sean, do you know anyone who has successfully used either to place a
> call?  

Not to my knowledge.  Due to some family in government I'm sure I know someone who's authorized for one or the other, but I can't say the topic's ever come up.  I'm just a telecom geek who gets bored and reads obscure documentation.

> I think the weak spot is when the tower overloads nobody can dial
> anything, including the bypass..


That's certainly true, I don't know much about CDMA but in GSM if the RACH channel is flooded the phone won't be able to get through with a channel request and thus won't be able to do much of anything useful.  I believe a DoS based on this was demonstrated a few years back, so it is a legitimate concern.

The GAO actually did a report on both GETS and WPS a few years ago (http://www.gao.gov/new.items/d09822.pdf).  Report pages 63-64 (PDF pages 68-69) show completion rates during major events of the last decade, though comparisons to normal calling in the affected areas during the same period are not available.  Assuming that normal calls did have completion problems, it seems that GETS works well and WPS works until the cells get completely flooded as happened during the '09 Inauguration.
---
Sean Harlow
sean at seanharlow.info



From source_route at yahoo.com  Thu May  3 14:24:46 2012
From: source_route at yahoo.com (Philip Lavine)
Date: Thu, 3 May 2012 12:24:46 -0700 (PDT)
Subject: mulcast assignments
Message-ID: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>

?? How do I get a registered multicast block?

From lsc at prgmr.com  Thu May  3 14:25:52 2012
From: lsc at prgmr.com (Luke S. Crawford)
Date: Thu, 3 May 2012 15:25:52 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
Message-ID: <20120503192552.GD9744@luke.xen.prgmr.com>

On Thu, May 03, 2012 at 10:59:47AM -0400, Brandt, Ralph wrote:
> One of the first things cellular companies can do is stop overselling
> cellular.  The second is end or raise the price significantly on
> unlimited plans, both voice and data.  Go to what the landlines called,
> USS, that is you pay for every minute....  Even if that charge is small,
> it will drive usage down.
> 
> Otherwise on a bad day people will die waiting for the yackers to get
> off the call phone so they can call 911.  Hopefully it will not be on
> VOIP and the internet is down.

A few years back, I was working late on the top floor of one of the Yahoo 
mission college buildings during an earthquake.  It felt really dramatic;
I was on the 9th floor and the lights were swinging back and forth and 
yeah.   So, I went outside (who knows how bad it was)  figured out it
wasn't that bad, and so before going home, I decided to call some people
to tell them I was okay.  Of course, it was as you describe, I couldn't
get through.

what did I do?  I sent a text message.  It got through and I got an
answer back in about the usual amount of time it takes someone to respond
to a sms text.

It seems like SMS might be a reasonable backup during these periods of
high load.  


From jof at thejof.com  Thu May  3 14:32:28 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 3 May 2012 12:32:28 -0700
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <20120503192552.GD9744@luke.xen.prgmr.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <20120503192552.GD9744@luke.xen.prgmr.com>
Message-ID: <CAHsqw9uRWTzisiWDoGeLqeSVw_mt8kpo19H2uzJHHcHzKYvbdw@mail.gmail.com>

On Thu, May 3, 2012 at 12:25 PM, Luke S. Crawford <lsc at prgmr.com> wrote:
> On Thu, May 03, 2012 at 10:59:47AM -0400, Brandt, Ralph wrote:
>> One of the first things cellular companies can do is stop overselling
>> cellular. ?The second is end or raise the price significantly on
>> unlimited plans, both voice and data. ?Go to what the landlines called,
>> USS, that is you pay for every minute.... ?Even if that charge is small,
>> it will drive usage down.
>>
>> Otherwise on a bad day people will die waiting for the yackers to get
>> off the call phone so they can call 911. ?Hopefully it will not be on
>> VOIP and the internet is down.
>
> A few years back, I was working late on the top floor of one of the Yahoo
> mission college buildings during an earthquake. ?It felt really dramatic;
> I was on the 9th floor and the lights were swinging back and forth and
> yeah. ? So, I went outside (who knows how bad it was) ?figured out it
> wasn't that bad, and so before going home, I decided to call some people
> to tell them I was okay. ?Of course, it was as you describe, I couldn't
> get through.
>
> what did I do? ?I sent a text message. ?It got through and I got an
> answer back in about the usual amount of time it takes someone to respond
> to a sms text.
>
> It seems like SMS might be a reasonable backup during these periods of
> high load.

Good point. SMSes seem pretty congestion friendly since they're
usually riding control channels anyway, and can be queued up and
delivered when capacity is there (no channel reservation needed).

--j


From gjshep at gmail.com  Thu May  3 14:35:02 2012
From: gjshep at gmail.com (Greg Shepherd)
Date: Thu, 3 May 2012 12:35:02 -0700
Subject: mulcast assignments
In-Reply-To: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
Message-ID: <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>

Why do you think you need an assigned mcast block? All inter domain
mcast uses source trees only, so just use SSM and you don't need
address assignments.

Greg

On Thu, May 3, 2012 at 12:24 PM, Philip Lavine <source_route at yahoo.com> wrote:
> ?? How do I get a registered multicast block?
>


From ralph.brandt at pateam.com  Thu May  3 14:40:40 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Thu, 3 May 2012 15:40:40 -0400
Subject: VoIP vs POTS (was Re: Operation Ghost Click)
In-Reply-To: <20120503192552.GD9744@luke.xen.prgmr.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <C262B52114110B4586FAF49F074F0580109897F1D6@mailserver2007.nyigc.globe>
 <721D15B2-2CA3-48BF-A090-600BF892B7B0@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCF5@embgsr24.pateam.com>
 <20120503192552.GD9744@luke.xen.prgmr.com>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECD5A@embgsr24.pateam.com>

Yep. What you experienced is exactly what I expected.  And yes, sms MAY
make it when a call will not.  In SAR demos we tell people, lost in the
woods, if cell doesn't work, send a message, hold the phone as high as
you can and slowly move it a couple feet back and forth. 

I do lots of public service events in the Alleghenies (the PA portion of
the Appalachians) where cell towers are either non-existant, far away or
hidden by another hill.  

I know this is off topic but if it saves a life, so be it.

When in this kind of area, TURN THE PHONE OFF WHEN YOU DON"T NEED IT.
My battery goes down in3-4 hours in the woods where in my home area it
stays up for nearly 30 hours.  It goes on high power hunting for a tower
that is not there.  

If you are planning to use a cell for emergencies, have an alternate way
to charge it.  I have a home made 8 AA cell pack with a cigarette
lighter well that I carry - I can do a couple recharges.  It will also
operate my ham radio Hand held for days which is far better to get me
out.

BTW if you are using a GPS, take at least 3 sets of spare batteries.
Other good things, a whistle, a mirror (to check your hair - you want to
look good for the searchers - grin), a garbage bag for an emergency
poncho and water.  If you can read a compass and map they are good but
if you don't know what magnetic north is, take a class if you plan to be
in the wooded areas.  It is also good to carry a snake bite kit, .38 and
9MM ones are great.  The woods are fun.
  

  

Ralph Brandt


-----Original Message-----
From: Luke S. Crawford [mailto:lsc at prgmr.com] 
Sent: Thursday, May 03, 2012 3:26 PM
To: NANOG list
Subject: Re: VoIP vs POTS (was Re: Operation Ghost Click)

On Thu, May 03, 2012 at 10:59:47AM -0400, Brandt, Ralph wrote:
> One of the first things cellular companies can do is stop overselling
> cellular.  The second is end or raise the price significantly on
> unlimited plans, both voice and data.  Go to what the landlines
called,
> USS, that is you pay for every minute....  Even if that charge is
small,
> it will drive usage down.
> 
> Otherwise on a bad day people will die waiting for the yackers to get
> off the call phone so they can call 911.  Hopefully it will not be on
> VOIP and the internet is down.

A few years back, I was working late on the top floor of one of the
Yahoo 
mission college buildings during an earthquake.  It felt really
dramatic;
I was on the 9th floor and the lights were swinging back and forth and 
yeah.   So, I went outside (who knows how bad it was)  figured out it
wasn't that bad, and so before going home, I decided to call some people
to tell them I was okay.  Of course, it was as you describe, I couldn't
get through.

what did I do?  I sent a text message.  It got through and I got an
answer back in about the usual amount of time it takes someone to
respond
to a sms text.

It seems like SMS might be a reasonable backup during these periods of
high load.  



From quentin.carpent at vtx-telecom.ch  Thu May  3 14:53:02 2012
From: quentin.carpent at vtx-telecom.ch (Quentin Carpent)
Date: Thu, 3 May 2012 21:53:02 +0200
Subject: mulcast assignments
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
Message-ID: <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>

You can also use the glop IP addressing:
http://tools.ietf.org/html/rfc3180

Quentin

-----Original Message-----
From: Greg Shepherd [mailto:gjshep at gmail.com]
Sent: Thu 5/3/2012 9:35 PM
To: Philip Lavine
Cc: NANOG list
Subject: Re: mulcast assignments
 
Why do you think you need an assigned mcast block? All inter domain
mcast uses source trees only, so just use SSM and you don't need
address assignments.

Greg

On Thu, May 3, 2012 at 12:24 PM, Philip Lavine <source_route at yahoo.com> wrote:
> ?? How do I get a registered multicast block?
>



From gjshep at gmail.com  Thu May  3 15:00:49 2012
From: gjshep at gmail.com (Greg Shepherd)
Date: Thu, 3 May 2012 13:00:49 -0700
Subject: mulcast assignments
In-Reply-To: <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
Message-ID: <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>

Sure, but GLOP predated SSM, and was really only an interim fix for
the presumed need of mcast address assignments. GLOP only gives you a
/24 for each ASN where SSM gives you a /8 for every unique unicast
address you have along with vastly superior security and network
simplicity.

Greg

On Thu, May 3, 2012 at 12:53 PM, Quentin Carpent
<quentin.carpent at vtx-telecom.ch> wrote:
> You can also use the glop IP addressing:
> http://tools.ietf.org/html/rfc3180
>
> Quentin
>
> -----Original Message-----
> From: Greg Shepherd [mailto:gjshep at gmail.com]
> Sent: Thu 5/3/2012 9:35 PM
> To: Philip Lavine
> Cc: NANOG list
> Subject: Re: mulcast assignments
>
> Why do you think you need an assigned mcast block? All inter domain
> mcast uses source trees only, so just use SSM and you don't need
> address assignments.
>
> Greg
>
> On Thu, May 3, 2012 at 12:24 PM, Philip Lavine <source_route at yahoo.com> wrote:
>> ?? How do I get a registered multicast block?
>>
>
>


From owen at delong.com  Thu May  3 15:19:58 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 3 May 2012 13:19:58 -0700
Subject: mulcast assignments
In-Reply-To: <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
Message-ID: <1824091A-68F2-4DD0-8615-A7394B9C9641@delong.com>

Simpler solution... Just set the P flag and use your unicast prefix as part of the group ID.

For example, if your unicast prefix is 2001:db8:f00d::/48, you could use:

ff4e:2001:db8:f00d::<group number>

Where <group number> is any number of your choosing up to 64 bits, but recommended
to be ?32 bits.

Make sense?

Owen

On May 3, 2012, at 1:00 PM, Greg Shepherd wrote:

> Sure, but GLOP predated SSM, and was really only an interim fix for
> the presumed need of mcast address assignments. GLOP only gives you a
> /24 for each ASN where SSM gives you a /8 for every unique unicast
> address you have along with vastly superior security and network
> simplicity.
> 
> Greg
> 
> On Thu, May 3, 2012 at 12:53 PM, Quentin Carpent
> <quentin.carpent at vtx-telecom.ch> wrote:
>> You can also use the glop IP addressing:
>> http://tools.ietf.org/html/rfc3180
>> 
>> Quentin
>> 
>> -----Original Message-----
>> From: Greg Shepherd [mailto:gjshep at gmail.com]
>> Sent: Thu 5/3/2012 9:35 PM
>> To: Philip Lavine
>> Cc: NANOG list
>> Subject: Re: mulcast assignments
>> 
>> Why do you think you need an assigned mcast block? All inter domain
>> mcast uses source trees only, so just use SSM and you don't need
>> address assignments.
>> 
>> Greg
>> 
>> On Thu, May 3, 2012 at 12:24 PM, Philip Lavine <source_route at yahoo.com> wrote:
>>>    How do I get a registered multicast block?
>>> 
>> 
>> 



From packetjockey at gmail.com  Thu May  3 15:25:01 2012
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Thu, 3 May 2012 16:25:01 -0400
Subject: IPv6 aggregation tool
Message-ID: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>

Hi list,

I can't seem to find any tools that'll aggregate a list of IPv6 prefixes.
 Used to 'aggregate' for IPv4, looking for something similar for IPv6.
 Thanks!

From gjshep at gmail.com  Thu May  3 15:38:14 2012
From: gjshep at gmail.com (Greg Shepherd)
Date: Thu, 3 May 2012 13:38:14 -0700
Subject: mulcast assignments
In-Reply-To: <1824091A-68F2-4DD0-8615-A7394B9C9641@delong.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <1824091A-68F2-4DD0-8615-A7394B9C9641@delong.com>
Message-ID: <CABFReBrwWzeH0wREdtfzajtY=pwVxH1qEjvCWuK_q0yTipDX4g@mail.gmail.com>

On Thu, May 3, 2012 at 1:19 PM, Owen DeLong <owen at delong.com> wrote:
> Simpler solution... Just set the P flag and use your unicast prefix as part of the group ID.
>
> For example, if your unicast prefix is 2001:db8:f00d::/48, you could use:
>
> ff4e:2001:db8:f00d::<group number>
>
> Where <group number> is any number of your choosing up to 64 bits, but recommended
> to be ?32 bits.
>
> Make sense?

Sure, for v6. :)

Greg

> Owen
>
> On May 3, 2012, at 1:00 PM, Greg Shepherd wrote:
>
>> Sure, but GLOP predated SSM, and was really only an interim fix for
>> the presumed need of mcast address assignments. GLOP only gives you a
>> /24 for each ASN where SSM gives you a /8 for every unique unicast
>> address you have along with vastly superior security and network
>> simplicity.
>>
>> Greg
>>
>> On Thu, May 3, 2012 at 12:53 PM, Quentin Carpent
>> <quentin.carpent at vtx-telecom.ch> wrote:
>>> You can also use the glop IP addressing:
>>> http://tools.ietf.org/html/rfc3180
>>>
>>> Quentin
>>>
>>> -----Original Message-----
>>> From: Greg Shepherd [mailto:gjshep at gmail.com]
>>> Sent: Thu 5/3/2012 9:35 PM
>>> To: Philip Lavine
>>> Cc: NANOG list
>>> Subject: Re: mulcast assignments
>>>
>>> Why do you think you need an assigned mcast block? All inter domain
>>> mcast uses source trees only, so just use SSM and you don't need
>>> address assignments.
>>>
>>> Greg
>>>
>>> On Thu, May 3, 2012 at 12:24 PM, Philip Lavine <source_route at yahoo.com> wrote:
>>>> ? ?How do I get a registered multicast block?
>>>>
>>>
>>>
>


From Valdis.Kletnieks at vt.edu  Thu May  3 15:42:09 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 03 May 2012 16:42:09 -0400
Subject: mulcast assignments
In-Reply-To: Your message of "Thu, 03 May 2012 13:38:14 -0700."
 <CABFReBrwWzeH0wREdtfzajtY=pwVxH1qEjvCWuK_q0yTipDX4g@mail.gmail.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <1824091A-68F2-4DD0-8615-A7394B9C9641@delong.com>
 <CABFReBrwWzeH0wREdtfzajtY=pwVxH1qEjvCWuK_q0yTipDX4g@mail.gmail.com>
Message-ID: <57073.1336077729@turing-police.cc.vt.edu>

On Thu, 03 May 2012 13:38:14 -0700, Greg Shepherd said:
> > Make sense?
>
> Sure, for v6. :)

Does it make sense to be planning new deployments for anythign else? ;)

(Hint - if your reaction is "but we're not v6-capable", who's fault is that?)

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

From chip.gwyn at gmail.com  Thu May  3 15:58:27 2012
From: chip.gwyn at gmail.com (chip)
Date: Thu, 3 May 2012 16:58:27 -0400
Subject: IPv6 aggregation tool
In-Reply-To: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
References: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
Message-ID: <CABGzhdu46ukHTr7xDhjx_bXvf87ngZgML5xTDz16pxpL-y_Pdg@mail.gmail.com>

Looks like the most recent NetAddr::IP perl module will do it:

http://search.cpan.org/~miker/NetAddr-IP-4.059/IP.pm#EXPORT_OK

Take a look at the Compact function.  I think that's what will do it.


--chip

On Thu, May 3, 2012 at 4:25 PM, Rafael Rodriguez <packetjockey at gmail.com> wrote:
> Hi list,
>
> I can't seem to find any tools that'll aggregate a list of IPv6 prefixes.
> ?Used to 'aggregate' for IPv4, looking for something similar for IPv6.
> ?Thanks!



-- 
Just my $.02, your mileage may vary,? batteries not included, etc....


From gjshep at gmail.com  Thu May  3 16:33:17 2012
From: gjshep at gmail.com (Greg Shepherd)
Date: Thu, 3 May 2012 14:33:17 -0700
Subject: mulcast assignments
In-Reply-To: <57073.1336077729@turing-police.cc.vt.edu>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <1824091A-68F2-4DD0-8615-A7394B9C9641@delong.com>
 <CABFReBrwWzeH0wREdtfzajtY=pwVxH1qEjvCWuK_q0yTipDX4g@mail.gmail.com>
 <57073.1336077729@turing-police.cc.vt.edu>
Message-ID: <CABFReBrYxpNSEYMcMqLk6Xjdhi+N7YD8RQU71pu4noqZTeDM-Q@mail.gmail.com>

On Thu, May 3, 2012 at 1:42 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Thu, 03 May 2012 13:38:14 -0700, Greg Shepherd said:
>> > Make sense?
>>
>> Sure, for v6. :)
>
> Does it make sense to be planning new deployments for anythign else? ;)
>
> (Hint - if your reaction is "but we're not v6-capable", who's fault is that?)

The original question was not from me. :)

But even for IPv6 I would avoid embedded addressing and just use SSM.
With SSM there's no need for embedded addressing and again you get all
the security and network simplicity.

 FF3x::/96

Greg


From nick at foobar.org  Thu May  3 17:32:56 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 03 May 2012 23:32:56 +0100
Subject: mulcast assignments
In-Reply-To: <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
Message-ID: <4FA30798.2080503@foobar.org>

On 03/05/2012 21:00, Greg Shepherd wrote:
> Sure, but GLOP predated SSM, and was really only an interim fix for
> the presumed need of mcast address assignments. GLOP only gives you a
> /24 for each ASN where SSM gives you a /8 for every unique unicast
> address you have along with vastly superior security and network
> simplicity.

SSM is indeed a lot simpler and better than GLOP in every conceivable way -
except vendor support.  It needs igmpv3 on all intermediate devices and SSM
support on the client device.  All major desktop operating systems now have
SSM support (OS/X since 10.7/Lion), but there is still lots of older
hardware which either doesn't support igmpv3 or else only supports it in a
very primitive fashion.  This can lead to Unexpected Behaviour in naive
roll-outs.

Nick


From tom at ninjabadger.net  Thu May  3 17:38:38 2012
From: tom at ninjabadger.net (Tom Hill)
Date: Thu, 03 May 2012 23:38:38 +0100
Subject: NUD- ipV6.
In-Reply-To: <7E79416ABDDDFC4E8C85571D0B5CAB3F1390732486@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7E79416ABDDDFC4E8C85571D0B5CAB3F1390732486@INBANSXCHMBSA1.in.alcatel-lucent.com>
Message-ID: <4FA308EE.9090705@ninjabadger.net>

On 03/05/12 16:07, S, Somasundaram (Somasundaram) wrote:
> Hi Everyone, Would like to hear from you on the significance of IPV6
> "Neighbor Unreachability detection (NUD)" specifically on the
> Router-Router link. While quick failure detection protocols like BFD
> are already present to detect the liveliness of the neighbor, does
> the providers/operators find NUD to be useful?
>
> Rgds/ Somasundaram

Coming from an Alcatel address, presumably you're aiming for 
MEF-compliance? i.e. "Can it detect a dead neighbour in 50ms or under?" 
might be a better query.

I'd be interested to hear what people think, anyway. :)

Tom


From gjshep at gmail.com  Thu May  3 17:44:23 2012
From: gjshep at gmail.com (Greg Shepherd)
Date: Thu, 3 May 2012 15:44:23 -0700
Subject: mulcast assignments
In-Reply-To: <4FA30798.2080503@foobar.org>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <4FA30798.2080503@foobar.org>
Message-ID: <CABFReBrLU9P6ESSqizNjzMkcVe-nEdsERDoQJATiwwp3_T60LQ@mail.gmail.com>

On Thu, May 3, 2012 at 3:32 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 03/05/2012 21:00, Greg Shepherd wrote:
>> Sure, but GLOP predated SSM, and was really only an interim fix for
>> the presumed need of mcast address assignments. GLOP only gives you a
>> /24 for each ASN where SSM gives you a /8 for every unique unicast
>> address you have along with vastly superior security and network
>> simplicity.
>
> SSM is indeed a lot simpler and better than GLOP in every conceivable way -
> except vendor support. ?It needs igmpv3 on all intermediate devices and SSM
> support on the client device. ?All major desktop operating systems now have
> SSM support (OS/X since 10.7/Lion), but there is still lots of older
> hardware which either doesn't support igmpv3 or else only supports it in a
> very primitive fashion. ?This can lead to Unexpected Behaviour in naive
> roll-outs.

I haven't seen a piece of network gear without SSM support in a very
long time. The weak link is the applications. It was the OS stacks but
that's finally caught up - it only took it 10 years...

The weakest link is simply multicast deployment - if it's not
everywhere it has little use. That's what AMT is promising to fix. And
with AMT comes the opportunity to bring SSM to non-SSM-capable apps if
it is implemented correctly.

Greg

> Nick
>


From paul4004 at gmail.com  Thu May  3 18:31:42 2012
From: paul4004 at gmail.com (PC)
Date: Thu, 3 May 2012 19:31:42 -0400
Subject: mulcast assignments
In-Reply-To: <CABFReBrLU9P6ESSqizNjzMkcVe-nEdsERDoQJATiwwp3_T60LQ@mail.gmail.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <4FA30798.2080503@foobar.org>
 <CABFReBrLU9P6ESSqizNjzMkcVe-nEdsERDoQJATiwwp3_T60LQ@mail.gmail.com>
Message-ID: <CAJAdsD=cA8JzCm1f6RSB7Jzp_SiyXbYs0P5-sC-nXhPyiB0eJA@mail.gmail.com>

And I've seen plenty of gear without SSM support:

Some of the larger offenders:
Juniper Clusters.
Cisco ASA
Some Linksys managed switches (no IGMP snooping support for it).

I really wouldn't think it'd be that hard to implement SSM if the equipment
had functional ASM support, but that's a story for another day I guess.

Most development for mcast largely occurred between  the last 90s and early
2000s it seems.  Since ~2005 once the hopes of inter-domain multicast
fizzled and IPTV failed to launch in any meaningfully way, multicast
development has largely been neglected by the major equipment vendors and
cast away as some funky thing used by certain enterprise and educational
market segments.

At least, IMHO...



On Thu, May 3, 2012 at 6:44 PM, Greg Shepherd <gjshep at gmail.com> wrote:

> On Thu, May 3, 2012 at 3:32 PM, Nick Hilliard <nick at foobar.org> wrote:
> > On 03/05/2012 21:00, Greg Shepherd wrote:
> >> Sure, but GLOP predated SSM, and was really only an interim fix for
> >> the presumed need of mcast address assignments. GLOP only gives you a
> >> /24 for each ASN where SSM gives you a /8 for every unique unicast
> >> address you have along with vastly superior security and network
> >> simplicity.
> >
> > SSM is indeed a lot simpler and better than GLOP in every conceivable
> way -
> > except vendor support.  It needs igmpv3 on all intermediate devices and
> SSM
> > support on the client device.  All major desktop operating systems now
> have
> > SSM support (OS/X since 10.7/Lion), but there is still lots of older
> > hardware which either doesn't support igmpv3 or else only supports it in
> a
> > very primitive fashion.  This can lead to Unexpected Behaviour in naive
> > roll-outs.
>
> I haven't seen a piece of network gear without SSM support in a very
> long time. The weak link is the applications. It was the OS stacks but
> that's finally caught up - it only took it 10 years...
>
> The weakest link is simply multicast deployment - if it's not
> everywhere it has little use. That's what AMT is promising to fix. And
> with AMT comes the opportunity to bring SSM to non-SSM-capable apps if
> it is implemented correctly.
>
> Greg
>
> > Nick
> >
>
>

From packetjockey at gmail.com  Thu May  3 20:35:10 2012
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Thu, 3 May 2012 21:35:10 -0400
Subject: IPv6 aggregation tool
In-Reply-To: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
References: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
Message-ID: <CALWyk_AxMj8C8GuR9-R2hUbpfoZ1FwkH0B=f7-g3puu=z1wZDQ@mail.gmail.com>

Found this tool that works perfectly.

http://zwitterion.org/software/aggregate-cidr-addresses/aggregate-cidr-addresses

Hoping this'll help someone else here on the list.  Thanks!

On Thu, May 3, 2012 at 4:25 PM, Rafael Rodriguez <packetjockey at gmail.com>wrote:

> Hi list,
>
> I can't seem to find any tools that'll aggregate a list of IPv6 prefixes.
>  Used to 'aggregate' for IPv4, looking for something similar for IPv6.
>  Thanks!
>

From mdevlin at aisle10.net  Thu May  3 20:39:31 2012
From: mdevlin at aisle10.net (Mike Devlin)
Date: Thu, 3 May 2012 21:39:31 -0400
Subject: Network diagram app that shows realtime link utilizatin
Message-ID: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>

Check out InterMapper (http://www.intermapper.com/) Its java based, but
works real well

From jhellenthal at dataix.net  Fri May  4 00:14:37 2012
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Fri, 4 May 2012 01:14:37 -0400
Subject: IPv6 aggregation tool
In-Reply-To: <CABGzhdu46ukHTr7xDhjx_bXvf87ngZgML5xTDz16pxpL-y_Pdg@mail.gmail.com>
References: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
 <CABGzhdu46ukHTr7xDhjx_bXvf87ngZgML5xTDz16pxpL-y_Pdg@mail.gmail.com>
Message-ID: <20120504051437.GC3940@DataIX.net>


The Net::CIDR package contains functions that manipulate lists of
IP netblocks expressed in CIDR notation. The Net::CIDR functions
handle both IPv4 and IPv6 addresses.

WWW: http://search.cpan.org/dist/Net-CIDR/

On Thu, May 03, 2012 at 04:58:27PM -0400, chip wrote:
> Looks like the most recent NetAddr::IP perl module will do it:
> 
> http://search.cpan.org/~miker/NetAddr-IP-4.059/IP.pm#EXPORT_OK
> 
> Take a look at the Compact function.  I think that's what will do it.
> 
> 
> --chip
> 
> On Thu, May 3, 2012 at 4:25 PM, Rafael Rodriguez <packetjockey at gmail.com> wrote:
> > Hi list,
> >
> > I can't seem to find any tools that'll aggregate a list of IPv6 prefixes.
> > ?Used to 'aggregate' for IPv4, looking for something similar for IPv6.
> > ?Thanks!
> 
> 
> 
> -- 
> Just my $.02, your mileage may vary,? batteries not included, etc....
> 

-- 

 - (2^(N-1))


From mohacsi at niif.hu  Fri May  4 01:31:04 2012
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Fri, 4 May 2012 08:31:04 +0200 (CEST)
Subject: NUD- ipV6.
In-Reply-To: <7E79416ABDDDFC4E8C85571D0B5CAB3F1390732486@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7E79416ABDDDFC4E8C85571D0B5CAB3F1390732486@INBANSXCHMBSA1.in.alcatel-lucent.com>
Message-ID: <alpine.BSF.2.00.1205040829210.40024@mignon.ki.iif.hu>

Hi,
 	Not useful for router-router link. However it is very useful for 
first-hop redundancy in data center environment - if you cannot implement 
VRRP for some reason.
 	Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Director Network and Multimedia
NIIF/HUNGARNET, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Thu, 3 May 2012, S, Somasundaram (Somasundaram) wrote:

> Hi Everyone,
>        Would like to hear from you on the significance of IPV6 "Neighbor Unreachability detection (NUD)" specifically on the Router-Router link. While quick failure detection protocols like BFD are already present to detect the liveliness of the neighbor, does the providers/operators find NUD to be useful?
>
> Rgds/
> Somasundaram
>


From jeff.tantsura at ericsson.com  Fri May  4 01:53:00 2012
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Fri, 4 May 2012 02:53:00 -0400
Subject: mulcast assignments
In-Reply-To: <4FA30798.2080503@foobar.org>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <4FA30798.2080503@foobar.org>
Message-ID: <97F7924A-7799-4101-81EC-725562CFF8C5@ericsson.com>

Hi,

All modern routers support mapping from IGMPv2 to PIM SSM, all static, some others thru DNS, etc

Regards,
Jeff

On May 3, 2012, at 12:34 PM, "Nick Hilliard" <nick at foobar.org> wrote:

> On 03/05/2012 21:00, Greg Shepherd wrote:
>> Sure, but GLOP predated SSM, and was really only an interim fix for
>> the presumed need of mcast address assignments. GLOP only gives you a
>> /24 for each ASN where SSM gives you a /8 for every unique unicast
>> address you have along with vastly superior security and network
>> simplicity.
> 
> SSM is indeed a lot simpler and better than GLOP in every conceivable way -
> except vendor support.  It needs igmpv3 on all intermediate devices and SSM
> support on the client device.  All major desktop operating systems now have
> SSM support (OS/X since 10.7/Lion), but there is still lots of older
> hardware which either doesn't support igmpv3 or else only supports it in a
> very primitive fashion.  This can lead to Unexpected Behaviour in naive
> roll-outs.
> 
> Nick
> 


From me at anuragbhatia.com  Fri May  4 04:11:43 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Fri, 4 May 2012 14:41:43 +0530
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
Message-ID: <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>

Curious to know if naked DSL (DSL without dialtone & POTS link) is common
in North America? We don't have that available here in India yet apart from
fact that PSTN <<>> IP connectivity is banned which brings up back to
GSM/CDMA and POTS option.

On Thu, May 3, 2012 at 8:47 PM, Brandt, Ralph <ralph.brandt at pateam.com>wrote:

> Connecticut has such a bill pending. My suggestion to people there, Get
> a ham radio license and a 2 meter transceiver with a  car adapter.......
>
>
>
>
> Ralph Brandt
> York PA
>
>
> -----Original Message-----
> From: Jared Mauch [mailto:jared at puck.nether.net]
> Sent: Wednesday, May 02, 2012 11:29 PM
> To: Frank Bulk
> Cc: NANOG list
> Subject: POTS Ending (Re: Operation Ghost Click)
>
>
> On May 2, 2012, at 9:42 PM, Frank Bulk wrote:
>
> > Many states have regulations regarding how long dial tone needs to
> last
> > during a power outage.  Iowa's PUC (the IUB) requires at least two
> hours of
> > backup power.  We design ours for eight hours.
>
> One thing of note that I've been tracking is this:
>
> http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-be
> coming-obsolete/54321184/1
>
> I'm somewhat dubious about the following claims on the part of the
> carrier.  This is a carrier that wants to meter your cellular data but
> provides wifi service inferior to the cellular data to "offload" their
> wireless network.
>
> -- snip --
> "Bill sponsors and phone companies including AT&T say deregulating
> land-line phone service will increase competition and allow carriers to
> invest in better technology rather than expand a dying service. Some
> consumer organizations fear the change will hurt affordable service,
> especially in rural areas."
> -- snip --
>
> - Jared
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From me at anuragbhatia.com  Fri May  4 04:16:43 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Fri, 4 May 2012 14:46:43 +0530
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>
References: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>
Message-ID: <CAJ0+aXZdnvgywDS_iiNT4FhXOqk5apJUJA4kebn9tHbfp2Ww5Q@mail.gmail.com>

I have been using Zenoss quite a bit. It does not shows exact real time
stat of interface but close to real time + it has ton more options for
monitoring via Zenpacks.


http://community.zenoss.org



On Fri, May 4, 2012 at 7:09 AM, Mike Devlin <mdevlin at aisle10.net> wrote:

> Check out InterMapper (http://www.intermapper.com/) Its java based, but
> works real well
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From cjp at 0x1.net  Fri May  4 09:53:26 2012
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Fri, 4 May 2012 10:53:26 -0400
Subject: Verizon 1xRTT/EVDO for OOB
Message-ID: <CAOMUSPZoniAOaqjNBkmq1HsSv0e65Gv5RKViyv1x3nv_9a4SUQ@mail.gmail.com>

Is anyone using Verizon 1xRTT/EVDO ("3G") for OOB work?  I'm trying to
sort out how exactly to order a compatible service from them.
Unfortunately I don't manage our Verizon Wireless relationship, so I
need to be specific.

Is there a service code or name they refer to this service as?
Looking for low bandwidth, static IP.

-cjp


From paul4004 at gmail.com  Fri May  4 10:19:06 2012
From: paul4004 at gmail.com (PC)
Date: Fri, 4 May 2012 11:19:06 -0400
Subject: Verizon 1xRTT/EVDO for OOB
In-Reply-To: <CAOMUSPZoniAOaqjNBkmq1HsSv0e65Gv5RKViyv1x3nv_9a4SUQ@mail.gmail.com>
References: <CAOMUSPZoniAOaqjNBkmq1HsSv0e65Gv5RKViyv1x3nv_9a4SUQ@mail.gmail.com>
Message-ID: <CAJAdsDn=sZavrFNOLaFuHnYWFt9J9Bb=zS7do1S3UW5oCCyy8w@mail.gmail.com>

Call a business sales rep and ask for "telemetry" or "Machine to Machine"
data plans.


On Fri, May 4, 2012 at 10:53 AM, Christopher J. Pilkington <cjp at 0x1.net>wrote:

> Is anyone using Verizon 1xRTT/EVDO ("3G") for OOB work?  I'm trying to
> sort out how exactly to order a compatible service from them.
> Unfortunately I don't manage our Verizon Wireless relationship, so I
> need to be specific.
>
> Is there a service code or name they refer to this service as?
> Looking for low bandwidth, static IP.
>
> -cjp
>
>

From dhubbard at dino.hostasaurus.com  Fri May  4 10:59:11 2012
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Fri, 4 May 2012 11:59:11 -0400
Subject: Verizon 1xRTT/EVDO for OOB
Message-ID: <FCD26398C5EDE746BFC47F43EA52A173056DEF4F@dino.ad.hostasaurus.com>

We've recently deployed our first Opengear ACM5004-G
http://opengear.com/product-acm5000-g.html and its
working great.  It has cellular (3G), ethernet, USB and
four serial interfaces; you could easily daisy chain a
serial interface to a terminal server if you need more
OOB serial ports.

The setup was very easy; our Verizon rep just required
the ESN off the bottom of the unit since Opengear's already
gone through Verizon's certification process so their
devices' ESN's are known to Verizon as valid for their
network.  He asked what plan we wanted, I told him I wanted
a static public IP, two days later we were up and running.
Since this is considered a M2M (machine to machine) device,
similar to alarm systems and other low bandwidth devices,
you can get monthly plans down to $7 for a few megabytes
and up to normal consumer-level 5 gigs for $50/month type
plans.  The static IP didn't add any cost.

The device has a cool unique feature where you can set it
to keep the cellular interface 'down' for data as its
normal state so no one outside is trying to break into it
or wasting your bandwidth.  Then you send a text message
to the phone number assigned to it and it will bring up
the data interface so you can SSH in.  You can configure
firewall rules on it, use key-based auth, change the ssh
port number, etc.

David

> -----Original Message-----
> From: Christopher J. Pilkington [mailto:cjp at 0x1.net] 
> Sent: Friday, May 04, 2012 10:53 AM
> To: nanog at nanog.org
> Subject: Verizon 1xRTT/EVDO for OOB
> 
> Is anyone using Verizon 1xRTT/EVDO ("3G") for OOB work?  I'm trying to
> sort out how exactly to order a compatible service from them.
> Unfortunately I don't manage our Verizon Wireless relationship, so I
> need to be specific.
> 
> Is there a service code or name they refer to this service as?
> Looking for low bandwidth, static IP.
> 
> -cjp
> 
> 
> 


From tdurack at gmail.com  Fri May  4 11:01:57 2012
From: tdurack at gmail.com (Tim Durack)
Date: Fri, 4 May 2012 12:01:57 -0400
Subject: NYC to DEU packet loss
Message-ID: <CAE_ug14wsNi9RMB0dRWsUeqJfm1S6y_bB+oe0kMknj+1CJQaZg@mail.gmail.com>

Trying to troubleshoot packet loss from NYC to DEU. Traceroute shows:

tdurack at 2ua82715mg:~$ traceroute -I 194.25.250.73
traceroute to 194.25.250.73 (194.25.250.73), 30 hops max, 60 byte packets

 <snip>
 4  216.55.2.85 (216.55.2.85)  1.694 ms  1.698 ms  1.698 ms
 5  vb1010.rar3.nyc-ny.us.xo.net (216.156.0.17)  4.788 ms  4.792 ms  4.791 ms
 6  207.88.14.178.ptr.us.xo.net (207.88.14.178)  1.684 ms  1.461 ms  1.452 ms
 7  62.157.250.245 (62.157.250.245)  40.457 ms  42.980 ms  42.982 ms
 8  hh-eb3-i.HH.DE.NET.DTAG.DE (62.154.32.134)  129.417 ms *  129.422 ms
 9  194.25.250.73 (194.25.250.73)  139.501 ms  136.192 ms  139.236 ms

Packet loss of approx. 20% affects hops 7 and 8, along with end host
9. Loss appears to be data-plane, not control-plane rate limiting.
Affected customer confirms this too :-)

62.157.250.245 is in Deutsche Telekom address spaces, so I'm guessing
this is either a DTAG problem or an issue between XO and DTAG.

I have a ticket open with XO, but I'm having a hard time figuring out
what is ~40ms away from NYC on a path to DEU. Any idea what the
physical path is?

-- 
Tim:>


From me at anuragbhatia.com  Fri May  4 11:11:04 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Fri, 4 May 2012 21:41:04 +0530
Subject: NYC to DEU packet loss
In-Reply-To: <CAE_ug14wsNi9RMB0dRWsUeqJfm1S6y_bB+oe0kMknj+1CJQaZg@mail.gmail.com>
References: <CAE_ug14wsNi9RMB0dRWsUeqJfm1S6y_bB+oe0kMknj+1CJQaZg@mail.gmail.com>
Message-ID: <CAJ0+aXbesHSmU6Y=UQzoPyciy1oOApaa_OQT2f+V5=DqvN5NXA@mail.gmail.com>

You may cross check return path to XO if you have access to any sever on
DTAG or from there looking glass if available. In many cases sudden latency
spike comes because of incorrect return path.

Hope this will help.

(Sent from my mobile device)

Anurag Bhatia
http://anuragbhatia.com
On May 4, 2012 9:32 PM, "Tim Durack" <tdurack at gmail.com> wrote:

> Trying to troubleshoot packet loss from NYC to DEU. Traceroute shows:
>
> tdurack at 2ua82715mg:~$ traceroute -I 194.25.250.73
> traceroute to 194.25.250.73 (194.25.250.73), 30 hops max, 60 byte packets
>
>  <snip>
>  4  216.55.2.85 (216.55.2.85)  1.694 ms  1.698 ms  1.698 ms
>  5  vb1010.rar3.nyc-ny.us.xo.net (216.156.0.17)  4.788 ms  4.792 ms
>  4.791 ms
>  6  207.88.14.178.ptr.us.xo.net (207.88.14.178)  1.684 ms  1.461 ms
>  1.452 ms
>  7  62.157.250.245 (62.157.250.245)  40.457 ms  42.980 ms  42.982 ms
>  8  hh-eb3-i.HH.DE.NET.DTAG.DE (62.154.32.134)  129.417 ms *  129.422 ms
>  9  194.25.250.73 (194.25.250.73)  139.501 ms  136.192 ms  139.236 ms
>
> Packet loss of approx. 20% affects hops 7 and 8, along with end host
> 9. Loss appears to be data-plane, not control-plane rate limiting.
> Affected customer confirms this too :-)
>
> 62.157.250.245 is in Deutsche Telekom address spaces, so I'm guessing
> this is either a DTAG problem or an issue between XO and DTAG.
>
> I have a ticket open with XO, but I'm having a hard time figuring out
> what is ~40ms away from NYC on a path to DEU. Any idea what the
> physical path is?
>
> --
> Tim:>
>
>

From hoyosa at gmail.com  Fri May  4 12:13:43 2012
From: hoyosa at gmail.com (Andrew Hoyos)
Date: Fri, 4 May 2012 10:13:43 -0700
Subject: mulcast assignments
In-Reply-To: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
Message-ID: <4FBED024-1EAA-4DC2-896D-C11E480C9CE0@gmail.com>

On May 3, 2012, at 12:24 PM, Philip Lavine wrote:

>    How do I get a registered multicast block?


If you truly need a globally unique multicast block, and GLOP/RFC6034/SSM won't work, you can submit an application to IANA here:

http://www.iana.org/form/multicast-ipv4

--
Andrew Hoyos
hoyosa at gmail.com





From cscora at apnic.net  Fri May  4 13:45:36 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 5 May 2012 04:45:36 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201205041845.q44IjaHx005529@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,
TRNOG, 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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 05 May, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              406993
    Prefixes after maximum aggregation:                          173163
    Deaggregation factor:                                          2.35
    Unique aggregates announced to Internet:                     198390
Total ASes present in the Internet Routing Table:                 40878
    Prefixes per ASN:                                              9.96
Origin-only ASes present in the Internet Routing Table:           33126
Origin ASes announcing only one prefix:                           15619
Transit ASes present in the Internet Routing Table:                5471
Transit-only ASes present in the Internet Routing Table:            141
Average AS path length visible in the Internet Routing Table:       4.5
    Max AS path length visible:                                      64
    Max AS path prepend of ASN ( 9902)                               56
Prefixes from unregistered ASNs in the Routing Table:               402
    Unregistered ASNs in the Routing Table:                         131
Number of 32-bit ASNs allocated by the RIRs:                       2663
Number of 32-bit ASNs visible in the Routing Table:                2281
Prefixes from 32-bit ASNs in the Routing Table:                    5694
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            114
Number of addresses announced to Internet:                   2544196464
    Equivalent to 151 /8s, 165 /16s and 91 /24s
    Percentage of available address space announced:               68.6
    Percentage of allocated address space announced:               68.7
    Percentage of available address space allocated:               99.9
    Percentage of address space in use by end-sites:               92.5
Total number of prefixes smaller than registry allocations:      174082

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    99714
    Total APNIC prefixes after maximum aggregation:               32251
    APNIC Deaggregation factor:                                    3.09
Prefixes being announced from the APNIC address blocks:           96165
    Unique aggregates announced from the APNIC address blocks:    39795
APNIC Region origin ASes present in the Internet Routing Table:    4682
    APNIC Prefixes per ASN:                                       20.54
APNIC Region origin ASes announcing only one prefix:               1239
APNIC Region transit ASes present in the Internet Routing Table:    728
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         20
Number of APNIC region 32-bit ASNs visible in the Routing Table:    197
Number of APNIC addresses announced to Internet:              644332128
    Equivalent to 38 /8s, 103 /16s and 186 /24s
    Percentage of available APNIC address space announced:         81.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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:                    150460
    Total ARIN prefixes after maximum aggregation:                76455
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           121468
    Unique aggregates announced from the ARIN address blocks:     50615
ARIN Region origin ASes present in the Internet Routing Table:    15067
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5733
ARIN Region transit ASes present in the Internet Routing Table:    1593
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      17
Number of ARIN addresses announced to Internet:               810105536
    Equivalent to 48 /8s, 73 /16s and 58 /24s
    Percentage of available ARIN address space announced:          64.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:                    100875
    Total RIPE prefixes after maximum aggregation:                53982
    RIPE Deaggregation factor:                                     1.87
Prefixes being announced from the RIPE address blocks:            92742
    Unique aggregates announced from the RIPE address blocks:     58472
RIPE Region origin ASes present in the Internet Routing Table:    16538
    RIPE Prefixes per ASN:                                         5.61
RIPE Region origin ASes announcing only one prefix:                8041
RIPE Region transit ASes present in the Internet Routing Table:    2638
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          28
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1535
Number of RIPE addresses announced to Internet:               511625288
    Equivalent to 30 /8s, 126 /16s and 200 /24s
    Percentage of available RIPE address space announced:          82.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:                   41119
    Total LACNIC prefixes after maximum aggregation:               8257
    LACNIC Deaggregation factor:                                   4.98
Prefixes being announced from the LACNIC address blocks:          41000
    Unique aggregates announced from the LACNIC address blocks:   20353
LACNIC Region origin ASes present in the Internet Routing Table:   1595
    LACNIC Prefixes per ASN:                                      25.71
LACNIC Region origin ASes announcing only one prefix:               437
LACNIC Region transit ASes present in the Internet Routing Table:   301
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   527
Number of LACNIC addresses announced to Internet:             100055944
    Equivalent to 5 /8s, 246 /16s and 187 /24s
    Percentage of available LACNIC address space announced:        66.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:                   8955
    Total AfriNIC prefixes after maximum aggregation:              2151
    AfriNIC Deaggregation factor:                                  4.16
Prefixes being announced from the AfriNIC address blocks:          6977
    Unique aggregates announced from the AfriNIC address blocks:   2233
AfriNIC Region origin ASes present in the Internet Routing Table:   536
    AfriNIC Prefixes per ASN:                                     13.02
AfriNIC Region origin ASes announcing only one prefix:              169
AfriNIC Region transit ASes present in the Internet Routing Table:  126
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             31795968
    Equivalent to 1 /8s, 229 /16s and 43 /24s
    Percentage of available AfriNIC address space announced:       47.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     2506      11113        1012   Korea Telecom (KIX)
17974     1866        510          73   PT TELEKOMUNIKASI INDONESIA
 7545     1678        301          86   TPG Internet Pty Ltd
 4755     1575        385         155   TATA Communications formerly 
 9829     1281       1069          30   BSNL National Internet Backbo
 7552     1178       1062          11   Vietel Corporation
 9583     1149         85         494   Sify Limited
 4808     1110       2050         318   CNCGROUP IP network: China169
24560     1027        385         167   Bharti Airtel Ltd., Telemedia
 9498      962        291          65   BHARTI Airtel Ltd.

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     3425       3807         194   bellsouth.net, inc. 
 7029     3373        986         159   Windstream Communications Inc
18566     2092        382         179   Covad Communications 
 1785     1895        680         130   PaeTec Communications, Inc.
20115     1640       1566         619   Charter Communications 
 4323     1606       1044         383   Time Warner Telecom
22773     1591       2911         115   Cox Communications, Inc.
30036     1423        261         761   Mediacom Communications Corp 
 7018     1247      10038         817   AT&T WorldNet Services
11492     1186        216         364   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
 8402     1719        544          16   Corbina telecom
34984      687        188         172   BILISIM TELEKOM
31148      683         37           9   FreeNet ISP
12479      672        669          68   Uni2 Autonomous System
 6830      655       2215         426   UPC Distribution Services
20940      642        208         502   Akamai Technologies European 
 8551      573        360          80   Bezeq International
 3320      534       8442         399   Deutsche Telekom AG
 2578      500         33           7   Demos, Moscow, Russia
 3292      472       2108         406   TDC Tele Danmark

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     1854        332         179   TVCABLE BOGOTA 
28573     1825       1130          59   NET Servicos de Comunicao S.A
 6503     1525        418          65   AVANTEL, S.A. 
 8151     1476       2999         340   UniNet S.A. de C.V. 
 7303     1371        837         188   Telecom Argentina Stet-France
26615      904        761          33   Tim Brasil S.A.
27947      685         74          98   Telconet S.A
11172      643         91          73   Servicios Alestra S.A de C.V 
22047      582        326          15   VTR PUNTO NET S.A. 
 3816      572        242         100   Empresa Nacional de Telecomun

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     1309        958          13   TEDATA
24863      843        274          35   LINKdotNET AS number
 6713      493        649          18   Itissalat Al-MAGHRIB
 3741      263        921         223   The Internet Solution 
12258      197         28          62   Vodacom Internet Company 
33776      186         12          21   Starcomms Nigeria Limited
24835      179         80           8   RAYA Telecom - Egypt
15706      169         32           6   Sudatel Internet Exchange Aut
16637      158        666          83   MTN Network Solutions
29571      157         15          16   Ci Telecom Autonomous system 

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     3425       3807         194   bellsouth.net, inc. 
 7029     3373        986         159   Windstream Communications Inc
 4766     2506      11113        1012   Korea Telecom (KIX)
18566     2092        382         179   Covad Communications 
 1785     1895        680         130   PaeTec Communications, Inc.
17974     1866        510          73   PT TELEKOMUNIKASI INDONESIA
10620     1854        332         179   TVCABLE BOGOTA 
28573     1825       1130          59   NET Servicos de Comunicao S.A
 8402     1719        544          16   Corbina telecom
 7545     1678        301          86   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
 7029      3373        3214      Windstream Communications Inc
18566      2092        1913      Covad Communications 
17974      1866        1793      PT TELEKOMUNIKASI INDONESIA
28573      1825        1766      NET Servicos de Comunicao S.A
 1785      1895        1765      PaeTec Communications, Inc.
 8402      1719        1703      Corbina telecom
10620      1854        1675      TVCABLE BOGOTA 
 7545      1678        1592      TPG Internet Pty Ltd
 4766      2506        1494      Korea Telecom (KIX)
22773      1591        1476      Cox Communications, Inc.

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
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
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.22.160.0/19        31042     Serbia Broadband Autonomous s
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
24.135.0.0/16        31042     Serbia Broadband Autonomous s

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:19       /9:12      /10:28      /11:82      /12:235     
/13:460     /14:831     /15:1494    /16:12241   /17:6244    /18:10575   
/19:20631   /20:29133   /21:30148   /22:40724   /23:38145   /24:212321  
/25:1192    /26:1428    /27:782     /28:165     /29:67      /30:17      
/31:0       /32:19      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3030          3373      Windstream Communications Inc
 6389     2143          3425      bellsouth.net, inc. 
18566     2041          2092      Covad Communications 
10620     1712          1854      TVCABLE BOGOTA 
 8402     1697          1719      Corbina telecom
30036     1367          1423      Mediacom Communications Corp 
 6503     1284          1525      AVANTEL, S.A. 
11492     1149          1186      Cable One 
 8452     1110          1309      TEDATA
 7011     1069          1184      Citizens Utilities 

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:537       2:651       4:14        6:3         8:406      12:1994   
  13:1        14:610      15:12       16:3        17:5        20:23     
  23:164      24:1762     27:1292     31:950      32:57       33:2      
  34:2        36:8        37:426      38:803      40:120      41:3083   
  42:135      44:3        46:1419     47:3        49:414      50:548    
  52:13       54:10       55:12       56:3        57:31       58:958    
  59:488      60:254      61:1208     62:986      63:2036     64:4166   
  65:2252     66:4477     67:2037     68:1160     69:3173     70:905    
  71:485      72:1829     74:2612     75:494      76:317      77:941    
  78:981      79:490      80:1213     81:907      82:680      83:546    
  84:483      85:1210     86:417      87:919      88:338      89:1666   
  90:291      91:4779     92:521      93:1489     94:1507     95:892    
  96:367      97:316      98:864      99:37      100:7       101:185    
 103:1037    106:101     107:191     108:276     109:1331    110:759    
 111:919     112:453     113:601     114:630     115:807     116:925    
 117:722     118:906     119:1232    120:354     121:691     122:1656   
 123:1105    124:1383    125:1247    128:560     129:194     130:252    
 131:623     132:179     133:22      134:245     135:62      136:215    
 137:173     138:356     139:183     140:494     141:242     142:409    
 143:429     144:521     145:70      146:500     147:282     148:770    
 149:306     150:157     151:179     152:466     153:172     154:12     
 155:400     156:217     157:376     158:175     159:544     160:338    
 161:260     162:347     163:191     164:581     165:397     166:573    
 167:465     168:822     169:128     170:860     171:127     172:2      
 173:1763    174:578     175:431     176:649     177:682     178:1356   
 180:1213    181:82      182:962     183:292     184:476     185:1      
 186:2249    187:1070    188:1232    189:1780    190:5536    192:6013   
 193:5292    194:3959    195:3408    196:1274    197:133     198:3655   
 199:4583    200:5835    201:1933    202:8549    203:8611    204:4343   
 205:2504    206:2749    207:2796    208:4045    209:3621    210:2732   
 211:1479    212:1993    213:1932    214:858     215:103     216:5112   
 217:1542    218:543     219:319     220:1232    221:557     222:323    
 223:337    

End of report


From cidr-report at potaroo.net  Fri May  4 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 4 May 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201205042200.q44M00hv076701@wattle.apnic.net>

BGP Update Report
Interval: 26-Apr-12 -to- 03-May-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            67265  2.9%      34.0 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS29049           53989  2.3%     129.8 -- DELTA-TELECOM-AS Delta Telecom LTD.
 3 - AS9829            33372  1.4%      30.6 -- BSNL-NIB National Internet Backbone
 4 - AS12479           28144  1.2%     120.3 -- UNI2-AS France Telecom Espana SA
 5 - AS9198            27568  1.2%     109.0 -- KAZTELECOM-AS JSC Kazakhtelecom
 6 - AS32528           25666  1.1%    6416.5 -- ABBOTT Abbot Labs
 7 - AS1785            22634  1.0%      12.0 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 8 - AS4538            21799  0.9%       4.0 -- ERX-CERNET-BKB China Education and Research Network Center
 9 - AS7029            19731  0.8%      10.3 -- WINDSTREAM - Windstream Communications Inc
10 - AS24560           19089  0.8%      24.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
11 - AS8452            18838  0.8%      21.4 -- TE-AS TE-AS
12 - AS8866            17069  0.7%      39.1 -- BTC-AS Bulgarian Telecommunication Company Plc.
13 - AS17974           17032  0.7%      16.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
14 - AS28573           15644  0.7%      13.2 -- NET Servicos de Comunicao S.A.
15 - AS26615           14630  0.6%      18.4 -- Tim Celular S.A.
16 - AS2118            14368  0.6%      11.0 -- RELCOM-AS OOO "NPO Relcom"
17 - AS1660            14117  0.6%     181.0 -- ANS-CORP-NY - ANS Communications
18 - AS45899           14013  0.6%      42.6 -- VNPT-AS-VN VNPT Corp
19 - AS27738           13750  0.6%      25.0 -- Ecuadortelecom S.A.
20 - AS6713            12978  0.6%      26.4 -- IAM-AS


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS44798           10303  0.4%   10303.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 2 - AS32528           25666  1.1%    6416.5 -- ABBOTT Abbot Labs
 3 - AS3                3283  0.1%     366.0 -- ASTELEK Tele-K Ltd.
 4 - AS32541            1320  0.1%    1320.0 -- SAIRB-AS - Schulman Associates Institutional Review Board, Inc.
 5 - AS17408            3099  0.1%    1033.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 6 - AS55665             990  0.0%     990.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia
 7 - AS13263            1872  0.1%     936.0 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S
 8 - AS34043             910  0.0%     910.0 -- RISS Internet Security Systems SRL
 9 - AS36955             902  0.0%     902.0 -- Matrix-ASN1
10 - AS4658              875  0.0%     875.0 -- NETFRONT-AS Netfront Information Technology Limited,
11 - AS35155             704  0.0%     704.0 -- VERBASOFT-AS Verbasoft ASN
12 - AS1355              699  0.0%     699.0 -- AHMSI-HQDC - American Home Mortgage Servicing, Inc.
13 - AS57767             687  0.0%     687.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network
14 - AS36948            1304  0.1%     652.0 -- KENIC
15 - AS33074             627  0.0%     627.0 -- ISC-NBO1 Internet Systems Consortium, Inc.
16 - AS50026            7703  0.3%     481.4 -- KODOTEL-LTD-AS Kodotel Ltd
17 - AS38857             925  0.0%     462.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd.
18 - AS36029             437  0.0%     437.0 -- CASAS - CASAS
19 - AS49072             430  0.0%     430.0 -- APSUARA-AS TCA Apsuara Ltd.
20 - AS37303             846  0.0%     423.0 -- AIRTELMADA


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 130.36.34.0/24    12815  0.5%   AS32528 -- ABBOTT Abbot Labs
 2 - 130.36.35.0/24    12815  0.5%   AS32528 -- ABBOTT Abbot Labs
 3 - 91.202.212.0/22   10303  0.4%   AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 4 - 62.36.252.0/22     8120  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 5 - 41.43.147.0/24     7890  0.3%   AS8452  -- TE-AS TE-AS
 6 - 62.36.249.0/24     6439  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 7 - 62.36.241.0/24     6076  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 62.36.210.0/24     5943  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
 9 - 194.63.9.0/24      5595  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
10 - 182.64.0.0/16      4360  0.2%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
11 - 202.56.215.0/24    3521  0.1%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
12 - 193.105.129.0/24   3283  0.1%   AS3     -- ASTELEK Tele-K Ltd.
13 - 202.153.174.0/24   3095  0.1%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
14 - 122.161.0.0/16     2688  0.1%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
15 - 115.170.128.0/17   2387  0.1%   AS4847  -- CNIX-AP China Networks Inter-Exchange
16 - 215.65.61.0/24     1753  0.1%   AS5800  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
17 - 216.54.202.0/24    1320  0.1%   AS32541 -- SAIRB-AS - Schulman Associates Institutional Review Board, Inc.
18 - 187.94.82.0/24     1267  0.1%   AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA
19 - 187.94.83.0/24     1267  0.1%   AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA
20 - 189.38.8.0/24      1266  0.1%   AS28306 -- TC Net Inform?tica e Telecomunica??es LTDA

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  4 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 4 May 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201205042200.q44M00UZ076697@wattle.apnic.net>

This report has been generated at Fri May  4 21:12:28 2012 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
        27-04-12    411252      239358
        28-04-12    409883      239786
        29-04-12    409974      239790
        30-04-12    409910      240936
        01-05-12    415235      241036
        02-05-12    415226      239890
        03-05-12    410389      239955
        04-05-12    410788      240155


AS Summary
         41002  Number of ASes in routing system
         17121  Number of ASes announcing only one prefix
          3425  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      112063456  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').

 --- 04May12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     410105   240096   170009    41.5%   All ASes

AS6389      3425      197     3228    94.2%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3414     1798     1616    47.3%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2506     1031     1475    58.9%   KIXS-AS-KR Korea Telecom
AS22773     1592      128     1464    92.0%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS18566     2092      705     1387    66.3%   COVAD - Covad Communications
                                               Co.
AS28573     1825      492     1333    73.0%   NET Servicos de Comunicao S.A.
AS4323      1607      385     1222    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1899      801     1098    57.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1575      531     1044    66.3%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS10620     1854      859      995    53.7%   Telmex Colombia S.A.
AS7552      1178      217      961    81.6%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1371      442      929    67.8%   Telecom Argentina S.A.
AS26615      904       33      871    96.3%   Tim Celular S.A.
AS8151      1478      659      819    55.4%   Uninet S.A. de C.V.
AS18101      947      159      788    83.2%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1110      350      760    68.5%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS17974     1866     1139      727    39.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS9394       845      159      686    81.2%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS7545      1679     1014      665    39.6%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS13977      765      121      644    84.2%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS3356      1098      461      637    58.0%   LEVEL3 Level 3 Communications
AS30036     1424      789      635    44.6%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS17676      691       75      616    89.1%   GIGAINFRA Softbank BB Corp.
AS19262      998      402      596    59.7%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS22561     1000      406      594    59.4%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS24560     1027      444      583    56.8%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS3549      1023      445      578    56.5%   GBLX Global Crossing Ltd.
AS4780       809      254      555    68.6%   SEEDNET Digital United Inc.
AS22047      582       31      551    94.7%   VTR BANDA ANCHA S.A.
AS4804       644       96      548    85.1%   MPX-AS Microplex PTY LTD

Total      43228    14623    28605    66.2%   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-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        27.54.144.0/24       AS45774 SPIDIGO-AS-IN Chandra Net Pvt. Limited, India
        27.54.151.0/24       AS45774 SPIDIGO-AS-IN Chandra Net Pvt. Limited, India
        27.112.114.0/24      AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        91.239.0.0/22        AS52165 PDSINET Personal Development Systems International SRL
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        114.134.16.0/20      AS56310 
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.223.60.0/22      AS6910  DIALTELECOMRO Dial Telecom S.R.L.
        176.115.224.0/20     AS51842 DSCNET DSC.NET SRL
        193.0.190.0/24       AS52165 PDSINET Personal Development Systems International SRL
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        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.122.134.0/24     AS38615 
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel 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.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        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.160.160.0/19     AS18233 
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        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.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.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS27876 American Data Networks
        216.194.160.0/20     AS27876 American Data Networks


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 jeroen at mompl.net  Fri May  4 17:53:37 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Fri, 04 May 2012 15:53:37 -0700
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <CAJ0+aXZdnvgywDS_iiNT4FhXOqk5apJUJA4kebn9tHbfp2Ww5Q@mail.gmail.com>
References: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>
 <CAJ0+aXZdnvgywDS_iiNT4FhXOqk5apJUJA4kebn9tHbfp2Ww5Q@mail.gmail.com>
Message-ID: <4FA45DF1.3030302@mompl.net>

Anurag Bhatia wrote:
> I have been using Zenoss quite a bit. It does not shows exact real time
> stat of interface but close to real time + it has ton more options for

I remember someone here saying that real time monitoring gives you
useless results, because if you make the time of measurement small
enough the utilisation becomes 100%. Measurement of throughput is how
many times this happens during a particular time interval. I hope I
remembered right.

Reminds me of http://en.wikipedia.org/wiki/Parmenides#The_Way_of_Truth

"Moreover he argued that movement was impossible because it requires
moving into "the void", and Parmenides identified "the void" with
nothing, and therefore (by definition) it does not exist. That which
does exist is The Parmenidean One, which is timeless, uniform, and
unchanging"

--
Earthquake Magnitude: 3.3
Date: Friday, May  4, 2012 05:16:08 UTC
Location: Island of Hawaii, Hawaii
Latitude: 19.4332; Longitude: -155.2877
Depth: 2.40 km



From marshall.eubanks at gmail.com  Fri May  4 18:45:14 2012
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Fri, 4 May 2012 19:45:14 -0400
Subject: mulcast assignments
In-Reply-To: <97F7924A-7799-4101-81EC-725562CFF8C5@ericsson.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <4FA30798.2080503@foobar.org>
 <97F7924A-7799-4101-81EC-725562CFF8C5@ericsson.com>
Message-ID: <CAJNg7VKR7MpfFy4MA+7xxkN0-c45hCvQMJH8FhCdW4PtrvkBEw@mail.gmail.com>

On Fri, May 4, 2012 at 2:53 AM, Jeff Tantsura
<jeff.tantsura at ericsson.com> wrote:
> Hi,
>
> All modern routers support mapping from IGMPv2 to PIM SSM, all static, some others thru DNS, etc

I am not sure what you mean here. To support SSM, you need IGMPv3. Most
routers do support IGMPv3, but there is still a fair amount of legacy
gear at various
edges which doesn't.

Regards
Marshall

>
> Regards,
> Jeff
>
> On May 3, 2012, at 12:34 PM, "Nick Hilliard" <nick at foobar.org> wrote:
>
>> On 03/05/2012 21:00, Greg Shepherd wrote:
>>> Sure, but GLOP predated SSM, and was really only an interim fix for
>>> the presumed need of mcast address assignments. GLOP only gives you a
>>> /24 for each ASN where SSM gives you a /8 for every unique unicast
>>> address you have along with vastly superior security and network
>>> simplicity.
>>
>> SSM is indeed a lot simpler and better than GLOP in every conceivable way -
>> except vendor support. ?It needs igmpv3 on all intermediate devices and SSM
>> support on the client device. ?All major desktop operating systems now have
>> SSM support (OS/X since 10.7/Lion), but there is still lots of older
>> hardware which either doesn't support igmpv3 or else only supports it in a
>> very primitive fashion. ?This can lead to Unexpected Behaviour in naive
>> roll-outs.
>>
>> Nick
>>
>


From davidpeahi at gmail.com  Fri May  4 19:05:29 2012
From: davidpeahi at gmail.com (david peahi)
Date: Fri, 4 May 2012 17:05:29 -0700
Subject: Verizon 1xRTT/EVDO for OOB
In-Reply-To: <CAOMUSPZoniAOaqjNBkmq1HsSv0e65Gv5RKViyv1x3nv_9a4SUQ@mail.gmail.com>
References: <CAOMUSPZoniAOaqjNBkmq1HsSv0e65Gv5RKViyv1x3nv_9a4SUQ@mail.gmail.com>
Message-ID: <CAE_aTPMPP_X6QdYc8dP5_xRd45qaR8rff6ONcG4WRimb0uQLow@mail.gmail.com>

We use 1X/EVDO for telemetry polling, but find that the latency is very
high with VZW to Verizon wired networks located in east Texas, so if your
network is on the west coast, every packet traverses the US continent twice
even though the endpoints may be less than 100 miles (or even 1 mile)
apart. VZW also tears down the cell tower to cell modem connection every 24
hours, resulting in IP connectivity loss, so this service is no good for
high availability applications. AT&T Mobility has a similar service, but
they keep the connection up all the time allowing the network designer to
use their service for high availability applications. AT&T's gateways are
in the Pacific Northwest, I believe, so the latency problem is the same.

On Fri, May 4, 2012 at 7:53 AM, Christopher J. Pilkington <cjp at 0x1.net>wrote:

> Is anyone using Verizon 1xRTT/EVDO ("3G") for OOB work?  I'm trying to
> sort out how exactly to order a compatible service from them.
> Unfortunately I don't manage our Verizon Wireless relationship, so I
> need to be specific.
>
> Is there a service code or name they refer to this service as?
> Looking for low bandwidth, static IP.
>
> -cjp
>
>

From jeff.tantsura at ericsson.com  Fri May  4 20:00:47 2012
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Fri, 4 May 2012 21:00:47 -0400
Subject: mulcast assignments
In-Reply-To: <CAJNg7VKR7MpfFy4MA+7xxkN0-c45hCvQMJH8FhCdW4PtrvkBEw@mail.gmail.com>
References: <1336073086.71538.YahooMailNeo@web162902.mail.bf1.yahoo.com>
 <CABFReBpPtXpjDSTuvpgB0JCTttLpGXXvkLq5QvLeHpB+0kSvmw@mail.gmail.com>
 <07C3015B9E21F949AB59B28F2D5B567F05A452@exch-pul-01.interne.smart-telecom.ch>
 <CABFReBouo-p-zkG-am=3v0hwK=jKna_0ozHCBkZrsmpX5xqzNw@mail.gmail.com>
 <4FA30798.2080503@foobar.org>
 <97F7924A-7799-4101-81EC-725562CFF8C5@ericsson.com>
 <CAJNg7VKR7MpfFy4MA+7xxkN0-c45hCvQMJH8FhCdW4PtrvkBEw@mail.gmail.com>
Message-ID: <FFB6C1AF-88C4-41DA-825F-D8E7C7AE29AF@ericsson.com>

Marshall,

That's exactly what the feature does, when it receives a IGMPv1/2 join it adds a preconfigured S and sends S,G (INCLUDE)upstream.
Google for IGMP mapping


Regards,
Jeff

On May 4, 2012, at 1:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com> wrote:

> On Fri, May 4, 2012 at 2:53 AM, Jeff Tantsura
> <jeff.tantsura at ericsson.com> wrote:
>> Hi,
>> 
>> All modern routers support mapping from IGMPv2 to PIM SSM, all static, some others thru DNS, etc
> 
> I am not sure what you mean here. To support SSM, you need IGMPv3. Most
> routers do support IGMPv3, but there is still a fair amount of legacy
> gear at various
> edges which doesn't.
> 
> Regards
> Marshall
> 
>> 
>> Regards,
>> Jeff
>> 
>> On May 3, 2012, at 12:34 PM, "Nick Hilliard" <nick at foobar.org> wrote:
>> 
>>> On 03/05/2012 21:00, Greg Shepherd wrote:
>>>> Sure, but GLOP predated SSM, and was really only an interim fix for
>>>> the presumed need of mcast address assignments. GLOP only gives you a
>>>> /24 for each ASN where SSM gives you a /8 for every unique unicast
>>>> address you have along with vastly superior security and network
>>>> simplicity.
>>> 
>>> SSM is indeed a lot simpler and better than GLOP in every conceivable way -
>>> except vendor support.  It needs igmpv3 on all intermediate devices and SSM
>>> support on the client device.  All major desktop operating systems now have
>>> SSM support (OS/X since 10.7/Lion), but there is still lots of older
>>> hardware which either doesn't support igmpv3 or else only supports it in a
>>> very primitive fashion.  This can lead to Unexpected Behaviour in naive
>>> roll-outs.
>>> 
>>> Nick
>>> 
>> 


From dmiller at tiggee.com  Fri May  4 21:28:34 2012
From: dmiller at tiggee.com (David Miller)
Date: Fri, 04 May 2012 22:28:34 -0400
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA45DF1.3030302@mompl.net>
References: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>
 <CAJ0+aXZdnvgywDS_iiNT4FhXOqk5apJUJA4kebn9tHbfp2Ww5Q@mail.gmail.com>
 <4FA45DF1.3030302@mompl.net>
Message-ID: <4FA49052.2000104@tiggee.com>

On 5/4/2012 6:53 PM, Jeroen van Aart wrote:
> Anurag Bhatia wrote:
>> I have been using Zenoss quite a bit. It does not shows exact real time
>> stat of interface but close to real time + it has ton more options for
>
> I remember someone here saying that real time monitoring gives you
> useless results, because if you make the time of measurement small
> enough the utilisation becomes 100%. Measurement of throughput is how
> many times this happens during a particular time interval. I hope I
> remembered right.
>

I think you are referring to this thread -
  http://www.gossamer-threads.com/lists/nanog/users/149903

and in particular this quote:
  cjp at 0x1 wrote on Feb 16, 2012, 11:25am
     As sampling rate approaches zero, so will the "spikyness" of the 
    graph--ultimately an interface is either sending a frame (*100*%) or
it's 
    not (0%). 

    -cjp


Utilisation doesn't "become 100%", instead measured utilisation will
either be 100% or 0% at each interval.

-DMM



From livio.zanol.puppim at gmail.com  Fri May  4 21:45:57 2012
From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim)
Date: Fri, 4 May 2012 23:45:57 -0300
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA49052.2000104@tiggee.com>
References: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>
 <CAJ0+aXZdnvgywDS_iiNT4FhXOqk5apJUJA4kebn9tHbfp2Ww5Q@mail.gmail.com>
 <4FA45DF1.3030302@mompl.net> <4FA49052.2000104@tiggee.com>
Message-ID: <CAOsW+mf3_DUbM0QZ+0kxi+m=b8UzdCqR0QnR9-TOh2gQSfk3=A@mail.gmail.com>

In a troubleshooting situation I think real time is valid. Off course, is
non-sense doing this for "normal" monitoring...

But firstly define: What's real-time? every second? miliseconds? 10
seconds? 30 seconds? It's subjective nowadays

2012/5/4 David Miller <dmiller at tiggee.com>

> On 5/4/2012 6:53 PM, Jeroen van Aart wrote:
> > Anurag Bhatia wrote:
> >> I have been using Zenoss quite a bit. It does not shows exact real time
> >> stat of interface but close to real time + it has ton more options for
> >
> > I remember someone here saying that real time monitoring gives you
> > useless results, because if you make the time of measurement small
> > enough the utilisation becomes 100%. Measurement of throughput is how
> > many times this happens during a particular time interval. I hope I
> > remembered right.
> >
>
> I think you are referring to this thread -
>  http://www.gossamer-threads.com/lists/nanog/users/149903
>
> and in particular this quote:
>  cjp at 0x1 wrote on Feb 16, 2012, 11:25am
>     As sampling rate approaches zero, so will the "spikyness" of the
>    graph--ultimately an interface is either sending a frame (*100*%) or
> it's
>    not (0%).
>
>    -cjp
>
>
> Utilisation doesn't "become 100%", instead measured utilisation will
> either be 100% or 0% at each interval.
>
> -DMM
>
>
>


-- 
[]'s

L?vio Zanol Puppim

From jeroen at mompl.net  Sat May  5 02:18:34 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Sat, 05 May 2012 00:18:34 -0700
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA49052.2000104@tiggee.com>
References: <CAJbq31HipyF12U9MW2H3wJ788joYAyp12ynuQvCHZ4MDgfXkbQ@mail.gmail.com>
 <CAJ0+aXZdnvgywDS_iiNT4FhXOqk5apJUJA4kebn9tHbfp2Ww5Q@mail.gmail.com>
 <4FA45DF1.3030302@mompl.net> <4FA49052.2000104@tiggee.com>
Message-ID: <4FA4D44A.4010808@mompl.net>

David Miller wrote:
> I think you are referring to this thread -
>   http://www.gossamer-threads.com/lists/nanog/users/149903

> Utilisation doesn't "become 100%", instead measured utilisation will
> either be 100% or 0% at each interval.

Thanks, and yes that was what I was trying to say. :-)

-- 
Earthquake Magnitude: 4.9
Date: Saturday, May  5, 2012 03:34:01 UTC
Location: North Indian Ocean
Latitude: 3.6480; Longitude: 86.7091
Depth: 12.70 km


From bayawa_jhondave at yahoo.com  Sat May  5 22:02:42 2012
From: bayawa_jhondave at yahoo.com (Jhon Dave Bayawa)
Date: Sat, 5 May 2012 20:02:42 -0700 (PDT)
Subject: AD
Message-ID: <1336273362.1974.YahooMailNeo@web111813.mail.gq1.yahoo.com>



?
Jhon Dave Bayawa      

From mpetach at netflight.com  Sun May  6 10:25:06 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 6 May 2012 08:25:06 -0700
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
Message-ID: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>

(tl;dr -- IPv6 link-local definition is ambiguous and inconsistent
across vendors)


I'm curious about what people's perception of valid link-local
addresses is; that is, what specifically makes a valid link-local
address?

The top portion of RFC 4291 lists the link-local prefix as:

2.4. Address Type Identification
   The type of an IPv6 address is identified by the high-order bits of
   the address, as follows:
      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Link-Local unicast   1111111010           FE80::/10       2.5.6
      Global Unicast       (everything else)

(from http://tools.ietf.org/html/rfc4291#section-2.4 )

Thus, it would *seem* that an address such as

fe80:1:1:1::2/64

when configured on an interface for its link-local address would
be a valid link-local address, as it falls within fe80::/10

However, when we read section 2.5.6, we see a different
definition:

2.5.6. Link-Local IPv6 Unicast Addresses


   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |    54 bits  |   64 bits      |
  +----------+-------------+---------------------+
   |1111111010|    0        |   interface ID         |
  +----------+-------------+---------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

(from http://tools.ietf.org/html/rfc4291#section-2.5.6 )

That section indicates that *only* addresses out of
fe80:0:0:0::/64
are valid link local addresses; that is, where the
upper 64 bits are precisely
1111111010000000000000000000000000000000000000000000000000000000

(1111111010 followed by 54 0 bits).

Is section 2.5.6 wrong?  Should it have been written
more like section 2.5.7, that specified the address
as a prefix, followed by 54 bits of subnet ID?  Or
did the authors really intend that most of fe80::/10
remain unused, and *only* a single /64 at the very
start of fe80::/10 would be valid?

I ask this because I'm running into situations where
indeed it seems that some router vendors do literally
only treat fe80::/64 as link-local, and *all other addresses
out of fe80::/10 are treated as global unicast*.

This has potential implications on the types of filtering
people may be assuming their router vendors are doing;
and, with respect to the parent thread, when you talk
about routers forwarding link-local packets, it would
probably be good to verify with your vendors whether
they take the sentence
"Routers must not forward any packets with Link-Local source or
   destination addresses to other links."
to apply to all of fe80::/10, or only to the more
restrictive fe80::/64 specified in section 2.5.6.

I will note that empirical testing shows that even
different product lines from the same vendor show
different behaviours, as though some engineers
read section 2.5.6 in detail, and others simply
read section 2.4, and skipped the fine print.

So...operators...what do *you* think the correct
definition is?  And which way would you prefer
your router vendors to read RFC4291?  Do you
prefer the loose definition from section 2.4, or
do you prefer the stricter definition from section
2.5.6?  Given that the RFC is ambiguous, and
has been for the past six years, I'd tend to think
the IETF doesn't really have a strong position one
way or the other, and is leaving it up to us as
operators to vote with our money, and give guidance
to router vendors as to which definition we'd like them
to follow.

Personally, I know my vote is to go with section 2.4,
rather than leave all the rest of fe80::/10 in an unusable
grey state, where some devices treat it as global unicast,
and others treat it as link-local.  If we all standardize on
the reading in 2.5.6, we leave the entire rest of the /10
fallow, with only one /64 usable from it.

Which way do *you* vote?

Thanks!

Matt


From dr at cluenet.de  Sun May  6 11:04:48 2012
From: dr at cluenet.de (Daniel Roesen)
Date: Sun, 6 May 2012 18:04:48 +0200
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
Message-ID: <20120506160448.GA1176@srv03.cluenet.de>

On Sun, May 06, 2012 at 08:25:06AM -0700, Matthew Petach wrote:
> So...operators...what do *you* think the correct
> definition is?  And which way would you prefer
> your router vendors to read RFC4291?

I would expect them to follow 2.4, even if the current spec says that
the 54 bits between /10 and /64 are supposed to be set to 0 today.
And indeed, it's the most pragmatic way to deal with that fuzzy spec.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From jabley at hopcount.ca  Sun May  6 13:08:56 2012
From: jabley at hopcount.ca (Joe Abley)
Date: Sun, 6 May 2012 18:08:56 +0000
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
Message-ID: <AC8F8B9A-2F96-4AC3-8B59-EB2F65A59B32@hopcount.ca>


On 2012-05-04, at 09:11, Anurag Bhatia wrote:

> Curious to know if naked DSL (DSL without dialtone & POTS link) is common
> in North America?

It's common in Bell Canada's service region in Ontario and Qu?bec. They still provide dial tone on each pair, though, to help techs avoid re-using apparently active pairs when they're out and about (and I think each naked pair is still run through a DMS so they can get their full set of line stats through the normal management platforms).


Joe



From joe at nethead.com  Sun May  6 14:17:50 2012
From: joe at nethead.com (Joe Hamelin)
Date: Sun, 6 May 2012 12:17:50 -0700
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <AC8F8B9A-2F96-4AC3-8B59-EB2F65A59B32@hopcount.ca>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <AC8F8B9A-2F96-4AC3-8B59-EB2F65A59B32@hopcount.ca>
Message-ID: <CAO0-hXYJsyTUkqRg50UTOXxBKVLCC3F4w=fywsuxKbru0bpqLA@mail.gmail.com>

On 2012-05-04, at 09:11, Anurag Bhatia wrote:

> Curious to know if naked DSL (DSL without dialtone & POTS link) is common
> in North America?

Very common for business (retail, etc.) and I have it at home.  We often
call it a dry-loop.  No battery or dial tone is common.  Some LECs do
deliver with dialtone so the customer can call 911 (emergency) in a pinch.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From stephen at sprunk.org  Sun May  6 14:44:12 2012
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sun, 06 May 2012 14:44:12 -0500
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
Message-ID: <4FA6D48C.3090804@sprunk.org>

On 04-May-12 04:11, Anurag Bhatia wrote:
> Curious to know if naked DSL (DSL without dialtone & POTS link) is common
> in North America?

The availability of naked DSL varies from state to state within the US,
depending on how successful the telcos have been at bribing^Wlobbying
the various state regulators and politicians.  Even where not required,
some telcos have ended up offering it anyway due to competition from
other service providers, eg. cable, fixed wireless or mobile wireless.

> PSTN <<>> IP connectivity is banned [in India] which brings up back to
> GSM/CDMA and POTS option.

The naked DSL debate isn't about VoIP; it's really about the mass
adoption of mobile phones.  Some telcos see DSL as an opportunity to
force customers to keep paying for landlines they never use anymore. 
This is a big deal because they have a lot of expensive equipment
they're still paying for--much of it bought to handle the massive influx
of dial-up modem users in the 1990s--that is generating less and less
revenue every year.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2312 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120506/39c2cb51/attachment-0001.bin>

From marka at isc.org  Sun May  6 17:08:21 2012
From: marka at isc.org (Mark Andrews)
Date: Mon, 07 May 2012 08:08:21 +1000
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: Your message of "Sun, 06 May 2012 08:25:06 MST."
 <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
Message-ID: <20120506220821.C02AA206DC14@drugs.dv.isc.org>


Any address withing FE80::/10 is a link local address, however when
you are constructing a link local address you sent bits [11..64]
to zero.  It's quite common for a specification to only use a subset
of the reserved space which is what happens here.

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


From randy at psg.com  Sun May  6 17:48:10 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 06 May 2012 12:48:10 -1000
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <20120506220821.C02AA206DC14@drugs.dv.isc.org>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
 <20120506220821.C02AA206DC14@drugs.dv.isc.org>
Message-ID: <m24nrtapud.wl%randy@psg.com>

> Any address withing FE80::/10 is a link local address

said with great authority.  shame the rfc does not do the same.  matt
points out a spec and implementation problem.

randy


From marka at isc.org  Sun May  6 18:38:06 2012
From: marka at isc.org (Mark Andrews)
Date: Mon, 07 May 2012 09:38:06 +1000
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: Your message of "Sun, 06 May 2012 12:48:10 -1000."
 <m24nrtapud.wl%randy@psg.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
 <20120506220821.C02AA206DC14@drugs.dv.isc.org> <m24nrtapud.wl%randy@psg.com>
Message-ID: <20120506233807.1EBA9206E332@drugs.dv.isc.org>


In message <m24nrtapud.wl%randy at psg.com>, Randy Bush writes:
> > Any address withing FE80::/10 is a link local address
> 
> said with great authority.  shame the rfc does not do the same.  matt
> points out a spec and implementation problem.
> 
> randy

Zero is there to remove the "what do I set these bits to" problem
for auto configuration when you have the standard /64 net/host
split.  The FE80::/10 is still clearly shown in 2.5.6 as a seperate
group of bits.

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


From bayawa_jhondave at yahoo.com  Sun May  6 21:58:11 2012
From: bayawa_jhondave at yahoo.com (Jhon Dave Bayawa)
Date: Sun, 6 May 2012 19:58:11 -0700 (PDT)
Subject: No subject
Message-ID: <1336359491.41196.YahooMailNeo@web111809.mail.gq1.yahoo.com>

thankyou

?
Jhon Dave Bayawa      

From cmadams at hiwaay.net  Sun May  6 22:40:15 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 6 May 2012 22:40:15 -0500
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <m24nrtapud.wl%randy@psg.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
 <20120506220821.C02AA206DC14@drugs.dv.isc.org> <m24nrtapud.wl%randy@psg.com>
Message-ID: <20120507034015.GA23649@hiwaay.net>

Once upon a time, Randy Bush <randy at psg.com> said:
> > Any address withing FE80::/10 is a link local address
> 
> said with great authority.  shame the rfc does not do the same.  matt
> points out a spec and implementation problem.

Well, the prefix length of 10 vs. 64 is hardly relevant when major
routers ignore the part about not forwarding the packets anyway.
-- 
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 mysidia at gmail.com  Mon May  7 00:42:11 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 7 May 2012 00:42:11 -0500
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
Message-ID: <CAAAwwbXh8+eJHRPuz2WtRT_JBqq+x6=AeAedaOGKYLF3Y+uMQA@mail.gmail.com>

On 5/6/12, Matthew Petach <mpetach at netflight.com> wrote:
> I'm curious about what people's perception of valid link-local
> addresses is; that is, what specifically makes a valid link-local
> address?

> The top portion of RFC 4291 lists the link-local prefix as:
[snip]
>       Link-Local unicast   1111111010           FE80::/10       2.5.6
>       Global Unicast       (everything else)

/10 is the link-local prefix.
Every address in this /10 is part of the link-local prefix, and  no IP address
in this /10 is  a valid global unicast address.

> Thus, it would *seem* that an address such as
> fe80:1:1:1::2/64
> when configured on an interface for its link-local address would
> be a valid link-local address, as it falls within fe80::/10

This is in the the link-local prefix,  but not a valid address, it doesn't
follow the format of a link local address as noted by 2.5.6.


[snip]
>    Routers must not forward any packets with Link-Local source or
>    destination addresses to other links.
> (from http://tools.ietf.org/html/rfc4291#section-2.5.6 )
> did the authors really intend that most of fe80::/10
> remain unused, and *only* a single /64 at the very
> start of fe80::/10 would be valid?

The usage of the remainder of the  /10  reserved for link local
is unspecified.; It is conceivable but unlikely that uses might be
defined in the future.

> I ask this because I'm running into situations where
> indeed it seems that some router vendors do literally
> only treat fe80::/64 as link-local, and *all other addresses
> out of fe80::/10 are treated as global unicast*.

This is definitely erroneous,  since fe80::/10 is excluded from the
global unicast address range.

Addresses outside the first /64  _might_  be valid link-local or not,
whatever they are,  they are  definitely not valid global unicast
addresses,   and they  fall within the link-local range: routers are
required to not forward  packets with a source or destination within
the /10.

> This has potential implications on the types of filtering
> people may be assuming their router vendors are doing;

When we are talking about security matters...   it's definitely not
safe to assume your vendor has implemented all the source/destination
address filtering they should.

Implement suitable testing to verify.

--
-JH


From gf at unixsol.org  Mon May  7 07:21:23 2012
From: gf at unixsol.org (Georgi Chorbadzhiyski)
Date: Mon, 07 May 2012 15:21:23 +0300
Subject: Are there any gmail admins reading here?
Message-ID: <4FA7BE43.9060702@unixsol.org>

Guys can somebody send me a contact with gmail admin that can fix this:

> Delivery to the following recipient failed permanently:
> 
>      my at email
> 
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the recipient
> domain. We recommend contacting the other email provider for further information
> about the cause of this error. The error that the other server returned was: 517
> 517 HELO mail-gy0-f174.google.com does not exist. (state 12).

I receive a lot of email forwarded by gmail to my email and I'm having problems only
when the emails are forwarded over the server that says he is mail-gy0-f174.google.com.
This happens to about 20-40 emails each day. Over a thousand more are forwarded by
gmail to me without any problems.

host mail-gy0-f174.google.com 8.8.8.8

  Using domain server:
  Name: 8.8.8.8
  Address: 8.8.8.8#53
  Aliases:

  Host mail-gy0-f174.google.com not found: 3(NXDOMAIN)

I have written to postmaster at gmail.com over a week ago, but as expected the email
send there just goes to /dev/null.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/


From bill at herrin.us  Mon May  7 07:56:13 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 7 May 2012 08:56:13 -0400
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
Message-ID: <CAP-guGWVhANrYv113pbAovSQbssqFr3Mo885eDNN_Jzb5t6irg@mail.gmail.com>

On 5/6/12, Matthew Petach <mpetach at netflight.com> wrote:
> Which way do *you* vote?

Hi Matthew,

Cisco routers forward packets for 127.0.0.0/8 unless explicitly
configured not to, treating it like any other unicast address.

Linux load balancers require a special kernel patch to also use them
as routers because the kernel authors failed to conceive of a
situation where accepting an external packet with a source address
matching a configured interface address was, in fact, a correct thing
to do.

I vote for the Cisco approach. It has occasionally quirky results but
it's also flexible enough to handle situations the protocol designers
didn't conceive of.

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 cgrosskopf at scoe.org  Mon May  7 11:30:37 2012
From: cgrosskopf at scoe.org (Cody Grosskopf)
Date: Mon, 7 May 2012 09:30:37 -0700 (PDT)
Subject: Network diagram app that shows realtime link utilizatin
In-Reply-To: <4FA4D44A.4010808@mompl.net>
Message-ID: <1734169789.9352543.1336408237526.JavaMail.root@zimbra.scoe.org>

Try out Observium...simple install and integration with RANCID.

----- Original Message -----
From: "Jeroen van Aart" <jeroen at mompl.net>
To: "NANOG list" <nanog at nanog.org>
Sent: Saturday, May 5, 2012 12:18:34 AM
Subject: Re: Network diagram app that shows realtime link utilizatin

David Miller wrote:
> I think you are referring to this thread -
>   http://www.gossamer-threads.com/lists/nanog/users/149903

> Utilisation doesn't "become 100%", instead measured utilisation will
> either be 100% or 0% at each interval.

Thanks, and yes that was what I was trying to say. :-)

-- 
Earthquake Magnitude: 4.9
Date: Saturday, May  5, 2012 03:34:01 UTC
Location: North Indian Ocean
Latitude: 3.6480; Longitude: 86.7091
Depth: 12.70 km


Notice to Recipient:  Information contained in this message may be privileged, confidential and  protected from disclosure. If you are not an intended recipient, it is  strictly prohibited to use, disseminate or copy this communication. If you  have received this in error, please reply to the sender and then delete the  message.Thank you.


From bzeeb-lists at lists.zabbadoz.net  Mon May  7 11:36:28 2012
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Mon, 7 May 2012 16:36:28 +0000
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <CAP-guGWVhANrYv113pbAovSQbssqFr3Mo885eDNN_Jzb5t6irg@mail.gmail.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
 <CAP-guGWVhANrYv113pbAovSQbssqFr3Mo885eDNN_Jzb5t6irg@mail.gmail.com>
Message-ID: <546BEFF1-E29B-47D4-9C27-7D0A28E9747F@lists.zabbadoz.net>

On 7. May 2012, at 12:56 , William Herrin wrote:

> I vote for the Cisco approach. It has occasionally quirky results but
> it's also flexible enough to handle situations the protocol designers
> didn't conceive of.

Isn't it a simple scope violation in IPv6 and thus a bug and with that end of story?
I mean the check isn't even overly expensive in this case... and I can't see how much meaningful
other than unicast traffic passing a gateway you could do this way anyway.  The worst
someone sends a small packet and you get a huge reply to a local node that didn't ask
for it keeping your switches and two random machines busy or generating a bit of nd noise,
or ...

19:12:31.257674 02:00:00:00:08:0b > 02:00:00:00:07:0a, ethertype IPv6 (0x86dd), length 70: (hlim 64, next-header ICMPv6 (58) payload length: 16) fe80::ff:fe00:80b > 2001:db8::1: [icmp6 sum ok] ICMP6, echo request, seq 12
19:12:31.257817 02:00:00:00:07:0a > 02:00:00:00:08:0b, ethertype IPv6 (0x86dd), length 118: (hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::ff:fe00:70a > fe80::ff:fe00:80b: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:db8::1, source address fe80::ff:fe00:80b

I actually tried to see if I could cross the atlantic with such a packet,
only to find that I didn't have an exist gateway showing this bug. Oh well,
I am safe.


/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!



From ralph.brandt at pateam.com  Mon May  7 15:06:13 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Mon, 7 May 2012 16:06:13 -0400
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com><4FA18774.7090909@mompl.net><CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com><4FA191D8.7070007@mompl.net><20120502200244.GH9267@hiwaay.net><00c301cd28ce$0d48eef0$27daccd0$@iname.com><D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net><51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B017018ECE05@embgsr24.pateam.com>

I am not sure who uses DSL here.  I have two people I know who use it,
both are dissatisfied and if they had an alternative it woud not be.

 

It is slow, unreliable compared to cable.  

 

Ralph Brandt

Communications Engineer

HP Enterprise Services

Telephone +1 717.506.0802

FAX +1 717.506.4358

Email Ralph.Brandt at pateam.com <mailto:Ralph.Brandt at pateam.com> 

5095 Ritter Rd

Mechanicsburg PA 17055

 

From: Anurag Bhatia [mailto:me at anuragbhatia.com] 
Sent: Friday, May 04, 2012 5:12 AM
To: Brandt, Ralph
Cc: NANOG list
Subject: Re: POTS Ending (Re: Operation Ghost Click)

 

Curious to know if naked DSL (DSL without dialtone & POTS link) is
common in North America? We don't have that available here in India yet
apart from fact that PSTN <<>> IP connectivity is banned which brings up
back to GSM/CDMA and POTS option.

On Thu, May 3, 2012 at 8:47 PM, Brandt, Ralph <ralph.brandt at pateam.com>
wrote:

Connecticut has such a bill pending. My suggestion to people there, Get
a ham radio license and a 2 meter transceiver with a  car adapter.......




Ralph Brandt
York PA



-----Original Message-----
From: Jared Mauch [mailto:jared at puck.nether.net]
Sent: Wednesday, May 02, 2012 11:29 PM
To: Frank Bulk
Cc: NANOG list
Subject: POTS Ending (Re: Operation Ghost Click)


On May 2, 2012, at 9:42 PM, Frank Bulk wrote:

> Many states have regulations regarding how long dial tone needs to
last
> during a power outage.  Iowa's PUC (the IUB) requires at least two
hours of
> backup power.  We design ours for eight hours.

One thing of note that I've been tracking is this:

http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-be
coming-obsolete/54321184/1
<http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-b
e%0d%0acoming-obsolete/54321184/1> 

I'm somewhat dubious about the following claims on the part of the
carrier.  This is a carrier that wants to meter your cellular data but
provides wifi service inferior to the cellular data to "offload" their
wireless network.

-- snip --
"Bill sponsors and phone companies including AT&T say deregulating
land-line phone service will increase competition and allow carriers to
invest in better technology rather than expand a dying service. Some
consumer organizations fear the change will hurt affordable service,
especially in rural areas."
-- snip --

- Jared





 

-- 

 

Anurag Bhatia

anuragbhatia.com <http://anuragbhatia.com> 

or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

 

Linkedin <http://in.linkedin.com/in/anuragbhatia21>  | Twitter
<https://twitter.com/anurag_bhatia>  | Google+
<https://plus.google.com/118280168625121532854> 

 


From jrhett at netconsonance.com  Mon May  7 16:17:07 2012
From: jrhett at netconsonance.com (Jo Rhett)
Date: Mon, 7 May 2012 14:17:07 -0700
Subject: Force10 E Series at the edge?
In-Reply-To: <4F735CFE.30606@bogus.com>
References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com>
 <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp>
 <4F735CFE.30606@bogus.com>
Message-ID: <B4F925B1-F550-4003-922B-8590F49574B2@netconsonance.com>


On Mar 28, 2012, at 11:48 AM, Joel jaeggli wrote:
> On 3/27/12 23:21 , Roberts, Brent wrote:
>> Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP 
> Doesn't support URPF which makes it unsuitable for RTBH and therefore

I was just about to pipe up and say "they do it fine!" and then I remembered that we built automatic filtering provisioning so that each edge customer got filters applied automatically based on their static assignments from us, or from IRR tables if a checkbox was marked. The boxes handled 1000x ports with ~6 filters per port no problem, but yeah, real uRPF would be nice.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.




From jeroen at mompl.net  Mon May  7 16:20:08 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Mon, 07 May 2012 14:20:08 -0700
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <51C66083768C2949A7EB14910C78B017018ECE05@embgsr24.pateam.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com><4FA18774.7090909@mompl.net><CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com><4FA191D8.7070007@mompl.net><20120502200244.GH9267@hiwaay.net><00c301cd28ce$0d48eef0$27daccd0$@iname.com><D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net><51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B017018ECE05@embgsr24.pateam.com>
Message-ID: <4FA83C88.5000900@mompl.net>

Brandt, Ralph wrote:
> I am not sure who uses DSL here.  I have two people I know who use it,
> both are dissatisfied and if they had an alternative it woud not be.

> It is slow, unreliable compared to cable.  

That's a rather bold statement which I find hard to believe. Do you have 
any data to back it up?

Haven't had much problems with DSL. In fact my current service (cruzio) 
has been very stable. With he only notable outage in recent years being 
the one that was caused by some cable being cut somewhere in Southern 
California (rather recent actually).

I think with cable you're stuck with the local monopolist aren't you?

Regards,
Jeroen

-- 
Earthquake Magnitude: 4.1
Date: Monday, May  7, 2012 13:19:36 UTC
Location: southern Iran
Latitude: 27.0547; Longitude: 56.4356
Depth: 35.00 km


From joelja at bogus.com  Mon May  7 17:39:11 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 07 May 2012 22:39:11 +0000
Subject: Force10 E Series at the edge?
In-Reply-To: <B4F925B1-F550-4003-922B-8590F49574B2@netconsonance.com>
References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com>
 <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp>
 <4F735CFE.30606@bogus.com>
 <B4F925B1-F550-4003-922B-8590F49574B2@netconsonance.com>
Message-ID: <4FA84F0F.90105@bogus.com>

On 5/7/12 21:17 , Jo Rhett wrote:
> 
> On Mar 28, 2012, at 11:48 AM, Joel jaeggli wrote:
>> On 3/27/12 23:21 , Roberts, Brent wrote:
>>> Is anyone running an E300 Series Chassis at the internet edge with
>>> multiple Full BGP feeds? 95th percent would be about 300 meg of
>>> traffic. BGP 
>> Doesn't support URPF which makes it unsuitable for RTBH and therefore
> 
> I was just about to pipe up and say "they do it fine!" and then I
> remembered that we built automatic filtering provisioning so that each
> edge customer got filters applied automatically based on their static
> assignments from us, or from IRR tables if a checkbox was marked. The
> boxes handled 1000x ports with ~6 filters per port no problem, but yeah,
> real uRPF would be nice.

Yeah, there's enough CAM on EJ linecards for the resultant rules either
way but I know what I'd prefer.

I do use and am reasonably happy with exascale, just not in that role.

> -- 
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet
> projects.
> 
> 
> 



From Vinny_Abello at Dell.com  Mon May  7 17:46:00 2012
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Mon, 7 May 2012 22:46:00 +0000
Subject: Force10 E Series at the edge?
In-Reply-To: <B4F925B1-F550-4003-922B-8590F49574B2@netconsonance.com>
References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com>
 <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp>
 <4F735CFE.30606@bogus.com>
 <B4F925B1-F550-4003-922B-8590F49574B2@netconsonance.com>
Message-ID: <FD9B2CB2B33E394FAE3B74669547605712B8B1F1@DFWX10HMPTC01.AMER.DELL.COM>

FYI: The E300 is the TeraScale series. If you're looking at used, be sure to get dual-cam cards or else you'll top out at 256k routes. Dual-cam should give you 512K/32K (v4/v6). Next step up would be the E600i with EJ RPM(s) which is the ExaScale series and supports up to 688k/128k (v4/v6) routes (EH RPM's still being the Terascale platform so definitely look for EJ's if considering the E600i). 300Mbps is nothing for the E300. Even 300Gbps is still within spec. It's rated for switching up to 400 Gbps and forwarding capacity of 196 Mpps.

This might be of use to you:

http://i.dell.com/sites/content/shared-content/data-sheets/en/Documents/Dell_Force10_Product_Quick_Reference_Guide.pdf

Although I don't work in the Force10 group (I do work for Dell), if you have any questions I can likely track down the right contacts to help you. Contact me off list. I've been learning the product line myself and playing with an E600i in just the past few months coming from familiarity with Cisco and Brocade. If you haven't used Force10 and FTOS before but are familiar with Cisco IOS, you'll pick it up fast.

-Vinny

-----Original Message-----
From: Jo Rhett [mailto:jrhett at netconsonance.com] 
Sent: Monday, May 07, 2012 5:17 PM
To: Joel jaeggli
Cc: NANOG
Subject: Re: Force10 E Series at the edge?


On Mar 28, 2012, at 11:48 AM, Joel jaeggli wrote:
> On 3/27/12 23:21 , Roberts, Brent wrote:
>> Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP 
> Doesn't support URPF which makes it unsuitable for RTBH and therefore

I was just about to pipe up and say "they do it fine!" and then I remembered that we built automatic filtering provisioning so that each edge customer got filters applied automatically based on their static assignments from us, or from IRR tables if a checkbox was marked. The boxes handled 1000x ports with ~6 filters per port no problem, but yeah, real uRPF would be nice.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.





From Vinny_Abello at Dell.com  Mon May  7 17:48:19 2012
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Mon, 7 May 2012 22:48:19 +0000
Subject: Force10 E Series at the edge?
In-Reply-To: <FD9B2CB2B33E394FAE3B74669547605712B8B1F1@DFWX10HMPTC01.AMER.DELL.COM>
References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com>
 <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp>
 <4F735CFE.30606@bogus.com>
 <B4F925B1-F550-4003-922B-8590F49574B2@netconsonance.com>
 <FD9B2CB2B33E394FAE3B74669547605712B8B1F1@DFWX10HMPTC01.AMER.DELL.COM>
Message-ID: <FD9B2CB2B33E394FAE3B74669547605712B8B212@DFWX10HMPTC01.AMER.DELL.COM>

Sorry... small correction. EH/EJ are line cards with different CAM sizes. RPM's for Terascale vs Exascale are EF vs EH. I'm getting my letters mixed up. :)

-Vinny

-----Original Message-----
From: Abello, Vinny 
Sent: Monday, May 07, 2012 6:46 PM
To: jrhett at netconsonance.com; joelja at bogus.com
Cc: nanog at nanog.org
Subject: RE: Force10 E Series at the edge?

FYI: The E300 is the TeraScale series. If you're looking at used, be sure to get dual-cam cards or else you'll top out at 256k routes. Dual-cam should give you 512K/32K (v4/v6). Next step up would be the E600i with EJ RPM(s) which is the ExaScale series and supports up to 688k/128k (v4/v6) routes (EH RPM's still being the Terascale platform so definitely look for EJ's if considering the E600i). 300Mbps is nothing for the E300. Even 300Gbps is still within spec. It's rated for switching up to 400 Gbps and forwarding capacity of 196 Mpps.

This might be of use to you:

http://i.dell.com/sites/content/shared-content/data-sheets/en/Documents/Dell_Force10_Product_Quick_Reference_Guide.pdf

Although I don't work in the Force10 group (I do work for Dell), if you have any questions I can likely track down the right contacts to help you. Contact me off list. I've been learning the product line myself and playing with an E600i in just the past few months coming from familiarity with Cisco and Brocade. If you haven't used Force10 and FTOS before but are familiar with Cisco IOS, you'll pick it up fast.

-Vinny

-----Original Message-----
From: Jo Rhett [mailto:jrhett at netconsonance.com] 
Sent: Monday, May 07, 2012 5:17 PM
To: Joel jaeggli
Cc: NANOG
Subject: Re: Force10 E Series at the edge?


On Mar 28, 2012, at 11:48 AM, Joel jaeggli wrote:
> On 3/27/12 23:21 , Roberts, Brent wrote:
>> Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP 
> Doesn't support URPF which makes it unsuitable for RTBH and therefore

I was just about to pipe up and say "they do it fine!" and then I remembered that we built automatic filtering provisioning so that each edge customer got filters applied automatically based on their static assignments from us, or from IRR tables if a checkbox was marked. The boxes handled 1000x ports with ~6 filters per port no problem, but yeah, real uRPF would be nice.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.






From jsw at inconcepts.biz  Mon May  7 18:26:29 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 7 May 2012 19:26:29 -0400
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
Message-ID: <CAPWAtbJS6u_xc4u_kN4g0J41tUHASXw=pMQqNz-KNntVDtHLyA@mail.gmail.com>

On Wed, May 2, 2012 at 11:29 PM, Jared Mauch <jared at puck.nether.net> wrote:
> http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-becoming-obsolete/54321184/1

Indiana is doing away with its requirement that the incumbent LECs
supply voice service to rural areas.  Indiana also used to require a
telephone, and posted emergency numbers for the nearest fire, police,
and ambulance service (or 911) near any swimming pool.  The entire
section of state code regarding residential swimming pools has now
been eliminated.  A victory for rural swimming-pool owners everywhere,
now people can drown in home swimming pools with no land lines nearby
to call for help.

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


From lstewart at superb.net  Mon May  7 18:34:43 2012
From: lstewart at superb.net (Landon Stewart)
Date: Mon, 7 May 2012 16:34:43 -0700
Subject: Anyone have a layman's guide to writing an rwhois daemon?
Message-ID: <CABgOHgsFu1-x-2612DwQScGspg=xLVEe1TPK+3MLfczDvLN_sw@mail.gmail.com>

Hi All,

I just wrote a perl daemon that seems to be a working rwhois server but the
RFC is quite difficult to read for me.  When talking about the protocol it
mentions a bunch of requirements and describes them quite strangely
(see rfc2167 section 3.1.9).  Is there a layman's guide around somewhere or
can anyone lend some advice here?  Is what I wrote acting like a real
rwhois server - at least partially?

$ whois -h sirt.hopone.net -p rwhois 66.235.162.21
%rwhois V-1.5:00ffff:00 rwhois.hopone.net (HopOne Internet Corp)
servername:sls-cf7p17
domain:rac13a.com
ipaddress:66.235.162.21
ipaddress:66.235.166.15
ipaddress:66.235.179.110
abusename:Abuse Department
abusephone:206-438-5909
abusemail:abuse at hopone.net
%ok

(If you try running the command above it may or may not be running and may
not succeed)

If anyone knows where to get an rwhois daemon that has hooks for looking up
the data in an external database (not a .cdb database or flat file) I'd
appreciate it a great deal.  I won't want to waste too much time on this if
I can help it but I want a functioning rwhois server.  Our rwhoisd at
rwhois.hopone.net has been broken for a while and for the life of me I
cannot figure out what's wrong with the data formatting it's using.  I
attempted to join the mailing list for ISC's rwhoisd daemon but it's dead
(no volume on the list).

-- 
Landon Stewart <LStewart at Superb.Net>
Sr. Administrator
Systems Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net

From jackson.tim at gmail.com  Mon May  7 18:44:08 2012
From: jackson.tim at gmail.com (Tim Jackson)
Date: Mon, 7 May 2012 18:44:08 -0500
Subject: Anyone have a layman's guide to writing an rwhois daemon?
In-Reply-To: <CABgOHgsFu1-x-2612DwQScGspg=xLVEe1TPK+3MLfczDvLN_sw@mail.gmail.com>
References: <CABgOHgsFu1-x-2612DwQScGspg=xLVEe1TPK+3MLfczDvLN_sw@mail.gmail.com>
Message-ID: <CAK19Y1dSonJWdLALByZt7TRvVUnC9c0fA-m640FTy+iia3=mGA@mail.gmail.com>

Dunno how much help it'll be but here's mine.. It's basic and probably
non-RFC compliant, but it might help.

crapbox.idge.net/~tjackson/rwhois.tar.gz
On May 7, 2012 6:35 PM, "Landon Stewart" <lstewart at superb.net> wrote:

> Hi All,
>
> I just wrote a perl daemon that seems to be a working rwhois server but the
> RFC is quite difficult to read for me.  When talking about the protocol it
> mentions a bunch of requirements and describes them quite strangely
> (see rfc2167 section 3.1.9).  Is there a layman's guide around somewhere or
> can anyone lend some advice here?  Is what I wrote acting like a real
> rwhois server - at least partially?
>
> $ whois -h sirt.hopone.net -p rwhois 66.235.162.21
> %rwhois V-1.5:00ffff:00 rwhois.hopone.net (HopOne Internet Corp)
> servername:sls-cf7p17
> domain:rac13a.com
> ipaddress:66.235.162.21
> ipaddress:66.235.166.15
> ipaddress:66.235.179.110
> abusename:Abuse Department
> abusephone:206-438-5909
> abusemail:abuse at hopone.net
> %ok
>
> (If you try running the command above it may or may not be running and may
> not succeed)
>
> If anyone knows where to get an rwhois daemon that has hooks for looking up
> the data in an external database (not a .cdb database or flat file) I'd
> appreciate it a great deal.  I won't want to waste too much time on this if
> I can help it but I want a functioning rwhois server.  Our rwhoisd at
> rwhois.hopone.net has been broken for a while and for the life of me I
> cannot figure out what's wrong with the data formatting it's using.  I
> attempted to join the mailing list for ISC's rwhoisd daemon but it's dead
> (no volume on the list).
>
> --
> Landon Stewart <LStewart at Superb.Net>
> Sr. Administrator
> Systems Engineering
> Superb Internet Corp - 888-354-6128 x 4199
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>

From me at anuragbhatia.com  Mon May  7 19:08:04 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 8 May 2012 05:38:04 +0530
Subject: Are there any gmail admins reading here?
In-Reply-To: <4FA7BE43.9060702@unixsol.org>
References: <4FA7BE43.9060702@unixsol.org>
Message-ID: <CAJ0+aXZWnJKjTMOqKr1ovMB2Z4bStMDwRC4coJ0U0+OOHieCUQ@mail.gmail.com>

Hello Georgi


I have passed your message to my known contact in Gmail team.



Hopefully you will her back from them.



On Mon, May 7, 2012 at 5:51 PM, Georgi Chorbadzhiyski <gf at unixsol.org>wrote:

> Guys can somebody send me a contact with gmail admin that can fix this:
>
> > Delivery to the following recipient failed permanently:
> >
> >      my at email
> >
> > Technical details of permanent failure:
> > Google tried to deliver your message, but it was rejected by the
> recipient
> > domain. We recommend contacting the other email provider for further
> information
> > about the cause of this error. The error that the other server returned
> was: 517
> > 517 HELO mail-gy0-f174.google.com does not exist. (state 12).
>
> I receive a lot of email forwarded by gmail to my email and I'm having
> problems only
> when the emails are forwarded over the server that says he is
> mail-gy0-f174.google.com.
> This happens to about 20-40 emails each day. Over a thousand more are
> forwarded by
> gmail to me without any problems.
>
> host mail-gy0-f174.google.com 8.8.8.8
>
>  Using domain server:
>  Name: 8.8.8.8
>  Address: 8.8.8.8#53
>  Aliases:
>
>  Host mail-gy0-f174.google.com not found: 3(NXDOMAIN)
>
> I have written to postmaster at gmail.com over a week ago, but as expected
> the email
> send there just goes to /dev/null.
>
> --
> Georgi Chorbadzhiyski
> http://georgi.unixsol.org/
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From mysidia at gmail.com  Mon May  7 23:26:55 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 7 May 2012 23:26:55 -0500
Subject: What is a link-local address?? WAS: Re: JUNOS forwards IPv6
 link-local packets
In-Reply-To: <CAP-guGWVhANrYv113pbAovSQbssqFr3Mo885eDNN_Jzb5t6irg@mail.gmail.com>
References: <CAEmG1=q6aa_33L29fjf7M4S_TQA4ydUT2yo_X22d3q+xFOfSMg@mail.gmail.com>
 <CAP-guGWVhANrYv113pbAovSQbssqFr3Mo885eDNN_Jzb5t6irg@mail.gmail.com>
Message-ID: <CAAAwwbX09=KGt66VizKYefRfNcFKBQXJ09TTmVkLC5FEwn1yEg@mail.gmail.com>

On 5/7/12, William Herrin <bill at herrin.us> wrote:
> On 5/6/12, Matthew Petach <mpetach at netflight.com> wrote:
>> Which way do *you* vote?
> Hi Matthew,
> Cisco routers forward packets for 127.0.0.0/8 unless explicitly
> configured not to, treating it like any other unicast address.

The difference with IPv4,  is the RFC1122 requirement is on hosts to
not allow the network number { 127, <any> } to appear outside the
host.     There's no RFC requirement that a router refuse to forward
traffic with a source or destination address within the reserved
loopback network number.    I a router filters based on source address
it is an added feature. there's no rfc requirement that an IPv4 router
"must not forward a packet with a source or destination address in the
[IPv4] loopback range".    The  Cisco behavior for  127/8    with IPv4
is  therefore quite reasonable.


With IPv6, there is a RFC MUST requirement that such packets to the
link local address space not be forwarded, therefore that Cisco
behavior would be severely broken/ in IPv6 with regards to fe80::/10:
an IPv6 router must not forward such packets as would be allowed with
normal  unicast addresses.

(Even if  the router is configured with one of those addresses, locally)

--
-JH


From cosmin.lupu at gmail.com  Tue May  8 00:16:47 2012
From: cosmin.lupu at gmail.com (Cosmin Lupu)
Date: Tue, 8 May 2012 08:16:47 +0300
Subject: Are there any gmail admins reading here?
In-Reply-To: <4FA7BE43.9060702@unixsol.org>
References: <4FA7BE43.9060702@unixsol.org>
Message-ID: <CAJ-KtNTB_qAOF5GYp5FJgpA1ZJUxSgtRvaBgRo=2OH_GaxCEjA@mail.gmail.com>

you try to deliver an email to *my at email* address. Of course it failed :)

On Mon, May 7, 2012 at 3:21 PM, Georgi Chorbadzhiyski <gf at unixsol.org>wrote:

> Guys can somebody send me a contact with gmail admin that can fix this:
>
> > Delivery to the following recipient failed permanently:
> >
> >      my at email
> >
> > Technical details of permanent failure:
> > Google tried to deliver your message, but it was rejected by the
> recipient
> > domain. We recommend contacting the other email provider for further
> information
> > about the cause of this error. The error that the other server returned
> was: 517
> > 517 HELO mail-gy0-f174.google.com does not exist. (state 12).
>
> I receive a lot of email forwarded by gmail to my email and I'm having
> problems only
> when the emails are forwarded over the server that says he is
> mail-gy0-f174.google.com.
> This happens to about 20-40 emails each day. Over a thousand more are
> forwarded by
> gmail to me without any problems.
>
> host mail-gy0-f174.google.com 8.8.8.8
>
>  Using domain server:
>  Name: 8.8.8.8
>  Address: 8.8.8.8#53
>  Aliases:
>
>  Host mail-gy0-f174.google.com not found: 3(NXDOMAIN)
>
> I have written to postmaster at gmail.com over a week ago, but as expected
> the email
> send there just goes to /dev/null.
>
> --
> Georgi Chorbadzhiyski
> http://georgi.unixsol.org/
>
>

From sr at swisscenter.com  Tue May  8 00:23:23 2012
From: sr at swisscenter.com (=?UTF-8?B?U8OpYmFzdGllbiBSaWNjaW8=?=)
Date: Tue, 08 May 2012 07:23:23 +0200
Subject: Are there any gmail admins reading here?
In-Reply-To: <4FA7BE43.9060702@unixsol.org>
References: <4FA7BE43.9060702@unixsol.org>
Message-ID: <4FA8ADCB.8070703@swisscenter.com>

Maybe you can temporary fix the issue adding mail-gy0-f174.google.com to 
your /etc/hosts file ?

On 07.05.2012 14:21, Georgi Chorbadzhiyski wrote:
> Guys can somebody send me a contact with gmail admin that can fix this:
>
>> Delivery to the following recipient failed permanently:
>>
>>       my at email
>>
>> Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the recipient
>> domain. We recommend contacting the other email provider for further information
>> about the cause of this error. The error that the other server returned was: 517
>> 517 HELO mail-gy0-f174.google.com does not exist. (state 12).
> I receive a lot of email forwarded by gmail to my email and I'm having problems only
> when the emails are forwarded over the server that says he is mail-gy0-f174.google.com.
> This happens to about 20-40 emails each day. Over a thousand more are forwarded by
> gmail to me without any problems.
>
> host mail-gy0-f174.google.com 8.8.8.8
>
>    Using domain server:
>    Name: 8.8.8.8
>    Address: 8.8.8.8#53
>    Aliases:
>
>    Host mail-gy0-f174.google.com not found: 3(NXDOMAIN)
>
> I have written to postmaster at gmail.com over a week ago, but as expected the email
> send there just goes to /dev/null.
>



From jkliachev at neterra.net  Tue May  8 01:55:47 2012
From: jkliachev at neterra.net (Javor Kliachev)
Date: Tue, 08 May 2012 09:55:47 +0300
Subject: L3VPN MPLS - Internal BGP between CE - PE
Message-ID: <4FA8C373.6030609@neterra.net>

Dear Members,

We are ISP which use the same autonomous system to hold External BGP 
sessions
and for implementing L3VPN MPLS ( as internal BGP )

We have a internal office router that receives a "default route" via IBGP
from our border router.

I'll try to briefly explain the problem:

This internal router named (CE) keeps IBGP session with PE router in VRF 
"def".

CE ( GlobalTable ) - PE ( vrf "DEF" )

The aim is "default route" IBGP received from the the ISP provider to be 
redistributed to PE in all vrf "DEF"

After establishing the session we observe that actualy that "default 
route" is propagating successful
in whole vrf "DEF" but MPLS does not set label of this route and the 
traffic is blackholed.

When using another protocol as OSPF and EIGRP everything is OK.

We opened case in Cisco TAC and they explaned that IOS official is not 
support IBGP between PE and CE. Only EBGP.

I would like to know if any of you had similar problem and if there is 
any workaround in Cisco platform.
I see for example Juniper has special commands for resolving this problem.

Thanks in advance!

Best~
Javor Kliachev


From gf at unixsol.org  Tue May  8 03:04:20 2012
From: gf at unixsol.org (Georgi Chorbadzhiyski)
Date: Tue, 08 May 2012 11:04:20 +0300
Subject: Are there any gmail admins reading here?
In-Reply-To: <4FA8ADCB.8070703@swisscenter.com>
References: <4FA7BE43.9060702@unixsol.org> <4FA8ADCB.8070703@swisscenter.com>
Message-ID: <4FA8D384.9090806@unixsol.org>

Around 05/08/2012 08:23 AM, S?bastien Riccio scribbled:
> Maybe you can temporary fix the issue adding mail-gy0-f174.google.com to 
> your /etc/hosts file ?

I just relaxed HELO checking for now but adding it to /etc/hosts is a good
idea.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/


From keegan.holley at sungard.com  Tue May  8 05:29:01 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 8 May 2012 06:29:01 -0400
Subject: L3VPN MPLS - Internal BGP between CE - PE
In-Reply-To: <4FA8C373.6030609@neterra.net>
References: <4FA8C373.6030609@neterra.net>
Message-ID: <CABO8Q6T4zp6yijh8xQ74cgGH_KHtJqp6wQk_mpMBzkGfbXR35A@mail.gmail.com>

What is the next hop of the route?  There should be an IGP route for
the next hop in the iBGP default.  It should have a label or LSP
attached to it.  How was the default generated?  Does it come from a
provider?  If so you may have to set next hop self on the router that
receives the default.  Your provider's PE router IP won't be in your
IGP by default and hence won't be known to your label protocol.

2012/5/8 Javor Kliachev <jkliachev at neterra.net>:
> Dear Members,
>
> We are ISP which use the same autonomous system to hold External BGP
> sessions
> and for implementing L3VPN MPLS ( as internal BGP )
>
> We have a internal office router that receives a "default route" via IBGP
> from our border router.
>
> I'll try to briefly explain the problem:
>
> This internal router named (CE) keeps IBGP session with PE router in VRF
> "def".
>
> CE ( GlobalTable ) - PE ( vrf "DEF" )
>
> The aim is "default route" IBGP received from the the ISP provider to be
> redistributed to PE in all vrf "DEF"
>
> After establishing the session we observe that actualy that "default route"
> is propagating successful
> in whole vrf "DEF" but MPLS does not set label of this route and the traffic
> is blackholed.
>
> When using another protocol as OSPF and EIGRP everything is OK.
>
> We opened case in Cisco TAC and they explaned that IOS official is not
> support IBGP between PE and CE. Only EBGP.
>
> I would like to know if any of you had similar problem and if there is any
> workaround in Cisco platform.
> I see for example Juniper has special commands for resolving this problem.
>
> Thanks in advance!
>
> Best~
> Javor Kliachev
>
>


From jkliachev at neterra.net  Tue May  8 06:10:51 2012
From: jkliachev at neterra.net (Javor Kliachev)
Date: Tue, 08 May 2012 14:10:51 +0300
Subject: L3VPN MPLS - Internal BGP between CE - PE
In-Reply-To: <CABO8Q6T4zp6yijh8xQ74cgGH_KHtJqp6wQk_mpMBzkGfbXR35A@mail.gmail.com>
References: <4FA8C373.6030609@neterra.net>
 <CABO8Q6T4zp6yijh8xQ74cgGH_KHtJqp6wQk_mpMBzkGfbXR35A@mail.gmail.com>
Message-ID: <4FA8FF3B.1000801@neterra.net>


From jkliachev at neterra.net  Tue May  8 06:14:17 2012
From: jkliachev at neterra.net (Javor Kliachev)
Date: Tue, 08 May 2012 14:14:17 +0300
Subject: L3VPN MPLS - Internal BGP between CE - PE
In-Reply-To: <CABO8Q6T4zp6yijh8xQ74cgGH_KHtJqp6wQk_mpMBzkGfbXR35A@mail.gmail.com>
References: <4FA8C373.6030609@neterra.net>
 <CABO8Q6T4zp6yijh8xQ74cgGH_KHtJqp6wQk_mpMBzkGfbXR35A@mail.gmail.com>
Message-ID: <4FA90009.8040507@neterra.net>

Dear Keegan,

Thank you for your advice!

Here is the output of my configuration and applied debug commands:

# PE router config:

The session bellow is between PE and CE:

router bgp 34224
!
address-family ipv4 vrf DEF
   redistribute connected
   redistribute static
   neighbor 10.18.7.1 remote-as 34224
   neighbor 10.18.7.1 description to_echo-sdc_CE
   neighbor 10.18.7.1 activate
   neighbor 10.18.7.1 send-community both
   neighbor 10.18.7.1 prefix-list Permit_Default in
   neighbor 10.18.7.1 route-map NEXT-HOP-SELF in
   neighbor 10.18.7.1 route-map NEXT-HOP-SELF out
   no synchronization
  exit-address-family
end

Hotel-st_PE#show route-map NEXT-HOP-SELF
route-map NEXT-HOP-SELF, permit, sequence 10
   Match clauses:
   Set clauses:
     ip next-hop peer-address
   Policy routing matches: 0 packets, 0 bytes


Hotel-st_PE#show ip bgp vpnv4 vrf DEF summary
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
State/PfxRcd
10.18.7.1       4 34224      85      38   894079    0    0 00:00:02        1

Hotel-st_PE#show ip bgp vpnv4 vrf DEF neighbors 10.18.7.1 routes

    Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 34224:151 (default for vrf DEF)
*>i0.0.0.0          10.18.7.1                0    120      0 i


Hotel-st_PE#show ip route vrf DEF

      23.0.0.0/32 is subnetted, 1 subnets
S       23.23.23.23 [1/0] via 10.18.7.1
      24.0.0.0/32 is subnetted, 1 subnets
C       24.24.24.24 is directly connected, Loopback30
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B       10.100.187.1/32 [200/0] via 10.1.7.253, 00:16:16
C       10.18.7.0/29 is directly connected, Vlan187
B*   0.0.0.0/0 [200/0] via 10.18.7.1, 00:08:40


#### Bravo-plv is other test PE router which should receive and use 
"default route"

bravo-plv_PE#show ip route vrf DEF

      23.0.0.0/32 is subnetted, 1 subnets
B       23.23.23.23 [200/0] via 10.1.1.253, 1w5d
      24.0.0.0/32 is subnetted, 1 subnets
B       24.24.24.24 [200/0] via 10.1.1.253, 2w0d
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.100.187.1/32 is directly connected, Loopback100
B       10.18.7.0/29 [200/0] via 10.1.1.253, 1w6d
B*   0.0.0.0/0 [200/0] via 10.18.7.1, 00:02:37

### this ping is OK because 10.18.7.0/29 is connected on the PE router.

bravo-plv_PE#ping vrf DEF 10.18.7.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.18.7.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

### 212.73.140.140.190 isn't in routing table. It is direct connected 
network on
interface on CE and passing via "default route"

bravo-plv_PE#ping vrf DEF 212.73.140.190

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 212.73.140.190, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This is very strange:
-------------------------------------------------------------------------------------------------
## this output showing that the router not set MPLS label for 0.0.0.0/0

Only for static and the connected networks.

bravo-plv_PE#show ip cef vrf DEF 10.18.7.0/29
10.18.7.0/29
   nexthop 10.1.7.1 Vlan15 label 76 43

bravo-plv_PE#show ip cef vrf DEF 0.0.0.0/0
0.0.0.0/0
   recursive via 87.121.83.25 unusable: no label
-------------------------------------------------------------------------------------------------

Best~

-- 
---
*Javor Kliachev*
IP engineer

Neterra Ltd.
Telephone: +359 2 975 16 16
Fax: +359 2 975 34 36
Mobile: +359 885 988 495
www.neterra.net <http://www.neterra.net>


From keegan.holley at sungard.com  Tue May  8 09:13:23 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 8 May 2012 10:13:23 -0400
Subject: L3VPN MPLS - Internal BGP between CE - PE
In-Reply-To: <4FA8FF3B.1000801@neterra.net>
References: <4FA8C373.6030609@neterra.net>
 <CABO8Q6T4zp6yijh8xQ74cgGH_KHtJqp6wQk_mpMBzkGfbXR35A@mail.gmail.com>
 <4FA8FF3B.1000801@neterra.net>
Message-ID: <CABO8Q6TkLQjuz0XnjP=46+d-QFS2fA+E82mbWxpRVbpyOxi50A@mail.gmail.com>

Look at the route to 87.121.83.25.  It looks like that's the address of
your provider's PE router.  It is most likely not in your IGP and hence
does not have a FEC.  You should set next-hop self on the router that peers
with your ISP.  Also, I might be missing something but I don't usually set
next-hop self using a route map.  I usually just use the update source and
next-hop-self options direct under BGP.


2012/5/8 Javor Kliachev <jkliachev at neterra.net>

> Dear Keegan,
>
> Thank you for your advice!
>
> Here is the output of my configuration and applied debug commands:
>
> #### PE router config:
>
> The session bellow is between PE and CE:
>
> router bgp 34224
> !
> address-family ipv4 vrf DEF
>   redistribute connected
>   redistribute static
>   neighbor 10.18.7.1 remote-as 34224
>   neighbor 10.18.7.1 description to_echo-sdc_CE
>   neighbor 10.18.7.1 activate
>   neighbor 10.18.7.1 send-community both
>   neighbor 10.18.7.1 prefix-list Permit_Default in
>   neighbor 10.18.7.1 route-map NEXT-HOP-SELF in
>   neighbor 10.18.7.1 route-map NEXT-HOP-SELF out
>   no synchronization
>  exit-address-family
> end
>
> *Hotel-st_PE#*show route-map NEXT-HOP-SELF
> route-map NEXT-HOP-SELF, permit, sequence 10
>   Match clauses:
>   Set clauses:
>     ip next-hop peer-address
>   Policy routing matches: 0 packets, 0 bytes
>
>
> *Hotel-st_PE*#show ip bgp vpnv4 vrf DEF summary
> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
> State/PfxRcd
> 10.18.7.1       4 34224      85      38   894079    0    0 00:00:02
> 1
>
> *Hotel-st_PE*#show ip bgp vpnv4 vrf DEF neighbors 10.18.7.1 routes
>
>    Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 34224:151 (default for vrf DEF)
> *>i0.0.0.0          10.18.7.1                0    120      0 i
>
>
> *Hotel-st_PE*#show ip route vrf DEF
>
>      23.0.0.0/32 is subnetted, 1 subnets
> S       23.23.23.23 [1/0] via 10.18.7.1
>      24.0.0.0/32 is subnetted, 1 subnets
> C       24.24.24.24 is directly connected, Loopback30
>      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
> B       10.100.187.1/32 [200/0] via 10.1.7.253, 00:16:16
> C       10.18.7.0/29 is directly connected, Vlan187
> B*   0.0.0.0/0 [200/0] via 10.18.7.1, 00:08:40
>
>
> #### Bravo-plv is other test PE router which should receive and use
> "default route"
>
> *bravo-plv_PE*#show ip route vrf DEF
>
>      23.0.0.0/32 is subnetted, 1 subnets
> B       23.23.23.23 [200/0] via 10.1.1.253, 1w5d
>      24.0.0.0/32 is subnetted, 1 subnets
> B       24.24.24.24 [200/0] via 10.1.1.253, 2w0d
>      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
> C       10.100.187.1/32 is directly connected, Loopback100
> B       10.18.7.0/29 [200/0] via 10.1.1.253, 1w6d
> B*   0.0.0.0/0 [200/0] via 10.18.7.1, 00:02:37
>
> ### this ping is OK because 10.18.7.0/29 is connected on the PE router.
>
> *bravo-plv_PE*#ping vrf DEF 10.18.7.1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 10.18.7.1, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
>
> ### 212.73.140.140.190 isn't in routing table. It is direct connected
> network on
> interface on CE and passing via "default route"
>
> *bravo-plv_PE*#ping vrf DEF 212.73.140.190
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 212.73.140.190, timeout is 2 seconds:
> .....
> Success rate is 0 percent (0/5)
>
> This is very strange:
>
> -------------------------------------------------------------------------------------------------
> ## this output showing that the router not set MPLS label for 0.0.0.0/0
>
> Only for static and the connected networks.
>
> *bravo-plv_PE**#*show ip cef vrf DEF 10.18.7.0/29
> 10.18.7.0/29
>   nexthop 10.1.7.1 Vlan15 label 76 43
>
> *bravo-plv_PE**#*show ip cef vrf DEF 0.0.0.0/0
> 0.0.0.0/0
>   recursive via 87.121.83.25 unusable: no label
>
> -------------------------------------------------------------------------------------------------
>
> Best~
>
>
> On 05/08/2012 01:29 PM, Keegan Holley wrote:
>
> What is the next hop of the route?  There should be an IGP route for
> the next hop in the iBGP default.  It should have a label or LSP
> attached to it.  How was the default generated?  Does it come from a
> provider?  If so you may have to set next hop self on the router that
> receives the default.  Your provider's PE router IP won't be in your
> IGP by default and hence won't be known to your label protocol.
>
> 2012/5/8 Javor Kliachev <jkliachev at neterra.net> <jkliachev at neterra.net>:
>
> Dear Members,
>
> We are ISP which use the same autonomous system to hold External BGP
> sessions
> and for implementing L3VPN MPLS ( as internal BGP )
>
> We have a internal office router that receives a "default route" via IBGP
> from our border router.
>
> I'll try to briefly explain the problem:
>
> This internal router named (CE) keeps IBGP session with PE router in VRF
> "def".
>
> CE ( GlobalTable ) - PE ( vrf "DEF" )
>
> The aim is "default route" IBGP received from the the ISP provider to be
> redistributed to PE in all vrf "DEF"
>
> After establishing the session we observe that actualy that "default route"
> is propagating successful
> in whole vrf "DEF" but MPLS does not set label of this route and the traffic
> is blackholed.
>
> When using another protocol as OSPF and EIGRP everything is OK.
>
> We opened case in Cisco TAC and they explaned that IOS official is not
> support IBGP between PE and CE. Only EBGP.
>
> I would like to know if any of you had similar problem and if there is any
> workaround in Cisco platform.
> I see for example Juniper has special commands for resolving this problem.
>
> Thanks in advance!
>
> Best~
> Javor Kliachev
>
>
>
>
>
> --
> ---
> *Javor Kliachev*
> IP engineer
>
> Neterra Ltd.
> Telephone: +359 2 975 16 16
> Fax: +359 2 975 34 36
> Mobile: +359 885 988 495
> www.neterra.net
>

From sar at knowledgecomputers.net  Tue May  8 15:59:50 2012
From: sar at knowledgecomputers.net (Sarpreet Basi)
Date: Tue, 08 May 2012 13:59:50 -0700
Subject: Cisco Nexus 2k EPLD upgrades question.
Message-ID: <4FA98946.8040103@knowledgecomputers.net>

Hello All,

Looking to deploying 3 x N2K-C2248TP-1GE (2ps 1fan) 4 x10GE slot and 48 
x 10/100/1000, Rather than a 6509.   I'm hesitant with those is the 
maintenance aspect. While ISSUs don't necessarily impact the 2248, EPLD 
upgrades would.  Do you know how upgrades are implemented on the 2248s?  
Is it via the host N7K's own epld process?

Any help on this would be much appreciated.

-- 
Thank You,

Sarpreet Basi
Knowledge Computers
Email: sar at knowledgecomputers.net
Toll-free: 800.967.6609 x102
International: 250.748.0818 x102
Fax: 250.748.3388
Mobile: 250.709.0336

---------------------------
AOL IM: sarpreetb
MSN: sarpreet at hotmail.com
www.knowledgecomputers.net


We Do Maintenance on All EOL Network Product.



From lstewart at superb.net  Tue May  8 17:02:24 2012
From: lstewart at superb.net (Landon Stewart)
Date: Tue, 8 May 2012 15:02:24 -0700
Subject: Anyone have a layman's guide to writing an rwhois daemon?
In-Reply-To: <CAK19Y1dSonJWdLALByZt7TRvVUnC9c0fA-m640FTy+iia3=mGA@mail.gmail.com>
References: <CABgOHgsFu1-x-2612DwQScGspg=xLVEe1TPK+3MLfczDvLN_sw@mail.gmail.com>
 <CAK19Y1dSonJWdLALByZt7TRvVUnC9c0fA-m640FTy+iia3=mGA@mail.gmail.com>
Message-ID: <CABgOHgvkoWrU2X=g84BQTe6H9v2H5Cd+bqiTCGY3cKXwCQoxkQ@mail.gmail.com>

Hey Tim, thanks a lot.  This did help.  I saw how you dealt with some
queries and stuff.  Thanks again!

On 7 May 2012 16:44, Tim Jackson <jackson.tim at gmail.com> wrote:

> Dunno how much help it'll be but here's mine.. It's basic and probably
> non-RFC compliant, but it might help.
>
> crapbox.idge.net/~tjackson/rwhois.tar.gz
> On May 7, 2012 6:35 PM, "Landon Stewart" <lstewart at superb.net> wrote:
>
>> Hi All,
>>
>> I just wrote a perl daemon that seems to be a working rwhois server but
>> the
>> RFC is quite difficult to read for me.  When talking about the protocol it
>> mentions a bunch of requirements and describes them quite strangely
>> (see rfc2167 section 3.1.9).  Is there a layman's guide around somewhere
>> or
>> can anyone lend some advice here?  Is what I wrote acting like a real
>> rwhois server - at least partially?
>>
>> $ whois -h sirt.hopone.net -p rwhois 66.235.162.21
>> %rwhois V-1.5:00ffff:00 rwhois.hopone.net (HopOne Internet Corp)
>> servername:sls-cf7p17
>> domain:rac13a.com
>> ipaddress:66.235.162.21
>> ipaddress:66.235.166.15
>> ipaddress:66.235.179.110
>> abusename:Abuse Department
>> abusephone:206-438-5909
>> abusemail:abuse at hopone.net
>> %ok
>>
>> (If you try running the command above it may or may not be running and may
>> not succeed)
>>
>> If anyone knows where to get an rwhois daemon that has hooks for looking
>> up
>> the data in an external database (not a .cdb database or flat file) I'd
>> appreciate it a great deal.  I won't want to waste too much time on this
>> if
>> I can help it but I want a functioning rwhois server.  Our rwhoisd at
>> rwhois.hopone.net has been broken for a while and for the life of me I
>> cannot figure out what's wrong with the data formatting it's using.  I
>> attempted to join the mailing list for ISC's rwhoisd daemon but it's dead
>> (no volume on the list).
>>
>> --
>> Landon Stewart <LStewart at Superb.Net>
>> Sr. Administrator
>> Systems Engineering
>> Superb Internet Corp - 888-354-6128 x 4199
>> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>>
>


-- 
Landon Stewart <LStewart at Superb.Net>
Sr. Administrator
Systems Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net

From alvarezp at alvarezp.ods.org  Tue May  8 21:48:55 2012
From: alvarezp at alvarezp.ods.org (Octavio Alvarez)
Date: Tue, 08 May 2012 19:48:55 -0700
Subject: VPN over satellite
In-Reply-To: <000e01cd26b5$8e132d90$aa3988b0$@be>
References: <000e01cd26b5$8e132d90$aa3988b0$@be>
Message-ID: <op.wdm6cene4oyyg1@alvarezp-laptop>

On Mon, 30 Apr 2012 02:42:27 -0700, Rens <rens at autempspourmoi.be> wrote:

> Could anybody recommend any hardware that can build a VPN that works well
> over satellite connections? (TCP enhancements)

I'd try splitting the solution into two devices: at the lower layer, the
tunneling part, which can be done with any traditional transport-layer VPN
solution; at the higher layer (prior to encryption), the TCP enhancement
part, for which, I'd look for dedicated and specialized multipoint WAN
optimization devices.

> I want to setup a L3 VPN between 2 satellite connections

That's brave! I'd check with the satellite provider if they are able to
forward your frames directly from VSAT to VSAT without going through the
hub, and, if multiple satellites are used, if they can route between
satellites. Most don't. Those two above are NOT easy to do. They will most
probably make your packets "double-hop", so your latency will be about 1.4
seconds.



-- 
Octavio.


From ml at kenweb.org  Wed May  9 09:19:24 2012
From: ml at kenweb.org (ML)
Date: Wed, 09 May 2012 10:19:24 -0400
Subject: ICMP Redirects from residential customer subnets?
Message-ID: <4FAA7CEC.3030502@kenweb.org>

Last night I was troubleshooting a strange issue where Apple products 
(So far just MacOS and Airports) were losing internet connectivity 
sporadically.

Originally I thought it was an IPv6 transition technology causing the 
problem but the customer couldn't even ping their default GW via v4.

To rule out the customer mistyping/giving us wrong information on what 
they were seeing  I attempted to verify IP connectivity from my DHCP 
server to them.  I pinged the IP they had retrieved via DHCP earlier.

What I got back were ICMP redirects interspersed with echo replies from 
the customer I was pinging.  The redirects were of the form:

"Redirect Host(New nexthop: x.y.z.23)" The nexthop being an IP of the 
customer I was troubleshooting.  Thinking that was very odd I setup an 
ACL on the vlan serving that subnet to log ICMP redirects.  What I found 
was one IP x.y.z.56 sending redirects to IPs on my network as well as 
several IPs outside my network.  As far as I know there is no legitimate 
reason for a residential PC or home gateway to send ICMP redirects. 
There were also a few dozen other IPs on that subnet sending ICMP 
redirects.  A majority of them had 68:7f:74 (Cisco-Linksys) OUIs.  There 
were also some Belkins and one ASUStek OUIs.

The 68:7f:74 source MACs were dispersed amongst many customers not all 
from the same customer.  Which leads me to believe there is either a 
bugged Linksys firmware or an exploited Linksys home gateway causing 
trouble.

Has anyone ever seen something like this before?

Is there any reason to see ICMP redirects on a single homed residential 
subnet? I'm considering adding ICMP redirects to my customer edge ACL 
unless there is a legitimate purpose for these packets.


Thanks
-ML






From nanog at techmonkeys.org  Wed May  9 09:31:04 2012
From: nanog at techmonkeys.org (Jeff Fisher)
Date: Wed, 09 May 2012 08:31:04 -0600
Subject: Network Solutions IPv6 DNS Admin needed
Message-ID: <4FAA7FA8.3050608@techmonkeys.org>

Hi,

I've been sending e-mails to IPV6Req at networksolutions.com; however, it's 
been months now and my IPv6 glue records have not been changed. If 
anyone knows somebody at Network Solutions who can help, please send me 
an off-list reply.

Thanks,
Jeff


From hrlinneweh at sbcglobal.net  Wed May  9 10:44:43 2012
From: hrlinneweh at sbcglobal.net (Henry Linneweh)
Date: Wed, 9 May 2012 08:44:43 -0700 (PDT)
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <4FA6D48C.3090804@sprunk.org>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <4FA6D48C.3090804@sprunk.org>
Message-ID: <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>

Premature and very dangerous move, the public is at great risk, only Sat phones seem
to work when there is a natural disaster. Cell phones for the most part can't even connect
to 911....

-henry



________________________________
 From: Stephen Sprunk <stephen at sprunk.org>
To: nanog at nanog.org 
Sent: Sunday, May 6, 2012 12:44 PM
Subject: Re: POTS Ending (Re: Operation Ghost Click)
 
On 04-May-12 04:11, Anurag Bhatia wrote:
> Curious to know if naked DSL (DSL without dialtone & POTS link) is common
> in North America?

The availability of naked DSL varies from state to state within the US,
depending on how successful the telcos have been at bribing^Wlobbying
the various state regulators and politicians.? Even where not required,
some telcos have ended up offering it anyway due to competition from
other service providers, eg. cable, fixed wireless or mobile wireless.

> PSTN <<>> IP connectivity is banned [in India] which brings up back to
> GSM/CDMA and POTS option.

The naked DSL debate isn't about VoIP; it's really about the mass
adoption of mobile phones.? Some telcos see DSL as an opportunity to
force customers to keep paying for landlines they never use anymore. 
This is a big deal because they have a lot of expensive equipment
they're still paying for--much of it bought to handle the massive influx
of dial-up modem users in the 1990s--that is generating less and less
revenue every year.

S

-- 
Stephen Sprunk? ? ? ?  "God does not play dice."? --Albert Einstein
CCIE #3723? ? ? ?  "God is an inveterate gambler, and He throws the
K5SSS? ? ? ? dice at every possible opportunity." --Stephen Hawking

From randy at psg.com  Wed May  9 10:54:49 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 09 May 2012 08:54:49 -0700
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <4FA6D48C.3090804@sprunk.org>
 <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
Message-ID: <m2sjf9z6wm.wl%randy@psg.com>

> Premature and very dangerous move, the public is at great risk, only
> Sat phones seem to work when there is a natural disaster. Cell phones
> for the most part can't even connect to 911....

tohoku quake
  o land voice phones did not work
  o mobile phone voice did not work
  o mobile phone text did not work
  o land ip worked, adsl, ftth, ...
  o mobile phone data worked!

you could send email but not make a voice call

just a data point

randy


From me at anuragbhatia.com  Wed May  9 11:11:46 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 9 May 2012 21:41:46 +0530
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <m2sjf9z6wm.wl%randy@psg.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <4FA6D48C.3090804@sprunk.org>
 <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
 <m2sjf9z6wm.wl%randy@psg.com>
Message-ID: <CAJ0+aXZtSTJNfA+LyMmWQv_vWjk6e0qxmt6AFxp_aRzvXgXUYg@mail.gmail.com>

On Wed, May 9, 2012 at 9:24 PM, Randy Bush <randy at psg.com> wrote:

> > Premature and very dangerous move, the public is at great risk, only
> > Sat phones seem to work when there is a natural disaster. Cell phones
> > for the most part can't even connect to 911....
>
> tohoku quake
>  o land voice phones did not work
>  o mobile phone voice did not work
>  o mobile phone text did not work
>  o land ip worked, adsl, ftth, ...
>  o mobile phone data worked!
>
> you could send email but not make a voice call
>
> How will you exactly "connect to internet" during such massive downtime? I
mean mobile data is dead, and with dead landline I assume cable broken -
then how exactly one can send email? :)

> just a data point
>
> randy
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From randy at psg.com  Wed May  9 11:14:55 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 09 May 2012 09:14:55 -0700
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <CAJ0+aXZtSTJNfA+LyMmWQv_vWjk6e0qxmt6AFxp_aRzvXgXUYg@mail.gmail.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <4FA6D48C.3090804@sprunk.org>
 <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
 <m2sjf9z6wm.wl%randy@psg.com>
 <CAJ0+aXZtSTJNfA+LyMmWQv_vWjk6e0qxmt6AFxp_aRzvXgXUYg@mail.gmail.com>
Message-ID: <m2obpxz5z4.wl%randy@psg.com>

>>> Premature and very dangerous move, the public is at great risk, only
>>> Sat phones seem to work when there is a natural disaster. Cell phones
>>> for the most part can't even connect to 911....
>>
>> tohoku quake
>>  o land voice phones did not work
>>  o mobile phone voice did not work
>>  o mobile phone text did not work
>>  o land ip worked, adsl, ftth, ...
>>  o mobile phone data worked!
>>
>> you could send email but not make a voice call
>>
>> How will you exactly "connect to internet" during such massive downtime? I
> mean mobile data is dead, and with dead landline I assume cable broken -
> then how exactly one can send email? :)

perhaps you should read a bit more carefully.  mobile data was not dead,
mobile voice was.  land voice was dead, land data was not.

randy


From me at anuragbhatia.com  Wed May  9 11:17:03 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 9 May 2012 21:47:03 +0530
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <m2obpxz5z4.wl%randy@psg.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <4FA6D48C.3090804@sprunk.org>
 <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
 <m2sjf9z6wm.wl%randy@psg.com>
 <CAJ0+aXZtSTJNfA+LyMmWQv_vWjk6e0qxmt6AFxp_aRzvXgXUYg@mail.gmail.com>
 <m2obpxz5z4.wl%randy@psg.com>
Message-ID: <CAJ0+aXbdfgtB=g3ET+22sh8mWAmU3+F00ySpPN==Btm8eARO5Q@mail.gmail.com>

You wrote 0 or o before everything and I felt you mean "zero".


Never mind. Thanks!

On Wed, May 9, 2012 at 9:44 PM, Randy Bush <randy at psg.com> wrote:

> >>> Premature and very dangerous move, the public is at great risk, only
> >>> Sat phones seem to work when there is a natural disaster. Cell phones
> >>> for the most part can't even connect to 911....
> >>
> >> tohoku quake
> >>  o land voice phones did not work
> >>  o mobile phone voice did not work
> >>  o mobile phone text did not work
> >>  o land ip worked, adsl, ftth, ...
> >>  o mobile phone data worked!
> >>
> >> you could send email but not make a voice call
> >>
> >> How will you exactly "connect to internet" during such massive
> downtime? I
> > mean mobile data is dead, and with dead landline I assume cable broken -
> > then how exactly one can send email? :)
>
> perhaps you should read a bit more carefully.  mobile data was not dead,
> mobile voice was.  land voice was dead, land data was not.
>
> randy
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From SNaslund at medline.com  Wed May  9 11:23:27 2012
From: SNaslund at medline.com (Naslund, Steve)
Date: Wed, 9 May 2012 11:23:27 -0500
Subject: POTS Ending (Re: Operation Ghost Click)
In-Reply-To: <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
References: <CBC5B39B.5CA04%jason_livingood@cable.comcast.com>
 <4FA18774.7090909@mompl.net>
 <CAL9jLaZYMiknhPK6FuhuW7sqgx-0FuRqMgQZz4DrbAD7_sDZRw@mail.gmail.com>
 <4FA191D8.7070007@mompl.net> <20120502200244.GH9267@hiwaay.net>
 <00c301cd28ce$0d48eef0$27daccd0$@iname.com>
 <D7DD67A0-CC2C-4895-AE0E-0E04B97C4056@puck.nether.net>
 <51C66083768C2949A7EB14910C78B017018ECCFD@embgsr24.pateam.com>
 <CAJ0+aXbBOn6FVEu1-EN5zU+c2ZQH3JC=SrQZ8Syixixii0-Oqw@mail.gmail.com>
 <4FA6D48C.3090804@sprunk.org>
 <1336578283.37496.YahooMailNeo@web180302.mail.gq1.yahoo.com>
Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0AC3C1FB@MUNEXBE1.medline.com>

Does not matter much when few people are using home landlines and even fewer own sat phones.

Steven Naslund

-----Original Message-----
From: Henry Linneweh [mailto:hrlinneweh at sbcglobal.net] 
Sent: Wednesday, May 09, 2012 10:45 AM
To: Stephen Sprunk; nanog at nanog.org
Subject: Re: POTS Ending (Re: Operation Ghost Click)

Premature and very dangerous move, the public is at great risk, only Sat phones seem
to work when there is a natural disaster. Cell phones for the most part can't even connect
to 911....

-henry



________________________________
 From: Stephen Sprunk <stephen at sprunk.org>
To: nanog at nanog.org 
Sent: Sunday, May 6, 2012 12:44 PM
Subject: Re: POTS Ending (Re: Operation Ghost Click)
 
On 04-May-12 04:11, Anurag Bhatia wrote:
> Curious to know if naked DSL (DSL without dialtone & POTS link) is common
> in North America?

The availability of naked DSL varies from state to state within the US,
depending on how successful the telcos have been at bribing^Wlobbying
the various state regulators and politicians.? Even where not required,
some telcos have ended up offering it anyway due to competition from
other service providers, eg. cable, fixed wireless or mobile wireless.

> PSTN <<>> IP connectivity is banned [in India] which brings up back to
> GSM/CDMA and POTS option.

The naked DSL debate isn't about VoIP; it's really about the mass
adoption of mobile phones.? Some telcos see DSL as an opportunity to
force customers to keep paying for landlines they never use anymore. 
This is a big deal because they have a lot of expensive equipment
they're still paying for--much of it bought to handle the massive influx
of dial-up modem users in the 1990s--that is generating less and less
revenue every year.

S

-- 
Stephen Sprunk? ? ? ?  "God does not play dice."? --Albert Einstein
CCIE #3723? ? ? ?  "God is an inveterate gambler, and He throws the
K5SSS? ? ? ? dice at every possible opportunity." --Stephen Hawking


From streiner at cluebyfour.org  Wed May  9 11:37:07 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 9 May 2012 12:37:07 -0400 (EDT)
Subject: Manhole fire, Pittsburgh PA
Message-ID: <Pine.LNX.4.64.1205091231430.20719@whammy.cluebyfour.org>

There was a manhole/electrical vault fire this morning in Pittsburgh on 
Fifth Ave in the Oakland area.  Numerous telcos/dark fiber providers 
affected (Level3, Verizon, DQE Communications, Fibertech Networks, 
possibly others).  Initial outage accurred at about 03:15 EDT today. 
Current restoration estimate is 15:00-16:00 EDT today.

jms


From rps at maine.edu  Wed May  9 12:10:10 2012
From: rps at maine.edu (Ray Soucy)
Date: Wed, 9 May 2012 13:10:10 -0400
Subject: ICMP Redirects from residential customer subnets?
In-Reply-To: <4FAA7CEC.3030502@kenweb.org>
References: <4FAA7CEC.3030502@kenweb.org>
Message-ID: <CALFTrnN-3+VGu_qr3h31vdYs+_erUUQukYh04yrcj_4QojdWXA@mail.gmail.com>

This is expected and will happen if the consumer router receives traffic
not destined for it for most consumer devices.

In the Ethernet world, it's usually the result of an active MAC falling out
of the table (e.g. disconnected) before the ARP entry on the router
expires.  The default behavior is to flood the unknown packet out every
port.  On a Cisco switch you would be looking at using something like UUFB
(unknown unicast flood blocking).

You might want to keep an eye on resource usage on your routers if you're
seeing this problem. Without UUFB there is a considerable uptick in ARP and
ICMP traffic caused by this behavior, usually driving up CPU.




On Wed, May 9, 2012 at 10:19 AM, ML <ml at kenweb.org> wrote:

> Last night I was troubleshooting a strange issue where Apple products (So
> far just MacOS and Airports) were losing internet connectivity sporadically.
>
> Originally I thought it was an IPv6 transition technology causing the
> problem but the customer couldn't even ping their default GW via v4.
>
> To rule out the customer mistyping/giving us wrong information on what
> they were seeing  I attempted to verify IP connectivity from my DHCP server
> to them.  I pinged the IP they had retrieved via DHCP earlier.
>
> What I got back were ICMP redirects interspersed with echo replies from
> the customer I was pinging.  The redirects were of the form:
>
> "Redirect Host(New nexthop: x.y.z.23)" The nexthop being an IP of the
> customer I was troubleshooting.  Thinking that was very odd I setup an ACL
> on the vlan serving that subnet to log ICMP redirects.  What I found was
> one IP x.y.z.56 sending redirects to IPs on my network as well as several
> IPs outside my network.  As far as I know there is no legitimate reason for
> a residential PC or home gateway to send ICMP redirects. There were also a
> few dozen other IPs on that subnet sending ICMP redirects.  A majority of
> them had 68:7f:74 (Cisco-Linksys) OUIs.  There were also some Belkins and
> one ASUStek OUIs.
>
> The 68:7f:74 source MACs were dispersed amongst many customers not all
> from the same customer.  Which leads me to believe there is either a bugged
> Linksys firmware or an exploited Linksys home gateway causing trouble.
>
> Has anyone ever seen something like this before?
>
> Is there any reason to see ICMP redirects on a single homed residential
> subnet? I'm considering adding ICMP redirects to my customer edge ACL
> unless there is a legitimate purpose for these packets.
>
>
> Thanks
> -ML
>
>
>
>
>
>


-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

From bedard.phil at gmail.com  Wed May  9 13:00:44 2012
From: bedard.phil at gmail.com (Phil)
Date: Wed, 9 May 2012 14:00:44 -0400
Subject: ICMP Redirects from residential customer subnets?
In-Reply-To: <CALFTrnN-3+VGu_qr3h31vdYs+_erUUQukYh04yrcj_4QojdWXA@mail.gmail.com>
References: <4FAA7CEC.3030502@kenweb.org>
 <CALFTrnN-3+VGu_qr3h31vdYs+_erUUQukYh04yrcj_4QojdWXA@mail.gmail.com>
Message-ID: <BF5F249B-2B18-44C0-B644-FD53A029D513@gmail.com>

I've seen this reported as a bug recently with Cisco/Linksys since the device is responding to frames for which it isn't the destination MAC when it should just discard them like the below case.   Not all consumer gateways do this.  

But absolutely agree it is the ARP/MAC age out mismatch issue that is the likely culprit.  

Phil

On May 9, 2012, at 1:10 PM, Ray Soucy <rps at maine.edu> wrote:

> This is expected and will happen if the consumer router receives traffic
> not destined for it for most consumer devices.
> 
> In the Ethernet world, it's usually the result of an active MAC falling out
> of the table (e.g. disconnected) before the ARP entry on the router
> expires.  The default behavior is to flood the unknown packet out every
> port.  On a Cisco switch you would be looking at using something like UUFB
> (unknown unicast flood blocking).
> 
> You might want to keep an eye on resource usage on your routers if you're
> seeing this problem. Without UUFB there is a considerable uptick in ARP and
> ICMP traffic caused by this behavior, usually driving up CPU.
> 
> 
> 
> 
> On Wed, May 9, 2012 at 10:19 AM, ML <ml at kenweb.org> wrote:
> 
>> Last night I was troubleshooting a strange issue where Apple products (So
>> far just MacOS and Airports) were losing internet connectivity sporadically.
>> 
>> Originally I thought it was an IPv6 transition technology causing the
>> problem but the customer couldn't even ping their default GW via v4.
>> 
>> To rule out the customer mistyping/giving us wrong information on what
>> they were seeing  I attempted to verify IP connectivity from my DHCP server
>> to them.  I pinged the IP they had retrieved via DHCP earlier.
>> 
>> What I got back were ICMP redirects interspersed with echo replies from
>> the customer I was pinging.  The redirects were of the form:
>> 
>> "Redirect Host(New nexthop: x.y.z.23)" The nexthop being an IP of the
>> customer I was troubleshooting.  Thinking that was very odd I setup an ACL
>> on the vlan serving that subnet to log ICMP redirects.  What I found was
>> one IP x.y.z.56 sending redirects to IPs on my network as well as several
>> IPs outside my network.  As far as I know there is no legitimate reason for
>> a residential PC or home gateway to send ICMP redirects. There were also a
>> few dozen other IPs on that subnet sending ICMP redirects.  A majority of
>> them had 68:7f:74 (Cisco-Linksys) OUIs.  There were also some Belkins and
>> one ASUStek OUIs.
>> 
>> The 68:7f:74 source MACs were dispersed amongst many customers not all
>> from the same customer.  Which leads me to believe there is either a bugged
>> Linksys firmware or an exploited Linksys home gateway causing trouble.
>> 
>> Has anyone ever seen something like this before?
>> 
>> Is there any reason to see ICMP redirects on a single homed residential
>> subnet? I'm considering adding ICMP redirects to my customer edge ACL
>> unless there is a legitimate purpose for these packets.
>> 
>> 
>> Thanks
>> -ML
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/



From jason at thebaughers.com  Wed May  9 15:24:06 2012
From: jason at thebaughers.com (Jason Baugher)
Date: Wed, 09 May 2012 15:24:06 -0500
Subject: ICMP Redirects from residential customer subnets?
In-Reply-To: <BF5F249B-2B18-44C0-B644-FD53A029D513@gmail.com>
References: <4FAA7CEC.3030502@kenweb.org>
 <CALFTrnN-3+VGu_qr3h31vdYs+_erUUQukYh04yrcj_4QojdWXA@mail.gmail.com>
 <BF5F249B-2B18-44C0-B644-FD53A029D513@gmail.com>
Message-ID: <4FAAD266.6010007@thebaughers.com>

I've seen this with fixed wireless base radios that are bridges. We had 
cases where a customer radio would drop offline, so the base radio would 
drop the mac of the customer router from it's table. New ICMP packets 
coming from the network would hit the wireless base radio and be flooded 
out to all the other client radios. Any other customer routers that were 
Linksys WRT54G and running a specific firmware version (can't remember 
the version) that had previously learned the IP of the now-missing 
customer router would redirect the packet back onto the network, 
reducing the TTL by 1. Since the wireless base would then flood the 
packet out again, we would see a storm of traffic that would 
exponentially increase until the TTL hit 0, at which time it would stop.

If I remember right, I was able to cause the Linksys to stop this 
behavior by enabling the multicast filtering feature, although I'm not 
sure why that did it. Since I couldn't run around to customers and 
enable it on each one, I ended up filtering all ICMP from the network 
towards the customers.

I researched the issue at the time and never found anyone else who had 
mentioned it. I didn't even bother to approach Linksys support.

Jason


On 5/9/2012 1:00 PM, Phil wrote:
> I've seen this reported as a bug recently with Cisco/Linksys since the device is responding to frames for which it isn't the destination MAC when it should just discard them like the below case.   Not all consumer gateways do this.
>
> But absolutely agree it is the ARP/MAC age out mismatch issue that is the likely culprit.
>
> Phil
>
> On May 9, 2012, at 1:10 PM, Ray Soucy<rps at maine.edu>  wrote:
>
>> This is expected and will happen if the consumer router receives traffic
>> not destined for it for most consumer devices.
>>
>> In the Ethernet world, it's usually the result of an active MAC falling out
>> of the table (e.g. disconnected) before the ARP entry on the router
>> expires.  The default behavior is to flood the unknown packet out every
>> port.  On a Cisco switch you would be looking at using something like UUFB
>> (unknown unicast flood blocking).
>>
>> You might want to keep an eye on resource usage on your routers if you're
>> seeing this problem. Without UUFB there is a considerable uptick in ARP and
>> ICMP traffic caused by this behavior, usually driving up CPU.
>>
>>
>>
>>
>> On Wed, May 9, 2012 at 10:19 AM, ML<ml at kenweb.org>  wrote:
>>
>>> Last night I was troubleshooting a strange issue where Apple products (So
>>> far just MacOS and Airports) were losing internet connectivity sporadically.
>>>
>>> Originally I thought it was an IPv6 transition technology causing the
>>> problem but the customer couldn't even ping their default GW via v4.
>>>
>>> To rule out the customer mistyping/giving us wrong information on what
>>> they were seeing  I attempted to verify IP connectivity from my DHCP server
>>> to them.  I pinged the IP they had retrieved via DHCP earlier.
>>>
>>> What I got back were ICMP redirects interspersed with echo replies from
>>> the customer I was pinging.  The redirects were of the form:
>>>
>>> "Redirect Host(New nexthop: x.y.z.23)" The nexthop being an IP of the
>>> customer I was troubleshooting.  Thinking that was very odd I setup an ACL
>>> on the vlan serving that subnet to log ICMP redirects.  What I found was
>>> one IP x.y.z.56 sending redirects to IPs on my network as well as several
>>> IPs outside my network.  As far as I know there is no legitimate reason for
>>> a residential PC or home gateway to send ICMP redirects. There were also a
>>> few dozen other IPs on that subnet sending ICMP redirects.  A majority of
>>> them had 68:7f:74 (Cisco-Linksys) OUIs.  There were also some Belkins and
>>> one ASUStek OUIs.
>>>
>>> The 68:7f:74 source MACs were dispersed amongst many customers not all
>>> from the same customer.  Which leads me to believe there is either a bugged
>>> Linksys firmware or an exploited Linksys home gateway causing trouble.
>>>
>>> Has anyone ever seen something like this before?
>>>
>>> Is there any reason to see ICMP redirects on a single homed residential
>>> subnet? I'm considering adding ICMP redirects to my customer edge ACL
>>> unless there is a legitimate purpose for these packets.
>>>
>>>
>>> Thanks
>>> -ML
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> -- 
>> Ray Soucy
>>
>> Epic Communications Specialist
>>
>> Phone: +1 (207) 561-3526
>>
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>
>
>



From szlists at szarka.org  Wed May  9 15:50:07 2012
From: szlists at szarka.org (Rob Szarka)
Date: Wed, 09 May 2012 16:50:07 -0400
Subject: Question about peering
In-Reply-To: <CAJ0+aXZGJHSnZxoUjHkod3=nAX_ofF5qtbiHBxu8=OvH-J23AA@mail.gmail.com>
References: <CAJ0+aXZGJHSnZxoUjHkod3=nAX_ofF5qtbiHBxu8=OvH-J23AA@mail.gmail.com>
Message-ID: <4FAAD87F.4070106@szarka.org>

On 4/6/2012 3:11 PM, Anurag Bhatia wrote:
> I am curious to know how small ISPs plan peering with other interested
> parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say
> A and C both have open peering policy and assuming the exist in same
> exchange or nearby. Now at this point is there is any "minimum bandwidth"
> considerations? Say if A and C have 1Gbps + of flowing traffic - very
> likely peering would be good idea to save transit costs to B. But if A and
> C have very low levels - does it still makes sense? Does peering costs
> anything if ISPs are in same exchange? Does at low traffic level it makes
> more sense to keep on reaching other ISPs via big transit provider?

One thing to consider is that peering can benefit both networks not just 
because of bandwidth savings, but because (given sufficient clue) they 
can deliver better performance and reliability to their mutual customers.



From keegan.holley at sungard.com  Wed May  9 19:06:37 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 9 May 2012 20:06:37 -0400
Subject: Question about peering
In-Reply-To: <CAJ0+aXZGJHSnZxoUjHkod3=nAX_ofF5qtbiHBxu8=OvH-J23AA@mail.gmail.com>
References: <CAJ0+aXZGJHSnZxoUjHkod3=nAX_ofF5qtbiHBxu8=OvH-J23AA@mail.gmail.com>
Message-ID: <CABO8Q6TVJDUvnUYPEHE2kN-YQ_1B2h3F3swwHYWfiq+1JOjM1Q@mail.gmail.com>

Most of the time no.  ISP A and ISP C probably don't have alot of traffic
destined for each other's AS's.  Without other peers in an IX sort of model
the link would probably be mostly devoid of (useful) traffic. Although, if
ISP A and C were small regional ISP's and they could get free peering from
someone like netflix that may be worth while, but I digress.   Another
interesting occurrence would be if ISP A shifted it's metrics to force it's
transit traffic into ISP C's AS offloading the cost of the eventual ISP B
hop to ISP C. (assuming someone announces the full table)  I've also seen
ISP A re-announce ISP C's routes to their upstreams with preferred metrics
in order to make the link "one-sided" and begin billing ISP A.



2012/4/6 Anurag Bhatia <me at anuragbhatia.com>

> Hello everyone
>
>
>
> I am curious to know how small ISPs plan peering with other interested
> parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say
> A and C both have open peering policy and assuming the exist in same
> exchange or nearby. Now at this point is there is any "minimum bandwidth"
> considerations? Say if A and C have 1Gbps + of flowing traffic - very
> likely peering would be good idea to save transit costs to B. But if A and
> C have very low levels - does it still makes sense? Does peering costs
> anything if ISPs are in same exchange? Does at low traffic level it makes
> more sense to keep on reaching other ISPs via big transit provider?
>
>
>
> Thanks.
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
> Linkedin: http://linkedin.anuragbhatia.com
>
>

From hank at efes.iucc.ac.il  Thu May 10 01:49:18 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 10 May 2012 09:49:18 +0300
Subject: Looking for W7 whois freeware
Message-ID: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>

I am looking for a Window 7 GUI utility that does raw whois - not the 
standard domain lookup, but rather allows me to specify and change the 
whois server I am talking to and allows me to customize the whois search 
string for IPs or ASNs or anything else a whois server will accept, like:
"-B -G as378".

I know of ezwhois but am looking for something better (for example - they 
don't have whois.ripe.net listed - one can add it but not save it).

Thanks,
Hank 



From ops.lists at gmail.com  Thu May 10 02:24:29 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 10 May 2012 12:54:29 +0530
Subject: Looking for W7 whois freeware
In-Reply-To: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
Message-ID: <CAArzuou2AO_6A8_+3pQJmRBcboGdR9trcLocugz34FaquEQNXA@mail.gmail.com>

Did you try this one Hank?

http://www.mcafee.com/us/downloads/free-tools/trout.aspx

On Thu, May 10, 2012 at 12:19 PM, Hank Nussbacher <hank at efes.iucc.ac.il> wrote:
> I am looking for a Window 7 GUI utility that does raw whois - not the
> standard domain lookup, but rather allows me to specify and change the whois
> server I am talking to and allows me to customize the whois search string
> for IPs or ASNs or anything else a whois server will accept, like:
> "-B -G as378".
>
> I know of ezwhois but am looking for something better (for example - they
> don't have whois.ripe.net listed - one can add it but not save it).
>
> Thanks,
> Hank
>



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From hank at efes.iucc.ac.il  Thu May 10 03:03:10 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 10 May 2012 11:03:10 +0300
Subject: Looking for W7 whois freeware
In-Reply-To: <CAArzuou2AO_6A8_+3pQJmRBcboGdR9trcLocugz34FaquEQNXA@mail.g
 mail.com>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
Message-ID: <5.1.1.6.2.20120510110239.01f8a4c8@efes.iucc.ac.il>

At 12:54 10/05/2012 +0530, Suresh Ramasubramanian wrote:

>Did you try this one Hank?
>
>http://www.mcafee.com/us/downloads/free-tools/trout.aspx

That is not a whois client.  Doesn't come close to what I need.  Thanks anyway.

-Hank


>On Thu, May 10, 2012 at 12:19 PM, Hank Nussbacher <hank at efes.iucc.ac.il> 
>wrote:
> > I am looking for a Window 7 GUI utility that does raw whois - not the
> > standard domain lookup, but rather allows me to specify and change the 
> whois
> > server I am talking to and allows me to customize the whois search string
> > for IPs or ASNs or anything else a whois server will accept, like:
> > "-B -G as378".
> >
> > I know of ezwhois but am looking for something better (for example - they
> > don't have whois.ripe.net listed - one can add it but not save it).
> >
> > Thanks,
> > Hank
> >
>
>
>
>--
>Suresh Ramasubramanian (ops.lists at gmail.com)



From ops.lists at gmail.com  Thu May 10 03:16:39 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 10 May 2012 13:46:39 +0530
Subject: Looking for W7 whois freeware
In-Reply-To: <5.1.1.6.2.20120510110239.01f8a4c8@efes.iucc.ac.il>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120510110239.01f8a4c8@efes.iucc.ac.il>
Message-ID: <CAArzuoucwBfCheeKkMJJWY=+-K8-7jiOogJ1nQdBsu-KCKiXog@mail.gmail.com>

Bah. "Built in, simple whois client" indeed.

On Thu, May 10, 2012 at 1:33 PM, Hank Nussbacher <hank at efes.iucc.ac.il> wrote:
>>
>> http://www.mcafee.com/us/downloads/free-tools/trout.aspx
>
>
> That is not a whois client. ?Doesn't come close to what I need. ?Thanks
> anyway.



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From lists at mtin.net  Thu May 10 09:23:16 2012
From: lists at mtin.net (Justin Wilson)
Date: Thu, 10 May 2012 10:23:16 -0400
Subject: Question about peering
In-Reply-To: <4FAAD87F.4070106@szarka.org>
Message-ID: <CBD1475F.2E90D%lists@mtin.net>

	We are cross-connected with several ISPs at a couple of data centers.
Very helpful in one situation as several of us share a soft-switch.

	Justin

-----Original Message-----
From: Rob Szarka <szlists at szarka.org>
Date: Wednesday, May 9, 2012 4:50 PM
To: <nanog at nanog.org>
Subject: Re: Question about peering

>On 4/6/2012 3:11 PM, Anurag Bhatia wrote:
>> I am curious to know how small ISPs plan peering with other interested
>> parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and
>>say
>> A and C both have open peering policy and assuming the exist in same
>> exchange or nearby. Now at this point is there is any "minimum
>>bandwidth"
>> considerations? Say if A and C have 1Gbps + of flowing traffic - very
>> likely peering would be good idea to save transit costs to B. But if A
>>and
>> C have very low levels - does it still makes sense? Does peering costs
>> anything if ISPs are in same exchange? Does at low traffic level it
>>makes
>> more sense to keep on reaching other ISPs via big transit provider?
>
>One thing to consider is that peering can benefit both networks not just
>because of bandwidth savings, but because (given sufficient clue) they
>can deliver better performance and reliability to their mutual customers.
>
>




From itsmemattchung at gmail.com  Thu May 10 09:39:58 2012
From: itsmemattchung at gmail.com (Matt Chung)
Date: Thu, 10 May 2012 09:39:58 -0500
Subject: Question about peering
In-Reply-To: <CBD1475F.2E90D%lists@mtin.net>
References: <4FAAD87F.4070106@szarka.org>
	<CBD1475F.2E90D%lists@mtin.net>
Message-ID: <CAKP=495YxApBWNtKzyoAC+kEeb_Lb_r3vYvM68iZoZDXOyFuCw@mail.gmail.com>

At the previous regional ISP i worked for we peered with google, facebook,
yahoo, pandora and several other content providers at Any2 exchange
(coresite).  We capitalized on that link since a tremendous amount of our
traffic was destined for those networks.

The cost to join that exchange was relatively cheap compared to what we
were paying for transit.  You may want to look for a similar exchange at
your pop.

On Thu, May 10, 2012 at 9:23 AM, Justin Wilson <lists at mtin.net> wrote:

>        We are cross-connected with several ISPs at a couple of data
> centers.
> Very helpful in one situation as several of us share a soft-switch.
>
>        Justin
>
> -----Original Message-----
> From: Rob Szarka <szlists at szarka.org>
> Date: Wednesday, May 9, 2012 4:50 PM
> To: <nanog at nanog.org>
> Subject: Re: Question about peering
>
> >On 4/6/2012 3:11 PM, Anurag Bhatia wrote:
> >> I am curious to know how small ISPs plan peering with other interested
> >> parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and
> >>say
> >> A and C both have open peering policy and assuming the exist in same
> >> exchange or nearby. Now at this point is there is any "minimum
> >>bandwidth"
> >> considerations? Say if A and C have 1Gbps + of flowing traffic - very
> >> likely peering would be good idea to save transit costs to B. But if A
> >>and
> >> C have very low levels - does it still makes sense? Does peering costs
> >> anything if ISPs are in same exchange? Does at low traffic level it
> >>makes
> >> more sense to keep on reaching other ISPs via big transit provider?
> >
> >One thing to consider is that peering can benefit both networks not just
> >because of bandwidth savings, but because (given sufficient clue) they
> >can deliver better performance and reliability to their mutual customers.
> >
> >
>
>
>
>


-- 
-Matt Chung

From mail at danrl.de  Thu May 10 11:28:45 2012
From: mail at danrl.de (Dan Luedtke)
Date: Thu, 10 May 2012 18:28:45 +0200
Subject: VPN over satellite
In-Reply-To: <op.wdm6cene4oyyg1@alvarezp-laptop>
References: <000e01cd26b5$8e132d90$aa3988b0$@be>
 <op.wdm6cene4oyyg1@alvarezp-laptop>
Message-ID: <1336667325.27821.1.camel@localhost>

Hi,

On Mon, 30 Apr 2012 02:42:27 -0700, Rens <rens at autempspourmoi.be> wrote:
> Could anybody recommend any hardware that can build a VPN that works well
> over satellite connections? (TCP enhancements)
Have you asked Genua? www.genua.de
Word on the street says they have a solution, but it may not appear on
their homepage ;) 

regards
  Dan

-- 
Dan Luedtke
http://www.danrl.de



From alex-reports at blastro.com  Thu May 10 11:46:48 2012
From: alex-reports at blastro.com (Alex Thurlow)
Date: Thu, 10 May 2012 11:46:48 -0500
Subject: Looking for W7 whois freeware
In-Reply-To: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
Message-ID: <4FABF0F8.8020305@blastro.com>

On 5/10/2012 1:49 AM, Hank Nussbacher wrote:
> I am looking for a Window 7 GUI utility that does raw whois - not the 
> standard domain lookup, but rather allows me to specify and change the 
> whois server I am talking to and allows me to customize the whois 
> search string for IPs or ASNs or anything else a whois server will 
> accept, like:
> "-B -G as378".
>
It's not a GUI, but whois under Cygwin has always worked well for me.

     -Alex


From csinghaus at hopone.net  Thu May 10 12:52:23 2012
From: csinghaus at hopone.net (Christopher Singhaus)
Date: Thu, 10 May 2012 13:52:23 -0400
Subject: eircom.net contact
Message-ID: <4FAC0057.9010402@hopone.net>

Not sure if this is the right list to send this out to, but I figured
I'd give it a try. I'm looking for anyone with a contact at Eircom.net.
Customers on their network are continually trying to brute force RDP
machines on our network. Fail2ban does automatically null route them and
send them an email, however all I get is a rfc-ignorant auto reply
stating to fill out a form on their website. In fact, they have been
listed as rfc ignorant since 2006.

http://www.rfc-ignorant.org/tools/detail.php?domain=eircom.net&submitted=1140112265&table=abuse

I've also sent emails to noc at eircom.net but received no reply whatsoever.

Just looking for a human to talk to at this point or any other advice.

-- 
Christopher Singhaus,
Systems Administrator / Abuse Dept
HopOne Internet Corp. - AS 14361 - www.hopone.net

"Yesterday's weirdness is tomorrow's reason why." -Hunter S Thompson



From john-nanog at johnpeach.com  Thu May 10 12:57:01 2012
From: john-nanog at johnpeach.com (John Peach)
Date: Thu, 10 May 2012 13:57:01 -0400
Subject: eircom.net contact
In-Reply-To: <4FAC0057.9010402@hopone.net>
References: <4FAC0057.9010402@hopone.net>
Message-ID: <20120510135701.3279bab3@jpeach-desktop.anbg.mssm.edu>

On Thu, 10 May 2012 13:52:23 -0400
Christopher Singhaus <csinghaus at hopone.net> wrote:

> Not sure if this is the right list to send this out to, but I figured
> I'd give it a try. I'm looking for anyone with a contact at
> Eircom.net. Customers on their network are continually trying to
> brute force RDP machines on our network. Fail2ban does automatically
> null route them and send them an email, however all I get is a
> rfc-ignorant auto reply stating to fill out a form on their website.
> In fact, they have been listed as rfc ignorant since 2006.
> 
> http://www.rfc-ignorant.org/tools/detail.php?domain=eircom.net&submitted=1140112265&table=abuse
> 
> I've also sent emails to noc at eircom.net but received no reply
> whatsoever.
> 
> Just looking for a human to talk to at this point or any other advice.
> 
Did you try calling them?
      Eircom Ltd                hostmaster at eircom.net
      1 Heuston South Quarter
      St Johns Road, Dublin 8 ie
      IE
      +35316008010


From csinghaus at hopone.net  Thu May 10 13:02:15 2012
From: csinghaus at hopone.net (Christopher Singhaus)
Date: Thu, 10 May 2012 14:02:15 -0400
Subject: eircom.net contact
In-Reply-To: <20120510135701.3279bab3@jpeach-desktop.anbg.mssm.edu>
References: <4FAC0057.9010402@hopone.net>
 <20120510135701.3279bab3@jpeach-desktop.anbg.mssm.edu>
Message-ID: <4FAC02A7.6060203@hopone.net>

John,

Haven't yet, was trying to avoid a screaming match over the telephone.
That will be my last resort if no one on this list has any other
contacts for them.


On 5/10/2012 1:57 PM, John Peach wrote:
> On Thu, 10 May 2012 13:52:23 -0400
> Christopher Singhaus <csinghaus at hopone.net> wrote:
> 
>> Not sure if this is the right list to send this out to, but I figured
>> I'd give it a try. I'm looking for anyone with a contact at
>> Eircom.net. Customers on their network are continually trying to
>> brute force RDP machines on our network. Fail2ban does automatically
>> null route them and send them an email, however all I get is a
>> rfc-ignorant auto reply stating to fill out a form on their website.
>> In fact, they have been listed as rfc ignorant since 2006.
>>
>> http://www.rfc-ignorant.org/tools/detail.php?domain=eircom.net&submitted=1140112265&table=abuse
>>
>> I've also sent emails to noc at eircom.net but received no reply
>> whatsoever.
>>
>> Just looking for a human to talk to at this point or any other advice.
>>
> Did you try calling them?
>       Eircom Ltd                hostmaster at eircom.net
>       1 Heuston South Quarter
>       St Johns Road, Dublin 8 ie
>       IE
>       +35316008010
> 

-- 
Christopher Singhaus,
Systems Administrator / Abuse Dept
HopOne Internet Corp. - AS 14361 - www.hopone.net

"Yesterday's weirdness is tomorrow's reason why." -Hunter S Thompson



From maxlarson.henry at transversal.ht  Thu May 10 13:02:53 2012
From: maxlarson.henry at transversal.ht (Max Larson Henry)
Date: Thu, 10 May 2012 13:02:53 -0500
Subject: eircom.net contact
In-Reply-To: <4FAC0057.9010402@hopone.net>
References: <4FAC0057.9010402@hopone.net>
Message-ID: <CAPQqn-mrq+xU5f1uN5GxPUfEPzY0zVpzFxet_LagepLMXQjVUA@mail.gmail.com>

maybe

 hostmaster at eircom.net  :)

 or
      1 Heuston South Quarter
      St Johns Road, Dublin 8 ie
      IE

or
      +35316008010


whois Eircom.net

....
Registrant:
Eircom Ltd
   1 Heuston South Quarter
   St Johns Road, Dublin 8 ie
   IE
  Domain Name: EIRCOM.NET

   Administrative Contact, Technical Contact:
      Eircom Ltd		hostmaster at eircom.net
      1 Heuston South Quarter
      St Johns Road, Dublin 8 ie
      IE
      +35316008010

-Max
On Thu, May 10, 2012 at 12:52 PM, Christopher Singhaus
<csinghaus at hopone.net> wrote:
> Not sure if this is the right list to send this out to, but I figured
> I'd give it a try. I'm looking for anyone with a contact at Eircom.net.
> Customers on their network are continually trying to brute force RDP
> machines on our network. Fail2ban does automatically null route them and
> send them an email, however all I get is a rfc-ignorant auto reply
> stating to fill out a form on their website. In fact, they have been
> listed as rfc ignorant since 2006.
>
> http://www.rfc-ignorant.org/tools/detail.php?domain=eircom.net&submitted=1140112265&table=abuse
>
> I've also sent emails to noc at eircom.net but received no reply whatsoever.
>
> Just looking for a human to talk to at this point or any other advice.
>
> --
> Christopher Singhaus,
> Systems Administrator / Abuse Dept
> HopOne Internet Corp. - AS 14361 - www.hopone.net
>
> "Yesterday's weirdness is tomorrow's reason why." -Hunter S Thompson
>
>


From csinghaus at hopone.net  Thu May 10 13:18:08 2012
From: csinghaus at hopone.net (Christopher Singhaus)
Date: Thu, 10 May 2012 14:18:08 -0400
Subject: eircom.net contact
In-Reply-To: <CAPQqn-mrq+xU5f1uN5GxPUfEPzY0zVpzFxet_LagepLMXQjVUA@mail.gmail.com>
References: <4FAC0057.9010402@hopone.net>
 <CAPQqn-mrq+xU5f1uN5GxPUfEPzY0zVpzFxet_LagepLMXQjVUA@mail.gmail.com>
Message-ID: <4FAC0660.7020200@hopone.net>

Actually, that might of worked. I at least got someone's 'out of the
office' auto response this time around instead of the 'fill out a form
on our website'. Looks like I need to wait until May 15th though.

On 5/10/2012 2:02 PM, Max Larson Henry wrote:
> maybe
> 
>  hostmaster at eircom.net  :)
> 
>  or
>       1 Heuston South Quarter
>       St Johns Road, Dublin 8 ie
>       IE
> 
> or
>       +35316008010
> 
> 
> whois Eircom.net
> 
> ....
> Registrant:
> Eircom Ltd
>    1 Heuston South Quarter
>    St Johns Road, Dublin 8 ie
>    IE
>   Domain Name: EIRCOM.NET
> 
>    Administrative Contact, Technical Contact:
>       Eircom Ltd		hostmaster at eircom.net
>       1 Heuston South Quarter
>       St Johns Road, Dublin 8 ie
>       IE
>       +35316008010
> 
> -Max
> On Thu, May 10, 2012 at 12:52 PM, Christopher Singhaus
> <csinghaus at hopone.net> wrote:
>> Not sure if this is the right list to send this out to, but I figured
>> I'd give it a try. I'm looking for anyone with a contact at Eircom.net.
>> Customers on their network are continually trying to brute force RDP
>> machines on our network. Fail2ban does automatically null route them and
>> send them an email, however all I get is a rfc-ignorant auto reply
>> stating to fill out a form on their website. In fact, they have been
>> listed as rfc ignorant since 2006.
>>
>> http://www.rfc-ignorant.org/tools/detail.php?domain=eircom.net&submitted=1140112265&table=abuse
>>
>> I've also sent emails to noc at eircom.net but received no reply whatsoever.
>>
>> Just looking for a human to talk to at this point or any other advice.
>>
>> --
>> Christopher Singhaus,
>> Systems Administrator / Abuse Dept
>> HopOne Internet Corp. - AS 14361 - www.hopone.net
>>
>> "Yesterday's weirdness is tomorrow's reason why." -Hunter S Thompson
>>
>>

-- 
Christopher Singhaus,
Systems Administrator / Abuse Dept
HopOne Internet Corp. - AS 14361 - www.hopone.net

"Yesterday's weirdness is tomorrow's reason why." -Hunter S Thompson



From scott at sberkman.net  Thu May 10 15:57:09 2012
From: scott at sberkman.net (Scott Berkman)
Date: Thu, 10 May 2012 16:57:09 -0400
Subject: Looking for W7 whois freeware
In-Reply-To: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
Message-ID: <0c6501cd2eef$77cbf890$6763e9b0$@sberkman.net>

I use Launchy (a keystroke launcher similar to GnomeDo, Quicksilver, etc)
and it's Runner plugin with some bat scripts that reference the builtin
whois DOS/CLI command to create my own.

So for example, to look up an IP at ARIN I just hit my hotkey (Atl-Space)
and type arin <tab> <IP> enter.  My bat script really just runs whois, sizes
the command prompt window, and waits for user input before disappearing.

I'm happy to share my scripts off list if you are interested.

	-Scott

-----Original Message-----
From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] 
Sent: Thursday, May 10, 2012 2:49 AM
To: nanog at nanog.org
Subject: Looking for W7 whois freeware

I am looking for a Window 7 GUI utility that does raw whois - not the
standard domain lookup, but rather allows me to specify and change the whois
server I am talking to and allows me to customize the whois search string
for IPs or ASNs or anything else a whois server will accept, like:
"-B -G as378".

I know of ezwhois but am looking for something better (for example - they
don't have whois.ripe.net listed - one can add it but not save it).

Thanks,
Hank 





From johnl at iecc.com  Fri May 11 01:10:59 2012
From: johnl at iecc.com (John Levine)
Date: 11 May 2012 06:10:59 -0000
Subject: eircom.net contact
In-Reply-To: <4FAC0660.7020200@hopone.net>
Message-ID: <20120511061059.41040.qmail@joyce.lan>

In article <4FAC0660.7020200 at hopone.net> you write:
>Actually, that might of worked. I at least got someone's 'out of the
>office' auto response this time around instead of the 'fill out a form
>on our website'. Looks like I need to wait until May 15th though.

Last time I tried to engage with Eircom, I encountered a severe case
of "we don't care, we don't have to, we wouldn't even know how, we're
The Phone Company."

R's,
John


From mantel at gmail.com  Fri May 11 03:26:35 2012
From: mantel at gmail.com (Niall Kearney)
Date: Fri, 11 May 2012 09:26:35 +0100
Subject: eircom.net contact
In-Reply-To: <20120511061059.41040.qmail@joyce.lan>
References: <4FAC0660.7020200@hopone.net>
 <20120511061059.41040.qmail@joyce.lan>
Message-ID: <CAJCmuEkzRRjduDpoi7a=FyTm5yRWerGpBEXrMu=ac-ppshi3Ow@mail.gmail.com>

That sounds like Eircom. They're in financial trouble at the moment so they
probably doubly don't care about their customers or anyone else unless
they're taking them to court or willing to buy them. Their twitter account
seems to be responsive ( https://twitter.com/#!/eircom ) although getting
them to understand might take a few steps.

Niall


On 11 May 2012 07:10, John Levine <johnl at iecc.com> wrote:

> In article <4FAC0660.7020200 at hopone.net> you write:
> >Actually, that might of worked. I at least got someone's 'out of the
> >office' auto response this time around instead of the 'fill out a form
> >on our website'. Looks like I need to wait until May 15th though.
>
> Last time I tried to engage with Eircom, I encountered a severe case
> of "we don't care, we don't have to, we wouldn't even know how, we're
> The Phone Company."
>
> R's,
> John
>
>

From cscora at apnic.net  Fri May 11 13:44:38 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 12 May 2012 04:44:38 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201205111844.q4BIic1u020463@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,
TRNOG, 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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 12 May, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              407563
    Prefixes after maximum aggregation:                          173478
    Deaggregation factor:                                          2.35
    Unique aggregates announced to Internet:                     199037
Total ASes present in the Internet Routing Table:                 40961
    Prefixes per ASN:                                              9.95
Origin-only ASes present in the Internet Routing Table:           33155
Origin ASes announcing only one prefix:                           15644
Transit ASes present in the Internet Routing Table:                5484
Transit-only ASes present in the Internet Routing Table:            137
Average AS path length visible in the Internet Routing Table:       4.5
    Max AS path length visible:                                      64
    Max AS path prepend of ASN ( 9902)                               56
Prefixes from unregistered ASNs in the Routing Table:               374
    Unregistered ASNs in the Routing Table:                         130
Number of 32-bit ASNs allocated by the RIRs:                       2687
Number of 32-bit ASNs visible in the Routing Table:                2322
Prefixes from 32-bit ASNs in the Routing Table:                    5860
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            108
Number of addresses announced to Internet:                   2547853104
    Equivalent to 151 /8s, 221 /16s and 39 /24s
    Percentage of available address space announced:               68.7
    Percentage of allocated address space announced:               68.8
    Percentage of available address space allocated:               99.9
    Percentage of address space in use by end-sites:               92.6
Total number of prefixes smaller than registry allocations:      173961

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   100290
    Total APNIC prefixes after maximum aggregation:               32360
    APNIC Deaggregation factor:                                    3.10
Prefixes being announced from the APNIC address blocks:           96740
    Unique aggregates announced from the APNIC address blocks:    39871
APNIC Region origin ASes present in the Internet Routing Table:    4683
    APNIC Prefixes per ASN:                                       20.66
APNIC Region origin ASes announcing only one prefix:               1234
APNIC Region transit ASes present in the Internet Routing Table:    729
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         20
Number of APNIC region 32-bit ASNs visible in the Routing Table:    203
Number of APNIC addresses announced to Internet:              644595328
    Equivalent to 38 /8s, 107 /16s and 190 /24s
    Percentage of available APNIC address space announced:         81.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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:                    150584
    Total ARIN prefixes after maximum aggregation:                76455
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           121585
    Unique aggregates announced from the ARIN address blocks:     50780
ARIN Region origin ASes present in the Internet Routing Table:    15088
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5739
ARIN Region transit ASes present in the Internet Routing Table:    1596
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      17
Number of ARIN addresses announced to Internet:               812031680
    Equivalent to 48 /8s, 102 /16s and 158 /24s
    Percentage of available ARIN address space announced:          64.8

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:                    100227
    Total RIPE prefixes after maximum aggregation:                54165
    RIPE Deaggregation factor:                                     1.85
Prefixes being announced from the RIPE address blocks:            92408
    Unique aggregates announced from the RIPE address blocks:     58733
RIPE Region origin ASes present in the Internet Routing Table:    16564
    RIPE Prefixes per ASN:                                         5.58
RIPE Region origin ASes announcing only one prefix:                8064
RIPE Region transit ASes present in the Internet Routing Table:    2649
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1551
Number of RIPE addresses announced to Internet:               512885448
    Equivalent to 30 /8s, 146 /16s and 2 /24s
    Percentage of available RIPE address space announced:          82.6

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:                   41419
    Total LACNIC prefixes after maximum aggregation:               8278
    LACNIC Deaggregation factor:                                   5.00
Prefixes being announced from the LACNIC address blocks:          41394
    Unique aggregates announced from the LACNIC address blocks:   20500
LACNIC Region origin ASes present in the Internet Routing Table:   1598
    LACNIC Prefixes per ASN:                                      25.90
LACNIC Region origin ASes announcing only one prefix:               441
LACNIC Region transit ASes present in the Internet Routing Table:   300
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   546
Number of LACNIC addresses announced to Internet:             100238984
    Equivalent to 5 /8s, 249 /16s and 134 /24s
    Percentage of available LACNIC address space announced:        66.4

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:                   8993
    Total AfriNIC prefixes after maximum aggregation:              2154
    AfriNIC Deaggregation factor:                                  4.18
Prefixes being announced from the AfriNIC address blocks:          7041
    Unique aggregates announced from the AfriNIC address blocks:   2219
AfriNIC Region origin ASes present in the Internet Routing Table:   532
    AfriNIC Prefixes per ASN:                                     13.23
AfriNIC Region origin ASes announcing only one prefix:              166
AfriNIC Region transit ASes present in the Internet Routing Table:  122
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             31782656
    Equivalent to 1 /8s, 228 /16s and 247 /24s
    Percentage of available AfriNIC address space announced:       47.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     2540      11114        1040   Korea Telecom (KIX)
17974     1869        510          73   PT TELEKOMUNIKASI INDONESIA
 7545     1678        301          85   TPG Internet Pty Ltd
 4755     1593        388         162   TATA Communications formerly 
 9829     1283       1069          30   BSNL National Internet Backbo
 7552     1164       1062          11   Vietel Corporation
 9583     1156         86         500   Sify Limited
 4808     1104       2049         315   CNCGROUP IP network: China169
24560     1027        385         167   Bharti Airtel Ltd., Telemedia
 9498      965        291          64   BHARTI Airtel Ltd.

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     3415       3807         193   bellsouth.net, inc. 
 7029     3376        986         159   Windstream Communications Inc
18566     2093        382         179   Covad Communications 
 1785     1903        681         131   PaeTec Communications, Inc.
20115     1638       1566         620   Charter Communications 
 4323     1606       1044         383   Time Warner Telecom
22773     1597       2911         115   Cox Communications, Inc.
30036     1407        262         752   Mediacom Communications Corp 
 7018     1251      10038         820   AT&T WorldNet Services
11492     1186        216         364   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
 8402     1728        544          16   Corbina telecom
34984      693        188         172   BILISIM TELEKOM
31148      685         37           9   FreeNet ISP
12479      679        671          69   Uni2 Autonomous System
20940      657        216         511   Akamai Technologies European 
 6830      656       2215         426   UPC Distribution Services
 8551      573        360          80   Bezeq International
 3320      485       8442         401   Deutsche Telekom AG
 3292      473       2108         407   TDC Tele Danmark
 8866      436        134          27   Bulgarian Telecommunication C

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     1869        334         175   TVCABLE BOGOTA 
28573     1849       1137          58   NET Servicos de Comunicao S.A
 6503     1524        418          66   AVANTEL, S.A. 
 8151     1480       3003         342   UniNet S.A. de C.V. 
 7303     1371        837         188   Telecom Argentina Stet-France
26615      903        761          33   Tim Brasil S.A.
27947      693         74          98   Telconet S.A
11172      642         91          73   Servicios Alestra S.A de C.V 
22047      582        326          15   VTR PUNTO NET S.A. 
 3816      576        243          98   Empresa Nacional de Telecomun

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     1307        958          13   TEDATA
24863      845        274          35   LINKdotNET AS number
 6713      496        649          18   Itissalat Al-MAGHRIB
 3741      263        921         223   The Internet Solution 
12258      197         28          62   Vodacom Internet Company 
33776      197         12          21   Starcomms Nigeria Limited
24835      179         80           8   RAYA Telecom - Egypt
16637      170        666          83   MTN Network Solutions
15706      169         32           6   Sudatel Internet Exchange Aut
29571      158         15          16   Ci Telecom Autonomous system 

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     3415       3807         193   bellsouth.net, inc. 
 7029     3376        986         159   Windstream Communications Inc
 4766     2540      11114        1040   Korea Telecom (KIX)
18566     2093        382         179   Covad Communications 
 1785     1903        681         131   PaeTec Communications, Inc.
10620     1869        334         175   TVCABLE BOGOTA 
17974     1869        510          73   PT TELEKOMUNIKASI INDONESIA
28573     1849       1137          58   NET Servicos de Comunicao S.A
 8402     1728        544          16   Corbina telecom
 7545     1678        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
 7029      3376        3217      Windstream Communications Inc
18566      2093        1914      Covad Communications 
17974      1869        1796      PT TELEKOMUNIKASI INDONESIA
28573      1849        1791      NET Servicos de Comunicao S.A
 1785      1903        1772      PaeTec Communications, Inc.
 8402      1728        1712      Corbina telecom
10620      1869        1694      TVCABLE BOGOTA 
 7545      1678        1593      TPG Internet Pty Ltd
 4766      2540        1500      Korea Telecom (KIX)
22773      1597        1482      Cox Communications, Inc.

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
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
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.32.168.0/21        15836     ARAX Autonomous System
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
27.112.114.0/24      23884     Proimage Engineering and Comm

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:19       /9:12      /10:29      /11:81      /12:235     
/13:460     /14:831     /15:1496    /16:12241   /17:6253    /18:10573   
/19:20706   /20:29319   /21:30533   /22:39962   /23:38226   /24:212903  
/25:1197    /26:1433    /27:787     /28:164     /29:66      /30:17      
/31:0       /32:20      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3033          3376      Windstream Communications Inc
 6389     2134          3415      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
10620     1715          1869      TVCABLE BOGOTA 
 8402     1706          1728      Corbina telecom
30036     1348          1407      Mediacom Communications Corp 
 6503     1282          1524      AVANTEL, S.A. 
11492     1149          1186      Cable One 
 8452     1108          1307      TEDATA
 7011     1069          1184      Citizens Utilities 

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:543       2:704       4:14        5:2         6:3         8:411    
  12:2001     13:1        14:610      15:12       16:3        17:5      
  20:23       23:166      24:1769     27:1298     31:953      32:57     
  33:2        34:2        36:8        37:440      38:808      40:120    
  41:3115     42:136      44:3        46:1417     47:3        49:402    
  50:546      52:13       54:10       55:13       56:3        57:32     
  58:961      59:509      60:255      61:1280     62:986      63:2056   
  64:4181     65:2241     66:4468     67:2019     68:1166     69:3209   
  70:905      71:484      72:1818     74:2592     75:492      76:319    
  77:948      78:985      79:489      80:1215     81:909      82:667    
  83:554      84:487      85:1224     86:438      87:918      88:334    
  89:1694     90:292      91:4810     92:539      93:1469     94:1519   
  95:903      96:369      97:316      98:873      99:38      100:7      
 101:186     103:1059    106:103     107:187     108:284     109:1337   
 110:769     111:915     112:409     113:605     114:631     115:898    
 116:938     117:715     118:911     119:1236    120:352     121:805    
 122:1668    123:1102    124:1382    125:1246    128:561     129:197    
 130:252     131:629     132:179     133:22      134:247     135:62     
 136:214     137:178     138:334     139:183     140:493     141:243    
 142:413     143:432     144:526     145:70      146:497     147:282    
 148:772     149:306     150:157     151:176     152:466     153:172    
 154:12      155:400     156:219     157:381     158:179     159:545    
 160:338     161:260     162:347     163:191     164:588     165:386    
 166:572     167:467     168:859     169:126     170:770     171:131    
 172:2       173:1738    174:583     175:432     176:696     177:735    
 178:1361    180:1208    181:82      182:974     183:290     184:486    
 185:1       186:2282    187:1074    188:1264    189:1791    190:5572   
 192:6002    193:5288    194:3807    195:3217    196:1283    197:135    
 198:3640    199:4605    200:5855    201:1936    202:8565    203:8595   
 204:4327    205:2526    206:2763    207:2798    208:4078    209:3616   
 210:2752    211:1489    212:2026    213:1935    214:851     215:103    
 216:5104    217:1546    218:544     219:338     220:1231    221:558    
 222:322     223:339    

End of report


From cidr-report at potaroo.net  Fri May 11 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 11 May 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201205112200.q4BM00ek036632@wattle.apnic.net>

BGP Update Report
Interval: 03-May-12 -to- 10-May-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS4755           156150  6.2%     101.8 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
 2 - AS17908           97561  3.9%     117.7 -- TCISL Tata Communications
 3 - AS9829            79604  3.1%      64.0 -- BSNL-NIB National Internet Backbone
 4 - AS8402            51507  2.0%      42.9 -- CORBINA-AS OJSC "Vimpelcom"
 5 - AS17488           35241  1.4%      52.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet
 6 - AS9583            33727  1.3%      33.4 -- SIFY-AS-IN Sify Limited
 7 - AS26615           31327  1.2%      35.2 -- Tim Celular S.A.
 8 - AS24722           30820  1.2%     446.7 -- BABILON-AS Babilon-T
 9 - AS12479           28711  1.1%      80.0 -- UNI2-AS France Telecom Espana SA
10 - AS45528           27927  1.1%      63.9 -- TDN Tikona Digital Networks Pvt Ltd.
11 - AS32528           25495  1.0%    8498.3 -- ABBOTT Abbot Labs
12 - AS17439           23396  0.9%     122.5 -- NETMAGIC-AP Netmagic Datacenter Mumbai
13 - AS24560           20247  0.8%      26.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
14 - AS24193           19570  0.8%      70.1 -- SIFY-IN Sify Limited Service Provider India
15 - AS10620           18412  0.7%       9.8 -- Telmex Colombia S.A.
16 - AS17762           18277  0.7%      78.1 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd
17 - AS7633            18244  0.7%      97.6 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore
18 - AS8452            17902  0.7%      22.4 -- TE-AS TE-AS
19 - AS1785            17596  0.7%       9.4 -- AS-PAETEC-NET - PaeTec Communications, Inc.
20 - AS18207           17175  0.7%      41.3 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS44798            9903  0.4%    9903.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 2 - AS32528           25495  1.0%    8498.3 -- ABBOTT Abbot Labs
 3 - AS17408            2829  0.1%    2829.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 4 - AS25911            1993  0.1%    1993.0 -- TALISMAN-CH3 - TALISMAN ENERGY INC.
 5 - AS3                1876  0.1%     366.0 -- PERMRMT Ltd. "Regional Media Transit"
 6 - AS55665            1057  0.0%    1057.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia
 7 - AS7219             1046  0.0%    1046.0 -- ASNTULIX - Tulix Systems, Inc.
 8 - AS4658              960  0.0%     960.0 -- NETFRONT-AS Netfront Information Technology Limited,
 9 - AS13263            1802  0.1%     901.0 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S
10 - AS34043             887  0.0%     887.0 -- RISS Internet Security Systems SRL
11 - AS45013            1615  0.1%     807.5 -- ECONOTEL-AS CJSC "Econotel"
12 - AS1355              700  0.0%     700.0 -- AHMSI-HQDC - American Home Mortgage Servicing, Inc.
13 - AS40677            1299  0.1%     649.5 -- GLOBALAIR-COM - Globalair.com
14 - AS37303            1230  0.1%     615.0 -- AIRTELMADA
15 - AS19743            3443  0.1%     573.8 -- 
16 - AS57767             555  0.0%     555.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network
17 - AS37086             527  0.0%     527.0 -- SOCATEL-AS
18 - AS38857            1039  0.0%     519.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd.
19 - AS20799            4984  0.2%     453.1 -- DATANET-AS Datanet.co.uk Ltd
20 - AS24722           30820  1.2%     446.7 -- BABILON-AS Babilon-T


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 130.36.34.0/24    12745  0.5%   AS32528 -- ABBOTT Abbot Labs
 2 - 130.36.35.0/24    12745  0.5%   AS32528 -- ABBOTT Abbot Labs
 3 - 109.161.64.0/19   12176  0.5%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 4 - 91.202.212.0/22    9903  0.4%   AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 5 - 41.43.147.0/24     9651  0.4%   AS8452  -- TE-AS TE-AS
 6 - 62.36.252.0/22     8081  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 7 - 182.64.0.0/16      7488  0.3%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 8 - 62.36.249.0/24     6501  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
 9 - 62.36.241.0/24     6099  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
10 - 62.36.210.0/24     5947  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
11 - 194.63.9.0/24      5089  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
12 - 205.94.64.0/20     4975  0.2%   AS3475  -- DNIC-AS-03475 - Navy Network Information Center (NNIC)
13 - 202.56.215.0/24    4093  0.1%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
14 - 193.34.176.0/23    2949  0.1%   AS3329  -- Hellas OnLine Electronic Communications S.A.
15 - 202.153.174.0/24   2829  0.1%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
16 - 115.170.128.0/17   2506  0.1%   AS4847  -- CNIX-AP China Networks Inter-Exchange
17 - 192.139.215.0/24   1993  0.1%   AS25911 -- TALISMAN-CH3 - TALISMAN ENERGY INC.
18 - 193.105.129.0/24   1876  0.1%   AS3     -- PERMRMT Ltd. "Regional Media Transit"
19 - 215.65.61.0/24     1726  0.1%   AS5800  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
20 - 221.120.230.0/24   1513  0.1%   AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited

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 11 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 11 May 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201205112200.q4BM00Fd036627@wattle.apnic.net>

This report has been generated at Fri May 11 21:12:23 2012 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
        04-05-12    410788      239947
        05-05-12    410006      239925
        06-05-12    409830      239992
        07-05-12    409942      240125
        08-05-12    409732      239935
        09-05-12    409471      240204
        10-05-12    409530      240855
        11-05-12    410225      240957


AS Summary
         41077  Number of ASes in routing system
         17163  Number of ASes announcing only one prefix
          3417  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      112440288  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').

 --- 11May12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     410703   240981   169722    41.3%   All ASes

AS6389      3415      196     3219    94.3%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3417     1803     1614    47.2%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2540     1060     1480    58.3%   KIXS-AS-KR Korea Telecom
AS22773     1597      129     1468    91.9%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS18566     2093      705     1388    66.3%   COVAD - Covad Communications
                                               Co.
AS28573     1849      517     1332    72.0%   NET Servicos de Comunicao S.A.
AS4323      1607      385     1222    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1903      800     1103    58.0%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS10620     1869      784     1085    58.1%   Telmex Colombia S.A.
AS4755      1593      548     1045    65.6%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1164      233      931    80.0%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1371      442      929    67.8%   Telecom Argentina S.A.
AS26615      903       33      870    96.3%   Tim Celular S.A.
AS8151      1480      668      812    54.9%   Uninet S.A. de C.V.
AS18101      947      158      789    83.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS17908      826       60      766    92.7%   TCISL Tata Communications
AS4808      1104      347      757    68.6%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS17974     1869     1139      730    39.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS9394       836      155      681    81.5%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS13977      765      121      644    84.2%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS3356      1098      461      637    58.0%   LEVEL3 Level 3 Communications
AS30036     1407      783      624    44.3%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS17676      691       75      616    89.1%   GIGAINFRA Softbank BB Corp.
AS24560     1027      427      600    58.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS22561     1017      418      599    58.9%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS19262      998      402      596    59.7%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS4780       829      256      573    69.1%   SEEDNET Digital United Inc.
AS3549      1009      444      565    56.0%   GBLX Global Crossing Ltd.
AS22047      582       31      551    94.7%   VTR BANDA ANCHA S.A.
AS8452      1307      765      542    41.5%   TE-AS TE-AS

Total      43113    14345    28768    66.7%   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-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        27.112.114.0/24      AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        114.134.16.0/20      AS56310 
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.223.60.0/22      AS6910  DIALTELECOMRO Dial Telecom S.R.L.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        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.122.134.0/24     AS38615 
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel 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.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        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.160.160.0/19     AS18233 
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        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.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.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS27876 American Data Networks
        216.194.160.0/20     AS27876 American Data Networks


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 uwcableguy at gmail.com  Fri May 11 20:29:53 2012
From: uwcableguy at gmail.com (Ben Bartsch)
Date: Fri, 11 May 2012 20:29:53 -0500
Subject: Juniper advertises ::/0 Cisco hears ::/3
Message-ID: <CAOvEG7MVoE3FscV+O9OnDP4S7UjL9Cz7hDS7PaoNzP+ziuBjOA@mail.gmail.com>

This one is very strange...

Has anyone seen this behavior with BGP IPv6 between Juniper (owned by Level
3, advertising routes correctly, sending default ::/0) and Cisco (6509
running 12.2.58.SXI6 advipservices, receiving all routes fine except
default, hearing ::/3)?  I worked with Level 3 and they confirmed they are
sending ::/0 as default:

show route advertising-protocol bgp 2001:1900:2100::XXX



inet6.0: 11139 destinations, 43712 routes (11135 active, 0 holddown, 7
hidden)

  Prefix                  Nexthop              MED     Lclpref    AS path

* ::/0                    Self                                    I


We see a ::/3:

XXXXXXX#sh ip bgp ipv6 uni neigh 2001:1900:2100::XXX received-r

BGP table version is 497237119, local router ID is XXX.XX.XX.XXXX

Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete



   Network          Next Hop            Metric LocPrf Weight Path

*> ::/3             2001:1900:2100::XXX

                                                           0 3356 i

I opened a TAC case and they had me run some IPv6 BGP detailed debugging
which confirmed we are receiving a ::/3

*May* *11* *18:01:07* *XXXXXXXXXXX* *67205:* *May* *11* *18:01:05.701* *CDT:
* *BGP*(*1*)*:* *process* *::/3*, *next* *hop* *2001:1900:2100::XXX* (*
FE80::XXXX:XXXX:XXXX:XXXX*), *metric* *0* *from* *2001:1900:2100::XXX*

Cisco's next step is for us to Wireshark the interface.  I have requested
Level 3 engage Juniper TAC, but am not expecting them to come up with
anything since they already confirmed they are sending ::/0.

We have a second connection to Level 3 that is Cisco - Cisco and it is
working fine.  My gut says this is one of those Juniper - Cisco
communications issues, but I need proof.

I am just curious if anyone has seen this type of behavior.  Have a great
weekend.

-Ben

From gwood83 at gmail.com  Fri May 11 21:17:08 2012
From: gwood83 at gmail.com (=?utf-8?B?Z3dvb2Q4M0BnbWFpbC5jb20=?=)
Date: Fri, 11 May 2012 19:17:08 -0700
Subject: =?utf-8?B?UmU6IEp1bmlwZXIgYWR2ZXJ0aXNlcyA6Oi8wIENpc2NvIGhlYXJzIDo6LzM=?=
Message-ID: <4fadc824.e55bb60a.7832.1982@mx.google.com>

Very interesting.  Do you know what platform and code the Juniper side on L3 is running?

Sent from my HTC on the Now Network from Sprint!

----- Reply message -----
From: "Ben Bartsch" <uwcableguy at gmail.com>
Date: Fri, May 11, 2012 6:29 pm
Subject: Juniper advertises ::/0 Cisco hears ::/3
To: <nanog at nanog.org>

This one is very strange...

Has anyone seen this behavior with BGP IPv6 between Juniper (owned by Level
3, advertising routes correctly, sending default ::/0) and Cisco (6509
running 12.2.58.SXI6 advipservices, receiving all routes fine except
default, hearing ::/3)?  I worked with Level 3 and they confirmed they are
sending ::/0 as default:

show route advertising-protocol bgp 2001:1900:2100::XXX



inet6.0: 11139 destinations, 43712 routes (11135 active, 0 holddown, 7
hidden)

  Prefix                  Nexthop              MED     Lclpref    AS path

* ::/0                    Self                                    I


We see a ::/3:

XXXXXXX#sh ip bgp ipv6 uni neigh 2001:1900:2100::XXX received-r

BGP table version is 497237119, local router ID is XXX.XX.XX.XXXX

Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete



   Network          Next Hop            Metric LocPrf Weight Path

*> ::/3             2001:1900:2100::XXX

                                                           0 3356 i

I opened a TAC case and they had me run some IPv6 BGP detailed debugging
which confirmed we are receiving a ::/3

*May* *11* *18:01:07* *XXXXXXXXXXX* *67205:* *May* *11* *18:01:05.701* *CDT:
* *BGP*(*1*)*:* *process* *::/3*, *next* *hop* *2001:1900:2100::XXX* (*
FE80::XXXX:XXXX:XXXX:XXXX*), *metric* *0* *from* *2001:1900:2100::XXX*

Cisco's next step is for us to Wireshark the interface.  I have requested
Level 3 engage Juniper TAC, but am not expecting them to come up with
anything since they already confirmed they are sending ::/0.

We have a second connection to Level 3 that is Cisco - Cisco and it is
working fine.  My gut says this is one of those Juniper - Cisco
communications issues, but I need proof.

I am just curious if anyone has seen this type of behavior.  Have a great
weekend.

-Ben

From saku at ytti.fi  Sat May 12 03:53:45 2012
From: saku at ytti.fi (Saku Ytti)
Date: Sat, 12 May 2012 11:53:45 +0300
Subject: Juniper advertises ::/0 Cisco hears ::/3
In-Reply-To: <CAOvEG7MVoE3FscV+O9OnDP4S7UjL9Cz7hDS7PaoNzP+ziuBjOA@mail.gmail.com>
References: <CAOvEG7MVoE3FscV+O9OnDP4S7UjL9Cz7hDS7PaoNzP+ziuBjOA@mail.gmail.com>
Message-ID: <CAAeewD9RiHbg-OoHM3mqJQJaD2+r2S1HRkp3Nk1hwMdci6rTfw@mail.gmail.com>

On 12 May 2012 04:29, Ben Bartsch <uwcableguy at gmail.com> wrote:
> Has anyone seen this behavior with BGP IPv6 between Juniper (owned by Level
> 3, advertising routes correctly, sending default ::/0) and Cisco (6509
> running 12.2.58.SXI6 advipservices, receiving all routes fine except
> default, hearing ::/3)? ?I worked with Level 3 and they confirmed they are
> sending ::/0 as default:

Just stab in the dark.

Verify that you're not disagreeing on SAFI.

If JNPR is sending labeled SAFI and you are expecting to receiving
unlabeled unicast SAFI. Then '3' from JNPR as 'implict null' would to
you mean prefix lenght.

Obviously it should fail harder, but I've seen IOS<->IOS reporting
SAFI to be one, but coding NLRI as if SAFI was something else.

-- 
? ++ytti


From sander at steffann.nl  Sat May 12 08:16:28 2012
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 12 May 2012 16:16:28 +0300
Subject: Juniper advertises ::/0 Cisco hears ::/3
In-Reply-To: <CAOvEG7MVoE3FscV+O9OnDP4S7UjL9Cz7hDS7PaoNzP+ziuBjOA@mail.gmail.com>
References: <CAOvEG7MVoE3FscV+O9OnDP4S7UjL9Cz7hDS7PaoNzP+ziuBjOA@mail.gmail.com>
Message-ID: <6FBAEAA6-2324-4BB6-945F-046788197670@steffann.nl>

Hi,

> This one is very strange...
> 
> Has anyone seen this behavior with BGP IPv6 between Juniper (owned by Level
> 3, advertising routes correctly, sending default ::/0) and Cisco (6509
> running 12.2.58.SXI6 advipservices, receiving all routes fine except
> default, hearing ::/3)?  I worked with Level 3 and they confirmed they are
> sending ::/0 as default:

I have seen this exact problem between two Cisco routers (c7600 sending default route, c7200 receiving ::/3), so I am not sure it's related to the Juniper box... It happened after I changed the BGP timers on the 7200, and it disappeared after removing the timer settings *and rebooting the 7200*.

- Sander



From hank at efes.iucc.ac.il  Sun May 13 00:19:42 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Sun, 13 May 2012 08:19:42 +0300
Subject: Looking for W7 whois freeware
In-Reply-To: <0c6501cd2eef$77cbf890$6763e9b0$@sberkman.net>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
Message-ID: <5.1.1.6.2.20120513081825.01ecc600@efes.iucc.ac.il>

At 16:57 10/05/2012 -0400, Scott Berkman wrote:

I am looking for a simple Windows GUI s/w for a secretary to use to do 
whois lookups for IP and ASNs and to easily copy/paste the 
results.  Amazing that there is no such beast.

-Hank

>I use Launchy (a keystroke launcher similar to GnomeDo, Quicksilver, etc)
>and it's Runner plugin with some bat scripts that reference the builtin
>whois DOS/CLI command to create my own.
>
>So for example, to look up an IP at ARIN I just hit my hotkey (Atl-Space)
>and type arin <tab> <IP> enter.  My bat script really just runs whois, sizes
>the command prompt window, and waits for user input before disappearing.
>
>I'm happy to share my scripts off list if you are interested.
>
>         -Scott
>
>-----Original Message-----
>From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il]
>Sent: Thursday, May 10, 2012 2:49 AM
>To: nanog at nanog.org
>Subject: Looking for W7 whois freeware
>
>I am looking for a Window 7 GUI utility that does raw whois - not the
>standard domain lookup, but rather allows me to specify and change the whois
>server I am talking to and allows me to customize the whois search string
>for IPs or ASNs or anything else a whois server will accept, like:
>"-B -G as378".
>
>I know of ezwhois but am looking for something better (for example - they
>don't have whois.ripe.net listed - one can add it but not save it).
>
>Thanks,
>Hank



From blakjak at blakjak.net  Sun May 13 00:29:24 2012
From: blakjak at blakjak.net (Mark Foster)
Date: Sun, 13 May 2012 17:29:24 +1200
Subject: Looking for W7 whois freeware
In-Reply-To: <5.1.1.6.2.20120513081825.01ecc600@efes.iucc.ac.il>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120513081825.01ecc600@efes.iucc.ac.il>
Message-ID: <4FAF46B4.8080703@blakjak.net>

Set up

http://www.the42.net/networkjack/

Point her browser at it. Problem solved?

I drove the Ping, Traceroute, Dig and Whois requirements of a Tier 2/3
Helpdesk with this tool for several weeks - several years ago, I
suppose, but I still have a copy running which I use occasionally when
I'm trapped behind web-only internet access.

Mark.

On 13/05/12 17:19, Hank Nussbacher wrote:
> At 16:57 10/05/2012 -0400, Scott Berkman wrote:
>
> I am looking for a simple Windows GUI s/w for a secretary to use to do
> whois lookups for IP and ASNs and to easily copy/paste the results. 
> Amazing that there is no such beast.
>
> -Hank
>
>> I use Launchy (a keystroke launcher similar to GnomeDo, Quicksilver,
>> etc)
>> and it's Runner plugin with some bat scripts that reference the builtin
>> whois DOS/CLI command to create my own.
>>
>> So for example, to look up an IP at ARIN I just hit my hotkey
>> (Atl-Space)
>> and type arin <tab> <IP> enter.  My bat script really just runs
>> whois, sizes
>> the command prompt window, and waits for user input before disappearing.
>>
>> I'm happy to share my scripts off list if you are interested.
>>
>>         -Scott
>>
>> -----Original Message-----
>> From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il]
>> Sent: Thursday, May 10, 2012 2:49 AM
>> To: nanog at nanog.org
>> Subject: Looking for W7 whois freeware
>>
>> I am looking for a Window 7 GUI utility that does raw whois - not the
>> standard domain lookup, but rather allows me to specify and change
>> the whois
>> server I am talking to and allows me to customize the whois search
>> string
>> for IPs or ASNs or anything else a whois server will accept, like:
>> "-B -G as378".
>>
>> I know of ezwhois but am looking for something better (for example -
>> they
>> don't have whois.ripe.net listed - one can add it but not save it).
>>
>> Thanks,
>> Hank
>
>



From mailinglist at theflux.net  Sun May 13 09:15:15 2012
From: mailinglist at theflux.net (Mailinglist)
Date: Sun, 13 May 2012 10:15:15 -0400
Subject: Looking for W7 whois freeware
In-Reply-To: <4FAF46B4.8080703@blakjak.net>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120513081825.01ecc600@efes.iucc.ac.il>
 <4FAF46B4.8080703@blakjak.net>
Message-ID: <7D397BE7-DE31-4D9F-AB0E-6B184A35B318@theflux.net>

Geoasn is web based splunk product.

Regards?

On May 13, 2012, at 1:29 AM, Mark Foster <blakjak at blakjak.net> wrote:

> Set up
> 
> http://www.the42.net/networkjack/
> 
> Point her browser at it. Problem solved?
> 
> I drove the Ping, Traceroute, Dig and Whois requirements of a Tier 2/3
> Helpdesk with this tool for several weeks - several years ago, I
> suppose, but I still have a copy running which I use occasionally when
> I'm trapped behind web-only internet access.
> 
> Mark.
> 
> On 13/05/12 17:19, Hank Nussbacher wrote:
>> At 16:57 10/05/2012 -0400, Scott Berkman wrote:
>> 
>> I am looking for a simple Windows GUI s/w for a secretary to use to do
>> whois lookups for IP and ASNs and to easily copy/paste the results. 
>> Amazing that there is no such beast.
>> 
>> -Hank
>> 
>>> I use Launchy (a keystroke launcher similar to GnomeDo, Quicksilver,
>>> etc)
>>> and it's Runner plugin with some bat scripts that reference the builtin
>>> whois DOS/CLI command to create my own.
>>> 
>>> So for example, to look up an IP at ARIN I just hit my hotkey
>>> (Atl-Space)
>>> and type arin <tab> <IP> enter.  My bat script really just runs
>>> whois, sizes
>>> the command prompt window, and waits for user input before disappearing.
>>> 
>>> I'm happy to share my scripts off list if you are interested.
>>> 
>>>        -Scott
>>> 
>>> -----Original Message-----
>>> From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il]
>>> Sent: Thursday, May 10, 2012 2:49 AM
>>> To: nanog at nanog.org
>>> Subject: Looking for W7 whois freeware
>>> 
>>> I am looking for a Window 7 GUI utility that does raw whois - not the
>>> standard domain lookup, but rather allows me to specify and change
>>> the whois
>>> server I am talking to and allows me to customize the whois search
>>> string
>>> for IPs or ASNs or anything else a whois server will accept, like:
>>> "-B -G as378".
>>> 
>>> I know of ezwhois but am looking for something better (for example -
>>> they
>>> don't have whois.ripe.net listed - one can add it but not save it).
>>> 
>>> Thanks,
>>> Hank
>> 
>> 
> 
> 


From jhellenthal at dataix.net  Sun May 13 10:12:59 2012
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Sun, 13 May 2012 11:12:59 -0400
Subject: Looking for W7 whois freeware
In-Reply-To: <5.1.1.6.2.20120513081825.01ecc600@efes.iucc.ac.il>
References: <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120510094822.01f92470@efes.iucc.ac.il>
 <5.1.1.6.2.20120513081825.01ecc600@efes.iucc.ac.il>
Message-ID: <20120513151259.GE82738@DataIX.net>



On Sun, May 13, 2012 at 08:19:42AM +0300, Hank Nussbacher wrote:
> At 16:57 10/05/2012 -0400, Scott Berkman wrote:
> 
> I am looking for a simple Windows GUI s/w for a secretary to use to do 
> whois lookups for IP and ASNs and to easily copy/paste the 
> results.  Amazing that there is no such beast.
> 

Use your internal company webserver and write a simple CGI form that she
can fill out and hit enter. This way you can simply control the results
if you ever find out that you are not getting what you want.

You could have that CGI also email out the results to her mailbox and
yours just so you can keep an eye on it.

> 
> >I use Launchy (a keystroke launcher similar to GnomeDo, Quicksilver, etc)
> >and it's Runner plugin with some bat scripts that reference the builtin
> >whois DOS/CLI command to create my own.
> >
> >So for example, to look up an IP at ARIN I just hit my hotkey (Atl-Space)
> >and type arin <tab> <IP> enter.  My bat script really just runs whois, sizes
> >the command prompt window, and waits for user input before disappearing.
> >
> >I'm happy to share my scripts off list if you are interested.
> >
> >         -Scott
> >
> >-----Original Message-----
> >From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il]
> >Sent: Thursday, May 10, 2012 2:49 AM
> >To: nanog at nanog.org
> >Subject: Looking for W7 whois freeware
> >
> >I am looking for a Window 7 GUI utility that does raw whois - not the
> >standard domain lookup, but rather allows me to specify and change the whois
> >server I am talking to and allows me to customize the whois search string
> >for IPs or ASNs or anything else a whois server will accept, like:
> >"-B -G as378".
> >
> >I know of ezwhois but am looking for something better (for example - they
> >don't have whois.ripe.net listed - one can add it but not save it).
> >
> >Thanks,
> >Hank
> 

-- 

 - (2^(N-1))


From righa.shake at gmail.com  Mon May 14 01:35:40 2012
From: righa.shake at gmail.com (Righa Shake)
Date: Mon, 14 May 2012 09:35:40 +0300
Subject: Level3 Contact
Message-ID: <CAJO3VzyE=TBOL7PxdrD-dO3mnECAeVD5qqZSUJ2R1CGYfjAfRQ@mail.gmail.com>

Kindly would a Level3 contact get me off list please.

Regards,
Righa Shake

From alexb at ripe.net  Mon May 14 04:45:13 2012
From: alexb at ripe.net (Alex Band)
Date: Mon, 14 May 2012 11:45:13 +0200
Subject: RPKI performance metrics; your help requested
Message-ID: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>

As the global RPKI data set and system load grows, we want to ensure that the system is performing well. This is why we have added measurement functionality to the RIPE NCC RPKI Validator toolset:
https://www.ripe.net/certification/rpki-validator-metrics

When enabled, it will gather the following data and send it to the RIPE NCC for analysis:

- Connection success rate to the configured repositories
- Whether IPv4 or IPv6 is used to connect
- Repository inconsistencies
- Time taken to validate all retrieved objects

There is a detailed post on the sidr mailing list with more information:
http://www.ietf.org/mail-archive/web/sidr/current/msg04595.html

We would really appreciate it if as many people from across the globe send us performance data. 
If you would like to participate, please install the latest RPKI Validator and leave it running as a service permanently:

https://www.ripe.net/certification/tools-and-resources

All you need is a system with Java 1.6, rsync and 1GB of available memory. Simply unzip the file, run ./bin/rpki-validator from the base directory and browse to http://localhost:8080. Then enable the performance metrics by clicking "Yes" to the prompt.

If you have any questions or feedback, please let me know.

Many thanks,

Alex Band
RIPE NCC

From mike at smashing.net  Mon May 14 06:14:00 2012
From: mike at smashing.net (Mike Hughes)
Date: Mon, 14 May 2012 12:14:00 +0100
Subject: UKNOF 23 - Call for Presentations
Message-ID: <CAF0UPdFp=ujje84T-1+djmfWDVhSGT7odu5OgTtmzACUB0=5wg@mail.gmail.com>

Hi all,

The next UKNOF meeting will take place on Thursday 11th October 2012
in London, and the Programme Committee are seeking content from the
community for this meeting.

You may often hear it said that UKNOF's remit is "distribution of
clue", so if the content of your talk fits with that ethos, we're
actually pretty open minded about what the actual topic is - as long
as it's relevant to our community's broad area of interest, and the
quality is good.

Talks are usually around 20 to 40 minutes in length, and common
subject areas are:

    Network operations
    Network architecture and design
    Networking hardware and software architecture
    Peering and interconnect
    Data centre design and operations
    IPv6 deployment
    Network monitoring and measurement
    New innovations in networking technology
    Open protocol standards
    Domain Name System infrastructure
    Network security and abuse prevention
    Impact of public policy of network operations

But, we're always on the lookout for something different, so don't
feel it has to fall into the areas above.

We're also interested in hearing proposals for panel discussions, as
these are a great way of presenting and discussing different views on
the same subject.

Please send your proposals to <submissions at uknof.org.uk>, including a
short abstract of the subject, and draft slides if these are
available.

The closing date for submissions is the 30th June 2012, but don't
worry if you miss the deadline and have something interesting to talk
about, as we are often able to accept shorter (10 minute) "lightning
talks" closer in to the meeting.

Please also get in touch if you would like to suggest any topics,
themes or speakers.

Please note that UKNOF is free to attend, thanks to the generosity of
our sponsors, and run on a non-profit (cost-recovery) basis, so is
therefore unable to reimburse speakers' expenses.

Thanks,
Mike


From dave at temk.in  Mon May 14 13:43:26 2012
From: dave at temk.in (Dave Temkin)
Date: Mon, 14 May 2012 14:43:26 -0400
Subject: NANOG 55 Agenda Published!
Message-ID: <4FB1524E.2040406@temk.in>

All,

The NANOG 55 Agenda has been published and is viewable at: http://www.nanog.org/meetings/nanog55/agenda.php

Detailed abstracts will be added to the agenda over the next few days.

Please note that the hotel group rate expires on May 18th.  Late registration for the meeting begins on 
5/28, so please register today to save significant money!  You may register here: 
http://www.nanog.org/meetings/nanog55/nanog55_registration.html

Some individuals may require a Visa and/or valid passport to enter Canada, please see details *here. 
<http://www.cic.gc.ca/english/resources/publications/meeting.asp#question2>**

The NANOG Program Committee is proud of the program that we have assembled for Vancouver and we are looking 
forward to welcoming everyone to this amazing venue.

*Regards,
-Dave Temkin
For the NANOG Program Committee


From dave at temk.in  Mon May 14 13:43:26 2012
From: dave at temk.in (Dave Temkin)
Date: Mon, 14 May 2012 14:43:26 -0400
Subject: [NANOG-announce] NANOG 55 Agenda Published!
Message-ID: <4FB1524E.2040406@temk.in>

All,

The NANOG 55 Agenda has been published and is viewable at: http://www.nanog.org/meetings/nanog55/agenda.php

Detailed abstracts will be added to the agenda over the next few days.

Please note that the hotel group rate expires on May 18th.  Late registration for the meeting begins on 
5/28, so please register today to save significant money!  You may register here: 
http://www.nanog.org/meetings/nanog55/nanog55_registration.html

Some individuals may require a Visa and/or valid passport to enter Canada, please see details *here. 
<http://www.cic.gc.ca/english/resources/publications/meeting.asp#question2>**

The NANOG Program Committee is proud of the program that we have assembled for Vancouver and we are looking 
forward to welcoming everyone to this amazing venue.

*Regards,
-Dave Temkin
For the NANOG Program Committee

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From jason at thebaughers.com  Mon May 14 17:03:40 2012
From: jason at thebaughers.com (Jason Baugher)
Date: Mon, 14 May 2012 17:03:40 -0500
Subject: Cogent for ISP bandwidth
Message-ID: <4FB1813C.7080207@thebaughers.com>

The emails on the Outages list reminded me to ask this question...

I've done some searching and haven't been able to find much in the last 
3 years as to their reliability and suitability as an upstream provider. 
For a regional ISP looking for GigE ports in the Chicago/St. Louis area, 
is Cogent a reasonable solution? Our gut feeling is that they don't 
stack up against a Level3 or Sprint, but they are being very aggressive 
with pricing to try and get our business.

Thanks,
Jason


From john.yocum at fluidhosting.com  Mon May 14 17:12:29 2012
From: john.yocum at fluidhosting.com (John T. Yocum)
Date: Mon, 14 May 2012 15:12:29 -0700
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1813C.7080207@thebaughers.com>
References: <4FB1813C.7080207@thebaughers.com>
Message-ID: <4FB1834D.8080202@fluidhosting.com>

In my experience Cogent is fine when used in a BGP mix. When we used 
them, our service was quite reliable. Routing was funky at times, but we 
never had packet loss.

--John

On 5/14/2012 3:03 PM, Jason Baugher wrote:
> The emails on the Outages list reminded me to ask this question...
>
> I've done some searching and haven't been able to find much in the last
> 3 years as to their reliability and suitability as an upstream provider.
> For a regional ISP looking for GigE ports in the Chicago/St. Louis area,
> is Cogent a reasonable solution? Our gut feeling is that they don't
> stack up against a Level3 or Sprint, but they are being very aggressive
> with pricing to try and get our business.
>
> Thanks,
> Jason
>


From lists at mtin.net  Mon May 14 17:33:26 2012
From: lists at mtin.net (Justin Wilson)
Date: Mon, 14 May 2012 18:33:26 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1813C.7080207@thebaughers.com>
Message-ID: <CBD6FF65.2EFC2%lists@mtin.net>

	I have very little issues with Cogent in the Chicago/Indiana/St. Louis
areas. They are peered much better than they were a few years ago.

	We have 1 client at Cermack purchasing Cogent bandwidth through a third
party at well under $1 a meg.

	Justin


--
Justin Wilson <j2sw at mtin.net>
Aol & Yahoo IM: j2sw
http://www.mtin.net/blog ? xISP News
http://www.twitter.com/j2sw ? Follow me on Twitter



-----Original Message-----
From: Jason Baugher <jason at thebaughers.com>
Date: Monday, May 14, 2012 6:03 PM
To: nanog <nanog at nanog.org>
Subject: Cogent for ISP bandwidth

>The emails on the Outages list reminded me to ask this question...
>
>I've done some searching and haven't been able to find much in the last
>3 years as to their reliability and suitability as an upstream provider.
>For a regional ISP looking for GigE ports in the Chicago/St. Louis area,
>is Cogent a reasonable solution? Our gut feeling is that they don't
>stack up against a Level3 or Sprint, but they are being very aggressive
>with pricing to try and get our business.
>
>Thanks,
>Jason
>




From mike at m5computersecurity.com  Mon May 14 17:33:52 2012
From: mike at m5computersecurity.com (Michael J McCafferty)
Date: Mon, 14 May 2012 15:33:52 -0700
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1834D.8080202@fluidhosting.com>
References: <4FB1813C.7080207@thebaughers.com>
 <4FB1834D.8080202@fluidhosting.com>
Message-ID: <1337034832.24326.49.camel@barney>

Jason,

I agree with John. You can't use them as your only provider, but you
wouldn't do that with *any* provider. I will add that they answer the
phone quickly, and the person who answers usually has a clue, has access
to the routers, and can be helpful. It's one of the benefits that they
really only sell one product. Honestly, I think their support is better
than most and the deliver what they say or better.

In the past the had a A peer / B peer setup that was a little funky, but
I think they are getting rid of that as they upgrade hardware throughout
their network.

We do also use Level3 (and others). As long as they come in to your
facility on different fiber or otherwise meet you physical diversity
requirements, you should be pretty happy. Add low commits to other
providers for more diversity as needed.

Good luck,
Mike

On Mon, 2012-05-14 at 15:12 -0700, John T. Yocum wrote:
> In my experience Cogent is fine when used in a BGP mix. When we used 
> them, our service was quite reliable. Routing was funky at times, but we 
> never had packet loss.
> 
> --John
> 
> On 5/14/2012 3:03 PM, Jason Baugher wrote:
> > The emails on the Outages list reminded me to ask this question...
> >
> > I've done some searching and haven't been able to find much in the last
> > 3 years as to their reliability and suitability as an upstream provider.
> > For a regional ISP looking for GigE ports in the Chicago/St. Louis area,
> > is Cogent a reasonable solution? Our gut feeling is that they don't
> > stack up against a Level3 or Sprint, but they are being very aggressive
> > with pricing to try and get our business.
> >
> > Thanks,
> > Jason
> >
> 

-- 
************************************************************
Michael J. McCafferty
CEO
M5 Hosting
http://www.m5hosting.com

Like us on Facebook for updates and photos:
https://www.facebook.com/m5hosting
************************************************************



From pauldotwall at gmail.com  Mon May 14 17:58:16 2012
From: pauldotwall at gmail.com (Paul WALL)
Date: Mon, 14 May 2012 18:58:16 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <1337034832.24326.49.camel@barney>
References: <4FB1813C.7080207@thebaughers.com>
 <4FB1834D.8080202@fluidhosting.com>
 <1337034832.24326.49.camel@barney>
Message-ID: <CAHnQ7eJNWrwGExc+2L903OyAnABAz6Q8FEwdUX43c3JQ2RWjBw@mail.gmail.com>

Cogent is really better suited as a tertiary provider.

Not a bad option, but you don't want to lose redundancy when they get
involved in their peering dispute or de-peering du jour.

Drive Slow,
Paul Wall

On 5/14/12, Michael J McCafferty <mike at m5computersecurity.com> wrote:
> Jason,
>
> I agree with John. You can't use them as your only provider, but you
> wouldn't do that with *any* provider. I will add that they answer the
> phone quickly, and the person who answers usually has a clue, has access
> to the routers, and can be helpful. It's one of the benefits that they
> really only sell one product. Honestly, I think their support is better
> than most and the deliver what they say or better.
>
> In the past the had a A peer / B peer setup that was a little funky, but
> I think they are getting rid of that as they upgrade hardware throughout
> their network.
>
> We do also use Level3 (and others). As long as they come in to your
> facility on different fiber or otherwise meet you physical diversity
> requirements, you should be pretty happy. Add low commits to other
> providers for more diversity as needed.
>
> Good luck,
> Mike
>
> On Mon, 2012-05-14 at 15:12 -0700, John T. Yocum wrote:
>> In my experience Cogent is fine when used in a BGP mix. When we used
>> them, our service was quite reliable. Routing was funky at times, but we
>> never had packet loss.
>>
>> --John
>>
>> On 5/14/2012 3:03 PM, Jason Baugher wrote:
>> > The emails on the Outages list reminded me to ask this question...
>> >
>> > I've done some searching and haven't been able to find much in the last
>> > 3 years as to their reliability and suitability as an upstream
>> > provider.
>> > For a regional ISP looking for GigE ports in the Chicago/St. Louis
>> > area,
>> > is Cogent a reasonable solution? Our gut feeling is that they don't
>> > stack up against a Level3 or Sprint, but they are being very aggressive
>> > with pricing to try and get our business.
>> >
>> > Thanks,
>> > Jason
>> >
>>
>
> --
> ************************************************************
> Michael J. McCafferty
> CEO
> M5 Hosting
> http://www.m5hosting.com
>
> Like us on Facebook for updates and photos:
> https://www.facebook.com/m5hosting
> ************************************************************
>
>
>


From alter3d at alter3d.ca  Mon May 14 18:00:27 2012
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Mon, 14 May 2012 19:00:27 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <1337034832.24326.49.camel@barney>
References: <4FB1813C.7080207@thebaughers.com>
 <4FB1834D.8080202@fluidhosting.com> <1337034832.24326.49.camel@barney>
Message-ID: <4FB18E8B.7020900@alter3d.ca>

I use Cogent as one of our upstreams at work, and I'll basically 
reiterate what others have said -- overall, I'd have no problems 
recommending them.   Their routing can sometimes be a little weird 
(though this is MUCH better now than it was a couple of years ago), so I 
wouldn't necessarily use them as my main provider for latency-sensitive 
applications, but this isn't normally a problem with 'general' 
traffic.    The A peer/B peer stuff they used to do was definitely 
weird, but they migrated us away from that configuration a few months 
ago (peering with them out of TorIX).   Presumably they're doing that 
across the rest of their network.   Their support has been fantastic in 
my experience..

I'd have to say they're probably the least painful provider I've dealt 
with overall (unlike some providers *cough*Telus*cough* who I've been 
waiting 7 weeks for to set up a freaking BGP session...).   I'd have no 
problems picking Cogent as a provider, though of course as one of many 
providers for redundancy (which would be no different than any other 
single provider).

- Pete


On 5/14/2012 6:33 PM, Michael J McCafferty wrote:
> Jason,
>
> I agree with John. You can't use them as your only provider, but you
> wouldn't do that with *any* provider. I will add that they answer the
> phone quickly, and the person who answers usually has a clue, has access
> to the routers, and can be helpful. It's one of the benefits that they
> really only sell one product. Honestly, I think their support is better
> than most and the deliver what they say or better.
>
> In the past the had a A peer / B peer setup that was a little funky, but
> I think they are getting rid of that as they upgrade hardware throughout
> their network.
>
> We do also use Level3 (and others). As long as they come in to your
> facility on different fiber or otherwise meet you physical diversity
> requirements, you should be pretty happy. Add low commits to other
> providers for more diversity as needed.
>
> Good luck,
> Mike
>
> On Mon, 2012-05-14 at 15:12 -0700, John T. Yocum wrote:
>> In my experience Cogent is fine when used in a BGP mix. When we used
>> them, our service was quite reliable. Routing was funky at times, but we
>> never had packet loss.
>>
>> --John
>>
>> On 5/14/2012 3:03 PM, Jason Baugher wrote:
>>> The emails on the Outages list reminded me to ask this question...
>>>
>>> I've done some searching and haven't been able to find much in the last
>>> 3 years as to their reliability and suitability as an upstream provider.
>>> For a regional ISP looking for GigE ports in the Chicago/St. Louis area,
>>> is Cogent a reasonable solution? Our gut feeling is that they don't
>>> stack up against a Level3 or Sprint, but they are being very aggressive
>>> with pricing to try and get our business.
>>>
>>> Thanks,
>>> Jason
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4418 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120514/35787e31/attachment-0001.bin>

From nonobvious at gmail.com  Mon May 14 18:52:36 2012
From: nonobvious at gmail.com (Bill Stewart)
Date: Mon, 14 May 2012 16:52:36 -0700
Subject: Protocols for Testing Intrusion Detection?
Message-ID: <CAD45i01reSDHH=fvm=EPHhuHDdynkJ9u2K8rLTYvC5_dJx048w@mail.gmail.com>

I'm looking for recommended protocols to use for testing intrusion
detection and maybe also firewall logging.
Basically I need some kind of protocol that it's ok to discard traffic
for in a production network, so I can be sure that the various systems
that should be detecting it and generating alarms are up and running.
Is there already a standard I should be using?   (This doesn't seem to
quite match RFC2544.)   I'm thinking about things like
- TCP and UDP echo protocol - is this sufficiently deprecated that it
won't be missed, or are there applications still using it?
- Higher-numbered TCP protocol, such as 31337, which appears to have
no official current use, and unofficially is for Back Orifice.
- http:80 from a well-known test address, such as evil.example.com
(probably need both RFC1918 and public IP addresses, so it's somewhat
site-dependent.  Should I be using 192.0.2.0/24 or 198.18.0.0/15 as
long as I'm careful not to leak them out to the real internet?)
- Is there any application that can actually set the RFC3514 Evil Bit?

-- 
----
? ? ? ? ? ?? Thanks;? ?? Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.


From jra at baylink.com  Mon May 14 19:30:35 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 14 May 2012 20:30:35 -0400 (EDT)
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1813C.7080207@thebaughers.com>
Message-ID: <16295469.4200.1337041835820.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jason Baugher" <jason at thebaughers.com>

> I've done some searching and haven't been able to find much in the last
> 3 years as to their reliability and suitability as an upstream provider.

Really?  That surprises me; people complain about Cogent on here, roughly,
weekly.  :-)

> For a regional ISP looking for GigE ports in the Chicago/St. Louis area,
> is Cogent a reasonable solution? Our gut feeling is that they don't
> stack up against a Level3 or Sprint, but they are being very aggressive
> with pricing to try and get our business.

The implication of everyone's "in a BGP mix" responses, in case you don't
get it (and I suspect you might not) is that you don't want Cogent to be
your *only* upstream provider.

If you're going to resell the bandwidth as an ISP, best practice says you
should have at least 2 upstreams.  3 or more is better,

Cogent has had a bad habit the last 5 or 10 years of getting into pissing
matches with other carriers about peering, and just cutting them off
(or being cut off)... which of course means that if they're your only 
connection to the Internet, then your customers simply can't reach sites 
connected to those providers.

So, in short: no matter how agressive they are, they're not the carrier
to have when you're having only one.

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 jmaimon at ttec.com  Mon May 14 20:33:27 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 14 May 2012 21:33:27 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <1337034832.24326.49.camel@barney>
References: <4FB1813C.7080207@thebaughers.com>
 <4FB1834D.8080202@fluidhosting.com> <1337034832.24326.49.camel@barney>
Message-ID: <4FB1B267.3000100@ttec.com>



Michael J McCafferty wrote:
> Jason,
>
> I agree with John. You can't use them as your only provider, but you
> wouldn't do that with *any* provider. I will add that they answer the
> phone quickly, and the person who answers usually has a clue, has access
> to the routers, and can be helpful. It's one of the benefits that they
> really only sell one product. Honestly, I think their support is better
> than most and the deliver what they say or better.
>
> In the past the had a A peer / B peer setup that was a little funky, but
> I think they are getting rid of that as they upgrade hardware throughout
> their network.


I like the separate peers. Its a nice concept in theory and gives you 
the flexibility to easily integrate it into an RR setup.

I wouldnt mind more providers offering it as an option without having to 
be educated as to how it works.

Joe



From jason at thebaughers.com  Mon May 14 21:27:57 2012
From: jason at thebaughers.com (Jason Baugher)
Date: Mon, 14 May 2012 21:27:57 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <16295469.4200.1337041835820.JavaMail.root@benjamin.baylink.com>
References: <16295469.4200.1337041835820.JavaMail.root@benjamin.baylink.com>
Message-ID: <4FB1BF2D.4010605@thebaughers.com>

On 5/14/2012 7:30 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Jason Baugher"<jason at thebaughers.com>
>> I've done some searching and haven't been able to find much in the last
>> 3 years as to their reliability and suitability as an upstream provider.
> Really?  That surprises me; people complain about Cogent on here, roughly,
> weekly.  :-)
Sorry, been on this list for quite some time, and I even went back to 
the archives. I don't see much there that is specific to Cogent doing a 
bad job. If I go back a few years, I find stuff about Cogent-Telia, 
Cogent-GBX, and even Cogent-HE IPv6 peering.
>> For a regional ISP looking for GigE ports in the Chicago/St. Louis area,
>> is Cogent a reasonable solution? Our gut feeling is that they don't
>> stack up against a Level3 or Sprint, but they are being very aggressive
>> with pricing to try and get our business.
> The implication of everyone's "in a BGP mix" responses, in case you don't
> get it (and I suspect you might not) is that you don't want Cogent to be
> your *only* upstream provider.
>
> If you're going to resell the bandwidth as an ISP, best practice says you
> should have at least 2 upstreams.  3 or more is better,
This would be a 3rd or possibly a 4th upstream.
> Cogent has had a bad habit the last 5 or 10 years of getting into pissing
> matches with other carriers about peering, and just cutting them off
> (or being cut off)... which of course means that if they're your only
> connection to the Internet, then your customers simply can't reach sites
> connected to those providers.
>
> So, in short: no matter how agressive they are, they're not the carrier
> to have when you're having only one.
>
> Cheers,
> -- jra



From apishdadi at gmail.com  Mon May 14 21:38:34 2012
From: apishdadi at gmail.com (Ameen Pishdadi)
Date: Mon, 14 May 2012 21:38:34 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1813C.7080207@thebaughers.com>
References: <4FB1813C.7080207@thebaughers.com>
Message-ID: <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>

No way they stack up against level3 or any of the other 4 big tier 1s but if you throw them in a blend with level3 there shouldn't be any issue and I wouldn't pay more the .75 cents a meg for a gig 

Thanks,
Ameen Pishdadi


On May 14, 2012, at 5:03 PM, Jason Baugher <jason at thebaughers.com> wrote:

> The emails on the Outages list reminded me to ask this question...
> 
> I've done some searching and haven't been able to find much in the last 3 years as to their reliability and suitability as an upstream provider. For a regional ISP looking for GigE ports in the Chicago/St. Louis area, is Cogent a reasonable solution? Our gut feeling is that they don't stack up against a Level3 or Sprint, but they are being very aggressive with pricing to try and get our business.
> 
> Thanks,
> Jason
> 


From faisal at snappydsl.net  Mon May 14 22:49:23 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Mon, 14 May 2012 23:49:23 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
Message-ID: <4FB1D243.6000405@snappydsl.net>

I often tell folks, Cogent is the 'Heidi Fleiss' of the industry ...... 
pretty much everyone of the major carriers / providers deal with them.. 
but no one wants to admit it.

I don't think there is any carrier out there that could be considered 
'Premium' in terms of quality of service (yeah their are a lot of folks 
who are Premium based on what they charge)...

One can only hedge one's bet for a quality connection by having multiple 
providers (you can mix and match) or go with some one like Internap or 
Tinet (folks who are taking traffic across multiple providers at their POP).

Of course your mileage may vary.... as long as you have alternate 
connectivity, it makes dealing with issues more palatable, whether it is 
Cogent or Level3...

Regards.

Faisal Imtiaz
Snappy Internet&  Telecom


On 5/14/2012 10:38 PM, Ameen Pishdadi wrote:
> No way they stack up against level3 or any of the other 4 big tier 1s but if you throw them in a blend with level3 there shouldn't be any issue and I wouldn't pay more the .75 cents a meg for a gig
>
> Thanks,
> Ameen Pishdadi
>
>
> On May 14, 2012, at 5:03 PM, Jason Baugher<jason at thebaughers.com>  wrote:
>
>> The emails on the Outages list reminded me to ask this question...
>>
>> I've done some searching and haven't been able to find much in the last 3 years as to their reliability and suitability as an upstream provider. For a regional ISP looking for GigE ports in the Chicago/St. Louis area, is Cogent a reasonable solution? Our gut feeling is that they don't stack up against a Level3 or Sprint, but they are being very aggressive with pricing to try and get our business.
>>
>> Thanks,
>> Jason
>>
>



From apishdadi at gmail.com  Mon May 14 23:32:42 2012
From: apishdadi at gmail.com (Ameen Pishdadi)
Date: Mon, 14 May 2012 23:32:42 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1D243.6000405@snappydsl.net>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
Message-ID: <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>

Has nothing to do with whether or not they deal with all the major carriers , they are a budget provider , always have , always will be. Aside from that what matters the most is eye ball user connectivity and level3 , AT&T, Verizon significantly have more eye balls connected directly to there network then cogent , we have cogent and level3 and 5 other providers on our Chicago network , with out any traffic engineering almost every thing will come in or go out level3, we use traffic optimizing equipment to automate our commit levels and also do performance based routing adjustments , I literally have to put a gun to its head to get a descent amount of traffic out to cogent , you may say it's a matter of opinion but statistics don't lie, even Telia out performs cogent according to stats , not just cause they have a massive eye ball network in Europe.

Ask yourself , who are the majority customers of cogent? Not end user ISPs , hosting companies aka content providers, and when there selling bandwidth cheaper then it costs to peer then there going to keep there costs to the minimum ... Cheaper is cheaper , the saying is true , you get what you pay for. 

A Kia and Ferrari can both get me from point a to point b, but the Ferrari is capable of getting me there way quicker, and yes I'm going to pay a premium for it but if I'm going from NYC to San Fran I'd definitely feel safer in the Ferrari reliability wise and get there a hell of a lot quicker... 


But like I said and the other 10 replies nothing wrong with cogent in a nice blend of 3 or more other providers ...


Thanks,
Ameen Pishdadi


On May 14, 2012, at 10:49 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:

> I often tell folks, Cogent is the 'Heidi Fleiss' of the industry ...... pretty much everyone of the major carriers / providers deal with them.. but no one wants to admit it.
> 
> I don't think there is any carrier out there that could be considered 'Premium' in terms of quality of service (yeah their are a lot of folks who are Premium based on what they charge)...
> 
> One can only hedge one's bet for a quality connection by having multiple providers (you can mix and match) or go with some one like Internap or Tinet (folks who are taking traffic across multiple providers at their POP).
> 
> Of course your mileage may vary.... as long as you have alternate connectivity, it makes dealing with issues more palatable, whether it is Cogent or Level3...
> 
> Regards.
> 
> Faisal Imtiaz
> Snappy Internet&  Telecom
> 
> 
> On 5/14/2012 10:38 PM, Ameen Pishdadi wrote:
>> No way they stack up against level3 or any of the other 4 big tier 1s but if you throw them in a blend with level3 there shouldn't be any issue and I wouldn't pay more the .75 cents a meg for a gig
>> 
>> Thanks,
>> Ameen Pishdadi
>> 
>> 
>> On May 14, 2012, at 5:03 PM, Jason Baugher<jason at thebaughers.com>  wrote:
>> 
>>> The emails on the Outages list reminded me to ask this question...
>>> 
>>> I've done some searching and haven't been able to find much in the last 3 years as to their reliability and suitability as an upstream provider. For a regional ISP looking for GigE ports in the Chicago/St. Louis area, is Cogent a reasonable solution? Our gut feeling is that they don't stack up against a Level3 or Sprint, but they are being very aggressive with pricing to try and get our business.
>>> 
>>> Thanks,
>>> Jason
>>> 
>> 
> 
> 


From mpalmer at hezmatt.org  Mon May 14 23:39:49 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Tue, 15 May 2012 14:39:49 +1000
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1BF2D.4010605@thebaughers.com>
References: <16295469.4200.1337041835820.JavaMail.root@benjamin.baylink.com>
 <4FB1BF2D.4010605@thebaughers.com>
Message-ID: <20120515043949.GF2843@hezmatt.org>

On Mon, May 14, 2012 at 09:27:57PM -0500, Jason Baugher wrote:
> On 5/14/2012 7:30 PM, Jay Ashworth wrote:
> >----- Original Message -----
> >>From: "Jason Baugher"<jason at thebaughers.com>
> >>I've done some searching and haven't been able to find much in the last
> >>3 years as to their reliability and suitability as an upstream provider.
> >Really?  That surprises me; people complain about Cogent on here, roughly,
> >weekly.  :-)
>
> Sorry, been on this list for quite some time, and I even went back
> to the archives. I don't see much there that is specific to Cogent
> doing a bad job. If I go back a few years, I find stuff about
> Cogent-Telia, Cogent-GBX, and even Cogent-HE IPv6 peering.

So when you play "What's the common factor?", you get... ?  <grin>

We decided not to use Cogent as one of the suppliers for a recent PoP
deployment because of these sorts of games -- it's not that we'd get caught
in them (we've got three providers), but we just don't want to reward that
sort of behaviour with our money.

- Matt



From darden at armc.org  Tue May 15 06:27:38 2012
From: darden at armc.org (Darden, Patrick S.)
Date: Tue, 15 May 2012 07:27:38 -0400
Subject: Protocols for Testing Intrusion Detection?
In-Reply-To: <CAD45i01reSDHH=fvm=EPHhuHDdynkJ9u2K8rLTYvC5_dJx048w@mail.gmail.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE107524070D5A07@EX2K3.armc.org>


nmap has some modes that are useful for this:

nmap -sX network		#christmas treepackets are sent, nastygram, kamikaze, should light up any IPS
nmap -sS network		#stealth syn scan, should light up any good IPS
nmap -O network		#OS scan, should light up any sensitive IPS
nmap -o network		#udp scan, should light up any very sensitive IPS
nmap network		#ping + easy check for open ports from 1--1023, should only light up an overly sensitive IPS

Lots more modes, and lots more scales of sensitivity.  All of these are subjective.  DMZs, VMZs, inner networks, and private networks would all have different scales of sensitivity.  E.g. in my private network if I detected an "nmap network" then I would investigate.  In my DMZ I probably wouldn't take notice of such a general scan.

Does that help?
--p



-----Original Message-----
From: Bill Stewart [mailto:nonobvious at gmail.com]
Sent: Monday, May 14, 2012 7:53 PM
To: NANOG list
Subject: Protocols for Testing Intrusion Detection?


I'm looking for recommended protocols to use for testing intrusion
detection and maybe also firewall logging.
Basically I need some kind of protocol that it's ok to discard traffic
for in a production network, so I can be sure that the various systems
that should be detecting it and generating alarms are up and running.
Is there already a standard I should be using?   (This doesn't seem to
quite match RFC2544.)   I'm thinking about things like
- TCP and UDP echo protocol - is this sufficiently deprecated that it
won't be missed, or are there applications still using it?
- Higher-numbered TCP protocol, such as 31337, which appears to have
no official current use, and unofficially is for Back Orifice.
- http:80 from a well-known test address, such as evil.example.com
(probably need both RFC1918 and public IP addresses, so it's somewhat
site-dependent.  Should I be using 192.0.2.0/24 or 198.18.0.0/15 as
long as I'm careful not to leak them out to the real internet?)
- Is there any application that can actually set the RFC3514 Evil Bit?

-- 
----
? ? ? ? ? ?? Thanks;? ?? Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.



From manager at monmouth.com  Tue May 15 07:21:53 2012
From: manager at monmouth.com (Mark Stevens)
Date: Tue, 15 May 2012 08:21:53 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB1813C.7080207@thebaughers.com>
References: <4FB1813C.7080207@thebaughers.com>
Message-ID: <4FB24A61.9090506@monmouth.com>

We use Cogent as one our upstreams and have had nothing but stability 
and excellent support over the years. But as other said, you really need 
multiple upstreams and cannot rely just on one whether it is Cogent or 
any other provider.


Mark

On 5/14/2012 6:03 PM, Jason Baugher wrote:
> The emails on the Outages list reminded me to ask this question...
>
> I've done some searching and haven't been able to find much in the 
> last 3 years as to their reliability and suitability as an upstream 
> provider. For a regional ISP looking for GigE ports in the Chicago/St. 
> Louis area, is Cogent a reasonable solution? Our gut feeling is that 
> they don't stack up against a Level3 or Sprint, but they are being 
> very aggressive with pricing to try and get our business.
>
> Thanks,
> Jason
>
>
>
>


From frnkblk at iname.com  Tue May 15 07:27:15 2012
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 15 May 2012 07:27:15 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB24A61.9090506@monmouth.com>
References: <4FB1813C.7080207@thebaughers.com> <4FB24A61.9090506@monmouth.com>
Message-ID: <007e01cd3296$0fc62720$2f527560$@iname.com>

I'm surprised the IPv6 component hasn't been brought up, yet -- Cogent's
IPv6 prefix coverage is smaller than most.  So having even two providers is
insufficient -- you really need at least three, so that if any one of the
three goes down you're not IPv6-isolated.

Frank

-----Original Message-----
From: Mark Stevens [mailto:manager at monmouth.com] 
Sent: Tuesday, May 15, 2012 7:22 AM
To: nanog at nanog.org
Subject: Re: Cogent for ISP bandwidth

We use Cogent as one our upstreams and have had nothing but stability 
and excellent support over the years. But as other said, you really need 
multiple upstreams and cannot rely just on one whether it is Cogent or 
any other provider.


Mark

On 5/14/2012 6:03 PM, Jason Baugher wrote:
> The emails on the Outages list reminded me to ask this question...
>
> I've done some searching and haven't been able to find much in the 
> last 3 years as to their reliability and suitability as an upstream 
> provider. For a regional ISP looking for GigE ports in the Chicago/St. 
> Louis area, is Cogent a reasonable solution? Our gut feeling is that 
> they don't stack up against a Level3 or Sprint, but they are being 
> very aggressive with pricing to try and get our business.
>
> Thanks,
> Jason
>
>
>
>





From faisal at snappydsl.net  Tue May 15 08:00:24 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Tue, 15 May 2012 09:00:24 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
Message-ID: <4FB25368.9020506@snappydsl.net>

Let me say it differently.

Take a look at thier AS174  peering relationship, (e.g using  
bgp.he.net), you can see that they (Cogent) are very well connected 
(directly) with all of the major networks. (this is what I meant by, 
they deal with all of the major carriers).

Your experience with traffic is very different from what we have seen, 
while I  can understand that, it can be due to many factors.

Based on AS Peering relationships, it would appear that Major / Most of 
the end user ISP's have them in their mix. I my opinion the Hosting 
providers use Cogent as a way to off load incoming  traffic from the 
more expensive carriers. Cogent performance is very decent if the 
traffic is all on-net ... they typically have issues when traffic is 
crossing their network, i.e. coming in and going out via their peers to 
other networks.

While the Kia and Ferrari example is cute, but when put into the context 
of 'Traffic' or 'Speed limit', then neither has the advantage. One might 
look good driving in a Ferrari.. but I digress.... packets are agnostic 
of what brand of router they are traveling thru or whose network they 
are transiting.

We are in agreement, that Cogent makes a good backup secondary or 
tertiary in a mix of Ip transit. However having said that it is valuable 
to check the bgp peering relationships of the different providers that 
you have, to make sure that you are choosing providers based on actual 
diversity rather than a perceived one.

Regards.

Faisal Imtiaz
Snappy Internet&  Telecom


On 5/15/2012 12:32 AM, Ameen Pishdadi wrote:
> Has nothing to do with whether or not they deal with all the major carriers , they are a budget provider , always have , always will be. Aside from that what matters the most is eye ball user connectivity and level3 , AT&T, Verizon significantly have more eye balls connected directly to there network then cogent , we have cogent and level3 and 5 other providers on our Chicago network , with out any traffic engineering almost every thing will come in or go out level3, we use traffic optimizing equipment to automate our commit levels and also do performance based routing adjustments , I literally have to put a gun to its head to get a descent amount of traffic out to cogent , you may say it's a matter of opinion but statistics don't lie, even Telia out performs cogent according to stats , not just cause they have a massive eye ball network in Europe.
>
> Ask yourself , who are the majority customers of cogent? Not end user ISPs , hosting companies aka content providers, and when there selling bandwidth cheaper then it costs to peer then there going to keep there costs to the minimum ... Cheaper is cheaper , the saying is true , you get what you pay for.
>
> A Kia and Ferrari can both get me from point a to point b, but the Ferrari is capable of getting me there way quicker, and yes I'm going to pay a premium for it but if I'm going from NYC to San Fran I'd definitely feel safer in the Ferrari reliability wise and get there a hell of a lot quicker...
>
>
> But like I said and the other 10 replies nothing wrong with cogent in a nice blend of 3 or more other providers ...
>
>
> Thanks,
> Ameen Pishdadi
>
>
> On May 14, 2012, at 10:49 PM, Faisal Imtiaz<faisal at snappydsl.net>  wrote:
>
>> I often tell folks, Cogent is the 'Heidi Fleiss' of the industry ...... pretty much everyone of the major carriers / providers deal with them.. but no one wants to admit it.
>>
>> I don't think there is any carrier out there that could be considered 'Premium' in terms of quality of service (yeah their are a lot of folks who are Premium based on what they charge)...
>>
>> One can only hedge one's bet for a quality connection by having multiple providers (you can mix and match) or go with some one like Internap or Tinet (folks who are taking traffic across multiple providers at their POP).
>>
>> Of course your mileage may vary.... as long as you have alternate connectivity, it makes dealing with issues more palatable, whether it is Cogent or Level3...
>>
>> Regards.
>>
>> Faisal Imtiaz
>> Snappy Internet&   Telecom
>>
>>
>> On 5/14/2012 10:38 PM, Ameen Pishdadi wrote:
>>> No way they stack up against level3 or any of the other 4 big tier 1s but if you throw them in a blend with level3 there shouldn't be any issue and I wouldn't pay more the .75 cents a meg for a gig
>>>
>>> Thanks,
>>> Ameen Pishdadi
>>>
>>>
>>> On May 14, 2012, at 5:03 PM, Jason Baugher<jason at thebaughers.com>   wrote:
>>>
>>>> The emails on the Outages list reminded me to ask this question...
>>>>
>>>> I've done some searching and haven't been able to find much in the last 3 years as to their reliability and suitability as an upstream provider. For a regional ISP looking for GigE ports in the Chicago/St. Louis area, is Cogent a reasonable solution? Our gut feeling is that they don't stack up against a Level3 or Sprint, but they are being very aggressive with pricing to try and get our business.
>>>>
>>>> Thanks,
>>>> Jason
>>>>
>>



From jason at thebaughers.com  Tue May 15 08:39:42 2012
From: jason at thebaughers.com (Jason Baugher)
Date: Tue, 15 May 2012 08:39:42 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB25368.9020506@snappydsl.net>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net>
Message-ID: <4FB25C9E.60607@thebaughers.com>

I appreciate the reference to bgp.he.net, I had not used that tool before.

We've worked with Sprint for years, and they have always been excellent 
for reliability and support. We recently picked up Level3, and so far 
they have been very good as well. It's a small thing, maybe, but I like 
that both Sprint and Level3 have nice online tools for change requests, 
trouble tickets, etc... We've been a Lightcore/CenturyLink customer for 
years as well, also very reliable. They don't have the slick online 
tools, but I can usually get a live person in their NOC.

Cogent is being very aggressive with their pricing, and if it weren't 
for the fact that we are geographically challenged and have to pay for 
transport to get to them, we might have already taken them up on it.

Thanks for all the input from everyone.

Jason


5/15/2012 8:00 AM, Faisal Imtiaz wrote:
> Let me say it differently.
>
> Take a look at thier AS174  peering relationship, (e.g using  
> bgp.he.net), you can see that they (Cogent) are very well connected 
> (directly) with all of the major networks. (this is what I meant by, 
> they deal with all of the major carriers).
>
> Your experience with traffic is very different from what we have seen, 
> while I  can understand that, it can be due to many factors.
>
> Based on AS Peering relationships, it would appear that Major / Most 
> of the end user ISP's have them in their mix. I my opinion the Hosting 
> providers use Cogent as a way to off load incoming  traffic from the 
> more expensive carriers. Cogent performance is very decent if the 
> traffic is all on-net ... they typically have issues when traffic is 
> crossing their network, i.e. coming in and going out via their peers 
> to other networks.
>
> While the Kia and Ferrari example is cute, but when put into the 
> context of 'Traffic' or 'Speed limit', then neither has the advantage. 
> One might look good driving in a Ferrari.. but I digress.... packets 
> are agnostic of what brand of router they are traveling thru or whose 
> network they are transiting.
>
> We are in agreement, that Cogent makes a good backup secondary or 
> tertiary in a mix of Ip transit. However having said that it is 
> valuable to check the bgp peering relationships of the different 
> providers that you have, to make sure that you are choosing providers 
> based on actual diversity rather than a perceived one.
>
> Regards.
>
> Faisal Imtiaz
> Snappy Internet&  Telecom
>
>
> On 5/15/2012 12:32 AM, Ameen Pishdadi wrote:
>> Has nothing to do with whether or not they deal with all the major 
>> carriers , they are a budget provider , always have , always will be. 
>> Aside from that what matters the most is eye ball user connectivity 
>> and level3 , AT&T, Verizon significantly have more eye balls 
>> connected directly to there network then cogent , we have cogent and 
>> level3 and 5 other providers on our Chicago network , with out any 
>> traffic engineering almost every thing will come in or go out level3, 
>> we use traffic optimizing equipment to automate our commit levels and 
>> also do performance based routing adjustments , I literally have to 
>> put a gun to its head to get a descent amount of traffic out to 
>> cogent , you may say it's a matter of opinion but statistics don't 
>> lie, even Telia out performs cogent according to stats , not just 
>> cause they have a massive eye ball network in Europe.
>>
>> Ask yourself , who are the majority customers of cogent? Not end user 
>> ISPs , hosting companies aka content providers, and when there 
>> selling bandwidth cheaper then it costs to peer then there going to 
>> keep there costs to the minimum ... Cheaper is cheaper , the saying 
>> is true , you get what you pay for.
>>
>> A Kia and Ferrari can both get me from point a to point b, but the 
>> Ferrari is capable of getting me there way quicker, and yes I'm going 
>> to pay a premium for it but if I'm going from NYC to San Fran I'd 
>> definitely feel safer in the Ferrari reliability wise and get there a 
>> hell of a lot quicker...
>>
>>
>> But like I said and the other 10 replies nothing wrong with cogent in 
>> a nice blend of 3 or more other providers ...
>>
>>
>> Thanks,
>> Ameen Pishdadi
>>
>>
>> On May 14, 2012, at 10:49 PM, Faisal Imtiaz<faisal at snappydsl.net>  
>> wrote:
>>
>>> I often tell folks, Cogent is the 'Heidi Fleiss' of the industry 
>>> ...... pretty much everyone of the major carriers / providers deal 
>>> with them.. but no one wants to admit it.
>>>
>>> I don't think there is any carrier out there that could be 
>>> considered 'Premium' in terms of quality of service (yeah their are 
>>> a lot of folks who are Premium based on what they charge)...
>>>
>>> One can only hedge one's bet for a quality connection by having 
>>> multiple providers (you can mix and match) or go with some one like 
>>> Internap or Tinet (folks who are taking traffic across multiple 
>>> providers at their POP).
>>>
>>> Of course your mileage may vary.... as long as you have alternate 
>>> connectivity, it makes dealing with issues more palatable, whether 
>>> it is Cogent or Level3...
>>>
>>> Regards.
>>>
>>> Faisal Imtiaz
>>> Snappy Internet&   Telecom
>>>
>>>
>>> On 5/14/2012 10:38 PM, Ameen Pishdadi wrote:
>>>> No way they stack up against level3 or any of the other 4 big tier 
>>>> 1s but if you throw them in a blend with level3 there shouldn't be 
>>>> any issue and I wouldn't pay more the .75 cents a meg for a gig
>>>>
>>>> Thanks,
>>>> Ameen Pishdadi
>>>>
>>>>
>>>> On May 14, 2012, at 5:03 PM, Jason Baugher<jason at thebaughers.com>   
>>>> wrote:
>>>>
>>>>> The emails on the Outages list reminded me to ask this question...
>>>>>
>>>>> I've done some searching and haven't been able to find much in the 
>>>>> last 3 years as to their reliability and suitability as an 
>>>>> upstream provider. For a regional ISP looking for GigE ports in 
>>>>> the Chicago/St. Louis area, is Cogent a reasonable solution? Our 
>>>>> gut feeling is that they don't stack up against a Level3 or 
>>>>> Sprint, but they are being very aggressive with pricing to try and 
>>>>> get our business.
>>>>>
>>>>> Thanks,
>>>>> Jason
>>>>>
>>>
>
>
>
>



From jkrejci at usinternet.com  Tue May 15 09:03:05 2012
From: jkrejci at usinternet.com (Justin Krejci)
Date: Tue, 15 May 2012 14:03:05 +0000
Subject: Cogent for ISP bandwidth
Message-ID: <1565443154-1337090586-cardhu_decombobulator_blackberry.rim.net-2132518071-@b13.c4.bise6.blackberry>

+1 for cogent, problem free and good responsive support.

Not sure why "don't use only 1 upstream if you care about accessibility" has anything to do with cogent specifically. Are peering/de-peering disputes more likely to occur than all other network/routing issues combined? its just another possible cause for an outage.



------Original Message------
From: Mark Stevens
To: nanog at nanog.org
ReplyTo: manager at monmouth.com
Subject: Re: Cogent for ISP bandwidth
Sent: May 15, 2012 7:21 AM

We use Cogent as one our upstreams and have had nothing but stability 
and excellent support over the years. But as other said, you really need 
multiple upstreams and cannot rely just on one whether it is Cogent or 
any other provider.


Mark

On 5/14/2012 6:03 PM, Jason Baugher wrote:
> The emails on the Outages list reminded me to ask this question...
>
> I've done some searching and haven't been able to find much in the 
> last 3 years as to their reliability and suitability as an upstream 
> provider. For a regional ISP looking for GigE ports in the Chicago/St. 
> Louis area, is Cogent a reasonable solution? Our gut feeling is that 
> they don't stack up against a Level3 or Sprint, but they are being 
> very aggressive with pricing to try and get our business.
>
> Thanks,
> Jason
>
>
>
>



From swm at emanon.com  Tue May 15 09:06:17 2012
From: swm at emanon.com (Scott Morris)
Date: Tue, 15 May 2012 10:06:17 -0400
Subject: BGP Clueful at Reliance Globalcom?
Message-ID: <4FB262D9.4020000@emanon.com>

Can someone from Reliance Globalcom who is clueful on their BGP
operations please contact me offlist?

I appreciate it!

-- 

 


*Scott Morris*

swm at emanon.com


Knowledge is power.

Power corrupts.

Study hard and be Eeeeviiiil......




From drew.weaver at thenap.com  Tue May 15 09:16:06 2012
From: drew.weaver at thenap.com (Drew Weaver)
Date: Tue, 15 May 2012 10:16:06 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <1565443154-1337090586-cardhu_decombobulator_blackberry.rim.net-2132518071-@b13.c4.bise6.blackberry>
References: <1565443154-1337090586-cardhu_decombobulator_blackberry.rim.net-2132518071-@b13.c4.bise6.blackberry>
Message-ID: <F3318834F1F89D46857972DD4B411D70053476F4DB@exchange>

I'm most likely wrong, but doesn't Cogent basically just a lease dark fiber/wavelengths from Level3's for the majority of their POP connectivity?

I know they have purchased some assets in the past but I'm under the impression they're highly levered to L3.

Wont they eventually run into a squeeze (possibly man made and intentional) which will force their pricing to go up?

Although, I suppose folks have been saying that the pricing isn't sustainable since Cogent began.

This is likely off-topic for this particular thread but has anyone seen any evidence yet of issues resulting from the L3/Global Crossing merger as far as pricing?

-Drew

-----Original Message-----
From: Justin Krejci [mailto:jkrejci at usinternet.com] 
Sent: Tuesday, May 15, 2012 10:03 AM
To: nanog at nanog.org
Subject: Re: Cogent for ISP bandwidth

+1 for cogent, problem free and good responsive support.

Not sure why "don't use only 1 upstream if you care about accessibility" has anything to do with cogent specifically. Are peering/de-peering disputes more likely to occur than all other network/routing issues combined? its just another possible cause for an outage.



------Original Message------
From: Mark Stevens
To: nanog at nanog.org
ReplyTo: manager at monmouth.com
Subject: Re: Cogent for ISP bandwidth
Sent: May 15, 2012 7:21 AM

We use Cogent as one our upstreams and have had nothing but stability and excellent support over the years. But as other said, you really need multiple upstreams and cannot rely just on one whether it is Cogent or any other provider.


Mark

On 5/14/2012 6:03 PM, Jason Baugher wrote:
> The emails on the Outages list reminded me to ask this question...
>
> I've done some searching and haven't been able to find much in the 
> last 3 years as to their reliability and suitability as an upstream 
> provider. For a regional ISP looking for GigE ports in the Chicago/St.
> Louis area, is Cogent a reasonable solution? Our gut feeling is that 
> they don't stack up against a Level3 or Sprint, but they are being 
> very aggressive with pricing to try and get our business.
>
> Thanks,
> Jason
>
>
>
>




From nicolai-nanog at chocolatine.org  Tue May 15 09:58:03 2012
From: nicolai-nanog at chocolatine.org (Nicolai)
Date: Tue, 15 May 2012 09:58:03 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
Message-ID: <20120515145803.GA16765@vectra.student.iastate.edu>

On Mon, May 14, 2012 at 09:38:34PM -0500, Ameen Pishdadi wrote:
> No way they stack up against level3 or any of the other 4 big tier 1s
> but if you throw them in a blend with level3 there shouldn't be any
> issue and I wouldn't pay more the .75 cents a meg for a gig

That's $7.50 per 1000mbps.  Sign me up!

Nicolai


From valdis.kletnieks at vt.edu  Tue May 15 10:23:15 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Tue, 15 May 2012 11:23:15 -0400
Subject: Protocols for Testing Intrusion Detection?
In-Reply-To: Your message of "Mon, 14 May 2012 16:52:36 -0700."
 <CAD45i01reSDHH=fvm=EPHhuHDdynkJ9u2K8rLTYvC5_dJx048w@mail.gmail.com>
References: <CAD45i01reSDHH=fvm=EPHhuHDdynkJ9u2K8rLTYvC5_dJx048w@mail.gmail.com>
Message-ID: <15834.1337095395@turing-police.cc.vt.edu>

On Mon, 14 May 2012 16:52:36 -0700, Bill Stewart said:
> - Is there any application that can actually set the RFC3514 Evil Bit?

Here ya go. hping3 patch. Swiss army knives always need one more blade...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hping3.3514.patch
Type: application/x-patch
Size: 3111 bytes
Desc: hping3.3514.patch
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120515/016eba6b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120515/016eba6b/attachment-0001.bin>

From ren.provo at gmail.com  Tue May 15 10:32:38 2012
From: ren.provo at gmail.com (Ren Provo)
Date: Tue, 15 May 2012 11:32:38 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <4FB25C9E.60607@thebaughers.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
Message-ID: <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>

Keep in mind http://bgp.he.net is not always accurate.  It is a great
start but even after years of pointing it out there are adjacencies
missing and oddly some listed as direct where no relationship even
exists.

On Tue, May 15, 2012 at 9:39 AM, Jason Baugher <jason at thebaughers.com> wrote:
> I appreciate the reference to bgp.he.net, I had not used that tool before.


From scott at sberkman.net  Tue May 15 11:17:22 2012
From: scott at sberkman.net (Scott Berkman)
Date: Tue, 15 May 2012 12:17:22 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAHnQ7eJNWrwGExc+2L903OyAnABAz6Q8FEwdUX43c3JQ2RWjBw@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <4FB1834D.8080202@fluidhosting.com> <1337034832.24326.49.camel@barney>
 <CAHnQ7eJNWrwGExc+2L903OyAnABAz6Q8FEwdUX43c3JQ2RWjBw@mail.gmail.com>
Message-ID: <012d01cd32b6$3678de60$a36a9b20$@sberkman.net>

+1 here.  Some would say if you are of a certain size, you almost NEED to
have a Cogent connection amongst others for when they have their spats.

If you are missing the history here, check out this link:
http://en.wikipedia.org/wiki/Cogent_Communications#Peering

	-Scott

-----Original Message-----
From: Paul WALL [mailto:pauldotwall at gmail.com] 
Sent: Monday, May 14, 2012 6:58 PM
To: Michael J McCafferty
Cc: nanog at nanog.org
Subject: Re: Cogent for ISP bandwidth

Cogent is really better suited as a tertiary provider.

Not a bad option, but you don't want to lose redundancy when they get
involved in their peering dispute or de-peering du jour.

Drive Slow,
Paul Wall

On 5/14/12, Michael J McCafferty <mike at m5computersecurity.com> wrote:
> Jason,
>
> I agree with John. You can't use them as your only provider, but you 
> wouldn't do that with *any* provider. I will add that they answer the 
> phone quickly, and the person who answers usually has a clue, has 
> access to the routers, and can be helpful. It's one of the benefits 
> that they really only sell one product. Honestly, I think their 
> support is better than most and the deliver what they say or better.
>
> In the past the had a A peer / B peer setup that was a little funky, 
> but I think they are getting rid of that as they upgrade hardware 
> throughout their network.
>
> We do also use Level3 (and others). As long as they come in to your 
> facility on different fiber or otherwise meet you physical diversity 
> requirements, you should be pretty happy. Add low commits to other 
> providers for more diversity as needed.
>
> Good luck,
> Mike
>
> On Mon, 2012-05-14 at 15:12 -0700, John T. Yocum wrote:
>> In my experience Cogent is fine when used in a BGP mix. When we used 
>> them, our service was quite reliable. Routing was funky at times, but 
>> we never had packet loss.
>>
>> --John
>>
>> On 5/14/2012 3:03 PM, Jason Baugher wrote:
>> > The emails on the Outages list reminded me to ask this question...
>> >
>> > I've done some searching and haven't been able to find much in the 
>> > last
>> > 3 years as to their reliability and suitability as an upstream 
>> > provider.
>> > For a regional ISP looking for GigE ports in the Chicago/St. Louis 
>> > area, is Cogent a reasonable solution? Our gut feeling is that they 
>> > don't stack up against a Level3 or Sprint, but they are being very 
>> > aggressive with pricing to try and get our business.
>> >
>> > Thanks,
>> > Jason
>> >
>>
>
> --
> ************************************************************
> Michael J. McCafferty
> CEO
> M5 Hosting
> http://www.m5hosting.com
>
> Like us on Facebook for updates and photos:
> https://www.facebook.com/m5hosting
> ************************************************************
>
>
>




From me at anuragbhatia.com  Tue May 15 11:36:56 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 15 May 2012 22:06:56 +0530
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
Message-ID: <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>

The only issue I saw with bgp.he.net is that it updates after 24hrs which
makes it hard to use for any recently made changes. But for rest works
pretty good.

On Tue, May 15, 2012 at 9:02 PM, Ren Provo <ren.provo at gmail.com> wrote:

> Keep in mind http://bgp.he.net is not always accurate.  It is a great
> start but even after years of pointing it out there are adjacencies
> missing and oddly some listed as direct where no relationship even
> exists.
>
> On Tue, May 15, 2012 at 9:39 AM, Jason Baugher <jason at thebaughers.com>
> wrote:
> > I appreciate the reference to bgp.he.net, I had not used that tool
> before.
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From randy at psg.com  Tue May 15 12:00:18 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 15 May 2012 07:00:18 -1000
Subject: pbx recco
Message-ID: <m2vcjxwfa5.wl%randy@psg.com>

have a friend who is a penguinista and wants to run a simple soft pbx.
support of soft phones, 7960s, connect to a commercial sip gate, ...
reccos for a packaged solution.

i run a raw asterisk and would not wish it on my worst enemy.

randy


From jra at baylink.com  Tue May 15 12:15:08 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 May 2012 13:15:08 -0400 (EDT)
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <26666510.4278.1337102108278.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Randy Bush" <randy at psg.com>

> have a friend who is a penguinista and wants to run a simple soft pbx.
> support of soft phones, 7960s, connect to a commercial sip gate, ...
> reccos for a packaged solution.
> 
> i run a raw asterisk and would not wish it on my worst enemy.

Heh.

I've been fond of FreePBX, myself, though the new version they were
working on seemed like it was going to break all the best bits.

Ward Mundy, @NerdUno, packages it as PBXinaFlash; 1.7.5.5 was decent.

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 cgrosskopf at scoe.org  Tue May 15 12:18:06 2012
From: cgrosskopf at scoe.org (Cody Grosskopf)
Date: Tue, 15 May 2012 10:18:06 -0700 (PDT)
Subject: pbx recco
In-Reply-To: <26666510.4278.1337102108278.JavaMail.root@benjamin.baylink.com>
Message-ID: <1324601030.10277185.1337102286196.JavaMail.root@zimbra.scoe.org>

Elastix should do the trick.

----- Original Message -----
From: "Jay Ashworth" <jra at baylink.com>
To: "NANOG" <nanog at nanog.org>
Sent: Tuesday, May 15, 2012 10:15:08 AM
Subject: Re: pbx recco

----- Original Message -----
> From: "Randy Bush" <randy at psg.com>

> have a friend who is a penguinista and wants to run a simple soft pbx.
> support of soft phones, 7960s, connect to a commercial sip gate, ...
> reccos for a packaged solution.
> 
> i run a raw asterisk and would not wish it on my worst enemy.

Heh.

I've been fond of FreePBX, myself, though the new version they were
working on seemed like it was going to break all the best bits.

Ward Mundy, @NerdUno, packages it as PBXinaFlash; 1.7.5.5 was decent.

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


Notice to Recipient:  Information contained in this message may be privileged, confidential and  protected from disclosure. If you are not an intended recipient, it is  strictly prohibited to use, disseminate or copy this communication. If you  have received this in error, please reply to the sender and then delete the  message.Thank you.


From tknchris at gmail.com  Tue May 15 12:24:50 2012
From: tknchris at gmail.com (chris)
Date: Tue, 15 May 2012 13:24:50 -0400
Subject: pbx recco
In-Reply-To: <1324601030.10277185.1337102286196.JavaMail.root@zimbra.scoe.org>
References: <26666510.4278.1337102108278.JavaMail.root@benjamin.baylink.com>
 <1324601030.10277185.1337102286196.JavaMail.root@zimbra.scoe.org>
Message-ID: <CAKnNFz_McoTQ_OD_03dkx+d10wjcAX0U9sK8MkyzxVFgq8Pbvw@mail.gmail.com>

i can see the ads coming now....

1 weird trick for a good phone system!

rofl

On Tue, May 15, 2012 at 1:18 PM, Cody Grosskopf <cgrosskopf at scoe.org> wrote:

> Elastix should do the trick.
>
> ----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>
> To: "NANOG" <nanog at nanog.org>
> Sent: Tuesday, May 15, 2012 10:15:08 AM
> Subject: Re: pbx recco
>
> ----- Original Message -----
> > From: "Randy Bush" <randy at psg.com>
>
> > have a friend who is a penguinista and wants to run a simple soft pbx.
> > support of soft phones, 7960s, connect to a commercial sip gate, ...
> > reccos for a packaged solution.
> >
> > i run a raw asterisk and would not wish it on my worst enemy.
>
> Heh.
>
> I've been fond of FreePBX, myself, though the new version they were
> working on seemed like it was going to break all the best bits.
>
> Ward Mundy, @NerdUno, packages it as PBXinaFlash; 1.7.5.5 was decent.
>
> 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
>
>
> Notice to Recipient:  Information contained in this message may be
> privileged, confidential and  protected from disclosure. If you are not an
> intended recipient, it is  strictly prohibited to use, disseminate or copy
> this communication. If you  have received this in error, please reply to
> the sender and then delete the  message.Thank you.
>
>

From carlosm3011 at gmail.com  Tue May 15 12:55:51 2012
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 15 May 2012 14:55:51 -0300
Subject: Video streaming over IPv6
Message-ID: <4FB298A7.802@gmail.com>

Hello,

Can anyone comment on the availability of IPv6 video streaming services?
I'm thinking about commercial, 'cloud'-based services a la U-Stream or
Make.TV.

I can roll my own, and will eventually do so, but having a commercial
service that I could use would make my life so much easier :-)

Any such service who is thinking about jumping on the World IPv6 Launch
Day bandwagon and could use some (I'd like to think clueful) debugging
can also contact me, we might be able to work something out.

regards,

Carlos


From jared at puck.nether.net  Tue May 15 13:02:05 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 15 May 2012 14:02:05 -0400
Subject: Video streaming over IPv6
In-Reply-To: <4FB298A7.802@gmail.com>
References: <4FB298A7.802@gmail.com>
Message-ID: <12827E4A-D7EE-412B-AF93-C40369F500AA@puck.nether.net>


On May 15, 2012, at 1:55 PM, Carlos Martinez-Cagnazzo wrote:

> Hello,
> 
> Can anyone comment on the availability of IPv6 video streaming services?
> I'm thinking about commercial, 'cloud'-based services a la U-Stream or
> Make.TV.
> 
> I can roll my own, and will eventually do so, but having a commercial
> service that I could use would make my life so much easier :-)
> 
> Any such service who is thinking about jumping on the World IPv6 Launch
> Day bandwagon and could use some (I'd like to think clueful) debugging
> can also contact me, we might be able to work something out.


I know that some services (e.g.: youtube) already have native ipv6 being served for existing http streaming mechanisms.

I'm not sure where all the other individual services are in that process, but if they are behind the popular CDNs, e.g.: Akamai I believe its just a simple provisioning box one selects with them to enable IPv6 as well.

- Jared

From cconn at b2b2c.ca  Tue May 15 13:23:27 2012
From: cconn at b2b2c.ca (Chris Conn)
Date: Tue, 15 May 2012 14:23:27 -0400
Subject: Earthlink/RIR1.ORG admin with a clue?
Message-ID: <4FB29F1F.1040606@b2b2c.ca>

Hello,

If a Earthlink/rir1.org hosting admin would care to contact me off-list 
since it appears the abuse department at earthlink does not understand 
what hosting a phishing site means.  I am being asked for logs to 
"prove" something, yet the URL I supply which clearly brings someone to 
a phishing site is apparently not "proof".

Thanks,

Chris Conn
B2B2C.ca



From wayne.wenthin at cascadetech.org  Tue May 15 13:29:38 2012
From: wayne.wenthin at cascadetech.org (Wayne Wenthin)
Date: Tue, 15 May 2012 11:29:38 -0700
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com>
References: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <CAJnYNY+Z7g+G5eh5Nf8O5o_XT-NdCXU1kyi3_U++gXLE1_z-cA@mail.gmail.com>

Randy,

Greets from 105/102!
Now that I've said that I have had some luck with Trixbox.   His fun will
be getting the Cisco phones talking sip and liking it.

Wayne

On Tue, May 15, 2012 at 10:00 AM, Randy Bush <randy at psg.com> wrote:

> have a friend who is a penguinista and wants to run a simple soft pbx.
> support of soft phones, 7960s, connect to a commercial sip gate, ...
> reccos for a packaged solution.
>
> i run a raw asterisk and would not wish it on my worst enemy.
>
> randy
>
>

From tim at interworx.nl  Tue May 15 13:33:28 2012
From: tim at interworx.nl (Tim Vollebregt)
Date: Tue, 15 May 2012 20:33:28 +0200
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
Message-ID: <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>

+1 for Cogent in the mix :)

People with a clue in their NOC, near zero routing issues in last 1,5 years.

On May 15, 2012, at 6:36 PM, Anurag Bhatia wrote:

> The only issue I saw with bgp.he.net is that it updates after 24hrs which
> makes it hard to use for any recently made changes. But for rest works
> pretty good.
> 
> On Tue, May 15, 2012 at 9:02 PM, Ren Provo <ren.provo at gmail.com> wrote:
> 
>> Keep in mind http://bgp.he.net is not always accurate.  It is a great
>> start but even after years of pointing it out there are adjacencies
>> missing and oddly some listed as direct where no relationship even
>> exists.
>> 
>> On Tue, May 15, 2012 at 9:39 AM, Jason Baugher <jason at thebaughers.com>
>> wrote:
>>> I appreciate the reference to bgp.he.net, I had not used that tool
>> before.
>> 
>> 
> 
> 
> -- 
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>



From xenophage at godshell.com  Tue May 15 13:33:15 2012
From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold)
Date: Tue, 15 May 2012 14:33:15 -0400
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com>
References: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <8115ED66-A391-448D-A9A5-696570E199F6@godshell.com>

On May 15, 2012, at 1:00 PM, Randy Bush wrote:
> have a friend who is a penguinista and wants to run a simple soft pbx.
> support of soft phones, 7960s, connect to a commercial sip gate, ...
> reccos for a packaged solution.

I'd recommend checking out SipXecs ..  It's a really slick open source system supporting all of the above, plus a bit more.  And there's a commercial arm as well that offers a commercially supported version with additional bells and whistles.

http://www.sipfoundry.org

> randy

---------------------------
Jason 'XenoPhage' Frisvold
xenophage at godshell.com
---------------------------
"Any sufficiently advanced magic is indistinguishable from technology."
- Niven's Inverse of Clarke's Third Law





From joly at punkcast.com  Tue May 15 13:36:00 2012
From: joly at punkcast.com (Joly MacFie)
Date: Tue, 15 May 2012 14:36:00 -0400
Subject: Video streaming over IPv6
In-Reply-To: <4FB298A7.802@gmail.com>
References: <4FB298A7.802@gmail.com>
Message-ID: <CAM9VJk0dgQtghgrTrvdHH3j=xY8_XYOTQ7yzOdVKGuBBhVjT1A@mail.gmail.com>

On Jun 6 I'll be streaming an ISOC-HK IPv6 Day
event<http://www.isoc.hk/2012/04/world-ipv6-launch-x-ipv6-in-action-x-ipv6worldasia-jun-6-12.html>via
Livestream.com, as I did last year when it was a source of some
ridicule/embarrassment that we only made it available in v4.

Even if we had the connectivity out of the venue, which I haven't bothered
to check, it doesn't seem like the tools exist.

Maybe next year we can have IPv6 streaming launch day...

j

On Tue, May 15, 2012 at 1:55 PM, Carlos Martinez-Cagnazzo <
carlosm3011 at gmail.com> wrote:

> Hello,
>
> Can anyone comment on the availability of IPv6 video streaming services?
> I'm thinking about commercial, 'cloud'-based services a la U-Stream or
> Make.TV.
>
> I can roll my own, and will eventually do so, but having a commercial
> service that I could use would make my life so much easier :-)
>
> Any such service who is thinking about jumping on the World IPv6 Launch
> Day bandwagon and could use some (I'd like to think clueful) debugging
> can also contact me, we might be able to work something out.
>
> regards,
>
> Carlos
>
>


-- 
---------------------------------------------------------------
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 regnauld at nsrc.org  Tue May 15 13:41:01 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Tue, 15 May 2012 18:41:01 +0000
Subject: pbx recco
In-Reply-To: <CAJnYNY+Z7g+G5eh5Nf8O5o_XT-NdCXU1kyi3_U++gXLE1_z-cA@mail.gmail.com>
References: <m2vcjxwfa5.wl%randy@psg.com>
 <CAJnYNY+Z7g+G5eh5Nf8O5o_XT-NdCXU1kyi3_U++gXLE1_z-cA@mail.gmail.com>
Message-ID: <20120515184101.GK32475@macbook.bluepipe.net>

Wayne Wenthin (wayne.wenthin) writes:
> Randy,
> 
> Greets from 105/102!
> Now that I've said that I have had some luck with Trixbox.   His fun will
> be getting the Cisco phones talking sip and liking it.

	Am running Trixbox (which wraps FreePBX) for 11 users, and using 7940s.

	Has been working like a charm for the last 3 years.

	Phil


From r.engehausen at gmail.com  Tue May 15 14:21:31 2012
From: r.engehausen at gmail.com (Roy)
Date: Tue, 15 May 2012 12:21:31 -0700
Subject: pbx recco
In-Reply-To: <CAJnYNY+Z7g+G5eh5Nf8O5o_XT-NdCXU1kyi3_U++gXLE1_z-cA@mail.gmail.com>
References: <m2vcjxwfa5.wl%randy@psg.com>
 <CAJnYNY+Z7g+G5eh5Nf8O5o_XT-NdCXU1kyi3_U++gXLE1_z-cA@mail.gmail.com>
Message-ID: <4FB2ACBB.3010002@gmail.com>



Trixbox is basically stagnated.  The last update was in 2010

On 5/15/2012 11:29 AM, Wayne Wenthin wrote:
> Randy,
>
> Greets from 105/102!
> Now that I've said that I have had some luck with Trixbox.   His fun will
> be getting the Cisco phones talking sip and liking it.
>
> Wayne
>
> On Tue, May 15, 2012 at 10:00 AM, Randy Bush<randy at psg.com>  wrote:
>
>> have a friend who is a penguinista and wants to run a simple soft pbx.
>> support of soft phones, 7960s, connect to a commercial sip gate, ...
>> reccos for a packaged solution.
>>
>> i run a raw asterisk and would not wish it on my worst enemy.
>>
>> randy
>>
>>



From rmosher at he.net  Tue May 15 14:30:55 2012
From: rmosher at he.net (Rob Mosher)
Date: Tue, 15 May 2012 15:30:55 -0400
Subject: bgp.he.net (was: Cogent for ISP bandwidth)
In-Reply-To: <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
Message-ID: <4FB2AEEF.7030806@he.net>

As previously mentioned, if you would like better representation in 
bgp.he.net, you can provide a feed to RIPE RIS or Routeviews, as this is 
where we get our data.  If an adjacency is visible here, it is reported. 
  We do not report false adjacencies.  If you have a specific question 
about an adjacency, email me and I will provide the exact route with the 
AS path demonstrating the adjacency.

--
Rob Mosher
Senior Network and Software Engineer
Hurricane Electric / AS6939


On 5/15/2012 11:32 AM, Ren Provo wrote:
> Keep in mind http://bgp.he.net is not always accurate.  It is a great
> start but even after years of pointing it out there are adjacencies
> missing and oddly some listed as direct where no relationship even
> exists.
>
> On Tue, May 15, 2012 at 9:39 AM, Jason Baugher<jason at thebaughers.com>  wrote:
>> I appreciate the reference to bgp.he.net, I had not used that tool before.


From rs at seastrom.com  Tue May 15 14:33:48 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Tue, 15 May 2012 15:33:48 -0400
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com> (Randy Bush's message of "Tue,
 15 May 2012 07:00:18 -1000")
References: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <86mx59dysj.fsf@seastrom.com>


Randy Bush <randy at psg.com> writes:

> have a friend who is a penguinista and wants to run a simple soft pbx.
> support of soft phones, 7960s, connect to a commercial sip gate, ...
> reccos for a packaged solution.

While Asterisk's configuration files are horrible (and written by
people who didn't understand what a tokenizer is) it's really a case
of the more clueful you are the worse off you'll find it.  You just
have to take a megadose of stupid pills in order to be happy with
Asterisk's configuration.

I've been using Astlinux, which allows access to the underlying files
(in fact you edit them through a web interface) successfully with
voip.ms (wholesale voip provider for cheap) for almost three years
now.  My experience fooling around with stuff like Trixbox, Askozia,
and FreePBX is that there are plenty of cute GUI wrappers out there
for configuring stuff, but at the end of the day as painful as
handling the files directly is, it's a lot less painful than trying to
work around the GUI's lossage whenever you want to do something that
the designers didn't anticipate, which is pretty much all the time.

Making Cisco 7940/7960 phones with SIP loads talk to Asterisk is
well-documented, and their lossage modes are well-understood.

Back to Astlinux, it's a pre-baked distro with click-here
upgradability that will run nicely from CF on an embedded box like a
PCEngines ALIX 2d3 (~15 simultaneous calls if you're not transcoding).
6 watts of power.  Not a bad deal.

> i run a raw asterisk and would not wish it on my worst enemy.

Sure you would, you'd encourage your competitors to use it.  :)

-r



From mohacsi at niif.hu  Tue May 15 14:58:44 2012
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Tue, 15 May 2012 21:58:44 +0200 (CEST)
Subject: Video streaming over IPv6
In-Reply-To: <4FB298A7.802@gmail.com>
References: <4FB298A7.802@gmail.com>
Message-ID: <alpine.BSF.2.00.1205152149220.40024@mignon.ki.iif.hu>

Hi,
 	Currently the videostreaming on IPv6, might be possible with RTP, 
RTMP, RTSP, HTML5, etc. - not with more intelligent Adobe Flash players 
(player control, stream quality selection etc.). The most of tha cases is 
the problem lies in Adobe Flash. In one hand The flash URL parsing is 
broken for IPv6 (does not recognised literal IPv6 addresses), other hand 
the player cannot fall-back to IPv4, or they don't implement 
happy-eyeballs.

Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Director Network and Multimedia
NIIF/HUNGARNET, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Tue, 15 May 2012, Carlos Martinez-Cagnazzo wrote:

> Hello,
>
> Can anyone comment on the availability of IPv6 video streaming services?
> I'm thinking about commercial, 'cloud'-based services a la U-Stream or
> Make.TV.
>
> I can roll my own, and will eventually do so, but having a commercial
> service that I could use would make my life so much easier :-)
>
> Any such service who is thinking about jumping on the World IPv6 Launch
> Day bandwagon and could use some (I'd like to think clueful) debugging
> can also contact me, we might be able to work something out.
>
> regards,
>
> Carlos
>
>


From carlos at race.com  Tue May 15 15:07:50 2012
From: carlos at race.com (Carlos Alcantar)
Date: Tue, 15 May 2012 20:07:50 +0000
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <CBD80585.74F7A%carlos@race.com>

+1 on pbxinaflash

http://pbxinaflash.net/


Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Randy Bush <randy at psg.com>
Date: Tue, 15 May 2012 07:00:18 -1000
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: pbx recco

have a friend who is a penguinista and wants to run a simple soft pbx.
support of soft phones, 7960s, connect to a commercial sip gate, ...
reccos for a packaged solution.

i run a raw asterisk and would not wish it on my worst enemy.

randy





From jared at puck.nether.net  Tue May 15 15:12:34 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 15 May 2012 16:12:34 -0400
Subject: pbx recco
In-Reply-To: <86mx59dysj.fsf@seastrom.com>
References: <m2vcjxwfa5.wl%randy@psg.com> <86mx59dysj.fsf@seastrom.com>
Message-ID: <ACBA7D7D-3DF5-459E-9FE4-21E34352832C@puck.nether.net>


On May 15, 2012, at 3:33 PM, Robert E. Seastrom wrote:

> Randy Bush <randy at psg.com> writes:
> 
>> have a friend who is a penguinista and wants to run a simple soft pbx.
>> support of soft phones, 7960s, connect to a commercial sip gate, ...
>> reccos for a packaged solution.
> 
> While Asterisk's configuration files are horrible (and written by
> people who didn't understand what a tokenizer is) it's really a case
> of the more clueful you are the worse off you'll find it.  You just
> have to take a megadose of stupid pills in order to be happy with
> Asterisk's configuration.

so, I've also been running asterisk in various iterations.  It's much better than it was in the past, but what I've found is once you poke at it enough macros are your friend and make your life easier.

I'm not sure how many of you have programmed some other type of PBX while on a modem or terminal, but asterisk clearly makes it easier to diagnose what is going on and integrate a number of other solutions.  It's also really meant to be run in a Linux environment vs *BSD.  Much pain can be explained by trying to deal with OS port variances.

The biggest problem I've seen is that for mass-users, the diverse network environments pose challenges to VoIP.  Many international hotels block 5060 or have broken NAT/ALG issues.

You usually need to VPN to the PBX or "internet" to work around these issues in my experience.

- Jared (A mostly happy asterisk user)

From goemon at anime.net  Tue May 15 15:51:49 2012
From: goemon at anime.net (goemon at anime.net)
Date: Tue, 15 May 2012 13:51:49 -0700 (PDT)
Subject: Earthlink/RIR1.ORG admin with a clue?
In-Reply-To: <4FB29F1F.1040606@b2b2c.ca>
References: <4FB29F1F.1040606@b2b2c.ca>
Message-ID: <Pine.LNX.4.64.1205151351270.9039@sasami.anime.net>

fix your mail filters and maybe someone might be able to respond to you.

    ----- Transcript of session follows -----
... while talking to smtp.cidc.net.:
>>> DATA
<<< 550 5.7.1 Rejected (100.00) - Retry with Cc: abuse at b2b2c.ca for analysis
554 5.0.0 Service unavailable

-Dan

On Tue, 15 May 2012, Chris Conn wrote:

> Hello,
>
> If a Earthlink/rir1.org hosting admin would care to contact me off-list since 
> it appears the abuse department at earthlink does not understand what hosting 
> a phishing site means.  I am being asked for logs to "prove" something, yet 
> the URL I supply which clearly brings someone to a phishing site is 
> apparently not "proof".
>
> Thanks,
>
> Chris Conn
> B2B2C.ca
>
>


From jvanoppen at spectrumnet.us  Tue May 15 16:47:11 2012
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Tue, 15 May 2012 21:47:11 +0000
Subject: Cogent for ISP bandwidth
In-Reply-To: <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
 <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE76327DC12AD@mail1-sea.office.spectrumnet.us>

We have cogent in the mix, and I do have to say one gets what one pays for...    They are a no redundancy, no extra capacity kind of shop...   This often is noticeable when they have fiber cuts or equipment failures, it also results in a lot more service affecting maintenance than our other providers.

That being said, we have several 10Gs to them as one of our five upstreams, we mostly use them for on-net traffic and a couple of selected peers where they seem not to have congestion issues.     My biggest bone to pick with them though is their incredibly crappy BGP community offering.     They have no selective (ie per peer) announcement control options which severely limits our ability to use them more since we end up sending their "perpend to [all] peers" community instead of just prepending to the peers we don't like the return routes on.

Thanks,
John @ AS11404



From apishdadi at gmail.com  Tue May 15 16:51:20 2012
From: apishdadi at gmail.com (A. Pishdadi)
Date: Tue, 15 May 2012 16:51:20 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <20120515145803.GA16765@vectra.student.iastate.edu>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <20120515145803.GA16765@vectra.student.iastate.edu>
Message-ID: <CAHGyo+-q0B7R5s4mYwPvh=BSAbgimDgA1eLwRxvahSySsrs4Rw@mail.gmail.com>

last time i checked .75 x 1000 = 750

On Tue, May 15, 2012 at 9:58 AM, Nicolai <nicolai-nanog at chocolatine.org>wrote:

> On Mon, May 14, 2012 at 09:38:34PM -0500, Ameen Pishdadi wrote:
> > No way they stack up against level3 or any of the other 4 big tier 1s
> > but if you throw them in a blend with level3 there shouldn't be any
> > issue and I wouldn't pay more the .75 cents a meg for a gig
>
> That's $7.50 per 1000mbps.  Sign me up!
>
> Nicolai
>
>

From alter3d at alter3d.ca  Tue May 15 17:19:18 2012
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Tue, 15 May 2012 18:19:18 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAHGyo+-q0B7R5s4mYwPvh=BSAbgimDgA1eLwRxvahSySsrs4Rw@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <20120515145803.GA16765@vectra.student.iastate.edu>
 <CAHGyo+-q0B7R5s4mYwPvh=BSAbgimDgA1eLwRxvahSySsrs4Rw@mail.gmail.com>
Message-ID: <4FB2D666.7050802@alter3d.ca>

You're using Verizon Math.  ;)   (If you don't know what this is, go 
Google it!)

"0.75 cents" is not "0.75 dollars".    "point 75 cents" == $0.0075.    
$0.0075 * 1000 = $7.50

- Peter


On 12-05-15 05:51 PM, A. Pishdadi wrote:
> last time i checked .75 x 1000 = 750
>
> On Tue, May 15, 2012 at 9:58 AM, Nicolai<nicolai-nanog at chocolatine.org>wrote:
>
>> On Mon, May 14, 2012 at 09:38:34PM -0500, Ameen Pishdadi wrote:
>>> No way they stack up against level3 or any of the other 4 big tier 1s
>>> but if you throw them in a blend with level3 there shouldn't be any
>>> issue and I wouldn't pay more the .75 cents a meg for a gig
>> That's $7.50 per 1000mbps.  Sign me up!
>>
>> Nicolai
>>
>>


From apishdadi at gmail.com  Tue May 15 17:23:53 2012
From: apishdadi at gmail.com (A. Pishdadi)
Date: Tue, 15 May 2012 17:23:53 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <201205152222.q4FMMQsC093707@mail.r-bonomi.com>
References: <CAHGyo+-q0B7R5s4mYwPvh=BSAbgimDgA1eLwRxvahSySsrs4Rw@mail.gmail.com>
 <201205152222.q4FMMQsC093707@mail.r-bonomi.com>
Message-ID: <CAHGyo+8gAp-kXZ=uaRZyoLA7o8uDf-SMo4_BOUaReaujDUmV0A@mail.gmail.com>

dam, i think this got more replies then the original thread in 10 minutes.
lol

On Tue, May 15, 2012 at 5:22 PM, Robert Bonomi <bonomi at mail.r-bonomi.com>wrote:

> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Tue May 15
> 16:53:50 2012
> > From: "A. Pishdadi" <apishdadi at gmail.com>
> > Date: Tue, 15 May 2012 16:51:20 -0500
> > Subject: Re: Cogent for ISP bandwidth
> > To: Nicolai <nicolai-nanog at chocolatine.org>
> > Cc: nanog at nanog.org
> >
> > last time i checked .75 x 1000 = 750
>
> 0.75 CENTS (as previously claimed) per meg is 750 CENTS per gig, or
> $7.50/gig.
>
> I suspect you 'meant '75 cents' (or '$0.75') per meg, but that is -not-
> what
> you said. :)
> >
> > On Tue, May 15, 2012 at 9:58 AM, Nicolai <nicolai-nanog at chocolatine.org
> >wrote:
> >
> > > On Mon, May 14, 2012 at 09:38:34PM -0500, Ameen Pishdadi wrote:
> > > > No way they stack up against level3 or any of the other 4 big tier 1s
> > > > but if you throw them in a blend with level3 there shouldn't be any
> > > > issue and I wouldn't pay more the .75 cents a meg for a gig
> > >
> > > That's $7.50 per 1000mbps.  Sign me up!
> > >
> > > Nicolai
> > >
> > >
> >
>

From jra at baylink.com  Tue May 15 17:49:34 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 May 2012 18:49:34 -0400 (EDT)
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAHGyo+-q0B7R5s4mYwPvh=BSAbgimDgA1eLwRxvahSySsrs4Rw@mail.gmail.com>
Message-ID: <7870050.4504.1337122174324.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "A. Pishdadi" <apishdadi at gmail.com>

> On Tue, May 15, 2012 at 9:58 AM, Nicolai
> <nicolai-nanog at chocolatine.org>wrote:
> 
> > On Mon, May 14, 2012 at 09:38:34PM -0500, Ameen Pishdadi wrote:
> > > No way they stack up against level3 or any of the other 4 big tier
> > > 1s
> > > but if you throw them in a blend with level3 there shouldn't be
> > > any
> > > issue and I wouldn't pay more the .75 cents a meg for a gig
> >
> > That's $7.50 per 1000mbps. Sign me up!

> last time i checked .75 x 1000 = 750

.75 dollars times 1000 = $750, yes.

But that's not what was written.  *That* was .75 cents, which, yes, 
comes out to $7.50/gbps.

Cheers,
-- jr 'and please don't make me fix your quoting' 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 nanog at lacutt.com  Tue May 15 17:58:01 2012
From: nanog at lacutt.com (Derrick H.)
Date: Tue, 15 May 2012 17:58:01 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <7870050.4504.1337122174324.JavaMail.root@benjamin.baylink.com>
References: <CAHGyo+-q0B7R5s4mYwPvh=BSAbgimDgA1eLwRxvahSySsrs4Rw@mail.gmail.com>
 <7870050.4504.1337122174324.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120515225759.GG12518@nm.lacutt.com>

On Tue, May 15, 2012 at 06:49:34PM -0400, Jay Ashworth wrote:
> ----- Original Message -----
> > From: "A. Pishdadi" <apishdadi at gmail.com>
> 
> > On Tue, May 15, 2012 at 9:58 AM, Nicolai
> > <nicolai-nanog at chocolatine.org>wrote:
> > 
> > > On Mon, May 14, 2012 at 09:38:34PM -0500, Ameen Pishdadi wrote:
> > > > No way they stack up against level3 or any of the other 4 big tier
> > > > 1s
> > > > but if you throw them in a blend with level3 there shouldn't be
> > > > any
> > > > issue and I wouldn't pay more the .75 cents a meg for a gig
> > >
> > > That's $7.50 per 1000mbps. Sign me up!
> 
> > last time i checked .75 x 1000 = 750
> 
> .75 dollars times 1000 = $750, yes.
> 
> But that's not what was written.  *That* was .75 cents, which, yes, 
> comes out to $7.50/gbps.

Reminds me of the infamous "Verizon Math":
http://www.youtube.com/watch?v=D2isSJKntbg

http://www.youtube.com/results?search_query=verizon+math&oq=verizon+math&aq=f&aqi=g6&aql=&gs_l=youtube.3..0l6.200.1851.0.2224.12.12.0.0.0.0.153.1126.6j6.12.0...0.0.HdrCiFAtWK0


Derrick

> 
> Cheers,
> -- jr 'and please don't make me fix your quoting' 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 tom at ninjabadger.net  Tue May 15 18:01:09 2012
From: tom at ninjabadger.net (Tom Hill)
Date: Wed, 16 May 2012 00:01:09 +0100
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com>
References: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <4FB2E035.9030104@ninjabadger.net>

On 15/05/12 18:00, Randy Bush wrote:
> i run a raw asterisk and would not wish it on my worst enemy.

I've been itching to try Freeswitch ever since I read this:

http://www.freeswitch.org/node/117

Tom


From mysidia at gmail.com  Tue May 15 19:26:50 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 15 May 2012 19:26:50 -0500
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAHnQ7eJNWrwGExc+2L903OyAnABAz6Q8FEwdUX43c3JQ2RWjBw@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <4FB1834D.8080202@fluidhosting.com>
 <1337034832.24326.49.camel@barney>
 <CAHnQ7eJNWrwGExc+2L903OyAnABAz6Q8FEwdUX43c3JQ2RWjBw@mail.gmail.com>
Message-ID: <CAAAwwbVamByqdPD8w9EM7s4HdyyBgqg2Ku-L2nOPQRq+pSC7WA@mail.gmail.com>

On 5/14/12, Paul WALL <pauldotwall at gmail.com> wrote:
> Cogent is really better suited as a tertiary provider.
> Not a bad option, but you don't want to lose redundancy when they get
> involved in their peering dispute or de-peering du jour.

I'll agree with that; if you have less than 3 upstreams; Cogent sounds risky
for that very reason.    If you have at least 3 upstreams for your network,
and you make sure they don't share common modes of failure, such as
the same fiber, then Cogents' service may be a suitable choice for one of those.

If you are serious about network availability,  triple redundancy is the bare
minimum anyways,   because there are lots of bad things that can happen
to an upstream network or their cabling that may take 24+ hours to repair,
during which  time a single SFP failure, router maintenance  on the
remaining upstream, or lots of  other smaller  more common equipment
glitches may incur total outage,  before there is any real chance
to recover redundancy.

Least cost options of achieving triple  and quad-redundancy are attractive

> Drive Slow,
> Paul Wall
--
-JH


From smb at cs.columbia.edu  Tue May 15 19:42:36 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 15 May 2012 20:42:36 -0400
Subject: Protocols for Testing Intrusion Detection?
In-Reply-To: <CAD45i01reSDHH=fvm=EPHhuHDdynkJ9u2K8rLTYvC5_dJx048w@mail.gmail.com>
References: <CAD45i01reSDHH=fvm=EPHhuHDdynkJ9u2K8rLTYvC5_dJx048w@mail.gmail.com>
Message-ID: <2B9280F7-BA6A-4FE5-A62F-F4B5F2A21ACC@cs.columbia.edu>

On May 14, 2012, at 7:52 PM, Bill Stewart wrote:
> 
> - Is there any application that can actually set the RFC3514 Evil Bit?


Code was added to FreeBSD to set it (though I think the commit was later
reverted); see the change logs at https://www.cs.columbia.edu/~smb/3514.html


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







From thomas.mangin at exa-networks.co.uk  Wed May 16 03:21:26 2012
From: thomas.mangin at exa-networks.co.uk (Thomas Mangin)
Date: Wed, 16 May 2012 09:21:26 +0100
Subject: pbx recco
In-Reply-To: <4FB2E035.9030104@ninjabadger.net>
References: <m2vcjxwfa5.wl%randy@psg.com> <4FB2E035.9030104@ninjabadger.net>
Message-ID: <5A34CF1F-9C91-49EA-BEEF-0EFDA0D63809@exa-networks.co.uk>


On 16 May 2012, at 00:01, Tom Hill wrote:

> I've been itching to try Freeswitch ever since I read this:
> http://www.freeswitch.org/node/117

Using FreeSwitch to provide trunk services for nearly a year. Very happy with it. Just does what it says on the tin.
Currently installing a CudaTel as our office PBX before recommending it or not to customer (eating your own dog food) so far so good :)

Thomas



From diogo.montagner at gmail.com  Wed May 16 07:09:16 2012
From: diogo.montagner at gmail.com (Diogo Montagner)
Date: Wed, 16 May 2012 20:09:16 +0800
Subject: Cross connecting two routers with channelized interfaces
Message-ID: <CACB8Nf7tO55BZ7bPBuRR3Gtm4QGmH1WSTEk5Fijz2QF=rp3eUg@mail.gmail.com>

Hello,

sorry for this dumb question.

Is it possible to connect two routers like below ?

RouterA/cstm1 ---- dark fiber ---- cstm1/RouterB

The interfaces used in this case are channelized STM1 in both sides.
Between RouterA and RouterB I would like to create many low-speed
interfaces ranging from 64Kbps up to 2Mbps. Between these two routers
there is no MUX.

The framing mode has to be SDH.

Thanks in advance!

Diogo


From faisal at snappydsl.net  Wed May 16 07:23:11 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Wed, 16 May 2012 08:23:11 -0400
Subject: Cross connecting two routers with channelized interfaces
In-Reply-To: <CACB8Nf7tO55BZ7bPBuRR3Gtm4QGmH1WSTEk5Fijz2QF=rp3eUg@mail.gmail.com>
References: <CACB8Nf7tO55BZ7bPBuRR3Gtm4QGmH1WSTEk5Fijz2QF=rp3eUg@mail.gmail.com>
Message-ID: <22750BA7-0C15-48E5-BBA0-5E39083F8F01@snappydsl.net>

Yes, u will have to connect the fibers in a cross manner..and setup one side to generate the clock..

Faisal

On May 16, 2012, at 8:09 AM, Diogo Montagner <diogo.montagner at gmail.com> wrote:

> Hello,
> 
> sorry for this dumb question.
> 
> Is it possible to connect two routers like below ?
> 
> RouterA/cstm1 ---- dark fiber ---- cstm1/RouterB
> 
> The interfaces used in this case are channelized STM1 in both sides.
> Between RouterA and RouterB I would like to create many low-speed
> interfaces ranging from 64Kbps up to 2Mbps. Between these two routers
> there is no MUX.
> 
> The framing mode has to be SDH.
> 
> Thanks in advance!
> 
> Diogo
> 
> 


From diogo.montagner at gmail.com  Wed May 16 07:31:10 2012
From: diogo.montagner at gmail.com (Diogo Montagner)
Date: Wed, 16 May 2012 20:31:10 +0800
Subject: Cross connecting two routers with channelized interfaces
In-Reply-To: <22750BA7-0C15-48E5-BBA0-5E39083F8F01@snappydsl.net>
References: <CACB8Nf7tO55BZ7bPBuRR3Gtm4QGmH1WSTEk5Fijz2QF=rp3eUg@mail.gmail.com>
 <22750BA7-0C15-48E5-BBA0-5E39083F8F01@snappydsl.net>
Message-ID: <CACB8Nf6ovtMz0SokvHHAnf7qkn3aYpY-m8DDicVYqiANhxG5Qg@mail.gmail.com>

Hi Faisal,

I have tried the setup in my lab. I can get the cSTM1s UP and the
controllers E1 up. But when I try to configure the subinterface, the
protocol does not come online.

Below is the configuration in one of the sides. The other side has
similar configuration.

controller SONET 4/0/2
 framing SDH
 aug controller au-4-tug-3
!

controller AU-4-TUG-3 4/0/2.1/1
 mode c-12
 tug-2 1 e1 1 channel-group 0 timeslots 1
!

interface Serial4/0/2.1/1/1/1:0
 bandwidth 64
 ip address 10.1.1.1 255.255.255.252
 encapsulation ppp
 load-interval 30
 no fair-queue
end

Thanks

Diogo


On Wed, May 16, 2012 at 8:23 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
> Yes, u will have to connect the fibers in a cross manner..and setup one side to generate the clock..
>
> Faisal
>
> On May 16, 2012, at 8:09 AM, Diogo Montagner <diogo.montagner at gmail.com> wrote:
>
>> Hello,
>>
>> sorry for this dumb question.
>>
>> Is it possible to connect two routers like below ?
>>
>> RouterA/cstm1 ---- dark fiber ---- cstm1/RouterB
>>
>> The interfaces used in this case are channelized STM1 in both sides.
>> Between RouterA and RouterB I would like to create many low-speed
>> interfaces ranging from 64Kbps up to 2Mbps. Between these two routers
>> there is no MUX.
>>
>> The framing mode has to be SDH.
>>
>> Thanks in advance!
>>
>> Diogo
>>
>>


From simon.perreault at viagenie.ca  Wed May 16 07:39:09 2012
From: simon.perreault at viagenie.ca (Simon Perreault)
Date: Wed, 16 May 2012 08:39:09 -0400
Subject: pbx recco
In-Reply-To: <4FB2E035.9030104@ninjabadger.net>
References: <m2vcjxwfa5.wl%randy@psg.com> <4FB2E035.9030104@ninjabadger.net>
Message-ID: <4FB39FED.8000604@viagenie.ca>

On 2012-05-15 19:01, Tom Hill wrote:
> On 15/05/12 18:00, Randy Bush wrote:
>> i run a raw asterisk and would not wish it on my worst enemy.
>
> I've been itching to try Freeswitch

I know FreeSWITCH and Asterisk from the inside out because we ported 
both of them to IPv6.

Verdict:

- Asterisk started ugly but is getting much better very quickly. They 
actually have paid professional coders working on it, and it shows. They 
started participating in the IETF. They recently implemented ICE. 
They're on the right track.

- FreeSWITCH started much prettier by reusing third-party libraries. But 
the glue code around these libs is absolutely horrendous. That glue code 
keeps growing and getting uglier. Their level of clue is dropping.

Right now, I'd pick Asterisk over FreeSWITCH.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


From lathama at gmail.com  Wed May 16 07:42:30 2012
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 16 May 2012 08:42:30 -0400
Subject: pbx recco
In-Reply-To: <4FB39FED.8000604@viagenie.ca>
References: <m2vcjxwfa5.wl%randy@psg.com> <4FB2E035.9030104@ninjabadger.net>
 <4FB39FED.8000604@viagenie.ca>
Message-ID: <CA+qj4S-3SpKN28tGJ1CNtuNDCmnmEZC8mKwrP970NTbG2k6UKQ@mail.gmail.com>

On Wed, May 16, 2012 at 8:39 AM, Simon Perreault
<simon.perreault at viagenie.ca> wrote:
> On 2012-05-15 19:01, Tom Hill wrote:
>>
>> On 15/05/12 18:00, Randy Bush wrote:
>>>
>>> i run a raw asterisk and would not wish it on my worst enemy.
>>
>>
>> I've been itching to try Freeswitch
>
>
> I know FreeSWITCH and Asterisk from the inside out because we ported both of
> them to IPv6.
>
> Verdict:
>
> - Asterisk started ugly but is getting much better very quickly. They
> actually have paid professional coders working on it, and it shows. They
> started participating in the IETF. They recently implemented ICE. They're on
> the right track.
>
> - FreeSWITCH started much prettier by reusing third-party libraries. But the
> glue code around these libs is absolutely horrendous. That glue code keeps
> growing and getting uglier. Their level of clue is dropping.
>
> Right now, I'd pick Asterisk over FreeSWITCH.
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source ? ? ? ?--> http://ecdysis.viagenie.ca
> STUN/TURN server ? ? ? ? ? ? ? --> http://numb.viagenie.ca
>

Thanks Simon, I was about to say something.  Users that have a hard
time with Asterisk do not understand it.

-- 
~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~


From meirea at charterschoolit.com  Wed May 16 09:58:45 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Wed, 16 May 2012 14:58:45 +0000
Subject: mxlogic.net list admin
Message-ID: <C95B38A68C80744C8B371447DB6EE98CD525C4@CSIT-SRV-MBX-03.charterschoolit.local>

Hello,

 

If there is an mxlogic.net admin available, please contact me off list
regarding an IP block. I have tried traditional channels and they are not
getting me anywhere.

 

Thanks,

 

Mario Eirea

 

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

From me at anuragbhatia.com  Wed May 16 12:19:11 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 16 May 2012 22:49:11 +0530
Subject: ASN source when using "-A with traceroute"
Message-ID: <CAJ0+aXaArNvzn=MMgttUak-ixuBEw7XdBvpMca1yPpAHSBLyww@mail.gmail.com>

Hello everyone!


I have a funny case - one of our upstream provider announced our address
space for very short time which was well due to confusion since we
requested them to announce one of other blocks while they by mistake
announced both blocks.

Anyways, now funny thing here is - whenever I run a traceroute from any of
Linux server from any location, I see upsteam provider as well as our ASN
in output of traceroute -A.


This is not really a problem at all but I am just curious to know the
source of IP-ASN mapping in traceroute output. Also any ideas on update
frequency of that source?



Thanks!

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From ahebert at pubnix.net  Wed May 16 12:46:59 2012
From: ahebert at pubnix.net (Alain Hebert)
Date: Wed, 16 May 2012 13:46:59 -0400
Subject: ASN source when using "-A with traceroute"
In-Reply-To: <CAJ0+aXaArNvzn=MMgttUak-ixuBEw7XdBvpMca1yPpAHSBLyww@mail.gmail.com>
References: <CAJ0+aXaArNvzn=MMgttUak-ixuBEw7XdBvpMca1yPpAHSBLyww@mail.gmail.com>
Message-ID: <4FB3E813.3050301@pubnix.net>

     ( I coudln't resist )

http://traceroute.sourceforge.net/

#define DEF_RADB_SERVER     "whois.radb.net"
#define DEF_RADB_SERVICE    "whois"

const char *get_as_path (const char *query) {

         server = getenv ("RA_SERVER");
         if (!server)  server = DEF_RADB_SERVER;

         service = getenv ("RA_SERVICE");
         if (!service)  service = DEF_RADB_SERVICE;

         n = snprintf (buf, sizeof (buf), "%s\r\n", query);

     Yadi, yada...

     So unless radb croak... you'll be fine.

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443


On 05/16/12 13:19, Anurag Bhatia wrote:
> Hello everyone!
>
>
> I have a funny case - one of our upstream provider announced our address
> space for very short time which was well due to confusion since we
> requested them to announce one of other blocks while they by mistake
> announced both blocks.
>
> Anyways, now funny thing here is - whenever I run a traceroute from any of
> Linux server from any location, I see upsteam provider as well as our ASN
> in output of traceroute -A.
>
>
> This is not really a problem at all but I am just curious to know the
> source of IP-ASN mapping in traceroute output. Also any ideas on update
> frequency of that source?
>
>
>
> Thanks!
>


From jeroen at mompl.net  Wed May 16 16:55:43 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 16 May 2012 14:55:43 -0700
Subject: Cogent for ISP bandwidth
In-Reply-To: <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
Message-ID: <4FB4225F.8060902@mompl.net>

Ameen Pishdadi wrote:
> A Kia and Ferrari can both get me from point a to point b, but the Ferrari is capable of getting me there way quicker, and yes I'm going to pay a premium for it but if I'm going from NYC to San Fran I'd definitely feel safer in the Ferrari reliability wise and get there a hell of a lot quicker... 

That's a really flawed comparison, as often is the case when using car 
analogies (amongst others).

A kia is much safer to drive, more economical and it is much more 
reliable than a ferrari. The ferrari may get you there quicker, if you 
didn't kill yourself along the way, or you got pulled over or if the car 
didn't break down (or all of the above).

So for a better price you have more reliability, more safety and better 
fuel economy. The ferrari is just for added show off, of some imaginary 
potential you will never reach.

If you insist on lame analogies, then you can compare a ferrari with a 
network provider who over commits its bandwidth and is continually over 
utilised. There is a promise of great speed, but you won't ever get it 
unless you try at 3 AM at night when traffic is lowest.

Have fun :-)

-- 
Earthquake Magnitude: 4.8
Date: Wednesday, May 16, 2012 15:02:51 UTC
Location: Southern Alaska
Latitude: 61.1008; Longitude: -149.8818
Depth: 45.30 km


From randy at psg.com  Wed May 16 17:55:47 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 16 May 2012 12:55:47 -1000
Subject: pbx recco
In-Reply-To: <CA+qj4S-3SpKN28tGJ1CNtuNDCmnmEZC8mKwrP970NTbG2k6UKQ@mail.gmail.com>
References: <m2vcjxwfa5.wl%randy@psg.com> <4FB2E035.9030104@ninjabadger.net>
 <4FB39FED.8000604@viagenie.ca>
 <CA+qj4S-3SpKN28tGJ1CNtuNDCmnmEZC8mKwrP970NTbG2k6UKQ@mail.gmail.com>
Message-ID: <m2396zburw.wl%randy@psg.com>

> Users that have a hard time with Asterisk do not understand it.

been running it since pre 1.  have large complex configs with confs,
follow-me (my original need), extensions and sip/iax peering with
strange things all over the developing world.

i still think config sucks.  and changing syntax regulary may look like
improvement to those with the copious spare time to track it.  but for
someone trying to run a stable install yet get the security patch of the
week, it sucks bigtime.

randy


From randy at psg.com  Wed May 16 18:50:55 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 16 May 2012 13:50:55 -1000
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
Message-ID: <m2txzfadnk.wl%randy@psg.com>

> As the global RPKI data set and system load grows, we want to ensure
> that the system is performing well. This is why we have added
> measurement functionality to the RIPE NCC RPKI Validator toolset:
> https://www.ripe.net/certification/rpki-validator-metrics
> 
> When enabled, it will gather the following data and send it to the
> RIPE NCC for analysis:

good stuff.  though you know how much i like centralization :)

of course you have seen the centralized rpki.net measurements presented
by rob at iepg 
   http://iepg.org/2012-03-ietf83/a-few-months-in-the-life-of-an-rpki-validator.pdf
and the measurements of an experiment using bit torrent instead of rsync
   http://iepg.org/2012-03-ietf83/rpki-bittorrent-experiment.pdf
and sidr/paris.  oops, good luck finding it, and he was cut short anyway
due to the meeting's tech fiasco.

but that is centralized.  and, if you would care to publish your
collection protocol, we would look at having the rpki.net relying party
software shove data down it.  but no promises.

but we're more focused on giving the *user* the tools to measure and
see.  so you may want to look at the tables and graphs (graphs more
germane to this discussion) from the rpki.net relying party software at,
for example,
   http://www.hactrn.net/opaque/rcynic/index.html

suggestions for improvement solicited, of course.

randy
   


From randy at psg.com  Wed May 16 18:55:23 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 16 May 2012 13:55:23 -1000
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <m2txzfadnk.wl%randy@psg.com>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
 <m2txzfadnk.wl%randy@psg.com>
Message-ID: <m2r4ujadg4.wl%randy@psg.com>

> but we're more focused on giving the *user* the tools to measure and
> see.  so you may want to look at the tables and graphs (graphs more
> germane to this discussion) from the rpki.net relying party software at,
> for example,
>    http://www.hactrn.net/opaque/rcynic/index.html

oh, and the docco for install and config of the relying party software
is at 
   https://trac.rpki.net/wiki/doc/RPKI/RP

randy


From paul at paulstewart.org  Wed May 16 20:37:56 2012
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 16 May 2012 21:37:56 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
 <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
Message-ID: <318001cd33cd$b0fa5340$12eef9c0$@paulstewart.org>

I liked Cogent when we had them years ago but due to routing instability
(off the charts) and unplanned down time every single month we dropped
them..... they call me every 3-6 months (different person each time) and I
tell them to go away....

Paul


-----Original Message-----
From: Tim Vollebregt [mailto:tim at interworx.nl] 
Sent: Tuesday, May 15, 2012 2:33 PM
To: nanog list
Subject: Re: Cogent for ISP bandwidth

+1 for Cogent in the mix :)

People with a clue in their NOC, near zero routing issues in last 1,5 years.

On May 15, 2012, at 6:36 PM, Anurag Bhatia wrote:

> The only issue I saw with bgp.he.net is that it updates after 24hrs 
> which makes it hard to use for any recently made changes. But for rest 
> works pretty good.
> 
> On Tue, May 15, 2012 at 9:02 PM, Ren Provo <ren.provo at gmail.com> wrote:
> 
>> Keep in mind http://bgp.he.net is not always accurate.  It is a great 
>> start but even after years of pointing it out there are adjacencies 
>> missing and oddly some listed as direct where no relationship even 
>> exists.
>> 
>> On Tue, May 15, 2012 at 9:39 AM, Jason Baugher 
>> <jason at thebaughers.com>
>> wrote:
>>> I appreciate the reference to bgp.he.net, I had not used that tool
>> before.
>> 
>> 
> 
> 
> --
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected 
> network!
> 
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> | 
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>





From djahandarie at gmail.com  Wed May 16 20:45:46 2012
From: djahandarie at gmail.com (Darius Jahandarie)
Date: Wed, 16 May 2012 21:45:46 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <318001cd33cd$b0fa5340$12eef9c0$@paulstewart.org>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
 <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
 <318001cd33cd$b0fa5340$12eef9c0$@paulstewart.org>
Message-ID: <CAFANWtWqcFWZxgVNiaOHZ0VPqGQqv0Dd7qUCU95wwMfdtQGj1g@mail.gmail.com>

On Wed, May 16, 2012 at 9:37 PM, Paul Stewart <paul at paulstewart.org> wrote:
> I liked Cogent when we had them years ago but due to routing instability
> (off the charts) and unplanned down time every single month we dropped
> them..... they call me every 3-6 months (different person each time) and I
> tell them to go away....

You know, if you're in the U.S., on the No Call list, and you tell
them specifically not to call you again, they're doing something
illegal and can be fined up to $16,000 dollars for it. Though I hear
that the FTC doesn't actually enforce it too well. May want to try
waving the stick at them at least.

-- 
Darius Jahandarie


From morrowc.lists at gmail.com  Wed May 16 21:18:26 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 16 May 2012 22:18:26 -0400
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <m2txzfadnk.wl%randy@psg.com>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
 <m2txzfadnk.wl%randy@psg.com>
Message-ID: <CAL9jLabcsOjSyV-mid409WKLEnU4K1hsRqU69S6Jz=ePcg=GwQ@mail.gmail.com>

On Wed, May 16, 2012 at 7:50 PM, Randy Bush <randy at psg.com> wrote:
> germane to this discussion) from the rpki.net relying party software at,
> for example,
> ? http://www.hactrn.net/opaque/rcynic/index.html
>
> suggestions for improvement solicited, of course.

the text talks about rpki.net
the link is for 'not rpki.net'

how does this work? <insert clownposse here>

rpki.net redirects to https://trac.rpki.net and poops out an ssl error :(
security is 'hard'...

Could someone make:
  1) rpki.net function as http redirecting to https with the right
cert (or put a SAN in the current cert?)
  2) put the graphs at 'not rpki.net' on rpki.net (too)
  3) indicate whether or not the graphs are of ongoing data or past-tense?

-chris


From randy at psg.com  Wed May 16 22:47:11 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 16 May 2012 17:47:11 -1000
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <CAL9jLabcsOjSyV-mid409WKLEnU4K1hsRqU69S6Jz=ePcg=GwQ@mail.gmail.com>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
 <m2txzfadnk.wl%randy@psg.com>
 <CAL9jLabcsOjSyV-mid409WKLEnU4K1hsRqU69S6Jz=ePcg=GwQ@mail.gmail.com>
Message-ID: <m2k40ba2ps.wl%randy@psg.com>

> Could someone make:
>   2) put the graphs at 'not rpki.net' on rpki.net (too)

no.  that is the exact point.  the graph to which i pointed is on rob's
site.  these are data each relying party can collect and see for
themselves and their point of view in the universe, not some central
authority.  ripe/ncc thinks it is the center of the universe.  we do
not.  we know it is in freemont [0], a neighborhood of seattle.

so that url is very intentionally rob's relying party instance.  i have
one at 
   http://rgnet.rpki.net/
but it has not been running as long as you can see.

and sorry that our certs did not pay godzilla or gobble for the
privilege of being in their bowsers.  refund below [1]

randy

[0] - http://en.wikipedia.org/wiki/Fremont,_Seattle
      http://www.stonerforums.com/lounge/members/guiness-albums-stuff-picture19971-center-known-universe-freemont.jpg
      http://www.waymarking.com/gallery/image.aspx?f=1&guid=e712e7f5-0a55-4cc0-a40c-88deedce8d72&gid=3


From paul4004 at gmail.com  Wed May 16 23:46:58 2012
From: paul4004 at gmail.com (PC)
Date: Wed, 16 May 2012 22:46:58 -0600
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAFANWtWqcFWZxgVNiaOHZ0VPqGQqv0Dd7qUCU95wwMfdtQGj1g@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
 <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
 <318001cd33cd$b0fa5340$12eef9c0$@paulstewart.org>
 <CAFANWtWqcFWZxgVNiaOHZ0VPqGQqv0Dd7qUCU95wwMfdtQGj1g@mail.gmail.com>
Message-ID: <CAJAdsDna02og7nnnMqE0bPjaa3N0UvY=Mh2Yf_TgaKVNHG=sgw@mail.gmail.com>

While there may be other grounds for telling them not to call you, the
do not call list is not one of them as it does not apply to business
to business solicitations.

"The national Do-Not-Call list protects home voice or personal
wireless phone numbers only. While you may be able to register a
business number, your registration will not make telephone
solicitations to that number unlawful."
http://www.fcc.gov/guides/unwanted-telephone-marketing-calls


On Wed, May 16, 2012 at 7:45 PM, Darius Jahandarie
<djahandarie at gmail.com> wrote:
>
> On Wed, May 16, 2012 at 9:37 PM, Paul Stewart <paul at paulstewart.org> wrote:
> > I liked Cogent when we had them years ago but due to routing instability
> > (off the charts) and unplanned down time every single month we dropped
> > them..... they call me every 3-6 months (different person each time) and I
> > tell them to go away....
>
> You know, if you're in the U.S., on the No Call list, and you tell
> them specifically not to call you again, they're doing something
> illegal and can be fined up to $16,000 dollars for it. Though I hear
> that the FTC doesn't actually enforce it too well. May want to try
> waving the stick at them at least.
>
> --
> Darius Jahandarie
>


From morrowc.lists at gmail.com  Thu May 17 00:58:50 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 17 May 2012 01:58:50 -0400
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <m2k40ba2ps.wl%randy@psg.com>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
 <m2txzfadnk.wl%randy@psg.com>
 <CAL9jLabcsOjSyV-mid409WKLEnU4K1hsRqU69S6Jz=ePcg=GwQ@mail.gmail.com>
 <m2k40ba2ps.wl%randy@psg.com>
Message-ID: <CAL9jLabHAMbncrqq9Uj9HcGNUiciPFDACa2rUdYnrYdWscJU6g@mail.gmail.com>

On Wed, May 16, 2012 at 11:47 PM, Randy Bush <randy at psg.com> wrote:
> and sorry that our certs did not pay godzilla or gobble for the
> privilege of being in their bowsers. ?refund below [1]

there was no [1]...

startssl.com - free certs. (that work)


From marshall.eubanks at gmail.com  Thu May 17 07:55:02 2012
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Thu, 17 May 2012 08:55:02 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAJAdsDna02og7nnnMqE0bPjaa3N0UvY=Mh2Yf_TgaKVNHG=sgw@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
 <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
 <318001cd33cd$b0fa5340$12eef9c0$@paulstewart.org>
 <CAFANWtWqcFWZxgVNiaOHZ0VPqGQqv0Dd7qUCU95wwMfdtQGj1g@mail.gmail.com>
 <CAJAdsDna02og7nnnMqE0bPjaa3N0UvY=Mh2Yf_TgaKVNHG=sgw@mail.gmail.com>
Message-ID: <CAJNg7VLre5fLRkHiJkhLgA++ce0VvFzTHjdQ9YU5khHnUocbEw@mail.gmail.com>

On Thu, May 17, 2012 at 12:46 AM, PC <paul4004 at gmail.com> wrote:
> While there may be other grounds for telling them not to call you, the
> do not call list is not one of them as it does not apply to business
> to business solicitations.
>
> "The national Do-Not-Call list protects home voice or personal
> wireless phone numbers only. While you may be able to register a
> business number, your registration will not make telephone
> solicitations to that number unlawful."
> http://www.fcc.gov/guides/unwanted-telephone-marketing-calls
>

Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list )

The Do-Not-Call registry does not prevent all unwanted calls. It does
not cover the following:

     calls from organizations with which you have established a
business relationship;

And, in this case, there is a previously established  business relationship.

Regards
Marshall

>
> On Wed, May 16, 2012 at 7:45 PM, Darius Jahandarie
> <djahandarie at gmail.com> wrote:
>>
>> On Wed, May 16, 2012 at 9:37 PM, Paul Stewart <paul at paulstewart.org> wrote:
>> > I liked Cogent when we had them years ago but due to routing instability
>> > (off the charts) and unplanned down time every single month we dropped
>> > them..... they call me every 3-6 months (different person each time) and I
>> > tell them to go away....
>>
>> You know, if you're in the U.S., on the No Call list, and you tell
>> them specifically not to call you again, they're doing something
>> illegal and can be fined up to $16,000 dollars for it. Though I hear
>> that the FTC doesn't actually enforce it too well. May want to try
>> waving the stick at them at least.
>>
>> --
>> Darius Jahandarie
>>
>


From djahandarie at gmail.com  Thu May 17 08:04:59 2012
From: djahandarie at gmail.com (Darius Jahandarie)
Date: Thu, 17 May 2012 09:04:59 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAJNg7VLre5fLRkHiJkhLgA++ce0VvFzTHjdQ9YU5khHnUocbEw@mail.gmail.com>
References: <4FB1813C.7080207@thebaughers.com>
 <98617538-EA41-4BA5-821D-7EAE7D6BF892@gmail.com>
 <4FB1D243.6000405@snappydsl.net>
 <93C90805-8BD7-4CC2-9326-E5BC5774A05F@gmail.com>
 <4FB25368.9020506@snappydsl.net> <4FB25C9E.60607@thebaughers.com>
 <CAG5ReHcDMouwFVue_GkFWzAyO+WU_tCyy4uf=pP3ce=CvvfTRg@mail.gmail.com>
 <CAJ0+aXaUDYM4xUW1wRHKLGGW4CfmZyvJbbQT4jVeabVecvhPVg@mail.gmail.com>
 <0AB7B4E0-7138-41FC-A4A5-3481D88E123A@interworx.nl>
 <318001cd33cd$b0fa5340$12eef9c0$@paulstewart.org>
 <CAFANWtWqcFWZxgVNiaOHZ0VPqGQqv0Dd7qUCU95wwMfdtQGj1g@mail.gmail.com>
 <CAJAdsDna02og7nnnMqE0bPjaa3N0UvY=Mh2Yf_TgaKVNHG=sgw@mail.gmail.com>
 <CAJNg7VLre5fLRkHiJkhLgA++ce0VvFzTHjdQ9YU5khHnUocbEw@mail.gmail.com>
Message-ID: <CAFANWtUdR1veBxFWZd9r19ijAULO1YaLfodObjZDkg-XB4DsQw@mail.gmail.com>

On Thu, May 17, 2012 at 8:55 AM, Marshall Eubanks
<marshall.eubanks at gmail.com> wrote:
> On Thu, May 17, 2012 at 12:46 AM, PC <paul4004 at gmail.com> wrote:
>> While there may be other grounds for telling them not to call you, the
>> do not call list is not one of them as it does not apply to business
>> to business solicitations.
>>
>> "The national Do-Not-Call list protects home voice or personal
>> wireless phone numbers only. While you may be able to register a
>> business number, your registration will not make telephone
>> solicitations to that number unlawful."
>> http://www.fcc.gov/guides/unwanted-telephone-marketing-calls
>>
>
> Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list )
>
> The Do-Not-Call registry does not prevent all unwanted calls. It does
> not cover the following:
>
> ? ? calls from organizations with which you have established a
> business relationship;
>
> And, in this case, there is a previously established ?business relationship.

"Because of limitations in the jurisdiction of the FTC and FCC, calls
from or on behalf of political organizations, charities, and telephone
surveyors would still be permitted, as would calls from companies with
which you have an existing business relationship, or those to whom
you?ve provided express agreement in writing to receive their calls.
However, if you ask a company with which you have an existing business
relationship to place your number on its own do-not-call list, it must
honor your request." [1]

Which seems to suggest to me, if you tell them to not call you again,
they need to stop.

However, I was not aware of the complications of using a business
number instead of a personal number.

[1] http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt107.shtm

-- 
Darius Jahandarie


From bonomi at mail.r-bonomi.com  Thu May 17 10:10:05 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 17 May 2012 10:10:05 -0500 (CDT)
Subject: Cogent for ISP bandwidth
In-Reply-To: <CAJNg7VLre5fLRkHiJkhLgA++ce0VvFzTHjdQ9YU5khHnUocbEw@mail.gmail.com>
Message-ID: <201205171510.q4HFA5nh022835@mail.r-bonomi.com>


Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
>
> On Thu, May 17, 2012 at 12:46 AM, PC <paul4004 at gmail.com> wrote:
> > While there may be other grounds for telling them not to call you, the
> > do not call list is not one of them as it does not apply to business
> > to business solicitations.
> >
> > "The national Do-Not-Call list protects home voice or personal
> > wireless phone numbers only. While you may be able to register a
> > business number, your registration will not make telephone
> > solicitations to that number unlawful."
> > http://www.fcc.gov/guides/unwanted-telephone-marketing-calls
> >
>
> Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list )
>
> The Do-Not-Call registry does not prevent all unwanted calls. It does
> not cover the following:
>
>      calls from organizations with which you have established a
> business relationship;
>
> And, in this case, there is a previously established  business relationship.

a) The "previously established business relationship" exemption expires 6 
   months after the 'business relationship' ends. (This is in the 'fine 
   print' of the actual rules0  As the relationship in question ended 
   several years ago, according to the prior poster, this exemption would 
   not apply.

b) Nothing in the Do-not-call rules applies to calls to business numbers.
   Callers to business numbers are not even required to respect a 'put me 
   on your "do-not-call" list', or 'do not call me again' request under
   the DNC rules.




From djahandarie at gmail.com  Thu May 17 10:13:02 2012
From: djahandarie at gmail.com (Darius Jahandarie)
Date: Thu, 17 May 2012 11:13:02 -0400
Subject: Cogent for ISP bandwidth
In-Reply-To: <201205171510.q4HFA5nh022835@mail.r-bonomi.com>
References: <CAJNg7VLre5fLRkHiJkhLgA++ce0VvFzTHjdQ9YU5khHnUocbEw@mail.gmail.com>
 <201205171510.q4HFA5nh022835@mail.r-bonomi.com>
Message-ID: <CAFANWtUrROGJZF0fFAZhs8QOnZQ2W4H7DqWDCwA+pUMnqCi1KQ@mail.gmail.com>

On Thu, May 17, 2012 at 11:10 AM, Robert Bonomi
<bonomi at mail.r-bonomi.com> wrote:
>
> Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
>>
>> On Thu, May 17, 2012 at 12:46 AM, PC <paul4004 at gmail.com> wrote:
>> > While there may be other grounds for telling them not to call you, the
>> > do not call list is not one of them as it does not apply to business
>> > to business solicitations.
>> >
>> > "The national Do-Not-Call list protects home voice or personal
>> > wireless phone numbers only. While you may be able to register a
>> > business number, your registration will not make telephone
>> > solicitations to that number unlawful."
>> > http://www.fcc.gov/guides/unwanted-telephone-marketing-calls
>> >
>>
>> Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list )
>>
>> The Do-Not-Call registry does not prevent all unwanted calls. It does
>> not cover the following:
>>
>> ? ? ?calls from organizations with which you have established a
>> business relationship;
>>
>> And, in this case, there is a previously established ?business relationship.
>
> a) The "previously established business relationship" exemption expires 6
> ? months after the 'business relationship' ends. (This is in the 'fine
> ? print' of the actual rules0 ?As the relationship in question ended
> ? several years ago, according to the prior poster, this exemption would
> ? not apply.
>
> b) Nothing in the Do-not-call rules applies to calls to business numbers.
> ? Callers to business numbers are not even required to respect a 'put me
> ? on your "do-not-call" list', or 'do not call me again' request under
> ? the DNC rules.

So the moral of the story is to make sure you always make your Cogent
calls from your home phone? :-)

-- 
Darius Jahandarie


From aservin at lacnic.net  Thu May 17 13:31:42 2012
From: aservin at lacnic.net (Arturo Servin)
Date: Thu, 17 May 2012 15:31:42 -0300
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <m2k40ba2ps.wl%randy@psg.com>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
 <m2txzfadnk.wl%randy@psg.com>
 <CAL9jLabcsOjSyV-mid409WKLEnU4K1hsRqU69S6Jz=ePcg=GwQ@mail.gmail.com>
 <m2k40ba2ps.wl%randy@psg.com>
Message-ID: <6A7FAA28-8EB7-4058-A2B2-2C35E8A5D39F@lacnic.net>


On 17 May 2012, at 00:47, Randy Bush wrote:

>> Could someone make:
>>  2) put the graphs at 'not rpki.net' on rpki.net (too)
> 
> no.  that is the exact point.  the graph to which i pointed is on rob's
> site.  these are data each relying party can collect and see for
> themselves and their point of view in the universe,

	Which I think it is a very valuable thing as a RP operator. I haven't used the lastest versions of RIPE NCC validator for myself but that would be a nice feature to have there as well. I will update my rcynic installation, I liked the graphs.

> not some central
> authority.
>  ripe/ncc thinks it is the center of the universe.  we do
> not.  we know it is in freemont [0], a neighborhood of seattle.

	I do not think that is the intention from RIPE NCC.

	The intention as I understood is to get the data that each RP is getting and to send it to central repository for further analysis. Which it is a centralized approach but for simplicity, not for thinking that they are the center of the universe.

	In my view there are 2 problems. One is to see as an RP operator how healthy are the repositories where you retrieve data (which for the url that you sent is done very nicely with rcynic), and two it is that as repository operator and protocol designers you'd like to see how good or bad your repository/protocols are doing to provide data to RPs in different locations of the world (which I think it is the aim of RIPE NCC effort).


> 
> so that url is very intentionally rob's relying party instance.  i have
> one at 
>   http://rgnet.rpki.net/
> but it has not been running as long as you can see.
> 
> and sorry that our certs did not pay godzilla or gobble for the
> privilege of being in their bowsers.  refund below [1]
> 
> randy
> 
> [0] - http://en.wikipedia.org/wiki/Fremont,_Seattle
>      http://www.stonerforums.com/lounge/members/guiness-albums-stuff-picture19971-center-known-universe-freemont.jpg
>      http://www.waymarking.com/gallery/image.aspx?f=1&guid=e712e7f5-0a55-4cc0-a40c-88deedce8d72&gid=3


	If anybody else is willing to share its data and URLs about their RP performance, I would be nice. I have an old rsync installation that I will try to update this weekend. Now it is here but does not show too much:

http://www.labs.lacnic.net/~rpki/rpki-monitor/rpki-ta-status.xml


Regards,
as




From carlosm3011 at gmail.com  Thu May 17 14:04:59 2012
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Thu, 17 May 2012 16:04:59 -0300
Subject: [routing-wg] RPKI performance metrics; your help requested
In-Reply-To: <6A7FAA28-8EB7-4058-A2B2-2C35E8A5D39F@lacnic.net>
References: <C9BF7FC6-2BFC-4B71-9C98-BF874939DB26@ripe.net>
 <m2txzfadnk.wl%randy@psg.com>
 <CAL9jLabcsOjSyV-mid409WKLEnU4K1hsRqU69S6Jz=ePcg=GwQ@mail.gmail.com>
 <m2k40ba2ps.wl%randy@psg.com>
 <6A7FAA28-8EB7-4058-A2B2-2C35E8A5D39F@lacnic.net>
Message-ID: <4FB54BDB.1040500@gmail.com>

Kudos to the RIPE NCC for graciously offering to collect and analyze
repository performance data. And I'm sure that if we ask nicely they
will provide data dumps we can analyze ourselves, just like they do with
RIS and other projects.

Cheers!

Carlos

On 5/17/12 3:31 PM, Arturo Servin wrote:
> On 17 May 2012, at 00:47, Randy Bush wrote:
>
>>> Could someone make:
>>>  2) put the graphs at 'not rpki.net' on rpki.net (too)
>> no.  that is the exact point.  the graph to which i pointed is on rob's
>> site.  these are data each relying party can collect and see for
>> themselves and their point of view in the universe,
> 	Which I think it is a very valuable thing as a RP operator. I haven't used the lastest versions of RIPE NCC validator for myself but that would be a nice feature to have there as well. I will update my rcynic installation, I liked the graphs.
>
>> not some central
>> authority.
>>  ripe/ncc thinks it is the center of the universe.  we do
>> not.  we know it is in freemont [0], a neighborhood of seattle.
> 	I do not think that is the intention from RIPE NCC.
>
> 	The intention as I understood is to get the data that each RP is getting and to send it to central repository for further analysis. Which it is a centralized approach but for simplicity, not for thinking that they are the center of the universe.
>
> 	In my view there are 2 problems. One is to see as an RP operator how healthy are the repositories where you retrieve data (which for the url that you sent is done very nicely with rcynic), and two it is that as repository operator and protocol designers you'd like to see how good or bad your repository/protocols are doing to provide data to RPs in different locations of the world (which I think it is the aim of RIPE NCC effort).
>
>
>> so that url is very intentionally rob's relying party instance.  i have
>> one at 
>>   http://rgnet.rpki.net/
>> but it has not been running as long as you can see.
>>
>> and sorry that our certs did not pay godzilla or gobble for the
>> privilege of being in their bowsers.  refund below [1]
>>
>> randy
>>
>> [0] - http://en.wikipedia.org/wiki/Fremont,_Seattle
>>      http://www.stonerforums.com/lounge/members/guiness-albums-stuff-picture19971-center-known-universe-freemont.jpg
>>      http://www.waymarking.com/gallery/image.aspx?f=1&guid=e712e7f5-0a55-4cc0-a40c-88deedce8d72&gid=3
>
> 	If anybody else is willing to share its data and URLs about their RP performance, I would be nice. I have an old rsync installation that I will try to update this weekend. Now it is here but does not show too much:
>
> http://www.labs.lacnic.net/~rpki/rpki-monitor/rpki-ta-status.xml
>
>
> Regards,
> as
>
>
>


From paul at paulstewart.org  Thu May 17 17:53:22 2012
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 17 May 2012 18:53:22 -0400
Subject: Commerical Backup Solutions
Message-ID: <339801cd347f$de562190$9b0264b0$@paulstewart.org>

Hey folks.

 

I'm hoping for some input from operational folks on backup solutions for
servers.  We are looking for a commercial backup solution with a nice
reporting dashboard etc.

 

It must support full/incremental backups on Windows and various flavors of
Linux.  We would also be looking for bare metal image/recovery abilities.

 

To date, we've been fond of Acronis until we got the quote for it ..
Initially we would be looking at 50-80 servers and growing it up from there
to probably 150-200 boxes.  Some of these servers are geographically
dispersed.

 

At the moment we have been using Bacula but it lacks bare metal options and
doesn't have any nice reporting options (Executive Dashboard etc)

 

Thanks for any input,

 

Paul

 

 

 


From mike.lyon at gmail.com  Thu May 17 17:59:02 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Thu, 17 May 2012 15:59:02 -0700
Subject: Commerical Backup Solutions
In-Reply-To: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
Message-ID: <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>

We used Acronis and it was a nightmare as was their off-shored support
model. Never again... Wouldn't touch them with a 10 foot pole.

Switched to Iron Mountain LiveVault which backs everything up over the
wire. It has basic reporting functions but not extremely granular.
http://ironmountain.com/services/democenter/livevault/player.html

Barracuda also seems to have a nice product. Though, i've never used it:
http://www.barracudanetworks.com/ns/products/backup_overview.php

-Mike

On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org> wrote:

> Hey folks.
>
>
>
> I'm hoping for some input from operational folks on backup solutions for
> servers.  We are looking for a commercial backup solution with a nice
> reporting dashboard etc.
>
>
>
> It must support full/incremental backups on Windows and various flavors of
> Linux.  We would also be looking for bare metal image/recovery abilities.
>
>
>
> To date, we've been fond of Acronis until we got the quote for it ..
> Initially we would be looking at 50-80 servers and growing it up from there
> to probably 150-200 boxes.  Some of these servers are geographically
> dispersed.
>
>
>
> At the moment we have been using Bacula but it lacks bare metal options and
> doesn't have any nice reporting options (Executive Dashboard etc)
>
>
>
> Thanks for any input,
>
>
>
> Paul
>
>
>
>
>
>
>
>


-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon

From DHyde at hosting.com  Thu May 17 18:04:29 2012
From: DHyde at hosting.com (Darrell Hyde)
Date: Thu, 17 May 2012 19:04:29 -0400
Subject: Commerical Backup Solutions
In-Reply-To: <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
Message-ID: <8CA9478D-7834-416A-986E-D8D734AE9A92@hosting.com>

Recently finished developing a product around Commvault Simpana. Fairly happy with their API and reporting capabilities. Application specific plugins (MySQL, mssql, exchange, etc) are pretty solid so far as well. 

On May 17, 2012, at 4:59 PM, "Mike Lyon" <mike.lyon at gmail.com> wrote:

> We used Acronis and it was a nightmare as was their off-shored support
> model. Never again... Wouldn't touch them with a 10 foot pole.
> 
> Switched to Iron Mountain LiveVault which backs everything up over the
> wire. It has basic reporting functions but not extremely granular.
> http://ironmountain.com/services/democenter/livevault/player.html
> 
> Barracuda also seems to have a nice product. Though, i've never used it:
> http://www.barracudanetworks.com/ns/products/backup_overview.php
> 
> -Mike
> 
> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org> wrote:
> 
>> Hey folks.
>> 
>> 
>> 
>> I'm hoping for some input from operational folks on backup solutions for
>> servers.  We are looking for a commercial backup solution with a nice
>> reporting dashboard etc.
>> 
>> 
>> 
>> It must support full/incremental backups on Windows and various flavors of
>> Linux.  We would also be looking for bare metal image/recovery abilities.
>> 
>> 
>> 
>> To date, we've been fond of Acronis until we got the quote for it ..
>> Initially we would be looking at 50-80 servers and growing it up from there
>> to probably 150-200 boxes.  Some of these servers are geographically
>> dispersed.
>> 
>> 
>> 
>> At the moment we have been using Bacula but it lacks bare metal options and
>> doesn't have any nice reporting options (Executive Dashboard etc)
>> 
>> 
>> 
>> Thanks for any input,
>> 
>> 
>> 
>> Paul
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
> 
> http://www.linkedin.com/in/mlyon


From gary.buckmaster at digitalpacific.com.au  Thu May 17 18:05:47 2012
From: gary.buckmaster at digitalpacific.com.au (Gary Buckmaster)
Date: Fri, 18 May 2012 09:05:47 +1000
Subject: Commerical Backup Solutions
In-Reply-To: <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
Message-ID: <4FB5844B.4040009@digitalpacific.com.au>

We were considering Acronis for backing up our internal infrastructure,
we use R1Soft for our customers.

What were the issues with Acronis?  I'd be interested in getting some
real-world feedback.  You can hit me off list if you like.

-Gary

On 5/18/2012 8:59 AM, Mike Lyon wrote:
> We used Acronis and it was a nightmare as was their off-shored support
> model. Never again... Wouldn't touch them with a 10 foot pole.
> 
> Switched to Iron Mountain LiveVault which backs everything up over the
> wire. It has basic reporting functions but not extremely granular.
> http://ironmountain.com/services/democenter/livevault/player.html
> 
> Barracuda also seems to have a nice product. Though, i've never used it:
> http://www.barracudanetworks.com/ns/products/backup_overview.php
> 
> -Mike
> 
> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org> wrote:
> 
>> Hey folks.
>>
>>
>>
>> I'm hoping for some input from operational folks on backup solutions for
>> servers.  We are looking for a commercial backup solution with a nice
>> reporting dashboard etc.
>>
>>
>>
>> It must support full/incremental backups on Windows and various flavors of
>> Linux.  We would also be looking for bare metal image/recovery abilities.
>>
>>
>>
>> To date, we've been fond of Acronis until we got the quote for it ..
>> Initially we would be looking at 50-80 servers and growing it up from there
>> to probably 150-200 boxes.  Some of these servers are geographically
>> dispersed.
>>
>>
>>
>> At the moment we have been using Bacula but it lacks bare metal options and
>> doesn't have any nice reporting options (Executive Dashboard etc)
>>
>>
>>
>> Thanks for any input,
>>
>>
>>
>> Paul
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 


From straterra at fuhell.com  Thu May 17 18:08:21 2012
From: straterra at fuhell.com (Thomas York)
Date: Thu, 17 May 2012 19:08:21 -0400
Subject: Commerical Backup Solutions
In-Reply-To: <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
Message-ID: <CAFJhVwgM9x2fCV0z2m6aNQKcz8jVpPpDPRn7br_JQ8nwdv1+Dw@mail.gmail.com>

We use Barracuda Yosemite backup with about 10 locations all over the
world, using disk to disk (single disks via esata and to SANs) and disk to
tape (both libraries and single drives). Very rarely do we have issues.
Barracuda support isn't as good as Yosemite's (Barracuda bought them) but
still not bad. Also, the site wide license is a steal! Get a demo, it might
fit the bill.

--Thomas York
On May 17, 2012 6:59 PM, "Mike Lyon" <mike.lyon at gmail.com> wrote:

> We used Acronis and it was a nightmare as was their off-shored support
> model. Never again... Wouldn't touch them with a 10 foot pole.
>
> Switched to Iron Mountain LiveVault which backs everything up over the
> wire. It has basic reporting functions but not extremely granular.
> http://ironmountain.com/services/democenter/livevault/player.html
>
> Barracuda also seems to have a nice product. Though, i've never used it:
> http://www.barracudanetworks.com/ns/products/backup_overview.php
>
> -Mike
>
> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org>
> wrote:
>
> > Hey folks.
> >
> >
> >
> > I'm hoping for some input from operational folks on backup solutions for
> > servers.  We are looking for a commercial backup solution with a nice
> > reporting dashboard etc.
> >
> >
> >
> > It must support full/incremental backups on Windows and various flavors
> of
> > Linux.  We would also be looking for bare metal image/recovery abilities.
> >
> >
> >
> > To date, we've been fond of Acronis until we got the quote for it ..
> > Initially we would be looking at 50-80 servers and growing it up from
> there
> > to probably 150-200 boxes.  Some of these servers are geographically
> > dispersed.
> >
> >
> >
> > At the moment we have been using Bacula but it lacks bare metal options
> and
> > doesn't have any nice reporting options (Executive Dashboard etc)
> >
> >
> >
> > Thanks for any input,
> >
> >
> >
> > Paul
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
>
> http://www.linkedin.com/in/mlyon
>

From joshbaird at gmail.com  Thu May 17 19:01:20 2012
From: joshbaird at gmail.com (Josh Baird)
Date: Thu, 17 May 2012 20:01:20 -0400
Subject: Commerical Backup Solutions
In-Reply-To: <CAFJhVwgM9x2fCV0z2m6aNQKcz8jVpPpDPRn7br_JQ8nwdv1+Dw@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
 <CAFJhVwgM9x2fCV0z2m6aNQKcz8jVpPpDPRn7br_JQ8nwdv1+Dw@mail.gmail.com>
Message-ID: <CABmW_PdpXTxvfL9VkqO9OrC867F53pKwLM8CXmo+ZowZpQj_LA@mail.gmail.com>

We have used Symantec's BackupExec (Veritas) in several locations but
have standardized on IBM's Tivoli Storage Manager (TSM).  Not a fan of
IBM, but it works, and it works well.  Be prepared to drop some
serious coin, though.  We currently use it to do tape backups for over
800+ servers (Linux, AIX, Windows).

Josh

On Thu, May 17, 2012 at 7:08 PM, Thomas York <straterra at fuhell.com> wrote:
> We use Barracuda Yosemite backup with about 10 locations all over the
> world, using disk to disk (single disks via esata and to SANs) and disk to
> tape (both libraries and single drives). Very rarely do we have issues.
> Barracuda support isn't as good as Yosemite's (Barracuda bought them) but
> still not bad. Also, the site wide license is a steal! Get a demo, it might
> fit the bill.
>
> --Thomas York
> On May 17, 2012 6:59 PM, "Mike Lyon" <mike.lyon at gmail.com> wrote:
>
>> We used Acronis and it was a nightmare as was their off-shored support
>> model. Never again... Wouldn't touch them with a 10 foot pole.
>>
>> Switched to Iron Mountain LiveVault which backs everything up over the
>> wire. It has basic reporting functions but not extremely granular.
>> http://ironmountain.com/services/democenter/livevault/player.html
>>
>> Barracuda also seems to have a nice product. Though, i've never used it:
>> http://www.barracudanetworks.com/ns/products/backup_overview.php
>>
>> -Mike
>>
>> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org>
>> wrote:
>>
>> > Hey folks.
>> >
>> >
>> >
>> > I'm hoping for some input from operational folks on backup solutions for
>> > servers. ?We are looking for a commercial backup solution with a nice
>> > reporting dashboard etc.
>> >
>> >
>> >
>> > It must support full/incremental backups on Windows and various flavors
>> of
>> > Linux. ?We would also be looking for bare metal image/recovery abilities.
>> >
>> >
>> >
>> > To date, we've been fond of Acronis until we got the quote for it ..
>> > Initially we would be looking at 50-80 servers and growing it up from
>> there
>> > to probably 150-200 boxes. ?Some of these servers are geographically
>> > dispersed.
>> >
>> >
>> >
>> > At the moment we have been using Bacula but it lacks bare metal options
>> and
>> > doesn't have any nice reporting options (Executive Dashboard etc)
>> >
>> >
>> >
>> > Thanks for any input,
>> >
>> >
>> >
>> > Paul
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Mike Lyon
>> 408-621-4826
>> mike.lyon at gmail.com
>>
>> http://www.linkedin.com/in/mlyon
>>


From marka at isc.org  Thu May 17 19:01:47 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 18 May 2012 10:01:47 +1000
Subject: Cogent for ISP bandwidth
In-Reply-To: Your message of "Thu, 17 May 2012 11:13:02 -0400."
 <CAFANWtUrROGJZF0fFAZhs8QOnZQ2W4H7DqWDCwA+pUMnqCi1KQ@mail.gmail.com>
References: <CAJNg7VLre5fLRkHiJkhLgA++ce0VvFzTHjdQ9YU5khHnUocbEw@mail.gmail.com>
 <201205171510.q4HFA5nh022835@mail.r-bonomi.com>
 <CAFANWtUrROGJZF0fFAZhs8QOnZQ2W4H7DqWDCwA+pUMnqCi1KQ@mail.gmail.com>
Message-ID: <20120518000148.6390420B5016@drugs.dv.isc.org>


In message <CAFANWtUrROGJZF0fFAZhs8QOnZQ2W4H7DqWDCwA+pUMnqCi1KQ at mail.gmail.com>
, Darius Jahandarie writes:
> On Thu, May 17, 2012 at 11:10 AM, Robert Bonomi
> <bonomi at mail.r-bonomi.com> wrote:
> >
> > Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> >>
> >> On Thu, May 17, 2012 at 12:46 AM, PC <paul4004 at gmail.com> wrote:
> >> > While there may be other grounds for telling them not to call you, the
> >> > do not call list is not one of them as it does not apply to business
> >> > to business solicitations.
> >> >
> >> > "The national Do-Not-Call list protects home voice or personal
> >> > wireless phone numbers only. While you may be able to register a
> >> > business number, your registration will not make telephone
> >> > solicitations to that number unlawful."
> >> > http://www.fcc.gov/guides/unwanted-telephone-marketing-calls
> >> >
> >>
> >> Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list )
> >>
> >> The Do-Not-Call registry does not prevent all unwanted calls. It does
> >> not cover the following:
> >>
> >> =C2=A0 =C2=A0 =C2=A0calls from organizations with which you have establi=
> shed a
> >> business relationship;
> >>
> >> And, in this case, there is a previously established =C2=A0business rela=
> tionship.
> >
> > a) The "previously established business relationship" exemption expires 6
> > =C2=A0 months after the 'business relationship' ends. (This is in the 'fi=
> ne
> > =C2=A0 print' of the actual rules0 =C2=A0As the relationship in question =
> ended
> > =C2=A0 several years ago, according to the prior poster, this exemption w=
> ould
> > =C2=A0 not apply.
> >
> > b) Nothing in the Do-not-call rules applies to calls to business numbers.
> > =C2=A0 Callers to business numbers are not even required to respect a 'pu=
> t me
> > =C2=A0 on your "do-not-call" list', or 'do not call me again' request und=
> er
> > =C2=A0 the DNC rules.
> 
> So the moral of the story is to make sure you always make your Cogent
> calls from your home phone? :-)
> 
> --=20
> Darius Jahandarie
> 

I suspect you could just sue them for harassment if they fail to
honour a request to stop calling you.

do-not-call lists cover home phones, in part, as governments, world
wide, recognise that individuals are not in the position to sue
every company that fails to honour requests to cease and desist.
Company to company battles are more even and many companies have a
existing relationship with lawyers as it is needed for other reasons.

There are laws in most countries that will stop this harassment.
You just need to pick the right one for the circumstances.

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


From blake at pfankuch.me  Thu May 17 20:31:24 2012
From: blake at pfankuch.me (Blake Pfankuch)
Date: Fri, 18 May 2012 01:31:24 +0000
Subject: Commerical Backup Solutions
In-Reply-To: <CABmW_PdpXTxvfL9VkqO9OrC867F53pKwLM8CXmo+ZowZpQj_LA@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
 <CAFJhVwgM9x2fCV0z2m6aNQKcz8jVpPpDPRn7br_JQ8nwdv1+Dw@mail.gmail.com>
 <CABmW_PdpXTxvfL9VkqO9OrC867F53pKwLM8CXmo+ZowZpQj_LA@mail.gmail.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C84861344B8@SHSBS.shenrons-house.local>

First, I work for a managed service provider.  We support a large number of traditional and over the wire backup solutions.  We have used Symantec Backup Exec, eVault, Acronis, Intronis, Asigra, Heroware (newer solution more DR focused) and many more I've purged from my memory.

I have been using BE since it was Veritas starting in about 2003.  Backup Exec is GREAT if you have a premise Disk server with Tape archive, or even a remote over fast WAN.  Acronis is nice, but not easy to manage historically.  Intronis get not only a no, but a "hell no please die now".  Asigra is probably one of my favorites.  You spend the cash for it, but it works right, it integrates with everything, depending on if you get it from a reseller or run your own vault, you get good reporting options and BMR is easy as pie.  Heroware has great DR and versioning options but its still growing.  Small datacenter platform, I like it a lot.

Aiming at Asigra a little more there are many vendors that offer over the wire backup using this.  Most of them price by the gig, but based on what you are doing you could probably do a peer replication where you run your own "vault" locally to back up to, and then integrate that to one of many providers to get your off site.  Asigra offers decent compression and integration into Windows and nix tools for open file and such.  We have used Asigra to backup up anything from nt4 to 2008r2, nix, bsd, as400, esx and esxi.  All the backup stuff is included.  You get the base software you get the ability to back up everything it can, with the exception of Message Level backup and restore in Exchange, and file level within SharePoint which require another service to be enabled.  The UI has its moments of clunky, but it has gotten WAY better over the past few years.  Reporting options are great, as is file growth trending.  Restores are tricky the first time, but its just a learning curve like any other app.

As far as BMR restores on above products I've pretty much done them all.  We do a lot of SMB work so many times single server, often SBS.  I have done single DC, Exchange servers, mysql servers, file and print servers and many more.  By far the trickiest ones are the Windows Small Business Servers based solely on the fact they can be complicated to work with as they have Windows, AD, Exchange, SQL, RWW and SharePoint on 1 box.  If you have ever done a BMR of an SBS server 2000/2003/2008/2011 if everything isn't perfect you might as well rebuild.  All of these assume you have a well managed backup solution which is getting all the data needed for a full restore of course.

Backup Exec its possible and its not that hard.  EVault in theory, but the process can be difficult.  Acronis does a very nice job of it.  Intronis don't bother, spend the time working on a resume because a BMR from this is probably a career changing event.  I had to attempt it for one customer, I got the data I needed gave it the proverbial finger and built a new server to move it onto.  

Asigra makes it really easy.   I have done about 5 (about 18 in our company total) SBS full restores.  You have to jump through a few hoops, but we fully restored a failed SBS 2003 server onto a VM while replacement hardware came in in 12 hours, including line of business SQL app, Exchange, AD and about 200gb of data.

Heroware is very similar in theory.  It works off a replication technology (DoubleTake backend) which does snapshots within the replication.  Heroware is designed to have an "appliance" per 10-50 servers depending on size and load so it might not scale to the size you are looking.  

Dollars to doughnuts if I had the option, I would do Asigra every time if I had the budget from the customer for the offsite.  Why?  Many of the resellers out there even guarantee they can do a 24 or 48 hour RTO of a full environment assuming they have the correct backed up date.  It just works that well.  I have done 2 5+ server environments restore the whole thing from backups with no problems in 24 hours or less onto mismatched hardware as well.  Keep in mind we are working with customers with user counts between 10 and 150 in most cases and usually about $1 per gig  because they are lower size.  I've heard rumors of people getting as low as 25 cents a gig, but I cant speak to that.

Yes, I resell many of these products at my day job, however I also implement and support them and work with the various support teams from each vendor.  I favor Asigra because of personal preference and ease of use.  

--Blake

-----Original Message-----
From: Josh Baird [mailto:joshbaird at gmail.com] 
Sent: Thursday, May 17, 2012 6:01 PM
To: Thomas York
Cc: nanog at nanog.org
Subject: Re: Commerical Backup Solutions

We have used Symantec's BackupExec (Veritas) in several locations but have standardized on IBM's Tivoli Storage Manager (TSM).  Not a fan of IBM, but it works, and it works well.  Be prepared to drop some serious coin, though.  We currently use it to do tape backups for over
800+ servers (Linux, AIX, Windows).

Josh

On Thu, May 17, 2012 at 7:08 PM, Thomas York <straterra at fuhell.com> wrote:
> We use Barracuda Yosemite backup with about 10 locations all over the 
> world, using disk to disk (single disks via esata and to SANs) and 
> disk to tape (both libraries and single drives). Very rarely do we have issues.
> Barracuda support isn't as good as Yosemite's (Barracuda bought them) 
> but still not bad. Also, the site wide license is a steal! Get a demo, 
> it might fit the bill.
>
> --Thomas York
> On May 17, 2012 6:59 PM, "Mike Lyon" <mike.lyon at gmail.com> wrote:
>
>> We used Acronis and it was a nightmare as was their off-shored 
>> support model. Never again... Wouldn't touch them with a 10 foot pole.
>>
>> Switched to Iron Mountain LiveVault which backs everything up over 
>> the wire. It has basic reporting functions but not extremely granular.
>> http://ironmountain.com/services/democenter/livevault/player.html
>>
>> Barracuda also seems to have a nice product. Though, i've never used it:
>> http://www.barracudanetworks.com/ns/products/backup_overview.php
>>
>> -Mike
>>
>> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org>
>> wrote:
>>
>> > Hey folks.
>> >
>> >
>> >
>> > I'm hoping for some input from operational folks on backup 
>> > solutions for servers. ?We are looking for a commercial backup 
>> > solution with a nice reporting dashboard etc.
>> >
>> >
>> >
>> > It must support full/incremental backups on Windows and various 
>> > flavors
>> of
>> > Linux. ?We would also be looking for bare metal image/recovery abilities.
>> >
>> >
>> >
>> > To date, we've been fond of Acronis until we got the quote for it ..
>> > Initially we would be looking at 50-80 servers and growing it up 
>> > from
>> there
>> > to probably 150-200 boxes. ?Some of these servers are 
>> > geographically dispersed.
>> >
>> >
>> >
>> > At the moment we have been using Bacula but it lacks bare metal 
>> > options
>> and
>> > doesn't have any nice reporting options (Executive Dashboard etc)
>> >
>> >
>> >
>> > Thanks for any input,
>> >
>> >
>> >
>> > Paul
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Mike Lyon
>> 408-621-4826
>> mike.lyon at gmail.com
>>
>> http://www.linkedin.com/in/mlyon
>>



From thames at viewqwest.com  Thu May 17 21:37:30 2012
From: thames at viewqwest.com (Thames)
Date: Fri, 18 May 2012 10:37:30 +0800
Subject: YouTube Video Streaming
Message-ID: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>

I would like to get some input for the following problem we face with YouTube video streaming.
We are an ISP in Singapore and peer with Google at Equinix and SOX (Singapore Open Exchange), For about 2 weeks we have been facing choppy streaming or continuous buffering on various YouTube videos. These problem videos are streamed at HD or original quality.
Our troubleshooting narrow down to those bad videos being streamed to us from outside Singapore. We contacted Google support, they are confused too, as why we are served from a cache server in Poland on one of the videos. The case has been escalated within Google, unfortunately no update from them since.

Not all YouTube videos are bad through us, some 45 minutes videos can fully buffered within seconds on HD or original quality, of course the IP we streamed for these videos are through our local peering with Google.

-Thames



From leigh.porter at ukbroadband.com  Fri May 18 03:48:57 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 18 May 2012 08:48:57 +0000
Subject: YouTube Video Streaming
In-Reply-To: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>
References: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>
Message-ID: <D181DDABABE57E4DB72FEE003314786456095A@EALPO1.ukbroadband.com>


> I would like to get some input for the following problem we face with
> YouTube video streaming.
> We are an ISP in Singapore and peer with Google at Equinix and SOX
> (Singapore Open Exchange), For about 2 weeks we have been facing choppy
> streaming or continuous buffering on various YouTube videos. These
> problem videos are streamed at HD or original quality.
> Our troubleshooting narrow down to those bad videos being streamed to
> us from outside Singapore. We contacted Google support, they are
> confused too, as why we are served from a cache server in Poland on one
> of the videos. The case has been escalated within Google, unfortunately
> no update from them since.
> 
> Not all YouTube videos are bad through us, some 45 minutes videos can
> fully buffered within seconds on HD or original quality, of course the
> IP we streamed for these videos are through our local peering with
> Google.

I have seen similar issues, some videos work fine but others seem to stop after either a few minutes or half way through. The same behaviour is seen on various computers, the same video stops at the same place.

I didn't have time and could not be bothered to look into it at the time and kind of put it down to one of those things that will be fixed later. 

So I'd be really interested in what the outcome is!

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From thilo.bangert at gmail.com  Fri May 18 04:53:18 2012
From: thilo.bangert at gmail.com (Thilo Bangert)
Date: Fri, 18 May 2012 11:53:18 +0200
Subject: pbx recco
In-Reply-To: <m2vcjxwfa5.wl%randy@psg.com>
References: <m2vcjxwfa5.wl%randy@psg.com>
Message-ID: <1349359.InRBKCV2M7@gaston>

yate hasnt been mentioned, which i am using successfully in multiple roles.

http://yate.null.ro/pmwiki/

they have a distro similar to freepbx at http://www.freesentral.com/

however, we are currently evaluating sip:provider CE, which may be more than 
you need, but definitively worth a look.

http://www.sipwise.com/products/spce/

its an open source softswitch implementation, which has made tremendous 
progress in recent releases.

kind regards
Thilo


From askoorb+nanog at gmail.com  Fri May 18 06:48:47 2012
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Fri, 18 May 2012 12:48:47 +0100
Subject: YouTube Video Streaming
In-Reply-To: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>
References: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>
Message-ID: <CALKLF0-ubqoDCNcbtTgc=rOy_Dd_sXxRJd=qep+jDAMOVVDwZw@mail.gmail.com>

Hi,

On Fri, May 18, 2012 at 3:37 AM, Thames <thames at viewqwest.com> wrote:
> I would like to get some input for the following problem we face with YouTube video streaming.
> We are an ISP in Singapore and peer with Google at Equinix and SOX (Singapore Open Exchange), For about 2 weeks we have been facing choppy streaming or continuous buffering on various YouTube videos.

I don't know how "big" you are, but have you considered joining the
"Google Global Cache" http://ggcadmin.google.com/ggc ?  It may help in
the future with issues like this.

It seems odd that Google aren't doing much with this, they are usually
quite obsessive when it comes to reducing latency and other issues
over their peering connections.

Alex


From jamie at photon.com  Fri May 18 07:08:59 2012
From: jamie at photon.com (Jamie Bowden)
Date: Fri, 18 May 2012 12:08:59 +0000
Subject: Commerical Backup Solutions
In-Reply-To: <CABmW_PdpXTxvfL9VkqO9OrC867F53pKwLM8CXmo+ZowZpQj_LA@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
 <CAFJhVwgM9x2fCV0z2m6aNQKcz8jVpPpDPRn7br_JQ8nwdv1+Dw@mail.gmail.com>
 <CABmW_PdpXTxvfL9VkqO9OrC867F53pKwLM8CXmo+ZowZpQj_LA@mail.gmail.com>
Message-ID: <465966A5F5B867419F604CD3E604C1E505BD305C@pra-ess-mail.pra.ray.com>

BackupExec was a Seagate product Symantec bought prior to their purchase of Veritas.  I've been using NetBackup for over a decade now (originally in Irix and Solaris heavy environments, but these days on Windows and Linux for the most part). Symantec are a pain the ass to deal with, but the core NetBackup functionality is still stable and reliable (and BackupExec has been brought into parity in many ways with NetBackup over the years, but still lacks some features and functions its bigger brother handles).  The master server role can be anywhere in your topology and the media server role is separated out and can exist across multiple hosts and locations.  Management can be done from any approved host running the management console software.  Tivoli and Legato are pretty similar feature, functionality, and being expensive, though I wouldn't wish Legato on anyone.

-- 
Jamie Bowden		(jamie at photon.com)
Sr. Sys. Admin.		(703) 243-6613 x3848
Photon Research Associates, Inc.
1616 Fort Myer Drive, Suite 1000
Arlington, VA 22209


> -----Original Message-----
> From: Josh Baird [mailto:joshbaird at gmail.com]
> Sent: Thursday, May 17, 2012 8:02 PM
> To: Thomas York
> Cc: nanog at nanog.org
> Subject: Re: Commerical Backup Solutions
> 
> We have used Symantec's BackupExec (Veritas) in several locations but
> have standardized on IBM's Tivoli Storage Manager (TSM).  Not a fan of
> IBM, but it works, and it works well.  Be prepared to drop some
> serious coin, though.  We currently use it to do tape backups for over
> 800+ servers (Linux, AIX, Windows).
> 
> Josh
> 
> On Thu, May 17, 2012 at 7:08 PM, Thomas York <straterra at fuhell.com>
> wrote:
> > We use Barracuda Yosemite backup with about 10 locations all over the
> > world, using disk to disk (single disks via esata and to SANs) and
> disk to
> > tape (both libraries and single drives). Very rarely do we have
> issues.
> > Barracuda support isn't as good as Yosemite's (Barracuda bought them)
> but
> > still not bad. Also, the site wide license is a steal! Get a demo, it
> might
> > fit the bill.
> >
> > --Thomas York
> > On May 17, 2012 6:59 PM, "Mike Lyon" <mike.lyon at gmail.com> wrote:
> >
> >> We used Acronis and it was a nightmare as was their off-shored
> support
> >> model. Never again... Wouldn't touch them with a 10 foot pole.
> >>
> >> Switched to Iron Mountain LiveVault which backs everything up over
> the
> >> wire. It has basic reporting functions but not extremely granular.
> >> http://ironmountain.com/services/democenter/livevault/player.html
> >>
> >> Barracuda also seems to have a nice product. Though, i've never used
> it:
> >> http://www.barracudanetworks.com/ns/products/backup_overview.php
> >>
> >> -Mike
> >>
> >> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org>
> >> wrote:
> >>
> >> > Hey folks.
> >> >
> >> >
> >> >
> >> > I'm hoping for some input from operational folks on backup
> solutions for
> >> > servers. ?We are looking for a commercial backup solution with a
> nice
> >> > reporting dashboard etc.
> >> >
> >> >
> >> >
> >> > It must support full/incremental backups on Windows and various
> flavors
> >> of
> >> > Linux. ?We would also be looking for bare metal image/recovery
> abilities.
> >> >
> >> >
> >> >
> >> > To date, we've been fond of Acronis until we got the quote for it
> ..
> >> > Initially we would be looking at 50-80 servers and growing it up
> from
> >> there
> >> > to probably 150-200 boxes. ?Some of these servers are
> geographically
> >> > dispersed.
> >> >
> >> >
> >> >
> >> > At the moment we have been using Bacula but it lacks bare metal
> options
> >> and
> >> > doesn't have any nice reporting options (Executive Dashboard etc)
> >> >
> >> >
> >> >
> >> > Thanks for any input,
> >> >
> >> >
> >> >
> >> > Paul
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> Mike Lyon
> >> 408-621-4826
> >> mike.lyon at gmail.com
> >>
> >> http://www.linkedin.com/in/mlyon
> >>



From scott at sberkman.net  Fri May 18 09:33:24 2012
From: scott at sberkman.net (Scott Berkman)
Date: Fri, 18 May 2012 10:33:24 -0400
Subject: Commerical Backup Solutions
In-Reply-To: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
Message-ID: <00e001cd3503$2f9d3ba0$8ed7b2e0$@sberkman.net>

Add Seagate's Evault to your list:

http://www.evault.com/

Has the support for BMR, Windows (including agents for Exchange and MSSQL),
Linux, encryption, vault replication, VADP, etc.

They also have a partner program for service providers (my employer happens
to be one).

I've personally used the product across multiple companies all the way back
to before Seagate bought them out, and I view it as one of the most mature
offerings on the market, and support has always been great.

Good luck!

	-Scott

-----Original Message-----
From: Paul Stewart [mailto:paul at paulstewart.org] 
Sent: Thursday, May 17, 2012 6:53 PM
To: nanog at nanog.org
Subject: Commerical Backup Solutions

Hey folks.

 

I'm hoping for some input from operational folks on backup solutions for
servers.  We are looking for a commercial backup solution with a nice
reporting dashboard etc.

 

It must support full/incremental backups on Windows and various flavors of
Linux.  We would also be looking for bare metal image/recovery abilities.

 

To date, we've been fond of Acronis until we got the quote for it ..
Initially we would be looking at 50-80 servers and growing it up from there
to probably 150-200 boxes.  Some of these servers are geographically
dispersed.

 

At the moment we have been using Bacula but it lacks bare metal options and
doesn't have any nice reporting options (Executive Dashboard etc)

 

Thanks for any input,

 

Paul

 

 

 




From scott at sberkman.net  Fri May 18 09:41:40 2012
From: scott at sberkman.net (Scott Berkman)
Date: Fri, 18 May 2012 10:41:40 -0400
Subject: Commerical Backup Solutions
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C84861344B8@SHSBS.shenrons-house.local>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
 <CAFJhVwgM9x2fCV0z2m6aNQKcz8jVpPpDPRn7br_JQ8nwdv1+Dw@mail.gmail.com>
 <CABmW_PdpXTxvfL9VkqO9OrC867F53pKwLM8CXmo+ZowZpQj_LA@mail.gmail.com>
 <CC75EEBF17C7374EA8309102B7B10C84861344B8@SHSBS.shenrons-house.local>
Message-ID: <00e501cd3504$56d51980$047f4c80$@sberkman.net>

I wanted to add that I've had some recent experience with Asigra (and
specifically pitting it against Evault), and they are currently a little
behind in VADP and other VMWare related feature sets, and their Linux
distribution support is very limited (basically no support for anything but
RedHat).  They also charge extra for the web console.

Overall for our needs, Evault beat out Asigra, but there isn't anything
horribly wrong with Asigra's product either.

-Scott

-----Original Message-----
From: Blake Pfankuch [mailto:blake at pfankuch.me] 
Sent: Thursday, May 17, 2012 9:31 PM
To: Josh Baird; Thomas York
Cc: nanog at nanog.org
Subject: RE: Commerical Backup Solutions

First, I work for a managed service provider.  We support a large number of
traditional and over the wire backup solutions.  We have used Symantec
Backup Exec, eVault, Acronis, Intronis, Asigra, Heroware (newer solution
more DR focused) and many more I've purged from my memory.

I have been using BE since it was Veritas starting in about 2003.  Backup
Exec is GREAT if you have a premise Disk server with Tape archive, or even a
remote over fast WAN.  Acronis is nice, but not easy to manage historically.
Intronis get not only a no, but a "hell no please die now".  Asigra is
probably one of my favorites.  You spend the cash for it, but it works
right, it integrates with everything, depending on if you get it from a
reseller or run your own vault, you get good reporting options and BMR is
easy as pie.  Heroware has great DR and versioning options but its still
growing.  Small datacenter platform, I like it a lot.

Aiming at Asigra a little more there are many vendors that offer over the
wire backup using this.  Most of them price by the gig, but based on what
you are doing you could probably do a peer replication where you run your
own "vault" locally to back up to, and then integrate that to one of many
providers to get your off site.  Asigra offers decent compression and
integration into Windows and nix tools for open file and such.  We have used
Asigra to backup up anything from nt4 to 2008r2, nix, bsd, as400, esx and
esxi.  All the backup stuff is included.  You get the base software you get
the ability to back up everything it can, with the exception of Message
Level backup and restore in Exchange, and file level within SharePoint which
require another service to be enabled.  The UI has its moments of clunky,
but it has gotten WAY better over the past few years.  Reporting options are
great, as is file growth trending.  Restores are tricky the first time, but
its just a learning curve like any other app.

As far as BMR restores on above products I've pretty much done them all.  We
do a lot of SMB work so many times single server, often SBS.  I have done
single DC, Exchange servers, mysql servers, file and print servers and many
more.  By far the trickiest ones are the Windows Small Business Servers
based solely on the fact they can be complicated to work with as they have
Windows, AD, Exchange, SQL, RWW and SharePoint on 1 box.  If you have ever
done a BMR of an SBS server 2000/2003/2008/2011 if everything isn't perfect
you might as well rebuild.  All of these assume you have a well managed
backup solution which is getting all the data needed for a full restore of
course.

Backup Exec its possible and its not that hard.  EVault in theory, but the
process can be difficult.  Acronis does a very nice job of it.  Intronis
don't bother, spend the time working on a resume because a BMR from this is
probably a career changing event.  I had to attempt it for one customer, I
got the data I needed gave it the proverbial finger and built a new server
to move it onto.  

Asigra makes it really easy.   I have done about 5 (about 18 in our company
total) SBS full restores.  You have to jump through a few hoops, but we
fully restored a failed SBS 2003 server onto a VM while replacement hardware
came in in 12 hours, including line of business SQL app, Exchange, AD and
about 200gb of data.

Heroware is very similar in theory.  It works off a replication technology
(DoubleTake backend) which does snapshots within the replication.  Heroware
is designed to have an "appliance" per 10-50 servers depending on size and
load so it might not scale to the size you are looking.  

Dollars to doughnuts if I had the option, I would do Asigra every time if I
had the budget from the customer for the offsite.  Why?  Many of the
resellers out there even guarantee they can do a 24 or 48 hour RTO of a full
environment assuming they have the correct backed up date.  It just works
that well.  I have done 2 5+ server environments restore the whole thing
from backups with no problems in 24 hours or less onto mismatched hardware
as well.  Keep in mind we are working with customers with user counts
between 10 and 150 in most cases and usually about $1 per gig  because they
are lower size.  I've heard rumors of people getting as low as 25 cents a
gig, but I cant speak to that.

Yes, I resell many of these products at my day job, however I also implement
and support them and work with the various support teams from each vendor.
I favor Asigra because of personal preference and ease of use.  

--Blake

-----Original Message-----
From: Josh Baird [mailto:joshbaird at gmail.com]
Sent: Thursday, May 17, 2012 6:01 PM
To: Thomas York
Cc: nanog at nanog.org
Subject: Re: Commerical Backup Solutions

We have used Symantec's BackupExec (Veritas) in several locations but have
standardized on IBM's Tivoli Storage Manager (TSM).  Not a fan of IBM, but
it works, and it works well.  Be prepared to drop some serious coin, though.
We currently use it to do tape backups for over
800+ servers (Linux, AIX, Windows).

Josh

On Thu, May 17, 2012 at 7:08 PM, Thomas York <straterra at fuhell.com> wrote:
> We use Barracuda Yosemite backup with about 10 locations all over the 
> world, using disk to disk (single disks via esata and to SANs) and 
> disk to tape (both libraries and single drives). Very rarely do we have
issues.
> Barracuda support isn't as good as Yosemite's (Barracuda bought them) 
> but still not bad. Also, the site wide license is a steal! Get a demo, 
> it might fit the bill.
>
> --Thomas York
> On May 17, 2012 6:59 PM, "Mike Lyon" <mike.lyon at gmail.com> wrote:
>
>> We used Acronis and it was a nightmare as was their off-shored 
>> support model. Never again... Wouldn't touch them with a 10 foot pole.
>>
>> Switched to Iron Mountain LiveVault which backs everything up over 
>> the wire. It has basic reporting functions but not extremely granular.
>> http://ironmountain.com/services/democenter/livevault/player.html
>>
>> Barracuda also seems to have a nice product. Though, i've never used it:
>> http://www.barracudanetworks.com/ns/products/backup_overview.php
>>
>> -Mike
>>
>> On Thu, May 17, 2012 at 3:53 PM, Paul Stewart <paul at paulstewart.org>
>> wrote:
>>
>> > Hey folks.
>> >
>> >
>> >
>> > I'm hoping for some input from operational folks on backup 
>> > solutions for servers. ?We are looking for a commercial backup 
>> > solution with a nice reporting dashboard etc.
>> >
>> >
>> >
>> > It must support full/incremental backups on Windows and various 
>> > flavors
>> of
>> > Linux. ?We would also be looking for bare metal image/recovery
abilities.
>> >
>> >
>> >
>> > To date, we've been fond of Acronis until we got the quote for it ..
>> > Initially we would be looking at 50-80 servers and growing it up 
>> > from
>> there
>> > to probably 150-200 boxes. ?Some of these servers are 
>> > geographically dispersed.
>> >
>> >
>> >
>> > At the moment we have been using Bacula but it lacks bare metal 
>> > options
>> and
>> > doesn't have any nice reporting options (Executive Dashboard etc)
>> >
>> >
>> >
>> > Thanks for any input,
>> >
>> >
>> >
>> > Paul
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Mike Lyon
>> 408-621-4826
>> mike.lyon at gmail.com
>>
>> http://www.linkedin.com/in/mlyon
>>





From dwhite at olp.net  Fri May 18 09:48:37 2012
From: dwhite at olp.net (Dan White)
Date: Fri, 18 May 2012 09:48:37 -0500
Subject: YouTube Video Streaming
In-Reply-To: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>
References: <BA368BB3EE598C479AAA581FCC5D70189B4C73E0C2@H-EXCHANGE.viewqwest.sg>
Message-ID: <20120518144837.GG5819@dan.olp.net>

On 05/18/12?10:37?+0800, Thames wrote:
>I would like to get some input for the following problem we face with
>YouTube video streaming.
>
>We are an ISP in Singapore and peer with Google at Equinix and SOX
>(Singapore Open Exchange), For about 2 weeks we have been facing choppy
>streaming or continuous buffering on various YouTube videos. These problem
>videos are streamed at HD or original quality.  Our troubleshooting narrow
>down to those bad videos being streamed to us from outside Singapore. We
>contacted Google support, they are confused too, as why we are served from
>a cache server in Poland on one of the videos. The case has been escalated
>within Google, unfortunately no update from them since.
>
>Not all YouTube videos are bad through us, some 45 minutes videos can
>fully buffered within seconds on HD or original quality, of course the IP
>we streamed for these videos are through our local peering with Google.
>
>-Thames

Thames,

We went through something similar here about a year ago. It took around two
weeks for Google engineers to resolve the trouble, however, the problem has
popped up once or twice since then.

Here is a post from the nanog archives that describes a workaround, where
you relay youtube dns queries to another DNS resolver in your area that
does not experience the problem:

http://seclists.org/nanog/2011/May/21

-- 
Dan White


From deric.kwok2000 at gmail.com  Fri May 18 12:13:36 2012
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Fri, 18 May 2012 13:13:36 -0400
Subject: need help about bgd and ospf
Message-ID: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>

Hi all

Can I have questions about bgp and ospf

1/ Do I have to redistrt bgd in ospf to make ospf to know which
upstrem bgp routers to go out

2/ If yes, how many routes can ospf database handle as one full bgp
table is about 400,000 routes

3/ When we have 8 ospf routers to run "redistrubt bgp", ls it 8 x
400,000 routes in ospf database?

4/ If not redistribted bgp, how ospf to know which upstream to go out

Thank you for your help


From jeff.tantsura at ericsson.com  Fri May 18 12:18:31 2012
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Fri, 18 May 2012 13:18:31 -0400
Subject: need help about bgd and ospf
In-Reply-To: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>
References: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>
Message-ID: <053FA908-4662-4224-B9D7-218E6E053A53@ericsson.com>

Nope, run iBGP, have only next-hops in OSPF.

Regards,
Jeff

On May 18, 2012, at 19:14, "Deric Kwok" <deric.kwok2000 at gmail.com> wrote:

> Hi all
> 
> Can I have questions about bgp and ospf
> 
> 1/ Do I have to redistrt bgd in ospf to make ospf to know which
> upstrem bgp routers to go out
> 
> 2/ If yes, how many routes can ospf database handle as one full bgp
> table is about 400,000 routes
> 
> 3/ When we have 8 ospf routers to run "redistrubt bgp", ls it 8 x
> 400,000 routes in ospf database?
> 
> 4/ If not redistribted bgp, how ospf to know which upstream to go out
> 
> Thank you for your help
> 


From bgreene at senki.org  Fri May 18 12:21:09 2012
From: bgreene at senki.org (Barry Greene)
Date: Fri, 18 May 2012 10:21:09 -0700
Subject: need help about bgd and ospf
In-Reply-To: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>
References: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>
Message-ID: <4E83C6F1-EA09-46CD-94A4-2C5B8ACB4728@senki.org>

Hi Deric,

I would strongly suggest that you watch a couple of the NANOG tutorials on routing. The would help you answer these and other questions. 

Go to this page - http://www.nanog.org/meetings/archive/ - pick a meeting and find the BGP tutorial. There are a few taught each year. 

Barry

Sent from my iPad

On May 18, 2012, at 10:13 AM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:

> Hi all
> 
> Can I have questions about bgp and ospf
> 
> 1/ Do I have to redistrt bgd in ospf to make ospf to know which
> upstrem bgp routers to go out
> 
> 2/ If yes, how many routes can ospf database handle as one full bgp
> table is about 400,000 routes
> 
> 3/ When we have 8 ospf routers to run "redistrubt bgp", ls it 8 x
> 400,000 routes in ospf database?
> 
> 4/ If not redistribted bgp, how ospf to know which upstream to go out
> 
> Thank you for your help
> 


From cscora at apnic.net  Fri May 18 14:03:46 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 19 May 2012 05:03:46 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201205181903.q4IJ3kxW026546@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,
TRNOG, 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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 19 May, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              409230
    Prefixes after maximum aggregation:                          173889
    Deaggregation factor:                                          2.35
    Unique aggregates announced to Internet:                     199573
Total ASes present in the Internet Routing Table:                 41033
    Prefixes per ASN:                                              9.97
Origin-only ASes present in the Internet Routing Table:           33202
Origin ASes announcing only one prefix:                           15654
Transit ASes present in the Internet Routing Table:                5481
Transit-only ASes present in the Internet Routing Table:            137
Average AS path length visible in the Internet Routing Table:       4.5
    Max AS path length visible:                                      30
    Max AS path prepend of ASN (36992)                               22
Prefixes from unregistered ASNs in the Routing Table:               365
    Unregistered ASNs in the Routing Table:                         132
Number of 32-bit ASNs allocated by the RIRs:                       2716
Number of 32-bit ASNs visible in the Routing Table:                2350
Prefixes from 32-bit ASNs in the Routing Table:                    5960
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            106
Number of addresses announced to Internet:                   2550061936
    Equivalent to 151 /8s, 254 /16s and 219 /24s
    Percentage of available address space announced:               68.8
    Percentage of allocated address space announced:               68.9
    Percentage of available address space allocated:               99.9
    Percentage of address space in use by end-sites:               92.7
Total number of prefixes smaller than registry allocations:      174827

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   100170
    Total APNIC prefixes after maximum aggregation:               32430
    APNIC Deaggregation factor:                                    3.09
Prefixes being announced from the APNIC address blocks:           96619
    Unique aggregates announced from the APNIC address blocks:    39919
APNIC Region origin ASes present in the Internet Routing Table:    4690
    APNIC Prefixes per ASN:                                       20.60
APNIC Region origin ASes announcing only one prefix:               1242
APNIC Region transit ASes present in the Internet Routing Table:    728
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         22
Number of APNIC region 32-bit ASNs visible in the Routing Table:    212
Number of APNIC addresses announced to Internet:              644826304
    Equivalent to 38 /8s, 111 /16s and 68 /24s
    Percentage of available APNIC address space announced:         81.8

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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:                    151240
    Total ARIN prefixes after maximum aggregation:                76711
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           121762
    Unique aggregates announced from the ARIN address blocks:     50992
ARIN Region origin ASes present in the Internet Routing Table:    15113
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5744
ARIN Region transit ASes present in the Internet Routing Table:    1595
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      16
Number of ARIN addresses announced to Internet:               812257216
    Equivalent to 48 /8s, 106 /16s and 15 /24s
    Percentage of available ARIN address space announced:          64.8

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:                    101103
    Total RIPE prefixes after maximum aggregation:                54239
    RIPE Deaggregation factor:                                     1.86
Prefixes being announced from the RIPE address blocks:            93267
    Unique aggregates announced from the RIPE address blocks:     58890
RIPE Region origin ASes present in the Internet Routing Table:    16571
    RIPE Prefixes per ASN:                                         5.63
RIPE Region origin ASes announcing only one prefix:                8060
RIPE Region transit ASes present in the Internet Routing Table:    2649
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1563
Number of RIPE addresses announced to Internet:               513346312
    Equivalent to 30 /8s, 153 /16s and 11 /24s
    Percentage of available RIPE address space announced:          82.7

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:                   41527
    Total LACNIC prefixes after maximum aggregation:               8282
    LACNIC Deaggregation factor:                                   5.01
Prefixes being announced from the LACNIC address blocks:          41554
    Unique aggregates announced from the LACNIC address blocks:   20491
LACNIC Region origin ASes present in the Internet Routing Table:   1596
    LACNIC Prefixes per ASN:                                      26.04
LACNIC Region origin ASes announcing only one prefix:               439
LACNIC Region transit ASes present in the Internet Routing Table:   300
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   554
Number of LACNIC addresses announced to Internet:             101104712
    Equivalent to 6 /8s, 6 /16s and 188 /24s
    Percentage of available LACNIC address space announced:        67.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:                   9047
    Total AfriNIC prefixes after maximum aggregation:              2163
    AfriNIC Deaggregation factor:                                  4.18
Prefixes being announced from the AfriNIC address blocks:          7073
    Unique aggregates announced from the AfriNIC address blocks:   2216
AfriNIC Region origin ASes present in the Internet Routing Table:   540
    AfriNIC Prefixes per ASN:                                     13.10
AfriNIC Region origin ASes announcing only one prefix:              169
AfriNIC Region transit ASes present in the Internet Routing Table:  120
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    5
Number of AfriNIC addresses announced to Internet:             31790080
    Equivalent to 1 /8s, 229 /16s and 20 /24s
    Percentage of available AfriNIC address space announced:       47.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     2608      11113        1101   Korea Telecom (KIX)
17974     1924        530          80   PT TELEKOMUNIKASI INDONESIA
 7545     1679        301          86   TPG Internet Pty Ltd
 4755     1577        385         155   TATA Communications formerly 
 9829     1296       1085          28   BSNL National Internet Backbo
 7552     1173       1062          11   Vietel Corporation
 9583     1157         87         500   Sify Limited
 4808     1109       2051         318   CNCGROUP IP network: China169
24560     1027        385         167   Bharti Airtel Ltd., Telemedia
 9498      964        291          64   BHARTI Airtel Ltd.

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     3414       3807         193   bellsouth.net, inc. 
 7029     3366        985         158   Windstream Communications Inc
18566     2094        382         177   Covad Communications 
 1785     1905        681         131   PaeTec Communications, Inc.
20115     1637       1566         619   Charter Communications 
22773     1607       2911         121   Cox Communications, Inc.
 4323     1584       1042         383   Time Warner Telecom
30036     1417        263         754   Mediacom Communications Corp 
 7018     1223      10024         821   AT&T WorldNet Services
11492     1186        216         364   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
 8402     1673        544          16   Corbina telecom
34984      696        188         172   BILISIM TELEKOM
31148      685         37           9   FreeNet ISP
12479      681        671          67   Uni2 Autonomous System
 2118      658         97          14   EUnet/RELCOM Autonomous Syste
20940      658        216         512   Akamai Technologies European 
 6830      655       2215         426   UPC Distribution Services
 8551      568        360          80   Bezeq International
 3320      486       8442         402   Deutsche Telekom AG
 3292      472       2108         407   TDC Tele Danmark

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     1909        339         180   TVCABLE BOGOTA 
28573     1866       1153          59   NET Servicos de Comunicao S.A
 6503     1527        418          65   AVANTEL, S.A. 
 8151     1484       3027         342   UniNet S.A. de C.V. 
 7303     1435        901         191   Telecom Argentina Stet-France
26615      902        760          32   Tim Brasil S.A.
27947      690         73          95   Telconet S.A
11172      642         91          73   Servicios Alestra S.A de C.V 
22047      582        326          15   VTR PUNTO NET S.A. 
 3816      578        244          98   Empresa Nacional de Telecomun

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     1196        957          12   TEDATA
24863      845        274          35   LINKdotNET AS number
 6713      497        649          18   Itissalat Al-MAGHRIB
 3741      262        905         223   The Internet Solution 
33776      203         12          21   Starcomms Nigeria Limited
12258      197         28          62   Vodacom Internet Company 
24835      179         80           8   RAYA Telecom - Egypt
16637      170        666          82   MTN Network Solutions
15706      164         32           6   Sudatel Internet Exchange Aut
29571      157         15          16   Ci Telecom Autonomous system 

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     3414       3807         193   bellsouth.net, inc. 
 7029     3366        985         158   Windstream Communications Inc
 4766     2608      11113        1101   Korea Telecom (KIX)
18566     2094        382         177   Covad Communications 
17974     1924        530          80   PT TELEKOMUNIKASI INDONESIA
10620     1909        339         180   TVCABLE BOGOTA 
 1785     1905        681         131   PaeTec Communications, Inc.
28573     1866       1153          59   NET Servicos de Comunicao S.A
 7545     1679        301          86   TPG Internet Pty Ltd
 8402     1673        544          16   Corbina telecom

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3366        3208      Windstream Communications Inc
18566      2094        1917      Covad Communications 
17974      1924        1844      PT TELEKOMUNIKASI INDONESIA
28573      1866        1807      NET Servicos de Comunicao S.A
 1785      1905        1774      PaeTec Communications, Inc.
10620      1909        1729      TVCABLE BOGOTA 
 8402      1673        1657      Corbina telecom
 7545      1679        1593      TPG Internet Pty Ltd
 4766      2608        1507      Korea Telecom (KIX)
22773      1607        1486      Cox Communications, Inc.

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
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
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser
32873   UNALLOCATED  12.46.102.0/24       10912       InterNAP Network Ser
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
27.112.114.0/24      23884     Proimage Engineering and Comm
41.222.79.0/24       36938     >>UNKNOWN<<

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:19       /9:12      /10:29      /11:81      /12:235     
/13:460     /14:832     /15:1495    /16:12258   /17:6266    /18:10598   
/19:20694   /20:29440   /21:30649   /22:40198   /23:38324   /24:213890  
/25:1218    /26:1450    /27:809     /28:168     /29:68      /30:17      
/31:0       /32:20      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3023          3366      Windstream Communications Inc
 6389     2133          3414      bellsouth.net, inc. 
18566     2043          2094      Covad Communications 
10620     1735          1909      TVCABLE BOGOTA 
 8402     1651          1673      Corbina telecom
30036     1358          1417      Mediacom Communications Corp 
 6503     1285          1527      AVANTEL, S.A. 
11492     1149          1186      Cable One 
 7011     1070          1185      Citizens Utilities 
 1785     1063          1905      PaeTec Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:542       2:686       4:13        5:11        6:3         8:414    
  12:2005     13:1        14:610      15:12       16:3        17:5      
  20:23       23:172      24:1772     27:1286     31:961      32:57     
  33:2        34:2        36:8        37:469      38:808      40:121    
  41:3097     42:133      44:3        46:1422     47:3        49:404    
  50:550      52:13       54:10       55:9        56:3        57:33     
  58:958      59:484      60:253      61:1228     62:995      63:2051   
  64:4179     65:2252     66:4473     67:2011     68:1164     69:3202   
  70:905      71:489      72:1823     74:2598     75:491      76:327    
  77:941      78:982      79:488      80:1211     81:911      82:664    
  83:553      84:487      85:1221     86:436      87:917      88:333    
  89:1708     90:290      91:4845     92:547      93:1321     94:1527   
  95:1181     96:367      97:313      98:878      99:38      100:7      
 101:190     103:1081    106:103     107:185     108:295     109:1329   
 110:765     111:921     112:410     113:603     114:623     115:834    
 116:932     117:715     118:910     119:1229    120:355     121:699    
 122:1658    123:1103    124:1382    125:1252    128:561     129:195    
 130:250     131:634     132:177     133:22      134:248     135:62     
 136:214     137:240     138:359     139:183     140:493     141:244    
 142:414     143:566     144:524     145:70      146:503     147:297    
 148:770     149:296     150:191     151:177     152:469     153:172    
 154:12      155:402     156:223     157:382     158:183     159:551    
 160:340     161:265     162:347     163:188     164:606     165:398    
 166:571     167:469     168:863     169:126     170:868     171:131    
 172:4       173:1743    174:580     175:431     176:586     177:754    
 178:1369    180:1214    181:83      182:1000    183:296     184:494    
 185:1       186:2302    187:1079    188:1275    189:1806    190:5511   
 192:5999    193:5444    194:4181    195:3219    196:1289    197:136    
 198:3658    199:4628    200:5840    201:1935    202:8584    203:8597   
 204:4335    205:2544    206:2765    207:2801    208:4062    209:3625   
 210:2754    211:1518    212:2030    213:1941    214:870     215:103    
 216:5096    217:1549    218:544     219:314     220:1238    221:557    
 222:324     223:337    

End of report


From scott.wolfe at cybera.net  Fri May 18 15:17:42 2012
From: scott.wolfe at cybera.net (Scott Wolfe)
Date: Fri, 18 May 2012 20:17:42 +0000
Subject: Level3 Issues
Message-ID: <00EF7A2C49DD4A49B732D027E5E728AE18666F75@exchange01.nashville.cybera.net>

Anyone having BGP issues in and out of Level3 in the past 30 minutes?

--ScottW

From bblackford at gmail.com  Fri May 18 15:35:23 2012
From: bblackford at gmail.com (Bill Blackford)
Date: Fri, 18 May 2012 13:35:23 -0700
Subject: Level3 Issues
In-Reply-To: <00EF7A2C49DD4A49B732D027E5E728AE18666F75@exchange01.nashville.cybera.net>
References: <00EF7A2C49DD4A49B732D027E5E728AE18666F75@exchange01.nashville.cybera.net>
Message-ID: <CAMv18ONR_mmJJZVQRqmjYnWR38-MHLUdBDQQW-xzp+XkZcOn=g@mail.gmail.com>

I see a few drops in ATLN

-b


On Fri, May 18, 2012 at 1:17 PM, Scott Wolfe <scott.wolfe at cybera.net> wrote:
> Anyone having BGP issues in and out of Level3 in the past 30 minutes?
>
> --ScottW



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.....


From ssaner at hubris.net  Fri May 18 15:45:55 2012
From: ssaner at hubris.net (Steven Saner)
Date: Fri, 18 May 2012 15:45:55 -0500
Subject: Level3 Issues
In-Reply-To: <00EF7A2C49DD4A49B732D027E5E728AE18666F75@exchange01.nashville.cybera.net>
References: <00EF7A2C49DD4A49B732D027E5E728AE18666F75@exchange01.nashville.cybera.net>
Message-ID: <4FB6B503.8080703@hubris.net>

On 05/18/2012 03:17 PM, Scott Wolfe wrote:
> Anyone having BGP issues in and out of Level3 in the past 30 minutes?
> 
> --ScottW
> 

No BGP issues via Kansas City, but looks like somewhat less than normal
amount of traffic.

Steve

-- 
--------------------------------------------------------------------------
Steven Saner <ssaner at hubris.net>                      Voice:  316-858-3000
Director of Network Operations                          Fax:  316-858-3001
Hubris Communications                                http://www.hubris.net


From cidr-report at potaroo.net  Fri May 18 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 18 May 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201205182200.q4IM006b046932@wattle.apnic.net>

BGP Update Report
Interval: 10-May-12 -to- 17-May-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            75456  3.6%      62.7 -- BSNL-NIB National Internet Backbone
 2 - AS8402            68093  3.2%      34.6 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS7029            29621  1.4%      13.3 -- WINDSTREAM - Windstream Communications Inc
 4 - AS24560           28898  1.4%      31.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 5 - AS12479           26694  1.3%     381.3 -- UNI2-AS France Telecom Espana SA
 6 - AS32528           24694  1.2%    4938.8 -- ABBOTT Abbot Labs
 7 - AS1785            24617  1.2%      13.2 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 8 - AS8452            20123  0.9%      29.7 -- TE-AS TE-AS
 9 - AS25620           19727  0.9%     116.7 -- COTAS LTDA.
10 - AS5800            19376  0.9%      72.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
11 - AS13118           19205  0.9%     533.5 -- ASN-YARTELECOM OJSC Rostelecom
12 - AS8151            14216  0.7%      17.4 -- Uninet S.A. de C.V.
13 - AS383             12128  0.6%     120.1 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group
14 - AS7552            11929  0.6%      11.8 -- VIETEL-AS-AP Vietel Corporation
15 - AS17974           11779  0.6%       9.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
16 - AS31148           10984  0.5%      15.4 -- FREENET-AS FreeNet ISP
17 - AS36167           10402  0.5%     103.0 -- NETRIPLEX01 - NETRIPLEX LLC
18 - AS11664           10180  0.5%      39.0 -- Techtel LMDS Comunicaciones Interactivas S.A.
19 - AS6503            10176  0.5%      16.8 -- Axtel, S.A.B. de C.V.
20 - AS9583             9985  0.5%      13.6 -- SIFY-AS-IN Sify Limited


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS44798            8115  0.4%    8115.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 2 - AS16652            5809  0.3%    5809.0 -- RISEUP - Riseup Networks
 3 - AS57343            5456  0.3%    5456.0 -- DIGIMAT-AS Digimat s.r.l.
 4 - AS32528           24694  1.2%    4938.8 -- ABBOTT Abbot Labs
 5 - AS20775            2640  0.1%    2640.0 -- GETIT GETIT Internet GmbH
 6 - AS3                2482  0.1%     366.0 -- UMNIAH Umniah Mobile Company
 7 - AS7219             1282  0.1%    1282.0 -- ASNTULIX - Tulix Systems, Inc.
 8 - AS36948            1932  0.1%     966.0 -- KENIC
 9 - AS55665             884  0.0%     884.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia
10 - AS19045            1708  0.1%     854.0 -- DIRECTCOM - Direct Communications Cable LLC
11 - AS21452             795  0.0%     795.0 -- skannet-ibadan
12 - AS42281             794  0.0%     794.0 -- RACHFAHL-IT-AS Rachfahl IT-Solutions GmbH & Co.KG
13 - AS5430             6128  0.3%     766.0 -- FREENETDE freenet Datenkommunikations GmbH
14 - AS29126             746  0.0%     746.0 -- DATIQ-AS Datiq B.V.
15 - AS32890            5134  0.2%     733.4 -- BTC-AS-1 - Beehive Telephone Company, Inc.
16 - AS9821              718  0.0%     718.0 -- DOST-PH-AP Department of Science and Technology
17 - AS40677            1223  0.1%     611.5 -- GLOBALAIR-COM - Globalair.com
18 - AS13263            1767  0.1%     589.0 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S
19 - AS49182            1136  0.1%     568.0 -- BTENGAGEIT BT ENGAGE IT Limited
20 - AS27667             557  0.0%     557.0 -- Universidad Autonoma de la Laguna


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/19   18741  0.8%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 130.36.34.0/24    12339  0.6%   AS32528 -- ABBOTT Abbot Labs
 3 - 130.36.35.0/24    12339  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 41.43.147.0/24     9960  0.4%   AS8452  -- TE-AS TE-AS
 5 - 91.202.212.0/22    8115  0.4%   AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 6 - 62.36.252.0/22     8007  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 7 - 62.36.249.0/24     6467  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 62.36.241.0/24     6066  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 9 - 62.36.210.0/24     5909  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
10 - 199.254.238.0/24   5809  0.3%   AS16652 -- RISEUP - Riseup Networks
11 - 91.231.179.0/24    5456  0.2%   AS57343 -- DIGIMAT-AS Digimat s.r.l.
12 - 194.63.9.0/24      5325  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
13 - 202.56.215.0/24    3582  0.2%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
14 - 69.54.109.0/24     3565  0.2%   AS7018  -- ATT-INTERNET4 - AT&T Services, Inc.
15 - 182.64.0.0/16      3345  0.1%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
16 - 217.194.224.0/20   2640  0.1%   AS20775 -- GETIT GETIT Internet GmbH
17 - 193.105.129.0/24   2482  0.1%   AS3     -- UMNIAH Umniah Mobile Company
18 - 115.170.128.0/17   2353  0.1%   AS4847  -- CNIX-AP China Networks Inter-Exchange
19 - 208.54.82.0/24     2127  0.1%   AS701   -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
20 - 69.31.106.0/23     1987  0.1%   AS35994 -- AKAMAI-AS - Akamai Technologies, 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 18 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 18 May 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201205182200.q4IM00cm046926@wattle.apnic.net>

This report has been generated at Fri May 18 21:12:46 2012 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
        11-05-12    410225      240868
        12-05-12    410475      240522
        13-05-12    410127      241239
        14-05-12    410740      240953
        15-05-12    410599      240761
        16-05-12    410522      241112
        17-05-12    411045      241394
        18-05-12    411873      241338


AS Summary
         41157  Number of ASes in routing system
         17189  Number of ASes announcing only one prefix
          3414  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      112440288  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').

 --- 18May12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     412447   241411   171036    41.5%   All ASes

AS6389      3414      196     3218    94.3%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3407     1889     1518    44.6%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2608     1122     1486    57.0%   KIXS-AS-KR Korea Telecom
AS22773     1607      135     1472    91.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS18566     2094      703     1391    66.4%   COVAD - Covad Communications
                                               Co.
AS28573     1858      497     1361    73.3%   NET Servicos de Comunicao S.A.
AS4323      1585      385     1200    75.7%   TWTC - tw telecom holdings,
                                               inc.
AS10620     1911      805     1106    57.9%   Telmex Colombia S.A.
AS1785      1905      802     1103    57.9%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1577      534     1043    66.1%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7303      1435      446      989    68.9%   Telecom Argentina S.A.
AS7552      1173      224      949    80.9%   VIETEL-AS-AP Vietel
                                               Corporation
AS26615      902       32      870    96.5%   Tim Celular S.A.
AS8151      1486      673      813    54.7%   Uninet S.A. de C.V.
AS18101      947      158      789    83.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS17974     1924     1162      762    39.6%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4808      1109      350      759    68.4%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS9394       834      153      681    81.7%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS13977      770      121      649    84.3%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS2118       658       14      644    97.9%   RELCOM-AS OOO "NPO Relcom"
AS3356      1100      463      637    57.9%   LEVEL3 Level 3 Communications
AS30036     1417      786      631    44.5%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS17676      691       75      616    89.1%   GIGAINFRA Softbank BB Corp.
AS19262      995      398      597    60.0%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS22561     1016      424      592    58.3%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS24560     1027      450      577    56.2%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS4780       832      258      574    69.0%   SEEDNET Digital United Inc.
AS3549      1006      444      562    55.9%   GBLX Global Crossing Ltd.
AS22047      582       31      551    94.7%   VTR BANDA ANCHA S.A.
AS8452      1302      759      543    41.7%   TE-AS TE-AS

Total      43172    14489    28683    66.4%   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-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        27.112.114.0/24      AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        114.134.16.0/20      AS56310 
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        172.14.0.0/24        AS57871 ASTELECENTR TeleCentr Ltd.
        172.15.0.0/24        AS57871 ASTELECENTR TeleCentr Ltd.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.223.60.0/22      AS6910  DIALTELECOMRO Dial Telecom S.R.L.
        194.61.59.0/24       AS49544 INTERACTIVE3D-AS i3d B.V.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.58.113.0/24      AS19161 
        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.122.134.0/24     AS38615 
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel 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.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        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 
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        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.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.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS27876 American Data Networks
        216.194.160.0/20     AS27876 American Data Networks


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 mehmet at akcin.net  Fri May 18 22:33:22 2012
From: mehmet at akcin.net (Mehmet Akcin)
Date: Fri, 18 May 2012 20:33:22 -0700
Subject: NANOG 55 DNS Track
In-Reply-To: <796D6922-297A-4AAC-8C16-5EDB85DE1C57@akcin.net>
References: <796D6922-297A-4AAC-8C16-5EDB85DE1C57@akcin.net>
Message-ID: <BF1D8580-5E10-4BFB-AD25-1D49FEF510C5@akcin.net>

Hello again,

I wanted to follow up and let NANOG community know the detailed plans for DNS Track.

Session will take place on Tuesday, June 5, 2012 from 5:00 PM to 6:30 PM	in Salon A-C

NANOG DNS BoF 90mins

5 Mins Introductions - Mehmet
15 Mins Steve Crocker - Chair, FCC CSRIC Working Group 5, DNSSEC Implementation Practices for ISPs
10 Mins PCH Update - Robert Martin-Leg?ne
10 Mins Verisign Update - Duane Wessels
10 Mins ICANN Update - Dave Knight
10 Mins Comcast Update - Chris Ganster
10 Mins ISC Update - Peter Losher
20 Mins Q&A - regarding presentations & more.

if you have any questions please feel free to contact me, looking forward to see you all there.

Mehmet

On May 2, 2012, at 9:05 AM, Mehmet Akcin wrote:

> Hello everyone,
> 
> NANOG 55 will take place in Vancouver , Canada June 3-6 , 2012. I will send more information about DNS Track timing and details of the track later.
> 
> I am sending this email to ask NANOG attendees to help us organize a better track by letting us know what topics they want to see covered about DNS.
> 
> We are also inviting parties who are DNS Software providers,  service providers, experts, and researchers to join and present about what they think is interesting. Please contact me directly if you want to briefly bring something interesting about DNS to this Track's and their attendees attention. 
> 
> Since the whole track will be 90mins and we want to allow as much as talks to take a place it would be good idea to limit any specific talk to 15 mins and keeping it really operational , brief and clear would be great idea.
> 
> as I said earlier as soon as track details are decided,  I will send a second e-mail to let the community know. thank you for your interest.
> 
> mehmet



From mukom.tamon at gmail.com  Sat May 19 02:50:14 2012
From: mukom.tamon at gmail.com (Mukom Akong T.)
Date: Sat, 19 May 2012 07:50:14 +0000
Subject: need help about bgd and ospf
In-Reply-To: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>
References: <CAAiP322uc5NOrRN1owMsPgj93RiDb8nzicgH5ZWc3MU2gricQw@mail.gmail.com>
Message-ID: <-235908272559486593@unknownmsgid>

Hi Deric,



On May 18, 2012, at 5:14 PM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:

>
> 1/ Do I have to redistrt bgd in ospf to make ospf to know which
> upstrem bgp routers to go out

Just an addition to what the others have already said. Redistributing
BGP into OSPF is rarely an effective thing to do. Am not sure OSPF can
handle that number of routes well.

>
> 2/ If yes, how many routes can ospf database handle as one full bgp
> table is about 400,000 routes
>
> 3/ When we have 8 ospf routers to run "redistrubt bgp", ls it 8 x
> 400,000 routes in ospf database?

I'd think so, as each of the 8 routers will generate type 5 LSAs for
their 400k routes from BGP.

>
> 4/ If not redistribted bgp, how ospf to know which upstream to go out

More important question is why do u want OSPF to know that
information? Is it the right protocol to do that?

>
> Thank you for your help
>


From me at anuragbhatia.com  Sat May 19 05:23:02 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Sat, 19 May 2012 15:53:02 +0530
Subject: Peer1/Server Beach support for BGP on dedicated servers
Message-ID: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>

Hello everyone


Was wondering if there's anyone from Server Beach/Peer1 here. We have a
dedicated server with them which we primarily use for DNS. I am adding
support for anycasting on that one but seems like Peer1 is not supporting
BGP at all. NOC support told me that they can announce our block
and statically pass us but cannot hear BGP announcement from our router.
Was wondering if someone else had similar issue?

This is important and if doesn't works then I would have to find a new
place for dedicated server somewhere in California.




Thanks!

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From jof at thejof.com  Sat May 19 05:48:48 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Sat, 19 May 2012 03:48:48 -0700
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
Message-ID: <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>

On Sat, May 19, 2012 at 3:23 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Was wondering if there's anyone from Server Beach/Peer1 here. We have a
> dedicated server with them which we primarily use for DNS. I am adding
> support for anycasting on that one but seems like Peer1 is not supporting
> BGP at all. NOC support told me that they can announce our block
> and statically pass us but cannot hear BGP announcement from our router.
> Was wondering if someone else had similar issue?

Generally, most dedicated hosting (renting/leasing the exclusive use
of a computer in their facility) outfits aren't setup to speak BGP to
individual servers/customers. Such a request is usually infrequent
enough that it doesn't warrant setting up the added hardware.

While you could have your provider announce your space for you, you'll
loose the fine-grained control over how that route gets announced once
the routing is out of your hands.

> This is important and if doesn't works then I would have to find a new
> place for dedicated server somewhere in California.

I would instead recommend looking for a colocation provider that will
host small installations (1 - 5 U), but is also savvy enough to speak
eBGP with their customers.

Cheers,
jof


From ahebert at pubnix.net  Sat May 19 06:56:51 2012
From: ahebert at pubnix.net (Alain Hebert)
Date: Sat, 19 May 2012 07:56:51 -0400 (EDT)
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
Message-ID: <5110.72.0.196.98.1337428611.squirrel@mail.pubnix.net>

> On Sat, May 19, 2012 at 3:23 AM, Anurag Bhatia <me at anuragbhatia.com>
> wrote:
>> Was wondering if there's anyone from Server Beach/Peer1 here. We have a
>> dedicated server with them which we primarily use for DNS. I am adding
>> support for anycasting on that one but seems like Peer1 is not
>> supporting
>> BGP at all. NOC support told me that they can announce our block
>> and statically pass us but cannot hear BGP announcement from our router.
>> Was wondering if someone else had similar issue?
>
> Generally, most dedicated hosting (renting/leasing the exclusive use
> of a computer in their facility) outfits aren't setup to speak BGP to
> individual servers/customers. Such a request is usually infrequent
> enough that it doesn't warrant setting up the added hardware.
>
> While you could have your provider announce your space for you, you'll
> loose the fine-grained control over how that route gets announced once
> the routing is out of your hands.
>
>> This is important and if doesn't works then I would have to find a new
>> place for dedicated server somewhere in California.
>
> I would instead recommend looking for a colocation provider that will
> host small installations (1 - 5 U), but is also savvy enough to speak
> eBGP with their customers.
>
> Cheers,
> jof
>
>

Hi,

Knowing Peer1, they *may be* accommodating enough to provide you with
something.

Are you talking only to server beach support?

PS: Yes, your need are a bit different from their usual customers =D

( I wont make a shameless plug ... )



From sethm at rollernet.us  Sat May 19 11:20:02 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Sat, 19 May 2012 09:20:02 -0700
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
Message-ID: <4FB7C832.6060106@rollernet.us>

On 5/19/12 3:48 AM, Jonathan Lassoff wrote:
> On Sat, May 19, 2012 at 3:23 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>> Was wondering if there's anyone from Server Beach/Peer1 here. We have a
>> dedicated server with them which we primarily use for DNS. I am adding
>> support for anycasting on that one but seems like Peer1 is not supporting
>> BGP at all. NOC support told me that they can announce our block
>> and statically pass us but cannot hear BGP announcement from our router.
>> Was wondering if someone else had similar issue?
> 
> Generally, most dedicated hosting (renting/leasing the exclusive use
> of a computer in their facility) outfits aren't setup to speak BGP to
> individual servers/customers. Such a request is usually infrequent
> enough that it doesn't warrant setting up the added hardware.
> 


There are places that can do such requests easily and quickly, but
they're typically smaller outfits that don't have thousands of customers
doing cookie-cutter packages.

~Seth


From woody at pch.net  Sat May 19 13:19:24 2012
From: woody at pch.net (Bill Woodcock)
Date: Sat, 19 May 2012 11:19:24 -0700
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <4FB7C832.6060106@rollernet.us>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
Message-ID: <03883C89-6A31-4F32-917C-B8616840B078@pch.net>


Any recommendations of such?

    
                -Bill


On May 19, 2012, at 9:20, "Seth Mattinen" <sethm at rollernet.us> wrote:

> On 5/19/12 3:48 AM, Jonathan Lassoff wrote:
>> On Sat, May 19, 2012 at 3:23 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>>> Was wondering if there's anyone from Server Beach/Peer1 here. We have a
>>> dedicated server with them which we primarily use for DNS. I am adding
>>> support for anycasting on that one but seems like Peer1 is not supporting
>>> BGP at all. NOC support told me that they can announce our block
>>> and statically pass us but cannot hear BGP announcement from our router.
>>> Was wondering if someone else had similar issue?
>> 
>> Generally, most dedicated hosting (renting/leasing the exclusive use
>> of a computer in their facility) outfits aren't setup to speak BGP to
>> individual servers/customers. Such a request is usually infrequent
>> enough that it doesn't warrant setting up the added hardware.
>> 
> 
> 
> There are places that can do such requests easily and quickly, but
> they're typically smaller outfits that don't have thousands of customers
> doing cookie-cutter packages.
> 
> ~Seth
> 



From erplefoo at gmail.com  Sat May 19 16:15:46 2012
From: erplefoo at gmail.com (Sean Davis)
Date: Sat, 19 May 2012 16:15:46 -0500
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
Message-ID: <FCE602CE-20F7-4497-90A9-F1363350229C@gmail.com>

Peer1/SB employee here -

(disclaimer: I'm really in security, not networking)

I imagine this would be technically possible, but I have no clue as to whether it is something we could offer or not. If you like, feel free to contact me off-list and I'll forward your questions/requirements along to those who can provide a better answer.

- Sean

Sent from a portable typo transmitter

On May 19, 2012, at 5:23, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Hello everyone
> 
> 
> Was wondering if there's anyone from Server Beach/Peer1 here. We have a
> dedicated server with them which we primarily use for DNS. I am adding
> support for anycasting on that one but seems like Peer1 is not supporting
> BGP at all. NOC support told me that they can announce our block
> and statically pass us but cannot hear BGP announcement from our router.
> Was wondering if someone else had similar issue?
> 
> This is important and if doesn't works then I would have to find a new
> place for dedicated server somewhere in California.
> 
> 
> 
> 
> Thanks!
> 
> -- 
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>


From asr at latency.net  Sat May 19 21:24:49 2012
From: asr at latency.net (Adam Rothschild)
Date: Sat, 19 May 2012 22:24:49 -0400
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us> <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
Message-ID: <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>

http://www.voxel.net offers web-orderable servers and VMs, with BGP
support (IPv4 and IPv6) available as a paid add-on in all service
locations.

I'm honestly surprised we don't see this supported by more folk in the
space.  The configuration is relatively trivial to automate, with IRR
data generating prefix-list updates, and the customer use cases are
compelling.

HTH,
-a

(disclaimer: biased recommendation)

On Sat, May 19, 2012 at 2:19 PM, Bill Woodcock <woody at pch.net> wrote:
>
> Any recommendations of such?
>
>
> ? ? ? ? ? ? ? ?-Bill
>
>
> On May 19, 2012, at 9:20, "Seth Mattinen" <sethm at rollernet.us> wrote:
>
>> On 5/19/12 3:48 AM, Jonathan Lassoff wrote:
>>> On Sat, May 19, 2012 at 3:23 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
>>>> Was wondering if there's anyone from Server Beach/Peer1 here. We have a
>>>> dedicated server with them which we primarily use for DNS. I am adding
>>>> support for anycasting on that one but seems like Peer1 is not supporting
>>>> BGP at all. NOC support told me that they can announce our block
>>>> and statically pass us but cannot hear BGP announcement from our router.
>>>> Was wondering if someone else had similar issue?
>>>
>>> Generally, most dedicated hosting (renting/leasing the exclusive use
>>> of a computer in their facility) outfits aren't setup to speak BGP to
>>> individual servers/customers. Such a request is usually infrequent
>>> enough that it doesn't warrant setting up the added hardware.
>>>
>>
>>
>> There are places that can do such requests easily and quickly, but
>> they're typically smaller outfits that don't have thousands of customers
>> doing cookie-cutter packages.
>>
>> ~Seth
>>
>
>


From steve.bertrand at gmail.com  Sun May 20 16:04:41 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Sun, 20 May 2012 15:04:41 -0600
Subject: Commerical Backup Solutions
In-Reply-To: <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
Message-ID: <4FB95C69.7080709@gmail.com>

On 2012-05-17 16:59, Mike Lyon wrote:
> We used Acronis and it was a nightmare as was their off-shored support
> model. Never again... Wouldn't touch them with a 10 foot pole.
>
> Switched to Iron Mountain LiveVault which backs everything up over the
> wire. It has basic reporting functions but not extremely granular.
> http://ironmountain.com/services/democenter/livevault/player.html

Does Iron Mountain LiveVault allow for bare metal restorations? I didn't 
see it after gleaning the site.

In my new job, we're using BackupExec pulling the data from ~100 servers 
to a SAN and then to tape. Iron Mountain comes in every day to to 
replace our tapes for offsite storage.

For the few boxes we have that aren't configured in HA pairs or 
clusters, we periodically do a snapshot with Acronis specifically for 
the bare metal restoration ability.

Steve


From mike.lyon at gmail.com  Sun May 20 16:20:26 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 20 May 2012 14:20:26 -0700
Subject: Commerical Backup Solutions
In-Reply-To: <4FB95C69.7080709@gmail.com>
References: <339801cd347f$de562190$9b0264b0$@paulstewart.org>
 <CAFFgAjA-P5d=CSBCGfbnfneKc1ga_je=9W7iZzSNRXt0u1m9uQ@mail.gmail.com>
 <4FB95C69.7080709@gmail.com>
Message-ID: <3695809685719300409@unknownmsgid>

I dont think the livevault solution offers for bare metal backups.
Tthey may if you have their appliance but not sure.

-mike

Sent from my iPhone

On May 20, 2012, at 14:04, Steve Bertrand <steve.bertrand at gmail.com> wrote:

> On 2012-05-17 16:59, Mike Lyon wrote:
>> We used Acronis and it was a nightmare as was their off-shored support
>> model. Never again... Wouldn't touch them with a 10 foot pole.
>>
>> Switched to Iron Mountain LiveVault which backs everything up over the
>> wire. It has basic reporting functions but not extremely granular.
>> http://ironmountain.com/services/democenter/livevault/player.html
>
> Does Iron Mountain LiveVault allow for bare metal restorations? I didn't see it after gleaning the site.
>
> In my new job, we're using BackupExec pulling the data from ~100 servers to a SAN and then to tape. Iron Mountain comes in every day to to replace our tapes for offsite storage.
>
> For the few boxes we have that aren't configured in HA pairs or clusters, we periodically do a snapshot with Acronis specifically for the bare metal restoration ability.
>
> Steve


From stefan.jakob at de-cix.net  Mon May 21 08:36:50 2012
From: stefan.jakob at de-cix.net (Stefan Jakob)
Date: Mon, 21 May 2012 15:36:50 +0200
Subject: IPv6 aggregation tool
In-Reply-To: <CALWyk_AxMj8C8GuR9-R2hUbpfoZ1FwkH0B=f7-g3puu=z1wZDQ@mail.gmail.com>
References: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
 <CALWyk_AxMj8C8GuR9-R2hUbpfoZ1FwkH0B=f7-g3puu=z1wZDQ@mail.gmail.com>
Message-ID: <4FBA44F2.9000109@de-cix.net>

Am 04.05.12 03:35, schrieb Rafael Rodriguez:
> Found this tool that works perfectly.
> 
> http://zwitterion.org/software/aggregate-cidr-addresses/aggregate-cidr-addresses
> 
> Hoping this'll help someone else here on the list.  Thanks!

Thx, this is at least three times faster than what I have here.


Just a comment on the final print statement, which doesn't fit my needs
for ipv6:


-    print "prefix: ", $_->prefix(), "\n";
+    print "print: " , $_->print(), "\n";


- prefix: 2001:0db8:0000:0000:0000:0000:0000:0000/32
+ print: 2001:db8::/32


Rgds, Stefan


From DOUGANLA at gru.com  Mon May 21 09:09:05 2012
From: DOUGANLA at gru.com (Dougan, Linda A)
Date: Mon, 21 May 2012 10:09:05 -0400
Subject: Iphone App that Scans IT equipment for Inventory
In-Reply-To: <4EB83110.6050302@gmail.com>
References: <4EB6CB74.6060003@gmail.com>
 <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
 <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>
 <4EB83110.6050302@gmail.com>
Message-ID: <C4DFC6F4A399A24AACCE645EE506F7F10127C4AE0582@GRUE2K7CCR.gruadmin.gru.com>

Does anyone know of an Iphone App that works for scanning manufacturer barcodes  of IT
equipment such as routers and switches and can be used for inventory?

?
?
?



?
?
Linda 



From andre at operations.net  Mon May 21 09:32:58 2012
From: andre at operations.net (Andre Gironda)
Date: Mon, 21 May 2012 20:02:58 +0530
Subject: Iphone App that Scans IT equipment for Inventory
In-Reply-To: <C4DFC6F4A399A24AACCE645EE506F7F10127C4AE0582@GRUE2K7CCR.gruadmin.gru.com>
References: <4EB6CB74.6060003@gmail.com>
 <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
 <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>
 <4EB83110.6050302@gmail.com>
 <C4DFC6F4A399A24AACCE645EE506F7F10127C4AE0582@GRUE2K7CCR.gruadmin.gru.com>
Message-ID: <CALKBUgjYrxb+OxwvtsktUm5zmQ_1kgb454ty3ZSAQ+DgiuPTOw@mail.gmail.com>

On Mon, May 21, 2012 at 7:39 PM, Dougan, Linda A <DOUGANLA at gru.com> wrote:
> Does anyone know of an Iphone App that works for scanning manufacturer barcodes ?of IT
> equipment such as routers and switches and can be used for inventory?

iNet Pro.

For Android, try Fing

dre


From jay at miscreant.org  Mon May 21 10:19:51 2012
From: jay at miscreant.org (Jay Mitchell)
Date: Tue, 22 May 2012 01:19:51 +1000
Subject: Iphone App that Scans IT equipment for Inventory
In-Reply-To: <CALKBUgjYrxb+OxwvtsktUm5zmQ_1kgb454ty3ZSAQ+DgiuPTOw@mail.gmail.com>
References: <4EB6CB74.6060003@gmail.com>
 <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
 <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>
 <4EB83110.6050302@gmail.com>
 <C4DFC6F4A399A24AACCE645EE506F7F10127C4AE0582@GRUE2K7CCR.gruadmin.gru.com>
 <CALKBUgjYrxb+OxwvtsktUm5zmQ_1kgb454ty3ZSAQ+DgiuPTOw@mail.gmail.com>
Message-ID: <69D78752-8136-4417-9197-419333DA0F51@miscreant.org>

Isn't iNet Pro for scanning devices attached to a network rather than for scanning physical barcodes on devices?

Kind regards,

Jay

On 22/05/2012, at 12:32 AM, Andre Gironda <andre at operations.net> wrote:

> On Mon, May 21, 2012 at 7:39 PM, Dougan, Linda A <DOUGANLA at gru.com> wrote:
>> Does anyone know of an Iphone App that works for scanning manufacturer barcodes  of IT
>> equipment such as routers and switches and can be used for inventory?
> 
> iNet Pro.
> 
> For Android, try Fing
> 
> dre
> 


From mikea at mikea.ath.cx  Mon May 21 10:58:16 2012
From: mikea at mikea.ath.cx (Mike Andrews)
Date: Mon, 21 May 2012 10:58:16 -0500
Subject: Iphone App that Scans IT equipment for Inventory
In-Reply-To: <69D78752-8136-4417-9197-419333DA0F51@miscreant.org>
References: <4EB6CB74.6060003@gmail.com>
 <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
 <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>
 <4EB83110.6050302@gmail.com>
 <C4DFC6F4A399A24AACCE645EE506F7F10127C4AE0582@GRUE2K7CCR.gruadmin.gru.com>
 <CALKBUgjYrxb+OxwvtsktUm5zmQ_1kgb454ty3ZSAQ+DgiuPTOw@mail.gmail.com>
 <69D78752-8136-4417-9197-419333DA0F51@miscreant.org>
Message-ID: <20120521155816.GA28913@mikea.ath.cx>

On Tue, May 22, 2012 at 01:19:51AM +1000, Jay Mitchell wrote:
> On 22/05/2012, at 12:32 AM, Andre Gironda <andre at operations.net> wrote:
> 
> > On Mon, May 21, 2012 at 7:39 PM, Dougan, Linda A <DOUGANLA at gru.com> wrote:
> >> Does anyone know of an Iphone App that works for scanning manufacturer barcodes  of IT
> >> equipment such as routers and switches and can be used for inventory?
> > 
> > iNet Pro.

> Isn't iNet Pro for scanning devices attached to a network rather than for scanning physical barcodes on devices?
> 
> Kind regards,

That's what the App Store entry for inet Pro tells me -- nothing to do
with optical scanning of barcodes at all, AFAICS. 

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin 


From sh.vahabzadeh at gmail.com  Mon May 21 14:48:55 2012
From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh)
Date: Tue, 22 May 2012 00:18:55 +0430
Subject: OSS Systems
In-Reply-To: <1326670811.98616415@apps.rackspace.com>
References: <CAGqGmqbZa8FMxgZErf9v9hJ6wNzN3=GhC9Su44+m1Ah6h0rdEA@mail.gmail.com>
 <6E5615AD-CD76-4599-8164-2B6B41687751@ukbroadband.com>
 <CAGqGmqZbaKcuBe8hx_jWKnkN4wydRz66DoGKyuAYJr3rt_zhMA@mail.gmail.com>
 <1326670811.98616415@apps.rackspace.com>
Message-ID: <CAGqGmqZ+pbTBY8yC-0a7XGOFH48SCpkmsaYV_vtaZsJDc06iSA@mail.gmail.com>

On Mon, Jan 16, 2012 at 3:10 AM, <khatfield at socllc.net> wrote:

> My personal opinion has been that we have seen great success in large
> environments with FreeRadius and using radrelay for mysql synchronization
> then an OpenLDAP-backend. We used FreeBSD/CARP and/or FreeVRRPd for
> failover but this can be accomplished in other methods.
>
> FreeRadius has a built-in CLUSTERIP module which allows
> clustering/load-balancing/failover or you could AnyCast the systems for
> redundancy.
>
> As for load balancing other Radius servers which may not have it built in
> - I would say a hardware solution is usually great because you get support,
> etc. However, if you don't need the support then there are a ton of options
> available. You could go as far as load balancing it with LVS (which I
> personally do not like but MANY do :)) or software load balancers like
> pen/pound/haproxy.
>
> Best of luck!
>
> -----Original Message-----
> From: "Shahab Vahabzadeh" <sh.vahabzadeh at gmail.com>
> Sent: Sunday, January 15, 2012 4:26pm
> To: "Leigh Porter" <leigh.porter at ukbroadband.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: OSS Systems
>
> Hi there again,
> I think Leigh is not available this week, anybody else idea about such a
> system?
> Which loadbalancer is good to use? LVS or hardware one? or radius as a
> proxy?
> How database must be placed? How radius servers talk to DB?
> And which radius server you suggest? Radiator?
> Thanks
>
> On Fri, Jan 6, 2012 at 1:45 AM, Leigh Porter
> <leigh.porter at ukbroadband.com>wrote:
>
> >
> >
> > On 5 Jan 2012, at 22:02, "Shahab Vahabzadeh" <sh.vahabzadeh at gmail.com>
> > wrote:
> >
> > > Hi there,
> > > Has anybody experience about running and OSS System in enterprise
> level?
> > > And do you have any idea about it?
> > > For example for an ISP who is running users more than 20K or 30K, there
> > > must be some good solutions to integrate all systems like:
> > > Radius, Billing Systems and CRM
> > > For example after searching and asking friends I have some ideas about
> > > Radius to use: radiator
> > > Is there anybody who has analyse such a systems before in his ISP? Need
> > > sharing here :)
> > > Thanks
> >
> > We did this a few years ago and ended up writing the while thing
> > ourselves. This included billing, subscriber management etc etc.
> >
> > We integrates to salesforce.com for the internal front end and the user
> > facing stuff we did ourselves.
> >
> > It was a big project and took a team of six about six months. But we
> ended
> > up with a perfect solution that did exactly what we needed and it was
> > pretty good.
> >
> > It handled within the order of users you mention, but we designed to 100k
> > users.
> >
> > We used radiator (highly recommended) with openldap back end. Multiple
> > load balanced servers etc etc.
> >
> > The worst thing we did was to build our own mail system. Not that it was
> > an issue, it never went wrong, but these days I'd just send people to
> gmail
> > or something.
> >
> > --
> > Leigh Porter
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the Symantec Email Security.cloud service.
> > For more information please visit http://www.symanteccloud.com
> > ______________________________________________________________________
> >
>
>
>
> --
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
>
> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90
>
>
>
>
>
>
Hi there again,
About this solution can anybody help about the best partition layout for
these machines?
For such a OSS system we need these 4 machine and having best partition
layout for them is important for example maybe we need a big /var/log for
Radius Server and etc.

   1. Load Balancer (ipvs)
   2. Radius Server (radiator/freeradius)
   3. Database Server (mysqld)
   4. Web Server for Billing (apache2)

Thanks


-- 
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

Cell Phone: +1 (415) 871 0742
PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

From josephgregoryguerra28 at gmail.com  Mon May 21 19:21:53 2012
From: josephgregoryguerra28 at gmail.com (joseph guerra)
Date: Mon, 21 May 2012 19:21:53 -0500
Subject: No subject
Message-ID: <CAO2fnTGrkLho_17oA8gLDtATdQo+8xzSdi2NU5WY5mKh=nTicw@mail.gmail.com>



From josephgregoryguerra28 at gmail.com  Mon May 21 19:21:58 2012
From: josephgregoryguerra28 at gmail.com (joseph guerra)
Date: Mon, 21 May 2012 19:21:58 -0500
Subject: No subject
Message-ID: <CAO2fnTEFYBw2ZRpODPs0M=Of08VYFsnae+dw5u5x8bDkH5QRRQ@mail.gmail.com>



From jay at west.net  Mon May 21 22:01:02 2012
From: jay at west.net (Jay Hennigan)
Date: Mon, 21 May 2012 20:01:02 -0700
Subject: Spam from inteliquent.com subject "nanog"
Message-ID: <4FBB016E.9000803@west.net>

Anyone else just get this?  Curious if they're scraping this list for
addresses.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From paul at paulstewart.org  Tue May 22 05:25:08 2012
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 22 May 2012 06:25:08 -0400
Subject: Spam from inteliquent.com subject "nanog"
In-Reply-To: <4FBB016E.9000803@west.net>
References: <4FBB016E.9000803@west.net>
Message-ID: <39a901cd3805$2b86f830$8294e890$@paulstewart.org>

Nothing here for what it's worth....

Paul


-----Original Message-----
From: Jay Hennigan [mailto:jay at west.net] 
Sent: Monday, May 21, 2012 11:01 PM
To: nanog at nanog.org
Subject: Spam from inteliquent.com subject "nanog"

Anyone else just get this?  Curious if they're scraping this list for
addresses.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse
Internet Service  -  http://www.impulse.net/ Your local telephone and
internet company - 805 884-6323 - WB6RDV




From ahebert at pubnix.net  Tue May 22 06:54:06 2012
From: ahebert at pubnix.net (Alain Hebert)
Date: Tue, 22 May 2012 07:54:06 -0400
Subject: Spam from inteliquent.com subject "nanog"
In-Reply-To: <39a901cd3805$2b86f830$8294e890$@paulstewart.org>
References: <4FBB016E.9000803@west.net>
 <39a901cd3805$2b86f830$8294e890$@paulstewart.org>
Message-ID: <4FBB7E5E.40908@pubnix.net>

     Same.  Nothing here.

     Maybe someone at Tiscali/Tinet where fixing their mailing with 
their new name and made an error.

On that subject...

     What kind of trouble Tiscali/Tinet got into to pull an "Arthur 
Anderson" and change their name to "Inteliquent"?

     Context: "Arthur Anderson" changed their name to "Accenture" (yuck) 
after that unfortunate incident.

     PS: I know they merge =D I'm just not a big fan of their new name.

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443


On 05/22/12 06:25, Paul Stewart wrote:
> Nothing here for what it's worth....
>
> Paul
>
>
> -----Original Message-----
> From: Jay Hennigan [mailto:jay at west.net]
> Sent: Monday, May 21, 2012 11:01 PM
> To: nanog at nanog.org
> Subject: Spam from inteliquent.com subject "nanog"
>
> Anyone else just get this?  Curious if they're scraping this list for
> addresses.
>
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse
> Internet Service  -  http://www.impulse.net/ Your local telephone and
> internet company - 805 884-6323 - WB6RDV
>
>
>
>


From oscar.vives at gmail.com  Tue May 22 12:06:41 2012
From: oscar.vives at gmail.com (Tei)
Date: Tue, 22 May 2012 10:06:41 -0700
Subject: this NANOG wiki is getting spammed
Message-ID: <CACg3zYEMoRJ5Hz+FrPjNi4-Es0MOeBnZCeD8R937FH21MT2-yA@mail.gmail.com>

I don't think this is the official nanog wiki, but anyway probably the
owners are on this mail list.

Spammers is wasting everyone time by filling it with crap.
http://nanog.cluepon.net/index.php/Special:RecentChanges

-- 
--
?in del ?ensaje.


.
.
.
.
.
















































postdata:
Blizzard is getting strange slower speeds for some customers (300ms
ping, wen other have a normal of 100ms). I blame this in evil ISP's
doing evil things, or routing problems. Ignore this line.


From packetjockey at gmail.com  Tue May 22 13:02:48 2012
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Tue, 22 May 2012 14:02:48 -0400
Subject: IPv6 aggregation tool
In-Reply-To: <4FBA44F2.9000109@de-cix.net>
References: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
 <CALWyk_AxMj8C8GuR9-R2hUbpfoZ1FwkH0B=f7-g3puu=z1wZDQ@mail.gmail.com>
 <4FBA44F2.9000109@de-cix.net>
Message-ID: <6EFA3E54-D989-487B-87A7-A3F1A622B606@gmail.com>

:) thanks! Was wondering how to do that.

Sent from my iPhone

On May 21, 2012, at 9:36, Stefan Jakob <stefan.jakob at de-cix.net> wrote:

> Am 04.05.12 03:35, schrieb Rafael Rodriguez:
>> Found this tool that works perfectly.
>> 
>> http://zwitterion.org/software/aggregate-cidr-addresses/aggregate-cidr-addresses
>> 
>> Hoping this'll help someone else here on the list.  Thanks!
> 
> Thx, this is at least three times faster than what I have here.
> 
> 
> Just a comment on the final print statement, which doesn't fit my needs
> for ipv6:
> 
> 
> -    print "prefix: ", $_->prefix(), "\n";
> +    print "print: " , $_->print(), "\n";
> 
> 
> - prefix: 2001:0db8:0000:0000:0000:0000:0000:0000/32
> + print: 2001:db8::/32
> 
> 
> Rgds, Stefan
> 


From m.hallgren at free.fr  Tue May 22 13:18:27 2012
From: m.hallgren at free.fr (Michael Hallgren)
Date: Tue, 22 May 2012 20:18:27 +0200
Subject: IPv6 aggregation tool
In-Reply-To: <6EFA3E54-D989-487B-87A7-A3F1A622B606@gmail.com>
References: <CALWyk_DkjNE4Y-PK9NY3TtEK+BUaL-XWEqAzXGDMhTNNV9u_pw@mail.gmail.com>
 <CALWyk_AxMj8C8GuR9-R2hUbpfoZ1FwkH0B=f7-g3puu=z1wZDQ@mail.gmail.com>
 <4FBA44F2.9000109@de-cix.net>
 <6EFA3E54-D989-487B-87A7-A3F1A622B606@gmail.com>
Message-ID: <1337710707.2903.2.camel@home>

Le mardi 22 mai 2012 ? 14:02 -0400, Rafael Rodriguez a ?crit :
> :) thanks! Was wondering how to do that.

$ perldoc Net::IP ;) That doc's a fine one to read also for other
reasons.

Cheers,

mh

> 
> Sent from my iPhone
> 
> On May 21, 2012, at 9:36, Stefan Jakob <stefan.jakob at de-cix.net> wrote:
> 
> > Am 04.05.12 03:35, schrieb Rafael Rodriguez:
> >> Found this tool that works perfectly.
> >> 
> >> http://zwitterion.org/software/aggregate-cidr-addresses/aggregate-cidr-addresses
> >> 
> >> Hoping this'll help someone else here on the list.  Thanks!
> > 
> > Thx, this is at least three times faster than what I have here.
> > 
> > 
> > Just a comment on the final print statement, which doesn't fit my needs
> > for ipv6:
> > 
> > 
> > -    print "prefix: ", $_->prefix(), "\n";
> > +    print "print: " , $_->print(), "\n";
> > 
> > 
> > - prefix: 2001:0db8:0000:0000:0000:0000:0000:0000/32
> > + print: 2001:db8::/32
> > 
> > 
> > Rgds, Stefan
> > 
> 




From simon.perreault at viagenie.ca  Tue May 22 13:21:30 2012
From: simon.perreault at viagenie.ca (Simon Perreault)
Date: Tue, 22 May 2012 14:21:30 -0400
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
 <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
 <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>
Message-ID: <4FBBD92A.1030500@viagenie.ca>

On 2012-05-19 22:24, Adam Rothschild wrote:
> http://www.voxel.net offers web-orderable servers and VMs, with BGP
> support (IPv4 and IPv6) available as a paid add-on in all service
> locations.

Is this publicly advertised or do you have to ask for it? I can't find 
anything about BGP on their web site...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


From JMcKenna at intelletrace.com  Tue May 22 14:02:46 2012
From: JMcKenna at intelletrace.com (J.J. Mc Kenna)
Date: Tue, 22 May 2012 19:02:46 +0000
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <4FBBD92A.1030500@viagenie.ca>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
 <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
 <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>
 <4FBBD92A.1030500@viagenie.ca>
Message-ID: <EAE75C548B908C4A99AC6D86C2A2F7620C8D0B39@CH1PRD0710MB367.namprd07.prod.outlook.com>

http://www.voxel.net/assets/VoxCAST-Whitepaper.pdf



J.J.????


-----Original Message-----
From: Simon Perreault [mailto:simon.perreault at viagenie.ca] 
Sent: Tuesday, May 22, 2012 11:22 AM
To: nanog at nanog.org
Subject: Re: Peer1/Server Beach support for BGP on dedicated servers

On 2012-05-19 22:24, Adam Rothschild wrote:
> http://www.voxel.net offers web-orderable servers and VMs, with BGP 
> support (IPv4 and IPv6) available as a paid add-on in all service 
> locations.

Is this publicly advertised or do you have to ask for it? I can't find anything about BGP on their web site...

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca





From morrowc.lists at gmail.com  Tue May 22 14:08:38 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 May 2012 15:08:38 -0400
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <EAE75C548B908C4A99AC6D86C2A2F7620C8D0B39@CH1PRD0710MB367.namprd07.prod.outlook.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
 <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
 <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>
 <4FBBD92A.1030500@viagenie.ca>
 <EAE75C548B908C4A99AC6D86C2A2F7620C8D0B39@CH1PRD0710MB367.namprd07.prod.outlook.com>
Message-ID: <CAL9jLaYMF19jxRn4J0aeDDEsyXCTrEwKUOPaST8ROGjhOGNaBQ@mail.gmail.com>

On Tue, May 22, 2012 at 3:02 PM, J.J. Mc Kenna
<JMcKenna at intelletrace.com> wrote:
> http://www.voxel.net/assets/VoxCAST-Whitepaper.pdf

that does mention bgp, but not in the context of 'make my server do
bgp with the voxel network equipment'... in the context of: "If you
setup a cdn you need to speak bgp".

I don't see a clicky-box on the voxel server (dedicated hosting)
configuration and pricing page for 'add the bgp to my server, pls.'.

-chris

> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault at viagenie.ca]
> Sent: Tuesday, May 22, 2012 11:22 AM
> To: nanog at nanog.org
> Subject: Re: Peer1/Server Beach support for BGP on dedicated servers
>
> On 2012-05-19 22:24, Adam Rothschild wrote:
>> http://www.voxel.net offers web-orderable servers and VMs, with BGP
>> support (IPv4 and IPv6) available as a paid add-on in all service
>> locations.
>
> Is this publicly advertised or do you have to ask for it? I can't find anything about BGP on their web site...
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source ? ? ? ?--> http://ecdysis.viagenie.ca
> STUN/TURN server ? ? ? ? ? ? ? --> http://numb.viagenie.ca
>
>
>
>


From simon.perreault at viagenie.ca  Tue May 22 14:13:54 2012
From: simon.perreault at viagenie.ca (Simon Perreault)
Date: Tue, 22 May 2012 15:13:54 -0400
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <EAE75C548B908C4A99AC6D86C2A2F7620C8D0B39@CH1PRD0710MB367.namprd07.prod.outlook.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
 <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
 <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>
 <4FBBD92A.1030500@viagenie.ca>
 <EAE75C548B908C4A99AC6D86C2A2F7620C8D0B39@CH1PRD0710MB367.namprd07.prod.outlook.com>
Message-ID: <4FBBE572.7040404@viagenie.ca>

On 2012-05-22 15:02, J.J. Mc Kenna wrote:
> http://www.voxel.net/assets/VoxCAST-Whitepaper.pdf

This is not what I would call "BGP support". It's just a CDN.

Thanks,
Simon

> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault at viagenie.ca]
> Sent: Tuesday, May 22, 2012 11:22 AM
> To: nanog at nanog.org
> Subject: Re: Peer1/Server Beach support for BGP on dedicated servers
>
> On 2012-05-19 22:24, Adam Rothschild wrote:
>> http://www.voxel.net offers web-orderable servers and VMs, with BGP
>> support (IPv4 and IPv6) available as a paid add-on in all service
>> locations.
>
> Is this publicly advertised or do you have to ask for it? I can't find anything about BGP on their web site...

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


From cmarlatt at rxsec.com  Tue May 22 15:52:40 2012
From: cmarlatt at rxsec.com (Chris Marlatt)
Date: Tue, 22 May 2012 16:52:40 -0400
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
 <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
Message-ID: <4FBBFC98.6070904@rxsec.com>

On 05/19/2012 02:19 PM, Bill Woodcock wrote:
>
> Any recommendations of such?
>
>
>                  -Bill

I know of a datacenter down in the Carolinas that will do such a setup 
for those sufficiently clued. Hit me up off list if you're interested in 
their details.

Regards,

	Chris


From paul.porter at gree.co.jp  Tue May 22 18:00:21 2012
From: paul.porter at gree.co.jp (Paul Porter)
Date: Tue, 22 May 2012 16:00:21 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
Message-ID: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>

Hi NANOG,

I'm looking for some information on the four largest US mobile phone
carriers and the current state of their IPv6 infrastructure. Specifically,
we are trying to figure out:

1.  How much of the carrier core and edge for AT&T, Verizon. T-Mobile, and
Sprint are on IPv6 now?
2.  If, and how, are they handling NAT64 for native IPv6 edge devices?
3. What is the percentage of breakdown for users on native IPv6? Dual
stacked?

GREE is a mobile social gaming company and we're trying to better
understand what lies between our customer's smart phones and our servers.
My next step will be to reach out to the carriers themselves, but I figured
many of their Network Engineers are probably on the NANOG mailing list and
this would be a great place to start.

Thanks in advance for your time and assistance.

Sincerely,

- Paul Porter

-- 
*Paul G. Porter
*GREE International | Network Engineer
CCNP, CCSP, JNCIS-FWV, JNCIA-Junos
E-mail: paul.porter at gree.net
Mobile: (510) 371-1147
Twitter: paul_g_porter

From cb.list6 at gmail.com  Tue May 22 18:21:44 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 22 May 2012 16:21:44 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
Message-ID: <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>

On May 22, 2012 4:00 PM, "Paul Porter" <paul.porter at gree.co.jp> wrote:
>
> Hi NANOG,
>
> I'm looking for some information on the four largest US mobile phone
> carriers and the current state of their IPv6 infrastructure. Specifically,
> we are trying to figure out:
>
> 1.  How much of the carrier core and edge for AT&T, Verizon. T-Mobile, and
> Sprint are on IPv6 now?

Hi,

T-Mobile USA has native ipv6 to all subscribers in all of it's coverage
area. But, less than 1% of subscribers use IPv6 because they do not have an
IPv6 capable phone. The Nexus S and Galaxy Nexus work well.

This device challenge will improve in time.  Samsung is doing a good job of
bringing IPv6 to Android devices. More info here
https://sites.google.com/site/tmoipv6/lg-mytouch

> 2.  If, and how, are they handling NAT64 for native IPv6 edge devices?

Yes, NAT64 / DNS64 is used in the case of reaching ipv4-only nodes.  If you
are concerned about middleboxs, you should deploy IPv6.

> 3. What is the percentage of breakdown for users on native IPv6? Dual
> stacked?
>

Small today. As IPv6 becomes the default setting, that will change.

CB

> GREE is a mobile social gaming company and we're trying to better
> understand what lies between our customer's smart phones and our servers.
> My next step will be to reach out to the carriers themselves, but I
figured
> many of their Network Engineers are probably on the NANOG mailing list and
> this would be a great place to start.
>
> Thanks in advance for your time and assistance.
>
> Sincerely,
>
> - Paul Porter
>
> --
> *Paul G. Porter
> *GREE International | Network Engineer
> CCNP, CCSP, JNCIS-FWV, JNCIA-Junos
> E-mail: paul.porter at gree.net
> Mobile: (510) 371-1147
> Twitter: paul_g_porter

From paul at paulgraydon.co.uk  Tue May 22 18:40:08 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Tue, 22 May 2012 13:40:08 -1000
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
Message-ID: <4FBC23D8.5040109@paulgraydon.co.uk>

On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp>  wrote:
>> Hi NANOG,
>>
>> I'm looking for some information on the four largest US mobile phone
>> carriers and the current state of their IPv6 infrastructure. Specifically,
>> we are trying to figure out:
>>
>> 1.  How much of the carrier core and edge for AT&T, Verizon. T-Mobile, and
>> Sprint are on IPv6 now?
> Hi,
>
> T-Mobile USA has native ipv6 to all subscribers in all of it's coverage
> area. But, less than 1% of subscribers use IPv6 because they do not have an
> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
>
> This device challenge will improve in time.  Samsung is doing a good job of
> bringing IPv6 to Android devices. More info here
That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it 
doesn't get an IPv6 address, only IPv4.  Works fine with IPv6 over my 
wireless network at home.  Doesn't seem to be anything obvious in the 
settings to enable or disable that.

Paul


From paul4004 at gmail.com  Tue May 22 18:59:00 2012
From: paul4004 at gmail.com (PC)
Date: Tue, 22 May 2012 17:59:00 -0600
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <4FBC23D8.5040109@paulgraydon.co.uk>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
Message-ID: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>

IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
LTE network.  I noticed its using it to communicate to Google for many
of it's services when I ran a netstat.  I believe they mandated
support for it from any certified device.

Unfortunately, it's still firewalled.


On Tue, May 22, 2012 at 5:40 PM, Paul Graydon <paul at paulgraydon.co.uk> wrote:
> On 05/22/2012 01:21 PM, Cameron Byrne wrote:
>>
>> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp> ?wrote:
>>>
>>> Hi NANOG,
>>>
>>> I'm looking for some information on the four largest US mobile phone
>>> carriers and the current state of their IPv6 infrastructure.
>>> Specifically,
>>> we are trying to figure out:
>>>
>>> 1. ?How much of the carrier core and edge for AT&T, Verizon. T-Mobile,
>>> and
>>> Sprint are on IPv6 now?
>>
>> Hi,
>>
>> T-Mobile USA has native ipv6 to all subscribers in all of it's coverage
>> area. But, less than 1% of subscribers use IPv6 because they do not have
>> an
>> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
>>
>> This device challenge will improve in time. ?Samsung is doing a good job
>> of
>> bringing IPv6 to Android devices. More info here
>
> That's interesting. ?I have a Galaxy Nexus on T-Mobile USA and it doesn't
> get an IPv6 address, only IPv4. ?Works fine with IPv6 over my wireless
> network at home. ?Doesn't seem to be anything obvious in the settings to
> enable or disable that.
>
> Paul
>


From Tina.Tsou.Zouting at huawei.com  Tue May 22 19:02:38 2012
From: Tina.Tsou.Zouting at huawei.com (Tina TSOU)
Date: Wed, 23 May 2012 00:02:38 +0000
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
 <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
Message-ID: <C0E0A32284495243BDE0AC8A066631A80D39A765@dfweml513-mbx.china.huawei.com>

iOS 5.1 includes SLAAC and DHCPv6 client.

Tina


> -----Original Message-----
> From: PC [mailto:paul4004 at gmail.com]
> Sent: Tuesday, May 22, 2012 4:59 PM
> To: Paul Graydon
> Cc: nanog at nanog.org
> Subject: Re: Current IPv6 state of US Mobile Phone Carriers
> 
> IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
> LTE network.  I noticed its using it to communicate to Google for many
> of it's services when I ran a netstat.  I believe they mandated
> support for it from any certified device.
> 
> Unfortunately, it's still firewalled.
> 
> 
> On Tue, May 22, 2012 at 5:40 PM, Paul Graydon <paul at paulgraydon.co.uk>
> wrote:
> > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> >>
> >> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp> ?wrote:
> >>>
> >>> Hi NANOG,
> >>>
> >>> I'm looking for some information on the four largest US mobile phone
> >>> carriers and the current state of their IPv6 infrastructure.
> >>> Specifically,
> >>> we are trying to figure out:
> >>>
> >>> 1. ?How much of the carrier core and edge for AT&T, Verizon. T-Mobile,
> >>> and
> >>> Sprint are on IPv6 now?
> >>
> >> Hi,
> >>
> >> T-Mobile USA has native ipv6 to all subscribers in all of it's coverage
> >> area. But, less than 1% of subscribers use IPv6 because they do not
> have
> >> an
> >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> >>
> >> This device challenge will improve in time. ?Samsung is doing a good
> job
> >> of
> >> bringing IPv6 to Android devices. More info here
> >
> > That's interesting. ?I have a Galaxy Nexus on T-Mobile USA and it
> doesn't
> > get an IPv6 address, only IPv4. ?Works fine with IPv6 over my wireless
> > network at home. ?Doesn't seem to be anything obvious in the settings to
> > enable or disable that.
> >
> > Paul
> >



From paul at paulgraydon.co.uk  Tue May 22 19:36:13 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Tue, 22 May 2012 14:36:13 -1000
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <4FBC23D8.5040109@paulgraydon.co.uk>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
Message-ID: <4FBC30FD.7000302@paulgraydon.co.uk>

On 05/22/2012 01:40 PM, Paul Graydon wrote:
> On 05/22/2012 01:21 PM, Cameron Byrne wrote:
>> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp>  wrote:
>>> Hi NANOG,
>>>
>>> I'm looking for some information on the four largest US mobile phone
>>> carriers and the current state of their IPv6 infrastructure. 
>>> Specifically,
>>> we are trying to figure out:
>>>
>>> 1.  How much of the carrier core and edge for AT&T, Verizon. 
>>> T-Mobile, and
>>> Sprint are on IPv6 now?
>> Hi,
>>
>> T-Mobile USA has native ipv6 to all subscribers in all of it's coverage
>> area. But, less than 1% of subscribers use IPv6 because they do not 
>> have an
>> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
>>
>> This device challenge will improve in time.  Samsung is doing a good 
>> job of
>> bringing IPv6 to Android devices. More info here
> That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it 
> doesn't get an IPv6 address, only IPv4.  Works fine with IPv6 over my 
> wireless network at home.  Doesn't seem to be anything obvious in the 
> settings to enable or disable that.
>
> Paul
>
Cameron contacted me off list and pointed out the steps.  Works a treat, 
NAT64 is handling the IPv4 traffic without any obvious problems, along 
with IPv6.  Smooth and simple.  Shame it has to be switched on through 
some manual steps, but I guess that's understandable for now given it's 
technically in Beta stage.

Paul


From morrowc.lists at gmail.com  Tue May 22 20:11:53 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 May 2012 21:11:53 -0400
Subject: Peer1/Server Beach support for BGP on dedicated servers
In-Reply-To: <CAL9jLaYMF19jxRn4J0aeDDEsyXCTrEwKUOPaST8ROGjhOGNaBQ@mail.gmail.com>
References: <CAJ0+aXYO=tZNudqm-ZDAce6PfQx+unoN7bMwaf3J6jaGs5yeoA@mail.gmail.com>
 <CAHsqw9sLO+SupL8v+rj7sj-A2mipbr5h9FRD59ZbgyKvRu1RUQ@mail.gmail.com>
 <4FB7C832.6060106@rollernet.us>
 <03883C89-6A31-4F32-917C-B8616840B078@pch.net>
 <CAPZUUwWnfkx_DAvOgid-p3G=prAr=PEhUjP3vXE_cWC=nGM6Xg@mail.gmail.com>
 <4FBBD92A.1030500@viagenie.ca>
 <EAE75C548B908C4A99AC6D86C2A2F7620C8D0B39@CH1PRD0710MB367.namprd07.prod.outlook.com>
 <CAL9jLaYMF19jxRn4J0aeDDEsyXCTrEwKUOPaST8ROGjhOGNaBQ@mail.gmail.com>
Message-ID: <CAL9jLabyBLtSi2E6KSWMk3J-vNetxNZYG4w6co1QEypj+jxM1w@mail.gmail.com>

On Tue, May 22, 2012 at 3:08 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Tue, May 22, 2012 at 3:02 PM, J.J. Mc Kenna
> <JMcKenna at intelletrace.com> wrote:
>> http://www.voxel.net/assets/VoxCAST-Whitepaper.pdf
>
> that does mention bgp, but not in the context of 'make my server do
> bgp with the voxel network equipment'... in the context of: "If you
> setup a cdn you need to speak bgp".
>
> I don't see a clicky-box on the voxel server (dedicated hosting)
> configuration and pricing page for 'add the bgp to my server, pls.'.

offlist a respondent states that emails to sales@ would get this
moving in the right direction... that seems promising.

thanks off-list respondent!
-chris


From wolfgang.rupprecht at gmail.com  Tue May 22 20:47:02 2012
From: wolfgang.rupprecht at gmail.com (Wolfgang S. Rupprecht)
Date: Tue, 22 May 2012 18:47:02 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
Message-ID: <878vgjzn1l.fsf@arbol.wsrcc.com>


Paul Graydon <paul at paulgraydon.co.uk> writes:
> That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it
> doesn't get an IPv6 address, only IPv4.  Works fine with IPv6 over my
> wireless network at home.  Doesn't seem to be anything obvious in the
> settings to enable or disable that.

Same here.  IPv6 works fine over my wifi, but doesn't work at all over
tmobile.

If I play with the cell settings to allow ipv4/ipv6 in APN then all
communication stops.  TMO might need to go back to those drawing
boards.  I don't see ipv6 working at all over their network.

-wolfgang
-- 
g+:  https://plus.google.com/114566345864337108516/about



From cb.list6 at gmail.com  Tue May 22 21:05:32 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 22 May 2012 19:05:32 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <878vgjzn1l.fsf@arbol.wsrcc.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
 <878vgjzn1l.fsf@arbol.wsrcc.com>
Message-ID: <CAD6AjGTGiaHxxX=DV3s=D3Ygadpp1rd4K=qk+u-zkBwTZwdJoQ@mail.gmail.com>

On May 22, 2012 6:50 PM, "Wolfgang S. Rupprecht" <
wolfgang.rupprecht at gmail.com> wrote:
>
>
> Paul Graydon <paul at paulgraydon.co.uk> writes:
> > That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it
> > doesn't get an IPv6 address, only IPv4.  Works fine with IPv6 over my
> > wireless network at home.  Doesn't seem to be anything obvious in the
> > settings to enable or disable that.
>
> Same here.  IPv6 works fine over my wifi, but doesn't work at all over
> tmobile.
>
> If I play with the cell settings to allow ipv4/ipv6 in APN then all
> communication stops.  TMO might need to go back to those drawing
> boards.  I don't see ipv6 working at all over their network.
>

Please read and follow the instructions here on how to setup
https://sites.google.com/site/tmoipv6/lg-mytouch

Feel free to ping me off-list if you see any issues.

>From what you wrote, my guess is you are using a phone that does not have
IPv6 support (only Nexus phones have support today... Other phones do not
have the correct radio / RIL capabilities)

CB

> -wolfgang
> --
> g+:  https://plus.google.com/114566345864337108516/about
>
>

From rcarpen at network1.net  Tue May 22 21:07:12 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 22 May 2012 22:07:12 -0400 (EDT)
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
Message-ID: <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>


Not only does Verizon *not* have IPv6 on their LTE network, they also do *not* have IPv4, except for double-NATed rfc1918 crap that changes your IP address every couple minutes. The only way to get a stable connection is to pay them $500 to get a static public IP address.

thanks,
-Randy


----- Original Message -----
> IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
> LTE network.  I noticed its using it to communicate to Google for
> many
> of it's services when I ran a netstat.  I believe they mandated
> support for it from any certified device.
> 
> Unfortunately, it's still firewalled.
> 
> 
> On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
> <paul at paulgraydon.co.uk> wrote:
> > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> >>
> >> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp>
> >> ?wrote:
> >>>
> >>> Hi NANOG,
> >>>
> >>> I'm looking for some information on the four largest US mobile
> >>> phone
> >>> carriers and the current state of their IPv6 infrastructure.
> >>> Specifically,
> >>> we are trying to figure out:
> >>>
> >>> 1. ?How much of the carrier core and edge for AT&T, Verizon.
> >>> T-Mobile,
> >>> and
> >>> Sprint are on IPv6 now?
> >>
> >> Hi,
> >>
> >> T-Mobile USA has native ipv6 to all subscribers in all of it's
> >> coverage
> >> area. But, less than 1% of subscribers use IPv6 because they do
> >> not have
> >> an
> >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> >>
> >> This device challenge will improve in time. ?Samsung is doing a
> >> good job
> >> of
> >> bringing IPv6 to Android devices. More info here
> >
> > That's interesting. ?I have a Galaxy Nexus on T-Mobile USA and it
> > doesn't
> > get an IPv6 address, only IPv4. ?Works fine with IPv6 over my
> > wireless
> > network at home. ?Doesn't seem to be anything obvious in the
> > settings to
> > enable or disable that.
> >
> > Paul
> >
> 
> 
> 


From morrowc.lists at gmail.com  Tue May 22 21:12:58 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 May 2012 22:12:58 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>
References: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
 <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>
Message-ID: <CAL9jLabc=cQdrQZt3DAeDwqx5f+eXTb9x8Gj=40V5wMQ3MRZhg@mail.gmail.com>

On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>
> Not only does Verizon *not* have IPv6 on their LTE network, they also do *not* have IPv4, except for double-NATed rfc1918 crap that changes your IP address every couple minutes. The only way to get a stable connection is to pay them $500 to get a static public IP address.
>

wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
was able to browse some ipv6-only sites.


From hrlinneweh at sbcglobal.net  Tue May 22 21:14:16 2012
From: hrlinneweh at sbcglobal.net (Henry Linneweh)
Date: Tue, 22 May 2012 19:14:16 -0700 (PDT)
Subject: =?utf-8?B?Vml4aWUgd2FybnM6IEROUyBDaGFuZ2VyIOKAmGJsYWNrb3V0c+KAmSBpbmV2?=
 =?utf-8?B?aXRhYmxl?=
Message-ID: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>

http://www.theregister.co.uk/2012/05/17/dns_changer_blackouts/

-Henry

From rcarpen at network1.net  Tue May 22 21:18:15 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 22 May 2012 22:18:15 -0400 (EDT)
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAL9jLabc=cQdrQZt3DAeDwqx5f+eXTb9x8Gj=40V5wMQ3MRZhg@mail.gmail.com>
Message-ID: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>

I suppose they are selectively letting certain devices in some areas. I get "der duh, what?" when I ask about it.

It certainly does not work on the iPad "3" in Ohio. Not only that, but I can't even pay them to give me a stable IPv4 address, because if you get a static IP, it disables the hotspot functionality. Head-->Wall.

thanks,
-Randy

----- Original Message -----
> On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter
> <rcarpen at network1.net> wrote:
> >
> > Not only does Verizon *not* have IPv6 on their LTE network, they
> > also do *not* have IPv4, except for double-NATed rfc1918 crap that
> > changes your IP address every couple minutes. The only way to get
> > a stable connection is to pay them $500 to get a static public IP
> > address.
> >
> 
> wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
> was able to browse some ipv6-only sites.
> 
> 


From derek at derekivey.com  Tue May 22 21:21:32 2012
From: derek at derekivey.com (Derek Ivey)
Date: Tue, 22 May 2012 22:21:32 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
Message-ID: <4FBC49AC.40308@derekivey.com>

Verizon still seems to be quiet about their IPv6 plans for their FiOS 
network too :(.

Derek

On 5/22/2012 10:18 PM, Randy Carpenter wrote:
> I suppose they are selectively letting certain devices in some areas. I get "der duh, what?" when I ask about it.
>
> It certainly does not work on the iPad "3" in Ohio. Not only that, but I can't even pay them to give me a stable IPv4 address, because if you get a static IP, it disables the hotspot functionality. Head-->Wall.
>
> thanks,
> -Randy
>
> ----- Original Message -----
>> On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter
>> <rcarpen at network1.net>  wrote:
>>> Not only does Verizon *not* have IPv6 on their LTE network, they
>>> also do *not* have IPv4, except for double-NATed rfc1918 crap that
>>> changes your IP address every couple minutes. The only way to get
>>> a stable connection is to pay them $500 to get a static public IP
>>> address.
>>>
>> wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
>> was able to browse some ipv6-only sites.
>>
>>



From morrowc.lists at gmail.com  Tue May 22 21:25:14 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 May 2012 22:25:14 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <4FBC49AC.40308@derekivey.com>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBC49AC.40308@derekivey.com>
Message-ID: <CAL9jLaauzGhYRqfab_j5-USAma6huAhLDkQ2H0_bVR6r+38XLQ@mail.gmail.com>

On Tue, May 22, 2012 at 10:21 PM, Derek Ivey <derek at derekivey.com> wrote:
> Verizon still seems to be quiet about their IPv6 plans for their FiOS
> network too :(.

no they aren't, their complete lack of any noise is their plan.

no plan.

joy.

> On 5/22/2012 10:18 PM, Randy Carpenter wrote:
>>
>> I suppose they are selectively letting certain devices in some areas. I
>> get "der duh, what?" when I ask about it.
>>
>> It certainly does not work on the iPad "3" in Ohio. Not only that, but I
>> can't even pay them to give me a stable IPv4 address, because if you get a
>> static IP, it disables the hotspot functionality. Head-->Wall.
>>
>> thanks,
>> -Randy
>>
>> ----- Original Message -----
>>>
>>> On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter
>>> <rcarpen at network1.net> ?wrote:
>>>>
>>>> Not only does Verizon *not* have IPv6 on their LTE network, they
>>>> also do *not* have IPv4, except for double-NATed rfc1918 crap that
>>>> changes your IP address every couple minutes. The only way to get
>>>> a stable connection is to pay them $500 to get a static public IP
>>>> address.
>>>>
>>> wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
>>> was able to browse some ipv6-only sites.
>>>
>>>
>
>


From morrowc.lists at gmail.com  Tue May 22 21:27:14 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 May 2012 22:27:14 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
References: <CAL9jLabc=cQdrQZt3DAeDwqx5f+eXTb9x8Gj=40V5wMQ3MRZhg@mail.gmail.com>
 <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
Message-ID: <CAL9jLaa5rkE9ga0E=o8+tunavTDZPttyN2f7eZurA90PZ1Z4pg@mail.gmail.com>

On Tue, May 22, 2012 at 10:18 PM, Randy Carpenter <rcarpen at network1.net> wrote:
> I suppose they are selectively letting certain devices in some areas. I get "der duh, what?" when I ask about it.
>

uhm... you asked someone at their kiosks/stores about ipv<anything>??
you are a very, very brave man.

> It certainly does not work on the iPad "3" in Ohio. Not only that, but I can't even pay them to give me a stable IPv4 address, because if you get a static IP, it disables the hotspot functionality. Head-->Wall.
>

good times!! mobile carriers live in what seems like a very different
world from the one the rest of the internet lives in :(

(cameron's folk aside, where there are still some oddities, at least
you can get working ipv6, and mostly working v4... or working enough
that I can tether my phone and vpn over that connection when
necessary)

-chris

> thanks,
> -Randy
>
> ----- Original Message -----
>> On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter
>> <rcarpen at network1.net> wrote:
>> >
>> > Not only does Verizon *not* have IPv6 on their LTE network, they
>> > also do *not* have IPv4, except for double-NATed rfc1918 crap that
>> > changes your IP address every couple minutes. The only way to get
>> > a stable connection is to pay them $500 to get a static public IP
>> > address.
>> >
>>
>> wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
>> was able to browse some ipv6-only sites.
>>
>>


From cb.list6 at gmail.com  Tue May 22 21:50:31 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 22 May 2012 19:50:31 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <20412.18436.198979.587791@arbol.wsrcc.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
 <878vgjzn1l.fsf@arbol.wsrcc.com>
 <CAD6AjGTGiaHxxX=DV3s=D3Ygadpp1rd4K=qk+u-zkBwTZwdJoQ@mail.gmail.com>
 <20412.18436.198979.587791@arbol.wsrcc.com>
Message-ID: <CAD6AjGSnM09=N_-72_-uE3a-Dq20tCJX6MM+YR-3XzGn_cSNEw@mail.gmail.com>

On May 22, 2012 7:14 PM, "Wolfgang S. Rupprecht" <
wolfgang.rupprecht at gmail.com> wrote:
>
>
> Cameron Byrne writes:
> >    From what you wrote,  guess is you are using a phone that does not
> >    have IPv6 support (only Nexus phones have support today... Other
phones
> >    do not have the correct radio / RIL capabilities)
>
> I'm using the Galaxy Nexus GSM bought directly from google a few weeks
> ago.  The firmware is up to date as are the apps.
>
> The instructions mention settings and pages that are slightly wrong
> for this phone.  I went to the "Mobile network settings" -> "Access
> Point names" -> "T-Mobile US, epc.tmobile.com" -> "APN Protocol".  It
> was "IPv4" and I changed it to "IPv4/IPv6" and then rebooted.  There
> was no "save" button or menu item.  After reboot the ipv4/ipv6 setting
> was still active (so it was saved), but no connection took place.  The
> cell tower I'm using is in Fremont, CA (CID 47052 LAC321).  Might it
> not be v6 connected?
>

For the sake of the archive and documenting the confirmed fix, the correct
APN setting for T-Mobile is "IPv6" not "IPv4 /IPv6"

CB

> -wolfgang
> --
> g+:  https://plus.google.com/114566345864337108516/about

From wolfgang.rupprecht at gmail.com  Tue May 22 21:58:07 2012
From: wolfgang.rupprecht at gmail.com (Wolfgang S. Rupprecht)
Date: Tue, 22 May 2012 19:58:07 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk> <878vgjzn1l.fsf@arbol.wsrcc.com>
 <CAD6AjGTGiaHxxX=DV3s=D3Ygadpp1rd4K=qk+u-zkBwTZwdJoQ@mail.gmail.com>
 <20412.18436.198979.587791@arbol.wsrcc.com>
 <CAD6AjGSnM09=N_-72_-uE3a-Dq20tCJX6MM+YR-3XzGn_cSNEw@mail.gmail.com>
Message-ID: <87zk8zy56o.fsf@arbol.wsrcc.com>


Cameron Byrne <cb.list6 at gmail.com> writes:
> On May 22, 2012 7:14 PM, "Wolfgang S. Rupprecht" <
> wolfgang.rupprecht at gmail.com> wrote:
>>
>>
>> Cameron Byrne writes:
>> >    From what you wrote,  guess is you are using a phone that does not
>> >    have IPv6 support (only Nexus phones have support today... Other
> phones
>> >    do not have the correct radio / RIL capabilities)
>>
>> I'm using the Galaxy Nexus GSM bought directly from google a few weeks
>> ago.  The firmware is up to date as are the apps.
>>
>> The instructions mention settings and pages that are slightly wrong
>> for this phone.  I went to the "Mobile network settings" -> "Access
>> Point names" -> "T-Mobile US, epc.tmobile.com" -> "APN Protocol".  It
>> was "IPv4" and I changed it to "IPv4/IPv6" and then rebooted.  There
>> was no "save" button or menu item.  After reboot the ipv4/ipv6 setting
>> was still active (so it was saved), but no connection took place.  The
>> cell tower I'm using is in Fremont, CA (CID 47052 LAC321).  Might it
>> not be v6 connected?
>>
>
> For the sake of the archive and documenting the confirmed fix, the correct
> APN setting for T-Mobile is "IPv6" not "IPv4 /IPv6"

Yup.  Thanks Cameron! Chosing IPv6 (-only), does work.  I can view
IPv6-only websites when on a cell connection.  Before that only worked
when on wifi.

-wolfgang
-- 
g+:  https://plus.google.com/114566345864337108516/about



From rcarpen at network1.net  Tue May 22 22:04:43 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 22 May 2012 23:04:43 -0400 (EDT)
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAL9jLaa5rkE9ga0E=o8+tunavTDZPttyN2f7eZurA90PZ1Z4pg@mail.gmail.com>
Message-ID: <0fde76c8-15e7-47e6-a65a-ccf64941c0bf@zimbra.network1.net>


----- Original Message -----
> On Tue, May 22, 2012 at 10:18 PM, Randy Carpenter
> <rcarpen at network1.net> wrote:
> > I suppose they are selectively letting certain devices in some
> > areas. I get "der duh, what?" when I ask about it.
> >
> 
> uhm... you asked someone at their kiosks/stores about ipv<anything>??
> you are a very, very brave man.

No... the Business technical support via telephone. They knew what I was talking about, but no idea about what VZW's plans are for it.

> > It certainly does not work on the iPad "3" in Ohio. Not only that,
> > but I can't even pay them to give me a stable IPv4 address,
> > because if you get a static IP, it disables the hotspot
> > functionality. Head-->Wall.
> >
> 
> good times!! mobile carriers live in what seems like a very different
> world from the one the rest of the internet lives in :(

Tell me about it. I would settle for a stable IPv4 address (dynamic is fine, but a "lease" time of something closer to an hour, rather than 2 minutes)

-Randy


From morrowc.lists at gmail.com  Tue May 22 22:13:27 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 May 2012 23:13:27 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <0fde76c8-15e7-47e6-a65a-ccf64941c0bf@zimbra.network1.net>
References: <CAL9jLaa5rkE9ga0E=o8+tunavTDZPttyN2f7eZurA90PZ1Z4pg@mail.gmail.com>
 <0fde76c8-15e7-47e6-a65a-ccf64941c0bf@zimbra.network1.net>
Message-ID: <CAL9jLabiYTrvPQacQHcgS3VEyr9oFWQ6jnZfxYtYXus5LL=P3w@mail.gmail.com>

On Tue, May 22, 2012 at 11:04 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>
> ----- Original Message -----
>> On Tue, May 22, 2012 at 10:18 PM, Randy Carpenter
>> <rcarpen at network1.net> wrote:
>> > I suppose they are selectively letting certain devices in some
>> > areas. I get "der duh, what?" when I ask about it.
>> >
>>
>> uhm... you asked someone at their kiosks/stores about ipv<anything>??
>> you are a very, very brave man.
>
> No... the Business technical support via telephone. They knew what I was talking about, but no idea about what VZW's plans are for it.
>

yea... so keep in mind that vzw and set(vzb(former mci/uunet) / vzt
(the phone company that owns the copper AND also deployed FIOS)) are
very, very different things.

I think inside vzb/vzt there's some oddness in their planning process
for v6, it's completely divorced from the vzw planning. If you want
answers about your vzw mifi/phone/tablet you can only ask vzw
kiosk/etc people :(

>> > It certainly does not work on the iPad "3" in Ohio. Not only that,
>> > but I can't even pay them to give me a stable IPv4 address,
>> > because if you get a static IP, it disables the hotspot
>> > functionality. Head-->Wall.
>> >
>>
>> good times!! mobile carriers live in what seems like a very different
>> world from the one the rest of the internet lives in :(
>
> Tell me about it. I would settle for a stable IPv4 address (dynamic is fine, but a "lease" time of something closer to an hour, rather than 2 minutes)

maybe they already did the CGN thing to their network, lots and lots
of single IP sharing by port number! look, it's the future!

-chris

>
> -Randy


From randy at psg.com  Tue May 22 22:35:05 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 23 May 2012 12:35:05 +0900
Subject: Vixie warns: DNS Changer =?UTF-8?B?4oCYYmxhY2tvdXRz4oCZ?=
 inevitable
In-Reply-To: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
Message-ID: <m2zk8zbmdy.wl%randy@psg.com>

father of bind?  that's news.

dnschanger gonna be a mess?  that's not news.

randy


From bmanning at vacation.karoshi.com  Tue May 22 22:39:10 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 23 May 2012 03:39:10 +0000
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
Message-ID: <20120523033910.GA23282@vacation.karoshi.com.>

On Tue, May 22, 2012 at 07:14:16PM -0700, Henry Linneweh wrote:
> http://www.theregister.co.uk/2012/05/17/dns_changer_blackouts/
> 
> -Henry

	Paul certainly knows how to manipulate the press.

/bill


From mjwise at kapu.net  Tue May 22 22:52:52 2012
From: mjwise at kapu.net (Michael J Wise)
Date: Tue, 22 May 2012 20:52:52 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <m2zk8zbmdy.wl%randy@psg.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
Message-ID: <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>


On May 22, 2012, at 8:35 PM, Randy Bush wrote:

> father of bind?  that's news.

	<http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html>

He was there, and Put The Fix In, to down the network.
I gather he's the one pulling it out on the appointed day as well.

> dnschanger gonna be a mess?  that's not news.


Agreed.

Aloha,
Michael.
-- 
"Please have your Internet License             
 and Usenet Registration handy..."



From dhubbard at dino.hostasaurus.com  Tue May 22 23:06:43 2012
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 23 May 2012 00:06:43 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0F098@dino.ad.hostasaurus.com>

I have the "4GLTE" LG VL600 usb modem from Verizon on a consumer
data-only $50/month plan and it gives my Windows 7 laptop
a v6 address on both 3G and "4G" connections.  I noticed it
recently when I was logged into the ARIN website since their
site puts a banner across the top when you're accessing via
ipv6; then I tried other sites to confirm it was working.

David

> -----Original Message-----
> From: Randy Carpenter [mailto:rcarpen at network1.net] 
> Sent: Tuesday, May 22, 2012 10:07 PM
> To: PC
> Cc: nanog at nanog.org
> Subject: Re: Current IPv6 state of US Mobile Phone Carriers
> 
> 
> Not only does Verizon *not* have IPv6 on their LTE network, 
> they also do *not* have IPv4, except for double-NATed rfc1918 
> crap that changes your IP address every couple minutes. The 
> only way to get a stable connection is to pay them $500 to 
> get a static public IP address.
> 
> thanks,
> -Randy
> 
> 
> ----- Original Message -----
> > IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
> > LTE network.  I noticed its using it to communicate to Google for
> > many
> > of it's services when I ran a netstat.  I believe they mandated
> > support for it from any certified device.
> > 
> > Unfortunately, it's still firewalled.
> > 
> > 
> > On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
> > <paul at paulgraydon.co.uk> wrote:
> > > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> > >>
> > >> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp>
> > >> ?wrote:
> > >>>
> > >>> Hi NANOG,
> > >>>
> > >>> I'm looking for some information on the four largest US mobile
> > >>> phone
> > >>> carriers and the current state of their IPv6 infrastructure.
> > >>> Specifically,
> > >>> we are trying to figure out:
> > >>>
> > >>> 1. ?How much of the carrier core and edge for AT&T, Verizon.
> > >>> T-Mobile,
> > >>> and
> > >>> Sprint are on IPv6 now?
> > >>
> > >> Hi,
> > >>
> > >> T-Mobile USA has native ipv6 to all subscribers in all of it's
> > >> coverage
> > >> area. But, less than 1% of subscribers use IPv6 because they do
> > >> not have
> > >> an
> > >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> > >>
> > >> This device challenge will improve in time. ?Samsung is doing a
> > >> good job
> > >> of
> > >> bringing IPv6 to Android devices. More info here
> > >
> > > That's interesting. ?I have a Galaxy Nexus on T-Mobile USA and it
> > > doesn't
> > > get an IPv6 address, only IPv4. ?Works fine with IPv6 over my
> > > wireless
> > > network at home. ?Doesn't seem to be anything obvious in the
> > > settings to
> > > enable or disable that.
> > >
> > > Paul
> > >
> > 
> > 
> > 
> 
> 
> 


From bmanning at vacation.karoshi.com  Tue May 22 23:10:40 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 23 May 2012 04:10:40 +0000
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
Message-ID: <20120523041040.GC23282@vacation.karoshi.com.>

On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote:
> 
> On May 22, 2012, at 8:35 PM, Randy Bush wrote:
> 
> > father of bind?  that's news.
> 
> 	<http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html>
> 
> He was there, and Put The Fix In, to down the network.

	Certainly news to Phil Almquist and the entire BIND development team
	at UCB.   Paul was at DECWRL and cut his teeth on pre-existing code.
	While he (and ISC) have since revised, gutted, tossed all the orginal
	code, rebuilt it twice - and others have done similar for their DNS
	software,  based on the BIND code base, implementation assumptions, and 
	with little or no ISC code, and they call it BIND as well,  it would be 
	a HUGE leap of faith to call Paul Vixie the father of 
		BIND - The Berkeley Internet Naming Daemon.

	As for being there and "Put The Fix In"...  Makes for great PR but 
	in actual fact, its a bandaid that is not going to stem the tide.
	An actual fix would really need to change the nature of the creaky
	1980's implementation artifacts that this community loves so well.

/bill


From randy at psg.com  Tue May 22 23:45:42 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 23 May 2012 13:45:42 +0900
Subject: Vixie warns: DNS Changer =?UTF-8?B?4oCYYmxhY2tvdXRz4oCZ?=
 inevitable
In-Reply-To: <20120523041040.GC23282@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
Message-ID: <m2likjbj49.wl%randy@psg.com>

> As for being there and "Put The Fix In"...  Makes for great PR but in
> actual fact, its a bandaid that is not going to stem the tide.

maybe we could wad up the sensationalist and self-aggrandizing newspaper
articles and use them to plug the dike?

randy


From mjwise at kapu.net  Wed May 23 00:07:52 2012
From: mjwise at kapu.net (Michael J Wise)
Date: Tue, 22 May 2012 22:07:52 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <20120523041040.GC23282@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
Message-ID: <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>


On May 22, 2012, at 9:10 PM, bmanning at vacation.karoshi.com wrote:

> On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote:
>> 
>> On May 22, 2012, at 8:35 PM, Randy Bush wrote:
>> 
>>> father of bind?  that's news.
>> 
>> 	<http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html>
>> 
>> He was there, and Put The Fix In, to down the network.
> 
> 	Certainly news to Phil Almquist and the entire BIND development team
> 	at UCB.   Paul was at DECWRL and cut his teeth on pre-existing code.
> 	While he (and ISC) have since revised, gutted, tossed all the orginal
> 	code, rebuilt it twice - and others have done similar for their DNS
> 	software,  based on the BIND code base, implementation assumptions, and 
> 	with little or no ISC code, and they call it BIND as well,  it would be 
> 	a HUGE leap of faith to call Paul Vixie the father of 
> 		BIND - The Berkeley Internet Naming Daemon.

Methinks we're talking at cross purposes.

> 	As for being there and "Put The Fix In"...  Makes for great PR but 
> 	in actual fact, its a bandaid that is not going to stem the tide.
> 	An actual fix would really need to change the nature of the creaky
> 	1980's implementation artifacts that this community loves so well.


I don't think we're talking about the same thing at all.
Paul was there to shut down the DNS changer system and replace it with something that restored functionality to the infected machines.
And I gather Paul will be one of the people who will turn the lights out on it.

Your other comments are non-sequitur to the main issue.
When those servers are turned off, Customer Support folks at many ISPs will prolly want to take their accrued vacation.

Aloha,
Michael.
-- 
"Please have your Internet License             
 and Usenet Registration handy..."



From bmanning at vacation.karoshi.com  Wed May 23 00:40:16 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 23 May 2012 05:40:16 +0000
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
Message-ID: <20120523054016.GA23944@vacation.karoshi.com.>

On Tue, May 22, 2012 at 10:07:52PM -0700, Michael J Wise wrote:
> 
> On May 22, 2012, at 9:10 PM, bmanning at vacation.karoshi.com wrote:
> 
> > On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote:
> >> 
> >> On May 22, 2012, at 8:35 PM, Randy Bush wrote:
> >> 
> >>> father of bind?  that's news.
> >> 
> >> 	<http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html>
> >> 
> >> He was there, and Put The Fix In, to down the network.
> > 
> > 	Certainly news to Phil Almquist and the entire BIND development team
> > 	at UCB.   Paul was at DECWRL and cut his teeth on pre-existing code.
> > 	While he (and ISC) have since revised, gutted, tossed all the orginal
> > 	code, rebuilt it twice - and others have done similar for their DNS
> > 	software,  based on the BIND code base, implementation assumptions, and 
> > 	with little or no ISC code, and they call it BIND as well,  it would be 
> > 	a HUGE leap of faith to call Paul Vixie the father of 
> > 		BIND - The Berkeley Internet Naming Daemon.
> 
> Methinks we're talking at cross purposes.

	maybe... :)  my comment was refering to the "father of bind" statement.

> > 	As for being there and "Put The Fix In"...  Makes for great PR but 
> > 	in actual fact, its a bandaid that is not going to stem the tide.
> > 	An actual fix would really need to change the nature of the creaky
> > 	1980's implementation artifacts that this community loves so well.
> 
> I don't think we're talking about the same thing at all.
> Paul was there to shut down the DNS changer system and replace it with something that restored functionality to the infected machines.
> And I gather Paul will be one of the people who will turn the lights out on it.

	He didn't "shut down" DNS Changer, he put up an equivalent system to hijack
	DNS traffic and direct it to the "right" place...  SO folks didn't see any
	problem and the DNS Changer infection grew and got worse.  When he is legally
	required to take his "bandaide" out of service, then the problem will resolve
	by folks who will have to clean their systems.

	As for "turning the lights out" - that will only happen when the value of 
	DNS hijacking drops.   As it is now,  ISC has placed DNS hijacking code
	into their mainstream code base... because DNS hijacking is so valuable to 
	folks.  In a modestly favorable light, ISC looks like an arms dealer (DNS redirection)
	to the bad guys -AND- (via DNSSEC) the good guys.  Either way, they make money.

	And yes, I think I agree with you.  Paul will be there to turn things off when 
	they no longer make money for his company.

> Your other comments are non-sequitur to the main issue.

	Perhaps I am not a member of the Paul Vixie cult of personality.  

> When those servers are turned off, Customer Support folks at many ISPs will prolly want to take their accrued vacation.

	Amen.  And there will be thousands more of them when the court order expires than
	existed when the Feds called him in.

/bill
> Aloha,
> Michael.
> -- 
> "Please have your Internet License             
>  and Usenet Registration handy..."
> 
> 


From randy at psg.com  Wed May 23 00:47:48 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 23 May 2012 14:47:48 +0900
Subject: Vixie warns: DNS Changer =?UTF-8?B?4oCYYmxhY2tvdXRz4oCZ?=
 inevitable
In-Reply-To: <20120523054016.GA23944@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
Message-ID: <m2bolfbg8r.wl%randy@psg.com>

>> When those servers are turned off, Customer Support folks at many
>> ISPs will prolly want to take their accrued vacation.
> Amen.  And there will be thousands more of them when the court order
> expires than existed when the Feds called him in.

they could extend the court order, or prolong the do-gooder hack longer
under some other pretext, increasing the underlying problem further.
more infected machines and more job creation for front line support when
the whitewash finally stops.

randy


From mjwise at kapu.net  Wed May 23 01:14:41 2012
From: mjwise at kapu.net (Michael J Wise)
Date: Tue, 22 May 2012 23:14:41 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <m2bolfbg8r.wl%randy@psg.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <m2bolfbg8r.wl%randy@psg.com>
Message-ID: <92E13493-8598-4FD2-8027-8DAF0EF02042@kapu.net>


On May 22, 2012, at 10:47 PM, Randy Bush wrote:

>>> When those servers are turned off, Customer Support folks at many
>>> ISPs will prolly want to take their accrued vacation.
>> Amen.  And there will be thousands more of them when the court order
>> expires than existed when the Feds called him in.
> 
> they could extend the court order, or prolong the do-gooder hack longer
> under some other pretext, increasing the underlying problem further.
> more infected machines and more job creation for front line support when
> the whitewash finally stops.


According to the pretty graphs, the number of machines querying the aforementioned infrastructure is going down.
Just not as fast as pretty much everyone would prefer?
and the DOJ is footing the bill, and grows tired of it.

So at some point, the lights are gonna be turned off.
It's a shame the ISPs who have the infected users have done less to mitigate the issue.
And many solutions were suggested, but all of them ended up being ? perceived to be worse than just shutting it down.

Or so I recall the presentation that Paul gave to a bunch of us in San Francisco back in February.

Aloha,
Michael.
-- 
"Please have your Internet License             
 and Usenet Registration handy..."



From owen at delong.com  Wed May 23 05:07:13 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 23 May 2012 03:07:13 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <20120523041040.GC23282@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
Message-ID: <0ABDA374-BBAF-4830-8F1E-D366B3A86F6D@delong.com>


On May 22, 2012, at 9:10 PM, bmanning at vacation.karoshi.com wrote:

> On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote:
>> 
>> On May 22, 2012, at 8:35 PM, Randy Bush wrote:
>> 
>>> father of bind?  that's news.
>> 
>> 	<http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html>
>> 
>> He was there, and Put The Fix In, to down the network.
> 
> 	Certainly news to Phil Almquist and the entire BIND development team
> 	at UCB.   Paul was at DECWRL and cut his teeth on pre-existing code.

Indeed, even the ISC history of the BIND project here:

http://www.isc.org/software/bind/history

shows that Paul's involvement began somewhere in the 4.9 timeframe.

One could, however, argue that he is the father of modern BIND implementations.

Owen



From r.bhatia at ipax.at  Wed May 23 05:18:33 2012
From: r.bhatia at ipax.at (Raoul Bhatia [IPAX])
Date: Wed, 23 May 2012 12:18:33 +0200
Subject: SNMP/TCP probes from critical.io
Message-ID: <4FBCB979.8020501@ipax.at>

hi!

during the last couple of days, i noticed probes from some hosts that
present themselves as critical.io probe hosts, including but not
limited to, the following IP addresses:

* 184.154.42.194 / critical.io
* 69.64.43.135 / research1.critical.io
* 69.64.43.137 / research2.critical.io
* 69.64.43.142 / research3.critical.io
* 50.116.22.209

The systems present the following information via http:
 > This system is coordinating an internet-wide survey of open TCP
 > ports, service banners, SNMP system descriptions, and NetBIOS name
 > queries. The results of this survey will be used to uncover
 > systematic vulnerabilities in the equipment provided by ISPs to their
 > customers.

Have you noticed these probes and what are your thoughts on them?

Cheers,
Raoul
-- 
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc.          email.          r.bhatia at ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OG          web.          http://www.ipax.at
Barawitzkagasse 10/2/2/11           email.            office at ipax.at
1190 Wien                           tel.               +43 1 3670030
FN 277995t HG Wien                  fax.            +43 1 3670030 15
____________________________________________________________________



From ops.lists at gmail.com  Wed May 23 05:21:33 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 23 May 2012 15:51:33 +0530
Subject: SNMP/TCP probes from critical.io
In-Reply-To: <4FBCB979.8020501@ipax.at>
References: <4FBCB979.8020501@ipax.at>
Message-ID: <CAArzuov9Su1=CJrZjVOXuUzf4rfVbOyV8i4Bfhnj9M4mEc3qcw@mail.gmail.com>

This is HD Moore's latest experiment.  It is annoying for sure but
well .. he's doing it for research, and you can either acl off his
probes or email him and he'll exempt your ASN from whatever scanning
he is doing.

On Wed, May 23, 2012 at 3:48 PM, Raoul Bhatia [IPAX] <r.bhatia at ipax.at> wrote:
>
> * 184.154.42.194 / critical.io
> * 69.64.43.135 / research1.critical.io
> * 69.64.43.137 / research2.critical.io
> * 69.64.43.142 / research3.critical.io
> * 50.116.22.209



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From brunner at nic-naa.net  Wed May 23 06:19:20 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 23 May 2012 07:19:20 -0400
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <20120523054016.GA23944@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <20120523054016.GA23944@vacation.karoshi.com.>
Message-ID: <4FBCC7B8.4050204@nic-naa.net>

On 5/23/12 1:40 AM, bmanning at vacation.karoshi.com wrote:
>  In a modestly favorable light, ISC looks like an arms dealer (DNS redirection)
> 	to the bad guys

my thought "looks like a reasonably successful alternate root operator".

i mention kevin dunlap as well as bill's mention of phil almquist, and
there's another 4th floor of evans hall name i nay recall when caffinated.

-e


From alvaro.vives at consulintel.es  Wed May 23 06:24:28 2012
From: alvaro.vives at consulintel.es (Alvaro Vives)
Date: Wed, 23 May 2012 13:24:28 +0200
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A80D39A765@dfweml513-mbx.china.huawei.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
 <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
 <C0E0A32284495243BDE0AC8A066631A80D39A765@dfweml513-mbx.china.huawei.com>
Message-ID: <004201cd38d6$9e550060$daff0120$@vives@consulintel.es>

In the radio interface?
Something in the GUI?

Alvaro

-----Mensaje original-----
De: Tina TSOU [mailto:Tina.Tsou.Zouting at huawei.com] 
Enviado el: mi?rcoles, 23 de mayo de 2012 2:03
Para: PC; Paul Graydon
CC: nanog at nanog.org
Asunto: RE: Current IPv6 state of US Mobile Phone Carriers

iOS 5.1 includes SLAAC and DHCPv6 client.

Tina


> -----Original Message-----
> From: PC [mailto:paul4004 at gmail.com]
> Sent: Tuesday, May 22, 2012 4:59 PM
> To: Paul Graydon
> Cc: nanog at nanog.org
> Subject: Re: Current IPv6 state of US Mobile Phone Carriers
> 
> IPV6 is present, to my knowledge, on all devices on the Verizon IPV6 
> LTE network.  I noticed its using it to communicate to Google for many 
> of it's services when I ran a netstat.  I believe they mandated 
> support for it from any certified device.
> 
> Unfortunately, it's still firewalled.
> 
> 
> On Tue, May 22, 2012 at 5:40 PM, Paul Graydon <paul at paulgraydon.co.uk>
> wrote:
> > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> >>
> >> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp> ?wrote:
> >>>
> >>> Hi NANOG,
> >>>
> >>> I'm looking for some information on the four largest US mobile 
> >>> phone carriers and the current state of their IPv6 infrastructure.
> >>> Specifically,
> >>> we are trying to figure out:
> >>>
> >>> 1. ?How much of the carrier core and edge for AT&T, Verizon. 
> >>> T-Mobile, and Sprint are on IPv6 now?
> >>
> >> Hi,
> >>
> >> T-Mobile USA has native ipv6 to all subscribers in all of it's 
> >> coverage area. But, less than 1% of subscribers use IPv6 because 
> >> they do not
> have
> >> an
> >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> >>
> >> This device challenge will improve in time. ?Samsung is doing a 
> >> good
> job
> >> of
> >> bringing IPv6 to Android devices. More info here
> >
> > That's interesting. ?I have a Galaxy Nexus on T-Mobile USA and it
> doesn't
> > get an IPv6 address, only IPv4. ?Works fine with IPv6 over my 
> > wireless network at home. ?Doesn't seem to be anything obvious in 
> > the settings to enable or disable that.
> >
> > Paul
> >




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.





From jamie at photon.com  Wed May 23 06:36:09 2012
From: jamie at photon.com (Jamie Bowden)
Date: Wed, 23 May 2012 11:36:09 +0000
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAL9jLabc=cQdrQZt3DAeDwqx5f+eXTb9x8Gj=40V5wMQ3MRZhg@mail.gmail.com>
References: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
 <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>
 <CAL9jLabc=cQdrQZt3DAeDwqx5f+eXTb9x8Gj=40V5wMQ3MRZhg@mail.gmail.com>
Message-ID: <465966A5F5B867419F604CD3E604C1E505C80C7A@pra-ess-mail.pra.ray.com>

> From: Christopher Morrow [mailto:morrowc.lists at gmail.com]
> On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter
> <rcarpen at network1.net> wrote:
> >
> > Not only does Verizon *not* have IPv6 on their LTE network, they also
> do *not* have IPv4, except for double-NATed rfc1918 crap that changes
> your IP address every couple minutes. The only way to get a stable
> connection is to pay them $500 to get a static public IP address.
> >
> 
> wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
> was able to browse some ipv6-only sites.


My Moto Droid RAZR is most definitely IPv6 over LTE.

Jamie


From geier at geier.ne.tz  Wed May 23 07:10:38 2012
From: geier at geier.ne.tz (Frank Habicht)
Date: Wed, 23 May 2012 15:10:38 +0300
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <m2zk8zbmdy.wl%randy@psg.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
Message-ID: <4FBCD3BE.5000709@geier.ne.tz>

Hi,

> dnschanger gonna be a mess?  that's not news.

Is there anywhere a page where one can type an ASN or a CIDR block and 
then the whois contacts get a list of IPs that still contact the 
unintended servers?

(I had done ACL with log on borders, and resolvers did show up too.
  So maybe some NS pointing towards those "bad" blocks?)

Thanks,
Frank


From bortzmeyer at nic.fr  Wed May 23 07:28:58 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 23 May 2012 14:28:58 +0200
Subject: Vixie warns: DNS Changer ?blackouts? inevitable
In-Reply-To: <4FBCD3BE.5000709@geier.ne.tz>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <4FBCD3BE.5000709@geier.ne.tz>
Message-ID: <20120523122858.GA15606@nic.fr>

On Wed, May 23, 2012 at 03:10:38PM +0300,
 Frank Habicht <geier at geier.ne.tz> wrote 
 a message of 13 lines which said:

> Is there anywhere a page where one can type an ASN or a CIDR block
> and then the whois contacts get a list of IPs that still contact the
> unintended servers?

See <http://www.dcwg.org/isps/>


From nanog at namor.ca  Wed May 23 10:22:08 2012
From: nanog at namor.ca (nanog at namor.ca)
Date: Wed, 23 May 2012 10:22:08 -0500 (CDT)
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <92E13493-8598-4FD2-8027-8DAF0EF02042@kapu.net>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <m2bolfbg8r.wl%randy@psg.com> <92E13493-8598-4FD2-8027-8DAF0EF02042@kapu.net>
Message-ID: <Pine.LNX.4.64.1205231013270.23985@e232.namor.ca>

On Tue, 22 May 2012, Michael J Wise wrote:

> So at some point, the lights are gonna be turned off.
> It's a shame the ISPs who have the infected users have done less to mitigate the issue.

To be fair, and take issue with this, it's not all on the ISPs, is it?

I've been seeing our counts decrease for months, but there are some who 
will not/cannot get it.

I am sadistically looking forward to the shutdown, admittedly.


From jra at baylink.com  Wed May 23 11:24:10 2012
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 23 May 2012 12:24:10 -0400 (EDT)
Subject: =?utf-8?Q?Re:_Vixie_warns:_DNS_Chan?=
 =?utf-8?Q?ger_=E2=80=98blackouts=E2=80=99_inevitable?=
In-Reply-To: <20120523033910.GA23282@vacation.karoshi.com.>
Message-ID: <2918014.5654.1337790250101.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: bmanning at vacation.karoshi.com

> On Tue, May 22, 2012 at 07:14:16PM -0700, Henry Linneweh wrote:
> > http://www.theregister.co.uk/2012/05/17/dns_changer_blackouts/
> 
> Paul certainly knows how to manipulate the press.

You don't know journalists very well, do you? 

Paul almost certainly (p > 0.995) had nothing to do with the writer's
chosen appellation, and wouldn't have been able to change it if he had.

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 kyle.creyts at gmail.com  Wed May 23 11:49:58 2012
From: kyle.creyts at gmail.com (Kyle Creyts)
Date: Wed, 23 May 2012 12:49:58 -0400
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <2918014.5654.1337790250101.JavaMail.root@benjamin.baylink.com>
References: <20120523033910.GA23282@vacation.karoshi.com.>
 <2918014.5654.1337790250101.JavaMail.root@benjamin.baylink.com>
Message-ID: <CA+TcGd-Vkc4j92Y9mTgoZd1BYu8ZfGLFzrAtDvNN4LXeUoBXqg@mail.gmail.com>

It makes for a more sensational story.

On Wed, May 23, 2012 at 12:24 PM, Jay Ashworth <jra at baylink.com> wrote:
> ----- Original Message -----
>> From: bmanning at vacation.karoshi.com
>
>> On Tue, May 22, 2012 at 07:14:16PM -0700, Henry Linneweh wrote:
>> > http://www.theregister.co.uk/2012/05/17/dns_changer_blackouts/
>>
>> Paul certainly knows how to manipulate the press.
>
> You don't know journalists very well, do you?
>
> Paul almost certainly (p > 0.995) had nothing to do with the writer's
> chosen appellation, and wouldn't have been able to change it if he had.
>
> 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
>



-- 
Kyle Creyts

Information Assurance Professional
BSidesDetroit Organizer


From Tina.Tsou.Zouting at huawei.com  Wed May 23 13:18:35 2012
From: Tina.Tsou.Zouting at huawei.com (Tina TSOU)
Date: Wed, 23 May 2012 18:18:35 +0000
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <004201cd38d6$9e550060$daff0120$@vives@consulintel.es>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
 <CAD6AjGT7jZzjLoLYVX_U4DsCxMPRxDu5yepphCMKJbbypLWg4Q@mail.gmail.com>
 <4FBC23D8.5040109@paulgraydon.co.uk>
 <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
 <C0E0A32284495243BDE0AC8A066631A80D39A765@dfweml513-mbx.china.huawei.com>,
 <004201cd38d6$9e550060$daff0120$@vives@consulintel.es>
Message-ID: <766631F7-74EC-4360-B3C2-46E42FF9256D@huawei.com>

For DHCPv6 client, there is no GUI.

Tina

On May 23, 2012, at 4:24 AM, "Alvaro Vives" <alvaro.vives at consulintel.es> wrote:

> DHCPv6 client


From jabley at hopcount.ca  Wed May 23 14:38:31 2012
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 23 May 2012 15:38:31 -0400
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <20120523041040.GC23282@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
Message-ID: <30EEFFBF-7809-4C98-A649-39543F7DF8DF@hopcount.ca>


On 2012-05-23, at 00:10, bmanning at vacation.karoshi.com wrote:

> 		BIND - The Berkeley Internet Naming Daemon.

"Berkeley Internet Name Domain", in fact.

http://www.eecs.berkeley.edu/Pubs/TechRpts/1984/CSD-84-182.pdf


Joe



From frnkblk at iname.com  Wed May 23 14:58:27 2012
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Wed, 23 May 2012 14:58:27 -0500
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>
References: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
 <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADjGdMFxyKySJ/5Y6sSj2paAQAAAAA=@iname.com>

Here's a screenshot from 15 months ago:
http://www.fix6.net/archives/2011/02/21/ipv6-live-on-verizons-lte-network/

Frank

-----Original Message-----
From: Randy Carpenter [mailto:rcarpen at network1.net]
Sent: Tuesday, May 22, 2012 9:07 PM
To: PC
Cc: nanog at nanog.org
Subject: Re: Current IPv6 state of US Mobile Phone Carriers


Not only does Verizon *not* have IPv6 on their LTE network, they also do *not* 
have IPv4, except for double-NATed rfc1918 crap that changes your IP address 
every couple minutes. The only way to get a stable connection is to pay them 
$500 to get a static public IP address.

thanks,
-Randy


----- Original Message -----
> IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
> LTE network.  I noticed its using it to communicate to Google for
> many
> of it's services when I ran a netstat.  I believe they mandated
> support for it from any certified device.
>
> Unfortunately, it's still firewalled.
>
>
> On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
> <paul at paulgraydon.co.uk> wrote:
> > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> >>
> >> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp>
> >>  wrote:
> >>>
> >>> Hi NANOG,
> >>>
> >>> I'm looking for some information on the four largest US mobile
> >>> phone
> >>> carriers and the current state of their IPv6 infrastructure.
> >>> Specifically,
> >>> we are trying to figure out:
> >>>
> >>> 1.  How much of the carrier core and edge for AT&T, Verizon.
> >>> T-Mobile,
> >>> and
> >>> Sprint are on IPv6 now?
> >>
> >> Hi,
> >>
> >> T-Mobile USA has native ipv6 to all subscribers in all of it's
> >> coverage
> >> area. But, less than 1% of subscribers use IPv6 because they do
> >> not have
> >> an
> >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> >>
> >> This device challenge will improve in time.  Samsung is doing a
> >> good job
> >> of
> >> bringing IPv6 to Android devices. More info here
> >
> > That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it
> > doesn't
> > get an IPv6 address, only IPv4.  Works fine with IPv6 over my
> > wireless
> > network at home.  Doesn't seem to be anything obvious in the
> > settings to
> > enable or disable that.
> >
> > Paul
> >
>
>
>






From bicknell at ufp.org  Wed May 23 15:09:09 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 23 May 2012 13:09:09 -0700
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <m2zk8zbmdy.wl%randy@psg.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
Message-ID: <20120523200909.GA86641@ussenterprise.ufp.org>

In a message written on Wed, May 23, 2012 at 12:35:05PM +0900, Randy Bush wrote:
> father of bind?  that's news.

I believe the error is in Paul Vixie's Wikipedia page, and I don't
do Wikipedia editing so I won't be fixing it.

http://en.wikipedia.org/wiki/Paul_Vixie

  "In 1988, while employed by DEC, he started working on the popular
   internet domain name server BIND, of which he was the primary author and
   architect, until release 8."

ISC has spent some effort on properly documenting the history of
BIND, and the result of that effort is located at:

http://www.isc.org/software/bind/history

You'll note there are two full paragraphs and a dozen folks involved
before Paul had anything to do with BIND.

ISC is always interested in updating the history if folks have any
additional information.  Feel free to e-mail me if you think you have
something important to add.

-- 
       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/20120523/00ed1780/attachment.bin>

From mjwise at kapu.net  Wed May 23 15:23:33 2012
From: mjwise at kapu.net (Michael J Wise)
Date: Wed, 23 May 2012 13:23:33 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts?=
 =?windows-1252?Q?=92_inevitable?=
In-Reply-To: <Pine.LNX.4.64.1205231013270.23985@e232.namor.ca>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <m2bolfbg8r.wl%randy@psg.com> <92E13493-8598-4FD2-8027-8DAF0EF02042@kapu.net>
 <Pine.LNX.4.64.1205231013270.23985@e232.namor.ca>
Message-ID: <4C498CD4-721D-49F2-BFFE-AB8BC010878A@kapu.net>


On May 23, 2012, at 8:22 AM, nanog at namor.ca wrote:

> On Tue, 22 May 2012, Michael J Wise wrote:
> 
>> So at some point, the lights are gonna be turned off.
>> It's a shame the ISPs who have the infected users have done less to mitigate the issue.
> 
> To be fair, and take issue with this, it's not all on the ISPs, is it?

Agreed.
By definition, the numbers have been falling.
So somewhere, someone is doing something to lessen the coming /facepalm

> I've been seeing our counts decrease for months, but there are some who will not/cannot get it.
> 
> I am sadistically looking forward to the shutdown, admittedly.

You have your time off approved I trust? :)

Aloha,
Michael.
-- 
"Please have your Internet License             
 and Usenet Registration handy..."



From morrowc.lists at gmail.com  Wed May 23 15:33:28 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 23 May 2012 16:33:28 -0400
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
Message-ID: <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>

On Wed, May 23, 2012 at 1:40 AM,  <bmanning at vacation.karoshi.com> wrote:
> Paul will be there to turn things off when
> ? ? ? ?they no longer make money for his company.

is the dns changer thingy making money for isc?


From jackson.tim at gmail.com  Wed May 23 15:51:43 2012
From: jackson.tim at gmail.com (Tim Jackson)
Date: Wed, 23 May 2012 15:51:43 -0500
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADjGdMFxyKySJ/5Y6sSj2paAQAAAAA=@iname.com>
References: <CAJAdsDmfnw6V1YizfaE2oE7GUXV84fL+LOF4s0X5xfNMPRQ_0Q@mail.gmail.com>
 <d0478146-d36c-4711-a670-5f1f3ae00d65@zimbra.network1.net>
 <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADjGdMFxyKySJ/5Y6sSj2paAQAAAAA=@iname.com>
Message-ID: <CAK19Y1d+3a0atDnFVWv6ZboJ58rcKfUdx3DBoZnTZKMYsSA2CA@mail.gmail.com>

http://i.imgur.com/c0Bmz.jpg

>From a few minutes ago...
On May 23, 2012 2:58 PM, "Frank Bulk - iName.com" <frnkblk at iname.com> wrote:

> Here's a screenshot from 15 months ago:
> http://www.fix6.net/archives/2011/02/21/ipv6-live-on-verizons-lte-network/
>
> Frank
>
> -----Original Message-----
> From: Randy Carpenter [mailto:rcarpen at network1.net]
> Sent: Tuesday, May 22, 2012 9:07 PM
> To: PC
> Cc: nanog at nanog.org
> Subject: Re: Current IPv6 state of US Mobile Phone Carriers
>
>
> Not only does Verizon *not* have IPv6 on their LTE network, they also do
> *not*
> have IPv4, except for double-NATed rfc1918 crap that changes your IP
> address
> every couple minutes. The only way to get a stable connection is to pay
> them
> $500 to get a static public IP address.
>
> thanks,
> -Randy
>
>
> ----- Original Message -----
> > IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
> > LTE network.  I noticed its using it to communicate to Google for
> > many
> > of it's services when I ran a netstat.  I believe they mandated
> > support for it from any certified device.
> >
> > Unfortunately, it's still firewalled.
> >
> >
> > On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
> > <paul at paulgraydon.co.uk> wrote:
> > > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> > >>
> > >> On May 22, 2012 4:00 PM, "Paul Porter"<paul.porter at gree.co.jp>
> > >>  wrote:
> > >>>
> > >>> Hi NANOG,
> > >>>
> > >>> I'm looking for some information on the four largest US mobile
> > >>> phone
> > >>> carriers and the current state of their IPv6 infrastructure.
> > >>> Specifically,
> > >>> we are trying to figure out:
> > >>>
> > >>> 1.  How much of the carrier core and edge for AT&T, Verizon.
> > >>> T-Mobile,
> > >>> and
> > >>> Sprint are on IPv6 now?
> > >>
> > >> Hi,
> > >>
> > >> T-Mobile USA has native ipv6 to all subscribers in all of it's
> > >> coverage
> > >> area. But, less than 1% of subscribers use IPv6 because they do
> > >> not have
> > >> an
> > >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> > >>
> > >> This device challenge will improve in time.  Samsung is doing a
> > >> good job
> > >> of
> > >> bringing IPv6 to Android devices. More info here
> > >
> > > That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it
> > > doesn't
> > > get an IPv6 address, only IPv4.  Works fine with IPv6 over my
> > > wireless
> > > network at home.  Doesn't seem to be anything obvious in the
> > > settings to
> > > enable or disable that.
> > >
> > > Paul
> > >
> >
> >
> >
>
>
>
>
>
>

From bmanning at vacation.karoshi.com  Wed May 23 16:00:27 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 23 May 2012 21:00:27 +0000
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
Message-ID: <20120523210027.GA26231@vacation.karoshi.com.>

On Wed, May 23, 2012 at 04:33:28PM -0400, Christopher Morrow wrote:
> On Wed, May 23, 2012 at 1:40 AM,  <bmanning at vacation.karoshi.com> wrote:
> > Paul will be there to turn things off when
> >        they no longer make money for his company.
> 
> is the dns changer thingy making money for isc?

	pretty sure.  a contract w/ the Feds, outsouring contracts w/ affected ISPs
	when the Fed deal runs out, development funding to code these kinds of fixes 
	into future versions of software, any number of second and third order fallout.
	No telling how effective constent self-promotion is.  One thing is clear, Paul
	is able to tell a great story.
	
	but its all speculation from here. ISC is well positioned to extract value
	from both ends of the spectrum.  They have a great business model. The optics
	look pretty odd from here, at lesat to me however - I am very glad for: )open 
	source & )other vendors of DNS SW.

/bill


From sginsberg at pandora.com  Wed May 23 16:07:10 2012
From: sginsberg at pandora.com (Steve Ginsberg)
Date: Wed, 23 May 2012 14:07:10 -0700
Subject: NANOG 55 Peering Track agenda and announcements
Message-ID: <08C1A9DA-2C19-42EA-AAF9-284CAD92DB9A@pandora.com>

Hi All,

Here's the current plan for the Peering BOF.

Session will take place on Monday, June 4, 2012 from 4:30 PM to 6:00 PM in Salon D-F

Please join us for a lively discussion.

NANOG Peering BoF 90 minutes

Introductions and PeeringDB PSA 5min
Peering Personals Part I 5min
LinkedIN Presentation/Discussion 20min
IX Updates 5 min
Peering Personals Part 2 5-10 min
Pandora Presentation/Discussion 20min
Mobile/Peering Changes Discussion 20 min

* If you'd like to be part of new Peering Personals - a chance to announce your intention to peer - we'd love to meet you. Please email me off-list with
Name, Organization, and URL in Peeringdb by next Monday.

* If you're an IX and want to be part of the IX update, please email me directly for the slide template. I'll send it to you so you can submit 1-3 (no more) PowerPoint slides which can be rolled with out narration, by next Monday. 

* I'd also like to speak to some more folks who work for the Mobile carriers so please get in touch if you'd like to help.


~Steve 
http://www.pandora.com/profile/peace
https://www.peeringdb.com/private/participant_view.php?id=1407
for peering requests please send to peering at pandora.com


From rcarpen at network1.net  Wed May 23 16:07:13 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Wed, 23 May 2012 17:07:13 -0400 (EDT)
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAK19Y1d+3a0atDnFVWv6ZboJ58rcKfUdx3DBoZnTZKMYsSA2CA@mail.gmail.com>
Message-ID: <23bba007-d8c2-41e6-b8fb-5bf842d8b53d@zimbra.network1.net>


Looks like some devices have it enabled, and some do not.

Does anyone have hotspot enabled? I am curious as to if IPv6 is being done via the hotspot, and how they are handling the prefix delegation.


thanks,
-Randy



----- Original Message -----
> 
> 
> http://i.imgur.com/c0Bmz.jpg
> 
> From a few minutes ago...
> On May 23, 2012 2:58 PM, "Frank Bulk - iName.com" < frnkblk at iname.com
> > wrote:
> 
> 
> Here's a screenshot from 15 months ago:
> http://www.fix6.net/archives/2011/02/21/ipv6-live-on-verizons-lte-network/
> 
> Frank
> 
> -----Original Message-----
> From: Randy Carpenter [mailto: rcarpen at network1.net ]
> Sent: Tuesday, May 22, 2012 9:07 PM
> To: PC
> Cc: nanog at nanog.org
> Subject: Re: Current IPv6 state of US Mobile Phone Carriers
> 
> 
> Not only does Verizon *not* have IPv6 on their LTE network, they also
> do *not*
> have IPv4, except for double-NATed rfc1918 crap that changes your IP
> address
> every couple minutes. The only way to get a stable connection is to
> pay them
> $500 to get a static public IP address.
> 
> thanks,
> -Randy
> 
> 
> ----- Original Message -----
> > IPV6 is present, to my knowledge, on all devices on the Verizon
> > IPV6
> > LTE network. I noticed its using it to communicate to Google for
> > many
> > of it's services when I ran a netstat. I believe they mandated
> > support for it from any certified device.
> > 
> > Unfortunately, it's still firewalled.
> > 
> > 
> > On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
> > < paul at paulgraydon.co.uk > wrote:
> > > On 05/22/2012 01:21 PM, Cameron Byrne wrote:
> > >> 
> > >> On May 22, 2012 4:00 PM, "Paul Porter"< paul.porter at gree.co.jp >
> > >> wrote:
> > >>> 
> > >>> Hi NANOG,
> > >>> 
> > >>> I'm looking for some information on the four largest US mobile
> > >>> phone
> > >>> carriers and the current state of their IPv6 infrastructure.
> > >>> Specifically,
> > >>> we are trying to figure out:
> > >>> 
> > >>> 1. How much of the carrier core and edge for AT&T, Verizon.
> > >>> T-Mobile,
> > >>> and
> > >>> Sprint are on IPv6 now?
> > >> 
> > >> Hi,
> > >> 
> > >> T-Mobile USA has native ipv6 to all subscribers in all of it's
> > >> coverage
> > >> area. But, less than 1% of subscribers use IPv6 because they do
> > >> not have
> > >> an
> > >> IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
> > >> 
> > >> This device challenge will improve in time. Samsung is doing a
> > >> good job
> > >> of
> > >> bringing IPv6 to Android devices. More info here
> > > 
> > > That's interesting. I have a Galaxy Nexus on T-Mobile USA and it
> > > doesn't
> > > get an IPv6 address, only IPv4. Works fine with IPv6 over my
> > > wireless
> > > network at home. Doesn't seem to be anything obvious in the
> > > settings to
> > > enable or disable that.
> > > 
> > > Paul
> > > 
> > 
> > 
> > 
> 
> 
> 
> 
> 
> 


From cb.list6 at gmail.com  Wed May 23 16:18:05 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 23 May 2012 14:18:05 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <23bba007-d8c2-41e6-b8fb-5bf842d8b53d@zimbra.network1.net>
References: <CAK19Y1d+3a0atDnFVWv6ZboJ58rcKfUdx3DBoZnTZKMYsSA2CA@mail.gmail.com>
 <23bba007-d8c2-41e6-b8fb-5bf842d8b53d@zimbra.network1.net>
Message-ID: <CAD6AjGS2F+LZuvq039b4Esr+GpjjehotpKrXeHY6WaZGJd1Feg@mail.gmail.com>

On Wed, May 23, 2012 at 2:07 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>
> Looks like some devices have it enabled, and some do not.
>
> Does anyone have hotspot enabled? I am curious as to if IPv6 is being done via the hotspot, and how they are handling the prefix delegation.
>
>

On T-Mobile, this code works for IPv6 + IPv4 HotSpot / WiFi tethering
on the Nexus S http://dan.drown.org/android/clat/

Galaxy Nexus S ROM of the same function here
https://groups.google.com/group/tmoipv6beta/browse_thread/thread/ba8aac8063735e2a

Mainline Android does not yet have an IPv6 tethering feature, but the
code has been pushed upstream to Android for review
https://android-review.googlesource.com/#/c/34490/


Cameron


From rodrick.brown at gmail.com  Wed May 23 17:47:45 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Wed, 23 May 2012 18:47:45 -0400
Subject: Equinix Tyoko service provider
Message-ID: <C3D5CBE1-7575-46C8-BCD0-ACCA29DCAFA0@gmail.com>

Can anyone recommended an Internet service provider with presence in Equinix-TKO. I'm looking to implement VPN access as means for backup access for a handful of collocated servers in this facility.

I have a small branch office in Jersey City with about 10 users that would access this link for contingency purposes only. In terms of hardware I'm thinking an ASA5505 will fit the bill.

Any pitfalls I should be aware of?

Feel free to contact me off list. 

Thanks. 

Sent from my iPhone

From mike.lyon at gmail.com  Wed May 23 18:10:05 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Wed, 23 May 2012 16:10:05 -0700
Subject: Any mail peeps from Rackspace?
Message-ID: <CAFFgAjBbELwTt_9rwH1um6dhf496fWxzQOqEvYr5aTq=zWM1Kw@mail.gmail.com>

Howdy,

Looking for a mail admin at Rackspace to help troubleshoot some issues.
Please hit me up off-list.

Thank You,
Mike


-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon

From vixie at isc.org  Wed May 23 19:28:32 2012
From: vixie at isc.org (paul vixie)
Date: Thu, 24 May 2012 00:28:32 +0000
Subject: vixie, father of multitudes
Message-ID: <4FBD80B0.5080903@isc.org>

thanks to several folks who let me know this was going on. i hadn't even
noticed that i wasn't getting nanog at . thanks to seclists.org for hosting
an archive i could use.

---

From: bmanning () vacation karoshi com
Date: Wed, 23 May 2012 05:40:16 +0000

On Tue, May 22, 2012 at 10:07:52PM -0700, Michael J Wise wrote:

    On May 22, 2012, at 9:10 PM, bmanning () vacation karoshi com wrote:


        On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote:

            On May 22, 2012, at 8:35 PM, Randy Bush wrote:


                father of bind?  that's news.

              
<http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html>

            He was there, and Put The Fix In, to down the network.

            Certainly news to Phil Almquist and the entire BIND
development team
            at UCB.   Paul was at DECWRL and cut his teeth on
pre-existing code.
            While he (and ISC) have since revised, gutted, tossed all
the orginal
            code, rebuilt it twice - and others have done similar for
their DNS
            software,  based on the BIND code base, implementation
assumptions, and
            with little or no ISC code, and they call it BIND as well, 
it would be
            a HUGE leap of faith to call Paul Vixie the father of
                    BIND - The Berkeley Internet Naming Daemon.

    Methinks we're talking at cross purposes.

        maybe... :)  my comment was refering to the "father of bind"
statement.

i don't describe myself that way. i inherited bind at 4.8.3 and fixed
stuff. i
rewrote a lot of it for 4.9.

we (mostly me but with huge work by robert halley and mark andrews)
rewrote most of
it for bind 8.1. (there was no 8.0.) other people (not me) wrote bind
9.x. other
people (mostly not the same people) are writing bind 10.

if my wikipedia entry is wrong in this regard i invite folks to fix it.
last i
heard it's disallowed for people to edit their own entries, so i have
not tried.

i am not the father of anything, except four healthy kids. i do
sometimes call
myself "the wierd uncle of the internet" but "father of bind" is not
what i mean.


            As for being there and "Put The Fix In"...  Makes for great
PR but
            in actual fact, its a bandaid that is not going to stem the
tide.
            An actual fix would really need to change the nature of the
creaky
            1980's implementation artifacts that this community loves so
well.

    I don't think we're talking about the same thing at all.
    Paul was there to shut down the DNS changer system and replace it
with something that restored functionality to the
    infected machines.
    And I gather Paul will be one of the people who will turn the lights
out on it.

yes, and yes.

        He didn't "shut down" DNS Changer, he put up an equivalent
system to hijack
        DNS traffic and direct it to the "right" place...  SO folks
didn't see any
        problem and the DNS Changer infection grew and got worse.  When
he is legally
        required to take his "bandaide" out of service, then the problem
will resolve
        by folks who will have to clean their systems.

it's true, the fbi team who powered all that stuff off and loaded it into a
u-haul truck are the ones who "shut down dns changer". or perhaps it was the
police in estonia who arrested all those people. i'm not the shutter-downer.

        As for "turning the lights out" - that will only happen when the
value of
        DNS hijacking drops.   As it is now,  ISC has placed DNS
hijacking code
        into their mainstream code base... because DNS hijacking is so
valuable to
        folks.  In a modestly favorable light, ISC looks like an arms
dealer (DNS redirection)
        to the bad guys -AND- (via DNSSEC) the good guys.  Either way,
they make money.

well, no. but that seems off-topic. start a new thread if you care.
(and, cc me!)

        And yes, I think I agree with you.  Paul will be there to turn
things off when
        they no longer make money for his company.

well, no. when the court order runs out we will have to shut things
down. but the
money FBI is paying us for this is just to cover costs. and, it's not my
company.
isc is a 501(c)(3), basically a ward of the state of delaware, having no
shares
and therefore no shareholders.
 

    Your other comments are non-sequitur to the main issue.

        Perhaps I am not a member of the Paul Vixie cult of personality.  

so sad.


    When those servers are turned off, Customer Support folks at many
ISPs will prolly want to take their accrued
    vacation.

        Amen.  And there will be thousands more of them when the court
order expires than
        existed when the Feds called him in.

um. no. hundreds of thousands less than before the feds called ISC in.
see dcwg.org.

it's lovely to have so many fans. keep those cards and letters coming.
(but, cc me!)

paul



From valdis.kletnieks at vt.edu  Wed May 23 19:42:18 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Wed, 23 May 2012 20:42:18 -0400
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: Your message of "Wed, 23 May 2012 13:09:09 -0700."
 <20120523200909.GA86641@ussenterprise.ufp.org>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <20120523200909.GA86641@ussenterprise.ufp.org>
Message-ID: <33756.1337820138@turing-police.cc.vt.edu>

On Wed, 23 May 2012 13:09:09 -0700, Leo Bicknell said:

>   "In 1988, while employed by DEC, he started working on the popular
>    internet domain name server BIND, of which he was the primary author and
>    architect, until release 8."
>
> ISC has spent some effort on properly documenting the history of
> BIND, and the result of that effort is located at:
>
> http://www.isc.org/software/bind/history
>
> You'll note there are two full paragraphs and a dozen folks involved
> before Paul had anything to do with BIND.

One could make the case that the releases before Paul got there weren't
exactly popular - how many DNS servers were in production in 1986? ;)

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

From george.herbert at gmail.com  Wed May 23 20:27:02 2012
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 23 May 2012 18:27:02 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <33756.1337820138@turing-police.cc.vt.edu>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
Message-ID: <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>

On Wed, May 23, 2012 at 5:42 PM,  <valdis.kletnieks at vt.edu> wrote:
> On Wed, 23 May 2012 13:09:09 -0700, Leo Bicknell said:
>
>> ? "In 1988, while employed by DEC, he started working on the popular
>> ? ?internet domain name server BIND, of which he was the primary author and
>> ? ?architect, until release 8."
>>
>> ISC has spent some effort on properly documenting the history of
>> BIND, and the result of that effort is located at:
>>
>> http://www.isc.org/software/bind/history
>>
>> You'll note there are two full paragraphs and a dozen folks involved
>> before Paul had anything to do with BIND.
>
> One could make the case that the releases before Paul got there weren't
> exactly popular - how many DNS servers were in production in 1986? ;)

Please don't make me remember hosts.txt before I've had a chance to
wrap up work, go home, and get some Scotch in...


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


From brett at the-watsons.org  Wed May 23 20:35:12 2012
From: brett at the-watsons.org (Brett Watson)
Date: Wed, 23 May 2012 18:35:12 -0700
Subject: =?utf-8?Q?Re:_Vixie_warns:_DNS_Changer_=E2=80=98blackouts?=
 =?utf-8?Q?=E2=80=99_inevitable?=
In-Reply-To: <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
 <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
Message-ID: <75E1CAFD-3D00-4231-961A-8FC74DC9F514@the-watsons.org>



On May 23, 2012, at 18:27, George Herbert <george.herbert at gmail.com> wrote:

> 
> Please don't make me remember hosts.txt before I've had a chance to
> wrap up work, go home, and get some Scotch in...
> 

Come on George, hosts.txt was the good old days :)

-b


From shrdlu at deaddrop.org  Wed May 23 20:42:34 2012
From: shrdlu at deaddrop.org (Lynda)
Date: Wed, 23 May 2012 18:42:34 -0700
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <75E1CAFD-3D00-4231-961A-8FC74DC9F514@the-watsons.org>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
 <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
 <75E1CAFD-3D00-4231-961A-8FC74DC9F514@the-watsons.org>
Message-ID: <4FBD920A.6050507@deaddrop.org>

On 5/23/2012 6:35 PM, Brett Watson wrote:

> On May 23, 2012, at 18:27, George Herbert<george.herbert at gmail.com>  wrote:

>> Please don't make me remember hosts.txt before I've had a chance to
>> wrap up work, go home, and get some Scotch in...

> Come on George, hosts.txt was the good old days :)

I still have a copy (from around 1992, so one of the very last), 
although much edited (and NOT 10,000 hosts, thanks).

-- 
A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately
described with pictures.



From george.herbert at gmail.com  Wed May 23 21:27:54 2012
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 23 May 2012 19:27:54 -0700
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <75E1CAFD-3D00-4231-961A-8FC74DC9F514@the-watsons.org>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
 <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
 <75E1CAFD-3D00-4231-961A-8FC74DC9F514@the-watsons.org>
Message-ID: <CAK__KztxNq35iFPVEYFC4F9ya1o1g3Cab2E9+6ZQHhMv5q01qA@mail.gmail.com>

On Wed, May 23, 2012 at 6:35 PM, Brett Watson <brett at the-watsons.org> wrote:
> On May 23, 2012, at 18:27, George Herbert <george.herbert at gmail.com> wrote:
>> Please don't make me remember hosts.txt before I've had a chance to
>> wrap up work, go home, and get some Scotch in...
>>
>
> Come on George, hosts.txt was the good old days :)


An elegant weapon, for a more civilized age?


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


From mjwise at kapu.net  Wed May 23 23:54:20 2012
From: mjwise at kapu.net (Michael J Wise)
Date: Wed, 23 May 2012 21:54:20 -0700
Subject: vixie, father of multitudes
In-Reply-To: <4FBD80B0.5080903@isc.org>
References: <4FBD80B0.5080903@isc.org>
Message-ID: <EB3AEDFC-A30B-4D14-8404-3004C0EAC3F7@kapu.net>


On May 23, 2012, at 5:28 PM, paul vixie wrote:

> it's lovely to have so many fans. keep those cards and letters coming.
> (but, cc me!)


Yessir!

Aloha,
Michael.
-- 
"Please have your Internet License             
 and Usenet Registration handy..."



From jhellenthal at dataix.net  Thu May 24 00:11:27 2012
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Thu, 24 May 2012 01:11:27 -0400
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <4FBD920A.6050507@deaddrop.org>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
 <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
 <75E1CAFD-3D00-4231-961A-8FC74DC9F514@the-watsons.org>
 <4FBD920A.6050507@deaddrop.org>
Message-ID: <20120524051127.GA59746@DataIX.net>



On Wed, May 23, 2012 at 06:42:34PM -0700, Lynda wrote:
> On 5/23/2012 6:35 PM, Brett Watson wrote:
> 
> > On May 23, 2012, at 18:27, George Herbert<george.herbert at gmail.com>  wrote:
> 
> >> Please don't make me remember hosts.txt before I've had a chance to
> >> wrap up work, go home, and get some Scotch in...
> 
> > Come on George, hosts.txt was the good old days :)
> 
> I still have a copy (from around 1992, so one of the very last), 
> although much edited (and NOT 10,000 hosts, thanks).
> 

ftp://ftp.math.ethz.ch/pub/doc/hosts.txt

Leftovers!

-- 

 - (2^(N-1))


From joly at punkcast.com  Thu May 24 00:54:36 2012
From: joly at punkcast.com (Joly MacFie)
Date: Thu, 24 May 2012 01:54:36 -0400
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <20120523200909.GA86641@ussenterprise.ufp.org>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <20120523200909.GA86641@ussenterprise.ufp.org>
Message-ID: <CAM9VJk0kYF1ZhrMUyzm=j=rTMhxDu1YKJxssTdXqYLHMTdvzgQ@mail.gmail.com>

The best policy, sometimes, when one sees something questionable on
Wikipedia, is to point it out on the talk page, and trust that others will
do the dirty work.. as in
http://en.wikipedia.org/wiki/Talk:Paul_Vixie#.22Father_of_BIND.22

j

On Wed, May 23, 2012 at 4:09 PM, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Wed, May 23, 2012 at 12:35:05PM +0900, Randy Bush
> wrote:
> > father of bind?  that's news.
>
> I believe the error is in Paul Vixie's Wikipedia page, and I don't
> do Wikipedia editing so I won't be fixing it.
>
> http://en.wikipedia.org/wiki/Paul_Vixie
>
>  "In 1988, while employed by DEC, he started working on the popular
>   internet domain name server BIND, of which he was the primary author and
>   architect, until release 8."
>
> ISC has spent some effort on properly documenting the history of
> BIND, and the result of that effort is located at:
>
> http://www.isc.org/software/bind/history
>
> You'll note there are two full paragraphs and a dozen folks involved
> before Paul had anything to do with BIND.
>
> ISC is always interested in updating the history if folks have any
> additional information.  Feel free to e-mail me if you think you have
> something important to add.
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>



-- 
---------------------------------------------------------------
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 bruns at 2mbit.com  Thu May 24 02:16:13 2012
From: bruns at 2mbit.com (Brielle Bruns)
Date: Thu, 24 May 2012 01:16:13 -0600
Subject: Qwest/CenturyLink implementing transparent proxies?
Message-ID: <4FBDE03D.6010104@2mbit.com>

Hello All,

A little off topic, but I was wondering if there's any Qwest/CenturyLink 
network engineers or techs lurking on this list that would contact me 
offlist?

I won't bore people with the details, but I'm seeing what appears to be 
a transparent proxy on some sites when visited from multiple clients 
(all with Qwest DSL).  When browsing on our non-Qwest circuits (such as 
the T1s), we do not see the same behaviors.

Its concerning to say the least, and something I'd like to get a clear 
and straight answer about.

Thanks!


-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org



From ken at infosec101.org  Thu May 24 03:47:51 2012
From: ken at infosec101.org (Ken Pfeil)
Date: Thu, 24 May 2012 04:47:51 -0400
Subject: =?utf-8?Q?Re:_Vixie_warns:_DNS_Changer_=E2=80=98blackouts?=
 =?utf-8?Q?=E2=80=99_inevitable?=
In-Reply-To: <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
 <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
Message-ID: <2D18166B-0B6B-4442-BF43-ED105512E41E@infosec101.org>

Save the good scotch for lmhosts :)



On May 23, 2012, at 9:27 PM, George Herbert <george.herbert at gmail.com> wrote:

> On Wed, May 23, 2012 at 5:42 PM,  <valdis.kletnieks at vt.edu> wrote:
>> On Wed, 23 May 2012 13:09:09 -0700, Leo Bicknell said:
>> 
>>>   "In 1988, while employed by DEC, he started working on the popular
>>>    internet domain name server BIND, of which he was the primary author and
>>>    architect, until release 8."
>>> 
>>> ISC has spent some effort on properly documenting the history of
>>> BIND, and the result of that effort is located at:
>>> 
>>> http://www.isc.org/software/bind/history
>>> 
>>> You'll note there are two full paragraphs and a dozen folks involved
>>> before Paul had anything to do with BIND.
>> 
>> One could make the case that the releases before Paul got there weren't
>> exactly popular - how many DNS servers were in production in 1986? ;)
> 
> Please don't make me remember hosts.txt before I've had a chance to
> wrap up work, go home, and get some Scotch in...
> 
> 
> -- 
> -george william herbert
> george.herbert at gmail.com
> 


From nick at foobar.org  Thu May 24 05:04:22 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 24 May 2012 11:04:22 +0100
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <20120523210027.GA26231@vacation.karoshi.com.>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
Message-ID: <4FBE07A6.7060405@foobar.org>

On 23/05/2012 22:00, bmanning at vacation.karoshi.com wrote:
> 	One thing is clear, Paul is able to tell a great story.

Bill, can you please take your snide remarks about Paul Vixie offline?

Nick


From notcommonmistakes at gmail.com  Thu May 24 07:50:47 2012
From: notcommonmistakes at gmail.com (not common)
Date: Thu, 24 May 2012 08:50:47 -0400
Subject: ISPs and full packet inspection
Message-ID: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>

Hello,

I am looking for some guidance on full packet inspection at the ISP level.

Is there any regulations that prohibit or provide guidance on this?

From deleskie at gmail.com  Thu May 24 07:53:48 2012
From: deleskie at gmail.com (jim deleskie)
Date: Thu, 24 May 2012 09:53:48 -0300
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <CAJL_ZMML+-F4D9r8-p4y4sYbAttLJ8ZYiv2jwBwDtf+bJH+Hbg@mail.gmail.com>

Asking for legal advice on NANOG is probably a REALLY REALLY bad idea.
Talk to a lawyer in the area(s) you do business.

-jim

On Thu, May 24, 2012 at 9:50 AM, not common <notcommonmistakes at gmail.com> wrote:
> Hello,
>
> I am looking for some guidance on full packet inspection at the ISP level.
>
> Is there any regulations that prohibit or provide guidance on this?


From toddunder at gmail.com  Thu May 24 07:58:19 2012
From: toddunder at gmail.com (Todd Underwood)
Date: Thu, 24 May 2012 08:58:19 -0400
Subject: RIPE 65 Call for Presentations/Papers
Message-ID: <CAB2RJyhGzLkdcp+t5mVBDnuCZ_5roDKx2hb7X1=nefBgNmPqBA@mail.gmail.com>

Fellow North American network-interested-and-involved folks:  In
September, RIPE will be back in Amsterdam and we're interested in
presentations.  Please see the appended Call for Presentations and let
me/us know if you have an interesting idea for a presentation, panel,
birds-of-a-feather sessions or a tutorial.  thanks!




Call for Presentations: RIPE 65

A RIPE Meeting is an open event where Internet Service Providers,
network operators and other interested parties get together. Although
the meeting is mostly technical, it is also a chance for people to
meet and network with others in their field.

RIPE 65 will take place on 24-28 September 2012 in Amsterdam, Netherlands.

The RIPE Programme Committee (PC) is now seeking content proposals
from the RIPE community for the Plenary, BoF and tutorial sessions at
RIPE 65. The PC is looking for presentations covering topics of
network engineering and operations, including but not limited to:

- IPv6 deployment
- Managing IPv4 scarcity in operations
- Commercial transactions of IPv4 addresses
- Data center technologies
- Network and DNS operations
- Internet governance and regulatory practices
- Network and routing security
- Content delivery
- Internet peering and mobile data exchange


Submissions

Attendees of the RIPE meetings are quite sensitive to keeping
presentations non-commercial, and product marketing talks are strongly
discouraged. Repeated audience feedback shows that the most successful
talks focus on operational experience, research results, or case
studies. For example, presenters wishing to describe a commercial
solution should focus on the underlying technology and not attempt a
product demonstration.

Presenters who are proposing a panel or BoF are encouraged to include
speakers from several (perhaps even competing) companies and/or a
neutral facilitator.

In addition to presentations selected in advance for the Plenary, the
RIPE PC also offers several time slots for ?lightning talks? which are
selected immediately before or during the conference.

The following requirements apply:

- Proposals for talks, BoFs and panels must be submitted for full
consideration no later than 1 July 2012, using the meeting submission
system at:

https://meetings.ripe.net/pc/

Proposals submitted after this date will be considered on a
space-available basis.

- Presenters should indicate how much time they will require (30
minutes for talks is a common maximum duration, although some talks
can be longer).

- Proposals for talks will only be considered by the PC if they
contain at least draft presentation slides (slides may be updated
later on). For BoFs and panels proposals must contain a clear
description as well as names of invited panelists/presenters.

- Due to potential technical issues, it is expected that most if not
all presenters/panelists will be physically present at the RIPE
meeting.

- Lightning talks should be submitted using the meeting submission
system. They must be short (10 minutes maximum) and often involve more
timely topics. They can be submitted at any time. The allocation of
lightning talk slots will be announced one day prior to the relevant
session.

If you have any questions or requests concerning content submissions,
please email pc [at] ripe [dot] net.

------

Todd Underwood
for the RIPE Program(me) Committee
toddunder at gmail.com


From bhmccie at gmail.com  Thu May 24 07:58:59 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 24 May 2012 07:58:59 -0500
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <4FBE3093.7090103@gmail.com>

You should be discussing this with inside counsel. Not NANOG.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 5/24/2012 7:50 AM, not common wrote:
> Hello,
>
> I am looking for some guidance on full packet inspection at the ISP level.
>
> Is there any regulations that prohibit or provide guidance on this?
> .
>


From notcommonmistakes at gmail.com  Thu May 24 08:13:16 2012
From: notcommonmistakes at gmail.com (not common)
Date: Thu, 24 May 2012 09:13:16 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <4FBE3093.7090103@gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
Message-ID: <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>

Thanks guys, I am looking for stuff to bring to my legal team (which is one
guy, that can't spell IP) and VPs.

There has to be some thing out there or is this really a hands of topic?

On Thu, May 24, 2012 at 8:58 AM, -Hammer- <bhmccie at gmail.com> wrote:

> You should be discussing this with inside counsel. Not NANOG.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
>
> On 5/24/2012 7:50 AM, not common wrote:
>
>> Hello,
>>
>> I am looking for some guidance on full packet inspection at the ISP level.
>>
>> Is there any regulations that prohibit or provide guidance on this?
>> .
>>
>>
>

From gabe at teksavvy.ca  Thu May 24 08:15:25 2012
From: gabe at teksavvy.ca (Gabriel Blanchard)
Date: Thu, 24 May 2012 09:15:25 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
Message-ID: <4FBE346D.5000500@teksavvy.ca>

might I suggest you consider replacing your legal team.

On 05/24/12 09:13, not common wrote:
> Thanks guys, I am looking for stuff to bring to my legal team (which is one
> guy, that can't spell IP) and VPs.
> 
> There has to be some thing out there or is this really a hands of topic?
> 
> On Thu, May 24, 2012 at 8:58 AM, -Hammer- <bhmccie at gmail.com> wrote:
> 
>> You should be discussing this with inside counsel. Not NANOG.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>>
>> On 5/24/2012 7:50 AM, not common wrote:
>>
>>> Hello,
>>>
>>> I am looking for some guidance on full packet inspection at the ISP level.
>>>
>>> Is there any regulations that prohibit or provide guidance on this?
>>> .
>>>
>>>
>>


From darden at armc.org  Thu May 24 08:19:04 2012
From: darden at armc.org (Patrick Darden)
Date: Thu, 24 May 2012 09:19:04 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <4FBE3548.2020500@armc.org>

0.  General Reference 
http://en.wikipedia.org/wiki/Deep_packet_inspection#DPI_at_network.2FInternet_service_providers  
e.g. Lawful Intercept

1.  network neutrality -- lots of possible laws coming up, 
http://en.wikipedia.org/wiki/Network_neutrality#Law_in_the_United_States  http://www.sans.org/reading_room/whitepapers/policyissues/net-neutrality-rest-peace_33809

2.  intellectual property -- all the sopa/pipa/etc. specifically privacy 
invasion 
http://en.wikipedia.org/wiki/Stop_Online_Piracy_Act#Deep-packet_inspection_and_privacy

3.  principle of implied responsibility -- if you change a data stream, 
it is implied you are responsible for it (i.e. administratively, 
editorially, etc.)

4.  Check out the CISSP legal domain.  Especially resources and 
references for it.  Someone on your team should have this 
certification.  
http://www.amazon.com/CISSP-Boxed-Set-All---One/dp/0071768459/ref=sr_1_1?ie=UTF8&qid=1337865477&sr=8-1

5.  The EFF might be able to help you.  WRT Privacy espec.

6.  SANS has tons of references.  www.sans.org

7.  Get with a lawyer who is network-aware.  Good luck with that.  Maybe 
try to find a lawyer with a CISSP cert?

--Patrick Darden


On 05/24/2012 08:50 AM, not common wrote:
> Hello,
>
> I am looking for some guidance on full packet inspection at the ISP level.
>
> Is there any regulations that prohibit or provide guidance on this?


From bhmccie at gmail.com  Thu May 24 08:22:25 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 24 May 2012 08:22:25 -0500
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
Message-ID: <4FBE3611.2060006@gmail.com>

The problem is that it is strictly a jurisdictional question. I'm not 
trying to throw it back at you. But I can't advise you w/o knowing the 
specifics of your ISP which I don't want to know. Does that make sense? 
What country? State? Where's your customer base? Do you have multiple 
carriers? Do you service DOD? Outside of US? Do you service EU? SWIFT 
(Financial wires?) etc? Mainly consumer? Commercial? The list could go on.

If you are being prodded by legal on this question then my advice would 
be to tell them that they have to provide that direction.

If you are being prodded by technology my advice would be to direct them 
to legal.

You should be picking up a pattern here....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 5/24/2012 8:13 AM, not common wrote:
> Thanks guys, I am looking for stuff to bring to my legal team (which 
> is one guy, that can't spell IP) and VPs.
>
> There has to be some thing out there or is this really a hands of topic?
>
> On Thu, May 24, 2012 at 8:58 AM, -Hammer- <bhmccie at gmail.com 
> <mailto:bhmccie at gmail.com>> wrote:
>
>     You should be discussing this with inside counsel. Not NANOG.
>
>     -Hammer-
>
>     "I was a normal American nerd"
>     -Jack Herer
>
>
>
>
>     On 5/24/2012 7:50 AM, not common wrote:
>
>         Hello,
>
>         I am looking for some guidance on full packet inspection at
>         the ISP level.
>
>         Is there any regulations that prohibit or provide guidance on
>         this?
>         .
>
>
>

From jcurran at istaff.org  Thu May 24 08:22:55 2012
From: jcurran at istaff.org (John Curran)
Date: Thu, 24 May 2012 09:22:55 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
Message-ID: <ED1D5BC5-1CA5-493E-BA44-2DDC99C64ECD@istaff.org>

On May 24, 2012, at 9:13 AM, not common wrote:

> Thanks guys, I am looking for stuff to bring to my legal team (which is one
> guy, that can't spell IP) and VPs.

One reasonably balanced and relatively recent overview for 
your legal folks to get oriented:

<http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1628024>

If that does not suffice, you have a more serious issue.

Best wishes,
/John



From bhmccie at gmail.com  Thu May 24 08:23:15 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 24 May 2012 08:23:15 -0500
Subject: ISPs and full packet inspection
In-Reply-To: <4FBE3611.2060006@gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
 <4FBE3611.2060006@gmail.com>
Message-ID: <4FBE3643.2020000@gmail.com>

And if your legal can't figure it out that is exactly what "outside 
counsel" is for.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 5/24/2012 8:22 AM, -Hammer- wrote:
> The problem is that it is strictly a jurisdictional question. I'm not 
> trying to throw it back at you. But I can't advise you w/o knowing the 
> specifics of your ISP which I don't want to know. Does that make 
> sense? What country? State? Where's your customer base? Do you have 
> multiple carriers? Do you service DOD? Outside of US? Do you service 
> EU? SWIFT (Financial wires?) etc? Mainly consumer? Commercial? The 
> list could go on.
>
> If you are being prodded by legal on this question then my advice 
> would be to tell them that they have to provide that direction.
>
> If you are being prodded by technology my advice would be to direct 
> them to legal.
>
> You should be picking up a pattern here....
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
> On 5/24/2012 8:13 AM, not common wrote:
>> Thanks guys, I am looking for stuff to bring to my legal team (which 
>> is one guy, that can't spell IP) and VPs.
>>
>> There has to be some thing out there or is this really a hands of topic?
>>
>> On Thu, May 24, 2012 at 8:58 AM, -Hammer- <bhmccie at gmail.com 
>> <mailto:bhmccie at gmail.com>> wrote:
>>
>>     You should be discussing this with inside counsel. Not NANOG.
>>
>>     -Hammer-
>>
>>     "I was a normal American nerd"
>>     -Jack Herer
>>
>>
>>
>>
>>     On 5/24/2012 7:50 AM, not common wrote:
>>
>>         Hello,
>>
>>         I am looking for some guidance on full packet inspection at
>>         the ISP level.
>>
>>         Is there any regulations that prohibit or provide guidance on
>>         this?
>>         .
>>
>>
>>

From valdis.kletnieks at vt.edu  Thu May 24 08:24:42 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Thu, 24 May 2012 09:24:42 -0400
Subject: ISPs and full packet inspection
In-Reply-To: Your message of "Thu, 24 May 2012 09:13:16 -0400."
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
Message-ID: <37503.1337865882@turing-police.cc.vt.edu>

On Thu, 24 May 2012 09:13:16 -0400, not common said:
> Thanks guys, I am looking for stuff to bring to my legal team (which is one
> guy, that can't spell IP) and VPs.

You probably want to fix that legal team.  If you're an ISP and your legal eagle
doesn't understand networking, you're opening yourself up to a world of hurt.

> There has to be some thing out there or is this really a hands of topic?

There's a whole mess of applicable laws. Patrick Darden just posed a good
intro as I was writing this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120524/7f5b48ac/attachment.bin>

From notcommonmistakes at gmail.com  Thu May 24 08:32:05 2012
From: notcommonmistakes at gmail.com (not common)
Date: Thu, 24 May 2012 09:32:05 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <37503.1337865882@turing-police.cc.vt.edu>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
 <37503.1337865882@turing-police.cc.vt.edu>
Message-ID: <CAKF9zbASVaSEQ95Z3uYvcUO538_wxys7zgjJ4sxYbYUvV8qASA@mail.gmail.com>

Thank you all, this will get me started and @Hammer, I see the trend your
talking about.

Cheers,

On Thu, May 24, 2012 at 9:24 AM, <valdis.kletnieks at vt.edu> wrote:

> On Thu, 24 May 2012 09:13:16 -0400, not common said:
> > Thanks guys, I am looking for stuff to bring to my legal team (which is
> one
> > guy, that can't spell IP) and VPs.
>
> You probably want to fix that legal team.  If you're an ISP and your legal
> eagle
> doesn't understand networking, you're opening yourself up to a world of
> hurt.
>
> > There has to be some thing out there or is this really a hands of topic?
>
> There's a whole mess of applicable laws. Patrick Darden just posed a good
> intro as I was writing this.
>

From bhmccie at gmail.com  Thu May 24 08:33:49 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 24 May 2012 08:33:49 -0500
Subject: ISPs and full packet inspection
In-Reply-To: <4FBE3548.2020500@armc.org>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3548.2020500@armc.org>
Message-ID: <4FBE38BD.5070901@gmail.com>

Very nice Patrick

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 5/24/2012 8:19 AM, Patrick Darden wrote:
> 0.  General Reference 
> http://en.wikipedia.org/wiki/Deep_packet_inspection#DPI_at_network.2FInternet_service_providers  
> e.g. Lawful Intercept
>
> 1.  network neutrality -- lots of possible laws coming up, 
> http://en.wikipedia.org/wiki/Network_neutrality#Law_in_the_United_States  
> http://www.sans.org/reading_room/whitepapers/policyissues/net-neutrality-rest-peace_33809 
>
>
> 2.  intellectual property -- all the sopa/pipa/etc. specifically 
> privacy invasion 
> http://en.wikipedia.org/wiki/Stop_Online_Piracy_Act#Deep-packet_inspection_and_privacy
>
> 3.  principle of implied responsibility -- if you change a data 
> stream, it is implied you are responsible for it (i.e. 
> administratively, editorially, etc.)
>
> 4.  Check out the CISSP legal domain.  Especially resources and 
> references for it.  Someone on your team should have this 
> certification.  
> http://www.amazon.com/CISSP-Boxed-Set-All---One/dp/0071768459/ref=sr_1_1?ie=UTF8&qid=1337865477&sr=8-1
>
> 5.  The EFF might be able to help you.  WRT Privacy espec.
>
> 6.  SANS has tons of references.  www.sans.org
>
> 7.  Get with a lawyer who is network-aware.  Good luck with that.  
> Maybe try to find a lawyer with a CISSP cert?
>
> --Patrick Darden
>
>
> On 05/24/2012 08:50 AM, not common wrote:
>> Hello,
>>
>> I am looking for some guidance on full packet inspection at the ISP 
>> level.
>>
>> Is there any regulations that prohibit or provide guidance on this?
>
> .
>


From copraphage at gmail.com  Thu May 24 09:23:44 2012
From: copraphage at gmail.com (Chris McDonald)
Date: Thu, 24 May 2012 10:23:44 -0400
Subject: alcatel var/integrator
Message-ID: <CAJsED6ETqwqJP1Aq-c03YnRSvkgmhAEDjfpZPy5Zu_damJKyeQ@mail.gmail.com>

does anyone have any experience with alcatel var's/integegrators
they'd be willing to share?

thanks
chris


From jared at puck.nether.net  Thu May 24 09:25:08 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 24 May 2012 10:25:08 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <4FBE3093.7090103@gmail.com>
 <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
Message-ID: <AB9D8F44-2AEC-4937-BB2B-2314E4396FC9@puck.nether.net>

Inside counsel should engage with outside counsel in this case.  Part of being a professional in many fields is knowing how to engage the right people (e.g.: doctors that refer you to an expert).

- jared

On May 24, 2012, at 9:13 AM, not common wrote:

> Thanks guys, I am looking for stuff to bring to my legal team (which is one
> guy, that can't spell IP) and VPs.
> 
> There has to be some thing out there or is this really a hands of topic?



From jeffshultz at wvi.com  Thu May 24 10:36:37 2012
From: jeffshultz at wvi.com (Jeff Shultz)
Date: Thu, 24 May 2012 08:36:37 -0700
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <20120523200909.GA86641@ussenterprise.ufp.org>
 <33756.1337820138@turing-police.cc.vt.edu>
 <CAK__Kzu_U42Zyz_+vhjzm_dM4ApCrrCqVuwp10WNtQ1Tiw-nrg@mail.gmail.com>
Message-ID: <4FBE5585.1030109@wvi.com>

On 5/23/2012 6:27 PM, George Herbert wrote:
> On Wed, May 23, 2012 at 5:42 PM,<valdis.kletnieks at vt.edu>  wrote:

>>
>> One could make the case that the releases before Paul got there weren't
>> exactly popular - how many DNS servers were in production in 1986? ;)
>
> Please don't make me remember hosts.txt before I've had a chance to
> wrap up work, go home, and get some Scotch in...
>
>

When I was in the US Army in Augsburg, GE, I was a dial-up "customer" of 
our local Army internet node. I'm not sure what the Micro was (Sperry? 
Unisys?) but it took up a good portion of a small room. hosts.txt was 
what it used - if I wanted to e-mail someone, I had to get the IP 
address of their e-mail server and have the sysadmin add it to the file.

I, through my aunt, had the hardest time getting the IP address of the 
Oregon State University e-mail server out of them because they couldn't 
believe that there was someone out there who wasn't running DNS yet. I 
just wanted to be able to send e-mail to my aunt, who was one of my few 
family members who had e-mail at the time.

This was 94-95. The system was due to be replaced at some point by a 486 
PC... that would do DNS. Base closed in 1998... I wonder if they ever 
got their new system?

Oy... I just remembered trying (and occasionally succeeding) to find 
Anonymous FTP sites via the nearly random typing of IP addresses on that 
system.

Okay, time to go hug my DNS server.

-- 
Jeff Shultz



From bruns at 2mbit.com  Thu May 24 10:51:50 2012
From: bruns at 2mbit.com (Brielle Bruns)
Date: Thu, 24 May 2012 09:51:50 -0600
Subject: Qwest/CenturyLink implementing transparent proxies?
In-Reply-To: <4FBDE03D.6010104@2mbit.com>
References: <4FBDE03D.6010104@2mbit.com>
Message-ID: <4FBE5916.8050009@2mbit.com>

On 5/24/12 1:16 AM, Brielle Bruns wrote:
> Hello All,
>
> A little off topic, but I was wondering if there's any Qwest/CenturyLink
> network engineers or techs lurking on this list that would contact me
> offlist?
>
> I won't bore people with the details, but I'm seeing what appears to be
> a transparent proxy on some sites when visited from multiple clients
> (all with Qwest DSL).  When browsing on our non-Qwest circuits (such as
> the T1s), we do not see the same behaviors.
>
> Its concerning to say the least, and something I'd like to get a clear
> and straight answer about.
>
> Thanks!


A quick update, some of the things that lead me to believe there's some 
sort of packet mucking going on over the past week or two, has magically 
cleared up on its own as of this morning.

I'm at a loss, so I'm going to throw my hands up and shrug.  Annoying to 
say the least, but not entirely unexpected.



-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org




From owen at delong.com  Thu May 24 11:52:34 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 24 May 2012 09:52:34 -0700
Subject: Qwest/CenturyLink implementing transparent proxies?
In-Reply-To: <4FBE5916.8050009@2mbit.com>
References: <4FBDE03D.6010104@2mbit.com> <4FBE5916.8050009@2mbit.com>
Message-ID: <0A4E59BB-9A75-4587-A70A-92B743241DD1@delong.com>


On May 24, 2012, at 8:51 AM, Brielle Bruns wrote:

> On 5/24/12 1:16 AM, Brielle Bruns wrote:
>> Hello All,
>> 
>> A little off topic, but I was wondering if there's any Qwest/CenturyLink
>> network engineers or techs lurking on this list that would contact me
>> offlist?
>> 
>> I won't bore people with the details, but I'm seeing what appears to be
>> a transparent proxy on some sites when visited from multiple clients
>> (all with Qwest DSL).  When browsing on our non-Qwest circuits (such as
>> the T1s), we do not see the same behaviors.
>> 
>> Its concerning to say the least, and something I'd like to get a clear
>> and straight answer about.
>> 
>> Thanks!
> 
> 
> A quick update, some of the things that lead me to believe there's some sort of packet mucking going on over the past week or two, has magically cleared up on its own as of this morning.
> 
> I'm at a loss, so I'm going to throw my hands up and shrug.  Annoying to say the least, but not entirely unexpected.
> 
> 
> 
> -- 
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org    /     http://www.ahbl.org
> 
> 


Perhaps they were testing facilities for an eventual CGN deployment.

The IPv4 world is only going to get worse in this regard as runout approaches and we begin to see more and more deployments of address sharing technologies at the carrier level (CGN, DS-Lite, etc.)

IPv6 -- 96 more bits, no magic, no header mutilation.

Owen



From jra at baylink.com  Thu May 24 12:20:01 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 24 May 2012 13:20:01 -0400 (EDT)
Subject: =?utf-8?Q?Re:_Vixie_warns:_DNS_Chan?=
 =?utf-8?Q?ger_=E2=80=98blackouts=E2=80=99_inevitable?=
In-Reply-To: <CAK__KztxNq35iFPVEYFC4F9ya1o1g3Cab2E9+6ZQHhMv5q01qA@mail.gmail.com>
Message-ID: <23612918.5878.1337880001418.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "George Herbert" <george.herbert at gmail.com>

> > Come on George, hosts.txt was the good old days :)
> 
> An elegant weapon, for a more civilized age?

Hokey files and ancient protocols are no match for a good resolver at 
your side, kid.

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 24 12:24:39 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 24 May 2012 13:24:39 -0400 (EDT)
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBoWQ8sqBZNThXaW0Vw6YjjMO80eg3E5O5=vHq35yv3xw@mail.gmail.com>
Message-ID: <16742022.5880.1337880279124.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "not common" <notcommonmistakes at gmail.com>

> Thanks guys, I am looking for stuff to bring to my legal team (which
> is one guy, that can't spell IP) and VPs.

My professional advice (IANAL) is that your inside counsel needs to find 
appropriate outside counsel well versed in this topic, and your VPs need to
pay them.

This is a Bet The Company topic.

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 christopher.morrow at gmail.com  Thu May 24 13:15:53 2012
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 24 May 2012 14:15:53 -0400
Subject: IETF SIDR Interim meeting post NANOG55
Message-ID: <CAL9jLaYOR+YhE1tmkOe+aWLypnweGwa4LcCaHUgEBLB3yEHPaQ@mail.gmail.com>

Howdy nanog attendee-potentials,
if there are folk interested in the SIDR (Secure InterDomain Routing)
work going on over in the IETF, there's an interim meeting scheduled
(like the one that was in San Diego during NANOG54) for 6/6/2012 in
Vancouver. If you'd like more information:
  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120606>

There will be both in-person and virtual (phone/webex) attendance
capabilities, we'd love to see some more operations folks chat about
especially:
  o rekeying processes/procedures/implications
  o performance measurement bounds

These two items are essentially:
  "How do I get that key thingy onto my router thingamabob?"
  including: "Oh, yes that device is in elbonia, we have always been
at info-war with elbonia, so.... maybe we should be more careful that
calling out the key in plain text over the phone to the local
colo-help-desk??"

and

  "How large/fast/agile does the whole of the system need to be? why
so small/large? How about the part related just to my
router-thing-a-ma-bob?"

attending-virtually,
-chris


From tdurack at gmail.com  Thu May 24 15:01:07 2012
From: tdurack at gmail.com (Tim Durack)
Date: Thu, 24 May 2012 16:01:07 -0400
Subject: Equinix Direct
Message-ID: <CAE_ug17-Pk46LQ6_fObExeE_M0f6qpNBtTQDH2+-v658N8KC4Q@mail.gmail.com>

Anyone got experience with "Equinix Direct"?

Looks like an interesting product from the glossy, but rather light on
details. I'm interested in the technical specs and real-life
experience.

(Not looking for sales. I've got a purchasing d00d for that.)

Thanks,

--
Tim:>


From betty at newnog.org  Thu May 24 15:52:08 2012
From: betty at newnog.org (Betty Burke <betty@nanog.org>)
Date: Thu, 24 May 2012 16:52:08 -0400
Subject: [NANOG-announce] NANOG 55 Update
Message-ID: <CABhExiwd_BaR0am8gOiUa3YeG6FCJ5LbZJk-4n3AhYf3PDu_MA@mail.gmail.com>

*NANOGers* do not miss out. NANOG 55 is Quickly Approaching!

For those who have not yet registered, please note:

   - *http://www.nanog.org/meetings/nanog55/nanog55_registration.html*
   - Late Registration starting May 28, 2012 (non-member $600, member $575,
   student $100)
   - On-Site Registration starting June 3, 2012 (non-member $675, member
   $650, student $100)

For those needing to make your hotel reservations, the Westin Bayshore,
Vancouver does have availability; Phone: (604) 682-3377 or visit
https://www.starwoodmeeting.com/StarGroupsWeb/booking/reservation?id=1110270761&key=424C7

The NANOG 55 *Agenda is complete and posted at
http://www.nanog.org/meetings/nanog55/socials.html*

*Lighting Talk Submissions Open (Abstracts Only), May 28, 2012*

And of course you will not want to miss on the ever popular *NANOG Socials
http://www.nanog.org/meetings/nanog55/socials.html*

Thank you to all our speakers, sponsors, NANOG committee members, and staff
who working to make NANOG 55 a reality!

Hope to see everyone in Vancouver!

Sincerely,
Betty

-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Office: +1 510 492 4030
Direct:  (810) 214-1218
nanog-support at nanog.org
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

From geemales at gmail.com  Thu May 24 15:58:22 2012
From: geemales at gmail.com (bt)
Date: Thu, 24 May 2012 13:58:22 -0700
Subject: Equinix Direct
In-Reply-To: <CAE_ug17-Pk46LQ6_fObExeE_M0f6qpNBtTQDH2+-v658N8KC4Q@mail.gmail.com>
References: <CAE_ug17-Pk46LQ6_fObExeE_M0f6qpNBtTQDH2+-v658N8KC4Q@mail.gmail.com>
Message-ID: <CABWy4mRT09E3oPDzvOkMQXexx_AGwPKyivfpD06E21kExHwpZQ@mail.gmail.com>

Bought and used ED at SV1 since mid-2004 I think.  I was running a consumer
website at the time.  I'm no longer with the company but when I checked
last year, they were still using it as a *backup* internet provider and
it's worked out well for them.  The biggest problem back then, and
currently, is the lack of larger ISPs.  At SV1 they had Global Crossing,
but the rest were basically mid-sized regional or national network
providers like Hurricane Electric.

The process for using it:
1) Purchase the service
2) Get the connect to ED, hook up to your equipment
3) You will establish a BGP neighbor relationship with the ED route servers
only, regardless of how many actual network providers you configure,
4) Use a web interface to pick the providers you want,
 - it'll be arranged as a matrix where you can choose commit rates (they
start at "0" for a lot of providers) and the resulting price, as well as
terms (which also start at "none").
 - also depending on provider, some will do DIA (direct internet access) or
just on-net (just their, and their direct customer's networks), or both.
 Make sure you know what service you're purchasing and that it matches your
design.
5) Modify or apply any routing policies you want specific for the providers
you've chosen,
6) Start pushing packets.

Though you peer with Equinix Direct and not the provider's router, of
course ED strips their ASN and you don't see it in the path attribute.  You
may or may not be able to set attributes like community or MED with the
providers; I don't know because we never used them in that capacity.   It
was strictly a backup circuit for us and so we set local-pref and path
prepending and left it at that.

We occasionally had problems with our primary service providers and the ED
service would work great.  External monitoring (a la Gomez or Keynote)
wouldn't catch a thing and no customer (internal or external) complaints
ever bubbled up to me.  During contract negotiations with our primary
provider, we ran on Global Crossing through ED for 1-2 months with no
problems.

For on-demand bandwidth with no commit and no contracts required, and if
you're already in an Equinix data center, I think it's a very nice service.

bt

On Thu, May 24, 2012 at 1:01 PM, Tim Durack <tdurack at gmail.com> wrote:

> Anyone got experience with "Equinix Direct"?
>
> Looks like an interesting product from the glossy, but rather light on
> details. I'm interested in the technical specs and real-life
> experience.
>
> (Not looking for sales. I've got a purchasing d00d for that.)
>
> Thanks,
>
> --
> Tim:>
>
>

From lsc at prgmr.com  Thu May 24 16:25:58 2012
From: lsc at prgmr.com (Luke S. Crawford)
Date: Thu, 24 May 2012 17:25:58 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <20120524212558.GA10426@luke.xen.prgmr.com>

On Thu, May 24, 2012 at 08:50:47AM -0400, not common wrote:
> Hello,
> 
> I am looking for some guidance on full packet inspection at the ISP level.
> 
> Is there any regulations that prohibit or provide guidance on this?

Unless you are absolutely huge, and maybe even then, you need to worry
more about how your customers will perceive this than how law enforcement
will perceive this.   (I mean, you want to follow the law, sure, but
even if it's legal, if it cheeses the customers?  well, you have a 
problem.) More to the point, like most on this list, law
isn't my field. 

In my experience?  customers get really, really uncomfortable with you
doing, well, almost anything below the headers.  I was talking about doing
a inward facing snort IDS (to detect compromised hosts before I got complaints)
and got so far as a prototype where I shared the info I recorded about each
IP with the customer in question, but talking to customers?  this idea 
was extremely offensive, so the project was quashed.  

Now, generally speaking, customers are much more okay with you going through
the IP headers.  For instance, instead of using an IDS, I could, say, count
the number of outgoing connections destined for port 22 or 25, or the same
but count how many unique destinations they use (e.g. to avoid MX host 
or ssh tunneling false positives... both of those use cases would have
a lot of connections on those ports, but to a small number of remote hosts.)

>From what I've heard customers say, this would likely cause less offense 
than using snort or the like to do full packet inspection.  (it wouldn't
be completely inoffensive, but I think that if I wiped the logs often
and shared my data with the customer, it sounds like something that
customers would tolerate.)  I haven't prototyped that system yet, 
though, so eh, who knows.  




From keegan.holley at sungard.com  Thu May 24 18:05:10 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 24 May 2012 19:05:10 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <CABO8Q6T2Wif10GrGeZ3aF8R1oKVEqx+=wGxD78JG3Fc0pk66tg@mail.gmail.com>

I've seen this come up on at least three different cop shows so I wouldn't
recommend it.  It's also not cool.  Packets wanna be free man.. ;)

Just my 2c


2012/5/24 not common <notcommonmistakes at gmail.com>

> Hello,
>
> I am looking for some guidance on full packet inspection at the ISP level.
>
> Is there any regulations that prohibit or provide guidance on this?
>
>

From keegan.holley at sungard.com  Thu May 24 18:12:08 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 24 May 2012 19:12:08 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <CABO8Q6RJGjULD5w13KdmgN_TGLKnYUhZ=fMC_rwM_p76beGCmQ@mail.gmail.com>

On a lighter note, did you know that your company can hold some of us
liable depending on what advice we give you and how far you run with it.
 Just a thought...  Overall, I wouldn't choose nanog over
google/wikipedia/GROKLAW unless it is something really specific
operationally.  This isn't really one of those topics.  Any lawyer worth
his luxury sedan should be able to do his own research.  Most of the laws
were written by lawyers and judges that don't understand IP (Internet
Protocol or Intellectual Property) either so your legal team is in good
company.


2012/5/24 not common <notcommonmistakes at gmail.com>

> Hello,
>
> I am looking for some guidance on full packet inspection at the ISP level.
>
> Is there any regulations that prohibit or provide guidance on this?
>
>

From mysidia at gmail.com  Thu May 24 20:37:52 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 24 May 2012 20:37:52 -0500
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <CAAAwwbVF-pSaZ4hkDrqfW97y4wo8CLuptZxdj3kTB=pCzS40ZA@mail.gmail.com>

On 5/24/12, not common <notcommonmistakes at gmail.com> wrote:
[snip
> I am looking for some guidance on full packet inspection at the ISP level.
Aside from any legal issue;  there is a  "respectable practices"
issue. Even if there is no regulation that prohibits something does
not mean it is OK.  Your customers' deserve to be made aware of any
full packet capture practices that may impact traffic to/from network
they own/manage,  before packet capture occurs,  especially when there
is data retention, or human examination/analysis based on contents of
large numbers of packets;  otherwise there is a risk you will be in
trouble, for some definition of "in trouble" that depends on the
circumstances.

Because your packet interception can put your user at risk;
proprietary information can be disclosed.    And most ISP customers
intend to purchase network connectivity service,  not   "record all my
traffic without telling me"  service ..



Are you prepared to explicitly explain to your customers,  both
existing, and new ones,
before they are allowed to buy or continue service from you --   under
what circumstances
you intercept full packets, whose packets do you capture,  what
packets do you capture, how many packets / how long will you capture
their packets,   what do you do with their contents after you capture
them,  how long do you keep  data,  what security controls do you have
in place  to prevent unauthorized   access to their packets  and
ensure timely destruction of sensitive data?


If the answer is NO,   that you   have poor planning,  or your privacy
practices are not solid enough to reveal to your customers  with
confidence,  then  save the money on consulting lawyers,  by choosing
NOT   to   implement   interception and capture of  full packets.


> Is there any regulations that prohibit or provide guidance on this?
-- 
-JH


From jhellenthal at dataix.net  Thu May 24 21:03:33 2012
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Thu, 24 May 2012 22:03:33 -0400
Subject: ISPs and full packet inspection
In-Reply-To: <CAAAwwbVF-pSaZ4hkDrqfW97y4wo8CLuptZxdj3kTB=pCzS40ZA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <CAAAwwbVF-pSaZ4hkDrqfW97y4wo8CLuptZxdj3kTB=pCzS40ZA@mail.gmail.com>
Message-ID: <20120525020333.GA16534@DataIX.net>



On Thu, May 24, 2012 at 08:37:52PM -0500, Jimmy Hess wrote:
> On 5/24/12, not common <notcommonmistakes at gmail.com> wrote:
> [snip
> > I am looking for some guidance on full packet inspection at the ISP level.
> Aside from any legal issue;  there is a  "respectable practices"
> issue. Even if there is no regulation that prohibits something does
> not mean it is OK.  Your customers' deserve to be made aware of any
> full packet capture practices that may impact traffic to/from network
> they own/manage,  before packet capture occurs,  especially when there
> is data retention, or human examination/analysis based on contents of
> large numbers of packets;  otherwise there is a risk you will be in
> trouble, for some definition of "in trouble" that depends on the
> circumstances.
> 
> Because your packet interception can put your user at risk;
> proprietary information can be disclosed.    And most ISP customers
> intend to purchase network connectivity service,  not   "record all my
> traffic without telling me"  service ..

If you need a call center to handle this just let me know... :) since
your call volume is going to spike through the roof.

> 
> 
> 
> Are you prepared to explicitly explain to your customers,  both
> existing, and new ones,
> before they are allowed to buy or continue service from you --   under
> what circumstances
> you intercept full packets, whose packets do you capture,  what
> packets do you capture, how many packets / how long will you capture
> their packets,   what do you do with their contents after you capture
> them,  how long do you keep  data,  what security controls do you have
> in place  to prevent unauthorized   access to their packets  and
> ensure timely destruction of sensitive data?
> 
> 
> If the answer is NO,   that you   have poor planning,  or your privacy
> practices are not solid enough to reveal to your customers  with
> confidence,  then  save the money on consulting lawyers,  by choosing
> NOT   to   implement   interception and capture of  full packets.
> 
> 
> > Is there any regulations that prohibit or provide guidance on this?
> -- 
> -JH

-- 

 - (2^(N-1))


From streiner at cluebyfour.org  Thu May 24 21:21:44 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 24 May 2012 22:21:44 -0400 (EDT)
Subject: ISPs and full packet inspection
In-Reply-To: <CAAAwwbVF-pSaZ4hkDrqfW97y4wo8CLuptZxdj3kTB=pCzS40ZA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
 <CAAAwwbVF-pSaZ4hkDrqfW97y4wo8CLuptZxdj3kTB=pCzS40ZA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1205242206090.26549@whammy.cluebyfour.org>

On Thu, 24 May 2012, Jimmy Hess wrote:

> On 5/24/12, not common <notcommonmistakes at gmail.com> wrote:
> [snip
>> I am looking for some guidance on full packet inspection at the ISP level.

Aside from all of the business and legal sticking points that others have 
mentioned, there are also the technical aspects of capturing, storing, 
transporting, analyzing, and managing those packets, and the appliances 
that do the heavy lifting.  As your traffic grows, that problem scales 
1:1 linearly, at best, and more likely n:1 linearly, or worse.  The added 
overhead of the infrastructure needed to support this will also make it 
more difficult to be price-competitive with your peers.

Your sales/marketing/executive staff would have their work cut out for 
them in trying to explain to existing and prospective customers not only 
where the value-add is for them, but why that would be worth the 
significant recurring costs you'd have to charge to cover your overhead 
and/or maintain your profit margin.

jms


From jra at baylink.com  Thu May 24 21:36:27 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 24 May 2012 22:36:27 -0400 (EDT)
Subject: ISPs and full packet inspection
In-Reply-To: <Pine.LNX.4.64.1205242206090.26549@whammy.cluebyfour.org>
Message-ID: <27716220.5934.1337913387147.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Justin M. Streiner" <streiner at cluebyfour.org>

> Aside from all of the business and legal sticking points that others have
> mentioned, there are also the technical aspects of capturing, storing,
> transporting, analyzing, and managing those packets, and the appliances
> that do the heavy lifting. As your traffic grows, that problem scales
> 1:1 linearly, at best, and more likely n:1 linearly, or worse. The
> added overhead of the infrastructure needed to support this will also make
> it more difficult to be price-competitive with your peers.

TL:DR; The reasons for doing this on any kind of general basis have to
be *EXCEPTIONALLY* compelling to make a business case for it, apart from 
any possible legal ramifications.

I used asterisks *and* capital letters; that's about an order of magnitude.

Don't forget staffing.

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 mohta at necom830.hpcl.titech.ac.jp  Fri May 25 01:25:35 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 25 May 2012 15:25:35 +0900
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
Message-ID: <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>

Randy Carpenter wrote:

> It certainly does not work on the iPad "3" in Ohio. Not only
> that, but I can't even pay them to give me a stable IPv4
> address, because if you get a static IP, it disables the
> hotspot functionality. Head-->Wall.

The proper way to have a static IP address is not to pay mobile
operators but to run mobile IP or something like that on your
terminal.

You can run your home agent at your home or office.

						Masataka Ohta


From tdurack at gmail.com  Fri May 25 07:19:10 2012
From: tdurack at gmail.com (Tim Durack)
Date: Fri, 25 May 2012 08:19:10 -0400
Subject: Equinix Direct
In-Reply-To: <CAE_ug17-Pk46LQ6_fObExeE_M0f6qpNBtTQDH2+-v658N8KC4Q@mail.gmail.com>
References: <CAE_ug17-Pk46LQ6_fObExeE_M0f6qpNBtTQDH2+-v658N8KC4Q@mail.gmail.com>
Message-ID: <CAE_ug16CDWff=2zbrb7XLozRzCRS7Vi3OP9TmySRAJmsDANQ0Q@mail.gmail.com>

Thanks for the response to my question.

What I have received confirms this is basically a metered IXP with
route servers and a mix of paid transit/peering options. Will be
interesting to see what the participant mix is.

It does concern me that the only connectivity options are FE/GE, no
10GE at this time. Makes me wonder about how serious the service is,
and whether I will end up with a more congested service than simply
getting a mix of transit providers myself.

Anyway, thanks again to all who responded.

-- 
Tim:>


From randy at psg.com  Tue May 22 20:55:53 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 23 May 2012 10:55:53 +0900
Subject: APNIC 34 Conference - Call for Papers
Message-ID: <m21umbd5jq.wl%randy@psg.com>

________________________________________________________________________

APNIC 34 Conference - Call for Papers
________________________________________________________________________


The APNIC 34 Programme Committee is now seeking tutorials and
presentations for the APNIC 34 Conference to be held in Phnom Penh,
Cambodia from 27 - 31 August 2012.  We are looking for content which
would suit the technical conference sessions and the tutorials.

Key Dates
---------

The timeline for submissions is:

Call for Papers Opens		Now
First Round Paper Acceptance	2 July 2012
Final Deadline for Submissions 	13 August 2012
Final Round Paper Acceptance 	20 August 2012
Final Slides Received		25 August 2012

Submitting Proposals
--------------------

	http://submission.apnic.net

Programme Material
------------------

The technical sessions at APNIC 34 will include presentations relevant
to Internet operations and technologies. The following topics are
examples of possible areas of interest.

       - IPv4 exhaustion / IPv6 deployment and operations
       - NAT64/444, 6rd, DSLite, A+P
       - ISP and Carrier Services
       - IXPs and Peering
       - Network security
       - Access and Transport Technologies
       - Content and Service Delivery

If you have any another ideas or proposals for panel or Birds of
Feather sessions, please feel free to submit your ideas via the
submission system.

If you have any questions, please email the Programme Committee at:

     apnic-pc at apnic.net

For more information about APNIC 34, please visit:

     http://conference.apnic.net/34


On behalf of:

APNIC 34 Programme Committee
Co-chairs: Philip Smith & Mark Tinka


From don at sandvine.com  Fri May 25 08:13:25 2012
From: don at sandvine.com (Don Bowman)
Date: Fri, 25 May 2012 13:13:25 +0000
Subject: ISPs and full packet inspection
In-Reply-To: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
References: <CAKF9zbBnvkw4bEq3f1YP0bXM9bS0in+Axj=0zrmnN3YZKcdKmA@mail.gmail.com>
Message-ID: <C7579F0BB38EC444912308442F7E195A11548553@wtl-exch-1.sandvine.com>

From: not common [mailto:notcommonmistakes at gmail.com] 

>Hello,
>
>I am looking for some guidance on full packet inspection at the ISP level.
>
>Is there any regulations that prohibit or provide guidance on this?

Your better to discuss use cases than technology.
E.g. do you plan to do per-user behavioural targeted advertising?
To secure the network from DNS changer malware?
To block slammer worm?
To deploy a session border controller?
To deploy a carrier-grade NAT (LSN)?
To collect bank information and profit?
To enhance the QoS of VoIP?
To deploy a transparent web or video cache?

All of them use packet inspection. All can be achieved w/o packet inspection. 
All of them vary wildly in how people would react :)

So... phrase your question and 'guidance' around the use case, not the
method you plan to achieve it today.




From morrowc.lists at gmail.com  Fri May 25 09:32:11 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 25 May 2012 10:32:11 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
Message-ID: <CAL9jLaaOzte1F+aOTu=qK1uLLnrf--Er90oz9ey6ys7+5eydHg@mail.gmail.com>

On Fri, May 25, 2012 at 2:25 AM, Masataka Ohta
<mohta at necom830.hpcl.titech.ac.jp> wrote:
> Randy Carpenter wrote:
>
>> It certainly does not work on the iPad "3" in Ohio. Not only
>> that, but I can't even pay them to give me a stable IPv4
>> address, because if you get a static IP, it disables the
>> hotspot functionality. Head-->Wall.
>
> The proper way to have a static IP address is not to pay mobile
> operators but to run mobile IP or something like that on your
> terminal.
>
> You can run your home agent at your home or office.

that seems super scalable and easy for 'people' to do ...


From valdis.kletnieks at vt.edu  Fri May 25 09:35:49 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Fri, 25 May 2012 10:35:49 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: Your message of "Fri, 25 May 2012 15:25:35 +0900."
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
Message-ID: <36677.1337956549@turing-police.cc.vt.edu>

On Fri, 25 May 2012 15:25:35 +0900, Masataka Ohta said:

> The proper way to have a static IP address is not to pay mobile
> operators but to run mobile IP or something like that on your
> terminal.
>
> You can run your home agent at your home or office.

And the 80% of the world's population that can afford exactly one
device which happens to be mobile, does, what, exactly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120525/dd8175ef/attachment.bin>

From jarek at dolsatbelchatow.pl  Fri May 25 09:47:51 2012
From: jarek at dolsatbelchatow.pl (Jarek Kasjaniuk)
Date: Fri, 25 May 2012 16:47:51 +0200
Subject: Database with telephone numbers
Message-ID: <4FBF9B97.6070806@dolsatbelchatow.pl>

Hello NANOG,

I am looking for information about database which provides the names of companies
and allocated telephone numbers in US.

I know that FCC has a website  http://apps.fcc.gov/cgb/form499/499a.cfm,
but there are only companies names.

In Poland we have similar database on our "FCC" website - UKE ( Office of Electronic Communications ),
but we can find to whom belongs allocated telephone numbers.
For example:  area code 12 + number starts at 200 -> 12200
and we have -> area code '12' | allocated pool 'SPQM=200(1,3,6,8,0)' | area 'Krakow' | owner 'TP S.A'

Where can I find that kind of information?

Thanks in advance for help.

--
Jarek Kasjaniuk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120525/e5b56fca/attachment.bin>

From kwallace at pcconnection.com  Fri May 25 10:00:30 2012
From: kwallace at pcconnection.com (Wallace Keith)
Date: Fri, 25 May 2012 11:00:30 -0400
Subject: Database with telephone numbers
In-Reply-To: <4FBF9B97.6070806@dolsatbelchatow.pl>
References: <4FBF9B97.6070806@dolsatbelchatow.pl>
Message-ID: <B92E4A692F0F6B419EE79045D420F72A2F44A3939B@MKA176.pcc.int>

Check  nanpa.com

http://nanpa.com/nas/public/assigned_code_query_step1.do?method=resetCodeQueryModel

although number portability may confuse things slightly- 

Keith

-----Original Message-----
From: Jarek Kasjaniuk [mailto:jarek at dolsatbelchatow.pl] 
Sent: Friday, May 25, 2012 10:48 AM
To: nanog at nanog.org
Subject: Database with telephone numbers

Hello NANOG,

I am looking for information about database which provides the names of companies and allocated telephone numbers in US.

I know that FCC has a website  http://apps.fcc.gov/cgb/form499/499a.cfm,
but there are only companies names.

In Poland we have similar database on our "FCC" website - UKE ( Office of Electronic Communications ), but we can find to whom belongs allocated telephone numbers.
For example:  area code 12 + number starts at 200 -> 12200 and we have -> area code '12' | allocated pool 'SPQM=200(1,3,6,8,0)' | area 'Krakow' | owner 'TP S.A'

Where can I find that kind of information?

Thanks in advance for help.

--
Jarek Kasjaniuk


From telephonetoughguy83 at gmail.com  Fri May 25 10:02:53 2012
From: telephonetoughguy83 at gmail.com (Andy Smith)
Date: Fri, 25 May 2012 10:02:53 -0500
Subject: Database with telephone numbers
In-Reply-To: <4FBF9B97.6070806@dolsatbelchatow.pl>
References: <4FBF9B97.6070806@dolsatbelchatow.pl>
Message-ID: <CAFWmz6koVp0FoTMByfF1SFATC1hT5df7j7PV5LG6UZfGj8yc-A@mail.gmail.com>

www.nanpa.com (North American Number Plan Association).  This is the
"official" site for area code/exchange information in North America.
www.localcallingguide.com also has information, but I'm not sure how
"official" it is.  Both sites have multiple ways of searching, i.e. per
area code, by lata, by company, etc.

On Fri, May 25, 2012 at 9:47 AM, Jarek Kasjaniuk
<jarek at dolsatbelchatow.pl>wrote:

> Hello NANOG,
>
> I am looking for information about database which provides the names of
> companies
> and allocated telephone numbers in US.
>
> I know that FCC has a website  http://apps.fcc.gov/cgb/form499/499a.cfm,
> but there are only companies names.
>
> In Poland we have similar database on our "FCC" website - UKE ( Office of
> Electronic Communications ),
> but we can find to whom belongs allocated telephone numbers.
> For example:  area code 12 + number starts at 200 -> 12200
> and we have -> area code '12' | allocated pool 'SPQM=200(1,3,6,8,0)' |
> area 'Krakow' | owner 'TP S.A'
>
> Where can I find that kind of information?
>
> Thanks in advance for help.
>
> --
> Jarek Kasjaniuk
>
>

From jarek at dolsatbelchatow.pl  Fri May 25 10:54:16 2012
From: jarek at dolsatbelchatow.pl (Jarek Kasjaniuk)
Date: Fri, 25 May 2012 17:54:16 +0200
Subject: Database with telephone numbers
In-Reply-To: <CAFWmz6koVp0FoTMByfF1SFATC1hT5df7j7PV5LG6UZfGj8yc-A@mail.gmail.com>
References: <4FBF9B97.6070806@dolsatbelchatow.pl>
 <CAFWmz6koVp0FoTMByfF1SFATC1hT5df7j7PV5LG6UZfGj8yc-A@mail.gmail.com>
Message-ID: <4FBFAB28.3020106@dolsatbelchatow.pl>

W dniu 25.05.2012 17:02, Andy Smith pisze:
> www.nanpa.com (North American Number Plan Association).  This is the
> "official" site for area code/exchange information in North America.
> www.localcallingguide.com also has information, but I'm not sure how
> "official" it is.  Both sites have multiple ways of searching, i.e. per
> area code, by lata, by company, etc.

Thank you to all of you for help and fast response to my inquiry.

--
Jarek Kasjaniuk

PS. I know the site is in Polish...
but may be this link will be useful to someone.

http://www.uke.gov.pl/tablice/home.do?execution=e5s1

1. Stacjonarne publiczne sieci telefoniczne ->  Fixed public telephone network
2. Ruchome (kom?rkowe) publiczne sieci telefoniczne -> Mobile (cellular) public telephone networks



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120525/f20d4612/attachment.bin>

From jra at baylink.com  Fri May 25 10:57:06 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 25 May 2012 11:57:06 -0400 (EDT)
Subject: FBI Presses for Amendment to CALEA to cover social networks
Message-ID: <19895142.6016.1337961426141.JavaMail.root@benjamin.baylink.com>

http://www.washingtonpost.com/business/technology/fbi-forming-communications-assistance-center-to-help-spy-on-americans/2012/05/24/gJQAFuuSnU_story.html

-- 
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 me at anuragbhatia.com  Fri May 25 11:01:11 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Fri, 25 May 2012 21:31:11 +0530
Subject: Industry practice for BGP costs - one time or fixed/monthly?
Message-ID: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>

Hello everyone


I have been aggressively looking for deals in servers in Europe for
anycasting. One thing which surprises me is the "setup costs" for BGP. Few
providers quoted additional $50-100 which looks OK but a few of them quoted
as high as $150 *extra every month* just for having BGP (no full routing
table, but just default route pointing). Is there's any technical logic
behind such heavy costs? I mean at the end of day we are all talking at
layer 3 and thus it does not involves any hard connection/physical work.
What other members pay for BGP setup costs?



Thanks!

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From deleskie at gmail.com  Fri May 25 11:04:08 2012
From: deleskie at gmail.com (jim deleskie)
Date: Fri, 25 May 2012 13:04:08 -0300
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
Message-ID: <CAJL_ZMMZQMBDSPe3+fazMiEOaUGiqLdE3HPAsThm3tzzkDVyVw@mail.gmail.com>

IMHO the only reason(s) would be to discourage people from asking for
it, or as a $$ grab.

-jim

On Fri, May 25, 2012 at 1:01 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Hello everyone
>
>
> I have been aggressively looking for deals in servers in Europe for
> anycasting. One thing which surprises me is the "setup costs" for BGP. Few
> providers quoted additional $50-100 which looks OK but a few of them quoted
> as high as $150 *extra every month* just for having BGP (no full routing
> table, but just default route pointing). Is there's any technical logic
> behind such heavy costs? I mean at the end of day we are all talking at
> layer 3 and thus it does not involves any hard connection/physical work.
> What other members pay for BGP setup costs?
>
>
>
> Thanks!
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>


From Ashish.Rastogi at csscorp.com  Fri May 25 11:04:08 2012
From: Ashish.Rastogi at csscorp.com (Ashish Rastogi)
Date: Fri, 25 May 2012 16:04:08 +0000
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
Message-ID: <E9E97C039E9B0A4689B3B1B0A81809F2012FA3@USBOSSA-MBX02.ad.csscorp.com>

Price is probably for high availability and high SLA standards.

Ashish Rastogi

________________________________________
From: Anurag Bhatia [me at anuragbhatia.com]
Sent: Friday, May 25, 2012 12:01 PM
To: NANOG Mailing List
Subject: Industry practice for BGP costs - one time or fixed/monthly?

Hello everyone


I have been aggressively looking for deals in servers in Europe for
anycasting. One thing which surprises me is the "setup costs" for BGP. Few
providers quoted additional $50-100 which looks OK but a few of them quoted
as high as $150 *extra every month* just for having BGP (no full routing
table, but just default route pointing). Is there's any technical logic
behind such heavy costs? I mean at the end of day we are all talking at
layer 3 and thus it does not involves any hard connection/physical work.
What other members pay for BGP setup costs?



Thanks!

--

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>
http://www.csscorp.com/common/email-disclaimer.php


From jared at puck.nether.net  Fri May 25 11:13:33 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 25 May 2012 12:13:33 -0400
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
Message-ID: <16E58470-6A1D-4913-B5C7-C7AECE092B32@puck.nether.net>

There are starting to be a major difference in cost for supporting bgp. Taking a look at routing table size, many people are going to see troubles around 512k routes. Placing you on a device that doesn't need a full table or one at all will result in lower capital costs and lower operational costs as fewer features need to be toyed with.

Static routes work on nearly every device :-)

- Jared 

On May 25, 2012, at 12:01 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Hello everyone
> 
> 
> I have been aggressively looking for deals in servers in Europe for
> anycasting. One thing which surprises me is the "setup costs" for BGP. Few
> providers quoted additional $50-100 which looks OK but a few of them quoted
> as high as $150 *extra every month* just for having BGP (no full routing
> table, but just default route pointing). Is there's any technical logic
> behind such heavy costs? I mean at the end of day we are all talking at
> layer 3 and thus it does not involves any hard connection/physical work.
> What other members pay for BGP setup costs?
> 
> 
> 
> Thanks!
> 
> -- 
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>


From m.hallgren at free.fr  Fri May 25 11:14:52 2012
From: m.hallgren at free.fr (Michael Hallgren)
Date: Fri, 25 May 2012 18:14:52 +0200
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <E9E97C039E9B0A4689B3B1B0A81809F2012FA3@USBOSSA-MBX02.ad.csscorp.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <E9E97C039E9B0A4689B3B1B0A81809F2012FA3@USBOSSA-MBX02.ad.csscorp.com>
Message-ID: <1337962492.2903.40.camel@home>

Le vendredi 25 mai 2012 ? 16:04 +0000, Ashish Rastogi a ?crit :
> Price is probably for high availability and high SLA standards.

Yes, hopefully not for simple BGP route exchange...! :)

mh

> 
> Ashish Rastogi
> 
> ________________________________________
> From: Anurag Bhatia [me at anuragbhatia.com]
> Sent: Friday, May 25, 2012 12:01 PM
> To: NANOG Mailing List
> Subject: Industry practice for BGP costs - one time or fixed/monthly?
> 
> Hello everyone
> 
> 
> I have been aggressively looking for deals in servers in Europe for
> anycasting. One thing which surprises me is the "setup costs" for BGP. Few
> providers quoted additional $50-100 which looks OK but a few of them quoted
> as high as $150 *extra every month* just for having BGP (no full routing
> table, but just default route pointing). Is there's any technical logic
> behind such heavy costs? I mean at the end of day we are all talking at
> layer 3 and thus it does not involves any hard connection/physical work.
> What other members pay for BGP setup costs?
> 
> 
> 
> Thanks!
> 
> --
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>
> http://www.csscorp.com/common/email-disclaimer.php
> 




From edward.dore at freethought-internet.co.uk  Fri May 25 11:18:13 2012
From: edward.dore at freethought-internet.co.uk (Edward J. Dore)
Date: Fri, 25 May 2012 17:18:13 +0100 (BST)
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
Message-ID: <784967753.85738.1337962693226.JavaMail.root@freethought-internet.co.uk>

The only thing that I can really think of is that the BGP sessions do take up extra CPU time and memory on the routing engine, so there is an additional cost to the provider in terms of needing more routers and/or bigger routers if they have lots of customers speaking BGP to them that they may not have factored in to their standard pricing.

I guess there is also some extra cost in terms of NOC staff and systems to monitor the sessions as well as providing any troubleshooting etc. that they wouldn't have to do with "standard" customers that are statically routed.

Edward Dore 
Freethought Internet 

----- Original Message -----
From: "Anurag Bhatia" <me at anuragbhatia.com>
To: "NANOG Mailing List" <nanog at nanog.org>
Sent: Friday, 25 May, 2012 5:01:11 PM
Subject: Industry practice for BGP costs - one time or fixed/monthly?

Hello everyone


I have been aggressively looking for deals in servers in Europe for
anycasting. One thing which surprises me is the "setup costs" for BGP. Few
providers quoted additional $50-100 which looks OK but a few of them quoted
as high as $150 *extra every month* just for having BGP (no full routing
table, but just default route pointing). Is there's any technical logic
behind such heavy costs? I mean at the end of day we are all talking at
layer 3 and thus it does not involves any hard connection/physical work.
What other members pay for BGP setup costs?



Thanks!

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>


From jvanoppen at spectrumnet.us  Fri May 25 11:21:42 2012
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Fri, 25 May 2012 16:21:42 +0000
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <1337962492.2903.40.camel@home>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <E9E97C039E9B0A4689B3B1B0A81809F2012FA3@USBOSSA-MBX02.ad.csscorp.com>
 <1337962492.2903.40.camel@home>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE76327E123C4@mail1-sea.office.spectrumnet.us>

I know we dislike BGP on small connections (even though we do it), it is an extra administrative hassle that tends to be the most work on the smallest connections.    Customers with multiple 10Gs tend to have small numbers of BGP related tickets than customers with a single fastE, given that, I can understand why soneone would want to charge, especially when it breaks the cookie-cutter templates that they are using for their low margin servers.    While something might be technically easy, don't forget that breaking automated proccesses does tend to cause administrative pain, that could be what the fees are for recouping. 



John

From sethm at rollernet.us  Fri May 25 11:38:29 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 25 May 2012 09:38:29 -0700
Subject: Database with telephone numbers
In-Reply-To: <4FBFAB28.3020106@dolsatbelchatow.pl>
References: <4FBF9B97.6070806@dolsatbelchatow.pl>
 <CAFWmz6koVp0FoTMByfF1SFATC1hT5df7j7PV5LG6UZfGj8yc-A@mail.gmail.com>
 <4FBFAB28.3020106@dolsatbelchatow.pl>
Message-ID: <4FBFB585.5000701@rollernet.us>

On 5/25/12 8:54 AM, Jarek Kasjaniuk wrote:
> W dniu 25.05.2012 17:02, Andy Smith pisze:
>> www.nanpa.com (North American Number Plan Association).  This is
>> the "official" site for area code/exchange information in North
>> America. www.localcallingguide.com also has information, but I'm
>> not sure how "official" it is.  Both sites have multiple ways of
>> searching, i.e. per area code, by lata, by company, etc.
> 
> Thank you to all of you for help and fast response to my inquiry.
> 

I've found www.telcodata.us useful as well.

~Seth


From joelja at bogus.com  Fri May 25 12:50:52 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 25 May 2012 10:50:52 -0700
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <36677.1337956549@turing-police.cc.vt.edu>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <36677.1337956549@turing-police.cc.vt.edu>
Message-ID: <4FBFC67C.5010101@bogus.com>

On 5/25/12 07:35 , valdis.kletnieks at vt.edu wrote:
> On Fri, 25 May 2012 15:25:35 +0900, Masataka Ohta said:
> 
>> The proper way to have a static IP address is not to pay mobile
>> operators but to run mobile IP or something like that on your
>> terminal.
>>
>> You can run your home agent at your home or office.
> 
> And the 80% of the world's population that can afford exactly one
> device which happens to be mobile, does, what, exactly?

the utlitiy of a static ip is probably lost on someone with only a
mobile phone...




From morrowc.lists at gmail.com  Fri May 25 13:00:18 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 25 May 2012 14:00:18 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <4FBFC67C.5010101@bogus.com>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <36677.1337956549@turing-police.cc.vt.edu>
 <4FBFC67C.5010101@bogus.com>
Message-ID: <CAL9jLaY-8DuWruzgtroRi5YxgWVHeAuvGZV-k6ff6e_FkiUNgQ@mail.gmail.com>

On Fri, May 25, 2012 at 1:50 PM, Joel jaeggli <joelja at bogus.com> wrote:
> On 5/25/12 07:35 , valdis.kletnieks at vt.edu wrote:

>> And the 80% of the world's population that can afford exactly one
>> device which happens to be mobile, does, what, exactly?
>
> the utlitiy of a static ip is probably lost on someone with only a
> mobile phone...

END-2-END!!!


From arturo.servin at gmail.com  Fri May 25 13:35:36 2012
From: arturo.servin at gmail.com (Arturo Servin)
Date: Fri, 25 May 2012 15:35:36 -0300
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAL9jLaY-8DuWruzgtroRi5YxgWVHeAuvGZV-k6ff6e_FkiUNgQ@mail.gmail.com>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <36677.1337956549@turing-police.cc.vt.edu> <4FBFC67C.5010101@bogus.com>
 <CAL9jLaY-8DuWruzgtroRi5YxgWVHeAuvGZV-k6ff6e_FkiUNgQ@mail.gmail.com>
Message-ID: <C4BA2B63-139B-4994-84D0-85C782FFF397@gmail.com>


	I wouldn't be so picky to have an static IP address in my phone, bur for sure I want a global IPvx one.


-as


On 25 May 2012, at 15:00, Christopher Morrow wrote:

> On Fri, May 25, 2012 at 1:50 PM, Joel jaeggli <joelja at bogus.com> wrote:
>> On 5/25/12 07:35 , valdis.kletnieks at vt.edu wrote:
> 
>>> And the 80% of the world's population that can afford exactly one
>>> device which happens to be mobile, does, what, exactly?
>> 
>> the utlitiy of a static ip is probably lost on someone with only a
>> mobile phone...
> 
> END-2-END!!!



From cscora at apnic.net  Fri May 25 14:03:50 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 26 May 2012 05:03:50 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201205251903.q4PJ3oEe020718@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,
TRNOG, 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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 26 May, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              411471
    Prefixes after maximum aggregation:                          174357
    Deaggregation factor:                                          2.36
    Unique aggregates announced to Internet:                     200214
Total ASes present in the Internet Routing Table:                 41122
    Prefixes per ASN:                                             10.01
Origin-only ASes present in the Internet Routing Table:           33227
Origin ASes announcing only one prefix:                           15654
Transit ASes present in the Internet Routing Table:                5503
Transit-only ASes present in the Internet Routing Table:            137
Average AS path length visible in the Internet Routing Table:       4.5
    Max AS path length visible:                                      29
    Max AS path prepend of ASN ( 2115)                               25
Prefixes from unregistered ASNs in the Routing Table:               385
    Unregistered ASNs in the Routing Table:                         134
Number of 32-bit ASNs allocated by the RIRs:                       2738
Number of 32-bit ASNs visible in the Routing Table:                2392
Prefixes from 32-bit ASNs in the Routing Table:                    6078
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            116
Number of addresses announced to Internet:                   2553429168
    Equivalent to 152 /8s, 50 /16s and 60 /24s
    Percentage of available address space announced:               68.9
    Percentage of allocated address space announced:               69.0
    Percentage of available address space allocated:               99.9
    Percentage of address space in use by end-sites:               92.6
Total number of prefixes smaller than registry allocations:      175392

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   100470
    Total APNIC prefixes after maximum aggregation:               32508
    APNIC Deaggregation factor:                                    3.09
Prefixes being announced from the APNIC address blocks:           96903
    Unique aggregates announced from the APNIC address blocks:    40056
APNIC Region origin ASes present in the Internet Routing Table:    4698
    APNIC Prefixes per ASN:                                       20.63
APNIC Region origin ASes announcing only one prefix:               1245
APNIC Region transit ASes present in the Internet Routing Table:    732
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         25
Number of APNIC region 32-bit ASNs visible in the Routing Table:    217
Number of APNIC addresses announced to Internet:              646675008
    Equivalent to 38 /8s, 139 /16s and 122 /24s
    Percentage of available APNIC address space announced:         82.0

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
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:                    151368
    Total ARIN prefixes after maximum aggregation:                76847
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           121901
    Unique aggregates announced from the ARIN address blocks:     51066
ARIN Region origin ASes present in the Internet Routing Table:    15130
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5742
ARIN Region transit ASes present in the Internet Routing Table:    1602
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:      17
Number of ARIN addresses announced to Internet:               812317120
    Equivalent to 48 /8s, 106 /16s and 249 /24s
    Percentage of available ARIN address space announced:          64.8

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:                    102332
    Total RIPE prefixes after maximum aggregation:                54493
    RIPE Deaggregation factor:                                     1.88
Prefixes being announced from the RIPE address blocks:            94402
    Unique aggregates announced from the RIPE address blocks:     59288
RIPE Region origin ASes present in the Internet Routing Table:    16590
    RIPE Prefixes per ASN:                                         5.69
RIPE Region origin ASes announcing only one prefix:                8060
RIPE Region transit ASes present in the Internet Routing Table:    2655
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          29
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1591
Number of RIPE addresses announced to Internet:               514347400
    Equivalent to 30 /8s, 168 /16s and 81 /24s
    Percentage of available RIPE address space announced:          82.9

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:                   41693
    Total LACNIC prefixes after maximum aggregation:               8266
    LACNIC Deaggregation factor:                                   5.04
Prefixes being announced from the LACNIC address blocks:          41798
    Unique aggregates announced from the LACNIC address blocks:   20439
LACNIC Region origin ASes present in the Internet Routing Table:   1597
    LACNIC Prefixes per ASN:                                      26.17
LACNIC Region origin ASes announcing only one prefix:               440
LACNIC Region transit ASes present in the Internet Routing Table:   308
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:   563
Number of LACNIC addresses announced to Internet:             101399432
    Equivalent to 6 /8s, 11 /16s and 59 /24s
    Percentage of available LACNIC address space announced:        67.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:                   9337
    Total AfriNIC prefixes after maximum aggregation:              2175
    AfriNIC Deaggregation factor:                                  4.29
Prefixes being announced from the AfriNIC address blocks:          7389
    Unique aggregates announced from the AfriNIC address blocks:   2197
AfriNIC Region origin ASes present in the Internet Routing Table:   541
    AfriNIC Prefixes per ASN:                                     13.66
AfriNIC Region origin ASes announcing only one prefix:              167
AfriNIC Region transit ASes present in the Internet Routing Table:  119
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             31746304
    Equivalent to 1 /8s, 228 /16s and 105 /24s
    Percentage of available AfriNIC address space announced:       47.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     2635      11114        1120   Korea Telecom (KIX)
17974     1925        530          80   PT TELEKOMUNIKASI INDONESIA
 7545     1671        301          87   TPG Internet Pty Ltd
 4755     1577        385         155   TATA Communications formerly 
 9829     1298       1085          28   BSNL National Internet Backbo
 7552     1173       1062          11   Vietel Corporation
 9583     1156         87         503   Sify Limited
 4808     1105       2050         317   CNCGROUP IP network: China169
24560     1027        385         167   Bharti Airtel Ltd., Telemedia
 9498      965        291          64   BHARTI Airtel Ltd.

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     3413       3807         193   bellsouth.net, inc. 
 7029     3335        986         159   Windstream Communications Inc
18566     2093        382         181   Covad Communications 
 1785     1909        681         131   PaeTec Communications, Inc.
20115     1639       1566         616   Charter Communications 
22773     1608       2911         121   Cox Communications, Inc.
 4323     1566       1040         379   Time Warner Telecom
30036     1401        260         760   Mediacom Communications Corp 
 7018     1224      10031         821   AT&T WorldNet Services
 7011     1188        317         681   Citizens Utilities 

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
 8402     1718        544          16   Corbina telecom
 2118     1312         97          14   EUnet/RELCOM Autonomous Syste
34984      697        188         172   BILISIM TELEKOM
12479      692        678          70   Uni2 Autonomous System
31148      684         37           9   FreeNet ISP
20940      669        221         522   Akamai Technologies European 
 6830      655       2215         426   UPC Distribution Services
 8551      577        362          71   Bezeq International
 3320      489       8442         402   Deutsche Telekom AG
 3292      471       2108         407   TDC Tele Danmark

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     1917        340         202   TVCABLE BOGOTA 
28573     1891       1171          59   NET Servicos de Comunicao S.A
 6503     1539        418          65   AVANTEL, S.A. 
 8151     1483       3054         337   UniNet S.A. de C.V. 
 7303     1435        901         191   Telecom Argentina Stet-France
26615      902        760          32   Tim Brasil S.A.
27947      689         73          95   Telconet S.A
11172      642         91          73   Servicios Alestra S.A de C.V 
 3816      584        247          89   Empresa Nacional de Telecomun
22047      582        326          15   VTR PUNTO NET S.A. 

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     1367        957          12   TEDATA
24863      846        274          35   LINKdotNET AS number
 6713      496        649          18   Itissalat Al-MAGHRIB
24835      321         80           8   RAYA Telecom - Egypt
 3741      262        905         223   The Internet Solution 
33776      205         12          21   Starcomms Nigeria Limited
12258      197         28          62   Vodacom Internet Company 
16637      171        666          83   MTN Network Solutions
15706      164         32           6   Sudatel Internet Exchange Aut
29571      157         15          16   Ci Telecom Autonomous system 

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     3413       3807         193   bellsouth.net, inc. 
 7029     3335        986         159   Windstream Communications Inc
 4766     2635      11114        1120   Korea Telecom (KIX)
18566     2093        382         181   Covad Communications 
17974     1925        530          80   PT TELEKOMUNIKASI INDONESIA
10620     1917        340         202   TVCABLE BOGOTA 
 1785     1909        681         131   PaeTec Communications, Inc.
28573     1891       1171          59   NET Servicos de Comunicao S.A
 8402     1718        544          16   Corbina telecom
 7545     1671        301          87   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
 7029      3335        3176      Windstream Communications Inc
18566      2093        1912      Covad Communications 
17974      1925        1845      PT TELEKOMUNIKASI INDONESIA
28573      1891        1832      NET Servicos de Comunicao S.A
 1785      1909        1778      PaeTec Communications, Inc.
10620      1917        1715      TVCABLE BOGOTA 
 8402      1718        1702      Corbina telecom
 7545      1671        1584      TPG Internet Pty Ltd
 4766      2635        1515      Korea Telecom (KIX)
22773      1608        1487      Cox Communications, Inc.

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
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
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser
32873   UNALLOCATED  12.46.102.0/24       10912       InterNAP Network Ser
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.44.40.0/21         23456     32-bit ASN transition
5.44.96.0/22         31342     AS from Clanotopia IT-Service
5.44.100.0/22        31342     AS from Clanotopia IT-Service
5.44.104.0/22        29066     velia.net
5.44.184.0/21        23456     32-bit ASN transition
5.44.216.0/21        51109     CAMELHOST SIA
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg

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:19       /9:12      /10:29      /11:81      /12:235     
/13:462     /14:832     /15:1502    /16:12299   /17:6299    /18:10615   
/19:20778   /20:29474   /21:30834   /22:40476   /23:38421   /24:215321  
/25:1229    /26:1457    /27:821     /28:169     /29:67      /30:17      
/31:0       /32:22      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     2995          3335      Windstream Communications Inc
 6389     2132          3413      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
10620     1734          1917      TVCABLE BOGOTA 
 8402     1696          1718      Corbina telecom
30036     1342          1401      Mediacom Communications Corp 
 6503     1293          1539      AVANTEL, S.A. 
 8452     1169          1367      TEDATA
11492     1149          1186      Cable One 
 7011     1073          1188      Citizens Utilities 

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:547       2:744       4:13        5:35        6:3         8:420    
  12:2006     13:1        14:618      15:12       16:3        17:5      
  20:23       23:173      24:1773     27:1319     31:1025     32:57     
  33:2        34:2        36:8        37:623      38:807      40:121    
  41:3203     42:137      44:3        46:1415     47:3        49:452    
  50:548      52:13       54:12       55:9        56:3        57:33     
  58:961      59:496      60:254      61:1217     62:1003     63:2036   
  64:4237     65:2249     66:4480     67:2008     68:1160     69:3196   
  70:933      71:494      72:1824     74:2599     75:493      76:328    
  77:952      78:984      79:492      80:1222     81:936      82:659    
  83:543      84:491      85:1221     86:438      87:907      88:340    
  89:1718     90:289      91:4854     92:550      93:1333     94:1517   
  95:1171     96:368      97:313      98:860      99:38      100:7      
 101:192     103:1105    106:104     107:185     108:307     109:1342   
 110:753     111:923     112:409     113:591     114:628     115:838    
 116:936     117:724     118:906     119:1236    120:357     121:698    
 122:1663    123:1103    124:1379    125:1254    128:554     129:195    
 130:245     131:631     132:287     133:22      134:248     135:59     
 136:214     137:187     138:359     139:186     140:496     141:243    
 142:417     143:555     144:535     145:70      146:506     147:286    
 148:775     149:298     150:191     151:177     152:468     153:172    
 154:12      155:401     156:223     157:381     158:186     159:556    
 160:340     161:265     162:345     163:190     164:606     165:397    
 166:593     167:466     168:862     169:126     170:875     171:131    
 172:4       173:1746    174:578     175:431     176:526     177:797    
 178:1380    180:1211    181:85      182:1005    183:226     184:497    
 185:1       186:2284    187:1098    188:1276    189:1804    190:5536   
 192:5996    193:5562    194:4526    195:3418    196:1208    197:148    
 198:3659    199:4650    200:5857    201:1940    202:8585    203:8607   
 204:4340    205:2550    206:2763    207:2802    208:4059    209:3629   
 210:2766    211:1534    212:2031    213:1934    214:863     215:103    
 216:5096    217:1550    218:553     219:314     220:1240    221:563    
 222:325     223:359    

End of report


From mohta at necom830.hpcl.titech.ac.jp  Fri May 25 16:44:58 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 26 May 2012 06:44:58 +0900
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAL9jLaaOzte1F+aOTu=qK1uLLnrf--Er90oz9ey6ys7+5eydHg@mail.gmail.com>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <CAL9jLaaOzte1F+aOTu=qK1uLLnrf--Er90oz9ey6ys7+5eydHg@mail.gmail.com>
Message-ID: <4FBFFD5A.6020304@necom830.hpcl.titech.ac.jp>

Christopher Morrow wrote:

>>> It certainly does not work on the iPad "3" in Ohio. Not only
>>> that, but I can't even pay them to give me a stable IPv4
>>> address, because if you get a static IP, it disables the
>>> hotspot functionality. Head-->Wall.
>>
>> The proper way to have a static IP address is not to pay mobile
>> operators but to run mobile IP or something like that on your
>> terminal.
>>
>> You can run your home agent at your home or office.
> 
> that seems super scalable and easy for 'people' to do ...

For people of NANOG, certainly.

Or, there can be commercial home agent service providers,
which may not be identical to your mobile operator, which
is something like MVNO over the Internet.

For NAT penetration, mobile tunneling of IP over TCP/UDP is
necessary.

An IPv4 home address may be shared by many mobile
terminals distinguished by port numbers, which is
why IPv6 is not necessary.

						Masataka Ohta


From cidr-report at potaroo.net  Fri May 25 17:00:01 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 25 May 2012 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201205252200.q4PM01bO087586@wattle.apnic.net>

BGP Update Report
Interval: 17-May-12 -to- 24-May-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            71594  4.0%      78.7 -- BSNL-NIB National Internet Backbone
 2 - AS8402            54432  3.1%      44.3 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS8452            38314  2.2%      16.2 -- TE-AS TE-AS
 4 - AS19647           33384  1.9%    4769.1 -- HPOD20001 - Hewlett-Packard Operation Division
 5 - AS12479           26798  1.5%     339.2 -- UNI2-AS France Telecom Espana SA
 6 - AS5800            23371  1.3%      84.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 7 - AS13118           20782  1.2%     593.8 -- ASN-YARTELECOM OJSC Rostelecom
 8 - AS35994           17912  1.0%    1377.8 -- AKAMAI-AS - Akamai Technologies, Inc.
 9 - AS24560           17630  1.0%      19.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
10 - AS17813           16617  0.9%     138.5 -- MTNL-AP Mahanagar Telephone Nigam Ltd.
11 - AS9808            14742  0.8%      11.4 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.
12 - AS7552            12672  0.7%      12.3 -- VIETEL-AS-AP Vietel Corporation
13 - AS28306           12632  0.7%     371.5 -- TC Net Inform?tica e Telecomunica??es LTDA
14 - AS36856           12254  0.7%    4084.7 -- MOZILLA-CORP - Mozilla Corporation
15 - AS19361           11423  0.6%     336.0 -- Atrium Telecomunicacoes Ltda
16 - AS9394            11138  0.6%      15.3 -- CRNET CHINA RAILWAY Internet(CRNET)
17 - AS45899           10666  0.6%       8.0 -- VNPT-AS-VN VNPT Corp
18 - AS27738            9948  0.6%      18.1 -- Ecuadortelecom S.A.
19 - AS8151             9906  0.6%      14.5 -- Uninet S.A. de C.V.
20 - AS28573            9469  0.5%       8.9 -- NET Servicos de Comunicao S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19647           33384  1.9%    4769.1 -- HPOD20001 - Hewlett-Packard Operation Division
 2 - AS44798            4471  0.2%    4471.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
 3 - AS36856           12254  0.7%    4084.7 -- MOZILLA-CORP - Mozilla Corporation
 4 - AS32528            9121  0.5%    3040.3 -- ABBOTT Abbot Labs
 5 - AS35994           17912  1.0%    1377.8 -- AKAMAI-AS - Akamai Technologies, Inc.
 6 - AS55665            1007  0.1%    1007.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia
 7 - AS18592            8586  0.5%     954.0 -- Corporacion Universitaria para el Desarrollo de Internet, A.C.
 8 - AS3                 922  0.1%     366.0 -- SPIDA-AS Spital Davosr
 9 - AS38857            1727  0.1%     863.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd.
10 - AS29126             833  0.1%     833.0 -- DATIQ-AS Datiq B.V.
11 - AS57817             801  0.1%     801.0 -- GTT-TORINO-AS Gruppo Torinese Trasporti S.p.A
12 - AS8657              762  0.0%     762.0 -- CPRM CPRM Autonomous System
13 - AS25644            3014  0.2%     753.5 -- LOGICLINK - Logic Solutions
14 - AS58074             700  0.0%     700.0 -- MIVIROM-AS MIVIROM COM PROD SRL
15 - AS53531             672  0.0%     672.0 -- MIDWEST-CARECENTER - Midwest Palliative & Hospice CareCenter
16 - AS14929            1321  0.1%     660.5 -- VITELITY - Vitelity, LLC
17 - AS16535             644  0.0%     644.0 -- ECHOS-3 - Echostar Holding Purchasing Corporation
18 - AS13263            1914  0.1%     638.0 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S
19 - AS13118           20782  1.2%     593.8 -- ASN-YARTELECOM OJSC Rostelecom
20 - AS3968              587  0.0%     587.0 -- El Colegio de Mexico, A.C.


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 109.161.64.0/19   20099  1.1%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 63.245.221.0/24   12241  0.6%   AS36856 -- MOZILLA-CORP - Mozilla Corporation
 3 - 168.87.176.0/24   10420  0.6%   AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
 4 - 168.87.128.0/21   10397  0.6%   AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
 5 - 41.43.147.0/24     9012  0.5%   AS8452  -- TE-AS TE-AS
 6 - 62.36.252.0/22     7981  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 7 - 62.36.249.0/24     6491  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 69.31.106.0/23     6335  0.3%   AS35994 -- AKAMAI-AS - Akamai Technologies, Inc.
 9 - 155.72.152.0/21    6204  0.3%   AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
10 - 155.72.158.0/24    6189  0.3%   AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
11 - 62.36.241.0/24     6125  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
12 - 62.36.210.0/24     5941  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 23.65.27.0/24      5768  0.3%   AS35994 -- AKAMAI-AS - Akamai Technologies, Inc.
14 - 23.2.6.0/23        5768  0.3%   AS35994 -- AKAMAI-AS - Akamai Technologies, Inc.
15 - 122.161.0.0/16     4877  0.3%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
16 - 130.36.34.0/24     4836  0.2%   AS32528 -- ABBOTT Abbot Labs
17 - 59.177.48.0/20     4639  0.2%   AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd.
18 - 91.202.212.0/22    4471  0.2%   AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
19 - 194.63.9.0/24      4356  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
20 - 130.36.35.0/24     4278  0.2%   AS32528 -- ABBOTT Abbot Labs

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 25 17:00:01 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 25 May 2012 22:00:01 GMT
Subject: The Cidr Report
Message-ID: <201205252200.q4PM01DK087581@wattle.apnic.net>

This report has been generated at Fri May 25 21:12:42 2012 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
        18-05-12    411873      241478
        19-05-12    412420      241334
        20-05-12    412517      241446
        21-05-12    412631      241800
        22-05-12    412894      241768
        23-05-12    413168      241938
        24-05-12    414410      242074
        25-05-12    414357      242162


AS Summary
         41237  Number of ASes in routing system
         17219  Number of ASes announcing only one prefix
          3412  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      112706272  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').

 --- 25May12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     414515   242089   172426    41.6%   All ASes

AS6389      3412      195     3217    94.3%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3375     1862     1513    44.8%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     1608      135     1473    91.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4766      2641     1174     1467    55.5%   KIXS-AS-KR Korea Telecom
AS18566     2093      706     1387    66.3%   COVAD - Covad Communications
                                               Co.
AS28573     1891      518     1373    72.6%   NET Servicos de Comunicao S.A.
AS2118      1312       14     1298    98.9%   RELCOM-AS OOO "NPO Relcom"
AS4323      1568      382     1186    75.6%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1908      809     1099    57.6%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4755      1577      537     1040    65.9%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7303      1435      448      987    68.8%   Telecom Argentina S.A.
AS10620     1917      938      979    51.1%   Telmex Colombia S.A.
AS7552      1173      217      956    81.5%   VIETEL-AS-AP Vietel
                                               Corporation
AS26615      901       32      869    96.4%   Tim Celular S.A.
AS8151      1486      680      806    54.2%   Uninet S.A. de C.V.
AS18101      949      159      790    83.2%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS17974     1925     1168      757    39.3%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4808      1105      349      756    68.4%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS9394       836      152      684    81.8%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS13977      773      123      650    84.1%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS3356      1097      462      635    57.9%   LEVEL3 Level 3 Communications
AS17676      692       75      617    89.2%   GIGAINFRA Softbank BB Corp.
AS30036     1402      788      614    43.8%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS22561     1020      419      601    58.9%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS19262      996      399      597    59.9%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS8452      1368      779      589    43.1%   TE-AS TE-AS
AS24560     1027      449      578    56.3%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS3549      1004      445      559    55.7%   GBLX Global Crossing Ltd.
AS22047      582       31      551    94.7%   VTR BANDA ANCHA S.A.
AS4780       832      284      548    65.9%   SEEDNET Digital United Inc.

Total      43905    14729    29176    66.5%   Top 30 total


Possible Bogus Routes

        5.45.32.0/20         AS58202 
        5.45.32.0/21         AS58202 
        5.45.32.0/22         AS58202 
        5.45.32.0/23         AS58202 
        5.45.34.0/23         AS58202 
        5.45.36.0/22         AS58202 
        5.45.36.0/23         AS58202 
        5.45.38.0/23         AS58202 
        5.45.40.0/21         AS58202 
        5.45.40.0/22         AS58202 
        5.45.40.0/23         AS58202 
        5.45.42.0/23         AS58202 
        5.45.44.0/22         AS58202 
        5.45.44.0/23         AS58202 
        5.45.46.0/23         AS58202 
        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-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        27.112.114.0/24      AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        91.239.220.0/22      AS51445 DUMICONET Dumcon Intermed SRL
        91.239.224.0/23      AS51445 DUMICONET Dumcon Intermed SRL
        91.239.226.0/24      AS51445 DUMICONET Dumcon Intermed SRL
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        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
        120.136.17.0/24      AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        172.14.0.0/24        AS57871 ASTELECENTR TeleCentr Ltd.
        172.15.0.0/24        AS57871 ASTELECENTR TeleCentr Ltd.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.223.60.0/22      AS6910  DIALTELECOMRO Dial Telecom S.R.L.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.58.113.0/24      AS19161 
        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.122.134.0/24     AS38615 
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel 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.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        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 
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        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.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.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS27876 American Data Networks
        216.194.160.0/20     AS27876 American Data Networks


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 ajarvela at gmail.com  Fri May 25 17:08:28 2012
From: ajarvela at gmail.com (Adam)
Date: Fri, 25 May 2012 18:08:28 -0400
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <784967753.85738.1337962693226.JavaMail.root@freethought-internet.co.uk>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <784967753.85738.1337962693226.JavaMail.root@freethought-internet.co.uk>
Message-ID: <CABNh=GA6fV3=6xyw2t+w++ME-iU4RjJ08RMFJDHpU86KSv4Onw@mail.gmail.com>

Edward's response nailed this one on the head.  It has to do with the
additional support/hardware required to support a BGP session.  Granted,
once a BGP session is established it rarely requires any tweaking, but I've
spent hours troubleshooting a downed BGP session because the client's IPS
signature update decided TCP/179 was malicious.

You also have to implement additional filters to protect yourself from what
your client can advertise.  I'm lucky enough to work for a major ISP with
pretty sophisticated filters built off the public route registry, but not
all ISPs have this functionality.

Adam

On Fri, May 25, 2012 at 12:18 PM, Edward J. Dore <
edward.dore at freethought-internet.co.uk> wrote:

> The only thing that I can really think of is that the BGP sessions do take
> up extra CPU time and memory on the routing engine, so there is an
> additional cost to the provider in terms of needing more routers and/or
> bigger routers if they have lots of customers speaking BGP to them that
> they may not have factored in to their standard pricing.
>
> I guess there is also some extra cost in terms of NOC staff and systems to
> monitor the sessions as well as providing any troubleshooting etc. that
> they wouldn't have to do with "standard" customers that are statically
> routed.
>
> Edward Dore
> Freethought Internet
>
> ----- Original Message -----
> From: "Anurag Bhatia" <me at anuragbhatia.com>
> To: "NANOG Mailing List" <nanog at nanog.org>
> Sent: Friday, 25 May, 2012 5:01:11 PM
> Subject: Industry practice for BGP costs - one time or fixed/monthly?
>
> Hello everyone
>
>
> I have been aggressively looking for deals in servers in Europe for
> anycasting. One thing which surprises me is the "setup costs" for BGP. Few
> providers quoted additional $50-100 which looks OK but a few of them quoted
> as high as $150 *extra every month* just for having BGP (no full routing
> table, but just default route pointing). Is there's any technical logic
> behind such heavy costs? I mean at the end of day we are all talking at
> layer 3 and thus it does not involves any hard connection/physical work.
> What other members pay for BGP setup costs?
>
>
>
> Thanks!
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
> Twitter<https://twitter.com/anurag_bhatia>|
> Google+ <https://plus.google.com/118280168625121532854>
>
>

From sethm at rollernet.us  Fri May 25 17:12:08 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 25 May 2012 15:12:08 -0700
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CABNh=GA6fV3=6xyw2t+w++ME-iU4RjJ08RMFJDHpU86KSv4Onw@mail.gmail.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <784967753.85738.1337962693226.JavaMail.root@freethought-internet.co.uk>
 <CABNh=GA6fV3=6xyw2t+w++ME-iU4RjJ08RMFJDHpU86KSv4Onw@mail.gmail.com>
Message-ID: <4FC003B8.5080108@rollernet.us>

On 5/25/12 3:08 PM, Adam wrote:
> 
> You also have to implement additional filters to protect yourself from what
> your client can advertise.  I'm lucky enough to work for a major ISP with
> pretty sophisticated filters built off the public route registry, but not
> all ISPs have this functionality.
> 

Is it really that hard to use a simple prefix list containing the one
prefix they're allowed to announce and default deny everything else?

~Seth


From valdis.kletnieks at vt.edu  Fri May 25 17:16:09 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Fri, 25 May 2012 18:16:09 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: Your message of "Sat, 26 May 2012 06:44:58 +0900."
 <4FBFFD5A.6020304@necom830.hpcl.titech.ac.jp>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <CAL9jLaaOzte1F+aOTu=qK1uLLnrf--Er90oz9ey6ys7+5eydHg@mail.gmail.com>
 <4FBFFD5A.6020304@necom830.hpcl.titech.ac.jp>
Message-ID: <14098.1337984169@turing-police.cc.vt.edu>

On Sat, 26 May 2012 06:44:58 +0900, Masataka Ohta said:
> An IPv4 home address may be shared by many mobile
> terminals distinguished by port numbers, which is
> why IPv6 is not necessary.

An IPv4 address can also be shared by many mobile terminals
distinguished by AOL userids.  How did that work out?

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

From mpalmer at hezmatt.org  Fri May 25 18:01:29 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Sat, 26 May 2012 09:01:29 +1000
Subject: Equinix Direct
In-Reply-To: <CAE_ug16CDWff=2zbrb7XLozRzCRS7Vi3OP9TmySRAJmsDANQ0Q@mail.gmail.com>
References: <CAE_ug17-Pk46LQ6_fObExeE_M0f6qpNBtTQDH2+-v658N8KC4Q@mail.gmail.com>
 <CAE_ug16CDWff=2zbrb7XLozRzCRS7Vi3OP9TmySRAJmsDANQ0Q@mail.gmail.com>
Message-ID: <20120525230129.GM24953@hezmatt.org>

On Fri, May 25, 2012 at 08:19:10AM -0400, Tim Durack wrote:
> It does concern me that the only connectivity options are FE/GE, no
> 10GE at this time. Makes me wonder about how serious the service is,
> and whether I will end up with a more congested service than simply
> getting a mix of transit providers myself.

It depends on what you mean by "serious".  As I understand it, it's not
targeted at the big end of town -- there's no way you wouldn't be going
direct to the big tier 1s yourself if you needed multiple 10GE pipes, for a
wide variety of reasons.  Instead, it's intended as a "leg up" for the
smaller players to get into the marketplace *without* needing to make a huge
commitment to the big tier 1s and manage far more moving parts than would
otherwise be the case.

- Matt



From mohta at necom830.hpcl.titech.ac.jp  Fri May 25 18:19:18 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 26 May 2012 08:19:18 +0900
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <14098.1337984169@turing-police.cc.vt.edu>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <CAL9jLaaOzte1F+aOTu=qK1uLLnrf--Er90oz9ey6ys7+5eydHg@mail.gmail.com>
 <4FBFFD5A.6020304@necom830.hpcl.titech.ac.jp>
 <14098.1337984169@turing-police.cc.vt.edu>
Message-ID: <4FC01376.9010204@necom830.hpcl.titech.ac.jp>

valdis.kletnieks at vt.edu wrote:

>> An IPv4 home address may be shared by many mobile
>> terminals distinguished by port numbers, which is
>> why IPv6 is not necessary.
> 
> An IPv4 address can also be shared by many mobile terminals
> distinguished by AOL userids.  How did that work out?

The point is that all the transport layer protocol have port
numbers.

So, if you have a stable IP address and, say, 256 stable port
numbers, your mobile device running applications as a server,
can be reached by the port number, distinguished from other
mobile devices sharing the IP address.

Such a service might cost $10 a month or Gree might offer
it free of charge.

					Masataka Ohta


From mpalmer at hezmatt.org  Fri May 25 19:06:03 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Sat, 26 May 2012 10:06:03 +1000
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
Message-ID: <20120526000603.GN24953@hezmatt.org>

On Fri, May 25, 2012 at 09:31:11PM +0530, Anurag Bhatia wrote:
> I have been aggressively looking for deals in servers in Europe for
> anycasting. One thing which surprises me is the "setup costs" for BGP. Few
> providers quoted additional $50-100 which looks OK but a few of them quoted
> as high as $150 *extra every month* just for having BGP (no full routing
> table, but just default route pointing). Is there's any technical logic
> behind such heavy costs? I mean at the end of day we are all talking at
> layer 3 and thus it does not involves any hard connection/physical work.
> What other members pay for BGP setup costs?

We pay what our providers think they can get away with.  Like most pricing
decisions, they're not based on any "technical logic", they're based on what
the market will bear.  Feel free to turn the process around -- decide what
the service is worth to you, tell the provider of the service that price,
and let them decide if they want to provide it to you at that price.  Don't
be too surprised if you get monkeys in exchange for your peanuts, though.

- Matt



From ryanczak at gmail.com  Sat May 26 06:33:15 2012
From: ryanczak at gmail.com (Matt Ryanczak)
Date: Sat, 26 May 2012 07:33:15 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <C4BA2B63-139B-4994-84D0-85C782FFF397@gmail.com>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <36677.1337956549@turing-police.cc.vt.edu> <4FBFC67C.5010101@bogus.com>
 <CAL9jLaY-8DuWruzgtroRi5YxgWVHeAuvGZV-k6ff6e_FkiUNgQ@mail.gmail.com>
 <C4BA2B63-139B-4994-84D0-85C782FFF397@gmail.com>
Message-ID: <4FC0BF7B.1020304@gmail.com>

On 5/25/12 2:35 PM, Arturo Servin wrote:
> 
> 	I wouldn't be so picky to have an static IP address in my phone, bur for sure I want a global IPvx one.

but would you want that dynamic IP address behind layers of NAT, ALG,
etc. or open and accessible?



From aservin at lacnic.net  Sat May 26 07:37:43 2012
From: aservin at lacnic.net (Arturo Servin)
Date: Sat, 26 May 2012 09:37:43 -0300
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <4FC0BF7B.1020304@gmail.com>
References: <b0382b3e-a003-49ca-8933-1d6d1a2e070b@zimbra.network1.net>
 <4FBF25DF.1000604@necom830.hpcl.titech.ac.jp>
 <36677.1337956549@turing-police.cc.vt.edu> <4FBFC67C.5010101@bogus.com>
 <CAL9jLaY-8DuWruzgtroRi5YxgWVHeAuvGZV-k6ff6e_FkiUNgQ@mail.gmail.com>
 <C4BA2B63-139B-4994-84D0-85C782FFF397@gmail.com> <4FC0BF7B.1020304@gmail.com>
Message-ID: <9E1B1AE3-2871-43BE-8ED0-1B15A5B10442@lacnic.net>


On 26 May 2012, at 08:33, Matt Ryanczak wrote:

> On 5/25/12 2:35 PM, Arturo Servin wrote:
>> 
>> 	I wouldn't be so picky to have an static IP address in my phone, bur for sure I want a global IPvx one.
> 
> but would you want that dynamic IP address behind layers of NAT, ALG,
> etc. or open and accessible?
> 

	Not at all.

	I want to be free.

	
-as



From joelja at bogus.com  Sat May 26 09:19:24 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 26 May 2012 07:19:24 -0700
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <4FC003B8.5080108@rollernet.us>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <784967753.85738.1337962693226.JavaMail.root@freethought-internet.co.uk>
 <CABNh=GA6fV3=6xyw2t+w++ME-iU4RjJ08RMFJDHpU86KSv4Onw@mail.gmail.com>
 <4FC003B8.5080108@rollernet.us>
Message-ID: <4FC0E66C.7070301@bogus.com>

On 5/25/12 15:12 , Seth Mattinen wrote:
> On 5/25/12 3:08 PM, Adam wrote:
>>
>> You also have to implement additional filters to protect yourself from what
>> your client can advertise.  I'm lucky enough to work for a major ISP with
>> pretty sophisticated filters built off the public route registry, but not
>> all ISPs have this functionality.
>>
> 
> Is it really that hard to use a simple prefix list containing the one
> prefix they're allowed to announce and default deny everything else?

If it's built off a registry, the customer can change it without direct
coordination which is a huge labor saving activity.

> ~Seth
> 



From askoorb+nanog at gmail.com  Sat May 26 09:44:54 2012
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Sat, 26 May 2012 15:44:54 +0100
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
Message-ID: <CALKLF0_6NFBr2Qtx2npTVxHJmvqH5qXK0Zanc=izem8jbnUu-A@mail.gmail.com>

Hello,

On Fri, May 25, 2012 at 5:01 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Hello everyone
>
>
> I have been aggressively looking for deals in servers in Europe for
> anycasting.

If you're looking for stuff in "Europe" (I'm assuming Western European
EU member states, rather than states bordering Russia or the Middle
East) one place you may wish to try is UKNOF (http://www.uknof.org.uk)
they have the UK equivalent of the NANOG mailing list, so will be able
to help you more with UK (and their neighbours) specific questions;
it's a different market there remember - "industry standards" are
different!

The UK and Ireland are also pretty good places geographically for
server locations, with lots of fat pipes to mainland Europe and across
the Atlantic to North America; there is a reason people like Amazon
put their data centers there.

HTH,

Alex


From lsc at prgmr.com  Sat May 26 20:39:16 2012
From: lsc at prgmr.com (Luke S. Crawford)
Date: Sat, 26 May 2012 21:39:16 -0400
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <20120526000603.GN24953@hezmatt.org>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <20120526000603.GN24953@hezmatt.org>
Message-ID: <20120527013916.GE16179@luke.xen.prgmr.com>

On Sat, May 26, 2012 at 10:06:03AM +1000, Matthew Palmer wrote:
> We pay what our providers think they can get away with.  Like most pricing
> decisions, they're not based on any "technical logic", they're based on what
> the market will bear.  Feel free to turn the process around -- decide what
> the service is worth to you, tell the provider of the service that price,
> and let them decide if they want to provide it to you at that price.  Don't
> be too surprised if you get monkeys in exchange for your peanuts, though.

Are you suggesting that you get worse service after you negotiate a better
deal with a particular provider?   I mean, certainly the different providers 
have different levels of quality, but my experience has been that with a 
particular provider, you get the same service regardless of how well you 
negotiated, assuming you eventually came to an agreement.

(quite often, in fact, I see the customer that asks for more... quite 
often gets more, without paying more.  We've all had that 'difficult
customer' that consumes far more support hours than what they pay
could possibly buy.  Quite often, that same customer negotiated a 
better deal, too.  It's a cost of selecting for customers that are 
good at negotiation that most businesspeople don't take into account.)

Back to negotiating for initial prices:  as far as I can tell, this is
largely a matter of knowing the market.  The high initial prices
are there so that the people that are unable or unwilling to put in
the effort to find what the real market prices are pay a lot more.   

I know as my own business has progressed?  the prices I pay even for
the same unit of commodities that don't fall in price (like rack
space) goes down fairly dramatically every year, simply because
I understand the market better.  



From mpalmer at hezmatt.org  Sat May 26 21:34:22 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Sun, 27 May 2012 12:34:22 +1000
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <20120527013916.GE16179@luke.xen.prgmr.com>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <20120526000603.GN24953@hezmatt.org>
 <20120527013916.GE16179@luke.xen.prgmr.com>
Message-ID: <20120527023422.GG18702@hezmatt.org>

On Sat, May 26, 2012 at 09:39:16PM -0400, Luke S. Crawford wrote:
> On Sat, May 26, 2012 at 10:06:03AM +1000, Matthew Palmer wrote:
> > We pay what our providers think they can get away with.  Like most pricing
> > decisions, they're not based on any "technical logic", they're based on what
> > the market will bear.  Feel free to turn the process around -- decide what
> > the service is worth to you, tell the provider of the service that price,
> > and let them decide if they want to provide it to you at that price.  Don't
> > be too surprised if you get monkeys in exchange for your peanuts, though.
> 
> Are you suggesting that you get worse service after you negotiate a better
> deal with a particular provider?

To a certain extent, yes.  It has been my experience (from both the service
provider and the customer point-of-view) that customers who aren't worth as
much to a supplier don't get as much "love", because the cost of losing
their business to a competitor is much less (or, in some cases, would be a
net win).

However, my main point was that if you are mainly concerned about price,
rather than quality of service (or, more precisely, the value-for-money
ratio between the two), you are likely to end up with a substandard service. 
I will concede, however, that I didn't make that point particularly clear,
for which I apologise.

- Matt


-- 
Advocating Object-Oriented Programming is like advocating Pants-Oriented
Clothing.
		-- Jacob Gabrielson



From mysidia at gmail.com  Sun May 27 11:54:31 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 27 May 2012 11:54:31 -0500
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <20120527023422.GG18702@hezmatt.org>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <20120526000603.GN24953@hezmatt.org>
 <20120527013916.GE16179@luke.xen.prgmr.com>
 <20120527023422.GG18702@hezmatt.org>
Message-ID: <CAAAwwbVNBduMEXEFw5Lu6TuwBPKLYvMXHxJZAep=uRRSuCEkNw@mail.gmail.com>

On 5/26/12, Matthew Palmer <mpalmer at hezmatt.org> wrote:
> On Sat, May 26, 2012 at 09:39:16PM -0400, Luke S. Crawford wrote:
>> On Sat, May 26, 2012 at 10:06:03AM +1000, Matthew Palmer wrote:

Whether $150/month or so just for BGP on a low-speed (sub-100M)
link is reasonable or not depends on the SP.

If there is  1 BGP customer, YOU, or even 1 to 10 customers, then it
sounds reasonable to me; even downright cheap, when you consider
deploying a custom service may require additional training of support
staff, more required involvement of higher level network architects,
and  require additional review of future network changes.
And the don't know in advance how many times you will be calling in
about that BPG session,  and requiring assistance from an engineer
well-versed in BGP,  not just standard Frontline or 2nd level support
work.


>> > We pay what our providers think they can get away with.  Like most
>> > decisions, they're not based on any "technical logic", they're based on
>> Are you suggesting that you get worse service after you negotiate a
>> deal with a particular provider?
> To a certain extent, yes.  It has been my experience (from both the service
> provider and the customer point-of-view) that customers who aren't worth as
> much to a supplier don't get as much "love", because the cost of losing
> their business to a competitor is much less (or, in some cases, would be a
[snip]
An org that negotiated a lower price per service are not necessarily
"worth" less, because measurement of worth is complicated. Might
purchase more services, might require fewer support/"free consulting"
incidents,  caused by issues that have nothing in the service
provider's control, such as customer-owned router crashing; they might
have more associates that will listen to their recommendations about
who to buy service from..  too little love may get an influential "I
recommend against using this provider, because...."

Support SLA, Service SLA, and all other expectations should be part of
the negotiation; otherwise you run the risk that  your unstated
expectations will not be met,  because there may be unstated
tradeoff/benefits removed for offering the low price   that you did
not include in the negotiation.

If the amount proposed isn't worth the level of service, the provider
needs to disclose that upfront,  probably in the form of a
counteroffer

--
-JH


From lsc at prgmr.com  Sun May 27 14:38:39 2012
From: lsc at prgmr.com (Luke S. Crawford)
Date: Sun, 27 May 2012 15:38:39 -0400
Subject: Industry practice for BGP costs - one time or fixed/monthly?
In-Reply-To: <20120527023422.GG18702@hezmatt.org>
References: <CAJ0+aXYRwZazh6kOD8abkHrZYfzpPqCFZTWddH-dGhTCHYBjjQ@mail.gmail.com>
 <20120526000603.GN24953@hezmatt.org>
 <20120527013916.GE16179@luke.xen.prgmr.com>
 <20120527023422.GG18702@hezmatt.org>
Message-ID: <20120527193839.GA22165@luke.xen.prgmr.com>

On Sun, May 27, 2012 at 12:34:22PM +1000, Matthew Palmer wrote:
> On Sat, May 26, 2012 at 09:39:16PM -0400, Luke S. Crawford wrote:
> > On Sat, May 26, 2012 at 10:06:03AM +1000, Matthew Palmer wrote:

> > > ... Feel free to turn the process around -- decide what
> > > the service is worth to you, tell the provider of the service that price,
> > > and let them decide if they want to provide it to you at that price.  Don't
> > > be too surprised if you get monkeys in exchange for your peanuts, though.
> > 
> > Are you suggesting that you get worse service after you negotiate a better
> > deal with a particular provider?
> 
> To a certain extent, yes.  It has been my experience (from both the service
> provider and the customer point-of-view) that customers who aren't worth as
> much to a supplier don't get as much "love", because the cost of losing
> their business to a competitor is much less (or, in some cases, would be a
> net win).

How is this communicated to the people doing the support?  is there a 
'cheap jerk' bit in the database?   Until I got my own company, 
working as the technical guy in another company, I was never 
told what a customer was paying.  I mean, I could see what plan they
were on, but as a technical person I don't see the price they are
paying unless I go directly into the billing database, and that sort 
of thing is usually super secret.  

>From a "business logic" perspective, I agree that it seems like
you describe the way it ought to be.  Sometimes at very small companies?
this is the case.  I remember a few times, the boss telling me 
"customer X is a big deal.  go out of your way for them"  - but that
happens less and less as the company gets bigger.  Think, for 
a moment; if it's not in the database in an easily accessible
manner, even if you do all the negotiation yourself, how many 
customers would you need before you lost track of who underpaid and
who overpaid?  for me, the limit would be around 5.  I bet even a 
professional relationship manager would have a hard time around 100
or so.  

Of all my current providers, the worst response I get from sales
is from the provider that I'm paying full price for.  I mean, maybe
that's because  they see themselves as premium and I'm small?
but maybe that's because I showed weakness by accepting the list price.
Or maybe it's because when I met the salesperson I was driving a 
cheap car and dressed for work.  I don't know.  



From nabilsharma at hotmail.com  Sun May 27 21:27:15 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Mon, 28 May 2012 02:27:15 +0000
Subject: Comcast Service for Non-Cap Bandwidth
Message-ID: <SNT129-W173056B934D9CB9B57B6C7A3040@phx.gbl>


NANOG List,
I am developing streaming video service, and seek your feedback... I would like to pay Comcast forward so that accessing our site does not count against user's bandwidth caps, similar to the arrangement made with Microsoft Xbox.
Does anyone know the name of this service? Is it something the sales contact at http://as7922.peeringdb.com/ can provide?
Thank you for your time.
Sincerely,
Nabil
 		 	   		  

From vixie at isc.org  Mon May 28 05:32:47 2012
From: vixie at isc.org (paul vixie)
Date: Mon, 28 May 2012 10:32:47 +0000
Subject: isc - a good business
Message-ID: <4FC3544F.5070407@isc.org>

greetings. i didn't notice this before, and i want to complete the record.

i'm paying more attention to the quoting this time, too.

> On Wed, May 23, 2012 at 04:33:28PM -0400, Christopher Morrow wrote:
> > On Wed, May 23, 2012 at 1:40 AM,  <bmanning at vacation.karoshi.com> wrote:
> > > Paul will be there to turn things off when
> > >        they no longer make money for his company.
> > 
> > is the dns changer thingy making money for isc?

no. yes. depends on what you mean.

we're under contract to the department of justice to run the servers. the amount is
intended to be cost-recovery level. (doing stuff like this for nothing does not scale,
unless the business is successful enough elsewhere, and even then there'll be limits.)

> From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
> Date: Wed, 23 May 2012 21:00:27 +0000
> Message-ID: <20120523210027.GA26231 at vacation.karoshi.com.>
>
> 	pretty sure.  a contract w/ the Feds, outsouring contracts w/ affected ISPs
> 	when the Fed deal runs out, development funding to code these kinds of fixes 
> 	into future versions of software, any number of second and third order fallout.

i don't know of any outsourcing contracts that will come into force when the fed deal
runs out. there is no development funding because there are no code fixes for this kind
of problem. i am certainly hoping for second and third order fallout; we pay the people
who write BIND using money collected from other people who buy support for BIND, or
consulting, or training, or custom feature development. that's how we keep BIND free,
and that's how we use a BSD-like license rather than a GPL-like license -- noone who
derives their appliance or product from BIND has any obligation to anybody. (noting,
nlnetlabs for unbound and nsd also use a BSD-like license, so ISC is not alone here.)

> 	No telling how effective constent self-promotion is.  One thing is clear, Paul
> 	is able to tell a great story.

thanks for your kind words. i've been trying to uplevel my storytelling capability since
i've long since lost my coding skills.

> 	but its all speculation from here. ISC is well positioned to extract value
> 	from both ends of the spectrum.  They have a great business model. The optics
> 	look pretty odd from here, at lesat to me however - I am very glad for: )open 
> 	source & )other vendors of DNS SW.

the women and men of ISC work their asses off to keep the world safer and saner. as you
puzzle over our business model please keep in mind that there is no "exit" possibility
here -- no IPO, no buyout. salaries at ISC are fair and reasonable, but nobody's getting
rich doing this work. so while i am likewise glad for open source and for other vendors
of open source DNS software, i'm struggling to grasp the intended suggestion. should ISC
stop giving away software? should we stop adding the features to our software that make it
relevant and desireable? should we stop selling the support and training and consulting
that make it possible to give away this software?

if you have a specific accusation of evil-doing, or a specific suggestion for how ISC can
become more morally pure, then please say exactly what you mean, and we can discuss that.

for more information, see: <http://www.isc.org/community/blog/201001/why-isc-not-profit>.
the short version is: ISC is a good business, we do good things, mostly for free, but also
for our customers. and we're totally unapologetic about what we do and who we are.

paul



From randy at psg.com  Mon May 28 06:52:07 2012
From: randy at psg.com (Randy Bush)
Date: Mon, 28 May 2012 20:52:07 +0900
Subject: isc - a good business
In-Reply-To: <4FC3544F.5070407@isc.org>
References: <4FC3544F.5070407@isc.org>
Message-ID: <m2zk8swmjc.wl%randy@psg.com>

fwiw, i think isc and isc staff are very well intentioned and do a lot
of good work for the community.  i have doubts about isc's business
model, but definitely not that it makes too much money or is greedy.
maybe a bit too much layer ten for my taste.  and i run and appreciate
the software.

randy


From evgeniy at ip.datagroup.ua  Mon May 28 08:31:34 2012
From: evgeniy at ip.datagroup.ua (Evgeniy Aikashev)
Date: Mon, 28 May 2012 16:31:34 +0300
Subject: Bogon list update for prefix for 5.1.0.0/19
Message-ID: <1327824649.20120528163134@ip.datagroup.ua>

Dear all,
We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our customers have no access to some part of Internet if they use these IPs.
Could you please update your bogon filters to permit this range.

Thanks.
-- 
Best regards,
Evgeniy Aikashev
network engineer
PJSC DATAGROUP




From vixie at isc.org  Mon May 28 08:43:24 2012
From: vixie at isc.org (paul vixie)
Date: Mon, 28 May 2012 13:43:24 +0000
Subject: isc - a good business
In-Reply-To: <m2zk8swmjc.wl%randy@psg.com>
References: <4FC3544F.5070407@isc.org> <m2zk8swmjc.wl%randy@psg.com>
Message-ID: <4FC380FC.3020907@isc.org>

On 5/28/2012 11:52 AM, Randy Bush wrote:
> ... maybe a bit too much layer ten for my taste. ...

on that, we're trying to improve. for example, we used to forego
features that some of us found repugnant, such as nxdomain remapping /
ad insertion. since the result was that our software was less relevant
but that there was no reduction in nxdomain remapping as a result of
BIND not providing it. so we dropped some of the layer ten stuff and
moved more in the direction of providing features the community of
interest found relevant. some say we sold out. maybe that's what manning
is on about, i can't tell. the software is free, and isc cherishes our
relevance.

if you catch us doing wierd layer ten stuff that bugs you, give a shout.
maybe we don't really mean it.

> ... and i run and appreciate the software.

that's why we're here.

paul


From morrowc.lists at gmail.com  Mon May 28 09:26:50 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 28 May 2012 10:26:50 -0400
Subject: isc - a good business
In-Reply-To: <4FC3544F.5070407@isc.org>
References: <4FC3544F.5070407@isc.org>
Message-ID: <CAL9jLabv2us=-uch7pRZ5TXAgsR_w3SDAi-WBDohTZr2Bmx4iQ@mail.gmail.com>

On Mon, May 28, 2012 at 6:32 AM, paul vixie <vixie at isc.org> wrote:
> i'm paying more attention to the quoting this time, too.
>
>> On Wed, May 23, 2012 at 04:33:28PM -0400, Christopher Morrow wrote:
>> > On Wed, May 23, 2012 at 1:40 AM, ?<bmanning at vacation.karoshi.com> wrote:
>> > > Paul will be there to turn things off when
>> > > ? ? ? ?they no longer make money for his company.
>> >
>> > is the dns changer thingy making money for isc?
>
> no. yes. depends on what you mean.
>
> we're under contract to the department of justice to run the servers. the amount is
> intended to be cost-recovery level. (doing stuff like this for nothing does not scale,
> unless the business is successful enough elsewhere, and even then there'll be limits.)

Thanks for the clarification.

-chris
(another bind user...)


From me at anuragbhatia.com  Mon May 28 13:51:10 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 29 May 2012 00:21:10 +0530
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
Message-ID: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>

Greetings everyone!


One small concern I wanted to discuss here. I know few registry/registrars
which do not accept both (or all) name servers of domain name on same
subnet. They demand at least 1 DNS server should be on different subnet for
failover reasons (old thoughts).

How one can deal with such case in case of anycasting setup which using one
single subnet everywhere?


Anyone else in community got similar issues?



Thanks.

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From drc at virtualized.org  Mon May 28 14:18:32 2012
From: drc at virtualized.org (David Conrad)
Date: Mon, 28 May 2012 12:18:32 -0700
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
Message-ID: <F95A06F9-39E8-4830-8D55-C5983EA9B5F4@virtualized.org>

Anurag,

On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
> I know few registry/registrars
> which do not accept both (or all) name servers of domain name on same
> subnet. They demand at least 1 DNS server should be on different subnet for
> failover reasons (old thoughts).

IMHO appropriately so.  The fact that anycast allows for multiple (potentially) geographically distributed machines to respond to DNS queries does not remove the value of having multiple prefixes for DNS servers. Single points of failure are generally bad. Imagine the scenario where someone makes a booboo and accidentally filters your single anycast prefix...

Regards,
-drc




From dot at dotat.at  Mon May 28 14:20:11 2012
From: dot at dotat.at (Tony Finch)
Date: Mon, 28 May 2012 20:20:11 +0100
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
Message-ID: <alpine.LSU.2.00.1205282018370.5807@hermes-2.csi.cam.ac.uk>

Anurag Bhatia <me at anuragbhatia.com> wrote:
>
> One small concern I wanted to discuss here. I know few
> registry/registrars which do not accept both (or all) name servers of
> domain name on same subnet. They demand at least 1 DNS server should be
> on different subnet for failover reasons (old thoughts).
>
> How one can deal with such case in case of anycasting setup which using
> one single subnet everywhere?

You still want name servers on more than one subnet in case the anycast
setup breaks.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
South Utsire: Northwesterly 6 to gale 8 decreasing 4 or 5. Moderate or rough.
Fair. Good.


From me at anuragbhatia.com  Mon May 28 14:24:01 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 29 May 2012 00:54:01 +0530
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <alpine.LSU.2.00.1205282018370.5807@hermes-2.csi.cam.ac.uk>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <alpine.LSU.2.00.1205282018370.5807@hermes-2.csi.cam.ac.uk>
Message-ID: <CAJ0+aXaoTEUy+pog_g0cq2JE5SU82yX9+sOXmrHw6EeF9J77_A@mail.gmail.com>

On Tue, May 29, 2012 at 12:50 AM, Tony Finch <dot at dotat.at> wrote:

> Anurag Bhatia <me at anuragbhatia.com> wrote:
> >
> > One small concern I wanted to discuss here. I know few
> > registry/registrars which do not accept both (or all) name servers of
> > domain name on same subnet. They demand at least 1 DNS server should be
> > on different subnet for failover reasons (old thoughts).
> >
> > How one can deal with such case in case of anycasting setup which using
> > one single subnet everywhere?
>
> You still want name servers on more than one subnet in case the anycast
> setup breaks.
>
> I am building redundancy within that setup. I mean it will be software
based BGP so if hardware if fried up, it will break BGP session and pull
off routes anyway and for cases like DNS server (software) failure, I will
monitor it via simple bash script which can turn bgp daemon down. So once
it is off, routing tables should take it to different node.


> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> South Utsire: Northwesterly 6 to gale 8 decreasing 4 or 5. Moderate or
> rough.
> Fair. Good.
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From bortzmeyer at nic.fr  Mon May 28 14:32:29 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 28 May 2012 21:32:29 +0200
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <25604_1338233229_4FC3D18D_25604_1794_1_CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
References: <25604_1338233229_4FC3D18D_25604_1794_1_CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
Message-ID: <20120528193229.GA24594@sources.org>

On Tue, May 29, 2012 at 12:21:10AM +0530,
 Anurag Bhatia <me at anuragbhatia.com> wrote 
 a message of 28 lines which said:

> I know few registry/registrars which do not accept both (or all)
> name servers of domain name on same subnet.

Since my employer is one of these registries, let me mention that I
fully agree with David Conrad here.

On Tue, May 29, 2012 at 12:54:01AM +0530,
 Anurag Bhatia <me at anuragbhatia.com> wrote 
 a message of 42 lines which said:

> I am building redundancy within that setup. I mean it will be
> software based BGP so if hardware if fried up, it will break BGP
> session and pull off routes anyway and for cases like DNS server
> (software) failure, I will monitor it via simple bash script which
> can turn bgp daemon down.

You will address *some* failure modes with this setup but not
all. Again, see David Conrad's examples of a fat finger adding your
prefix in a route-map.


From patrick at ianai.net  Mon May 28 14:37:13 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 28 May 2012 15:37:13 -0400
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <CAJ0+aXaoTEUy+pog_g0cq2JE5SU82yX9+sOXmrHw6EeF9J77_A@mail.gmail.com>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <alpine.LSU.2.00.1205282018370.5807@hermes-2.csi.cam.ac.uk>
 <CAJ0+aXaoTEUy+pog_g0cq2JE5SU82yX9+sOXmrHw6EeF9J77_A@mail.gmail.com>
Message-ID: <80B8C7B7-674F-4194-BA3B-21DABDB80BF8@ianai.net>

On May 28, 2012, at 15:24 , Anurag Bhatia wrote:
> On Tue, May 29, 2012 at 12:50 AM, Tony Finch <dot at dotat.at> wrote:
>> Anurag Bhatia <me at anuragbhatia.com> wrote:
>>> 
>>> One small concern I wanted to discuss here. I know few
>>> registry/registrars which do not accept both (or all) name servers of
>>> domain name on same subnet. They demand at least 1 DNS server should be
>>> on different subnet for failover reasons (old thoughts).
>>> 
>>> How one can deal with such case in case of anycasting setup which using
>>> one single subnet everywhere?
>> 
>> You still want name servers on more than one subnet in case the anycast
>> setup breaks.
>> 
> I am building redundancy within that setup. I mean it will be software
> based BGP so if hardware if fried up, it will break BGP session and pull
> off routes anyway and for cases like DNS server (software) failure, I will
> monitor it via simple bash script which can turn bgp daemon down. So once
> it is off, routing tables should take it to different node.

Famous last words: "I am building redundancy...."  As if "redundancy" stops someone else announcing your prefix and sucking in half the packets on the 'Net meant for you.  (Just one of many failure modes against which you cannot possibly defend.)

That said, IMHO, if you want to shoot yourself in the foot, you should be allowed to do so.  Your foot, your decision.  I'm sure there are registrars out there that do not babysit you.  Find one that doesn't tell you how to run your own infrastructure.

And enjoy the extra spice that gives your life. :)

-- 
TTFN,
patrick



From me at anuragbhatia.com  Mon May 28 14:47:34 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 29 May 2012 01:17:34 +0530
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <80B8C7B7-674F-4194-BA3B-21DABDB80BF8@ianai.net>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <alpine.LSU.2.00.1205282018370.5807@hermes-2.csi.cam.ac.uk>
 <CAJ0+aXaoTEUy+pog_g0cq2JE5SU82yX9+sOXmrHw6EeF9J77_A@mail.gmail.com>
 <80B8C7B7-674F-4194-BA3B-21DABDB80BF8@ianai.net>
Message-ID: <CAJ0+aXYp-7AUqXymdixu8w6oWo8Za=ppHSUqnHBb0VEZQsDTGA@mail.gmail.com>

On Tue, May 29, 2012 at 1:07 AM, Patrick W. Gilmore <patrick at ianai.net>wrote:

> On May 28, 2012, at 15:24 , Anurag Bhatia wrote:
> > On Tue, May 29, 2012 at 12:50 AM, Tony Finch <dot at dotat.at> wrote:
> >> Anurag Bhatia <me at anuragbhatia.com> wrote:
> >>>
> >>> One small concern I wanted to discuss here. I know few
> >>> registry/registrars which do not accept both (or all) name servers of
> >>> domain name on same subnet. They demand at least 1 DNS server should be
> >>> on different subnet for failover reasons (old thoughts).
> >>>
> >>> How one can deal with such case in case of anycasting setup which using
> >>> one single subnet everywhere?
> >>
> >> You still want name servers on more than one subnet in case the anycast
> >> setup breaks.
> >>
> > I am building redundancy within that setup. I mean it will be software
> > based BGP so if hardware if fried up, it will break BGP session and pull
> > off routes anyway and for cases like DNS server (software) failure, I
> will
> > monitor it via simple bash script which can turn bgp daemon down. So once
> > it is off, routing tables should take it to different node.
>
> Famous last words: "I am building redundancy...."  As if "redundancy"
> stops someone else announcing your prefix and sucking in half the packets
> on the 'Net meant for you.  (Just one of many failure modes against which
> you cannot possibly defend.)
>
> Well, you could make me realize those painful points more humble way.
Anyways, really appreciate points you made and yes, I must find some way
out to them.  May be I was wrong in posting question here before doing my
homework. I am sorry everyone.


Thanks.


That said, IMHO, if you want to shoot yourself in the foot, you should be
> allowed to do so.  Your foot, your decision.  I'm sure there are registrars
> out there that do not babysit you.  Find one that doesn't tell you how to
> run your own infrastructure.
>
> And enjoy the extra spice that gives your life. :)
>
> --
> TTFN,
> patrick
>
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
Twitter<https://twitter.com/anurag_bhatia>|
Google+ <https://plus.google.com/118280168625121532854>

From jra at baylink.com  Mon May 28 14:52:57 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 28 May 2012 15:52:57 -0400 (EDT)
Subject: isc - a good business
In-Reply-To: <4FC380FC.3020907@isc.org>
Message-ID: <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "paul vixie" <vixie at isc.org>

> On 5/28/2012 11:52 AM, Randy Bush wrote:
> > ... maybe a bit too much layer ten for my taste. ...
> 
> on that, we're trying to improve. for example, we used to forego
> features that some of us found repugnant, such as nxdomain remapping /
> ad insertion. since the result was that our software was less relevant
> but that there was no reduction in nxdomain remapping as a result of
> BIND not providing it.

To clarify that a bit...

You're saying you used to decline to include in BIND the capability to break
the Internet by returning things other than NXDOMAIN for names which do not
exist...

but now you're *ok* with breaking the internet, and BIND now does that?

If that's what you mean, I'll explain to you why that's a bad layer 10 call.

*Now*, you see, we no longer have a canonical Good Engineering Example to 
which we can point when yelling at people (and software vendors) which
*do* permit that, to say "see?  You shouldn't be doing that; it's bad."

"The Web Is Not The Internet."

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 fw at deneb.enyo.de  Mon May 28 14:56:34 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 28 May 2012 21:56:34 +0200
Subject: Vixie warns: DNS Changer =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?=
 inevitable
In-Reply-To: <20120523210027.GA26231@vacation.karoshi.com.>
 (bmanning@vacation.karoshi.com's message of "Wed, 23 May 2012 21:00:27
 +0000")
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
Message-ID: <87likculjh.fsf@mid.deneb.enyo.de>

[Dnschanger substitute server operations]

> One thing is clear, Paul is able to tell a great story.

PR for ISC is somewhat limited, it's often attributed to the FBI:

| The effort, scheduled to begin this afternoon, is designed to let
| those people know that their Internet connections will stop working
| on July 9, when temporary servers set up by the FBI to help
| DNSChanger victims are due to be disconnected.

<http://news.cnet.com/8301-1009_3-57439407-83/google-will-alert-users-to-dnschanger-malware-infection/>

| The FBI has now seized control of the malicious DNS servers, but
| countless computers are still infected with the malware.

<http://www.h-online.com/security/news/item/Google-warns-DNSChanger-victims-1583037.html>

| The malware is so vicious ? it can interfere with users' Web
| browsing, steer them to fraudulent websites and make their computers
| vulnerable to other malicious software ? that the FBI has put a
| safety net of sorts in place, using government computers to prevent
| any Internet disruptions for users whose computers may be infected.

<http://www.technolog.msnbc.msn.com/technology/technolog/infected-users-get-legit-warning-about-july-9-internet-doomsday-751078>

(I'm justing quoting what I found.  Some of the linked articles
contain bogus information.)

In any case, this isn't what bugs me about the whole process.  I don't
like the way this is implemented?mainly the use of RPZ, but there are
other concerns.  The notification process has some issues as well, but
it's certainly a great learning exercise for all folks involved with
this.  To me, it doesn't really matter that Dnschanger is fairly minor
as far as such things go.  Hopefully, the knowledge and the contacts
established can be applied to other cases as well.


From george.herbert at gmail.com  Mon May 28 15:08:56 2012
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 28 May 2012 13:08:56 -0700
Subject: isc - a good business
In-Reply-To: <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>
References: <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>
Message-ID: <8FD4955E-9A27-4A9C-BB1A-6CA46AB6D286@gmail.com>


It's past given that large entities that can forge the use of BIND; at that point, engineering aside, Paul's point that the market and code have spoken is hard to deny.

Sucks when it works against us...


George William Herbert
Sent from my iPhone

On May 28, 2012, at 12:52, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
>> From: "paul vixie" <vixie at isc.org>
> 
>> On 5/28/2012 11:52 AM, Randy Bush wrote:
>>> ... maybe a bit too much layer ten for my taste. ...
>> 
>> on that, we're trying to improve. for example, we used to forego
>> features that some of us found repugnant, such as nxdomain remapping /
>> ad insertion. since the result was that our software was less relevant
>> but that there was no reduction in nxdomain remapping as a result of
>> BIND not providing it.
> 
> To clarify that a bit...
> 
> You're saying you used to decline to include in BIND the capability to break
> the Internet by returning things other than NXDOMAIN for names which do not
> exist...
> 
> but now you're *ok* with breaking the internet, and BIND now does that?
> 
> If that's what you mean, I'll explain to you why that's a bad layer 10 call.
> 
> *Now*, you see, we no longer have a canonical Good Engineering Example to 
> which we can point when yelling at people (and software vendors) which
> *do* permit that, to say "see?  You shouldn't be doing that; it's bad."
> 
> "The Web Is Not The Internet."
> 
> 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 vixie at isc.org  Mon May 28 15:59:28 2012
From: vixie at isc.org (Paul Vixie)
Date: Mon, 28 May 2012 20:59:28 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> (Roland
 Dobbins's message of "Tue, 1 May 2012 11:36:23 +0000")
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
Message-ID: <g38vgc81jj.fsf@nsa.vix.com>

more "threads from the crypt" as i catch up to 6000 missed nanog posts.

"Dobbins, Roland" <rdobbins at arbor.net> writes:

> On Apr 28, 2012, at 5:17 PM, Saku Ytti wrote:
>
>> People might scared to rely on DNS on accepting routes, but is this
>> really an issue?
>
> Yes, recursive dependencies are an issue.  I'm really surprised that
> folks are even seriously considering something like this, but OTOH, this
> sort of thing keeps cropping up in various contexts from time to time,
> sigh.

so, first, i think you mean circular dependencies not recursive dependencies.

second, i'd agree that that's probably bad engineering.

third, rsync's dependencies on routing (as in the RPKI+ROA case) are not
circular (which i think was david conrad's point but i'll drag it to here.)

my reason for not taking ROVER seriously is that route filter preparation
is an essentially offline activity -- you do it from a cron job not "live".
and to do this you have to know in advance what policy data is available
which may or may not have the same coverage as "the routes you will receive
between one cron job and the next".

we could in other words use DNS to store route policy data if we wanted to
use a recursive zone transfer of all policy zones, as a replacement for
rsync. (but why would we do this? we have rsync, which worked for IRR data
for many years.)

ROVER expects that we will query for policy at the instant of need. that's
nuts for a lot of reasons, one of which is its potentially and unmanageably
circular dependency on the acceptance of a route you don't know how to
accept or reject yet.

my take-away from this thread is: very few people take RPKI seriously, but
even fewer take ROVER seriously.

-- 
Paul Vixie
KI6YSY


From randy at psg.com  Mon May 28 16:03:02 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 29 May 2012 06:03:02 +0900
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <CAJ0+aXaoTEUy+pog_g0cq2JE5SU82yX9+sOXmrHw6EeF9J77_A@mail.gmail.com>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <alpine.LSU.2.00.1205282018370.5807@hermes-2.csi.cam.ac.uk>
 <CAJ0+aXaoTEUy+pog_g0cq2JE5SU82yX9+sOXmrHw6EeF9J77_A@mail.gmail.com>
Message-ID: <m2obp8vx15.wl%randy@psg.com>

> I am building redundancy within that setup. I mean it will be software
> based BGP so if hardware if fried up, it will break BGP session and pull
> off routes anyway and for cases like DNS server (software) failure, I will
> monitor it via simple bash script which can turn bgp daemon down. So once
> it is off, routing tables should take it to different node.

i have a tee shirt which says

   All Devices Break
   Two Devices Will Break at Once
   Global BGP Never Converges

randy, a co-author of 2182


From maxlarson.henry at transversal.ht  Mon May 28 16:12:25 2012
From: maxlarson.henry at transversal.ht (maxlarson.henry at transversal.ht)
Date: Mon, 28 May 2012 21:12:25 +0000
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
Message-ID: <1175631976-1338239539-cardhu_decombobulator_blackberry.rim.net-229244179-@b17.c23.bise6.blackberry>

Q
------Message d'origine------
De?: Randy Bush
??: Anurag Bhatia
Cc?: NANOG Mailing List
Objet?: Re: DNS anycasting - multiple DNS servers on same subnet Vs registrar/registry policies
Envoy??: 28 mai, 2012 17:03

> I am building redundancy within that setup. I mean it will be software
> based BGP so if hardware if fried up, it will break BGP session and pull
> off routes anyway and for cases like DNS server (software) failure, I will
> monitor it via simple bash script which can turn bgp daemon down. So once
> it is off, routing tables should take it to different node.

i have a tee shirt which says

   All Devices Break
   Two Devices Will Break at Once
   Global BGP Never Converges

randy, a co-author of 2182



Envoy? par mon BlackBerry de Digicel

From vixie at isc.org  Mon May 28 16:14:19 2012
From: vixie at isc.org (Paul Vixie)
Date: Mon, 28 May 2012 21:14:19 +0000
Subject: isc - a good business
In-Reply-To: <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>
 (Jay Ashworth's message of "Mon, 28 May 2012 15:52:57 -0400 (EDT)")
References: <4FC380FC.3020907@isc.org>
 <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>
Message-ID: <g34nr080us.fsf@nsa.vix.com>

(all caught up after this.)

Jay Ashworth <jra at baylink.com> writes:

> ----- Original Message -----
>> From: "paul vixie" <vixie at isc.org>
>
>> On 5/28/2012 11:52 AM, Randy Bush wrote:
>> > ... maybe a bit too much layer ten for my taste. ...
>> 
>> on that, we're trying to improve. for example, we used to forego
>> features that some of us found repugnant, such as nxdomain remapping /
>> ad insertion. since the result was that our software was less relevant
>> but that there was no reduction in nxdomain remapping as a result of
>> BIND not providing it.
>
> To clarify that a bit...

let's keep trying.

> You're saying you used to decline to include in BIND the capability to
> break the Internet by returning things other than NXDOMAIN for names
> which do not exist...

no, that's not what i'm saying.

> but now you're *ok* with breaking the internet, and BIND now does that?

no, that's also not what i'm saying.

> If that's what you mean, I'll explain to you why that's a bad layer 10 call.

it's not, but i'm listening.

> *Now*, you see, we no longer have a canonical Good Engineering Example to 
> which we can point when yelling at people (and software vendors) which
> *do* permit that, to say "see?  You shouldn't be doing that; it's bad."
>
> "The Web Is Not The Internet."

i see what you mean, and i'm sad that this arrow is no longer in your
quiver. perhaps you can still refer to nlnetlabs unbound for this purpose.

if i thought there was even one isp anywhere who wanted to use nxdomain
remapping but didn't because bind didn't have that feature, i'd be ready to
argue the point. but all isc did by not supporting this feature was force
some isp's to not use bind, and: isc is not in the "sour grapes" business.

meanwhile isc continues to push for ubiquitous dnssec, through to the stub,
to take this issue off the table for all people and all time. (that's "the
real fix" for nxdomain remapping.)

-- 
Paul Vixie
KI6YSY


From randy at psg.com  Mon May 28 16:17:09 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 29 May 2012 06:17:09 +0900
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <1175631976-1338239539-cardhu_decombobulator_blackberry.rim.net-229244179-@b17.c23.bise6.blackberry>
References: <1175631976-1338239539-cardhu_decombobulator_blackberry.rim.net-229244179-@b17.c23.bise6.blackberry>
Message-ID: <m2likcvwdm.wl%randy@psg.com>

maxlarson.henry at transversal.ht wrote:
> Q
> ------Message d'origine------
> De?: Randy Bush
> ??: Anurag Bhatia
> Cc?: NANOG Mailing List
> Objet?: Re: DNS anycasting - multiple DNS servers on same subnet Vs registrar/registry policies
> Envoy??: 28 mai, 2012 17:03
> ...
> Envoy? par mon BlackBerry de Digicel

QED, eh?


From sethm at rollernet.us  Mon May 28 16:19:41 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 28 May 2012 14:19:41 -0700
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: <1327824649.20120528163134@ip.datagroup.ua>
References: <1327824649.20120528163134@ip.datagroup.ua>
Message-ID: <4FC3EBED.1060101@rollernet.us>

On 5/28/12 6:31 AM, Evgeniy Aikashev wrote:
> Dear all,
> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our customers have no access to some part of Internet if they use these IPs.
> Could you please update your bogon filters to permit this range.
> 


Do you have a test IP address that can be pinged or traceroute to?

~Seth


From maxlarson.henry at transversal.ht  Mon May 28 16:38:30 2012
From: maxlarson.henry at transversal.ht (Max Larson Henry)
Date: Mon, 28 May 2012 16:38:30 -0500
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <m2likcvwdm.wl%randy@psg.com>
References: <1175631976-1338239539-cardhu_decombobulator_blackberry.rim.net-229244179-@b17.c23.bise6.blackberry>
 <m2likcvwdm.wl%randy@psg.com>
Message-ID: <CAPQqn-kB+Gtx5QF-3KiKTafeB0jLYmz_v+28wQ=3DgceBrhS4A@mail.gmail.com>

off topic.
I have to do a better job to prevent my 5 year old daughter from
touching my phone :)

-M

On Mon, May 28, 2012 at 4:17 PM, Randy Bush <randy at psg.com> wrote:
> maxlarson.henry at transversal.ht wrote:
>> Q
>> ------Message d'origine------
>> De?: Randy Bush
>> ??: Anurag Bhatia
>> Cc?: NANOG Mailing List
>> Objet?: Re: DNS anycasting - multiple DNS servers on same subnet Vs registrar/registry policies
>> Envoy??: 28 mai, 2012 17:03
>> ...
>> Envoy? par mon BlackBerry de Digicel
>
> QED, eh?


From drc at virtualized.org  Mon May 28 16:42:40 2012
From: drc at virtualized.org (David Conrad)
Date: Mon, 28 May 2012 14:42:40 -0700
Subject: rpki vs. secure dns?
In-Reply-To: <g38vgc81jj.fsf@nsa.vix.com>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
Message-ID: <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>

On May 28, 2012, at 1:59 PM, Paul Vixie wrote:
> third, rsync's dependencies on routing (as in the RPKI+ROA case) are not
> circular (which i think was david conrad's point but i'll drag it to here.)

Nope.  My point was that anything that uses the Internet to fetch the data (including rsync) has a circular dependency on routing. It's just a question of timing.

> ROVER expects that we will query for policy at the instant of need.

Might want to review https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf, particularly the slide entitled "Avoid a Cyclic Dependency".

As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives.  

Regards,
-drc



From mpalmer at hezmatt.org  Mon May 28 16:45:35 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Tue, 29 May 2012 07:45:35 +1000
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: <1327824649.20120528163134@ip.datagroup.ua>
References: <1327824649.20120528163134@ip.datagroup.ua>
Message-ID: <20120528214535.GS18702@hezmatt.org>

On Mon, May 28, 2012 at 04:31:34PM +0300, Evgeniy Aikashev wrote:
> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our
> customers have no access to some part of Internet if they use these IPs.
> Could you please update your bogon filters to permit this range.

You're probably going to go and have a stern word with the Hamachi people,
too -- they've been squatting on that space for a while now.

- Matt



From drc at virtualized.org  Mon May 28 16:58:03 2012
From: drc at virtualized.org (David Conrad)
Date: Mon, 28 May 2012 14:58:03 -0700
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: <20120528214535.GS18702@hezmatt.org>
References: <1327824649.20120528163134@ip.datagroup.ua>
 <20120528214535.GS18702@hezmatt.org>
Message-ID: <B8B4FD22-A756-4695-9853-47DCB60B8F80@virtualized.org>

On May 28, 2012, at 2:45 PM, Matthew Palmer wrote:
> On Mon, May 28, 2012 at 04:31:34PM +0300, Evgeniy Aikashev wrote:
>> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our
>> customers have no access to some part of Internet if they use these IPs.
>> Could you please update your bogon filters to permit this range.
> 
> You're probably going to go and have a stern word with the Hamachi people,
> too -- they've been squatting on that space for a while now.

Are they still doing that?  Back when I was at IANA, I mentioned that their usage of 5/8 was a really bad idea that was going to bite them.  IIRC they indicated they were going to migrate to a different approach...

Regards,
-drc



From vixie at isc.org  Mon May 28 17:01:59 2012
From: vixie at isc.org (paul vixie)
Date: Mon, 28 May 2012 22:01:59 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
Message-ID: <4FC3F5D7.5000206@isc.org>

On 5/28/2012 9:42 PM, David Conrad wrote:
> On May 28, 2012, at 1:59 PM, Paul Vixie wrote:
>> third, rsync's dependencies on routing (as in the RPKI+ROA case) are not
>> circular (which i think was david conrad's point but i'll drag it to here.)
> Nope.  My point was that anything that uses the Internet to fetch the data (including rsync) has a circular dependency on routing. It's just a question of timing.

when you say it's a question of timing, i agree, but then i think you
won't agree again. in batch mode i can express a policy that's true from
that moment forward until removed. in real time mode i have to be able
to express a policy which is both valid and reachable at the moment of
validation. that's a question of timing but the word "just" as in "just
a question of timing" trivializes a galaxy-sized problem space.

>
>> ROVER expects that we will query for policy at the instant of need.
> Might want to review https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf, particularly the slide entitled "Avoid a Cyclic Dependency".

i read it. this is also what draft-gersch-grow-revdns-bpg says. this
makes for a "fail open" design -- the only thing the system can reliably
tell you is "reject". this precludes islands of, or a mode of, "fail
closed". while i don't consider a mode of "fail closed" to be
practically likely, i'd like to preserve the fig leaf of theoretical
possibility. (and the more likely possibility that islands of "fail
closed" could be sewn in.)

> As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives. 

i can tell more than that. rover is a system that only works at all when
everything everywhere is working well, and when changes always come in
perfect time-order, where that order is nowhere defined, and is in any
event uncontrollable.

rsync's punt of the ordering problem is batch mode with policy start
times rather than policy valid instants. to my mind anyone who doesn't
punt the ordering problem has to instead solve it. rover does neither.

paul


From paul4004 at gmail.com  Mon May 28 17:08:28 2012
From: paul4004 at gmail.com (PC)
Date: Mon, 28 May 2012 17:08:28 -0500
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <SNT129-W173056B934D9CB9B57B6C7A3040@phx.gbl>
References: <SNT129-W173056B934D9CB9B57B6C7A3040@phx.gbl>
Message-ID: <CAJAdsD=FX3urOSb4Dqg05Ca6=a278AO8nErnhH5H5O6+o3XmBA@mail.gmail.com>

While I still don't agree it's fair, that arrangement seems limited to
the viewing of the Xfinity TV application via XBOX for subscribers who
have both an internet and cable TV package via Comcast and not XBOX in
general.  None the less, the cap is 250gb at the moment, and only
applies to residential accounts.


On Sun, May 27, 2012 at 9:27 PM, Nabil Sharma <nabilsharma at hotmail.com> wrote:
>
> NANOG List,
> I am developing streaming video service, and seek your feedback... I would like to pay Comcast forward so that accessing our site does not count against user's bandwidth caps, similar to the arrangement made with Microsoft Xbox.
> Does anyone know the name of this service? Is it something the sales contact at http://as7922.peeringdb.com/ can provide?
> Thank you for your time.
> Sincerely,
> Nabil
>


From ryan at u13.net  Mon May 28 17:19:55 2012
From: ryan at u13.net (ryan at u13.net)
Date: Mon, 28 May 2012 18:19:55 -0400
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <SNT129-W173056B934D9CB9B57B6C7A3040@phx.gbl>
References: <SNT129-W173056B934D9CB9B57B6C7A3040@phx.gbl>
Message-ID: <3e09162446567502ad34e58c1d9c6c2f@u13.net>

On 27.05.2012 22:27, Nabil Sharma wrote:

> NANOG List,
> I am developing streaming video service, and seek your feedback... I
> would like to pay Comcast forward so that accessing our site does not
> count against user's bandwidth caps, similar to the arrangement made 
> with
> Microsoft Xbox.


http://news.cnet.com/8301-1023_3-57436489-93/comcast-ditches-250gb-data-cap-tests-tiered-pricing/

The cap is [recently] suspended for most subscribers and if it comes 
back it looks like it may be under a different policy going forward


From jra at baylink.com  Mon May 28 18:16:47 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 28 May 2012 19:16:47 -0400 (EDT)
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <g34nr080us.fsf@nsa.vix.com>
Message-ID: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Paul Vixie" <vixie at isc.org>

> > *Now*, you see, we no longer have a canonical Good Engineering
> > Example to
> > which we can point when yelling at people (and software vendors)
> > which
> > *do* permit that, to say "see? You shouldn't be doing that; it's
> > bad."
> >
> > "The Web Is Not The Internet."
> 
> i see what you mean, and i'm sad that this arrow is no longer in your
> quiver. perhaps you can still refer to nlnetlabs unbound for this
> purpose.
> 
> if i thought there was even one isp anywhere who wanted to use nxdomain
> remapping but didn't because bind didn't have that feature, i'd be ready to
> argue the point. but all isc did by not supporting this feature was force
> some isp's to not use bind, and: isc is not in the "sour grapes"
> business.

Well, I disagree on that, but I am not widely travelled, and perhaps
the obvious argument I see wasn't ever actually used.

This is the "do I put cigarette burn preventers on the toilet paper 
dispensers in my 'no smoking' restroom" problem, pretty much exactly.

> meanwhile isc continues to push for ubiquitous dnssec, through to the stub,
> to take this issue off the table for all people and all time. (that's "the
> real fix" for nxdomain remapping.)

You really believe that the outcome of that will be "we can't make some
extra revenue off NXDOMAIN remapping because of DNSSEC?  Well, the hell
with DNSSEC, then"?

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 nabilsharma at hotmail.com  Mon May 28 18:27:32 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Mon, 28 May 2012 23:27:32 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <CAJAdsD=FX3urOSb4Dqg05Ca6=a278AO8nErnhH5H5O6+o3XmBA@mail.gmail.com>
References: <SNT129-W173056B934D9CB9B57B6C7A3040@phx.gbl>,
 <CAJAdsD=FX3urOSb4Dqg05Ca6=a278AO8nErnhH5H5O6+o3XmBA@mail.gmail.com>
Message-ID: <SNT129-W603297122BAE6387ED6D16A3040@phx.gbl>

PC:

Thank you for the reply.  We will not encourage customers to disconnect cable TV service, think of it more like an add-on.

I generate http test stream with DSCP code point 5 to match the Xbox service, however Comcast is rewriting the packets as CS 1, even when serving out a server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft is using, it is not the regular paid peering.

Sincerely,
Nabil

> Date: Mon, 28 May 2012 17:08:28 -0500
> Subject: Re: Comcast Service for Non-Cap Bandwidth
> From: paul4004 at gmail.com
> To: nabilsharma at hotmail.com
> CC: nanog at nanog.org
> 
> While I still don't agree it's fair, that arrangement seems limited to
> the viewing of the Xfinity TV application via XBOX for subscribers who
> have both an internet and cable TV package via Comcast and not XBOX in
> general.  None the less, the cap is 250gb at the moment, and only
> applies to residential accounts.
> 
> 
> On Sun, May 27, 2012 at 9:27 PM, Nabil Sharma <nabilsharma at hotmail.com> wrote:
> >
> > NANOG List,
> > I am developing streaming video service, and seek your feedback... I would like to pay Comcast forward so that accessing our site does not count against user's bandwidth caps, similar to the arrangement made with Microsoft Xbox.
> > Does anyone know the name of this service? Is it something the sales contact at http://as7922.peeringdb.com/ can provide?
> > Thank you for your time.
> > Sincerely,
> > Nabil
> >
 		 	   		  

From rbf+nanog at panix.com  Mon May 28 18:56:29 2012
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Mon, 28 May 2012 18:56:29 -0500
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <20120528193229.GA24594@sources.org>
References: <25604_1338233229_4FC3D18D_25604_1794_1_CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <20120528193229.GA24594@sources.org>
Message-ID: <20120528235629.GA23276@panix.com>

On Mon, May 28, 2012 at 09:32:29PM +0200, Stephane Bortzmeyer wrote:
> On Tue, May 29, 2012 at 12:21:10AM +0530,
>  Anurag Bhatia <me at anuragbhatia.com> wrote 
>  a message of 28 lines which said:
> 
> > I know few registry/registrars which do not accept both (or all)
> > name servers of domain name on same subnet.
> 
> Since my employer is one of these registries, let me mention that I
> fully agree with David Conrad here.

How does your employer know if two nameservers (two IP addresses) are
on the same subnet?

     -- Brett


From mysidia at gmail.com  Mon May 28 19:05:26 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 28 May 2012 19:05:26 -0500
Subject: isc - a good business
In-Reply-To: <g34nr080us.fsf@nsa.vix.com>
References: <4FC380FC.3020907@isc.org>
 <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>
 <g34nr080us.fsf@nsa.vix.com>
Message-ID: <CAAAwwbWT8qSzaKW=BuPAuKpe+xXhJvcjEwOaYhEiNnrBd-domg@mail.gmail.com>

On 5/28/12, Paul Vixie <vixie at isc.org> wrote:
[snip]
> if i thought there was even one isp anywhere who wanted to use nxdomain
> remapping but didn't because bind didn't have that feature, i'd be ready to
> argue the point. but all isc did by not supporting this feature was force

Maybe they would think twice, if they used BIND,  and BIND not only
excluded the feature,
or if activating the feature required loading an "Unsupported"
plugin, external module,  patch, that would periodically generate
syslog warnings about dangerous NXDOMAIN mapping settings, but
documentation also contained a FAQ explaining why the feature "global
wildcards" or "nxdomain remapping" are not officially supported, and
explained some of the serious problems the concept of NXDOMAIN
remapping causes..

There is no point in "denying a feature" that is in demand,  because
that simply means there will then be demand to fork the product, and
provide the users the features they want, that the developer is
denying them for "political reasons".

Also, the cats out of the bag once the feature is provided --
introducing a breaking change that would completely remove an
in-demand existing feature from the userbase would be ill-advised.


> some isp's to not use bind, and: isc is not in the "sour grapes" business.

Other implementations mimic BIND;  the BIND implementation is kind of a leader.
By including the feature,  other implementations are influenced to
include the feature.
It would be best for the BIND developers'  position on the usage of
the feature to be clear.

"Don't turn this on just because it's there... here's why..  oh, by
the way, you need to do this, this, and this other thing, before you
can turn it on"

> meanwhile isc continues to push for ubiquitous dnssec, through to the stub,
> to take this issue off the table for all people and all time. (that's "the
> real fix" for nxdomain remapping.)

It's a good fix,  but the code bits to implement it on major OSes
don't exist today,
and if they are fully implemented by all vendors,  it's still
approximately  3 years before
they make it into a new OS'  release cycle, and then another 10 years before
the functionality gets deployed and enabled by default,  and older
systems get retired.

Discouraging the breakage is a good interim fix,  when ubiqutous
DNSSEC to the stub
is optimistically 15 years out.

> --
> Paul Vixie
--
-JH


From marka at isc.org  Mon May 28 19:14:51 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 29 May 2012 10:14:51 +1000
Subject: isc - a good business
In-Reply-To: Your message of "Mon, 28 May 2012 19:05:26 EST."
 <CAAAwwbWT8qSzaKW=BuPAuKpe+xXhJvcjEwOaYhEiNnrBd-domg@mail.gmail.com>
References: <4FC380FC.3020907@isc.org>
 <26627378.6326.1338234777043.JavaMail.root@benjamin.baylink.com>
 <g34nr080us.fsf@nsa.vix.com>
 <CAAAwwbWT8qSzaKW=BuPAuKpe+xXhJvcjEwOaYhEiNnrBd-domg@mail.gmail.com>
Message-ID: <20120529001451.B5B9D20FCD4A@drugs.dv.isc.org>


The code is DNSSEC aware, it doesn't perform redirection if the
client can detect that redirection has occured.  So sign your zones
and use a validating client (or just one that sets DO=1).

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


From mmk at one.com  Mon May 28 19:32:26 2012
From: mmk at one.com (Mikkel Mondrup Kristensen)
Date: Tue, 29 May 2012 02:32:26 +0200
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <20120528235629.GA23276@panix.com>
References: <25604_1338233229_4FC3D18D_25604_1794_1_CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <20120528193229.GA24594@sources.org> <20120528235629.GA23276@panix.com>
Message-ID: <5EBC0868-05D2-435E-A671-E957AF72F506@one.com>


On May 29, 2012, at 01:56 , Brett Frankenberger wrote:

> On Mon, May 28, 2012 at 09:32:29PM +0200, Stephane Bortzmeyer wrote:
>> On Tue, May 29, 2012 at 12:21:10AM +0530,
>> Anurag Bhatia <me at anuragbhatia.com> wrote 
>> a message of 28 lines which said:
>> 
>>> I know few registry/registrars which do not accept both (or all)
>>> name servers of domain name on same subnet.
>> 
>> Since my employer is one of these registries, let me mention that I
>> fully agree with David Conrad here.
> 
> How does your employer know if two nameservers (two IP addresses) are
> on the same subnet?
> 
Registrars are still rocking classful routing like its 1993.

--
Mikkel


From marka at isc.org  Mon May 28 19:54:12 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 29 May 2012 10:54:12 +1000
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: Your message of "Mon, 28 May 2012 19:16:47 -0400."
 <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
References: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120529005412.6354420FD3FB@drugs.dv.isc.org>


In message <1564718.6360.1338247007903.JavaMail.root at benjamin.baylink.com>, Jay
 Ashworth writes:
> ----- Original Message -----
> > From: "Paul Vixie" <vixie at isc.org>
> 
> > > *Now*, you see, we no longer have a canonical Good Engineering
> > > Example to
> > > which we can point when yelling at people (and software vendors)
> > > which
> > > *do* permit that, to say "see? You shouldn't be doing that; it's
> > > bad."
> > >
> > > "The Web Is Not The Internet."
> > 
> > i see what you mean, and i'm sad that this arrow is no longer in your
> > quiver. perhaps you can still refer to nlnetlabs unbound for this
> > purpose.
> > 
> > if i thought there was even one isp anywhere who wanted to use nxdomain
> > remapping but didn't because bind didn't have that feature, i'd be ready to
> > argue the point. but all isc did by not supporting this feature was force
> > some isp's to not use bind, and: isc is not in the "sour grapes"
> > business.
> 
> Well, I disagree on that, but I am not widely travelled, and perhaps
> the obvious argument I see wasn't ever actually used.
> 
> This is the "do I put cigarette burn preventers on the toilet paper 
> dispensers in my 'no smoking' restroom" problem, pretty much exactly.
> 
> > meanwhile isc continues to push for ubiquitous dnssec, through to the stub,
> > to take this issue off the table for all people and all time. (that's "the
> > real fix" for nxdomain remapping.)
> 
> You really believe that the outcome of that will be "we can't make some
> extra revenue off NXDOMAIN remapping because of DNSSEC?  Well, the hell
> with DNSSEC, then"?

People will route around ISP that do stupid things.  They do so
today.  When your browers supports DANE there will be more incentive
to ensure that DNSSEC does not break and more incentive to route
around ISP's that do break DNSSEC.

Even a ISP that is redirecting on NXDOMAIN wants to be sure that
it is a real NXDOMAIN not one that is spoofed do the path to the
ISP's resolver will be DNSSEC clean and they will be validating.

Until stub resolvers set DO=1 pretty much ubiquitously this won't
be a problem for ISP's that want to do nxdomain redirection.  There
still plenty of crappy DNS proxies in CPE routers to be replaced
before you can just set DO=1 as a default without worrying about
breaking DNS lookups.  Even setting EDNS as a default is a issue.

That said we are starting down the long path to making it EDNS a
default.  DiG in BIND 9 defaults to using EDNS and "dig +trace"
turns set DO=1 as well.  You don't get things fixed if the breakage
is not visible.

Mark

> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.co
> m
> Designer                     The Things I Think                       RFC 210
> 0
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DI
> I
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 127
> 4
> 
-- 
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 28 20:08:36 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 29 May 2012 11:08:36 +1000
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: Your message of "Tue, 29 May 2012 02:32:26 +0200."
 <5EBC0868-05D2-435E-A671-E957AF72F506@one.com>
References: <25604_1338233229_4FC3D18D_25604_1794_1_CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <20120528193229.GA24594@sources.org> <20120528235629.GA23276@panix.com>
 <5EBC0868-05D2-435E-A671-E957AF72F506@one.com>
Message-ID: <20120529010836.C5B6E20FD594@drugs.dv.isc.org>


In message <5EBC0868-05D2-435E-A671-E957AF72F506 at one.com>, Mikkel Mondrup Krist
ensen writes:
> 
> On May 29, 2012, at 01:56 , Brett Frankenberger wrote:
> 
> > On Mon, May 28, 2012 at 09:32:29PM +0200, Stephane Bortzmeyer wrote:
> >> On Tue, May 29, 2012 at 12:21:10AM +0530,
> >> Anurag Bhatia <me at anuragbhatia.com> wrote 
> >> a message of 28 lines which said:
> >> 
> >>> I know few registry/registrars which do not accept both (or all)
> >>> name servers of domain name on same subnet.
> >> 
> >> Since my employer is one of these registries, let me mention that I
> >> fully agree with David Conrad here.
> > 
> > How does your employer know if two nameservers (two IP addresses) are
> > on the same subnet?
> > 
> Registrars are still rocking classful routing like its 1993.

As long as they are covered by the same BGP anouncement they are
NOT redundant.  It shouldn't be that hard for registrars to take a
full bgp feed and use it to validate.  If it's in the same /24 for
IPv4 it may as well be in the same subnet even if you have smaller
subnets internally.  The world only listens to the one announcement.

For those of you who thing that if your net is down you don't need
to be able to respond to DNS requests, the DNS is not designed to
handle non reachable zones.  It's designed to handle some of the
nameservers for a zone being unreachable.

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


From jra at baylink.com  Mon May 28 20:52:25 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 28 May 2012 21:52:25 -0400 (EDT)
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <20120529005412.6354420FD3FB@drugs.dv.isc.org>
Message-ID: <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Mark Andrews" <marka at isc.org>

[ vix: ]
> > > meanwhile isc continues to push for ubiquitous dnssec, through to
> > > the stub,
> > > to take this issue off the table for all people and all time.
> > > (that's "the
> > > real fix" for nxdomain remapping.)
> >
> > You really believe that the outcome of that will be "we can't make
> > some
> > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the
> > hell
> > with DNSSEC, then"?
> 
> People will route around ISP that do stupid things. They do so
> today. When your browers supports DANE there will be more incentive
> to ensure that DNSSEC does not break and more incentive to route
> around ISP's that do break DNSSEC.

My personal reaction to that, Mark, is to say that you *badly* overestimate
the average Internet end-user (who make up, roughly, 80% of the endpoints,
in my jackleg estimation).

> Even a ISP that is redirecting on NXDOMAIN wants to be sure that
> it is a real NXDOMAIN not one that is spoofed do the path to the
> ISP's resolver will be DNSSEC clean and they will be validating.

I'm not sure I understood that...

> Until stub resolvers set DO=1 pretty much ubiquitously this won't
> be a problem for ISP's that want to do nxdomain redirection. There
> still plenty of crappy DNS proxies in CPE routers to be replaced
> before you can just set DO=1 as a default without worrying about
> breaking DNS lookups. Even setting EDNS as a default is a issue.

...but that's probably because I don't understand DNSSEC well enough.

> That said we are starting down the long path to making it EDNS a
> default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
> turns set DO=1 as well. You don't get things fixed if the breakage
> is not visible.

We may be talking about different breakage here...

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 randy at psg.com  Mon May 28 21:06:31 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 29 May 2012 11:06:31 +0900
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <20120529005412.6354420FD3FB@drugs.dv.isc.org>
References: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
 <20120529005412.6354420FD3FB@drugs.dv.isc.org>
Message-ID: <m2likbspug.wl%randy@psg.com>

> Jay Ashworth writes:
please do not feed the troll

> When your browers supports DANE

and a billion home nats support dnssec :(

randy


From mysidia at gmail.com  Mon May 28 21:20:04 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 28 May 2012 21:20:04 -0500
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <20120529005412.6354420FD3FB@drugs.dv.isc.org>
References: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
 <20120529005412.6354420FD3FB@drugs.dv.isc.org>
Message-ID: <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg@mail.gmail.com>

On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> Until stub resolvers set DO=1 pretty much ubiquitously this won't
> be a problem for ISP's that want to do nxdomain redirection.  There

Yeah.............
Right now current _server_  implementations don't even have it right,
for properly implementing DNSSEC validation down to that level, let
alone the stubs below the server.

Many SME LANs utilize Windows-based endpoints, and commonly have
Windows-based DNS servers on the LAN, used by endpoints, where the
Windows DNS servers are set to forward queries to ISP recursive
servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
 When Windows DNS server is configured to forward DNS queries to a
list of reasonable  recursive DNS servers,  the server sets  CD (Check
disabled) bit set, and the DO bit set  for all queries it sends;
there is no option to "support dnssec queries from smart stubs but
don't send queries from dumb stubs with CD".

Also, there are by default no trust anchors, and _Every_ response is
treated as valid.  (In other words, CD bit and DO bits are set in
forwarded queries, but no validation occurs).
It's kind of like having a SSL implementation that treats ALL SSL
certificates as valid, until and unless you take manual steps to
configure a CA list.

If you don't like this default and want to configure Windows DNS with
the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
supported key type, and the current root signing key is not of a
compatible format.

Your "smart" stub can send a query to this broken DNSSEC
implementation with the DO bit set, for sure.




> still plenty of crappy DNS proxies in CPE routers to be replaced
> before you can just set DO=1 as a default without worrying about
> breaking DNS lookups.  Even setting EDNS as a default is a issue.
[snip]

I'm all for smart stubs   as long as  (1) They can get the data to them
(2) They can get the proper logging/reporting to them,  E.g.   No
"silent" upstream validate/discard;      No  upstream  silent "ignore
the stub's requested CD bit and validate/discard anyways"
and

(3) The validation path is intact for _dumb_ non-validating stubs too.

--
-JH


From fernando at gont.com.ar  Mon May 28 20:17:33 2012
From: fernando at gont.com.ar (Fernando Gont)
Date: Mon, 28 May 2012 22:17:33 -0300
Subject: IPv6 security: New IETF I-Ds,
 slideware and videos of recent presentations, trainings, etc...
Message-ID: <4FC423AD.5000703@gont.com.ar>

Folks,

* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
protection against rogue DHCPv6 servers. The I-D is available at:
<http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
Other IPv6 security I-Ds (such as,
draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
check them out at:
<http://www.si6networks.com/publications/ietf.html>

* The slideware (and some videos!) of some of our recent presentations
about IPv6 security are now available online. You can find them at:
<http://www.si6networks.com/presentations/index.html>

* We have also scheduled IPv6 hacking trainings in Paris (France) and
Ghent (Belgium). You can find more details at:
<http://www.si6networks.com/index.html#conferences>

Our Twitter: @SI6Networks
ipv6hackers mailing-list:
<http://lists.si6networks.com/listinfo/ipv6hackers/>

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From marka at isc.org  Mon May 28 21:38:23 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 29 May 2012 12:38:23 +1000
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: Your message of "Mon, 28 May 2012 21:52:25 -0400."
 <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>
References: <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120529023823.C2B5220FE5A8@drugs.dv.isc.org>


In message <23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay Ashworth writ
es:
> ----- Original Message -----
> > From: "Mark Andrews" <marka at isc.org>
> 
> [ vix: ]
> > > > meanwhile isc continues to push for ubiquitous dnssec, through to
> > > > the stub,
> > > > to take this issue off the table for all people and all time.
> > > > (that's "the
> > > > real fix" for nxdomain remapping.)
> > >
> > > You really believe that the outcome of that will be "we can't make
> > > some
> > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the
> > > hell
> > > with DNSSEC, then"?
> > 
> > People will route around ISP that do stupid things. They do so
> > today. When your browers supports DANE there will be more incentive
> > to ensure that DNSSEC does not break and more incentive to route
> > around ISP's that do break DNSSEC.
> 
> My personal reaction to that, Mark, is to say that you *badly* overestimate
> the average Internet end-user (who make up, roughly, 80% of the endpoints,
> in my jackleg estimation).

Google's recursive nameservers see plenty of traffic.
 
> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that
> > it is a real NXDOMAIN not one that is spoofed do the path to the
> > ISP's resolver will be DNSSEC clean and they will be validating.
> 
> I'm not sure I understood that...

        Authoritative server
                ^
	     secure
         (DO=1 queries)
		v
  ISP's validating recursive server
                ^
     insecure, redirect possible
         (DO=0 queries)
                v
           Stub clients.

Putting it another way, the ISP doesn't want to be fooled even if
it is fooling its customers.  The ISP can't allow it's recursive
servers to get the wrong answers for irs.gov, picking a signed
domain, as they would look silly for not validating when there is
a simple way for them to be sure that they are not being spoofed.

> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> > be a problem for ISP's that want to do nxdomain redirection. There
> > still plenty of crappy DNS proxies in CPE routers to be replaced
> > before you can just set DO=1 as a default without worrying about
> > breaking DNS lookups. Even setting EDNS as a default is a issue.
> 
> ...but that's probably because I don't understand DNSSEC well enough.

The ISP <-> stub client path often has a additional piece in the
path that is often a heap of steaming !@$! that doesn't do basic
DNS let alone EDNS and DNSSEC.  For example the Netgear router at
home doesn't support DNS over TCP which is basic DNS (I'm using it
as a access point not a router because of this).   It's this sort
of breakage that is stopping OS vendors changing defaults.  This
can often be bypassed by forcing the resolver to use the ISP's
nameservers directly but you need to know to do that.

     ISP's validating recursive server
                ^
                v
            CPE Router (broken DNS proxy code)
                ^
                v
           Stub clients.

You can also replace CPE Router with a broken firewall that is a
steaming heap of !@#% when it comes to DNS packet inspection.  These
are harder to bypass and require someone to fix the configuration
to replace/upgrade the box.

> > That said we are starting down the long path to making it EDNS a
> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
> > turns set DO=1 as well. You don't get things fixed if the breakage
> > is not visible.
> 
> We may be talking about different breakage here...
> 
> 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
> 
-- 
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 28 21:47:10 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 29 May 2012 12:47:10 +1000
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: Your message of "Mon, 28 May 2012 21:20:04 EST."
 <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg@mail.gmail.com>
References: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
 <20120529005412.6354420FD3FB@drugs.dv.isc.org>
 <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg@mail.gmail.com>
Message-ID: <20120529024710.8971D20FE6A0@drugs.dv.isc.org>


In message <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
, Jimmy Hess writes:
> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> > be a problem for ISP's that want to do nxdomain redirection.  There
> 
> Yeah.............
> Right now current _server_  implementations don't even have it right,
> for properly implementing DNSSEC validation down to that level, let
> alone the stubs below the server.
> 
> Many SME LANs utilize Windows-based endpoints, and commonly have
> Windows-based DNS servers on the LAN, used by endpoints, where the
> Windows DNS servers are set to forward queries to ISP recursive
> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
>  When Windows DNS server is configured to forward DNS queries to a
> list of reasonable  recursive DNS servers,  the server sets  CD (Check
> disabled) bit set, and the DO bit set  for all queries it sends;
> there is no option to "support dnssec queries from smart stubs but
> don't send queries from dumb stubs with CD".

Well I'm trying to get this fixed at the protocol level for other
reasons as explained in
http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html

draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
call and if you think always setting CD=1 when forwarding is bad for
whatever reason I could do with some support.
 
> Also, there are by default no trust anchors, and _Every_ response is
> treated as valid.  (In other words, CD bit and DO bits are set in
> forwarded queries, but no validation occurs).
> It's kind of like having a SSL implementation that treats ALL SSL
> certificates as valid, until and unless you take manual steps to
> configure a CA list.
> 
> If you don't like this default and want to configure Windows DNS with
> the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
> supported key type, and the current root signing key is not of a
> compatible format.
> 
> Your "smart" stub can send a query to this broken DNSSEC
> implementation with the DO bit set, for sure.
> 
> 
> 
> 
> > still plenty of crappy DNS proxies in CPE routers to be replaced
> > before you can just set DO=1 as a default without worrying about
> > breaking DNS lookups.  Even setting EDNS as a default is a issue.
> [snip]
> 
> I'm all for smart stubs   as long as  (1) They can get the data to them
> (2) They can get the proper logging/reporting to them,  E.g.   No
> "silent" upstream validate/discard;      No  upstream  silent "ignore
> the stub's requested CD bit and validate/discard anyways"
> and
> 
> (3) The validation path is intact for _dumb_ non-validating stubs too.
> 
> --
> -JH
-- 
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 28 23:58:00 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 28 May 2012 23:58:00 -0500
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <F95A06F9-39E8-4830-8D55-C5983EA9B5F4@virtualized.org>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <F95A06F9-39E8-4830-8D55-C5983EA9B5F4@virtualized.org>
Message-ID: <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ@mail.gmail.com>

On 5/28/12, David Conrad <drc at virtualized.org> wrote:
> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
>> I know few registry/registrars
>> which do not accept both (or all) name servers of domain name on same
>> subnet. They demand at least 1 DNS server should be on different subnet for
>> failover reasons (old thoughts).
> IMHO appropriately so.  The fact that anycast allows for multiple
> (potentially) geographically distributed machines to respond to DNS queries
> does not remove the value of having multiple prefixes for DNS servers.
[snip]
It dramatically reduces the value, and meets the basic RFC requirement
for geographically distributed DNS servers, although there are still
routing issues that will impact all DNS servers to share a prefix
It is more important that a domain registrar not refuse to register a
domain,  or erroneously declare a valid listing invalid.

The purpose of using a registrar is to establish DNS delegation, not
to validate your site's redundancy meets the absolute best possible
practices for fault tolerance.

Ideally certainly should have DNS servers under multiple prefixes --
and it seems a little bit silly to go through all the trouble of
implementing a complicated anycast geo. dist scheme,   while ignoring
a simpler failure mode.    It's your choice.

It's not appropriately so for a registrar to say anything your choice;
thats your network
not theirs.  By the same token the registrar can't tell you not to
alias all 3 IP addresses on
different subnets to the same physical server.

Again, it's ill-advised, but a "mistake"  that has nothing to do with
the registrar's network or the registration service.

--
-JH


From bmanning at vacation.karoshi.com  Tue May 29 00:59:19 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 29 May 2012 05:59:19 +0000
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <20120529023823.C2B5220FE5A8@drugs.dv.isc.org>
References: <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>
 <20120529023823.C2B5220FE5A8@drugs.dv.isc.org>
Message-ID: <20120529055919.GA23179@vacation.karoshi.com.>

On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> 
> Putting it another way, the ISP doesn't want to be fooled even if
> it is fooling its customers.  

	don't lie to us, but we lie to our customers.

	and you don't see a problem with this?

/bill


From randy at psg.com  Tue May 29 01:13:33 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 29 May 2012 15:13:33 +0900
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ@mail.gmail.com>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <F95A06F9-39E8-4830-8D55-C5983EA9B5F4@virtualized.org>
 <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ@mail.gmail.com>
Message-ID: <m2txyzikfm.wl%randy@psg.com>

> It is more important that a domain registrar not refuse to register a
> domain, or erroneously declare a valid listing invalid.
> 
> The purpose of using a registrar is to establish DNS delegation, not
> to validate your site's redundancy meets the absolute best possible
> practices for fault tolerance.

just for my curiosity, where do you draw the line for technical
compliance?  do the servers need to serve the zone?  does the served
zone need to have the same NS RRset as the request and hence parent?
do the servers need to be able to answer compliant dns queries?  over
tcp too?

your first paragraph quoted above would seem to say that none of this is
needed.  the registrar's job is to stick the delegation in the parent
zone and actually functioning name service be damned.

randy, a naggumite


From marka at isc.org  Tue May 29 01:37:29 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 29 May 2012 16:37:29 +1000
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: Your message of "Tue, 29 May 2012 05:59:19 GMT."
 <20120529055919.GA23179@vacation.karoshi.com.>
References: <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>
 <20120529023823.C2B5220FE5A8@drugs.dv.isc.org>
 <20120529055919.GA23179@vacation.karoshi.com.>
Message-ID: <20120529063731.686622106AEB@drugs.dv.isc.org>


In message <20120529055919.GA23179 at vacation.karoshi.com.>, bmanning at vacation.ka
roshi.com writes:
> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> > 
> > Putting it another way, the ISP doesn't want to be fooled even if
> > it is fooling its customers.  
> 
> 	don't lie to us, but we lie to our customers.
> 
> 	and you don't see a problem with this?

I didn't say I like it.  It may even be illegal in some juristictions
for a ISP to do it without properly informing the customer and
allowing them to opt in/out.  Doing it to yourself however can't
be illegal.  In the end it is a tool and the method of deployment
is often as important as whether you deploy it or not.

It's a little like direct marketing via email.  If you have consent
of the party being emailed it isn't spam.  If you don't have consent
it is spam at least here in Australia.  Other juristictions have
looser guidelines.

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


From george.herbert at gmail.com  Tue May 29 01:42:14 2012
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 28 May 2012 23:42:14 -0700
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <4fc4668f.9101320a.3db1.ffff8773SMTPIN_ADDED@mx.google.com>
References: <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>
 <20120529023823.C2B5220FE5A8@drugs.dv.isc.org>
 <4fc4668f.9101320a.3db1.ffff8773SMTPIN_ADDED@mx.google.com>
Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7@gmail.com>





On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:

> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>> 
>> Putting it another way, the ISP doesn't want to be fooled even if
>> it is fooling its customers.  
> 
>    don't lie to us, but we lie to our customers.
> 
>    and you don't see a problem with this?
> 
> /bill

We tried saying no, we tried walking customers away, we tried not adding the feature, we tried shame, someone reputedly had dolls with pins in them.

We lost.

There is an endgame around that; when it's ready....


George William Herbert
Sent from my iPhone

From dot at dotat.at  Tue May 29 04:51:54 2012
From: dot at dotat.at (Tony Finch)
Date: Tue, 29 May 2012 10:51:54 +0100
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <m2likbspug.wl%randy@psg.com>
References: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
 <20120529005412.6354420FD3FB@drugs.dv.isc.org> <m2likbspug.wl%randy@psg.com>
Message-ID: <alpine.LSU.2.00.1205291050540.5807@hermes-2.csi.cam.ac.uk>

Randy Bush <randy at psg.com> wrote:
>
> > When your browers supports DANE
>
> and a billion home nats support dnssec :(

I expect there will be a depressingly large amount of DNS-over-TLS in the
future in order to bypass broken ALGs.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate,
occasionally very poor.


From randy at psg.com  Tue May 29 04:58:47 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 29 May 2012 18:58:47 +0900
Subject: NXDomain remapping, DNSSEC, Layer 9, and you.
In-Reply-To: <alpine.LSU.2.00.1205291050540.5807@hermes-2.csi.cam.ac.uk>
References: <1564718.6360.1338247007903.JavaMail.root@benjamin.baylink.com>
 <20120529005412.6354420FD3FB@drugs.dv.isc.org>
 <m2likbspug.wl%randy@psg.com>
 <alpine.LSU.2.00.1205291050540.5807@hermes-2.csi.cam.ac.uk>
Message-ID: <m2ehq3ia08.wl%randy@psg.com>

> I expect there will be a depressingly large amount of DNS-over-TLS in
> the future in order to bypass broken ALGs.

there may be a lot of foo-over-https to bypass broken nats in the core,
and the edge, and whatever restrictive middleboxes political disfunction
creates.

because of st00pidity, we will go up a layer to try to reestablish end
to end.

randy


From bortzmeyer at nic.fr  Tue May 29 05:27:59 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 29 May 2012 12:27:59 +0200
Subject: rpki vs. secure dns?
In-Reply-To: <4FC3F5D7.5000206@isc.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org>
Message-ID: <20120529102759.GA25838@nic.fr>

On Mon, May 28, 2012 at 10:01:59PM +0000,
 paul vixie <vixie at isc.org> wrote 
 a message of 37 lines which said:

> i can tell more than that. rover is a system that only works at all
> when everything everywhere is working well, and when changes always
> come in perfect time-order,

Exactly like DNSSEC. So, DNSSEC is doomed :-)


From bortzmeyer at nic.fr  Tue May 29 05:30:06 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 29 May 2012 12:30:06 +0200
Subject: rpki vs. secure dns?
In-Reply-To: <g38vgc81jj.fsf@nsa.vix.com>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
Message-ID: <20120529103005.GB25838@nic.fr>

On Mon, May 28, 2012 at 08:59:28PM +0000,
 Paul Vixie <vixie at isc.org> wrote 
 a message of 43 lines which said:

> ROVER expects that we will query for policy at the instant of
> need. that's nuts for a lot of reasons, one of which is its
> potentially and unmanageably circular dependency on the acceptance
> of a route you don't know how to accept or reject yet.

If someone starts to announce 2001:db8:f00::/48 *and* all the name
servers for 0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa are in 2001:db8:f00::/48,
then I suggest that he is wrong, not Rover...



From bortzmeyer at nic.fr  Tue May 29 05:34:51 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 29 May 2012 12:34:51 +0200
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <20120528235629.GA23276@panix.com>
References: <25604_1338233229_4FC3D18D_25604_1794_1_CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <20120528193229.GA24594@sources.org>
 <20120528235629.GA23276@panix.com>
Message-ID: <20120529103451.GC25838@nic.fr>

On Mon, May 28, 2012 at 06:56:29PM -0500,
 Brett Frankenberger <rbf+nanog at panix.com> wrote 
 a message of 15 lines which said:

> How does your employer know if two nameservers (two IP addresses) are
> on the same subnet?

The current heuristic for IPv4 is "belongs in the same /28" (and /64
for IPv6). Otherwise, Mark Andrews is right, we should use a BGP feed
but it would be complicated for a command-line tool.


From vixie at isc.org  Tue May 29 06:02:38 2012
From: vixie at isc.org (paul vixie)
Date: Tue, 29 May 2012 11:02:38 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <20120529102759.GA25838@nic.fr>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
Message-ID: <4FC4ACCE.6000903@isc.org>

On 5/29/2012 10:27 AM, Stephane Bortzmeyer wrote:
> On Mon, May 28, 2012 at 10:01:59PM +0000,
>  paul vixie <vixie at isc.org> wrote 
>  a message of 37 lines which said:
>
>> i can tell more than that. rover is a system that only works at all
>> when everything everywhere is working well, and when changes always
>> come in perfect time-order,
> Exactly like DNSSEC. 

no. dnssec for a response only needs that response's delegation and
signing path to work, not "everything everywhere".

> So, DNSSEC is doomed :-)

i hope not. if we had to start over on something that can protect the
cache against trivial pollution and also enable new applications like
DANE, we'd be ten years from first prototype instead of ten years from
ubiquity.

paul


From o.calvano at gmail.com  Tue May 29 06:56:09 2012
From: o.calvano at gmail.com (Olivier CALVANO)
Date: Tue, 29 May 2012 13:56:09 +0200
Subject: Search Link between changzhou (china) and Singapore
Message-ID: <CAJajPee3smod-x8r0FE=teWmem=0U1PiJwNt=hZ9+==123N9Bw@mail.gmail.com>

Hi

I am search a operator for a Layer 2 Link (if possible) between:
Changzhou (china)
Equinix Singapore

anyone know operators for this ?

thanks
olivier


From carl at mobsource.com  Tue May 29 07:21:39 2012
From: carl at mobsource.com (carl gough [mobsource])
Date: Tue, 29 May 2012 22:21:39 +1000
Subject: NANOG Digest, Vol 52, Issue 67
In-Reply-To: <mailman.13882.1338285123.46019.nanog@nanog.org>
Message-ID: <CBEAFC58.34E07%carl@mobsource.com>

Does anyone have any intel on bandwidth trading in the usa?

[carl gough] founder and CEO  +61 425 266 764

mobsource .com  defined by benefits  not by technology
Skype ? mobsource Follow @mobsource Facebook ? mobsource


















On 29/05/12 7:52 PM, "nanog-request at nanog.org" <nanog-request at nanog.org>
wrote:

>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. IPv6 security: New IETF I-Ds, slideware and videos of recent
>      presentations, trainings, etc... (Fernando Gont)
>   2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
>   3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
>   4. Re: DNS anycasting - multiple DNS servers on same subnet Vs
>      registrar/registry policies (Jimmy Hess)
>   5. Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>      (bmanning at vacation.karoshi.com)
>   6. Re: DNS anycasting - multiple DNS servers on same subnet Vs
>      registrar/registry policies (Randy Bush)
>   7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
>   8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert)
>   9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 28 May 2012 22:17:33 -0300
>From: Fernando Gont <fernando at gont.com.ar>
>To: NANOG <nanog at nanog.org>
>Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent
>	presentations, trainings, etc...
>Message-ID: <4FC423AD.5000703 at gont.com.ar>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Folks,
>
>* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
>Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
>protection against rogue DHCPv6 servers. The I-D is available at:
><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
>Other IPv6 security I-Ds (such as,
>draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
>check them out at:
><http://www.si6networks.com/publications/ietf.html>
>
>* The slideware (and some videos!) of some of our recent presentations
>about IPv6 security are now available online. You can find them at:
><http://www.si6networks.com/presentations/index.html>
>
>* We have also scheduled IPv6 hacking trainings in Paris (France) and
>Ghent (Belgium). You can find more details at:
><http://www.si6networks.com/index.html#conferences>
>
>Our Twitter: @SI6Networks
>ipv6hackers mailing-list:
><http://lists.si6networks.com/listinfo/ipv6hackers/>
>
>Thanks!
>
>Best regards,
>-- 
>Fernando Gont
>SI6 Networks
>e-mail: fgont at si6networks.com
>PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>
>
>-- 
>Fernando Gont
>e-mail: fernando at gont.com.ar || fgont at si6networks.com
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 29 May 2012 12:38:23 +1000
>From: Mark Andrews <marka at isc.org>
>To: Jay Ashworth <jra at baylink.com>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
>
>
>In message 
><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay
>Ashworth writ
>es:
>> ----- Original Message -----
>> > From: "Mark Andrews" <marka at isc.org>
>> 
>> [ vix: ]
>> > > > meanwhile isc continues to push for ubiquitous dnssec, through to
>> > > > the stub,
>> > > > to take this issue off the table for all people and all time.
>> > > > (that's "the
>> > > > real fix" for nxdomain remapping.)
>> > >
>> > > You really believe that the outcome of that will be "we can't make
>> > > some
>> > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the
>> > > hell
>> > > with DNSSEC, then"?
>> > 
>> > People will route around ISP that do stupid things. They do so
>> > today. When your browers supports DANE there will be more incentive
>> > to ensure that DNSSEC does not break and more incentive to route
>> > around ISP's that do break DNSSEC.
>> 
>> My personal reaction to that, Mark, is to say that you *badly*
>>overestimate
>> the average Internet end-user (who make up, roughly, 80% of the
>>endpoints,
>> in my jackleg estimation).
>
>Google's recursive nameservers see plenty of traffic.
> 
>> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that
>> > it is a real NXDOMAIN not one that is spoofed do the path to the
>> > ISP's resolver will be DNSSEC clean and they will be validating.
>> 
>> I'm not sure I understood that...
>
>        Authoritative server
>                ^
>	     secure
>         (DO=1 queries)
>		v
>  ISP's validating recursive server
>                ^
>     insecure, redirect possible
>         (DO=0 queries)
>                v
>           Stub clients.
>
>Putting it another way, the ISP doesn't want to be fooled even if
>it is fooling its customers.  The ISP can't allow it's recursive
>servers to get the wrong answers for irs.gov, picking a signed
>domain, as they would look silly for not validating when there is
>a simple way for them to be sure that they are not being spoofed.
>
>> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
>> > be a problem for ISP's that want to do nxdomain redirection. There
>> > still plenty of crappy DNS proxies in CPE routers to be replaced
>> > before you can just set DO=1 as a default without worrying about
>> > breaking DNS lookups. Even setting EDNS as a default is a issue.
>> 
>> ...but that's probably because I don't understand DNSSEC well enough.
>
>The ISP <-> stub client path often has a additional piece in the
>path that is often a heap of steaming !@$! that doesn't do basic
>DNS let alone EDNS and DNSSEC.  For example the Netgear router at
>home doesn't support DNS over TCP which is basic DNS (I'm using it
>as a access point not a router because of this).   It's this sort
>of breakage that is stopping OS vendors changing defaults.  This
>can often be bypassed by forcing the resolver to use the ISP's
>nameservers directly but you need to know to do that.
>
>     ISP's validating recursive server
>                ^
>                v
>            CPE Router (broken DNS proxy code)
>                ^
>                v
>           Stub clients.
>
>You can also replace CPE Router with a broken firewall that is a
>steaming heap of !@#% when it comes to DNS packet inspection.  These
>are harder to bypass and require someone to fix the configuration
>to replace/upgrade the box.
>
>> > That said we are starting down the long path to making it EDNS a
>> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
>> > turns set DO=1 as well. You don't get things fixed if the breakage
>> > is not visible.
>> 
>> We may be talking about different breakage here...
>> 
>> 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
>> 
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 29 May 2012 12:47:10 +1000
>From: Mark Andrews <marka at isc.org>
>To: Jimmy Hess <mysidia at gmail.com>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
>
>
>In message 
><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
>, Jimmy Hess writes:
>> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
>> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
>> > be a problem for ISP's that want to do nxdomain redirection.  There
>> 
>> Yeah.............
>> Right now current _server_  implementations don't even have it right,
>> for properly implementing DNSSEC validation down to that level, let
>> alone the stubs below the server.
>> 
>> Many SME LANs utilize Windows-based endpoints, and commonly have
>> Windows-based DNS servers on the LAN, used by endpoints, where the
>> Windows DNS servers are set to forward queries to ISP recursive
>> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
>>  When Windows DNS server is configured to forward DNS queries to a
>> list of reasonable  recursive DNS servers,  the server sets  CD (Check
>> disabled) bit set, and the DO bit set  for all queries it sends;
>> there is no option to "support dnssec queries from smart stubs but
>> don't send queries from dumb stubs with CD".
>
>Well I'm trying to get this fixed at the protocol level for other
>reasons as explained in
>http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html
>
>draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
>call and if you think always setting CD=1 when forwarding is bad for
>whatever reason I could do with some support.
> 
>> Also, there are by default no trust anchors, and _Every_ response is
>> treated as valid.  (In other words, CD bit and DO bits are set in
>> forwarded queries, but no validation occurs).
>> It's kind of like having a SSL implementation that treats ALL SSL
>> certificates as valid, until and unless you take manual steps to
>> configure a CA list.
>> 
>> If you don't like this default and want to configure Windows DNS with
>> the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
>> supported key type, and the current root signing key is not of a
>> compatible format.
>> 
>> Your "smart" stub can send a query to this broken DNSSEC
>> implementation with the DO bit set, for sure.
>> 
>> 
>> 
>> 
>> > still plenty of crappy DNS proxies in CPE routers to be replaced
>> > before you can just set DO=1 as a default without worrying about
>> > breaking DNS lookups.  Even setting EDNS as a default is a issue.
>> [snip]
>> 
>> I'm all for smart stubs   as long as  (1) They can get the data to them
>> (2) They can get the proper logging/reporting to them,  E.g.   No
>> "silent" upstream validate/discard;      No  upstream  silent "ignore
>> the stub's requested CD bit and validate/discard anyways"
>> and
>> 
>> (3) The validation path is intact for _dumb_ non-validating stubs too.
>> 
>> --
>> -JH
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
>
>
>------------------------------
>
>Message: 4
>Date: Mon, 28 May 2012 23:58:00 -0500
>From: Jimmy Hess <mysidia at gmail.com>
>To: David Conrad <drc at virtualized.org>
>Cc: NANOG Mailing List <nanog at nanog.org>
>Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
>	registrar/registry policies
>Message-ID:
>	<CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On 5/28/12, David Conrad <drc at virtualized.org> wrote:
>> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
>>> I know few registry/registrars
>>> which do not accept both (or all) name servers of domain name on same
>>> subnet. They demand at least 1 DNS server should be on different
>>>subnet for
>>> failover reasons (old thoughts).
>> IMHO appropriately so.  The fact that anycast allows for multiple
>> (potentially) geographically distributed machines to respond to DNS
>>queries
>> does not remove the value of having multiple prefixes for DNS servers.
>[snip]
>It dramatically reduces the value, and meets the basic RFC requirement
>for geographically distributed DNS servers, although there are still
>routing issues that will impact all DNS servers to share a prefix
>It is more important that a domain registrar not refuse to register a
>domain,  or erroneously declare a valid listing invalid.
>
>The purpose of using a registrar is to establish DNS delegation, not
>to validate your site's redundancy meets the absolute best possible
>practices for fault tolerance.
>
>Ideally certainly should have DNS servers under multiple prefixes --
>and it seems a little bit silly to go through all the trouble of
>implementing a complicated anycast geo. dist scheme,   while ignoring
>a simpler failure mode.    It's your choice.
>
>It's not appropriately so for a registrar to say anything your choice;
>thats your network
>not theirs.  By the same token the registrar can't tell you not to
>alias all 3 IP addresses on
>different subnets to the same physical server.
>
>Again, it's ill-advised, but a "mistake"  that has nothing to do with
>the registrar's network or the registration service.
>
>--
>-JH
>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 29 May 2012 05:59:19 +0000
>From: bmanning at vacation.karoshi.com
>To: Mark Andrews <marka at isc.org>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529055919.GA23179 at vacation.karoshi.com.>
>Content-Type: text/plain; charset=us-ascii
>
>On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>> 
>> Putting it another way, the ISP doesn't want to be fooled even if
>> it is fooling its customers.
>
>	don't lie to us, but we lie to our customers.
>
>	and you don't see a problem with this?
>
>/bill
>
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 29 May 2012 15:13:33 +0900
>From: Randy Bush <randy at psg.com>
>To: Jimmy Hess <mysidia at gmail.com>
>Cc: North American Network Operators' Group <nanog at nanog.org>
>Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
>	registrar/registry policies
>Message-ID: <m2txyzikfm.wl%randy at psg.com>
>Content-Type: text/plain; charset=US-ASCII
>
>> It is more important that a domain registrar not refuse to register a
>> domain, or erroneously declare a valid listing invalid.
>> 
>> The purpose of using a registrar is to establish DNS delegation, not
>> to validate your site's redundancy meets the absolute best possible
>> practices for fault tolerance.
>
>just for my curiosity, where do you draw the line for technical
>compliance?  do the servers need to serve the zone?  does the served
>zone need to have the same NS RRset as the request and hence parent?
>do the servers need to be able to answer compliant dns queries?  over
>tcp too?
>
>your first paragraph quoted above would seem to say that none of this is
>needed.  the registrar's job is to stick the delegation in the parent
>zone and actually functioning name service be damned.
>
>randy, a naggumite
>
>
>
>------------------------------
>
>Message: 7
>Date: Tue, 29 May 2012 16:37:29 +1000
>From: Mark Andrews <marka at isc.org>
>To: bmanning at vacation.karoshi.com
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
>
>
>In message <20120529055919.GA23179 at vacation.karoshi.com.>,
>bmanning at vacation.ka
>roshi.com writes:
>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>> > 
>> > Putting it another way, the ISP doesn't want to be fooled even if
>> > it is fooling its customers.
>> 
>> 	don't lie to us, but we lie to our customers.
>> 
>> 	and you don't see a problem with this?
>
>I didn't say I like it.  It may even be illegal in some juristictions
>for a ISP to do it without properly informing the customer and
>allowing them to opt in/out.  Doing it to yourself however can't
>be illegal.  In the end it is a tool and the method of deployment
>is often as important as whether you deploy it or not.
>
>It's a little like direct marketing via email.  If you have consent
>of the party being emailed it isn't spam.  If you don't have consent
>it is spam at least here in Australia.  Other juristictions have
>looser guidelines.
>
>Mark
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
>
>
>------------------------------
>
>Message: 8
>Date: Mon, 28 May 2012 23:42:14 -0700
>From: George Herbert <george.herbert at gmail.com>
>To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
>Content-Type: text/plain;	charset=us-ascii
>
>
>
>
>
>On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:
>
>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>>> 
>>> Putting it another way, the ISP doesn't want to be fooled even if
>>> it is fooling its customers.
>> 
>>    don't lie to us, but we lie to our customers.
>> 
>>    and you don't see a problem with this?
>> 
>> /bill
>
>We tried saying no, we tried walking customers away, we tried not adding
>the feature, we tried shame, someone reputedly had dolls with pins in
>them.
>
>We lost.
>
>There is an endgame around that; when it's ready....
>
>
>George William Herbert
>Sent from my iPhone
>
>
>------------------------------
>
>Message: 9
>Date: Tue, 29 May 2012 10:51:54 +0100
>From: Tony Finch <dot at dotat.at>
>To: Randy Bush <randy at psg.com>
>Cc: North American Network Operators' Group <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID:
>	<alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Randy Bush <randy at psg.com> wrote:
>>
>> > When your browers supports DANE
>>
>> and a billion home nats support dnssec :(
>
>I expect there will be a depressingly large amount of DNS-over-TLS in the
>future in order to bypass broken ALGs.
>
>Tony.
>-- 
>f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
>Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate,
>occasionally very poor.
>
>
>
>End of NANOG Digest, Vol 52, Issue 67
>*************************************




From nabilsharma at hotmail.com  Tue May 29 09:06:41 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Tue, 29 May 2012 14:06:41 +0000
Subject: NANOG Digest, Vol 52, Issue 67
In-Reply-To: <CBEAFC58.34E07%carl@mobsource.com>
References: <mailman.13882.1338285123.46019.nanog@nanog.org>,
 <CBEAFC58.34E07%carl@mobsource.com>
Message-ID: <SNT129-W194941D0E978BCE9EC0433A3050@phx.gbl>

Mr Karl:

We use number of these service to improve delivery of our content to end users.

Which service or services do you seek info for?

Sincerely,
Nabil

> Date: Tue, 29 May 2012 22:21:39 +1000
> Subject: Re: NANOG Digest, Vol 52, Issue 67
> From: carl at mobsource.com
> To: nanog at nanog.org
> 
> Does anyone have any intel on bandwidth trading in the usa?
> 
> [carl gough] founder and CEO  +61 425 266 764
> 
> mobsource .com  defined by benefits  not by technology
> Skype ? mobsource Follow @mobsource Facebook ? mobsource
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 29/05/12 7:52 PM, "nanog-request at nanog.org" <nanog-request at nanog.org>
> wrote:
> 
> >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. IPv6 security: New IETF I-Ds, slideware and videos of recent
> >      presentations, trainings, etc... (Fernando Gont)
> >   2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   4. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Jimmy Hess)
> >   5. Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >      (bmanning at vacation.karoshi.com)
> >   6. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Randy Bush)
> >   7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert)
> >   9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch)
> >
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Mon, 28 May 2012 22:17:33 -0300
> >From: Fernando Gont <fernando at gont.com.ar>
> >To: NANOG <nanog at nanog.org>
> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent
> >	presentations, trainings, etc...
> >Message-ID: <4FC423AD.5000703 at gont.com.ar>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >Folks,
> >
> >* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
> >Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
> >protection against rogue DHCPv6 servers. The I-D is available at:
> ><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
> >Other IPv6 security I-Ds (such as,
> >draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
> >check them out at:
> ><http://www.si6networks.com/publications/ietf.html>
> >
> >* The slideware (and some videos!) of some of our recent presentations
> >about IPv6 security are now available online. You can find them at:
> ><http://www.si6networks.com/presentations/index.html>
> >
> >* We have also scheduled IPv6 hacking trainings in Paris (France) and
> >Ghent (Belgium). You can find more details at:
> ><http://www.si6networks.com/index.html#conferences>
> >
> >Our Twitter: @SI6Networks
> >ipv6hackers mailing-list:
> ><http://lists.si6networks.com/listinfo/ipv6hackers/>
> >
> >Thanks!
> >
> >Best regards,
> >-- 
> >Fernando Gont
> >SI6 Networks
> >e-mail: fgont at si6networks.com
> >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >
> >
> >-- 
> >Fernando Gont
> >e-mail: fernando at gont.com.ar || fgont at si6networks.com
> >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >
> >
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 2
> >Date: Tue, 29 May 2012 12:38:23 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jay Ashworth <jra at baylink.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
> >
> >
> >In message 
> ><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay
> >Ashworth writ
> >es:
> >> ----- Original Message -----
> >> > From: "Mark Andrews" <marka at isc.org>
> >> 
> >> [ vix: ]
> >> > > > meanwhile isc continues to push for ubiquitous dnssec, through to
> >> > > > the stub,
> >> > > > to take this issue off the table for all people and all time.
> >> > > > (that's "the
> >> > > > real fix" for nxdomain remapping.)
> >> > >
> >> > > You really believe that the outcome of that will be "we can't make
> >> > > some
> >> > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the
> >> > > hell
> >> > > with DNSSEC, then"?
> >> > 
> >> > People will route around ISP that do stupid things. They do so
> >> > today. When your browers supports DANE there will be more incentive
> >> > to ensure that DNSSEC does not break and more incentive to route
> >> > around ISP's that do break DNSSEC.
> >> 
> >> My personal reaction to that, Mark, is to say that you *badly*
> >>overestimate
> >> the average Internet end-user (who make up, roughly, 80% of the
> >>endpoints,
> >> in my jackleg estimation).
> >
> >Google's recursive nameservers see plenty of traffic.
> > 
> >> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that
> >> > it is a real NXDOMAIN not one that is spoofed do the path to the
> >> > ISP's resolver will be DNSSEC clean and they will be validating.
> >> 
> >> I'm not sure I understood that...
> >
> >        Authoritative server
> >                ^
> >	     secure
> >         (DO=1 queries)
> >		v
> >  ISP's validating recursive server
> >                ^
> >     insecure, redirect possible
> >         (DO=0 queries)
> >                v
> >           Stub clients.
> >
> >Putting it another way, the ISP doesn't want to be fooled even if
> >it is fooling its customers.  The ISP can't allow it's recursive
> >servers to get the wrong answers for irs.gov, picking a signed
> >domain, as they would look silly for not validating when there is
> >a simple way for them to be sure that they are not being spoofed.
> >
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> >> > be a problem for ISP's that want to do nxdomain redirection. There
> >> > still plenty of crappy DNS proxies in CPE routers to be replaced
> >> > before you can just set DO=1 as a default without worrying about
> >> > breaking DNS lookups. Even setting EDNS as a default is a issue.
> >> 
> >> ...but that's probably because I don't understand DNSSEC well enough.
> >
> >The ISP <-> stub client path often has a additional piece in the
> >path that is often a heap of steaming !@$! that doesn't do basic
> >DNS let alone EDNS and DNSSEC.  For example the Netgear router at
> >home doesn't support DNS over TCP which is basic DNS (I'm using it
> >as a access point not a router because of this).   It's this sort
> >of breakage that is stopping OS vendors changing defaults.  This
> >can often be bypassed by forcing the resolver to use the ISP's
> >nameservers directly but you need to know to do that.
> >
> >     ISP's validating recursive server
> >                ^
> >                v
> >            CPE Router (broken DNS proxy code)
> >                ^
> >                v
> >           Stub clients.
> >
> >You can also replace CPE Router with a broken firewall that is a
> >steaming heap of !@#% when it comes to DNS packet inspection.  These
> >are harder to bypass and require someone to fix the configuration
> >to replace/upgrade the box.
> >
> >> > That said we are starting down the long path to making it EDNS a
> >> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
> >> > turns set DO=1 as well. You don't get things fixed if the breakage
> >> > is not visible.
> >> 
> >> We may be talking about different breakage here...
> >> 
> >> 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
> >> 
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 3
> >Date: Tue, 29 May 2012 12:47:10 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
> >
> >
> >In message 
> ><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
> >, Jimmy Hess writes:
> >> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> >> > be a problem for ISP's that want to do nxdomain redirection.  There
> >> 
> >> Yeah.............
> >> Right now current _server_  implementations don't even have it right,
> >> for properly implementing DNSSEC validation down to that level, let
> >> alone the stubs below the server.
> >> 
> >> Many SME LANs utilize Windows-based endpoints, and commonly have
> >> Windows-based DNS servers on the LAN, used by endpoints, where the
> >> Windows DNS servers are set to forward queries to ISP recursive
> >> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
> >>  When Windows DNS server is configured to forward DNS queries to a
> >> list of reasonable  recursive DNS servers,  the server sets  CD (Check
> >> disabled) bit set, and the DO bit set  for all queries it sends;
> >> there is no option to "support dnssec queries from smart stubs but
> >> don't send queries from dumb stubs with CD".
> >
> >Well I'm trying to get this fixed at the protocol level for other
> >reasons as explained in
> >http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html
> >
> >draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
> >call and if you think always setting CD=1 when forwarding is bad for
> >whatever reason I could do with some support.
> > 
> >> Also, there are by default no trust anchors, and _Every_ response is
> >> treated as valid.  (In other words, CD bit and DO bits are set in
> >> forwarded queries, but no validation occurs).
> >> It's kind of like having a SSL implementation that treats ALL SSL
> >> certificates as valid, until and unless you take manual steps to
> >> configure a CA list.
> >> 
> >> If you don't like this default and want to configure Windows DNS with
> >> the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
> >> supported key type, and the current root signing key is not of a
> >> compatible format.
> >> 
> >> Your "smart" stub can send a query to this broken DNSSEC
> >> implementation with the DO bit set, for sure.
> >> 
> >> 
> >> 
> >> 
> >> > still plenty of crappy DNS proxies in CPE routers to be replaced
> >> > before you can just set DO=1 as a default without worrying about
> >> > breaking DNS lookups.  Even setting EDNS as a default is a issue.
> >> [snip]
> >> 
> >> I'm all for smart stubs   as long as  (1) They can get the data to them
> >> (2) They can get the proper logging/reporting to them,  E.g.   No
> >> "silent" upstream validate/discard;      No  upstream  silent "ignore
> >> the stub's requested CD bit and validate/discard anyways"
> >> and
> >> 
> >> (3) The validation path is intact for _dumb_ non-validating stubs too.
> >> 
> >> --
> >> -JH
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 28 May 2012 23:58:00 -0500
> >From: Jimmy Hess <mysidia at gmail.com>
> >To: David Conrad <drc at virtualized.org>
> >Cc: NANOG Mailing List <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >	registrar/registry policies
> >Message-ID:
> >	<CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >On 5/28/12, David Conrad <drc at virtualized.org> wrote:
> >> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
> >>> I know few registry/registrars
> >>> which do not accept both (or all) name servers of domain name on same
> >>> subnet. They demand at least 1 DNS server should be on different
> >>>subnet for
> >>> failover reasons (old thoughts).
> >> IMHO appropriately so.  The fact that anycast allows for multiple
> >> (potentially) geographically distributed machines to respond to DNS
> >>queries
> >> does not remove the value of having multiple prefixes for DNS servers.
> >[snip]
> >It dramatically reduces the value, and meets the basic RFC requirement
> >for geographically distributed DNS servers, although there are still
> >routing issues that will impact all DNS servers to share a prefix
> >It is more important that a domain registrar not refuse to register a
> >domain,  or erroneously declare a valid listing invalid.
> >
> >The purpose of using a registrar is to establish DNS delegation, not
> >to validate your site's redundancy meets the absolute best possible
> >practices for fault tolerance.
> >
> >Ideally certainly should have DNS servers under multiple prefixes --
> >and it seems a little bit silly to go through all the trouble of
> >implementing a complicated anycast geo. dist scheme,   while ignoring
> >a simpler failure mode.    It's your choice.
> >
> >It's not appropriately so for a registrar to say anything your choice;
> >thats your network
> >not theirs.  By the same token the registrar can't tell you not to
> >alias all 3 IP addresses on
> >different subnets to the same physical server.
> >
> >Again, it's ill-advised, but a "mistake"  that has nothing to do with
> >the registrar's network or the registration service.
> >
> >--
> >-JH
> >
> >
> >
> >------------------------------
> >
> >Message: 5
> >Date: Tue, 29 May 2012 05:59:19 +0000
> >From: bmanning at vacation.karoshi.com
> >To: Mark Andrews <marka at isc.org>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529055919.GA23179 at vacation.karoshi.com.>
> >Content-Type: text/plain; charset=us-ascii
> >
> >On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> 
> >> Putting it another way, the ISP doesn't want to be fooled even if
> >> it is fooling its customers.
> >
> >	don't lie to us, but we lie to our customers.
> >
> >	and you don't see a problem with this?
> >
> >/bill
> >
> >
> >
> >------------------------------
> >
> >Message: 6
> >Date: Tue, 29 May 2012 15:13:33 +0900
> >From: Randy Bush <randy at psg.com>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >	registrar/registry policies
> >Message-ID: <m2txyzikfm.wl%randy at psg.com>
> >Content-Type: text/plain; charset=US-ASCII
> >
> >> It is more important that a domain registrar not refuse to register a
> >> domain, or erroneously declare a valid listing invalid.
> >> 
> >> The purpose of using a registrar is to establish DNS delegation, not
> >> to validate your site's redundancy meets the absolute best possible
> >> practices for fault tolerance.
> >
> >just for my curiosity, where do you draw the line for technical
> >compliance?  do the servers need to serve the zone?  does the served
> >zone need to have the same NS RRset as the request and hence parent?
> >do the servers need to be able to answer compliant dns queries?  over
> >tcp too?
> >
> >your first paragraph quoted above would seem to say that none of this is
> >needed.  the registrar's job is to stick the delegation in the parent
> >zone and actually functioning name service be damned.
> >
> >randy, a naggumite
> >
> >
> >
> >------------------------------
> >
> >Message: 7
> >Date: Tue, 29 May 2012 16:37:29 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: bmanning at vacation.karoshi.com
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
> >
> >
> >In message <20120529055919.GA23179 at vacation.karoshi.com.>,
> >bmanning at vacation.ka
> >roshi.com writes:
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> > 
> >> > Putting it another way, the ISP doesn't want to be fooled even if
> >> > it is fooling its customers.
> >> 
> >> 	don't lie to us, but we lie to our customers.
> >> 
> >> 	and you don't see a problem with this?
> >
> >I didn't say I like it.  It may even be illegal in some juristictions
> >for a ISP to do it without properly informing the customer and
> >allowing them to opt in/out.  Doing it to yourself however can't
> >be illegal.  In the end it is a tool and the method of deployment
> >is often as important as whether you deploy it or not.
> >
> >It's a little like direct marketing via email.  If you have consent
> >of the party being emailed it isn't spam.  If you don't have consent
> >it is spam at least here in Australia.  Other juristictions have
> >looser guidelines.
> >
> >Mark
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 8
> >Date: Mon, 28 May 2012 23:42:14 -0700
> >From: George Herbert <george.herbert at gmail.com>
> >To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
> >Content-Type: text/plain;	charset=us-ascii
> >
> >
> >
> >
> >
> >On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:
> >
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >>> 
> >>> Putting it another way, the ISP doesn't want to be fooled even if
> >>> it is fooling its customers.
> >> 
> >>    don't lie to us, but we lie to our customers.
> >> 
> >>    and you don't see a problem with this?
> >> 
> >> /bill
> >
> >We tried saying no, we tried walking customers away, we tried not adding
> >the feature, we tried shame, someone reputedly had dolls with pins in
> >them.
> >
> >We lost.
> >
> >There is an endgame around that; when it's ready....
> >
> >
> >George William Herbert
> >Sent from my iPhone
> >
> >
> >------------------------------
> >
> >Message: 9
> >Date: Tue, 29 May 2012 10:51:54 +0100
> >From: Tony Finch <dot at dotat.at>
> >To: Randy Bush <randy at psg.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID:
> >	<alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >Randy Bush <randy at psg.com> wrote:
> >>
> >> > When your browers supports DANE
> >>
> >> and a billion home nats support dnssec :(
> >
> >I expect there will be a depressingly large amount of DNS-over-TLS in the
> >future in order to bypass broken ALGs.
> >
> >Tony.
> >-- 
> >f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> >Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate,
> >occasionally very poor.
> >
> >
> >
> >End of NANOG Digest, Vol 52, Issue 67
> >*************************************
> 
> 
> 
 		 	   		  

From Jason_Livingood at cable.comcast.com  Tue May 29 09:17:12 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 29 May 2012 14:17:12 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <3e09162446567502ad34e58c1d9c6c2f@u13.net>
Message-ID: <CBEA5275.622F4%jason_livingood@cable.comcast.com>

http://news.cnet.com/8301-1023_3-57436489-93/comcast-ditches-250gb-data-cap-tests-tiered-pricing/

The cap is [recently] suspended for most subscribers and if it comes
back it looks like it may be under a different policy going forward

Correct - the 250GB limit is suspended while alternatives are evaluated.

See http://blog.comcast.com/2012/05/comcast-to-replace-usage-cap-with-improved-data-usage-management-approaches.html

- Jason

From drc at virtualized.org  Tue May 29 09:17:20 2012
From: drc at virtualized.org (David Conrad)
Date: Tue, 29 May 2012 07:17:20 -0700
Subject: DNS anycasting - multiple DNS servers on same subnet Vs
 registrar/registry policies
In-Reply-To: <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ@mail.gmail.com>
References: <CAJ0+aXabEt=3eG-JFH1TXXWGS3JsnuAtqzQuGA78bj-6oxAgMQ@mail.gmail.com>
 <F95A06F9-39E8-4830-8D55-C5983EA9B5F4@virtualized.org>
 <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ@mail.gmail.com>
Message-ID: <8BB7B386-D893-49B3-927A-AEE9427927E0@virtualized.org>

Jimmy,

On May 28, 2012, at 9:58 PM, Jimmy Hess wrote:
> The purpose of using a registrar is to establish DNS delegation, not
> to validate your site's redundancy meets the absolute best possible
> practices for fault tolerance.

Terminology nit: the purpose of a registrar is to allow folks the freedom to choose the service level/price that meets their needs. I assume you mean 'registry'.

> It's not appropriately so for a registrar to say anything your choice; thats your network not theirs.  

An alternative viewpoint is that the parent zone is responsible for the child zone, thus the parent registry can impose what they feel are appropriate requirements to ensure the zones within that registry are maintained correctly. If you do not agree with these requirements, there are now over 200 other registries to choose from (and soon to be many, many more).

Regards,
-drc



From Jason_Livingood at cable.comcast.com  Tue May 29 09:19:35 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 29 May 2012 14:19:35 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <SNT129-W603297122BAE6387ED6D16A3040@phx.gbl>
Message-ID: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>

I generate http test stream with DSCP code point 5 to match the Xbox service, however Comcast is rewriting the packets as CS 1, even when serving out a server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft is using, it is not the regular paid peering.

Yeah, that won't work but that marking is just for byte counting (which per my other not does not really have any effect now anyway since the 250GB policy was suspended. See also http://blog.comcast.com/2012/05/the-facts-about-xfinity-tv-and-xbox-360-comcast-is-not-prioritizing.html

For peering & interconnect, see:
http://www.comcast.com/peering/?SCRedirect=true
http://www.comcast.com/dedicatedinternet/?SCRedirect=true

Thanks
Jason

From drc at virtualized.org  Tue May 29 09:21:35 2012
From: drc at virtualized.org (David Conrad)
Date: Tue, 29 May 2012 07:21:35 -0700
Subject: rpki vs. secure dns?
In-Reply-To: <4FC4ACCE.6000903@isc.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
Message-ID: <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>

On May 29, 2012, at 4:02 AM, paul vixie wrote:
>>> i can tell more than that. rover is a system that only works at all
>>> when everything everywhere is working well, and when changes always
>>> come in perfect time-order,
>> Exactly like DNSSEC. 
> 
> no. dnssec for a response only needs that response's delegation and
> signing path to work, not "everything everywhere".

My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.

Regards,
-drc



From carlosm3011 at gmail.com  Tue May 29 09:24:24 2012
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 29 May 2012 11:24:24 -0300
Subject: Video streaming over IPv6
In-Reply-To: <4FB298A7.802@gmail.com>
References: <4FB298A7.802@gmail.com>
Message-ID: <4FC4DC18.8040904@gmail.com>

As a followup on this question, I have had good success with Wowza Media
Server. Thanks to those who pointed it out to me.

If someone is interested in testing the IPv6 stream, drop me a note over
private.

Warm regards

Carlos

On 5/15/12 2:55 PM, Carlos Martinez-Cagnazzo wrote:
> Hello,
>
> Can anyone comment on the availability of IPv6 video streaming services?
> I'm thinking about commercial, 'cloud'-based services a la U-Stream or
> Make.TV.
>
> I can roll my own, and will eventually do so, but having a commercial
> service that I could use would make my life so much easier :-)
>
> Any such service who is thinking about jumping on the World IPv6 Launch
> Day bandwagon and could use some (I'd like to think clueful) debugging
> can also contact me, we might be able to work something out.
>
> regards,
>
> Carlos


From Jason_Livingood at cable.comcast.com  Tue May 29 09:25:10 2012
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 29 May 2012 14:25:10 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>
Message-ID: <CBEA5441.6230C%jason_livingood@cable.comcast.com>

Mail formatting issue with my mail client again? Note that the 1st paragraph was quoted from Nabil...

>I generate http test stream with DSCP code point 5 to match the Xbox service,
> however Comcast is rewriting the packets as CS 1, even when serving out a
> server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft
> is using, it is not the regular paid peering.

[JL] Yeah, that won't work but that marking is just for byte counting (which per my other not does not really have any effect now anyway since the 250GB policy was suspended. See also http://blog.comcast.com/2012/05/the-facts-about-xfinity-tv-and-xbox-360-comcast-is-not-prioritizing.html

For peering & interconnect, see:
http://www.comcast.com/peering/?SCRedirect=true
http://www.comcast.com/dedicatedinternet/?SCRedirect=true

Thanks
Jason

From alexb at ripe.net  Tue May 29 10:23:29 2012
From: alexb at ripe.net (Alex Band)
Date: Tue, 29 May 2012 17:23:29 +0200
Subject: rpki vs. secure dns?
In-Reply-To: <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
Message-ID: <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>

On 29 May 2012, at 16:21, David Conrad wrote:

> On May 29, 2012, at 4:02 AM, paul vixie wrote:
>>>> i can tell more than that. rover is a system that only works at all
>>>> when everything everywhere is working well, and when changes always
>>>> come in perfect time-order,
>>> Exactly like DNSSEC. 
>> 
>> no. dnssec for a response only needs that response's delegation and
>> signing path to work, not "everything everywhere".
> 
> My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.

RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'.

So in RPKI, partial data ? so you failed to fetch one of the ROAs in the set ? can make something 'invalid' or 'unknown' that should actually be 'valid'.
http://tools.ietf.org/html/rfc6483#page-3

As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)

-Alex

From paul4004 at gmail.com  Tue May 29 11:18:37 2012
From: paul4004 at gmail.com (PC)
Date: Tue, 29 May 2012 11:18:37 -0500
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <CBEA5441.6230C%jason_livingood@cable.comcast.com>
References: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>
 <CBEA5441.6230C%jason_livingood@cable.comcast.com>
Message-ID: <CAJAdsD=gQzqKcjx4D6vHBe3Ojm2SC876nf5ZGDtpzCTKAJwg5g@mail.gmail.com>

Hi Nabil,

DSCP tagging on inter-domain internet traffic is not expected to work (I
wouldn't expect this to work at any ISP, quite frankly, absent some very
special arrangements).

>From reading the article in the link below, it sounds like they are using
DSCP to ensure when a user has maxed their bandwidth allotment (say,
downloading the latest WOW update), that TV viewing is not disrupted.
Instead of providing QOS on it to do this, it seems they provide you an
included-with-the-service additional bandwidth allotment/connection not
related to your internet connection, much how normal video is sent.  In
theory, this service could work if you cancelled your internet.  In
reality, it probably won't.  Many providers do the same for VOIP traffic if
they have phone services, etc (which do often work with no internet
service).

I will say this -- I do telemetry data distribution which is nothing more
than a 1.5 megabit constant UDP stream (multicast anyone?  I wish).  The
amount of traffic I push is roughly ~350gb/month per site.  With hundreds
of business account sites on Comcast, Verizon, AT&T, cox, and others -- The
statistics don't lie.  The Comcast network has the least packet loss of the
bunch by a wide margin in many cases, and in my opinion, is the most well
built consumer broadband access network out there.  With forward error
correction, It's an extremely rare event that I see any requests for
retransmission, generally isolated to maintenance activities.

My suggestion?  Just send your data towards comcast from a Tier 1 ISP.  Get
it as close to your users (geographically) as you can, or use a CDN.  Then,
I think you will be fine.

As for the connectivity, you might find it a good idea to explore the
comcast paid peering/transit solution if comcast is your primary
destination and packet delivery is critical.  Heavy NDA requirements
resulting in lack of general pricing range input from the community every
time the question has come up on NANOG has kept me from inquiring about
paid peering.  But I will tell you just purchasing from the many transit
providers who do publish pricing has not resulted in any problems or
congestion, which is a good sign.



On Tue, May 29, 2012 at 9:25 AM, Livingood, Jason <
Jason_Livingood at cable.comcast.com> wrote:

> Mail formatting issue with my mail client again? Note that the 1st
> paragraph was quoted from Nabil...
>
> >I generate http test stream with DSCP code point 5 to match the Xbox
> service,
> > however Comcast is rewriting the packets as CS 1, even when serving out a
> > server at Soft Layer (paid peer).  This is why I ask for name of service
> Microsoft
> > is using, it is not the regular paid peering.
>
> [JL] Yeah, that won't work but that marking is just for byte counting
> (which per my other not does not really have any effect now anyway since
> the 250GB policy was suspended. See also
> http://blog.comcast.com/2012/05/the-facts-about-xfinity-tv-and-xbox-360-comcast-is-not-prioritizing.html
>
> For peering & interconnect, see:
> http://www.comcast.com/peering/?SCRedirect=true
> http://www.comcast.com/dedicatedinternet/?SCRedirect=true
>
> Thanks
> Jason
>

From richard.barnes at gmail.com  Tue May 29 11:33:51 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Tue, 29 May 2012 12:33:51 -0400
Subject: rpki vs. secure dns?
In-Reply-To: <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
Message-ID: <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>

>>>>> i can tell more than that. rover is a system that only works at all
>>>>> when everything everywhere is working well, and when changes always
>>>>> come in perfect time-order,
>>>> Exactly like DNSSEC.
>>>
>>> no. dnssec for a response only needs that response's delegation and
>>> signing path to work, not "everything everywhere".
>>
>> My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.
>
> RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'.
>
> So in RPKI, partial data ? so you failed to fetch one of the ROAs in the set ? can make something 'invalid' or 'unknown' that should actually be 'valid'.
> http://tools.ietf.org/html/rfc6483#page-3

I wouldn't read that as saying that the RPKI requires you to have full
data in order to provide any benefit.  Where sufficient certs and ROAs
exist to validate an announcement, you can mark it valid/invalid --
just like ROVER, but with a harder failure case.

> As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)

Of course, there's a reason that an announcement that contradicts a
ROA is marked as invalid [RFC6483].  Such announcements are hijacks,
the attacks that the RPKI is designed to prevent.  If ROVER doesn't
provide a hard fail here, then it would seem to not be providing much
security benefit.

I agree with the person higher up the thread that ROVER seems like
just another distribution mechanism for what is essentially RPKI data.

--Richard


From alexb at ripe.net  Tue May 29 12:05:01 2012
From: alexb at ripe.net (Alex Band)
Date: Tue, 29 May 2012 19:05:01 +0200
Subject: rpki vs. secure dns?
In-Reply-To: <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
Message-ID: <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>


On 29 May 2012, at 18:33, Richard Barnes wrote:

>>>>>> i can tell more than that. rover is a system that only works at all
>>>>>> when everything everywhere is working well, and when changes always
>>>>>> come in perfect time-order,
>>>>> Exactly like DNSSEC.
>>>> 
>>>> no. dnssec for a response only needs that response's delegation and
>>>> signing path to work, not "everything everywhere".
>>> 
>>> My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.
>> 
>> RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'.
>> 
>> So in RPKI, partial data ? so you failed to fetch one of the ROAs in the set ? can make something 'invalid' or 'unknown' that should actually be 'valid'.
>> http://tools.ietf.org/html/rfc6483#page-3
> 
> I wouldn't read that as saying that the RPKI requires you to have full
> data in order to provide any benefit.  Where sufficient certs and ROAs
> exist to validate an announcement, you can mark it valid/invalid --
> just like ROVER, but with a harder failure case.

I don't mean that you need ROAs describing every route announcement in existence for it to be useful. 

What I mean is for an operator to determine if a route announcement is RPKI valid, invalid or unknown, they will need *all* ROAs that *have been created*. If they miss a ROA in the data set during the fetching process, a route can end up with the incorrect validity state. See my example.

>> As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)
> 
> Of course, there's a reason that an announcement that contradicts a
> ROA is marked as invalid [RFC6483].  Such announcements are hijacks,
> the attacks that the RPKI is designed to prevent.  If ROVER doesn't
> provide a hard fail here, then it would seem to not be providing much
> security benefit.

That does seem the case. I don't think ROVER provides a hard fail. Can someone confirm?

> I agree with the person higher up the thread that ROVER seems like
> just another distribution mechanism for what is essentially RPKI data.

But does that distribution method easily allow you to get the full set of available data?

-Alex



From richard.barnes at gmail.com  Tue May 29 12:37:45 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Tue, 29 May 2012 13:37:45 -0400
Subject: rpki vs. secure dns?
In-Reply-To: <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
 <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>
Message-ID: <CACB24MuS7GUmwXevSSmLBjh-t0HjkKWR3JydDuDjaSPQqxXUPQ@mail.gmail.com>

>>> So in RPKI, partial data ? so you failed to fetch one of the ROAs in the set ? can make something 'invalid' or 'unknown' that should actually be 'valid'.
>>> http://tools.ietf.org/html/rfc6483#page-3
>>
>> I wouldn't read that as saying that the RPKI requires you to have full
>> data in order to provide any benefit. ?Where sufficient certs and ROAs
>> exist to validate an announcement, you can mark it valid/invalid --
>> just like ROVER, but with a harder failure case.
>
> I don't mean that you need ROAs describing every route announcement in existence for it to be useful.
>
> What I mean is for an operator to determine if a route announcement is RPKI valid, invalid or unknown, they will need *all* ROAs that *have been created*. If they miss a ROA in the data set during the fetching process, a route can end up with the incorrect validity state. See my example.

Oh, ok sure.  The validation outcomes with full data will be different
than with partial data.  But that's why the "unknown" state is there
-- as there's more data, things move from "unknown" to
"valid/invalid".


>>> As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)
>>
>> Of course, there's a reason that an announcement that contradicts a
>> ROA is marked as invalid [RFC6483]. ?Such announcements are hijacks,
>> the attacks that the RPKI is designed to prevent. ?If ROVER doesn't
>> provide a hard fail here, then it would seem to not be providing much
>> security benefit.
>
> That does seem the case. I don't think ROVER provides a hard fail. Can someone confirm?
>
>> I agree with the person higher up the thread that ROVER seems like
>> just another distribution mechanism for what is essentially RPKI data.
>
> But does that distribution method easily allow you to get the full set of available data?

>From what little I know, it seems to me that ROVER is optimized for
point queries, rather than bulk data access.  Which is the opposite of
making it easy to get full data :)

--Richard


From drc at virtualized.org  Tue May 29 12:43:46 2012
From: drc at virtualized.org (David Conrad)
Date: Tue, 29 May 2012 10:43:46 -0700
Subject: rpki vs. secure dns?
In-Reply-To: <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
Message-ID: <7F5B6800-47E9-4075-A819-0AA9E054302B@virtualized.org>

On May 29, 2012, at 8:23 AM, Alex Band wrote:
> RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data.

I think I now understand concerns about scaling... :-)

Regards,
-drc



From cmadams at hiwaay.net  Tue May 29 12:52:30 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 29 May 2012 12:52:30 -0500
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <SNT129-W603297122BAE6387ED6D16A3040@phx.gbl>
References: <CAJAdsD=FX3urOSb4Dqg05Ca6=a278AO8nErnhH5H5O6+o3XmBA@mail.gmail.com>
 <SNT129-W603297122BAE6387ED6D16A3040@phx.gbl>
Message-ID: <20120529175230.GF8479@hiwaay.net>

Once upon a time, Nabil Sharma <nabilsharma at hotmail.com> said:
> I generate http test stream with DSCP code point 5 to match the Xbox service, however Comcast is rewriting the packets as CS 1, even when serving out a server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft is using, it is not the regular paid peering.

It is my understanding that the Xbox On-Demand streaming is just talking
to the regular On-Demand servers at the head-end (just like On-Demand
over QAM works); the traffic has nothing to do with Microsoft's network,
peering, etc.  That's why Comcast doesn't count it against any caps; it
isn't transit traffic, it is local.
-- 
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 sylvie at newnog.org  Mon May 28 13:43:30 2012
From: sylvie at newnog.org (Sylvie LaPerriere)
Date: Mon, 28 May 2012 14:43:30 -0400
Subject: [NANOG-announce] A note to all NANOG Colleagues
Message-ID: <CA+Py6b8EyiTohmcoZoX3htKfVP4zEXVfb31jpk9w2XvKTiiSag@mail.gmail.com>

*NANOG Colleagues:

Just a year ago, NewNOG, prepared for the launch of NANOG 52 under a new
leadership. The journey has been filled with challenges, but also with
GREAT success. We delivered on our promise to ?not break anything? and
preserve your user experience during the transition.  Mission accomplished:
we produced NANOG 52, 53, 54 while each time learning, documenting and
improving upon the previous one.  We are thankful for your tolerance with
change and are confident for the future.

The important highlights we gleamed from our meetings and various
conversations in the community were to provide transparency in our
governance and continuance of the NANOG value set.  The Board and NANOG
Committees representatives met off-site last August to assess NANOG?s core
values, its important services and the meaning of its brand for attendees.
  The outcome was a 3-year strategic plan with milestones to provide this
board and its successors with a documented foundation for continuity.

Sponsors, members, and meeting attendees have been very supportive and
pleased with our progress, and simply wish to continue to enjoy being a
part of NANOG activities.  That is encouraging and a sign that we are
moving in the right direction.

In the spirit of transparency, and to recognize the hard work and
dedication of the Board and Committee members, I want to call out their
achievements:

   - Their personal commitment to attend bi-weekly Board meetings and their
   dedication in showing progress on their area of responsibility.
   - The Board and Development Committee created a sustainable sponsorship
   model <http://www.nanog.org/sponsors/sponsor_opportunities.html>compliant
with our non-profit status providing adequate funding for our
   current activities such as our mailing-lists, archives, and conferences
   while planning for the launch of our educational/training activities.
   - The Development Committee members fully met the respective Sponsorship
   plan targets for NANOG 52, 53, 54 and 55. We are financially sound.
   - The Program Committee delivered outstanding Programming for NANOG 53
   and NANOG 54, exceeding all previous expectations at respectively 583 and
   604 registrants.
   - The Program Committee delivered yet another outstanding Conference
   Agenda for NANOG 55 opening next week in Vancouver.
   - The Communications Committee continuously manages the mailing lists
   and our website services.
   - The Membership committee continues to provide value and benefits to
   its  members since its creation in February 2011.
   - The Board documented the roles, responsibilities of all Committee
   members.
   - The Board executed venue contracts for NANOG 56, 57, and closing on 58.
   - The Board secured a support structure (Secretariat, Executive
   Director, Conference technical services, event webcasting) without the
   burden of creating an employee set of responsibilities.
   - The Treasurer prepared and filed our first audited financial report.
   - The Executive Director has lead the transition phase of moving the
   NANOG equipment and Intellectual property onto their new locations.
   - The Executive Director has continued the strong relations with ARIN as
   we are exploring new ways of partnering in support of our common community.
   - The Executive Director and the NANOG Secretariat have developed smooth
   operational processes.
   - The NANOG Secretariat is a great team. They took special care in
   documenting processes and procedures as we learned our new ways.  We now
   have a solid playbook for our continued operations. They also attended all
   our committees, minuted and published.


As we approach our Election process next October, let me share a few
personal thoughts with you.  We are not yet done.  It is critical that we
complete the service transition steps, continue to streamline the
responsibilities of event planning and support.  We need to execute on our
commitment to launch our educational and scholarship initiatives.

In preparation for the election process and the need to reflect and set new
goals, I will be pleased to share with the community a summary of our Board
Retreat, Strategic Goals, and a peak into our future.  My hope is that you
will find an activity worthy of your volunteering.

Please plan to attend the NANOG Member Meeting, Sunday, June 3, 2012 at
5:45-6:45 pm (PST).


See you in Vancouver,

Sylvie
*

-- 

Sylvie LaPerriere

NANOG Chair   -  www.nanog.org
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

From paul at cupis.co.uk  Tue May 29 14:45:51 2012
From: paul at cupis.co.uk (Paul Cupis)
Date: Tue, 29 May 2012 20:45:51 +0100
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: <4FC3EBED.1060101@rollernet.us>
References: <1327824649.20120528163134@ip.datagroup.ua>
 <4FC3EBED.1060101@rollernet.us>
Message-ID: <jq390m$jet$1@dough.gmane.org>

On 28/05/12 22:19, Seth Mattinen wrote:
> On 5/28/12 6:31 AM, Evgeniy Aikashev wrote:
>> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our customers have no access to some part of Internet if they use these IPs.
>> Could you please update your bogon filters to permit this range.
>
> Do you have a test IP address that can be pinged or traceroute to?

5.1.1.1 works for me (ping/traceroute), from AS35228.

Regards,




From keith at mccallion.com  Tue May 29 15:36:36 2012
From: keith at mccallion.com (Keith McCallion)
Date: Tue, 29 May 2012 13:36:36 -0700
Subject: ISPs and full packet inspection
Message-ID: <4391984312dcdd7f26a85a46729309f9.squirrel@vienna.hostgo.com>

On Thu, May 24, 2012 7:36 pm, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Justin M. Streiner" <streiner at cluebyfour.org>
>> Aside from all of the business and legal sticking points that others
have
>> mentioned, there are also the technical aspects of capturing, storing,
transporting, analyzing, and managing those packets, and the appliances
that do the heavy lifting. As your traffic grows, that problem scales 1:1
linearly, at best, and more likely n:1 linearly, or worse. The added
overhead of the infrastructure needed to support this will also make
>> it more difficult to be price-competitive with your peers.
> TL:DR; The reasons for doing this on any kind of general basis have to
be *EXCEPTIONALLY* compelling to make a business case for it, apart from
any possible legal ramifications.
> I used asterisks *and* capital letters; that's about an order of
magnitude.
> Don't forget staffing.

I am a little surprised no one has referenced Wired's recent article about
Libya's Internet Surveillance systems:

http://www.wired.com/threatlevel/2012/05/ff_libya/all/1

It's good reading and I think does a good job of summarizing both the
technical challenges but also the political implications of such a system.

-Keith







From valdis.kletnieks at vt.edu  Tue May 29 15:53:48 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Tue, 29 May 2012 16:53:48 -0400
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: Your message of "Tue, 29 May 2012 20:45:51 +0100."
 <jq390m$jet$1@dough.gmane.org>
References: <1327824649.20120528163134@ip.datagroup.ua>
 <4FC3EBED.1060101@rollernet.us> <jq390m$jet$1@dough.gmane.org>
Message-ID: <32363.1338324828@turing-police.cc.vt.edu>

On Tue, 29 May 2012 20:45:51 +0100, Paul Cupis said:
> On 28/05/12 22:19, Seth Mattinen wrote:
> > On 5/28/12 6:31 AM, Evgeniy Aikashev wrote:
> >> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our customers have no access to some part of Internet if they use these IPs.
> >> Could you please update your bogon filters to permit this range.
> >
> > Do you have a test IP address that can be pinged or traceroute to?
>
> 5.1.1.1 works for me (ping/traceroute), from AS35228.

Given the allegations of squatting in 5/8, are you sure you got the *right* 5.1.1.1?

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

From shortdudey123 at gmail.com  Tue May 29 16:02:26 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Tue, 29 May 2012 16:02:26 -0500
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: <32363.1338324828@turing-police.cc.vt.edu>
References: <1327824649.20120528163134@ip.datagroup.ua>
 <4FC3EBED.1060101@rollernet.us> <jq390m$jet$1@dough.gmane.org>
 <32363.1338324828@turing-police.cc.vt.edu>
Message-ID: <CAPiURgX7c5jYmJzJ4jR_FLtWTd4RG8gniptQQngDxEsYb-YBAQ@mail.gmail.com>

I did a tracert from my school's network on TWC:

~~~~~~~~~
Tracing route to 5-1-1-1-dynamic.retail.datagroup.ua [5.1.1.1]
over a maximum of 30 hops:

  5     1 ms     1 ms     1 ms  esc033.escriptconnect.com [64.132.85.33]
  6     4 ms     4 ms     4 ms  chi2-pr1-xe-0-3-0-0.us.twtelecom.net[66.192.245
.166]
  7   140 ms   139 ms   139 ms  64.211.193.22
  8   140 ms   140 ms   140 ms  5-1-1-1-dynamic.retail.datagroup.ua[5.1.1.1]

Trace complete.
~~~~~~~~~

Hop 7 is owned by Level 3.  Hope this helps.

-Grant

On Tue, May 29, 2012 at 3:53 PM, <valdis.kletnieks at vt.edu> wrote:

> On Tue, 29 May 2012 20:45:51 +0100, Paul Cupis said:
> > On 28/05/12 22:19, Seth Mattinen wrote:
> > > On 5/28/12 6:31 AM, Evgeniy Aikashev wrote:
> > >> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our
> customers have no access to some part of Internet if they use these IPs.
> > >> Could you please update your bogon filters to permit this range.
> > >
> > > Do you have a test IP address that can be pinged or traceroute to?
> >
> > 5.1.1.1 works for me (ping/traceroute), from AS35228.
>
> Given the allegations of squatting in 5/8, are you sure you got the
> *right* 5.1.1.1?
>
>

From Curtis.Starnes at granburyisd.org  Tue May 29 16:38:31 2012
From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS)
Date: Tue, 29 May 2012 16:38:31 -0500
Subject: Bogon list update for prefix for 5.1.0.0/19
In-Reply-To: <CAPiURgX7c5jYmJzJ4jR_FLtWTd4RG8gniptQQngDxEsYb-YBAQ@mail.gmail.com>
References: <1327824649.20120528163134@ip.datagroup.ua>
 <4FC3EBED.1060101@rollernet.us> <jq390m$jet$1@dough.gmane.org>
 <32363.1338324828@turing-police.cc.vt.edu>
 <CAPiURgX7c5jYmJzJ4jR_FLtWTd4RG8gniptQQngDxEsYb-YBAQ@mail.gmail.com>
Message-ID: <A5FACB06A6163C4790FAE19E1C9314D70136CF2F8B42@MAILSRV.granbury.k12.tx.us>

No problems tracing from AS19945.
Robex.com shows 5.1.0.0/19 belonging to AS21219

Ran traceroute, mtr, and windows pathping.
No problems with any of them.

# traceroute -A 5.1.1.1
traceroute to 5.1.1.1 (5.1.1.1), 30 hops max, 60 byte packets
1st 3 hops snipped
4  cr83.dlstx.ip.att.net (12.122.139.50) [AS7018]  8.743 ms  8.755 ms  8.748 ms
 5  cr1.dlstx.ip.att.net (12.123.18.110) [AS7018]  8.792 ms  8.800 ms  8.784 ms
 6  gar25.dlstx.ip.att.net (12.122.85.233) [AS7018]  5.941 ms 192.205.32.178 (192.205.32.178) [*]  5.524 ms  5.377 ms
 7  64.211.193.22 (64.211.193.22) [AS3549]  161.212 ms  162.769 ms  196.734 ms
 8  5-1-1-1-dynamic.retail.datagroup.ua (5.1.1.1) [AS21219]  162.187 ms  160.830 ms  161.757 ms

                                                My traceroute  [v0.75]
TEC-MAILSCAN-DMZ.granbury.k12.tx.us (0.0.0.0)                                                Tue May 29 16:30:56 2012
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                             Packets               Pings
 Host                                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1st 2 hops snipped 
 3. cr83.dlstx.ip.att.net                                      0.0%   200    6.0   6.4   5.2  40.6   2.5
 4. cr1.dlstx.ip.att.net                                        0.0%   200    9.1   8.6   5.4  50.8   4.2
 5. gar25.dlstx.ip.att.net                                   0.0%   200    5.0   5.3   4.7  15.9   0.9
 6. 192.205.32.178                                                0.0%   186    5.1  18.3   5.0 195.7  35.7
 7. 64.211.193.22                                                  0.0%   186  184.4 170.3 159.4 254.3  14.3
 8. 5-1-1-1-dynamic.retail.datagroup.ua    0.0%   186  187.5 167.1 159.5 189.2   7.1


C:\Windows\System32>pathping 5.1.1.1

Tracing route to 5-1-1-1-dynamic.retail.datagroup.ua [5.1.1.1]
over a maximum of 30 hops:
1st 3 hops removed.....
  4  cr84.dlstx.ip.att.net [12.122.138.54]
  5  cr2.dlstx.ip.att.net [12.123.18.250]
  6  gar27.dlstx.ip.att.net [12.123.16.77]
  7  192.205.34.82
  8  64.211.193.22
  9  5-1-1-1-dynamic.retail.datagroup.ua [5.1.1.1]

Computing statistics for 225 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
1st 3 hops removed.........
  4  ---     100/ 100 =100%   100/ 100 =100%  cr84.dlstx.ip.att.net [12.122.138.54]                0/ 100 =  0%   |
  5  ---     100/ 100 =100%   100/ 100 =100%  cr2.dlstx.ip.att.net [12.123.18.250]                  0/ 100 =  0%   |
  6  ---     100/ 100 =100%   100/ 100 =100%  gar27.dlstx.ip.att.net [12.123.16.77]               0/ 100 =  0%   |
  7  ---     100/ 100 =100%   100/ 100 =100%  192.205.34.82                                                           0/ 100 =  0%   |
  8  191ms     2/ 100 =  2%     2/ 100 =  2%  64.211.193.22                                                               0/ 100 =  0%   |
  9  191ms     0/ 100 =  0%     0/ 100 =  0%  5-1-1-1-dynamic.retail.datagroup.ua [5.1.1.1]


Curtis

-----Original Message-----
From: Grant Ridder [mailto:shortdudey123 at gmail.com] 
Sent: Tuesday, May 29, 2012 4:02 PM
To: valdis.kletnieks at vt.edu
Cc: Paul Cupis; nanog at nanog.org
Subject: Re: Bogon list update for prefix for 5.1.0.0/19

I did a tracert from my school's network on TWC:

~~~~~~~~~
Tracing route to 5-1-1-1-dynamic.retail.datagroup.ua [5.1.1.1] over a maximum of 30 hops:

  5     1 ms     1 ms     1 ms  esc033.escriptconnect.com [64.132.85.33]
  6     4 ms     4 ms     4 ms  chi2-pr1-xe-0-3-0-0.us.twtelecom.net[66.192.245
.166]
  7   140 ms   139 ms   139 ms  64.211.193.22
  8   140 ms   140 ms   140 ms  5-1-1-1-dynamic.retail.datagroup.ua[5.1.1.1]

Trace complete.
~~~~~~~~~

Hop 7 is owned by Level 3.  Hope this helps.

-Grant

On Tue, May 29, 2012 at 3:53 PM, <valdis.kletnieks at vt.edu> wrote:

> On Tue, 29 May 2012 20:45:51 +0100, Paul Cupis said:
> > On 28/05/12 22:19, Seth Mattinen wrote:
> > > On 5/28/12 6:31 AM, Evgeniy Aikashev wrote:
> > >> We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. 
> > >> Our
> customers have no access to some part of Internet if they use these IPs.
> > >> Could you please update your bogon filters to permit this range.
> > >
> > > Do you have a test IP address that can be pinged or traceroute to?
> >
> > 5.1.1.1 works for me (ping/traceroute), from AS35228.
>
> Given the allegations of squatting in 5/8, are you sure you got the
> *right* 5.1.1.1?
>
>


From carl at mobsource.com  Tue May 29 16:50:07 2012
From: carl at mobsource.com (carl gough [mobsource])
Date: Wed, 30 May 2012 07:50:07 +1000
Subject: trading bandwidth
In-Reply-To: <SNT129-W194941D0E978BCE9EC0433A3050@phx.gbl>
Message-ID: <CBEB811F.34E28%carl@mobsource.com>

Thanks Nabil,  Bandwidth Trading is not a new concept, but to make it
work effectively it will have to address a couple of prerequisites to be
successful. A network of buyers and sellers has to be created, contracted
and connected for instant pricing, inventory management and delivery of a
defined and standardised service. Not a la enron of course, they traded
derivatives.

[carl gough] founder and CEO  +61 425 266 764
mobsource .com  defined by benefits  not by technology
Skype ? mobsource Follow @mobsource Facebook ? mobsource



From:  Nabil Sharma <nabilsharma at hotmail.com>
Date:  Tue, 29 May 2012 14:06:41 +0000
To:  carl gough <carl at mobsource.com>, <nanog at nanog.org>
Subject:  RE: NANOG Digest, Vol 52, Issue 67

Mr Karl:

We use number of these service to improve delivery of our content to end
users.

Which service or services do you seek info for?

Sincerely,
Nabil

> Date: Tue, 29 May 2012 22:21:39 +1000
> Subject: Re: NANOG Digest, Vol 52, Issue 67
> From: carl at mobsource.com
> To: nanog at nanog.org
> 
> Does anyone have any intel on bandwidth trading in the usa?
> 
> [carl gough] founder and CEO  +61 425 266 764
> 
> mobsource .com  defined by benefits  not by technology
> Skype ? mobsource Follow @mobsource Facebook ? mobsource
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 29/05/12 7:52 PM, "nanog-request at nanog.org" <nanog-request at nanog.org>
> wrote:
> 
> >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. IPv6 security: New IETF I-Ds, slideware and videos of recent
> >      presentations, trainings, etc... (Fernando Gont)
> >   2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   4. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Jimmy Hess)
> >   5. Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >      (bmanning at vacation.karoshi.com)
> >   6. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Randy Bush)
> >   7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert)
> >   9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch)
> >
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Mon, 28 May 2012 22:17:33 -0300
> >From: Fernando Gont <fernando at gont.com.ar>
> >To: NANOG <nanog at nanog.org>
> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent
> > presentations, trainings, etc...
> >Message-ID: <4FC423AD.5000703 at gont.com.ar>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >Folks,
> >
> >* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
> >Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
> >protection against rogue DHCPv6 servers. The I-D is available at:
> ><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
> >Other IPv6 security I-Ds (such as,
> >draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
> >check them out at:
> ><http://www.si6networks.com/publications/ietf.html>
> >
> >* The slideware (and some videos!) of some of our recent presentations
> >about IPv6 security are now available online. You can find them at:
> ><http://www.si6networks.com/presentations/index.html>
> >
> >* We have also scheduled IPv6 hacking trainings in Paris (France) and
> >Ghent (Belgium). You can find more details at:
> ><http://www.si6networks.com/index.html#conferences>
> >
> >Our Twitter: @SI6Networks
> >ipv6hackers mailing-list:
> ><http://lists.si6networks.com/listinfo/ipv6hackers/>
> >
> >Thanks!
> >
> >Best regards,
> >-- 
> >Fernando Gont
> >SI6 Networks
> >e-mail: fgont at si6networks.com
> >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >
> >
> >-- 
> >Fernando Gont
> >e-mail: fernando at gont.com.ar || fgont at si6networks.com
> >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >
> >
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 2
> >Date: Tue, 29 May 2012 12:38:23 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jay Ashworth <jra at baylink.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
> >
> >
> >In message 
> ><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay
> >Ashworth writ
> >es:
> >> ----- Original Message -----
> >> > From: "Mark Andrews" <marka at isc.org>
> >> 
> >> [ vix: ]
> >> > > > meanwhile isc continues to push for ubiquitous dnssec, through to
> >> > > > the stub,
> >> > > > to take this issue off the table for all people and all time.
> >> > > > (that's "the
> >> > > > real fix" for nxdomain remapping.)
> >> > >
> >> > > You really believe that the outcome of that will be "we can't make
> >> > > some
> >> > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the
> >> > > hell
> >> > > with DNSSEC, then"?
> >> > 
> >> > People will route around ISP that do stupid things. They do so
> >> > today. When your browers supports DANE there will be more incentive
> >> > to ensure that DNSSEC does not break and more incentive to route
> >> > around ISP's that do break DNSSEC.
> >> 
> >> My personal reaction to that, Mark, is to say that you *badly*
> >>overestimate
> >> the average Internet end-user (who make up, roughly, 80% of the
> >>endpoints,
> >> in my jackleg estimation).
> >
> >Google's recursive nameservers see plenty of traffic.
> > 
> >> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that
> >> > it is a real NXDOMAIN not one that is spoofed do the path to the
> >> > ISP's resolver will be DNSSEC clean and they will be validating.
> >> 
> >> I'm not sure I understood that...
> >
> >        Authoritative server
> >                ^
> >      secure
> >         (DO=1 queries)
> > v
> >  ISP's validating recursive server
> >                ^
> >     insecure, redirect possible
> >         (DO=0 queries)
> >                v
> >           Stub clients.
> >
> >Putting it another way, the ISP doesn't want to be fooled even if
> >it is fooling its customers.  The ISP can't allow it's recursive
> >servers to get the wrong answers for irs.gov, picking a signed
> >domain, as they would look silly for not validating when there is
> >a simple way for them to be sure that they are not being spoofed.
> >
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> >> > be a problem for ISP's that want to do nxdomain redirection. There
> >> > still plenty of crappy DNS proxies in CPE routers to be replaced
> >> > before you can just set DO=1 as a default without worrying about
> >> > breaking DNS lookups. Even setting EDNS as a default is a issue.
> >> 
> >> ...but that's probably because I don't understand DNSSEC well enough.
> >
> >The ISP <-> stub client path often has a additional piece in the
> >path that is often a heap of steaming !@$! that doesn't do basic
> >DNS let alone EDNS and DNSSEC.  For example the Netgear router at
> >home doesn't support DNS over TCP which is basic DNS (I'm using it
> >as a access point not a router because of this).   It's this sort
> >of breakage that is stopping OS vendors changing defaults.  This
> >can often be bypassed by forcing the resolver to use the ISP's
> >nameservers directly but you need to know to do that.
> >
> >     ISP's validating recursive server
> >                ^
> >                v
> >            CPE Router (broken DNS proxy code)
> >                ^
> >                v
> >           Stub clients.
> >
> >You can also replace CPE Router with a broken firewall that is a
> >steaming heap of !@#% when it comes to DNS packet inspection.  These
> >are harder to bypass and require someone to fix the configuration
> >to replace/upgrade the box.
> >
> >> > That said we are starting down the long path to making it EDNS a
> >> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
> >> > turns set DO=1 as well. You don't get things fixed if the breakage
> >> > is not visible.
> >> 
> >> We may be talking about different breakage here...
> >> 
> >> 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
> >> 
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 3
> >Date: Tue, 29 May 2012 12:47:10 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
> >
> >
> >In message 
> ><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
> >, Jimmy Hess writes:
> >> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> >> > be a problem for ISP's that want to do nxdomain redirection.  There
> >> 
> >> Yeah.............
> >> Right now current _server_  implementations don't even have it right,
> >> for properly implementing DNSSEC validation down to that level, let
> >> alone the stubs below the server.
> >> 
> >> Many SME LANs utilize Windows-based endpoints, and commonly have
> >> Windows-based DNS servers on the LAN, used by endpoints, where the
> >> Windows DNS servers are set to forward queries to ISP recursive
> >> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
> >>  When Windows DNS server is configured to forward DNS queries to a
> >> list of reasonable  recursive DNS servers,  the server sets  CD (Check
> >> disabled) bit set, and the DO bit set  for all queries it sends;
> >> there is no option to "support dnssec queries from smart stubs but
> >> don't send queries from dumb stubs with CD".
> >
> >Well I'm trying to get this fixed at the protocol level for other
> >reasons as explained in
> >http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html
> >
> >draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
> >call and if you think always setting CD=1 when forwarding is bad for
> >whatever reason I could do with some support.
> > 
> >> Also, there are by default no trust anchors, and _Every_ response is
> >> treated as valid.  (In other words, CD bit and DO bits are set in
> >> forwarded queries, but no validation occurs).
> >> It's kind of like having a SSL implementation that treats ALL SSL
> >> certificates as valid, until and unless you take manual steps to
> >> configure a CA list.
> >> 
> >> If you don't like this default and want to configure Windows DNS with
> >> the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
> >> supported key type, and the current root signing key is not of a
> >> compatible format.
> >> 
> >> Your "smart" stub can send a query to this broken DNSSEC
> >> implementation with the DO bit set, for sure.
> >> 
> >> 
> >> 
> >> 
> >> > still plenty of crappy DNS proxies in CPE routers to be replaced
> >> > before you can just set DO=1 as a default without worrying about
> >> > breaking DNS lookups.  Even setting EDNS as a default is a issue.
> >> [snip]
> >> 
> >> I'm all for smart stubs   as long as  (1) They can get the data to them
> >> (2) They can get the proper logging/reporting to them,  E.g.   No
> >> "silent" upstream validate/discard;      No  upstream  silent "ignore
> >> the stub's requested CD bit and validate/discard anyways"
> >> and
> >> 
> >> (3) The validation path is intact for _dumb_ non-validating stubs too.
> >> 
> >> --
> >> -JH
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 28 May 2012 23:58:00 -0500
> >From: Jimmy Hess <mysidia at gmail.com>
> >To: David Conrad <drc at virtualized.org>
> >Cc: NANOG Mailing List <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
> > registrar/registry policies
> >Message-ID:
> > <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >On 5/28/12, David Conrad <drc at virtualized.org> wrote:
> >> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
> >>> I know few registry/registrars
> >>> which do not accept both (or all) name servers of domain name on same
> >>> subnet. They demand at least 1 DNS server should be on different
> >>>subnet for
> >>> failover reasons (old thoughts).
> >> IMHO appropriately so.  The fact that anycast allows for multiple
> >> (potentially) geographically distributed machines to respond to DNS
> >>queries
> >> does not remove the value of having multiple prefixes for DNS servers.
> >[snip]
> >It dramatically reduces the value, and meets the basic RFC requirement
> >for geographically distributed DNS servers, although there are still
> >routing issues that will impact all DNS servers to share a prefix
> >It is more important that a domain registrar not refuse to register a
> >domain,  or erroneously declare a valid listing invalid.
> >
> >The purpose of using a registrar is to establish DNS delegation, not
> >to validate your site's redundancy meets the absolute best possible
> >practices for fault tolerance.
> >
> >Ideally certainly should have DNS servers under multiple prefixes --
> >and it seems a little bit silly to go through all the trouble of
> >implementing a complicated anycast geo. dist scheme,   while ignoring
> >a simpler failure mode.    It's your choice.
> >
> >It's not appropriately so for a registrar to say anything your choice;
> >thats your network
> >not theirs.  By the same token the registrar can't tell you not to
> >alias all 3 IP addresses on
> >different subnets to the same physical server.
> >
> >Again, it's ill-advised, but a "mistake"  that has nothing to do with
> >the registrar's network or the registration service.
> >
> >--
> >-JH
> >
> >
> >
> >------------------------------
> >
> >Message: 5
> >Date: Tue, 29 May 2012 05:59:19 +0000
> >From: bmanning at vacation.karoshi.com
> >To: Mark Andrews <marka at isc.org>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529055919.GA23179 at vacation.karoshi.com.>
> >Content-Type: text/plain; charset=us-ascii
> >
> >On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> 
> >> Putting it another way, the ISP doesn't want to be fooled even if
> >> it is fooling its customers.
> >
> > don't lie to us, but we lie to our customers.
> >
> > and you don't see a problem with this?
> >
> >/bill
> >
> >
> >
> >------------------------------
> >
> >Message: 6
> >Date: Tue, 29 May 2012 15:13:33 +0900
> >From: Randy Bush <randy at psg.com>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
> > registrar/registry policies
> >Message-ID: <m2txyzikfm.wl%randy at psg.com>
> >Content-Type: text/plain; charset=US-ASCII
> >
> >> It is more important that a domain registrar not refuse to register a
> >> domain, or erroneously declare a valid listing invalid.
> >> 
> >> The purpose of using a registrar is to establish DNS delegation, not
> >> to validate your site's redundancy meets the absolute best possible
> >> practices for fault tolerance.
> >
> >just for my curiosity, where do you draw the line for technical
> >compliance?  do the servers need to serve the zone?  does the served
> >zone need to have the same NS RRset as the request and hence parent?
> >do the servers need to be able to answer compliant dns queries?  over
> >tcp too?
> >
> >your first paragraph quoted above would seem to say that none of this is
> >needed.  the registrar's job is to stick the delegation in the parent
> >zone and actually functioning name service be damned.
> >
> >randy, a naggumite
> >
> >
> >
> >------------------------------
> >
> >Message: 7
> >Date: Tue, 29 May 2012 16:37:29 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: bmanning at vacation.karoshi.com
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
> >
> >
> >In message <20120529055919.GA23179 at vacation.karoshi.com.>,
> >bmanning at vacation.ka
> >roshi.com writes:
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> > 
> >> > Putting it another way, the ISP doesn't want to be fooled even if
> >> > it is fooling its customers.
> >> 
> >> don't lie to us, but we lie to our customers.
> >> 
> >> and you don't see a problem with this?
> >
> >I didn't say I like it.  It may even be illegal in some juristictions
> >for a ISP to do it without properly informing the customer and
> >allowing them to opt in/out.  Doing it to yourself however can't
> >be illegal.  In the end it is a tool and the method of deployment
> >is often as important as whether you deploy it or not.
> >
> >It's a little like direct marketing via email.  If you have consent
> >of the party being emailed it isn't spam.  If you don't have consent
> >it is spam at least here in Australia.  Other juristictions have
> >looser guidelines.
> >
> >Mark
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 8
> >Date: Mon, 28 May 2012 23:42:14 -0700
> >From: George Herbert <george.herbert at gmail.com>
> >To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> >
> >On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:
> >
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >>> 
> >>> Putting it another way, the ISP doesn't want to be fooled even if
> >>> it is fooling its customers.
> >> 
> >>    don't lie to us, but we lie to our customers.
> >> 
> >>    and you don't see a problem with this?
> >> 
> >> /bill
> >
> >We tried saying no, we tried walking customers away, we tried not adding
> >the feature, we tried shame, someone reputedly had dolls with pins in
> >them.
> >
> >We lost.
> >
> >There is an endgame around that; when it's ready....
> >
> >
> >George William Herbert
> >Sent from my iPhone
> >
> >
> >------------------------------
> >
> >Message: 9
> >Date: Tue, 29 May 2012 10:51:54 +0100
> >From: Tony Finch <dot at dotat.at>
> >To: Randy Bush <randy at psg.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID:
> > <alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >Randy Bush <randy at psg.com> wrote:
> >>
> >> > When your browers supports DANE
> >>
> >> and a billion home nats support dnssec :(
> >
> >I expect there will be a depressingly large amount of DNS-over-TLS in the
> >future in order to bypass broken ALGs.
> >
> >Tony.
> >-- 
> >f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> >Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate,
> >occasionally very poor.
> >
> >
> >
> >End of NANOG Digest, Vol 52, Issue 67
> >*************************************
> 
> 
> 
       



From lorell at hathcock.org  Tue May 29 17:10:38 2012
From: lorell at hathcock.org (Lorell Hathcock)
Date: Tue, 29 May 2012 17:10:38 -0500
Subject: trading bandwidth
In-Reply-To: <CBEB811F.34E28%carl@mobsource.com>
References: <SNT129-W194941D0E978BCE9EC0433A3050@phx.gbl>
 <CBEB811F.34E28%carl@mobsource.com>
Message-ID: <06d501cd3de7$e1179050$a346b0f0$@hathcock.org>

If you ever want a run down on how Enron did it (or didn't do it), there are
several on this list who can tell you all about it.

-----Original Message-----
From: carl gough [mobsource] [mailto:carl at mobsource.com] 
Sent: Tuesday, May 29, 2012 4:50 PM
To: Nabil Sharma; nanog at nanog.org
Subject: trading bandwidth

Thanks Nabil,  Bandwidth Trading is not a new concept, but to make it work
effectively it will have to address a couple of prerequisites to be
successful. A network of buyers and sellers has to be created, contracted
and connected for instant pricing, inventory management and delivery of a
defined and standardised service. Not a la enron of course, they traded
derivatives.

[carl gough] founder and CEO  +61 425 266 764 mobsource .com  defined by
benefits  not by technology Skype - mobsource Follow @mobsource Facebook -
mobsource



From:  Nabil Sharma <nabilsharma at hotmail.com>
Date:  Tue, 29 May 2012 14:06:41 +0000
To:  carl gough <carl at mobsource.com>, <nanog at nanog.org>
Subject:  RE: NANOG Digest, Vol 52, Issue 67

Mr Karl:

We use number of these service to improve delivery of our content to end
users.

Which service or services do you seek info for?

Sincerely,
Nabil

> Date: Tue, 29 May 2012 22:21:39 +1000
> Subject: Re: NANOG Digest, Vol 52, Issue 67
> From: carl at mobsource.com
> To: nanog at nanog.org
> 
> Does anyone have any intel on bandwidth trading in the usa?
> 
> [carl gough] founder and CEO  +61 425 266 764
> 
> mobsource .com  defined by benefits  not by technology Skype - 
> mobsource Follow @mobsource Facebook - mobsource
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 29/05/12 7:52 PM, "nanog-request at nanog.org" 
> <nanog-request at nanog.org>
> wrote:
> 
> >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. IPv6 security: New IETF I-Ds, slideware and videos of recent
> >      presentations, trainings, etc... (Fernando Gont)
> >   2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   4. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Jimmy Hess)
> >   5. Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >      (bmanning at vacation.karoshi.com)
> >   6. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Randy Bush)
> >   7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert)
> >   9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch)
> >
> >
> >---------------------------------------------------------------------
> >-
> >
> >Message: 1
> >Date: Mon, 28 May 2012 22:17:33 -0300
> >From: Fernando Gont <fernando at gont.com.ar>
> >To: NANOG <nanog at nanog.org>
> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent  
> >presentations, trainings, etc...
> >Message-ID: <4FC423AD.5000703 at gont.com.ar>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >Folks,
> >
> >* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting 
> >Against Rogue DHCPv6 Servers", which is meant to provide 
> >RA-Guard-like protection against rogue DHCPv6 servers. The I-D is
available at:
> ><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
> >Other IPv6 security I-Ds (such as,
> >draft-ietf-v6ops-ra-guard-implementation) have been revised. Please 
> >check them out at:
> ><http://www.si6networks.com/publications/ietf.html>
> >
> >* The slideware (and some videos!) of some of our recent 
> >presentations about IPv6 security are now available online. You can find
them at:
> ><http://www.si6networks.com/presentations/index.html>
> >
> >* We have also scheduled IPv6 hacking trainings in Paris (France) and 
> >Ghent (Belgium). You can find more details at:
> ><http://www.si6networks.com/index.html#conferences>
> >
> >Our Twitter: @SI6Networks
> >ipv6hackers mailing-list:
> ><http://lists.si6networks.com/listinfo/ipv6hackers/>
> >
> >Thanks!
> >
> >Best regards,
> >--
> >Fernando Gont
> >SI6 Networks
> >e-mail: fgont at si6networks.com
> >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >
> >
> >--
> >Fernando Gont
> >e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP 
> >Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >
> >
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 2
> >Date: Tue, 29 May 2012 12:38:23 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jay Ashworth <jra at baylink.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
> >
> >
> >In message
> ><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay 
> >Ashworth writ
> >es:
> >> ----- Original Message -----
> >> > From: "Mark Andrews" <marka at isc.org>
> >> 
> >> [ vix: ]
> >> > > > meanwhile isc continues to push for ubiquitous dnssec, 
> >> > > > through to the stub, to take this issue off the table for all 
> >> > > > people and all time.
> >> > > > (that's "the
> >> > > > real fix" for nxdomain remapping.)
> >> > >
> >> > > You really believe that the outcome of that will be "we can't 
> >> > > make some extra revenue off NXDOMAIN remapping because of 
> >> > > DNSSEC? Well, the hell with DNSSEC, then"?
> >> > 
> >> > People will route around ISP that do stupid things. They do so 
> >> > today. When your browers supports DANE there will be more 
> >> > incentive to ensure that DNSSEC does not break and more incentive 
> >> > to route around ISP's that do break DNSSEC.
> >> 
> >> My personal reaction to that, Mark, is to say that you *badly* 
> >>overestimate  the average Internet end-user (who make up, roughly, 
> >>80% of the endpoints,  in my jackleg estimation).
> >
> >Google's recursive nameservers see plenty of traffic.
> > 
> >> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that 
> >> > it is a real NXDOMAIN not one that is spoofed do the path to the 
> >> > ISP's resolver will be DNSSEC clean and they will be validating.
> >> 
> >> I'm not sure I understood that...
> >
> >        Authoritative server
> >                ^
> >      secure
> >         (DO=1 queries)
> > v
> >  ISP's validating recursive server
> >                ^
> >     insecure, redirect possible
> >         (DO=0 queries)
> >                v
> >           Stub clients.
> >
> >Putting it another way, the ISP doesn't want to be fooled even if it 
> >is fooling its customers.  The ISP can't allow it's recursive servers 
> >to get the wrong answers for irs.gov, picking a signed domain, as 
> >they would look silly for not validating when there is a simple way 
> >for them to be sure that they are not being spoofed.
> >
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't 
> >> > be a problem for ISP's that want to do nxdomain redirection. 
> >> > There still plenty of crappy DNS proxies in CPE routers to be 
> >> > replaced before you can just set DO=1 as a default without 
> >> > worrying about breaking DNS lookups. Even setting EDNS as a default
is a issue.
> >> 
> >> ...but that's probably because I don't understand DNSSEC well enough.
> >
> >The ISP <-> stub client path often has a additional piece in the path 
> >that is often a heap of steaming !@$! that doesn't do basic DNS let 
> >alone EDNS and DNSSEC.  For example the Netgear router at home 
> >doesn't support DNS over TCP which is basic DNS (I'm using it
> >as a access point not a router because of this).   It's this sort
> >of breakage that is stopping OS vendors changing defaults.  This can 
> >often be bypassed by forcing the resolver to use the ISP's 
> >nameservers directly but you need to know to do that.
> >
> >     ISP's validating recursive server
> >                ^
> >                v
> >            CPE Router (broken DNS proxy code)
> >                ^
> >                v
> >           Stub clients.
> >
> >You can also replace CPE Router with a broken firewall that is a 
> >steaming heap of !@#% when it comes to DNS packet inspection.  These 
> >are harder to bypass and require someone to fix the configuration to 
> >replace/upgrade the box.
> >
> >> > That said we are starting down the long path to making it EDNS a 
> >> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
> >> > turns set DO=1 as well. You don't get things fixed if the 
> >> > breakage is not visible.
> >> 
> >> We may be talking about different breakage here...
> >> 
> >> 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
> >> 
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 3
> >Date: Tue, 29 May 2012 12:47:10 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
> >
> >
> >In message
> ><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
> >, Jimmy Hess writes:
> >> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't 
> >> > be a problem for ISP's that want to do nxdomain redirection.  
> >> > There
> >> 
> >> Yeah.............
> >> Right now current _server_  implementations don't even have it 
> >> right, for properly implementing DNSSEC validation down to that 
> >> level, let alone the stubs below the server.
> >> 
> >> Many SME LANs utilize Windows-based endpoints, and commonly have 
> >> Windows-based DNS servers on the LAN, used by endpoints, where the 
> >> Windows DNS servers are set to forward queries to ISP recursive
> >> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
> >>  When Windows DNS server is configured to forward DNS queries to a 
> >> list of reasonable  recursive DNS servers,  the server sets  CD 
> >> (Check
> >> disabled) bit set, and the DO bit set  for all queries it sends; 
> >> there is no option to "support dnssec queries from smart stubs but 
> >> don't send queries from dumb stubs with CD".
> >
> >Well I'm trying to get this fixed at the protocol level for other 
> >reasons as explained in 
> >http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html
> >
> >draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last 
> >call and if you think always setting CD=1 when forwarding is bad for 
> >whatever reason I could do with some support.
> > 
> >> Also, there are by default no trust anchors, and _Every_ response 
> >> is treated as valid.  (In other words, CD bit and DO bits are set 
> >> in forwarded queries, but no validation occurs).
> >> It's kind of like having a SSL implementation that treats ALL SSL 
> >> certificates as valid, until and unless you take manual steps to 
> >> configure a CA list.
> >> 
> >> If you don't like this default and want to configure Windows DNS 
> >> with the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is 
> >> the only supported key type, and the current root signing key is 
> >> not of a compatible format.
> >> 
> >> Your "smart" stub can send a query to this broken DNSSEC 
> >> implementation with the DO bit set, for sure.
> >> 
> >> 
> >> 
> >> 
> >> > still plenty of crappy DNS proxies in CPE routers to be replaced 
> >> > before you can just set DO=1 as a default without worrying about 
> >> > breaking DNS lookups.  Even setting EDNS as a default is a issue.
> >> [snip]
> >> 
> >> I'm all for smart stubs   as long as  (1) They can get the data to them
> >> (2) They can get the proper logging/reporting to them,  E.g.   No
> >> "silent" upstream validate/discard;      No  upstream  silent "ignore
> >> the stub's requested CD bit and validate/discard anyways"
> >> and
> >> 
> >> (3) The validation path is intact for _dumb_ non-validating stubs too.
> >> 
> >> --
> >> -JH
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 28 May 2012 23:58:00 -0500
> >From: Jimmy Hess <mysidia at gmail.com>
> >To: David Conrad <drc at virtualized.org>
> >Cc: NANOG Mailing List <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs  
> >registrar/registry policies
> >Message-ID:
> > <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >On 5/28/12, David Conrad <drc at virtualized.org> wrote:
> >> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
> >>> I know few registry/registrars
> >>> which do not accept both (or all) name servers of domain name on 
> >>>same  subnet. They demand at least 1 DNS server should be on 
> >>>different subnet for  failover reasons (old thoughts).
> >> IMHO appropriately so.  The fact that anycast allows for multiple
> >> (potentially) geographically distributed machines to respond to DNS 
> >>queries  does not remove the value of having multiple prefixes for 
> >>DNS servers.
> >[snip]
> >It dramatically reduces the value, and meets the basic RFC 
> >requirement for geographically distributed DNS servers, although 
> >there are still routing issues that will impact all DNS servers to 
> >share a prefix It is more important that a domain registrar not 
> >refuse to register a domain,  or erroneously declare a valid listing
invalid.
> >
> >The purpose of using a registrar is to establish DNS delegation, not 
> >to validate your site's redundancy meets the absolute best possible 
> >practices for fault tolerance.
> >
> >Ideally certainly should have DNS servers under multiple prefixes -- 
> >and it seems a little bit silly to go through all the trouble of
> >implementing a complicated anycast geo. dist scheme,   while ignoring
> >a simpler failure mode.    It's your choice.
> >
> >It's not appropriately so for a registrar to say anything your 
> >choice; thats your network not theirs.  By the same token the 
> >registrar can't tell you not to alias all 3 IP addresses on different 
> >subnets to the same physical server.
> >
> >Again, it's ill-advised, but a "mistake"  that has nothing to do with 
> >the registrar's network or the registration service.
> >
> >--
> >-JH
> >
> >
> >
> >------------------------------
> >
> >Message: 5
> >Date: Tue, 29 May 2012 05:59:19 +0000
> >From: bmanning at vacation.karoshi.com
> >To: Mark Andrews <marka at isc.org>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529055919.GA23179 at vacation.karoshi.com.>
> >Content-Type: text/plain; charset=us-ascii
> >
> >On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> 
> >> Putting it another way, the ISP doesn't want to be fooled even if 
> >> it is fooling its customers.
> >
> > don't lie to us, but we lie to our customers.
> >
> > and you don't see a problem with this?
> >
> >/bill
> >
> >
> >
> >------------------------------
> >
> >Message: 6
> >Date: Tue, 29 May 2012 15:13:33 +0900
> >From: Randy Bush <randy at psg.com>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs  
> >registrar/registry policies
> >Message-ID: <m2txyzikfm.wl%randy at psg.com>
> >Content-Type: text/plain; charset=US-ASCII
> >
> >> It is more important that a domain registrar not refuse to register 
> >> a domain, or erroneously declare a valid listing invalid.
> >> 
> >> The purpose of using a registrar is to establish DNS delegation, 
> >> not to validate your site's redundancy meets the absolute best 
> >> possible practices for fault tolerance.
> >
> >just for my curiosity, where do you draw the line for technical 
> >compliance?  do the servers need to serve the zone?  does the served 
> >zone need to have the same NS RRset as the request and hence parent?
> >do the servers need to be able to answer compliant dns queries?  over 
> >tcp too?
> >
> >your first paragraph quoted above would seem to say that none of this 
> >is needed.  the registrar's job is to stick the delegation in the 
> >parent zone and actually functioning name service be damned.
> >
> >randy, a naggumite
> >
> >
> >
> >------------------------------
> >
> >Message: 7
> >Date: Tue, 29 May 2012 16:37:29 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: bmanning at vacation.karoshi.com
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
> >
> >
> >In message <20120529055919.GA23179 at vacation.karoshi.com.>,
> >bmanning at vacation.ka
> >roshi.com writes:
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> > 
> >> > Putting it another way, the ISP doesn't want to be fooled even if 
> >> > it is fooling its customers.
> >> 
> >> don't lie to us, but we lie to our customers.
> >> 
> >> and you don't see a problem with this?
> >
> >I didn't say I like it.  It may even be illegal in some juristictions 
> >for a ISP to do it without properly informing the customer and 
> >allowing them to opt in/out.  Doing it to yourself however can't be 
> >illegal.  In the end it is a tool and the method of deployment is 
> >often as important as whether you deploy it or not.
> >
> >It's a little like direct marketing via email.  If you have consent 
> >of the party being emailed it isn't spam.  If you don't have consent 
> >it is spam at least here in Australia.  Other juristictions have 
> >looser guidelines.
> >
> >Mark
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 8
> >Date: Mon, 28 May 2012 23:42:14 -0700
> >From: George Herbert <george.herbert at gmail.com>
> >To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> >
> >On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:
> >
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >>> 
> >>> Putting it another way, the ISP doesn't want to be fooled even if 
> >>> it is fooling its customers.
> >> 
> >>    don't lie to us, but we lie to our customers.
> >> 
> >>    and you don't see a problem with this?
> >> 
> >> /bill
> >
> >We tried saying no, we tried walking customers away, we tried not 
> >adding the feature, we tried shame, someone reputedly had dolls with 
> >pins in them.
> >
> >We lost.
> >
> >There is an endgame around that; when it's ready....
> >
> >
> >George William Herbert
> >Sent from my iPhone
> >
> >
> >------------------------------
> >
> >Message: 9
> >Date: Tue, 29 May 2012 10:51:54 +0100
> >From: Tony Finch <dot at dotat.at>
> >To: Randy Bush <randy at psg.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID:
> > <alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >Randy Bush <randy at psg.com> wrote:
> >>
> >> > When your browers supports DANE
> >>
> >> and a billion home nats support dnssec :(
> >
> >I expect there will be a depressingly large amount of DNS-over-TLS in 
> >the future in order to bypass broken ALGs.
> >
> >Tony.
> >--
> >f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> >Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate, 
> >occasionally very poor.
> >
> >
> >
> >End of NANOG Digest, Vol 52, Issue 67
> >*************************************
> 
> 
> 
       




From owen at delong.com  Tue May 29 17:10:04 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 May 2012 15:10:04 -0700
Subject: trading bandwidth
In-Reply-To: <CBEB811F.34E28%carl@mobsource.com>
References: <CBEB811F.34E28%carl@mobsource.com>
Message-ID: <F06244E4-AA0C-4C28-B915-2A8106164CE7@delong.com>

IIRC, the concept was first introduced by MCI and Enron to great fanfare
and subsequent graphic demonstrations of the destructive power of
unregulated markets controlled by people of limited moral fortitude.

Owen

On May 29, 2012, at 2:50 PM, carl gough [mobsource] wrote:

> Thanks Nabil,  Bandwidth Trading is not a new concept, but to make it
> work effectively it will have to address a couple of prerequisites to be
> successful. A network of buyers and sellers has to be created, contracted
> and connected for instant pricing, inventory management and delivery of a
> defined and standardised service. Not a la enron of course, they traded
> derivatives.
> 
> [carl gough] founder and CEO  +61 425 266 764
> mobsource .com  defined by benefits  not by technology
> Skype ? mobsource Follow @mobsource Facebook ? mobsource
> 
> 
> 
> From:  Nabil Sharma <nabilsharma at hotmail.com>
> Date:  Tue, 29 May 2012 14:06:41 +0000
> To:  carl gough <carl at mobsource.com>, <nanog at nanog.org>
> Subject:  RE: NANOG Digest, Vol 52, Issue 67
> 
> Mr Karl:
> 
> We use number of these service to improve delivery of our content to end
> users.
> 
> Which service or services do you seek info for?
> 
> Sincerely,
> Nabil
> 
>> Date: Tue, 29 May 2012 22:21:39 +1000
>> Subject: Re: NANOG Digest, Vol 52, Issue 67
>> From: carl at mobsource.com
>> To: nanog at nanog.org
>> 
>> Does anyone have any intel on bandwidth trading in the usa?
>> 
>> [carl gough] founder and CEO  +61 425 266 764
>> 
>> mobsource .com  defined by benefits  not by technology
>> Skype ? mobsource Follow @mobsource Facebook ? mobsource
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 29/05/12 7:52 PM, "nanog-request at nanog.org" <nanog-request at nanog.org>
>> wrote:
>> 
>>> 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. IPv6 security: New IETF I-Ds, slideware and videos of recent
>>>     presentations, trainings, etc... (Fernando Gont)
>>>  2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
>>>  3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
>>>  4. Re: DNS anycasting - multiple DNS servers on same subnet Vs
>>>     registrar/registry policies (Jimmy Hess)
>>>  5. Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>>     (bmanning at vacation.karoshi.com)
>>>  6. Re: DNS anycasting - multiple DNS servers on same subnet Vs
>>>     registrar/registry policies (Randy Bush)
>>>  7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
>>>  8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert)
>>>  9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch)
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> Message: 1
>>> Date: Mon, 28 May 2012 22:17:33 -0300
>>> From: Fernando Gont <fernando at gont.com.ar>
>>> To: NANOG <nanog at nanog.org>
>>> Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent
>>> presentations, trainings, etc...
>>> Message-ID: <4FC423AD.5000703 at gont.com.ar>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> Folks,
>>> 
>>> * We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
>>> Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
>>> protection against rogue DHCPv6 servers. The I-D is available at:
>>> <http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
>>> Other IPv6 security I-Ds (such as,
>>> draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
>>> check them out at:
>>> <http://www.si6networks.com/publications/ietf.html>
>>> 
>>> * The slideware (and some videos!) of some of our recent presentations
>>> about IPv6 security are now available online. You can find them at:
>>> <http://www.si6networks.com/presentations/index.html>
>>> 
>>> * We have also scheduled IPv6 hacking trainings in Paris (France) and
>>> Ghent (Belgium). You can find more details at:
>>> <http://www.si6networks.com/index.html#conferences>
>>> 
>>> Our Twitter: @SI6Networks
>>> ipv6hackers mailing-list:
>>> <http://lists.si6networks.com/listinfo/ipv6hackers/>
>>> 
>>> Thanks!
>>> 
>>> Best regards,
>>> -- 
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: fgont at si6networks.com
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Fernando Gont
>>> e-mail: fernando at gont.com.ar || fgont at si6networks.com
>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 2
>>> Date: Tue, 29 May 2012 12:38:23 +1000
>>> From: Mark Andrews <marka at isc.org>
>>> To: Jay Ashworth <jra at baylink.com>
>>> Cc: NANOG <nanog at nanog.org>
>>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>> Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
>>> 
>>> 
>>> In message 
>>> <23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay
>>> Ashworth writ
>>> es:
>>>> ----- Original Message -----
>>>>> From: "Mark Andrews" <marka at isc.org>
>>>> 
>>>> [ vix: ]
>>>>>>> meanwhile isc continues to push for ubiquitous dnssec, through to
>>>>>>> the stub,
>>>>>>> to take this issue off the table for all people and all time.
>>>>>>> (that's "the
>>>>>>> real fix" for nxdomain remapping.)
>>>>>> 
>>>>>> You really believe that the outcome of that will be "we can't make
>>>>>> some
>>>>>> extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the
>>>>>> hell
>>>>>> with DNSSEC, then"?
>>>>> 
>>>>> People will route around ISP that do stupid things. They do so
>>>>> today. When your browers supports DANE there will be more incentive
>>>>> to ensure that DNSSEC does not break and more incentive to route
>>>>> around ISP's that do break DNSSEC.
>>>> 
>>>> My personal reaction to that, Mark, is to say that you *badly*
>>>> overestimate
>>>> the average Internet end-user (who make up, roughly, 80% of the
>>>> endpoints,
>>>> in my jackleg estimation).
>>> 
>>> Google's recursive nameservers see plenty of traffic.
>>> 
>>>>> Even a ISP that is redirecting on NXDOMAIN wants to be sure that
>>>>> it is a real NXDOMAIN not one that is spoofed do the path to the
>>>>> ISP's resolver will be DNSSEC clean and they will be validating.
>>>> 
>>>> I'm not sure I understood that...
>>> 
>>>       Authoritative server
>>>               ^
>>>     secure
>>>        (DO=1 queries)
>>> v
>>> ISP's validating recursive server
>>>               ^
>>>    insecure, redirect possible
>>>        (DO=0 queries)
>>>               v
>>>          Stub clients.
>>> 
>>> Putting it another way, the ISP doesn't want to be fooled even if
>>> it is fooling its customers.  The ISP can't allow it's recursive
>>> servers to get the wrong answers for irs.gov, picking a signed
>>> domain, as they would look silly for not validating when there is
>>> a simple way for them to be sure that they are not being spoofed.
>>> 
>>>>> Until stub resolvers set DO=1 pretty much ubiquitously this won't
>>>>> be a problem for ISP's that want to do nxdomain redirection. There
>>>>> still plenty of crappy DNS proxies in CPE routers to be replaced
>>>>> before you can just set DO=1 as a default without worrying about
>>>>> breaking DNS lookups. Even setting EDNS as a default is a issue.
>>>> 
>>>> ...but that's probably because I don't understand DNSSEC well enough.
>>> 
>>> The ISP <-> stub client path often has a additional piece in the
>>> path that is often a heap of steaming !@$! that doesn't do basic
>>> DNS let alone EDNS and DNSSEC.  For example the Netgear router at
>>> home doesn't support DNS over TCP which is basic DNS (I'm using it
>>> as a access point not a router because of this).   It's this sort
>>> of breakage that is stopping OS vendors changing defaults.  This
>>> can often be bypassed by forcing the resolver to use the ISP's
>>> nameservers directly but you need to know to do that.
>>> 
>>>    ISP's validating recursive server
>>>               ^
>>>               v
>>>           CPE Router (broken DNS proxy code)
>>>               ^
>>>               v
>>>          Stub clients.
>>> 
>>> You can also replace CPE Router with a broken firewall that is a
>>> steaming heap of !@#% when it comes to DNS packet inspection.  These
>>> are harder to bypass and require someone to fix the configuration
>>> to replace/upgrade the box.
>>> 
>>>>> That said we are starting down the long path to making it EDNS a
>>>>> default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
>>>>> turns set DO=1 as well. You don't get things fixed if the breakage
>>>>> is not visible.
>>>> 
>>>> We may be talking about different breakage here...
>>>> 
>>>> 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
>>>> 
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 3
>>> Date: Tue, 29 May 2012 12:47:10 +1000
>>> From: Mark Andrews <marka at isc.org>
>>> To: Jimmy Hess <mysidia at gmail.com>
>>> Cc: NANOG <nanog at nanog.org>
>>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>> Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
>>> 
>>> 
>>> In message 
>>> <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
>>> , Jimmy Hess writes:
>>>> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
>>>>> Until stub resolvers set DO=1 pretty much ubiquitously this won't
>>>>> be a problem for ISP's that want to do nxdomain redirection.  There
>>>> 
>>>> Yeah.............
>>>> Right now current _server_  implementations don't even have it right,
>>>> for properly implementing DNSSEC validation down to that level, let
>>>> alone the stubs below the server.
>>>> 
>>>> Many SME LANs utilize Windows-based endpoints, and commonly have
>>>> Windows-based DNS servers on the LAN, used by endpoints, where the
>>>> Windows DNS servers are set to forward queries to ISP recursive
>>>> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
>>>> When Windows DNS server is configured to forward DNS queries to a
>>>> list of reasonable  recursive DNS servers,  the server sets  CD (Check
>>>> disabled) bit set, and the DO bit set  for all queries it sends;
>>>> there is no option to "support dnssec queries from smart stubs but
>>>> don't send queries from dumb stubs with CD".
>>> 
>>> Well I'm trying to get this fixed at the protocol level for other
>>> reasons as explained in
>>> http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html
>>> 
>>> draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
>>> call and if you think always setting CD=1 when forwarding is bad for
>>> whatever reason I could do with some support.
>>> 
>>>> Also, there are by default no trust anchors, and _Every_ response is
>>>> treated as valid.  (In other words, CD bit and DO bits are set in
>>>> forwarded queries, but no validation occurs).
>>>> It's kind of like having a SSL implementation that treats ALL SSL
>>>> certificates as valid, until and unless you take manual steps to
>>>> configure a CA list.
>>>> 
>>>> If you don't like this default and want to configure Windows DNS with
>>>> the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
>>>> supported key type, and the current root signing key is not of a
>>>> compatible format.
>>>> 
>>>> Your "smart" stub can send a query to this broken DNSSEC
>>>> implementation with the DO bit set, for sure.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> still plenty of crappy DNS proxies in CPE routers to be replaced
>>>>> before you can just set DO=1 as a default without worrying about
>>>>> breaking DNS lookups.  Even setting EDNS as a default is a issue.
>>>> [snip]
>>>> 
>>>> I'm all for smart stubs   as long as  (1) They can get the data to them
>>>> (2) They can get the proper logging/reporting to them,  E.g.   No
>>>> "silent" upstream validate/discard;      No  upstream  silent "ignore
>>>> the stub's requested CD bit and validate/discard anyways"
>>>> and
>>>> 
>>>> (3) The validation path is intact for _dumb_ non-validating stubs too.
>>>> 
>>>> --
>>>> -JH
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 4
>>> Date: Mon, 28 May 2012 23:58:00 -0500
>>> From: Jimmy Hess <mysidia at gmail.com>
>>> To: David Conrad <drc at virtualized.org>
>>> Cc: NANOG Mailing List <nanog at nanog.org>
>>> Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
>>> registrar/registry policies
>>> Message-ID:
>>> <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> On 5/28/12, David Conrad <drc at virtualized.org> wrote:
>>>> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
>>>>> I know few registry/registrars
>>>>> which do not accept both (or all) name servers of domain name on same
>>>>> subnet. They demand at least 1 DNS server should be on different
>>>>> subnet for
>>>>> failover reasons (old thoughts).
>>>> IMHO appropriately so.  The fact that anycast allows for multiple
>>>> (potentially) geographically distributed machines to respond to DNS
>>>> queries
>>>> does not remove the value of having multiple prefixes for DNS servers.
>>> [snip]
>>> It dramatically reduces the value, and meets the basic RFC requirement
>>> for geographically distributed DNS servers, although there are still
>>> routing issues that will impact all DNS servers to share a prefix
>>> It is more important that a domain registrar not refuse to register a
>>> domain,  or erroneously declare a valid listing invalid.
>>> 
>>> The purpose of using a registrar is to establish DNS delegation, not
>>> to validate your site's redundancy meets the absolute best possible
>>> practices for fault tolerance.
>>> 
>>> Ideally certainly should have DNS servers under multiple prefixes --
>>> and it seems a little bit silly to go through all the trouble of
>>> implementing a complicated anycast geo. dist scheme,   while ignoring
>>> a simpler failure mode.    It's your choice.
>>> 
>>> It's not appropriately so for a registrar to say anything your choice;
>>> thats your network
>>> not theirs.  By the same token the registrar can't tell you not to
>>> alias all 3 IP addresses on
>>> different subnets to the same physical server.
>>> 
>>> Again, it's ill-advised, but a "mistake"  that has nothing to do with
>>> the registrar's network or the registration service.
>>> 
>>> --
>>> -JH
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 5
>>> Date: Tue, 29 May 2012 05:59:19 +0000
>>> From: bmanning at vacation.karoshi.com
>>> To: Mark Andrews <marka at isc.org>
>>> Cc: NANOG <nanog at nanog.org>
>>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>> Message-ID: <20120529055919.GA23179 at vacation.karoshi.com.>
>>> Content-Type: text/plain; charset=us-ascii
>>> 
>>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>>>> 
>>>> Putting it another way, the ISP doesn't want to be fooled even if
>>>> it is fooling its customers.
>>> 
>>> don't lie to us, but we lie to our customers.
>>> 
>>> and you don't see a problem with this?
>>> 
>>> /bill
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 6
>>> Date: Tue, 29 May 2012 15:13:33 +0900
>>> From: Randy Bush <randy at psg.com>
>>> To: Jimmy Hess <mysidia at gmail.com>
>>> Cc: North American Network Operators' Group <nanog at nanog.org>
>>> Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
>>> registrar/registry policies
>>> Message-ID: <m2txyzikfm.wl%randy at psg.com>
>>> Content-Type: text/plain; charset=US-ASCII
>>> 
>>>> It is more important that a domain registrar not refuse to register a
>>>> domain, or erroneously declare a valid listing invalid.
>>>> 
>>>> The purpose of using a registrar is to establish DNS delegation, not
>>>> to validate your site's redundancy meets the absolute best possible
>>>> practices for fault tolerance.
>>> 
>>> just for my curiosity, where do you draw the line for technical
>>> compliance?  do the servers need to serve the zone?  does the served
>>> zone need to have the same NS RRset as the request and hence parent?
>>> do the servers need to be able to answer compliant dns queries?  over
>>> tcp too?
>>> 
>>> your first paragraph quoted above would seem to say that none of this is
>>> needed.  the registrar's job is to stick the delegation in the parent
>>> zone and actually functioning name service be damned.
>>> 
>>> randy, a naggumite
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 7
>>> Date: Tue, 29 May 2012 16:37:29 +1000
>>> From: Mark Andrews <marka at isc.org>
>>> To: bmanning at vacation.karoshi.com
>>> Cc: NANOG <nanog at nanog.org>
>>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>> Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
>>> 
>>> 
>>> In message <20120529055919.GA23179 at vacation.karoshi.com.>,
>>> bmanning at vacation.ka
>>> roshi.com writes:
>>>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>>>>> 
>>>>> Putting it another way, the ISP doesn't want to be fooled even if
>>>>> it is fooling its customers.
>>>> 
>>>> don't lie to us, but we lie to our customers.
>>>> 
>>>> and you don't see a problem with this?
>>> 
>>> I didn't say I like it.  It may even be illegal in some juristictions
>>> for a ISP to do it without properly informing the customer and
>>> allowing them to opt in/out.  Doing it to yourself however can't
>>> be illegal.  In the end it is a tool and the method of deployment
>>> is often as important as whether you deploy it or not.
>>> 
>>> It's a little like direct marketing via email.  If you have consent
>>> of the party being emailed it isn't spam.  If you don't have consent
>>> it is spam at least here in Australia.  Other juristictions have
>>> looser guidelines.
>>> 
>>> Mark
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 8
>>> Date: Mon, 28 May 2012 23:42:14 -0700
>>> From: George Herbert <george.herbert at gmail.com>
>>> To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
>>> Cc: NANOG <nanog at nanog.org>
>>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>> Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
>>> Content-Type: text/plain; charset=us-ascii
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:
>>> 
>>>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
>>>>> 
>>>>> Putting it another way, the ISP doesn't want to be fooled even if
>>>>> it is fooling its customers.
>>>> 
>>>>   don't lie to us, but we lie to our customers.
>>>> 
>>>>   and you don't see a problem with this?
>>>> 
>>>> /bill
>>> 
>>> We tried saying no, we tried walking customers away, we tried not adding
>>> the feature, we tried shame, someone reputedly had dolls with pins in
>>> them.
>>> 
>>> We lost.
>>> 
>>> There is an endgame around that; when it's ready....
>>> 
>>> 
>>> George William Herbert
>>> Sent from my iPhone
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 9
>>> Date: Tue, 29 May 2012 10:51:54 +0100
>>> From: Tony Finch <dot at dotat.at>
>>> To: Randy Bush <randy at psg.com>
>>> Cc: North American Network Operators' Group <nanog at nanog.org>
>>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>>> Message-ID:
>>> <alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
>>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>> 
>>> Randy Bush <randy at psg.com> wrote:
>>>> 
>>>>> When your browers supports DANE
>>>> 
>>>> and a billion home nats support dnssec :(
>>> 
>>> I expect there will be a depressingly large amount of DNS-over-TLS in the
>>> future in order to bypass broken ALGs.
>>> 
>>> Tony.
>>> -- 
>>> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
>>> Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate,
>>> occasionally very poor.
>>> 
>>> 
>>> 
>>> End of NANOG Digest, Vol 52, Issue 67
>>> *************************************
>> 
>> 
>> 
> 
> 



From carlos at race.com  Tue May 29 17:20:01 2012
From: carlos at race.com (Carlos Alcantar)
Date: Tue, 29 May 2012 22:20:01 +0000
Subject: trading bandwidth
In-Reply-To: <06d501cd3de7$e1179050$a346b0f0$@hathcock.org>
Message-ID: <CBEA9986.7570A%carlos@race.com>

Doesn't Arbinet have some sort of trading system like this currently?

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Lorell Hathcock <lorell at hathcock.org>
Date: Tue, 29 May 2012 17:10:38 -0500
To: "'carl gough [mobsource]'" <carl at mobsource.com>, 'Nabil Sharma'
<nabilsharma at hotmail.com>, "nanog at nanog.org" <nanog at nanog.org>
Subject: RE: trading bandwidth

If you ever want a run down on how Enron did it (or didn't do it), there
are
several on this list who can tell you all about it.

-----Original Message-----
From: carl gough [mobsource] [mailto:carl at mobsource.com]
Sent: Tuesday, May 29, 2012 4:50 PM
To: Nabil Sharma; nanog at nanog.org
Subject: trading bandwidth

Thanks Nabil,  Bandwidth Trading is not a new concept, but to make it work
effectively it will have to address a couple of prerequisites to be
successful. A network of buyers and sellers has to be created, contracted
and connected for instant pricing, inventory management and delivery of a
defined and standardised service. Not a la enron of course, they traded
derivatives.

[carl gough] founder and CEO  +61 425 266 764 mobsource .com  defined by
benefits  not by technology Skype - mobsource Follow @mobsource Facebook -
mobsource



From:  Nabil Sharma <nabilsharma at hotmail.com>
Date:  Tue, 29 May 2012 14:06:41 +0000
To:  carl gough <carl at mobsource.com>, <nanog at nanog.org>
Subject:  RE: NANOG Digest, Vol 52, Issue 67

Mr Karl:

We use number of these service to improve delivery of our content to end
users.

Which service or services do you seek info for?

Sincerely,
Nabil

> Date: Tue, 29 May 2012 22:21:39 +1000
> Subject: Re: NANOG Digest, Vol 52, Issue 67
> From: carl at mobsource.com
> To: nanog at nanog.org
> 
> Does anyone have any intel on bandwidth trading in the usa?
> 
> [carl gough] founder and CEO  +61 425 266 764
> 
> mobsource .com  defined by benefits  not by technology Skype -
> mobsource Follow @mobsource Facebook - mobsource
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 29/05/12 7:52 PM, "nanog-request at nanog.org"
> <nanog-request at nanog.org>
> wrote:
> 
> >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. IPv6 security: New IETF I-Ds, slideware and videos of recent
> >      presentations, trainings, etc... (Fernando Gont)
> >   2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   4. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Jimmy Hess)
> >   5. Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >      (bmanning at vacation.karoshi.com)
> >   6. Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >      registrar/registry policies (Randy Bush)
> >   7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews)
> >   8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert)
> >   9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch)
> >
> >
> >---------------------------------------------------------------------
> >-
> >
> >Message: 1
> >Date: Mon, 28 May 2012 22:17:33 -0300
> >From: Fernando Gont <fernando at gont.com.ar>
> >To: NANOG <nanog at nanog.org>
> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent
> >presentations, trainings, etc...
> >Message-ID: <4FC423AD.5000703 at gont.com.ar>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >Folks,
> >
> >* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
> >Against Rogue DHCPv6 Servers", which is meant to provide
> >RA-Guard-like protection against rogue DHCPv6 servers. The I-D is
available at:
> ><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
> >Other IPv6 security I-Ds (such as,
> >draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
> >check them out at:
> ><http://www.si6networks.com/publications/ietf.html>
> >
> >* The slideware (and some videos!) of some of our recent
> >presentations about IPv6 security are now available online. You can find
them at:
> ><http://www.si6networks.com/presentations/index.html>
> >
> >* We have also scheduled IPv6 hacking trainings in Paris (France) and
> >Ghent (Belgium). You can find more details at:
> ><http://www.si6networks.com/index.html#conferences>
> >
> >Our Twitter: @SI6Networks
> >ipv6hackers mailing-list:
> ><http://lists.si6networks.com/listinfo/ipv6hackers/>
> >
> >Thanks!
> >
> >Best regards,
> >--
> >Fernando Gont
> >SI6 Networks
> >e-mail: fgont at si6networks.com
> >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >
> >
> >--
> >Fernando Gont
> >e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP
> >Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >
> >
> >
> >
> >
> >
> >------------------------------
> >
> >Message: 2
> >Date: Tue, 29 May 2012 12:38:23 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jay Ashworth <jra at baylink.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
> >
> >
> >In message
> ><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay
> >Ashworth writ
> >es:
> >> ----- Original Message -----
> >> > From: "Mark Andrews" <marka at isc.org>
> >> 
> >> [ vix: ]
> >> > > > meanwhile isc continues to push for ubiquitous dnssec,
> >> > > > through to the stub, to take this issue off the table for all
> >> > > > people and all time.
> >> > > > (that's "the
> >> > > > real fix" for nxdomain remapping.)
> >> > >
> >> > > You really believe that the outcome of that will be "we can't
> >> > > make some extra revenue off NXDOMAIN remapping because of
> >> > > DNSSEC? Well, the hell with DNSSEC, then"?
> >> > 
> >> > People will route around ISP that do stupid things. They do so
> >> > today. When your browers supports DANE there will be more
> >> > incentive to ensure that DNSSEC does not break and more incentive
> >> > to route around ISP's that do break DNSSEC.
> >> 
> >> My personal reaction to that, Mark, is to say that you *badly*
> >>overestimate  the average Internet end-user (who make up, roughly,
> >>80% of the endpoints,  in my jackleg estimation).
> >
> >Google's recursive nameservers see plenty of traffic.
> > 
> >> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that
> >> > it is a real NXDOMAIN not one that is spoofed do the path to the
> >> > ISP's resolver will be DNSSEC clean and they will be validating.
> >> 
> >> I'm not sure I understood that...
> >
> >        Authoritative server
> >                ^
> >      secure
> >         (DO=1 queries)
> > v
> >  ISP's validating recursive server
> >                ^
> >     insecure, redirect possible
> >         (DO=0 queries)
> >                v
> >           Stub clients.
> >
> >Putting it another way, the ISP doesn't want to be fooled even if it
> >is fooling its customers.  The ISP can't allow it's recursive servers
> >to get the wrong answers for irs.gov, picking a signed domain, as
> >they would look silly for not validating when there is a simple way
> >for them to be sure that they are not being spoofed.
> >
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> >> > be a problem for ISP's that want to do nxdomain redirection.
> >> > There still plenty of crappy DNS proxies in CPE routers to be
> >> > replaced before you can just set DO=1 as a default without
> >> > worrying about breaking DNS lookups. Even setting EDNS as a default
is a issue.
> >> 
> >> ...but that's probably because I don't understand DNSSEC well enough.
> >
> >The ISP <-> stub client path often has a additional piece in the path
> >that is often a heap of steaming !@$! that doesn't do basic DNS let
> >alone EDNS and DNSSEC.  For example the Netgear router at home
> >doesn't support DNS over TCP which is basic DNS (I'm using it
> >as a access point not a router because of this).   It's this sort
> >of breakage that is stopping OS vendors changing defaults.  This can
> >often be bypassed by forcing the resolver to use the ISP's
> >nameservers directly but you need to know to do that.
> >
> >     ISP's validating recursive server
> >                ^
> >                v
> >            CPE Router (broken DNS proxy code)
> >                ^
> >                v
> >           Stub clients.
> >
> >You can also replace CPE Router with a broken firewall that is a
> >steaming heap of !@#% when it comes to DNS packet inspection.  These
> >are harder to bypass and require someone to fix the configuration to
> >replace/upgrade the box.
> >
> >> > That said we are starting down the long path to making it EDNS a
> >> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace"
> >> > turns set DO=1 as well. You don't get things fixed if the
> >> > breakage is not visible.
> >> 
> >> We may be talking about different breakage here...
> >> 
> >> 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
> >> 
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 3
> >Date: Tue, 29 May 2012 12:47:10 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
> >
> >
> >In message
> ><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
> >, Jimmy Hess writes:
> >> On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't
> >> > be a problem for ISP's that want to do nxdomain redirection.
> >> > There
> >> 
> >> Yeah.............
> >> Right now current _server_  implementations don't even have it
> >> right, for properly implementing DNSSEC validation down to that
> >> level, let alone the stubs below the server.
> >> 
> >> Many SME LANs utilize Windows-based endpoints, and commonly have
> >> Windows-based DNS servers on the LAN, used by endpoints, where the
> >> Windows DNS servers are set to forward queries to ISP recursive
> >> servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
> >>  When Windows DNS server is configured to forward DNS queries to a
> >> list of reasonable  recursive DNS servers,  the server sets  CD
> >> (Check
> >> disabled) bit set, and the DO bit set  for all queries it sends;
> >> there is no option to "support dnssec queries from smart stubs but
> >> don't send queries from dumb stubs with CD".
> >
> >Well I'm trying to get this fixed at the protocol level for other
> >reasons as explained in
> >http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html
> >
> >draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
> >call and if you think always setting CD=1 when forwarding is bad for
> >whatever reason I could do with some support.
> > 
> >> Also, there are by default no trust anchors, and _Every_ response
> >> is treated as valid.  (In other words, CD bit and DO bits are set
> >> in forwarded queries, but no validation occurs).
> >> It's kind of like having a SSL implementation that treats ALL SSL
> >> certificates as valid, until and unless you take manual steps to
> >> configure a CA list.
> >> 
> >> If you don't like this default and want to configure Windows DNS
> >> with the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is
> >> the only supported key type, and the current root signing key is
> >> not of a compatible format.
> >> 
> >> Your "smart" stub can send a query to this broken DNSSEC
> >> implementation with the DO bit set, for sure.
> >> 
> >> 
> >> 
> >> 
> >> > still plenty of crappy DNS proxies in CPE routers to be replaced
> >> > before you can just set DO=1 as a default without worrying about
> >> > breaking DNS lookups.  Even setting EDNS as a default is a issue.
> >> [snip]
> >> 
> >> I'm all for smart stubs   as long as  (1) They can get the data to
>them
> >> (2) They can get the proper logging/reporting to them,  E.g.   No
> >> "silent" upstream validate/discard;      No  upstream  silent "ignore
> >> the stub's requested CD bit and validate/discard anyways"
> >> and
> >> 
> >> (3) The validation path is intact for _dumb_ non-validating stubs too.
> >> 
> >> --
> >> -JH
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 28 May 2012 23:58:00 -0500
> >From: Jimmy Hess <mysidia at gmail.com>
> >To: David Conrad <drc at virtualized.org>
> >Cc: NANOG Mailing List <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >registrar/registry policies
> >Message-ID:
> > <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >On 5/28/12, David Conrad <drc at virtualized.org> wrote:
> >> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote:
> >>> I know few registry/registrars
> >>> which do not accept both (or all) name servers of domain name on
> >>>same  subnet. They demand at least 1 DNS server should be on
> >>>different subnet for  failover reasons (old thoughts).
> >> IMHO appropriately so.  The fact that anycast allows for multiple
> >> (potentially) geographically distributed machines to respond to DNS
> >>queries  does not remove the value of having multiple prefixes for
> >>DNS servers.
> >[snip]
> >It dramatically reduces the value, and meets the basic RFC
> >requirement for geographically distributed DNS servers, although
> >there are still routing issues that will impact all DNS servers to
> >share a prefix It is more important that a domain registrar not
> >refuse to register a domain,  or erroneously declare a valid listing
invalid.
> >
> >The purpose of using a registrar is to establish DNS delegation, not
> >to validate your site's redundancy meets the absolute best possible
> >practices for fault tolerance.
> >
> >Ideally certainly should have DNS servers under multiple prefixes --
> >and it seems a little bit silly to go through all the trouble of
> >implementing a complicated anycast geo. dist scheme,   while ignoring
> >a simpler failure mode.    It's your choice.
> >
> >It's not appropriately so for a registrar to say anything your
> >choice; thats your network not theirs.  By the same token the
> >registrar can't tell you not to alias all 3 IP addresses on different
> >subnets to the same physical server.
> >
> >Again, it's ill-advised, but a "mistake"  that has nothing to do with
> >the registrar's network or the registration service.
> >
> >--
> >-JH
> >
> >
> >
> >------------------------------
> >
> >Message: 5
> >Date: Tue, 29 May 2012 05:59:19 +0000
> >From: bmanning at vacation.karoshi.com
> >To: Mark Andrews <marka at isc.org>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529055919.GA23179 at vacation.karoshi.com.>
> >Content-Type: text/plain; charset=us-ascii
> >
> >On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> 
> >> Putting it another way, the ISP doesn't want to be fooled even if
> >> it is fooling its customers.
> >
> > don't lie to us, but we lie to our customers.
> >
> > and you don't see a problem with this?
> >
> >/bill
> >
> >
> >
> >------------------------------
> >
> >Message: 6
> >Date: Tue, 29 May 2012 15:13:33 +0900
> >From: Randy Bush <randy at psg.com>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
> >registrar/registry policies
> >Message-ID: <m2txyzikfm.wl%randy at psg.com>
> >Content-Type: text/plain; charset=US-ASCII
> >
> >> It is more important that a domain registrar not refuse to register
> >> a domain, or erroneously declare a valid listing invalid.
> >> 
> >> The purpose of using a registrar is to establish DNS delegation,
> >> not to validate your site's redundancy meets the absolute best
> >> possible practices for fault tolerance.
> >
> >just for my curiosity, where do you draw the line for technical
> >compliance?  do the servers need to serve the zone?  does the served
> >zone need to have the same NS RRset as the request and hence parent?
> >do the servers need to be able to answer compliant dns queries?  over
> >tcp too?
> >
> >your first paragraph quoted above would seem to say that none of this
> >is needed.  the registrar's job is to stick the delegation in the
> >parent zone and actually functioning name service be damned.
> >
> >randy, a naggumite
> >
> >
> >
> >------------------------------
> >
> >Message: 7
> >Date: Tue, 29 May 2012 16:37:29 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: bmanning at vacation.karoshi.com
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
> >
> >
> >In message <20120529055919.GA23179 at vacation.karoshi.com.>,
> >bmanning at vacation.ka
> >roshi.com writes:
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >> > 
> >> > Putting it another way, the ISP doesn't want to be fooled even if
> >> > it is fooling its customers.
> >> 
> >> don't lie to us, but we lie to our customers.
> >> 
> >> and you don't see a problem with this?
> >
> >I didn't say I like it.  It may even be illegal in some juristictions
> >for a ISP to do it without properly informing the customer and
> >allowing them to opt in/out.  Doing it to yourself however can't be
> >illegal.  In the end it is a tool and the method of deployment is
> >often as important as whether you deploy it or not.
> >
> >It's a little like direct marketing via email.  If you have consent
> >of the party being emailed it isn't spam.  If you don't have consent
> >it is spam at least here in Australia.  Other juristictions have
> >looser guidelines.
> >
> >Mark
> >--
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 8
> >Date: Mon, 28 May 2012 23:42:14 -0700
> >From: George Herbert <george.herbert at gmail.com>
> >To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> >
> >On May 28, 2012, at 22:59, bmanning at vacation.karoshi.com wrote:
> >
> >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote:
> >>> 
> >>> Putting it another way, the ISP doesn't want to be fooled even if
> >>> it is fooling its customers.
> >> 
> >>    don't lie to us, but we lie to our customers.
> >> 
> >>    and you don't see a problem with this?
> >> 
> >> /bill
> >
> >We tried saying no, we tried walking customers away, we tried not
> >adding the feature, we tried shame, someone reputedly had dolls with
> >pins in them.
> >
> >We lost.
> >
> >There is an endgame around that; when it's ready....
> >
> >
> >George William Herbert
> >Sent from my iPhone
> >
> >
> >------------------------------
> >
> >Message: 9
> >Date: Tue, 29 May 2012 10:51:54 +0100
> >From: Tony Finch <dot at dotat.at>
> >To: Randy Bush <randy at psg.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID:
> > <alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >Randy Bush <randy at psg.com> wrote:
> >>
> >> > When your browers supports DANE
> >>
> >> and a billion home nats support dnssec :(
> >
> >I expect there will be a depressingly large amount of DNS-over-TLS in
> >the future in order to bypass broken ALGs.
> >
> >Tony.
> >--
> >f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> >Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate,
> >occasionally very poor.
> >
> >
> >
> >End of NANOG Digest, Vol 52, Issue 67
> >*************************************
> 
> 
> 
       







From brett at the-watsons.org  Tue May 29 17:54:19 2012
From: brett at the-watsons.org (Brett Watson)
Date: Tue, 29 May 2012 15:54:19 -0700
Subject: trading bandwidth
In-Reply-To: <F06244E4-AA0C-4C28-B915-2A8106164CE7@delong.com>
References: <CBEB811F.34E28%carl@mobsource.com>
 <F06244E4-AA0C-4C28-B915-2A8106164CE7@delong.com>
Message-ID: <5BD697A0-C302-42E6-8F66-822A21F2559D@the-watsons.org>


On May 29, 2012, at 3:10 PM, Owen DeLong wrote:

> IIRC, the concept was first introduced by MCI and Enron to great fanfare
> and subsequent graphic demonstrations of the destructive power of
> unregulated markets controlled by people of limited moral fortitude.

Not ALL of us were of limited moral fortitude! :) I still think the concept was fundamentally sound, and I certainly meant well, but I was in a position of very little power so what I said generally didn't carry a lot of weight in that environment.

-b

From randy at psg.com  Tue May 29 18:00:04 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 30 May 2012 08:00:04 +0900
Subject: ISPs and full packet inspection
In-Reply-To: <4391984312dcdd7f26a85a46729309f9.squirrel@vienna.hostgo.com>
References: <4391984312dcdd7f26a85a46729309f9.squirrel@vienna.hostgo.com>
Message-ID: <m24nqyioej.wl%randy@psg.com>

> I am a little surprised no one has referenced Wired's recent article
> about Libya's Internet Surveillance systems:
> 
> http://www.wired.com/threatlevel/2012/05/ff_libya/all/1

and that of AT&T doing the same, alledgedly illegally, for the USG.

randy


From nabilsharma at hotmail.com  Tue May 29 19:34:06 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Wed, 30 May 2012 00:34:06 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <CBEA5441.6230C%jason_livingood@cable.comcast.com>
References: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>,
 <CBEA5441.6230C%jason_livingood@cable.comcast.com>
Message-ID: <SNT129-W27BAFEED03374FB1A68E24A30A0@phx.gbl>


Mr. Jason:
Thank u for the reply, very informative URL. Understood on the cap, but how long it will remain not enforced is a good guess!
What I am trying to is have Comcast mark our IP ranges with QoS, so downloads or congestion inside the household will not degrade performance.
You can see at http://ber.gd/post/23025893856/comcast-traffic-prioritization that this is the configuration for Microsoft Xbox. Do you know what this service is called and who at Comcast can help me with the commercials?
Sincerely,
Nabil

From: Jason_Livingood at cable.comcast.com
To: nabilsharma at hotmail.com; nanog at nanog.org
Subject: Re: Comcast Service for Non-Cap Bandwidth
Date: Tue, 29 May 2012 14:25:10 +0000







Mail formatting issue with my mail client again? Note that the 1st paragraph was quoted from Nabil...




>I generate http test stream with DSCP code point 5 to match the Xbox service, 
> however Comcast is rewriting the packets as CS 1, even when serving out a 
> server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft
> is using, it is not the regular paid peering.



[JL] Yeah, that won't work but that marking is just for byte counting (which per my other not does not really have any effect now anyway since the 250GB policy was suspended. See also

http://blog.comcast.com/2012/05/the-facts-about-xfinity-tv-and-xbox-360-comcast-is-not-prioritizing.html



For peering & interconnect, see:
http://www.comcast.com/peering/?SCRedirect=true
http://www.comcast.com/dedicatedinternet/?SCRedirect=true



Thanks
Jason


 		 	   		  

From nabilsharma at hotmail.com  Tue May 29 19:38:08 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Wed, 30 May 2012 00:38:08 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <20120529175230.GF8479@hiwaay.net>
References: <CAJAdsD=FX3urOSb4Dqg05Ca6=a278AO8nErnhH5H5O6+o3XmBA@mail.gmail.com>,
 <SNT129-W603297122BAE6387ED6D16A3040@phx.gbl>,
 <20120529175230.GF8479@hiwaay.net>
Message-ID: <SNT129-W342BD8D3A4F43567EB5292A30A0@phx.gbl>

Adams:

I would like to understand how this works.  I see the Comcast VOD servers for San Francisco are in Seattle, higher round trip and route mile than our servers at Soft Layer in San Jose.  We are costing Comcast less money than their own content.

Signed,
Nabil

> Date: Tue, 29 May 2012 12:52:30 -0500
> From: cmadams at hiwaay.net
> To: nanog at nanog.org
> Subject: Re: Comcast Service for Non-Cap Bandwidth
> 
> Once upon a time, Nabil Sharma <nabilsharma at hotmail.com> said:
> > I generate http test stream with DSCP code point 5 to match the Xbox service, however Comcast is rewriting the packets as CS 1, even when serving out a server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft is using, it is not the regular paid peering.
> 
> It is my understanding that the Xbox On-Demand streaming is just talking
> to the regular On-Demand servers at the head-end (just like On-Demand
> over QAM works); the traffic has nothing to do with Microsoft's network,
> peering, etc.  That's why Comcast doesn't count it against any caps; it
> isn't transit traffic, it is local.
> -- 
> 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 nabilsharma at hotmail.com  Tue May 29 19:41:43 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Wed, 30 May 2012 00:41:43 +0000
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <CAJAdsD=gQzqKcjx4D6vHBe3Ojm2SC876nf5ZGDtpzCTKAJwg5g@mail.gmail.com>
References: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>,
 <CBEA5441.6230C%jason_livingood@cable.comcast.com>,
 <CAJAdsD=gQzqKcjx4D6vHBe3Ojm2SC876nf5ZGDtpzCTKAJwg5g@mail.gmail.com>
Message-ID: <SNT129-W24DF215EE2E337E115C60DA30A0@phx.gbl>


PC:
I also wish to know how much the Comcast "Paid Peering" service costs, and if this is an option that can get us the delivery we require.
Could you please help me to understand why it is protected by NDA? Is there anyone on the NANOG list who can share this pricing with me in private?
Sincerely,
Nabil

Date: Tue, 29 May 2012 11:18:37 -0500
Subject: Re: Comcast Service for Non-Cap Bandwidth
From: paul4004 at gmail.com
To: Jason_Livingood at cable.comcast.com
CC: nabilsharma at hotmail.com; nanog at nanog.org

Hi Nabil,

DSCP tagging on inter-domain internet traffic is not expected to work (I wouldn't expect this to work at any ISP, quite frankly, absent some very special arrangements).

>From reading the article in the link below, it sounds like they are using DSCP to ensure when a user has maxed their bandwidth allotment (say, downloading the latest WOW update), that TV viewing is not disrupted.  Instead of providing QOS on it to do this, it seems they provide you an included-with-the-service additional bandwidth allotment/connection not related to your internet connection, much how normal video is sent.  In theory, this service could work if you cancelled your internet.  In reality, it probably won't.  Many providers do the same for VOIP traffic if they have phone services, etc (which do often work with no internet service).



I will say this -- I do telemetry data distribution which is nothing more than a 1.5 megabit constant UDP stream (multicast anyone?  I wish).  The amount of traffic I push is roughly ~350gb/month per site.  With hundreds of business account sites on Comcast, Verizon, AT&T, cox, and others -- The statistics don't lie.  The Comcast network has the least packet loss of the bunch by a wide margin in many cases, and in my opinion, is the most well built consumer broadband access network out there.  With forward error correction, It's an extremely rare event that I see any requests for retransmission, generally isolated to maintenance activities.



My suggestion?  Just send your data towards comcast from a Tier 1 ISP.  Get it as close to your users (geographically) as you can, or use a CDN.  Then, I think you will be fine.

As for the connectivity, you might find it a good idea to explore the comcast paid peering/transit solution if comcast is your primary destination and packet delivery is critical.  Heavy NDA requirements resulting in lack of general pricing range input from the community every time the question has come up on NANOG has kept me from inquiring about paid peering.  But I will tell you just purchasing from the many transit providers who do publish pricing has not resulted in any problems or congestion, which is a good sign.





On Tue, May 29, 2012 at 9:25 AM, Livingood, Jason <Jason_Livingood at cable.comcast.com> wrote:


Mail formatting issue with my mail client again? Note that the 1st paragraph was quoted from Nabil...



>I generate http test stream with DSCP code point 5 to match the Xbox service,

> however Comcast is rewriting the packets as CS 1, even when serving out a

> server at Soft Layer (paid peer).  This is why I ask for name of service Microsoft

> is using, it is not the regular paid peering.



[JL] Yeah, that won't work but that marking is just for byte counting (which per my other not does not really have any effect now anyway since the 250GB policy was suspended. See also http://blog.comcast.com/2012/05/the-facts-about-xfinity-tv-and-xbox-360-comcast-is-not-prioritizing.html





For peering & interconnect, see:

http://www.comcast.com/peering/?SCRedirect=true

http://www.comcast.com/dedicatedinternet/?SCRedirect=true



Thanks

Jason



 		 	   		  

From spacemarket at tormail.org  Tue May 29 19:43:17 2012
From: spacemarket at tormail.org (The SpaceMarket)
Date: Wed, 30 May 2012 00:43:17 +0000
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
Message-ID: <1SZX07-000EBC-EQ@internal.tormail.org>

IPv4 is not going away as quickly as many would like.  Most realistic
observations show IPv4 will still be the numbering scheme most widely
deployed and utilized for the next decade.  This due mainly to peers
and providers whom have not deployed IPv6 and ISP end-users, which
continue to use, antiquated operating systems. 

SpaceMarket provides a platform for entities to acquire additional
resources that find themselves deficient, and a platform for those with
excess/unused resources to monetize their valuable resources. 

Our platform is safe, secure and confidential. 

Buyers and sellers can rest assured that their trades will be executed
without a hitch (no hijacked network ranges or scammers) as each
network allocation available has been thoroughly investigated and
tested (we?re either announcing or have announced the networks
available for an extended period of time), and upon request by either
the buyer or seller, SpaceMarket will serve as an escrow agent for the
transaction. 

Currently (as of this writing), there we have just over
150,000 addresses available for immediate use. This may seem like a low
number, but allocations are listed and acquired daily using our
automated system?we don?t have to be involved in your transaction. In
order to provide our services without hassle and confidentially, we
provide access to our trading platform via Tor (as a Tor Hidden
Service).  This allows our members to connect freely and without worry
as to who may be monitoring your online activities or visitors to our
site.  Additionally, access to the site is restricted to active members
of our trading community.  

For more information on our service, site URL or membership please
e-mail us at spacemarket at tormail.org.  We look forward to assisting you
with your IPv4 needs! Please use our public key (below) when
corresponding via E-mail.  Don?t forget to send us yours!

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
/R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
OkSi
=HUbF
-----END PGP PUBLIC KEY BLOCK-----


From jtk at cymru.com  Tue May 29 19:46:08 2012
From: jtk at cymru.com (John Kristoff)
Date: Tue, 29 May 2012 19:46:08 -0500
Subject: trading bandwidth
In-Reply-To: <F06244E4-AA0C-4C28-B915-2A8106164CE7@delong.com>
References: <CBEB811F.34E28%carl@mobsource.com>
 <F06244E4-AA0C-4C28-B915-2A8106164CE7@delong.com>
Message-ID: <20120529194608.74e83eb6@localhost>

On Tue, 29 May 2012 15:10:04 -0700
Owen DeLong <owen at delong.com> wrote:

> IIRC, the concept was first introduced by MCI and Enron to great
> fanfare and subsequent graphic demonstrations of the destructive
> power of unregulated markets controlled by people of limited moral
> fortitude.

I thought those big organizations actually came in later.  Here is an
article discussing Band-X, which was one of at least two as I recall
that predated some of some of those more well known, later entrants:

  http://www.technologyreview.com/communications/11772/

John


From nabilsharma at hotmail.com  Tue May 29 19:53:44 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Wed, 30 May 2012 00:53:44 +0000
Subject: isc - a good business
In-Reply-To: <m2zk8swmjc.wl%randy@psg.com>
References: <4FC3544F.5070407@isc.org>,<m2zk8swmjc.wl%randy@psg.com>
Message-ID: <SNT129-W3170CC22ECC063F36DA332A30A0@phx.gbl>

Paul:

Where can we read details about the services ISC provided to the FBI, and how they were compensated?

As Mahatma Gandhi says: it is difficult, but not impossible, to conduct strictly honest business.

Sincerely,
Nabil

> Date: Mon, 28 May 2012 20:52:07 +0900
> From: randy at psg.com
> To: vixie at isc.org
> Subject: Re: isc - a good business
> CC: nanog at nanog.org
> 
> fwiw, i think isc and isc staff are very well intentioned and do a lot
> of good work for the community.  i have doubts about isc's business
> model, but definitely not that it makes too much money or is greedy.
> maybe a bit too much layer ten for my taste.  and i run and appreciate
> the software.
> 
> randy
> 
 		 	   		  

From marka at isc.org  Tue May 29 20:02:38 2012
From: marka at isc.org (Mark Andrews)
Date: Wed, 30 May 2012 11:02:38 +1000
Subject: trading bandwidth
In-Reply-To: Your message of "Tue, 29 May 2012 17:10:38 EST."
 <06d501cd3de7$e1179050$a346b0f0$@hathcock.org>
References: <SNT129-W194941D0E978BCE9EC0433A3050@phx.gbl>
 <CBEB811F.34E28%carl@mobsource.com>
 <06d501cd3de7$e1179050$a346b0f0$@hathcock.org>
Message-ID: <20120530010239.B1641210DD5D@drugs.dv.isc.org>


	If you are going to top post ***trim*** the post especially if
	it is a response to a digest.  The whole digest isn't needed.

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


From mctim at isc.org  Tue May 29 19:16:05 2012
From: mctim at isc.org (Timothy McGinnis)
Date: Tue, 29 May 2012 20:16:05 -0400
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <1SZX07-000EBC-EQ@internal.tormail.org>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
Message-ID: <4FC566C5.6080903@isc.org>

Dear Unnamed person at The SpaceMarket,

This list has an Acceptable Use Policy at:

http://www.nanog.org/mailinglist/

"Acceptable Use Policy

 1. Discussion will focus on Internet operational and technical issues
    as described in the charter of NANOG.
    <http://www.nanog.org/governance/charter/>
 2. Postings of issues inconsistent with the charter are prohibited.
 3. Cross posting is prohibited.
 4. Postings that include foul language, character assassination, and
    lack of respect for other participants are prohibited.
 5. Product marketing is prohibited.
 6. Postings of political, philosophical, and legal nature are prohibited.
 7. Using list as source for private marketing initiatives is prohibited.
 8. Autoresponders sending mail either to the list or to the poster are
    prohibited.

Individuals who violate these guidelines will be contacted and asked to
adhere to the guidelines. "

Please take your Unsolicited Bulk Mail elsewhere.

-- 
Cheers,

McTim




On 5/29/2012 8:43 PM, The SpaceMarket wrote:
> IPv4 is not going away as quickly as many would like.  Most realistic
> observations show IPv4 will still be the numbering scheme most widely
> deployed and utilized for the next decade.  This due mainly to peers
> and providers whom have not deployed IPv6 and ISP end-users, which
> continue to use, antiquated operating systems. 
>
> SpaceMarket provides a platform for entities to acquire additional
> resources that find themselves deficient, and a platform for those with
> excess/unused resources to monetize their valuable resources. 
>
> Our platform is safe, secure and confidential. 
>
> Buyers and sellers can rest assured that their trades will be executed
> without a hitch (no hijacked network ranges or scammers) as each
> network allocation available has been thoroughly investigated and
> tested (we?re either announcing or have announced the networks
> available for an extended period of time), and upon request by either
> the buyer or seller, SpaceMarket will serve as an escrow agent for the
> transaction. 
>
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a low
> number, but allocations are listed and acquired daily using our
> automated system?we don?t have to be involved in your transaction. In
> order to provide our services without hassle and confidentially, we
> provide access to our trading platform via Tor (as a Tor Hidden
> Service).  This allows our members to connect freely and without worry
> as to who may be monitoring your online activities or visitors to our
> site.  Additionally, access to the site is restricted to active members
> of our trading community.  
>
> For more information on our service, site URL or membership please
> e-mail us at spacemarket at tormail.org.  We look forward to assisting you
> with your IPv4 needs! Please use our public key (below) when
> corresponding via E-mail.  Don?t forget to send us yours!
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
> Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
> CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
> X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
> 21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
> 2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
> bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
> Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
> UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
> FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
> vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
> tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
> BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
> /R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
> 1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
> VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
> HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
> M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
> V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
> WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
> WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
> myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
> hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
> FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
> 49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
> xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
> gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
> XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
> 3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
> sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
> Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
> ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
> cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
> uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
> cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
> AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
> gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
> INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
> MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
> 2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
> q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
> 605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
> NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
> yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
> 4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
> mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
> OkSi
> =HUbF
> -----END PGP PUBLIC KEY BLOCK-----
>



From owen at delong.com  Tue May 29 20:22:01 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 May 2012 18:22:01 -0700
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <1SZX07-000EBC-EQ@internal.tormail.org>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
Message-ID: <B549C508-47D1-4050-967F-C1A40BD6A718@delong.com>

Likely transfers made in this way may not be recordable with the applicable RIRs and may violate the RIR policies.

If you care about your addresses being properly registered in whois to avoid unnecessary hassles around being able to route them, I highly recommend making sure that you are working either directly with a registered resource holder and/or through a reputable facilitator. In my experience, the RIR staff are readily available and very helpful in answering questions about transfer policies and helping you to work within the system to avoid difficulties later.

The RIRs that serves North America are ARIN (US, Canada, much of the Caribbean) http://www.arin.net
and LACNIC (Mexico, the rest of the Caribbean) http://www.lacnic.net.

Others are APNIC (Asia/Australia) http://www.apnic.net, RIPE NCC (Europe) http://www.ripe.net, and AfriNIC (Africa) http://www.afrinic.net

Owen

On May 29, 2012, at 5:43 PM, The SpaceMarket wrote:

> IPv4 is not going away as quickly as many would like.  Most realistic
> observations show IPv4 will still be the numbering scheme most widely
> deployed and utilized for the next decade.  This due mainly to peers
> and providers whom have not deployed IPv6 and ISP end-users, which
> continue to use, antiquated operating systems. 
> 
> SpaceMarket provides a platform for entities to acquire additional
> resources that find themselves deficient, and a platform for those with
> excess/unused resources to monetize their valuable resources. 
> 
> Our platform is safe, secure and confidential. 
> 
> Buyers and sellers can rest assured that their trades will be executed
> without a hitch (no hijacked network ranges or scammers) as each
> network allocation available has been thoroughly investigated and
> tested (we?re either announcing or have announced the networks
> available for an extended period of time), and upon request by either
> the buyer or seller, SpaceMarket will serve as an escrow agent for the
> transaction. 
> 
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a low
> number, but allocations are listed and acquired daily using our
> automated system?we don?t have to be involved in your transaction. In
> order to provide our services without hassle and confidentially, we
> provide access to our trading platform via Tor (as a Tor Hidden
> Service).  This allows our members to connect freely and without worry
> as to who may be monitoring your online activities or visitors to our
> site.  Additionally, access to the site is restricted to active members
> of our trading community.  
> 
> For more information on our service, site URL or membership please
> e-mail us at spacemarket at tormail.org.  We look forward to assisting you
> with your IPv4 needs! Please use our public key (below) when
> corresponding via E-mail.  Don?t forget to send us yours!
> 
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
> Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
> CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
> X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
> 21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
> 2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
> bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
> Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
> UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
> FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
> vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
> tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
> BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
> /R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
> 1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
> VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
> HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
> M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
> V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
> WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
> WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
> myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
> hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
> FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
> 49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
> xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
> gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
> XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
> 3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
> sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
> Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
> ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
> cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
> uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
> cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
> AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
> gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
> INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
> MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
> 2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
> q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
> 605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
> NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
> yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
> 4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
> mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
> OkSi
> =HUbF
> -----END PGP PUBLIC KEY BLOCK-----



From apishdadi at gmail.com  Tue May 29 20:30:44 2012
From: apishdadi at gmail.com (Ameen Pishdadi)
Date: Tue, 29 May 2012 20:30:44 -0500
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <4FC566C5.6080903@isc.org>
References: <1SZX07-000EBC-EQ@internal.tormail.org> <4FC566C5.6080903@isc.org>
Message-ID: <010BB3DC-BABE-4AB1-B534-B0C14A68B5D4@gmail.com>

Of all the people you pick to spam you picked NANOG, maybe you should hit up bugtraq next 

On May 29, 2012, at 7:16 PM, Timothy McGinnis <mctim at isc.org> wrote:

> Dear Unnamed person at The SpaceMarket,
> 
> This list has an Acceptable Use Policy at:
> 
> http://www.nanog.org/mailinglist/
> 
> "Acceptable Use Policy
> 
> 1. Discussion will focus on Internet operational and technical issues
>    as described in the charter of NANOG.
>    <http://www.nanog.org/governance/charter/>
> 2. Postings of issues inconsistent with the charter are prohibited.
> 3. Cross posting is prohibited.
> 4. Postings that include foul language, character assassination, and
>    lack of respect for other participants are prohibited.
> 5. Product marketing is prohibited.
> 6. Postings of political, philosophical, and legal nature are prohibited.
> 7. Using list as source for private marketing initiatives is prohibited.
> 8. Autoresponders sending mail either to the list or to the poster are
>    prohibited.
> 
> Individuals who violate these guidelines will be contacted and asked to
> adhere to the guidelines. "
> 
> Please take your Unsolicited Bulk Mail elsewhere.
> 
> -- 
> Cheers,
> 
> McTim
> 
> 
> 
> 
> On 5/29/2012 8:43 PM, The SpaceMarket wrote:
>> IPv4 is not going away as quickly as many would like.  Most realistic
>> observations show IPv4 will still be the numbering scheme most widely
>> deployed and utilized for the next decade.  This due mainly to peers
>> and providers whom have not deployed IPv6 and ISP end-users, which
>> continue to use, antiquated operating systems. 
>> 
>> SpaceMarket provides a platform for entities to acquire additional
>> resources that find themselves deficient, and a platform for those with
>> excess/unused resources to monetize their valuable resources. 
>> 
>> Our platform is safe, secure and confidential. 
>> 
>> Buyers and sellers can rest assured that their trades will be executed
>> without a hitch (no hijacked network ranges or scammers) as each
>> network allocation available has been thoroughly investigated and
>> tested (we?re either announcing or have announced the networks
>> available for an extended period of time), and upon request by either
>> the buyer or seller, SpaceMarket will serve as an escrow agent for the
>> transaction. 
>> 
>> Currently (as of this writing), there we have just over
>> 150,000 addresses available for immediate use. This may seem like a low
>> number, but allocations are listed and acquired daily using our
>> automated system?we don?t have to be involved in your transaction. In
>> order to provide our services without hassle and confidentially, we
>> provide access to our trading platform via Tor (as a Tor Hidden
>> Service).  This allows our members to connect freely and without worry
>> as to who may be monitoring your online activities or visitors to our
>> site.  Additionally, access to the site is restricted to active members
>> of our trading community.  
>> 
>> For more information on our service, site URL or membership please
>> e-mail us at spacemarket at tormail.org.  We look forward to assisting you
>> with your IPv4 needs! Please use our public key (below) when
>> corresponding via E-mail.  Don?t forget to send us yours!
>> 
>> -----BEGIN PGP PUBLIC KEY BLOCK-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> 
>> mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
>> Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
>> CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
>> X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
>> 21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
>> 2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
>> bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
>> Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
>> UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
>> FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
>> vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
>> tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
>> BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
>> /R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
>> 1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
>> VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
>> HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
>> M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
>> V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
>> WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
>> WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
>> myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
>> hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
>> FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
>> 49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
>> xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
>> gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
>> XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
>> 3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
>> sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
>> Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
>> ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
>> cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
>> uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
>> cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
>> AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
>> gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
>> INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
>> MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
>> 2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
>> q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
>> 605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
>> NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
>> yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
>> 4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
>> mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
>> OkSi
>> =HUbF
>> -----END PGP PUBLIC KEY BLOCK-----
>> 
> 
> 


From mike at mtcc.com  Tue May 29 20:35:26 2012
From: mike at mtcc.com (Michael Thomas)
Date: Tue, 29 May 2012 18:35:26 -0700
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <010BB3DC-BABE-4AB1-B534-B0C14A68B5D4@gmail.com>
References: <1SZX07-000EBC-EQ@internal.tormail.org> <4FC566C5.6080903@isc.org>
 <010BB3DC-BABE-4AB1-B534-B0C14A68B5D4@gmail.com>
Message-ID: <4FC5795E.90103@mtcc.com>

On 05/29/2012 06:30 PM, Ameen Pishdadi wrote:
> Of all the people you pick to spam you picked NANOG, maybe you should hit up bugtraq next
>

Maybe it's really an ipv6 cabal advertisement :)

Mike


From cb.list6 at gmail.com  Tue May 29 20:38:34 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 29 May 2012 18:38:34 -0700
Subject: Need (to acquire or sell) IPv4? Come to SpaceMarket.
In-Reply-To: <B549C508-47D1-4050-967F-C1A40BD6A718@delong.com>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <B549C508-47D1-4050-967F-C1A40BD6A718@delong.com>
Message-ID: <CAD6AjGRiZshzaJcwgMsCHYWfc0DT=fQ=8ckbUH3cwwpCRHqA1A@mail.gmail.com>

On Tue, May 29, 2012 at 6:22 PM, Owen DeLong <owen at delong.com> wrote:
> Likely transfers made in this way may not be recordable with the applicable RIRs and may violate the RIR policies.
>
> If you care about your addresses being properly registered in whois to avoid unnecessary hassles around being able to route them, I highly recommend making sure that you are working either directly with a registered resource holder and/or through a reputable facilitator. In my experience, the RIR staff are readily available and very helpful in answering questions about transfer policies and helping you to work within the system to avoid difficulties later.
>
> The RIRs that serves North America are ARIN (US, Canada, much of the Caribbean) http://www.arin.net
> and LACNIC (Mexico, the rest of the Caribbean) http://www.lacnic.net.
>
> Others are APNIC (Asia/Australia) http://www.apnic.net, RIPE NCC (Europe) http://www.ripe.net, and AfriNIC (Africa) http://www.afrinic.net
>


Owen,

If i were you, i would strongly consider deploying IPv6 instead of
dealing with this IPv4 mess.  :)

In all seriousness folks, it is going to get scary out there ...
meaning, you are going to have to work with spammers over TOR to get
addresses for your legitimate business reasons.

In related news, Facebook jumped on the gun on world IPv6 launch

http://www.akamai.com/ipv6

Come on in, the water is fine  (can't say the same about IPv4 and
their shady resell markets).

CB
>
> On May 29, 2012, at 5:43 PM, The SpaceMarket wrote:
>
>> IPv4 is not going away as quickly as many would like. ?Most realistic
>> observations show IPv4 will still be the numbering scheme most widely
>> deployed and utilized for the next decade. ?This due mainly to peers
>> and providers whom have not deployed IPv6 and ISP end-users, which
>> continue to use, antiquated operating systems.
>>
>> SpaceMarket provides a platform for entities to acquire additional
>> resources that find themselves deficient, and a platform for those with
>> excess/unused resources to monetize their valuable resources.
>>
>> Our platform is safe, secure and confidential.
>>
>> Buyers and sellers can rest assured that their trades will be executed
>> without a hitch (no hijacked network ranges or scammers) as each
>> network allocation available has been thoroughly investigated and
>> tested (we?re either announcing or have announced the networks
>> available for an extended period of time), and upon request by either
>> the buyer or seller, SpaceMarket will serve as an escrow agent for the
>> transaction.
>>
>> Currently (as of this writing), there we have just over
>> 150,000 addresses available for immediate use. This may seem like a low
>> number, but allocations are listed and acquired daily using our
>> automated system?we don?t have to be involved in your transaction. In
>> order to provide our services without hassle and confidentially, we
>> provide access to our trading platform via Tor (as a Tor Hidden
>> Service). ?This allows our members to connect freely and without worry
>> as to who may be monitoring your online activities or visitors to our
>> site. ?Additionally, access to the site is restricted to active members
>> of our trading community.
>>
>> For more information on our service, site URL or membership please
>> e-mail us at spacemarket at tormail.org. ?We look forward to assisting you
>> with your IPv4 needs! Please use our public key (below) when
>> corresponding via E-mail. ?Don?t forget to send us yours!
>>
>> -----BEGIN PGP PUBLIC KEY BLOCK-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
>> Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
>> CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
>> X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
>> 21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
>> 2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
>> bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
>> Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
>> UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
>> FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
>> vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
>> tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
>> BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
>> /R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
>> 1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
>> VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
>> HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
>> M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
>> V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
>> WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
>> WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
>> myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
>> hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
>> FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
>> 49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
>> xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
>> gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
>> XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
>> 3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
>> sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
>> Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
>> ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
>> cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
>> uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
>> cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
>> AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
>> gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
>> INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
>> MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
>> 2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
>> q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
>> 605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
>> NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
>> yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
>> 4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
>> mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
>> OkSi
>> =HUbF
>> -----END PGP PUBLIC KEY BLOCK-----
>
>


From randy at psg.com  Tue May 29 21:19:05 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 30 May 2012 11:19:05 +0900
Subject: the report from the spambox front
Message-ID: <m2bol6s95y.wl%randy@psg.com>

as part of daily maint, where i read midnight logs from 20+ systems etc,
i scan my spambox to make sure nothing falls through, and indeed catch
one or two daily.  but the spam is a source of great amusement.  the
internet is an wondrous place.

the number of messages offering help for the serious bedbug problem has
been dropping off recently.  so there really is hope we are winning the
war on the bedbug front.  whew!

fedex has so many dell xps laptops in transit to me that storing them
looks to become a serious problem.  anyone with some space in a storage
locker near jimbocho?

zita would really like to take advantage of all the free lobsters, but
there is no red lobster we know of in tokyo [0].  as tokyo has
everything, i am sure i could find one.  but will they take an american
coupon?

a lot of russians are still trying to draw my attention to something
which is obviously important.  anyone out there read russian?  i hope it
is not something critical, like news on the bedbugs in moscow.

we would love to take advantage of all the great clearance sales on
fords, but the cost of garaging a car, especially a large one, in tokyo
is a bit steep.

randy, who has to run out to the accountant to keep up with all the
       fraud monitoring reports on my bank accounts and credit cards in
       the caymans.


From lyle at lcrcomputer.net  Tue May 29 21:27:00 2012
From: lyle at lcrcomputer.net (Lyle Giese)
Date: Tue, 29 May 2012 21:27:00 -0500
Subject: the report from the spambox front
In-Reply-To: <m2bol6s95y.wl%randy@psg.com>
References: <m2bol6s95y.wl%randy@psg.com>
Message-ID: <4FC58574.8030508@lcrcomputer.net>

On 05/29/12 21:19, Randy Bush wrote:
> as part of daily maint, where i read midnight logs from 20+ systems etc,
> i scan my spambox to make sure nothing falls through, and indeed catch
> one or two daily.  but the spam is a source of great amusement.  the
> internet is an wondrous place.
>
> the number of messages offering help for the serious bedbug problem has
> been dropping off recently.  so there really is hope we are winning the
> war on the bedbug front.  whew!
>
> fedex has so many dell xps laptops in transit to me that storing them
> looks to become a serious problem.  anyone with some space in a storage
> locker near jimbocho?
>
> zita would really like to take advantage of all the free lobsters, but
> there is no red lobster we know of in tokyo [0].  as tokyo has
> everything, i am sure i could find one.  but will they take an american
> coupon?
>
> a lot of russians are still trying to draw my attention to something
> which is obviously important.  anyone out there read russian?  i hope it
> is not something critical, like news on the bedbugs in moscow.
>
> we would love to take advantage of all the great clearance sales on
> fords, but the cost of garaging a car, especially a large one, in tokyo
> is a bit steep.
>
> randy, who has to run out to the accountant to keep up with all the
>         fraud monitoring reports on my bank accounts and credit cards in
>         the caymans.
>
How do you then escape all the Canadian Pharmacy ads with a business 
license in New Zealand sent via compromised free email accounts?

Lyle Giese
LCR Computer Services, Inc.




From vixie at isc.org  Tue May 29 21:44:01 2012
From: vixie at isc.org (Paul Vixie)
Date: Wed, 30 May 2012 02:44:01 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <CACB24MuS7GUmwXevSSmLBjh-t0HjkKWR3JydDuDjaSPQqxXUPQ@mail.gmail.com>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
 <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>
 <CACB24MuS7GUmwXevSSmLBjh-t0HjkKWR3JydDuDjaSPQqxXUPQ@mail.gmail.com>
Message-ID: <4FC58971.8010806@isc.org>

On 2012-05-29 5:37 PM, Richard Barnes wrote:
>>> I agree with the person higher up the thread that ROVER seems like
>>> just another distribution mechanism for what is essentially RPKI data.

noting, that up-thread person also said "i havn't studied this in detail
so i'm probably wrong."

>> But does that distribution method easily allow you to get the full set of available data?
> >From what little I know, it seems to me that ROVER is optimized for
> point queries, rather than bulk data access.  Which is the opposite of
> making it easy to get full data :)

that's close to the problem but it is not the problem.

RPKI is a catalogue. it's possible to fetch all of the data you could
need, before starting what's basically the "batch job" of computing the
filters you will use at BGP-reception-time to either accept or ignore an
incoming route. if your "fetch and recompute" steps don't work, then
you'll have to continue filtering using stale data. if that data becomes
too stale you're likely to have to turn off the filtering until you can
resynchronize.

ROVER is not a catalogue. it's impossible to know what data you could
need to precompute any route filters, and it's impossible to know what
'all possible rover data' is -- in fact that would be a nonsequitur. you
could i suppose query for every possible netblock (of every possible
size) but that's an awful lot of queries and you'd have to do it every
day in order to see new stuff or to know when to forget old stuff.

the problem is in time domain bounding of data validity and data
reachability. ROVER expects you to be able to query for the information
about a route at the time you receive that route. that's point-in-time
validity and reachability, which you might not have depending on where
the DNS servers are and what order you're receiving routes in. RPKI+ROA
expects you to have periodic but complete access to a catalogue, and
then your future use of the data you fetched has only the risk of
staleness or invalidity, but never reachability.

as others have stated, there is no reference collection of bad ideas.
otherwise we would have written this one up in 1996 when a couple of dns
people looked at the routing system and said 'hey what about something
like [ROVER]?' and the routing people explained in detail why it
wouldn't work.

paul


From randy at psg.com  Tue May 29 21:55:49 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 30 May 2012 11:55:49 +0900
Subject: rpki vs. secure dns?
In-Reply-To: <4FC58971.8010806@isc.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
 <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>
 <CACB24MuS7GUmwXevSSmLBjh-t0HjkKWR3JydDuDjaSPQqxXUPQ@mail.gmail.com>
 <4FC58971.8010806@isc.org>
Message-ID: <m2y5oaqswa.wl%randy@psg.com>

http://www.cafepress.com/nxdomain/8592477

randy, who will be wearing his at nanog


From randy_94108 at yahoo.com  Tue May 29 22:00:13 2012
From: randy_94108 at yahoo.com (Randy)
Date: Tue, 29 May 2012 20:00:13 -0700 (PDT)
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <1SZX07-000EBC-EQ@internal.tormail.org>
Message-ID: <1338346813.96749.YahooMailClassic@web181117.mail.ne1.yahoo.com>

Nice Tuesday-Evening humor!
...an escrow-agent..and 150k addresses..note "Currently(as of this writing)"
No doubt the next post will have 250k free.
./Randy

> To: nanog at nanog.org, nanog-announce at nanog.org
> Date: Tuesday, May 29, 2012, 5:43 PM
> IPv4 is not going away as quickly as
> many would like.? Most realistic
> observations show IPv4 will still be the numbering scheme
> most widely
> deployed and utilized for the next decade.? This due
> mainly to peers
> and providers whom have not deployed IPv6 and ISP end-users,
> which
> continue to use, antiquated operating systems. 
> 
> SpaceMarket provides a platform for entities to acquire
> additional
> resources that find themselves deficient, and a platform for
> those with
> excess/unused resources to monetize their valuable
> resources. 
> 
> Our platform is safe, secure and confidential. 
> 
> Buyers and sellers can rest assured that their trades will
> be executed
> without a hitch (no hijacked network ranges or scammers) as
> each
> network allocation available has been thoroughly
> investigated and
> tested (we?re either announcing or have announced the
> networks
> available for an extended period of time), and upon request
> by either
> the buyer or seller, SpaceMarket will serve as an escrow
> agent for the
> transaction. 
> 
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem
> like a low
> number, but allocations are listed and acquired daily using
> our
> automated system?we don?t have to be involved in your
> transaction. In
> order to provide our services without hassle and
> confidentially, we
> provide access to our trading platform via Tor (as a Tor
> Hidden
> Service).? This allows our members to connect freely
> and without worry
> as to who may be monitoring your online activities or
> visitors to our
> site.? Additionally, access to the site is restricted
> to active members
> of our trading community.? 
> 
> For more information on our service, site URL or membership
> please
> e-mail us at spacemarket at tormail.org.?
> We look forward to assisting you
> with your IPv4 needs! Please use our public key (below)
> when
> corresponding via E-mail.? Don?t forget to send us
> yours!



From randy at psg.com  Tue May 29 22:00:27 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 30 May 2012 12:00:27 +0900
Subject: rpki vs. secure dns?
In-Reply-To: <m2y5oaqswa.wl%randy@psg.com>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
 <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>
 <CACB24MuS7GUmwXevSSmLBjh-t0HjkKWR3JydDuDjaSPQqxXUPQ@mail.gmail.com>
 <4FC58971.8010806@isc.org> <m2y5oaqswa.wl%randy@psg.com>
Message-ID: <m2vcjeqsok.wl%randy@psg.com>

> http://www.cafepress.com/nxdomain/8592477
> randy, who will be wearing his at nanog

oops!  should acknowledge that it was a gracious gift from geoff, to
whom i had introduced http://sugru.com/ the hacker's playdough

randy


From ops.lists at gmail.com  Tue May 29 22:16:00 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 30 May 2012 08:46:00 +0530
Subject: the report from the spambox front
In-Reply-To: <m2bol6s95y.wl%randy@psg.com>
References: <m2bol6s95y.wl%randy@psg.com>
Message-ID: <CAArzuouR2G5C7c22Z_ba91UyPg3trxH-RHRdQ8Q1WmfixMQyCg@mail.gmail.com>

These three are the same spammer (who is hitting my traps as well,
heavily and regularly)

He gets so many subnets from one provider after the other, and dumps
them when they're blocked (within a day or two), that I wonder whether
v4 is actually running out at all ..

At least multiple /28s is a bit better IP allocation wise (though
rather tougher for my filters to keep track of) than Romanian LIRs
handing every spammer that asks a /15, anytime they want.

--srs

On Wed, May 30, 2012 at 7:49 AM, Randy Bush <randy at psg.com> wrote:
> the number of messages offering help for the serious bedbug problem has
> been dropping off recently. ?so there really is hope we are winning the
> war on the bedbug front. ?whew!

> zita would really like to take advantage of all the free lobsters, but
> there is no red lobster we know of in tokyo [0]. ?as tokyo has
> everything, i am sure i could find one. ?but will they take an american
> coupon?

> we would love to take advantage of all the great clearance sales on
> fords, but the cost of garaging a car, especially a large one, in tokyo
> is a bit steep.


From carl at mobsource.com  Tue May 29 22:29:24 2012
From: carl at mobsource.com (carl gough [mobsource])
Date: Wed, 30 May 2012 13:29:24 +1000
Subject: NANOG Digest, Vol 52, Issue 74
In-Reply-To: <mailman.14029.1338340605.46019.nanog@nanog.org>
Message-ID: <CBEBCBB2.351B9%carl@mobsource.com>

>John, I think we have cross wires, without meaning to advertise or tout
>for business, the bandx solution and the enron solutions totally missed
>the mark in terms of timing.

Every revolution, wether electricity, steam, automotive or telecoms, goes
through a boom, then a bust, then a golden age period that emerges where
it matures, we are in  a maturity period now of IT. The names above, came
at a time when the boom and subsequent bust occurred, they were not around
for the golden age - fast forward to now, over a decade later since bandx,
and you have the pieces of the puzzle that can be re assembled using the
right technology. We don?t differentiate using technology anymore, we get
creative with the way we use iT.

70% of the worlds capacity is unlit, untouched, and creating no value
whatsoever - 

http://mobsource.tumblr.com/post/22890631023/bandwidth-trading-platform-liv
e


>Message: 7
>Date: Tue, 29 May 2012 19:46:08 -0500
>From: John Kristoff <jtk at cymru.com>
>To: Owen DeLong <owen at delong.com>
>Cc: "carl gough \[mobsource\]" <carl at mobsource.com>, nanog at nanog.org
>Subject: Re: trading bandwidth
>Message-ID: <20120529194608.74e83eb6 at localhost>
>Content-Type: text/plain; charset=US-ASCII
>
>On Tue, 29 May 2012 15:10:04 -0700
>Owen DeLong <owen at delong.com> wrote:
>
>> IIRC, the concept was first introduced by MCI and Enron to great
>> fanfare and subsequent graphic demonstrations of the destructive
>> power of unregulated markets controlled by people of limited moral
>> fortitude.
>
>I thought those big organizations actually came in later.  Here is an
>article discussing Band-X, which was one of at least two as I recall
>that predated some of some of those more well known, later entrants:
>
>  http://www.technologyreview.com/communications/11772/
>
>John
>
>




From shane at castlepoint.net  Tue May 29 22:52:17 2012
From: shane at castlepoint.net (Shane Amante)
Date: Tue, 29 May 2012 21:52:17 -0600
Subject: rpki vs. secure dns?
In-Reply-To: <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
Message-ID: <5B556145-6859-49F0-BCD4-4E8D316CD828@castlepoint.net>

Alex,

First, I would note that there is a talk specifically on this subject coming up at NANOG 55, which is scheduled for Tuesday afternoon from 2:30 - 3 PM.  (Note, I'm not giving the talk, just pointing out that your questions may best be followed up face-to-face then).  Anyway, see below.

On May 29, 2012, at 9:23 AM, Alex Band wrote:
> On 29 May 2012, at 16:21, David Conrad wrote:
> 
>> On May 29, 2012, at 4:02 AM, paul vixie wrote:
>>>>> i can tell more than that. rover is a system that only works at all
>>>>> when everything everywhere is working well, and when changes always
>>>>> come in perfect time-order,
>>>> Exactly like DNSSEC. 
>>> 
>>> no. dnssec for a response only needs that response's delegation and
>>> signing path to work, not "everything everywhere".
>> 
>> My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.
> 
> RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'.
> 
> So in RPKI, partial data ? so you failed to fetch one of the ROAs in the set ? can make something 'invalid' or 'unknown' that should actually be 'valid'.
> http://tools.ietf.org/html/rfc6483#page-3
> 
> As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)

Actually, I believe it does.  Specifically, there are two types of DNS RR's:
a)  RLOCK: Route Lock
b)  SRO: Secure Route Origin
Please refer to the following URL for definitions of each: <http://tools.ietf.org/html/draft-gersch-grow-revdns-bgp-00#section-3>.

In short, an RLOCK is applied to a covering aggregate to indicate that each announcement at and more-specific to that covering aggregate require an SRO RR to be considered "Valid".  To re-frame your example above:

10.0.0.0/16 --
   RLOCK
   SRO AS123

Note, there is no SRO defined at 10.0.1.0/24.

Thus, if/when AS456 comes along and announces 10.0.1.0/24, it should be declared Invalid due to:
a)  A DNSSEC lookup for an SRO RR at 10.0.1.0/24 returns NXDOMAIN;
b)  Subsequent lookups for an RLOCK RR (and SRO RR to get the RLOCK's Origin AS) at a covering aggregate returns a positive acknowledgement at 10.0.0.0/16.

Of course, if you want /both/ IP prefixes to be considered Valid, then you would have to also define an SRO RR for the more-specific 10.0.1.0/24 as follows:
10.0.1.0/24
    SRO AS456

-shane

From owen at delong.com  Tue May 29 22:53:44 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 May 2012 20:53:44 -0700
Subject: Need (to acquire or sell) IPv4? Come to SpaceMarket.
In-Reply-To: <CAD6AjGRiZshzaJcwgMsCHYWfc0DT=fQ=8ckbUH3cwwpCRHqA1A@mail.gmail.com>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <B549C508-47D1-4050-967F-C1A40BD6A718@delong.com>
 <CAD6AjGRiZshzaJcwgMsCHYWfc0DT=fQ=8ckbUH3cwwpCRHqA1A@mail.gmail.com>
Message-ID: <76B965A8-45F8-41AC-9939-DB1D1253F5C9@delong.com>


On May 29, 2012, at 6:38 PM, Cameron Byrne wrote:

> On Tue, May 29, 2012 at 6:22 PM, Owen DeLong <owen at delong.com> wrote:
>> Likely transfers made in this way may not be recordable with the applicable RIRs and may violate the RIR policies.
>> 
>> If you care about your addresses being properly registered in whois to avoid unnecessary hassles around being able to route them, I highly recommend making sure that you are working either directly with a registered resource holder and/or through a reputable facilitator. In my experience, the RIR staff are readily available and very helpful in answering questions about transfer policies and helping you to work within the system to avoid difficulties later.
>> 
>> The RIRs that serves North America are ARIN (US, Canada, much of the Caribbean) http://www.arin.net
>> and LACNIC (Mexico, the rest of the Caribbean) http://www.lacnic.net.
>> 
>> Others are APNIC (Asia/Australia) http://www.apnic.net, RIPE NCC (Europe) http://www.ripe.net, and AfriNIC (Africa) http://www.afrinic.net
>> 
> 
> 
> Owen,
> 
> If i were you, i would strongly consider deploying IPv6 instead of
> dealing with this IPv4 mess.  :)
> 
Cameron,

As you know, I've dual-stacked all my stuff and I'm now in the business of helping others get there.

> In all seriousness folks, it is going to get scary out there ...
> meaning, you are going to have to work with spammers over TOR to get
> addresses for your legitimate business reasons.
> 

How legitimate can they be if you're doing that?

> In related news, Facebook jumped on the gun on world IPv6 launch
> 

This is a good thing!

> http://www.akamai.com/ipv6
> 
> Come on in, the water is fine  (can't say the same about IPv4 and
> their shady resell markets).

True that!

Owen

> 
> CB
>> 
>> On May 29, 2012, at 5:43 PM, The SpaceMarket wrote:
>> 
>>> IPv4 is not going away as quickly as many would like.  Most realistic
>>> observations show IPv4 will still be the numbering scheme most widely
>>> deployed and utilized for the next decade.  This due mainly to peers
>>> and providers whom have not deployed IPv6 and ISP end-users, which
>>> continue to use, antiquated operating systems.
>>> 
>>> SpaceMarket provides a platform for entities to acquire additional
>>> resources that find themselves deficient, and a platform for those with
>>> excess/unused resources to monetize their valuable resources.
>>> 
>>> Our platform is safe, secure and confidential.
>>> 
>>> Buyers and sellers can rest assured that their trades will be executed
>>> without a hitch (no hijacked network ranges or scammers) as each
>>> network allocation available has been thoroughly investigated and
>>> tested (we?re either announcing or have announced the networks
>>> available for an extended period of time), and upon request by either
>>> the buyer or seller, SpaceMarket will serve as an escrow agent for the
>>> transaction.
>>> 
>>> Currently (as of this writing), there we have just over
>>> 150,000 addresses available for immediate use. This may seem like a low
>>> number, but allocations are listed and acquired daily using our
>>> automated system?we don?t have to be involved in your transaction. In
>>> order to provide our services without hassle and confidentially, we
>>> provide access to our trading platform via Tor (as a Tor Hidden
>>> Service).  This allows our members to connect freely and without worry
>>> as to who may be monitoring your online activities or visitors to our
>>> site.  Additionally, access to the site is restricted to active members
>>> of our trading community.
>>> 
>>> For more information on our service, site URL or membership please
>>> e-mail us at spacemarket at tormail.org.  We look forward to assisting you
>>> with your IPv4 needs! Please use our public key (below) when
>>> corresponding via E-mail.  Don?t forget to send us yours!
>>> 
>>> -----BEGIN PGP PUBLIC KEY BLOCK-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>> 
>>> mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
>>> Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
>>> CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
>>> X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
>>> 21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
>>> 2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
>>> bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
>>> Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
>>> UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
>>> FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
>>> vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
>>> tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
>>> BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
>>> /R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
>>> 1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
>>> VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
>>> HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
>>> M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
>>> V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
>>> WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
>>> WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
>>> myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
>>> hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
>>> FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
>>> 49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
>>> xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
>>> gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
>>> XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
>>> 3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
>>> sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
>>> Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
>>> ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
>>> cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
>>> uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
>>> cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
>>> AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
>>> gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
>>> INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
>>> MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
>>> 2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
>>> q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
>>> 605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
>>> NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
>>> yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
>>> 4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
>>> mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
>>> OkSi
>>> =HUbF
>>> -----END PGP PUBLIC KEY BLOCK-----
>> 
>> 



From scott at doc.net.au  Tue May 29 23:15:37 2012
From: scott at doc.net.au (Scott Howard)
Date: Tue, 29 May 2012 21:15:37 -0700
Subject: Need (to acquire or sell) IPv4? Come to SpaceMarket.
In-Reply-To: <4FC566C5.6080903@isc.org>
References: <1SZX07-000EBC-EQ@internal.tormail.org> <4FC566C5.6080903@isc.org>
Message-ID: <CACnPsNUWtnsNvHDK7eH4uWd0Mz37DUDoqhPKw5Xi6caPkDbB=Q@mail.gmail.com>

On Tue, May 29, 2012 at 5:16 PM, Timothy McGinnis <mctim at isc.org> wrote:

> Dear Unnamed person at The SpaceMarket,
>

He appears to not be "unnamed".  Gmail links the user to the Google+
profile https://plus.google.com/116655492141266828122 under the name Dan
Cooper, and with a "photo" of another Dan Cooper, being
http://en.wikipedia.org/wiki/D._B._Cooper

Yup, that's the type of person you want to be "buying" IPv4 addresses off...

  Scott.

From shane at castlepoint.net  Tue May 29 23:24:28 2012
From: shane at castlepoint.net (Shane Amante)
Date: Tue, 29 May 2012 22:24:28 -0600
Subject: rpki vs. secure dns?
In-Reply-To: <4FC58971.8010806@isc.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
 <4F4FBD95-846F-4A4F-B0B9-54C765B5ECC0@ripe.net>
 <CACB24MuS7GUmwXevSSmLBjh-t0HjkKWR3JydDuDjaSPQqxXUPQ@mail.gmail.com>
 <4FC58971.8010806@isc.org>
Message-ID: <8FAD12E1-1C03-4FE8-B359-D1E54CB8E37F@castlepoint.net>

Paul,

On May 29, 2012, at 8:44 PM, Paul Vixie wrote:
> On 2012-05-29 5:37 PM, Richard Barnes wrote:
>>>> I agree with the person higher up the thread that ROVER seems like
>>>> just another distribution mechanism for what is essentially RPKI data.
> 
> noting, that up-thread person also said "i havn't studied this in detail
> so i'm probably wrong."
> 
>>> But does that distribution method easily allow you to get the full set of available data?
>>> From what little I know, it seems to me that ROVER is optimized for
>> point queries, rather than bulk data access.  Which is the opposite of
>> making it easy to get full data :)
> 
> that's close to the problem but it is not the problem.
> 
> RPKI is a catalogue. it's possible to fetch all of the data you could
> need, before starting what's basically the "batch job" of computing the
> filters you will use at BGP-reception-time to either accept or ignore an
> incoming route. if your "fetch and recompute" steps don't work, then
> you'll have to continue filtering using stale data. if that data becomes
> too stale you're likely to have to turn off the filtering until you can
> resynchronize.
> 
> ROVER is not a catalogue. it's impossible to know what data you could
> need to precompute any route filters, and it's impossible to know what
> 'all possible rover data' is -- in fact that would be a nonsequitur. you
> could i suppose query for every possible netblock (of every possible
> size) but that's an awful lot of queries and you'd have to do it every
> day in order to see new stuff or to know when to forget old stuff.
> 
> the problem is in time domain bounding of data validity and data
> reachability. ROVER expects you to be able to query for the information
> about a route at the time you receive that route. that's point-in-time
> validity and reachability, which you might not have depending on where
> the DNS servers are and what order you're receiving routes in. RPKI+ROA
> expects you to have periodic but complete access to a catalogue, and
> then your future use of the data you fetched has only the risk of
> staleness or invalidity, but never reachability.
> 
> as others have stated, there is no reference collection of bad ideas.
> otherwise we would have written this one up in 1996 when a couple of dns
> people looked at the routing system and said 'hey what about something
> like [ROVER]?' and the routing people explained in detail why it
> wouldn't work.

Just one correction to the above.  As pointed out in Section 4 of draft-gersch-grow-revdns-bgp-00 "near-real-time route origin verification" is merely one instantiation of the "ROVER concept".  Please refer to that section for other potential uses of such published data.

I would also ask people to expand their minds beyond the "it must have a (near-)real-time mechanism" directly coupled to the Control Plane" for a variety of reasons.  Such a tight coupling of /any/ two systems inevitably, and unfortunately, will only fail at scale in ways that likely would never have been predicted a priori[1] -- unfortunately, you only learn this lesson afterward.  Question is: how quickly can you detect and react to unwind the specific problem w/out having to turn it off completely, (i.e.: "shields down")?  Alternatively, is it more prudent to engineer some 'sanity' safeguards, (i.e.: back away from the 'real-time' aspect), to avoid this from happening at all or at least extremely rarely?

-shane

[1] FWIW, Dave Meyer has been doing some thinking about "complexity" for a while now, drawing analogies from outside of networking/computing, and has some fascinating insight.  I'm sure if there's enough interest, he'd be willing to discuss it.  Who knows, we may even learn something.  :-)

From vixie at isc.org  Wed May 30 00:06:50 2012
From: vixie at isc.org (Paul Vixie)
Date: Wed, 30 May 2012 05:06:50 +0000
Subject: rpki vs. secure dns?
In-Reply-To: <5B556145-6859-49F0-BCD4-4E8D316CD828@castlepoint.net>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net> <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <5B556145-6859-49F0-BCD4-4E8D316CD828@castlepoint.net>
Message-ID: <4FC5AAEA.103@isc.org>

"ah, the force is strong in this one."

On 2012-05-30 3:52 AM, Shane Amante wrote:
> On May 29, 2012, at 9:23 AM, Alex Band wrote:
>> ...
>>
>> As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)
> Actually, I believe it does.  Specifically, there are two types of DNS RR's:
> a)  RLOCK: Route Lock
> b)  SRO: Secure Route Origin
> Please refer to the following URL for definitions of each: <http://tools.ietf.org/html/draft-gersch-grow-revdns-bgp-00#section-3>.

as dns is an unreliable protocol, and is not atomic across multiple
questions, what is the effect of seeing one of those rrsets but not the
other? (here again we see the disadvantage of starting from incomplete
information.)

On 2012-05-30 4:24 AM, Shane Amante wrote:
> On May 29, 2012, at 8:44 PM, Paul Vixie wrote:
>> ...
>>
>> the problem is in time domain bounding of data validity and data
>> reachability. ROVER expects you to be able to query for the information
>> about a route at the time you receive that route. that's point-in-time
>> validity and reachability, which you might not have depending on where
>> the DNS servers are and what order you're receiving routes in. RPKI+ROA
>> expects you to have periodic but complete access to a catalogue, and
>> then your future use of the data you fetched has only the risk of
>> staleness or invalidity, but never reachability.
>>
>> as others have stated, there is no reference collection of bad ideas.
>> otherwise we would have written this one up in 1996 when a couple of dns
>> people looked at the routing system and said 'hey what about something
>> like [ROVER]?' and the routing people explained in detail why it
>> wouldn't work.
> Just one correction to the above.  As pointed out in Section 4 of draft-gersch-grow-revdns-bgp-00 "near-real-time route origin verification" is merely one instantiation of the "ROVER concept".  Please refer to that section for other potential uses of such published data.

my comment on that draft was (on the dnsop mailing list, march 10, 2012):

> your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the
> draft and the design are of admirable quality. as a co-author of RFC
> 2317 i agree that it does not suit the needs of bgp security since it
> seeks only to provide a method of fully naming hosts, not networks.
>
> importantly, i see no reference to RFC 1101 in your draft. RFC 1101
> describes a way to name networks, and while at first it did not seem to
> be compatible with CIDR, implementation (in "netstat -r" back in BSD/OS
> 3.1) showed that RFC 1101 was in fact not as classful as it appeared.
...
> you may find that some of your work has already been done for you, or,
> you may find that this is related work that should be referenced in your
> draft along with the reasons why your proposed method is necessary.

joe and dan (authors of this draft) responded:

>    thanks for your comments and support.  We will definitely reference RFC draft 1101 in our next version.

and indeed this was done, but weakly:

>    Changes from version 01 to 02
...
>       Expanded the related work discussion to include RFC 1101.

looking at draft -02 we see:

> 4.1.  Naming via RFC 1101
>
>    The problem of associating records with network names dates back to
>    at least [RFC1101].  This work coincides with some of the early
>    development of DNS and discusses issues regarding hosts.txt files.
>    The RFC observation makes a key observation that one should provide
>    "mappings for subnets, even when nested".
>
>    The approach taken here clearly states how to map an IPv4 prefix that
>    is on an octet boundary.  The RFC maps "10.IN-ADDR.ARPA for class A
>    net 10, 2.128.IN-ADDR.ARPA for class B net 128.2, etc."  This is
>    essentially the same as the approach proposed here, although we
>    append an "m" label (discussed later in this document).
>
>    [RFC1101] also mentions more specific subnets, but the details are
>    limited.  We believe the approach proposed here builds on the best
>    ideas from this RFC and expands on the details of how the naming
>    convention would work.

in other words no explaination for why the existing RFC 1101 encoding
will not serve, even though RFC 1101 encoding been used for network
naming in the CIDR era, without limitation.

this reader is left wondering, what's the real impetus here?

> I would also ask people to expand their minds beyond the "it must have a (near-)real-time mechanism" directly coupled to the Control Plane" for a variety of reasons.  Such a tight coupling of /any/ two systems inevitably, and unfortunately, will only fail at scale in ways that likely would never have been predicted a priori[1] -- 

i think you're paying insufficient attention to this discussion, if you
think that failure predictions have not already been well made with
respect to the rover approach to routing security.

> ...
>
> [1] FWIW, Dave Meyer has been doing some thinking about "complexity" for a while now, drawing analogies from outside of networking/computing, and has some fascinating insight.  I'm sure if there's enough interest, he'd be willing to discuss it.  Who knows, we may even learn something.  :-)

see also <http://queue.acm.org/detail.cfm?id=1242499>.

paul

From paul4004 at gmail.com  Wed May 30 00:37:04 2012
From: paul4004 at gmail.com (PC)
Date: Wed, 30 May 2012 00:37:04 -0500
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <SNT129-W24DF215EE2E337E115C60DA30A0@phx.gbl>
References: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>
 <CBEA5441.6230C%jason_livingood@cable.comcast.com>
 <CAJAdsD=gQzqKcjx4D6vHBe3Ojm2SC876nf5ZGDtpzCTKAJwg5g@mail.gmail.com>
 <SNT129-W24DF215EE2E337E115C60DA30A0@phx.gbl>
Message-ID: <CAJAdsDmmK10xnL=Gm7QH1R4+8Pbe9JTt+gYxU2qvTO+yQ_-bJQ@mail.gmail.com>

Just e-mail them if you want to know.  I'm sure it wouldn't take much
actual effort to obtain a price from sales.

Go here, and there's instructions.
*www.comcast.com/peering/*
**

Having said that, bandwidth from your host (softlayer) has direct comcast
private peering (back in 2008, anyways --
http://www.webhostingtalk.com/showthread.php?t=740564). Maybe you can find
a looking glass somewhere and verify it's still true, and just use them.

I wouldn't expect them to honor your DSCP or QOS marking though, or someone
larger than you would have already done this.  Not likely to work.




On Tue, May 29, 2012 at 7:41 PM, Nabil Sharma <nabilsharma at hotmail.com>wrote:

>
> PC:
> I also wish to know how much the Comcast "Paid Peering" service costs, and
> if this is an option that can get us the delivery we require.
> Could you please help me to understand why it is protected by NDA? Is
> there anyone on the NANOG list who can share this pricing with me in
> private?
> Sincerely,
> Nabil
>

From mark.tinka at seacom.mu  Wed May 30 00:44:12 2012
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 30 May 2012 07:44:12 +0200
Subject: Comcast Service for Non-Cap Bandwidth
In-Reply-To: <SNT129-W27BAFEED03374FB1A68E24A30A0@phx.gbl>
References: <CBEA52BB.622F9%jason_livingood@cable.comcast.com>
 <CBEA5441.6230C%jason_livingood@cable.comcast.com>
 <SNT129-W27BAFEED03374FB1A68E24A30A0@phx.gbl>
Message-ID: <201205300744.13043.mark.tinka@seacom.mu>

On Wednesday, May 30, 2012 02:34:06 AM Nabil Sharma wrote:

> Mr. Jason:
> Thank u for the reply, very informative URL. Understood
> on the cap, but how long it will remain not enforced is
> a good guess! What I am trying to is have Comcast mark
> our IP ranges with QoS, so downloads or congestion
> inside the household will not degrade performance. You
> can see at
> http://ber.gd/post/23025893856/comcast-traffic-prioritiz
> ation that this is the configuration for Microsoft Xbox.
> Do you know what this service is called and who at
> Comcast can help me with the commercials?

There is nothing to confirm with any certainty that even 
though Comcast may be remarking QoS values upon ingress to 
their network, that those (new) markings actually have any 
(forwarding) meaning in their network.

As someone stated before, relying on QoS for regular IP 
Transit traffic is tenuous at best.

Mark.


From sginsberg at pandora.com  Wed May 30 01:21:07 2012
From: sginsberg at pandora.com (Steve Ginsberg)
Date: Tue, 29 May 2012 23:21:07 -0700
Subject: NANOG 55 Peering Track agenda and announcements
In-Reply-To: <08C1A9DA-2C19-42EA-AAF9-284CAD92DB9A@pandora.com>
References: <08C1A9DA-2C19-42EA-AAF9-284CAD92DB9A@pandora.com>
Message-ID: <F244312F-4010-4F8C-BE74-D8389B09D8D2@pandora.com>

Friendly reminder about the Peering BoF. I'll extend the deadline for IX slides to Friday (see details below). For Peering Personals earlier is better, but I'll probably let folks in if we have space since we'd like to welcome new peers.

Hope you can join us for a lively discussion!

~Steve


On May 23, 2012, at 2:07 PM, Steve Ginsberg wrote:

> Hi All,
> 
> Here's the current plan for the Peering BOF.
> 
> Session will take place on Monday, June 4, 2012 from 4:30 PM to 6:00 PM in Salon D-F
> 
> Please join us for a lively discussion.
> 
> NANOG Peering BoF 90 minutes
> 
> Introductions and PeeringDB PSA 5min
> Peering Personals Part I 5min
> LinkedIN Presentation/Discussion 20min
> IX Updates 5 min
> Peering Personals Part 2 5-10 min
> Pandora Presentation/Discussion 20min
> Mobile/Peering Changes Discussion 20 min
> 
> * If you'd like to be part of new Peering Personals - a chance to announce your intention to peer - we'd love to meet you. Please email me off-list with
> Name, Organization, and URL in Peeringdb by next Monday.
> 
> * If you're an IX and want to be part of the IX update, please email me directly for the slide template. I'll send it to you so you can submit 1-3 (no more) PowerPoint slides which can be rolled with out narration, by next Monday. 
> 
> * I'd also like to speak to some more folks who work for the Mobile carriers so please get in touch if you'd like to help.
> 
> 
> ~Steve 
> http://www.pandora.com/profile/peace
> https://www.peeringdb.com/private/participant_view.php?id=1407
> for peering requests please send to peering at pandora.com
> 


From tony.mccrory at gmail.com  Wed May 30 03:02:26 2012
From: tony.mccrory at gmail.com (Tony McCrory)
Date: Wed, 30 May 2012 09:02:26 +0100
Subject: Need (to acquire or sell) IPv4? Come to SpaceMarket.
In-Reply-To: <CACnPsNUWtnsNvHDK7eH4uWd0Mz37DUDoqhPKw5Xi6caPkDbB=Q@mail.gmail.com>
References: <1SZX07-000EBC-EQ@internal.tormail.org> <4FC566C5.6080903@isc.org>
 <CACnPsNUWtnsNvHDK7eH4uWd0Mz37DUDoqhPKw5Xi6caPkDbB=Q@mail.gmail.com>
Message-ID: <CAG9TQP=VsL9rR5LbZyRCASEFU1E5gWvvjPYYo=M2hw+LT+87PQ@mail.gmail.com>

On 30 May 2012 05:15, Scott Howard <scott at doc.net.au> wrote:

> On Tue, May 29, 2012 at 5:16 PM, Timothy McGinnis <mctim at isc.org> wrote:
>
> > Dear Unnamed person at The SpaceMarket,
> >
>
> He appears to not be "unnamed".  Gmail links the user to the Google+
> profile https://plus.google.com/116655492141266828122 under the name Dan
> Cooper, and with a "photo" of another Dan Cooper, being
> http://en.wikipedia.org/wiki/D._B._Cooper
>
> Yup, that's the type of person you want to be "buying" IPv4 addresses
> off...
>
>  Scott.
>

Google+ About page:
Tagline
I am D.B. Cooper version 2.0.
Occupation
Creating money out of thin air.

From o.calvano at gmail.com  Wed May 30 04:00:45 2012
From: o.calvano at gmail.com (Olivier CALVANO)
Date: Wed, 30 May 2012 11:00:45 +0200
Subject: Contact Requested : China Telecom and SingTel
Message-ID: <CAJajPecK1G4jV4B0NC8teruiY9Bx-iKot5UcGsTpWTstoPc8aw@mail.gmail.com>

Hi


anyone have the name/email of a contact into China Telecom and SingTel
for operator ?

thanks
olivier


From aduitsis at noc.ntua.gr  Wed May 30 04:21:08 2012
From: aduitsis at noc.ntua.gr (Athanasios Douitsis)
Date: Wed, 30 May 2012 12:21:08 +0300
Subject: yahoo uk & ireland contact
Message-ID: <CABT9mj-2+x20CURGkjhOVfcku8Xtz7FufXpHKubNCGAsK3BEmA@mail.gmail.com>

Hi,

Could someone from engineer from yahoo uk & ireland please contact me off-list?

I am the admin of a provider with ~25000 DSL users in Greece. For some
months now, yahoo cannot be accessed correctly from our newly acquired
IP block 37.32.128.0/17. Reportedly, the problem appears when talking
to 217.146.187.123 but doesn't appear when talking to 217.12.8.76.

Even the contact mail registered with RIPE (uk-abuse at cc.yahoo-inc.com)
returns an automated response saying they don't read mail from that
address.

Regards to all,
Athanasios Douitsis


From randy at psg.com  Wed May 30 04:43:53 2012
From: randy at psg.com (Randy Bush)
Date: Wed, 30 May 2012 18:43:53 +0900
Subject: rpki vs. secure dns?
In-Reply-To: <4FC5AAEA.103@isc.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
 <F88DE2FE-03E2-4C4E-B274-AF8446284C40@arbor.net>
 <g38vgc81jj.fsf@nsa.vix.com>
 <E26EA4F9-C339-42C7-A3E2-5E31D1830999@virtualized.org>
 <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
 <4FC4ACCE.6000903@isc.org>
 <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
 <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
 <5B556145-6859-49F0-BCD4-4E8D316CD828@castlepoint.net>
 <4FC5AAEA.103@isc.org>
Message-ID: <m2mx4qqa06.wl%randy@psg.com>

>> I would also ask people to expand their minds beyond the "it must
>> have a (near-)real-time mechanism" directly coupled to the Control
>> Plane" for a variety of reasons.  Such a tight coupling of /any/ two
>> systems inevitably, and unfortunately, will only fail at scale in
>> ways that likely would never have been predicted a priori[1] --
> i think you're paying insufficient attention to this discussion, if
> you think that failure predictions have not already been well made
> with respect to the rover approach to routing security.

rfc 3439, the most complex document about simplicity you can imagine

randy


From isabeldias1 at yahoo.com  Wed May 30 06:41:49 2012
From: isabeldias1 at yahoo.com (isabel dias)
Date: Wed, 30 May 2012 04:41:49 -0700 (PDT)
Subject: Contact Requested : China Telecom and SingTel
In-Reply-To: <CAJajPecK1G4jV4B0NC8teruiY9Bx-iKot5UcGsTpWTstoPc8aw@mail.gmail.com>
References: <CAJajPecK1G4jV4B0NC8teruiY9Bx-iKot5UcGsTpWTstoPc8aw@mail.gmail.com>
Message-ID: <1338378109.98397.YahooMailNeo@web121605.mail.ne1.yahoo.com>

You are an excellent point of contact at China Telecoms. In fact you could try the resident team in resourcing for huawei?at your local university campus ....
?
they always turn up in exhibitions ............
 

________________________________
 From: Olivier CALVANO <o.calvano at gmail.com>
To: "NANOG list (nanog at nanog.org)" <nanog at nanog.org> 
Sent: Wednesday, May 30, 2012 10:00 AM
Subject: Contact Requested : China Telecom and SingTel
  
Hi


anyone have the name/email of a contact into China Telecom and SingTel
for operator ?

thanks
olivier

From vixie at isc.org  Wed May 30 09:06:03 2012
From: vixie at isc.org (Paul Vixie)
Date: Wed, 30 May 2012 14:06:03 +0000
Subject: isc - a good business
In-Reply-To: <SNT129-W3170CC22ECC063F36DA332A30A0@phx.gbl>
References: <4FC3544F.5070407@isc.org>, <m2zk8swmjc.wl%randy@psg.com>
 <SNT129-W3170CC22ECC063F36DA332A30A0@phx.gbl>
Message-ID: <4FC6294B.5060308@isc.org>

On 2012-05-30 12:53 AM, Nabil Sharma wrote:
> Paul:
>
> Where can we read details about the services ISC provided to the FBI,
> and how they were compensated?

it's in the AP News article published a few weeks ago. for an example:

http://www.foxnews.com/scitech/2012/04/23/hundreds-thousands-may-lose-internet-in-july/

> As Mahatma Gandhi says: it is difficult, but not impossible, to
> conduct strictly honest business.
>
> Sincerely,
> Nabil

the FBI's business dealings are transparent in this case. judge for
yourself whether it's also strictly honest.

paul

From EWieling at nyigc.com  Wed May 30 09:07:30 2012
From: EWieling at nyigc.com (Eric Wieling)
Date: Wed, 30 May 2012 10:07:30 -0400
Subject: Need (to acquire or sell) IPv4? Come to SpaceMarket.
In-Reply-To: <CACnPsNUWtnsNvHDK7eH4uWd0Mz37DUDoqhPKw5Xi6caPkDbB=Q@mail.gmail.com>
References: <1SZX07-000EBC-EQ@internal.tormail.org> <4FC566C5.6080903@isc.org>
 <CACnPsNUWtnsNvHDK7eH4uWd0Mz37DUDoqhPKw5Xi6caPkDbB=Q@mail.gmail.com>
Message-ID: <C262B52114110B4586FAF49F074F0580154B94D2CF@mailserver2007.nyigc.globe>


Anyone who spams, regardless of how great their product is, does not get my business nor the business of anyone else who will listen to me.


-----Original Message-----
From: Scott Howard [mailto:scott at doc.net.au] 
Sent: Wednesday, May 30, 2012 12:16 AM
To: Timothy McGinnis
Cc: nanog at nanog.org
Subject: Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.

On Tue, May 29, 2012 at 5:16 PM, Timothy McGinnis <mctim at isc.org> wrote:

> Dear Unnamed person at The SpaceMarket,
>

He appears to not be "unnamed".  Gmail links the user to the Google+ profile https://plus.google.com/116655492141266828122 under the name Dan Cooper, and with a "photo" of another Dan Cooper, being http://en.wikipedia.org/wiki/D._B._Cooper

Yup, that's the type of person you want to be "buying" IPv4 addresses off...

  Scott.


From psirt at cisco.com  Wed May 30 11:09:11 2012
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 30 May 2012 12:09:11 -0400
Subject: Cisco Security Advisory: Cisco IOS XR Software Route Processor Denial
 of Service Vulnerability 
Message-ID: <201205301209018.cisco-sa-20120530-iosxr@psirt.cisco.com>

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

Cisco IOS XR Software Route Processor Denial of Service Vulnerability

Advisory ID: cisco-sa-20120530-iosxr

Revision 1.0

For Public Release 2012 May 30 16:00  UTC (GMT)
+---------------------------------------------------------------------
 
Summary
=======

Cisco IOS XR Software contains a vulnerability when handling crafted
packets that may result in a denial of service condition. The
vulnerability only exists on Cisco 9000 Series Aggregation Services
Routers (ASR) Route Switch Processor (RSP440) and Cisco Carrier
Routing System (CRS) Performance Route Processor (PRP). The
vulnerability is a result of improper handling of crafted packets and
could cause the route processor, which processes the packets, to be
unable to transmit packets to the fabric.

Cisco has released free software updates that address this
vulnerability. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120530-iosxr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk/GMvQACgkQQXnnBKKRMNDF2wD6A5yZWmZgCmk5x+RJ2mxIXzcW
RXsu7/NENNspgbOJk2wA/RIJ9Fbzy+QZTRuQtg2vX0vCOhterMOVmN3Ue0VCzj52
=lCxE
-----END PGP SIGNATURE-----


From nickm at stanford.edu  Wed May 30 11:15:10 2012
From: nickm at stanford.edu (Nick McKeown)
Date: Wed, 30 May 2012 09:15:10 -0700
Subject: Help us to help you debug networks
Message-ID: <4FC6478E.8040700@stanford.edu>

Dear Colleague,

I am writing to ask you to help us.... so that we might help you. My 
group at Stanford University is building open source tools to 
automatically diagnose network failures such as reachability problems, 
networks loops, and traffic congestion. Our goal is to create tools that 
are useful to people who own and operate real production networks.

Would you be willing to fill out a quick 5-minute survey to help us with 
our research? I know we all get asked to fill out a lot of these surveys 
- our goal here is to learn from you, so we can help you in your job, 
and help the community more broadly. To test our ideas, and to help us 
build tools that would be useful to you, we need your input: We want to 
know what network problems you deal with in your network. We plan to 
publish the results of our survey in an anonymized, aggregated form that 
you might find useful, along with our research results. Please feel free 
to forward this email.

You can find the survey at http://svy.mk/NetDebug

Many thanks. We really appreciate your time.

- Nick

--------------------------
Professor of Computer Science
Stanford University


From dgolding at ragingwire.com  Wed May 30 17:20:12 2012
From: dgolding at ragingwire.com (Dan Golding)
Date: Wed, 30 May 2012 15:20:12 -0700
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <1SZX07-000EBC-EQ@internal.tormail.org>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
Message-ID: <1C7B96053DD7814496A0D1E71661B68302BD7C01@SMF-ENTXM-001.sac.ragingwire.net>


There are five registered STLS facilitators - https://www.arin.net/resources/transfer_listing/facilitator_list.html

SpaceMarket is not one of them. I am confounded about why anyone would select a broker who has not taken the basic step of registering with the RIR. Of course, the typos and anonymity should also give you pause. Maybe this is the first round of "419" IP Address Transfer Scam emails. May I suggest...

---

My name is Ishmael Curran, illegitimate son of the recently deposed North Virginia Minister of IP Address Distribution. I am currently in hiding and unable to effectively transfer two pre-RIR CLASS A ADDRESS BLOCKS. If you could assist me by paying an IP Address Transfer Fee of $42,561 in Bolivian Pesos to the enclosed Antiguan bank drop, I will provide one of the pre-RIR address blocks to you, as a "thank you". My current status as a fugitive, following the unfortunate VX Gas release at the last ARIN public policy forum precludes my direct involvement. Your short-term loan of $32,945 will be returned via clearly legitimate third-party cashier's check, upon request. 

Yours Truly, Ishmael

-------

Dan

> -----Original Message-----
> From: The SpaceMarket [mailto:spacemarket at tormail.org]
> Sent: Tuesday, May 29, 2012 8:43 PM
> To: nanog at nanog.org; nanog-announce at nanog.org
> Subject: Need (to acquire or sell) IPv4? Come to SpaceMarket.
> 
> IPv4 is not going away as quickly as many would like.  Most realistic
> observations show IPv4 will still be the numbering scheme most widely
> deployed and utilized for the next decade.  This due mainly to peers
> and providers whom have not deployed IPv6 and ISP end-users, which
> continue to use, antiquated operating systems.
> 
> SpaceMarket provides a platform for entities to acquire additional
> resources that find themselves deficient, and a platform for those with
> excess/unused resources to monetize their valuable resources.
> 
> Our platform is safe, secure and confidential.
> 
> Buyers and sellers can rest assured that their trades will be executed
> without a hitch (no hijacked network ranges or scammers) as each
> network allocation available has been thoroughly investigated and
> tested (we?re either announcing or have announced the networks
> available for an extended period of time), and upon request by either
> the buyer or seller, SpaceMarket will serve as an escrow agent for the
> transaction.
> 
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a low
> number, but allocations are listed and acquired daily using our
> automated system?we don?t have to be involved in your transaction. In
> order to provide our services without hassle and confidentially, we
> provide access to our trading platform via Tor (as a Tor Hidden
> Service).  This allows our members to connect freely and without worry
> as to who may be monitoring your online activities or visitors to our
> site.  Additionally, access to the site is restricted to active members
> of our trading community.
> 
> For more information on our service, site URL or membership please
> e-mail us at spacemarket at tormail.org.  We look forward to assisting you
> with your IPv4 needs! Please use our public key (below) when
> corresponding via E-mail.  Don?t forget to send us yours!
> 
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> mQINBE/FaAgBEADT4VpYwIRnUj8R7tFAAWdcHBHR9SEpebBskq400kG50UA8o3Cq
> Ox5tBfY0It9AOaRE6yhOu7TcPbLrJyjjkl2UqqpMF/pIRasqXTbwHKT1vkpt22Oc
> CtHFmXSY4KgE51lfHq7ijRt+m9B3j78Jr6uklpca8IW41eXNyje4272DLv4L1wHR
> X00VXPr6pULn3bgm/KfnwmmY0ucpDlLJIZ1xsRFTstNKrA5d0K96RhhqDWcaZGyf
> 21nskMRwRahO+VcRVE4515AZ09L1CfSoUbNOVtSHIiANYSPbq9QQHNeBas5MJkuA
> 2aZ/TyCEJ501AtTKL735w1ile+3DMK/sRQhEOzTp/Y4AmIDJSKRDYnhJnE9T2x/C
> bud54hvoT+sx7xq3Fbo18xCAeBWDO/3k2G44z2ecyAzGCP8YUGAVp5sa+X7nHvZR
> Z2W+DQn/XuPXPSzsbPqh6wxnhrr5/0IdU06jjLK398n+r2eM8nDJnm8BFYICrBE4
> UcG4Jd2KHejL+PeIB1IO4KHmmCJD3W1Ya1zi2wUjPX5PB3gf3p492+2iowu/k9kt
> FyTx+FoVZQDfqUGdBm7C8JvwNCXB2c92P58mV8ds0vmGPoMk7zioWMspInVFDXUB
> vbShwtK4eowfoT3u1PwtgRJdsKzDZ3TTIKqmGFF24OkP2c2s5DBi2W/PYwARAQAB
> tCVTcGFjZU1hcmtldCA8c3BhY2VtYXJrZXRAdG9ybWFpbC5vcmc+iQI3BBMBCAAh
> BQJPxWgIAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEOaJI/0SIsh9MpgP
> /R3uEtdnJWbTlI1uaJQ/50Xh7XtarY+qKSlK/YC059v4mJYgRx+la15pmryGyKDF
> 1qyPu+EI1r437EREr8uGy+LFqI2lD4oKXxvJRDJSqaiwYpAVM2t/prE9bYju5puS
> VZbeNEsUse9MthhoesOg+fGfsI6P5W1aAWQswKWDM/tegjW+NPXbv8yWnC7Vfe6b
> HUghDlUETihleohWxtoqGla6I7s8qxYMFa684mF84Xyrnj/5DIey8Z5ROwwqQv4y
> M2jVOPpa02S1tyLd4aNI2pP7IVsBMK9uvsN+VBKUtGlhap1RSAMQaFWoKR0L1M3o
> V3LkmezSKaMjlk2XhSzokJP9snV99KRMxMjlCQwEnS7dct6JLokU1cYNyHSSjDOC
> WN57FeBt4pnG1HA31Z2B81jz3oKzYN2lOqAvY5L657sIUWWoPfhGjkEIiFtlRGCl
> WvEg4xyXRUf2dsXFHsYqDsMzR3p67L2CwTNErqF5ZhwxchuNp6E1gIdYoZghcYuT
> myxbGF0uFTH7ymg3yzJxuE/78iqhbMGAnkwdCa2GaczmymQiWkNqVQjpZizUdN7w
> hTrm5vQ9OucrpHCFoLOZ3Kk29o7m586I3welE0Kz4cmDdcoqM798k3/BxKUTAHFv
> FNhjHfzllDy1QiLXbm9z+Uu/oIr/h/X8DNRHzFXNwqcUuQINBE/FaAgBEADBqS9r
> 49m5RmRUH/YTy6V2iAwdf6fTzr+hOT9FDhdKYfF9TEgT4ZZEIg1BLhCUlwfSO3Ex
> xCFt8Wdtnbs/z6pd5iFb+Gm11q/CPUMBq7lgiLrO9FNLg8geTlyHGgDQNm8w5At4
> gvi5Y7r17UlVrmd71H9ZpmB1iN8uM2pjirD5WRYAyX3KdYhzEJmorA6HKn5OSM/8
> XAugeEXkgMEwn4NioZJjSbunTYNXDK6CqvGNI8X2w34V5qs/+jcIJ9f08ijkB/OK
> 3rtaYKEVmcoHV8UFNQREbJqV44doOxtUfajyOyCB5+/B4KKOx8MrwTGB9R2ia9hY
> sobdNv3fPOASrlSlUpVdy6iXipwSUTaoi4EscMKnL7fh4xAphqWVbCrKVqBOR7m3
> Oxy9Q+9/eFWs3qQoDbq+E2HtEtvfvtckwZ8HqtxnLnBPMgj7kbN5mv5yMLGmLreb
> ruLlf6Ran/xwTQPtyvDoojWAf8o1PWkA0prK3iZiHUJ5KJLm5soh6nf+FPh8RxRJ
> cBMr0TGYieL21hU63T7iGvHYOLYANG/vUacrA3jvm3a3NbLDkwXl5JLLBOgf5iXm
> uZRWbgK121Kss1BTPeh//QaBeZnVj48JohPZQ7WuspWiJm6z33CrIORkqFU+VTzy
> cf/klE1tBH+ETpvaVMIxOd1AUzmLmZa/g5vnXQARAQABiQIfBBgBCAAJBQJPxWgI
> AhsMAAoJEOaJI/0SIsh9TtYP/2Jq4+KbowRhnw9gJsOr26i643T7LRsFw2+XvbHP
> gICwTZYdRa3F8zvTb1R/45Fqt3atZd2pszRFosGx6hCjVZGSTgCbiNscpAntPiSl
> INFUIXj7L5XlUptFflWNP+uHdYXyAYXl7nuIDOhdfs1gFBXdeuhtmO93kDY52UIv
> MnFYGrFiZZFBttiffseX/XpJ1W8mnWMF9nqihWFBxvbuauOlVzYofvzYjAQQJb/3
> 2rNpx2z4mm68Wyn1go9zx75aOEIafEjYlZuusGcpFzchu1xwT4OEGAXXTQ4Sh6aM
> q4FgQcPxKo5NvU1XJyoCuye5R93tT0uxQNqCeiP+a44PYXex3ijRyS2JhRDhE3uI
> 605N7+BTVMbcJgo7krptDGfwUOfBRq92jMxINzWsCynJIvh+iYl1R0AecClYgjHV
> NNzouXMKzS4isXvB/k0LQOYOxWpIwm2xFVODGItDTzErLnPrsFgdxLyJf980HyVO
> yz/NXL7Xz4kzWAPLO2qboMp/caGlgZviEomffggJKqpnvRYSOl91lf0fVbRYQ4yy
> 4N2mUpT3iPq87lmhqJWmNhxa9XcfbW5JVHzaiGteuDinWyLQBEuOCpGdFQs8TXuG
> mQxm5LQ9c8+N4HAXN1jCmP7Oo2shT5TfQXTPs7hlujXz9xs0Gf4n6YEa6yofGiHM
> OkSi
> =HUbF
> -----END PGP PUBLIC KEY BLOCK-----


From lanning at lanning.cc  Wed May 30 17:51:06 2012
From: lanning at lanning.cc (Robert Hajime Lanning)
Date: Wed, 30 May 2012 15:51:06 -0700
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <1SZX07-000EBC-EQ@internal.tormail.org>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
Message-ID: <4FC6A45A.9090000@lanning.cc>

Can I trade in my class A? (10/8)

On 05/29/12 17:43, The SpaceMarket wrote:
> IPv4 is not going away as quickly as many would like.  Most realistic
> observations show IPv4 will still be the numbering scheme most widely
> deployed and utilized for the next decade.  This due mainly to peers
> and providers whom have not deployed IPv6 and ISP end-users, which
> continue to use, antiquated operating systems.
>
> SpaceMarket provides a platform for entities to acquire additional
> resources that find themselves deficient, and a platform for those with
> excess/unused resources to monetize their valuable resources.
>
> Our platform is safe, secure and confidential.
>
> Buyers and sellers can rest assured that their trades will be executed
> without a hitch (no hijacked network ranges or scammers) as each
> network allocation available has been thoroughly investigated and
> tested (we?re either announcing or have announced the networks
> available for an extended period of time), and upon request by either
> the buyer or seller, SpaceMarket will serve as an escrow agent for the
> transaction.
>
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a low
> number, but allocations are listed and acquired daily using our
> automated system?we don?t have to be involved in your transaction. In
> order to provide our services without hassle and confidentially, we
> provide access to our trading platform via Tor (as a Tor Hidden
> Service).  This allows our members to connect freely and without worry
> as to who may be monitoring your online activities or visitors to our
> site.  Additionally, access to the site is restricted to active members
> of our trading community.
>
> For more information on our service, site URL or membership please
> e-mail us at spacemarket at tormail.org.  We look forward to assisting you
> with your IPv4 needs! Please use our public key (below) when
> corresponding via E-mail.  Don?t forget to send us yours!

-- 
Mr. Flibble
King of the Potato People


From trelane at trelane.net  Wed May 30 21:30:15 2012
From: trelane at trelane.net (Andrew D Kirch)
Date: Wed, 30 May 2012 22:30:15 -0400
Subject: isc - a good business
In-Reply-To: <4FC6294B.5060308@isc.org>
References: <4FC3544F.5070407@isc.org>, <m2zk8swmjc.wl%randy@psg.com>
 <SNT129-W3170CC22ECC063F36DA332A30A0@phx.gbl> <4FC6294B.5060308@isc.org>
Message-ID: <4FC6D7B7.6040804@trelane.net>

Paul,

I just wanted to point out that you're a horrible person for employing 
people at a sustainable level, for giving away the product of your 
company for free, and for having the temerity to assist the FBI, on 
break-even basis ensuring that users of the internet continue to have 
access to DNS.  HOW DARE YOU SIR?

Andrew





On 5/30/2012 10:06 AM, Paul Vixie wrote:
> On 2012-05-30 12:53 AM, Nabil Sharma wrote:
>> Paul:
>>
>> Where can we read details about the services ISC provided to the FBI,
>> and how they were compensated?
> it's in the AP News article published a few weeks ago. for an example:
>
> http://www.foxnews.com/scitech/2012/04/23/hundreds-thousands-may-lose-internet-in-july/
>
>> As Mahatma Gandhi says: it is difficult, but not impossible, to
>> conduct strictly honest business.
>>
>> Sincerely,
>> Nabil
> the FBI's business dealings are transparent in this case. judge for
> yourself whether it's also strictly honest.
>
> paul



From Curtis.Starnes at granburyisd.org  Wed May 30 21:40:40 2012
From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS)
Date: Wed, 30 May 2012 21:40:40 -0500
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <4FC6A45A.9090000@lanning.cc>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <4FC6A45A.9090000@lanning.cc>
Message-ID: <A5FACB06A6163C4790FAE19E1C9314D70136CF327D63@MAILSRV.granbury.k12.tx.us>

I thought the 10.0.0.0/8 was mine.....
I was going to sell some of it!

Curtis

-----Original Message-----
From: Robert Hajime Lanning [mailto:lanning at lanning.cc] 
Sent: Wednesday, May 30, 2012 5:51 PM
To: nanog at nanog.org
Subject: Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.

Can I trade in my class A? (10/8)

On 05/29/12 17:43, The SpaceMarket wrote:
> IPv4 is not going away as quickly as many would like.  Most realistic 
> observations show IPv4 will still be the numbering scheme most widely 
> deployed and utilized for the next decade.  This due mainly to peers 
> and providers whom have not deployed IPv6 and ISP end-users, which 
> continue to use, antiquated operating systems.
>
> SpaceMarket provides a platform for entities to acquire additional 
> resources that find themselves deficient, and a platform for those 
> with excess/unused resources to monetize their valuable resources.
>
> Our platform is safe, secure and confidential.
>
> Buyers and sellers can rest assured that their trades will be executed 
> without a hitch (no hijacked network ranges or scammers) as each 
> network allocation available has been thoroughly investigated and 
> tested (we?re either announcing or have announced the networks 
> available for an extended period of time), and upon request by either 
> the buyer or seller, SpaceMarket will serve as an escrow agent for the 
> transaction.
>
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a 
> low number, but allocations are listed and acquired daily using our 
> automated system?we don?t have to be involved in your transaction. In 
> order to provide our services without hassle and confidentially, we 
> provide access to our trading platform via Tor (as a Tor Hidden 
> Service).  This allows our members to connect freely and without worry 
> as to who may be monitoring your online activities or visitors to our 
> site.  Additionally, access to the site is restricted to active 
> members of our trading community.
>
> For more information on our service, site URL or membership please 
> e-mail us at spacemarket at tormail.org.  We look forward to assisting 
> you with your IPv4 needs! Please use our public key (below) when 
> corresponding via E-mail.  Don?t forget to send us yours!

--
Mr. Flibble
King of the Potato People


From Curtis.Starnes at granburyisd.org  Wed May 30 21:43:41 2012
From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS)
Date: Wed, 30 May 2012 21:43:41 -0500
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <A5FACB06A6163C4790FAE19E1C9314D70136CF327D63@MAILSRV.granbury.k12.tx.us>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <4FC6A45A.9090000@lanning.cc>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D63@MAILSRV.granbury.k12.tx.us>
Message-ID: <A5FACB06A6163C4790FAE19E1C9314D70136CF327D64@MAILSRV.granbury.k12.tx.us>

I guess I will just have to settle for selling my 224.0.0.0/24     :-<

-----Original Message-----
From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] 
Sent: Wednesday, May 30, 2012 9:41 PM
To: 'lanning at lanning.cc'; nanog at nanog.org
Subject: RE: Need (to acquire or sell) IPv4? Come to SpaceMarket.

I thought the 10.0.0.0/8 was mine.....
I was going to sell some of it!

Curtis

-----Original Message-----
From: Robert Hajime Lanning [mailto:lanning at lanning.cc]
Sent: Wednesday, May 30, 2012 5:51 PM
To: nanog at nanog.org
Subject: Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.

Can I trade in my class A? (10/8)

On 05/29/12 17:43, The SpaceMarket wrote:
> IPv4 is not going away as quickly as many would like.  Most realistic 
> observations show IPv4 will still be the numbering scheme most widely 
> deployed and utilized for the next decade.  This due mainly to peers 
> and providers whom have not deployed IPv6 and ISP end-users, which 
> continue to use, antiquated operating systems.
>
> SpaceMarket provides a platform for entities to acquire additional 
> resources that find themselves deficient, and a platform for those 
> with excess/unused resources to monetize their valuable resources.
>
> Our platform is safe, secure and confidential.
>
> Buyers and sellers can rest assured that their trades will be executed 
> without a hitch (no hijacked network ranges or scammers) as each 
> network allocation available has been thoroughly investigated and 
> tested (we?re either announcing or have announced the networks 
> available for an extended period of time), and upon request by either 
> the buyer or seller, SpaceMarket will serve as an escrow agent for the 
> transaction.
>
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a 
> low number, but allocations are listed and acquired daily using our 
> automated system?we don?t have to be involved in your transaction. In 
> order to provide our services without hassle and confidentially, we 
> provide access to our trading platform via Tor (as a Tor Hidden 
> Service).  This allows our members to connect freely and without worry 
> as to who may be monitoring your online activities or visitors to our 
> site.  Additionally, access to the site is restricted to active 
> members of our trading community.
>
> For more information on our service, site URL or membership please 
> e-mail us at spacemarket at tormail.org.  We look forward to assisting 
> you with your IPv4 needs! Please use our public key (below) when 
> corresponding via E-mail.  Don?t forget to send us yours!

--
Mr. Flibble
King of the Potato People


From valdis.kletnieks at vt.edu  Wed May 30 21:55:16 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Wed, 30 May 2012 22:55:16 -0400
Subject: isc - a good business
In-Reply-To: Your message of "Wed, 30 May 2012 22:30:15 -0400."
 <4FC6D7B7.6040804@trelane.net>
References: <4FC3544F.5070407@isc.org>, <m2zk8swmjc.wl%randy@psg.com>
 <SNT129-W3170CC22ECC063F36DA332A30A0@phx.gbl> <4FC6294B.5060308@isc.org>
 <4FC6D7B7.6040804@trelane.net>
Message-ID: <4273.1338432916@turing-police.cc.vt.edu>

On Wed, 30 May 2012 22:30:15 -0400, Andrew D Kirch said:
> I just wanted to point out that you're a horrible person for employing
> people at a sustainable level, for giving away the product of your
> company for free, and for having the temerity to assist the FBI, on
> break-even basis ensuring that users of the internet continue to have
> access to DNS.  HOW DARE YOU SIR?

On the other hand, Ayn Rand is doing so many RPMs that Google is
investigating her as a power source for their next data center... ;)

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

From nathan at atlasnetworks.us  Wed May 30 22:07:37 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 31 May 2012 03:07:37 +0000
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <A5FACB06A6163C4790FAE19E1C9314D70136CF327D64@MAILSRV.granbury.k12.tx.us>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <4FC6A45A.9090000@lanning.cc>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D63@MAILSRV.granbury.k12.tx.us>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D64@MAILSRV.granbury.k12.tx.us>
Message-ID: <8C26A4FDAE599041A13EB499117D3C28899BD26F@EX-MB-1.corp.atlasnetworks.us>

None of these jokes are class-e.

-----Original Message-----
From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] 
Sent: Wednesday, May 30, 2012 7:44 PM
To: STARNES, CURTIS; 'lanning at lanning.cc'; nanog at nanog.org
Subject: RE: Need (to acquire or sell) IPv4? Come to SpaceMarket.

I guess I will just have to settle for selling my 224.0.0.0/24     :-<

-----Original Message-----
From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org]
Sent: Wednesday, May 30, 2012 9:41 PM
To: 'lanning at lanning.cc'; nanog at nanog.org
Subject: RE: Need (to acquire or sell) IPv4? Come to SpaceMarket.

I thought the 10.0.0.0/8 was mine.....
I was going to sell some of it!

Curtis

-----Original Message-----
From: Robert Hajime Lanning [mailto:lanning at lanning.cc]
Sent: Wednesday, May 30, 2012 5:51 PM
To: nanog at nanog.org
Subject: Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.

Can I trade in my class A? (10/8)

On 05/29/12 17:43, The SpaceMarket wrote:
> IPv4 is not going away as quickly as many would like.  Most realistic 
> observations show IPv4 will still be the numbering scheme most widely 
> deployed and utilized for the next decade.  This due mainly to peers 
> and providers whom have not deployed IPv6 and ISP end-users, which 
> continue to use, antiquated operating systems.
>
> SpaceMarket provides a platform for entities to acquire additional 
> resources that find themselves deficient, and a platform for those 
> with excess/unused resources to monetize their valuable resources.
>
> Our platform is safe, secure and confidential.
>
> Buyers and sellers can rest assured that their trades will be executed 
> without a hitch (no hijacked network ranges or scammers) as each 
> network allocation available has been thoroughly investigated and 
> tested (we?re either announcing or have announced the networks 
> available for an extended period of time), and upon request by either 
> the buyer or seller, SpaceMarket will serve as an escrow agent for the 
> transaction.
>
> Currently (as of this writing), there we have just over
> 150,000 addresses available for immediate use. This may seem like a 
> low number, but allocations are listed and acquired daily using our 
> automated system?we don?t have to be involved in your transaction. In 
> order to provide our services without hassle and confidentially, we 
> provide access to our trading platform via Tor (as a Tor Hidden 
> Service).  This allows our members to connect freely and without worry 
> as to who may be monitoring your online activities or visitors to our 
> site.  Additionally, access to the site is restricted to active 
> members of our trading community.
>
> For more information on our service, site URL or membership please 
> e-mail us at spacemarket at tormail.org.  We look forward to assisting 
> you with your IPv4 needs! Please use our public key (below) when 
> corresponding via E-mail.  Don?t forget to send us yours!

--
Mr. Flibble
King of the Potato People


From apishdadi at gmail.com  Wed May 30 22:43:52 2012
From: apishdadi at gmail.com (Ameen Pishdadi)
Date: Wed, 30 May 2012 22:43:52 -0500
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28899BD26F@EX-MB-1.corp.atlasnetworks.us>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <4FC6A45A.9090000@lanning.cc>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D63@MAILSRV.granbury.k12.tx.us>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D64@MAILSRV.granbury.k12.tx.us>
 <8C26A4FDAE599041A13EB499117D3C28899BD26F@EX-MB-1.corp.atlasnetworks.us>
Message-ID: <FF3AA2F5-CE01-4017-B2AD-189440CF3638@gmail.com>

Lol

Thanks,
Ameen Pishdadi


On May 30, 2012, at 10:07 PM, Nathan Eisenberg <nathan at atlasnetworks.us> wrote:

> None of these jokes are class-e.
> 
> -----Original Message-----
> From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] 
> Sent: Wednesday, May 30, 2012 7:44 PM
> To: STARNES, CURTIS; 'lanning at lanning.cc'; nanog at nanog.org
> Subject: RE: Need (to acquire or sell) IPv4? Come to SpaceMarket.
> 
> I guess I will just have to settle for selling my 224.0.0.0/24     :-<
> 
> -----Original Message-----
> From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org]
> Sent: Wednesday, May 30, 2012 9:41 PM
> To: 'lanning at lanning.cc'; nanog at nanog.org
> Subject: RE: Need (to acquire or sell) IPv4? Come to SpaceMarket.
> 
> I thought the 10.0.0.0/8 was mine.....
> I was going to sell some of it!
> 
> Curtis
> 
> -----Original Message-----
> From: Robert Hajime Lanning [mailto:lanning at lanning.cc]
> Sent: Wednesday, May 30, 2012 5:51 PM
> To: nanog at nanog.org
> Subject: Re: Need (to acquire or sell) IPv4? Come to SpaceMarket.
> 
> Can I trade in my class A? (10/8)
> 
> On 05/29/12 17:43, The SpaceMarket wrote:
>> IPv4 is not going away as quickly as many would like.  Most realistic 
>> observations show IPv4 will still be the numbering scheme most widely 
>> deployed and utilized for the next decade.  This due mainly to peers 
>> and providers whom have not deployed IPv6 and ISP end-users, which 
>> continue to use, antiquated operating systems.
>> 
>> SpaceMarket provides a platform for entities to acquire additional 
>> resources that find themselves deficient, and a platform for those 
>> with excess/unused resources to monetize their valuable resources.
>> 
>> Our platform is safe, secure and confidential.
>> 
>> Buyers and sellers can rest assured that their trades will be executed 
>> without a hitch (no hijacked network ranges or scammers) as each 
>> network allocation available has been thoroughly investigated and 
>> tested (we?re either announcing or have announced the networks 
>> available for an extended period of time), and upon request by either 
>> the buyer or seller, SpaceMarket will serve as an escrow agent for the 
>> transaction.
>> 
>> Currently (as of this writing), there we have just over
>> 150,000 addresses available for immediate use. This may seem like a 
>> low number, but allocations are listed and acquired daily using our 
>> automated system?we don?t have to be involved in your transaction. In 
>> order to provide our services without hassle and confidentially, we 
>> provide access to our trading platform via Tor (as a Tor Hidden 
>> Service).  This allows our members to connect freely and without worry 
>> as to who may be monitoring your online activities or visitors to our 
>> site.  Additionally, access to the site is restricted to active 
>> members of our trading community.
>> 
>> For more information on our service, site URL or membership please 
>> e-mail us at spacemarket at tormail.org.  We look forward to assisting 
>> you with your IPv4 needs! Please use our public key (below) when 
>> corresponding via E-mail.  Don?t forget to send us yours!
> 
> --
> Mr. Flibble
> King of the Potato People
> 


From bonomi at mail.r-bonomi.com  Thu May 31 03:52:45 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 31 May 2012 03:52:45 -0500 (CDT)
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28899BD26F@EX-MB-1.corp.atlasnetworks.us>
Message-ID: <201205310852.q4V8qjmA027140@mail.r-bonomi.com>

Nathan Eisenberg <nathan at atlasnetworks.us> wrote:
>
> None of these jokes are class-e.
>

I considered offering 172.24.0.0/14, in an attempt at in-CIDR humor.




From lanning at lanning.cc  Thu May 31 04:15:41 2012
From: lanning at lanning.cc (Robert Hajime Lanning)
Date: Thu, 31 May 2012 02:15:41 -0700
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <201205310852.q4V8qjmA027140@mail.r-bonomi.com>
References: <201205310852.q4V8qjmA027140@mail.r-bonomi.com>
Message-ID: <4FC736BD.6070900@lanning.cc>

On 05/31/12 01:52, Robert Bonomi wrote:
> I considered offering 172.24.0.0/14, in an attempt at in-CIDR humor.

Can we be arrested for in-CIDR trading?

-- 
Mr. Flibble
King of the Potato People


From danny at danysek.cz  Thu May 31 05:23:30 2012
From: danny at danysek.cz (Daniel Suchy)
Date: Thu, 31 May 2012 12:23:30 +0200
Subject: HE.net BGP origin attribute rewriting
Message-ID: <4FC746A2.5010707@danysek.cz>

Hello,

we discovered, that at least Hurricane Electric (HE, AS 6939) does
rewrite BGP origin attribute unconditionally in all routes traversing
their network. This mandatory, but probably not widely known/used
attribute should not be changed by any speaker except originating router
(RFC 4271, section 5.1.1). HE rewrites origin for all routes.

I tried communicate this issue with HE, but they're not willing change
their configuration and respect mentioned RFC document, and they're
claiming, that another networks (Level3 was mentioned exactly) does
similar thing. In my experience, there're not so many service providers
doing that.

What's your view on this, do you think, that service providers can
simply ignore existing RFCs?

With regards,
Daniel



From rol at witbe.net  Thu May 31 05:26:42 2012
From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=))
Date: Thu, 31 May 2012 12:26:42 +0200
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <A5FACB06A6163C4790FAE19E1C9314D70136CF327D64@MAILSRV.granbury.k12.tx.us>
References: <1SZX07-000EBC-EQ@internal.tormail.org>
 <4FC6A45A.9090000@lanning.cc>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D63@MAILSRV.granbury.k12.tx.us>
 <A5FACB06A6163C4790FAE19E1C9314D70136CF327D64@MAILSRV.granbury.k12.tx.us>
Message-ID: <20120531122642.11542755@tux.DEF.witbe.net>

Hello,

On Wed, 30 May 2012 21:43:41 -0500
"STARNES, CURTIS" <Curtis.Starnes at granburyisd.org> wrote:

> I guess I will just have to settle for selling my 224.0.0.0/24     :-<
> 

After checking some machines, it seems that 127.0.0.1/8 can be sold multiple
times, as it is fully re-usable.

Any bonus for that ?

Paul


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

From nick at foobar.org  Thu May 31 06:26:29 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 31 May 2012 12:26:29 +0100
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC746A2.5010707@danysek.cz>
References: <4FC746A2.5010707@danysek.cz>
Message-ID: <4FC75565.4000404@foobar.org>

On 31/05/2012 11:23, Daniel Suchy wrote:
> In my experience, there're not so many service providers
> doing that.

Plenty of providers do it.  IIWY, I would universally rewrite origin at
your ingress points to be the same; otherwise you'll find that providers
will merely use it as a means of influencing the bgp best path decision
algorithm so that they end up with more of your traffic, and can
consequently charge you more.  There are many useful ways to build a
multi-exit discrimination policy.  Using origin is not one of them, in my
opinion.

The problem is that origin is ranked one place higher than MED.  So if you
don't rewrite it, you are automatically giving your upstreams an inherent
means of strongly influencing the tie-breaking policy.  If this were an
attribute which actually meant something, then maybe there would be some
point in paying attention to it, but it conveys no useful information these
days.  IOW, it is completely pointless these days and you almost certainly
want to work the possibility of any upstream tweaking it.

Nick


From thegameiam at yahoo.com  Thu May 31 06:55:28 2012
From: thegameiam at yahoo.com (David Barak)
Date: Thu, 31 May 2012 07:55:28 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC75565.4000404@foobar.org>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
Message-ID: <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>

On May 31, 2012, at 7:26 AM, Nick Hilliard <nick at foobar.org> wrote:
>   There are many useful ways to build a
> multi-exit discrimination policy.  Using origin is not one of them, in my
> opinion.
> 
> The problem is that origin is ranked one place higher than MED.  So if you
> don't rewrite it, you are automatically giving your upstreams an inherent
> means of strongly influencing the tie-breaking policy.  If this were an
> attribute which actually meant something, then maybe there would be some
> point in paying attention to it, but it conveys no useful information these
> days.  IOW, it is completely pointless these days and you almost certainly
> want to work the possibility of any upstream tweaking it.
> 
> Nick
> 

I disagree.  Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is.  The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending "soft" preferences down the transitive chain.  Also useful is "set origin egp XX" - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties.

David Barak

Sent from a mobile device, please forgive autocorrection.


From sthaug at nethelp.no  Thu May 31 07:03:00 2012
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 31 May 2012 14:03:00 +0200 (CEST)
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
Message-ID: <20120531.140300.74687292.sthaug@nethelp.no>

> I disagree.  Origin is tremendously useful as a multi-AS weighting
> tool, and isn't the blunt hammer that AS_PATH is.

If you think of AS_PATH as a blunt hammer, how would you describe
localpref?

We use AS_PATH in many cases *precisely* because we don't consider it
to be a blunt hammer...

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From thegameiam at yahoo.com  Thu May 31 07:33:27 2012
From: thegameiam at yahoo.com (David Barak)
Date: Thu, 31 May 2012 08:33:27 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120531.140300.74687292.sthaug@nethelp.no>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <20120531.140300.74687292.sthaug@nethelp.no>
Message-ID: <37AB0984-E51B-400D-B43B-180E79A527C3@yahoo.com>



On May 31, 2012, at 8:03 AM, sthaug at nethelp.no wrote:

>> I disagree.  Origin is tremendously useful as a multi-AS weighting
>> tool, and isn't the blunt hammer that AS_PATH is.
> 
> If you think of AS_PATH as a blunt hammer, how would you describe
> localpref?
> 
> We use AS_PATH in many cases *precisely* because we don't consider it
> to be a blunt hammer...
> 

So you're connected to providers A and B, who in turn connect to C.  Additionally, B has customer D.

If you set origin E toward B (leaving origin I toward A) you influence C's decision without affecting either B or D, and you ensure that C still learns both routes to you.  It's a more subtle nudge than as-path.

In general, I prefer routinely using attributes that are further down the algorithm so at the big guns can be saved for when they're needed or for special policy issues.

David Barak

Sent from a mobile device, please forgive autocorrection.

From ted at fred.net  Thu May 31 08:06:17 2012
From: ted at fred.net (Ted Fischer)
Date: Thu, 31 May 2012 09:06:17 -0400
Subject: Need (to acquire or sell) IPv4?  Come to SpaceMarket.
In-Reply-To: <4FC736BD.6070900@lanning.cc>
References: <201205310852.q4V8qjmA027140@mail.r-bonomi.com>
 <4FC736BD.6070900@lanning.cc>
Message-ID: <20120531130633.87EE21590DA@mail-out05.xecu.net>


I could probably gin up some cheap black market Class F's ... I'll 
match and beat any advertised or unadvertised route.

http://www.rfc-editor.org/rfc/rfc1365.txt

Ted


>On 05/31/12 01:52, Robert Bonomi wrote:
>>I considered offering 172.24.0.0/14, in an attempt at in-CIDR humor.
>
>Can we be arrested for in-CIDR trading?
>
>--
>Mr. Flibble
>King of the Potato People


From cncr04s at gmail.com  Thu May 31 08:14:40 2012
From: cncr04s at gmail.com (cncr04s/Randy)
Date: Thu, 31 May 2012 08:14:40 -0500
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <87likculjh.fsf@mid.deneb.enyo.de>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
Message-ID: <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>

On Mon, May 28, 2012 at 2:56 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>
> [Dnschanger substitute server operations]
>
> > One thing is clear, Paul is able to tell a great story.
>
> PR for ISC is somewhat limited, it's often attributed to the FBI:
>
> | The effort, scheduled to begin this afternoon, is designed to let
> | those people know that their Internet connections will stop working
> | on July 9, when temporary servers set up by the FBI to help
> | DNSChanger victims are due to be disconnected.
>
>
> <http://news.cnet.com/8301-1009_3-57439407-83/google-will-alert-users-to-dnschanger-malware-infection/>
>
> | The FBI has now seized control of the malicious DNS servers, but
> | countless computers are still infected with the malware.
>
>
> <http://www.h-online.com/security/news/item/Google-warns-DNSChanger-victims-1583037.html>
>
> | The malware is so vicious ? it can interfere with users' Web
> | browsing, steer them to fraudulent websites and make their computers
> | vulnerable to other malicious software ? that the FBI has put a
> | safety net of sorts in place, using government computers to prevent
> | any Internet disruptions for users whose computers may be infected.
>
>
> <http://www.technolog.msnbc.msn.com/technology/technolog/infected-users-get-legit-warning-about-july-9-internet-doomsday-751078>
>
> (I'm justing quoting what I found. ?Some of the linked articles
> contain bogus information.)
>
> In any case, this isn't what bugs me about the whole process. ?I don't
> like the way this is implemented?mainly the use of RPZ, but there are
> other concerns. ?The notification process has some issues as well, but
> it's certainly a great learning exercise for all folks involved with
> this. ?To me, it doesn't really matter that Dnschanger is fairly minor
> as far as such things go. ?Hopefully, the knowledge and the contacts
> established can be applied to other cases as well.
>

Exactly how much can it cost to serve up those requests... I mean for
9$ a month I have a cpu that handles 2000 *Recursive* Queries a
second. 900 bux could net me *200,000* a second if not more.
The government overspends on a lot of things.. they need some one whos
got the experience to use a bunch of cheap servers for the resolvers
and a box that hosts the IPs used and then distributes the query
packets.


From nick at foobar.org  Thu May 31 08:37:56 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 31 May 2012 14:37:56 +0100
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
Message-ID: <4FC77434.5000306@foobar.org>

On 31/05/2012 12:55, David Barak wrote:
> I disagree.  Origin is tremendously useful as a multi-AS weighting tool,
> and isn't the blunt hammer that AS_PATH is.  The place where I've gotten
> the most benefit is large internal networks, where there may be multiple
> MPLS clouds along with sites cascaded off of them - it provides a way of
> sending "soft" preferences down the transitive chain.  Also useful is
> "set origin egp XX" - on a route injector, that can post-pend an ASN and
> limit the spread of a route while still allowing the same transitive
> properties.

We're not talking about the same thing here: configuring a policy to use an
interior-generated origin is completely different to depending on what your
upstreams configure their announcements to look like.

If you don't rewrite your transit providers' origin, then you are telling
them that they can directly influence your exit discrimination policy on
the basis of a purely advisory flag which has no real meaning.  I.e. if one
of them tweaks origin to be IGP and another leaves everything set at EGP or
incomplete, then the tweaker will end up taking more of your traffic on no
basis whatsoever, other than the fact that they bent the rules of what some
might consider as pair play.  This is broken and harmful.  Rewriting the
origin on ingress stops this particular line of network abuse.

Nick


From keegan.holley at sungard.com  Thu May 31 09:00:50 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 31 May 2012 10:00:50 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC77434.5000306@foobar.org>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org>
Message-ID: <CABO8Q6Q9usN9V=ZN48kTUNMNGkhxwKvmoqMW+on6EqHhw5pwzw@mail.gmail.com>

I have seen providers instruct their upstreams to raise local-pref to
hijack traffic.  More than a few ISP's rewrite origin though.  Personally I
only consider it a slightly shady practice.  I think the problem with BGP
(among other things) is that there is no "blunt hammer".  Now that routers
have more than 1G of RAM and more than one core it may be time to add some
more knobs.


2012/5/31 Nick Hilliard <nick at foobar.org>

> On 31/05/2012 12:55, David Barak wrote:
> > I disagree.  Origin is tremendously useful as a multi-AS weighting tool,
> > and isn't the blunt hammer that AS_PATH is.  The place where I've gotten
> > the most benefit is large internal networks, where there may be multiple
> > MPLS clouds along with sites cascaded off of them - it provides a way of
> > sending "soft" preferences down the transitive chain.  Also useful is
> > "set origin egp XX" - on a route injector, that can post-pend an ASN and
> > limit the spread of a route while still allowing the same transitive
> > properties.
>
> We're not talking about the same thing here: configuring a policy to use an
> interior-generated origin is completely different to depending on what your
> upstreams configure their announcements to look like.
>
> If you don't rewrite your transit providers' origin, then you are telling
> them that they can directly influence your exit discrimination policy on
> the basis of a purely advisory flag which has no real meaning.  I.e. if one
> of them tweaks origin to be IGP and another leaves everything set at EGP or
> incomplete, then the tweaker will end up taking more of your traffic on no
> basis whatsoever, other than the fact that they bent the rules of what some
> might consider as pair play.  This is broken and harmful.  Rewriting the
> origin on ingress stops this particular line of network abuse.
>
> Nick
>
>
>

From morrowc.lists at gmail.com  Thu May 31 10:31:18 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 31 May 2012 11:31:18 -0400
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
Message-ID: <CAL9jLaZjcf5O+9U4ZDrhvzTizAKO-JbH7LY+-rvU6zkfSrUWiQ@mail.gmail.com>

On Thu, May 31, 2012 at 9:14 AM, cncr04s/Randy <cncr04s at gmail.com> wrote:

> Exactly how much can it cost to serve up those requests... I mean for
> 9$ a month I have a cpu that handles 2000 *Recursive* Queries a

network bandwidth
people/monitoring
router(s)
redundancy
geo-local copies

you are asking the wrong question

-chris


From mfidelman at meetinghouse.net  Thu May 31 10:38:33 2012
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Thu, 31 May 2012 11:38:33 -0400
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
Message-ID: <4FC79079.4020004@meetinghouse.net>

cncr04s/Randy wrote:
> Exactly how much can it cost to serve up those requests... I mean for
> 9$ a month I have a cpu that handles 2000 *Recursive* Queries a
> second. 900 bux could net me *200,000* a second if not more.
> The government overspends on a lot of things..

Looks like you just answered your own question:

> they need some one whos
> got the experience to use a bunch of cheap servers for the resolvers
> and a box that hosts the IPs used and then distributes the query
> packets.

I expect part of what the FBI is paying for is the time of people with 
that expertise.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra




From valdis.kletnieks at vt.edu  Thu May 31 10:39:55 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Thu, 31 May 2012 11:39:55 -0400
Subject: =?windows-1252?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_inevita?=
 =?windows-1252?Q?ble?=
In-Reply-To: Your message of "Thu, 31 May 2012 08:14:40 -0500."
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
Message-ID: <37363.1338478795@turing-police.cc.vt.edu>

On Thu, 31 May 2012 08:14:40 -0500, "cncr04s/Randy" said:

> Exactly how much can it cost to serve up those requests... I mean for
> 9$ a month I have a cpu that handles 2000 *Recursive* Queries a
> second. 900 bux could net me *200,000* a second if not more.
> The government overspends on a lot of things.. they need some one whos
> got the experience to use a bunch of cheap servers for the resolvers
> and a box that hosts the IPs used and then distributes the query
> packets.

For $50/mo I can have a connection from Comcast.  That doesn't mean that
I could run my own cable to the nearest major exchange for anywhere near
$50.

Also, what's the failover if your $9/mo CPU develops a bad RAM card?  Does
your $9/mo CPU have sufficient geographic diversity to survive a backhoe?
And about 4 zillion other things that people that actually have to run production
services worry about...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120531/8c5efd00/attachment-0001.bin>

From drais at icantclick.org  Thu May 31 10:45:12 2012
From: drais at icantclick.org (david raistrick)
Date: Thu, 31 May 2012 11:45:12 -0400 (EDT)
Subject: =?ISO-8859-7?Q?Re=3A_Vixie_warns=3A_DNS_Changer_=A1blackouts=A2_inevitable?=
In-Reply-To: <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1205311143450.46851@murf.icantclick.org>

On Thu, 31 May 2012, cncr04s/Randy wrote:
>>
>
> Exactly how much can it cost to serve up those requests... I mean for
> 9$ a month I have a cpu that handles 2000 *Recursive* Queries a
> second. 900 bux could net me *200,000* a second if not more.
> The government overspends on a lot of things.. they need some one whos
> got the experience to use a bunch of cheap servers for the resolvers
> and a box that hosts the IPs used and then distributes the query
> packets.


So you'd offer your expertise for $9 (or $900) a month 24/7?  Since you 
imply server cost is the only cost in operating such a service......



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org


From thegameiam at yahoo.com  Thu May 31 10:46:46 2012
From: thegameiam at yahoo.com (David Barak)
Date: Thu, 31 May 2012 08:46:46 -0700 (PDT)
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC77434.5000306@foobar.org>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
Message-ID: <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>

?
From: Nick Hilliard <nick at foobar.org>
>If you don't rewrite your transit providers' origin, then you are telling
>them that they can directly influence your exit discrimination policy on
>the basis of a purely advisory flag which has no real meaning.? 

On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"?? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute.? Many providers re-write MED, and apparently some re-write ORIGIN.? Neither of those is "network abuse" - it's more accurately described as "network routing policy."? As has been stated here before: your network, your rules.

?
David Barak
Need Geek Rock? Try The Franchise: 
http://www.listentothefranchise.com

From bicknell at ufp.org  Thu May 31 10:51:41 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 31 May 2012 08:51:41 -0700
Subject: Vixie warns: DNS =?utf-8?Q?Changer_?=
 =?utf-8?B?4oCYYmxhY2tvdXRz4oCZ?= inevitable
In-Reply-To: <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
Message-ID: <20120531155141.GB13781@ussenterprise.ufp.org>

In a message written on Thu, May 31, 2012 at 08:14:40AM -0500, cncr04s/Randy wrote:
> Exactly how much can it cost to serve up those requests... I mean for
> 9$ a month I have a cpu that handles 2000 *Recursive* Queries a
> second. 900 bux could net me *200,000* a second if not more.
> The government overspends on a lot of things.. they need some one whos
> got the experience to use a bunch of cheap servers for the resolvers
> and a box that hosts the IPs used and then distributes the query
> packets.

The interesting bit with DNSChanger isn't serving up the requests,
but the engineering to do it in place.  Remember, all of the clients
are pointed to specific IP addresses by the malware.

The FBI comes in and takes all the servers because they are going
to be used in the court case, and then has to pay someone to figure
out how to stand a service back up at the exact same IP's serving
those infected clients in a way they won't notice.  This includes
include working with the providers of the IP Routing, IP Address
blocks, colocation space and so on to keep providing the service.

In this case it was also pre-planned to be nearly seamless so that
end users would not see any down time, and the servers had to be
fully instrumented to capture all of the infected client IP addresses
and report them to various parties for remediation, including further
evidence to the court for the legal proceedings.  The FBI also had
to convince a judge this was the right thing to do, so I'm sure
someone had to pay some experts to explain all of this to a judge
to make it happen.

I suspect the cost of the hardware to handle the queries is neglegable,
I doubt of all the money spent more than a few thousand dollars
went to the hardware.  It seems like the engineering and coordination
was rather significant here, and I'll bet that's where all the money
was spent.

-- 
       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/20120531/aebd8544/attachment.bin>

From cncr04s at gmail.com  Thu May 31 11:11:38 2012
From: cncr04s at gmail.com (cncr04s/Randy)
Date: Thu, 31 May 2012 11:11:38 -0500
Subject: =?windows-1252?Q?Re=3A_Re=3A_Vixie_warns=3A_DNS_Changer_=91blackouts=92_ine?=
 =?windows-1252?Q?vitable?=
In-Reply-To: <37363.1338478795@turing-police.cc.vt.edu>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
 <37363.1338478795@turing-police.cc.vt.edu>
Message-ID: <CALvoTptsKeGLQ0DXJ0wmTs7fOcB2qBC7O8ax4oa3BY9ZjK6BwA@mail.gmail.com>

On Thu, May 31, 2012 at 10:39 AM,  <valdis.kletnieks at vt.edu> wrote:
> On Thu, 31 May 2012 08:14:40 -0500, "cncr04s/Randy" said:
>
>> Exactly how much can it cost to serve up those requests... I mean for
>> 9$ a month I have a cpu that handles 2000 *Recursive* Queries a
>> second. 900 bux could net me *200,000* a second if not more.
>> The government overspends on a lot of things.. they need some one whos
>> got the experience to use a bunch of cheap servers for the resolvers
>> and a box that hosts the IPs used and then distributes the query
>> packets.
>
> For $50/mo I can have a connection from Comcast. ?That doesn't mean that
> I could run my own cable to the nearest major exchange for anywhere near
> $50.
>
> Also, what's the failover if your $9/mo CPU develops a bad RAM card? ?Does
> your $9/mo CPU have sufficient geographic diversity to survive a backhoe?
> And about 4 zillion other things that people that actually have to run production
> services worry about...

My comment was directed at government spending... no need to have such
a angry tone about the "comment". I was only comparing to what I spend
on my large volumes of queries and what this so called expensive stuff
the government is running...     And I have never developed a bad ram
card, even if I did, replacements are easy as i'm talking about
distributed vps in this case.


From keegan.holley at sungard.com  Thu May 31 11:21:12 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 31 May 2012 12:21:12 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
Message-ID: <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>

2012/5/31 David Barak <thegameiam at yahoo.com>

>
> From: Nick Hilliard <nick at foobar.org>
> >If you don't rewrite your transit providers' origin, then you are telling
> >them that they can directly influence your exit discrimination policy on
> >the basis of a purely advisory flag which has no real meaning.
>
> On what precisely do you base the idea that a mandatory transitive
> attribute of a BGP prefix is a "purely advisory flag which has no real
> meaning"?  I encourage you to reconsider that opinion - it's actually a
> useful attribute, much the way that MED is a useful attribute.  Many
> providers re-write MED, and apparently some re-write ORIGIN.  Neither of
> those is "network abuse" - it's more accurately described as "network
> routing policy."  As has been stated here before: your network, your rules.
>

The internet by definition is a network of network so no one entity can
keep traffic segregated to their network.  Modifying someone else routing
advertisements without their consent is just as bad as filtering them in my
opinion.  Doing so to move traffic into your AS in order to gain an
advantage in peering arrangements and make more money off of the end user
is just dastardly.

The "your network your rules" philosophy doesn't work for something as
large as the internet, or POTS or power grids or RF or anything else that
requires multiple companies to work together.  This is why we have debates
on DPI and network neutrality and such.  What if some country wants to
block youtube and they start advertising bogus routes for it?  What if our
upstreams could shorten our AS paths to 1 or even shorten prefixes to drive
traffic through one AS or another? Giving all control to the network
operators would result in chaos.

From nick at foobar.org  Thu May 31 11:27:16 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 31 May 2012 17:27:16 +0100
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
Message-ID: <4FC79BE4.5040301@foobar.org>

On 31/05/2012 16:46, David Barak wrote:
> On what precisely do you base the idea that a mandatory transitive
> attribute of a BGP prefix is a "purely advisory flag which has no real
> meaning"?

Let's say network A uses cisco kit and injects prefixes into their ibgp
tables using network statements.  The default for this is to set
origin=igp.  On the other hand, network B also uses cisco kit and uses
"redistribute" to inject static routes from their route reflectors.  By
default, these prefixes will have origin=incomplete.  Network C uses
juniper kit, which sets origin=igp for all injected prefixes, regardless of
whether it's via an IGP or some other means.

So, the default origin policy is that unless the originator of an prefix
manually tweaks the origin to be consistent with something that is actually
consistent (with what, I don't know - because there is no good definition
of the difference between, say, igp and incomplete), then different
_syntactic_ network configurations will set the parameter differently, even
if there is no _semantic_ difference in those configs.

This is a pretty random mess.  I do not wish to operate the networks which
I manage on the basis of a parameter which is basically arbitrary and which
can be tuned by an upstream connectivity provider to their advantage based
on their whims.

> I encourage you to reconsider that opinion - it's actually a
> useful attribute, much the way that MED is a useful attribute.  Many
> providers re-write MED, and apparently some re-write ORIGIN.  Neither of
> those is "network abuse" - it's more accurately described as "network
> routing policy."

med is useful in an inter-asn context if you have multiple links into a
specific asn and wish to discriminate between them on the basis of what
that ASN suggests.  Same for origin if you trust that the other ASN has
configured origin in a sensible manner.

MED can be trusted in situations where you have a prescribed policy for
trusting med, preferably backed by a contract which defines the MEDs.
Otherwise, thanks but no thanks.

> As has been stated here before: your network, your rules.

yep, definitely! :-)

Nick



From jlightfoot at gmail.com  Thu May 31 11:38:39 2012
From: jlightfoot at gmail.com (John Lightfoot)
Date: Thu, 31 May 2012 12:38:39 -0400
Subject: =?us-ascii?Q?RE:_Re:_Vixie_warns:_DNS_Changer_'blackouts'_inevitable?=
In-Reply-To: <37363.1338478795@turing-police.cc.vt.edu>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
 <37363.1338478795@turing-police.cc.vt.edu>
Message-ID: <015901cd3f4b$d7a60050$86f200f0$@gmail.com>

> 
> > Exactly how much can it cost to serve up those requests... I mean for
> > 9$ a month I have a cpu that handles 2000 *Recursive* Queries a
> > second. 900 bux could net me *200,000* a second if not more.
> > The government overspends on a lot of things.. they need some one whos
> > got the experience to use a bunch of cheap servers for the resolvers
> > and a box that hosts the IPs used and then distributes the query
> > packets.
> 
> For $50/mo I can have a connection from Comcast.  That doesn't mean that I
> could run my own cable to the nearest major exchange for anywhere near
$50.
> 
> Also, what's the failover if your $9/mo CPU develops a bad RAM card?  Does
> your $9/mo CPU have sufficient geographic diversity to survive a backhoe?
> And about 4 zillion other things that people that actually have to run
production
> services worry about...

Why should the taxpayers pay for geographic diversity or any of those 4
zillion other things required to keep these DNS servers up so infected
computers can continue to reach the Internet?  I don't really mind paying
$9/300 millionths per month to help folks make a smooth transition back to
proper DNS, but I wouldn't want to pay much more.  The FBI should have just
pulled the plug and let the folks who can't connect inundate their ISPs with
support calls, which might encourage the ISPs to be a little more proactive
about shutting down the botnets they host.



From nick at foobar.org  Thu May 31 11:44:00 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 31 May 2012 17:44:00 +0100
Subject: Vixie warns: DNS Changer =?windows-1252?Q?=91blackouts=92_?=
 =?windows-1252?Q?inevitable?=
In-Reply-To: <CALvoTptsKeGLQ0DXJ0wmTs7fOcB2qBC7O8ax4oa3BY9ZjK6BwA@mail.gmail.com>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com> <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
 <37363.1338478795@turing-police.cc.vt.edu>
 <CALvoTptsKeGLQ0DXJ0wmTs7fOcB2qBC7O8ax4oa3BY9ZjK6BwA@mail.gmail.com>
Message-ID: <4FC79FD0.2030100@foobar.org>

On 31/05/2012 17:11, cncr04s/Randy wrote:
> My comment was directed at government spending... no need to have such
> a angry tone about the "comment". I was only comparing to what I spend
> on my large volumes of queries and what this so called expensive stuff
> the government is running...     And I have never developed a bad ram
> card, even if I did, replacements are easy as i'm talking about
> distributed vps in this case.

I'm getting the impression that the ISC involvement with the FBI on this
issue went well beyond the notion of sticking a couple of noddy DNS servers
on the Internet and well into the realm of engineering consultancy, court
appearances, engineering and management all-nighters, providing a level of
trustworthy service that could be justified to a
court of criminal law and so on.  All for $87k?  Personally, I don't have a
problem with that level of expenditure.

Nick


From saku at ytti.fi  Thu May 31 12:06:46 2012
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 31 May 2012 20:06:46 +0300
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
Message-ID: <20120531170646.GA2477@pob.ytti.fi>

On (2012-05-31 08:46 -0700), David Barak wrote:

> On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"?? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute.? Many providers re-write MED, and apparently some re-write ORIGIN.? Neither of those is "network abuse" - it's more accurately described as "network routing policy."? As has been stated here before: your network, your rules.

When provider rewrites MED, they do it, because they don't want peer to
cause them to cold-potato, to which they may have compelling reason.
Then some clever people realise they forgot to rewrite origin, working
around the implicit agreement you had with them.

-- 
  ++ytti


From wayne at tuckerlabs.com  Thu May 31 12:18:48 2012
From: wayne at tuckerlabs.com (Wayne Tucker)
Date: Thu, 31 May 2012 10:18:48 -0700
Subject: BGP ORF in practice
Message-ID: <CAOfiG73yqs7cyajv7KLKCu7uxh5JCSmJfJOjrjBWNr633oABNw@mail.gmail.com>

What's the general consensus (hah! ;) regarding the use of RFC5291 BGP
outbound route filtering?  It's worked well for me in the lab, but I have
yet to use it in a live environment (and I don't know that most service
providers would know what I was talking about if I asked for it).  Does it
work great or does it end up being more pain than it's worth?

Thanks

:w

From ras at e-gerbil.net  Thu May 31 12:22:16 2012
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 31 May 2012 12:22:16 -0500
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
 <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
Message-ID: <20120531172216.GO66560@gerbil.cluepon.net>

On Thu, May 31, 2012 at 12:21:12PM -0400, Keegan Holley wrote:
> The internet by definition is a network of network so no one entity 
> can keep traffic segregated to their network.  Modifying someone else 
> routing advertisements without their consent is just as bad as 
> filtering them in my opinion.  Doing so to move traffic into your AS 
> in order to gain an advantage in peering arrangements and make more 
> money off of the end user is just dastardly.

There was one particularly (in)famous network *coughpeer1cough* which 
was well known for selectively rewriting the origin codes towards their 
peers a few years back. For example, if traffic was going to New York, 
they would advertise the prefix with IGP in New York, and Incomplete 
everywhere else, forcing other networks to haul the traffic to New York. 
This is a violation of most peering agreements, which require consistent 
advertisements unless otherwise agreed, but it was just sneaky enough 
that it flew under the radar of most folks for quite a while. When it 
was finally noticed and they refused to stop doing it when asked, a few 
folks just depeered them, but a bunch of others just "solved the 
problem" by rewriting the origin codes. This is why you still see a lot 
of rewriting happening today by default, to avoid a repeat of the same 
issue.

Personally I was of the opinion that the correct solution to this 
particular problem was just to terminate the peering relationship, but 
honestly Origin code is a pretty useless attribute in the modern 
Internet, and it exists today only because it's impossible to take it 
out of the protocol. I don't see anyone complaining when we rewrite 
someone else's MEDs, sometimes as a trick to move traffic onto your 
network (*), or even that big of a complaint when we remove another 
networks' communities, so I don't see why anyone cares about this one.

Maybe a "better" fix would be a local knob to ignore Origin code in the 
best path decision without having to modify it. Start asking your 
vendors for it now, maybe it'll show up around 2017... :)

(*) I've seen a lot of inexperienced BGP speaking customers be very 
upset that they can't "send any traffic using natural bgp" (yes, there 
appears to be some kind of delusion running around that modifying BGP 
attributes to influence path selection is bad... What's next, "organic 
routes, not from concentrate"? :P), which in the end turned out to be us 
sending the customer MEDs based on our IGP cost, other networks sending 
them MEDs of 0, and them not knowing enough to do something useful with 
the data or else rewrite it to 0.

-- 
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 bicknell at ufp.org  Thu May 31 12:34:39 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 31 May 2012 10:34:39 -0700
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120531172216.GO66560@gerbil.cluepon.net>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
 <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
 <20120531172216.GO66560@gerbil.cluepon.net>
Message-ID: <20120531173439.GA17383@ussenterprise.ufp.org>

In a message written on Thu, May 31, 2012 at 12:22:16PM -0500, Richard A Steenbergen wrote:
> out of the protocol. I don't see anyone complaining when we rewrite 
> someone else's MEDs, sometimes as a trick to move traffic onto your 
> network (*), or even that big of a complaint when we remove another 
> networks' communities, so I don't see why anyone cares about this one.

Take all the politics and contracts out of it, and look at MED from
a 100% pure engineering perspective, with the traditional view that
MED reflects IGP cost, and origin reflects where the route came
from in the first place.

I would argue the right engineering answer is that each network,
on outbound, should set the MED equal to the IGP cost.  Basically
if an ASN gets 4 routes with 4 different MEDS on 4 peering points
and picks the "best", when it passes it on to the next metric the
IGP cost an AS away no longer makes any sense.

If the behavior is for each ASN to inject their own MED on outbound,
then rewriting inbound or outbound is just an extension of the
entirely local policy anyway, no different than changing IGP metrics.
Don't want to reflect IGP metrics, rewrite to a fixed value.

The origin is different, at least conceptually.  The origin type
should reflect the state of the route before it went into BGP, a
property which does not change per-AS hop along the way.

That's why with a pure engineer hat on I would be much more
surprised/upset to see someone rewriting origin while I would expect
them to be rewriting MED.

Of course the real world isn't 100% engineering based.  ISP's do
all sorts of weird and fun things, and customers can (usually) vote
with their dollars.  I don't have a problem with an ISP implementing
pretty much any BGP policy they want /provided they disclose it to
their BGP customers/.

Perhaps if a large number of people were a bit more rational with their
peering policies we wouldn't have enginers dedicated to generating
routing funkyness just to meet peering criteria.  It's not helping
anyone get reliable, high performing network access.

-- 
       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/20120531/83395cc7/attachment.bin>

From rafael at cresci.org  Thu May 31 12:41:09 2012
From: rafael at cresci.org (Rafael Cresci)
Date: Thu, 31 May 2012 14:41:09 -0300
Subject: Syria blackout?
Message-ID: <8ECD7514-4D6B-4704-839C-B040574E30D0@cresci.org>

Customers (from UAE) who have servers with us in Atlanta - one of the companies I work for, remaining anonymus for the moment - are reporting that their sub-customers and viewers from Syria can't access FTP or download any kind of Flash/video/multimedia content from inside that country. Completely blocked.

Anyone confirms?

Another government blockage to avoid social captiruing of massacre videos and photos? 



From rjs at rob.sh  Thu May 31 12:59:41 2012
From: rjs at rob.sh (Rob Shakir)
Date: Thu, 31 May 2012 18:59:41 +0100
Subject: BGP ORF in practice
In-Reply-To: <CAOfiG73yqs7cyajv7KLKCu7uxh5JCSmJfJOjrjBWNr633oABNw@mail.gmail.com>
References: <CAOfiG73yqs7cyajv7KLKCu7uxh5JCSmJfJOjrjBWNr633oABNw@mail.gmail.com>
Message-ID: <18022357-823A-4AA5-94B9-C97B7E7B52D8@rob.sh>


On 31 May 2012, at 18:18, Wayne Tucker wrote:

> What's the general consensus (hah! ;) regarding the use of RFC5291 BGP
> outbound route filtering?  It's worked well for me in the lab, but I have
> yet to use it in a live environment (and I don't know that most service
> providers would know what I was talking about if I asked for it).  Does it
> work great or does it end up being more pain than it's worth?


Hi Wayne,

In my experience, ORF is not particularly widely deployed in live network deployments.

It has some potential to be difficult to manage where implementations begin to experience complexities in building UPDATE message replication groups (where peers have a dynamic advertisement (egress) policy due to ORF, then this may mean that the number of peers with common UPDATE policies reduces, and hence concepts like policy-driven UPDATE groups become less efficient). This may impact the scaling of your BGP speakers in ways that are not easy to model - and hence may be undesirable on PE/border devices where control-plane CPU is a concern.

Further to this, there is, or has been, some disconnect in the modes of ORF that are supported between various speakers - for instance, some vendors support only prefix-based ORF, where others support only RT-based, which causes some barriers to implementation.

In an inter-domain context, I have seen some discussion of ORF as a means by which an L3VPN customer may choose to receive only a subset of their routing information at particular "low feature" sites - but the inter-operability issues mentioned above resulted in this not being deployed. Do you have a similar deployment case?

Cheers,
r.




From smeuse at mara.org  Thu May 31 13:45:16 2012
From: smeuse at mara.org (Steve Meuse)
Date: Thu, 31 May 2012 14:45:16 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
 <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
Message-ID: <CA+3sbiN6DBEM8npwnXX5FUWWRzjvr0n29kqCyBcOB+QkfjFCtg@mail.gmail.com>

On Thu, May 31, 2012 at 12:21 PM, Keegan Holley
<keegan.holley at sungard.com>wrote:

>
> The internet by definition is a network of network so no one entity can
> keep traffic segregated to their network.  Modifying someone else routing
> advertisements without their consent is just as bad as filtering them in my
> opinion.  Doing so to move traffic into your AS in order to gain an
> advantage in peering arrangements and make more money off of the end user
> is just dastardly.
>
>
While this is a nice thought, it's not practical in reality. If you give
someone a knob, they are going to turn it. Someone will look to take
advantage of it.

If you pay me, fine. If you don't pay me, I'm not going to allow you to
potentially cost me significant dollars in infrastructure costs just to
preserve the notion of free love and peering :)

-Steve

From eugen at leitl.org  Thu May 31 13:59:50 2012
From: eugen at leitl.org (Eugen Leitl)
Date: Thu, 31 May 2012 20:59:50 +0200
Subject: [liberationtech] Syria blackout?
Message-ID: <20120531185950.GR17120@leitl.org>

----- Forwarded message from Andrew Lewis <andrew at pdqvpn.com> -----

From: Andrew Lewis <andrew at pdqvpn.com>
Date: Thu, 31 May 2012 14:29:05 -0400
To: Eugen Leitl <eugen at leitl.org>, liberationtech at lists.stanford.edu
Subject: Re: [liberationtech] Syria blackout?
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

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

Not as far as I can tell. Everything seemed to be the same, and my
contacts in Syria haven't reported anything amiss.


On 5/31/12 2:26 PM, Eugen Leitl wrote:
> ----- Forwarded message from Rafael Cresci <rafael at cresci.org>
> -----
> 
> From: Rafael Cresci <rafael at cresci.org> Date: Thu, 31 May 2012
> 14:41:09 -0300 To: nanog at nanog.org Subject: Syria blackout? 
> X-Mailer: Apple Mail (2.1278)
> 
> Customers (from UAE) who have servers with us in Atlanta - one of
> the companies I work for, remaining anonymus for the moment - are
> reporting that their sub-customers and viewers from Syria can't
> access FTP or download any kind of Flash/video/multimedia content
> from inside that country. Completely blocked.
> 
> Anyone confirms?
> 
> Another government blockage to avoid social captiruing of massacre
> videos and photos?
> 
> 
> ----- End forwarded message -----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPx7hxAAoJEJW/J8aB8dYIMEgIAIGuNaBKjCpZDpD7VFx+sig+
rAnmeQzxARQBZixb858qAncpEKP71gDJhdS8tcKRTuTZk8k59/781aFjmnVvCC2j
QRNMmHl6AOggt/5T0VHY+E3ixm7mAOTM3TtumlwPNKKecI6GzzP1CDkAyvnSUKU7
FpDzv4JrsRCJZrtv0Sg5A5ijvWf3JT020sCjTchC05/FTaqjukmOvAGm9vrh2eFy
bDUprMD83tqVDpKeCtRWhh+v4L9nXgoRBYoJ0JOnP1A+/wcFCk3AVNL9VcS1zZHQ
TlI/1WbbL9MNtZg+GIv5ZgDtiIpgy/hqk9tBWh/ZSM79YTX/dAw17vK3TpZ4Rww=
=58O+
-----END PGP SIGNATURE-----

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


From eugen at leitl.org  Thu May 31 14:01:00 2012
From: eugen at leitl.org (Eugen Leitl)
Date: Thu, 31 May 2012 21:01:00 +0200
Subject: [liberationtech] Syria blackout?
Message-ID: <20120531190100.GS17120@leitl.org>

----- Forwarded message from Andrew <andrew at pdqvpn.com> -----

From: Andrew <andrew at pdqvpn.com>
Date: Thu, 31 May 2012 14:36:22 -0400
To: liberationtech at lists.stanford.edu
Subject: Re: [liberationtech] Syria blackout?
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1

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

And it looks like I maybe wrong. It seems that torrents, and videos
stopped working sometime yesterday. I am going to do some more
digging. Tor, and some specific types of VPNs still seem to be working
fine.

- -Andrew

On 5/31/2012 2:26 PM, Eugen Leitl wrote:
> ----- Forwarded message from Rafael Cresci <rafael at cresci.org>
> -----
> 
> From: Rafael Cresci <rafael at cresci.org> Date: Thu, 31 May 2012
> 14:41:09 -0300 To: nanog at nanog.org Subject: Syria blackout? 
> X-Mailer: Apple Mail (2.1278)
> 
> Customers (from UAE) who have servers with us in Atlanta - one of
> the companies I work for, remaining anonymus for the moment - are
> reporting that their sub-customers and viewers from Syria can't
> access FTP or download any kind of Flash/video/multimedia content
> from inside that country. Completely blocked.
> 
> Anyone confirms?
> 
> Another government blockage to avoid social captiruing of massacre
> videos and photos?
> 
> 
> ----- End forwarded message -----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPx7omAAoJEJW/J8aB8dYIUkYIAJtSxAFptjkShh3rpYXPKXpi
7wXj77j126e5mk5Dd/XpR1VuiRyTBbBt+fscRWZaW1c6IvDTe9YjrYDMFUcq3tns
dWCvqD+sMowhB9UGnx9zOe+mJwOoMMqAI6rWtewNKQPlgDbA+wzVujGsLHT1jdYz
YGujXrCudM2+w79uL79vmJRJ/r6DgaUDgif5beubEdcTzP0uGL3zg8rhCAQ1Oh6I
qKHV9AdC4jEmGmz0Abd0KoCpVrEyI4QypD7TiCToo+Uc3TSjtXcRmxmZiT+183FH
YCg8JBEYqFSArmk8S5YXxxQwDYvYN83jTp8Esrrlh8Rae22f45E7EXDw6xV0qlo=
=57kz
-----END PGP SIGNATURE-----
_______________________________________________
liberationtech mailing list
liberationtech at lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


From andrew at pdqvpn.com  Thu May 31 14:28:49 2012
From: andrew at pdqvpn.com (Andrew)
Date: Thu, 31 May 2012 15:28:49 -0400
Subject: [liberationtech] Syria blackout?
In-Reply-To: <20120531190100.GS17120@leitl.org>
References: <20120531190100.GS17120@leitl.org>
Message-ID: <4FC7C671.5040109@pdqvpn.com>

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

And as a follow up on this list:

I have one report from one ISP(Sawa) that things are blocked. I am now
trying to collect more info to see if it is something implemented at
the ISP level or something at the exit points for the entire country.
These international connections fall under the control of STE(State
Telecom Establishment) and the PDN/PDN2 backbone that they control,
which everyone else rides on top of. In the past all blocking was
ordered and relayed through STE, but implemented at the ISP level.
This resulted in discrepancies and uneven filtering as ISP choose to
interpret the rules a little differently, as well as using different
to tech to implement the orders from the Syrian Government. If this is
a uniform block across all ISPs, then it indicates that STE has
stepped in and and taken responsibility. It also indicates that they
may have acquired new gear, as they did not have the capacity or
skills to take part in such activity in the past.

- -Andrew

On 5/31/2012 3:01 PM, Eugen Leitl wrote:
> ----- Forwarded message from Andrew <andrew at pdqvpn.com> -----
> 
> From: Andrew <andrew at pdqvpn.com> Date: Thu, 31 May 2012 14:36:22
> -0400 To: liberationtech at lists.stanford.edu Subject: Re:
> [liberationtech] Syria blackout? User-Agent: Mozilla/5.0 (Windows
> NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
> 
> And it looks like I maybe wrong. It seems that torrents, and
> videos stopped working sometime yesterday. I am going to do some
> more digging. Tor, and some specific types of VPNs still seem to be
> working fine.
> 
> -Andrew
> 
> On 5/31/2012 2:26 PM, Eugen Leitl wrote:
>> ----- Forwarded message from Rafael Cresci <rafael at cresci.org> 
>> -----
> 
>> From: Rafael Cresci <rafael at cresci.org> Date: Thu, 31 May 2012 
>> 14:41:09 -0300 To: nanog at nanog.org Subject: Syria blackout? 
>> X-Mailer: Apple Mail (2.1278)
> 
>> Customers (from UAE) who have servers with us in Atlanta - one
>> of the companies I work for, remaining anonymus for the moment -
>> are reporting that their sub-customers and viewers from Syria
>> can't access FTP or download any kind of Flash/video/multimedia
>> content from inside that country. Completely blocked.
> 
>> Anyone confirms?
> 
>> Another government blockage to avoid social captiruing of
>> massacre videos and photos?
> 
> 
>> ----- End forwarded message -----
> 
> _______________________________________________ liberationtech
> mailing list liberationtech at lists.stanford.edu
> 
> Should you need to change your subscription options, please go to:
> 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> If you would like to receive a daily digest, click "yes" (once you
> click above) next to "would you like to receive list mail batched
> in a daily digest?"
> 
> You will need the user name and password you receive from the list
> moderator in monthly reminders. You may ask for a reminder here:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> Should you need immediate assistance, please contact the list
> moderator.
> 
> Please don't forget to follow us on
> http://twitter.com/#!/Liberationtech
> 
> ----- End forwarded message -----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPx8ZwAAoJEJW/J8aB8dYIPwEIAKAXT5KXyflBeqA+ZTDWa3I5
9hYGKmAEjN6VQfav7eoAFIn/w+5qrntfSrMIgrMykSbUSDNAL4gN5rZ4SOa8DtIA
amITGi3+XgxUnohPBgrRfJDoE71X3W6pIJwEwUqPc5c79kpH8Q3/Bk0XKb9yyvO1
zT/8XFnMYgBmeCvqxnMvpsoL7GCzbQ1tgKDeZbIqo7x6caDESbk40goNuMXpo6XH
bEQoD8YdwuflSIjHgp0VcveDj78frFAoo3e/5gUcCmvpOKl+Wf+PLfkf3U1Qs6yb
K9Si+F0RJNEAQ647xKlJB24x5GmYauBCiz5j3qvzMUAkwBmeD3QhHhCpmKnN24A=
=L9gH
-----END PGP SIGNATURE-----


From keegan.holley at sungard.com  Thu May 31 15:02:01 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 31 May 2012 16:02:01 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120531172216.GO66560@gerbil.cluepon.net>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
 <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
 <20120531172216.GO66560@gerbil.cluepon.net>
Message-ID: <CABO8Q6T9TQ5vEfiSW68cQ2AE=qKd9WBJA+40Q2BJ5g9yBzqdCw@mail.gmail.com>

2012/5/31 Richard A Steenbergen <ras at e-gerbil.net>

> On Thu, May 31, 2012 at 12:21:12PM -0400, Keegan Holley wrote:
> > The internet by definition is a network of network so no one entity
> > can keep traffic segregated to their network.  Modifying someone else
> > routing advertisements without their consent is just as bad as
> > filtering them in my opinion.  Doing so to move traffic into your AS
> > in order to gain an advantage in peering arrangements and make more
> > money off of the end user is just dastardly.
>
> There was one particularly (in)famous network *coughpeer1cough* which
> was well known for selectively rewriting the origin codes towards their
> peers a few years back. For example, if traffic was going to New York,
> they would advertise the prefix with IGP in New York, and Incomplete
> everywhere else, forcing other networks to haul the traffic to New York.
> This is a violation of most peering agreements, which require consistent
> advertisements unless otherwise agreed, but it was just sneaky enough
> that it flew under the radar of most folks for quite a while. When it
> was finally noticed and they refused to stop doing it when asked, a few
> folks just depeered them, but a bunch of others just "solved the
> problem" by rewriting the origin codes. This is why you still see a lot
> of rewriting happening today by default, to avoid a repeat of the same
> issue.
>
> Personally I was of the opinion that the correct solution to this
> particular problem was just to terminate the peering relationship, but
> honestly Origin code is a pretty useless attribute in the modern
> Internet, and it exists today only because it's impossible to take it
> out of the protocol. I don't see anyone complaining when we rewrite
> someone else's MEDs, sometimes as a trick to move traffic onto your
> network (*), or even that big of a complaint when we remove another
> networks' communities, so I don't see why anyone cares about this one.
>
> It's hard to catch when someone is modifying your advertisements.  Also, I
don't expect MED to be compared globally since different networks will
handle it differently so chances are I'm just using it to contol traffic to
and from a directly connected ISP.  If you rewrite it to do the same thing
with your upstreams I probably won't care as long as latency and hop count
remain reasonable.  That being said I've seen an upstream mess with
local-pref in their AS and then again upstream from them and began pulling
traffic literally into a different country.  That IMHO is egregious.


> Maybe a "better" fix would be a local knob to ignore Origin code in the
> best path decision without having to modify it. Start asking your
> vendors for it now, maybe it'll show up around 2017... :)
>

I still think it would cool if BGP had an AS topology database of some
sort, but that's too expensive.  Most BGP policies are not very
deterministic in my experience.

>
> (*) I've seen a lot of inexperienced BGP speaking customers be very
> upset that they can't "send any traffic using natural bgp" (yes, there
> appears to be some kind of delusion running around that modifying BGP
> attributes to influence path selection is bad... What's next, "organic
> routes, not from concentrate"? :P), which in the end turned out to be us
> sending the customer MEDs based on our IGP cost, other networks sending
> them MEDs of 0, and them not knowing enough to do something useful with
> the data or else rewrite it to 0.
>
>
Well less than ten years ago I remember hearing that BGP was only for ISP's
or very large enterprises and most people should try to run an IGP only.  I
still hear from companies who are nervous about running BGP with a private
MPLS provider.  Old habits die hard I guess..

From keegan.holley at sungard.com  Thu May 31 15:04:54 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 31 May 2012 16:04:54 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <CA+3sbiN6DBEM8npwnXX5FUWWRzjvr0n29kqCyBcOB+QkfjFCtg@mail.gmail.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
 <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
 <CA+3sbiN6DBEM8npwnXX5FUWWRzjvr0n29kqCyBcOB+QkfjFCtg@mail.gmail.com>
Message-ID: <CABO8Q6Qf7pk2EGA3Vd5Y_eFi-W7W0Zo5K+xzGe=bz6LXFcu2fw@mail.gmail.com>

2012/5/31 Steve Meuse <smeuse at mara.org>

>
>
> On Thu, May 31, 2012 at 12:21 PM, Keegan Holley <keegan.holley at sungard.com
> > wrote:
>
>>
>> The internet by definition is a network of network so no one entity can
>> keep traffic segregated to their network.  Modifying someone else routing
>> advertisements without their consent is just as bad as filtering them in
>> my
>> opinion.  Doing so to move traffic into your AS in order to gain an
>> advantage in peering arrangements and make more money off of the end user
>> is just dastardly.
>>
>>
> While this is a nice thought, it's not practical in reality. If you give
> someone a knob, they are going to turn it. Someone will look to take
> advantage of it.
>
>  If you pay me, fine. If you don't pay me, I'm not going to allow you to
> potentially cost me significant dollars in infrastructure costs just to
> preserve the notion of free love and peering :)
>

If you consider not mucking with my advertisements and those of my
customers "free love" then I hope you don't work for one of my upstreams.
Likewise, if you consider not hijacking my traffic to drive up revenue as
"cost".  Anything to make a buck I suppose.  sigh..

From rgolodner at infratection.com  Thu May 31 15:27:54 2012
From: rgolodner at infratection.com (Richard Golodner)
Date: Thu, 31 May 2012 15:27:54 -0500
Subject: Vixie warns: DNS Changer
 =?UTF-8?Q?=E2=80=98blackouts=E2=80=99?= inevitable
In-Reply-To: <4FC79FD0.2030100@foobar.org>
References: <1337739256.83913.YahooMailNeo@web180310.mail.gq1.yahoo.com>
 <m2zk8zbmdy.wl%randy@psg.com>
 <9F94CA28-4295-4F5D-8548-1F988FDDF2AB@kapu.net>
 <20120523041040.GC23282@vacation.karoshi.com.>
 <7B628519-76AE-43A1-B023-8A9F129FF158@kapu.net>
 <4fbc7867.839f2a0a.6258.ffffe59cSMTPIN_ADDED@mx.google.com>
 <CAL9jLaZezSdhOijCcBAQ2F_tfXF3OyAB552oz=3PPQV6uxM7UA@mail.gmail.com>
 <20120523210027.GA26231@vacation.karoshi.com.>
 <87likculjh.fsf@mid.deneb.enyo.de>
 <CALvoTpvCJV66xVo-JEud-Zk57tF9KocAiDKjqR15=VADRE8DRg@mail.gmail.com>
 <37363.1338478795@turing-police.cc.vt.edu>
 <CALvoTptsKeGLQ0DXJ0wmTs7fOcB2qBC7O8ax4oa3BY9ZjK6BwA@mail.gmail.com>
 <4FC79FD0.2030100@foobar.org>
Message-ID: <1338496074.2073.8.camel@Andromeda>

	Is it time to drop this yet? Three weeks old. Let's move on.
	Richard Golodner
	



From izaac at setec.org  Thu May 31 16:34:02 2012
From: izaac at setec.org (Izaac)
Date: Thu, 31 May 2012 17:34:02 -0400
Subject: Current IPv6 state of US Mobile Phone Carriers
In-Reply-To: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
References: <CAG_ecaEtKhfeocBVno8gjNx=weMYQrxXOvUe1X1bHagz-a5=hw@mail.gmail.com>
Message-ID: <20120531T213250Z@localhost>

On Tue, May 22, 2012 at 04:00:21PM -0700, Paul Porter wrote:
> 1.  How much of the carrier core and edge for AT&T, Verizon. T-Mobile, and
> Sprint are on IPv6 now?

http://mailman.nanog.org/pipermail/nanog/2010-February/018940.html

Still doesn't work.  Gave up doing solicitations for native addressing.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__


From eugen at leitl.org  Thu May 31 16:43:08 2012
From: eugen at leitl.org (Eugen Leitl)
Date: Thu, 31 May 2012 23:43:08 +0200
Subject: [liberationtech] Syria blackout?
Message-ID: <20120531214308.GZ17120@leitl.org>

----- Forwarded message from KheOps <kheops at ceops.eu> -----

From: KheOps <kheops at ceops.eu>
Date: Thu, 31 May 2012 23:11:37 +0200
To: liberationtech at lists.stanford.edu
Subject: Re: [liberationtech] Syria blackout?
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Yes, this has been confirmed by several people we know there.

Tor seems to be blocked at least on 3G connections. Download of some
file extensions through cleartext HTTP is blocked too (mp4, flv, mpg, ...).

It seems UltraSurf and some other VPNs are blocked too, though as Andrew
said, some other specific ones continue working.

For Tor, it would be worth setting up obfsproxy-equipped bridges. We
will try to work on this asap on our side.

KheOps

On 05/31/2012 08:36 PM, Andrew wrote:
> And it looks like I maybe wrong. It seems that torrents, and videos
> stopped working sometime yesterday. I am going to do some more
> digging. Tor, and some specific types of VPNs still seem to be working
> fine.
> 
> -Andrew
> 
> On 5/31/2012 2:26 PM, Eugen Leitl wrote:
>> ----- Forwarded message from Rafael Cresci <rafael at cresci.org>
>> -----
> 
>> From: Rafael Cresci <rafael at cresci.org> Date: Thu, 31 May 2012
>> 14:41:09 -0300 To: nanog at nanog.org Subject: Syria blackout? 
>> X-Mailer: Apple Mail (2.1278)
> 
>> Customers (from UAE) who have servers with us in Atlanta - one of
>> the companies I work for, remaining anonymus for the moment - are
>> reporting that their sub-customers and viewers from Syria can't
>> access FTP or download any kind of Flash/video/multimedia content
>> from inside that country. Completely blocked.
> 
>> Anyone confirms?
> 
>> Another government blockage to avoid social captiruing of massacre
>> videos and photos?
> 
> 
>> ----- End forwarded message -----
> 
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
> 
> Should you need to change your subscription options, please go to:
> 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"
> 
> You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> Should you need immediate assistance, please contact the list moderator.
> 
> Please don't forget to follow us on http://twitter.com/#!/Liberationtech




_______________________________________________
liberationtech mailing list
liberationtech at lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


From nick at foobar.org  Thu May 31 17:10:31 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 31 May 2012 23:10:31 +0100
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <CABO8Q6Qf7pk2EGA3Vd5Y_eFi-W7W0Zo5K+xzGe=bz6LXFcu2fw@mail.gmail.com>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
 <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
 <4FC77434.5000306@foobar.org>
 <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
 <CABO8Q6Sxd4CsSJWPwpL1FzpVMKXGgf9FFwCw+RVKyNvP48q=tQ@mail.gmail.com>
 <CA+3sbiN6DBEM8npwnXX5FUWWRzjvr0n29kqCyBcOB+QkfjFCtg@mail.gmail.com>
 <CABO8Q6Qf7pk2EGA3Vd5Y_eFi-W7W0Zo5K+xzGe=bz6LXFcu2fw@mail.gmail.com>
Message-ID: <4FC7EC57.1060303@foobar.org>

On 31/05/2012 21:04, Keegan Holley wrote:
> If you consider not mucking with my advertisements and those of my
> customers "free love" then I hope you don't work for one of my upstreams.
> Likewise, if you consider not hijacking my traffic to drive up revenue as
> "cost".  Anything to make a buck I suppose.  sigh..

solution:

> route-map rm-transit-in permit 1
>  continue
>  set origin igp
> route-map rm-transit-in permit 10
>  [...]

It sucks slightly, but not very much.  For sure, a lot less than the
suckage that happens when your transit provider stomps around with origin
from their learned prefixes.

Nick


From jra at baylink.com  Thu May 31 19:11:22 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 31 May 2012 20:11:22 -0400 (EDT)
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com>
Message-ID: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>

"The proposal comes from Alex Stamos of research firm iSec Partners, and 
would appoint Artemis Internet as the gatekeeper of .secure. Artemis would 
require registered domains to encrypt all web and email traffic (except for 
HTTP redirects funneling connections towards the appropriate TLS-encrypted 
site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam 
prevention. In addition, Artemis would employ a rigorous screening process to 
verify registrants' identities (including reviewing articles of incorporation 
and human interviews), and routinely conduct security scans of registered 
sites. The venture has $9.6 million (US) in funding provided by Artemis'
parent company NCC Group, a UK-based IT security firm."

  https://lwn.net/Articles/497254/

Discuss.  Debate.  Digress.

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 31 19:19:51 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 31 May 2012 20:19:51 -0400 (EDT)
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
Message-ID: <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> Subject: Wacky Weekend: The '.secure' gTLD

I see that LWN has already spotted this; smb will no doubt be pleased to 
know that the very first reply suggests that RFC 3514 solves the problem
much more easily.

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 rubensk at gmail.com  Thu May 31 19:29:49 2012
From: rubensk at gmail.com (Rubens Kuhl)
Date: Thu, 31 May 2012 21:29:49 -0300
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>
References: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
 <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAGFn2k3_7CkPtxgF_FqVZZ7Z-c_fRwtmmsPQKu9T=4qb6nUfGw@mail.gmail.com>

On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth <jra at baylink.com> wrote:
> ----- Original Message -----
>> From: "Jay Ashworth" <jra at baylink.com>
>
>> Subject: Wacky Weekend: The '.secure' gTLD
>
> I see that LWN has already spotted this; smb will no doubt be pleased to
> know that the very first reply suggests that RFC 3514 solves the problem
> much more easily.

In the domain business we don't need a new RFC to know that everything
that is evil will end in .evil, and everything else is not evil. No
need to define a new bitmask field.


Rubens


From shortdudey123 at gmail.com  Thu May 31 19:43:43 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Thu, 31 May 2012 19:43:43 -0500
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <CAGFn2k3_7CkPtxgF_FqVZZ7Z-c_fRwtmmsPQKu9T=4qb6nUfGw@mail.gmail.com>
References: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
 <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>
 <CAGFn2k3_7CkPtxgF_FqVZZ7Z-c_fRwtmmsPQKu9T=4qb6nUfGw@mail.gmail.com>
Message-ID: <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>

I think this is an interesting concept, but i don't know how well it will
hold up in the long run.  All the initial verification and continuous
scanning will no doubtingly give the .secure TLD a high cost relative to
other TLD's.

-Grant

On Thu, May 31, 2012 at 7:29 PM, Rubens Kuhl <rubensk at gmail.com> wrote:

> On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth <jra at baylink.com> wrote:
> > ----- Original Message -----
> >> From: "Jay Ashworth" <jra at baylink.com>
> >
> >> Subject: Wacky Weekend: The '.secure' gTLD
> >
> > I see that LWN has already spotted this; smb will no doubt be pleased to
> > know that the very first reply suggests that RFC 3514 solves the problem
> > much more easily.
>
> In the domain business we don't need a new RFC to know that everything
> that is evil will end in .evil, and everything else is not evil. No
> need to define a new bitmask field.
>
>
> Rubens
>
>

From Sherif_Hashem at hms.harvard.edu  Thu May 31 19:49:49 2012
From: Sherif_Hashem at hms.harvard.edu (Hashem, Sherif Rakhaa)
Date: Thu, 31 May 2012 20:49:49 -0400
Subject: Wikipedia Timing Out
Message-ID: <3C43EC49B7AF084BA385F946485B1F4C5446414CED@ITCCRMAIL02.MED.HARVARD.EDU>

Is Wikipedia timing out for anyone else from the Metro Boston area?

Thanks,
Sherif

Harvard Medical School | Network Operations
107 Avenue Louis Pasteur | Vanderbilt Hall Suite 021| Boston, MA, 02115
d: (617)999-6816  | c: (617)999-7818 | f: (617)998-6663


From nanog-post at rsuc.gweep.net  Thu May 31 19:50:14 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Thu, 31 May 2012 20:50:14 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC75565.4000404@foobar.org>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
Message-ID: <20120601005012.GA27422@gweep.net>

On Thu, May 31, 2012 at 12:26:29PM +0100, Nick Hilliard wrote:
> On 31/05/2012 11:23, Daniel Suchy wrote:
> > In my experience, there're not so many service providers
> > doing that.
> 
> Plenty of providers do it.  IIWY, I would universally rewrite origin at
> your ingress points to be the same; otherwise you'll find that providers
> will merely use it as a means of influencing the bgp best path decision
> algorithm so that they end up with more of your traffic, and can
> consequently charge you more.  There are many useful ways to build a
> multi-exit discrimination policy.  Using origin is not one of them, in my
> opinion.

I never encountered someone I paid doing this, but infrastructure-cheap 
peers who stretched virtual circuits to meet peering point requirements
then tried to attract traffic away from those links were doing it for 
years. I had the policy to overwrite peer's origin if they were
inconsistant at will for 6079 in the early 2000s.


-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG


From robertg at garlic.com  Thu May 31 19:50:41 2012
From: robertg at garlic.com (Robert Glover)
Date: Thu, 31 May 2012 17:50:41 -0700
Subject: West Coast Charter Outage
Message-ID: <4FC811E1.20200@garlic.com>

Does anyone have any information on a Charter outage on the West Coast?


From mike at mtcc.com  Thu May 31 19:57:11 2012
From: mike at mtcc.com (Michael Thomas)
Date: Thu, 31 May 2012 17:57:11 -0700
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>
References: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
 <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>
 <CAGFn2k3_7CkPtxgF_FqVZZ7Z-c_fRwtmmsPQKu9T=4qb6nUfGw@mail.gmail.com>
 <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>
Message-ID: <4FC81367.4010509@mtcc.com>

On 05/31/2012 05:43 PM, Grant Ridder wrote:
> I think this is an interesting concept, but i don't know how well it will
> hold up in the long run.  All the initial verification and continuous
> scanning will no doubtingly give the .secure TLD a high cost relative to
> other TLD's.
>

Countries would never all agree on what the definition of "secure"
was, so clearly we'll have to have

secure.ly
secure.it
secure.us
secure.no
...

Mike


From fred at cisco.com  Thu May 31 20:16:21 2012
From: fred at cisco.com (Fred Baker)
Date: Thu, 31 May 2012 18:16:21 -0700
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>
References: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
 <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>
 <CAGFn2k3_7CkPtxgF_FqVZZ7Z-c_fRwtmmsPQKu9T=4qb6nUfGw@mail.gmail.com>
 <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>
Message-ID: <B121E0B3-A242-454F-B2D5-F6FF52D932F8@cisco.com>


On May 31, 2012, at 5:43 PM, Grant Ridder wrote:

> I think this is an interesting concept, but i don't know how well it will
> hold up in the long run.  All the initial verification and continuous
> scanning will no doubtingly give the .secure TLD a high cost relative to
> other TLD's.

not necessarily. It can be done with a laptop that does "dig" and sends email to the place.

What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. "What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem?"

BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM headers in it. It's getting the policy in place that if a domain is known to be using DKIM, to drop traffic from it that isn't signed or for which the signature fails.

You may find the following exchange with my military son, whose buddies apparently call me "skynet", amusing...

Begin forwarded message:

> From: Fred Baker <fred at cisco.com>
> Date: May 9, 2012 12:55:40 PM PDT
> To: Colin Baker <...>
> Subject: Re: skynet
> 
> On May 9, 2012, at 2:14 PM, Colin Baker wrote:
>> so my friends and i have taken to calling you 'Skynet' since you
>> invented the internet and have full access to all technological
>> secrets...
>> 
>> A question came up last night regarding phishing attempts.  When we
>> call our banks or other companies, we have to identify as the customer
>> by giving specific info such as mother's maiden name, password, last
>> 4, etc.  That is so the company knows that this is us and not an
>> identify thief.
>> 
>> Why dont companies have to do the same thing with us?  I could get a
>> random call from someone claiming to be Wells Fargo, but they dont
>> have to do anything like 'the wells fargo secret code is 117 and the
>> authentication for me to call about your account is 7G.'  would it
>> make sense to have that sort of two-way authentication?
>> 
>> We thought you might know, since your hands are in every realm of
>> current business practices, technology, and you read the encyclopedia
>> as a kid.
> 
> Well, show this to your buddies.
> 
> If you're using Apple Mail, right now, go to the "View" bar, go down to "Message", and from there to "Raw Source". An email message contains two parts - one that is the email itself, and one (called the "envelope") that contains information used in sending the message around. There will be several lines that start with "Received:"; they tell you that the message was received by a specific Mail Transfer Agent (an application running on a computer) at a certain time; if there are several of them, you can infer that the MTA that received it sent it to the next, and if you're looking for delays in mail transfer, a large difference in time is a smoking weapon saying where that delay was.
> 
> Also in the envelope, you may find a datum that looks like:
> 
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
>> d=cisco.com; i=tli at cisco.com; l=319; q=dns/txt;
>> s=iport; t=1336587580; x=1337797180;
>> h=subject:mime-version:from:in-reply-to:date:cc:
>>  content-transfer-encoding:message-id:references:to;
>> bh=cXlHIR7jgb7lDsoGWEAx6MS6AJ7zJwnnwkO+N7lsBqs=;
>> b=gks8REH7Yho0kcjPt/+H8FJMmi0qF/tZ/mpARWFevTiObT64ZaXog3+k
>>  tDKdaPOAYQYJ8OoJfT/ynOGdtOnN87adlM0lUoDgY5s7bg6juBnaSESG0
>>  UMo18OTQiwuXzV94LNzNSl3lsH++1tfzbsNJe1p+TzjGtBljFoQgMZu4l
>>  c=;
> 
> That particular one is from an email sent to me by a colleague named Tony Li <tli at cisco.com>, who is a Cisco employee. It gives you proof that the message originated from Cisco, and in this case, that Cisco believes that it was originated by Tony Li.
> 
> I'll bet you find a similar thing in this very note.
> 
> "DKIM" stands for "Domain Keys Identified Mail", and is used by Google, Yahoo, and Cisco among others. Here's the DKIM Information Element from the email you sent me:
> 
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>>       d=gmail.com; s=20120113;
>>       h=mime-version:date:message-id:subject:from:to:content-type;
>>       bh=+PAULPy6MwBt3TU1am4I5yRRvfudEeK0k2nzWGCD6kY=;
>>       b=aKMwdM9q/Jh72pJ51i3Kyumy6wIMk6osgAfCyukFh2ATgiy3yWuu5oam4/DgRvo81+
>>        OD0xeYqSyTx2Z2qjUxHtz9kl5nxCkNWlePbOjefog0gfPH1nKN/Kw/562k7OFvl3WeXd
>>        hOIfpNOZb+W5wBIavFg9HKLvr8oDCcNNNkAx0c4WlynMNodcpQVkFchsYDFfV0x5jNme
>>        st/+XLCNmjE1h73/WGmRn3AVJ7WaHKWWdW8PDKw2p1HLnrN8l1FCDeWDX6dMHtABSLuH
>>        C5ScenHkhgPDcAyDdjSmVqEPmuaUB4GU7BaNRqwsUMjcvJZxYuOETux05pBYY2HpRYTC
>>        D6yQ==
> 
> The theory is that if someone (your MTA, not your computer) receives such an information element, it can apply a policy. The policy might say 
> 
> - "I don't think that domain <> implements DKIM, so I'll just accept the message", or 
> - "I think it does, but this email doesn't have one, so obviously this isn't from that domain and therefore is bogus; I'll drop it", or 
> - "I think it does, and this email has one, but the signature is bogus; I'll drop it", or 
> - "I think it does, and this email has one that checks out, so I'll deliver it to Lt Baker".
> 
> There is another approach, called Secure MIME or S/MIME. Your military mail system uses it. It puts a signature on every email that you send, so we can definitively say that you personally sent it, and if we get an email from a military address that either has no signature or the signature is invalid, we can drop it. S/MIME has an additional capability - it can encrypt the mail, and it can even encrypt it in a way that only the person you sent it to can read it.
> 
> Policy.
> 
> What if nobody implements the policy? We all put signatures on our mail, but nobody checks them?
> 
> Phishing. That's what happens.
> 
> We're trying to make the network self-aware. We need to make the humans self-aware before we can do that.


> Oh, I should have also said something else.
> 
> In addition, we are capable of authenticating a user that sends an email. Again assuming that you're using Apple Mail, go to the "Mail" header on the upper bar, to "Preferences", to "Accounts", to your outgoing mail server (SMTP), to "Edit SMTP Server List", to "Advanced". You'll see there that you can select a different port for mail, and that you have the option of using the Secure Sockets Layer (SSL) between you and your first MTA - your SMTP mail server. If that is configured, the server can say it knows for sure that the mail originated with you, and can therefore apply the DKIM signature.
> 
> I mentioned that I'm getting spam from Austin's YAHOO account; I wonder if you are. YAHOO uses DKIM as well, but whoever is really sending it is tricking YAHOO into believing the email is from Austin, which I suspect means that either YAHOO isn't using SSL or someone got Austin's credentials. 
> 
> There are two weak links. People using the tools, and network administrators using the tools. If they are actually used, as far as we know they work. They are often not or only partially used.


From mike at mtcc.com  Thu May 31 21:08:34 2012
From: mike at mtcc.com (Michael Thomas)
Date: Thu, 31 May 2012 19:08:34 -0700
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <B121E0B3-A242-454F-B2D5-F6FF52D932F8@cisco.com>
References: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
 <28606200.6922.1338509991586.JavaMail.root@benjamin.baylink.com>
 <CAGFn2k3_7CkPtxgF_FqVZZ7Z-c_fRwtmmsPQKu9T=4qb6nUfGw@mail.gmail.com>
 <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>
 <B121E0B3-A242-454F-B2D5-F6FF52D932F8@cisco.com>
Message-ID: <4FC82422.4050907@mtcc.com>

On 05/31/2012 06:16 PM, Fred Baker wrote:
>
> not necessarily. It can be done with a laptop that does "dig" and sends email to the place.
>
> What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. "What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem?"
>
> BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM headers in it. It's getting the policy in place that if a domain is known to be using DKIM, to drop traffic from it that isn't signed or for which the signature fails.

Wow, I wouldn't have expected such a deep dive on DKIM here, but...

Last I heard, where we're at is sort of bilateral agreements between the
paypals of the world telling the gmails of the world to drop broken/missing
DKIM signatures. And that is between pretty specialized situations -- it
doesn't apply to corpro-paypal denizens, just their transactional mail.
The good news is that even though it's specialized, it's both high volume
and high value.

The big problem with a larger scope -- as we found out when I was still
at Cisco -- is that it's very difficult for $MEGACORP to hunt down
all of the sources of legitimate email that is sent in the name of
$MEGACORP. Some of these mail producers are ages old, unowned,
unmaintained, and still needed. It's very difficult to find them all,
let alone remediate them. So posting some policy like "DROP IF
NOT SIGNED" will send false positives to an unacceptable level
for $MEGACORP.  So the vast majority of Cisco's email is signed, but
not all of it. After 4 years away, I would be very surprised to hear that
has changed because IT really doesn't have much motivation to hunt
it all down even if it ultimately lead to being able to make a stronger
statement.

One other thing:

>> That particular one is from an email sent to me by a colleague named Tony Li<tli at cisco.com>, who is a Cisco employee. It gives you proof that the message originated from Cisco, and in this case, that Cisco believes that it was originated by Tony Li.

In reality, Cisco doesn't know that's it really coming from Tony Li. We
never required authentication to submission servers. And even if we
did, it wouldn't be conclusive, of course.

A valid DKIM signature really says: "we Cisco take responsibility for this
email". If it's spam, if it's spoofed from a bot, if it's somebody having
dubious fun spoofing Tony Li... you get no guarantee as the receiving
MTA that it isn't one of those, but you can reasonable complain to
Cisco if you're getting them because it's going through their
infrastructure. I think that's an incremental improvement because it
was far too easy for the $ISP's of the world to blow off complaints of
massive botnets on their networks because they could just say that
it must have been spoofed. If they sign their mail, it's now their
responsibility.

Mike



From johnl at iecc.com  Thu May 31 21:52:43 2012
From: johnl at iecc.com (John Levine)
Date: 1 Jun 2012 02:52:43 -0000
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <B121E0B3-A242-454F-B2D5-F6FF52D932F8@cisco.com>
Message-ID: <20120601025243.53806.qmail@joyce.lan>

>What will drive the price up is the lawsuits that come out of the
>woodwork when they start trying to enforce their provisions. "What? I
>have already printed my letterhead! What do you mean my busted DKIM
>service is a problem?"

History suggests that the problem will be the opposite.  They will
find that the number of registrations is an order of magnitude less
than their worst case estimate (a problem that every domain added in
the past decade has had), and they will make the rules ever looser to
try to gather more registrations and appease their financial backers
until it's yet another meaningless generic TLD.

For concrete examples, see what happened to .AERO, .TRAVEL, .PRO, and
of course the race to the bottom of first regular SSL certificates,
and now green bar certificates.

What might be useful would be .BANK, with both security rules and
limited registrations to actual banks.  Identifying banks is
relatively* easy, since you can use the lists of entities that
national bank regulators regulate.

R's,
John

* - I said relatively, not absolutely.



From valdis.kletnieks at vt.edu  Thu May 31 23:42:19 2012
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Date: Fri, 01 Jun 2012 00:42:19 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: Your message of "Thu, 31 May 2012 20:11:22 -0400."
 <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
References: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
Message-ID: <34719.1338525739@turing-police.cc.vt.edu>

On Thu, 31 May 2012 20:11:22 -0400, Jay Ashworth said:
> routinely conduct security scans of registered sites.

This can only play out one of 2 ways:

1) They launch an nmap scan on the 13th of every month from a known fixed address
which everybody just drops traffic, and it's pointless.

2) The worst rules-of-engagement mess the industry has ever seen.

> sites. The venture has $9.6 million (US) in funding provided by Artemis'
> parent company NCC Group, a UK-based IT security firm."

And only have to pay $185K to ICANN for the TLD.  Hmm....

A bunch of lawyers are gonna get filthy stinking rich.  I think I need to make some popcorn. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120601/04364046/attachment.bin>