From jra at baylink.com  Mon Sep  1 05:35:27 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 1 Sep 2014 01:35:27 -0400 (EDT)
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating	High Speed Internet is against Sharia
In-Reply-To: <20140901033416.GB26122@vortex.com>
Message-ID: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>

Cause it's a long weekend, and why shouldn't it be whackier than normal.

----- Forwarded Message -----
> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
> To: privacy-list at vortex.com
> Sent: Sunday, August 31, 2014 11:34:16 PM
> Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is against Sharia
> An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
> against Sharia
> 
> (Iran Human Rights):
> http://www.iranhumanrights.org/2014/08/makarem-internet/
> 
> A Grand Ayatollah in Iran has determined that access to high-speed and
> 3G Internet is "against Sharia" and "against moral standards." In
> answer to a question published on his website, Grand Ayatollah Nasser
> Makarem Shirazi, one of the country's highest clerical authorities,
> issued a fatwa, stating "All third generation [3G] and high-speed
> internet services, prior to realization of the required conditions for
> the National Information Network [Iran's government-controlled and
> censored Internet which is under development], is against Sharia [and]
> against moral and human standards."
> 
> - - -
> 
> Comcast, Verizon, AT&T, Time Warner Cable, and other dominant ISPs are
> now in a bidding war to hire him as a consultant and board member.

RUN AWAY!!!

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From bbqroast at gmail.com  Mon Sep  1 05:44:27 2014
From: bbqroast at gmail.com (mcfbbqroast .)
Date: Mon, 1 Sep 2014 17:44:27 +1200
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating High Speed Internet is against Sharia
In-Reply-To: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
References: <20140901033416.GB26122@vortex.com>
 <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAKJkDEv2BekQU6HtY=RQqrL+XFaTO+LRDZvDdhiwkG07OPswhg@mail.gmail.com>

Ladies and gentlemen, we have our mysterious backhoe driver.

Who would've known?
On 1 Sep 2014 17:37, "Jay Ashworth" <jra at baylink.com> wrote:

> Cause it's a long weekend, and why shouldn't it be whackier than normal.
>
> ----- Forwarded Message -----
> > From: "PRIVACY Forum mailing list" <privacy at vortex.com>
> > To: privacy-list at vortex.com
> > Sent: Sunday, August 31, 2014 11:34:16 PM
> > Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
> Stating High Speed Internet is against Sharia
> > An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
> > against Sharia
> >
> > (Iran Human Rights):
> > http://www.iranhumanrights.org/2014/08/makarem-internet/
> >
> > A Grand Ayatollah in Iran has determined that access to high-speed and
> > 3G Internet is "against Sharia" and "against moral standards." In
> > answer to a question published on his website, Grand Ayatollah Nasser
> > Makarem Shirazi, one of the country's highest clerical authorities,
> > issued a fatwa, stating "All third generation [3G] and high-speed
> > internet services, prior to realization of the required conditions for
> > the National Information Network [Iran's government-controlled and
> > censored Internet which is under development], is against Sharia [and]
> > against moral and human standards."
> >
> > - - -
> >
> > Comcast, Verizon, AT&T, Time Warner Cable, and other dominant ISPs are
> > now in a bidding war to hire him as a consultant and board member.
>
> RUN AWAY!!!
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land
> Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
> 1274
>


From larrysheldon at cox.net  Mon Sep  1 06:04:38 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 01 Sep 2014 01:04:38 -0500
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating	High Speed Internet is against Sharia
In-Reply-To: <lhcM1o0171cZc5601hcPKa>
References: <lhcM1o0171cZc5601hcPKa>
Message-ID: <54040C76.3030402@cox.net>

On 9/1/2014 00:35, Jay Ashworth wrote:
> Cause it's a long weekend, and why shouldn't it be whackier than normal.
>
> ----- Forwarded Message -----
>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>> To: privacy-list at vortex.com
>> Sent: Sunday, August 31, 2014 11:34:16 PM
>> Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is against Sharia
>> An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
>> against Sharia
>>
>> (Iran Human Rights):
>> http://www.iranhumanrights.org/2014/08/makarem-internet/
>>
>> A Grand Ayatollah in Iran has determined that access to high-speed and
>> 3G Internet is "against Sharia" and "against moral standards." In
>> answer to a question published on his website, Grand Ayatollah Nasser
                                   ^^^^^^^^^^^^^^
Is that odd?
-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


From brunner at nic-naa.net  Mon Sep  1 06:08:36 2014
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Sun, 31 Aug 2014 23:08:36 -0700
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating	High Speed Internet is against Sharia
In-Reply-To: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
References: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
Message-ID: <54040D64.7060806@nic-naa.net>

well, looking at the ayatollah's website and invoking google translate 
there's this language:

"... different mechanisms to secure and protect their users against the 
moral and psychological damage this type of service, including access to 
information, videos and photos from immoral and inhuman, rumors and 
seduction, spying and undermining the foundations of the family ..."

so, not a lot goofier than the objection to .xxx made by the usg, or 
available at most media outlets that sell the meme that the internet 
causes shit to happen.

-e

  On 8/31/14 10:35 PM, Jay Ashworth wrote:
> Cause it's a long weekend, and why shouldn't it be whackier than normal.
>
> ----- Forwarded Message -----
>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>> To: privacy-list at vortex.com
>> Sent: Sunday, August 31, 2014 11:34:16 PM
>> Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is against Sharia
>> An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
>> against Sharia
>>
>> (Iran Human Rights):
>> http://www.iranhumanrights.org/2014/08/makarem-internet/
>>
>> A Grand Ayatollah in Iran has determined that access to high-speed and
>> 3G Internet is "against Sharia" and "against moral standards." In
>> answer to a question published on his website, Grand Ayatollah Nasser
>> Makarem Shirazi, one of the country's highest clerical authorities,
>> issued a fatwa, stating "All third generation [3G] and high-speed
>> internet services, prior to realization of the required conditions for
>> the National Information Network [Iran's government-controlled and
>> censored Internet which is under development], is against Sharia [and]
>> against moral and human standards."
>>
>> - - -
>>
>> Comcast, Verizon, AT&T, Time Warner Cable, and other dominant ISPs are
>> now in a bidding war to hire him as a consultant and board member.
> RUN AWAY!!!
>
> Cheers,
> -- jra
>



From bmanning at isi.edu  Mon Sep  1 06:08:51 2014
From: bmanning at isi.edu (manning bill)
Date: Sun, 31 Aug 2014 23:08:51 -0700
Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating	High Speed Internet is against Sharia
In-Reply-To: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
References: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
Message-ID: <4E0BBC73-EA6D-44B4-856E-C275291B534F@isi.edu>

so Internet in the US is safe?


/bill
Neca eos omnes.  Deus suos agnoscet.

On 31August2014Sunday, at 22:35, Jay Ashworth <jra at baylink.com> wrote:

> Cause it's a long weekend, and why shouldn't it be whackier than normal.
> 
> ----- Forwarded Message -----
>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>> To: privacy-list at vortex.com
>> Sent: Sunday, August 31, 2014 11:34:16 PM
>> Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is against Sharia
>> An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
>> against Sharia
>> 
>> (Iran Human Rights):
>> http://www.iranhumanrights.org/2014/08/makarem-internet/
>> 
>> A Grand Ayatollah in Iran has determined that access to high-speed and
>> 3G Internet is "against Sharia" and "against moral standards." In
>> answer to a question published on his website, Grand Ayatollah Nasser
>> Makarem Shirazi, one of the country's highest clerical authorities,
>> issued a fatwa, stating "All third generation [3G] and high-speed
>> internet services, prior to realization of the required conditions for
>> the National Information Network [Iran's government-controlled and
>> censored Internet which is under development], is against Sharia [and]
>> against moral and human standards."
>> 
>> - - -
>> 
>> Comcast, Verizon, AT&T, Time Warner Cable, and other dominant ISPs are
>> now in a bidding war to hire him as a consultant and board member.
> 
> RUN AWAY!!!
> 
> Cheers,
> -- jra
> 
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274



From joly at punkcast.com  Mon Sep  1 07:19:25 2014
From: joly at punkcast.com (Joly MacFie)
Date: Mon, 1 Sep 2014 03:19:25 -0400
Subject: FCC Help Wanted
Message-ID: <CAM9VJk2zKdtqFed39AOtvzk=heeRN_Gr2sY5PV2KVHyom4_hMg@mail.gmail.com>

https://www.usajobs.gov/GetJob/ViewDetails/379628100

Job Title:Telecommunications Policy and Technology Specialist (Internet)

Agency:Federal Communications Commission

SALARY RANGE:

$124,995.00 to $157,100.00 / Per Year

DUTIES:

As Telecommunications Policy and Technology Specialist (Internet), he/she
serves as a senior expert consultant and advisor with regard to wireline
and wireless broadband technologies used in communications networks,
Internet technologies, Internet networking, and traffic exchange evolution
issues. Provides expert technical and policy advice on the technology,
design, and operations of Internet networks, including changes in network
design and traffic exchange practices and policies resulting from emerging
commercial practices and strategies. Performs investigative analyses and
original research with respect to critical and unprecedented network
operations, service provision, traffic exchange, and content delivery
issues that involve emerging technologies, services, and commercial
incentives; evaluates technical, social, legal, institutional and other
related implications of proposed policy decisions on technology adoption,
deployment, network operations, communications services provision; and
provides input into Commission proceedings that implement those proposed
policy decisions.

Drafts recommendations, decision memoranda, notices of inquiry, notices of
proposed rulemaking, orders, and public notices concerning the technical
and business/financial aspects of designing, building, operating, and
exchanging traffic among Internet backbone networks, and content delivery
and other Internet networks. Drafts correspondence and reports concerning
controversial technical aspects of pending or future issues that may
warrant Commission actions, requesting additional information as necessary.
Initiates correspondence responsive to inquiries from the public, other
government agencies, other parts of the FCC, and Congress. Initiates
communications with the public (including service providers, trade
associations, and consumer groups) concerning technological, business, and
operational issues of specific interest or concern to the Commission.

Provides guidance and leadership over unusually complex newly emerging
technical matters, including those of a precedent-setting nature. Provides
expert technical and policy analysis for the Division on any issues
relating to advanced communications systems, including broadband systems
and the Internet, as assigned by the Division Chief or designees.
Facilitates decision and action on such matters by drafting briefing
material or rulemaking documents and by briefing the Division and/or
Division management on policy or action alternative issues.

________________________________

QUALIFICATIONS REQUIRED:


Specialized Experience: Applicants must have a minimum of one year of
specialized experience equivalent to at least the GS-14 grade level in the
Federal service.

For this position, specialized experience includes the following:

1) Experience applying knowledge of network management and operations,
network architecture, Internet technologies and services, broadband
technologies, data communications, and communications network technology;

2) Experience in a variety of communications networks and systems including
Internet and broadband networks;

3) Experience performing investigative analyses and original research with
respect to unprecedented network operations and service provision issues
that involve emerging technologies; and

4) Experience presenting complex technical and policy information to
various audiences.




--
---------------------------------------------------------------
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 lists at tarundua.net  Mon Sep  1 09:28:58 2014
From: lists at tarundua.net (Tarun Dua)
Date: Mon, 1 Sep 2014 14:58:58 +0530
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <CAEmG1=rGU=zzTXo8CWFua_AAp7vQ9UbkfH4nZTOqSgBuy5s0zA@mail.gmail.com>
References: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com>
 <CAEmG1=rGU=zzTXo8CWFua_AAp7vQ9UbkfH4nZTOqSgBuy5s0zA@mail.gmail.com>
Message-ID: <CAAjbWEquXmz5V2e9ADg2DsqJB--njf+FAnmkA6xRgwDYbPfF6g@mail.gmail.com>

Would it not help if RIPE un-publishes these ASN's from their whois database ?

I filed the abuse report at RIPE but haven't heard back from them. We
are NOT a RIPE member but an APNIC member.

Regards
-Tarun

On Mon, Sep 1, 2014 at 3:49 AM, Matthew Petach <mpetach at netflight.com> wrote:
> On Sun, Aug 31, 2014 at 12:47 PM, Doug Madory <dmadory at renesys.com> wrote:
>
>> Ah yes BusinessTorg (AS60937). I have also seen this one doing what you
>> are describing. Not to MSFT or GOOG, but another major technology company
>> that we peer with. In fact, it is going on right now but only visible if
>> you receive routes directly from them. A while ago, I sent them a note
>> describing what was happening and suggested they might want to stop
>> accepting routes from that AS, but they still do.
>>
>
>
> Be aware that even if you don't think you're
> peering with them directly, you may be picking
> up routes via the public route servers at exchange
> points, so check to see if you need to apply
> filters on your route server peerings as well.
>
> Matt


From me at anuragbhatia.com  Mon Sep  1 09:50:53 2014
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Mon, 1 Sep 2014 15:20:53 +0530
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <CAAjbWEquXmz5V2e9ADg2DsqJB--njf+FAnmkA6xRgwDYbPfF6g@mail.gmail.com>
References: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com>
 <CAEmG1=rGU=zzTXo8CWFua_AAp7vQ9UbkfH4nZTOqSgBuy5s0zA@mail.gmail.com>
 <CAAjbWEquXmz5V2e9ADg2DsqJB--njf+FAnmkA6xRgwDYbPfF6g@mail.gmail.com>
Message-ID: <CAJ0+aXavbv1d7owJ8SXVenh-p=h+EhdREJXR2fMJc=LjF11-nw@mail.gmail.com>

Hi Tarun

Not really. People who are filtering route are filtering already since only
you have route object for it and people who are not filtering, for them
RIPE DB and whois won't matter.






On Mon, Sep 1, 2014 at 2:58 PM, Tarun Dua <lists at tarundua.net> wrote:

> Would it not help if RIPE un-publishes these ASN's from their whois
> database ?
>
> I filed the abuse report at RIPE but haven't heard back from them. We
> are NOT a RIPE member but an APNIC member.
>
> Regards
> -Tarun
>
> On Mon, Sep 1, 2014 at 3:49 AM, Matthew Petach <mpetach at netflight.com>
> wrote:
> > On Sun, Aug 31, 2014 at 12:47 PM, Doug Madory <dmadory at renesys.com>
> wrote:
> >
> >> Ah yes BusinessTorg (AS60937). I have also seen this one doing what you
> >> are describing. Not to MSFT or GOOG, but another major technology
> company
> >> that we peer with. In fact, it is going on right now but only visible if
> >> you receive routes directly from them. A while ago, I sent them a note
> >> describing what was happening and suggested they might want to stop
> >> accepting routes from that AS, but they still do.
> >>
> >
> >
> > Be aware that even if you don't think you're
> > peering with them directly, you may be picking
> > up routes via the public route servers at exchange
> > points, so check to see if you need to apply
> > filters on your route server peerings as well.
> >
> > Matt
>



-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter
<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2


From saku at ytti.fi  Mon Sep  1 09:58:51 2014
From: saku at ytti.fi (Saku Ytti)
Date: Mon, 1 Sep 2014 12:58:51 +0300
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <CAAjbWEquXmz5V2e9ADg2DsqJB--njf+FAnmkA6xRgwDYbPfF6g@mail.gmail.com>
References: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com>
 <CAEmG1=rGU=zzTXo8CWFua_AAp7vQ9UbkfH4nZTOqSgBuy5s0zA@mail.gmail.com>
 <CAAjbWEquXmz5V2e9ADg2DsqJB--njf+FAnmkA6xRgwDYbPfF6g@mail.gmail.com>
Message-ID: <20140901095851.GA22922@pob.ytti.fi>

On (2014-09-01 14:58 +0530), Tarun Dua wrote:

Hi,

> Would it not help if RIPE un-publishes these ASN's from their whois database ?
> 
> I filed the abuse report at RIPE but haven't heard back from them. We
> are NOT a RIPE member but an APNIC member.

Not sure against what RIPE rule it would be and what kind of leverage RIPE
could have here, even if we know they are intentionally evil.

However if I'd be supporting my family with this type of business model, I
would simply appear to be very bad at it, not evil. So I would claim that we
didn't do anything bad here, it was one of our customer (as they do have
different origin AS), and when pointed out, that this ASN has never been your
customer and cannot be, as completely different physical location, I'd simply
say we seeme to have verify-first-as turned off, so it could have been anyone,
and we're hard at work resolving it.
All of this with appropriate delay in answering to queries so you can keep on
doing it years before it's even clear you're evil not just really bad in your
job.

-- 
  ++ytti


From brunner at nic-naa.net  Mon Sep  1 15:35:24 2014
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Mon, 01 Sep 2014 08:35:24 -0700
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating	High Speed Internet is against Sharia
In-Reply-To: <54040D64.7060806@nic-naa.net>
References: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
 <54040D64.7060806@nic-naa.net>
Message-ID: <5404923C.2050409@nic-naa.net>

see also:
http://www.al-monitor.com/pulse/originals/2014/09/iran-3g-phones-filter-unsanitary-water.html#

restated slightly, video, the primary vehicle for porn, needs minders, 
text, the primary vehicle for ideas, does not.

-e

On 8/31/14 11:08 PM, Eric Brunner-Williams wrote:
> well, looking at the ayatollah's website and invoking google translate 
> there's this language:
>
> "... different mechanisms to secure and protect their users against 
> the moral and psychological damage this type of service, including 
> access to information, videos and photos from immoral and inhuman, 
> rumors and seduction, spying and undermining the foundations of the 
> family ..."
>
> so, not a lot goofier than the objection to .xxx made by the usg, or 
> available at most media outlets that sell the meme that the internet 
> causes shit to happen.
>
> -e
>
>  On 8/31/14 10:35 PM, Jay Ashworth wrote:
>> Cause it's a long weekend, and why shouldn't it be whackier than normal.
>>
>> ----- Forwarded Message -----
>>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>>> To: privacy-list at vortex.com
>>> Sent: Sunday, August 31, 2014 11:34:16 PM
>>> Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa 
>>> Stating High Speed Internet is against Sharia
>>> An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
>>> against Sharia
>>>
>>> (Iran Human Rights):
>>> http://www.iranhumanrights.org/2014/08/makarem-internet/
>>>
>>> A Grand Ayatollah in Iran has determined that access to high-speed and
>>> 3G Internet is "against Sharia" and "against moral standards." In
>>> answer to a question published on his website, Grand Ayatollah Nasser
>>> Makarem Shirazi, one of the country's highest clerical authorities,
>>> issued a fatwa, stating "All third generation [3G] and high-speed
>>> internet services, prior to realization of the required conditions for
>>> the National Information Network [Iran's government-controlled and
>>> censored Internet which is under development], is against Sharia [and]
>>> against moral and human standards."
>>>
>>> - - -
>>>
>>> Comcast, Verizon, AT&T, Time Warner Cable, and other dominant ISPs are
>>> now in a bidding war to hire him as a consultant and board member.
>> RUN AWAY!!!
>>
>> Cheers,
>> -- jra
>>
>
>
>



From nick at pelagiris.org  Mon Sep  1 18:33:28 2014
From: nick at pelagiris.org (Nick B)
Date: Mon, 1 Sep 2014 14:33:28 -0400
Subject: FCC Help Wanted
In-Reply-To: <CAM9VJk2zKdtqFed39AOtvzk=heeRN_Gr2sY5PV2KVHyom4_hMg@mail.gmail.com>
References: <CAM9VJk2zKdtqFed39AOtvzk=heeRN_Gr2sY5PV2KVHyom4_hMg@mail.gmail.com>
Message-ID: <CAE7MFi+ABy+Gxnhz4+670PQJ5qi78=Ozt8MMchf_RfFC4VLwtg@mail.gmail.com>

Will applications without a cancelled check for at least 100k in
"donations" be considered?
Nick


On Mon, Sep 1, 2014 at 3:19 AM, Joly MacFie <joly at punkcast.com> wrote:

> https://www.usajobs.gov/GetJob/ViewDetails/379628100
>
> Job Title:Telecommunications Policy and Technology Specialist (Internet)
>
> Agency:Federal Communications Commission
>
> SALARY RANGE:
>
> $124,995.00 to $157,100.00 / Per Year
>
> DUTIES:
>
> As Telecommunications Policy and Technology Specialist (Internet), he/she
> serves as a senior expert consultant and advisor with regard to wireline
> and wireless broadband technologies used in communications networks,
> Internet technologies, Internet networking, and traffic exchange evolution
> issues. Provides expert technical and policy advice on the technology,
> design, and operations of Internet networks, including changes in network
> design and traffic exchange practices and policies resulting from emerging
> commercial practices and strategies. Performs investigative analyses and
> original research with respect to critical and unprecedented network
> operations, service provision, traffic exchange, and content delivery
> issues that involve emerging technologies, services, and commercial
> incentives; evaluates technical, social, legal, institutional and other
> related implications of proposed policy decisions on technology adoption,
> deployment, network operations, communications services provision; and
> provides input into Commission proceedings that implement those proposed
> policy decisions.
>
> Drafts recommendations, decision memoranda, notices of inquiry, notices of
> proposed rulemaking, orders, and public notices concerning the technical
> and business/financial aspects of designing, building, operating, and
> exchanging traffic among Internet backbone networks, and content delivery
> and other Internet networks. Drafts correspondence and reports concerning
> controversial technical aspects of pending or future issues that may
> warrant Commission actions, requesting additional information as necessary.
> Initiates correspondence responsive to inquiries from the public, other
> government agencies, other parts of the FCC, and Congress. Initiates
> communications with the public (including service providers, trade
> associations, and consumer groups) concerning technological, business, and
> operational issues of specific interest or concern to the Commission.
>
> Provides guidance and leadership over unusually complex newly emerging
> technical matters, including those of a precedent-setting nature. Provides
> expert technical and policy analysis for the Division on any issues
> relating to advanced communications systems, including broadband systems
> and the Internet, as assigned by the Division Chief or designees.
> Facilitates decision and action on such matters by drafting briefing
> material or rulemaking documents and by briefing the Division and/or
> Division management on policy or action alternative issues.
>
> ________________________________
>
> QUALIFICATIONS REQUIRED:
>
>
> Specialized Experience: Applicants must have a minimum of one year of
> specialized experience equivalent to at least the GS-14 grade level in the
> Federal service.
>
> For this position, specialized experience includes the following:
>
> 1) Experience applying knowledge of network management and operations,
> network architecture, Internet technologies and services, broadband
> technologies, data communications, and communications network technology;
>
> 2) Experience in a variety of communications networks and systems including
> Internet and broadband networks;
>
> 3) Experience performing investigative analyses and original research with
> respect to unprecedented network operations and service provision issues
> that involve emerging technologies; and
>
> 4) Experience presenting complex technical and policy information to
> various audiences.
>
>
>
>
> --
> ---------------------------------------------------------------
> 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 kmedcalf at dessus.com  Mon Sep  1 20:24:40 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Mon, 01 Sep 2014 14:24:40 -0600
Subject: FCC Help Wanted
In-Reply-To: <CAE7MFi+ABy+Gxnhz4+670PQJ5qi78=Ozt8MMchf_RfFC4VLwtg@mail.gmail.com>
Message-ID: <a0885a1e43d4144a8bf3c1c7fa478f76@mail.dessus.com>


Of couse such applications will be accepted.  However, applicants are warned that failure to include a donation will require alternate verification of the requisite lack of morals and ethics.

>Will applications without a cancelled check for at least 100k in
>"donations" be considered?
>
>On Mon, Sep 1, 2014 at 3:19 AM, Joly MacFie <joly at punkcast.com> wrote:
>
>> https://www.usajobs.gov/GetJob/ViewDetails/379628100
>>
>> Job Title:Telecommunications Policy and Technology Specialist
>(Internet)
>>
>> Agency:Federal Communications Commission
>>
>> SALARY RANGE:
>>
>> $124,995.00 to $157,100.00 / Per Year
>>
>> DUTIES:
>>
>> As Telecommunications Policy and Technology Specialist (Internet),
>he/she
>> serves as a senior expert consultant and advisor with regard to
>wireline
>> and wireless broadband technologies used in communications networks,
>> Internet technologies, Internet networking, and traffic exchange
>evolution
>> issues. Provides expert technical and policy advice on the technology,
>> design, and operations of Internet networks, including changes in
>network
>> design and traffic exchange practices and policies resulting from
>emerging
>> commercial practices and strategies. Performs investigative analyses
>and
>> original research with respect to critical and unprecedented network
>> operations, service provision, traffic exchange, and content delivery
>> issues that involve emerging technologies, services, and commercial
>> incentives; evaluates technical, social, legal, institutional and other
>> related implications of proposed policy decisions on technology
>adoption,
>> deployment, network operations, communications services provision; and
>> provides input into Commission proceedings that implement those
>proposed
>> policy decisions.
>>
>> Drafts recommendations, decision memoranda, notices of inquiry, notices
>of
>> proposed rulemaking, orders, and public notices concerning the
>technical
>> and business/financial aspects of designing, building, operating, and
>> exchanging traffic among Internet backbone networks, and content
>delivery
>> and other Internet networks. Drafts correspondence and reports
>concerning
>> controversial technical aspects of pending or future issues that may
>> warrant Commission actions, requesting additional information as
>necessary.
>> Initiates correspondence responsive to inquiries from the public, other
>> government agencies, other parts of the FCC, and Congress. Initiates
>> communications with the public (including service providers, trade
>> associations, and consumer groups) concerning technological, business,
>and
>> operational issues of specific interest or concern to the Commission.
>>
>> Provides guidance and leadership over unusually complex newly emerging
>> technical matters, including those of a precedent-setting nature.
>Provides
>> expert technical and policy analysis for the Division on any issues
>> relating to advanced communications systems, including broadband
>systems
>> and the Internet, as assigned by the Division Chief or designees.
>> Facilitates decision and action on such matters by drafting briefing
>> material or rulemaking documents and by briefing the Division and/or
>> Division management on policy or action alternative issues.
>>
>> ________________________________
>>
>> QUALIFICATIONS REQUIRED:
>>
>>
>> Specialized Experience: Applicants must have a minimum of one year of
>> specialized experience equivalent to at least the GS-14 grade level in
>the
>> Federal service.
>>
>> For this position, specialized experience includes the following:
>>
>> 1) Experience applying knowledge of network management and operations,
>> network architecture, Internet technologies and services, broadband
>> technologies, data communications, and communications network
>technology;
>>
>> 2) Experience in a variety of communications networks and systems
>including
>> Internet and broadband networks;
>>
>> 3) Experience performing investigative analyses and original research
>with
>> respect to unprecedented network operations and service provision
>issues
>> that involve emerging technologies; and
>>
>> 4) Experience presenting complex technical and policy information to
>> various audiences.
>>
>>
>>
>>
>> --
>> ---------------------------------------------------------------
>> 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 shortdudey123 at gmail.com  Mon Sep  1 21:25:51 2014
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Mon, 1 Sep 2014 14:25:51 -0700
Subject: FCC Help Wanted
In-Reply-To: <a0885a1e43d4144a8bf3c1c7fa478f76@mail.dessus.com>
References: <a0885a1e43d4144a8bf3c1c7fa478f76@mail.dessus.com>
Message-ID: <526B7FC0-90C7-4381-8987-6992CD578B52@gmail.com>

If you have ties to Grand Ayatollah, it would probably be an automatic acceptance into the position.

Grant

Sent from my iPhone

> On Sep 1, 2014, at 1:24 PM, "Keith Medcalf" <kmedcalf at dessus.com> wrote:
> 
> 
> Of couse such applications will be accepted.  However, applicants are warned that failure to include a donation will require alternate verification of the requisite lack of morals and ethics.
> 
>> Will applications without a cancelled check for at least 100k in
>> "donations" be considered?
>> 
>>> On Mon, Sep 1, 2014 at 3:19 AM, Joly MacFie <joly at punkcast.com> wrote:
>>> 
>>> https://www.usajobs.gov/GetJob/ViewDetails/379628100
>>> 
>>> Job Title:Telecommunications Policy and Technology Specialist
>> (Internet)
>>> 
>>> Agency:Federal Communications Commission
>>> 
>>> SALARY RANGE:
>>> 
>>> $124,995.00 to $157,100.00 / Per Year
>>> 
>>> DUTIES:
>>> 
>>> As Telecommunications Policy and Technology Specialist (Internet),
>> he/she
>>> serves as a senior expert consultant and advisor with regard to
>> wireline
>>> and wireless broadband technologies used in communications networks,
>>> Internet technologies, Internet networking, and traffic exchange
>> evolution
>>> issues. Provides expert technical and policy advice on the technology,
>>> design, and operations of Internet networks, including changes in
>> network
>>> design and traffic exchange practices and policies resulting from
>> emerging
>>> commercial practices and strategies. Performs investigative analyses
>> and
>>> original research with respect to critical and unprecedented network
>>> operations, service provision, traffic exchange, and content delivery
>>> issues that involve emerging technologies, services, and commercial
>>> incentives; evaluates technical, social, legal, institutional and other
>>> related implications of proposed policy decisions on technology
>> adoption,
>>> deployment, network operations, communications services provision; and
>>> provides input into Commission proceedings that implement those
>> proposed
>>> policy decisions.
>>> 
>>> Drafts recommendations, decision memoranda, notices of inquiry, notices
>> of
>>> proposed rulemaking, orders, and public notices concerning the
>> technical
>>> and business/financial aspects of designing, building, operating, and
>>> exchanging traffic among Internet backbone networks, and content
>> delivery
>>> and other Internet networks. Drafts correspondence and reports
>> concerning
>>> controversial technical aspects of pending or future issues that may
>>> warrant Commission actions, requesting additional information as
>> necessary.
>>> Initiates correspondence responsive to inquiries from the public, other
>>> government agencies, other parts of the FCC, and Congress. Initiates
>>> communications with the public (including service providers, trade
>>> associations, and consumer groups) concerning technological, business,
>> and
>>> operational issues of specific interest or concern to the Commission.
>>> 
>>> Provides guidance and leadership over unusually complex newly emerging
>>> technical matters, including those of a precedent-setting nature.
>> Provides
>>> expert technical and policy analysis for the Division on any issues
>>> relating to advanced communications systems, including broadband
>> systems
>>> and the Internet, as assigned by the Division Chief or designees.
>>> Facilitates decision and action on such matters by drafting briefing
>>> material or rulemaking documents and by briefing the Division and/or
>>> Division management on policy or action alternative issues.
>>> 
>>> ________________________________
>>> 
>>> QUALIFICATIONS REQUIRED:
>>> 
>>> 
>>> Specialized Experience: Applicants must have a minimum of one year of
>>> specialized experience equivalent to at least the GS-14 grade level in
>> the
>>> Federal service.
>>> 
>>> For this position, specialized experience includes the following:
>>> 
>>> 1) Experience applying knowledge of network management and operations,
>>> network architecture, Internet technologies and services, broadband
>>> technologies, data communications, and communications network
>> technology;
>>> 
>>> 2) Experience in a variety of communications networks and systems
>> including
>>> Internet and broadband networks;
>>> 
>>> 3) Experience performing investigative analyses and original research
>> with
>>> respect to unprecedented network operations and service provision
>> issues
>>> that involve emerging technologies; and
>>> 
>>> 4) Experience presenting complex technical and policy information to
>>> various audiences.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> ---------------------------------------------------------------
>>> 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 kotikalapudi.sriram at nist.gov  Mon Sep  1 21:34:27 2014
From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi)
Date: Mon, 1 Sep 2014 21:34:27 +0000
Subject: Prefix hijacking, how to prevent and fix currently
Message-ID: <1a936788ac1741a89e0cc1a2222a2c8d@BN1PR09MB0274.namprd09.prod.outlook.com>

>> Loose mode RPKI:
>>  - verified or unknown less-specific route is preferable to failing more-specific

>Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest
>match is not done to whole population, population is first divided to
>'verified', 'unknown' and 'failed' routes, and longest match is done for each
>sub-population in order, until match is found.

Of course, a PRO you are seeking to achieve is:

If Org. A is parent and upstream of Org. B, and Org. A has created a ROA for its 
own less specific, while no ROA has been created (due to negligence, oversight, etc.) 
for the suballocation (more specific) of Org. B,
and if Org. A happens *not* to announce its less specific, then Org. B's announcement 
of the more specific from its own AS will be treated softly. 
That is, Org. B's announcement will be 'Invalid' but nevertheless the route is 
accepted/installed by any receiving AS that is using the 'Loose' mode.  
This is the benign/beneficial use of 'Loose' mode.
   
But the CON here is:

For instance, Org. C owns a prefix but has not yet deployed any services using it.
Org. C created a ROA (perhaps even an ROA with AS0) purely with the intent 
to make sure that no one else can get away with announcing any
subprefix (more specific) under its prefix unless they have a ROA for the subprefix.
The 'Loose' mode obviously defeats this.
Some Org. D can maliciously announce a subprefix under Org. C's prefix,
and get away with it due to the 'Loose' mode.

So there will be this tension between the PRO and CON of your 'Loose' mode.

I think, 'Loose mode', if used at all, should not be used beyond a short grace period.
Beyond the grace period, network operators and their customers will be 
well advised to adhere to the following from RFC 7115: 
"Before issuing a ROA for a super-block, an operator MUST ensure that
   all sub-allocations from that block that are announced by other ASes,
   e.g., customers, have correct ROAs in the RPKI."

Sriram   




   

From somasundaram.s at alcatel-lucent.com  Tue Sep  2 04:47:37 2014
From: somasundaram.s at alcatel-lucent.com (S, Somasundaram (Somasundaram))
Date: Tue, 2 Sep 2014 04:47:37 +0000
Subject: Multicast Internet Route table.
Message-ID: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>

Members
    I have few questions related to Multicast deployment in the internet today.
1: Does all the ISP's provide Multicast Routing by default?
2:  Is there any placeholder where one can get to know the Multicast Internet Route table (usage, stability etc) just like Unicast Route table (http://bgpupdates.potaroo.net)?





From bbqroast at gmail.com  Tue Sep  2 05:19:26 2014
From: bbqroast at gmail.com (mcfbbqroast .)
Date: Tue, 2 Sep 2014 17:19:26 +1200
Subject: FCC Help Wanted
In-Reply-To: <526B7FC0-90C7-4381-8987-6992CD578B52@gmail.com>
References: <a0885a1e43d4144a8bf3c1c7fa478f76@mail.dessus.com>
 <526B7FC0-90C7-4381-8987-6992CD578B52@gmail.com>
Message-ID: <CAKJkDEtTkNuW33=u1Qz-7Fk+wFEZNqtsk726bQXsRy3uB--zXw@mail.gmail.com>

What value of shares in major telecommunications companies would be
considered adequate for such a role?
On 2 Sep 2014 09:30, "Grant Ridder" <shortdudey123 at gmail.com> wrote:

> If you have ties to Grand Ayatollah, it would probably be an automatic
> acceptance into the position.
>
> Grant
>
> Sent from my iPhone
>
> > On Sep 1, 2014, at 1:24 PM, "Keith Medcalf" <kmedcalf at dessus.com> wrote:
> >
> >
> > Of couse such applications will be accepted.  However, applicants are
> warned that failure to include a donation will require alternate
> verification of the requisite lack of morals and ethics.
> >
> >> Will applications without a cancelled check for at least 100k in
> >> "donations" be considered?
> >>
> >>> On Mon, Sep 1, 2014 at 3:19 AM, Joly MacFie <joly at punkcast.com> wrote:
> >>>
> >>> https://www.usajobs.gov/GetJob/ViewDetails/379628100
> >>>
> >>> Job Title:Telecommunications Policy and Technology Specialist
> >> (Internet)
> >>>
> >>> Agency:Federal Communications Commission
> >>>
> >>> SALARY RANGE:
> >>>
> >>> $124,995.00 to $157,100.00 / Per Year
> >>>
> >>> DUTIES:
> >>>
> >>> As Telecommunications Policy and Technology Specialist (Internet),
> >> he/she
> >>> serves as a senior expert consultant and advisor with regard to
> >> wireline
> >>> and wireless broadband technologies used in communications networks,
> >>> Internet technologies, Internet networking, and traffic exchange
> >> evolution
> >>> issues. Provides expert technical and policy advice on the technology,
> >>> design, and operations of Internet networks, including changes in
> >> network
> >>> design and traffic exchange practices and policies resulting from
> >> emerging
> >>> commercial practices and strategies. Performs investigative analyses
> >> and
> >>> original research with respect to critical and unprecedented network
> >>> operations, service provision, traffic exchange, and content delivery
> >>> issues that involve emerging technologies, services, and commercial
> >>> incentives; evaluates technical, social, legal, institutional and other
> >>> related implications of proposed policy decisions on technology
> >> adoption,
> >>> deployment, network operations, communications services provision; and
> >>> provides input into Commission proceedings that implement those
> >> proposed
> >>> policy decisions.
> >>>
> >>> Drafts recommendations, decision memoranda, notices of inquiry, notices
> >> of
> >>> proposed rulemaking, orders, and public notices concerning the
> >> technical
> >>> and business/financial aspects of designing, building, operating, and
> >>> exchanging traffic among Internet backbone networks, and content
> >> delivery
> >>> and other Internet networks. Drafts correspondence and reports
> >> concerning
> >>> controversial technical aspects of pending or future issues that may
> >>> warrant Commission actions, requesting additional information as
> >> necessary.
> >>> Initiates correspondence responsive to inquiries from the public, other
> >>> government agencies, other parts of the FCC, and Congress. Initiates
> >>> communications with the public (including service providers, trade
> >>> associations, and consumer groups) concerning technological, business,
> >> and
> >>> operational issues of specific interest or concern to the Commission.
> >>>
> >>> Provides guidance and leadership over unusually complex newly emerging
> >>> technical matters, including those of a precedent-setting nature.
> >> Provides
> >>> expert technical and policy analysis for the Division on any issues
> >>> relating to advanced communications systems, including broadband
> >> systems
> >>> and the Internet, as assigned by the Division Chief or designees.
> >>> Facilitates decision and action on such matters by drafting briefing
> >>> material or rulemaking documents and by briefing the Division and/or
> >>> Division management on policy or action alternative issues.
> >>>
> >>> ________________________________
> >>>
> >>> QUALIFICATIONS REQUIRED:
> >>>
> >>>
> >>> Specialized Experience: Applicants must have a minimum of one year of
> >>> specialized experience equivalent to at least the GS-14 grade level in
> >> the
> >>> Federal service.
> >>>
> >>> For this position, specialized experience includes the following:
> >>>
> >>> 1) Experience applying knowledge of network management and operations,
> >>> network architecture, Internet technologies and services, broadband
> >>> technologies, data communications, and communications network
> >> technology;
> >>>
> >>> 2) Experience in a variety of communications networks and systems
> >> including
> >>> Internet and broadband networks;
> >>>
> >>> 3) Experience performing investigative analyses and original research
> >> with
> >>> respect to unprecedented network operations and service provision
> >> issues
> >>> that involve emerging technologies; and
> >>>
> >>> 4) Experience presenting complex technical and policy information to
> >>> various audiences.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> ---------------------------------------------------------------
> >>> 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 saku at ytti.fi  Tue Sep  2 06:36:40 2014
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 2 Sep 2014 09:36:40 +0300
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <1a936788ac1741a89e0cc1a2222a2c8d@BN1PR09MB0274.namprd09.prod.outlook.com>
References: <1a936788ac1741a89e0cc1a2222a2c8d@BN1PR09MB0274.namprd09.prod.outlook.com>
Message-ID: <20140902063640.GA28920@pob.ytti.fi>

On (2014-09-01 21:34 +0000), Sriram, Kotikalapudi wrote:

Hi Sriram,

Please help me understand the argument.

> Some Org. D can maliciously announce a subprefix under Org. C's prefix,
> and get away with it due to the 'Loose' mode.

So C is advertising valid 192.0.2.0/24
Is D advertising valid 192.0.2.0/23?

This is unfixable problem? If D is advertising invalid or unknown, C would
still work and win, as longest prefix match is done first to the 'valid'
population, if search is found, other populations are not searched.

> I think, 'Loose mode', if used at all, should not be used beyond a short grace period.

We need to be pragmatic and ready to compromise. Right now deploying RPKI puts
you in competitive disadvantage, loose mode would remove the business risk and
make it easier to justify deployment.

-- 
  ++ytti


From wmaton at ottix.net  Tue Sep  2 10:44:46 2014
From: wmaton at ottix.net (William F. Maton Sotomayor)
Date: Tue, 2 Sep 2014 06:44:46 -0400 (EDT)
Subject: Multicast Internet Route table.
In-Reply-To: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
Message-ID: <alpine.DEB.2.03.1409020642060.8155@iskra.ottix.net>

On Tue, 2 Sep 2014, S, Somasundaram (Somasundaram) wrote:

> Members
>    I have few questions related to Multicast deployment in the internet today.

Inter-domain I am assuming.

> 1: Does all the ISP's provide Multicast Routing by default?

Probably not a majority, but it is found on research networks like 
Internet2, GEANT, etc and any of their member networks.

> 2:  Is there any placeholder where one can get to know the Multicast Internet Route table (usage, stability etc) just like Unicast Route table (http://bgpupdates.potaroo.net)?

One such place, long running:

https://nic.nrc.ca/bgp-mcast/bgp-active.html

There may be others on the networks mentioned above...

wfms


From ahebert at pubnix.net  Tue Sep  2 11:25:25 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Tue, 02 Sep 2014 07:25:25 -0400
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating	High Speed Internet is against Sharia
In-Reply-To: <5404923C.2050409@nic-naa.net>
References: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
 <54040D64.7060806@nic-naa.net> <5404923C.2050409@nic-naa.net>
Message-ID: <5405A925.8010000@pubnix.net>

Eric Brunner-Williams wrote:
> see also:
> http://www.al-monitor.com/pulse/originals/2014/09/iran-3g-phones-filter-unsanitary-water.html#
>
>
> restated slightly, video, the primary vehicle for porn, needs minders,
> text, the primary vehicle for ideas, does not.

    What about ASCII porn?

    It was the first thing I printed on a HP mini in the mid-80's. =D

>
> -e
>
> On 8/31/14 11:08 PM, Eric Brunner-Williams wrote:
>> well, looking at the ayatollah's website and invoking google
>> translate there's this language:
>>
>> "... different mechanisms to secure and protect their users against
>> the moral and psychological damage this type of service, including
>> access to information, videos and photos from immoral and inhuman,
>> rumors and seduction, spying and undermining the foundations of the
>> family ..."
>>
>> so, not a lot goofier than the objection to .xxx made by the usg, or
>> available at most media outlets that sell the meme that the internet
>> causes shit to happen.
>>
>> -e
>>
>>  On 8/31/14 10:35 PM, Jay Ashworth wrote:
>>> Cause it's a long weekend, and why shouldn't it be whackier than
>>> normal.
>>>
>>> ----- Forwarded Message -----
>>>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>>>> To: privacy-list at vortex.com
>>>> Sent: Sunday, August 31, 2014 11:34:16 PM
>>>> Subject: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
>>>> Stating High Speed Internet is against Sharia
>>>> An Iranian Grand Ayatollah Issues Fatwa Stating High Speed Internet is
>>>> against Sharia
>>>>
>>>> (Iran Human Rights):
>>>> http://www.iranhumanrights.org/2014/08/makarem-internet/
>>>>
>>>> A Grand Ayatollah in Iran has determined that access to high-speed and
>>>> 3G Internet is "against Sharia" and "against moral standards." In
>>>> answer to a question published on his website, Grand Ayatollah Nasser
>>>> Makarem Shirazi, one of the country's highest clerical authorities,
>>>> issued a fatwa, stating "All third generation [3G] and high-speed
>>>> internet services, prior to realization of the required conditions for
>>>> the National Information Network [Iran's government-controlled and
>>>> censored Internet which is under development], is against Sharia [and]
>>>> against moral and human standards."
>>>>
>>>> - - -
>>>>
>>>> Comcast, Verizon, AT&T, Time Warner Cable, and other dominant ISPs are
>>>> now in a bidding war to hire him as a consultant and board member.
>>> RUN AWAY!!!
>>>
>>> Cheers,
>>> -- jra
>>>
>>
>>
>>
>
>



From jtk at cymru.com  Tue Sep  2 12:46:38 2014
From: jtk at cymru.com (John Kristoff)
Date: Tue, 2 Sep 2014 07:46:38 -0500
Subject: Multicast Internet Route table.
In-Reply-To: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
Message-ID: <20140902074638.266a657b@localhost>

On Tue, 2 Sep 2014 04:47:37 +0000
"S, Somasundaram (Somasundaram)" <somasundaram.s at alcatel-lucent.com>
wrote:

> 1: Does all the ISP's provide Multicast Routing by
> default?

No not all and even those that do often do not do so on the same gear,
links and peers as their unicast forwarding.

> 2:  Is there any placeholder where one can get to know the
> Multicast Internet Route table (usage, stability etc) just like
> Unicast Route table (http://bgpupdates.potaroo.net)?

Marshall Eubanks at one time probably maintained the most comprehensive
IP multicast status pages at http://www.multicasttech.com/status (no
longer available).  I've not seen nor heard from Marshall in a long
time so I wouldn't expect this to come back any time soon.

Sadly I don't know of any suitable replacement, but you might find some
of that by searching here, if nothing else using the router proxies to
examine status by hand:

  <http://noc.net.internet2.edu/>

CAIDA used to do some, but I'm not sure they have anything active any
longer, browsing their tools and data may turn up some hints to other
work.

The once NLANR inspired and run Beacon project hasn't completely died
out, there is this I found at ja.net for instance:

  <http://www.beacon.ja.net/>

Interdomain IP multicast has practically since the beginning
been a notoriously niche and limited service compared to unicast
service.  There are a handful of reasons for that, but I think you will
find it becoming decreasingly available rather than more so on
interdomain basis.

John


From kotikalapudi.sriram at nist.gov  Tue Sep  2 15:08:28 2014
From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi)
Date: Tue, 2 Sep 2014 15:08:28 +0000
Subject: Prefix hijacking, how to prevent and fix currently
Message-ID: <5f43d6b8ce3c4e089e4f77c32b5ea20d@BN1PR09MB0274.namprd09.prod.outlook.com>

>Please help me understand the argument.

>

>> Some Org. D can maliciously announce a subprefix under Org. C's

>> prefix, and get away with it due to the 'Loose' mode.

>

>So C is advertising valid 192.0.2.0/24

>Is D advertising valid 192.0.2.0/23?

>

>This is unfixable problem? If D is advertising invalid or unknown, C

>would still work and win, as longest prefix match is done first to the 'valid'

>population, if search is found, other populations are not searched.



The example that I gave was not that.

In my example, C has legitimate ownership of the less specific (e.g., 192.0.2.0/23).

D is malicious and attempting to hijack a subprefix (e.g., 192.0.2.0/24).

Importantly, C has a created a ROA for 192.0.2.0/23 only to protect its address space,

but currently *does not advertise* this prefix or any part of it.

So D's more specific announcement (hijack) is 'Invalid' in this scenario,

but the 'Loose' mode operation would accept/install D's route.

Am I right about that? If yes, that is the side effect or CON that I was trying to highlight.



>> I think, 'Loose mode', if used at all, should not be used beyond a short grace period.



>We need to be pragmatic and ready to compromise. Right now deploying

>RPKI puts you in competitive disadvantage, loose mode would remove the

>business risk and make it easier to justify deployment.



I agree about making some compromises. But we need to bear in mind

the side effects such as the above in the transition period.

For example, to mitigate the above stated CON, the operator (C in our example)

should go ahead and announce its prefix (e.g., 192.0.2.0/23) in BGP even though

he/she may not currently intend to set up any servers/services in that address space.



Further, at a later/more mature stage of RPKI, when most operators have

implemented the paragraph I cited from RFC 7115, then routers can drop 'Loose' mode.



Sriram





From job at instituut.net  Tue Sep  2 15:25:39 2014
From: job at instituut.net (Job Snijders)
Date: Tue, 2 Sep 2014 17:25:39 +0200
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <5f43d6b8ce3c4e089e4f77c32b5ea20d@BN1PR09MB0274.namprd09.prod.outlook.com>
References: <5f43d6b8ce3c4e089e4f77c32b5ea20d@BN1PR09MB0274.namprd09.prod.outlook.com>
Message-ID: <20140902152539.GG25691@Vurt.local>

On Tue, Sep 02, 2014 at 03:08:28PM +0000, Sriram, Kotikalapudi wrote:
> The example that I gave was not that. In my example, C has legitimate
> ownership of the less specific (e.g., 192.0.2.0/23).  D is malicious
> and attempting to hijack a subprefix (e.g., 192.0.2.0/24).
> Importantly, C has a created a ROA for 192.0.2.0/23 only to protect
> its address space, but currently *does not advertise* this prefix or
> any part of it.  So D's more specific announcement (hijack) is
> 'Invalid' in this scenario, but the 'Loose' mode operation would
> accept/install D's route.  Am I right about that? If yes, that is the
> side effect or CON that I was trying to highlight.

You are right in your observation.

What is the real damage of hijacking a prefix which is not in use?
Email reputation that gets trashed for that prefix? I think the hijacks
we fear most are those of prefixes that are actively in use. For these
attacks I'd want to help customers protect against, and unused space is
low on my priority list.

> Further, at a later/more mature stage of RPKI, when most operators
> have implemented the paragraph I cited from RFC 7115, then routers can
> drop 'Loose' mode.

Implementing a 'Loose mode' would be a local policy decision, made by an
organisation, not a router. :-)

Kind regards,

Job


From corey.touchet at corp.totalserversolutions.com  Tue Sep  2 15:29:26 2014
From: corey.touchet at corp.totalserversolutions.com (Corey Touchet)
Date: Tue, 2 Sep 2014 15:29:26 +0000
Subject: Multicast Internet Route table.
In-Reply-To: <20140902074638.266a657b@localhost>
Message-ID: <D02B3D26.13DCB%corey.touchet@corp.totalserversolutions.com>

14 years at Verizon Wireless and I despised the crop of multicast products
that seemed to pop up from time to time.  Even in a fully controlled
network multicast remains at best black magic.  There are ways to make it
more reliable and prevent people from ruining the setups especially for
PIM type setups, but I would agree with others, unicast has better
advantages though you have to keep up with the bandwidth curve.  Content
delivery systems moving the content closer to edge customers makes this
less of a problem as well.

Torrent style distribution appears to be particularly effective as long as
you can maintain a pool of users to distribute the content.  Blizzard has
made good progress using this for game updates will a fallback to http if
you can?t get the content via torrents.




On 9/2/14, 6:46 AM, "John Kristoff" <jtk at cymru.com> wrote:

>On Tue, 2 Sep 2014 04:47:37 +0000
>"S, Somasundaram (Somasundaram)" <somasundaram.s at alcatel-lucent.com>
>wrote:
>
>> 1: Does all the ISP's provide Multicast Routing by
>> default?
>
>No not all and even those that do often do not do so on the same gear,
>links and peers as their unicast forwarding.
>
>> 2:  Is there any placeholder where one can get to know the
>> Multicast Internet Route table (usage, stability etc) just like
>> Unicast Route table (http://bgpupdates.potaroo.net)?
>
>Marshall Eubanks at one time probably maintained the most comprehensive
>IP multicast status pages at http://www.multicasttech.com/status (no
>longer available).  I've not seen nor heard from Marshall in a long
>time so I wouldn't expect this to come back any time soon.
>
>Sadly I don't know of any suitable replacement, but you might find some
>of that by searching here, if nothing else using the router proxies to
>examine status by hand:
>
>  <http://noc.net.internet2.edu/>
>
>CAIDA used to do some, but I'm not sure they have anything active any
>longer, browsing their tools and data may turn up some hints to other
>work.
>
>The once NLANR inspired and run Beacon project hasn't completely died
>out, there is this I found at ja.net for instance:
>
>  <http://www.beacon.ja.net/>
>
>Interdomain IP multicast has practically since the beginning
>been a notoriously niche and limited service compared to unicast
>service.  There are a handful of reasons for that, but I think you will
>find it becoming decreasingly available rather than more so on
>interdomain basis.
>
>John



From saku at ytti.fi  Tue Sep  2 15:27:54 2014
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 2 Sep 2014 18:27:54 +0300
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <9a7467f302e1430c9420ad7399402f61@BN1PR09MB0274.namprd09.prod.outlook.com>
References: <9a7467f302e1430c9420ad7399402f61@BN1PR09MB0274.namprd09.prod.outlook.com>
Message-ID: <20140902152754.GA7823@pob.ytti.fi>

On (2014-09-02 14:44 +0000), Sriram, Kotikalapudi wrote:

Hi Sriram,

> Importantly, C has a created a ROA for 192.0.2.0/23 only to protect 
> its address space, but currently *does not advertise* this prefix or any part of it.
> So D's more specific announcement (hijack) is 'Invalid' in this scenario but 
> the 'Loose' mode operation would accept/install D's route.
> Am I right about that? If yes, that is the side effect or CON that I was trying to highlight.

Absolutely, thanks I now understood you and we're on the same page. Loose only
protects routed networks, it do not protect hijacked non-routed prefixes.

> Further, later in a mature stage of RPKI, when nearly all operators have 
> implemented the paragraph I cited from RFC 7115, then routers can drop 'Loose' mode.    

Yes, many may have sufficient confidence to turn off loose mode at later time.
All of them would be able to gather data during loose-period about actual
occurrence of false positives. Perhaps that is always 0 or at least has been 0
for past several years, this might be make it easy to give accurate data of
factual business risks.

-- 
  ++ytti


From alvarezp at alvarezp.ods.org  Tue Sep  2 15:43:16 2014
From: alvarezp at alvarezp.ods.org (Octavio Alvarez)
Date: Tue, 02 Sep 2014 08:43:16 -0700
Subject: Multicast Internet Route table.
In-Reply-To: <20140902074638.266a657b@localhost>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost>
Message-ID: <5405E594.8000401@alvarezp.ods.org>

On 09/02/2014 05:46 AM, John Kristoff wrote:
> On Tue, 2 Sep 2014 04:47:37 +0000
> "S, Somasundaram (Somasundaram)" <somasundaram.s at alcatel-lucent.com>
> wrote:
> 
>> 1: Does all the ISP's provide Multicast Routing by
>> default?
> 
> No not all and even those that do often do not do so on the same gear,
> links and peers as their unicast forwarding.

Why would that be, are network devices not able to support multicast?

I have never used interdomain multicast but I imagine the global
m-routing table would quickly become large.


From streiner at cluebyfour.org  Tue Sep  2 13:29:23 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 2 Sep 2014 09:29:23 -0400 (EDT)
Subject: Multicast Internet Route table.
In-Reply-To: <D02B3D26.13DCB%corey.touchet@corp.totalserversolutions.com>
References: <D02B3D26.13DCB%corey.touchet@corp.totalserversolutions.com>
Message-ID: <Pine.LNX.4.64.1409020909110.17627@whammy.cluebyfour.org>

On Tue, 2 Sep 2014, Corey Touchet wrote:

> 14 years at Verizon Wireless and I despised the crop of multicast products
> that seemed to pop up from time to time.  Even in a fully controlled
> network multicast remains at best black magic.  There are ways to make it
> more reliable and prevent people from ruining the setups especially for
> PIM type setups, but I would agree with others, unicast has better
> advantages though you have to keep up with the bandwidth curve.

I can tell you that the IPv4 multicast routing table size has been 
pretty much flat (stable to declining slightly) for the past several 
years.  Right now, I see a total of just under 3,800 IPv4 multicast routes 
through Internet2 and other research/education networks, and that number 
hasn't changed much in probably 2-3 years.  I don't get any multicast 
routes from my commodity Internet providers.  Several years ago (2008-ish),
I was receiving around twice that many multicast routes, so it has died 
off significantly in the long view.

External IPv4 multicast traffic has been pretty much zilch for quite some 
time, from my viewpoint.

jms


From morrowc.lists at gmail.com  Tue Sep  2 15:53:15 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 2 Sep 2014 11:53:15 -0400
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <20140902152539.GG25691@Vurt.local>
References: <5f43d6b8ce3c4e089e4f77c32b5ea20d@BN1PR09MB0274.namprd09.prod.outlook.com>
 <20140902152539.GG25691@Vurt.local>
Message-ID: <CAL9jLabfDuTpyZJrw03ig85VZfUKS_4R2QvAEzFd4=NPpvaR2Q@mail.gmail.com>

On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job at instituut.net> wrote:
> On Tue, Sep 02, 2014 at 03:08:28PM +0000, Sriram, Kotikalapudi wrote:
>> The example that I gave was not that. In my example, C has legitimate
>> ownership of the less specific (e.g., 192.0.2.0/23).  D is malicious
>> and attempting to hijack a subprefix (e.g., 192.0.2.0/24).
>> Importantly, C has a created a ROA for 192.0.2.0/23 only to protect
>> its address space, but currently *does not advertise* this prefix or
>> any part of it.  So D's more specific announcement (hijack) is
>> 'Invalid' in this scenario, but the 'Loose' mode operation would
>> accept/install D's route.  Am I right about that? If yes, that is the
>> side effect or CON that I was trying to highlight.
>
> You are right in your observation.
>
> What is the real damage of hijacking a prefix which is not in use?

'not in use' ... where?

What if the 'owner' of the block has the block only routed
'internally' (either behind gateways/firewalls/airgaps or just inside
their ASN) The expectation of the 'owner' is that they are using the
space and it's not routed 'somewhere else', right?

-chris


From jeff.tantsura at ericsson.com  Tue Sep  2 15:58:16 2014
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Tue, 2 Sep 2014 15:58:16 +0000
Subject: Multicast Internet Route table.
In-Reply-To: <5405E594.8000401@alvarezp.ods.org>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost> <5405E594.8000401@alvarezp.ods.org>
Message-ID: <D02B359D.6F7A4%jeff.tantsura@ericsson.com>

It is not the network devices per se, it is additional configuration,
security, MSDP peering, etc, i.e. OPEX

Business justification for such effort is not obvious, (most of multicast
deployments I have done in my previous life were because I loved the
technology, not because of business needs :))

Cheers,
Jeff




-----Original Message-----
From: Octavio Alvarez <alvarezp at alvarezp.ods.org>
Date: Tuesday, September 2, 2014 at 8:43 AM
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Multicast Internet Route table.

>On 09/02/2014 05:46 AM, John Kristoff wrote:
>> On Tue, 2 Sep 2014 04:47:37 +0000
>> "S, Somasundaram (Somasundaram)" <somasundaram.s at alcatel-lucent.com>
>> wrote:
>> 
>>> 1: Does all the ISP's provide Multicast Routing by
>>> default?
>> 
>> No not all and even those that do often do not do so on the same gear,
>> links and peers as their unicast forwarding.
>
>Why would that be, are network devices not able to support multicast?
>
>I have never used interdomain multicast but I imagine the global
>m-routing table would quickly become large.



From swmike at swm.pp.se  Tue Sep  2 16:05:42 2014
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 2 Sep 2014 18:05:42 +0200 (CEST)
Subject: Multicast Internet Route table.
In-Reply-To: <5405E594.8000401@alvarezp.ods.org>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost> <5405E594.8000401@alvarezp.ods.org>
Message-ID: <alpine.DEB.2.02.1409021803430.7929@uplift.swm.pp.se>

On Tue, 2 Sep 2014, Octavio Alvarez wrote:

> I have never used interdomain multicast but I imagine the global 
> m-routing table would quickly become large.

I have set up interdomain routing connecting both to a few peers and a 
Tier1 transit provider. Not many non-research networks to be seen.

Also, since we didn't use it it kept breaking and I had to fix it every 
two years or so, where it probably had been down for months.

I don't believe in Internet-wide multicast happening in current 
incarnation, it's just too fragile and too few people are using it. It 
wouldn't scale either due to all the state that needs to be kept.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


From job at instituut.net  Tue Sep  2 16:08:35 2014
From: job at instituut.net (Job Snijders)
Date: Tue, 2 Sep 2014 18:08:35 +0200
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <CAL9jLabfDuTpyZJrw03ig85VZfUKS_4R2QvAEzFd4=NPpvaR2Q@mail.gmail.com>
References: <5f43d6b8ce3c4e089e4f77c32b5ea20d@BN1PR09MB0274.namprd09.prod.outlook.com>
 <20140902152539.GG25691@Vurt.local>
 <CAL9jLabfDuTpyZJrw03ig85VZfUKS_4R2QvAEzFd4=NPpvaR2Q@mail.gmail.com>
Message-ID: <20140902160835.GH25691@Vurt.local>

On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
> On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job at instituut.net> wrote:
>
> > What is the real damage of hijacking a prefix which is not in use?
>
> 'not in use' ... where?
> 
> What if the 'owner' of the block has the block only routed
> 'internally' (either behind gateways/firewalls/airgaps or just inside
> their ASN) The expectation of the 'owner' is that they are using the
> space and it's not routed 'somewhere else', right?

Interesting point. A commmon approach is to announce such internal
prefixes and blackhole packets to and from at a border.

Alternatively they could set "AS 0" in the ROA of such 'not globally
used' prefixes.  I don't think loose mode should apply to 'AS 0' ROAs.

Kind regards,

Job


From jtk at cymru.com  Tue Sep  2 16:30:44 2014
From: jtk at cymru.com (John Kristoff)
Date: Tue, 2 Sep 2014 11:30:44 -0500
Subject: Multicast Internet Route table.
In-Reply-To: <5405E594.8000401@alvarezp.ods.org>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost>
 <5405E594.8000401@alvarezp.ods.org>
Message-ID: <20140902113044.31395f01@localhost>

On Tue, 02 Sep 2014 08:43:16 -0700
Octavio Alvarez <alvarezp at alvarezp.ods.org> wrote:

> > No not all and even those that do often do not do so on the same
> > gear, links and peers as their unicast forwarding.
> 
> Why would that be, are network devices not able to support multicast?

That was part of it, but there is also some benefit to separating it.
When I ran networks with it, we essentially had it everywhere so I'm
not the best person to explain the reasons others may have had.

IP multicast can be difficult to troubleshoot and maintain, especially
when it often runs for months on end without issue, until it doesn't.
There may be practical scaling limitations and security issues.  So
isolation in part may be both a practical necessity and an operational
safeguard.

> I have never used interdomain multicast but I imagine the global
> m-routing table would quickly become large.

The routes wouldn't need to look much different than unicast, but when
you have to start maintaining other state other than just route
reachability, particularly for tracking participants in groups and
sources, things can get unwieldy fast.  The best thing I can say about
IP multicast is that it nice experience to *have had*.

Note, this is not to disparage decisions by those who choose to use IP
multicast for certain circumstances, which is still in widespread use
and successful such as with TV over cable networks, but those are
largely isolated environments and configurations are generally set in
such a way that much of the scaling, state and security issues are
sufficiently dealt with.

John


From dwcarder at wisc.edu  Tue Sep  2 16:48:26 2014
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Tue, 02 Sep 2014 11:48:26 -0500
Subject: Multicast Internet Route table.
In-Reply-To: <alpine.DEB.2.02.1409021803430.7929@uplift.swm.pp.se>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost> <5405E594.8000401@alvarezp.ods.org>
 <alpine.DEB.2.02.1409021803430.7929@uplift.swm.pp.se>
Message-ID: <20140902164825.GD14857@ricotta.doit.wisc.edu>

Thus spake Mikael Abrahamsson (swmike at swm.pp.se) on Tue, Sep 02, 2014 at 06:05:42PM +0200:
> On Tue, 2 Sep 2014, Octavio Alvarez wrote:
> 
> >I have never used interdomain multicast but I imagine the global m-routing
> >table would quickly become large.
> 
> I have set up interdomain routing connecting both to a few peers and a Tier1
> transit provider. Not many non-research networks to be seen.
> 
> Also, since we didn't use it it kept breaking and I had to fix it every two
> years or so, where it probably had been down for months.
> 
> I don't believe in Internet-wide multicast happening in current incarnation,
> it's just too fragile and too few people are using it. It wouldn't scale
> either due to all the state that needs to be kept.
 
Inter-domain multicast was largely replaced in practice by CDN's.

In addition to scale issues in keeping state, large wireless L1 environments
are hostile to functioning multicast.

Dale


From morrowc.lists at gmail.com  Tue Sep  2 16:51:14 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 2 Sep 2014 12:51:14 -0400
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <20140902160835.GH25691@Vurt.local>
References: <5f43d6b8ce3c4e089e4f77c32b5ea20d@BN1PR09MB0274.namprd09.prod.outlook.com>
 <20140902152539.GG25691@Vurt.local>
 <CAL9jLabfDuTpyZJrw03ig85VZfUKS_4R2QvAEzFd4=NPpvaR2Q@mail.gmail.com>
 <20140902160835.GH25691@Vurt.local>
Message-ID: <CAL9jLaa_=mq7N0Zf27OMJe3UaO2KbdkuP8N-3MoEvzoezFhhpw@mail.gmail.com>

On Tue, Sep 2, 2014 at 12:08 PM, Job Snijders <job at instituut.net> wrote:
> On Tue, Sep 02, 2014 at 11:53:15AM -0400, Christopher Morrow wrote:
>> On Tue, Sep 2, 2014 at 11:25 AM, Job Snijders <job at instituut.net> wrote:
>>
>> > What is the real damage of hijacking a prefix which is not in use?
>>
>> 'not in use' ... where?
>>
>> What if the 'owner' of the block has the block only routed
>> 'internally' (either behind gateways/firewalls/airgaps or just inside
>> their ASN) The expectation of the 'owner' is that they are using the
>> space and it's not routed 'somewhere else', right?
>
> Interesting point. A commmon approach is to announce such internal
> prefixes and blackhole packets to and from at a border.

there are lots of belts/suspenders ways to fix this, yes.

> Alternatively they could set "AS 0" in the ROA of such 'not globally
> used' prefixes.  I don't think loose mode should apply to 'AS 0' ROAs.

ok


From bill at herrin.us  Tue Sep  2 17:00:51 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Sep 2014 13:00:51 -0400
Subject: Multicast Internet Route table.
In-Reply-To: <D02B3D26.13DCB%corey.touchet@corp.totalserversolutions.com>
References: <20140902074638.266a657b@localhost>
 <D02B3D26.13DCB%corey.touchet@corp.totalserversolutions.com>
Message-ID: <CAP-guGWkmP_FPukiqna2koNBx2qxMEr3Y3-FOpc7+quQPzENPA@mail.gmail.com>

On Tue, Sep 2, 2014 at 11:29 AM, Corey Touchet
<corey.touchet at corp.totalserversolutions.com> wrote:
> 14 years at Verizon Wireless and I despised the crop of multicast products
> that seemed to pop up from time to time.  [...]  Content
> delivery systems moving the content closer to edge customers makes this
> less of a problem as well. [...]
> Torrent style distribution appears to be particularly effective as long as
> you can maintain a pool of users to distribute the content.

Hi Corey,

Would it be fair to say that:

Unicast delivery from distributed caches (e.g. CDNs, Content Delivery
Networks) and/or unicast peer to peer transfer is more effective in
nearly all applications where interdomain multicast routing is a
candidate solution?

If that's true, would it be useful for ISPs to build some kind of
generalized multi-layer streaming cache system that any end-user
application could make use of? Build caching into the system's
capabilities instead of it being hit or miss depending on who pays for
a CDN?

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From wmaton at ottix.net  Tue Sep  2 17:08:45 2014
From: wmaton at ottix.net (William F. Maton Sotomayor)
Date: Tue, 2 Sep 2014 13:08:45 -0400 (EDT)
Subject: Multicast Internet Route table.
In-Reply-To: <D02B359D.6F7A4%jeff.tantsura@ericsson.com>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost> <5405E594.8000401@alvarezp.ods.org>
 <D02B359D.6F7A4%jeff.tantsura@ericsson.com>
Message-ID: <alpine.DEB.2.03.1409021308230.8155@iskra.ottix.net>

On Tue, 2 Sep 2014, Jeff Tantsura wrote:

> It is not the network devices per se, it is additional configuration,
> security, MSDP peering, etc, i.e. OPEX
>
> Business justification for such effort is not obvious, (most of multicast
> deployments I have done in my previous life were because I loved the
> technology, not because of business needs :))

Ditto, although business needs played a part as well. :)

wfms


From gjshep at gmail.com  Tue Sep  2 17:10:51 2014
From: gjshep at gmail.com (Greg Shepherd)
Date: Tue, 2 Sep 2014 10:10:51 -0700
Subject: Multicast Internet Route table.
In-Reply-To: <20140902164825.GD14857@ricotta.doit.wisc.edu>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost>
 <5405E594.8000401@alvarezp.ods.org>
 <alpine.DEB.2.02.1409021803430.7929@uplift.swm.pp.se>
 <20140902164825.GD14857@ricotta.doit.wisc.edu>
Message-ID: <CABFReBodOq6AQEaG1Hb_VsMxKRvqE6GiW2-CZGF6u79+D8shfg@mail.gmail.com>

I'll try to be brief-ish..

Interdomain Multicast suffered from three fundamental problems:

1) Deering's original use cases are far different from what it's used for
today. His original intent was to create a broadcast domain overlay over an
L3 topology. With this came reqs which today are largely nothing more than
unnecessary complexity with limited security and stability. The primary bit
of baggage is network based source discovery - the idea that anyone can
send and everyone will get those packets. Today all we want are explicit
trees. SSM solves these issues, but requires IP stacks, apps, and networks
to all support SSM. BUT, the one bit that Deering got right which the
community ditched was overlay. He knew not all boxes would support it so
DVMRP included tunneling (which I think is the first RFC to use overlay
encapsulation, but I'm willing to be wrong here.) When PIM replaced DVMRP
we unfortunately retained network based source discovery (RPs, MSDP, etc..)
but ditched encapsulation. This caused number 2 below.

2) Everyone must enable it or nobody can really benefit from it. The push
for native multicast (PIM) at the end of the last century was well
intended, but failed. If we had made IGMP multi-hop or something similar to
provide jumping over unicast-only networks we may be in a different place
today. But today we do have AMT which is trying to solve this problem. Some
venders do support it and some networks have already rolled it out in
trials. This may have some hope in changing the game.

3) Multicast is UDP. Many of the "multicast" problems people have stated
here on the list can more accurately be classified as UDP problems. When
using UDP rather than TCP, congestion control and reliability need to be
addressed at the application layer. Some solutions have capitalized on this
requirement by engineering solutions for each independently rather than
being stuck trying to game TCP (see unicast ABR).

So, with SSM only, an overlay layer like AMT, and a resilient application
layer CC and reliability we may have the right tools to see a larger global
multicast footprint. Or we may have figured all this out a bit too late.

Greg


On Tue, Sep 2, 2014 at 9:48 AM, Dale W. Carder <dwcarder at wisc.edu> wrote:

> Thus spake Mikael Abrahamsson (swmike at swm.pp.se) on Tue, Sep 02, 2014 at
> 06:05:42PM +0200:
> > On Tue, 2 Sep 2014, Octavio Alvarez wrote:
> >
> > >I have never used interdomain multicast but I imagine the global
> m-routing
> > >table would quickly become large.
> >
> > I have set up interdomain routing connecting both to a few peers and a
> Tier1
> > transit provider. Not many non-research networks to be seen.
> >
> > Also, since we didn't use it it kept breaking and I had to fix it every
> two
> > years or so, where it probably had been down for months.
> >
> > I don't believe in Internet-wide multicast happening in current
> incarnation,
> > it's just too fragile and too few people are using it. It wouldn't scale
> > either due to all the state that needs to be kept.
>
> Inter-domain multicast was largely replaced in practice by CDN's.
>
> In addition to scale issues in keeping state, large wireless L1
> environments
> are hostile to functioning multicast.
>
> Dale
>


From m.hallgren at free.fr  Tue Sep  2 19:32:31 2014
From: m.hallgren at free.fr (Michael Hallgren)
Date: Tue, 02 Sep 2014 21:32:31 +0200
Subject: Multicast Internet Route table.
In-Reply-To: <alpine.DEB.2.02.1409021803430.7929@uplift.swm.pp.se>
References: <A11CB189CA381D4E8002572EFF81F18B1F676B40@SG70XWXCHMBA03.zap.alcatel-lucent.com>
 <20140902074638.266a657b@localhost> <5405E594.8000401@alvarezp.ods.org>
 <alpine.DEB.2.02.1409021803430.7929@uplift.swm.pp.se>
Message-ID: <54061B4F.8020703@free.fr>

Le 02/09/2014 18:05, Mikael Abrahamsson a ?crit :
> On Tue, 2 Sep 2014, Octavio Alvarez wrote:
>
>> I have never used interdomain multicast but I imagine the global
>> m-routing table would quickly become large.
>
> I have set up interdomain routing connecting both to a few peers and a
> Tier1 transit provider. Not many non-research networks to be seen.
>
> Also, since we didn't use it it kept breaking and I had to fix it
> every two years or so, where it probably had been down for months.
>
> I don't believe in Internet-wide multicast happening in current
> incarnation, it's just too fragile and too few people are using it. It
> wouldn't scale either due to all the state that needs to be kept.
>
Been there as well. Now, IPv6 mcast? ;-)

Cheers,
mh


From joe at nethead.com  Tue Sep  2 19:50:12 2014
From: joe at nethead.com (Joe Hamelin)
Date: Tue, 2 Sep 2014 12:50:12 -0700
Subject: Fwd: [ PRIVACY Forum ] An Iranian Grand Ayatollah Issues Fatwa
 Stating High Speed Internet is against Sharia
In-Reply-To: <54040D64.7060806@nic-naa.net>
References: <3338313.10593.1409549727117.JavaMail.root@benjamin.baylink.com>
 <54040D64.7060806@nic-naa.net>
Message-ID: <CAO0-hXY2dz13PSHgWrz0fW4t6y-E9m9coiBH5yjtq6-ROsT--w@mail.gmail.com>

I'm guessing that he is upset at the price of new Sandvines or whatever
they use.  Maybe a ploy to bend the vendor on maintenance contract cost.

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


From elouie at yahoo.com  Tue Sep  2 23:35:44 2014
From: elouie at yahoo.com (Eric A Louie)
Date: Tue, 2 Sep 2014 16:35:44 -0700
Subject: Recommendations, Colo Reno, Albuquerque, Phoenix, Las Vegas
Message-ID: <1409700944.88911.YahooMailNeo@web181601.mail.ne1.yahoo.com>

Does anyone have recommendations for Colocation space in any of those 4 cities?

thanks
Eric


From corey.touchet at corp.totalserversolutions.com  Wed Sep  3 00:28:24 2014
From: corey.touchet at corp.totalserversolutions.com (Corey Touchet)
Date: Wed, 3 Sep 2014 00:28:24 +0000
Subject: Recommendations, Colo Reno, Albuquerque, Phoenix, Las Vegas
In-Reply-To: <1409700944.88911.YahooMailNeo@web181601.mail.ne1.yahoo.com>
Message-ID: <D02BBCBA.1469B%corey.touchet@corp.totalserversolutions.com>

See response off list.





On 9/2/14, 5:35 PM, "Eric A Louie" <elouie at yahoo.com> wrote:

>Does anyone have recommendations for Colocation space in any of those 4
>cities?
>
>thanks
>Eric



From list at satchell.net  Wed Sep  3 03:07:09 2014
From: list at satchell.net (Stephen Satchell)
Date: Tue, 02 Sep 2014 20:07:09 -0700
Subject: Recommendations, Colo Reno, Albuquerque, Phoenix, Las Vegas
In-Reply-To: <1409700944.88911.YahooMailNeo@web181601.mail.ne1.yahoo.com>
References: <1409700944.88911.YahooMailNeo@web181601.mail.ne1.yahoo.com>
Message-ID: <540685DD.703@satchell.net>

On 09/02/2014 04:35 PM, Eric A Louie wrote:
> Does anyone have recommendations for Colocation space in any of those 4 cities?
> 
> thanks
> Eric
> 

Co-location in Reno is a shrinking proposition.  The only place I know
about, and have toured, is:

Roller Networks
Seth Mattinen, CTO
3545 Airway Drive, Suite 114
Reno NV 89511
(775)284-0282 Ext 101
rollernetwork.com



From jra at baylink.com  Wed Sep  3 15:29:24 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 3 Sep 2014 11:29:24 -0400 (EDT)
Subject: DC opinions?
In-Reply-To: <24974266.10083.1409106566545.JavaMail.root@benjamin.baylink.com>
Message-ID: <12181700.10947.1409758164682.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>
> Sent: Tuesday, August 26, 2014 10:29:26 PM

> Anyone in Centurylink Ashburn or Seattle? Do you have an opinion?
> 
> Customary protocols apply.

Thanks to the three people who sent me opinions (trending negative), and
to Fergdawg, who thought my inquiry was overly cryptic.  Given I only got
three replies, perhaps he was right.  :-)

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From dmadory at renesys.com  Wed Sep  3 17:27:14 2014
From: dmadory at renesys.com (Doug Madory)
Date: Wed, 3 Sep 2014 13:27:14 -0400
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
References: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
Message-ID: <A32CC951-AFD3-4CB9-AE4B-57A79B94DF55@renesys.com>

http://www.bgpmon.net/using-bgp-data-to-find-spammers/

This blog post furthers this discussion, but it would have been appropriate to cite my original analysis explicitly, rather than simply citing "some discussion on Nanog recently."

If we want to foster a community where people share expertise on this list, fully citing others' work is essential, as in any professional or academic setting.

Doug Madory
603-643-9300 x115
Hanover, NH
"The Internet Intelligence Authority"

On Aug 31, 2014, at 2:04 PM, Doug Madory <dmadory at renesys.com> wrote:

> FWIW, this is from an IP squatting operation I came across in recent weeks. I encounter these things regularly in the course of working with BGP data - probably others do too. Usually I look up the ASN or prefix and often it has already been added to someone's spam source list. When I see that, I assume the "system is working" and move on.
> 
> In this case, starting late Jun, we have seen IP address ranges from around the world (most ranges are unused, sometimes hijacked space) announced by one of two (formerly unused) ASNs and routed through another formerly unused ASN, 57756, then on to Anders (AS39792) and out to the Internet in the following form:
> 
> 	... 39792 57756 {3.721, 43239}	prefix
> 
> The prefixes are only routed for an hour or two before it moves on to the next range of IP address space. Not sure if this is for spam or something else. Either way, it is probably associated with something bad. Earlier this month I reached out to a contact at Anders in Russia and gave him some details about what was happening. I didn't get a response, but within a couple of days the routing (mostly) shifted from Anders to through Petersburg Internet Network (AS44050). I have no idea if this was due to my email. The day it moved to PIN I sent similar emails to addresses I could find at PIN, but haven't seen any response. Now the these routes take one of two forms:
> 
> 	... 39792 57756 {3.721, 43239}	prefix
> 
> Or
> 
> 	... 44050 57756 {3.721, 43239}	prefix
> 
> This is mostly routed through Cogent (AS174), but Anders (AS39792) also has a lot of peers. I would advise that people treat any route coming through AS57756 is probably bad. AS57756 doesn't originate anything and hasn't since 28-Jun when it very briefly hijacked some NZ space.
> 
> Also, Pierre-Antoine Vervier from Symantec gave a good talk at NANOG in Feb about IP squatting for spam generation. Pierre and I have since compared notes on this topic.
> 
> -Doug Madory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140903/88d01802/attachment.sig>

From jlk at thrashyour.com  Wed Sep  3 17:27:40 2014
From: jlk at thrashyour.com (John Kinsella)
Date: Wed, 03 Sep 2014 10:27:40 -0700
Subject: old-school wiring nightmares
Message-ID: <54074F8C.5030901@thrashyour.com>

Wiring closet rats nests have frequently been a fun topic, so with that 
in mind, may I present telephone lines in Stockholm, circa late 1800s: 
http://www.thisiscolossal.com/2014/09/telefontornet-stockholm/

Have fun wire-tracing *that*

Click through to the flickr albums - the Tekniska Museet has put some 
great stuff up!


From morrowc.lists at gmail.com  Wed Sep  3 17:41:34 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 3 Sep 2014 13:41:34 -0400
Subject: old-school wiring nightmares
In-Reply-To: <54074F8C.5030901@thrashyour.com>
References: <54074F8C.5030901@thrashyour.com>
Message-ID: <CAL9jLabPwpnQFvSecX=VLc6g2GsJ48ke9L1_ut-_SnZh7B3ZHw@mail.gmail.com>

On Wed, Sep 3, 2014 at 1:27 PM, John Kinsella <jlk at thrashyour.com> wrote:
> Wiring closet rats nests have frequently been a fun topic, so with that in
> mind, may I present telephone lines in Stockholm, circa late 1800s:
> http://www.thisiscolossal.com/2014/09/telefontornet-stockholm/
>
> Have fun wire-tracing *that*

imagine the probably almost constant outages in the winter months due
to ice buildup on the lines...

> Click through to the flickr albums - the Tekniska Museet has put some great
> stuff up!


From cb.list6 at gmail.com  Wed Sep  3 17:47:17 2014
From: cb.list6 at gmail.com (Ca By)
Date: Wed, 3 Sep 2014 10:47:17 -0700
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <A32CC951-AFD3-4CB9-AE4B-57A79B94DF55@renesys.com>
References: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
 <A32CC951-AFD3-4CB9-AE4B-57A79B94DF55@renesys.com>
Message-ID: <CAD6AjGQL1L=2s3_YGq1miEVkqbph2c+tNTC83kviSyS-ARBwWg@mail.gmail.com>

On Wed, Sep 3, 2014 at 10:27 AM, Doug Madory <dmadory at renesys.com> wrote:
> http://www.bgpmon.net/using-bgp-data-to-find-spammers/
>
> This blog post furthers this discussion, but it would have been appropriate to cite my original analysis explicitly, rather than simply citing "some discussion on Nanog recently."
>
> If we want to foster a community where people share expertise on this list, fully citing others' work is essential, as in any professional or academic setting.
>
> Doug Madory
> 603-643-9300 x115
> Hanover, NH
> "The Internet Intelligence Authority"
>

Doug,

Furthering a sense of community through public shaming and allegations
of plagiarism?


> On Aug 31, 2014, at 2:04 PM, Doug Madory <dmadory at renesys.com> wrote:
>
>> FWIW, this is from an IP squatting operation I came across in recent weeks. I encounter these things regularly in the course of working with BGP data - probably others do too. Usually I look up the ASN or prefix and often it has already been added to someone's spam source list. When I see that, I assume the "system is working" and move on.
>>
>> In this case, starting late Jun, we have seen IP address ranges from around the world (most ranges are unused, sometimes hijacked space) announced by one of two (formerly unused) ASNs and routed through another formerly unused ASN, 57756, then on to Anders (AS39792) and out to the Internet in the following form:
>>
>>       ... 39792 57756 {3.721, 43239}  prefix
>>
>> The prefixes are only routed for an hour or two before it moves on to the next range of IP address space. Not sure if this is for spam or something else. Either way, it is probably associated with something bad. Earlier this month I reached out to a contact at Anders in Russia and gave him some details about what was happening. I didn't get a response, but within a couple of days the routing (mostly) shifted from Anders to through Petersburg Internet Network (AS44050). I have no idea if this was due to my email. The day it moved to PIN I sent similar emails to addresses I could find at PIN, but haven't seen any response. Now the these routes take one of two forms:
>>
>>       ... 39792 57756 {3.721, 43239}  prefix
>>
>> Or
>>
>>       ... 44050 57756 {3.721, 43239}  prefix
>>
>> This is mostly routed through Cogent (AS174), but Anders (AS39792) also has a lot of peers. I would advise that people treat any route coming through AS57756 is probably bad. AS57756 doesn't originate anything and hasn't since 28-Jun when it very briefly hijacked some NZ space.
>>
>> Also, Pierre-Antoine Vervier from Symantec gave a good talk at NANOG in Feb about IP squatting for spam generation. Pierre and I have since compared notes on this topic.
>>
>> -Doug Madory
>


From corbe at corbe.net  Wed Sep  3 18:29:38 2014
From: corbe at corbe.net (Daniel Corbe)
Date: Wed, 03 Sep 2014 14:29:38 -0400
Subject: old-school wiring nightmares
In-Reply-To: <CAL9jLabPwpnQFvSecX=VLc6g2GsJ48ke9L1_ut-_SnZh7B3ZHw@mail.gmail.com>
 (Christopher Morrow's message of "Wed, 3 Sep 2014 13:41:34 -0400")
References: <54074F8C.5030901@thrashyour.com>
 <CAL9jLabPwpnQFvSecX=VLc6g2GsJ48ke9L1_ut-_SnZh7B3ZHw@mail.gmail.com>
Message-ID: <ygftx4o7e25.fsf@corbe.net>

Christopher Morrow <morrowc.lists at gmail.com> writes:

> On Wed, Sep 3, 2014 at 1:27 PM, John Kinsella <jlk at thrashyour.com> wrote:
>> Wiring closet rats nests have frequently been a fun topic, so with that in
>> mind, may I present telephone lines in Stockholm, circa late 1800s:
>> http://www.thisiscolossal.com/2014/09/telefontornet-stockholm/
>>
>> Have fun wire-tracing *that*

And things worked like that for decades.

>
> imagine the probably almost constant outages in the winter months due
> to ice buildup on the lines...
>

This still happens.   Overhead fiber is a thing you know.

>> Click through to the flickr albums - the Tekniska Museet has put some great
>> stuff up!


From isaacnanog at gmail.com  Wed Sep  3 09:00:17 2014
From: isaacnanog at gmail.com (Isaac Adams)
Date: Wed, 3 Sep 2014 10:00:17 +0100
Subject: Vendor cert levels
Message-ID: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>

Hey Folks,

I am trying to work out a strategy for vendor certification in our company.
As a general rule, do you all fund employees certification and if so what
kind of levels do you try to maintain as good practice?

For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE?

Clearly certification does not usually reflect ability but it does help
people feel valued and to maintain a basic level of competence.

Thanks all,
Isaac


From morrowc.lists at gmail.com  Wed Sep  3 19:11:23 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 3 Sep 2014 15:11:23 -0400
Subject: old-school wiring nightmares
In-Reply-To: <ygftx4o7e25.fsf@corbe.net>
References: <54074F8C.5030901@thrashyour.com>
 <CAL9jLabPwpnQFvSecX=VLc6g2GsJ48ke9L1_ut-_SnZh7B3ZHw@mail.gmail.com>
 <ygftx4o7e25.fsf@corbe.net>
Message-ID: <CAL9jLaaSvoBy=_FuyA7D0zqZsuaNmCf67w9ubUH2KJOU=tiLMA@mail.gmail.com>

On Wed, Sep 3, 2014 at 2:29 PM, Daniel Corbe <corbe at corbe.net> wrote:
> Christopher Morrow <morrowc.lists at gmail.com> writes:
>>
>> imagine the probably almost constant outages in the winter months due
>> to ice buildup on the lines...
>>
>
> This still happens.   Overhead fiber is a thing you know.
>

the hell you say!


From ahebert at pubnix.net  Wed Sep  3 19:22:55 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Wed, 03 Sep 2014 15:22:55 -0400
Subject: old-school wiring nightmares
In-Reply-To: <CAL9jLaaSvoBy=_FuyA7D0zqZsuaNmCf67w9ubUH2KJOU=tiLMA@mail.gmail.com>
References: <54074F8C.5030901@thrashyour.com>
 <CAL9jLabPwpnQFvSecX=VLc6g2GsJ48ke9L1_ut-_SnZh7B3ZHw@mail.gmail.com>
 <ygftx4o7e25.fsf@corbe.net>
 <CAL9jLaaSvoBy=_FuyA7D0zqZsuaNmCf67w9ubUH2KJOU=tiLMA@mail.gmail.com>
Message-ID: <54076A8F.6050702@pubnix.net>

On 09/03/14 15:11, Christopher Morrow wrote:
> On Wed, Sep 3, 2014 at 2:29 PM, Daniel Corbe <corbe at corbe.net> wrote:
>> Christopher Morrow <morrowc.lists at gmail.com> writes:
>>> imagine the probably almost constant outages in the winter months due
>>> to ice buildup on the lines...
>>>
>> This still happens.   Overhead fiber is a thing you know.
>>
> the hell you say!
>
>
Like this?

http://i980.photobucket.com/albums/ae281/ipaqted/rodent_zps98bc0abf.jpg




From jared at puck.nether.net  Wed Sep  3 19:23:16 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 3 Sep 2014 15:23:16 -0400
Subject: Vendor cert levels
In-Reply-To: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
Message-ID: <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>


> On Sep 3, 2014, at 5:00 AM, Isaac Adams <isaacnanog at gmail.com> wrote:
> 
> Hey Folks,
> 
> I am trying to work out a strategy for vendor certification in our company.
> As a general rule, do you all fund employees certification and if so what
> kind of levels do you try to maintain as good practice?
> 
> For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE?
> 
> Clearly certification does not usually reflect ability but it does help
> people feel valued and to maintain a basic level of competence.

Cisco discriminates against customers without certification and delays service and support to them as a result.  (e.g.: you can?t open a sev 1 case online unless you are ?CCIE?).

You likely want to have someone with this access in their account to speed access when there are network critical issues.

- Jared

From marshall.eubanks at gmail.com  Wed Sep  3 19:45:25 2014
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Wed, 3 Sep 2014 15:45:25 -0400
Subject: Facebook down?
Message-ID: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>

http://www.downforeveryoneorjustme.com/facebook.com

It's not just you! *http://facebook.com* <http://facebook.com/> looks down
from here.

Relevant because of the likely increase in productiviity


Regards

Marshall Eubanks


From auser at mind.net  Wed Sep  3 19:46:27 2014
From: auser at mind.net (aUser)
Date: Wed, 3 Sep 2014 12:46:27 -0700
Subject: Facebook down?
Message-ID: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>

Appears to be in Oregon, Southern Oregon.  Mobile too.

Sent from my iPhone 5S.

> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> 
> This message has no content.


From nanog at hostleasing.net  Wed Sep  3 19:48:51 2014
From: nanog at hostleasing.net (Randy Epstein)
Date: Wed, 03 Sep 2014 15:48:51 -0400
Subject: Facebook down?
In-Reply-To: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
Message-ID: <D02CE8DE.B69C3%nanog@hostleasing.net>

Yes.

On 9/3/14, 3:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com> wrote:

>http://www.downforeveryoneorjustme.com/facebook.com
>
>It's not just you! *http://facebook.com* <http://facebook.com/> looks down
>from here.
>
>Relevant because of the likely increase in productiviity
>
>
>Regards
>
>Marshall Eubanks




From wbailey at satelliteintelligencegroup.com  Wed Sep  3 19:48:44 2014
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 3 Sep 2014 19:48:44 +0000
Subject: Facebook down?
In-Reply-To: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
Message-ID: <D02CBE92.21EE9%wbailey@satelliteintelligencegroup.com>

I?m getting a ton done right now too.. Hasn?t been working since my first
attempt about 20 minutes ago.



On 9/3/14, 12:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com> wrote:

>http://www.downforeveryoneorjustme.com/facebook.com
>
>It's not just you! *http://facebook.com* <http://facebook.com/> looks down
>from here.
>
>Relevant because of the likely increase in productiviity
>
>
>Regards
>
>Marshall Eubanks



From kate at quadranet.com  Wed Sep  3 19:51:22 2014
From: kate at quadranet.com (Kate Gerry)
Date: Wed, 3 Sep 2014 12:51:22 -0700
Subject: Facebook down?
In-Reply-To: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F601A7E7EE2C59@EXCH>

This is awesome. Though I think this will be more of a time sink with employees F5ing until Facebook is back online.

Down from Los Angeles.

--

-----Original Message-----
From: NANOG [mailto:nanog-bounces+kate=quadranet.com at nanog.org] On Behalf Of aUser
Sent: Wednesday, September 3, 2014 12:46 PM
To: Marshall Eubanks
Cc: nanog at nanog.org
Subject: Re: Facebook down?

Appears to be in Oregon, Southern Oregon.  Mobile too.

Sent from my iPhone 5S.

> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> 
> This message has no content.


From bkain1 at ford.com  Wed Sep  3 19:51:59 2014
From: bkain1 at ford.com (Kain, Rebecca (.))
Date: Wed, 3 Sep 2014 19:51:59 +0000
Subject: Facebook down?
In-Reply-To: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
Message-ID: <7DB845D64966DC44A1CC592780539B4B011E7DB1@nafmbx47.exchange.ford.com>

Down here at Ford, Dearborn Michigan


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marshall Eubanks
Sent: Wednesday, September 03, 2014 3:45 PM
To: nanog at nanog.org
Subject: Facebook down?

http://www.downforeveryoneorjustme.com/facebook.com

It's not just you! *http://facebook.com* <http://facebook.com/> looks down
from here.

Relevant because of the likely increase in productiviity


Regards

Marshall Eubanks

From di at egihosting.com  Wed Sep  3 19:52:17 2014
From: di at egihosting.com (Di Li)
Date: Wed, 3 Sep 2014 12:52:17 -0700
Subject: Facebook down?
In-Reply-To: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
Message-ID: <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>

SJC too


On Wed, Sep 3, 2014 at 12:46 PM, aUser <auser at mind.net> wrote:

> Appears to be in Oregon, Southern Oregon.  Mobile too.
>
> Sent from my iPhone 5S.
>
> > On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
> marshall.eubanks at gmail.com> wrote:
> >
> > This message has no content.
>



-- 
Thanks,
Di


From rwebb at ropeguru.com  Wed Sep  3 19:54:21 2014
From: rwebb at ropeguru.com (Robert Webb)
Date: Wed, 03 Sep 2014 15:54:21 -0400
Subject: Facebook down?
In-Reply-To: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
Message-ID: <web-221061@mail.ropeguru.com>

Down out of the VA/DC area also.

On Wed, 3 Sep 2014 12:46:27 -0700
  aUser <auser at mind.net> wrote:
> Appears to be in Oregon, Southern Oregon.  Mobile too.
> 
> Sent from my iPhone 5S.
> 
>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks 
>><marshall.eubanks at gmail.com> wrote:
>> 
>> This message has no content.



From nanog at hostleasing.net  Wed Sep  3 19:56:06 2014
From: nanog at hostleasing.net (Randy Epstein)
Date: Wed, 03 Sep 2014 15:56:06 -0400
Subject: Facebook down?
In-Reply-To: <D02CE8DE.B69C3%nanog@hostleasing.net>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
 <D02CE8DE.B69C3%nanog@hostleasing.net>
Message-ID: <D02CEA92.B69DB%nanog@hostleasing.net>

Back up now.

On 9/3/14, 3:48 PM, "Randy Epstein" <nanog at hostleasing.net> wrote:

>Yes.
>
>On 9/3/14, 3:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com> wrote:
>
>>http://www.downforeveryoneorjustme.com/facebook.com
>>
>>It's not just you! *http://facebook.com* <http://facebook.com/> looks
>>down
>>from here.
>>
>>Relevant because of the likely increase in productiviity
>>
>>
>>Regards
>>
>>Marshall Eubanks
>
>




From w3yni1 at gmail.com  Wed Sep  3 19:58:53 2014
From: w3yni1 at gmail.com (Charles Mills)
Date: Wed, 3 Sep 2014 15:58:53 -0400
Subject: Facebook down?
In-Reply-To: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
Message-ID: <CAOF0KO8HOfVsSdETKnKGYj_i3Yys2FnD9EivmJ32qoMzrMs2kA@mail.gmail.com>

W. PA. too.  Looks pretty widespread.


On Wed, Sep 3, 2014 at 3:46 PM, aUser <auser at mind.net> wrote:

> Appears to be in Oregon, Southern Oregon.  Mobile too.
>
> Sent from my iPhone 5S.
>
> > On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
> marshall.eubanks at gmail.com> wrote:
> >
> > This message has no content.
>


From deleskie at gmail.com  Wed Sep  3 20:00:13 2014
From: deleskie at gmail.com (jim deleskie)
Date: Wed, 3 Sep 2014 17:00:13 -0300
Subject: Facebook down?
In-Reply-To: <D02CBE92.21EE9%wbailey@satelliteintelligencegroup.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
 <D02CBE92.21EE9%wbailey@satelliteintelligencegroup.com>
Message-ID: <CAJL_ZMOkdfA1m_Y_Dv3M3MK4H_nn-tgE47ZecRBbxbRxbQTiSQ@mail.gmail.com>

>From East coast of Canada down as well.


On Wed, Sep 3, 2014 at 4:48 PM, Warren Bailey <
wbailey at satelliteintelligencegroup.com> wrote:

> I?m getting a ton done right now too.. Hasn?t been working since my first
> attempt about 20 minutes ago.
>
>
>
> On 9/3/14, 12:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com>
> wrote:
>
> >http://www.downforeveryoneorjustme.com/facebook.com
> >
> >It's not just you! *http://facebook.com* <http://facebook.com/> looks
> down
> >from here.
> >
> >Relevant because of the likely increase in productiviity
> >
> >
> >Regards
> >
> >Marshall Eubanks
>
>


From mark at viviotech.net  Wed Sep  3 20:01:29 2014
From: mark at viviotech.net (Mark Keymer)
Date: Wed, 03 Sep 2014 13:01:29 -0700
Subject: Facebook down?
In-Reply-To: <D02CBE92.21EE9%wbailey@satelliteintelligencegroup.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
 <D02CBE92.21EE9%wbailey@satelliteintelligencegroup.com>
Message-ID: <54077399.3030500@viviotech.net>

Was down here too.

But I see the homepage now.

However, http://www.downforeveryoneorjustme.com/facebook.com still shows 
down. So maybe it is just starting to come up for some?
What I would love to know what happened. :)

Sincerely,

Mark

On 9/3/2014 12:48 PM, Warren Bailey wrote:
> I?m getting a ton done right now too.. Hasn?t been working since my first
> attempt about 20 minutes ago.
>
>
>
> On 9/3/14, 12:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com> wrote:
>
>> http://www.downforeveryoneorjustme.com/facebook.com
>>
>> It's not just you! *http://facebook.com* <http://facebook.com/> looks down
> >from here.
>> Relevant because of the likely increase in productiviity
>>
>>
>> Regards
>>
>> Marshall Eubanks



From vristevs at ramapo.edu  Wed Sep  3 20:05:55 2014
From: vristevs at ramapo.edu (Vlad)
Date: Wed, 03 Sep 2014 16:05:55 -0400
Subject: Facebook down?
In-Reply-To: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
Message-ID: <540774A3.1020109@ramapo.edu>

Thanks for posting.  Same here too in NJ.

  I notified our helpdesk to prepare for the 3,000 students who will 
call in telling us is the "Internet is broken"

On 9/3/2014 3:45 PM, Marshall Eubanks wrote:
> http://www.downforeveryoneorjustme.com/facebook.com
>
> It's not just you! *http://facebook.com* <http://facebook.com/> looks down
> from here.
>
> Relevant because of the likely increase in productiviity
>
>
> Regards
>
> Marshall Eubanks



From eriktown at gmail.com  Wed Sep  3 20:06:20 2014
From: eriktown at gmail.com (Bjorn Townsend)
Date: Wed, 3 Sep 2014 16:06:20 -0400
Subject: Facebook down?
In-Reply-To: <7DB845D64966DC44A1CC592780539B4B011E7DB1@nafmbx47.exchange.ford.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
 <7DB845D64966DC44A1CC592780539B4B011E7DB1@nafmbx47.exchange.ford.com>
Message-ID: <CALviwb-w53UH=imLdidmpESF_ZGKPexiSHxF508jNCrTBmjmsA@mail.gmail.com>

Working in NYC!


On Wed, Sep 3, 2014 at 3:51 PM, Kain, Rebecca (.) <bkain1 at ford.com> wrote:

> Down here at Ford, Dearborn Michigan
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marshall Eubanks
> Sent: Wednesday, September 03, 2014 3:45 PM
> To: nanog at nanog.org
> Subject: Facebook down?
>
> http://www.downforeveryoneorjustme.com/facebook.com
>
> It's not just you! *http://facebook.com* <http://facebook.com/> looks down
> from here.
>
> Relevant because of the likely increase in productiviity
>
>
> Regards
>
> Marshall Eubanks
>



-- 
Bjorn Townsend | eriktown at gmail.com


From mike at sentex.net  Wed Sep  3 20:08:12 2014
From: mike at sentex.net (Mike Tancsa)
Date: Wed, 03 Sep 2014 16:08:12 -0400
Subject: Facebook down?
In-Reply-To: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
Message-ID: <5407752C.9000609@sentex.net>

Back up now (from Toronto) with the following IPs 
(69.171.237.20,2a03:2880:10:cf07:face:b00c:0:1)

Was down when I first checked.

% telnet www.facebook.com 443
Trying 69.171.237.20...
telnet: connect to address 69.171.237.20: Connection refused
Trying 2a03:2880:10:cf07:face:b00c:0:1...
telnet: connect to address 2a03:2880:10:cf07:face:b00c:0:1: Connection 
refused
telnet: Unable to connect to remote host
%

% telnet www.facebook.com 443
Trying 69.171.237.20...
Connected to star.c10r.facebook.com.
Escape character is '^]'.
^]
telnet> cl
Connection closed.
% telnet -6  www.facebook.com 443
Trying 2a03:2880:10:cf07:face:b00c:0:1...
Connected to star.c10r.facebook.com.
Escape character is '^]'.
^]
telnet> cl
Connection closed.
%


On 9/3/2014 3:46 PM, aUser wrote:
> Appears to be in Oregon, Southern Oregon.  Mobile too.
>
> Sent from my iPhone 5S.
>
>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
>>
>> This message has no content.
>
>


-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/


From kristopher.doyen at gmail.com  Wed Sep  3 20:13:12 2014
From: kristopher.doyen at gmail.com (Kristopher Doyen)
Date: Wed, 3 Sep 2014 16:13:12 -0400
Subject: Facebook down?
In-Reply-To: <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>
Message-ID: <CAC+M4QSVM5MF5FVWOZWwB+jG6xT0c2Fwrg+AWpPu8V6eb5iEXA@mail.gmail.com>

Up here on Comcast in Tennessee.


On Wed, Sep 3, 2014 at 3:52 PM, Di Li <di at egihosting.com> wrote:

> SJC too
>
>
> On Wed, Sep 3, 2014 at 12:46 PM, aUser <auser at mind.net> wrote:
>
> > Appears to be in Oregon, Southern Oregon.  Mobile too.
> >
> > Sent from my iPhone 5S.
> >
> > > On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
> > marshall.eubanks at gmail.com> wrote:
> > >
> > > This message has no content.
> >
>
>
>
> --
> Thanks,
> Di
>


From edward.dore at freethought-internet.co.uk  Wed Sep  3 20:14:46 2014
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Wed, 3 Sep 2014 21:14:46 +0100
Subject: Facebook down?
In-Reply-To: <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>
Message-ID: <25BE7120-DCC8-43C5-8E5C-4C9560873B63@freethought-internet.co.uk>

It wasn't loading here in the UK either, although it's back now.

Edward Dore 
Freethought Internet 

On 3 Sep 2014, at 20:52, Di Li <di at egihosting.com> wrote:

> SJC too
> 
> 
> On Wed, Sep 3, 2014 at 12:46 PM, aUser <auser at mind.net> wrote:
> 
>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>> 
>> Sent from my iPhone 5S.
>> 
>>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
>> marshall.eubanks at gmail.com> wrote:
>>> 
>>> This message has no content.
>> 
> 
> 
> 
> -- 
> Thanks,
> Di



From djahandarie at gmail.com  Wed Sep  3 20:15:54 2014
From: djahandarie at gmail.com (Darius Jahandarie)
Date: Wed, 3 Sep 2014 16:15:54 -0400
Subject: Facebook down?
In-Reply-To: <web-221061@mail.ropeguru.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <web-221061@mail.ropeguru.com>
Message-ID: <CAFANWtUD7twPbeFg84R8WMTviDee2j3rKUA8BY=5ykNWXuOX5w@mail.gmail.com>

Down from intersellar orbit.

On Wed, Sep 3, 2014 at 3:54 PM, Robert Webb <rwebb at ropeguru.com> wrote:
> Down out of the VA/DC area also.
>
>
> On Wed, 3 Sep 2014 12:46:27 -0700
>  aUser <auser at mind.net> wrote:
>>
>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>>
>> Sent from my iPhone 5S.
>>
>>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks
>>> <marshall.eubanks at gmail.com> wrote:
>>>
>>> This message has no content.
>
>



-- 
Darius Jahandarie


From streiner at cluebyfour.org  Wed Sep  3 17:58:18 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 3 Sep 2014 13:58:18 -0400 (EDT)
Subject: Facebook down?
In-Reply-To: <CAOF0KO8HOfVsSdETKnKGYj_i3Yys2FnD9EivmJ32qoMzrMs2kA@mail.gmail.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <CAOF0KO8HOfVsSdETKnKGYj_i3Yys2FnD9EivmJ32qoMzrMs2kA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1409031356460.2883@whammy.cluebyfour.org>

Works here (large .edu in Western PA).  I would expect there to be rioting 
in the streets if FB was down.

jms

On Wed, 3 Sep 2014, Charles Mills wrote:

> W. PA. too.  Looks pretty widespread.
>
>
> On Wed, Sep 3, 2014 at 3:46 PM, aUser <auser at mind.net> wrote:
>
>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>>
>> Sent from my iPhone 5S.
>>
>>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
>> marshall.eubanks at gmail.com> wrote:
>>>
>>> This message has no content.
>>
>


From daniel.millar at gowifi.co.nz  Wed Sep  3 19:59:53 2014
From: daniel.millar at gowifi.co.nz (Daniel Millar)
Date: Wed, 3 Sep 2014 19:59:53 +0000
Subject: Facebook down?
In-Reply-To: <D02CE8DE.B69C3%nanog@hostleasing.net>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
 <D02CE8DE.B69C3%nanog@hostleasing.net>
Message-ID: <D02CEB67.2F1E%daniel.millar@gowifi.co.nz>

Looks to be back up now






On 3/09/14 3:48 pm, "Randy Epstein" <nanog at hostleasing.net> wrote:

>Yes.
>
>On 9/3/14, 3:45 PM, "Marshall Eubanks" <marshall.eubanks at gmail.com> wrote:
>
>>http://www.downforeveryoneorjustme.com/facebook.com
>>
>>It's not just you! *http://facebook.com* <http://facebook.com/> looks
>>down
>>from here.
>>
>>Relevant because of the likely increase in productiviity
>>
>>
>>Regards
>>
>>Marshall Eubanks
>
>



From robin.polak at gmail.com  Wed Sep  3 20:15:59 2014
From: robin.polak at gmail.com (Robin Polak)
Date: Wed, 3 Sep 2014 16:15:59 -0400
Subject: Facebook down?
In-Reply-To: <web-221061@mail.ropeguru.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <web-221061@mail.ropeguru.com>
Message-ID: <CAJy_fVEWjW9eKW3CP6DqJM4FkC5d_TC8frd8A2KgMqw1hXQw=w@mail.gmail.com>

It's up in NYC from Cogent

traceroute to facebook.com (173.252.110.27), 30 hops max, 60 byte packets
 1  pfsense.alloy.local (172.16.20.1)  0.308 ms  0.395 ms  0.259 ms
 2  10.0.2.2 (10.0.2.2)  0.719 ms  0.602 ms  0.480 ms
 3  * * *
 4  * * *
 5  * * *
 6  gi0-0-0-18.209.nr11.b001578-0.jfk01.atlas.cogentco.com (38.104.190.97)
 8.511 ms  4.990 ms  6.357 ms
 7  gi2-12.mag01.jfk01.atlas.cogentco.com (154.24.8.202)  3.595 ms
gi2-12.mag02.jfk01.atlas.cogentco.com (154.24.8.206)  3.753 ms
gi2-12.mag01.jfk01.atlas.cogentco.com (154.24.8.202)  4.069 ms
 8  te0-2-0-0.rcr22.jfk01.atlas.cogentco.com (154.54.80.89)  6.441 ms
te0-6-0-0.rcr22.jfk01.atlas.cogentco.com (154.54.80.97)  6.227 ms
te0-2-0-0.rcr22.jfk01.atlas.cogentco.com (154.54.80.89)  3.649 ms
 9  be2355.ccr21.jfk02.atlas.cogentco.com (154.54.43.93)  4.787 ms
be2356.ccr22.jfk02.atlas.cogentco.com (154.54.43.97)  4.290 ms
be2358.mpd22.jfk02.atlas.cogentco.com (154.54.43.105)  4.108 ms
10  be2150.mpd21.dca01.atlas.cogentco.com (154.54.31.129)  9.557 ms  9.228
ms be2151.mpd22.dca01.atlas.cogentco.com (154.54.40.73)  8.767 ms
11  be2112.ccr41.iad02.atlas.cogentco.com (154.54.5.233)  11.265 ms  12.065
ms be2113.ccr41.iad02.atlas.cogentco.com (154.54.6.169)  13.096 ms
12  xe-11-2-1.edge3.Washington4.Level3.net (4.68.63.173)  10.781 ms  11.072
ms  13.606 ms
13  4.53.116.78 (4.53.116.78)  10.876 ms  9.413 ms  9.890 ms
14  be2.bb02.iad3.tfbnw.net (31.13.24.8)  27.637 ms be3.bb01.iad3.tfbnw.net
(173.252.65.32)  24.573 ms  23.740 ms
15  ae12.bb04.frc3.tfbnw.net (31.13.24.95)  23.398 ms
ae17.bb04.frc3.tfbnw.net (31.13.29.232)  23.474 ms ae12.bb03.frc3.tfbnw.net
(31.13.24.88)  23.161 ms
16  ae87.dr04.frc1.tfbnw.net (173.252.64.53)  24.017 ms
ae90.dr02.frc1.tfbnw.net (173.252.65.111)  25.780 ms
ae89.dr04.frc1.tfbnw.net (173.252.65.99)  37.919 ms
17  * * *
18  * * *
19  edge-star-shv-13-frc1.facebook.com (173.252.110.27)  26.808 ms  25.720
ms  25.618 ms



On Wed, Sep 3, 2014 at 3:54 PM, Robert Webb <rwebb at ropeguru.com> wrote:

> Down out of the VA/DC area also.
>
>
> On Wed, 3 Sep 2014 12:46:27 -0700
>  aUser <auser at mind.net> wrote:
>
>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>>
>> Sent from my iPhone 5S.
>>
>>  On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
>>> marshall.eubanks at gmail.com> wrote:
>>>
>>> This message has no content.
>>>
>>
>


-- 
Robin Polak
E-Mail: robin.polak at gmail.com
V. 917-494-2080


From iggdawg at gmail.com  Wed Sep  3 20:36:50 2014
From: iggdawg at gmail.com (Ian Bowers)
Date: Wed, 3 Sep 2014 16:36:50 -0400
Subject: Facebook down?
In-Reply-To: <CALviwb-w53UH=imLdidmpESF_ZGKPexiSHxF508jNCrTBmjmsA@mail.gmail.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
 <7DB845D64966DC44A1CC592780539B4B011E7DB1@nafmbx47.exchange.ford.com>
 <CALviwb-w53UH=imLdidmpESF_ZGKPexiSHxF508jNCrTBmjmsA@mail.gmail.com>
Message-ID: <CAOtTuaoqLr=57+7Df8kiQV5FZXTVw4tLab4g3VfJYG+4EpCD2g@mail.gmail.com>

It's accessible in MA Boston, but runing MTR to facebook on TCP/80 is one
of the uglier readouts I've seen in a long time.


On Wed, Sep 3, 2014 at 4:06 PM, Bjorn Townsend <eriktown at gmail.com> wrote:

> Working in NYC!
>
>
> On Wed, Sep 3, 2014 at 3:51 PM, Kain, Rebecca (.) <bkain1 at ford.com> wrote:
>
> > Down here at Ford, Dearborn Michigan
> >
> >
> > -----Original Message-----
> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Marshall
> Eubanks
> > Sent: Wednesday, September 03, 2014 3:45 PM
> > To: nanog at nanog.org
> > Subject: Facebook down?
> >
> > http://www.downforeveryoneorjustme.com/facebook.com
> >
> > It's not just you! *http://facebook.com* <http://facebook.com/> looks
> down
> > from here.
> >
> > Relevant because of the likely increase in productiviity
> >
> >
> > Regards
> >
> > Marshall Eubanks
> >
>
>
>
> --
> Bjorn Townsend | eriktown at gmail.com
>


From kristopher.doyen at gmail.com  Wed Sep  3 20:41:03 2014
From: kristopher.doyen at gmail.com (Kristopher Doyen)
Date: Wed, 3 Sep 2014 16:41:03 -0400
Subject: Facebook down?
In-Reply-To: <5407752C.9000609@sentex.net>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <5407752C.9000609@sentex.net>
Message-ID: <CAC+M4QRW9L7v9QgmJL9pavArE=mAJsxXQJyJ-PbakXBi_WvUXA@mail.gmail.com>

facebook.com has address 173.252.110.27
facebook.com has IPv6 address 2a03:2880:2110:df07:face:b00c:0:1
facebook.com mail is handled by 10 msgin.t.facebook.com.

www.facebook.com is an alias for star.c10r.facebook.com.
star.c10r.facebook.com has address 31.13.65.33
star.c10r.facebook.com has IPv6 address 2a03:2880:f011:301:face:b00c:0:1
star.c10r.facebook.com mail is handled by 10 msgin.t.facebook.com.

dig shows:

facebook.com. 453 IN A 173.252.110.27

So perhaps different dns entries are just cached depending on geographical
location.





On Wed, Sep 3, 2014 at 4:08 PM, Mike Tancsa <mike at sentex.net> wrote:

> Back up now (from Toronto) with the following IPs
> (69.171.237.20,2a03:2880:10:cf07:face:b00c:0:1)
>
> Was down when I first checked.
>
> % telnet www.facebook.com 443
> Trying 69.171.237.20...
> telnet: connect to address 69.171.237.20: Connection refused
> Trying 2a03:2880:10:cf07:face:b00c:0:1...
> telnet: connect to address 2a03:2880:10:cf07:face:b00c:0:1: Connection
> refused
> telnet: Unable to connect to remote host
> %
>
> % telnet www.facebook.com 443
> Trying 69.171.237.20...
> Connected to star.c10r.facebook.com.
> Escape character is '^]'.
> ^]
> telnet> cl
> Connection closed.
> % telnet -6  www.facebook.com 443
> Trying 2a03:2880:10:cf07:face:b00c:0:1...
> Connected to star.c10r.facebook.com.
> Escape character is '^]'.
> ^]
> telnet> cl
> Connection closed.
> %
>
>
>
> On 9/3/2014 3:46 PM, aUser wrote:
>
>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>>
>> Sent from my iPhone 5S.
>>
>>  On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
>>> marshall.eubanks at gmail.com> wrote:
>>>
>>> This message has no content.
>>>
>>
>>
>>
>
> --
> -------------------
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, mike at sentex.net
> Providing Internet services since 1994 www.sentex.net
> Cambridge, Ontario Canada   http://www.tancsa.com/
>


From iggdawg at gmail.com  Wed Sep  3 20:42:25 2014
From: iggdawg at gmail.com (Ian Bowers)
Date: Wed, 3 Sep 2014 16:42:25 -0400
Subject: Facebook down?
In-Reply-To: <CAC+M4QSVM5MF5FVWOZWwB+jG6xT0c2Fwrg+AWpPu8V6eb5iEXA@mail.gmail.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>
 <CAC+M4QSVM5MF5FVWOZWwB+jG6xT0c2Fwrg+AWpPu8V6eb5iEXA@mail.gmail.com>
Message-ID: <CAOtTuaq=kzEFGKX7LWGDU_jh=qvPJ9E4GyZaaLN_79o2aGEG3A@mail.gmail.com>

[image: Inline image 1]


On Wed, Sep 3, 2014 at 4:13 PM, Kristopher Doyen <kristopher.doyen at gmail.com
> wrote:

> Up here on Comcast in Tennessee.
>
>
> On Wed, Sep 3, 2014 at 3:52 PM, Di Li <di at egihosting.com> wrote:
>
> > SJC too
> >
> >
> > On Wed, Sep 3, 2014 at 12:46 PM, aUser <auser at mind.net> wrote:
> >
> > > Appears to be in Oregon, Southern Oregon.  Mobile too.
> > >
> > > Sent from my iPhone 5S.
> > >
> > > > On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
> > > marshall.eubanks at gmail.com> wrote:
> > > >
> > > > This message has no content.
> > >
> >
> >
> >
> > --
> > Thanks,
> > Di
> >
>


From sparctacus at gmail.com  Wed Sep  3 21:01:57 2014
From: sparctacus at gmail.com (Bryan Irvine)
Date: Wed, 3 Sep 2014 14:01:57 -0700
Subject: Facebook down?
In-Reply-To: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
References: <CAJNg7VKfkWj4mwPq1OBXnO=1Z1+jckfqnMULfE8U+9wvtFbagw@mail.gmail.com>
Message-ID: <CAG367gbiaot_5C912vBDnRjScqnpuTGKs96VmbH=W-RiRNQ-ZA@mail.gmail.com>

I called 911, they didn't know anything about it.


On Wed, Sep 3, 2014 at 12:45 PM, Marshall Eubanks <
marshall.eubanks at gmail.com> wrote:

> http://www.downforeveryoneorjustme.com/facebook.com
>
> It's not just you! *http://facebook.com* <http://facebook.com/> looks down
> from here.
>
> Relevant because of the likely increase in productiviity
>
>
> Regards
>
> Marshall Eubanks
>


From jra at baylink.com  Wed Sep  3 21:03:12 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 3 Sep 2014 17:03:12 -0400 (EDT)
Subject: DC opinions?
In-Reply-To: <24974266.10083.1409106566545.JavaMail.root@benjamin.baylink.com>
Message-ID: <13860118.11051.1409778192545.JavaMail.root@benjamin.baylink.com>

> Anyone in Centurylink Ashburn or Seattle? Do you have an opinion?

And the replies I got helped me to illustrate my concerns.

So now, off I go to go DC shopping.  Of course, I'm happy to hear people's
glowing opinions in this part of the process.  Requirements:

1) West/Central/East US (Seattle/Vegas/Virginia?  Maybe Chattanooga)
2) Disaster avoidance (Seismic, Wind, Water, Ice/Snow, etc)
3) Good DR per site
4) Direct access to big eyeball networks (Comcast, T-Bone, etc)
5) MPLS connectivity on a reasonably dense backbone, and between two/three
   data centers
6) As someone put it so lyrically the other day, "financial diversity"
   (If someone's going to pooch the records and accidentally shut you off,
   better they only hit 1/2 or 1/3 of your gear.)

The DCs need to be TIA-942 *certified*, though there appears to be some 
question about whether it's 942-A-1 that is required; I do not read the
proposal that way, myself.

I'll be looking to put in 6-10 racks; if a lockable cage isn't horribly more
expensive that'd be nice.  208/3ph, good UPSs, good gensets, good refuel,
good security; all that good stuff.

Anyone got a datacenter RFP in that general class that isn't company
proprietary?

Off list as usual; I'll summarize if anyone wants to know.  I won't be
saying where we went until we go there, as usual.  ;-)

Thanks,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Wed Sep  3 21:03:52 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 3 Sep 2014 17:03:52 -0400 (EDT)
Subject: Facebook down?
In-Reply-To: <CAFANWtUD7twPbeFg84R8WMTviDee2j3rKUA8BY=5ykNWXuOX5w@mail.gmail.com>
Message-ID: <6169695.11053.1409778232082.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Darius Jahandarie" <djahandarie at gmail.com>

> Down from intersellar orbit.

And Darius wins the Internet for today.

PS: What do you pay for a loop up there?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From nick at foobar.org  Wed Sep  3 21:06:08 2014
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 03 Sep 2014 22:06:08 +0100
Subject: Facebook down?
In-Reply-To: <CAFANWtUD7twPbeFg84R8WMTviDee2j3rKUA8BY=5ykNWXuOX5w@mail.gmail.com>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <web-221061@mail.ropeguru.com>
 <CAFANWtUD7twPbeFg84R8WMTviDee2j3rKUA8BY=5ykNWXuOX5w@mail.gmail.com>
Message-ID: <540782C0.9070100@foobar.org>

it totally was not down from interstellar orbit.  You didn't have time to
tell because rtt from interstellar space is 11 hours minimum, which is even
worse than some cellular data operators.  Pants on fire.

Can anyone confirm if it was down in the MD/DC, Northern Oregon, Eastern PA
and Palo Alto areas?  I'm dying to know.

Nick

On 03/09/2014 21:15, Darius Jahandarie wrote:
> Down from intersellar orbit.
> 
> On Wed, Sep 3, 2014 at 3:54 PM, Robert Webb <rwebb at ropeguru.com> wrote:
>> Down out of the VA/DC area also.
>>
>>
>> On Wed, 3 Sep 2014 12:46:27 -0700
>>  aUser <auser at mind.net> wrote:
>>>
>>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>>>
>>> Sent from my iPhone 5S.
>>>
>>>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks
>>>> <marshall.eubanks at gmail.com> wrote:
>>>>
>>>> This message has no content.
>>
>>
> 
> 
> 



From andree+nanog at toonk.nl  Wed Sep  3 21:06:52 2014
From: andree+nanog at toonk.nl (Andree Toonk)
Date: Wed, 03 Sep 2014 14:06:52 -0700
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <A32CC951-AFD3-4CB9-AE4B-57A79B94DF55@renesys.com>
References: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
 <A32CC951-AFD3-4CB9-AE4B-57A79B94DF55@renesys.com>
Message-ID: <540782EC.9080507@toonk.nl>

.-- My secret spy satellite informs me that at 2014-09-03 10:27 AM  Doug
Madory wrote:
> http://www.bgpmon.net/using-bgp-data-to-find-spammers/
> 
> This blog post furthers this discussion, but it would have been appropriate to cite my original analysis explicitly, rather than simply citing "some discussion on Nanog recently."

I appreciate your point but you're assuming that you are the original /
sole source. More than one org has been working on this and the recent
increase in IP squatting has been discussed on a few private and public
lists. All content in this post originates from our own data and
analysis. As you've seen we described a second (not previously
discussed) case in great detail as well.

> If we want to foster a community where people share expertise on this
list, fully citing others' work is essential, as in any professional or
academic setting.

Credit where credit is due, in the blog we publicly thanked one
Individual (Job) for his help. To be honest I think this is a great
example of how we worked with the community. We've worked with the ISP's
involved, shared all our data and worked closely with some of them to
verify traffic patterns and figure out why these prefixes were being
accepted.


Cheers,
 Andree (BGPmon)



From owen at delong.com  Wed Sep  3 21:16:58 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Sep 2014 14:16:58 -0700
Subject: Facebook down?
In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F601A7E7EE2C59@EXCH>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <4B4120B1642DCF48ACA84E4F82C8E1F601A7E7EE2C59@EXCH>
Message-ID: <FEAF99B3-13A1-4F55-B3C2-1AB741263793@delong.com>

What would I be doing with a load balancer as an alternative time-waste for Facebook?

Or are you suggesting that I would amuse myself by lowering the brightness of my keyboard backlight?

I am confused by your comment.

Owen

On Sep 3, 2014, at 12:51 PM, Kate Gerry <kate at quadranet.com> wrote:

> This is awesome. Though I think this will be more of a time sink with employees F5ing until Facebook is back online.
> 
> Down from Los Angeles.
> 
> --
> 
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+kate=quadranet.com at nanog.org] On Behalf Of aUser
> Sent: Wednesday, September 3, 2014 12:46 PM
> To: Marshall Eubanks
> Cc: nanog at nanog.org
> Subject: Re: Facebook down?
> 
> Appears to be in Oregon, Southern Oregon.  Mobile too.
> 
> Sent from my iPhone 5S.
> 
>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
>> 
>> This message has no content.



From tfarrell at riotgames.com  Wed Sep  3 21:26:39 2014
From: tfarrell at riotgames.com (Trent Farrell)
Date: Wed, 3 Sep 2014 14:26:39 -0700
Subject: Vendor cert levels
In-Reply-To: <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
Message-ID: <CAKDtZnkQ7-v6XqM7ZRxoq=yaJVRxNF3Z6Hh5kZ-e8hV+nS_fWg@mail.gmail.com>

^^ It really helps if you're a Cisco shop to have CCIEs.

Every place I've worked has offered to refund the cost of a cert after
you pass (if the employee fails, the cost is on them), and it's had a
pretty decent uptake among the more junior staff - as well as the CCIE
re-certs.

I'm not sure if Juniper have a similar type system of rewarding
partners that are packed with certified engineers, but I wouldn't be
surprised if they did.


On Wed, Sep 3, 2014 at 12:23 PM, Jared Mauch <jared at puck.nether.net> wrote:
>
>> On Sep 3, 2014, at 5:00 AM, Isaac Adams <isaacnanog at gmail.com> wrote:
>>
>> Hey Folks,
>>
>> I am trying to work out a strategy for vendor certification in our company.
>> As a general rule, do you all fund employees certification and if so what
>> kind of levels do you try to maintain as good practice?
>>
>> For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE?
>>
>> Clearly certification does not usually reflect ability but it does help
>> people feel valued and to maintain a basic level of competence.
>
> Cisco discriminates against customers without certification and delays service and support to them as a result.  (e.g.: you can?t open a sev 1 case online unless you are ?CCIE?).
>
> You likely want to have someone with this access in their account to speed access when there are network critical issues.
>
> - Jared



-- 
Trent Farrell

Riot Games

IP Network Engineer

E: tfarrell at riotgames.com | IE:  +353 83 446 6809 | US: +1 424 285 9825

Summoner name: Foro


From bill at herrin.us  Wed Sep  3 21:35:47 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 3 Sep 2014 17:35:47 -0400
Subject: DC opinions?
In-Reply-To: <13860118.11051.1409778192545.JavaMail.root@benjamin.baylink.com>
References: <24974266.10083.1409106566545.JavaMail.root@benjamin.baylink.com>
 <13860118.11051.1409778192545.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP-guGXGYFFmztF-CpPfk=9P57=oCouV65a1h3eJ-ro72vjBjg@mail.gmail.com>

On Wed, Sep 3, 2014 at 5:03 PM, Jay Ashworth <jra at baylink.com> wrote:
> 3) Good DR per site

I put a DR site at DR Fortress in Honolulu. One of the best decisions
I ever made.

Sadly, maintenance of that site has now passed to another...

-Bill


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From bluegill at freeshell.org  Wed Sep  3 21:34:05 2014
From: bluegill at freeshell.org (Jon Garrison)
Date: Wed, 03 Sep 2014 14:34:05 -0700
Subject: Vendor cert levels
In-Reply-To: <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
Message-ID: <78D13690-764F-4397-8358-7F9BB8B8C6A7@freeshell.org>

On 3 Sep 2014, at 12:23, Jared Mauch wrote:

>> On Sep 3, 2014, at 5:00 AM, Isaac Adams <isaacnanog at gmail.com> wrote:
>>
>> Hey Folks,
>>
>> I am trying to work out a strategy for vendor certification in our 
>> company.
>> As a general rule, do you all fund employees certification and if so 
>> what
>> kind of levels do you try to maintain as good practice?
>>
>> For example. NOC staff should be JNCIA and engineering JNCIP to 
>> JNCIE?
>>
>> Clearly certification does not usually reflect ability but it does 
>> help
>> people feel valued and to maintain a basic level of competence.
>
> Cisco discriminates against customers without certification and delays 
> service and support to them as a result.  (e.g.: you can?t open a 
> sev 1 case online unless you are ?CCIE?).

You can however just call them and yell "Environment Down" and they will 
call it whatever Sev you want. There are an unending number of issues 
with their online case opening "portal" however.

Filling out a form online to wait a call back was never my first choice. 
Plus putting that Cisco hold music on speaker is a good way to improve 
the mood!

> You likely want to have someone with this access in their account to 
> speed access when there are network critical issues.
>
> - Jared


From derek.andrew at usask.ca  Wed Sep  3 21:47:42 2014
From: derek.andrew at usask.ca (Derek Andrew)
Date: Wed, 03 Sep 2014 15:47:42 -0600
Subject: Vendor cert levels
In-Reply-To: <6b46ade3b6ba40539985bf5f20052984@CAMPUSCAS3.usask.ca>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
 <6b46ade3b6ba40539985bf5f20052984@CAMPUSCAS3.usask.ca>
Message-ID: <CAAf7Uok2DM3z52N67-U_qL433RY+piwy-NKPHO=DChwgU1p_Ag@mail.gmail.com>

I found the fastest way to open a sev 1 case is to open it online as sev 3,
that gets all the questions out of the way, then call the 800 number and
escalate to network down emergency. You then hold for the next available
engineer. I am pleased with the responsiveness of this approach.

d


On Wed, Sep 3, 2014 at 3:34 PM, Jon Garrison <bluegill at freeshell.org> wrote:

> On 3 Sep 2014, at 12:23, Jared Mauch wrote:
>
> >> On Sep 3, 2014, at 5:00 AM, Isaac Adams <isaacnanog at gmail.com> wrote:
> >>
> >> Hey Folks,
> >>
> >> I am trying to work out a strategy for vendor certification in our
> >> company.
> >> As a general rule, do you all fund employees certification and if so
> >> what
> >> kind of levels do you try to maintain as good practice?
> >>
> >> For example. NOC staff should be JNCIA and engineering JNCIP to
> >> JNCIE?
> >>
> >> Clearly certification does not usually reflect ability but it does
> >> help
> >> people feel valued and to maintain a basic level of competence.
> >
> > Cisco discriminates against customers without certification and delays
> > service and support to them as a result.  (e.g.: you can?t open a
> > sev 1 case online unless you are ?CCIE?).
>
> You can however just call them and yell "Environment Down" and they will
> call it whatever Sev you want. There are an unending number of issues
> with their online case opening "portal" however.
>
> Filling out a form online to wait a call back was never my first choice.
> Plus putting that Cisco hold music on speaker is a good way to improve
> the mood!
>
> > You likely want to have someone with this access in their account to
> > speed access when there are network critical issues.
> >
> > - Jared
>



-- 
Copyright 2014 Derek Andrew (excluding quotations)

+1 306 966 4808
Information and Communications Technology
University of Saskatchewan
Peterson 120; 54 Innovation Boulevard
Saskatoon,Saskatchewan,Canada. S7N 2V3
Timezone GMT-6

Typed but not read.


From bill at herrin.us  Wed Sep  3 21:56:51 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 3 Sep 2014 17:56:51 -0400
Subject: Vendor cert levels
In-Reply-To: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
Message-ID: <CAP-guGVmqxZoe_=OGpMU-L5mhDyt6ct3f3OSbC_H8_f302Cfbw@mail.gmail.com>

On Wed, Sep 3, 2014 at 5:00 AM, Isaac Adams <isaacnanog at gmail.com> wrote:
> I am trying to work out a strategy for vendor certification in our company.
> As a general rule, do you all fund employees certification and if so what
> kind of levels do you try to maintain as good practice?
>
> For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE?
>
> Clearly certification does not usually reflect ability but it does help
> people feel valued and to maintain a basic level of competence.

Hi Isaac,

Personally, I use certifications as more of a weed-out factor. List
lots of certifications on your resume? No interview for you.
Particularly that guy who used what should have been valuable space on
his resume to report having taken a 3-day certification course in
configuring Kentrox CSU/DSUs. Yikes!

Seriously though, certs stink of a cogs-in-the-machine approach to
business, which is the opposite of making folks feel individually
valued. Gee, I can tell from talking to you that you're smarter than
half our engineers but if you want to respond to the red lights in the
NOC you'll have to go get a CCNA.

If you want them to feel valued, give them an education reimbursement
program for any job-relevant training, college coursework, etc. Any
who want to spend it on certs, so be it. Any who want to spend it
professional conferences like NANOG, well, those are the ones you
keep.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From edward.dore at freethought-internet.co.uk  Thu Sep  4 07:09:58 2014
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Thu, 4 Sep 2014 08:09:58 +0100
Subject: Facebook down?
In-Reply-To: <44DDF028A1AFE9418C30E40EDC9B69DC53300394@MKPV-GRP-EXMBS1.ad.sis.tv>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>,
 <25BE7120-DCC8-43C5-8E5C-4C9560873B63@freethought-internet.co.uk>
 <44DDF028A1AFE9418C30E40EDC9B69DC53300394@MKPV-GRP-EXMBS1.ad.sis.tv>
Message-ID: <E38C31E7-751F-477E-A874-27A6E890427C@freethought-internet.co.uk>

Yep, completely out for me here. Couldn't even get as much as an error page most of the time, although I did briefly get a generic message saying "Sorry, something went wrong. We're working on getting this fixed as soon as we can".

I'm on Virgin Media cable for IPv4 and a SIXXS tunnel hosted by Goscomb in London for IPv6.

Multiple people in a UK techy IRC channel that I frequent were also reporting it as down at the time.

Edward Dore 
Freethought Internet 

On 3 Sep 2014, at 23:22, Rich Lewis <RLewis at sis.tv> wrote:

> Really? I'm in the UK too (London) and it was fine for me the whole time. I do have an IPv6 tunnel to HE though, so maybe it was fine on v6 and only down via v4??
> 
> 
> 
> From: Edward Dore
> Sent: ?03/?09/?2014 21:45
> To: Di Li
> Cc: nanog at nanog.org
> Subject: Re: Facebook down?
> 
> It wasn't loading here in the UK either, although it's back now.
> 
> Edward Dore 
> Freethought Internet 
> 
> On 3 Sep 2014, at 20:52, Di Li <di at egihosting.com> wrote:
> 
> > SJC too
> > 
> > 
> > On Wed, Sep 3, 2014 at 12:46 PM, aUser <auser at mind.net> wrote:
> > 
> >> Appears to be in Oregon, Southern Oregon.  Mobile too.
> >> 
> >> Sent from my iPhone 5S.
> >> 
> >>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
> >> marshall.eubanks at gmail.com> wrote:
> >>> 
> >>> This message has no content.
> >> 
> > 
> > 
> > 
> > -- 
> > Thanks,
> > Di
> 
> 
> 
> 
> Satellite Information Services Limited. Registered Office: Whitehall Avenue, Kingston, Milton Keynes, Buckinghamshire, MK10 0AX. Company No. 4243307
> 
> The information in this email (which includes any files transmitted with it) is confidential and is intended for the addressee only. Unauthorized recipients are required to maintain confidentiality. If you have received this email in error please notify the sender immediately, destroy any copies and delete it from your computer system.
> 
> 



From andy at nosignal.org  Thu Sep  4 07:26:11 2014
From: andy at nosignal.org (Andy Davidson)
Date: Thu, 4 Sep 2014 07:26:11 +0000
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <CAEmG1=rGU=zzTXo8CWFua_AAp7vQ9UbkfH4nZTOqSgBuy5s0zA@mail.gmail.com>
References: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com>
 <CAEmG1=rGU=zzTXo8CWFua_AAp7vQ9UbkfH4nZTOqSgBuy5s0zA@mail.gmail.com>
Message-ID: <5a83b430bb2648cc8293526389e4689f@AM3PR07MB0597.eurprd07.prod.outlook.com>

Hi,

Matthew Petach wrote:
> Be aware that even if you don't think you're peering with them 
> directly, you may be picking up routes via the public route 
> servers at exchange points, so check to see if you need to apply
> filters on your route server peerings as well.

At the risk of receiving 1,000 critical replies along the lines of "an internet exchange is not the routing police", I will point out that an IXP route-server is actually a really elegant place to do route filtering.  

The IXPs I help to maintain (LONAP & IXLeeds in the UK) do perform IRR filtering on the MLP route-servers.  This is handy in the scenario that the ISP is manually filtering customers, where such a technique scales badly when considering how to filter peers.  We're transparent and help customers fix route objects when they don't understand why an MLP peering is not effective.  If IRR wasn't a total crock, it'd be a really good system.


Saku Ytti wrote:
> Companies who are likely target for this, like MSFT and GOOG, 
> might want to monitor DFZ and see if they are receiving prefixes
> no one else is receiving.

The more eyes on the problem, the harder it is for these attacks to work, so the more likely targets (not specifically identifying the two companies in your example, there are lots of likely targets, many in the "Enterprise" space) who feed services like RIPE RIS or Routeviews, the easier it will be to learn what the attack vectors are and fight them.

Andy

From rsk at gsp.org  Thu Sep  4 09:17:11 2014
From: rsk at gsp.org (Rich Kulawiec)
Date: Thu, 4 Sep 2014 05:17:11 -0400
Subject: Vendor cert levels
In-Reply-To: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
Message-ID: <20140904091711.GB8568@gsp.org>

On Wed, Sep 03, 2014 at 10:00:17AM +0100, Isaac Adams wrote:
> As a general rule, do you all fund employees certification and if so what
> kind of levels do you try to maintain as good practice?

No and none.  I see value in competence, practice, experience, education
and the inevitable bitter lessons that we all must endure, but I don't
see any value in the vendor certification process except as "cash cow
for vendors".

---rsk


From woody at pch.net  Thu Sep  4 09:34:26 2014
From: woody at pch.net (Bill Woodcock)
Date: Thu, 4 Sep 2014 12:34:26 +0300
Subject: Vendor cert levels
In-Reply-To: <CAP-guGVmqxZoe_=OGpMU-L5mhDyt6ct3f3OSbC_H8_f302Cfbw@mail.gmail.com>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <CAP-guGVmqxZoe_=OGpMU-L5mhDyt6ct3f3OSbC_H8_f302Cfbw@mail.gmail.com>
Message-ID: <CF5EE5E2-A2F6-41C5-A546-2DC2073A3EF0@pch.net>


We got a resume once where the guy listed "2-day workshop on personal grooming, Karachi, Pakistan" under his "education" section. I think that trumps the Kentrox certification.  :-)

    
                -Bill


> On Sep 4, 2014, at 0:58, "William Herrin" <bill at herrin.us> wrote:
> 
>> On Wed, Sep 3, 2014 at 5:00 AM, Isaac Adams <isaacnanog at gmail.com> wrote:
>> I am trying to work out a strategy for vendor certification in our company.
>> As a general rule, do you all fund employees certification and if so what
>> kind of levels do you try to maintain as good practice?
>> 
>> For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE?
>> 
>> Clearly certification does not usually reflect ability but it does help
>> people feel valued and to maintain a basic level of competence.
> 
> Hi Isaac,
> 
> Personally, I use certifications as more of a weed-out factor. List
> lots of certifications on your resume? No interview for you.
> Particularly that guy who used what should have been valuable space on
> his resume to report having taken a 3-day certification course in
> configuring Kentrox CSU/DSUs. Yikes!
> 
> Seriously though, certs stink of a cogs-in-the-machine approach to
> business, which is the opposite of making folks feel individually
> valued. Gee, I can tell from talking to you that you're smarter than
> half our engineers but if you want to respond to the red lights in the
> NOC you'll have to go get a CCNA.
> 
> If you want them to feel valued, give them an education reimbursement
> program for any job-relevant training, college coursework, etc. Any
> who want to spend it on certs, so be it. Any who want to spend it
> professional conferences like NANOG, well, those are the ones you
> keep.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> Can I solve your unusual networking challenges?



From isaacnanog at gmail.com  Thu Sep  4 09:39:59 2014
From: isaacnanog at gmail.com (Isaac Adams)
Date: Thu, 4 Sep 2014 10:39:59 +0100
Subject: Vendor cert levels
In-Reply-To: <CF5EE5E2-A2F6-41C5-A546-2DC2073A3EF0@pch.net>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <CAP-guGVmqxZoe_=OGpMU-L5mhDyt6ct3f3OSbC_H8_f302Cfbw@mail.gmail.com>
 <CF5EE5E2-A2F6-41C5-A546-2DC2073A3EF0@pch.net>
Message-ID: <CAGFjxGasWe=7pqguDxSQD=2S_ou65ZOdx8p1AS6KfBSQitKCoA@mail.gmail.com>

In all seriousness, some people could do with that!


On Thu, Sep 4, 2014 at 10:34 AM, Bill Woodcock <woody at pch.net> wrote:

>
> We got a resume once where the guy listed "2-day workshop on personal
> grooming, Karachi, Pakistan" under his "education" section. I think that
> trumps the Kentrox certification.  :-)
>
>
>                 -Bill
>
>
> > On Sep 4, 2014, at 0:58, "William Herrin" <bill at herrin.us> wrote:
> >
> >> On Wed, Sep 3, 2014 at 5:00 AM, Isaac Adams <isaacnanog at gmail.com>
> wrote:
> >> I am trying to work out a strategy for vendor certification in our
> company.
> >> As a general rule, do you all fund employees certification and if so
> what
> >> kind of levels do you try to maintain as good practice?
> >>
> >> For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE?
> >>
> >> Clearly certification does not usually reflect ability but it does help
> >> people feel valued and to maintain a basic level of competence.
> >
> > Hi Isaac,
> >
> > Personally, I use certifications as more of a weed-out factor. List
> > lots of certifications on your resume? No interview for you.
> > Particularly that guy who used what should have been valuable space on
> > his resume to report having taken a 3-day certification course in
> > configuring Kentrox CSU/DSUs. Yikes!
> >
> > Seriously though, certs stink of a cogs-in-the-machine approach to
> > business, which is the opposite of making folks feel individually
> > valued. Gee, I can tell from talking to you that you're smarter than
> > half our engineers but if you want to respond to the red lights in the
> > NOC you'll have to go get a CCNA.
> >
> > If you want them to feel valued, give them an education reimbursement
> > program for any job-relevant training, college coursework, etc. Any
> > who want to spend it on certs, so be it. Any who want to spend it
> > professional conferences like NANOG, well, those are the ones you
> > keep.
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William Herrin ................ herrin at dirtside.com  bill at herrin.us
> > Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> > Can I solve your unusual networking challenges?
>
>


From eric.stoltz at neovera.com  Thu Sep  4 12:17:03 2014
From: eric.stoltz at neovera.com (Eric Stoltz)
Date: Thu, 04 Sep 2014 08:17:03 -0400
Subject: Vendor cert levels
In-Reply-To: <78D13690-764F-4397-8358-7F9BB8B8C6A7@freeshell.org>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
 <78D13690-764F-4397-8358-7F9BB8B8C6A7@freeshell.org>
Message-ID: <5408583F.1040304@neovera.com>

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

The technical term for that music is the "Cisco Disco"



On 09/03/2014 05:34 PM, Jon Garrison wrote:
> On 3 Sep 2014, at 12:23, Jared Mauch wrote:
> 
>>> On Sep 3, 2014, at 5:00 AM, Isaac Adams <isaacnanog at gmail.com>
>>> wrote:
>>> 
>>> Hey Folks,
>>> 
>>> I am trying to work out a strategy for vendor certification in
>>> our company. As a general rule, do you all fund employees
>>> certification and if so what kind of levels do you try to
>>> maintain as good practice?
>>> 
>>> For example. NOC staff should be JNCIA and engineering JNCIP to
>>> JNCIE?
>>> 
>>> Clearly certification does not usually reflect ability but it
>>> does help people feel valued and to maintain a basic level of
>>> competence.
>> 
>> Cisco discriminates against customers without certification and
>> delays service and support to them as a result.  (e.g.: you can?t
>> open a sev 1 case online unless you are ?CCIE?).
> 
> You can however just call them and yell "Environment Down" and they
> will call it whatever Sev you want. There are an unending number of
> issues with their online case opening "portal" however.
> 
> Filling out a form online to wait a call back was never my first
> choice. Plus putting that Cisco hold music on speaker is a good way
> to improve the mood!
> 
>> You likely want to have someone with this access in their account
>> to speed access when there are network critical issues.
>> 
>> - Jared
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUCFg+AAoJEBFPpLYBAeD1+MQIAMqj+WT/QQuyfLHNXWPy1qFB
OHvfyMf5CKRAsNhMO3Dh/i2PQ0gqxxsBxCkb6bQ1LjxeWGXB2jINEjrnFst2H5F4
MpVaU0AX+PX1dxc2qwldX6p5Ve4R5kNa64DeKBsgKSSnnYYMhSBU3fLXDkvWKqLC
LhIR5Zg3cGZwBTo5cCuJPZWHVt4zruMYuoIxrOgVQg28jOUWNgU81sFYCIWG7Fii
/C/eAeF9bpkczpJgAqD0d1lynFqpqPfOtns16QDV2dLzGmegSjF3eCiXqE8Eu5u7
Cf7pcRMHT1+KZdAnB75GoTLxdfS4LObh+cUo48e4+pCcIJIz0khLnIAhOGaYpEU=
=42vb
-----END PGP SIGNATURE-----


From amekkaoui at mektel.ca  Thu Sep  4 13:12:28 2014
From: amekkaoui at mektel.ca (A Mekkaoui)
Date: Thu, 4 Sep 2014 09:12:28 -0400
Subject: Cisco SFP
Message-ID: <002701cfc841$e1616680$a4243380$@ca>

Hi

 

Can you please provide me a contact of a vendor of SFP-GE-L Cisco SFP, I
need it today or tomorrow morning at the lasted.

 

Thank you 

 

A MEKKAOUI

MEKTEL INC

amekkaoui at mektel.ca

 



From eric.stoltz at neovera.com  Thu Sep  4 14:23:08 2014
From: eric.stoltz at neovera.com (Eric Stoltz)
Date: Thu, 04 Sep 2014 10:23:08 -0400
Subject: Vendor cert levels
In-Reply-To: <5408583F.1040304@neovera.com>
References: <CAGFjxGbq3H+1m8XpM29DuQ-+cBNaz=CiEA+9AVxF6i=ot3FMEA@mail.gmail.com>
 <D4D6BF93-E087-48FF-ABAB-30ADF30C452D@puck.nether.net>
 <78D13690-764F-4397-8358-7F9BB8B8C6A7@freeshell.org>
 <5408583F.1040304@neovera.com>
Message-ID: <540875CC.1010201@neovera.com>




The technical term for that music is the "Cisco Disco"




> On 09/03/2014 05:34 PM, Jon Garrison wrote:
>> On 3 Sep 2014, at 12:23, Jared Mauch wrote:
> 
>>>> On Sep 3, 2014, at 5:00 AM, Isaac Adams <isaacnanog at gmail.com>
>>>> wrote:
>>>>
>>>> Hey Folks,
>>>>
>>>> I am trying to work out a strategy for vendor certification in
>>>> our company. As a general rule, do you all fund employees
>>>> certification and if so what kind of levels do you try to
>>>> maintain as good practice?
>>>>
>>>> For example. NOC staff should be JNCIA and engineering JNCIP to
>>>> JNCIE?
>>>>
>>>> Clearly certification does not usually reflect ability but it
>>>> does help people feel valued and to maintain a basic level of
>>>> competence.
>>>
>>> Cisco discriminates against customers without certification and
>>> delays service and support to them as a result.  (e.g.: you can?t
>>> open a sev 1 case online unless you are ?CCIE?).
> 
>> You can however just call them and yell "Environment Down" and they
>> will call it whatever Sev you want. There are an unending number of
>> issues with their online case opening "portal" however.
> 
>> Filling out a form online to wait a call back was never my first
>> choice. Plus putting that Cisco hold music on speaker is a good way
>> to improve the mood!
> 
>>> You likely want to have someone with this access in their account
>>> to speed access when there are network critical issues.
>>>
>>> - Jared
> 


From mark at viviotech.net  Thu Sep  4 16:22:41 2014
From: mark at viviotech.net (Mark Keymer)
Date: Thu, 04 Sep 2014 09:22:41 -0700
Subject: More Godaddy DNS and whois server issues?
Message-ID: <540891D1.9020501@viviotech.net>

Hi,

So this started a little while ago but seems to be getting worse.

What I am seeing is dns servers over at godaddy not replying however I 
seem to be able to traceroute ok to them. Also I have started to see 
that the whois.godaddy.com servers also seem to be having issues as well 
with "Whois information is currently unavailable.  Please try again later."

Anyone else also seeing issues this morning? And able to confirm the 
issue is with godaddy?

Sincerely,

-- 
Mark Keymer



From steve at blighty.com  Thu Sep  4 16:55:43 2014
From: steve at blighty.com (Steve Atkins)
Date: Thu, 4 Sep 2014 09:55:43 -0700
Subject: More Godaddy DNS and whois server issues?
In-Reply-To: <540891D1.9020501@viviotech.net>
References: <540891D1.9020501@viviotech.net>
Message-ID: <369A982D-394A-4EC7-96C7-DC2542510C2F@blighty.com>


On Sep 4, 2014, at 9:22 AM, Mark Keymer <mark at viviotech.net> wrote:

> Hi,
> 
> So this started a little while ago but seems to be getting worse.
> 
> What I am seeing is dns servers over at godaddy not replying however I seem to be able to traceroute ok to them. Also I have started to see that the whois.godaddy.com servers also seem to be having issues as well with "Whois information is currently unavailable.  Please try again later."
> 
> Anyone else also seeing issues this morning? And able to confirm the issue is with godaddy?

I've seen reports of this for a week or so, with the symptoms looking like overly aggressive abuse / query rate handling - packets from networks containing busy resolvers being blocked.

Grapevine tells me that they don't think they're doing it intentionally (maybe they outsourced something and it broke?).

Cheers,
  Steve



From rob at invaluement.com  Thu Sep  4 17:35:43 2014
From: rob at invaluement.com (Rob McEwen)
Date: Thu, 04 Sep 2014 13:35:43 -0400
Subject: More Godaddy DNS and whois server issues?
In-Reply-To: <369A982D-394A-4EC7-96C7-DC2542510C2F@blighty.com>
References: <540891D1.9020501@viviotech.net>
 <369A982D-394A-4EC7-96C7-DC2542510C2F@blighty.com>
Message-ID: <5408A2EF.1050700@invaluement.com>

On 9/4/2014 12:55 PM, Steve Atkins wrote:
> On Sep 4, 2014, at 9:22 AM, Mark Keymer <mark at viviotech.net> wrote:
>
>> > Hi,
>> > 
>> > So this started a little while ago but seems to be getting worse.
>> > 
>> > What I am seeing is dns servers over at godaddy not replying however I seem to be able to traceroute ok to them. Also I have started to see that the whois.godaddy.com servers also seem to be having issues as well with "Whois information is currently unavailable.  Please try again later."
>> > 
>> > Anyone else also seeing issues this morning? And able to confirm the issue is with godaddy?
> I've seen reports of this for a week or so, with the symptoms looking like overly aggressive abuse / query rate handling - packets from networks containing busy resolvers being blocked.
>
> Grapevine tells me that they don't think they're doing it intentionally (maybe they outsourced something and it broke?).


a few hours ago... One of my MX gateway filtering clients (for the small
spam filtering portion of my business) was having trouble this morning
with their own users accessing webmail (hosted on their exchange
server), and I discovered that the "a" record was resolving from some
locations, but not from others.  The domain was using GoDaddy's
"domaincontrol.com" series of name servers. I thought that they might
have had wrong host names in their registrar records and I told my
client to contact Godaddy, verify that these were correct, and ask
Godaddy about possible timeout and/or "no answer" issues. I tried
querying the host name from one location (direct to Godaddy's DNS) and
I'd get an answer, then from another location (direct to Godaddy's DNS)
and I would get a seemingly endless timeout.

-- 
Rob McEwen
+1 (478) 475-9032



From RLewis at sis.tv  Wed Sep  3 22:22:58 2014
From: RLewis at sis.tv (Rich Lewis)
Date: Wed, 3 Sep 2014 22:22:58 +0000
Subject: Facebook down?
In-Reply-To: <25BE7120-DCC8-43C5-8E5C-4C9560873B63@freethought-internet.co.uk>
References: <CA1FC4BB-FEC2-46E8-B431-91C8AF6457A3@mind.net>
 <CAGjDqLxVac1C2f=21TasUhLRKVKfogZbjphr-COKyObpET4gVA@mail.gmail.com>,
 <25BE7120-DCC8-43C5-8E5C-4C9560873B63@freethought-internet.co.uk>
Message-ID: <44DDF028A1AFE9418C30E40EDC9B69DC53300394@MKPV-GRP-EXMBS1.ad.sis.tv>

Really? I'm in the UK too (London) and it was fine for me the whole time. I do have an IPv6 tunnel to HE though, so maybe it was fine on v6 and only down via v4??



________________________________
From: Edward Dore<mailto:edward.dore at freethought-internet.co.uk>
Sent: ?03/?09/?2014 21:45
To: Di Li<mailto:di at egihosting.com>
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: Facebook down?

It wasn't loading here in the UK either, although it's back now.

Edward Dore
Freethought Internet

On 3 Sep 2014, at 20:52, Di Li <di at egihosting.com> wrote:

> SJC too
>
>
> On Wed, Sep 3, 2014 at 12:46 PM, aUser <auser at mind.net> wrote:
>
>> Appears to be in Oregon, Southern Oregon.  Mobile too.
>>
>> Sent from my iPhone 5S.
>>
>>> On Sep 3, 2014, at 12:45 PM, Marshall Eubanks <
>> marshall.eubanks at gmail.com> wrote:
>>>
>>> This message has no content.
>>
>
>
>
> --
> Thanks,
> Di


**********************************************************************

Satellite Information Services Limited. Registered Office: Whitehall Avenue, Kingston, Milton Keynes, Buckinghamshire, MK10 0AX. Company No. 4243307 

The information in this email (which includes any files transmitted with it) is confidential and is intended for the addressee only. Unauthorized recipients are required to maintain confidentiality. If you have received this email in error please notify the sender immediately, destroy any copies and delete it from your computer system. 

**********************************************************************

From me at staticsafe.ca  Thu Sep  4 16:26:57 2014
From: me at staticsafe.ca (staticsafe)
Date: Thu, 04 Sep 2014 12:26:57 -0400
Subject: More Godaddy DNS and whois server issues?
In-Reply-To: <540891D1.9020501@viviotech.net>
References: <540891D1.9020501@viviotech.net>
Message-ID: <540892D1.9090904@staticsafe.ca>

On 9/4/2014 12:22, Mark Keymer wrote:
> Hi,
> 
> So this started a little while ago but seems to be getting worse.
> 
> What I am seeing is dns servers over at godaddy not replying however I
> seem to be able to traceroute ok to them. Also I have started to see
> that the whois.godaddy.com servers also seem to be having issues as well
> with "Whois information is currently unavailable.  Please try again later."
> 
> Anyone else also seeing issues this morning? And able to confirm the
> issue is with godaddy?
> 
> Sincerely,
> 

Do you have any particular NSes and/or domains we can test with?

-- 
staticsafe
https://staticsafe.ca


From feamster at cc.gatech.edu  Thu Sep  4 18:47:42 2014
From: feamster at cc.gatech.edu (Nick Feamster)
Date: Thu, 4 Sep 2014 14:47:42 -0400
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
References: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
Message-ID: <0C5A3013-ACCA-458E-A775-7F34938C284F@cc.gatech.edu>

Hi Doug, All,

We?ve seen similar things, including hijacks of less specific IP prefixes (even /8s), correlated with spam behavior.  

We presented on this at NANOG 35:
http://nanog.org/meetings/nanog36/presentations/feamster.pdf

Slide 4 shows a short-lived BGP announcement for IP space that was the source of spam.  Interestingly, many of the short-lived annoucements that we observed were /8s.  Subsequent slides explain why.  Subsequent slides explain these observations in more detail, and we had a paper in SIGCOMM?06 describing this activity in more detail:
http://www.cc.gatech.edu/~feamster/papers/p396-ramachandran.pdf

We have a couple of pieces of follow-up work:
- It turns out that you can use BGP dynamics as features to design filters for spam and other attack traffic (we have a couple of papers on this)
- Some of these observable dynamics are also useful for establishing AS reputation (a la Hostexploit) - we have some ongoing work here

Happy to talk more, either on-list or off-list.

Cheers,
-Nick

On Aug 31, 2014, at 2:04 PM, Doug Madory <dmadory at renesys.com> wrote:

> FWIW, this is from an IP squatting operation I came across in recent weeks. I encounter these things regularly in the course of working with BGP data - probably others do too. Usually I look up the ASN or prefix and often it has already been added to someone's spam source list. When I see that, I assume the "system is working" and move on.
> 
> In this case, starting late Jun, we have seen IP address ranges from around the world (most ranges are unused, sometimes hijacked space) announced by one of two (formerly unused) ASNs and routed through another formerly unused ASN, 57756, then on to Anders (AS39792) and out to the Internet in the following form:
> 
> 	... 39792 57756 {3.721, 43239}	prefix
> 
> The prefixes are only routed for an hour or two before it moves on to the next range of IP address space. Not sure if this is for spam or something else. Either way, it is probably associated with something bad. Earlier this month I reached out to a contact at Anders in Russia and gave him some details about what was happening. I didn't get a response, but within a couple of days the routing (mostly) shifted from Anders to through Petersburg Internet Network (AS44050). I have no idea if this was due to my email. The day it moved to PIN I sent similar emails to addresses I could find at PIN, but haven't seen any response. Now the these routes take one of two forms:
> 
> 	... 39792 57756 {3.721, 43239}	prefix
> 
> Or
> 
> 	... 44050 57756 {3.721, 43239}	prefix
> 
> This is mostly routed through Cogent (AS174), but Anders (AS39792) also has a lot of peers. I would advise that people treat any route coming through AS57756 is probably bad. AS57756 doesn't originate anything and hasn't since 28-Jun when it very briefly hijacked some NZ space.
> 
> Also, Pierre-Antoine Vervier from Symantec gave a good talk at NANOG in Feb about IP squatting for spam generation. Pierre and I have since compared notes on this topic.
> 
> -Doug Madory
> 
> ----- Original Message -----
>> From: "Tarun Dua" <lists at tarundua.net>
>> To: nanog at nanog.org
>> Sent: Thursday, August 28, 2014 12:55:25 PM
>> Subject: Prefix hijacking, how to prevent and fix currently
>> 
>> AS Number 43239
>> AS Name SPETSENERGO-AS SpetsEnergo Ltd.
>> 
>> Has started hijacking our IPv4 prefix, while this prefix was NOT in
>> production, it worries us that it was this easy for someone to hijack
>> it.
>> 
>> http://bgp.he.net/AS43239#_prefixes
>> 
>> 103.20.212.0/22 <- This belongs to us.
>> 
>> 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd.
>> 193.43.33.0/24 hydrocontrol S.C.R.L.
>> 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
>> 
>> Where do we complain to get this fixed.
>> 
>> -Tarun
>> AS132420
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140904/2466a4a6/attachment.sig>

From mark at viviotech.net  Fri Sep  5 02:10:47 2014
From: mark at viviotech.net (Mark Keymer)
Date: Thu, 04 Sep 2014 19:10:47 -0700
Subject: More Godaddy DNS and whois server issues?
In-Reply-To: <540892D1.9090904@staticsafe.ca>
References: <540891D1.9020501@viviotech.net> <540892D1.9090904@staticsafe.ca>
Message-ID: <54091BA7.50004@viviotech.net>

Hi,

They all came back later and are good now. But next time if it happens I 
will send some of the NS servers and domains.

Sincerely,

Mark


On 9/4/2014 9:26 AM, staticsafe wrote:
> On 9/4/2014 12:22, Mark Keymer wrote:
>> Hi,
>>
>> So this started a little while ago but seems to be getting worse.
>>
>> What I am seeing is dns servers over at godaddy not replying however I
>> seem to be able to traceroute ok to them. Also I have started to see
>> that the whois.godaddy.com servers also seem to be having issues as well
>> with "Whois information is currently unavailable.  Please try again later."
>>
>> Anyone else also seeing issues this morning? And able to confirm the
>> issue is with godaddy?
>>
>> Sincerely,
>>
> Do you have any particular NSes and/or domains we can test with?
>



From marka at isc.org  Fri Sep  5 02:26:59 2014
From: marka at isc.org (Mark Andrews)
Date: Fri, 05 Sep 2014 12:26:59 +1000
Subject: More Godaddy DNS and whois server issues?
In-Reply-To: Your message of "Thu, 04 Sep 2014 12:26:57 -0400."
 <540892D1.9090904@staticsafe.ca>
References: <540891D1.9020501@viviotech.net> <540892D1.9090904@staticsafe.ca>
Message-ID: <20140905022659.E4A911E77FCA@rock.dv.isc.org>


In message <540892D1.9090904 at staticsafe.ca>, staticsafe writes:
> On 9/4/2014 12:22, Mark Keymer wrote:
> > Hi,
> > 
> > So this started a little while ago but seems to be getting worse.
> > 
> > What I am seeing is dns servers over at godaddy not replying however I
> > seem to be able to traceroute ok to them. Also I have started to see
> > that the whois.godaddy.com servers also seem to be having issues as well
> > with "Whois information is currently unavailable.  Please try again later."
> > 
> > Anyone else also seeing issues this morning? And able to confirm the
> > issue is with godaddy?
> > 
> > Sincerely,
> > 
> 
> Do you have any particular NSes and/or domains we can test with?

The following nameservers for godaddy.com are currently down.  The
machines themselves are up as we can ping them.

godaddy.com. @2600:1403:a::43 (a8-67.akam.net.): dns=timeout edns=timeout edns1=timeout edns at 512=timeout ednsopt=timeout edns1opt=timeout
godaddy.com. @2a02:26f0:67::41 (a20-65.akam.net.): dns=timeout edns=timeout edns1=timeout edns at 512=timeout ednsopt=timeout edns1opt=timeout
godaddy.com. @2600:1401:1::42 (a6-66.akam.net.): dns=timeout edns=timeout edns1=timeout edns at 512=timeout ednsopt=timeout edns1opt=timeout

The above was from EDNS compliance testing I am doing.  The report
is regenerated daily.

http://users.isc.org/~marka/alexa-report.html

- 
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  Fri Sep  5 03:21:22 2014
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 4 Sep 2014 23:21:22 -0400 (EDT)
Subject: More Godaddy DNS and whois server issues?
In-Reply-To: <540891D1.9020501@viviotech.net>
Message-ID: <17762290.178.1409887282270.JavaMail.root@benjamin.baylink.com>

I have an ear to whisper in on this topic at GD. 

If you're still having trouble through today, Thursday, please reply 
on this thread (or, if you're on Outages@, preferably over on that thread),
with what, when, and how, and I will pass the hard data along.

If you've already posted details here, just confirm still a problem, and
I can harvest.

The majority of the trouble is layer 3 and above, as I understand it; 
ping/trace to the relevant servers is working on, generally?  If otherwise,
mention that as well, pse.

Cheers,
-- jra

----- Original Message -----
> From: "Mark Keymer" <mark at viviotech.net>
> To: nanog at nanog.org
> Sent: Thursday, September 4, 2014 12:22:41 PM
> Subject: More Godaddy DNS and whois server issues?
> Hi,
> 
> So this started a little while ago but seems to be getting worse.
> 
> What I am seeing is dns servers over at godaddy not replying however I
> seem to be able to traceroute ok to them. Also I have started to see
> that the whois.godaddy.com servers also seem to be having issues as
> well
> with "Whois information is currently unavailable. Please try again
> later."
> 
> Anyone else also seeing issues this morning? And able to confirm the
> issue is with godaddy?
> 
> Sincerely,
> 
> --
> Mark Keymer

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From mehmet at akcin.net  Fri Sep  5 09:57:04 2014
From: mehmet at akcin.net (Mehmet Akcin)
Date: Fri, 5 Sep 2014 02:57:04 -0700
Subject: TPF 1 - Istanbul, TR
Message-ID: <CA+LTh5Wi+=K82A4TTK9kaRNWzhjp095q=DTHrT6QDoPqgz9P8Q@mail.gmail.com>

NANOG Friends,

There have been several exciting developments in order to kick start a
major Internet Exchange Point in Turkey in past months.

We are , several peering enthusiasts , organizing Turkish Peering Forum in
Istanbul, September 29 , 2014.

More details can be found about the event at below link

http://trnog.org/tpf

We are currently also looking for people who are experienced in operating
IXPs in Developing regions to come speak about their experiences in a Panel
which will take place during this event.

The event will have many guests who are decision making people from Turkish
ISPs, Universities, Banks, and Govt Agencies.

Please go ahead and sign up for the event if you are planning to attend and
ping me directly off-list if you have any questions.

Mehmet


From koalafil at gmail.com  Fri Sep  5 14:06:08 2014
From: koalafil at gmail.com (Filiz Yilmaz)
Date: Fri, 5 Sep 2014 16:06:08 +0200
Subject: Call for Presentations RIPE 69
In-Reply-To: <CAHWoQeP5Br_Lk5LRKj4nQR-Wzb3P90y1_w4wrdjhotW7D=0zGA@mail.gmail.com>
References: <CAHWoQeP5Br_Lk5LRKj4nQR-Wzb3P90y1_w4wrdjhotW7D=0zGA@mail.gmail.com>
Message-ID: <CAHWoQeNanAiWEo7mu_2KP9F8pP1gU+st4uKr7QnggnHgeGJaQQ@mail.gmail.com>

Dear colleagues,

Following the past submission deadline here is an update from the RIPE PC:

A list of currently accepted RIPE 69 presentations will be published next
week and a separate note will be sent to the ripe-list once this is out.

There are still slots remaining for the final RIPE 69 programme and RIPE
Programme Committee will accept new proposals until 1 October 2014.

This is a last call deadline if you wish to submit a proposal.

Kind regards

Filiz Yilmaz
RIPE PC Chair





On Wed, Jun 11, 2014 at 5:48 PM, Filiz Yilmaz <koalafil at gmail.com> wrote:

> Dear colleagues,
>
> Please find the CFP for RIPE 69 in London below.
>
> The deadline for submissions is 31 August 2014.
>
> Please also note that speakers do not receive any extra reduction or
> funding towards the meeting fee at the RIPE Meetings.
>
> Kind regards
>
> Filiz Yilmaz
> RIPE PC Chair
> http://www.ripe.net/ripe/meetings/ripe-meetings/pc
>
>
> ---------------------
>
> Call for Presentations
>
> 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 69 will take place from 3- November 2014 in London, UK.
>
> The RIPE Programme Committee (PC) is now seeking content proposals from
> the RIPE community for the plenary session presentations, BoFs (Birds of a
> Feather sessions), panels, workshops, tutorials and lightning talks at RIPE
> 69. 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 centre technologies
> ? Network and DNS operations
> ? Internet governance and regulatory practices
>  ? Network and routing security
> ? Content delivery
> ? Internet peering and mobile data exchange
>
> Submissions
>
> RIPE Meeting attendees 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.
>
> The RIPE PC accepts proposals for different presentation formats,
> including plenary session presentations, tutorials, workshops, BoFs (Birds
> of a Feather sessions) and lightning talks. See the full descriptions of
> these formats at
> https://ripe69.ripe.net/submit-topic/presentation-formats/
>
> 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 general requirements apply:
>
> - Proposals for plenary session presentations, BoFs, panels, workshops and
> tutorials must be submitted for full consideration no later than 31 August
> 2014, using the meeting submission system at
> https://ripe69.ripe.net/submit-topic/guidelines/. Proposals submitted
> after this date will be considered on a space-available basis.
>
> -  Lightning talks should also be submitted using the meeting submission
> system (https://ripe69.ripe.net/submit-topic/submission-form/) and can be
> submitted just days before the RIPE Meeting starts or even during the
> meeting week. The allocation of lightning talk slots will be announced in
> short notice ? in some cases on the same day but often one day prior to the
> relevant session.
>
> - Presenters should indicate how much time they will require.
> See more information on time slot allocations per presentation format at
> https://ripe69.ripe.net/submit-topic/presentation-formats/
>
> - 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
> panels, proposals must contain a clear description, as well as the names of
> invited panelists, presenters and moderators.
>
> - Due to potential technical issues, it is expected that most, if not all,
> presenters/panelists will be physically present at the RIPE Meeting.
>
> If you have any questions or requests concerning content submissions,
> please email pc [at] ripe [dot] net.
>
> ---------------------
>


From jra at baylink.com  Fri Sep  5 14:16:00 2014
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 5 Sep 2014 10:16:00 -0400 (EDT)
Subject: The Next Big Thing: Named-Data Networking
Message-ID: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>

How many Youtube subject tags will fit in *your* routers' TCAM?

  http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip

[ Can someone convince me this isn't the biggest troll in the history 
of the internet? Cause it sounds like shoehorning DNS /and Google/ into 
IP in place of, y'know, IP addresses. ]

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From fergdawgster at mykolab.com  Fri Sep  5 14:27:18 2014
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Fri, 05 Sep 2014 07:27:18 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
Message-ID: <5409C846.3020307@mykolab.com>

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

On 9/5/2014 7:16 AM, Jay Ashworth wrote:

> How many Youtube subject tags will fit in *your* routers' TCAM?
> 
> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
>
>  [ Can someone convince me this isn't the biggest troll in the
> history of the internet? Cause it sounds like shoehorning DNS /and
> Google/ into IP in place of, y'know, IP addresses. ]
> 

I didn't read it that way exactly, especially in light of this not in
the Wikipedia article:

"Application-layer designs have also been proposed for deploying a
content-centric interface. This has benefits such as easier
deployment, backwards compatibility and more flexible delivery support."

https://en.wikipedia.org/wiki/Named_data_networking

It's an interesting concept, but it ain't gonna replace TCP/IP, DNS,
or IP addresses anytime soon. :-)

- - ferg

- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQJyEYACgkQKJasdVTchbIF0QD9FFwhgIKz7ssn9olaQHhIO6rO
8JzN5RZoF1itLe4LSgEBANvgyc8qbZp5QhsTQBLxpPpoLF0JVLsgzbEs3xCqgQ76
=kUKE
-----END PGP SIGNATURE-----


From jra at baylink.com  Fri Sep  5 14:35:48 2014
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 05 Sep 2014 10:35:48 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <5409C846.3020307@mykolab.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
Message-ID: <522cbbf4-2d84-404f-808f-bb5889daf898@email.android.com>

"Interface" sure.

But the dangers of replacing actual /addresses/ with things which are not is sufficiently well understood that even Van Jacobson ought to know about 'em, right?  :-)

On September 5, 2014 10:27:18 AM EDT, Paul Ferguson <fergdawgster at mykolab.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>On 9/5/2014 7:16 AM, Jay Ashworth wrote:
>
>> How many Youtube subject tags will fit in *your* routers' TCAM?
>> 
>>
>http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
>>
>>  [ Can someone convince me this isn't the biggest troll in the
>> history of the internet? Cause it sounds like shoehorning DNS /and
>> Google/ into IP in place of, y'know, IP addresses. ]
>> 
>
>I didn't read it that way exactly, especially in light of this not in
>the Wikipedia article:
>
>"Application-layer designs have also been proposed for deploying a
>content-centric interface. This has benefits such as easier
>deployment, backwards compatibility and more flexible delivery
>support."
>
>https://en.wikipedia.org/wiki/Named_data_networking
>
>It's an interesting concept, but it ain't gonna replace TCP/IP, DNS,
>or IP addresses anytime soon. :-)
>
>- - ferg
>
>- -- 
>Paul Ferguson
>VP Threat Intelligence, IID
>PGP Public Key ID: 0x54DC85B2
>Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2.0.22 (MingW32)
>
>iF4EAREIAAYFAlQJyEYACgkQKJasdVTchbIF0QD9FFwhgIKz7ssn9olaQHhIO6rO
>8JzN5RZoF1itLe4LSgEBANvgyc8qbZp5QhsTQBLxpPpoLF0JVLsgzbEs3xCqgQ76
>=kUKE
>-----END PGP SIGNATURE-----

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From fergdawgster at mykolab.com  Fri Sep  5 14:40:08 2014
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Fri, 05 Sep 2014 07:40:08 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <522cbbf4-2d84-404f-808f-bb5889daf898@email.android.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <522cbbf4-2d84-404f-808f-bb5889daf898@email.android.com>
Message-ID: <5409CB48.4080404@mykolab.com>

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

On 9/5/2014 7:35 AM, Jay Ashworth wrote:

> "Interface" sure.
> 
> But the dangers of replacing actual /addresses/ with things which
> are not is sufficiently well understood that even Van Jacobson
> ought to know about 'em, right? :-)
> 

Compare & contrast: There is still large-scale resistance (for lack of
a better term) to IPv6 deployment, so what chance does deployment of
Named Data-Networking stand? :-)

- - ferg


> On September 5, 2014 10:27:18 AM EDT, Paul Ferguson 
> <fergdawgster at mykolab.com> wrote:
> 
> On 9/5/2014 7:16 AM, Jay Ashworth wrote:
> 
> How many Youtube subject tags will fit in *your* routers' TCAM?
> 
> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
>
>  [ Can someone convince me this isn't the biggest troll in the 
> history of the internet? Cause it sounds like shoehorning DNS /and 
> Google/ into IP in place of, y'know, IP addresses. ]
> 
> 
> I didn't read it that way exactly, especially in light of this not
> in the Wikipedia article:
> 
> "Application-layer designs have also been proposed for deploying a 
> content-centric interface. This has benefits such as easier 
> deployment, backwards compatibility and more flexible delivery
> support."
> 
> https://en.wikipedia.org/wiki/Named_data_networking
> 
> It's an interesting concept, but it ain't gonna replace TCP/IP,
> DNS, or IP addresses anytime soon. :-)
> 
> - ferg
> 
> 
> 
> -- Sent from my Android phone with K-9 Mail. Please excuse my
> brevity.

- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQJy0gACgkQKJasdVTchbIVGQEAmPM5XTV9er8vtivwsPncz8x4
rDxyKiXDvD08CeqRN/cBANKT4Da86IryizcPp7UTknguI6N3yrAdBYYhmzVInZH8
=wVf9
-----END PGP SIGNATURE-----


From jschiel at flowtools.net  Fri Sep  5 14:47:23 2014
From: jschiel at flowtools.net (me)
Date: Fri, 05 Sep 2014 08:47:23 -0600
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <5409CB48.4080404@mykolab.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <522cbbf4-2d84-404f-808f-bb5889daf898@email.android.com>
 <5409CB48.4080404@mykolab.com>
Message-ID: <5409CCFB.9070809@flowtools.net>


On 09/05/2014 08:40 AM, Paul Ferguson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 9/5/2014 7:35 AM, Jay Ashworth wrote:
>
>> "Interface" sure.
>>
>> But the dangers of replacing actual /addresses/ with things which
>> are not is sufficiently well understood that even Van Jacobson
>> ought to know about 'em, right? :-)
>>
> Compare & contrast: There is still large-scale resistance (for lack of
> a better term) to IPv6 deployment, so what chance does deployment of
> Named Data-Networking stand? :-)
>
> - - ferg
>

This idea needs more simmer time.

https://en.wikipedia.org/wiki/Named_data_networking

" Juno also introduces the concept of a delivery-centric interface, 
which extends the traditional content-centric interface to allow 
applications to stipulate multiple diverse delivery requirements that 
place certain constraints on how the content should be provided. For 
instance, these constraints can deal with such things as performance, 
resilience, security, monetary cost and anonymity."

Almost sounds like the perfect protocol to allow the combination 
Internet/content provider to keep all content coming from where they 
want the content to come from instead of the freedom to choose where the 
content comes from.

--John Schiel

>> On September 5, 2014 10:27:18 AM EDT, Paul Ferguson
>> <fergdawgster at mykolab.com> wrote:
>>
>> On 9/5/2014 7:16 AM, Jay Ashworth wrote:
>>
>> How many Youtube subject tags will fit in *your* routers' TCAM?
>>
>> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
>>
>>   [ Can someone convince me this isn't the biggest troll in the
>> history of the internet? Cause it sounds like shoehorning DNS /and
>> Google/ into IP in place of, y'know, IP addresses. ]
>>
>>
>> I didn't read it that way exactly, especially in light of this not
>> in the Wikipedia article:
>>
>> "Application-layer designs have also been proposed for deploying a
>> content-centric interface. This has benefits such as easier
>> deployment, backwards compatibility and more flexible delivery
>> support."
>>
>> https://en.wikipedia.org/wiki/Named_data_networking
>>
>> It's an interesting concept, but it ain't gonna replace TCP/IP,
>> DNS, or IP addresses anytime soon. :-)
>>
>> - ferg
>>
>>
>>
>> -- Sent from my Android phone with K-9 Mail. Please excuse my
>> brevity.
> - -- 
> Paul Ferguson
> VP Threat Intelligence, IID
> PGP Public Key ID: 0x54DC85B2
> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iF4EAREIAAYFAlQJy0gACgkQKJasdVTchbIVGQEAmPM5XTV9er8vtivwsPncz8x4
> rDxyKiXDvD08CeqRN/cBANKT4Da86IryizcPp7UTknguI6N3yrAdBYYhmzVInZH8
> =wVf9
> -----END PGP SIGNATURE-----



From Gary.Dunaway at teamhgs.com  Fri Sep  5 14:58:41 2014
From: Gary.Dunaway at teamhgs.com (Gary Dunaway)
Date: Fri, 5 Sep 2014 14:58:41 +0000
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <5409C846.3020307@mykolab.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
Message-ID: <1B2337429310304A8483E6ECE293371EE5BA8564@PHMNEXCHMBS-01.HTMT.SOFT.NET>



>> How many Youtube subject tags will fit in *your* routers' TCAM?
>> 
>> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch
>> -consortium-to-replace-tcpip
>>
>>  [ Can someone convince me this isn't the biggest troll in the history 
>> of the internet? Cause it sounds like shoehorning DNS /and Google/ 
>> into IP in place of, y'know, IP addresses. ]
>> 

>I didn't read it that way exactly, especially in light of this not in the Wikipedia article:
>
>"Application-layer designs have also been proposed for deploying a content-centric interface. This has benefits such as easier deployment, backwards compatibility >and more flexible delivery support."
>
>https://en.wikipedia.org/wiki/Named_data_networking
>
>It's an interesting concept, but it ain't gonna replace TCP/IP, DNS, or IP addresses anytime soon. :-)
>
>- - ferg


Given how long the process has been to go from IPv4 to IPv6, I would imagine something like this taking much longer to take root and spread out to the masses. It is a curious concept though and the papers written on the consortium site may be work a quick read.

-gary
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _

Please make note of our new e-mail domain name: TEAMHGS.COM. 
Request you to update your address book accordingly.

Confidentiality Notice:
The information contained in this electronic message and any attachments to this message are 
intended for the exclusive use of the addressee(s) and may contain confidential or privileged 
information. If you are not the intended recipient, please notify the sender at 
Hinduja Global Solutions or postmaster at teamhgs.com immediately and destroy all copies of 
this message and any attachments.

9284f6a0-bf16-11e3-b1b6-0800200c9a66

From saku at ytti.fi  Fri Sep  5 15:25:51 2014
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 5 Sep 2014 18:25:51 +0300
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <1B2337429310304A8483E6ECE293371EE5BA8564@PHMNEXCHMBS-01.HTMT.SOFT.NET>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <1B2337429310304A8483E6ECE293371EE5BA8564@PHMNEXCHMBS-01.HTMT.SOFT.NET>
Message-ID: <20140905152551.GA18967@pob.ytti.fi>

On (2014-09-05 14:58 +0000), Gary Dunaway wrote:

> Given how long the process has been to go from IPv4 to IPv6, I would imagine something like this taking much longer to take root and spread out to the masses. It is a curious concept though and the papers written on the consortium site may be work a quick read.

I don't think IPv4 to IPv6 is taking long because it's technically difficult,
it is taking long time because it's hard to justify it commercially, no one is
paying you premium to get it, because it does not provide anything your
customers want.

We could probably deploy completely new protocol stack in 5 years, if there
was business incentive, if customers would switch to you from current
provider, if you are providing this.

Having said that I skimmed through NDN and it seems like
yet-another-flow-forwarding-concept. I quickly lose interest when I run into
proposal where state does not end after reading header. Having all these
states sitting in FIB does not seem anywhere near plausible even with moore's
law hand waving.

I'm sure better than IP is possible, but I can't tell what it is. I think IP
addresses are more relevant today than they should be. We already do rely on
doing 2 lookups, IP (infrastructure) and DNS (dictionary/service), and IP
addresses probably can be made completely uninteresting low-level detail by
looking how to revamp host's dictionary lookup, adding complexity there has
very little impact on scaling.


-- 
  ++ytti


From bill at herrin.us  Fri Sep  5 15:34:16 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Sep 2014 11:34:16 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP-guGWtNww90jcBjUWKk34H6EtZXUvxBPr41=J4Xj3YKNqAEQ@mail.gmail.com>

On Fri, Sep 5, 2014 at 10:16 AM, Jay Ashworth <jra at baylink.com> wrote:
>   http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
>
> Can someone convince me this isn't the biggest troll in the history
> of the internet?

Not me. The description of the thing wanders inscrutably from a sort
of generalized distributed content caching (which is a great idea
readily buildable without any change in paradigm whatsoever) to stuff
that is vaguely reminiscent of the John Day BS which despite all
reason manages to suck in yet another networking researcher from time
to time.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?


From dmadory at renesys.com  Fri Sep  5 16:12:48 2014
From: dmadory at renesys.com (Doug Madory)
Date: Fri, 5 Sep 2014 12:12:48 -0400
Subject: Prefix hijacking, how to prevent and fix currently
In-Reply-To: <0C5A3013-ACCA-458E-A775-7F34938C284F@cc.gatech.edu>
References: <F1879621-EC26-4787-AB9F-B9B585F3E05D@renesys.com>
 <0C5A3013-ACCA-458E-A775-7F34938C284F@cc.gatech.edu>
Message-ID: <6496BCDC-225D-428D-8481-EC38D7FC9FBB@renesys.com>

Hi Nick, All,

Thanks for the links. I'm glad to know people are working on this. I don't think anyone was suggesting that this was a new phenomenon. 

Someone wrote to this list about a particular incident and I shared details about how this was part of a larger IP squatting operation. Unique from other on-going IP squatting incidents that I'm aware of, this one was rather unique in its use of two unused ASNs to quickly cycle through various prefixes of (mostly) unused address space.

http://seclists.org/nanog/2014/Aug/513	(Aug 31)

It was disappointing to see someone claim the discovery of this IP squatting operation three days later without a reference to my detailed write-up in this public forum. This had been going for months, but only after I explained what had happened could this "discovery" take place.

http://www.bgpmon.net/using-bgp-data-to-find-spammers/	(Sep 3)

What is most interesting is that shortly before I wrote my email, the IP squatting operation had changed tactics. Although there are still some stale routes in circulation, the "57756 {43239, {3.721}" format is no longer the format being used. 

Since Saturday, the IP squatting operation has moved to the following route format:

	... 44050 197598 {49121, 197794}	prefix

By the time of Andree's blog post on Wednesday, this new route format had been the main tactic for four days. He didn't pick up on the change - perhaps because I hadn't caught the change by the time I wrote my email this weekend. Maybe he can "discover" it now.

BTW, these routes are being universally accepted, so whatever technique we think we're employing to filter routes like this, it isn't working. 

Doug Madory
603-643-9300 x115
Hanover, NH
"The Internet Intelligence Authority"

On Sep 4, 2014, at 2:47 PM, Nick Feamster <feamster at cc.gatech.edu> wrote:

> Hi Doug, All,
> 
> We?ve seen similar things, including hijacks of less specific IP prefixes (even /8s), correlated with spam behavior.  
> 
> We presented on this at NANOG 35:
> http://nanog.org/meetings/nanog36/presentations/feamster.pdf
> 
> Slide 4 shows a short-lived BGP announcement for IP space that was the source of spam.  Interestingly, many of the short-lived annoucements that we observed were /8s.  Subsequent slides explain why.  Subsequent slides explain these observations in more detail, and we had a paper in SIGCOMM?06 describing this activity in more detail:
> http://www.cc.gatech.edu/~feamster/papers/p396-ramachandran.pdf
> 
> We have a couple of pieces of follow-up work:
> - It turns out that you can use BGP dynamics as features to design filters for spam and other attack traffic (we have a couple of papers on this)
> - Some of these observable dynamics are also useful for establishing AS reputation (a la Hostexploit) - we have some ongoing work here
> 
> Happy to talk more, either on-list or off-list.
> 
> Cheers,
> -Nick
> 
> On Aug 31, 2014, at 2:04 PM, Doug Madory <dmadory at renesys.com> wrote:
> 
>> FWIW, this is from an IP squatting operation I came across in recent weeks. I encounter these things regularly in the course of working with BGP data - probably others do too. Usually I look up the ASN or prefix and often it has already been added to someone's spam source list. When I see that, I assume the "system is working" and move on.
>> 
>> In this case, starting late Jun, we have seen IP address ranges from around the world (most ranges are unused, sometimes hijacked space) announced by one of two (formerly unused) ASNs and routed through another formerly unused ASN, 57756, then on to Anders (AS39792) and out to the Internet in the following form:
>> 
>> 	... 39792 57756 {3.721, 43239}	prefix
>> 
>> The prefixes are only routed for an hour or two before it moves on to the next range of IP address space. Not sure if this is for spam or something else. Either way, it is probably associated with something bad. Earlier this month I reached out to a contact at Anders in Russia and gave him some details about what was happening. I didn't get a response, but within a couple of days the routing (mostly) shifted from Anders to through Petersburg Internet Network (AS44050). I have no idea if this was due to my email. The day it moved to PIN I sent similar emails to addresses I could find at PIN, but haven't seen any response. Now the these routes take one of two forms:
>> 
>> 	... 39792 57756 {3.721, 43239}	prefix
>> 
>> Or
>> 
>> 	... 44050 57756 {3.721, 43239}	prefix
>> 
>> This is mostly routed through Cogent (AS174), but Anders (AS39792) also has a lot of peers. I would advise that people treat any route coming through AS57756 is probably bad. AS57756 doesn't originate anything and hasn't since 28-Jun when it very briefly hijacked some NZ space.
>> 
>> Also, Pierre-Antoine Vervier from Symantec gave a good talk at NANOG in Feb about IP squatting for spam generation. Pierre and I have since compared notes on this topic.
>> 
>> -Doug Madory
>> 
>> ----- Original Message -----
>>> From: "Tarun Dua" <lists at tarundua.net>
>>> To: nanog at nanog.org
>>> Sent: Thursday, August 28, 2014 12:55:25 PM
>>> Subject: Prefix hijacking, how to prevent and fix currently
>>> 
>>> AS Number 43239
>>> AS Name SPETSENERGO-AS SpetsEnergo Ltd.
>>> 
>>> Has started hijacking our IPv4 prefix, while this prefix was NOT in
>>> production, it worries us that it was this easy for someone to hijack
>>> it.
>>> 
>>> http://bgp.he.net/AS43239#_prefixes
>>> 
>>> 103.20.212.0/22 <- This belongs to us.
>>> 
>>> 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd.
>>> 193.43.33.0/24 hydrocontrol S.C.R.L.
>>> 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
>>> 
>>> Where do we complain to get this fixed.
>>> 
>>> -Tarun
>>> AS132420
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140905/f119780f/attachment.sig>

From jtk at cymru.com  Fri Sep  5 16:37:38 2014
From: jtk at cymru.com (John Kristoff)
Date: Fri, 5 Sep 2014 11:37:38 -0500
Subject: Security Track @ NANOG 62 Call for Participation
Message-ID: <20140905113738.1f94168f@localhost>

Friends, colleagues, fellow operators,

The network security track, formerly known as the ISP security BoF,
will be on the agenda at NANOG 62 in Baltimore and I will be the track
facilitator.  My good friend Krassimir (Krassi) Tzvetanov many of you
may know, has also agreed to help coordinate.

We not only seek your participation, but we are also interested you
contributing to the track content.  If there is something or if you know
someone who might like to present, discuss or conduct a demonstration
of, we want to hear from you.  Here is an incomplete list of ideas to
stir your thoughts:

  * BGPSEC and RPKI update or deployments
  * Route leak/hijack monitoring and mitigation
  * Mobile issues
  * IPv6 security concerns or case studies
  * DDoS mitigation experience and case studies
  * Customer support and management practices
  * Control plane best practices and templates
  * Embedded device problems and protections
  * Government regulatory, compliance and privacy issues
  * Walled garden techniques
  * Malware analysis
  * MPLS and VLAN security issues
  * VM and cloud security challenges
  * OpenFlow/SDN security considerations
  * <insert your new cool tool or idea here>

Note, this track is not streamed nor recorded.

If you want your PGP key signed by me (or anyone else), you should
upload it before arriving to this page to we have a record of it before
meeting in person.

  <http://biglumber.com/x/web?keyring=9191>

John


From cscora at apnic.net  Fri Sep  5 18:13:20 2014
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 6 Sep 2014 04:13:20 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201409051813.s85IDKFb026770@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 06 Sep, 2014

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              510100
    Prefixes after maximum aggregation:                          198112
    Deaggregation factor:                                          2.57
    Unique aggregates announced to Internet:                     250288
Total ASes present in the Internet Routing Table:                 47620
    Prefixes per ASN:                                             10.71
Origin-only ASes present in the Internet Routing Table:           36120
Origin ASes announcing only one prefix:                           16393
Transit ASes present in the Internet Routing Table:                6143
Transit-only ASes present in the Internet Routing Table:            175
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      40
    Max AS path prepend of ASN ( 55644)                              33
Prefixes from unregistered ASNs in the Routing Table:              1717
    Unregistered ASNs in the Routing Table:                         447
Number of 32-bit ASNs allocated by the RIRs:                       7325
Number of 32-bit ASNs visible in the Routing Table:                5357
Prefixes from 32-bit ASNs in the Routing Table:                   19764
Number of bogon 32-bit ASNs visible in the Routing Table:           637
Special use prefixes present in the Routing Table:                   13
Prefixes being announced from unallocated address space:            359
Number of addresses announced to Internet:                   2709663044
    Equivalent to 161 /8s, 130 /16s and 45 /24s
    Percentage of available address space announced:               73.2
    Percentage of allocated address space announced:               73.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               96.8
Total number of prefixes smaller than registry allocations:      175164

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   124791
    Total APNIC prefixes after maximum aggregation:               36480
    APNIC Deaggregation factor:                                    3.42
Prefixes being announced from the APNIC address blocks:          128407
    Unique aggregates announced from the APNIC address blocks:    52594
APNIC Region origin ASes present in the Internet Routing Table:    4976
    APNIC Prefixes per ASN:                                       25.81
APNIC Region origin ASes announcing only one prefix:               1222
APNIC Region transit ASes present in the Internet Routing Table:    866
Average APNIC Region AS path length visible:                        4.8
    Max APNIC Region AS path length visible:                         40
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1085
Number of APNIC addresses announced to Internet:              735584832
    Equivalent to 43 /8s, 216 /16s and 34 /24s
    Percentage of available APNIC address space announced:         86.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, 63488-64098, 131072-135580
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, 150/8, 153/8,
                       163/8, 171/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:                    169824
    Total ARIN prefixes after maximum aggregation:                85082
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           171838
    Unique aggregates announced from the ARIN address blocks:     80213
ARIN Region origin ASes present in the Internet Routing Table:    16357
    ARIN Prefixes per ASN:                                        10.51
ARIN Region origin ASes announcing only one prefix:                6122
ARIN Region transit ASes present in the Internet Routing Table:    1694
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:     180
Number of ARIN addresses announced to Internet:              1084222720
    Equivalent to 64 /8s, 159 /16s and 237 /24s
    Percentage of available ARIN address space announced:          57.4

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, 62464-63487, 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, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/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:                    125056
    Total RIPE prefixes after maximum aggregation:                63097
    RIPE Deaggregation factor:                                     1.98
Prefixes being announced from the RIPE address blocks:           129909
    Unique aggregates announced from the RIPE address blocks:     82260
RIPE Region origin ASes present in the Internet Routing Table:    17711
    RIPE Prefixes per ASN:                                         7.33
RIPE Region origin ASes announcing only one prefix:                8212
RIPE Region transit ASes present in the Internet Routing Table:    2886
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          32
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2738
Number of RIPE addresses announced to Internet:               659140996
    Equivalent to 39 /8s, 73 /16s and 177 /24s
    Percentage of available RIPE address space announced:          95.8

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
                       59392-61439, 61952-62463, 196608-202239
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,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   59494
    Total LACNIC prefixes after maximum aggregation:              10628
    LACNIC Deaggregation factor:                                   5.60
Prefixes being announced from the LACNIC address blocks:          67699
    Unique aggregates announced from the LACNIC address blocks:   30217
LACNIC Region origin ASes present in the Internet Routing Table:   2277
    LACNIC Prefixes per ASN:                                      29.73
LACNIC Region origin ASes announcing only one prefix:               617
LACNIC Region transit ASes present in the Internet Routing Table:   457
Average LACNIC Region AS path length visible:                       4.6
    Max LACNIC Region AS path length visible:                        23
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1301
Number of LACNIC addresses announced to Internet:             169647488
    Equivalent to 10 /8s, 28 /16s and 157 /24s
    Percentage of available LACNIC address space announced:       101.1

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  11080
    Total AfriNIC prefixes after maximum aggregation:              2783
    AfriNIC Deaggregation factor:                                  3.98
Prefixes being announced from the AfriNIC address blocks:         11888
    Unique aggregates announced from the AfriNIC address blocks:   4690
AfriNIC Region origin ASes present in the Internet Routing Table:   738
    AfriNIC Prefixes per ASN:                                     16.11
AfriNIC Region origin ASes announcing only one prefix:              220
AfriNIC Region transit ASes present in the Internet Routing Table:  160
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       28
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:   53
Number of AfriNIC addresses announced to Internet:             58374400
    Equivalent to 3 /8s, 122 /16s and 185 /24s
    Percentage of available AfriNIC address space announced:       58.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2933      11591         922   Korea Telecom
17974     2808        900          74   PT Telekomunikasi Indonesia
 7545     2336        336         121   TPG Telecom Limited
 4755     1899        413         192   TATA Communications formerly 
 9829     1641       1306          38   National Internet Backbone
 9583     1316        104         538   Sify Limited
 9498     1303        333          91   BHARTI Airtel Ltd.
 7552     1237       1098          14   Viettel Corporation
 9808     1233       6639          15   Guangdong Mobile Communicatio
 4808     1207       2160         363   CNCGROUP IP network China169 

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
22773     2902       2940         142   Cox Communications Inc.
 6389     2895       3688          51   BellSouth.net Inc.
18566     2045        379         178   MegaPath Corporation
 7029     1914       1957         304   Windstream Communications Inc
20115     1782       1767         505   Charter Communications
 4323     1622       1055         407   tw telecom holdings, inc.
30036     1522        316         579   Mediacom Communications Corp
 6983     1466        817         314   ITC^Deltacom
  701     1437      11242         721   MCI Communications Services, 
22561     1307        408         237   CenturyTel Internet Holdings,

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
34984     1751        299         282   TELLCOM ILETISIM HIZMETLERI A
20940     1486        580        1093   Akamai International B.V.
 8402     1317        544          15   OJSC "Vimpelcom"
31148     1042         45          20   Freenet Ltd.
13188     1013         97          51   TOV "Bank-Inform"
 8551      974        371          41   Bezeq International-Ltd
 6849      833        356          27   JSC "Ukrtelecom"
12479      788        798          58   France Telecom Espana SA
 6830      774       2335         429   Liberty Global Operations B.V
 9198      665        346          28   JSC Kazakhtelecom

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
28573     3228       2316         118   NET Servi?os de Comunica??o S
10620     2953        478         245   Telmex Colombia S.A.
18881     2086       1036          22   Global Village Telecom
 7303     1774       1182         234   Telecom Argentina S.A.
 6147     1738        374          30   Telefonica del Peru S.A.A.
 8151     1466       2999         433   Uninet S.A. de C.V.
 6503     1124        434          62   Axtel, S.A.B. de C.V.
 7738      999       1882          41   Telemar Norte Leste S.A.
27947      902        130          51   Telconet S.A
26615      889       2325          35   Tim Celular 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
24863      942        280          26   Link Egypt (Link.NET)
 6713      670        744          37   Office National des Postes et
 8452      596        958          13   TE-AS
36992      315        816          27   ETISALAT MISR
24835      307        144           9   Vodafone Data
 3741      249        920         212   Internet Solutions
29571      237         22          17   Cote d'Ivoire Telecom
37054      233         19           6   Data Telecom Service
15706      186         17           6   Sudatel (Sudan Telecom Co. Lt
12258      174         26          71   MWEB CONNECT (PROPRIETARY) LI

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
28573     3228       2316         118   NET Servi?os de Comunica??o S
10620     2953        478         245   Telmex Colombia S.A.
 4766     2933      11591         922   Korea Telecom
22773     2902       2940         142   Cox Communications Inc.
 6389     2895       3688          51   BellSouth.net Inc.
17974     2808        900          74   PT Telekomunikasi Indonesia
 7545     2336        336         121   TPG Telecom Limited
18881     2086       1036          22   Global Village Telecom
18566     2045        379         178   MegaPath Corporation
 7029     1914       1957         304   Windstream Communications Inc

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 6389      2895        2844      BellSouth.net Inc.
22773      2902        2760      Cox Communications Inc.
17974      2808        2734      PT Telekomunikasi Indonesia
10620      2953        2708      Telmex Colombia S.A.
 7545      2336        2215      TPG Telecom Limited
18881      2086        2064      Global Village Telecom
 4766      2933        2011      Korea Telecom
18566      2045        1867      MegaPath Corporation
 6147      1738        1708      Telefonica del Peru S.A.A.
 4755      1899        1707      TATA Communications formerly 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
20260   UNALLOCATED  8.25.160.0/24         3356       Level 3 Communicatio
20260   UNALLOCATED  8.25.161.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24        12180       Internap Network Ser
46473   UNALLOCATED  8.27.124.0/24        12180       Internap Network Ser
55020   UNALLOCATED  8.30.123.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          6461       Abovenet Communicati
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.88.0.0/16         6697     Republican Unitary Telecommun
100.89.0.0/16         6697     Republican Unitary Telecommun
100.90.0.0/16         6697     Republican Unitary Telecommun
100.91.0.0/16         6697     Republican Unitary Telecommun
100.92.0.0/16         6697     Republican Unitary Telecommun
100.93.0.0/16         6697     Republican Unitary Telecommun
100.94.0.0/16         6697     Republican Unitary Telecommun
100.95.0.0/16         6697     Republican Unitary Telecommun
100.96.0.0/14         6697     Republican Unitary Telecommun
100.104.0.0/13        6697     Republican Unitary Telecommun

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.100.241.0/24       23456     32bit Transition AS
24.231.96.0/24       21548     MTO Telecom Inc.
27.100.7.0/24        56096     >>UNKNOWN<<
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.10.0/24        37004     >>UNKNOWN<<
41.73.11.0/24        37004     >>UNKNOWN<<
41.73.12.0/24        37004     >>UNKNOWN<<
41.73.13.0/24        37004     >>UNKNOWN<<
41.73.14.0/24        37004     >>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:16       /9:12      /10:30      /11:90      /12:261     
/13:502     /14:987     /15:1707    /16:13049   /17:7054    /18:11764   
/19:24634   /20:35318   /21:37747   /22:54525   /23:47785   /24:271789  
/25:1079    /26:1028    /27:665     /28:15      /29:19      /30:10      
/31:1       /32:13      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2139          2902      Cox Communications Inc.
18566     2000          2045      MegaPath Corporation
 6389     1674          2895      BellSouth.net Inc.
30036     1372          1522      Mediacom Communications Corp
 6147     1313          1738      Telefonica del Peru S.A.A.
 6983     1167          1466      ITC^Deltacom
 7029     1156          1914      Windstream Communications Inc
11492     1121          1170      CABLE ONE, INC.
34984     1072          1751      TELLCOM ILETISIM HIZMETLERI A
10620     1036          2953      Telmex Colombia S.A.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1327      2:662       3:3         4:17        5:1119      6:21     
   8:750      12:1860     13:4        14:1112     15:17       16:2      
  17:39       18:21       20:51       23:914      24:1808     27:1782   
  31:1406     32:39       33:2        34:5        36:139      37:1784   
  38:964      39:14       40:221      41:2535     42:271      43:271    
  44:16       45:65       46:2122     47:24       49:733      50:824    
  52:12       54:51       55:6        56:4        57:32       58:1199   
  59:662      60:425      61:1692     62:1236     63:1837     64:4375   
  65:2298     66:4205     67:2027     68:1033     69:3253     70:864    
  71:478      72:2020     74:2575     75:369      76:421      77:1610   
  78:801      79:722      80:1321     81:1205     82:784      83:770    
  84:760      85:1322     86:437      87:1159     88:463      89:1785   
  90:138      91:5702     92:768      93:1801     94:2020     95:1594   
  96:423      97:342      98:1160     99:49      100:66      101:713    
 103:5513    104:213     105:39      106:180     107:622     108:570    
 109:1986    110:1029    111:1352    112:715     113:862     114:773    
 115:1194    116:1108    117:990     118:1561    119:1425    120:423    
 121:969     122:2192    123:1613    124:1427    125:1574    128:582    
 129:348     130:362     131:765     132:429     133:165     134:319    
 135:76      136:302     137:288     138:384     139:204     140:218    
 141:407     142:575     143:433     144:509     145:115     146:626    
 147:550     148:969     149:433     150:474     151:601     152:463    
 153:242     154:341     155:531     156:359     157:328     158:278    
 159:932     160:329     161:589     162:1722    163:350     164:701    
 165:652     166:361     167:671     168:1125    169:122     170:1398   
 171:184     172:65      173:1618    174:702     175:609     176:1482   
 177:3520    178:2072    179:765     180:1782    181:1590    182:1653   
 183:555     184:714     185:2018    186:2978    187:1711    188:2202   
 189:1493    190:7854    191:756     192:7521    193:5504    194:4049   
 195:3556    196:1422    197:688     198:5142    199:5479    200:6445   
 201:2869    202:9171    203:9004    204:4546    205:2646    206:2943   
 207:2914    208:3922    209:3768    210:3302    211:1828    212:2322   
 213:2125    214:859     215:86      216:5621    217:1693    218:613    
 219:407     220:1365    221:686     222:481     223:598    

End of report


From bzs at world.std.com  Fri Sep  5 18:28:34 2014
From: bzs at world.std.com (Barry Shein)
Date: Fri, 5 Sep 2014 14:28:34 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <5409C846.3020307@mykolab.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
Message-ID: <21514.210.949594.760636@world.std.com>


Interesting, here are my speaking notes from a talk I gave at
Hackerspace/SG in June 2011. Slightly different but in a similar
spirit depending on your sense of "similar":


                            THE END OF DNS

A Quick History

The internet uses host names but routing is done based on
numeric IP addresses usually.

For example world.std.com is 192.74.137.5 in dotted notation or
0xC04A8905 hex or 1100000001001010100010010000000101 binary or
3,226,110,213.

world.std.com can be looked at as:

          w   o   r   l   d   .   s   t   d   .   c   o   m
          073557  071154  062056  071564  062056  061557  066400

So, we need to go from the host name to the ip address and back
reliably.

Originally we used a hosttable which was simply a text file, on
unix-like systems you see a remnant of it with entries like

   127.0.0.1    localhost
   192.74.137.5 world.std.com world

with other information spread across /etc/nets and /etc/gateways, a
snippet of the distributed format from RFC810 is:

   NET : 18.0.0.0 : LCSNET :
   GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW :
   HOST : 10.0.0.73 : SRI-NIC,NIC : FOONLY-F3 : TENEX :
       NCP/TELNET,NCP/FTP, TCP/TELNET, TCP/FTP :
   HOST: 10.2.0.11 : SU-TIP,FELT-TIP :::

This was downloaded from a single host, often at midnight, and there
was a unix program (hosttable) to reformat the information for Unix.

Yes, every host on the internet downloaded a common file, often every
night.

This wouldn't scale well so Paul Mockapetris devised "DNS" or Domain
Naming Service.

The idea is very simple, each site would be responsible for their own
domain and to respond to simple remote requests for name to ip address
mappings or back again.

There would be a root, or multiple roots, which would respond to
requests to locate who should be asked about a domain, for example if
you want to know the ip address for world.std.com the conversation
goes roughly:

   (To Root Server):       Where is the COM server?
   (From Root Server):     SOMEHOST
   (TO SOMEHOST):          Where is the STD.COM server?
   (From SOMEHOST):        192.137.74.112
   (TO 192.74.137.112):    WHAT IS WORLD.STD.COM's IP ADDRESS (A RECORD)?
   (FROM 192.74.137.112):  192.74.137.5

It's amazing. to me, that it works let alone so quickly!

But let's examine this, WHY do this mapping?

1. Computationally / Memory efficient

2. Sometimes IP changes, host name can be more stable.  One reason to
   change IP is change of ISP, or LAN re-organization.

3. DNS Tricks! load balancing (e.g., round-robin), failover,
   content caching and distribution.

4. Multiple interfaces

5. Aliases

We also overload some other functions on DNS such as who is this
host's mail server or their SPF information. But let's stick to host
to ip address mapping.

THE BIG IDEA:

Why not just use the host names as ip addresses? They're integers.

In IPv6 they're rather long integers, 16 bytes.

Looking thru hundreds of millions of web server log records I found
host names to be about 32 bytes long, including dots.

So sending the host name as the ip address is not an enormous
expansion over current plans for IPv6, about double on average though
variable length must be accomdated for long host names, up to 1K or
thereabouts.

Routing by ip addresses is really very simple:

A router looks at some number of bits of an IP address, the "network"
portion, and either knows where to hand this packet next, either
another router or the actual host and we're done, or only knows that
any network which isn't in its table needs to be handed to a "default"
router neighbor and with luck the packet will eventually find a router
which knows what to do with the packet.

There might use varying number of bits to determine the best router to
send a packet to next.

At the "center" there are these routers which have NO default, they
either know how to get your packet on its way or it has no route and
is discarded.

Really very simple, all the complexity is in keeping the information
in each router current. This turns out to be not only an information
distribution problem but also an information distribution STABILITY
problem.

But it's not our problem today.

All we need concern ourself with is that there is a host name to ip
addr mapping and these ip addresses are used in routing packets,
that's the point.

But why not just use the host name and skip the mapping?

FQDNs are hierarchical, we can pick them apart and start routing a
packet looking to go to world.std.com by routing to (or towards) a COM
router, then a STD.COM router, and finally hand it off to
WORLD.STD.COM.

No doubt the devil is in the details, but tonight we're interested in
whether it's worthwhile working out those details. Are there fatal
flaws?

One complaint might be computational complexity. Integers are easy to
put into tables and use as indexes. Most real routers even have
specially built memory to speed this up.

Then again the 70s are over, the 80s are over, the 90s are over, the
2000s are over, computers are fast and getting faster and parallelism
(such as multiple cores and threads) is commodity as are relatively
large memories.

If the average host name is about 32 characters and there are about a
billion hosts then it takes around 32GB to hold all that information,
maybe twice that with table overhead, 64GB. I can buy 64GB flash
drives for around $100! They're too slow but I hope you get my point.

And, besides, you only need to hold each network portion once in a router's
memory, not for every host:

  COM
   THEWORLD  192.74.137.0
    SHELL01  71
    DNS      112

that's simple.

To search the table the router could use a perfect hash function or as
close to that as we really need.

It would probably be better if we all agreed on one or a few hash
functions but it's not necessary, it's only used inside a router, but
it might make debugging easier.

Bazinga! No DNS!

But what about our list of uses of host to ip mappings?

1. Computationally / Memory efficient

   Who cares?

2. IP changes?

   Build it into ICMP and BGP infrastructure, that's a routing
   problem.

   We already have another system, ARP, which deals with similar
   problems to map IP to MAC addresses.

3. DNS Tricks!

   Trix are for kids. But, again, a routing problem.

4. Multiple interfaces

   Same sort of problem, mostly a last hop problem.

5. Aliases

   Still a last hop problem

What are the problems?

What do we gain?

We get rid of this huge, noisy, complex infrastructure.

We still need registries and registrars because we still need to file
who "owns" a host name.

But we can get rid of the entire RIR structure, the five regional
organizations which hand out IP block, usually for $1000 or more per
year depending on the number of bits in the network part (less is more
expensive.)

Well, they could still coordinate some routing functions, ASNs, etc.

No DNS, no DNS attacks!

To me this seems more secure tho that's a dangerous conjecture to make.

But we have removed a rather public, distributed target and put most
of the function in the routing infrastructure directly which tends to
be more secure. For example, you don't accept routing updates from
anyone, only trusted hosts. And in the near future we can expect even
that to be "signed".

Speaking of signed, no DNNSSEC! DNSSEC is a fairly simple concept,
sign DNS information exchanges using public key cryptography, with a
rather complex operational overhead such as key updates and
revocations. Gone!

I've discussed this on very technical (private) mailing lists with the
sort of people who built the MSN infrastructure, Morgan-Stanley (no
more than 100msecs downtime PER YEAR!), Google, Vonage, etc.

Worst complaint: We're so accustomed to thinking in terms of DNS that
there must be SOMETHING wrong with your idea!!

A few thought it was great and made reference to other discussions
over the years which were somewhat similar tho not quite as sweeping.

SO WHAT IS WRONG?

-- 
        -Barry Shein

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


From Brian_Field at cable.comcast.com  Fri Sep  5 18:51:01 2014
From: Brian_Field at cable.comcast.com (Field, Brian)
Date: Fri, 5 Sep 2014 18:51:01 +0000
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
Message-ID: <D02F5BF1.25B5C3%brian_field@cable.comcast.com>


Here?s my $0.02.   I?m only going to touch on a small part of what I
understand NDN to be? namely making caching a first class citizen of the
network.  When you think about the types of traffic currently carried over
our collective networks, there might be value if the network eco system
more natively supported caching.

Van?s first paper proposing this NDN concept (afaik) was in 2009.

If we were to get into the ?way-back? machine to say 2003, when
peer-2-peer was a big app, one might have then decided that we really need
to make ?peer-2-peer? a first class citizen of the network.  In fact the
IETF tried [at some level] to do this with the DECADE WG.  The app space
evolved, p2p is no longer as prevalent, and DECADE saw/got little
traction.  

In 1998, we might have been thinking about making NNTP a first class
citizen of the network.

Maybe we need to think about making *software* [instead of a specific
service] a first class citizen of the network.   What do I mean by this?

If software were a first class citizen of our networks in 2003, we might
have hopped onto our routers and done a ?yum install decade?? which would
install software that would make the network eco system more efficient at
supporting p2p traffic.

Today, on our network eco system we might do a ?yum uninstall decade? and
then do a ?yum install caching?? which might embed caching functionality
into our routing eco system? hopefully making the delivery of cacheable
content more efficient.

In N years, when there is yet another new app pushing the network eco
system, we might then be doing a ?yum uninstall caching? and instead doing
a ?yum install new-app? which would make the network eco system more
efficient at supporting this new-app.

Brian





On 9/5/14, 8:16 AM, "Jay Ashworth" <jra at baylink.com> wrote:

>How many Youtube subject tags will fit in *your* routers' TCAM?
>
>  
>http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-con
>sortium-to-replace-tcpip
>
>[ Can someone convince me this isn't the biggest troll in the history
>of the internet? Cause it sounds like shoehorning DNS /and Google/ into
>IP in place of, y'know, IP addresses. ]
>
>Cheers,
>-- jra
>-- 
>Jay R. Ashworth                  Baylink
>jra at baylink.com
>Designer                     The Things I Think                       RFC
>2100
>Ashworth & Associates       http://www.bcp38.info          2000 Land
>Rover DII
>St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
>1274



From sander at steffann.nl  Fri Sep  5 19:21:17 2014
From: sander at steffann.nl (Sander Steffann)
Date: Fri, 5 Sep 2014 21:21:17 +0200
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
Message-ID: <74B09FDD-D097-494A-8E9D-C5CB17DC4D51@steffann.nl>

Hi,

> How many Youtube subject tags will fit in *your* routers' TCAM?
> 
>  http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
> 
> [ Can someone convince me this isn't the biggest troll in the history 
> of the internet? Cause it sounds like shoehorning DNS /and Google/ into 
> IP in place of, y'know, IP addresses. ]

Well, you don't need addresses for clients, just for content... From the architecture page at http://named-data.net/project/archoverview/:

"Note that neither Interest nor Data packets carry any host or interface addresses (such as IP addresses); Interest packets are routed towards data producers based on the names carried in the Interest packets, and Data packets are returned based on the state information set up by the Interests at each router hop."

So it's basically suggesting a NAT-like table in every single router. And we all know how well NAT boxes scale...

Cheers,
Sander



From jra at baylink.com  Fri Sep  5 19:23:45 2014
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 5 Sep 2014 15:23:45 -0400 (EDT)
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <74B09FDD-D097-494A-8E9D-C5CB17DC4D51@steffann.nl>
Message-ID: <5765978.290.1409945025031.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Sander Steffann" <sander at steffann.nl>

> > How many Youtube subject tags will fit in *your* routers' TCAM?
> >
> >  http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
> >
> > [ Can someone convince me this isn't the biggest troll in the
> > history
> > of the internet? Cause it sounds like shoehorning DNS /and Google/
> > into
> > IP in place of, y'know, IP addresses. ]
> 
> Well, you don't need addresses for clients, just for content... From
> the architecture page at http://named-data.net/project/archoverview/:
> 
> "Note that neither Interest nor Data packets carry any host or
> interface addresses (such as IP addresses); Interest packets are
> routed towards data producers based on the names carried in the
> Interest packets, and Data packets are returned based on the state
> information set up by the Interests at each router hop."
> 
> So it's basically suggesting a NAT-like table in every single router.
> And we all know how well NAT boxes scale...

Well, as I suggested, I didn't think it was nearly that easy to do. 

It sounds to me like they want to put *Google* in every router.

Cause no one who posits this stuff has, apparently, ever had to do network
diagnosis.

You put too much distributed state in the network and it comes apart. We're
nearly there now with IPv4.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From yuksem at cse.unr.edu  Fri Sep  5 19:27:35 2014
From: yuksem at cse.unr.edu (Murat Yuksel)
Date: Fri, 5 Sep 2014 12:27:35 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <D02F5BF1.25B5C3%brian_field@cable.comcast.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <D02F5BF1.25B5C3%brian_field@cable.comcast.com>
Message-ID: <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>

As far as I understand, NDN's basic premise is to install "names" into the network layer. I don't think they (the NDN inventors) consider it as a new "app" at this point, even tough eventually it may merely stay as a new app.

I think the final thing that will determine the success of NDN is whether or not pushing names into the network layer rather than handling it at the app layer is going to return significant enough benefits. On the positive side, we will get rid of name -> address -> name mapping we are doing with DNS, we will enjoy content caching in routers themselves without relying on content servers to do it for us, and the story of upgrading to IPv6 will be over. :)  On the negative side, we will have to deal with a whole new set of security and privacy issues (I can see a new wave of funding for cyber-security folks), we will need to revamp our routers (arguably which seems to attract Cisco so far) to handle names rather than IP addresses, and most importantly re-educate our practitioners to configure these "revamped" routers!

The key question is that do we really need to push the names into the network layer? I personally don't see this will happen, particularly as a replacement to TCP/IP as was laid down in the slashdot article. The best bet, IMHO, for NDN is to establish software-based NDN routers that maintain content tagged with names. One way to imagine I guess is to consider each router as a NAT box for this. I just can't see it replacing IP-based forwarding. We all wish things were so easy to change, but simply they are not.

Best,

-Murat

On Sep 5, 2014, at 11:51 AM, Field, Brian <Brian_Field at cable.comcast.com> wrote:

> 
> Here?s my $0.02.   I?m only going to touch on a small part of what I
> understand NDN to be? namely making caching a first class citizen of the
> network.  When you think about the types of traffic currently carried over
> our collective networks, there might be value if the network eco system
> more natively supported caching.
> 
> Van?s first paper proposing this NDN concept (afaik) was in 2009.
> 
> If we were to get into the ?way-back? machine to say 2003, when
> peer-2-peer was a big app, one might have then decided that we really need
> to make ?peer-2-peer? a first class citizen of the network.  In fact the
> IETF tried [at some level] to do this with the DECADE WG.  The app space
> evolved, p2p is no longer as prevalent, and DECADE saw/got little
> traction.  
> 
> In 1998, we might have been thinking about making NNTP a first class
> citizen of the network.
> 
> Maybe we need to think about making *software* [instead of a specific
> service] a first class citizen of the network.   What do I mean by this?
> 
> If software were a first class citizen of our networks in 2003, we might
> have hopped onto our routers and done a ?yum install decade?? which would
> install software that would make the network eco system more efficient at
> supporting p2p traffic.
> 
> Today, on our network eco system we might do a ?yum uninstall decade? and
> then do a ?yum install caching?? which might embed caching functionality
> into our routing eco system? hopefully making the delivery of cacheable
> content more efficient.
> 
> In N years, when there is yet another new app pushing the network eco
> system, we might then be doing a ?yum uninstall caching? and instead doing
> a ?yum install new-app? which would make the network eco system more
> efficient at supporting this new-app.
> 
> Brian
> 
> 
> 
> 
> 
> On 9/5/14, 8:16 AM, "Jay Ashworth" <jra at baylink.com> wrote:
> 
>> How many Youtube subject tags will fit in *your* routers' TCAM?
>> 
>> 
>> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-con
>> sortium-to-replace-tcpip
>> 
>> [ Can someone convince me this isn't the biggest troll in the history
>> of the internet? Cause it sounds like shoehorning DNS /and Google/ into
>> IP in place of, y'know, IP addresses. ]
>> 
>> Cheers,
>> -- jra
>> -- 
>> Jay R. Ashworth                  Baylink
>> jra at baylink.com
>> Designer                     The Things I Think                       RFC
>> 2100
>> Ashworth & Associates       http://www.bcp38.info          2000 Land
>> Rover DII
>> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
>> 1274

======================================== 
Murat Yuksel
Associate Professor
Graduate Director
Department of Computer Science and Engineering 
University of Nevada - Reno 
1664 N. Virginia Street, MS 171, Reno, NV 89557.
Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877
E-mail: yuksem at cse.unr.edu
Web: http://www.cse.unr.edu/~yuksem 
========================================



From fergdawgster at mykolab.com  Fri Sep  5 19:38:13 2014
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Fri, 05 Sep 2014 12:38:13 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <D02F5BF1.25B5C3%brian_field@cable.comcast.com>
 <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>
Message-ID: <540A1125.9030403@mykolab.com>

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

The principle questions still stand unanswered:

What is the motivation for this? What do you gain? Does it create some
large architectural and performance in efficiency?

- - ferg

On 9/5/2014 12:27 PM, Murat Yuksel wrote:

> As far as I understand, NDN's basic premise is to install "names"
> into the network layer. I don't think they (the NDN inventors)
> consider it as a new "app" at this point, even tough eventually it
> may merely stay as a new app.
> 
> I think the final thing that will determine the success of NDN is
> whether or not pushing names into the network layer rather than
> handling it at the app layer is going to return significant enough
> benefits. On the positive side, we will get rid of name -> address
> -> name mapping we are doing with DNS, we will enjoy content
> caching in routers themselves without relying on content servers to
> do it for us, and the story of upgrading to IPv6 will be over. :)
> On the negative side, we will have to deal with a whole new set of
> security and privacy issues (I can see a new wave of funding for
> cyber-security folks), we will need to revamp our routers (arguably
> which seems to attract Cisco so far) to handle names rather than IP
> addresses, and most importantly re-educate our practitioners to
> configure these "revamped" routers!
> 
> The key question is that do we really need to push the names into
> the network layer? I personally don't see this will happen,
> particularly as a replacement to TCP/IP as was laid down in the
> slashdot article. The best bet, IMHO, for NDN is to establish
> software-based NDN routers that maintain content tagged with names.
> One way to imagine I guess is to consider each router as a NAT box
> for this. I just can't see it replacing IP-based forwarding. We all
> wish things were so easy to change, but simply they are not.
> 
> Best,
> 
> -Murat
> 
> On Sep 5, 2014, at 11:51 AM, Field, Brian
> <Brian_Field at cable.comcast.com> wrote:
> 
>> 
>> Here?s my $0.02.   I?m only going to touch on a small part of
>> what I understand NDN to be? namely making caching a first class
>> citizen of the network.  When you think about the types of
>> traffic currently carried over our collective networks, there
>> might be value if the network eco system more natively supported
>> caching.
>> 
>> Van?s first paper proposing this NDN concept (afaik) was in
>> 2009.
>> 
>> If we were to get into the ?way-back? machine to say 2003, when 
>> peer-2-peer was a big app, one might have then decided that we
>> really need to make ?peer-2-peer? a first class citizen of the
>> network.  In fact the IETF tried [at some level] to do this with
>> the DECADE WG.  The app space evolved, p2p is no longer as
>> prevalent, and DECADE saw/got little traction.
>> 
>> In 1998, we might have been thinking about making NNTP a first
>> class citizen of the network.
>> 
>> Maybe we need to think about making *software* [instead of a
>> specific service] a first class citizen of the network.   What do
>> I mean by this?
>> 
>> If software were a first class citizen of our networks in 2003,
>> we might have hopped onto our routers and done a ?yum install
>> decade?? which would install software that would make the network
>> eco system more efficient at supporting p2p traffic.
>> 
>> Today, on our network eco system we might do a ?yum uninstall
>> decade? and then do a ?yum install caching?? which might embed
>> caching functionality into our routing eco system? hopefully
>> making the delivery of cacheable content more efficient.
>> 
>> In N years, when there is yet another new app pushing the network
>> eco system, we might then be doing a ?yum uninstall caching? and
>> instead doing a ?yum install new-app? which would make the
>> network eco system more efficient at supporting this new-app.
>> 
>> Brian
>> 
>> 
>> 
>> 
>> 
>> On 9/5/14, 8:16 AM, "Jay Ashworth" <jra at baylink.com> wrote:
>> 
>>> How many Youtube subject tags will fit in *your* routers'
>>> TCAM?
>>> 
>>> 
>>> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-con
>>>
>>> 
sortium-to-replace-tcpip
>>> 
>>> [ Can someone convince me this isn't the biggest troll in the
>>> history of the internet? Cause it sounds like shoehorning DNS
>>> /and Google/ into IP in place of, y'know, IP addresses. ]
>>> 
>>> Cheers, -- jra -- Jay R. Ashworth                  Baylink 
>>> jra at baylink.com Designer                     The Things I Think
>>> RFC 2100 Ashworth & Associates       http://www.bcp38.info
>>> 2000 Land Rover DII St Petersburg FL USA      BCP38: Ask For It
>>> By Name!           +1 727 647 1274
> 
> ======================================== Murat Yuksel Associate
> Professor Graduate Director Department of Computer Science and
> Engineering University of Nevada - Reno 1664 N. Virginia Street, MS
> 171, Reno, NV 89557. Phone: +1 (775) 327 2246, Fax: +1 (775) 784
> 1877 E-mail: yuksem at cse.unr.edu Web: http://www.cse.unr.edu/~yuksem
>  ========================================
> 
> 
> 


- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF0EAREIAAYFAlQKESUACgkQKJasdVTchbJNHAD/ewvpcjDp9riZGaY2nQmt65gy
GSmfQnKsgAPQw6fRC9QA+K3RZ8yb1DUCzxFzVpog+GpmOiQFBq1savUPwE0IRF0=
=YGBf
-----END PGP SIGNATURE-----


From yuksem at cse.unr.edu  Fri Sep  5 19:42:36 2014
From: yuksem at cse.unr.edu (Murat Yuksel)
Date: Fri, 5 Sep 2014 12:42:36 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <74B09FDD-D097-494A-8E9D-C5CB17DC4D51@steffann.nl>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <74B09FDD-D097-494A-8E9D-C5CB17DC4D51@steffann.nl>
Message-ID: <74408EAC-A493-4439-A2A1-1C46BE4048B2@cse.unr.edu>


On Sep 5, 2014, at 12:21 PM, Sander Steffann <sander at steffann.nl> wrote:

> Hi,
> 
>> How many Youtube subject tags will fit in *your* routers' TCAM?
>> 
>> http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
>> 
>> [ Can someone convince me this isn't the biggest troll in the history 
>> of the internet? Cause it sounds like shoehorning DNS /and Google/ into 
>> IP in place of, y'know, IP addresses. ]
> 
> Well, you don't need addresses for clients, just for content... From the architecture page at http://named-data.net/project/archoverview/:
> 
> "Note that neither Interest nor Data packets carry any host or interface addresses (such as IP addresses); Interest packets are routed towards data producers based on the names carried in the Interest packets, and Data packets are returned based on the state information set up by the Interests at each router hop."
> 
> So it's basically suggesting a NAT-like table in every single router. And we all know how well NAT boxes scale...
> 

We were writing in parallel. :)

-Murat

> Cheers,
> Sander

======================================== 
Murat Yuksel
Associate Professor
Graduate Director
Department of Computer Science and Engineering 
University of Nevada - Reno 
1664 N. Virginia Street, MS 171, Reno, NV 89557.
Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877
E-mail: yuksem at cse.unr.edu
Web: http://www.cse.unr.edu/~yuksem 
========================================



From Valdis.Kletnieks at vt.edu  Fri Sep  5 19:49:17 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 05 Sep 2014 15:49:17 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: Your message of "Fri, 05 Sep 2014 12:38:13 -0700."
 <540A1125.9030403@mykolab.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <D02F5BF1.25B5C3%brian_field@cable.comcast.com>
 <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>
 <540A1125.9030403@mykolab.com>
Message-ID: <12670.1409946557@turing-police.cc.vt.edu>

On Fri, 05 Sep 2014 12:38:13 -0700, Paul Ferguson said:
> The principle questions still stand unanswered:
> 
> What is the motivation for this? What do you gain? Does it create some
> large architectural and performance in efficiency?

How often do the copyright owners on content give a flying fig in a
rolling donut about efficiency if it interferes with being able to
control who accesses the content, and how?

Look at the legislative history of attempts to fix the anti-circumvention
clause of the DMCA so it's not illegal to do technical tricks to access content
you have a legal right to access.  That should tell you all you need to know
about the motivation for this....




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140905/5a1f962f/attachment.sig>

From fergdawgster at mykolab.com  Fri Sep  5 20:02:42 2014
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Fri, 05 Sep 2014 13:02:42 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <12670.1409946557@turing-police.cc.vt.edu>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <D02F5BF1.25B5C3%brian_field@cable.comcast.com>
 <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>
 <540A1125.9030403@mykolab.com> <12670.1409946557@turing-police.cc.vt.edu>
Message-ID: <540A16E2.6080902@mykolab.com>

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

On 9/5/2014 12:49 PM, Valdis.Kletnieks at vt.edu wrote:

> On Fri, 05 Sep 2014 12:38:13 -0700, Paul Ferguson said:
>> The principle questions still stand unanswered:
>> 
>> What is the motivation for this? What do you gain? Does it create
>> some large architectural and performance in efficiency?
> 
> How often do the copyright owners on content give a flying fig in
> a rolling donut about efficiency if it interferes with being able
> to control who accesses the content, and how?
> 
> Look at the legislative history of attempts to fix the
> anti-circumvention clause of the DMCA so it's not illegal to do
> technical tricks to access content you have a legal right to
> access.  That should tell you all you need to know about the
> motivation for this....
> 


Thanks for validating for me that this is pretty much what John Schiel
said earlier:


>> Almost sounds like the perfect protocol to allow the combination 
>> Internet/content provider to keep all content coming from where
>> they want the content to come from instead of the freedom to
>> choose
where the
>> content comes from.

- - ferg


- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQKFuIACgkQKJasdVTchbK5FQD/Sk4TXIMBxJo6TMlPwhjXYYRJ
nUuWCfhlJ20MCVMJbRoBANqwQOE0+wLyTqhvfwc3hbQLCt0ok91YXsfAEcQY9rA1
=o0UB
-----END PGP SIGNATURE-----


From brandon at rd.bbc.co.uk  Fri Sep  5 21:09:16 2014
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Fri, 5 Sep 2014 22:09:16 +0100 (BST)
Subject: The Next Big Thing: Named-Data Networking
Message-ID: <201409052109.WAA24413@sunf10.rd.bbc.co.uk>

> From: Jay Ashworth <jra at baylink.com>
> It sounds to me like they want to put *Google* in every router.
> 
> Cause no one who posits this stuff has, apparently, ever had to do network
> diagnosis.

Probably more focussed on selling you your internet keyword

brandon


From bill at herrin.us  Fri Sep  5 21:17:34 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Sep 2014 17:17:34 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <D02F5BF1.25B5C3%brian_field@cable.comcast.com>
 <EEB60D32-C501-41F0-89DE-E6E176E62D34@cse.unr.edu>
Message-ID: <CAP-guGWxOR4370TWYvMbP+MAPTPiy9w4ovbay4D85vBec_k0VA@mail.gmail.com>

On Fri, Sep 5, 2014 at 3:27 PM, Murat Yuksel <yuksem at cse.unr.edu> wrote:
> As far as I understand, NDN's basic premise is to
> install "names" into the network layer.

Hi Murat,

If they think names belong at layer 4 instead of layer 7 I can offer a
couple insights on how this might be used to make layer 3 cheaper and
more effective.

If they think names belong at layer 3 everyone in this forum can
rattle off a dozen reasons why that's totally wacko.


On Fri, Sep 5, 2014 at 2:51 PM, Field, Brian
<Brian_Field at cable.comcast.com> wrote:
> I'm only going to touch on a small part of what I
> understand NDN to be? namely making caching a first class citizen of the
> network.

Anycast can allow a supporting client to find the nearest device of
type X. And it can allow the local device of type X to find the
nearest regional device of type X. Making caching a first class
network element is positively needless.

Regards,
Bill Herrin




-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From cidr-report at potaroo.net  Fri Sep  5 22:00:00 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 5 Sep 2014 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201409052200.s85M00h5036269@wattle.apnic.net>

This report has been generated at Fri Sep  5 21:14:08 2014 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/2.0 for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        29-08-14    515254      284223
        30-08-14    514660      283956
        31-08-14    515006      283036
        01-09-14    514875      283511
        02-09-14    515163      283467
        03-09-14    514778      283319
        04-09-14    514694      284222
        05-09-14    515023      284597


AS Summary
         48176  Number of ASes in routing system
         19499  Number of ASes announcing only one prefix
          3224  Largest number of prefixes announced by an AS
                AS28573: NET Servi?os de Comunica??o S.A.,BR
      120184320  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


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').

 --- 05Sep14 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     515485   284614   230871    44.8%   All ASes

AS28573     3224      136     3088    95.8%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS6389      2894       69     2825    97.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS17974     2809       80     2729    97.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS22773     2900      173     2727    94.0%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS4766      2933     1197     1736    59.2%   KIXS-AS-KR Korea Telecom,KR
AS4755      1896      243     1653    87.2%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS6147      1738      163     1575    90.6%   Telefonica del Peru S.A.A.,PE
AS7303      1779      285     1494    84.0%   Telecom Argentina S.A.,AR
AS18881     2086      652     1434    68.7%   Global Village Telecom,BR
AS8402      1287       25     1262    98.1%   CORBINA-AS OJSC "Vimpelcom",RU
AS4323      1634      413     1221    74.7%   TWTC - tw telecom holdings,
                                               inc.,US
AS20115     1784      579     1205    67.5%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS7552      1264       61     1203    95.2%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS7545      2352     1150     1202    51.1%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS9808      1238       38     1200    96.9%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS9498      1305      110     1195    91.6%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566     2044      862     1182    57.8%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS10620     2954     1827     1127    38.2%   Telmex Colombia S.A.,CO
AS22561     1308      259     1049    80.2%   AS22561 - CenturyTel Internet
                                               Holdings, Inc.,US
AS7738       999       83      916    91.7%   Telemar Norte Leste S.A.,BR
AS2516      1055      202      853    80.9%   KDDI KDDI CORPORATION,JP
AS24560     1174      334      840    71.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services,IN
AS4788      1048      226      822    78.4%   TMNET-AS-AP TM Net, Internet
                                               Service Provider,MY
AS7029      2005     1190      815    40.6%   WINDSTREAM - Windstream
                                               Communications Inc,US
AS38285      956      151      805    84.2%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS4780      1027      255      772    75.2%   SEEDNET Digital United Inc.,TW
AS26615      897      127      770    85.8%   Tim Celular S.A.,BR
AS18101      955      193      762    79.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI,IN
AS8151      1476      722      754    51.1%   Uninet S.A. de C.V.,MX
AS17908      838       92      746    89.0%   TCISL Tata Communications,IN

Total      51859    11897    39962    77.1%   Top 30 total


Possible Bogus Routes

        5.100.241.0/24       AS19957 -Reserved AS-,ZZ
        24.231.96.0/24       AS21548 MTO - MTO Telecom Inc.,CA
        27.100.7.0/24        AS56096 
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.10.0/24        AS37004 -Reserved AS-,ZZ
        41.73.11.0/24        AS37004 -Reserved AS-,ZZ
        41.73.12.0/24        AS37004 -Reserved AS-,ZZ
        41.73.13.0/24        AS37004 -Reserved AS-,ZZ
        41.73.14.0/24        AS37004 -Reserved AS-,ZZ
        41.73.15.0/24        AS37004 -Reserved AS-,ZZ
        41.73.16.0/24        AS37004 -Reserved AS-,ZZ
        41.73.18.0/24        AS37004 -Reserved AS-,ZZ
        41.73.20.0/24        AS37004 -Reserved AS-,ZZ
        41.73.21.0/24        AS37004 -Reserved AS-,ZZ
        41.76.48.0/21        AS36969 MTL-AS,MW
        41.78.120.0/23       AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US
        41.78.180.0/23       AS37265 -Reserved AS-,ZZ
        41.189.96.0/20       AS37000 -Reserved AS-,ZZ
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -Reserved AS-,ZZ
        41.191.108.0/22      AS37004 -Reserved AS-,ZZ
        41.191.108.0/24      AS37004 -Reserved AS-,ZZ
        41.191.109.0/24      AS37004 -Reserved AS-,ZZ
        41.191.110.0/24      AS37004 -Reserved AS-,ZZ
        41.191.111.0/24      AS37004 -Reserved AS-,ZZ
        41.223.208.0/22      AS37000 -Reserved AS-,ZZ
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV,NL
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV,NL
        62.193.160.0/19      AS24801 -Reserved AS-,ZZ
        62.193.160.0/20      AS24801 -Reserved AS-,ZZ
        62.193.176.0/20      AS24801 -Reserved AS-,ZZ
        64.25.16.0/23        AS19535 -Reserved AS-,ZZ
        64.25.20.0/24        AS19535 -Reserved AS-,ZZ
        64.25.21.0/24        AS19535 -Reserved AS-,ZZ
        64.25.22.0/24        AS19535 -Reserved AS-,ZZ
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US
        64.111.160.0/20      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.160.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.161.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.162.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.167.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.169.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.170.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.171.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.172.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.173.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.174.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.175.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global,US
        66.55.96.0/23        AS17203 -Reserved AS-,ZZ
        66.55.98.0/24        AS17203 -Reserved AS-,ZZ
        66.55.99.0/24        AS17203 -Reserved AS-,ZZ
        66.55.100.0/22       AS17203 -Reserved AS-,ZZ
        66.55.102.0/23       AS17203 -Reserved AS-,ZZ
        66.55.104.0/21       AS17203 -Reserved AS-,ZZ
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation,CA
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.,IT
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        74.112.100.0/22      AS16764 -Reserved AS-,ZZ
        74.113.200.0/23      AS46939 -Reserved AS-,ZZ
        74.114.52.0/22       AS40818 -Reserved AS-,ZZ
        74.114.52.0/23       AS40818 -Reserved AS-,ZZ
        74.114.52.0/24       AS40818 -Reserved AS-,ZZ
        74.114.53.0/24       AS40818 -Reserved AS-,ZZ
        74.114.54.0/23       AS40818 -Reserved AS-,ZZ
        74.114.54.0/24       AS40818 -Reserved AS-,ZZ
        74.114.55.0/24       AS40818 -Reserved AS-,ZZ
        74.118.132.0/22      AS5117  -Reserved AS-,ZZ
        74.120.212.0/23      AS32326 -Reserved AS-,ZZ
        74.120.214.0/23      AS32326 -Reserved AS-,ZZ
        74.121.24.0/22       AS36263 FORONA - Forona Technologies, Inc.,US
        74.123.136.0/21      AS53358 -Reserved AS-,ZZ
        77.243.80.0/24       AS42597 -Reserved AS-,ZZ
        77.243.81.0/24       AS42597 -Reserved AS-,ZZ
        77.243.88.0/24       AS42597 -Reserved AS-,ZZ
        77.243.91.0/24       AS42597 -Reserved AS-,ZZ
        77.243.94.0/24       AS42597 -Reserved AS-,ZZ
        77.243.95.0/24       AS42597 -Reserved AS-,ZZ
        80.78.133.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/23       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.135.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.250.32.0/22       AS37106 ODUA-AS,NG
        85.202.160.0/20      AS44404 -Reserved AS-,ZZ
        89.31.24.0/23        AS41455 -Reserved AS-,ZZ
        89.31.26.0/23        AS41455 -Reserved AS-,ZZ
        89.31.28.0/22        AS41455 -Reserved AS-,ZZ
        89.207.8.0/21        AS3292  TDC TDC A/S,DK
        91.193.60.0/22       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.195.66.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.197.36.0/22       AS43359 -Reserved AS-,ZZ
        91.199.90.0/24       AS44330 -Reserved AS-,ZZ
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG,DE
        91.228.160.0/24      AS35557 GRITSENKO-AS PE GRITSENKO NADEJDA NIKOLAEVNA,UA
        91.239.157.0/24      AS24958 TBSH The Bunker Secure Hosting Limited,GB
        93.190.10.0/24       AS47254 -Reserved AS-,ZZ
        100.65.0.0/24        AS4826  VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU
        100.88.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.89.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.90.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.91.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.92.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.93.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.94.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.95.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.96.0.0/14        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.104.0.0/13       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.112.0.0/13       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.120.0.0/14       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        100.124.0.0/14       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. ,AU
        103.6.108.0/22       AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN
        103.6.228.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.9.108.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.76.0/22       AS18097 DCN D.C.N. Corporation,JP
        103.18.92.0/22       AS13269 
        103.18.92.0/24       AS13269 
        103.18.94.0/24       AS13269 
        103.18.248.0/22      AS18097 DCN D.C.N. Corporation,JP
        103.19.0.0/22        AS18097 DCN D.C.N. Corporation,JP
        103.20.100.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.20.101.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.21.4.0/22        AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US
        103.25.120.0/22      AS13280 
        103.26.76.0/22       AS13280 
        103.26.116.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.220.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.249.8.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.250.0.0/22       AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.250.12.0/22      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.250.12.0/23      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.250.12.0/24      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.250.13.0/24      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.250.14.0/23      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.250.14.0/24      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.250.15.0/24      AS58451 EASYHOST-HK EASYHOST SOLUTION LIMITED,HK
        103.251.192.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        104.194.160.0/19     AS36315 SERVPAC - Servpac Inc.,US
        104.195.128.0/17     AS5645  TEKSAVVY - TekSavvy Solutions, Inc.,CA
        116.206.72.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.85.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.103.0/24     AS6461  ABOVENET - Abovenet Communications, Inc,US
        117.103.32.0/24      AS23861 
        117.103.33.0/24      AS23861 
        117.103.34.0/24      AS23861 
        117.103.35.0/24      AS23861 
        117.103.36.0/24      AS23861 
        117.103.37.0/24      AS23861 
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street,CN
        124.108.16.0/22      AS38904 
        124.158.28.0/22      AS45857 
        131.108.244.0/22     AS52928 JANAJ? SERVI?OS LTDA,BR
        142.147.62.0/24      AS3958  AIRCANADA - Air Canada,CA
        166.93.0.0/16        AS23537 CRITIGEN - Micro Source, Inc.,US
        172.85.0.0/24        AS29571 CITelecom-AS,CI
        172.85.1.0/24        AS29571 CITelecom-AS,CI
        172.85.2.0/24        AS29571 CITelecom-AS,CI
        172.85.3.0/24        AS29571 CITelecom-AS,CI
        172.86.0.0/24        AS29571 CITelecom-AS,CI
        172.86.1.0/24        AS29571 CITelecom-AS,CI
        172.86.2.0/24        AS29571 CITelecom-AS,CI
        172.87.0.0/24        AS29571 CITelecom-AS,CI
        172.88.0.0/24        AS29571 CITelecom-AS,CI
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group),CN
        176.111.168.0/22     AS50586 MACROSOLUTIONS MacroSolution SRL,RO
        182.237.24.0/24      AS55503 
        182.237.25.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        185.28.180.0/22      AS18097 DCN D.C.N. Corporation,JP
        185.69.60.0/22       AS60341 DATACOMFORT Data Comfort BV,NL
        190.124.252.0/22     AS7303  Telecom Argentina S.A.,AR
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US
        192.25.10.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.11.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.13.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.14.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.34.152.0/21      AS10835 VISIONARY - Visionary Communications, Inc.,US
        192.75.23.0/24       AS2579  AS2579 - Alcatel-Lucent,US
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.72.0/24      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.124.252.0/22     AS680   DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE
        192.131.233.0/24     AS7018  ATT-INTERNET4 - AT&T Services, Inc.,US
        192.149.81.0/24      AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US
        192.154.32.0/19      AS81    NCREN - MCNC,US
        192.154.64.0/19      AS81    NCREN - MCNC,US
        192.166.32.0/20      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        192.245.195.0/24     AS7381  SUNGARDRS - SunGard Availability Services LP,US
        193.9.59.0/24        AS1257  TELE2,SE
        193.16.106.0/24      AS31539 -Reserved AS-,ZZ
        193.16.145.0/24      AS31392 -Reserved AS-,ZZ
        193.22.86.0/24       AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI
        193.22.224.0/20      AS3322  -Reserved AS-,ZZ
        193.22.238.0/23      AS62383 LDS-AS Lambrechts Data Services VOF,BE
        193.26.213.0/24      AS31641 BYTEL-AS Bytel Ltd,GB
        193.28.14.0/24       AS34309 LINK11 Link11 GmbH,DE
        193.33.6.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.33.252.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.53.5.0/24        AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.93.6.0/23        AS35559 SOMEADDRESS Someaddress Networks Ltd,GB
        193.111.229.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.149.2.0/23       AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.178.196.0/22     AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company,JO
        193.200.244.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.201.244.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.245.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.246.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.202.8.0/21       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.202.9.0/24       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.223.103.0/24     AS3248  SIL-AT Tele2 Telecommunication GmbH,AT
        193.227.109.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.227.236.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.0.116.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.0.117.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.6.252.0/24       AS21202 DCSNET-AS Bredband2 AB,SE
        194.9.8.0/23         AS2863  SPRITELINK Centor AB,SE
        194.9.8.0/24         AS2863  SPRITELINK Centor AB,SE
        194.33.11.0/24       AS8943  JUMP Jump Networks Ltd.,GB
        194.39.78.0/23       AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        194.49.17.0/24       AS13135 CREW-AS Wieske's Crew GmbH,DE
        194.50.8.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.60.88.0/21       AS5089  NTL Virgin Media Limited,GB
        194.63.152.0/22      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.79.36.0/22       AS3257  TINET-BACKBONE Tinet SpA,DE
        194.88.6.0/24        AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
        194.88.226.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.99.67.0/24       AS9083  CARPENET carpeNet Information Technologies GmbH,DE
        194.126.152.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.126.219.0/24     AS34545 -Reserved AS-,ZZ
        194.126.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        194.150.214.0/23     AS30880 SPACEDUMP-AS SpaceDump IT AB,SE
        194.156.179.0/24     AS3209  VODANET Vodafone GmbH,DE
        194.180.25.0/24      AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE
        194.187.24.0/22      AS8856  UKRNET UkrNet Ltd,UA
        195.8.48.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.48.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.119.0/24       AS34304 TEENTELECOM Teen Telecom SRL,RO
        195.42.232.0/22      AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        195.85.194.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.85.201.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.110.0.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB,SE
        195.149.119.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.189.174.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA,BE
        195.234.156.0/24     AS25028 -Reserved AS-,ZZ
        195.242.182.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.244.18.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.245.98.0/23      AS48918 GLOBALWAYS GLOBALWAYS AG,DE
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.6.0.0/24         AS32768 routability-tests,MU
        196.22.8.0/24        AS27822 Emerging Markets Communications de Argentina S.R.L,AR
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        196.192.124.0/23     AS37301 AFRINIC-ZA-CPT-AS,MU
        196.216.254.0/24     AS32768 routability-tests,MU
        198.22.195.0/24      AS54583 -Reserved AS-,ZZ
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.,US
        198.74.11.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.13.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.192.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited,CA
        198.163.215.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.163.216.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        198.176.208.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.209.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.210.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.211.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.252.165.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.166.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.167.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.168.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.169.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        199.85.9.0/24        AS852   ASN852 - TELUS Communications Inc.,CA
        199.88.52.0/22       AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US
        199.116.200.0/21     AS22830 -Reserved AS-,ZZ
        199.120.150.0/24     AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        200.1.112.0/24       AS29754 GO2TEL - GO2TEL.COM INC.,US
        200.58.248.0/21      AS27849 
        200.81.48.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        200.81.49.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR
        202.53.138.0/24      AS4058  CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK
        202.58.113.0/24      AS19161 -Reserved AS-,ZZ
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.,IN
        203.142.219.0/24     AS45149 
        203.160.48.0/21      AS38008 
        203.189.116.0/22     AS45606 
        203.189.116.0/24     AS45606 
        203.189.117.0/24     AS45606 
        203.189.118.0/24     AS45606 
        203.189.119.0/24     AS45606 
        204.10.88.0/21       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        204.10.94.0/23       AS30097 NUWAVE - NuWave,US
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US
        204.16.96.0/24       AS19972 -Reserved AS-,ZZ
        204.16.97.0/24       AS19972 -Reserved AS-,ZZ
        204.16.98.0/24       AS19972 -Reserved AS-,ZZ
        204.16.99.0/24       AS19972 -Reserved AS-,ZZ
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta,GB
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp,US
        205.166.231.0/24     AS7029  WINDSTREAM - Windstream Communications Inc,US
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network,CA
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US
        206.223.224.0/24     AS21548 MTO - MTO Telecom Inc.,CA
        207.2.120.0/21       AS6221  USCYBERSITES - US Cybersites, Inc,US
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.,US
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.,US
        207.254.128.0/21     AS30689 FLOW-NET - FLOW,JM
        207.254.128.0/24     AS30689 FLOW-NET - FLOW,JM
        207.254.136.0/21     AS30689 FLOW-NET - FLOW,JM
        208.66.64.0/24       AS16936 -Reserved AS-,ZZ
        208.66.65.0/24       AS16936 -Reserved AS-,ZZ
        208.66.66.0/24       AS16936 -Reserved AS-,ZZ
        208.66.67.0/24       AS16936 -Reserved AS-,ZZ
        208.67.132.0/22      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        208.69.192.0/23      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.69.195.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.75.152.0/21      AS32146 -Reserved AS-,ZZ
        208.76.20.0/24       AS31812 -Reserved AS-,ZZ
        208.76.21.0/24       AS31812 -Reserved AS-,ZZ
        208.77.164.0/24      AS22659 -Reserved AS-,ZZ
        208.77.166.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC,US
        208.84.232.0/24      AS33131 -Reserved AS-,ZZ
        208.84.234.0/24      AS33131 -Reserved AS-,ZZ
        208.84.237.0/24      AS33131 -Reserved AS-,ZZ
        208.84.238.0/24      AS33131 -Reserved AS-,ZZ
        208.94.216.0/23      AS13629 -Reserved AS-,ZZ
        208.94.219.0/24      AS13629 -Reserved AS-,ZZ
        208.94.221.0/24      AS13629 -Reserved AS-,ZZ
        208.94.223.0/24      AS13629 -Reserved AS-,ZZ
        209.135.171.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.135.175.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.177.64.0/20      AS6461  ABOVENET - Abovenet Communications, Inc,US
        209.193.112.0/20     AS209   ASN-QWEST - Qwest Communications Company, LLC,US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US
        209.209.224.0/19     AS19513 -Reserved AS-,ZZ
        209.209.248.0/23     AS19513 -Reserved AS-,ZZ
        209.209.250.0/23     AS19513 -Reserved AS-,ZZ
        209.209.251.0/24     AS19513 -Reserved AS-,ZZ
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US
        209.234.112.0/23     AS32252 -Reserved AS-,ZZ
        209.234.114.0/23     AS32252 -Reserved AS-,ZZ
        209.234.116.0/24     AS32252 -Reserved AS-,ZZ
        209.234.117.0/24     AS32252 -Reserved AS-,ZZ
        209.234.118.0/24     AS32252 -Reserved AS-,ZZ
        209.234.119.0/24     AS32252 -Reserved AS-,ZZ
        209.234.120.0/24     AS32252 -Reserved AS-,ZZ
        209.234.121.0/24     AS32252 -Reserved AS-,ZZ
        209.234.122.0/24     AS32252 -Reserved AS-,ZZ
        213.255.128.0/20     AS24863 LINKdotNET-AS,EG
        213.255.144.0/20     AS24863 LINKdotNET-AS,EG
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.,US
        216.146.0.0/19       AS11915 US-TELEPACIFIC - TelePacific Communications,US
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US


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 cidr-report at potaroo.net  Fri Sep  5 22:00:02 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 5 Sep 2014 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201409052200.s85M02Ki036285@wattle.apnic.net>

BGP Update Report
Interval: 28-Aug-14 -to- 04-Sep-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS23752          202735  4.3%    1547.6 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 2 - AS9829           121879  2.6%      73.6 -- BSNL-NIB National Internet Backbone,IN
 3 - AS8402            90067  1.9%      59.6 -- CORBINA-AS OJSC "Vimpelcom",RU
 4 - AS3816            82980  1.8%      97.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO
 5 - AS16024           81114  1.7%   20278.5 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE
 6 - AS28573           65225  1.4%      17.6 -- NET Servi?os de Comunica??o S.A.,BR
 7 - AS4775            52040  1.1%     423.1 -- GLOBE-TELECOM-AS Globe Telecoms,PH
 8 - AS1659            47694  1.0%     190.8 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
 9 - AS6389            47667  1.0%      16.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc.,US
10 - AS10098           39605  0.8%     392.1 -- HENDERSON-HK Henderson Data Centre Limited,HK
11 - AS41691           32951  0.7%     969.1 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU
12 - AS2706            29910  0.6%     747.8 -- PI-HK Pacnet Internet (Hong Kong) Limited,JP
13 - AS7545            29521  0.6%      12.5 -- TPG-INTERNET-AP TPG Telecom Limited,AU
14 - AS27047           24756  0.5%     426.8 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center,US
15 - AS8928            22776  0.5%     172.5 -- INTEROUTE Interoute Communications Limited,GB
16 - AS36969           22698  0.5%    1335.2 -- MTL-AS,MW
17 - AS17908           22338  0.5%      26.7 -- TCISL Tata Communications,IN
18 - AS17974           22184  0.5%       7.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID
19 - AS24814           22017  0.5%    3145.3 -- SCS-AS Syrian Computer Society, scs,SY
20 - AS45899           20785  0.4%      44.4 -- VNPT-AS-VN VNPT Corp,VN


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS16024           81114  1.7%   20278.5 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE
 2 - AS38267            4081  0.1%    4081.0 -- FIBRENET-BD FibreNet Communications Ltd.,BD
 3 - AS2                4053  0.1%    1540.0 -- UDEL-DCN - University of Delaware,US
 4 - AS32336           16980  0.4%    3396.0 -- IPASS-2 - iPass Incorporated,US
 5 - AS62174            3216  0.1%    3216.0 -- INTERPAN-AS INTERPAN LTD.,BG
 6 - AS24814           22017  0.5%    3145.3 -- SCS-AS Syrian Computer Society, scs,SY
 7 - AS26661           10644  0.2%    2661.0 -- JCPS-ASN - Jeffco Public Schools,US
 8 - AS33643            2410  0.1%    2410.0 -- JELLYBELLY - Jelly Belly Candy Company,US
 9 - AS37620            4468  0.1%    2234.0 -- VIETTEL-CM-AS,CM
10 - AS21732            5808  0.1%    1936.0 -- FLAVORUS-ASN - Flavorus Inc,US
11 - AS3                1615  0.0%    5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US
12 - AS23752          202735  4.3%    1547.6 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
13 - AS30944            1495  0.0%    1495.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT
14 - AS37327            1378  0.0%    1378.0 -- NICMG,MG
15 - AS36969           22698  0.5%    1335.2 -- MTL-AS,MW
16 - AS11561            2626  0.1%    1313.0 -- EOL-AS1 - EDGAR Online, Inc.,US
17 - AS35093            3843  0.1%    1281.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
18 - AS32383            1240  0.0%    1240.0 -- ROME-NET - ROME Sverdrup,US
19 - AS3                1218  0.0%    2942.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US
20 - AS56309           10425  0.2%    1158.3 -- SIAMDATA-TH 558/402 Ratchadapisek rd,TH


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.70.64.0/21   100609  2.0%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 2 - 202.70.88.0/21   100289  2.0%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 3 - 185.47.232.0/22   81108  1.6%   AS16024 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE
 4 - 202.123.88.0/24   39235  0.8%   AS10098 -- HENDERSON-HK Henderson Data Centre Limited,HK
 5 - 46.53.64.0/19     38354  0.8%   AS24814 -- SCS-AS Syrian Computer Society, scs,SY
                                     AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY
 6 - 89.221.206.0/24   32783  0.7%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU
 7 - 120.28.62.0/24    25917  0.5%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms,PH
 8 - 222.127.0.0/24    25854  0.5%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms,PH
 9 - 192.115.44.0/22   19563  0.4%   AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL
10 - 216.231.194.0/24  16975  0.3%   AS32336 -- IPASS-2 - iPass Incorporated,US
11 - 205.247.12.0/24   13532  0.3%   AS6459  -- TRANSBEAM - I-2000, Inc.,US
12 - 112.215.16.0/24   11580  0.2%   AS17885 -- JKTXLNET-AS-AP PT Excelcomindo Pratama,ID
                                     AS24203 -- NAPXLNET-AS-ID PT Excelcomindo Pratama (Network Access Provider),ID
13 - 192.58.232.0/24   10788  0.2%   AS6629  -- NOAA-AS - NOAA,US
14 - 162.247.210.0/24   9669  0.2%   AS6     -- BULL-HN - Bull HN Information Systems Inc.,US
15 - 120.118.64.0/19    7759  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
16 - 163.15.188.0/22    7757  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
17 - 203.64.238.0/24    7757  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
18 - 163.15.185.0/24    7755  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
19 - 120.118.96.0/20    7755  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
20 - 163.15.192.0/24    7755  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW

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 esuarez at fcaglp.fcaglp.unlp.edu.ar  Fri Sep  5 22:15:40 2014
From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=)
Date: Fri, 05 Sep 2014 19:15:40 -0300
Subject: no more "Send through Gmail" option
Message-ID: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>

Hi,

according to this thread:

https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D

Gmail isn't allowing anymore "Send through Gmail" option.

Eduardo.-

-- 
Eduardo A. Suarez
Mec?nico Unix - Plomero de redes
Facultad de Ciencias Astron?micas y Geof?sicas - UNLP
FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From royce at techsolvency.com  Fri Sep  5 22:43:19 2014
From: royce at techsolvency.com (Royce Williams)
Date: Fri, 5 Sep 2014 14:43:19 -0800
Subject: no more "Send through Gmail" option
In-Reply-To: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
Message-ID: <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>

On Fri, Sep 5, 2014 at 2:15 PM, Eduardo A. Su?rez
<esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote:
>
> Hi,
>
> according to this thread:
>
> https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D
>
> Gmail isn't allowing anymore "Send through Gmail" option.

Yep. Existing email-address setups are grandfathered, but no new ones
can be added via the UI.

It's probably a mix of "let's support the ecosystem by only sending
mail from servers authorized by the domain holder" and "let's sell
more Google for Work email hosting".

If it really was more the former, there would be a "if your SPF
records include:_spf.google.com, you can still do it" option, IMO.

Royce


From hugo at slabnet.com  Fri Sep  5 23:01:53 2014
From: hugo at slabnet.com (Hugo Slabbert)
Date: Fri, 5 Sep 2014 16:01:53 -0700
Subject: no more "Send through Gmail" option
In-Reply-To: <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
 <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
Message-ID: <20140905230153.GJ27158@bamboo.slabnet.com>

>If it really was more the former, there would be a "if your SPF
>records include:_spf.google.com, you can still do it" option, IMO.

Manager: So, you're saying if we just check the SPF record when they set 
up the account, we could still let them do it.

Tech: Yes, except if they also use DKIM; then it's a no-go.

Manager: Okay, so if their SPF record includes Google's and they don't 
have DKIM, then we'd be okay?

Tech: Yes...but if they don't have an SPF record when they set up the 
account and then add one later, we'd still be in trouble.

Manager: ...

Tech: I guess we could do periodic checks for SPF records on their 
domains and either disable sending or send them an alert if an SPF 
record is created that could problems?

Manager: ...okay...and then it'd be okay?

Tech: Well, if they don't have DKIM to start and then add it, that would 
also be a problem.

Manager: ...

Tech: ...but in addition to doing checks for new/altered SPF records, we 
could also do checks if they add DKIM after adding the account.

Manager: ...

Tech: ...or we could just turn it off.

Manager: Works for me.

On Fri 2014-Sep-05 14:43:19 -0800, Royce Williams <royce at techsolvency.com> wrote:

>On Fri, Sep 5, 2014 at 2:15 PM, Eduardo A. Su?rez
><esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote:
>>
>> Hi,
>>
>> according to this thread:
>>
>> https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D
>>
>> Gmail isn't allowing anymore "Send through Gmail" option.
>
>Yep. Existing email-address setups are grandfathered, but no new ones
>can be added via the UI.
>
>It's probably a mix of "let's support the ecosystem by only sending
>mail from servers authorized by the domain holder" and "let's sell
>more Google for Work email hosting".
>
>If it really was more the former, there would be a "if your SPF
>records include:_spf.google.com, you can still do it" option, IMO.
>
>Royce

-- 
Hugo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140905/1c1d8085/attachment.sig>

From itg at itechgeek.com  Fri Sep  5 23:01:41 2014
From: itg at itechgeek.com (ITechGeek)
Date: Fri, 5 Sep 2014 19:01:41 -0400
Subject: no more "Send through Gmail" option
In-Reply-To: <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
 <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
Message-ID: <CAN2EnhBQFHOKjKB=F-RwvnRbgdU67XUbENvdRVQALHjtzz=9=Q@mail.gmail.com>

As a replacement, you can use Amazon SES and verify single email addresses
if you don't have access over the whole domain.

-----------------------------------------------------------------------------------------------
-ITG (ITechGeek)
ITG at ITechGeek.Com
https://itg.nu/
GPG Keys: https://itg.nu/contact/gpg-key
Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net


On Fri, Sep 5, 2014 at 6:43 PM, Royce Williams <royce at techsolvency.com>
wrote:

> On Fri, Sep 5, 2014 at 2:15 PM, Eduardo A. Su?rez
> <esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote:
> >
> > Hi,
> >
> > according to this thread:
> >
> >
> https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D
> >
> > Gmail isn't allowing anymore "Send through Gmail" option.
>
> Yep. Existing email-address setups are grandfathered, but no new ones
> can be added via the UI.
>
> It's probably a mix of "let's support the ecosystem by only sending
> mail from servers authorized by the domain holder" and "let's sell
> more Google for Work email hosting".
>
> If it really was more the former, there would be a "if your SPF
> records include:_spf.google.com, you can still do it" option, IMO.
>
> Royce
>


From royce at techsolvency.com  Fri Sep  5 23:26:48 2014
From: royce at techsolvency.com (Royce Williams)
Date: Fri, 5 Sep 2014 15:26:48 -0800
Subject: no more "Send through Gmail" option
In-Reply-To: <20140905230153.GJ27158@bamboo.slabnet.com>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
 <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
 <20140905230153.GJ27158@bamboo.slabnet.com>
Message-ID: <CA+E3k91f0bVb0FRWxykoJzPUEk1tRj=DW2_Bkh7tD-c+4VARyQ@mail.gmail.com>

On Fri, Sep 5, 2014 at 3:01 PM, Hugo Slabbert <hugo at slabnet.com> wrote:
>> If it really was more the former, there would be a "if your SPF
>> records include:_spf.google.com, you can still do it" option, IMO.
>
>
> Manager: So, you're saying if we just check the SPF record when they set up
> the account, we could still let them do it.
>
> Tech: Yes, except if they also use DKIM; then it's a no-go.
>
> Manager: Okay, so if their SPF record includes Google's and they don't have
> DKIM, then we'd be okay?
>
> Tech: Yes...but if they don't have an SPF record when they set up the
> account and then add one later, we'd still be in trouble.
>
> Manager: ...
>
> Tech: I guess we could do periodic checks for SPF records on their domains
> and either disable sending or send them an alert if an SPF record is created
> that could problems?
>
> Manager: ...okay...and then it'd be okay?
>
> Tech: Well, if they don't have DKIM to start and then add it, that would
> also be a problem.
>
> Manager: ...
>
> Tech: ...but in addition to doing checks for new/altered SPF records, we
> could also do checks if they add DKIM after adding the account.
>
> Manager: ...
>
> Tech: ...or we could just turn it off.
>
> Manager: Works for me.

The scenario largely rings true, except that I would think it
reasonable to tell people that it if it breaks because they added
DKIM, it's not Google's problem to fix.

But your larger point is valid.  Requiring Google for Work
automatically means that Google is dealing with geeks who manage the
entire domain, instead of chasing failure modes for individual end
users.

That being said, domain holders could signal that they're deliberately
opting in domain-wide by using a different SPF include, like
'_spf-fwd.google.com', and agreeing (with a checkbox?) that chasing
DKIM is their baby.

Royce


From itg at itechgeek.com  Sat Sep  6 00:03:50 2014
From: itg at itechgeek.com (ITechGeek)
Date: Fri, 5 Sep 2014 20:03:50 -0400
Subject: Weekly CIDR Reports
Message-ID: <CAN2EnhAzrzwkQAhSo05pXW7zEVb12NbO6kyLPqkViTd2a=9XoQ@mail.gmail.com>

Does anyone know if it is possible to get a copy of the Announced and
Withdrawn prefix list a couple weeks ago?  Is that weekly list archived
somewhere?

-----------------------------------------------------------------------------------------------
-ITG (ITechGeek)
ITG at ITechGeek.Com
https://itg.nu/
GPG Keys: https://itg.nu/contact/gpg-key
Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net


From shrdlu at deaddrop.org  Sat Sep  6 00:14:36 2014
From: shrdlu at deaddrop.org (Shrdlu)
Date: Fri, 05 Sep 2014 17:14:36 -0700
Subject: Weekly CIDR Reports
In-Reply-To: <CAN2EnhAzrzwkQAhSo05pXW7zEVb12NbO6kyLPqkViTd2a=9XoQ@mail.gmail.com>
References: <CAN2EnhAzrzwkQAhSo05pXW7zEVb12NbO6kyLPqkViTd2a=9XoQ@mail.gmail.com>
Message-ID: <540A51EC.7020703@deaddrop.org>

On 9/5/2014 5:03 PM, ITechGeek wrote:
> Does anyone know if it is possible to get a copy of the Announced and
> Withdrawn prefix list a couple weeks ago?  Is that weekly list archived
> somewhere?

Which weeks? I'm pretty compulsive, and have most of them.

-- 
"They had discovered Mr. Slippery's True Name and it was Roger Andrew
Pollack TIN/SSAN 0959-34-2861, and no amount of evasion, tricky
programming, or robot sources could ever again protect him from them."
               True Names, Vernor Vinge


From me at staticsafe.ca  Sat Sep  6 00:24:24 2014
From: me at staticsafe.ca (staticsafe)
Date: Fri, 05 Sep 2014 20:24:24 -0400
Subject: Weekly CIDR Reports
In-Reply-To: <CAN2EnhAzrzwkQAhSo05pXW7zEVb12NbO6kyLPqkViTd2a=9XoQ@mail.gmail.com>
References: <CAN2EnhAzrzwkQAhSo05pXW7zEVb12NbO6kyLPqkViTd2a=9XoQ@mail.gmail.com>
Message-ID: <540A5438.9080703@staticsafe.ca>

On 9/5/2014 20:03, ITechGeek wrote:
> Does anyone know if it is possible to get a copy of the Announced and
> Withdrawn prefix list a couple weeks ago?  Is that weekly list archived
> somewhere?
> 
> -----------------------------------------------------------------------------------------------
> -ITG (ITechGeek)

Since these are mailed to the NANOG list they will be available in their
mailman archives:

http://mailman.nanog.org/pipermail/nanog/

-- 
staticsafe
https://staticsafe.ca


From itg at itechgeek.com  Sat Sep  6 00:36:49 2014
From: itg at itechgeek.com (ITechGeek)
Date: Fri, 5 Sep 2014 20:36:49 -0400
Subject: Weekly CIDR Reports
In-Reply-To: <540A5438.9080703@staticsafe.ca>
References: <CAN2EnhAzrzwkQAhSo05pXW7zEVb12NbO6kyLPqkViTd2a=9XoQ@mail.gmail.com>
 <540A5438.9080703@staticsafe.ca>
Message-ID: <CAN2EnhCqK=vebbxMgT5TtGp+XjRo+fsuFhFFidxzOvQP98zXNw@mail.gmail.com>

What is sent to the list only shows possible bogus routes and unstable
routes.  I'm looking for the more complete (
http://www.cidr-report.org/as2.0/as-prefixes.txt).

-----------------------------------------------------------------------------------------------
-ITG (ITechGeek)
ITG at ITechGeek.Com
https://itg.nu/
GPG Keys: https://itg.nu/contact/gpg-key
Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net


On Fri, Sep 5, 2014 at 8:24 PM, staticsafe <me at staticsafe.ca> wrote:

> On 9/5/2014 20:03, ITechGeek wrote:
> > Does anyone know if it is possible to get a copy of the Announced and
> > Withdrawn prefix list a couple weeks ago?  Is that weekly list archived
> > somewhere?
> >
> >
> -----------------------------------------------------------------------------------------------
> > -ITG (ITechGeek)
>
> Since these are mailed to the NANOG list they will be available in their
> mailman archives:
>
> http://mailman.nanog.org/pipermail/nanog/
>
> --
> staticsafe
> https://staticsafe.ca
>


From randy at psg.com  Sat Sep  6 01:00:10 2014
From: randy at psg.com (Randy Bush)
Date: Sat, 06 Sep 2014 10:00:10 +0900
Subject: Security Track @ NANOG 62 Call for Participation
In-Reply-To: <20140905113738.1f94168f@localhost>
References: <20140905113738.1f94168f@localhost>
Message-ID: <m2lhpxy351.wl%randy@psg.com>

of course i can make noise about the rpki and origin validation, if that
is of help.  and i do not need to know more than a few days in advance.

but i would love 15 mins to talk about progress on cryptech, and hope to
have a toy to show off.  <https://trac.cryptech.is/>

> If you want your PGP key signed by me (or anyone else), you should
> upload it before arriving to this page to we have a record of it before
> meeting in person.

grammar yuchh

randy


From alvarezp at alvarezp.ods.org  Sat Sep  6 03:06:56 2014
From: alvarezp at alvarezp.ods.org (Octavio Alvarez)
Date: Fri, 05 Sep 2014 20:06:56 -0700
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
Message-ID: <540A7A50.6020303@alvarezp.ods.org>

On 05/09/14 07:16, Jay Ashworth wrote:
> How many Youtube subject tags will fit in *your* routers' TCAM?
> 
>   http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
> 
> [ Can someone convince me this isn't the biggest troll in the history 
> of the internet? Cause it sounds like shoehorning DNS /and Google/ into 
> IP in place of, y'know, IP addresses. ]

Just my opinion:

I just saw one video [1] so I may be misjudging or misunderstanding:

When posted in 2007 there were many open problems yet. I hardly think
that all the benefits would be real benefits and most things can be
already done and it doesn't solve the most intricate problems of today's
Internet. I wonder if it could really be fully trusted.

Sounds nice and all, but I'm having trouble constructing it in my own
head. What about live content (multicast), what about I as an end-user
being able to certify my own information without relying on someone
else? How to get the initial certificates, signed and trusted? When I
request everybody near me to get some info and nobody have it, will
everybody ask for everybody near each of them?

And besides, most of the problems he describes can be solved by
inserting a layer between 3 and 4 (something based on the Host Identity
Protocol and its DNS records). It's still a change of paradigm but a
smaller one: instead of connecting to hosts, connect to services that
can be provided (dig -t ESRV) by many hosts each of which may have (dig
-t AAAA) many physical addresses. You set up a tunnel with internal
signaling between end hosts that have multiple addresses and there you
go: automatic path resiliency on both sides, automatic L3 mobility with
connection persistency, some basic automatic encryption for all
connections among those two hosts, all without requiring PI addressing
(BGP would only be used for Internet providers and big sites)... It
would scale and all that is needed is some changes in the OS, not
applications, not the whole Internet. No need to justify equipment
acquisition because it is end-to-end. The infrastructure doesn't need to
be updated at first, but would need to catch up. Internet could be
forced to catch up and if done properly, this gives automatic efficient
addressing with a drastic reduction of the global routing table and
automatic BCP38. IPv6 could be an excellent opportunity to get this working.

[1] https://www.youtube.com/watch?v=gqGEMQveoqg

Best regards.


From rsk at gsp.org  Sat Sep  6 10:37:52 2014
From: rsk at gsp.org (Rich Kulawiec)
Date: Sat, 6 Sep 2014 06:37:52 -0400
Subject: no more "Send through Gmail" option
In-Reply-To: <CAN2EnhBQFHOKjKB=F-RwvnRbgdU67XUbENvdRVQALHjtzz=9=Q@mail.gmail.com>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
 <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
 <CAN2EnhBQFHOKjKB=F-RwvnRbgdU67XUbENvdRVQALHjtzz=9=Q@mail.gmail.com>
Message-ID: <20140906103752.GA18278@gsp.org>

On Fri, Sep 05, 2014 at 07:01:41PM -0400, ITechGeek wrote:
> As a replacement, you can use Amazon SES and verify single email addresses
> if you don't have access over the whole domain.

Not if you want people to accept your mail.  Thanks to Amazon's policy
of (a) allowing unlimited spam and (b) ignoring all abuse reports [1],
it's long since become a best practice to refuse all SMTP traffic from
amazonses.com, compute-1.amazonaws.com, compute.amazonaws.com and whatever
other subdomains they have/will have associated with that part of their
operation.

---rsk

[1] Which they don't make easy to file.  Instead of accepting reports at
abuse@, like every other responsible, professional, properly managed
operation, they force complainers to jump through hoops...in order
to file a complaint...which they studiously ignore.


From jared at puck.Nether.net  Sat Sep  6 16:40:08 2014
From: jared at puck.Nether.net (Jared Mauch)
Date: Sat, 6 Sep 2014 12:40:08 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <5409CB48.4080404@mykolab.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <522cbbf4-2d84-404f-808f-bb5889daf898@email.android.com>
 <5409CB48.4080404@mykolab.com>
Message-ID: <20140906164008.GA16093@puck.nether.net>

On Fri, Sep 05, 2014 at 07:40:08AM -0700, Paul Ferguson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 9/5/2014 7:35 AM, Jay Ashworth wrote:
> 
> > "Interface" sure.
> > 
> > But the dangers of replacing actual /addresses/ with things which
> > are not is sufficiently well understood that even Van Jacobson
> > ought to know about 'em, right? :-)
> > 
> 
> Compare & contrast: There is still large-scale resistance (for lack of
> a better term) to IPv6 deployment, so what chance does deployment of
> Named Data-Networking stand? :-)

	resistance [to ipv6] is futile - http://www.spreadshirt.com/-C3376A12786302

	I certainly don't think IPv6 will reach 100% deployment, people
will continue [to get paid?] to operate 6to4 and 4to6 gateways, even if just
enterprise edge from a nat44(+) gateways.

	I'm still waiting for a few orgs to make the IPv6 jump like
Wayport/attwifi as an example.  They could do nat66 like they do nat44
and easily make the sites look the same through their templates.

	If you assume most people are right and Netflix is 33% of the US
internet at peak, that's 33% that's fully ipv6 capable on the server-side.
facebook, google and others count up as well, so much of content is reachable.

	If apple/icloud make the jump to publishing AAAA records as part
of their CDN efforts to move away from akamai, I suspect much more of the
LTE traffic would make that jump to v6.  (Waiting to see ATT upgrade their LTE
to support v6 to match VZ).

	It also appears that OSX 10.10 fixes some of the IPv6 issues that exist
in 10.9, so with that update in the coming months I'm expecting even more IPv6
traffic to replace the IPv4 bits.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


From rubensk at gmail.com  Sat Sep  6 17:00:05 2014
From: rubensk at gmail.com (Rubens Kuhl)
Date: Sat, 6 Sep 2014 14:00:05 -0300
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <21514.210.949594.760636@world.std.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <21514.210.949594.760636@world.std.com>
Message-ID: <CAGFn2k3EhCrktpiFBbymJz9mZ=Jt4byzBkQtAaawp=Yrhn-Y8w@mail.gmail.com>

>
> There would be a root, or multiple roots, which would respond to
> requests to locate who should be asked about a domain, for example if
> you want to know the ip address for world.std.com the conversation
> goes roughly:
>
>    (To Root Server):       Where is the COM server?
>    (From Root Server):     SOMEHOST
>    (TO SOMEHOST):          Where is the STD.COM server?
>    (From SOMEHOST):        192.137.74.112
>    (TO 192.74.137.112):    WHAT IS WORLD.STD.COM's IP ADDRESS (A RECORD)?
>    (FROM 192.74.137.112):  192.74.137.5
>
> Not quite right. It actually goes like this on the wire:

    (To Root Server):       WHAT IS WORLD.STD.COM <http://world.std.com/>'s
IP ADDRESS (A RECORD)?
   (From Root Server):     I don't know, but SOMEHOST is the one to ask
about COM
   (TO SOMEHOST):       WHAT IS WORLD.STD.COM <http://world.std.com/>'s IP
ADDRESS (A RECORD)?
   (From SOMEHOST):     I don't know, but 192.74.137.112 is the one to ask
about STD.COM
   (TO 192.74.137.112):    WHAT IS WORLD.STD.COM <http://world.std.com/>'s
IP ADDRESS (A RECORD)?
   (FROM 192.74.137.112):  192.74.137.5

Or the DNSSEC option:

    (To Root Server):       WHAT IS WORLD.STD.COM <http://world.std.com/>'s
IP ADDRESS (A RECORD)?
   (From Root Server):     I don't know, but SOMEHOST is the one to ask
about COM, and you can trust SOMEONE if it signs with COM-Key. Signed with
ROOT-Key.
   (TO SOMEHOST):       WHAT IS WORLD.STD.COM <http://world.std.com/>'s IP
ADDRESS (A RECORD)?
   (From SOMEHOST):     I don't know, but 192.74.137.112 is the one to ask
about STD.COM, and and you can't tell whether you are really talking to
192.74.137.112  since it's not signed. Signed with COM-Key.
   (TO 192.74.137.112):    WHAT IS WORLD.STD.COM <http://world.std.com/>'s
IP ADDRESS (A RECORD)?
   (FROM 192.74.137.112):  192.74.137.5.


Rubens


From owen at delong.com  Sat Sep  6 17:31:02 2014
From: owen at delong.com (Owen DeLong)
Date: Sat, 6 Sep 2014 10:31:02 -0700
Subject: no more "Send through Gmail" option
In-Reply-To: <CAN2EnhBQFHOKjKB=F-RwvnRbgdU67XUbENvdRVQALHjtzz=9=Q@mail.gmail.com>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
 <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
 <CAN2EnhBQFHOKjKB=F-RwvnRbgdU67XUbENvdRVQALHjtzz=9=Q@mail.gmail.com>
Message-ID: <D556F285-F597-4519-8C0D-6AA357409C3F@delong.com>

You would also need to not care about sending email to IPv6 domains.

Owen

On Sep 5, 2014, at 16:01 , ITechGeek <itg at itechgeek.com> wrote:

> As a replacement, you can use Amazon SES and verify single email addresses
> if you don't have access over the whole domain.
> 
> -----------------------------------------------------------------------------------------------
> -ITG (ITechGeek)
> ITG at ITechGeek.Com
> https://itg.nu/
> GPG Keys: https://itg.nu/contact/gpg-key
> Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
> Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
> http://fb.me/Jbwa.Net
> 
> 
> On Fri, Sep 5, 2014 at 6:43 PM, Royce Williams <royce at techsolvency.com>
> wrote:
> 
>> On Fri, Sep 5, 2014 at 2:15 PM, Eduardo A. Su?rez
>> <esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote:
>>> 
>>> Hi,
>>> 
>>> according to this thread:
>>> 
>>> 
>> https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D
>>> 
>>> Gmail isn't allowing anymore "Send through Gmail" option.
>> 
>> Yep. Existing email-address setups are grandfathered, but no new ones
>> can be added via the UI.
>> 
>> It's probably a mix of "let's support the ecosystem by only sending
>> mail from servers authorized by the domain holder" and "let's sell
>> more Google for Work email hosting".
>> 
>> If it really was more the former, there would be a "if your SPF
>> records include:_spf.google.com, you can still do it" option, IMO.
>> 
>> Royce
>> 



From me at anuragbhatia.com  Sat Sep  6 19:54:46 2014
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Sun, 7 Sep 2014 01:24:46 +0530
Subject: Per policy session cap on Juniper SRX
Message-ID: <CAJ0+aXbXZ2f-Z5mR_TXEu3m=5ZdRe-3cTcDkp3KYvE+eBOAobA@mail.gmail.com>

Hello everyone!


I have a Juniper SRX firewall and in recent times I did had issues because
one or other user doing an attack outside. Usually it is compromised client
machines which create a lot of firewall sessions in outside direction.


I was thinking of two specific things as fix for this:


   1. Can I somehow put a cap per security policy so that all available
   sessions aren't chewed by clients?

   2. We have very few clients who actually use firewall in outbound, rest
   all in inbound. This I wish to skip firewall in outbound but in my test I
   found it behaves strange. I tried with machine having inbound traffic via
   firewall. They ping and port 80 also worked but SSH just hung up as soon as
   I started. I see SRX can be used in unidirectional setup but somehow it
   fails in my case.



Any suggestions/advice/ sample configs?


Thanks in advance!

-- 


Anurag Bhatia
anuragbhatia.com

Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter
<https://twitter.com/anurag_bhatia>
Skype: anuragbhatia.com

PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2


From m.waehlisch at fu-berlin.de  Fri Sep  5 20:42:43 2014
From: m.waehlisch at fu-berlin.de (Matthias Waehlisch)
Date: Fri, 5 Sep 2014 22:42:43 +0200
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <alpine.WNT.2.00.1409052230440.9936@mw-PC>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <74B09FDD-D097-494A-8E9D-C5CB17DC4D51@steffann.nl>
 <alpine.WNT.2.00.1409052230440.9936@mw-PC>
Message-ID: <alpine.WNT.2.00.1409052242270.9936@mw-PC>


On Fri, 5 Sep 2014, Sander Steffann wrote:

> Well, you don't need addresses for clients, just for content... From 
> the architecture page at http://named-data.net/project/archoverview/:
>
> "Note that neither Interest nor Data packets carry any host or 
> interface addresses (such as IP addresses); Interest packets are 
> routed towards data producers based on the names carried in the 
> Interest packets, and Data packets are returned based on the state 
> information set up by the Interests at each router hop."
>
> So it's basically suggesting a NAT-like table in every single router.
> And we all know how well NAT boxes scale...
>
  the pending interest table is more similar to multicast routing table,
which is maintained by end user subscriptions -- still challenging wrt
to scalability.


Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net


From mohta at necom830.hpcl.titech.ac.jp  Sun Sep  7 02:11:36 2014
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 07 Sep 2014 11:11:36 +0900
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <21514.210.949594.760636@world.std.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com> <21514.210.949594.760636@world.std.com>
Message-ID: <540BBED8.8000307@necom830.hpcl.titech.ac.jp>

Barry Shein wrote:

> The idea is very simple, each site would be responsible for their own
> domain and to respond to simple remote requests for name to ip address
> mappings or back again.

Wrong. DNS is not that simple.

Domains and sites have, in general, independent topology
that sites can not be responsible for domains.

Perhaps, your misunderstanding is commonly shared by those
who believe in NDN, though they might think there are
negligible number of exceptions.

Then, data, mostly, could be routed based on name hierarchy,
which scales well.

The reality, however, is that exceptions are everywhere
and we need something like DNS to translate names into
something scalably routable, that is, hierarchical
addresses.

						Masataka Ohta



From fergdawgster at mykolab.com  Sun Sep  7 15:33:02 2014
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Sun, 07 Sep 2014 08:33:02 -0700
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <1410082125488.85722@surrey.ac.uk>
References: <1410082125488.85722@surrey.ac.uk>
Message-ID: <540C7AAE.7060400@mykolab.com>

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

There's been a lot of on-and-off discussion about v6, especially about
security and operational concerns about some aspects of IPv6
deployment, specifically regarding neighbor discovery (although there
are other operational security concerns, as well).

I'd like to provide this as an example of those concerns, without any
additional commentary. :-)

See also:

http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html

Cheers,

- - ferg



- -------- Forwarded Message --------
Subject: Interesting problems with using IPv6
Date: Sun, 7 Sep 2014 09:28:45 +0000
From: l.wood at surrey.ac.uk
To: ietf at ietf.org

http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/

Interesting scaling concerns...

Lloyd Wood
http://about.me/lloydwood

[end]


- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlQMeq4ACgkQKJasdVTchbJVuAD/d8qvCrOAr9UswM+9YQaOyTNQ
btFUX/1sRImNCcqkIpkA/RdQUhLE5TkmSlULZZ6A5wgsLDE8byukz8O318715kW+
=chES
-----END PGP SIGNATURE-----


From bzs at world.std.com  Sun Sep  7 16:24:02 2014
From: bzs at world.std.com (Barry Shein)
Date: Sun, 7 Sep 2014 12:24:02 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <540BBED8.8000307@necom830.hpcl.titech.ac.jp>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <21514.210.949594.760636@world.std.com>
 <540BBED8.8000307@necom830.hpcl.titech.ac.jp>
Message-ID: <21516.34466.439880.900138@world.std.com>


Understand these were speaking notes and it was safe to assume the
audience basically understood DNS so it wasn't my intention to give an
exhaustive introduction to how DNS works.

There also seems to be some splitting of hairs over the meaning of
"site" in your response. That is, some sort of physical boundary vs an
authoritative boundary.

At any rate my proposal doesn't eliminate hierarchical addresses, it
just says (in brief) that "bits is bits" and IP numeric addresses per
se were mostly a product of modeling fast CPU registers which may not
be the only model. One could use the FQDNs themselves as hierarchical
addresses at least as an external representation.

It was intended to be a provocative proposal.


On September 7, 2014 at 11:11 mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) wrote:
 > Barry Shein wrote:
 > 
 > > The idea is very simple, each site would be responsible for their own
 > > domain and to respond to simple remote requests for name to ip address
 > > mappings or back again.
 > 
 > Wrong. DNS is not that simple.
 > 
 > Domains and sites have, in general, independent topology
 > that sites can not be responsible for domains.
 > 
 > Perhaps, your misunderstanding is commonly shared by those
 > who believe in NDN, though they might think there are
 > negligible number of exceptions.
 > 
 > Then, data, mostly, could be routed based on name hierarchy,
 > which scales well.
 > 
 > The reality, however, is that exceptions are everywhere
 > and we need something like DNS to translate names into
 > something scalably routable, that is, hierarchical
 > addresses.
 > 
 > 						Masataka Ohta

-- 
        -Barry Shein

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


From cb.list6 at gmail.com  Sun Sep  7 17:13:57 2014
From: cb.list6 at gmail.com (Ca By)
Date: Sun, 7 Sep 2014 10:13:57 -0700
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <540C7AAE.7060400@mykolab.com>
References: <1410082125488.85722@surrey.ac.uk> <540C7AAE.7060400@mykolab.com>
Message-ID: <CAD6AjGSDiwW9ovcTQC1rvpT1LVQs_T4Of9Af5tVj2wYZNCwqug@mail.gmail.com>

On Sep 7, 2014 8:35 AM, "Paul Ferguson" <fergdawgster at mykolab.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> There's been a lot of on-and-off discussion about v6, especially about
> security and operational concerns about some aspects of IPv6
> deployment, specifically regarding neighbor discovery (although there
> are other operational security concerns, as well).
>
> I'd like to provide this as an example of those concerns, without any
> additional commentary. :-)
>
> See also:
>
> http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html
>

ietf at ... Yawn.

> Cheers,
>
> - - ferg
>
>

Ferg,

What's your point? Is it that ip networks fail?

There are decades of mailing lists archives at nanog and others that have
the same thing -- 1) stressed out ops guy 2) buggy code (tac says need to
load latest code as first step)  3) L2 mess -- most of those examples of
epic failure are ipv4 related, but many are just ethernet fails.

If your point is that IPv6 cannot be deployed at scale, i have a list of
meaningful counter examples where in fact it does work.

And as already mention, the mailing list archive at nanog and others is
full of folks with poor design or gear.

There are various docs that try to help folks deploy networks well.

https://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-06

CB

>
> - -------- Forwarded Message --------
> Subject: Interesting problems with using IPv6
> Date: Sun, 7 Sep 2014 09:28:45 +0000
> From: l.wood at surrey.ac.uk
> To: ietf at ietf.org
>
>
http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
>
> Interesting scaling concerns...
>
> Lloyd Wood
> http://about.me/lloydwood
>
> [end]
>
>
> - --
> Paul Ferguson
> VP Threat Intelligence, IID
> PGP Public Key ID: 0x54DC85B2
> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iF4EAREIAAYFAlQMeq4ACgkQKJasdVTchbJVuAD/d8qvCrOAr9UswM+9YQaOyTNQ
> btFUX/1sRImNCcqkIpkA/RdQUhLE5TkmSlULZZ6A5wgsLDE8byukz8O318715kW+
> =chES
> -----END PGP SIGNATURE-----


From sthaug at nethelp.no  Sun Sep  7 19:02:56 2014
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sun, 07 Sep 2014 21:02:56 +0200 (CEST)
Subject: Interesting problems with using IPv6
In-Reply-To: <CAD6AjGSDiwW9ovcTQC1rvpT1LVQs_T4Of9Af5tVj2wYZNCwqug@mail.gmail.com>
References: <1410082125488.85722@surrey.ac.uk> <540C7AAE.7060400@mykolab.com>
 <CAD6AjGSDiwW9ovcTQC1rvpT1LVQs_T4Of9Af5tVj2wYZNCwqug@mail.gmail.com>
Message-ID: <20140907.210256.74681304.sthaug@nethelp.no>

> There are decades of mailing lists archives at nanog and others that have
> the same thing -- 1) stressed out ops guy 2) buggy code (tac says need to
> load latest code as first step)  3) L2 mess -- most of those examples of
> epic failure are ipv4 related, but many are just ethernet fails.
> 
> If your point is that IPv6 cannot be deployed at scale, i have a list of
> meaningful counter examples where in fact it does work.
> 
> And as already mention, the mailing list archive at nanog and others is
> full of folks with poor design or gear.

Did you actually read the whole story? Did you read Jeff Wheeler's 
presentation, referenced in the comment?

http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf

Steinar Haug, AS 2116


From surfer at mauigateway.com  Sun Sep  7 19:17:18 2014
From: surfer at mauigateway.com (Scott Weeks)
Date: Sun, 7 Sep 2014 12:17:18 -0700
Subject: Fwd: Interesting problems with using IPv6
Message-ID: <20140907121718.43C44FB1@m0005298.ppops.net>



--- fergdawgster at mykolab.com wrote:
From: Paul Ferguson <fergdawgster at mykolab.com>

There's been a lot of on-and-off discussion about v6, 
especially about security and operational concerns 
about some aspects of IPv6 deployment, specifically 
regarding neighbor discovery (although there are other 
operational security concerns, as well).

I'd like to provide this as an example of those 
concerns, without any additional commentary. :-)

See also:

http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html
--------------------------------------------------


I read the article and Tim Warnock on ipv6.org.au gave 
a pretty good and very brief summary.  Pasted here for
those that don't have time to read it.  :-)

"large L2 domain + ipv6 windows privacy extensions + some 
intel card bug + some mention of igmp snooping = multicast 
flood w/ high switch/router cpu..."

Of course it's worth reading and there is a lot more to 
the post...

scott


From mohta at necom830.hpcl.titech.ac.jp  Sun Sep  7 22:37:27 2014
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 08 Sep 2014 07:37:27 +0900
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <21516.34466.439880.900138@world.std.com>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>	<5409C846.3020307@mykolab.com>	<21514.210.949594.760636@world.std.com>	<540BBED8.8000307@necom830.hpcl.titech.ac.jp>
 <21516.34466.439880.900138@world.std.com>
Message-ID: <540CDE27.7070300@necom830.hpcl.titech.ac.jp>

Barry Shein wrote:

> Understand these were speaking notes and it was safe to assume the
> audience basically understood DNS so it wasn't my intention to give an
> exhaustive introduction to how DNS works.

Surprisingly many people who basically understand DNS have the
same misunderstanding as you, which is why some people believe
in NDN.

> There also seems to be some splitting of hairs over the meaning of
> "site" in your response. That is, some sort of physical boundary vs an
> authoritative boundary.

Then, "site" based FQDN can not be used for scalable routing.

> At any rate my proposal doesn't eliminate hierarchical addresses,

See above.

> One could use the FQDNs themselves as hierarchical
> addresses at least as an external representation.

You are trying to define something not usable for scalable
routing a hierarchical address, which is as bad as your
attempt to distort the definition of "site".

						Masataka Ohta



From david at mailplus.nl  Mon Sep  8 07:23:13 2014
From: david at mailplus.nl (David Hofstee)
Date: Mon, 8 Sep 2014 09:23:13 +0200
Subject: no more "Send through Gmail" option
In-Reply-To: <CA+E3k91f0bVb0FRWxykoJzPUEk1tRj=DW2_Bkh7tD-c+4VARyQ@mail.gmail.com>
References: <20140905191540.695xijfgiswkgwg8@fcaglp.fcaglp.unlp.edu.ar>
 <CA+E3k91amZGcU-Yhjvt-=8DcXQDhFfrAQaCSDWEB23dS76rcEg@mail.gmail.com>
 <20140905230153.GJ27158@bamboo.slabnet.com>
 <CA+E3k91f0bVb0FRWxykoJzPUEk1tRj=DW2_Bkh7tD-c+4VARyQ@mail.gmail.com>
Message-ID: <78C35D6C1A82D243B830523B4193CF5F75C0C7A3A5@SBS1.blinker.local>

It is Google's problem. Because they need to check every time, before sending, if they are allowed to send emails. Otherwise they would/could be spamming (depends on your favorite definition of spam). 


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

-----Oorspronkelijk bericht-----
Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Royce Williams
Verzonden: Saturday, September 6, 2014 1:27 AM
Aan: Hugo Slabbert
CC: NANOG
Onderwerp: Re: no more "Send through Gmail" option

On Fri, Sep 5, 2014 at 3:01 PM, Hugo Slabbert <hugo at slabnet.com> wrote:
>> If it really was more the former, there would be a "if your SPF 
>> records include:_spf.google.com, you can still do it" option, IMO.
>
...
> Manager: Works for me.

The scenario largely rings true, except that I would think it reasonable to tell people that it if it breaks because they added DKIM, it's not Google's problem to fix.
...

From dwcarder at wisc.edu  Mon Sep  8 15:08:44 2014
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Mon, 08 Sep 2014 10:08:44 -0500
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <20140907121718.43C44FB1@m0005298.ppops.net>
References: <20140907121718.43C44FB1@m0005298.ppops.net>
Message-ID: <20140908150843.GA89235@ricotta.doit.wisc.edu>

Thus spake Scott Weeks (surfer at mauigateway.com) on Sun, Sep 07, 2014 at 12:17:18PM -0700:
> --- fergdawgster at mykolab.com wrote:
> From: Paul Ferguson <fergdawgster at mykolab.com>
> 
> There's been a lot of on-and-off discussion about v6, 
> especially about security and operational concerns 
> about some aspects of IPv6 deployment, specifically 
> regarding neighbor discovery (although there are other 
> operational security concerns, as well).
> 
> I'd like to provide this as an example of those 
> concerns, without any additional commentary. :-)
> 
> See also:
> 
> http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html
> --------------------------------------------------
> 
> 
> I read the article and Tim Warnock on ipv6.org.au gave 
> a pretty good and very brief summary.  Pasted here for
> those that don't have time to read it.  :-)
> 
> "large L2 domain + ipv6 windows privacy extensions + some 
> intel card bug + some mention of igmp snooping = multicast 
> flood w/ high switch/router cpu..."


This is well known. see: draft-pashby-magma-simplify-mld-snooping-01

About 4-5 years ago there was CSCtl51859.

Vendor implementations that treat v6 neighbor discovery like it's IGMPv2
are doomed to fail.

Dale


From johnl at iecc.com  Mon Sep  8 15:24:24 2014
From: johnl at iecc.com (John Levine)
Date: 8 Sep 2014 15:24:24 -0000
Subject: no more "Send through Gmail" option
In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75C0C7A3A5@SBS1.blinker.local>
Message-ID: <20140908152424.21805.qmail@joyce.lan>


>It is Google's problem. Because they need to check every time, before sending, if they
>are allowed to send emails. Otherwise they would/could be spamming (depends on your
>favorite definition of spam).

Sort of.  This is related to the great DMARC debacle earlier this
year, in which Yahoo and AOL took a reasonable anti-phishing tool and
repurposed it to sort of close the barn door after each had separate
huge thefts of user credentials and address books, with horrible
consequences to mailing lists and legitimate third party mailers.

For more details, see http://jl.ly/Email/aoldmarc.html

R's,
John


From bzs at world.std.com  Mon Sep  8 17:28:09 2014
From: bzs at world.std.com (Barry Shein)
Date: Mon, 8 Sep 2014 13:28:09 -0400
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <20140907121718.43C44FB1@m0005298.ppops.net>
References: <20140907121718.43C44FB1@m0005298.ppops.net>
Message-ID: <21517.59177.373564.333891@world.std.com>


Reading the article what occurs to me is:

IPv4 requires a certain amount of administrative personnel overhead.

It's relatively low which is certainly one reason for the success of
IPv4. People are expensive so any new, pervasive technology will be
judged at least in part on its personnel requirements.

I'd go so far as to say that administering large IPv4 networks grows
in personnel roughly as the log of the number of nodes.

If what this is telling us, or warning us, is that IPv6 networks
require higher personnel costs then that could become a big issue.

Particularly among management where they've become used to a few to
several people in a team running the heart of quite large networks.

What if IPv6 deployment doubles or triples that personnel requirement
for the same quality of administration?

Does anyone know of any studies along these lines? My guess is that
there isn't enough data yet.

-- 
        -Barry Shein

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


From bzs at world.std.com  Mon Sep  8 17:41:44 2014
From: bzs at world.std.com (Barry Shein)
Date: Mon, 8 Sep 2014 13:41:44 -0400
Subject: The Next Big Thing: Named-Data Networking
In-Reply-To: <540CDE27.7070300@necom830.hpcl.titech.ac.jp>
References: <10848755.196.1409926560055.JavaMail.root@benjamin.baylink.com>
 <5409C846.3020307@mykolab.com>
 <21514.210.949594.760636@world.std.com>
 <540BBED8.8000307@necom830.hpcl.titech.ac.jp>
 <21516.34466.439880.900138@world.std.com>
 <540CDE27.7070300@necom830.hpcl.titech.ac.jp>
Message-ID: <21517.59992.781819.854054@world.std.com>


Well, it's a good thing we have you around to keep us honest.


On September 8, 2014 at 07:37 mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) wrote:
 > Barry Shein wrote:
 > 
 > > Understand these were speaking notes and it was safe to assume the
 > > audience basically understood DNS so it wasn't my intention to give an
 > > exhaustive introduction to how DNS works.
 > 
 > Surprisingly many people who basically understand DNS have the
 > same misunderstanding as you, which is why some people believe
 > in NDN.
 > 
 > > There also seems to be some splitting of hairs over the meaning of
 > > "site" in your response. That is, some sort of physical boundary vs an
 > > authoritative boundary.
 > 
 > Then, "site" based FQDN can not be used for scalable routing.
 > 
 > > At any rate my proposal doesn't eliminate hierarchical addresses,
 > 
 > See above.
 > 
 > > One could use the FQDNs themselves as hierarchical
 > > addresses at least as an external representation.
 > 
 > You are trying to define something not usable for scalable
 > routing a hierarchical address, which is as bad as your
 > attempt to distort the definition of "site".
 > 
 > 						Masataka Ohta

-- 
        -Barry Shein

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


From morrowc.lists at gmail.com  Mon Sep  8 18:30:00 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 8 Sep 2014 14:30:00 -0400
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <21517.59177.373564.333891@world.std.com>
References: <20140907121718.43C44FB1@m0005298.ppops.net>
 <21517.59177.373564.333891@world.std.com>
Message-ID: <CAL9jLaZXN4Tsr+1iktzVqM7AQSorbvvgBkHK8QP_P2GWF-UsDA@mail.gmail.com>

On Mon, Sep 8, 2014 at 1:28 PM, Barry Shein <bzs at world.std.com> wrote:
>
> Reading the article what occurs to me is:
>
> IPv4 requires a certain amount of administrative personnel overhead.
>
> It's relatively low which is certainly one reason for the success of
> IPv4. People are expensive so any new, pervasive technology will be
> judged at least in part on its personnel requirements.
>
> I'd go so far as to say that administering large IPv4 networks grows
> in personnel roughly as the log of the number of nodes.

surely this depends a LOT on the quality of the folk doing this job
and their foresight in automating as much as possible, no? (probably
this point isn't for debate, but the point is any network can be run
badly)

> If what this is telling us, or warning us, is that IPv6 networks
> require higher personnel costs then that could become a big issue.

is this a reflection of 'new technology' to the users (network folk)
in question?
What in ipv6 networking is inherently 'more people required' than ipv4
networking?

>
> Particularly among management where they've become used to a few to
> several people in a team running the heart of quite large networks.
>
> What if IPv6 deployment doubles or triples that personnel requirement
> for the same quality of administration?

this sounds, to me, like: "People need training or comfort with :
instead of . in 'ip address' stuff..." (and other similar differences
between how v4 and v6 operate at scale)

> Does anyone know of any studies along these lines? My guess is that
> there isn't enough data yet.

that sounds reasonable.


From koalafil at gmail.com  Tue Sep  9 11:34:11 2014
From: koalafil at gmail.com (Filiz Yilmaz)
Date: Tue, 9 Sep 2014 13:34:11 +0200
Subject: Call for Presentations RIPE 69
In-Reply-To: <CAHWoQeNanAiWEo7mu_2KP9F8pP1gU+st4uKr7QnggnHgeGJaQQ@mail.gmail.com>
References: <CAHWoQeP5Br_Lk5LRKj4nQR-Wzb3P90y1_w4wrdjhotW7D=0zGA@mail.gmail.com>
 <CAHWoQeNanAiWEo7mu_2KP9F8pP1gU+st4uKr7QnggnHgeGJaQQ@mail.gmail.com>
Message-ID: <CAHWoQePCaBdfVeSknTU=cBWmrpi2LBtDDcH8SZ3f0YPDof83FA@mail.gmail.com>

Dear all,

As announced earlier, Draft RIPE Plenary programme is now published at:

https://ripe69.ripe.net/programme/meeting-plan/plenary/

For the remaining slots, we will continue accepting new proposals until 1
October 2014.

Kind regards

Filiz Yilmaz
RIPE PC Chair


On Fri, Sep 5, 2014 at 4:06 PM, Filiz Yilmaz <koalafil at gmail.com> wrote:

> Dear colleagues,
>
> Following the past submission deadline here is an update from the RIPE PC:
>
>
> A list of currently accepted RIPE 69 presentations will be published next
> week and a separate note will be sent to the ripe-list once this is out.
>
> There are still slots remaining for the final RIPE 69 programme and RIPE
> Programme Committee will accept new proposals until 1 October 2014.
>
> This is a last call deadline if you wish to submit a proposal.
>
> Kind regards
>
> Filiz Yilmaz
> RIPE PC Chair
>
>
>
>
>
> On Wed, Jun 11, 2014 at 5:48 PM, Filiz Yilmaz <koalafil at gmail.com> wrote:
>
>> Dear colleagues,
>>
>> Please find the CFP for RIPE 69 in London below.
>>
>> The deadline for submissions is 31 August 2014.
>>
>> Please also note that speakers do not receive any extra reduction or
>> funding towards the meeting fee at the RIPE Meetings.
>>
>> Kind regards
>>
>> Filiz Yilmaz
>> RIPE PC Chair
>> http://www.ripe.net/ripe/meetings/ripe-meetings/pc
>>
>>
>> ---------------------
>>
>> Call for Presentations
>>
>> 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 69 will take place from 3- November 2014 in London, UK.
>>
>> The RIPE Programme Committee (PC) is now seeking content proposals from
>> the RIPE community for the plenary session presentations, BoFs (Birds of a
>> Feather sessions), panels, workshops, tutorials and lightning talks at RIPE
>> 69. 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 centre technologies
>> ? Network and DNS operations
>> ? Internet governance and regulatory practices
>>  ? Network and routing security
>> ? Content delivery
>> ? Internet peering and mobile data exchange
>>
>> Submissions
>>
>> RIPE Meeting attendees 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.
>>
>> The RIPE PC accepts proposals for different presentation formats,
>> including plenary session presentations, tutorials, workshops, BoFs (Birds
>> of a Feather sessions) and lightning talks. See the full descriptions of
>> these formats at
>> https://ripe69.ripe.net/submit-topic/presentation-formats/
>>
>> 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 general requirements apply:
>>
>> - Proposals for plenary session presentations, BoFs, panels, workshops
>> and tutorials must be submitted for full consideration no later than 31
>> August 2014, using the meeting submission system at
>> https://ripe69.ripe.net/submit-topic/guidelines/. Proposals submitted
>> after this date will be considered on a space-available basis.
>>
>> -  Lightning talks should also be submitted using the meeting submission
>> system (https://ripe69.ripe.net/submit-topic/submission-form/) and can
>> be submitted just days before the RIPE Meeting starts or even during the
>> meeting week. The allocation of lightning talk slots will be announced in
>> short notice ? in some cases on the same day but often one day prior to the
>> relevant session.
>>
>> - Presenters should indicate how much time they will require.
>> See more information on time slot allocations per presentation format at
>> https://ripe69.ripe.net/submit-topic/presentation-formats/
>>
>> - 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
>> panels, proposals must contain a clear description, as well as the names of
>> invited panelists, presenters and moderators.
>>
>> - Due to potential technical issues, it is expected that most, if not
>> all, presenters/panelists will be physically present at the RIPE Meeting.
>>
>> If you have any questions or requests concerning content submissions,
>> please email pc [at] ripe [dot] net.
>>
>> ---------------------
>>
>
>


From rubensk at gmail.com  Tue Sep  9 15:24:08 2014
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 9 Sep 2014 12:24:08 -0300
Subject: Akamai DNS off-line contact
Message-ID: <CAGFn2k0rMVpS8XRxHhV=LOnTjvt=0OVhV0H0goHhz3RFXvTKKA@mail.gmail.com>

We are seeing a high profile DNS zone hosted at Akamai with DNSSEC
algorithm mismatch (KSK is algorithm 7, ZSK is algorithm 8).

If someone could contact me off-list...


Rubens


From betty at newnog.org  Tue Sep  9 16:17:29 2014
From: betty at newnog.org (Betty Burke <betty@nanog.org>)
Date: Tue, 9 Sep 2014 11:17:29 -0500
Subject: [NANOG-announce] NANOG 62 Highlights
Message-ID: <CABhExixwhg=9nAZHtyyasNfSuU4_EKJEq4OREU2tDt1K1YqFtg@mail.gmail.com>

NANOGers:

A few details and updates regarding our activities in Baltimore, October
5-8, 2014

NANOG Highlights
<https://www.nanog.org/meetings/nanog62/agendahighlights> information
is now available.  We have updates to the Agenda Topics
<https://www.nanog.org/meetings/nanog62/preagenda>, information on Socials,
and update on Sponsorship activity.

Candidate information regarding NANOG Elections
<https://www.nanog.org/governance/elections/2014> has also been updated.

Baltimore Education Series
<https://www.nanog.org/meetings/education/home> Registration
through October 5, 2014 is open for non-member $300, member $275.

NANOG 62, be sure to make your Registration
<https://www.nanog.org/meetings/nanog62/registration>.  The fee increase
dates are noted below:

   - Early Bird Registration through September 14, 2014 (non-member $450,
   member $425, student $100)
   - Standard Registration starting September 15, 2014 (non-member $525,
   member $500, student $100)
   - Late Registration starting September 29, 2014 (non-member $600, member
   $575, student $100)

Make your hotel reservations soon.  We have added 2 additional hotel room
blocks to accommodate your trip to Baltimore. Note the NANOG rate at each
will expire soon.

   - Hyatt Regency Baltimore
   - Room Rate:  $199 single/double, plus taxes
      - Group Rate Expires:  Thursday, September 18, 2014
      - Reservations:   Please call 1-800-233-1234 or +1-410-528-1234 for
      hotel reservations and state that you will be attending NANOG 62 or click
      here
      <https://resweb.passkey.com/Resweb.do?mode=welcome_ei_new&eventID=10381224>for
      online reservations
   - Hilton Baltimore
   - Room Rate:  $199 single/double, plus taxes
      - Group Rate Expires:  Sunday, September 21, 2014
      - Reservations:   Please call 1-800-445-8667 for hotel reservations
      and please mention the NANOG group, or click here
      <https://aws.passkey.com/g/32199126> for online reservations
   - Sheraton Inner Harbor Hotel
   - Room Rate:  $189 single/double, plus taxes
      - Group Rate Expires:  Wednesday, September 17, 2014
      - Reservations:  Please call 1-866-715-0006 or +1-410-962-8300 for
      hotel reservations and state that you will be attending NANOG 62 or click
      here
      <https://www.starwoodmeeting.com/StarGroupsWeb/booking/reservation?id=1404016802&key=1FB3041A>
for
      online reservations

NANOG 62 Fellowships <https://www.nanog.org/resources/fellowships> and
Sponsorships <https://www.nanog.org/sponsors/opportunities> are also
available.  Do not delay, take advantage of these opportunities, as they
will close shortly.

We are fast approaching the final weeks of NANOG 62 preparations, should
you have any questions, please send them to nanog-support at nanog.org.


All best,
Betty
-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Tel: +1 510 492 4030
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From tarko at lanparty.ee  Wed Sep 10 11:20:45 2014
From: tarko at lanparty.ee (Tarko Tikan)
Date: Wed, 10 Sep 2014 14:20:45 +0300
Subject: 2000::/6
Message-ID: <5410340D.2010007@lanparty.ee>

hey,

2000::/6 with aspath 3257 3549 has appeared in global routing table. 
Surely we can't be only ones seeing it. Looks like someone messed up 
interface/route config at 3549 by omitting 4 from the prefixlen.

According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
"2000::/6 is visible by 79% of 92 IPv6 RIS full peers."

-- 
tarko


From ahebert at pubnix.net  Wed Sep 10 12:33:15 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Wed, 10 Sep 2014 08:33:15 -0400
Subject: 2000::/6
In-Reply-To: <5410340D.2010007@lanparty.ee>
References: <5410340D.2010007@lanparty.ee>
Message-ID: <5410450B.8000207@pubnix.net>

    As of 8h30m EST.

*>i 2000::/6           <ipv6 peer>    100    100        0      3257 3549 i
       Last update to IP routing table: 21h23m56s

-----
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 09/10/14 07:20, Tarko Tikan wrote:
> hey,
>
> 2000::/6 with aspath 3257 3549 has appeared in global routing table.
> Surely we can't be only ones seeing it. Looks like someone messed up
> interface/route config at 3549 by omitting 4 from the prefixlen.
>
> According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
> "2000::/6 is visible by 79% of 92 IPv6 RIS full peers."
>



From wp at null0.nl  Wed Sep 10 12:42:21 2014
From: wp at null0.nl (Wouter Prins)
Date: Wed, 10 Sep 2014 14:42:21 +0200
Subject: 2000::/6
In-Reply-To: <5410450B.8000207@pubnix.net>
References: <5410340D.2010007@lanparty.ee>
	<5410450B.8000207@pubnix.net>
Message-ID: <CAHMVi8=JiawwgcgwwNSQTEi6f1CSEUaoPhpdW4yrtabY1nNuzw@mail.gmail.com>

Hi,

::/24 is also present:   AS-PATH 8455 13030 9498 7602

Mailed the tech-c 2 weeks ago, no response so far.

On 10 September 2014 14:33, Alain Hebert <ahebert at pubnix.net> wrote:

>     As of 8h30m EST.
>
> *>i 2000::/6           <ipv6 peer>    100    100        0      3257 3549 i
>        Last update to IP routing table: 21h23m56s
>
> -----
> 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 09/10/14 07:20, Tarko Tikan wrote:
> > hey,
> >
> > 2000::/6 with aspath 3257 3549 has appeared in global routing table.
> > Surely we can't be only ones seeing it. Looks like someone messed up
> > interface/route config at 3549 by omitting 4 from the prefixlen.
> >
> > According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
> > "2000::/6 is visible by 79% of 92 IPv6 RIS full peers."
> >
>
>


-- 
Wouter Prins
wp at null0.nl


From job at instituut.net  Wed Sep 10 16:16:43 2014
From: job at instituut.net (Job Snijders)
Date: Wed, 10 Sep 2014 18:16:43 +0200
Subject: 2000::/6
In-Reply-To: <5410340D.2010007@lanparty.ee>
References: <5410340D.2010007@lanparty.ee>
Message-ID: <20140910161643.GP53723@Vurt.local>

On Wed, Sep 10, 2014 at 02:20:45PM +0300, Tarko Tikan wrote:
> 2000::/6 with aspath 3257 3549 has appeared in global routing table. Surely
> we can't be only ones seeing it. Looks like someone messed up
> interface/route config at 3549 by omitting 4 from the prefixlen.
> 
> According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
> "2000::/6 is visible by 79% of 92 IPv6 RIS full peers."

This problem has been solved.

Kind regards,

Job


From jra at baylink.com  Wed Sep 10 17:26:09 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 10 Sep 2014 13:26:09 -0400 (EDT)
Subject: [outages] Verizon fiber ring down in LA
In-Reply-To: <2101655215.9737200.1410368856461.JavaMail.root@impulse.net>
Message-ID: <23230090.1022.1410369969504.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Owen Roth via Outages" <outages at outages.org>

> Is anyone else being impacted or have more information about a Verizon
> fiber ring repair in LA that went south yesterday afternoon? A
> client's fiber is STILL down more than 16 hours later, and the only
> information I have is that it is a configuration/provisioning issue
> with no ETR!
> 
> This is new ground -- I have never an outage of this type, and rarely
> of this duration. Any further information is appreciated.

This is the first I've seen of this here or on NANOG; what was your source
for the outage reason you mention?  (Assuming you can say. :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From mkamal at noor.net  Wed Sep 10 18:41:29 2014
From: mkamal at noor.net (Mohamed Kamal)
Date: Wed, 10 Sep 2014 20:41:29 +0200 (EET)
Subject: CEF problem - Traffic forwarding
In-Reply-To: <1834275486.12369853.1410374130493.JavaMail.zimbra@noor.net>
Message-ID: <1799777542.12370051.1410374489186.JavaMail.zimbra@noor.net>

Hello, 

I have a very strange problem on my ASR-1006 BRAS router. 

This router is having two equal paths toward a P router via IS-IS. The BRAS is seeing the P router over the two paths and the two paths are installed in the RIB and FIB as follows:

bng.rams.ca.asr1#sh ip cef 10.10.10.141 internal 

10.10.10.141/32, epoch 3, RIB[I], refcount 6, per-longest-match-prefix sharing
  sources: RIB, LTE 
  feature space:
   IPRM: 0x00028000
   Broker: linked, distributed at 1st priority
   LFD: 10.10.10.141/32 1 local label
   local label info: global/592
        contains path extension list
        disposition chain 0x7FCE5CB8C440
        label switch chain 0x7FCE5CB82FC0
  ifnums:
   GigabitEthernet0/0/0(8): 172.17.11.9
   GigabitEthernet1/0/0(24): 172.17.11.17
  path 7FCE67248388, path list 7FCE5FF51A40, share 1/1, type attached nexthop, for IPv4
    MPLS short path extensions: MOI flags = 0x0 label implicit-null
  nexthop 172.17.11.9 GigabitEthernet0/0/0, adjacency IP adj out of GigabitEthernet0/0/0, addr 172.17.11.9 7FCE5C406958
  path 7FCE6724B5B8, path list 7FCE5FF51A40, share 1/1, type attached nexthop, for IPv4
    MPLS short path extensions: MOI flags = 0x0 label implicit-null
  nexthop 172.17.11.17 GigabitEthernet1/0/0, adjacency IP adj out of GigabitEthernet1/0/0, addr 172.17.11.17 7FCE5079A540
  output chain: IP adj out of GigabitEthernet0/0/0, addr 172.17.11.9 7FCE5C406958

The problem is, CEF is seeing the two paths equal, but the output chain is only having one exit interface and the traffic is traversing this interface only!

This is the interface config:

bng.rams.ca.asr1#sh run all | sec 0/0/0
interface GigabitEthernet0/0/0
 description "Connected to p1 router"
 mtu 1600
 ip address 172.17.11.10 255.255.255.252
 ip redirects
 ip unreachables
 ip proxy-arp
 ip mtu 1600
 no ip load-sharing per-longest-match-prefix
 ip cef accounting non-recursive internal
 ip router isis
 ip flow monitor adsl input
 ip flow monitor adsl output
 ip pim dr-priority 1
 ip pim query-interval 30
 ip mfib forwarding input
 ip mfib forwarding output
 ip mfib cef input
 ip mfib cef output
 ip route-cache cef
 ip route-cache
 ip split-horizon
 ip igmp last-member-query-interval 1000
 ip igmp last-member-query-count 2
 ip igmp query-max-response-time 10
 ip igmp version 2
 ip igmp query-interval 60
 ip igmp tcn query count 2
 ip igmp tcn query interval 10

interface GigabitEthernet1/0/0
 description " Connected to p1 router"
 mtu 1600
 ip address 172.17.11.18 255.255.255.252
 ip redirects
 ip unreachables
 ip proxy-arp
 ip mtu 1600
 no ip load-sharing per-longest-match-prefix
 ip cef accounting non-recursive internal
 ip router isis
 ip flow monitor adsl input
 ip flow monitor adsl output
 ip pim dr-priority 1
 ip pim query-interval 30
 ip mfib forwarding input
 ip mfib forwarding output
 ip mfib cef input
 ip mfib cef output
 ip route-cache cef
 ip route-cache
 ip split-horizon
 ip igmp last-member-query-interval 1000
 ip igmp last-member-query-count 2
 ip igmp query-max-response-time 10
 ip igmp version 2
 ip igmp query-interval 60
 ip igmp tcn query count 2
 ip igmp tcn query interval 10

So, what do you think?

Regards,
Mohamed Kamal


From drohan at gmail.com  Wed Sep 10 23:00:33 2014
From: drohan at gmail.com (Daniel Rohan)
Date: Wed, 10 Sep 2014 16:00:33 -0700
Subject: MEF certifications recommendations?
Message-ID: <CAJXc8R+x2HZJep=R7YbXmPTZcr57O0EzcFaYRy9zi_=wb7jbpg@mail.gmail.com>

Hi all,

As our organization has matured, we've discovered the joy of speaking the
same carrier ethernet languages as our vendors and as such we're going
through a process of aligning our service-offerings with MEF-centric
terminology.

Anyone out there taken any MEF-certification training programs and had a
good enough experience to recommend one to us?

I'm looking for two types of training-- one for the customer-facing folks
and one for the engineering folks.

We're in Seattle, so local recommendations or nationally-know
recommendations are preferred.

Thanks,

Dan


From randy at psg.com  Thu Sep 11 13:24:46 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 11 Sep 2014 22:24:46 +0900
Subject: 2000::/6
In-Reply-To: <20140910161643.GP53723@Vurt.local>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
Message-ID: <m2tx4ee1cx.wl%randy@psg.com>

>> According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
>> "2000::/6 is visible by 79% of 92 IPv6 RIS full peers."
> This problem has been solved.

do we mark it up to pixie dust, or do we get an actual post mortem?

randy


From jared at puck.nether.net  Thu Sep 11 13:34:21 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 11 Sep 2014 09:34:21 -0400
Subject: 2000::/6
In-Reply-To: <m2tx4ee1cx.wl%randy@psg.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
Message-ID: <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>


> On Sep 11, 2014, at 9:24 AM, Randy Bush <randy at psg.com> wrote:
> 
>>> According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
>>> "2000::/6 is visible by 79% of 92 IPv6 RIS full peers."
>> This problem has been solved.
> 
> do we mark it up to pixie dust, or do we get an actual post mortem?

I talked to folks at 3549, they had a few tickets on it that took care of that.

I know we are reviewing our ?alloc-boundary? filter to prevent such a large prefix passing again.

- Jared

From randy at psg.com  Thu Sep 11 13:41:38 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 11 Sep 2014 22:41:38 +0900
Subject: 2000::/6
In-Reply-To: <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
Message-ID: <m2ppf2e0kt.wl%randy@psg.com>

>>>> According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing
>>>> "2000::/6 is visible by 79% of 92 IPv6 RIS full peers."
>>> This problem has been solved.
>> do we mark it up to pixie dust, or do we get an actual post mortem?
> I talked to folks at 3549, they had a few tickets on it that took care
> of that.

maybe i am more than usually st00pid this evening, but i am no smarter
on what actually happened, how it was detected/reported by/to someone
who could fix it, and how it was fixed.  you know, a basic post mortem,
so some of us could learn a lesson or two.

randy


From dave at dvstn.com  Thu Sep 11 13:45:41 2014
From: dave at dvstn.com (Dave Brockman)
Date: Thu, 11 Sep 2014 09:45:41 -0400
Subject: Contact at NetSuite DNS operations?
In-Reply-To: <53FF7D36.9050803@lcrcomputer.net>
References: <53FF7D36.9050803@lcrcomputer.net>
Message-ID: <5411A785.6000908@dvstn.com>

On 8/28/2014 3:04 PM, Lyle Giese wrote:
> I discovered that NetSuite's dns servers ens0 & 1 .netsuite.com are
> invisible from Comcast's business services in the Chicago area(limits of
> my testing abilities) but I can reach these same servers from a Linode
> virtual system in the Dallas, TX area.
> 
> Looks like it's been this way for at least two months.
> 
> If someone from NetSuite could say hi and look into it, I am sure it
> will help NetSuite more than me.
> 
> Lyle Giese
> LCR Computer Services, Inc.
> 

If anyone at Netsuite is lurking, we are having the same issue from
184.174.190.19, 184.174.190.29, and 198.91.75.75.  It is affecting
transactional emails (receipts/order confirmations).  Many thanks in
advance, and apologies for the noise.

Regards,

dtb

Dave Brockman
Senior Network Engineer



From tarko at lanparty.ee  Fri Sep 12 07:53:56 2014
From: tarko at lanparty.ee (Tarko Tikan)
Date: Fri, 12 Sep 2014 10:53:56 +0300
Subject: 2000::/6
In-Reply-To: <m2ppf2e0kt.wl%randy@psg.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com>
Message-ID: <5412A694.2050105@lanparty.ee>

hey,

> maybe i am more than usually st00pid this evening, but i am no smarter
> on what actually happened, how it was detected

Dunno about others but I personally detected it using my tools that look 
for our prefixes (or more specifics) being advertised by someone else. 
Large covering prefix obviously triggered the bells.

I'm pretty sure it was a typo in the config, the prefix length had to be 
/64 but was entered as /6 instead.

-- 
tarko


From nick at foobar.org  Fri Sep 12 09:48:06 2014
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 12 Sep 2014 10:48:06 +0100
Subject: 2000::/6
In-Reply-To: <5412A694.2050105@lanparty.ee>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
Message-ID: <5412C156.9040905@foobar.org>

On 12/09/2014 08:53, Tarko Tikan wrote:
> I'm pretty sure it was a typo in the config, the prefix length had to be
> /64 but was entered as /6 instead.

2000::/64 doesn't make much sense either.

Nick



From tarko at lanparty.ee  Fri Sep 12 09:54:41 2014
From: tarko at lanparty.ee (Tarko Tikan)
Date: Fri, 12 Sep 2014 12:54:41 +0300
Subject: 2000::/6
In-Reply-To: <5412C156.9040905@foobar.org>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <5412C156.9040905@foobar.org>
Message-ID: <5412C2E1.80606@lanparty.ee>

hey,

> 2000::/64 doesn't make much sense either.

No and it was obviously not what was configured.

But something like 2001:7d0:1:1::1/64 misconfigured on interface as 
2001:7d0:1:1::1/6 becomes 2000::/6

-- 
tarko


From cscora at apnic.net  Fri Sep 12 18:11:14 2014
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 13 Sep 2014 04:11:14 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201409121811.s8CIBE7w022595@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 13 Sep, 2014

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              510411
    Prefixes after maximum aggregation:                          198347
    Deaggregation factor:                                          2.57
    Unique aggregates announced to Internet:                     250698
Total ASes present in the Internet Routing Table:                 47994
    Prefixes per ASN:                                             10.63
Origin-only ASes present in the Internet Routing Table:           36148
Origin ASes announcing only one prefix:                           16392
Transit ASes present in the Internet Routing Table:                6157
Transit-only ASes present in the Internet Routing Table:            173
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      40
    Max AS path prepend of ASN ( 55644)                              33
Prefixes from unregistered ASNs in the Routing Table:              1661
    Unregistered ASNs in the Routing Table:                         446
Number of 32-bit ASNs allocated by the RIRs:                       7379
Number of 32-bit ASNs visible in the Routing Table:                5689
Prefixes from 32-bit ASNs in the Routing Table:                   19972
Number of bogon 32-bit ASNs visible in the Routing Table:            16
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            350
Number of addresses announced to Internet:                   2710407908
    Equivalent to 161 /8s, 141 /16s and 138 /24s
    Percentage of available address space announced:               73.2
    Percentage of allocated address space announced:               73.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               96.9
Total number of prefixes smaller than registry allocations:      175155

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   124899
    Total APNIC prefixes after maximum aggregation:               36562
    APNIC Deaggregation factor:                                    3.42
Prefixes being announced from the APNIC address blocks:          128593
    Unique aggregates announced from the APNIC address blocks:    52768
APNIC Region origin ASes present in the Internet Routing Table:    4980
    APNIC Prefixes per ASN:                                       25.82
APNIC Region origin ASes announcing only one prefix:               1215
APNIC Region transit ASes present in the Internet Routing Table:    870
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         40
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1086
Number of APNIC addresses announced to Internet:              735938624
    Equivalent to 43 /8s, 221 /16s and 136 /24s
    Percentage of available APNIC address space announced:         86.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, 63488-64098, 131072-135580
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, 150/8, 153/8,
                       163/8, 171/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:                    169997
    Total ARIN prefixes after maximum aggregation:                85153
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           171979
    Unique aggregates announced from the ARIN address blocks:     80373
ARIN Region origin ASes present in the Internet Routing Table:    16371
    ARIN Prefixes per ASN:                                        10.51
ARIN Region origin ASes announcing only one prefix:                6124
ARIN Region transit ASes present in the Internet Routing Table:    1687
Average ARIN Region AS path length visible:                         3.9
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:     190
Number of ARIN addresses announced to Internet:              1084723616
    Equivalent to 64 /8s, 167 /16s and 145 /24s
    Percentage of available ARIN address space announced:          57.4

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, 62464-63487, 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, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/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:                    125058
    Total RIPE prefixes after maximum aggregation:                63149
    RIPE Deaggregation factor:                                     1.98
Prefixes being announced from the RIPE address blocks:           130033
    Unique aggregates announced from the RIPE address blocks:     82363
RIPE Region origin ASes present in the Internet Routing Table:    17714
    RIPE Prefixes per ASN:                                         7.34
RIPE Region origin ASes announcing only one prefix:                8207
RIPE Region transit ASes present in the Internet Routing Table:    2899
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          32
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3045
Number of RIPE addresses announced to Internet:               659229828
    Equivalent to 39 /8s, 75 /16s and 12 /24s
    Percentage of available RIPE address space announced:          95.8

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
                       59392-61439, 61952-62463, 196608-202239
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,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   59409
    Total LACNIC prefixes after maximum aggregation:              10635
    LACNIC Deaggregation factor:                                   5.59
Prefixes being announced from the LACNIC address blocks:          67668
    Unique aggregates announced from the LACNIC address blocks:   30185
LACNIC Region origin ASes present in the Internet Routing Table:   2297
    LACNIC Prefixes per ASN:                                      29.46
LACNIC Region origin ASes announcing only one prefix:               630
LACNIC Region transit ASes present in the Internet Routing Table:   456
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        27
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1316
Number of LACNIC addresses announced to Internet:             170834048
    Equivalent to 10 /8s, 46 /16s and 184 /24s
    Percentage of available LACNIC address space announced:       101.8

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  10981
    Total AfriNIC prefixes after maximum aggregation:              2802
    AfriNIC Deaggregation factor:                                  3.92
Prefixes being announced from the AfriNIC address blocks:         11788
    Unique aggregates announced from the AfriNIC address blocks:   4709
AfriNIC Region origin ASes present in the Internet Routing Table:   739
    AfriNIC Prefixes per ASN:                                     15.95
AfriNIC Region origin ASes announcing only one prefix:              216
AfriNIC Region transit ASes present in the Internet Routing Table:  154
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       28
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:   52
Number of AfriNIC addresses announced to Internet:             59392000
    Equivalent to 3 /8s, 138 /16s and 64 /24s
    Percentage of available AfriNIC address space announced:       59.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2933      11591         922   Korea Telecom
17974     2811        900          74   PT Telekomunikasi Indonesia
 7545     2345        336         121   TPG Telecom Limited
 4755     1902        413         192   TATA Communications formerly 
 9829     1635       1306          38   National Internet Backbone
 4808     1396       2227         409   CNCGROUP IP network China169 
 9583     1321        105         542   Sify Limited
 9498     1302        333          91   BHARTI Airtel Ltd.
 7552     1241       1098          14   Viettel Corporation
 9808     1239       6639          15   Guangdong Mobile Communicatio

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     2897       3688          51   BellSouth.net Inc.
22773     2884       2940         142   Cox Communications Inc.
18566     2045        379         178   MegaPath Corporation
 7029     1903       1959         320   Windstream Communications Inc
20115     1780       1766         502   Charter Communications
 4323     1622       1055         406   tw telecom holdings, inc.
30036     1522        318         572   Mediacom Communications Corp
 6983     1476        817         311   ITC^Deltacom
  701     1438      11242         720   MCI Communications Services, 
22561     1309        408         237   CenturyTel Internet Holdings,

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
34984     1753        299         284   TELLCOM ILETISIM HIZMETLERI A
20940     1470        571        1083   Akamai International B.V.
 8402     1386        544          15   OJSC "Vimpelcom"
31148     1042         45          20   Freenet Ltd.
13188     1013         97          51   TOV "Bank-Inform"
 8551      946        371          41   Bezeq International-Ltd
 6849      805        356          26   JSC "Ukrtelecom"
12479      793        798          58   France Telecom Espana SA
 6830      776       2335         431   Liberty Global Operations B.V
 9198      660        346          28   JSC Kazakhtelecom

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
28573     3053       2311         107   NET Servi?os de Comunica??o S
10620     2951        478         274   Telmex Colombia S.A.
18881     2100       1036          22   Global Village Telecom
 7303     1756       1166         233   Telecom Argentina S.A.
 6147     1708        374          30   Telefonica del Peru S.A.A.
 8151     1468       2999         434   Uninet S.A. de C.V.
 6503     1109        434          62   Axtel, S.A.B. de C.V.
 7738      999       1882          41   Telemar Norte Leste S.A.
27947      908        130          51   Telconet S.A
26615      899       2325          35   Tim Celular 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
24863      916        280          26   Link Egypt (Link.NET)
 6713      670        744          37   Office National des Postes et
 8452      546        958          13   TE-AS
36992      336        816          30   ETISALAT MISR
24835      307        144           9   Vodafone Data
 3741      249        920         212   Internet Solutions
37054      244         19           6   Data Telecom Service
29571      237         22          17   Cote d'Ivoire Telecom
15706      186         17           6   Sudatel (Sudan Telecom Co. Lt
12258      174         26          71   MWEB CONNECT (PROPRIETARY) LI

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
28573     3053       2311         107   NET Servi?os de Comunica??o S
10620     2951        478         274   Telmex Colombia S.A.
 4766     2933      11591         922   Korea Telecom
 6389     2897       3688          51   BellSouth.net Inc.
22773     2884       2940         142   Cox Communications Inc.
17974     2811        900          74   PT Telekomunikasi Indonesia
 7545     2345        336         121   TPG Telecom Limited
18881     2100       1036          22   Global Village Telecom
18566     2045        379         178   MegaPath Corporation
 7029     1903       1959         320   Windstream Communications Inc

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 6389      2897        2846      BellSouth.net Inc.
22773      2884        2742      Cox Communications Inc.
17974      2811        2737      PT Telekomunikasi Indonesia
10620      2951        2677      Telmex Colombia S.A.
 7545      2345        2224      TPG Telecom Limited
18881      2100        2078      Global Village Telecom
 4766      2933        2011      Korea Telecom
18566      2045        1867      MegaPath Corporation
 4755      1902        1710      TATA Communications formerly 
 6147      1708        1678      Telefonica del Peru S.A.A.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
20260   UNALLOCATED  8.25.160.0/24         3356       Level 3 Communicatio
20260   UNALLOCATED  8.25.161.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24        12180       Internap Network Ser
46473   UNALLOCATED  8.27.124.0/24        12180       Internap Network Ser
55020   UNALLOCATED  8.30.123.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          6461       Abovenet Communicati
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.100.241.0/24       23456     32bit Transition AS
24.231.96.0/24       21548     MTO Telecom Inc.
27.100.7.0/24        56096     >>UNKNOWN<<
37.16.88.0/23        57652     >>UNKNOWN<<
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.10.0/24        37004     >>UNKNOWN<<
41.73.11.0/24        37004     >>UNKNOWN<<
41.73.12.0/24        37004     >>UNKNOWN<<
41.73.13.0/24        37004     >>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:16       /9:12      /10:31      /11:90      /12:262     
/13:504     /14:991     /15:1712    /16:13047   /17:7062    /18:11768   
/19:24633   /20:35229   /21:37733   /22:54535   /23:47854   /24:272035  
/25:1077    /26:1042    /27:723     /28:14      /29:18      /30:10      
/31:1       /32:12      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2121          2884      Cox Communications Inc.
18566     2000          2045      MegaPath Corporation
 6389     1676          2897      BellSouth.net Inc.
30036     1371          1522      Mediacom Communications Corp
 6147     1276          1708      Telefonica del Peru S.A.A.
 6983     1175          1476      ITC^Deltacom
 7029     1134          1903      Windstream Communications Inc
11492     1116          1165      CABLE ONE, INC.
34984     1074          1753      TELLCOM ILETISIM HIZMETLERI A
 8402     1058          1386      OJSC "Vimpelcom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1329      2:664       3:3         4:18        5:1127      6:21     
   8:749      12:1854     13:4        14:1111     15:17       16:2      
  17:40       18:21       20:51       23:919      24:1768     27:1763   
  31:1410     32:39       33:2        34:5        36:143      37:1773   
  38:965      39:17       40:223      41:2522     42:267      43:328    
  44:16       45:71       46:2142     47:25       49:731      50:822    
  52:12       54:51       55:6        56:6        57:32       58:1204   
  59:661      60:426      61:1702     62:1270     63:1831     64:4366   
  65:2292     66:4190     67:2014     68:1033     69:3277     70:864    
  71:474      72:1998     74:2566     75:369      76:422      77:1599   
  78:826      79:725      80:1303     81:1200     82:773      83:773    
  84:729      85:1328     86:441      87:1159     88:465      89:1782   
  90:138      91:5698     92:767      93:1787     94:1990     95:1604   
  96:428      97:342      98:1153     99:48      100:66      101:713    
 103:5590    104:228     105:38      106:182     107:635     108:568    
 109:1980    110:1029    111:1359    112:720     113:862     114:778    
 115:1209    116:1123    117:992     118:1559    119:1409    120:433    
 121:963     122:2195    123:1614    124:1431    125:1579    128:608    
 129:348     130:364     131:764     132:428     133:165     134:320    
 135:76      136:304     137:290     138:384     139:204     140:213    
 141:413     142:580     143:434     144:511     145:114     146:682    
 147:554     148:970     149:433     150:482     151:602     152:468    
 153:243     154:338     155:535     156:357     157:328     158:275    
 159:931     160:324     161:592     162:1720    163:348     164:702    
 165:659     166:363     167:681     168:1120    169:123     170:1394   
 171:184     172:62      173:1619    174:708     175:605     176:1499   
 177:3581    178:2077    179:764     180:1777    181:1579    182:1654   
 183:553     184:716     185:2049    186:2955    187:1700    188:2208   
 189:1474    190:7824    191:747     192:7532    193:5501    194:4048   
 195:3565    196:1414    197:660     198:5139    199:5462    200:6471   
 201:2855    202:9151    203:9011    204:4552    205:2651    206:2950   
 207:2925    208:3918    209:3761    210:3304    211:1834    212:2335   
 213:2145    214:860     215:86      216:5624    217:1705    218:614    
 219:408     220:1366    221:686     222:484     223:598    

End of report


From cidr-report at potaroo.net  Fri Sep 12 22:00:00 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 12 Sep 2014 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201409122200.s8CM00Xv056928@wattle.apnic.net>

This report has been generated at Fri Sep 12 21:14:14 2014 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/2.0 for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        05-09-14    515023      284407
        06-09-14    515306      284358
        07-09-14    515397      284522
        08-09-14    515833      284494
        09-09-14    515844      284760
        10-09-14    515949      284121
        11-09-14    510621      284307
        12-09-14    515908      284348


AS Summary
         48248  Number of ASes in routing system
         19517  Number of ASes announcing only one prefix
          3051  Largest number of prefixes announced by an AS
                AS28573: NET Servi?os de Comunica??o S.A.,BR
      120167168  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


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').

 --- 12Sep14 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     515956   284380   231576    44.9%   All ASes

AS28573     3051      124     2927    95.9%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS6389      2894       79     2815    97.3%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS17974     2812       80     2732    97.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS22773     2881      173     2708    94.0%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS18881     2100      113     1987    94.6%   Global Village Telecom,BR
AS4766      2934     1198     1736    59.2%   KIXS-AS-KR Korea Telecom,KR
AS4755      1900      232     1668    87.8%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS6147      1735      164     1571    90.5%   Telefonica del Peru S.A.A.,PE
AS7303      1761      284     1477    83.9%   Telecom Argentina S.A.,AR
AS8402      1358       23     1335    98.3%   CORBINA-AS OJSC "Vimpelcom",RU
AS4323      1634      412     1222    74.8%   TWTC - tw telecom holdings,
                                               inc.,US
AS7552      1263       58     1205    95.4%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS20115     1781      576     1205    67.7%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS7545      2361     1162     1199    50.8%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS9808      1239       42     1197    96.6%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS9498      1304      109     1195    91.6%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566     2044      862     1182    57.8%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS10620     2951     1854     1097    37.2%   Telmex Colombia S.A.,CO
AS22561     1308      263     1045    79.9%   AS22561 - CenturyTel Internet
                                               Holdings, Inc.,US
AS7029      1996     1023      973    48.7%   WINDSTREAM - Windstream
                                               Communications Inc,US
AS7738       999       83      916    91.7%   Telemar Norte Leste S.A.,BR
AS6983      1476      616      860    58.3%   ITCDELTA - Earthlink, Inc.,US
AS24560     1173      333      840    71.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services,IN
AS4788      1052      231      821    78.0%   TMNET-AS-AP TM Net, Internet
                                               Service Provider,MY
AS38285      957      143      814    85.1%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS9829      1635      825      810    49.5%   BSNL-NIB National Internet
                                               Backbone,IN
AS8151      1477      701      776    52.5%   Uninet S.A. de C.V.,MX
AS4780      1027      254      773    75.3%   SEEDNET Digital United Inc.,TW
AS26615      899      127      772    85.9%   Tim Celular S.A.,BR
AS18101      955      194      761    79.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI,IN

Total      52957    12338    40619    76.7%   Top 30 total


Possible Bogus Routes

        5.100.241.0/24       AS19957 -Reserved AS-,ZZ
        24.231.96.0/24       AS21548 MTO - MTO Telecom Inc.,CA
        27.100.7.0/24        AS56096 
        37.16.88.0/23        AS57652 -Reserved AS-,ZZ
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.10.0/24        AS37004 -Reserved AS-,ZZ
        41.73.11.0/24        AS37004 -Reserved AS-,ZZ
        41.73.12.0/24        AS37004 -Reserved AS-,ZZ
        41.73.13.0/24        AS37004 -Reserved AS-,ZZ
        41.73.14.0/24        AS37004 -Reserved AS-,ZZ
        41.73.15.0/24        AS37004 -Reserved AS-,ZZ
        41.73.16.0/24        AS37004 -Reserved AS-,ZZ
        41.73.18.0/24        AS37004 -Reserved AS-,ZZ
        41.73.20.0/24        AS37004 -Reserved AS-,ZZ
        41.73.21.0/24        AS37004 -Reserved AS-,ZZ
        41.76.48.0/21        AS36969 MTL-AS,MW
        41.78.120.0/23       AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US
        41.78.180.0/23       AS37265 -Reserved AS-,ZZ
        41.189.96.0/20       AS37000 -Reserved AS-,ZZ
        41.191.108.0/22      AS37004 -Reserved AS-,ZZ
        41.191.108.0/24      AS37004 -Reserved AS-,ZZ
        41.191.109.0/24      AS37004 -Reserved AS-,ZZ
        41.191.110.0/24      AS37004 -Reserved AS-,ZZ
        41.191.111.0/24      AS37004 -Reserved AS-,ZZ
        41.223.208.0/22      AS37000 -Reserved AS-,ZZ
        43.243.152.0/23      AS58514 SUPERNET-AS-ID PT. Supernet Advance Teknologi,ID
        62.193.160.0/19      AS24801 -Reserved AS-,ZZ
        62.193.160.0/20      AS24801 -Reserved AS-,ZZ
        62.193.176.0/20      AS24801 -Reserved AS-,ZZ
        64.25.16.0/23        AS19535 -Reserved AS-,ZZ
        64.25.20.0/24        AS19535 -Reserved AS-,ZZ
        64.25.21.0/24        AS19535 -Reserved AS-,ZZ
        64.25.22.0/24        AS19535 -Reserved AS-,ZZ
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US
        64.111.160.0/20      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.160.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.161.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.162.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.167.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.169.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.170.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.171.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.172.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.173.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.174.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.175.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global,US
        66.55.96.0/23        AS17203 -Reserved AS-,ZZ
        66.55.98.0/24        AS17203 -Reserved AS-,ZZ
        66.55.99.0/24        AS17203 -Reserved AS-,ZZ
        66.55.100.0/22       AS17203 -Reserved AS-,ZZ
        66.55.102.0/23       AS17203 -Reserved AS-,ZZ
        66.55.104.0/21       AS17203 -Reserved AS-,ZZ
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation,CA
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.,IT
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        74.112.100.0/22      AS16764 -Reserved AS-,ZZ
        74.113.200.0/23      AS46939 -Reserved AS-,ZZ
        74.114.52.0/22       AS40818 -Reserved AS-,ZZ
        74.114.52.0/23       AS40818 -Reserved AS-,ZZ
        74.114.52.0/24       AS40818 -Reserved AS-,ZZ
        74.114.53.0/24       AS40818 -Reserved AS-,ZZ
        74.114.54.0/23       AS40818 -Reserved AS-,ZZ
        74.114.54.0/24       AS40818 -Reserved AS-,ZZ
        74.114.55.0/24       AS40818 -Reserved AS-,ZZ
        74.114.184.0/22      AS19888 -Reserved AS-,ZZ
        74.118.132.0/22      AS5117  -Reserved AS-,ZZ
        74.120.212.0/23      AS32326 -Reserved AS-,ZZ
        74.120.214.0/23      AS32326 -Reserved AS-,ZZ
        74.121.24.0/22       AS36263 FORONA - Forona Technologies, Inc.,US
        74.123.136.0/21      AS53358 -Reserved AS-,ZZ
        77.243.80.0/24       AS42597 -Reserved AS-,ZZ
        77.243.81.0/24       AS42597 -Reserved AS-,ZZ
        77.243.88.0/24       AS42597 -Reserved AS-,ZZ
        77.243.91.0/24       AS42597 -Reserved AS-,ZZ
        77.243.94.0/24       AS42597 -Reserved AS-,ZZ
        77.243.95.0/24       AS42597 -Reserved AS-,ZZ
        80.78.133.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/23       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.135.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.250.32.0/22       AS37106 ODUA-AS,NG
        85.202.160.0/20      AS44404 -Reserved AS-,ZZ
        89.31.24.0/23        AS41455 -Reserved AS-,ZZ
        89.31.26.0/23        AS41455 -Reserved AS-,ZZ
        89.31.28.0/22        AS41455 -Reserved AS-,ZZ
        91.193.60.0/22       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.195.66.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.197.36.0/22       AS43359 -Reserved AS-,ZZ
        91.199.90.0/24       AS44330 -Reserved AS-,ZZ
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG,DE
        91.228.160.0/24      AS35557 GRITSENKO-AS PE GRITSENKO NADEJDA NIKOLAEVNA,UA
        91.239.157.0/24      AS24958 TBSH The Bunker Secure Hosting Limited,GB
        93.190.10.0/24       AS47254 -Reserved AS-,ZZ
        100.65.0.0/24        AS4826  VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. ,AU
        103.6.108.0/22       AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN
        103.9.108.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.76.0/22       AS18097 DCN D.C.N. Corporation,JP
        103.18.92.0/22       AS13269 
        103.18.92.0/24       AS13269 
        103.18.94.0/24       AS13269 
        103.18.248.0/22      AS18097 DCN D.C.N. Corporation,JP
        103.19.0.0/22        AS18097 DCN D.C.N. Corporation,JP
        103.20.100.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.20.101.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.21.4.0/22        AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US
        103.26.76.0/22       AS13280 
        103.26.116.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.228.132.0/22     AS4826  VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.220.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.249.8.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.250.0.0/22       AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.251.192.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        104.171.144.0/24     AS16628 DEDICATED-FIBER-COMMUNICATIONS - DedFiberCo,US
        116.206.72.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.85.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.103.0/24     AS6461  ABOVENET - Abovenet Communications, Inc,US
        117.103.32.0/24      AS23861 
        117.103.33.0/24      AS23861 
        117.103.34.0/24      AS23861 
        117.103.35.0/24      AS23861 
        117.103.36.0/24      AS23861 
        117.103.37.0/24      AS23861 
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street,CN
        124.158.28.0/22      AS45857 
        142.147.62.0/24      AS3958  AIRCANADA - Air Canada,CA
        162.210.240.0/21     AS17246 -Reserved AS-,ZZ
        162.210.244.0/24     AS17246 -Reserved AS-,ZZ
        162.210.245.0/24     AS17246 -Reserved AS-,ZZ
        162.210.246.0/24     AS17246 -Reserved AS-,ZZ
        162.210.247.0/24     AS17246 -Reserved AS-,ZZ
        162.244.140.0/22     AS17246 -Reserved AS-,ZZ
        162.244.140.0/24     AS17246 -Reserved AS-,ZZ
        162.244.141.0/24     AS17246 -Reserved AS-,ZZ
        166.93.0.0/16        AS23537 CRITIGEN - Micro Source, Inc.,US
        172.85.0.0/24        AS29571 CITelecom-AS,CI
        172.85.1.0/24        AS29571 CITelecom-AS,CI
        172.85.2.0/24        AS29571 CITelecom-AS,CI
        172.85.3.0/24        AS29571 CITelecom-AS,CI
        172.86.0.0/24        AS29571 CITelecom-AS,CI
        172.86.1.0/24        AS29571 CITelecom-AS,CI
        172.86.2.0/24        AS29571 CITelecom-AS,CI
        172.87.0.0/24        AS29571 CITelecom-AS,CI
        172.88.0.0/24        AS29571 CITelecom-AS,CI
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group),CN
        176.111.168.0/22     AS50586 MACROSOLUTIONS MacroSolution SRL,RO
        182.237.24.0/24      AS55503 
        182.237.25.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        185.28.180.0/22      AS18097 DCN D.C.N. Corporation,JP
        190.124.252.0/22     AS7303  Telecom Argentina S.A.,AR
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US
        192.25.10.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.11.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.13.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.14.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.34.152.0/21      AS10835 VISIONARY - Visionary Communications, Inc.,US
        192.75.23.0/24       AS2579  AS2579 - Alcatel-Lucent,US
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.72.0/24      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.124.252.0/22     AS680   DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE
        192.131.233.0/24     AS7018  ATT-INTERNET4 - AT&T Services, Inc.,US
        192.149.81.0/24      AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US
        192.154.32.0/19      AS81    NCREN - MCNC,US
        192.154.64.0/19      AS81    NCREN - MCNC,US
        192.166.32.0/20      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        192.245.195.0/24     AS7381  SUNGARDRS - SunGard Availability Services LP,US
        193.9.59.0/24        AS1257  TELE2,SE
        193.16.106.0/24      AS31539 -Reserved AS-,ZZ
        193.16.145.0/24      AS31392 -Reserved AS-,ZZ
        193.22.86.0/24       AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI
        193.22.224.0/20      AS3322  -Reserved AS-,ZZ
        193.22.238.0/23      AS62383 LDS-AS Lambrechts Data Services VOF,BE
        193.26.213.0/24      AS31641 BYTEL-AS Bytel Ltd,GB
        193.28.14.0/24       AS34309 LINK11 Link11 GmbH,DE
        193.33.6.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.33.252.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.53.5.0/24        AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.93.6.0/23        AS35559 SOMEADDRESS Someaddress Networks Ltd,GB
        193.111.229.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.149.2.0/23       AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.178.196.0/22     AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company,JO
        193.200.244.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.201.244.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.245.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.246.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.202.8.0/21       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.202.9.0/24       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.223.103.0/24     AS3248  SIL-AT Tele2 Telecommunication GmbH,AT
        193.227.109.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.227.236.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.0.116.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.0.117.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.6.252.0/24       AS21202 DCSNET-AS Bredband2 AB,SE
        194.9.8.0/23         AS2863  SPRITELINK Centor AB,SE
        194.9.8.0/24         AS2863  SPRITELINK Centor AB,SE
        194.33.11.0/24       AS8943  JUMP Jump Networks Ltd.,GB
        194.39.78.0/23       AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        194.49.17.0/24       AS13135 CREW-AS Wieske's Crew GmbH,DE
        194.50.8.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.60.88.0/21       AS5089  NTL Virgin Media Limited,GB
        194.63.152.0/22      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.79.36.0/22       AS3257  TINET-BACKBONE Tinet SpA,DE
        194.88.6.0/24        AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
        194.88.226.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.99.67.0/24       AS9083  CARPENET carpeNet Information Technologies GmbH,DE
        194.126.152.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.126.219.0/24     AS34545 -Reserved AS-,ZZ
        194.126.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        194.150.214.0/23     AS30880 SPACEDUMP-AS SpaceDump IT AB,SE
        194.156.179.0/24     AS3209  VODANET Vodafone GmbH,DE
        194.180.25.0/24      AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE
        194.187.24.0/22      AS8856  UKRNET UkrNet Ltd,UA
        195.8.48.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.48.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.119.0/24       AS34304 TEENTELECOM Teen Telecom SRL,RO
        195.42.232.0/22      AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        195.85.194.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.85.201.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.110.0.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB,SE
        195.149.119.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.189.174.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA,BE
        195.234.156.0/24     AS25028 -Reserved AS-,ZZ
        195.242.182.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.244.18.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.245.98.0/23      AS48918 GLOBALWAYS GLOBALWAYS AG,DE
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.6.0.0/24         AS32768 routability-tests,MU
        196.22.8.0/24        AS27822 Emerging Markets Communications de Argentina S.R.L,AR
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        196.192.124.0/23     AS37301 AFRINIC-ZA-CPT-AS,MU
        196.216.254.0/24     AS32768 routability-tests,MU
        198.22.195.0/24      AS54583 -Reserved AS-,ZZ
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.,US
        198.74.11.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.13.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.192.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited,CA
        198.163.215.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.163.216.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        198.176.208.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.209.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.210.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.211.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.252.165.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.166.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.167.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.168.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.169.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        199.85.9.0/24        AS852   ASN852 - TELUS Communications Inc.,CA
        199.88.52.0/22       AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US
        199.116.200.0/21     AS22830 -Reserved AS-,ZZ
        199.120.150.0/24     AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        200.1.112.0/24       AS29754 GO2TEL - GO2TEL.COM INC.,US
        200.58.248.0/21      AS27849 
        200.81.48.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        200.81.49.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR
        202.53.138.0/24      AS4058  CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK
        202.58.113.0/24      AS19161 -Reserved AS-,ZZ
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.,IN
        203.142.219.0/24     AS45149 
        203.160.48.0/21      AS38008 
        203.189.116.0/22     AS45606 
        203.189.116.0/24     AS45606 
        203.189.117.0/24     AS45606 
        203.189.118.0/24     AS45606 
        203.189.119.0/24     AS45606 
        204.10.88.0/21       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US
        204.16.96.0/24       AS19972 -Reserved AS-,ZZ
        204.16.97.0/24       AS19972 -Reserved AS-,ZZ
        204.16.98.0/24       AS19972 -Reserved AS-,ZZ
        204.16.99.0/24       AS19972 -Reserved AS-,ZZ
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta,GB
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp,US
        205.166.231.0/24     AS7029  WINDSTREAM - Windstream Communications Inc,US
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network,CA
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US
        206.223.224.0/24     AS21548 MTO - MTO Telecom Inc.,CA
        207.2.120.0/21       AS6221  USCYBERSITES - US Cybersites, Inc,US
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.,US
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.,US
        207.254.128.0/21     AS30689 FLOW-NET - FLOW,JM
        207.254.128.0/24     AS30689 FLOW-NET - FLOW,JM
        207.254.136.0/21     AS30689 FLOW-NET - FLOW,JM
        208.66.64.0/24       AS16936 -Reserved AS-,ZZ
        208.66.65.0/24       AS16936 -Reserved AS-,ZZ
        208.66.66.0/24       AS16936 -Reserved AS-,ZZ
        208.66.67.0/24       AS16936 -Reserved AS-,ZZ
        208.67.132.0/22      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        208.69.192.0/23      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.69.195.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.75.152.0/21      AS32146 -Reserved AS-,ZZ
        208.76.20.0/24       AS31812 -Reserved AS-,ZZ
        208.76.21.0/24       AS31812 -Reserved AS-,ZZ
        208.77.164.0/24      AS22659 -Reserved AS-,ZZ
        208.77.166.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC,US
        208.84.232.0/24      AS33131 -Reserved AS-,ZZ
        208.84.234.0/24      AS33131 -Reserved AS-,ZZ
        208.84.237.0/24      AS33131 -Reserved AS-,ZZ
        208.84.238.0/24      AS33131 -Reserved AS-,ZZ
        208.94.216.0/23      AS13629 -Reserved AS-,ZZ
        208.94.219.0/24      AS13629 -Reserved AS-,ZZ
        208.94.221.0/24      AS13629 -Reserved AS-,ZZ
        208.94.223.0/24      AS13629 -Reserved AS-,ZZ
        209.135.171.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.135.175.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.177.64.0/20      AS6461  ABOVENET - Abovenet Communications, Inc,US
        209.193.112.0/20     AS209   ASN-QWEST - Qwest Communications Company, LLC,US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US
        209.209.224.0/19     AS19513 -Reserved AS-,ZZ
        209.209.248.0/23     AS19513 -Reserved AS-,ZZ
        209.209.250.0/23     AS19513 -Reserved AS-,ZZ
        209.209.251.0/24     AS19513 -Reserved AS-,ZZ
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US
        209.234.112.0/23     AS32252 -Reserved AS-,ZZ
        209.234.114.0/23     AS32252 -Reserved AS-,ZZ
        209.234.116.0/24     AS32252 -Reserved AS-,ZZ
        209.234.117.0/24     AS32252 -Reserved AS-,ZZ
        209.234.118.0/24     AS32252 -Reserved AS-,ZZ
        209.234.119.0/24     AS32252 -Reserved AS-,ZZ
        209.234.120.0/24     AS32252 -Reserved AS-,ZZ
        209.234.121.0/24     AS32252 -Reserved AS-,ZZ
        209.234.122.0/24     AS32252 -Reserved AS-,ZZ
        213.255.128.0/20     AS24863 LINKdotNET-AS,EG
        213.255.144.0/20     AS24863 LINKdotNET-AS,EG
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.,US
        216.146.0.0/19       AS11915 US-TELEPACIFIC - TelePacific Communications,US
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US
        216.251.50.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN
        216.251.53.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN
        216.251.62.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN


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 cidr-report at potaroo.net  Fri Sep 12 22:00:01 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 12 Sep 2014 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201409122200.s8CM01Iw056943@wattle.apnic.net>

BGP Update Report
Interval: 02-Sep-14 -to- 09-Sep-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829           262205  6.6%     223.2 -- BSNL-NIB National Internet Backbone,IN
 2 - AS23752          203380  5.1%    1848.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 3 - AS8402            76755  1.9%     148.8 -- CORBINA-AS OJSC "Vimpelcom",RU
 4 - AS10620           70088  1.8%      32.2 -- Telmex Colombia S.A.,CO
 5 - AS28573           61428  1.6%      34.2 -- NET Servi?os de Comunica??o S.A.,BR
 6 - AS4775            51694  1.3%    1174.9 -- GLOBE-TELECOM-AS Globe Telecoms,PH
 7 - AS1659            47371  1.2%     928.8 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
 8 - AS22724           30060  0.8%     165.2 -- PUNTONET S.A.,EC
 9 - AS27047           25572  0.7%     521.9 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center,US
10 - AS45899           23280  0.6%      62.1 -- VNPT-AS-VN VNPT Corp,VN
11 - AS24814           22703  0.6%    3243.3 -- SCS-AS Syrian Computer Society, scs,SY
12 - AS48159           20836  0.5%      85.4 -- TIC-AS Telecommunication Infrastructure Company,IR
13 - AS25003           19506  0.5%     513.3 -- INTERNET_BINAT Internet Binat Ltd,IL
14 - AS29386           17894  0.5%     303.3 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY
15 - AS38197           17755  0.5%      26.7 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK
16 - AS7552            17546  0.4%      15.0 -- VIETEL-AS-AP Viettel Corporation,VN
17 - AS8151            17224  0.4%      16.3 -- Uninet S.A. de C.V.,MX
18 - AS32336           17179  0.4%   17179.0 -- IPASS-2 - iPass Incorporated,US
19 - AS3816            16953  0.4%      28.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO
20 - AS4837            16903  0.4%      25.5 -- CHINA169-BACKBONE CNCGROUP China169 Backbone,CN


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS32336           17179  0.4%   17179.0 -- IPASS-2 - iPass Incorporated,US
 2 - AS18135            7714  0.2%    7714.0 -- BTV BTV Cable television,JP
 3 - AS226              4808  0.1%    4808.0 -- LOS-NETTOS-AS - Los Nettos,US
 4 - AS26661           10732  0.3%    3577.3 -- JCPS-ASN - Jeffco Public Schools,US
 5 - AS47680            3259  0.1%    3259.0 -- NHCS EOBO Limited,IE
 6 - AS24814           22703  0.6%    3243.3 -- SCS-AS Syrian Computer Society, scs,SY
 7 - AS21732            5626  0.1%    2813.0 -- FLAVORUS-ASN - Flavorus Inc,US
 8 - AS62174            2597  0.1%    2597.0 -- INTERPAN-AS INTERPAN LTD.,BG
 9 - AS38267            2518  0.1%    2518.0 -- FIBRENET-BD FibreNet Communications Ltd.,BD
10 - AS37620            4427  0.1%    2213.5 -- VIETTEL-CM-AS,CM
11 - AS33643            2175  0.1%    2175.0 -- JELLYBELLY - Jelly Belly Candy Company,US
12 - AS61747            1959  0.1%    1959.0 -- San Internet Brasil Ltda,BR
13 - AS40122            9459  0.2%    1891.8 -- MORTGAGE-INFORMATION-SERVICES-INC - Mortgage Information Services INC,US
14 - AS23752          203380  5.1%    1848.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
15 - AS35093            3518  0.1%    1759.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
16 - AS3                1620  0.0%    5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US
17 - AS30944            1599  0.0%    1599.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT
18 - AS23295            1391  0.0%    1391.0 -- EA-01 - Extend America,US
19 - AS6629            10582  0.3%    1322.8 -- NOAA-AS - NOAA,US
20 - AS2                1321  0.0%    1540.0 -- UDEL-DCN - University of Delaware,US


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.70.88.0/21   101279  2.4%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 2 - 202.70.64.0/21   101235  2.4%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 3 - 46.53.64.0/19     39739  0.9%   AS24814 -- SCS-AS Syrian Computer Society, scs,SY
                                     AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY
 4 - 120.28.62.0/24    25868  0.6%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms,PH
 5 - 222.127.0.0/24    25583  0.6%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms,PH
 6 - 192.115.44.0/22   19349  0.5%   AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL
 7 - 216.231.194.0/24  17179  0.4%   AS32336 -- IPASS-2 - iPass Incorporated,US
 8 - 89.221.206.0/24   15073  0.4%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU
 9 - 205.247.12.0/24   12358  0.3%   AS6459  -- TRANSBEAM - I-2000, Inc.,US
10 - 112.215.16.0/24   12257  0.3%   AS24203 -- NAPXLNET-AS-ID PT Excelcomindo Pratama (Network Access Provider),ID
11 - 192.58.232.0/24   10565  0.2%   AS6629  -- NOAA-AS - NOAA,US
12 - 120.118.64.0/19    7794  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
13 - 163.15.185.0/24    7794  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
14 - 120.118.96.0/20    7794  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
15 - 163.15.188.0/22    7794  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
16 - 163.15.192.0/24    7792  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
17 - 203.64.238.0/24    7792  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
18 - 42.83.48.0/20      7714  0.2%   AS18135 -- BTV BTV Cable television,JP
19 - 200.34.149.0/24    7008  0.2%   AS8151  -- Uninet S.A. de C.V.,MX
20 - 189.50.136.0/23    5608  0.1%   AS28330 -- IFTNET Informatica Ltda,BR

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 owen at delong.com  Sat Sep 13 01:51:51 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 12 Sep 2014 18:51:51 -0700
Subject: 2000::/6
In-Reply-To: <5412A694.2050105@lanparty.ee>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
Message-ID: <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>

My guess, actually, would be that someone was entering a more specific default (2000::/3) using a numeric keypad and missed the key with an off by one row error.

There is no matching entry in whois for 2000::/64 (or shorter), so it is unlikely that 2000::/64 was an intended configuration.

Owen

On Sep 12, 2014, at 12:53 AM, Tarko Tikan <tarko at lanparty.ee> wrote:

> hey,
> 
>> maybe i am more than usually st00pid this evening, but i am no smarter
>> on what actually happened, how it was detected
> 
> Dunno about others but I personally detected it using my tools that look for our prefixes (or more specifics) being advertised by someone else. Large covering prefix obviously triggered the bells.
> 
> I'm pretty sure it was a typo in the config, the prefix length had to be /64 but was entered as /6 instead.
> 
> -- 
> tarko



From brobare at wavebroadband.com  Thu Sep 11 04:35:10 2014
From: brobare at wavebroadband.com (Brandon Robare)
Date: Thu, 11 Sep 2014 04:35:10 +0000
Subject: MEF certifications recommendations?
In-Reply-To: <CAJXc8R+x2HZJep=R7YbXmPTZcr57O0EzcFaYRy9zi_=wb7jbpg@mail.gmail.com>
References: <CAJXc8R+x2HZJep=R7YbXmPTZcr57O0EzcFaYRy9zi_=wb7jbpg@mail.gmail.com>
Message-ID: <D0367159.31645%brobare@wavebroadband.com>

The MEF puts out a list of accredited providers -
http://metroethernetforum.org/certification-mef-cecp/mef-cecp-atps

Not sure if any are local to Seattle however.

For me personally, when I studied for the CE 1.0 and CE 2.0 tests, I just
read the book that Jon Kieffer and Ralph Santitoro from Fujitsu wrote.
Would recommend this for any of your staff that already have a solid
understanding of the technical parts of CE. Easy read and aligns well with
the test.

Brandon

On 9/10/14, 4:00 PM, "Daniel Rohan" <drohan at gmail.com> wrote:

>Hi all,
>
>As our organization has matured, we've discovered the joy of speaking the
>same carrier ethernet languages as our vendors and as such we're going
>through a process of aligning our service-offerings with MEF-centric
>terminology.
>
>Anyone out there taken any MEF-certification training programs and had a
>good enough experience to recommend one to us?
>
>I'm looking for two types of training-- one for the customer-facing folks
>and one for the engineering folks.
>
>We're in Seattle, so local recommendations or nationally-know
>recommendations are preferred.
>
>Thanks,
>
>Dan



From tarko at lanparty.ee  Sat Sep 13 10:33:37 2014
From: tarko at lanparty.ee (Tarko Tikan)
Date: Sat, 13 Sep 2014 13:33:37 +0300
Subject: 2000::/6
In-Reply-To: <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>
Message-ID: <54141D81.30800@lanparty.ee>

hey,

> There is no matching entry in whois for 2000::/64 (or shorter), so it is unlikely that 2000::/64 was an intended configuration.

2000::/64 has nothing to do with it.

Any address between 2000:0000:0000:0000:0000:0000:0000:0000 and 
23ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff together with misconfigured 
prefix length (6 instead 64) becomes 2000::/6 prefix.

-- 
tarko


From tnystrom at us.ntt.net  Sat Sep 13 22:12:17 2014
From: tnystrom at us.ntt.net (Tor Nystrom)
Date: Sat, 13 Sep 2014 18:12:17 -0400
Subject: NANOG Digest, Vol 80, Issue 13
Message-ID: <qt4gh09epg2x6446xj0brjee.1410646336460@email.android.com>

Sure np. I will pull the same data tomorrow and then again on Friday and from there on I will do it every Friday.

Tor


Sent via the Samsung Galaxy S?III, an AT&T 4G LTE smartphone

-------- Original message --------
From: nanog-request at nanog.org 
Date:09/13/2014  8:00 AM  (GMT-05:00) 
To: nanog at nanog.org 
Subject: NANOG Digest, Vol 80, Issue 13 

Send NANOG mailing list submissions to
nanog at nanog.org

To subscribe or unsubscribe via the World Wide Web, visit
http://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. Weekly Routing Table Report (Routing Analysis Role Account)
?? 2. The Cidr Report (cidr-report at potaroo.net)
?? 3. BGP Update Report (cidr-report at potaroo.net)
?? 4. Re: 2000::/6 (Owen DeLong)
?? 5. Re: MEF certifications recommendations? (Brandon Robare)
?? 6. Re: 2000::/6 (Tarko Tikan)


----------------------------------------------------------------------

Message: 1
Date: Sat, 13 Sep 2014 04:11:14 +1000 (EST)
From: Routing Analysis Role Account <cscora at apnic.net>
To: apops at apops.net, nanog at nanog.org, routing-wg at ripe.net,
afnog at afnog.org, sanog at sanog.org, pacnog at pacnog.org, safnog at safnog.org
Subject: Weekly Routing Table Report
Message-ID: <201409121811.s8CIBE7w022595 at 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 13 Sep, 2014

Report Website:???? http://thyme.rand.apnic.net
Detailed Analysis:? http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:????????????????????????????? 510411
??? Prefixes after maximum aggregation:????????????????????????? 198347
??? Deaggregation factor:????????????????????????????????????????? 2.57
??? Unique aggregates announced to Internet:???????????????????? 250698
Total ASes present in the Internet Routing Table:???????????????? 47994
??? Prefixes per ASN:???????????????????????????????????????????? 10.63
Origin-only ASes present in the Internet Routing Table:?????????? 36148
Origin ASes announcing only one prefix:?????????????????????????? 16392
Transit ASes present in the Internet Routing Table:??????????????? 6157
Transit-only ASes present in the Internet Routing Table:??????????? 173
Average AS path length visible in the Internet Routing Table:?????? 4.6
??? Max AS path length visible:????????????????????????????????????? 40
??? Max AS path prepend of ASN ( 55644)????????????????????????????? 33
Prefixes from unregistered ASNs in the Routing Table:????????????? 1661
??? Unregistered ASNs in the Routing Table:???????????????????????? 446
Number of 32-bit ASNs allocated by the RIRs:?????????????????????? 7379
Number of 32-bit ASNs visible in the Routing Table:??????????????? 5689
Prefixes from 32-bit ASNs in the Routing Table:?????????????????? 19972
Number of bogon 32-bit ASNs visible in the Routing Table:??????????? 16
Special use prefixes present in the Routing Table:??????????????????? 0
Prefixes being announced from unallocated address space:??????????? 350
Number of addresses announced to Internet:?????????????????? 2710407908
??? Equivalent to 161 /8s, 141 /16s and 138 /24s
??? Percentage of available address space announced:?????????????? 73.2
??? Percentage of allocated address space announced:?????????????? 73.2
??? Percentage of available address space allocated:????????????? 100.0
??? Percentage of address space in use by end-sites:?????????????? 96.9
Total number of prefixes smaller than registry allocations:????? 175155

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:?????????????????? 124899
??? Total APNIC prefixes after maximum aggregation:?????????????? 36562
??? APNIC Deaggregation factor:??????????????????????????????????? 3.42
Prefixes being announced from the APNIC address blocks:????????? 128593
??? Unique aggregates announced from the APNIC address blocks:??? 52768
APNIC Region origin ASes present in the Internet Routing Table:??? 4980
??? APNIC Prefixes per ASN:?????????????????????????????????????? 25.82
APNIC Region origin ASes announcing only one prefix:?????????????? 1215
APNIC Region transit ASes present in the Internet Routing Table:??? 870
Average APNIC Region AS path length visible:??????????????????????? 4.7
??? Max APNIC Region AS path length visible:???????????????????????? 40
Number of APNIC region 32-bit ASNs visible in the Routing Table:?? 1086
Number of APNIC addresses announced to Internet:????????????? 735938624
??? Equivalent to 43 /8s, 221 /16s and 136 /24s
??? Percentage of available APNIC address space announced:???????? 86.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, 63488-64098, 131072-135580
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, 150/8, 153/8,
?????????????????????? 163/8, 171/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:??????????????????? 169997
??? Total ARIN prefixes after maximum aggregation:??????????????? 85153
??? ARIN Deaggregation factor:???????????????????????????????????? 2.00
Prefixes being announced from the ARIN address blocks:?????????? 171979
??? Unique aggregates announced from the ARIN address blocks:???? 80373
ARIN Region origin ASes present in the Internet Routing Table:??? 16371
??? ARIN Prefixes per ASN:??????????????????????????????????????? 10.51
ARIN Region origin ASes announcing only one prefix:??????????????? 6124
ARIN Region transit ASes present in the Internet Routing Table:??? 1687
Average ARIN Region AS path length visible:???????????????????????? 3.9
??? Max ARIN Region AS path length visible:????????????????????????? 22
Number of ARIN region 32-bit ASNs visible in the Routing Table:???? 190
Number of ARIN addresses announced to Internet:????????????? 1084723616
??? Equivalent to 64 /8s, 167 /16s and 145 /24s
??? Percentage of available ARIN address space announced:????????? 57.4

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, 62464-63487, 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, 128/8,
?????????????????????? 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
?????????????????????? 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
?????????????????????? 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
?????????????????????? 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
?????????????????????? 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
?????????????????????? 173/8, 174/8, 184/8, 192/8, 198/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:??????????????????? 125058
??? Total RIPE prefixes after maximum aggregation:??????????????? 63149
??? RIPE Deaggregation factor:???????????????????????????????????? 1.98
Prefixes being announced from the RIPE address blocks:?????????? 130033
??? Unique aggregates announced from the RIPE address blocks:???? 82363
RIPE Region origin ASes present in the Internet Routing Table:??? 17714
??? RIPE Prefixes per ASN:???????????????????????????????????????? 7.34
RIPE Region origin ASes announcing only one prefix:??????????????? 8207
RIPE Region transit ASes present in the Internet Routing Table:??? 2899
Average RIPE Region AS path length visible:???????????????????????? 5.0
??? Max RIPE Region AS path length visible:????????????????????????? 32
Number of RIPE region 32-bit ASNs visible in the Routing Table:??? 3045
Number of RIPE addresses announced to Internet:?????????????? 659229828
??? Equivalent to 39 /8s, 75 /16s and 12 /24s
??? Percentage of available RIPE address space announced:????????? 95.8

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
?????????????????????? 59392-61439, 61952-62463, 196608-202239
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,
?????????????????????? 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
?????????????????????? 193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:?????????????????? 59409
??? Total LACNIC prefixes after maximum aggregation:????????????? 10635
??? LACNIC Deaggregation factor:?????????????????????????????????? 5.59
Prefixes being announced from the LACNIC address blocks:????????? 67668
??? Unique aggregates announced from the LACNIC address blocks:?? 30185
LACNIC Region origin ASes present in the Internet Routing Table:?? 2297
??? LACNIC Prefixes per ASN:????????????????????????????????????? 29.46
LACNIC Region origin ASes announcing only one prefix:?????????????? 630
LACNIC Region transit ASes present in the Internet Routing Table:?? 456
Average LACNIC Region AS path length visible:?????????????????????? 4.7
??? Max LACNIC Region AS path length visible:??????????????????????? 27
Number of LACNIC region 32-bit ASNs visible in the Routing Table:? 1316
Number of LACNIC addresses announced to Internet:???????????? 170834048
??? Equivalent to 10 /8s, 46 /16s and 184 /24s
??? Percentage of available LACNIC address space announced:?????? 101.8

LACNIC AS Blocks?????? 26592-26623, 27648-28671, 52224-53247,
?????????????????????? 61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks? 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
?????????????????????? 191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:????????????????? 10981
??? Total AfriNIC prefixes after maximum aggregation:????????????? 2802
??? AfriNIC Deaggregation factor:????????????????????????????????? 3.92
Prefixes being announced from the AfriNIC address blocks:???????? 11788
??? Unique aggregates announced from the AfriNIC address blocks:?? 4709
AfriNIC Region origin ASes present in the Internet Routing Table:?? 739
??? AfriNIC Prefixes per ASN:???????????????????????????????????? 15.95
AfriNIC Region origin ASes announcing only one prefix:????????????? 216
AfriNIC Region transit ASes present in the Internet Routing Table:? 154
Average AfriNIC Region AS path length visible:????????????????????? 4.8
??? Max AfriNIC Region AS path length visible:?????????????????????? 28
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:?? 52
Number of AfriNIC addresses announced to Internet:???????????? 59392000
??? Equivalent to 3 /8s, 138 /16s and 64 /24s
??? Percentage of available AfriNIC address space announced:?????? 59.0

AfriNIC AS Blocks????? 36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks? 41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

? ASN?? No of nets? /20 equiv? MaxAgg? Description
4766???? 2933????? 11591???????? 922?? Korea Telecom
17974???? 2811??????? 900????????? 74?? PT Telekomunikasi Indonesia
7545???? 2345??????? 336???????? 121?? TPG Telecom Limited
4755???? 1902??????? 413???????? 192?? TATA Communications formerly 
9829???? 1635?????? 1306????????? 38?? National Internet Backbone
4808???? 1396?????? 2227???????? 409?? CNCGROUP IP network China169 
9583???? 1321??????? 105???????? 542?? Sify Limited
9498???? 1302??????? 333????????? 91?? BHARTI Airtel Ltd.
7552???? 1241?????? 1098????????? 14?? Viettel Corporation
9808???? 1239?????? 6639????????? 15?? Guangdong Mobile Communicatio

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???? 2897?????? 3688????????? 51?? BellSouth.net Inc.
22773???? 2884?????? 2940???????? 142?? Cox Communications Inc.
18566???? 2045??????? 379???????? 178?? MegaPath Corporation
7029???? 1903?????? 1959???????? 320?? Windstream Communications Inc
20115???? 1780?????? 1766???????? 502?? Charter Communications
4323???? 1622?????? 1055???????? 406?? tw telecom holdings, inc.
30036???? 1522??????? 318???????? 572?? Mediacom Communications Corp
6983???? 1476??????? 817???????? 311?? ITC^Deltacom
? 701???? 1438????? 11242???????? 720?? MCI Communications Services, 
22561???? 1309??????? 408???????? 237?? CenturyTel Internet Holdings,

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
34984???? 1753??????? 299???????? 284?? TELLCOM ILETISIM HIZMETLERI A
20940???? 1470??????? 571??????? 1083?? Akamai International B.V.
8402???? 1386??????? 544????????? 15?? OJSC "Vimpelcom"
31148???? 1042???????? 45????????? 20?? Freenet Ltd.
13188???? 1013???????? 97????????? 51?? TOV "Bank-Inform"
8551????? 946??????? 371????????? 41?? Bezeq International-Ltd
6849????? 805??????? 356????????? 26?? JSC "Ukrtelecom"
12479????? 793??????? 798????????? 58?? France Telecom Espana SA
6830????? 776?????? 2335???????? 431?? Liberty Global Operations B.V
9198????? 660??????? 346????????? 28?? JSC Kazakhtelecom

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
28573???? 3053?????? 2311???????? 107?? NET Servi?os de Comunica??o S
10620???? 2951??????? 478???????? 274?? Telmex Colombia S.A.
18881???? 2100?????? 1036????????? 22?? Global Village Telecom
7303???? 1756?????? 1166???????? 233?? Telecom Argentina S.A.
6147???? 1708??????? 374????????? 30?? Telefonica del Peru S.A.A.
8151???? 1468?????? 2999???????? 434?? Uninet S.A. de C.V.
6503???? 1109??????? 434????????? 62?? Axtel, S.A.B. de C.V.
7738????? 999?????? 1882????????? 41?? Telemar Norte Leste S.A.
27947????? 908??????? 130????????? 51?? Telconet S.A
26615????? 899?????? 2325????????? 35?? Tim Celular 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
24863????? 916??????? 280????????? 26?? Link Egypt (Link.NET)
6713????? 670??????? 744????????? 37?? Office National des Postes et
8452????? 546??????? 958????????? 13?? TE-AS
36992????? 336??????? 816????????? 30?? ETISALAT MISR
24835????? 307??????? 144?????????? 9?? Vodafone Data
3741????? 249??????? 920???????? 212?? Internet Solutions
37054????? 244???????? 19?????????? 6?? Data Telecom Service
29571????? 237???????? 22????????? 17?? Cote d'Ivoire Telecom
15706????? 186???????? 17?????????? 6?? Sudatel (Sudan Telecom Co. Lt
12258????? 174???????? 26????????? 71?? MWEB CONNECT (PROPRIETARY) LI

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
28573???? 3053?????? 2311???????? 107?? NET Servi?os de Comunica??o S
10620???? 2951??????? 478???????? 274?? Telmex Colombia S.A.
4766???? 2933????? 11591???????? 922?? Korea Telecom
6389???? 2897?????? 3688????????? 51?? BellSouth.net Inc.
22773???? 2884?????? 2940???????? 142?? Cox Communications Inc.
17974???? 2811??????? 900????????? 74?? PT Telekomunikasi Indonesia
7545???? 2345??????? 336???????? 121?? TPG Telecom Limited
18881???? 2100?????? 1036????????? 22?? Global Village Telecom
18566???? 2045??????? 379???????? 178?? MegaPath Corporation
7029???? 1903?????? 1959???????? 320?? Windstream Communications Inc

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

? ASN?? No of nets? Net Savings Description
6389????? 2897??????? 2846????? BellSouth.net Inc.
22773????? 2884??????? 2742????? Cox Communications Inc.
17974????? 2811??????? 2737????? PT Telekomunikasi Indonesia
10620????? 2951??????? 2677????? Telmex Colombia S.A.
7545????? 2345??????? 2224????? TPG Telecom Limited
18881????? 2100??????? 2078????? Global Village Telecom
4766????? 2933??????? 2011????? Korea Telecom
18566????? 2045??????? 1867????? MegaPath Corporation
4755????? 1902??????? 1710????? TATA Communications formerly 
6147????? 1708??????? 1678????? Telefonica del Peru S.A.A.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS? Designation? Network????????????? Transit AS? Description
30662?? UNALLOCATED? 8.2.129.0/24????????? 3356?????? Level 3 Communicatio
53506?? UNALLOCATED? 8.17.102.0/23???????? 2828?????? XO Communications
20260?? UNALLOCATED? 8.25.160.0/24???????? 3356?????? Level 3 Communicatio
20260?? UNALLOCATED? 8.25.161.0/24???????? 3356?????? Level 3 Communicatio
46473?? UNALLOCATED? 8.27.122.0/24??????? 12180?????? Internap Network Ser
46473?? UNALLOCATED? 8.27.124.0/24??????? 12180?????? Internap Network Ser
55020?? UNALLOCATED? 8.30.123.0/24???????? 3356?????? Level 3 Communicatio
27205?? UNALLOCATED? 8.38.16.0/21????????? 6461?????? Abovenet Communicati
15347?? UNALLOCATED? 8.224.147.0/24?????? 12064?????? Cox Communications I
33628?? UNALLOCATED? 12.0.239.0/24???????? 1239?????? Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network??????????? Origin AS? Description
5.100.241.0/24?????? 23456???? 32bit Transition AS
24.231.96.0/24?????? 21548???? MTO Telecom Inc.
27.100.7.0/24??????? 56096???? >>UNKNOWN<<
37.16.88.0/23??????? 57652???? >>UNKNOWN<<
41.73.1.0/24???????? 37004???? >>UNKNOWN<<
41.73.2.0/24???????? 37004???? >>UNKNOWN<<
41.73.10.0/24??????? 37004???? >>UNKNOWN<<
41.73.11.0/24??????? 37004???? >>UNKNOWN<<
41.73.12.0/24??????? 37004???? >>UNKNOWN<<
41.73.13.0/24??????? 37004???? >>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:16?????? /9:12????? /10:31????? /11:90????? /12:262???? 
/13:504???? /14:991???? /15:1712??? /16:13047?? /17:7062??? /18:11768?? 
/19:24633?? /20:35229?? /21:37733?? /22:54535?? /23:47854?? /24:272035? 
/25:1077??? /26:1042??? /27:723???? /28:14????? /29:18????? /30:10????? 
/31:1?????? /32:12????? 

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

? ASN?? No of nets? Total ann.?? Description
22773???? 2121????????? 2884????? Cox Communications Inc.
18566???? 2000????????? 2045????? MegaPath Corporation
6389???? 1676????????? 2897????? BellSouth.net Inc.
30036???? 1371????????? 1522????? Mediacom Communications Corp
6147???? 1276????????? 1708????? Telefonica del Peru S.A.A.
6983???? 1175????????? 1476????? ITC^Deltacom
7029???? 1134????????? 1903????? Windstream Communications Inc
11492???? 1116????????? 1165????? CABLE ONE, INC.
34984???? 1074????????? 1753????? TELLCOM ILETISIM HIZMETLERI A
8402???? 1058????????? 1386????? OJSC "Vimpelcom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

?? 1:1329????? 2:664?????? 3:3???????? 4:18??????? 5:1127????? 6:21???? 
?? 8:749????? 12:1854???? 13:4??????? 14:1111???? 15:17?????? 16:2????? 
? 17:40?????? 18:21?????? 20:51?????? 23:919????? 24:1768???? 27:1763?? 
? 31:1410???? 32:39?????? 33:2??????? 34:5??????? 36:143????? 37:1773?? 
? 38:965????? 39:17?????? 40:223????? 41:2522???? 42:267????? 43:328??? 
? 44:16?????? 45:71?????? 46:2142???? 47:25?????? 49:731????? 50:822??? 
? 52:12?????? 54:51?????? 55:6??????? 56:6??????? 57:32?????? 58:1204?? 
? 59:661????? 60:426????? 61:1702???? 62:1270???? 63:1831???? 64:4366?? 
? 65:2292???? 66:4190???? 67:2014???? 68:1033???? 69:3277???? 70:864??? 
? 71:474????? 72:1998???? 74:2566???? 75:369????? 76:422????? 77:1599?? 
? 78:826????? 79:725????? 80:1303???? 81:1200???? 82:773????? 83:773??? 
? 84:729????? 85:1328???? 86:441????? 87:1159???? 88:465????? 89:1782?? 
? 90:138????? 91:5698???? 92:767????? 93:1787???? 94:1990???? 95:1604?? 
? 96:428????? 97:342????? 98:1153???? 99:48????? 100:66????? 101:713??? 
103:5590??? 104:228???? 105:38????? 106:182???? 107:635???? 108:568??? 
109:1980??? 110:1029??? 111:1359??? 112:720???? 113:862???? 114:778??? 
115:1209??? 116:1123??? 117:992???? 118:1559??? 119:1409??? 120:433??? 
121:963???? 122:2195??? 123:1614??? 124:1431??? 125:1579??? 128:608??? 
129:348???? 130:364???? 131:764???? 132:428???? 133:165???? 134:320??? 
135:76????? 136:304???? 137:290???? 138:384???? 139:204???? 140:213??? 
141:413???? 142:580???? 143:434???? 144:511???? 145:114???? 146:682??? 
147:554???? 148:970???? 149:433???? 150:482???? 151:602???? 152:468??? 
153:243???? 154:338???? 155:535???? 156:357???? 157:328???? 158:275??? 
159:931???? 160:324???? 161:592???? 162:1720??? 163:348???? 164:702??? 
165:659???? 166:363???? 167:681???? 168:1120??? 169:123???? 170:1394?? 
171:184???? 172:62????? 173:1619??? 174:708???? 175:605???? 176:1499?? 
177:3581??? 178:2077??? 179:764???? 180:1777??? 181:1579??? 182:1654?? 
183:553???? 184:716???? 185:2049??? 186:2955??? 187:1700??? 188:2208?? 
189:1474??? 190:7824??? 191:747???? 192:7532??? 193:5501??? 194:4048?? 
195:3565??? 196:1414??? 197:660???? 198:5139??? 199:5462??? 200:6471?? 
201:2855??? 202:9151??? 203:9011??? 204:4552??? 205:2651??? 206:2950?? 
207:2925??? 208:3918??? 209:3761??? 210:3304??? 211:1834??? 212:2335?? 
213:2145??? 214:860???? 215:86????? 216:5624??? 217:1705??? 218:614??? 
219:408???? 220:1366??? 221:686???? 222:484???? 223:598??? 

End of report


------------------------------

Message: 2
Date: Fri, 12 Sep 2014 22:00:00 GMT
From: cidr-report at potaroo.net
To: cidr-report at potaroo.net
Cc: nanog at nanog.org, routing-wg at ripe.net, apops at apops.net,
eof-list at ripe.net, afnog at afnog.org
Subject: The Cidr Report
Message-ID: <201409122200.s8CM00Xv056928 at wattle.apnic.net>

This report has been generated at Fri Sep 12 21:14:14 2014 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/2.0 for a current version of this report.

Recent Table History
??????? Date????? Prefixes??? CIDR Agg
??????? 05-09-14??? 515023????? 284407
??????? 06-09-14??? 515306????? 284358
??????? 07-09-14??? 515397????? 284522
??????? 08-09-14??? 515833????? 284494
??????? 09-09-14??? 515844????? 284760
??????? 10-09-14??? 515949????? 284121
??????? 11-09-14??? 510621????? 284307
??????? 12-09-14??? 515908????? 284348


AS Summary
???????? 48248? Number of ASes in routing system
???????? 19517? Number of ASes announcing only one prefix
????????? 3051? Largest number of prefixes announced by an AS
??????????????? AS28573: NET Servi?os de Comunica??o S.A.,BR
????? 120167168? Largest address span announced by an AS (/32s)
??????????????? AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


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').

--- 12Sep14 ---
ASnum??? NetsNow NetsAggr? NetGain?? % Gain?? Description

Table???? 515956?? 284380?? 231576??? 44.9%?? All ASes

AS28573???? 3051????? 124???? 2927??? 95.9%?? NET Servi?os de Comunica??o
?????????????????????????????????????????????? S.A.,BR
AS6389????? 2894?????? 79???? 2815??? 97.3%?? BELLSOUTH-NET-BLK -
?????????????????????????????????????????????? BellSouth.net Inc.,US
AS17974???? 2812?????? 80???? 2732??? 97.2%?? TELKOMNET-AS2-AP PT
?????????????????????????????????????????????? Telekomunikasi Indonesia,ID
AS22773???? 2881????? 173???? 2708??? 94.0%?? ASN-CXA-ALL-CCI-22773-RDC -
?????????????????????????????????????????????? Cox Communications Inc.,US
AS18881???? 2100????? 113???? 1987??? 94.6%?? Global Village Telecom,BR
AS4766????? 2934???? 1198???? 1736??? 59.2%?? KIXS-AS-KR Korea Telecom,KR
AS4755????? 1900????? 232???? 1668??? 87.8%?? TATACOMM-AS TATA
?????????????????????????????????????????????? Communications formerly VSNL
?????????????????????????????????????????????? is Leading ISP,IN
AS6147????? 1735????? 164???? 1571??? 90.5%?? Telefonica del Peru S.A.A.,PE
AS7303????? 1761????? 284???? 1477??? 83.9%?? Telecom Argentina S.A.,AR
AS8402????? 1358?????? 23???? 1335??? 98.3%?? CORBINA-AS OJSC "Vimpelcom",RU
AS4323????? 1634????? 412???? 1222??? 74.8%?? TWTC - tw telecom holdings,
?????????????????????????????????????????????? inc.,US
AS7552????? 1263?????? 58???? 1205??? 95.4%?? VIETEL-AS-AP Viettel
?????????????????????????????????????????????? Corporation,VN
AS20115???? 1781????? 576???? 1205??? 67.7%?? CHARTER-NET-HKY-NC - Charter
?????????????????????????????????????????????? Communications,US
AS7545????? 2361???? 1162???? 1199??? 50.8%?? TPG-INTERNET-AP TPG Telecom
?????????????????????????????????????????????? Limited,AU
AS9808????? 1239?????? 42???? 1197??? 96.6%?? CMNET-GD Guangdong Mobile
?????????????????????????????????????????????? Communication Co.Ltd.,CN
AS9498????? 1304????? 109???? 1195??? 91.6%?? BBIL-AP BHARTI Airtel Ltd.,IN
AS18566???? 2044????? 862???? 1182??? 57.8%?? MEGAPATH5-US - MegaPath
?????????????????????????????????????????????? Corporation,US
AS10620???? 2951???? 1854???? 1097??? 37.2%?? Telmex Colombia S.A.,CO
AS22561???? 1308????? 263???? 1045??? 79.9%?? AS22561 - CenturyTel Internet
?????????????????????????????????????????????? Holdings, Inc.,US
AS7029????? 1996???? 1023????? 973??? 48.7%?? WINDSTREAM - Windstream
?????????????????????????????????????????????? Communications Inc,US
AS7738?????? 999?????? 83????? 916??? 91.7%?? Telemar Norte Leste S.A.,BR
AS6983????? 1476????? 616????? 860??? 58.3%?? ITCDELTA - Earthlink, Inc.,US
AS24560???? 1173????? 333????? 840??? 71.6%?? AIRTELBROADBAND-AS-AP Bharti
?????????????????????????????????????????????? Airtel Ltd., Telemedia
?????????????????????????????????????????????? Services,IN
AS4788????? 1052????? 231????? 821??? 78.0%?? TMNET-AS-AP TM Net, Internet
?????????????????????????????????????????????? Service Provider,MY
AS38285????? 957????? 143????? 814??? 85.1%?? M2TELECOMMUNICATIONS-AU M2
?????????????????????????????????????????????? Telecommunications Group
?????????????????????????????????????????????? Ltd,AU
AS9829????? 1635????? 825????? 810??? 49.5%?? BSNL-NIB National Internet
?????????????????????????????????????????????? Backbone,IN
AS8151????? 1477????? 701????? 776??? 52.5%?? Uninet S.A. de C.V.,MX
AS4780????? 1027????? 254????? 773??? 75.3%?? SEEDNET Digital United Inc.,TW
AS26615????? 899????? 127????? 772??? 85.9%?? Tim Celular S.A.,BR
AS18101????? 955????? 194????? 761??? 79.7%?? RELIANCE-COMMUNICATIONS-IN
?????????????????????????????????????????????? Reliance Communications
?????????????????????????????????????????????? Ltd.DAKC MUMBAI,IN

Total????? 52957??? 12338??? 40619??? 76.7%?? Top 30 total


Possible Bogus Routes

??????? 5.100.241.0/24?????? AS19957 -Reserved AS-,ZZ
??????? 24.231.96.0/24?????? AS21548 MTO - MTO Telecom Inc.,CA
??????? 27.100.7.0/24??????? AS56096 
??????? 37.16.88.0/23??????? AS57652 -Reserved AS-,ZZ
??????? 41.73.1.0/24???????? AS37004 -Reserved AS-,ZZ
??????? 41.73.2.0/24???????? AS37004 -Reserved AS-,ZZ
??????? 41.73.10.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.11.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.12.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.13.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.14.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.15.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.16.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.18.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.20.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.73.21.0/24??????? AS37004 -Reserved AS-,ZZ
??????? 41.76.48.0/21??????? AS36969 MTL-AS,MW
??????? 41.78.120.0/23?????? AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US
??????? 41.78.180.0/23?????? AS37265 -Reserved AS-,ZZ
??????? 41.189.96.0/20?????? AS37000 -Reserved AS-,ZZ
??????? 41.191.108.0/22????? AS37004 -Reserved AS-,ZZ
??????? 41.191.108.0/24????? AS37004 -Reserved AS-,ZZ
??????? 41.191.109.0/24????? AS37004 -Reserved AS-,ZZ
??????? 41.191.110.0/24????? AS37004 -Reserved AS-,ZZ
??????? 41.191.111.0/24????? AS37004 -Reserved AS-,ZZ
??????? 41.223.208.0/22????? AS37000 -Reserved AS-,ZZ
??????? 43.243.152.0/23????? AS58514 SUPERNET-AS-ID PT. Supernet Advance Teknologi,ID
??????? 62.193.160.0/19????? AS24801 -Reserved AS-,ZZ
??????? 62.193.160.0/20????? AS24801 -Reserved AS-,ZZ
??????? 62.193.176.0/20????? AS24801 -Reserved AS-,ZZ
??????? 64.25.16.0/23??????? AS19535 -Reserved AS-,ZZ
??????? 64.25.20.0/24??????? AS19535 -Reserved AS-,ZZ
??????? 64.25.21.0/24??????? AS19535 -Reserved AS-,ZZ
??????? 64.25.22.0/24??????? AS19535 -Reserved AS-,ZZ
??????? 64.25.27.0/24??????? AS7046? RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US
??????? 64.111.160.0/20????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.160.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.161.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.162.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.167.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.169.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.170.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.171.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.172.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.173.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.174.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 64.111.175.0/24????? AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
??????? 65.75.216.0/23?????? AS10494 AAI - Accurate Automation, Inc.,US
??????? 65.75.217.0/24?????? AS10494 AAI - Accurate Automation, Inc.,US
??????? 65.111.1.0/24??????? AS32258 SDNGLOBAL - SDN Global,US
??????? 66.55.96.0/23??????? AS17203 -Reserved AS-,ZZ
??????? 66.55.98.0/24??????? AS17203 -Reserved AS-,ZZ
??????? 66.55.99.0/24??????? AS17203 -Reserved AS-,ZZ
??????? 66.55.100.0/22?????? AS17203 -Reserved AS-,ZZ
??????? 66.55.102.0/23?????? AS17203 -Reserved AS-,ZZ
??????? 66.55.104.0/21?????? AS17203 -Reserved AS-,ZZ
??????? 66.180.64.0/21?????? AS32558 ZEUTER - Zeuter Development Corporation,CA
??????? 66.187.240.0/20????? AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US
??????? 66.205.224.0/19????? AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
??????? 66.251.128.0/24????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 66.251.133.0/24????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 66.251.134.0/24????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 66.251.136.0/21????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 66.251.140.0/24????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 66.251.141.0/24????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 66.251.142.0/24????? AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
??????? 71.19.134.0/23?????? AS3313? INET-AS BT Italia S.p.A.,IT
??????? 72.19.0.0/19???????? AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
??????? 74.112.100.0/22????? AS16764 -Reserved AS-,ZZ
??????? 74.113.200.0/23????? AS46939 -Reserved AS-,ZZ
??????? 74.114.52.0/22?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.52.0/23?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.52.0/24?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.53.0/24?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.54.0/23?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.54.0/24?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.55.0/24?????? AS40818 -Reserved AS-,ZZ
??????? 74.114.184.0/22????? AS19888 -Reserved AS-,ZZ
??????? 74.118.132.0/22????? AS5117? -Reserved AS-,ZZ
??????? 74.120.212.0/23????? AS32326 -Reserved AS-,ZZ
??????? 74.120.214.0/23????? AS32326 -Reserved AS-,ZZ
??????? 74.121.24.0/22?????? AS36263 FORONA - Forona Technologies, Inc.,US
??????? 74.123.136.0/21????? AS53358 -Reserved AS-,ZZ
??????? 77.243.80.0/24?????? AS42597 -Reserved AS-,ZZ
??????? 77.243.81.0/24?????? AS42597 -Reserved AS-,ZZ
??????? 77.243.88.0/24?????? AS42597 -Reserved AS-,ZZ
??????? 77.243.91.0/24?????? AS42597 -Reserved AS-,ZZ
??????? 77.243.94.0/24?????? AS42597 -Reserved AS-,ZZ
??????? 77.243.95.0/24?????? AS42597 -Reserved AS-,ZZ
??????? 80.78.133.0/24?????? AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
??????? 80.78.134.0/23?????? AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
??????? 80.78.134.0/24?????? AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
??????? 80.78.135.0/24?????? AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
??????? 80.250.32.0/22?????? AS37106 ODUA-AS,NG
??????? 85.202.160.0/20????? AS44404 -Reserved AS-,ZZ
??????? 89.31.24.0/23??????? AS41455 -Reserved AS-,ZZ
??????? 89.31.26.0/23??????? AS41455 -Reserved AS-,ZZ
??????? 89.31.28.0/22??????? AS41455 -Reserved AS-,ZZ
??????? 91.193.60.0/22?????? AS3356? LEVEL3 - Level 3 Communications, Inc.,US
??????? 91.195.66.0/23?????? AS3356? LEVEL3 - Level 3 Communications, Inc.,US
??????? 91.197.36.0/22?????? AS43359 -Reserved AS-,ZZ
??????? 91.199.90.0/24?????? AS44330 -Reserved AS-,ZZ
??????? 91.209.115.0/24????? AS31103 KEYWEB-AS Keyweb AG,DE
??????? 91.228.160.0/24????? AS35557 GRITSENKO-AS PE GRITSENKO NADEJDA NIKOLAEVNA,UA
??????? 91.239.157.0/24????? AS24958 TBSH The Bunker Secure Hosting Limited,GB
??????? 93.190.10.0/24?????? AS47254 -Reserved AS-,ZZ
??????? 100.65.0.0/24??????? AS4826? VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU
??????? 102.2.88.0/22??????? AS38456 PACTEL-AS-AP Pacific Teleports. ,AU
??????? 103.6.108.0/22?????? AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN
??????? 103.9.108.0/22?????? AS4725? ODN SOFTBANK TELECOM Corp.,JP
??????? 103.15.92.0/22?????? AS23818 JETINTERNET JETINTERNET Corporation,JP
??????? 103.18.76.0/22?????? AS18097 DCN D.C.N. Corporation,JP
??????? 103.18.92.0/22?????? AS13269 
??????? 103.18.92.0/24?????? AS13269 
??????? 103.18.94.0/24?????? AS13269 
??????? 103.18.248.0/22????? AS18097 DCN D.C.N. Corporation,JP
??????? 103.19.0.0/22??????? AS18097 DCN D.C.N. Corporation,JP
??????? 103.20.100.0/24????? AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
??????? 103.20.101.0/24????? AS45334 AIRCEL-AS-AP Dishne

From larrysheldon at cox.net  Sun Sep 14 05:57:28 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sun, 14 Sep 2014 00:57:28 -0500
Subject: NANOG Digest, Vol 80, Issue 13
In-Reply-To: <qtV21o00H1cZc5601tV4Sb>
References: <qtV21o00H1cZc5601tV4Sb>
Message-ID: <54152E48.3060307@cox.net>

On 9/13/2014 17:12, Tor Nystrom wrote:
> Sure np. I will pull the same data tomorrow and then again on Friday and from there on I will do it every Friday.


[snip]

> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."

-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


From sam at spacething.org  Sun Sep 14 17:45:31 2014
From: sam at spacething.org (Sam Stickland)
Date: Sun, 14 Sep 2014 18:45:31 +0100
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <CAL9jLaZXN4Tsr+1iktzVqM7AQSorbvvgBkHK8QP_P2GWF-UsDA@mail.gmail.com>
References: <20140907121718.43C44FB1@m0005298.ppops.net>
 <21517.59177.373564.333891@world.std.com>
 <CAL9jLaZXN4Tsr+1iktzVqM7AQSorbvvgBkHK8QP_P2GWF-UsDA@mail.gmail.com>
Message-ID: <CAAQt0oPjhddQO+G=_OhNFmvGLDezHfutYRbTjfdCji1SgHJY=w@mail.gmail.com>

Slightly off topic, but has there ever been a proposed protocol where hosts
can register their L2/L3 binding with their connected switch (which could
then propagate the binding to other switches in the Layer 2 domain)?
Further discovery requests (e.g. ARP, ND) from other attached hosts could
then all be directly replied, eliminating broadcast gratuitous arps. If the
switches don't support the protocol they would default to flooding the
discovery requests.

It seems to me that so many network are caused because of the inability to
change the host mechanisms.

Sam

On Mon, Sep 8, 2014 at 7:30 PM, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> On Mon, Sep 8, 2014 at 1:28 PM, Barry Shein <bzs at world.std.com> wrote:
> >
> > Reading the article what occurs to me is:
> >
> > IPv4 requires a certain amount of administrative personnel overhead.
> >
> > It's relatively low which is certainly one reason for the success of
> > IPv4. People are expensive so any new, pervasive technology will be
> > judged at least in part on its personnel requirements.
> >
> > I'd go so far as to say that administering large IPv4 networks grows
> > in personnel roughly as the log of the number of nodes.
>
> surely this depends a LOT on the quality of the folk doing this job
> and their foresight in automating as much as possible, no? (probably
> this point isn't for debate, but the point is any network can be run
> badly)
>
> > If what this is telling us, or warning us, is that IPv6 networks
> > require higher personnel costs then that could become a big issue.
>
> is this a reflection of 'new technology' to the users (network folk)
> in question?
> What in ipv6 networking is inherently 'more people required' than ipv4
> networking?
>
> >
> > Particularly among management where they've become used to a few to
> > several people in a team running the heart of quite large networks.
> >
> > What if IPv6 deployment doubles or triples that personnel requirement
> > for the same quality of administration?
>
> this sounds, to me, like: "People need training or comfort with :
> instead of . in 'ip address' stuff..." (and other similar differences
> between how v4 and v6 operate at scale)
>
> > Does anyone know of any studies along these lines? My guess is that
> > there isn't enough data yet.
>
> that sounds reasonable.
>


From mpetach at netflight.com  Sun Sep 14 18:20:04 2014
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 14 Sep 2014 11:20:04 -0700
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <CAAQt0oPjhddQO+G=_OhNFmvGLDezHfutYRbTjfdCji1SgHJY=w@mail.gmail.com>
References: <20140907121718.43C44FB1@m0005298.ppops.net>
 <21517.59177.373564.333891@world.std.com>
 <CAL9jLaZXN4Tsr+1iktzVqM7AQSorbvvgBkHK8QP_P2GWF-UsDA@mail.gmail.com>
 <CAAQt0oPjhddQO+G=_OhNFmvGLDezHfutYRbTjfdCji1SgHJY=w@mail.gmail.com>
Message-ID: <CAEmG1=pxN5htbqtO8_oguepoY4VRg5cCaV8iFD6QxQG15z84eg@mail.gmail.com>

On Sun, Sep 14, 2014 at 10:45 AM, Sam Stickland <sam at spacething.org> wrote:

> Slightly off topic, but has there ever been a proposed protocol where hosts
> can register their L2/L3 binding with their connected switch (which could
> then propagate the binding to other switches in the Layer 2 domain)?
> Further discovery requests (e.g. ARP, ND) from other attached hosts could
> then all be directly replied, eliminating broadcast gratuitous arps. If the
> switches don't support the protocol they would default to flooding the
> discovery requests.
>
> It seems to me that so many network are caused because of the inability to
> change the host mechanisms.
>
> Sam
>


It looks like in 2011 Cisco proposed a
technology called "OTV" that would do
just that, according to this page:
 http://network-101.blogspot.com/2011/03/otv-vs-vpls.html
Granted, it was aimed for wide-area
networking, rather than control within
a datacenter; but as everyone who has
started doing BGP to their top of rack
switches has learned, there's often good
value in adopting techniques and protocols
used in the wide area network within the
datacenter as well.

However, I haven't heard recent mention
of it, so I'm guessing it failed to make a
big enough splash to get any widespread
adoption.

Matt


From mysidia at gmail.com  Sun Sep 14 21:19:42 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 14 Sep 2014 16:19:42 -0500
Subject: 2000::/6
In-Reply-To: <54141D81.30800@lanparty.ee>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com> <54141D81.30800@lanparty.ee>
Message-ID: <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>

On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan <tarko at lanparty.ee> wrote:
> 2000::/64 has nothing to do with it.
>
> Any address between 2000:0000:0000:0000:0000:0000:0000:0000 and
> 23ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff together with misconfigured prefix
> length (6 instead 64) becomes 2000::/6 prefix.

It should be rejected for the same reason that  192.168.10.0/16 is
invalid in a prefix list  or access list.

Any decent router won't allow you to enter just anything in that range
into the export rules  with a /6,  except 2000::  itself, and will
even show you a failure response instead of silently ignoring the
invalid input,  for the very purpose of helping you avoid such errors.
   2001::1/6  would be an example of an invalid input --  there are
one or more non-zero bits listed outside the prefix, or where  bits in
the mask are zero.

Only 2000:0000:0000:0000:0000:0000:0000:0000/6    properly conforms,
not just "any IP"   in that range  can have a /6  appended to the end.


-- 
-JH


From nick at foobar.org  Sun Sep 14 21:34:59 2014
From: nick at foobar.org (Nick Hilliard)
Date: Sun, 14 Sep 2014 22:34:59 +0100
Subject: 2000::/6
In-Reply-To: <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>
 <54141D81.30800@lanparty.ee>
 <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
Message-ID: <54160A03.4060608@foobar.org>

On 14/09/2014 22:19, Jimmy Hess wrote:
> Any decent router won't allow you to enter just anything in that range
> into the export rules  with a /6,  except 2000::  itself

tarko is right in suggesting that config typos can cause this sort of
thing, e.g.

--
router bgp 65555
address-family ipv6
 redistribute static

ipv6 route 2001:418:3ef:1000::/6 2001:db8::1
--

Bear in mind that the "network" statement in the router bgp stanza on cisco
routers is only one of several methods of injecting prefixes into a bgp
rib, and is a method that many people routinely avoid because it means
duplication of configuration: each network statement requires a grounding
"ip{v6} route" statement in order to work stably.  So why not combine the two?

Nick



From rbf+nanog at panix.com  Sun Sep 14 21:39:42 2014
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Sun, 14 Sep 2014 16:39:42 -0500
Subject: 2000::/6
In-Reply-To: <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>
 <54141D81.30800@lanparty.ee>
 <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
Message-ID: <20140914213942.GA24812@panix.com>

On Sun, Sep 14, 2014 at 04:19:42PM -0500, Jimmy Hess wrote:
> On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan <tarko at lanparty.ee> wrote:
> > 2000::/64 has nothing to do with it.
> >
> > Any address between 2000:0000:0000:0000:0000:0000:0000:0000 and
> > 23ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff together with misconfigured prefix
> > length (6 instead 64) becomes 2000::/6 prefix.
> 
> It should be rejected for the same reason that  192.168.10.0/16 is
> invalid in a prefix list  or access list.

RTR(config)#ip prefix-list TEST permit 192.168.10.0/16
RTR(config)#do sho ip prefix-list TEST
ip prefix-list TEST: 1 entries
   seq 5 permit 192.168.0.0/16

This isn't surprising to people who've been using IOS for a while ...
 
> Any decent router won't allow you to enter just anything in that range
> into the export rules  with a /6,  except 2000::  itself, and will
> even show you a failure response instead of silently ignoring the
> invalid input,  for the very purpose of helping you avoid such errors.

Well, unfortunately, a lot of us have (as you define the term) indecent
routers.

RTR(config)#ipv6 prefix-list TEST permit 2000:1111::/6
RTR(config)#do sho ipv6 prefix-list TEST
ipv6 prefix-list TEST: 1 entries
   seq 5 permit 2000::/6

>    2001::1/6  would be an example of an invalid input --  there are
> one or more non-zero bits listed outside the prefix, or where  bits in
> the mask are zero.
> 
> Only 2000:0000:0000:0000:0000:0000:0000:0000/6    properly conforms,
> not just "any IP"   in that range  can have a /6  appended to the end.

     -- Brett


From bep at whack.org  Mon Sep 15 06:29:59 2014
From: bep at whack.org (Bruce Pinsky)
Date: Sun, 14 Sep 2014 23:29:59 -0700
Subject: Fwd: Interesting problems with using IPv6
In-Reply-To: <CAEmG1=pxN5htbqtO8_oguepoY4VRg5cCaV8iFD6QxQG15z84eg@mail.gmail.com>
References: <20140907121718.43C44FB1@m0005298.ppops.net>
 <21517.59177.373564.333891@world.std.com>
 <CAL9jLaZXN4Tsr+1iktzVqM7AQSorbvvgBkHK8QP_P2GWF-UsDA@mail.gmail.com>
 <CAAQt0oPjhddQO+G=_OhNFmvGLDezHfutYRbTjfdCji1SgHJY=w@mail.gmail.com>
 <CAEmG1=pxN5htbqtO8_oguepoY4VRg5cCaV8iFD6QxQG15z84eg@mail.gmail.com>
Message-ID: <54168767.6010506@whack.org>

On 9/14/2014 11:20 AM, Matthew Petach wrote:
> On Sun, Sep 14, 2014 at 10:45 AM, Sam Stickland <sam at spacething.org> wrote:
> 
>> Slightly off topic, but has there ever been a proposed protocol where hosts
>> can register their L2/L3 binding with their connected switch (which could
>> then propagate the binding to other switches in the Layer 2 domain)?
>> Further discovery requests (e.g. ARP, ND) from other attached hosts could
>> then all be directly replied, eliminating broadcast gratuitous arps. If the
>> switches don't support the protocol they would default to flooding the
>> discovery requests.
>>
>> It seems to me that so many network are caused because of the inability to
>> change the host mechanisms.
>>
>> Sam
>>
> 
> 
> It looks like in 2011 Cisco proposed a
> technology called "OTV" that would do
> just that, according to this page:
>  http://network-101.blogspot.com/2011/03/otv-vs-vpls.html
> Granted, it was aimed for wide-area
> networking, rather than control within
> a datacenter; but as everyone who has
> started doing BGP to their top of rack
> switches has learned, there's often good
> value in adopting techniques and protocols
> used in the wide area network within the
> datacenter as well.
> 
> However, I haven't heard recent mention
> of it, so I'm guessing it failed to make a
> big enough splash to get any widespread
> adoption.
>

Also consider the emergence of eVPN and PBB-eVPN.

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=5998&tclass=popup

-- 
=========
bep


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3750 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140914/0adceecb/attachment.bin>

From gambare08 at yahoo.com  Mon Sep 15 11:50:03 2014
From: gambare08 at yahoo.com (lek)
Date: Mon, 15 Sep 2014 11:50:03 +0000 (UTC)
Subject: CEF problem - Traffic forwarding
References: <1834275486.12369853.1410374130493.JavaMail.zimbra@noor.net>
 <1799777542.12370051.1410374489186.JavaMail.zimbra@noor.net>
Message-ID: <loom.20140915T134635-853@post.gmane.org>

Hello Mohamed,

Your cef has load sharing disabled on the interface.
>  no ip load-sharing per-longest-match-prefix

regards,



From mkamal at noor.net  Mon Sep 15 12:05:32 2014
From: mkamal at noor.net (Mohamed Kamal)
Date: Mon, 15 Sep 2014 15:05:32 +0300
Subject: CEF problem - Traffic forwarding
In-Reply-To: <loom.20140915T134635-853@post.gmane.org>
References: <1834275486.12369853.1410374130493.JavaMail.zimbra@noor.net>
 <1799777542.12370051.1410374489186.JavaMail.zimbra@noor.net>
 <loom.20140915T134635-853@post.gmane.org>
Message-ID: <5416D60C.1060408@noor.net>


On 9/15/2014 2:50 PM, lek wrote:
> Hello Mohamed,
>
> Your cef has load sharing disabled on the interface.
>> >  no ip load-sharing per-longest-match-prefix
Yes, and when I try to configure ip load-sharing per-destination, I get 
the following error message:

%Cannot change the load sharing mode: Per-session QoS

Regards,

Mohamed Kamal
Network Engineer, Core Team

NOOR Data Networks, SAE

City Stars Capital 5 A4
Omar Ibn El Khattab Street
Heliopolis, Cairo, Egypt

Mobile GSM.: +2  0100 29 49 691
Land Line.:  +20 2 16700  Ext.: 139
Fax.:        +20 2 3748 2816
Email.:      mkamal at noor.net




From tglassey at earthlink.net  Mon Sep 15 13:19:02 2014
From: tglassey at earthlink.net (todd)
Date: Mon, 15 Sep 2014 06:19:02 -0700
Subject: question  - is there any tracking about how much bittorrent traffic
 there is across the various ISP's
Message-ID: <5416E746.1010706@earthlink.net>

I am looking for numbers on the amount of BitTorrent traffic flowing 
around the Internet today. Any idea where I could find both numbers of 
events and bytes used info?

Todd
-- 
Thanks,
Todd S. Glassey
[Personal Email]
---------------------------
This email may contain confidential material protected as trade secrets 
and the like and as such is by default considered private and 
confidential in form. Without the word "PUBLIC:" as the opening tag in 
the Subject Line this email is to be considered confidential and may not 
be reproduced or excerpted in any form or disclosed to any unauthorized 
parties in any form; If this mail was forwarded or incorrectly sent to 
you please destroy it immediately.


From tarko at lanparty.ee  Mon Sep 15 14:24:09 2014
From: tarko at lanparty.ee (Tarko Tikan)
Date: Mon, 15 Sep 2014 17:24:09 +0300
Subject: 2000::/6
In-Reply-To: <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>
 <54141D81.30800@lanparty.ee>
 <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
Message-ID: <5416F689.1050206@lanparty.ee>

hey,

> Any decent router won't allow you to enter just anything in that range
> into the export rules  with a /6,  except 2000::  itself, and will
> even show you a failure response instead of silently ignoring the
> invalid input,  for the very purpose of helping you avoid such errors.

IOS was already brought up, luckily Junos and TIMOS do just that (both 
for prefix-lists and static routes). Unfortunately directly connected 
networks remain and there is no way to solve that.

-- 
tarko


From lnguyen at opsource.net  Mon Sep 15 13:23:44 2014
From: lnguyen at opsource.net (Luan Nguyen)
Date: Mon, 15 Sep 2014 09:23:44 -0400
Subject: QSFP 40G breakout cable
Message-ID: <CADR+d4bihS_c3+aQCbLCNg4FYN1ydQ-XCm-_e3qPtv32FtHqTA@mail.gmail.com>

Hi folks,
Anyone from the northern VA area has a couple extra of these? I'd like to
borrow for a couple days to see if they work in other vendors' equipment?
Believe it or not, Cisco' s one is much cheaper.

Thanks!

rg/lmn


From jwbensley at gmail.com  Tue Sep 16 08:48:45 2014
From: jwbensley at gmail.com (James Bensley)
Date: Tue, 16 Sep 2014 09:48:45 +0100
Subject: Book / Literature Recommendations
Message-ID: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>

Hi All,

What is the single best book you have read on networking? That's a
wide topic so to clarify I'm talking about service provider networking
but I do enjoy all aspects really and don't want to limit my self to
one area of networking.

I'm often reading technical books about technology X or protocol Y but
they are generally explaining a new technology to me, how it works and
how to use it (and how to configure it if its a book by a vendor like
Juniper or Cisco). That is usually a learning exercise though required
for an upcoming project or deliverable.

I haven't read many vendor neutral books recently that explained
concepts, or technologies, or paradigms that I found profound, radical
and extremely useful.

I feel like I'm just reading networking books these days to learn a
new technology for a period of time (until a project completes) then
moving on to the next technology (book). Longevity of the information
doesn't seem as profound as it used to; BGP design principals will
stay with me for decades until we reach the need for BGP v5 or
similar, learning about 8b/10b encoding was interesting but not really
required for my line of work more out of hobbyist interest and serves
no practical purpose as a network engineer.


Cheers,
James.


From raaki.88 at gmail.com  Tue Sep 16 09:00:52 2014
From: raaki.88 at gmail.com (Rakesh M)
Date: Tue, 16 Sep 2014 14:30:52 +0530
Subject: Book / Literature Recommendations
In-Reply-To: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
Message-ID: <CAC2aK2oYaJK86YnbjQ8-qSGOJMH9gVKgafPry--A78vcnKS5Yg@mail.gmail.com>

i found mpls enabled applications better, not sure if that meets your
requirement.


R

On Tue, Sep 16, 2014 at 2:18 PM, James Bensley <jwbensley at gmail.com> wrote:

> Hi All,
>
> What is the single best book you have read on networking? That's a
> wide topic so to clarify I'm talking about service provider networking
> but I do enjoy all aspects really and don't want to limit my self to
> one area of networking.
>
> I'm often reading technical books about technology X or protocol Y but
> they are generally explaining a new technology to me, how it works and
> how to use it (and how to configure it if its a book by a vendor like
> Juniper or Cisco). That is usually a learning exercise though required
> for an upcoming project or deliverable.
>
> I haven't read many vendor neutral books recently that explained
> concepts, or technologies, or paradigms that I found profound, radical
> and extremely useful.
>
> I feel like I'm just reading networking books these days to learn a
> new technology for a period of time (until a project completes) then
> moving on to the next technology (book). Longevity of the information
> doesn't seem as profound as it used to; BGP design principals will
> stay with me for decades until we reach the need for BGP v5 or
> similar, learning about 8b/10b encoding was interesting but not really
> required for my line of work more out of hobbyist interest and serves
> no practical purpose as a network engineer.
>
>
> Cheers,
> James.
>


From rdobbins at arbor.net  Tue Sep 16 09:04:09 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Tue, 16 Sep 2014 16:04:09 +0700
Subject: Book / Literature Recommendations
In-Reply-To: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
Message-ID: <50AC5B51-EC7D-445E-A0E9-8B6B287FD925@arbor.net>


On Sep 16, 2014, at 3:48 PM, James Bensley <jwbensley at gmail.com> wrote:

> What is the single best book you have read on networking? 

Impossible to answer with just one, really.

Apart from the classics like Stevens and Perlman and Halabi and McPherson and Doyle, these two:

<http://www.ciscopress.com/store/router-security-strategies-securing-ip-network-traffic-9781587053368>

<http://www.ciscopress.com/store/mpls-vpn-security-9781587051838>

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

                   Equo ne credite, Teucri.

    		   	  -- Laoco?n



From matthew at matthew.at  Tue Sep 16 09:07:50 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 16 Sep 2014 11:07:50 +0200
Subject: Book / Literature Recommendations
In-Reply-To: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
Message-ID: <2A3F4518-570F-4140-B1BA-F27F554EE47D@matthew.at>

"Patterns in Network Architecture"

You might not agree with it, but it does stimulate some thinking.

Matthew Kaufman

(Sent from my iPhone)

> On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley at gmail.com> wrote:
> 
> Hi All,
> 
> What is the single best book you have read on networking? That's a
> wide topic so to clarify I'm talking about service provider networking
> but I do enjoy all aspects really and don't want to limit my self to
> one area of networking.
> 
> I'm often reading technical books about technology X or protocol Y but
> they are generally explaining a new technology to me, how it works and
> how to use it (and how to configure it if its a book by a vendor like
> Juniper or Cisco). That is usually a learning exercise though required
> for an upcoming project or deliverable.
> 
> I haven't read many vendor neutral books recently that explained
> concepts, or technologies, or paradigms that I found profound, radical
> and extremely useful.
> 
> I feel like I'm just reading networking books these days to learn a
> new technology for a period of time (until a project completes) then
> moving on to the next technology (book). Longevity of the information
> doesn't seem as profound as it used to; BGP design principals will
> stay with me for decades until we reach the need for BGP v5 or
> similar, learning about 8b/10b encoding was interesting but not really
> required for my line of work more out of hobbyist interest and serves
> no practical purpose as a network engineer.
> 
> 
> Cheers,
> James.


From jason at biel-tech.com  Tue Sep 16 10:04:00 2014
From: jason at biel-tech.com (Jason Biel)
Date: Tue, 16 Sep 2014 05:04:00 -0500
Subject: Book / Literature Recommendations
In-Reply-To: <2A3F4518-570F-4140-B1BA-F27F554EE47D@matthew.at>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <2A3F4518-570F-4140-B1BA-F27F554EE47D@matthew.at>
Message-ID: <CAGpNY1EfNyK1rr5_NSf-V33FKiRxp7p=XND2ciu=Je7wCgLJJA@mail.gmail.com>

BGP Bible:
Internet Routing Architectures (2nd Edition)
http://amzn.com/157870233X

On Tue, Sep 16, 2014 at 4:07 AM, Matthew Kaufman <matthew at matthew.at> wrote:

> "Patterns in Network Architecture"
>
> You might not agree with it, but it does stimulate some thinking.
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> > On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley at gmail.com> wrote:
> >
> > Hi All,
> >
> > What is the single best book you have read on networking? That's a
> > wide topic so to clarify I'm talking about service provider networking
> > but I do enjoy all aspects really and don't want to limit my self to
> > one area of networking.
> >
> > I'm often reading technical books about technology X or protocol Y but
> > they are generally explaining a new technology to me, how it works and
> > how to use it (and how to configure it if its a book by a vendor like
> > Juniper or Cisco). That is usually a learning exercise though required
> > for an upcoming project or deliverable.
> >
> > I haven't read many vendor neutral books recently that explained
> > concepts, or technologies, or paradigms that I found profound, radical
> > and extremely useful.
> >
> > I feel like I'm just reading networking books these days to learn a
> > new technology for a period of time (until a project completes) then
> > moving on to the next technology (book). Longevity of the information
> > doesn't seem as profound as it used to; BGP design principals will
> > stay with me for decades until we reach the need for BGP v5 or
> > similar, learning about 8b/10b encoding was interesting but not really
> > required for my line of work more out of hobbyist interest and serves
> > no practical purpose as a network engineer.
> >
> >
> > Cheers,
> > James.
>



-- 
Jason


From coy.hile at coyhile.com  Tue Sep 16 10:59:23 2014
From: coy.hile at coyhile.com (coy.hile at coyhile.com)
Date: Tue, 16 Sep 2014 06:59:23 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <50AC5B51-EC7D-445E-A0E9-8B6B287FD925@arbor.net>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <50AC5B51-EC7D-445E-A0E9-8B6B287FD925@arbor.net>
Message-ID: <161756AA-BDB1-4171-8D6C-CC6509457D21@coyhile.com>

Everything Stevens wrote. Including newer editions since his passing. Bill kept him listed as first author on the new edition of APUE for a reason.

Sent from my iPhone

> On Sep 16, 2014, at 5:04, Roland Dobbins <rdobbins at arbor.net> wrote:
> 
> 
>> On Sep 16, 2014, at 3:48 PM, James Bensley <jwbensley at gmail.com> wrote:
>> 
>> What is the single best book you have read on networking?
> 
> Impossible to answer with just one, really.
> 
> Apart from the classics like Stevens and Perlman and Halabi and McPherson and Doyle, these two:
> 
> <http://www.ciscopress.com/store/router-security-strategies-securing-ip-network-traffic-9781587053368>
> 
> <http://www.ciscopress.com/store/mpls-vpn-security-9781587051838>
> 
> ----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
> 
>                   Equo ne credite, Teucri.
> 
>                     -- Laoco?n
> 

From jra at baylink.com  Tue Sep 16 15:26:09 2014
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 16 Sep 2014 11:26:09 -0400 (EDT)
Subject: Scotland ccTLD?
In-Reply-To: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
Message-ID: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>

I know that IANA bases its list of ccTLDs on the 3166 list.

Does anyone know if the 3166 secretariat has a preliminary choice in mind?
I see press coverage of ".scot", but of course that's not germane.

I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab, which
apparently stands for Alba, which I will assume has historical significance
(the country name in Scots Gaelic, perhaps?)

What kind of timeframe would a new ccTLD for a major country roll out on?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From ops.lists at gmail.com  Tue Sep 16 15:39:40 2014
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Tue, 16 Sep 2014 21:09:40 +0530
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>

Alba was the ancient roman name for England, meaning white, because if the
white cliffs of Dover

They called Scotland Caledonia and Ireland Hibernia

Scotland is named for an ancient / mythical queen named Scota so they
should be fine with say sc
On 16-Sep-2014 8:58 pm, "Jay Ashworth" <jra at baylink.com> wrote:

> I know that IANA bases its list of ccTLDs on the 3166 list.
>
> Does anyone know if the 3166 secretariat has a preliminary choice in mind?
> I see press coverage of ".scot", but of course that's not germane.
>
> I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab, which
> apparently stands for Alba, which I will assume has historical significance
> (the country name in Scots Gaelic, perhaps?)
>
> What kind of timeframe would a new ccTLD for a major country roll out on?
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land
> Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
> 1274
>


From jra at baylink.com  Tue Sep 16 15:43:29 2014
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 16 Sep 2014 11:43:29 -0400 (EDT)
Subject: Scotland ccTLD?
In-Reply-To: <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
Message-ID: <31924537.1808.1410882209423.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Suresh Ramasubramanian" <ops.lists at gmail.com>

> Alba was the ancient roman name for England, meaning white, because if
> the white cliffs of Dover
> 
> They called Scotland Caledonia and Ireland Hibernia

Ah.

> Scotland is named for an ancient / mythical queen named Scota so they
> should be fine with say sc

Except that, alas, .sc is already assigned, to Seychelles.  Or this wouldn't
be a thing.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From markjr at easydns.com  Tue Sep 16 15:44:54 2014
From: markjr at easydns.com (Mark E. Jeftovic)
Date: Tue, 16 Sep 2014 11:44:54 -0400
Subject: Scotland ccTLD?
In-Reply-To: <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
Message-ID: <54185AF6.9030308@easydns.com>


.SC is the ccTLD for Seychelles

- mark

Suresh Ramasubramanian wrote:
> Alba was the ancient roman name for England, meaning white, because if the
> white cliffs of Dover
> 
> They called Scotland Caledonia and Ireland Hibernia
> 
> Scotland is named for an ancient / mythical queen named Scota so they
> should be fine with say sc
> On 16-Sep-2014 8:58 pm, "Jay Ashworth" <jra at baylink.com> wrote:
> 
>> I know that IANA bases its list of ccTLDs on the 3166 list.
>>
>> Does anyone know if the 3166 secretariat has a preliminary choice in mind?
>> I see press coverage of ".scot", but of course that's not germane.
>>
>> I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab, which
>> apparently stands for Alba, which I will assume has historical significance
>> (the country name in Scots Gaelic, perhaps?)
>>
>> What kind of timeframe would a new ccTLD for a major country roll out on?
>>
>> Cheers,
>> -- jra
>>
>> --
>> Jay R. Ashworth                  Baylink
>> jra at baylink.com
>> Designer                     The Things I Think                       RFC
>> 2100
>> Ashworth & Associates       http://www.bcp38.info          2000 Land
>> Rover DII
>> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
>> 1274
>>
> 

-- 
Mark E. Jeftovic <markjr at easydns.com>
Founder & CEO, easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225
Read my blog: http://markable.com



From rubensk at gmail.com  Tue Sep 16 15:45:07 2014
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 16 Sep 2014 12:45:07 -0300
Subject: Scotland ccTLD?
In-Reply-To: <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
Message-ID: <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>

On Tue, Sep 16, 2014 at 12:39 PM, Suresh Ramasubramanian <
ops.lists at gmail.com> wrote:

> Alba was the ancient roman name for England, meaning white, because if the
> white cliffs of Dover
>
> They called Scotland Caledonia and Ireland Hibernia
>
> Scotland is named for an ancient / mythical queen named Scota so they
> should be fine with say sc
>
>
sc is Seychelles. Available s* include sf, sp, sq, su and sw. They should
pick .sf, use .scot for in-country domains and sell all .sf domains to San
Francisco residents.


Rubens


From tshaw at oitc.com  Tue Sep 16 15:52:38 2014
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 16 Sep 2014 11:52:38 -0400
Subject: Scotland ccTLD?
In-Reply-To: <31924537.1808.1410882209423.JavaMail.root@benjamin.baylink.com>
References: <31924537.1808.1410882209423.JavaMail.root@benjamin.baylink.com>
Message-ID: <0C94FDB7-DA73-49F2-BD4B-6C91DF56EF03@oitc.com>


On Sep 16, 2014, at 11:43 AM, Jay Ashworth wrote:

> ----- Original Message -----
>> From: "Suresh Ramasubramanian" <ops.lists at gmail.com>
> 
>> Alba was the ancient roman name for England, meaning white, because if
>> the white cliffs of Dover
>> 
>> They called Scotland Caledonia and Ireland Hibernia
> 
> Ah.
> 
>> Scotland is named for an ancient / mythical queen named Scota so they
>> should be fine with say sc
> 
> Except that, alas, .sc is already assigned, to Seychelles.  Or this wouldn't
> be a thing.  :-)
> 

Why not ct? 

The Scots have always embraced Caledonia.  Heck, their airline, before BA bought them, was called British Caledonia (a better airline than BA IMHO)




From msa at latt.net  Tue Sep 16 15:55:49 2014
From: msa at latt.net (Majdi S. Abbas)
Date: Tue, 16 Sep 2014 11:55:49 -0400
Subject: Scotland ccTLD?
In-Reply-To: <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
Message-ID: <20140916155549.GA2873@puck.nether.net>

On Tue, Sep 16, 2014 at 12:45:07PM -0300, Rubens Kuhl wrote:
> sc is Seychelles. Available s* include sf, sp, sq, su and sw. They should
> pick .sf, use .scot for in-country domains and sell all .sf domains to San
> Francisco residents.

	su is not available.

	--msa


From nick at foobar.org  Tue Sep 16 15:56:21 2014
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 16 Sep 2014 16:56:21 +0100
Subject: Scotland ccTLD?
In-Reply-To: <31924537.1808.1410882209423.JavaMail.root@benjamin.baylink.com>
References: <31924537.1808.1410882209423.JavaMail.root@benjamin.baylink.com>
Message-ID: <54185DA5.5030901@foobar.org>

On 16/09/2014 16:43, Jay Ashworth wrote:
> Except that, alas, .sc is already assigned, to Seychelles.  Or this wouldn't
> be a thing.  :-)

no-one's recently found oil under the Seychelles, so there doesn't seem to
be an immediate need to install some new democracy over there and liberate
the downtrodden .sc domain.

Otherwise, "Alba" is the scottish Gaelic for "Scotland", but .al is
assigned to Albania.

Nick




From tshaw at oitc.com  Tue Sep 16 16:03:14 2014
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 16 Sep 2014 12:03:14 -0400
Subject: Scotland ccTLD?
In-Reply-To: <0C94FDB7-DA73-49F2-BD4B-6C91DF56EF03@oitc.com>
References: <31924537.1808.1410882209423.JavaMail.root@benjamin.baylink.com>
 <0C94FDB7-DA73-49F2-BD4B-6C91DF56EF03@oitc.com>
Message-ID: <74914676-6BA2-494E-A07B-DB88DE1291A6@oitc.com>


On Sep 16, 2014, at 11:52 AM, TR Shaw wrote:

> 
> On Sep 16, 2014, at 11:43 AM, Jay Ashworth wrote:
> 
>> ----- Original Message -----
>>> From: "Suresh Ramasubramanian" <ops.lists at gmail.com>
>> 
>>> Alba was the ancient roman name for England, meaning white, because if
>>> the white cliffs of Dover
>>> 
>>> They called Scotland Caledonia and Ireland Hibernia
>> 
>> Ah.
>> 
>>> Scotland is named for an ancient / mythical queen named Scota so they
>>> should be fine with say sc
>> 
>> Except that, alas, .sc is already assigned, to Seychelles.  Or this wouldn't
>> be a thing.  :-)
>> 
> 
> Why not ct? 
> 
> The Scots have always embraced Caledonia.  Heck, their airline, before BA bought them, was called British Caledonia (a better airline than BA IMHO)
> 
> 



Typo. SHould have been CE

From jaap at NLnetLabs.nl  Tue Sep 16 16:24:17 2014
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 16 Sep 2014 18:24:17 +0200
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <201409161624.s8GGOHAh056803@bela.nlnetlabs.nl>

 Jay Ashworth writes:

 > I know that IANA bases its list of ccTLDs on the 3166 list.
 > 
 > Does anyone know if the 3166 secretariat has a preliminary choice in
 > mind?

It hasn't. 

 > I see press coverage of ".scot", but of course that's not
 > germane.

That is a gTLD at best, not an alpha-2 ISO 3166 code.

 > 
 > I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab,
 > which apparently stands for Alba, which I will assume has historical
 > significance (the country name in Scots Gaelic, perhaps?)
 > 
 > What kind of timeframe would a new ccTLD for a major country roll out
 > on?

Well, first the country has to exist, which can take some time even
when the vote is yes. ISO 3166 MA allocates a  code, and tries to
do that as soon as possible the country has a name etc., hopefully
it can be arranged at the date the country became in existing (which
was the case with recent new coutries (SS, SX, CW etc.) but that
are no guarantees. Then ICANA can pick a registry, delegate etc.
Whether they plan to prepare for that in advance one has to ask
IANA.

	jaap



From drc at virtualized.org  Tue Sep 16 16:26:24 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 16 Sep 2014 09:26:24 -0700
Subject: Scotland ccTLD?
In-Reply-To: <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
Message-ID: <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>

On Sep 16, 2014, at 8:45 AM, Rubens Kuhl <rubensk at gmail.com> wrote:
> Available s* include sf, sp, sq, su and sw.

SF (Finland, from ?Suomi Finland?) is ?transitionally reserved? meaning it is allocated but will be removed from the allocated list ?soon? (for some value of the variable ?soon?). I believe the hold down timer for transitionally reserved is something like 50 years now. As such, it?s not available.

SU is the Soviet Union, now classified as ?exceptionally reserved? which IANA treats as available for assignment (other exceptionally reserved codes are EU, UK, and AC).  Don?t get me started on why SU is exceptionally reserved instead of transitionally reserved.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140916/ad16621b/attachment.sig>

From j at arpa.com  Tue Sep 16 16:28:05 2014
From: j at arpa.com (jamie rishaw)
Date: Tue, 16 Sep 2014 11:28:05 -0500
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <CABL6YZR7e+KcxYHZduzjfJ-ACC_iZWfBsYH-fDrOXZ8UWMFueA@mail.gmail.com>

Do we get to bill time and materials (t&m) if they vote to secede?  I mean,
we're engineers and all but even this discussion has netted a
nonsignificant number of billable hours.

Remember, the entire secession movement is being funded by a couple of
Lottery winners.

Just sayin'.

-j

On Tue, Sep 16, 2014 at 10:26 AM, Jay Ashworth <jra at baylink.com> wrote:

> I know that IANA bases its list of ccTLDs on the 3166 list.
>
> Does anyone know if the 3166 secretariat has a preliminary choice in mind?
> I see press coverage of ".scot", but of course that's not germane.
>
> I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab, which
> apparently stands for Alba, which I will assume has historical significance
> (the country name in Scots Gaelic, perhaps?)
>
> What kind of timeframe would a new ccTLD for a major country roll out on?
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land
> Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
> 1274
>



-- 
jamie rishaw // .com.arpa at j <- reverse it. ish.

"...let's consider this world like a family and care about each other..."
             -Malala Yousafzai


From rdobbins at arbor.net  Tue Sep 16 16:30:47 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Tue, 16 Sep 2014 23:30:47 +0700
Subject: Scotland ccTLD?
In-Reply-To: <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
Message-ID: <07440AFF-0405-4799-9634-CEB43EEDB578@arbor.net>


On Sep 16, 2014, at 11:26 PM, David Conrad <drc at virtualized.org> wrote:

> Don?t get me started on why SU is exceptionally reserved instead of transitionally reserved.

Just in case?

;>

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

                   Equo ne credite, Teucri.

    		   	  -- Laoco?n

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140916/e9e69647/attachment.sig>

From jra at baylink.com  Tue Sep 16 16:50:10 2014
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 16 Sep 2014 12:50:10 -0400
Subject: Scotland ccTLD?
In-Reply-To: <CABL6YZR7e+KcxYHZduzjfJ-ACC_iZWfBsYH-fDrOXZ8UWMFueA@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CABL6YZR7e+KcxYHZduzjfJ-ACC_iZWfBsYH-fDrOXZ8UWMFueA@mail.gmail.com>
Message-ID: <4f59997d-498b-47c1-a50a-dbf5d6b41f15@email.android.com>

Ssshhhh! :-)

On September 16, 2014 12:28:05 PM EDT, jamie rishaw <j at arpa.com> wrote:
>Do we get to bill time and materials (t&m) if they vote to secede?  I
>mean,
>we're engineers and all but even this discussion has netted a
>nonsignificant number of billable hours.
>
>Remember, the entire secession movement is being funded by a couple of
>Lottery winners.
>
>Just sayin'.
>
>-j
>
>On Tue, Sep 16, 2014 at 10:26 AM, Jay Ashworth <jra at baylink.com> wrote:
>
>> I know that IANA bases its list of ccTLDs on the 3166 list.
>>
>> Does anyone know if the 3166 secretariat has a preliminary choice in
>mind?
>> I see press coverage of ".scot", but of course that's not germane.
>>
>> I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab,
>which
>> apparently stands for Alba, which I will assume has historical
>significance
>> (the country name in Scots Gaelic, perhaps?)
>>
>> What kind of timeframe would a new ccTLD for a major country roll out
>on?
>>
>> Cheers,
>> -- jra
>>
>> --
>> Jay R. Ashworth                  Baylink
>> jra at baylink.com
>> Designer                     The Things I Think                      
>RFC
>> 2100
>> Ashworth & Associates       http://www.bcp38.info          2000 Land
>> Rover DII
>> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727
>647
>> 1274
>>
>
>
>
>-- 
>jamie rishaw // .com.arpa at j <- reverse it. ish.
>
>"...let's consider this world like a family and care about each
>other..."
>             -Malala Yousafzai

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From bzs at world.std.com  Tue Sep 16 17:01:24 2014
From: bzs at world.std.com (Barry Shein)
Date: Tue, 16 Sep 2014 13:01:24 -0400
Subject: Scotland ccTLD?
In-Reply-To: <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
Message-ID: <21528.27876.774494.71428@world.std.com>


.PC, for Picts (I believe it's available.) But I doubt that would fly.

They could combine Scotland and Picts to rationalize .SP.

I don't know anything about Scotland's attitude toward being
identified with the Picts, however. Perhaps that's a nonsensical idea.

Oh well. I guess if Scotland devolves they should invade
Seychelles. Problem solved.

-- 
        -Barry Shein

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


From dougb at dougbarton.us  Tue Sep 16 17:08:13 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 16 Sep 2014 10:08:13 -0700
Subject: Scotland ccTLD?
In-Reply-To: <CABL6YZR7e+KcxYHZduzjfJ-ACC_iZWfBsYH-fDrOXZ8UWMFueA@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CABL6YZR7e+KcxYHZduzjfJ-ACC_iZWfBsYH-fDrOXZ8UWMFueA@mail.gmail.com>
Message-ID: <54186E7D.2040204@dougbarton.us>

On 9/16/14 9:28 AM, jamie rishaw wrote:
> Remember, the entire secession movement is being funded by a couple of
> Lottery winners.

Um ... the history of Scots not wanting to be ruled by !Scots goes back 
a wee bit further. :)

Doug



From dougb at dougbarton.us  Tue Sep 16 17:09:27 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 16 Sep 2014 10:09:27 -0700
Subject: Scotland ccTLD?
In-Reply-To: <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
Message-ID: <54186EC7.6060507@dougbarton.us>

On 9/16/14 9:26 AM, David Conrad wrote:
> SU is the Soviet Union, now classified as ?exceptionally reserved?
> which IANA treats as available for assignment (other exceptionally
> reserved codes are EU, UK, and AC).  Don?t get me started on why SU
> is exceptionally reserved instead of transitionally reserved.

A better question is why is SU still in the root?

Doug *ducks and runs*



From drc at virtualized.org  Tue Sep 16 17:18:31 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 16 Sep 2014 10:18:31 -0700
Subject: Scotland ccTLD?
In-Reply-To: <21528.27876.774494.71428@world.std.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <21528.27876.774494.71428@world.std.com>
Message-ID: <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>

On Sep 16, 2014, at 10:01 AM, Barry Shein <bzs at world.std.com> wrote:
> .PC, for Picts (I believe it's available.) But I doubt that would fly.

Clearly the right answer here is either .SW or perhaps just .WH (since a whisky from a place other than Scotland is obviously just wrong ... :))

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140916/7f756e57/attachment.sig>

From wwaites at tardis.ed.ac.uk  Tue Sep 16 17:31:11 2014
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Tue, 16 Sep 2014 18:31:11 +0100
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <541873DF.9070503@tardis.ed.ac.uk>

On 16/09/14 16:26, Jay Ashworth wrote:
> I see also a suggestion, credited to Dave Eastabrook (sp?) of .ab, which
> apparently stands for Alba, which I will assume has historical significance
> (the country name in Scots Gaelic, perhaps?)

It has current significance, as Gaelic is recognised as an official
(albeit minority) language. This is probably a reasonable suggestion.

The irony is that these kinds of infrastructure questions are so far
below the radar of the Scottish Government that I wouldn't be
surprised at all if its operation were outsourced to Nominet...


From bill at herrin.us  Tue Sep 16 17:32:31 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 16 Sep 2014 13:32:31 -0400
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP-guGXVO7ujGRmWeg5fSD1e6HT8UBOw9c37_kRa0Nu+BG+=WA@mail.gmail.com>

On Tue, Sep 16, 2014 at 11:26 AM, Jay Ashworth <jra at baylink.com> wrote:
> I know that IANA bases its list of ccTLDs on the 3166 list.
>
> Does anyone know if the 3166 secretariat has a preliminary choice in mind?
> I see press coverage of ".scot", but of course that's not germane.

Here's a list of assigned and available ISO 3166 alpha-2 codes:

http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table

Regards,
Bill Herrin

-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?


From rsk at gsp.org  Tue Sep 16 17:41:55 2014
From: rsk at gsp.org (Rich Kulawiec)
Date: Tue, 16 Sep 2014 13:41:55 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
Message-ID: <20140916174154.GA26470@gsp.org>

On Tue, Sep 16, 2014 at 09:48:45AM +0100, James Bensley wrote:
> What is the single best book you have read on networking?

Elements of Networking Style, Michael A. Padlipsky, 1984.  How could anyone
*not* love a book which includes this in the foreword:

	Brace yourselves.  We are about to try something that borders
	on the unique: an actually rather serious technical book which
	is not only (gasp) vehemently anti-Solemn but also (shudder)
	takes sides.  I tend to think of it as "Constructive Snottiness".

---rsk

p.s. And anything/everything Stevens wrote.



From jamie at photon.com  Tue Sep 16 17:42:31 2014
From: jamie at photon.com (Jamie Bowden)
Date: Tue, 16 Sep 2014 17:42:31 +0000
Subject: Scotland ccTLD?
In-Reply-To: <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <21528.27876.774494.71428@world.std.com>
 <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>
Message-ID: <5EA9A87201F2AB42BFD9B954797F19BE013C0C4C@PRA-IAD-MAIL.pra.ray.com>

> From: David Conrad

> Clearly the right answer here is either .SW or perhaps just .WH (since a
> whisky from a place other than Scotland is obviously just wrong ... :))

I believe the Irish monks who invented the stuff might beg to differ, but really, we're talking about an oil rich nation being repressed by a despotic monarchy, why the hell haven't we invaded already?

Jamie


From jaap at NLnetLabs.nl  Tue Sep 16 17:43:48 2014
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 16 Sep 2014 19:43:48 +0200
Subject: Scotland ccTLD?
In-Reply-To: <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
Message-ID: <201409161743.s8GHhmoi031660@bela.nlnetlabs.nl>

 > On Sep 16, 2014, at 8:45 AM, Rubens Kuhl <rubensk at gmail.com> wrote: >
 > Available s* include sf, sp, sq, su and sw.

One really should to consult
<http://www.iso.org/iso/home/standards/country_codes.htm> and
<https://www.iso.org/obp/ui/#home> before making these kind of
assumptions.

	jaap


From brunner at nic-naa.net  Tue Sep 16 17:45:56 2014
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Tue, 16 Sep 2014 10:45:56 -0700
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <54187754.9080706@nic-naa.net>

On 9/16/14 8:26 AM, Jay Ashworth wrote:
> What kind of timeframe would a new ccTLD for a major country roll out on?

that could be several quite distinct questions:

1. assuming that the "aye" vote prevails, in what quarter will the 
iso3166/ma issue the relevant update, allocating a code point to the new 
political jurisdiction?

2. assuming the iso3166/ma issues the relevant update and code point, 
when will the new political jurisdiction designate a registry operator?

3. assuming new political jurisdiction designates a registry operator, 
when will the root zone publisher delegate the code point to the 
operator designated by the new political jurisdiction?

4. assuming the root zone publisher delegates the code point to the 
operator, when will the operator "go live", and what, if any, "stages 
of" or "restrictions on" access will the operator exercise subsequent to 
that point in time?

your milage may vary, of course.

Eric



From dougb at dougbarton.us  Tue Sep 16 17:52:09 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 16 Sep 2014 10:52:09 -0700
Subject: Scotland ccTLD?
In-Reply-To: <CAP-guGXVO7ujGRmWeg5fSD1e6HT8UBOw9c37_kRa0Nu+BG+=WA@mail.gmail.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAP-guGXVO7ujGRmWeg5fSD1e6HT8UBOw9c37_kRa0Nu+BG+=WA@mail.gmail.com>
Message-ID: <541878C9.1000703@dougbarton.us>

On 9/16/14 10:32 AM, William Herrin wrote:
> On Tue, Sep 16, 2014 at 11:26 AM, Jay Ashworth <jra at baylink.com> wrote:
>> I know that IANA bases its list of ccTLDs on the 3166 list.
>>
>> Does anyone know if the 3166 secretariat has a preliminary choice in mind?
>> I see press coverage of ".scot", but of course that's not germane.
>
> Here's a list of assigned and available ISO 3166 alpha-2 codes:
>
> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table

Minor nit, referring to secondary sources, even ones so well-maintained 
as wikipedia, has rather often led to confusion in the ccTLD space. The 
primary source for this information is here, I encourage people to refer 
to it instead:

https://www.iso.org/obp/ui/#search

Doug



From rubensk at gmail.com  Tue Sep 16 17:53:28 2014
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 16 Sep 2014 14:53:28 -0300
Subject: Scotland ccTLD?
In-Reply-To: <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
Message-ID: <CAGFn2k2LxyDMT7YmavBsZ=C2zqP08ar_yjQzzw1Nx-TR7D5=Tw@mail.gmail.com>

On Tue, Sep 16, 2014 at 1:26 PM, David Conrad <drc at virtualized.org> wrote:

> On Sep 16, 2014, at 8:45 AM, Rubens Kuhl <rubensk at gmail.com> wrote:
> > Available s* include sf, sp, sq, su and sw.
>
> SF (Finland, from ?Suomi Finland?) is ?transitionally reserved? meaning it
> is allocated but will be removed from the allocated list ?soon? (for some
> value of the variable ?soon?). I believe the hold down timer for
> transitionally reserved is something like 50 years now. As such, it?s not
> available.
>
> SU is the Soviet Union, now classified as ?exceptionally reserved? which
> IANA treats as available for assignment (other exceptionally reserved codes
> are EU, UK, and AC).  Don?t get me started on why SU is exceptionally
> reserved instead of transitionally reserved.
>

Why SU is not transitionally reserved:
http://vimeo.com/87939821


Rubens


From lists at mtin.net  Tue Sep 16 17:53:51 2014
From: lists at mtin.net (Justin Wilson)
Date: Tue, 16 Sep 2014 13:53:51 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <20140916174154.GA26470@gsp.org>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <20140916174154.GA26470@gsp.org>
Message-ID: <D03DF10A.7EDCE%lists@mtin.net>



?Designing Campus Networks? From Cisco.
?Internet Routing Architectures?
?Next Generation Network Services? from Cisco Press

To me those are pretty general and how to apply it to different scenarios.
 

Justin


--
Justin Wilson <j2sw at mtin.net>
http://www.mtin.net <http://www.mtin.net/blog>
Managed Services ? xISP Solutions ? Data Centers
http://www.thebrotherswisp.com
Podcast about xISP topics




On 9/16/14, 1:41 PM, "Rich Kulawiec" <rsk at gsp.org> wrote:

>On Tue, Sep 16, 2014 at 09:48:45AM +0100, James Bensley wrote:
>> What is the single best book you have read on networking?
>
>Elements of Networking Style, Michael A. Padlipsky, 1984.  How could
>anyone
>*not* love a book which includes this in the foreword:
>
>	Brace yourselves.  We are about to try something that borders
>	on the unique: an actually rather serious technical book which
>	is not only (gasp) vehemently anti-Solemn but also (shudder)
>	takes sides.  I tend to think of it as "Constructive Snottiness".
>
>---rsk
>
>p.s. And anything/everything Stevens wrote.
>




From dougb at dougbarton.us  Tue Sep 16 18:03:54 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 16 Sep 2014 11:03:54 -0700
Subject: Scotland ccTLD?
In-Reply-To: <54187754.9080706@nic-naa.net>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <54187754.9080706@nic-naa.net>
Message-ID: <54187B8A.7070400@dougbarton.us>

On 9/16/14 10:45 AM, Eric Brunner-Williams wrote:
> On 9/16/14 8:26 AM, Jay Ashworth wrote:
>> What kind of timeframe would a new ccTLD for a major country roll out on?
>
> that could be several quite distinct questions:
>
> 1. assuming that the "aye" vote prevails, in what quarter will the
> iso3166/ma issue the relevant update, allocating a code point to the new
> political jurisdiction?
>
> 2. assuming the iso3166/ma issues the relevant update and code point,
> when will the new political jurisdiction designate a registry operator?
>
> 3. assuming new political jurisdiction designates a registry operator,
> when will the root zone publisher delegate the code point to the
> operator designated by the new political jurisdiction?
>
> 4. assuming the root zone publisher delegates the code point to the
> operator, when will the operator "go live", and what, if any, "stages
> of" or "restrictions on" access will the operator exercise subsequent to
> that point in time?

FWIW (and despite my participation in the thread) all of this 
speculation is worthless, in case anyone is keeping score at home. :)

Meanwhile, it's probably worth pointing out that while Eric has the 
rough outline of the process correct above, by no means do all of those 
steps have to occur serially. OTOH, there is no accounting for how 
quickly or slowly any of them will occur. There are also numerous 
possible entanglements at each step, so really, the speculation is 
worthless. :)

Doug



From owen at delong.com  Tue Sep 16 18:00:35 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Sep 2014 11:00:35 -0700
Subject: 2000::/6
In-Reply-To: <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
References: <5410340D.2010007@lanparty.ee> <20140910161643.GP53723@Vurt.local>
 <m2tx4ee1cx.wl%randy@psg.com>
 <85122F8E-A898-4981-A580-9EFDA3A51E0F@puck.nether.net>
 <m2ppf2e0kt.wl%randy@psg.com> <5412A694.2050105@lanparty.ee>
 <BCC6AE00-5A40-4C55-ACDA-EF2E26955724@delong.com>
 <54141D81.30800@lanparty.ee>
 <CAAAwwbWkHon=avH9xtZVnL0HN_h=XzpCD8qYRJEW5Mq1urCZtA@mail.gmail.com>
Message-ID: <8EAC6463-A240-451C-8E62-B599561CCA79@delong.com>


On Sep 14, 2014, at 2:19 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan <tarko at lanparty.ee> wrote:
>> 2000::/64 has nothing to do with it.
>> 
>> Any address between 2000:0000:0000:0000:0000:0000:0000:0000 and
>> 23ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff together with misconfigured prefix
>> length (6 instead 64) becomes 2000::/6 prefix.
> 
> It should be rejected for the same reason that  192.168.10.0/16 is
> invalid in a prefix list  or access list.
> 
> Any decent router won't allow you to enter just anything in that range
> into the export rules  with a /6,  except 2000::  itself, and will
> even show you a failure response instead of silently ignoring the
> invalid input,  for the very purpose of helping you avoid such errors.
>   2001::1/6  would be an example of an invalid input --  there are
> one or more non-zero bits listed outside the prefix, or where  bits in
> the mask are zero.
> 
> Only 2000:0000:0000:0000:0000:0000:0000:0000/6    properly conforms,
> not just "any IP"   in that range  can have a /6  appended to the end.

Which is one of the reasons I think it was more likely a typo for 2000::/3
being entered via numeric keypad.

3 and 6 are adjacent on a numeric keypad and both 2000::/3 and 2000::/6 are
valid prefixes.

Owen



From drc at virtualized.org  Tue Sep 16 18:06:28 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 16 Sep 2014 11:06:28 -0700
Subject: Scotland ccTLD?
In-Reply-To: <541878C9.1000703@dougbarton.us>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAP-guGXVO7ujGRmWeg5fSD1e6HT8UBOw9c37_kRa0Nu+BG+=WA@mail.gmail.com>
 <541878C9.1000703@dougbarton.us>
Message-ID: <F8728C33-7CDF-470F-8CBA-E13B154AFB9A@virtualized.org>

On Sep 16, 2014, at 10:52 AM, Doug Barton <dougb at dougbarton.us> wrote:
>> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table
> 
> Minor nit, referring to secondary sources, even ones so well-maintained as wikipedia, has rather often led to confusion in the ccTLD space. The primary source for this information is here, I encourage people to refer to it instead:
> 
> https://www.iso.org/obp/ui/#search

Using the new UI, how would one identify the ISO-3166 codes that have been reserved for user defined purposes (i.e., AA, QM-QZ, XA-XZ, and ZZ)?

The decoding table was extremely useful.  It?s a shame ISO decided to remove it. 

Regards,
-drc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140916/2e87324a/attachment.sig>

From dougb at dougbarton.us  Tue Sep 16 18:13:52 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 16 Sep 2014 11:13:52 -0700
Subject: Scotland ccTLD?
In-Reply-To: <F8728C33-7CDF-470F-8CBA-E13B154AFB9A@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAP-guGXVO7ujGRmWeg5fSD1e6HT8UBOw9c37_kRa0Nu+BG+=WA@mail.gmail.com>
 <541878C9.1000703@dougbarton.us>
 <F8728C33-7CDF-470F-8CBA-E13B154AFB9A@virtualized.org>
Message-ID: <54187DE0.7030207@dougbarton.us>

On 9/16/14 11:06 AM, David Conrad wrote:
> On Sep 16, 2014, at 10:52 AM, Doug Barton <dougb at dougbarton.us>
> wrote:
>>> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table
>>
>> Minor nit, referring to secondary sources, even ones so
>> well-maintained as wikipedia, has rather often led to confusion
>> in the ccTLD space. The primary source for this information is
>> here, I encourage people to refer to it instead:
>>
>> https://www.iso.org/obp/ui/#search
>
> Using the new UI, how would one identify the ISO-3166 codes that
> have been reserved for user defined purposes (i.e., AA, QM-QZ,
> XA-XZ, and ZZ)?
>
> The decoding table was extremely useful.  It?s a shame ISO decided
> to remove it.

I agree, but, progress ... ?

Doug



From drc at virtualized.org  Tue Sep 16 18:21:43 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 16 Sep 2014 11:21:43 -0700
Subject: Scotland ccTLD?
In-Reply-To: <5EA9A87201F2AB42BFD9B954797F19BE013C0C4C@PRA-IAD-MAIL.pra.ray.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <21528.27876.774494.71428@world.std.com>
 <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>
 <5EA9A87201F2AB42BFD9B954797F19BE013C0C4C@PRA-IAD-MAIL.pra.ray.com>
Message-ID: <8A91C88F-7AD3-41CF-AE6E-FE96ED623F59@virtualized.org>

On Sep 16, 2014, at 10:42 AM, Jamie Bowden <jamie at photon.com> wrote:
>> Clearly the right answer here is either .SW or perhaps just .WH (since a
>> whisky from a place other than Scotland is obviously just wrong ... :))
> 
> I believe the Irish monks who invented the stuff might beg to differ,

No, no. They invented Whiskey. (:) for the humo(u)r impaired)

> but really, we're talking about an oil rich nation being repressed by a despotic monarchy, why the hell haven't we invaded already?

Probably the weather.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140916/dc9369dd/attachment.sig>

From bill at herrin.us  Tue Sep 16 18:26:09 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 16 Sep 2014 14:26:09 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <2A3F4518-570F-4140-B1BA-F27F554EE47D@matthew.at>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <2A3F4518-570F-4140-B1BA-F27F554EE47D@matthew.at>
Message-ID: <CAP-guGUTYEiTHb_3Ue+Evz38EhjfMXpWUk=G7DbazPLcaO4j3g@mail.gmail.com>

On Tue, Sep 16, 2014 at 5:07 AM, Matthew Kaufman <matthew at matthew.at> wrote:
> "Patterns in Network Architecture"
>
> You might not agree with it, but it does stimulate some thinking.

Hi Matthew,

I would agree that any attempt to understand the material stimulates
thinking. The book ranges from "inscrutable" to "extremely poorly
written."

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?


From bill at herrin.us  Tue Sep 16 18:33:45 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 16 Sep 2014 14:33:45 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <161756AA-BDB1-4171-8D6C-CC6509457D21@coyhile.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <50AC5B51-EC7D-445E-A0E9-8B6B287FD925@arbor.net>
 <161756AA-BDB1-4171-8D6C-CC6509457D21@coyhile.com>
Message-ID: <CAP-guGURAvnkCHAjfkugFKmwDq2bADJsbwWLnU94Z8KOnbO+QA@mail.gmail.com>

On Tue, Sep 16, 2014 at 6:59 AM,  <coy.hile at coyhile.com> wrote:
> Everything Stevens wrote.

Even volume 3?

TCP/IP Illustrated volume 1 is one of the finest books on IPv4 ever
written but volume 3 smells of "Please write us another book. We don't
care what it's about, just write something."

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?


From cb.list6 at gmail.com  Tue Sep 16 18:35:05 2014
From: cb.list6 at gmail.com (Ca By)
Date: Tue, 16 Sep 2014 11:35:05 -0700
Subject: Book / Literature Recommendations
In-Reply-To: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
Message-ID: <CAD6AjGT_4QW8YViNSzP+YGep_587UAAPWivhpmjV6secLqdP7w@mail.gmail.com>

On Tue, Sep 16, 2014 at 1:48 AM, James Bensley <jwbensley at gmail.com> wrote:
> Hi All,
>
> What is the single best book you have read on networking? That's a
> wide topic so to clarify I'm talking about service provider networking
> but I do enjoy all aspects really and don't want to limit my self to
> one area of networking.
>
> I'm often reading technical books about technology X or protocol Y but
> they are generally explaining a new technology to me, how it works and
> how to use it (and how to configure it if its a book by a vendor like
> Juniper or Cisco). That is usually a learning exercise though required
> for an upcoming project or deliverable.
>
> I haven't read many vendor neutral books recently that explained
> concepts, or technologies, or paradigms that I found profound, radical
> and extremely useful.
>
> I feel like I'm just reading networking books these days to learn a
> new technology for a period of time (until a project completes) then
> moving on to the next technology (book). Longevity of the information
> doesn't seem as profound as it used to; BGP design principals will
> stay with me for decades until we reach the need for BGP v5 or
> similar, learning about 8b/10b encoding was interesting but not really
> required for my line of work more out of hobbyist interest and serves
> no practical purpose as a network engineer.
>
>
> Cheers,
> James.


I recommend reading the NANOG meeting materials archive presos and videos.

Good to see what people are actually doing, real lessons learned.

CB


From jtk at cymru.com  Tue Sep 16 18:55:12 2014
From: jtk at cymru.com (John Kristoff)
Date: Tue, 16 Sep 2014 13:55:12 -0500
Subject: Book / Literature Recommendations
In-Reply-To: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
Message-ID: <20140916135512.7e7b71ac@localhost>

On Tue, 16 Sep 2014 09:48:45 +0100
James Bensley <jwbensley at gmail.com> wrote:

> What is the single best book you have read on networking?

I couldn't narrow it down to one, but since it hasn't been mentioned
already, Radia Perlman's Interconnections.  Her's is utterly fantastic
largely in part because she often explains why some things are the way
they are (how we got what we have) and sometimes why what we have isn't
always so great.  Other great books mentioned take a similar tack, they
go beyond what is in written specs.

John


From mansaxel at besserwisser.org  Tue Sep 16 19:47:39 2014
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Tue, 16 Sep 2014 21:47:39 +0200
Subject: Scotland ccTLD?
In-Reply-To: <54186EC7.6060507@dougbarton.us>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
 <54186EC7.6060507@dougbarton.us>
Message-ID: <20140916194739.GL10142@besserwisser.org>

Subject: Re: Scotland ccTLD? Date: Tue, Sep 16, 2014 at 10:09:27AM -0700 Quoting Doug Barton (dougb at dougbarton.us):
 
> A better question is why is SU still in the root?

Since the rebels in eastern Ukraine have been reported to call their
intimidation police "????"[0] I suppose the rest of the apparat that
was Soviet Union will return shortly.  Better keep SU in the root just
in case.

On a more on-topic note, there are several domains still in use under SU. 

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
The entire CHINESE WOMEN'S VOLLEYBALL TEAM all share ONE personality --
and have since BIRTH!!

[0] https://en.wikipedia.org/wiki/Donetsk_People's_Republic#Sectarian_attacks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140916/2a22f8a4/attachment.sig>

From tom at ninjabadger.net  Tue Sep 16 20:07:17 2014
From: tom at ninjabadger.net (Tom Hill)
Date: Tue, 16 Sep 2014 21:07:17 +0100
Subject: Scotland ccTLD?
In-Reply-To: <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <21528.27876.774494.71428@world.std.com>
 <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>
Message-ID: <54189875.5030608@ninjabadger.net>

On 16/09/14 18:18, David Conrad wrote:
> Clearly the right answer here is either .SW or perhaps just .WH
> (since a whisky from a place other than Scotland is obviously just
> wrong ... :))

Actually heard recently that .sq might be the preferred option. Not sure
what the reason for that was.

I'd like to think that, unofficially, we could remember it as 'sq for
squatted namespace'. :)

-- 
Tom


From bill at herrin.us  Tue Sep 16 20:12:11 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 16 Sep 2014 16:12:11 -0400
Subject: Scotland ccTLD?
In-Reply-To: <54189875.5030608@ninjabadger.net>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <21528.27876.774494.71428@world.std.com>
 <29C7D6E1-56BF-427B-84AF-0ED25D725A8F@virtualized.org>
 <54189875.5030608@ninjabadger.net>
Message-ID: <CAP-guGWt2SBoeGFV_VWGdyg9U_Vxqg25HXX+Dye3cEgbi2kjNw@mail.gmail.com>

On Tue, Sep 16, 2014 at 4:07 PM, Tom Hill <tom at ninjabadger.net> wrote:
> On 16/09/14 18:18, David Conrad wrote:
>> Clearly the right answer here is either .SW or perhaps just .WH
>> (since a whisky from a place other than Scotland is obviously just
>> wrong ... :))
>
> Actually heard recently that .sq might be the preferred option. Not sure
> what the reason for that was.
>
> I'd like to think that, unofficially, we could remember it as 'sq for
> squatted namespace'. :)

Squatland?

-Bill


From russw at riw.us  Tue Sep 16 21:44:34 2014
From: russw at riw.us (Russ White)
Date: Tue, 16 Sep 2014 17:44:34 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <D03DF10A.7EDCE%lists@mtin.net>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <20140916174154.GA26470@gsp.org> <D03DF10A.7EDCE%lists@mtin.net>
Message-ID: <00a301cfd1f7$697757f0$3c6607d0$@riw.us>


> ?Designing Campus Networks? From Cisco.
> ?Internet Routing Architectures?
> ?Next Generation Network Services? from Cisco Press

I hate to suggest my own book, but -- The Art of Network Architecture, I
think, is pretty good. I know Doyle's Routing TCP/IP is good, I really
appreciate Radia's Interconnections, and I found Day's book useful in
thinking through models (even if it's not the best written -- but I?m pretty
tolerant on that front). And no, you won't hurt my feelings if you disagree.

:-)

Russ



From mfidelman at meetinghouse.net  Tue Sep 16 21:51:28 2014
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Tue, 16 Sep 2014 17:51:28 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <20140916135512.7e7b71ac@localhost>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <20140916135512.7e7b71ac@localhost>
Message-ID: <5418B0E0.5000107@meetinghouse.net>

John Kristoff wrote:
> On Tue, 16 Sep 2014 09:48:45 +0100
> James Bensley <jwbensley at gmail.com> wrote:
>
>> What is the single best book you have read on networking?
>
Well, it's been a LONG time, but it's got to be either Stallings, Comer, 
or Tannenbaum.

Miles Fidelman


From surfer at mauigateway.com  Tue Sep 16 22:21:32 2014
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 16 Sep 2014 15:21:32 -0700
Subject: Book / Literature Recommendations
Message-ID: <20140916152132.7F89D814@m0005296.ppops.net>



> On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley at gmail.com> wrote:

> What is the single best book you have read on 
> networking? 
-----------------------------


Paper is soooo 20th century.  C'mon, we're a decade and 
a half into the 21st century.   :-)

http://www.tcpipguide.com/free/t_toc.htm

scott


From owen at delong.com  Tue Sep 16 22:43:56 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Sep 2014 15:43:56 -0700
Subject: Scotland ccTLD?
In-Reply-To: <20140916155549.GA2873@puck.nether.net>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <20140916155549.GA2873@puck.nether.net>
Message-ID: <8DE5EAE1-1810-4842-8562-2D3B178B7BEC@delong.com>


On Sep 16, 2014, at 8:55 AM, Majdi S. Abbas <msa at latt.net> wrote:

> On Tue, Sep 16, 2014 at 12:45:07PM -0300, Rubens Kuhl wrote:
>> sc is Seychelles. Available s* include sf, sp, sq, su and sw. They should
>> pick .sf, use .scot for in-country domains and sell all .sf domains to San
>> Francisco residents.
> 
> 	su is not available.
> 
> 	--msa

I think it is now, since the break up of the Soviet Union.

Owen



From mfidelman at meetinghouse.net  Tue Sep 16 23:01:55 2014
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Tue, 16 Sep 2014 19:01:55 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <20140916152132.7F89D814@m0005296.ppops.net>
References: <20140916152132.7F89D814@m0005296.ppops.net>
Message-ID: <5418C163.4020701@meetinghouse.net>

Scott Weeks wrote:
>
>> On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley at gmail.com> wrote:
>> What is the single best book you have read on
>> networking?
> -----------------------------
>
>
> Paper is soooo 20th century.  C'mon, we're a decade and
> a half into the 21st century.   :-)
>
> http://www.tcpipguide.com/free/t_toc.htm
>
> scott
Experience the power of the bookbook:
https://www.youtube.com/watch?v=MOXQo7nURs0

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra



From mohta at necom830.hpcl.titech.ac.jp  Tue Sep 16 23:57:38 2014
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Wed, 17 Sep 2014 08:57:38 +0900
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <5418CE72.6000304@necom830.hpcl.titech.ac.jp>

What will happen to ".uk" if England is left alone?

					Masataka Ohta




From rubensk at gmail.com  Wed Sep 17 00:01:38 2014
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 16 Sep 2014 21:01:38 -0300
Subject: Scotland ccTLD?
In-Reply-To: <5418CE72.6000304@necom830.hpcl.titech.ac.jp>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <5418CE72.6000304@necom830.hpcl.titech.ac.jp>
Message-ID: <CAGFn2k01FjZSBP+2jpaFum0frc790PKZ63TsAJYa4p0BhBVtFQ@mail.gmail.com>

On Tue, Sep 16, 2014 at 8:57 PM, Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> What will happen to ".uk" if England is left alone?
>

Will be reserved to a future "United Korea" if that happens...


Rubens


From mpalmer at hezmatt.org  Wed Sep 17 00:21:37 2014
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Wed, 17 Sep 2014 10:21:37 +1000
Subject: Scotland ccTLD?
In-Reply-To: <21528.27876.774494.71428@world.std.com>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <21528.27876.774494.71428@world.std.com>
Message-ID: <20140917002137.GK25667@hezmatt.org>

On Tue, Sep 16, 2014 at 01:01:24PM -0400, Barry Shein wrote:
> .PC, for Picts (I believe it's available.) But I doubt that would fly.

They could abolish all taxes and fund the entire country just on domain name
sales.

> I don't know anything about Scotland's attitude toward being
> identified with the Picts, however. Perhaps that's a nonsensical idea.

They've always been a bit picty about that sort of thing.

- Matt



From kmedcalf at dessus.com  Wed Sep 17 00:33:27 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Tue, 16 Sep 2014 18:33:27 -0600
Subject: Scotland ccTLD?
In-Reply-To: <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
Message-ID: <26f455d3e70a664384c0a6d4dc22413c@mail.dessus.com>



>sc is Seychelles. Available s* include sf, sp, sq, su and sw. They should
>pick .sf, use .scot for in-country domains and sell all .sf domains to
>San Francisco residents.

Or Science Fiction productions.  Lots more money there.






From larrysheldon at cox.net  Wed Sep 17 01:06:44 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Tue, 16 Sep 2014 20:06:44 -0500
Subject: Book / Literature Recommendations
In-Reply-To: <rz2q1o0191cZc5601z2sH1>
References: <20140916152132.7F89D814@m0005296.ppops.net>
 <rz2q1o0191cZc5601z2sH1>
Message-ID: <5418DEA4.1040608@cox.net>

On 9/16/2014 18:01, Miles Fidelman wrote:
> Scott Weeks wrote:
>>
>>> On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley at gmail.com> wrote:
>>> What is the single best book you have read on
>>> networking?
>> -----------------------------
>>
>>
>> Paper is soooo 20th century.  C'mon, we're a decade and
>> a half into the 21st century.   :-)
>>
>> http://www.tcpipguide.com/free/t_toc.htm
>>
>> scott
> Experience the power of the bookbook:
> https://www.youtube.com/watch?v=MOXQo7nURs0


And I will tell you that when you are in a dark wiring closet trying to 
figure out how to "get into" an unfamiliar piece of equipment, a 
flashlight and the right collection of paper is priceless, while the 
cold, dark screen is worthless.

I think of this "paperless" idiocy every time I write "20 reams of 
printer paper" on the grocery list.  For the first half of my life -- 
maybe a little less -- I did not ever do that.  Thanks, G*d, I no longer 
by 8? X 11 and 11 X 17 fan-fold (? of that green-bar).

-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


From larrysheldon at cox.net  Wed Sep 17 01:15:36 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Tue, 16 Sep 2014 20:15:36 -0500
Subject: Scotland ccTLD?
In-Reply-To: <rzyY1o00Y1cZc5601zyZoL>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <rzyY1o00Y1cZc5601zyZoL>
Message-ID: <5418E0B8.2060501@cox.net>

On 9/16/2014 18:57, Masataka Ohta wrote:
> What will happen to ".uk" if England is left alone?
> 
> 					Masataka Ohta

There are still at least 3 countries left in the UK if Scotland splits.

The name change is that in that event, Great Britain (.gb
country-code 	Reserved Domain - IANA) will refer only to the land mass
(which it should any way, but if often used to refer to the three
kingdoms on it.


-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


From rdobbins at arbor.net  Wed Sep 17 01:27:57 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 17 Sep 2014 08:27:57 +0700
Subject: Book / Literature Recommendations
In-Reply-To: <5418DEA4.1040608@cox.net>
References: <20140916152132.7F89D814@m0005296.ppops.net>
 <rz2q1o0191cZc5601z2sH1> <5418DEA4.1040608@cox.net>
Message-ID: <52FFD7D2-B115-470B-AFA8-63AFEEE8EB52@arbor.net>


On Sep 17, 2014, at 8:06 AM, Larry Sheldon <larrysheldon at cox.net> wrote:

> I think of this "paperless" idiocy every time I write "20 reams of printer paper" on the grocery list.

While it should be mandatory that things like operational plans/procedures and contact lists should be printed out Just In Case, the ability to have a near-infinite number of books and other references in my mobile phone, which has a 9,000mAh battery which doesn't need to be charged more than once every 3 or 4 days (as well as a spare battery of the same capacity), makes it a lot easier to a) have ready access to reference materials I know in advance I need and b) quickly locate and download any additional references I may need, but hadn't anticipated needing ahead of time.

This capability has been of great utility on several occasions involving significant sturm und drang.

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

                   Equo ne credite, Teucri.

    		   	  -- Laoco?n



From lists at mtin.net  Wed Sep 17 01:37:58 2014
From: lists at mtin.net (Justin Wilson)
Date: Tue, 16 Sep 2014 21:37:58 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <52FFD7D2-B115-470B-AFA8-63AFEEE8EB52@arbor.net>
References: <20140916152132.7F89D814@m0005296.ppops.net>
 <rz2q1o0191cZc5601z2sH1> <5418DEA4.1040608@cox.net>
 <52FFD7D2-B115-470B-AFA8-63AFEEE8EB52@arbor.net>
Message-ID: <D03E5DE0.7EE70%lists@mtin.net>

Being able to find an Internet connection these days is pretty easy.  Ive
left the data center and driven to mcdonalds to download stuff in a pinch.
But, I can find things in a real book easier.  I think it?s the way my
mind works.  Its getting easier though on the Kindle. Just learned
behavior is all.

Justin

--
Justin Wilson <j2sw at mtin.net>
http://www.mtin.net <http://www.mtin.net/blog>
Managed Services ? xISP Solutions ? Data Centers
http://www.thebrotherswisp.com
Podcast about xISP topics





On 9/16/14, 9:27 PM, "Roland Dobbins" <rdobbins at arbor.net> wrote:

>
>On Sep 17, 2014, at 8:06 AM, Larry Sheldon <larrysheldon at cox.net> wrote:
>
>> I think of this "paperless" idiocy every time I write "20 reams of
>>printer paper" on the grocery list.
>
>While it should be mandatory that things like operational
>plans/procedures and contact lists should be printed out Just In Case,
>the ability to have a near-infinite number of books and other references
>in my mobile phone, which has a 9,000mAh battery which doesn't need to be
>charged more than once every 3 or 4 days (as well as a spare battery of
>the same capacity), makes it a lot easier to a) have ready access to
>reference materials I know in advance I need and b) quickly locate and
>download any additional references I may need, but hadn't anticipated
>needing ahead of time.
>
>This capability has been of great utility on several occasions involving
>significant sturm und drang.
>
>----------------------------------------------------------------------
>Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                   Equo ne credite, Teucri.
>
>    		   	  -- Laoco?n
>




From rdobbins at arbor.net  Wed Sep 17 01:46:43 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 17 Sep 2014 08:46:43 +0700
Subject: Book / Literature Recommendations
In-Reply-To: <D03E5DE0.7EE70%lists@mtin.net>
References: <20140916152132.7F89D814@m0005296.ppops.net>
 <rz2q1o0191cZc5601z2sH1> <5418DEA4.1040608@cox.net>
 <52FFD7D2-B115-470B-AFA8-63AFEEE8EB52@arbor.net>
 <D03E5DE0.7EE70%lists@mtin.net>
Message-ID: <5398A9BE-E8DE-4936-918C-394D86C039D5@arbor.net>


On Sep 17, 2014, at 8:37 AM, Justin Wilson <lists at mtin.net> wrote:

> But, I can find things in a real book easier.

Full-text search in the Kindle app, .pdf viewer app, et. al. is pretty useful for finding things, IMHO.

;>

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

                   Equo ne credite, Teucri.

    		   	  -- Laoco?n



From kmedcalf at dessus.com  Wed Sep 17 04:07:27 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Tue, 16 Sep 2014 22:07:27 -0600
Subject: Book / Literature Recommendations
In-Reply-To: <52FFD7D2-B115-470B-AFA8-63AFEEE8EB52@arbor.net>
Message-ID: <3b5814e1509276409a95840be3d7fb21@mail.dessus.com>


On Tuesday, 16 September, 2014, 19:28, Roland Dobbins <rdobbins at arbor.net> said:
>On Sep 17, 2014, at 8:06 AM, Larry Sheldon <larrysheldon at cox.net> wrote:

>> I think of this "paperless" idiocy every time I write "20 reams of
>>rinter paper" on the grocery list.

>While it should be mandatory that things like operational
>plans/procedures and contact lists should be printed out Just In Case,
>the ability to have a near-infinite number of books and other references
>in my mobile phone, which has a 9,000mAh battery which doesn't need to be
>charged more than once every 3 or 4 days (as well as a spare battery of
>the same capacity), makes it a lot easier to a) have ready access to
>reference materials I know in advance I need and b) quickly locate and
>download any additional references I may need, but hadn't anticipated
>needing ahead of time.
>
>This capability has been of great utility on several occasions involving
>significant sturm und drang.

I bought super extended batteries for my Galaxy III and its great -- lasts about 84 hours with all functions turned on.  Most phones these days, however, ship with teeny weenie batteries that can barely keep the device working for a few hours at a time, let alone be actually useful for anything (unless you carry four or five fully charges spares with you at all times).  The manufacturer provided battery would last about 6 hours with all functions turned on, provided you never used the phone or turned on the display.  Some manufacturers even specialize in manufacturing non-serviceable devices in which you cannot put a real battery if you wanted.

Now if only there was a way to get them to not use that bloody awful super-glare glass (or get it replaced with a matte non-glare glass) so that you didn't have to go stand in a dark closet to use the phone ...






From drohan at gmail.com  Wed Sep 17 04:34:23 2014
From: drohan at gmail.com (Daniel Rohan)
Date: Tue, 16 Sep 2014 21:34:23 -0700
Subject: Book / Literature Recommendations
In-Reply-To: <20140916135512.7e7b71ac@localhost>
References: <CAAWx_pUCTN-p1+=8EYm9iBsks8Y+pzE85q8=nL_Beb6JV6_AZQ@mail.gmail.com>
 <20140916135512.7e7b71ac@localhost>
Message-ID: <CAJXc8RKz8HUdHCK5fboUUn9i9McGU_sEX-NPc-WOdWw4749E_Q@mail.gmail.com>

+1 for Perlman's Interconnections. I love her humor peppered throughout.

On Tuesday, September 16, 2014, John Kristoff <jtk at cymru.com> wrote:

> On Tue, 16 Sep 2014 09:48:45 +0100
> James Bensley <jwbensley at gmail.com <javascript:;>> wrote:
>
> > What is the single best book you have read on networking?
>
> I couldn't narrow it down to one, but since it hasn't been mentioned
> already, Radia Perlman's Interconnections.  Her's is utterly fantastic
> largely in part because she often explains why some things are the way
> they are (how we got what we have) and sometimes why what we have isn't
> always so great.  Other great books mentioned take a similar tack, they
> go beyond what is in written specs.
>
> John
>


From rdobbins at arbor.net  Wed Sep 17 05:03:16 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 17 Sep 2014 12:03:16 +0700
Subject: Book / Literature Recommendations
In-Reply-To: <3b5814e1509276409a95840be3d7fb21@mail.dessus.com>
References: <3b5814e1509276409a95840be3d7fb21@mail.dessus.com>
Message-ID: <27E4D0EB-3770-46BB-ABD8-1DBC7F616C1F@arbor.net>


On Sep 17, 2014, at 11:07 AM, Keith Medcalf <kmedcalf at dessus.com> wrote:

> Most phones these days, however, ship with teeny weenie batteries that can barely keep the device working for a few hours at a time, let alone be actually useful for anything (unless you carry four or five fully charges spares with you at all times).  The manufacturer provided battery would last about 6 hours with all functions turned on, provided you never used the phone or turned on the display.

Samsung's Note 2 (what I'm using), Note 3, and the upcoming Note 4 all sport removable batteries, thankfully, along with MicroSD slots (I have a 128GB MicroSD in mine).
 
ZeroLemon (available through Amazon) make high-capacity batteries/cases for the Samsung phones.  I have two of their 9,000mAh extended batteries for the Note 2, along with their ZeroShock case which replaces the back cover of the phone and holds the extended-life batteries (the batteries themselves come with replacement back covers/cases, but I prefer the presumed additional protection offered by the ZeroShock case).

>  Some manufacturers even specialize in manufacturing non-serviceable devices in which you cannot put a real battery if you wanted.

For iPhone users, the iBattz battery cases feature removable batteries - they're the same ones used in the Samsung Galaxy S3, and so are readily available.  So, one can  replace the batteries in the battery case as needed, which is the best design I've seen for the iPhone.  iBattz are available via Amazon, as well.  Battery chargers for these batteries are also readily available, so that one can charge the batteries themselves without being forced to plug the iPhone/case itself into a charger (also available from Amazon).  

> Now if only there was a way to get them to not use that bloody awful super-glare glass (or get it replaced with a matte non-glare glass) so that you didn't have to go stand in a dark closet to use the phone ...

Anti-glare screen protectors are available for most any phone, these days.  Again, they're available via Amazon.

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

                   Equo ne credite, Teucri.

    		   	  -- Laoco?n



From mfidelman at meetinghouse.net  Wed Sep 17 05:09:08 2014
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Wed, 17 Sep 2014 01:09:08 -0400
Subject: Book / Literature Recommendations
In-Reply-To: <27E4D0EB-3770-46BB-ABD8-1DBC7F616C1F@arbor.net>
References: <3b5814e1509276409a95840be3d7fb21@mail.dessus.com>
 <27E4D0EB-3770-46BB-ABD8-1DBC7F616C1F@arbor.net>
Message-ID: <54191774.8020606@meetinghouse.net>

Roland Dobbins wrote:
> On Sep 17, 2014, at 11:07 AM, Keith Medcalf <kmedcalf at dessus.com> wrote:
>
>> Most phones these days, however, ship with teeny weenie batteries that can barely keep the device working for a few hours at a time, let alone be actually useful for anything (unless you carry four or five fully charges spares with you at all times).  The manufacturer provided battery would last about 6 hours with all functions turned on, provided you never used the phone or turned on the display.
> Samsung's Note 2 (what I'm using), Note 3, and the upcoming Note 4 all sport removable batteries, thankfully, along with MicroSD slots (I have a 128GB MicroSD in mine).
>   
> ZeroLemon (available through Amazon) make high-capacity batteries/cases for the Samsung phones.  I have two of their 9,000mAh extended batteries for the Note 2, along with their ZeroShock case which replaces the back cover of the phone and holds the extended-life batteries (the batteries themselves come with replacement back covers/cases, but I prefer the presumed additional protection offered by the ZeroShock case).

My Note 2 would be useless without one of those big batteries.


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra



From oscar.vives at gmail.com  Wed Sep 17 08:02:45 2014
From: oscar.vives at gmail.com (Tei)
Date: Wed, 17 Sep 2014 10:02:45 +0200
Subject: Scotland ccTLD?
In-Reply-To: <5418E0B8.2060501@cox.net>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <5418E0B8.2060501@cox.net>
Message-ID: <CACg3zYEHwudTfoPGHRS+9eJWLV++kSOAnFBypa9LLy8cZps8vw@mail.gmail.com>

http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table

VR, GO, ON, NY, ...these seems to be free :D

Clearly New York must declare independence.

-- 
--
?in del ?ensaje.


From david at cantrell.org.uk  Wed Sep 17 12:18:18 2014
From: david at cantrell.org.uk (David Cantrell)
Date: Wed, 17 Sep 2014 13:18:18 +0100
Subject: Scotland ccTLD?
In-Reply-To: <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
Message-ID: <20140917121818.GA7300@bytemark.barnyard.co.uk>

On Tue, Sep 16, 2014 at 09:26:24AM -0700, David Conrad wrote:

> SU is the Soviet Union, now classified as ?exceptionally reserved? which IANA treats as available for assignment (other exceptionally reserved codes are EU, UK, and AC)...

Do you not mean *un*available for assignment? They're not going to go
assigning .eu or .uk to anyone because they're already assigned and in
use. .ac is too, although it's rather less important.

-- 
David Cantrell | top google result for "topless karaoke murders"

You can't spell AWESOME without ME!


From lists at quux.de  Wed Sep 17 14:17:16 2014
From: lists at quux.de (Jens Link)
Date: Wed, 17 Sep 2014 16:17:16 +0200
Subject: Scotland ccTLD?
In-Reply-To: <8DE5EAE1-1810-4842-8562-2D3B178B7BEC@delong.com> (Owen DeLong's
 message of "Tue, 16 Sep 2014 15:43:56 -0700")
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <20140916155549.GA2873@puck.nether.net>
 <8DE5EAE1-1810-4842-8562-2D3B178B7BEC@delong.com>
Message-ID: <877g12gwlv.fsf@pc8.berlin.quux.de>

Owen DeLong <owen at delong.com> writes:

> On Sep 16, 2014, at 8:55 AM, Majdi S. Abbas <msa at latt.net> wrote:

>> 	su is not available.
> I think it is now, since the break up of the Soviet Union.

A friend told me that .su domains are quite common in windows
environments after the admins discovered that .local is not a good
choice. ;-)

Jens
-- 
----------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink at jabber.quux.de | ---------------  | 
----------------------------------------------------------------------------


From drc at virtualized.org  Wed Sep 17 14:26:31 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 07:26:31 -0700
Subject: Scotland ccTLD?
In-Reply-To: <20140917121818.GA7300@bytemark.barnyard.co.uk>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <3595FE58-34EC-4A83-B685-95BF70DC4773@virtualized.org>
 <20140917121818.GA7300@bytemark.barnyard.co.uk>
Message-ID: <FC7E1823-9774-4920-BC95-146A4009DB44@virtualized.org>

Hi,

On Sep 17, 2014, at 5:18 AM, David Cantrell <david at cantrell.org.uk> wrote:
> On Tue, Sep 16, 2014 at 09:26:24AM -0700, David Conrad wrote:
> 
>> SU is the Soviet Union, now classified as ?exceptionally reserved? which IANA treats as available for assignment (other exceptionally reserved codes are EU, UK, and AC)...
> 
> Do you not mean *un*available for assignment?

Apologies for the ambiguity. IANA treats the ?exceptionally reserved? category as available for assignment as a CCTLD and a number of exceptionally reserved ISO-3166-2 codes have been assigned (including SU, AC, EU, etc).

> They're not going to go
> assigning .eu or .uk to anyone because they're already assigned and in
> use. .ac is too, although it's rather less important.

Right.  Similarly, .SU has been assigned.  SU is a bit odd in the sense that it was moved to ?transitionally reserved? when the Soviet Union broke up and a batch of new country codes were created (e.g., RU, UA, etc.) and then, in 2007 (or so) it was moved from ?transitionally reserved? (which the ISO 3166 Maintenance Agency says ?stop use ASAP?) to ?exceptionally reserved?.  The .SU ccTLD is also a bit odd in that it is the only code that does not (officially) have a nation-state (and hence a legal framework) behind it. In practice, I believe it falls under the Russian legal framework.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/e3e558d9/attachment.sig>

From drc at virtualized.org  Wed Sep 17 14:32:38 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 07:32:38 -0700
Subject: Scotland ccTLD?
In-Reply-To: <877g12gwlv.fsf@pc8.berlin.quux.de>
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <20140916155549.GA2873@puck.nether.net>
 <8DE5EAE1-1810-4842-8562-2D3B178B7BEC@delong.com>
 <877g12gwlv.fsf@pc8.berlin.quux.de>
Message-ID: <EFA3573C-0B19-4D7A-9A19-AF6F7463149E@virtualized.org>

On Sep 17, 2014, at 7:17 AM, Jens Link <lists at quux.de> wrote:
> Owen DeLong <owen at delong.com> writes:
>> On Sep 16, 2014, at 8:55 AM, Majdi S. Abbas <msa at latt.net> wrote:
>>> 	su is not available.
>> I think it is now, since the break up of the Soviet Union.

No it is not.

> A friend told me that .su domains are quite common in windows
> environments after the admins discovered that .local is not a good
> choice. ;-)

That would be an *exceptionally* bad idea.  If queries to those domains leaked out of the local environment (which, of course, _never_ happens), they could be resolved simply by purchasing the .SU domain and then setting up name servers with a wildcard to return an address for a honeypot.  The bad guys could then just sit and wait (and then profit).  This is a form of ?name collision? which is all the rage these days (see https://www.icann.org/resources/pages/name-collision-2013-12-06-en).

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/3dd840c4/attachment.sig>

From lists at quux.de  Wed Sep 17 14:52:11 2014
From: lists at quux.de (Jens Link)
Date: Wed, 17 Sep 2014 16:52:11 +0200
Subject: Scotland ccTLD?
In-Reply-To: <EFA3573C-0B19-4D7A-9A19-AF6F7463149E@virtualized.org> (David
 Conrad's message of "Wed, 17 Sep 2014 07:32:38 -0700")
References: <23566941.1804.1410881042458.JavaMail.root@benjamin.baylink.com>
 <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <CAArzuostSHJ+SP_V3AtqKpmDOkyCByfCV-x9HYTpmu2LOdphEA@mail.gmail.com>
 <CAGFn2k2mbeMYSqW9KrQS_wBvqzW1t8umWyWzz_MzA=0obrkeBQ@mail.gmail.com>
 <20140916155549.GA2873@puck.nether.net>
 <8DE5EAE1-1810-4842-8562-2D3B178B7BEC@delong.com>
 <877g12gwlv.fsf@pc8.berlin.quux.de>
 <EFA3573C-0B19-4D7A-9A19-AF6F7463149E@virtualized.org>
Message-ID: <87tx46fgf8.fsf@pc8.berlin.quux.de>

David Conrad <drc at virtualized.org> writes:

>> A friend told me that .su domains are quite common in windows
>> environments after the admins discovered that .local is not a good
>> choice. ;-)
>
> That would be an *exceptionally* bad idea. 

I agree. On the other hand: People pay me to fix network problems,
including DNS. 

Jens
-- 
----------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink at jabber.quux.de | ---------------  | 
----------------------------------------------------------------------------


From bmanning at isi.edu  Wed Sep 17 15:03:02 2014
From: bmanning at isi.edu (manning bill)
Date: Wed, 17 Sep 2014 08:03:02 -0700
Subject: Scotland ccTLD? - armchair quarterbacking
In-Reply-To: <5418E0B8.2060501@cox.net>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <rzyY1o00Y1cZc5601zyZoL> <5418E0B8.2060501@cox.net>
Message-ID: <B571906F-1D11-4D32-BFE0-91DC666608B5@isi.edu>

Perhaps a dose of factual information may temper this thread.
If we are talking about ISO-3166-2 - the basis for the CCTLD delegations, then:

1_  Scotland has no say in the country code selected.
2_  ICANN has no say in the country code selected.
3_  The choice is up to an ISO committee.   

See:  http://www.iso.org/iso/country_codes.htm


/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 16September2014Tuesday, at 18:15, Larry Sheldon <LarrySheldon at cox.net> wrote:

> On 9/16/2014 18:57, Masataka Ohta wrote:
>> What will happen to ".uk" if England is left alone?
>> 
>> 					Masataka Ohta
> 
> There are still at least 3 countries left in the UK if Scotland splits.
> 
> The name change is that in that event, Great Britain (.gb
> country-code 	Reserved Domain - IANA) will refer only to the land mass
> (which it should any way, but if often used to refer to the three
> kingdoms on it.
> 
> 
> -- 
> The unique Characteristics of System Administrators:
> 
> The fact that they are infallible; and,
> 
> The fact that they learn from their mistakes.



From brunner at nic-naa.net  Wed Sep 17 15:28:52 2014
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 17 Sep 2014 08:28:52 -0700
Subject: Scotland ccTLD? - armchair quarterbacking
In-Reply-To: <B571906F-1D11-4D32-BFE0-91DC666608B5@isi.edu>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <rzyY1o00Y1cZc5601zyZoL> <5418E0B8.2060501@cox.net>
 <B571906F-1D11-4D32-BFE0-91DC666608B5@isi.edu>
Message-ID: <5419A8B4.9030402@nic-naa.net>

well, apropos to point #2, the iso3166/ma includes representatives from
ten agencies, of which a certain 501(c)(3) originally in marina del rey,
now in los angeles, is included.

however, i can't imagine staff offering an opinion of record on the subject.

"ay" for "aye" would work for me.

-e

On 9/17/14 8:03 AM, manning bill wrote:
> Perhaps a dose of factual information may temper this thread.
> If we are talking about ISO-3166-2 - the basis for the CCTLD delegations, then:
>
> 1_  Scotland has no say in the country code selected.
> 2_  ICANN has no say in the country code selected.
> 3_  The choice is up to an ISO committee.   
>
> See:  http://www.iso.org/iso/country_codes.htm
>
>
> /bill
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
>
> On 16September2014Tuesday, at 18:15, Larry Sheldon <LarrySheldon at cox.net> wrote:
>
>> On 9/16/2014 18:57, Masataka Ohta wrote:
>>> What will happen to ".uk" if England is left alone?
>>>
>>> 					Masataka Ohta
>> There are still at least 3 countries left in the UK if Scotland splits.
>>
>> The name change is that in that event, Great Britain (.gb
>> country-code 	Reserved Domain - IANA) will refer only to the land mass
>> (which it should any way, but if often used to refer to the three
>> kingdoms on it.
>>
>>
>> -- 
>> The unique Characteristics of System Administrators:
>>
>> The fact that they are infallible; and,
>>
>> The fact that they learn from their mistakes.
>
>
>



From dougb at dougbarton.us  Wed Sep 17 15:48:27 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 17 Sep 2014 08:48:27 -0700
Subject: Scotland ccTLD? - armchair quarterbacking
In-Reply-To: <B571906F-1D11-4D32-BFE0-91DC666608B5@isi.edu>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <rzyY1o00Y1cZc5601zyZoL> <5418E0B8.2060501@cox.net>
 <B571906F-1D11-4D32-BFE0-91DC666608B5@isi.edu>
Message-ID: <5419AD4B.2040906@dougbarton.us>

On 9/17/14 8:03 AM, manning bill wrote:
> Perhaps a dose of factual information may temper this thread.
> If we are talking about ISO-3166-2 - the basis for the CCTLD delegations, then:
> 
> 1_  Scotland has no say in the country code selected.

This is not actually true. We have prior art on countries not liking the
code they were assigned, and successfully lobbying for it to be changed.
This is one of the entanglements that I referred to previously. :)

Doug



From jra at baylink.com  Wed Sep 17 16:03:19 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 12:03:19 -0400 (EDT)
Subject: Scotland ccTLD? - armchair quarterbacking
In-Reply-To: <B571906F-1D11-4D32-BFE0-91DC666608B5@isi.edu>
Message-ID: <23536056.1988.1410969799048.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "manning bill" <bmanning at isi.edu>

> Perhaps a dose of factual information may temper this thread.
> If we are talking about ISO-3166-2 - the basis for the CCTLD
> delegations, then:
> 
> 1_ Scotland has no say in the country code selected.

Am I missing something, or is the Finnish transition from .sf to .fi 
counterevidence to that assertion?

Cheers,
-- jr 'so many things are just me' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Wed Sep 17 16:09:15 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 12:09:15 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <16339722.1990.1410969884627.JavaMail.root@benjamin.baylink.com>
Message-ID: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>

Pursuant to

  https://www.icann.org/resources/pages/name-collision-2013-12-06-en)

mentioned in the Scotland thread... it seems there are two major potential
points of possible collision:

1) User network uses "fake" TLD which is no longer fake, and local 
resolver server blows it

2) User network blows it worse, and tries to resolve a monocomponent name
off non-local servers.

The latter would seem to be avoidable by making sure that *DNS resolution
of bare TLDs always returns NXDOMAIN*.

Is that a requirement for a TLD?

If it isn't, does anyone know of any domains dumb enough to actual 
return something for a lookup on the bare TLD?

Is there actually *any* good reason why a lookup on a bare TLD ("com.")
might return a valid record?

And what about Naomi?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Wed Sep 17 16:10:54 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 12:10:54 -0400 (EDT)
Subject: Scotland ccTLD?
In-Reply-To: <FC7E1823-9774-4920-BC95-146A4009DB44@virtualized.org>
Message-ID: <10441777.1994.1410970254061.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "David Conrad" <drc at virtualized.org>

> Right. Similarly, .SU has been assigned. SU is a bit odd in the sense
> that it was moved to ?transitionally reserved? when the Soviet Union
> broke up and a batch of new country codes were created (e.g., RU, UA,
> etc.) and then, in 2007 (or so) it was moved from ?transitionally
> reserved? (which the ISO 3166 Maintenance Agency says ?stop use ASAP?)
> to ?exceptionally reserved?. The .SU ccTLD is also a bit odd in that
> it is the only code that does not (officially) have a nation-state
> (and hence a legal framework) behind it. In practice, I believe it
> falls under the Russian legal framework.

The European Union (holder of .eu) is not a nation-state either, is it?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From drc at virtualized.org  Wed Sep 17 16:46:12 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 09:46:12 -0700
Subject: Bare TLD resolutions
In-Reply-To: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
References: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
Message-ID: <323CB74D-8B3C-4E7D-BEC3-99BBBFA080B6@virtualized.org>

Jay,

On Sep 17, 2014, at 9:09 AM, Jay Ashworth <jra at baylink.com> wrote:
> it seems there are two major potential points of possible collision:
> 
> 1) User network uses "fake" TLD which is no longer fake, and local 
> resolver server blows it
> 
> 2) User network blows it worse, and tries to resolve a monocomponent name
> off non-local servers.

A common case of name collision is driven by the ?DNS search path?, e.g., if you have a ?search path? of ?bar.com;foo.bar.com? and you type ?telnet baz?, _some_ resolver libraries will try to resolve ?baz.bar.com?, if that fails then ?baz.foo.bar.com?, if that fails then ?baz.?, if that fails return an error to the user.

However, the "search path? algorithm was never fully standardized and there are implementations that try ?baz.? first (there are even some implementations that will split up the path elements, e.g., if ?baz.bar.com? fails, the resolver library will try ?baz.com?).

In my view, given the lack of standardization and the potential security implications, search paths shouldn?t be used at all.

> The latter would seem to be avoidable by making sure that *DNS resolution
> of bare TLDs always returns NXDOMAIN*.

It is quite rare that a TLD is queried for directly. Resolver libraries generally do not parse the name being queried and send the minimum to the authoritative servers. That is, if a resolver is asked for ?foo.bar.com?, it sends the entire string to the root server and gets back a referral to the COM servers ? it generally does not parse ?foo.bar.com? to get the TLD and send ?COM? to the root servers to get the referral. This latter behavior is called ?QNAME minimization? and is a good idea for performance and privacy (and other reasons), but not yet generally implemented because it is a bit tricky in the general case. 

> If it isn't, does anyone know of any domains dumb enough to actual 
> return something for a lookup on the bare TLD?

There are a few ccTLDs that provide apex wildcards: they?ll return an ?A? record for any random goop (.WS is an example), however this behavior is banned from gTLDs (an outcome of the SiteFinder debacle).

> Is there actually *any* good reason why a lookup on a bare TLD ("com.")
> might return a valid record?

Some of the folks in ICANN?s new gTLD program, typically the folks who?ve gone for ?brand? TLDs (e.g., .bmw), have argued for what?s called ?dotless? domains: they want people to be able to do stuff like point their browsers at ?http://bmw? and have the web page for BMW show up.  Unfortunately for them, several oceans have already gone under that particular bridge (see https://www.icann.org/en/system/files/files/sac-053-en.pdf) and ICANN has (to date) resisted those requests. (I actually don?t know if the folks behind .BMW wanted dotless domains ? just using BMW as an example)

> And what about Naomi?

Never was a big fan of the chair.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/4cbab2a8/attachment.sig>

From drc at virtualized.org  Wed Sep 17 16:47:45 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 09:47:45 -0700
Subject: Scotland ccTLD?
In-Reply-To: <10441777.1994.1410970254061.JavaMail.root@benjamin.baylink.com>
References: <10441777.1994.1410970254061.JavaMail.root@benjamin.baylink.com>
Message-ID: <DE8DEB4E-1685-4922-B4B7-CFC30BF0F76D@virtualized.org>

On Sep 17, 2014, at 9:10 AM, Jay Ashworth <jra at baylink.com> wrote:
>> The .SU ccTLD is also a bit odd in that
>> it is the only code that does not (officially) have a nation-state
>> (and hence a legal framework) behind it. In practice, I believe it
>> falls under the Russian legal framework.
> 
> The European Union (holder of .eu) is not a nation-state either, is it?

No, but the EC exists.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/e915e1fb/attachment.sig>

From zachary.mcgibbon+nanog at gmail.com  Wed Sep 17 16:53:29 2014
From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon)
Date: Wed, 17 Sep 2014 12:53:29 -0400
Subject: Here comes iOS 8...
Message-ID: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>

So Apple is about to release iOS 8... Have you done anything special to
your network setup to accommodate the traffic flood ie traffic shaping
rules, cache servers, etc?

I heard that Apple Caching servers won't work with this update, so I'm
guessing it will be pushed through Akamai servers as is usually is.

- Zachary


From nick at flhsi.com  Wed Sep 17 17:04:25 2014
From: nick at flhsi.com (Nick Olsen)
Date: Wed, 17 Sep 2014 13:04:25 -0400
Subject: Here comes iOS 8...
In-Reply-To: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
Message-ID: <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>

I've been waiting all morning.
  
 Expedited repair of a primary link to prepare for the traffic. Not that it 
didn't have multiple backups. But one doesn't trifle with IOS8 release 
traffic.. If it's anything like IOS7 was..
  
 Nick Olsen
Network Operations  (855) FLSPEED  x106
 

----------------------------------------
 From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
Sent: Wednesday, September 17, 2014 12:59 PM
To: "NANOG" <nanog at nanog.org>
Subject: Here comes iOS 8...   
So Apple is about to release iOS 8... Have you done anything special to
your network setup to accommodate the traffic flood ie traffic shaping
rules, cache servers, etc?

I heard that Apple Caching servers won't work with this update, so I'm
guessing it will be pushed through Akamai servers as is usually is.

- Zachary
 



From brunner at nic-naa.net  Wed Sep 17 17:16:04 2014
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 17 Sep 2014 10:16:04 -0700
Subject: Scotland ccTLD?
In-Reply-To: <10441777.1994.1410970254061.JavaMail.root@benjamin.baylink.com>
References: <10441777.1994.1410970254061.JavaMail.root@benjamin.baylink.com>
Message-ID: <5419C1D4.2010302@nic-naa.net>

On 9/17/14 9:10 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "David Conrad" <drc at virtualized.org>
>> Right. Similarly, .SU has been assigned. SU is a bit odd in the sense
>> that it was moved to ?transitionally reserved? when the Soviet Union
>> broke up and a batch of new country codes were created (e.g., RU, UA,
>> etc.) and then, in 2007 (or so) it was moved from ?transitionally
>> reserved? (which the ISO 3166 Maintenance Agency says ?stop use ASAP?)
>> to ?exceptionally reserved?. The .SU ccTLD is also a bit odd in that
>> it is the only code that does not (officially) have a nation-state
>> (and hence a legal framework) behind it. In practice, I believe it
>> falls under the Russian legal framework.
> The European Union (holder of .eu) is not a nation-state either, is it?
>
> Cheers,
> -- jra
iso3166-1 is not restricted to political jurisdictions, e.g., a 
"nation-state". there are about a dozen regional intellectual property 
organizations which have been allocated iso3166-1 code points, along 
with quite a few bits of postage stamp trivia, my favorites being those 
that have no human residents, some have been recently withdrawn.

in the gtld trade, the .eu hack and the .ps hack stand out as creative 
use -- the first used the existence of a reserved alpha2 for a currency, 
the second a statistical abstraction -- to solve two similar problems -- 
the non-availability of namespaces to de facto political jurisdictions. 
the arab league has attempted, without success to date, to replicate the 
.eu hack, and an attempt has been made, also without success, to 
re-purpose rather than retire an iso3166-1 code point, previously 
allocated to the united states and managed until withdrawn, by the 
insular affairs office of the department of the interior, for one or 
more indigenous polities of north america.

this just popped up in my fb feed (yes, i read rue89), apropos of the 
.su sub-thread. in keeping with the 
owen-knows-more-about-everything-than-i-do truism, one is free to ignore 
this and hold fast to owen's latest revealed wisdom:

http://rue89.nouvelobs.com/2014/09/15/lurss-existe-toujours-internet-cest-devenu-zone-254809

-e


From shortdudey123 at gmail.com  Wed Sep 17 17:31:50 2014
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 17 Sep 2014 10:31:50 -0700
Subject: Here comes iOS 8...
In-Reply-To: <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
Message-ID: <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>

For those that are curious, it looks like the download is 1.1 gigs.

-Grant

On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:

> I've been waiting all morning.
>
>  Expedited repair of a primary link to prepare for the traffic. Not that it
> didn't have multiple backups. But one doesn't trifle with IOS8 release
> traffic.. If it's anything like IOS7 was..
>
>  Nick Olsen
> Network Operations  (855) FLSPEED  x106
>
>
> ----------------------------------------
>  From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
> Sent: Wednesday, September 17, 2014 12:59 PM
> To: "NANOG" <nanog at nanog.org>
> Subject: Here comes iOS 8...
> So Apple is about to release iOS 8... Have you done anything special to
> your network setup to accommodate the traffic flood ie traffic shaping
> rules, cache servers, etc?
>
> I heard that Apple Caching servers won't work with this update, so I'm
> guessing it will be pushed through Akamai servers as is usually is.
>
> - Zachary
>
>
>


From jra at baylink.com  Wed Sep 17 17:36:09 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 13:36:09 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <323CB74D-8B3C-4E7D-BEC3-99BBBFA080B6@virtualized.org>
Message-ID: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "David Conrad" <drc at virtualized.org>

> A common case of name collision is driven by the ?DNS search path?,
> e.g., if you have a ?search path? of ?bar.com;foo.bar.com? and you
> type ?telnet baz?, _some_ resolver libraries will try to resolve
> ?baz.bar.com?, if that fails then ?baz.foo.bar.com?, if that fails
> then ?baz.?, if that fails return an error to the user.
> 
> However, the "search path? algorithm was never fully standardized and
> there are implementations that try ?baz.? first (there are even some
> implementations that will split up the path elements, e.g., if
> ?baz.bar.com? fails, the resolver library will try ?baz.com?).

Yes; this is what I was talking about.

If I have a machine inside my network called "aero", and I telnet to
it, and for some reason the search path blows it, I might try to
resolve "aero." against the Greater Internet, and if the .aero TLD
*returns an A record*, then I'm in trouble.  Correct?

> In my view, given the lack of standardization and the potential
> security implications, search paths shouldn?t be used at all.

True, but not entirely germane to this level of the issue.

> > The latter would seem to be avoidable by making sure that *DNS
> > resolution of bare TLDs always returns NXDOMAIN*.
> 
> It is quite rare that a TLD is queried for directly. Resolver
> libraries generally do not parse the name being queried and send the
> minimum to the authoritative servers. That is, if a resolver is asked
> for ?foo.bar.com?, it sends the entire string to the root server and
> gets back a referral to the COM servers ? it generally does not parse
> ?foo.bar.com? to get the TLD and send ?COM? to the root servers to get
> the referral. This latter behavior is called ?QNAME minimization? and
> is a good idea for performance and privacy (and other reasons), but
> not yet generally implemented because it is a bit tricky in the
> general case.

Sure, but as you pointed out above, we're not talking about that.

We're talking, largely, about error cases *that used to break as you wanted,
and now might not*.

> > If it isn't, does anyone know of any domains dumb enough to actual
> > return something for a lookup on the bare TLD?
> 
> There are a few ccTLDs that provide apex wildcards: they?ll return an
> ?A? record for any random goop (.WS is an example), however this
> behavior is banned from gTLDs (an outcome of the SiteFinder debacle).

A records being returned for bare TLDs *is* formally banned?

(Oh: specifically for cctlds.  Got it.)

Citation?

> > Is there actually *any* good reason why a lookup on a bare TLD
> > ("com.") might return a valid record?
> 
> Some of the folks in ICANN?s new gTLD program, typically the folks
> who?ve gone for ?brand? TLDs (e.g., .bmw), have argued for what?s
> called ?dotless? domains: 

Yeah; that's not a "good" reason.  :-)

> > And what about Naomi?
> 
> Never was a big fan of the chair.

Electric Company FTW.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From zachary.mcgibbon+nanog at gmail.com  Wed Sep 17 17:38:55 2014
From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon)
Date: Wed, 17 Sep 2014 13:38:55 -0400
Subject: Here comes iOS 8...
In-Reply-To: <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
Message-ID: <CAJdNreiTpkZonjKEieOnOmsaS6jZUtBTFVLDr_vrhhkoo=c22A@mail.gmail.com>

At first we saw traffic going directly to Apple (swcdn.apple.com) via our
commercial link, then it went to llnw.net, and now it is going to Akamai.

access1-srp#traceroute swcdn.apple.com
Translating "swcdn.apple.com"...domain server (132.206.44.21) [OK]

Type escape sequence to abort.
Tracing the route to geo.buni.guat.aaplimg.com (17.253.2.221)

  1 internet2-vlan677.GW.McGill.CA (132.216.255.107) [AS 17356] 4 msec 0
msec 0 msec
  2 vtelinet-216-66-110-108.vermontel.net (216.66.110.108) [AS 17356] 12
msec 8 msec 8 msec
  3 206.126.115.175 [AS 17356] 12 msec 8 msec 12 msec

----------

access1-srp#traceroute swcdn.apple.com
Translating "swcdn.apple.com"...domain server (132.206.44.21) [OK]

Type escape sequence to abort.
Tracing the route to apple-dnld.vo.llnwd.net (208.111.128.6)

  1 internet2-vlan877.GW.McGill.CA (132.216.255.99) [AS 17356] 4 msec 0
msec 0 msec
  2 Internet1-vlan710.GW.McGill.CA (192.168.254.4) [AS 15318] 0 msec 0 msec
0 msec
  3 mcgill-gw-qix.risq.net (206.167.128.57) [AS 17356] 0 msec 0 msec 0 msec
  4 mcgill-qix.dmtrl-rq.risq.net (132.202.52.89) [AS 17356] 4 msec 0 msec 0
msec
  5 imtrl-uq.risq.net (192.77.55.245) [AS 17356] 0 msec 0 msec 0 msec
  6 mtrl2rtr2.canarie.ca (199.212.24.82) [AS 6509] 0 msec 4 msec 0 msec
  7 10ge5-4.fr1.lga.llnw.net (198.32.160.134) [AS 17356] 52 msec 8 msec 12
msec

----------

access1-srp#traceroute swcdn.apple.com
Translating "swcdn.apple.com"...domain server (132.206.44.21) [OK]

Type escape sequence to abort.
Tracing the route to a1271.gi3.akamai.net (206.167.78.23)

  1 internet1-vlan876.GW.McGill.CA (132.216.255.97) [AS 17356] 0 msec 4
msec 0 msec
  2 mcgill-gw-intrarisq.risq.net (206.167.128.33) [AS 17356] 60 msec 0 msec
0 msec
  3 mcgill-intrarisq.dmtrl-rq.risq.net (132.202.42.89) [AS 17356] 0 msec 0
msec 0 msec
  4 v2257-colo625.risq.net (132.202.45.14) [AS 376] 0 msec 4 msec 0 msec
  5 a1271.gi3.akamai.net (206.167.78.23) [AS 376] 0 msec 4 msec 0 msec



On Wed, Sep 17, 2014 at 1:31 PM, Grant Ridder <shortdudey123 at gmail.com>
wrote:

> For those that are curious, it looks like the download is 1.1 gigs.
>
> -Grant
>
> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>
>> I've been waiting all morning.
>>
>>  Expedited repair of a primary link to prepare for the traffic. Not that
>> it
>> didn't have multiple backups. But one doesn't trifle with IOS8 release
>> traffic.. If it's anything like IOS7 was..
>>
>>  Nick Olsen
>> Network Operations  (855) FLSPEED  x106
>>
>>
>> ----------------------------------------
>>  From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>> Sent: Wednesday, September 17, 2014 12:59 PM
>> To: "NANOG" <nanog at nanog.org>
>> Subject: Here comes iOS 8...
>> So Apple is about to release iOS 8... Have you done anything special to
>> your network setup to accommodate the traffic flood ie traffic shaping
>> rules, cache servers, etc?
>>
>> I heard that Apple Caching servers won't work with this update, so I'm
>> guessing it will be pushed through Akamai servers as is usually is.
>>
>> - Zachary
>>
>>
>>
>


From dougb at dougbarton.us  Wed Sep 17 17:40:24 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 17 Sep 2014 10:40:24 -0700
Subject: Bare TLD resolutions
In-Reply-To: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
References: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
Message-ID: <5419C788.9010704@dougbarton.us>

On 9/17/14 10:36 AM, Jay Ashworth wrote:

> A records being returned for bare TLDs*is*  formally banned?
>
> (Oh: specifically for cctlds.  Got it.)

No, ICANN doesn't ban anything for the ccTLDs.

> Citation?

The gTLD registry contracts describe the fact that they cannot add A 
records at the zone apex.



From drc at virtualized.org  Wed Sep 17 17:45:23 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 10:45:23 -0700
Subject: Bare TLD resolutions
In-Reply-To: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
References: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
Message-ID: <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>

Jay,

On Sep 17, 2014, at 10:36 AM, Jay Ashworth <jra at baylink.com> wrote:
> We're talking, largely, about error cases *that used to break as you wanted,
> and now might not*.

Yep.  Well, it used to break if you happened to be using the right version of resolver library.  There have been cases where operating system vendors had different search path behaviors in their resolver libraries depending on version and even patch level.  It?s all a bit of a mess.

>> There are a few ccTLDs that provide apex wildcards: they?ll return an
>> ?A? record for any random goop (.WS is an example), however this
>> behavior is banned from gTLDs (an outcome of the SiteFinder debacle).
> 
> A records being returned for bare TLDs *is* formally banned?
> 
> (Oh: specifically for cctlds.  Got it.)

To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or wildcards). ICANN has no mechanism by which policy can be imposed on ccTLDs.

> Citation?

https://www.icann.org/news/announcement-2013-08-30-en

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/496819f2/attachment.sig>

From jra at baylink.com  Wed Sep 17 17:54:15 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 13:54:15 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
Message-ID: <3140833.2010.1410976455317.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "David Conrad" <drc at virtualized.org>

> > A records being returned for bare TLDs *is* formally banned?
> >
> > (Oh: specifically for cctlds. Got it.)
> 
> To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or
> wildcards). ICANN has no mechanism by which policy can be imposed on
> ccTLDs.

Yeah; sorry; quoted it backwards.

> > Citation?
> 
> https://www.icann.org/news/announcement-2013-08-30-en

Thanks, Dave.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From brunner at nic-naa.net  Wed Sep 17 18:08:15 2014
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 17 Sep 2014 11:08:15 -0700
Subject: Bare TLD resolutions
In-Reply-To: <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
References: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
 <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
Message-ID: <5419CE0F.50800@nic-naa.net>

On 9/17/14 10:45 AM, David Conrad wrote:
> To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or wildcards).

um. .museum. ...


From drc at virtualized.org  Wed Sep 17 18:11:45 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 11:11:45 -0700
Subject: Bare TLD resolutions
In-Reply-To: <5419CE0F.50800@nic-naa.net>
References: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
 <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
 <5419CE0F.50800@nic-naa.net>
Message-ID: <A477D226-7E71-480F-A335-0AF4438B873E@virtualized.org>

On Sep 17, 2014, at 11:08 AM, Eric Brunner-Williams <brunner at nic-naa.net> wrote:
> On 9/17/14 10:45 AM, David Conrad wrote:
>> To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or wildcards).
> um. .museum. ?

.MUSEUM gave up their wildcard some time ago.

Regards,
-drc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/7d2562ca/attachment.sig>

From johnl at iecc.com  Wed Sep 17 20:46:40 2014
From: johnl at iecc.com (John Levine)
Date: 17 Sep 2014 20:46:40 -0000
Subject: Bare TLD resolutions
In-Reply-To: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
Message-ID: <20140917204640.37641.qmail@joyce.lan>

>The latter would seem to be avoidable by making sure that *DNS resolution
>of bare TLDs always returns NXDOMAIN*.
>
>Is that a requirement for a TLD?

No. In fact, a TLD lookup that returned NXDOMAIN would be utterly
broken since that would mean the TLD had no SOA, no NS, and no
subdomains.  Perhaps you're confusing it with NOERROR.

>If it isn't, does anyone know of any domains dumb enough to actual 
>return something for a lookup on the bare TLD?

Yes.  If you'd read RFC 7085, you'd already know which ones do.

There have been A and MX records at TLDs nearly as long as there have
been TLDs.

R's,
John


From jra at baylink.com  Wed Sep 17 20:57:52 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 16:57:52 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <20140917204640.37641.qmail@joyce.lan>
Message-ID: <19973779.2038.1410987472068.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "John Levine" <johnl at iecc.com>

> >The latter would seem to be avoidable by making sure that *DNS resolution
> >of bare TLDs always returns NXDOMAIN*.
> >
> >Is that a requirement for a TLD?
> 
> No. In fact, a TLD lookup that returned NXDOMAIN would be utterly
> broken since that would mean the TLD had no SOA, no NS, and no
> subdomains. Perhaps you're confusing it with NOERROR.

No, I was confusing you for someone who understood -- as everyone else
here seems to have -- that I meant "querying for an A, AAAA, or MX 
record".

> >If it isn't, does anyone know of any domains dumb enough to actual
> >return something for a lookup on the bare TLD?
> 
> Yes. If you'd read RFC 7085, you'd already know which ones do.
> 
> There have been A and MX records at TLDs nearly as long as there have
> been TLDs.

And this is *why* I assumed you knew that, since the RFC is yours, and
makes precisely that distinction.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From asullivan at dyn.com  Wed Sep 17 21:13:37 2014
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 17 Sep 2014 17:13:37 -0400
Subject: Bare TLD resolutions
In-Reply-To: <19973779.2038.1410987472068.JavaMail.root@benjamin.baylink.com>
References: <20140917204640.37641.qmail@joyce.lan>
 <19973779.2038.1410987472068.JavaMail.root@benjamin.baylink.com>
Message-ID: <20140917211336.GT89960@dyn.com>

On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
> ----- Original Message -----
> No, I was confusing you for someone who understood -- as everyone else
> here seems to have -- that I meant "querying for an A, AAAA, or MX 
> record".

You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA,
or MX, and not everything else?  Presumably you don't want to do
negative caching?  

A

-- 
Andrew Sullivan
Dyn, Inc.
asullivan at dyn.com
v: +1 603 663 0448


From marka at isc.org  Wed Sep 17 21:39:08 2014
From: marka at isc.org (Mark Andrews)
Date: Thu, 18 Sep 2014 07:39:08 +1000
Subject: Bare TLD resolutions
In-Reply-To: Your message of "Wed, 17 Sep 2014 17:13:37 -0400."
 <20140917211336.GT89960@dyn.com>
References: <20140917204640.37641.qmail@joyce.lan>
 <19973779.2038.1410987472068.JavaMail.root@benjamin.baylink.com>
 <20140917211336.GT89960@dyn.com>
Message-ID: <20140917213908.9A26B1FADC1F@rock.dv.isc.org>


In message <20140917211336.GT89960 at dyn.com>, Andrew Sullivan writes:
> On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
> > ----- Original Message -----
> > No, I was confusing you for someone who understood -- as everyone else
> > here seems to have -- that I meant "querying for an A, AAAA, or MX 
> > record".
> 
> You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA,
> or MX, and not everything else?  Presumably you don't want to do
> negative caching?  
> 
> A
> 
> -- 
> Andrew Sullivan
> Dyn, Inc.
> asullivan at dyn.com
> v: +1 603 663 0448

You want gethostbyname, getaddrinfo to return HOST_NOT_FOUND/EAI_NONAME
if a single label is entered and is not matched by
<label>.<search-list-element>.  localhost is special cased.

You want res_search() to return  HOST_NOT_FOUND if a single label
is entered and is not matched by <label>.<search-list-element>.

You want res_query() and other tools that look in the DNS and are
*not* searching to return whatever is in the DNS.

If you have a new interface that looks for SRV records you want
that to fail if <srv-prefix>.<label>.<search-list-element> is not
found unless searching is explictly disabled.  This allows for
things like "_whois._tcp.tld SRV ...." to work.

Search lists are for hosts and host like things.  Resolver libraries
have different interfaces for different purposes.  Single label
hostnames for reaching non local equipment was deliberately phase
out in the 1980's as it was clearly a bad concept.

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  Wed Sep 17 21:48:58 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 17:48:58 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <20140917211336.GT89960@dyn.com>
Message-ID: <4331947.2044.1410990538588.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Andrew Sullivan" <asullivan at dyn.com>

> On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
> > ----- Original Message -----
> > No, I was confusing you for someone who understood -- as everyone else
> > here seems to have -- that I meant "querying for an A, AAAA, or MX record".
> 
> You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA,
> or MX, and not everything else? Presumably you don't want to do
> negative caching?

I want to return NXDOMAIN *because there is no record of that type at that
node*.

That was the underlying point here; I thought that was pretty clear.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Wed Sep 17 21:51:13 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 17:51:13 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <20140917213908.9A26B1FADC1F@rock.dv.isc.org>
Message-ID: <21906507.2046.1410990673107.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Mark Andrews" <marka at isc.org>

> Search lists are for hosts and host like things. Resolver libraries
> have different interfaces for different purposes. Single label
> hostnames for reaching non local equipment was deliberately phase
> out in the 1980's as it was clearly a bad concept.

Yes, and we're discussing the practical reason *why* it's a bad concept. 

:-)

My abject apologies to everyone who didn't get that I was talking about
the *source* of the problem by synecdoche.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From dougb at dougbarton.us  Wed Sep 17 21:51:15 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 17 Sep 2014 14:51:15 -0700
Subject: Bare TLD resolutions
In-Reply-To: <4331947.2044.1410990538588.JavaMail.root@benjamin.baylink.com>
References: <4331947.2044.1410990538588.JavaMail.root@benjamin.baylink.com>
Message-ID: <541A0253.7020608@dougbarton.us>

On 9/17/14 2:48 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Andrew Sullivan" <asullivan at dyn.com>
>
>> On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
>>> ----- Original Message -----
>>> No, I was confusing you for someone who understood -- as everyone else
>>> here seems to have -- that I meant "querying for an A, AAAA, or MX record".
>>
>> You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA,
>> or MX, and not everything else? Presumably you don't want to do
>> negative caching?
>
> I want to return NXDOMAIN *because there is no record of that type at that
> node*.
>
> That was the underlying point here; I thought that was pretty clear.

But that's not what NXDOMAIN means. :)  You get an NXDOMAIN response 
when there is no label at that point in the tree, period. In the case 
you specify you get the combination of NOANSWER + NOERROR if there is no 
address record, but there are other records (like there are at a zone 
apex).

hth,

Doug




From Valdis.Kletnieks at vt.edu  Wed Sep 17 21:56:14 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 17 Sep 2014 17:56:14 -0400
Subject: Bare TLD resolutions
In-Reply-To: Your message of "Wed, 17 Sep 2014 17:48:58 -0400."
 <4331947.2044.1410990538588.JavaMail.root@benjamin.baylink.com>
References: <4331947.2044.1410990538588.JavaMail.root@benjamin.baylink.com>
Message-ID: <41935.1410990974@turing-police.cc.vt.edu>

On Wed, 17 Sep 2014 17:48:58 -0400, Jay Ashworth said:

> I want to return NXDOMAIN *because there is no record of that type at that
> node*.

NXDOMAIN means "There are no records of *any* type at that node".

NOERROR means "There are no records of *that* type at that node (but the
node exists and there may be records of other types if you ask for them)".

The distinction is important.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/25830263/attachment.sig>

From jra at baylink.com  Wed Sep 17 21:59:51 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 17:59:51 -0400 (EDT)
Subject: [VoiceOps] ITFS Term vendor question
In-Reply-To: <CACw3o7j3pW8Ke3-6mgL2g1YhHMj7p7WTAEcka6wjgo-yQ-r8qQ@mail.gmail.com>
Message-ID: <23734767.2066.1410991191470.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Nick Crocker" <nick.crocker at gmail.com>

> Can someone shed some light on how you might be accomplishing this, I have
> a hard time believing that customers are being told they cannot dial TF
> numbers in their own country.

In the US, it's always been my understanding that what we call INWATS calls
are dipped *at the originating CO*, and the actual toll call across the
SS7/TDM backbone goes out using either the real 10D DN of the target line,
or some fake 10D that routes to the appropriate trunk group somehow at the
destination end.

So it's not that unusual to me that a network that is interfacing at 
Class 4, instead of Class 5, might be unable to originate calls to TF DNs.

I admit to not being sure this is a worldwide view of the issue, as our
Wikipedian friends would say, though.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Wed Sep 17 22:01:59 2014
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 17 Sep 2014 18:01:59 -0400 (EDT)
Subject: Bare TLD resolutions
In-Reply-To: <541A0253.7020608@dougbarton.us>
Message-ID: <15346258.2068.1410991319508.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Doug Barton" <dougb at dougbarton.us>

> > I want to return NXDOMAIN *because there is no record of that type
> > at that node*.
> >
> > That was the underlying point here; I thought that was pretty clear.
> 
> But that's not what NXDOMAIN means. :) You get an NXDOMAIN response
> when there is no label at that point in the tree, period. In the case
> you specify you get the combination of NOANSWER + NOERROR if there is no
> address record, but there are other records (like there are at a zone
> apex).

D'oh.  Yes; I overspecified.  Damn.

> hth,

It did; thanks. 

Well, except for John, but he thinks I'm an idiot dilettante anyway.  :-)

Cheers,
-- jra 
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From fred at cisco.com  Wed Sep 17 22:04:07 2014
From: fred at cisco.com (Fred Baker (fred))
Date: Wed, 17 Sep 2014 22:04:07 +0000
Subject: Bare TLD resolutions
In-Reply-To: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
References: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
Message-ID: <0EF9B30B-EFEB-40AD-A36A-E50CC9987539@cisco.com>

IMHO, since ICANN has created the situation, the ball is in ICANN?s court to say how this works without disrupting name services. Their ill-informed hipshot is not our emergency.

On Sep 17, 2014, at 9:09 AM, Jay Ashworth <jra at baylink.com> wrote:

> Pursuant to
> 
>  https://www.icann.org/resources/pages/name-collision-2013-12-06-en)
> 
> mentioned in the Scotland thread... it seems there are two major potential
> points of possible collision:
> 
> 1) User network uses "fake" TLD which is no longer fake, and local 
> resolver server blows it
> 
> 2) User network blows it worse, and tries to resolve a monocomponent name
> off non-local servers.
> 
> The latter would seem to be avoidable by making sure that *DNS resolution
> of bare TLDs always returns NXDOMAIN*.
> 
> Is that a requirement for a TLD?
> 
> If it isn't, does anyone know of any domains dumb enough to actual 
> return something for a lookup on the bare TLD?
> 
> Is there actually *any* good reason why a lookup on a bare TLD ("com.")
> might return a valid record?
> 
> And what about Naomi?
> 
> Cheers,
> -- jra
> 
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/0c1bab91/attachment.sig>

From marka at isc.org  Wed Sep 17 22:05:05 2014
From: marka at isc.org (Mark Andrews)
Date: Thu, 18 Sep 2014 08:05:05 +1000
Subject: Bare TLD resolutions
In-Reply-To: Your message of "Wed, 17 Sep 2014 17:51:13 -0400."
 <21906507.2046.1410990673107.JavaMail.root@benjamin.baylink.com>
References: <21906507.2046.1410990673107.JavaMail.root@benjamin.baylink.com>
Message-ID: <20140917220505.B7FFC1FADF01@rock.dv.isc.org>


In message <21906507.2046.1410990673107.JavaMail.root at benjamin.baylink.com>, Ja
y Ashworth writes:
> ----- Original Message -----
> > From: "Mark Andrews" <marka at isc.org>
> 
> > Search lists are for hosts and host like things. Resolver libraries
> > have different interfaces for different purposes. Single label
> > hostnames for reaching non local equipment was deliberately phase
> > out in the 1980's as it was clearly a bad concept.
> 
> Yes, and we're discussing the practical reason *why* it's a bad concept. 
> 
> :-)
> 
> My abject apologies to everyone who didn't get that I was talking about
> the *source* of the problem by synecdoche.

The source of the problem is bad search list handling.  It wouldn't matter
what records are there if the search list handling was correct.

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


From drc at virtualized.org  Wed Sep 17 22:31:50 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 17 Sep 2014 15:31:50 -0700
Subject: Bare TLD resolutions
In-Reply-To: <0EF9B30B-EFEB-40AD-A36A-E50CC9987539@cisco.com>
References: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
 <0EF9B30B-EFEB-40AD-A36A-E50CC9987539@cisco.com>
Message-ID: <413C873A-D0E1-4AD9-B742-843DEA6D598F@virtualized.org>

Fred,

On Sep 17, 2014, at 3:04 PM, Fred Baker (fred) <fred at cisco.com> wrote:
> IMHO, since ICANN has created the situation, 

ICANN has created ill-specified domain search path heuristics and truly fascinating implementations of those heuristics?  ICANN has caused people to use non-allocated TLDs in environments where queries for those non-allocated TLDs hit the public Internet?  ICANN had made applications dependent upon receiving NXDOMAINs in a way that implies the root of the DNS should never be expanded (even for country codes or internationalized domain names)?

> the ball is in ICANN?s court to say how this works without disrupting name services.

Actually, name services aren?t disrupted. They are behaving exactly as specified in the DNS and as intended.  What is disrupted is (typically unknown) assumptions people have made regarding the composition of the top-level of the domain namespace. ICANN has been working to try to help mitigate the issue for some time now (initial discussions occurred in 2010).

> Their ill-informed hipshot is not our emergency.

Hipshots are generally not a good idea, regardless of whether they are ill-informed. 

Whose emergency it is probably depends on how the delegation of new top-level domains impacts the operation of your network. To date, in cases where there was impact, the affected parties have worked to address the issues and (AFAIK) no emergencies have been experienced.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/2f30def1/attachment.sig>

From mohta at necom830.hpcl.titech.ac.jp  Wed Sep 17 23:35:40 2014
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 18 Sep 2014 08:35:40 +0900
Subject: Bare TLD resolutions
In-Reply-To: <41935.1410990974@turing-police.cc.vt.edu>
References: <4331947.2044.1410990538588.JavaMail.root@benjamin.baylink.com>
 <41935.1410990974@turing-police.cc.vt.edu>
Message-ID: <541A1ACC.1030309@necom830.hpcl.titech.ac.jp>

Doug Barton wrote:

> In the case
> you specify you get the combination of NOANSWER + NOERROR
> if there is no address record, but there are other records
> (like there are at a zone apex).

Valdis.Kletnieks at vt.edu wrote:

> NXDOMAIN means "There are no records of *any* type at that node".

Not.

Though your misunderstanding is common, NXDOMAIN means "no
such node exist", while some node may exist without having any
data, as is specified in rfc1034:

	Each node and leaf on the
	tree corresponds to a resource set (which may be empty).

						Masataka Ohta



From asullivan at dyn.com  Thu Sep 18 00:22:22 2014
From: asullivan at dyn.com (Andrew Sullivan)
Date: Wed, 17 Sep 2014 20:22:22 -0400
Subject: Bare TLD resolutions
In-Reply-To: <20140917213908.9A26B1FADC1F@rock.dv.isc.org>
References: <20140917204640.37641.qmail@joyce.lan>
 <19973779.2038.1410987472068.JavaMail.root@benjamin.baylink.com>
 <20140917211336.GT89960@dyn.com>
 <20140917213908.9A26B1FADC1F@rock.dv.isc.org>
Message-ID: <20140918002221.GX89960@dyn.com>

On Thu, Sep 18, 2014 at 07:39:08AM +1000, Mark Andrews wrote:

> You want gethostbyname, getaddrinfo to return HOST_NOT_FOUND/EAI_NONAME

I was unaware that getaddrinfo returned "NXDOMAIN", which is what I
read in the thread being talked about.  Not return values from the OS
calls.  I guess I missed that message.

> You want res_search() to return  HOST_NOT_FOUND if a single label
> is entered and is not matched by <label>.<search-list-element>.
> 
> You want res_query() and other tools that look in the DNS and are
> *not* searching to return whatever is in the DNS.

These are not even remotely the same thing as what was being proposed,
which is all I was commenting on.

A

-- 
Andrew Sullivan
Dyn, Inc.
asullivan at dyn.com
v: +1 603 663 0448


From mpalmer at hezmatt.org  Thu Sep 18 00:43:03 2014
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Thu, 18 Sep 2014 10:43:03 +1000
Subject: Scotland ccTLD?
In-Reply-To: <CACg3zYEHwudTfoPGHRS+9eJWLV++kSOAnFBypa9LLy8cZps8vw@mail.gmail.com>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
 <5418E0B8.2060501@cox.net>
 <CACg3zYEHwudTfoPGHRS+9eJWLV++kSOAnFBypa9LLy8cZps8vw@mail.gmail.com>
Message-ID: <20140918004303.GW25667@hezmatt.org>

On Wed, Sep 17, 2014 at 10:02:45AM +0200, Tei wrote:
> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table
> 
> GO [...] seems to be free :D

1600 Amphitheatre Parkway... the newest independent state.

- Matt



From mysidia at gmail.com  Thu Sep 18 01:01:34 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 17 Sep 2014 20:01:34 -0500
Subject: Bare TLD resolutions
In-Reply-To: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
References: <16339722.1990.1410969884627.JavaMail.root@benjamin.baylink.com>
 <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAAAwwbWwHDGhLocOm47gRq3Md3=SNs667jmobXwz6wz1wk0XZQ@mail.gmail.com>

On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth <jra at baylink.com> wrote:

> The latter would seem to be avoidable by making sure that *DNS resolution
> of bare TLDs always returns NXDOMAIN*.
[snip]

Not  NXDOMAIN.    When  TLD.  is looked up,  they should always return NOERROR.

And yield, either   (1)  the NS records for the TLD,  for QTYPE NS or 'ANY'

For other queries   TLD.  should return NOERROR  with  Zero RRs in the
answer   (Empty response).


A NXDOMAIN response would be declaring that the TLD does not exist.


--
-JH


From owen at delong.com  Thu Sep 18 01:20:11 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 17 Sep 2014 18:20:11 -0700
Subject: Bare TLD resolutions
In-Reply-To: <CAAAwwbWwHDGhLocOm47gRq3Md3=SNs667jmobXwz6wz1wk0XZQ@mail.gmail.com>
References: <16339722.1990.1410969884627.JavaMail.root@benjamin.baylink.com>
 <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
 <CAAAwwbWwHDGhLocOm47gRq3Md3=SNs667jmobXwz6wz1wk0XZQ@mail.gmail.com>
Message-ID: <1761B485-D796-49AE-B081-6E24526A2A1B@delong.com>


On Sep 17, 2014, at 6:01 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth <jra at baylink.com> wrote:
> 
>> The latter would seem to be avoidable by making sure that *DNS resolution
>> of bare TLDs always returns NXDOMAIN*.
> [snip]
> 
> Not  NXDOMAIN.    When  TLD.  is looked up,  they should always return NOERROR.

Well? A TLD which does not exist should return NXDOMAIN. For example, if I do a query for .NONEXISTANTTLD.,
then I should get NXDOMAIN?

Owens-MacBook-Pro:Downloads owendelong$ dig NONEXISTANTTLD.

; <<>> DiG 9.8.3-P1 <<>> NONEXISTANTTLD.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64254
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;NONEXISTANTTLD.			IN	A

;; AUTHORITY SECTION:
.			3600	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2014091701 1800 900 604800 86400

But for any TLD which exists, yes.

Owen



From joesox at gmail.com  Thu Sep 18 02:04:13 2014
From: joesox at gmail.com (JoeSox)
Date: Wed, 17 Sep 2014 19:04:13 -0700
Subject: Here comes iOS 8...
In-Reply-To: <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
Message-ID: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>

Grant,
Do you have a reference? Someone just told me it is more around 5GB.

--
Later, Joe

On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
wrote:

> For those that are curious, it looks like the download is 1.1 gigs.
>
> -Grant
>
> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>
> > I've been waiting all morning.
> >
> >  Expedited repair of a primary link to prepare for the traffic. Not that
> it
> > didn't have multiple backups. But one doesn't trifle with IOS8 release
> > traffic.. If it's anything like IOS7 was..
> >
> >  Nick Olsen
> > Network Operations  (855) FLSPEED  x106
> >
> >
> > ----------------------------------------
> >  From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
> > Sent: Wednesday, September 17, 2014 12:59 PM
> > To: "NANOG" <nanog at nanog.org>
> > Subject: Here comes iOS 8...
> > So Apple is about to release iOS 8... Have you done anything special to
> > your network setup to accommodate the traffic flood ie traffic shaping
> > rules, cache servers, etc?
> >
> > I heard that Apple Caching servers won't work with this update, so I'm
> > guessing it will be pushed through Akamai servers as is usually is.
> >
> > - Zachary
> >
> >
> >
>


From contact at winterei.se  Thu Sep 18 02:07:56 2014
From: contact at winterei.se (Paul S.)
Date: Thu, 18 Sep 2014 11:07:56 +0900
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <541A3E7C.5000808@winterei.se>

Later,

I think it requires 5.7G of free space on the device -- but the download 
is not that big.

On 9/18/2014 ?? 11:04, JoeSox wrote:
> Grant,
> Do you have a reference? Someone just told me it is more around 5GB.
>
> --
> Later, Joe
>
> On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
> wrote:
>
>> For those that are curious, it looks like the download is 1.1 gigs.
>>
>> -Grant
>>
>> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>>
>>> I've been waiting all morning.
>>>
>>>   Expedited repair of a primary link to prepare for the traffic. Not that
>> it
>>> didn't have multiple backups. But one doesn't trifle with IOS8 release
>>> traffic.. If it's anything like IOS7 was..
>>>
>>>   Nick Olsen
>>> Network Operations  (855) FLSPEED  x106
>>>
>>>
>>> ----------------------------------------
>>>   From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>> To: "NANOG" <nanog at nanog.org>
>>> Subject: Here comes iOS 8...
>>> So Apple is about to release iOS 8... Have you done anything special to
>>> your network setup to accommodate the traffic flood ie traffic shaping
>>> rules, cache servers, etc?
>>>
>>> I heard that Apple Caching servers won't work with this update, so I'm
>>> guessing it will be pushed through Akamai servers as is usually is.
>>>
>>> - Zachary
>>>
>>>
>>>



From bdha at mirrorshades.net  Thu Sep 18 02:08:58 2014
From: bdha at mirrorshades.net (Bryan Horstmann-Allen)
Date: Wed, 17 Sep 2014 22:08:58 -0400
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <20140918020858.GI83821@lab.int.icgroup.com>

+------------------------------------------------------------------------------
| On 2014-09-17 19:04:13, JoeSox wrote:
| 
| Do you have a reference? Someone just told me it is more around 5GB.

The download is 1.1GB. 5.6GB is required for the actual upgrade.
-- 
bdha


From alexander at neilson.net.nz  Thu Sep 18 02:09:39 2014
From: alexander at neilson.net.nz (Alexander Neilson)
Date: Thu, 18 Sep 2014 14:09:39 +1200
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <66B58FFB-FDE0-4E20-9953-70F1E46B091C@neilson.net.nz>

According to devices I have seen numbers have been between 800MB and 1.3GB

iPhone 4S, iPhone 5, iPad 2 (3G), iPad Air (LTE)

Regards
Alexander

Alexander Neilson
Neilson Productions Limited

alexander at neilson.net.nz
021 329 681
022 456 2326

On 18/09/2014, at 2:04 pm, JoeSox <joesox at gmail.com> wrote:

> Grant,
> Do you have a reference? Someone just told me it is more around 5GB.
> 
> --
> Later, Joe
> 
> On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
> wrote:
> 
>> For those that are curious, it looks like the download is 1.1 gigs.
>> 
>> -Grant
>> 
>> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>> 
>>> I've been waiting all morning.
>>> 
>>> Expedited repair of a primary link to prepare for the traffic. Not that
>> it
>>> didn't have multiple backups. But one doesn't trifle with IOS8 release
>>> traffic.. If it's anything like IOS7 was..
>>> 
>>> Nick Olsen
>>> Network Operations  (855) FLSPEED  x106
>>> 
>>> 
>>> ----------------------------------------
>>> From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>> To: "NANOG" <nanog at nanog.org>
>>> Subject: Here comes iOS 8...
>>> So Apple is about to release iOS 8... Have you done anything special to
>>> your network setup to accommodate the traffic flood ie traffic shaping
>>> rules, cache servers, etc?
>>> 
>>> I heard that Apple Caching servers won't work with this update, so I'm
>>> guessing it will be pushed through Akamai servers as is usually is.
>>> 
>>> - Zachary
>>> 
>>> 
>>> 
>> 



From joesox at gmail.com  Thu Sep 18 02:10:28 2014
From: joesox at gmail.com (JoeSox)
Date: Wed, 17 Sep 2014 19:10:28 -0700
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <CAAXNyuA0dpdswk1aQYSsjPaNuDn6iDvX6MkCAT00KuAakj=HCw@mail.gmail.com>

Someone just told me its 5GB free space needed. That makes sense where
someone could have read it wrong. Thanks.
5GB for for iphone seemed a bit odd.
--
Later, Joe

On Wed, Sep 17, 2014 at 7:04 PM, JoeSox <joesox at gmail.com> wrote:

> Grant,
> Do you have a reference? Someone just told me it is more around 5GB.
>
> --
> Later, Joe
>
> On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
> wrote:
>
>> For those that are curious, it looks like the download is 1.1 gigs.
>>
>> -Grant
>>
>> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>>
>> > I've been waiting all morning.
>> >
>> >  Expedited repair of a primary link to prepare for the traffic. Not
>> that it
>> > didn't have multiple backups. But one doesn't trifle with IOS8 release
>> > traffic.. If it's anything like IOS7 was..
>> >
>> >  Nick Olsen
>> > Network Operations  (855) FLSPEED  x106
>> >
>> >
>> > ----------------------------------------
>> >  From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>> > Sent: Wednesday, September 17, 2014 12:59 PM
>> > To: "NANOG" <nanog at nanog.org>
>> > Subject: Here comes iOS 8...
>> > So Apple is about to release iOS 8... Have you done anything special to
>> > your network setup to accommodate the traffic flood ie traffic shaping
>> > rules, cache servers, etc?
>> >
>> > I heard that Apple Caching servers won't work with this update, so I'm
>> > guessing it will be pushed through Akamai servers as is usually is.
>> >
>> > - Zachary
>> >
>> >
>> >
>>
>
>


From woody at pch.net  Thu Sep 18 03:37:56 2014
From: woody at pch.net (Bill Woodcock)
Date: Wed, 17 Sep 2014 20:37:56 -0700
Subject: Here comes iOS 8...
In-Reply-To: <66B58FFB-FDE0-4E20-9953-70F1E46B091C@neilson.net.nz>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
 <66B58FFB-FDE0-4E20-9953-70F1E46B091C@neilson.net.nz>
Message-ID: <76F1EC04-330E-48BC-AE4A-FBBAF8A25723@pch.net>


Slight differences depending on platform. For my 5S, the OTA patch is 1.1GB, and the clean install is 2.05GB. Both compressed, of course. 

    
                -Bill


> On Sep 17, 2014, at 19:15, "Alexander Neilson" <alexander at neilson.net.nz> wrote:
> 
> According to devices I have seen numbers have been between 800MB and 1.3GB
> 
> iPhone 4S, iPhone 5, iPad 2 (3G), iPad Air (LTE)
> 
> Regards
> Alexander
> 
> Alexander Neilson
> Neilson Productions Limited
> 
> alexander at neilson.net.nz
> 021 329 681
> 022 456 2326
> 
>> On 18/09/2014, at 2:04 pm, JoeSox <joesox at gmail.com> wrote:
>> 
>> Grant,
>> Do you have a reference? Someone just told me it is more around 5GB.
>> 
>> --
>> Later, Joe
>> 
>> On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
>> wrote:
>> 
>>> For those that are curious, it looks like the download is 1.1 gigs.
>>> 
>>> -Grant
>>> 
>>>> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>>>> 
>>>> I've been waiting all morning.
>>>> 
>>>> Expedited repair of a primary link to prepare for the traffic. Not that
>>> it
>>>> didn't have multiple backups. But one doesn't trifle with IOS8 release
>>>> traffic.. If it's anything like IOS7 was..
>>>> 
>>>> Nick Olsen
>>>> Network Operations  (855) FLSPEED  x106
>>>> 
>>>> 
>>>> ----------------------------------------
>>>> From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>>> To: "NANOG" <nanog at nanog.org>
>>>> Subject: Here comes iOS 8...
>>>> So Apple is about to release iOS 8... Have you done anything special to
>>>> your network setup to accommodate the traffic flood ie traffic shaping
>>>> rules, cache servers, etc?
>>>> 
>>>> I heard that Apple Caching servers won't work with this update, so I'm
>>>> guessing it will be pushed through Akamai servers as is usually is.
>>>> 
>>>> - Zachary
> 



From shortdudey123 at gmail.com  Thu Sep 18 05:24:21 2014
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 17 Sep 2014 22:24:21 -0700
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <C6204568-7EF5-417F-B44D-3CC0587F2216@gmail.com>

My reference was the update page in settings said the download was 1.1 gig

Grant

Sent from my iPhone

> On Sep 17, 2014, at 7:04 PM, JoeSox <joesox at gmail.com> wrote:
> 
> Grant,
> Do you have a reference? Someone just told me it is more around 5GB.
> 
> --
> Later, Joe
> 
> On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
> wrote:
> 
>> For those that are curious, it looks like the download is 1.1 gigs.
>> 
>> -Grant
>> 
>>> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>>> 
>>> I've been waiting all morning.
>>> 
>>> Expedited repair of a primary link to prepare for the traffic. Not that
>> it
>>> didn't have multiple backups. But one doesn't trifle with IOS8 release
>>> traffic.. If it's anything like IOS7 was..
>>> 
>>> Nick Olsen
>>> Network Operations  (855) FLSPEED  x106
>>> 
>>> 
>>> ----------------------------------------
>>> From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>> To: "NANOG" <nanog at nanog.org>
>>> Subject: Here comes iOS 8...
>>> So Apple is about to release iOS 8... Have you done anything special to
>>> your network setup to accommodate the traffic flood ie traffic shaping
>>> rules, cache servers, etc?
>>> 
>>> I heard that Apple Caching servers won't work with this update, so I'm
>>> guessing it will be pushed through Akamai servers as is usually is.
>>> 
>>> - Zachary
>> 


From johnl at iecc.com  Thu Sep 18 08:56:51 2014
From: johnl at iecc.com (John Levine)
Date: 18 Sep 2014 08:56:51 -0000
Subject: [VoiceOps] ITFS Term vendor question
In-Reply-To: <23734767.2066.1410991191470.JavaMail.root@benjamin.baylink.com>
Message-ID: <20140918085651.2551.qmail@joyce.lan>

In article <23734767.2066.1410991191470.JavaMail.root at benjamin.baylink.com> you write:
>---- Original Message -----
>> From: "Nick Crocker" <nick.crocker at gmail.com>
>
>> Can someone shed some light on how you might be accomplishing this, I have
>> a hard time believing that customers are being told they cannot dial TF
>> numbers in their own country.
>
>In the US, it's always been my understanding that what we call INWATS calls
>are dipped *at the originating CO*, and the actual toll call across the
>SS7/TDM backbone goes out using either the real 10D DN of the target line,
>or some fake 10D that routes to the appropriate trunk group somehow at the
>destination end.

I was under the impression that the dip returns the IXC that handles
the number, and the call goes out with the original number for the IXC
to handle.  The translation to POTS or whatever happens at the IXC's
SCP.  The SCP could reject the call if there's no route that matches
the condition on the incoming call.  ("The number you are calling is
not available from your area")

There's a lot of 8xx processing that routes based on time of day or
where the caller is or whichever call center is less busy.  That would
seem hard to do if the 8xx number were already translated.  The
originating CO often does the dip to get the 10D target for LNP, but
that's different.

Could someone who understands this better clarify?


From tlyons at ivenue.com  Thu Sep 18 09:19:42 2014
From: tlyons at ivenue.com (Todd Lyons)
Date: Thu, 18 Sep 2014 02:19:42 -0700
Subject: Outbound traffic from 208.89.136.0/22 going from L.A. to London?
Message-ID: <CAFG21ojkzG1iaf-+kH0BmzOi_bfbG-20-q=n4FUEsE8LVFttfw@mail.gmail.com>

I'm seeing some weird routing outbound for *some* destinations.
Testing from 208.89.139.252.

google.com resolves for me to 74.125.239.112 and the outbound path is
fast and appears to stay in the US.

yahoo.com resolves for me to 98.138.253.109, but the outbound path
goes through Savvis London, then to BT, then to Yahoo.

# mtr 98.138.253.109 --report --report-cycles 10
HOST: mail.mrball.net             Loss%   Snt   Last   Avg  Best  Wrst StDev
...internal...
  5. gw.iv.ivenue.com              0.0%    10    2.7   2.7   2.6   2.8   0.1
  6. 64.70.17.121                  0.0%    10    2.8   3.8   2.8  11.5   2.7
  7. hr2-v3007.la1.savvis.net      0.0%    10    2.8  22.9   2.8 203.1  63.3
  8. 204.70.203.90                 0.0%    10    4.0   4.3   3.8   5.6   0.5
  9. cr1-pos-0-0-0-0.londonuk1.sa  0.0%    10  177.1 157.9 151.1 179.7  11.5
 10. esr1-xe-7-0-0.ams.savvis.net  0.0%    10  166.5 166.4 166.3 166.5   0.1
 11. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
 12. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
 13. ixp1-xe-11-0-0-0.us-ash.eu.b 80.0%    10  597.0 595.7 594.4 597.0   1.9
 14. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
 15. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
 16. ae-5.pat1.nez.yahoo.com      90.0%    10  546.0 546.0 546.0 546.0   0.0
 17. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0

# mtr 98.138.253.109 -n --report --report-cycles 15
HOST: mail.mrball.net             Loss%   Snt   Last   Avg  Best  Wrst StDev
...internal...
  5. 208.89.136.1                  0.0%    15    2.6   2.7   2.6   2.9   0.1
  6. 64.70.17.121                  0.0%    15    2.8   8.9   2.8  57.5  16.2
  7. 64.70.11.57                   0.0%    15    2.8   2.9   2.8   3.2   0.1
  8. 204.70.203.90                 0.0%    15    4.4   5.4   3.7  23.5   5.0
  9. 204.70.192.122                0.0%    15  151.2 154.7 151.1 172.9   7.0
 10. 204.70.202.2                  0.0%    15  166.4 168.8 166.3 202.7   9.4
 11. ???                          100.0    15    0.0   0.0   0.0   0.0   0.0
 12. 166.49.208.90                80.0%    15  508.3 507.2 505.9 508.3   1.2
 13. 166.49.208.59                80.0%    15  589.8 589.8 588.9 590.6   0.9
 14. ???                          100.0    15    0.0   0.0   0.0   0.0   0.0
 15. 216.115.96.81                93.3%    15  521.8 521.8 521.8 521.8   0.0
 16. ???                          100.0    15    0.0   0.0   0.0   0.0   0.0
 17. 216.115.100.3                93.3%    15  537.4 537.4 537.4 537.4   0.0
 18. 98.138.144.29                91.7%    12  537.1 537.1 537.1 537.1   0.0
 19. ???                          100.0     5    0.0   0.0   0.0   0.0   0.0
 20. 98.138.240.28                80.0%     5  537.9 537.9 537.9 537.9   0.0
 21. ???                          100.0     4    0.0   0.0   0.0   0.0   0.0
 22. 98.138.253.109               66.7%     3  537.9 537.9 537.9 537.9   0.0

Traffic served by Akamai appears to be fast and stays local (i.e.
tested to www.apple.com).

A call in to Savvis got attached to master ticket 4828052, which is
for "large packet loss".  Describes the symptom, not the cause.

Is there anybody who has more info?  Anybody who's a Savvis customer
who sees the same weird outbound routing?  Or are we the only ones?
Feel free to traceroute to 208.89.139.252 to try and duplicate these
results.

...Todd

-- 
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine


From sander at steffann.nl  Thu Sep 18 10:34:31 2014
From: sander at steffann.nl (Sander Steffann)
Date: Thu, 18 Sep 2014 12:34:31 +0200
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <082677CC-3C09-49CE-88DF-4BF25CB477A1@steffann.nl>

Hi,

> Do you have a reference? Someone just told me it is more around 5GB.

It seems to depend on the device. IIRC my iPhone 4S downloaded ?0.9GB and my iPad Mini ?1.3GB. That might be because the 4S is still a 32-bit device.

Cheers,
Sander



From tlyons at ivenue.com  Thu Sep 18 11:39:43 2014
From: tlyons at ivenue.com (Todd Lyons)
Date: Thu, 18 Sep 2014 04:39:43 -0700
Subject: Outbound traffic from 208.89.136.0/22 going from L.A. to London?
In-Reply-To: <OF4BEED7D7.CE088E9F-ON85257D57.00340404-85257D57.003431C4@portware.com>
References: <CAFG21ojkzG1iaf-+kH0BmzOi_bfbG-20-q=n4FUEsE8LVFttfw@mail.gmail.com>
 <OF4BEED7D7.CE088E9F-ON85257D57.00340404-85257D57.003431C4@portware.com>
Message-ID: <CAFG21ogq3JLJRe66CcA+gax9GdXaV4ZH8DarXg5o=aqepnQKdQ@mail.gmail.com>

The issue was seemingly fixed about 30 minutes ago, and has been
confirmed to be fixed by multiple parties.  Many thanks for the
response Vincent.  Have a fantastic day!

...Todd


On Thu, Sep 18, 2014 at 2:30 AM, Vincent Aniello <VAniello at portware.com> wrote:
> We are seeing issues on our Savvis Internet connections in New York to users
> in London and Sweden.  Not many details yet, just seeing slow and sporadic
> connectivity.
>
> --Vincent
>
>
>
> From:        Todd Lyons <tlyons at ivenue.com>
> To:        NANOG list <nanog at nanog.org>
> Date:        09/18/2014 05:21 AM
> Subject:        Outbound traffic from 208.89.136.0/22 going from L.A. to
> London?
> Sent by:        "NANOG" <nanog-bounces at nanog.org>
> ________________________________
>
>
>
> I'm seeing some weird routing outbound for *some* destinations.
> Testing from 208.89.139.252.
>
> google.com resolves for me to 74.125.239.112 and the outbound path is
> fast and appears to stay in the US.
>
> yahoo.com resolves for me to 98.138.253.109, but the outbound path
> goes through Savvis London, then to BT, then to Yahoo.
>
> # mtr 98.138.253.109 --report --report-cycles 10
> HOST: mail.mrball.net             Loss%   Snt   Last   Avg  Best  Wrst StDev
> ...internal...
>  5. gw.iv.ivenue.com              0.0%    10    2.7   2.7   2.6   2.8   0.1
>  6. 64.70.17.121                  0.0%    10    2.8   3.8   2.8  11.5   2.7
>  7. hr2-v3007.la1.savvis.net      0.0%    10    2.8  22.9   2.8 203.1  63.3
>  8. 204.70.203.90                 0.0%    10    4.0   4.3   3.8   5.6   0.5
>  9. cr1-pos-0-0-0-0.londonuk1.sa  0.0%    10  177.1 157.9 151.1 179.7  11.5
> 10. esr1-xe-7-0-0.ams.savvis.net  0.0%    10  166.5 166.4 166.3 166.5   0.1
> 11. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
> 12. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
> 13. ixp1-xe-11-0-0-0.us-ash.eu.b 80.0%    10  597.0 595.7 594.4 597.0   1.9
> 14. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
> 15. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
> 16. ae-5.pat1.nez.yahoo.com      90.0%    10  546.0 546.0 546.0 546.0   0.0
> 17. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
>
> # mtr 98.138.253.109 -n --report --report-cycles 15
> HOST: mail.mrball.net             Loss%   Snt   Last   Avg  Best  Wrst StDev
> ...internal...
>  5. 208.89.136.1                  0.0%    15    2.6   2.7   2.6   2.9   0.1
>  6. 64.70.17.121                  0.0%    15    2.8   8.9   2.8  57.5  16.2
>  7. 64.70.11.57                   0.0%    15    2.8   2.9   2.8   3.2   0.1
>  8. 204.70.203.90                 0.0%    15    4.4   5.4   3.7  23.5   5.0
>  9. 204.70.192.122                0.0%    15  151.2 154.7 151.1 172.9   7.0
> 10. 204.70.202.2                  0.0%    15  166.4 168.8 166.3 202.7   9.4
> 11. ???                          100.0    15    0.0   0.0   0.0   0.0   0.0
> 12. 166.49.208.90                80.0%    15  508.3 507.2 505.9 508.3   1.2
> 13. 166.49.208.59                80.0%    15  589.8 589.8 588.9 590.6   0.9
> 14. ???                          100.0    15    0.0   0.0   0.0   0.0   0.0
> 15. 216.115.96.81                93.3%    15  521.8 521.8 521.8 521.8   0.0
> 16. ???                          100.0    15    0.0   0.0   0.0   0.0   0.0
> 17. 216.115.100.3                93.3%    15  537.4 537.4 537.4 537.4   0.0
> 18. 98.138.144.29                91.7%    12  537.1 537.1 537.1 537.1   0.0
> 19. ???                          100.0     5    0.0   0.0   0.0   0.0   0.0
> 20. 98.138.240.28                80.0%     5  537.9 537.9 537.9 537.9   0.0
> 21. ???                          100.0     4    0.0   0.0   0.0   0.0   0.0
> 22. 98.138.253.109               66.7%     3  537.9 537.9 537.9 537.9   0.0
>
> Traffic served by Akamai appears to be fast and stays local (i.e.
> tested to www.apple.com).
>
> A call in to Savvis got attached to master ticket 4828052, which is
> for "large packet loss".  Describes the symptom, not the cause.
>
> Is there anybody who has more info?  Anybody who's a Savvis customer
> who sees the same weird outbound routing?  Or are we the only ones?
> Feel free to traceroute to 208.89.139.252 to try and duplicate these
> results.
>
> ...Todd
>
> --
> The total budget at all receivers for solving senders' problems is $0.
> If you want them to accept your mail and manage it the way you want,
> send it the way the spec says to. --John Levine
>



-- 
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine


From corbe at corbe.net  Thu Sep 18 17:53:52 2014
From: corbe at corbe.net (Daniel Corbe)
Date: Thu, 18 Sep 2014 13:53:52 -0400
Subject: upstream support for flowspec
Message-ID: <ygfbnqcbyrz.fsf@corbe.net>


I was perusing RFC5575 after reading a presentation that ALU did
(presumably during some previous NANOG conference).  Reference:
https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf

This seems like it would be a godsend for small operators like myself who don't have
access to unlimited bandwidth and are put off by off-site scrubbing
services.  

As far as I can tell though the only platforms that offer support are
the 7750-SR and platforms made by Juniper.

Is there anything in the air about widening the adoption base?  Cisco?
Brocade?  

And once that happens, what are the chances of services providers
adopting this for their customers to make use of on as wide of a scale
as (for example) blackhole community strings.

I'd certainly *love* to have a way to mitigate an attack that doesn't
involve me sacrificing one service on my network to save the rest.

Best,
Daniel


From jtk at cymru.com  Thu Sep 18 18:06:34 2014
From: jtk at cymru.com (John Kristoff)
Date: Thu, 18 Sep 2014 13:06:34 -0500
Subject: upstream support for flowspec
In-Reply-To: <ygfbnqcbyrz.fsf@corbe.net>
References: <ygfbnqcbyrz.fsf@corbe.net>
Message-ID: <20140918130634.55bf5853@localhost>

On Thu, 18 Sep 2014 13:53:52 -0400
Daniel Corbe <corbe at corbe.net> wrote:

> Is there anything in the air about widening the adoption base?  Cisco?
> Brocade?

I've seen some suggesting that increased support, but even at Juniper,
actions seem to speak larger than words.  There seems to be very little
interest for awhile now.  However, I do know of some providers who use
it, largely internal only.

We also have tried a community flow-spec service, and more recently
have been prototyping a community RTBH server with flow-spec capability
(ping me off list if you want to hear more or see me at NANOG 62).

A few people have recently told me they would like our community RTBH
service via flow-spec instead of just BGP next hop, but really only one
seemed seriously intent on configuring it day one.

John


From morrowc.lists at gmail.com  Thu Sep 18 18:12:15 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 18 Sep 2014 14:12:15 -0400
Subject: upstream support for flowspec
In-Reply-To: <ygfbnqcbyrz.fsf@corbe.net>
References: <ygfbnqcbyrz.fsf@corbe.net>
Message-ID: <CAL9jLabZFdaiecvSEm6pULq+VGX=pBodZu7O6UucHjWBt0MoqA@mail.gmail.com>

On Thu, Sep 18, 2014 at 1:53 PM, Daniel Corbe <corbe at corbe.net> wrote:
> And once that happens, what are the chances of services providers
> adopting this for their customers to make use of on as wide of a scale
> as (for example) blackhole community strings.
>
> I'd certainly *love* to have a way to mitigate an attack that doesn't
> involve me sacrificing one service on my network to save the rest.

there are providers (verizon business, att, sprint, ntt at least) that
provide mitigation via bgp update... which is equivalent to the
blackhole community stuff, why not investigate those options? (or if
you had, what was lacking?)


From youssef at 720.fr  Thu Sep 18 18:32:29 2014
From: youssef at 720.fr (Youssef Bengelloun-Zahr)
Date: Thu, 18 Sep 2014 20:32:29 +0200
Subject: upstream support for flowspec
In-Reply-To: <ygfbnqcbyrz.fsf@corbe.net>
References: <ygfbnqcbyrz.fsf@corbe.net>
Message-ID: <B118D743-7287-40BA-AFCF-E930831EAAB1@720.fr>



Envoy? de mon iPhone

> Le 18 sept. 2014 ? 19:53, Daniel Corbe <corbe at corbe.net> a ?crit :
> 
> 
> I was perusing RFC5575 after reading a presentation that ALU did
> (presumably during some previous NANOG conference).  Reference:
> https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf
> 
> This seems like it would be a godsend for small operators like myself who don't have
> access to unlimited bandwidth and are put off by off-site scrubbing
> services.  
> 
> As far as I can tell though the only platforms that offer support are
> the 7750-SR and platforms made by Juniper.
> 
> Is there anything in the air about widening the adoption base?  Cisco?
> Brocade?

Hi,

I've submitted a request through my Brocade SE to support this, but it seems they are not interested about it.

They claim their strategy is to achieve the same using SDN capabilities via OPENFLOW support.

In the mean time, we are sitting ducks with our traditional technics.

I read in an old NANOG thread (IIRC) that cisco was about to support this really soon on IOS-XR, but I am not 100% sur.

Best regards.

> 
> And once that happens, what are the chances of services providers
> adopting this for their customers to make use of on as wide of a scale
> as (for example) blackhole community strings.
> 
> I'd certainly *love* to have a way to mitigate an attack that doesn't
> involve me sacrificing one service on my network to save the rest.
> 
> Best,
> Daniel


From saku at ytti.fi  Thu Sep 18 18:39:29 2014
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 18 Sep 2014 21:39:29 +0300
Subject: upstream support for flowspec
In-Reply-To: <ygfbnqcbyrz.fsf@corbe.net>
References: <ygfbnqcbyrz.fsf@corbe.net>
Message-ID: <20140918183929.GA23558@pob.ytti.fi>

On (2014-09-18 13:53 -0400), Daniel Corbe wrote:

Hi Daniel,

> This seems like it would be a godsend for small operators like myself who don't have
> access to unlimited bandwidth and are put off by off-site scrubbing
> services.  
> 
> As far as I can tell though the only platforms that offer support are
> the 7750-SR and platforms made by Juniper.

Cisco IOS-XR supports flowspec today as well.

How much more would you pay per Mbps/month to have operator offer flowspec?
IP transit is quite low margin product, supporting flowspec may have some
adverse effects to business case:

a) you're paying less, as you're not receiving the traffic
b) operator may get more traffic, as attack does not yield desired outcome

And when we look at the feature technically

a) junos does not allow setting flowspec on in FW filters and then apply FW
filter where you wish to do it, it's automatically turned on for all traffic
transiting box. This may be undesirable.

b) by default junos accepts all flowspec actions, such as diverting traffic to
new IP or new VRF. This may cause undesirable security issues.

c) added feature == added complexity == reduced availability

-- 
  ++ytti


From corbe at corbe.net  Thu Sep 18 19:12:29 2014
From: corbe at corbe.net (Daniel Corbe)
Date: Thu, 18 Sep 2014 15:12:29 -0400
Subject: upstream support for flowspec
In-Reply-To: <20140918183929.GA23558@pob.ytti.fi> (Saku Ytti's message of
 "Thu, 18 Sep 2014 21:39:29 +0300")
References: <ygfbnqcbyrz.fsf@corbe.net> <20140918183929.GA23558@pob.ytti.fi>
Message-ID: <ygf7g10bv4y.fsf@corbe.net>


Saku Ytti <saku at ytti.fi> writes:

> On (2014-09-18 13:53 -0400), Daniel Corbe wrote:
>
> Hi Daniel,
>
>> This seems like it would be a godsend for small operators like
>> myself who don't have
>> access to unlimited bandwidth and are put off by off-site scrubbing
>> services.  
>> 
>> As far as I can tell though the only platforms that offer support are
>> the 7750-SR and platforms made by Juniper.
>
> Cisco IOS-XR supports flowspec today as well.
>
> How much more would you pay per Mbps/month to have operator offer flowspec?
> IP transit is quite low margin product, supporting flowspec may have some
> adverse effects to business case:
>
> a) you're paying less, as you're not receiving the traffic

This ventures into the realm of an operator doing something responsible
to protect me vs routing me unwanted traffic and going "lol, bill."

If you want to start playing that game, I'm happy to pay more per mbit
of traffic if you're happy to guarantee me that you won't route me
traffic that I'm expressly uninterested in.

> b) operator may get more traffic, as attack does not yield desired
> outcome

Not necessarily true.  If I can identify and push malicious traffic
towards your edge, then you can do the same towards your peers. 

If I can ask you to filter by source, can you turn around and do so by
source *AND* destination?  You know what I'm announcing, so it seems
like this ought to be possible.  Short of that, it would require us to
be in a trust relationship and I can see how that would be problematic.

If we circle back around to paying a premium for the service, then I'm
going to expect you to absorb the attack on my behalf.


>
> And when we look at the feature technically
>
> a) junos does not allow setting flowspec on in FW filters and then apply FW
> filter where you wish to do it, it's automatically turned on for all traffic
> transiting box. This may be undesirable.
>
> b) by default junos accepts all flowspec actions, such as diverting traffic to
> new IP or new VRF. This may cause undesirable security issues.
>
> c) added feature == added complexity == reduced availability

-Daniel


From corbe at corbe.net  Thu Sep 18 19:15:41 2014
From: corbe at corbe.net (Daniel Corbe)
Date: Thu, 18 Sep 2014 15:15:41 -0400
Subject: upstream support for flowspec
In-Reply-To: <ygf7g10bv4y.fsf@corbe.net> (Daniel Corbe's message of "Thu, 18
 Sep 2014 15:12:29 -0400")
References: <ygfbnqcbyrz.fsf@corbe.net> <20140918183929.GA23558@pob.ytti.fi>
 <ygf7g10bv4y.fsf@corbe.net>
Message-ID: <ygf38bobuzm.fsf@corbe.net>


Also, if I'm buying full line rate commit from you then you're not
actually losing any money on the deal whether or not you route me the
traffic.

-Daniel

Daniel Corbe <corbe at corbe.net> writes:

> Saku Ytti <saku at ytti.fi> writes:
>
>> On (2014-09-18 13:53 -0400), Daniel Corbe wrote:
>>
>> Hi Daniel,
>>
>>> This seems like it would be a godsend for small operators like
>>> myself who don't have
>>> access to unlimited bandwidth and are put off by off-site scrubbing
>>> services.  
>>> 
>>> As far as I can tell though the only platforms that offer support are
>>> the 7750-SR and platforms made by Juniper.
>>
>> Cisco IOS-XR supports flowspec today as well.
>>
>> How much more would you pay per Mbps/month to have operator offer flowspec?
>> IP transit is quite low margin product, supporting flowspec may have some
>> adverse effects to business case:
>>
>> a) you're paying less, as you're not receiving the traffic
>
> This ventures into the realm of an operator doing something responsible
> to protect me vs routing me unwanted traffic and going "lol, bill."
>
> If you want to start playing that game, I'm happy to pay more per mbit
> of traffic if you're happy to guarantee me that you won't route me
> traffic that I'm expressly uninterested in.
>
>> b) operator may get more traffic, as attack does not yield desired
>> outcome
>
> Not necessarily true.  If I can identify and push malicious traffic
> towards your edge, then you can do the same towards your peers. 
>
> If I can ask you to filter by source, can you turn around and do so by
> source *AND* destination?  You know what I'm announcing, so it seems
> like this ought to be possible.  Short of that, it would require us to
> be in a trust relationship and I can see how that would be problematic.
>
> If we circle back around to paying a premium for the service, then I'm
> going to expect you to absorb the attack on my behalf.
>
>
>>
>> And when we look at the feature technically
>>
>> a) junos does not allow setting flowspec on in FW filters and then apply FW
>> filter where you wish to do it, it's automatically turned on for all traffic
>> transiting box. This may be undesirable.
>>
>> b) by default junos accepts all flowspec actions, such as diverting traffic to
>> new IP or new VRF. This may cause undesirable security issues.
>>
>> c) added feature == added complexity == reduced availability
>
> -Daniel


From job at instituut.net  Thu Sep 18 20:02:21 2014
From: job at instituut.net (Job Snijders)
Date: Thu, 18 Sep 2014 22:02:21 +0200
Subject: upstream support for flowspec
In-Reply-To: <ygf38bobuzm.fsf@corbe.net>
References: <ygfbnqcbyrz.fsf@corbe.net> <20140918183929.GA23558@pob.ytti.fi>
 <ygf7g10bv4y.fsf@corbe.net> <ygf38bobuzm.fsf@corbe.net>
Message-ID: <20140918200221.GB96444@Vurt.local>

On Thu, Sep 18, 2014 at 03:15:41PM -0400, Daniel Corbe wrote:
> Also, if I'm buying full line rate commit from you then you're not
> actually losing any money on the deal whether or not you route me the
> traffic.

Ha, I wish all customers would buy in full line rate commits! :-)

- Job


From job at instituut.net  Thu Sep 18 20:19:25 2014
From: job at instituut.net (Job Snijders)
Date: Thu, 18 Sep 2014 22:19:25 +0200
Subject: upstream support for flowspec
In-Reply-To: <ygf7g10bv4y.fsf@corbe.net>
References: <ygfbnqcbyrz.fsf@corbe.net> <20140918183929.GA23558@pob.ytti.fi>
 <ygf7g10bv4y.fsf@corbe.net>
Message-ID: <20140918201925.GC96444@Vurt.local>

On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote:

> > a) you're paying less, as you're not receiving the traffic
> 
> This ventures into the realm of an operator doing something responsible
> to protect me vs routing me unwanted traffic and going "lol, bill."
> 
> If you want to start playing that game, I'm happy to pay more per mbit
> of traffic if you're happy to guarantee me that you won't route me
> traffic that I'm expressly uninterested in.

Would you be willing to pay for the traffic _not_ delivered to you
because of customer-pushed ACLs? If so, that would take the argument
away "because we filter we can't bill". Would you be willing to pay a
premium to be able to do so? Is it worth a premium to insert ACLs in
real time in the upstream's network or is a 2 hour delay acceptable?
what about 5 minute delay? 

Aside from practical issues with flowspec as Ytti mentioned already, I
don't think the market has yet figured out how stuff like this should
work and become cost-effective.

Kind regards,

Job


From joelja at bogus.com  Thu Sep 18 20:35:17 2014
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 18 Sep 2014 13:35:17 -0700
Subject: upstream support for flowspec
In-Reply-To: <20140918201925.GC96444@Vurt.local>
References: <ygfbnqcbyrz.fsf@corbe.net> <20140918183929.GA23558@pob.ytti.fi>
 <ygf7g10bv4y.fsf@corbe.net> <20140918201925.GC96444@Vurt.local>
Message-ID: <541B4205.8090501@bogus.com>

On 9/18/14 1:19 PM, Job Snijders wrote:
> On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote:
> 
>>> a) you're paying less, as you're not receiving the traffic
>>
>> This ventures into the realm of an operator doing something responsible
>> to protect me vs routing me unwanted traffic and going "lol, bill."
>>
>> If you want to start playing that game, I'm happy to pay more per mbit
>> of traffic if you're happy to guarantee me that you won't route me
>> traffic that I'm expressly uninterested in.
> 
> Would you be willing to pay for the traffic _not_ delivered to you
> because of customer-pushed ACLs? If so, that would take the argument
> away "because we filter we can't bill". Would you be willing to pay a
> premium to be able to do so? Is it worth a premium to insert ACLs in
> real time in the upstream's network or is a 2 hour delay acceptable?
> what about 5 minute delay? 

It's not really a question we have to ask. Managed firewall services
have way higher margins then pure IP transit. By extension dropping
packets can be substantially more profitable especially on a per packet
or byte basis then delivering them. Not everyone wants that service however.

> Aside from practical issues with flowspec as Ytti mentioned already, I
> don't think the market has yet figured out how stuff like this should
> work and become cost-effective.

Ah cost effective is a consideration, yeah that is a bit of a bummer.

> Kind regards,
> 
> Job
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140918/c2ba4505/attachment.sig>

From BMassel at descartes.com  Thu Sep 18 20:42:23 2014
From: BMassel at descartes.com (Brock Massel)
Date: Thu, 18 Sep 2014 20:42:23 +0000
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
Message-ID: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>

Hi folks,
I'm hoping someone can shed some light on the situation.

The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some.

Several looking glass' report network not in table. 

Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? 

B 


From job at instituut.net  Thu Sep 18 20:49:16 2014
From: job at instituut.net (Job Snijders)
Date: Thu, 18 Sep 2014 22:49:16 +0200
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
Message-ID: <20140918204916.GF96444@Vurt.local>

On Thu, Sep 18, 2014 at 08:42:23PM +0000, Brock Massel wrote:
> The 192.250.24 addresses have been reachable for several months in the
> current configuration with no reported issues. Since the 16th we have
> been hearing reports that destinations in that block are unavailable
> for some.
> 
> Several looking glass' report network not in table. 

Which ones?

> Can someone lend a hand? What is the best way to improve this
> situation? How do we find where the problem is? 

Do you have a pingable IP address in the range which is problematic?
That would help others who are willing to debug your issue enormously.

Kind regards,

Job


From sthaug at nethelp.no  Thu Sep 18 21:08:55 2014
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 18 Sep 2014 23:08:55 +0200 (CEST)
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <20140918204916.GF96444@Vurt.local>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <20140918204916.GF96444@Vurt.local>
Message-ID: <20140918.230855.41694907.sthaug@nethelp.no>

> > The 192.250.24 addresses have been reachable for several months in the
> > current configuration with no reported issues. Since the 16th we have
> > been hearing reports that destinations in that block are unavailable
> > for some.
> > 
> > Several looking glass' report network not in table. 

Visible from here (AS 2116, Norway). 

> Do you have a pingable IP address in the range which is problematic?
> That would help others who are willing to debug your issue enormously.

192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From hslabbert at stargate.ca  Thu Sep 18 21:23:51 2014
From: hslabbert at stargate.ca (Hugo Slabbert)
Date: Thu, 18 Sep 2014 14:23:51 -0700
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <20140918.230855.41694907.sthaug@nethelp.no>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <20140918204916.GF96444@Vurt.local>
 <20140918.230855.41694907.sthaug@nethelp.no>
Message-ID: <20140918212350.GH1494@stargate.ca>

On Thu 2014-Sep-18 23:08:55 +0200, sthaug at nethelp.no <sthaug at nethelp.no> wrote:
>> > The 192.250.24 addresses have been reachable for several months in the
>> > current configuration with no reported issues. Since the 16th we have
>> > been hearing reports that destinations in that block are unavailable
>> > for some.
>> >
>> > Several looking glass' report network not in table.
>
>Visible from here (AS 2116, Norway).
>
>> Do you have a pingable IP address in the range which is problematic?
>> That would help others who are willing to debug your issue enormously.
>
>192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116.
>
>Steinar Haug, Nethelp consulting, sthaug at nethelp.no

Same from AS 19171 (Canada).  Shows up in all our transits and the IPs Steinar 
noted are pingable and traceable.  We're currently reaching it through 577 812 
23034.  All our transits are showing the route through 812 (Rogers).

--
Hugo Slabbert
Stargate Connections - AS19171



From tony at wicks.co.nz  Thu Sep 18 21:26:27 2014
From: tony at wicks.co.nz (Tony Wicks)
Date: Fri, 19 Sep 2014 09:26:27 +1200
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <20140918.230855.41694907.sthaug@nethelp.no>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <20140918204916.GF96444@Vurt.local>
 <20140918.230855.41694907.sthaug@nethelp.no>
Message-ID: <002d01cfd387$381bdeb0$a8539c10$@wicks.co.nz>



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of sthaug at nethelp.no
Sent: Friday, 19 September 2014 9:09 a.m.
To: BMassel at descartes.com; job at instituut.net
Cc: nanog at nanog.org
Subject: Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
global crossing, XO

> > The 192.250.24 addresses have been reachable for several months in 
> > the current configuration with no reported issues. Since the 16th we 
> > have been hearing reports that destinations in that block are 
> > unavailable for some.

Reachable from New Zealand -

192.250.24.0/24    *[BGP/170] 02:42:04, MED 0, localpref 90
                      AS path: 4826 174 812 23034 I, validation-state:
unverified
                    > to 175.45.102.9 via ae1.526

64 bytes from 192.250.24.1: icmp_seq=0 ttl=242 time=193.274 ms
64 bytes from 192.250.24.1: icmp_seq=1 ttl=242 time=196.312 ms
64 bytes from 192.250.24.1: icmp_seq=2 ttl=242 time=197.578 ms







From gary at baribault.net  Thu Sep 18 21:36:26 2014
From: gary at baribault.net (Gary Baribault)
Date: Thu, 18 Sep 2014 17:36:26 -0400
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <20140918.230855.41694907.sthaug@nethelp.no>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <20140918204916.GF96444@Vurt.local>
 <20140918.230855.41694907.sthaug@nethelp.no>
Message-ID: <541B505A.5090207@baribault.net>

Pingable from Montreal area as well

Gary Baribault
Courriel: gary at baribault.net
GPG Key: 0x685430d1
Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1

On 09/18/2014 05:08 PM, sthaug at nethelp.no wrote:
>>> The 192.250.24 addresses have been reachable for several months in the
>>> current configuration with no reported issues. Since the 16th we have
>>> been hearing reports that destinations in that block are unavailable
>>> for some.
>>>
>>> Several looking glass' report network not in table. 
> Visible from here (AS 2116, Norway). 
>
>> Do you have a pingable IP address in the range which is problematic?
>> That would help others who are willing to debug your issue enormously.
> 192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116.
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>



From dougb at dougbarton.us  Thu Sep 18 21:38:24 2014
From: dougb at dougbarton.us (Doug Barton)
Date: Thu, 18 Sep 2014 14:38:24 -0700
Subject: Here comes iOS 8...
In-Reply-To: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
Message-ID: <541B50D0.70504@dougbarton.us>

FWIW ...

http://techcrunch.com/2014/09/18/ios-8-adoption-off-to-a-slower-start-than-ios-7-say-multiple-usage-trackers/


From gary at baribault.net  Thu Sep 18 21:39:01 2014
From: gary at baribault.net (Gary Baribault)
Date: Thu, 18 Sep 2014 17:39:01 -0400
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <20140918.230855.41694907.sthaug@nethelp.no>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <20140918204916.GF96444@Vurt.local>
 <20140918.230855.41694907.sthaug@nethelp.no>
Message-ID: <541B50F5.3070404@baribault.net>

Hum, Traceroute is not as nice

traceroute to 192.250.24.1 (192.250.24.1), 30 hops max, 60 byte packets
 1  GW (192.168.0.2)  0.459 ms  0.435 ms  0.422 ms
 2  * * *
 3  10.170.182.81 (10.170.182.81)  18.417 ms  18.711 ms  18.702 ms
 4  216.113.124.126 (216.113.124.126)  16.611 ms  17.774 ms  17.774 ms
 5  216.113.122.74 (216.113.122.74)  45.746 ms  46.035 ms  46.025 ms
 6  144.232.7.250 (144.232.7.250)  44.529 ms  45.507 ms  45.178 ms
 7  be3013.ccr21.ord03.atlas.cogentco.com (154.54.10.37)  38.741 ms 
35.537 ms  37.036 ms
 8  24.156.159.153 (24.156.159.153)  31.433 ms  32.658 ms  29.417 ms
 9  24.156.144.177 (24.156.144.177)  34.106 ms  32.621 ms
van58-10-228-225.dynamic.rogerstelecom.net (209.148.228.225)  30.299 ms
10  24.156.144.126 (24.156.144.126)  30.339 ms  30.329 ms  30.055 ms
11  24.153.4.185 (24.153.4.185)  32.955 ms  34.112 ms  34.146 ms
12  gi-3-0-0.agw02.hrnr.phub.net.cable.rogers.com (24.153.7.82)  30.935
ms  32.375 ms  32.356 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * 206.186.1.10 (206.186.1.10)  37.869 ms

Gary Baribault
Courriel: gary at baribault.net
GPG Key: 0x685430d1
Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1

On 09/18/2014 05:08 PM, sthaug at nethelp.no wrote:
>>> The 192.250.24 addresses have been reachable for several months in the
>>> current configuration with no reported issues. Since the 16th we have
>>> been hearing reports that destinations in that block are unavailable
>>> for some.
>>>
>>> Several looking glass' report network not in table. 
> Visible from here (AS 2116, Norway). 
>
>> Do you have a pingable IP address in the range which is problematic?
>> That would help others who are willing to debug your issue enormously.
> 192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116.
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>



From BMassel at descartes.com  Thu Sep 18 21:54:27 2014
From: BMassel at descartes.com (Brock Massel)
Date: Thu, 18 Sep 2014 21:54:27 +0000
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <CADzy1LbJL29TrpiLp+NrPhOG5VbuqVHk68c3qkmEAt4tmZhwZw@mail.gmail.com>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <CADzy1LbJL29TrpiLp+NrPhOG5VbuqVHk68c3qkmEAt4tmZhwZw@mail.gmail.com>
Message-ID: <5D7E8D6713A8AA4AB53AF403632BE826013774419F@CPEXM01.corp.dsg.local>

Karsten,
Thank you I am not sure why those 702 and 19294 old entries would still be there. 

We have engaged 812 for help. 

Shall I assume cleaning up the old entries will solve the problems?



-----Original Message-----
From: Karsten Elfenbein [mailto:karsten.elfenbein at gmail.com] 
Sent: Thursday, September 18, 2014 5:46 PM
To: Brock Massel
Cc: nanog at nanog.org
Subject: Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO

Hi,

looks like you mainly use one transit provider (AS812) or your other transit providers correctly filter that prefix.

According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_version=0.7&resource=192.250.24.0%2F22
there is no route object for the 192.250.24.0/22.
As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to have started filtering the prefix from AS812. Which reduced the visibility of that prefix. Check the BGplay from the last days:
https://stat.ripe.net/192.250.24.0%2F22#tabId=routing

so create the correct route object and the prefix should come up over the next day(s)

Also get the more specific route objects removed which point to other AS.

192.250.24.0/23 AS702
192.250.24.0/24 AS19294



Karsten

2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel at descartes.com>:
> Hi folks,
> I'm hoping someone can shed some light on the situation.
>
> The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some.
>
> Several looking glass' report network not in table.
>
> Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is?
>
> B


From andy.litzinger.lists at gmail.com  Tue Sep 16 15:33:38 2014
From: andy.litzinger.lists at gmail.com (Andy Litzinger)
Date: Tue, 16 Sep 2014 08:33:38 -0700
Subject: BGP per-flow load balancing between eBGP and iBGP learned prefix
Message-ID: <CAEs0Em+0N=aXuUc6aRhmyC9CXkJUgtO85S9AFWq3KhV9UeCaaA@mail.gmail.com>

Hello,

I have a Load Balancer that uses a default route to a VRRP IP hosted
between two Juniper MX80 routers.  Each MX router has a single BGP feed
from the same provider and each session is currently receiving only a
default route.

I'd like to load balance my outbound traffic across the two links.  More
specifically I want to balance traffic to a particular prefix across the
two links so even if i was receiving full routes trying to manually split
prefixes to a second upstream VRRP instance wouldn't help.

I believe the typical way to do this would be to run an IGP between the LB
and the MX's so that each MX advertises a default route to the LB and let
ECMP take care of it.  I'm not averse to this long term, but I have a short
term need and the LB requires a license to participate in an IGP.  Is there
another way?  I should note that the LB will not let me enter multiple
default or identical static routes so I can't try spinning up a second VRRP
session and adding a second default route on the LB to it.

Is it possible to let BGP do the load balancing?  From what I can tell this
would be trivial if both of the provider links were terminated on the same
router via a few multipath config lines but because they are on different
routers I seem to be running into the "eBGP > iBGP" Path selection criteria
which prevents the routes from being equal.

I appreciate any ideas!

regards,
 -andy


From jmcc at hosterstats.com  Tue Sep 16 16:34:57 2014
From: jmcc at hosterstats.com (John McCormac)
Date: Tue, 16 Sep 2014 17:34:57 +0100
Subject: Scotland ccTLD?
In-Reply-To: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
References: <15006189.1806.1410881169907.JavaMail.root@benjamin.baylink.com>
Message-ID: <541866B1.40305@hosterstats.com>

On 16/09/2014 16:26, Jay Ashworth wrote:
> What kind of timeframe would a new ccTLD for a major country roll out on?

The main issue wouldn't be the timeframe for a rollout of a Scottish 
ccTLD but rather the disengagement from the .UK ccTLD. The legislative 
part will take time and there might also be an issue about the contract 
to operate the registry being put out to tender. It might definitely be 
a question of months and these things can drag on.

In the event of a Yes vote in the independence referendum, most of 
Scotland's domain name footprint will still be .UK orientated. That 
would be very slow to change and the new ccTLD would begin to operate in 
parallel with that. That .SCOT gTLD could end up being very lucky as it 
might just fill a niche in a market where there is no serious 
competition from a local official ccTLD.

Regards...jmcc
-- 
**********************************************************
John McCormac  *  e-mail: jmcc at hosterstats.com
MC2            *  web: http://www.hosterstats.com/
22 Viewmount   *  Domain Registrations Statistics
Waterford      *  And Historical DNS Database.
Ireland        *  Over 396 Million Domains Tracked.
IE             *  web: http://newgtldnews.com
**********************************************************


From ainglis at agoc.com  Wed Sep 17 18:08:28 2014
From: ainglis at agoc.com (Inglis, Adam)
Date: Wed, 17 Sep 2014 18:08:28 +0000
Subject: Here comes iOS 8...
In-Reply-To: <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
Message-ID: <013E121BB2474C489C9000DFA2239C3C4147920B@AGCMBX02.AGC01.com>

Depending on the device used, the zip file can range from 

Length: 1515061530 (1.4G) [application/octet-stream]

To

Length: 2119504233 (2.0G) [application/octet-stream]

Parsed from http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml 

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Grant Ridder
Sent: Wednesday, September 17, 2014 1:34 PM
To: nick at flhsi.com
Cc: NANOG
Subject: Re: Here comes iOS 8...

For those that are curious, it looks like the download is 1.1 gigs.

-Grant

On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:

> I've been waiting all morning.
>
>  Expedited repair of a primary link to prepare for the traffic. Not 
> that it didn't have multiple backups. But one doesn't trifle with IOS8 
> release traffic.. If it's anything like IOS7 was..
>
>  Nick Olsen
> Network Operations  (855) FLSPEED  x106
>
>
> ----------------------------------------
>  From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
> Sent: Wednesday, September 17, 2014 12:59 PM
> To: "NANOG" <nanog at nanog.org>
> Subject: Here comes iOS 8...
> So Apple is about to release iOS 8... Have you done anything special 
> to your network setup to accommodate the traffic flood ie traffic 
> shaping rules, cache servers, etc?
>
> I heard that Apple Caching servers won't work with this update, so I'm 
> guessing it will be pushed through Akamai servers as is usually is.
>
> - Zachary
>
>
>


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender or send back to returns at agoc.com and delete the material from any computer.

From jcantu at nic.mx  Wed Sep 17 22:17:49 2014
From: jcantu at nic.mx (Jose Damian Cantu Davila)
Date: Wed, 17 Sep 2014 22:17:49 +0000
Subject: IP Geolocation Issue
Message-ID: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>

Hi, Im new here, so any advice would be very appreciated.

Is someone from Maxmind IP Geolocation available, that I can talk to offline?

Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil.

Thanks for your help.

[damian cantu]



From tylermills at gmail.com  Thu Sep 18 02:09:20 2014
From: tylermills at gmail.com (Tyler Mills)
Date: Wed, 17 Sep 2014 21:09:20 -0500
Subject: Here comes iOS 8...
In-Reply-To: <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
Message-ID: <541A3ED0.2010700@gmail.com>

The download was ~1.1GB, the installer requires almost 5GB free to proceed.

Tyler.

On 9/17/14 9:04 PM, JoeSox wrote:
> Grant,
> Do you have a reference? Someone just told me it is more around 5GB.
>
> --
> Later, Joe
>
> On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder <shortdudey123 at gmail.com>
> wrote:
>
>> For those that are curious, it looks like the download is 1.1 gigs.
>>
>> -Grant
>>
>> On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen <nick at flhsi.com> wrote:
>>
>>> I've been waiting all morning.
>>>
>>>   Expedited repair of a primary link to prepare for the traffic. Not that
>> it
>>> didn't have multiple backups. But one doesn't trifle with IOS8 release
>>> traffic.. If it's anything like IOS7 was..
>>>
>>>   Nick Olsen
>>> Network Operations  (855) FLSPEED  x106
>>>
>>>
>>> ----------------------------------------
>>>   From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>> To: "NANOG" <nanog at nanog.org>
>>> Subject: Here comes iOS 8...
>>> So Apple is about to release iOS 8... Have you done anything special to
>>> your network setup to accommodate the traffic flood ie traffic shaping
>>> rules, cache servers, etc?
>>>
>>> I heard that Apple Caching servers won't work with this update, so I'm
>>> guessing it will be pushed through Akamai servers as is usually is.
>>>
>>> - Zachary
>>>
>>>
>>>



From VAniello at portware.com  Thu Sep 18 09:30:06 2014
From: VAniello at portware.com (Vincent Aniello)
Date: Thu, 18 Sep 2014 05:30:06 -0400
Subject: Outbound traffic from 208.89.136.0/22 going from L.A. to London?
In-Reply-To: <CAFG21ojkzG1iaf-+kH0BmzOi_bfbG-20-q=n4FUEsE8LVFttfw@mail.gmail.com>
References: <CAFG21ojkzG1iaf-+kH0BmzOi_bfbG-20-q=n4FUEsE8LVFttfw@mail.gmail.com>
Message-ID: <OF4BEED7D7.CE088E9F-ON85257D57.00340404-85257D57.003431C4@portware.com>

We are seeing issues on our Savvis Internet connections in New York to 
users in London and Sweden.  Not many details yet, just seeing slow and 
sporadic connectivity.

--Vincent



From:   Todd Lyons <tlyons at ivenue.com>
To:     NANOG list <nanog at nanog.org>
Date:   09/18/2014 05:21 AM
Subject:        Outbound traffic from 208.89.136.0/22 going from L.A. to 
London?
Sent by:        "NANOG" <nanog-bounces at nanog.org>



I'm seeing some weird routing outbound for *some* destinations.
Testing from 208.89.139.252.

google.com resolves for me to 74.125.239.112 and the outbound path is
fast and appears to stay in the US.

yahoo.com resolves for me to 98.138.253.109, but the outbound path
goes through Savvis London, then to BT, then to Yahoo.

# mtr 98.138.253.109 --report --report-cycles 10
HOST: mail.mrball.net             Loss%   Snt   Last   Avg  Best  Wrst 
StDev
...internal...
  5. gw.iv.ivenue.com              0.0%    10    2.7   2.7   2.6   2.8 0.1
  6. 64.70.17.121                  0.0%    10    2.8   3.8   2.8  11.5 2.7
  7. hr2-v3007.la1.savvis.net      0.0%    10    2.8  22.9   2.8 203.1 
63.3
  8. 204.70.203.90                 0.0%    10    4.0   4.3   3.8   5.6 0.5
  9. cr1-pos-0-0-0-0.londonuk1.sa  0.0%    10  177.1 157.9 151.1 179.7 
11.5
 10. esr1-xe-7-0-0.ams.savvis.net  0.0%    10  166.5 166.4 166.3 166.5 0.1
 11. ???                          100.0    10    0.0   0.0   0.0   0.0 0.0
 12. ???                          100.0    10    0.0   0.0   0.0   0.0 0.0
 13. ixp1-xe-11-0-0-0.us-ash.eu.b 80.0%    10  597.0 595.7 594.4 597.0 1.9
 14. ???                          100.0    10    0.0   0.0   0.0   0.0 0.0
 15. ???                          100.0    10    0.0   0.0   0.0   0.0 0.0
 16. ae-5.pat1.nez.yahoo.com      90.0%    10  546.0 546.0 546.0 546.0 0.0
 17. ???                          100.0    10    0.0   0.0   0.0   0.0 0.0

# mtr 98.138.253.109 -n --report --report-cycles 15
HOST: mail.mrball.net             Loss%   Snt   Last   Avg  Best  Wrst 
StDev
...internal...
  5. 208.89.136.1                  0.0%    15    2.6   2.7   2.6   2.9 0.1
  6. 64.70.17.121                  0.0%    15    2.8   8.9   2.8  57.5 
16.2
  7. 64.70.11.57                   0.0%    15    2.8   2.9   2.8   3.2 0.1
  8. 204.70.203.90                 0.0%    15    4.4   5.4   3.7  23.5 5.0
  9. 204.70.192.122                0.0%    15  151.2 154.7 151.1 172.9 7.0
 10. 204.70.202.2                  0.0%    15  166.4 168.8 166.3 202.7 9.4
 11. ???                          100.0    15    0.0   0.0   0.0   0.0 0.0
 12. 166.49.208.90                80.0%    15  508.3 507.2 505.9 508.3 1.2
 13. 166.49.208.59                80.0%    15  589.8 589.8 588.9 590.6 0.9
 14. ???                          100.0    15    0.0   0.0   0.0   0.0 0.0
 15. 216.115.96.81                93.3%    15  521.8 521.8 521.8 521.8 0.0
 16. ???                          100.0    15    0.0   0.0   0.0   0.0 0.0
 17. 216.115.100.3                93.3%    15  537.4 537.4 537.4 537.4 0.0
 18. 98.138.144.29                91.7%    12  537.1 537.1 537.1 537.1 0.0
 19. ???                          100.0     5    0.0   0.0   0.0   0.0 0.0
 20. 98.138.240.28                80.0%     5  537.9 537.9 537.9 537.9 0.0
 21. ???                          100.0     4    0.0   0.0   0.0   0.0 0.0
 22. 98.138.253.109               66.7%     3  537.9 537.9 537.9 537.9 0.0

Traffic served by Akamai appears to be fast and stays local (i.e.
tested to www.apple.com).

A call in to Savvis got attached to master ticket 4828052, which is
for "large packet loss".  Describes the symptom, not the cause.

Is there anybody who has more info?  Anybody who's a Savvis customer
who sees the same weird outbound routing?  Or are we the only ones?
Feel free to traceroute to 208.89.139.252 to try and duplicate these
results.

...Todd

-- 
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine



From karsten.elfenbein at gmail.com  Thu Sep 18 21:54:05 2014
From: karsten.elfenbein at gmail.com (Karsten Elfenbein)
Date: Thu, 18 Sep 2014 23:54:05 +0200
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <CADzy1LbJL29TrpiLp+NrPhOG5VbuqVHk68c3qkmEAt4tmZhwZw@mail.gmail.com>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <CADzy1LbJL29TrpiLp+NrPhOG5VbuqVHk68c3qkmEAt4tmZhwZw@mail.gmail.com>
Message-ID: <CADzy1LYCv_WzgCZdh1q_xQuvkh6wiQ8s4TMoBkEr_=xJx65mAw@mail.gmail.com>

Hi,

looks like you mainly use one transit provider (AS812) or your other
transit providers correctly filter that prefix.

According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_version=0.7&resource=192.250.24.0%2F22
there is no route object for the 192.250.24.0/22.
As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to
have started filtering the prefix from AS812. Which reduced the
visibility of that prefix. Check the BGplay from the last days:
https://stat.ripe.net/192.250.24.0%2F22#tabId=routing

so create the correct route object and the prefix should come up over
the next day(s)

Also get the more specific route objects removed which point to other AS.
192.250.24.0/23 AS702
192.250.24.0/24 AS19294


Karsten

2014-09-18 23:46 GMT+02:00 Karsten Elfenbein <karsten.elfenbein at gmail.com>:
> Hi,
>
> looks like you mainly use one transit provider (AS812) or your other
> transit providers correctly filter that prefix.
>
> According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_version=0.7&resource=192.250.24.0%2F22
> there is no route object for the 192.250.24.0/22.
> As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to
> have started filtering the prefix from AS812. Which reduced the
> visibility of that prefix. Check the BGplay from the last days:
> https://stat.ripe.net/192.250.24.0%2F22#tabId=routing
>
> so create the correct route object and the prefix should come up over
> the next day(s)
>
> Also get the more specific route objects removed which point to other AS.
>
> 192.250.24.0/23 AS702
> 192.250.24.0/24 AS19294
>
>
>
> Karsten
>
> 2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel at descartes.com>:
>> Hi folks,
>> I'm hoping someone can shed some light on the situation.
>>
>> The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some.
>>
>> Several looking glass' report network not in table.
>>
>> Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is?
>>
>> B


From karsten.elfenbein at gmail.com  Thu Sep 18 22:09:44 2014
From: karsten.elfenbein at gmail.com (Karsten Elfenbein)
Date: Fri, 19 Sep 2014 00:09:44 +0200
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <5D7E8D6713A8AA4AB53AF403632BE826013774419F@CPEXM01.corp.dsg.local>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
 <CADzy1LbJL29TrpiLp+NrPhOG5VbuqVHk68c3qkmEAt4tmZhwZw@mail.gmail.com>
 <5D7E8D6713A8AA4AB53AF403632BE826013774419F@CPEXM01.corp.dsg.local>
Message-ID: <CADzy1LZfVXP0MtoJGaGO=qYC+WLzPLQSngW-rk7Ru=URg2ik=A@mail.gmail.com>

The more specific objects are more cosmetic issue.
The main problem is the missing object for your /22. As well as your
AS23034 does not seem to be listed in AS-ROGERS:AS-CUSTOMERS
http://bgp.he.net/AS812#_irr

Karsten



2014-09-18 23:54 GMT+02:00 Brock Massel <BMassel at descartes.com>:
> Karsten,
> Thank you I am not sure why those 702 and 19294 old entries would still be there.
>
> We have engaged 812 for help.
>
> Shall I assume cleaning up the old entries will solve the problems?
>
>
>
> -----Original Message-----
> From: Karsten Elfenbein [mailto:karsten.elfenbein at gmail.com]
> Sent: Thursday, September 18, 2014 5:46 PM
> To: Brock Massel
> Cc: nanog at nanog.org
> Subject: Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
>
> Hi,
>
> looks like you mainly use one transit provider (AS812) or your other transit providers correctly filter that prefix.
>
> According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_version=0.7&resource=192.250.24.0%2F22
> there is no route object for the 192.250.24.0/22.
> As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to have started filtering the prefix from AS812. Which reduced the visibility of that prefix. Check the BGplay from the last days:
> https://stat.ripe.net/192.250.24.0%2F22#tabId=routing
>
> so create the correct route object and the prefix should come up over the next day(s)
>
> Also get the more specific route objects removed which point to other AS.
>
> 192.250.24.0/23 AS702
> 192.250.24.0/24 AS19294
>
>
>
> Karsten
>
> 2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel at descartes.com>:
>> Hi folks,
>> I'm hoping someone can shed some light on the situation.
>>
>> The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some.
>>
>> Several looking glass' report network not in table.
>>
>> Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is?
>>
>> B
>


From joelja at bogus.com  Thu Sep 18 23:57:08 2014
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 18 Sep 2014 16:57:08 -0700
Subject: upstream support for flowspec
In-Reply-To: <20140918130634.55bf5853@localhost>
References: <ygfbnqcbyrz.fsf@corbe.net> <20140918130634.55bf5853@localhost>
Message-ID: <541B7154.1000105@bogus.com>

On 9/18/14 11:06 AM, John Kristoff wrote:
> On Thu, 18 Sep 2014 13:53:52 -0400
> Daniel Corbe <corbe at corbe.net> wrote:
> 
>> Is there anything in the air about widening the adoption base?  Cisco?
>> Brocade?
> 
> I've seen some suggesting that increased support, but even at Juniper,
> actions seem to speak larger than words.  There seems to be very little
> interest for awhile now.  However, I do know of some providers who use
> it, largely internal only.

afaik from some previous experience it was hard to know a-priori which
flow-spec route insertion was going to cause aberrant performance on the
juniper platforms we were using.

That's kinda ok if you use them since at least you can be aware of and
revert that if it proves to be a problem. but it's kind of handing your
customer a loaded gun.

> We also have tried a community flow-spec service, and more recently
> have been prototyping a community RTBH server with flow-spec capability
> (ping me off list if you want to hear more or see me at NANOG 62).
> 
> A few people have recently told me they would like our community RTBH
> service via flow-spec instead of just BGP next hop, but really only one
> seemed seriously intent on configuring it day one.
> 
> John
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140918/ad652256/attachment.sig>

From larrysheldon at cox.net  Fri Sep 19 02:55:23 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Thu, 18 Sep 2014 21:55:23 -0500
Subject: [VoiceOps] ITFS Term vendor question
In-Reply-To: <sN3z1o00F1cZc5601N43Uf>
References: <sN3z1o00F1cZc5601N43Uf>
Message-ID: <541B9B1B.3090809@cox.net>

On 9/17/2014 16:59, Jay Ashworth wrote:
> ---- Original Message -----
>> From: "Nick Crocker" <nick.crocker at gmail.com>
>
>> Can someone shed some light on how you might be accomplishing this, I have
>> a hard time believing that customers are being told they cannot dial TF
>> numbers in their own country.
>
> In the US, it's always been my understanding that what we call INWATS calls
> are dipped *at the originating CO*, and the actual toll call across the
> SS7/TDM backbone goes out using either the real 10D DN of the target line,
> or some fake 10D that routes to the appropriate trunk group somehow at the
> destination end.
>
> So it's not that unusual to me that a network that is interfacing at
> Class 4, instead of Class 5, might be unable to originate calls to TF DNs.
>
> I admit to not being sure this is a worldwide view of the issue, as our
> Wikipedian friends would say, though.

I don't think I ever know the details of automatic TF routing, but I'm 
pretty sure that in California Zenith and Enterprise numbers were 
translated by R & R and sent collect.  Zenith 9000 is the only exception 
I know of.

Operator 25 (?) calls were just sent collect to the CB number.

In-WATS was purchased for particular areas (rest-of-the-state, for 
example) and calls from a point not paid-for simply would not translate.



-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


From frnkblk at iname.com  Fri Sep 19 03:58:12 2014
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 18 Sep 2014 22:58:12 -0500
Subject: IP Geolocation Issue
In-Reply-To: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>
References: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>
Message-ID: <006901cfd3bd$ef1b09c0$cd511d40$@iname.com>

I would suggest starting with this form:
https://www.maxmind.com/en/correction

More here: http://nanog.peeringdb.com/index.php/GeoIP

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jose Damian Cantu
Davila
Sent: Wednesday, September 17, 2014 5:18 PM
To: nanog at nanog.org
Subject: IP Geolocation Issue

Hi, Im new here, so any advice would be very appreciated.

Is someone from Maxmind IP Geolocation available, that I can talk to
offline?

Its regarding to a block we assigned to a client. The client and its
customers are located in Mexico but the IP Geolocation services says they
are located in Brazil.

Thanks for your help.

[damian cantu]





From rdobbins at arbor.net  Fri Sep 19 04:23:47 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 19 Sep 2014 11:23:47 +0700
Subject: BGP per-flow load balancing between eBGP and iBGP learned prefix
In-Reply-To: <CAEs0Em+0N=aXuUc6aRhmyC9CXkJUgtO85S9AFWq3KhV9UeCaaA@mail.gmail.com>
References: <CAEs0Em+0N=aXuUc6aRhmyC9CXkJUgtO85S9AFWq3KhV9UeCaaA@mail.gmail.com>
Message-ID: <18BEDE07-6502-49FE-856C-6D5CE1B6081B@arbor.net>


On Sep 16, 2014, at 10:33 PM, Andy Litzinger <andy.litzinger.lists at gmail.com> wrote:

> I appreciate any ideas!

My idea mainly centers around the operational complexity and difficulty of troubleshooting a setup of this nature.

Why not just let routing take its natural course?  Or at most, play some simple preference games which have consistent outcomes?

This kind of thing is generally far more trouble than it's worth, in my experience.

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

                   Equo ne credite, Teucri.

    		   	  -- Laoco?n



From morrowc.lists at gmail.com  Fri Sep 19 04:32:36 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 19 Sep 2014 00:32:36 -0400
Subject: BGP per-flow load balancing between eBGP and iBGP learned prefix
In-Reply-To: <18BEDE07-6502-49FE-856C-6D5CE1B6081B@arbor.net>
References: <CAEs0Em+0N=aXuUc6aRhmyC9CXkJUgtO85S9AFWq3KhV9UeCaaA@mail.gmail.com>
 <18BEDE07-6502-49FE-856C-6D5CE1B6081B@arbor.net>
Message-ID: <CAL9jLaaMKrF_i_TRRrYScNOT94ETFLXcvSq2Kf_qqYYhYWBcKg@mail.gmail.com>

On Fri, Sep 19, 2014 at 12:23 AM, Roland Dobbins <rdobbins at arbor.net> wrote:
>
> On Sep 16, 2014, at 10:33 PM, Andy Litzinger <andy.litzinger.lists at gmail.com> wrote:
>
>> I appreciate any ideas!
>
> My idea mainly centers around the operational complexity and difficulty of troubleshooting a setup of this nature.
>

yes, this.

> Why not just let routing take its natural course?  Or at most, play some simple preference games which have consistent outcomes?
>

I think he's only getting default from his provider(s), which is a
shame, get full routes instead and then play the preferences off...(I
think).

> This kind of thing is generally far more trouble than it's worth, in my experience.
>

this, yes.

> ----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                    Equo ne credite, Teucri.
>
>                           -- Laoco?n
>


From j at arpa.com  Fri Sep 19 06:41:06 2014
From: j at arpa.com (jamie rishaw)
Date: Fri, 19 Sep 2014 01:41:06 -0500
Subject: Moot thread: Scotland
Message-ID: <CABL6YZSAv8n96hsUvWHCRoeKemb=pRmcZnF8D3N5LGxGz6X1bA@mail.gmail.com>

Nice exercise in what-ifs, but with 90% reporting and a ten point "No,
thank you" majority, the decision to stay as one UK has clearly prevailed.
..Not that I'm up at 0240 Eastern to check on the vote of course.
Source: BBC World News.
-j

-- 
jamie rishaw // .com.arpa at j <- reverse it. ish.

"...let's consider this world like a family and care about each other..."
             -Malala Yousafzai


From dot at dotat.at  Fri Sep 19 09:01:11 2014
From: dot at dotat.at (Tony Finch)
Date: Fri, 19 Sep 2014 10:01:11 +0100
Subject: Bare TLD resolutions
In-Reply-To: <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
References: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
 <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
Message-ID: <alpine.LSU.2.00.1409190959570.3000@hermes-1.csi.cam.ac.uk>

David Conrad <drc at virtualized.org> wrote:

> To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or wildcards).

Wildcards are being used for the name collision gubbins.

; <<>> DiG 9.11.0pre-alpha <<>> *.prod
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51904
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;*.prod.                                IN      A

;; ANSWER SECTION:
*.prod.                 3600    IN      A       127.0.53.53

;; Query time: 66 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Sep 19 10:00:30 BST 2014
;; MSG SIZE  rcvd: 51

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From alex at alexwacker.com  Fri Sep 19 00:09:43 2014
From: alex at alexwacker.com (Alex Wacker)
Date: Thu, 18 Sep 2014 20:09:43 -0400
Subject: IP Geolocation Issue
In-Reply-To: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>
References: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>
Message-ID: <CA+3otVi60Rte6Vsi1ea7bSqyd80Eij5gPFrhDj6R8R7-C5GAdA@mail.gmail.com>

You can submit corrections to maxmind here:
https://www.maxmind.com/en/correction

On Wed, Sep 17, 2014 at 6:17 PM, Jose Damian Cantu Davila <jcantu at nic.mx> wrote:
> Hi, Im new here, so any advice would be very appreciated.
>
> Is someone from Maxmind IP Geolocation available, that I can talk to offline?
>
> Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil.
>
> Thanks for your help.
>
> [damian cantu]
>


From m.waehlisch at fu-berlin.de  Fri Sep 19 13:28:27 2014
From: m.waehlisch at fu-berlin.de (Matthias Waehlisch)
Date: Fri, 19 Sep 2014 15:28:27 +0200
Subject: Survey about RPKI/DNSSEC
Message-ID: <alpine.WNT.2.00.1409191520250.7480@mw-PC>

Hi NANOG,

  we, a group of researchers, try to better understand the deployment of 
RPKI and DNSSEC. It's not always easy to find technical reasons for what 
we observe. To get more insights why you deploy or don't deploy RPKI or 
DNSSEC, we would like to ask you to participate in the following brief 
survey:

                http://eSurv.org?u=rpkidnssec

  We really appreciate your time. It should not take more than 5 minutes 
to complete the survey.

  The survey is anonymous. The results are only used to improve research 
on inter-networking. If there is interest, we will post the results to 
the list.

  Fell free to contact me offlist in case of further questions or 
comments.


Many thanks!

matthias
(on behalf of the team)


[This email has also been sent to RIPE and SIDR folks.]


-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net


From deric.kwok2000 at gmail.com  Fri Sep 19 13:52:04 2014
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Fri, 19 Sep 2014 09:52:04 -0400
Subject: any suggestion for networktool
Message-ID: <CAAiP323qEm8upUsnqHPpgabUpQTcbgw=R9p2Lias2hhNsddxjA@mail.gmail.com>

Hi all

Any tool can help to collect destination ip  in graph for different
location?

eg: Germany

Thank you so much


From andy at newslink.com  Fri Sep 19 14:33:02 2014
From: andy at newslink.com (Andy Ringsmuth)
Date: Fri, 19 Sep 2014 09:33:02 -0500
Subject: Here comes iOS 8...
In-Reply-To: <541A3ED0.2010700@gmail.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
 <541A3ED0.2010700@gmail.com>
Message-ID: <75545F9B-6403-4F6B-8E76-9D07AFF32E5C@newslink.com>

>>>> 
>>>> ----------------------------------------
>>>>  From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>>> To: "NANOG" <nanog at nanog.org>
>>>> Subject: Here comes iOS 8...
>>>> So Apple is about to release iOS 8... Have you done anything special to
>>>> your network setup to accommodate the traffic flood ie traffic shaping
>>>> rules, cache servers, etc?
>>>> 
>>>> I heard that Apple Caching servers won't work with this update, so I'm
>>>> guessing it will be pushed through Akamai servers as is usually is.
>>>> 
>>>> - Zachary

Interestingly enough, it seems Apple primarily used it's own, new, CDN for the iOS 8 release:

http://appleinsider.com/articles/14/09/18/apple-chose-to-handle-ios-8-rollout-with-own-content-delivery-network

----
Andy Ringsmuth
andy at newslink.com
News Link ? Manager Technology & Facilities
2201 Winthrop Rd., Lincoln, NE 68502-4158
(402) 475-6397    (402) 304-0083 cellular

From drc at virtualized.org  Fri Sep 19 15:01:36 2014
From: drc at virtualized.org (David Conrad)
Date: Fri, 19 Sep 2014 08:01:36 -0700
Subject: Bare TLD resolutions
In-Reply-To: <alpine.LSU.2.00.1409190959570.3000@hermes-1.csi.cam.ac.uk>
References: <13054977.2006.1410975369686.JavaMail.root@benjamin.baylink.com>
 <5A8EF145-85A9-4F3F-B0EE-245B3665AB47@virtualized.org>
 <alpine.LSU.2.00.1409190959570.3000@hermes-1.csi.cam.ac.uk>
Message-ID: <4FC8BBD9-CAD8-48EA-BAEA-7A3B0E9869AA@virtualized.org>

On Sep 19, 2014, at 2:01 AM, Tony Finch <dot at dotat.at> wrote:
> David Conrad <drc at virtualized.org> wrote:
>> To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or wildcards).
> Wildcards are being used for the name collision gubbins.

Ah, true. Apologies. There is a waiver from that restriction exclusively for the name collision stuff. I believe the waiver expires 90 days after the initial delegation.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140919/f3d635b1/attachment.sig>

From dbrisson at uvm.edu  Fri Sep 19 15:20:35 2014
From: dbrisson at uvm.edu (Dan Brisson)
Date: Fri, 19 Sep 2014 11:20:35 -0400
Subject: Here comes iOS 8...
In-Reply-To: <75545F9B-6403-4F6B-8E76-9D07AFF32E5C@newslink.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
 <541A3ED0.2010700@gmail.com>
 <75545F9B-6403-4F6B-8E76-9D07AFF32E5C@newslink.com>
Message-ID: <541C49C3.70204@uvm.edu>

That's we thought and what we experienced but as the day went on they 
definitely shifted some load to Akamai.

-dan


Dan Brisson
Network Engineer
University of Vermont

On 9/19/2014 10:33 AM, Andy Ringsmuth wrote:
>>>>> ----------------------------------------
>>>>>   From: "Zachary McGibbon" <zachary.mcgibbon+nanog at gmail.com>
>>>>> Sent: Wednesday, September 17, 2014 12:59 PM
>>>>> To: "NANOG" <nanog at nanog.org>
>>>>> Subject: Here comes iOS 8...
>>>>> So Apple is about to release iOS 8... Have you done anything special to
>>>>> your network setup to accommodate the traffic flood ie traffic shaping
>>>>> rules, cache servers, etc?
>>>>>
>>>>> I heard that Apple Caching servers won't work with this update, so I'm
>>>>> guessing it will be pushed through Akamai servers as is usually is.
>>>>>
>>>>> - Zachary
> Interestingly enough, it seems Apple primarily used it's own, new, CDN for the iOS 8 release:
>
> http://appleinsider.com/articles/14/09/18/apple-chose-to-handle-ios-8-rollout-with-own-content-delivery-network
>
> ----
> Andy Ringsmuth
> andy at newslink.com
> News Link ? Manager Technology & Facilities
> 2201 Winthrop Rd., Lincoln, NE 68502-4158
> (402) 475-6397    (402) 304-0083 cellular



From mike at sentex.net  Fri Sep 19 16:03:16 2014
From: mike at sentex.net (Mike Tancsa)
Date: Fri, 19 Sep 2014 12:03:16 -0400
Subject: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet,
 global crossing, XO
In-Reply-To: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
References: <5D7E8D6713A8AA4AB53AF403632BE8260137743FE5@CPEXM01.corp.dsg.local>
Message-ID: <541C53C4.1060504@sentex.net>

On 9/18/2014 4:42 PM, Brock Massel wrote:
> Hi folks,
> I'm hoping someone can shed some light on the situation.
>
> The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some.
>
> Several looking glass' report network not in table.

Which ones ? I see you via just Rogers (AS812). Do you have transit with 
anyone else ?

TATA (AS6453) does not seem to know about you for some reason.  They 
peer directly with Rogers. Perhaps the RADB entries are not there for 
you ?  I think they create their filters based on that.


% whois -h whois.ra.net 192.250.24.0
route:      192.250.24.0/24
descr:      PNAP-ACS inflow route
origin:     AS19294
mnt-by:     MAINT-SGNS
changed:    corey.drake at sungard.com 20070201
source:     RADB

route:          192.250.24.0/23
descr:          Encompass Europe
origin:         AS702
member-of:      RS-UUNETNL
remarks:        -------------------------------------------
remarks:        E-mail is the preferred contact method!
remarks:        -------------------------------------------
remarks:        Please use one of the following addresses:
remarks:        abuse at nl.uu.net   - for abuse notification
remarks:        support at nl.uu.net - for technical questions
remarks:        info at nl.uu.net    - for anything else
remarks:        -------------------------------------------
notify:         ripe-guardian at NL.UU.NET
mnt-by:         AS1890-MNT
mnt-by:         UUNET-MNT
changed:        marcel at eu.uu.net 20011030
source:         RIPE
remarks:        ****************************
remarks:        * THIS OBJECT IS NOT VALID
remarks:        * Please note that all personal data has been removed 
from this object.
remarks:        * To view the original object, please query the RIPE 
Database at:
remarks:        * http://www.ripe.net/whois
remarks:        ****************************

route:        192.250.24.0/24
descr:        Descartes-Inflow-ATL
origin:       AS19294
mnt-by:       ASN-INFLOW-NET
changed:      rdarrow at inflow.com 20040330
source:       SAVVIS



-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/


From baldur.norddahl at gmail.com  Fri Sep 19 17:02:36 2014
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 19 Sep 2014 19:02:36 +0200
Subject: BGP per-flow load balancing between eBGP and iBGP learned prefix
In-Reply-To: <CAEs0Em+0N=aXuUc6aRhmyC9CXkJUgtO85S9AFWq3KhV9UeCaaA@mail.gmail.com>
References: <CAEs0Em+0N=aXuUc6aRhmyC9CXkJUgtO85S9AFWq3KhV9UeCaaA@mail.gmail.com>
Message-ID: <CAPkb-7BD1w9xH15xTUEVxQ2xce+pW-mTsohjU8ps0xX9cGESew@mail.gmail.com>

Hi,

Your problem is that the LB will only deliver traffic to one router. You
then want that router to send half of the traffic to the other router via a
default route. But that is unsound: The other router would be configured
with a similar multipath default route and send half of the traffic right
back to the first router, creating a loop.

You need the routers to be able to deliver traffic to both provider next
hops directly. This can be done by clever use of VLAN or MPLS tunneling.
Let me try to describe the VLAN option:

Put provider link 1 on VLAN 100 and provider link 2 on VLAN 200. Make sure
both routers have access to both VLANs. Make a static host route (/32) on
the router that is not speaking BGP on that VLAN. The host route would
point to the provider next hop on the VLAN. Now you have the same L3
distance to both next hops and multipath routing can do the rest.

Regards,

Baldur




On 16 September 2014 17:33, Andy Litzinger <andy.litzinger.lists at gmail.com>
wrote:

> Hello,
>
> I have a Load Balancer that uses a default route to a VRRP IP hosted
> between two Juniper MX80 routers.  Each MX router has a single BGP feed
> from the same provider and each session is currently receiving only a
> default route.
>
> I'd like to load balance my outbound traffic across the two links.  More
> specifically I want to balance traffic to a particular prefix across the
> two links so even if i was receiving full routes trying to manually split
> prefixes to a second upstream VRRP instance wouldn't help.
>
> I believe the typical way to do this would be to run an IGP between the LB
> and the MX's so that each MX advertises a default route to the LB and let
> ECMP take care of it.  I'm not averse to this long term, but I have a short
> term need and the LB requires a license to participate in an IGP.  Is there
> another way?  I should note that the LB will not let me enter multiple
> default or identical static routes so I can't try spinning up a second VRRP
> session and adding a second default route on the LB to it.
>
> Is it possible to let BGP do the load balancing?  From what I can tell this
> would be trivial if both of the provider links were terminated on the same
> router via a few multipath config lines but because they are on different
> routers I seem to be running into the "eBGP > iBGP" Path selection criteria
> which prevents the routes from being equal.
>
> I appreciate any ideas!
>
> regards,
>  -andy
>


From cscora at apnic.net  Fri Sep 19 18:11:42 2014
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 20 Sep 2014 04:11:42 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201409191811.s8JIBgVH011066@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 20 Sep, 2014

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              511921
    Prefixes after maximum aggregation:                          198473
    Deaggregation factor:                                          2.58
    Unique aggregates announced to Internet:                     251597
Total ASes present in the Internet Routing Table:                 48035
    Prefixes per ASN:                                             10.66
Origin-only ASes present in the Internet Routing Table:           36161
Origin ASes announcing only one prefix:                           16351
Transit ASes present in the Internet Routing Table:                6146
Transit-only ASes present in the Internet Routing Table:            174
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      68
    Max AS path prepend of ASN ( 55644)                              61
Prefixes from unregistered ASNs in the Routing Table:              1700
    Unregistered ASNs in the Routing Table:                         458
Number of 32-bit ASNs allocated by the RIRs:                       7444
Number of 32-bit ASNs visible in the Routing Table:                5728
Prefixes from 32-bit ASNs in the Routing Table:                   20047
Number of bogon 32-bit ASNs visible in the Routing Table:            18
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            355
Number of addresses announced to Internet:                   2709105124
    Equivalent to 161 /8s, 121 /16s and 169 /24s
    Percentage of available address space announced:               73.2
    Percentage of allocated address space announced:               73.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               96.9
Total number of prefixes smaller than registry allocations:      175598

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   125104
    Total APNIC prefixes after maximum aggregation:               36537
    APNIC Deaggregation factor:                                    3.42
Prefixes being announced from the APNIC address blocks:          128815
    Unique aggregates announced from the APNIC address blocks:    52995
APNIC Region origin ASes present in the Internet Routing Table:    4975
    APNIC Prefixes per ASN:                                       25.89
APNIC Region origin ASes announcing only one prefix:               1202
APNIC Region transit ASes present in the Internet Routing Table:    858
Average APNIC Region AS path length visible:                        4.7
    Max APNIC Region AS path length visible:                         68
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1094
Number of APNIC addresses announced to Internet:              734629952
    Equivalent to 43 /8s, 201 /16s and 144 /24s
    Percentage of available APNIC address space announced:         85.9

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 131072-135580
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, 150/8, 153/8,
                       163/8, 171/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:                    170497
    Total ARIN prefixes after maximum aggregation:                85240
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           172517
    Unique aggregates announced from the ARIN address blocks:     80687
ARIN Region origin ASes present in the Internet Routing Table:    16358
    ARIN Prefixes per ASN:                                        10.55
ARIN Region origin ASes announcing only one prefix:                6103
ARIN Region transit ASes present in the Internet Routing Table:    1694
Average ARIN Region AS path length visible:                         3.9
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:     198
Number of ARIN addresses announced to Internet:              1084451232
    Equivalent to 64 /8s, 163 /16s and 105 /24s
    Percentage of available ARIN address space announced:          57.4

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, 62464-63487, 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, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/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:                    124980
    Total RIPE prefixes after maximum aggregation:                63152
    RIPE Deaggregation factor:                                     1.98
Prefixes being announced from the RIPE address blocks:           129955
    Unique aggregates announced from the RIPE address blocks:     82506
RIPE Region origin ASes present in the Internet Routing Table:    17713
    RIPE Prefixes per ASN:                                         7.34
RIPE Region origin ASes announcing only one prefix:                8196
RIPE Region transit ASes present in the Internet Routing Table:    2894
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          32
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3064
Number of RIPE addresses announced to Internet:               658938244
    Equivalent to 39 /8s, 70 /16s and 153 /24s
    Percentage of available RIPE address space announced:          95.8

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
                       59392-61439, 61952-62463, 196608-202239
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,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   59873
    Total LACNIC prefixes after maximum aggregation:              10670
    LACNIC Deaggregation factor:                                   5.61
Prefixes being announced from the LACNIC address blocks:          68111
    Unique aggregates announced from the LACNIC address blocks:   30388
LACNIC Region origin ASes present in the Internet Routing Table:   2316
    LACNIC Prefixes per ASN:                                      29.41
LACNIC Region origin ASes announcing only one prefix:               635
LACNIC Region transit ASes present in the Internet Routing Table:   457
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        26
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1321
Number of LACNIC addresses announced to Internet:             170980736
    Equivalent to 10 /8s, 48 /16s and 245 /24s
    Percentage of available LACNIC address space announced:       101.9

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  11324
    Total AfriNIC prefixes after maximum aggregation:              2828
    AfriNIC Deaggregation factor:                                  4.00
Prefixes being announced from the AfriNIC address blocks:         12168
    Unique aggregates announced from the AfriNIC address blocks:   4716
AfriNIC Region origin ASes present in the Internet Routing Table:   740
    AfriNIC Prefixes per ASN:                                     16.44
AfriNIC Region origin ASes announcing only one prefix:              215
AfriNIC Region transit ASes present in the Internet Routing Table:  156
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:   51
Number of AfriNIC addresses announced to Internet:             59684608
    Equivalent to 3 /8s, 142 /16s and 183 /24s
    Percentage of available AfriNIC address space announced:       59.3

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2938      11591         923   Korea Telecom
17974     2815        900          74   PT Telekomunikasi Indonesia
 7545     2350        336         120   TPG Telecom Limited
 4755     1906        413         192   TATA Communications formerly 
 9829     1641       1306          38   National Internet Backbone
 4808     1398       2228         410   CNCGROUP IP network China169 
 9583     1321        105         542   Sify Limited
 9498     1303        333          91   BHARTI Airtel Ltd.
 9808     1259       6639          15   Guangdong Mobile Communicatio
 7552     1228       1098          14   Viettel Corporation

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     2897       3688          51   BellSouth.net Inc.
22773     2893       2940         142   Cox Communications Inc.
18566     2046        379         178   MegaPath Corporation
 7029     1923       1975         326   Windstream Communications Inc
20115     1787       1771         499   Charter Communications
 4323     1630       1051         408   tw telecom holdings, inc.
30036     1525        320         578   Mediacom Communications Corp
 6983     1503        817         311   ITC^Deltacom
  701     1436      11242         719   MCI Communications Services, 
22561     1308        408         237   CenturyTel Internet Holdings,

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
34984     1815        299         283   TELLCOM ILETISIM HIZMETLERI A
20940     1473        571        1083   Akamai International B.V.
 8402     1422        544          14   OJSC "Vimpelcom"
31148     1042         45          20   Freenet Ltd.
13188     1023         97          44   TOV "Bank-Inform"
 8551      959        371          41   Bezeq International-Ltd
 6849      838        356          26   JSC "Ukrtelecom"
12479      799        798          59   France Telecom Espana SA
 6830      777       2335         432   Liberty Global Operations B.V
 9198      662        346          28   JSC Kazakhtelecom

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
28573     3029       2311         107   NET Servi?os de Comunica??o S
10620     2965        481         251   Telmex Colombia S.A.
18881     2104       1036          22   Global Village Telecom
 6147     1842        374          30   Telefonica del Peru S.A.A.
 7303     1756       1166         233   Telecom Argentina S.A.
 8151     1471       3016         432   Uninet S.A. de C.V.
 6503     1125        434          62   Axtel, S.A.B. de C.V.
 7738      999       1882          41   Telemar Norte Leste S.A.
27947      909        130          51   Telconet S.A
26615      881       2325          35   Tim Celular 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
24863      949        280          26   Link Egypt (Link.NET)
 6713      678        760          38   Office National des Postes et
 8452      559        958          13   TE-AS
36992      341        816          29   ETISALAT MISR
24835      307        144           9   Vodafone Data
 3741      249        920         212   Internet Solutions
29571      242         22          17   Cote d'Ivoire Telecom
37054      232         19           6   Data Telecom Service
15706      186         17           6   Sudatel (Sudan Telecom Co. Lt
12258      174         26          71   MWEB CONNECT (PROPRIETARY) LI

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
28573     3029       2311         107   NET Servi?os de Comunica??o S
10620     2965        481         251   Telmex Colombia S.A.
 4766     2938      11591         923   Korea Telecom
 6389     2897       3688          51   BellSouth.net Inc.
22773     2893       2940         142   Cox Communications Inc.
17974     2815        900          74   PT Telekomunikasi Indonesia
 7545     2350        336         120   TPG Telecom Limited
18881     2104       1036          22   Global Village Telecom
18566     2046        379         178   MegaPath Corporation
 7029     1923       1975         326   Windstream Communications Inc

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 6389      2897        2846      BellSouth.net Inc.
22773      2893        2751      Cox Communications Inc.
17974      2815        2741      PT Telekomunikasi Indonesia
10620      2965        2714      Telmex Colombia S.A.
 7545      2350        2230      TPG Telecom Limited
18881      2104        2082      Global Village Telecom
 4766      2938        2015      Korea Telecom
18566      2046        1868      MegaPath Corporation
 6147      1842        1812      Telefonica del Peru S.A.A.
 4755      1906        1714      TATA Communications formerly 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
20260   UNALLOCATED  8.25.160.0/24         3356       Level 3 Communicatio
20260   UNALLOCATED  8.25.161.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24        12180       Internap Network Ser
46473   UNALLOCATED  8.27.124.0/24        12180       Internap Network Ser
55020   UNALLOCATED  8.30.123.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          6461       Abovenet Communicati
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.100.241.0/24       23456     32bit Transition AS
24.231.96.0/24       21548     MTO Telecom Inc.
27.100.7.0/24        56096     >>UNKNOWN<<
37.16.88.0/23        57652     >>UNKNOWN<<
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.10.0/24        37004     >>UNKNOWN<<
41.73.11.0/24        37004     >>UNKNOWN<<
41.73.12.0/24        37004     >>UNKNOWN<<
41.73.13.0/24        37004     >>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:16       /9:12      /10:31      /11:90      /12:262     
/13:504     /14:998     /15:1714    /16:13030   /17:7089    /18:11782   
/19:24618   /20:35257   /21:37713   /22:54763   /23:48020   /24:273112  
/25:1083    /26:1047    /27:725     /28:14      /29:18      /30:10      
/31:1       /32:12      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2128          2893      Cox Communications Inc.
18566     2001          2046      MegaPath Corporation
 6389     1676          2897      BellSouth.net Inc.
 6147     1404          1842      Telefonica del Peru S.A.A.
30036     1370          1525      Mediacom Communications Corp
 6983     1196          1503      ITC^Deltacom
 7029     1139          1923      Windstream Communications Inc
34984     1136          1815      TELLCOM ILETISIM HIZMETLERI A
11492     1123          1171      CABLE ONE, INC.
 8402     1093          1422      OJSC "Vimpelcom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1334      2:663       3:3         4:18        5:1108      6:21     
   8:754      12:1852     13:4        14:1124     15:17       16:2      
  17:41       18:21       20:51       23:922      24:1753     27:1780   
  31:1415     32:39       33:2        34:5        36:146      37:1781   
  38:992      39:19       40:224      41:2621     42:271      43:372    
  44:16       45:73       46:2166     47:25       49:734      50:804    
  52:12       54:52       55:5        56:6        57:32       58:1219   
  59:661      60:428      61:1713     62:1272     63:1830     64:4409   
  65:2295     66:4200     67:2036     68:1049     69:3282     70:864    
  71:472      72:1996     74:2584     75:372      76:425      77:1605   
  78:852      79:730      80:1323     81:1203     82:786      83:777    
  84:739      85:1326     86:445      87:1164     88:467      89:1754   
  90:136      91:5756     92:767      93:1787     94:1993     95:1299   
  96:432      97:342      98:1150     99:48      100:66      101:724    
 103:5627    104:250     105:135     106:184     107:612     108:572    
 109:1977    110:1034    111:1343    112:718     113:887     114:779    
 115:1213    116:1119    117:1002    118:1569    119:1422    120:437    
 121:971     122:2195    123:1613    124:1435    125:1578    128:612    
 129:348     130:369     131:806     132:431     133:165     134:321    
 135:78      136:299     137:291     138:383     139:204     140:219    
 141:414     142:579     143:445     144:505     145:112     146:685    
 147:558     148:968     149:435     150:494     151:705     152:468    
 153:240     154:348     155:537     156:367     157:328     158:277    
 159:936     160:324     161:602     162:1763    163:356     164:697    
 165:660     166:363     167:681     168:1120    169:123     170:1401   
 171:183     172:61      173:1636    174:712     175:609     176:1495   
 177:3534    178:2083    179:796     180:1767    181:1622    182:1654   
 183:540     184:719     185:2082    186:2966    187:1706    188:2197   
 189:1489    190:7914    191:747     192:7558    193:5512    194:4051   
 195:3583    196:1435    197:657     198:5149    199:5484    200:6508   
 201:2910    202:9156    203:8998    204:4564    205:2654    206:2952   
 207:2935    208:3916    209:3751    210:3303    211:1826    212:2333   
 213:2146    214:861     215:86      216:5685    217:1696    218:614    
 219:394     220:1368    221:687     222:486     223:595    

End of report


From cidr-report at potaroo.net  Fri Sep 19 22:00:00 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 19 Sep 2014 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201409192200.s8JM00o4027130@wattle.apnic.net>

This report has been generated at Fri Sep 19 21:14:16 2014 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/2.0 for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        12-09-14    515908      284438
        13-09-14    516151      284548
        14-09-14    516230      284807
        15-09-14    516654      285229
        16-09-14    516482      285409
        17-09-14    516468      285417
        18-09-14    516715      285921
        19-09-14    517011      286429


AS Summary
         48288  Number of ASes in routing system
         19501  Number of ASes announcing only one prefix
          3030  Largest number of prefixes announced by an AS
                AS28573: NET Servi?os de Comunica??o S.A.,BR
      120100352  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


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').

 --- 19Sep14 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     517308   286326   230982    44.7%   All ASes

AS28573     3030      119     2911    96.1%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS6389      2897      129     2768    95.5%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS22773     2899      161     2738    94.4%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS17974     2815       80     2735    97.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS18881     2104      114     1990    94.6%   Global Village Telecom,BR
AS4766      2939     1203     1736    59.1%   KIXS-AS-KR Korea Telecom,KR
AS6147      1842      167     1675    90.9%   Telefonica del Peru S.A.A.,PE
AS7303      1762      285     1477    83.8%   Telecom Argentina S.A.,AR
AS4755      1904      521     1383    72.6%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS8402      1403       26     1377    98.1%   CORBINA-AS OJSC "Vimpelcom",RU
AS4323      1640      412     1228    74.9%   TWTC - tw telecom holdings,
                                               inc.,US
AS9808      1259       42     1217    96.7%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS20115     1788      573     1215    68.0%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS7552      1263       57     1206    95.5%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS7545      2367     1162     1205    50.9%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS9498      1305      109     1196    91.6%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566     2045      863     1182    57.8%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS10620     2969     1897     1072    36.1%   Telmex Colombia S.A.,CO
AS22561     1308      307     1001    76.5%   AS22561 - CenturyTel Internet
                                               Holdings, Inc.,US
AS7029      2031     1048      983    48.4%   WINDSTREAM - Windstream
                                               Communications Inc,US
AS7738       999       83      916    91.7%   Telemar Norte Leste S.A.,BR
AS6983      1503      629      874    58.2%   ITCDELTA - Earthlink, Inc.,US
AS24560     1173      333      840    71.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services,IN
AS38285      957      133      824    86.1%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS4788      1055      235      820    77.7%   TMNET-AS-AP TM Net, Internet
                                               Service Provider,MY
AS8151      1479      704      775    52.4%   Uninet S.A. de C.V.,MX
AS18101      955      194      761    79.7%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI,IN
AS4780      1029      275      754    73.3%   SEEDNET Digital United Inc.,TW
AS26615      882      130      752    85.3%   Tim Celular S.A.,BR
AS17908      838       92      746    89.0%   TCISL Tata Communications,IN

Total      52440    12083    40357    77.0%   Top 30 total


Possible Bogus Routes

        5.100.241.0/24       AS19957 -Reserved AS-,ZZ
        24.231.96.0/24       AS21548 MTO - MTO Telecom Inc.,CA
        27.100.7.0/24        AS56096 
        31.217.248.0/21      AS44902 COV-ASN COVAGE NETWORKS SASU,FR
        37.16.88.0/23        AS57652 -Reserved AS-,ZZ
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.10.0/24        AS37004 -Reserved AS-,ZZ
        41.73.11.0/24        AS37004 -Reserved AS-,ZZ
        41.73.12.0/24        AS37004 -Reserved AS-,ZZ
        41.73.13.0/24        AS37004 -Reserved AS-,ZZ
        41.73.14.0/24        AS37004 -Reserved AS-,ZZ
        41.73.15.0/24        AS37004 -Reserved AS-,ZZ
        41.73.16.0/24        AS37004 -Reserved AS-,ZZ
        41.73.18.0/24        AS37004 -Reserved AS-,ZZ
        41.73.20.0/24        AS37004 -Reserved AS-,ZZ
        41.73.21.0/24        AS37004 -Reserved AS-,ZZ
        41.76.48.0/21        AS36969 MTL-AS,MW
        41.78.120.0/23       AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US
        41.78.180.0/23       AS37265 -Reserved AS-,ZZ
        41.189.96.0/20       AS37000 -Reserved AS-,ZZ
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -Reserved AS-,ZZ
        41.191.108.0/22      AS37004 -Reserved AS-,ZZ
        41.191.108.0/24      AS37004 -Reserved AS-,ZZ
        41.191.109.0/24      AS37004 -Reserved AS-,ZZ
        41.191.110.0/24      AS37004 -Reserved AS-,ZZ
        41.191.111.0/24      AS37004 -Reserved AS-,ZZ
        41.223.208.0/22      AS37000 -Reserved AS-,ZZ
        62.193.160.0/19      AS24801 -Reserved AS-,ZZ
        62.193.160.0/20      AS24801 -Reserved AS-,ZZ
        62.193.176.0/20      AS24801 -Reserved AS-,ZZ
        64.25.16.0/23        AS19535 -Reserved AS-,ZZ
        64.25.20.0/24        AS19535 -Reserved AS-,ZZ
        64.25.21.0/24        AS19535 -Reserved AS-,ZZ
        64.25.22.0/24        AS19535 -Reserved AS-,ZZ
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US
        64.111.160.0/20      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.160.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.161.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.162.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.167.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.169.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.170.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.171.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.172.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.173.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.174.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.175.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global,US
        66.55.96.0/23        AS17203 -Reserved AS-,ZZ
        66.55.98.0/24        AS17203 -Reserved AS-,ZZ
        66.55.99.0/24        AS17203 -Reserved AS-,ZZ
        66.55.100.0/22       AS17203 -Reserved AS-,ZZ
        66.55.102.0/23       AS17203 -Reserved AS-,ZZ
        66.55.104.0/21       AS17203 -Reserved AS-,ZZ
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation,CA
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.,IT
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        74.112.100.0/22      AS16764 -Reserved AS-,ZZ
        74.113.200.0/23      AS46939 -Reserved AS-,ZZ
        74.114.52.0/22       AS40818 -Reserved AS-,ZZ
        74.114.52.0/23       AS40818 -Reserved AS-,ZZ
        74.114.52.0/24       AS40818 -Reserved AS-,ZZ
        74.114.53.0/24       AS40818 -Reserved AS-,ZZ
        74.114.54.0/23       AS40818 -Reserved AS-,ZZ
        74.114.54.0/24       AS40818 -Reserved AS-,ZZ
        74.114.55.0/24       AS40818 -Reserved AS-,ZZ
        74.114.184.0/22      AS19888 -Reserved AS-,ZZ
        74.118.132.0/22      AS5117  -Reserved AS-,ZZ
        74.120.212.0/23      AS32326 -Reserved AS-,ZZ
        74.120.214.0/23      AS32326 -Reserved AS-,ZZ
        74.121.24.0/22       AS36263 FORONA - Forona Technologies, Inc.,US
        74.123.136.0/21      AS53358 -Reserved AS-,ZZ
        77.243.81.0/24       AS42597 -Reserved AS-,ZZ
        77.243.91.0/24       AS42597 -Reserved AS-,ZZ
        77.243.95.0/24       AS42597 -Reserved AS-,ZZ
        80.78.133.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/23       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.135.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.250.32.0/22       AS37106 ODUA-AS,NG
        85.202.160.0/20      AS44404 -Reserved AS-,ZZ
        89.31.24.0/23        AS41455 -Reserved AS-,ZZ
        89.31.26.0/23        AS41455 -Reserved AS-,ZZ
        89.31.28.0/22        AS41455 -Reserved AS-,ZZ
        91.103.8.0/24        AS42551 -Reserved AS-,ZZ
        91.103.9.0/24        AS42551 -Reserved AS-,ZZ
        91.103.10.0/24       AS42551 -Reserved AS-,ZZ
        91.103.11.0/24       AS42551 -Reserved AS-,ZZ
        91.193.60.0/22       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.195.66.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.197.36.0/22       AS43359 -Reserved AS-,ZZ
        91.199.90.0/24       AS44330 -Reserved AS-,ZZ
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG,DE
        91.220.84.0/24       AS5577  ROOT root SA,LU
        91.220.173.0/24      AS30058 FDCSERVERS - FDCservers.net,US
        91.228.160.0/24      AS19979 DEPO40-AS Trusov Ilya Igorevych,RU
        91.239.157.0/24      AS24958 TBSH The Bunker Secure Hosting Limited,GB
        93.190.10.0/24       AS47254 -Reserved AS-,ZZ
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. ,AU
        103.6.108.0/22       AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN
        103.9.108.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.76.0/22       AS18097 DCN D.C.N. Corporation,JP
        103.18.248.0/22      AS18097 DCN D.C.N. Corporation,JP
        103.19.0.0/22        AS18097 DCN D.C.N. Corporation,JP
        103.20.100.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.20.101.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.21.4.0/22        AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US
        103.26.116.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.228.132.0/22     AS4826  VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.108.0/22     AS13283 
        103.248.220.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.249.8.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.250.0.0/22       AS17676 GIGAINFRA Softbank BB Corp.,JP
        104.193.92.0/24      AS62466 CLEAR-DDOS-AS - ClearDDoS Technologies,CA
        104.193.93.0/24      AS62466 CLEAR-DDOS-AS - ClearDDoS Technologies,CA
        104.193.94.0/24      AS62466 CLEAR-DDOS-AS - ClearDDoS Technologies,CA
        104.193.95.0/24      AS62466 CLEAR-DDOS-AS - ClearDDoS Technologies,CA
        104.193.128.0/22     AS46886 TEKIFY-BROADBAND - Tekify Broadband,US
        104.193.128.0/24     AS46886 TEKIFY-BROADBAND - Tekify Broadband,US
        104.193.129.0/24     AS46886 TEKIFY-BROADBAND - Tekify Broadband,US
        104.193.130.0/24     AS46886 TEKIFY-BROADBAND - Tekify Broadband,US
        104.193.131.0/24     AS46886 TEKIFY-BROADBAND - Tekify Broadband,US
        104.200.160.0/19     AS22552 ESITED - eSited Solutions,US
        104.216.0.0/15       AS40676 AS40676 - Psychz Networks,US
        116.206.72.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.85.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.103.0/24     AS6461  ABOVENET - Abovenet Communications, Inc,US
        117.103.32.0/24      AS23861 
        117.103.33.0/24      AS23861 
        117.103.34.0/24      AS23861 
        117.103.35.0/24      AS23861 
        117.103.36.0/24      AS23861 
        117.103.37.0/24      AS23861 
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street,CN
        124.158.28.0/22      AS45857 
        131.161.132.0/22     AS26229 Sistema Oeste de Servi?os LTDA,BR
        142.147.62.0/24      AS3958  AIRCANADA - Air Canada,CA
        162.210.240.0/21     AS17246 -Reserved AS-,ZZ
        162.210.244.0/24     AS17246 -Reserved AS-,ZZ
        162.210.245.0/24     AS17246 -Reserved AS-,ZZ
        162.210.246.0/24     AS17246 -Reserved AS-,ZZ
        162.210.247.0/24     AS17246 -Reserved AS-,ZZ
        162.244.140.0/22     AS17246 -Reserved AS-,ZZ
        162.244.140.0/24     AS17246 -Reserved AS-,ZZ
        162.244.141.0/24     AS17246 -Reserved AS-,ZZ
        166.93.0.0/16        AS23537 CRITIGEN - Micro Source, Inc.,US
        172.85.0.0/24        AS29571 CITelecom-AS,CI
        172.85.1.0/24        AS29571 CITelecom-AS,CI
        172.85.2.0/24        AS29571 CITelecom-AS,CI
        172.85.3.0/24        AS29571 CITelecom-AS,CI
        172.86.0.0/24        AS29571 CITelecom-AS,CI
        172.86.1.0/24        AS29571 CITelecom-AS,CI
        172.86.2.0/24        AS29571 CITelecom-AS,CI
        172.87.0.0/24        AS29571 CITelecom-AS,CI
        172.88.0.0/24        AS29571 CITelecom-AS,CI
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group),CN
        176.111.168.0/22     AS50586 MACROSOLUTIONS MacroSolution SRL,RO
        182.237.24.0/24      AS55503 
        182.237.25.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        185.28.180.0/22      AS18097 DCN D.C.N. Corporation,JP
        190.124.252.0/22     AS7303  Telecom Argentina S.A.,AR
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US
        192.25.10.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.11.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.13.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.14.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.34.152.0/21      AS10835 VISIONARY - Visionary Communications, Inc.,US
        192.75.23.0/24       AS2579  AS2579 - Alcatel-Lucent,US
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.72.0/24      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.124.252.0/22     AS680   DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE
        192.131.233.0/24     AS7018  ATT-INTERNET4 - AT&T Services, Inc.,US
        192.149.81.0/24      AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US
        192.154.32.0/19      AS81    NCREN - MCNC,US
        192.154.64.0/19      AS81    NCREN - MCNC,US
        192.166.32.0/20      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        192.245.195.0/24     AS7381  SUNGARDRS - SunGard Availability Services LP,US
        193.9.59.0/24        AS1257  TELE2,SE
        193.16.106.0/24      AS31539 -Reserved AS-,ZZ
        193.16.145.0/24      AS31392 -Reserved AS-,ZZ
        193.22.86.0/24       AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI
        193.22.224.0/20      AS3322  -Reserved AS-,ZZ
        193.22.238.0/23      AS62383 LDS-AS Lambrechts Data Services VOF,BE
        193.23.121.0/24      AS29664 RGCOM-VANCO-HAI Reliance Globalcom Limited,GB
        193.26.213.0/24      AS31641 BYTEL-AS Bytel Ltd,GB
        193.28.14.0/24       AS34309 LINK11 Link11 GmbH,DE
        193.33.6.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.33.252.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.53.5.0/24        AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.93.6.0/23        AS35559 SOMEADDRESS Someaddress Networks Ltd,GB
        193.111.229.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.149.2.0/23       AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.178.196.0/22     AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company,JO
        193.200.244.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.201.244.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.245.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.246.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.202.8.0/21       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.202.9.0/24       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.223.103.0/24     AS3248  SIL-AT Tele2 Telecommunication GmbH,AT
        193.227.109.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.227.236.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.0.116.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.0.117.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.6.252.0/24       AS21202 DCSNET-AS Bredband2 AB,SE
        194.9.8.0/23         AS2863  SPRITELINK Centor AB,SE
        194.9.8.0/24         AS2863  SPRITELINK Centor AB,SE
        194.33.11.0/24       AS8943  JUMP Jump Networks Ltd.,GB
        194.39.78.0/23       AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        194.49.17.0/24       AS13135 CREW-AS Wieske's Crew GmbH,DE
        194.50.8.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.60.88.0/21       AS5089  NTL Virgin Media Limited,GB
        194.63.152.0/22      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.79.36.0/22       AS3257  TINET-BACKBONE Tinet SpA,DE
        194.88.6.0/24        AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
        194.88.226.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.99.67.0/24       AS9083  CARPENET carpeNet Information Technologies GmbH,DE
        194.126.152.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.126.219.0/24     AS34545 -Reserved AS-,ZZ
        194.126.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        194.150.214.0/23     AS30880 SPACEDUMP-AS SpaceDump IT AB,SE
        194.156.179.0/24     AS3209  VODANET Vodafone GmbH,DE
        194.180.25.0/24      AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE
        194.187.24.0/22      AS8856  UKRNET UkrNet Ltd,UA
        195.8.48.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.48.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.119.0/24       AS34304 TEENTELECOM Teen Telecom SRL,RO
        195.42.232.0/22      AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        195.85.194.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.85.201.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.110.0.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB,SE
        195.149.119.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.189.174.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA,BE
        195.234.156.0/24     AS25028 -Reserved AS-,ZZ
        195.242.182.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.244.18.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.245.98.0/23      AS48918 GLOBALWAYS GLOBALWAYS AG,DE
        196.3.181.0/24       AS37004 -Reserved AS-,ZZ
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.6.0.0/24         AS32768 routability-tests,MU
        196.22.8.0/24        AS27822 Emerging Markets Communications de Argentina S.R.L,AR
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        196.192.124.0/23     AS37301 AFRINIC-ZA-CPT-AS,MU
        196.216.254.0/24     AS32768 routability-tests,MU
        198.22.195.0/24      AS54583 -Reserved AS-,ZZ
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.,US
        198.74.11.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.13.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.192.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited,CA
        198.163.215.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.163.216.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        198.176.208.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.209.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.210.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.211.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.252.165.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.166.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.167.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.168.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.169.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        199.85.9.0/24        AS852   ASN852 - TELUS Communications Inc.,CA
        199.88.52.0/22       AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US
        199.116.200.0/21     AS22830 -Reserved AS-,ZZ
        199.120.150.0/24     AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        200.1.112.0/24       AS29754 GO2TEL - GO2TEL.COM INC.,US
        200.58.248.0/21      AS27849 
        200.81.48.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        200.81.49.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR
        202.53.138.0/24      AS4058  CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK
        202.58.113.0/24      AS19161 -Reserved AS-,ZZ
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.,IN
        203.142.219.0/24     AS45149 
        203.160.48.0/21      AS38008 
        203.189.116.0/22     AS45606 
        203.189.116.0/24     AS45606 
        203.189.117.0/24     AS45606 
        203.189.118.0/24     AS45606 
        203.189.119.0/24     AS45606 
        204.10.88.0/21       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US
        204.16.96.0/24       AS19972 -Reserved AS-,ZZ
        204.16.97.0/24       AS19972 -Reserved AS-,ZZ
        204.16.98.0/24       AS19972 -Reserved AS-,ZZ
        204.16.99.0/24       AS19972 -Reserved AS-,ZZ
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta,GB
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp,US
        205.166.231.0/24     AS7029  WINDSTREAM - Windstream Communications Inc,US
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network,CA
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US
        206.223.224.0/24     AS21548 MTO - MTO Telecom Inc.,CA
        207.2.120.0/21       AS6221  USCYBERSITES - US Cybersites, Inc,US
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.,US
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.,US
        207.254.128.0/21     AS30689 FLOW-NET - FLOW,JM
        207.254.128.0/24     AS30689 FLOW-NET - FLOW,JM
        207.254.136.0/21     AS30689 FLOW-NET - FLOW,JM
        208.66.64.0/24       AS16936 -Reserved AS-,ZZ
        208.66.65.0/24       AS16936 -Reserved AS-,ZZ
        208.66.66.0/24       AS16936 -Reserved AS-,ZZ
        208.66.67.0/24       AS16936 -Reserved AS-,ZZ
        208.67.132.0/22      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        208.69.192.0/23      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.69.195.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.75.152.0/21      AS32146 -Reserved AS-,ZZ
        208.76.20.0/24       AS31812 -Reserved AS-,ZZ
        208.76.21.0/24       AS31812 -Reserved AS-,ZZ
        208.77.164.0/24      AS22659 -Reserved AS-,ZZ
        208.77.166.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC,US
        208.84.232.0/24      AS33131 -Reserved AS-,ZZ
        208.84.234.0/24      AS33131 -Reserved AS-,ZZ
        208.84.237.0/24      AS33131 -Reserved AS-,ZZ
        208.84.238.0/24      AS33131 -Reserved AS-,ZZ
        208.94.216.0/23      AS13629 -Reserved AS-,ZZ
        208.94.219.0/24      AS13629 -Reserved AS-,ZZ
        208.94.221.0/24      AS13629 -Reserved AS-,ZZ
        208.94.223.0/24      AS13629 -Reserved AS-,ZZ
        209.135.171.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.135.175.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.177.64.0/20      AS6461  ABOVENET - Abovenet Communications, Inc,US
        209.193.112.0/20     AS209   ASN-QWEST - Qwest Communications Company, LLC,US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US
        209.209.224.0/19     AS19513 -Reserved AS-,ZZ
        209.209.248.0/23     AS19513 -Reserved AS-,ZZ
        209.209.250.0/23     AS19513 -Reserved AS-,ZZ
        209.209.251.0/24     AS19513 -Reserved AS-,ZZ
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US
        209.234.112.0/23     AS32252 -Reserved AS-,ZZ
        209.234.114.0/23     AS32252 -Reserved AS-,ZZ
        209.234.116.0/24     AS32252 -Reserved AS-,ZZ
        209.234.117.0/24     AS32252 -Reserved AS-,ZZ
        209.234.118.0/24     AS32252 -Reserved AS-,ZZ
        209.234.119.0/24     AS32252 -Reserved AS-,ZZ
        209.234.120.0/24     AS32252 -Reserved AS-,ZZ
        209.234.121.0/24     AS32252 -Reserved AS-,ZZ
        209.234.122.0/24     AS32252 -Reserved AS-,ZZ
        213.255.128.0/20     AS24863 LINKdotNET-AS,EG
        213.255.144.0/20     AS24863 LINKdotNET-AS,EG
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.,US
        216.146.0.0/19       AS11915 US-TELEPACIFIC - TelePacific Communications,US
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US
        216.251.50.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN
        216.251.53.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN
        216.251.62.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN


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 cidr-report at potaroo.net  Fri Sep 19 22:00:01 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 19 Sep 2014 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201409192200.s8JM01fQ027143@wattle.apnic.net>

BGP Update Report
Interval: 11-Sep-14 -to- 18-Sep-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS166            409955  9.2%   81991.0 -- IDA-AS - Institute for Defense Analyses,US
 2 - AS23752          191535  4.3%    1915.3 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 3 - AS9829           135822  3.0%     127.5 -- BSNL-NIB National Internet Backbone,IN
 4 - AS22646           80061  1.8%     563.8 -- HARCOM1 - Hargray Communications Group, Inc.,US
 5 - AS17974           65371  1.5%      23.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID
 6 - AS28573           58834  1.3%      18.3 -- NET Servi?os de Comunica??o S.A.,BR
 7 - AS8402            52541  1.2%      99.5 -- CORBINA-AS OJSC "Vimpelcom",RU
 8 - AS45899           50440  1.1%     102.7 -- VNPT-AS-VN VNPT Corp,VN
 9 - AS1659            47246  1.1%    1027.1 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
10 - AS8151            37288  0.8%      29.3 -- Uninet S.A. de C.V.,MX
11 - AS7545            36135  0.8%      20.2 -- TPG-INTERNET-AP TPG Telecom Limited,AU
12 - AS37457           33799  0.8%      39.5 -- Telkom-Internet,ZA
13 - AS25184           27350  0.6%     217.1 -- AFRANET AFRANET Co. Tehran, Iran,IR
14 - AS27047           24662  0.6%     456.7 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center,US
15 - AS34154           23665  0.5%    4733.0 -- CONFIGO-AS Configo Systems Gesellschaft fuer Systemloesungen mbH,DE
16 - AS3816            22462  0.5%      34.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO
17 - AS7018            21502  0.5%      17.5 -- ATT-INTERNET4 - AT&T Services, Inc.,US
18 - AS23342           21260  0.5%     545.1 -- UNITEDLAYER - Unitedlayer, Inc.,US
19 - AS647             20291  0.5%     143.9 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US
20 - AS25003           19979  0.5%     740.0 -- INTERNET_BINAT Internet Binat Ltd,IL


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS166            409955  9.2%   81991.0 -- IDA-AS - Institute for Defense Analyses,US
 2 - AS32336           10960  0.2%   10960.0 -- IPASS-2 - iPass Incorporated,US
 3 - AS6629            10648  0.2%   10648.0 -- NOAA-AS - NOAA,US
 4 - AS46150            9107  0.2%    9107.0 -- SNHU - Southern New Hampshire University,US
 5 - AS6459            13446  0.3%    6723.0 -- TRANSBEAM - I-2000, Inc.,US
 6 - AS34154           23665  0.5%    4733.0 -- CONFIGO-AS Configo Systems Gesellschaft fuer Systemloesungen mbH,DE
 7 - AS37620            4139  0.1%    4139.0 -- VIETTEL-CM-AS,CM
 8 - AS26661           10543  0.2%    3514.3 -- JCPS-ASN - Jeffco Public Schools,US
 9 - AS62174            3020  0.1%    3020.0 -- INTERPAN-AS INTERPAN LTD.,BG
10 - AS5               15853  0.4%       7.0 -- SYMBOLICS - Symbolics, Inc.,US
11 - AS2                9322  0.2%    2129.0 -- UDEL-DCN - University of Delaware,US
12 - AS35093            4218  0.1%    2109.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
13 - AS33643            1998  0.0%    1998.0 -- JELLYBELLY - Jelly Belly Candy Company,US
14 - AS23752          191535  4.3%    1915.3 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
15 - AS21732            5257  0.1%    1752.3 -- FLAVORUS-ASN - Flavorus Inc,US
16 - AS3                1733  0.0%    5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US
17 - AS30944            1554  0.0%    1554.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT
18 - AS18135           10850  0.2%    1550.0 -- BTV BTV Cable television,JP
19 - AS41452            1505  0.0%    1505.0 -- ZGAIR-AS Zracna luka Zagreb d.o.o.,HR
20 - AS23295            1369  0.0%    1369.0 -- EA-01 - Extend America,US


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 129.246.0.0/16   149760  3.2%   AS166   -- IDA-AS - Institute for Defense Analyses,US
 2 - 129.246.250.0/24 130195  2.8%   AS166   -- IDA-AS - Institute for Defense Analyses,US
 3 - 129.246.218.0/24 129992  2.8%   AS166   -- IDA-AS - Institute for Defense Analyses,US
 4 - 202.70.64.0/21    95312  2.0%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 5 - 202.70.88.0/21    95131  2.0%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 6 - 46.53.64.0/19     26402  0.6%   AS24814 -- SCS-AS Syrian Computer Society, scs,SY
                                     AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY
 7 - 217.71.221.0/24   23651  0.5%   AS34154 -- CONFIGO-AS Configo Systems Gesellschaft fuer Systemloesungen mbH,DE
 8 - 64.29.130.0/24    21222  0.5%   AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US
 9 - 192.115.44.0/22   19857  0.4%   AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL
10 - 205.247.12.0/24   13436  0.3%   AS6459  -- TRANSBEAM - I-2000, Inc.,US
11 - 200.34.149.0/24   12446  0.3%   AS8151  -- Uninet S.A. de C.V.,MX
12 - 216.231.194.0/24  10960  0.2%   AS32336 -- IPASS-2 - iPass Incorporated,US
13 - 42.83.48.0/20     10838  0.2%   AS18135 -- BTV BTV Cable television,JP
14 - 192.58.232.0/24   10648  0.2%   AS6629  -- NOAA-AS - NOAA,US
15 - 112.215.16.0/24   10100  0.2%   AS24203 -- NAPXLNET-AS-ID PT Excelcomindo Pratama (Network Access Provider),ID
16 - 64.223.206.0/24    9107  0.2%   AS46150 -- SNHU - Southern New Hampshire University,US
17 - 198.58.74.0/24     8542  0.2%   AS20013 -- CYRUSONE - CyrusOne LLC,US
18 - 196.43.159.0/24    7888  0.2%   AS5     -- SYMBOLICS - Symbolics, Inc.,US
19 - 196.43.132.0/22    7882  0.2%   AS5     -- SYMBOLICS - Symbolics, Inc.,US
20 - 163.15.192.0/24    7836  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW

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 danm at prime.gushi.org  Fri Sep 19 23:44:04 2014
From: danm at prime.gushi.org (Dan Mahoney, System Admin)
Date: Fri, 19 Sep 2014 16:44:04 -0700 (PDT)
Subject: Paging Level3 Mail Admins: Your messagelabs config is broken
Message-ID: <alpine.BSF.2.00.1409191638320.72555@prime.gushi.org>

Note: sending this from my personal account to increase odds of someone 
seeing it.  My work address is dmahoney at isc.org.

ISC is having trouble mailing noc at level3.net, we keep getting redirected 
to a messagelabs error, seems to be happening from any address we send 
from, including personal addresses and the (sender/envelope) address of 
our ticket system.

This is probably nonoptimal.

You can reach me voice at 650-423-1362, or our noc number at 650-423-1310.

Final-Recipient: rfc822; noc at Level3.net
Original-Recipient: rfc822;noc at Level3.net
Action: failed
Status: 5.0.0
Remote-MTA: dns; cluster5.us.messagelabs.com
Diagnostic-Code: smtp; 553-Sorry, your email address jtl at isc.org has been
553-blacklisted. Refer to the Troubleshooting page at
553-http://www.symanteccloud.com/troubleshooting for more 553
information.
(#5.7.1)

Sep 19 23:32:58 amstel postfix/smtp[93402]: ED44E1FCBC3: 
to=<noc at Level3.net>, relay=cluster5.us.messagelabs.com[216.82.250.51]:25, 
delay=6.6, delays=1.4/0/5.1/0.16, dsn=5.0.0, status=bounced (host 
cluster5.us.messagelabs.com[216.82.250.51] said: 553-Sorry, your email 
address dmahoney at isc.org has been 553-blacklisted. Refer to the 
Troubleshooting page at 553-http://www.symanteccloud.com/troubleshooting 
for more 553 information. (#5.7.1) (in reply to RCPT TO command))

-Dan Mahoney
(hat: isc.org operations group).

-- 




From asr at latency.net  Sat Sep 20 00:03:04 2014
From: asr at latency.net (Adam Rothschild)
Date: Fri, 19 Sep 2014 20:03:04 -0400
Subject: Here comes iOS 8...
In-Reply-To: <75545F9B-6403-4F6B-8E76-9D07AFF32E5C@newslink.com>
References: <CAJdNregZGgm9mTLxueVnTQ0KEQzdTJrMK12xvqQBiGVwEr=ndA@mail.gmail.com>
 <fccfceef31ee4a8c99e72f25dbbe7582@flhsi.com>
 <CAPiURgUiey_aJA94vHrXVK-DyC26Oods+YfqbYtM6YEZkj+FUg@mail.gmail.com>
 <CAAXNyuBTDd_E9=24roDf3wbLohuy+QvNeeko9+1FFA51MtbxvQ@mail.gmail.com>
 <541A3ED0.2010700@gmail.com>
 <75545F9B-6403-4F6B-8E76-9D07AFF32E5C@newslink.com>
Message-ID: <CAPZUUwVUeSHJFOiSaEK-jQR4kaaF35X+OQmdYo54aHKKk5S6=Q@mail.gmail.com>

On Fri, Sep 19, 2014 at 10:33 AM, Andy Ringsmuth <andy at newslink.com> wrote:
[...]
> Interestingly enough, it seems Apple primarily used it's own, new, CDN for the iOS 8 release:
>
> http://appleinsider.com/articles/14/09/18/apple-chose-to-handle-ios-8-rollout-with-own-content-delivery-network

I noticed same.  Moreover, Apple appears to be reaching 701 over
3356/174 in my neck of the woods, which is not the wisest move, due to
congestion, and thus painstakingly slow transfer speeds.

Null routing 17.253.0.0/16 caused downloads to fall back to Akamai,
where performance was quite snappy.

(I'm not saying this is a good idea, or recommended at scale -- just
sharing my observations.)

FWIW,
-a


From randy at psg.com  Sat Sep 20 04:32:46 2014
From: randy at psg.com (Randy Bush)
Date: Sat, 20 Sep 2014 13:32:46 +0900
Subject: internet governance, rir policy, and the decline of civilization
Message-ID: <m2wq8y6he9.wl%randy@psg.com>

http://mailman.apnic.net/mailing-lists/sig-policy/archive/2014/09/msg00049.html


From saku at ytti.fi  Sat Sep 20 07:56:02 2014
From: saku at ytti.fi (Saku Ytti)
Date: Sat, 20 Sep 2014 10:56:02 +0300
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <m2wq8y6he9.wl%randy@psg.com>
References: <m2wq8y6he9.wl%randy@psg.com>
Message-ID: <20140920075602.GA22750@pob.ytti.fi>

On (2014-09-20 13:32 +0900), Randy Bush wrote:

> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2014/09/msg00049.html

Interesting quote from the paper.

I've sometimes wondered if RIR's do too much, if there is inherent mission
creep to justify increasing revenue due to increasing member base.

While it is often useful to the community and at least mostly harmless, it may
reduce competition in areas that are not strictly needed to be monopolized.

I believe monopolies are good for many things, but the scope of each monopoly
should be well defined and no mission creep should be allowed.
I'm not sure for example, if 11MEUR is needed for number registry personnel
costs, that could give you 100 hostmasters with 5500EUR/month salary, in good
likelihood, we'd be able to run focused number registry with volunteers.
Inside monopoly, there is always honest belief that you are operating as
leanly as you can, because usually no organization realizes their
inefficiencies until they must to survive.

-- 
  ++ytti


From matthew at corp.crocker.com  Sat Sep 20 14:18:43 2014
From: matthew at corp.crocker.com (Matthew Crocker)
Date: Sat, 20 Sep 2014 10:18:43 -0400
Subject: Saying goodnight to my GSR
Message-ID: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>


Has been running for a while, time to shut ?er down.   She (is a router a she?) used to handle all of my BGP GigE links but over the years has been demoted to OSPF and T1 aggregation.

If anyone needs a boat anchor let me know.

gsr8-1#show version 
Cisco Internetwork Operating System Software 
IOS (tm) GS Software (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Thu 30-Jun-05 18:29 by pwade
Image text-base: 0x50010E80, data-base: 0x536E8000

ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2] RELEASE SOFTWARE

 gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes
Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005
System image file is "slot0:gsr-p-mz.120-30.S3.bin"

cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on

2 Route Processor Cards
2 Clock Scheduler Cards
3 Switch Fabric Cards
2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2 GigabitEthernet).
1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet).
1 Ethernet/IEEE 802.3 interface(s)
5 GigabitEthernet/IEEE 802.3 interface(s)
507K bytes of non-volatile configuration memory.

20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matthew at crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com






From jeroen at massar.ch  Sat Sep 20 14:39:35 2014
From: jeroen at massar.ch (Jeroen Massar)
Date: Sat, 20 Sep 2014 16:39:35 +0200
Subject: Saying goodnight to my GSR
In-Reply-To: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
Message-ID: <541D91A7.6080200@massar.ch>

On 2014-09-20 16:18, Matthew Crocker wrote:
[..]
> IOS (tm) GS Software (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2)
[..]
>  gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes

Thank you for finally taking a vulnerable system of the Internet!

Greets,
 Jeroen



From james.cutler at consultant.com  Sat Sep 20 14:56:51 2014
From: james.cutler at consultant.com (James R Cutler)
Date: Sat, 20 Sep 2014 10:56:51 -0400
Subject: Saying goodnight to my GSR
In-Reply-To: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
Message-ID: <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>

On Sep 20, 2014, at 10:18 AM, Matthew Crocker <matthew at corp.crocker.com> wrote about his old router:

> <SNIP/>
> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes
> Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
> System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005
> <SNIP/>

Matt,

Wow.  You have amazing power reliability!

Want to tell us your secret?

Regards.

James R. Cutler
James.cutler at consultant.com
PGP keys at http://pgp.mit.edu



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140920/81e676a6/attachment.sig>

From matthew at corp.crocker.com  Sat Sep 20 17:09:54 2014
From: matthew at corp.crocker.com (Matthew S. Crocker)
Date: Sat, 20 Sep 2014 13:09:54 -0400 (EDT)
Subject: Saying goodnight to my GSR
In-Reply-To: <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
Message-ID: <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>

-48VDC. 



> On Sep 20, 2014, at 10:58 AM, James R Cutler <james.cutler at consultant.com> wrote:
> 
> On Sep 20, 2014, at 10:18 AM, Matthew Crocker <matthew at corp.crocker.com> wrote about his old router:
> 
>> <SNIP/>
>> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes
>> Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
>> System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005
>> <SNIP/>
> 
> Matt,
> 
> Wow.  You have amazing power reliability!
> 
> Want to tell us your secret?
> 
> Regards.
> 
> James R. Cutler
> James.cutler at consultant.com
> PGP keys at http://pgp.mit.edu
> 
> 
> 



From baconzombie at gmail.com  Sat Sep 20 17:37:31 2014
From: baconzombie at gmail.com (Bacon Zombie)
Date: Sat, 20 Sep 2014 19:37:31 +0200
Subject: Saying goodnight to my GSR
In-Reply-To: <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
Message-ID: <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>

So when was the last time you patched this internet facing device?
On Sep 20, 2014 7:12 PM, "Matthew S. Crocker" <matthew at corp.crocker.com>
wrote:

> -48VDC.
>
>
>
> > On Sep 20, 2014, at 10:58 AM, James R Cutler <
> james.cutler at consultant.com> wrote:
> >
> > On Sep 20, 2014, at 10:18 AM, Matthew Crocker <matthew at corp.crocker.com>
> wrote about his old router:
> >
> >> <SNIP/>
> >> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes
> >> Uptime for this control processor is 9 years, 2 weeks, 2 days, 18
> minutes
> >> System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6
> 2005
> >> <SNIP/>
> >
> > Matt,
> >
> > Wow.  You have amazing power reliability!
> >
> > Want to tell us your secret?
> >
> > Regards.
> >
> > James R. Cutler
> > James.cutler at consultant.com
> > PGP keys at http://pgp.mit.edu
> >
> >
> >
>
>


From baconzombie at gmail.com  Sat Sep 20 17:59:26 2014
From: baconzombie at gmail.com (Bacon Zombie)
Date: Sat, 20 Sep 2014 19:59:26 +0200
Subject: Saying goodnight to my GSR
In-Reply-To: <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
 <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
 <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>
Message-ID: <CAPz7E51FuePOJ6QrOcMeG+UzDY4ePi00c6X2qwPuk=qPUv7Bvg@mail.gmail.com>

OK thank you for decommissioning this.*

* Only if you either had authority to do so for max 1 year or had no
authority but were fighting to have it patches or replaced for years.
On Sep 20, 2014 7:54 PM, "Daniel Sterling" <sterling.daniel at gmail.com>
wrote:

> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com>
> wrote:
>
> > So when was the last time you patched this internet facing device?
>
> Isn't the better response, thank you for decommissioning it?
>
> Can someone from cisco set up a poll or release whatever numbers they
> have about how many of these old devices are still in service?
>
> Thanks,
> Dan
>


From joelja at bogus.com  Sat Sep 20 18:01:44 2014
From: joelja at bogus.com (Joel Jaeggli)
Date: Sat, 20 Sep 2014 11:01:44 -0700
Subject: Saying goodnight to my GSR
In-Reply-To: <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
 <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
Message-ID: <9F09D4F9-38BC-4B66-ABE1-A2F4B9F8A9C1@bogus.com>



> On Sep 20, 2014, at 10:37, Bacon Zombie <baconzombie at gmail.com> wrote:
> 
> So when was the last time you patched this internet facing device?

Sunday sept 4 2005?

Seems like a good run. If it hasn't been rooted or fallen over since then it's apparently pretty secure...

> On Sep 20, 2014 7:12 PM, "Matthew S. Crocker" <matthew at corp.crocker.com>
> wrote:
> 
>> -48VDC.
>> 
>> 
>> 
>>>> On Sep 20, 2014, at 10:58 AM, James R Cutler <
>>> james.cutler at consultant.com> wrote:
>>> 
>>> On Sep 20, 2014, at 10:18 AM, Matthew Crocker <matthew at corp.crocker.com>
>> wrote about his old router:
>>> 
>>>> <SNIP/>
>>>> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes
>>>> Uptime for this control processor is 9 years, 2 weeks, 2 days, 18
>> minutes
>>>> System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6
>> 2005
>>>> <SNIP/>
>>> 
>>> Matt,
>>> 
>>> Wow.  You have amazing power reliability!
>>> 
>>> Want to tell us your secret?
>>> 
>>> Regards.
>>> 
>>> James R. Cutler
>>> James.cutler at consultant.com
>>> PGP keys at http://pgp.mit.edu
> 


From bzs at world.std.com  Sat Sep 20 18:18:42 2014
From: bzs at world.std.com (Barry Shein)
Date: Sat, 20 Sep 2014 14:18:42 -0400
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <m2wq8y6he9.wl%randy@psg.com>
References: <m2wq8y6he9.wl%randy@psg.com>
Message-ID: <21533.50434.408121.474090@world.std.com>


Quis custodiet ipsos custodes?

  -b


From sterling.daniel at gmail.com  Sat Sep 20 17:54:30 2014
From: sterling.daniel at gmail.com (Daniel Sterling)
Date: Sat, 20 Sep 2014 13:54:30 -0400
Subject: Saying goodnight to my GSR
In-Reply-To: <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
 <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
Message-ID: <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>

On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com> wrote:

> So when was the last time you patched this internet facing device?

Isn't the better response, thank you for decommissioning it?

Can someone from cisco set up a poll or release whatever numbers they
have about how many of these old devices are still in service?

Thanks,
Dan


From sterling.daniel at gmail.com  Sat Sep 20 18:05:56 2014
From: sterling.daniel at gmail.com (Daniel Sterling)
Date: Sat, 20 Sep 2014 14:05:56 -0400
Subject: Saying goodnight to my GSR
In-Reply-To: <CAPz7E51FuePOJ6QrOcMeG+UzDY4ePi00c6X2qwPuk=qPUv7Bvg@mail.gmail.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
 <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
 <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>
 <CAPz7E51FuePOJ6QrOcMeG+UzDY4ePi00c6X2qwPuk=qPUv7Bvg@mail.gmail.com>
Message-ID: <CAJZMiudXOB8yEzgWksCVj_+=twDdypd-3_Qczt0xqCzhdQSJiQ@mail.gmail.com>

Again, you're focusing resentment towards someone who did the right
thing. Negative reinforcement will discourage others from taking
action and will discourage them from encouraging others to take
action.

Let's focus on who still has vulnerable equipment and how to help
them. Let's not shame people who did the right thing

Thanks,
Dan


On Sat, Sep 20, 2014 at 1:59 PM, Bacon Zombie <baconzombie at gmail.com> wrote:
> OK thank you for decommissioning this.*
>
> * Only if you either had authority to do so for max 1 year or had no
> authority but were fighting to have it patches or replaced for years.
> On Sep 20, 2014 7:54 PM, "Daniel Sterling" <sterling.daniel at gmail.com>
> wrote:
>
>> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com>
>> wrote:
>>
>> > So when was the last time you patched this internet facing device?
>>
>> Isn't the better response, thank you for decommissioning it?
>>
>> Can someone from cisco set up a poll or release whatever numbers they
>> have about how many of these old devices are still in service?
>>
>> Thanks,
>> Dan
>>


From jared at puck.nether.net  Sat Sep 20 19:26:04 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 20 Sep 2014 15:26:04 -0400
Subject: Saying goodnight to my GSR
In-Reply-To: <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
 <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
 <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>
Message-ID: <54E2C1FC-54AD-4606-8F8D-A78FB28C1827@puck.nether.net>


> On Sep 20, 2014, at 1:54 PM, Daniel Sterling <sterling.daniel at gmail.com> wrote:
> 
> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com> wrote:
> 
>> So when was the last time you patched this internet facing device?
> 
> Isn't the better response, thank you for decommissioning it?
> 
> Can someone from cisco set up a poll or release whatever numbers they
> have about how many of these old devices are still in service?

OpenSNMPProject has some of this data for devices that respond to the string ?public?.

Lots of old stuff out there.

- Jared

From kmedcalf at dessus.com  Sat Sep 20 20:25:40 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 20 Sep 2014 14:25:40 -0600
Subject: Saying goodnight to my GSR
In-Reply-To: <CAJZMiudXOB8yEzgWksCVj_+=twDdypd-3_Qczt0xqCzhdQSJiQ@mail.gmail.com>
Message-ID: <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>


And what, exactly, is it vulnerable to?

>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Sterling
>Sent: Saturday, 20 September, 2014 12:06
>To: Bacon Zombie
>Cc: nanog at nanog.org
>Subject: Re: Saying goodnight to my GSR
>
>Again, you're focusing resentment towards someone who did the right
>thing. Negative reinforcement will discourage others from taking
>action and will discourage them from encouraging others to take
>action.
>
>Let's focus on who still has vulnerable equipment and how to help
>them. Let's not shame people who did the right thing
>
>Thanks,
>Dan
>
>
>On Sat, Sep 20, 2014 at 1:59 PM, Bacon Zombie <baconzombie at gmail.com>
>wrote:
>> OK thank you for decommissioning this.*
>>
>> * Only if you either had authority to do so for max 1 year or had no
>> authority but were fighting to have it patches or replaced for years.
>> On Sep 20, 2014 7:54 PM, "Daniel Sterling" <sterling.daniel at gmail.com>
>> wrote:
>>
>>> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com>
>>> wrote:
>>>
>>> > So when was the last time you patched this internet facing device?
>>>
>>> Isn't the better response, thank you for decommissioning it?
>>>
>>> Can someone from cisco set up a poll or release whatever numbers they
>>> have about how many of these old devices are still in service?
>>>
>>> Thanks,
>>> Dan
>>>





From ruairi.carroll at gmail.com  Sat Sep 20 20:56:37 2014
From: ruairi.carroll at gmail.com (Ruairi Carroll)
Date: Sat, 20 Sep 2014 14:56:37 -0600
Subject: Saying goodnight to my GSR
In-Reply-To: <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
References: <CAJZMiudXOB8yEzgWksCVj_+=twDdypd-3_Qczt0xqCzhdQSJiQ@mail.gmail.com>
 <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
Message-ID: <CANdN9jb1S+ejYDnWXiO7xKYrT_UsUvdvw73doa5Dr2ZD0CxcRw@mail.gmail.com>

> And what, exactly, is it vulnerable to?

Most of these, I'd imagine:
http://www.cisco.com/c/en/us/td/docs/ios/12_0s/release/ntes/120SCAVS.html


On 20 September 2014 14:25, Keith Medcalf <kmedcalf at dessus.com> wrote:

>
> And what, exactly, is it vulnerable to?
>
> >-----Original Message-----
> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Sterling
> >Sent: Saturday, 20 September, 2014 12:06
> >To: Bacon Zombie
> >Cc: nanog at nanog.org
> >Subject: Re: Saying goodnight to my GSR
> >
> >Again, you're focusing resentment towards someone who did the right
> >thing. Negative reinforcement will discourage others from taking
> >action and will discourage them from encouraging others to take
> >action.
> >
> >Let's focus on who still has vulnerable equipment and how to help
> >them. Let's not shame people who did the right thing
> >
> >Thanks,
> >Dan
> >
> >
> >On Sat, Sep 20, 2014 at 1:59 PM, Bacon Zombie <baconzombie at gmail.com>
> >wrote:
> >> OK thank you for decommissioning this.*
> >>
> >> * Only if you either had authority to do so for max 1 year or had no
> >> authority but were fighting to have it patches or replaced for years.
> >> On Sep 20, 2014 7:54 PM, "Daniel Sterling" <sterling.daniel at gmail.com>
> >> wrote:
> >>
> >>> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com>
> >>> wrote:
> >>>
> >>> > So when was the last time you patched this internet facing device?
> >>>
> >>> Isn't the better response, thank you for decommissioning it?
> >>>
> >>> Can someone from cisco set up a poll or release whatever numbers they
> >>> have about how many of these old devices are still in service?
> >>>
> >>> Thanks,
> >>> Dan
> >>>
>
>
>
>


From saku at ytti.fi  Sat Sep 20 21:04:16 2014
From: saku at ytti.fi (Saku Ytti)
Date: Sun, 21 Sep 2014 00:04:16 +0300
Subject: Saying goodnight to my GSR
In-Reply-To: <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
References: <CAJZMiudXOB8yEzgWksCVj_+=twDdypd-3_Qczt0xqCzhdQSJiQ@mail.gmail.com>
 <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
Message-ID: <20140920210416.GA10252@pob.ytti.fi>

On (2014-09-20 14:25 -0600), Keith Medcalf wrote:

> And what, exactly, is it vulnerable to?

Fair question. Felix Lindner has shown some ~0 budget attacks on IOS. But I'm
not sure if there actually are known attack vectors for properly secured
system (iACL, rACL in this case)
Crash bugs are there probably, but those are likely in every release and some
motivation + lab time might yield success DoS attack on platform, and if
you're L2 connected to a router, most are DoSable anyhow, regardless of
version.

Personally, I wouldn't be too worried about this. If I were, I wouldn't dare
to run any commercially or otherwise available networking operating system,
they all have terrible history in terms of software reliability against
attacks.
But there appears to be no actual business-case for security, if we look at
fortune500 companies who have been thoroughly pwned, it has not impacted their
market cap. Public sector, including military are happy to buy 'audited'
network connection from commercial companies running commercial systems, which
all certainly are pwnable with extremely modest budget, regardless how new
release they are running.

-- 
  ++ytti


From kmedcalf at dessus.com  Sat Sep 20 21:17:17 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 20 Sep 2014 15:17:17 -0600
Subject: Saying goodnight to my GSR
In-Reply-To: <CANdN9jb1S+ejYDnWXiO7xKYrT_UsUvdvw73doa5Dr2ZD0CxcRw@mail.gmail.com>
Message-ID: <dd1f97d046192e489d8afb47ef75ff9f@mail.dessus.com>


I do not see any vulnerabilities listed there.  Only documentation of behavioral bugs, caveats, and restrictions.

A "vulnerability" would be something like the one Microsoft introduced into all versions of the Windows IP stack after Windows 2003 and Windows XP wherein "the Operating System will execute the payload of an IP packet with SYSTEM authority and SYSTEM integrity when a crafted IP packet is received in which a certain combination of invalid and reserved header bits are set".

>-----Original Message-----
>From: Ruairi Carroll [mailto:ruairi.carroll at gmail.com]
>Sent: Saturday, 20 September, 2014 14:57
>To: Keith Medcalf
>Cc: Daniel Sterling; Bacon Zombie; nanog at nanog.org
>Subject: Re: Saying goodnight to my GSR
>
>> And what, exactly, is it vulnerable to?
>
>Most of these, I'd imagine:
>http://www.cisco.com/c/en/us/td/docs/ios/12_0s/release/ntes/120SCAVS.html
>
>
>On 20 September 2014 14:25, Keith Medcalf <kmedcalf at dessus.com> wrote:
>
>
>
>	And what, exactly, is it vulnerable to?
>
>
>	>-----Original Message-----
>	>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel
>Sterling
>	>Sent: Saturday, 20 September, 2014 12:06
>	>To: Bacon Zombie
>	>Cc: nanog at nanog.org
>	>Subject: Re: Saying goodnight to my GSR
>	>
>	>Again, you're focusing resentment towards someone who did the right
>	>thing. Negative reinforcement will discourage others from taking
>	>action and will discourage them from encouraging others to take
>	>action.
>	>
>	>Let's focus on who still has vulnerable equipment and how to help
>	>them. Let's not shame people who did the right thing
>	>
>	>Thanks,
>	>Dan
>	>
>	>
>	>On Sat, Sep 20, 2014 at 1:59 PM, Bacon Zombie
><baconzombie at gmail.com>
>	>wrote:
>	>> OK thank you for decommissioning this.*
>	>>
>	>> * Only if you either had authority to do so for max 1 year or had
>no
>	>> authority but were fighting to have it patches or replaced for
>years.
>	>> On Sep 20, 2014 7:54 PM, "Daniel Sterling"
><sterling.daniel at gmail.com>
>	>> wrote:
>	>>
>	>>> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie
><baconzombie at gmail.com>
>	>>> wrote:
>	>>>
>	>>> > So when was the last time you patched this internet facing
>device?
>	>>>
>	>>> Isn't the better response, thank you for decommissioning it?
>	>>>
>	>>> Can someone from cisco set up a poll or release whatever numbers
>they
>	>>> have about how many of these old devices are still in service?
>	>>>
>	>>> Thanks,
>	>>> Dan
>	>>>
>
>
>
>
>






From jra at baylink.com  Sat Sep 20 22:05:42 2014
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 20 Sep 2014 18:05:42 -0400 (EDT)
Subject: Saying goodnight to my GSR
In-Reply-To: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
Message-ID: <783904.2592.1411250742448.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Matthew Crocker" <matthew at corp.crocker.com>

> Has been running for a while, time to shut ?er down. She (is a router
> a she?) used to handle all of my BGP GigE links but over the years has
> been demoted to OSPF and T1 aggregation.
> 
> If anyone needs a boat anchor let me know.

Please tell me her nodename is 'gracie'.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From morrowc.lists at gmail.com  Sun Sep 21 01:12:26 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 20 Sep 2014 21:12:26 -0400
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <20140920075602.GA22750@pob.ytti.fi>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
Message-ID: <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>

On Sat, Sep 20, 2014 at 3:56 AM, Saku Ytti <saku at ytti.fi> wrote:
> I'm not sure for example, if 11MEUR is needed for number registry personnel
> costs, that could give you 100 hostmasters with 5500EUR/month salary, in good
> likelihood, we'd be able to run focused number registry with volunteers.

I think your math is off? 11,000,000 / 100 == 110,000 / 12 == 9,166 month

right? Did you mean '200 hostmasters at 5500/month' ?

you'd likely also have to put into the mix the cost of infrastructure,
right? I'm not sure what current arin/ripe/apnic folk have deployed, I
imagine some servers (100k of gear? replaced every 3yrs?) and
routing/switching devices (2M replaced every 3 yrs), and link costs.

-chris


From randy at psg.com  Sun Sep 21 01:32:45 2014
From: randy at psg.com (Randy Bush)
Date: Sun, 21 Sep 2014 10:32:45 +0900
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
Message-ID: <m238bl4v2a.wl%randy@psg.com>

>> I'm not sure for example, if 11GER is needed for number registry personnel
>> costs, that could give you 100 hostmasters with 5500EUR/month salary, in good
>> likelihood, we'd be able to run focused number registry with volunteers.
> 
> I think your math is off? 11,000,000 / 100 == 110,000 / 12 == 9,166 month
> 
> right? Did you mean '200 hostmasters at 5500/month' ?
> 
> you'd likely also have to put into the mix the cost of infrastructure,
> right? I'm not sure what current arin/ripe/apnic folk have deployed, I
> imagine some servers (100k of gear? replaced every 3yrs?) and
> routing/switching devices (2M replaced every 3 yrs), and link costs.

we could nit-pick saku's arithmetic to death, but what would we learn?
it costs money and clue to run a good registry, news at eleven.

in '92 or whenever, when the nic contract went out to bid, rick said
he'd do it for free with some simple scripts.  it's a long way from that
to where we are today, and i doubt either extreme is where we should be.

i suspect that if we threw out all the micro-management policies,
restrictions on transfers, barriers to entry for legacy and newcomers,
etc., we might be able to move significantly closer to rick's idealistic
position.

buy it would require a change of paradigm, and that usually requires a
lot of folk retiring.  so to repeat/paraphrase what i just said in the
apnic forum,

someone too shy to post here (yes, virginia, there are such people:)
suggested i shill for them.  i think their points are worth it.
reasonable public resource governance practice would include at least
the following:
 - term limits for board and committee positions (maybe 2-4 years?)
 - ten year employment caps on executive staff
 - members decide bylaws and budgets

and as i suggested to arin, a gov/ops review consultation consisting of
folk with some stature in these areas, and not having any members from
board or staff.

i would love to see some folk with enable on the board, such as you.
but without the paradigm shift, it would just be pain and torture to no
real avail.  and good folk with enable are too busy enabling the
internet as opposed to making careers as wannabe micro-policy wonks.

randy


From morrowc.lists at gmail.com  Sun Sep 21 01:45:11 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 20 Sep 2014 21:45:11 -0400
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <m238bl4v2a.wl%randy@psg.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
 <m238bl4v2a.wl%randy@psg.com>
Message-ID: <CAL9jLabPOwsGFoiHEo+iz0b1jeFcRGqk0RBx2xM+aLMUUX8hvw@mail.gmail.com>

On Sat, Sep 20, 2014 at 9:32 PM, Randy Bush <randy at psg.com> wrote:
>>> I'm not sure for example, if 11GER is needed for number registry personnel
>>> costs, that could give you 100 hostmasters with 5500EUR/month salary, in good
>>> likelihood, we'd be able to run focused number registry with volunteers.
>>
>> I think your math is off? 11,000,000 / 100 == 110,000 / 12 == 9,166 month
>>
>> right? Did you mean '200 hostmasters at 5500/month' ?
>>
>> you'd likely also have to put into the mix the cost of infrastructure,
>> right? I'm not sure what current arin/ripe/apnic folk have deployed, I
>> imagine some servers (100k of gear? replaced every 3yrs?) and
>> routing/switching devices (2M replaced every 3 yrs), and link costs.
>
> we could nit-pick saku's arithmetic to death, but what would we learn?
> it costs money and clue to run a good registry, news at eleven.

sure, my point wasn't really that 'math is wrong', so much as 'running
a registry likely costs some cake in gear/bw/admin-time'

and that i'm not sure that 11m is off as a number close to the scale
of the cost/problem.


> i would love to see some folk with enable on the board, such as you.

can't other officer from same company already serving, phew! :) (see
bullfighter turn stance)

> but without the paradigm shift, it would just be pain and torture to no
> real avail.  and good folk with enable are too busy enabling the
> internet as opposed to making careers as wannabe micro-policy wonks.

I also agree that 'lots of policy' hasn't really gotten us anywhere :(


From randy at psg.com  Sun Sep 21 01:47:16 2014
From: randy at psg.com (Randy Bush)
Date: Sun, 21 Sep 2014 10:47:16 +0900
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <CAL9jLabPOwsGFoiHEo+iz0b1jeFcRGqk0RBx2xM+aLMUUX8hvw@mail.gmail.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
 <m238bl4v2a.wl%randy@psg.com>
 <CAL9jLabPOwsGFoiHEo+iz0b1jeFcRGqk0RBx2xM+aLMUUX8hvw@mail.gmail.com>
Message-ID: <m2y4td3ftn.wl%randy@psg.com>

> I also agree that 'lots of policy' hasn't really gotten us anywhere :(

< cheap shot >

this is not exactly true.  we just don't like where it has gotten us :)

randy


From morrowc.lists at gmail.com  Sun Sep 21 01:54:36 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 20 Sep 2014 21:54:36 -0400
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <m2y4td3ftn.wl%randy@psg.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
 <m238bl4v2a.wl%randy@psg.com>
 <CAL9jLabPOwsGFoiHEo+iz0b1jeFcRGqk0RBx2xM+aLMUUX8hvw@mail.gmail.com>
 <m2y4td3ftn.wl%randy@psg.com>
Message-ID: <CAL9jLabWTrRX8QHsMCvdunM6nkg4rue6+-stBp6PCBfVcKMgog@mail.gmail.com>

On Sat, Sep 20, 2014 at 9:47 PM, Randy Bush <randy at psg.com> wrote:
>> I also agree that 'lots of policy' hasn't really gotten us anywhere :(
>
> < cheap shot >
>
> this is not exactly true.  we just don't like where it has gotten us :)

that's a fair cheap shot.


From randy at psg.com  Sun Sep 21 01:57:19 2014
From: randy at psg.com (Randy Bush)
Date: Sun, 21 Sep 2014 10:57:19 +0900
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <CAL9jLabWTrRX8QHsMCvdunM6nkg4rue6+-stBp6PCBfVcKMgog@mail.gmail.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
 <m238bl4v2a.wl%randy@psg.com>
 <CAL9jLabPOwsGFoiHEo+iz0b1jeFcRGqk0RBx2xM+aLMUUX8hvw@mail.gmail.com>
 <m2y4td3ftn.wl%randy@psg.com>
 <CAL9jLabWTrRX8QHsMCvdunM6nkg4rue6+-stBp6PCBfVcKMgog@mail.gmail.com>
Message-ID: <m2vboh3fcw.wl%randy@psg.com>

>>> I also agree that 'lots of policy' hasn't really gotten us anywhere :(
>> < cheap shot >
>> this is not exactly true.  we just don't like where it has gotten us :)
> that's a fair cheap shot.

https://www.apnic.net/policy/proposals/prop-103

randy


From jcurran at arin.net  Sun Sep 21 13:59:02 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 21 Sep 2014 13:59:02 +0000
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <m238bl4v2a.wl%randy@psg.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
 <m238bl4v2a.wl%randy@psg.com>
Message-ID: <A609A2F5-2C29-4723-B284-DC422FFA2CA1@arin.net>

On Sep 20, 2014, at 9:32 PM, Randy Bush <randy at psg.com> wrote:

> in '92 or whenever, when the nic contract went out to bid, rick said
> he'd do it for free with some simple scripts.  it's a long way from that
> to where we are today, and i doubt either extreme is where we should be.
> 
> i suspect that if we threw out all the micro-management policies,
> restrictions on transfers, barriers to entry for legacy and newcomers,
> etc., we might be able to move significantly closer to rick's idealistic
> position.

It is true that we have accumulated several decades worth of policies
and assumptions that originate from the baseline that "IPv4 is a very
limited resource"; whether these make sense to carry over to a world 
where RIRs are not doing IPv4 issuance but merely keeping track of the
present address holder is an excellent question. There is nothing that 
inherently prevents a change in approach other than the policy developed 
by the community.  Given that anyone can participate in the policy 
development process (with results that are based on participant support 
for various proposals), does the lack of change reflect just a general 
lack of interest in making that happen or is it a reflection of the 
hysteresis built into the system? (i.e. the perceived need to learn 
the policy terminology and the policy development process, write up 
a proposal, educating others in the problem your trying to solve, 
participating in the discussion, etc.)

I have had folks tell me that it doesn't appear worth the effort to
change policy when all they really want is to get some address space -  
that a fairly hard situation to address; how does one have policy which 
truly serves the needs of entire community, when the actual participants 
are volunteers and thus a self-selected subset by definition?  In the 
ARIN region, the presumed answer to this question is the ARIN Advisory 
Council, which shepherds the development of policy proposals into draft 
policies and proposes them for adoption before the community (which does
reduce the amount of process issues that someone with a good idea needs 
to know in order to raise it for consideration...) It still ultimately 
comes down to the show of support for a given policy proposal at the 
ARIN Public Policy Consultations (PPCs) which are held during NANOG and 
the twice annual ARIN Public Policy Meetings.  Those who participate 
(generally between 50 and 100 folks depending on meeting) determine via 
their show of support whether draft policies ultimately get abandoned or 
adopted. If there is an "unserved" segment of the community out there of
any size, it simply takes attending either on-site (or remotely) to be 
included; making significant policy changes does not require membership, 
agreements, seats on the AC or Board, or anything else other than actual 
participation in the process.

> buy it would require a change of paradigm, and that usually requires a
> lot of folk retiring.

I'm going to disagree since most of concerns you cite above (e.g. transfer 
restrictions) are set in policy, and as I indicated, that can be readily be 
changed if even a small number of people got involved with a clear intent to 
change them.

> so to repeat/paraphrase what i just said in the apnic forum,
> 
> someone too shy to post here (yes, virginia, there are such people:)
> suggested i shill for them.  i think their points are worth it.
> reasonable public resource governance practice would include at least
> the following:
> - term limits for board and committee positions (maybe 2-4 years?)
> - ten year employment caps on executive staff
> - members decide bylaws and budgets
> 
> and as i suggested to arin, a gov/ops review consultation consisting of
> folk with some stature in these areas, and not having any members from
> board or staff.

Despite the fact that I do not believe that current policy development is 
encumbered by the practices you cite above, I do believe that any member-
based organization should periodically look at its accountability to the 
community served.  There is some commonality of belief in that principle 
among the other RIR; in fact, the RIRs (working via the NRO) recently 
completed a RIR survey and published a matrix providing an overview of 
the governance frameworks of the RIRs.  It is designed as a reference 
for the global Internet community, and provides a structured overview 
of various aspects of RIR governance, with links to the source documents 
on the respective websites of the RIRs -

    https://www.nro.net/about-the-nro/rir-governance-matrix

I do not believe that the current RIR governance matrix gets to the level 
of detail necessary to show each RIR's compliance to your "reasonable public 
resource governance practices" listed above; I will propose that it be 
updated accordingly as a first step in this process.  While everyone may 
not agree on what constitutes best practices for RIR governance, there is 
no reason not to have clear documentation of the current state of affairs 
to aid in the discussion.

Thanks!
/John

John Curran
President and CEO
ARIN



From johnl at iecc.com  Sun Sep 21 14:53:12 2014
From: johnl at iecc.com (John Levine)
Date: 21 Sep 2014 14:53:12 -0000
Subject: Bare TLD resolutions
In-Reply-To: <alpine.LSU.2.00.1409190959570.3000@hermes-1.csi.cam.ac.uk>
Message-ID: <20140921145312.2158.qmail@joyce.lan>

In article <alpine.LSU.2.00.1409190959570.3000 at hermes-1.csi.cam.ac.uk> you write:
>David Conrad <drc at virtualized.org> wrote:
>
>> To be clear, generic TLDs (gTLDs) can?t have bare (dotless) TLDs (or wildcards).
>
>Wildcards are being used for the name collision gubbins.

>;; ANSWER SECTION:
>*.prod.                 3600    IN      A       127.0.53.53

Yes, but only for a few months before the TLD goes live to try and
flush out prior local use of new TLDs.  The rule about wildcards in
live TLDs hasn't changed.

There was a lot about this at Verisign's name collision workshop after
the London IETF.

http://namecollisions.net/program/index.html

R's,
John


From saku at ytti.fi  Sun Sep 21 15:20:33 2014
From: saku at ytti.fi (Saku Ytti)
Date: Sun, 21 Sep 2014 18:20:33 +0300
Subject: internet governance, rir policy, and the decline of civilization
In-Reply-To: <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
References: <m2wq8y6he9.wl%randy@psg.com> <20140920075602.GA22750@pob.ytti.fi>
 <CAL9jLaZyJTEBxChv_z9sKgbiZXJJg=qpbP_pD=s_OM2C+L_GMA@mail.gmail.com>
Message-ID: <20140921152033.GA7872@pob.ytti.fi>

On (2014-09-20 21:12 -0400), Christopher Morrow wrote:

> I think your math is off? 11,000,000 / 100 == 110,000 / 12 == 9,166 month
> 
> right? Did you mean '200 hostmasters at 5500/month' ?

No. I live in socialist country where every 1 gross EUR paid to employees
costs about 1.7 EUR to employer.

-- 
  ++ytti


From rs at seastrom.com  Sun Sep 21 15:21:55 2014
From: rs at seastrom.com (Rob Seastrom)
Date: Sun, 21 Sep 2014 11:21:55 -0400
Subject: IP Geolocation Issue
In-Reply-To: <CA+3otVi60Rte6Vsi1ea7bSqyd80Eij5gPFrhDj6R8R7-C5GAdA@mail.gmail.com> (Alex
 Wacker's message of "Thu, 18 Sep 2014 20:09:43 -0400")
References: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>
 <CA+3otVi60Rte6Vsi1ea7bSqyd80Eij5gPFrhDj6R8R7-C5GAdA@mail.gmail.com>
Message-ID: <86r3z5xalo.fsf@valhalla.seastrom.com>


Good luck with that.  My past experience with them (while not as bad
as dealing with certain fast-n-loose RBLs) has been less than
encouraging.

-r

Alex Wacker <alex at alexwacker.com> writes:

> You can submit corrections to maxmind here:
> https://www.maxmind.com/en/correction
>
> On Wed, Sep 17, 2014 at 6:17 PM, Jose Damian Cantu Davila <jcantu at nic.mx> wrote:
>> Hi, Im new here, so any advice would be very appreciated.
>>
>> Is someone from Maxmind IP Geolocation available, that I can talk to offline?
>>
>> Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil.
>>
>> Thanks for your help.
>>
>> [damian cantu]
>>


From tom at ninjabadger.net  Sun Sep 21 19:09:52 2014
From: tom at ninjabadger.net (Tom Hill)
Date: Sun, 21 Sep 2014 20:09:52 +0100
Subject: Saying goodnight to my GSR
In-Reply-To: <54E2C1FC-54AD-4606-8F8D-A78FB28C1827@puck.nether.net>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <0A552C5F-2BD2-4A90-8223-228BDF5B30A6@consultant.com>
 <24173EBC-7138-4280-AB6D-77B380FE0CFA@corp.crocker.com>
 <CAPz7E53UUjt-t6tKjd-f1tffWhHe-LZFXOtgCDNY3asCS_DfCQ@mail.gmail.com>
 <CAJZMiudMt_pJnG=fJemPmZqmE5O27TWzaqEWask-7qCpo901PQ@mail.gmail.com>
 <54E2C1FC-54AD-4606-8F8D-A78FB28C1827@puck.nether.net>
Message-ID: <541F2280.10206@ninjabadger.net>

On 20/09/14 20:26, Jared Mauch wrote:
> OpenSNMPProject has some of this data for devices that respond to the string ?public?.
> 
> Lots of old stuff out there.

That might make for quite an interesting talk, Jared. :)

-- 
Tom



From ahebert at pubnix.net  Mon Sep 22 11:38:52 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Mon, 22 Sep 2014 07:38:52 -0400
Subject: Saying goodnight to my GSR
In-Reply-To: <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
References: <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
Message-ID: <54200A4C.1050604@pubnix.net>

    Well,

    I think it was just blind fear talking.

    Properly configured, it is less a security issue than newer devices.

    Pretty impressive from Matthew to have the patience/skills to not
simply "reload" that fridge over the years.

On 09/20/14 16:25, Keith Medcalf wrote:
> And what, exactly, is it vulnerable to?
>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Sterling
>> Sent: Saturday, 20 September, 2014 12:06
>> To: Bacon Zombie
>> Cc: nanog at nanog.org
>> Subject: Re: Saying goodnight to my GSR
>>
>> Again, you're focusing resentment towards someone who did the right
>> thing. Negative reinforcement will discourage others from taking
>> action and will discourage them from encouraging others to take
>> action.
>>
>> Let's focus on who still has vulnerable equipment and how to help
>> them. Let's not shame people who did the right thing
>>
>> Thanks,
>> Dan
>>
>>
>> On Sat, Sep 20, 2014 at 1:59 PM, Bacon Zombie <baconzombie at gmail.com>
>> wrote:
>>> OK thank you for decommissioning this.*
>>>
>>> * Only if you either had authority to do so for max 1 year or had no
>>> authority but were fighting to have it patches or replaced for years.
>>> On Sep 20, 2014 7:54 PM, "Daniel Sterling" <sterling.daniel at gmail.com>
>>> wrote:
>>>
>>>> On Sat, Sep 20, 2014 at 1:37 PM, Bacon Zombie <baconzombie at gmail.com>
>>>> wrote:
>>>>
>>>>> So when was the last time you patched this internet facing device?
>>>> Isn't the better response, thank you for decommissioning it?
>>>>
>>>> Can someone from cisco set up a poll or release whatever numbers they
>>>> have about how many of these old devices are still in service?
>>>>
>>>> Thanks,
>>>> Dan
>>>>
>
>
>



From dhubbard at dino.hostasaurus.com  Mon Sep 22 13:35:46 2014
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Mon, 22 Sep 2014 09:35:46 -0400
Subject: Saying goodnight to my GSR
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17305A15FD2@dino.ad.hostasaurus.com>

Got you beat by nine weeks with a Foundry 9604. :-)

#sh ver
  SW: Version 03.3.01aTc1 Copyright (c) 1996-2004 Foundry Networks, Inc.
      Compiled on Feb 01 2005 at 11:21:12 labeled as FES03301a
      (2057881 bytes) from Primary foundry-FES/FES03301a.bin
      Boot Monitor: Version 03.2.00Tc4
  HW: Stackable FES9604
========================================================================
==
      Serial #: 
  330 MHz Power PC processor 8245 (version 129/1014) 66 MHz bus
  512 KB boot flash memory
16384 KB code flash memory
  128 MB DRAM
The system uptime is 3411 days 7 hours 52 minutes 20 seconds 
The system started at 01:38:44 Eastern Sat May 21 2005

The system : started=warm start   reloaded=by "reload"



Poor thing just handles traffic for managed power strips and we haven't
had the heart to replace it lol.

David


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew
Crocker
Sent: Saturday, September 20, 2014 10:19 AM
To: NANOG
Subject: Saying goodnight to my GSR


Has been running for a while, time to shut 'er down.   She (is a router
a she?) used to handle all of my BGP GigE links but over the years has
been demoted to OSPF and T1 aggregation.

If anyone needs a boat anchor let me know.

gsr8-1#show version
Cisco Internetwork Operating System Software IOS (tm) GS Software
(GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support:
http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco
Systems, Inc.
Compiled Thu 30-Jun-05 18:29 by pwade
Image text-base: 0x50010E80, data-base: 0x536E8000

ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2]
RELEASE SOFTWARE

 gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime
for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6
2005 System image file is "slot0:gsr-p-mz.120-30.S3.bin"

cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of
memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last
reset from power-on

2 Route Processor Cards
2 Clock Scheduler Cards
3 Switch Fabric Cards
2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2
GigabitEthernet).
1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3
GigabitEthernet).
1 Ethernet/IEEE 802.3 interface(s)
5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile
configuration memory.

20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matthew at crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com








From streiner at cluebyfour.org  Mon Sep 22 10:23:27 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 22 Sep 2014 06:23:27 -0400 (EDT)
Subject: Saying goodnight to my GSR
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A17305A15FD2@dino.ad.hostasaurus.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <FCD26398C5EDE746BFC47F43EA52A17305A15FD2@dino.ad.hostasaurus.com>
Message-ID: <Pine.LNX.4.64.1409220615481.31614@whammy.cluebyfour.org>

On Mon, 22 Sep 2014, David Hubbard wrote:

> Got you beat by nine weeks with a Foundry 9604. :-)

I might have a Cat5505 or two on our out-of-band management network with 
uptimes that approach this.

jms

> #sh ver
>  SW: Version 03.3.01aTc1 Copyright (c) 1996-2004 Foundry Networks, Inc.
>      Compiled on Feb 01 2005 at 11:21:12 labeled as FES03301a
>      (2057881 bytes) from Primary foundry-FES/FES03301a.bin
>      Boot Monitor: Version 03.2.00Tc4
>  HW: Stackable FES9604
> ========================================================================
> ==
>      Serial #:
>  330 MHz Power PC processor 8245 (version 129/1014) 66 MHz bus
>  512 KB boot flash memory
> 16384 KB code flash memory
>  128 MB DRAM
> The system uptime is 3411 days 7 hours 52 minutes 20 seconds
> The system started at 01:38:44 Eastern Sat May 21 2005
>
> The system : started=warm start   reloaded=by "reload"
>
>
>
> Poor thing just handles traffic for managed power strips and we haven't
> had the heart to replace it lol.
>
> David
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew
> Crocker
> Sent: Saturday, September 20, 2014 10:19 AM
> To: NANOG
> Subject: Saying goodnight to my GSR
>
>
> Has been running for a while, time to shut 'er down.   She (is a router
> a she?) used to handle all of my BGP GigE links but over the years has
> been demoted to OSPF and T1 aggregation.
>
> If anyone needs a boat anchor let me know.
>
> gsr8-1#show version
> Cisco Internetwork Operating System Software IOS (tm) GS Software
> (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support:
> http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco
> Systems, Inc.
> Compiled Thu 30-Jun-05 18:29 by pwade
> Image text-base: 0x50010E80, data-base: 0x536E8000
>
> ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2]
> RELEASE SOFTWARE
>
> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime
> for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
> System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6
> 2005 System image file is "slot0:gsr-p-mz.120-30.S3.bin"
>
> cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of
> memory.
> R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last
> reset from power-on
>
> 2 Route Processor Cards
> 2 Clock Scheduler Cards
> 3 Switch Fabric Cards
> 2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2
> GigabitEthernet).
> 1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3
> GigabitEthernet).
> 1 Ethernet/IEEE 802.3 interface(s)
> 5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile
> configuration memory.
>
> 20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
> 8192K bytes of Flash internal SIMM (Sector size 256K).
> Configuration register is 0x2102
>
>
>
> --
> Matthew S. Crocker
> President
> Crocker Communications, Inc.
> PO BOX 710
> Greenfield, MA 01302-0710
>
> E: matthew at crocker.com
> P: (413) 746-2760
> F: (413) 746-3704
> W: http://www.crocker.com
>
>
>
>
>
>
>


From jcantu at nic.mx  Mon Sep 22 15:12:07 2014
From: jcantu at nic.mx (Jose Damian Cantu Davila)
Date: Mon, 22 Sep 2014 15:12:07 +0000
Subject: IP Geolocation Issue
In-Reply-To: <86r3z5xalo.fsf@valhalla.seastrom.com>
References: <FCF66E96D201B14192834EDDF93D55D60A839584@EXCHANGE-AX.nic.com.mx>
 <CA+3otVi60Rte6Vsi1ea7bSqyd80Eij5gPFrhDj6R8R7-C5GAdA@mail.gmail.com>
 <86r3z5xalo.fsf@valhalla.seastrom.com>
Message-ID: <FCF66E96D201B14192834EDDF93D55D60A83B68B@EXCHANGE-AX.nic.com.mx>

Thanks to everyone for the advise and the information.

Already got in touch with someone of Maxmind.

Damian.
IAR.

-----Original Message-----
From: Rob Seastrom [mailto:rs at seastrom.com] 
Sent: domingo, 21 de septiembre de 2014 10:22 a.m.
To: Alex Wacker
Cc: Jose Damian Cantu Davila; nanog at nanog.org
Subject: Re: IP Geolocation Issue


Good luck with that.  My past experience with them (while not as bad as dealing with certain fast-n-loose RBLs) has been less than encouraging.

-r

Alex Wacker <alex at alexwacker.com> writes:

> You can submit corrections to maxmind here:
> https://www.maxmind.com/en/correction
>
> On Wed, Sep 17, 2014 at 6:17 PM, Jose Damian Cantu Davila <jcantu at nic.mx> wrote:
>> Hi, Im new here, so any advice would be very appreciated.
>>
>> Is someone from Maxmind IP Geolocation available, that I can talk to offline?
>>
>> Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil.
>>
>> Thanks for your help.
>>
>> [damian cantu]
>>


----------


Este mensaje contiene informacion confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor eliminalo, ya que difundir, revelar, copiar o tomar cualquier accion basada en el contenido esta estrictamente prohibido. Network Information Center Mexico, S.C., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, Mexico, C.P. 64840 recaba tus datos personales necesarios para: la prestacion, estudio, analisis y mejora del servicio, la realizacion de comunicaciones y notificaciones; la transferencia y publicacion en los casos aplicables; el cumplimiento de la relacion existente; asi como para la prevencion o denuncia en la comision de ilicitos. Si eres colaborador o candidato a colaborador de NIC Mexico, tus datos seran utilizados para: la creacion y administracion de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realizacion de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestion y administracion de servicios de pago y/o nomina; asi como para contacto y/o notificaciones. Si participas en promociones o en estudios podras dejar de participar. Para mayor informacion revisa el Aviso de Privacidad [http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf]


This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center Mexico, S.C., located on Av. Eugenio Garza Sada 427 Col. Altavista L4-6, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events.  If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note [http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf]



From drew.weaver at thenap.com  Mon Sep 22 17:57:32 2014
From: drew.weaver at thenap.com (Drew Weaver)
Date: Mon, 22 Sep 2014 17:57:32 +0000
Subject: Saying goodnight to my GSR
In-Reply-To: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
Message-ID: <7e892e28395d4bcf840646b24bb2f500@EXCHANGE2K13.thenap.com>

The best thing about having GSRs around is trading them in for ASR 9900s.

The freight is a ding, though.

-Drew


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Crocker
Sent: Saturday, September 20, 2014 10:19 AM
To: NANOG
Subject: Saying goodnight to my GSR


Has been running for a while, time to shut 'er down.   She (is a router a she?) used to handle all of my BGP GigE links but over the years has been demoted to OSPF and T1 aggregation.

If anyone needs a boat anchor let me know.

gsr8-1#show version
Cisco Internetwork Operating System Software IOS (tm) GS Software (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Thu 30-Jun-05 18:29 by pwade
Image text-base: 0x50010E80, data-base: 0x536E8000

ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2] RELEASE SOFTWARE

 gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005 System image file is "slot0:gsr-p-mz.120-30.S3.bin"

cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last reset from power-on

2 Route Processor Cards
2 Clock Scheduler Cards
3 Switch Fabric Cards
2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2 GigabitEthernet).
1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet).
1 Ethernet/IEEE 802.3 interface(s)
5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile configuration memory.

20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matthew at crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com






From jim at supernap.com  Mon Sep 22 18:12:16 2014
From: jim at supernap.com (Jim Devane)
Date: Mon, 22 Sep 2014 18:12:16 +0000
Subject: Saying goodnight to my GSR
In-Reply-To: <7e892e28395d4bcf840646b24bb2f500@EXCHANGE2K13.thenap.com>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <7e892e28395d4bcf840646b24bb2f500@EXCHANGE2K13.thenap.com>
Message-ID: <84D3E8887D73004C93F6E9FD4E086955011BD894DF@MDB1.switchnet.nv>

They make great fish tanks in their second lives, although uptime stats are more "general recollection" for me now.

http://postimg.org/image/xdyp4o6p7/



-----Original Message-----
From: NANOG [mailto:nanog-bounces+jdevane=switchnap.com at nanog.org] On Behalf Of Drew Weaver
Sent: Monday, September 22, 2014 10:58 AM
To: 'Matthew Crocker'
Cc: 'nanog at nanog.org'
Subject: RE: Saying goodnight to my GSR

The best thing about having GSRs around is trading them in for ASR 9900s.

The freight is a ding, though.

-Drew


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Crocker
Sent: Saturday, September 20, 2014 10:19 AM
To: NANOG
Subject: Saying goodnight to my GSR


Has been running for a while, time to shut 'er down.   She (is a router a she?) used to handle all of my BGP GigE links but over the years has been demoted to OSPF and T1 aggregation.

If anyone needs a boat anchor let me know.

gsr8-1#show version
Cisco Internetwork Operating System Software IOS (tm) GS Software (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc.
Compiled Thu 30-Jun-05 18:29 by pwade
Image text-base: 0x50010E80, data-base: 0x536E8000

ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2] RELEASE SOFTWARE

 gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005 System image file is "slot0:gsr-p-mz.120-30.S3.bin"

cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of memory.
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last reset from power-on

2 Route Processor Cards
2 Clock Scheduler Cards
3 Switch Fabric Cards
2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2 GigabitEthernet).
1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet).
1 Ethernet/IEEE 802.3 interface(s)
5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile configuration memory.

20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matthew at crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com




CONFIDENTIAL INFORMATION

This email message, its chain, and any attachments: (a) may include proprietary information, trade secrets, confidential information and/or other protected information ("Confidential Information") which are hereby labeled as Confidential for protection purposes, (b) is sent to you in confidence with a reasonable expectation of privacy, (c) may be protected by confidentiality agreements requiring this notice and/or identification, and (d) is not intended for transmission to, or receipt by unauthorized persons. If you are not the intended recipient, please notify the sender immediately by telephone or by replying to this message. Please then delete this message, any attachments, chains, copies or portions from your system(s). Thank you.


From jra at baylink.com  Mon Sep 22 19:44:15 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 22 Sep 2014 15:44:15 -0400 (EDT)
Subject: Twitter appears inop
Message-ID: <33386189.2684.1411415054930.JavaMail.root@benjamin.baylink.com>

I'm getting various 403 messages on tweets about "looks automated", from
Tweetcaster and the Web UI, both over Sprint LTE from Tampa; anyone else
seeing this?

Retrieval seems ok; the web UI loads fine too.  Appears internal.

I would notify them, but Twitter is down.

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From streiner at cluebyfour.org  Mon Sep 22 16:07:03 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 22 Sep 2014 12:07:03 -0400 (EDT)
Subject: Saying goodnight to my GSR
In-Reply-To: <84D3E8887D73004C93F6E9FD4E086955011BD894DF@MDB1.switchnet.nv>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <7e892e28395d4bcf840646b24bb2f500@EXCHANGE2K13.thenap.com>
 <84D3E8887D73004C93F6E9FD4E086955011BD894DF@MDB1.switchnet.nv>
Message-ID: <Pine.LNX.4.64.1409221206001.11166@whammy.cluebyfour.org>

On Mon, 22 Sep 2014, Jim Devane wrote:

> They make great fish tanks in their second lives, although uptime stats are more "general recollection" for me now.
>
> http://postimg.org/image/xdyp4o6p7/

Reminds me of a kegerator I saw many moons ago, made out of a hollowed-out 
Wellfleet BCN ;)

jms

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+jdevane=switchnap.com at nanog.org] On Behalf Of Drew Weaver
> Sent: Monday, September 22, 2014 10:58 AM
> To: 'Matthew Crocker'
> Cc: 'nanog at nanog.org'
> Subject: RE: Saying goodnight to my GSR
>
> The best thing about having GSRs around is trading them in for ASR 9900s.
>
> The freight is a ding, though.
>
> -Drew
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Crocker
> Sent: Saturday, September 20, 2014 10:19 AM
> To: NANOG
> Subject: Saying goodnight to my GSR
>
>
> Has been running for a while, time to shut 'er down.   She (is a router a she?) used to handle all of my BGP GigE links but over the years has been demoted to OSPF and T1 aggregation.
>
> If anyone needs a boat anchor let me know.
>
> gsr8-1#show version
> Cisco Internetwork Operating System Software IOS (tm) GS Software (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc.
> Compiled Thu 30-Jun-05 18:29 by pwade
> Image text-base: 0x50010E80, data-base: 0x536E8000
>
> ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2] RELEASE SOFTWARE
>
> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005 System image file is "slot0:gsr-p-mz.120-30.S3.bin"
>
> cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of memory.
> R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last reset from power-on
>
> 2 Route Processor Cards
> 2 Clock Scheduler Cards
> 3 Switch Fabric Cards
> 2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2 GigabitEthernet).
> 1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet).
> 1 Ethernet/IEEE 802.3 interface(s)
> 5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile configuration memory.
>
> 20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
> 8192K bytes of Flash internal SIMM (Sector size 256K).
> Configuration register is 0x2102
>
>
>
> --
> Matthew S. Crocker
> President
> Crocker Communications, Inc.
> PO BOX 710
> Greenfield, MA 01302-0710
>
> E: matthew at crocker.com
> P: (413) 746-2760
> F: (413) 746-3704
> W: http://www.crocker.com
>
>
>
>
> CONFIDENTIAL INFORMATION
>
> This email message, its chain, and any attachments: (a) may include proprietary information, trade secrets, confidential information and/or other protected information ("Confidential Information") which are hereby labeled as Confidential for protection purposes, (b) is sent to you in confidence with a reasonable expectation of privacy, (c) may be protected by confidentiality agreements requiring this notice and/or identification, and (d) is not intended for transmission to, or receipt by unauthorized persons. If you are not the intended recipient, please notify the sender immediately by telephone or by replying to this message. Please then delete this message, any attachments, chains, copies or portions from your system(s). Thank you.
>


From matlockken at gmail.com  Mon Sep 22 20:10:35 2014
From: matlockken at gmail.com (Ken Matlock)
Date: Mon, 22 Sep 2014 14:10:35 -0600
Subject: Saying goodnight to my GSR
In-Reply-To: <Pine.LNX.4.64.1409221206001.11166@whammy.cluebyfour.org>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <7e892e28395d4bcf840646b24bb2f500@EXCHANGE2K13.thenap.com>
 <84D3E8887D73004C93F6E9FD4E086955011BD894DF@MDB1.switchnet.nv>
 <Pine.LNX.4.64.1409221206001.11166@whammy.cluebyfour.org>
Message-ID: <CAF-Wqd5sLBG=yaaG5++rn3OzqFdYzUiJuHED8W=SoRak5PDS8Q@mail.gmail.com>

Ha! I'd say that's an upgrade for the BCN! ;-)

I still have nightmares about Site Mangler, and conflicting versions
between it and the BCN/BLNs.....

Ken

On Mon, Sep 22, 2014 at 10:07 AM, Justin M. Streiner <
streiner at cluebyfour.org> wrote:

> On Mon, 22 Sep 2014, Jim Devane wrote:
>
>  They make great fish tanks in their second lives, although uptime stats
>> are more "general recollection" for me now.
>>
>> http://postimg.org/image/xdyp4o6p7/
>>
>
> Reminds me of a kegerator I saw many moons ago, made out of a hollowed-out
> Wellfleet BCN ;)
>
> jms
>
>
>  -----Original Message-----
>> From: NANOG [mailto:nanog-bounces+jdevane=switchnap.com at nanog.org] On
>> Behalf Of Drew Weaver
>> Sent: Monday, September 22, 2014 10:58 AM
>> To: 'Matthew Crocker'
>> Cc: 'nanog at nanog.org'
>> Subject: RE: Saying goodnight to my GSR
>>
>> The best thing about having GSRs around is trading them in for ASR 9900s.
>>
>> The freight is a ding, though.
>>
>> -Drew
>>
>>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Crocker
>> Sent: Saturday, September 20, 2014 10:19 AM
>> To: NANOG
>> Subject: Saying goodnight to my GSR
>>
>>
>> Has been running for a while, time to shut 'er down.   She (is a router a
>> she?) used to handle all of my BGP GigE links but over the years has been
>> demoted to OSPF and T1 aggregation.
>>
>> If anyone needs a boat anchor let me know.
>>
>> gsr8-1#show version
>> Cisco Internetwork Operating System Software IOS (tm) GS Software
>> (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support:
>> http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco
>> Systems, Inc.
>> Compiled Thu 30-Jun-05 18:29 by pwade
>> Image text-base: 0x50010E80, data-base: 0x536E8000
>>
>> ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2]
>> RELEASE SOFTWARE
>>
>> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime for
>> this control processor is 9 years, 2 weeks, 2 days, 18 minutes System
>> returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005
>> System image file is "slot0:gsr-p-mz.120-30.S3.bin"
>>
>> cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of
>> memory.
>> R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last
>> reset from power-on
>>
>> 2 Route Processor Cards
>> 2 Clock Scheduler Cards
>> 3 Switch Fabric Cards
>> 2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2
>> GigabitEthernet).
>> 1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet).
>> 1 Ethernet/IEEE 802.3 interface(s)
>> 5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile
>> configuration memory.
>>
>> 20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
>> 8192K bytes of Flash internal SIMM (Sector size 256K).
>> Configuration register is 0x2102
>>
>>
>>
>> --
>> Matthew S. Crocker
>> President
>> Crocker Communications, Inc.
>> PO BOX 710
>> Greenfield, MA 01302-0710
>>
>> E: matthew at crocker.com
>> P: (413) 746-2760
>> F: (413) 746-3704
>> W: http://www.crocker.com
>>
>>
>>
>>
>> CONFIDENTIAL INFORMATION
>>
>> This email message, its chain, and any attachments: (a) may include
>> proprietary information, trade secrets, confidential information and/or
>> other protected information ("Confidential Information") which are hereby
>> labeled as Confidential for protection purposes, (b) is sent to you in
>> confidence with a reasonable expectation of privacy, (c) may be protected
>> by confidentiality agreements requiring this notice and/or identification,
>> and (d) is not intended for transmission to, or receipt by unauthorized
>> persons. If you are not the intended recipient, please notify the sender
>> immediately by telephone or by replying to this message. Please then delete
>> this message, any attachments, chains, copies or portions from your
>> system(s). Thank you.
>>
>>


From larrysheldon at cox.net  Mon Sep 22 23:10:17 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 22 Sep 2014 18:10:17 -0500
Subject: Saying goodnight to my GSR
In-Reply-To: <uBfp1o0071cZc5601BfrKg>
References: <714837b348d4c84a8bd079ffb2cb7849@mail.dessus.com>
 <uBfp1o0071cZc5601BfrKg>
Message-ID: <5420AC59.9000903@cox.net>

On 9/22/2014 06:38, Alain Hebert wrote:
>   Properly configured, it is less a security issue than newer devices.
>
>      Pretty impressive from Matthew to have the patience/skills to not
> simply "reload" that fridge over the years.

Whew!  I was afraid I was the one who thought so anymore.

-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.



Quis custodiet ipsos custodes


From larrysheldon at cox.net  Mon Sep 22 23:13:27 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 22 Sep 2014 18:13:27 -0500
Subject: Saying goodnight to my GSR
In-Reply-To: <uDcz1o00e1cZc5601Dd1nk>
References: <364EF33D-F054-4666-9778-A4B40F6ACDC7@corp.crocker.com>
 <uDcz1o00e1cZc5601Dd1nk>
Message-ID: <5420AD17.4070502@cox.net>

On 9/22/2014 08:35, David Hubbard wrote:
> Got you beat by nine weeks with a Foundry 9604. :-)

> The system uptime is 3411 days 7 hours 52 minutes 20 seconds
> The system started at 01:38:44 Eastern Sat May 21 2005

That's the kind of waving I like to see.
-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.



Quis custodiet ipsos custodes


From holbor at sonss.net  Mon Sep 22 23:44:17 2014
From: holbor at sonss.net (Richard Holbo)
Date: Mon, 22 Sep 2014 16:44:17 -0700
Subject: IPV6 Multicast Listener storm control?
Message-ID: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>

(originally posted to wispa ipv6 list, and someone there mentioned that
folks here might have some suggestions, so apologize if you are a member of
both.)

I am seeing issues with IPV6 multicast storms in my network that are fairly
low volume (1-2mbit), but that are causing service disruptions due to CPU
load on the switches and that the network is a Point to MultiPoint wireless
network.

I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst
3750 and 3560 switches.  These are switched back to a routed interface and
IP addresses are assigned by DHCP.  We are not using IPV6 at all, and I
don't have control of the clients.

What I'm seeing is IPV6 Multicast Listener requests from a single client
(different clients at different times) going out on the network, the
switches manage them in software, so CPU goes up (not a lot, but it seems
to impact performance quite a bit), but the larger problem is that all
other IPV6 clients respond to the multicast broadcast address generating a
1-2mbit storm of traffic to all ports all the time.  This then transits the
bandwidth constrained wireless network in a steady state, causing high
collisions which causes _significant_ performance degradation in the
wireless network.

It would appear that this is _generally_ caused by Dell or HP workstations
with buggy network interface cards in hibernate mode.

http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/

http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-listener-discovery-queries/

Now it looks like from my reading that CISCO MLD snooping would _help_ with
this, though it would not stop the offender from generating the multicast
requests, it might keep if from reaching _all_ ports, but it would still
affect any ports that had _subscribed_ IPV6 clients, and it would require
changing the SDM template and a reload on all the switches.  So not a real
answer and very painful.

Right now, I'm just tracking the source down and shutting it off.  Do not
really want to get into an argument about switched vs routed, and am
working on reducing the size of the broadcast domain now, but this is a new
issue, and I need to come up with some kind of plan to resolve with my
current equipment/network.

Any thoughts?? Ideas?  I suspect this will become more of an issue for more
folks in the near future.

/thanks

-- 
Richard Holbo
Southern Oregon Network Support Services
richard.holbo at sonss.net - 541.890.8067
http://www.sonss.net


From swmike at swm.pp.se  Tue Sep 23 03:55:30 2014
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 23 Sep 2014 05:55:30 +0200 (CEST)
Subject: IPV6 Multicast Listener storm control?
In-Reply-To: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>
References: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1409230552140.14735@uplift.swm.pp.se>

On Mon, 22 Sep 2014, Richard Holbo wrote:

> Now it looks like from my reading that CISCO MLD snooping would _help_ with
> this, though it would not stop the offender from generating the multicast
> requests, it might keep if from reaching _all_ ports, but it would still

If the packets are sent to ff02::1, then this will be sent to all ports 
even with MLD snooping turned on.

http://www.ietf.org/rfc/rfc4541.txt

"In IPv6, the data forwarding rules are more straight forward because
    MLD is mandated for addresses with scope 2 (link-scope) or greater.
    The only exception is the address FF02::1 which is the all hosts
    link-scope address for which MLD messages are never sent.  Packets
    with the all hosts link-scope address should be forwarded on all
    ports."

So I doubt turning on MLD snooping will help.

Your switches, can't you do some kind of protocol based filtering, and 
only allow two ethertypes, ARP and IPv4?

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


From SNaslund at medline.com  Tue Sep 23 04:24:56 2014
From: SNaslund at medline.com (Naslund, Steve)
Date: Tue, 23 Sep 2014 04:24:56 +0000
Subject: IPV6 Multicast Listener storm control?
In-Reply-To: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>
References: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>
Message-ID: <9578293AE169674F9A048B2BC9A081B40124F957B9@MUNPRDMBXA1.medline.com>

We have seen the same issue with Lenovo devices.  They all seem to have a variety of Intel chipsets.  We have not found a good solution other than updating drivers and/or shutting down ipv6 which we really don?t want to do but it is easier to automate that than to automate the driver update.  I will be interested in seeing what anyone else has come up with to kill these off.  In our case, the biggest issue is wireless clients that show this behavior because they really bury the access points CPU.  The switched network seems to absorb the load better.

Steven Naslund
Chicago IL

>>> (originally posted to wispa ipv6 list, and someone there mentioned that folks here might have some suggestions, so apologize if you are a member of
>>>both.)

>>>I am seeing issues with IPV6 multicast storms in my network that are fairly low volume (1-2mbit), but that are causing service disruptions due to CPU load >>>on the switches and that the network is a Point to MultiPoint wireless network.

>>>I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst
>>>3750 and 3560 switches.  These are switched back to a routed interface and IP addresses are assigned by DHCP.  We are not using IPV6 at all, and I don't >>>have control of the clients.

>>>What I'm seeing is IPV6 Multicast Listener requests from a single client (different clients at different times) going out on the network, the switches >>>manage them in software, so CPU goes up (not a lot, but it seems to impact performance quite a bit), but the larger problem is that all other IPV6 clients >>>respond to the multicast broadcast address generating a 1-2mbit storm of traffic to all ports all the time.  This then transits the bandwidth constrained >>>wireless network in a steady state, causing high collisions which causes _significant_ performance degradation in the wireless network.


From rs at seastrom.com  Tue Sep 23 11:59:23 2014
From: rs at seastrom.com (Rob Seastrom)
Date: Tue, 23 Sep 2014 07:59:23 -0400
Subject: IPV6 Multicast Listener storm control?
In-Reply-To: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com> (Richard
 Holbo's message of "Mon, 22 Sep 2014 16:44:17 -0700")
References: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>
Message-ID: <86ppem5yzo.fsf@valhalla.seastrom.com>


Richard Holbo <holbor at sonss.net> writes:

> I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst
> 3750 and 3560 switches.  These are switched back to a routed interface and
> IP addresses are assigned by DHCP.  We are not using IPV6 at all, and I
> don't have control of the clients.

This configuration is reminiscent of my back lawn.  It probably grew
organically, has been neglected for a period of time, and it's going
to require a bit of effort to tame it and bring it under control.

You probably don't have the option of blocking horizontal layer 2
traffic like the WISP guys do, and even if you were able to get away
with that it brings its own set of downsides to it.

The solution here is to chop things into separate broadcast domains,
each one no bigger than a single switch.  You might bring each to a
routed interface on another device (or likely more than one other
device depending on your network layout), but on no account should you
have the broadcast domain span more than one port on that device.

Hopefully you don't have any poorly behaved software that depends on
being in the same broadcast domain.  It can be difficult to inventory
that and make sure it all works before taking the leap.  It could be
easier to just peel off one workgroup of people to configure them that
way as a pilot and see if anyone squawks.  Tell them that you're doing
it and that you want feedback, since your current configuration is
conditioning them to just suck it up when the network periodically
flakes.

Hope this helps,

-r



From rs at seastrom.com  Tue Sep 23 12:00:54 2014
From: rs at seastrom.com (Rob Seastrom)
Date: Tue, 23 Sep 2014 08:00:54 -0400
Subject: IPV6 Multicast Listener storm control?
In-Reply-To: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com> (Richard
 Holbo's message of "Mon, 22 Sep 2014 16:44:17 -0700")
References: <CAFiN6rqyqPspPvV3Yi1im2uxCnm9NoPbDof1MXEO++A7vk9kZQ@mail.gmail.com>
Message-ID: <86lhpa5yx5.fsf@valhalla.seastrom.com>


Richard Holbo <holbor at sonss.net> writes:

> I am seeing issues with IPV6 multicast storms in my network that are fairly
> low volume (1-2mbit), but that are causing service disruptions due to CPU
> load on the switches and that the network is a Point to MultiPoint wireless
> network.

OK, well one comment in my previous email will sound stupid (not
enough coffee yet) but the upshot remains: more subnetting.

-r



From jlester at wcs.k12.va.us  Wed Sep 24 02:39:19 2014
From: jlester at wcs.k12.va.us (Jason Lester)
Date: Tue, 23 Sep 2014 22:39:19 -0400
Subject: Google Services Problems?
Message-ID: <CANoO+=8S6HKpU=A8_DaCEHsf1rHQrCeD9hn3GXcC6Dh+X1fsow@mail.gmail.com>

Is anyone else seeing intermittently down or very slow access to Google
services like YouTube and Google Play Store?  We have two upstream
providers: one peers with XO and Level3, one with Qwest.  When our Google
traffic is preferring the route through XO, we see things like YouTube
videos not loading, Android devices not able to download updates, Google
Play Music not streaming, etc.  The main source network we are seeing it
from is 206.111.9.XXX which is owned by XO according to whois, but seems to
be sourcing Google traffic.  I assume they are caching or CDN servers of
some type for Google that are hosted at XO.  The problem started on Friday
as far as we can tell.

We had a similar problem a few weeks ago with Google Images searching.  The
search result page showed the same thumbnail (a car crash) for anything you
searched for.  It was again being sourced from the 206.111.9.XXX network.
Clicking on the image showed you the proper image, just the thumbnails were
wrong.  It cleared up in a couple of hours in that case, but the current
problem has been going on for a while.

Thanks,
Jason


From psirt at cisco.com  Wed Sep 24 16:23:14 2014
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 24 Sep 2014 12:23:14 -0400
Subject: Cisco Security Advisory: Cisco IOS Software RSVP Vulnerability 
Message-ID: <201409241223.17.rsvp@psirt.cisco.com>

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

Cisco IOS Software RSVP Vulnerability

Advisory ID: cisco-sa-20140924-rsvp

Revision 1.0

For Public Release 2014 September 24 16:00  UTC (GMT)

Summary
+======

A vulnerability in the implementation of the Resource Reservation Protocol (RSVP) in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker cause the device to reload. This vulnerability could be exploited repeatedly to cause an extended denial of service (DoS) condition.

Cisco has released free software updates that address this vulnerability.

A workaround that mitigates this vulnerability is available.

This advisory is available at the following link: 
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140924-rsvp

Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUIZNfAAoJEIpI1I6i1Mx3qoIP/RnDEwuhG4SEtyEAycEOpJoX
cDsmK8C0xRKYkoUeSlmkO1TXzRk42RMnd6aoYAxojgqsYnVt10ZKibSLzCxZxWnX
MMKhMPSrUSvWvPNgLDYyOJ4R4B6IOwYwS6wNCABtiwes/rET+p+d0gw4rZ4SLujF
hSrWcxE8Fax5zU7Z++ZifOhcg/C7gGvIbsuStf01S6/oZHPx8PXnVj9J4eI0Yxz9
JRhkJQv8FlfJYzZnxbi545YH1fUt+e5FzTTlPOaYayYqi0E/NvrPW64s8QKLURE7
M01EzxIsyItwxIYAXy5pcUHnyAd/bZ21CmEiHvOq4GZVXoZpkkF0pCceos+mC987
4mPYVe+PwNrPJwb0qdG6MKDiXmO+txVFLazNF2JJaGeFYjeN+If57mJSttznVLiE
ZPCkdLmr/Y2uDbtwoDdFI6TbrIsFceawIEKLn5lIPQrtt+JiwkWkxKSLMsB6wm0l
nmogpIL43jgnozrYRTMizA+hu/mHgg88mOWD/AAFA5O6K+YQIEYYtYjy4Bundrq7
2Rr6uJNUN9fD3amT3ZqP6DE7ETlAkC29sFy0IuXkudpXc+YrcVAkhwrlMekoeepL
t6cWl+o8dTaexJe7h4neuADwCPrT15wNBiasHP0Uw/BAUnbPM2aOjL8WZDb1BHvT
5AkSuOMpsSZakqt0vik+
=kL1E
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 24 16:23:47 2014
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 24 Sep 2014 12:23:47 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Metadata Vulnerabilities 
Message-ID: <201409241223.17.metadata@psirt.cisco.com>

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

Cisco IOS Software Metadata Vulnerabilities

Advisory ID: cisco-sa-20140924-metadata

Revision 1.0

For Public Release 2014 September 24 16:00  UTC (GMT)

Summary
+======

Two vulnerabilities in the metadata flow feature of Cisco IOS Software could allow an unauthenticated, remote attacker to reload a vulnerable device.

The vulnerabilities are due to improper handling of transit RSVP packets that need to be processed by the metadata infrastructure. An attacker could exploit these vulnerabilities by sending malformed RSVP packets to an affected device. A successful exploit could allow the attacker to cause an extended denial of service (DoS) condition.

Cisco has released free software updates that address these vulnerabilities.

Workarounds that mitigate these vulnerabilities are not available. 

This advisory is available at the following link: 
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140924-metadata

Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUIZNfAAoJEIpI1I6i1Mx3SpwP/jfNLKisT8kvgV2iMhFr0Z2w
1oOqnYmG1WWNh/yXh+uKIPeHUDSYjsW1ntAP/vnuw1Op2UDPMl1fTWe4AWo8huOf
R2cq3dCBZRfKmlhfJAGuqaramkAITwLPNsODwIHZUwXYQPrHnlZB7c/Ry8dkE+d5
ATGeGFS9nDnboAKyRFyusLarQ95X+Yukpq/BmGLXd+neuC+tz4x1PCBvQJdeqaMx
Fg2r94dg0mhzwYJ/HBLVUk4OJRYhJxUeJw7zqrB9GGZnYry+ll8qY9pSbMVpI1Yy
523Okpes5zJ1KNR+uceABj1SSpe0n+LAfqj8ekkzrZz7CQGONYEd39PSor73zKBE
1SmyUVj75hoH3rx45SQLgArvfUXkJZLeSgnstWU7DCIlD5OjxMbazq8nlU9cmD5q
gXKtPLZI8/xREwUjmmowv3ykSscxW7x0EBL/NCG+JcXmTGS26gf8SGsVfkDYIkuo
iLxrgkiuvXtq+SGLdmRnfC7Ts2m/5E1AJHW7V64yZ+tNLW4XM5cMjMtDZXTQdQHN
sQvPe8E4sFFpcSn2vi0Y5weBItr3p+QGDF5HxojPr1NLZz8bHUBWJ6kjYvDynM3C
yGXTgEI7g8vmzcfeBTZCa3Us/qDb+0DZFzt15TpUbZmcuVjcoSo3myp1+XzP7ky2
xC9OlRnpvnRWrSnAXcLe
=E9az
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 24 16:24:19 2014
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 24 Sep 2014 12:24:19 -0400
Subject: Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS
 Software Multicast Domain Name System 
Message-ID: <201409241224.17.mdns@psirt.cisco.com>

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

Multiple Vulnerabilities in Cisco IOS Software Multicast Domain Name System

Advisory ID: cisco-sa-20140924-mdns

Revision 1.0

For Public Release 2014 September 24 16:00  UTC (GMT)

Summary
+======

The Cisco IOS Software implementation of the multicast Domain Name System (mDNS) feature contains the following vulnerabilities when processing mDNS packets that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition:

Cisco IOS Software mDNS Gateway Memory Leak Vulnerability
Cisco IOS Software mDNS Gateway Denial of Service Vulnerability
Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140924-mdns

Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link:
http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUIZNeAAoJEIpI1I6i1Mx3euMP/0ptD3acwXkieo5NTQEYXU2L
cMlnxkTZnXzzjkGAcy0eJKhHAh9JI0FU5DcEVmMbTd7qXnm2sixFYR27dxMCJBaG
Quj5RgGGz2KUFNGO87+JX8zw8yBKyknN8eO7njBb6c99UHAv/GVZAjnwcDEbRM3L
G7/C7S7ZVkk8w63U46CsVV5eaGj2RQnbZx3jYNhPKjZnCc/MQSM87nnTuR8RjkCm
wlrReK6BjxtJ13R3o2NmWzSJWSsc8N81pvIooJdaBCqlGZ4e/j06Z5+S5CF3DGiJ
xJvEdKGdvLRo14hUtQLJ8Vx8bJMkHBdr7Bernmca/8AIeXEMdc61ZGs8bS72Magh
JbiJIT7B3jQXdjzQpQ/mHKNoghkI302g3H6egrtsCBWr+lepEIfmHLf4h0LueqWh
pVQPqXWAGg+5AR1ABvP+mwtQuz/psboXpacMM8keZ2a/6uS82tf3lTXR/8zBd+Om
sGbhBYIkO67Cp/Zn2CNY1v9Pg8f4tNAkATazg2Mvt4QfOlRUFRYBdyV2LZLSDCJ4
9/Pw8s7pLMMFpt90pBzIBUY+FsiGkWoHduMO7/O93Zw4Y2n2vnRYFkyuFQFphBuO
M2Yb20vqO9tsELTt0MDmdfXf40HhhAUF6zbw6fWa4SCV4CwZn6h8eAZttsqQQqxl
cdgZjAsAV5dsoejxk0LC
=7Kkh
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 24 16:24:51 2014
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 24 Sep 2014 12:24:51 -0400
Subject: Cisco Security Advisory: Cisco IOS Software DHCP Version 6 Denial of
 Service Vulnerability 
Message-ID: <201409241224.17.dhcpv6@psirt.cisco.com>

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

Cisco IOS Software DHCP Version 6 Denial of Service Vulnerability

Advisory ID: cisco-sa-20140924-dhcpv6

Revision 1.0

For Public Release 2014 September 24 16:00  UTC (GMT)

Summary
+======

A vulnerability in the DHCP version 6 (DHCPv6) server implementation of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition.

The vulnerability is due to improper parsing of malformed DHCPv6 packets. An attacker could exploit this vulnerability by sending malformed DHCPv6 packets to be processed by an affected device. An exploit could allow the attacker to cause a memory leak and eventual reload of an affected device.

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-20140924-dhcpv6

Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUIZNeAAoJEIpI1I6i1Mx3FxAP/i8bB96s06HvbR5sSFBf6iqW
QMfKKOujTGf9w9UH/CUqVtvX2kDLoaZXxoARruZ3hIk2tWqfkFCIyGtCSEXwQxfg
+ueE/LpmXZWkvZ7eLk7GS7lclfVlbu4W5GR1+asp3qIOeKRUpY9SPWDlLuT7vmtb
s8WmVbDKQOEg3MJSt4tkUSDQsL6AOvhFue2VYjGUnzYX0SPOQxkeCGCbOcmCRGPH
3Yi0IPiUa/XOxOCfsSlXJQP5OWVOlCnQZGiOlyaiaYiyTjUlB7uKgZP/jGIuc/gf
4dt0FTK/VykqLXIXERNBL28IO/4ZZDtkZvosy92iUG/BlXzdxB4+9pZ3wgqeih9Q
2hVNgX+xQ+M6BoTyMZ11OvZxqvaIr4e4ijx/CRx+jkqsX3tgoWzcEWe6EDpAL/6s
G7+0cZ04L5zdbZg0NTqciuN04Wm7HEKTpCr3Da/BwomP7Wzx/zHkKAi0IUj/Qa9f
hD/RYmapejks3QXpVPaxYoSQANq7u7dBlSenNYxKaurRNDe9JO8y0LHrLWgF/PlW
CRRt3k7x5bo+nHSUQrZTIeJhPLcvZ9zxLhs1X3ksSdB44ro0pH9kGky6ewPzrd/7
8HimC+ibFB5bU+sjw1iLNZY3Wd9pVNpiezuCzoKgK4mJ8IjbtFm+mBRvDL4bf5xA
oKMD5Aa57OYRgeRzm5ZR
=N1Wn
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 24 16:25:24 2014
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 24 Sep 2014 12:25:24 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation
 Protocol Denial of Service Vulnerability 
Message-ID: <201409241225.17.sip@psirt.cisco.com>

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

Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability

Advisory ID: cisco-sa-20140924-sip

Revision 1.0

For Public Release 2014 September 24 16:00  UTC (GMT)

Summary
+======

A vulnerability in the Session Initiation Protocol (SIP) implementation in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of an affected device. To exploit this vulnerability, affected devices must be configured to process SIP messages.

Cisco has released free software updates that address this vulnerability. 

There are no workarounds for devices that must run SIP; however, mitigations are available to limit exposure to this vulnerability.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140924-sip

Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUIZNgAAoJEIpI1I6i1Mx307EQAI1LtZYk5Eiw9CR6ZQSCPjjI
vxWM5f+29TObzPyYSlWuoexDnryZ5s3FZNje6HKz0ie9hoHEXJq1YTU7Ya/JeuWV
6yNgBgbIC94PcpmK+aHuboSk/oe9aEvAsIM5lIQJwTxIa1CTq5zP1iKwe420iOQd
YOHy8rjxRXda+G3OS/91m98mLQ72vIwQ2tCqrAsn484RoPMHndnMvchLLwxdEsHL
fHW0tdTDXZ0KAup92koXBiIBbasfdOo/EgunmI1xw1bbDqs3fX2G6Dl5SiOUHSM0
0sn83/7WnexbXXG+Zv9vAxgYbevesQWqOpZl0Aw+nl+ov2RvmcuaEKXIm/1yPROV
vJXaL+q38c+A34Hio308V8xgnPn1CCW91TrOzT+iv+tIrH6O+jT/ehjz8ioNHrKn
lxenUBdRiSvLNF/LOpZFlvRs9Gdbat7iwOLbi7ri5s3Mjs4gRQcPg/ElboFvMz1D
bZuSk2y7tq46MxvZosHY1JWu+5VgsO2tJAvl+isgn/Vc6Rk6ZAFpvLK+HjPN7AF3
+rPXMm/lqC9IhgviyNpDEVo0clm9a8vNwgki30s4XCS6Mat4irSX+Af0X6fZ1VII
K0M+fNHgR72lLv1NR9TsRWz40njwx+ks9a9fdmkfNRuXXjx8OBfC0kwVKBU0H3EJ
hzkjmy3Hee100G2V/9X+
=X1lR
-----END PGP SIGNATURE-----


From psirt at cisco.com  Wed Sep 24 16:25:57 2014
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 24 Sep 2014 12:25:57 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Network Address
 Translation Denial of Service Vulnerability 
Message-ID: <201409241225.17.nat@psirt.cisco.com>

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

Cisco IOS Software Network Address Translation Denial of Service Vulnerability

Advisory ID: cisco-sa-20140924-nat

Revision 1.0

For Public Release 2014 September 24 16:00  UTC (GMT)

Summary
+======

A vulnerability in the Network Address Translation (NAT) feature of Cisco IOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper translation of IP version 4 (IPv4) packets.

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-20140924-nat

Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUIZNfAAoJEIpI1I6i1Mx3GjkQAKWPwFAUj1OaQ+/vwiKdlcwC
sZZk53GXtQE3IVMyOYP2LyeDJk1E/Krv8BK8gguBxSjjhRi4WLKc2lr7NrbOmQUh
qq9UCG1HXQi1pOUuKxTJVtlX6jktiZrdvguWcRDCZc6jbPs0cZNmfrsD5fsp8w/2
65dIFPRPYWebLBvKPCJYEvd87ugbb+jLl28qdlCFAaUMgLBnvgeNemIPu9LxgatI
I1rEGXSs6YEkAzGG4uwRvOA+K/3GChuGt1v3b4YS6QVOJCHQlNvvztZMJKcPOEj5
EgtHlsQJC/tCLLT43l6+IAbmDTyaXiZITHhxFa3NXI3q6v8yuf7USFnAI7HyNdW7
ZqYpRybdyIMMSaDCMTEjYKQ5wSq95Ci9K2J52GuADKo2VJiAntoRF496VL1WftT8
80jKzNoaDX4310xvSEN2DEAU5ekLH3792o/6zIB+HgDWKZOEayO9ugWjMrBrI226
Djn/sD3oEWKUkp5EZS2HJAzYTitE5zBOfAh5qfQs7siTQQIcP3b2NgdFR5ZTiile
Eo2w82I2QC96zUz51a4ESLrK88fOAl30mh/Zk8qhxCUs/29z6h2m7AAsc/9QZNHd
Q4lwkodU7yllOIPV16ob47B61XueH4V3Jw7Rt3CJZUwbDTYALlPDK3bwjR60WxP7
KP2y8xOM0z4g0HMz/8bc
=luk3
-----END PGP SIGNATURE-----


From dhubbard at dino.hostasaurus.com  Wed Sep 24 16:42:15 2014
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 24 Sep 2014 12:42:15 -0400
Subject: 2002::/16 [6to4] & abuse
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>

Curious if anyone can tell me, or point me to a link, on how 2002::/16
is actually implemented for 6to4?  Strictly for curiosity.

We had a customer ask about blocking spam from their wordpress blog that
we host and the spammer was using 2002:af2c:785::af2c:785, which was the
first time I'd seen wordpress spam coming from IPv6.  Per RFC3964, I'm
guessing the 175.44.120.5 is just a relay router, not surprisingly, on
the China Net network and the spammer was native v6?

I see that net advertised from 6939 (HE) and 1103 (SURFnet Netherlands)
from the perspective of my feeds, so that just got me more confused.

Thanks,

David


From trejrco at gmail.com  Wed Sep 24 16:56:03 2014
From: trejrco at gmail.com (TJ)
Date: Wed, 24 Sep 2014 12:56:03 -0400
Subject: 2002::/16 [6to4] & abuse
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>
Message-ID: <CALOgxGbnvnOHVFaKMW2JfHHgpuCY8AwB=fFkdpnrxQdQa+oQ7g@mail.gmail.com>

2002::/16 would be advertised by anyone *still *operating a 6to4 relay.

A host w/ only IPv4 connectivity could use 6to4 to get access to an
IPv6-only resource, thanks to automatic IPv6-in-IPv4 encapsulation
(Protocol41) and with a helping hand from publicly operated relays.
Someone with (only?) native IPv6 would not, normally / unintentionally, use
a 6to4 address.  In this case, af2c:785 being on both sides means it is (if
everyone is playing nicely / by the rules) a host at that v4 address doing
this automagically.

Pure supposition:  a compromised host that happens to have, and prefer,
6to4.


/TJ


On Wed, Sep 24, 2014 at 12:42 PM, David Hubbard <
dhubbard at dino.hostasaurus.com> wrote:

> Curious if anyone can tell me, or point me to a link, on how 2002::/16
> is actually implemented for 6to4?  Strictly for curiosity.
>
> We had a customer ask about blocking spam from their wordpress blog that
> we host and the spammer was using 2002:af2c:785::af2c:785, which was the
> first time I'd seen wordpress spam coming from IPv6.  Per RFC3964, I'm
> guessing the 175.44.120.5 is just a relay router, not surprisingly, on
> the China Net network and the spammer was native v6?
>
> I see that net advertised from 6939 (HE) and 1103 (SURFnet Netherlands)
> from the perspective of my feeds, so that just got me more confused.
>
> Thanks,
>
> David
>


From bill at herrin.us  Wed Sep 24 17:09:27 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 24 Sep 2014 13:09:27 -0400
Subject: 2002::/16 [6to4] & abuse
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>
Message-ID: <CAP-guGVUBO8MUzyF9uv1+HNSMWjb2aGoWp7+WtcPWhvOp7y3yQ@mail.gmail.com>

Hi David,

6to4 is a stateless tunnel network. The tunnel entry node advertises
2002::/16 into the native IPv6 network and relays received IPv6
packets inside an IPv4 packet. The tunnel exit node's IPv4 address is
encoded in the 6to4 IPv6 destination address.

No IPv6 addresses are changed in the transmission of the packet, so
unless someone is incorrectly advertising more-specifics for
2002::/16, 2002:af2c:785::af2c:785 is the host that connected to your
customer and that host is connected to af.2c.07.85, i.e. 175.44.7.133.

Going the other way (towards the native IPv6 network), 175.44.7.133
encapsulates the IPv6 packet into an IPv4 packet addressed to the
standard anycast IPv4 address for a 6to4 exit node. This packet finds
its way to the nearest 6to4 exit node on the IPv6 native network where
it is decapsulated back to an plain IPv6 packet.

Repeating af2c:785 in the address is just like saying 10.11.10.11.
Don't expect it to mean anything.

Regards,
Bill Herrin

On Wed, Sep 24, 2014 at 12:42 PM, David Hubbard
<dhubbard at dino.hostasaurus.com> wrote:
> Curious if anyone can tell me, or point me to a link, on how 2002::/16
> is actually implemented for 6to4?  Strictly for curiosity.
>
> We had a customer ask about blocking spam from their wordpress blog that
> we host and the spammer was using 2002:af2c:785::af2c:785, which was the
> first time I'd seen wordpress spam coming from IPv6.  Per RFC3964, I'm
> guessing the 175.44.120.5 is just a relay router, not surprisingly, on
> the China Net network and the spammer was native v6?
>
> I see that net advertised from 6939 (HE) and 1103 (SURFnet Netherlands)
> from the perspective of my feeds, so that just got me more confused.
>
> Thanks,
>
> David



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From paigeadele at gmail.com  Wed Sep 24 20:16:25 2014
From: paigeadele at gmail.com (Paige Thompson)
Date: Wed, 24 Sep 2014 23:16:25 +0300
Subject: 2002::/16 [6to4] & abuse
In-Reply-To: <CAP-guGVUBO8MUzyF9uv1+HNSMWjb2aGoWp7+WtcPWhvOp7y3yQ@mail.gmail.com>
References: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>
 <CAP-guGVUBO8MUzyF9uv1+HNSMWjb2aGoWp7+WtcPWhvOp7y3yQ@mail.gmail.com>
Message-ID: <665c05606edc9e28bc3da557c95bb123@yourstruly.sx>

On 2014-09-24 20:09, William Herrin wrote:
> Hi David,
> 
> 6to4 is a stateless tunnel network. The tunnel entry node advertises
> 2002::/16 into the native IPv6 network and relays received IPv6
> packets inside an IPv4 packet. The tunnel exit node's IPv4 address is
> encoded in the 6to4 IPv6 destination address.
> 
> No IPv6 addresses are changed in the transmission of the packet, so
> unless someone is incorrectly advertising more-specifics for
> 2002::/16, 2002:af2c:785::af2c:785 is the host that connected to your
> customer and that host is connected to af.2c.07.85, i.e. 175.44.7.133.
> 
> Going the other way (towards the native IPv6 network), 175.44.7.133
> encapsulates the IPv6 packet into an IPv4 packet addressed to the
> standard anycast IPv4 address for a 6to4 exit node. This packet finds
> its way to the nearest 6to4 exit node on the IPv6 native network where
> it is decapsulated back to an plain IPv6 packet.
> 
> Repeating af2c:785 in the address is just like saying 10.11.10.11.
> Don't expect it to mean anything.
> 
> Regards,
> Bill Herrin
> 
> On Wed, Sep 24, 2014 at 12:42 PM, David Hubbard
> <dhubbard at dino.hostasaurus.com> wrote:
>> Curious if anyone can tell me, or point me to a link, on how 2002::/16
>> is actually implemented for 6to4?  Strictly for curiosity.
>> 
>> We had a customer ask about blocking spam from their wordpress blog 
>> that
>> we host and the spammer was using 2002:af2c:785::af2c:785, which was 
>> the
>> first time I'd seen wordpress spam coming from IPv6.  Per RFC3964, I'm
>> guessing the 175.44.120.5 is just a relay router, not surprisingly, on
>> the China Net network and the spammer was native v6?
>> 
>> I see that net advertised from 6939 (HE) and 1103 (SURFnet 
>> Netherlands)
>> from the perspective of my feeds, so that just got me more confused.
>> 
>> Thanks,
>> 
>> David

Was gonna say if the customer is complaining that there is wordpress 
spam (in the apache logs) of an ipv6 address then the customer probably 
has an ipv6 address that he/she doesn't know about. Most people don't 
even know about ip6tables vs iptables. Usually apache won't serve the 
request unless the request includes the hostname of the vhost to server 
unless its all setup in /var/www/localhost or something, getting back to 
wordpress kind of makes me wonder how that RBL service (kismet? I think 
its called?) that they have is going to keep up with ipv6... theres a 
lot of them.

-- 
GPG: 0x0d5d2688 (keys.gnupg.net)


From dhubbard at dino.hostasaurus.com  Wed Sep 24 18:56:12 2014
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 24 Sep 2014 14:56:12 -0400
Subject: 2002::/16 [6to4] & abuse
References: <FCD26398C5EDE746BFC47F43EA52A17305EEFA@dino.ad.hostasaurus.com>
 <CAP-guGVUBO8MUzyF9uv1+HNSMWjb2aGoWp7+WtcPWhvOp7y3yQ@mail.gmail.com>
 <dee472b5ef0d4f45640d3e34915ad873@yourstruly.sx>
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17305A15FD4@dino.ad.hostasaurus.com>

Thanks Bill, TJ and Owen; it's much clearer now. 

David


From randy at psg.com  Wed Sep 24 19:05:16 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 25 Sep 2014 04:05:16 +0900
Subject: update
Message-ID: <m24mvwq1oz.wl%randy@psg.com>

there is an update out you want.  badly.
debian/ubuntu admins may want to apt-get update/upgrade or whatever
freebsd similarly
can not speak for other systems


From jared at puck.nether.net  Wed Sep 24 19:07:26 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 24 Sep 2014 15:07:26 -0400
Subject: update
In-Reply-To: <m24mvwq1oz.wl%randy@psg.com>
References: <m24mvwq1oz.wl%randy@psg.com>
Message-ID: <9A3E054D-ED5F-45FC-8314-89B74AD595D9@puck.nether.net>

Can I presume you?re talking about the bash CVE-2014-6271?

- jared

> On Sep 24, 2014, at 3:05 PM, Randy Bush <randy at psg.com> wrote:
> 
> there is an update out you want.  badly.
> debian/ubuntu admins may want to apt-get update/upgrade or whatever
> freebsd similarly
> can not speak for other systems



From randy at psg.com  Wed Sep 24 19:10:51 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 25 Sep 2014 04:10:51 +0900
Subject: update
In-Reply-To: <542316DF.50404@frii.net>
References: <m24mvwq1oz.wl%randy@psg.com>
	<542316DF.50404@frii.net>
Message-ID: <m2zjdoomv8.wl%randy@psg.com>

> See: http://seclists.org/oss-sec/2014/q3/650

sigh.  i am well aware of it but saw no benefit for further blabbing a
vuln

randy


From spencerg at frii.net  Wed Sep 24 19:09:19 2014
From: spencerg at frii.net (Spencer Gaw)
Date: Wed, 24 Sep 2014 13:09:19 -0600
Subject: update
In-Reply-To: <m24mvwq1oz.wl%randy@psg.com>
References: <m24mvwq1oz.wl%randy@psg.com>
Message-ID: <542316DF.50404@frii.net>

See: http://seclists.org/oss-sec/2014/q3/650

Regards,

SG

On 9/24/2014 1:05 PM, Randy Bush wrote:
> there is an update out you want.  badly.
> debian/ubuntu admins may want to apt-get update/upgrade or whatever
> freebsd similarly
> can not speak for other systems



From spencerg at frii.net  Wed Sep 24 19:38:09 2014
From: spencerg at frii.net (Spencer Gaw)
Date: Wed, 24 Sep 2014 13:38:09 -0600
Subject: update
In-Reply-To: <m2zjdoomv8.wl%randy@psg.com>
References: <m24mvwq1oz.wl%randy@psg.com>	<542316DF.50404@frii.net>
 <m2zjdoomv8.wl%randy@psg.com>
Message-ID: <54231DA1.6020703@frii.net>

Keeping silent after the embargo is over isn't doing anyone any favors. 
I think Florian said it best in his most recent message:

"In this particular case, I think we had to publish technical details so 
that those who cannot patch immediately can at least try to mitigate 
this vulnerability using filters on devices in front of web servers, or 
tools like mod_security. And without the technical details, I doubt this 
vulnerability would have received the attention it deserves until 
someone figures things out. We could easily have obfuscated the patch to 
delay this, but what's the point?"

For anyone that would like to see if a system is vulnerable:

|env x='() { :;}; echo vulnerable' bash -c "echo this is a test"|


If you receive the echo output, your version of bash is affected.

Regards,

SG

On 9/24/2014 1:10 PM, Randy Bush wrote:
>> See: http://seclists.org/oss-sec/2014/q3/650
> sigh.  i am well aware of it but saw no benefit for further blabbing a
> vuln
>
> randy



From shortdudey123 at gmail.com  Wed Sep 24 20:47:20 2014
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 24 Sep 2014 13:47:20 -0700
Subject: AWS EC2 us-west-2 reboot
Message-ID: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>

As an FYI,  it looks like Amazon is doing a mass reboot of the physical
hosts in us-west-2 across all AZ's and it is scheduled to start tomorrow
and take a couple days.
Go to *https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events
<https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:* to
see what instances are affected when.

-Grant


From gabe at teksavvy.ca  Wed Sep 24 20:51:44 2014
From: gabe at teksavvy.ca (Gabriel Blanchard)
Date: Wed, 24 Sep 2014 20:51:44 +0000
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
Message-ID: <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>

Bash related?

> On Sep 24, 2014, at 4:47 PM, "Grant Ridder" <shortdudey123 at gmail.com> wrote:
> 
> As an FYI,  it looks like Amazon is doing a mass reboot of the physical
> hosts in us-west-2 across all AZ's and it is scheduled to start tomorrow
> and take a couple days.
> Go to *https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events
> <https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:* to
> see what instances are affected when.
> 
> -Grant


From alter3d at alter3d.ca  Wed Sep 24 20:55:47 2014
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Wed, 24 Sep 2014 16:55:47 -0400
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
 <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
Message-ID: <54232FD3.50103@alter3d.ca>

Likely not, since it's affecting Windows instances as well.

Also not just us-west-2 -- we have tons of instances scheduled for 
downtime in us-east-1 and eu-west-1 as well.

-Peter


On 09/24/2014 04:51 PM, Gabriel Blanchard wrote:
> Bash related?
>
>> On Sep 24, 2014, at 4:47 PM, "Grant Ridder" <shortdudey123 at gmail.com> wrote:
>>
>> As an FYI,  it looks like Amazon is doing a mass reboot of the physical
>> hosts in us-west-2 across all AZ's and it is scheduled to start tomorrow
>> and take a couple days.
>> Go to *https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events
>> <https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:* to
>> see what instances are affected when.
>>
>> -Grant



From shortdudey123 at gmail.com  Wed Sep 24 20:56:39 2014
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 24 Sep 2014 13:56:39 -0700
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
 <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
Message-ID: <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>

Doubt it since a bash patch shouldn't require a reboot

On Wed, Sep 24, 2014 at 1:51 PM, Gabriel Blanchard <gabe at teksavvy.ca> wrote:

> Bash related?
>
> > On Sep 24, 2014, at 4:47 PM, "Grant Ridder" <shortdudey123 at gmail.com>
> wrote:
> >
> > As an FYI,  it looks like Amazon is doing a mass reboot of the physical
> > hosts in us-west-2 across all AZ's and it is scheduled to start tomorrow
> > and take a couple days.
> > Go to *
> https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events
> > <https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:*
> to
> > see what instances are affected when.
> >
> > -Grant
>


From jimpop at gmail.com  Wed Sep 24 22:11:39 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 18:11:39 -0400
Subject: update
In-Reply-To: <m24mvwq1oz.wl%randy@psg.com>
References: <m24mvwq1oz.wl%randy@psg.com>
Message-ID: <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>

> debian/ubuntu admins may want to apt-get update/upgrade or whatever

debian/ubuntu aren't really all that immediately impacted.

$ grep "bash$" /etc/passwd | wc -l
2

 ^^ both of those are user accounts, not system/daemon accounts.

-Jim P.


From redkrieg at gmail.com  Wed Sep 24 22:17:55 2014
From: redkrieg at gmail.com (Brandon Whaley)
Date: Wed, 24 Sep 2014 18:17:55 -0400
Subject: update
In-Reply-To: <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
Message-ID: <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>

The scope of the issue isn't limited to SSH, that's just a popular
example people are using.  Any program calling bash could potentially
be vulnerable.

On Wed, Sep 24, 2014 at 6:11 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>> debian/ubuntu admins may want to apt-get update/upgrade or whatever
>
> debian/ubuntu aren't really all that immediately impacted.
>
> $ grep "bash$" /etc/passwd | wc -l
> 2
>
>  ^^ both of those are user accounts, not system/daemon accounts.
>
> -Jim P.


From jimpop at gmail.com  Wed Sep 24 22:27:03 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 18:27:03 -0400
Subject: update
In-Reply-To: <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
Message-ID: <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>

On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley <redkrieg at gmail.com> wrote:
> The scope of the issue isn't limited to SSH, that's just a popular
> example people are using.  Any program calling bash could potentially
> be vulnerable.

Agreed.  My point was that bash is not all that popular on
debian/ubuntu for accounts that would be running public facing
services that would be processing user defined input (www-data,
cgi-bin, list, irc, lp, mail, etc).  Sure some non-privileged user
could host their own cgi script on >:1024, but that's not really a
critical "stop the presses!!" upgrade issue, imho.

-Jim P.


From brfree at adobe.com  Wed Sep 24 21:02:55 2014
From: brfree at adobe.com (Brian Free)
Date: Wed, 24 Sep 2014 21:02:55 +0000
Subject: Oi Assistance
Message-ID: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>

Hi NANOG,
I'm hoping someone out there has had some experience with Oi Telecommunications.  We've been struggling to work with them to get a couple of circuits in Sao Paulo live.  The primary problem is mostly a language barrier.  Is anyone aware of an English speaking NOC email address or phone number for Oi?  After months of back and forth through a third party translator working with our account team, I've reached my limit and am hoping there's another option to get some technical assistance with the BGP configuration of these two circuits.  Any advice will be appreciated.

Thanks,
Brian



From javier at advancedmachines.us  Wed Sep 24 21:35:01 2014
From: javier at advancedmachines.us (Javier J)
Date: Wed, 24 Sep 2014 17:35:01 -0400
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
 <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
 <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>
Message-ID: <CA+M5dWb3F5e5avL976zptCkQXHrYC159dowth1uv9hfC+mpgew@mail.gmail.com>

Just got the same email. Not just US. Servers in Sydney we have also. Why
such short notice?
On Sep 24, 2014 4:58 PM, "Grant Ridder" <shortdudey123 at gmail.com> wrote:

> Doubt it since a bash patch shouldn't require a reboot
>
> On Wed, Sep 24, 2014 at 1:51 PM, Gabriel Blanchard <gabe at teksavvy.ca>
> wrote:
>
> > Bash related?
> >
> > > On Sep 24, 2014, at 4:47 PM, "Grant Ridder" <shortdudey123 at gmail.com>
> > wrote:
> > >
> > > As an FYI,  it looks like Amazon is doing a mass reboot of the physical
> > > hosts in us-west-2 across all AZ's and it is scheduled to start
> tomorrow
> > > and take a couple days.
> > > Go to *
> > https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events
> > > <https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:*
> > to
> > > see what instances are affected when.
> > >
> > > -Grant
> >
>


From mike at mtcc.com  Wed Sep 24 22:35:40 2014
From: mike at mtcc.com (Michael Thomas)
Date: Wed, 24 Sep 2014 15:35:40 -0700
Subject: update
In-Reply-To: <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
Message-ID: <5423473C.1030805@mtcc.com>


On 9/24/14, 3:27 PM, Jim Popovitch wrote:
> On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley <redkrieg at gmail.com> wrote:
>> The scope of the issue isn't limited to SSH, that's just a popular
>> example people are using.  Any program calling bash could potentially
>> be vulnerable.
> Agreed.  My point was that bash is not all that popular on
> debian/ubuntu for accounts that would be running public facing
> services that would be processing user defined input (www-data,
> cgi-bin, list, irc, lp, mail, etc).  Sure some non-privileged user
> could host their own cgi script on >:1024, but that's not really a
> critical "stop the presses!!" upgrade issue, imho.
>
>

This is already made it to /. so I'm not sure why Randy was being so 
hush hush...

But my read is that this could affect anything that calls bash to do 
processing, like
handing off to CGI by putting in headers to p0wn the box. Also: bash is 
incredibly
pervasive though any unix disto, in not at all obvious places, so I 
wouldn't be
complacent about this at all.

Mike


From jimpop at gmail.com  Wed Sep 24 22:50:05 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 18:50:05 -0400
Subject: update
In-Reply-To: <5423473C.1030805@mtcc.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
Message-ID: <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>

On Sep 24, 2014 6:39 PM, "Michael Thomas" <mike at mtcc.com> wrote:
>
>
> On 9/24/14, 3:27 PM, Jim Popovitch wrote:
>>
>> On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley <redkrieg at gmail.com>
wrote:
>>>
>>> The scope of the issue isn't limited to SSH, that's just a popular
>>> example people are using.  Any program calling bash could potentially
>>> be vulnerable.
>>
>> Agreed.  My point was that bash is not all that popular on
>> debian/ubuntu for accounts that would be running public facing
>> services that would be processing user defined input (www-data,
>> cgi-bin, list, irc, lp, mail, etc).  Sure some non-privileged user
>> could host their own cgi script on >:1024, but that's not really a
>> critical "stop the presses!!" upgrade issue, imho.
>>
>>
>
> This is already made it to /. so I'm not sure why Randy was being so hush
hush...
>
> But my read is that this could affect anything that calls bash to do
processing, like
> handing off to CGI by putting in headers to p0wn the box. Also: bash is
incredibly
> pervasive though any unix disto, in not at all obvious places, so I
wouldn't be
> complacent about this at all.
>
> Mike

If someone is already invoking #!/bin/bash from a cgi, then they are
already doing it wrong (bash has massive bloat/overhead for a CGI script).
But I do agree, it's hard to know exactly what idiots do.  :-)

-Jim P.


From ahebert at pubnix.net  Wed Sep 24 22:58:23 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Wed, 24 Sep 2014 18:58:23 -0400
Subject: update
In-Reply-To: <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
Message-ID: <54234C8F.5080906@pubnix.net>

On 09/24/14 18:50, Jim Popovitch wrote:
> On Sep 24, 2014 6:39 PM, "Michael Thomas" <mike at mtcc.com> wrote:
>>
>> On 9/24/14, 3:27 PM, Jim Popovitch wrote:
>>> On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley <redkrieg at gmail.com>
> wrote:
>>>> The scope of the issue isn't limited to SSH, that's just a popular
>>>> example people are using.  Any program calling bash could potentially
>>>> be vulnerable.
>>> Agreed.  My point was that bash is not all that popular on
>>> debian/ubuntu for accounts that would be running public facing
>>> services that would be processing user defined input (www-data,
>>> cgi-bin, list, irc, lp, mail, etc).  Sure some non-privileged user
>>> could host their own cgi script on >:1024, but that's not really a
>>> critical "stop the presses!!" upgrade issue, imho.
>>>
>>>
>> This is already made it to /. so I'm not sure why Randy was being so hush
> hush...
>> But my read is that this could affect anything that calls bash to do
> processing, like
>> handing off to CGI by putting in headers to p0wn the box. Also: bash is
> incredibly
>> pervasive though any unix disto, in not at all obvious places, so I
> wouldn't be
>> complacent about this at all.
>>
>> Mike
> If someone is already invoking #!/bin/bash from a cgi, then they are
> already doing it wrong (bash has massive bloat/overhead for a CGI script).
> But I do agree, it's hard to know exactly what idiots do.  :-)

    Maybe just mis-informed, they become idiots if they keep doing it
after someone pointed it to them =D

>
> -Jim P.


From Valdis.Kletnieks at vt.edu  Wed Sep 24 23:00:39 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 24 Sep 2014 19:00:39 -0400
Subject: update
In-Reply-To: Your message of "Wed, 24 Sep 2014 18:50:05 -0400."
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
Message-ID: <34137.1411599639@turing-police.cc.vt.edu>

On Wed, 24 Sep 2014 18:50:05 -0400, Jim Popovitch said:

> If someone is already invoking #!/bin/bash from a cgi, then they are
> already doing it wrong (bash has massive bloat/overhead for a CGI script).

You sure you don't have *any* cgi's that do something like
system("mail -s 'cgi program xxyz hit fatal error' webadmin at localhost");
because all it takes is finding a way to force the fatal error while you
send a crafted User-Agent: header....

As Jim Popovitch said, bash usage is incredibly pervasive....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140924/b94b974e/attachment.sig>

From jimpop at gmail.com  Wed Sep 24 23:22:14 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 19:22:14 -0400
Subject: update
In-Reply-To: <34137.1411599639@turing-police.cc.vt.edu>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
Message-ID: <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>

On Sep 24, 2014 7:00 PM, <Valdis.Kletnieks at vt.edu> wrote:
>
> On Wed, 24 Sep 2014 18:50:05 -0400, Jim Popovitch said:
>
> > If someone is already invoking #!/bin/bash from a cgi, then they are
> > already doing it wrong (bash has massive bloat/overhead for a CGI
script).
>
> You sure you don't have *any* cgi's that do something like
> system("mail -s 'cgi program xxyz hit fatal error' webadmin at localhost");
> because all it takes is finding a way to force the fatal error while you
> send a crafted User-Agent: header....

That won't automatically invoke bash on Debian/Ubuntu....unless someone
intentionally changed default shells....

-Jim P.


From fdj at mindspring.com  Wed Sep 24 23:36:44 2014
From: fdj at mindspring.com (Daniel Jackson)
Date: Wed, 24 Sep 2014 19:36:44 -0400
Subject: update
In-Reply-To: <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
Message-ID: <5423558C.7020401@mindspring.com>

On 09/24/2014 07:22 PM, Jim Popovitch wrote:
> That won't automatically invoke bash on Debian/Ubuntu....unless someone
> intentionally changed default shells....
>
> -Jim P.

People seem not to know that Debian and derivatives use a variant 
Almquist shell rather than bash for system accounts.

Daniel



From mysidia at gmail.com  Thu Sep 25 00:00:32 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 24 Sep 2014 19:00:32 -0500
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
 <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
 <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>
Message-ID: <CAAAwwbX6K-jHwwcMM0vD0v3JYS9BabE2ggk9gzREbq7qOYqRZg@mail.gmail.com>

On Wed, Sep 24, 2014 at 3:56 PM, Grant Ridder <shortdudey123 at gmail.com> wrote:
> Doubt it since a bash patch shouldn't require a reboot

Unless you have a long-running bash script in the background providing
a vital system service, and that service is so important in your
environment that you might as well reboot  rather than kill and
respawn it.

--
-JH


From cma at cmadams.net  Thu Sep 25 00:41:31 2014
From: cma at cmadams.net (Chris Adams)
Date: Wed, 24 Sep 2014 19:41:31 -0500
Subject: update
In-Reply-To: <5423558C.7020401@mindspring.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
Message-ID: <20140925004131.GB32683@cmadams.net>

Once upon a time, Daniel Jackson <fdj at mindspring.com> said:
> On 09/24/2014 07:22 PM, Jim Popovitch wrote:
> >That won't automatically invoke bash on Debian/Ubuntu....unless someone
> >intentionally changed default shells....
> 
> People seem not to know that Debian and derivatives use a variant
> Almquist shell rather than bash for system accounts.

It doesn't have much to do with default shells or system account
settings; it has everything to do with what is /bin/sh.  I think /bin/sh
has been dash (derived from NetBSD's Almquist shell) on Debian-derived
systems for a while now.  Other major Linux distributions, e.g.
RHEL/Fedora family and IIRC SuSE, use bash as /bin/sh though, so should
be patched ASAP (especially if they are web servers).

Has anybody looked to see if the popular web software the users install
and don't maintain (e.g. Wordpress, phpBB, Joomla, Drupal) use system()
or the like to call out to external programs?  What about service
provider type stuff like RT?  I know Nagios calls out to shell scripts
for notifications and such, and passes some things in environment
variables (don't know if it can be tricked in this fashion though).

-- 
Chris Adams <cma at cmadams.net>


From mysidia at gmail.com  Thu Sep 25 01:27:39 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 24 Sep 2014 20:27:39 -0500
Subject: update
In-Reply-To: <20140925004131.GB32683@cmadams.net>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com> <20140925004131.GB32683@cmadams.net>
Message-ID: <CAAAwwbUNH+NbjKpV=aJi9r8rn=+Li5bcSOYsQ9=TXB2MApFSEA@mail.gmail.com>

On Wed, Sep 24, 2014 at 7:41 PM, Chris Adams <cma at cmadams.net> wrote:
> Has anybody looked to see if the popular web software the users install
> and don't maintain (e.g. Wordpress, phpBB, Joomla, Drupal) use system()

Wouldn't it be great if it was JUST  system()?   It's also  popen(),
shell_exec(),  passhru(),  exec(),  backtic operator.

I am pretty sure ALL of them use at least 1 of these in various places
out of the box,  and many plugins use these as well,  such that a
shell could be invoked,  but  popen() on $sendmail is  particularly
common.


> or the like to call out to external programs?  What about service
> provider type stuff like RT?  I know Nagios calls out to shell scripts

--
-JH


From beckman at angryox.com  Thu Sep 25 01:39:39 2014
From: beckman at angryox.com (Peter Beckman)
Date: Wed, 24 Sep 2014 21:39:39 -0400
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <CA+M5dWb3F5e5avL976zptCkQXHrYC159dowth1uv9hfC+mpgew@mail.gmail.com>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
 <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
 <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>
 <CA+M5dWb3F5e5avL976zptCkQXHrYC159dowth1uv9hfC+mpgew@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1409242127330.88890@nog.angryox.com>

Likely some sort of potentially serious bug or flaw in EC2 or Xen. AWS
Security is really on the ball on such things and do everything they can to
make invisible fixes with no customer impact, but sometimes a reboot is
required in order to apply the changes necessary to keep customer instances
safe from attacks and vulnerabilities.

Another possibility: getting rid of older hardware. A reboot will keep you
in the same class of service but may move you to a new physical machine.
Unlikely though at this reported scale.

Same thing happened in December 2011 [1].

Beckman

[1]
http://www.crn.com/news/cloud/232300111/widespread-amazon-ec2-cloud-instance-reboots-spark-questions-concerns.htm

On Wed, 24 Sep 2014, Javier J wrote:

> Just got the same email. Not just US. Servers in Sydney we have also. Why
> such short notice?
>
> On Sep 24, 2014 4:58 PM, "Grant Ridder" <shortdudey123 at gmail.com> wrote:
>
>> Doubt it since a bash patch shouldn't require a reboot
>>
>> On Wed, Sep 24, 2014 at 1:51 PM, Gabriel Blanchard <gabe at teksavvy.ca>
>> wrote:
>>
>>> Bash related?
>>>
>>>> On Sep 24, 2014, at 4:47 PM, "Grant Ridder" <shortdudey123 at gmail.com>
>>> wrote:
>>>>
>>>> As an FYI,  it looks like Amazon is doing a mass reboot of the physical
>>>> hosts in us-west-2 across all AZ's and it is scheduled to start
>> tomorrow
>>>> and take a couple days.
>>>> Go to *
>>> https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events
>>>> <https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Events>:*
>>> to
>>>> see what instances are affected when.
>>>>
>>>> -Grant
>>>
>>
>

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------


From bill at herrin.us  Thu Sep 25 02:29:25 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 24 Sep 2014 22:29:25 -0400
Subject: update
In-Reply-To: <5423558C.7020401@mindspring.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
Message-ID: <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>

On Wed, Sep 24, 2014 at 7:36 PM, Daniel Jackson <fdj at mindspring.com> wrote:
> On 09/24/2014 07:22 PM, Jim Popovitch wrote:
>> That won't automatically invoke bash on Debian/Ubuntu....unless someone
>> intentionally changed default shells....
>
> People seem not to know that Debian and derivatives use a variant Almquist
> shell rather than bash for system accounts.

You're both wrong.

$ cat /etc/issue
Debian GNU/Linux 7 \n \l

$ ls -laF /bin/sh
lrwxrwxrwx 1 root root 4 Nov 17  2011 /bin/sh -> bash*
$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash


If you installed Debian from scratch in the last couple of years you
might have gotten a different system shell. Those of us who have been
using Debian for a *long time*  were asked once during one upgrade
whether we wanted the upgrade to change our defaults and generally
said no.

Welcome to production fellas, where the bleeding edge latest thing
isn't what's installed.

Regards,
Bill Herrin

-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From rodrigo at 1telecom.com.br  Thu Sep 25 01:46:27 2014
From: rodrigo at 1telecom.com.br (Rodrigo Augusto)
Date: Wed, 24 Sep 2014 22:46:27 -0300
Subject: Oi Assistance
In-Reply-To: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
References: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
Message-ID: <D1DFC10B-16E4-41F9-BDD9-AEA5415B95A5@1telecom.com.br>

Hi Brian... I am not from oi( asn 7738), i am a customer from oi... But, can i try to help you?! 
I don't have any dificult with oi( estabilish bgp peer, route filters, ipv6 peering with 7738 etc).
 what you want? 
Could you help?!
Enviado via iPhone ?
Grupo Connectoway

> Em 24/09/2014, ?s 18:02, Brian Free <brfree at adobe.com> escreveu:
> 
> Hi NANOG,
> I'm hoping someone out there has had some experience with Oi Telecommunications.  We've been struggling to work with them to get a couple of circuits in Sao Paulo live.  The primary problem is mostly a language barrier.  Is anyone aware of an English speaking NOC email address or phone number for Oi?  After months of back and forth through a third party translator working with our account team, I've reached my limit and am hoping there's another option to get some technical assistance with the BGP configuration of these two circuits.  Any advice will be appreciated.
> 
> Thanks,
> Brian
> 



From jimpop at gmail.com  Thu Sep 25 02:43:30 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 22:43:30 -0400
Subject: update
In-Reply-To: <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
Message-ID: <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>

On Wed, Sep 24, 2014 at 10:29 PM, William Herrin <bill at herrin.us> wrote:
> On Wed, Sep 24, 2014 at 7:36 PM, Daniel Jackson <fdj at mindspring.com> wrote:
>> On 09/24/2014 07:22 PM, Jim Popovitch wrote:
>>> That won't automatically invoke bash on Debian/Ubuntu....unless someone
>>> intentionally changed default shells....
>>
>> People seem not to know that Debian and derivatives use a variant Almquist
>> shell rather than bash for system accounts.
>
> You're both wrong.
>
> $ cat /etc/issue
> Debian GNU/Linux 7 \n \l
>
> $ ls -laF /bin/sh
> lrwxrwxrwx 1 root root 4 Nov 17  2011 /bin/sh -> bash*
> $ grep root /etc/passwd
> root:x:0:0:root:/root:/bin/bash

You have done something wrong/different than what appears on a
relatively clean install:

$ cat /etc/issue
Debian GNU/Linux 7 \n \l

$ cat /etc/debian_version
7.6

$ ls -laF /bin/sh
lrwxrwxrwx 1 root root 4 Mar  1  2012 /bin/sh -> dash*

$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/sh

I'm curious now... did you install a server or desktop version of
Debian?  Was if from netinst or cds, etc.?

-Jim P.


From bill at herrin.us  Thu Sep 25 02:49:22 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 24 Sep 2014 22:49:22 -0400
Subject: update
In-Reply-To: <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
Message-ID: <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>

On Wed, Sep 24, 2014 at 10:43 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> You have done something wrong/different than what appears on a
> relatively clean install:

Since you didn't read it, I'm gonna repeat it:

"If you installed Debian from scratch in the last couple of years you
might have gotten a different system shell. Those of us who have been
using Debian for a *long time*  were asked once during one upgrade
whether we wanted the upgrade to change our defaults and generally
said no.

Welcome to production fellas, where the bleeding edge latest thing
isn't what's installed."

-Bill



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From jimpop at gmail.com  Thu Sep 25 02:52:12 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 22:52:12 -0400
Subject: update
In-Reply-To: <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>
Message-ID: <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>

On Wed, Sep 24, 2014 at 10:49 PM, William Herrin <bill at herrin.us> wrote:
> On Wed, Sep 24, 2014 at 10:43 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>> You have done something wrong/different than what appears on a
>> relatively clean install:
>
> Since you didn't read it, I'm gonna repeat it:
>
> "If you installed Debian from scratch in the last couple of years you
> might have gotten a different system shell. Those of us who have been
> using Debian for a *long time*  were asked once during one upgrade
> whether we wanted the upgrade to change our defaults and generally
> said no.
>
> Welcome to production fellas, where the bleeding edge latest thing
> isn't what's installed."


I *did* read that, and it doesn't change anything about what I wrote.
Debian didn't make those changes for you......   Debian has never set
root's shell to bash, ever.   PEBKAC?

-Jim P.


From randy at psg.com  Thu Sep 25 02:53:35 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 25 Sep 2014 11:53:35 +0900
Subject: bored with bash, read this one
Message-ID: <m2egv0mmvk.wl%randy@psg.com>

paper this morning at a really good ches <http://www.chesworkshop.org/ches2014/>
SCA-obsessed conference

"Get Your Hands Off My Laptop: Physical Side-Channel Key-Extraction Attacks On PCs"
http://eprint.iacr.org/2014/626
http://www.tau.ac.il/~tromer/handsoff/

gets your gpg private key damned quickly

randy


From bill at herrin.us  Thu Sep 25 02:56:10 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 24 Sep 2014 22:56:10 -0400
Subject: update
In-Reply-To: <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>
 <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>
Message-ID: <CAP-guGV91tJYgfugxUtS6LuEDK7Z6nTTR7S0eV1mEHtY4vyA=g@mail.gmail.com>

On Wed, Sep 24, 2014 at 10:52 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> I *did* read that, and it doesn't change anything about what I wrote.
> Debian didn't make those changes for you......   Debian has never set
> root's shell to bash, ever.   PEBKAC?

I've been running Debian for longer than the dash shell has existed.
What do you imagine the default shell was back then?

Definitely PEBKAC. You just picked the wrong chair.

-Bill


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From mysidia at gmail.com  Thu Sep 25 02:56:43 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 24 Sep 2014 21:56:43 -0500
Subject: update
In-Reply-To: <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
Message-ID: <CAAAwwbUXpsZaiD7xiRpCjFG8FLVKUHxp_Azvzz0VopLPVgu8Fw@mail.gmail.com>

On Wed, Sep 24, 2014 at 9:43 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> You have done something wrong/different than what appears on a
> relatively clean install:
>
> $ cat /etc/debian_version
> 7.6
> $ ls -laF /bin/sh
> lrwxrwxrwx 1 root root 4 Mar  1  2012 /bin/sh -> dash*

What is this fabled 7.6 that you speak of?  :)


:~# cat /etc/debian_version
4.0

:~# ls -ld /bin/sh

lrwxrwxrwx 1 root root 4 2014-02-22 11:52 /bin/sh -> bash



--
-JH


From bill at herrin.us  Thu Sep 25 03:03:42 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 24 Sep 2014 23:03:42 -0400
Subject: update
In-Reply-To: <CAAAwwbUXpsZaiD7xiRpCjFG8FLVKUHxp_Azvzz0VopLPVgu8Fw@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAAAwwbUXpsZaiD7xiRpCjFG8FLVKUHxp_Azvzz0VopLPVgu8Fw@mail.gmail.com>
Message-ID: <CAP-guGXtO0NSfzEw47YCJ-Feb=xSK7f_oGAx7p4mVYsAW_nSCw@mail.gmail.com>

On Wed, Sep 24, 2014 at 10:56 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Wed, Sep 24, 2014 at 9:43 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>> You have done something wrong/different than what appears on a
>> relatively clean install:
>>
>> $ cat /etc/debian_version
>> 7.6
>> $ ls -laF /bin/sh
>> lrwxrwxrwx 1 root root 4 Mar  1  2012 /bin/sh -> dash*
>
> What is this fabled 7.6 that you speak of?  :)
>
>
> :~# cat /etc/debian_version
> 4.0
>
> :~# ls -ld /bin/sh
>
> lrwxrwxrwx 1 root root 4 2014-02-22 11:52 /bin/sh -> bash

ROFL. Jimmy, please tell me you had to start up a VM to check that. :)

-Bill


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Can I solve your unusual networking challenges?


From swmike at swm.pp.se  Thu Sep 25 03:11:22 2014
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 25 Sep 2014 05:11:22 +0200 (CEST)
Subject: update
In-Reply-To: <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>
 <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1409250507380.14735@uplift.swm.pp.se>

On Wed, 24 Sep 2014, Jim Popovitch wrote:

> I *did* read that, and it doesn't change anything about what I wrote. 
> Debian didn't make those changes for you......  Debian has never set 
> root's shell to bash, ever.  PEBKAC?

I can verify Williams settings on my Debian system that was initially 
installed back in 3.x days or so, probably around 2005 or thereabouts. My 
root shell uses bash and /bin/sh points to bash. I probably received a 
question about this sometime long ago when upgrading but I guess I 
answered no.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


From jimpop at gmail.com  Thu Sep 25 03:14:19 2014
From: jimpop at gmail.com (Jim Popovitch)
Date: Wed, 24 Sep 2014 23:14:19 -0400
Subject: update
In-Reply-To: <CAP-guGV91tJYgfugxUtS6LuEDK7Z6nTTR7S0eV1mEHtY4vyA=g@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>
 <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>
 <CAP-guGV91tJYgfugxUtS6LuEDK7Z6nTTR7S0eV1mEHtY4vyA=g@mail.gmail.com>
Message-ID: <CAGfsgR1nts3-AaY1kk+07ZFgP+m6i6j9fUNrATrzm5xWcN-KfQ@mail.gmail.com>

On Sep 24, 2014 10:56 PM, "William Herrin" <bill at herrin.us> wrote:
>
> On Wed, Sep 24, 2014 at 10:52 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> > I *did* read that, and it doesn't change anything about what I wrote.
> > Debian didn't make those changes for you......   Debian has never set
> > root's shell to bash, ever.   PEBKAC?
>
> I've been running Debian for longer than the dash shell has existed.
> What do you imagine the default shell was back then?

chisel & stone?   :-)  j/k I'm probably also old enough to remember, but I
don't really care to.

> Definitely PEBKAC. You just picked the wrong chair.

I'm seeing that.

-Jim P.


From mysidia at gmail.com  Thu Sep 25 03:19:03 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 24 Sep 2014 22:19:03 -0500
Subject: update
In-Reply-To: <CAP-guGXtO0NSfzEw47YCJ-Feb=xSK7f_oGAx7p4mVYsAW_nSCw@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAAAwwbUXpsZaiD7xiRpCjFG8FLVKUHxp_Azvzz0VopLPVgu8Fw@mail.gmail.com>
 <CAP-guGXtO0NSfzEw47YCJ-Feb=xSK7f_oGAx7p4mVYsAW_nSCw@mail.gmail.com>
Message-ID: <CAAAwwbUB_b0VUU_-2hrrqsJS+gBq-7Dyf-mUhcFeLLzy+0whzQ@mail.gmail.com>

On Wed, Sep 24, 2014 at 10:03 PM, William Herrin <bill at herrin.us> wrote:
>> lrwxrwxrwx 1 root root 4 2014-02-22 11:52 /bin/sh -> bash
>
> ROFL. Jimmy, please tell me you had to start up a VM to check that. :)

Not a live system,  but aside from honeypots,  there really are
embedded appliances and  companies with websites still in production
based on LAMP installations on Etch and  Lenny.

I understand the dash shell wasn't introduced until Debian Squeeze
(6.0),  which is in the past 4 years.

> -Bill
--
-JH


From reed at reedloden.com  Thu Sep 25 03:41:38 2014
From: reed at reedloden.com (Reed Loden)
Date: Wed, 24 Sep 2014 20:41:38 -0700
Subject: AWS EC2 us-west-2 reboot
In-Reply-To: <alpine.BSF.2.00.1409242127330.88890@nog.angryox.com>
References: <CAPiURgX51b3trghF7M916KQk3+fQcuR9C3qQTReQ5rbysHR=VQ@mail.gmail.com>
 <BA8132E6-AC26-4F1C-8C1D-48E23EAEFCFF@teksavvy.ca>
 <CAPiURgXLpqX5msowQfUbqtXKtg3WxoH2gvc98DPmWuE-UTQn5Q@mail.gmail.com>
 <CA+M5dWb3F5e5avL976zptCkQXHrYC159dowth1uv9hfC+mpgew@mail.gmail.com>
 <alpine.BSF.2.00.1409242127330.88890@nog.angryox.com>
Message-ID: <20140924204138.5a6bdf1d.reed@reedloden.com>

On Wed, 24 Sep 2014 21:39:39 -0400
Peter Beckman <beckman at angryox.com> wrote:

> Likely some sort of potentially serious bug or flaw in EC2 or Xen. AWS
> Security is really on the ball on such things and do everything they can to
> make invisible fixes with no customer impact, but sometimes a reboot is
> required in order to apply the changes necessary to keep customer instances
> safe from attacks and vulnerabilities.

Rumor mill is that it's XSA-108, embargoed until 2014-10-01 12:00
(http://xenbits.xen.org/xsa/). Just somebody's guess, though, afaik.

~reed


From randy at psg.com  Thu Sep 25 04:05:45 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 25 Sep 2014 13:05:45 +0900
Subject: update
In-Reply-To: <54231DA1.6020703@frii.net>
References: <m24mvwq1oz.wl%randy@psg.com> <542316DF.50404@frii.net>
 <m2zjdoomv8.wl%randy@psg.com> <54231DA1.6020703@frii.net>
Message-ID: <m2bnq4mjja.wl%randy@psg.com>

> Keeping silent after the embargo is over isn't doing anyone any
> favors. 

when do you think the embargo is over?

yes, it got blabbed.  but that does not mean one should be a blabber.

randy


From DStaal at usa.net  Thu Sep 25 04:38:07 2014
From: DStaal at usa.net (Daniel Staal)
Date: Thu, 25 Sep 2014 00:38:07 -0400
Subject: update
In-Reply-To: <m24mvwq1oz.wl%randy@psg.com>
References: <m24mvwq1oz.wl%randy@psg.com>
Message-ID: <4A048AC5603629B2E5CD5B3F@[192.168.1.50]>

--As of September 25, 2014 4:05:16 AM +0900, Randy Bush is alleged to have 
said:

> there is an update out you want.  badly.
> debian/ubuntu admins may want to apt-get update/upgrade or whatever
> freebsd similarly
> can not speak for other systems

--As for the rest, it is mine.

FreeBSD (and other BSDs, as far as I can tell) are not affected unless the 
admin has installed bash specifically; it's not part of the default 
install.  It may however have been installed as part of the requirements 
for something else.

This also should mean that the vulnerability is a bit more limited than in 
systems that use bash for /bin/sh: Even if you've installed bash, you 
aren't as likely to be running it in CGI or other similar contexts.  (Not 
that that means it's blocked entirely if you've installed it, but it should 
help.)

As of Wednsday afternoon, FreeBSD ports had the update but packages did not 
yet.

Daniel T. Staal

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


From nanog at veggiechinese.net  Thu Sep 25 04:41:04 2014
From: nanog at veggiechinese.net (Will Yardley)
Date: Wed, 24 Sep 2014 21:41:04 -0700
Subject: update
In-Reply-To: <alpine.DEB.2.02.1409250507380.14735@uplift.swm.pp.se>
References: <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAP-guGWh9hmPYHXF8isUDFuqY+GXpvH2f1qFnR0LbTgy0Z_oMA@mail.gmail.com>
 <CAGfsgR3Las8WFC7Kc8DNXoJqbANO6Z-7GQGo=yZCP11yFM2T6A@mail.gmail.com>
 <alpine.DEB.2.02.1409250507380.14735@uplift.swm.pp.se>
Message-ID: <20140925044103.GA26159@aura.veggiechinese.net>

On Thu, Sep 25, 2014 at 05:11:22AM +0200, Mikael Abrahamsson wrote:
> On Wed, 24 Sep 2014, Jim Popovitch wrote:
> 
> > I *did* read that, and it doesn't change anything about what I wrote. 
> > Debian didn't make those changes for you......  Debian has never set 
> > root's shell to bash, ever.  PEBKAC?
> 
> I can verify Williams settings on my Debian system that was initially 
> installed back in 3.x days or so, probably around 2005 or thereabouts. My 
> root shell uses bash and /bin/sh points to bash.

I haven't administered many Debian / Ubuntu systems recently, but I did
during the days of hamm / slink / potato, and my recollection is that
the *default* /bin/sh in 2.x and 3.x was bash, though it was possible to
configure the system to use ash or something lighter weight instead.
Doubt I currently have access to any systems that old, but:

% cat /etc/debian_version 
5.0.4
% ls -al /bin/sh 
lrwxrwxrwx 1 root root 4 2009-03-05 16:58 /bin/sh -> bash*
% which dash                         
dash not found

$ cat /etc/debian_version 
5.0.9
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 2010-08-02 12:21 /bin/sh -> bash*

So, I think "never... ever" is maybe not quite correct.

w



From hugo at slabnet.com  Thu Sep 25 04:41:43 2014
From: hugo at slabnet.com (Hugo Slabbert)
Date: Wed, 24 Sep 2014 21:41:43 -0700
Subject: update
In-Reply-To: <m2bnq4mjja.wl%randy@psg.com>
References: <m24mvwq1oz.wl%randy@psg.com> <542316DF.50404@frii.net>
 <m2zjdoomv8.wl%randy@psg.com> <54231DA1.6020703@frii.net>
 <m2bnq4mjja.wl%randy@psg.com>
Message-ID: <20140925044143.GA5456@bamboo.slabnet.com>

>when do you think the embargo is over?

ref: http://seclists.org/oss-sec/2014/q3/650

"At present, public disclosure is scheduled for Wednesday, 2014-09-24
14:00 UTC.  We do not expect the schedule to change, but we may be
forced to revise it."

>Date: Wed, 24 Sep 2014 15:07:26 -0400
>From: Jared Mauch <jared at puck.nether.net>
>To: Randy Bush <randy at psg.com>
>Cc: North American Network Operators' Group <nanog at nanog.org>
>Subject: Re: update
>X-Mailer: Apple Mail (2.1985.4)
>
>Can I presume you?re talking about the bash CVE-2014-6271?

>Date: Wed, 24 Sep 2014 13:09:19 -0600
>From: Spencer Gaw <spencerg at frii.net>
>To: Randy Bush <randy at psg.com>, North American Network Operators' Group 
><nanog at nanog.org>
>Subject: Re: update
>User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 
>Thunderbird/31.1.1
>
>See: http://seclists.org/oss-sec/2014/q3/650

Both are > 2014-09-24 14:00 UTC by my count.  Unless the embargo got 
extended?

On Thu 2014-Sep-25 13:05:45 +0900, Randy Bush <randy at psg.com> wrote:

>> Keeping silent after the embargo is over isn't doing anyone any
>> favors.
>
>when do you think the embargo is over?
>
>yes, it got blabbed.  but that does not mean one should be a blabber.
>
>randy

-- 
Hugo


From joesox at gmail.com  Thu Sep 25 14:31:28 2014
From: joesox at gmail.com (JoeSox)
Date: Thu, 25 Sep 2014 07:31:28 -0700
Subject: update
In-Reply-To: <20140925044143.GA5456@bamboo.slabnet.com>
References: <m24mvwq1oz.wl%randy@psg.com> <542316DF.50404@frii.net>
 <m2zjdoomv8.wl%randy@psg.com> <54231DA1.6020703@frii.net>
 <m2bnq4mjja.wl%randy@psg.com>
 <20140925044143.GA5456@bamboo.slabnet.com>
Message-ID: <CAAXNyuA3pa5yRgrrgQOb=FCUwApRh7STeRWpZOXyQZrZdaEqyA@mail.gmail.com>

Does anyone know if there is official/unofficial vendor/manufacturer list
yet to all their official Vulnerability webpage info?
I thought I saw some when Heartbleed broke out.
--
Later, Joe

On Wed, Sep 24, 2014 at 9:41 PM, Hugo Slabbert <hugo at slabnet.com> wrote:

> when do you think the embargo is over?
>>
>
> ref: http://seclists.org/oss-sec/2014/q3/650
>
> "At present, public disclosure is scheduled for Wednesday, 2014-09-24
> 14:00 UTC.  We do not expect the schedule to change, but we may be
> forced to revise it."
>
>  Date: Wed, 24 Sep 2014 15:07:26 -0400
>> From: Jared Mauch <jared at puck.nether.net>
>> To: Randy Bush <randy at psg.com>
>> Cc: North American Network Operators' Group <nanog at nanog.org>
>> Subject: Re: update
>> X-Mailer: Apple Mail (2.1985.4)
>>
>> Can I presume you?re talking about the bash CVE-2014-6271?
>>
>
>  Date: Wed, 24 Sep 2014 13:09:19 -0600
>> From: Spencer Gaw <spencerg at frii.net>
>> To: Randy Bush <randy at psg.com>, North American Network Operators' Group <
>> nanog at nanog.org>
>> Subject: Re: update
>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101
>> Thunderbird/31.1.1
>>
>> See: http://seclists.org/oss-sec/2014/q3/650
>>
>
> Both are > 2014-09-24 14:00 UTC by my count.  Unless the embargo got
> extended?
>
>
> On Thu 2014-Sep-25 13:05:45 +0900, Randy Bush <randy at psg.com> wrote:
>
>  Keeping silent after the embargo is over isn't doing anyone any
>>> favors.
>>>
>>
>> when do you think the embargo is over?
>>
>> yes, it got blabbed.  but that does not mean one should be a blabber.
>>
>> randy
>>
>
> --
> Hugo
>


From humbertogaliza at gmail.com  Thu Sep 25 20:58:55 2014
From: humbertogaliza at gmail.com (Humberto Galiza)
Date: Thu, 25 Sep 2014 17:58:55 -0300
Subject: Oi Assistance
In-Reply-To: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
References: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
Message-ID: <CAByG9DOhzpw2S+6N3OV6ARvj_C7P31bdJiS00grM0EfaCFV_+Q@mail.gmail.com>

Brian,

I?m not an AS7738 customer neither a member, but perhaps I can get
some information/help from a friend who works there. What kind of
information/assistance are you looking for?

FYI, most of folks whose aren?t AS7738 customer, experience bad/long
time to get technical assistance or response; it?s not just you :)
Humberto Galiza


2014-09-24 18:02 GMT-03:00 Brian Free <brfree at adobe.com>:
> Hi NANOG,
> I'm hoping someone out there has had some experience with Oi Telecommunications.  We've been struggling to work with them to get a couple of circuits in Sao Paulo live.  The primary problem is mostly a language barrier.  Is anyone aware of an English speaking NOC email address or phone number for Oi?  After months of back and forth through a third party translator working with our account team, I've reached my limit and am hoping there's another option to get some technical assistance with the BGP configuration of these two circuits.  Any advice will be appreciated.
>
> Thanks,
> Brian
>


From brfree at adobe.com  Thu Sep 25 21:09:34 2014
From: brfree at adobe.com (Brian Free)
Date: Thu, 25 Sep 2014 21:09:34 +0000
Subject: Oi Assistance
In-Reply-To: <CAByG9DOhzpw2S+6N3OV6ARvj_C7P31bdJiS00grM0EfaCFV_+Q@mail.gmail.com>
References: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
 <CAByG9DOhzpw2S+6N3OV6ARvj_C7P31bdJiS00grM0EfaCFV_+Q@mail.gmail.com>
Message-ID: <e15ef443a14044dd8017a1facee5b9ad@DM2PR02MB350.namprd02.prod.outlook.com>

Humberto,
I have been contacted by a couple of engineers inside of Oi or its subsidiaries.  I'm pursuing those options at the moment, but sincerely appreciate your offer of assistance.  I'm not sure whether I'm glad to hear that it's not just me or whether I find that to be even more discouraging.  :)

Thanks,
Brian

-----Original Message-----
From: Humberto Galiza [mailto:humbertogaliza at gmail.com] 
Sent: Thursday, September 25, 2014 2:59 PM
To: Brian Free
Cc: nanog at nanog.org
Subject: Re: Oi Assistance

Brian,

I?m not an AS7738 customer neither a member, but perhaps I can get some information/help from a friend who works there. What kind of information/assistance are you looking for?

FYI, most of folks whose aren?t AS7738 customer, experience bad/long time to get technical assistance or response; it?s not just you :) Humberto Galiza


2014-09-24 18:02 GMT-03:00 Brian Free <brfree at adobe.com>:
> Hi NANOG,
> I'm hoping someone out there has had some experience with Oi Telecommunications.  We've been struggling to work with them to get a couple of circuits in Sao Paulo live.  The primary problem is mostly a language barrier.  Is anyone aware of an English speaking NOC email address or phone number for Oi?  After months of back and forth through a third party translator working with our account team, I've reached my limit and am hoping there's another option to get some technical assistance with the BGP configuration of these two circuits.  Any advice will be appreciated.
>
> Thanks,
> Brian
>

From fred.crandall at whidbeytel.com  Thu Sep 25 18:27:13 2014
From: fred.crandall at whidbeytel.com (Fred Crandall)
Date: Thu, 25 Sep 2014 11:27:13 -0700
Subject: hotmail/msn/outlook mail admin contact
Message-ID: <20140925182713.GA40489@fred-rmbp15.whidbeytel.com>

Hello NANOG'ers,

Looking for a mail admin contact over at Microsoft who deals with the outgoing mail servers related to hotmail.com/msn.com/outlook.com.

Feel free to contact me privately.

Thank you.

Fred Crandall
Sr Systems Admin
Whidbey Telecom


From jeroen at mompl.net  Fri Sep 26 00:55:18 2014
From: jeroen at mompl.net (Jeroen van Aart)
Date: Thu, 25 Sep 2014 17:55:18 -0700
Subject: bored with bash, read this one
In-Reply-To: <m2egv0mmvk.wl%randy@psg.com>
References: <m2egv0mmvk.wl%randy@psg.com>
Message-ID: <5424B976.8040805@mompl.net>

On 09/24/2014 07:53 PM, Randy Bush wrote:
> "Get Your Hands Off My Laptop: Physical Side-Channel Key-Extraction Attacks On PCs"
> http://eprint.iacr.org/2014/626
> http://www.tau.ac.il/~tromer/handsoff/
>
> gets your gpg private key damned quickly

Only 4 pages into reading the pdf, but it's an excellent read, thanks.

-- 
Earthquake Magnitude: 5.2
Date: 2014-09-25  18:59:59.790 UTC
Date Local: 2014-09-25 11:59:59 PDT
Location: 83km NNW of Visokoi Island,
Latitude: -55.9853; Longitude: -27.6086
Depth: 112.94 km | e-quake.org


From randy at psg.com  Fri Sep 26 01:52:34 2014
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Sep 2014 10:52:34 +0900
Subject: bored with bash, read this one
In-Reply-To: <5424B976.8040805@mompl.net>
References: <m2egv0mmvk.wl%randy@psg.com>
	<5424B976.8040805@mompl.net>
Message-ID: <m2eguzi1wd.wl%randy@psg.com>

>> "Get Your Hands Off My Laptop: Physical Side-Channel Key-Extraction Attacks On PCs"
>> http://eprint.iacr.org/2014/626
>> http://www.tau.ac.il/~tromer/handsoff/
>> gets your gpg private key damned quickly
> Only 4 pages into reading the pdf, but it's an excellent read, thanks.

also an excellent and fun presenter, who took the risk of a live demo.
unfortunately, ches is still a pretty classic academic conference, so
the idea of streaming or of storing video is not on the radar.

randy


From joly at punkcast.com  Fri Sep 26 02:59:26 2014
From: joly at punkcast.com (Joly MacFie)
Date: Thu, 25 Sep 2014 22:59:26 -0400
Subject: update
In-Reply-To: <CAAXNyuA3pa5yRgrrgQOb=FCUwApRh7STeRWpZOXyQZrZdaEqyA@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com> <542316DF.50404@frii.net>
 <m2zjdoomv8.wl%randy@psg.com> <54231DA1.6020703@frii.net>
 <m2bnq4mjja.wl%randy@psg.com>
 <20140925044143.GA5456@bamboo.slabnet.com>
 <CAAXNyuA3pa5yRgrrgQOb=FCUwApRh7STeRWpZOXyQZrZdaEqyA@mail.gmail.com>
Message-ID: <CAM9VJk3wkcWhT7uj6SUv4OJ9LTSMr=0HMkqrqQbki1z8iewkBQ@mail.gmail.com>

fsf put out a statement

https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability


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


From randy at psg.com  Fri Sep 26 04:45:22 2014
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Sep 2014 13:45:22 +0900
Subject: thailand
Message-ID: <m2lhp7gfbx.wl%randy@psg.com>

any gossip of cable or other bandwidth issues into bangkok?

randy


From randy at psg.com  Fri Sep 26 06:16:35 2014
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Sep 2014 15:16:35 +0900
Subject: thailand
In-Reply-To: <m2lhp7gfbx.wl%randy@psg.com>
References: <m2lhp7gfbx.wl%randy@psg.com>
Message-ID: <m2bnq2hpoc.wl%randy@psg.com>

answer received, thanks gary.  i have been under water for a couple of
weeks.

randy


From arturo.servin at gmail.com  Fri Sep 26 12:27:25 2014
From: arturo.servin at gmail.com (Arturo Servin)
Date: Fri, 26 Sep 2014 13:27:25 +0100
Subject: Oi Assistance
In-Reply-To: <e15ef443a14044dd8017a1facee5b9ad@DM2PR02MB350.namprd02.prod.outlook.com>
References: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
 <CAByG9DOhzpw2S+6N3OV6ARvj_C7P31bdJiS00grM0EfaCFV_+Q@mail.gmail.com>
 <e15ef443a14044dd8017a1facee5b9ad@DM2PR02MB350.namprd02.prod.outlook.com>
Message-ID: <CALo9H1aXpYKpbx2Cqr6Lv7kHyfwpwNRKd+xSR22kevPgwMPXQw@mail.gmail.com>

Try LACNOG or GTER (aka Brazilian NOG group) emailing list.

May be somebody there could help.

Regards
as


On Thu, Sep 25, 2014 at 10:09 PM, Brian Free <brfree at adobe.com> wrote:

> Humberto,
> I have been contacted by a couple of engineers inside of Oi or its
> subsidiaries.  I'm pursuing those options at the moment, but sincerely
> appreciate your offer of assistance.  I'm not sure whether I'm glad to hear
> that it's not just me or whether I find that to be even more discouraging.
> :)
>
> Thanks,
> Brian
>
> -----Original Message-----
> From: Humberto Galiza [mailto:humbertogaliza at gmail.com]
> Sent: Thursday, September 25, 2014 2:59 PM
> To: Brian Free
> Cc: nanog at nanog.org
> Subject: Re: Oi Assistance
>
> Brian,
>
> I?m not an AS7738 customer neither a member, but perhaps I can get some
> information/help from a friend who works there. What kind of
> information/assistance are you looking for?
>
> FYI, most of folks whose aren?t AS7738 customer, experience bad/long time
> to get technical assistance or response; it?s not just you :) Humberto
> Galiza
>
>
> 2014-09-24 18:02 GMT-03:00 Brian Free <brfree at adobe.com>:
> > Hi NANOG,
> > I'm hoping someone out there has had some experience with Oi
> Telecommunications.  We've been struggling to work with them to get a
> couple of circuits in Sao Paulo live.  The primary problem is mostly a
> language barrier.  Is anyone aware of an English speaking NOC email address
> or phone number for Oi?  After months of back and forth through a third
> party translator working with our account team, I've reached my limit and
> am hoping there's another option to get some technical assistance with the
> BGP configuration of these two circuits.  Any advice will be appreciated.
> >
> > Thanks,
> > Brian
> >
>


From dave at temk.in  Fri Sep 26 14:24:41 2014
From: dave at temk.in (Dave Temkin)
Date: Fri, 26 Sep 2014 10:24:41 -0400
Subject: NANOG College Immersion Program
Message-ID: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>

I'm excited to announce that for NANOG 63 in San Antonio that we will begin
the NANOG College Immersion Program. This program aims to provide the next
generation of Network Operators with an edge in today's highly competitive
market and allows us a conduit of highly capable operators, engineers, and
architects.

Please see below for the full program description.

Regards,
-Dave Temkin, for the NANOG Board of Directors


NANOG College Immersion Program

Summary:

NANOG is committed to ensuring next generation of networking professionals
have an opportunity become part of the operational community that makes the
internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
Yahoo, and Amazon rely on NANOG to discuss key architectural and
operational topics relevant to Internet infrastructure. NANOG believes by
introducing undergraduates to our vibrant community before entering the job
marketplace, they will have a better understanding of how the
infrastructure of the Internet works and how they might participate after
graduation. Further, students may be able to find internship opportunities
they may have not otherwise found.

Offering:

NANOG will provide an expenses-paid trip to the current meeting for up to
25 students per meeting. The paid expenses will include:

   -

   Airfare (up to $500)
   -

   Four nights of hotel (must be booked by NANOG staff)
   -

   Ground transportation (reasonable cost)
   -

   Meal stipend (adjusted for meeting location)



NANOG will also, space permitting, allow free admission for students to the
NANOG Education Series (https://www.nanog.org/meetings/education/home)
class prior to the meeting they are attending.

NANOG will provide guidance to students as to what they may and may not
attend. Of note, alcohol is served at some NANOG events and there is the
expectation that those not legally entitled to consume alcohol will refrain
from doing so. NANOG takes no responsibility for those that break the law
during their meetings and reserves the right to refuse admission to those
that violate our Attendance Charter.


Expectation:

NANOG will not be involved in any syllabus or coursework for the students.
The NANOG organization will provide an agenda and slideware for the
materials that the students will be viewing and expects their professor to
determine the best way their students can extract educational value from
the NANOG program. NANOG asks, in return, that all students complete our
surveys in full and that their teaching staff provide us with a summary of
how they used our program in the classroom and/or in coursework. A few
paragraphs from each student explaining the value that they got from the
program and social interactions would also be a good idea.


Q&A:

Q: What is NANOG and what is the value proposition for sending a student to
this conference?

A: The North American Network Operators Group or NANOG, is the professional
association for Internet engineering and architecture. Our core focus is on
the technologies and systems that make the Internet function: core routing
and switching; Internet inter-domain routing; the domain name system;
peering and interconnection; and Internet core security. We also cover
associated areas with a direct impact on Internet architecture such as data
centers and optical networking.  The value proposition for the student is
exposure to all of these subjects and technical material but more
importantly to the organizations and individuals.  The opportunity for
students to make industry contacts is invaluable.

Q: How do we select students for this sponsorship?

A: Send your best and brightest, highlight that the value is the density of
industry representatives in a common location.

Q: What do the students owe back to NANOG?

A: In addition to the anonymous surveys that all attendees are asked to
complete, the NANOG Board would request that all sponsorship recipients
provide feedback on their experiences.  Lastly, we would like to encourage
the students join the mailing list (nanog at nanog.org), attend more
conferences and get involved in the industry.

Q: How do we evaluate our students participation?

A: Students could provide a variety of deliverables back to the
institution.  These could include a writeup of selected presentations from
the agenda, an overview of the conference as a whole, or even a list of the
individuals they met during the conference.

Q: What will be covered in the sponsorship?

A: Hotel, conference fee, airfare, and a reasonable stipend for incidentals
such as meals.

Q: Why are you sponsoring our students for this conference?

A: The NANOG organization is keen to encourage the future technology
leaders and innovators to get interested and involved in this segment of
the industry.


From jg at freedesktop.org  Fri Sep 26 14:37:06 2014
From: jg at freedesktop.org (Jim Gettys)
Date: Fri, 26 Sep 2014 10:37:06 -0400
Subject: update
In-Reply-To: <CAAAwwbUB_b0VUU_-2hrrqsJS+gBq-7Dyf-mUhcFeLLzy+0whzQ@mail.gmail.com>
References: <m24mvwq1oz.wl%randy@psg.com>
 <CAGfsgR1rkC_mdAQYsbNusegcbAm-zakvxohoqbQw5e_d0TOoUw@mail.gmail.com>
 <CAPf5k+6L5JiHoK8ctW0YkwYhzTVV489201fQ7Vcv822SLO7y=A@mail.gmail.com>
 <CAGfsgR1a5brii8HyXvbYXfsWefi8ZXCg31XL5jxG_tc-PUUCrQ@mail.gmail.com>
 <5423473C.1030805@mtcc.com>
 <CAGfsgR1a7Y_RCVTdpy8a5YDPMTaLWKivac0eW9pE5GZv1TQjEQ@mail.gmail.com>
 <34137.1411599639@turing-police.cc.vt.edu>
 <CAGfsgR2hJyf+RfpMR2TJD5A_=isz28Lq1pwbm-H4D3aACL5z7g@mail.gmail.com>
 <5423558C.7020401@mindspring.com>
 <CAP-guGVo7V-oDs-nbFkUgJYHo41YFqYRe=MCU4s97LxFanvf1A@mail.gmail.com>
 <CAGfsgR02M0F4AoD0X9r12y6NeND3+mwpC_gWDfig67F8n41HQQ@mail.gmail.com>
 <CAAAwwbUXpsZaiD7xiRpCjFG8FLVKUHxp_Azvzz0VopLPVgu8Fw@mail.gmail.com>
 <CAP-guGXtO0NSfzEw47YCJ-Feb=xSK7f_oGAx7p4mVYsAW_nSCw@mail.gmail.com>
 <CAAAwwbUB_b0VUU_-2hrrqsJS+gBq-7Dyf-mUhcFeLLzy+0whzQ@mail.gmail.com>
Message-ID: <CAGhGL2BLs0jhjGOU1DSqjt369pFNf_=+R_uStvBRVe8WikWXtA@mail.gmail.com>

On Wed, Sep 24, 2014 at 11:19 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Wed, Sep 24, 2014 at 10:03 PM, William Herrin <bill at herrin.us> wrote:
> >> lrwxrwxrwx 1 root root 4 2014-02-22 11:52 /bin/sh -> bash
> >
> > ROFL. Jimmy, please tell me you had to start up a VM to check that. :)
>
> Not a live system,  but aside from honeypots,  there really are
> embedded appliances and  companies with websites still in production
> based on LAMP installations on Etch and  Lenny.
>

?Lots of small embedded Linux systems (e.g. your home router), are *not*
vulnerable to this particular problem. An quick glance at 6 reasonably
current home routers shows all are using the "ash" shell, rather than bash,
as it is much smaller and part of busybox, which most of these devices use.

That being said, there are many, many other serious vulnerabilities in that
class of device, compounded many times over by the fact that most lack any
sort of update stream, and usually require manual update, if ever new
firmware does become available.

Those of you unfamiliar with The Moon worm should familiarize yourself with
it.  Consider it a shot across our bow....

For those of you who want to understand more about the situation we're all
in, go look at my talk at the Berkman Center, and read the articles linked
from there by Bruce Schneier and Dan Geer.

http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys

Jim Gettys


From jason at lixfeld.ca  Fri Sep 26 14:51:06 2014
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Fri, 26 Sep 2014 10:51:06 -0400
Subject: Multi-port RFC2544/EtherSAM loopback appliance
Message-ID: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca>

Group,

I'm looking for options and opinions on a cost effective, multi-port (6'ish port SFP/SFP+) RFC2544/EtherSAM rack appliance that can act as the remote/loopback for our field installers' portable RFC2544/EtherSAM enabled Exfo test sets.

I came across XenaNetworks XenaCompact which looks like it would fit the bill, but I'm sure there are others (save Ixia, Exfo and Fluke, which I'm pretty much excluding by default because I imagine they are likely completely out to lunch on price relative to the extremely simplified feature set we require).

Thanks in advance.

From cscora at apnic.net  Fri Sep 26 18:12:39 2014
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 27 Sep 2014 04:12:39 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201409261812.s8QICdqm019715@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 27 Sep, 2014

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              512186
    Prefixes after maximum aggregation:                          198722
    Deaggregation factor:                                          2.58
    Unique aggregates announced to Internet:                     252159
Total ASes present in the Internet Routing Table:                 48124
    Prefixes per ASN:                                             10.64
Origin-only ASes present in the Internet Routing Table:           36176
Origin ASes announcing only one prefix:                           16357
Transit ASes present in the Internet Routing Table:                6173
Transit-only ASes present in the Internet Routing Table:            176
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      68
    Max AS path prepend of ASN ( 55644)                              61
Prefixes from unregistered ASNs in the Routing Table:              1761
    Unregistered ASNs in the Routing Table:                         448
Number of 32-bit ASNs allocated by the RIRs:                       7505
Number of 32-bit ASNs visible in the Routing Table:                5775
Prefixes from 32-bit ASNs in the Routing Table:                   20231
Number of bogon 32-bit ASNs visible in the Routing Table:            13
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            358
Number of addresses announced to Internet:                   2709988068
    Equivalent to 161 /8s, 135 /16s and 34 /24s
    Percentage of available address space announced:               73.2
    Percentage of allocated address space announced:               73.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               96.9
Total number of prefixes smaller than registry allocations:      175400

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   125220
    Total APNIC prefixes after maximum aggregation:               36661
    APNIC Deaggregation factor:                                    3.42
Prefixes being announced from the APNIC address blocks:          128967
    Unique aggregates announced from the APNIC address blocks:    53231
APNIC Region origin ASes present in the Internet Routing Table:    4982
    APNIC Prefixes per ASN:                                       25.89
APNIC Region origin ASes announcing only one prefix:               1201
APNIC Region transit ASes present in the Internet Routing Table:    866
Average APNIC Region AS path length visible:                        4.8
    Max APNIC Region AS path length visible:                         68
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1110
Number of APNIC addresses announced to Internet:              734586688
    Equivalent to 43 /8s, 200 /16s and 231 /24s
    Percentage of available APNIC address space announced:         85.9

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 131072-135580
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, 150/8, 153/8,
                       163/8, 171/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:                    170487
    Total ARIN prefixes after maximum aggregation:                85188
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           172481
    Unique aggregates announced from the ARIN address blocks:     80696
ARIN Region origin ASes present in the Internet Routing Table:    16365
    ARIN Prefixes per ASN:                                        10.54
ARIN Region origin ASes announcing only one prefix:                6093
ARIN Region transit ASes present in the Internet Routing Table:    1699
Average ARIN Region AS path length visible:                         3.9
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:     208
Number of ARIN addresses announced to Internet:              1084878240
    Equivalent to 64 /8s, 169 /16s and 237 /24s
    Percentage of available ARIN address space announced:          57.4

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, 62464-63487, 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, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/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:                    125076
    Total RIPE prefixes after maximum aggregation:                63321
    RIPE Deaggregation factor:                                     1.98
Prefixes being announced from the RIPE address blocks:           130217
    Unique aggregates announced from the RIPE address blocks:     82829
RIPE Region origin ASes present in the Internet Routing Table:    17733
    RIPE Prefixes per ASN:                                         7.34
RIPE Region origin ASes announcing only one prefix:                8213
RIPE Region transit ASes present in the Internet Routing Table:    2905
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          32
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3071
Number of RIPE addresses announced to Internet:               659421828
    Equivalent to 39 /8s, 77 /16s and 250 /24s
    Percentage of available RIPE address space announced:          95.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
                       59392-61439, 61952-62463, 196608-202239
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,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   59763
    Total LACNIC prefixes after maximum aggregation:              10685
    LACNIC Deaggregation factor:                                   5.59
Prefixes being announced from the LACNIC address blocks:          68010
    Unique aggregates announced from the LACNIC address blocks:   30357
LACNIC Region origin ASes present in the Internet Routing Table:   2321
    LACNIC Prefixes per ASN:                                      29.30
LACNIC Region origin ASes announcing only one prefix:               633
LACNIC Region transit ASes present in the Internet Routing Table:   457
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        26
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1330
Number of LACNIC addresses announced to Internet:             171055744
    Equivalent to 10 /8s, 50 /16s and 26 /24s
    Percentage of available LACNIC address space announced:       102.0

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-265628 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  11305
    Total AfriNIC prefixes after maximum aggregation:              2821
    AfriNIC Deaggregation factor:                                  4.01
Prefixes being announced from the AfriNIC address blocks:         12153
    Unique aggregates announced from the AfriNIC address blocks:   4730
AfriNIC Region origin ASes present in the Internet Routing Table:   741
    AfriNIC Prefixes per ASN:                                     16.40
AfriNIC Region origin ASes announcing only one prefix:              217
AfriNIC Region transit ASes present in the Internet Routing Table:  159
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:   56
Number of AfriNIC addresses announced to Internet:             59753216
    Equivalent to 3 /8s, 143 /16s and 195 /24s
    Percentage of available AfriNIC address space announced:       59.4

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2928      11583         924   Korea Telecom
17974     2812        900          74   PT Telekomunikasi Indonesia
 7545     2354        336         121   TPG Telecom Limited
 4755     1910        413         192   TATA Communications formerly 
 9829     1633       1306          38   National Internet Backbone
 4808     1430       2215         421   CNCGROUP IP network China169 
 9583     1320        105         541   Sify Limited
 9498     1304        333          91   BHARTI Airtel Ltd.
 9808     1283       6634          13   Guangdong Mobile Communicatio
 7552     1229       1098          14   Viettel Corporation

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     2897       3688          51   BellSouth.net Inc.
22773     2895       2940         141   Cox Communications Inc.
18566     2045        379         181   MegaPath Corporation
 7029     1934       1975         333   Windstream Communications Inc
20115     1797       1781         489   Charter Communications
 4323     1629       1051         409   tw telecom holdings, inc.
 6983     1498        867         251   ITC^Deltacom
30036     1494        311         608   Mediacom Communications Corp
  701     1437      11258         720   MCI Communications Services, 
22561     1308        408         237   CenturyTel Internet Holdings,

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
34984     1816        296         345   TELLCOM ILETISIM HIZMETLERI A
20940     1477        573        1086   Akamai International B.V.
 8402     1416        544          15   OJSC "Vimpelcom"
31148     1043         45          21   Freenet Ltd.
13188     1034        100          31   TOV "Bank-Inform"
 8551      962        372          42   Bezeq International-Ltd
 6849      829        356          26   JSC "Ukrtelecom"
12479      804        798          58   France Telecom Espana SA
 6830      776       2335         431   Liberty Global Operations B.V
 9198      629        346          28   JSC Kazakhtelecom

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
28573     3041       2310         110   NET Servi?os de Comunica??o S
10620     2981        483         250   Telmex Colombia S.A.
18881     2108       1036          22   Global Village Telecom
 7303     1765       1175         234   Telecom Argentina S.A.
 6147     1734        374          30   Telefonica del Peru S.A.A.
 8151     1472       2998         433   Uninet S.A. de C.V.
 6503     1118        434          61   Axtel, S.A.B. de C.V.
 7738      999       1882          41   Telemar Norte Leste S.A.
27947      909        130          51   Telconet S.A
26615      872       2325          35   Tim Celular 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
24863      949        280          26   Link Egypt (Link.NET)
 6713      678        760          38   Office National des Postes et
 8452      555        958          13   TE-AS
36992      347        824          27   ETISALAT MISR
24835      307        144           9   Vodafone Data
 3741      249        920         212   Internet Solutions
29571      245         22          17   Cote d'Ivoire Telecom
37054      233         19           6   Data Telecom Service
15706      186         17           6   Sudatel (Sudan Telecom Co. Lt
12258      174         26          71   MWEB CONNECT (PROPRIETARY) LI

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
28573     3041       2310         110   NET Servi?os de Comunica??o S
10620     2981        483         250   Telmex Colombia S.A.
 4766     2928      11583         924   Korea Telecom
 6389     2897       3688          51   BellSouth.net Inc.
22773     2895       2940         141   Cox Communications Inc.
17974     2812        900          74   PT Telekomunikasi Indonesia
 7545     2354        336         121   TPG Telecom Limited
18881     2108       1036          22   Global Village Telecom
18566     2045        379         181   MegaPath Corporation
 7029     1934       1975         333   Windstream Communications Inc

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 6389      2897        2846      BellSouth.net Inc.
22773      2895        2754      Cox Communications Inc.
17974      2812        2738      PT Telekomunikasi Indonesia
10620      2981        2731      Telmex Colombia S.A.
 7545      2354        2233      TPG Telecom Limited
18881      2108        2086      Global Village Telecom
 4766      2928        2004      Korea Telecom
18566      2045        1864      MegaPath Corporation
 4755      1910        1718      TATA Communications formerly 
 6147      1734        1704      Telefonica del Peru S.A.A.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
20260   UNALLOCATED  8.25.160.0/24         3356       Level 3 Communicatio
20260   UNALLOCATED  8.25.161.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24        12180       Internap Network Ser
46473   UNALLOCATED  8.27.124.0/24        12180       Internap Network Ser
55020   UNALLOCATED  8.30.123.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          6461       Abovenet Communicati
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
5.100.241.0/24       23456     32bit Transition AS
24.231.96.0/24       21548     MTO Telecom Inc.
27.100.7.0/24        56096     >>UNKNOWN<<
31.217.248.0/21      44902     COVAGE NETWORKS SASU
37.16.88.0/23        57652     >>UNKNOWN<<
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.10.0/24        37004     >>UNKNOWN<<
41.73.11.0/24        37004     >>UNKNOWN<<
41.73.12.0/24        37004     >>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:16       /9:12      /10:31      /11:90      /12:262     
/13:504     /14:998     /15:1711    /16:13033   /17:7098    /18:11836   
/19:24585   /20:35270   /21:37688   /22:54834   /23:48041   /24:273273  
/25:1075    /26:1054    /27:718     /28:14      /29:19      /30:10      
/31:1       /32:13      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2128          2895      Cox Communications Inc.
18566     2000          2045      MegaPath Corporation
 6389     1676          2897      BellSouth.net Inc.
30036     1339          1494      Mediacom Communications Corp
 6147     1301          1734      Telefonica del Peru S.A.A.
 6983     1186          1498      ITC^Deltacom
 7029     1138          1934      Windstream Communications Inc
34984     1136          1816      TELLCOM ILETISIM HIZMETLERI A
11492     1128          1176      CABLE ONE, INC.
 8402     1096          1416      OJSC "Vimpelcom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1344      2:664       3:3         4:18        5:1144      6:21     
   8:758      12:1848     13:4        14:1125     15:17       16:2      
  17:42       18:21       20:51       23:925      24:1755     27:1805   
  31:1412     32:39       33:2        34:5        36:155      37:1783   
  38:999      39:11       40:225      41:2614     42:268      43:390    
  44:16       45:76       46:2177     47:25       49:738      50:801    
  52:12       54:52       55:6        56:6        57:32       58:1209   
  59:661      60:432      61:1718     62:1271     63:1829     64:4411   
  65:2294     66:4183     67:2041     68:1047     69:3280     70:865    
  71:473      72:1995     74:2594     75:372      76:409      77:1604   
  78:853      79:729      80:1323     81:1208     82:792      83:777    
  84:742      85:1322     86:447      87:1159     88:469      89:1755   
  90:138      91:5755     92:755      93:1796     94:2068     95:1282   
  96:427      97:342      98:1100     99:48      100:66      101:723    
 103:5685    104:287     105:137     106:184     107:637     108:576    
 109:1980    110:1036    111:1383    112:716     113:896     114:780    
 115:1212    116:1118    117:990     118:1574    119:1413    120:429    
 121:973     122:2196    123:1618    124:1437    125:1577    128:596    
 129:348     130:365     131:824     132:430     133:165     134:324    
 135:78      136:305     137:290     138:378     139:195     140:222    
 141:405     142:580     143:435     144:506     145:110     146:688    
 147:554     148:958     149:407     150:496     151:709     152:470    
 153:240     154:353     155:544     156:371     157:331     158:279    
 159:933     160:325     161:600     162:1781    163:357     164:703    
 165:663     166:364     167:675     168:1119    169:121     170:1416   
 171:185     172:61      173:1640    174:703     175:615     176:1507   
 177:3554    178:2082    179:795     180:1761    181:1599    182:1659   
 183:533     184:725     185:2100    186:2945    187:1689    188:2220   
 189:1491    190:7812    191:757     192:7563    193:5514    194:4048   
 195:3592    196:1433    197:653     198:5147    199:5488    200:6502   
 201:2889    202:9161    203:8985    204:4582    205:2655    206:2963   
 207:2944    208:3915    209:3740    210:3296    211:1822    212:2360   
 213:2153    214:867     215:87      216:5620    217:1698    218:617    
 219:395     220:1369    221:699     222:484     223:597    

End of report


From Lee at asgard.org  Fri Sep 26 19:52:30 2014
From: Lee at asgard.org (Lee Howard)
Date: Fri, 26 Sep 2014 15:52:30 -0400
Subject: NANOG College Immersion Program
In-Reply-To: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>
References: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>
Message-ID: <D04B3C1B.6EDEC%Lee@asgard.org>

I am delighted to see this, and I hope other conferences will do likewise.

Lee

On 9/26/14 10:24 AM, "Dave Temkin" <dave at temk.in> wrote:

>I'm excited to announce that for NANOG 63 in San Antonio that we will
>begin
>the NANOG College Immersion Program. This program aims to provide the next
>generation of Network Operators with an edge in today's highly competitive
>market and allows us a conduit of highly capable operators, engineers, and
>architects.
>
>Please see below for the full program description.
>
>Regards,
>-Dave Temkin, for the NANOG Board of Directors
>
>
>NANOG College Immersion Program
>
>Summary:
>
>NANOG is committed to ensuring next generation of networking professionals
>have an opportunity become part of the operational community that makes
>the
>internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
>Yahoo, and Amazon rely on NANOG to discuss key architectural and
>operational topics relevant to Internet infrastructure. NANOG believes by
>introducing undergraduates to our vibrant community before entering the
>job
>marketplace, they will have a better understanding of how the
>infrastructure of the Internet works and how they might participate after
>graduation. Further, students may be able to find internship opportunities
>they may have not otherwise found.
>
>Offering:
>
>NANOG will provide an expenses-paid trip to the current meeting for up to
>25 students per meeting. The paid expenses will include:
>
>   -
>
>   Airfare (up to $500)
>   -
>
>   Four nights of hotel (must be booked by NANOG staff)
>   -
>
>   Ground transportation (reasonable cost)
>   -
>
>   Meal stipend (adjusted for meeting location)
>
>
>
>NANOG will also, space permitting, allow free admission for students to
>the
>NANOG Education Series (https://www.nanog.org/meetings/education/home)
>class prior to the meeting they are attending.
>
>NANOG will provide guidance to students as to what they may and may not
>attend. Of note, alcohol is served at some NANOG events and there is the
>expectation that those not legally entitled to consume alcohol will
>refrain
>from doing so. NANOG takes no responsibility for those that break the law
>during their meetings and reserves the right to refuse admission to those
>that violate our Attendance Charter.
>
>
>Expectation:
>
>NANOG will not be involved in any syllabus or coursework for the students.
>The NANOG organization will provide an agenda and slideware for the
>materials that the students will be viewing and expects their professor to
>determine the best way their students can extract educational value from
>the NANOG program. NANOG asks, in return, that all students complete our
>surveys in full and that their teaching staff provide us with a summary of
>how they used our program in the classroom and/or in coursework. A few
>paragraphs from each student explaining the value that they got from the
>program and social interactions would also be a good idea.
>
>
>Q&A:
>
>Q: What is NANOG and what is the value proposition for sending a student
>to
>this conference?
>
>A: The North American Network Operators Group or NANOG, is the
>professional
>association for Internet engineering and architecture. Our core focus is
>on
>the technologies and systems that make the Internet function: core routing
>and switching; Internet inter-domain routing; the domain name system;
>peering and interconnection; and Internet core security. We also cover
>associated areas with a direct impact on Internet architecture such as
>data
>centers and optical networking.  The value proposition for the student is
>exposure to all of these subjects and technical material but more
>importantly to the organizations and individuals.  The opportunity for
>students to make industry contacts is invaluable.
>
>Q: How do we select students for this sponsorship?
>
>A: Send your best and brightest, highlight that the value is the density
>of
>industry representatives in a common location.
>
>Q: What do the students owe back to NANOG?
>
>A: In addition to the anonymous surveys that all attendees are asked to
>complete, the NANOG Board would request that all sponsorship recipients
>provide feedback on their experiences.  Lastly, we would like to encourage
>the students join the mailing list (nanog at nanog.org), attend more
>conferences and get involved in the industry.
>
>Q: How do we evaluate our students participation?
>
>A: Students could provide a variety of deliverables back to the
>institution.  These could include a writeup of selected presentations from
>the agenda, an overview of the conference as a whole, or even a list of
>the
>individuals they met during the conference.
>
>Q: What will be covered in the sponsorship?
>
>A: Hotel, conference fee, airfare, and a reasonable stipend for
>incidentals
>such as meals.
>
>Q: Why are you sponsoring our students for this conference?
>
>A: The NANOG organization is keen to encourage the future technology
>leaders and innovators to get interested and involved in this segment of
>the industry.
>




From tsands at rackspace.com  Fri Sep 26 21:21:52 2014
From: tsands at rackspace.com (Tom Sands)
Date: Fri, 26 Sep 2014 21:21:52 +0000
Subject: NANOG College Immersion Program
In-Reply-To: <D04B3C1B.6EDEC%Lee@asgard.org>
References: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>,
 <D04B3C1B.6EDEC%Lee@asgard.org>
Message-ID: <7B378EB3C047B74A899746268AB045397DD76ABC@ORD1EXD04.RACKSPACE.CORP>

Agreed, this is a great idea and opportunity (and it's finally in San Antonio)  ;)



________________________________________
From: NANOG [nanog-bounces at nanog.org] on behalf of Lee Howard [Lee at asgard.org]
Sent: Friday, September 26, 2014 2:52 PM
To: Dave Temkin; nanog-announce at nanog.org; North American Network Operators' Group
Subject: Re: NANOG College Immersion Program

I am delighted to see this, and I hope other conferences will do likewise.

Lee

On 9/26/14 10:24 AM, "Dave Temkin" <dave at temk.in> wrote:

>I'm excited to announce that for NANOG 63 in San Antonio that we will
>begin
>the NANOG College Immersion Program. This program aims to provide the next
>generation of Network Operators with an edge in today's highly competitive
>market and allows us a conduit of highly capable operators, engineers, and
>architects.
>
>Please see below for the full program description.
>
>Regards,
>-Dave Temkin, for the NANOG Board of Directors
>
>
>NANOG College Immersion Program
>
>Summary:
>
>NANOG is committed to ensuring next generation of networking professionals
>have an opportunity become part of the operational community that makes
>the
>internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
>Yahoo, and Amazon rely on NANOG to discuss key architectural and
>operational topics relevant to Internet infrastructure. NANOG believes by
>introducing undergraduates to our vibrant community before entering the
>job
>marketplace, they will have a better understanding of how the
>infrastructure of the Internet works and how they might participate after
>graduation. Further, students may be able to find internship opportunities
>they may have not otherwise found.
>
>Offering:
>
>NANOG will provide an expenses-paid trip to the current meeting for up to
>25 students per meeting. The paid expenses will include:
>
>   -
>
>   Airfare (up to $500)
>   -
>
>   Four nights of hotel (must be booked by NANOG staff)
>   -
>
>   Ground transportation (reasonable cost)
>   -
>
>   Meal stipend (adjusted for meeting location)
>
>
>
>NANOG will also, space permitting, allow free admission for students to
>the
>NANOG Education Series (https://www.nanog.org/meetings/education/home)
>class prior to the meeting they are attending.
>
>NANOG will provide guidance to students as to what they may and may not
>attend. Of note, alcohol is served at some NANOG events and there is the
>expectation that those not legally entitled to consume alcohol will
>refrain
>from doing so. NANOG takes no responsibility for those that break the law
>during their meetings and reserves the right to refuse admission to those
>that violate our Attendance Charter.
>
>
>Expectation:
>
>NANOG will not be involved in any syllabus or coursework for the students.
>The NANOG organization will provide an agenda and slideware for the
>materials that the students will be viewing and expects their professor to
>determine the best way their students can extract educational value from
>the NANOG program. NANOG asks, in return, that all students complete our
>surveys in full and that their teaching staff provide us with a summary of
>how they used our program in the classroom and/or in coursework. A few
>paragraphs from each student explaining the value that they got from the
>program and social interactions would also be a good idea.
>
>
>Q&A:
>
>Q: What is NANOG and what is the value proposition for sending a student
>to
>this conference?
>
>A: The North American Network Operators Group or NANOG, is the
>professional
>association for Internet engineering and architecture. Our core focus is
>on
>the technologies and systems that make the Internet function: core routing
>and switching; Internet inter-domain routing; the domain name system;
>peering and interconnection; and Internet core security. We also cover
>associated areas with a direct impact on Internet architecture such as
>data
>centers and optical networking.  The value proposition for the student is
>exposure to all of these subjects and technical material but more
>importantly to the organizations and individuals.  The opportunity for
>students to make industry contacts is invaluable.
>
>Q: How do we select students for this sponsorship?
>
>A: Send your best and brightest, highlight that the value is the density
>of
>industry representatives in a common location.
>
>Q: What do the students owe back to NANOG?
>
>A: In addition to the anonymous surveys that all attendees are asked to
>complete, the NANOG Board would request that all sponsorship recipients
>provide feedback on their experiences.  Lastly, we would like to encourage
>the students join the mailing list (nanog at nanog.org), attend more
>conferences and get involved in the industry.
>
>Q: How do we evaluate our students participation?
>
>A: Students could provide a variety of deliverables back to the
>institution.  These could include a writeup of selected presentations from
>the agenda, an overview of the conference as a whole, or even a list of
>the
>individuals they met during the conference.
>
>Q: What will be covered in the sponsorship?
>
>A: Hotel, conference fee, airfare, and a reasonable stipend for
>incidentals
>such as meals.
>
>Q: Why are you sponsoring our students for this conference?
>
>A: The NANOG organization is keen to encourage the future technology
>leaders and innovators to get interested and involved in this segment of
>the industry.
>




From dave at temk.in  Fri Sep 26 21:44:27 2014
From: dave at temk.in (Dave Temkin)
Date: Fri, 26 Sep 2014 14:44:27 -0700
Subject: NANOG College Immersion Program
In-Reply-To: <CAJwSb9Z765JP-T8xRU=wQd2KH5LTkgV188t-W3kgvXbRjGRDLQ@mail.gmail.com>
References: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>
 <CAJwSb9Z765JP-T8xRU=wQd2KH5LTkgV188t-W3kgvXbRjGRDLQ@mail.gmail.com>
Message-ID: <CAFJiuFpuQ1iD_xqqq7hH3EWZGNdHQUMUsPpQRYe=yShjxcSQUQ@mail.gmail.com>

Yes, the professor will need to apply on behalf of the students that they
wish to send, as NANOG will not be directly involved in their coursework.

Regards,
-Dave

On Fri, Sep 26, 2014 at 2:41 PM, Colin McIntosh <cmcintosh33 at gmail.com>
wrote:

> I think this is a great idea! Will a student's school/professor be
> required to participate or can students apply by on their own?
>
> -Colin
> On Sep 26, 2014 10:26 AM, "Dave Temkin" <dave at temk.in> wrote:
>
>> I'm excited to announce that for NANOG 63 in San Antonio that we will
>> begin
>> the NANOG College Immersion Program. This program aims to provide the next
>> generation of Network Operators with an edge in today's highly competitive
>> market and allows us a conduit of highly capable operators, engineers, and
>> architects.
>>
>> Please see below for the full program description.
>>
>> Regards,
>> -Dave Temkin, for the NANOG Board of Directors
>>
>>
>> NANOG College Immersion Program
>>
>> Summary:
>>
>> NANOG is committed to ensuring next generation of networking professionals
>> have an opportunity become part of the operational community that makes
>> the
>> internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
>> Yahoo, and Amazon rely on NANOG to discuss key architectural and
>> operational topics relevant to Internet infrastructure. NANOG believes by
>> introducing undergraduates to our vibrant community before entering the
>> job
>> marketplace, they will have a better understanding of how the
>> infrastructure of the Internet works and how they might participate after
>> graduation. Further, students may be able to find internship opportunities
>> they may have not otherwise found.
>>
>> Offering:
>>
>> NANOG will provide an expenses-paid trip to the current meeting for up to
>> 25 students per meeting. The paid expenses will include:
>>
>>    -
>>
>>    Airfare (up to $500)
>>    -
>>
>>    Four nights of hotel (must be booked by NANOG staff)
>>    -
>>
>>    Ground transportation (reasonable cost)
>>    -
>>
>>    Meal stipend (adjusted for meeting location)
>>
>>
>>
>> NANOG will also, space permitting, allow free admission for students to
>> the
>> NANOG Education Series (https://www.nanog.org/meetings/education/home)
>> class prior to the meeting they are attending.
>>
>> NANOG will provide guidance to students as to what they may and may not
>> attend. Of note, alcohol is served at some NANOG events and there is the
>> expectation that those not legally entitled to consume alcohol will
>> refrain
>> from doing so. NANOG takes no responsibility for those that break the law
>> during their meetings and reserves the right to refuse admission to those
>> that violate our Attendance Charter.
>>
>>
>> Expectation:
>>
>> NANOG will not be involved in any syllabus or coursework for the students.
>> The NANOG organization will provide an agenda and slideware for the
>> materials that the students will be viewing and expects their professor to
>> determine the best way their students can extract educational value from
>> the NANOG program. NANOG asks, in return, that all students complete our
>> surveys in full and that their teaching staff provide us with a summary of
>> how they used our program in the classroom and/or in coursework. A few
>> paragraphs from each student explaining the value that they got from the
>> program and social interactions would also be a good idea.
>>
>>
>> Q&A:
>>
>> Q: What is NANOG and what is the value proposition for sending a student
>> to
>> this conference?
>>
>> A: The North American Network Operators Group or NANOG, is the
>> professional
>> association for Internet engineering and architecture. Our core focus is
>> on
>> the technologies and systems that make the Internet function: core routing
>> and switching; Internet inter-domain routing; the domain name system;
>> peering and interconnection; and Internet core security. We also cover
>> associated areas with a direct impact on Internet architecture such as
>> data
>> centers and optical networking.  The value proposition for the student is
>> exposure to all of these subjects and technical material but more
>> importantly to the organizations and individuals.  The opportunity for
>> students to make industry contacts is invaluable.
>>
>> Q: How do we select students for this sponsorship?
>>
>> A: Send your best and brightest, highlight that the value is the density
>> of
>> industry representatives in a common location.
>>
>> Q: What do the students owe back to NANOG?
>>
>> A: In addition to the anonymous surveys that all attendees are asked to
>> complete, the NANOG Board would request that all sponsorship recipients
>> provide feedback on their experiences.  Lastly, we would like to encourage
>> the students join the mailing list (nanog at nanog.org), attend more
>> conferences and get involved in the industry.
>>
>> Q: How do we evaluate our students participation?
>>
>> A: Students could provide a variety of deliverables back to the
>> institution.  These could include a writeup of selected presentations from
>> the agenda, an overview of the conference as a whole, or even a list of
>> the
>> individuals they met during the conference.
>>
>> Q: What will be covered in the sponsorship?
>>
>> A: Hotel, conference fee, airfare, and a reasonable stipend for
>> incidentals
>> such as meals.
>>
>> Q: Why are you sponsoring our students for this conference?
>>
>> A: The NANOG organization is keen to encourage the future technology
>> leaders and innovators to get interested and involved in this segment of
>> the industry.
>>
>


From cidr-report at potaroo.net  Fri Sep 26 22:00:00 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 26 Sep 2014 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201409262200.s8QM00lS046344@wattle.apnic.net>

This report has been generated at Fri Sep 26 21:14:14 2014 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/2.0 for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        19-09-14    517011      286314
        20-09-14    517131      286452
        21-09-14    517145      286348
        22-09-14    517265      286462
        23-09-14    516936      286439
        24-09-14    517269      286348
        25-09-14    516916      286747
        26-09-14    517584      286887


AS Summary
         48340  Number of ASes in routing system
         19506  Number of ASes announcing only one prefix
          3011  Largest number of prefixes announced by an AS
                AS28573: NET Servi?os de Comunica??o S.A.,BR
      120100352  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


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').

 --- 26Sep14 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     517554   286814   230740    44.6%   All ASes

AS28573     3011      144     2867    95.2%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS6389      2897      131     2766    95.5%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS22773     2899      161     2738    94.4%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS17974     2812       80     2732    97.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS18881     2108      297     1811    85.9%   Global Village Telecom,BR
AS4766      2939     1203     1736    59.1%   KIXS-AS-KR Korea Telecom,KR
AS6147      1751      165     1586    90.6%   Telefonica del Peru S.A.A.,PE
AS7303      1769      284     1485    83.9%   Telecom Argentina S.A.,AR
AS4755      1908      514     1394    73.1%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS8402      1394       23     1371    98.4%   CORBINA-AS OJSC "Vimpelcom",RU
AS20115     1798      563     1235    68.7%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS9808      1285       54     1231    95.8%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS4323      1640      412     1228    74.9%   TWTC - tw telecom holdings,
                                               inc.,US
AS7552      1263       58     1205    95.4%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS7545      2371     1171     1200    50.6%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS9498      1306      109     1197    91.7%   BBIL-AP BHARTI Airtel Ltd.,IN
AS10620     2981     1829     1152    38.6%   Telmex Colombia S.A.,CO
AS18566     2044      907     1137    55.6%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS22561     1308      311      997    76.2%   AS22561 - CenturyTel Internet
                                               Holdings, Inc.,US
AS7029      2035     1054      981    48.2%   WINDSTREAM - Windstream
                                               Communications Inc,US
AS7738       999       83      916    91.7%   Telemar Norte Leste S.A.,BR
AS6983      1496      631      865    57.8%   ITCDELTA - Earthlink, Inc.,US
AS24560     1173      336      837    71.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services,IN
AS4788      1069      242      827    77.4%   TMNET-AS-AP TM Net, Internet
                                               Service Provider,MY
AS38285      955      132      823    86.2%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS18101      957      196      761    79.5%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI,IN
AS8151      1479      724      755    51.0%   Uninet S.A. de C.V.,MX
AS4780      1022      274      748    73.2%   SEEDNET Digital United Inc.,TW
AS17908      838       92      746    89.0%   TCISL Tata Communications,IN
AS26615      872      132      740    84.9%   Tim Celular S.A.,BR

Total      52379    12312    40067    76.5%   Top 30 total


Possible Bogus Routes

        5.100.241.0/24       AS19957 -Reserved AS-,ZZ
        24.231.96.0/24       AS21548 MTO - MTO Telecom Inc.,CA
        27.100.7.0/24        AS56096 
        31.217.248.0/21      AS44902 COV-ASN COVAGE NETWORKS SASU,FR
        37.16.88.0/23        AS57652 -Reserved AS-,ZZ
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.10.0/24        AS37004 -Reserved AS-,ZZ
        41.73.11.0/24        AS37004 -Reserved AS-,ZZ
        41.73.12.0/24        AS37004 -Reserved AS-,ZZ
        41.73.13.0/24        AS37004 -Reserved AS-,ZZ
        41.73.14.0/24        AS37004 -Reserved AS-,ZZ
        41.73.15.0/24        AS37004 -Reserved AS-,ZZ
        41.73.16.0/24        AS37004 -Reserved AS-,ZZ
        41.73.18.0/24        AS37004 -Reserved AS-,ZZ
        41.73.20.0/24        AS37004 -Reserved AS-,ZZ
        41.73.21.0/24        AS37004 -Reserved AS-,ZZ
        41.76.48.0/21        AS36969 MTL-AS,MW
        41.78.120.0/23       AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US
        41.78.180.0/23       AS37265 -Reserved AS-,ZZ
        41.189.96.0/20       AS37000 -Reserved AS-,ZZ
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -Reserved AS-,ZZ
        41.191.108.0/22      AS37004 -Reserved AS-,ZZ
        41.191.108.0/24      AS37004 -Reserved AS-,ZZ
        41.191.109.0/24      AS37004 -Reserved AS-,ZZ
        41.191.110.0/24      AS37004 -Reserved AS-,ZZ
        41.191.111.0/24      AS37004 -Reserved AS-,ZZ
        41.209.128.0/18      AS1273  CW Cable and Wireless Worldwide plc,GB
        41.223.208.0/22      AS37000 -Reserved AS-,ZZ
        62.193.160.0/19      AS24801 -Reserved AS-,ZZ
        62.193.160.0/20      AS24801 -Reserved AS-,ZZ
        62.193.176.0/20      AS24801 -Reserved AS-,ZZ
        64.25.16.0/23        AS19535 -Reserved AS-,ZZ
        64.25.20.0/24        AS19535 -Reserved AS-,ZZ
        64.25.21.0/24        AS19535 -Reserved AS-,ZZ
        64.25.22.0/24        AS19535 -Reserved AS-,ZZ
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US
        64.111.160.0/20      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.160.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.161.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.162.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.167.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.169.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.170.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.171.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.172.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.173.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.174.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        64.111.175.0/24      AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global,US
        66.55.96.0/23        AS17203 -Reserved AS-,ZZ
        66.55.98.0/24        AS17203 -Reserved AS-,ZZ
        66.55.99.0/24        AS17203 -Reserved AS-,ZZ
        66.55.100.0/22       AS17203 -Reserved AS-,ZZ
        66.55.102.0/23       AS17203 -Reserved AS-,ZZ
        66.55.104.0/21       AS17203 -Reserved AS-,ZZ
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation,CA
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.,IT
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        74.112.100.0/22      AS16764 -Reserved AS-,ZZ
        74.113.200.0/23      AS46939 -Reserved AS-,ZZ
        74.114.52.0/22       AS40818 -Reserved AS-,ZZ
        74.114.52.0/23       AS40818 -Reserved AS-,ZZ
        74.114.52.0/24       AS40818 -Reserved AS-,ZZ
        74.114.53.0/24       AS40818 -Reserved AS-,ZZ
        74.114.54.0/23       AS40818 -Reserved AS-,ZZ
        74.114.54.0/24       AS40818 -Reserved AS-,ZZ
        74.114.55.0/24       AS40818 -Reserved AS-,ZZ
        74.114.184.0/22      AS19888 -Reserved AS-,ZZ
        74.118.132.0/22      AS5117  -Reserved AS-,ZZ
        74.120.212.0/23      AS32326 -Reserved AS-,ZZ
        74.120.214.0/23      AS32326 -Reserved AS-,ZZ
        74.121.24.0/22       AS36263 FORONA - Forona Technologies, Inc.,US
        74.123.136.0/21      AS53358 -Reserved AS-,ZZ
        77.243.81.0/24       AS42597 -Reserved AS-,ZZ
        77.243.91.0/24       AS42597 -Reserved AS-,ZZ
        77.243.95.0/24       AS42597 -Reserved AS-,ZZ
        80.78.133.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/23       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.134.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.78.135.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        80.250.32.0/22       AS37106 ODUA-AS,NG
        85.202.160.0/20      AS44404 -Reserved AS-,ZZ
        89.31.24.0/23        AS41455 -Reserved AS-,ZZ
        89.31.26.0/23        AS41455 -Reserved AS-,ZZ
        89.31.28.0/22        AS41455 -Reserved AS-,ZZ
        91.103.8.0/24        AS42551 -Reserved AS-,ZZ
        91.103.9.0/24        AS42551 -Reserved AS-,ZZ
        91.103.10.0/24       AS42551 -Reserved AS-,ZZ
        91.103.11.0/24       AS42551 -Reserved AS-,ZZ
        91.193.60.0/22       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.195.66.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        91.197.36.0/22       AS43359 -Reserved AS-,ZZ
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG,DE
        91.220.84.0/24       AS5577  ROOT root SA,LU
        91.220.173.0/24      AS30058 FDCSERVERS - FDCservers.net,US
        91.228.160.0/24      AS19979 DEPO40-AS Trusov Ilya Igorevych,RU
        91.239.157.0/24      AS24958 TBSH The Bunker Secure Hosting Limited,GB
        93.157.184.0/22      AS12714 TI-AS Net By Net Holding LLC,RU
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. ,AU
        103.6.108.0/22       AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN
        103.9.108.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.76.0/22       AS18097 DCN D.C.N. Corporation,JP
        103.18.248.0/22      AS18097 DCN D.C.N. Corporation,JP
        103.19.0.0/22        AS18097 DCN D.C.N. Corporation,JP
        103.20.100.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.20.101.0/24      AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN
        103.21.4.0/22        AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US
        103.26.116.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.228.132.0/22     AS4826  VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.220.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.249.8.0/22       AS4725  ODN SOFTBANK TELECOM Corp.,JP
        103.250.0.0/22       AS17676 GIGAINFRA Softbank BB Corp.,JP
        116.206.72.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.85.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        116.206.103.0/24     AS6461  ABOVENET - Abovenet Communications, Inc,US
        117.103.32.0/24      AS23861 
        117.103.33.0/24      AS23861 
        117.103.34.0/24      AS23861 
        117.103.35.0/24      AS23861 
        117.103.36.0/24      AS23861 
        117.103.37.0/24      AS23861 
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street,CN
        124.158.28.0/22      AS45857 
        131.161.200.0/22     AS52439 OPTIC,CL
        137.63.128.0/17      AS13226 ESSIST-AS-AP 24/7 Distribution Pty Ltd,AU
        142.147.62.0/24      AS3958  AIRCANADA - Air Canada,CA
        162.210.240.0/24     AS17246 -Reserved AS-,ZZ
        162.210.241.0/24     AS17246 -Reserved AS-,ZZ
        162.210.244.0/24     AS17246 -Reserved AS-,ZZ
        162.210.245.0/24     AS17246 -Reserved AS-,ZZ
        162.210.246.0/24     AS17246 -Reserved AS-,ZZ
        162.210.247.0/24     AS17246 -Reserved AS-,ZZ
        162.244.140.0/24     AS17246 -Reserved AS-,ZZ
        162.244.141.0/24     AS17246 -Reserved AS-,ZZ
        162.244.142.0/24     AS17246 -Reserved AS-,ZZ
        162.244.143.0/24     AS17246 -Reserved AS-,ZZ
        166.93.0.0/16        AS23537 CRITIGEN - Micro Source, Inc.,US
        172.85.0.0/24        AS29571 CITelecom-AS,CI
        172.85.1.0/24        AS29571 CITelecom-AS,CI
        172.85.2.0/24        AS29571 CITelecom-AS,CI
        172.85.3.0/24        AS29571 CITelecom-AS,CI
        172.86.0.0/24        AS29571 CITelecom-AS,CI
        172.86.1.0/24        AS29571 CITelecom-AS,CI
        172.86.2.0/24        AS29571 CITelecom-AS,CI
        172.87.0.0/24        AS29571 CITelecom-AS,CI
        172.88.0.0/24        AS29571 CITelecom-AS,CI
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group),CN
        176.111.168.0/22     AS50586 MACROSOLUTIONS MacroSolution SRL,RO
        182.237.24.0/24      AS55503 
        182.237.25.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        185.28.180.0/22      AS18097 DCN D.C.N. Corporation,JP
        185.40.4.0/24        AS20004 -Reserved AS-,ZZ
        185.40.5.0/24        AS20004 -Reserved AS-,ZZ
        185.40.6.0/24        AS20004 -Reserved AS-,ZZ
        185.40.7.0/24        AS20004 -Reserved AS-,ZZ
        185.71.72.0/22       AS24916 ORBITAL-ASN OrbitalNet Ltd,GB
        190.124.252.0/22     AS7303  Telecom Argentina S.A.,AR
        192.9.0.0/16         AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US
        192.25.10.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.11.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.13.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.25.14.0/24       AS5714  HPES - Hewlett-Packard Company,US
        192.34.152.0/21      AS10835 VISIONARY - Visionary Communications, Inc.,US
        192.75.23.0/24       AS2579  AS2579 - Alcatel-Lucent,US
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.70.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.71.0/24      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.101.72.0/24      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.124.252.0/22     AS680   DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE
        192.131.233.0/24     AS7018  ATT-INTERNET4 - AT&T Services, Inc.,US
        192.149.81.0/24      AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US
        192.154.32.0/19      AS81    NCREN - MCNC,US
        192.154.64.0/19      AS81    NCREN - MCNC,US
        192.166.32.0/20      AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        192.188.208.0/20     AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        192.245.195.0/24     AS7381  SUNGARDRS - SunGard Availability Services LP,US
        193.9.59.0/24        AS1257  TELE2,SE
        193.16.106.0/24      AS31539 -Reserved AS-,ZZ
        193.16.145.0/24      AS31392 -Reserved AS-,ZZ
        193.22.86.0/24       AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI
        193.22.224.0/20      AS3322  -Reserved AS-,ZZ
        193.22.238.0/23      AS62383 LDS-AS Lambrechts Data Services VOF,BE
        193.26.213.0/24      AS31641 BYTEL-AS Bytel Ltd,GB
        193.28.14.0/24       AS34309 LINK11 Link11 GmbH,DE
        193.33.6.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.33.252.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.53.5.0/24        AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.93.6.0/23        AS35559 SOMEADDRESS Someaddress Networks Ltd,GB
        193.111.229.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.149.2.0/23       AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.178.196.0/22     AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company,JO
        193.200.244.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.201.244.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.245.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.201.246.0/24     AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        193.202.8.0/21       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.202.9.0/24       AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        193.223.103.0/24     AS3248  SIL-AT Tele2 Telecommunication GmbH,AT
        193.227.109.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        193.227.236.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.0.116.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.0.117.0/24       AS21437 AVITI-AS Aviti ltd.,UA
        194.6.252.0/24       AS21202 DCSNET-AS Bredband2 AB,SE
        194.9.8.0/23         AS2863  SPRITELINK Centor AB,SE
        194.9.8.0/24         AS2863  SPRITELINK Centor AB,SE
        194.33.11.0/24       AS8943  JUMP Jump Networks Ltd.,GB
        194.39.78.0/23       AS702   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        194.49.17.0/24       AS13135 CREW-AS Wieske's Crew GmbH,DE
        194.50.8.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.60.88.0/21       AS5089  NTL Virgin Media Limited,GB
        194.63.152.0/22      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.79.36.0/22       AS3257  TINET-BACKBONE Tinet SpA,DE
        194.88.6.0/24        AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
        194.88.226.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.99.67.0/24       AS9083  CARPENET carpeNet Information Technologies GmbH,DE
        194.126.152.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.126.219.0/24     AS34545 -Reserved AS-,ZZ
        194.126.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        194.150.214.0/23     AS30880 SPACEDUMP-AS SpaceDump IT AB,SE
        194.156.179.0/24     AS3209  VODANET Vodafone GmbH,DE
        194.180.25.0/24      AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE
        194.187.24.0/22      AS8856  UKRNET UkrNet Ltd,UA
        195.8.48.0/23        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.48.0/24        AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.8.119.0/24       AS34304 TEENTELECOM Teen Telecom SRL,RO
        195.42.232.0/22      AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE
        195.85.194.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.85.201.0/24      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.110.0.0/23       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB,SE
        195.149.119.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.189.174.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA,BE
        195.234.156.0/24     AS25028 -Reserved AS-,ZZ
        195.242.182.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.244.18.0/23      AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        195.245.98.0/23      AS48918 GLOBALWAYS GLOBALWAYS AG,DE
        196.3.181.0/24       AS37004 -Reserved AS-,ZZ
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.6.0.0/24         AS32768 routability-tests,MU
        196.22.8.0/24        AS27822 Emerging Markets Communications de Argentina S.R.L,AR
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        196.49.128.0/17      AS1273  CW Cable and Wireless Worldwide plc,GB
        196.192.124.0/23     AS37301 AFRINIC-ZA-CPT-AS,MU
        196.216.254.0/24     AS32768 routability-tests,MU
        198.22.195.0/24      AS54583 -Reserved AS-,ZZ
        198.23.26.0/24       AS4390  BELLATLANTIC-COM - Bell Atlantic, Inc.,US
        198.74.11.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.13.0/24       AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US
        198.74.38.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.39.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.74.40.0/24       AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US
        198.97.72.0/21       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.96.0/19       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.192.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.97.240.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        198.163.214.0/24     AS21804 ACCESS-SK - Access Communications  Co-operative Limited,CA
        198.163.215.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.163.216.0/24     AS6327  SHAW - Shaw Communications Inc.,CA
        198.168.0.0/16       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        198.176.208.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.209.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.210.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.176.211.0/24     AS4318  ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US
        198.252.165.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.166.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.167.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.168.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        198.252.169.0/24     AS20115 CHARTER-NET-HKY-NC - Charter Communications,US
        199.85.9.0/24        AS852   ASN852 - TELUS Communications Inc.,CA
        199.88.52.0/22       AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US
        199.116.200.0/21     AS22830 -Reserved AS-,ZZ
        199.120.150.0/24     AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US
        199.121.0.0/16       AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        199.123.16.0/20      AS721   DNIC-ASBLK-00721-00726 - DoD Network Information Center,US
        200.1.112.0/24       AS29754 GO2TEL - GO2TEL.COM INC.,US
        200.58.248.0/21      AS27849 
        200.81.48.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        200.81.49.0/24       AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR
        202.53.138.0/24      AS4058  CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK
        202.58.113.0/24      AS19161 -Reserved AS-,ZZ
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.,IN
        203.142.219.0/24     AS45149 
        203.189.116.0/22     AS45606 
        203.189.116.0/24     AS45606 
        203.189.117.0/24     AS45606 
        203.189.118.0/24     AS45606 
        203.189.119.0/24     AS45606 
        204.10.88.0/21       AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US
        204.16.96.0/24       AS19972 -Reserved AS-,ZZ
        204.16.97.0/24       AS19972 -Reserved AS-,ZZ
        204.16.98.0/24       AS19972 -Reserved AS-,ZZ
        204.16.99.0/24       AS19972 -Reserved AS-,ZZ
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta,GB
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp,US
        205.166.231.0/24     AS7029  WINDSTREAM - Windstream Communications Inc,US
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network,CA
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US
        206.223.224.0/24     AS21548 MTO - MTO Telecom Inc.,CA
        207.2.120.0/21       AS6221  USCYBERSITES - US Cybersites, Inc,US
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc,US
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc,US
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.,US
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.,US
        207.254.128.0/21     AS30689 FLOW-NET - FLOW,JM
        207.254.128.0/24     AS30689 FLOW-NET - FLOW,JM
        207.254.136.0/21     AS30689 FLOW-NET - FLOW,JM
        208.66.64.0/24       AS16936 -Reserved AS-,ZZ
        208.66.65.0/24       AS16936 -Reserved AS-,ZZ
        208.66.66.0/24       AS16936 -Reserved AS-,ZZ
        208.66.67.0/24       AS16936 -Reserved AS-,ZZ
        208.67.132.0/22      AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        208.69.192.0/23      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.69.195.0/24      AS6461  ABOVENET - Abovenet Communications, Inc,US
        208.75.152.0/21      AS32146 -Reserved AS-,ZZ
        208.76.20.0/24       AS31812 -Reserved AS-,ZZ
        208.76.21.0/24       AS31812 -Reserved AS-,ZZ
        208.77.164.0/24      AS22659 -Reserved AS-,ZZ
        208.77.166.0/24      AS4323  TWTC - tw telecom holdings, inc.,US
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC,US
        208.84.232.0/24      AS33131 -Reserved AS-,ZZ
        208.84.234.0/24      AS33131 -Reserved AS-,ZZ
        208.84.237.0/24      AS33131 -Reserved AS-,ZZ
        208.84.238.0/24      AS33131 -Reserved AS-,ZZ
        208.94.216.0/23      AS13629 -Reserved AS-,ZZ
        208.94.219.0/24      AS13629 -Reserved AS-,ZZ
        208.94.221.0/24      AS13629 -Reserved AS-,ZZ
        208.94.223.0/24      AS13629 -Reserved AS-,ZZ
        209.135.171.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.135.175.0/24     AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US
        209.177.64.0/20      AS6461  ABOVENET - Abovenet Communications, Inc,US
        209.193.112.0/20     AS209   ASN-QWEST - Qwest Communications Company, LLC,US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US
        209.209.224.0/19     AS19513 -Reserved AS-,ZZ
        209.209.248.0/23     AS19513 -Reserved AS-,ZZ
        209.209.250.0/23     AS19513 -Reserved AS-,ZZ
        209.209.251.0/24     AS19513 -Reserved AS-,ZZ
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US
        209.234.112.0/23     AS32252 -Reserved AS-,ZZ
        209.234.114.0/23     AS32252 -Reserved AS-,ZZ
        209.234.116.0/24     AS32252 -Reserved AS-,ZZ
        209.234.117.0/24     AS32252 -Reserved AS-,ZZ
        209.234.118.0/24     AS32252 -Reserved AS-,ZZ
        209.234.119.0/24     AS32252 -Reserved AS-,ZZ
        209.234.120.0/24     AS32252 -Reserved AS-,ZZ
        209.234.121.0/24     AS32252 -Reserved AS-,ZZ
        209.234.122.0/24     AS32252 -Reserved AS-,ZZ
        213.255.128.0/20     AS24863 LINKdotNET-AS,EG
        213.255.144.0/20     AS24863 LINKdotNET-AS,EG
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.,US
        216.146.0.0/19       AS11915 US-TELEPACIFIC - TelePacific Communications,US
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.,US
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US
        216.251.50.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN
        216.251.53.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN
        216.251.62.0/24      AS38191 INFOSYS-AS Infosys Technologies Ltd,IN


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 cidr-report at potaroo.net  Fri Sep 26 22:00:01 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 26 Sep 2014 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201409262200.s8QM01NZ046361@wattle.apnic.net>

BGP Update Report
Interval: 18-Sep-14 -to- 25-Sep-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS23752          191619  4.8%    1774.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 2 - AS9829           188607  4.7%     156.7 -- BSNL-NIB National Internet Backbone,IN
 3 - AS45816          107578  2.7%    3842.1 -- ISHK-AP I-Services Network Solution Limited,HK
 4 - AS28573           68733  1.7%      42.1 -- NET Servi?os de Comunica??o S.A.,BR
 5 - AS8402            55366  1.4%     139.8 -- CORBINA-AS OJSC "Vimpelcom",RU
 6 - AS45899           53685  1.3%     106.9 -- VNPT-AS-VN VNPT Corp,VN
 7 - AS1659            48577  1.2%     647.7 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
 8 - AS38197           47060  1.2%      59.4 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK
 9 - AS46150           39398  1.0%   39398.0 -- SNHU - Southern New Hampshire University,US
10 - AS17974           30578  0.8%      10.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID
11 - AS9583            27813  0.7%      19.5 -- SIFY-AS-IN Sify Limited,IN
12 - AS3816            26573  0.7%      42.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO
13 - AS8151            25496  0.6%      22.9 -- Uninet S.A. de C.V.,MX
14 - AS7018            23825  0.6%      19.4 -- ATT-INTERNET4 - AT&T Services, Inc.,US
15 - AS2               23652  0.6%    2129.0 -- UDEL-DCN - University of Delaware,US
16 - AS23342           22160  0.6%   22160.0 -- UNITEDLAYER - Unitedlayer, Inc.,US
17 - AS47331           20650  0.5%       7.5 -- TTNET TTNet A.S.,TR
18 - AS25003           19817  0.5%     900.8 -- INTERNET_BINAT Internet Binat Ltd,IL
19 - AS17552           17881  0.5%     112.5 -- TRUE-AS-AP True Internet Co.,Ltd.,TH
20 - AS9145            14318  0.4%      69.8 -- EWETEL EWE TEL GmbH,DE


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS46150           39398  1.0%   39398.0 -- SNHU - Southern New Hampshire University,US
 2 - AS23342           22160  0.6%   22160.0 -- UNITEDLAYER - Unitedlayer, Inc.,US
 3 - AS2               23652  0.6%    2129.0 -- UDEL-DCN - University of Delaware,US
 4 - AS32336            4634  0.1%    4634.0 -- IPASS-2 - iPass Incorporated,US
 5 - AS45816          107578  2.7%    3842.1 -- ISHK-AP I-Services Network Solution Limited,HK
 6 - AS22667            6879  0.2%    3439.5 -- VISTA - Vista Broadband Networks, Inc.,US
 7 - AS27390            3135  0.1%    3135.0 -- ALGAS - Fred Alger & Co Inc.,US
 8 - AS62174            2631  0.1%    2631.0 -- INTERPAN-AS INTERPAN LTD.,BG
 9 - AS51888            2556  0.1%    2556.0 -- PILOTSYSTEMS-AS Pilot Systems consulting SARL,FR
10 - AS34154           13745  0.3%    2290.8 -- CONFIGO-AS Configo Systems Gesellschaft fuer Systemloesungen mbH,DE
11 - AS62318            2280  0.1%    2280.0 -- BIMEH-MA-AS Bimeh Ma,IR
12 - AS41762            1938  0.1%    1938.0 -- SEVNET PE Logvinov Vladimir Vladimirovich,UA
13 - AS18135           13192  0.3%    1884.6 -- BTV BTV Cable television,JP
14 - AS35093            3610  0.1%    1805.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO
15 - AS23752          191619  4.8%    1774.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
16 - AS3                1732  0.0%    5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US
17 - AS30944            1673  0.0%    1673.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT
18 - AS33643            1646  0.0%    1646.0 -- JELLYBELLY - Jelly Belly Candy Company,US
19 - AS17372            1420  0.0%    1420.0 -- BMO-TOR2 - Bank of Montreal,CA
20 - AS9140             1399  0.0%    1399.0 -- HYPERNEPH Hyperneph Ltd,GB


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.70.88.0/21    95465  2.3%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 2 - 202.70.64.0/21    95297  2.3%   AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP
 3 - 64.223.206.0/24   39398  0.9%   AS46150 -- SNHU - Southern New Hampshire University,US
 4 - 64.29.130.0/24    22160  0.5%   AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US
 5 - 192.115.44.0/22   19714  0.5%   AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL
 6 - 217.71.221.0/24   13697  0.3%   AS34154 -- CONFIGO-AS Configo Systems Gesellschaft fuer Systemloesungen mbH,DE
 7 - 42.83.48.0/20     13180  0.3%   AS18135 -- BTV BTV Cable television,JP
 8 - 205.247.12.0/24   10556  0.2%   AS6459  -- TRANSBEAM - I-2000, Inc.,US
 9 - 192.58.232.0/24    9670  0.2%   AS6629  -- NOAA-AS - NOAA,US
10 - 103.255.44.0/24    9488  0.2%   AS2     -- UDEL-DCN - University of Delaware,US
11 - 103.255.46.0/24    9364  0.2%   AS2     -- UDEL-DCN - University of Delaware,US
12 - 120.118.96.0/20    8034  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
13 - 203.64.238.0/24    8032  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
14 - 163.15.188.0/22    8032  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
15 - 163.15.192.0/24    8030  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
16 - 120.118.64.0/19    8030  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
17 - 163.15.185.0/24    8028  0.2%   AS1659  -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW
18 - 200.34.149.0/24    7501  0.2%   AS8151  -- Uninet S.A. de C.V.,MX
19 - 192.40.208.0/21    6874  0.2%   AS22667 -- VISTA - Vista Broadband Networks, Inc.,US
20 - 204.140.216.0/24   5910  0.1%   AS226   -- LOS-NETTOS-AS - Los Nettos,US

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 cmcintosh33 at gmail.com  Fri Sep 26 21:41:27 2014
From: cmcintosh33 at gmail.com (Colin McIntosh)
Date: Fri, 26 Sep 2014 17:41:27 -0400
Subject: NANOG College Immersion Program
In-Reply-To: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>
References: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>
Message-ID: <CAJwSb9Z765JP-T8xRU=wQd2KH5LTkgV188t-W3kgvXbRjGRDLQ@mail.gmail.com>

I think this is a great idea! Will a student's school/professor be required
to participate or can students apply by on their own?

-Colin
On Sep 26, 2014 10:26 AM, "Dave Temkin" <dave at temk.in> wrote:

> I'm excited to announce that for NANOG 63 in San Antonio that we will begin
> the NANOG College Immersion Program. This program aims to provide the next
> generation of Network Operators with an edge in today's highly competitive
> market and allows us a conduit of highly capable operators, engineers, and
> architects.
>
> Please see below for the full program description.
>
> Regards,
> -Dave Temkin, for the NANOG Board of Directors
>
>
> NANOG College Immersion Program
>
> Summary:
>
> NANOG is committed to ensuring next generation of networking professionals
> have an opportunity become part of the operational community that makes the
> internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
> Yahoo, and Amazon rely on NANOG to discuss key architectural and
> operational topics relevant to Internet infrastructure. NANOG believes by
> introducing undergraduates to our vibrant community before entering the job
> marketplace, they will have a better understanding of how the
> infrastructure of the Internet works and how they might participate after
> graduation. Further, students may be able to find internship opportunities
> they may have not otherwise found.
>
> Offering:
>
> NANOG will provide an expenses-paid trip to the current meeting for up to
> 25 students per meeting. The paid expenses will include:
>
>    -
>
>    Airfare (up to $500)
>    -
>
>    Four nights of hotel (must be booked by NANOG staff)
>    -
>
>    Ground transportation (reasonable cost)
>    -
>
>    Meal stipend (adjusted for meeting location)
>
>
>
> NANOG will also, space permitting, allow free admission for students to the
> NANOG Education Series (https://www.nanog.org/meetings/education/home)
> class prior to the meeting they are attending.
>
> NANOG will provide guidance to students as to what they may and may not
> attend. Of note, alcohol is served at some NANOG events and there is the
> expectation that those not legally entitled to consume alcohol will refrain
> from doing so. NANOG takes no responsibility for those that break the law
> during their meetings and reserves the right to refuse admission to those
> that violate our Attendance Charter.
>
>
> Expectation:
>
> NANOG will not be involved in any syllabus or coursework for the students.
> The NANOG organization will provide an agenda and slideware for the
> materials that the students will be viewing and expects their professor to
> determine the best way their students can extract educational value from
> the NANOG program. NANOG asks, in return, that all students complete our
> surveys in full and that their teaching staff provide us with a summary of
> how they used our program in the classroom and/or in coursework. A few
> paragraphs from each student explaining the value that they got from the
> program and social interactions would also be a good idea.
>
>
> Q&A:
>
> Q: What is NANOG and what is the value proposition for sending a student to
> this conference?
>
> A: The North American Network Operators Group or NANOG, is the professional
> association for Internet engineering and architecture. Our core focus is on
> the technologies and systems that make the Internet function: core routing
> and switching; Internet inter-domain routing; the domain name system;
> peering and interconnection; and Internet core security. We also cover
> associated areas with a direct impact on Internet architecture such as data
> centers and optical networking.  The value proposition for the student is
> exposure to all of these subjects and technical material but more
> importantly to the organizations and individuals.  The opportunity for
> students to make industry contacts is invaluable.
>
> Q: How do we select students for this sponsorship?
>
> A: Send your best and brightest, highlight that the value is the density of
> industry representatives in a common location.
>
> Q: What do the students owe back to NANOG?
>
> A: In addition to the anonymous surveys that all attendees are asked to
> complete, the NANOG Board would request that all sponsorship recipients
> provide feedback on their experiences.  Lastly, we would like to encourage
> the students join the mailing list (nanog at nanog.org), attend more
> conferences and get involved in the industry.
>
> Q: How do we evaluate our students participation?
>
> A: Students could provide a variety of deliverables back to the
> institution.  These could include a writeup of selected presentations from
> the agenda, an overview of the conference as a whole, or even a list of the
> individuals they met during the conference.
>
> Q: What will be covered in the sponsorship?
>
> A: Hotel, conference fee, airfare, and a reasonable stipend for incidentals
> such as meals.
>
> Q: Why are you sponsoring our students for this conference?
>
> A: The NANOG organization is keen to encourage the future technology
> leaders and innovators to get interested and involved in this segment of
> the industry.
>


From kmedcalf at dessus.com  Sat Sep 27 03:11:54 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Fri, 26 Sep 2014 21:11:54 -0600
Subject: update
In-Reply-To: <CAGhGL2BLs0jhjGOU1DSqjt369pFNf_=+R_uStvBRVe8WikWXtA@mail.gmail.com>
Message-ID: <24b0a923ef5f87488cdaf5dfe681937a@mail.dessus.com>


On Friday, 26 September, 2014 08:37,Jim Gettys <jg at freedesktop.org> said: 

>For those of you who want to understand more about the situation we're
>all in, go look at my talk at the Berkman Center, and read the articles
>linked from there by Bruce Schneier and Dan Geer.

>http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys

Unfortunately, that page contains near the top the ludicrous and impossible assertion:

""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy Code in Zero-Day Vulnerabilities",  by Clark, Fry, Blaze and Smith makes clear that ignoring these devices is foolhardy; unmaintained systems become more vulnerable, with time."

It is impossible for unchanged/unmaintained systems to develop more vulnerabilities with time.  Perhaps what these folks mean is that "vulnerabilities which existed from the time the system was first developed become more well known over time".

The fact that the folks in the next building can peep at your privates through the bedroom window on which you did not install blinds does not mean that the vulnerability only exists from the time it is published in the local tabloid -- it existed all along -- it did not "magically" come into existence at some point after the building was built, the window installed, and you moved in without putting up windows blinds.

The fact that you did not become aware of it until you saw a photograph of yourself doing unmentionable things only serves as the point in time at which you became aware of your failure to properly assess the posture of the system in the first place.

>Jim Gettys






From jjones at danrj.com  Sat Sep 27 02:25:57 2014
From: jjones at danrj.com (Jerry Jones)
Date: Fri, 26 Sep 2014 21:25:57 -0500
Subject: Multi-port RFC2544/EtherSAM loopback appliance
In-Reply-To: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca>
References: <9D1503ED-3593-48E4-9D0C-29A0FA13D181@lixfeld.ca>
Message-ID: <38F269AE-7265-4006-B7C9-D90F128A24EF@danrj.com>

Many ethernet termination devices will support most of the features it sounds like you are looking for. No clue what price range you consider but these may work for you.

Been a couple years since I played with the EtherSAM, but I think it supports two different testing options. One where the far end is on the same subnet and one which uses L3/IP. If you are on the same LAN segment, then pretty much any switch which supports loopback should work I think. Else, devices such as the Adva FSP150 or Juniper ACX or MX (probably a bit of overkill but very multi-purpose), or several different Ciena platforms come to mind.


On Sep 26, 2014, at 9:51 AM, Jason Lixfeld <jason at lixfeld.ca> wrote:

Group,

I'm looking for options and opinions on a cost effective, multi-port (6'ish port SFP/SFP+) RFC2544/EtherSAM rack appliance that can act as the remote/loopback for our field installers' portable RFC2544/EtherSAM enabled Exfo test sets.

I came across XenaNetworks XenaCompact which looks like it would fit the bill, but I'm sure there are others (save Ixia, Exfo and Fluke, which I'm pretty much excluding by default because I imagine they are likely completely out to lunch on price relative to the extremely simplified feature set we require).

Thanks in advance.



From sandro.unix at gmail.com  Sat Sep 27 10:47:14 2014
From: sandro.unix at gmail.com (Alessandro Braga)
Date: Sat, 27 Sep 2014 07:47:14 -0300
Subject: Oi Assistance
In-Reply-To: <CALo9H1aXpYKpbx2Cqr6Lv7kHyfwpwNRKd+xSR22kevPgwMPXQw@mail.gmail.com>
References: <c8bb223243e14e37ad2bce96d2320599@DM2PR02MB350.namprd02.prod.outlook.com>
 <CAByG9DOhzpw2S+6N3OV6ARvj_C7P31bdJiS00grM0EfaCFV_+Q@mail.gmail.com>
 <e15ef443a14044dd8017a1facee5b9ad@DM2PR02MB350.namprd02.prod.outlook.com>
 <CALo9H1aXpYKpbx2Cqr6Lv7kHyfwpwNRKd+xSR22kevPgwMPXQw@mail.gmail.com>
Message-ID: <CALNpVOiTqK81-DVGK68psWfiScbaZ7DnOLtZGz1GcSjYCLuuXQ@mail.gmail.com>

Brian,

Please could you write me privately. May be I can help you.

Let me know what are you trying to do.

BR,
Alessandro
On Sep 26, 2014 9:29 AM, "Arturo Servin" <arturo.servin at gmail.com> wrote:

> Try LACNOG or GTER (aka Brazilian NOG group) emailing list.
>
> May be somebody there could help.
>
> Regards
> as
>
>
> On Thu, Sep 25, 2014 at 10:09 PM, Brian Free <brfree at adobe.com> wrote:
>
> > Humberto,
> > I have been contacted by a couple of engineers inside of Oi or its
> > subsidiaries.  I'm pursuing those options at the moment, but sincerely
> > appreciate your offer of assistance.  I'm not sure whether I'm glad to
> hear
> > that it's not just me or whether I find that to be even more
> discouraging.
> > :)
> >
> > Thanks,
> > Brian
> >
> > -----Original Message-----
> > From: Humberto Galiza [mailto:humbertogaliza at gmail.com]
> > Sent: Thursday, September 25, 2014 2:59 PM
> > To: Brian Free
> > Cc: nanog at nanog.org
> > Subject: Re: Oi Assistance
> >
> > Brian,
> >
> > I?m not an AS7738 customer neither a member, but perhaps I can get some
> > information/help from a friend who works there. What kind of
> > information/assistance are you looking for?
> >
> > FYI, most of folks whose aren?t AS7738 customer, experience bad/long time
> > to get technical assistance or response; it?s not just you :) Humberto
> > Galiza
> >
> >
> > 2014-09-24 18:02 GMT-03:00 Brian Free <brfree at adobe.com>:
> > > Hi NANOG,
> > > I'm hoping someone out there has had some experience with Oi
> > Telecommunications.  We've been struggling to work with them to get a
> > couple of circuits in Sao Paulo live.  The primary problem is mostly a
> > language barrier.  Is anyone aware of an English speaking NOC email
> address
> > or phone number for Oi?  After months of back and forth through a third
> > party translator working with our account team, I've reached my limit and
> > am hoping there's another option to get some technical assistance with
> the
> > BGP configuration of these two circuits.  Any advice will be appreciated.
> > >
> > > Thanks,
> > > Brian
> > >
> >
>


From lists at mtin.net  Sat Sep 27 13:46:53 2014
From: lists at mtin.net (Justin Wilson)
Date: Sat, 27 Sep 2014 09:46:53 -0400
Subject: peeringdb
Message-ID: <D04C380D.7F474%lists@mtin.net>

Trying to update some records on peeringdb.com and am not getting much
response.  Just wondering if I am the only one.  I am not getting response
back from support.  Figured this would be a good place to ask.  More curious
than anything. 

Thanks,
Justin

--
Justin Wilson <j2sw at mtin.net>
http://www.mtin.net <http://www.mtin.net/blog>
Managed Services ? xISP Solutions ? Data Centers
http://www.thebrotherswisp.com
Podcast about xISP topics
http://www.midwest-ix.com
Peering ? Transit ? Internet Exchange





From job at instituut.net  Sat Sep 27 13:50:13 2014
From: job at instituut.net (Job Snijders)
Date: Sat, 27 Sep 2014 15:50:13 +0200
Subject: peeringdb
In-Reply-To: <D04C380D.7F474%lists@mtin.net>
References: <D04C380D.7F474%lists@mtin.net>
Message-ID: <20140927135013.GQ72322@Vurt.local>

On Sat, Sep 27, 2014 at 09:46:53AM -0400, Justin Wilson wrote:
> Trying to update some records on peeringdb.com and am not getting much
> response. Just wondering if I am the only one. I am not getting
> response back from support. Figured this would be a good place to ask.
> More curious than anything. 

Send me your ticket number off-list, I'll check.

Kind regards,

Job


From smutt at depht.com  Sat Sep 27 17:52:45 2014
From: smutt at depht.com (Andrew McConachie)
Date: Sat, 27 Sep 2014 10:52:45 -0700
Subject: NANOG College Immersion Program
In-Reply-To: <CAFJiuFpuQ1iD_xqqq7hH3EWZGNdHQUMUsPpQRYe=yShjxcSQUQ@mail.gmail.com>
References: <CAFJiuFrbFQPgXkEzHynX6wCqQ-rFYchuwQRPQhx6s0UTY_cwAg@mail.gmail.com>
 <CAJwSb9Z765JP-T8xRU=wQd2KH5LTkgV188t-W3kgvXbRjGRDLQ@mail.gmail.com>
 <CAFJiuFpuQ1iD_xqqq7hH3EWZGNdHQUMUsPpQRYe=yShjxcSQUQ@mail.gmail.com>
Message-ID: <5426F96D.2060003@depht.com>

Hi Dave,

Some questions regarding this program:

0) Is there a webpage somewhere with more information?
1) How do students/professors apply?
2) Who can qualify for this program? Are there age restrictions? Undergrads? Graduate students? Are there geographical restrictions?
3) How many seats are there?

Thanks,
Andrew McConachie

On 9/26/14 2:44 PM, Dave Temkin wrote:
> Yes, the professor will need to apply on behalf of the students that they
> wish to send, as NANOG will not be directly involved in their coursework.
>
> Regards,
> -Dave
>
> On Fri, Sep 26, 2014 at 2:41 PM, Colin McIntosh <cmcintosh33 at gmail.com>
> wrote:
>
>> I think this is a great idea! Will a student's school/professor be
>> required to participate or can students apply by on their own?
>>
>> -Colin
>> On Sep 26, 2014 10:26 AM, "Dave Temkin" <dave at temk.in> wrote:
>>
>>> I'm excited to announce that for NANOG 63 in San Antonio that we will
>>> begin
>>> the NANOG College Immersion Program. This program aims to provide the next
>>> generation of Network Operators with an edge in today's highly competitive
>>> market and allows us a conduit of highly capable operators, engineers, and
>>> architects.
>>>
>>> Please see below for the full program description.
>>>
>>> Regards,
>>> -Dave Temkin, for the NANOG Board of Directors
>>>
>>>
>>> NANOG College Immersion Program
>>>
>>> Summary:
>>>
>>> NANOG is committed to ensuring next generation of networking professionals
>>> have an opportunity become part of the operational community that makes
>>> the
>>> internet run. Companies such as Google, Level 3, Microsoft, NTT, Netflix,
>>> Yahoo, and Amazon rely on NANOG to discuss key architectural and
>>> operational topics relevant to Internet infrastructure. NANOG believes by
>>> introducing undergraduates to our vibrant community before entering the
>>> job
>>> marketplace, they will have a better understanding of how the
>>> infrastructure of the Internet works and how they might participate after
>>> graduation. Further, students may be able to find internship opportunities
>>> they may have not otherwise found.
>>>
>>> Offering:
>>>
>>> NANOG will provide an expenses-paid trip to the current meeting for up to
>>> 25 students per meeting. The paid expenses will include:
>>>
>>>    -
>>>
>>>    Airfare (up to $500)
>>>    -
>>>
>>>    Four nights of hotel (must be booked by NANOG staff)
>>>    -
>>>
>>>    Ground transportation (reasonable cost)
>>>    -
>>>
>>>    Meal stipend (adjusted for meeting location)
>>>
>>>
>>>
>>> NANOG will also, space permitting, allow free admission for students to
>>> the
>>> NANOG Education Series (https://www.nanog.org/meetings/education/home)
>>> class prior to the meeting they are attending.
>>>
>>> NANOG will provide guidance to students as to what they may and may not
>>> attend. Of note, alcohol is served at some NANOG events and there is the
>>> expectation that those not legally entitled to consume alcohol will
>>> refrain
>>> from doing so. NANOG takes no responsibility for those that break the law
>>> during their meetings and reserves the right to refuse admission to those
>>> that violate our Attendance Charter.
>>>
>>>
>>> Expectation:
>>>
>>> NANOG will not be involved in any syllabus or coursework for the students.
>>> The NANOG organization will provide an agenda and slideware for the
>>> materials that the students will be viewing and expects their professor to
>>> determine the best way their students can extract educational value from
>>> the NANOG program. NANOG asks, in return, that all students complete our
>>> surveys in full and that their teaching staff provide us with a summary of
>>> how they used our program in the classroom and/or in coursework. A few
>>> paragraphs from each student explaining the value that they got from the
>>> program and social interactions would also be a good idea.
>>>
>>>
>>> Q&A:
>>>
>>> Q: What is NANOG and what is the value proposition for sending a student
>>> to
>>> this conference?
>>>
>>> A: The North American Network Operators Group or NANOG, is the
>>> professional
>>> association for Internet engineering and architecture. Our core focus is
>>> on
>>> the technologies and systems that make the Internet function: core routing
>>> and switching; Internet inter-domain routing; the domain name system;
>>> peering and interconnection; and Internet core security. We also cover
>>> associated areas with a direct impact on Internet architecture such as
>>> data
>>> centers and optical networking.  The value proposition for the student is
>>> exposure to all of these subjects and technical material but more
>>> importantly to the organizations and individuals.  The opportunity for
>>> students to make industry contacts is invaluable.
>>>
>>> Q: How do we select students for this sponsorship?
>>>
>>> A: Send your best and brightest, highlight that the value is the density
>>> of
>>> industry representatives in a common location.
>>>
>>> Q: What do the students owe back to NANOG?
>>>
>>> A: In addition to the anonymous surveys that all attendees are asked to
>>> complete, the NANOG Board would request that all sponsorship recipients
>>> provide feedback on their experiences.  Lastly, we would like to encourage
>>> the students join the mailing list (nanog at nanog.org), attend more
>>> conferences and get involved in the industry.
>>>
>>> Q: How do we evaluate our students participation?
>>>
>>> A: Students could provide a variety of deliverables back to the
>>> institution.  These could include a writeup of selected presentations from
>>> the agenda, an overview of the conference as a whole, or even a list of
>>> the
>>> individuals they met during the conference.
>>>
>>> Q: What will be covered in the sponsorship?
>>>
>>> A: Hotel, conference fee, airfare, and a reasonable stipend for
>>> incidentals
>>> such as meals.
>>>
>>> Q: Why are you sponsoring our students for this conference?
>>>
>>> A: The NANOG organization is keen to encourage the future technology
>>> leaders and innovators to get interested and involved in this segment of
>>> the industry.
>>>



From jra at baylink.com  Sun Sep 28 01:10:28 2014
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 27 Sep 2014 21:10:28 -0400 (EDT)
Subject: update
In-Reply-To: <24b0a923ef5f87488cdaf5dfe681937a@mail.dessus.com>
Message-ID: <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Keith Medcalf" <kmedcalf at dessus.com>

> Unfortunately, that page contains near the top the ludicrous and
> impossible assertion:
> 
> ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of
> Legacy Code in Zero-Day Vulnerabilities", by Clark, Fry, Blaze and
> Smith makes clear that ignoring these devices is foolhardy;
> unmaintained systems become more vulnerable, with time."
> 
> It is impossible for unchanged/unmaintained systems to develop more
> vulnerabilities with time. Perhaps what these folks mean is that
> "vulnerabilities which existed from the time the system was first
> developed become more well known over time".

That's not actually true.  A running process, instantiated from a file
of object code, derives its behavior from a number of interfaces; to the
kernel, the libc, the filesystem of the machine it's run on, and even 
network interfaces off the machine.

While the device itself may be -- or seem to be -- immutable, unless you're
certain that *nothing around it changed either*, then you cannot assume
that things became vulnerabilities *as deployed* which were not so previously.

Ok, yes, that's partially equivalent to what you said, at least in the
case of, say, consumer routers, booting from flash.  But for code running
on real OSs, it's possible for a vulnerability to "appear" because something
under or beside the code got updated, turning something which could not
be attacked into something which could.

I haven't an example case, but it is theoretically possible.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From mysidia at gmail.com  Sun Sep 28 02:48:34 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 27 Sep 2014 21:48:34 -0500
Subject: update
In-Reply-To: <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>
References: <24b0a923ef5f87488cdaf5dfe681937a@mail.dessus.com>
 <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAAAwwbVc0qJTU0oWEJWjsrU3ELi5_W53G=xwC7M_6CJHHUgaeA@mail.gmail.com>

On Sat, Sep 27, 2014 at 8:10 PM, Jay Ashworth <jra at baylink.com> wrote:
> I haven't an example case, but it is theoretically possible.

Qmail-smtpd  has a buffer overflow vulnerability related to integer
overflow which can only be reached when compiled on a 64-bit platform.
x86_64  did not exist when the code was originally written.

If memory serves,  the author never acknowledged the vulnerability and
declined to pay bounty or fix the bug stating   that nobody allows
gigabytes of RAM per smtp process.

However.... you see, there you have a lingering bug that can be
exposed under the right environment....   (Year 2030...  computers
have Petabytes of RAM...  why would you seriously limit any one
process to less than a terabyte....?)

-> http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html

> Cheers,
> -- jra
--
-JH


From kmedcalf at dessus.com  Sun Sep 28 04:07:07 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 27 Sep 2014 22:07:07 -0600
Subject: update
In-Reply-To: <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>
Message-ID: <f8cc0d3084944e4391e451e473e5583f@mail.dessus.com>

>> Unfortunately, that page contains near the top the ludicrous and
>> impossible assertion:

>> ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of
>> Legacy Code in Zero-Day Vulnerabilities", by Clark, Fry, Blaze and
>> Smith makes clear that ignoring these devices is foolhardy;
>> unmaintained systems become more vulnerable, with time."

>> It is impossible for unchanged/unmaintained systems to develop more
>> vulnerabilities with time. Perhaps what these folks mean is that
>> "vulnerabilities which existed from the time the system was first
>> developed become more well known over time".

>That's not actually true.  A running process, instantiated from a file
>of object code, derives its behavior from a number of interfaces; to the
>kernel, the libc, the filesystem of the machine it's run on, and even
>network interfaces off the machine.

>While the device itself may be -- or seem to be -- immutable, unless
>you're
>certain that *nothing around it changed either*, then you cannot assume
>that things became vulnerabilities *as deployed* which were not so
>previously.

>Ok, yes, that's partially equivalent to what you said, at least in the
>case of, say, consumer routers, booting from flash.  But for code running
>on real OSs, it's possible for a vulnerability to "appear" because
>something
>under or beside the code got updated, turning something which could not
>be attacked into something which could.

>I haven't an example case, but it is theoretically possible.

No, it is not.  If you have "changed something" then the system is not unchanged.  For example, if you have updated libc, applied a patch to something, changed the network adapter and therefore the drivers, you have changed the "vulnerability profile" of the box (or, more correctly everything in the path of direct connection to the change).  This is why there is change control.  So that when you "make a change" you can assess the impact of the change on *everything* it affects.  A running process on a commodity OS on a given box will not spontaneously have vulnerabilities created or destroyed save and except by a change made within the "sphere of influence" (meaning, in that case, anything inside "the box").

By very definition an "unmaintained" system is not subjected to change, and therefore the vulnerability profile cannot change.

For example, if I build a Linux machine running Slackware 1.0 (I had one of those running for many years) that is performing a specific task, and that "box" is not maintained (that is, no changes are made to any part of the software or hardware comprising the box), then the vulnerability profile does not change despite the passage of 15 years of time.  It cannot spontaneously have a new vulnerability created five years after commissioning that did not exist at the time it was commissioned, nor can one that existed at commissioning go away.  By the same token, external change -- for example increasing the network transit of the network to which "the box" is connected from an ISDN connection to a DS3 -- does not change the "vulnerability profile" of the box itself; and, cannot cause a new vulnerability to be created or destroyed within  that box.  Such an "external change" may affect the likelihood of exploitation of a pre-existing vulnerability, but cannot create a new vulnerability nor cause one that exists to go away.

This is why XP (for example) becomes *more* secure when Microsoft support ends, not *less*.  It is no longer subject to change and therefore its vulnerability profile has become fixed, rather than a perpetually moving target.  From the time the box becomes "no longer subject to change" it will have its vulnerability profile fixed at that point right up until it is decommissioned (or decommissions itself by, for example, having the magic smoke escape).

This then leads to the assessment of the value of "vendor support".  "Vendor Support" that is predicated on a perpetual requirement to make change for change sake (such as Microsoft updates) is a negative value proposition and is unmaintainable.  It is impossible to perform the required re-assessments at the fantastic rate of change imposed by such systems.  On the other hand, "Vendor Support" which does not require perpetual change, has a value and that value is the difference between the future value of the series of recurring "support" fee's and the cost of "replacement" of the affected component when a "change" has been assessed to be necessary, either to remove a pre-existing vulnerability (which may no longer be able to be mitigated, or may be excessively expensive to mitigate) or for new features (or hardware warranty services, for example, in the specific case of SmartNet contracts).  The decision to implement the change (and thus an evaluable shift in the vulnerability profile, which becomes fixed at the time the change is made and continues unchanged, right up until the next change occurs) is subject to rational management of change processes and rational analysis.

For systems predicated on massive continual change the impact of which cannot be assessed (such as most "Microsoft" products, or Adobe Flash, or, <there are several others>) leads to a complacent dependence on the vendor due to a complete inability to rationally assess the vulnerabilities contained in such systems or anything "within the sphere of direct influence" of them.  This then has the effect of imposing "dependence" and "lock in" to the vendor.  Commodity computing hardware vendors (Dell is an example) do the same thing as well, deliberately imposing uncontrollable change with deliberate requirements for implementation of non-consequent change (ie, deliberately removing compatibility in order to force upgrades to new versions of Microsoft Windows), in order to "lock" their customers into their products and institute dependent behaviour.  Interestingly the behaviour of vendors and the customers of vendors with such practices is remarkably similar to the behavioural traits displayed by crack addicts and their dealers.






From Valdis.Kletnieks at vt.edu  Sun Sep 28 04:46:39 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 28 Sep 2014 00:46:39 -0400
Subject: update
In-Reply-To: Your message of "Sat, 27 Sep 2014 21:10:28 -0400."
 <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>
References: <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>
Message-ID: <68040.1411879599@turing-police.cc.vt.edu>

On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said:

> I haven't an example case, but it is theoretically possible.

The sendmail setuid bug, where it failed to check the return code
because it was *never* possible for setuid from root to non-root to fail...
... until the Linux kernel grew new features.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140928/a1c1c556/attachment.sig>

From kmedcalf at dessus.com  Sun Sep 28 04:50:31 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 27 Sep 2014 22:50:31 -0600
Subject: update
In-Reply-To: <CAAAwwbVc0qJTU0oWEJWjsrU3ELi5_W53G=xwC7M_6CJHHUgaeA@mail.gmail.com>
Message-ID: <34c2578b1325d341ab62a856c7f40283@mail.dessus.com>


On Saturday, 27 September, 2014 20:49, Jimmy Hess said:
>On Sat, Sep 27, 2014 at 8:10 PM, Jay Ashworth <jra at baylink.com> wrote:
>> I haven't an example case, but it is theoretically possible.

>Qmail-smtpd  has a buffer overflow vulnerability related to integer
>overflow which can only be reached when compiled on a 64-bit platform.
>x86_64  did not exist when the code was originally written.

>If memory serves,  the author never acknowledged the vulnerability and
>declined to pay bounty or fix the bug stating   that nobody allows
>gigabytes of RAM per smtp process.

>However.... you see, there you have a lingering bug that can be
>exposed under the right environment....   (Year 2030...  computers
>have Petabytes of RAM...  why would you seriously limit any one
>process to less than a terabyte....?)

>-> http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html

** the person making the change in this instance is referred to as "you".  This is not to imply that it is any of you personally, but simply because it is easier to write using that pronoun rather than figuring out an appropriate third-person descriptive.  I personally think "the retard" is most appropriate, but then that is just me :)

In this case however, you have implemented a change and it has changed the vulnerability profile.  Presumably at one point you were running Qmail-smtpd on x86 (32-bit).  You introduced a change (x86 -> x64) which changed the vulnerability profile.  Perhaps you implemented two changes -- one to an x64 kernel, and second to an x64 userland.  Whatever the case, there was still a change, and it was only because of the change that the vulnerability manifested.

If you had not made the change, you would not have introduced the vulnerability.

That your assessment of the change in vulnerability profile resulting from your change was defective is the whole point of this discussion.  

If you had been rational about the change to from x86 -> x64 and 32-bit userland to 64-bit userland, you would have limited all processes to the same per-process address space as they had in the x86 model in order to prevent the introduction of vulnerabilities such as this, and only permitted larger address spaces for processes that required them (ie, were part of the justification for making the change).  If the change was "thrust upon you" with no justification, then the "thruster" should be terminated (with extreme prejudice, if possible).  Notwithstanding, if you are responsible for the Safety and Security of the system changed, you should go stand in the corner for failing to perform your job adequately, or perhaps be promoted to management where you will no longer be a threat.

And the assumption about "(Year 2030...  computers have Petabytes of RAM...  why would you seriously limit any one process to less than a terabyte....?)" implies that there is an intent to implement further change. 

Before you make the change to "computers having petabytes of RAM" and "not limiting any process to less than a terabyte of per process address space", I would hope that you would assess the impact of that change.  Especially since you now have additional information on which to generate a more accurate assessment of the impact of making that change, and what mitigations you should put in place when you make that change to prevent yourself from being either terminated with extreme prejudice or promotion to management (unless, of course, those are your goals).

One of the reasons for "limiting a process to less than a terabyte of process address space" is that it may lead to the manifestation of vulnerabilities such as the one discussed here.  

My original proposition still holds perfectly:  

(1) The vulnerability profile of a system is fixed at system commissioning.
(2) Vulnerabilities do not get created nor destroyed except through implementation of change.
(3) If there is no change to a system, then there can be no change in its vulnerabilities.

Of course, you must set the boundaries of "system" correctly.  Choosing the wrong boundary may cause you to mislead yourself as to what a particular change may impact.






From kmedcalf at dessus.com  Sun Sep 28 04:57:53 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 27 Sep 2014 22:57:53 -0600
Subject: update
In-Reply-To: <68040.1411879599@turing-police.cc.vt.edu>
Message-ID: <9d5b5fbb41535c49a1de80ac1bbf339b@mail.dessus.com>


This is another case where a change was made.

If the change had not been made (implement the new kernel) then the vulnerability would not have been introduced.

The more examples people think they find, the more it proves my proposition.  Vulnerabilities can only be introduced or removed through change.  If there is no change, then the vulnerability profile is fixed.

>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of
>Valdis.Kletnieks at vt.edu
>Sent: Saturday, 27 September, 2014 22:47
>To: Jay Ashworth
>Cc: NANOG
>Subject: Re: update
>
>On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said:
>
>> I haven't an example case, but it is theoretically possible.
>
>The sendmail setuid bug, where it failed to check the return code
>because it was *never* possible for setuid from root to non-root to
>fail...
>... until the Linux kernel grew new features.





From bill at herrin.us  Sun Sep 28 06:39:15 2014
From: bill at herrin.us (William Herrin)
Date: Sun, 28 Sep 2014 02:39:15 -0400
Subject: update
In-Reply-To: <24b0a923ef5f87488cdaf5dfe681937a@mail.dessus.com>
References: <CAGhGL2BLs0jhjGOU1DSqjt369pFNf_=+R_uStvBRVe8WikWXtA@mail.gmail.com>
 <24b0a923ef5f87488cdaf5dfe681937a@mail.dessus.com>
Message-ID: <CAP-guGXM5pqAGnD9KBqe+AgEidtHmX3tBq5pSZ0D=Vow+w5hZw@mail.gmail.com>

On Fri, Sep 26, 2014 at 11:11 PM, Keith Medcalf <kmedcalf at dessus.com> wrote:
> On Friday, 26 September, 2014 08:37,Jim Gettys <jg at freedesktop.org> said:
>>http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys
>
> ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy
> Code in Zero-Day Vulnerabilities",  by Clark, Fry, Blaze and Smith makes clear
> that ignoring these devices is foolhardy; unmaintained systems become more
> vulnerable, with time."
>
> It is impossible for unchanged/unmaintained systems to develop more
> vulnerabilities with time.  Perhaps what these folks mean is that
> "vulnerabilities which existed from the time the system was first
> developed become more well known over time".

Keith,

Any statement can be made foolish if you tweak the words a little.
They said, "Unmaintained systems become more vulnerable with time," a
reasonable and possibly correct claim. You paraphrased it as,
"unmaintained systems develop more
vulnerabilities with time," which is, of course, absurd.

The vulnerabilities were there the whole time, but the progression of
discovery and dissemination of knowledge about those vulnerabilities
makes the systems more vulnerable. The systems are more vulnerable
because the rest of the world has learned more about how those systems
may be successfully attacked.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?


From kmedcalf at dessus.com  Sun Sep 28 06:57:48 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 28 Sep 2014 00:57:48 -0600
Subject: update
In-Reply-To: <CAFS5k-i6Cw=HhEUbYL8Oy=B9OQuFXKmoRio79f59vAW63qVZAg@mail.gmail.com>
Message-ID: <c3c94bf9a6c2a940af0268dbda3483fa@mail.dessus.com>



On Saturday, 27 September, 2014 23:29, Kenneth Finnegan <kennethfinnegan2007 at gmail.com> said:
>> My original proposition still holds perfectly:
>>
>> (1) The vulnerability profile of a system is fixed at system
>>     commissioning.
>> (2) Vulnerabilities do not get created nor destroyed except through
>>     implementation of change.
>> (3) If there is no change to a system, then there can be no change in
>>     its vulnerabilities.

>Your original proposition is pointlessly academic. Yes, given
>absolutely no changes to the system, it's vulnerability profile does
>not change. 

>Does your "correct" system boundary include the file system? 
>So you're definition of an unchanging system only uses
>read-only file systems. 

Now that would depend, would it not.  If you mean as in storing "data" or processing "data", then obviously not.  If you mean the "executable contents" as in "the contents of the filesystem which are executed as part of the system" then obviously yes.  Changing the "data" content of the filesystem is, in general, why one would implement a system in the first place.  However, changing "executable contents" which are then executed implies a change which must be assessed.

>Does it include the system's load average?
>Can't ever change the number of clients connected to it... Does it
>include the system's uptime?  Etc.

These are only relevant if they are vulnerabilities.  If these things are vulnerabilities I should hope that mitigations are in place to prevent them from being exploited, and that these mitigations were put in place from the get-go rather than when they appeared on CNN.

>So yes, you're right. The number of existing vulnerabilities in a
>system never changes. It's just that you've also ruled out every
>system I can imagine being even remotely useful in life, so your
>argument seems to apply to _nothing_.

No, it applies to everything.  It applies to routers and switches and it applies to Mail Servers, and to everything else.  When a network device is implemented everyone makes the assumption that it is, other than its designed function (switching packets), a zero-security device.  This is why there is control-plane policing.  This is why you segregate the management network.  This is why you create isolated management access.  This is why you do not open up telnet, ssh, ftp, tftp, http, and whatever else to "anyone" on the internet.

If you do this properly, you do not care much about vulnerabilities in telnet, ssh, ftp, tftp, or http because they cannot be exploited (or rather, any such issues can only be exploited by a known set of actors).  You have put mitigations in place to address the risks and any possible vulnerabilities.  Just because no one has yet demonstrated a vulnerability does not mean that it does not exist.

If you have done this properly (ie, you acted prudently), you no longer care whether there are vulnerabilities or not, because you already have mitigations in place that would prevent them from being exploited (whether they exist or not).

Then everytime you see on CNN that there is a new major flaw in the swashbuckle that can be taken advantage of by a bottle of whiskey, you pat yourself on the back and congratulate yourself having already assessed that there might be a problem in the swashbuckle when whiskey was present, so you already put in mitigations to prevent that.  Or maybe you decided that you don't need to swashbuckle at all so you disabled that feature, in which case you don't really care about the supply of whiskey either.

>What does change for a system is the threat profile as exploits become
>better known. Arguing that it is better to blissful march onward with
>what is *known* to be a vulnerable system instead of rolling out
>stable branch security updates that *generally* contain less bugs
>demonstrates a lack of pragmatism.

No, blindly rolling out patches which fix things that do not need fixing is foolhardy.  It may very well be that the particular version of IOS  running has a vulnerability in the http server portion of the software.  However, that service is disabled because after rational evaluation it was decided (when the system was implemented) that the http feature was not required and as part of prudent policy, things which are not required were disabled.  Therefore, implementation of the change to fix the vulnerability provides zero benefit.  In fact, implementation of the change may have other detrimental effects which I will not know until after implementing the change.  Therefore, the cost/benefit and risk analysis clearly indicates that the change should not be made.

However, if the change fixes an issue with regards to packet switching/forwarding, and if I am experiencing the issue or might experience the issue, then I should consider applying the change sooner or later, as warranted by the circumstances.  On the other hand, if it is impossible for the circumstance to arise which will lead to the manifestation of the issue that is the subject of the change, then I should not implement the change.

The same can be applied to "upgrading" to an x64 system from an x86 system.  If there is no need driving the upgrade, then why do it?  Doing so changes the "vulnerability profile" to something different from what it was, and you may fail to account for all the vulnerabilities in the new profile (for example buffer overflows and arithmetic overflows due to the increased size of the process address space).  If the current system is working perfectly and has all the appropriate mitigations in place to keep it safe and secure (in the operational sense), then the cost/benefit and risk analysis clearly indicates that the change should not be made.

>I'm sorry that someone on the Internet hasn't precisely used your
>made-up distinction between a "vulnerability profile" and the actual
>threat level given the current state of the rest of the universe. 

Operations folks make decisions based on the "vulnerability profile" all the time, whether they realize it or not, and generally could care less about the "threat profile".  If an operational concern comes about because of a change in the "threat level" then there has been a failure to properly assess the "vulnerability profile" and apply appropriate mitigations; and, that failure happened long before the news hit the mainstream media.  It is only if the change in the "threat profile" in light of the existing mitigations already in place as a result of assessing the "vulnerability profile" indicates that a change must be implemented, should a change be implemented.  This would also require a re-assessment of the "vulnerability profile" of all existing systems as a result of the new information.

>We >really don't need to be splitting hairs about this on the NANOG
>list...

This may or may not be true.  I suspect the density of real Operations folks is greater here than just about anywhere else.  (and by that I mean the number of list subscribers that have actual operational responsibilities for keeping things running safely and securely).






From kmedcalf at dessus.com  Sun Sep 28 07:19:42 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 28 Sep 2014 01:19:42 -0600
Subject: update
In-Reply-To: <CAP-guGXM5pqAGnD9KBqe+AgEidtHmX3tBq5pSZ0D=Vow+w5hZw@mail.gmail.com>
Message-ID: <63bc8bd589e6f84dadd9f8bb13354db8@mail.dessus.com>


On Sunday, 28 September, 2014 00:39, William Herrin said:
>On Fri, Sep 26, 2014 at 11:11 PM, Keith Medcalf <kmedcalf at dessus.com>
>wrote:
>> On Friday, 26 September, 2014 08:37,Jim Gettys <jg at freedesktop.org>
>>said:
>>>http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys

>> ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of
>> Legacy Code in Zero-Day Vulnerabilities",  by Clark, Fry, Blaze and 
>> Smith makes clear that ignoring these devices is foolhardy; 
>> unmaintained systems become more vulnerable, with time."

>> It is impossible for unchanged/unmaintained systems to develop more
>> vulnerabilities with time.  Perhaps what these folks mean is that
>> "vulnerabilities which existed from the time the system was first
>> developed become more well known over time".

>Keith,

>Any statement can be made foolish if you tweak the words a little.
>They said, "Unmaintained systems become more vulnerable with time," a
>reasonable and possibly correct claim. You paraphrased it as,
>"unmaintained systems develop more
>vulnerabilities with time," which is, of course, absurd.

>The vulnerabilities were there the whole time, but the progression of
>discovery and dissemination of knowledge about those vulnerabilities
>makes the systems more vulnerable. The systems are more vulnerable
>because the rest of the world has learned more about how those systems
>may be successfully attacked.

You are absolutely correct, Bill.  

The truly correct statement of affairs is that the pre-existing 
vulnerabilities, which have not been mitigated, become more 
likely to be exploited over time.

That premise would change the tenor of the paper entirely from 
crack addict encouragement to giving the useful advice that 
the issue stems not from the failure of the dealer to continue
providing more crack, but rather from the consumers failure
to realize that smoking crack is dangerous and may be deleterious
to one's health unless suitable precautions are taken before
engaging in the activity.

If one fully and correctly assess the avenues by which exploitation 
may occur and fully mitigates those avenues of attack, then the
system, although unmaintained, does not become subject to increased
likelihood of having vulnerabilities exploited over time.

>Regards,
>Bill Herrin






From mysidia at gmail.com  Sun Sep 28 12:38:33 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 28 Sep 2014 07:38:33 -0500
Subject: update
In-Reply-To: <9d5b5fbb41535c49a1de80ac1bbf339b@mail.dessus.com>
References: <68040.1411879599@turing-police.cc.vt.edu>
 <9d5b5fbb41535c49a1de80ac1bbf339b@mail.dessus.com>
Message-ID: <CAAAwwbUUyP_fk4+Rzg0dakCg+UJUpkMhOJdYJ-zJs6Fizk27QA@mail.gmail.com>

On Sat, Sep 27, 2014 at 11:57 PM, Keith Medcalf <kmedcalf at dessus.com>
wrote:> This is another case where a change was made.
> If the change had not been made (implement the new kernel) then the vulnerability would not have been introduced.
>[...]
> The more examples people think they find, the more it proves my proposition.  Vulnerabilities can only be introduced or removed through change.  If there is no change, then the vulnerability profile is fixed.

I see what you did there... you expanded the boundaries of the
"system" to include not just the application code but more and more of
the environment, CPU, Kernel, ....

The problem is, before it is an entirely correct statement to assert
that a zero entropy system never develops new vulnerabilities, you
have to expand the boundaries of the "system"  to include the entire
planet.

Suppose you have a vulnerability that can only be exposed if port 1234
is open.   That's no problem,  you blocked port 1234 on the external
firewall, therefore the application cannot be considered to be
vulnerable during testing.

A few years later you replace the firewall with a NAT router that
doesn't block port 1234.

Oops!  Now you have to consider the entire network and the Firewall to
be part of the application  / internal part of the system.

And it doesn't end there.   Eventually for the statement to remain
true, the boundaries of the system which 'cannot develop a
vulnerability unless it changes' have to expand  in order to include
the attackers' brains.

"If the attacker discovers a new trick or kind of attack they did not
know before"   then a change to the system has occured.


--
-JH


From kmedcalf at dessus.com  Sun Sep 28 15:08:37 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 28 Sep 2014 09:08:37 -0600
Subject: update
In-Reply-To: <CAAAwwbUUyP_fk4+Rzg0dakCg+UJUpkMhOJdYJ-zJs6Fizk27QA@mail.gmail.com>
Message-ID: <a3e892e37bd4444a92e7474d09a89051@mail.dessus.com>


On Sunday, 28 September, 2014 06:39, Jimmy Hess <mysidia at gmail.com> said:
>On Sat, Sep 27, 2014 at 11:57 PM, Keith Medcalf <kmedcalf at dessus.com>
>wrote:> This is another case where a change was made.

>> If the change had not been made (implement the new kernel) then the
>vulnerability would not have been introduced.

>> The more examples people think they find, the more it proves my
>proposition.  Vulnerabilities can only be introduced or removed through
>change.  If there is no change, then the vulnerability profile is fixed.

>I see what you did there... you expanded the boundaries of the
>"system" to include not just the application code but more and more of
>the environment, CPU, Kernel, ....

No, those are part of the system and have a direct effect on the "application code".  Whether the network connection is two tin cans and a string, twisted pair or fiber is irrelevant.  Whether you are located on the third floor or the fourth floor is (likely) irrelevant.  However, changing the network connection from two tin cans and a string to fiber is relevant if it affects the system.  Such an effect would be a change of the network interface hardware and the requisite change in drivers.  If the existing hardware and software can already handle both fiber and tin cans and string, then the change cannot affect the system since you are not changing anything upon which operation of the system is dependent.

>The problem is, before it is an entirely correct statement to assert
>that a zero entropy system never develops new vulnerabilities, you
>have to expand the boundaries of the "system"  to include the entire
>planet.

Incorrect.  The whole planet does not directly affect the system.  Well, that is not entirely true.  There could be an earthquake that knocks the building down.  Presumably you have mitigations in place for that -- usually a continuity and recovery plan.  The planet could also be struck by a meteor causing an extinction level event to occur.  There would probably be no need to mitigate that.

>Suppose you have a vulnerability that can only be exposed if port 1234
>is open.   That's no problem,  you blocked port 1234 on the external
>firewall, therefore the application cannot be considered to be
>vulnerable during testing.

The first action would be to disable the vulnerable service using port 1234, assuming that it is unnecessary.  If it is necessary for some use or cannot be disabled, then you either mitigate the vulnerability by filtering in an external firewall, or decide to accept the risk of operating with a (possible) known vulnerability.  These actions do not remove the vulnerability -- they mitigate exploit of the vulnerability.  The vulnerability is still there.

>A few years later you replace the firewall with a NAT router that
>doesn't block port 1234.

>Oops!  Now you have to consider the entire network and the Firewall to
>be part of the application  / internal part of the system.

No, they are part of the mitigation for the vulnerability in the first system.  You have not changed the first system, you have decided to no longer mitigate its vulnerability.  Presumably you did this based on a rational assessment of the risks and benefits of doing so because you evaluated the effect of the change to the firewall, noted that port 1234 would no longer be filtered, and as a result the mitigation for the vulnerability in the first system would no longer be in place and that exploit of that vulnerability was now possible.

>And it doesn't end there.   Eventually for the statement to remain
>true, the boundaries of the system which 'cannot develop a
>vulnerability unless it changes' have to expand  in order to include
>the attackers' brains.

But you did not change the fact that port 1234 in the first system contains a vulnerability.  It was vulnerable from the get-go so you implemented a mitigation.  You did not make the vulnerability "go away" you merely reduced the risk of exploit to an acceptable level.  When you changed the firewall system you did not introduce a vulnerability in the first system.  You merely decided to change the risk of exploit of a pre-existing condition.

>"If the attacker discovers a new trick or kind of attack they did not
>know before"   then a change to the system has occurred.

No.  Either you have already addressed the possibility of the vulnerability existing and how it might be exploited, or you have not.  If you did not consider the possibility that of the vulnerability, then upon learning of its existence you either need to implement a change to fix it, or implement a mitigation of some type.  Conversely, if adequate mitigation is already in place or the vulnerability is moot (for example, the vulnerable service is externally filtered or is disabled), then an increase in the knowledge of the attacker is irrelevant.







From john at op-sec.us  Sun Sep 28 03:06:57 2014
From: john at op-sec.us (John Fraizer)
Date: Sat, 27 Sep 2014 23:06:57 -0400
Subject: Security Update: Muli-Router Looking Glass (MRLG) version 5.5.0
 released
Message-ID: <CALxrgME7VndG1-wvXskoEh9GXee97LfBKkqCr_GCXcJ6hDTZQg@mail.gmail.com>

I was contacted by Luca Bruno a couple of months ago regarding the
fastping.c utility that has been included with MRLG for the past 14 years.
It seems that fastping.c is vulnerable to a crafted attack that can cause
remote memory overwrite/corruption.

The fastping.c utility was only used by MRLG in the outside chance that the
"router" in question was Zebra/Quagga.  Based on Google results, this is a
very minuscule minority of installations that utilize MRLG.

I was OCONUS with limited connectivity when Luca contacted me, in addition
to being up to my eyeballs dealing with a Southeast Asia network redesign.

Last night, I had some downtime and was able to put together a (superior?)
replacement for fastping.c that utilizes the existing ping utility on the
MRLG host system while emulating the Cisco IOS ping facility.

I have released MRLG 5.5.0 as of Sat Sep 27 03:16:28 UTC 2014.  It is a
(nearly) drop-in replacement for all previous versions of MRLG that
addresses the issue that Luca Bruno and Mariano Graziano brought to light
in CVE-2014-3931. See: http://www.s3.eurecom.fr/cve/CVE-2014-3931.txt

The latest MRLG (5.5.0) is available at http://mrlg.op-sec.us/

I know that the details of this CVE was published at:
http://mailman.nanog.org/pipermail/nanog/2014-July/068014.html and
http://www.s3.eurecom.fr/lg/defcon_looking-glass.pdf
http://vrt-blog.snort.org/2014/09/looking-glasses-with-bacon.html
http://tools.cisco.com/security/center/viewAlert.x?alertId=35693
https://www.defcon.org/images/defcon-22/dc-22-presentations/Bruno-Graziano/DEFCON-22-Luca-Bruno-Mariano-Graziano-looking-glass-Updated.pdf
https://www.usenix.org/system/files/conference/woot14/woot14-bruno.pdf

There are likely many other locations at which CVE-2014-3931 is detailed.

I ask that the NANOG community make it known - via whatever channels - that
this vulnerability has been addressed and mitigated and that you please
point folks to http://mrlg.op-sec.us/ for the latest code.

Many thanks!

--
John Fraizer
????


From kennethfinnegan2007 at gmail.com  Sun Sep 28 05:29:14 2014
From: kennethfinnegan2007 at gmail.com (Kenneth Finnegan)
Date: Sat, 27 Sep 2014 22:29:14 -0700
Subject: update
In-Reply-To: <34c2578b1325d341ab62a856c7f40283@mail.dessus.com>
References: <CAAAwwbVc0qJTU0oWEJWjsrU3ELi5_W53G=xwC7M_6CJHHUgaeA@mail.gmail.com>
 <34c2578b1325d341ab62a856c7f40283@mail.dessus.com>
Message-ID: <CAFS5k-i6Cw=HhEUbYL8Oy=B9OQuFXKmoRio79f59vAW63qVZAg@mail.gmail.com>

> My original proposition still holds perfectly:
>
> (1) The vulnerability profile of a system is fixed at system commissioning.
> (2) Vulnerabilities do not get created nor destroyed except through implementation of change.
> (3) If there is no change to a system, then there can be no change in its vulnerabilities.

Your original proposition is pointlessly academic. Yes, given
absolutely no changes to the system, it's vulnerability profile does
not change. Does your "correct" system boundary include the file
system? So you're definition of an unchanging system only uses
read-only file systems. Does it include the system's load average?
Can't ever change the number of clients connected to it... Does it
include the system's uptime?  Etc.

So yes, you're right. The number of existing vulnerabilities in a
system never changes. It's just that you've also ruled out every
system I can imagine being even remotely useful in life, so your
argument seems to apply to _nothing_.

What does change for a system is the threat profile as exploits become
better known. Arguing that it is better to blissful march onward with
what is *known* to be a vulnerable system instead of rolling out
stable branch security updates that *generally* contain less bugs
demonstrates a lack of pragmatism.

I'm sorry that someone on the Internet hasn't precisely used your
made-up distinction between a "vulnerability profile" and the actual
threat level given the current state of the rest of the universe. We
really don't need to be splitting hairs about this on the NANOG
list...

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/


From jra at baylink.com  Sun Sep 28 17:22:57 2014
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 28 Sep 2014 13:22:57 -0400 (EDT)
Subject: update
In-Reply-To: <a3e892e37bd4444a92e7474d09a89051@mail.dessus.com>
Message-ID: <22337429.3366.1411924977345.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Keith Medcalf" <kmedcalf at dessus.com>

> >The problem is, before it is an entirely correct statement to assert
> >that a zero entropy system never develops new vulnerabilities, you
> >have to expand the boundaries of the "system" to include the entire
> >planet.
> 
> Incorrect. The whole planet does not directly affect the system. Well,
> that is not entirely true. There could be an earthquake that knocks
> the building down. Presumably you have mitigations in place for that
> -- usually a continuity and recovery plan. The planet could also be
> struck by a meteor causing an extinction level event to occur. There
> would probably be no need to mitigate that.

"The Internet is the only endeavour of man in which a single-character 
typographical error in a file on a computer on the other side of the 
planet *which you do not even know exists* can take your entire business
off line for the better part of a day."

-- Someone, in the wake of the (I think) Turkish YouTube BGP hijacking;
    damn if I remember who.  I might be embellishing.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Sun Sep 28 17:26:33 2014
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 28 Sep 2014 13:26:33 -0400 (EDT)
Subject: update
In-Reply-To: <9d5b5fbb41535c49a1de80ac1bbf339b@mail.dessus.com>
Message-ID: <2252562.3368.1411925193794.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Keith Medcalf" <kmedcalf at dessus.com>

> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of
> >Valdis.Kletnieks at vt.edu

> >On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said:
> >
> >> I haven't an example case, but it is theoretically possible.
> >
> >The sendmail setuid bug, where it failed to check the return code
> >because it was *never* possible for setuid from root to non-root to
> >fail...
> >... until the Linux kernel grew new features.

> This is another case where a change was made.
> 
> If the change had not been made (implement the new kernel) then the
> vulnerability would not have been introduced.
> 
> The more examples people think they find, the more it proves my
> proposition. Vulnerabilities can only be introduced or removed through
> change. If there is no change, then the vulnerability profile is
> fixed.

[ quoting fixed because you were too lazy ]

We have established, Keith, that you place the boundary of the object
for which an end-deployer has administrative control in a different place
for the purpose of assigning blame than most other people seem to, yes.

The sendmail maintainers are *NOT RESPONSIBLE* for avoiding exploits that
cannot happen in any available or planned deployment environment, nor for
decisions made by the creators of those environments which *cause their
code to become exploitable ex-post-facto*.  That's the point which I see
being made here.  If that's orthogonal to your argument, so be it.

Could we drop this now?

Cheers,
-- jra

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From Valdis.Kletnieks at vt.edu  Sun Sep 28 20:47:13 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 28 Sep 2014 16:47:13 -0400
Subject: update
In-Reply-To: Your message of "Sun, 28 Sep 2014 02:39:15 -0400."
 <CAP-guGXM5pqAGnD9KBqe+AgEidtHmX3tBq5pSZ0D=Vow+w5hZw@mail.gmail.com>
References: <CAGhGL2BLs0jhjGOU1DSqjt369pFNf_=+R_uStvBRVe8WikWXtA@mail.gmail.com>
 <24b0a923ef5f87488cdaf5dfe681937a@mail.dessus.com>
 <CAP-guGXM5pqAGnD9KBqe+AgEidtHmX3tBq5pSZ0D=Vow+w5hZw@mail.gmail.com>
Message-ID: <104443.1411937233@turing-police.cc.vt.edu>

On Sun, 28 Sep 2014 02:39:15 -0400, William Herrin said:

> The vulnerabilities were there the whole time, but the progression of
> discovery and dissemination of knowledge about those vulnerabilities
> makes the systems more vulnerable. The systems are more vulnerable
> because the rest of the world has learned more about how those systems
> may be successfully attacked.

Hopefully, Keith will admit that *THAT* qualifies as a "change" in his
book as well.  If attackers are coming at you with an updated copy
of Metasploit, things have changed....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140928/c1c0154e/attachment.sig>

From Valdis.Kletnieks at vt.edu  Sun Sep 28 21:06:01 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 28 Sep 2014 17:06:01 -0400
Subject: update
In-Reply-To: Your message of "Sat, 27 Sep 2014 22:50:31 -0600."
 <34c2578b1325d341ab62a856c7f40283@mail.dessus.com>
References: <34c2578b1325d341ab62a856c7f40283@mail.dessus.com>
Message-ID: <105251.1411938361@turing-police.cc.vt.edu>

On Sat, 27 Sep 2014 22:50:31 -0600, "Keith Medcalf" said:
> If you had been rational about the change to from x86 -> x64 and 32-bit
> userland to 64-bit userland, you would have limited all processes to the same
> per-process address space as they had in the x86 model in order to prevent the
> introduction of vulnerabilities such as this, and only permitted larger address
> spaces for processes that required them (ie, were part of the justification for
> making the change).

If security was *that* easy, we'd all be good at it.

First off, security never lives in a vacuum - it gets to trade off with other
concerns, like performance and usability.  There are workloads where the fact
that x86_64 uses wider variables and thus more memory bandwidth is outweighed
by the fact that the increased number of effectively usable registers drastically
reduces the number of memory accesses needed. So it's not just about address
space.

Secondly, if you convert everything to the x64_64 model rather than keeping
*two* sets of ABI around, you've just halved your attack surface, and reduced
the number of ways you can accidentally mess yourself up by updating the
64-bit library and missing the 32-bit one (or vice versa).  And if you've just
eaten, I suggest you *not* look at the mess involved in making sure that
things like ioctls pass the same structure to the kernel whether they're
calling from a 32 bit or a 64 bit binary.  So there's a case to be made that
if even only *some* of your code needs 64-bit mode, you should cut it *all*
over....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140928/b19ea527/attachment.sig>

From kmedcalf at dessus.com  Sun Sep 28 21:06:18 2014
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 28 Sep 2014 15:06:18 -0600
Subject: update
In-Reply-To: <104443.1411937233@turing-police.cc.vt.edu>
Message-ID: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>


On Sunday, 28 September, 2014 14:47, Valdis.Kletnieks at vt.edu said:

>On Sun, 28 Sep 2014 02:39:15 -0400, William Herrin said:

>> The vulnerabilities were there the whole time, but the progression of
>> discovery and dissemination of knowledge about those vulnerabilities
>> makes the systems more vulnerable. The systems are more vulnerable
>> because the rest of the world has learned more about how those systems
>> may be successfully attacked.

>Hopefully, Keith will admit that *THAT* qualifies as a "change" in his
>book as well.  If attackers are coming at you with an updated copy
>of Metasploit, things have changed....

Sorry to disappoint, but those are not changes that make the system more
vulnerable.  They are externalities that may change the likelihood of 
exploitation of an existing vulnerability, but does not create any new 
vulnerability.  Again, if the new exploit were targeting a vulnerability
which was fully mitigated already and thus could not be exploited, there
has not even been a change in likelihood of exploit or risk.







From jra at baylink.com  Sun Sep 28 21:12:28 2014
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 28 Sep 2014 17:12:28 -0400 (EDT)
Subject: update
In-Reply-To: <104443.1411937233@turing-police.cc.vt.edu>
Message-ID: <2204186.3388.1411938748821.JavaMail.root@benjamin.baylink.com>

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

> On Sun, 28 Sep 2014 02:39:15 -0400, William Herrin said:
> 
> > The vulnerabilities were there the whole time, but the progression of
> > discovery and dissemination of knowledge about those vulnerabilities
> > makes the systems more vulnerable. The systems are more vulnerable
> > because the rest of the world has learned more about how those
> > systems may be successfully attacked.
> 
> Hopefully, Keith will admit that *THAT* qualifies as a "change" in his
> book as well. If attackers are coming at you with an updated copy
> of Metasploit, things have changed....

I will actually grant to Keith this: the thing he's saying, actually is true.

If you change *anything* on a computer, its attack surface may change one
way or another.

The question is: which of those things can you be reliably be expected to
know about.  And whom you are.

If you are the developer of Sendmail, you can't be expected to know that
*a change to the API of Linux* will make something attackable; there are
too many possible changes, which no one is positing at any given moment, 
and that way lies madness.

Because that's true, you can't be expected to warn your users of it, either,
just as the manufacturer of concrete used to build a bridge could be expected
to warn people who build and use the bridge that "the creation of a 
nanobot that likes to eat portland cement might cause your bridge to 
crumble".

It's true, but it's not especially helpful. To anyone.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From Valdis.Kletnieks at vt.edu  Sun Sep 28 21:50:53 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 28 Sep 2014 17:50:53 -0400
Subject: update
In-Reply-To: Your message of "Sun, 28 Sep 2014 15:06:18 -0600."
 <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
Message-ID: <107190.1411941053@turing-police.cc.vt.edu>

On Sun, 28 Sep 2014 15:06:18 -0600, "Keith Medcalf" said:

> >Hopefully, Keith will admit that *THAT* qualifies as a "change" in his
> >book as well.  If attackers are coming at you with an updated copy
> >of Metasploit, things have changed....
>
> Sorry to disappoint, but those are not changes that make the system more
> vulnerable.  They are externalities that may change the likelihood of
> exploitation of an existing vulnerability, but does not create any new
> vulnerability.  Again, if the new exploit were targeting a vulnerability
> which was fully mitigated already and thus could not be exploited, there
> has not even been a change in likelihood of exploit or risk.

So tell us Keith - since you said earlier that properly designed systems will
already have 100% mitigations against these attackes _that you don't even know
about yet_, how exactly did you design these mitigations?  (Fred Fish's thesis
paper, where he shows that malware detection is equivalent to the Turing Halting
Problem, is actually relevant here).

In particular, how did you mitigate attacks that are _in the data stream
that you're charging customers to carry_? (And yes, there *have* been
fragmentation attacks and the like - and I'm not aware of a formal proof
that any currently shipping IP stack is totally correct, either, so there
may still be unidentified attacks).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140928/af791be6/attachment.sig>

From gtaylor at tnetconsulting.net  Mon Sep 29 03:42:56 2014
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 28 Sep 2014 22:42:56 -0500
Subject: GMail contact  -  misroute / security issue
Message-ID: <5428D540.7080904@tnetconsulting.net>

Hi,

I'm looking for a GMail contact.

My wife is receiving someone else's emails.

Specifically she is receiving emails for <first name><middle 
initial><last name>@gmail.com (no dots) when her email address is really 
<same first name>.<same middle initial>.<same last name>@gmail.com (dots).

I don't know if this is a "feature" or a "bug", but either way, it's 
disquieting my wife.  (Unhappy wife = unhappy life.)

I view this as both non-RFC compliant behavior -and- a potential 
security risk.  (Registering a GMail account as 
<someone><famous>@gmail.com (no dot) to capture email for 
<someone>.<famous>@gmail.com (dot) emails.)

Please reply or email me directly at gtaylor (at) tnetconsulting (dot) 
net for additional details.

Thank you and have a nice day.



-- 
Grant. . . .
unix || die


P.S.  Thus far messages to postmaster at gmail.com and abuse at gmail.com have 
gone unanswered.


From royce at techsolvency.com  Mon Sep 29 03:50:08 2014
From: royce at techsolvency.com (Royce Williams)
Date: Sun, 28 Sep 2014 19:50:08 -0800
Subject: GMail contact - misroute / security issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
Message-ID: <CA+E3k91yLQpxua5PM2KECDGtx6vYgQOQbPtHb-gP2PvBjDe0vA@mail.gmail.com>

On Sun, Sep 28, 2014 at 7:42 PM, Grant Taylor <gtaylor at tnetconsulting.net>
wrote:

> My wife is receiving someone else's emails.
>
> Specifically she is receiving emails for <first name><middle initial><last
> name>@gmail.com (no dots) when her email address is really <same first
> name>.<same middle initial>.<same last name>@gmail.com (dots).


If someone else thinks that the non-dotted email address is theirs, they
are mistaken.

This is a Gmail feature.  Adding or removing dots makes no difference,
other than changing readability.

All versions of the email address are your wife's.

Royce


From ryan.landry at gmail.com  Mon Sep 29 03:50:42 2014
From: ryan.landry at gmail.com (ryanL)
Date: Sun, 28 Sep 2014 20:50:42 -0700
Subject: GMail contact - misroute / security issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
Message-ID: <CAK_-TSZQsQGV-KG9ZkF1PHea6J4PNbTk--j2jXBOHwbvHsOVOw@mail.gmail.com>

https://support.google.com/mail/answer/10313?hl=en

On Sun, Sep 28, 2014 at 8:42 PM, Grant Taylor <gtaylor at tnetconsulting.net>
wrote:

> Hi,
>
> I'm looking for a GMail contact.
>
> My wife is receiving someone else's emails.
>
> Specifically she is receiving emails for <first name><middle initial><last
> name>@gmail.com (no dots) when her email address is really <same first
> name>.<same middle initial>.<same last name>@gmail.com (dots).
>
> I don't know if this is a "feature" or a "bug", but either way, it's
> disquieting my wife.  (Unhappy wife = unhappy life.)
>
> I view this as both non-RFC compliant behavior -and- a potential security
> risk.  (Registering a GMail account as <someone><famous>@gmail.com (no
> dot) to capture email for <someone>.<famous>@gmail.com (dot) emails.)
>
> Please reply or email me directly at gtaylor (at) tnetconsulting (dot) net
> for additional details.
>
> Thank you and have a nice day.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
> P.S.  Thus far messages to postmaster at gmail.com and abuse at gmail.com have
> gone unanswered.
>


From kauer at biplane.com.au  Mon Sep 29 03:57:21 2014
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 29 Sep 2014 13:57:21 +1000
Subject: GMail contact  -  misroute / security issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
Message-ID: <1411963041.8131.166.camel@karl>

On Sun, 2014-09-28 at 22:42 -0500, Grant Taylor wrote:
> I'm looking for a GMail contact.
> My wife is receiving someone else's emails.
> Specifically she is receiving emails for <first name><middle 
> initial><last name>@gmail.com (no dots) when her email address is really 
> <same first name>.<same middle initial>.<same last name>@gmail.com (dots).

http://lmgtfy.com/?q=addresses+with+dots+in+them

Dots in GMail email addresses (before the at symbol of course) are
syntactic sugar. "a.b.c at gmail.com" is the same as "abc at gmail.com".

The sender in your wife's case just has the wrong email address for
his/her desired recipient.

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A




From mike.lyon at gmail.com  Mon Sep 29 03:57:41 2014
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 28 Sep 2014 20:57:41 -0700
Subject: GMail contact - misroute / security issue
In-Reply-To: <CA+E3k91yLQpxua5PM2KECDGtx6vYgQOQbPtHb-gP2PvBjDe0vA@mail.gmail.com>
References: <5428D540.7080904@tnetconsulting.net>
 <CA+E3k91yLQpxua5PM2KECDGtx6vYgQOQbPtHb-gP2PvBjDe0vA@mail.gmail.com>
Message-ID: <CAFFgAjBR5R_cJZ-mwp_wCZ7hgoqgV7rSO0xgRKRi8pk=-70trQ@mail.gmail.com>

I have the same issue and have had it for quite a while. I've met some
great new friends because of it as well!

-Mike

On Sunday, September 28, 2014, Royce Williams <royce at techsolvency.com>
wrote:

> On Sun, Sep 28, 2014 at 7:42 PM, Grant Taylor <gtaylor at tnetconsulting.net
> <javascript:;>>
> wrote:
>
> > My wife is receiving someone else's emails.
> >
> > Specifically she is receiving emails for <first name><middle
> initial><last
> > name>@gmail.com (no dots) when her email address is really <same first
> > name>.<same middle initial>.<same last name>@gmail.com (dots).
>
>
> If someone else thinks that the non-dotted email address is theirs, they
> are mistaken.
>
> This is a Gmail feature.  Adding or removing dots makes no difference,
> other than changing readability.
>
> All versions of the email address are your wife's.
>
> Royce
>


-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon


From gtaylor at tnetconsulting.net  Mon Sep 29 04:02:39 2014
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 28 Sep 2014 23:02:39 -0500
Subject: Match.com contact - Previously: GMail contact - misroute / security
 issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
Message-ID: <5428D9DF.80902@tnetconsulting.net>

On 9/28/14, 10:42 PM, Grant Taylor wrote:
> My wife is receiving someone else's emails.

Okay ... so someone is sending to the incorrect email address that is a 
variant of my wife's GMail address.

The real annoying part is that someone used my wife's email address 
(sans dots) as their email address on Match.com.  So my wife is now 
receiving all the notifications that are meant to go to that other person.

> Specifically she is receiving emails for <first name><middle
> initial><last name>@gmail.com (no dots) when her email address is really
> <same first name>.<same middle initial>.<same last name>@gmail.com (dots).
>
> I don't know if this is a "feature" or a "bug", but either way, it's
> disquieting my wife.  (Unhappy wife = unhappy life.)

*sigh*

So this is a non-RFC compliant ""feature.

*headshake*

Does anyone have any Match.com contacts?  I'll try going that route to 
get the messages stopped.  (Including emailing postmaster@ and abuse@ to 
see if they can help.)

> Please reply or email me directly at gtaylor (at) tnetconsulting (dot)
> net for additional details.
>
> Thank you and have a nice day.



-- 
Grant. . . .
unix || die


From john at op-sec.us  Mon Sep 29 04:15:54 2014
From: john at op-sec.us (John Fraizer)
Date: Mon, 29 Sep 2014 00:15:54 -0400
Subject: Match.com contact - Previously: GMail contact - misroute /
 security issue
In-Reply-To: <5428D9DF.80902@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
 <5428D9DF.80902@tnetconsulting.net>
Message-ID: <CALxrgMFTOBy5M89WHdgdFmLNpierdAn2Wa2P=F5gBJtamNwrGw@mail.gmail.com>

Set up a filter in the GMAIL console to match (pun intended) the "Match"
emails and filter them into their own label.  Then, hide that label.  Don't
delete them though.  You might have a gold mine there.  Think of the
comedic relief you could provide others with "
www.My-wife-keeps-getting-sent-pics-of-some-guys-tiny.org"  You could post
the emails, the profile names of the pervs, etc.  Sort of like a 20/20 "To
catch a..." only instead of predator, it would be perv.

--
John Fraizer
????


From johnl at iecc.com  Sat Sep 27 02:37:24 2014
From: johnl at iecc.com (John Levine)
Date: 27 Sep 2014 02:37:24 -0000
Subject: GMail contact  -  misroute / security issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
Message-ID: <20140927023724.2050.qmail@ary.lan>

>My wife is receiving someone else's emails.

Welcome to the club.

>Specifically she is receiving emails for <first name><middle 
>initial><last name>@gmail.com (no dots) when her email address is really 
><same first name>.<same middle initial>.<same last name>@gmail.com (dots).
>
>I don't know if this is a "feature" or a "bug", but either way, it's 
>disquieting my wife.  (Unhappy wife = unhappy life.)

Google is quite clear that they ignore dots in the mailbox name.

johnqpublic at gmail == john.q.public at gmail == j.o.h.n.q.p.u.b.l.i.c at gmail

>I view this as both non-RFC compliant behavior 

RFC 5321 says that the interpretation of the local-part in the address is
entirely up to the recipient host, so it's hard to imagine how this would
not be RFC compliant.

In practice, you can't fix stupid, so if your wife is feeling charitable,
she can write back and tell people she's not the guy they're looking for,
or else she can just report it all as spam.  If she writes back, be prepared
for people to insist that she must be the person they intended to write to.
My gmail address is my name, and my name is fairly common, so I get all sorts
of mail, including mail from a car dealer in Phoenix who was just sure that I
wanted to buy a car from him even though I live in upstate New York.

R's,
John


From pete at altadena.net  Mon Sep 29 05:32:49 2014
From: pete at altadena.net (Pete Carah)
Date: Mon, 29 Sep 2014 00:32:49 -0500
Subject: update
In-Reply-To: <107190.1411941053@turing-police.cc.vt.edu>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu>
Message-ID: <5428EF01.3050602@altadena.net>

On 09/28/2014 04:50 PM, Valdis.Kletnieks at vt.edu wrote:
> On Sun, 28 Sep 2014 15:06:18 -0600, "Keith Medcalf" said:
>
>>
>> Sorry to disappoint, but those are not changes that make the system more
>> vulnerable.  They are externalities that may change the likelihood of
>> exploitation of an existing vulnerability, but does not create any new
>> vulnerability.  Again, if the new exploit were targeting a vulnerability
>> which was fully mitigated already and thus could not be exploited, there
>> has not even been a change in likelihood of exploit or risk.
> So tell us Keith - since you said earlier that properly designed systems will
> already have 100% mitigations against these attackes _that you don't even know
> about yet_, how exactly did you design these mitigations?  (Fred Fish's thesis
> paper, where he shows that malware detection is equivalent to the Turing Halting
> Problem, is actually relevant here).
>
> In particular, how did you mitigate attacks that are _in the data stream
> that you're charging customers to carry_? (And yes, there *have* been
> fragmentation attacks and the like - and I'm not aware of a formal proof
> that any currently shipping IP stack is totally correct, either, so there
> may still be unidentified attacks).
>
>
For that matter, has the *specification* of tcp/ip been proven to be
"correct" in any complete way?  In particular is it correct in any
useful sense in the face of attackers that are ready and willing to
spoof any possible feature of tcp/ip and its applications?  (e.g. spam
protection involves turning several MUST clauses from 821/822 to MUST
NOT; the specs were not themselves reasonable in the face of determined
attackers.  And unfortunately Postel's famous maxim fails in the face of
determined attackers, or at least the definition of "liberal" has to be
tempered a lot.)

The main serious effects of slammer, for example, were not directly from
the worm itself, but due to the fact that the worm generated random
addresses (at about 30k pps on a 100meg ethernet) without regard to
"address family", and most default router's cpus were overwhelmed
issuing lots of "network unreachable" icmp messages (which I think were
a MUST at the time).  Now that we've run out of spare v4 addresses, we
wouldn't get so many unreachables :-)  Fortunately most of our
vulnerable customers back then were behind T1's so it didn't really hit
us too badly.  The only real workaround at the time was to disable
unreachables, which has other undesirable side effects when the
customers are mostly behaving.  (Unplugging worked best.) (and at least
that worm didn't write anything to disk, so a reboot fixed it for a
while...)

I know that there are features (e.g. fragmentation, source routing, even
host/net unreachable etc etc) in the spec that fall down badly in the
face of purposeful attacks.  And things like the 7007 incident, where
DATA passing between only a few nodes in the larger internet caused a
very large-scale cascading failure.  Jay mentioned another; there were
approximations to 7007 a few times a year for several years after that
incident (one involved routing the whole internet through Sweden). 
Mitigations for things like that are time-varying (e.g. IRR, if enough
people actually used it (and in the face of tcp/ip forgery, that isn't
sufficient either)...), and indeed one has to include the entire
internet (and all of the people running it) as part of the system for
that kind of analysis to mean anything.  And can anyone prove that any
one of the 7007-like incidents were really accidents or not?  For that
matter, maybe they were "normal accidents" (see Perrow - recommended
reading for anyone involved with complex systems which the internet
certainly qualifies (The internet is *much* more complex than the phone
system, and there must be people in NANOG who remember the fallout from
the Hinsdale fire (fast busy, anyone?  Even in Los Angeles...)).  (if
one believes that 7007 was accidental, then it was induced by a
combination of a misfeature in ios (11.x?) (mitigated with some of the
"address-family" features in 12.x, though I don' t know if that was the
intent) and a serious lack of documentation in matters concerning BGP. 
And a lack of error-checking outside that site (though IRR was the only
source of check-data at the time and was (still is?) woefully incomplete.)

The halting problem comes up in connection with _data_ handling in any
computer with even a language interpreter (e.g. is browser-based
javascript complete enough for the halting problem to apply to it?  I
think so.  Java certainly is, though most browser-based java is supposed
to be sandboxed.  Perl, python, ruby, php all are.)  (and in any real
piece of equipment, can any of these make permanent state changes to the
retained memory (flash or disk) in the computer?  If so then this
halting problem equivalence gives us trouble even if no changes are made
to any executable programs (including shared libs) that came with the
computer.)  (especially true if the box is a router with any sort of
dynamic routing, even ARP/NDP)

How, for example, am I to know a priori for all possible <script src=
strings, the difference between a 3rd party download of jquery and a
malicious downloader *before running the download* (for that matter,
even after...)  Whitelisting does not help here in the face of attackers
that spoof protocol features, in this case filenames and/or DNS. 
Noscript and related (e.g. chrome's script protection) whitelist whole
sites, which is nowhere near granular enough, but even then is a pain
for the user to manage.  If the user is the proverbial grandmother, it
is probably impossible to manage.

-- Pete



From larrysheldon at cox.net  Mon Sep 29 06:14:23 2014
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 29 Sep 2014 01:14:23 -0500
Subject: update
In-Reply-To: <wtZj1o0101cZc5601tZm15>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu> <wtZj1o0101cZc5601tZm15>
Message-ID: <5428F8BF.6030602@cox.net>

On 9/29/2014 00:32, Pete Carah wrote:
> For that matter, has the*specification*  of tcp/ip been proven to be
> "correct" in any complete way?

I find that question in this forum really confusing.

I thought all of the RFC-descriptions of protocols were taken to be 
statements that "if you do it this way, we think we can inter-operate" 
but at no time to be taken as "right" or "wrong".
-- 
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


Quis custodiet ipsos custodes


From ggm at algebras.org  Mon Sep 29 06:41:12 2014
From: ggm at algebras.org (George Michaelson)
Date: Mon, 29 Sep 2014 16:41:12 +1000
Subject: update
In-Reply-To: <5428F8BF.6030602@cox.net>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu>
 <5428F8BF.6030602@cox.net>
Message-ID: <CAKr6gn0ikL+MwrJBSYSedD=faPYfQnV4hrfabR0uyh95qoHWew@mail.gmail.com>

for two asynchronous, otherwise unconnected systems, using TCP/IP there is
a state transition sequence which can be shown to work if you stick to it.
There are also (I believe) corner cases when you send unexpected sequences,
and some of them have known behaviours

in that sense, the question: "does the RFC adequately document the state
transition sequences which are understood to be valid states and
transitions" is a well formed question.

Robin Milner, in his calculus of communicating systems tried to codify a
formal mathematics of async communicating systems. I don't know if anyone
either extended the idea(s) or applied it to TCP/IP.

Certainly I believe there are formally verified protocols. Thats a space
Erlang occupies isn't it?

On Mon, Sep 29, 2014 at 4:14 PM, Larry Sheldon <larrysheldon at cox.net> wrote:

> On 9/29/2014 00:32, Pete Carah wrote:
>
>> For that matter, has the*specification*  of tcp/ip been proven to be
>> "correct" in any complete way?
>>
>
> I find that question in this forum really confusing.
>
> I thought all of the RFC-descriptions of protocols were taken to be
> statements that "if you do it this way, we think we can inter-operate" but
> at no time to be taken as "right" or "wrong".
> --
> The unique Characteristics of System Administrators:
>
> The fact that they are infallible; and,
>
> The fact that they learn from their mistakes.
>
>
> Quis custodiet ipsos custodes
>


From list at satchell.net  Mon Sep 29 06:57:33 2014
From: list at satchell.net (Stephen Satchell)
Date: Sun, 28 Sep 2014 23:57:33 -0700
Subject: update
In-Reply-To: <5428F8BF.6030602@cox.net>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu> <wtZj1o0101cZc5601tZm15>
 <5428F8BF.6030602@cox.net>
Message-ID: <542902DD.4010903@satchell.net>

On 09/28/2014 11:14 PM, Larry Sheldon wrote:
> I thought all of the RFC-descriptions of protocols were taken to be
> statements that "if you do it this way, we think we can inter-operate"
> but at no time to be taken as "right" or "wrong".

Correct.  That gave birth to the original "interop" conferences,
informal gatherings of people to test out their implementations of the
RFCs that eventually grew into the full-blown conference we know today.

Frankly, this is where Mr. Stevens was instrumental in making the
Internet what it is today.


From nixon at nsc.liu.se  Mon Sep 29 12:23:29 2014
From: nixon at nsc.liu.se (Leif Nixon)
Date: Mon, 29 Sep 2014 14:23:29 +0200
Subject: Perfsonar and shellshock
Message-ID: <87a95iy5ry.fsf@keb.lan>

Please guys,

If everybody could patch their perfsonar boxen against shellshock LIKE
RIGHT NOW, or preferably LAST WEEK, or alternatively put the machines
out of their misery with a shotgun, that would be great.

Thank you,

-- 
Leif Nixon - Security officer
National Supercomputer Centre - Swedish National Infrastructure for Computing
Nordic Data Grid Facility - European Grid Infrastructure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 172 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140929/20b8358a/attachment.sig>

From list at satchell.net  Mon Sep 29 12:55:22 2014
From: list at satchell.net (Stephen Satchell)
Date: Mon, 29 Sep 2014 05:55:22 -0700
Subject: Perfsonar and shellshock
In-Reply-To: <87a95iy5ry.fsf@keb.lan>
References: <87a95iy5ry.fsf@keb.lan>
Message-ID: <542956BA.4010704@satchell.net>

On 09/29/2014 05:23 AM, Leif Nixon wrote:
> Please guys,
> 
> If everybody could patch their perfsonar boxen against shellshock LIKE
> RIGHT NOW, or preferably LAST WEEK, or alternatively put the machines
> out of their misery with a shotgun, that would be great.
> 
> Thank you,
> 

>From the perfSonar site:

"perfSONAR is recommending that all users run yum update to download the
latest packages from the CentOS repositories"

This will need to be done again in a couple of weeks, when a "better"
patch becomes available from the FSF or wherever.

By the way, the history of the development of bash is mildly
interesting.  http://www.wired.com/2014/09/shellshocked-bash/


From jared at puck.nether.net  Mon Sep 29 14:38:57 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 29 Sep 2014 10:38:57 -0400
Subject: Perfsonar and shellshock
In-Reply-To: <542956BA.4010704@satchell.net>
References: <87a95iy5ry.fsf@keb.lan> <542956BA.4010704@satchell.net>
Message-ID: <B8184F85-CB57-4699-B07F-68AEC8C82216@puck.nether.net>


> On Sep 29, 2014, at 8:55 AM, Stephen Satchell <list at satchell.net> wrote:
> 
> On 09/29/2014 05:23 AM, Leif Nixon wrote:
>> Please guys,
>> 
>> If everybody could patch their perfsonar boxen against shellshock LIKE
>> RIGHT NOW, or preferably LAST WEEK, or alternatively put the machines
>> out of their misery with a shotgun, that would be great.
>> 
>> Thank you,
>> 
> 
>> From the perfSonar site:
> 
> "perfSONAR is recommending that all users run yum update to download the
> latest packages from the CentOS repositories"
> 
> This will need to be done again in a couple of weeks, when a "better"
> patch becomes available from the FSF or wherever.
> 
> By the way, the history of the development of bash is mildly
> interesting.  http://www.wired.com/2014/09/shellshocked-bash/

Proper operation of a host requires automated updating (yum-updatesd, yum-cron) to pick up these packages.

Those who are paranoid or afraid of damage from automatic updates should exclude packages that require specific
versions.

- Jared

From Valdis.Kletnieks at vt.edu  Mon Sep 29 15:57:22 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 29 Sep 2014 11:57:22 -0400
Subject: GMail contact - misroute / security issue
In-Reply-To: Your message of "Sun, 28 Sep 2014 20:57:41 -0700."
 <CAFFgAjBR5R_cJZ-mwp_wCZ7hgoqgV7rSO0xgRKRi8pk=-70trQ@mail.gmail.com>
References: <5428D540.7080904@tnetconsulting.net>
 <CA+E3k91yLQpxua5PM2KECDGtx6vYgQOQbPtHb-gP2PvBjDe0vA@mail.gmail.com>
 <CAFFgAjBR5R_cJZ-mwp_wCZ7hgoqgV7rSO0xgRKRi8pk=-70trQ@mail.gmail.com>
Message-ID: <4318.1412006242@turing-police.cc.vt.edu>

On Sun, 28 Sep 2014 20:57:41 -0700, Mike Lyon said:
> I have the same issue and have had it for quite a while. I've met some
> great new friends because of it as well!

Odd.  Never seen it happen to me.  I wonder why.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140929/c8dd03af/attachment.sig>

From Valdis.Kletnieks at vt.edu  Mon Sep 29 16:09:34 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 29 Sep 2014 12:09:34 -0400
Subject: update
In-Reply-To: Your message of "Mon, 29 Sep 2014 00:32:49 -0500."
 <5428EF01.3050602@altadena.net>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu>
 <5428EF01.3050602@altadena.net>
Message-ID: <5060.1412006974@turing-police.cc.vt.edu>

On Mon, 29 Sep 2014 00:32:49 -0500, Pete Carah said:

> The halting problem comes up in connection with _data_ handling in any
> computer with even a language interpreter (e.g. is browser-based
> javascript complete enough for the halting problem to apply to it?

The halting problem applies to *any* language/system that's Turing-complete.
And the bar is *really* low for that. If you have an increment or decrement
operator, a branch operator, and a test-and-skip-on-zero, you're
Turing-complete.

In fact, you can design a CPU with *one* opcode that's Turing complete. Part
of the fun is that since there's only one opcode, you can omit it, and then
instructions consist only of operand addresses.  Then remember that von Neumann
architectures allow self-modifying code....

http://en.wikipedia.org/wiki/One_instruction_set_computer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140929/391677f6/attachment.sig>

From nicolai-nanog at chocolatine.org  Mon Sep 29 17:06:29 2014
From: nicolai-nanog at chocolatine.org (Nicolai)
Date: Mon, 29 Sep 2014 17:06:29 +0000
Subject: GMail contact  -  misroute / security issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
Message-ID: <20140929170629.GA23632@vectra.student.iastate.edu>

On Sun, Sep 28, 2014 at 10:42:56PM -0500, Grant Taylor wrote:

> Specifically she is receiving emails for <first name><middle initial><last
> name>@gmail.com (no dots) when her email address is really <same first
> name>.<same middle initial>.<same last name>@gmail.com (dots).
> 
> I don't know if this is a "feature" or a "bug", but either way, it's
> disquieting my wife.  (Unhappy wife = unhappy life.)

Have your wife log in while omitting the dots, using e.g. "janeqpublic"
instead of "jane.q.public" as the username.  She'll see there's only
one account, and it's her's, and that someone just typed the wrong
address.

Most likely reason: gmail is so common that someone mistypes
johnsmith at example.com as johnsmith at gmail.com, not paying attention to
what they're doing.  It happens.

Nicolai


From baconzombie at gmail.com  Mon Sep 29 17:19:17 2014
From: baconzombie at gmail.com (Bacon Zombie)
Date: Mon, 29 Sep 2014 19:19:17 +0200
Subject: Match.com contact - Previously: GMail contact - misroute /
 security issue
In-Reply-To: <CALxrgMFTOBy5M89WHdgdFmLNpierdAn2Wa2P=F5gBJtamNwrGw@mail.gmail.com>
References: <5428D540.7080904@tnetconsulting.net>
 <5428D9DF.80902@tnetconsulting.net>
 <CALxrgMFTOBy5M89WHdgdFmLNpierdAn2Wa2P=F5gBJtamNwrGw@mail.gmail.com>
Message-ID: <CAPz7E51BO6Q=7nb1Dos9Z7naqu0Yatt2st-f_w13rO9wCthSAw@mail.gmail.com>

You sure you wife did not sign up or Match.com and using this as a cover
story?
On Sep 29, 2014 6:17 AM, "John Fraizer" <john at op-sec.us> wrote:

> Set up a filter in the GMAIL console to match (pun intended) the "Match"
> emails and filter them into their own label.  Then, hide that label.  Don't
> delete them though.  You might have a gold mine there.  Think of the
> comedic relief you could provide others with "
> www.My-wife-keeps-getting-sent-pics-of-some-guys-tiny.org"  You could post
> the emails, the profile names of the pervs, etc.  Sort of like a 20/20 "To
> catch a..." only instead of predator, it would be perv.
>
> --
> John Fraizer
> ????
>


From disordr at gmail.com  Mon Sep 29 17:34:01 2014
From: disordr at gmail.com (Philip)
Date: Mon, 29 Sep 2014 10:34:01 -0700
Subject: GMail contact - misroute / security issue
In-Reply-To: <20140929170629.GA23632@vectra.student.iastate.edu>
References: <5428D540.7080904@tnetconsulting.net>
 <20140929170629.GA23632@vectra.student.iastate.edu>
Message-ID: <CAMSne7BhJwpTp179GkQrmer9aZ1k_BoyzT4W-Nk_a5WOES4adw@mail.gmail.com>

On Mon, Sep 29, 2014 at 10:06 AM, Nicolai <nicolai-nanog at chocolatine.org>
wrote:

>
> Have your wife log in while omitting the dots, using e.g. "janeqpublic"
> instead of "jane.q.public" as the username.  She'll see there's only
> one account, and it's her's, and that someone just typed the wrong
> address.
>
>
This is what I was going to suggest. Have your wife login to the match.com
site (using the forgot password feature),
and then just deactivate / delete the account.
Or as other have pointed out, gmail filters with hidden labels or direct to
spam also works great.


From merike at doubleshotsecurity.com  Mon Sep 29 18:06:47 2014
From: merike at doubleshotsecurity.com (Merike Kaeo)
Date: Mon, 29 Sep 2014 11:06:47 -0700
Subject: update
In-Reply-To: <CAKr6gn0ikL+MwrJBSYSedD=faPYfQnV4hrfabR0uyh95qoHWew@mail.gmail.com>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu> <5428F8BF.6030602@cox.net>
 <CAKr6gn0ikL+MwrJBSYSedD=faPYfQnV4hrfabR0uyh95qoHWew@mail.gmail.com>
Message-ID: <272753F6-FD06-4B35-BDD7-5634DAD0B806@doubleshotsecurity.com>

Heh?.this reminded me of a project I had to do circa 1991/2 when getting my Master's in EE where we used this book and mechanism to
'validate' TCP.  http://spinroot.com/gerard/popd.html

Although as a student homework assignment I wouldn't say what we did was in any way rigorous but certainly had me learning some interesting
concepts (and as I was actually creating a backbone with routers at the time it was kind of fun to see where academics and operations went a bit
orthogonal) :)  And no, I can't for the life of me remember that far back except to remember that I was the only one in class with practical knowledge.

And then of course there's the 'how did one actually implement the protocols' and hence the Interop conferences as someone already mentioned.
Even a formal proof of 'protocol validation and correctness' doesn't alter the implementation creativities?

- merike


On Sep 28, 2014, at 11:41 PM, George Michaelson <ggm at algebras.org> wrote:

> for two asynchronous, otherwise unconnected systems, using TCP/IP there is
> a state transition sequence which can be shown to work if you stick to it.
> There are also (I believe) corner cases when you send unexpected sequences,
> and some of them have known behaviours
> 
> in that sense, the question: "does the RFC adequately document the state
> transition sequences which are understood to be valid states and
> transitions" is a well formed question.
> 
> Robin Milner, in his calculus of communicating systems tried to codify a
> formal mathematics of async communicating systems. I don't know if anyone
> either extended the idea(s) or applied it to TCP/IP.
> 
> Certainly I believe there are formally verified protocols. Thats a space
> Erlang occupies isn't it?
> 
> On Mon, Sep 29, 2014 at 4:14 PM, Larry Sheldon <larrysheldon at cox.net> wrote:
> 
>> On 9/29/2014 00:32, Pete Carah wrote:
>> 
>>> For that matter, has the*specification*  of tcp/ip been proven to be
>>> "correct" in any complete way?
>>> 
>> 
>> I find that question in this forum really confusing.
>> 
>> I thought all of the RFC-descriptions of protocols were taken to be
>> statements that "if you do it this way, we think we can inter-operate" but
>> at no time to be taken as "right" or "wrong".
>> --
>> The unique Characteristics of System Administrators:
>> 
>> The fact that they are infallible; and,
>> 
>> The fact that they learn from their mistakes.
>> 
>> 
>> Quis custodiet ipsos custodes
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140929/995ee7d6/attachment.sig>

From bzs at world.std.com  Mon Sep 29 18:15:32 2014
From: bzs at world.std.com (Barry Shein)
Date: Mon, 29 Sep 2014 14:15:32 -0400
Subject: update
In-Reply-To: <22337429.3366.1411924977345.JavaMail.root@benjamin.baylink.com>
References: <a3e892e37bd4444a92e7474d09a89051@mail.dessus.com>
 <22337429.3366.1411924977345.JavaMail.root@benjamin.baylink.com>
Message-ID: <21545.41412.920131.364499@world.std.com>


On September 28, 2014 at 13:22 jra at baylink.com (Jay Ashworth) wrote:
 > 
 > "The Internet is the only endeavour of man in which a single-character 
 > typographical error in a file on a computer on the other side of the 
 > planet *which you do not even know exists* can take your entire business
 > off line for the better part of a day."
 > 
 > -- Someone, in the wake of the (I think) Turkish YouTube BGP hijacking;
 >     damn if I remember who.  I might be embellishing.  :-)

Oh I dunno. I know someone who accidentally brought down the entire
Manhattan phone system (monopoly, pre-mobile days) installing a
carefully tested patch with a hot failover running (oh well, the best
laid schemes o' Mice an' Men, Gang aft agley.)

Sure, that was just Manhattan, and of course everyone on the other
side of those connections.


-- 
        -Barry Shein

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


From jwelcher at gmail.com  Mon Sep 29 03:52:47 2014
From: jwelcher at gmail.com (James Welcher)
Date: Sun, 28 Sep 2014 20:52:47 -0700
Subject: GMail contact - misroute / security issue
In-Reply-To: <5428D540.7080904@tnetconsulting.net>
References: <5428D540.7080904@tnetconsulting.net>
Message-ID: <CAPS1T295TW73K4BAhRM=yVxC+grp0+=VuWEO_70oEjw8aMh3jQ@mail.gmail.com>

Gmail will strip out periods. So it's not like there was some OTHER email
address that your wife is suddenly getting. There is only her address. Dots
or No Dots. Your wife's email address IS THE SAME as the dotless-version.

On Sun, Sep 28, 2014 at 8:42 PM, Grant Taylor <gtaylor at tnetconsulting.net>
wrote:

> Hi,
>
> I'm looking for a GMail contact.
>
> My wife is receiving someone else's emails.
>
> Specifically she is receiving emails for <first name><middle initial><last
> name>@gmail.com (no dots) when her email address is really <same first
> name>.<same middle initial>.<same last name>@gmail.com (dots).
>
> I don't know if this is a "feature" or a "bug", but either way, it's
> disquieting my wife.  (Unhappy wife = unhappy life.)
>
> I view this as both non-RFC compliant behavior -and- a potential security
> risk.  (Registering a GMail account as <someone><famous>@gmail.com (no
> dot) to capture email for <someone>.<famous>@gmail.com (dot) emails.)
>
> Please reply or email me directly at gtaylor (at) tnetconsulting (dot) net
> for additional details.
>
> Thank you and have a nice day.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
> P.S.  Thus far messages to postmaster at gmail.com and abuse at gmail.com have
> gone unanswered.
>



-- 
James Welcher


From amitchell at isipp.com  Mon Sep 29 18:48:03 2014
From: amitchell at isipp.com (Anne P. Mitchell, Esq.)
Date: Mon, 29 Sep 2014 12:48:03 -0600
Subject: Match.com contact - Previously: GMail contact - misroute /
 security issue
In-Reply-To: <mailman.1.1411992001.23990.nanog@nanog.org>
References: <mailman.1.1411992001.23990.nanog@nanog.org>
Message-ID: <8080F958-50E4-45A4-B1D8-948140EF45B7@isipp.com>


> Does anyone have any Match.com contacts?  I'll try going that route to 
> get the messages stopped.  (Including emailing postmaster@ and abuse@ to 
> see if they can help.)

I've contacted Grant offlist to provide him with a contact.

Anne

Anne P. Mitchell, Esq.
CEO/President
ISIPP SuretyMail Email Accreditation
Your mail system + SuretyMail accreditation = delivered to their inbox!
http://www.SuretyMail.com/

Author: Section 6 of the Federal CAN-SPAM Act of 2003
Member, California Bar Cyberspace Law Committee
Ret. Professor of Law, Lincoln Law School of San Jose
https://www.linkedin.com/in/annemitchell
303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell 




From Valdis.Kletnieks at vt.edu  Mon Sep 29 19:02:09 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 29 Sep 2014 15:02:09 -0400
Subject: update
In-Reply-To: Your message of "Sun, 28 Sep 2014 13:22:57 -0400."
 <22337429.3366.1411924977345.JavaMail.root@benjamin.baylink.com>
References: <22337429.3366.1411924977345.JavaMail.root@benjamin.baylink.com>
Message-ID: <14767.1412017329@turing-police.cc.vt.edu>

On Sun, 28 Sep 2014 13:22:57 -0400, Jay Ashworth said:
> "The Internet is the only endeavour of man in which a single-character
> typographical error in a file on a computer on the other side of the
> planet *which you do not even know exists* can take your entire business
> off line for the better part of a day."
>
> -- Someone, in the wake of the (I think) Turkish YouTube BGP hijacking;
>     damn if I remember who.  I might be embellishing.  :-)

"A distributed system is one in which the failure of a computer you didn't even
know existed can render your own computer unusable." -- Leslie Lamport, 1987.

http://research.microsoft.com/en-us/um/people/lamport/pubs/distributed-system.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140929/92a8c40e/attachment.sig>

From jra at baylink.com  Mon Sep 29 19:42:36 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 29 Sep 2014 15:42:36 -0400 (EDT)
Subject: Match.com contact - Previously: GMail contact - misroute /
 security issue
In-Reply-To: <5428D9DF.80902@tnetconsulting.net>
Message-ID: <1996241.3518.1412019756808.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Grant Taylor" <gtaylor at tnetconsulting.net>

> *sigh*
> 
> So this is a non-RFC compliant ""feature.

Nope.  The LHS of an email address *is system defined*; no one outside of
the destination mailserver is permitted to make any assumptions about it.

RFC5322 3.4.1:

"""
The local-part portion is a domain-dependent string.  In addresses,
it is simply interpreted on the particular host as a name of a
particular mailbox.
"""

Note that using a "real name" as an email address is Not The Best Idea:

http://www.sendmail.com/sm/open_source/support/support_faq/faq_ver_8_issues/#3.5

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From blair.trosper at gmail.com  Mon Sep 29 21:12:18 2014
From: blair.trosper at gmail.com (Blair Trosper)
Date: Mon, 29 Sep 2014 16:12:18 -0500
Subject: YouTube CDN down?
Message-ID: <CAA5Ek4eTsYG-iwc+kPXgwJo-2L_wu6BWv_B8HVEd=5zRefQGOg@mail.gmail.com>

Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from
multiple ASNs in multiple locations in the United States.  Tried multiple
operating systems and browsers...all have the same issue.

(The very few that do play stall out, even though they're buffered.)

Is this just me, or is there an issue afoot?


From lists.nanog at monmotha.net  Mon Sep 29 21:16:14 2014
From: lists.nanog at monmotha.net (Brandon Martin)
Date: Mon, 29 Sep 2014 17:16:14 -0400
Subject: YouTube CDN down?
In-Reply-To: <CAA5Ek4eTsYG-iwc+kPXgwJo-2L_wu6BWv_B8HVEd=5zRefQGOg@mail.gmail.com>
References: <CAA5Ek4eTsYG-iwc+kPXgwJo-2L_wu6BWv_B8HVEd=5zRefQGOg@mail.gmail.com>
Message-ID: <5429CC1E.7040101@monmotha.net>

On 09/29/2014 05:12 PM, Blair Trosper wrote:
> Suddenly having an inability to play YouTube videos over IPv4 and IPv6 from
> multiple ASNs in multiple locations in the United States.  Tried multiple
> operating systems and browsers...all have the same issue.
>
> (The very few that do play stall out, even though they're buffered.)
>
> Is this just me, or is there an issue afoot?
>

Seems to be working here over a HE.net IPv6 tunnel (Chicago endpoint).

-- 
Brandon Martin


From blair.trosper at gmail.com  Mon Sep 29 21:22:43 2014
From: blair.trosper at gmail.com (Blair Trosper)
Date: Mon, 29 Sep 2014 16:22:43 -0500
Subject: YouTube CDN down?
In-Reply-To: <5429CC1E.7040101@monmotha.net>
References: <CAA5Ek4eTsYG-iwc+kPXgwJo-2L_wu6BWv_B8HVEd=5zRefQGOg@mail.gmail.com>
 <5429CC1E.7040101@monmotha.net>
Message-ID: <CAA5Ek4eTK+=v-djQQN5Pq=jNsxxrs7gbZv0XnMuPcwnd8N5PqA@mail.gmail.com>

Watching in dev tools, the CDN is returning the dreaded HTTP header 204 (No
Content), even though the entire video is buffering.

This reminds me of an outage a while back that only affected IPv6.

I've confirmed with other users, and YouTube is dead to us from these
networks:
- AS22645 (Texas Gigapop) - v4/v6
- AS19108 (Suddenlink) - v4
- AS40285 (Northland Cable) - v4/v6
- AS40244 (TurnKey) - v4/v6

It does seem to be regional.  People in SC/NC who are presumably hitting
the Charleston DC are unaffected.

On Mon, Sep 29, 2014 at 4:16 PM, Brandon Martin <lists.nanog at monmotha.net>
wrote:

> On 09/29/2014 05:12 PM, Blair Trosper wrote:
>
>> Suddenly having an inability to play YouTube videos over IPv4 and IPv6
>> from
>> multiple ASNs in multiple locations in the United States.  Tried multiple
>> operating systems and browsers...all have the same issue.
>>
>> (The very few that do play stall out, even though they're buffered.)
>>
>> Is this just me, or is there an issue afoot?
>>
>>
> Seems to be working here over a HE.net IPv6 tunnel (Chicago endpoint).
>
> --
> Brandon Martin
>


From jlw at jlw.com  Mon Sep 29 23:17:15 2014
From: jlw at jlw.com (Jeff Woolsey)
Date: Mon, 29 Sep 2014 16:17:15 -0700
Subject: GMail contact  -  misroute / security issue
In-Reply-To: <20140929170629.GA23632@vectra.student.iastate.edu>
References: <5428D540.7080904@tnetconsulting.net>
 <20140929170629.GA23632@vectra.student.iastate.edu>
Message-ID: <5429E87B.6040306@jlw.com>

On 09/29/14 10:06, Nicolai wrote:
> Most likely reason: gmail is so common that someone mistypes 
> johnsmith at example.com as johnsmith at gmail.com, not paying attention to 
> what they're doing. It happens.

More likely, I think, is that newbies think that email addresses already 
exist for everyone on the planet at firstlast at gmail.com, and they just 
give that when asked (maybe they think it's throwaway and never actually 
expect to get any email there).  I'm in the same boat.   It doesn't 
bother me all that much because gmail is not my primary mail service.  I 
use it to store big stuff that's clogging the mail service I do pay 
for.  In fact, it can be entertaining, as I get usernames and passwords 
for sites that this guy signed up for.  He's also a poker player and has 
recently tried to enroll at an art college.  The latter I could reply to 
and explain that their prospective student is an idiot and should not be 
accepted, but that's what will happen anyway if I don't say anything.

-- 
Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and unused storage capacity.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
"Card sorting, Joel." -me, re Solitaire



From paigeadele at gmail.com  Mon Sep 29 23:33:04 2014
From: paigeadele at gmail.com (Paige Thompson)
Date: Tue, 30 Sep 2014 02:33:04 +0300
Subject: YouTube CDN down?
In-Reply-To: <CAA5Ek4eTK+=v-djQQN5Pq=jNsxxrs7gbZv0XnMuPcwnd8N5PqA@mail.gmail.com>
References: <CAA5Ek4eTsYG-iwc+kPXgwJo-2L_wu6BWv_B8HVEd=5zRefQGOg@mail.gmail.com>
 <5429CC1E.7040101@monmotha.net>
 <CAA5Ek4eTK+=v-djQQN5Pq=jNsxxrs7gbZv0XnMuPcwnd8N5PqA@mail.gmail.com>
Message-ID: <5429EC30.5040803@gmail.com>

yt is working for me:

2607:f2f8:a2c4:/48 / 206.125.168.64/28

On 09/30/14 00:22, Blair Trosper wrote:
> Watching in dev tools, the CDN is returning the dreaded HTTP header 204 (No
> Content), even though the entire video is buffering.
>
> This reminds me of an outage a while back that only affected IPv6.
>
> I've confirmed with other users, and YouTube is dead to us from these
> networks:
> - AS22645 (Texas Gigapop) - v4/v6
> - AS19108 (Suddenlink) - v4
> - AS40285 (Northland Cable) - v4/v6
> - AS40244 (TurnKey) - v4/v6
>
> It does seem to be regional.  People in SC/NC who are presumably hitting
> the Charleston DC are unaffected.
>
> On Mon, Sep 29, 2014 at 4:16 PM, Brandon Martin <lists.nanog at monmotha.net>
> wrote:
>
>> On 09/29/2014 05:12 PM, Blair Trosper wrote:
>>
>>> Suddenly having an inability to play YouTube videos over IPv4 and IPv6
>>> from
>>> multiple ASNs in multiple locations in the United States.  Tried multiple
>>> operating systems and browsers...all have the same issue.
>>>
>>> (The very few that do play stall out, even though they're buffered.)
>>>
>>> Is this just me, or is there an issue afoot?
>>>
>>>
>> Seems to be working here over a HE.net IPv6 tunnel (Chicago endpoint).
>>
>> --
>> Brandon Martin
>>



From paigeadele at gmail.com  Tue Sep 30 02:30:09 2014
From: paigeadele at gmail.com (Paige Thompson)
Date: Tue, 30 Sep 2014 05:30:09 +0300
Subject: Internet in Venezuela
Message-ID: <542A15B1.6010507@gmail.com>

I have lots of questions, feel free to contact me privately if you have
some time or interest in answering
some of them.

-Paige

paigeadele at gmail.com
PGP: 0x0d5d2688 (keys.gnupg.net), also attached.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0d5d2688.pub.asc
Type: application/pgp-encrypted
Size: 3112 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140930/f703d889/attachment.pgp>

From pete at altadena.net  Tue Sep 30 03:10:45 2014
From: pete at altadena.net (Pete Carah)
Date: Mon, 29 Sep 2014 22:10:45 -0500
Subject: update
In-Reply-To: <5428F8BF.6030602@cox.net>
References: <4f19b7f0d08345408906cb4bc7cbc736@mail.dessus.com>
 <107190.1411941053@turing-police.cc.vt.edu> <wtZj1o0101cZc5601tZm15>
 <5428F8BF.6030602@cox.net>
Message-ID: <542A1F35.1040305@altadena.net>

On 09/29/2014 01:14 AM, Larry Sheldon wrote:
> On 9/29/2014 00:32, Pete Carah wrote:
>> For that matter, has the*specification*  of tcp/ip been proven to be
>> "correct" in any complete way?
>
> I find that question in this forum really confusing.
I was adding it to Valdis's statement about proven correctness of the
TCP/IP stack.  It is only possible to prove correctness of software in
relation to a (assumed) correct (and complete) specification.  Correct
software relative to a spec that doesn't relate to the real world may be
considered correct but will still fail in application.  Many of the
famous failures of military systems (and many more from commercial
systems) come from bad (or missing) assumptions in the spec, (and many
also from bad implementation, to be sure...)

The thread in question is more about security than interoperation, and
real-world effects of both compliant and non-compliant uses of the net. 
The real point is that many of the features included in tcp/ip to handle
random occurrences make purposeful interference *worse*.  In a world
with purposeful attacks, those specifications have to be amended; in
that sense they are not "correct".

>
> I thought all of the RFC-descriptions of protocols were taken to be
> statements that "if you do it this way, we think we can inter-operate"
> but at no time to be taken as "right" or "wrong".

The use of modals (MUST, MUST NOT, SHOULD) in the specification implies
a sense of correctness.

Indeed that is mostly there to guarantee interoperation.  In the early
days (pre-mid-80's) the security aspects of the protocols was minimal;
it was assumed that people would pay attention to the specs.  Now we
have players that (use spam for an example, again) (mostly) completely
comply to the technical specifications but manage to bring the net to
its knees anyhow, and also players that test what (mostly) minor
violations to the spec will do to the rest of the net.  (try to defend
against a joe-job using stock qmail, for example; that system is
completely compliant to the (older) RFCs and cannot handle significant
amounts of forged mail, mostly due to its completely compliant handling
of bounces.

And some of the MUST statements in earlier application protocols
(821/822, for example) have had to be turned off in order to defend
against such purposeful actions (e.g. bounce all messages that fail
delivery; doing so makes the spam problem MUCH worse.)  The protocols
have to be adapted to handle attacks, there is no alternative.  In that
way, there is (in some sense) correctness or not.  At least the RFC
system does allow for fairly easy (but not too easy) modification with
experience.

-- Pete



From fernando at gont.com.ar  Tue Sep 30 04:54:07 2014
From: fernando at gont.com.ar (Fernando Gont)
Date: Tue, 30 Sep 2014 01:54:07 -0300
Subject: IPv6 Extension Headers in the Real World
Message-ID: <542A376F.704@gont.com.ar>

Folks,

Earlier in September we published a revision of our I-D "IPv6 Extension
Headers in the Real World"
(<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world>).

At this point in time, we're interested in knowing whether our I-D is of
value for the IPv6 ops community, such that we can decide whether to
continue working/improving it. Additionally, if there's anything you
think we've missed in the document, we'd like to hear from you.

Overall, our I-D is meant to provide a reality-check with respect to the
issues surrounding IPv6 Extension Headers and their use on the public
Internet. More specifically, its goals are:

1) Provide data regarding support of IPv6 EHs in the real world.

    This is interesting data to refer people to (e.g., folks
    developing protocols) regarding the extent to which IPv6 EHs
    are usable on the public Internet (at least with web, mail, and
    name servers).


2) Summarize the issues associated with IPv6 EHs (performance, security,
etc.)

    This is of use for folks concerned with the issues surrounding
    IPv6 EHs, and covers practical issues.


3) Summarizes the implications of the aforementioned filtering.

    For example, if you're designing a protocol that is meant to
    work on the public Internet, you may want to provide some fall-back
    mechanism that does not employ IPv6 EHs.

    Yet another of the implications is the security issue that has
    been discussed on-list: if e.g. IPv6 fragments are dropped and you
    can be tricked into generating them, you may be subject to a DoS
    attack.


4) Flag possible further work

   Here we try to flag areas where the further work may be needed,
   such as adding fall-back mechanisms to some existing protocols,
   or avoiding the use of IPv6 EHs where possible.


Thanks!

Best regards,
-- 
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 a.harrowell at gmail.com  Tue Sep 30 16:29:45 2014
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Tue, 30 Sep 2014 17:29:45 +0100
Subject: GMail contact - misroute / security issue
In-Reply-To: <5429E87B.6040306@jlw.com>
References: <5428D540.7080904@tnetconsulting.net>
 <20140929170629.GA23632@vectra.student.iastate.edu>
 <5429E87B.6040306@jlw.com>
Message-ID: <CA+qGm=84SxQfSjhp66=J3BOUf9VTi71dBE=WYhS=GDKVRQcrrQ@mail.gmail.com>

Related oddness: if you're British and a GMail user, you either got a
gmail.com username before the lawsuit, or you got a googlemail.com
between the lawsuit and the point when Google and the owner of the
"gmail" trademark settled, or then you got a gmail.com again.

Google chose to alias googlemail.com and gmail.com addresses so as to
minimise the mess, but this doesn't stop people who have
googlemail.com entering gmail.com (or vice versa) when they set up an
account on www.somewebsi.te, because they are conditioned to use
gmail.com/googlemail.com interchangeably, and then being baffled as to
why firstname.lastname at googlemail.com (or vice versa)/password1234
doesn't work, because googlemail==gmail and anyway my address is
really firstname.lastname at gmail.com (or googlemail) - look, I get
email on it, it must be the right one :-)



On Tue, Sep 30, 2014 at 12:17 AM, Jeff Woolsey <jlw at jlw.com> wrote:
> On 09/29/14 10:06, Nicolai wrote:
>>
>> Most likely reason: gmail is so common that someone mistypes
>> johnsmith at example.com as johnsmith at gmail.com, not paying attention to what
>> they're doing. It happens.
>
>
> More likely, I think, is that newbies think that email addresses already
> exist for everyone on the planet at firstlast at gmail.com, and they just give
> that when asked (maybe they think it's throwaway and never actually expect
> to get any email there).  I'm in the same boat.   It doesn't bother me all
> that much because gmail is not my primary mail service.  I use it to store
> big stuff that's clogging the mail service I do pay for.  In fact, it can be
> entertaining, as I get usernames and passwords for sites that this guy
> signed up for.  He's also a poker player and has recently tried to enroll at
> an art college.  The latter I could reply to and explain that their
> prospective student is an idiot and should not be accepted, but that's what
> will happen anyway if I don't say anything.
>
> --
> Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
> Spum bad keming.
> Nature abhors a straight antenna, a clean lens, and unused storage capacity.
> "Delete! Delete! OK!" -Dr. Bronner on disk space management
> "Card sorting, Joel." -me, re Solitaire
>


From baconzombie at gmail.com  Tue Sep 30 17:20:56 2014
From: baconzombie at gmail.com (Bacon Zombie)
Date: Tue, 30 Sep 2014 19:20:56 +0200
Subject: GMail contact - misroute / security issue
In-Reply-To: <CA+qGm=84SxQfSjhp66=J3BOUf9VTi71dBE=WYhS=GDKVRQcrrQ@mail.gmail.com>
References: <5428D540.7080904@tnetconsulting.net>
 <20140929170629.GA23632@vectra.student.iastate.edu>
 <5429E87B.6040306@jlw.com>
 <CA+qGm=84SxQfSjhp66=J3BOUf9VTi71dBE=WYhS=GDKVRQcrrQ@mail.gmail.com>
Message-ID: <CAPz7E50-v3KgRKj8TpPWbb5_npoW1Ez1Y=UTKz53b_Cq0jUUNw@mail.gmail.com>

This probably also effected German users.
On Sep 30, 2014 6:32 PM, "Alexander Harrowell" <a.harrowell at gmail.com>
wrote:

> Related oddness: if you're British and a GMail user, you either got a
> gmail.com username before the lawsuit, or you got a googlemail.com
> between the lawsuit and the point when Google and the owner of the
> "gmail" trademark settled, or then you got a gmail.com again.
>
> Google chose to alias googlemail.com and gmail.com addresses so as to
> minimise the mess, but this doesn't stop people who have
> googlemail.com entering gmail.com (or vice versa) when they set up an
> account on www.somewebsi.te, because they are conditioned to use
> gmail.com/googlemail.com interchangeably, and then being baffled as to
> why firstname.lastname at googlemail.com (or vice versa)/password1234
> doesn't work, because googlemail==gmail and anyway my address is
> really firstname.lastname at gmail.com (or googlemail) - look, I get
> email on it, it must be the right one :-)
>
>
>
> On Tue, Sep 30, 2014 at 12:17 AM, Jeff Woolsey <jlw at jlw.com> wrote:
> > On 09/29/14 10:06, Nicolai wrote:
> >>
> >> Most likely reason: gmail is so common that someone mistypes
> >> johnsmith at example.com as johnsmith at gmail.com, not paying attention to
> what
> >> they're doing. It happens.
> >
> >
> > More likely, I think, is that newbies think that email addresses already
> > exist for everyone on the planet at firstlast at gmail.com, and they just
> give
> > that when asked (maybe they think it's throwaway and never actually
> expect
> > to get any email there).  I'm in the same boat.   It doesn't bother me
> all
> > that much because gmail is not my primary mail service.  I use it to
> store
> > big stuff that's clogging the mail service I do pay for.  In fact, it
> can be
> > entertaining, as I get usernames and passwords for sites that this guy
> > signed up for.  He's also a poker player and has recently tried to
> enroll at
> > an art college.  The latter I could reply to and explain that their
> > prospective student is an idiot and should not be accepted, but that's
> what
> > will happen anyway if I don't say anything.
> >
> > --
> > Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
> > Spum bad keming.
> > Nature abhors a straight antenna, a clean lens, and unused storage
> capacity.
> > "Delete! Delete! OK!" -Dr. Bronner on disk space management
> > "Card sorting, Joel." -me, re Solitaire
> >
>


From bmeshier at amherst.com  Tue Sep 30 21:42:53 2014
From: bmeshier at amherst.com (Meshier, Brent)
Date: Tue, 30 Sep 2014 21:42:53 +0000
Subject: MetroE Providers
Message-ID: <68C2CBC977F3E04799DF9C76E938E7090859F94D@DFEXCH1.asglp.com>

Are there any sites or services that can list local network providers by zip code or address?  We're constantly opening up regional offices across the US and need to streamline the process of obtaining connectivity.

--Brent
--- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication.