From awal_ece at yahoo.com  Tue Dec  1 05:38:23 2015
From: awal_ece at yahoo.com (ABDUL AWAL)
Date: Tue, 1 Dec 2015 05:38:23 +0000 (UTC)
Subject: OT: BdNOG announces website blocks
In-Reply-To: <CAM9VJk3RK3rqsUdOYStYy3SdUkBFW4rVHEg3mNOzOnhnLsBgEQ@mail.gmail.com>
References: <CAM9VJk3RK3rqsUdOYStYy3SdUkBFW4rVHEg3mNOzOnhnLsBgEQ@mail.gmail.com>
Message-ID: <1704320804.13112765.1448948304006.JavaMail.yahoo@mail.yahoo.com>

Some new article on this topic...

http://bdnews24.com/bangladesh/2015/12/01/minister-tarana-writes-to-facebook-proposing-discussion
http://bdnews24.com/bangladesh/2015/11/29/proxy-servers-to-access-facebook-will-soon-be-unavailable-state-minister-tarana

BR//Awal

 


    On Monday, November 30, 2015 12:14 AM, Joly MacFie <joly at punkcast.com> wrote:
 

 Seems like there's some hardball going on

http://www.thedailystar.net/country/cyber-crimes-govt-write-facebook-deal-179314



On Wed, Nov 18, 2015 at 3:22 PM, Scott Weeks <surfer at mauigateway.com> wrote:
> >
> > ---------------------------------------------
> > Md. abdullah Al naser mail.naserbd at yahoo.com
> > Wed Nov 18 12:56:15 BDT 2015
> >
> > The service of Facebook, Viber and Whatsapp are
> > blocked from now till further notice. It has been
> > ordered by Begum Tarana Halim, State Minister, Post
> > and Telecommunications.
> > ----------------------------------------------
>

-- 
---------------------------------------------------------------
Joly MacFie? 218 565 9365 Skype:punkcast
--------------------------------------------------------------
-


  

From m4rtntns at gmail.com  Tue Dec  1 16:59:31 2015
From: m4rtntns at gmail.com (Martin T)
Date: Tue, 1 Dec 2015 18:59:31 +0200
Subject: strategies to mitigate DNS amplification attacks in ISP network
Message-ID: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>

Hi,

as around 40% of ASNs allow at least partial IPv4 address spoofing in
their network(http://spoofer.csail.mit.edu/summary.php) and there are
around 30 million open-resolvers(http://openresolverproject.org/) in
the Internet, then DNS amplification traffic is daily occasion for
ISPs. This in probably mainly because RPF checks and DNS
RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html)
are not ubiquitously implemented, recursive requests without any ACLs
in DNS servers are often allowed, it requires little effort from
attackers point of view and is effective attack method. Unfortunately,
there seems to be very limited number of countermeasures for ISPs. Few
which I can think of:

1) higher capacity backbone links - I'm not sure if this can be
considered a mitigation method, but at least it can help to affect
smaller amount of customers if traffic volumes are not very high


2) rate-limit incoming DNS traffic flows on peering and uplink ports -
here I mean something similar to iptables "recent"
module(http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16)
which allows certain number of certain type of packets in a configured
time-slot per IP. However, such functionality is probably not common
on edge or backbone routers.


Tracking the packet state does definitely not work because state table
should be synchronized between all the routers in the network and
again, this requires Internet-routers to have stateful firewall
functionality. In addition, one also needs to allow new DNS
connections from Internet to its network.
If one simply polices incoming DNS traffic on uplink and peering
ports(for example if baseline DNS traffic is 5Mbps, then policer is
set to 50Mbps), then legitimate customers DNS traffic is also affected
in case of actual attack occurs and policer starts to drop DNS
traffic, i.e. policer has no way to distinguish between the legitimate
and non-legitimate incoming DNS traffic.


Am I wrong in some points? What are the common practices to mitigate
DNS amplification attacks in ISP network?


thanks,
Martin

From rdobbins at arbor.net  Tue Dec  1 17:14:21 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 02 Dec 2015 00:14:21 +0700
Subject: strategies to mitigate DNS amplification attacks in ISP network
In-Reply-To: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
Message-ID: <F53AB4B1-8131-4013-963D-54838A90B18C@arbor.net>

On 1 Dec 2015, at 23:59, Martin T wrote:

> What are the common practices to mitigate
> DNS amplification attacks in ISP network?

Situationally-appropriate network access policies instantiated as ACLs 
on hardware-based routers/layer-3 switches in IDCs, on customer 
aggregation routers, in mitigation centers, etc.

S/RTBH.

flowspec.

IDMS (full disclosure, I work for a vendor of such systems).

See this .pdf preso:

<https://app.box.com/s/r7an1moswtc7ce58f8gg>

Statefulness is out, as you indicate.

QoS is out, as you indicated (e.g., legitimate traffic is 'crowded out' 
by programmatically-generated attack traffic).

The real solution to this entire problem set is source-address 
validation, as you indicate.  Until the happy day when we've achieved 
universal source-address validation arrives, various combinations of the 
above.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Tue Dec  1 17:15:16 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 02 Dec 2015 00:15:16 +0700
Subject: strategies to mitigate DNS amplification attacks in ISP network
In-Reply-To: <F53AB4B1-8131-4013-963D-54838A90B18C@arbor.net>
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
 <F53AB4B1-8131-4013-963D-54838A90B18C@arbor.net>
Message-ID: <7C7E6FAA-5D27-46E2-9713-272FF5956CCB@arbor.net>

On 2 Dec 2015, at 0:14, Roland Dobbins wrote:

> Until the happy day when we've achieved universal source-address 
> validation arrives, various combinations of the above.

I forgot to mention RRL on authoritative servers, apologies.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From bill at herrin.us  Tue Dec  1 18:35:16 2015
From: bill at herrin.us (William Herrin)
Date: Tue, 1 Dec 2015 13:35:16 -0500
Subject: strategies to mitigate DNS amplification attacks in ISP network
In-Reply-To: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
Message-ID: <CAP-guGUwg1OVr3Afx4cg75nfj1mOH6aEC1+QKTUhTskwe4T6yQ@mail.gmail.com>

On Tue, Dec 1, 2015 at 11:59 AM, Martin T <m4rtntns at gmail.com> wrote:
> Am I wrong in some points? What are the common practices to mitigate
> DNS amplification attacks in ISP network?

Hi Martin,

You seem to be focused on DNS amplification from the perspective of
the attack's target. To the target, it's just another DDOS attack. As
with other DDOS attacks, you reroute the contained /24 to a DDOS
mitigator who specializes in removing unwanted packets from the data
stream and passing the rest to your network via a tunnel. The
mitigator writes custom software on expensive server arrays which
figure out the attack de jour signatures and scrub the packet flows.

Some folks rate-limit UDP flows. This just kills everything sooner
during an attack since you kinda need DNS to work.

Rate limiting by source turns your DNS requests stateful... a happy
fun way to shoot yourself in the foot.

Really, your best bet is to treat it as just another DDOS and let the
guy you pay for DDOS service handle the details.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From surfer at mauigateway.com  Tue Dec  1 18:36:28 2015
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 1 Dec 2015 10:36:28 -0800
Subject: OT: BdNOG announces website blocks
Message-ID: <20151201103628.598D935C@m0087796.ppops.net>


--- nanog at nanog.org wrote:
From: ABDUL AWAL via NANOG <nanog at nanog.org>

http://bdnews24.com/bangladesh/2015/11/29/proxy-servers-to-access-facebook-will-soon-be-unavailable-state-minister-tarana
---------------------------------


Hahaha, gov't official - meet reality.


"State Minister for Posts and Telecommunications Tarana 
Halim says proxy servers being used..."

""I think Facebook can't be closed unless the internet 
is shut down. We don't want to do that. We won't shut 
down the internet," said Tarana Halim."

"We are only catching only those that need to be caught, 
not everyone."

"I ask you (journalists) to find out whether it's possible 
or not. I hope you will find the answer. Closing down 
Facebook 100 percent is not possible in any country in the 
world"

Or any other app a gov't wants to keep from its citizenry
so their communications with others can be controlled.



"Those who are using them are using a bandwidth with 
a specific capacity. They won't be able to do that 
much longer. Because this bandwidth's capacity is low."

"The second bandwidth's speed is far lower than normal. 
Saboteurs can't communicate and organise attacks fast 
enough using that bandwidth. It's very easy to track 
(anyone's internet activity) if the speed is low.""


wtf does that even mean?


scott


From niels=nanog at bakker.net  Tue Dec  1 19:19:00 2015
From: niels=nanog at bakker.net (Niels Bakker)
Date: Tue, 1 Dec 2015 20:19:00 +0100
Subject: OT: BdNOG announces website blocks
In-Reply-To: <20151201103628.598D935C@m0087796.ppops.net>
References: <1704320804.13112765.1448948304006.JavaMail.yahoo@mail.yahoo.com>
 <20151201103628.598D935C@m0087796.ppops.net>
Message-ID: <20151201191900.GJ3097@excession.tpb.net>

* surfer at mauigateway.com (Scott Weeks) [Tue 01 Dec 2015, 19:40 CET]:
>"Those who are using them are using a bandwidth with
>a specific capacity. They won't be able to do that
>much longer. Because this bandwidth's capacity is low."
>
>"The second bandwidth's speed is far lower than normal.
>Saboteurs can't communicate and organise attacks fast
>enough using that bandwidth. It's very easy to track
>(anyone's internet activity) if the speed is low.""
>
>
>wtf does that even mean?

Using a VPN means all your content will be served from its endpoint 
and has to be trucked across country borders, possibly from another 
continent, rather than being served over local peering, which would 
likely have had better throughput.


	-- Niels.

From jra at baylink.com  Tue Dec  1 19:21:00 2015
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 1 Dec 2015 19:21:00 +0000 (UTC)
Subject: RFC 6335 DNS SRV registrations
Message-ID: <1526951823.11820.1448997660576.JavaMail.zimbra@baylink.com>

If you've done one, please ping me off-list?  Got a few clarifications that
the RFC doesn't go deep enough in the right places for.

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 fhr at fhrnet.eu  Tue Dec  1 19:22:27 2015
From: fhr at fhrnet.eu (Filip Hruska)
Date: Tue, 1 Dec 2015 20:22:27 +0100
Subject: OT: BdNOG announces website blocks
In-Reply-To: <20151201103628.598D935C@m0087796.ppops.net>
References: <20151201103628.598D935C@m0087796.ppops.net>
Message-ID: <565DF373.80602@fhrnet.eu>

I think that means they'd like to use deep packet inspection equipment 
for the whole country. But they don't have the budget for equipment with 
such capabilities so they want to limit bandwidth usage by cutting off 
access to some popular services.

Maybe I got it all wrong; That article is very confusing.

On 12/01/2015 07:36 PM, Scott Weeks wrote:
>
> --- nanog at nanog.org wrote:
> From: ABDUL AWAL via NANOG <nanog at nanog.org>
>
> http://bdnews24.com/bangladesh/2015/11/29/proxy-servers-to-access-facebook-will-soon-be-unavailable-state-minister-tarana
> ---------------------------------
>
>
> Hahaha, gov't official - meet reality.
>
>
> "State Minister for Posts and Telecommunications Tarana
> Halim says proxy servers being used..."
>
> ""I think Facebook can't be closed unless the internet
> is shut down. We don't want to do that. We won't shut
> down the internet," said Tarana Halim."
>
> "We are only catching only those that need to be caught,
> not everyone."
>
> "I ask you (journalists) to find out whether it's possible
> or not. I hope you will find the answer. Closing down
> Facebook 100 percent is not possible in any country in the
> world"
>
> Or any other app a gov't wants to keep from its citizenry
> so their communications with others can be controlled.
>
>
>
> "Those who are using them are using a bandwidth with
> a specific capacity. They won't be able to do that
> much longer. Because this bandwidth's capacity is low."
>
> "The second bandwidth's speed is far lower than normal.
> Saboteurs can't communicate and organise attacks fast
> enough using that bandwidth. It's very easy to track
> (anyone's internet activity) if the speed is low.""
>
>
> wtf does that even mean?
>
>
> scott
>

From maxtul at netassist.ua  Tue Dec  1 19:23:08 2015
From: maxtul at netassist.ua (Max Tulyev)
Date: Tue, 01 Dec 2015 21:23:08 +0200
Subject: IPv6 Cogent vs Hurricane Electric
Message-ID: <565DF39C.9060503@netassist.ua>

Hi All,

we got an issue today that announces from Cogent don't reach Hurricane
Electric. HE support said that's a feature, not a bug.

So we have splitted Internet again?

I have to change at least one of my uplinks because of it, which one is
better to drop, HE or Cogent?

From michael.hare at wisc.edu  Tue Dec  1 17:23:01 2015
From: michael.hare at wisc.edu (Michael Hare)
Date: Tue, 01 Dec 2015 17:23:01 +0000
Subject: strategies to mitigate DNS amplification attacks in ISP network
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
Message-ID: <DM3PR0601MB2011982419777A0C7960842FF90F0@DM3PR0601MB2011.namprd06.prod.outlook.com>

Martin-

I represent a statewide educational network running Juniper gear that is a quasi-enterprise.  I think efforts depend on size and type of network.  We are testing an approach that involves;

1) whitelisting known local resolvers, well behaved cloud DNS resolvers. 
2) on ingress, policing non-conforming traffic that matches UDP src port 53 dst port unreserved bytes > 1400
3) on ingress, queuing fragments to high packet loss priority [you better understand how fragments are used in your network before doing this]
4) If you have Juniper gear look into prefix-action
5) RTBH if required

This obviously doesn't work on the core of the internet.

Other good tips: 
* strengthen [anycast] your local DNS resolvers and consider a scheme that allows you to change their outgoing address on the fly.
* push [some] of your external authoritative DNS to the cloud.

-Michael

> > -----Original Message-----
> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin T
> > Sent: Tuesday, December 01, 2015 11:00 AM
> > To: nanog at nanog.org
> > Subject: strategies to mitigate DNS amplification attacks in ISP network
> >
> > Hi,
> >
> > as around 40% of ASNs allow at least partial IPv4 address spoofing in
> > their network(http://spoofer.csail.mit.edu/summary.php) and there are
> > around 30 million open-resolvers(http://openresolverproject.org/) in
> > the Internet, then DNS amplification traffic is daily occasion for
> > ISPs. This in probably mainly because RPF checks and DNS
> > RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-
> > Rate-Limiting.html)
> > are not ubiquitously implemented, recursive requests without any ACLs
> > in DNS servers are often allowed, it requires little effort from
> > attackers point of view and is effective attack method. Unfortunately,
> > there seems to be very limited number of countermeasures for ISPs. Few
> > which I can think of:
> >
> > 1) higher capacity backbone links - I'm not sure if this can be
> > considered a mitigation method, but at least it can help to affect
> > smaller amount of customers if traffic volumes are not very high
> >
> >
> > 2) rate-limit incoming DNS traffic flows on peering and uplink ports -
> > here I mean something similar to iptables "recent"
> > module(http://www.netfilter.org/documentation/HOWTO/netfilter-
> extensions-
> > HOWTO-3.html#ss3.16)
> > which allows certain number of certain type of packets in a configured
> > time-slot per IP. However, such functionality is probably not common
> > on edge or backbone routers.
> >
> >
> > Tracking the packet state does definitely not work because state table
> > should be synchronized between all the routers in the network and
> > again, this requires Internet-routers to have stateful firewall
> > functionality. In addition, one also needs to allow new DNS
> > connections from Internet to its network.
> > If one simply polices incoming DNS traffic on uplink and peering
> > ports(for example if baseline DNS traffic is 5Mbps, then policer is
> > set to 50Mbps), then legitimate customers DNS traffic is also affected
> > in case of actual attack occurs and policer starts to drop DNS
> > traffic, i.e. policer has no way to distinguish between the legitimate
> > and non-legitimate incoming DNS traffic.
> >
> >
> > Am I wrong in some points? What are the common practices to mitigate
> > DNS amplification attacks in ISP network?
> >
> >
> > thanks,
> > Martin

From morrowc.lists at gmail.com  Tue Dec  1 19:33:44 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 1 Dec 2015 14:33:44 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <565DF39C.9060503@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
Message-ID: <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>

hasn't this been the case for ~10 yrs now?

On Tue, Dec 1, 2015 at 2:23 PM, Max Tulyev <maxtul at netassist.ua> wrote:
> Hi All,
>
> we got an issue today that announces from Cogent don't reach Hurricane
> Electric. HE support said that's a feature, not a bug.
>
> So we have splitted Internet again?
>
> I have to change at least one of my uplinks because of it, which one is
> better to drop, HE or Cogent?

From maxtul at netassist.ua  Tue Dec  1 19:36:01 2015
From: maxtul at netassist.ua (Max Tulyev)
Date: Tue, 01 Dec 2015 21:36:01 +0200
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
Message-ID: <565DF6A1.4050507@netassist.ua>

Just hit it for first time...

Is there any other similar splits in IPv6 world?

On 01.12.15 21:33, Christopher Morrow wrote:
> hasn't this been the case for ~10 yrs now?
> 
> On Tue, Dec 1, 2015 at 2:23 PM, Max Tulyev <maxtul at netassist.ua> wrote:
>> Hi All,
>>
>> we got an issue today that announces from Cogent don't reach Hurricane
>> Electric. HE support said that's a feature, not a bug.
>>
>> So we have splitted Internet again?
>>
>> I have to change at least one of my uplinks because of it, which one is
>> better to drop, HE or Cogent?
> 


From job at instituut.net  Tue Dec  1 19:37:09 2015
From: job at instituut.net (Job Snijders)
Date: Tue, 1 Dec 2015 20:37:09 +0100
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <565DF39C.9060503@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
Message-ID: <20151201193709.GP55095@22.rev.meerval.net>

On Tue, Dec 01, 2015 at 09:23:08PM +0200, Max Tulyev wrote:
> we got an issue today that announces from Cogent don't reach Hurricane
> Electric. HE support said that's a feature, not a bug.
> 
> So we have splitted Internet again?

Was there ever an adjacency between 6939 and 174 in the IPv6 DFZ?
Maybe bgpmon or dyn can comment on information collected over the last
few years. 

> I have to change at least one of my uplinks because of it, which one
> is better to drop, HE or Cogent?

I recommend You base your decision on metrics relevant to your business,
such as network performance, positive/negative experiences with their
NOC, support from your account manager, pricing, how easy it was to
reach them (local tail needed or not), etc.

Kind regards,

Job

From trelane at trelane.net  Tue Dec  1 19:39:14 2015
From: trelane at trelane.net (Andrew Kirch)
Date: Tue, 1 Dec 2015 14:39:14 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
Message-ID: <CALA5tJJ=fWGBRisd8=myYjHFx7=rtfUaWGLE1r9RmaDLjobBYw@mail.gmail.com>

Might I suggest cake pleas?

On Tuesday, December 1, 2015, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> hasn't this been the case for ~10 yrs now?
>
> On Tue, Dec 1, 2015 at 2:23 PM, Max Tulyev <maxtul at netassist.ua
> <javascript:;>> wrote:
> > Hi All,
> >
> > we got an issue today that announces from Cogent don't reach Hurricane
> > Electric. HE support said that's a feature, not a bug.
> >
> > So we have splitted Internet again?
> >
> > I have to change at least one of my uplinks because of it, which one is
> > better to drop, HE or Cogent?
>

From alarig at swordarmor.fr  Tue Dec  1 20:01:40 2015
From: alarig at swordarmor.fr (Alarig Le Lay)
Date: Tue, 1 Dec 2015 21:01:40 +0100
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CALA5tJJ=fWGBRisd8=myYjHFx7=rtfUaWGLE1r9RmaDLjobBYw@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
 <CALA5tJJ=fWGBRisd8=myYjHFx7=rtfUaWGLE1r9RmaDLjobBYw@mail.gmail.com>
Message-ID: <20151201200140.GA22343@drscott.swordarmor.fr>

On Tue Dec  1 14:39:14 2015, Andrew Kirch wrote:
> Might I suggest cake pleas?

You mean
http://www.datacenterknowledge.com/wp-content/uploads/2009/10/Hurricane-Cake.jpg ?

-- 
Alarig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151201/dfa2537a/attachment.pgp>

From dovid at telecurve.com  Tue Dec  1 21:53:22 2015
From: dovid at telecurve.com (Dovid Bender)
Date: Tue, 1 Dec 2015 16:53:22 -0500
Subject: APC vs TrippLite metered PDU's
Message-ID: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>

Hello All,

We currently use TrippLite and over all have been very happy with their
metered PDU's. When we first started out we had some minor issues and their
support went above and beyond. Lately the their Java web interface has been
becoming a real pain. More and more browsers lock it by default and it
takes a lot of work to get it working correctly. Does anyone have any
experience with APC? How are is management of their devices and over all
how do they operate?

TIA.

Dovid

From aaron at heyaaron.com  Tue Dec  1 22:43:23 2015
From: aaron at heyaaron.com (Aaron C. de Bruyn)
Date: Tue, 1 Dec 2015 14:43:23 -0800
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
Message-ID: <CAEE+rGqUjZVr0ocktQjyKE_nqQos33PdVUZ8RzsjXcx7xro8QA@mail.gmail.com>

If I recall correctly, they have an HTML-based GUI.  I rarely use it.  I
mainly use SSH and SNMP which they support as well.

-A

On Tue, Dec 1, 2015 at 1:53 PM, Dovid Bender <dovid at telecurve.com> wrote:

> Hello All,
>
> We currently use TrippLite and over all have been very happy with their
> metered PDU's. When we first started out we had some minor issues and their
> support went above and beyond. Lately the their Java web interface has been
> becoming a real pain. More and more browsers lock it by default and it
> takes a lot of work to get it working correctly. Does anyone have any
> experience with APC? How are is management of their devices and over all
> how do they operate?
>
> TIA.
>
> Dovid
>

From ianm at fairwaymc.com  Tue Dec  1 23:04:03 2015
From: ianm at fairwaymc.com (Ian Mock)
Date: Tue, 1 Dec 2015 23:04:03 +0000
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAEE+rGqUjZVr0ocktQjyKE_nqQos33PdVUZ8RzsjXcx7xro8QA@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
 <CAEE+rGqUjZVr0ocktQjyKE_nqQos33PdVUZ8RzsjXcx7xro8QA@mail.gmail.com>
Message-ID: <783C627CF58B9948866C2A5DD8C7A90792628983@colombx02.fairwaymc.com>

+1 for APC, HTML based GUI, also supports major management protocols. Never had a problem with it.

Ian Mock


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron C. de Bruyn
Sent: Tuesday, December 01, 2015 4:43 PM
To: Dovid Bender
Cc: NANOG
Subject: Re: APC vs TrippLite metered PDU's

If I recall correctly, they have an HTML-based GUI.  I rarely use it.  I mainly use SSH and SNMP which they support as well.

-A

On Tue, Dec 1, 2015 at 1:53 PM, Dovid Bender <dovid at telecurve.com> wrote:

> Hello All,
>
> We currently use TrippLite and over all have been very happy with 
> their metered PDU's. When we first started out we had some minor 
> issues and their support went above and beyond. Lately the their Java 
> web interface has been becoming a real pain. More and more browsers 
> lock it by default and it takes a lot of work to get it working 
> correctly. Does anyone have any experience with APC? How are is 
> management of their devices and over all how do they operate?
>
> TIA.
>
> Dovid
>


From louisk at cryptomonkeys.org  Tue Dec  1 22:36:45 2015
From: louisk at cryptomonkeys.org (Louis Kowolowski)
Date: Tue, 1 Dec 2015 14:36:45 -0800
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
Message-ID: <E97CB835-297A-4D4C-B831-82F3F235FA12@cryptomonkeys.org>

On Dec 1, 2015, at 1:53 PM, Dovid Bender <dovid at telecurve.com> wrote:
> 
> Hello All,
> 
> We currently use TrippLite and over all have been very happy with their
> metered PDU's. When we first started out we had some minor issues and their
> support went above and beyond. Lately the their Java web interface has been
> becoming a real pain. More and more browsers lock it by default and it
> takes a lot of work to get it working correctly. Does anyone have any
> experience with APC? How are is management of their devices and over all
> how do they operate?
> 
I haven?t used anything in the last couple of years, but historically they didn?t require any plugins. They?ve also been wide open, so make sure you run around and disable all the usual suspects (telnet, non-https, unencrypted snmp). Other than that, I?ve had zero issues with management.

--
Louis Kowolowski                                louisk at cryptomonkeys.org <mailto:louisk at cryptomonkeys.org>
Cryptomonkeys:                                   http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>

Making life more interesting for people since 1977

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

From jfmezei_nanog at vaxination.ca  Tue Dec  1 23:53:23 2015
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Tue, 1 Dec 2015 18:53:23 -0500
Subject: Netflow parameters and data that comes from CDNs
Message-ID: <565E32F3.3010303@vaxination.ca>


Hopefully this should be a simple question ...

(Note: Akamai used as a generic CDN name in the context of this email
and could be any CDN provider)


Context: regulatory filings where wireless carriers states that zero
rating of certain selected streaming music is done based on the "from
IP" in packets coming into its network.


When a content provider such as jf_music.com (fictitious)  makes use of
one or more content distribution networks, does the "from IP" in packets
belong to the CDN, or to jf_music.com ?  (if Akamai uses IPs provided by
jf_music, this has inteteresting routing questions).


If I setup such a service with Akamai, does Akamai provide me with an
authoritative list of IPs that will be generating my traffic in various
cities ? Are these IPs stable or would they typically change fairly
often as Akamai builds more nodes etc ?

And do various CDNs have very different implementations ?


And in fictitious case of jf_music.com hiring Akamai, would the Akamai
server(s)  have a dedicated IP for jf_music in each city (or re-use same
IP via anycast)  or would the CDN servers use the same IP address to
deliver multiple services from totally different content providers ?

(Considering BGP routing limits , I have to assume that routing of
individual IPs can't be done).

I need more of a sanity check on this.

From stl at wiredrive.com  Wed Dec  2 00:07:12 2015
From: stl at wiredrive.com (Scott Larson)
Date: Tue, 1 Dec 2015 16:07:12 -0800
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
Message-ID: <CAFt8naFbAGEd7rA8ZqfQ0KLn+OV=+FSmyyEYnUKtizrAwcpQUA@mail.gmail.com>

     Just to toss them into the mix as a suggestion to look at, we run
Server Technology PDUs here and really like them, especially the POPS+PIPS
line. As far as infrastructure device web interfaces go theirs is arguably
the best I've used and no Java is involved.


*[image: userimage]Scott Larson[image: los angeles]
<https://www.google.com/maps/place/4216+Glencoe+Ave,+Marina+Del+Rey,+CA+90292/@33.9892151,-118.4421334,17z/data=!3m1!4b1!4m2!3m1!1s0x80c2ba88ffae914d:0x14e1d00084d4d09c>Lead
Systems Administrator[image: wdlogo] <https://www.wiredrive.com/> [image:
linkedin] <https://www.linkedin.com/company/wiredrive> [image: facebook]
<https://www.twitter.com/wiredrive> [image: twitter]
<https://www.facebook.com/wiredrive> [image: instagram]
<https://www.instagram.com/wiredrive>T 310 823 8238 x1106
<310%20823%208238%20x1106>  |  M 310 904 8818 <310%20904%208818>*

On Tue, Dec 1, 2015 at 1:53 PM, Dovid Bender <dovid at telecurve.com> wrote:

> Hello All,
>
> We currently use TrippLite and over all have been very happy with their
> metered PDU's. When we first started out we had some minor issues and their
> support went above and beyond. Lately the their Java web interface has been
> becoming a real pain. More and more browsers lock it by default and it
> takes a lot of work to get it working correctly. Does anyone have any
> experience with APC? How are is management of their devices and over all
> how do they operate?
>
> TIA.
>
> Dovid
>

From James at mor-pah.net  Wed Dec  2 00:24:47 2015
From: James at mor-pah.net (James Greig)
Date: Wed, 2 Dec 2015 00:24:47 +0000
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
Message-ID: <46434F64-1486-48EE-ACAA-13D42C21DBED@mor-pah.net>

Raritan and apc pdus are great and do the job.  We use snmp read and writes mainly but the web interface is pretty good and no java out plugins needed.

Kind regards

James Greig 

> On 1 Dec 2015, at 21:53, Dovid Bender <dovid at telecurve.com> wrote:
> 
> Hello All,
> 
> We currently use TrippLite and over all have been very happy with their
> metered PDU's. When we first started out we had some minor issues and their
> support went above and beyond. Lately the their Java web interface has been
> becoming a real pain. More and more browsers lock it by default and it
> takes a lot of work to get it working correctly. Does anyone have any
> experience with APC? How are is management of their devices and over all
> how do they operate?
> 
> TIA.
> 
> Dovid

From jwalter at weebly.com  Wed Dec  2 00:34:43 2015
From: jwalter at weebly.com (Jeff Walter)
Date: Tue, 1 Dec 2015 16:34:43 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <20151201200140.GA22343@drscott.swordarmor.fr>
References: <565DF39C.9060503@netassist.ua>
 <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
 <CALA5tJJ=fWGBRisd8=myYjHFx7=rtfUaWGLE1r9RmaDLjobBYw@mail.gmail.com>
 <20151201200140.GA22343@drscott.swordarmor.fr>
Message-ID: <CAAGWaEf1Sq1EVN1Axo6zzp_r7oWx869P0U1nFwnVmoPMywY8tw@mail.gmail.com>

That cake will haunt NANOG until the end of time.

On Tue, Dec 1, 2015 at 12:01 PM, Alarig Le Lay <alarig at swordarmor.fr> wrote:

> On Tue Dec  1 14:39:14 2015, Andrew Kirch wrote:
> > Might I suggest cake pleas?
>
> You mean
>
> http://www.datacenterknowledge.com/wp-content/uploads/2009/10/Hurricane-Cake.jpg
> ?
>
> --
> Alarig
>

From marka at isc.org  Wed Dec  2 00:39:38 2015
From: marka at isc.org (Mark Andrews)
Date: Wed, 02 Dec 2015 11:39:38 +1100
Subject: strategies to mitigate DNS amplification attacks in ISP network
In-Reply-To: Your message of "Tue, 01 Dec 2015 17:23:01 -0000."
 <DM3PR0601MB2011982419777A0C7960842FF90F0@DM3PR0601MB2011.namprd06.prod.outlook.com>
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
 <DM3PR0601MB2011982419777A0C7960842FF90F0@DM3PR0601MB2011.namprd06.prod.outlook.com>
Message-ID: <20151202003938.32B2C3DEA982@rock.dv.isc.org>


Deploy DNS COOKIES.  This allows legitimate UDP traffic to be
identified and treated differently to spoofed traffic by providing
the equivalent to a TCP handshake but over UDP.

This is currently in IETF last call but the code points are assigned
and implementations are available.  Ask your nameserver vendor for
this today.  Ask your OS vendor for support.

https://tools.ietf.org/html/draft-ietf-dnsop-cookies-07

Mark

In message <DM3PR0601MB2011982419777A0C7960842FF90F0 at DM3PR0601MB2011.namprd06.p
rod.outlook.com>, Michael Hare writes:
> Martin-
> 
> I represent a statewide educational network running Juniper gear that is a qu
> asi-enterprise.  I think efforts depend on size and type of network.  We are 
> testing an approach that involves;
> 
> 1) whitelisting known local resolvers, well behaved cloud DNS resolvers. 
> 2) on ingress, policing non-conforming traffic that matches UDP src port 53 d
> st port unreserved bytes > 1400
> 3) on ingress, queuing fragments to high packet loss priority [you better und
> erstand how fragments are used in your network before doing this]
> 4) If you have Juniper gear look into prefix-action
> 5) RTBH if required
> 
> This obviously doesn't work on the core of the internet.
> 
> Other good tips: 
> * strengthen [anycast] your local DNS resolvers and consider a scheme that al
> lows you to change their outgoing address on the fly.
> * push [some] of your external authoritative DNS to the cloud.
> 
> -Michael
> 
> > > -----Original Message-----
> > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin T
> > > Sent: Tuesday, December 01, 2015 11:00 AM
> > > To: nanog at nanog.org
> > > Subject: strategies to mitigate DNS amplification attacks in ISP network
> > >
> > > Hi,
> > >
> > > as around 40% of ASNs allow at least partial IPv4 address spoofing in
> > > their network(http://spoofer.csail.mit.edu/summary.php) and there are
> > > around 30 million open-resolvers(http://openresolverproject.org/) in
> > > the Internet, then DNS amplification traffic is daily occasion for
> > > ISPs. This in probably mainly because RPF checks and DNS
> > > RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Respons
> e-
> > > Rate-Limiting.html)
> > > are not ubiquitously implemented, recursive requests without any ACLs
> > > in DNS servers are often allowed, it requires little effort from
> > > attackers point of view and is effective attack method. Unfortunately,
> > > there seems to be very limited number of countermeasures for ISPs. Few
> > > which I can think of:
> > >
> > > 1) higher capacity backbone links - I'm not sure if this can be
> > > considered a mitigation method, but at least it can help to affect
> > > smaller amount of customers if traffic volumes are not very high
> > >
> > >
> > > 2) rate-limit incoming DNS traffic flows on peering and uplink ports -
> > > here I mean something similar to iptables "recent"
> > > module(http://www.netfilter.org/documentation/HOWTO/netfilter-
> > extensions-
> > > HOWTO-3.html#ss3.16)
> > > which allows certain number of certain type of packets in a configured
> > > time-slot per IP. However, such functionality is probably not common
> > > on edge or backbone routers.
> > >
> > >
> > > Tracking the packet state does definitely not work because state table
> > > should be synchronized between all the routers in the network and
> > > again, this requires Internet-routers to have stateful firewall
> > > functionality. In addition, one also needs to allow new DNS
> > > connections from Internet to its network.
> > > If one simply polices incoming DNS traffic on uplink and peering
> > > ports(for example if baseline DNS traffic is 5Mbps, then policer is
> > > set to 50Mbps), then legitimate customers DNS traffic is also affected
> > > in case of actual attack occurs and policer starts to drop DNS
> > > traffic, i.e. policer has no way to distinguish between the legitimate
> > > and non-legitimate incoming DNS traffic.
> > >
> > >
> > > Am I wrong in some points? What are the common practices to mitigate
> > > DNS amplification attacks in ISP network?
> > >
> > >
> > > thanks,
> > > Martin
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From patrick at ianai.net  Wed Dec  2 02:53:52 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 1 Dec 2015 21:53:52 -0500
Subject: Netflow parameters and data that comes from CDNs
In-Reply-To: <565E32F3.3010303@vaxination.ca>
References: <565E32F3.3010303@vaxination.ca>
Message-ID: <253DF9B0-82BB-4735-B613-87F1CD0837AD@ianai.net>

The answer is: It depends.

:)

In the case of Akamai, for a standard streaming or HTTP service, the IP address is not dedicated to a single customer. Also, Akamai is not going to give you a list of IP addresses serving your content.

This is specific to Akamai, and for a general Akamai customer. Obviously anything _can_ be done with enough money and negotiation. (Also, neither of the two tidbits of info above is confidential or even difficult to find on the Internet.)

I am unsure how other CDNs handle these requests. I -suspect- it would be easier for other CDNs to guarantee certain content is always served from certain IP addresses.

As for who owns the IP address of the Akamai server, Akamai is very public about putting servers inside networks. It is called their AANP program. AANP servers are frequently numbered with the hosting ISP?s space. But an AANP node is not guaranteed to have the ISP?s IP space, and not all servers are in AANP nodes.

-- 
TTFN,
patrick

> On Dec 1, 2015, at 6:53 PM, Jean-Francois Mezei <jfmezei_nanog at vaxination.ca> wrote:
> 
> 
> Hopefully this should be a simple question ...
> 
> (Note: Akamai used as a generic CDN name in the context of this email
> and could be any CDN provider)
> 
> 
> Context: regulatory filings where wireless carriers states that zero
> rating of certain selected streaming music is done based on the "from
> IP" in packets coming into its network.
> 
> 
> When a content provider such as jf_music.com (fictitious)  makes use of
> one or more content distribution networks, does the "from IP" in packets
> belong to the CDN, or to jf_music.com ?  (if Akamai uses IPs provided by
> jf_music, this has inteteresting routing questions).
> 
> 
> If I setup such a service with Akamai, does Akamai provide me with an
> authoritative list of IPs that will be generating my traffic in various
> cities ? Are these IPs stable or would they typically change fairly
> often as Akamai builds more nodes etc ?
> 
> And do various CDNs have very different implementations ?
> 
> 
> And in fictitious case of jf_music.com hiring Akamai, would the Akamai
> server(s)  have a dedicated IP for jf_music in each city (or re-use same
> IP via anycast)  or would the CDN servers use the same IP address to
> deliver multiple services from totally different content providers ?
> 
> (Considering BGP routing limits , I have to assume that routing of
> individual IPs can't be done).
> 
> I need more of a sanity check on this.


From karsten.elfenbein at gmail.com  Wed Dec  2 08:24:42 2015
From: karsten.elfenbein at gmail.com (Karsten Elfenbein)
Date: Wed, 2 Dec 2015 09:24:42 +0100
Subject: strategies to mitigate DNS amplification attacks in ISP network
In-Reply-To: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
Message-ID: <CADzy1LYexe-cMVaxMX+TAxkGGCQSsL9AB0jNEaS=Wiu+7jERuA@mail.gmail.com>

Hi,

depends on the type of ISP you are and the bandwidth used in the attack.

If most attacks are targeted for www.example.com then you could design
your net so that www.example.com is just a TCP service VIP that never
needs any UDP. This would make it possible to place simple ACL on your
edge to get rid of most stuff.
Yes there are people that know how to correctly DDOS but most just
give up after there attack traffic never affects the service.

If the bandwidth exceeds your transit/peering capacity you need to
filter/blackhole it upstream. You can also isolate the prefix under
attack to a single transit or a DDOS mitigation service to prevent the
other prefixes from being impacted.

Other useful stuff is a flow based traffic analysis tool to get
details about the attack.


Karsten



2015-12-01 17:59 GMT+01:00 Martin T <m4rtntns at gmail.com>:
> Hi,
>
> as around 40% of ASNs allow at least partial IPv4 address spoofing in
> their network(http://spoofer.csail.mit.edu/summary.php) and there are
> around 30 million open-resolvers(http://openresolverproject.org/) in
> the Internet, then DNS amplification traffic is daily occasion for
> ISPs. This in probably mainly because RPF checks and DNS
> RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html)
> are not ubiquitously implemented, recursive requests without any ACLs
> in DNS servers are often allowed, it requires little effort from
> attackers point of view and is effective attack method. Unfortunately,
> there seems to be very limited number of countermeasures for ISPs. Few
> which I can think of:
>
> 1) higher capacity backbone links - I'm not sure if this can be
> considered a mitigation method, but at least it can help to affect
> smaller amount of customers if traffic volumes are not very high
>
>
> 2) rate-limit incoming DNS traffic flows on peering and uplink ports -
> here I mean something similar to iptables "recent"
> module(http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16)
> which allows certain number of certain type of packets in a configured
> time-slot per IP. However, such functionality is probably not common
> on edge or backbone routers.
>
>
> Tracking the packet state does definitely not work because state table
> should be synchronized between all the routers in the network and
> again, this requires Internet-routers to have stateful firewall
> functionality. In addition, one also needs to allow new DNS
> connections from Internet to its network.
> If one simply polices incoming DNS traffic on uplink and peering
> ports(for example if baseline DNS traffic is 5Mbps, then policer is
> set to 50Mbps), then legitimate customers DNS traffic is also affected
> in case of actual attack occurs and policer starts to drop DNS
> traffic, i.e. policer has no way to distinguish between the legitimate
> and non-legitimate incoming DNS traffic.
>
>
> Am I wrong in some points? What are the common practices to mitigate
> DNS amplification attacks in ISP network?
>
>
> thanks,
> Martin

From twh at megagroup.ru  Wed Dec  2 08:33:01 2015
From: twh at megagroup.ru (Stepan Kucherenko)
Date: Wed, 2 Dec 2015 11:33:01 +0300
Subject: strategies to mitigate DNS amplification attacks in ISP network
In-Reply-To: <F53AB4B1-8131-4013-963D-54838A90B18C@arbor.net>
References: <CAJx5YvFt7-OVuCdzgs6fS+7PdCBKrj9O=qw6V9GSuqNYFSYO_Q@mail.gmail.com>
 <F53AB4B1-8131-4013-963D-54838A90B18C@arbor.net>
Message-ID: <565EACBD.6060302@megagroup.ru>

>
> flowspec.
>

Probably the best method if you have competent engineers and uplinks who 
can give you bgp flowspec.

Makes bandwitdh attacks amusing instead of annoying.

From justindh.ml at gmail.com  Tue Dec  1 23:42:29 2015
From: justindh.ml at gmail.com (Justin H.)
Date: Tue, 1 Dec 2015 15:42:29 -0800
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <783C627CF58B9948866C2A5DD8C7A90792628983@colombx02.fairwaymc.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
 <CAEE+rGqUjZVr0ocktQjyKE_nqQos33PdVUZ8RzsjXcx7xro8QA@mail.gmail.com>
 <783C627CF58B9948866C2A5DD8C7A90792628983@colombx02.fairwaymc.com>
Message-ID: <565E3064.5040700@gmail.com>

I haven't had any experience with TrippLite's interface, but I've gotten 
very frustrated with java interfaces lately and avoid them if possible.

APC's web interface is both simple and easy.  I use their switched rack 
PDUs, but I believe the interface is the same for metered. It's simple 
and easy, but has enough features to be generally useful to me.

Justin H.

Ian Mock wrote:
> +1 for APC, HTML based GUI, also supports major management protocols. Never had a problem with it.
>
> Ian Mock
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron C. de Bruyn
> Sent: Tuesday, December 01, 2015 4:43 PM
> To: Dovid Bender
> Cc: NANOG
> Subject: Re: APC vs TrippLite metered PDU's
>
> If I recall correctly, they have an HTML-based GUI.  I rarely use it.  I mainly use SSH and SNMP which they support as well.
>
> -A
>
> On Tue, Dec 1, 2015 at 1:53 PM, Dovid Bender <dovid at telecurve.com> wrote:
>
>> Hello All,
>>
>> We currently use TrippLite and over all have been very happy with
>> their metered PDU's. When we first started out we had some minor
>> issues and their support went above and beyond. Lately the their Java
>> web interface has been becoming a real pain. More and more browsers
>> lock it by default and it takes a lot of work to get it working
>> correctly. Does anyone have any experience with APC? How are is
>> management of their devices and over all how do they operate?
>>
>> TIA.
>>
>> Dovid
>>


From ctomkow at gmail.com  Tue Dec  1 23:57:47 2015
From: ctomkow at gmail.com (Craig Tomkow)
Date: Tue, 1 Dec 2015 16:57:47 -0700
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
Message-ID: <CAHVTWiDLZCEFi8HRM-79LqEwwm8AGtw4F8scYT1SniryhzWYgw@mail.gmail.com>

APC PDUs have been good.  Their HTTPS interface moves like molasses iirc,
but as long as you have some SNMP mgmt platform (APC struxureware for us),
then you are good.
On Dec 1, 2015 2:55 PM, "Dovid Bender" <dovid at telecurve.com> wrote:

> Hello All,
>
> We currently use TrippLite and over all have been very happy with their
> metered PDU's. When we first started out we had some minor issues and their
> support went above and beyond. Lately the their Java web interface has been
> becoming a real pain. More and more browsers lock it by default and it
> takes a lot of work to get it working correctly. Does anyone have any
> experience with APC? How are is management of their devices and over all
> how do they operate?
>
> TIA.
>
> Dovid
>

From frederik at kriewitz.eu  Wed Dec  2 10:25:28 2015
From: frederik at kriewitz.eu (Frederik Kriewitz)
Date: Wed, 2 Dec 2015 11:25:28 +0100
Subject: APC vs TrippLite metered PDU's
In-Reply-To: <CAHVTWiDLZCEFi8HRM-79LqEwwm8AGtw4F8scYT1SniryhzWYgw@mail.gmail.com>
References: <CAM3TTh38UtEBTZyiceDDiSATmXhdNOWmQnGBTUk=HPs0aUm4FA@mail.gmail.com>
 <CAHVTWiDLZCEFi8HRM-79LqEwwm8AGtw4F8scYT1SniryhzWYgw@mail.gmail.com>
Message-ID: <CAKCUjRVUgEA7-3nhT7Qhd1s3uUbHJ+=EEMWgRpqmXZk9q-n6QQ@mail.gmail.com>

Hello Dovid,

we've been using APC devices (including PDUs) for a couple of years.

Occasionally the MGMT cards of the devices stop responding, we had to
manually reset them on site (Reset is possible without affecting the
devices, it won't toggle any relays). This has been a rare event
(~once every 10 years). Overall they are running stable.

You shouldn't expect any long time software/bug fix support either.
E.g. they didn't fix their SSL implementation when the POODLE attack
came up on various slightly older devices (the devices only support
SSLv3 so it's hard to use HTTPS nowadays). On older devices (first
generation) enabling HTTPS will make the interface become really slow
too (apparently due to CPU limitations). On the new MGMT cards (second
generation) they apparently added some crypto hardware offloading
chips to fix that.

Proper HTTPS support is the biggest issue we're still having with
them. In order to enable HTTPS on the webinterface you've to use their
"APC Security Wizard" to generate the key and get the CSR, once you
got it signed you've to use the Wizard again to import the
certificate, then upload the resulting file to the device. The Wizard
is only available for Windows and is a basic GUI application, there's
no easy automation possible. If you have a couple of 100 devices,
renewing certificates for them is a relay annoying task. Their
solution for this is to get a wildcard certificate and use the same
certificate on all devices.

Besides that there's no support for intermediate certificates which in
practice forces you to install any intermediate certificate on your
devices from which you're planning to access the webinterface.
This was first reported in 2007 and is still not fixed:
http://forums.apc.com/spaces/7/ups-management-devices-powerchute-software/forums/general/4567/ssl-intermediate-certificates-on-nmc

If you've a company policy which forces you to use proper
certificates, etc. for the webinterface using APC will be painful.
If you'll use the webinterface rarely and handle the switching, etc.
via SNMP you should be fine.

If you have any probelm try their their forum (Their normal ticketing
system support is really bad).

Best Regards,
Frederik Kriewitz

On Wed, Dec 2, 2015 at 12:57 AM, Craig Tomkow <ctomkow at gmail.com> wrote:
> APC PDUs have been good.  Their HTTPS interface moves like molasses iirc,
> but as long as you have some SNMP mgmt platform (APC struxureware for us),
> then you are good.

From job at instituut.net  Wed Dec  2 11:46:56 2015
From: job at instituut.net (Job Snijders)
Date: Wed, 2 Dec 2015 12:46:56 +0100
Subject: Rob Blokzijl Dies Peacefully Aged 72
Message-ID: <20151202114656.GV55095@22.rev.meerval.net>

NANOG,

Rob Blokzijl, one of the founding fathers of the RIPE (and by extent,
internet as we know it in Europe), passed away yesterday. The links in
the email below offer more insight into his life and accomplishments.

Kind regards,

Job

----- Forwarded message from Daniel Karrenberg <daniel.karrenberg at ripe.net> -----

Date: Wed, 2 Dec 2015 11:02:11 +0100
From: Daniel Karrenberg <daniel.karrenberg at ripe.net>
To: RIPE Community <ripe-list at ripe.net>
Subject: Rob Blokzijl Dies Peacefully Aged 72

Dear colleagues,

I have the painful duty to inform you that Rob Blokzijl, RIPE Chair
Emeritus died at his home in the Netherlands yesterday after a long illness.

https://www.ripe.net/participate/ripe/rob-blokzijl-obituary

This is a sad moment for all of us because we loose a leader whose
influence permeates the RIPE community and the way we conduct our work.
Rob will live on in this way.

Those who wish to share their own tribute to Rob can do so here for all
to see:

https://labs.ripe.net/Members/mirjam/tribute-to-dr-robert-blokzij-1943-2015

I am sure Rob would wish to see positive, even somewhat lighthearted
and anecdotal contributions.

Daniel Karrenberg
Chief Scientist
RIPE NCC


----- End forwarded message -----

From Steve.Mikulasik at civeo.com  Wed Dec  2 15:13:15 2015
From: Steve.Mikulasik at civeo.com (Steve Mikulasik)
Date: Wed, 2 Dec 2015 15:13:15 +0000
Subject: Stewart B.C Loses Internet
Message-ID: <CY1PR07MB2200E252B5B054DD081FECF5FA0E0@CY1PR07MB2200.namprd07.prod.outlook.com>

Interesting story about a small town in BC losing Internet once the non-profit ISP leaves town and they have no alternatives.

http://www.ctvnews.ca/sci-tech/they-won-t-see-this-remote-b-c-town-loses-internet-access-indefinitely-1.2682525






From liz.fazekas at gmail.com  Wed Dec  2 13:02:31 2015
From: liz.fazekas at gmail.com (Liz Fazekas)
Date: Wed, 2 Dec 2015 08:02:31 -0500
Subject: Rob Blokzijl Dies Peacefully Aged 72
In-Reply-To: <20151202114656.GV55095@22.rev.meerval.net>
References: <20151202114656.GV55095@22.rev.meerval.net>
Message-ID: <CAD23y0rsRkidBiPTwngRtt-iA5qYku8Q_=9RU2afo1cO9Wp8Qg@mail.gmail.com>

R.I.P.

Danke fur all the contributions!

On Wed, Dec 2, 2015 at 6:46 AM, Job Snijders <job at instituut.net> wrote:

> NANOG,
>
> Rob Blokzijl, one of the founding fathers of the RIPE (and by extent,
> internet as we know it in Europe), passed away yesterday. The links in
> the email below offer more insight into his life and accomplishments.
>
> Kind regards,
>
> Job
>
> ----- Forwarded message from Daniel Karrenberg <daniel.karrenberg at ripe.net>
> -----
>
> Date: Wed, 2 Dec 2015 11:02:11 +0100
> From: Daniel Karrenberg <daniel.karrenberg at ripe.net>
> To: RIPE Community <ripe-list at ripe.net>
> Subject: Rob Blokzijl Dies Peacefully Aged 72
>
> Dear colleagues,
>
> I have the painful duty to inform you that Rob Blokzijl, RIPE Chair
> Emeritus died at his home in the Netherlands yesterday after a long
> illness.
>
> https://www.ripe.net/participate/ripe/rob-blokzijl-obituary
>
> This is a sad moment for all of us because we loose a leader whose
> influence permeates the RIPE community and the way we conduct our work.
> Rob will live on in this way.
>
> Those who wish to share their own tribute to Rob can do so here for all
> to see:
>
> https://labs.ripe.net/Members/mirjam/tribute-to-dr-robert-blokzij-1943-2015
>
> I am sure Rob would wish to see positive, even somewhat lighthearted
> and anecdotal contributions.
>
> Daniel Karrenberg
> Chief Scientist
> RIPE NCC
>
>
> ----- End forwarded message -----
>



-- 
  Liz *******
416.660.5456

From Chad.Myers at theice.com  Wed Dec  2 22:00:03 2015
From: Chad.Myers at theice.com (Chad Myers)
Date: Wed, 2 Dec 2015 22:00:03 +0000
Subject: SevOne Monitoring
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7B2FE1D@MUNPRDMBXA1.medline.com>
References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org>
 <9578293AE169674F9A048B2BC9A081B401C7B2FE1D@MUNPRDMBXA1.medline.com>
Message-ID: <48DDB6F6-D755-439F-B7A8-C4B609417E26@theice.com>

I took a look at SevOne back when you could download a free, 500-element version of it when I was looking for something to deal with Netflow.  I'd heard of it prior but nothing from the website seemed overly appealing.  Actually -using- the product though it was wonderful seeing a tool built to automatically deal with a lot of the things that are fairly routine but are time consuming to deal with.  Automatic filtering of what is monitored based on user customizable rules.  For example:  Junos device? Ignore all file systems that are mounted from /dev/md*, ignore pim([de])|lsi|gre|ipip|dsc interfaces, and so on.  If an interface is set to admin-down automatically prevent alarms from it.  Then don't alarm on it being down.  If it later changes so it isn't admin-down then start monitoring & alerting on it again automatically.

As Steven pointed out though the pricing model escalates rapidly since they do it by each individual object.  If using netflow, each netflow interface is considered 100 elements if I remember correctly.  Even if I ignored netflow, a single EX8216 would consume a few thousand elements or more if I wanted to monitor all of the interfaces in the chassis.  Just looking at it for lab usage over ~12 Juniper devices, if I wanted to get full monitoring over all devices, without netflow/sflow, it was a few hundred thousand elements.  When I try to extrapolate that to our production environment with thousands of network devices I can't even imagine what the element count and subsequent cost would be.  When comparing against similar tools the cost is simply outrageous due to the licensing.  And I just realized that it actually becomes more cost effective to have an internal development team dedicated to writing & maintaining custom network monitoring tools when compared to licensing costs like this.

Independent of that, I'm miffed that the free, 500-element version I was using for home and lab use is no longer usable.  It says the license is valid until sometime in 2031, but won't actually let me beyond that point until I upload an updated license file.  Can't even do a reinstall since the original license file is only valid for a few weeks before it expires.  I keep forgetting to contact support about it when I'm at home but since they completely removed the free version I'm doubtful that they will provide an updated license file.

So yeah, fantastic tool, not as pretty as Solarwinds, but it gets really expensive, really fast.  And when talking with them I got the impression that the licensing was per year versus a one-time license cost and then recurring maintenance cost for support & software updates; the above licensing behavior in the free version supports that impression.  I don't know if that is correct though as I didn't think to ask while I was talking with them.

-Chad


On Nov 25, 2015, at 12:04 PM, "Naslund, Steve" <SNaslund at medline.com> wrote:

> I looked at SevOne and liked the product a lot.  One thing we found was that the pricing model escalates pretty rapidly because they count every OBJECT you monitor, not every device.  So if I am looking at Bytes In, Bytes Out, Errors In, etc on a single interface those are all counted as a separate OBJECT against your license count.  You really have to be more selective about what you want to see which to me is really inconvenient because often you don't know what SNMP object you want to look at until a problem surfaces.  One of the strengths I really liked was the trending capability that helps you predict capacity issues before you hit them.
>
> Summary:  Good product, real expensive in wide deployment.
>
> Steven Naslund
> Chicago IL
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart
> Sent: Wednesday, November 25, 2015 2:55 AM
> To: 'NANOG'
> Subject: SevOne Monitoring
>
> Hey folks.
>
>
>
> Looking for feedback from actual customers on SevOne for network monitoring . anyone using them and willing to share thoughts online/offline?
>
>
>
> They have an appealing system for network monitoring and considering it as a replacement to Solarwinds.
>
>
>
> Cheers,
>
> Paul
>
>
>
>
>


________________________________

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

From ryan at u13.net  Thu Dec  3 01:38:13 2015
From: ryan at u13.net (Ryan Rawdon)
Date: Wed, 2 Dec 2015 19:38:13 -0600
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <565DF39C.9060503@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
Message-ID: <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>


> On Dec 1, 2015, at 1:23 PM, Max Tulyev <maxtul at netassist.ua> wrote:
> 
> Hi All,
> 
> we got an issue today that announces from Cogent don't reach Hurricane
> Electric. HE support said that's a feature, not a bug.
> 
> So we have splitted Internet again?
> 
> I have to change at least one of my uplinks because of it, which one is
> better to drop, HE or Cogent?


There is another option, instead of choosing just one - perhaps establish a tunnel to HE from a L3 device that can do the tunneling in hardware?  You can get a HE tunnel for free, and they will speak BGP to you.

Alternatively, if you are on any IXes where HE is present - they will not only peer with you for v6, but announce a full table if you want it. 

From seth.mos at dds.nl  Thu Dec  3 08:04:56 2015
From: seth.mos at dds.nl (Seth Mos)
Date: Thu, 3 Dec 2015 09:04:56 +0100
Subject: Google Chrome 47.0.2526.73M broken NTLM proxy authentication
Message-ID: <565FF7A8.7070201@dds.nl>

Dear Google,

As of Dec 2nd the Google Chrome 47.0.2526.73M breaks NTLM proxy
authentication. This is unfortunate as nobody can get off the company
network now, which is secure I suppose, but not quite what I had in mind.

https://productforums.google.com/forum/#!topic/chrome/G_9eXH9c_ns;context-place=forum/chrome

So if anybody gets called that Google Chrome is throwing a
username/password prompt for every website you try, listing the website
as the authentication domain, instead of the proxy server, this is for you.

If you are ahead of the curve, you can make a GPO to disable Chrome
updates for the time being until this is fixed. If the browser already
updated, well, sorry.

Kind regards,

Seth

From throwaway1958251 at gmail.com  Thu Dec  3 08:15:04 2015
From: throwaway1958251 at gmail.com (halp us)
Date: Thu, 3 Dec 2015 03:15:04 -0500
Subject: Ransom DDoS attack - need help!
Message-ID: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>

All,

I've been a NANOG member for many years but I'm emailing from an anonymous
account to reduce the chance of the attackers finding me.

A company that shall remain anonymous has received a ransom DDoS note from
a very well known group that has been in the news lately. Recently they've
threatened to carry out a major DDoS attack if they are not paid by a
deadline which is approaching. They've performed an attack of a smaller
magnitude to prove that they're serious.

Based on certain details that I can't reveal here, we believe the magnitude
of the upcoming attack may be in the several hundred Gbps.

I would really appreciate help in a few areas (primarily with certain
provider contacts/intros) so we can execute our strategy (which I can't
reveal here for obvious reasons). If you email me off-list with a
name/email that you've previously used on-list, I will reply from my real
email.

Alternatively, if you can post your experiences on-list with large scale
high profile ransom DDoS attacks, I'd really appreciate it!

Thanks

From josh at kyneticwifi.com  Thu Dec  3 14:54:45 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Thu, 3 Dec 2015 08:54:45 -0600
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <CAC6=tfai5ppt3H78vqqP5q1nEYF7BzASOo8LthML8CC-jM96LA@mail.gmail.com>

Sounds like lizardSquad may be at it again
On Dec 3, 2015 8:53 AM, "halp us" <throwaway1958251 at gmail.com> wrote:

> All,
>
> I've been a NANOG member for many years but I'm emailing from an anonymous
> account to reduce the chance of the attackers finding me.
>
> A company that shall remain anonymous has received a ransom DDoS note from
> a very well known group that has been in the news lately. Recently they've
> threatened to carry out a major DDoS attack if they are not paid by a
> deadline which is approaching. They've performed an attack of a smaller
> magnitude to prove that they're serious.
>
> Based on certain details that I can't reveal here, we believe the magnitude
> of the upcoming attack may be in the several hundred Gbps.
>
> I would really appreciate help in a few areas (primarily with certain
> provider contacts/intros) so we can execute our strategy (which I can't
> reveal here for obvious reasons). If you email me off-list with a
> name/email that you've previously used on-list, I will reply from my real
> email.
>
> Alternatively, if you can post your experiences on-list with large scale
> high profile ransom DDoS attacks, I'd really appreciate it!
>
> Thanks
>

From josh at kyneticwifi.com  Thu Dec  3 15:04:41 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Thu, 3 Dec 2015 09:04:41 -0600
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAE7vEqF1N+Cbg6_BQjsq457A005n6T-E1E7-Cp59UEJR-oQtmg@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <CAC6=tfai5ppt3H78vqqP5q1nEYF7BzASOo8LthML8CC-jM96LA@mail.gmail.com>
 <CAE7vEqF1N+Cbg6_BQjsq457A005n6T-E1E7-Cp59UEJR-oQtmg@mail.gmail.com>
Message-ID: <CAC6=tfbsLA0O1JoL-5wLEtRPZDaG=xdYp3ULoeiUOnajCvh3Ng@mail.gmail.com>

None of those names you just mentioned have made the international news.
On Dec 3, 2015 8:59 AM, "Chris Baker" <cbaker at dyn.com> wrote:

> Can you provide some additional details? Is it someone claiming
> association with a known group like DD4BC or the Armada Collective or
> unbranded?
>
> Cheers,
> CBaker
>
>
> On Thu, Dec 3, 2015 at 9:54 AM, Josh Reynolds <josh at kyneticwifi.com>
> wrote:
>
>> Sounds like lizardSquad may be at it again
>> On Dec 3, 2015 8:53 AM, "halp us" <throwaway1958251 at gmail.com> wrote:
>>
>> > All,
>> >
>> > I've been a NANOG member for many years but I'm emailing from an
>> anonymous
>> > account to reduce the chance of the attackers finding me.
>> >
>> > A company that shall remain anonymous has received a ransom DDoS note
>> from
>> > a very well known group that has been in the news lately. Recently
>> they've
>> > threatened to carry out a major DDoS attack if they are not paid by a
>> > deadline which is approaching. They've performed an attack of a smaller
>> > magnitude to prove that they're serious.
>> >
>> > Based on certain details that I can't reveal here, we believe the
>> magnitude
>> > of the upcoming attack may be in the several hundred Gbps.
>> >
>> > I would really appreciate help in a few areas (primarily with certain
>> > provider contacts/intros) so we can execute our strategy (which I can't
>> > reveal here for obvious reasons). If you email me off-list with a
>> > name/email that you've previously used on-list, I will reply from my
>> real
>> > email.
>> >
>> > Alternatively, if you can post your experiences on-list with large scale
>> > high profile ransom DDoS attacks, I'd really appreciate it!
>> >
>> > Thanks
>> >
>>
>
>

From rdobbins at arbor.net  Thu Dec  3 15:20:26 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 03 Dec 2015 22:20:26 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <F2A86265-59D7-4F90-964D-6D57C877F4CF@arbor.net>

On 3 Dec 2015, at 15:15, halp us wrote:

> Based on certain details that I can't reveal here, we believe the 
> magnitude of the upcoming attack may be in the several hundred Gbps.

They lie.  The largest attacks we've seen from these threat actors are 
in the ~60gb/sec range - which is nothing to shake a stick at, mind.

Many times, they don't follow through.  But you're right to be prepared.

See these two presos:

<https://app.box.com/s/2kpbqfdl1ko3qhfhe4y8ekd1rvj24vfd>

<https://app.box.com/s/r7an1moswtc7ce58f8gg>

> I would really appreciate help in a few areas (primarily with certain 
> provider contacts/intros) so we can execute our strategy (which I 
> can't reveal here for obvious reasons).

All this super-secret squirrel stuff doesn't help, it's actually a 
hindrance.  The short answer is 'upstream ACLs'.

Nevertheless, contact me 1:1 and I'll work to hook you up with the right 
folks.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From nick at foobar.org  Thu Dec  3 15:26:40 2015
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 3 Dec 2015 15:26:40 +0000
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <56605F30.4090203@foobar.org>

On 03/12/2015 08:15, halp us wrote:
> a very well known group that has been in the news lately. Recently they've
> threatened to carry out a major DDoS attack if they are not paid by a
> deadline which is approaching. They've performed an attack of a smaller
> magnitude to prove that they're serious.

bear in mind that if you pay a ransom like this:

1. you're opening up a bank account for them to dip into whenever they feel
they need more money.

2. you're perpetuating the problem of ddos-or-ransom by turning it into a
viable business.

If you believe that someone who issues a ransom threat will stop if you pay
them off, you're smoking crack.

Nick


From rdobbins at arbor.net  Thu Dec  3 15:36:32 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 03 Dec 2015 22:36:32 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <56605F30.4090203@foobar.org>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <56605F30.4090203@foobar.org>
Message-ID: <B61A6FE8-EF48-425C-BE52-98D661443CED@arbor.net>

On 3 Dec 2015, at 22:26, Nick Hilliard wrote:

> If you believe that someone who issues a ransom threat will stop if you pay
> them off, you're smoking crack.

+1

These attacks aren't rocket-science to defend against.

OP, ping me 1:1.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From dcorbe at hammerfiber.com  Thu Dec  3 15:39:10 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Thu, 3 Dec 2015 10:39:10 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <56605F30.4090203@foobar.org>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <56605F30.4090203@foobar.org>
Message-ID: <F7C9EFAE-AEFF-4F1C-A641-FC995F2EEE2E@hammerfiber.com>


> On Dec 3, 2015, at 10:26 AM, Nick Hilliard <nick at foobar.org> wrote:
> 
> On 03/12/2015 08:15, halp us wrote:
>> a very well known group that has been in the news lately. Recently they've
>> threatened to carry out a major DDoS attack if they are not paid by a
>> deadline which is approaching. They've performed an attack of a smaller
>> magnitude to prove that they're serious.
> 
> bear in mind that if you pay a ransom like this:
> 
> 1. you're opening up a bank account for them to dip into whenever they feel
> they need more money.

Most of these types of service ransom deals are conducted via bitcoin.  So I don?t see how this could be the case unless you mean to say that appeasing your attackers is a bad idea because they might just be emboldened enough to try and extort you again whenever the piggy bank is beginning to run dry.


From Patrick.Darden at p66.com  Thu Dec  3 15:49:21 2015
From: Patrick.Darden at p66.com (Darden, Patrick)
Date: Thu, 3 Dec 2015 15:49:21 +0000
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <7c41a800f3ba46fdb539676d931d394d@BRTEXMB02.phillips66.net>

Talk to your upstream provider.  They may already have mitigation in place (e.g. Arbor devices).  If not, then if you know much about this anticipated attack (and you seem to have some details) they can certainly implement ACLs and other moderating  tools.  Regardless, contact the FBI or similar LEA and get them involved: extortion and threats for now, and if they follow through then you have civil and very possibly criminal proceedings to look forward to.

I also highly recommend you contact EFF.  Start at eff.org

--patrick darden

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of halp us
Sent: Thursday, December 03, 2015 2:15 AM
To: nanog at nanog.org
Subject: [EXTERNAL]Ransom DDoS attack - need help!

All,

I've been a NANOG member for many years but I'm emailing from an anonymous account to reduce the chance of the attackers finding me.

A company that shall remain anonymous has received a ransom DDoS note from a very well known group that has been in the news lately. Recently they've threatened to carry out a major DDoS attack if they are not paid by a deadline which is approaching. They've performed an attack of a smaller magnitude to prove that they're serious.

Based on certain details that I can't reveal here, we believe the magnitude of the upcoming attack may be in the several hundred Gbps.

I would really appreciate help in a few areas (primarily with certain provider contacts/intros) so we can execute our strategy (which I can't reveal here for obvious reasons). If you email me off-list with a name/email that you've previously used on-list, I will reply from my real email.

Alternatively, if you can post your experiences on-list with large scale high profile ransom DDoS attacks, I'd really appreciate it!

Thanks

From jtk at cymru.com  Thu Dec  3 16:23:14 2015
From: jtk at cymru.com (John Kristoff)
Date: Thu, 3 Dec 2015 10:23:14 -0600
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <20151203102314.5309421d@localhost>

On Thu, 3 Dec 2015 03:15:04 -0500
halp us <throwaway1958251 at gmail.com> wrote:

> I would really appreciate help in a few areas (primarily with certain
> provider contacts/intros) so we can execute our strategy (which I
> can't reveal here for obvious reasons). If you email me off-list with
> a name/email that you've previously used on-list, I will reply from
> my real email.

Hello,

Sorry for your troubles.  I'm happy to try to put you in touch with
people we know or specific providers that may be particularly important
for you, given the path attack traffic may follow to you.  Generally,
however, you need to be working with your upstream providers or peers.
Those are your best friends that are best able to mitigate traffic from
reaching you or to help trace back where it is coming from.

We also operate a free community service called UTRS, which is
essentially just a community remote triggered black hole (RTBH)
service.  Depending on the attack and where it is coming from, it may
be of some help.  It is another tool in the tool box that is relatively
easy to get going.  Technical details and sign up form here:

  <https://www.cymru.com/jtk/misc/utrs.html>
  <http://www.team-cymru.org/UTRS/>

In case an attack does come, you must be able to provide some profile
of the attack traffic for others to help.  A sample of the attack
traffic (e.g. a pcap, flow data, logs), including any characteristics
that might help others help you mitigate is important.  This includes
source network, IP address(es) (but they may be spoofed), protocol,
port, packet size, payload, etc... anything that may uniquely identify
the traffic.  Keep track of the time an attack starts and let people
know what time zone you're working in, or convert to UTC (preferred).

> Alternatively, if you can post your experiences on-list with large
> scale high profile ransom DDoS attacks, I'd really appreciate it!

You should consider engaging your local federal law enforcement
office.  Don't expect miracles, but at least have that ball rolling.
They will probably tell you not to pay, and generally you shouldn't.
Keep a good evidence trail.  Be vigilant, but don't panic.

John

From bill at herrin.us  Thu Dec  3 16:24:23 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 3 Dec 2015 11:24:23 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <CAP-guGXjjbtvPxu9q_Hgt6r5y_oTyaBjtO_ByD4+sSFAjEwRNA@mail.gmail.com>

On Thu, Dec 3, 2015 at 3:15 AM, halp us <throwaway1958251 at gmail.com> wrote:
> A company that shall remain anonymous has received a ransom DDoS note from
> a very well known group that has been in the news lately. Recently they've
> threatened to carry out a major DDoS attack if they are not paid by a
> deadline which is approaching. They've performed an attack of a smaller
> magnitude to prove that they're serious.

Hello,

Are you announcing your IP addresses via BGP or does your ISP manage
routing for you?

If BGP, contract with a DDOS mitigator now. During an attack, you
reroute the /24 containing the attacked destination to the mitigator
and let them scrub the bad traffic for you. I have no idea who to
recommend but I believe there was a recent discussion on nanog about
just that subject.

Make sure your ISP provides you with a small block of its addresses so
that you can anchor the tunnel from the DDOS mitigator no matter which
of your announced address blocks is attacked. And test to make sure
your addresses really do reroute to the mitigator at need: your ISP
can do a number of things to foul up your BGP announcement which you
won't notice until you try to reroute.

If not BGP, this is your ISP's problem. Notify them of the threat so
that they can get ready to mitigate it.


As others have said, don't pay the ransom. Even if the current thieves
honor the bargain, it'll become known that you paid. That paints a
great big target on your back for every other thief out there.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From dovid at telecurve.com  Thu Dec  3 19:38:08 2015
From: dovid at telecurve.com (Dovid Bender)
Date: Thu, 3 Dec 2015 14:38:08 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <F2A86265-59D7-4F90-964D-6D57C877F4CF@arbor.net>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <F2A86265-59D7-4F90-964D-6D57C877F4CF@arbor.net>
Message-ID: <CAM3TTh3YaF+dRXjsSRU5zDhT7Rn=_hFz8WNJ-Ht2nPvQkf6rqg@mail.gmail.com>

The last I spoke with NTT they said the largest they ever saw was > 300GB
and most of the time they don't follow through. They threaten 100 networks
and hope that x% will pay them off 'just in case'

On Thu, Dec 3, 2015 at 10:20 AM, Roland Dobbins <rdobbins at arbor.net> wrote:

> On 3 Dec 2015, at 15:15, halp us wrote:
>
> Based on certain details that I can't reveal here, we believe the
>> magnitude of the upcoming attack may be in the several hundred Gbps.
>>
>
> They lie.  The largest attacks we've seen from these threat actors are in
> the ~60gb/sec range - which is nothing to shake a stick at, mind.
>
> Many times, they don't follow through.  But you're right to be prepared.
>
> See these two presos:
>
> <https://app.box.com/s/2kpbqfdl1ko3qhfhe4y8ekd1rvj24vfd>
>
> <https://app.box.com/s/r7an1moswtc7ce58f8gg>
>
> I would really appreciate help in a few areas (primarily with certain
>> provider contacts/intros) so we can execute our strategy (which I can't
>> reveal here for obvious reasons).
>>
>
> All this super-secret squirrel stuff doesn't help, it's actually a
> hindrance.  The short answer is 'upstream ACLs'.
>
> Nevertheless, contact me 1:1 and I'll work to hook you up with the right
> folks.
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
>

From cbaker at dyn.com  Thu Dec  3 14:59:57 2015
From: cbaker at dyn.com (Chris Baker)
Date: Thu, 3 Dec 2015 09:59:57 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAC6=tfai5ppt3H78vqqP5q1nEYF7BzASOo8LthML8CC-jM96LA@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <CAC6=tfai5ppt3H78vqqP5q1nEYF7BzASOo8LthML8CC-jM96LA@mail.gmail.com>
Message-ID: <CAE7vEqF1N+Cbg6_BQjsq457A005n6T-E1E7-Cp59UEJR-oQtmg@mail.gmail.com>

Can you provide some additional details? Is it someone claiming association
with a known group like DD4BC or the Armada Collective or unbranded?

Cheers,
CBaker


On Thu, Dec 3, 2015 at 9:54 AM, Josh Reynolds <josh at kyneticwifi.com> wrote:

> Sounds like lizardSquad may be at it again
> On Dec 3, 2015 8:53 AM, "halp us" <throwaway1958251 at gmail.com> wrote:
>
> > All,
> >
> > I've been a NANOG member for many years but I'm emailing from an
> anonymous
> > account to reduce the chance of the attackers finding me.
> >
> > A company that shall remain anonymous has received a ransom DDoS note
> from
> > a very well known group that has been in the news lately. Recently
> they've
> > threatened to carry out a major DDoS attack if they are not paid by a
> > deadline which is approaching. They've performed an attack of a smaller
> > magnitude to prove that they're serious.
> >
> > Based on certain details that I can't reveal here, we believe the
> magnitude
> > of the upcoming attack may be in the several hundred Gbps.
> >
> > I would really appreciate help in a few areas (primarily with certain
> > provider contacts/intros) so we can execute our strategy (which I can't
> > reveal here for obvious reasons). If you email me off-list with a
> > name/email that you've previously used on-list, I will reply from my real
> > email.
> >
> > Alternatively, if you can post your experiences on-list with large scale
> > high profile ransom DDoS attacks, I'd really appreciate it!
> >
> > Thanks
> >
>

From cbaker at dyn.com  Thu Dec  3 15:11:27 2015
From: cbaker at dyn.com (Chris Baker)
Date: Thu, 3 Dec 2015 10:11:27 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAC6=tfbsLA0O1JoL-5wLEtRPZDaG=xdYp3ULoeiUOnajCvh3Ng@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <CAC6=tfai5ppt3H78vqqP5q1nEYF7BzASOo8LthML8CC-jM96LA@mail.gmail.com>
 <CAE7vEqF1N+Cbg6_BQjsq457A005n6T-E1E7-Cp59UEJR-oQtmg@mail.gmail.com>
 <CAC6=tfbsLA0O1JoL-5wLEtRPZDaG=xdYp3ULoeiUOnajCvh3Ng@mail.gmail.com>
Message-ID: <CAE7vEqEQjid9wOTyY0dYH_t=Sp4hJUUEseBCejQYtYiQ2=7TWA@mail.gmail.com>

OSINT has a plethora of detail available:

http://www.reuters.com/article/2015/11/30/greece-banks-idUSL8N13P5B420151130
http://www.ibtimes.co.uk/armada-collective-who-are-hackers-extorting-bitcoin-ransoms-what-can-we-do-1528253
http://www.bloomberg.com/news/articles/2015-09-09/bitcoin-ddos-ransom-demands-raise-dd4bc-profile

On Thu, Dec 3, 2015 at 10:04 AM, Josh Reynolds <josh at kyneticwifi.com> wrote:

> None of those names you just mentioned have made the international news.
> On Dec 3, 2015 8:59 AM, "Chris Baker" <cbaker at dyn.com> wrote:
>
>> Can you provide some additional details? Is it someone claiming
>> association with a known group like DD4BC or the Armada Collective or
>> unbranded?
>>
>> Cheers,
>> CBaker
>>
>>
>> On Thu, Dec 3, 2015 at 9:54 AM, Josh Reynolds <josh at kyneticwifi.com>
>> wrote:
>>
>>> Sounds like lizardSquad may be at it again
>>> On Dec 3, 2015 8:53 AM, "halp us" <throwaway1958251 at gmail.com> wrote:
>>>
>>> > All,
>>> >
>>> > I've been a NANOG member for many years but I'm emailing from an
>>> anonymous
>>> > account to reduce the chance of the attackers finding me.
>>> >
>>> > A company that shall remain anonymous has received a ransom DDoS note
>>> from
>>> > a very well known group that has been in the news lately. Recently
>>> they've
>>> > threatened to carry out a major DDoS attack if they are not paid by a
>>> > deadline which is approaching. They've performed an attack of a smaller
>>> > magnitude to prove that they're serious.
>>> >
>>> > Based on certain details that I can't reveal here, we believe the
>>> magnitude
>>> > of the upcoming attack may be in the several hundred Gbps.
>>> >
>>> > I would really appreciate help in a few areas (primarily with certain
>>> > provider contacts/intros) so we can execute our strategy (which I can't
>>> > reveal here for obvious reasons). If you email me off-list with a
>>> > name/email that you've previously used on-list, I will reply from my
>>> real
>>> > email.
>>> >
>>> > Alternatively, if you can post your experiences on-list with large
>>> scale
>>> > high profile ransom DDoS attacks, I'd really appreciate it!
>>> >
>>> > Thanks
>>> >
>>>
>>
>>

From robban+nanog at netnerdz.se  Thu Dec  3 15:14:34 2015
From: robban+nanog at netnerdz.se (Robban)
Date: Thu, 3 Dec 2015 16:14:34 +0100
Subject: Ransom DDoS attack - need help!
In-Reply-To: <20151203150913.GD4332@shell01.saturnus.netnerdz.se>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <20151203150913.GD4332@shell01.saturnus.netnerdz.se>
Message-ID: <20151203151433.GE4332@shell01.saturnus.netnerdz.se>

Hi!
This is my first mail to the list.
Afaik, the DDoS is "only" a UDP based one (or much of the attack), you should be able to mitigate 
some to much of the damage caused by filled pipes by blocking incomming UDP trafic at your ISP level.
 
//Robban
 
> * On Thu, Dec 03, 2015 at 03:15:04AM -0500, halp us <throwaway1958251 at gmail.com> wrote:
> > All,
> > 
> > I've been a NANOG member for many years but I'm emailing from an anonymous
> > account to reduce the chance of the attackers finding me.
> > 
> > A company that shall remain anonymous has received a ransom DDoS note from
> > a very well known group that has been in the news lately. Recently they've
> > threatened to carry out a major DDoS attack if they are not paid by a
> > deadline which is approaching. They've performed an attack of a smaller
> > magnitude to prove that they're serious.
> > 
> > Based on certain details that I can't reveal here, we believe the magnitude
> > of the upcoming attack may be in the several hundred Gbps.
> > 
> > I would really appreciate help in a few areas (primarily with certain
> > provider contacts/intros) so we can execute our strategy (which I can't
> > reveal here for obvious reasons). If you email me off-list with a
> > name/email that you've previously used on-list, I will reply from my real
> > email.
> > 
> > Alternatively, if you can post your experiences on-list with large scale
> > high profile ransom DDoS attacks, I'd really appreciate it!
> > 
> > Thanks

-- 
Robert Soderlund

From brandon at burn.net  Thu Dec  3 16:34:00 2015
From: brandon at burn.net (Brandon Applegate)
Date: Thu, 3 Dec 2015 11:34:00 -0500
Subject: TWC RR contact off list ?
Message-ID: <9A217094-E959-40E6-B603-8AE40DAF0794@burn.net>

Could someone from TWC RR contact me off-list ?  I have an IPv6 / DNS question / request.  I?m in Cincinnati, OH and this is residential if that matters.

Otherwise - if anyone non-TWC on list can point me to a person/address etc that will let me leap frog frontline support that would be great.  There?s no way the support folks are going to know what I?m asking or who/how to escalate.

Thanks in advance.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
"SH1-0151.  This is the serial number, of our orbital gun."

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

From Tony.McKay at RitterCommunications.com  Thu Dec  3 18:35:38 2015
From: Tony.McKay at RitterCommunications.com (Tony McKay)
Date: Thu, 3 Dec 2015 18:35:38 +0000
Subject: SevOne Monitoring
In-Reply-To: <48DDB6F6-D755-439F-B7A8-C4B609417E26@theice.com>
References: <00be01d1275e$e6400760$b2c01620$@paulstewart.org>
 <9578293AE169674F9A048B2BC9A081B401C7B2FE1D@MUNPRDMBXA1.medline.com>
 <48DDB6F6-D755-439F-B7A8-C4B609417E26@theice.com>
Message-ID: <6F2BC9429CDDC6438D1FE460D2258BB4023019C4C1@EXCHANGENODE1.ritter.net>

All,
	I've been using SevOne for 3 years, and I can confirm some of your suspicions around element licensing, in that you will consume more element counts than you allowed in your budget.  It does provide a very granular way of omitting objects from discovery through regex.  It is not a single pane of glass solution, in that fault management is not its forte.  This platform is for performance measurement and management primarily.  A good example of this is that out of the box, it cannot throw an alert if an interface goes down.  You have to programmatically build each alert based on an SNMP polled value, so there is a long lead time before you can bring it into production.  Compared to other similar products out there, price per license seems to be pretty steep, since it include the hardware, but you also will continue to pay 18% maintenance year over year.

	I'm available for any one-on-one discussions you might have about the platform offline.


Tony McKay
Tony.mckay at rittercommunications.com

-The boundary to your comfort zone fades a little each time you cross it.  Raise your limits by pushing them.

This electronic mail transmission may contain confidential or privileged information. If you believe that you have received this message in error, please notify the sender by reply transmission and delete the message without copying or disclosing it.


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chad Myers
Sent: Wednesday, December 02, 2015 4:00 PM
To: Naslund, Steve
Cc: nanog at nanog.org
Subject: [BULK] Re: SevOne Monitoring

I took a look at SevOne back when you could download a free, 500-element version of it when I was looking for something to deal with Netflow.  I'd heard of it prior but nothing from the website seemed overly appealing.  Actually -using- the product though it was wonderful seeing a tool built to automatically deal with a lot of the things that are fairly routine but are time consuming to deal with.  Automatic filtering of what is monitored based on user customizable rules.  For example:  Junos device? Ignore all file systems that are mounted from /dev/md*, ignore pim([de])|lsi|gre|ipip|dsc interfaces, and so on.  If an interface is set to admin-down automatically prevent alarms from it.  Then don't alarm on it being down.  If it later changes so it isn't admin-down then start monitoring & alerting on it again automatically.

As Steven pointed out though the pricing model escalates rapidly since they do it by each individual object.  If using netflow, each netflow interface is considered 100 elements if I remember correctly.  Even if I ignored netflow, a single EX8216 would consume a few thousand elements or more if I wanted to monitor all of the interfaces in the chassis.  Just looking at it for lab usage over ~12 Juniper devices, if I wanted to get full monitoring over all devices, without netflow/sflow, it was a few hundred thousand elements.  When I try to extrapolate that to our production environment with thousands of network devices I can't even imagine what the element count and subsequent cost would be.  When comparing against similar tools the cost is simply outrageous due to the licensing.  And I just realized that it actually becomes more cost effective to have an internal development team dedicated to writing & maintaining custom network monitoring tools when compared to licensing costs like this.

Independent of that, I'm miffed that the free, 500-element version I was using for home and lab use is no longer usable.  It says the license is valid until sometime in 2031, but won't actually let me beyond that point until I upload an updated license file.  Can't even do a reinstall since the original license file is only valid for a few weeks before it expires.  I keep forgetting to contact support about it when I'm at home but since they completely removed the free version I'm doubtful that they will provide an updated license file.

So yeah, fantastic tool, not as pretty as Solarwinds, but it gets really expensive, really fast.  And when talking with them I got the impression that the licensing was per year versus a one-time license cost and then recurring maintenance cost for support & software updates; the above licensing behavior in the free version supports that impression.  I don't know if that is correct though as I didn't think to ask while I was talking with them.

-Chad


On Nov 25, 2015, at 12:04 PM, "Naslund, Steve" <SNaslund at medline.com> wrote:

> I looked at SevOne and liked the product a lot.  One thing we found was that the pricing model escalates pretty rapidly because they count every OBJECT you monitor, not every device.  So if I am looking at Bytes In, Bytes Out, Errors In, etc on a single interface those are all counted as a separate OBJECT against your license count.  You really have to be more selective about what you want to see which to me is really inconvenient because often you don't know what SNMP object you want to look at until a problem surfaces.  One of the strengths I really liked was the trending capability that helps you predict capacity issues before you hit them.
>
> Summary:  Good product, real expensive in wide deployment.
>
> Steven Naslund
> Chicago IL
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart
> Sent: Wednesday, November 25, 2015 2:55 AM
> To: 'NANOG'
> Subject: SevOne Monitoring
>
> Hey folks.
>
>
>
> Looking for feedback from actual customers on SevOne for network monitoring . anyone using them and willing to share thoughts online/offline?
>
>
>
> They have an appealing system for network monitoring and considering it as a replacement to Solarwinds.
>
>
>
> Cheers,
>
> Paul
>
>
>
>
>


________________________________

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

From jared at compuwizz.net  Thu Dec  3 18:40:06 2015
From: jared at compuwizz.net (Jared Geiger)
Date: Thu, 3 Dec 2015 10:40:06 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
Message-ID: <CAHuchRCYVVHEQ2bvnhXKgT5vepDw-J0THx8cRkdxU_8BqHeHSQ@mail.gmail.com>

Wouldn't this be a Net Neutrality issue now or would it fall on HE for not
willing to buy transit to Cogent IPv6?

On Wed, Dec 2, 2015 at 5:38 PM, Ryan Rawdon <ryan at u13.net> wrote:

>
> > On Dec 1, 2015, at 1:23 PM, Max Tulyev <maxtul at netassist.ua> wrote:
> >
> > Hi All,
> >
> > we got an issue today that announces from Cogent don't reach Hurricane
> > Electric. HE support said that's a feature, not a bug.
> >
> > So we have splitted Internet again?
> >
> > I have to change at least one of my uplinks because of it, which one is
> > better to drop, HE or Cogent?
>
>
> There is another option, instead of choosing just one - perhaps establish
> a tunnel to HE from a L3 device that can do the tunneling in hardware?  You
> can get a HE tunnel for free, and they will speak BGP to you.
>
> Alternatively, if you are on any IXes where HE is present - they will not
> only peer with you for v6, but announce a full table if you want it.

From lyndon at orthanc.ca  Thu Dec  3 19:59:23 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 3 Dec 2015 11:59:23 -0800 (PST)
Subject: Ransom DDoS attack - need help!
In-Reply-To: <20151203151433.GE4332@shell01.saturnus.netnerdz.se>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <20151203150913.GD4332@shell01.saturnus.netnerdz.se>
 <20151203151433.GE4332@shell01.saturnus.netnerdz.se>
Message-ID: <alpine.BSF.2.20.1512031152350.78820@orthanc.ca>

> Afaik, the DDoS is "only" a UDP based one (or much of the attack), you should be able to mitigate
> some to much of the damage caused by filled pipes by blocking incomming UDP trafic at your ISP level.

This is the Armada Collective, based on the description.  We just went 
through a round with them. The hardest they were able to hit us peaked at 
a little under 80 Gbits/second. Primarily DNS and NTP amplification 
attacks. They also hit our web servers with a little over 80 million 
requests over a one hour period, and played some games with TCP to try to 
mess with the protocol stacks on the servers and network gear.

Cloudflare took care of the web attacks.  For DDoS, something like 
Incapsula will take care of the layer 3 stuff.  Not cheap, but very 
effective.

--lyndon


From rdobbins at arbor.net  Thu Dec  3 20:10:53 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 04 Dec 2015 03:10:53 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAC6=tfbsLA0O1JoL-5wLEtRPZDaG=xdYp3ULoeiUOnajCvh3Ng@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <CAC6=tfai5ppt3H78vqqP5q1nEYF7BzASOo8LthML8CC-jM96LA@mail.gmail.com>
 <CAE7vEqF1N+Cbg6_BQjsq457A005n6T-E1E7-Cp59UEJR-oQtmg@mail.gmail.com>
 <CAC6=tfbsLA0O1JoL-5wLEtRPZDaG=xdYp3ULoeiUOnajCvh3Ng@mail.gmail.com>
Message-ID: <2609799E-5EAC-44E4-B075-43FEAA9DD425@arbor.net>

On 3 Dec 2015, at 22:04, Josh Reynolds wrote:

> None of those names you just mentioned have made the international news.

Of course they have.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Thu Dec  3 20:11:44 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 04 Dec 2015 03:11:44 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAM3TTh3YaF+dRXjsSRU5zDhT7Rn=_hFz8WNJ-Ht2nPvQkf6rqg@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <F2A86265-59D7-4F90-964D-6D57C877F4CF@arbor.net>
 <CAM3TTh3YaF+dRXjsSRU5zDhT7Rn=_hFz8WNJ-Ht2nPvQkf6rqg@mail.gmail.com>
Message-ID: <C3728EA0-9571-4A65-A77C-420D7C9655B4@arbor.net>

On 4 Dec 2015, at 2:38, Dovid Bender wrote:

> The last I spoke with NTT they said the largest they ever saw was > 300GB

That wasn't DD4BC or Armada Collective.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From bill at herrin.us  Thu Dec  3 20:51:49 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 3 Dec 2015 15:51:49 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAHuchRCYVVHEQ2bvnhXKgT5vepDw-J0THx8cRkdxU_8BqHeHSQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
 <CAHuchRCYVVHEQ2bvnhXKgT5vepDw-J0THx8cRkdxU_8BqHeHSQ@mail.gmail.com>
Message-ID: <CAP-guGUuo1YgeeY=EuwUhfWL3yAjXv5aJBA2iqvfOhFDAQDMsw@mail.gmail.com>

On Thu, Dec 3, 2015 at 1:40 PM, Jared Geiger <jared at compuwizz.net> wrote:
> Wouldn't this be a Net Neutrality issue now or would it fall on HE for not
> willing to buy transit to Cogent IPv6?

Wouldn't it fall on Cogent for being unwilling to buy transit from HE?
HE is the IPv6 leader in the game.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From clay584 at gmail.com  Thu Dec  3 21:03:07 2015
From: clay584 at gmail.com (Clay Curtis)
Date: Thu, 3 Dec 2015 16:03:07 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <C3728EA0-9571-4A65-A77C-420D7C9655B4@arbor.net>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <F2A86265-59D7-4F90-964D-6D57C877F4CF@arbor.net>
 <CAM3TTh3YaF+dRXjsSRU5zDhT7Rn=_hFz8WNJ-Ht2nPvQkf6rqg@mail.gmail.com>
 <C3728EA0-9571-4A65-A77C-420D7C9655B4@arbor.net>
Message-ID: <CAG3QdWN3zP2gTr4EQacM5hANrC7XU5aMhLdN8WY5qG_oAQVwXw@mail.gmail.com>

F5 Silverline, Arbor Networks, Incapsula, to name a few can do ddos
protection.  Don't pay up, use ddos protection.

Clay



On Thu, Dec 3, 2015 at 3:11 PM, Roland Dobbins <rdobbins at arbor.net> wrote:

> On 4 Dec 2015, at 2:38, Dovid Bender wrote:
>
> > The last I spoke with NTT they said the largest they ever saw was > 300GB
>
> That wasn't DD4BC or Armada Collective.
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
>

From owen at delong.com  Thu Dec  3 21:07:44 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 3 Dec 2015 13:07:44 -0800
Subject: Multi-core clamp on ammeter
In-Reply-To: <86r3j9ef01.fsf@valhalla.seastrom.com>
References: <86r3j9ef01.fsf@valhalla.seastrom.com>
Message-ID: <A2B9402B-C037-416E-9614-EF26E61BA610@delong.com>

The results I was able to find are not promising.

The best I could come up with is to make use of this and some cobbling:

https://moderndevice.com/new-products/current-sensor/ <https://moderndevice.com/new-products/current-sensor/>

I have had good luck with other items from Modern Device, but I have not played with this one.

It can be purchased here: https://moderndevice.com/product/current-sensor/ <https://moderndevice.com/product/current-sensor/>
for $18.

Not responsive to your query, but something I thought you might also find of interest:

http://ipo.lbl.gov/wp-content/uploads/sites/8/2014/12/3165pub2.pdf <http://ipo.lbl.gov/wp-content/uploads/sites/8/2014/12/3165pub2.pdf>

Owen

> On Nov 28, 2015, at 18:06 , Rob Seastrom <rs+nanog at seastrom.com> wrote:
> 
> 
> Hi folks,
> 
> I own a Megger MMC850 which will read amps in a multi-core cable, such as the 10 gauge SEOOW cable one often finds feeding rack PDUs.
> 
> Datasheet here:  http://www.mouser.com/ds/2/263/MMC850_DS_en_V02-15853.pdf
> 
> Apparently they've been discontinued.  Pity.
> 
> Anyone know of a suitable replacement?  I need more.
> 
> -r


From A.L.M.Buxey at lboro.ac.uk  Thu Dec  3 21:25:05 2015
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Thu, 3 Dec 2015 21:25:05 +0000
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAG3QdWN3zP2gTr4EQacM5hANrC7XU5aMhLdN8WY5qG_oAQVwXw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <F2A86265-59D7-4F90-964D-6D57C877F4CF@arbor.net>
 <CAM3TTh3YaF+dRXjsSRU5zDhT7Rn=_hFz8WNJ-Ht2nPvQkf6rqg@mail.gmail.com>
 <C3728EA0-9571-4A65-A77C-420D7C9655B4@arbor.net>
 <CAG3QdWN3zP2gTr4EQacM5hANrC7XU5aMhLdN8WY5qG_oAQVwXw@mail.gmail.com>
Message-ID: <20151203212505.GA11695@lboro.ac.uk>

Hi,
> F5 Silverline, Arbor Networks, Incapsula, to name a few can do ddos
> protection.  Don't pay up, use ddos protection.

you know how many ponder whether AV companies write some of the viruses....

;-)

alan

From jwalter at weebly.com  Thu Dec  3 21:39:36 2015
From: jwalter at weebly.com (Jeff Walter)
Date: Thu, 3 Dec 2015 13:39:36 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAP-guGUuo1YgeeY=EuwUhfWL3yAjXv5aJBA2iqvfOhFDAQDMsw@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
 <CAHuchRCYVVHEQ2bvnhXKgT5vepDw-J0THx8cRkdxU_8BqHeHSQ@mail.gmail.com>
 <CAP-guGUuo1YgeeY=EuwUhfWL3yAjXv5aJBA2iqvfOhFDAQDMsw@mail.gmail.com>
Message-ID: <CAAGWaEcMdh+EFLeAxStsZL547-51b435EcC=AynPCFHr1oExoA@mail.gmail.com>

As funny as that would be, it would never happen. Cogent thinks they're the
biggest. HE is the biggest (last I checked). HE wants to peer. Cogent wants
HE to pay for transit. Cake reference. Still partitioned.

How do you get them connected? I hate to say it, but it would take a major
shift within Cogent. In the meantime your best option to see the whole IPv6
internet is to pay Cogent and to get free v6 transit with HE over an
exchange or tunnel.

On Thu, Dec 3, 2015 at 12:51 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Dec 3, 2015 at 1:40 PM, Jared Geiger <jared at compuwizz.net> wrote:
> > Wouldn't this be a Net Neutrality issue now or would it fall on HE for
> not
> > willing to buy transit to Cogent IPv6?
>
> Wouldn't it fall on Cogent for being unwilling to buy transit from HE?
> HE is the IPv6 leader in the game.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>

From baldur.norddahl at gmail.com  Thu Dec  3 23:19:30 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 4 Dec 2015 00:19:30 +0100
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <565DF39C.9060503@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
Message-ID: <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>

On 1 December 2015 at 20:23, Max Tulyev <maxtul at netassist.ua> wrote:

> Hi All,
>
> we got an issue today that announces from Cogent don't reach Hurricane
> Electric. HE support said that's a feature, not a bug.
>
> So we have splitted Internet again?
>
> I have to change at least one of my uplinks because of it, which one is
> better to drop, HE or Cogent?
>

Question: Why would you have to drop one of them? You have no problem if
you have both.

Even in the case of a link failure to one of them, you will likely not see
a big impact since everyone else also keeps multiple transits. You will
only have trouble with people that are single homed Cogent or HE, in which
case it is more them having a problem than you.

Regards,

Baldur

From alan at clegg.com  Fri Dec  4 00:29:42 2015
From: alan at clegg.com (Alan Clegg)
Date: Thu, 3 Dec 2015 18:29:42 -0600
Subject: TWC RR contact off list ?
In-Reply-To: <9A217094-E959-40E6-B603-8AE40DAF0794@burn.net>
References: <9A217094-E959-40E6-B603-8AE40DAF0794@burn.net>
Message-ID: <5660DE76.6080601@clegg.com>



On 12/3/15 10:34 AM, Brandon Applegate wrote:
> Could someone from TWC RR contact me off-list ?  I have an IPv6 / DNS
> question / request.  I?m in Cincinnati, OH and this is residential if
> that matters.

Is the IPv6 problem related to the 7% packet loss that I've been told
can be fixed by power-cycling my cable modem?  I it HAD been up for 71
days, after all.

(and yes, the problem continues if anyone from TWC would like to chat).

AlanC
-- 
Why don't we wander and follow la vie dansante.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 561 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151203/cc0f9b3e/attachment.pgp>

From mpetach at netflight.com  Fri Dec  4 00:58:08 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 3 Dec 2015 16:58:08 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
Message-ID: <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>

Or, if you feel that Cogent's stubborn insistence on
partitioning the global v6 internet shouldn't be rewarded
with money, pay someone *other* than cogent for
IPv6 transit and also connect to HE.net; that way
you still have access to cogent routes, but you also
send a subtle economic nudge that says "hey cogent--
trying to get into the tier 1 club by partitioning the
internet isn't a good path for long-term sucess".

Note that this is purely my own opinion, not necessarily
that of my employer, my friends, my family, or even my
cat.  I asked my cat about cogent IPv6, and all I got was
a ghostly hairball as a reply[0].

Matt


[0] https://www.youtube.com/watch?v=6kEME0CxmtY



On Thu, Dec 3, 2015 at 3:19 PM, Baldur Norddahl
<baldur.norddahl at gmail.com> wrote:
> On 1 December 2015 at 20:23, Max Tulyev <maxtul at netassist.ua> wrote:
>
>> Hi All,
>>
>> we got an issue today that announces from Cogent don't reach Hurricane
>> Electric. HE support said that's a feature, not a bug.
>>
>> So we have splitted Internet again?
>>
>> I have to change at least one of my uplinks because of it, which one is
>> better to drop, HE or Cogent?
>>
>
> Question: Why would you have to drop one of them? You have no problem if
> you have both.
>
> Even in the case of a link failure to one of them, you will likely not see
> a big impact since everyone else also keeps multiple transits. You will
> only have trouble with people that are single homed Cogent or HE, in which
> case it is more them having a problem than you.
>
> Regards,
>
> Baldur
>

From nanogml at Mail.DDoS-Mitigator.net  Fri Dec  4 01:00:16 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Thu, 3 Dec 2015 17:00:16 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <20151204010016.GA6303@Mail.DDoS-Mitigator.net>


hi "need help"

On 12/03/15 at 03:15am, halp us wrote:
> A company that shall remain anonymous has received a ransom DDoS note from
> a very well known group that has been in the news lately. 

use an email reader that allows you to see all the received email headers
to see which STMP routers they came thru to reach your smtp servers

contact each of the ISP that owns those IP# ranges to forewarn them of
your upcoming DDoS attacks .. if you're/we're lucky, the actual DDoS
attacks would pass thru the same ISPs again

> Recently they've
> threatened to carry out a major DDoS attack if they are not paid by a
> deadline which is approaching. They've performed an attack of a smaller
> magnitude to prove that they're serious.

cool .. more proof that they can carry out an attacks allows you ( law enforcement
and the ISP ) to track down who they are, where they come from, etc, etc, etc

since you also kinda know what time/date they will be attacking, the ISP and
law enforcement can be watching for the incoming attacks reverse track the
originating and probably cracked routers ... and hopefully, one-in-a-million
chance to find the ddos-extorter's computers

if the extorter is in the same city ( your local bully ) using the same ISP, 
finding the extorter should be trivial

you can also catch the extorter by "pretending" to have put up the $$$$
and tell the FBI/interpol/ISPs/PayPal/etc to watch the non-existent account
for incoming connections from the extorter ... and keep telling the
extorter the $$$ is there even if they can't seem to get their $$$

> I would really appreciate help in a few areas (primarily with certain
> provider contacts/intros) so we can execute our strategy (which I can't
> reveal here for obvious reasons).

most folks would like to see that you have done your "homework" too 
trying to stop incoming DDoS attacks ... aka, you need to able to provide 
them the necessary info for them to help you ...

run tcpdump and/or etherreal to capture the DDoS attacks

==========

---------------------------------------------------------------------------
ALL servers are under kinda harmless script kiddie attacks every second ...
- defend against those ( free ) ddos attacks scenarios
	#
	# if you cannot figure out how to stop these harmless probes, you're
	# gonna be in trouble when the DDoS attacks are intent on their attacks
	#
---------------------------------------------------------------------------

Simple things you should do BEFORE getting outside DDoS mitigation help, 
because they will probably ask and probably perform the same thing:

	- prepare a ( time, $$$, technical expertise ) budget to stop that DDoS attacks

	- get the received headers from the extorter's emails
	-----------------------------------------------------

	- get the ph# and email contacts of your ISP's security dept and 
	their peers/uplinks  .. similarly for the ph# of your local FBI/police dept

	- at a minimum, update patch all servers to today's patch releases
	------------------------------------------------------------------

	- "confirm" means use the FREE online test tools to test your servers
	- confirm your DNS servers are NOT open resolvers
	- confirm your SMTP servers are NOT open relays

	- use the NTP servers from your ISP if you're not sure if your NTPd is secure

	---------------------------------------------------------------------------
	- install IPtables + tarpit to defend against almost all TCP-based attacks
	-	imho, it is pointless to run iptables without tarpit support
	-	http://NetworkNightmare.net/Tarpits/#Install
	---------------------------------------------------------------------------

	- defending against UDP attacks requires you get help from your ISP
		- usually against DNS, NTP, NFS, SNMP, X11, etc

	- defending against ICMP attacks requires you get help from your ISP
  
	#
	# you cannot stop, block, prevent, mitigate UDP-based or ICMP-based
	# ddos attacks at your servers .. 
	#
	# the ddos attack damage ( wasting your time, $$$ and bandwidth ) 
	# is already done if it reaches your servers
	#

	- backup your user ( /home, /etc ) data ...
	- build a brand new server from latest distro and restore your data from backup

- if you don't have time for all this DDoS stuff.... and willing to do only 1 thing,
  install and learn iptables with tarpits on all your servers exposed to the internet

	- it's trivial or NOT trivial depending on your abilities
	- it is trivial ( few minutes/hours work ) for those folks familiar with IPtables

	http://IPtables-BlackList.net

- if you do decide to go with outside DDoS scrubbers, you definitely will need $$$

if you don't have the time but have the $$$, hire a couple different DDoS mitigators
to help protect your boxes during the DDoS attacks

	# sample list of DDoS mitigator appliances
	http://DDoS-Mitigator.net/Competitors

- few dozen other things to do to protect your servers from DDoS attacks

- follow up with those nanog contacts that have offered to help ...

- sit back and watch for new attacks that you haven't addressed

magic pixie dust
alvin
http://DDoS-Mitigator.net/Mitigation-Howto


From dennis at justipit.com  Fri Dec  4 01:44:46 2015
From: dennis at justipit.com (dennis)
Date: Thu, 03 Dec 2015 20:44:46 -0500
Subject: Ransom DDoS attack - need help!
Message-ID: <022qb1iu0n3e63lr770vwti3.1449193486189@email.android.com>


    

Many online business have learned how to deal with these threats. ?Just recently Protonmail hit the news and found out the hard way whether to pay or NOT. ?Have a quick read at the log of events for yourself.
http://arstechnica.com/security/2015/11/how-extorted-e-mail-provider-got-back-online-after-crippling-ddos-attack/
Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone

-------- Original message --------
From: Roland Dobbins <rdobbins at arbor.net> 
Date: 12/3/2015  3:10 PM  (GMT-05:00) 
To: NANOG <nanog at nanog.org> 
Subject: Re: Ransom DDoS attack - need help! 

On 3 Dec 2015, at 22:04, Josh Reynolds wrote:

> None of those names you just mentioned have made the international news.

Of course they have.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>


From mpalmer at hezmatt.org  Fri Dec  4 01:46:01 2015
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Fri, 4 Dec 2015 12:46:01 +1100
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
Message-ID: <20151204014601.GR14178@hezmatt.org>

On Thu, Dec 03, 2015 at 04:58:08PM -0800, Matthew Petach wrote:
> Or, if you feel that Cogent's stubborn insistence on partitioning the
> global v6 internet shouldn't be rewarded with money, pay someone *other*
> than cogent for IPv6 transit and also connect to HE.net; that way you
> still have access to cogent routes, but you also send a subtle economic
> nudge that says "hey cogent-- trying to get into the tier 1 club by
> partitioning the internet isn't a good path for long-term sucess".

Sadly, anyone you pay for transit to Cogent routes is going to be giving
Cogent their cut, so it's not a perfect signal to Cogent that we'd prefer to
have one IPv6ternet rather than two.  At the very least, configure the
routers to that any routes you learn via HE are preferenced, and announce
your routes as preferring HE, so that Cogent gets as little of the traffic
as possible.

- Matt


From lyndon at orthanc.ca  Fri Dec  4 01:54:43 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 3 Dec 2015 17:54:43 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <20151204010016.GA6303@Mail.DDoS-Mitigator.net>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <20151204010016.GA6303@Mail.DDoS-Mitigator.net>
Message-ID: <D06D9698-D4B0-44C6-B84A-84DDEF58C3F2@orthanc.ca>


On Dec 3, 2015, at 5:00 PM, alvin nanog <nanogml at Mail.DDoS-Mitigator.net> wrote:

> run tcpdump and/or etherreal to capture the DDoS attacks

<face palm> Of course! If we had only thought of this sooner! </face palm>

:-)

--lyndon

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

From jared at puck.nether.net  Fri Dec  4 02:02:04 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 3 Dec 2015 21:02:04 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
Message-ID: <378B3850-60D7-4B4D-9CD0-B20F609345C4@puck.nether.net>


> On Dec 2, 2015, at 8:38 PM, Ryan Rawdon <ryan at u13.net> wrote:
> 
> 
>> On Dec 1, 2015, at 1:23 PM, Max Tulyev <maxtul at netassist.ua> wrote:
>> 
>> Hi All,
>> 
>> we got an issue today that announces from Cogent don't reach Hurricane
>> Electric. HE support said that's a feature, not a bug.
>> 
>> So we have splitted Internet again?
>> 
>> I have to change at least one of my uplinks because of it, which one is
>> better to drop, HE or Cogent?
> 
> 
> There is another option, instead of choosing just one - perhaps establish a tunnel to HE from a L3 device that can do the tunneling in hardware?  You can get a HE tunnel for free, and they will speak BGP to you.
> 
> Alternatively, if you are on any IXes where HE is present - they will not only peer with you for v6, but announce a full table if you want it.

Looking at the most recent IPv6 data available at CAIDA you can see the customer cone size:

http://as-rank.caida.org/?data-selected-id=15

Be careful as the tool seems fragile when switching from the 2014-09-01 IPv6 dataset and trying to sort by options, it seems to switch back to IPv4 silently.

Prefixes and/or AS?es in customer cone are likely the best measure, but even there Cogent is 2x HE.net.  The only place where he.net leads is the transit degree with is likely distorted because of what you mention above, full tables, etc.

I find this data interesting and wish there was something more recent than 2014-09-01 to test with.  Perhaps I could do something with all these atlas credits I have.  (or someone could use them for me).

- Jared

From jared at puck.nether.net  Fri Dec  4 02:06:57 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 3 Dec 2015 21:06:57 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
Message-ID: <A50745CB-7C99-410B-BCC4-A45C0AF3C3BC@puck.nether.net>


> On Dec 3, 2015, at 7:58 PM, Matthew Petach <mpetach at netflight.com> wrote:
> 
> Or, if you feel that Cogent's stubborn insistence on
> partitioning the global v6 internet shouldn't be rewarded
> with money, pay someone *other* than cogent for
> IPv6 transit and also connect to HE.net; that way
> you still have access to cogent routes, but you also
> send a subtle economic nudge that says "hey cogent--
> trying to get into the tier 1 club by partitioning the
> internet isn't a good path for long-term sucess".
> 
> Note that this is purely my own opinion, not necessarily
> that of my employer, my friends, my family, or even my
> cat.  I asked my cat about cogent IPv6, and all I got was
> a ghostly hairball as a reply[0].

I would say that if you buy transit for IPv4, you should have congruent
relationship with IPv6 as well.  A network that does one and not the
other is clearly obvious to a skilled engineer.

Partitioning networks is bad, and I?d like to see this resolved myself.

	- Jared



From lyndon at orthanc.ca  Fri Dec  4 02:28:58 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 3 Dec 2015 18:28:58 -0800
Subject: Staring Down the Armada Collective
Message-ID: <9820E156-CD80-47E8-A574-6FA0FBA10014@orthanc.ca>

Typically, businesses hide from admitting they've been hit by drive-by attacks like Armada is trying to pull off. It has been interesting to see the public reaction from the post-Protonmail targets, many of whom are being very visible about 1) admitting they have been hit by the attacks, and 2) making it very clear the Armada crew can f*** right off as far as collecting ransom is concerned. (Also, 3) the amazing support from customers who understand why we are working on putting up defences instead of just paying, and therefore put up with the inevitable downtime as we reconfigure sometimes large chunks of our networks.)

The money asked for was a pittance (around USD$6K) for the attacks I'm personally aware of.  The targeted were willing to spend far in excess of that to deploy the necessary wall of DDoS protection to keep their services running.  If they didn't have it there, already.

What does that say for the business model of the botnet handlers?  They can't up their ransom demands, because nobody is paying at the current rates.  And they can't lower them, for the same reason.  And if they change their targets to sites than might potentially pay a few hundred dollars at best, those sites will just shut down anyway.

Are we perhaps, finally, reaching the cusp where everyone has realized that if we all, collectively, tell the rodents to f*** off, they just might?

Happy Holidays!

--lyndon

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

From nanogml at Mail.DDoS-Mitigator.net  Fri Dec  4 02:34:42 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Thu, 3 Dec 2015 18:34:42 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <D06D9698-D4B0-44C6-B84A-84DDEF58C3F2@orthanc.ca>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <20151204010016.GA6303@Mail.DDoS-Mitigator.net>
 <D06D9698-D4B0-44C6-B84A-84DDEF58C3F2@orthanc.ca>
Message-ID: <20151204023442.GA9156@Mail.DDoS-Mitigator.net>


hi lyndon

On 12/03/15 at 05:54pm, Lyndon Nerenberg wrote:
> On Dec 3, 2015, at 5:00 PM, alvin nanog <nanogml at Mail.DDoS-Mitigator.net> wrote:
> > run tcpdump and/or etherreal to capture the DDoS attacks
>
> <face palm> Of course! If we had only thought of this sooner! </face palm>
> :-)

yupperz.. the problem is, capturing is nice, you have all this data ... now what ,,

all that tcpdump jibberish needs to be converted and presented in a format
suitable for the bean counters to allocate $$$ to mitigate and minimize the
effects of the "free n hopefully relatively harmless" DDoS attacks occuring
every second

lets assume required services are properly configured and excluded
        - acl's only for your own dns queries
        - ssh only from specific ip#
        - ntp to/from your isp

lets assume you allow incoming ssh only from w.x.y.z ... all other connections are DoS attacks
  tcpdump -n -l ! host w.x.y.z and port 22

lets assume mail is your mail server .. all traffic NOT on port 25 are DoS attacks
  tcpdump -n -l host mail.example.com and ! port 25

lets assume www is your web server .. all traffic NOT on port 80 are DoS attacks
  tcpdump -n -l host mail.example.com and ! port 80

if you are running all the services ( mail + apache + mysql ) on one servr
the remaining tcp connections are DoS attacks
  tcpdump -n -l host mail.example.com and \( ! port 80 and ! port 80 and ! port 3306 \)

lets assume dns is your dns server .. i consider all tcp traffic from outside as DoS attacks
  tcpdump -n -l tcp host dns.example.com

to see possible udp attacks .. don't forget to exclude your own DNS and NTP queries
  tcpdump -n -l udp

to see possible icmp attacks
  tcpdump -n -l icmp

too many gazillions options makes the world go round n round ...
- where does it end :-) ... it doesn't ...

if you get a screenful of data flying by of stuff you don't recognize,
you're probably under light DDoS attacks

magic pixie dust
alvin
http://DDoS-Mitigator.net/cgi-bin/IPtables-GUI.pl


From mpetach at netflight.com  Fri Dec  4 02:42:59 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 3 Dec 2015 18:42:59 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <378B3850-60D7-4B4D-9CD0-B20F609345C4@puck.nether.net>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
 <378B3850-60D7-4B4D-9CD0-B20F609345C4@puck.nether.net>
Message-ID: <CAEmG1=piUoA7=4C6t+X3ye++76ZZJCbm=nk26d4n6_88J6KkCw@mail.gmail.com>

On Thu, Dec 3, 2015 at 6:02 PM, Jared Mauch <jared at puck.nether.net> wrote:
>
> Looking at the most recent IPv6 data available at CAIDA you can see the customer cone size:
>
> http://as-rank.caida.org/?data-selected-id=15
>
> Be careful as the tool seems fragile when switching from the 2014-09-01 IPv6 dataset and trying to sort by options, it seems to switch back to IPv4 silently.
>
> Prefixes and/or AS?es in customer cone are likely the best measure, but even there Cogent is 2x HE.net.  The only place where he.net leads is the transit degree with is likely distorted because of what you mention above, full tables, etc.
>
> I find this data interesting and wish there was something more recent than 2014-09-01 to test with.  Perhaps I could do something with all these atlas credits I have.  (or someone could use them for me).
>
> - Jared


Note their analysis is horribly flawed,
as it suffers from a 32-bit limitation
for counting IPv6 addresses.

I'd love to see them fix their code
and then re-run the analysis.

Matt

From rdobbins at arbor.net  Fri Dec  4 04:09:02 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 04 Dec 2015 11:09:02 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <20151204023442.GA9156@Mail.DDoS-Mitigator.net>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <20151204010016.GA6303@Mail.DDoS-Mitigator.net>
 <D06D9698-D4B0-44C6-B84A-84DDEF58C3F2@orthanc.ca>
 <20151204023442.GA9156@Mail.DDoS-Mitigator.net>
Message-ID: <FC4ED1CF-7A44-4E8C-B3D6-26E38C12BC42@arbor.net>

On 4 Dec 2015, at 9:34, alvin nanog wrote:

> all that tcpdump jibberish

Is entirely unnecessary, as well as being completely impractical on a 
network of any size.

Reasonable network access policies for the entities under attack plus 
flow telemetry collection/analysis, S/RTBH, and/or flowspec are a good 
start, along with this:

<http://www.merit.edu/mail.archives/nanog/msg03776.html>

This business of attempting to use packet captures for everything is the 
equivalent of your doctor attempting to diagnose the reason you're 
running a fever by using an electron microscope.

Start with the BCPs, then move to the macroanalytical.  Only dip into 
the microanalytical when required, and even then, do so very 
selectively.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Fri Dec  4 04:10:56 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 04 Dec 2015 11:10:56 +0700
Subject: Staring Down the Armada Collective
In-Reply-To: <9820E156-CD80-47E8-A574-6FA0FBA10014@orthanc.ca>
References: <9820E156-CD80-47E8-A574-6FA0FBA10014@orthanc.ca>
Message-ID: <7D0EE074-7C68-425A-8058-04BB1ADA76D8@arbor.net>

On 4 Dec 2015, at 9:28, Lyndon Nerenberg wrote:

> Are we perhaps, finally, reaching the cusp where everyone has realized 
> that if we all, collectively, tell the rodents to f*** off, they just 
> might?

By my very rough and subjective guesstimate, extortion is the motivation 
behind ~15% of all DDoS attacks, FYI.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From lyndon at orthanc.ca  Fri Dec  4 05:14:39 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 3 Dec 2015 21:14:39 -0800
Subject: Staring Down the Armada Collective
In-Reply-To: <9820E156-CD80-47E8-A574-6FA0FBA10014@orthanc.ca>
References: <9820E156-CD80-47E8-A574-6FA0FBA10014@orthanc.ca>
Message-ID: <4C4593EF-5E55-495E-944A-46E4D9DAAD36@orthanc.ca>


On Dec 3, 2015, at 6:28 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> Are we perhaps, finally, reaching the cusp where everyone has realized that if we all, collectively, tell the rodents to f*** off, they just might?

I should also mention that, despite their bluster, they can't keep it up for more than half an hour.

By then, the upstream networks have figured it out and have null routed anything of consequence - far upstream.  Meanwhile, back haul your traffic in via a private network and they won't be able to do shit to you. (E.g. the standard Cloudflare model.)

They are not as smart as they make themselves out to be.  Don't let fear drive your decisions.

--lyndon

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

From lyndon at orthanc.ca  Fri Dec  4 05:44:14 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 3 Dec 2015 21:44:14 -0800
Subject: Staring Down the Armada Collective
In-Reply-To: <4C4593EF-5E55-495E-944A-46E4D9DAAD36@orthanc.ca>
References: <9820E156-CD80-47E8-A574-6FA0FBA10014@orthanc.ca>
 <4C4593EF-5E55-495E-944A-46E4D9DAAD36@orthanc.ca>
Message-ID: <D179B663-3950-4FE5-B465-D58E0BAE72F0@orthanc.ca>


On Dec 3, 2015, at 9:14 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> I should also mention that, despite their bluster, they can't keep it up for more than half an hour.

The mailing list has been quiet. All step forward who are scared to say "me too" on account of Armada.

--lyndon

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

From dennis at justipit.com  Fri Dec  4 13:21:01 2015
From: dennis at justipit.com (dennis)
Date: Fri, 04 Dec 2015 08:21:01 -0500
Subject: Staring Down the Armada Collective
Message-ID: <91fs50ys396vkhf8jawk7qdj.1449233563218@email.android.com>


    

I agree Protonmail took a stance and believe many others can learn from their experience. But let's not over simplify the problem. According to their blogs the attacks were over 100G and went on for hours at a time over several days. ?Attacks can go on for days and months. ?Protonmail found themselves up against varying attack tactics and ultimately ?took a defense in depth approach to mitigate the attack.?
Null routing original ip completes the attack, game over , sever is down. Granted this can help prevent colateral damages. ?Combined with proxies can work well for dns redirect to route through cloud scrubbing but these solutions can add latency and impact legitimate traffic also. With redirection there is also the complexity of TLS/SSL (certificate management, ?privacy, etc.) And then you must also consider ip based (non proxied) targets. ? These dns redirect/proxy methods don't handle ip based attack targets and cause the need to swing ip prefixes via bgp. Bottom line, attackers can impact the infrastructure by varying their tactics and the approach should be well thought out and multilayered.


Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone

-------- Original message --------
From: Lyndon Nerenberg <lyndon at orthanc.ca> 
Date: 12/4/2015  12:14 AM  (GMT-05:00) 
To: North American Network Operators' Group <nanog at nanog.org> 
Subject: Re: Staring Down the Armada Collective 


On Dec 3, 2015, at 6:28 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> Are we perhaps, finally, reaching the cusp where everyone has realized that if we all, collectively, tell the rodents to f*** off, they just might?

I should also mention that, despite their bluster, they can't keep it up for more than half an hour.

By then, the upstream networks have figured it out and have null routed anything of consequence - far upstream.? Meanwhile, back haul your traffic in via a private network and they won't be able to do shit to you. (E.g. the standard Cloudflare model.)

They are not as smart as they make themselves out to be.? Don't let fear drive your decisions.

--lyndon


From nanogml at Mail.DDoS-Mitigator.net  Fri Dec  4 14:15:22 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Fri, 4 Dec 2015 06:15:22 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <FC4ED1CF-7A44-4E8C-B3D6-26E38C12BC42@arbor.net>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <20151204010016.GA6303@Mail.DDoS-Mitigator.net>
 <D06D9698-D4B0-44C6-B84A-84DDEF58C3F2@orthanc.ca>
 <20151204023442.GA9156@Mail.DDoS-Mitigator.net>
 <FC4ED1CF-7A44-4E8C-B3D6-26E38C12BC42@arbor.net>
Message-ID: <20151204141522.GA26153@Mail.DDoS-Mitigator.net>


hi ya roland

On 12/04/15 at 11:09am, Roland Dobbins wrote:
> On 4 Dec 2015, at 9:34, alvin nanog wrote:
> >all that tcpdump jibberish
> 
> Is entirely unnecessary, as well as being completely impractical on a
> network of any size.

up to a point, probing around at the packet level is un-necessary depending
on what one is looking for as the end result

> Reasonable network access policies for the entities under attack plus flow
> telemetry collection/analysis, S/RTBH, and/or flowspec are a good start,
> along with this:

flows may address some of the DDoS issues but might not cover all
the various DDoS attacks and mitigation options and still stay within the
victims possibly non-existent DDoS mitigation budgets

> This business of attempting to use packet captures for everything is the
> equivalent of your doctor attempting to diagnose the reason you're running a
> fever by using an electron microscope.

sometimes, one does need to be able to crawl, before walking, before
running track vs running marathons or find someone that can run for you

in the case of ddos mitigation, no one solution can mitigate against all
the possible various attacks... mitigation is a multi-layered solutions

- who-what-when-where-how-why-etc:

- one does need to know what servers, ports and hw is being attacked

  it makes DDoS mitigation a lot easier if you know what is under attack
  and orders of magnitude less expensive to mitigate

- one does need to know who is attacking

  if one cannot defend against low level script kiddie ddos attacks, 
  it's unlikely one will survive a ddos attacks from a more skilled attacker
  determined to take out a server or break in etc

  if you can and have defended against all the basic script kiddie ddos attacks,
  then it might make it easier to find the next set of the various
  ddos mitigation options you need to take 

- one does need to know how often, what time, they are attacking

  if they are attacking after hours, some folks might not care compared
  to they attacking during regular business hours

- one does need to know how much traffic the attacks are costing you
  in terms of time and loss of productivity due to wasted bandwidth

  even at 10% of your bandwidth used up by useless DDoS traffic is still
  noticibly annoying if you were to looking to increase network performance

- nobody can really say why they are attacking, other than are you
  a low level fruit for easy picking or a target'd victim for
  many reasons ( paid ransom before, high profile servers, a bank, 
  govt servers, etc ) .. pay once and all the other DDoS ransom attackers
  will come knocking to collect their share

> Start with the BCPs, then move to the macroanalytical.  Only dip into the
> microanalytical when required, and even then, do so very selectively.

yup... selective and escalate the migitation process and procedure

magix pixie dust
alvin

From amitchell at isipp.com  Fri Dec  4 14:55:36 2015
From: amitchell at isipp.com (Anne Mitchell)
Date: Fri, 4 Dec 2015 07:55:36 -0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <mailman.1.1449230401.20053.nanog@nanog.org>
References: <mailman.1.1449230401.20053.nanog@nanog.org>
Message-ID: <9064E1A5-6100-4669-81D2-702D1F0B4B78@isipp.com>

Sorry this is so late, I get NANOG in Digest Mode...

> I would really appreciate help in a few areas (primarily with certain
> provider contacts/intros) so we can execute our strategy (which I can't
> reveal here for obvious reasons). If you email me off-list with a
> name/email that you've previously used on-list, I will reply from my real
> email.
> 
> Alternatively, if you can post your experiences on-list with large scale
> high profile ransom DDoS attacks, I'd really appreciate it!

Please contact me offlist, and I will introduce you to the person who says the below - they are from $ENORMOUS-ESP, and were deeply involved in the efforts during last year's rounds of ransom DDoSs which saw many different targets coordinating in fending off the attacks (and working with the FBI).  The basecamp group to which he refers is the group of all of the different NOC and architect folks from the various companies, who strategized together, and all of their info is still there.  I'm familiar with this all as I was part of the coordination efforts, as so many of the targets also happened to be customers of ours and, you know, lawyer. ;-)

He says:

"I'm happy to invite him to the basecamp if he wants access, just need his email.

Otherwise, feel free to share with him that others ended up using prolexic OR whatever the other large provider is out there. that seems to be the universal solution if they don't want to buy gear and roll their own solution. Amazon and Google cloud environments aren't impervious from this stuff, but they are getting better, and using some of the same technology."

---

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification
Is Email You Send Being Junked? Get to the Inbox Using Your Own Mail System!
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

"Email marketing is the one place where it's better to ask permission than forgiveness." - Me

Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Ret. Professor of Law, Lincoln Law School of San Jose
303-731-2121 | amitchell at isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell



From pauldotwall at gmail.com  Fri Dec  4 17:03:37 2015
From: pauldotwall at gmail.com (Paul WALL)
Date: Fri, 4 Dec 2015 12:03:37 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAAGWaEf1Sq1EVN1Axo6zzp_r7oWx869P0U1nFwnVmoPMywY8tw@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAL9jLabJ+MrNMucWyE6n5_toikp6Ehio3dM6Wb-34RgYrP3KvQ@mail.gmail.com>
 <CALA5tJJ=fWGBRisd8=myYjHFx7=rtfUaWGLE1r9RmaDLjobBYw@mail.gmail.com>
 <20151201200140.GA22343@drscott.swordarmor.fr>
 <CAAGWaEf1Sq1EVN1Axo6zzp_r7oWx869P0U1nFwnVmoPMywY8tw@mail.gmail.com>
Message-ID: <CAHnQ7eLDAtp36e+XGF9A1Sv6ywH2WGJg=Afdo+C=mOUcfq0HGQ@mail.gmail.com>

On Tue, Dec 1, 2015 at 7:34 PM, Jeff Walter <jwalter at weebly.com> wrote:
> That cake will haunt NANOG until the end of time.
>
> On Tue, Dec 1, 2015 at 12:01 PM, Alarig Le Lay <alarig at swordarmor.fr> wrote:
>
>> On Tue Dec  1 14:39:14 2015, Andrew Kirch wrote:
>> > Might I suggest cake pleas?
>>
>> You mean
>>
>> http://www.datacenterknowledge.com/wp-content/uploads/2009/10/Hurricane-Cake.jpg
>> ?
>>


i mean

"Different companies have different personalities, and the vast
majority work through their relationships fine in the interest of the
public and the industry.  But there are always a few companies that
like to act out on the public stage to achieve their business
objectives."

                  --Mike Leber, 6/29/15 Telecom Ramblings

along with the bad spelling, we have short memories.  peering is about
mutual benefits. when benefits aren't there peering doesn't happen.
going to nanog and yelling about peering by saying that you're a
victim isn't a mutual benefit last i checked. their lack of peering
doesn't demand another moment of our attention. choose wisely.

Drive slow,
Paul WALL

From cscora at apnic.net  Fri Dec  4 18:11:13 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 5 Dec 2015 04:11:13 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201512041811.tB4IBDj8031213@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 05 Dec, 2015

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

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

BGP routing table entries examined:                              571357
    Prefixes after maximum aggregation (per Origin AS):          212309
    Deaggregation factor:                                          2.69
    Unique aggregates announced (without unneeded subnets):      278305
Total ASes present in the Internet Routing Table:                 52177
    Prefixes per ASN:                                             10.95
Origin-only ASes present in the Internet Routing Table:           36655
Origin ASes announcing only one prefix:                           15946
Transit ASes present in the Internet Routing Table:                6383
Transit-only ASes present in the Internet Routing Table:            165
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      35
    Max AS path prepend of ASN ( 55644)                              31
Prefixes from unregistered ASNs in the Routing Table:              1028
    Unregistered ASNs in the Routing Table:                         367
Number of 32-bit ASNs allocated by the RIRs:                      11965
Number of 32-bit ASNs visible in the Routing Table:                9139
Prefixes from 32-bit ASNs in the Routing Table:                   34775
Number of bogon 32-bit ASNs visible in the Routing Table:            14
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            421
Number of addresses announced to Internet:                   2802085056
    Equivalent to 167 /8s, 4 /16s and 108 /24s
    Percentage of available address space announced:               75.7
    Percentage of allocated address space announced:               75.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.8
Total number of prefixes smaller than registry allocations:      188133

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

Prefixes being announced by APNIC Region ASes:                   144487
    Total APNIC prefixes after maximum aggregation:               39866
    APNIC Deaggregation factor:                                    3.62
Prefixes being announced from the APNIC address blocks:          152684
    Unique aggregates announced from the APNIC address blocks:    60777
APNIC Region origin ASes present in the Internet Routing Table:    5113
    APNIC Prefixes per ASN:                                       29.86
APNIC Region origin ASes announcing only one prefix:               1190
APNIC Region transit ASes present in the Internet Routing Table:    895
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1719
Number of APNIC addresses announced to Internet:              756067456
    Equivalent to 45 /8s, 16 /16s and 172 /24s
    Percentage of available APNIC address space announced:         88.4

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:                    180946
    Total ARIN prefixes after maximum aggregation:                88978
    ARIN Deaggregation factor:                                     2.03
Prefixes being announced from the ARIN address blocks:           184304
    Unique aggregates announced from the ARIN address blocks:     86632
ARIN Region origin ASes present in the Internet Routing Table:    16512
    ARIN Prefixes per ASN:                                        11.16
ARIN Region origin ASes announcing only one prefix:                5973
ARIN Region transit ASes present in the Internet Routing Table:    1717
Average ARIN Region AS path length visible:                         3.7
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:     859
Number of ARIN addresses announced to Internet:              1102523072
    Equivalent to 65 /8s, 183 /16s and 42 /24s
    Percentage of available ARIN address space announced:          58.3

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, 64198-64296, 393216-395164
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:                    137500
    Total RIPE prefixes after maximum aggregation:                68502
    RIPE Deaggregation factor:                                     2.01
Prefixes being announced from the RIPE address blocks:           145455
    Unique aggregates announced from the RIPE address blocks:     90245
RIPE Region origin ASes present in the Internet Routing Table:    18032
    RIPE Prefixes per ASN:                                         8.07
RIPE Region origin ASes announcing only one prefix:                7990
RIPE Region transit ASes present in the Internet Routing Table:    2987
Average RIPE Region AS path length visible:                         4.8
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4264
Number of RIPE addresses announced to Internet:               701905536
    Equivalent to 41 /8s, 214 /16s and 58 /24s
    Percentage of available RIPE address space announced:         102.0

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-204287
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:                   60468
    Total LACNIC prefixes after maximum aggregation:              11827
    LACNIC Deaggregation factor:                                   5.11
Prefixes being announced from the LACNIC address blocks:          73119
    Unique aggregates announced from the LACNIC address blocks:   34095
LACNIC Region origin ASes present in the Internet Routing Table:   2455
    LACNIC Prefixes per ASN:                                      29.78
LACNIC Region origin ASes announcing only one prefix:               599
LACNIC Region transit ASes present in the Internet Routing Table:   544
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        22
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2126
Number of LACNIC addresses announced to Internet:             170315776
    Equivalent to 10 /8s, 38 /16s and 208 /24s
    Percentage of available LACNIC address space announced:       101.5

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:                  13096
    Total AfriNIC prefixes after maximum aggregation:              3095
    AfriNIC Deaggregation factor:                                  4.23
Prefixes being announced from the AfriNIC address blocks:         15374
    Unique aggregates announced from the AfriNIC address blocks:   6200
AfriNIC Region origin ASes present in the Internet Routing Table:   734
    AfriNIC Prefixes per ASN:                                     20.95
AfriNIC Region origin ASes announcing only one prefix:              194
AfriNIC Region transit ASes present in the Internet Routing Table:  164
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       20
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  171
Number of AfriNIC addresses announced to Internet:             70910720
    Equivalent to 4 /8s, 58 /16s and 3 /24s
    Percentage of available AfriNIC address space announced:       70.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
 4538     5502       4192          75   China Education and Research 
 7545     3019        346         154   TPG Telecom Limited
 4766     2994      11135         990   Korea Telecom
17974     2725        914          96   PT Telekomunikasi Indonesia
 9829     2214       1413         315   National Internet Backbone
 4755     2065        431         234   TATA Communications formerly 
 9808     1684       8639          18   Guangdong Mobile Communicatio
 4808     1568       2273         500   CNCGROUP IP network China169 
 9583     1519        163          85   Sify Limited
 9498     1401        335         112   BHARTI Airtel Ltd.

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

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
22773     3244       2964         143   Cox Communications Inc.
 3356     2574      10691         525   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
18566     2213        394         277   MegaPath Corporation
20115     1889       1897         401   Charter Communications
 6983     1697        849         238   EarthLink, Inc.
30036     1656        331         355   Mediacom Communications Corp
 4323     1578       1021         396   tw telecom holdings, inc.
  209     1486       4327        1235   Qwest Communications Company,
  701     1392      11415         664   MCI Communications Services, 

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
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2241        888        1608   Akamai International B.V.
34984     1912        319         410   TELLCOM ILETISIM HIZMETLERI A
 8551     1241        376          44   Bezeq International-Ltd
 8402     1185        544          15   OJSC "Vimpelcom"
13188     1075         97          79   TOV "Bank-Inform"
12479     1051        967          77   France Telecom Espana SA
31148     1041         47          41   Freenet Ltd.
 9198      958        349          25   JSC Kazakhtelecom
 6830      898       2712         468   Liberty Global Operations B.V

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3407        540         157   Telmex Colombia S.A.
 8151     2113       3347         500   Uninet S.A. de C.V.
 7303     1580        941         241   Telecom Argentina S.A.
 6503     1386        437          57   Axtel, S.A.B. de C.V.
28573     1261       2164         119   NET Servi?os de Comunica??o S
11830     1094        364          24   Instituto Costarricense de El
 6147     1039        376          34   Telefonica del Peru S.A.A.
26615     1000       2325          34   Tim Celular S.A.
 7738      994       1882          41   Telemar Norte Leste S.A.
 3816      970        459         186   COLOMBIA TELECOMUNICACIONES S

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

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1117       1470          14   TE-AS
24863     1038        409          38   Link Egypt (Link.NET)
37611      577         39          42   Afrihost-Brevis Computer Serv
36903      522        263         102   Office National des Postes et
36992      427       1229          31   ETISALAT MISR
37492      323        192          74   Orange Tunisie
29571      244         21          11   Cote d'Ivoire Telecom
 3741      221        837         183   Internet Solutions
24835      201        146          12   Vodafone Data
15706      171         32           6   Sudatel (Sudan Telecom Co. Lt

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
 4538     5502       4192          75   China Education and Research 
10620     3407        540         157   Telmex Colombia S.A.
22773     3244       2964         143   Cox Communications Inc.
 7545     3019        346         154   TPG Telecom Limited
 4766     2994      11135         990   Korea Telecom
17974     2725        914          96   PT Telekomunikasi Indonesia
 3356     2574      10691         525   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2241        888        1608   Akamai International B.V.

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

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

  ASN   No of nets  Net Savings Description
10620      3407        3250      Telmex Colombia S.A.
22773      3244        3101      Cox Communications Inc.
 7545      3019        2865      TPG Telecom Limited
17974      2725        2629      PT Telekomunikasi Indonesia
 6389      2508        2466      BellSouth.net Inc.
39891      2473        2466      SaudiNet, Saudi Telecom Compa
 3356      2574        2049      Level 3 Communications, Inc.
 4766      2994        2004      Korea Telecom
18566      2213        1936      MegaPath Corporation
 9829      2214        1899      National Internet Backbone

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

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

Bad AS  Designation  Network              Transit AS  Description
 8655   UNALLOCATED  1.3.3.0/24            4134       No.31,Jin-rong Stree
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
47092   UNALLOCATED  8.8.204.0/24         16410       The Reynolds and Rey
53506   UNALLOCATED  8.17.102.0/23         3356       Level 3 Communicatio
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
18985   UNALLOCATED  8.21.68.0/22          3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I

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

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

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
31.170.96.0/23       23456     32bit Transition AS
31.217.248.0/21      44902     COVAGE NETWORKS SASU
37.46.8.0/23         13768     Peer 1 Network (USA) Inc.
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.

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:11      /10:36      /11:98      /12:264     
/13:507     /14:1009    /15:1765    /16:12937   /17:7374    /18:12563   
/19:25583   /20:37612   /21:39750   /22:62943   /23:54469   /24:312855  
/25:541     /26:580     /27:382     /28:16      /29:16      /30:9       
/31:0       /32:21      

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

  ASN   No of nets  Total ann.   Description
22773     2435          3244      Cox Communications Inc.
39891     2432          2473      SaudiNet, Saudi Telecom Compa
18566     2115          2213      MegaPath Corporation
 6389     1553          2508      BellSouth.net Inc.
30036     1473          1656      Mediacom Communications Corp
 6983     1344          1697      EarthLink, Inc.
10620     1285          3407      Telmex Colombia S.A.
34984     1209          1912      TELLCOM ILETISIM HIZMETLERI A
11492     1134          1219      CABLE ONE, INC.
31148      960          1041      Freenet Ltd.

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

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

   1:1645      2:701       4:100       5:2037      6:25        8:1409   
  12:1803     13:28       14:1550     15:23       16:2        17:57     
  18:19       20:48       23:1323     24:1740     27:2129     31:1681   
  32:54       33:2        34:4        35:5        36:192      37:2223   
  38:1122     39:22       40:74       41:2894     42:365      43:1615   
  44:36       45:1520     46:2338     47:63       49:1028     50:816    
  52:33       54:93       55:7        56:8        57:44       58:1414   
  59:822      60:514      61:1762     62:1448     63:1918     64:4408   
  65:2189     66:4032     67:2138     68:1078     69:3244     70:1035   
  71:463      72:1991     74:2548     75:356      76:407      77:1382   
  78:1259     79:803      80:1339     81:1356     82:845      83:650    
  84:780      85:1482     86:454      87:1042     88:540      89:1900   
  90:167      91:5988     92:861      93:2302     94:2179     95:2236   
  96:473      97:352      98:909      99:45      100:79      101:851    
 103:8953    104:2188    105:73      106:358     107:1136    108:635    
 109:2122    110:1223    111:1519    112:859     113:1101    114:892    
 115:1512    116:1472    117:1347    118:1976    119:1494    120:506    
 121:1155    122:2129    123:1853    124:1563    125:1736    128:707    
 129:369     130:389     131:1272    132:589     133:169     134:451    
 135:119     136:344     137:248     138:1539    139:190     140:247    
 141:456     142:638     143:727     144:571     145:147     146:798    
 147:612     148:1288    149:446     150:621     151:811     152:569    
 153:271     154:473     155:906     156:453     157:446     158:342    
 159:1057    160:420     161:674     162:2209    163:493     164:706    
 165:1086    166:312     167:889     168:1331    169:545     170:1502   
 171:261     172:357     173:1557    174:705     175:759     176:1511   
 177:3933    178:2341    179:1076    180:2022    181:1598    182:1874   
 183:656     184:770     185:5035    186:3049    187:1860    188:2075   
 189:1706    190:7525    191:1211    192:8713    193:5709    194:4311   
 195:3696    196:2238    197:1109    198:5484    199:5545    200:6682   
 201:3504    202:9848    203:9243    204:4567    205:2746    206:3032   
 207:3022    208:4004    209:3968    210:3748    211:2008    212:2684   
 213:2179    214:842     215:73      216:5763    217:1879    218:743    
 219:542     220:1631    221:808     222:639     223:861    

End of report

From theghost101 at gmail.com  Fri Dec  4 09:03:54 2015
From: theghost101 at gmail.com (Danijel Starman)
Date: Fri, 4 Dec 2015 10:03:54 +0100
Subject: Netflow parameters and data that comes from CDNs
In-Reply-To: <565E32F3.3010303@vaxination.ca>
References: <565E32F3.3010303@vaxination.ca>
Message-ID: <CADXh1J5UhO+1O_U7a0ZzzpHdQbHAEcNASN1X9B+fn9MD3CW7Nw@mail.gmail.com>

Hi,


> And in fictitious case of jf_music.com hiring Akamai, would the Akamai
> server(s)  have a dedicated IP for jf_music in each city (or re-use same
> IP via anycast)  or would the CDN servers use the same IP address to
> deliver multiple services from totally different content providers ?
>

Generally the CDN provider would have a cluster of machines/IP's on each of
their locations that are reused by different customers and are probably
divided by service/content. They would probably be stable but can vary due
to service improvements or disruptions. As it was noted Akamai is putting
servers into the ISP's, I don't think that others like L3 or Limelight do
it (or seen evidence that they do).

From frnkblk at iname.com  Fri Dec  4 22:02:38 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 4 Dec 2015 16:02:38 -0600
Subject: eBay contact that deals with IPv6
Message-ID: <004201d12edf$7d519ba0$77f4d2e0$@iname.com>

I'm looking for an eBay network engineer to contact me off-list that can dig
into an IPv6 performance issue. I started monitoring ipv6.ebay.com a week or
two ago and the site times out (10 second timer) regularly.  The last seven
days indicate it's been timing out about one-third of the time.

Frank


From randy at psg.com  Sat Dec  5 01:43:22 2015
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Dec 2015 10:43:22 +0900
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
Message-ID: <m2lh99zn45.wl%randy@psg.com>

> Or, if you feel that Cogent's stubborn insistence on partitioning the
> global v6 internet

if A does not peer with B,
then for all A and B
they are evil partitioners?

can we lower the rhetoric?

randy

From mpetach at netflight.com  Sat Dec  5 02:08:27 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 4 Dec 2015 18:08:27 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <m2lh99zn45.wl%randy@psg.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
Message-ID: <CAEmG1=rc8HHAG6tfYtkuHi4J7vDdwEQ+ETojn0W5X0HD+8uzUA@mail.gmail.com>

On Fri, Dec 4, 2015 at 5:43 PM, Randy Bush <randy at psg.com> wrote:
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>> global v6 internet
>
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
>
> can we lower the rhetoric?
>
> randy
>



I thought we already had this conversation
a few years ago, but my memory is short,
so we can have it again.   ^_^;

No, it's not an issue of A not peering
with B, it's A selling "internet transit"
for a known subset of the internet
rather than the whole kit and kaboodle.

I rather think that if you're going to put
a sign out saying "we sell internet transit",
it *is* incumbent on you to make a best
effort to ensure you have as complete
a copy of the full routing table as possible;
otherwise, it's potentially a fraudulent claim.
At least, that's what it would be in any other
industry if you sold something under a particular
name while knowing the whole time it didn't
fit the definition of the product.

I know in the service station industry,
I'd get in a lot of trouble if I sold "premium
unleaded gasoline" that was really just the
same as the "regular unleaded" with a
different label.  It's fortunate that we're
not a regulated industry, so there's nobody
checking up on us to make sure that if
we sell "internet transit", it's not really
"internet transit, minus level3, sprint, ATT,
and a bunch of other networks that won't
get your prefixes from me".

It all boils down to 'caveat emptor' -- not all
uses of the word "internet transit" mean the
same thing--check carefully when buying, and
make sure you make informed decisions.

Matt
(now with 50% less rhetoric!)

From baldur.norddahl at gmail.com  Sat Dec  5 02:09:07 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sat, 5 Dec 2015 03:09:07 +0100
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <m2lh99zn45.wl%randy@psg.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
Message-ID: <CAPkb-7B4E8dojyNBjc4_e8q-GFp=ihY4d1OV0227+xi-shv8oA@mail.gmail.com>

On 5 December 2015 at 02:43, Randy Bush <randy at psg.com> wrote:

> > Or, if you feel that Cogent's stubborn insistence on partitioning the
> > global v6 internet
>
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
>
> can we lower the rhetoric?
>

They both loses on this. In fact anyone claiming tier 1 status loses here,
because this illustrates why you can never be single homed on a tier 1
network. These guys simply do not have the full internet.

Regards,

Baldur

From contact at winterei.se  Sat Dec  5 02:43:50 2015
From: contact at winterei.se (Paul S.)
Date: Sat, 5 Dec 2015 11:43:50 +0900
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAPkb-7B4E8dojyNBjc4_e8q-GFp=ihY4d1OV0227+xi-shv8oA@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
 <CAPkb-7B4E8dojyNBjc4_e8q-GFp=ihY4d1OV0227+xi-shv8oA@mail.gmail.com>
Message-ID: <56624F66.3070600@winterei.se>

It is worth noting that HE indeed provides the full view, it's the other 
side that has an issue.

(Since HE isn't really a tier 1, their transit relationships with Telia 
and other carriers "save" them)

Cogent -> HE dies with unreachable on the first hop though, and that's 
an issue for Cogent customers.

On 12/5/2015 11:09 AM, Baldur Norddahl wrote:
> On 5 December 2015 at 02:43, Randy Bush <randy at psg.com> wrote:
>
>>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>>> global v6 internet
>> if A does not peer with B,
>> then for all A and B
>> they are evil partitioners?
>>
>> can we lower the rhetoric?
>>
> They both loses on this. In fact anyone claiming tier 1 status loses here,
> because this illustrates why you can never be single homed on a tier 1
> network. These guys simply do not have the full internet.
>
> Regards,
>
> Baldur


From josh at kyneticwifi.com  Sat Dec  5 02:47:35 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Fri, 4 Dec 2015 20:47:35 -0600
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <56624F66.3070600@winterei.se>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
 <CAPkb-7B4E8dojyNBjc4_e8q-GFp=ihY4d1OV0227+xi-shv8oA@mail.gmail.com>
 <56624F66.3070600@winterei.se>
Message-ID: <CAC6=tfbA4smKr-mKmjcy_4COXoZbS0ES5+53J57q8qcPfWOBbQ@mail.gmail.com>

Is "tier" even a thing anymore?
On Dec 4, 2015 8:46 PM, "Paul S." <contact at winterei.se> wrote:

> It is worth noting that HE indeed provides the full view, it's the other
> side that has an issue.
>
> (Since HE isn't really a tier 1, their transit relationships with Telia
> and other carriers "save" them)
>
> Cogent -> HE dies with unreachable on the first hop though, and that's an
> issue for Cogent customers.
>
> On 12/5/2015 11:09 AM, Baldur Norddahl wrote:
>
>> On 5 December 2015 at 02:43, Randy Bush <randy at psg.com> wrote:
>>
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>>>> global v6 internet
>>>>
>>> if A does not peer with B,
>>> then for all A and B
>>> they are evil partitioners?
>>>
>>> can we lower the rhetoric?
>>>
>>> They both loses on this. In fact anyone claiming tier 1 status loses
>> here,
>> because this illustrates why you can never be single homed on a tier 1
>> network. These guys simply do not have the full internet.
>>
>> Regards,
>>
>> Baldur
>>
>
>

From contact at winterei.se  Sat Dec  5 02:49:39 2015
From: contact at winterei.se (Paul S.)
Date: Sat, 5 Dec 2015 11:49:39 +0900
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <56624F66.3070600@winterei.se>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
 <CAPkb-7B4E8dojyNBjc4_e8q-GFp=ihY4d1OV0227+xi-shv8oA@mail.gmail.com>
 <56624F66.3070600@winterei.se>
Message-ID: <566250C3.1030809@winterei.se>

Whoops, spoke too soon.

While HE indeed seems to use the transits to reach Cogent, they only do 
this over v4.

IPv6 packets are indeed dropped on the first border. Sorry for the noise.

core1.fmt1.he.net> traceroute ipv6 2001:550:2:d::a:2 numericTarget 
2001:550:2:d::a:2
Hop Start 	1
Hop End 	30

Hop 	Packet 1 	Packet 2 	Packet 3 	Hostname
1 	* 	* 	* 	?
2 	* 	* 	* 	?
3 	* 	* 	* 	?
4 	* 	* 	* 	?
IP: Errno(8) Trace Route Failed, no response from target node.




On 12/5/2015 11:43 AM, Paul S. wrote:
> It is worth noting that HE indeed provides the full view, it's the 
> other side that has an issue.
>
> (Since HE isn't really a tier 1, their transit relationships with 
> Telia and other carriers "save" them)
>
> Cogent -> HE dies with unreachable on the first hop though, and that's 
> an issue for Cogent customers.
>
> On 12/5/2015 11:09 AM, Baldur Norddahl wrote:
>> On 5 December 2015 at 02:43, Randy Bush <randy at psg.com> wrote:
>>
>>>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>>>> global v6 internet
>>> if A does not peer with B,
>>> then for all A and B
>>> they are evil partitioners?
>>>
>>> can we lower the rhetoric?
>>>
>> They both loses on this. In fact anyone claiming tier 1 status loses 
>> here,
>> because this illustrates why you can never be single homed on a tier 1
>> network. These guys simply do not have the full internet.
>>
>> Regards,
>>
>> Baldur
>


From randy at psg.com  Sat Dec  5 02:50:28 2015
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Dec 2015 11:50:28 +0900
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAEmG1=rc8HHAG6tfYtkuHi4J7vDdwEQ+ETojn0W5X0HD+8uzUA@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
 <CAEmG1=rc8HHAG6tfYtkuHi4J7vDdwEQ+ETojn0W5X0HD+8uzUA@mail.gmail.com>
Message-ID: <m2a8ppzk0b.wl%randy@psg.com>

> No, it's not an issue of A not peering
> with B, it's A selling "internet transit"
> for a known subset of the internet
> rather than the whole kit and kaboodle.

right.  then hurricane and cogent should both
make clear that they do not provide ipv6 transit
to the entire internet.

randy

From bill at herrin.us  Sat Dec  5 02:57:26 2015
From: bill at herrin.us (William Herrin)
Date: Fri, 4 Dec 2015 21:57:26 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <m2lh99zn45.wl%randy@psg.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
Message-ID: <CAP-guGWjYt2LqTUqrDn9VeSy606=zJcwjZiT0vYj=Y+3wYNZmQ@mail.gmail.com>

On Fri, Dec 4, 2015 at 8:43 PM, Randy Bush <randy at psg.com> wrote:
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>> global v6 internet
>
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
>
> can we lower the rhetoric?

It's Cogent. Seriously. They earned their disrespect.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From owen at delong.com  Sun Dec  6 00:05:44 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 5 Dec 2015 16:05:44 -0800
Subject: DHCPv6 PD & Routing Questions
In-Reply-To: <20151125235950.6E5293D93209@rock.dv.isc.org>
References: <564F923B.9080200@jsbc.cc>
 <CAKCUjRXuD+knVBZSohAyNshBTDZ0DTXvRuBTg3Kn24RfrcH_ZQ@mail.gmail.com>
 <CAA93jw4WYBdbOvicCtTohSaEPajU-DrEFvrK4TSDNH6Zq4w72w@mail.gmail.com>
 <5650FDED.70300@jsbc.cc>
 <alpine.DEB.2.02.1511230717350.24520@uplift.swm.pp.se>
 <5652D3F9.6030009@lanparty.ee>
 <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>
 <20151123202706.6A0A83D76305@rock.dv.isc.org>
 <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com>
 <20151123223954.A3DA13D775D5@rock.dv.isc.org>
 <42270.1448383626@turing-police.cc.vt.edu>
 <20151124233647.E3D5B3D855A4@rock.dv.isc.org>
 <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com>
 <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>
 <20151125235950.6E5293D93209@rock.dv.isc.org>
Message-ID: <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>


> On Nov 25, 2015, at 15:59 , Mark Andrews <marka at isc.org> wrote:
> 
> 
> In message <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw at mail.gmail.com>, Brian Knight writes:
>> On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl
>> <baldur.norddahl at gmail.com> wrote:
>>> 
>>> DHCPv6-PD allows multiple PD requests. But did anyone actually implement
>>> that? I am not aware of any device that will hand out sub delegations on
>>> one interface, notice that it is out of address space and then go request
>>> more space from the upstream router (*).
>>> 
>>> DHCPv6-PD allows size hints, but it is often ignored. Also there is no
>>> guidance for what prefix sizes you should ask for. Many CPEs will ask for
>>> /48. If you got a /48 you will give out that /48 and then not honor any
>>> further requests, because only one /48 per site is allowed. If you are an
>>> ISP that gives out /48 and your customers CPE asks for a /56 you will still
>>> ignore his size hint and give him /48.
>> 
>> Or, worse, the ISP's DHCPv6 server honors the new request and issues
>> the larger prefix, but refuses to route it.  Ran into that myself when
>> I replaced my home CPE router, and changed the prefix hint to ask for
>> a /60 block (expanded from /64) at the same time.  That made for a
>> frustrating few days without IPv6 service, waiting for my original
>> delegation to expire.  (Tech support, of course, had no clue and
>> blamed my router.)
>> 
>> In retrospect I should have perhaps had my original CPE generate a
>> DHCP release message for that prefix before disconnecting it.  But I
>> won't be the last person to fail to generate that.
>> 
>> -Brian
> 
> Well the requesting router could announce the route.  ISC's client
> has hooks that allow this to be done.  That is, after all, how
> routing is designed to work.  The DHCP server usually is sitting
> in a data center on the other side of the country with zero ability
> to inject approptiate routes.
> 

Are you really suggesting that a residential ISP accept routes advertised
from their customer?s CPE? Really?

That?s about the most ridiculous thing I?ve heard on NANOG in a long time
and that?s saying something.

> The DHCP relay could also have injected routes but that is a second
> class solution.

Maybe, but in an ISP/Customer PD environment, it?s certainly preferable
to what you consider a ?first class? solution.

Owen


From owen at delong.com  Sun Dec  6 04:48:09 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 5 Dec 2015 20:48:09 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <565DF39C.9060503@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
Message-ID: <4B77055E-7D54-4266-B71F-6EB004EAC5DC@delong.com>

Admittedly, I may be biased, but even I am not sure in which direction.

HE and Cogent have been in a pissing match over peering for a very long time.

HE refuses to pay transit (which to me seems reasonable).
Cogent refuses to peer with HE or pay transit. (The latter seeming reasonable
to me, the former not so much).

The dispute is bad for the internet.
Paying Cogent would also, IMHO, be bad for the internet.

If it were me, I would drop Cogent, let them know why you are dropping them,
and find a provider that has transit to both Cogent and HE as a replacement.

YMMV.

Owen

The following may also be of interest from the archives:

https://www.youtube.com/watch?v=7CObnXjmDtg

> On Dec 1, 2015, at 11:23 , Max Tulyev <maxtul at netassist.ua> wrote:
> 
> Hi All,
> 
> we got an issue today that announces from Cogent don't reach Hurricane
> Electric. HE support said that's a feature, not a bug.
> 
> So we have splitted Internet again?
> 
> I have to change at least one of my uplinks because of it, which one is
> better to drop, HE or Cogent?


From owen at delong.com  Sun Dec  6 04:49:37 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 5 Dec 2015 20:49:37 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
Message-ID: <C41BF4D2-7CC4-48C2-8FC1-42CBBAA03887@delong.com>


> On Dec 2, 2015, at 17:38 , Ryan Rawdon <ryan at u13.net> wrote:
> 
> 
>> On Dec 1, 2015, at 1:23 PM, Max Tulyev <maxtul at netassist.ua> wrote:
>> 
>> Hi All,
>> 
>> we got an issue today that announces from Cogent don't reach Hurricane
>> Electric. HE support said that's a feature, not a bug.
>> 
>> So we have splitted Internet again?
>> 
>> I have to change at least one of my uplinks because of it, which one is
>> better to drop, HE or Cogent?
> 
> 
> There is another option, instead of choosing just one - perhaps establish a tunnel to HE from a L3 device that can do the tunneling in hardware?  You can get a HE tunnel for free, and they will speak BGP to you.
> 
> Alternatively, if you are on any IXes where HE is present - they will not only peer with you for v6, but announce a full table if you want it. 

Where the definition of Full Table is everything that isn?t exclusively behind Cogent.

Owen


From marka at isc.org  Sun Dec  6 05:18:49 2015
From: marka at isc.org (Mark Andrews)
Date: Sun, 06 Dec 2015 16:18:49 +1100
Subject: DHCPv6 PD & Routing Questions
In-Reply-To: Your message of "Sat, 05 Dec 2015 16:05:44 -0800."
 <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>
References: <564F923B.9080200@jsbc.cc>
 <CAKCUjRXuD+knVBZSohAyNshBTDZ0DTXvRuBTg3Kn24RfrcH_ZQ@mail.gmail.com>
 <CAA93jw4WYBdbOvicCtTohSaEPajU-DrEFvrK4TSDNH6Zq4w72w@mail.gmail.com>
 <5650FDED.70300@jsbc.cc>
 <alpine.DEB.2.02.1511230717350.24520@uplift.swm.pp.se>
 <5652D3F9.6030009@lanparty.ee>
 <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>
 <20151123202706.6A0A83D76305@rock.dv.isc.org>
 <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com>
 <20151123223954.A3DA13D775D5@rock.dv.isc.org>
 <42270.1448383626@turing-police.cc.vt.edu>
 <20151124233647.E3D5B3D855A4@rock.dv.isc.org>
 <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com>
 <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>
 <20151125235950.6E5293D93209@rock.dv.isc.org>
 <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>
Message-ID: <20151206051849.A887E3E687A7@rock.dv.isc.org>


In message <E82EA149-2530-41FF-9CE0-670E6CD7D097 at delong.com>, Owen DeLong writes:
>
> > On Nov 25, 2015, at 15:59 , Mark Andrews <marka at isc.org> wrote:
> >
> >
> > In message
> <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw at mail.gmail.com>,
> Brian Knight writes:
> >> On Tue, Nov 24, 2015 at 6:34 PM, Baldur Norddahl
> >> <baldur.norddahl at gmail.com> wrote:
> >>>
> >>> DHCPv6-PD allows multiple PD requests. But did anyone actually
> implement
> >>> that? I am not aware of any device that will hand out sub delegations
> on
> >>> one interface, notice that it is out of address space and then go
> request
> >>> more space from the upstream router (*).
> >>>
> >>> DHCPv6-PD allows size hints, but it is often ignored. Also there is no
> >>> guidance for what prefix sizes you should ask for. Many CPEs will ask for
> >>> /48. If you got a /48 you will give out that /48 and then not honor any
> >>> further requests, because only one /48 per site is allowed. If you are an
> >>> ISP that gives out /48 and your customers CPE asks for a /56 you will
> >>> still ignore his size hint and give him /48.
> >>
> >> Or, worse, the ISP's DHCPv6 server honors the new request and issues
> >> the larger prefix, but refuses to route it.  Ran into that myself when
> >> I replaced my home CPE router, and changed the prefix hint to ask for
> >> a /60 block (expanded from /64) at the same time.  That made for a
> >> frustrating few days without IPv6 service, waiting for my original
> >> delegation to expire.  (Tech support, of course, had no clue and
> >> blamed my router.)
> >>
> >> In retrospect I should have perhaps had my original CPE generate a
> >> DHCP release message for that prefix before disconnecting it.  But I
> >> won't be the last person to fail to generate that.
> >>
> >> -Brian
> >
> > Well the requesting router could announce the route.  ISC's client
> > has hooks that allow this to be done.  That is, after all, how
> > routing is designed to work.  The DHCP server usually is sitting
> > in a data center on the other side of the country with zero ability
> > to inject approptiate routes.
>
> Are you really suggesting that a residential ISP accept routes advertised
> from their customer???s CPE? Really?

PD is used internally as well as externally, and with a little bit
of crypto to prove the assigned address belongs to them there really
isn't a reason a CPE device couldn't announce a address to a ISP.
It would also allow BCP38 filters to be built rather than using RFP
which is only a approximate solution.

> That???s about the most ridiculous thing I???ve heard on NANOG in a long time
> and that???s saying something.
>
> > The DHCP relay could also have injected routes but that is a second
> > class solution.
>
> Maybe, but in an ISP/Customer PD environment, it???s certainly preferable
> to what you consider a ???first class??? solution.

Actually it is still a second class solution. Have the CPE generate
the routes and use information from the relay as a acceptance filter.

That way the device that was delegated the prefix decides what it
announced.

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

From owen at delong.com  Sun Dec  6 05:37:10 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 5 Dec 2015 21:37:10 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <m2lh99zn45.wl%randy@psg.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
Message-ID: <FCCD4763-5CF8-4D86-9882-36E5F9881432@delong.com>


> On Dec 4, 2015, at 17:43 , Randy Bush <randy at psg.com> wrote:
> 
>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>> global v6 internet
> 
> if A does not peer with B,
> then for all A and B
> they are evil partitioners?
> 
> can we lower the rhetoric?
> 
> randy

Does that remain true for values of A where A is willing to peer with
B, but B refuses to peer with A?

Owen


From bill at herrin.us  Sun Dec  6 07:56:38 2015
From: bill at herrin.us (William Herrin)
Date: Sun, 6 Dec 2015 02:56:38 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <C41BF4D2-7CC4-48C2-8FC1-42CBBAA03887@delong.com>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
 <C41BF4D2-7CC4-48C2-8FC1-42CBBAA03887@delong.com>
Message-ID: <CAP-guGUGY2FkZ9DKJ1qTrSPRA3eTzNBqPLeQWZsitDc7VMxt3Q@mail.gmail.com>

On Sat, Dec 5, 2015 at 11:49 PM, Owen DeLong <owen at delong.com> wrote:
> Where the definition of Full Table is everything that isn?t exclusively behind Cogent.

I thought that was a full table in IPv4 as well?

-Bill

-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From jared at puck.nether.net  Sun Dec  6 09:08:37 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Sun, 6 Dec 2015 04:08:37 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAP-guGUGY2FkZ9DKJ1qTrSPRA3eTzNBqPLeQWZsitDc7VMxt3Q@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
 <C41BF4D2-7CC4-48C2-8FC1-42CBBAA03887@delong.com>
 <CAP-guGUGY2FkZ9DKJ1qTrSPRA3eTzNBqPLeQWZsitDc7VMxt3Q@mail.gmail.com>
Message-ID: <678E9A34-B5D1-4161-8126-22A9E94EB4D8@puck.nether.net>


> On Dec 6, 2015, at 2:56 AM, William Herrin <bill at herrin.us> wrote:
> 
> On Sat, Dec 5, 2015 at 11:49 PM, Owen DeLong <owen at delong.com> wrote:
>> Where the definition of Full Table is everything that isn?t exclusively behind Cogent.
> 
> I thought that was a full table in IPv4 as well?

The disjoint is IPv4 they can reach each other, but the relationships that exist for IPv4 aren?t all dual-stacked with congruent policies.

As with all things, I suspect this has more to do with ?market optics? vs what?s best for the network(s) involved.

my take: I don?t think there are a lot of actual missing bits as a result of this.

- Jared

From baldur.norddahl at gmail.com  Sun Dec  6 16:45:56 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sun, 6 Dec 2015 17:45:56 +0100
Subject: DHCPv6 PD & Routing Questions
In-Reply-To: <20151206051849.A887E3E687A7@rock.dv.isc.org>
References: <564F923B.9080200@jsbc.cc>
 <CAKCUjRXuD+knVBZSohAyNshBTDZ0DTXvRuBTg3Kn24RfrcH_ZQ@mail.gmail.com>
 <CAA93jw4WYBdbOvicCtTohSaEPajU-DrEFvrK4TSDNH6Zq4w72w@mail.gmail.com>
 <5650FDED.70300@jsbc.cc>
 <alpine.DEB.2.02.1511230717350.24520@uplift.swm.pp.se>
 <5652D3F9.6030009@lanparty.ee>
 <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>
 <20151123202706.6A0A83D76305@rock.dv.isc.org>
 <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com>
 <20151123223954.A3DA13D775D5@rock.dv.isc.org>
 <42270.1448383626@turing-police.cc.vt.edu>
 <20151124233647.E3D5B3D855A4@rock.dv.isc.org>
 <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com>
 <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>
 <20151125235950.6E5293D93209@rock.dv.isc.org>
 <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>
 <20151206051849.A887E3E687A7@rock.dv.isc.org>
Message-ID: <CAPkb-7D51zcgzN3SHFY7o-d2cWo+FNMQy7go3HsSyY_+6G8Xuw@mail.gmail.com>

On 6 December 2015 at 06:18, Mark Andrews <marka at isc.org> wrote:

> > Are you really suggesting that a residential ISP accept routes advertised
> > from their customer?s CPE? Really?
>
> PD is used internally as well as externally, and with a little bit
> of crypto to prove the assigned address belongs to them there really
> isn't a reason a CPE device couldn't announce a address to a ISP.
> It would also allow BCP38 filters to be built rather than using RFP
> which is only a approximate solution.
>

Do you envision that the CPE runs OSPFv3 or something else? Would that
scale? I am not an OSPF expert, but thousands of CPEs in an OSPF domain
does not sound like a sane thing.

What is the advantage? The prefix has been assigned to the CPE. If the CPE
does not advertise the prefix it just goes to the null route. What is the
use case where you want a prefix assigned to a CPE but _not_ routed to the
same CPE?

I do agree that there is something missing here, but I prefer a solution
that does not require the CPE to be changed.

Regards,

Baldur

From bill at herrin.us  Sun Dec  6 18:33:24 2015
From: bill at herrin.us (William Herrin)
Date: Sun, 6 Dec 2015 13:33:24 -0500
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <678E9A34-B5D1-4161-8126-22A9E94EB4D8@puck.nether.net>
References: <565DF39C.9060503@netassist.ua>
 <98647D12-9795-4B78-AD19-2588674A6C77@u13.net>
 <C41BF4D2-7CC4-48C2-8FC1-42CBBAA03887@delong.com>
 <CAP-guGUGY2FkZ9DKJ1qTrSPRA3eTzNBqPLeQWZsitDc7VMxt3Q@mail.gmail.com>
 <678E9A34-B5D1-4161-8126-22A9E94EB4D8@puck.nether.net>
Message-ID: <CAP-guGXugi49jn2YdoeSoJMQt7bDcnzTyr3kO+X_rxgmLK0Q4A@mail.gmail.com>

On Sun, Dec 6, 2015 at 4:08 AM, Jared Mauch <jared at puck.nether.net> wrote:
>> On Dec 6, 2015, at 2:56 AM, William Herrin <bill at herrin.us> wrote:
>> On Sat, Dec 5, 2015 at 11:49 PM, Owen DeLong <owen at delong.com> wrote:
>>> Where the definition of Full Table is everything that isn?t exclusively behind Cogent.
>> I thought that was a full table in IPv4 as well?
>
> The disjoint is IPv4 they can reach each other, but the relationships that exist for IPv4 aren?t all dual-stacked with congruent policies.

Hi Jared,

I was being sarcastic. I would never accept Cogent as my sole service
provider because they have a history of getting in to arguments which
leave their customers with only a partial view of the Internet. In
IPv6 -AND- IPv4. As far as I'm concerned, anyone exclusively on Cogent
isn't fully on the Internet and it's not my problem to get them there.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From jamesl at mythostech.com  Sun Dec  6 18:37:44 2015
From: jamesl at mythostech.com (James Laszko)
Date: Sun, 6 Dec 2015 18:37:44 +0000
Subject: Modem as a service?
Message-ID: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>

We are looking to automate testing of OOB modem connections when our NMS detects a site connection failure.  Rather than have a live body call a modem number (or even a fax) to see if it answers (to determine if there is a potential site power issue), we'd like to be able to utilize some "Modem as a service" to automate this.  I've exhausted my Google skills trying to see if anything like this exists.  Anyone have any experience?



Thank you,


James Laszko
Mythos Technology Inc
jamesl at mythostech.com<mailto:jamesl at mythostech.com>


From joelja at bogus.com  Sun Dec  6 18:38:33 2015
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 6 Dec 2015 10:38:33 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <FCCD4763-5CF8-4D86-9882-36E5F9881432@delong.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
 <FCCD4763-5CF8-4D86-9882-36E5F9881432@delong.com>
Message-ID: <566480A9.3070603@bogus.com>

On 12/5/15 9:37 PM, Owen DeLong wrote:
> 
>> On Dec 4, 2015, at 17:43 , Randy Bush <randy at psg.com> wrote:
>>
>>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>>> global v6 internet
>>
>> if A does not peer with B,
>> then for all A and B
>> they are evil partitioners?
>>
>> can we lower the rhetoric?
>>
>> randy
> 
> Does that remain true for values of A where A is willing to peer with
> B, but B refuses to peer with A?

These are (mostly) reasonable business decisions engaged by (mostly)
reasonable actors.  both providers have tools available to them to
address the partition unilaterally as one of them does in ipv4  where
they so inclined.

Neither provider has significant numbers of single homed eyeballs
marooned behind them which would be bad.

> Owen
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151206/703f6afb/attachment.pgp>

From joelja at bogus.com  Sun Dec  6 18:57:23 2015
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 6 Dec 2015 10:57:23 -0800
Subject: Modem as a service?
In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
Message-ID: <56648513.6070001@bogus.com>

On 12/6/15 10:37 AM, James Laszko wrote:
> We are looking to automate testing of OOB modem connections when our
> NMS detects a site connection failure.  Rather than have a live body
> call a modem number (or even a fax) to see if it answers (to
> determine if there is a potential site power issue), we'd like to be
> able to utilize some "Modem as a service" to automate this.  I've
> exhausted my Google skills trying to see if anything like this
> exists.  Anyone have any experience?

Typically that sort of thing would be implemented as an event handler
driven by the nms

Internet outdial used to be a thing, but probably these days that means
dropping your own modem someplace.

> 
> 
> Thank you,
> 
> 
> James Laszko Mythos Technology Inc 
> jamesl at mythostech.com<mailto:jamesl at mythostech.com>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151206/785570f8/attachment.pgp>

From baconzombie at gmail.com  Sun Dec  6 18:59:28 2015
From: baconzombie at gmail.com (Bacon Zombie)
Date: Sun, 6 Dec 2015 19:59:28 +0100
Subject: Modem as a service?
In-Reply-To: <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
Message-ID: <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>

Have you looked into scheduled scans with WarVOX?
On Dec 6, 2015 7:39 PM, "James Laszko" <jamesl at mythostech.com> wrote:

We are looking to automate testing of OOB modem connections when our NMS
detects a site connection failure.  Rather than have a live body call a
modem number (or even a fax) to see if it answers (to determine if there is
a potential site power issue), we'd like to be able to utilize some "Modem
as a service" to automate this.  I've exhausted my Google skills trying to
see if anything like this exists.  Anyone have any experience?



Thank you,


James Laszko
Mythos Technology Inc
jamesl at mythostech.com<mailto:jamesl at mythostech.com>

From jamesl at mythostech.com  Sun Dec  6 19:19:43 2015
From: jamesl at mythostech.com (James Laszko)
Date: Sun, 6 Dec 2015 19:19:43 +0000
Subject: Modem as a service?
In-Reply-To: <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
Message-ID: <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>

It looks like WarVOX has been rolled into Metasploit?.  I guess using SIP trunking could accomplish the same thing ? we don?t need to actually connect to the OOB modem on the other side, we just need a NO ANSWER/ANSWER kind of response.  I will investigate SIP software to accomplish this, unless someone has quick pointers?  ?


Thank you,


James

From: Bacon Zombie [mailto:baconzombie at gmail.com]
Sent: Sunday, December 06, 2015 10:59
To: James Laszko
Cc: nanog at nanog.org
Subject: Re: Modem as a service?


Have you looked into scheduled scans with WarVOX?
On Dec 6, 2015 7:39 PM, "James Laszko" <jamesl at mythostech.com<mailto:jamesl at mythostech.com>> wrote:
We are looking to automate testing of OOB modem connections when our NMS detects a site connection failure.  Rather than have a live body call a modem number (or even a fax) to see if it answers (to determine if there is a potential site power issue), we'd like to be able to utilize some "Modem as a service" to automate this.  I've exhausted my Google skills trying to see if anything like this exists.  Anyone have any experience?



Thank you,


James Laszko
Mythos Technology Inc
jamesl at mythostech.com<mailto:jamesl at mythostech.com><mailto:jamesl at mythostech.com<mailto:jamesl at mythostech.com>>

From marty at cloudflare.com  Sun Dec  6 20:47:35 2015
From: marty at cloudflare.com (Marty Strong)
Date: Sun, 6 Dec 2015 20:47:35 +0000
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <566480A9.3070603@bogus.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <CAEmG1=r=QZ5C9MwdNB_xaoQSGzv_7DB4niTooj=QHhcFWDMcoQ@mail.gmail.com>
 <m2lh99zn45.wl%randy@psg.com>
 <FCCD4763-5CF8-4D86-9882-36E5F9881432@delong.com>
 <566480A9.3070603@bogus.com>
Message-ID: <AA174966-9EDB-4BC5-B402-E78321062F77@cloudflare.com>

I think what?s stopping this from being a bigger issue is that neither network has many (if any) single-homed customers that don?t connect on IPv4, which as mentioned previously isn?t partitioned. If there were many IPv6 only eyeballs single-homed behind each network then it would be a bigger issue.

Regards,
Marty Strong
--------------------------------------
CloudFlare - AS13335
Network Engineer
marty at cloudflare.com
+44 7584 906 055
smartflare (Skype)

http://www.peeringdb.com/view.php?asn=13335

> On 6 Dec 2015, at 18:38, joel jaeggli <joelja at bogus.com> wrote:
> 
> On 12/5/15 9:37 PM, Owen DeLong wrote:
>> 
>>> On Dec 4, 2015, at 17:43 , Randy Bush <randy at psg.com> wrote:
>>> 
>>>> Or, if you feel that Cogent's stubborn insistence on partitioning the
>>>> global v6 internet
>>> 
>>> if A does not peer with B,
>>> then for all A and B
>>> they are evil partitioners?
>>> 
>>> can we lower the rhetoric?
>>> 
>>> randy
>> 
>> Does that remain true for values of A where A is willing to peer with
>> B, but B refuses to peer with A?
> 
> These are (mostly) reasonable business decisions engaged by (mostly)
> reasonable actors.  both providers have tools available to them to
> address the partition unilaterally as one of them does in ipv4  where
> they so inclined.
> 
> Neither provider has significant numbers of single homed eyeballs
> marooned behind them which would be bad.
> 
>> Owen
>> 
> 
> 


From james.cutler at consultant.com  Sun Dec  6 21:36:53 2015
From: james.cutler at consultant.com (James R Cutler)
Date: Sun, 6 Dec 2015 16:36:53 -0500
Subject: Modem as a service?
In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
Message-ID: <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>

> On Dec 6, 2015, at 2:19 PM, James Laszko <jamesl at mythostech.com> wrote:
> 
> ... we don?t need to actually connect to the OOB modem on the other side, we just need a NO ANSWER/ANSWER kind of response. ?

Forget modems - to probe via some kind of analog connection, just get a single instrument wireless telephone with answering capability.  For a bonus, put some kind of identifier in the answering message:  No power > no answer; power > answer.


James R. Cutler
James.cutler at consultant.com
PGP keys at http://pgp.mit.edu




From kauer at biplane.com.au  Sun Dec  6 22:17:09 2015
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 07 Dec 2015 09:17:09 +1100
Subject: Modem as a service?
In-Reply-To: <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
Message-ID: <1449440229.2876.10.camel@karl>

On Sun, 2015-12-06 at 16:36 -0500, James R Cutler wrote:
> > On Dec 6, 2015, at 2:19 PM, James Laszko <jamesl at mythostech.com> wrote:
> > 
> > ... we don?t need to actually connect to the OOB modem on the other side, we just need a NO ANSWER/ANSWER kind of response. ?
> 
> Forget modems - to probe via some kind of analog connection, just get
> a single instrument wireless telephone with answering capability.  For
> a bonus, put some kind of identifier in the answering message:  No
> power > no answer; power > answer.

I must be thick - how does that solve the problem? The OP wants to know
if a modem at a remote site will answer the phone. Maybe I misunderstood
the problem.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882



From owen at delong.com  Sun Dec  6 22:20:36 2015
From: owen at delong.com (Owen DeLong)
Date: Sun, 6 Dec 2015 14:20:36 -0800
Subject: DHCPv6 PD & Routing Questions
In-Reply-To: <CAPkb-7D51zcgzN3SHFY7o-d2cWo+FNMQy7go3HsSyY_+6G8Xuw@mail.gmail.com>
References: <564F923B.9080200@jsbc.cc>
 <CAKCUjRXuD+knVBZSohAyNshBTDZ0DTXvRuBTg3Kn24RfrcH_ZQ@mail.gmail.com>
 <CAA93jw4WYBdbOvicCtTohSaEPajU-DrEFvrK4TSDNH6Zq4w72w@mail.gmail.com>
 <5650FDED.70300@jsbc.cc>
 <alpine.DEB.2.02.1511230717350.24520@uplift.swm.pp.se>
 <5652D3F9.6030009@lanparty.ee>
 <29055E3F-B923-4E21-8513-60CC8C14A6C9@delong.com>
 <20151123202706.6A0A83D76305@rock.dv.isc.org>
 <6B49EE17-6DE1-4493-91C1-478F3BA44F12@delong.com>
 <20151123223954.A3DA13D775D5@rock.dv.isc.org>
 <42270.1448383626@turing-police.cc.vt.edu>
 <20151124233647.E3D5B3D855A4@rock.dv.isc.org>
 <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com>
 <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>
 <20151125235950.6E5293D93209@rock.dv.isc.org>
 <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>
 <20151206051849.A887E3E687A7@rock.dv.isc.org>
 <CAPkb-7D51zcgzN3SHFY7o-d2cWo+FNMQy7go3HsSyY_+6G8Xuw@mail.gmail.com>
Message-ID: <6971CD18-E643-42FC-9C6B-A61AF17E7543@delong.com>


> On Dec 6, 2015, at 08:45 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> On 6 December 2015 at 06:18, Mark Andrews <marka at isc.org> wrote:
> 
>>> Are you really suggesting that a residential ISP accept routes advertised
>>> from their customer?s CPE? Really?
>> 
>> PD is used internally as well as externally, and with a little bit
>> of crypto to prove the assigned address belongs to them there really
>> isn't a reason a CPE device couldn't announce a address to a ISP.
>> It would also allow BCP38 filters to be built rather than using RFP
>> which is only a approximate solution.
>> 
> 
> Do you envision that the CPE runs OSPFv3 or something else? Would that
> scale? I am not an OSPF expert, but thousands of CPEs in an OSPF domain
> does not sound like a sane thing.

As an alternative worth considering, it could do this with BGP instead of OSPF.

There?s nothing mythical or magical about BGP. A CPE autoconfiguring itself
to advertise the prefix(es) it has received from upstream DHCPv6 server(s)
to it?s neighbors is not rocket science. In fact, this would mean that the CPE
could also accept a default route via the same BGP session and it could
even be used to enable automatic failover for mulihomed dynamically addressed
sites.

Sure, this requires modifying the CPE, but not in a particularly huge way and
it provides a much cleaner and more scaleable solution for the ISP side of the
equation than OSPF.

Most current implementations use RIPv2, but we all know just how icky that is.

> What is the advantage? The prefix has been assigned to the CPE. If the CPE
> does not advertise the prefix it just goes to the null route. What is the
> use case where you want a prefix assigned to a CPE but _not_ routed to the
> same CPE?

_not_ routed is not the only consideration here.

routed via alternative paths may be worthy of consideration.

Owen


From jamesl at mythostech.com  Sun Dec  6 22:28:55 2015
From: jamesl at mythostech.com (James Laszko)
Date: Sun, 6 Dec 2015 22:28:55 +0000
Subject: Modem as a service?
In-Reply-To: <1449440229.2876.10.camel@karl>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
Message-ID: <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>

Nah, it wasn't you!  :)

The solution I think we're going to go with is leveraging our existing SIP infrastructure and write scripts to dial out to the OOB Modem / Fax machines at the sites that are disconnected from the network.  If they both don?t answer, we'll assume a power outage.  If one or the other does answer, it'll queue up for human interaction.

I wrote a script in Perl in about 15 minutes to do this.  God, I'm not sure if I'm stuck thinking inside or outside the box anymore!


Thanks for the replies and insights,


James


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Auer
Sent: Sunday, December 06, 2015 14:17
To: nanog at nanog.org
Subject: Re: Modem as a service?

On Sun, 2015-12-06 at 16:36 -0500, James R Cutler wrote:
> > On Dec 6, 2015, at 2:19 PM, James Laszko <jamesl at mythostech.com> wrote:
> > 
> > ... we don?t need to actually connect to the OOB modem on the other 
> > side, we just need a NO ANSWER/ANSWER kind of response. ?
> 
> Forget modems - to probe via some kind of analog connection, just get 
> a single instrument wireless telephone with answering capability.  For 
> a bonus, put some kind of identifier in the answering message:  No 
> power > no answer; power > answer.

I must be thick - how does that solve the problem? The OP wants to know if a modem at a remote site will answer the phone. Maybe I misunderstood the problem.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882



From rbf+nanog at panix.com  Sun Dec  6 23:03:47 2015
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Sun, 6 Dec 2015 17:03:47 -0600
Subject: DHCPv6 PD & Routing Questions
In-Reply-To: <6971CD18-E643-42FC-9C6B-A61AF17E7543@delong.com>
References: <20151123223954.A3DA13D775D5@rock.dv.isc.org>
 <42270.1448383626@turing-police.cc.vt.edu>
 <20151124233647.E3D5B3D855A4@rock.dv.isc.org>
 <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com>
 <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>
 <20151125235950.6E5293D93209@rock.dv.isc.org>
 <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>
 <20151206051849.A887E3E687A7@rock.dv.isc.org>
 <CAPkb-7D51zcgzN3SHFY7o-d2cWo+FNMQy7go3HsSyY_+6G8Xuw@mail.gmail.com>
 <6971CD18-E643-42FC-9C6B-A61AF17E7543@delong.com>
Message-ID: <20151206230347.GA3528@panix.com>

On Sun, Dec 06, 2015 at 02:20:36PM -0800, Owen DeLong wrote:
> 
> As an alternative worth considering, it could do this with BGP instead of OSPF.
> 
> There?s nothing mythical or magical about BGP. A CPE autoconfiguring
> itself to advertise the prefix(es) it has received from upstream
> DHCPv6 server(s) to it?s neighbors is not rocket science. In fact,
> this would mean that the CPE could also accept a default route via
> the same BGP session and it could even be used to enable automatic
> failover for mulihomed dynamically addressed sites.
> 
> Sure, this requires modifying the CPE, but not in a particularly huge
> way and it provides a much cleaner and more scaleable solution for
> the ISP side of the equation than OSPF.
> 
> Most current implementations use RIPv2, but we all know just how icky
> that is.

How do you secure that?  Or do you just assume no one will announce
someone else's prefix?  (I can think of ways to secure it, of course,
but none of the approaches for having the DHCP server configure some
sort of prefix access control seem to me to be any better or easier
than having the DCHP server configure a static route).

This isn't a problem I face, but if it were, I think I'd solve it by
having the DHCP server inject the route via BGP with an appropriate
next-hop.

     -- Brett

From owen at delong.com  Mon Dec  7 00:05:23 2015
From: owen at delong.com (Owen DeLong)
Date: Sun, 6 Dec 2015 16:05:23 -0800
Subject: DHCPv6 PD & Routing Questions
In-Reply-To: <20151206230347.GA3528@panix.com>
References: <20151123223954.A3DA13D775D5@rock.dv.isc.org>
 <42270.1448383626@turing-police.cc.vt.edu>
 <20151124233647.E3D5B3D855A4@rock.dv.isc.org>
 <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA@mail.gmail.com>
 <CAMWxDfrh+O=SPZwPmAZhYnvAEeK2eMFw3CD0qf34Fkbb=-SaPw@mail.gmail.com>
 <20151125235950.6E5293D93209@rock.dv.isc.org>
 <E82EA149-2530-41FF-9CE0-670E6CD7D097@delong.com>
 <20151206051849.A887E3E687A7@rock.dv.isc.org>
 <CAPkb-7D51zcgzN3SHFY7o-d2cWo+FNMQy7go3HsSyY_+6G8Xuw@mail.gmail.com>
 <6971CD18-E643-42FC-9C6B-A61AF17E7543@delong.com>
 <20151206230347.GA3528@panix.com>
Message-ID: <5636F8B7-E878-4287-9A54-DF5181ECA617@delong.com>


> On Dec 6, 2015, at 15:03 , Brett Frankenberger <rbf+nanog at panix.com> wrote:
> 
> On Sun, Dec 06, 2015 at 02:20:36PM -0800, Owen DeLong wrote:
>> 
>> As an alternative worth considering, it could do this with BGP instead of OSPF.
>> 
>> There?s nothing mythical or magical about BGP. A CPE autoconfiguring
>> itself to advertise the prefix(es) it has received from upstream
>> DHCPv6 server(s) to it?s neighbors is not rocket science. In fact,
>> this would mean that the CPE could also accept a default route via
>> the same BGP session and it could even be used to enable automatic
>> failover for mulihomed dynamically addressed sites.
>> 
>> Sure, this requires modifying the CPE, but not in a particularly huge
>> way and it provides a much cleaner and more scaleable solution for
>> the ISP side of the equation than OSPF.
>> 
>> Most current implementations use RIPv2, but we all know just how icky
>> that is.
> 
> How do you secure that?  Or do you just assume no one will announce
> someone else's prefix?  (I can think of ways to secure it, of course,
> but none of the approaches for having the DHCP server configure some
> sort of prefix access control seem to me to be any better or easier
> than having the DCHP server configure a static route).
> 
> This isn't a problem I face, but if it were, I think I'd solve it by
> having the DHCP server inject the route via BGP with an appropriate
> next-hop.

A perfectly valid alternative? However, lots of people seem determined to use
a routing protocol from the CPE. Given that constraint, I was looking at the options available
and trying to pick the most reasonable among them.

Note: Your concern is equally applicable to RIPv2 and OSPF as it is to BGP.

Owen


From josh at kyneticwifi.com  Mon Dec  7 00:13:10 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Sun, 6 Dec 2015 18:13:10 -0600
Subject: Modem as a service?
In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
 <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
Message-ID: <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>

You could always just use UPS equipment that can send out alerts on power
outages and low bat voltage. Or, use equipment that supports dying gasp.
On Dec 6, 2015 4:31 PM, "James Laszko" <jamesl at mythostech.com> wrote:

> Nah, it wasn't you!  :)
>
> The solution I think we're going to go with is leveraging our existing SIP
> infrastructure and write scripts to dial out to the OOB Modem / Fax
> machines at the sites that are disconnected from the network.  If they both
> don?t answer, we'll assume a power outage.  If one or the other does
> answer, it'll queue up for human interaction.
>
> I wrote a script in Perl in about 15 minutes to do this.  God, I'm not
> sure if I'm stuck thinking inside or outside the box anymore!
>
>
> Thanks for the replies and insights,
>
>
> James
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Auer
> Sent: Sunday, December 06, 2015 14:17
> To: nanog at nanog.org
> Subject: Re: Modem as a service?
>
> On Sun, 2015-12-06 at 16:36 -0500, James R Cutler wrote:
> > > On Dec 6, 2015, at 2:19 PM, James Laszko <jamesl at mythostech.com>
> wrote:
> > >
> > > ... we don?t need to actually connect to the OOB modem on the other
> > > side, we just need a NO ANSWER/ANSWER kind of response. ?
> >
> > Forget modems - to probe via some kind of analog connection, just get
> > a single instrument wireless telephone with answering capability.  For
> > a bonus, put some kind of identifier in the answering message:  No
> > power > no answer; power > answer.
>
> I must be thick - how does that solve the problem? The OP wants to know if
> a modem at a remote site will answer the phone. Maybe I misunderstood the
> problem.
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
>
> GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old
> fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
>
>
>

From maxtul at netassist.ua  Mon Dec  7 00:24:44 2015
From: maxtul at netassist.ua (Max Tulyev)
Date: Mon, 07 Dec 2015 02:24:44 +0200
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
Message-ID: <5664D1CC.6000500@netassist.ua>

On 04.12.15 01:19, Baldur Norddahl wrote:
> On 1 December 2015 at 20:23, Max Tulyev <maxtul at netassist.ua> wrote:
>> I have to change at least one of my uplinks because of it, which one is
>> better to drop, HE or Cogent?
>>
> 
> Question: Why would you have to drop one of them? You have no problem if
> you have both.

Because of money, isn't it? I don't want to pay twice!

> Even in the case of a link failure to one of them, you will likely not see
> a big impact since everyone else also keeps multiple transits. You will
> only have trouble with people that are single homed Cogent or HE, in which
> case it is more them having a problem than you.

As I fully implement IPv6 on my net, I got a HUGE impact already. That's
the problem.

So as this is not a bug, but a long time story - I relized for me as a
cutomer connectivity from both Hurricane Electric and Cogent is a crap.
So people should avoid both, and buy for example from Level3 and NTT,
which do not have such problem and do not sell me partial connectivity
without any warning before signing the contract.

I'm just a IP transit customer, and I don't give a something for that
wars who is the real Tier1. I just want a working service for my money
instead of answering a hundreds calls from my subscribers!

From mpetach at netflight.com  Mon Dec  7 00:54:38 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 6 Dec 2015 16:54:38 -0800
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <5664D1CC.6000500@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <5664D1CC.6000500@netassist.ua>
Message-ID: <CAEmG1=oCdTPfVCGkeMUr7xsGBA6+-4cTduSDnzdX9sn4DAA8Xg@mail.gmail.com>

On Sun, Dec 6, 2015 at 4:24 PM, Max Tulyev <maxtul at netassist.ua> wrote:
> On 04.12.15 01:19, Baldur Norddahl wrote:
>> On 1 December 2015 at 20:23, Max Tulyev <maxtul at netassist.ua> wrote:
>>> I have to change at least one of my uplinks because of it, which one is
>>> better to drop, HE or Cogent?
>>
>> Question: Why would you have to drop one of them? You have no problem if
>> you have both.
>
> Because of money, isn't it? I don't want to pay twice!

Completely makes sense--you want to get the
most value possible for the dollars you spend,
which means you want to choose upstream
providers that give you the most complete
view of the internet possible.

> So as this is not a bug, but a long time story - I relized for me as a
> cutomer connectivity from both Hurricane Electric and Cogent is a crap.
> So people should avoid both, and buy for example from Level3 and NTT,
> which do not have such problem and do not sell me partial connectivity
> without any warning before signing the contract.
>
> I'm just a IP transit customer, and I don't give a something for that
> wars who is the real Tier1. I just want a working service for my money
> instead of answering a hundreds calls from my subscribers!

So, for you, the choice is going to come
down to a comparison of how much each
provider charges vs how much of a headache
they're creating for you in terms of partial
reachability problems.  While bigger entities
like Level 3 and NTT will give you fewer reachability
headaches, they're also likely to charge more; and
you don't want to put all your eggs in one basket.

So, hypothetically speaking, if Level3 and NTT
both charge $2/mb/s/month, and Cogent and
HE charge $0.75/mb/s/month, you might
find that you get a more cost-effective
blend by getting 3 circuits, one each
from Level3 OR NTT, and Cogent,
and HE, for a total cost of $2+$0.75+$0.75,
or $3.50, instead of the other option
of buying two circuits, one each
from Level3 and NTT, which would
be $2+$2, or $4.

Yes, I realize this is completely contrived
hypothetical set of prices, but the point is
only you have the knowledge of how much
each provider is charging you; take that
information, do a few searches in your
favorite search engine for "$PROVIDER
peering dispute", and see which providers
have the best and worst histories as far
as getting into peering disputes, and then
choose accordingly.

It would be nice if there were a rating
system for ISPs that would make it
easier for smaller companies to know
if they were buying from an "A" rated
ISP vs a "C" or "D" rated ISP, somewhat
like restaurants that have to post their
department of health scores visibly.
However, without any overseeing entity
that would provide such a rating service,
for now it's up to each buyer to do their
own research to decide which ISPs are
safer to work with, and which ones are
riskier.

Best of luck making the right choices!

Thanks!

Matt

From kauer at biplane.com.au  Mon Dec  7 01:03:48 2015
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 07 Dec 2015 12:03:48 +1100
Subject: Modem as a service?
In-Reply-To: <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
 <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
 <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>
Message-ID: <1449450228.2876.38.camel@karl>

On Sun, 2015-12-06 at 18:13 -0600, Josh Reynolds wrote:
> You could always just use UPS equipment that can send out alerts on power
> outages and low bat voltage. Or, use equipment that supports dying gasp.

The equipment you have needs to be able to send the alert, which means
SMS or email-capable equipment needs to stay powered up long enough to
do that.

There might be a product idea here, if no-one's done it already:
Something like a RaspBerry Pi, running off a lithium battery, with a
recharge circuit and something to detect a power outage. Add a 3G/4G
card to send an SMS alert, put it all in a box, plug it into power. Only
configuration needed is setting the SMS target(s)... If you made it
network addressable (on 3G/4G) it could send emails as well.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882



From b-nanog at grmbl.net  Mon Dec  7 01:07:50 2015
From: b-nanog at grmbl.net (b)
Date: Mon, 7 Dec 2015 02:07:50 +0100
Subject: Modem as a service?
In-Reply-To: <1449450228.2876.38.camel@karl>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
 <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
 <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>
 <1449450228.2876.38.camel@karl>
Message-ID: <20151207010750.GB54921@mx.grmbl.net>

What about a $20 android phone, when it detects a power loss (stops charging), send an sms.

On Mon, Dec 07, 2015 at 12:03:48PM +1100, Karl Auer wrote:
> On Sun, 2015-12-06 at 18:13 -0600, Josh Reynolds wrote:
> > You could always just use UPS equipment that can send out alerts on power
> > outages and low bat voltage. Or, use equipment that supports dying gasp.
> 
> The equipment you have needs to be able to send the alert, which means
> SMS or email-capable equipment needs to stay powered up long enough to
> do that.
> 
> There might be a product idea here, if no-one's done it already:
> Something like a RaspBerry Pi, running off a lithium battery, with a
> recharge circuit and something to detect a power outage. Add a 3G/4G
> card to send an SMS alert, put it all in a box, plug it into power. Only
> configuration needed is setting the SMS target(s)... If you made it
> network addressable (on 3G/4G) it could send emails as well.
> 
> Regards, K.
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
> 
> GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
> Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
> 
> 

From jhaustin at gmail.com  Mon Dec  7 01:15:51 2015
From: jhaustin at gmail.com (Jeremy Austin)
Date: Sun, 6 Dec 2015 16:15:51 -0900
Subject: Modem as a service?
In-Reply-To: <1449450228.2876.38.camel@karl>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
 <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
 <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>
 <1449450228.2876.38.camel@karl>
Message-ID: <CABNB40XRUg7Qh9VQ9AKAz+RdaNGfjCOTH0fVpb6-gtEt4E0OGA@mail.gmail.com>

On Sun, Dec 6, 2015 at 4:03 PM, Karl Auer <kauer at biplane.com.au> wrote:

>
> There might be a product idea here, if no-one's done it already:
> Something like a RaspBerry Pi, running off a lithium battery, with a
> recharge circuit and something to detect a power outage. Add a 3G/4G
> card to send an SMS alert, put it all in a box, plug it into power. Only
> configuration needed is setting the SMS target(s)... If you made it
> network addressable (on 3G/4G) it could send emails as well.


Almost exactly my scenario.

While you're at it, add IP/serial links to console servers and tunnel in.
I've got this as the only OOB option for sites with no copper. Low
bandwidth 3G plan.

-- 
Jeremy Austin
Whitestone Power & Communications
(907) 895-2311
(907) 803-5422
jhaustin at gmail.com

From hal at buzcom.net  Mon Dec  7 01:18:37 2015
From: hal at buzcom.net (Hal Ponton)
Date: Mon, 7 Dec 2015 01:18:37 +0000
Subject: Modem as a service?
In-Reply-To: <20151207010750.GB54921@mx.grmbl.net>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
 <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
 <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>
 <1449450228.2876.38.camel@karl> <20151207010750.GB54921@mx.grmbl.net>
Message-ID: <04C24B85-C161-4859-BE2D-4C305922AE59@buzcom.net>

There are already devices that are doing this like PowerTxT, it may be based off another company I may add but we are using them for OOB monitoring of power for remote sites.

They have just enough power in the capacitors to send a text message to a master number or gateway for an NMS.

Have a look at http://www.tekview-solutions.com/powertxt.php

Regards,

Hal Ponton

Senior Network Engineer

Buzcom / FibreWiFi

Tel: 07429 979 217
Email: hal at buzcom.net

> On 7 Dec 2015, at 01:07, b <b-nanog at grmbl.net> wrote:
> 
> What about a $20 android phone, when it detects a power loss (stops charging), send an sms.
> 
>> On Mon, Dec 07, 2015 at 12:03:48PM +1100, Karl Auer wrote:
>>> On Sun, 2015-12-06 at 18:13 -0600, Josh Reynolds wrote:
>>> You could always just use UPS equipment that can send out alerts on power
>>> outages and low bat voltage. Or, use equipment that supports dying gasp.
>> 
>> The equipment you have needs to be able to send the alert, which means
>> SMS or email-capable equipment needs to stay powered up long enough to
>> do that.
>> 
>> There might be a product idea here, if no-one's done it already:
>> Something like a RaspBerry Pi, running off a lithium battery, with a
>> recharge circuit and something to detect a power outage. Add a 3G/4G
>> card to send an SMS alert, put it all in a box, plug it into power. Only
>> configuration needed is setting the SMS target(s)... If you made it
>> network addressable (on 3G/4G) it could send emails as well.
>> 
>> Regards, K.
>> 
>> -- 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Karl Auer (kauer at biplane.com.au)
>> http://www.biplane.com.au/kauer
>> http://twitter.com/kauer389
>> 
>> GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
>> Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
>> 
>> 

From hal at buzcom.net  Mon Dec  7 01:23:24 2015
From: hal at buzcom.net (Hal Ponton)
Date: Mon, 7 Dec 2015 01:23:24 +0000
Subject: Modem as a service?
In-Reply-To: <04C24B85-C161-4859-BE2D-4C305922AE59@buzcom.net>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
 <8078ED370ADA824281219A7B5BADC39B6D3DA453@MBX023-W1-CA-4.exch023.domain.local>
 <CAC6=tfaVhfXJFzxmTMH10OzTnLRyxUEG6xBz7ULXHr4bFHWhJA@mail.gmail.com>
 <1449450228.2876.38.camel@karl> <20151207010750.GB54921@mx.grmbl.net>
 <04C24B85-C161-4859-BE2D-4C305922AE59@buzcom.net>
Message-ID: <A6D582A1-25E9-4773-A1C6-317A9C3359F6@buzcom.net>

Apologies,

Should have listed the following link as this is suited for the US market whereas the other is European.

http://www.tekview-solutions.com/powertxtduo.php

Regards,

Hal Ponton

Senior Network Engineer

Buzcom / FibreWiFi

Tel: 07429 979 217
Email: hal at buzcom.net

> On 7 Dec 2015, at 01:18, Hal Ponton <hal at buzcom.net> wrote:
> 
> There are already devices that are doing this like PowerTxT, it may be based off another company I may add but we are using them for OOB monitoring of power for remote sites.
> 
> They have just enough power in the capacitors to send a text message to a master number or gateway for an NMS.
> 
> Have a look at http://www.tekview-solutions.com/powertxt.php
> 
> Regards,
> 
> Hal Ponton
> 
> Senior Network Engineer
> 
> Buzcom / FibreWiFi
> 
> Tel: 07429 979 217
> Email: hal at buzcom.net
> 
>> On 7 Dec 2015, at 01:07, b <b-nanog at grmbl.net> wrote:
>> 
>> What about a $20 android phone, when it detects a power loss (stops charging), send an sms.
>> 
>>>> On Mon, Dec 07, 2015 at 12:03:48PM +1100, Karl Auer wrote:
>>>> On Sun, 2015-12-06 at 18:13 -0600, Josh Reynolds wrote:
>>>> You could always just use UPS equipment that can send out alerts on power
>>>> outages and low bat voltage. Or, use equipment that supports dying gasp.
>>> 
>>> The equipment you have needs to be able to send the alert, which means
>>> SMS or email-capable equipment needs to stay powered up long enough to
>>> do that.
>>> 
>>> There might be a product idea here, if no-one's done it already:
>>> Something like a RaspBerry Pi, running off a lithium battery, with a
>>> recharge circuit and something to detect a power outage. Add a 3G/4G
>>> card to send an SMS alert, put it all in a box, plug it into power. Only
>>> configuration needed is setting the SMS target(s)... If you made it
>>> network addressable (on 3G/4G) it could send emails as well.
>>> 
>>> Regards, K.
>>> 
>>> -- 
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Karl Auer (kauer at biplane.com.au)
>>> http://www.biplane.com.au/kauer
>>> http://twitter.com/kauer389
>>> 
>>> GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
>>> Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
>>> 
>>> 

From baldur.norddahl at gmail.com  Mon Dec  7 01:32:38 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 7 Dec 2015 02:32:38 +0100
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <CAEmG1=oCdTPfVCGkeMUr7xsGBA6+-4cTduSDnzdX9sn4DAA8Xg@mail.gmail.com>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <5664D1CC.6000500@netassist.ua>
 <CAEmG1=oCdTPfVCGkeMUr7xsGBA6+-4cTduSDnzdX9sn4DAA8Xg@mail.gmail.com>
Message-ID: <CAPkb-7At6BAgKUh0sukQJ+jVdO09bSCUpjvjF-4s00RtP59xbw@mail.gmail.com>

On 7 December 2015 at 01:54, Matthew Petach <mpetach at netflight.com> wrote:

> So, hypothetically speaking, if Level3 and NTT
> both charge $2/mb/s/month, and Cogent and
> HE charge $0.75/mb/s/month, you might
> find that you get a more cost-effective
> blend by getting 3 circuits, one each
> from Level3 OR NTT, and Cogent,
> and HE, for a total cost of $2+$0.75+$0.75,
> or $3.50, instead of the other option
> of buying two circuits, one each
> from Level3 and NTT, which would
> be $2+$2, or $4.
>

Or you could buy from some so called "tier 2" or "tier 3" providers
instead. Say the world has 6 tier 1 providers called A, B, C, D, E and F.
Ideally you would get the best connectivity (the most direct routes) by
buying from two tier 2, one which has A, B and C as uplink and the other
has D, E and F.

In my experience the connectivity between tier 1 providers can be really
bad. If I use only my Cogent transit, some traffic will go from Europe to
New York and back again. The performance is so bad that my customers will
start calling me and claim the network is down. Just looking at the routing
table will not tell you the full story here.

Back to the real world: Cogent is good for dirt cheap transit, HE is good
for their massive peering and then you also take in someone local to cover
all your bases.

Regards,

Baldur

From admin at coldnorthadmin.com  Mon Dec  7 06:41:21 2015
From: admin at coldnorthadmin.com (Laurent Dumont)
Date: Mon, 7 Dec 2015 01:41:21 -0500
Subject: Questions regarding equipment for a large LAN event
Message-ID: <56652A11.3090602@coldnorthadmin.com>

Hi Nanog,

This email might seem a bit strange but bear with me. I am a member of a 
student club in Montreal named "Lan ETS". Every year, we organize on the 
biggest LAN event in North-America. We have an amazing partnership with 
Cisco where they allow us to request a fair amount of equipment so that 
we can create the best experience for our players.

This year, we are looking into some equipment that slightly out of our 
usual expertise. Usually, we target high-density stackable switches like 
a 3650/3750/3850 with 48 GigE and 4 SFP for our 10G core. We design our 
network around small "islands" of players all linked with each other 
through a 2x10G fiber network. Everyone is assigned a public address and 
we route everyone out through our core switch.

We were looking at either the Nexus 7004 chassis or the ASR 9004/9006 
chassis for this year event. We would then use 48xGigE and 1x24 SFP+ 
line cards. Our actual port requirements and somewhat flexible but we do 
need at least 4x10G Fiber ports. And at least 48 GigE ports for players 
or access switches.

I'm also open to any suggestion within Cisco portfolio. Our needs are 
pretty standard and nothing extraordinary but we would like to use this 
opportunity in order to try new equipment and technologies that are 
usually only seem within ISP and large networks.

I appreciate any input on the matter!

Thank you

-- 
Laurent Dumont
https://coldnorthadmin.com


From rdobbins at arbor.net  Mon Dec  7 06:53:39 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 07 Dec 2015 13:53:39 +0700
Subject: Questions regarding equipment for a large LAN event
In-Reply-To: <56652A11.3090602@coldnorthadmin.com>
References: <56652A11.3090602@coldnorthadmin.com>
Message-ID: <ADB64D7C-5FC0-4500-813C-CC8CC032EEAA@arbor.net>

On 7 Dec 2015, at 13:41, Laurent Dumont wrote:

> I appreciate any input on the matter!

1.  cisco-nsp is a better list for this type of question.

2.  The ASR9K is an edge router, not an access switch.

3.  Why not just ask Cisco, for starters?
	
-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From mark.tinka at seacom.mu  Mon Dec  7 06:59:21 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 7 Dec 2015 08:59:21 +0200
Subject: Questions regarding equipment for a large LAN event
In-Reply-To: <56652A11.3090602@coldnorthadmin.com>
References: <56652A11.3090602@coldnorthadmin.com>
Message-ID: <56652E49.80709@seacom.mu>



On 7/Dec/15 08:41, Laurent Dumont wrote:

>  
>
> We were looking at either the Nexus 7004 chassis or the ASR 9004/9006
> chassis for this year event. We would then use 48xGigE and 1x24 SFP+
> line cards. Our actual port requirements and somewhat flexible but we
> do need at least 4x10G Fiber ports. And at least 48 GigE ports for
> players or access switches.

If you're going to order new platforms from Cisco for your event, you
should check out the new 6800 switches.

The Nexus should do the job as well.

The ASR9000 are more routers than switches, although they will do the
job also. If you have some routing requirements, they are not a bad choice.

For the access side, you certainly want to continue with the 3650/3850
switches

Mark.

From seth.mos at dds.nl  Mon Dec  7 07:58:51 2015
From: seth.mos at dds.nl (Seth Mos)
Date: Mon, 7 Dec 2015 08:58:51 +0100
Subject: Google Chrome 47.0.2526.73M broken NTLM proxy authentication
In-Reply-To: <565FF7A8.7070201@dds.nl>
References: <565FF7A8.7070201@dds.nl>
Message-ID: <56653C3B.2040708@dds.nl>

A quick update, Google Chrome engineering did cut a new release with a
fix for this but it's not available yet.

https://code.google.com/p/chromium/issues/detail?id=544255

The current workaround is to shrink your return headers smaller then
4096 bytes to prevent the authentication popup.

Get ready for a rough monday morning, we've already had to field quite a
few calls, and the GPO policy doesn't work, yay.

Dear Google, your internet browser doesn't browse the internet, please
make haste.

Kind regards,

Seth


Op 3-12-2015 om 9:04 schreef Seth Mos:
> Dear Google,
> 
> As of Dec 2nd the Google Chrome 47.0.2526.73M breaks NTLM proxy
> authentication. This is unfortunate as nobody can get off the company
> network now, which is secure I suppose, but not quite what I had in mind.
> 
> https://productforums.google.com/forum/#!topic/chrome/G_9eXH9c_ns;context-place=forum/chrome
> 
> So if anybody gets called that Google Chrome is throwing a
> username/password prompt for every website you try, listing the website
> as the authentication domain, instead of the proxy server, this is for you.
> 
> If you are ahead of the curve, you can make a GPO to disable Chrome
> updates for the time being until this is fixed. If the browser already
> updated, well, sorry.
> 
> Kind regards,
> 
> Seth
> 


From alejandroacostaalamo at gmail.com  Mon Dec  7 11:51:41 2015
From: alejandroacostaalamo at gmail.com (Alejandro Acosta)
Date: Mon, 7 Dec 2015 07:21:41 -0430
Subject: Questions regarding equipment for a large LAN event
In-Reply-To: <56652A11.3090602@coldnorthadmin.com>
References: <56652A11.3090602@coldnorthadmin.com>
Message-ID: <566572CD.7010706@gmail.com>

You have not IPv6 at all?.., this is a good starting point

El 12/7/2015 a las 2:11 AM, Laurent Dumont escribi?:
> Hi Nanog,
>
> This email might seem a bit strange but bear with me. I am a member of
> a student club in Montreal named "Lan ETS". Every year, we organize on
> the biggest LAN event in North-America. We have an amazing partnership
> with Cisco where they allow us to request a fair amount of equipment
> so that we can create the best experience for our players.
>
> This year, we are looking into some equipment that slightly out of our
> usual expertise. Usually, we target high-density stackable switches
> like a 3650/3750/3850 with 48 GigE and 4 SFP for our 10G core. We
> design our network around small "islands" of players all linked with
> each other through a 2x10G fiber network. Everyone is assigned a
> public address and we route everyone out through our core switch.
>
> We were looking at either the Nexus 7004 chassis or the ASR 9004/9006
> chassis for this year event. We would then use 48xGigE and 1x24 SFP+
> line cards. Our actual port requirements and somewhat flexible but we
> do need at least 4x10G Fiber ports. And at least 48 GigE ports for
> players or access switches.
>
> I'm also open to any suggestion within Cisco portfolio. Our needs are
> pretty standard and nothing extraordinary but we would like to use
> this opportunity in order to try new equipment and technologies that
> are usually only seem within ISP and large networks.
>
> I appreciate any input on the matter!
>
> Thank you
>


From A.L.M.Buxey at lboro.ac.uk  Mon Dec  7 12:12:22 2015
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 7 Dec 2015 12:12:22 +0000
Subject: Questions regarding equipment for a large LAN event
In-Reply-To: <56652A11.3090602@coldnorthadmin.com>
References: <56652A11.3090602@coldnorthadmin.com>
Message-ID: <20151207121222.GC18696@lboro.ac.uk>

hi


okay...so lots of gig connections with 10g interconnects etc - have you actually done network
analysis/flows of the events in the past to see what you actually require to run the event? 
what sort of stuff are they doing - multiplayer PvP stuff or are they shipping 
images/ISOs across to each other?   as well as the data requirements what sort of protection
do you put into place (that would affect choice of edge switch).   as others will probably
say, this is really more suited to eg c-nsp 


alan

From baconzombie at gmail.com  Mon Dec  7 14:34:01 2015
From: baconzombie at gmail.com (Bacon Zombie)
Date: Mon, 7 Dec 2015 15:34:01 +0100
Subject: Questions regarding equipment for a large LAN event
In-Reply-To: <20151207121222.GC18696@lboro.ac.uk>
References: <56652A11.3090602@coldnorthadmin.com>
 <20151207121222.GC18696@lboro.ac.uk>
Message-ID: <CAPz7E52qwtFF=QrVVWEmLHQ2qfoipbGN6aDQjr7yR_hOKeEv4g@mail.gmail.com>

Have a look at what they did for QuakeCon.

What Powers Quakecon | Network Operations Center Tour https
<https://www.youtube.com/watch?v=mOv62lBdlXU>://
<https://www.youtube.com/watch?v=mOv62lBdlXU>www.youtube.com
<https://www.youtube.com/watch?v=mOv62lBdlXU>/watch?v=
<https://www.youtube.com/watch?v=mOv62lBdlXU>mOv62lBdlXU
<https://www.youtube.com/watch?v=mOv62lBdlXU>

https://mobile.twitter.com/quakeconnetwork
On Dec 7, 2015 1:15 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> hi
>
>
> okay...so lots of gig connections with 10g interconnects etc - have you
> actually done network
> analysis/flows of the events in the past to see what you actually require
> to run the event?
> what sort of stuff are they doing - multiplayer PvP stuff or are they
> shipping
> images/ISOs across to each other?   as well as the data requirements what
> sort of protection
> do you put into place (that would affect choice of edge switch).   as
> others will probably
> say, this is really more suited to eg c-nsp
>
>
> alan
>

From outsider at scarynet.org  Mon Dec  7 14:50:14 2015
From: outsider at scarynet.org (Alexander Maassen)
Date: Mon, 7 Dec 2015 15:50:14 +0100
Subject: Mozilla Cert expired today :P
Message-ID: <ce790b545afe8479f7c73f88f29f604f.squirrel@mail.scarynet.org>

Kinda funny and perhaps offtopic, but I noticed the cert for mozilla.org
expired right before my eyes when checking my plugins.


From littlefishguy at gmail.com  Mon Dec  7 14:53:26 2015
From: littlefishguy at gmail.com (Scott Fisher)
Date: Mon, 7 Dec 2015 09:53:26 -0500
Subject: Mozilla Cert expired today :P
In-Reply-To: <ce790b545afe8479f7c73f88f29f604f.squirrel@mail.scarynet.org>
References: <ce790b545afe8479f7c73f88f29f604f.squirrel@mail.scarynet.org>
Message-ID: <CAHddgMyGkp=Dr9AJy_5xXgjLVii-GfMDYNAOwHNRd1iz4-Yovg@mail.gmail.com>

Looks fine to me.

On Mon, Dec 7, 2015 at 9:50 AM, Alexander Maassen <outsider at scarynet.org> wrote:
> Kinda funny and perhaps offtopic, but I noticed the cert for mozilla.org
> expired right before my eyes when checking my plugins.
>



-- 
Scott

From sakamura at gmail.com  Mon Dec  7 15:16:45 2015
From: sakamura at gmail.com (Ishmael Rufus)
Date: Mon, 7 Dec 2015 09:16:45 -0600
Subject: Mozilla Cert expired today :P
In-Reply-To: <ce790b545afe8479f7c73f88f29f604f.squirrel@mail.scarynet.org>
References: <ce790b545afe8479f7c73f88f29f604f.squirrel@mail.scarynet.org>
Message-ID: <CAL-SDLGr69jeCQDCPoQdYq1U+BOOsiQadfKm5gidzZs-yVeVTQ@mail.gmail.com>

Hit Ctrl+F5

On Mon, Dec 7, 2015 at 8:50 AM, Alexander Maassen <outsider at scarynet.org>
wrote:

> Kinda funny and perhaps offtopic, but I noticed the cert for mozilla.org
> expired right before my eyes when checking my plugins.
>
>

From Steve.Mikulasik at civeo.com  Mon Dec  7 15:37:21 2015
From: Steve.Mikulasik at civeo.com (Steve Mikulasik)
Date: Mon, 7 Dec 2015 15:37:21 +0000
Subject: IGF Mandate Renewl
Message-ID: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>

The UN's Internet Governance Forum is up for renewal at the end of 2015, without UN approval they will be shutdown. I am relatively new here and haven't seen much discussion about IGF and UN (attempted) involvement in the internet. How do people feel about the IGF and should it be renewed by the UN? I can't really figure out what gap they fill other than being big conference.


https://en.wikipedia.org/wiki/Internet_Governance_Forum#2015_mandate_renewal



From larrysheldon at cox.net  Mon Dec  7 17:54:17 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 7 Dec 2015 11:54:17 -0600
Subject: Modem as a service?
In-Reply-To: <1449440229.2876.10.camel@karl>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl>
Message-ID: <5665C7C9.5080600@cox.net>

On 12/6/2015 16:17, Karl Auer wrote:
> On Sun, 2015-12-06 at 16:36 -0500, James R Cutler wrote:
>>> On Dec 6, 2015, at 2:19 PM, James Laszko <jamesl at mythostech.com> wrote:
>>>
>>> ... we don?t need to actually connect to the OOB modem on the other side, we just need a NO ANSWER/ANSWER kind of response. ?
>>
>> Forget modems - to probe via some kind of analog connection, just get
>> a single instrument wireless telephone with answering capability.  For
>> a bonus, put some kind of identifier in the answering message:  No
>> power > no answer; power > answer.
>
> I must be thick - how does that solve the problem? The OP wants to know
> if a modem at a remote site will answer the phone. Maybe I misunderstood
> the problem.

I'll join the confusion--I thought the OP wanted to test for power 
availability at the distant site by seeing if a modem there would answer 
the phone there.  That it HAD to be a modem in that case makes no sense 
to me.

I'm of the line now and have been for a while and maybe y'all don't do 
things the way we did--we always had an answering machine (two or three 
in some places*) that always answered on the first ring and gave some 
kind of status report that was updated hourly on on event).  If it did 
not answer, the power was out.

*at one site we had one that gave general status--what's up, what's 
down, what's generally interesting (outages scheduled soon, where we are 
in the daily batch cycle).  We had another listing southern region 
outputs ready for pick-up and one listing northern region stuff.


-- 
sed quis custodiet ipsos custodes? (Juvenal)

From jlewis at lewis.org  Mon Dec  7 18:22:52 2015
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 7 Dec 2015 13:22:52 -0500 (EST)
Subject: Modem as a service?
In-Reply-To: <5665C7C9.5080600@cox.net>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl> <5665C7C9.5080600@cox.net>
Message-ID: <Pine.LNX.4.61.1512071319380.10544@soloth.lewis.org>

On Mon, 7 Dec 2015, Larry Sheldon wrote:

> I'll join the confusion--I thought the OP wanted to test for power 
> availability at the distant site by seeing if a modem there would answer the 
> phone there.  That it HAD to be a modem in that case makes no sense to me.

Presumably, the modems are already there (setup to answer) as a means to 
access the OOB console servers in the case of a network outage.  "Does it 
answer" is just a simple way to tell "is the power out, and everything's 
dead, or is there a network problem that's caused us to lose visibility?"


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

From owen at delong.com  Mon Dec  7 18:52:27 2015
From: owen at delong.com (Owen DeLong)
Date: Mon, 7 Dec 2015 10:52:27 -0800
Subject: IGF Mandate Renewl
In-Reply-To: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>

The IGF is certainly preferable to moving this role into the ITU.

Owen

> On Dec 7, 2015, at 07:37 , Steve Mikulasik <Steve.Mikulasik at civeo.com> wrote:
> 
> The UN's Internet Governance Forum is up for renewal at the end of 2015, without UN approval they will be shutdown. I am relatively new here and haven't seen much discussion about IGF and UN (attempted) involvement in the internet. How do people feel about the IGF and should it be renewed by the UN? I can't really figure out what gap they fill other than being big conference.
> 
> 
> https://en.wikipedia.org/wiki/Internet_Governance_Forum#2015_mandate_renewal
> 
> 


From jamie at workshopx.com  Mon Dec  7 19:07:51 2015
From: jamie at workshopx.com (Jamie Gwatkin)
Date: Mon, 7 Dec 2015 14:07:51 -0500
Subject: Modem as a service?
In-Reply-To: <Pine.LNX.4.61.1512071319380.10544@soloth.lewis.org>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl> <5665C7C9.5080600@cox.net>
 <Pine.LNX.4.61.1512071319380.10544@soloth.lewis.org>
Message-ID: <CAAh0A0mrFm-gKpn9erp=ptCqx_XUgfVydm1Ymh-UhTxEFndA+g@mail.gmail.com>

You could easily do this using Twillio. We've done the same thing to test
if a PBX is up.


On Mon, Dec 7, 2015 at 1:22 PM, Jon Lewis <jlewis at lewis.org> wrote:

> On Mon, 7 Dec 2015, Larry Sheldon wrote:
>
> I'll join the confusion--I thought the OP wanted to test for power
>> availability at the distant site by seeing if a modem there would answer
>> the phone there.  That it HAD to be a modem in that case makes no sense to
>> me.
>>
>
> Presumably, the modems are already there (setup to answer) as a means to
> access the OOB console servers in the case of a network outage.  "Does it
> answer" is just a simple way to tell "is the power out, and everything's
> dead, or is there a network problem that's caused us to lose visibility?"
>
>
> ----------------------------------------------------------------------
>  Jon Lewis, MCP :)           |  I route
>                              |  therefore you are
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>



-- 
*Jamie Gwatkin* / Software Developer - DevOps
jamie at workshopx.com <fabien at workshopx.com>


Inspire creation.
www.workshopx.com

*Our companies*

CanvasPop <http://canvaspop.com/> / CanvasPop API
<http://canvaspop.com/photo-printing-api> / DNA11 <http://dna11.com/> /
Crated <http://crated.com/> / PopKey <http://popkey.co/>

From morrowc.lists at gmail.com  Mon Dec  7 19:08:34 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 7 Dec 2015 14:08:34 -0500
Subject: IGF Mandate Renewl
In-Reply-To: <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
 <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>
Message-ID: <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>

but the ITU is a larger conference over more time, so that's a plus, right?
also, it's international, and telephone, so really .. .they are super
qualified to talk about internet governance stuff.

On Mon, Dec 7, 2015 at 1:52 PM, Owen DeLong <owen at delong.com> wrote:
> The IGF is certainly preferable to moving this role into the ITU.
>
> Owen
>
>> On Dec 7, 2015, at 07:37 , Steve Mikulasik <Steve.Mikulasik at civeo.com> wrote:
>>
>> The UN's Internet Governance Forum is up for renewal at the end of 2015, without UN approval they will be shutdown. I am relatively new here and haven't seen much discussion about IGF and UN (attempted) involvement in the internet. How do people feel about the IGF and should it be renewed by the UN? I can't really figure out what gap they fill other than being big conference.
>>
>>
>> https://en.wikipedia.org/wiki/Internet_Governance_Forum#2015_mandate_renewal
>>
>>
>

From owen at delong.com  Mon Dec  7 19:35:55 2015
From: owen at delong.com (Owen DeLong)
Date: Mon, 7 Dec 2015 11:35:55 -0800
Subject: IGF Mandate Renewl
In-Reply-To: <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
 <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>
 <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>
Message-ID: <53667252-A298-417C-B94C-A62991F30EDE@delong.com>


> On Dec 7, 2015, at 11:08 , Christopher Morrow <morrowc.lists at gmail.com> wrote:
> 
> but the ITU is a larger conference over more time, so that's a plus, right?

Not necessarily.

The ITU is much less democratic and fails to incorporate a wide variety of stakeholders.

The IGF isn?t a whole lot better in this regard, but the IGF has the advantage of being a non-binding cooperative process
where the ITU can fall back on certain treaty obligations to inflict its will.


> also, it's international, and telephone, so really .. .they are super
> qualified to talk about internet governance stuff.

Sarcasm, right?

Owen


> 
> On Mon, Dec 7, 2015 at 1:52 PM, Owen DeLong <owen at delong.com> wrote:
>> The IGF is certainly preferable to moving this role into the ITU.
>> 
>> Owen
>> 
>>> On Dec 7, 2015, at 07:37 , Steve Mikulasik <Steve.Mikulasik at civeo.com> wrote:
>>> 
>>> The UN's Internet Governance Forum is up for renewal at the end of 2015, without UN approval they will be shutdown. I am relatively new here and haven't seen much discussion about IGF and UN (attempted) involvement in the internet. How do people feel about the IGF and should it be renewed by the UN? I can't really figure out what gap they fill other than being big conference.
>>> 
>>> 
>>> https://en.wikipedia.org/wiki/Internet_Governance_Forum#2015_mandate_renewal
>>> 
>>> 
>> 


From joly at punkcast.com  Mon Dec  7 20:55:20 2015
From: joly at punkcast.com (Joly MacFie)
Date: Mon, 7 Dec 2015 15:55:20 -0500
Subject: IGF Mandate Renewl
In-Reply-To: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <CAM9VJk1iDoy8W8cQ0mc_U1aVKycDCUuUY-RaXtwbnMqzxJtroA@mail.gmail.com>

The Internet Society has been very involved in this. Latest report is here:
https://www.internetsociety.org/blog/public-policy/2015/12/where-wsis-heading-post-2015





On Mon, Dec 7, 2015 at 10:37 AM, Steve Mikulasik <Steve.Mikulasik at civeo.com>
wrote:

> The UN's Internet Governance Forum is up for renewal at the end of 2015,
> without UN approval they will be shutdown. I am relatively new here and
> haven't seen much discussion about IGF and UN (attempted) involvement in
> the internet. How do people feel about the IGF and should it be renewed by
> the UN? I can't really figure out what gap they fill other than being big
> conference.
>
>
>
> https://en.wikipedia.org/wiki/Internet_Governance_Forum#2015_mandate_renewal
>
>
>


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-

From ESundberg at nitelusa.com  Mon Dec  7 22:15:28 2015
From: ESundberg at nitelusa.com (Erik Sundberg)
Date: Mon, 7 Dec 2015 22:15:28 +0000
Subject: Devices with only USB console port - Need a Console Server Solution
Message-ID: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>

We have one of these nice new and fancy Cisco ASR920-24SZ, just realized it doesn't have an RJ45 Console port only USB. When we deploy devices at our pop we wire the console port to a terminal\console server, well that doesn't work for a usb console device.

So what is everyone doing for out of band management via the console when it's a usb only device?
Is there something I am missing?
Is there a console server for USB?
Does cisco make an USB to RJ45 Jack adapter?

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

From nanogml at Mail.DDoS-Mitigator.net  Mon Dec  7 22:33:24 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Mon, 7 Dec 2015 14:33:24 -0800
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
Message-ID: <20151207223324.GA7785@Mail.DDoS-Mitigator.net>


hi erik

On 12/07/15 at 10:15pm, Erik Sundberg wrote:
> We have one of these nice new and fancy Cisco ASR920-24SZ, just realized it doesn't have an RJ45 Console port only USB. When we deploy devices at our pop we wire the console port to a terminal\console server, well that doesn't work for a usb console device.
..
> Does cisco make an USB to RJ45 Jack adapter?

cisco bought linksys long long ago whom, along with dozens of others, make USB-ethernet gigE dongle

magic pixie dust
alvin
# DDoS-Mitigator.net

From brez at brezworks.com  Mon Dec  7 22:45:55 2015
From: brez at brezworks.com (Jeremy Bresley)
Date: Mon, 7 Dec 2015 16:45:55 -0600
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
Message-ID: <56660C23.6040801@brezworks.com>

Looks like what you want is the A920-CONS-KIT-S part.  Description on it 
is "ASR 920 Serial Console Cabling Kit"  This is a $0 item when ordered 
with the ASR920s.  The other option is the A900-CONS-KIT-U which is the 
USB-USB console kit.

http://www.cisco.com/c/en/us/td/docs/routers/asr920/hardware/installation/guide/ASR920_HIG/hw_installation.html#pgfId-1199994

Shows the adapter which I'm assuming is what's included in the kit, they 
mention needing the RJ-45 to DB9 cable (normal Cisco console cable) in 
addition to this ASR9XX specific adapter.  Should be able to plug your 
normal terminal server cables into the adapter cable listed above.

Hope this is helpful.

Jeremy "TheBrez" Bresley
brez at brezworks.com

On 12/7/2015 4:15 PM, Erik Sundberg wrote:
> We have one of these nice new and fancy Cisco ASR920-24SZ, just realized it doesn't have an RJ45 Console port only USB. When we deploy devices at our pop we wire the console port to a terminal\console server, well that doesn't work for a usb console device.
>
> So what is everyone doing for out of band management via the console when it's a usb only device?
> Is there something I am missing?
> Is there a console server for USB?
> Does cisco make an USB to RJ45 Jack adapter?
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.


From kauer at biplane.com.au  Mon Dec  7 22:45:58 2015
From: kauer at biplane.com.au (Karl Auer)
Date: Tue, 08 Dec 2015 09:45:58 +1100
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
Message-ID: <1449528358.20094.29.camel@karl>

On Mon, 2015-12-07 at 22:15 +0000, Erik Sundberg wrote:
> We have one of these nice new and fancy Cisco ASR920-24SZ, just
> realized it doesn't have an RJ45 Console port only USB. When we deploy
> devices at our pop we wire the console port to a terminal\console
> server, well that doesn't work for a usb console device.
> 
> So what is everyone doing for out of band management via the console
> when it's a usb only device?
> Is there something I am missing?
> Is there a console server for USB?
> Does cisco make an USB to RJ45 Jack adapter?

This seems to have the info you need. Looks like that's a USB serial
port, so when you plug into it, your laptop grows a new serial port that
can be used to communicate with the device:

http://www.cisco.com/c/en/us/td/docs/routers/asr920/hardware/installation/guide/ASR920_HIG/hw_installation.html

According to that there is a USB-to-RJ45 adapter available, but not
supplied with the device.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882



From ESundberg at nitelusa.com  Mon Dec  7 23:22:17 2015
From: ESundberg at nitelusa.com (Erik Sundberg)
Date: Mon, 7 Dec 2015 23:22:17 +0000
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <1449528358.20094.29.camel@karl>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
 <1449528358.20094.29.camel@karl>
Message-ID: <495D0934DA46854A9CA758393724D59016D48773@NI-MAIL02.nii.ads>

USB-to-RJ45 adapter available --- Does anyone have the part number? is it A920-CONS-KIT-S - Serial Console Kit, USB-to-RJ45 cable

Can anyone confirm this is the right part number

Thanks Everyone



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Auer
Sent: Monday, December 07, 2015 4:46 PM
To: nanog at nanog.org
Subject: Re: Devices with only USB console port - Need a Console Server Solution

On Mon, 2015-12-07 at 22:15 +0000, Erik Sundberg wrote:
> We have one of these nice new and fancy Cisco ASR920-24SZ, just
> realized it doesn't have an RJ45 Console port only USB. When we deploy
> devices at our pop we wire the console port to a terminal\console
> server, well that doesn't work for a usb console device.
>
> So what is everyone doing for out of band management via the console
> when it's a usb only device?
> Is there something I am missing?
> Is there a console server for USB?
> Does cisco make an USB to RJ45 Jack adapter?

This seems to have the info you need. Looks like that's a USB serial port, so when you plug into it, your laptop grows a new serial port that can be used to communicate with the device:

http://www.cisco.com/c/en/us/td/docs/routers/asr920/hardware/installation/guide/ASR920_HIG/hw_installation.html

According to that there is a USB-to-RJ45 adapter available, but not supplied with the device.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882



________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

From dylan at ambauen.com  Mon Dec  7 23:23:00 2015
From: dylan at ambauen.com (Dylan Ambauen)
Date: Mon, 7 Dec 2015 15:23:00 -0800
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
Message-ID: <CAEt0T_4KHbsh-oVLrk=v1fZvk1BPE=n+hnEW0eLCFmgB4=FRPg@mail.gmail.com>

Ftdi USB to Serial / Rs232 Console Rollover Cable for Cisco Routers - Rj45
https://www.amazon.com/dp/B00M2SAKMG/ref=cm_sw_r_em_awd_HnHzwb7XCEQAV

This is an active cable. Not passive.

Any USB to serial converter will probably do it.

---

Dylan Ambauen
On Dec 7, 2015 2:16 PM, "Erik Sundberg" <ESundberg at nitelusa.com> wrote:

> We have one of these nice new and fancy Cisco ASR920-24SZ, just realized
> it doesn't have an RJ45 Console port only USB. When we deploy devices at
> our pop we wire the console port to a terminal\console server, well that
> doesn't work for a usb console device.
>
> So what is everyone doing for out of band management via the console when
> it's a usb only device?
> Is there something I am missing?
> Is there a console server for USB?
> Does cisco make an USB to RJ45 Jack adapter?
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner. Thank you.
>

From larrysheldon at cox.net  Mon Dec  7 23:30:27 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 7 Dec 2015 17:30:27 -0600
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
Message-ID: <56661693.8020304@cox.net>

On 12/7/2015 16:15, Erik Sundberg wrote:
> We have one of these nice new and fancy Cisco ASR920-24SZ, just
> realized it doesn't have an RJ45 Console port only USB.

I am always surprised at people who unpack new toys that somebody paid a 
lot of money for only to find at that late date that the new toy does 
not fit into their defined (for some shaky value of "defined") structure.



-- 
sed quis custodiet ipsos custodes? (Juvenal)

From kauer at biplane.com.au  Mon Dec  7 23:51:37 2015
From: kauer at biplane.com.au (Karl Auer)
Date: Tue, 08 Dec 2015 10:51:37 +1100
Subject: Devices with only USB console port - Need a Console Server
 Solution
In-Reply-To: <CAEt0T_4KHbsh-oVLrk=v1fZvk1BPE=n+hnEW0eLCFmgB4=FRPg@mail.gmail.com>
References: <495D0934DA46854A9CA758393724D59016D47D68@NI-MAIL02.nii.ads>
 <CAEt0T_4KHbsh-oVLrk=v1fZvk1BPE=n+hnEW0eLCFmgB4=FRPg@mail.gmail.com>
Message-ID: <1449532297.20094.44.camel@karl>

On Mon, 2015-12-07 at 15:23 -0800, Dylan Ambauen wrote:
> Any USB to serial converter will probably do it.

The OP is looking to integrate a device with a console server. "Any
converter" would be a mistake. You can get these things for two dollars,
but you get what you pay for.

Maybe seek suggestions here as to converters others have used with
success, the main criteria for success being robustness, reliability and
build quality.

Personally in this situation I would get the approved, vendor supplied,
genuine part.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882



From randy at psg.com  Tue Dec  8 00:06:00 2015
From: randy at psg.com (Randy Bush)
Date: Tue, 08 Dec 2015 09:06:00 +0900
Subject: IGF Mandate Renewl
In-Reply-To: <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
 <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>
 <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>
Message-ID: <m2io49x0rb.wl%randy@psg.com>

> but the ITU is a larger conference over more time, so that's a plus,
> right?  also, it's international, and telephone, so really .. .they
> are super qualified to talk about internet governance stuff.

they eat better food than we do

though i may endure san dogville for the sake of roberto's carne asada
burritos

From jcenile1983 at gmail.com  Mon Dec  7 05:39:49 2015
From: jcenile1983 at gmail.com (John Cenile)
Date: Mon, 7 Dec 2015 16:39:49 +1100
Subject: Amazon - Wrong website location
Message-ID: <CAEhSU44rN6Am3kDv6-EJR30Rje-K5mcuLApK4Cj=UGxEBOGBKA@mail.gmail.com>

Hello,

Amazon's website is currently suggesting Amazon India, rather than Amazon
USA. So I'm guessing whatever GeoIP database they're using is out of date,
but I have updated as many public GeoIP databases I could find.

I have emailed their noc@ email address multiple times, but have not heard
back from them.

Does anyone know where I can fix this up, or who I can contact to resolve
this?

From p.bonvin at edsi-tech.com  Mon Dec  7 12:40:39 2015
From: p.bonvin at edsi-tech.com (Philippe Bonvin)
Date: Mon, 7 Dec 2015 12:40:39 +0000
Subject: Looking for VPS providers with BGP session
Message-ID: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>

Hello,


I'm looking for providers around the world who are able to provide VPS with a BGP session but it seems to be rather difficult to find. I have already found a few with WHT/bgp.he.net/google but a little help would be appreciated.


Does anyone have contact or know people who can offer such services ?

If yes, please contact me off list.


Our budget is quite low: around 50$/month/node +/- 50$ depending the transit providers for a server with 1-2 CPU cores, 20 Go SSD or SAS and 1-2 Go RAM.


I'll be happy to share my provider list we use with anyone who needs it.


Thanks for your help,

Philippe

[EDSI-Tech Sarl]<http://www.edsi-tech.com>
Philippe Bonvin, Directeur
EDSI-Tech S?rl<http://www.edsi-tech.com>
EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15
Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78

From ying.zhang13 at hpe.com  Mon Dec  7 20:07:37 2015
From: ying.zhang13 at hpe.com (Zhang, Ying)
Date: Mon, 7 Dec 2015 20:07:37 +0000
Subject: Survey on Middlebox modeling and troubleshooting
Message-ID: <9FB7CAEB5595194395CF60B36B98FEED1DAB8127@G4W3210.americas.hpqcorp.net>

Dear All,

We are researchers in HP Labs and Duke university. We are currently working on a project related to Middlebox modeling and troubleshooting.
We are currently conducting a survey and gathering feedback from operators.
Can you help us by providing some answers? Please feel free to email us if you have any additional suggestions.
https://www.surveymonkey.com/r/5SFP6G8

Thanks!
-Ying


From prichter at icsi.berkeley.edu  Mon Dec  7 23:22:47 2015
From: prichter at icsi.berkeley.edu (Philipp Richter)
Date: Mon, 7 Dec 2015 18:22:47 -0500
Subject: Survey on IPv4 Scarcity, IPv6 Adoption, Carrier-Grade NAT Deployment
Message-ID: <566614C7.6050606@icsi.berkeley.edu>

Dear NANOG readers,

we are a team of researchers from ICSI Berkeley, TU Berlin, TU Munich,
Internet Initiative Japan and UC Berkeley jointly working on a project
to assess the effects of IPv4 address exhaustion.

As part of our research, we conduct a survey among network operators.
The goal of this survey is to better understand the degree of IPv4
scarcity that ISPs face and which measures are taken to combat it (IPv4
Carrier-Grade NAT deployment, IPv4 address markets, and IPv6 transition
mechanisms).

If you work for an ISP that connects end-users to the Internet, we would
greatly appreciate your response.

To participate, please visit http://natsurvey.icsi.berkeley.edu/

(answering should take about 5 minutes, all questions are explicitly
optional).

We will make anonymized results of this survey available to the public
in early 2016.

Thank you very much for your support!


If you have questions or concerns, please feel free to contact me
directly at prichter AT icsi DOT berkeley DOT edu.

--
Philipp Richter
Research Assistant / PhD Student
TU Berlin / ICSI

From morrowc.lists at gmail.com  Tue Dec  8 04:21:35 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 7 Dec 2015 23:21:35 -0500
Subject: IGF Mandate Renewl
In-Reply-To: <53667252-A298-417C-B94C-A62991F30EDE@delong.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
 <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>
 <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>
 <53667252-A298-417C-B94C-A62991F30EDE@delong.com>
Message-ID: <CAL9jLabetgEQrhFqG-nKOo8GXMpYpkjWUDYm+ag5UwzA5oTTvA@mail.gmail.com>

On Mon, Dec 7, 2015 at 2:35 PM, Owen DeLong <owen at delong.com> wrote:
>
>> On Dec 7, 2015, at 11:08 , Christopher Morrow <morrowc.lists at gmail.com> wrote:
>> also, it's international, and telephone, so really .. .they are super
>> qualified to talk about internet governance stuff.
>
> Sarcasm, right?

always with respect to the ITU, always.

(I dont' disagree with your position on this matter, at all)

From mureninc at gmail.com  Tue Dec  8 04:58:56 2015
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Mon, 7 Dec 2015 22:58:56 -0600
Subject: IPv6 Cogent vs Hurricane Electric
In-Reply-To: <5664D1CC.6000500@netassist.ua>
References: <565DF39C.9060503@netassist.ua>
 <CAPkb-7BHZQH9P1=9iNA=-rJ7nRf2qG+WEYmamrZ+qR9zsPcWKQ@mail.gmail.com>
 <5664D1CC.6000500@netassist.ua>
Message-ID: <CAPKkNb71F5-mFShk8-pyJXkNBFpXODdzfJTSWw2eRuRS1b+azw@mail.gmail.com>

On 6 December 2015 at 18:24, Max Tulyev <maxtul at netassist.ua> wrote:
> On 04.12.15 01:19, Baldur Norddahl wrote:
>> On 1 December 2015 at 20:23, Max Tulyev <maxtul at netassist.ua> wrote:
>>> I have to change at least one of my uplinks because of it, which one is
>>> better to drop, HE or Cogent?
>>>
>>
>> Question: Why would you have to drop one of them? You have no problem if
>> you have both.
>
> Because of money, isn't it? I don't want to pay twice!
>
>> Even in the case of a link failure to one of them, you will likely not see
>> a big impact since everyone else also keeps multiple transits. You will
>> only have trouble with people that are single homed Cogent or HE, in which
>> case it is more them having a problem than you.
>
> As I fully implement IPv6 on my net, I got a HUGE impact already. That's
> the problem.
>
> So as this is not a bug, but a long time story - I relized for me as a
> cutomer connectivity from both Hurricane Electric and Cogent is a crap.
> So people should avoid both, and buy for example from Level3 and NTT,
> which do not have such problem and do not sell me partial connectivity
> without any warning before signing the contract.


I agree with your conclusion, however, your premise is not correct ?
technically, HE is /not/ requiring you to purchase IPv6 from them; in
fact, they're rather openly giving away IPv6, including IPv6 transit,
away for free.

My understanding is that this includes both the tunnels (including
BGP) and the on-premise connectivity options.

So, feel free to ask for your money back from HE, and try that with Cogent, too!

C.


>
> I'm just a IP transit customer, and I don't give a something for that
> wars who is the real Tier1. I just want a working service for my money
> instead of answering a hundreds calls from my subscribers!

From dovid at telecurve.com  Tue Dec  8 11:31:58 2015
From: dovid at telecurve.com (Dovid Bender)
Date: Tue, 8 Dec 2015 06:31:58 -0500
Subject: Looking for VPS providers with BGP session
In-Reply-To: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
References: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
Message-ID: <CAM3TTh2M_PPcrSQcmAkwFO+XORdaAaC7d2Acn-o7oYywa6+h+Q@mail.gmail.com>

I am looking for this as well. I am OK with 1 CPU core since all I need is
a default route.

On Mon, Dec 7, 2015 at 7:40 AM, Philippe Bonvin via NANOG <nanog at nanog.org>
wrote:

> Hello,
>
>
> I'm looking for providers around the world who are able to provide VPS
> with a BGP session but it seems to be rather difficult to find. I have
> already found a few with WHT/bgp.he.net/google but a little help would be
> appreciated.
>
>
> Does anyone have contact or know people who can offer such services ?
>
> If yes, please contact me off list.
>
>
> Our budget is quite low: around 50$/month/node +/- 50$ depending the
> transit providers for a server with 1-2 CPU cores, 20 Go SSD or SAS and 1-2
> Go RAM.
>
>
> I'll be happy to share my provider list we use with anyone who needs it.
>
>
> Thanks for your help,
>
> Philippe
>
> [EDSI-Tech Sarl]<http://www.edsi-tech.com>
> Philippe Bonvin, Directeur
> EDSI-Tech S?rl<http://www.edsi-tech.com>
> EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41
> (0) 21 566 14 15
> Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France
> | T?l?phone: +33 (0)4 86 15 44 78
>

From jared at puck.Nether.net  Tue Dec  8 12:16:03 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Tue, 8 Dec 2015 07:16:03 -0500
Subject: Looking for VPS providers with BGP session
In-Reply-To: <CAM3TTh2M_PPcrSQcmAkwFO+XORdaAaC7d2Acn-o7oYywa6+h+Q@mail.gmail.com>
References: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
 <CAM3TTh2M_PPcrSQcmAkwFO+XORdaAaC7d2Acn-o7oYywa6+h+Q@mail.gmail.com>
Message-ID: <20151208121603.GA5598@puck.nether.net>

	You may want to look at this presenation from Nat Morris:

http://www.slideshare.net/natmorris/anycast-on-a-shoe-string

	- Jared

On Tue, Dec 08, 2015 at 06:31:58AM -0500, Dovid Bender wrote:
> I am looking for this as well. I am OK with 1 CPU core since all I need is
> a default route.
> 
> On Mon, Dec 7, 2015 at 7:40 AM, Philippe Bonvin via NANOG <nanog at nanog.org>
> wrote:
> 
> > Hello,
> >
> >
> > I'm looking for providers around the world who are able to provide VPS
> > with a BGP session but it seems to be rather difficult to find. I have
> > already found a few with WHT/bgp.he.net/google but a little help would be
> > appreciated.
> >
> >
> > Does anyone have contact or know people who can offer such services ?
> >
> > If yes, please contact me off list.
> >
> >
> > Our budget is quite low: around 50$/month/node +/- 50$ depending the
> > transit providers for a server with 1-2 CPU cores, 20 Go SSD or SAS and 1-2
> > Go RAM.
> >
> >
> > I'll be happy to share my provider list we use with anyone who needs it.
> >
> >
> > Thanks for your help,
> >
> > Philippe
> >
> > [EDSI-Tech Sarl]<http://www.edsi-tech.com>
> > Philippe Bonvin, Directeur
> > EDSI-Tech S?rl<http://www.edsi-tech.com>
> > EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41
> > (0) 21 566 14 15
> > Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France
> > | T?l?phone: +33 (0)4 86 15 44 78
> >

-- 
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 sunyucong at gmail.com  Tue Dec  8 12:52:22 2015
From: sunyucong at gmail.com (Yucong Sun)
Date: Tue, 8 Dec 2015 20:52:22 +0800
Subject: Looking for VPS providers with BGP session
In-Reply-To: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
References: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
Message-ID: <CAJygYd0Wm9Lt0HOzhYv1ozDjgicxzq484ALLHDQdwPzkee14-A@mail.gmail.com>

I recommend http://www.quadranet.com/ ! I have been a happy customer
for almost two years,

I have a single dedicated server over there,  running full BGP feed
with them, It's a fairly extensive setup with multiple sessions,
automatic null routing and all the communities tinkering! Their NOC is
very friendly and very easy to work with!

On Mon, Dec 7, 2015 at 8:40 PM, Philippe Bonvin via NANOG
<nanog at nanog.org> wrote:
> Hello,
>
>
> I'm looking for providers around the world who are able to provide VPS with a BGP session but it seems to be rather difficult to find. I have already found a few with WHT/bgp.he.net/google but a little help would be appreciated.
>
>
> Does anyone have contact or know people who can offer such services ?
>
> If yes, please contact me off list.
>
>
> Our budget is quite low: around 50$/month/node +/- 50$ depending the transit providers for a server with 1-2 CPU cores, 20 Go SSD or SAS and 1-2 Go RAM.
>
>
> I'll be happy to share my provider list we use with anyone who needs it.
>
>
> Thanks for your help,
>
> Philippe
>
> [EDSI-Tech Sarl]<http://www.edsi-tech.com>
> Philippe Bonvin, Directeur
> EDSI-Tech S?rl<http://www.edsi-tech.com>
> EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15
> Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78

From listas at kurtkraut.net  Tue Dec  8 16:24:31 2015
From: listas at kurtkraut.net (Kurt Kraut)
Date: Tue, 8 Dec 2015 14:24:31 -0200
Subject: Is RouteViews dead? Is there any alternatives?
Message-ID: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>

Hi,


For the past couple of months I've been attempting to add new Autonomous
Systems to the RouteViews project and got no response. Talking to other AS
in my area, I wasn't able to find no new BGP operator that got a response
from them since July.

Is RouteViews dead? If the answer is yes, it is sad. It is the most used
resource about the internet routing for multiple perspectives.

Is there any other similar project that I could colaborate providing the
point of view of my routers have of the internet?


Best regards,


Kurt Kraut

From contact at winterei.se  Tue Dec  8 16:36:45 2015
From: contact at winterei.se (Paul S.)
Date: Wed, 9 Dec 2015 01:36:45 +0900
Subject: Is RouteViews dead? Is there any alternatives?
In-Reply-To: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
References: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
Message-ID: <5667071D.3020804@winterei.se>

RIPE stats also takes a feed similarly.

On 12/9/2015 01:24 AM, Kurt Kraut via NANOG wrote:
> Hi,
>
>
> For the past couple of months I've been attempting to add new Autonomous
> Systems to the RouteViews project and got no response. Talking to other AS
> in my area, I wasn't able to find no new BGP operator that got a response
> from them since July.
>
> Is RouteViews dead? If the answer is yes, it is sad. It is the most used
> resource about the internet routing for multiple perspectives.
>
> Is there any other similar project that I could colaborate providing the
> point of view of my routers have of the internet?
>
>
> Best regards,
>
>
> Kurt Kraut


From joelja at bogus.com  Tue Dec  8 17:01:57 2015
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 8 Dec 2015 09:01:57 -0800
Subject: Is RouteViews dead? Is there any alternatives?
In-Reply-To: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
References: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
Message-ID: <56670D05.1040308@bogus.com>

Hi,

I'm still on the help at routeviews.org alias.

I haven't seen any mail from Kurt Kraut.

so I would suspect that something is being filtered someplace.

perhaps we can interceed to identify that issue.

thanks
joel


On 12/8/15 8:24 AM, Kurt Kraut via NANOG wrote:
> Hi,
> 
> 
> For the past couple of months I've been attempting to add new Autonomous
> Systems to the RouteViews project and got no response. Talking to other AS
> in my area, I wasn't able to find no new BGP operator that got a response
> from them since July.
> 
> Is RouteViews dead? If the answer is yes, it is sad. It is the most used
> resource about the internet routing for multiple perspectives.
> 
> Is there any other similar project that I could colaborate providing the
> point of view of my routers have of the internet?
> 
> 
> Best regards,
> 
> 
> Kurt Kraut
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151208/22064aff/attachment.pgp>

From morrowc.lists at gmail.com  Tue Dec  8 17:21:06 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Dec 2015 12:21:06 -0500
Subject: Is RouteViews dead? Is there any alternatives?
In-Reply-To: <5667071D.3020804@winterei.se>
References: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
 <5667071D.3020804@winterei.se>
Message-ID: <CAL9jLaaa6FL-3hLbz6sXSq1XWjQ9Q1pxh7OEaVtNbnwHjHaYtw@mail.gmail.com>

routeviews peering tuned up this weekend... in ashburn equinix.

kemp and his folk are normally quite respsnsive, are you sure your
mail got to them?

On Tue, Dec 8, 2015 at 11:36 AM, Paul S. <contact at winterei.se> wrote:
> RIPE stats also takes a feed similarly.
>
>
> On 12/9/2015 01:24 AM, Kurt Kraut via NANOG wrote:
>>
>> Hi,
>>
>>
>> For the past couple of months I've been attempting to add new Autonomous
>> Systems to the RouteViews project and got no response. Talking to other AS
>> in my area, I wasn't able to find no new BGP operator that got a response
>> from them since July.
>>
>> Is RouteViews dead? If the answer is yes, it is sad. It is the most used
>> resource about the internet routing for multiple perspectives.
>>
>> Is there any other similar project that I could colaborate providing the
>> point of view of my routers have of the internet?
>>
>>
>> Best regards,
>>
>>
>> Kurt Kraut
>
>

From kemp at network-services.uoregon.edu  Tue Dec  8 19:37:13 2015
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Tue, 8 Dec 2015 11:37:13 -0800
Subject: Is RouteViews dead? Is there any alternatives?
In-Reply-To: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
References: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
Message-ID: <56673169.40102@network-services.uoregon.edu>


The problem being discussed here relates to:
route-views.saopaulo.routeviews.org

We do have a lot of outstanding requests for that collector.
But there are some issues there that we need to discuss with
the exchange.  We'll work on getting that moving forward.

Apologies for the lack of response.

John Kemp
help at routeviews.org

On 12/8/15 8:24 AM, Kurt Kraut via NANOG wrote:
> Hi,
> 
> 
> For the past couple of months I've been attempting to add new Autonomous
> Systems to the RouteViews project and got no response. Talking to other AS
> in my area, I wasn't able to find no new BGP operator that got a response
> from them since July.
> 
> Is RouteViews dead? If the answer is yes, it is sad. It is the most used
> resource about the internet routing for multiple perspectives.
> 
> Is there any other similar project that I could colaborate providing the
> point of view of my routers have of the internet?
> 
> 
> Best regards,
> 
> 
> Kurt Kraut
> 

From collin at averysmallbird.com  Tue Dec  8 19:53:13 2015
From: collin at averysmallbird.com (Collin Anderson)
Date: Tue, 8 Dec 2015 14:53:13 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <012401d1288b$3f7d3370$be779a50$@tndh.net>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
Message-ID: <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>

This thread seems to have run its course, but it was an interesting
conversation, so I wanted to flag that the Open Technology Institute is
running what seems to be a fairly balanced panel on the issue in D.C. next
week. Might be worth asking if there's remote participation.

https://newamerica.cvent.com/events/zero-rating-and-net-neutrality-is-free-content-naughty-or-nice-/registration-8e22b15178dc4fa88c2ebe19525262eb.aspx?i=d0db0beb-7340-47c8-8bcc-86d9d6cc85b8

New America
Please note our new address!
740 15th Street NW, Suite 900, Washington, DC 20005
Wednesday, December 16, 2015 | 12:00 pm - 1:45 pm


Even if the D.C. Circuit Court of Appeals upholds the FCC?s Open Internet
Order, the ability of mobile carriers to exclude certain content from the
data caps or buckets that determine what a user pays each month remains
undecided and controversial. Although mobile carriers maintain that
zero-rating selected content is pro-consumer, some consumer advocates argue
the FCC should find it violates network neutrality rules against favoring
some Internet content or applications over others.

In the U.S., T-Mobile recently launched Binge On, which allows consumers to
opt out of the delivery of 'free' (zero-rated) streaming video content at
lower resolution (CD quality), and instead receive content at
high-definition that counts against their data limit. T-Mobile also hosts
Music Freedom, which zero-rates participating streaming music services.

In the developing world, Facebook?s Free Basics initiative partners with
mobile carriers to provide cell phone customers with low-bandwidth versions
of participating information and social media apps (e.g., Wikipedia and
Facebook itself) at no cost in the hope this exposure will encourage them
to upgrade to full Internet access.

Join us for an explanation and debate about zero-rating on mobile networks,
featuring the two companies most visibly marketing the practice, as well as
a range of perspectives from consumer and public interest advocates.

Lunch will be served.

Follow the discussion online using #ZeroRating
and by following us @OTI.

Participants:
Kevin Martin
Vice President for Mobile & Global Access, Facebook
Former Chairman, FCC
@facebook

Mark Cooper
Research Director, Consumer Federation of America
@ConsumerFed

Steve Sharkey
Chief, Engineering and Technology Policy, T-Mobile
@TMobile

Matt Wood
Policy Director, Free Press
@MattFWood

Sarah Morris
Senior Policy Counsel, Open Technology Institute at New America
@sarmorris

Moderator:
Michael Calabrese
Director, Wireless Future Project, Open Technology Institute at New America
@MCalabreseNAF


On Thu, Nov 26, 2015 at 3:44 PM, Tony Hain <alh-ietf at tndh.net> wrote:

> Keenan Tims wrote:
> > To: nanog at nanog.org
> > Subject: Re: Binge On! - And So This is Net Neutrality?
> >
> > I'm surprised you're supporting T-Mob here Owen. To me it's pretty
> > clear: they are charging more for bits that are not streaming video.
> > That's not neutral treatment from a policy perspective, and has no basis
> in
> > the cost of operating the network.
>
> I have no visibility into what the line
> "T?Mobile will work with content providers to ensure that our networks
> work together to properly"
> actually means, but they could/should be using this as a tool to drive
> content sources to IPv6.
>
> Trying to explain to consumers why an unlimited data plan only works for a
> tiny subset of content is a waste of energy. Picking a category and
> "encouraging" that content to move, then after the time limit, pick the
> next category, rinse/repeat, is a way to move traffic away from the 6/4 nat
> infrastructure without having to make a big deal about the IP version to
> the consumer, and at the same time remove "it costs too much" complaints
> from the sources. If I were implementing such a plan, I would walk the list
> of traffic sources based on volume to move traffic as quickly as possible,
> so it makes perfect sense to me that they would start with video.
>
> Tony
>
>
> >
> > Granted, the network itself is neutral, but the purported purpose of NN
> in
> > my eyes is twofold: take away the influence of the network on user and
> > operator behaviour, and encourage an open market in network services
> > (both content and access). Allowing zero-rating based on *any* criteria
> > gives them a strong influence over what the end users are going to do
> with
> > their network connection, and distorts the market for network services.
> > What makes streaming video special to merit zero-rating?
> >
> > I like Clay's connection to the boiling frog. Yes, it's "nice" for most
> > consumers now, but it's still distorting the market.
> >
> > I'm also not seeing why they have to make this so complicated. If they
> can
> > afford to zero-rate high-bandwidth services like video and audio
> streaming,
> > clearly there is network capacity to spare. The user behaviour they're
> > encouraging with free video streaming is *precisely* what the incumbents
> > claimed was causing congestion to merit throttling a few years ago, and
> still
> > to this day whine about constantly. I don't have data, but I would expect
> > usage of this to align quite nicely with their current peaks.
> >
> > Why not just raise the caps to something reasonable or make it unlimited
> > across the board? I could even get behind zero-rating all
> 'off-peak-hours'
> > use like we used to have for mobile voice; at least that makes sense for
> the
> > network. What they're doing though is product differentiation where none
> > exists; in fact the zero-rating is likely to cause more load on the
> system than
> > just doubling or tripling the users'
> > caps. That there seems to be little obvious justification for it from a
> network
> > perspective makes me vary wary.
> >
> > Keenan
> >
> > On 2015-11-23 18:05, Owen DeLong wrote:
> > >
> > >> On Nov 23, 2015, at 17:28 , Baldur Norddahl
> > <baldur.norddahl at gmail.com> wrote:
> > >>
> > >> On 24 November 2015 at 00:22, Owen DeLong <owen at delong.com>
> > wrote:
> > >>
> > >>> Are there a significant number (ANY?) streaming video providers
> > >>> using UDP to deliver their streams?
> > >>>
> > >>
> > >> What else could we have that is UDP based? Ah voice calls. Video
> calls.
> > >> Stuff that requires low latency and where TCP retransmit of stale
> > >> data is bad. Media without buffering because it is real time.
> > >>
> > >> And why would a telco want to zero rate all the bandwidth heavy media
> > >> with certain exceptions? Like not zero rating media that happens to
> > >> compete with some of their own services, such as voice calls and video
> > calls.
> > >>
> > >> Yes sounds like net neutrality to me too (or not!).
> > >>
> > >> Regards,
> > >>
> > >> Baldur
> > >
> > > All T-Mobile plans include unlimited 128kbps data, so a voice call is
> > > effectively already zero-rated for all practical purposes.
> > >
> > > I guess the question is: Is it better for the consumer to pay for
> > > everything equally, or, is it reasonable for carriers to be able to
> > > give away some free data without opening it up to everything?
> > >
> > > To me, net neutrality isn?t as much about what you charge the customer
> > > for the data, it?s about whether you prioritize certain classes of
> > > traffic to the detriment of others in terms of service delivery.
> > >
> > > If T-Mobile were taking money from the video streaming services or
> > > only accepting certain video streaming services, I?d likely agree with
> > > you that this is a neutrality issue.
> > >
> > > However, in this case, it appears to me that they aren?t trying to
> > > give an advantage to any particular competing streaming video service
> > > over the other, they aren?t taking money from participants in the
> program,
> > and consumers stand to benefit from it.
> > >
> > > If you see an actual way in which it?s better for everyone if T-Mobile
> > > weren?t doing this, then please explain it. If not, then this strikes
> > > me as harmless and overall benefits consumers.
> > >
> > > Owen
> > >
>
>


-- 
*Collin David Anderson*
averysmallbird.com | @cda | Washington, D.C.

From jfmezei_nanog at vaxination.ca  Wed Dec  9 04:46:08 2015
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Tue, 8 Dec 2015 23:46:08 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
Message-ID: <5667B210.8050208@vaxination.ca>

Side question:

Since the OP mentioned a "ransom" demand (aka: extortion), should law
enforcement be contacted in such cases ? Is there any experience doing
this ? Are they any help ?

In North america, would that mean FBI in USA and RCMP in Canada, or
local police force which then escalates to proper law enforcement agency ?

From rdobbins at arbor.net  Wed Dec  9 06:07:17 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 09 Dec 2015 13:07:17 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <5667B210.8050208@vaxination.ca>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <5667B210.8050208@vaxination.ca>
Message-ID: <C544E426-1C52-4BF8-8A77-21811A2226A0@arbor.net>

On 9 Dec 2015, at 11:46, Jean-Francois Mezei wrote:

> Since the OP mentioned a "ransom" demand (aka: extortion), should law 
> enforcement be contacted in such cases ?

Yes.

> Is there any experience doing this ?

Yes.

> Are they any help ?

Operationally, no.  Investigatively, possibly.

>
> In North america, would that mean FBI in USA and RCMP in Canada

Yes.

> or local police force which then escalates to proper law enforcement 
> agency ?

If you're asking about US and/or Canada, the relevant national LEA 
generally applies.  In other jurisdictions, it's situationally-specific.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From nanogml at Mail.DDoS-Mitigator.net  Wed Dec  9 15:31:33 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Wed, 9 Dec 2015 07:31:33 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <5667B210.8050208@vaxination.ca>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <5667B210.8050208@vaxination.ca>
Message-ID: <20151209153133.GA20362@Mail.DDoS-Mitigator.net>


hi jean-f

On 12/08/15 at 11:46pm, Jean-Francois Mezei wrote:
> Since the OP mentioned a "ransom" demand (aka: extortion), should law
> enforcement be contacted in such cases ?

simply saying "these bozo's are attempting to extort $100 from me"
with their email demands probably will not get the law enforcements attention

yes ... only after you have done everything you can and ready to take
the attackers to court but need law enforcement to haul them into court
and/or seize their computers for evidence

- (ntpdate/ntpd) sync your clock so that your logs have accurate time 

- check the ip# of the email servers and routers it came thru

  you may or may not need to worry about spoof'ed ip# since they 
  want you to get hold of them to give um the $$

- contact the abuse at -the-ISP  for each of those routers and servers
	- traceroute the IP# of the mail servers 
	- "whois IP#" and contact each of the ISPs

- contact the ISPs that provide connectivity to your "drop off point"
  of where you "supposed to pay up" ... we're assuming that the
  dropoff point is NOT controlled/owned by the ddos attackers

- since you know what time/date/etc that they threaten to attack,
  you should verify your data on the backup systems
  ( build a clone and keep it offline )

  everybody ( you, the ISP, cops, etc ) can all be watching the 
  DDoS attacks and tracing it back to the originating script kiddie
  or the entire extortion network

  you should also get secondary connectivity to watch the DDoS attacks
  in progress and trace it back to the originating source

  let them attack ( the honeypot ) so you can trace it back...

  tarpit all the tcp-based services so that you have 2minutes to 
  trace the attacks back to them ... they cannot "hang up" until 
  the tcp connection attempts times out

- when everything is setup ... tell the DDoS attackers the $$$
  is ready for pickup and watch the DDoS attackers attempt to
  collect the $$$ that doesn't really exist

> Is there any experience doing this ? 

yup...

> Are they any help ?

nope if you don't have the info they want see .. 

you should make it easy for them to take action to get court orders 
to haul them in

yup ... if the cops are trying to collect evidence "on the DDoS attackers"
you'd be in luck

yup ... if the DDoS attackers are large enough and/or if they're attacking 
the high profile victims

> In North america, would that mean FBI in USA and RCMP in Canada, or
> local police force which then escalates to proper law enforcement agency ?

escalation starts with you to provide all the necessary info ...
nobody else will be doing that work for you

get hold of the security dept of your ISP  and any other ISP
along the traceroute and whois iP# way back to the DDoS attackers 

ISPs probably have their favorite agents they like to work with
to chase down the xxx-most-wanted DDoS attackers

magic pixie dust
alvin
# DDoS-Mitigator.net


From brandon at burn.net  Wed Dec  9 15:32:30 2015
From: brandon at burn.net (Brandon Applegate)
Date: Wed, 9 Dec 2015 10:32:30 -0500
Subject: IEEE OUI regauth (search ?) site
Message-ID: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>

They?ve made some changes recently - I had a perl script that would do the lookup and scrape live - it was great.  It broke a week or so ago.

This seems to be the page to search for OUI:

https://regauth.standards.ieee.org/standards-ra-web/pub/view.html <https://regauth.standards.ieee.org/standards-ra-web/pub/view.html>

I?ve tried 4 Browsers across 2 OS?s - and that page pops up a ?Loading? sub window - flashes and reloads (loop).

Anyone have any insight on how one can look up an OUI (yes I know about oui.txt, but I?m asking about a live query site).

Thanks in advance.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
"SH1-0151.  This is the serial number, of our orbital gun."

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

From lists at quux.de  Wed Dec  9 15:43:47 2015
From: lists at quux.de (Jens Link)
Date: Wed, 09 Dec 2015 16:43:47 +0100
Subject: IEEE OUI regauth (search ?) site
In-Reply-To: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net> (Brandon
 Applegate's message of "Wed, 9 Dec 2015 10:32:30 -0500")
References: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
Message-ID: <87y4d37hl8.fsf@pc8.berlin.quux.de>

Brandon Applegate <brandon at burn.net> writes:

Hi,

> Anyone have any insight on how one can look up an OUI (yes I know about
> oui.txt, but I?m asking about a live query site).

https://www.wireshark.org/tools/oui-lookup.html  ?

Jens
-- 
----------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink at quux.de        | ---------------  | 
----------------------------------------------------------------------------

From royce at techsolvency.com  Wed Dec  9 15:44:05 2015
From: royce at techsolvency.com (Royce Williams)
Date: Wed, 9 Dec 2015 06:44:05 -0900
Subject: IEEE OUI regauth (search ?) site
In-Reply-To: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
References: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
Message-ID: <CA+E3k91SSCPqw-yuC5jW+19giJ-PEe9RK=FR1eturFY5oZy90w@mail.gmail.com>

On Wed, Dec 9, 2015 at 6:32 AM, Brandon Applegate <brandon at burn.net> wrote:

> They?ve made some changes recently - I had a perl script that would do the
> lookup and scrape live - it was great.  It broke a week or so ago.
>
> This seems to be the page to search for OUI:
>
> https://regauth.standards.ieee.org/standards-ra-web/pub/view.html <
> https://regauth.standards.ieee.org/standards-ra-web/pub/view.html>
>
> I?ve tried 4 Browsers across 2 OS?s - and that page pops up a ?Loading?
> sub window - flashes and reloads (loop).
>
> Anyone have any insight on how one can look up an OUI (yes I know about
> oui.txt, but I?m asking about a live query site).
>
> Thanks in advance.
>

I know that you've asked about using it live, but IMO, you should
reconsider.

Given the latency between the creation of a new OUI and it showing up in a
given environment, live scraping is significant overkill.  Platforms like
Forescout pull it about once a quarter, IIRC.

Pulling the text file is also probably significantly more reliable than any
given web interface, as you've already discovered.

And if you cache the whole text file locally, there's no way that anyone
external to your organization -- even IEEE -- can tell which OUIs you are
looking up.

Royce

From henry at AegisInfoSys.com  Tue Dec  8 02:40:47 2015
From: henry at AegisInfoSys.com (Henry Yen)
Date: Mon, 7 Dec 2015 21:40:47 -0500
Subject: Modem as a service?
In-Reply-To: <5665C7C9.5080600@cox.net>
References: <8078ED370ADA824281219A7B5BADC39B6D3D6DDA@MBX023-W1-CA-4.exch023.domain.local>
 <CAPz7E52ZS_TKyjYHazFxzznqNrMrKpg51Oa9kqopnHi7kOggiQ@mail.gmail.com>
 <CAPz7E53NdTohgHf_jbF=KZJTRcTe3vRdYyis1a76Tm-BVDE-NA@mail.gmail.com>
 <8078ED370ADA824281219A7B5BADC39B6D3D7B6F@MBX023-W1-CA-4.exch023.domain.local>
 <8F4B1FAF-9CEE-4046-99DE-D7CE4BC801AA@consultant.com>
 <1449440229.2876.10.camel@karl> <5665C7C9.5080600@cox.net>
Message-ID: <20151208024047.GI20120@nntp.AegisInfoSys.com>

On Mon, Dec 07, 2015 at 11:54:17AM -0600, Larry Sheldon wrote:
> I'll join the confusion--I thought the OP wanted to test for power 
> availability at the distant site by seeing if a modem there would answer 
> the phone there.  That it HAD to be a modem in that case makes no sense 
> to me.
> 
> I'm of the line now and have been for a while and maybe y'all don't do 
> things the way we did--we always had an answering machine (two or three 
> in some places*) that always answered on the first ring and gave some 
> kind of status report that was updated hourly on on event).  If it did 
> not answer, the power was out.

At a client wiring closet, the super-conscientious rack maintainer one day
decided that it was good practice to replace consumer-standard batteries
during his quarterly cleaning rounds.

Answering machines have replaceable batteries. Modems do not.

-- 
Henry Yen <Henry.Yen at Aegis00.com>               Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York
(800) AEGIS-00 x949                             1-800-AEGIS-00 (800-234-4700)


From felipe at starbyte.net  Tue Dec  8 12:07:11 2015
From: felipe at starbyte.net (Felipe Zanchet Grazziotin)
Date: Tue, 8 Dec 2015 12:07:11 +0000
Subject: Looking for VPS providers with BGP session
In-Reply-To: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
References: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
Message-ID: <CAAvATDacS=H70DmydJ0za5fo3OS3DJ3An99mnQb_xtDGKLAs4w@mail.gmail.com>

Hi,

you might find useful to see Nat Morris's presentation on "Anycast on a
shoe string".
He lists several VPS providers that do BGP for his project.

Here is one link:
http://www.slideshare.net/natmorris/anycast-on-a-shoe-string

Regards,
Felipe


On 7 December 2015 at 12:40, Philippe Bonvin via NANOG <nanog at nanog.org>
wrote:

> Hello,
>
>
> I'm looking for providers around the world who are able to provide VPS
> with a BGP session but it seems to be rather difficult to find. I have
> already found a few with WHT/bgp.he.net/google but a little help would be
> appreciated.
>
>
> Does anyone have contact or know people who can offer such services ?
>
> If yes, please contact me off list.
>
>
> Our budget is quite low: around 50$/month/node +/- 50$ depending the
> transit providers for a server with 1-2 CPU cores, 20 Go SSD or SAS and 1-2
> Go RAM.
>
>
> I'll be happy to share my provider list we use with anyone who needs it.
>
>
> Thanks for your help,
>
> Philippe
>
> [EDSI-Tech Sarl]<http://www.edsi-tech.com>
> Philippe Bonvin, Directeur
> EDSI-Tech S?rl<http://www.edsi-tech.com>
> EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41
> (0) 21 566 14 15
> Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France
> | T?l?phone: +33 (0)4 86 15 44 78
>

From lear at cisco.com  Tue Dec  8 12:26:34 2015
From: lear at cisco.com (Eliot Lear)
Date: Tue, 8 Dec 2015 13:26:34 +0100
Subject: IGF Mandate Renewl
In-Reply-To: <m2io49x0rb.wl%randy@psg.com>
References: <CY1PR07MB22003758766B65A03D321E83FA090@CY1PR07MB2200.namprd07.prod.outlook.com>
 <634D9AB2-94B4-4CFD-A06C-BCAD3ADC5E86@delong.com>
 <CAL9jLabvogF_s+HiH1vxeCTq+MK3r_FgmRo=7Ngy14=15f3X-w@mail.gmail.com>
 <m2io49x0rb.wl%randy@psg.com>
Message-ID: <5666CC7A.5050407@cisco.com>



On 12/8/15 1:06 AM, Randy Bush wrote:
> they eat better food than we do

Not in my considerable experience.  I always thought that was part of
the problem.

Eliot


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151208/af85c331/attachment.pgp>

From ashwin at pch.net  Tue Dec  8 19:23:57 2015
From: ashwin at pch.net (Ashwin Jacob Mathew)
Date: Tue, 8 Dec 2015 11:23:57 -0800
Subject: Is RouteViews dead? Is there any alternatives?
In-Reply-To: <F64B1357-DC79-46F9-BD48-7A3D1B96B381@pch.net>
References: <CAPbn28kU479kC6NT5=QDZ_FLLRx4F_abjCUfegFx0ea1gvhnXg@mail.gmail.com>
 <F64B1357-DC79-46F9-BD48-7A3D1B96B381@pch.net>
Message-ID: <56672E4D.4020102@pch.net>

PCH maintains routing archives here:
https://www.pch.net/resources/Raw_Routing_Data/

In aggregate, our AS3856 collects routes from 1307 distinct ASNs spread
across 82 IXPs.

> *From:* Kurt Kraut via NANOG <nanog at nanog.org <mailto:nanog at nanog.org>>
> *Date:* December 8, 2015 at 08:24:31 PST
> *To:* NANOG list <nanog at nanog.org <mailto:nanog at nanog.org>>
> *Subject:* *Is RouteViews dead? Is there any alternatives?*
> *Reply-To:* Kurt Kraut <listas at kurtkraut.net
> <mailto:listas at kurtkraut.net>>
>
> Hi,
>
>
> For the past couple of months I've been attempting to add new Autonomous
> Systems to the RouteViews project and got no response. Talking to other AS
> in my area, I wasn't able to find no new BGP operator that got a response
> from them since July.
>
> Is RouteViews dead? If the answer is yes, it is sad. It is the most used
> resource about the internet routing for multiple perspectives.
>
> Is there any other similar project that I could colaborate providing the
> point of view of my routers have of the internet?
>
>
> Best regards,
>
>
> Kurt Kraut


From mailman at tuxcon.com  Wed Dec  9 04:08:15 2015
From: mailman at tuxcon.com (Stephen)
Date: Wed, 9 Dec 2015 14:38:15 +1030
Subject: Ransom DDoS attack - need help!
In-Reply-To: <F7C9EFAE-AEFF-4F1C-A641-FC995F2EEE2E@hammerfiber.com>
References: <CAA3uY602BOVHFLFK0dhp1irvKdfRDb9A1HJLEM3_hrt+FkCtYw@mail.gmail.com>
 <56605F30.4090203@foobar.org>
 <F7C9EFAE-AEFF-4F1C-A641-FC995F2EEE2E@hammerfiber.com>
Message-ID: <20151209040815.GC4366@lancelot>

I believe that is what he meant, yeah. Figurative opening of the bank
account - showing them that you're willing to pay makes you a target
for future payments as well.
On Thu, 03 Dec 2015, Daniel Corbe wrote:

> 
> > On Dec 3, 2015, at 10:26 AM, Nick Hilliard <nick at foobar.org> wrote:
> > 
> > On 03/12/2015 08:15, halp us wrote:
> >> a very well known group that has been in the news lately. Recently they've
> >> threatened to carry out a major DDoS attack if they are not paid by a
> >> deadline which is approaching. They've performed an attack of a smaller
> >> magnitude to prove that they're serious.
> > 
> > bear in mind that if you pay a ransom like this:
> > 
> > 1. you're opening up a bank account for them to dip into whenever they feel
> > they need more money.
> 
> Most of these types of service ransom deals are conducted via bitcoin.  So I don?t see how this could be the case unless you mean to say that appeasing your attackers is a bad idea because they might just be emboldened enough to try and extort you again whenever the piggy bank is beginning to run dry.
> 

From alberto at caida.org  Wed Dec  9 04:24:50 2015
From: alberto at caida.org (Alberto Dainotti)
Date: Tue, 8 Dec 2015 20:24:50 -0800
Subject: CAIDA BGP Hackathon 6,7 Feb 2016 -- Call for Participation 
Message-ID: <7008071D-7B7B-461B-9EF8-8C2827E4E6DB@caida.org>

What: CAIDA BGP Hackathon, Call for Participation (CFP)
When: Feb 6-7, 2016
Where: the San Diego Supercomputer Center (SDSC) on the University of
California at San Diego (UCSD) campus.
Who: Parties interested in hacking on live BGP data.
Inquiries: bgp-hackathon-info at caida.org
Important Deadline: Dec 22, 2015 for travel grant requests
Apply to attend: http://www.caida.org/workshops/bgp-hackathon/1602/ 


CAIDA, in cooperation with CSU, USC, UFMG, FORTH, Route Views, RIPE
NCC, will host a BGP Hackathon on the 6-7th of February 2016 at UC San
Diego (La Jolla, CA, USA).
The theme of the hackathon is ?live BGP measurements and monitoring?.

We will provide participating teams with access to data sources and a
toolbox: live streaming of BGP data, the new BGPMon interface, BGP
processing tools and APIs such as the opensource BGPStream software
framework, the PEERING testbed, RIPE RIS, visualization tools, and
data-plane active measurement platforms such as CAIDA Ark and RIPE
Atlas. Participating teams will work on "challenges" that extend,
integrate and demonstrate the utility of these platforms/data for
understanding or solving practical problems (e.g., detecting BGP
prefix hijacking, evaluating anycast performance, effectively
visualizing phenomena).

The hackathon will be held in San Diego the weekend immediately
preceding the NANOG conference and the AIMS academic Internet
measurement workshop.
The hackathon aims to:
- bring together these different communities, e.g., to discuss
  problems operators face that academics may want to research;
- advertise tools (e.g., PEERING peering.usc.edu, BGPStream
  bgpstream.caida.org) to the communities and get people familiar with
  using them, and encourage further use in the future;
- get people working together on interesting/important problems,
  hopefully spurring further collaboration on these problems;
- provide extra incentive for students to attend NANOG.  

### FORMAT
Each team of 2-4 people will work on a "challenge".
The organization committee will propose a set of challenges to
bootstrap feedback and refinement based on community input:
participants can propose totally new challenges, modifications to
existing ones, and express their preferences.
The set of potential challenges is described in the event website at
https://github.com/CAIDA/bgp-hackathon/wiki/List-of-Challenges
and will continuously evolve in the days preceding the hackathon. 

On Saturday morning, participants will very briefly introduce their
interests and ideas and teams will be officially formed. On Saturday
and Sunday, participants will work together in teams to hack and
develop their ideas, culminating in very short presentations to the
jury on Sunday evening and a party to announce the winning teams and
celebrate everyone's participation.
During the event, domain-experts will provide support to the teams.

Participants are free to work on drafted challenges and on their own
ideas in the days preceding the hackathon. A mailing list and
documentation will provide support on the platforms/tools/data used in
the hackathon. However, for the teams to compete in the hackathon for
prizes, they will have to demonstrate that substantial work was done
during the two-day event.
 
### PARTICIPATION AND TRAVEL GRANTS
Application to participate in the hackathon is open from December
8, 2016. Application does not guarantee participation. There is no
application fee, and no participation fee.  We will accept
applications until one week before the hackathon, or until capacity is
reached. However, the deadline to apply for a travel grant (through
the hackathon application form) is 22 December 2015. Travel grants
reimburse flights and hotel expenses.
Food and drinks will be provided throughout the two-day event.

http://www.caida.org/workshops/bgp-hackathon/1602/



From joe at joesdatacenter.com  Tue Dec  8 07:24:34 2015
From: joe at joesdatacenter.com (Joe Morgan)
Date: Tue, 8 Dec 2015 01:24:34 -0600
Subject: Ransom DDoS attack - need help!
Message-ID: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>

We received a similar ransom e-mail yesterday followed by a UDP flood
attack. Here is a sample of the attack traffic we received as well as a
copy of the ransom e-mail. Thought this might be useful to others who have
been targeted as well. I will have to talk with our upstream providers to
get a definitive on the size of the attacks. At the point in time we
blackholed our ip we were seeing 20+Gbps.

*Dec/07/2015 5:40:22PM *Here is a summary of the flows to our web server IP
during the ddos event:
================================================

Top 10 flows by packets per pecond for dst IP: 96.43.134.147
  Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
     0.001 UDP      175.43.224.99  1900  22456    2048    2.0 M    5.8 G
     0.002 UDP    120.199.113.49  1900  54177    2048    1.0 M    2.8 G
     0.002 UDP    27.208.164.227  1900  54177    2048    1.0 M    2.7 G
     0.002 UDP      60.209.31.218  1900  16632    2048    1.0 M    3.0 G
     0.002 UDP      27.220.71.238  1900  22456    2048    1.0 M    3.0 G
     0.002 UDP      120.236.121.9  1900  62005    2048    1.0 M    2.5 G
     0.002 UDP    104.137.222.90  1900  14944    2048    1.0 M    3.7 G
     0.002 UDP      121.27.133.72  1900  44417    2048    1.0 M    3.0 G
     0.002 UDP        92.241.8.75    53  5575    2048    1.0 M  12.4 G
     0.002 UDP    120.197.56.134  1900  30672    2048    1.0 M    2.7 G

Top 10 flows by flows per second for dst IP: 96.43.134.147
  Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
   248.847 UDP      41.214.2.249    123  47207    8.6 M    34594  133.4 M
   248.886 UDP    91.208.136.126    123  63775    6.7 M    26813  103.4 M
   150.893 UDP      85.118.98.253    123  47207    5.1 M    33843  130.5 M
   151.053 UDP      80.179.166.7    123  63775    5.0 M    33292  128.4 M
   151.230 UDP      69.31.105.142    123  47207    4.9 M    32657  125.9 M
   150.436 UDP      182.190.0.17    123  45291    4.8 M    32128  123.9 M
   248.832 UDP      95.128.184.10    123  63775    4.7 M    19020  73.3 M
   150.573 UDP      188.162.13.4    123  42571    4.6 M    30514  117.7 M
   150.261 UDP      205.128.68.5    123  45291    4.2 M    27777  107.1 M
   149.962 UDP      205.128.68.5    123  42571    4.1 M    27443  105.8 M

Top 10 flows by bits per second for dst IP: 96.43.134.147
  Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
     0.002 UDP        92.241.8.75    53  5575    2048    1.0 M  12.4 G
     0.003 UDP    190.184.144.74    53  18340    2048  682666    8.3 G
     0.003 UDP    190.109.218.69    53  63492    2048  682666    8.3 G
     0.004 UDP    103.251.48.245    53  43701    2048  512000    6.2 G
     0.004 UDP    46.149.191.239    53  58439    2048  512000    6.2 G
     0.001 UDP      175.43.224.99  1900  22456    2048    2.0 M    5.8 G
     0.006 UDP        37.72.70.85    53  63909    2048  341333    4.1 G
     0.006 UDP    138.204.178.169    53  2162    2048  341333    4.1 G
     0.006 UDP      200.31.97.107    53  33765    2048  341333    4.1 G
     0.006 UDP      110.164.58.82    53  61397    2048  341333    4.1 G

================================================

Copy of the e-mail headers:

Delivered-To: joe at joesdatacenter.com
Received: by 10.79.27.84 with SMTP id b81csp1190623ivb;
        Mon, 7 Dec 2015 15:32:22 -0800 (PST)
X-Received: by 10.25.88.208 with SMTP id m199mr28948lfb.157.1449531142088;
        Mon, 07 Dec 2015 15:32:22 -0800 (PST)
Return-Path: <armada.collective at bk.ru>
Received: from f369.i.mail.ru (f369.i.mail.ru. [217.69.141.11])
        by mx.google.com with ESMTPS id 7si214394lfk.103.2015.12.07.15.32.21
        for <joe at joesdatacenter.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 07 Dec 2015 15:32:22 -0800 (PST)
Received-SPF: pass (google.com: domain of armada.collective at bk.ru
designates 217.69.141.11 as permitted sender) client-ip=217.69.141.11;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of armada.collective at bk.ru
designates 217.69.141.11 as permitted sender)
smtp.mailfrom=armada.collective at bk.ru;
       dkim=pass header.i=@bk.ru;
       dmarc=pass (p=NONE dis=NONE) header.from=bk.ru
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=bk.ru; s=mail;
	h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From;
bh=1BpwCe2lM8814gJCW/09LwlVtrY6pZtMIFMB0Eprzmw=;
	b=DKaMWqtH3zre6+R+qmC6+5DTa/o3zx58ubNGalhnEP8cJUtZ/Ln8DnxkQojAdL46g06xlY8rl2QhH07Rm/BHMG9ahsqKSW59F04vcrSv6m6vLnu+4GVwW0ZnRrbkYIaKJohosgdUzUMew9naxuDpF+fD1UqPKCqSs2jgu5071Dw=;
Received: from [95.191.131.93] (ident=mail)
	by f369.i.mail.ru with local (envelope-from <armada.collective at bk.ru>)
	id 1a65GX-0008H5-DO
	for joe at joesdatacenter.com; Tue, 08 Dec 2015 02:32:21 +0300
Received: from [95.191.131.93] by e.mail.ru with HTTP;
	Tue, 08 Dec 2015 02:32:21 +0300
From: =?UTF-8?B?QXJtYWRhIENvbGxlY3RpdmU=?= <armada.collective at bk.ru>
To: joe at joesdatacenter.com
Subject: =?UTF-8?B?UmFuc29tIHJlcXVlc3Q6IEREb1MgQXR0YWNr?=
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
X-Originating-IP: [95.191.131.93]
Date: Tue, 08 Dec 2015 02:32:21 +0300
Reply-To: =?UTF-8?B?QXJtYWRhIENvbGxlY3RpdmU=?= <armada.collective at bk.ru>
X-Priority: 3 (Normal)
Message-ID: <1449531141.2696669 at f369.i.mail.ru>
Content-Type: multipart/alternative;
	boundary="--ALT--7N12aTwEB8hvVlFgA0NbUaD4Daicjipu1449531141"
X-Mras: Ok
X-Spam: undefined

Copy of the e-mail:
From: Armada Collective <armada.collective at bk.ru>
Subject: Ransom request: DDoS Attack

Message Body:
FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE
DECISION!


We are Armada Collective.

If you haven heard for us, use Google. Recently, we have launched some of
the largest DDoS attacks in history.
Check this out, for example:
https://twitter.com/optucker/status/665470164411023360 (and it was measured
while we were DDoS-ing 3 other sites at the same time)
And this: https://twitter.com/optucker/status/666501788607098880

We will start DDoS-ing your network if you don't pay 20 Bitcoins @
19zErvraWpnLj4Ga7nsLXh8C52g1zogYJe by Wednesday.


Right now we will start small 30 minutes UDP attack on your site IP:
96.43.134.147 It will not be hard, just to prove that we are for real
Armada Collective.

If you don't pay by Wednesday, massive attack will start, price to stop
will increase to 40 BTC and will go up 2 BTC for every hour of attack and
attack will last for as long as you don't pay.

In addition, we will be contacting affected customers to explain why they
are down and recommend them to move to OVH. We will do the same on social
networks.

Our attacks are extremely powerful - peaks over 1 Tbps per second.

Prevent it all with just 20 BTC @ 19zErvraWpnLj4Ga7nsLXh8C52g1zogYJe


Do not reply, we will not read. Pay and we will know its you. AND YOU WILL
NEVER AGAIN HEAR FROM US!

And nobody will ever know you cooperated.

-- 
Thank You,
Joe Morgan - Owner
Joe's Datacenter, LLC
http://joesdatacenter.com
816-726-7615

From nanogml at Mail.DDoS-Mitigator.net  Thu Dec 10 00:48:19 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Wed, 9 Dec 2015 16:48:19 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
References: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
Message-ID: <20151210004819.GA30006@Mail.DDoS-Mitigator.net>


hi joe

On 12/08/15 at 01:24am, Joe Morgan wrote:
> We received a similar ransom e-mail yesterday 

:-)

dont pay real $$$ ... pretend that it was paid and watch for
them to come get the ransom ... never give your real banking info

ask them, where do you send the "$xx,000" mastercard gift card
by fedex/ups/dhl ... law enforcement might get lucky with real 
physical addresses ... once in a while, there are dumb criminals
that show up on tv news

> followed by a UDP flood attack. 

*pout* or not  ... their demo shows they've got the zombie botnet
capable of sending 20+Gbps .... law enforcement and ISP security dept 
"should be interested" to trace them down ... but it takes
tons of (their) resources to take the next steps: who is it and
where are the attackers

*pout* ... udp ddos floods are "expensive" to solve ...

unfortunately, you cannot mitigate any incoming UDP-ddos attacks at your
server/router.... udp mitigation has to be done by"
- somehow, you need to find out who they are etc and legally seize their botnet
- your upstream ISP/peer whom doesn't send it to you
- or you setup and 2nd pipe at a geographically different colo ( cheaper )
- or you first send your udp traffic thru a ( expensive ) ddos scrubber

the idea of "limit" the udp traffic is basically useless, since
udp packets already came down the wire ... 

you should at least not reply to any udp ddos packet 
- don't send "host not available", etc etc

> Here is a sample of the attack traffic we received as well as a
> copy of the ransom e-mail. Thought this might be useful to others who have
> been targeted as well. I will have to talk with our upstream providers to
> get a definitive on the size of the attacks. At the point in time we
> blackholed our ip we were seeing 20+Gbps.
> 
> *Dec/07/2015 5:40:22PM *Here is a summary of the flows to our web server IP
> during the ddos event:

since it is a webserver they're playing with ... there's "dozen" things you
can do to mitigate the UDP flood attacks
- web server should only be running apache ...
  remove ntpd, bind, etc, etc, etc aka, remove the risks of udp amplification
- make sure required things like ntpd/sshd etc are using local non-routable ip#
- long common sense list of stuff to do ... including the 4 points listed above

everybody would want the timezone so they can check their "bandwidth" monitor
to see if 20Gbps hurts them too

> Top 10 flows by packets per pecond for dst IP: 96.43.134.147
>   Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
>      0.001 UDP      175.43.224.99  1900  22456    2048    2.0 M    5.8 G
>      0.002 UDP    120.199.113.49  1900  54177    2048    1.0 M    2.8 G
>      0.002 UDP    27.208.164.227  1900  54177    2048    1.0 M    2.7 G

what app do yu have that talks to port 1900 ?

these are probably spoof'd src address .... but you will never know
until you look up these ip# to see if there is any common link to it
like it all belonging to the same zombie net

for all ListofZombiehosts
do
 - whois 175.43.224.99
 - traceroute 175.43.224.99
done

- udp is primarily used for ntp, dns, nfs, x11, snmp, etc
  if the service is not used, turn off the ntp/bind/nfsd/X11/snmpd daemons

> Top 10 flows by flows per second for dst IP: 96.43.134.147
>   Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
>    248.847 UDP      41.214.2.249    123  47207    8.6 M    34594  133.4 M
>    248.886 UDP    91.208.136.126    123  63775    6.7 M    26813  103.4 M
>    150.893 UDP      85.118.98.253    123  47207    5.1 M    33843  130.5 M

they like to play with ntpd ... make sure your NTPd sw is patched

> Top 10 flows by bits per second for dst IP: 96.43.134.147
>   Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
>      0.002 UDP        92.241.8.75    53  5575    2048    1.0 M  12.4 G
>      0.003 UDP    190.184.144.74    53  18340    2048  682666    8.3 G
>      0.003 UDP    190.109.218.69    53  63492    2048  682666    8.3 G

they like to play with DNS ... make sure your bind sw is patched and
properly configured ( not open resolver, etc )

> ================================================
> 
> Copy of the e-mail headers:
> 
> Delivered-To: joe at joesdatacenter.com
> Received: by 10.79.27.84 with SMTP id b81csp1190623ivb;
>         Mon, 7 Dec 2015 15:32:22 -0800 (PST)

i assume this ip# is your own local lan ?

> X-Received: by 10.25.88.208 with SMTP id m199mr28948lfb.157.1449531142088;
>         Mon, 07 Dec 2015 15:32:22 -0800 (PST)
> Return-Path: <armada.collective at bk.ru>

something tangible to trace/monitor

good luck trying to get bk.ru and their ISP to help resolve the ransom issue

	traceroute bk.ru
	traceroute mail.ru

	traceroute 217.69.141.11
	traceroute 95.191.131.93

	whois 217.69.141.11
	whois 95.191.131.93

politely rattle the security cages of the NOC for each of the ISPs that
is listed in traceroute and especially the IP# owner

> Received: from f369.i.mail.ru (f369.i.mail.ru. [217.69.141.11])
>         by mx.google.com with ESMTPS id 7si214394lfk.103.2015.12.07.15.32.21
>         for <joe at joesdatacenter.com>
...

> Received: from [95.191.131.93] (ident=mail)
> 	by f369.i.mail.ru with local (envelope-from <armada.collective at bk.ru>)
....
> Received: from [95.191.131.93] by e.mail.ru with HTTP;
> 	Tue, 08 Dec 2015 02:32:21 +0300
> From: =?UTF-8?B?QXJtYWRhIENvbGxlY3RpdmU=?= <armada.collective at bk.ru>
....

> X-Mailer: Mail.Ru Mailer 1.0

looks like they are using webmail ??

> X-Originating-IP: [95.191.131.93]

mail.ru knows exactly who is/was using their ip# 95.191.131.93 at 02:32:21 +0300

> Date: Tue, 08 Dec 2015 02:32:21 +0300
> Reply-To: =?UTF-8?B?QXJtYWRhIENvbGxlY3RpdmU=?= <armada.collective at bk.ru>

...
 
> If you haven heard for us, use Google. Recently, we have launched some of
> the largest DDoS attacks in history.
> Check this out, for example:
> https://twitter.com/optucker/status/665470164411023360 (and it was measured
> while we were DDoS-ing 3 other sites at the same time)
> And this: https://twitter.com/optucker/status/666501788607098880
> 
> We will start DDoS-ing your network if you don't pay 20 Bitcoins @
> 19zErvraWpnLj4Ga7nsLXh8C52g1zogYJe by Wednesday.

orders of magnitude cheaper than tracking down who it is that sent
the email and chasing down their botnet

everybody in the world, should not be using any of the products/services
whom also support bitcoin or any other anonymous payment methods

> Right now we will start small 30 minutes UDP attack on your site IP:
> 96.43.134.147 It will not be hard, just to prove that we are for real
> Armada Collective.

tough group .... the FBI, interpol and especially the russian law 
enforcement group should be interested to get hold of them ... 
it will be expensive in time to track them down while they collect
enough $$$ from lots of folks that dont want to deal with the 
primary issue of ransoms

> If you don't pay by Wednesday, massive attack will start, price to stop
> will increase to 40 BTC and will go up 2 BTC for every hour of attack and
> attack will last for as long as you don't pay.
> 
> In addition, we will be contacting affected customers to explain why they
> are down and recommend them to move to OVH. We will do the same on social
> networks.

:-)

> Our attacks are extremely powerful - peaks over 1 Tbps per second.

that should be big enough of an issues that all ISPs between them
and you would want to stop it too

it's gonna be expensive in time and staff to play cat-n-mouse with them

> Do not reply, we will not read. Pay and we will know its you. AND YOU WILL
> NEVER AGAIN HEAR FROM US!

:-)

magic pixie dust
alvin
# DDoS-Mitigator.net

From rdobbins at arbor.net  Thu Dec 10 01:28:41 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 10 Dec 2015 08:28:41 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
References: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
Message-ID: <1B9AC094-3677-4730-87C0-B60EAB9201C8@arbor.net>

On 8 Dec 2015, at 14:24, Joe Morgan wrote:

> At the point in time we blackholed our ip we were seeing 20+Gbps.

These two presos discuss extortion DDoS and UDP reflection/amplification 
attacks, specifically - it isn't necessary to resort to D/RTBH to deal 
with these attacks:

<https://app.box.com/s/776tkb82634ewvzvp26nnout6v4ij39q>

<https://app.box.com/s/r7an1moswtc7ce58f8gg>

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From baldur.norddahl at gmail.com  Thu Dec 10 01:38:45 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 10 Dec 2015 02:38:45 +0100
Subject: Ransom DDoS attack - need help!
In-Reply-To: <20151210004819.GA30006@Mail.DDoS-Mitigator.net>
References: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
 <20151210004819.GA30006@Mail.DDoS-Mitigator.net>
Message-ID: <CAPkb-7Bz33D2m8rLBn-U=ZJOcUUZE9+LG9bBjUoHZU8DqRo-cw@mail.gmail.com>

On 10 December 2015 at 01:48, alvin nanog <nanogml at mail.ddos-mitigator.net>
wrote:

> what app do yu have that talks to port 1900 ?
>

UDP 1900 is a "Chargen" UDP reflection attack. The DNS and NTP packets are
also from a reflection attack.

We filter UDP 1900 at our border. Not to protect our network from attack,
although it still helps. The packets might have come down our IP transit
pipes, which are high capacity, but we can still stop it from doing further
damage at the smaller pipes in our access network.

We filter UDP 1900 because too many of our customers run vulnerable CPE
devices that can be abused as a Chargen reflector. We stop that hard by
dropping UDP 1900 both ingress and egress.

He is being hit with a volume based UDP reflection attack. The IP addresses
are not faked. They all lead back to people that run vulnerable CPE
devices, NTP servers or open DNS resolvers.

Reflection attacks require that you have the ability to send out faked IP
addresses. Botnets are generally unable to do that. Their max attack size
is limited by the bandwidth at the server, where they have the ability to
send out faked UDP packets.

Keep attacking you if you do not pay is bad business. They could be
attacking someone who will pay instead. No one has infinite attack
bandwidth available.

Regards,

Baldur

From baldur.norddahl at gmail.com  Thu Dec 10 01:53:35 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 10 Dec 2015 02:53:35 +0100
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAPkb-7Bz33D2m8rLBn-U=ZJOcUUZE9+LG9bBjUoHZU8DqRo-cw@mail.gmail.com>
References: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
 <20151210004819.GA30006@Mail.DDoS-Mitigator.net>
 <CAPkb-7Bz33D2m8rLBn-U=ZJOcUUZE9+LG9bBjUoHZU8DqRo-cw@mail.gmail.com>
Message-ID: <CAPkb-7ApCkxSddmEexJfrDuSEsWDYCy_VZ_79+g7_Eewkh_k8g@mail.gmail.com>

>
>
> On 10 December 2015 at 01:48, alvin nanog <nanogml at mail.ddos-mitigator.net
> > wrote:
>
>> what app do yu have that talks to port 1900 ?
>>
>
> UDP 1900 is a "Chargen" UDP reflection attack. The DNS and NTP packets are
> also from a reflection attack.
>
>
Sorry I was made aware that UDP 1900 is SSDP. We still block it :-) To my
knowledge there is no real use case for it and no user has ever complained
about that being blocked.

Regards,

Baldur

From yang.yu.list at gmail.com  Thu Dec 10 05:52:25 2015
From: yang.yu.list at gmail.com (Yang Yu)
Date: Thu, 10 Dec 2015 13:52:25 +0800
Subject: Looking for VPS providers with BGP session
In-Reply-To: <CAJygYd0Wm9Lt0HOzhYv1ozDjgicxzq484ALLHDQdwPzkee14-A@mail.gmail.com>
References: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
 <CAJygYd0Wm9Lt0HOzhYv1ozDjgicxzq484ALLHDQdwPzkee14-A@mail.gmail.com>
Message-ID: <CAFwKRnSTrn+ZLVuBaELSNOSZ3TUKwATwdC3jfuxNzVwqaJDjDA@mail.gmail.com>

On Tue, Dec 8, 2015 at 8:52 PM, Yucong Sun <sunyucong at gmail.com> wrote:
> I recommend http://www.quadranet.com/ ! I have been a happy customer
> for almost two years,
>
> I have a single dedicated server over there,  running full BGP feed
> with them, It's a fairly extensive setup with multiple sessions,
> automatic null routing and all the communities tinkering! Their NOC is
> very friendly and very easy to work with!
>

I would avoid QuadraNet for VPS services. They refused to give me a
/48 (not even another /64). And it took a shout on WHT for them to
respond to my tickets opened months ago.


Yang

From joe at joesdatacenter.com  Thu Dec 10 06:21:11 2015
From: joe at joesdatacenter.com (Joe Morgan)
Date: Thu, 10 Dec 2015 00:21:11 -0600
Subject: Ransom DDoS attack - need help!
Message-ID: <CAKDS_tnQuFzDj=9QZWO=cDFsf4qnHU2+O1=QtUnkpthZ15TGDg@mail.gmail.com>

Just an update for those following. We have custom in house software that
watches the traffic flows from our edge routers and automatically
blackholes any ip getting targeted. The blackhole gets sent upstream which
is what we did to maintain the network for our customers during the first
attack. We did not suffer any network outage because of the attacks other
than our public facing website which honestly is not critical. Since we
submitted this thread originally we have gotten two responses from "Armada
Collective". One basically a reminder telling us we had 24 hours left to
pay. The next came tonight as they were supposed to be hitting us.  The
second response said they were supposed to be hitting us but decided to
give us two more days to get the cash into bitcoin. As of right now we have
not replied to them and have no plans to do so. We never had plans to
respond or pay them, although telling them whats on my mind sounds
appealing. We have contacted the FBI and are working with them providing
info. As for protecting our network from future attacks we put all public
facing web sites behind Cloudflare and changed the ips from what they were.
We left the old ips nulled at our edge and with our providers. We plan to
null any ip they decide to hit and and wait it out. As of right now all
they have done is take our website offline briefly so not much of a
problems as it has not caused our customers issues. Thanks for all the help
and info that has been provided and we plan to update this thread as things
unfold. I know there are others that have had similar demands (several have
reached out off list.) so hopefully the info is useful.

-- 
Thank You,
Joe Morgan - Owner
Joe's Datacenter, LLC
http://joesdatacenter.com
816-726-7615

From rdobbins at arbor.net  Thu Dec 10 06:51:45 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 10 Dec 2015 13:51:45 +0700
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAKDS_tnQuFzDj=9QZWO=cDFsf4qnHU2+O1=QtUnkpthZ15TGDg@mail.gmail.com>
References: <CAKDS_tnQuFzDj=9QZWO=cDFsf4qnHU2+O1=QtUnkpthZ15TGDg@mail.gmail.com>
Message-ID: <DC8F44EE-1593-44FA-9B93-D1D78C4E2B7D@arbor.net>

On 10 Dec 2015, at 13:21, Joe Morgan wrote:

> We have custom in house software that watches the traffic flows from 
> our edge routers and automatically blackholes any ip getting targeted.

Suggest you take a look at the presos I posted earlier and look into 
S/RTBH, flowspec, some limited QoS, and some preemptive ACLs so that you 
aren't forced into completing the DDoS.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From colinj at gt86car.org.uk  Thu Dec 10 08:20:35 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Thu, 10 Dec 2015 08:20:35 +0000
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
References: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
Message-ID: <6B88729B-82C6-4707-BD61-FAE85D8CD7CA@gt86car.org.uk>

fingerprint shows China and Russia related as expected
Why do the abuse teams in China and Russia ignore basic abuse reports, why peer/setup connections to companies where abuse is ignored.

Colin

> On 8 Dec 2015, at 07:24, Joe Morgan <joe at joesdatacenter.com> wrote:
> 
> We received a similar ransom e-mail yesterday followed by a UDP flood
> attack. Here is a sample of the attack traffic we received as well as a
> copy of the ransom e-mail. Thought this might be useful to others who have
> been targeted as well. I will have to talk with our upstream providers to
> get a definitive on the size of the attacks. At the point in time we
> blackholed our ip we were seeing 20+Gbps.
> 
> *Dec/07/2015 5:40:22PM *Here is a summary of the flows to our web server IP
> during the ddos event:
> ================================================
> 
> Top 10 flows by packets per pecond for dst IP: 96.43.134.147
>  Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
>     0.001 UDP      175.43.224.99  1900  22456    2048    2.0 M    5.8 G
>     0.002 UDP    120.199.113.49  1900  54177    2048    1.0 M    2.8 G
>     0.002 UDP    27.208.164.227  1900  54177    2048    1.0 M    2.7 G
>     0.002 UDP      60.209.31.218  1900  16632    2048    1.0 M    3.0 G
>     0.002 UDP      27.220.71.238  1900  22456    2048    1.0 M    3.0 G
>     0.002 UDP      120.236.121.9  1900  62005    2048    1.0 M    2.5 G
>     0.002 UDP    104.137.222.90  1900  14944    2048    1.0 M    3.7 G
>     0.002 UDP      121.27.133.72  1900  44417    2048    1.0 M    3.0 G
>     0.002 UDP        92.241.8.75    53  5575    2048    1.0 M  12.4 G
>     0.002 UDP    120.197.56.134  1900  30672    2048    1.0 M    2.7 G
> 
> Top 10 flows by flows per second for dst IP: 96.43.134.147
>  Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
>   248.847 UDP      41.214.2.249    123  47207    8.6 M    34594  133.4 M
>   248.886 UDP    91.208.136.126    123  63775    6.7 M    26813  103.4 M
>   150.893 UDP      85.118.98.253    123  47207    5.1 M    33843  130.5 M
>   151.053 UDP      80.179.166.7    123  63775    5.0 M    33292  128.4 M
>   151.230 UDP      69.31.105.142    123  47207    4.9 M    32657  125.9 M
>   150.436 UDP      182.190.0.17    123  45291    4.8 M    32128  123.9 M
>   248.832 UDP      95.128.184.10    123  63775    4.7 M    19020  73.3 M
>   150.573 UDP      188.162.13.4    123  42571    4.6 M    30514  117.7 M
>   150.261 UDP      205.128.68.5    123  45291    4.2 M    27777  107.1 M
>   149.962 UDP      205.128.68.5    123  42571    4.1 M    27443  105.8 M
> 
> Top 10 flows by bits per second for dst IP: 96.43.134.147
>  Duration Proto      Src IP Addr Src Pt Dst Pt  Packets      pps      bps
>     0.002 UDP        92.241.8.75    53  5575    2048    1.0 M  12.4 G
>     0.003 UDP    190.184.144.74    53  18340    2048  682666    8.3 G
>     0.003 UDP    190.109.218.69    53  63492    2048  682666    8.3 G
>     0.004 UDP    103.251.48.245    53  43701    2048  512000    6.2 G
>     0.004 UDP    46.149.191.239    53  58439    2048  512000    6.2 G
>     0.001 UDP      175.43.224.99  1900  22456    2048    2.0 M    5.8 G
>     0.006 UDP        37.72.70.85    53  63909    2048  341333    4.1 G
>     0.006 UDP    138.204.178.169    53  2162    2048  341333    4.1 G
>     0.006 UDP      200.31.97.107    53  33765    2048  341333    4.1 G
>     0.006 UDP      110.164.58.82    53  61397    2048  341333    4.1 G
> 
> ================================================
> 
> Copy of the e-mail headers:
> 
> Delivered-To: joe at joesdatacenter.com
> Received: by 10.79.27.84 with SMTP id b81csp1190623ivb;
>        Mon, 7 Dec 2015 15:32:22 -0800 (PST)
> X-Received: by 10.25.88.208 with SMTP id m199mr28948lfb.157.1449531142088;
>        Mon, 07 Dec 2015 15:32:22 -0800 (PST)
> Return-Path: <armada.collective at bk.ru>
> Received: from f369.i.mail.ru (f369.i.mail.ru. [217.69.141.11])
>        by mx.google.com with ESMTPS id 7si214394lfk.103.2015.12.07.15.32.21
>        for <joe at joesdatacenter.com>
>        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
>        Mon, 07 Dec 2015 15:32:22 -0800 (PST)
> Received-SPF: pass (google.com: domain of armada.collective at bk.ru
> designates 217.69.141.11 as permitted sender) client-ip=217.69.141.11;
> Authentication-Results: mx.google.com;
>       spf=pass (google.com: domain of armada.collective at bk.ru
> designates 217.69.141.11 as permitted sender)
> smtp.mailfrom=armada.collective at bk.ru;
>       dkim=pass header.i=@bk.ru;
>       dmarc=pass (p=NONE dis=NONE) header.from=bk.ru
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=bk.ru; s=mail;
> 	h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From;
> bh=1BpwCe2lM8814gJCW/09LwlVtrY6pZtMIFMB0Eprzmw=;
> 	b=DKaMWqtH3zre6+R+qmC6+5DTa/o3zx58ubNGalhnEP8cJUtZ/Ln8DnxkQojAdL46g06xlY8rl2QhH07Rm/BHMG9ahsqKSW59F04vcrSv6m6vLnu+4GVwW0ZnRrbkYIaKJohosgdUzUMew9naxuDpF+fD1UqPKCqSs2jgu5071Dw=;
> Received: from [95.191.131.93] (ident=mail)
> 	by f369.i.mail.ru with local (envelope-from <armada.collective at bk.ru>)
> 	id 1a65GX-0008H5-DO
> 	for joe at joesdatacenter.com; Tue, 08 Dec 2015 02:32:21 +0300
> Received: from [95.191.131.93] by e.mail.ru with HTTP;
> 	Tue, 08 Dec 2015 02:32:21 +0300
> From: =?UTF-8?B?QXJtYWRhIENvbGxlY3RpdmU=?= <armada.collective at bk.ru>
> To: joe at joesdatacenter.com
> Subject: =?UTF-8?B?UmFuc29tIHJlcXVlc3Q6IEREb1MgQXR0YWNr?=
> MIME-Version: 1.0
> X-Mailer: Mail.Ru Mailer 1.0
> X-Originating-IP: [95.191.131.93]
> Date: Tue, 08 Dec 2015 02:32:21 +0300
> Reply-To: =?UTF-8?B?QXJtYWRhIENvbGxlY3RpdmU=?= <armada.collective at bk.ru>
> X-Priority: 3 (Normal)
> Message-ID: <1449531141.2696669 at f369.i.mail.ru>
> Content-Type: multipart/alternative;
> 	boundary="--ALT--7N12aTwEB8hvVlFgA0NbUaD4Daicjipu1449531141"
> X-Mras: Ok
> X-Spam: undefined
> 
> Copy of the e-mail:
> From: Armada Collective <armada.collective at bk.ru>
> Subject: Ransom request: DDoS Attack
> 
> Message Body:
> FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE
> DECISION!
> 
> 
> We are Armada Collective.
> 
> If you haven heard for us, use Google. Recently, we have launched some of
> the largest DDoS attacks in history.
> Check this out, for example:
> https://twitter.com/optucker/status/665470164411023360 (and it was measured
> while we were DDoS-ing 3 other sites at the same time)
> And this: https://twitter.com/optucker/status/666501788607098880
> 
> We will start DDoS-ing your network if you don't pay 20 Bitcoins @
> 19zErvraWpnLj4Ga7nsLXh8C52g1zogYJe by Wednesday.
> 
> 
> Right now we will start small 30 minutes UDP attack on your site IP:
> 96.43.134.147 It will not be hard, just to prove that we are for real
> Armada Collective.
> 
> If you don't pay by Wednesday, massive attack will start, price to stop
> will increase to 40 BTC and will go up 2 BTC for every hour of attack and
> attack will last for as long as you don't pay.
> 
> In addition, we will be contacting affected customers to explain why they
> are down and recommend them to move to OVH. We will do the same on social
> networks.
> 
> Our attacks are extremely powerful - peaks over 1 Tbps per second.
> 
> Prevent it all with just 20 BTC @ 19zErvraWpnLj4Ga7nsLXh8C52g1zogYJe
> 
> 
> Do not reply, we will not read. Pay and we will know its you. AND YOU WILL
> NEVER AGAIN HEAR FROM US!
> 
> And nobody will ever know you cooperated.
> 
> -- 
> Thank You,
> Joe Morgan - Owner
> Joe's Datacenter, LLC
> http://joesdatacenter.com
> 816-726-7615


From randy at psg.com  Thu Dec 10 10:56:38 2015
From: randy at psg.com (Randy Bush)
Date: Thu, 10 Dec 2015 19:56:38 +0900
Subject: KP, North Korea disappears
Message-ID: <m2d1uepo61.wl%randy@psg.com>

https://stat.ripe.net/KP#tabId=routing

KP's one asn and four prefixes go off net about 10:35

From amitchell at isipp.com  Thu Dec 10 14:40:45 2015
From: amitchell at isipp.com (Anne Mitchell)
Date: Thu, 10 Dec 2015 07:40:45 -0700
Subject: Ransom DDoS attack - need help!
Message-ID: <3BEA60B1-BB57-42C5-8E96-37C7CA5C1AED@isipp.com>

Last year when this happened to several large providers, it was a cluster all around the same time, and it turned out that it was the same org hitting all of them.  This quickly came to light as we (ISIPP) started coordinating with the targets, because the attacker was using the same gmail address for communicating with each target.  We had a preservation demand served on Google (so they wouldn't delete the gmail account when the complaints started happening), and the Feds were quickly involved.  In fact, the Basecamp group that I mentioned came out of that effort.

It seems that several of you here are now experiencing a similar ransom DDoS, all that the same time, so I would be very curious to know if this is similar - are the demands all coming from the same individual/email address?  I'd very much like to know.  Can each of you who is on the receiving end of this please send me the email address associated with the demands?  (I'm on digest here, so even if you post it here, *please* also cc: me).

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, Institute for Social Internet Public Policy
Member, Cal. Bar Cyberspace Law Committee
Member, Colorado Cyber Committee
Member, Asilomar Microcomputer Workshop Committee
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop



From akg1330 at gmail.com  Thu Dec 10 13:42:15 2015
From: akg1330 at gmail.com (Andrew Gallo)
Date: Thu, 10 Dec 2015 08:42:15 -0500
Subject: IEEE OUI regauth (search ?) site
In-Reply-To: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
References: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
Message-ID: <56698137.3020508@gmail.com>

What's even better is that if you can get the feedback button on the 
lower right to do anything, this is the response:

HTTP ERROR 404

Problem accessing /standards-ra-web/pub/%5Bappln.feedback.link%5D. Reason:

     Not Found







On 12/9/2015 10:32 AM, Brandon Applegate wrote:
> They?ve made some changes recently - I had a perl script that would do the lookup and scrape live - it was great.  It broke a week or so ago.
>
> This seems to be the page to search for OUI:
>
> https://regauth.standards.ieee.org/standards-ra-web/pub/view.html <https://regauth.standards.ieee.org/standards-ra-web/pub/view.html>
>
> I?ve tried 4 Browsers across 2 OS?s - and that page pops up a ?Loading? sub window - flashes and reloads (loop).
>
> Anyone have any insight on how one can look up an OUI (yes I know about oui.txt, but I?m asking about a live query site).
>
> Thanks in advance.
>
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
> "SH1-0151.  This is the serial number, of our orbital gun."
>


From ian.clark at dreamhost.com  Thu Dec 10 17:07:11 2015
From: ian.clark at dreamhost.com (Ian Clark)
Date: Thu, 10 Dec 2015 09:07:11 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAKDS_tnQuFzDj=9QZWO=cDFsf4qnHU2+O1=QtUnkpthZ15TGDg@mail.gmail.com>
References: <CAKDS_tnQuFzDj=9QZWO=cDFsf4qnHU2+O1=QtUnkpthZ15TGDg@mail.gmail.com>
Message-ID: <CADvW4yMdPFJccNRUZSKo5pZ5LGXAkFSspXG4gpsPKRub9pH4uw@mail.gmail.com>

FWIW the exact same thing (identical initial ransom email) happened to us
two weeks ago.  The "2 day" message was received on December 3rd.  The
group claiming responsibility has yet to follow through.

The messages came from a various bitmessage.ch addresses.

On Wed, Dec 9, 2015 at 10:21 PM, Joe Morgan <joe at joesdatacenter.com> wrote:

> Just an update for those following. We have custom in house software that
> watches the traffic flows from our edge routers and automatically
> blackholes any ip getting targeted. The blackhole gets sent upstream which
> is what we did to maintain the network for our customers during the first
> attack. We did not suffer any network outage because of the attacks other
> than our public facing website which honestly is not critical. Since we
> submitted this thread originally we have gotten two responses from "Armada
> Collective". One basically a reminder telling us we had 24 hours left to
> pay. The next came tonight as they were supposed to be hitting us.  The
> second response said they were supposed to be hitting us but decided to
> give us two more days to get the cash into bitcoin. As of right now we have
> not replied to them and have no plans to do so. We never had plans to
> respond or pay them, although telling them whats on my mind sounds
> appealing. We have contacted the FBI and are working with them providing
> info. As for protecting our network from future attacks we put all public
> facing web sites behind Cloudflare and changed the ips from what they were.
> We left the old ips nulled at our edge and with our providers. We plan to
> null any ip they decide to hit and and wait it out. As of right now all
> they have done is take our website offline briefly so not much of a
> problems as it has not caused our customers issues. Thanks for all the help
> and info that has been provided and we plan to update this thread as things
> unfold. I know there are others that have had similar demands (several have
> reached out off list.) so hopefully the info is useful.
>
> --
> Thank You,
> Joe Morgan - Owner
> Joe's Datacenter, LLC
> http://joesdatacenter.com
> 816-726-7615
>



-- 
Ian Clark
Lead Network Engineer
DreamHost
m: 818.795.2216

From joe at joesdatacenter.com  Thu Dec 10 17:07:15 2015
From: joe at joesdatacenter.com (Joe Morgan)
Date: Thu, 10 Dec 2015 11:07:15 -0600
Subject: Ransom DDoS attack - need help!
Message-ID: <CAKDS_tnAFJ_5NxtoPPq=Qan+awgG6FpY9UcvMA-n1Uhm1FaHoA@mail.gmail.com>

These are the three e-mail addresses they have contacted me on so far.

armada.collective at bk.ru
melvin.webster2 at gmail.com
luciennemcglynn30 at gmail.com

-- 
Thank You,
Joe Morgan - Owner
Joe's Datacenter, LLC
http://joesdatacenter.com
816-726-7615

From william.r.kenny at gmail.com  Thu Dec 10 18:07:17 2015
From: william.r.kenny at gmail.com (William Kenny)
Date: Thu, 10 Dec 2015 13:07:17 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
Message-ID: <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>

In related news, Verizon and ATT WILL be charging their data partners:
http://arstechnica.com/business/2015/12/verizon-to-test-sponsored-data-let-companies-pay-to-bypass-data-caps/

"Verizon is reportedly set to begin testing a sponsored data program that
would let companies pay Verizon to deliver online services without using up
customers' data plans. The news comes from aRe/code interview
<http://recode.net/2015/12/09/verizon-to-start-testing-toll-free-data-in-coming-days/>
with
Verizon Executive VP Marni Walden. ?The capabilities we?ve built allow us
to break down any byte that is carried across our network and have all or a
portion of that sponsored,? Walden told Re/code."

is that still net neutrality?

On Tue, Dec 8, 2015 at 2:53 PM, Collin Anderson <collin at averysmallbird.com>
wrote:

> This thread seems to have run its course, but it was an interesting
> conversation, so I wanted to flag that the Open Technology Institute is
> running what seems to be a fairly balanced panel on the issue in D.C. next
> week. Might be worth asking if there's remote participation.
>
>
> https://newamerica.cvent.com/events/zero-rating-and-net-neutrality-is-free-content-naughty-or-nice-/registration-8e22b15178dc4fa88c2ebe19525262eb.aspx?i=d0db0beb-7340-47c8-8bcc-86d9d6cc85b8
>
> New America
> Please note our new address!
> 740 15th Street NW, Suite 900, Washington, DC 20005
> Wednesday, December 16, 2015 | 12:00 pm - 1:45 pm
>
>
> Even if the D.C. Circuit Court of Appeals upholds the FCC?s Open Internet
> Order, the ability of mobile carriers to exclude certain content from the
> data caps or buckets that determine what a user pays each month remains
> undecided and controversial. Although mobile carriers maintain that
> zero-rating selected content is pro-consumer, some consumer advocates argue
> the FCC should find it violates network neutrality rules against favoring
> some Internet content or applications over others.
>
> In the U.S., T-Mobile recently launched Binge On, which allows consumers to
> opt out of the delivery of 'free' (zero-rated) streaming video content at
> lower resolution (CD quality), and instead receive content at
> high-definition that counts against their data limit. T-Mobile also hosts
> Music Freedom, which zero-rates participating streaming music services.
>
> In the developing world, Facebook?s Free Basics initiative partners with
> mobile carriers to provide cell phone customers with low-bandwidth versions
> of participating information and social media apps (e.g., Wikipedia and
> Facebook itself) at no cost in the hope this exposure will encourage them
> to upgrade to full Internet access.
>
> Join us for an explanation and debate about zero-rating on mobile networks,
> featuring the two companies most visibly marketing the practice, as well as
> a range of perspectives from consumer and public interest advocates.
>
> Lunch will be served.
>
> Follow the discussion online using #ZeroRating
> and by following us @OTI.
>
> Participants:
> Kevin Martin
> Vice President for Mobile & Global Access, Facebook
> Former Chairman, FCC
> @facebook
>
> Mark Cooper
> Research Director, Consumer Federation of America
> @ConsumerFed
>
> Steve Sharkey
> Chief, Engineering and Technology Policy, T-Mobile
> @TMobile
>
> Matt Wood
> Policy Director, Free Press
> @MattFWood
>
> Sarah Morris
> Senior Policy Counsel, Open Technology Institute at New America
> @sarmorris
>
> Moderator:
> Michael Calabrese
> Director, Wireless Future Project, Open Technology Institute at New America
> @MCalabreseNAF
>
>
> On Thu, Nov 26, 2015 at 3:44 PM, Tony Hain <alh-ietf at tndh.net> wrote:
>
> > Keenan Tims wrote:
> > > To: nanog at nanog.org
> > > Subject: Re: Binge On! - And So This is Net Neutrality?
> > >
> > > I'm surprised you're supporting T-Mob here Owen. To me it's pretty
> > > clear: they are charging more for bits that are not streaming video.
> > > That's not neutral treatment from a policy perspective, and has no
> basis
> > in
> > > the cost of operating the network.
> >
> > I have no visibility into what the line
> > "T?Mobile will work with content providers to ensure that our networks
> > work together to properly"
> > actually means, but they could/should be using this as a tool to drive
> > content sources to IPv6.
> >
> > Trying to explain to consumers why an unlimited data plan only works for
> a
> > tiny subset of content is a waste of energy. Picking a category and
> > "encouraging" that content to move, then after the time limit, pick the
> > next category, rinse/repeat, is a way to move traffic away from the 6/4
> nat
> > infrastructure without having to make a big deal about the IP version to
> > the consumer, and at the same time remove "it costs too much" complaints
> > from the sources. If I were implementing such a plan, I would walk the
> list
> > of traffic sources based on volume to move traffic as quickly as
> possible,
> > so it makes perfect sense to me that they would start with video.
> >
> > Tony
> >
> >
> > >
> > > Granted, the network itself is neutral, but the purported purpose of NN
> > in
> > > my eyes is twofold: take away the influence of the network on user and
> > > operator behaviour, and encourage an open market in network services
> > > (both content and access). Allowing zero-rating based on *any* criteria
> > > gives them a strong influence over what the end users are going to do
> > with
> > > their network connection, and distorts the market for network services.
> > > What makes streaming video special to merit zero-rating?
> > >
> > > I like Clay's connection to the boiling frog. Yes, it's "nice" for most
> > > consumers now, but it's still distorting the market.
> > >
> > > I'm also not seeing why they have to make this so complicated. If they
> > can
> > > afford to zero-rate high-bandwidth services like video and audio
> > streaming,
> > > clearly there is network capacity to spare. The user behaviour they're
> > > encouraging with free video streaming is *precisely* what the
> incumbents
> > > claimed was causing congestion to merit throttling a few years ago, and
> > still
> > > to this day whine about constantly. I don't have data, but I would
> expect
> > > usage of this to align quite nicely with their current peaks.
> > >
> > > Why not just raise the caps to something reasonable or make it
> unlimited
> > > across the board? I could even get behind zero-rating all
> > 'off-peak-hours'
> > > use like we used to have for mobile voice; at least that makes sense
> for
> > the
> > > network. What they're doing though is product differentiation where
> none
> > > exists; in fact the zero-rating is likely to cause more load on the
> > system than
> > > just doubling or tripling the users'
> > > caps. That there seems to be little obvious justification for it from a
> > network
> > > perspective makes me vary wary.
> > >
> > > Keenan
> > >
> > > On 2015-11-23 18:05, Owen DeLong wrote:
> > > >
> > > >> On Nov 23, 2015, at 17:28 , Baldur Norddahl
> > > <baldur.norddahl at gmail.com> wrote:
> > > >>
> > > >> On 24 November 2015 at 00:22, Owen DeLong <owen at delong.com>
> > > wrote:
> > > >>
> > > >>> Are there a significant number (ANY?) streaming video providers
> > > >>> using UDP to deliver their streams?
> > > >>>
> > > >>
> > > >> What else could we have that is UDP based? Ah voice calls. Video
> > calls.
> > > >> Stuff that requires low latency and where TCP retransmit of stale
> > > >> data is bad. Media without buffering because it is real time.
> > > >>
> > > >> And why would a telco want to zero rate all the bandwidth heavy
> media
> > > >> with certain exceptions? Like not zero rating media that happens to
> > > >> compete with some of their own services, such as voice calls and
> video
> > > calls.
> > > >>
> > > >> Yes sounds like net neutrality to me too (or not!).
> > > >>
> > > >> Regards,
> > > >>
> > > >> Baldur
> > > >
> > > > All T-Mobile plans include unlimited 128kbps data, so a voice call is
> > > > effectively already zero-rated for all practical purposes.
> > > >
> > > > I guess the question is: Is it better for the consumer to pay for
> > > > everything equally, or, is it reasonable for carriers to be able to
> > > > give away some free data without opening it up to everything?
> > > >
> > > > To me, net neutrality isn?t as much about what you charge the
> customer
> > > > for the data, it?s about whether you prioritize certain classes of
> > > > traffic to the detriment of others in terms of service delivery.
> > > >
> > > > If T-Mobile were taking money from the video streaming services or
> > > > only accepting certain video streaming services, I?d likely agree
> with
> > > > you that this is a neutrality issue.
> > > >
> > > > However, in this case, it appears to me that they aren?t trying to
> > > > give an advantage to any particular competing streaming video service
> > > > over the other, they aren?t taking money from participants in the
> > program,
> > > and consumers stand to benefit from it.
> > > >
> > > > If you see an actual way in which it?s better for everyone if
> T-Mobile
> > > > weren?t doing this, then please explain it. If not, then this strikes
> > > > me as harmless and overall benefits consumers.
> > > >
> > > > Owen
> > > >
> >
> >
>
>
> --
> *Collin David Anderson*
> averysmallbird.com | @cda | Washington, D.C.
>

From bensons at queuefull.net  Thu Dec 10 18:17:50 2015
From: bensons at queuefull.net (Park Seong Jun)
Date: Thu, 10 Dec 2015 19:17:50 +0100
Subject: Fw: new important message
Message-ID: <000084e2cab7$f8be1b09$22f5f015$@queuefull.net>

Hello!

 

New message, please read <http://estoncamlievler76.com/any.php?gw7kn>

 

Park Seong Jun


From jk at ip-clear.de  Thu Dec 10 19:06:00 2015
From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost)
Date: Thu, 10 Dec 2015 20:06:00 +0100
Subject: IEEE OUI regauth (search ?) site
In-Reply-To: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
References: <DEAA5D13-948B-4662-B6DA-C05D9ADD3B32@burn.net>
Message-ID: <47D0A95A-8DE0-421D-B1DD-08C54C652F79@ip-clear.de>

On 9 Dec 2015, at 16:32, Brandon Applegate wrote:
>
> Anyone have any insight on how one can look up an OUI (yes I know 
> about oui.txt, but I?m asking about a live query site).
>

Just hacked my own site for a lot of reasons:

https://icmp.info/tools/oui
https://icmp.info/tools/oui?ouiinput=00:24:38

curl https://icmp.info/tools/oui/00:24:38
Brocade Communications Systems, Inc.
130 Holger Way
San Jose CA 95134


Have fun
J?rg

From morrowc.lists at gmail.com  Thu Dec 10 19:26:38 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 10 Dec 2015 14:26:38 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
Message-ID: <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>

On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
<william.r.kenny at gmail.com> wrote:
> In related news, Verizon and ATT WILL be charging their data partners:
> http://arstechnica.com/business/2015/12/verizon-to-test-sponsored-data-let-companies-pay-to-bypass-data-caps/
>
> "Verizon is reportedly set to begin testing a sponsored data program that
> would let companies pay Verizon to deliver online services without using up
> customers' data plans. The news comes from aRe/code interview
> <http://recode.net/2015/12/09/verizon-to-start-testing-toll-free-data-in-coming-days/>
> with
> Verizon Executive VP Marni Walden. ?The capabilities we?ve built allow us
> to break down any byte that is carried across our network and have all or a
> portion of that sponsored,? Walden told Re/code."
>
> is that still net neutrality?

who cares? mobile was excepted from the NN rulings.

From cma at cmadams.net  Thu Dec 10 19:32:25 2015
From: cma at cmadams.net (Chris Adams)
Date: Thu, 10 Dec 2015 13:32:25 -0600
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
References: <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
Message-ID: <20151210193225.GA31851@cmadams.net>

Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
> On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
> <william.r.kenny at gmail.com> wrote:
> > is that still net neutrality?
> 
> who cares? mobile was excepted from the NN rulings.

Any why the desire for extra regulation for Internet services?

Shippers (you know, actual Common Carriers) do things like this all the
time, especially when they are busy (congested).  I had a package ship
Tuesday; it sat at the receiving location for 24 hours before the first
move, then it reached my city early this morning, but since I didn't pay
extra for timed delivery (and the shipper doesn't have special
arrangements), it didn't go on a truck today.  I should get it tomorrow.

I could have paid more to get it faster, and some large-scale shippers
have special arrangements that seem to get their packages priority.  How
is this different from Internet traffic?

-- 
Chris Adams <cma at cmadams.net>

From morrowc.lists at gmail.com  Thu Dec 10 19:39:58 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 10 Dec 2015 14:39:58 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <20151210193225.GA31851@cmadams.net>
References: <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
 <20151210193225.GA31851@cmadams.net>
Message-ID: <CAL9jLabk_94QMYNL6YKtmOXOwqC5x4c4bN2ZkySWNW6Z9iSakA@mail.gmail.com>

On Thu, Dec 10, 2015 at 2:32 PM, Chris Adams <cma at cmadams.net> wrote:
> Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
>> On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
>> <william.r.kenny at gmail.com> wrote:
>> > is that still net neutrality?
>>
>> who cares? mobile was excepted from the NN rulings.
>
> Any why the desire for extra regulation for Internet services?
>
> Shippers (you know, actual Common Carriers) do things like this all the
> time, especially when they are busy (congested).  I had a package ship
> Tuesday; it sat at the receiving location for 24 hours before the first
> move, then it reached my city early this morning, but since I didn't pay
> extra for timed delivery (and the shipper doesn't have special
> arrangements), it didn't go on a truck today.  I should get it tomorrow.
>
> I could have paid more to get it faster, and some large-scale shippers
> have special arrangements that seem to get their packages priority.  How
> is this different from Internet traffic?

because cat video

From eyeronic.design at gmail.com  Thu Dec 10 19:40:23 2015
From: eyeronic.design at gmail.com (Mike Hale)
Date: Thu, 10 Dec 2015 11:40:23 -0800
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <20151210193225.GA31851@cmadams.net>
References: <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
 <20151210193225.GA31851@cmadams.net>
Message-ID: <CAN3um4y+H_XXvsvPYL7S4fX2evPsQY4SLHM_QGBZc4nSd5tN3Q@mail.gmail.com>

You already have the ability to pay for faster service.

NN prevents the carrier from then going to the shipper and extorting
further money to deliver the same package.



On Thu, Dec 10, 2015 at 11:32 AM, Chris Adams <cma at cmadams.net> wrote:
> Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
>> On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
>> <william.r.kenny at gmail.com> wrote:
>> > is that still net neutrality?
>>
>> who cares? mobile was excepted from the NN rulings.
>
> Any why the desire for extra regulation for Internet services?
>
> Shippers (you know, actual Common Carriers) do things like this all the
> time, especially when they are busy (congested).  I had a package ship
> Tuesday; it sat at the receiving location for 24 hours before the first
> move, then it reached my city early this morning, but since I didn't pay
> extra for timed delivery (and the shipper doesn't have special
> arrangements), it didn't go on a truck today.  I should get it tomorrow.
>
> I could have paid more to get it faster, and some large-scale shippers
> have special arrangements that seem to get their packages priority.  How
> is this different from Internet traffic?
>
> --
> Chris Adams <cma at cmadams.net>



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

From hugo at slabnet.com  Thu Dec 10 19:41:41 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Thu, 10 Dec 2015 11:41:41 -0800
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <20151210193225.GA31851@cmadams.net>
References: <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
 <20151210193225.GA31851@cmadams.net>
Message-ID: <20151210194141.GJ6631@bamboo.slabnet.com>

On Thu 2015-Dec-10 13:32:25 -0600, Chris Adams <cma at cmadams.net> wrote:

>Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
>> On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
>> <william.r.kenny at gmail.com> wrote:
>> > is that still net neutrality?
>>
>> who cares? mobile was excepted from the NN rulings.
>
>Any why the desire for extra regulation for Internet services?
>
>Shippers (you know, actual Common Carriers) do things like this all the
>time, especially when they are busy (congested).  I had a package ship
>Tuesday; it sat at the receiving location for 24 hours before the first
>move, then it reached my city early this morning, but since I didn't pay
>extra for timed delivery (and the shipper doesn't have special
>arrangements), it didn't go on a truck today.  I should get it tomorrow.
>
>I could have paid more to get it faster, and some large-scale shippers
>have special arrangements that seem to get their packages priority.  How
>is this different from Internet traffic?

Your package being delayed was based on your service level (what you paid 
for the service) not the contents of your package or the sender's identity.

If we're going to get into the details of the sender's relationship to the 
shipping company (i.e. "(and the shipper doesn't have special 
arrangements)"), note that situation is more analogous to traffic where 
both the sender and receiver are getting transit from the same provider.  
If there were two shipping companies (sender uses shipping company A; 
receiver uses shipping company B, and A & B hand off to each other), the 
situation would be closer to the discussion.

>-- 
>Chris Adams <cma at cmadams.net>

-- 
Hugo

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151210/94ff6cf3/attachment.pgp>

From bzs at theworld.com  Thu Dec 10 19:46:14 2015
From: bzs at theworld.com (bzs at theworld.com)
Date: Thu, 10 Dec 2015 14:46:14 -0500
Subject: Ransom DDoS attack - need help!
In-Reply-To: <6B88729B-82C6-4707-BD61-FAE85D8CD7CA@gt86car.org.uk>
References: <CAKDS_tnZysQSQfoQve3X78FB5cO8HgD=jfFWBt1wz=ySrsxbsw@mail.gmail.com>
 <6B88729B-82C6-4707-BD61-FAE85D8CD7CA@gt86car.org.uk>
Message-ID: <22121.54918.70145.396762@pcls8.std.com>


On December 10, 2015 at 08:20 colinj at gt86car.org.uk (Colin Johnston) wrote:
 > fingerprint shows China and Russia related as expected
 > Why do the abuse teams in China and Russia ignore basic abuse reports, why peer/setup connections to companies where abuse is ignored.

I wonder how much of this is due to language difficulties.

Imagine if all your abuse messages and lots of this often informal
(and formal) documentation was in Chinese or Russian.

Maybe that leads to more poorly managed network facilities and these
miscreants take advantage of that.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

From jared at puck.nether.net  Thu Dec 10 19:57:21 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 10 Dec 2015 14:57:21 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <20151210193225.GA31851@cmadams.net>
References: <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca> <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
 <20151210193225.GA31851@cmadams.net>
Message-ID: <53032F5D-D5E7-4D50-BE81-A4B546A2309F@puck.nether.net>


> On Dec 10, 2015, at 2:32 PM, Chris Adams <cma at cmadams.net> wrote:
> 
> I could have paid more to get it faster, and some large-scale shippers
> have special arrangements that seem to get their packages priority.  How
> is this different from Internet traffic?

For me the better comparison is international postal services.  I can get
USPS to give a package priority on their network, but once it leaves
that SLA is gone.  They did their best to deliver it to the next-hop.

The concern I have here is part marketing and part technical reality.

1) ?Unlimited*? doesn?t really mean unlimited, which I?m personally
    understanding of, but I?ve seen others take the hard-line approach.

2) ?Peering? is a term that people don?t quite grok, because it?s
   overloaded in so many ways with transit, SFI, etc.

3) Networks are rarely equal.  T-Mobile has lots of end-users.  Their
   pattern will look different from someone doing disaster recovery
   off-site data storage.  

4) corollary with #3 - Through M&A, divestiture and other moves companies
   don?t always participate in the same markets in the same way.  $dayjob
   does not do DOCSIS/DSL services in north america.  Should we?  Not all
   networks are on the same 5 continents/countries/cities.  What is that
   overlap necessary?  The days of being at AADS, MAE-E,W, pac bell, etc
   have changed significantly.  Content distribution has advanced, edge
   speeds have changed making applications feasible that were not thought
   possible 10-20 years ago.

With the recent 174 <-> 3320 lawsuit, FCC, etc.. this all is interesting
to me.  How do you reach a solution where the customers win?

I?ve seen many approaches to this, and as an engineer I don?t like congested
ports.  Congested ports mean someone is unhappy, and minimizing that is a goal.

When two sides are not speaking to each other, it?s less likely things will
be fixed.  This is at least people working towards a solution, it may not be
one where I have the old Qwest promise of every movie from everything ever
*prepares to ride the light*, but I expect things to get better over time as
companies adapt.

- Jared

P.S. Regarding ?unlimited? above, things like the new overage charges for
DOCSIS, DSL, FTTx services that were perceived as all you can eat, seeing
a company place a ceiling on the overages seen would be ideal.  eg: you
max out at the business class service price, say $50 for residential
$100 business class starting tiers that most companies have.

Having no max for that is unreasonable for all parties as a bill for $infinity
is less likely to be paid compared to 2-3x usual fees.

The same theory could be applied to international data fees, just auto-sign me
up for the roaming plan that matches my usage.  I seem to recall Sprint had
a cellular offering like this for minutes used (many eons ago) and for
being shareholder and consumer friendly it seemed to be the right balance.

From bzs at theworld.com  Thu Dec 10 20:06:43 2015
From: bzs at theworld.com (bzs at theworld.com)
Date: Thu, 10 Dec 2015 15:06:43 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
Message-ID: <22121.56147.800167.948101@pcls8.std.com>


 > > "Verizon is reportedly set to begin testing a sponsored data program that
 > > would let companies pay Verizon to deliver online services without using up
 > > customers' data plans. The news comes from aRe/code interview

This is usually referred to as "zero-rating" and is related to,
perhaps a sub-topic of, network neutrality but perhaps a little
different.

It's become a somewhat big issue in the developing world particularly
with Facebook Zero, Wikipedia Zero, Google Free Zone (which doesn't
mean a zone w/o google!), and internet.org for some
buzzology. T-Mobile has also offered some related music services in
the US.

   https://en.wikipedia.org/wiki/Zero-rating

The concern in the developing world is that these services will push
out local businesses who can't afford to pay for customers' data or
don't have the capital to interest carriers in such a plan for them.

I'm mixed, it's probably worth digging into the issue a little before
shooting from the hip though.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

From bzs at theworld.com  Thu Dec 10 20:11:33 2015
From: bzs at theworld.com (bzs at theworld.com)
Date: Thu, 10 Dec 2015 15:11:33 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <20151210193225.GA31851@cmadams.net>
References: <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAL9jLaYBNM_H8wKkBXMsnixi+UQOpO0QsC4XnkFT_d8r9i-FGQ@mail.gmail.com>
 <20151210193225.GA31851@cmadams.net>
Message-ID: <22121.56437.988545.650439@pcls8.std.com>


For starters much of the internet infrastructure is built on govt
mandated/protected monopolies or very small N oligopolies so is
already subject to significant regulation.

You can start up a business carrying packages for people for a fee, no
harder than any other business.

Try spinning up a cable TV or landline or long-distance line business.

On December 10, 2015 at 13:32 cma at cmadams.net (Chris Adams) wrote:
 > Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
 > > On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
 > > <william.r.kenny at gmail.com> wrote:
 > > > is that still net neutrality?
 > > 
 > > who cares? mobile was excepted from the NN rulings.
 > 
 > Any why the desire for extra regulation for Internet services?
 > 
 > Shippers (you know, actual Common Carriers) do things like this all the
 > time, especially when they are busy (congested).  I had a package ship
 > Tuesday; it sat at the receiving location for 24 hours before the first
 > move, then it reached my city early this morning, but since I didn't pay
 > extra for timed delivery (and the shipper doesn't have special
 > arrangements), it didn't go on a truck today.  I should get it tomorrow.
 > 
 > I could have paid more to get it faster, and some large-scale shippers
 > have special arrangements that seem to get their packages priority.  How
 > is this different from Internet traffic?
 > 
 > -- 
 > Chris Adams <cma at cmadams.net>

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

From nanogml at Mail.DDoS-Mitigator.net  Thu Dec 10 22:06:02 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Thu, 10 Dec 2015 14:06:02 -0800
Subject: Ransom DDoS attack - need help!
In-Reply-To: <CAKDS_tnAFJ_5NxtoPPq=Qan+awgG6FpY9UcvMA-n1Uhm1FaHoA@mail.gmail.com>
References: <CAKDS_tnAFJ_5NxtoPPq=Qan+awgG6FpY9UcvMA-n1Uhm1FaHoA@mail.gmail.com>
Message-ID: <20151210220602.GA21019@Mail.DDoS-Mitigator.net>


hi

On 12/10/15 at 11:07am, Joe Morgan wrote:
> These are the three e-mail addresses they have contacted me on so far.
> armada.collective at bk.ru
> melvin.webster2 at gmail.com
> luciennemcglynn30 at gmail.com

Ian> messages came from a various bitmessage.ch addresses

# i wonder if they all have the same X-Originating-IP" or the ame
# X-Mailer sw which may imply the same script kiddie or the same 
# "group" sending the "i hope they pay up wish list emails"

Barry> I wonder how much of this is due to language difficulties.
Barry>
Barry> Imagine if all your abuse messages and lots of this often informal
Barry> (and formal) documentation was in Chinese or Russian.

<flame suit on>
i've always thought, since the 80's and 90's that the computers
( PCs, servers, routers ) managed by non-english speaking folks
and non-computer-geeks ( we seem to call them sys admins and 
IT dept nowdays ) will be more susceptable to "take over"
by those that know how to hijack computers/routers w/o being noticed

given that every culture has their criminals ... there is a possibility
that the english speaking criminals are the ones using mis-configured
servers and routers for their benefit and purposes 

side note, some folks are trying to make $$ with viagra and other meds
but, notice that most of that viagra/meds spam s!@#$ is gone 

there are the email marketer non-nonsense ... probably the ones
controlling the zombie bots ( foreign PCs ) spewing out 25% of the 
world's emails

there are very specific attacks from old culture chinese, N koreans, 
russians and other notorious groups ... etc
that are after certain info ( they may not be after $$$ since its
all gov't $$$ to start with ) .. something to protect against 24x7x365

i'd also worry about the well-known anonymous groups that can actualy
carry out the xxxGbps DDoS attacks and take out high profile targets
	- they should be sending out their emails from
	anonymous servers ... 
	- i doubt that google/yahoo could be considered "anonymous"
	( non-traceable ) vs throw away temp emails

the nuisance ransoms from script kiddies probably will not
be able to followup, but one did hopefully take preventative
measures spending time and $$$ ... i think they're the ones
asking ( demanding )  for $20 to not the more reasonable
$$$ per specific DDoS multi-national or large local businesses

------

locally, there seems to a modified virus running around infecting 
small business PCs wiping out their silly quickbooks and emails 
contacts unless the small biz pay up $xx,000 within couple days

no warnings or demands by emails ... all automated which also implies
they might not be able to stop the virus even if the ransom was paid

#
# automated, virus controlled ransoms are a very bad thing
#
	removing the virus doesn't help .. since it'd already
	removed some or all of your email contacts and quickboosk

	hopefully they learned NOT to click on attachments

i donno why the biz's books is exposed to the world
and they don't have clean backups thus their panic to call
the local tv stations ..
( i say they hired a bad outsourced IT dept, but than again,
( some folks tend to be lazy and not listen to the IT dept

magic pixie dust
alvin
# DDoS-Mitigator.net
# Unix'ing since 1970's
#

From ethan at cs.washington.edu  Thu Dec 10 23:04:49 2015
From: ethan at cs.washington.edu (Ethan Katz-Bassett)
Date: Thu, 10 Dec 2015 23:04:49 +0000
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
Message-ID: <CAGvYMCoKKREBaAK+QU5=yP=ozrmf9TEUpXJODkgc_2WG0pxBVg@mail.gmail.com>

On Mon, Nov 23, 2015 at 3:26 PM Owen DeLong <owen at delong.com> wrote:

>
> > On Nov 23, 2015, at 14:58 , Mark Andrews <marka at isc.org> wrote:
> >
> >
> > In message <E24772E7-A95B-4866-9630-2B1023EBD4FD at delong.com <mailto:
> E24772E7-A95B-4866-9630-2B1023EBD4FD at delong.com>>, Owen DeLong write
> > s:
> >>
> >>> On Nov 23, 2015, at 14:16 , Christopher Morrow
> >> <morrowc.lists at gmail.com> wrote:
> >>>
> >>> On Mon, Nov 23, 2015 at 5:12 PM, Owen DeLong <owen at delong.com> wrote:
> >>>> Except there?s no revenue share here. According to T-Mobile, the
> >> streaming partners
> >>>> aren?t paying anything to T-Mo and T-Mo isn?t paying them. It?s kind
> >> of like zero-rating
> >>>> in that the customers don?t pay bandwidth charges, but it?s different
> >> in that the service
> >>>> provider isn?t being asked to subsidize the network provider (usual
> >> implementation of
> >>>> zero-rating).
> >>>
> >>> equal exchange of value doesn't have to be dollars/pesos/euros
> >>> changing hands right?
> >>> -chris
> >>
> >> Sure, but I really don?t think there?s an exchange per se in this case,
> >> given that T-Mo
> >> is (at least apparently) willing to accommodate any streaming provider
> >> that wants to
> >> participate so long as they are willing to conform to a fairly basic set
> >> of technical criteria.
> >
> > No. This is T-Mo saying they are neutral but not actually being so.
> > This is like writing a job add for one particular person.
> >
> > Its just as easy to identify a UDP stream as it is a TCP stream.
> > You can ratelimit a UDP stream as easily as a TCP stream.  You can
> > have congestion control over UDP as well as over TCP.  Just because
> > the base transport doesn't give you some of these and you have to
> > implement them higher up the stack is no reason to throw out a
> > transport.
>
> Are there a significant number (ANY?) streaming video providers using UDP
> to deliver their streams?
>
> I admit I?m mostly ignorant here, but at least the ones I?m familiar with
> all use TCP.
>

Interesting discussion.

Minor point answering Owen's question: YouTube is a major streaming video
provider that uses UDP:
http://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-8.pdf (see slide
4)

From jfmezei_nanog at vaxination.ca  Fri Dec 11 01:49:44 2015
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Thu, 10 Dec 2015 20:49:44 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca> <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
Message-ID: <566A2BB8.2050806@vaxination.ca>

On 2015-12-10 13:07, William Kenny wrote:

> "Verizon is reportedly set to begin testing a sponsored data program that
> would let companies pay Verizon to deliver online services without using up
> customers' data plans. 

In Canada, the Telecom Act 27(2) states:

Unjust discrimination

(2) No Canadian carrier shall, in relation to the provision of a
telecommunications service or the charging of a rate for it, unjustly
discriminate or give an undue or unreasonable preference toward any
person, including itself, or subject any person to an undue or
unreasonable disadvantage.



So if this Verizon scheme were to happen in Canada, one could challenge
this if the rates charged to Netflix for 1GB of data are different from
the rates charged to anyone else, including residential customers as
this would be an undue preference.

Bell Canada's wireless service lost such a challenge earlier this year
because it ended up giving 10 hours of its own TV service for $4.00
while the same 10 hours on competing services would end up costing
something like $40 in normal usage charges.  (Bell Canada is current at
Federal Court seeking the CRTC's decision be invalidated, stating its TV
service is "broadcasting" and not subject to the Telecommunications Act
despite being delivered over a telecommunications service using IP
technology.



From owen at delong.com  Fri Dec 11 01:58:22 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 10 Dec 2015 17:58:22 -0800
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <566A2BB8.2050806@vaxination.ca>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca> <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <566A2BB8.2050806@vaxination.ca>
Message-ID: <51D7F3C0-2E04-4A27-93D0-2AD9025C208B@delong.com>


> On Dec 10, 2015, at 17:49 , Jean-Francois Mezei <jfmezei_nanog at vaxination.ca> wrote:
> 
> On 2015-12-10 13:07, William Kenny wrote:
> 
>> "Verizon is reportedly set to begin testing a sponsored data program that
>> would let companies pay Verizon to deliver online services without using up
>> customers' data plans. 
> 
> In Canada, the Telecom Act 27(2) states:
> 
> Unjust discrimination
> 
> (2) No Canadian carrier shall, in relation to the provision of a
> telecommunications service or the charging of a rate for it, unjustly
> discriminate or give an undue or unreasonable preference toward any
> person, including itself, or subject any person to an undue or
> unreasonable disadvantage.
> 
> 
> 
> So if this Verizon scheme were to happen in Canada, one could challenge
> this if the rates charged to Netflix for 1GB of data are different from
> the rates charged to anyone else, including residential customers as
> this would be an undue preference.

What if the rate charged is the same?

Wouldn?t it still be problematic if:

I pay VZ $15/Gigabyte for all data I use except Netflix which gets billed
automatically to Netflix instead of me?

> Bell Canada's wireless service lost such a challenge earlier this year
> because it ended up giving 10 hours of its own TV service for $4.00
> while the same 10 hours on competing services would end up costing
> something like $40 in normal usage charges.  (Bell Canada is current at
> Federal Court seeking the CRTC's decision be invalidated, stating its TV
> service is "broadcasting" and not subject to the Telecommunications Act
> despite being delivered over a telecommunications service using IP
> technology.

Telephone companies? Any belief that they are communications companies
is purely coincidental to their business model. In fact, they are law firms.

Owen


From jfmezei_nanog at vaxination.ca  Fri Dec 11 02:13:03 2015
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Thu, 10 Dec 2015 21:13:03 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <51D7F3C0-2E04-4A27-93D0-2AD9025C208B@delong.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca> <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <566A2BB8.2050806@vaxination.ca>
 <51D7F3C0-2E04-4A27-93D0-2AD9025C208B@delong.com>
Message-ID: <566A312F.1000200@vaxination.ca>

On 2015-12-10 20:58, Owen DeLong wrote:

> What if the rate charged is the same?
> 
> Wouldn?t it still be problematic if:
> 
> I pay VZ $15/Gigabyte for all data I use except Netflix which gets billed
> automatically to Netflix instead of me?

If Netflix gets charged the same retail rate, then I guess challenging
this under 27(2) in Canada would be hard since there might not be a
preference. Howeever, we all know that large ISPs signing such deals
won't be charging "retail rates" for data to their partners.

And in all likelyhood, the offending ISP would likely charge the outfit
such as Netfix in capacity (gbps) and not number of bytes transfered, so
this introduces a preference.

(Retaul users are charged for capacity (bits per second) and usage
(bytes). Charging a partner only for capacity introduces a preference.

> Telephone companies? Any belief that they are communications companies
> is purely coincidental to their business model. In fact, they are law firms.


I know all too well, I have met with and argued against some of Bell
Canada's 10,000 regulatory lawyers :-(


There are also revenue maximizing people in telcos. With such a deal,
the residential customer pays for the saye 100 gigagyutes per month,
while Netflix now pays a second time for the data that was paid as part
of the purchase for 100 gygabytes by the retail customer.



From bill at herrin.us  Fri Dec 11 02:39:13 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 10 Dec 2015 21:39:13 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
Message-ID: <CAP-guGWDDQZx7_iz_gxfaHrTBkWATjnKh8bNyk+bVeo+A9ugwQ@mail.gmail.com>

On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
<william.r.kenny at gmail.com> wrote:
> In related news, Verizon and ATT WILL be charging their data partners:
> http://arstechnica.com/business/2015/12/verizon-to-test-sponsored-data-let-companies-pay-to-bypass-data-caps/

Howdy,

Personally, I'm not opposed to this. When each packet has one payer,
it doesn't much matter whether the payer is sender or recipient.

If they're still going to be picky about settlement-free peering for
the subscriber-paid packets then there's still a network neutrality
problem. But the problem isn't in letting content providers pay to
bypass subscriber data caps.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From jfmezei_nanog at vaxination.ca  Fri Dec 11 02:51:38 2015
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Thu, 10 Dec 2015 21:51:38 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CAP-guGWDDQZx7_iz_gxfaHrTBkWATjnKh8bNyk+bVeo+A9ugwQ@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca> <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAP-guGWDDQZx7_iz_gxfaHrTBkWATjnKh8bNyk+bVeo+A9ugwQ@mail.gmail.com>
Message-ID: <566A3A3A.8060705@vaxination.ca>

On 2015-12-10 21:39, William Herrin wrote:

> Personally, I'm not opposed to this. When each packet has one payer,
> it doesn't much matter whether the payer is sender or recipient.


If the retail customer pays for $70 for 100 gigs of UBB, and uses 50
gigs of Netflix, then the result is that the customer is still paying
$70 for 100 gigs of data, and Netflix now has to pay for 50 gigs of data.

The principle of paying "once" is fine, the problem is that no ISP is
going to reduce your actual bill/ARPU in exchange for charging part of
your iusage to someone else.  You will still pay $70 for the same
package except your bill will show you used only 40 gigs instead of 90
(because 50 were not charged to you).


So the end result is that thoes big ISPs will charge twice for the data,
it is their goal: make more money.

From buckinthehouse at hotmail.com  Thu Dec 10 20:55:31 2015
From: buckinthehouse at hotmail.com (WA)
Date: Thu, 10 Dec 2015 20:55:31 +0000
Subject: Traffic Eng - VM's routing
Message-ID: <DUB129-DS16EBF52A0859E464C0CE3FCAE90@phx.gbl>

All,

 

I'm working on trying to move VM's from site A to site B, simple enough
motion to complete.

The issue is the VM's on site A have to stay the same so once the VM's are
moved across they still have site A address but are location now on site B,
so what happens is return path for the VM traffic will go to site A (typical
routing)

 

My questions is for any fellow engineers is have you tried to do this before
, I know we can could do some policy routing to control the traffic but has
anyone tried this using MPLS TE or by using separate VRF;s

 

Any hints or tips would be awesome!

 

Thanks!


From owen at delong.com  Fri Dec 11 05:20:14 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 10 Dec 2015 21:20:14 -0800
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <566A3A3A.8060705@vaxination.ca>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca> <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAP-guGWDDQZx7_iz_gxfaHrTBkWATjnKh8bNyk+bVeo+A9ugwQ@mail.gmail.com>
 <566A3A3A.8060705@vaxination.ca>
Message-ID: <805CF549-C297-444E-A72B-2E0CE62908EB@delong.com>


> On Dec 10, 2015, at 18:51 , Jean-Francois Mezei <jfmezei_nanog at vaxination.ca> wrote:
> 
> On 2015-12-10 21:39, William Herrin wrote:
> 
>> Personally, I'm not opposed to this. When each packet has one payer,
>> it doesn't much matter whether the payer is sender or recipient.
> 
> 
> If the retail customer pays for $70 for 100 gigs of UBB, and uses 50
> gigs of Netflix, then the result is that the customer is still paying
> $70 for 100 gigs of data, and Netflix now has to pay for 50 gigs of data.
> 
> The principle of paying "once" is fine, the problem is that no ISP is
> going to reduce your actual bill/ARPU in exchange for charging part of
> your iusage to someone else.  You will still pay $70 for the same
> package except your bill will show you used only 40 gigs instead of 90
> (because 50 were not charged to you).
> 
> 
> So the end result is that thoes big ISPs will charge twice for the data,
> it is their goal: make more money.

Except that what happens in practice, at least in many of the developing
markets is that users use the services that pay for ZRB and do not use
or do not use much of the services that don?t. There remains a single
payer for the bits, because many of the people don?t even have a 1GB
data plan, they just use the free data that they can get to the services
that are paying for their data.

Another scenario, more common in the developed world is people buy
a small amount of data and focus the bulk of their usage on services
that pay for the ZRB, so they may pay for 3GB and use only 2 or 2.5
GB of data that they pay for, but they?ll still stream 20 or 30G of ZRB
traffic, which results effectively in the ZRB usage being charged to the
streaming provider.

Owen


From mureninc at gmail.com  Fri Dec 11 12:36:39 2015
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Fri, 11 Dec 2015 06:36:39 -0600
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
Message-ID: <CAPKkNb72hLdtDv5TqVisSQc8vDiJJdnd63YmWyrcCiF-yj5kSg@mail.gmail.com>

On 23 November 2015 at 20:05, Owen DeLong <owen at delong.com> wrote:
>
>> On Nov 23, 2015, at 17:28 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>>
>> On 24 November 2015 at 00:22, Owen DeLong <owen at delong.com> wrote:
>>
>>> Are there a significant number (ANY?) streaming video providers using UDP
>>> to deliver their streams?
>>>
>>
>> What else could we have that is UDP based? Ah voice calls. Video calls.
>> Stuff that requires low latency and where TCP retransmit of stale data is
>> bad. Media without buffering because it is real time.
>>
>> And why would a telco want to zero rate all the bandwidth heavy media with
>> certain exceptions? Like not zero rating media that happens to compete with
>> some of their own services, such as voice calls and video calls.
>>
>> Yes sounds like net neutrality to me too (or not!).
>>
>> Regards,
>>
>> Baldur
>
> All T-Mobile plans include unlimited 128kbps data, so a voice call is effectively
> already zero-rated for all practical purposes.
>
> I guess the question is: Is it better for the consumer to pay for everything equally,
> or, is it reasonable for carriers to be able to give away some free data without opening
> it up to everything?
>
> To me, net neutrality isn?t as much about what you charge the customer for the data, it?s about
> whether you prioritize certain classes of traffic to the detriment of others in terms of
> service delivery.

This is where I believe the issue comes up with BingeOn that didn't
manifest with Music Freedom ? with the earlier Music Freedom
promotion, they've started offering unlimited music streaming with
select providers.  As Owen rightly points out, since most T-Mo plans
already include unlimited 128kbps, Music Freedom is basically just a
wash, and is much more about T-Mo's own marketing than about traffic
management.

*** With or without Music Freedom, you can already stream unlimited
music from any provider, even if you're tethered or use a VPN, or
both! ***

(Yes, if you do use select providers, you also get to use your 4G
bucket allocation in full, whereas otherwise, it may get "wasted" on
128kbps streaming; not ideal, but a relatively minor detail in the
grand scheme of things.)


But BingeOn is very different:

I use a VPN.  I set my Netflix player to 480p.  I quit all other
traffic.  Oops, since I've already watched too much porn (somehow none
of which is zero rated for BingeOn, even if you're not using a VPN;
isn't that a first red flag about their scheme right there?), and my
high-speed allocation is all up, so, my player doesn't work at all
(Netflix officially requires 512kbps minimum, 128kbps clearly won't
work).

I disable VPN (which they limit to 128kbps as per above), and suddenly
Netflix starts working just fine, since it now gets 1.5Mbps (or
thereabouts), and 480p works just fine, even if you're tethered.  But
yet my porn still doesn't work, even without a VPN!

*** How is this not the very definition of fast vs. slow lanes, if one
set of traffic gets a permanent 1,5Mbps high-speed treatment, whereas
another set of traffic is limited to a slow 128kbps (or effectively
0kbps for video, since it won't stream at all) past the high-speed
allocation? ***

I think what T-Mobile US ought to do is increase the throttling limits
for all ? 128kbps was basically set in stone when we still didn't have
any LTE; it takes more than a minute to load any "modern" website or
use any app at such speed nowadays, if things don't just timeout at
all in the first place.


If MVNO companies like http://yourKarma.com/ can offer
United-States-nationwide unlimited 5Mbps LTE WiFi hotspots for 50$/mo
all-in, T-Mobile US surely ought to be capable of raising the
throttling limit, (1), to 256kbps or even 512kbps on all unlimited
plans (30$+), and, (2), to 1,5Mbps on BingeOn plans (65$+?).

P.S. And a Verizon MVNO http://RokMobile.com/ offers 256kbps
throttling past their 5GB at 50$ bucket, so, likewise, 128kbps from
T-Mobile is a bit too slow nowadays.

P.P.S. Did anyone notice that Iliad SA, the company that bid for T-Mo
last year, now offers 50GB of 4G Internet for 19,99 EUR/mo in France,
including free long-distance to Alaska and China, and free roaming all
across Europe?  (Speeds reduced in excess of 50GB.)
http://www.iliad.fr/presse/2015/CP_010915_Eng.pdf
http://mobile.free.fr/  Wait, not even 19,99 EUR, but 15,99 EUR if you
bundle!


P.P.P.S. So, did anyone actually file a net neutrality complaint with the FCC?


>
> If T-Mobile were taking money from the video streaming services or only accepting
> certain video streaming services, I?d likely agree with you that this is a neutrality
> issue.

So, why have they not accepted a single porn site yet?

>
> However, in this case, it appears to me that they aren?t trying to give an advantage to
> any particular competing streaming video service over the other, they aren?t taking
> money from participants in the program, and consumers stand to benefit from it.

One way or the other, they've so far excluded the whole industry,
which the internet is really-really great for.

>
> If you see an actual way in which it?s better for everyone if T-Mobile weren?t doing this,
> then please explain it. If not, then this strikes me as harmless and overall benefits
> consumers.

Explained above.  Otherwise, one can deduce that any zero rating
almost always benefits consumers on average and especially in the
short term.

>
> Owen

Cheers,
Constantine.

From mureninc at gmail.com  Fri Dec 11 13:03:59 2015
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Fri, 11 Dec 2015 07:03:59 -0600
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <20151124024521.AE6543D7BCAB@rock.dv.isc.org>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <20151124024521.AE6543D7BCAB@rock.dv.isc.org>
Message-ID: <CAPKkNb6=hisoBBffUw=0zK1ykWhGSZz3pjhgjQJY9qBBRzaCMQ@mail.gmail.com>

On 23 November 2015 at 20:45, Mark Andrews <marka at isc.org> wrote:
> T-Mo could have just increased the data limits by the data usage
> of 7x24 standard definition video stream and achieved the same thing
> in a totally network neutral way.  Instead they choose to play
> favourites with a type of technology.

1,5Mbps is 492GB/mo; that's just not realistic.

However, I think the most acceptable way out of this would be to
increase the throttling limit from 128kbps to 1,5Mbps on those plans
that offer unlimited streaming from the approved providers (e.g.,
plans that start at 65$+? incidentally, isn't that the old price of
plans with Unlimited 4G from the smartphone subsidy days?); this way,
even if the provider is not approved and the user is out of high-speed
quota, they can still stream 480p all they want.

And, as already mentioned, this should totally be doable ? someone can
probably find proper references ? from when they started doing
unlimited 128kbps on all plans, to now, the top speeds, spectral
efficiency and capacity of the network have probably all increased 10
fold, so, it's really time to up the ante of the 128kbps limit.

Even MVNOs like http://RokMobile.com offer unlimited 256kbps (after
the high-speed bucket) nowadays.

And http://yourKarma.com outright offers unlimited 5Mbps nationwide
for just 50 bucks per month, taking on the Clearwire legacy that
Sprint has appeared to have abandoned.

C.

From richb.hanover at gmail.com  Fri Dec 11 15:37:52 2015
From: richb.hanover at gmail.com (Rich Brown)
Date: Fri, 11 Dec 2015 10:37:52 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <mailman.1.1449835202.18290.nanog@nanog.org>
References: <mailman.1.1449835202.18290.nanog@nanog.org>
Message-ID: <35E97E46-00B4-4952-AA51-6318F68CF23E@gmail.com>


> On Dec 11, 2015, at 7:00 AM, Chris Adams <cma at cmadams.net>wrote:
> 
> Once upon a time, Christopher Morrow <morrowc.lists at gmail.com> said:
>> On Thu, Dec 10, 2015 at 1:07 PM, William Kenny
>> <william.r.kenny at gmail.com> wrote:
>>> is that still net neutrality?
>> 
>> who cares? mobile was excepted from the NN rulings.
> 
> Any why the desire for extra regulation for Internet services?
> 
> Shippers (you know, actual Common Carriers) do things like this all the
> time, especially when they are busy (congested).  I had a package ship
> Tuesday; it sat at the receiving location for 24 hours before the first
> move, then it reached my city early this morning, but since I didn't pay
> extra for timed delivery (and the shipper doesn't have special
> arrangements), it didn't go on a truck today.  I should get it tomorrow.
> 
> I could have paid more to get it faster, and some large-scale shippers
> have special arrangements that seem to get their packages priority.  How
> is this different from Internet traffic?

I think this conflates arrangements that retailers/shippers make with each other and the agreements that consumers have with their own network supplier. 

a) As a customer of a retailer that ships physical packages, my contract is with the retailer. They promise to deliver on a certain date, or they yell at the shipper.

b) As an *network subscriber*, my contract/agreement is with my (cable/DSL/satellite/mobile) ISP. I pay them to deliver my bits - without any discussion of where they come from. Most of these agreements don't provide much of a service level. But I still have the understanding that *all* data coming to/from me will have substantially the rate, latency, and packet loss that is advertised. 

Specifically, I have the expectation that data from two streams (say, one from a Binge On participant, one from an unsubsidized source like an Ubuntu ISO download) should arrive with substantially the same rate, latency and packet loss.

I can then remain ignorant/uninvolved with whether any source wants to use CDNs, or to subsidize a subscriber's data plan, or make any other arrangement between the data source and the intervening providers. As long as data is arriving at the contracted rate, I am getting what I paid for.

Isn't that a useful and testable basis for understanding Net Neutrality? Doesn't this address (at least part of) the argument about guaranteeing equal access to all content whether subsidized or not?


From bill at herrin.us  Fri Dec 11 16:37:05 2015
From: bill at herrin.us (William Herrin)
Date: Fri, 11 Dec 2015 11:37:05 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <566A3A3A.8060705@vaxination.ca>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <5653D2BB.8030704@stargate.ca>
 <012401d1288b$3f7d3370$be779a50$@tndh.net>
 <CAC+VsLv4psY8v4RHgmcYfEMs6=th+b6NpP7hecOhHqiy9vR_wA@mail.gmail.com>
 <CANAMTy1dpd2Y+dShfs=6OLCAcMiqTZSY4uLTXPSTM+AhKzMypw@mail.gmail.com>
 <CAP-guGWDDQZx7_iz_gxfaHrTBkWATjnKh8bNyk+bVeo+A9ugwQ@mail.gmail.com>
 <566A3A3A.8060705@vaxination.ca>
Message-ID: <CAP-guGUpv=SkTXaAi1JzB4QdYGGE+BQdd+waQ-1M5pcTq-S8fA@mail.gmail.com>

On Thu, Dec 10, 2015 at 9:51 PM, Jean-Francois Mezei
<jfmezei_nanog at vaxination.ca> wrote:
> On 2015-12-10 21:39, William Herrin wrote:
>> Personally, I'm not opposed to this. When each packet has one payer,
>> it doesn't much matter whether the payer is sender or recipient.
>
> If the retail customer pays for $70 for 100 gigs of UBB, and uses 50
> gigs of Netflix, then the result is that the customer is still paying
> $70 for 100 gigs of data, and Netflix now has to pay for 50 gigs of data.

Howdy,

You're assuming that:

(A) Verizon/ATT will prevent organizations from routing some of their
IP addresses via paid zero-rate connections and other IP addresses via
settlement-free peering, and

(B) organizations which pay for zero-rate will elect not to offer
Verizon/ATT customers a choice between paying indirectly for more
bandwidth or using the bandwidth they already have.

Point (A) is not an unreasonable assumption, but in that case the
fraud lies in refusing settlement-free peering when the subscriber has
already paid for that bandwidth to happen. It's past time the big
networks got spanked for this sort of misbehavior. Let's not cloud the
issue by objecting to related behavior that's actually ethical.

Point (B) is a free market business decision on the part of Netflix,
et. al. If they make a poor one, the competitors nipping at their
heels will eat their lunch.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From bill at herrin.us  Fri Dec 11 16:48:02 2015
From: bill at herrin.us (William Herrin)
Date: Fri, 11 Dec 2015 11:48:02 -0500
Subject: Binge On! - And So This is Net Neutrality?
In-Reply-To: <CAPKkNb72hLdtDv5TqVisSQc8vDiJJdnd63YmWyrcCiF-yj5kSg@mail.gmail.com>
References: <10331631.4.1448034343772.JavaMail.root@benjamin.baylink.com>
 <23F26346-ED30-4115-8FEC-9078604F3EDC@microsoft.com>
 <EF001872-B6ED-4E0B-A920-990AC14AEB7E@delong.com>
 <CAL9jLaaR8_R+DX-wVpEvGe4pQhk7zmJYv04M7mAafF_U_PKDdw@mail.gmail.com>
 <E24772E7-A95B-4866-9630-2B1023EBD4FD@delong.com>
 <20151123225817.314A03D77872@rock.dv.isc.org>
 <7CD49BA4-217C-4669-A0FA-9D6E586C4ABD@delong.com>
 <CAPkb-7Axwpq9NwF=KVcqvWJGAS1QYhEH6XxO_MhbH1ahfUJf=A@mail.gmail.com>
 <CE4E1597-280D-4A37-9DC8-0CE3FFBD86E5@delong.com>
 <CAPKkNb72hLdtDv5TqVisSQc8vDiJJdnd63YmWyrcCiF-yj5kSg@mail.gmail.com>
Message-ID: <CAP-guGU3aZX702uFte9ikOX6qyEEcVr8__3ojZ1+v9UF4h=eDQ@mail.gmail.com>

On Fri, Dec 11, 2015 at 7:36 AM, Constantine A. Murenin
<mureninc at gmail.com> wrote:
> I disable VPN (which they limit to 128kbps as per above), and suddenly
> Netflix starts working just fine, since it now gets 1.5Mbps (or
> thereabouts), and 480p works just fine, even if you're tethered.  But
> yet my porn still doesn't work, even without a VPN!
>
> *** How is this not the very definition of fast vs. slow lanes, if one
> set of traffic gets a permanent 1,5Mbps high-speed treatment, whereas
> another set of traffic is limited to a slow 128kbps (or effectively
> 0kbps for video, since it won't stream at all) past the high-speed
> allocation? ***

Hi Constantine,

In the general case, because it's non-discriminatory. You had the same
speed either way until you hit your account cap and if you pay for
more bandwidth you'll have the same speed to both once again.
Moreover, anyone can pay for zero-rating.

In the T-Mobile binge-on case, it's probably a violation of net
neutrality. Unless I misunderstand, they're zero-rating folks based on
content and technology rather than payment. That's a no-no. They make
the case that they're not discriminating against one video provider or
another but they're discriminating against video providers versus
other less popular technologies whose cost of doing business is
effectively increased.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From Aaron.Hough at expedient.com  Fri Dec 11 17:12:08 2015
From: Aaron.Hough at expedient.com (Hough, Aaron)
Date: Fri, 11 Dec 2015 17:12:08 +0000
Subject: AOL emails bouncing back certain domains
Message-ID: <595919e6b99b426590e6ba87f54cf6a2@810-EXCHMB01.cbb.local>

The following problem has been acknowledged and yet, has been persisting for weeks unfortunately:

"Apparently, email messages ( that with the @aol.com domain ) bounces to and in some occasions, from multiple domains and comes up with Error 521. This has been escalated already. As of writing, we are still working towards a possible solution on this. We would like to apologize for the inconvenience this issue might have caused, but let us assure you that higher level technicians have been assigned to getting this resolved."


From cscora at apnic.net  Fri Dec 11 18:12:28 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 12 Dec 2015 04:12:28 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201512111812.tBBICSnu032424@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 12 Dec, 2015

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

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

BGP routing table entries examined:                              573795
    Prefixes after maximum aggregation (per Origin AS):          212506
    Deaggregation factor:                                          2.70
    Unique aggregates announced (without unneeded subnets):      279069
Total ASes present in the Internet Routing Table:                 52276
    Prefixes per ASN:                                             10.98
Origin-only ASes present in the Internet Routing Table:           36640
Origin ASes announcing only one prefix:                           15915
Transit ASes present in the Internet Routing Table:                6406
Transit-only ASes present in the Internet Routing Table:            169
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      37
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:              1023
    Unregistered ASNs in the Routing Table:                         367
Number of 32-bit ASNs allocated by the RIRs:                      12048
Number of 32-bit ASNs visible in the Routing Table:                9230
Prefixes from 32-bit ASNs in the Routing Table:                   35204
Number of bogon 32-bit ASNs visible in the Routing Table:            15
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            423
Number of addresses announced to Internet:                   2813287104
    Equivalent to 167 /8s, 175 /16s and 90 /24s
    Percentage of available address space announced:               76.0
    Percentage of allocated address space announced:               76.0
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.8
Total number of prefixes smaller than registry allocations:      188866

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

Prefixes being announced by APNIC Region ASes:                   145489
    Total APNIC prefixes after maximum aggregation:               39792
    APNIC Deaggregation factor:                                    3.66
Prefixes being announced from the APNIC address blocks:          153904
    Unique aggregates announced from the APNIC address blocks:    61088
APNIC Region origin ASes present in the Internet Routing Table:    5117
    APNIC Prefixes per ASN:                                       30.08
APNIC Region origin ASes announcing only one prefix:               1193
APNIC Region transit ASes present in the Internet Routing Table:    896
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1743
Number of APNIC addresses announced to Internet:              755731328
    Equivalent to 45 /8s, 11 /16s and 139 /24s
    Percentage of available APNIC address space announced:         88.3

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:                    181116
    Total ARIN prefixes after maximum aggregation:                89082
    ARIN Deaggregation factor:                                     2.03
Prefixes being announced from the ARIN address blocks:           184502
    Unique aggregates announced from the ARIN address blocks:     86820
ARIN Region origin ASes present in the Internet Routing Table:    16505
    ARIN Prefixes per ASN:                                        11.18
ARIN Region origin ASes announcing only one prefix:                5956
ARIN Region transit ASes present in the Internet Routing Table:    1725
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:     875
Number of ARIN addresses announced to Internet:              1113232064
    Equivalent to 66 /8s, 90 /16s and 146 /24s
    Percentage of available ARIN address space announced:          58.9

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, 64198-64296, 393216-395164
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:                    138024
    Total RIPE prefixes after maximum aggregation:                68622
    RIPE Deaggregation factor:                                     2.01
Prefixes being announced from the RIPE address blocks:           145940
    Unique aggregates announced from the RIPE address blocks:     90428
RIPE Region origin ASes present in the Internet Routing Table:    18037
    RIPE Prefixes per ASN:                                         8.09
RIPE Region origin ASes announcing only one prefix:                7983
RIPE Region transit ASes present in the Internet Routing Table:    2991
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          34
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4298
Number of RIPE addresses announced to Internet:               702206592
    Equivalent to 41 /8s, 218 /16s and 210 /24s
    Percentage of available RIPE address space announced:         102.1

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
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:                   60416
    Total LACNIC prefixes after maximum aggregation:              11871
    LACNIC Deaggregation factor:                                   5.09
Prefixes being announced from the LACNIC address blocks:          73218
    Unique aggregates announced from the LACNIC address blocks:   34132
LACNIC Region origin ASes present in the Internet Routing Table:   2461
    LACNIC Prefixes per ASN:                                      29.75
LACNIC Region origin ASes announcing only one prefix:               594
LACNIC Region transit ASes present in the Internet Routing Table:   543
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        23
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2138
Number of LACNIC addresses announced to Internet:             170425600
    Equivalent to 10 /8s, 40 /16s and 125 /24s
    Percentage of available LACNIC address space announced:       101.6

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:                  13465
    Total AfriNIC prefixes after maximum aggregation:              3098
    AfriNIC Deaggregation factor:                                  4.35
Prefixes being announced from the AfriNIC address blocks:         15808
    Unique aggregates announced from the AfriNIC address blocks:   6241
AfriNIC Region origin ASes present in the Internet Routing Table:   730
    AfriNIC Prefixes per ASN:                                     21.65
AfriNIC Region origin ASes announcing only one prefix:              189
AfriNIC Region transit ASes present in the Internet Routing Table:  170
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       19
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  176
Number of AfriNIC addresses announced to Internet:             71309824
    Equivalent to 4 /8s, 64 /16s and 26 /24s
    Percentage of available AfriNIC address space announced:       70.8

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
 4538     5584       4192          76   China Education and Research 
 7545     3059        346         156   TPG Telecom Limited
 4766     3016      11136         998   Korea Telecom
17974     2732        914          96   PT Telekomunikasi Indonesia
 9829     2190       1414         315   National Internet Backbone
 4755     2066        431         234   TATA Communications formerly 
 9808     1686       8639          18   Guangdong Mobile Communicatio
 4808     1568       2273         500   CNCGROUP IP network China169 
 9583     1519        163          85   Sify Limited
 9498     1402        335         112   BHARTI Airtel Ltd.

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

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
22773     3267       2964         143   Cox Communications Inc.
 3356     2591      10692         531   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
18566     2212        394         277   MegaPath Corporation
20115     1894       1902         403   Charter Communications
 6983     1698        849         239   EarthLink, Inc.
30036     1664        332         341   Mediacom Communications Corp
 4323     1577       1021         394   tw telecom holdings, inc.
  209     1460       4337        1225   Qwest Communications Company,
  701     1395      11447         665   MCI Communications Services, 

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
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2255        895        1619   Akamai International B.V.
34984     1926        321         401   TELLCOM ILETISIM HIZMETLERI A
 8551     1438        376          44   Bezeq International-Ltd
 8402     1173        544          15   OJSC "Vimpelcom"
13188     1075         97          79   TOV "Bank-Inform"
12479     1054        967          77   France Telecom Espana SA
31148     1042         47          41   Freenet Ltd.
 9198      950        349          25   JSC Kazakhtelecom
 6830      899       2713         469   Liberty Global Operations B.V

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3418        543         117   Telmex Colombia S.A.
 8151     2118       3350         503   Uninet S.A. de C.V.
 7303     1580        941         241   Telecom Argentina S.A.
 6503     1353        453          58   Axtel, S.A.B. de C.V.
28573     1243       2158         164   NET Servi?os de Comunica??o S
11830     1094        366          25   Instituto Costarricense de El
 6147     1037        376          34   Telefonica del Peru S.A.A.
 7738      994       1882          41   Telemar Norte Leste S.A.
 3816      974        459         185   COLOMBIA TELECOMUNICACIONES S
26615      960       2325          34   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
 8452     1228       1470          14   TE-AS
24863     1133        409          38   Link Egypt (Link.NET)
37611      581         39          38   Afrihost-Brevis Computer Serv
36903      540        272         108   Office National des Postes et
36992      431       1229          32   ETISALAT MISR
37492      325        192          74   Orange Tunisie
29571      244         21          11   Cote d'Ivoire Telecom
24835      234        146          12   Vodafone Data
 3741      221        837         183   Internet Solutions
15706      171         32           6   Sudatel (Sudan Telecom Co. Lt

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
 4538     5584       4192          76   China Education and Research 
10620     3418        543         117   Telmex Colombia S.A.
22773     3267       2964         143   Cox Communications Inc.
 7545     3059        346         156   TPG Telecom Limited
 4766     3016      11136         998   Korea Telecom
17974     2732        914          96   PT Telekomunikasi Indonesia
 3356     2591      10692         531   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2255        895        1619   Akamai International B.V.

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

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

  ASN   No of nets  Net Savings Description
10620      3418        3301      Telmex Colombia S.A.
22773      3267        3124      Cox Communications Inc.
 7545      3059        2903      TPG Telecom Limited
17974      2732        2636      PT Telekomunikasi Indonesia
 6389      2508        2466      BellSouth.net Inc.
39891      2473        2466      SaudiNet, Saudi Telecom Compa
 3356      2591        2060      Level 3 Communications, Inc.
 4766      3016        2018      Korea Telecom
18566      2212        1935      MegaPath Corporation
 9829      2190        1875      National Internet Backbone

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
47092   UNALLOCATED  8.8.204.0/24         16410       The Reynolds and Rey
53506   UNALLOCATED  8.17.102.0/23         3356       Level 3 Communicatio
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
18985   UNALLOCATED  8.21.68.0/22          3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
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
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
31.170.96.0/23       23456     32bit Transition AS
31.217.248.0/21      44902     COVAGE NETWORKS SASU
37.46.8.0/23         13768     Peer 1 Network (USA) Inc.
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.

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:11      /10:36      /11:100     /12:265     
/13:508     /14:1014    /15:1772    /16:12964   /17:7387    /18:12607   
/19:25540   /20:37739   /21:39941   /22:63279   /23:54855   /24:314197  
/25:544     /26:578     /27:380     /28:16      /29:16      /30:9       
/31:0       /32:21      

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

  ASN   No of nets  Total ann.   Description
22773     2457          3267      Cox Communications Inc.
39891     2432          2473      SaudiNet, Saudi Telecom Compa
18566     2114          2212      MegaPath Corporation
 6389     1553          2508      BellSouth.net Inc.
30036     1481          1664      Mediacom Communications Corp
 6983     1345          1698      EarthLink, Inc.
10620     1288          3418      Telmex Colombia S.A.
34984     1211          1926      TELLCOM ILETISIM HIZMETLERI A
11492     1140          1230      CABLE ONE, INC.
31148      961          1042      Freenet Ltd.

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

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

   1:1645      2:705       4:100       5:2050      6:26        8:1410   
  12:1808     13:29       14:1593     15:23       16:2        17:56     
  18:19       20:46       22:1        23:1321     24:1740     27:2153   
  31:1644     32:54       33:2        34:4        35:5        36:185    
  37:2200     38:1130     39:22       40:76       41:3006     42:369    
  43:1624     44:36       45:1550     46:2343     47:64       49:1042   
  50:821      52:35       54:96       55:8        56:8        57:44     
  58:1416     59:834      60:513      61:1760     62:1463     63:1914   
  64:4419     65:2189     66:4056     67:2144     68:1090     69:3277   
  70:1044     71:464      72:1987     74:2554     75:357      76:417    
  77:1376     78:1261     79:815      80:1326     81:1361     82:854    
  83:669      84:772      85:1520     86:454      87:1050     88:549    
  89:1905     90:167      91:5973     92:860      93:2298     94:2208   
  95:2231     96:472      97:354      98:910      99:45      100:79     
 101:863     103:9072    104:2189    105:73      106:360     107:1138   
 108:637     109:2352    110:1226    111:1537    112:871     113:1195   
 114:901     115:1517    116:1502    117:1326    118:1999    119:1496   
 120:511     121:1159    122:2255    123:1873    124:1546    125:1740   
 128:702     129:353     130:389     131:1274    132:575     133:169    
 134:451     135:119     136:344     137:310     138:1545    139:188    
 140:247     141:465     142:636     143:722     144:572     145:149    
 146:806     147:606     148:1269    149:457     150:623     151:813    
 152:574     153:268     154:467     155:896     156:436     157:446    
 158:341     159:1061    160:421     161:689     162:2216    163:499    
 164:709     165:1091    166:313     167:906     168:1341    169:554    
 170:1479    171:265     172:362     173:1569    174:717     175:763    
 176:1516    177:3971    178:2279    179:1070    180:2032    181:1618   
 182:1898    183:656     184:765     185:5123    186:3021    187:1891   
 188:2096    189:1710    190:7487    191:1221    192:8720    193:5732   
 194:4316    195:3705    196:2251    197:1141    198:5514    199:5522   
 200:6677    201:3494    202:9872    203:9293    204:4568    205:2744   
 206:2989    207:3012    208:4013    209:3971    210:3744    211:2011   
 212:2624    213:2163    214:836     215:73      216:5740    217:1877   
 218:742     219:544     220:1635    221:802     222:646     223:865    


End of report

From eric.sieg at gmail.com  Fri Dec 11 18:22:28 2015
From: eric.sieg at gmail.com (Eric Sieg)
Date: Fri, 11 Dec 2015 13:22:28 -0500
Subject: Looking for a Network Solution contact
Message-ID: <CAEcHXr7UADXuUdqBLpLe9155SKabcCiLN50e6sjYORjTwAPqwA@mail.gmail.com>

If you could contact me off list, i'd appreciate it.

From blake at ispn.net  Fri Dec 11 21:54:13 2015
From: blake at ispn.net (Blake Hudson)
Date: Fri, 11 Dec 2015 15:54:13 -0600
Subject: AOL emails bouncing back certain domains
In-Reply-To: <595919e6b99b426590e6ba87f54cf6a2@810-EXCHMB01.cbb.local>
References: <595919e6b99b426590e6ba87f54cf6a2@810-EXCHMB01.cbb.local>
Message-ID: <566B4605.1030401@ispn.net>

Aaron, I reported an issue here almost a month ago (521 5.2.1 : AOL will 
not accept delivery of this message). AOL support did, eventually, 
acknowledge an issue and the failed deliveries did, eventually, clear up 
for us. AOL support never stated what the issue was nor did they provide 
any explanation. The responses that we received, much like the response 
you received, did not give me the impression that their support staff 
was provided any information to pass along.

The only advice I can offer is to take care of your own stuff and keep 
following up with AOL occasionally regarding their issues. There's not 
much you can do, as a non AOL customer, to resolve their issue. We did 
have some AOL customers reach out to AOL and it seems as though they 
also had trouble getting any reasonable level of support.

--Blake

Hough, Aaron wrote on 12/11/2015 11:12 AM:
> The following problem has been acknowledged and yet, has been persisting for weeks unfortunately:
>
> "Apparently, email messages ( that with the @aol.com domain ) bounces to and in some occasions, from multiple domains and comes up with Error 521. This has been escalated already. As of writing, we are still working towards a possible solution on this. We would like to apologize for the inconvenience this issue might have caused, but let us assure you that higher level technicians have been assigned to getting this resolved."
>


From jra at baylink.com  Sat Dec 12 06:18:38 2015
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 12 Dec 2015 01:18:38 -0500
Subject: John McAfee: Massive DDoS attack on the internet was from smartphone
 botnet on popular app
Message-ID: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>

Is McAfee just talking to dry his teeth here? This isn't actually practical, is it? Carriers would notice, right?

http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-app-1532993
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From colinj at gt86car.org.uk  Sat Dec 12 06:35:05 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Sat, 12 Dec 2015 06:35:05 +0000
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
Message-ID: <917A28AE-9258-4F13-BE43-1E53D7472EA9@gt86car.org.uk>

saw a lot of bad traffic from china mobile more recently, hard to solve since abuse reports ignored.....

colin
Sent from my iPhone

> On 12 Dec 2015, at 06:18, Jay Ashworth <jra at baylink.com> wrote:
> 
> Is McAfee just talking to dry his teeth here? This isn't actually practical, is it? Carriers would notice, right?
> 
> http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-app-1532993
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

From john-nanog at peachfamily.net  Sat Dec 12 13:06:22 2015
From: john-nanog at peachfamily.net (John Peach)
Date: Sat, 12 Dec 2015 08:06:22 -0500
Subject: AOL emails bouncing back certain domains
In-Reply-To: <566B4605.1030401@ispn.net>
References: <595919e6b99b426590e6ba87f54cf6a2@810-EXCHMB01.cbb.local>
 <566B4605.1030401@ispn.net>
Message-ID: <20151212080622.5740ad1b@hulk>

I too reported this issue here and an AOL postmaster contacted me
offlist and got our servers sorted.

On Fri, 11 Dec 2015 15:54:13 -0600
Blake Hudson <blake at ispn.net> wrote:

> Aaron, I reported an issue here almost a month ago (521 5.2.1 : AOL will 
> not accept delivery of this message). AOL support did, eventually, 
> acknowledge an issue and the failed deliveries did, eventually, clear up 
> for us. AOL support never stated what the issue was nor did they provide 
> any explanation. The responses that we received, much like the response 
> you received, did not give me the impression that their support staff 
> was provided any information to pass along.
> 
> The only advice I can offer is to take care of your own stuff and keep 
> following up with AOL occasionally regarding their issues. There's not 
> much you can do, as a non AOL customer, to resolve their issue. We did 
> have some AOL customers reach out to AOL and it seems as though they 
> also had trouble getting any reasonable level of support.
> 
> --Blake
> 
> Hough, Aaron wrote on 12/11/2015 11:12 AM:
> > The following problem has been acknowledged and yet, has been persisting for weeks unfortunately:
> >
> > "Apparently, email messages ( that with the @aol.com domain ) bounces to and in some occasions, from multiple domains and comes up with Error 521. This has been escalated already. As of writing, we are still working towards a possible solution on this. We would like to apologize for the inconvenience this issue might have caused, but let us assure you that higher level technicians have been assigned to getting this resolved."
> >
> 


-- 
John
PGP Public Key: 412934AC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151212/aec9ff6f/attachment.pgp>

From dcorbe at hammerfiber.com  Sat Dec 12 13:50:29 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Sat, 12 Dec 2015 08:50:29 -0500
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
Message-ID: <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>


> On Dec 12, 2015, at 1:18 AM, Jay Ashworth <jra at baylink.com> wrote:
> 
> Is McAfee just talking to dry his teeth here? This isn't actually practical, is it? Carriers would notice, right?

Whether carriers might notice (or even care, because hey we can bill for data!) is debatable.  But...

> 
> http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-app-1532993

"and the unsophisticated way the botnet could be implemented through a simple smartphone app, suggests hackers sympathetic to Islamic State (Isis) may be behind it."

"The majority of the domain servers are controlled by U.S. interests - three are controlled by the US government. Who has the largest axe to grind? Isis. Who has the most to gain? Isis. Isis certainly has the technical capability to write a popular app.?

He certainly is making some wild leaps of logic here.

This is the most substantive sentence in the article: "But I have no direct evidence.?




From nanog at shankland.org  Sat Dec 12 17:23:47 2015
From: nanog at shankland.org (Jim Shankland)
Date: Sat, 12 Dec 2015 09:23:47 -0800
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
Message-ID: <566C5823.8010707@shankland.org>

Also, this jumped out at me:

"The problem with the recent attack is that the originating IP addresses 
were evenly distributed within the IPV4 universe," McAfee says. "This is 
virtually impossible using spoofing."

Am I missing something, or is an even distribution of originating IP 
addresses virtually impossible *without* using spoofing?

Jim




From rdobbins at arbor.net  Sat Dec 12 17:34:06 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sun, 13 Dec 2015 00:34:06 +0700
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <566C5823.8010707@shankland.org>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org>
Message-ID: <EB8422A5-EFAD-464D-AF9D-4715A1BD17FD@arbor.net>

On 13 Dec 2015, at 0:23, Jim Shankland wrote:

> Am I missing something, or is an even distribution of originating IP 
> addresses virtually impossible *without* using spoofing?

If his remarks were reported correctly, they are incorrect.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rsk at gsp.org  Sat Dec 12 17:42:20 2015
From: rsk at gsp.org (Rich Kulawiec)
Date: Sat, 12 Dec 2015 12:42:20 -0500
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <566C5823.8010707@shankland.org>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org>
Message-ID: <20151212174220.GA4941@gsp.org>

On Sat, Dec 12, 2015 at 09:23:47AM -0800, Jim Shankland wrote:
> Also, this jumped out at me:
> 
> "The problem with the recent attack is that the originating IP
> addresses were evenly distributed within the IPV4 universe," McAfee
> says. "This is virtually impossible using spoofing."
> 
> Am I missing something, or is an even distribution of originating IP
> addresses virtually impossible *without* using spoofing?

I think it's quite doable using botnets.  I routinely log attacks/abuse 
that are clearly coordinated, yet originate from very diverse sources.

---rsk

From marka at isc.org  Sat Dec 12 22:45:00 2015
From: marka at isc.org (Mark Andrews)
Date: Sun, 13 Dec 2015 09:45:00 +1100
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: Your message of "Sat, 12 Dec 2015 12:42:20 -0500."
 <20151212174220.GA4941@gsp.org>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org> <20151212174220.GA4941@gsp.org>
Message-ID: <20151212224500.7AFB93F3B851@rock.dv.isc.org>


In message <20151212174220.GA4941 at gsp.org>, Rich Kulawiec writes:
> On Sat, Dec 12, 2015 at 09:23:47AM -0800, Jim Shankland wrote:
> > Also, this jumped out at me:
> > 
> > "The problem with the recent attack is that the originating IP
> > addresses were evenly distributed within the IPV4 universe," McAfee
> > says. "This is virtually impossible using spoofing."
> > 
> > Am I missing something, or is an even distribution of originating IP
> > addresses virtually impossible *without* using spoofing?
> 
> I think it's quite doable using botnets.  I routinely log attacks/abuse 
> that are clearly coordinated, yet originate from very diverse sources.

"very diverse sources" does not imply "even distribution".  If they
are not spoofed addresses you would expect to see hot and cool spots
on a heat map of IPv4 space.

If they are spoofed addresses and there is a uniform random number
generator used then you would expect to see a uniform heat map.

Given the way some individual root nodes operate it is blindingly
easy to see spoofed traffic as many of them don't service the entire
Internet normally.  Routing delivers traffic from particular subsets
to particular nodes.  Each node services a part of the Internet and
only receives taffic from that part.  If you see the whole Internet
when you normally only see a subset of the Internet at this node
then the traffic is spoofed.  If you see traffic only from the usual
sources at the node then the traffic is not spoofed.

Now I don't know what was actually seen as the only information
I've seen is what has been publically released.

Mark

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

From morrowc.lists at gmail.com  Sun Dec 13 01:38:57 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 12 Dec 2015 20:38:57 -0500
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <20151212224500.7AFB93F3B851@rock.dv.isc.org>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org> <20151212174220.GA4941@gsp.org>
 <20151212224500.7AFB93F3B851@rock.dv.isc.org>
Message-ID: <CAL9jLabQw1CjYwBUd1BpzZae=HNT2inbUCa66tSEJ+aEPw5XOw@mail.gmail.com>

you all do realize you are debating a popular press article who's
single 'source' is a loon, right?

On Sat, Dec 12, 2015 at 5:45 PM, Mark Andrews <marka at isc.org> wrote:
>
> In message <20151212174220.GA4941 at gsp.org>, Rich Kulawiec writes:
>> On Sat, Dec 12, 2015 at 09:23:47AM -0800, Jim Shankland wrote:
>> > Also, this jumped out at me:
>> >
>> > "The problem with the recent attack is that the originating IP
>> > addresses were evenly distributed within the IPV4 universe," McAfee
>> > says. "This is virtually impossible using spoofing."
>> >
>> > Am I missing something, or is an even distribution of originating IP
>> > addresses virtually impossible *without* using spoofing?
>>
>> I think it's quite doable using botnets.  I routinely log attacks/abuse
>> that are clearly coordinated, yet originate from very diverse sources.
>
> "very diverse sources" does not imply "even distribution".  If they
> are not spoofed addresses you would expect to see hot and cool spots
> on a heat map of IPv4 space.
>
> If they are spoofed addresses and there is a uniform random number
> generator used then you would expect to see a uniform heat map.
>
> Given the way some individual root nodes operate it is blindingly
> easy to see spoofed traffic as many of them don't service the entire
> Internet normally.  Routing delivers traffic from particular subsets
> to particular nodes.  Each node services a part of the Internet and
> only receives taffic from that part.  If you see the whole Internet
> when you normally only see a subset of the Internet at this node
> then the traffic is spoofed.  If you see traffic only from the usual
> sources at the node then the traffic is not spoofed.
>
> Now I don't know what was actually seen as the only information
> I've seen is what has been publically released.
>
> Mark
>
>> ---rsk
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From jhall at futuresouth.us  Sun Dec 13 10:14:53 2015
From: jhall at futuresouth.us (Jonathan Hall)
Date: Sun, 13 Dec 2015 10:14:53 +0000
Subject: Fwd: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
References: <080DDFF0-F1C4-4091-8592-8A1F163679F6@futuresouth.us>
Message-ID: <985C0695-57F8-4665-B463-981AAA63B3C6@futuresouth.us>

Stupid me forgot to CC the NANOG list.

Begin forwarded message:

From: Jonathan Hall <jhall at futuresouth.us<mailto:jhall at futuresouth.us>>
Date: 13 December 2015 at 11:13:31 GMT+1
To: Jay Ashworth <jra at baylink.com<mailto:jra at baylink.com>>
Subject: Re: John McAfee: Massive DDoS attack on the internet was from smartphone botnet on popular app

DDoS attacks launched from massive botnets are not unusual, and mobile phones being used as participants of said botnets has been a well known thing since android came to market.

People seem to have forgotten about AgoBot/PhatBot/GaoBot. Once upon a time, it was dubbed ?The Swiss Army Knife of The Internet,? being fully cross-platform. It compiled on Linux, BSD and Windows with no problem, and as such, had spreading capabilities to infect cross-platform just the same. It was purely P2P at core, but also supported IRC. The P2P portion was for the developers. Anyone who had botnets generally only used and knew of the the IRC control point, and the code was watermarked originally to prevent any random Joe Blow from compiling. The botnets of those who had the code from Ago, Phatty and Wonk (the originators of the first release) were able to be controlled by a select group of friends of the developers.

This put more than 4 million bots at the disposal of that group.

Examining the synflood code that was contained within would show that the spoofing had multiple options, one of which was 100% completely random spoofed address per a packet.

My personal favourite is the 0.0.0.0 source spoof, which spoofs from various random hosts in 0.0.0.0/8 . Good luck filtering those out with ACL?s and mitigation techniques? I?m not certain that would work today, but it most certainly did in 2004.

Concepts like this do not die off and just fade away into /dev/null land. People simply get smarter and quieter about it. Ago/Phatty/Wonk got hit in Operation Cyber Slam in 2004 and the bulk of it all was kept very quiet. Coincidentally, Ago?s young brother, Nills, was the developer of msblaster, too. But, alas, I digress...

Considering all of that, why would anyone be shocked to find massive attacks being launched from what is technically the easiest point of infection: phones? In this case, all that?s done is an app gets put up and the users download it. And with thinks such as android roots and iPhone jailbreaks being common knowledge and point-and-click easy to do? More and more people are unlocking their devices just for the sake of saying, ?My phone is rooted.? And as phones become more and more powerful, as well as bandwidth climbing to record highs on mobile platforms, you can only be assured that this sort of attack vector will continue to increase in popularity.

I do think that jumping up and saying, ?ISIS is taking over US phones!? is a bit of a wild leap. But at the same time, why would anyone think they aren?t already using this method to fund themselves? Botnets = money, period. Do you have any idea how much money people pay for usage of botnets to launch attacks? Just pure chance says there are members of ISIL as well as present and potentially future supporters of ISIL that have botnets. After all, twelve year old kids with Guy Fawkes masks in their mothers basements have botnets these days?

On 12 Dec 2015, at 07:18, Jay Ashworth <jra at baylink.com<mailto:jra at baylink.com>> wrote:

Is McAfee just talking to dry his teeth here? This isn't actually practical, is it? Carriers would notice, right?

http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-app-1532993
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



From brunner at nic-naa.net  Mon Dec 14 03:06:11 2015
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Sun, 13 Dec 2015 19:06:11 -0800
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
Message-ID: <566E3223.6080204@nic-naa.net>

If the system of interest consists of a non-trivial number of carrier 
edge devices, then a non-random distribution of source addresses is 
certain. (para 1, tech).

The armed organization referred to as "Isis" is described[1,2] in some 
detail, in the first as having sophisticated digital marketing 
experience and resources, and in the second as having a functional 
administrative within its internal structures. One, or both, are 
sufficient to de-corollate that organization and "unsophisticated" 
means. (para 1, cont.)

And as Jim Shankland points out, only spoofing can randomize 
carrier-originating addresses.

Eric

[1] 
http://www.cracked.com/blog/isis-wants-us-to-invade-7-facts-revealed-by-their-magazine 
(yes, an odd journal of record, but life is odd, not even)
[2] 
http://www.theguardian.com/world/2015/dec/07/islamic-state-document-masterplan-for-power


On 12/11/15 10:18 PM, Jay Ashworth wrote:
> Is McAfee just talking to dry his teeth here? This isn't actually practical, is it? Carriers would notice, right?
>
> http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attack-internet-was-smartphone-botnet-popular-app-1532993


From jcenile1983 at gmail.com  Mon Dec 14 05:19:33 2015
From: jcenile1983 at gmail.com (John Cenile)
Date: Mon, 14 Dec 2015 16:19:33 +1100
Subject: Amazon - Detecting wrong location
Message-ID: <CAEhSU475sqxLGsJ8uumWMvaBv0Hy8=N6FzaT5n9AVNge4rQRDw@mail.gmail.com>

Hello,

Amazon's website is currently suggesting Amazon India, rather than Amazon
USA. So I'm guessing whatever GeoIP database they're using is out of date,
but I have updated as many public GeoIP databases I could find.

I have emailed their noc@ email address multiple times, but have not heard
back from them.

Does anyone know where I can fix this up, or who I can contact to resolve
this?

From dot at dotat.at  Mon Dec 14 10:26:43 2015
From: dot at dotat.at (Tony Finch)
Date: Mon, 14 Dec 2015 10:26:43 +0000
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <566C5823.8010707@shankland.org>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org>
Message-ID: <alpine.LSU.2.00.1512141023510.959@hermes-2.csi.cam.ac.uk>

Jim Shankland <nanog at shankland.org> wrote:

> Also, this jumped out at me:
>
> "The problem with the recent attack is that the originating IP addresses were
> evenly distributed within the IPV4 universe," McAfee says. "This is virtually
> impossible using spoofing."
>
> Am I missing something, or is an even distribution of originating IP addresses
> virtually impossible *without* using spoofing?

You are correct and McAfee is confused.

http://root-servers.org/news/events-of-20151130.txt

   DNS root name servers that use IP anycast observed this
   traffic at a significant number of anycast sites.

This implies that the botnet was widely distributed.

   The source addresses of these particular queries appear to be
   randomized and distributed throughout the IPv4 address space.

This says the attackers also used spoofing.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: East 5 to 7, occasionally gale 8 in Rockall.
Moderate or rough, occasionally very rough in Rockall. Occasional rain. Good,
occasionally poor.

From ying.zhang13 at hpe.com  Mon Dec 14 15:31:47 2015
From: ying.zhang13 at hpe.com (Zhang, Ying)
Date: Mon, 14 Dec 2015 15:31:47 +0000
Subject: Survey on Middlebox modeling and troubleshooting
Message-ID: <9FB7CAEB5595194395CF60B36B98FEED1DABCD2C@G4W3210.americas.hpqcorp.net>

Dear All,

We are researchers in HP Labs and Duke university. We are currently working on a project related to Middlebox modeling and troubleshooting.
We are currently conducting a survey and gathering feedback from operators.
Can you help us by providing some answers? Please feel free to email us if you have any additional suggestions.
https://www.surveymonkey.com/r/5SFP6G8

Thanks!
-Ying


From ispcolohost at gmail.com  Mon Dec 14 21:00:48 2015
From: ispcolohost at gmail.com (David H)
Date: Mon, 14 Dec 2015 16:00:48 -0500
Subject: Opinions on Cologix data centers?
Message-ID: <CAMQ0et0Nhd_Va888KuFkhWGnQ=rDX-mJAvnn+AEnboKpszL9EA@mail.gmail.com>

Hello; was curious if anyone has opinions on Cologix?  Any aspect would be
of interest; management, financials, colo quality (power, a/c, etc).  The
specific facility I'm looking at is their Lakeland FL building which began
life under a company called Colo 5 that they purchased; it's only two years
old.  They seem to have been on a buying spree recently with other colo
buildings.

Thanks,

David

From oliver.oboyle at gmail.com  Mon Dec 14 21:12:48 2015
From: oliver.oboyle at gmail.com (Oliver O'Boyle)
Date: Mon, 14 Dec 2015 16:12:48 -0500
Subject: Opinions on Cologix data centers?
In-Reply-To: <CAMQ0et0Nhd_Va888KuFkhWGnQ=rDX-mJAvnn+AEnboKpszL9EA@mail.gmail.com>
References: <CAMQ0et0Nhd_Va888KuFkhWGnQ=rDX-mJAvnn+AEnboKpszL9EA@mail.gmail.com>
Message-ID: <CAMOPTEwKYAwy4_tP0DHwODXeKGi3kw2W0HvFC=ciy=ZGqk4qNg@mail.gmail.com>

I used/inherited them in Montreal after they bought out a series of colos.
The corporate management team is good and I would work with them again.
They saw themselves as partners and not just a vendor. The local DC
manager/team was honest and easy to work with and they were very
knowledgeable.

The quality of the facility and success of your projects depends in great
deal on what they bought and what stage they are at in upgrading it. In my
case, the original DC had some design issues they were battling with
related to the previous owner + unplanned growth that forced some poor
decisions. Cologix did, however, redesign everything and make some major
investments in the facility. We saw improvements come out every few months.

Oliver

On Mon, Dec 14, 2015 at 4:00 PM, David H <ispcolohost at gmail.com> wrote:

> Hello; was curious if anyone has opinions on Cologix?  Any aspect would be
> of interest; management, financials, colo quality (power, a/c, etc).  The
> specific facility I'm looking at is their Lakeland FL building which began
> life under a company called Colo 5 that they purchased; it's only two years
> old.  They seem to have been on a buying spree recently with other colo
> buildings.
>
> Thanks,
>
> David
>



-- 
:o@>

From fciocchetti at mintel.com  Mon Dec 14 13:33:03 2015
From: fciocchetti at mintel.com (Francesco Ciocchetti)
Date: Mon, 14 Dec 2015 13:33:03 +0000
Subject: Turkey .tr domains un-resolvable over IPv4 ?
Message-ID: <CAMfY69n8gP2PoOmKBkga6P_SWWgVvz7-wdgqccgXJxcRJFxZKw@mail.gmail.com>

Is anyone seeing the same ?

I am only able to reach any of the

tr.                     172800  IN      NS      ns2.nic.tr.
tr.                     172800  IN      NS      ns4.nic.tr.
tr.                     172800  IN      NS      ns5.nic.tr.
tr.                     172800  IN      NS      ns1.nic.tr.
tr.                     172800  IN      NS      ns3.nic.tr.

over IPv6 right now ,

Short time ago traceroute was showing routing loops for ipv4 - www.nic.tr

* 27. 144.122.1.21                              91.7%    12  351.2 351.2
351.2 351.2   0.0*
* 28. ??                                        100.0    12    0.0   0.0
0.0   0.0   0.0*
* 29. 144.122.1.21                              90.0%    10  336.2 336.2
336.2 336.2   0.0*
* 30. 144.122.1.22                              88.9%     9  159.9 159.9
159.9 159.9   0.0*

same for ns1.nic.tr : 144.122.95.51


Francesco Ciocchetti

-- 

Mintel Group Ltd | 11 Pilgrim Street | London | EC4V 6RN
Registered in England: Number 1475918. | VAT Number: GB 232 9342 72

Contact details for our other offices can be found at 
http://www.mintel.com/office-locations.

This email and any attachments may include content that is confidential, 
privileged 
or otherwise protected under applicable law. Unauthorised disclosure, 
copying, distribution 
or use of the contents is prohibited and may be unlawful. If you have 
received this email in error,
including without appropriate authorisation, then please reply to the 
sender about the error 
and delete this email and any attachments.


From earp at champlain.edu  Mon Dec 14 14:02:49 2015
From: earp at champlain.edu (Earp, John)
Date: Mon, 14 Dec 2015 09:02:49 -0500
Subject: bway.net contact?
Message-ID: <CABBn5EBbRpdsHKMs3SAj5ijYHXCx37J4+LTPZCMecuVkFthMAg@mail.gmail.com>

Would someone from bway.net ISP contact me off list please?  Thank you.

From wayne.wenthin at cascadetech.org  Mon Dec 14 15:57:27 2015
From: wayne.wenthin at cascadetech.org (Wayne Wenthin)
Date: Mon, 14 Dec 2015 07:57:27 -0800
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <alpine.LSU.2.00.1512141023510.959@hermes-2.csi.cam.ac.uk>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org>
 <alpine.LSU.2.00.1512141023510.959@hermes-2.csi.cam.ac.uk>
Message-ID: <CAJnYNYK7VmL4xX5e-bgg4A1p+KkzSa_59kJyUq6YBf=zHkc5sQ@mail.gmail.com>

Keep in mind that he is running for President also.

From stu at actusa.net  Mon Dec 14 21:07:48 2015
From: stu at actusa.net (Stuart Sheldon)
Date: Mon, 14 Dec 2015 13:07:48 -0800
Subject: Opinions on Cologix data centers?
In-Reply-To: <CAMQ0et0Nhd_Va888KuFkhWGnQ=rDX-mJAvnn+AEnboKpszL9EA@mail.gmail.com>
References: <CAMQ0et0Nhd_Va888KuFkhWGnQ=rDX-mJAvnn+AEnboKpszL9EA@mail.gmail.com>
Message-ID: <566F2FA4.6090903@actusa.net>

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

Hi David,

We've been in their facility in Dallas for about a year now and have had
great luck with them. Very happy with there service.

DISCLAIMER: We have our own AS and do not buy bandwidth from them, so I
can not attest to their connectivity, but their power and cooling have
been consistently awesome.

Stu Sheldon
ACT USA


On 12/14/2015 01:00 PM, David H wrote:
> Hello; was curious if anyone has opinions on Cologix?  Any aspect would be
> of interest; management, financials, colo quality (power, a/c, etc).  The
> specific facility I'm looking at is their Lakeland FL building which began
> life under a company called Colo 5 that they purchased; it's only two years
> old.  They seem to have been on a buying spree recently with other colo
> buildings.
> 
> Thanks,
> 
> David
> 

- -- 
And you run and you run to catch up with the sun, but its sinking
And racing around to come up behind you again
The sun is the same in the relative way, but youre older
Shorter of breath and one day closer to death
               -- Pink Floyd - "Time Lyrics"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJWby+jAAoJEFKVLITDJSGSW6IP/3buhnkulqNEzT5vWQ0Mtwr0
XN0gggjKONQxDKMeiwYQJ1WjrFCg29YavIcq45l/iXDA5qEl+izhYNUrinR4iQf6
X8wYJofxSC/C75C3I2Qd260KC3KjDMEQOb6TcvxAZhCfPDP8lG5cRm7SUwnb48Ke
pVEexeRcvOBYQpq9ph0qFx9zGT0ewIJd1jQSWmfM5VZsUOvxCSflhddTV4l5/taW
fTg+ensSMuT+kA5/R+92/cqzGT9yUROGJw+uD9zGijeWX0iGC7CxhIP/kXyjoC3S
783/5pc+nPzayJEHdcuhe/onFP7jRv4fGHWhjJDkI/YGBFeB80++zioruIUItRQt
ugCYg3I5QLULTVxq6l2o9xpy0nK6c6p+0au7k8ZIkn/ks4K50XhJuRpZfKo3n+zV
RzDDCD67QAgThMVi0IRWQYeX/uHt/zO3zTw6kllCuPjlDLlCPM6iNPmOLolooDbL
QXy4BANHz1HOVk89BRBU8Lqh2Zp2HHlSA9+Q4HeJ8nQul4FfQxmuV+k09Aajigur
Xaklko4WP9Qusl4trlfGKoHXPBxjjyYVw8Mb+THZu1erQVCy/5kvya8OtrBMm03I
d3t3I2EwH5/uL/dLaLOpIMDbd2KrAzjVf8+KxYonTTFa2uJzsRuZ20f6x2aUt4QF
DYCTU5qExQbxWiwBWXrY
=tUS6
-----END PGP SIGNATURE-----

From jared at puck.nether.net  Tue Dec 15 01:56:28 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 14 Dec 2015 20:56:28 -0500
Subject: Turkey .tr domains un-resolvable over IPv4 ?
In-Reply-To: <CAMfY69n8gP2PoOmKBkga6P_SWWgVvz7-wdgqccgXJxcRJFxZKw@mail.gmail.com>
References: <CAMfY69n8gP2PoOmKBkga6P_SWWgVvz7-wdgqccgXJxcRJFxZKw@mail.gmail.com>
Message-ID: <E1F91DC7-D1CB-4374-8C95-C5FA2B571D5E@puck.nether.net>

I was told this was done due to a DDoS attack that originated outside turkey.  I have been unable to locate someone with enough details that they could be assisted to bring this back online.  We did look into traffic patterns on-network and saw attack traffic prior to the routes going away but without a route it?s much harder to assist.

Anyone at nic.tr or RIPE that has been working this is welcome to contact me off-list for assistance.

I?m actually quite surprised it took so many hours to make NANOG, and hasn?t yet made the DNS-operations list.

- Jared

> On Dec 14, 2015, at 8:33 AM, Francesco Ciocchetti <fciocchetti at mintel.com> wrote:
> 
> Is anyone seeing the same ?
> 
> I am only able to reach any of the
> 
> tr.                     172800  IN      NS      ns2.nic.tr.
> tr.                     172800  IN      NS      ns4.nic.tr.
> tr.                     172800  IN      NS      ns5.nic.tr.
> tr.                     172800  IN      NS      ns1.nic.tr.
> tr.                     172800  IN      NS      ns3.nic.tr.
> 
> over IPv6 right now ,
> 
> Short time ago traceroute was showing routing loops for ipv4 - www.nic.tr
> 
> * 27. 144.122.1.21                              91.7%    12  351.2 351.2
> 351.2 351.2   0.0*
> * 28. ??                                        100.0    12    0.0   0.0
> 0.0   0.0   0.0*
> * 29. 144.122.1.21                              90.0%    10  336.2 336.2
> 336.2 336.2   0.0*
> * 30. 144.122.1.22                              88.9%     9  159.9 159.9
> 159.9 159.9   0.0*
> 
> same for ns1.nic.tr : 144.122.95.51
> 
> 
> Francesco Ciocchetti
> 
> -- 
> 
> Mintel Group Ltd | 11 Pilgrim Street | London | EC4V 6RN
> Registered in England: Number 1475918. | VAT Number: GB 232 9342 72
> 
> Contact details for our other offices can be found at 
> http://www.mintel.com/office-locations.
> 
> This email and any attachments may include content that is confidential, 
> privileged 
> or otherwise protected under applicable law. Unauthorised disclosure, 
> copying, distribution 
> or use of the contents is prohibited and may be unlawful. If you have 
> received this email in error,
> including without appropriate authorisation, then please reply to the 
> sender about the error 
> and delete this email and any attachments.


From dave.taht at gmail.com  Tue Dec 15 09:48:50 2015
From: dave.taht at gmail.com (Dave Taht)
Date: Tue, 15 Dec 2015 10:48:50 +0100
Subject: reliably detecting the presence of a bridge?
Message-ID: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>

I am curious if there is some sort of igmp or other form of message
that would reliably detect if a switch had a bridge on it. How could
deviceA detect deviceC was a bridge in this case?

deviceA  -> ethernet switch -> deviceB
                    ethernet switch -> deviceC with bridged wifi and ethernet

question came up in the context of:

http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.html

--
Dave T?ht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

From contact at winterei.se  Tue Dec 15 12:32:25 2015
From: contact at winterei.se (Paul S.)
Date: Tue, 15 Dec 2015 21:32:25 +0900
Subject: Opinions on Cologix data centers?
In-Reply-To: <CAMOPTEwKYAwy4_tP0DHwODXeKGi3kw2W0HvFC=ciy=ZGqk4qNg@mail.gmail.com>
References: <CAMQ0et0Nhd_Va888KuFkhWGnQ=rDX-mJAvnn+AEnboKpszL9EA@mail.gmail.com>
 <CAMOPTEwKYAwy4_tP0DHwODXeKGi3kw2W0HvFC=ciy=ZGqk4qNg@mail.gmail.com>
Message-ID: <56700859.5090003@winterei.se>

I recommend them for everything other than the quality of their remote 
hands. They could do with some improvements in this department.

We have space at Cologix Dallas (within Infomart), and it's all fine. We 
run our own ASN too though, so no idea on the bandwidth side of things.

On 12/15/2015 06:12 AM, Oliver O'Boyle wrote:
> I used/inherited them in Montreal after they bought out a series of colos.
> The corporate management team is good and I would work with them again.
> They saw themselves as partners and not just a vendor. The local DC
> manager/team was honest and easy to work with and they were very
> knowledgeable.
>
> The quality of the facility and success of your projects depends in great
> deal on what they bought and what stage they are at in upgrading it. In my
> case, the original DC had some design issues they were battling with
> related to the previous owner + unplanned growth that forced some poor
> decisions. Cologix did, however, redesign everything and make some major
> investments in the facility. We saw improvements come out every few months.
>
> Oliver
>
> On Mon, Dec 14, 2015 at 4:00 PM, David H <ispcolohost at gmail.com> wrote:
>
>> Hello; was curious if anyone has opinions on Cologix?  Any aspect would be
>> of interest; management, financials, colo quality (power, a/c, etc).  The
>> specific facility I'm looking at is their Lakeland FL building which began
>> life under a company called Colo 5 that they purchased; it's only two years
>> old.  They seem to have been on a buying spree recently with other colo
>> buildings.
>>
>> Thanks,
>>
>> David
>>
>
>


From jared at puck.Nether.net  Tue Dec 15 13:04:36 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Tue, 15 Dec 2015 08:04:36 -0500
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
Message-ID: <20151215130436.GA6777@puck.nether.net>

On Tue, Dec 15, 2015 at 10:48:50AM +0100, Dave Taht wrote:
> I am curious if there is some sort of igmp or other form of message
> that would reliably detect if a switch had a bridge on it. How could
> deviceA detect deviceC was a bridge in this case?
> 
> deviceA  -> ethernet switch -> deviceB
>                     ethernet switch -> deviceC with bridged wifi and ethernet
> 
> question came up in the context of:
> 
> http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.html

	The best way I've seen is to measure latency to the devices and infer from there.
You can always make the latency longer, but making it shorter is much harder :)

	- 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 matthew at matthew.at  Tue Dec 15 14:46:51 2015
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 15 Dec 2015 10:46:51 -0400
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
Message-ID: <04B519D1-BFAE-474C-86AF-902ADA4F4707@matthew.at>

Why do you care if there's a bridge? Seems you care about higher latency, packet loss, lower reliability, etc. Measure what matters and act on that, rather than trying to guess performance from link type.

Matthew Kaufman

(Sent from my iPhone)

> On Dec 15, 2015, at 5:48 AM, Dave Taht <dave.taht at gmail.com> wrote:
> 
> I am curious if there is some sort of igmp or other form of message
> that would reliably detect if a switch had a bridge on it. How could
> deviceA detect deviceC was a bridge in this case?
> 
> deviceA  -> ethernet switch -> deviceB
>                    ethernet switch -> deviceC with bridged wifi and ethernet
> 
> question came up in the context of:
> 
> http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.html
> 
> --
> Dave T?ht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi

From bill at herrin.us  Tue Dec 15 15:19:37 2015
From: bill at herrin.us (William Herrin)
Date: Tue, 15 Dec 2015 10:19:37 -0500
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
Message-ID: <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>

On Tue, Dec 15, 2015 at 4:48 AM, Dave Taht <dave.taht at gmail.com> wrote:
> I am curious if there is some sort of igmp or other form of message
> that would reliably detect if a switch had a bridge on it. How could
> deviceA detect deviceC was a bridge in this case?

Hi Dave,

Start with precision in language. An ethernet switch is one form of
ethernet bridge although the reverse is not necessarily true. So, a
switch is always a bridge by definition. Q.E.D.

>From what you've posted, you don't want to detect the difference
between a switch and a bridge, you want to detect the difference
between a wired and wireless segment segment in the network. Is that
correct? Any wireless link or just radio? Any radio link or just
802.11 wifi? Are you just trying to detect stations behind wireless or
do you want to identify segments that are carried over wireless?

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From tim.h at bendtel.com  Tue Dec 15 21:55:46 2015
From: tim.h at bendtel.com (Tim Howe)
Date: Tue, 15 Dec 2015 13:55:46 -0800
Subject: AT&T (SBC Global) email admins?
Message-ID: <20151215135546.36ed5cf7@cool.bendtel.com>

I hate going this route, but repeated attempts at all other avenues
have been exhausted.

	We have a customer IP that has been blocked from sending email
to SBC Global addresses since day one.  The options AT&T has presented
for dealing with this clearly have no effect or simply don't work (one
of the email addresses bounces).

	Could someone contact me privately and clue me in as to who can
be contacted to clear an old blacklist entry?

--TimH

From frnkblk at iname.com  Tue Dec 15 22:36:21 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 15 Dec 2015 16:36:21 -0600
Subject: John McAfee: Massive DDoS attack on the internet was from
 smartphone botnet on popular app
In-Reply-To: <alpine.LSU.2.00.1512141023510.959@hermes-2.csi.cam.ac.uk>
References: <254A692C-2050-4E6E-9A9A-3E1E2B7ECB1A@baylink.com>
 <6039BE6E-341D-43EF-8048-E5065B776652@hammerfiber.com>
 <566C5823.8010707@shankland.org>
 <alpine.LSU.2.00.1512141023510.959@hermes-2.csi.cam.ac.uk>
Message-ID: <005f01d13789$05bf85e0$113e91a0$@iname.com>

Good stuff from Duane here:
http://www.circleid.com/posts/20151215_verisign_perspective_on_recent_root_s
erver_attacks/

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tony Finch
Sent: Monday, December 14, 2015 4:27 AM
To: Jim Shankland <nanog at shankland.org>
Cc: nanog at nanog.org
Subject: Re: John McAfee: Massive DDoS attack on the internet was from
smartphone botnet on popular app

Jim Shankland <nanog at shankland.org> wrote:

> Also, this jumped out at me:
>
> "The problem with the recent attack is that the originating IP addresses
were
> evenly distributed within the IPV4 universe," McAfee says. "This is
virtually
> impossible using spoofing."
>
> Am I missing something, or is an even distribution of originating IP
addresses
> virtually impossible *without* using spoofing?

You are correct and McAfee is confused.

http://root-servers.org/news/events-of-20151130.txt

   DNS root name servers that use IP anycast observed this
   traffic at a significant number of anycast sites.

This implies that the botnet was widely distributed.

   The source addresses of these particular queries appear to be
   randomized and distributed throughout the IPv4 address space.

This says the attackers also used spoofing.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: East 5 to 7, occasionally gale 8 in
Rockall.
Moderate or rough, occasionally very rough in Rockall. Occasional rain.
Good,
occasionally poor.



From smutt at depht.com  Tue Dec 15 15:04:21 2015
From: smutt at depht.com (Andrew McConachie)
Date: Tue, 15 Dec 2015 10:04:21 -0500
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
Message-ID: <56702BF5.2080508@depht.com>

Flip a bit in the Ethernet FCS as it egresses deviceA. If the frame 
arrives with a correct checksum at deviceB, then there's a switch in the 
middle. Most modern switches recalculate FCS at egress port.

If the frame never arrives, most likely there is a switch in between. If 
the frame arrives with the broken FCS, there is no intermediate switch.

--Andrew

On 12/15/15 4:48 AM, Dave Taht wrote:
> I am curious if there is some sort of igmp or other form of message
> that would reliably detect if a switch had a bridge on it. How could
> deviceA detect deviceC was a bridge in this case?
>
> deviceA  -> ethernet switch -> deviceB
>                      ethernet switch -> deviceC with bridged wifi and ethernet
>
> question came up in the context of:
>
> http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.html
>
> --
> Dave T?ht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi


From ahmed.dalaali at hrins.net  Tue Dec 15 18:08:34 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Tue, 15 Dec 2015 21:08:34 +0300
Subject: Nat
Message-ID: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>

Dear All, 

We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.

Please any advice regarding the three brands and what are the advantages and disadvantages for each one? 


Regards,  




From nellermann at broadaspect.com  Wed Dec 16 01:12:47 2015
From: nellermann at broadaspect.com (Nick Ellermann)
Date: Wed, 16 Dec 2015 01:12:47 +0000
Subject: Nat
In-Reply-To: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
Message-ID: <87102386af2f4a5f92e012a18ead1cf5@exchange.broadaspect.local>

What features and scale do you need? Assume with NAT you are performing some levels of firewall security and serving applications? 


Sincerely,
Nick Ellermann - CTO & VP Cloud Services
BroadAspect
?
E: nellermann at broadaspect.com 
P: 703-297-4639
F: 703-996-4443
?
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

-----Original Message-----
From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com at nanog.org] On Behalf Of Ahmed Munaf
Sent: Tuesday, December 15, 2015 1:09 PM
To: nanog at nanog.org
Subject: Nat

Dear All, 

We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.

Please any advice regarding the three brands and what are the advantages and disadvantages for each one? 


Regards,  




From hf0002+nanog at uah.edu  Wed Dec 16 01:15:42 2015
From: hf0002+nanog at uah.edu (Hunter Fuller)
Date: Tue, 15 Dec 2015 19:15:42 -0600
Subject: Nat
In-Reply-To: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
Message-ID: <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>

You are using a Cisco what for NAT? And which products are you considering?

On Tuesday, December 15, 2015, Ahmed Munaf <ahmed.dalaali at hrins.net> wrote:

> Dear All,
>
> We are using cisco for natting, we'd like to change it to another brand
> like A10 or Citrix.
>
> Please any advice regarding the three brands and what are the advantages
> and disadvantages for each one?
>
>
> Regards,
>
>
>
>

From dave.taht at gmail.com  Wed Dec 16 09:36:46 2015
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 16 Dec 2015 10:36:46 +0100
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
Message-ID: <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>

On Tue, Dec 15, 2015 at 4:19 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Dec 15, 2015 at 4:48 AM, Dave Taht <dave.taht at gmail.com> wrote:
>> I am curious if there is some sort of igmp or other form of message
>> that would reliably detect if a switch had a bridge on it. How could
>> deviceA detect deviceC was a bridge in this case?
>
> Hi Dave,
>
> Start with precision in language. An ethernet switch is one form of
> ethernet bridge although the reverse is not necessarily true. So, a
> switch is always a bridge by definition. Q.E.D.

Sure.

>
> From what you've posted, you don't want to detect the difference
> between a switch and a bridge, you want to detect the difference

To be more clear I wanted to detect if there was more than one
bridge on the network, where the bridge being a PITA was a wired/wireless
bridge.

> between a wired and wireless segment segment in the network. Is that
> correct? Any wireless link or just radio? Any radio link or just
> 802.11 wifi?

I believe the radios in this case were probably ubnt.

https://nodes.wlan-si.net/network/statistics/

>Are you just trying to detect stations behind wireless or
> do you want to identify segments that are carried over wireless?

The latter.

In this case a routing optimization that works well on wired links was
enabled when there were wireless bridges on that segment, leading to
some chaos in the originally referenced thread.


The "right", slower, inefficient on wired, routing metric is the ETX
metric in that case, but knowing when to turn that on, automatically,
would be nice... which means somehow detecting there was a wireless
bridge on that network. So as no announcements of BPDUs are seen, I
was hoping there was some sort of active query that could be made
asking if there was anything weird and wireless nearby.....

https://nodes.wlan-si.net/topology/

> Regards,
> Bill Herrin
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From swmike at swm.pp.se  Wed Dec 16 10:32:22 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 16 Dec 2015 11:32:22 +0100 (CET)
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1512161122520.29581@uplift.swm.pp.se>

On Tue, 15 Dec 2015, Dave Taht wrote:

> I am curious if there is some sort of igmp or other form of message
> that would reliably detect if a switch had a bridge on it. How could
> deviceA detect deviceC was a bridge in this case?
>
> deviceA  -> ethernet switch -> deviceB
>                    ethernet switch -> deviceC with bridged wifi and ethernet
>
> question came up in the context of:
>
> http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.html

It seems that the goal here is to find out if there is some kind of L2 
device that bridges to a medium that uses retransmits to handle that it's 
not natively up to the 10^-12 BER that wired ethernet adheres to and that 
might have variable transfer speeds and might stall due to adverse 
conditions from time to time?

I would say no, there is no simple way of doing that. You can 
heuristically detect if multiple parties on the LAN participates and if 
you're willing to send probe packets to see if there is a mac-learning 
device in the middle, but it's hard to determine if this just a regular 
wired ethernet switch or if it uses some other medium.

Easiest way for babel is most likely to do the link quality detection on 
all mediums, or at least do it as soon as there has been some packet loss 
seen. If the devices are willing to time stamp the packets and they check 
that the RTT between the devices is always sub-1ms, then that's a decent 
indicator that the link is high speed and wired, and if it's over 1ms, 
it's time to start running the link quality estimation algorithm. Facing 
bufferbloat so that link is over 1ms RTT, you probably want to 
link-estimate it anyway...

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

From mohta at necom830.hpcl.titech.ac.jp  Wed Dec 16 10:37:38 2015
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Wed, 16 Dec 2015 19:37:38 +0900
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
Message-ID: <56713EF2.1040608@necom830.hpcl.titech.ac.jp>

Dave Taht wrote:

> To be more clear I wanted to detect if there was more than one
> bridge on the network, where the bridge being a PITA was a wired/wireless
> bridge.

Listen to spanning tree protocol.

							Masataka Ohta

From ahmed.dalaali at hrins.net  Wed Dec 16 10:45:16 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Wed, 16 Dec 2015 13:45:16 +0300
Subject: Nat
In-Reply-To: <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
Message-ID: <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net>

Yes, we are using ASR1004 for NAT, we are considering A10 or Citrix or F5. we?ve not decided till now! 
maybe we change it  to another product, if anyone give us a better solution. 

this will be used for ISP?s users. 

> On Dec 16, 2015, at 4:15 AM, Hunter Fuller <hf0002+nanog at uah.edu> wrote:
> 
> You are using a Cisco what for NAT? And which products are you considering?
> 
> On Tuesday, December 15, 2015, Ahmed Munaf <ahmed.dalaali at hrins.net <mailto:ahmed.dalaali at hrins.net>> wrote:
> Dear All,
> 
> We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.
> 
> Please any advice regarding the three brands and what are the advantages and disadvantages for each one?
> 
> 
> Regards,
> 
> 
> 


From cabo at tzi.org  Wed Dec 16 12:50:43 2015
From: cabo at tzi.org (Carsten Bormann)
Date: Wed, 16 Dec 2015 13:50:43 +0100
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <567139D5.9080209@tzi.org>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <567139D5.9080209@tzi.org>
Message-ID: <56715E23.9090309@tzi.org>

[Dave asked me to repost this to the list -- not sure how useful this
little lead is; haven't worked on this for more than half a decade.]

I don't have a good platform to test this on today, but one way to
detect a wireless bridge a couple of years ago was to send a SNAP packet
(actually anything with an Ethernet length -- as opposed to ethertype --
in it) that is shorter than Ethernet minimum length (14 + 46), and then
see whether the padding you put in on one end survives over to the other
end.  That of course only works with bridges that actually optimize this
case (plus you can detect those that completely mess up this case --
there are quite a few of those).

Hope that helps; would need to do experiments with real hardware to say
anything more substantive.

Gr??e, Carsten

PS.: In case you wonder what the work was that led to this observation:
https://tools.ietf.org/html/draft-bormann-rohc-over-802-02


From chuckchurch at gmail.com  Wed Dec 16 13:40:48 2015
From: chuckchurch at gmail.com (Chuck Church)
Date: Wed, 16 Dec 2015 08:40:48 -0500
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
Message-ID: <05dc01d13807$643e3520$2cba9f60$@gmail.com>

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dave Taht
Sent: Wednesday, December 16, 2015 4:37 AM
To: William Herrin <bill at herrin.us>
Cc: NANOG <nanog at nanog.org>
Subject: Re: reliably detecting the presence of a bridge?


The latter.

In this case a routing optimization that works well on wired links was enabled when there were wireless bridges on that segment, leading to some chaos in the originally referenced thread.


The "right", slower, inefficient on wired, routing metric is the ETX metric in that case, but knowing when to turn that on, automatically, would be nice... which means somehow detecting there was a wireless bridge on that network. So as no announcements of BPDUs are seen, I was hoping there was some sort of active query that could be made asking if there was anything weird and wireless nearby.....

https://nodes.wlan-si.net/topology/

----------------------------------------------------------------------------

Seems there are two possible ways to attach wireless clients to a wired network (at least 2 common ways).  A consumer-grade wireless router doing NAT, or a true layer 2 AP.  Assuming neither are sending BPDUs, there are a few ways to detect them I can think of, assuming you've got control of the switch they're attached to:

Wireless AP (L2 only) - port security limiting number of learnable MAC address per port is pretty easy.  In the case of UBNT you mentioned, it's even easier.  They use a discovery protocol (multicast I believe) and have CDP, both on by default.

NATing router - a little tougher to do.  Scanning your DCHP database or ARP/MAC tables for OUI that shouldn't be on the network - Linksys, D-Link, Netgear etc.  Or perhaps occasionally port-scan your network looking for open TCP/8080, I think that's the most common port for  managing these.  They may not respond on the WAN side if configured right, but the old default was on.  NMAP and its fingerprinting might come in handy too, if they're turned off access from the WAN side.

Chuck


From anoop at alumni.duke.edu  Wed Dec 16 15:33:04 2015
From: anoop at alumni.duke.edu (Anoop Ghanwani)
Date: Wed, 16 Dec 2015 07:33:04 -0800
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <05dc01d13807$643e3520$2cba9f60$@gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <05dc01d13807$643e3520$2cba9f60$@gmail.com>
Message-ID: <CA+-tSzzezs_w+xzyVasDFxmrQtqGYbPkdrdtj2uA6wvAdj0=ZQ@mail.gmail.com>

If LLDP (link layer discovery protocol) is enabled, you could try using
that.  There is a system capabilities TLV in the LLDPDU sent by a system,
but I'm not sure how reliably it is filled in, especially if a device is
capable of both switching and routing.  The way LLDP is supposed to work is
a device will receive LLDPDUs from other devices immediately adjacent to
it.  It can then read the LLDP database of those devices (via management)
and figure out what those devices are connected to, and so on.

Otherwise, bridges are supposed to be "transparent," so there is no way to
know they are present by using user data frames.

Anoop

From mark.tinka at seacom.mu  Wed Dec 16 16:22:21 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 16 Dec 2015 18:22:21 +0200
Subject: Nat
In-Reply-To: <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net>
Message-ID: <56718FBD.8050602@seacom.mu>



On 16/Dec/15 12:45, Ahmed Munaf wrote:

> Yes, we are using ASR1004 for NAT, we are considering A10 or Citrix or F5. we?ve not decided till now! 
> maybe we change it  to another product, if anyone give us a better solution. 
>
> this will be used for ISP?s users. 

The ASR1000 is not a bad large scale NAT device. Are there any specific
issues you are facing with it?

Mark.

From ahmed.dalaali at hrins.net  Wed Dec 16 16:36:19 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Wed, 16 Dec 2015 19:36:19 +0300
Subject: Nat
In-Reply-To: <56718FBD.8050602@seacom.mu>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
Message-ID: <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>

In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems! 

Ahmed, 

> On Dec 16, 2015, at 7:22 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 16/Dec/15 12:45, Ahmed Munaf wrote:
> 
>> Yes, we are using ASR1004 for NAT, we are considering A10 or Citrix or F5. we?ve not decided till now! 
>> maybe we change it  to another product, if anyone give us a better solution. 
>> 
>> this will be used for ISP?s users. 
> 
> The ASR1000 is not a bad large scale NAT device. Are there any specific
> issues you are facing with it?
> 
> Mark.


From mark.tinka at seacom.mu  Wed Dec 16 16:52:08 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 16 Dec 2015 18:52:08 +0200
Subject: Nat
In-Reply-To: <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
Message-ID: <567196B8.9020508@seacom.mu>



On 16/Dec/15 18:36, Ahmed Munaf wrote:

> In addition to the limited concurrent sessions for ASR1000, we are
> facing some issue with many users how are playing online games! Nat
> problems!

This could be a function of the size of your ESP.

The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP
will do 4,000,000 NAT sessions with a per-second setup rate of 300,000
sessions.

Of course, it makes little sense to upgrade if you run out of sessions
before you hit the NAT throughput ceiling, so other vendors may be more
commercially palatable.

Mark.

From dwessels at verisign.com  Wed Dec 16 19:15:51 2015
From: dwessels at verisign.com (Wessels, Duane)
Date: Wed, 16 Dec 2015 19:15:51 +0000
Subject: Call for Presentations - DNS-OARC Spring Workshop, March/April 2016
Message-ID: <705034F9-5837-4CA9-8E46-C5BDA9896B6A@verisign.com>


The 24th DNS-OARC Workshop will take place in Buenos Aires, Argentina between March 31st and April 1st 2016, Thursday and Friday before IETF95. This will be the first time DNS-OARC is held in the Southern Hemisphere. To attract the best DNS minds and local audience, DNS-OARC is requesting proposals for presentations, with a preference for Operational Practices Reports, and "How we solved this problem" presentations.

This workshop intends to build from previous strong DNS-OARC workshops, where both operational content and research are welcome. Presentations from DNS operators are particularly desired, as well as from DNS researchers. All DNS-related subjects are accepted. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. A timeslot will be available for lightning talks (5-10 minutes) on April 1st, for which submissions will be accepted during March 31st on a first-come first-served basis.

Workshop Milestones
	? 30th November 2015, Call for Presentations posted and open for submissions
	? 29th January 2016, Deadline for submission
	? 16th February 2016, Final Program published
	? 28th March 2016, Final deadline for slideset submission

Details for abstract submission are published here:

        https://indico.dns-oarc.net/event/22/call-for-abstracts/

The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To ensure the quality of the workshop, submissions including draft slides will get extra points during evaluation.

You can contact the Programme Committee (https://www.dns-oarc.net/oarc/programme) via <submissions at dns-oarc.net> if you have questions or concerns.

OARC is also seeking sponsorship for this workshop, please contact <sponsor at dns-oarc.net> if your organization is interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

Duane Wessels, on behalf of the OARC Program Committee

From octalnanog at alvarezp.org  Wed Dec 16 19:37:45 2015
From: octalnanog at alvarezp.org (Octavio Alvarez)
Date: Wed, 16 Dec 2015 11:37:45 -0800
Subject: Nat
In-Reply-To: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
Message-ID: <5671BD89.7000606@alvarezp.org>

On 15/12/15 10:08, Ahmed Munaf wrote:
> Dear All, 
> 
> We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.

If you are willing to rephrase it to "we are using Cisco IOS for
NATting, we'd like to change it to another platform or brand", you may
want to take a look at Cisco ASAs. In my opinion those are better
NATters than IOS.

Best regards.

From tony at wicks.co.nz  Wed Dec 16 19:46:48 2015
From: tony at wicks.co.nz (Tony Wicks)
Date: Thu, 17 Dec 2015 08:46:48 +1300
Subject: Nat
In-Reply-To: <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
Message-ID: <002601d1383a$81640750$842c15f0$@wicks.co.nz>

We have the ASR1006 ESP40's handling 25,000+home broadband users running NAT and barely breaking a sweat. What ESP are you using ?

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ahmed Munaf
Sent: Thursday, 17 December 2015 5:36 AM
To: Mark Tinka <mark.tinka at seacom.mu>
Cc: nanog at nanog.org
Subject: Re: Nat

In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems! 

Ahmed, 



From Jason_Livingood at cable.comcast.com  Wed Dec 16 22:38:50 2015
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 16 Dec 2015 22:38:50 +0000
Subject: Nat
In-Reply-To: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
Message-ID: <D29747F0.11F8D4%jason_livingood@cable.comcast.com>

IPv4 NAT!? Free yourself from the tyranny of shared addresses. ;-)

http://www.comcast6.net/images/files/revolt.jpg	


Jason



On 12/15/15, 1:08 PM, "NANOG on behalf of Ahmed Munaf"
<nanog-bounces+jason_livingood=cable.comcast.com at nanog.org on behalf of
ahmed.dalaali at hrins.net> wrote:

>Dear All, 
>
>We are using cisco for natting, we'd like to change it to another brand
>like A10 or Citrix.
>
>Please any advice regarding the three brands and what are the advantages
>and disadvantages for each one?
>
>
>Regards,  
>
>
>
>


From r.engehausen at gmail.com  Wed Dec 16 22:51:51 2015
From: r.engehausen at gmail.com (Roy)
Date: Wed, 16 Dec 2015 15:51:51 -0700
Subject: IPV6 availability
Message-ID: <5671EB07.7020807@gmail.com>

Anyone know what the IPV6 availability is on Cable One or Charter networks?

Last I heard from Charter was that they were in beta.  Its been in that 
state for years.

I can't find anything on Cable One

From josh at kyneticwifi.com  Wed Dec 16 23:25:06 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Wed, 16 Dec 2015 17:25:06 -0600
Subject: Nat
In-Reply-To: <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
Message-ID: <CAC6=tfbKWa_wW+HgL_4RtFSL8K_NaE3wqAXt3zPJ_cOtZMZCww@mail.gmail.com>

If it were only so easy...
On Dec 16, 2015 4:41 PM, "Livingood, Jason" <
Jason_Livingood at cable.comcast.com> wrote:

> IPv4 NAT!? Free yourself from the tyranny of shared addresses. ;-)
>
> http://www.comcast6.net/images/files/revolt.jpg
>
>
> Jason
>
>
>
> On 12/15/15, 1:08 PM, "NANOG on behalf of Ahmed Munaf"
> <nanog-bounces+jason_livingood=cable.comcast.com at nanog.org on behalf of
> ahmed.dalaali at hrins.net> wrote:
>
> >Dear All,
> >
> >We are using cisco for natting, we'd like to change it to another brand
> >like A10 or Citrix.
> >
> >Please any advice regarding the three brands and what are the advantages
> >and disadvantages for each one?
> >
> >
> >Regards,
> >
> >
> >
> >
>
>

From marka at isc.org  Wed Dec 16 23:28:56 2015
From: marka at isc.org (Mark Andrews)
Date: Thu, 17 Dec 2015 10:28:56 +1100
Subject: Nat
In-Reply-To: <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
Message-ID: <770D0609-0A3A-4142-854F-210410682D69@isc.org>

+1000000

Nobody should have to be doing NAT today.

We need to make IPv4 painful to use.  Adding  delay between SYN and SYN/ACK would
be one way to achieve this.  Start at 100ms..200ms and increase it by 100ms each year.

Mark

On 17/12/2015, at 9:38 AM, "Livingood, Jason" <Jason_Livingood at cable.comcast.com> wrote:

> IPv4 NAT!? Free yourself from the tyranny of shared addresses. ;-)
> 
> http://www.comcast6.net/images/files/revolt.jpg	
> 
> 
> Jason

From nanogml at Mail.DDoS-Mitigator.net  Wed Dec 16 23:49:06 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Wed, 16 Dec 2015 15:49:06 -0800
Subject: Nat
In-Reply-To: <770D0609-0A3A-4142-854F-210410682D69@isc.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
Message-ID: <20151216234906.GA5898@Mail.DDoS-Mitigator.net>


hi folkx

On 12/17/15 at 10:28am, Mark Andrews wrote:
> We need to make IPv4 painful to use.

already is too crowded

> Adding  delay between SYN and SYN/ACK would be one way to achieve this.

<flame suiton>
change tcp windoow size to 1 byte per packet or decrease from 1500 byte
packets, more traffic they use, slower it becomes 

instead of zero byte as used in tarpits

>  Start at 100ms..200ms and increase it by 100ms each year.

some of verizon's shared IPv4 traffic has delays exceeding 3sec 
and i seen it exceeding 6sec for simple things like using gmail
thru their network

"delays" are built in automatically ...
- too much spam ..
- too much useless video downloads
- too much useless steaming
- too much useless pix
- too much games 

and alll that junk will increase as more people use it

it'd be nice to put these "services" on their own private LAN
and slow just themself down instead of slowing everybody down

pay more $$$ to get better/faster connectivity ...

</flame suiton>
ducking for cover
alvin

From marka at isc.org  Wed Dec 16 23:52:41 2015
From: marka at isc.org (Mark Andrews)
Date: Thu, 17 Dec 2015 10:52:41 +1100
Subject: Nat
In-Reply-To: <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
Message-ID: <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>

This doesn't put pain on those that have enough addresses that they don't need
to NAT yet.  We need to put some pain onto everyone that is IPv4 only.

Mark

On 17/12/2015, at 10:39 AM, Charles Monson <charles.lists at camonson.com> wrote:

> We need to make IPv4 painful to use.  Adding  delay between SYN and SYN/ACK would
> be one way to achieve this.  Start at 100ms..200ms and increase it by 100ms each year.
> 
> It seems like NAT would be another way to make IPv4 more painful to use.


From mel at beckman.org  Thu Dec 17 00:14:20 2015
From: mel at beckman.org (Mel Beckman)
Date: Thu, 17 Dec 2015 00:14:20 +0000
Subject: Nat
In-Reply-To: <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>,
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
Message-ID: <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>

Mark,

Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually. 

I don't like what you eat. Lets put a surcharge on it to make you feel pain and do what I want. :)

 -mel beckman

> On Dec 16, 2015, at 3:55 PM, Mark Andrews <marka at isc.org> wrote:
> 
> This doesn't put pain on those that have enough addresses that they don't need
> to NAT yet.  We need to put some pain onto everyone that is IPv4 only.
> 
> Mark
> 
>> On 17/12/2015, at 10:39 AM, Charles Monson <charles.lists at camonson.com> wrote:
>> 
>> We need to make IPv4 painful to use.  Adding  delay between SYN and SYN/ACK would
>> be one way to achieve this.  Start at 100ms..200ms and increase it by 100ms each year.
>> 
>> It seems like NAT would be another way to make IPv4 more painful to use.
> 

From larrysheldon at cox.net  Thu Dec 17 00:28:17 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Wed, 16 Dec 2015 18:28:17 -0600
Subject: Nat
In-Reply-To: <770D0609-0A3A-4142-854F-210410682D69@isc.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
Message-ID: <567201A1.6050004@cox.net>

On 12/16/2015 17:28, Mark Andrews wrote:
> +1000000
>
> Nobody should have to be doing NAT today.
>
> We need to make IPv4 painful to use.  Adding  delay between SYN and
> SYN/ACK would be one way to achieve this.  Start at 100ms..200ms and
> increase it by 100ms each year.


If it is such a good idea, why do you have to do that?




-- 
sed quis custodiet ipsos custodes? (Juvenal)

From larrysheldon at cox.net  Thu Dec 17 00:30:53 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Wed, 16 Dec 2015 18:30:53 -0600
Subject: Nat
In-Reply-To: <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
Message-ID: <5672023D.40902@cox.net>

On 12/16/2015 18:14, Mel Beckman wrote:
> Mark,
>
> Why? Why do WE "need" to force people to bend to our will? The market
> will get us all there eventually.
>
> I don't like what you eat. Lets put a surcharge on it to make you
> feel pain and do what I want. :)

That's what I'm talking about.

But this IS right out of the current government's handbook.
-- 
sed quis custodiet ipsos custodes? (Juvenal)

From marka at isc.org  Thu Dec 17 00:57:29 2015
From: marka at isc.org (Mark Andrews)
Date: Thu, 17 Dec 2015 11:57:29 +1100
Subject: Nat
In-Reply-To: <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>,
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
Message-ID: <CBE806D8-470A-4695-8E71-16DFBED288CB@isc.org>

While we will get us there eventually it will be at the considerably more expensive
for everyone involved.  There is also a distinct lack of a working free market in most
of the world.  There isn't one in Australia.  From what I read there isn't one in most
of the developed nations in the world including the US.

Mark

On 17/12/2015, at 11:14 AM, Mel Beckman <mel at beckman.org> wrote:

> Mark,
> 
> Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually. 
> 
> I don't like what you eat. Lets put a surcharge on it to make you feel pain and do what I want. :)
> 
> -mel beckman
> 
>> On Dec 16, 2015, at 3:55 PM, Mark Andrews <marka at isc.org> wrote:
>> 
>> This doesn't put pain on those that have enough addresses that they don't need
>> to NAT yet.  We need to put some pain onto everyone that is IPv4 only.
>> 
>> Mark
>> 
>>> On 17/12/2015, at 10:39 AM, Charles Monson <charles.lists at camonson.com> wrote:
>>> 
>>> We need to make IPv4 painful to use.  Adding  delay between SYN and SYN/ACK would
>>> be one way to achieve this.  Start at 100ms..200ms and increase it by 100ms each year.
>>> 
>>> It seems like NAT would be another way to make IPv4 more painful to use.
>> 


From randy at psg.com  Thu Dec 17 01:22:18 2015
From: randy at psg.com (Randy Bush)
Date: Thu, 17 Dec 2015 10:22:18 +0900
Subject: Nat
In-Reply-To: <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
Message-ID: <m24mfhj2d1.wl%randy@psg.com>

> We need to put some pain onto everyone that is IPv4 only.

this is the oppress the workers so they will revolt theory.  load of
crap.

make ipv6 easier to deploy, especially in enterprise.  repeat the
previous sentence 42 times.

what keeps the cows in the pasture is the quality of the grass not
the height of the fence.

randy

From mike-nanog at tiedyenetworks.com  Thu Dec 17 01:37:49 2015
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Wed, 16 Dec 2015 17:37:49 -0800
Subject: Comcast carrier sales
Message-ID: <567211ED.7050408@tiedyenetworks.com>

Hi,

     Im trying to establish connectivity with comcast and their normal 
sales channel doesn't seem to be equipped to deal with a facilities 
based carrier who wishes to establish some kind of meet-me arrangement 
on fiber. Does anyone know or can a comcast carrer sales rep contact me? 
I want to give you money....

Mike-

From larrysheldon at cox.net  Thu Dec 17 01:49:49 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Wed, 16 Dec 2015 19:49:49 -0600
Subject: Nat
In-Reply-To: <uRP01r0151cZc5601RP1oE>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <uRP01r0151cZc5601RP1oE>
Message-ID: <567214BD.4020705@cox.net>

On 12/16/2015 19:22, Randy Bush wrote:
>> We need to put some pain onto everyone that is IPv4 only.
>
> this is the oppress the workers so they will revolt theory.  load of
> crap.
>
> make ipv6 easier to deploy, especially in enterprise.  repeat the
> previous sentence 42 times.
>
> what keeps the cows in the pasture is the quality of the grass not
> the height of the fence.


Have you considered national politics?  The world needs you.



-- 
sed quis custodiet ipsos custodes? (Juvenal)

From list at satchell.net  Thu Dec 17 02:15:03 2015
From: list at satchell.net (Stephen Satchell)
Date: Wed, 16 Dec 2015 18:15:03 -0800
Subject: Nat
In-Reply-To: <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
Message-ID: <56721AA7.5040902@satchell.net>

On 12/16/2015 04:14 PM, Mel Beckman wrote:
> I don't like what you eat. Lets put a surcharge on it to make you feel pain and do what I want.:)

"I don't like what you eat.  Lets put a TAX on it to make you feel pain 
and do what I want."

There.  Fixed it for you.

From charles.lists at camonson.com  Wed Dec 16 23:39:38 2015
From: charles.lists at camonson.com (Charles Monson)
Date: Wed, 16 Dec 2015 17:39:38 -0600
Subject: Nat
In-Reply-To: <770D0609-0A3A-4142-854F-210410682D69@isc.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
Message-ID: <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>

>
> We need to make IPv4 painful to use.  Adding  delay between SYN and
> SYN/ACK would
> be one way to achieve this.  Start at 100ms..200ms and increase it by
> 100ms each year.


It seems like NAT would be another way to make IPv4 more painful to use.

From berry at gadsdenst.org  Thu Dec 17 01:53:55 2015
From: berry at gadsdenst.org (Berry Mobley)
Date: Wed, 16 Dec 2015 20:53:55 -0500
Subject: Nat
In-Reply-To: <m24mfhj2d1.wl%randy@psg.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
Message-ID: <mailman.3.1450319644.16036.nanog@nanog.org>

At 08:22 PM 12/16/2015, Randy Bush wrote:
> > We need to put some pain onto everyone that is IPv4 only.
>
>this is the oppress the workers so they will revolt theory.  load of
>crap.
>
>make ipv6 easier to deploy, especially in enterprise.  repeat the
>previous sentence 42 times.

This. I'm in an enterprise with some stubborn vendors, and none of 
them are even talking about ipv6. It won't help me to move (and it 
won't help you to get well if you're here) if my users can't get to 
their stuff.

Berry 


From dcorbe at hammerfiber.com  Thu Dec 17 02:36:28 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Wed, 16 Dec 2015 21:36:28 -0500
Subject: Comcast carrier sales
In-Reply-To: <567211ED.7050408@tiedyenetworks.com>
References: <567211ED.7050408@tiedyenetworks.com>
Message-ID: <D3C8F814-1F36-4C03-9F17-A209BC767CBB@hammerfiber.com>


> On Dec 16, 2015, at 8:37 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> 
> Hi,
> 
>    Im trying to establish connectivity with comcast and their normal sales channel doesn't seem to be equipped to deal with a facilities based carrier who wishes to establish some kind of meet-me arrangement on fiber. Does anyone know or can a comcast carrer sales rep contact me? I want to give you money....
> 
> Mike-
> 

What?s your definition of a ?normal? sales channel?  If you?re calling the Comcast business line you probably won?t get much help.

Have you tried pinging someone at Comcast wholesale yet?

http://www.comcastwholesale.com/


From josh at kyneticwifi.com  Thu Dec 17 02:44:03 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Wed, 16 Dec 2015 20:44:03 -0600
Subject: Nat
In-Reply-To: <20151217023409.69DFB2C061A@mail.nanog.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <20151217023409.69DFB2C061A@mail.nanog.org>
Message-ID: <CAC6=tfZhwOnb8WnzMv_ohy6wXVwfb8G7Lmy=pwbGOh5znCNh+A@mail.gmail.com>

Publicly shame them by listing the ones who don't fully support IPv6. List
them here, so we know to choose their competition.
On Dec 16, 2015 8:39 PM, "Berry Mobley" <berry at gadsdenst.org> wrote:

> At 08:22 PM 12/16/2015, Randy Bush wrote:
>
>> > We need to put some pain onto everyone that is IPv4 only.
>>
>> this is the oppress the workers so they will revolt theory.  load of
>> crap.
>>
>> make ipv6 easier to deploy, especially in enterprise.  repeat the
>> previous sentence 42 times.
>>
>
> This. I'm in an enterprise with some stubborn vendors, and none of them
> are even talking about ipv6. It won't help me to move (and it won't help
> you to get well if you're here) if my users can't get to their stuff.
>
> Berry
>

From randy at psg.com  Thu Dec 17 07:07:49 2015
From: randy at psg.com (Randy Bush)
Date: Thu, 17 Dec 2015 16:07:49 +0900
Subject: Nat
In-Reply-To: <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
Message-ID: <m2poy5h7sq.wl%randy@psg.com>

> It seems like NAT would be another way to make IPv4 more painful to
> use.

it is.  but, judging by people's actions, in many cases it seems less
painful than going to ipv6.  off-pissing, but reality.

randy

From Andrew.White2 at charter.com  Thu Dec 17 13:20:41 2015
From: Andrew.White2 at charter.com (White, Andrew)
Date: Thu, 17 Dec 2015 07:20:41 -0600
Subject: IPV6 availability
In-Reply-To: <5671EB07.7020807@gmail.com>
References: <5671EB07.7020807@gmail.com>
Message-ID: <678FDBA32DA0DD4A8EFB6D1C2FDC268A0208400DFC@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>

Here's our page on IPv6 support:

http://www.charter.net/support/internet/ipv6/

TL;DR: Subscribers can only get ipv6 today via a 6rd tunnel.


Andrew White
Desk:  314.394-9594  | Cell:  314.452-4386
Systems Engineer III, DAS DNS group
Charter Communications
12405 Powerscourt Drive, St. Louis,  MO 63131



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roy
Sent: Wednesday, December 16, 2015 4:52 PM
To: nanog
Subject: IPV6 availability

Anyone know what the IPV6 availability is on Cable One or Charter networks?

Last I heard from Charter was that they were in beta.  Its been in that state for years.

I can't find anything on Cable One

From bortzmeyer at nic.fr  Thu Dec 17 14:01:37 2015
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Thu, 17 Dec 2015 15:01:37 +0100
Subject: DNSSEC and ISPs faking DNS responses
In-Reply-To: <56455885.8090409@vaxination.ca>
References: <56455885.8090409@vaxination.ca>
Message-ID: <20151217140137.GA14332@nic.fr>

On Thu, Nov 12, 2015 at 10:27:01PM -0500,
 Jean-Francois Mezei <jfmezei_nanog at vaxination.ca> wrote 
 a message of 66 lines which said:

> The Qu?bec government is wanting to pass a law that will force ISPs
> to block and/or redirect certain sites it doesn't like.  (namely
> sites that offer on-line gambling that compete against its own Loto
> Qu?bec).

You may be interested in this analysis of DNS censorship in some
european countries:

https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes/

From jim.rampley at charter.com  Thu Dec 17 14:32:48 2015
From: jim.rampley at charter.com (Rampley Jr, Jim F)
Date: Thu, 17 Dec 2015 08:32:48 -0600
Subject: IPV6 availability
In-Reply-To: <678FDBA32DA0DD4A8EFB6D1C2FDC268A0208400DFC@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>
References: <5671EB07.7020807@gmail.com>
 <678FDBA32DA0DD4A8EFB6D1C2FDC268A0208400DFC@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>
Message-ID: <D2982334.BF415%jim.rampley@charter.com>


Hi Roy,

Charter has launched IPv6 for our commercial Fiber Internet customers. We
are also in EFT with IPv6 for Cable Modem Management and Dual Stack for
Resi HSI is in our PoC lab. Both of these are expected to launch mid-2016.

Hope this is helpful. Let me know if you have any questions.

Jim





On 12/17/15, 7:20 AM, "NANOG on behalf of White, Andrew"
<nanog-bounces at nanog.org on behalf of Andrew.White2 at charter.com> wrote:

>Here's our page on IPv6 support:
>
>http://www.charter.net/support/internet/ipv6/
>
>TL;DR: Subscribers can only get ipv6 today via a 6rd tunnel.
>
>
>Andrew White
>Desk:  314.394-9594  | Cell:  314.452-4386
>Systems Engineer III, DAS DNS group
>Charter Communications
>12405 Powerscourt Drive, St. Louis,  MO 63131
>
>
>
>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roy
>Sent: Wednesday, December 16, 2015 4:52 PM
>To: nanog
>Subject: IPV6 availability
>
>Anyone know what the IPV6 availability is on Cable One or Charter
>networks?
>
>Last I heard from Charter was that they were in beta.  Its been in that
>state for years.
>
>I can't find anything on Cable One


From r.engehausen at gmail.com  Thu Dec 17 14:44:44 2015
From: r.engehausen at gmail.com (Roy)
Date: Thu, 17 Dec 2015 07:44:44 -0700
Subject: IPV6 availability
In-Reply-To: <D2982334.BF415%jim.rampley@charter.com>
References: <5671EB07.7020807@gmail.com>
 <678FDBA32DA0DD4A8EFB6D1C2FDC268A0208400DFC@KSTLMEXCP02MBX.CORP.CHARTERCOM.COM>
 <D2982334.BF415%jim.rampley@charter.com>
Message-ID: <5672CA5C.4050408@gmail.com>

Thanks for the info

I have contacted my sales rep to she if she can get it turned on for my 
fiber connection.

Roy

On 12/17/2015 7:32 AM, Rampley Jr, Jim F wrote:
> Hi Roy,
>
> Charter has launched IPv6 for our commercial Fiber Internet customers. We
> are also in EFT with IPv6 for Cable Modem Management and Dual Stack for
> Resi HSI is in our PoC lab. Both of these are expected to launch mid-2016.
>
> Hope this is helpful. Let me know if you have any questions.
>
> Jim
>
>
>
>
>
> On 12/17/15, 7:20 AM, "NANOG on behalf of White, Andrew"
> <nanog-bounces at nanog.org on behalf of Andrew.White2 at charter.com> wrote:
>
>> Here's our page on IPv6 support:
>>
>> http://www.charter.net/support/internet/ipv6/
>>
>> TL;DR: Subscribers can only get ipv6 today via a 6rd tunnel.
>>
>>
>> Andrew White
>> Desk:  314.394-9594  | Cell:  314.452-4386
>> Systems Engineer III, DAS DNS group
>> Charter Communications
>> 12405 Powerscourt Drive, St. Louis,  MO 63131
>>
>>
>>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roy
>> Sent: Wednesday, December 16, 2015 4:52 PM
>> To: nanog
>> Subject: IPV6 availability
>>
>> Anyone know what the IPV6 availability is on Cable One or Charter
>> networks?
>>
>> Last I heard from Charter was that they were in beta.  Its been in that
>> state for years.
>>
>> I can't find anything on Cable One
>


From prichter at icsi.berkeley.edu  Thu Dec 17 16:20:06 2015
From: prichter at icsi.berkeley.edu (Philipp Richter)
Date: Thu, 17 Dec 2015 17:20:06 +0100
Subject: Survey on IPv4 Scarcity, IPv6 Adoption, Carrier-Grade NAT
 Deployment
In-Reply-To: <566614C7.6050606@icsi.berkeley.edu>
References: <566614C7.6050606@icsi.berkeley.edu>
Message-ID: <5672E0B6.1060905@icsi.berkeley.edu>

Dear NANOG readers,

thank you very much for your participation in this survey. We already
received more than 60 replies from ISPs all over the world.

If you work for an ISP and didn't answer yet, we would greatly
appreciate your response.

Link to the survey: http://natsurvey.icsi.berkeley.edu/

(approx. 5 minutes, all questions explicitly optional)

thank you!

On 08/12/15 00:22, Philipp Richter wrote:
> Dear NANOG readers,
> 
> we are a team of researchers from ICSI Berkeley, TU Berlin, TU Munich,
> Internet Initiative Japan and UC Berkeley jointly working on a project
> to assess the effects of IPv4 address exhaustion.
> 
> As part of our research, we conduct a survey among network operators.
> The goal of this survey is to better understand the degree of IPv4
> scarcity that ISPs face and which measures are taken to combat it (IPv4
> Carrier-Grade NAT deployment, IPv4 address markets, and IPv6 transition
> mechanisms).
> 
> If you work for an ISP that connects end-users to the Internet, we would
> greatly appreciate your response.
> 
> To participate, please visit http://natsurvey.icsi.berkeley.edu/
> 
> (answering should take about 5 minutes, all questions are explicitly
> optional).
> 
> We will make anonymized results of this survey available to the public
> in early 2016.
> 
> Thank you very much for your support!
> 
> 
> If you have questions or concerns, please feel free to contact me
> directly at prichter AT icsi DOT berkeley DOT edu.
> 
> --
> Philipp Richter
> Research Assistant / PhD Student
> TU Berlin / ICSI
> 

From tim.h at bendtel.com  Thu Dec 17 16:22:52 2015
From: tim.h at bendtel.com (Tim Howe)
Date: Thu, 17 Dec 2015 08:22:52 -0800
Subject: AT&T (SBC Global) email admins?
In-Reply-To: <20151215135546.36ed5cf7@cool.bendtel.com>
References: <20151215135546.36ed5cf7@cool.bendtel.com>
Message-ID: <20151217082252.4a8eda20@wind.dirtymonday.net>

On Tue, 15 Dec 2015 13:55:46 -0800
Tim Howe <tim.h at bendtel.com> wrote:

> [...]
> 	Could someone contact me privately and clue me in as to who can
> be contacted to clear an old blacklist entry?
> 
> --TimH

	FYI, I got resolution off-list.  Thanks!

--TimH

From colinj at gt86car.org.uk  Thu Dec 17 16:31:23 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Thu, 17 Dec 2015 16:31:23 +0000
Subject: Fwd: ByteNight 2015 North West movie
References: <4A5B49B8-52A8-4CB9-8F91-D731A9AA2A3F@gt86car.org.uk>
Message-ID: <95CD6C45-0C6F-45D1-8C6B-5AFC740004F0@gt86car.org.uk>

As network/server techies  (UK and EU/USA) lets raise even more money donations next year for Action for Children.

Colin


> Begin forwarded message:
> 
> From: Colin Johnston <colinj at gt86car.org.uk>
> Subject: Fwd: ByteNight 2015 North West movie
> Date: 17 December 2015 at 16:25:12 GMT
> To: "<andy.burnham.mp at parliament.uk>" <andy.burnham.mp at parliament.uk>, stephen <S.Hellier at wigan.gov.uk>, "ASPINALL, Karen" <karen.aspinall at parliament.uk>, CWU Mersey Branch <unionoffice at cwumersey.org>
> Cc: Colin Johnston <colinj at gt86car.org.uk>, Kylie Prankerd <kylie.prankerd at actionforchildren.org.uk>, Eric Johnston <eric at satsig.net>, colin.johnstone at bt.com
> 
> Please come and support next year, this is important to us that this event is seen as the best event in the northwest for community involvement
> I raised 720 pounds as sole BT North West member, and 1 million pounds raised uk wide
> 
>> https://youtu.be/aHeq9F-m4NY <https://youtu.be/aHeq9F-m4NY>
> 
> 
> Colin Johnston
> 
>> Begin forwarded message:
>> 
>> From: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
>> Subject: ByteNight 2015 North West movie
>> Date: 17 December 2015 at 16:05:18 GMT
>> To: colin.johnstone at bt.com <mailto:colin.johnstone at bt.com>
>> Cc: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
>> 
>> https://youtu.be/aHeq9F-m4NY <https://youtu.be/aHeq9F-m4NY> <https://youtu.be/aHeq9F-m4NY>


From ahmed.dalaali at hrins.net  Thu Dec 17 17:30:32 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Thu, 17 Dec 2015 20:30:32 +0300
Subject: Nat
In-Reply-To: <567196B8.9020508@seacom.mu>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net> <567196B8.9020508@seacom.mu>
Message-ID: <186B1104-F30A-4EF6-A321-C17717204805@hrins.net>





> On Dec 16, 2015, at 7:52 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 16/Dec/15 18:36, Ahmed Munaf wrote:
> 
>> In addition to the limited concurrent sessions for ASR1000, we are
>> facing some issue with many users how are playing online games! Nat
>> problems!
> 
> This could be a function of the size of your ESP.
> 
> The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP
> will do 4,000,000 NAT sessions with a per-second setup rate of 300,000
> sessions.
> 
> Of course, it makes little sense to upgrade if you run out of sessions
> before you hit the NAT throughput ceiling, so other vendors may be more
> commercially palatable.
> 
> Mark.

Thats right but as you mentioned that its commercially palatable, however I don?t know if the other vendors are the same performance as ASR1000!  this was my question if someone recommend another vendor. 



From ahmed.dalaali at hrins.net  Thu Dec 17 17:36:06 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Thu, 17 Dec 2015 20:36:06 +0300
Subject: Nat
In-Reply-To: <002601d1383a$81640750$842c15f0$@wicks.co.nz>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
 <002601d1383a$81640750$842c15f0$@wicks.co.nz>
Message-ID: <4F040284-0811-4291-BA58-C7178DCBCF52@hrins.net>

we are using ESP 20 

> On Dec 16, 2015, at 10:46 PM, Tony Wicks <tony at wicks.co.nz> wrote:
> 
> We have the ASR1006 ESP40's handling 25,000+home broadband users running NAT and barely breaking a sweat. What ESP are you using ?
> 
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ahmed Munaf
> Sent: Thursday, 17 December 2015 5:36 AM
> To: Mark Tinka <mark.tinka at seacom.mu>
> Cc: nanog at nanog.org
> Subject: Re: Nat
> 
> In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems! 
> 
> Ahmed, 
> 
> 


From nick at foobar.org  Thu Dec 17 17:47:35 2015
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 17 Dec 2015 17:47:35 +0000
Subject: Nat
In-Reply-To: <4F040284-0811-4291-BA58-C7178DCBCF52@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
 <002601d1383a$81640750$842c15f0$@wicks.co.nz>
 <4F040284-0811-4291-BA58-C7178DCBCF52@hrins.net>
Message-ID: <5672F537.60707@foobar.org>

On 17/12/2015 17:36, Ahmed Munaf wrote:
> we are using ESP 20 

You haven't said what you mean by "better".  This could mean "faster" or
"copes with more sessions" or "cheaper".  If your ISP is large, then it
might be "cost per user is lower" or "able to cope with the number of users".

Nick



From eriks at netideainc.ca  Thu Dec 17 18:34:39 2015
From: eriks at netideainc.ca (Netideainc)
Date: Thu, 17 Dec 2015 13:34:39 -0500
Subject: Nat
In-Reply-To: <186B1104-F30A-4EF6-A321-C17717204805@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net> <567196B8.9020508@seacom.mu>
 <186B1104-F30A-4EF6-A321-C17717204805@hrins.net>
Message-ID: <E48CBD02-54E8-46D9-B08D-36CDD3F01DE7@netideainc.ca>

At $dayjob$ (which is a university) we spoke to several vendors and eventually gave A10 Networks Thunder 3030 a test drive.

It satisfied our requirements and fit our budget.   Most of our NAT traffic originates from our undergraduate student population.  Peak workload during 2015 fall term was about 27k concurrently active devices, 4.6Gbps, 415kpps.

The ASR1000 would have been our other choice but the ASR's higher price pushed us toward A10.

Eriks
---
Eriks Rugelis
Sr. Consultant
Netidea Inc.
T: +1.416.876.0740

> On Dec 17, 2015, at 12:30, Ahmed Munaf <ahmed.dalaali at hrins.net> wrote:
> 
> 
> 
> 
> 
>> On Dec 16, 2015, at 7:52 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>> 
>> 
>> 
>>> On 16/Dec/15 18:36, Ahmed Munaf wrote:
>>> 
>>> In addition to the limited concurrent sessions for ASR1000, we are
>>> facing some issue with many users how are playing online games! Nat
>>> problems!
>> 
>> This could be a function of the size of your ESP.
>> 
>> The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP
>> will do 4,000,000 NAT sessions with a per-second setup rate of 300,000
>> sessions.
>> 
>> Of course, it makes little sense to upgrade if you run out of sessions
>> before you hit the NAT throughput ceiling, so other vendors may be more
>> commercially palatable.
>> 
>> Mark.
> 
> Thats right but as you mentioned that its commercially palatable, however I don?t know if the other vendors are the same performance as ASR1000!  this was my question if someone recommend another vendor. 
> 
> 

From mpetach at netflight.com  Thu Dec 17 18:59:03 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 17 Dec 2015 10:59:03 -0800
Subject: Nat
In-Reply-To: <m24mfhj2d1.wl%randy@psg.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
Message-ID: <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>

On Wed, Dec 16, 2015 at 5:22 PM, Randy Bush <randy at psg.com> wrote:
>> We need to put some pain onto everyone that is IPv4 only.
>
> this is the oppress the workers so they will revolt theory.

Ah, yes, the workers are quite revolting!

> load of crap.
>
> make ipv6 easier to deploy, especially in enterprise.  repeat the
> previous sentence 42 times.


I'm still waiting for the IETF to come around
to allowing feature parity between IPv4 and IPv6
when it comes to DHCP.  The stance of not
allowing the DHCP server to assign a default
gateway to the host in IPv6 is a big stumbling
point for at least one large enterprise I'm aware
of.  Right now, the biggest obstacle to IPv6
deployment seems to be the ivory-tower types
in the IETF that want to keep it pristine, vs
allowing it to work in the real world.

> what keeps the cows in the pasture is the quality of the grass not
> the height of the fence.
>
> randy

Randy, I would happily appoint you as CIG-Q,
the Chief Inspector of Grass Quality.    ;)

Matt

From chuckchurch at gmail.com  Thu Dec 17 19:27:33 2015
From: chuckchurch at gmail.com (Chuck Church)
Date: Thu, 17 Dec 2015 14:27:33 -0500
Subject: Nat
In-Reply-To: <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
Message-ID: <01de01d13900$fe364dd0$faa2e970$@gmail.com>

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Petach
Sent: Thursday, December 17, 2015 1:59 PM
Cc: North American Network Operators' Group <nanog at nanog.org>
Subject: Re: Nat

>I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP.  

And that recent thread on prefix delegation doesn't really leave a good taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and get that/those prefix(s) in your (ISP) routing tables.  Given that 99.999% of home users would be fine with a delegation of a single /64 and a single subnet I'm tempted to do that for now and let the DHCP-PD ink dry for a while so CPE support can follow up.

Chuck


From bzs at theworld.com  Thu Dec 17 21:01:42 2015
From: bzs at theworld.com (bzs at theworld.com)
Date: Thu, 17 Dec 2015 16:01:42 -0500
Subject: failover via comcast tunnel?
Message-ID: <22131.8886.119084.674737@pcls8.std.com>


I'm looking at some sort of 50-100mbps failover link in case my
primary is down.

My options seem limited particularly since I'm cheap.

I see Comcast has unlimited data business links in this range but I'm
not sure I'd want to deal with the management issue of BGP or swapping
ip blocks etc with them in an emergency. I just tried calling their
business sales line and after the initial "Thank you for calling
Comcast Business Services etc" it dropped me...three times. Yeah, that
builds confidence.

So I'm thinking something more like using their service as a raw
bandwidth pipe and tunneling to an actual route provider?

Crazy? Anyone done anything like this? Are there tools for that?
Other, similar suggestions?

Feel free contact me off-list.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

From mhoppes at indigowireless.com  Thu Dec 17 21:15:01 2015
From: mhoppes at indigowireless.com (Matt Hoppes)
Date: Thu, 17 Dec 2015 16:15:01 -0500
Subject: failover via comcast tunnel?
In-Reply-To: <22131.8886.119084.674737@pcls8.std.com>
References: <22131.8886.119084.674737@pcls8.std.com>
Message-ID: <5C433AA7-1A9E-4D65-B403-48E57493707D@indigowireless.com>

You could tunnel to a data center. 

Or NAT out their service. 

Tunneling via EoIP would allow you to stay within their ToS. 

> On Dec 17, 2015, at 16:01, bzs at theworld.com wrote:
> 
> 
> I'm looking at some sort of 50-100mbps failover link in case my
> primary is down.
> 
> My options seem limited particularly since I'm cheap.
> 
> I see Comcast has unlimited data business links in this range but I'm
> not sure I'd want to deal with the management issue of BGP or swapping
> ip blocks etc with them in an emergency. I just tried calling their
> business sales line and after the initial "Thank you for calling
> Comcast Business Services etc" it dropped me...three times. Yeah, that
> builds confidence.
> 
> So I'm thinking something more like using their service as a raw
> bandwidth pipe and tunneling to an actual route provider?
> 
> Crazy? Anyone done anything like this? Are there tools for that?
> Other, similar suggestions?
> 
> Feel free contact me off-list.
> 
> -- 
>        -Barry Shein
> 
> Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
> The World              | Public Access Internet     | Since 1989     *oo*

From marka at isc.org  Fri Dec 18 00:46:13 2015
From: marka at isc.org (Mark Andrews)
Date: Fri, 18 Dec 2015 11:46:13 +1100
Subject: Nat
In-Reply-To: Your message of "Thu, 17 Dec 2015 14:27:33 -0500."
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
Message-ID: <20151218004613.BB9483F6434F@rock.dv.isc.org>


In message <01de01d13900$fe364dd0$faa2e970$@gmail.com>, "Chuck Church" writes:
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Petach
> Sent: Thursday, December 17, 2015 1:59 PM
> Cc: North American Network Operators' Group <nanog at nanog.org>
> Subject: Re: Nat
>
> >I'm still waiting for the IETF to come around to allowing feature
> >parity between IPv4 and IPv6 when it comes to DHCP.
>
> And that recent thread on prefix delegation doesn't really leave a good
> taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and
> get that/those prefix(s) in your (ISP) routing tables.  Given that
> 99.999% of home users would be fine with a delegation of a single /64 and
> a single subnet I'm tempted to do that for now and let the DHCP-PD ink
> dry for a while so CPE support can follow up.

I have a single CPE router and 3 /64's in use.  One for each of the
wireless SSID's and one for the wired network.  This is the default
for homenet devices.  A single /64 means you have to bridge all the
traffic.

A single /64 has never been enough and it is time to grind that
myth into the ground.  ISP's that say a single /64 is enough are
clueless.

Mark

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

From nellermann at broadaspect.com  Fri Dec 18 02:31:19 2015
From: nellermann at broadaspect.com (Nick Ellermann)
Date: Fri, 18 Dec 2015 02:31:19 +0000
Subject: IPv4 subnets for lease?
Message-ID: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>

We have customers asking to lease IP space for BGP transit with us and other peers. But they are struggling to get at a minimum even a Class C, even though they have their own ASN. We don't have large amounts of free IPv4 space to lease out to a single customer in most cases anymore. Hope to at least introduce these customers to some contacts that may be able to help.
Do we know of any reputable sources that are leasing or selling IPv4 subnets as small as a /24 to satisfy their diversity needs? Thanks!

Sincerely,
Nick Ellermann - CTO & VP Cloud Services
BroadAspect

E: nellermann at broadaspect.com<mailto:nellermann at broadaspect.com>
P: 703-297-4639
F: 703-996-4443

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


From sgi at tango.lu  Thu Dec 17 09:28:57 2015
From: sgi at tango.lu (Mark Zimmer)
Date: Thu, 17 Dec 2015 10:28:57 +0100
Subject: ISP marking ipsec traffic based on certificate, how is this
 =?UTF-8?Q?possible=3F?=
Message-ID: <74f36cf472f9a41d2d7974cd475e2d6f@tango.lu>

 Hello list,

  I have a site-to-site ipsec vpn with strongswan. It was working well
  for 5-6 months then a day ago I have noticed something strange, that
  from Site-A to Site-B (tunnel mode) only the upload bandwidth is 
 capped
  down to 20-30kbit/s inside the VPN.
  I have tried various apps like ftp, scp on different ports it was the
  same result. I also ran speedtest/wget on both endpoints just to make
  sure that not the entire connection of those networks are capped.

  Since outside parties cannot see anything from what's going on inside
  the tunnel, first I was thinking that they started limiting the 
 traffic
  based on port (4500 udp) or based on protocol (ESP), that is easy to 
 do.

  In older versions of strongswan it's not possible to change the charon
  nat port (probably wouldn't work anyway since most of the traffic 
 should
  be ESP (protocol 50)).
  I have restarted the strongswan daemon on both endpoints multiple 
 times
  it did not change the situation (the bandwidth limiting was still 
 present).
 
  So my last idea was to make new vpn certificates. For my biggest
  surprise with the new certificates the capping was gone and the
  bandwidth went back to normal. I hope I don't have to put the old 
 certs
  back from backup just to make a point.

  One of the ISPs must started tagging the ipsec traffic based on the
  certificate and then do traffic shaping (QoS) on it to throttle down 
 the
  bandwidth. How is this even possible? I was thinking that an ipsec
  connection is encrypted and random from the beginning. How can they
  define a pattern to their whatever device to be able to mark this
  specific traffic?
  Is there a part at the beginning of the connection sequence which is
  always the same with using the same certificate?

  Do I have to worry about here that my vpn keys got compromised?

  Anybody ever experienced this?

  Thanks!

From nellermann at broadaspect.com  Fri Dec 18 03:21:15 2015
From: nellermann at broadaspect.com (Nick Ellermann)
Date: Fri, 18 Dec 2015 03:21:15 +0000
Subject: ISP marking ipsec traffic based on certificate, how is this
 possible?
In-Reply-To: <74f36cf472f9a41d2d7974cd475e2d6f@tango.lu>
References: <74f36cf472f9a41d2d7974cd475e2d6f@tango.lu>
Message-ID: <bdb668387fd940429086f03e2c55f9e1@exchange.broadaspect.local>

Sure your VPN tunnel wasn't 'stuck' flowing through a less than optimal or saturated ISP upstream transit peer? Sometimes, just restarting your VPN may force the traffic through a different path in your ISP's network and clear up an issue. We manage many customer IPsec tunnels, hit similar situations where a restart works the best especially when the issue is not in under your control.

Sincerely,
Nick Ellermann ? CTO & VP Cloud Services
BroadAspect
?
E: nellermann at broadaspect.com 
P: 703-297-4639
F: 703-996-4443
?
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Zimmer
Sent: Thursday, December 17, 2015 4:29 AM
To: nanog at nanog.org
Subject: ISP marking ipsec traffic based on certificate, how is this possible?

 Hello list,

  I have a site-to-site ipsec vpn with strongswan. It was working well
  for 5-6 months then a day ago I have noticed something strange, that
  from Site-A to Site-B (tunnel mode) only the upload bandwidth is  capped
  down to 20-30kbit/s inside the VPN.
  I have tried various apps like ftp, scp on different ports it was the
  same result. I also ran speedtest/wget on both endpoints just to make
  sure that not the entire connection of those networks are capped.

  Since outside parties cannot see anything from what's going on inside
  the tunnel, first I was thinking that they started limiting the  traffic
  based on port (4500 udp) or based on protocol (ESP), that is easy to  do.

  In older versions of strongswan it's not possible to change the charon
  nat port (probably wouldn't work anyway since most of the traffic  should
  be ESP (protocol 50)).
  I have restarted the strongswan daemon on both endpoints multiple  times
  it did not change the situation (the bandwidth limiting was still  present).
 
  So my last idea was to make new vpn certificates. For my biggest
  surprise with the new certificates the capping was gone and the
  bandwidth went back to normal. I hope I don't have to put the old  certs
  back from backup just to make a point.

  One of the ISPs must started tagging the ipsec traffic based on the
  certificate and then do traffic shaping (QoS) on it to throttle down  the
  bandwidth. How is this even possible? I was thinking that an ipsec
  connection is encrypted and random from the beginning. How can they
  define a pattern to their whatever device to be able to mark this
  specific traffic?
  Is there a part at the beginning of the connection sequence which is
  always the same with using the same certificate?

  Do I have to worry about here that my vpn keys got compromised?

  Anybody ever experienced this?

  Thanks!

From randy at psg.com  Fri Dec 18 04:40:39 2015
From: randy at psg.com (Randy Bush)
Date: Fri, 18 Dec 2015 13:40:39 +0900
Subject: Nat
In-Reply-To: <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
Message-ID: <m2wpsce5dk.wl%randy@psg.com>

>> make ipv6 easier to deploy, especially in enterprise.  repeat the
>> previous sentence 42 times.
> 
> I'm still waiting for the IETF to come around
> to allowing feature parity between IPv4 and IPv6
> when it comes to DHCP.  The stance of not
> allowing the DHCP server to assign a default
> gateway to the host in IPv6 is a big stumbling
> point for at least one large enterprise I'm aware
> of.  Right now, the biggest obstacle to IPv6
> deployment seems to be the ivory-tower types
> in the IETF that want to keep it pristine, vs
> allowing it to work in the real world.

i disagree strongly on one point.  ipv6 is about as far from pristine as
a protocol can get.  an icon of second system syndrome.  and it is
simpler than it used to be.  remember TLAs, NLAs, ...

but the dhcp st00pidity does encapsulate the arrogance and stupidity
marvelously

>> what keeps the cows in the pasture is the quality of the grass not
>> the height of the fence.
> Randy, I would happily appoint you as CIG-Q,
> the Chief Inspector of Grass Quality.    ;)

i gave all such things up over 21 years ago

randy

From jtin at akamai.com  Fri Dec 18 08:01:33 2015
From: jtin at akamai.com (Tin, James)
Date: Fri, 18 Dec 2015 08:01:33 +0000
Subject: ISP marking ipsec traffic based on certificate, how is this
 possible?
In-Reply-To: <bdb668387fd940429086f03e2c55f9e1@exchange.broadaspect.local>
References: <74f36cf472f9a41d2d7974cd475e2d6f@tango.lu>
 <bdb668387fd940429086f03e2c55f9e1@exchange.broadaspect.local>
Message-ID: <46CBE99F-B187-459C-AA6D-1B57AA6571EF@akamai.com>

If you?re using certificates, It could be possible you may have changed your VPN from IPSEC to SSLVPN. 
In which case it now runs over TCP port 443.
So maybe they?re not doing traffic shaping on TCP 443.

James



On 18/12/2015 2:21 pm, "Nick Ellermann" <nellermann at broadaspect.com> wrote:

>Sure your VPN tunnel wasn't 'stuck' flowing through a less than optimal or saturated ISP upstream transit peer? Sometimes, just restarting your VPN may force the traffic through a different path in your ISP's network and clear up an issue. We manage many customer IPsec tunnels, hit similar situations where a restart works the best especially when the issue is not in under your control.
>
>Sincerely,
>Nick Ellermann ? CTO & VP Cloud Services
>BroadAspect
> 
>E: nellermann at broadaspect.com 
>P: 703-297-4639
>F: 703-996-4443
> 
>THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Zimmer
>Sent: Thursday, December 17, 2015 4:29 AM
>To: nanog at nanog.org
>Subject: ISP marking ipsec traffic based on certificate, how is this possible?
>
> Hello list,
>
>  I have a site-to-site ipsec vpn with strongswan. It was working well
>  for 5-6 months then a day ago I have noticed something strange, that
>  from Site-A to Site-B (tunnel mode) only the upload bandwidth is  capped
>  down to 20-30kbit/s inside the VPN.
>  I have tried various apps like ftp, scp on different ports it was the
>  same result. I also ran speedtest/wget on both endpoints just to make
>  sure that not the entire connection of those networks are capped.
>
>  Since outside parties cannot see anything from what's going on inside
>  the tunnel, first I was thinking that they started limiting the  traffic
>  based on port (4500 udp) or based on protocol (ESP), that is easy to  do.
>
>  In older versions of strongswan it's not possible to change the charon
>  nat port (probably wouldn't work anyway since most of the traffic  should
>  be ESP (protocol 50)).
>  I have restarted the strongswan daemon on both endpoints multiple  times
>  it did not change the situation (the bandwidth limiting was still  present).
> 
>  So my last idea was to make new vpn certificates. For my biggest
>  surprise with the new certificates the capping was gone and the
>  bandwidth went back to normal. I hope I don't have to put the old  certs
>  back from backup just to make a point.
>
>  One of the ISPs must started tagging the ipsec traffic based on the
>  certificate and then do traffic shaping (QoS) on it to throttle down  the
>  bandwidth. How is this even possible? I was thinking that an ipsec
>  connection is encrypted and random from the beginning. How can they
>  define a pattern to their whatever device to be able to mark this
>  specific traffic?
>  Is there a part at the beginning of the connection sequence which is
>  always the same with using the same certificate?
>
>  Do I have to worry about here that my vpn keys got compromised?
>
>  Anybody ever experienced this?
>
>  Thanks!

From bortzmeyer at nic.fr  Fri Dec 18 08:28:11 2015
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 18 Dec 2015 09:28:11 +0100
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
Message-ID: <20151218082811.GA13639@nic.fr>

http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554
https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713&cat=SIRT_1&actp=LIST

Should we blame Juniper for letting a git repository open to
"unauthorized code" or should we congratulate them for their frankness
(few corporations would have admitted the problem)?

From karsten_thomann at linfre.de  Fri Dec 18 13:19:36 2015
From: karsten_thomann at linfre.de (Karsten Thomann)
Date: Fri, 18 Dec 2015 13:19:36 +0000
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <20151218082811.GA13639@nic.fr>
References: <20151218082811.GA13639@nic.fr>
Message-ID: <2790549.8LFx1ecJs8@linne>

Am Freitag, 18. Dezember 2015, 09:28:11 schrieb Stephane Bortzmeyer:
> http://forums.juniper.net/t5/Security-Incident-Response/Important-Announceme
> nt-about-ScreenOS/ba-p/285554
> 
https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713&cat=
SIRT_1
> &actp=LIST
> 
> Should we blame Juniper for letting a git repository open to
> "unauthorized code" or should we congratulate them for their frankness
> (few corporations would have admitted the problem)?

I think we should do both, even if it would be interessting to know how long 
the problem already exists.

From dave.taht at gmail.com  Fri Dec 18 12:28:02 2015
From: dave.taht at gmail.com (Dave Taht)
Date: Fri, 18 Dec 2015 13:28:02 +0100
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <2790549.8LFx1ecJs8@linne>
References: <20151218082811.GA13639@nic.fr>
	<2790549.8LFx1ecJs8@linne>
Message-ID: <CAA93jw541rK_etQa=4qsXYzCdAuw3+KFtidYdSCL-M9kXxEiMQ@mail.gmail.com>

I think "unauthorized code" is still plausible newspeak for "bug".

Why blame finger foo when you can blame terrorists?

From A.L.M.Buxey at lboro.ac.uk  Fri Dec 18 14:09:29 2015
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Fri, 18 Dec 2015 14:09:29 +0000
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <2790549.8LFx1ecJs8@linne>
References: <20151218082811.GA13639@nic.fr>
 <2790549.8LFx1ecJs8@linne>
Message-ID: <20151218140929.GB15618@lboro.ac.uk>

Hi,

> > Should we blame Juniper for letting a git repository open to
> > "unauthorized code" or should we congratulate them for their frankness
> > (few corporations would have admitted the problem)?

'un-authorized' - not authorized.

this could be code/idea by some/one engineer for eg debugging purpose etc that
just didnt get ANY signoff by anyone - so during code review they've questioned
its presence and not found the relevant sign-off etc.

take VW here...they are now blaming a small set of engineers who rigged the emissions
system....if they can say that no managers/execs knew about this and it was purely in
some small code team etc then that too is unauthorized code - but its internal,
not an external bad guy (it will be interesting however, in that case, whether that really
was the case and it WASNT known about by someone else...thus 'authorized' in that it wasnt
stopped)

alan

From ahmed.dalaali at hrins.net  Fri Dec 18 16:30:35 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Fri, 18 Dec 2015 19:30:35 +0300
Subject: Nat
In-Reply-To: <5672F537.60707@foobar.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
 <002601d1383a$81640750$842c15f0$@wicks.co.nz>
 <4F040284-0811-4291-BA58-C7178DCBCF52@hrins.net> <5672F537.60707@foobar.org>
Message-ID: <5CF2C77A-EB19-4F7D-B213-3DFDC944E19E@hrins.net>



> On Dec 17, 2015, at 8:47 PM, Nick Hilliard <nick at foobar.org> wrote:
> 
> On 17/12/2015 17:36, Ahmed Munaf wrote:
>> we are using ESP 20 
> 
> You haven't said what you mean by "better".  This could mean "faster" or
> "copes with more sessions" or "cheaper".  If your ISP is large, then it
> might be "cost per user is lower" or "able to cope with the number of users".
> 
> Nick
> 
> 

I mean by better, it handle more sessions and cheaper 

From ahmed.dalaali at hrins.net  Fri Dec 18 16:37:28 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Fri, 18 Dec 2015 19:37:28 +0300
Subject: Nat
In-Reply-To: <E48CBD02-54E8-46D9-B08D-36CDD3F01DE7@netideainc.ca>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net> <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net> <567196B8.9020508@seacom.mu>
 <186B1104-F30A-4EF6-A321-C17717204805@hrins.net>
 <E48CBD02-54E8-46D9-B08D-36CDD3F01DE7@netideainc.ca>
Message-ID: <19D1D235-05B5-4365-A603-5FAC897C42AB@hrins.net>

Thanks, we are speaking with few vendors and A10 one of them. they offer the model Thunder 3030S, the price was good in comparison  with the specifications  of this model. 

its good to know that it works good at your university. 


> On Dec 17, 2015, at 9:34 PM, Netideainc <eriks at netideainc.ca> wrote:
> 
> At $dayjob$ (which is a university) we spoke to several vendors and eventually gave A10 Networks Thunder 3030 a test drive.
> 
> It satisfied our requirements and fit our budget.   Most of our NAT traffic originates from our undergraduate student population.  Peak workload during 2015 fall term was about 27k concurrently active devices, 4.6Gbps, 415kpps.
> 
> The ASR1000 would have been our other choice but the ASR's higher price pushed us toward A10.
> 
> Eriks
> ---
> Eriks Rugelis
> Sr. Consultant
> Netidea Inc.
> T: +1.416.876.0740
> 
>> On Dec 17, 2015, at 12:30, Ahmed Munaf <ahmed.dalaali at hrins.net> wrote:
>> 
>> 
>> 
>> 
>> 
>>> On Dec 16, 2015, at 7:52 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>>> 
>>> 
>>> 
>>>> On 16/Dec/15 18:36, Ahmed Munaf wrote:
>>>> 
>>>> In addition to the limited concurrent sessions for ASR1000, we are
>>>> facing some issue with many users how are playing online games! Nat
>>>> problems!
>>> 
>>> This could be a function of the size of your ESP.
>>> 
>>> The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP
>>> will do 4,000,000 NAT sessions with a per-second setup rate of 300,000
>>> sessions.
>>> 
>>> Of course, it makes little sense to upgrade if you run out of sessions
>>> before you hit the NAT throughput ceiling, so other vendors may be more
>>> commercially palatable.
>>> 
>>> Mark.
>> 
>> Thats right but as you mentioned that its commercially palatable, however I don?t know if the other vendors are the same performance as ASR1000!  this was my question if someone recommend another vendor. 
>> 
>> 


From smb at cs.columbia.edu  Fri Dec 18 16:52:42 2015
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Fri, 18 Dec 2015 11:52:42 -0500
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <CAA93jw541rK_etQa=4qsXYzCdAuw3+KFtidYdSCL-M9kXxEiMQ@mail.gmail.com>
References: <20151218082811.GA13639@nic.fr> <2790549.8LFx1ecJs8@linne>
 <CAA93jw541rK_etQa=4qsXYzCdAuw3+KFtidYdSCL-M9kXxEiMQ@mail.gmail.com>
Message-ID: <8F6A8780-2166-457D-A80A-B385E5E46637@cs.columbia.edu>



On 18 Dec 2015, at 7:28, Dave Taht wrote:

> I think "unauthorized code" is still plausible newspeak for "bug".
>
> Why blame finger foo when you can blame terrorists?

It looks like two different holes, one a back door for unauthorized
console login and one to somehow leak VPN encryption keys.  There are
hints that that latter involved tinkering with certain constants in
the crypto (https://twitter.com/matthew_d_green/status/677871004354371584);
that would squarely point the finger at some government's intelligence
agency.

I don't know who did it, but neither 'bug' nor 'developer debugging
code' sounds plausible here.


From smb at cs.columbia.edu  Fri Dec 18 17:03:40 2015
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Fri, 18 Dec 2015 12:03:40 -0500
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <8F6A8780-2166-457D-A80A-B385E5E46637@cs.columbia.edu>
References: <20151218082811.GA13639@nic.fr> <2790549.8LFx1ecJs8@linne>
 <CAA93jw541rK_etQa=4qsXYzCdAuw3+KFtidYdSCL-M9kXxEiMQ@mail.gmail.com>
 <8F6A8780-2166-457D-A80A-B385E5E46637@cs.columbia.edu>
Message-ID: <E70008E7-E6EA-48AD-B16C-99137D25A572@cs.columbia.edu>



On 18 Dec 2015, at 11:52, Steven M. Bellovin wrote:

> On 18 Dec 2015, at 7:28, Dave Taht wrote:
>
>> I think "unauthorized code" is still plausible newspeak for "bug".
>>
>> Why blame finger foo when you can blame terrorists?
>
> It looks like two different holes, one a back door for unauthorized
> console login and one to somehow leak VPN encryption keys.  There are
> hints that that latter involved tinkering with certain constants in
> the crypto (https://twitter.com/matthew_d_green/status/677871004354371584);
> that would squarely point the finger at some government's intelligence
> agency.
>
> I don't know who did it, but neither 'bug' nor 'developer debugging
> code' sounds plausible here.

https://twitter.com/sweis/status/677896363070259200


From royce at techsolvency.com  Fri Dec 18 17:27:02 2015
From: royce at techsolvency.com (Royce Williams)
Date: Fri, 18 Dec 2015 08:27:02 -0900
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <E70008E7-E6EA-48AD-B16C-99137D25A572@cs.columbia.edu>
References: <20151218082811.GA13639@nic.fr> <2790549.8LFx1ecJs8@linne>
 <CAA93jw541rK_etQa=4qsXYzCdAuw3+KFtidYdSCL-M9kXxEiMQ@mail.gmail.com>
 <8F6A8780-2166-457D-A80A-B385E5E46637@cs.columbia.edu>
 <E70008E7-E6EA-48AD-B16C-99137D25A572@cs.columbia.edu>
Message-ID: <CA+E3k93LiE0cy=AKSsKf+wWvgEUFn0fNuYZwfs-GVStw6hiZkg@mail.gmail.com>

On Fri, Dec 18, 2015 at 8:03 AM, Steven M. Bellovin <smb at cs.columbia.edu> wrote:
> On 18 Dec 2015, at 11:52, Steven M. Bellovin wrote:
>
>> On 18 Dec 2015, at 7:28, Dave Taht wrote:
>>
>>> I think "unauthorized code" is still plausible newspeak for "bug".
>>>
>>> Why blame finger foo when you can blame terrorists?
>>
>> It looks like two different holes, one a back door for unauthorized
>> console login and one to somehow leak VPN encryption keys.  There are
>> hints that that latter involved tinkering with certain constants in
>> the crypto (https://twitter.com/matthew_d_green/status/677871004354371584);
>> that would squarely point the finger at some government's intelligence
>> agency.
>>
>> I don't know who did it, but neither 'bug' nor 'developer debugging
>> code' sounds plausible here.
>
> https://twitter.com/sweis/status/677896363070259200

That tweet got deleted, apparently to redraft/correct; is this the equivalent?

https://twitter.com/sweis/status/677897914643976193
https://gist.github.com/hdm/107614ea292e856faa81#file-ssg500-6-3-0r12-0-diff-L16

Royce

From smb at cs.columbia.edu  Fri Dec 18 17:32:50 2015
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Fri, 18 Dec 2015 12:32:50 -0500
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <CA+E3k93LiE0cy=AKSsKf+wWvgEUFn0fNuYZwfs-GVStw6hiZkg@mail.gmail.com>
References: <20151218082811.GA13639@nic.fr> <2790549.8LFx1ecJs8@linne>
 <CAA93jw541rK_etQa=4qsXYzCdAuw3+KFtidYdSCL-M9kXxEiMQ@mail.gmail.com>
 <8F6A8780-2166-457D-A80A-B385E5E46637@cs.columbia.edu>
 <E70008E7-E6EA-48AD-B16C-99137D25A572@cs.columbia.edu>
 <CA+E3k93LiE0cy=AKSsKf+wWvgEUFn0fNuYZwfs-GVStw6hiZkg@mail.gmail.com>
Message-ID: <C974E22A-D4C3-4E18-B29E-FBB65C29263D@cs.columbia.edu>

Yes. He's backing off a bit on the claim, since he doesn't have full context. 

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

Sent from from a handheld; please excuse tyops

> On Dec 18, 2015, at 12:27 PM, Royce Williams <royce at techsolvency.com> wrote:
> 
>> On Fri, Dec 18, 2015 at 8:03 AM, Steven M. Bellovin <smb at cs.columbia.edu> wrote:
>>> On 18 Dec 2015, at 11:52, Steven M. Bellovin wrote:
>>> 
>>>> On 18 Dec 2015, at 7:28, Dave Taht wrote:
>>>> 
>>>> I think "unauthorized code" is still plausible newspeak for "bug".
>>>> 
>>>> Why blame finger foo when you can blame terrorists?
>>> 
>>> It looks like two different holes, one a back door for unauthorized
>>> console login and one to somehow leak VPN encryption keys.  There are
>>> hints that that latter involved tinkering with certain constants in
>>> the crypto (https://twitter.com/matthew_d_green/status/677871004354371584);
>>> that would squarely point the finger at some government's intelligence
>>> agency.
>>> 
>>> I don't know who did it, but neither 'bug' nor 'developer debugging
>>> code' sounds plausible here.
>> 
>> https://twitter.com/sweis/status/677896363070259200
> 
> That tweet got deleted, apparently to redraft/correct; is this the equivalent?
> 
> https://twitter.com/sweis/status/677897914643976193
> https://gist.github.com/hdm/107614ea292e856faa81#file-ssg500-6-3-0r12-0-diff-L16
> 
> Royce


From cscora at apnic.net  Fri Dec 18 18:10:59 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 19 Dec 2015 04:10:59 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201512181810.tBIIAxxG008335@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 19 Dec, 2015

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

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

BGP routing table entries examined:                              575038
    Prefixes after maximum aggregation (per Origin AS):          212671
    Deaggregation factor:                                          2.70
    Unique aggregates announced (without unneeded subnets):      279789
Total ASes present in the Internet Routing Table:                 52332
    Prefixes per ASN:                                             10.99
Origin-only ASes present in the Internet Routing Table:           36643
Origin ASes announcing only one prefix:                           15899
Transit ASes present in the Internet Routing Table:                6389
Transit-only ASes present in the Internet Routing Table:            168
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      37
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:              1022
    Unregistered ASNs in the Routing Table:                         366
Number of 32-bit ASNs allocated by the RIRs:                      12134
Number of 32-bit ASNs visible in the Routing Table:                9300
Prefixes from 32-bit ASNs in the Routing Table:                   35469
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:            410
Number of addresses announced to Internet:                   2802619584
    Equivalent to 167 /8s, 12 /16s and 148 /24s
    Percentage of available address space announced:               75.7
    Percentage of allocated address space announced:               75.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.8
Total number of prefixes smaller than registry allocations:      189105

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

Prefixes being announced by APNIC Region ASes:                   145893
    Total APNIC prefixes after maximum aggregation:               39962
    APNIC Deaggregation factor:                                    3.65
Prefixes being announced from the APNIC address blocks:          154461
    Unique aggregates announced from the APNIC address blocks:    61426
APNIC Region origin ASes present in the Internet Routing Table:    5124
    APNIC Prefixes per ASN:                                       30.14
APNIC Region origin ASes announcing only one prefix:               1200
APNIC Region transit ASes present in the Internet Routing Table:    892
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1759
Number of APNIC addresses announced to Internet:              756146560
    Equivalent to 45 /8s, 17 /16s and 225 /24s
    Percentage of available APNIC address space announced:         88.4

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:                    181146
    Total ARIN prefixes after maximum aggregation:                89006
    ARIN Deaggregation factor:                                     2.04
Prefixes being announced from the ARIN address blocks:           184534
    Unique aggregates announced from the ARIN address blocks:     86477
ARIN Region origin ASes present in the Internet Routing Table:    16478
    ARIN Prefixes per ASN:                                        11.20
ARIN Region origin ASes announcing only one prefix:                5936
ARIN Region transit ASes present in the Internet Routing Table:    1723
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:     895
Number of ARIN addresses announced to Internet:              1102004160
    Equivalent to 65 /8s, 175 /16s and 63 /24s
    Percentage of available ARIN address space announced:          58.3

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, 64198-64296, 393216-395164
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:                    138479
    Total RIPE prefixes after maximum aggregation:                68745
    RIPE Deaggregation factor:                                     2.01
Prefixes being announced from the RIPE address blocks:           146403
    Unique aggregates announced from the RIPE address blocks:     90629
RIPE Region origin ASes present in the Internet Routing Table:    18038
    RIPE Prefixes per ASN:                                         8.12
RIPE Region origin ASes announcing only one prefix:                7978
RIPE Region transit ASes present in the Internet Routing Table:    2990
Average RIPE Region AS path length visible:                         4.8
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4316
Number of RIPE addresses announced to Internet:               702141824
    Equivalent to 41 /8s, 217 /16s and 213 /24s
    Percentage of available RIPE address space announced:         102.1

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
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:                   60498
    Total LACNIC prefixes after maximum aggregation:              11803
    LACNIC Deaggregation factor:                                   5.13
Prefixes being announced from the LACNIC address blocks:          73413
    Unique aggregates announced from the LACNIC address blocks:   34606
LACNIC Region origin ASes present in the Internet Routing Table:   2461
    LACNIC Prefixes per ASN:                                      29.83
LACNIC Region origin ASes announcing only one prefix:               594
LACNIC Region transit ASes present in the Internet Routing Table:   537
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        23
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2153
Number of LACNIC addresses announced to Internet:             170625024
    Equivalent to 10 /8s, 43 /16s and 136 /24s
    Percentage of available LACNIC address space announced:       101.7

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:                  13470
    Total AfriNIC prefixes after maximum aggregation:              3113
    AfriNIC Deaggregation factor:                                  4.33
Prefixes being announced from the AfriNIC address blocks:         15817
    Unique aggregates announced from the AfriNIC address blocks:   6300
AfriNIC Region origin ASes present in the Internet Routing Table:   736
    AfriNIC Prefixes per ASN:                                     21.49
AfriNIC Region origin ASes announcing only one prefix:              191
AfriNIC Region transit ASes present in the Internet Routing Table:  168
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       19
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  177
Number of AfriNIC addresses announced to Internet:             71324160
    Equivalent to 4 /8s, 64 /16s and 82 /24s
    Percentage of available AfriNIC address space announced:       70.9

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
 4538     5599       4192          76   China Education and Research 
 7545     3059        346         157   TPG Telecom Limited
 4766     3016      11136         999   Korea Telecom
17974     2758        914          96   PT Telekomunikasi Indonesia
 9829     2201       1413         372   National Internet Backbone
 4755     2067        431         232   TATA Communications formerly 
 9808     1687       8639          18   Guangdong Mobile Communicatio
 4808     1590       2275         504   CNCGROUP IP network China169 
 9583     1507        163          80   Sify Limited
38197     1412         88         186   Sun Network (Hong Kong) Limit

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     3270       2964         145   Cox Communications Inc.
 3356     2600      10693         537   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
18566     2212        394         277   MegaPath Corporation
20115     1897       1902         403   Charter Communications
 6983     1698        849         238   EarthLink, Inc.
30036     1666        332         334   Mediacom Communications Corp
 4323     1577       1021         393   tw telecom holdings, inc.
  209     1463       4338        1227   Qwest Communications Company,
  701     1373      11441         646   MCI Communications Services, 

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
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2261        892        1617   Akamai International B.V.
34984     1910        318         426   TELLCOM ILETISIM HIZMETLERI A
 8551     1437        376          44   Bezeq International-Ltd
 8402     1082        544          15   OJSC "Vimpelcom"
13188     1075         97          79   TOV "Bank-Inform"
12479     1062        965          80   France Telecom Espana SA
31148     1042         47          41   Freenet Ltd.
 9198      950        349          25   JSC Kazakhtelecom
 6830      898       2712         468   Liberty Global Operations B.V

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3419        543         113   Telmex Colombia S.A.
 8151     2122       3364         491   Uninet S.A. de C.V.
 7303     1581        942         241   Telecom Argentina S.A.
 6503     1388        453          58   Axtel, S.A.B. de C.V.
28573     1213       2174         131   NET Servi?os de Comunica??o S
11830     1094        366          25   Instituto Costarricense de El
 6147     1039        376          34   Telefonica del Peru S.A.A.
 7738      994       1882          41   Telemar Norte Leste S.A.
 3816      974        459         185   COLOMBIA TELECOMUNICACIONES S
26615      948       2325          34   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
 8452     1184       1470          14   TE-AS
24863     1135        405          37   Link Egypt (Link.NET)
37611      583         39          40   Afrihost-Brevis Computer Serv
36903      552        278         110   Office National des Postes et
36992      434       1233          33   ETISALAT MISR
37492      325        192          74   Orange Tunisie
29571      264         21          11   Cote d'Ivoire Telecom
24835      245        146          12   Vodafone Data
 3741      221        837         183   Internet Solutions
15706      171         32           6   Sudatel (Sudan Telecom Co. Lt

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
 4538     5599       4192          76   China Education and Research 
10620     3419        543         113   Telmex Colombia S.A.
22773     3270       2964         145   Cox Communications Inc.
 7545     3059        346         157   TPG Telecom Limited
 4766     3016      11136         999   Korea Telecom
17974     2758        914          96   PT Telekomunikasi Indonesia
 3356     2600      10693         537   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2261        892        1617   Akamai International B.V.

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

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

  ASN   No of nets  Net Savings Description
10620      3419        3306      Telmex Colombia S.A.
22773      3270        3125      Cox Communications Inc.
 7545      3059        2902      TPG Telecom Limited
17974      2758        2662      PT Telekomunikasi Indonesia
 6389      2508        2466      BellSouth.net Inc.
39891      2473        2466      SaudiNet, Saudi Telecom Compa
 3356      2600        2063      Level 3 Communications, Inc.
 4766      3016        2017      Korea Telecom
18566      2212        1935      MegaPath Corporation
 4755      2067        1835      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         3356       Level 3 Communicatio
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
18985   UNALLOCATED  8.21.68.0/22          3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint
32805   UNALLOCATED  12.1.225.0/24         7018       AT&T Services, Inc.

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

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

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
31.170.96.0/23       23456     32bit Transition AS
37.46.8.0/23         13768     Peer 1 Network (USA) Inc.
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.
37.46.15.0/24        36351     SoftLayer Technologies Inc.

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:13      /10:36      /11:100     /12:265     
/13:506     /14:1016    /15:1773    /16:12988   /17:7408    /18:12610   
/19:25580   /20:37740   /21:39987   /22:63460   /23:54945   /24:315024  
/25:546     /26:578     /27:384     /28:17      /29:16      /30:9       
/31:0       /32:21      

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

  ASN   No of nets  Total ann.   Description
22773     2458          3270      Cox Communications Inc.
39891     2432          2473      SaudiNet, Saudi Telecom Compa
18566     2114          2212      MegaPath Corporation
 6389     1553          2508      BellSouth.net Inc.
30036     1483          1666      Mediacom Communications Corp
 6983     1345          1698      EarthLink, Inc.
10620     1289          3419      Telmex Colombia S.A.
34984     1205          1910      TELLCOM ILETISIM HIZMETLERI A
11492     1132          1222      CABLE ONE, INC.
31148      961          1042      Freenet Ltd.

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

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

   1:1643      2:653       4:100       5:2068      6:26        8:1412   
  12:1801     13:30       14:1588     15:23       16:2        17:57     
  18:19       20:48       22:1        23:1320     24:1730     27:2132   
  31:1703     32:54       33:2        34:4        35:5        36:192    
  37:2211     38:1137     39:22       40:76       41:3005     42:368    
  43:1623     44:36       45:1567     46:2353     47:64       49:1069   
  50:825      51:3        52:35       54:96       55:8        56:8      
  57:44       58:1430     59:840      60:519      61:1760     62:1461   
  63:1909     64:4436     65:2186     66:4071     67:2136     68:1090   
  69:3270     70:1043     71:461      72:1976     74:2557     75:358    
  76:416      77:1378     78:1280     79:820      80:1324     81:1361   
  82:848      83:669      84:779      85:1532     86:456      87:1048   
  88:548      89:1930     90:153      91:5964     92:861      93:2307   
  94:2238     95:2242     96:472      97:353      98:957      99:45     
 100:79      101:872     103:9167    104:2171    105:88      106:361    
 107:1108    108:638     109:2369    110:1239    111:1542    112:878    
 113:1188    114:916     115:1534    116:1515    117:1351    118:2009   
 119:1491    120:513     121:1163    122:2254    123:1872    124:1570   
 125:1739    128:674     129:353     130:422     131:1281    132:592    
 133:169     134:452     135:121     136:348     137:310     138:1586   
 139:197     140:249     141:465     142:637     143:737     144:578    
 145:150     146:827     147:609     148:1306    149:450     150:622    
 151:809     152:570     153:269     154:477     155:904     156:443    
 157:404     158:347     159:1065    160:421     161:690     162:2213   
 163:501     164:712     165:1100    166:315     167:913     168:1339   
 169:560     170:1484    171:267     172:373     173:1572    174:716    
 175:766     176:1497    177:3961    178:2277    179:1049    180:2051   
 181:1629    182:1911    183:649     184:763     185:5177    186:3051   
 187:1879    188:2125    189:1710    190:7543    191:1262    192:8738   
 193:5734    194:4308    195:3730    196:2250    197:1113    198:5503   
 199:5518    200:6707    201:3489    202:9869    203:9299    204:4557   
 205:2730    206:2966    207:3018    208:4017    209:3973    210:3766   
 211:2018    212:2616    213:2199    214:831     215:73      216:5721   
 217:1871    218:741     219:543     220:1640    221:798     222:641    
 223:874    

End of report

From bzs at theworld.com  Fri Dec 18 18:44:36 2015
From: bzs at theworld.com (bzs at theworld.com)
Date: Fri, 18 Dec 2015 13:44:36 -0500
Subject: failover via comcast tunnel?
In-Reply-To: <5C433AA7-1A9E-4D65-B403-48E57493707D@indigowireless.com>
References: <22131.8886.119084.674737@pcls8.std.com>
 <5C433AA7-1A9E-4D65-B403-48E57493707D@indigowireless.com>
Message-ID: <22132.21524.419955.747434@pcls8.std.com>


FWIW we do expect to pay for this service, by "cheap" I just meant,
well, cheap, but not free. It's all relative I suppose.

But thanks for the response thus far!

On December 17, 2015 at 16:15 mhoppes at indigowireless.com (Matt Hoppes) wrote:
 > You could tunnel to a data center. 
 > 
 > Or NAT out their service. 
 > 
 > Tunneling via EoIP would allow you to stay within their ToS. 
 > 
 > > On Dec 17, 2015, at 16:01, bzs at theworld.com wrote:
 > > 
 > > 
 > > I'm looking at some sort of 50-100mbps failover link in case my
 > > primary is down.
 > > 
 > > My options seem limited particularly since I'm cheap.
 > > 
 > > I see Comcast has unlimited data business links in this range but I'm
 > > not sure I'd want to deal with the management issue of BGP or swapping
 > > ip blocks etc with them in an emergency. I just tried calling their
 > > business sales line and after the initial "Thank you for calling
 > > Comcast Business Services etc" it dropped me...three times. Yeah, that
 > > builds confidence.
 > > 
 > > So I'm thinking something more like using their service as a raw
 > > bandwidth pipe and tunneling to an actual route provider?
 > > 
 > > Crazy? Anyone done anything like this? Are there tools for that?
 > > Other, similar suggestions?
 > > 
 > > Feel free contact me off-list.
 > > 
 > > -- 
 > >        -Barry Shein
 > > 
 > > Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
 > > Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
 > > The World              | Public Access Internet     | Since 1989     *oo*

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

From Lee at asgard.org  Fri Dec 18 21:07:26 2015
From: Lee at asgard.org (Lee Howard)
Date: Fri, 18 Dec 2015 16:07:26 -0500
Subject: IPv4 subnets for lease?
In-Reply-To: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
References: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
Message-ID: <D299DE5B.D1556%Lee@asgard.org>

Leasing is ill-advised; the addresses will be unsellable once the spammers
are through with them.
Really, there?s no other reason to lease.

If you want to buy or sell addresses in the ARIN region, some of the
facilitators at 
https://www.arin.net/resources/transfer_listing/facilitator_list.html are
pretty good (ask me; I?ll let you know my opinions privately).

The only ones I know who will deal in blocks as small as /24 are
http://www.ipv4auctions.com/
There may be others I don?t know about.

Of course you have to ask whether IPv6 is a possible alternative, and you
shouldn?t go to all the troule and expense of buying addresses without
turning up dual-stack. That would be like spending $20 for a tissue when
you need a $10 cold medicine; it helps, but not for long.

Lee


On 12/17/15, 9:31 PM, "NANOG on behalf of Nick Ellermann"
<nanog-bounces at nanog.org on behalf of nellermann at broadaspect.com> wrote:

>We have customers asking to lease IP space for BGP transit with us and
>other peers. But they are struggling to get at a minimum even a Class C,
>even though they have their own ASN. We don't have large amounts of free
>IPv4 space to lease out to a single customer in most cases anymore. Hope
>to at least introduce these customers to some contacts that may be able
>to help.
>Do we know of any reputable sources that are leasing or selling IPv4
>subnets as small as a /24 to satisfy their diversity needs? Thanks!
>
>Sincerely,
>Nick Ellermann - CTO & VP Cloud Services
>BroadAspect
>
>E: nellermann at broadaspect.com<mailto:nellermann at broadaspect.com>
>P: 703-297-4639
>F: 703-996-4443
>
>THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>MATERIAL and is thus for use only by the intended recipient. If you
>received this in error, please contact the sender and delete the e-mail
>and its attachments from all computers.
>
>



From Lee at asgard.org  Fri Dec 18 21:18:51 2015
From: Lee at asgard.org (Lee Howard)
Date: Fri, 18 Dec 2015 16:18:51 -0500
Subject: Nat
In-Reply-To: <01de01d13900$fe364dd0$faa2e970$@gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
Message-ID: <D299E117.D157A%Lee@asgard.org>



On 12/17/15, 2:27 PM, "NANOG on behalf of Chuck Church"
<nanog-bounces at nanog.org on behalf of chuckchurch at gmail.com> wrote:

>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Petach
>Sent: Thursday, December 17, 2015 1:59 PM
>Cc: North American Network Operators' Group <nanog at nanog.org>
>Subject: Re: Nat
>
>>I'm still waiting for the IETF to come around to allowing feature parity
>>between IPv4 and IPv6 when it comes to DHCP.
>
>And that recent thread on prefix delegation doesn't really leave a good
>taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and
>get that/those prefix(s) in your (ISP) routing tables.  Given that
>99.999% of home users would be fine with a delegation of a single /64 and
>a single subnet I'm tempted to do that for now and let the DHCP-PD ink
>dry for a while so CPE support can follow up.

Which thread on which list?  DHCP-PD works to any home gateway that
supports IPv6. I know how the routing is set up in cable, don?t know about
other access.
Or did you mean a prefix for a mobile device? Ongoing discussion in IETF
v6ops, with consensus that multiple addresses are needed.

There?s disagreement among ISPs about what size prefix to delegate. So
what? Pick a number and do it. I don?t know of anybody who thinks a /64 is
right for the home user, but I know of clueful people running every nibble
between /60 and /48. Pick a number, plan so you can change it later, and
deploy.

Lee

>
>Chuck
>
>



From Lee at asgard.org  Fri Dec 18 21:20:48 2015
From: Lee at asgard.org (Lee Howard)
Date: Fri, 18 Dec 2015 16:20:48 -0500
Subject: Nat
In-Reply-To: <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
Message-ID: <D299E276.D1593%Lee@asgard.org>



On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
<nanog-bounces at nanog.org on behalf of mpetach at netflight.com> wrote:

>On Wed, Dec 16, 2015 at 5:22 PM, Randy Bush <randy at psg.com> wrote:
>>> We need to put some pain onto everyone that is IPv4 only.
>>
>> this is the oppress the workers so they will revolt theory.
>
>Ah, yes, the workers are quite revolting!
>
>> load of crap.
>>
>> make ipv6 easier to deploy, especially in enterprise.  repeat the
>> previous sentence 42 times.
>
>
>I'm still waiting for the IETF to come around
>to allowing feature parity between IPv4 and IPv6
>when it comes to DHCP.  The stance of not
>allowing the DHCP server to assign a default
>gateway to the host in IPv6 is a big stumbling
>point for at least one large enterprise I'm aware
>of. 


Tell me again why you want this, and not routing information from the
router?


> Right now, the biggest obstacle to IPv6
>deployment seems to be the ivory-tower types
>in the IETF that want to keep it pristine, vs
>allowing it to work in the real world.

There?s a mix of people at IETF, but more operator input there would be
helpful. I have a particular draft in mind that is stuck between ?we?d
rather delay IPv6 than do it wrong? and ?be realistic about how people
will deploy it."

Lee



From Lee at asgard.org  Fri Dec 18 21:21:28 2015
From: Lee at asgard.org (Lee Howard)
Date: Fri, 18 Dec 2015 16:21:28 -0500
Subject: Nat
In-Reply-To: <20151217023407.AE7DE2C060C@mail.nanog.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <20151217023407.AE7DE2C060C@mail.nanog.org>
Message-ID: <D299E2EE.D159B%Lee@asgard.org>



On 12/16/15, 8:53 PM, "NANOG on behalf of Berry Mobley"
<nanog-bounces at nanog.org on behalf of berry at gadsdenst.org> wrote:

>At 08:22 PM 12/16/2015, Randy Bush wrote:
>> > We need to put some pain onto everyone that is IPv4 only.
>>
>>this is the oppress the workers so they will revolt theory.  load of
>>crap.
>>
>>make ipv6 easier to deploy, especially in enterprise.  repeat the
>>previous sentence 42 times.
>
>This. I'm in an enterprise with some stubborn vendors, and none of
>them are even talking about ipv6. It won't help me to move (and it
>won't help you to get well if you're here) if my users can't get to
>their stuff.


Can you dual-stack while you wait for them?
Can we help you push on those vendors?

Lee

>
>Berry 
>
>



From Lee at asgard.org  Fri Dec 18 21:35:24 2015
From: Lee at asgard.org (Lee Howard)
Date: Fri, 18 Dec 2015 16:35:24 -0500
Subject: Nat
In-Reply-To: <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
Message-ID: <D299E31B.D159F%Lee@asgard.org>



On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman"
<nanog-bounces at nanog.org on behalf of mel at beckman.org> wrote:

>Mark,
>
>Why? Why do WE "need" to force people to bend to our will? The market
>will get us all there eventually.

Some companies will run out of IPv4 addresses before others. When that
happens, they have four choices:

1. Buy IPv4 addresses. But supply is going; in a couple of years, there
will be nothing larger than a /16. And this raises costs, and therefore
consumer prices.
2. Address sharing. Breaks p2p, some other things.
3. Address family translation. Breaks several things.
4. IPv6-only. Means only IPv6-enabled content is available.

That?s why some values of $we ?need? to force people to deploy IPv6: so
$we don?t screw consumers and break the Internet.

But those with IPv4 addresses see exhaustion as someone else?s problem.
They don?t care if somebody else?s prices go up, unless they?re the ones
blamed for the rising prices. (?You have to pay more for Internet access
or you won?t be able to reach Amazon or eBay.?)
They might not like the performance of address sharing/translation, but if
they wait until they notice the pain, and it takes them two years to
respond, they?re already in serious trouble.

There is still time for companies without IPv6 to get it deployed before
going out of business. But anyone who isn?t done two years from now is in
trouble.

Lee




From owen at delong.com  Fri Dec 18 21:55:00 2015
From: owen at delong.com (Owen DeLong)
Date: Fri, 18 Dec 2015 13:55:00 -0800
Subject: Nat
In-Reply-To: <D299E31B.D159F%Lee@asgard.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
 <D299E31B.D159F%Lee@asgard.org>
Message-ID: <98CD2849-845B-46E4-9C5F-E17641B2D54B@delong.com>


> On Dec 18, 2015, at 13:35 , Lee Howard <Lee at asgard.org> wrote:
> 
> 
> 
> On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman"
> <nanog-bounces at nanog.org on behalf of mel at beckman.org> wrote:
> 
>> Mark,
>> 
>> Why? Why do WE "need" to force people to bend to our will? The market
>> will get us all there eventually.

Not all problems are well solved by markets, contrary to popular dogma.

In this case, those with the least ability to affect the outcome overall are the ones with
the greatest need for IPv6. Large incumbent organizations that have lots of IPv4 addresses
already have very little tangible market incentive to move, yet until they move, it?s very difficult
for smaller players to operate without IPv4 even though it?s now very hard for them to get
IPv4 addresses.

As such, it?s incumbent on each and every one of us to try and resolve this globally so as
to reduce the lasting impacts of our dependence on IPv4 globally.

Owen



From marka at isc.org  Fri Dec 18 22:13:24 2015
From: marka at isc.org (Mark Andrews)
Date: Sat, 19 Dec 2015 09:13:24 +1100
Subject: Nat
In-Reply-To: Your message of "Fri, 18 Dec 2015 16:35:24 -0500."
 <D299E31B.D159F%Lee@asgard.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <798937A2-415F-4316-BC48-D8C07769CB64@beckman.org>
 <D299E31B.D159F%Lee@asgard.org>
Message-ID: <20151218221324.4858A3F6CBB8@rock.dv.isc.org>


In message <D299E31B.D159F%Lee at asgard.org>, Lee Howard writes:
> 
> 
> On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman"
> <nanog-bounces at nanog.org on behalf of mel at beckman.org> wrote:
> 
> >Mark,
> >
> >Why? Why do WE "need" to force people to bend to our will? The market
> >will get us all there eventually.
> 
> Some companies will run out of IPv4 addresses before others. When that
> happens, they have four choices:
> 
> 1. Buy IPv4 addresses. But supply is going; in a couple of years, there
> will be nothing larger than a /16. And this raises costs, and therefore
> consumer prices.
> 2. Address sharing. Breaks p2p, some other things.
> 3. Address family translation. Breaks several things.
> 4. IPv6-only. Means only IPv6-enabled content is available.

Additionally just because you have enough IPv4 addresses it doesn't
mean that the other end has a IPv4 address that is not shared with
multiple customers.  You can't connect to them.

The ISP industry has totally !@#$$!@$ over the customers for too
long.  It should have made available IPv6 to everyone before the
first RIR ran out of addresses. Everyone of you that has not delivered
IPv6 to your customers already should be ashamed to call yourself
a ISP because you definitely have stopped delivering the Internet
to your customers (you only deliver half the Internet), you have
not Provided the Service that they need to be able to connect to
everyone out there in the world.  When your customers purchase a
Internet connection they *expect* to be able to reach *everyone*
not just those that have a IPv4 address to themselves because they
don't care about IPv4 vs IPv6.  They just want to be able to reach
everyone that is on the Internet and it is your *job* to deliver
that.  Thats what you get *paid* to do.  Not doing that is *fraud*.

It's time governments started issuing large fines for false advertising
for failure to make available IPv6 to your customers.


> That's why some values of $we "need" to force people to deploy IPv6: so
> $we don't screw consumers and break the Internet.
> 
> But those with IPv4 addresses see exhaustion as someone else's problem.
> They don't care if somebody else's prices go up, unless they're the ones
> blamed for the rising prices. ("You have to pay more for Internet access
> or you won't be able to reach Amazon or eBay.")
> They might not like the performance of address sharing/translation, but if
> they wait until they notice the pain, and it takes them two years to
> respond, they're already in serious trouble.
>
> There is still time for companies without IPv6 to get it deployed before
> going out of business. But anyone who isn't done two years from now is in
> trouble.
>
> Lee

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

From bob at FiberInternetCenter.com  Fri Dec 18 22:30:51 2015
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Fri, 18 Dec 2015 14:30:51 -0800
Subject: IPv4 subnets for lease?
In-Reply-To: <D299DE5B.D1556%Lee@asgard.org>
References: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
 <D299DE5B.D1556%Lee@asgard.org>
Message-ID: <c7d9579fc766e86745b8a73f80181585.squirrel@66.201.44.180>

I see it different than Lee ... because, there are no new ipv4 addresses
they are all used. I have seen the same spam issue with IP space that is
sold. So be careful.

I have been involved in both leasing and purchasing IPv4 space. Like
everything else you want to check the mileage/usage and look for dents
before leasing or buying.

 No matter which method - verify you are getting  clean addresses before
spending a dime.

Purchasing can be a large upfront investment - leasing is a good option
for many.  We all know someday the space won't be needed. It's just a
matter of when. My advise if you have cash and time buy IPv4 space.  If
not lease and focus on spending the cash on newer gear that can handle all
the /24s and IPv6 prefixes.

If leasing, make sure you are dealing with a source that watches carefully
and can provide you multi-year contract optioned space....so you can toss
them away when IPv6 is it.

Thank You
Bob Evans
CTO




> Leasing is ill-advised; the addresses will be unsellable once the spammers
> are through with them.
> Really, there?s no other reason to lease.
>
> If you want to buy or sell addresses in the ARIN region, some of the
> facilitators at
> https://www.arin.net/resources/transfer_listing/facilitator_list.html are
> pretty good (ask me; I?ll let you know my opinions privately).
>
> The only ones I know who will deal in blocks as small as /24 are
> http://www.ipv4auctions.com/
> There may be others I don?t know about.
>
> Of course you have to ask whether IPv6 is a possible alternative, and you
> shouldn?t go to all the troule and expense of buying addresses without
> turning up dual-stack. That would be like spending $20 for a tissue when
> you need a $10 cold medicine; it helps, but not for long.
>
> Lee
>
>
> On 12/17/15, 9:31 PM, "NANOG on behalf of Nick Ellermann"
> <nanog-bounces at nanog.org on behalf of nellermann at broadaspect.com> wrote:
>
>>We have customers asking to lease IP space for BGP transit with us and
>>other peers. But they are struggling to get at a minimum even a Class C,
>>even though they have their own ASN. We don't have large amounts of free
>>IPv4 space to lease out to a single customer in most cases anymore. Hope
>>to at least introduce these customers to some contacts that may be able
>>to help.
>>Do we know of any reputable sources that are leasing or selling IPv4
>>subnets as small as a /24 to satisfy their diversity needs? Thanks!
>>
>>Sincerely,
>>Nick Ellermann - CTO & VP Cloud Services
>>BroadAspect
>>
>>E: nellermann at broadaspect.com<mailto:nellermann at broadaspect.com>
>>P: 703-297-4639
>>F: 703-996-4443
>>
>>THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>>MATERIAL and is thus for use only by the intended recipient. If you
>>received this in error, please contact the sender and delete the e-mail
>>and its attachments from all computers.
>>
>>
>
>
>



From mcn4 at leicester.ac.uk  Sat Dec 19 00:21:05 2015
From: mcn4 at leicester.ac.uk (Matthew Newton)
Date: Sat, 19 Dec 2015 00:21:05 +0000
Subject: Nat
In-Reply-To: <D299E276.D1593%Lee@asgard.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
Message-ID: <20151219002105.GB58695@rootmail.cc.le.ac.uk>

On Fri, Dec 18, 2015 at 04:20:48PM -0500, Lee Howard wrote:
> On 12/17/15, 1:59 PM, Matthew Petach wrote:
> > I'm still waiting for the IETF to come around to allowing
> > feature parity between IPv4 and IPv6 when it comes to DHCP.
> > The stance of not allowing the DHCP server to assign a default
> > gateway to the host in IPv6 is a big stumbling point for at
> > least one large enterprise I'm aware of. 
> 
> Tell me again why you want this, and not routing information
> from the router?

All config is in one place. IP address, default gateway, domain
name, DNS servers, search path, the lot.

The mix of having to do this crazy thing of gateway announcements
from one place, DNS from somewhere else, possibly auto-assigning
addresses from a router, but maybe getting them over DHCPv6. It's
just confusing and unnecessary and IMHO isn't helpful for
persuading people to move to IPv6. Especially when everyone
already understands DHCP in the v4 world.

Both RAs and DHCP have their place and can be really useful
together or apart in different situations, but witholding key
functionality from DHCP "beacuse you can do it in a RA instead"
isn't helping the v6 cause.

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>

From mpalmer at hezmatt.org  Sat Dec 19 00:23:57 2015
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Sat, 19 Dec 2015 11:23:57 +1100
Subject: Nat
In-Reply-To: <5CF2C77A-EB19-4F7D-B213-3DFDC944E19E@hrins.net>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <CAMFTxdS7O48YY3jW+TxNF7TS7T3h1r6FvLfo+mCHty99oOfhsg@mail.gmail.com>
 <5D7E4B7E-3672-41E1-8BF6-F1D6C85CFDE1@hrins.net>
 <56718FBD.8050602@seacom.mu>
 <3F8FBB6F-47B1-4A51-BCC6-484CA92109F8@hrins.net>
 <002601d1383a$81640750$842c15f0$@wicks.co.nz>
 <4F040284-0811-4291-BA58-C7178DCBCF52@hrins.net>
 <5672F537.60707@foobar.org>
 <5CF2C77A-EB19-4F7D-B213-3DFDC944E19E@hrins.net>
Message-ID: <20151219002357.GI7692@hezmatt.org>

On Fri, Dec 18, 2015 at 07:30:35PM +0300, Ahmed Munaf wrote:
> > On Dec 17, 2015, at 8:47 PM, Nick Hilliard <nick at foobar.org> wrote:
> > 
> > On 17/12/2015 17:36, Ahmed Munaf wrote:
> >> we are using ESP 20 
> > 
> > You haven't said what you mean by "better".  This could mean "faster" or
> > "copes with more sessions" or "cheaper".  If your ISP is large, then it
> > might be "cost per user is lower" or "able to cope with the number of users".
> 
> I mean by better, it handle more sessions and cheaper 

At what scale?  You probably won't get much cheaper than an rPi and
netfilter at home scale, but I wouldn't want to run a national ISP on one. 
Also, by "cheaper" do you just mean capex, or is opex a concern?

- Matt


From sander at steffann.nl  Sat Dec 19 14:03:18 2015
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 19 Dec 2015 15:03:18 +0100
Subject: Nat
In-Reply-To: <20151219002105.GB58695@rootmail.cc.le.ac.uk>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org> <20151219002105.GB58695@rootmail.cc.le.ac.uk>
Message-ID: <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>

Hi Matthew,

> The mix of having to do this crazy thing of gateway announcements
> from one place, DNS from somewhere else, possibly auto-assigning
> addresses from a router, but maybe getting them over DHCPv6. It's
> just confusing and unnecessary and IMHO isn't helpful for
> persuading people to move to IPv6. Especially when everyone
> already understands DHCP in the v4 world.
> 
> Both RAs and DHCP have their place and can be really useful
> together or apart in different situations, but witholding key
> functionality from DHCP "beacuse you can do it in a RA instead"
> isn't helping the v6 cause.

Have you ever tried to deploy IPv6 (even if only in a lab environment)? I have worked with several companies (ISP and enterprise) and once they stop thinking "I want to do everything in IPv6 in exactly the same way as I have always done in IPv4" and actually look at the features that IPv6 provides them they are usually much happier with IPv6 than they were with IPv4.

I am sure that a century ago people who were used to horse and buggy transport thought that cars were annoyingly complex and that having to put petrol in instead of hay was a huge problem. But I am very glad that in the end they adapted instead of convincing other people to make cars run on hay ;)

Just joking of course, but seriously: we need to look at what the best solution for the future is, not at ways of avoiding having to learn something new/different.

Cheers,
Sander


From jeffm at iglou.com  Sat Dec 19 14:49:42 2015
From: jeffm at iglou.com (Jeff McAdams)
Date: Sat, 19 Dec 2015 09:49:42 -0500 (EST)
Subject: Nat
In-Reply-To: <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
Message-ID: <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>

Congratulations, Sander, on proving Matthew's point quite consicely.

Matthew pointed out reasons that people don't like this setup, and reasons
that they *AREN'T DEPLOYING IPV6*.  And you blow them off with, "but it's
not the best way."  Great, I think I probably even agree with you that
using the RAs is, in general better, but let me make this really clear.

It. Is. An. Obstacle. For. Some. People. To. Deploy. IPv6.

The IETF went for a lot of architectural purity (and ignored some real
world valid use cases that RA just won't work for at all), and wanted
something clean and well designed...and that's OK.  But it doesn't help us
solve the real-world problem of IPv4 depletion if that architectural
purity causes people not to deploy the solution.

Real world operators (some, at least) want default route/router assigned
via DHCP for real world operational reasons.  If the IETF and others
respond merely by saying that it's better to do IPv6 this other way, right
or wrong, *THE IETF* is the problem.

It's far past time to worry about architectural purity.  We need people
deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this
point, to fix the problems that are causing people not to deploy.

On Sat, December 19, 2015 09:03, Sander Steffann wrote:
> Hi Matthew,
>
>
>> The mix of having to do this crazy thing of gateway announcements
>> from one place, DNS from somewhere else, possibly auto-assigning
>> addresses from a router, but maybe getting them over DHCPv6. It's just
>> confusing and unnecessary and IMHO isn't helpful for persuading people
>> to move to IPv6. Especially when everyone already understands DHCP in
>> the v4 world.
>>
>> Both RAs and DHCP have their place and can be really useful
>> together or apart in different situations, but witholding key
>> functionality from DHCP "beacuse you can do it in a RA instead" isn't
>> helping the v6 cause.
>
> Have you ever tried to deploy IPv6 (even if only in a lab environment)? I
> have worked with several companies (ISP and enterprise) and once they
> stop thinking "I want to do everything in IPv6 in exactly the same way as
> I have always done in IPv4" and actually look at the features that IPv6
> provides them they are usually much happier with IPv6 than they were with
> IPv4.
>
>
> I am sure that a century ago people who were used to horse and buggy
> transport thought that cars were annoyingly complex and that having to
> put petrol in instead of hay was a huge problem. But I am very glad that
> in the end they adapted instead of convincing other people to make cars
> run on hay ;)
>
> Just joking of course, but seriously: we need to look at what the best
> solution for the future is, not at ways of avoiding having to learn
> something new/different.
>
> Cheers,
> Sander
>
>
>


-- 
Jeff


From ahmed.dalaali at hrins.net  Sat Dec 19 14:53:00 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Sat, 19 Dec 2015 17:53:00 +0300
Subject: CDN 
Message-ID: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>

Dear All, 

Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc, hosting their servers on other party providers? 
just like what GGC and Akamai do by hosting their servers on other ISP?s datacenter! 

Regards, 


From sander at steffann.nl  Sat Dec 19 15:17:04 2015
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 19 Dec 2015 16:17:04 +0100
Subject: Nat
In-Reply-To: <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org> <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
Message-ID: <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>

Hi Jeff,

> It's far past time to worry about architectural purity.  We need people
> deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this
> point, to fix the problems that are causing people not to deploy.

I partially agree with you. If people have learned how IPv6 works, deployed IPv6 (even if just in a lab) and came to the conclusion that there is an obstacle then I very much want to hear what problems they ran into. That's rarely the case unfortunately. Most of the time I hear "we don't want to learn something new".

If the choice is between the IETF having to change standards vs some people having to learn something new then sorry, they will have to invest some time and learn.... IPv4 != IPv6. You have to keep learning, that's part of the job.

Where we should focus our efforts is on making that learning process as easy as we can. That is an area where we have been failing horribly. Especially for enterprises. The mindset in enterprises is very different from that in ISPs, and we have been assuming for too long that documentation and best-practices for an ISP also work in an enterprise. I see a lot of enterprises that just don't know where to start, how to best run their networks with IPv6, with concerns about management, privacy, security etc. Changing standards isn't going to solve that (except to give them a false sense of security because it starts looking a lot like IPv4 on the surface). Besides: the time it takes to change standards and get new code deployed everywhere would be a bigger obstacle in getting IPv6 deployed soon anyway.

So yes, people have to deploy IPv6 as soon as possible, but it's not the job of the IETF to fix all of the obstacles. There are definitely obstacles that the IETF needs to fix. But I don't think this is one of them... This one is better solved by showing how to make good use of all the nice features that IPv6 offers.

Cheers,
Sander


From mehmet at akcin.net  Sat Dec 19 15:35:11 2015
From: mehmet at akcin.net (Mehmet Akcin)
Date: Sat, 19 Dec 2015 07:35:11 -0800
Subject: CDN
In-Reply-To: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
Message-ID: <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>

looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
give you an idea where they are.

mehmet

On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
wrote:

> Dear All,
>
> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
> hosting their servers on other party providers?
> just like what GGC and Akamai do by hosting their servers on other ISP?s
> datacenter!
>
> Regards,
>
>

From patrick at ianai.net  Sat Dec 19 16:13:36 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sat, 19 Dec 2015 11:13:36 -0500
Subject: CDN
In-Reply-To: <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
Message-ID: <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>

PeeringDB will tell you where they connect. I do not think anyone puts stuff into PeeringDB when they have on-net nodes.

In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.

-- 
TTFN,
patrick

> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
> 
> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
> give you an idea where they are.
> 
> mehmet
> 
> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
> wrote:
> 
>> Dear All,
>> 
>> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
>> hosting their servers on other party providers?
>> just like what GGC and Akamai do by hosting their servers on other ISP?s
>> datacenter!
>> 
>> Regards,
>> 
>> 


From mehmet at akcin.net  Sat Dec 19 16:16:39 2015
From: mehmet at akcin.net (Mehmet Akcin)
Date: Sat, 19 Dec 2015 08:16:39 -0800
Subject: CDN
In-Reply-To: <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
 <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
Message-ID: <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net>

I don?t think anyone really would tell where their critical network assets are but obviously you can guesstimate by looking where they have connection points available.

> On Dec 19, 2015, at 8:13 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> 
> PeeringDB will tell you where they connect. I do not think anyone puts stuff into PeeringDB when they have on-net nodes.
> 
> In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.
> 
> -- 
> TTFN,
> patrick
> 
>> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>> 
>> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
>> give you an idea where they are.
>> 
>> mehmet
>> 
>> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
>> wrote:
>> 
>>> Dear All,
>>> 
>>> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
>>> hosting their servers on other party providers?
>>> just like what GGC and Akamai do by hosting their servers on other ISP?s
>>> datacenter!
>>> 
>>> Regards,
>>> 
>>> 
> 


From nick at foobar.org  Sat Dec 19 16:17:30 2015
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 19 Dec 2015 16:17:30 +0000
Subject: Nat
In-Reply-To: <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org> <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
 <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
Message-ID: <5675831A.4050300@foobar.org>

Sander Steffann wrote:
> So yes, people have to deploy IPv6 as soon as possible, but it's not
> the job of the IETF to fix all of the obstacles.

What we need is for the IETF to stop being an obstacle.

More to the point, as the IETF's opinion is based on the consensus of
its working groups, it would help if specific people in a small number
of IETF working groups stopped doing everything within their power to
prevent dhcpv6 from becoming feature complete.

Unfortunately, this turned into a religious war a long time ago and the
primary consideration with regard to dhcpv6 has not been what's best for
ipv6 or ipv6 users or ipv6 operators, but ensuring that dhcpv6 is
sufficiently crippled as a protocol that it cannot be deployed without
RA due to lack of features.

It will happen, sooner or later.  One of the large vendors is eventually
going to make a corporate decision that the current situation is stupid
and will come up with vendor specific extensions to dhcpv6 to make it a
standalone protocol.  Due to their size, everyone else will be forced to
implement this standard.  It's just a pity we can't set out and make a
compatible standard on day 1, or even year 19.

Nick

From jared at puck.nether.net  Sat Dec 19 16:18:58 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 19 Dec 2015 11:18:58 -0500
Subject: Nat
In-Reply-To: <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org> <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
 <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
Message-ID: <4F496D90-A5E7-4316-B1F6-6B1A615FB151@puck.nether.net>

I'm preparing some slides on this topic for an upcoming webinar our marketing team has roped me into :-)

I'd love to hear from people on what they perceive and the real barriers they have seen with regards to IPv6 in your environment. 

I certainly have the list from our IT department. After much effort and under duress it seems they are making progress and 2016 will be the year it happens. 

Jared Mauch

> On Dec 19, 2015, at 10:17 AM, Sander Steffann <sander at steffann.nl> wrote:
> 
> 
> If the choice is between the IETF having to change standards vs some people having to learn something new then sorry, they will have to invest some time and learn.... IPv4 != IPv6. You have to keep learning, that's part of the job.

From patrick at ianai.net  Sat Dec 19 16:27:12 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sat, 19 Dec 2015 11:27:12 -0500
Subject: CDN
In-Reply-To: <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
 <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
 <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net>
Message-ID: <29C5EDEC-CA80-4E40-9C0B-F82CE214DA6B@ianai.net>

I do not follow the logic.

If a CDN says they have a gigantic peering node in DC, how does that tell you where they put on-net servers?

Wouldn?t it make more sense to put servers on-net in OKC or SLC because they do _NOT_ have large peering nodes there? Locality is important. Akamai has thousands of nodes in a hundred or so countries. While they have a lot of peering, I have trouble thinking their nodes are all next to large IXPs. (OK, I know they are not, but let?s not get into that.) Plus this seems very US/EU centric. What about places without a lot large IXPs, like South America, Africa, South-East Asia, etc.?

Finally, your logic seems a bit self-contradictory: ?They won?t tell you where their big network nodes are. But if you look in this free, public database, you can find their big network nodes."

-- 
TTFN,
patrick

> On Dec 19, 2015, at 11:16 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
> 
> I don?t think anyone really would tell where their critical network assets are but obviously you can guesstimate by looking where they have connection points available.
> 
>> On Dec 19, 2015, at 8:13 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
>> 
>> PeeringDB will tell you where they connect. I do not think anyone puts stuff into PeeringDB when they have on-net nodes.
>> 
>> In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>>> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>>> 
>>> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
>>> give you an idea where they are.
>>> 
>>> mehmet
>>> 
>>> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
>>> wrote:
>>> 
>>>> Dear All,
>>>> 
>>>> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
>>>> hosting their servers on other party providers?
>>>> just like what GGC and Akamai do by hosting their servers on other ISP?s
>>>> datacenter!
>>>> 
>>>> Regards,
>>>> 
>>>> 
>> 


From mehmet at akcin.net  Sat Dec 19 16:32:11 2015
From: mehmet at akcin.net (Mehmet Akcin)
Date: Sat, 19 Dec 2015 08:32:11 -0800
Subject: CDN
In-Reply-To: <29C5EDEC-CA80-4E40-9C0B-F82CE214DA6B@ianai.net>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
 <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
 <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net>
 <29C5EDEC-CA80-4E40-9C0B-F82CE214DA6B@ianai.net>
Message-ID: <708E13A0-B88D-4BDE-A144-4BE15A706318@akcin.net>

I think we both agree there is no perfect publication of where their servers actually are

Given Ahmed is asking "Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc, hosting their servers on other party providers??

i think the answer you given which is 

>>> 
>>> In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.


good one

Mehmet

> On Dec 19, 2015, at 8:27 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> 
> I do not follow the logic.
> 
> If a CDN says they have a gigantic peering node in DC, how does that tell you where they put on-net servers?
> 
> Wouldn?t it make more sense to put servers on-net in OKC or SLC because they do _NOT_ have large peering nodes there? Locality is important. Akamai has thousands of nodes in a hundred or so countries. While they have a lot of peering, I have trouble thinking their nodes are all next to large IXPs. (OK, I know they are not, but let?s not get into that.) Plus this seems very US/EU centric. What about places without a lot large IXPs, like South America, Africa, South-East Asia, etc.?
> 
> Finally, your logic seems a bit self-contradictory: ?They won?t tell you where their big network nodes are. But if you look in this free, public database, you can find their big network nodes."
> 
> -- 
> TTFN,
> patrick
> 
>> On Dec 19, 2015, at 11:16 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>> 
>> I don?t think anyone really would tell where their critical network assets are but obviously you can guesstimate by looking where they have connection points available.
>> 
>>> On Dec 19, 2015, at 8:13 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
>>> 
>>> PeeringDB will tell you where they connect. I do not think anyone puts stuff into PeeringDB when they have on-net nodes.
>>> 
>>> In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.
>>> 
>>> -- 
>>> TTFN,
>>> patrick
>>> 
>>>> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>>>> 
>>>> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
>>>> give you an idea where they are.
>>>> 
>>>> mehmet
>>>> 
>>>> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
>>>> wrote:
>>>> 
>>>>> Dear All,
>>>>> 
>>>>> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
>>>>> hosting their servers on other party providers?
>>>>> just like what GGC and Akamai do by hosting their servers on other ISP?s
>>>>> datacenter!
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> 
>>> 
> 


From nanog at ics-il.net  Sat Dec 19 16:41:58 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 19 Dec 2015 10:41:58 -0600 (CST)
Subject: Nat
In-Reply-To: <20151218004613.BB9483F6434F@rock.dv.isc.org>
Message-ID: <943962769.2261.1450543395936.JavaMail.mhammett@ThunderFuck>

"A single /64 has never been enough and it is time to grind that 
myth into the ground. ISP's that say a single /64 is enough are 
clueless." 



LLLLOOOOOOLLLLL 


A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

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

From: "Mark Andrews" <marka at isc.org> 
To: "Chuck Church" <chuckchurch at gmail.com> 
Cc: "North American Network Operators' Group" <nanog at nanog.org> 
Sent: Thursday, December 17, 2015 6:46:13 PM 
Subject: Re: Nat 


In message <01de01d13900$fe364dd0$faa2e970$@gmail.com>, "Chuck Church" writes: 
> -----Original Message----- 
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Petach 
> Sent: Thursday, December 17, 2015 1:59 PM 
> Cc: North American Network Operators' Group <nanog at nanog.org> 
> Subject: Re: Nat 
> 
> >I'm still waiting for the IETF to come around to allowing feature 
> >parity between IPv4 and IPv6 when it comes to DHCP. 
> 
> And that recent thread on prefix delegation doesn't really leave a good 
> taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and 
> get that/those prefix(s) in your (ISP) routing tables. Given that 
> 99.999% of home users would be fine with a delegation of a single /64 and 
> a single subnet I'm tempted to do that for now and let the DHCP-PD ink 
> dry for a while so CPE support can follow up. 

I have a single CPE router and 3 /64's in use. One for each of the 
wireless SSID's and one for the wired network. This is the default 
for homenet devices. A single /64 means you have to bridge all the 
traffic. 

A single /64 has never been enough and it is time to grind that 
myth into the ground. ISP's that say a single /64 is enough are 
clueless. 

Mark 

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


From youssef at 720.fr  Sat Dec 19 16:44:16 2015
From: youssef at 720.fr (Youssef Bengelloun-Zahr)
Date: Sat, 19 Dec 2015 17:44:16 +0100
Subject: CDN
In-Reply-To: <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
 <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
Message-ID: <CEE6F49F-30F8-427E-B55A-296B212DD0DC@720.fr>

Hello,

I believe Microsoft does that too, even if it's not explicitly written :

http://www.microsoft.com/Peering/Caching

Best regards.



> Le 19 d?c. 2015 ? 17:13, Patrick W. Gilmore <patrick at ianai.net> a ?crit :
> 
> PeeringDB will tell you where they connect. I do not think anyone puts stuff into PeeringDB when they have on-net nodes.
> 
> In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.
> 
> -- 
> TTFN,
> patrick
> 
>> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>> 
>> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
>> give you an idea where they are.
>> 
>> mehmet
>> 
>> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
>> wrote:
>> 
>>> Dear All,
>>> 
>>> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
>>> hosting their servers on other party providers?
>>> just like what GGC and Akamai do by hosting their servers on other ISP?s
>>> datacenter!
>>> 
>>> Regards,
> 

From dcorbe at hammerfiber.com  Sat Dec 19 16:56:01 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Sat, 19 Dec 2015 11:56:01 -0500
Subject: Nat
In-Reply-To: <943962769.2261.1450543395936.JavaMail.mhammett@ThunderFuck>
References: <943962769.2261.1450543395936.JavaMail.mhammett@ThunderFuck>
Message-ID: <C9833646-5050-485C-8344-CED36E4EBCD9@hammerfiber.com>

Hi,

> On Dec 19, 2015, at 11:41 AM, Mike Hammett <nanog at ics-il.net> wrote:
> 
> "A single /64 has never been enough and it is time to grind that 
> myth into the ground. ISP's that say a single /64 is enough are 
> clueless." 
> 
> 
> 
> LLLLOOOOOOLLLLL 
> 
> 
> A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. 
> 
> 

You?re being deliberately flippant.

There are technical reasons why a single /64 is not enough for an end user.  A lot of it has to do with the way auto configuration works.  The lower 64 bits of the IP address are essentially host entropy.  EUI-64 (for example) is a 64 bit number derived from the mac address of the NIC.

The requirement for the host portion of the address to be 64 bits long isn?t likely to change.   Which means a /64 is the smallest possible prefix that can be assigned to an end user and it limits said end user to a single subnet.

Handing out a /56 or a /48 allows the customer premise equipment to have multiple networks behind it.  It?s a good practice and there?s certainly enough address space available to support it.


From dave.taht at gmail.com  Sat Dec 19 17:14:02 2015
From: dave.taht at gmail.com (Dave Taht)
Date: Sat, 19 Dec 2015 18:14:02 +0100
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CA+-tSzzezs_w+xzyVasDFxmrQtqGYbPkdrdtj2uA6wvAdj0=ZQ@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <05dc01d13807$643e3520$2cba9f60$@gmail.com>
 <CA+-tSzzezs_w+xzyVasDFxmrQtqGYbPkdrdtj2uA6wvAdj0=ZQ@mail.gmail.com>
Message-ID: <CAA93jw718OcD_rCe+Kk+nYoij2UgoF2gTR1yYBEHh8VwrSwe-g@mail.gmail.com>

In the end, there seems to be no "reliable" way to ask the network my question.

But... WOW! Thank you all for your interesting and clever techniques!

From joelja at bogus.com  Sat Dec 19 17:44:35 2015
From: joelja at bogus.com (joel jaeggli)
Date: Sat, 19 Dec 2015 09:44:35 -0800
Subject: CDN
In-Reply-To: <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
 <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
 <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net>
Message-ID: <56759783.9060205@bogus.com>

On 12/19/15 8:16 AM, Mehmet Akcin wrote:
> I don?t think anyone really would tell where their critical network assets are but obviously you can guesstimate by looking where they have connection points available.

in general people who want to serve bits to your customers are going to
be a little less coy about where there assets are. in particular the CDN
bits are interested in peering nearer to your region of operation rather
than further.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
https://beta.peeringdb.com/net/1418

https://www.google.com/about/datacenters/inside/locations/index.html
https://beta.peeringdb.com/net/433

https://www.cloudflare.com/network-map/
https://beta.peeringdb.com/net/4224


>> On Dec 19, 2015, at 8:13 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
>>
>> PeeringDB will tell you where they connect. I do not think anyone puts stuff into PeeringDB when they have on-net nodes.
>>
>> In general, only the big three (Akamai, Netflix, Google) have significant deployments inside eyeball networks. Exceptions to every rule and all that, but if you pick random large eyeball network, chances are very, very high they have no one other than those three - if they have any at all.
>>
>> -- 
>> TTFN,
>> patrick
>>
>>> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>>>
>>> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
>>> give you an idea where they are.
>>>
>>> mehmet
>>>
>>> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf <ahmed.dalaali at hrins.net>
>>> wrote:
>>>
>>>> Dear All,
>>>>
>>>> Does anyone know if AWS amazon ?cloudfront?, cloud flare, Microsoft ? etc,
>>>> hosting their servers on other party providers?
>>>> just like what GGC and Akamai do by hosting their servers on other ISP?s
>>>> datacenter!
>>>>
>>>> Regards,
>>>>
>>>>
>>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151219/1124779d/attachment.pgp>

From bzs at theworld.com  Sat Dec 19 17:44:10 2015
From: bzs at theworld.com (bzs at theworld.com)
Date: Sat, 19 Dec 2015 12:44:10 -0500
Subject: IPv4 subnets for lease?
In-Reply-To: <c7d9579fc766e86745b8a73f80181585.squirrel@66.201.44.180>
References: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
 <D299DE5B.D1556%Lee@asgard.org>
 <c7d9579fc766e86745b8a73f80181585.squirrel@66.201.44.180>
Message-ID: <22133.38762.962197.677506@pcls8.std.com>


Although I realize it's a practical matter I find it fairly amazing
that IPv4 blocks will be stigmatized as spam infected and hence
worthless or nearly so.

Talk about giving in to "terrorists" (I use that word
metaphorically.)

Something to note next time someone asks me what the actual financial
impact of spamming is.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

From mpetach at netflight.com  Sat Dec 19 18:01:54 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 19 Dec 2015 10:01:54 -0800
Subject: Nat
In-Reply-To: <D299E276.D1593%Lee@asgard.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
Message-ID: <CAEmG1=pCB71kYrn_Nyht7cMMPd06s3GL_LqsR_F=i2Lbpy37jw@mail.gmail.com>

On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee at asgard.org> wrote:
>
>
> On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
>
>>I'm still waiting for the IETF to come around
>>to allowing feature parity between IPv4 and IPv6
>>when it comes to DHCP.  The stance of not
>>allowing the DHCP server to assign a default
>>gateway to the host in IPv6 is a big stumbling
>>point for at least one large enterprise I'm aware
>>of.
>
>
> Tell me again why you want this, and not routing information from the
> router?

Apologies for the delay in replying, work has
been insanely busy as we come to the end
of the quarter.

The problem is when you have multiple routers
in a common arena, there's no way to associate
a given client with a given router unless the DHCP
server can give out that information.

In an enterprise wireless environment,
you have many different subnets
for different sets of employees.  Unfortunately,
the reality of common RF spectrum dictates
you can't do separate SSIDs for every subnet
your employees belong to; so, you have one
SSID for the company that employees associate
with, and then the DHCP server issues an appropriate
IP to the laptop based on the certificate/credentials
presented.  In the v4 world, you get your IP address
and your router information all from the DHCP server,
you end up on the right subnet in the right building
for your job classification, and all is good.
In the v6 world, your DHCP server hands you an IP
address, but the client sees an entire spectrum of
routers to choose from, with no idea of which one
would be most appropriate to make use of.  Do I
use the one that's here in the same building as me,
or do I use one that's several blocks away in an
entirely different part of the campus?

The wonderful thing about modern wireless setups
for enterprises is that you can allow your employees
to all have their laptops configured to associate with
the same SSID, and handle all the issues of assigning
them to a particular subnet and vlan at the RADIUS/DHCPv4
level; you don't have to have different employees on
different SSIDs for finance vs engineering vs HR
vs sales.  In v4, you can segment the employees
very nicely after they've associated with the AP
and give them all the necessary information for
building in which they're in.  V6 doesn't provide that
ability; so, I associate with the AP, I get my IPv6 address,
and then I look at which possible routers are announcing
information about my subnet, and I see there's one in
building B, one in building F, and one in building W, and
I just randomly pick one, which may be nearby, or may
be across the other side of campus.  Furthermore, I also
see all the announcements from routers for subnets
I'm *not* a part of, cluttering up the spectrum.  Rather
than have routers spewing out "here I am" messages
and taking up RF spectrum, I'd much prefer to explicitly
tell clients "you're in sales, you're in building W, here's
your IP address, and use the upstream router located
in your building."  No extra RF spectrum used up by
routers all over the place saying "here I am", no issues
of clients choosing a less-optimal upstream router and
then complaining about latency and performance.

I can see where in some environments, routers
using RAs to announce their presence to clients
makes sense.  Large-scale enterprise wireless
isn't one of those; so, give us the *ability* to
choose to explicitly give out router information
via DHCPv6 in those situations.  I'm not saying
RAs are bad; I'm simply saying that the IETF
plugging its ears to the needs of enterprises
and claiming that we just don't 'get' how IPv6
is supposed to work and therefore they won't
support assigning router information via DHCPv6
is an impediment to more rapid adoption.

And for those of you who say "but just use
different SSIDs for every subnet in the company",
please go do some reading on how SSIDs
are beaconed, and what the effective limit
is on how many SSIDs you can have within
a given region of RF coverage.  It's generally
best to keep your SSID count in the single
digits; by the time you get more than a dozen
SSIDs, you're using up nearly half of your
RF spectrum just beaconing the SSIDs.


>> Right now, the biggest obstacle to IPv6
>>deployment seems to be the ivory-tower types
>>in the IETF that want to keep it pristine, vs
>>allowing it to work in the real world.
>
> There?s a mix of people at IETF, but more operator input there would be
> helpful. I have a particular draft in mind that is stuck between ?we?d
> rather delay IPv6 than do it wrong? and ?be realistic about how people
> will deploy it."
>
> Lee

I agree more operator input would be good;
unfortunately, it's easier for management to
say "let's just delay IPv6 until they get it
working" than it is to justify sending employees
to IETF meetings all over the place to explain
why their model of how IPv6 should work isn't
working out for the enterprise.

In effect, the IETF's stance is making it more
expensive for companies to deploy IPv6 than
simply stay on IPv4--so is it any wonder that
people aren't moving faster?

Reduce the friction preventing companies
from being able to do parallel, homologous
IPv6 deployments, and you'll see faster
movements.  Right now, the insistence that
IPv6 *must* be done differently, and *must*
be done with an orthogonal network design
and topology is an increased cost companies
are unwilling to bear.  And there is *NO* technical
reason that DHCPv6 could not be allowed to
provide identical information as DHCPv4; it
is purely human stubbornness on the part
of IETF members who insist that *their*
model of how IPv6 should be deployed is
better, and therefore they won't even allow
the *option* to do it a different way.

Such hubris!  Is it any wonder people avoid
dealing with the IETF?

OK.  Taking some deep breaths and calming
back down now...

Fundamentally, Lee, the challenge is when you
have multiple routers for a given subnet, how do
you put some set of clients pointing to one router,
and a different set of clients pointing to another
router using RAs?

Thanks!

Matt

From mpetach at netflight.com  Sat Dec 19 18:10:01 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 19 Dec 2015 10:10:01 -0800
Subject: Nat
In-Reply-To: <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
 <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
Message-ID: <CAEmG1=qVEzu2jHDURExLF1FSHkeOnBfWBqY5626NnpWXi374OQ@mail.gmail.com>

On Sat, Dec 19, 2015 at 7:17 AM, Sander Steffann <sander at steffann.nl> wrote:
> Hi Jeff,
>
>> It's far past time to worry about architectural purity.  We need people
>> deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this
>> point, to fix the problems that are causing people not to deploy.
>
> I partially agree with you. If people have learned how IPv6 works, deployed IPv6 (even if just in a lab) and came to the conclusion that there is an obstacle then I very much want to hear what problems they ran into. That's rarely the case unfortunately. Most of the time I hear "we don't want to learn something new".


Hi Sander,

I have multiple sets of clients on a particular subnet; the subnet
is somewhat geographically distributed; I have multiple routers
on the subnet.  I currently am able to explicitly associate clients
with the most appropriate router for them in v4.
How can I do this using only RAs in IPv6?

I'd be happy to learn something new.  Unfortunately, my
research hasn't shown me that there's something new
to learn, it's shown me that "IPv6 can't do that, sorry."

Thanks!

Matt

From bill at herrin.us  Sat Dec 19 18:17:25 2015
From: bill at herrin.us (William Herrin)
Date: Sat, 19 Dec 2015 13:17:25 -0500
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
Message-ID: <CAP-guGUc4RtcDvenjgSsd_hSfj1mxdyKxwT9dAvRbJ=2PTGe8g@mail.gmail.com>

On Wed, Dec 16, 2015 at 4:36 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Tue, Dec 15, 2015 at 4:19 PM, William Herrin <bill at herrin.us> wrote:

>> From what you've posted, you don't want to detect the difference
>> between a switch and a bridge, you want to detect the difference
>
> To be more clear I wanted to detect if there was more than one
> bridge on the network, where the bridge being a PITA was a wired/wireless
> bridge.

Hi Dave,

I recommend you stop using the word "bridge." I think see where you're
heading with it, but I think you're chasing a blind alley which
encourages a false mental model of how layer 2 networks function. You
came here for answers. This is one of them.

"Bridge" describes a device which existed in layer 2 networks a
quarter century ago. You had a 10-base2 ethernet with every station
connected to a shared coax wire. Or you had a token ring where each
station was wired to the next station in a loop. Or if you were
sophisticated you had 10-baseT with a hub that repeated bits from any
port to all ports with no concept of packets.

And then you had a bridge which could connect these networks together,
buffering complete packets and smartly repeating only the packets
which belong on the other side. The bridge let you expand past the
distance limitations imposed by the ethernet collision domain, and it
let you move between two different speed networks.

These networks are now largely a historical curiousity. There are no
hubs, no 10-base2, no token passing rings. Not any more. Individual
stations now connect directly to a bridge device, which these days we
often call a "switch." Even where the stations have a shared media
(e.g. 802.11), the stations talk to the bridge, not to each other.

Bridge specifies a condition that, today, is close enough to always
true as makes no difference.



>>Are you just trying to detect stations behind wireless or
>> do you want to identify segments that are carried over wireless?
>
> The latter.
>
> In this case a routing optimization that works well on wired links was
> enabled when there were wireless bridges on that segment, leading to
> some chaos in the originally referenced thread.

The short answer to your question is: No, there is no reliable way for
software operating at layer 3 to determine that it's working across
links which contain wired or wireless.

The longer answer is that you may be asking the wrong question. Layer
2 links transit different kinds of media. Copper. Fiber. Radio. Laser.
Sometimes they travel virtual medias where the underlying technologies
are deliberately hidden. VPNs. MPLS. Sometimes it starts copper,
transits a media converter and ends up fiber. The media types do not,
in and of themselves, make much difference with respect to optimizing
layer-3 traffic flows.

Capacity
Loss
Latency
Jitter

These are the factors which matter. A full duplex licensed radio link
will tend to have exactly the same characteristics as a copper
ethernet across the same distance. An 802.11 radio link will not --
802.11 is half duplex with retransmission. It will tend to exhibit
much higher jitter than the licensed radio link and has a true
capacity limit far below the data rate.

The layer 2 media type is not known at layer 3. Optimizing for media
type is probably barking up the wrong tree anyway. Optimize for the
network characteristics which matter.

Capacity
Loss
Latency
Jitter

These are the things you want to detect and optimize for. Favor higher
capacity links. Avoid loss like the plague. Favor low latency. Prefer
low jitter.

If a link isn't too full and isn't suffering high jitter, you can
often estimate capacity by sending some small pings and some large
pings and measuring the difference in round-trip latency. But this
doesn't work if the link is comprised of parallel paths -- you'll get
the capacity of a single path instead of the total capacity. For
example, a 128kbps ISDN BRI running multilink PPP will detect as
64kbps. And it doesn't work with half duplex paths where capacity is a
stochastic function based on the number of colliding speakers.

Loss is the deadly one. Packet loss above a fractional percent kills
TCP/IP pretty fast. Detecting it is highly situational. In principle
your routers could keep track of packet counts sent and received from
each neighbor and communicate them with each other. Then alter the
base link metric depending on differences in the counts. I haven't
seen this done anywhere though. Except on point to point links the
router generally doesn't know or track which neighbor sent which
packet.

Latency (delay) changes with distance and buffering. Can't really tell
the difference between the two from layer 3. Can't measure latency
without actively polliing, which consumes capacity. And high jitter
renders latency measurements unreliable.

Jitter is the degree to which latency changes from packet to packet.
Links operating near capacity will express higher jitter as some
packets are buffered and some aren't. Links with an underlying error
detection and retransmission mechanism (like 802.11) will express
higher jitter. Half duplex links with collision avoidance or collision
detection (802.11 or old-school 10-baseT) will express higher jitter
as packets from simultaneously transmitting stations collide and are
delayed with a backoff before retransmission.

Jitter can be measured on a link, but it can't be predicted. Once
measured, you can't know the cause: whether it's a full duplex link
running near capacity or a half duplex link that occasionally has
other stations speaking. Which makes it hard to predict whether and
how often the jitter will recur.

Anyway, the bottom line is that you only think you care whether a link
is wired or wireless. What you *really* care about is:

Capacity
Loss
Latency
Jitter

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From sander at steffann.nl  Sat Dec 19 19:21:28 2015
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 19 Dec 2015 20:21:28 +0100
Subject: Nat
In-Reply-To: <5675831A.4050300@foobar.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org> <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
 <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
 <5675831A.4050300@foobar.org>
Message-ID: <DFAA3E10-9A57-4250-93ED-12DC89C3212B@steffann.nl>

Hi Nick,

> Unfortunately, this turned into a religious war a long time ago and the
> primary consideration with regard to dhcpv6 has not been what's best for
> ipv6 or ipv6 users or ipv6 operators, but ensuring that dhcpv6 is
> sufficiently crippled as a protocol that it cannot be deployed without
> RA due to lack of features.

As a network operator what I'm afraid of is the exact opposite: DHCP duplicating everything that RA does so that I now have duplicate and possibly conflicting sources of information. I already have to put DNS resolvers in both because some operating systems only use the ones provided in the RA and others only use those from DHCP. I can'd even begin to imagine the mess if e.g. routing information is also duplicated, with different operating systems using different sources.

I don't really care about the solution itself. I don't mind the original situation where routing stuff is done in RA and the rest is done in DHCP. I wouldn't have minded if everything was in RA, or everything was in DHCP. But the worst choice would be conflicting or overlapping solutions with some people religiously only implementing one of them.

There are always trade-offs. And some stupid design decisions were made in the past. But let's not create an even bigger mess...

Cheers,
Sander


From james.cutler at consultant.com  Sat Dec 19 19:32:21 2015
From: james.cutler at consultant.com (James R Cutler)
Date: Sat, 19 Dec 2015 14:32:21 -0500
Subject: Nat
In-Reply-To: <CAEmG1=pCB71kYrn_Nyht7cMMPd06s3GL_LqsR_F=i2Lbpy37jw@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <CAEmG1=pCB71kYrn_Nyht7cMMPd06s3GL_LqsR_F=i2Lbpy37jw@mail.gmail.com>
Message-ID: <D9B0BD7C-EFBC-4948-A603-F70C4B17FA70@consultant.com>

This is OT of NAT, but follows the existing discussion.

Since discussion has warped around to host configuration DHCP (again), it might be useful to review discussions dating from 2011:

The stupidity of trying to "fix? DHCPv6
and
The Business Wisdom of trying to "fix? DHCPv6

which also refer to discussions from 2009.

The pertinent Business View is 
> The security domain for HOST should not overlap the security domain for ROUTER.
> 
> That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP!
It is imperative to supply the features that End System Operators find useful for their business. This simple position is independent of IPv4/IPv6 differences.  

Since DHCP is a Host Configuration tool and is quite independent of router configurations except for DHCP forwarding entries, we must quit requiring ongoing fiddly network router configuration changes to make End System configuration changes. These can be centrally managed by DHCP run to meet End System configuration requirement, even including providing default routes. This simple position is independent of IPv4/IPv6 differences.

All that is necessary is for us to end the years of religious debate of DHCP vs RA and to start providing solutions that meet business management needs.

James R. Cutler
James.cutler at consultant.com
PGP keys at http://pgp.mit.edu



> On Dec 19, 2015, at 1:01 PM, Matthew Petach <mpetach at netflight.com> wrote:
> 
> On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee at asgard.org> wrote:
>> 
>> 
>> On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
>> 
>>> I'm still waiting for the IETF to come around
>>> to allowing feature parity between IPv4 and IPv6
>>> when it comes to DHCP.  The stance of not
>>> allowing the DHCP server to assign a default
>>> gateway to the host in IPv6 is a big stumbling
>>> point for at least one large enterprise I'm aware
>>> of.
>> 
>> 
>> Tell me again why you want this, and not routing information from the
>> router?
> 
> Apologies for the delay in replying, work has
> been insanely busy as we come to the end
> of the quarter.
> 
> The problem is when you have multiple routers
> in a common arena, there's no way to associate
> a given client with a given router unless the DHCP
> server can give out that information.
> 
> In an enterprise wireless environment,
> you have many different subnets
> for different sets of employees.  Unfortunately,
> the reality of common RF spectrum dictates
> you can't do separate SSIDs for every subnet
> your employees belong to; so, you have one
> SSID for the company that employees associate
> with, and then the DHCP server issues an appropriate
> IP to the laptop based on the certificate/credentials
> presented.  In the v4 world, you get your IP address
> and your router information all from the DHCP server,
> you end up on the right subnet in the right building
> for your job classification, and all is good.
> In the v6 world, your DHCP server hands you an IP
> address, but the client sees an entire spectrum of
> routers to choose from, with no idea of which one
> would be most appropriate to make use of.  Do I
> use the one that's here in the same building as me,
> or do I use one that's several blocks away in an
> entirely different part of the campus?
> 
> The wonderful thing about modern wireless setups
> for enterprises is that you can allow your employees
> to all have their laptops configured to associate with
> the same SSID, and handle all the issues of assigning
> them to a particular subnet and vlan at the RADIUS/DHCPv4
> level; you don't have to have different employees on
> different SSIDs for finance vs engineering vs HR
> vs sales.  In v4, you can segment the employees
> very nicely after they've associated with the AP
> and give them all the necessary information for
> building in which they're in.  V6 doesn't provide that
> ability; so, I associate with the AP, I get my IPv6 address,
> and then I look at which possible routers are announcing
> information about my subnet, and I see there's one in
> building B, one in building F, and one in building W, and
> I just randomly pick one, which may be nearby, or may
> be across the other side of campus.  Furthermore, I also
> see all the announcements from routers for subnets
> I'm *not* a part of, cluttering up the spectrum.  Rather
> than have routers spewing out "here I am" messages
> and taking up RF spectrum, I'd much prefer to explicitly
> tell clients "you're in sales, you're in building W, here's
> your IP address, and use the upstream router located
> in your building."  No extra RF spectrum used up by
> routers all over the place saying "here I am", no issues
> of clients choosing a less-optimal upstream router and
> then complaining about latency and performance.
> 
> I can see where in some environments, routers
> using RAs to announce their presence to clients
> makes sense.  Large-scale enterprise wireless
> isn't one of those; so, give us the *ability* to
> choose to explicitly give out router information
> via DHCPv6 in those situations.  I'm not saying
> RAs are bad; I'm simply saying that the IETF
> plugging its ears to the needs of enterprises
> and claiming that we just don't 'get' how IPv6
> is supposed to work and therefore they won't
> support assigning router information via DHCPv6
> is an impediment to more rapid adoption.
> 
> And for those of you who say "but just use
> different SSIDs for every subnet in the company",
> please go do some reading on how SSIDs
> are beaconed, and what the effective limit
> is on how many SSIDs you can have within
> a given region of RF coverage.  It's generally
> best to keep your SSID count in the single
> digits; by the time you get more than a dozen
> SSIDs, you're using up nearly half of your
> RF spectrum just beaconing the SSIDs.
> 
> 
>>> Right now, the biggest obstacle to IPv6
>>> deployment seems to be the ivory-tower types
>>> in the IETF that want to keep it pristine, vs
>>> allowing it to work in the real world.
>> 
>> There?s a mix of people at IETF, but more operator input there would be
>> helpful. I have a particular draft in mind that is stuck between ?we?d
>> rather delay IPv6 than do it wrong? and ?be realistic about how people
>> will deploy it."
>> 
>> Lee
> 
> I agree more operator input would be good;
> unfortunately, it's easier for management to
> say "let's just delay IPv6 until they get it
> working" than it is to justify sending employees
> to IETF meetings all over the place to explain
> why their model of how IPv6 should work isn't
> working out for the enterprise.
> 
> In effect, the IETF's stance is making it more
> expensive for companies to deploy IPv6 than
> simply stay on IPv4--so is it any wonder that
> people aren't moving faster?
> 
> Reduce the friction preventing companies
> from being able to do parallel, homologous
> IPv6 deployments, and you'll see faster
> movements.  Right now, the insistence that
> IPv6 *must* be done differently, and *must*
> be done with an orthogonal network design
> and topology is an increased cost companies
> are unwilling to bear.  And there is *NO* technical
> reason that DHCPv6 could not be allowed to
> provide identical information as DHCPv4; it
> is purely human stubbornness on the part
> of IETF members who insist that *their*
> model of how IPv6 should be deployed is
> better, and therefore they won't even allow
> the *option* to do it a different way.
> 
> Such hubris!  Is it any wonder people avoid
> dealing with the IETF?
> 
> OK.  Taking some deep breaths and calming
> back down now...
> 
> Fundamentally, Lee, the challenge is when you
> have multiple routers for a given subnet, how do
> you put some set of clients pointing to one router,
> and a different set of clients pointing to another
> router using RAs?
> 
> Thanks!
> 
> Matt


From mark.tinka at seacom.mu  Sat Dec 19 19:36:05 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 19 Dec 2015 21:36:05 +0200
Subject: CDN
In-Reply-To: <56759783.9060205@bogus.com>
References: <C5D4F8D7-FB4B-4FBD-A769-BCFC24B2F809@hrins.net>
 <CA+LTh5XCW6Th23OuQcHd4_Pu65xuKNDw948api2tLHP=J8cJwA@mail.gmail.com>
 <7BD153A6-6CFC-49AF-85C5-6B037324226B@ianai.net>
 <24649FE2-CDE8-4791-AEC8-B038D8C4D30C@akcin.net> <56759783.9060205@bogus.com>
Message-ID: <5675B1A5.3010704@seacom.mu>


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



On 19/Dec/15 19:44, joel jaeggli wrote:

> > > in general people who want to serve bits to your customers are
going to > be a little less coy about where there assets are. in
particular the CDN > bits are interested in peering nearer to your
region of operation rather > than further.

And on the partner side (where we, a service provider, may host a CDN
cluster on-net), provided the CDN provider is fine with it, we would not
be coy about what CDN assets are where, to the public and our customers.

Mark.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWdbGlAAoJEGcZuYTeKm+GnCwP/RD7aUXzuRBSUih5/GvAlBr9
QrV0QyPInZQs5+xLJ+irvJKIZMcdsD3Wg6XYWWcJnoZVOZWo9ywIHxxOZtbZXZ+P
xmQen8O95Yi8VtyzI1PuVPqQ5IwdcyjBFsw4G/99oCH0iz1RVHcDqzULoO9BmOIY
ihAgzugyNLDa655xokANC7yux3ZnSpwIIMi0uNhEWvxJA9cm6vgosnAqKqp89Gna
87p1UgkJhI1dGafbR7J3GCXPPBC/mIbTSHwHyCjvJygPtaQptiQUsZxKsCD9khj+
9KBn99899HvhWKFILYrcIZCOrFSXLWZ1RtfzDgWcViMd5U2NZruK+oi/38yiX45F
SQWKbxbEBGO61vDIoAOxVCfoHjFUCKAGbmxhMgT0tVofA1+T3YXTJk26qNaY8od7
19nW3iihWM+wngeeEpTqZYhhiuBFsLQ0cf/BAdZS3VksQoleEJr4ObMKcL+6Imgj
1XsN/1IFXnb8g2j2AEGYni8iheqMABcGs+zpi5HbfZfG+7HSp990ihmv2hAyrQD+
iDDYu9xP0aE6xfHBvRuOtK6TdJnftCBf5bye45oEq/mC7p9a9e7krw6jS+SeEw/k
T8Cu8JQ3UJHufTJfQ78HDZsuSuNgQS6ZlKc4VPTCoaeqwRtCDFve4BTGF2O0Jlny
DKjQ/AOgVaAxdF/OB9K6
=iymt
-----END PGP SIGNATURE-----


From nick at foobar.org  Sat Dec 19 19:39:53 2015
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 19 Dec 2015 19:39:53 +0000
Subject: Nat
In-Reply-To: <D9B0BD7C-EFBC-4948-A603-F70C4B17FA70@consultant.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <CAEmG1=pCB71kYrn_Nyht7cMMPd06s3GL_LqsR_F=i2Lbpy37jw@mail.gmail.com>
 <D9B0BD7C-EFBC-4948-A603-F70C4B17FA70@consultant.com>
Message-ID: <5675B289.2010400@foobar.org>

James R Cutler wrote:
> All that is necessary is for us to end the years of religious debate
> of DHCP vs RA and to start providing solutions that meet business
> management needs.

Heresy!  Burn him!

Nick

From baldur.norddahl at gmail.com  Sat Dec 19 20:34:26 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sat, 19 Dec 2015 21:34:26 +0100
Subject: Nat
In-Reply-To: <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
Message-ID: <CAPkb-7BkQ7+RPEsAeEnDJ34M1v5EL-m_WB8g+mZpyRGQ7Xj-OA@mail.gmail.com>

On 19 December 2015 at 15:49, Jeff McAdams <jeffm at iglou.com> wrote:

> It's far past time to worry about architectural purity.  We need people
> deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this
> point, to fix the problems that are causing people not to deploy.
>


If you want to deploy IPv6 NOW you will do it with the tools available NOW.
There might be use cases with a real problem, but usually the problem is at
layer 8/9.

We had our share of difficulty with deploying IPv6, but the problems were
in the implementations not the standards.

I think it is naive to believe some people would deploy IPv6 if it was just
a bit more like IPv4. No, they still would ignore it. Because the real
reason was never anything to do with IPv6, but simply that they do not see
any reason to do it. If these people wanted to do it, they would do it.
Instead they make up excuses. You are wasting your time if you try to adapt
to made up excuses.

Regards,

Baldur

From larrysheldon at cox.net  Sat Dec 19 21:53:26 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sat, 19 Dec 2015 15:53:26 -0600
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <CAP-guGUc4RtcDvenjgSsd_hSfj1mxdyKxwT9dAvRbJ=2PTGe8g@mail.gmail.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <CAP-guGUc4RtcDvenjgSsd_hSfj1mxdyKxwT9dAvRbJ=2PTGe8g@mail.gmail.com>
Message-ID: <5675D1D6.4060903@cox.net>

On 12/19/2015 12:17, William Herrin wrote:

[snip]

> I recommend you stop using the word "bridge." I think see where you're
> heading with it, but I think you're chasing a blind alley which
> encourages a false mental model of how layer 2 networks function. You
> came here for answers. This is one of them.
>
> "Bridge" describes a device which existed in layer 2 networks a
> quarter century ago. You had a 10-base2 ethernet with every station
> connected to a shared coax wire. Or you had a token ring where each
> station was wired to the next station in a loop. Or if you were
> sophisticated you had 10-baseT with a hub that repeated bits from any
> port to all ports with no concept of packets.
>
> And then you had a bridge which could connect these networks together,
> buffering complete packets and smartly repeating only the packets
> which belong on the other side. The bridge let you expand past the
> distance limitations imposed by the ethernet collision domain, and it
> let you move between two different speed networks.
>
> These networks are now largely a historical curiousity. There are no
> hubs, no 10-base2, no token passing rings. Not any more. Individual
> stations now connect directly to a bridge device, which these days we
> often call a "switch." Even where the stations have a shared media
> (e.g. 802.11), the stations talk to the bridge, not to each other.
>
> Bridge specifies a condition that, today, is close enough to always
> true as makes no difference.

Super explanation.

But I still have one question (which might be based on errors)--

I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) 
that offer a "bridge" mode, apparently to build a dedicated radio link 
between two such terminals.

Are they operating as a Radia Perlman "bridge", or is this yet another 
example if the Wiffy World high-jacking words and terms that used to 
have actual meanings?


Nice write-up, even though it is sort of sad to be confronted with the 
fact that my experience and knowledge with hose-connected (10base5. 
10base2) or token-ring networks, and hubs, and stuff is now without 
value.  That is the very worst part of getting old.

Next objective:  Somebody to 'splain at what happened to the 
wonderfulness of the OSI model where layer X did not know, could not 
know, did not care what layer X-1 was, did, or how it did it.
-- 
sed quis custodiet ipsos custodes? (Juvenal)

From sander at steffann.nl  Sat Dec 19 22:37:27 2015
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 19 Dec 2015 23:37:27 +0100
Subject: Nat
In-Reply-To: <CAEmG1=qVEzu2jHDURExLF1FSHkeOnBfWBqY5626NnpWXi374OQ@mail.gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org> <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <31373.74.139.119.34.1450536582.iglou@webmail.iglou.com>
 <841DE17E-F075-491C-BAFE-144E6FFE6A53@steffann.nl>
 <CAEmG1=qVEzu2jHDURExLF1FSHkeOnBfWBqY5626NnpWXi374OQ@mail.gmail.com>
Message-ID: <47ED158D-1343-4D58-92C3-31D982195C9C@steffann.nl>

Hi Matthew,

> I have multiple sets of clients on a particular subnet; the subnet
> is somewhat geographically distributed; I have multiple routers
> on the subnet.  I currently am able to explicitly associate clients
> with the most appropriate router for them in v4.
> How can I do this using only RAs in IPv6?
> 
> I'd be happy to learn something new.  Unfortunately, my
> research hasn't shown me that there's something new
> to learn, it's shown me that "IPv6 can't do that, sorry."

Thanks for showing me a use-case that indeed doesn't work with IPv6 :)

Cheers,
Sander


From johnl at iecc.com  Sat Dec 19 22:52:53 2015
From: johnl at iecc.com (John Levine)
Date: 19 Dec 2015 22:52:53 -0000
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <5675D1D6.4060903@cox.net>
Message-ID: <20151219225253.28781.qmail@ary.lan>

>I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) 
>that offer a "bridge" mode, apparently to build a dedicated radio link 
>between two such terminals.

The ones I've seen 

Normally those things are routers, typically with NAT on the wifi
side.  If you put it in bridge mode it is indeed a bridge, passing the
packets back and forth without messing with them.  Depending on which
way you set them up, it might be a wireless link between two wired
networks, or an extra access point with the wire running back to the
router.

>Next objective:  Somebody to 'splain at what happened to the 
>wonderfulness of the OSI model where layer X did not know, could not 
>know, did not care what layer X-1 was, did, or how it did it.

It never actually existed.  If you built your network that way,
passing each packet up and down six or seven layers, it would have
been absurdly slow.  In reality the layers only happen in places where
you can plug in multiple things at one layer, e.g., different physical
connections underneath your IP layer.

R's,
John

From james.cutler at consultant.com  Sat Dec 19 22:53:33 2015
From: james.cutler at consultant.com (James R Cutler)
Date: Sat, 19 Dec 2015 17:53:33 -0500
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <5675D1D6.4060903@cox.net>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <CAP-guGUc4RtcDvenjgSsd_hSfj1mxdyKxwT9dAvRbJ=2PTGe8g@mail.gmail.com>
 <5675D1D6.4060903@cox.net>
Message-ID: <F0EAE3D8-97C9-4B5B-928E-DA0360EB2B3C@consultant.com>

> On Dec 19, 2015, at 4:53 PM, Larry Sheldon <larrysheldon at cox.net> wrote:
> 
> On 12/19/2015 12:17, William Herrin wrote:
> 
> [snip]
> 
>> I recommend you stop using the word "bridge." I think see where you're
>> heading with it, but I think you're chasing a blind alley which
>> encourages a false mental model of how layer 2 networks function. You
>> came here for answers. This is one of them.
>> 
>> "Bridge" describes a device which existed in layer 2 networks a
>> quarter century ago. You had a 10-base2 ethernet with every station
>> connected to a shared coax wire. Or you had a token ring where each
>> station was wired to the next station in a loop. Or if you were
>> sophisticated you had 10-baseT with a hub that repeated bits from any
>> port to all ports with no concept of packets.
>> 
>> And then you had a bridge which could connect these networks together,
>> buffering complete packets and smartly repeating only the packets
>> which belong on the other side. The bridge let you expand past the
>> distance limitations imposed by the ethernet collision domain, and it
>> let you move between two different speed networks.
>> 
>> These networks are now largely a historical curiousity. There are no
>> hubs, no 10-base2, no token passing rings. Not any more. Individual
>> stations now connect directly to a bridge device, which these days we
>> often call a "switch." Even where the stations have a shared media
>> (e.g. 802.11), the stations talk to the bridge, not to each other.
>> 
>> Bridge specifies a condition that, today, is close enough to always
>> true as makes no difference.
> 
> Super explanation.
> 
> But I still have one question (which might be based on errors)--
> 
> I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that offer a "bridge" mode, apparently to build a dedicated radio link between two such terminals.
> 
> Are they operating as a Radia Perlman "bridge", or is this yet another example if the Wiffy World high-jacking words and terms that used to have actual meanings?
> 

Bridge Mode (ATT Passthrough) simply means that the router between the WAN connection and the LAN/WiFi ports is turned off and all ports share the same switch (so packets just ?pass through?. Thus all ports appear connected to a common switch.  Call that what you will, there is no spanning tree here even though we all love Radia.

> Nice write-up, even though it is sort of sad to be confronted with the fact that my experience and knowledge with hose-connected (10base5. 10base2) or token-ring networks, and hubs, and stuff is now without value.  That is the very worst part of getting old.
> 
> Next objective:  Somebody to 'splain at what happened to the wonderfulness of the OSI model where layer X did not know, could not know, did not care what layer X-1 was, did, or how it did it.

The TCP/IP suite was ?free? and essentially drove IPX/SPX, DECNet, AppleTalk, and SNA out of any large market.  Digital Equipment Corporation, for example, viewed DECnet networking as a profit center rather than a sales enabler for their hardware and software.  

And nobody wanted to spend the probably very large cost to remove what was essentially network code from applications. This is why almost every application existing need (still needs) modification just to accommodate larger address integers and a different display mechanism for addresses .
  
> -- 
> sed quis custodiet ipsos custodes? (Juvenal)

Nobody.


From larrysheldon at cox.net  Sat Dec 19 23:15:46 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sat, 19 Dec 2015 17:15:46 -0600
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <F0EAE3D8-97C9-4B5B-928E-DA0360EB2B3C@consultant.com>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <CAP-guGUc4RtcDvenjgSsd_hSfj1mxdyKxwT9dAvRbJ=2PTGe8g@mail.gmail.com>
 <5675D1D6.4060903@cox.net>
 <F0EAE3D8-97C9-4B5B-928E-DA0360EB2B3C@consultant.com>
Message-ID: <5675E522.5070400@cox.net>

On 12/19/2015 16:53, James R Cutler wrote:

[snip]

>> But I still have one question (which might be based on errors)--
>>
>> I think I have used WiFi terminals ("air ports", "WiFi routers"
>> [spit]) that offer a "bridge" mode, apparently to build a dedicated
>> radio link between two such terminals.
>>
>> Are they operating as a Radia Perlman "bridge", or is this yet
>> another example if the Wiffy World high-jacking words and terms
>> that used to have actual meanings?
>>
>
> Bridge Mode (ATT Passthrough) simply means that the router between
> the WAN connection and the LAN/WiFi ports is turned off and all ports
> share the same switch (so packets just ?pass through?. Thus all ports
> appear connected to a common switch.  Call that what you will, there
> is no spanning tree here even though we all love Radia.

I have three radios in my little toy network (two because the original 
installation was in a big house that had annoying dead spots with only 
one, one because I had to replace the router and the router replacement 
included a radio).

I just looked at one (I'm pretty sure the others are similar of the 
same) that has a pick fir "AP Mode" which offers "Access Point (default) 
which is what I run, "AP Client", "Wireless Repeater" and "Wireless Bridge".

I just realized that I don't know (or don't remember--I am old) what the 
documentation says (see--I am so old I think there IS documentation and 
that it WILL explain stuff.)


>> -- sed quis custodiet ipsos custodes? (Juvenal)
>
> Nobody.

Heh

-- 
sed quis custodiet ipsos custodes? (Juvenal)

From larrysheldon at cox.net  Sat Dec 19 23:31:55 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sat, 19 Dec 2015 17:31:55 -0600
Subject: reliably detecting the presence of a bridge?
In-Reply-To: <5675E522.5070400@cox.net>
References: <CAA93jw6LXBpSfXcF2PgqrLjQ53bOdwXErHZNpjMpmEJ-N7FKVw@mail.gmail.com>
 <CAP-guGX7RegM09Y1Vw4N9OB=tbN2OsOf630DZAgqU6hMUswZmA@mail.gmail.com>
 <CAA93jw67+_AO+ia+Fd561s6C0f6XnxC-SjVY7cnM9W8yV0XU-Q@mail.gmail.com>
 <CAP-guGUc4RtcDvenjgSsd_hSfj1mxdyKxwT9dAvRbJ=2PTGe8g@mail.gmail.com>
 <5675D1D6.4060903@cox.net>
 <F0EAE3D8-97C9-4B5B-928E-DA0360EB2B3C@consultant.com>
 <5675E522.5070400@cox.net>
Message-ID: <5675E8EB.8050809@cox.net>

On 12/19/2015 17:15, Larry Sheldon wrote:
> On 12/19/2015 16:53, James R Cutler wrote:
>
> [snip]
>
>>> But I still have one question (which might be based on errors)--
>>>
>>> I think I have used WiFi terminals ("air ports", "WiFi routers"
>>> [spit]) that offer a "bridge" mode, apparently to build a dedicated
>>> radio link between two such terminals.
>>>
>>> Are they operating as a Radia Perlman "bridge", or is this yet
>>> another example if the Wiffy World high-jacking words and terms
>>> that used to have actual meanings?
>>>
>>
>> Bridge Mode (ATT Passthrough) simply means that the router between
>> the WAN connection and the LAN/WiFi ports is turned off and all ports
>> share the same switch (so packets just ?pass through?. Thus all ports
>> appear connected to a common switch.  Call that what you will, there
>> is no spanning tree here even though we all love Radia.
>
> I have three radios in my little toy network (two because the original
> installation was in a big house that had annoying dead spots with only
> one, one because I had to replace the router and the router replacement
> included a radio).
>
> I just looked at one (I'm pretty sure the others are similar of the
> same) that has a pick for "AP Mode" which offers "Access Point (default)
> which is what I run, "AP Client", "Wireless Repeater" and "Wireless
> Bridge".

I did not make it clear--this on is by no means a router--it has two 
interfaces, 10baseT, and radio.

> I just realized that I don't know (or don't remember--I am old) what the
> documentation says (see--I am so old I think there IS documentation and
> that it WILL explain stuff.)

I did look it up, and now don't know as much as I did.

-- 
sed quis custodiet ipsos custodes? (Juvenal)

From nanog at ics-il.net  Sun Dec 20 16:57:49 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 20 Dec 2015 10:57:49 -0600 (CST)
Subject: Nat
In-Reply-To: <8D2BAAA5-C96E-4BD0-BB4F-D00218D17F9A@corbe.net>
Message-ID: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>

There's nothing that can really be done about it now and I certainly wasn't able to participate when these things were decided. 

However, keeping back 64 bits for the host was a stupid move from the beginning. We're reserving 64 bits for what's currently a 48 bit number. You can use every single MAC address whereas IPS are lost to subnetting and other such things. I could have seen maybe holding back 56 bits for the host if for some reason we need to replace the current system of MAC addresses at some point before IPv6 is replaced. 

There may be address space to support it, but is there nimble boundary space for it? 

The idea that there's a possible need for more than 4 bits worth of subnets in a home is simply ludicrous and we have people advocating 16 bits worth of subnets. How does that compare to the entire IPv4 Internet? 


There is little that can be done about much of this now, but at least we can label some of these past decisions as ridiculous and hopefully a lesson for next time. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

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

From: "Daniel Corbe" <corbe at corbe.net> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "Mark Andrews" <marka at isc.org>, "North American Network Operators' Group" <nanog at nanog.org> 
Sent: Saturday, December 19, 2015 10:55:03 AM 
Subject: Re: Nat 

Hi. 

> On Dec 19, 2015, at 11:41 AM, Mike Hammett <nanog at ics-il.net> wrote: 
> 
> "A single /64 has never been enough and it is time to grind that 
> myth into the ground. ISP's that say a single /64 is enough are 
> clueless." 
> 
> 
> 
> LLLLOOOOOOLLLLL 
> 
> 
> A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. 
> 
> 

You?re being deliberately flippant. 

There are technical reasons why a single /64 is not enough for an end user. A lot of it has to do with the way auto configuration works. The lower 64 bits of the IP address are essentially host entropy. EUI-64 (for example) is a 64 bit number derived from the mac address of the NIC. 

The requirement for the host portion of the address to be 64 bits long isn?t likely to change. Which means a /64 is the smallest possible prefix that can be assigned to an end user and it limits said end user to a single subnet. 

Handing out a /56 or a /48 allows the customer premise equipment to have multiple networks behind it. It?s a good practice and there?s certainly enough address space available to support it. 




From dcorbe at hammerfiber.com  Sun Dec 20 17:55:34 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Sun, 20 Dec 2015 12:55:34 -0500
Subject: Nat
In-Reply-To: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
Message-ID: <A8F8A1A3-DB06-4065-ACE4-9862F5DAF0D2@hammerfiber.com>


> On Dec 20, 2015, at 11:57 AM, Mike Hammett <nanog at ics-il.net> wrote:
> 
> However, keeping back 64 bits for the host was a stupid move from the beginning. We're reserving 64 bits for what's currently a 48 bit number. You can use every single MAC address whereas IPS are lost to subnetting and other such things. I could have seen maybe holding back 56 bits for the host if for some reason we need to replace the current system of MAC addresses at some point before IPv6 is replaced. 

EUI-64 isn?t the only thing out there that expects hosts to have 64-bit addresses.  That was only an example.  

> 
> There may be address space to support it, but is there nimble boundary space for it? 

Yes.  Do the math.  If every end user got a /48 there?s still 281 *trillion* subnets to go around.   The limiting factor in IPv4 is that nobody expected to be able to connect 4 billion devices to the Internet when it was conceived.  I really doubt that we?ll see 281 trillion people walking around any time in the next 1000 generations of human civilization.  

IPv6 is here to stay.  

> 
> The idea that there's a possible need for more than 4 bits worth of subnets in a home is simply ludicrous and we have people advocating 16 bits worth of subnets. How does that compare to the entire IPv4 Internet? 

You?re still stuck on ?LOOOOL ADDRESSES.?  

> 
> 
> There is little that can be done about much of this now, but at least we can label some of these past decisions as ridiculous and hopefully a lesson for next time. 

There isn?t going to be a next time.

> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> ----- Original Message -----
> 
> From: "Daniel Corbe" <corbe at corbe.net> 
> To: "Mike Hammett" <nanog at ics-il.net> 
> Cc: "Mark Andrews" <marka at isc.org>, "North American Network Operators' Group" <nanog at nanog.org> 
> Sent: Saturday, December 19, 2015 10:55:03 AM 
> Subject: Re: Nat 
> 
> Hi. 
> 
>> On Dec 19, 2015, at 11:41 AM, Mike Hammett <nanog at ics-il.net> wrote: 
>> 
>> "A single /64 has never been enough and it is time to grind that 
>> myth into the ground. ISP's that say a single /64 is enough are 
>> clueless." 
>> 
>> 
>> 
>> LLLLOOOOOOLLLLL 
>> 
>> 
>> A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. 
>> 
>> 
> 
> You?re being deliberately flippant. 
> 
> There are technical reasons why a single /64 is not enough for an end user. A lot of it has to do with the way auto configuration works. The lower 64 bits of the IP address are essentially host entropy. EUI-64 (for example) is a 64 bit number derived from the mac address of the NIC. 
> 
> The requirement for the host portion of the address to be 64 bits long isn?t likely to change. Which means a /64 is the smallest possible prefix that can be assigned to an end user and it limits said end user to a single subnet. 
> 
> Handing out a /56 or a /48 allows the customer premise equipment to have multiple networks behind it. It?s a good practice and there?s certainly enough address space available to support it. 
> 
> 
> 


From mpetach at netflight.com  Sun Dec 20 18:22:20 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 20 Dec 2015 10:22:20 -0800
Subject: Nat
In-Reply-To: <A8F8A1A3-DB06-4065-ACE4-9862F5DAF0D2@hammerfiber.com>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
 <A8F8A1A3-DB06-4065-ACE4-9862F5DAF0D2@hammerfiber.com>
Message-ID: <CAEmG1=rFr-HFV5JNM2W1Bf_UbnUtXa6HvJ1d_R+nfeZuQSyBUQ@mail.gmail.com>

On Sun, Dec 20, 2015 at 9:55 AM, Daniel Corbe <dcorbe at hammerfiber.com> wrote:
>> On Dec 20, 2015, at 11:57 AM, Mike Hammett <nanog at ics-il.net> wrote:
>>
>> There is little that can be done about much of this now, but at least we can label some of these past decisions as ridiculous and hopefully a lesson for next time.
>
> There isn?t going to be a next time.

*points and snickers quietly*

You're either an incredible optimist,
or you're angling to be the next oft-
misquoted "640KB should be enough
for anyone" voice.

We got a good quarter of a century
out of IPv4.  I think we *might* hit
the century mark with IPv6...maybe.
But before we hit that, I suspect we'll
have found enough shortcomings
and gaps that we'll need to start
developing a new addressing format
to go with the newer networking
protocols we'll be designing to
fix those shortcomings.

Until the sun goes poof, there's *always*
going to be a next time.  We're never going
to get it _completely_ right.  You just have
to consider a longer time horizon than our
own careers.

Matt

From dcorbe at hammerfiber.com  Sun Dec 20 18:36:00 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Sun, 20 Dec 2015 13:36:00 -0500
Subject: Nat
In-Reply-To: <CAEmG1=rFr-HFV5JNM2W1Bf_UbnUtXa6HvJ1d_R+nfeZuQSyBUQ@mail.gmail.com>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
 <A8F8A1A3-DB06-4065-ACE4-9862F5DAF0D2@hammerfiber.com>
 <CAEmG1=rFr-HFV5JNM2W1Bf_UbnUtXa6HvJ1d_R+nfeZuQSyBUQ@mail.gmail.com>
Message-ID: <2C7192B7-C2AF-46BB-88C6-1F0C7B27C747@hammerfiber.com>


> On Dec 20, 2015, at 1:22 PM, Matthew Petach <mpetach at netflight.com> wrote:
> 
> On Sun, Dec 20, 2015 at 9:55 AM, Daniel Corbe <dcorbe at hammerfiber.com> wrote:
>>> On Dec 20, 2015, at 11:57 AM, Mike Hammett <nanog at ics-il.net> wrote:
>>> 
>>> There is little that can be done about much of this now, but at least we can label some of these past decisions as ridiculous and hopefully a lesson for next time.
>> 
>> There isn?t going to be a next time.
> 
> *points and snickers quietly*
> 
> You're either an incredible optimist,
> or you're angling to be the next oft-
> misquoted "640KB should be enough
> for anyone" voice.
> 
> We got a good quarter of a century
> out of IPv4.  I think we *might* hit
> the century mark with IPv6...maybe.
> But before we hit that, I suspect we'll
> have found enough shortcomings
> and gaps that we'll need to start
> developing a new addressing format
> to go with the newer networking
> protocols we'll be designing to
> fix those shortcomings.
> 
> Until the sun goes poof, there's *always*
> going to be a next time.  We're never going
> to get it _completely_ right.  You just have
> to consider a longer time horizon than our
> own careers.
> 
> Matt
> 

I?m only going to say one more thing on this subject because this is essentially a side bar that has very little to do with the subject matter of the OP.  

If we hadn?t run out of address space we?d still be trying to fix IPv4.  The numbers don?t lie.  It?s not very likely that we?re going to be space constrained on the IPv6 Internet like we are on the IPv4 internet.  Nobody is going to want to repeat the pain of the last 17 years of trying to convince people to run IPv6.

Just about every technical challenge with the underlying protocol stack is fixable.  Except for one: what happens when we run out addresses.  For all of its flaws, IPv6 addresses this one particular issue quite well.



From baldur.norddahl at gmail.com  Sun Dec 20 19:53:40 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sun, 20 Dec 2015 20:53:40 +0100
Subject: Nat
In-Reply-To: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
References: <8D2BAAA5-C96E-4BD0-BB4F-D00218D17F9A@corbe.net>
 <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAPkb-7BTMPi5CKWHvh+iBGoj=2NNA4fZUwMzkvQ=B7bujOQkxg@mail.gmail.com>

On 20 December 2015 at 17:57, Mike Hammett <nanog at ics-il.net> wrote:

> The idea that there's a possible need for more than 4 bits worth of
> subnets in a home is simply ludicrous and we have people advocating 16 bits
> worth of subnets. How does that compare to the entire IPv4 Internet?
>

Does those extra bits somehow physical hurt you?

Really the choice of address space was 64 or 128 bits. Anything else would
just make it cumbersome to implement in hardware.

We are assigning /48 to end users. If IPv6 addresses had been 64 bits, that
would leave just 16 bits to the users. We would have gone from you get more
than you could possible imagine to "plenty for most, but not that much
really".

I am happy that we have 128 bits. It has already proven useful for many
purposes, including the ability to encode pairs of 32 bit IPv4 addresses as
part of the IPv6 address.

Regards,

Baldur

From chuckchurch at gmail.com  Mon Dec 21 02:23:04 2015
From: chuckchurch at gmail.com (Chuck Church)
Date: Sun, 20 Dec 2015 21:23:04 -0500
Subject: Nat
In-Reply-To: <20151218004613.BB9483F6434F@rock.dv.isc.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
 <20151218004613.BB9483F6434F@rock.dv.isc.org>
Message-ID: <00e801d13b96$873e1120$95ba3360$@gmail.com>

-----Original Message-----
From: Mark Andrews [mailto:marka at isc.org] 
Sent: Thursday, December 17, 2015 7:46 PM
To: Chuck Church <chuckchurch at gmail.com>
Cc: 'Matthew Petach' <mpetach at netflight.com>; 'North American Network
Operators' Group' <nanog at nanog.org>
Subject: Re: Nat


>I have a single CPE router and 3 /64's in use.  One for each of the
wireless SSID's and one for the wired network.  This is the default for
homenet devices.  A single /64 means you >have to bridge all the traffic.

>A single /64 has never been enough and it is time to grind that myth into
the ground.  ISP's that say a single /64 is enough are clueless.

Mark,

	I agree that a /48 or /56 being reserved for business
customers/sites is reasonable.  But for residential use, I'm having a hard
time believing multi-subnet home networks are even remotely common outside
of networking folk such as the NANOG members.  A lot of recent IPv4 devices
such as smart TVs have the ability to auto-discover things they can talk to
on the network.  If we start segmenting our home networks to keep toasters
from talking to thermostats, doesn't this end up meaning your average home
user will need to be proficient in writing FW rules?  Bridging an entire
house network isn't that bad.

Chuck


From kmedcalf at dessus.com  Mon Dec 21 03:11:53 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 20 Dec 2015 20:11:53 -0700
Subject: Nat
In-Reply-To: <00e801d13b96$873e1120$95ba3360$@gmail.com>
Message-ID: <4796c7cb3fd76240964a8416525cc00d@mail.dessus.com>

> 	I agree that a /48 or /56 being reserved for business
> customers/sites is reasonable.  But for residential use, I'm having a hard
> time believing multi-subnet home networks are even remotely common outside
> of networking folk such as the NANOG members.  A lot of recent IPv4
> devices
> such as smart TVs have the ability to auto-discover things they can talk
> to
> on the network.  If we start segmenting our home networks to keep toasters
> from talking to thermostats, doesn't this end up meaning your average home
> user will need to be proficient in writing FW rules?  Bridging an entire
> house network isn't that bad.

I have (currently) 6 network segments.  One for my "trusted" clients, one for my "trusted" servers, one for the "entertainment" systems, one for "dirty & untrustworthy" computers (such as those from $dayjob), one for "clean" WiFi, and one for dirty WiFi.  If there were any additional classes of devices, they would live in their own subnets as well.

I cannot habituation between classes of devices on the same network segment.  Untrustworthy devices are relegated to their own segments where they cannot talk to anything that they ought not be talking to.  Of course, your definition of "untrustworthy" may not be the same as mine.  Any device over which I do not have supreme complete authority is untrustworthy -- which by definition includes most entertainment and other "Internet-of-Crap" devices.






From nanog at ics-il.net  Mon Dec 21 03:15:48 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 20 Dec 2015 21:15:48 -0600 (CST)
Subject: Nat
In-Reply-To: <4796c7cb3fd76240964a8416525cc00d@mail.dessus.com>
Message-ID: <849025565.4913.1450667823465.JavaMail.mhammett@ThunderFuck>

Most people couldn't care less and just want the Internet on their device to work. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

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

From: "Keith Medcalf" <kmedcalf at dessus.com> 
To: nanog at nanog.org 
Sent: Sunday, December 20, 2015 9:11:53 PM 
Subject: RE: Nat 

> I agree that a /48 or /56 being reserved for business 
> customers/sites is reasonable. But for residential use, I'm having a hard 
> time believing multi-subnet home networks are even remotely common outside 
> of networking folk such as the NANOG members. A lot of recent IPv4 
> devices 
> such as smart TVs have the ability to auto-discover things they can talk 
> to 
> on the network. If we start segmenting our home networks to keep toasters 
> from talking to thermostats, doesn't this end up meaning your average home 
> user will need to be proficient in writing FW rules? Bridging an entire 
> house network isn't that bad. 

I have (currently) 6 network segments. One for my "trusted" clients, one for my "trusted" servers, one for the "entertainment" systems, one for "dirty & untrustworthy" computers (such as those from $dayjob), one for "clean" WiFi, and one for dirty WiFi. If there were any additional classes of devices, they would live in their own subnets as well. 

I cannot habituation between classes of devices on the same network segment. Untrustworthy devices are relegated to their own segments where they cannot talk to anything that they ought not be talking to. Of course, your definition of "untrustworthy" may not be the same as mine. Any device over which I do not have supreme complete authority is untrustworthy -- which by definition includes most entertainment and other "Internet-of-Crap" devices. 







From mpalmer at hezmatt.org  Mon Dec 21 03:25:13 2015
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Mon, 21 Dec 2015 14:25:13 +1100
Subject: Nat
In-Reply-To: <4796c7cb3fd76240964a8416525cc00d@mail.dessus.com>
References: <00e801d13b96$873e1120$95ba3360$@gmail.com>
 <4796c7cb3fd76240964a8416525cc00d@mail.dessus.com>
Message-ID: <20151221032513.GH7692@hezmatt.org>

On Sun, Dec 20, 2015 at 08:11:53PM -0700, Keith Medcalf wrote:
> > 	I agree that a /48 or /56 being reserved for business
> > customers/sites is reasonable.  But for residential use, I'm having a hard
> > time believing multi-subnet home networks are even remotely common outside
> > of networking folk such as the NANOG members.  A lot of recent IPv4
> > devices
> > such as smart TVs have the ability to auto-discover things they can talk
> > to
> > on the network.  If we start segmenting our home networks to keep toasters
> > from talking to thermostats, doesn't this end up meaning your average home
> > user will need to be proficient in writing FW rules?  Bridging an entire
> > house network isn't that bad.
> 
> I have (currently) 6 network segments.  One for my "trusted" clients, one
> for my "trusted" servers, one for the "entertainment" systems, one for
> "dirty & untrustworthy" computers (such as those from $dayjob), one for
> "clean" WiFi, and one for dirty WiFi.  If there were any additional
> classes of devices, they would live in their own subnets as well.

If suspect you probably come under the "networking folk such as NANOG
members" exception to the general assertion.

- Matt


From mpalmer at hezmatt.org  Mon Dec 21 03:28:33 2015
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Mon, 21 Dec 2015 14:28:33 +1100
Subject: Nat
In-Reply-To: <00e801d13b96$873e1120$95ba3360$@gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
 <20151218004613.BB9483F6434F@rock.dv.isc.org>
 <00e801d13b96$873e1120$95ba3360$@gmail.com>
Message-ID: <20151221032820.GI7692@hezmatt.org>

On Sun, Dec 20, 2015 at 09:23:04PM -0500, Chuck Church wrote:
> 	I agree that a /48 or /56 being reserved for business
> customers/sites is reasonable.  But for residential use, I'm having a hard
> time believing multi-subnet home networks are even remotely common outside
> of networking folk such as the NANOG members.  A lot of recent IPv4 devices
> such as smart TVs have the ability to auto-discover things they can talk to
> on the network.  If we start segmenting our home networks to keep toasters
> from talking to thermostats, doesn't this end up meaning your average home
> user will need to be proficient in writing FW rules?  Bridging an entire
> house network isn't that bad.

Depends on how many devices you have on it.  Once you start filling your
home with Internet of Unpatchable Security Holes devices, having everything
on a single ethernet segment might start to get a little...  noisy.

Thankfully, IPv6 has well-defined multicast scopes, which makes it trivially
easy to do cross-L2-segment service discovery without needing to resort to
manually berking around with firewall rules.

- Matt


From randy.fischer at gmail.com  Mon Dec 21 03:34:16 2015
From: randy.fischer at gmail.com (Randy Fischer)
Date: Sun, 20 Dec 2015 22:34:16 -0500
Subject: Nat
In-Reply-To: <849025565.4913.1450667823465.JavaMail.mhammett@ThunderFuck>
References: <4796c7cb3fd76240964a8416525cc00d@mail.dessus.com>
 <849025565.4913.1450667823465.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAGXkcm6kQtKKi26Ox-gxD-9hKfL7aX5OYroyp7zhiNPh+ahS+Q@mail.gmail.com>

On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett <nanog at ics-il.net> wrote:

> Most people couldn't care less and just want the Internet on their device
> to work.


Well, if the best practice for CPE routers included as a matter of course
the subnets "connected to internet", "local only (e.g. IoT)" and "guest
network", and if they just worked,  then they wouldn't mind that either.

A friend of mine used to refer to this as 'refrigerator consciousness" - he
was a gearhead, so it was a pejorative.  Instead, I think of it as a design
goal.

-Randy Fischer

From nanog at ics-il.net  Mon Dec 21 03:36:39 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 20 Dec 2015 21:36:39 -0600 (CST)
Subject: Nat
In-Reply-To: <CAGXkcm6kQtKKi26Ox-gxD-9hKfL7aX5OYroyp7zhiNPh+ahS+Q@mail.gmail.com>
Message-ID: <315532451.4960.1450669073224.JavaMail.mhammett@ThunderFuck>

We can't get people to use passwords judiciously (create them at all for WiFi, change them, use more than one, etc.) and now you want them to manage networks? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

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

From: "Randy Fischer" <randy.fischer at gmail.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "North American Network Operators Group" <nanog at nanog.org> 
Sent: Sunday, December 20, 2015 9:34:16 PM 
Subject: Re: Nat 





On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog at ics-il.net > wrote: 


Most people couldn't care less and just want the Internet on their device to work. 




Well, if the best practice for CPE routers included as a matter of course the subnets "connected to internet", "local only (e.g. IoT)" and "guest network", and if they just worked, then they wouldn't mind that either. 


A friend of mine used to refer to this as 'refrigerator consciousness" - he was a gearhead, so it was a pejorative. Instead, I think of it as a design goal. 


-Randy Fischer 





From marka at isc.org  Mon Dec 21 03:40:50 2015
From: marka at isc.org (Mark Andrews)
Date: Mon, 21 Dec 2015 14:40:50 +1100
Subject: Nat
In-Reply-To: Your message of "Sun, 20 Dec 2015 21:23:04 -0500."
 <00e801d13b96$873e1120$95ba3360$@gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
 <20151218004613.BB9483F6434F@rock.dv.isc.org>
 <00e801d13b96$873e1120$95ba3360$@gmail.com>
Message-ID: <20151221034050.2073F3F7BA70@rock.dv.isc.org>


In message <00e801d13b96$873e1120$95ba3360$@gmail.com>, "Chuck Church" writes:
> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org] 
> Sent: Thursday, December 17, 2015 7:46 PM
> To: Chuck Church <chuckchurch at gmail.com>
> Cc: 'Matthew Petach' <mpetach at netflight.com>; 'North American Network
> Operators' Group' <nanog at nanog.org>
> Subject: Re: Nat
> 
> 
> >I have a single CPE router and 3 /64's in use.  One for each of the
> wireless SSID's and one for the wired network.  This is the default for
> homenet devices.  A single /64 means you >have to bridge all the traffic.
> 
> >A single /64 has never been enough and it is time to grind that myth into
> the ground.  ISP's that say a single /64 is enough are clueless.
> 
> Mark,
> 
> 	I agree that a /48 or /56 being reserved for business
> customers/sites is reasonable.  But for residential use, I'm having a hard
> time believing multi-subnet home networks are even remotely common outside
> of networking folk such as the NANOG members.  A lot of recent IPv4 devices
> such as smart TVs have the ability to auto-discover things they can talk to
> on the network.  If we start segmenting our home networks to keep toasters
> from talking to thermostats, doesn't this end up meaning your average home
> user will need to be proficient in writing FW rules?  Bridging an entire
> house network isn't that bad.

So *you* think the ISPs should *dictate* how a user internally
splits up their network?  There is NO technical reason to NOT give
a customer multiple subnets.  Every technology supports multiple
prefixes. Even with 6rd you *can* give the user multiple subnets.
It's only lazyness (or purchasing incompetence if the BR doesn't
support multiple domains) that results in ISP's handing out single
subnets over 6rd.

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

From chuckchurch at gmail.com  Mon Dec 21 03:54:49 2015
From: chuckchurch at gmail.com (Chuck Church)
Date: Sun, 20 Dec 2015 22:54:49 -0500
Subject: Nat
In-Reply-To: <20151221032820.GI7692@hezmatt.org>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
 <20151218004613.BB9483F6434F@rock.dv.isc.org>
 <00e801d13b96$873e1120$95ba3360$@gmail.com>
 <20151221032820.GI7692@hezmatt.org>
Message-ID: <011901d13ba3$57fcac20$07f60460$@gmail.com>

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matt Palmer
Sent: Sunday, December 20, 2015 10:29 PM
To: nanog at nanog.org
Subject: Re: Nat

>Depends on how many devices you have on it.  Once you start filling your
home with Internet of Unpatchable Security Holes devices, having everything
on a single ethernet >segment might start to get a little...  noisy.

>Thankfully, IPv6 has well-defined multicast scopes, which makes it
trivially easy to do cross-L2-segment service discovery without needing to
resort to manually berking around >with firewall rules.

>- Matt

If your home is full of unpatched or compromised hosts, and they're using
these well-defined multicast scopes, doesn't that mean they can now
communicate and infect one another?  For years I've seen people on this list
insist on "NAT/PAT != firewall".   Well, a router routing everything it sees
is even less of a firewall.  I'm really not trying to be argumentative here,
but I'm just having a hard time believing Joe Sixpack will be applying
business networking principals such as micro-segmenting to a home network
with 3 to 7 devices on it.  If anything, these complexities we keep
adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing
down the general deployment of IPv6.

Chuck


From kmedcalf at dessus.com  Mon Dec 21 04:06:26 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 20 Dec 2015 21:06:26 -0700
Subject: Nat
In-Reply-To: <315532451.4960.1450669073224.JavaMail.mhammett@ThunderFuck>
Message-ID: <fd519926aff0954e828a8bb002f417b0@mail.dessus.com>


You can lead a horse to water, but you cannot make it drink.  If people choose to be the authors of their own misfortunes, that is their choice.  I know a good many folks who are not members of NANOG yet have multiple separate L2 and L3 networks to keep the "crap" isolated.

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On Behalf
> Of Mike Hammett
> Sent: Sunday, 20 December, 2015 20:37
> Cc: North American Network Operators Group
> Subject: Re: Nat
> 
> We can't get people to use passwords judiciously (create them at all for
> WiFi, change them, use more than one, etc.) and now you want them to
> manage networks?
> 
> 
> 
> 
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> ----- Original Message -----
> 
> From: "Randy Fischer" <randy.fischer at gmail.com>
> To: "Mike Hammett" <nanog at ics-il.net>
> Cc: "North American Network Operators Group" <nanog at nanog.org>
> Sent: Sunday, December 20, 2015 9:34:16 PM
> Subject: Re: Nat
> 
> 
> 
> 
> 
> On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog at ics-il.net > wrote:
> 
> 
> Most people couldn't care less and just want the Internet on their device
> to work.
> 
> 
> 
> 
> Well, if the best practice for CPE routers included as a matter of course
> the subnets "connected to internet", "local only (e.g. IoT)" and "guest
> network", and if they just worked, then they wouldn't mind that either.
> 
> 
> A friend of mine used to refer to this as 'refrigerator consciousness" -
> he was a gearhead, so it was a pejorative. Instead, I think of it as a
> design goal.
> 
> 
> -Randy Fischer
> 
> 
> 





From jason at thebaughers.com  Mon Dec 21 05:22:23 2015
From: jason at thebaughers.com (Jason Baugher)
Date: Sun, 20 Dec 2015 23:22:23 -0600
Subject: Nat
In-Reply-To: <fd519926aff0954e828a8bb002f417b0@mail.dessus.com>
References: <315532451.4960.1450669073224.JavaMail.mhammett@ThunderFuck>
 <fd519926aff0954e828a8bb002f417b0@mail.dessus.com>
Message-ID: <CAGbD49oKJpbxiGpV-0om4NKdoyhDG6t7nLjMbnhagdzfWM4pQA@mail.gmail.com>

In the real world of service providers and customers, people don't "choose
to be the authors". To choose, they would have to know the options. If I
were to randomly poll 1000 of our residential customers to ask them about
their L2/L3 networks, firewall policies, etc..., they'd have no idea what I
was talking about. The majority of our small business customers are in the
same situation. The larger businesses with their own IT staff are in a
little better shape. The network consultants in the area barely understand
these subjects better than their customers.

Whether we're talking about Joe Sixpack or John SMB, they pay for a service
and expect that service to magically work. They've used phones for years
without understanding the PSTN. We gave them cellphones without making them
understand RF/LTE/GPRS/etc.... They drive cars every day without the first
clue about how internal combustion engines work. Why should data networks
be any different? Sure, I'm oversimplifying things, but that's how
non-technical people think. They should be able to spend money on cool
and/or useful gadgets, connect those gadgets to their networks, and use
them. It's tough enough to try and explain why the neighbor's wi-fi parked
on channel 8 is an interferer. L2, L3, IPv4/6 and Multicast? Good luck.

>From a service provider perspective, I feel we have 2 choices. The first is
to spend a lot of time trying to educate our customers on how networks work
and how to manage theirs. Personally, I'd rather have my fingernails pulled
out. The second, and I feel much less likely to fail, is to spend time
developing technology and service offerings to give our customers the easy,
spoon-fed experience they're looking for - and charge them for it
accordingly.





On Sun, Dec 20, 2015 at 10:06 PM, Keith Medcalf <kmedcalf at dessus.com> wrote:

>
> You can lead a horse to water, but you cannot make it drink.  If people
> choose to be the authors of their own misfortunes, that is their choice.  I
> know a good many folks who are not members of NANOG yet have multiple
> separate L2 and L3 networks to keep the "crap" isolated.
>
> > -----Original Message-----
> > From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On
> Behalf
> > Of Mike Hammett
> > Sent: Sunday, 20 December, 2015 20:37
> > Cc: North American Network Operators Group
> > Subject: Re: Nat
> >
> > We can't get people to use passwords judiciously (create them at all for
> > WiFi, change them, use more than one, etc.) and now you want them to
> > manage networks?
> >
> >
> >
> >
> > -----
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > ----- Original Message -----
> >
> > From: "Randy Fischer" <randy.fischer at gmail.com>
> > To: "Mike Hammett" <nanog at ics-il.net>
> > Cc: "North American Network Operators Group" <nanog at nanog.org>
> > Sent: Sunday, December 20, 2015 9:34:16 PM
> > Subject: Re: Nat
> >
> >
> >
> >
> >
> > On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog at ics-il.net >
> wrote:
> >
> >
> > Most people couldn't care less and just want the Internet on their device
> > to work.
> >
> >
> >
> >
> > Well, if the best practice for CPE routers included as a matter of course
> > the subnets "connected to internet", "local only (e.g. IoT)" and "guest
> > network", and if they just worked, then they wouldn't mind that either.
> >
> >
> > A friend of mine used to refer to this as 'refrigerator consciousness" -
> > he was a gearhead, so it was a pejorative. Instead, I think of it as a
> > design goal.
> >
> >
> > -Randy Fischer
> >
> >
> >
>
>
>
>
>

From mpalmer at hezmatt.org  Mon Dec 21 05:49:38 2015
From: mpalmer at hezmatt.org ('Matt Palmer')
Date: Mon, 21 Dec 2015 16:49:38 +1100
Subject: Nat
In-Reply-To: <011901d13ba3$57fcac20$07f60460$@gmail.com>
References: <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
 <20151218004613.BB9483F6434F@rock.dv.isc.org>
 <00e801d13b96$873e1120$95ba3360$@gmail.com>
 <20151221032820.GI7692@hezmatt.org>
 <011901d13ba3$57fcac20$07f60460$@gmail.com>
Message-ID: <20151221054938.GL7692@hezmatt.org>

On Sun, Dec 20, 2015 at 10:54:49PM -0500, Chuck Church wrote:
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matt Palmer
> >Depends on how many devices you have on it.  Once you start filling your
> >home with Internet of Unpatchable Security Holes devices, having everything
> >on a single ethernet >segment might start to get a little...  noisy.
> 
> >Thankfully, IPv6 has well-defined multicast scopes, which makes it
> >trivially easy to do cross-L2-segment service discovery without needing to
> >resort to manually berking around >with firewall rules.
> 
> If your home is full of unpatched or compromised hosts, and they're using
> these well-defined multicast scopes, doesn't that mean they can now
> communicate and infect one another?

No, multicast for discovery doesn't necessarily mean that the application
traffic can also pass.  The discovery multicast packets could be filtered at
any point within the network, also.

However, access control isn't what you asked about.  You claimed that
multiple L2 segments broke service discovery, and I refuted that point.

> For years I've seen people on this list
> insist on "NAT/PAT != firewall".   Well, a router routing everything it sees
> is even less of a firewall.

Correct.  However, nowhere did I suggest that a router should be routing
absolutely everything it sees.

> I'm really not trying to be argumentative here,

And yet, you're doing an awfully good job of being argumentative, about a
subject you really don't seem to know a whole lot about.

> but I'm just having a hard time believing Joe Sixpack will be applying
> business networking principals such as micro-segmenting to a home network
> with 3 to 7 devices on it.  If anything, these complexities we keep
> adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing
> down the general deployment of IPv6.

Yes, it's a pity that people who refuse to learn about the new features that
IPv6 provides keep trying to shoehorn IPv6 into their legacy mindset, but
there's not a whole lot the rest of us can do about that.

- Matt


From bortzmeyer at nic.fr  Mon Dec 21 08:31:37 2015
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 21 Dec 2015 09:31:37 +0100
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <20151218082811.GA13639@nic.fr>
References: <20151218082811.GA13639@nic.fr>
Message-ID: <20151221083137.GB8797@nic.fr>

On Fri, Dec 18, 2015 at 09:28:11AM +0100,
 Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote 
 a message of 6 lines which said:

> http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554

The password for the first backdoor (the one regarding telnet/SSH
access) has been published recently:

https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor

Shodan finds 26000 ScreenOS machines reachable from the Internet. It
will be a small botnet :-)

From mcn4 at leicester.ac.uk  Mon Dec 21 11:00:28 2015
From: mcn4 at leicester.ac.uk (Matthew Newton)
Date: Mon, 21 Dec 2015 11:00:28 +0000
Subject: Nat
In-Reply-To: <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
Message-ID: <20151221110028.GA35546@rootmail.cc.le.ac.uk>

Hi,

On Sat, Dec 19, 2015 at 03:03:18PM +0100, Sander Steffann wrote:
> > The mix of having to do this crazy thing of gateway announcements
> > from one place, DNS from somewhere else, possibly auto-assigning
> > addresses from a router, but maybe getting them over DHCPv6. It's
> > just confusing and unnecessary and IMHO isn't helpful for
> > persuading people to move to IPv6. Especially when everyone
> > already understands DHCP in the v4 world.
> 
> Have you ever tried to deploy IPv6 (even if only in a lab
> environment)? I have worked with several companies (ISP and
> enterprise) and once they stop thinking "I want to do everything
> in IPv6 in exactly the same way as I have always done in IPv4"
> and actually look at the features that IPv6 provides them they
> are usually much happier with IPv6 than they were with IPv4.

I've been running IPv6 for over 10 years. RAs and SLAAC. Doesn't
affect my previous comment. :)

IPv6 should by all means recommend certain technologies that are
"better" in an idealogical world. Not having one small feature
that makes it harder for people to deploy (for whatever the
reason) does't help the cause.

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>

From A.L.M.Buxey at lboro.ac.uk  Mon Dec 21 11:51:56 2015
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 21 Dec 2015 11:51:56 +0000
Subject: Nat
In-Reply-To: <20151221110028.GA35546@rootmail.cc.le.ac.uk>
References: <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org>
 <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <D299E276.D1593%Lee@asgard.org>
 <20151219002105.GB58695@rootmail.cc.le.ac.uk>
 <5B66F13D-DE61-446F-8649-2CB970F2611E@steffann.nl>
 <20151221110028.GA35546@rootmail.cc.le.ac.uk>
Message-ID: <20151221115156.GC21143@lboro.ac.uk>

Hi,

> > > persuading people to move to IPv6. Especially when everyone
> > > already understands DHCP in the v4 world.

<snip>

> > enterprise) and once they stop thinking "I want to do everything
> > in IPv6 in exactly the same way as I have always done in IPv4"

exactly.

as my thoughts often gather at any IPv6 deployment event I go to

"stop trying to shape IPv6 into your IPv4 model"


yes, there are annoyances...like older routers/clients not supporting
extensions to allow DNS/NTP etc from being fed in SLAAC...and clients
only supporting SLAAC and not DHCPv6 etc etc  but if you just SLAAC/DHCPv6
into your dual-stack environment then silly clients still get things via 
DHCPv4....and you start getting IPv6 connectivity...and then work through
the NEXT part.

more effort should be spent on eg address management and network topology.
the client stuff is easy

THEN we get to the stuff we should be looking at and expending more effort
on... not 'how do I deploy IPv6?' but 'how do i switch off IPv4?'  ;-)

hopefully 2016 will be the year when more sites have IPv6-only networks 
on their enterprise networks with eg 464XLAT etc 

alan

From nanog at ics-il.net  Mon Dec 21 12:48:24 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 21 Dec 2015 06:48:24 -0600 (CST)
Subject: Nat
In-Reply-To: <fd519926aff0954e828a8bb002f417b0@mail.dessus.com>
Message-ID: <685106065.61.1450702165062.JavaMail.mhammett@ThunderFuck>

It simply is not common and will not become common. Not everyone is a network engineer. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Keith Medcalf" <kmedcalf at dessus.com> 
To: nanog at nanog.org 
Sent: Sunday, December 20, 2015 10:06:26 PM 
Subject: RE: Nat 


You can lead a horse to water, but you cannot make it drink. If people choose to be the authors of their own misfortunes, that is their choice. I know a good many folks who are not members of NANOG yet have multiple separate L2 and L3 networks to keep the "crap" isolated. 

> -----Original Message----- 
> From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com at nanog.org] On Behalf 
> Of Mike Hammett 
> Sent: Sunday, 20 December, 2015 20:37 
> Cc: North American Network Operators Group 
> Subject: Re: Nat 
> 
> We can't get people to use passwords judiciously (create them at all for 
> WiFi, change them, use more than one, etc.) and now you want them to 
> manage networks? 
> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> ----- Original Message ----- 
> 
> From: "Randy Fischer" <randy.fischer at gmail.com> 
> To: "Mike Hammett" <nanog at ics-il.net> 
> Cc: "North American Network Operators Group" <nanog at nanog.org> 
> Sent: Sunday, December 20, 2015 9:34:16 PM 
> Subject: Re: Nat 
> 
> 
> 
> 
> 
> On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog at ics-il.net > wrote: 
> 
> 
> Most people couldn't care less and just want the Internet on their device 
> to work. 
> 
> 
> 
> 
> Well, if the best practice for CPE routers included as a matter of course 
> the subnets "connected to internet", "local only (e.g. IoT)" and "guest 
> network", and if they just worked, then they wouldn't mind that either. 
> 
> 
> A friend of mine used to refer to this as 'refrigerator consciousness" - 
> he was a gearhead, so it was a pejorative. Instead, I think of it as a 
> design goal. 
> 
> 
> -Randy Fischer 
> 
> 
> 






From surfer at mauigateway.com  Mon Dec 21 15:12:29 2015
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 21 Dec 2015 07:12:29 -0800
Subject: Nat
Message-ID: <20151221071229.9752389D@m0087796.ppops.net>



--- chuckchurch at gmail.com wrote:
From: "Chuck Church" <chuckchurch at gmail.com>

but I'm just having a hard time believing Joe Sixpack will be applying
business networking principals such as micro-segmenting to a home network
with 3 to 7 devices on it.  If anything, these complexities we keep
----------------------------------------


Won't the devices themselves begin to do that based on minimal
or no input from Joe?

scott

From jlewis at lewis.org  Mon Dec 21 16:51:35 2015
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 21 Dec 2015 11:51:35 -0500 (EST)
Subject: Nat
In-Reply-To: <011901d13ba3$57fcac20$07f60460$@gmail.com>
References: <5E0884E1-952F-434D-B2F9-FDA87814A7EC@hrins.net>
 <D29747F0.11F8D4%jason_livingood@cable.comcast.com>
 <770D0609-0A3A-4142-854F-210410682D69@isc.org>
 <CAAbPayKVqf7r=77Jjks8WJOgm5eqFpD4OqUyTopKBPa2TRvQNA@mail.gmail.com>
 <6B6686E3-D30B-4E42-8F06-F8077D62894F@isc.org> <m24mfhj2d1.wl%randy@psg.com>
 <CAEmG1=oX3uf4OGg586SiBJxQDZoNurNicx-K0Ouaw0MESwwnNQ@mail.gmail.com>
 <01de01d13900$fe364dd0$faa2e970$@gmail.com>
 <20151218004613.BB9483F6434F@rock.dv.isc.org>
 <00e801d13b96$873e1120$95ba3360$@gmail.com>
 <20151221032820.GI7692@hezmatt.org>
 <011901d13ba3$57fcac20$07f60460$@gmail.com>
Message-ID: <Pine.LNX.4.61.1512211142280.10544@soloth.lewis.org>

On Sun, 20 Dec 2015, Chuck Church wrote:

> insist on "NAT/PAT != firewall".   Well, a router routing everything it sees
> is even less of a firewall.  I'm really not trying to be argumentative here,
> but I'm just having a hard time believing Joe Sixpack will be applying
> business networking principals such as micro-segmenting to a home network
> with 3 to 7 devices on it.  If anything, these complexities we keep

I'm not disagreeing, but as this came up recently in another forum, I 
think you'll find that most home networks have a couple times that number 
of networked devices...once you add up computers, phones, tablets, game 
consoles, TV's & other media devices, thermostats, cameras, security 
systems, you'll probably run out of fingers and toes counting them all in 
a typical home network.  The average home user wouldn't know what you were 
talking about though if you asked them if they wanted to put various 
device classes in different subnets.  They just want it all to work...and 
keeping it all working means providing at least a default level of 
security/filtering that prevents all of it from being directly accessed by 
remote scanners looking to exploit insecure systems.

> adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing
> down the general deployment of IPv6.

>From my perspective, ISP's not offering v6 is what's slowing down 
deployment.  My home cable provider still does not.

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

From A.L.M.Buxey at lboro.ac.uk  Mon Dec 21 16:55:43 2015
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 21 Dec 2015 16:55:43 +0000
Subject: Nat
In-Reply-To: <20151221071229.9752389D@m0087796.ppops.net>
References: <20151221071229.9752389D@m0087796.ppops.net>
Message-ID: <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>

I'm surprised that noone of the home wifi router folk haven't cornered the market on that one in terms of client separation.  Most people don't need the devices to talk to each other so by default all ports on different VLANs .. 192.168.0-8.x etc

Internet of things security out of the box. Web interface to change port membership for those that DO need inter device access

Or maybe there are such defaults out there from some suppliers i'm not familiar with? :)

alan

From johnl at iecc.com  Mon Dec 21 17:12:57 2015
From: johnl at iecc.com (John Levine)
Date: 21 Dec 2015 17:12:57 -0000
Subject: Nat
In-Reply-To: <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>
Message-ID: <20151221171257.35863.qmail@ary.lan>

In article <4102D692-A315-4C38-A2CB-54F96999E251 at lboro.ac.uk> you write:
>I'm surprised that noone of the home wifi router folk haven't cornered the market on that
>one in terms of client separation.  Most people don't need the devices to talk to each
>other so by default all ports on different VLANs .. 192.168.0-8.x etc

Some of the cheap Linksys routers I've seen appear to be able to put different
addresses and different VLANs on the different ethernet ports.  I don't think
it could do multiple VLANs on the same port, and even if it could, you'd have
to be impressively obsessive to configure all the MAC addresses by hand.


From dot at dotat.at  Mon Dec 21 17:18:37 2015
From: dot at dotat.at (Tony Finch)
Date: Mon, 21 Dec 2015 17:18:37 +0000
Subject: Nat
In-Reply-To: <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>
References: <20151221071229.9752389D@m0087796.ppops.net>
 <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>
Message-ID: <alpine.LSU.2.00.1512211716240.959@hermes-2.csi.cam.ac.uk>

Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:

> Most people don't need the devices to talk to each other

A lot of home networking uses mDNS - partitioning off devices will break
things like printing and chromecast and using your phone as a remote
control for your media players, etc. ad nauseam.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Northwest Fitzroy, Sole, Lundy, Fastnet, Irish Sea, Shannon: Mainly
southwesterly 6 to gale 8, occasionally severe gale 9. Rough or very rough,
becoming very rough or high, except in Irish Sea. Occasional rain. Moderate or
poor, occasionally good.

From dougb at dougbarton.us  Mon Dec 21 17:41:46 2015
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 21 Dec 2015 09:41:46 -0800
Subject: [CVE-2015-7755] Backdoor in Juniper/ScreenOS
In-Reply-To: <20151218082811.GA13639@nic.fr>
References: <20151218082811.GA13639@nic.fr>
Message-ID: <567839DA.8090102@dougbarton.us>

https://www.schneier.com/blog/archives/2015/12/back_door_in_ju.html

From marka at isc.org  Mon Dec 21 19:12:42 2015
From: marka at isc.org (Mark Andrews)
Date: Tue, 22 Dec 2015 06:12:42 +1100
Subject: Nat
In-Reply-To: Your message of "Mon, 21 Dec 2015 16:55:43 -0000."
 <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>
References: <20151221071229.9752389D@m0087796.ppops.net>
 <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>
Message-ID: <20151221191242.CBEE43F87CB1@rock.dv.isc.org>


We already have CPE vendors shipping with "guest" ssids.  These
require a seperate /64 and are usually treated as external to the
home network.  With IPv4 you grab a seperate chunck of rfc1918 space
and nat that as well as the main chuck of space.  For IPv6 you need
multiple /64s from the ISP.  A single /64 is not enough.  This is
all done with a point and click interface.

If you are a ISP that supplies a single /64 then you really should
stop showing your lack of clue to all and sundry by supplying
multiple /64s.

If you are a ISP that doesn't supply IPv6 at all then you really
are not doing your job as a ISP.

Mark

In message <4102D692-A315-4C38-A2CB-54F96999E251 at lboro.ac.uk>, Alan Buxey write
s:
> I'm surprised that noone of the home wifi router folk haven't cornered the ma
> rket on that one in terms of client separation.  Most people don't need the d
> evices to talk to each other so by default all ports on different VLANs .. 19
> 2.168.0-8.x etc
> 
> Internet of things security out of the box. Web interface to change port memb
> ership for those that DO need inter device access
> 
> Or maybe there are such defaults out there from some suppliers i'm not famili
> ar with? :)
> 
> alan
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From marka at isc.org  Mon Dec 21 19:42:26 2015
From: marka at isc.org (Mark Andrews)
Date: Tue, 22 Dec 2015 06:42:26 +1100
Subject: Nat
In-Reply-To: Your message of "Mon, 21 Dec 2015 17:18:37 -0000."
 <alpine.LSU.2.00.1512211716240.959@hermes-2.csi.cam.ac.uk>
References: <20151221071229.9752389D@m0087796.ppops.net>
 <4102D692-A315-4C38-A2CB-54F96999E251@lboro.ac.uk>
 <alpine.LSU.2.00.1512211716240.959@hermes-2.csi.cam.ac.uk>
Message-ID: <20151221194226.150103F881B0@rock.dv.isc.org>


In message <alpine.LSU.2.00.1512211716240.959 at hermes-2.csi.cam.ac.uk>, Tony Fin
ch writes:
> Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:
> 
> > Most people don't need the devices to talk to each other
> 
> A lot of home networking uses mDNS - partitioning off devices will break
> things like printing and chromecast and using your phone as a remote
> control for your media players, etc. ad nauseam.

But with a little help from the router it still works.
 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> Northwest Fitzroy, Sole, Lundy, Fastnet, Irish Sea, Shannon: Mainly
> southwesterly 6 to gale 8, occasionally severe gale 9. Rough or very rough,
> becoming very rough or high, except in Irish Sea. Occasional rain. Moderate o
> r
> poor, occasionally good.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From owen at delong.com  Mon Dec 21 21:24:03 2015
From: owen at delong.com (Owen DeLong)
Date: Mon, 21 Dec 2015 13:24:03 -0800
Subject: Nat
In-Reply-To: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
Message-ID: <4D6D73DE-39F3-432D-B2E3-65FB8FD77BBC@delong.com>


> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog at ics-il.net> wrote:
> 
> There's nothing that can really be done about it now and I certainly wasn't able to participate when these things were decided. 
> 
> However, keeping back 64 bits for the host was a stupid move from the beginning. We're reserving 64 bits for what's currently a 48 bit number. You can use every single MAC address whereas IPS are lost to subnetting and other such things. I could have seen maybe holding back 56 bits for the host if for some reason we need to replace the current system of MAC addresses at some point before IPv6 is replaced. 

That?s not what happened. What happened was that we added 64 bits to the address space (the original thought was a 64 bit address space) in order to allow for simplified host autoconf based on EUI-64 addresses. It did seem like a good idea at the time.

At the time, IEEE had realized that they were running out of EUI-48 addresses and had decided that the next generation would be EUI-64 and in fact, if you look at newer interfaces (e.g. firewire) you will see that they do, in fact, ship with EUI-64 addresses baked in. Given that IEEE had already decided on EUI-64 as the way forward for ?MAC? addresses, it seems to me that 64 bits makes more sense than 56.

> There may be address space to support it, but is there nimble boundary space for it?

I think you mean nibble-boundary space for it and the answer is yes.

> The idea that there's a possible need for more than 4 bits worth of subnets in a home is simply ludicrous and we have people advocating 16 bits worth of subnets. How does that compare to the entire IPv4 Internet? 

I have more than 16 subnets in my house, so I can cite at least one house with need for more than 4 bits just in a hand-coded network.

Considering the future possibilities for automated topological hierarchies using DHCP-PD with dynamic joining and pruning routers, I think 8 bits is simply not enough to allow for the kind of flexibility we?d like to give to developers, so 16 bits seems like a reasonable compromise.

> There is little that can be done about much of this now, but at least we can label some of these past decisions as ridiculous and hopefully a lesson for next time. 


TL;DR version: Below is a detailed explanation of why giving a /48 to every residence is harmless and just makes sense.

If you find that adequate, stop here. If you are still skeptical, read on?

Except that the decisions weren?t ridiculous. They not only made sense then, but for the most part, if you consider a bigger picture and a wider longer-term view than just what we are experiencing today, they make even more sense.

First, unlike the 100 gallon or 10,000 gallon fuel tank analogy, extra bits added to the address space come at a near zero cost, so adding them if there?s any potential use is what I would classify as a no-brainer. At the time IPv6 was developed, 64-bit processors were beginning to be deployed and there was no expectation that we?d see 128-bit processors. As such, 128 bit addresses were cheap and easily implementable in anticipated hardware and feasible in existing hardware, so 128-bits made a lot of sense from that perspective.

From the 64-bits we were considering, adding another 64 bits so that we could do EUI-based addressing also made a lot of sense. 48-bits didn?t make much sense because we already knew that IEEE was looking at moving from 48-bits to 64-bits for EUI addresses. A very simple mechanism for translating EUI-48 into a valid unique EUI-64 address was already documented by IEEE (Add an FF suffix to the OUI portion and an EE Prefix to the ESI portion, and ensure that the Locally Generated bit is 1). As such, a locally generated 02:a9:3e:8c:7f:1d address becomes 02:a9:3e:ff:ee:8c:7f:1d while a registered address ac:87:a3:23:45:67 would become ae:87:a3:ff:fe:23:45:67.

The justification for 16 bits of subnetting is a little more pie-in-the-sky, I?ll grant you, but given a 64-bit network numbering space, there?s really no disadvantage to giving out /48s and very little (or no) advantage to giving out smaller chunks to end-sites, regardless of their residential or commercial nature.

Let?s assume that ISPs come in essentially 3 flavors. MEGA (The Verizons, AT&Ts, Comcasts, etc. of the world) having more than 5 million customers, LARGE (having between 100,000and 5 million customers) and SMALL (having fewer than 100,000 customers).

Let?s assume the worst possible splits and add 1 nibble to the minimum needed for each ISP and another nibble for overhead.

Further, let?s assume that 7 billion people on earth all live in individual households and that each of them runs their own small business bringing the total customer base worldwide to 14 billion.

If everyone subscribes to a MEGA and each MEGA serves 5 million customers, we need 2,800 MEGA ISPs. Each of those will need 5,000,000 /48s which would require a /24. Let?s give each of those an additional 8 bits for overhead and bad splits and say each of them gets a /16. That?s 2,800 out of
65,536 /16s and we?ve served every customer on the planet with a lot of extra overhead, using approximately 4% of the address space.

Now, let?s make another copy of earth and serve everyone on a LARGE ISP with only 100,000 customers each. This requires  140,000 LARGE ISPs each of whom will need a /28 (100,000 /48s doesn?t fit in a /32, so we bump them up to /28). Adding in bad splits and overhead at a nibble each, we give each of them a /20. 140,000 /20s out of 1,048,576 total of which we used 44,800 for the MEGA ISPS leaves us with 863,776 /20s still available. We?ve now managed to burn approximately 18% of the total address space and we?ve served the entire world twice.

Finally, let us serve every customer in the world using a small ISP. Let?s assume that each small ISP only serves about 5,000 customers. For 5,000 customers, we would need a /32. Backing that off two nibbles for bad splits and overhead, we give each one a /24.

This will require 2,800,000 /24s. (I realize lots of ISPs server fewer than 5,000 customers, but those ISPs also don?t serve a total of 14 billion end sites,
so I think in terms of averages, this is not an unreasonable place to throw the dart).

There are 16,777,216 /24s in total, but we?ve already used 2,956,800 for the MEGA and LARGE ISPs, bringing our total utilization to 5,756,800 /24s.

We have now built three complete copies of the internet with some really huge assumptions about number of households and businesses added in and we still have only used roughly 34% of the total address space, including nibble boundary round-ups and everything else.

I propose the following: Let?s give out /48s for now. If we manage to hit either of the following two conditions in less than 50 years, I will happily (assuming I am still alive when it happens) assist in efforts to shift to more restrictive allocations.

	Condition 1: If any RIR fully allocates more than 3 /12s worth of address space total
	Condition 2: If we somehow manage to completely allocate all of 2000::/3

I realize that Condition 2 is almost impossible without meeting condition 1 much much earlier, but I put it there just in case.

If we reach a point where EITHER of those conditions becomes true, I will be happy to support more restrictive allocation policy. In the worst case, we have roughly 3/4 of the address space still unallocated when we switch to more restrictive policies. In the case of condition 1, we have a whole lot more. (At most we?ve used roughly 15[1] of the 512 /12s in 2000::/3 or less than 0.004% of the total address space.

My bet is that we can completely roll out IPv6 to everyone with every end-site getting a /48 and still not burn more than 0.004% of the total address space.

If anyone can prove me wrong, then I?ll help to push for more restrictive policies. Until then, let?s just give out /48s and stop hand wringing about how wasteful it is. Addresses that sit in the free pool beyond the end of the useful life of a protocol are also wasted.


Owen



[1] This figure could go up if we add more RIRs. However, even if we double it, we move from 0.004% to 0.008% utilization risk with 10 RIRs.


> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> ----- Original Message -----
> 
> From: "Daniel Corbe" <corbe at corbe.net> 
> To: "Mike Hammett" <nanog at ics-il.net> 
> Cc: "Mark Andrews" <marka at isc.org>, "North American Network Operators' Group" <nanog at nanog.org> 
> Sent: Saturday, December 19, 2015 10:55:03 AM 
> Subject: Re: Nat 
> 
> Hi. 
> 
>> On Dec 19, 2015, at 11:41 AM, Mike Hammett <nanog at ics-il.net> wrote: 
>> 
>> "A single /64 has never been enough and it is time to grind that 
>> myth into the ground. ISP's that say a single /64 is enough are 
>> clueless." 
>> 
>> 
>> 
>> LLLLOOOOOOLLLLL 
>> 
>> 
>> A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. 
>> 
>> 
> 
> You?re being deliberately flippant. 
> 
> There are technical reasons why a single /64 is not enough for an end user. A lot of it has to do with the way auto configuration works. The lower 64 bits of the IP address are essentially host entropy. EUI-64 (for example) is a 64 bit number derived from the mac address of the NIC. 
> 
> The requirement for the host portion of the address to be 64 bits long isn?t likely to change. Which means a /64 is the smallest possible prefix that can be assigned to an end user and it limits said end user to a single subnet. 
> 
> Handing out a /56 or a /48 allows the customer premise equipment to have multiple networks behind it. It?s a good practice and there?s certainly enough address space available to support it. 
> 
> 
> 


From owen at delong.com  Mon Dec 21 21:29:48 2015
From: owen at delong.com (Owen DeLong)
Date: Mon, 21 Dec 2015 13:29:48 -0800
Subject: Nat
In-Reply-To: <2C7192B7-C2AF-46BB-88C6-1F0C7B27C747@hammerfiber.com>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
 <A8F8A1A3-DB06-4065-ACE4-9862F5DAF0D2@hammerfiber.com>
 <CAEmG1=rFr-HFV5JNM2W1Bf_UbnUtXa6HvJ1d_R+nfeZuQSyBUQ@mail.gmail.com>
 <2C7192B7-C2AF-46BB-88C6-1F0C7B27C747@hammerfiber.com>
Message-ID: <748287DD-5C07-4737-9463-F5A1713D2045@delong.com>

Not quite true?

"What happens when we have to make an incompatible change to the fundamental packet header?? is the real challenge.

It happens that in the case of IPv4, we didn?t hit that particular wall until we needed a larger address.

In IPv6, it will probably be something related to the ability to scale the number of routing destinations if I had to guess, but it?s so far in the future that predicting it now is somewhere between highly suspect and utterly impossible.

There will be a next time? There is _ALWAYS_ a next time with any human system. We always end up changing how we use things and then needing to adapt those things to those changes. That?s not a bad thing. Hopefully we will learn some lessons from this process and make the next transition somewhat less painful. However, most of those lessons are behavioral and judging by our progress on climate change, I?m not convinced we?ve learned anything at all about addressing problems before they reach crisis status.


Owen
> 
> I?m only going to say one more thing on this subject because this is essentially a side bar that has very little to do with the subject matter of the OP.  
> 
> If we hadn?t run out of address space we?d still be trying to fix IPv4.  The numbers don?t lie.  It?s not very likely that we?re going to be space constrained on the IPv6 Internet like we are on the IPv4 internet.  Nobody is going to want to repeat the pain of the last 17 years of trying to convince people to run IPv6.
> 
> Just about every technical challenge with the underlying protocol stack is fixable.  Except for one: what happens when we run out addresses.  For all of its flaws, IPv6 addresses this one particular issue quite well.
> 
> 


From surfer at mauigateway.com  Mon Dec 21 21:58:53 2015
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 21 Dec 2015 13:58:53 -0800
Subject: Nat
Message-ID: <20151221135853.9752738E@m0087796.ppops.net>



--- jared at puck.nether.net wrote:
From: Jared Mauch <jared at puck.nether.net>

I'd love to hear from people on what they perceive and 
the real barriers they have seen with regards to IPv6 
in your environment. 
-------------------------------------------------------

In the enterprise; managers that don't (and don't want to)
understand and say things like "present a business plan and
we might consider it.  In the mean time I need everyone to 
focus on <insert short-term need here>."  The things a 
netgeek has to put up with when (s)he doesn't want to move.

scott

From hannigan at gmail.com  Mon Dec 21 22:29:48 2015
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 21 Dec 2015 17:29:48 -0500
Subject: IPv4 subnets for lease?
In-Reply-To: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
References: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
Message-ID: <CAMDXq5O1ehd2o_GS_X0XTXqhOVJJSKkDdob2M97tW4DEAksQ+A@mail.gmail.com>

On Thu, Dec 17, 2015 at 9:31 PM, Nick Ellermann <nellermann at broadaspect.com>
wrote:

> We have customers asking to lease IP space for BGP transit with us and
> other peers. But they are struggling to get at a minimum even a Class C,
> even though they have their own ASN. We don't have large amounts of free
> IPv4 space to lease out to a single customer in most cases anymore. Hope to
> at least introduce these customers to some contacts that may be able to
> help.
> Do we know of any reputable sources that are leasing or selling IPv4
> subnets as small as a /24 to satisfy their diversity needs? Thanks!
>
>

I'm going to stay focused on your question.

There are many methods to obtain additional IPv4 address space.

o You can still use an RIR and get a last /22 in the RIPE region provided
you follow their rules, and no, you do not have to be in Europe.

Read carefully:

     https://www.ripe.net/participate/policies/proposals/2013-03

o You can use a marketplace where buyers and sellers live in harmony to
conduct buy and sell (bid, offer) transactions. I find the folks at Addrex
very knowledgeable www.addrex.net

o You can use a auction site. The folks at Hilco Streambank seem to be able
to keep theirs running at www.ipv4auctions.com

The above are not endorsements. There are many others. Some are credible.
Some are interesting. YMMV.

This thread will now self-destruct.

Best,

-M<

From mark.tinka at seacom.mu  Tue Dec 22 05:57:37 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 22 Dec 2015 07:57:37 +0200
Subject: Nat
In-Reply-To: <CAGbD49oKJpbxiGpV-0om4NKdoyhDG6t7nLjMbnhagdzfWM4pQA@mail.gmail.com>
References: <315532451.4960.1450669073224.JavaMail.mhammett@ThunderFuck>
 <fd519926aff0954e828a8bb002f417b0@mail.dessus.com>
 <CAGbD49oKJpbxiGpV-0om4NKdoyhDG6t7nLjMbnhagdzfWM4pQA@mail.gmail.com>
Message-ID: <5678E651.6060002@seacom.mu>



On 21/Dec/15 07:22, Jason Baugher wrote:

>
> >From a service provider perspective, I feel we have 2 choices. The first is
> to spend a lot of time trying to educate our customers on how networks work
> and how to manage theirs. Personally, I'd rather have my fingernails pulled
> out. The second, and I feel much less likely to fail, is to spend time
> developing technology and service offerings to give our customers the easy,
> spoon-fed experience they're looking for - and charge them for it
> accordingly.

+1.

Car manufacturers gave us ABS, instead of lengthy manuals about how to
brake effectively in the wet.

Mark.

From bjorn at mork.no  Tue Dec 22 09:21:22 2015
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 22 Dec 2015 10:21:22 +0100
Subject: Nat
In-Reply-To: <4D6D73DE-39F3-432D-B2E3-65FB8FD77BBC@delong.com> (Owen DeLong's
 message of "Mon, 21 Dec 2015 13:24:03 -0800")
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
 <4D6D73DE-39F3-432D-B2E3-65FB8FD77BBC@delong.com>
Message-ID: <8737uurg8d.fsf@nemi.mork.no>

Owen DeLong <owen at delong.com> writes:
>> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog at ics-il.net> wrote:
>
>> The idea that there's a possible need for more than 4 bits worth of
>> subnets in a home is simply ludicrous and we have people advocating
>> 16 bits worth of subnets. How does that compare to the entire IPv4
>> Internet?
>
> I have more than 16 subnets in my house, so I can cite at least one
> house with need for more than 4 bits just in a hand-coded network.
>
> Considering the future possibilities for automated topological
> hierarchies using DHCP-PD with dynamic joining and pruning routers, I
> think 8 bits is simply not enough to allow for the kind of flexibility
> we?d like to give to developers, so 16 bits seems like a reasonable
> compromise.

Thanks for summarizing why /48 for everybody is possible.  But I fear
that is not helping much against arguments based on "need". I believe it
is difficult to argue that anyone needs any IP address at all, given
that there are lots of people in the world who seem to survive just fine
without one...

So, with that sorted out, let's consider what you can do with 16 bits of
subnets.  One example is checksum neutral prefix translation (RFC6296)
without touching the interface id bits . Let's say you have two upstream
ISPs handing you the prefixes A/48 and B/56.  Neither offer any
multihoming support to residential users and both do BCP38 of course. So
you use B/56 internally and do prefix translation to allow your router
to select upstream without involving the clients.  Thanks to the A/48
from the first ISP, you are able to choose a set of 256 (or possibly 255
since 0xffff cannot be used) checksum neutral subnet pairs.

Yes, I know. Evil. No need. No CPE support.  Etc.

The important part is that 16 bits of subnets is enough to play
algorithmic tricks with the subnet part of your address too, whereas
this is much more difficult with fewer bits.  No, you don't need to do
it.  But you CAN.  The sparse IPv6 addressing model is about opening up
possibilities.  Note that those possibilities includes restricting
yourself to using a single address.  You don't have to use all your 2^80
addresses :)

And for the ISPs, using /48 for every user means fewer prefix lengths to
consider for routing and address management. Sure, we manage diverse
prefix lengths in IPv4 today, but why not take advantage of this
possible simplification if we can? Only those living on bugs will object
to simpler address databases and routing filters.


Bj?rn

From fredrik at resilans.se  Tue Dec 22 09:59:49 2015
From: fredrik at resilans.se (Fredrik Widell)
Date: Tue, 22 Dec 2015 10:59:49 +0100 (CET)
Subject: [NANOG] IPv4 subnets for lease?
In-Reply-To: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
References: <1661b60868b54fe3b6a3eaaabc5c70e1@exchange.broadaspect.local>
Message-ID: <alpine.LNX.2.00.1512221053160.27653@server.resilans.se>

On Fri, 18 Dec 2015, Nick Ellermann wrote:


Hi.

We lease /24's or more to customers since many years, but as someone later in the thread commented,
spammers will use this opportunity if they can, so we limit our customers to 
Sweden nowadays, and always check their earlier reputation before leasing space.
If you have Swedish customers you are welcome to send in an application.

( http://webb.resilans.se/registry/order-eng.html )




> We have customers asking to lease IP space for BGP transit with us and other peers. But they are struggling to get at a minimum even a Class C, even though they have their own ASN. We don't have large amounts of free IPv4 space to lease out to a single customer in most cases anymore. Hope to at least introduce these customers to some contacts that may be able to help.
> Do we know of any reputable sources that are leasing or selling IPv4 subnets as small as a /24 to satisfy their diversity needs? Thanks!
>
> Sincerely,
> Nick Ellermann - CTO & VP Cloud Services
> BroadAspect
>
> E: nellermann at broadaspect.com<mailto:nellermann at broadaspect.com>
> P: 703-297-4639
> F: 703-996-4443
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>

-- 

Mvh

 	Fredrik Widell Resilans AB http://www.resilans.se/
 	mail:   info at resilans.se , fredrik at resilans.se
 	phone:  +46 8 688 11 80

From alexis at panix.com  Tue Dec 22 10:51:56 2015
From: alexis at panix.com (Alexis Rosen)
Date: Tue, 22 Dec 2015 05:51:56 -0500
Subject: Looking for VPS providers with BGP session
In-Reply-To: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
References: <83693bec3ebe4738b5558668f632788f@exchange1.ad.edsi-tech.com>
Message-ID: <7F149B86-01F3-436E-8C8E-2191E76C71B2@panix.com>

On Dec 7, 2015, at 7:40 AM, Philippe Bonvin via NANOG <nanog at nanog.org> wrote:
> Hello,
> 
> I'm looking for providers around the world who are able to provide VPS with a BGP session but it seems to be rather difficult to find. I have already found a few with WHT/bgp.he.net/google but a little help would be appreciated.
> 
> Does anyone have contact or know people who can offer such services ?
> 
> If yes, please contact me off list.
> [...]

I am apparently 2 weeks behind on reading nanog, and haven't posted here in probably 17-18 years. We offer that service.

Philippe found us last week, so thanks to whoever pointed him our way...

/a

From cb.list6 at gmail.com  Tue Dec 22 12:45:01 2015
From: cb.list6 at gmail.com (Ca By)
Date: Tue, 22 Dec 2015 04:45:01 -0800
Subject: IPv4 shutdown in mobile
Message-ID: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>

TL;DR version: the data shows you are negligent if your eyeball content
(cdn, cloud, ...) does  not support native ipv6.

With the NAT and IPv4 leasing threads lingering on, i figured it was time
for an update on how the other half live

More than 1/3 of North America mobile traffic to the top websites is end to
end ipv6
http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/

The trend is clearly growing, and as AT&T and Sprint catch up with T-Mobile
and Verizon, the acceleration to 50% should be easily achieved.
Furthermore, only one mobile carrier has iPhone dual-stacked today (afaik),
but Apple has a plan for banning ipv4-only apps and has delivered the
required features for having ipv6-only iphones in 2016 with these iOS 9.2
features

https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html

On some mobile providers, ipv6 is already dominant and ipv4 is waning. Once
iPhones updates to ipv6-only as described above, ipv4 will only be a corner
case of operations.  This comes with added benefit that ipv6 is faster :

https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/

At least in mobile, the change to ipv6 has been quick and the pace is
increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I know
many people liken ipv6 to "the boy who cried wolf", so be it, the
data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
the right metaphor was "the tortoise and the hare" or "the little engine
that could"... Or even better IPv4 is John Henry.  It was the best in its
time, but times have changed.

CB

From motamedi at cs.uoregon.edu  Tue Dec 22 16:44:06 2015
From: motamedi at cs.uoregon.edu (Reza Motamedi)
Date: Tue, 22 Dec 2015 08:44:06 -0800
Subject: interconnection costs
Message-ID: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>

Hi NANOG

We are a group of researchers and our focus is on the economy of
interconnection in the Internet. My question is mainly about the various
costs of an AS establishing a connection with another AS, including the
costs charged by the colocation providers. I am familiar with most of the
connection options such as public peering on IXP, and private peering
through xconnects. My understanding is that in addition to the cost of
transit that the smaller AS pays to the larger AS, in the former you pay a
monthly fee to establish a link to the switching fabric and then you can
connect to as many ASes that are member in the IXP, and in the later you
need to pay for as many xconnects that you need to connect to as many ASes
that you plan to peer with. Obviously in both cases there is the cost of
being in the colocation and renting a rack or whatever. What are the other
costs involved? How should the AS reach the colocation center in the first
place? I don't think every network can dig a hole an lay cables. Who should
they pay to get from one PoP to another? Do ASes have to pay for xconnect
to connect their PoP in a data center to the rest of their network?

I think there is no single answer as different businesses may have
different pricing models. I hope the discussion can help me understand the
whole ecosystem a little bit better.


Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

From jwbensley at gmail.com  Tue Dec 22 17:33:07 2015
From: jwbensley at gmail.com (James Bensley)
Date: Tue, 22 Dec 2015 17:33:07 +0000
Subject: interconnection costs
In-Reply-To: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
Message-ID: <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>

On 22 December 2015 at 16:44, Reza Motamedi <motamedi at cs.uoregon.edu> wrote:
> I think there is no single answer as different businesses may have
> different pricing models. I hope the discussion can help me understand the
> whole ecosystem a little bit better.


Hi Reza,

I have a list of example items that need to be costed in below, it is
by no means a definitive list though:

https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2&pli=1#


Cheers,
James.

From owen at delong.com  Tue Dec 22 17:47:44 2015
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Dec 2015 09:47:44 -0800
Subject: Nat
In-Reply-To: <8737uurg8d.fsf@nemi.mork.no>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
 <4D6D73DE-39F3-432D-B2E3-65FB8FD77BBC@delong.com>
 <8737uurg8d.fsf@nemi.mork.no>
Message-ID: <B0DEF559-89A7-4D6D-9A2D-8811303B9230@delong.com>


> On Dec 22, 2015, at 01:21 , Bj?rn Mork <bjorn at mork.no> wrote:
> 
> Owen DeLong <owen at delong.com> writes:
>>> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog at ics-il.net> wrote:
>> 
>>> The idea that there's a possible need for more than 4 bits worth of
>>> subnets in a home is simply ludicrous and we have people advocating
>>> 16 bits worth of subnets. How does that compare to the entire IPv4
>>> Internet?
>> 
>> I have more than 16 subnets in my house, so I can cite at least one
>> house with need for more than 4 bits just in a hand-coded network.
>> 
>> Considering the future possibilities for automated topological
>> hierarchies using DHCP-PD with dynamic joining and pruning routers, I
>> think 8 bits is simply not enough to allow for the kind of flexibility
>> we?d like to give to developers, so 16 bits seems like a reasonable
>> compromise.
> 
> Thanks for summarizing why /48 for everybody is possible.  But I fear
> that is not helping much against arguments based on "need". I believe it
> is difficult to argue that anyone needs any IP address at all, given
> that there are lots of people in the world who seem to survive just fine
> without one?

Arguments based on ?need? don?t make any sense in an IPv6 context.

Sure, we shouldn?t be so profligate in our distribution of the address pool
that we run out well before the protocol?s useful life is exhausted, but I
think I?ve shown that the current allocation policies, including /48 have
adequate protection against that occurring.

Being more restrictive just for the sake of being more restrictive doesn?t
serve any purpose. It doesn?t help anyone. As such, I just don?t understand
those arguments. If someone can show me a tangible benefit from a more
restrictive policy, I?m open to considering it, but so far, none exists.

> So, with that sorted out, let's consider what you can do with 16 bits of
> subnets.  One example is checksum neutral prefix translation (RFC6296)
> without touching the interface id bits . Let's say you have two upstream
> ISPs handing you the prefixes A/48 and B/56.  Neither offer any
> multihoming support to residential users and both do BCP38 of course. So
> you use B/56 internally and do prefix translation to allow your router
> to select upstream without involving the clients.  Thanks to the A/48
> from the first ISP, you are able to choose a set of 256 (or possibly 255
> since 0xffff cannot be used) checksum neutral subnet pairs.

That?s a really icky alternative to simple BGP multihoming (which is what
I?m currently using at home).

Of course, not the worst, but a significantly bad part of this is the provider
that?s only giving you a /56 to begin with. ;-)

> Yes, I know. Evil. No need. No CPE support.  Etc.

True that.

> The important part is that 16 bits of subnets is enough to play
> algorithmic tricks with the subnet part of your address too, whereas
> this is much more difficult with fewer bits.  No, you don't need to do
> it.  But you CAN.  The sparse IPv6 addressing model is about opening up
> possibilities.  Note that those possibilities includes restricting
> yourself to using a single address.  You don't have to use all your 2^80
> addresses :)

I completely agree.

> 
> And for the ISPs, using /48 for every user means fewer prefix lengths to
> consider for routing and address management. Sure, we manage diverse
> prefix lengths in IPv4 today, but why not take advantage of this
> possible simplification if we can? Only those living on bugs will object
> to simpler address databases and routing filters.

Again, you?re preaching to the choir.

Owen


From owen at delong.com  Tue Dec 22 17:57:27 2015
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Dec 2015 09:57:27 -0800
Subject: IPv4 shutdown in mobile
In-Reply-To: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
Message-ID: <D3164172-EEEE-4D13-8C4A-39E04C41087E@delong.com>

Does this mean you are negligent for not supporting IPv6 on my phone on your network?

My phone is perfectly capable of IPv6, yet because it doesn?t support your particular religion
about IPv4 translation, you refuse to support IPv6 on it.

When is T-Mobile going to fix their IPv6 implementation and stop ignoring the #1 market
leading phone manufacturer?

Owen

> On Dec 22, 2015, at 04:45 , Ca By <cb.list6 at gmail.com> wrote:
> 
> TL;DR version: the data shows you are negligent if your eyeball content
> (cdn, cloud, ...) does  not support native ipv6.
> 
> With the NAT and IPv4 leasing threads lingering on, i figured it was time
> for an update on how the other half live
> 
> More than 1/3 of North America mobile traffic to the top websites is end to
> end ipv6
> http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/
> 
> The trend is clearly growing, and as AT&T and Sprint catch up with T-Mobile
> and Verizon, the acceleration to 50% should be easily achieved.
> Furthermore, only one mobile carrier has iPhone dual-stacked today (afaik),
> but Apple has a plan for banning ipv4-only apps and has delivered the
> required features for having ipv6-only iphones in 2016 with these iOS 9.2
> features
> 
> https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
> 
> On some mobile providers, ipv6 is already dominant and ipv4 is waning. Once
> iPhones updates to ipv6-only as described above, ipv4 will only be a corner
> case of operations.  This comes with added benefit that ipv6 is faster :
> 
> https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/
> 
> At least in mobile, the change to ipv6 has been quick and the pace is
> increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I know
> many people liken ipv6 to "the boy who cried wolf", so be it, the
> data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
> the right metaphor was "the tortoise and the hare" or "the little engine
> that could"... Or even better IPv4 is John Henry.  It was the best in its
> time, but times have changed.
> 
> CB


From james.cutler at consultant.com  Tue Dec 22 18:04:13 2015
From: james.cutler at consultant.com (James R Cutler)
Date: Tue, 22 Dec 2015 13:04:13 -0500
Subject: Nat
In-Reply-To: <B0DEF559-89A7-4D6D-9A2D-8811303B9230@delong.com>
References: <1356977108.3953.1450630744338.JavaMail.mhammett@ThunderFuck>
 <4D6D73DE-39F3-432D-B2E3-65FB8FD77BBC@delong.com>
 <8737uurg8d.fsf@nemi.mork.no>
 <B0DEF559-89A7-4D6D-9A2D-8811303B9230@delong.com>
Message-ID: <AE81DC89-72E9-4706-A712-3116F6A0584F@consultant.com>

Comments inline


> On Dec 22, 2015, at 12:47 PM, Owen DeLong <owen at delong.com> wrote:
> 
> 
>> On Dec 22, 2015, at 01:21 , Bj?rn Mork <bjorn at mork.no> wrote:
>> 
>> Owen DeLong <owen at delong.com> writes:
>>>> On Dec 20, 2015, at 08:57 , Mike Hammett <nanog at ics-il.net> wrote:
>>> 
>>>> The idea that there's a possible need for more than 4 bits worth of
>>>> subnets in a home is simply ludicrous and we have people advocating
>>>> 16 bits worth of subnets. How does that compare to the entire IPv4
>>>> Internet?
>>> 
>>> I have more than 16 subnets in my house, so I can cite at least one
>>> house with need for more than 4 bits just in a hand-coded network.
>>> 
>>> Considering the future possibilities for automated topological
>>> hierarchies using DHCP-PD with dynamic joining and pruning routers, I
>>> think 8 bits is simply not enough to allow for the kind of flexibility
>>> we?d like to give to developers, so 16 bits seems like a reasonable
>>> compromise.
>> 
>> Thanks for summarizing why /48 for everybody is possible.  But I fear
>> that is not helping much against arguments based on "need". I believe it
>> is difficult to argue that anyone needs any IP address at all, given
>> that there are lots of people in the world who seem to survive just fine
>> without one?
> 
> Arguments based on ?need? don?t make any sense in an IPv6 context.
> 
> Sure, we shouldn?t be so profligate in our distribution of the address pool
> that we run out well before the protocol?s useful life is exhausted, but I
> think I?ve shown that the current allocation policies, including /48 have
> adequate protection against that occurring.
> 
> Being more restrictive just for the sake of being more restrictive doesn?t
> serve any purpose. It doesn?t help anyone. As such, I just don?t understand
> those arguments. If someone can show me a tangible benefit from a more
> restrictive policy, I?m open to considering it, but so far, none exists.

The best feature of being more restrictive is continuing employment of people and processes for restriction.

The worst feature of being more restrictive is paying for the extra people and processes.

If we standardize on /48 (or whatever) then we can put all that money and labor into solving the real business problems of the IPv6 Internet..

	Cutler
> 
>> So, with that sorted out, let's consider what you can do with 16 bits of
>> subnets.  One example is checksum neutral prefix translation (RFC6296)
>> without touching the interface id bits . Let's say you have two upstream
>> ISPs handing you the prefixes A/48 and B/56.  Neither offer any
>> multihoming support to residential users and both do BCP38 of course. So
>> you use B/56 internally and do prefix translation to allow your router
>> to select upstream without involving the clients.  Thanks to the A/48
>> from the first ISP, you are able to choose a set of 256 (or possibly 255
>> since 0xffff cannot be used) checksum neutral subnet pairs.
> 
> That?s a really icky alternative to simple BGP multihoming (which is what
> I?m currently using at home).
> 
> Of course, not the worst, but a significantly bad part of this is the provider
> that?s only giving you a /56 to begin with. ;-)
> 
>> Yes, I know. Evil. No need. No CPE support.  Etc.
> 
> True that.
> 
>> The important part is that 16 bits of subnets is enough to play
>> algorithmic tricks with the subnet part of your address too, whereas
>> this is much more difficult with fewer bits.  No, you don't need to do
>> it.  But you CAN.  The sparse IPv6 addressing model is about opening up
>> possibilities.  Note that those possibilities includes restricting
>> yourself to using a single address.  You don't have to use all your 2^80
>> addresses :)
> 
> I completely agree.
> 
>> 
>> And for the ISPs, using /48 for every user means fewer prefix lengths to
>> consider for routing and address management. Sure, we manage diverse
>> prefix lengths in IPv4 today, but why not take advantage of this
>> possible simplification if we can? Only those living on bugs will object
>> to simpler address databases and routing filters.
> 
> Again, you?re preaching to the choir.
> 
> Owen
> 


From cb.list6 at gmail.com  Tue Dec 22 18:08:13 2015
From: cb.list6 at gmail.com (Ca By)
Date: Tue, 22 Dec 2015 10:08:13 -0800
Subject: IPv4 shutdown in mobile
In-Reply-To: <D3164172-EEEE-4D13-8C4A-39E04C41087E@delong.com>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <D3164172-EEEE-4D13-8C4A-39E04C41087E@delong.com>
Message-ID: <CAD6AjGShFy8hFadnUScR_cBjGNNazqLW7trL46FZGdD1A8Fgfw@mail.gmail.com>

On Tuesday, December 22, 2015, Owen DeLong <owen at delong.com> wrote:

> Does this mean you are negligent for not supporting IPv6 on my phone on
> your network?
>
> My phone is perfectly capable of IPv6, yet because it doesn?t support your
> particular religion
> about IPv4 translation, you refuse to support IPv6 on it.
>
> When is T-Mobile going to fix their IPv6 implementation and stop ignoring
> the #1 market
> leading phone manufacturer?
>
> Owen
>
>
Apple has an ipv6-only plan in the link above. They have committed to
remove the ipv4 dependent apps from the app store. Once the ipv4-only apps
are bannished, i dont see any roadblocks for ipv6 on iPhone.

While you say there is a religious war, i am saying Apple outlined a plan
for ipv6-only and T-Mobile is likely to follow that plan from Apple.

CB



> > On Dec 22, 2015, at 04:45 , Ca By <cb.list6 at gmail.com <javascript:;>>
> wrote:
> >
> > TL;DR version: the data shows you are negligent if your eyeball content
> > (cdn, cloud, ...) does  not support native ipv6.
> >
> > With the NAT and IPv4 leasing threads lingering on, i figured it was time
> > for an update on how the other half live
> >
> > More than 1/3 of North America mobile traffic to the top websites is end
> to
> > end ipv6
> >
> http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/
> >
> > The trend is clearly growing, and as AT&T and Sprint catch up with
> T-Mobile
> > and Verizon, the acceleration to 50% should be easily achieved.
> > Furthermore, only one mobile carrier has iPhone dual-stacked today
> (afaik),
> > but Apple has a plan for banning ipv4-only apps and has delivered the
> > required features for having ipv6-only iphones in 2016 with these iOS 9.2
> > features
> >
> >
> https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
> >
> > On some mobile providers, ipv6 is already dominant and ipv4 is waning.
> Once
> > iPhones updates to ipv6-only as described above, ipv4 will only be a
> corner
> > case of operations.  This comes with added benefit that ipv6 is faster :
> >
> >
> https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/
> >
> > At least in mobile, the change to ipv6 has been quick and the pace is
> > increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I
> know
> > many people liken ipv6 to "the boy who cried wolf", so be it, the
> > data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
> > the right metaphor was "the tortoise and the hare" or "the little engine
> > that could"... Or even better IPv4 is John Henry.  It was the best in its
> > time, but times have changed.
> >
> > CB
>
>

From owen at delong.com  Tue Dec 22 18:13:32 2015
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Dec 2015 10:13:32 -0800
Subject: IPv4 shutdown in mobile
In-Reply-To: <CAD6AjGShFy8hFadnUScR_cBjGNNazqLW7trL46FZGdD1A8Fgfw@mail.gmail.com>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <D3164172-EEEE-4D13-8C4A-39E04C41087E@delong.com>
 <CAD6AjGShFy8hFadnUScR_cBjGNNazqLW7trL46FZGdD1A8Fgfw@mail.gmail.com>
Message-ID: <16AF9DB4-EF95-4419-BD67-A02CDB625B4D@delong.com>

Yet until Apple gets to that IPv6-only stage, you?re refusing to support IPv6 for those of us
that need it today even while we still need IPv4, too.

Owen

> On Dec 22, 2015, at 10:08 , Ca By <cb.list6 at gmail.com> wrote:
> 
> 
> 
> On Tuesday, December 22, 2015, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> Does this mean you are negligent for not supporting IPv6 on my phone on your network?
> 
> My phone is perfectly capable of IPv6, yet because it doesn?t support your particular religion
> about IPv4 translation, you refuse to support IPv6 on it.
> 
> When is T-Mobile going to fix their IPv6 implementation and stop ignoring the #1 market
> leading phone manufacturer?
> 
> Owen
> 
> 
> Apple has an ipv6-only plan in the link above. They have committed to remove the ipv4 dependent apps from the app store. Once the ipv4-only apps are bannished, i dont see any roadblocks for ipv6 on iPhone. 
> 
> While you say there is a religious war, i am saying Apple outlined a plan for ipv6-only and T-Mobile is likely to follow that plan from Apple. 
> 
> CB
> 
>  
> > On Dec 22, 2015, at 04:45 , Ca By <cb.list6 at gmail.com <javascript:;>> wrote:
> >
> > TL;DR version: the data shows you are negligent if your eyeball content
> > (cdn, cloud, ...) does  not support native ipv6.
> >
> > With the NAT and IPv4 leasing threads lingering on, i figured it was time
> > for an update on how the other half live
> >
> > More than 1/3 of North America mobile traffic to the top websites is end to
> > end ipv6
> > http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/ <http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/>
> >
> > The trend is clearly growing, and as AT&T and Sprint catch up with T-Mobile
> > and Verizon, the acceleration to 50% should be easily achieved.
> > Furthermore, only one mobile carrier has iPhone dual-stacked today (afaik),
> > but Apple has a plan for banning ipv4-only apps and has delivered the
> > required features for having ipv6-only iphones in 2016 with these iOS 9.2
> > features
> >
> > https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html <https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html>
> >
> > On some mobile providers, ipv6 is already dominant and ipv4 is waning. Once
> > iPhones updates to ipv6-only as described above, ipv4 will only be a corner
> > case of operations.  This comes with added benefit that ipv6 is faster :
> >
> > https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/ <https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/>
> >
> > At least in mobile, the change to ipv6 has been quick and the pace is
> > increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I know
> > many people liken ipv6 to "the boy who cried wolf", so be it, the
> > data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
> > the right metaphor was "the tortoise and the hare" or "the little engine
> > that could"... Or even better IPv4 is John Henry.  It was the best in its
> > time, but times have changed.
> >
> > CB
> 


From dcorbe at hammerfiber.com  Tue Dec 22 18:24:05 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Tue, 22 Dec 2015 13:24:05 -0500
Subject: Atlantic City
Message-ID: <BA300893-D83F-410C-8E1E-0CC3B285C031@hammerfiber.com>

Can someone quote me a price off-list for 300Mbit (preferably on a GigE) in Atlantic City somewhere?


From Lee at asgard.org  Tue Dec 22 18:53:25 2015
From: Lee at asgard.org (Lee Howard)
Date: Tue, 22 Dec 2015 13:53:25 -0500
Subject: IPv4 shutdown in mobile
In-Reply-To: <16AF9DB4-EF95-4419-BD67-A02CDB625B4D@delong.com>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <D3164172-EEEE-4D13-8C4A-39E04C41087E@delong.com>
 <CAD6AjGShFy8hFadnUScR_cBjGNNazqLW7trL46FZGdD1A8Fgfw@mail.gmail.com>
 <16AF9DB4-EF95-4419-BD67-A02CDB625B4D@delong.com>
Message-ID: <D29F061F.D1A0D%Lee@asgard.org>



On 12/22/15, 1:13 PM, "NANOG on behalf of Owen DeLong"
<nanog-bounces at nanog.org on behalf of owen at delong.com> wrote:

>Yet until Apple gets to that IPv6-only stage, you?re refusing to support
>IPv6 for those of us
>that need it today even while we still need IPv4, too.
>
>Owen


Owen, you?re out of line.

Lee



>
>> On Dec 22, 2015, at 10:08 , Ca By <cb.list6 at gmail.com> wrote:
>> 
>> 
>> 
>> On Tuesday, December 22, 2015, Owen DeLong <owen at delong.com
>><mailto:owen at delong.com>> wrote:
>> Does this mean you are negligent for not supporting IPv6 on my phone on
>>your network?
>> 
>> My phone is perfectly capable of IPv6, yet because it doesn?t support
>>your particular religion
>> about IPv4 translation, you refuse to support IPv6 on it.
>> 
>> When is T-Mobile going to fix their IPv6 implementation and stop
>>ignoring the #1 market
>> leading phone manufacturer?
>> 
>> Owen
>> 
>> 
>> Apple has an ipv6-only plan in the link above. They have committed to
>>remove the ipv4 dependent apps from the app store. Once the ipv4-only
>>apps are bannished, i dont see any roadblocks for ipv6 on iPhone.
>> 
>> While you say there is a religious war, i am saying Apple outlined a
>>plan for ipv6-only and T-Mobile is likely to follow that plan from
>>Apple. 
>> 
>> CB
>> 
>>  
>> > On Dec 22, 2015, at 04:45 , Ca By <cb.list6 at gmail.com <javascript:;>>
>>wrote:
>> >
>> > TL;DR version: the data shows you are negligent if your eyeball
>>content
>> > (cdn, cloud, ...) does  not support native ipv6.
>> >
>> > With the NAT and IPv4 leasing threads lingering on, i figured it was
>>time
>> > for an update on how the other half live
>> >
>> > More than 1/3 of North America mobile traffic to the top websites is
>>end to
>> > end ipv6
>> > 
>>http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic
>>-is-ipv6-and-still-growing/
>><http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffi
>>c-is-ipv6-and-still-growing/>
>> >
>> > The trend is clearly growing, and as AT&T and Sprint catch up with
>>T-Mobile
>> > and Verizon, the acceleration to 50% should be easily achieved.
>> > Furthermore, only one mobile carrier has iPhone dual-stacked today
>>(afaik),
>> > but Apple has a plan for banning ipv4-only apps and has delivered the
>> > required features for having ipv6-only iphones in 2016 with these iOS
>>9.2
>> > features
>> >
>> > 
>>https://developer.apple.com/library/ios/documentation/NetworkingInternetW
>>eb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Trans
>>ition/UnderstandingandPreparingfortheIPv6Transition.html
>><https://developer.apple.com/library/ios/documentation/NetworkingInternet
>>Web/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Tran
>>sition/UnderstandingandPreparingfortheIPv6Transition.html>
>> >
>> > On some mobile providers, ipv6 is already dominant and ipv4 is
>>waning. Once
>> > iPhones updates to ipv6-only as described above, ipv4 will only be a
>>corner
>> > case of operations.  This comes with added benefit that ipv6 is
>>faster :
>> >
>> > 
>>https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on
>>-board/ 
>><https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-o
>>n-board/>
>> >
>> > At least in mobile, the change to ipv6 has been quick and the pace is
>> > increasing -- not just on ipv6 deployment but also on ipv4 shutdown.
>>I know
>> > many people liken ipv6 to "the boy who cried wolf", so be it, the
>> > data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will
>>see
>> > the right metaphor was "the tortoise and the hare" or "the little
>>engine
>> > that could"... Or even better IPv4 is John Henry.  It was the best in
>>its
>> > time, but times have changed.
>> >
>> > CB
>> 
>
>



From trelane at trelane.net  Tue Dec 22 19:04:31 2015
From: trelane at trelane.net (Andrew Kirch)
Date: Tue, 22 Dec 2015 14:04:31 -0500
Subject: IPv4 shutdown in mobile
In-Reply-To: <16AF9DB4-EF95-4419-BD67-A02CDB625B4D@delong.com>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <D3164172-EEEE-4D13-8C4A-39E04C41087E@delong.com>
 <CAD6AjGShFy8hFadnUScR_cBjGNNazqLW7trL46FZGdD1A8Fgfw@mail.gmail.com>
 <16AF9DB4-EF95-4419-BD67-A02CDB625B4D@delong.com>
Message-ID: <CALA5tJKoar=2yj883sG1LJki+BupM-0FQ=1mekzigJ9rw3DGhg@mail.gmail.com>

I wonder if Tmobile realizes that when you sign up for a contract with
them using one of their phones as a wifi hotspot, the address of their
enterprise NAT is what's recorded by their form.  They even make you
check a button to accept their lack of security.

Not that that could result in massive fraud or anything.  Not that
massive fraud is a problem for Tmobile either come to think of it.


On Tue, Dec 22, 2015 at 1:13 PM, Owen DeLong <owen at delong.com> wrote:
> Yet until Apple gets to that IPv6-only stage, you?re refusing to support IPv6 for those of us
> that need it today even while we still need IPv4, too.
>
> Owen
>
>> On Dec 22, 2015, at 10:08 , Ca By <cb.list6 at gmail.com> wrote:
>>
>>
>>
>> On Tuesday, December 22, 2015, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> Does this mean you are negligent for not supporting IPv6 on my phone on your network?
>>
>> My phone is perfectly capable of IPv6, yet because it doesn?t support your particular religion
>> about IPv4 translation, you refuse to support IPv6 on it.
>>
>> When is T-Mobile going to fix their IPv6 implementation and stop ignoring the #1 market
>> leading phone manufacturer?
>>
>> Owen
>>
>>
>> Apple has an ipv6-only plan in the link above. They have committed to remove the ipv4 dependent apps from the app store. Once the ipv4-only apps are bannished, i dont see any roadblocks for ipv6 on iPhone.
>>
>> While you say there is a religious war, i am saying Apple outlined a plan for ipv6-only and T-Mobile is likely to follow that plan from Apple.
>>
>> CB
>>
>>
>> > On Dec 22, 2015, at 04:45 , Ca By <cb.list6 at gmail.com <javascript:;>> wrote:
>> >
>> > TL;DR version: the data shows you are negligent if your eyeball content
>> > (cdn, cloud, ...) does  not support native ipv6.
>> >
>> > With the NAT and IPv4 leasing threads lingering on, i figured it was time
>> > for an update on how the other half live
>> >
>> > More than 1/3 of North America mobile traffic to the top websites is end to
>> > end ipv6
>> > http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/ <http://www.worldipv6launch.org/2015-wrapup-more-than-13-us-mobile-traffic-is-ipv6-and-still-growing/>
>> >
>> > The trend is clearly growing, and as AT&T and Sprint catch up with T-Mobile
>> > and Verizon, the acceleration to 50% should be easily achieved.
>> > Furthermore, only one mobile carrier has iPhone dual-stacked today (afaik),
>> > but Apple has a plan for banning ipv4-only apps and has delivered the
>> > required features for having ipv6-only iphones in 2016 with these iOS 9.2
>> > features
>> >
>> > https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html <https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html>
>> >
>> > On some mobile providers, ipv6 is already dominant and ipv4 is waning. Once
>> > iPhones updates to ipv6-only as described above, ipv4 will only be a corner
>> > case of operations.  This comes with added benefit that ipv6 is faster :
>> >
>> > https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/ <https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/>
>> >
>> > At least in mobile, the change to ipv6 has been quick and the pace is
>> > increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I know
>> > many people liken ipv6 to "the boy who cried wolf", so be it, the
>> > data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
>> > the right metaphor was "the tortoise and the hare" or "the little engine
>> > that could"... Or even better IPv4 is John Henry.  It was the best in its
>> > time, but times have changed.
>> >
>> > CB
>>
>

From wwaites at tardis.ed.ac.uk  Tue Dec 22 19:00:54 2015
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Tue, 22 Dec 2015 19:00:54 +0000 (GMT)
Subject: interconnection costs
In-Reply-To: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
Message-ID: <20151222.190054.126884291084033560.wwaites@tardis.ed.ac.uk>

there is also the increasingly common pattern of "remote peering"
where you lease a circuit to an exchange point but do not establish a
presence in the facility. this can either be done with the last leg on
a dedicated cross-connect (so it looks to the exchange operator just
like any other connection except that it is to an intermediary and not
to you) or multiplexed on a single connection to the exchange operated
by a carrier that specialises in facilitating remote peering.

to the extent that this practice dramatically decouples the peering
graph from the underlying infrastructure graph it is debatable if this
is a wise or efficient strategy. on the other hand it significantly
widens the operational scope of bgp configuration knobs.

but the point is, you can do peering without a physical presence in a
location, and it is a common thing to do.

cheers,
-w

--
William Waites <wwaites at tardis.ed.ac.uk>  |  School of Informatics
   https://tardis.ed.ac.uk/~wwaites/      | University of Edinburgh
         https://hubs.net.uk/             |      HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

From motamedi at cs.uoregon.edu  Tue Dec 22 19:11:36 2015
From: motamedi at cs.uoregon.edu (Reza Motamedi)
Date: Tue, 22 Dec 2015 11:11:36 -0800
Subject: interconnection costs
In-Reply-To: <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
Message-ID: <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>

Thanks guys for the replies.

I wanted to clarify two things in my questions. First by peering I did not
necessarily mean "settlement free" interconnection. I meant any inter-AS
connection. My understanding is that in addition to the cost of transit
that should be paid to the transit provider, there also exists the cost of
the xconnect that is charged by the colocation provider. Secondly, my
question was more about the expenses, as opposed to the technical
costs/benefits. I have browsed through the "Peering Playbook", but I think
its more about providing a case "settlement free" peering.

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbensley at gmail.com> wrote:

> On 22 December 2015 at 16:44, Reza Motamedi <motamedi at cs.uoregon.edu>
> wrote:
> > I think there is no single answer as different businesses may have
> > different pricing models. I hope the discussion can help me understand
> the
> > whole ecosystem a little bit better.
>
>
> Hi Reza,
>
> I have a list of example items that need to be costed in below, it is
> by no means a definitive list though:
>
>
> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2&pli=1#
>
>
> Cheers,
> James.
>
>

From faisal at snappytelecom.net  Tue Dec 22 19:28:13 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 22 Dec 2015 19:28:13 +0000 (GMT)
Subject: interconnection costs (off list)
In-Reply-To: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
Message-ID: <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>

Salam Reza,

You are asking an interesting set of questions, it might be easier to answer the over a phone call conversation (at least fro our perspective, being a small ISP/NSP ). I can write to you a lengthy reply, but am not sure if I will be able to convey to you the information properly.

The way you have posed the question, indicates to me that you are taking a particular view of a 'network', which is not the same view I hold. I am not sure if your view is more prevalent or our view as a service provider.

Regardless I think it would make for an interesting conversation. Feel free to call me at your convenience.

Regards.

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net

----- Original Message -----
> From: "Reza Motamedi" <motamedi at cs.uoregon.edu>
> To: "nanog list" <nanog at nanog.org>
> Sent: Tuesday, December 22, 2015 11:44:06 AM
> Subject: interconnection costs

> Hi NANOG
> 
> We are a group of researchers and our focus is on the economy of
> interconnection in the Internet. My question is mainly about the various
> costs of an AS establishing a connection with another AS, including the
> costs charged by the colocation providers. I am familiar with most of the
> connection options such as public peering on IXP, and private peering
> through xconnects. My understanding is that in addition to the cost of
> transit that the smaller AS pays to the larger AS, in the former you pay a
> monthly fee to establish a link to the switching fabric and then you can
> connect to as many ASes that are member in the IXP, and in the later you
> need to pay for as many xconnects that you need to connect to as many ASes
> that you plan to peer with. Obviously in both cases there is the cost of
> being in the colocation and renting a rack or whatever. What are the other
> costs involved? How should the AS reach the colocation center in the first
> place? I don't think every network can dig a hole an lay cables. Who should
> they pay to get from one PoP to another? Do ASes have to pay for xconnect
> to connect their PoP in a data center to the rest of their network?
> 
> I think there is no single answer as different businesses may have
> different pricing models. I hope the discussion can help me understand the
> whole ecosystem a little bit better.
> 
> 
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon

From josh at imaginenetworksllc.com  Tue Dec 22 19:29:55 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 22 Dec 2015 14:29:55 -0500
Subject: interconnection costs (off list)
In-Reply-To: <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>
Message-ID: <CAN9qwJ_KRwkFTXNk1BA2fjMoB+8+e9-Rv1ti_wqx_aOkYrPjyw@mail.gmail.com>

Not offlist.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Dec 22, 2015 at 2:28 PM, Faisal Imtiaz <faisal at snappytelecom.net>
wrote:

> Salam Reza,
>
> You are asking an interesting set of questions, it might be easier to
> answer the over a phone call conversation (at least fro our perspective,
> being a small ISP/NSP ). I can write to you a lengthy reply, but am not
> sure if I will be able to convey to you the information properly.
>
> The way you have posed the question, indicates to me that you are taking a
> particular view of a 'network', which is not the same view I hold. I am not
> sure if your view is more prevalent or our view as a service provider.
>
> Regardless I think it would make for an interesting conversation. Feel
> free to call me at your convenience.
>
> Regards.
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
>
> ----- Original Message -----
> > From: "Reza Motamedi" <motamedi at cs.uoregon.edu>
> > To: "nanog list" <nanog at nanog.org>
> > Sent: Tuesday, December 22, 2015 11:44:06 AM
> > Subject: interconnection costs
>
> > Hi NANOG
> >
> > We are a group of researchers and our focus is on the economy of
> > interconnection in the Internet. My question is mainly about the various
> > costs of an AS establishing a connection with another AS, including the
> > costs charged by the colocation providers. I am familiar with most of the
> > connection options such as public peering on IXP, and private peering
> > through xconnects. My understanding is that in addition to the cost of
> > transit that the smaller AS pays to the larger AS, in the former you pay
> a
> > monthly fee to establish a link to the switching fabric and then you can
> > connect to as many ASes that are member in the IXP, and in the later you
> > need to pay for as many xconnects that you need to connect to as many
> ASes
> > that you plan to peer with. Obviously in both cases there is the cost of
> > being in the colocation and renting a rack or whatever. What are the
> other
> > costs involved? How should the AS reach the colocation center in the
> first
> > place? I don't think every network can dig a hole an lay cables. Who
> should
> > they pay to get from one PoP to another? Do ASes have to pay for xconnect
> > to connect their PoP in a data center to the rest of their network?
> >
> > I think there is no single answer as different businesses may have
> > different pricing models. I hope the discussion can help me understand
> the
> > whole ecosystem a little bit better.
> >
> >
> > Best Regards
> > Reza Motamedi (R.M)
> > Graduate Research Fellow
> > Oregon Network Research Group
> > Computer and Information Science
> > University of Oregon
>

From faisal at snappytelecom.net  Tue Dec 22 19:31:11 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 22 Dec 2015 19:31:11 +0000 (GMT)
Subject: interconnection costs (off list)
In-Reply-To: <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>
Message-ID: <1985862880.1715255.1450812671919.JavaMail.zimbra@snappytelecom.net>

Ouch... so much for off list .. :(

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net

----- Original Message -----
> From: "Faisal Imtiaz" <faisal at snappytelecom.net>
> To: "Reza Motamedi" <motamedi at cs.uoregon.edu>
> Cc: "nanog list" <nanog at nanog.org>
> Sent: Tuesday, December 22, 2015 2:28:13 PM
> Subject: Re: interconnection costs (off list)

> Salam Reza,
> 
> You are asking an interesting set of questions, it might be easier to answer the
> over a phone call conversation (at least fro our perspective, being a small
> ISP/NSP ). I can write to you a lengthy reply, but am not sure if I will be
> able to convey to you the information properly.
> 
> The way you have posed the question, indicates to me that you are taking a
> particular view of a 'network', which is not the same view I hold. I am not
> sure if your view is more prevalent or our view as a service provider.
> 
> Regardless I think it would make for an interesting conversation. Feel free to
> call me at your convenience.
> 
> Regards.
> 
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
> 
> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
> 
> ----- Original Message -----
>> From: "Reza Motamedi" <motamedi at cs.uoregon.edu>
>> To: "nanog list" <nanog at nanog.org>
>> Sent: Tuesday, December 22, 2015 11:44:06 AM
>> Subject: interconnection costs
> 
>> Hi NANOG
>> 
>> We are a group of researchers and our focus is on the economy of
>> interconnection in the Internet. My question is mainly about the various
>> costs of an AS establishing a connection with another AS, including the
>> costs charged by the colocation providers. I am familiar with most of the
>> connection options such as public peering on IXP, and private peering
>> through xconnects. My understanding is that in addition to the cost of
>> transit that the smaller AS pays to the larger AS, in the former you pay a
>> monthly fee to establish a link to the switching fabric and then you can
>> connect to as many ASes that are member in the IXP, and in the later you
>> need to pay for as many xconnects that you need to connect to as many ASes
>> that you plan to peer with. Obviously in both cases there is the cost of
>> being in the colocation and renting a rack or whatever. What are the other
>> costs involved? How should the AS reach the colocation center in the first
>> place? I don't think every network can dig a hole an lay cables. Who should
>> they pay to get from one PoP to another? Do ASes have to pay for xconnect
>> to connect their PoP in a data center to the rest of their network?
>> 
>> I think there is no single answer as different businesses may have
>> different pricing models. I hope the discussion can help me understand the
>> whole ecosystem a little bit better.
>> 
>> 
>> Best Regards
>> Reza Motamedi (R.M)
>> Graduate Research Fellow
>> Oregon Network Research Group
>> Computer and Information Science
> > University of Oregon

From ghenry at suretec.co.uk  Tue Dec 22 19:36:02 2015
From: ghenry at suretec.co.uk (Gavin Henry)
Date: Tue, 22 Dec 2015 19:36:02 +0000
Subject: interconnection costs (off list)
In-Reply-To: <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <174225016.1715204.1450812493187.JavaMail.zimbra@snappytelecom.net>
Message-ID: <CAPcb_G+E-ciQVAbqf+048w=o5noJ7MsjmKNskqfPvrF8uoUj2Q@mail.gmail.com>

On list :)

From nanog at ics-il.net  Tue Dec 22 19:38:21 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 22 Dec 2015 13:38:21 -0600 (CST)
Subject: interconnection costs (off list)
In-Reply-To: <1985862880.1715255.1450812671919.JavaMail.zimbra@snappytelecom.net>
Message-ID: <1503564717.2013.1450813144095.JavaMail.mhammett@ThunderFuck>

Faisal is new to the Internet. ;-) 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Faisal Imtiaz" <faisal at snappytelecom.net> 
To: "Reza Motamedi" <motamedi at cs.uoregon.edu> 
Cc: "nanog list" <nanog at nanog.org> 
Sent: Tuesday, December 22, 2015 1:31:11 PM 
Subject: Re: interconnection costs (off list) 

Ouch... so much for off list .. :( 

Faisal Imtiaz 
Snappy Internet & Telecom 
7266 SW 48 Street 
Miami, FL 33155 
Tel: 305 663 5518 x 232 

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net 

----- Original Message ----- 
> From: "Faisal Imtiaz" <faisal at snappytelecom.net> 
> To: "Reza Motamedi" <motamedi at cs.uoregon.edu> 
> Cc: "nanog list" <nanog at nanog.org> 
> Sent: Tuesday, December 22, 2015 2:28:13 PM 
> Subject: Re: interconnection costs (off list) 

> Salam Reza, 
> 
> You are asking an interesting set of questions, it might be easier to answer the 
> over a phone call conversation (at least fro our perspective, being a small 
> ISP/NSP ). I can write to you a lengthy reply, but am not sure if I will be 
> able to convey to you the information properly. 
> 
> The way you have posed the question, indicates to me that you are taking a 
> particular view of a 'network', which is not the same view I hold. I am not 
> sure if your view is more prevalent or our view as a service provider. 
> 
> Regardless I think it would make for an interesting conversation. Feel free to 
> call me at your convenience. 
> 
> Regards. 
> 
> Faisal Imtiaz 
> Snappy Internet & Telecom 
> 7266 SW 48 Street 
> Miami, FL 33155 
> Tel: 305 663 5518 x 232 
> 
> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net 
> 
> ----- Original Message ----- 
>> From: "Reza Motamedi" <motamedi at cs.uoregon.edu> 
>> To: "nanog list" <nanog at nanog.org> 
>> Sent: Tuesday, December 22, 2015 11:44:06 AM 
>> Subject: interconnection costs 
> 
>> Hi NANOG 
>> 
>> We are a group of researchers and our focus is on the economy of 
>> interconnection in the Internet. My question is mainly about the various 
>> costs of an AS establishing a connection with another AS, including the 
>> costs charged by the colocation providers. I am familiar with most of the 
>> connection options such as public peering on IXP, and private peering 
>> through xconnects. My understanding is that in addition to the cost of 
>> transit that the smaller AS pays to the larger AS, in the former you pay a 
>> monthly fee to establish a link to the switching fabric and then you can 
>> connect to as many ASes that are member in the IXP, and in the later you 
>> need to pay for as many xconnects that you need to connect to as many ASes 
>> that you plan to peer with. Obviously in both cases there is the cost of 
>> being in the colocation and renting a rack or whatever. What are the other 
>> costs involved? How should the AS reach the colocation center in the first 
>> place? I don't think every network can dig a hole an lay cables. Who should 
>> they pay to get from one PoP to another? Do ASes have to pay for xconnect 
>> to connect their PoP in a data center to the rest of their network? 
>> 
>> I think there is no single answer as different businesses may have 
>> different pricing models. I hope the discussion can help me understand the 
>> whole ecosystem a little bit better. 
>> 
>> 
>> Best Regards 
>> Reza Motamedi (R.M) 
>> Graduate Research Fellow 
>> Oregon Network Research Group 
>> Computer and Information Science 
> > University of Oregon 


From faisal at snappytelecom.net  Tue Dec 22 19:45:06 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 22 Dec 2015 19:45:06 +0000 (GMT)
Subject: interconnection costs (off list)
In-Reply-To: <1503564717.2013.1450813144095.JavaMail.mhammett@ThunderFuck>
References: <1503564717.2013.1450813144095.JavaMail.mhammett@ThunderFuck>
Message-ID: <1645790040.1715396.1450813506810.JavaMail.zimbra@snappytelecom.net>

or More like getting too old to remember completing the edit of mail to: field !

LOL!


Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net

----- Original Message -----
> From: "Mike Hammett" <nanog at ics-il.net>
> Cc: "nanog list" <nanog at nanog.org>
> Sent: Tuesday, December 22, 2015 2:38:21 PM
> Subject: Re: interconnection costs (off list)

> Faisal is new to the Internet. ;-)
> 
> 
> 
> 
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com
> 
> 
> ----- Original Message -----
> 
> From: "Faisal Imtiaz" <faisal at snappytelecom.net>
> To: "Reza Motamedi" <motamedi at cs.uoregon.edu>
> Cc: "nanog list" <nanog at nanog.org>
> Sent: Tuesday, December 22, 2015 1:31:11 PM
> Subject: Re: interconnection costs (off list)
> 
> Ouch... so much for off list .. :(
> 
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
> 
> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
> 
> ----- Original Message -----
>> From: "Faisal Imtiaz" <faisal at snappytelecom.net>
>> To: "Reza Motamedi" <motamedi at cs.uoregon.edu>
>> Cc: "nanog list" <nanog at nanog.org>
>> Sent: Tuesday, December 22, 2015 2:28:13 PM
>> Subject: Re: interconnection costs (off list)
> 
>> Salam Reza,
>> 
>> You are asking an interesting set of questions, it might be easier to answer the
>> over a phone call conversation (at least fro our perspective, being a small
>> ISP/NSP ). I can write to you a lengthy reply, but am not sure if I will be
>> able to convey to you the information properly.
>> 
>> The way you have posed the question, indicates to me that you are taking a
>> particular view of a 'network', which is not the same view I hold. I am not
>> sure if your view is more prevalent or our view as a service provider.
>> 
>> Regardless I think it would make for an interesting conversation. Feel free to
>> call me at your convenience.
>> 
>> Regards.
>> 
>> Faisal Imtiaz
>> Snappy Internet & Telecom
>> 7266 SW 48 Street
>> Miami, FL 33155
>> Tel: 305 663 5518 x 232
>> 
>> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
>> 
>> ----- Original Message -----
>>> From: "Reza Motamedi" <motamedi at cs.uoregon.edu>
>>> To: "nanog list" <nanog at nanog.org>
>>> Sent: Tuesday, December 22, 2015 11:44:06 AM
>>> Subject: interconnection costs
>> 
>>> Hi NANOG
>>> 
>>> We are a group of researchers and our focus is on the economy of
>>> interconnection in the Internet. My question is mainly about the various
>>> costs of an AS establishing a connection with another AS, including the
>>> costs charged by the colocation providers. I am familiar with most of the
>>> connection options such as public peering on IXP, and private peering
>>> through xconnects. My understanding is that in addition to the cost of
>>> transit that the smaller AS pays to the larger AS, in the former you pay a
>>> monthly fee to establish a link to the switching fabric and then you can
>>> connect to as many ASes that are member in the IXP, and in the later you
>>> need to pay for as many xconnects that you need to connect to as many ASes
>>> that you plan to peer with. Obviously in both cases there is the cost of
>>> being in the colocation and renting a rack or whatever. What are the other
>>> costs involved? How should the AS reach the colocation center in the first
>>> place? I don't think every network can dig a hole an lay cables. Who should
>>> they pay to get from one PoP to another? Do ASes have to pay for xconnect
>>> to connect their PoP in a data center to the rest of their network?
>>> 
>>> I think there is no single answer as different businesses may have
>>> different pricing models. I hope the discussion can help me understand the
>>> whole ecosystem a little bit better.
>>> 
>>> 
>>> Best Regards
>>> Reza Motamedi (R.M)
>>> Graduate Research Fellow
>>> Oregon Network Research Group
>>> Computer and Information Science
> > > University of Oregon

From morrowc.lists at gmail.com  Tue Dec 22 20:39:54 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 22 Dec 2015 15:39:54 -0500
Subject: Atlantic City
In-Reply-To: <BA300893-D83F-410C-8E1E-0CC3B285C031@hammerfiber.com>
References: <BA300893-D83F-410C-8E1E-0CC3B285C031@hammerfiber.com>
Message-ID: <CAL9jLaaWzqTQWpJ9CiOAZ8fsOYMbvS=p8NObq0jTLfVTGHMoGg@mail.gmail.com>

On Tue, Dec 22, 2015 at 1:24 PM, Daniel Corbe <dcorbe at hammerfiber.com> wrote:
> Can someone quote me a price off-list for 300Mbit (preferably on a GigE) in Atlantic City somewhere?
>

that smells like FiOS territory...

From baldur.norddahl at gmail.com  Tue Dec 22 21:02:51 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 22 Dec 2015 22:02:51 +0100
Subject: interconnection costs
In-Reply-To: <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
Message-ID: <CAPkb-7Ab-DY1Os3ji8Dm2GctThoTyR0vm5Tm43MXEr2kQXiuAA@mail.gmail.com>

There is only a xconnect expense if the peering happens at a third party
datacenter.

If it is a first party datacenter any xconnect fees can be considered part
of the peering price.

There is also the case where one party leases or builds a fiber to the
other party. The xconnect  always goes to the DC owner but there is usually
a choice of companies that can lease fiber. The transit provider might own
the fiber and provide the fiber lease and transit charge as one combined
offer.

We buy transit from the incumbent teleco. There is no xconnect because we
are in the building already with our gpon equipment and all cost is
regulated by the government. The regulator put the price of xconnect at $0
because frankly xconnect is a made up cost.

Regards

Baldur

From sotnickd-nanog at ddv.com  Tue Dec 22 21:34:40 2015
From: sotnickd-nanog at ddv.com (David Sotnick)
Date: Tue, 22 Dec 2015 13:34:40 -0800
Subject: How to update IPv6 geolocation data? Google sites blocked.
Message-ID: <CALwYWVOgkwmMi6Y1c-d-oD+Fkd_=42bMqTuXOCDZ3UY3TwgvUg@mail.gmail.com>

Hello, and Season's Greetings!

We recently lit up a new IPv6-connected location and expanded our
ARIN-allocated /48 network to a /44 network to accommodate the additional
location (and future locations).

However, since moving our small satellite office off our primary /48 and
onto their own /48 as part of our /44 network, the users at that office are
receiving messages from e.g. YouTube that the "user has not made this
content available in your country".

How does one go about updating this v6 geolocation data? This is impacting
a bunch of our users.

Thanks!

-David

From jlewis at lewis.org  Tue Dec 22 22:12:25 2015
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 22 Dec 2015 17:12:25 -0500 (EST)
Subject: How to update IPv6 geolocation data? Google sites blocked.
In-Reply-To: <CALwYWVOgkwmMi6Y1c-d-oD+Fkd_=42bMqTuXOCDZ3UY3TwgvUg@mail.gmail.com>
References: <CALwYWVOgkwmMi6Y1c-d-oD+Fkd_=42bMqTuXOCDZ3UY3TwgvUg@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1512221708300.10544@soloth.lewis.org>

On Tue, 22 Dec 2015, David Sotnick wrote:

> Hello, and Season's Greetings!
>
> We recently lit up a new IPv6-connected location and expanded our
> ARIN-allocated /48 network to a /44 network to accommodate the additional
> location (and future locations).
>
> However, since moving our small satellite office off our primary /48 and
> onto their own /48 as part of our /44 network, the users at that office are
> receiving messages from e.g. YouTube that the "user has not made this
> content available in your country".
>
> How does one go about updating this v6 geolocation data? This is impacting
> a bunch of our users.

Using a smart phone on the wifi at that office (obviously, the WIFI 
network has to be providing IPv6, or bridged to a network providing IPv6), 
go to google.com in a web browser (not the google app), and click near the 
bottom of the page "Use precise location".  AFAIK, that provides to GOOG 
your GPS coordinates.  It still might take a week for them to update 
everything.

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

From lyndon at orthanc.ca  Wed Dec 23 02:14:56 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 22 Dec 2015 18:14:56 -0800
Subject: MACsec to edge hosts
Message-ID: <ECB1095D-4862-4A49-9806-90AAAA956C09@orthanc.ca>

Are any of you pushing MACsec (802.1AE) out from your switches to the edge hosts?  Vs. just running it on the network cross-connect fabric?

We have a scenario where, if we could MACsec encrypt those (switch <-> host) links, we could eliminate a lot of application level TLS.  But searching for a list of PHYs that support this turned up a very thin set of chips, with most of them being several years old now.

Are people even using MACsec in anything other than an "encrypt cross connects between the cages" context?  I would be very interested in chatting with anyone who has tried pushing this out from their switches to the connected hosts.

--lyndon

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

From joly at punkcast.com  Wed Dec 23 03:03:02 2015
From: joly at punkcast.com (Joly MacFie)
Date: Tue, 22 Dec 2015 22:03:02 -0500
Subject: interconnection costs
In-Reply-To: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
Message-ID: <CAM9VJk3DG8q3kSr=C3Sp-8pAfLEarSir6_n3ymKEd5WHhvpT=w@mail.gmail.com>

?If you haven't already, you should read this

?http://drpeering.net/core/bookOutline.html


?

On Tue, Dec 22, 2015 at 11:44 AM, Reza Motamedi <motamedi at cs.uoregon.edu>
wrote:

> Hi NANOG
>
> We are a group of researchers and our focus is on the economy of
> interconnection in the Internet. My question is mainly about the various
> costs of an AS establishing a connection with another AS, including the
> costs charged by the colocation providers. I am familiar with most of the
> connection options such as public peering on IXP, and private peering
> through xconnects. My understanding is that in addition to the cost of
> transit that the smaller AS pays to the larger AS, in the former you pay a
> monthly fee to establish a link to the switching fabric and then you can
> connect to as many ASes that are member in the IXP, and in the later you
> need to pay for as many xconnects that you need to connect to as many ASes
> that you plan to peer with. Obviously in both cases there is the cost of
> being in the colocation and renting a rack or whatever. What are the other
> costs involved? How should the AS reach the colocation center in the first
> place? I don't think every network can dig a hole an lay cables. Who should
> they pay to get from one PoP to another? Do ASes have to pay for xconnect
> to connect their PoP in a data center to the rest of their network?
>
> I think there is no single answer as different businesses may have
> different pricing models. I hope the discussion can help me understand the
> whole ecosystem a little bit better.
>
>
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon
>



-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-

From A.L.M.Buxey at lboro.ac.uk  Wed Dec 23 13:07:50 2015
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Wed, 23 Dec 2015 13:07:50 +0000
Subject: MACsec to edge hosts
In-Reply-To: <ECB1095D-4862-4A49-9806-90AAAA956C09@orthanc.ca>
References: <ECB1095D-4862-4A49-9806-90AAAA956C09@orthanc.ca>
Message-ID: <AB7F9650-3EAD-488D-A879-1BA9BDA7200F@lboro.ac.uk>

The host has to support it... I've only seen the cisco anyconnect client add such support to the host 

alan

From ahmed.dalaali at hrins.net  Wed Dec 23 16:22:10 2015
From: ahmed.dalaali at hrins.net (Ahmed Munaf)
Date: Wed, 23 Dec 2015 19:22:10 +0300
Subject: Nat
In-Reply-To: <5678E651.6060002@seacom.mu>
References: <315532451.4960.1450669073224.JavaMail.mhammett@ThunderFuck>
 <fd519926aff0954e828a8bb002f417b0@mail.dessus.com>
 <CAGbD49oKJpbxiGpV-0om4NKdoyhDG6t7nLjMbnhagdzfWM4pQA@mail.gmail.com>
 <5678E651.6060002@seacom.mu>
Message-ID: <8D7DC3CB-CACC-4547-95E6-426D5CFC5E64@hrins.net>

Hello, 

Does anyone use Citrix  Netscaler MPX 14000 as a CGNAT  for more than 25K users? 

Regards, 

From jwbensley at gmail.com  Wed Dec 23 17:07:51 2015
From: jwbensley at gmail.com (James Bensley)
Date: Wed, 23 Dec 2015 17:07:51 +0000
Subject: interconnection costs
In-Reply-To: <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
Message-ID: <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>

On 22 December 2015 at 19:11, Reza Motamedi <motamedi at cs.uoregon.edu> wrote:
> Thanks guys for the replies.
>
> I wanted to clarify two things in my questions. First by peering I did not
> necessarily mean "settlement free" interconnection. I meant any inter-AS
> connection. My understanding is that in addition to the cost of transit that
> should be paid to the transit provider, there also exists the cost of the
> xconnect that is charged by the colocation provider. Secondly, my question
> was more about the expenses, as opposed to the technical costs/benefits. I
> have browsed through the "Peering Playbook", but I think its more about
> providing a case "settlement free" peering.

Dude, how are you going to weigh up the costs and benefits of peering
if you don't include the "costs". I refer you back to the same
documented I referred you to yesterday...

> On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbensley at gmail.com> wrote:
>> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2&pli=1#


This time look at section 4 of this huge and hard to navigate
document, "4. Peering Costs":

https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit#heading=h.nqqauszv8vj


Loosely extrapolating:

Network transport: You need to be physically connected unless you
blagged space in the same rack and can patch in for free.

Hardware: You need tin to route packets.

Software: You need software to monitor the packet routing.

Colocation: You need space/power/cooler/security in which the tin can operate.

Staffing costs: Someone has to configure that tin.

Admin/engineering overhead: Someone has to manage the peering process

Peering port: You probably have to pay to peer.

Reseller ports: You might need remote connectivity to the LAN and
"network transport" above would refer to a cross connect to the remote
peering provider instead of directly into the IXP LAN.



James.

From motamedi at cs.uoregon.edu  Wed Dec 23 19:05:40 2015
From: motamedi at cs.uoregon.edu (Reza Motamedi)
Date: Wed, 23 Dec 2015 11:05:40 -0800
Subject: interconnection costs
In-Reply-To: <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
Message-ID: <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>

Thanks James,

I totally missed that section. Sorry about that. I think the picture is
becoming more clear in my head now.

Let me first make sure my terminology is right.
- With respect to peering, there are "transit" in which you pay the other
AS in 95-5 fashion or whatever, and "settlement-free" in which two ASes
agree not to charge each other for traffic exchange. In the latter, the
exchanged traffic is limited to the customer cone of the two ASes.
- Peering can happen either "publicly" though an IXP or "privately" through
directly linking the ports of two routers and exchanging BGP traffic.

Now, if I understood correctly, the difference between the cost of public
and private peering is that in public, one AS pays to be connected to the
IXP fabric, perhaps to the IXP provider and the colo provider. I'm assuming
IXP and colo provider are not always the same organization as it is the
case in SIX (Seattle IXP) and colo providers in Westin Building including
Equinix, ZAYO, etc. So the AS is being charged for becoming an IXP member,
and also to be allowed to take a line from its rack to the IXP's "meet me
room". Additionally if one decides to buy transit over the IXP it has to
pay the transit providers.
In Private peering however the AS pays the colo provider for the xconnect
per ASes that it wants to peer with. The cost of transit would be
additional if the peering is in fact a transit and not settlement free.

All the costs of HW, SW, personnel, administration, and perhaps
transmission between colos (including remote peering, being waved to
another location, tethering) would be the same, right?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Dec 23, 2015 at 9:07 AM, James Bensley <jwbensley at gmail.com> wrote:

> On 22 December 2015 at 19:11, Reza Motamedi <motamedi at cs.uoregon.edu>
> wrote:
> > Thanks guys for the replies.
> >
> > I wanted to clarify two things in my questions. First by peering I did
> not
> > necessarily mean "settlement free" interconnection. I meant any inter-AS
> > connection. My understanding is that in addition to the cost of transit
> that
> > should be paid to the transit provider, there also exists the cost of the
> > xconnect that is charged by the colocation provider. Secondly, my
> question
> > was more about the expenses, as opposed to the technical costs/benefits.
> I
> > have browsed through the "Peering Playbook", but I think its more about
> > providing a case "settlement free" peering.
>
> Dude, how are you going to weigh up the costs and benefits of peering
> if you don't include the "costs". I refer you back to the same
> documented I referred you to yesterday...
>
> > On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbensley at gmail.com>
> wrote:
> >>
> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2&pli=1#
>
>
> This time look at section 4 of this huge and hard to navigate
> document, "4. Peering Costs":
>
>
> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit#heading=h.nqqauszv8vj
>
>
> Loosely extrapolating:
>
> Network transport: You need to be physically connected unless you
> blagged space in the same rack and can patch in for free.
>
> Hardware: You need tin to route packets.
>
> Software: You need software to monitor the packet routing.
>
> Colocation: You need space/power/cooler/security in which the tin can
> operate.
>
> Staffing costs: Someone has to configure that tin.
>
> Admin/engineering overhead: Someone has to manage the peering process
>
> Peering port: You probably have to pay to peer.
>
> Reseller ports: You might need remote connectivity to the LAN and
> "network transport" above would refer to a cross connect to the remote
> peering provider instead of directly into the IXP LAN.
>
>
>
> James.
>
>

From bill.norton at gmail.com  Tue Dec 22 23:13:13 2015
From: bill.norton at gmail.com (Bill Norton)
Date: Tue, 22 Dec 2015 15:13:13 -0800
Subject: interconnection costs
In-Reply-To: <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
Message-ID: <45245668-6560-4D6E-B6FA-F766315912D8@gmail.com>

Hi Reza - 

When researching the costs of peering you should perhaps categorize into the most popular forms of peering.

Public (many-to-many) peering solutions vs. private (one-to-one)
--------------------------------------------------------------------------------------
There are of course many opinions on the merits of public peering vs. private peering, economically, technically, and strategically, but the unit cost per bit varies in both cases based on how much traffic is exchanged. The unit cost is the cost of peering divided by the amount of traffic peered, giving us a measure in $/Mbps. Network operators often compare this against the unit cost of transit, and make their decisions based primarily on cost. Generally I have seen content and cloud companies care more about the end-user experience and less about the cost of delivering the bits. To them peering directly provides better connectivity, so even if it costs more that Internet Transit it is often strategic to do so to improve the end-user experience. We now have data to back this improved end-user experience.

Remote Peering 
----------------------
And then consider that one can remove the capital costs and reduce the opex for public and private peering through a technique called remote peering (aka ?tethering?) into the well populated IXPs. 

Here we can remove the cost of the routers (amortized to thousands per month typically), opex for powered colocation (maybe thousands per month) and deployment costs. The transport cost remains. One write up I did in The Internet Peering Playbook showed that remote peering into an IXP can be had for about the cost of the transport alone. I also collected the religious arguments from the field highlighting the arguments for and against remote peering. This can be found in the book as well as in this blog:

http://drpeering.net/AskDrPeering/blog/articles/Ask_DrPeering/Entries/2012/9/18_The_Great_Remote_Peering_Debate.html <http://drpeering.net/AskDrPeering/blog/articles/Ask_DrPeering/Entries/2012/9/18_The_Great_Remote_Peering_Debate.html>

I hope this helps -

Bill 

> On Dec 22, 2015, at 11:11 AM, Reza Motamedi <motamedi at cs.uoregon.edu> wrote:
> 
> Thanks guys for the replies.
> 
> I wanted to clarify two things in my questions. First by peering I did not
> necessarily mean "settlement free" interconnection. I meant any inter-AS
> connection. My understanding is that in addition to the cost of transit
> that should be paid to the transit provider, there also exists the cost of
> the xconnect that is charged by the colocation provider. Secondly, my
> question was more about the expenses, as opposed to the technical
> costs/benefits. I have browsed through the "Peering Playbook", but I think
> its more about providing a case "settlement free" peering.
> 
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon
> 
> On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbensley at gmail.com> wrote:
> 
>> On 22 December 2015 at 16:44, Reza Motamedi <motamedi at cs.uoregon.edu>
>> wrote:
>>> I think there is no single answer as different businesses may have
>>> different pricing models. I hope the discussion can help me understand
>> the
>>> whole ecosystem a little bit better.
>> 
>> 
>> Hi Reza,
>> 
>> I have a list of example items that need to be costed in below, it is
>> by no means a definitive list though:
>> 
>> 
>> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2&pli=1#
>> 
>> 
>> Cheers,
>> James.
>> 
>> 


From baldur.norddahl at gmail.com  Wed Dec 23 22:12:42 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Wed, 23 Dec 2015 23:12:42 +0100
Subject: interconnection costs
In-Reply-To: <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
Message-ID: <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>

On 23 December 2015 at 20:05, Reza Motamedi <motamedi at cs.uoregon.edu> wrote:

> In Private peering however the AS pays the colo provider for the xconnect
> per ASes that it wants to peer with. The cost of transit would be
> additional if the peering is in fact a transit and not settlement free.
>

You are still assuming there is a colo. But perhaps the most common case is
a multihomed company buying transit from two independent service providers.
The customer is at his office and the two service providers will have their
end somewhere in the city, perhaps even terminating their end of the
circuit in a street cabinet. The customer is multihomed and therefore has
his own AS. This is a peering situation with three AS numbers that fits
your description, it is private peering and there is no xconnect. Instead
there is usually a leased line cost, but this cost is often hidden from the
customer. Also the ISP might own the line (physical fiber) and the cost is
not a simple $/month.

But also two ISPs might peer in this way. Residual internet providers have
a ton of points of presences, so why choose a place where there is a
xconnect fee? We can peer anywhere in the city, including at a random
street cabinet. Often the cost of renting a dark fiber somewhere is lower
than a xconnect fee (a sign that datacenter owners are too greedy).

If one party is a content provider I give you that the peering point is
usually at a datacenter somewhere. But still, if the content provider is
big enough to run their own datacenter, we are back at the leased line case
again. Some content providers, even if small, prefer to just run their own
datacenter in the basement of their offices.

Regards,

Baldur

From motamedi at cs.uoregon.edu  Thu Dec 24 00:39:11 2015
From: motamedi at cs.uoregon.edu (Reza Motamedi)
Date: Wed, 23 Dec 2015 16:39:11 -0800
Subject: interconnection costs
In-Reply-To: <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
 <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
Message-ID: <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>

Aren't availability, guaranteed service and remote hands an incentive to do
peering inside a third party colocation?

I see very large numbers for xconnects for instance in Equnix [
https://blog.equinix.com/2013/08/equinix-cross-connects-hit-110000/] and it
made me believe buying xconnect is still a normal practice.

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Dec 23, 2015 at 2:12 PM, Baldur Norddahl <baldur.norddahl at gmail.com>
wrote:

>
>
> On 23 December 2015 at 20:05, Reza Motamedi <motamedi at cs.uoregon.edu>
> wrote:
>
>> In Private peering however the AS pays the colo provider for the xconnect
>> per ASes that it wants to peer with. The cost of transit would be
>> additional if the peering is in fact a transit and not settlement free.
>>
>
> You are still assuming there is a colo. But perhaps the most common case
> is a multihomed company buying transit from two independent service
> providers. The customer is at his office and the two service providers will
> have their end somewhere in the city, perhaps even terminating their end of
> the circuit in a street cabinet. The customer is multihomed and therefore
> has his own AS. This is a peering situation with three AS numbers that fits
> your description, it is private peering and there is no xconnect. Instead
> there is usually a leased line cost, but this cost is often hidden from the
> customer. Also the ISP might own the line (physical fiber) and the cost is
> not a simple $/month.
>
> But also two ISPs might peer in this way. Residual internet providers have
> a ton of points of presences, so why choose a place where there is a
> xconnect fee? We can peer anywhere in the city, including at a random
> street cabinet. Often the cost of renting a dark fiber somewhere is lower
> than a xconnect fee (a sign that datacenter owners are too greedy).
>
> If one party is a content provider I give you that the peering point is
> usually at a datacenter somewhere. But still, if the content provider is
> big enough to run their own datacenter, we are back at the leased line case
> again. Some content providers, even if small, prefer to just run their own
> datacenter in the basement of their offices.
>
> Regards,
>
> Baldur
>
>

From Valdis.Kletnieks at vt.edu  Thu Dec 24 02:04:27 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 23 Dec 2015 21:04:27 -0500
Subject: interconnection costs
In-Reply-To: <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
 <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
 <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
Message-ID: <107714.1450922667@turing-police.cc.vt.edu>

On Wed, 23 Dec 2015 16:39:11 -0800, Reza Motamedi said:
> Aren't availability, guaranteed service and remote hands an incentive to do
> peering inside a third party colocation?

Sure.  But there are places in the US where you have to decide whether the
cost of lighting 300 miles of fiber to the colo is worth the benefits, when
the other option is lighting fiber to a street cabinet across town.
-------------- 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/20151223/37e4ab83/attachment.pgp>

From baldur.norddahl at gmail.com  Thu Dec 24 02:10:14 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 24 Dec 2015 03:10:14 +0100
Subject: interconnection costs
In-Reply-To: <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
 <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
 <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
Message-ID: <CAPkb-7CAnResV8n2O2+KfbZ0vKLO_r-GazNK_JK1_+enr8f-mA@mail.gmail.com>

Hi,

The counter example is the Netnod Stockholm IX that allows you to connect
via dark fiber from anywhere within Stockholm. The other large european
exchanges also offer multiple connection options.

"Aren't availability, guaranteed service and remote hands an incentive to
do peering inside a third party colocation? "

That really depends on your situation and who you are. As a residential ISP
our business is not in a DC. If we have any equipment at all there, it
would only be a router. But usually we do not want a router there, we just
want a connection. So in fact we do not want access to the facility at all.

If you are a content provider, you might have servers and what not. Then
sure. Or if you are large IP transit provider, you might want to host a
router, so you can sell to other customers at the DC (if it is a transit
neutral DC).

This is why we now see the rise of remote peering.

Regards,

Baldur



On 24 December 2015 at 01:39, Reza Motamedi <motamedi at cs.uoregon.edu> wrote:

> Aren't availability, guaranteed service and remote hands an incentive to
> do peering inside a third party colocation?
>
> I see very large numbers for xconnects for instance in Equnix [
> https://blog.equinix.com/2013/08/equinix-cross-connects-hit-110000/] and
> it made me believe buying xconnect is still a normal practice.
>
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon
>
> On Wed, Dec 23, 2015 at 2:12 PM, Baldur Norddahl <
> baldur.norddahl at gmail.com> wrote:
>
>>
>>
>> On 23 December 2015 at 20:05, Reza Motamedi <motamedi at cs.uoregon.edu>
>> wrote:
>>
>>> In Private peering however the AS pays the colo provider for the xconnect
>>> per ASes that it wants to peer with. The cost of transit would be
>>> additional if the peering is in fact a transit and not settlement free.
>>>
>>
>> You are still assuming there is a colo. But perhaps the most common case
>> is a multihomed company buying transit from two independent service
>> providers. The customer is at his office and the two service providers will
>> have their end somewhere in the city, perhaps even terminating their end of
>> the circuit in a street cabinet. The customer is multihomed and therefore
>> has his own AS. This is a peering situation with three AS numbers that fits
>> your description, it is private peering and there is no xconnect. Instead
>> there is usually a leased line cost, but this cost is often hidden from the
>> customer. Also the ISP might own the line (physical fiber) and the cost is
>> not a simple $/month.
>>
>> But also two ISPs might peer in this way. Residual internet providers
>> have a ton of points of presences, so why choose a place where there is a
>> xconnect fee? We can peer anywhere in the city, including at a random
>> street cabinet. Often the cost of renting a dark fiber somewhere is lower
>> than a xconnect fee (a sign that datacenter owners are too greedy).
>>
>> If one party is a content provider I give you that the peering point is
>> usually at a datacenter somewhere. But still, if the content provider is
>> big enough to run their own datacenter, we are back at the leased line case
>> again. Some content providers, even if small, prefer to just run their own
>> datacenter in the basement of their offices.
>>
>> Regards,
>>
>> Baldur
>>
>>
>

From baldur.norddahl at gmail.com  Thu Dec 24 02:13:02 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 24 Dec 2015 03:13:02 +0100
Subject: interconnection costs
In-Reply-To: <107714.1450922667@turing-police.cc.vt.edu>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
 <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
 <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
 <107714.1450922667@turing-police.cc.vt.edu>
Message-ID: <CAPkb-7AohjKYarF8Y7LjzJ0COB4_eSxMvNggbA=v0a5rhx3fTg@mail.gmail.com>

On 24 December 2015 at 03:04, <Valdis.Kletnieks at vt.edu> wrote:

> On Wed, 23 Dec 2015 16:39:11 -0800, Reza Motamedi said:
> > Aren't availability, guaranteed service and remote hands an incentive to
> do
> > peering inside a third party colocation?
>
> Sure.  But there are places in the US where you have to decide whether the
> cost of lighting 300 miles of fiber to the colo is worth the benefits, when
> the other option is lighting fiber to a street cabinet across town.
>

Also remember that 300 miles of fiber is going to go through a dozen of
street cabinets to get there.

Regards,

Baldur

From lorell at hathcock.org  Thu Dec 24 02:49:38 2015
From: lorell at hathcock.org (Lorell Hathcock)
Date: Wed, 23 Dec 2015 20:49:38 -0600
Subject: Broadband Router Comparisons
Message-ID: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>

All:

Not all consumer grade customer premises equipment is created equally.  But end customers sure think it is.  I have retirement aged customers buying the crappiest routers and then blaming my cable network for all their connection woes.  The real problem is that there were plenty of problems on the cable network to deal with, so it was impossible to tell between a problem that a customer was having with their CPE versus a real problem in my network.

Much of that has been cleared up on my side now, but customers were used to blaming us for everything so that they don't even consider that their equipment could be to blame.

I want to be able to point out a third party list of all (most) broadband routers that rates them by performance.  Or that rates them by crappiness that I can send them to so they can look up their own router and determine if other users have had problems with that router and what can be done to fix it.

So far my search has been in vain.

Any thoughts?

Thanks in advance.

Lorell Hathcock

Sent from my iPad

From josh at imaginenetworksllc.com  Thu Dec 24 02:52:02 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Wed, 23 Dec 2015 21:52:02 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
Message-ID: <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>

Have the customer bypass the router.  Why suggest another router that may
have problems in the future that you ended up getting blamed for?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Wed, Dec 23, 2015 at 9:49 PM, Lorell Hathcock <lorell at hathcock.org>
wrote:

> All:
>
> Not all consumer grade customer premises equipment is created equally.
> But end customers sure think it is.  I have retirement aged customers
> buying the crappiest routers and then blaming my cable network for all
> their connection woes.  The real problem is that there were plenty of
> problems on the cable network to deal with, so it was impossible to tell
> between a problem that a customer was having with their CPE versus a real
> problem in my network.
>
> Much of that has been cleared up on my side now, but customers were used
> to blaming us for everything so that they don't even consider that their
> equipment could be to blame.
>
> I want to be able to point out a third party list of all (most) broadband
> routers that rates them by performance.  Or that rates them by crappiness
> that I can send them to so they can look up their own router and determine
> if other users have had problems with that router and what can be done to
> fix it.
>
> So far my search has been in vain.
>
> Any thoughts?
>
> Thanks in advance.
>
> Lorell Hathcock
>
> Sent from my iPad

From lorell at hathcock.org  Thu Dec 24 03:38:05 2015
From: lorell at hathcock.org (Lorell Hathcock)
Date: Wed, 23 Dec 2015 21:38:05 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
Message-ID: <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>

Josh:

That's a good troubleshooting technique when the customer is cooperative and technically competent.

I am looking for a third party list to which I may point that rates all/most routers on the market.  This list would not have my input on it at all.  If a router from the list winds up being bad, it is not my fault because it is third party.  

Such a list would help shift the conversation from blaming us at the ISP by default to casting doubt on the CPE device where the blame now rightly resides.

I've checked the primary search engine for such a thing a list.  I get a lot of ads for broadband routers.  A search on dslreports.com yields nothing useful.  pcmag.com wants to tell me about $150-$300 routers new to the market in 2015.  

I just need a comprehensive list of routers with ratings.  A couple of user reviews about routers going bad would also be nice!

Thanks,

Lorell Hathcock



Sent from my iPad

> On Dec 23, 2015, at 8:52 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
> 
> Have the customer bypass the router.  Why suggest another router that may have problems in the future that you ended up getting blamed for?
> 
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
>> On Wed, Dec 23, 2015 at 9:49 PM, Lorell Hathcock <lorell at hathcock.org> wrote:
>> All:
>> 
>> Not all consumer grade customer premises equipment is created equally.  But end customers sure think it is.  I have retirement aged customers buying the crappiest routers and then blaming my cable network for all their connection woes.  The real problem is that there were plenty of problems on the cable network to deal with, so it was impossible to tell between a problem that a customer was having with their CPE versus a real problem in my network.
>> 
>> Much of that has been cleared up on my side now, but customers were used to blaming us for everything so that they don't even consider that their equipment could be to blame.
>> 
>> I want to be able to point out a third party list of all (most) broadband routers that rates them by performance.  Or that rates them by crappiness that I can send them to so they can look up their own router and determine if other users have had problems with that router and what can be done to fix it.
>> 
>> So far my search has been in vain.
>> 
>> Any thoughts?
>> 
>> Thanks in advance.
>> 
>> Lorell Hathcock
>> 
>> Sent from my iPad
> 

From dan at drakontas.org  Thu Dec 24 03:42:41 2015
From: dan at drakontas.org (Daniel C. Eckert)
Date: Wed, 23 Dec 2015 22:42:41 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
Message-ID: <CAGNc-gD0cMG=YF=c7bSg6bioVnS1Gugq58fvs4E0s1g49y9MZA@mail.gmail.com>

For a place to find reviews about specific models, I'd just point them to
the product pages on Amazon and emphasize the ratings and narrative
descriptions.  Maybe not the most "scientific" method, but as long as the
reviews posted align with your observations/assessment of a particular
model, you've got a starting point there.  Maybe compile a list of direct
links for models you often see customers trying, so your CSRs can
copy/paste them without research.

Unfortunately, I'm not aware of a repository like you're describing with
your request, though.

Dan

On Wed, Dec 23, 2015 at 10:38 PM, Lorell Hathcock <lorell at hathcock.org>
wrote:

> Josh:
>
> That's a good troubleshooting technique when the customer is cooperative
> and technically competent.
>
> I am looking for a third party list to which I may point that rates
> all/most routers on the market.  This list would not have my input on it at
> all.  If a router from the list winds up being bad, it is not my fault
> because it is third party.
>
> Such a list would help shift the conversation from blaming us at the ISP
> by default to casting doubt on the CPE device where the blame now rightly
> resides.
>
> I've checked the primary search engine for such a thing a list.  I get a
> lot of ads for broadband routers.  A search on dslreports.com yields
> nothing useful.  pcmag.com wants to tell me about $150-$300 routers new
> to the market in 2015.
>
> I just need a comprehensive list of routers with ratings.  A couple of
> user reviews about routers going bad would also be nice!
>
> Thanks,
>
> Lorell Hathcock
>
>
>
> Sent from my iPad
>
> > On Dec 23, 2015, at 8:52 PM, Josh Luthman <josh at imaginenetworksllc.com>
> wrote:
> >
> > Have the customer bypass the router.  Why suggest another router that
> may have problems in the future that you ended up getting blamed for?
> >
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> >> On Wed, Dec 23, 2015 at 9:49 PM, Lorell Hathcock <lorell at hathcock.org>
> wrote:
> >> All:
> >>
> >> Not all consumer grade customer premises equipment is created equally.
> But end customers sure think it is.  I have retirement aged customers
> buying the crappiest routers and then blaming my cable network for all
> their connection woes.  The real problem is that there were plenty of
> problems on the cable network to deal with, so it was impossible to tell
> between a problem that a customer was having with their CPE versus a real
> problem in my network.
> >>
> >> Much of that has been cleared up on my side now, but customers were
> used to blaming us for everything so that they don't even consider that
> their equipment could be to blame.
> >>
> >> I want to be able to point out a third party list of all (most)
> broadband routers that rates them by performance.  Or that rates them by
> crappiness that I can send them to so they can look up their own router and
> determine if other users have had problems with that router and what can be
> done to fix it.
> >>
> >> So far my search has been in vain.
> >>
> >> Any thoughts?
> >>
> >> Thanks in advance.
> >>
> >> Lorell Hathcock
> >>
> >> Sent from my iPad
> >
>

From faisal at snappytelecom.net  Thu Dec 24 04:08:53 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Thu, 24 Dec 2015 04:08:53 +0000 (GMT)
Subject: interconnection costs
In-Reply-To: <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
 <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
 <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
Message-ID: <214724016.1733032.1450930133320.JavaMail.zimbra@snappytelecom.net>

Hi Reza,

There is some terminology and view point confusion... 

First of all, it is Network(s) which connect with Other Networks using AS #, not AS's which connect with each other. (In a particular view (Routing) it could be said that AS's connect with each other).

Second, A connection (interconnection) is just that...as simple as a piece of cable that is connecting two routers together (routers are next to each other)....In a complex example, the two routers can be in different parts of the world.

Today we take Colo Providers for granted, in realty they merely provide " Rent a Data Center" +  "Rent other services on demand".
Originally these folks used to make their money by renting space, power, cooling  etc.. However they have figured out over the years that they can make a lot more money by 'renting' a piece of wire, and lately they trend is to extract as much money they possibly can for renting these wires as they can get.... These are the x-connect charges... 

Other have pointed out that 'peering' comes in many flavors, and it can be argued that IP Transit (aka internet access) is the top of the paid peering interconnection type.

There are a number of 'Eco-systems' in play if you want to look at the whole picture. There are Last Mile network, Middle Mile Networks, Long Haul Networks, Data Center(s), Peering Fabric's etc.

Today connectivity decisions are influenced by Location, Cost of getting to that Location, and Cost of having Presence at that location. Which in turning out to be more and more dictated by Long Haul connectivity providers and mostly by the terms and conditions of the Colo Providers. Older Colo's where lots of major carriers are present, tend to be the most arrogant, expensive and challenging companies to do business with, however their competitors who tend to be far more reasonable and cooperative to work with, are lacking in their list of 'Networks' that one can connect with...thus forcing difficult decisions.

Another interesting thing to note is that Different Markets have Different Colo Folks holding the 'premier' position, and they pretty much all act that way in those markets, the same operator in other markets where they don't have a lead position are much more reasonable to work with, (and there are always some exceptions).

So from a network (ISP) operator's perspective the following appears to be options listed in graduating manner.

        1)  Buy IP Transit from who every is available (Typically a very limited choice if any, and pretty much no negotiating leverage)
        2)  Buy Middle Mile transport to nearest Data Center in Town. (Better options than 1, unless the D.C. is a major one, otherwise still limited options)
        3)  Buy Long Haul to nearest Major Data Center...(Better options then 2, costs get to be interesting).
        4)  Buy Long Haul to nearest Major Data Center and establish a POP at the DC    
        5)  Buy Long Haul to nearest Major Data Center and establish a POP at that DC and extend your connections to other DC for connectivity (because who you want to connect to is not present in the other Data Center).
        6)  Buy Multiple Long Haul to different Major Data Center and establish POP and connectivity etc etc etc.

So after painting this picture... What costs do you want to analyze ? Not everyone is building networks in the same manner..

:)




Faisal Imtiaz
Snappy Internet & Telecom


----- Original Message -----
> From: "Reza Motamedi" <motamedi at cs.uoregon.edu>
> To: "Baldur Norddahl" <baldur.norddahl at gmail.com>
> Cc: "nanog list" <nanog at nanog.org>
> Sent: Wednesday, December 23, 2015 7:39:11 PM
> Subject: Re: interconnection costs

> Aren't availability, guaranteed service and remote hands an incentive to do
> peering inside a third party colocation?
> 
> I see very large numbers for xconnects for instance in Equnix [
> https://blog.equinix.com/2013/08/equinix-cross-connects-hit-110000/] and it
> made me believe buying xconnect is still a normal practice.
> 
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon
> 
> On Wed, Dec 23, 2015 at 2:12 PM, Baldur Norddahl <baldur.norddahl at gmail.com>
> wrote:
> 
>>
>>
>> On 23 December 2015 at 20:05, Reza Motamedi <motamedi at cs.uoregon.edu>
>> wrote:
>>
>>> In Private peering however the AS pays the colo provider for the xconnect
>>> per ASes that it wants to peer with. The cost of transit would be
>>> additional if the peering is in fact a transit and not settlement free.
>>>
>>
>> You are still assuming there is a colo. But perhaps the most common case
>> is a multihomed company buying transit from two independent service
>> providers. The customer is at his office and the two service providers will
>> have their end somewhere in the city, perhaps even terminating their end of
>> the circuit in a street cabinet. The customer is multihomed and therefore
>> has his own AS. This is a peering situation with three AS numbers that fits
>> your description, it is private peering and there is no xconnect. Instead
>> there is usually a leased line cost, but this cost is often hidden from the
>> customer. Also the ISP might own the line (physical fiber) and the cost is
>> not a simple $/month.
>>
>> But also two ISPs might peer in this way. Residual internet providers have
>> a ton of points of presences, so why choose a place where there is a
>> xconnect fee? We can peer anywhere in the city, including at a random
>> street cabinet. Often the cost of renting a dark fiber somewhere is lower
>> than a xconnect fee (a sign that datacenter owners are too greedy).
>>
>> If one party is a content provider I give you that the peering point is
>> usually at a datacenter somewhere. But still, if the content provider is
>> big enough to run their own datacenter, we are back at the leased line case
>> again. Some content providers, even if small, prefer to just run their own
>> datacenter in the basement of their offices.
>>
>> Regards,
>>
>> Baldur
>>

From joly at punkcast.com  Thu Dec 24 05:08:00 2015
From: joly at punkcast.com (Joly MacFie)
Date: Thu, 24 Dec 2015 00:08:00 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
Message-ID: <CAM9VJk0E56u4F-1cAiHsr3iwA9YZwExiv7zVzhPSLj0ZTd9VLw@mail.gmail.com>

?Paywalled, but
http://www.consumerreports.org/cro/wireless-routers/buying-guide.htm

?

On Wed, Dec 23, 2015 at 9:49 PM, Lorell Hathcock <lorell at hathcock.org>
wrote:

> All:
>
> Not all consumer grade customer premises equipment is created equally.
> But end customers sure think it is.  I have retirement aged customers
> buying the crappiest routers and then blaming my cable network for all
> their connection woes.  The real problem is that there were plenty of
> problems on the cable network to deal with, so it was impossible to tell
> between a problem that a customer was having with their CPE versus a real
> problem in my network.
>
> Much of that has been cleared up on my side now, but customers were used
> to blaming us for everything so that they don't even consider that their
> equipment could be to blame.
>
> I want to be able to point out a third party list of all (most) broadband
> routers that rates them by performance.  Or that rates them by crappiness
> that I can send them to so they can look up their own router and determine
> if other users have had problems with that router and what can be done to
> fix it.
>
> So far my search has been in vain.
>
> Any thoughts?
>
> Thanks in advance.
>
> Lorell Hathcock
>
> Sent from my iPad




-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-

From seth.mos at dds.nl  Thu Dec 24 05:54:34 2015
From: seth.mos at dds.nl (Seth Mos)
Date: Thu, 24 Dec 2015 06:54:34 +0100
Subject: Broadband Router Comparisons
Message-ID: <fnhuv26j9t4hhpmvgphptkp2.1450936018174@email.android.com>

Smallnetbuilder.com has quite a few models of routers tested, which is decent. I've bugged them about ipv6 testing before but not too much progress there. Powerconsumption is not listed either, which can be as expensive as the router itself at 21 cents per kWh.

Regards,
Seth


-------- Oorspronkelijk bericht --------
Van: Lorell Hathcock <lorell at hathcock.org> 
Datum: 24-12-2015  03:49  (GMT+01:00) 
Aan: nanog at nanog.org 
Onderwerp: Broadband Router Comparisons 

All:

Not all consumer grade customer premises equipment is created equally.  But end customers sure think it is.  I have retirement aged customers buying the crappiest routers and then blaming my cable network for all their connection woes.  The real problem is that there were plenty of problems on the cable network to deal with, so it was impossible to tell between a problem that a customer was having with their CPE versus a real problem in my network.

Much of that has been cleared up on my side now, but customers were used to blaming us for everything so that they don't even consider that their equipment could be to blame.

I want to be able to point out a third party list of all (most) broadband routers that rates them by performance.  Or that rates them by crappiness that I can send them to so they can look up their own router and determine if other users have had problems with that router and what can be done to fix it.

So far my search has been in vain.

Any thoughts?

Thanks in advance.

Lorell Hathcock

Sent from my iPad

From rs-lists at seastrom.com  Thu Dec 24 13:58:55 2015
From: rs-lists at seastrom.com (Rob Seastrom)
Date: Thu, 24 Dec 2015 08:58:55 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
Message-ID: <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>


> On Dec 23, 2015, at 10:38 PM, Lorell Hathcock <lorell at hathcock.org> wrote:
> 
> That's a good troubleshooting technique when the customer is cooperative and technically competent.

... and has ethernet on anything in the house, which is increasingly a bad thing to rely on.  Got an iPad, a smart phone, and a MacBook Air (any revision)?  Two of the three have substantially no support for hardwired Ethernet.  The third requires an external USB adaptor.  "Go out and buy this $24 gizmo so we can confirm that your $29 router/wireless device is indeed crap" is a hard thing to get most people to do.

-r



From baldur.norddahl at gmail.com  Thu Dec 24 15:05:21 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 24 Dec 2015 16:05:21 +0100
Subject: Broadband Router Comparisons
In-Reply-To: <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
Message-ID: <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>

I have reasonable success with simply lending the customer a router. In
most cases they will then buy it afterwards, because it turns out that
their old router was indeed bad.

But you can not win them all. Sometimes it is the other equipment that is
bad, or the customer is clueless. They might even be lying because everyone
knows you have to pretend it is worse than it actually is to get the doctor
to take you seriously. Also who here can honestly say you never pretended
to power cycle your Windows 95 when asked by the support bot on the phone,
while actually running Linux, because that is the only way to get passed on
to second tier support?

Just last week I had a customer complaining his router was bad. I went out
there and found it in the basement, on the floor, under a bed with a ton of
crap on top. He said it was so much worse than his old internet, where he
had the router in the center of the house in his living room. Not too
surprisingly? He claimed the routers were located the same place until I
turned up at his house and asked to see it...

I do not think you will have much success at pointing to a list of
supposedly bad routers. The world is just too complex. A bad experience can
be due to anything really. Most likely they are on 2,4 GHz and the spectrum
is crowded. Combine with an old computer (or even brand new!) that has crap
2,4 GHz wifi - nothing a router can do about that. I demonstrate that it
can work with my own computer and then advise the customer on what to buy.

Regards,

Baldur

From lists at mtin.net  Thu Dec 24 15:40:00 2015
From: lists at mtin.net (Justin Wilson)
Date: Thu, 24 Dec 2015 10:40:00 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
Message-ID: <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>

The trend is a managed router service.  This way the ISP can control the customer experience a little better.  It also gives the ISP a DMARC point to test from, which is not as reliant on getting the customer involved. 

Mikrotik makes the hAP lite, which has a retail of $21.95.  http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html <http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html>  .  This is *nix based router you can cheaply deploy even if a customer doesn?t want a managed router.  I have clients who deploy this as a ?modem? if the customer chooses their own router.  By doing this the ISP can run pings, traceroutes, see usage, and other useful tools from the customer side.

Once you figure on your average support call on troubleshooting a customer router $21.95 is a drop in the bucket. Having a place to test from the customer side is invaluable.  Tons of tricks you can do too.  Turn on the wireless and have the customer connect to it.  Block out all traffic except what the customer is using for tests (i.e. wireless) so you can see if there are devices hogging the pipe.   You can do frequency scans to see how bad 2.4 is.    You can get a dual band hAP router with AC.  It is more expensive so deploying one of those at every customer might not be feasible. 


Justin Wilson
j2sw at mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting ? Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman

> On Dec 24, 2015, at 10:05 AM, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> I have reasonable success with simply lending the customer a router. In
> most cases they will then buy it afterwards, because it turns out that
> their old router was indeed bad.
> 
> But you can not win them all. Sometimes it is the other equipment that is
> bad, or the customer is clueless. They might even be lying because everyone
> knows you have to pretend it is worse than it actually is to get the doctor
> to take you seriously. Also who here can honestly say you never pretended
> to power cycle your Windows 95 when asked by the support bot on the phone,
> while actually running Linux, because that is the only way to get passed on
> to second tier support?
> 
> Just last week I had a customer complaining his router was bad. I went out
> there and found it in the basement, on the floor, under a bed with a ton of
> crap on top. He said it was so much worse than his old internet, where he
> had the router in the center of the house in his living room. Not too
> surprisingly? He claimed the routers were located the same place until I
> turned up at his house and asked to see it...
> 
> I do not think you will have much success at pointing to a list of
> supposedly bad routers. The world is just too complex. A bad experience can
> be due to anything really. Most likely they are on 2,4 GHz and the spectrum
> is crowded. Combine with an old computer (or even brand new!) that has crap
> 2,4 GHz wifi - nothing a router can do about that. I demonstrate that it
> can work with my own computer and then advise the customer on what to buy.
> 
> Regards,
> 
> Baldur
> 


From kmedcalf at dessus.com  Thu Dec 24 16:58:49 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Thu, 24 Dec 2015 09:58:49 -0700
Subject: Broadband Router Comparisons
In-Reply-To: <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
Message-ID: <76d6e6175f3bfa47b08b2951d0e43a02@mail.dessus.com>

> to take you seriously. Also who here can honestly say you never pretended
> to power cycle your Windows 95 when asked by the support bot on the phone,
> while actually running Linux, because that is the only way to get passed
> on to second tier support?

I can honestly say that I have told support droids that I am rebooting "Windows" while actually running zOS.  Support droids have a definite problem with comprehending "No Transport" ...

I have even called to report a border router down on their network.  They complain and want to plug, unplug and reboot.  It isn't until 20 minutes later when the call volume exceeds the "geez there must be something wrong with our network" limit that someone actually bother to look and see where the problem is really located.





From frnkblk at iname.com  Thu Dec 24 19:01:45 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 24 Dec 2015 13:01:45 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
Message-ID: <001101d13e7d$896a8a70$9c3f9f50$@iname.com>

+1.

Here's one managed option that non-Calix customers, such as WISPs, have found interesting: https://www.calix.com/systems/gigafamily-overview/GigaCenters.html

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Wilson
Sent: Thursday, December 24, 2015 9:40 AM
To: nanog at nanog.org
Subject: Re: Broadband Router Comparisons

The trend is a managed router service.  This way the ISP can control the customer experience a little better.  It also gives the ISP a DMARC point to test from, which is not as reliant on getting the customer involved. 

Mikrotik makes the hAP lite, which has a retail of $21.95.  http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html <http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html>  .  This is *nix based router you can cheaply deploy even if a customer doesn?t want a managed router.  I have clients who deploy this as a ?modem? if the customer chooses their own router.  By doing this the ISP can run pings, traceroutes, see usage, and other useful tools from the customer side.

Once you figure on your average support call on troubleshooting a customer router $21.95 is a drop in the bucket. Having a place to test from the customer side is invaluable.  Tons of tricks you can do too.  Turn on the wireless and have the customer connect to it.  Block out all traffic except what the customer is using for tests (i.e. wireless) so you can see if there are devices hogging the pipe.   You can do frequency scans to see how bad 2.4 is.    You can get a dual band hAP router with AC.  It is more expensive so deploying one of those at every customer might not be feasible. 


Justin Wilson
j2sw at mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting ? Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman

> On Dec 24, 2015, at 10:05 AM, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> I have reasonable success with simply lending the customer a router. In
> most cases they will then buy it afterwards, because it turns out that
> their old router was indeed bad.
> 
> But you can not win them all. Sometimes it is the other equipment that is
> bad, or the customer is clueless. They might even be lying because everyone
> knows you have to pretend it is worse than it actually is to get the doctor
> to take you seriously. Also who here can honestly say you never pretended
> to power cycle your Windows 95 when asked by the support bot on the phone,
> while actually running Linux, because that is the only way to get passed on
> to second tier support?
> 
> Just last week I had a customer complaining his router was bad. I went out
> there and found it in the basement, on the floor, under a bed with a ton of
> crap on top. He said it was so much worse than his old internet, where he
> had the router in the center of the house in his living room. Not too
> surprisingly? He claimed the routers were located the same place until I
> turned up at his house and asked to see it...
> 
> I do not think you will have much success at pointing to a list of
> supposedly bad routers. The world is just too complex. A bad experience can
> be due to anything really. Most likely they are on 2,4 GHz and the spectrum
> is crowded. Combine with an old computer (or even brand new!) that has crap
> 2,4 GHz wifi - nothing a router can do about that. I demonstrate that it
> can work with my own computer and then advise the customer on what to buy.
> 
> Regards,
> 
> Baldur
> 




From jason at thebaughers.com  Thu Dec 24 19:02:49 2015
From: jason at thebaughers.com (Jason Baugher)
Date: Thu, 24 Dec 2015 13:02:49 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
Message-ID: <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>

Providing a managed service is the direction we're going. In our case,
since we're a Calix shop, we're using their GigaCenters, but I'm sure there
are other vendor options out there.

Early indications are that 95+% of our residential customers would rather
pay a nominal "maintenance" fee and use our managed router than purchase
their own. From our end, we get a little more revenue, we ensure our
customers aren't blaming us for problems caused by junk routers, and we
provide a level of service and support that the big guys can't even come
close to matching.

On Thu, Dec 24, 2015 at 9:40 AM, Justin Wilson <lists at mtin.net> wrote:

> The trend is a managed router service.  This way the ISP can control the
> customer experience a little better.  It also gives the ISP a DMARC point
> to test from, which is not as reliant on getting the customer involved.
>
> Mikrotik makes the hAP lite, which has a retail of $21.95.
> http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html
> <
> http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html>
> .  This is *nix based router you can cheaply deploy even if a customer
> doesn?t want a managed router.  I have clients who deploy this as a ?modem?
> if the customer chooses their own router.  By doing this the ISP can run
> pings, traceroutes, see usage, and other useful tools from the customer
> side.
>
> Once you figure on your average support call on troubleshooting a customer
> router $21.95 is a drop in the bucket. Having a place to test from the
> customer side is invaluable.  Tons of tricks you can do too.  Turn on the
> wireless and have the customer connect to it.  Block out all traffic except
> what the customer is using for tests (i.e. wireless) so you can see if
> there are devices hogging the pipe.   You can do frequency scans to see how
> bad 2.4 is.    You can get a dual band hAP router with AC.  It is more
> expensive so deploying one of those at every customer might not be feasible.
>
>
> Justin Wilson
> j2sw at mtin.net
>
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting ? Data Centers - Bandwidth
>
> http://www.midwest-ix.com  COO/Chairman
>
> > On Dec 24, 2015, at 10:05 AM, Baldur Norddahl <baldur.norddahl at gmail.com>
> wrote:
> >
> > I have reasonable success with simply lending the customer a router. In
> > most cases they will then buy it afterwards, because it turns out that
> > their old router was indeed bad.
> >
> > But you can not win them all. Sometimes it is the other equipment that is
> > bad, or the customer is clueless. They might even be lying because
> everyone
> > knows you have to pretend it is worse than it actually is to get the
> doctor
> > to take you seriously. Also who here can honestly say you never pretended
> > to power cycle your Windows 95 when asked by the support bot on the
> phone,
> > while actually running Linux, because that is the only way to get passed
> on
> > to second tier support?
> >
> > Just last week I had a customer complaining his router was bad. I went
> out
> > there and found it in the basement, on the floor, under a bed with a ton
> of
> > crap on top. He said it was so much worse than his old internet, where he
> > had the router in the center of the house in his living room. Not too
> > surprisingly? He claimed the routers were located the same place until I
> > turned up at his house and asked to see it...
> >
> > I do not think you will have much success at pointing to a list of
> > supposedly bad routers. The world is just too complex. A bad experience
> can
> > be due to anything really. Most likely they are on 2,4 GHz and the
> spectrum
> > is crowded. Combine with an old computer (or even brand new!) that has
> crap
> > 2,4 GHz wifi - nothing a router can do about that. I demonstrate that it
> > can work with my own computer and then advise the customer on what to
> buy.
> >
> > Regards,
> >
> > Baldur
> >
>
>

From colinj at gt86car.org.uk  Thu Dec 24 23:44:10 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Thu, 24 Dec 2015 23:44:10 +0000
Subject: de-peering for security sake 
In-Reply-To: <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
Message-ID: <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>

see
http://map.norsecorp.com

We really need to ask if China and Russia for that matter will not take abuse reports seriously why allow them to network to the internet ?

Colin


From Valdis.Kletnieks at vt.edu  Fri Dec 25 00:48:59 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 24 Dec 2015 19:48:59 -0500
Subject: de-peering for security sake
In-Reply-To: <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
Message-ID: <201874.1451004539@turing-police.cc.vt.edu>

On Thu, 24 Dec 2015 23:44:10 +0000, Colin Johnston said:
> We really need to ask if China and Russia for that matter will not take abuse
> reports seriously why allow them to network to the internet ?

Well, first off, it isn't like China or Russia are just one ASN.  You'd have
to de-peer a bunch of ASN's - and also eliminate any paid transit connections.

Note that even North Korea has managed to land at least a small presence on
the Internet.  Are you going to ban them too?

While we're banning countries, how about the country that's known for
widespread surveillance both foreign and domestic, has one of the strongest
cyber warfare arsenals around, and has been caught multiple times diverting and
backdooring routers sold to foreign countries?

Oh wait, that's the US. Maybe we better rethink this?

Obviously, there's a lot of organizations that think that being able to
communicate with China and Russia outweighs the security issues.  You are
of course welcome to make a list of all Russian and Chinese ASNs and block
their prefixes at your border.
-------------- 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/20151224/9de9a4a7/attachment.pgp>

From dcorbe at hammerfiber.com  Fri Dec 25 00:50:50 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Thu, 24 Dec 2015 19:50:50 -0500
Subject: de-peering for security sake 
In-Reply-To: <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
Message-ID: <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>

Let?s just cut off the entirety of the third world instead of having a tangible mitigation plan in place.

> On Dec 24, 2015, at 6:44 PM, Colin Johnston <colinj at gt86car.org.uk> wrote:
> 
> see
> http://map.norsecorp.com
> 
> We really need to ask if China and Russia for that matter will not take abuse reports seriously why allow them to network to the internet ?
> 
> Colin
> 


From list at satchell.net  Fri Dec 25 01:25:07 2015
From: list at satchell.net (Stephen Satchell)
Date: Thu, 24 Dec 2015 17:25:07 -0800
Subject: de-peering for security sake
In-Reply-To: <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
Message-ID: <567C9AF3.7070207@satchell.net>

On 12/24/2015 04:50 PM, Daniel Corbe wrote:
> Let?s just cut off the entirety of the third world instead of having
> a tangible mitigation plan in place.

While you thing you are making a snarky response, it would be handy for 
end users to be able to turn on and off access to other countries 
retail.  If *they* don't need access to certain third world countries, 
it would be their decision, not the operator's decision.

For example, here on my little network we have no need for connectivity 
to much of Asia, Africa, or India.  We do have need to talk to Europe, 
Australia, and some countries in South America.


From baldur.norddahl at gmail.com  Fri Dec 25 01:41:14 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 25 Dec 2015 02:41:14 +0100
Subject: de-peering for security sake
In-Reply-To: <567C9AF3.7070207@satchell.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
Message-ID: <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>

I am afraid people are already doing this. Every time I bring a new IP
series into production, my users will complain that they are locked out
from sites including many government sites. This is because people will
load IP location lists into their firewall and drop packets at the border.
Of course they will not update said lists and load year old lists into
their firewalls.

So now my users can not access government sites because the IP ranges were
owned by a company in a different country two years ago.

Take a guess on how responsive site owners are when we complain about their
firewall. Most refuse to acknowledge they do any blocking and insist the
problem is at our end. That is if they respond at all.

Regards,

Baldur


On 25 December 2015 at 02:25, Stephen Satchell <list at satchell.net> wrote:

> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>
>> Let?s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
>>
>
> While you thing you are making a snarky response, it would be handy for
> end users to be able to turn on and off access to other countries retail.
> If *they* don't need access to certain third world countries, it would be
> their decision, not the operator's decision.
>
> For example, here on my little network we have no need for connectivity to
> much of Asia, Africa, or India.  We do have need to talk to Europe,
> Australia, and some countries in South America.
>
>

From ops.lists at gmail.com  Fri Dec 25 03:25:24 2015
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 25 Dec 2015 08:55:24 +0530
Subject: de-peering for security sake
In-Reply-To: <567C9AF3.7070207@satchell.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
Message-ID: <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>

Hmm, has anyone at all kept count of the number of times such a discussion has started up in just the last year, and how many more times in the past 16 or so years?

Mind you, back in say 2004, this discussion would have run to 50 or 60 emails at a bare minimum, in no time at all.

--srs

On 25-Dec-2015, at 6:55 AM, Stephen Satchell <list at satchell.net> wrote:

>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>> Let?s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
> 
> While you thing you are making a snarky response, it would be handy for end users to be able to turn on and off access to other countries retail.

From owen at delong.com  Fri Dec 25 03:36:54 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 24 Dec 2015 19:36:54 -0800
Subject: de-peering for security sake
In-Reply-To: <567C9AF3.7070207@satchell.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
Message-ID: <051F260C-EF1D-490B-82F6-32ADDB793FE0@delong.com>


> On Dec 24, 2015, at 17:25 , Stephen Satchell <list at satchell.net> wrote:
> 
> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>> Let?s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
> 
> While you thing you are making a snarky response, it would be handy for end users to be able to turn on and off access to other countries retail.  If *they* don't need access to certain third world countries, it would be their decision, not the operator's decision.
> 
> For example, here on my little network we have no need for connectivity to much of Asia, Africa, or India.  We do have need to talk to Europe, Australia, and some countries in South America.

Yes? Balkanization has been such a wonderful and useful strategy in the physical world, let?s bring it to cyberspace and we should be able to expect the same level of success?

Oh, wait, that wouldn?t be so good. Maybe this should be rethought.

One of the definitions of insanity is doing the same thing over and over again, expecting different results. This would seem to me to fit that particular definition.

Owen


From owen at delong.com  Fri Dec 25 03:38:12 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 24 Dec 2015 19:38:12 -0800
Subject: de-peering for security sake
In-Reply-To: <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>
Message-ID: <D3E92CC3-B4A3-4D5A-973F-520BEF978E49@delong.com>

Yes? Isn?t it impressive just how persistent the bad idea fairy can be?

Owen

> On Dec 24, 2015, at 19:25 , Suresh Ramasubramanian <ops.lists at gmail.com> wrote:
> 
> Hmm, has anyone at all kept count of the number of times such a discussion has started up in just the last year, and how many more times in the past 16 or so years?
> 
> Mind you, back in say 2004, this discussion would have run to 50 or 60 emails at a bare minimum, in no time at all.
> 
> --srs
> 
> On 25-Dec-2015, at 6:55 AM, Stephen Satchell <list at satchell.net> wrote:
> 
>>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>> Let?s just cut off the entirety of the third world instead of having
>>> a tangible mitigation plan in place.
>> 
>> While you thing you are making a snarky response, it would be handy for end users to be able to turn on and off access to other countries retail.


From ops.lists at gmail.com  Fri Dec 25 03:42:09 2015
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 25 Dec 2015 09:12:09 +0530
Subject: de-peering for security sake
In-Reply-To: <D3E92CC3-B4A3-4D5A-973F-520BEF978E49@delong.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>
 <D3E92CC3-B4A3-4D5A-973F-520BEF978E49@delong.com>
Message-ID: <958CEB06-B1BA-4D00-B2B5-95329B4B1E38@gmail.com>

Well, at least she's here rather than sprinkling eggnog and brandy flavoured pixie dust on our gear over the Christmas break.

--srs

> On 25-Dec-2015, at 9:08 AM, Owen DeLong <owen at delong.com> wrote:
> 
> Yes? Isn?t it impressive just how persistent the bad idea fairy can be?
> 
> Owen

From matecs at niif.hu  Thu Dec 24 13:59:38 2015
From: matecs at niif.hu (mate csaba)
Date: Thu, 24 Dec 2015 14:59:38 +0100
Subject: announcement of freerouter
Message-ID: <567BFA4A.4040306@niif.hu>

hi,
pleased to announce a stable release of freerouter.
this is a routing daemon that does packet handling itself
so it can do bridging, routing ipv4/ipv6 unicast/multicast,
mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp, babel...
does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan, nvgre...
have a lot of built in servers like dns, http(s), smtp, pop3, telnet, 
tacacs, radius, ssh...
it can start external images which could be connected, so various lab 
topolgies can be easily created.
our nren uses if as primary fullbgp rr for more than a year for about 
hundred routers.
here is the homepage: http://freerouter.nop.hu/
feel free to try it out and send suggestions/bug reports...:)
thanks in advance,
csaba mate
niif/hungarnet


From josh at kyneticwifi.com  Fri Dec 25 04:23:24 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Thu, 24 Dec 2015 22:23:24 -0600
Subject: announcement of freerouter
In-Reply-To: <567BFA4A.4040306@niif.hu>
References: <567BFA4A.4040306@niif.hu>
Message-ID: <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>

RouterOS is an existing product by MikroTik.
On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:

> hi,
> pleased to announce a stable release of freerouter.
> this is a routing daemon that does packet handling itself
> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
> babel...
> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
> nvgre...
> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
> tacacs, radius, ssh...
> it can start external images which could be connected, so various lab
> topolgies can be easily created.
> our nren uses if as primary fullbgp rr for more than a year for about
> hundred routers.
> here is the homepage: http://freerouter.nop.hu/
> feel free to try it out and send suggestions/bug reports...:)
> thanks in advance,
> csaba mate
> niif/hungarnet
>
>

From joelja at bogus.com  Fri Dec 25 04:40:36 2015
From: joelja at bogus.com (Joel Jaeggli)
Date: Thu, 24 Dec 2015 20:40:36 -0800
Subject: de-peering for security sake 
In-Reply-To: <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
Message-ID: <55E75BC2-A95A-4431-AC0D-E0CA88D4F90D@bogus.com>

While you have a great deal of control over what prefixes you choose to accept... You have very little control over your advertised prefixes once they exit your ASN. Maybe your transits offer communities to control their peer advertisements. In general assuming you're paying for the Internet cone, you have a vested interest in them propagating everywhere otherwise the party that is partitioned is you.

Sent from my iPhone

> On Dec 24, 2015, at 15:44, Colin Johnston <colinj at gt86car.org.uk> wrote:
> 
> see
> http://map.norsecorp.com
> 
> We really need to ask if China and Russia for that matter will not take abuse reports seriously why allow them to network to the internet ?
> 
> Colin
> 
> 

From mark.tinka at seacom.mu  Fri Dec 25 07:11:05 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 25 Dec 2015 09:11:05 +0200
Subject: IPv4 shutdown in mobile
In-Reply-To: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
Message-ID: <567CEC09.60609@seacom.mu>



On 22/Dec/15 14:45, Ca By wrote:
>
> At least in mobile, the change to ipv6 has been quick and the pace is
> increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I know
> many people liken ipv6 to "the boy who cried wolf", so be it, the
> data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
> the right metaphor was "the tortoise and the hare" or "the little engine
> that could"... Or even better IPv4 is John Henry.  It was the best in its
> time, but times have changed.

Mobile in Africa has done nothing on IPv6. South East Asia was the same
last time I was there (2012).

It would be nice to hear about Europe, the Middle East Latin America and
Canada as well, if anyone has any stories.

Mark.

From swmike at swm.pp.se  Fri Dec 25 07:56:25 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 25 Dec 2015 08:56:25 +0100 (CET)
Subject: IPv4 shutdown in mobile
In-Reply-To: <567CEC09.60609@seacom.mu>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
Message-ID: <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>

On Fri, 25 Dec 2015, Mark Tinka wrote:

> It would be nice to hear about Europe, the Middle East Latin America and 
> Canada as well, if anyone has any stories.

I know of at least one mobile provider in Sweden, Finland and Germany that 
have IPv6 enabled for at least part of their device base.

Some have chosen IPv4v6 (providing dual stack) which means they can do 
this with Apple devices today, some are IPv6 only which means they're like 
T-Mobile waiting for the Apple App universe to come around to being IPv6 
only supporting.

North America is by far the leader in number of IPv6 enabled customers 
which

https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-exhaustion-global-heat-map-network-country-growth-data.html#networks

shows. However, things are happening all across the world now... I 
wouldn't be surprised if we're already in the 100-300M IPv6 enabled 
devices range by now...

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

From colinj at gt86car.org.uk  Fri Dec 25 09:50:45 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Fri, 25 Dec 2015 09:50:45 +0000
Subject: de-peering for security sake
In-Reply-To: <201874.1451004539@turing-police.cc.vt.edu>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <201874.1451004539@turing-police.cc.vt.edu>
Message-ID: <AB34841A-723B-4D84-B5F3-1F514F972822@gt86car.org.uk>


> On 25 Dec 2015, at 00:48, Valdis.Kletnieks at vt.edu wrote:
> 
> On Thu, 24 Dec 2015 23:44:10 +0000, Colin Johnston said:
>> We really need to ask if China and Russia for that matter will not take abuse
>> reports seriously why allow them to network to the internet ?
> 
> Well, first off, it isn't like China or Russia are just one ASN.  You'd have
> to de-peer a bunch of ASN's - and also eliminate any paid transit connections.
> 
> Note that even North Korea has managed to land at least a small presence on
> the Internet.  Are you going to ban them too?
> 
> While we're banning countries, how about the country that's known for
> widespread surveillance both foreign and domestic, has one of the strongest
> cyber warfare arsenals around, and has been caught multiple times diverting and
> backdooring routers sold to foreign countries?
> 
> Oh wait, that's the US. Maybe we better rethink this?
> 
> Obviously, there's a lot of organizations that think that being able to
> communicate with China and Russia outweighs the security issues.  You are
> of course welcome to make a list of all Russian and Chinese ASNs and block
> their prefixes at your border.

So therefore we must somehow engage and enforce best practice for abuse alerts and action issues

Colin


From nick at foobar.org  Fri Dec 25 12:14:22 2015
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 25 Dec 2015 12:14:22 +0000
Subject: de-peering for security sake
In-Reply-To: <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
Message-ID: <567D331E.10206@foobar.org>

Daniel Corbe wrote:
> Let?s just cut off the entirety of the third world instead of having
> a tangible mitigation plan in place.

You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?

> https://en.wikipedia.org/wiki/Third_World

What an enormously silly idea.

Seasons greetings to all,

Nick


From maxtul at netassist.ua  Fri Dec 25 12:41:43 2015
From: maxtul at netassist.ua (Max Tulyev)
Date: Fri, 25 Dec 2015 14:41:43 +0200
Subject: de-peering for security sake
In-Reply-To: <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
Message-ID: <567D3987.2050008@netassist.ua>

Come on, keep calm and wait a year: Russia and China will de-peer with
all the world for their security (AKA censorship) reasons! ;)

On 25.12.15 01:44, Colin Johnston wrote:
> see
> http://map.norsecorp.com
> 
> We really need to ask if China and Russia for that matter will not take abuse reports seriously why allow them to network to the internet ?
> 
> Colin
> 
> 


From dcorbe at hammerfiber.com  Fri Dec 25 14:11:55 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Fri, 25 Dec 2015 09:11:55 -0500
Subject: de-peering for security sake
In-Reply-To: <567D331E.10206@foobar.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567D331E.10206@foobar.org>
Message-ID: <C884B1AA-F3EE-4DD8-95A5-16EA0C101FE3@hammerfiber.com>


> On Dec 25, 2015, at 7:14 AM, Nick Hilliard <nick at foobar.org> wrote:
> 
> Daniel Corbe wrote:
>> Let?s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
> 
> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?
> 
>> https://en.wikipedia.org/wiki/Third_World
> 
> What an enormously silly idea.
> 
> Seasons greetings to all,
> 
> Nick
> 

It was a stupid idea even before you corrected me.


From nanog at ics-il.net  Fri Dec 25 14:18:36 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Fri, 25 Dec 2015 08:18:36 -0600 (CST)
Subject: de-peering for security sake
In-Reply-To: <C884B1AA-F3EE-4DD8-95A5-16EA0C101FE3@hammerfiber.com>
Message-ID: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>

To the thread, not necessarily Daniel, if blocking countries\continents is a bad thing (not saying I disagree), how do you deal with the flood of trash? Just take it on the chin? 

The degree of splash damage by blocking this way will vary based upon what kind of network you are. Residential eyeballs? You could probably block most of a lot of things and people wouldn't notice or care, as long as it wasn't Google, Facebook, Netflix, etc. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Daniel Corbe" <dcorbe at hammerfiber.com> 
To: "Nick Hilliard" <nick at foobar.org> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Friday, December 25, 2015 8:11:55 AM 
Subject: Re: de-peering for security sake 


> On Dec 25, 2015, at 7:14 AM, Nick Hilliard <nick at foobar.org> wrote: 
> 
> Daniel Corbe wrote: 
>> Let?s just cut off the entirety of the third world instead of having 
>> a tangible mitigation plan in place. 
> 
> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel? 
> 
>> https://en.wikipedia.org/wiki/Third_World 
> 
> What an enormously silly idea. 
> 
> Seasons greetings to all, 
> 
> Nick 
> 

It was a stupid idea even before you corrected me. 



From cb.list6 at gmail.com  Fri Dec 25 14:29:44 2015
From: cb.list6 at gmail.com (Ca By)
Date: Fri, 25 Dec 2015 06:29:44 -0800
Subject: IPv4 shutdown in mobile
In-Reply-To: <567CEC09.60609@seacom.mu>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
Message-ID: <CAD6AjGQK6vM69bSfCs63uRE4RfKpr02twvJ9PQ4C3a7yjVZO1Q@mail.gmail.com>

On Friday, December 25, 2015, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 22/Dec/15 14:45, Ca By wrote:
> >
> > At least in mobile, the change to ipv6 has been quick and the pace is
> > increasing -- not just on ipv6 deployment but also on ipv4 shutdown. I
> know
> > many people liken ipv6 to "the boy who cried wolf", so be it, the
> > data shows the ipv6 wolf is here.  Or perhapsin hind   sight, we will see
> > the right metaphor was "the tortoise and the hare" or "the little engine
> > that could"... Or even better IPv4 is John Henry.  It was the best in its
> > time, but times have changed.
>
> Mobile in Africa has done nothing on IPv6. South East Asia was the same
> last time I was there (2012).
>
> It would be nice to hear about Europe, the Middle East Latin America and
> Canada as well, if anyone has any stories.
>
> Mark.
>

SK Telecom has deployed 464xlat at a large scale  in Korea
http://slidehot.us/resources/applying-ipv6-to-lte-networks.482671/

From list at satchell.net  Fri Dec 25 15:35:00 2015
From: list at satchell.net (Stephen Satchell)
Date: Fri, 25 Dec 2015 07:35:00 -0800
Subject: de-peering for security sake
In-Reply-To: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
References: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
Message-ID: <567D6224.9010600@satchell.net>

On 12/25/2015 06:18 AM, Mike Hammett wrote:
> To the thread, not necessarily Daniel, if blocking
> countries\continents is a bad thing (not saying I disagree), how do
> you deal with the flood of trash? Just take it on the chin?
>
> The degree of splash damage by blocking this way will vary based
> uponwhat kind of network you are. Residential eyeballs? You could
> probably block most of a lot of things and people wouldn't notice
> or care, as long as it wasn't Google, Facebook, Netflix, etc.

In my networks, different users have different requirements.  So I have 
to be careful in my ACLs to allow what they need, while reducing access 
by those who view the Internet as a sewer, and not as a privilege. (Used 
to be a BOFH in the NSF days.)

So my blocking list has grown, as I have identified bad actors from the 
information in my logs.  Keeping in mind that people with one bad habit 
will most likely have other bad habits as well, I keep it simple: if you 
don't play nice, you are blocked at the demarc.

For of the majority of my users, I provide access behind a router with 
the block list shown below.  For those customers who want an unblocked 
feed, I provide that by having the edge bypass the filtering router. (No 
one has asked yet for custom filters -- 1841s are cheap and easy, and 
don't take much power.)

I don't intend to provide this list for others to use.  I provide this 
list as an example of how I exercise my right of Internet Freedom of 
Assocation, and keep my own network safe from intruders.  Abuse reports? 
  I've given up on them, frankly.  My logs don't include enough 
information for some admins, so they drop my reports without further 
comment.  When there is an admin listed.

The nice thing about IPTABLES is that I can pull a report, if I want to, 
of which of these blocks are still generating traffic.  As we go farther 
down the IPv4-split road, I may just set up a database of the blocks, 
and monitor the traffic to see which ones have gone silent and thus can 
be removed.  Or not -- that's a lot of work and time, both of which I 
can direct to activities that bring in revenue.

> 1.93.34.222/32		china ssh abuser 	2014 August
> 5.79.75.0/24		netherlands	spam	2015 January
> 8.27.235.155		Microsoft		2015 September
> 14.139.172.0/24		india ssh abuser	2015 April
> 23.19.26.250		ubiquityservers.com ssh	2015 January
> 23.90.39.0/24		eonix.net 	spam	2014 October
> 23.90.51.0/24		eonix.net 	spam	2014 October
> 23.227.196.0/24		Swiftway.com 	spammer	2014 October
> 23.228.74.0/24		globalfrag.com	spam	2015 January
> 23.228.78.0/24		Blanckeart (NY) spam	2014 September
> 23.228.96.0/24		globalfrag.com	spam	2015 January
> 23.228.103.0/24		spam			2015 April
> 23.229.2.0/24		servermania.com	spam	2015 January
> 23.229.97.0/24		servermania.com	spam	2015 January
> 23.247.12.0/24		globalfrag.com	spam	2015 January
> 23.254.59.0/24		spam			2015 April
> 31.184.194.114		russia		ssh	2015 January
> 36.72.228.0/24		India ssh abuser	2014 October
> 38.113.188.0/24		cogent.net	spam	2015 January
> 41.186.0.0/16		Rwanda		ssh	2015 May
> 43.229.52.0/24		unknown		ssh	2015 May
> 43.229.53.0/24		unknown		ssh	2015 September
> 43.255.189.0/24		unknown         ssh	2015 June
> 46.166.136.0/24		spam			2015 April
> 46.166.189.0/24		spam			2015 April
> 50.2.0.0/15		eonix.net spam		2014 October
> 50.7.38.0/24		fdcservers.net	spam	2015 January
> 50.162.224.109		comcast.net	ssh	2015 January
> 52.28.227.79		amazonaws	ssh	2015 September
> 58.208.0.0/12 		china ssh abuser	2015 May
> 58.217.106.0/24		china ssh		2014 November
> 58.218.166.241/24	china ssh abuser	2015 April
> 58.218.204.241/24	china ssh abuser	2015 April
> 60.173.8.0/24		china shellshock	2014 September
> 60.173.9.0/24		china shellshock	2014 September
> 60.173.10.0/24		china shellshock	2014 September
> 60.173.11.0/24		china shellshock	2014 September
> 60.173.14.0/24		china shellshock	2014 September
> 60.173.26.0/24		china shellshock	2014 September
> 60.174.233.0/24		china shellshock	2014 September
> 60.184.82.0/24		china spam		2014 October
> 61.153.105.0/24		china ssh abuser	2014 August
> 61.153.110.0/24		china ssh abuser 	2014 August
> 61.174.49.0/24		china smtp abuser 	2014 August
> 61.174.50.0/24		china ssh abuser 	2014 August
> 61.174.51.0/24		china ssh abuser 	2014 August
> 61.168.229.114/24	china ssh abuser	2015 February
> 62.210.78.0/24		french ssh abuser	2014 October
> 63.223.110.0/24		sentris.com spam	2014 October
> 64.4.54.253		Microsoft		2015 September
> 64.16.210.0/23		sagonet.com	spam	2015 January
> 66.37.4.0/24		omnis.com mail		2014 October
> 66.70.34.113		superfish		2015 May
> 66.148.122.0/24		superb.net	spam	2015 January
> 66.55.93.168/29		gigenet.com spam	2014 October
> 68.233.128.0/20		yesmail.com spam	2014 October
> 69.58.3.0/24		spam			2015 April
> 69.60.127.172		slantcoil.info 		2014 August
> 69.65.41.30/32		online market media 	2014 August
> 69.65.46.56/29		online market media 	2014 August
> 69.65.53.0/24		Hd-gaming.com	spam	2015 January
> 69.168.184.210		xplornet.com	ssh	2015 January
> 70.39.86.0/24		spam			2015 April
> 70.39.122.0/24		sharktech.net	spam	2015 January
> 71.245.177.204		Verizon		ssh	2015 July
> 74.208.0.0/16		1on1 mail abuse		2014 October
> 75.99.22.136/29		NY ssh abuse 		2014 August
> 75.140.42.118		china nmap 		2014 August
> 76.191.64.0/18		vanoppen.biz spam	2014 October
> 76.191.112.0/22		sentris.com spam	2014 October
> 78.129.180.0/24		rapidswitch.com	spam	2015 January
> 78.138.127.0/24		poland	spam		2015 January
> 79.142.65.0/24		Netherlands spam	2014 October
> 80.82.66.0/24		netherlands	spam	2015 January
> 80.82.70.0/24		Spybot proxy abuse 	2014 August
> 80.82.79.0/24		Spybot proxy abuse 	2014 August
> 80.242.123.0/24		Boznia ssh abuse	2015 May
> 82.102.176.0/21		ssh abuse		2015 June
> 83.234.174.0/24		Charger		ssh	2015 September
> 86.34.224.0/24		Romania spam		2014 October
> 89.248.172.0/24		Netherlands shellshock	2014 September
> 93.174.89.0/24		netherlands	spam	2015 January
> 95.211.155.0/24 	Netherlands spammer	2014 October
> 95.211.158.0/24		leaseweb.com spam	2014 October
> 95.211.197.0/24		leaseweb.com spam	2014 October
> 103.6.151.0/24		Signapore	ssh	2015 September
> 103.41.124.0/24		Hong Kong ssh abuser	2015 March
> 103.252.99.0/24		relay.pttag.com spam	2014 October
> 104.36.86.0/24		servercrate.com	spam	2015 January
> 104.140.56.0/24		spam			2015 April
> 104.148.71.0/24		domain phising spam	2015 May
> 106.4.0.0/14		china spammer		2014 October
> 107.158.0.0/16		eonix.net spam		2014 October
> 107.182.141.0/24	cloudshards.com	spam	2015 January
> 108.168.211.0/24	softlayer.com spam	2014 October
> 109.63.0.0/16		WiMax core ssh abuser	2015 May
> 109.161.128.0/18	WiMax ssh abuser	2015 May
> 109.161.192.0/18	WiMax ssh abuser	2015 May
> 109.169.75.64/24	belfast ssh abuser	2015 February
> 110.76.47.0/24		china ssh abuser	2014 October
> 111.1.46.125/24		china ssh abuser	2015 April
> 111.74.238.0/24		china ssh abuser	2014 October
> 111.192.0.0/12		china ssh abuser	2015 June
> 112.93.254.128/29	china smtp abuser 	2014 August
> 113.106.63.0/24		china ssh abyser	2014 September
> 113.163.32.0/19		vietnam ssh abuser	2015 December
> 113.171.10.0/24		vietnam ssh abuser 	2014 August
> 115.153.142.0/23	china spammer		2014 October
> 115.239.228.14/24	china ssh abuser	2015 February
> 115.239.248.0/24	china ssh abuset	2014 October
> 116.10.191.0/24		china ssh abuser 	2014 August
> 117.21.173.0/24		china		ssh	2015 January
> 117.21.191.0/24		china ssh abuser	2014 October
> 117.27.158.0/24		china ssh abuser	2014 October
> 117.224.0.0/16		WiMax ssh abuser	2015 May
> 117.235.194.0/24	india spammer		2014 October
> 117.244.0.0/16		WiMax ssh abuser	2015 May
> 117.245.0.0/18		WiMax ssh abuser	2015 September
> 117.245.64.0/19		WiMax ssh abuser	2015 September
> 117.253.0.0/16		WiMax ssh abuser	2015 May
> 117.255.208.0/20	WiMax ssh abuser	2015 May
> 117.255.224.0/19	WiMax ssh abuser	2015 May
> 118.123.166.0/24	china ssh abuser	2015 April
> 121.12.109.0/24		china	mail-relay	2015 January
> 122.224.32.0/24		china ssh abuser	2014 October
> 122.225.97.64/26	china ssh abuser	2014 October
> 122.225.103.0/24	china ssh abuser	2014 December
> 122.225.109.0/24	china ssh abuser	2014 August
> 122.226.102.0/23	china ssh abuser	2014 October
> 122.231.69.0/24		china spammer		2014 October
> 123.157.150.0/24	china ssh abuser	2014 October
> 123.242.229.75/24	hong kong ssh abuser	2015 February
> 124.35.69.0/24		Japan		ssh	2015 January
> 134.19.180.0/24		netherlands	spam	2015 January
> 144.0.0.0/24		china ssh abuser	2014 August
> 153.120.25.0/24		japan ssh abuser	2014 September
> 162.217.99.0/24		Internap spam		2014 October
> 162.219.27.0/24		alnitech.com spammer	2014 October
> 162.221.201.0/24	esecuredata spammer	2014 October
> 162.246.57.0/24		spam			2015 April
> 162.246.58.0/24		spam			2015 April
> 162.250.120.0/21	spam			2015 June
> 162.251.160.0/24	1gservers.com		2014 October
> 171.111.153.0/24	china ShellShock	2014 October
> 173.44.157.0/24		serverhub.com 	spam	2015 January
> 173.22.177.0/24		spam			2015 April
> 173.44.253.0/24		spam			2015 April
> 173.45.90.0/24		ee.net spammers		2014 October
> 173.213.70.224/27	falldare.net 		2014 August
> 173.213.94.0/24		spam			2015 April
> 173.213.100.0/24	eonix.net	spam	2015 January
> 173.213.103.224/27	slantcoil.info 		2014 August
> 173.224.121.0/24	spam			2015 April
> 173.224.123.0/24	dedicatedserver4u spam	2014 October
> 173.224.126.0/24	dedicatedserver4u spam	2014 October
> 173.232.112.0/24	learn2speak.info	2014 October
> 173.232.249.0/24	eonix.net	spam	2015 January
> 173.244.147.0/24	spam			2015 April
> 175.101.0.0/16		excellmedia.net india 	2014 August
> 176.51.227.0/24		russian spam		2014 October
> 177.54.144.57		eonix.net	ssh	2015 January
> 178.251.230.0/24	spam			2015 April
> 183.57.57.0/24		china SSH abuser	2014 October
> 185.42.240.32/24	ssh			2015 April
> 183.82.10/24		India SSH abuser	2014 October
> 184.170.244.0/24	coloat.com 		2014 October
> 185.44.107.0/24		spam			2015 April
> 186.216.247.0/24	Brazil          ssh     2015 September
> 186.216.249.0/24	Brazil          ssh     2015 September
> 186.216.250.0/24	Brazil          ssh     2015 September
> 186.216.251.0/24	Brazil          ssh     2015 September
> 188.40.248.0/24		German spammer		2014 October
> 188.234.136.0/22	Russia		ssh	2015 September
> 193.107.16.0/24		Seychelles ssh abuser	2014 August
> 192.3.108.0/24		colocrossing.com spam	2014 October
> 193.104.41.53/24	modolvia ssh abuse	2015 April
> 198.89.90.0/24		spam			2015 April
> 199.34.124.0/24		baremetalcloud.com spam	2014 October
> 199.115.228.0/22	VolumeDrive spam	2014 October
> 199.182.161.0/24	serverel.net		2014 October
> 199.189.115.71/24	Antigua and Barbuda SSH 2015 February
> 199.202.216.0/24	spam			2015 April
> 200.30.170.0		Nicaragua	SSH	2015 January
> 200.162.4.0/26		Brazil spam (exe)	2014 October
> 202.85.213.203/24	China ssh abuser	2015 February
> 202.137.9.53/24		link.net.id	ssh	2015 January
> 202.137.225.0/24	ssh			2015 April
> 202.109.143.0/24	china ssh abuser	2014 October
> 202.146.220.0/24	hong kong domain phish	2015 May
> 204.45.208.0/24		fdcservers.net	spam	2015 January
> 206.222.18.0/24		ee.net	spam	2015 January
> 208.94.21.0/24		E-dialog.com	spam	2015 January
> 208.94.244.144/28	joedatacenter.com spam	2014 October
> 209.95.38.0/24		mpcustomer.com spam	2014 October
> 209.95.40.0/24		spam			2015 April
> 209.160.24.0/24		hopone.net	spam	2015 January
> 210.32.200.0/21		China ssh		2015 December
> 210.211.118.0/24	Vietnam ssh abuse	2015 December
> 213.163.66.0/24		netherlands	spam	2015 January
> 211.143.243.0/24	china ssh abuser	2014 August
> 213.163.66.0/24		netherlands	spam	2015 January
> 213.163.72.0/24		i3d.net spammer		2014 October
> 216.77.79.0/24		china nmap 		2014 August
> 216.99.158.150/24	psychz.net ssh abuse	2015 March
> 218.2.0.0/16		china ssh abuser	2014 October
> 218.3.0.0/16		china ssh abuser	2015 December
> 218.4.0.0/16		china ssh abuser	2015 December
> 218.64.0.0/16		china ssh abuser	2015 July
> 218.65.0.0/17		china ssh abuser	2015 July
> 218.199.144.0/24	china ssh abuser	2015 November
> 219.138.135.0/24	china ssh abuser 	2014 August
> 219.141.254.244/24	china ssh abusert	2015 April
> 220.163.0.0/16		china domain phishing	2015 May
> 220.164.0.0/16		china domain phishing	2015 May
> 220.165.0.0/16		china domain phishing	2015 May
> 220.177.198.0/24	china ssh abuser	2014 October
> 220.184.0.0/16		china ssh abuser	2015 May
> 220.185.0.0/16		china ssh abuser	2015 May
> 220.186.0.0/16		china ssh abuser	2015 May
> 220.187.0.0/16		china ssh abuser	2015 May
> 220.188.0.0/16		china ssh abuser	2015 May
> 220.189.0.0/16		china ssh abuser	2015 May
> 220.190.0.0/16		china ssh abuser	2015 May
> 220.191.0.0/16		china ssh abuser	2015 May
> 221.194.47.0/24		china ssh abuser	2014 October
> 221.224.0.0/13		china ssh abuser	2015 May
> 221.229.160.223/24	china ssh abuser	2015 April
> 221.229.160.241/24	china ssh abuser	2015 April
> 221.235.188.0/24	china ssh abuser	2014 November
> 222.34.30.0/24		china shellshock	2014 November
> 222.163.192.0/24	china ssh abuser 	2014 August (2014 Sep)
> 222.184.0.0/13		china ssh abuser	2015 May
> 223.73.110.0/24		china		spam	2015 January


From dcorbe at hammerfiber.com  Fri Dec 25 16:25:30 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Fri, 25 Dec 2015 11:25:30 -0500
Subject: de-peering for security sake
In-Reply-To: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
References: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
Message-ID: <A3BE9B4F-CDB9-43D1-9B03-456D6A8AA339@hammerfiber.com>


> On Dec 25, 2015, at 9:18 AM, Mike Hammett <nanog at ics-il.net> wrote:
> 
> To the thread, not necessarily Daniel, if blocking countries\continents is a bad thing (not saying I disagree), how do you deal with the flood of trash? Just take it on the chin? 

If you as an end user want to be the cyber-equivalent of a xenophobe because OMG BAD INTERNETS then be my guest.  On the other hand, I?m a network operator so I don?t have the luxury of dictating to my users what they can and cannot reach.  

> 
> The degree of splash damage by blocking this way will vary based upon what kind of network you are. Residential eyeballs? You could probably block most of a lot of things and people wouldn't notice or care, as long as it wasn't Google, Facebook, Netflix, etc. 

As a residential ISP with many first and second generation American immigrants in my service footprint I can assure you this notion is patently false.  People will definitely notice and care if they can?t communicate with their relatives and consume content in their home countries.  

> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> ----- Original Message -----
> 
> From: "Daniel Corbe" <dcorbe at hammerfiber.com> 
> To: "Nick Hilliard" <nick at foobar.org> 
> Cc: "NANOG" <nanog at nanog.org> 
> Sent: Friday, December 25, 2015 8:11:55 AM 
> Subject: Re: de-peering for security sake 
> 
> 
>> On Dec 25, 2015, at 7:14 AM, Nick Hilliard <nick at foobar.org> wrote: 
>> 
>> Daniel Corbe wrote: 
>>> Let?s just cut off the entirety of the third world instead of having 
>>> a tangible mitigation plan in place. 
>> 
>> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel? 
>> 
>>> https://en.wikipedia.org/wiki/Third_World 
>> 
>> What an enormously silly idea. 
>> 
>> Seasons greetings to all, 
>> 
>> Nick 
>> 
> 
> It was a stupid idea even before you corrected me. 
> 
> 


From dcorbe at hammerfiber.com  Fri Dec 25 16:32:15 2015
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Fri, 25 Dec 2015 11:32:15 -0500
Subject: de-peering for security sake
In-Reply-To: <A3BE9B4F-CDB9-43D1-9B03-456D6A8AA339@hammerfiber.com>
References: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
 <A3BE9B4F-CDB9-43D1-9B03-456D6A8AA339@hammerfiber.com>
Message-ID: <1385CC7C-EB62-4FD6-B320-6B5724AC476B@hammerfiber.com>

You know, without actually looking I?m willing to lay money down that the people beating the blocklist drum are the same people who scream the loudest about net neutrality when they can?t actually get to the content they want. 

> On Dec 25, 2015, at 11:25 AM, Daniel Corbe <dcorbe at hammerfiber.com> wrote:
> 
> 
>> On Dec 25, 2015, at 9:18 AM, Mike Hammett <nanog at ics-il.net> wrote:
>> 
>> To the thread, not necessarily Daniel, if blocking countries\continents is a bad thing (not saying I disagree), how do you deal with the flood of trash? Just take it on the chin? 
> 
> If you as an end user want to be the cyber-equivalent of a xenophobe because OMG BAD INTERNETS then be my guest.  On the other hand, I?m a network operator so I don?t have the luxury of dictating to my users what they can and cannot reach.  
> 
>> 
>> The degree of splash damage by blocking this way will vary based upon what kind of network you are. Residential eyeballs? You could probably block most of a lot of things and people wouldn't notice or care, as long as it wasn't Google, Facebook, Netflix, etc. 
> 
> As a residential ISP with many first and second generation American immigrants in my service footprint I can assure you this notion is patently false.  People will definitely notice and care if they can?t communicate with their relatives and consume content in their home countries.  
> 
>> 
>> 
>> 
>> 
>> ----- 
>> Mike Hammett 
>> Intelligent Computing Solutions 
>> http://www.ics-il.com 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> http://www.midwest-ix.com 
>> 
>> 
>> ----- Original Message -----
>> 
>> From: "Daniel Corbe" <dcorbe at hammerfiber.com> 
>> To: "Nick Hilliard" <nick at foobar.org> 
>> Cc: "NANOG" <nanog at nanog.org> 
>> Sent: Friday, December 25, 2015 8:11:55 AM 
>> Subject: Re: de-peering for security sake 
>> 
>> 
>>> On Dec 25, 2015, at 7:14 AM, Nick Hilliard <nick at foobar.org> wrote: 
>>> 
>>> Daniel Corbe wrote: 
>>>> Let?s just cut off the entirety of the third world instead of having 
>>>> a tangible mitigation plan in place. 
>>> 
>>> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel? 
>>> 
>>>> https://en.wikipedia.org/wiki/Third_World 
>>> 
>>> What an enormously silly idea. 
>>> 
>>> Seasons greetings to all, 
>>> 
>>> Nick 
>>> 
>> 
>> It was a stupid idea even before you corrected me. 
>> 
>> 
> 


From owen at delong.com  Fri Dec 25 17:22:43 2015
From: owen at delong.com (Owen DeLong)
Date: Fri, 25 Dec 2015 09:22:43 -0800
Subject: de-peering for security sake
In-Reply-To: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
References: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
Message-ID: <FE5AEB6C-2117-4FF1-BEFD-10B1D21A492A@delong.com>


> On Dec 25, 2015, at 06:18 , Mike Hammett <nanog at ics-il.net> wrote:
> 
> To the thread, not necessarily Daniel, if blocking countries\continents is a bad thing (not saying I disagree), how do you deal with the flood of trash? Just take it on the chin? 

Allowing hate speech is the price of having free speech. I will decry, denounce, and object to all of the statements promoting racism or banning entry of people based on religion, or other forms of discrimination, but I will not claim that any person has no right to make those statements. In fact, I will strongly defend the right of those people to make fools of themselves in public every bit as strongly as I will defend my right to make opposing statements. Unless we tolerate unpopular speech, we risk a tyranny of the majority which is both detrimental to society overall and antithetical to freedom of speech, the principles of democracy, and the entire concept of a free society.

To some extent, some of the trash we take on the chin on the internet is the price of having a free and open internet.

I?m not opposed to localized depeering or blockage when warranted, but it is important to keep such actions as granular as practicable. Otherwise, the collateral damage to the free and open internet becomes greater than the damage done by the miscreants we are attempting to block.

Surely blocking an entire nation is well beyond ?as granular as practicable?.

I realize that reactionary overreach has become fashionable in the US since 9/11. Some great examples include the U.S.A.P.A.T.R.I.O.T. act, warrantless wiretapping and the associated unconstitutional laws of ex post facto granting retroactive immunity to the phone companies that lacked the will to say no. Examples abound even today in the surveillance bill that got buried in the recent budget act.

> The degree of splash damage by blocking this way will vary based upon what kind of network you are. Residential eyeballs? You could probably block most of a lot of things and people wouldn't notice or care, as long as it wasn't Google, Facebook, Netflix, etc. 

That may be true, but even if it is, it still doesn?t make broad censorship a concept we should support or accept in practice.

The extent to which it is true reminds me of the story (apocryphal as it is) of the frog in a pot of water with the temperature being raised slowly.

Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position.

Owen


From cscora at apnic.net  Fri Dec 25 18:11:52 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 26 Dec 2015 04:11:52 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201512251811.tBPIBqul032328@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 26 Dec, 2015

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

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

BGP routing table entries examined:                              576265
    Prefixes after maximum aggregation (per Origin AS):          213285
    Deaggregation factor:                                          2.70
    Unique aggregates announced (without unneeded subnets):      280854
Total ASes present in the Internet Routing Table:                 52365
    Prefixes per ASN:                                             11.00
Origin-only ASes present in the Internet Routing Table:           36632
Origin ASes announcing only one prefix:                           15883
Transit ASes present in the Internet Routing Table:                6400
Transit-only ASes present in the Internet Routing Table:            169
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      37
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:              1012
    Unregistered ASNs in the Routing Table:                         362
Number of 32-bit ASNs allocated by the RIRs:                      12218
Number of 32-bit ASNs visible in the Routing Table:                9333
Prefixes from 32-bit ASNs in the Routing Table:                   35630
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:            393
Number of addresses announced to Internet:                   2802731460
    Equivalent to 167 /8s, 14 /16s and 73 /24s
    Percentage of available address space announced:               75.7
    Percentage of allocated address space announced:               75.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.9
Total number of prefixes smaller than registry allocations:      189204

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

Prefixes being announced by APNIC Region ASes:                   146560
    Total APNIC prefixes after maximum aggregation:               40490
    APNIC Deaggregation factor:                                    3.62
Prefixes being announced from the APNIC address blocks:          155240
    Unique aggregates announced from the APNIC address blocks:    62692
APNIC Region origin ASes present in the Internet Routing Table:    5125
    APNIC Prefixes per ASN:                                       30.29
APNIC Region origin ASes announcing only one prefix:               1198
APNIC Region transit ASes present in the Internet Routing Table:    890
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1770
Number of APNIC addresses announced to Internet:              756202372
    Equivalent to 45 /8s, 18 /16s and 187 /24s
    Percentage of available APNIC address space announced:         88.4

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:                    181143
    Total ARIN prefixes after maximum aggregation:                88980
    ARIN Deaggregation factor:                                     2.04
Prefixes being announced from the ARIN address blocks:           184603
    Unique aggregates announced from the ARIN address blocks:     86550
ARIN Region origin ASes present in the Internet Routing Table:    16470
    ARIN Prefixes per ASN:                                        11.21
ARIN Region origin ASes announcing only one prefix:                5932
ARIN Region transit ASes present in the Internet Routing Table:    1727
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:     905
Number of ARIN addresses announced to Internet:              1101780160
    Equivalent to 65 /8s, 171 /16s and 212 /24s
    Percentage of available ARIN address space announced:          58.3

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, 64198-64296, 393216-395164
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:                    138551
    Total RIPE prefixes after maximum aggregation:                68822
    RIPE Deaggregation factor:                                     2.01
Prefixes being announced from the RIPE address blocks:           146446
    Unique aggregates announced from the RIPE address blocks:     90653
RIPE Region origin ASes present in the Internet Routing Table:    18042
    RIPE Prefixes per ASN:                                         8.12
RIPE Region origin ASes announcing only one prefix:                7965
RIPE Region transit ASes present in the Internet Routing Table:    2991
Average RIPE Region AS path length visible:                         4.9
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4325
Number of RIPE addresses announced to Internet:               702356864
    Equivalent to 41 /8s, 221 /16s and 29 /24s
    Percentage of available RIPE address space announced:         102.1

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 196608-204287
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:                   60646
    Total LACNIC prefixes after maximum aggregation:              11836
    LACNIC Deaggregation factor:                                   5.12
Prefixes being announced from the LACNIC address blocks:          73576
    Unique aggregates announced from the LACNIC address blocks:   34301
LACNIC Region origin ASes present in the Internet Routing Table:   2463
    LACNIC Prefixes per ASN:                                      29.87
LACNIC Region origin ASes announcing only one prefix:               595
LACNIC Region transit ASes present in the Internet Routing Table:   542
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2158
Number of LACNIC addresses announced to Internet:             170689536
    Equivalent to 10 /8s, 44 /16s and 132 /24s
    Percentage of available LACNIC address space announced:       101.7

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:                  13649
    Total AfriNIC prefixes after maximum aggregation:              3115
    AfriNIC Deaggregation factor:                                  4.38
Prefixes being announced from the AfriNIC address blocks:         16007
    Unique aggregates announced from the AfriNIC address blocks:   6324
AfriNIC Region origin ASes present in the Internet Routing Table:   736
    AfriNIC Prefixes per ASN:                                     21.75
AfriNIC Region origin ASes announcing only one prefix:              193
AfriNIC Region transit ASes present in the Internet Routing Table:  167
Average AfriNIC Region AS path length visible:                      4.5
    Max AfriNIC Region AS path length visible:                       18
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  175
Number of AfriNIC addresses announced to Internet:             71343360
    Equivalent to 4 /8s, 64 /16s and 157 /24s
    Percentage of available AfriNIC address space announced:       70.9

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
 4538     5600       4192          76   China Education and Research 
 7545     3065        346         158   TPG Telecom Limited
 4766     3018      11136        1000   Korea Telecom
17974     2854        914          96   PT Telekomunikasi Indonesia
 9829     2221       1416         374   National Internet Backbone
 4755     2068        431         233   TATA Communications formerly 
 9808     1709       8639          18   Guangdong Mobile Communicatio
 4808     1590       2275         505   CNCGROUP IP network China169 
 9583     1508        121         557   Sify Limited
38197     1416         88         186   Sun Network (Hong Kong) Limit

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     3272       2964         145   Cox Communications Inc.
 3356     2594      10690         532   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
18566     2211        394         277   MegaPath Corporation
20115     1908       1907         403   Charter Communications
 6983     1699        849         238   EarthLink, Inc.
30036     1668        332         329   Mediacom Communications Corp
 4323     1578       1021         393   tw telecom holdings, inc.
  209     1464       4338        1228   Qwest Communications Company,
  701     1381      11445         652   MCI Communications Services, 

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
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2290        909        1642   Akamai International B.V.
34984     1933        321         410   TELLCOM ILETISIM HIZMETLERI A
 8551     1435        376          44   Bezeq International-Ltd
 8402     1087        544          15   OJSC "Vimpelcom"
13188     1075         97          79   TOV "Bank-Inform"
12479     1070        965          80   France Telecom Espana SA
31148     1042         47          41   Freenet Ltd.
 9198      954        349          26   JSC Kazakhtelecom
 6830      894       2712         464   Liberty Global Operations B.V

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     3412        541         120   Telmex Colombia S.A.
 8151     2121       3364         490   Uninet S.A. de C.V.
 7303     1581        942         241   Telecom Argentina S.A.
 6503     1388        453          58   Axtel, S.A.B. de C.V.
28573     1205       2174         131   NET Servi?os de Comunica??o S
11830     1096        366          25   Instituto Costarricense de El
 6147     1037        376          34   Telefonica del Peru S.A.A.
 7738      994       1882          41   Telemar Norte Leste S.A.
 3816      977        460         187   COLOMBIA TELECOMUNICACIONES S
26615      956       2325          34   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
 8452     1208       1470          14   TE-AS
24863     1167        405          37   Link Egypt (Link.NET)
37611      583         39          40   Afrihost-Brevis Computer Serv
36903      552        278         110   Office National des Postes et
36992      446       1233          33   ETISALAT MISR
37492      328        192          67   Orange Tunisie
24835      326        146          12   Vodafone Data
29571      264         21          11   Cote d'Ivoire Telecom
 3741      221        837         183   Internet Solutions
15706      171         32           6   Sudatel (Sudan Telecom Co. Lt

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
 4538     5600       4192          76   China Education and Research 
10620     3412        541         120   Telmex Colombia S.A.
22773     3272       2964         145   Cox Communications Inc.
 7545     3065        346         158   TPG Telecom Limited
 4766     3018      11136        1000   Korea Telecom
17974     2854        914          96   PT Telekomunikasi Indonesia
 3356     2594      10690         532   Level 3 Communications, Inc.
 6389     2508       3687          42   BellSouth.net Inc.
39891     2473        129           7   SaudiNet, Saudi Telecom Compa
20940     2290        909        1642   Akamai International B.V.

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

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

  ASN   No of nets  Net Savings Description
10620      3412        3292      Telmex Colombia S.A.
22773      3272        3127      Cox Communications Inc.
 7545      3065        2907      TPG Telecom Limited
17974      2854        2758      PT Telekomunikasi Indonesia
 6389      2508        2466      BellSouth.net Inc.
39891      2473        2466      SaudiNet, Saudi Telecom Compa
 3356      2594        2062      Level 3 Communications, Inc.
 4766      3018        2018      Korea Telecom
18566      2211        1934      MegaPath Corporation
 9829      2221        1847      National Internet Backbone

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         3356       Level 3 Communicatio
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
18985   UNALLOCATED  8.21.68.0/22          3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint
32805   UNALLOCATED  12.1.225.0/24         7018       AT&T Services, Inc.

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

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

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
31.170.96.0/23       23456     32bit Transition AS
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.
37.46.15.0/24        36351     SoftLayer Technologies Inc.
41.73.1.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:13      /10:36      /11:100     /12:265     
/13:507     /14:1016    /15:1773    /16:12983   /17:7413    /18:12626   
/19:25571   /20:37724   /21:39995   /22:63678   /23:55100   /24:315883  
/25:547     /26:576     /27:381     /28:16      /29:16      /30:9       
/31:0       /32:21      

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

  ASN   No of nets  Total ann.   Description
22773     2460          3272      Cox Communications Inc.
39891     2432          2473      SaudiNet, Saudi Telecom Compa
18566     2113          2211      MegaPath Corporation
 6389     1553          2508      BellSouth.net Inc.
30036     1485          1668      Mediacom Communications Corp
 6983     1345          1699      EarthLink, Inc.
10620     1290          3412      Telmex Colombia S.A.
34984     1221          1933      TELLCOM ILETISIM HIZMETLERI A
11492     1132          1222      CABLE ONE, INC.
31148      961          1042      Freenet Ltd.

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

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

   1:1639      2:655       4:100       5:2072      6:26        8:1420   
  12:1797     13:30       14:1594     15:23       16:2        17:57     
  18:19       20:48       22:1        23:1314     24:1737     27:2157   
  31:1716     32:54       33:2        34:4        35:5        36:197    
  37:2217     38:1140     39:22       40:76       41:3013     42:368    
  43:1619     44:36       45:1582     46:2374     47:63       49:1070   
  50:823      51:3        52:36       54:96       55:8        56:8      
  57:44       58:1436     59:840      60:523      61:1770     62:1413   
  63:1909     64:4447     65:2177     66:4075     67:2136     68:1092   
  69:3270     70:1041     71:461      72:1979     74:2559     75:358    
  76:418      77:1381     78:1269     79:821      80:1312     81:1347   
  82:859      83:669      84:775      85:1524     86:457      87:1040   
  88:552      89:1935     90:153      91:5963     92:862      93:2308   
  94:2231     95:2248     96:470      97:353      98:955      99:45     
 100:79      101:871     103:9243    104:2165    105:89      106:360    
 107:1099    108:639     109:2376    110:1247    111:1550    112:887    
 113:1193    114:916     115:1539    116:1516    117:1609    118:2029   
 119:1520    120:518     121:1165    122:2250    123:1877    124:1579   
 125:1741    128:673     129:357     130:422     131:1273    132:593    
 133:169     134:453     135:117     136:339     137:310     138:1599   
 139:199     140:248     141:464     142:637     143:738     144:578    
 145:150     146:824     147:609     148:1425    149:459     150:625    
 151:809     152:566     153:270     154:481     155:908     156:445    
 157:411     158:349     159:1065    160:421     161:695     162:2221   
 163:508     164:712     165:1100    166:315     167:921     168:1344   
 169:560     170:1483    171:263     172:369     173:1576    174:715    
 175:769     176:1503    177:3996    178:2221    179:1063    180:2071   
 181:1632    182:1911    183:664     184:763     185:5252    186:3015   
 187:1898    188:2124    189:1721    190:7579    191:1257    192:8747   
 193:5727    194:4315    195:3711    196:2255    197:1120    198:5498   
 199:5517    200:6715    201:3491    202:9915    203:9290    204:4569   
 205:2738    206:2963    207:3020    208:4012    209:3977    210:3763   
 211:2019    212:2623    213:2186    214:814     215:73      216:5707   
 217:1887    218:741     219:555     220:1639    221:807     222:645    
 223:880    

End of report

From gabriel.j.marais at gmail.com  Fri Dec 25 06:27:57 2015
From: gabriel.j.marais at gmail.com (Gabriel Marais)
Date: Fri, 25 Dec 2015 08:27:57 +0200
Subject: announcement of freerouter
In-Reply-To: <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>
References: <567BFA4A.4040306@niif.hu>
 <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>
Message-ID: <CAO8NbkQ1EEvmxvUuQW+JAwTHy5CxXDFM6sDnS+DMNy0dwPCMVQ@mail.gmail.com>

And very well priced for the rich feature list.
On 25 Dec 2015 6:25 AM, "Josh Reynolds" <josh at kyneticwifi.com> wrote:

> RouterOS is an existing product by MikroTik.
> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>
> > hi,
> > pleased to announce a stable release of freerouter.
> > this is a routing daemon that does packet handling itself
> > so it can do bridging, routing ipv4/ipv6 unicast/multicast,
> > mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
> > speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
> > babel...
> > does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
> > nvgre...
> > have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
> > tacacs, radius, ssh...
> > it can start external images which could be connected, so various lab
> > topolgies can be easily created.
> > our nren uses if as primary fullbgp rr for more than a year for about
> > hundred routers.
> > here is the homepage: http://freerouter.nop.hu/
> > feel free to try it out and send suggestions/bug reports...:)
> > thanks in advance,
> > csaba mate
> > niif/hungarnet
> >
> >
>

From matecs at niif.hu  Fri Dec 25 07:34:38 2015
From: matecs at niif.hu (mate csaba)
Date: Fri, 25 Dec 2015 08:34:38 +0100
Subject: announcement of freerouter
In-Reply-To: <CAO8NbkQ1EEvmxvUuQW+JAwTHy5CxXDFM6sDnS+DMNy0dwPCMVQ@mail.gmail.com>
References: <567BFA4A.4040306@niif.hu>
 <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>
 <CAO8NbkQ1EEvmxvUuQW+JAwTHy5CxXDFM6sDnS+DMNy0dwPCMVQ@mail.gmail.com>
Message-ID: <567CF18E.5060606@niif.hu>

it's free and as far as i know the only sw router with working evpn/pbb, 
evpn/vxlan, and evpn/cmac data plane, just to name one...
regards,
cs


On 12/25/2015 07:27 AM, Gabriel Marais wrote:
>
> And very well priced for the rich feature list.
>
> On 25 Dec 2015 6:25 AM, "Josh Reynolds" <josh at kyneticwifi.com 
> <mailto:josh at kyneticwifi.com>> wrote:
>
>     RouterOS is an existing product by MikroTik.
>     On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu
>     <mailto:matecs at niif.hu>> wrote:
>
>     > hi,
>     > pleased to announce a stable release of freerouter.
>     > this is a routing daemon that does packet handling itself
>     > so it can do bridging, routing ipv4/ipv6 unicast/multicast,
>     > mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
>     > speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
>     > babel...
>     > does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
>     > nvgre...
>     > have a lot of built in servers like dns, http(s), smtp, pop3,
>     telnet,
>     > tacacs, radius, ssh...
>     > it can start external images which could be connected, so
>     various lab
>     > topolgies can be easily created.
>     > our nren uses if as primary fullbgp rr for more than a year for
>     about
>     > hundred routers.
>     > here is the homepage: http://freerouter.nop.hu/
>     > feel free to try it out and send suggestions/bug reports...:)
>     > thanks in advance,
>     > csaba mate
>     > niif/hungarnet
>     >
>     >
>


From ler762 at gmail.com  Fri Dec 25 19:06:33 2015
From: ler762 at gmail.com (Lee)
Date: Fri, 25 Dec 2015 14:06:33 -0500
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
Message-ID: <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>

On 12/24/15, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> I am afraid people are already doing this. Every time I bring a new IP
> series into production, my users will complain that they are locked out
> from sites including many government sites. This is because people will
> load IP location lists into their firewall and drop packets at the border.
> Of course they will not update said lists and load year old lists into
> their firewalls.

Enable IPv6 for your users.  1) it's not going to have any "history" &
2) ipv6 probably isn't blocked.

> So now my users can not access government sites because the IP ranges were
> owned by a company in a different country two years ago.

Find one of your users that's a citizen of said gov't & forward their
complaint to the gov't sites.  Non-citizen complaints are much easier
to ignore..

Regards,
Lee


> Take a guess on how responsive site owners are when we complain about their
> firewall. Most refuse to acknowledge they do any blocking and insist the
> problem is at our end. That is if they respond at all.
>
> Regards,
>
> Baldur
>
>
> On 25 December 2015 at 02:25, Stephen Satchell <list at satchell.net> wrote:
>
>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>
>>> Let?s just cut off the entirety of the third world instead of having
>>> a tangible mitigation plan in place.
>>>
>>
>> While you thing you are making a snarky response, it would be handy for
>> end users to be able to turn on and off access to other countries retail.
>> If *they* don't need access to certain third world countries, it would be
>> their decision, not the operator's decision.
>>
>> For example, here on my little network we have no need for connectivity
>> to
>> much of Asia, Africa, or India.  We do have need to talk to Europe,
>> Australia, and some countries in South America.
>>
>>
>

From baldur.norddahl at gmail.com  Fri Dec 25 19:43:55 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 25 Dec 2015 20:43:55 +0100
Subject: de-peering for security sake
In-Reply-To: <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
Message-ID: <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>

On 25 December 2015 at 20:06, Lee <ler762 at gmail.com> wrote:

> Enable IPv6 for your users.  1) it's not going to have any "history" &
> 2) ipv6 probably isn't blocked.
>

I am not aware of just one single government site in this country (Denmark)
that is IPv6 enabled. There are zero danish news sites that are IPv6
enabled. In fact, nothing here is IPv6 enabled - with the exception of all
major ISP sites. For some strange reason all ISPs have IPv6 on their
websites (but they do not provide IPv6 to their customers). It is sad
really.


>
> > So now my users can not access government sites because the IP ranges
> were
> > owned by a company in a different country two years ago.
>
> Find one of your users that's a citizen of said gov't & forward their
> complaint to the gov't sites.  Non-citizen complaints are much easier
> to ignore..
>

I am a citizen and yes, they do ignore us. If you can manage to find the
right guy, he can probably fix it in a few minutes. It is just that there
is no way to get to that guy. The front desk has no clue what you are
talking about. To these people we should just stop sending traffic from
Romania and it would all be fixed, no?

To make it worse it is a really boring game of whack a mole. The users are
constantly finding new sites that are either blocking us or are showing the
site in the wrong language. Each time we open up a new IP series, it all
starts over again. We do not have enough cash on hand to simply buy a real
large chunk of IPv4, so we have multiple smaller blocks.

With regards to this thread, I am finding a worrying trend for websites to
block out of country IP-addresses at the firewall. In the past you could
expect that some content would not play or that your credit card payment
would be blocked. But now you never get to that stage because sites are
dropping the packets at the firewall.

Regards,

Baldur

From colinj at gt86car.org.uk  Fri Dec 25 20:10:38 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Fri, 25 Dec 2015 20:10:38 +0000
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
Message-ID: <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>

why do the chinese network folks never reply and action abuse reports, normal slow speed network abuse is tolerated, but not high speed deliberate abuse albeit compromised machines

Sent from my iPhone

> On 25 Dec 2015, at 19:43, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
>> On 25 December 2015 at 20:06, Lee <ler762 at gmail.com> wrote:
>> 
>> Enable IPv6 for your users.  1) it's not going to have any "history" &
>> 2) ipv6 probably isn't blocked.
>> 
> 
> I am not aware of just one single government site in this country (Denmark)
> that is IPv6 enabled. There are zero danish news sites that are IPv6
> enabled. In fact, nothing here is IPv6 enabled - with the exception of all
> major ISP sites. For some strange reason all ISPs have IPv6 on their
> websites (but they do not provide IPv6 to their customers). It is sad
> really.
> 
> 
>> 
>>> So now my users can not access government sites because the IP ranges
>> were
>>> owned by a company in a different country two years ago.
>> 
>> Find one of your users that's a citizen of said gov't & forward their
>> complaint to the gov't sites.  Non-citizen complaints are much easier
>> to ignore..
>> 
> 
> I am a citizen and yes, they do ignore us. If you can manage to find the
> right guy, he can probably fix it in a few minutes. It is just that there
> is no way to get to that guy. The front desk has no clue what you are
> talking about. To these people we should just stop sending traffic from
> Romania and it would all be fixed, no?
> 
> To make it worse it is a really boring game of whack a mole. The users are
> constantly finding new sites that are either blocking us or are showing the
> site in the wrong language. Each time we open up a new IP series, it all
> starts over again. We do not have enough cash on hand to simply buy a real
> large chunk of IPv4, so we have multiple smaller blocks.
> 
> With regards to this thread, I am finding a worrying trend for websites to
> block out of country IP-addresses at the firewall. In the past you could
> expect that some content would not play or that your credit card payment
> would be blocked. But now you never get to that stage because sites are
> dropping the packets at the firewall.
> 
> Regards,
> 
> Baldur

From baldur.norddahl at gmail.com  Fri Dec 25 20:29:05 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 25 Dec 2015 21:29:05 +0100
Subject: de-peering for security sake
In-Reply-To: <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
Message-ID: <CAPkb-7Bf8D68yAtyh777hm09DHwciJ++F-kb0N2+BG=tfefC1g@mail.gmail.com>

On 25 December 2015 at 21:10, Colin Johnston <colinj at gt86car.org.uk> wrote:

> why do the chinese network folks never reply and action abuse reports,
> normal slow speed network abuse is tolerated, but not high speed deliberate
> abuse albeit compromised machine
>

They do not speak the same language as you. They barely understand your
complaint and you would not understand their reply (in chinese!) - or do
you expect everyone to know english?

Why does everyone expect the chinese to use Google Translate? Try it
yourself before sending off your complaint in Mandarin...

Regards,

Baldur

From colinj at gt86car.org.uk  Fri Dec 25 20:40:38 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Fri, 25 Dec 2015 20:40:38 +0000
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7Bf8D68yAtyh777hm09DHwciJ++F-kb0N2+BG=tfefC1g@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
 <CAPkb-7Bf8D68yAtyh777hm09DHwciJ++F-kb0N2+BG=tfefC1g@mail.gmail.com>
Message-ID: <F2D23224-B892-4055-B455-ADFFFF75DD8B@gt86car.org.uk>

been there, done that
???? fix you ntp reflection servers :)

Sent from my iPhone

> On 25 Dec 2015, at 20:29, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
>> On 25 December 2015 at 21:10, Colin Johnston <colinj at gt86car.org.uk> wrote:
>> 
>> why do the chinese network folks never reply and action abuse reports,
>> normal slow speed network abuse is tolerated, but not high speed deliberate
>> abuse albeit compromised machine
> 
> They do not speak the same language as you. They barely understand your
> complaint and you would not understand their reply (in chinese!) - or do
> you expect everyone to know english?
> 
> Why does everyone expect the chinese to use Google Translate? Try it
> yourself before sending off your complaint in Mandarin...
> 
> Regards,
> 
> Baldur

From owen at delong.com  Fri Dec 25 20:49:37 2015
From: owen at delong.com (Owen DeLong)
Date: Fri, 25 Dec 2015 12:49:37 -0800
Subject: de-peering for security sake
In-Reply-To: <F2D23224-B892-4055-B455-ADFFFF75DD8B@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
 <CAPkb-7Bf8D68yAtyh777hm09DHwciJ++F-kb0N2+BG=tfefC1g@mail.gmail.com>
 <F2D23224-B892-4055-B455-ADFFFF75DD8B@gt86car.org.uk>
Message-ID: <D83F712C-3056-4CAD-86C2-FABB00F94B4F@delong.com>

I think that even in the US, a provider would want a more specific complaint than ?The network abuses?.

Owen

> On Dec 25, 2015, at 12:40 , Colin Johnston <colinj at gt86car.org.uk> wrote:
> 
> been there, done that
> ???? fix you ntp reflection servers :)
> 
> Sent from my iPhone
> 
>> On 25 Dec 2015, at 20:29, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>> 
>>> On 25 December 2015 at 21:10, Colin Johnston <colinj at gt86car.org.uk> wrote:
>>> 
>>> why do the chinese network folks never reply and action abuse reports,
>>> normal slow speed network abuse is tolerated, but not high speed deliberate
>>> abuse albeit compromised machine
>> 
>> They do not speak the same language as you. They barely understand your
>> complaint and you would not understand their reply (in chinese!) - or do
>> you expect everyone to know english?
>> 
>> Why does everyone expect the chinese to use Google Translate? Try it
>> yourself before sending off your complaint in Mandarin...
>> 
>> Regards,
>> 
>> Baldur


From swmike at swm.pp.se  Fri Dec 25 21:52:12 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 25 Dec 2015 22:52:12 +0100 (CET)
Subject: de-peering for security sake
In-Reply-To: <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
Message-ID: <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>

On Fri, 25 Dec 2015, Colin Johnston wrote:

> why do the chinese network folks never reply and action abuse reports, 
> normal slow speed network abuse is tolerated, but not high speed 
> deliberate abuse albeit compromised machines

This is not a chinese problem, this is a general ISP problem. Most ISPs do 
not respond to abuse reports.

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

From clayton at mnsi.net  Fri Dec 25 22:12:04 2015
From: clayton at mnsi.net (Clayton Zekelman)
Date: Fri, 25 Dec 2015 17:12:04 -0500
Subject: de-peering for security sake
In-Reply-To: <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
 <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>
Message-ID: <4D0907C4-2976-416D-81CE-B42D7389400F@mnsi.net>

Just an off the cuff thought but if the format of the abuse messages could be standardized so handling them would be semi-automated somewhat like ACNS notices, it might improve response.

Maybe such a format already exists and just isn't widely used.

Sent from my iPhone

> On Dec 25, 2015, at 4:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
>> On Fri, 25 Dec 2015, Colin Johnston wrote:
>> 
>> why do the chinese network folks never reply and action abuse reports, normal slow speed network abuse is tolerated, but not high speed deliberate abuse albeit compromised machines
> 
> This is not a chinese problem, this is a general ISP problem. Most ISPs do not respond to abuse reports.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se

From hugo at slabnet.com  Fri Dec 25 22:35:32 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Fri, 25 Dec 2015 14:35:32 -0800 (PST)
Subject: de-peering for security sake
In-Reply-To: <4D0907C4-2976-416D-81CE-B42D7389400F@mnsi.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
 <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>
 <4D0907C4-2976-416D-81CE-B42D7389400F@mnsi.net>
Message-ID: <16264572.kqhkiG.151db486262@slabnet.com>

Just in case I missed the /s on there:

> Maybe such a format already exists and just isn't widely used.

It does and it isn't.

http://www.x-arf.org/

--
Hugo
hugo at slabnet.com: email, xmpp/jabber
also on Signal

---- From: Clayton Zekelman <clayton at mnsi.net> -- Sent: 2015-12-25 - 14:12 ----

> Just an off the cuff thought but if the format of the abuse messages could be standardized so handling them would be semi-automated somewhat like ACNS notices, it might improve response.
>
> Maybe such a format already exists and just isn't widely used.
>
> Sent from my iPhone
>
>> On Dec 25, 2015, at 4:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>>
>>> On Fri, 25 Dec 2015, Colin Johnston wrote:
>>>
>>> why do the chinese network folks never reply and action abuse reports, normal slow speed network abuse is tolerated, but not high speed deliberate abuse albeit compromised machines
>>
>> This is not a chinese problem, this is a general ISP problem. Most ISPs do not respond to abuse reports.
>>
>> --
>> Mikael Abrahamsson    email: swmike at swm.pp.se
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: PGP/MIME digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151225/09ed2dd6/attachment.pgp>

From tshaw at oitc.com  Fri Dec 25 22:41:19 2015
From: tshaw at oitc.com (TR Shaw)
Date: Fri, 25 Dec 2015 17:41:19 -0500
Subject: de-peering for security sake
In-Reply-To: <4D0907C4-2976-416D-81CE-B42D7389400F@mnsi.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
 <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>
 <4D0907C4-2976-416D-81CE-B42D7389400F@mnsi.net>
Message-ID: <423408B2-F54C-48DA-B91C-66BEF42AAE5D@oitc.com>

ARF (http://www.rfc-editor.org/rfc/rfc5965.txt <http://www.rfc-editor.org/rfc/rfc5965.txt>, https://www.rfc-editor.org/rfc/rfc6650.txt) and X-ARF (http://www.x-arf.org/index.html <http://www.x-arf.org/index.html>) are used quite alot and many, like Yahoo, only accept ARF reports on abusive emails.

you might want to read MAAWG?s BCP: https://www.m3aawg.org/sites/default/files/document/M3AAWG_Feedback_Reporting_Recommendation_BP-2014-02.pdf <https://www.m3aawg.org/sites/default/files/document/M3AAWG_Feedback_Reporting_Recommendation_BP-2014-02.pdf>

Tom

> On Dec 25, 2015, at 5:12 PM, Clayton Zekelman <clayton at mnsi.net> wrote:
> 
> Just an off the cuff thought but if the format of the abuse messages could be standardized so handling them would be semi-automated somewhat like ACNS notices, it might improve response.
> 
> Maybe such a format already exists and just isn't widely used.
> 
> Sent from my iPhone
> 
>> On Dec 25, 2015, at 4:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>> 
>>> On Fri, 25 Dec 2015, Colin Johnston wrote:
>>> 
>>> why do the chinese network folks never reply and action abuse reports, normal slow speed network abuse is tolerated, but not high speed deliberate abuse albeit compromised machines
>> 
>> This is not a chinese problem, this is a general ISP problem. Most ISPs do not respond to abuse reports.
>> 
>> -- 
>> Mikael Abrahamsson    email: swmike at swm.pp.se


From trelane at trelane.net  Fri Dec 25 23:54:09 2015
From: trelane at trelane.net (Andrew Kirch)
Date: Fri, 25 Dec 2015 18:54:09 -0500
Subject: de-peering for security sake
In-Reply-To: <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
 <alpine.DEB.2.02.1512252250480.29581@uplift.swm.pp.se>
Message-ID: <CALA5tJ+0Y_Vthd+29s5-JhjPMbhQ0yz1rwFxv=d8KLqVSLoicg@mail.gmail.com>

Speaking as a former DNSBL operator, NANOG has a poor history of
dealing with those who report abuse as well.

On Fri, Dec 25, 2015 at 4:52 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> On Fri, 25 Dec 2015, Colin Johnston wrote:
>
>> why do the chinese network folks never reply and action abuse reports,
>> normal slow speed network abuse is tolerated, but not high speed deliberate
>> abuse albeit compromised machines
>
>
> This is not a chinese problem, this is a general ISP problem. Most ISPs do
> not respond to abuse reports.
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se

From owen at delong.com  Sat Dec 26 07:00:35 2015
From: owen at delong.com (Owen DeLong)
Date: Fri, 25 Dec 2015 23:00:35 -0800
Subject: de-peering for security sake
In-Reply-To: <Pine.LNX.4.64.1512252215370.5566@yuri.anime.net>
References: <152665494.5477.1451053216146.JavaMail.mhammett@ThunderFuck>
 <FE5AEB6C-2117-4FF1-BEFD-10B1D21A492A@delong.com>
 <Pine.LNX.4.64.1512252215370.5566@yuri.anime.net>
Message-ID: <4BB271C8-B40D-4E14-8329-D582044E2D90@delong.com>


> On Dec 25, 2015, at 22:16 , Dan Hollis <goemon at anime.net> wrote:
> 
> On Fri, 25 Dec 2015, Owen DeLong wrote:
>> Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position.
> 
> At what point do you cut the wire? How abusive is acceptable?

IMHO, you never cut the wire. You may filter selectively, but cutting the wire comes with far more collateral damage than actual useful effect.

Owen


From mark.tinka at seacom.mu  Sat Dec 26 07:14:42 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 26 Dec 2015 09:14:42 +0200
Subject: IPv4 shutdown in mobile
In-Reply-To: <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
 <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>
Message-ID: <567E3E62.7020407@seacom.mu>



On 25/Dec/15 09:56, Mikael Abrahamsson wrote:

>  
>
> I know of at least one mobile provider in Sweden, Finland and Germany
> that have IPv6 enabled for at least part of their device base.
>
> Some have chosen IPv4v6 (providing dual stack) which means they can do
> this with Apple devices today, some are IPv6 only which means they're
> like T-Mobile waiting for the Apple App universe to come around to
> being IPv6 only supporting.

This is encouraging to see.

None of the major mobile carriers in eastern, western, central and
southern Africa have done anything IPv6-related on their network that I
am aware about. The availability of IPv4 space in the AFRINIC region,
coupled with the ease of spending millions on CG-NAT's vs. rolling out
IPv6 means unless they start, someone's pants will be at their knees in
a non-picturesque way very soon.

The lack of interest, head-in-the-sand approach is quite alarming,
particularly as mobile networks are increasingly carrying the majority
of consumer data traffic in Africa, year-in, year-out.

Mark.

From mark.tinka at seacom.mu  Sat Dec 26 07:21:25 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 26 Dec 2015 09:21:25 +0200
Subject: de-peering for security sake
In-Reply-To: <567D331E.10206@foobar.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567D331E.10206@foobar.org>
Message-ID: <567E3FF5.6090505@seacom.mu>



On 25/Dec/15 14:14, Nick Hilliard wrote:

> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?

And watch the transit per-Mbps price go up? Who do we think funds the
low bandwidth costs of the "first world"?

Mark.

From swmike at swm.pp.se  Sat Dec 26 07:38:12 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 26 Dec 2015 08:38:12 +0100 (CET)
Subject: IPv4 shutdown in mobile
In-Reply-To: <567E3E62.7020407@seacom.mu>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
 <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>
 <567E3E62.7020407@seacom.mu>
Message-ID: <alpine.DEB.2.02.1512260822380.29581@uplift.swm.pp.se>

On Sat, 26 Dec 2015, Mark Tinka wrote:

> None of the major mobile carriers in eastern, western, central and 
> southern Africa have done anything IPv6-related on their network that I 
> am aware about. The availability of IPv4 space in the AFRINIC region, 
> coupled with the ease of spending millions on CG-NAT's vs. rolling out 
> IPv6 means unless they start, someone's pants will be at their knees in 
> a non-picturesque way very soon.

Well, in Europe and Asia, the amount of providers that have rolled out 
IPv6 is not zero, but I'd say it's in the 5-10% range or something like 
that.

It's easier to roll out IPv6 in a mobile network if you can do it single 
stack, so Apple supporting IPv6 only is a major step forward (this is due 
to the IPv6 bearer type was introduced around 12-14 years ago, whereas the 
IPv4v6 bearer type is less than 5 years old and was initially a 4G only 
thing).

> The lack of interest, head-in-the-sand approach is quite alarming,
> particularly as mobile networks are increasingly carrying the majority
> of consumer data traffic in Africa, year-in, year-out.

A lot of providers who have rolled out IPv6 have predominantly done so 
because they happen to have employed good engineers and empowered them to 
do things over longer time, keeping IPv6 costs down because they were done 
during normal hardware/software cycles, instead of a short intensive 
project that cost a lot of money.

I imagine that doing IPv6 single stack rollout in mobile starting now, you 
could be done in 1-2 years without major costs incurred, because now the 
handset landscape has matured enough that there are a good set of devices 
that support (or will support) IPv6 single stack properly. 2-3 years back, 
this just wasn't the case for generic bought-in-the-electronics-store 3GPP 
featurephone or smartphone. It's still the case that if a large part of 
your customer base has simple phones or feature phones, IPv6 support isn't 
needed. So while I do not agree that it's a great business strategy to 
wait even longer, I can understand those who have waited because they saw 
it as too hard to do, potentially because they didn't have the skilled 
engineers to do it. If they start now or during 2016, it's going to be a 
lot easier for them compared to the ones who started in 2010.

I guess there are major differences across the continent as to what 
network gear is used, but I know some operators who shipped their 10 
year old 2G basestations to African providers, and if these are still in 
use, potentially even without a support contract, then these will never 
support IPv6 properly. Networks built like this will be laggards just the 
same way people running old routers won't have the right features to 
support IPv6 properly.

However, if you have 3G basestations with support contracts (or that at 
least have software updated in the last 5-10 years), then getting IPv6 
only working should be perfectly doable if they upgrade the core of their 
mobile network.

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

From A.L.M.Buxey at lboro.ac.uk  Sat Dec 26 10:29:03 2015
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Sat, 26 Dec 2015 10:29:03 +0000
Subject: announcement of freerouter
In-Reply-To: <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>
References: <567BFA4A.4040306@niif.hu>
 <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>
Message-ID: <BF294B48-A5DE-469D-AB82-F4D54F9C0B54@lboro.ac.uk>

>RouterOS is an existing product by MikroTik

Yes but this was an announcement about freerouter. If RouterOS has an announcement to make they can send their own email ;)

alan

From matecs at niif.hu  Sat Dec 26 10:39:01 2015
From: matecs at niif.hu (mate csaba)
Date: Sat, 26 Dec 2015 11:39:01 +0100
Subject: announcement of freerouter
In-Reply-To: <BF294B48-A5DE-469D-AB82-F4D54F9C0B54@lboro.ac.uk>
References: <567BFA4A.4040306@niif.hu>
 <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=rsS8T6YQ7Fsg@mail.gmail.com>
 <BF294B48-A5DE-469D-AB82-F4D54F9C0B54@lboro.ac.uk>
Message-ID: <567E6E45.1070500@niif.hu>

> >RouterOS is an existing product by MikroTik
>
> Yes but this was an announcement about freerouter. If RouterOS has an 
> announcement to make they can send their own email ;)
since then i got it and corrected my page...
cs

From nanog at ics-il.net  Sat Dec 26 14:19:10 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 26 Dec 2015 08:19:10 -0600 (CST)
Subject: de-peering for security sake
In-Reply-To: <4BB271C8-B40D-4E14-8329-D582044E2D90@delong.com>
Message-ID: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>

How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Owen DeLong" <owen at delong.com> 
To: "Dan Hollis" <goemon at anime.net> 
Cc: "Mike Hammett" <nanog at ics-il.net>, "NANOG" <nanog at nanog.org> 
Sent: Saturday, December 26, 2015 1:00:35 AM 
Subject: Re: de-peering for security sake 


> On Dec 25, 2015, at 22:16 , Dan Hollis <goemon at anime.net> wrote: 
> 
> On Fri, 25 Dec 2015, Owen DeLong wrote: 
>> Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position. 
> 
> At what point do you cut the wire? How abusive is acceptable? 

IMHO, you never cut the wire. You may filter selectively, but cutting the wire comes with far more collateral damage than actual useful effect. 

Owen 



From list at satchell.net  Sat Dec 26 15:09:28 2015
From: list at satchell.net (Stephen Satchell)
Date: Sat, 26 Dec 2015 07:09:28 -0800
Subject: de-peering for security sake
In-Reply-To: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
Message-ID: <567EADA8.2090307@satchell.net>

On 12/26/2015 06:19 AM, Mike Hammett wrote:
> How much is an acceptable standard to the community? Individual /32s
> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's
> IPv6 equivalent would be) has made your naughty list that you block
> the whole prefix?

My gauge is volume of obnoxious traffic.  When I get lots of SSH probes 
from a /32, I block the /32.  When I get lots of SSH probes across a 
range of a /24, I block the /24.

When I see that the bad traffic has caused me to block multiple /24s, I 
will block the entire allocation.

By "lots" I mean hundreds or more.  When the criminals try to bust my 
door down, I take stops to stop them.

Ditto with attempts to relay mail through my mail servers.

My goal isn't to reduce traffic.  My goal is to stop irresponsible 
people from finding a rat-hole to do things I don't authorize them to 
do.  Defense in depth.

This is in addition to selecting the TCP and UDP ports carefully that I 
expose to the outside world.  Indeed, I have separate ACLs for inbound, 
outbound, and DMZ ports.  So, I've limited service from the inside to 
the outside to this:

> #       ---originated by LAN host to Internet
> FORWARD_TCP="ftp ssh snmp telnet smtp smtps submission domain http https ntp nicname rwhois pop3 pop3s imap imaps radius"
> FORWARD_TCP="$FORWARD_TCP 465 8008 webcache 8443 8888 snpp rsync"
> #           xmpp-client
> FORWARD_TCP="$FORWARD_TCP 5222 5223 8002"
> #           Microsoft Notification Protocol (msnp) [Messenger]
> FORWARD_TCP="$FORWARD_TCP 1863"
> #           Microsoft PPTP
> FORWARD_TCP="$FORWARD_TCP 1723"
> #           Timbuktu client, Service Ports 1-4
> FORWARD_TCP="$FORWARD_TCP 407 1417:1420"
> #           memoq
> FORWARD_TCP="$FORWARD_TCP 2705"
> #
> FORWARD_UDP="domain ntp snmp 407 443 500 1419 1701 1812 4500 snmp 3389 10000 55555 "

Your client base and my client base differ.  I make NNAP difficult to 
use against the world from my people.  But I don't hamstring them; if 
they want access to an outside service, they have but to ask.

I also terminate spammers.


From baldur.norddahl at gmail.com  Sat Dec 26 15:19:15 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sat, 26 Dec 2015 16:19:15 +0100
Subject: de-peering for security sake
In-Reply-To: <567EADA8.2090307@satchell.net>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net>
Message-ID: <CAPkb-7CRsC0Kdfxg+JgVUXGWb5mNYQWWJo0aaV_1cPrCU0vTkA@mail.gmail.com>

On 26 December 2015 at 16:09, Stephen Satchell <list at satchell.net> wrote:

> On 12/26/2015 06:19 AM, Mike Hammett wrote:
>
>> How much is an acceptable standard to the community? Individual /32s
>> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's
>> IPv6 equivalent would be) has made your naughty list that you block
>> the whole prefix?
>>
>
> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes
> from a /32, I block the /32.  When I get lots of SSH probes across a range
> of a /24, I block the /24.
>


Do you people have nothing better to do than scan firewall log files and
insert rules to block stuff that was already blocked by default?

Hint: if ssh probes spams your log then move your ssh service to a non
standard port.

Regards,

Baldur

From nanog at ics-il.net  Sat Dec 26 15:30:02 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 26 Dec 2015 09:30:02 -0600 (CST)
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7CRsC0Kdfxg+JgVUXGWb5mNYQWWJo0aaV_1cPrCU0vTkA@mail.gmail.com>
Message-ID: <2021609972.5706.1451143841390.JavaMail.mhammett@ThunderFuck>

1) Automation is your friend. 
2) If a host is compromised and doing an SSH scan, it's likely going to also be attempting SMTP, WordPress, home router, etc. attacks. Use a canary to block that host altogether to better your network. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Baldur Norddahl" <baldur.norddahl at gmail.com> 
To: nanog at nanog.org 
Sent: Saturday, December 26, 2015 9:19:15 AM 
Subject: Re: de-peering for security sake 

On 26 December 2015 at 16:09, Stephen Satchell <list at satchell.net> wrote: 

> On 12/26/2015 06:19 AM, Mike Hammett wrote: 
> 
>> How much is an acceptable standard to the community? Individual /32s 
>> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's 
>> IPv6 equivalent would be) has made your naughty list that you block 
>> the whole prefix? 
>> 
> 
> My gauge is volume of obnoxious traffic. When I get lots of SSH probes 
> from a /32, I block the /32. When I get lots of SSH probes across a range 
> of a /24, I block the /24. 
> 


Do you people have nothing better to do than scan firewall log files and 
insert rules to block stuff that was already blocked by default? 

Hint: if ssh probes spams your log then move your ssh service to a non 
standard port. 

Regards, 

Baldur 


From jabley at hopcount.ca  Sat Dec 26 16:14:25 2015
From: jabley at hopcount.ca (Joe Abley)
Date: Sat, 26 Dec 2015 11:14:25 -0500
Subject: de-peering for security sake
In-Reply-To: <567EADA8.2090307@satchell.net>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net>
Message-ID: <-1680641458761921693@unknownmsgid>

On Dec 26, 2015, at 10:09, Stephen Satchell <list at satchell.net> wrote:

> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from a /32, I block the /32.

... without any knowledge of how many end systems are going to be affected.

A significant campus or provider user base behind a NAT is likely to
have more infections in absolute terms, which means more observed bad
behaviour. It also means more end-systems (again, in absolute terms)
that represent collateral damage.

> When I get lots of SSH probes across a range of a /24, I block the /24.

[...]

> When I see that the bad traffic has caused me to block multiple /24s, I will block the entire allocation.

Your network, your rules. But that's not the way I would manage things
if I thought my job was to optimise and maximise connectivity between
my users and the Internet.

With respect to ssh scans in particular -- disable all forms of
password authentication and insist upon public key authentication
instead. If the password scan log lines still upset you, stop logging
them.


Joe

From wwaites at tardis.ed.ac.uk  Sat Dec 26 16:58:29 2015
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Sat, 26 Dec 2015 16:58:29 +0000 (GMT)
Subject: de-peering for security sake
In-Reply-To: <-1680641458761921693@unknownmsgid>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
Message-ID: <20151226.165829.1439560680207250860.wwaites@tardis.ed.ac.uk>

On Sat, 26 Dec 2015 11:14:25 -0500, Joe Abley <jabley at hopcount.ca> said:

    >> My gauge is volume of obnoxious traffic.  When I get lots of
    >> SSH probes from a /32, I block the /32.

    > ... without any knowledge of how many end systems are going to
    > be affected.  A significant campus or provider user base behind
    > a NAT is likely to have more infections in absolute terms, which
    > means more observed bad behaviour. It also means more
    > end-systems (again, in absolute terms) that represent collateral
    > damage.
    
Indeed this is only going to get worse with pressure on IPv4
addressing space. I often see this with small rural providers that
have not yet progressed to the level of getting their own address
space, and the available space is already insufficient in many cases.

Another important scenario where this happens is Tor exit nodes. I
have not observed any de-peering or network-layer filtering around
exit nodes, but the milder, but still very obnoxious, tactic of
application-layer capchas happens a lot. This is a serious problem for
privacy or security conscious users (i.e. most of Tor's userbase) that
tend not to enable JavaScript unless there is good reason. And a lot
of these capcha systems require JavaScript.

I see this every day since I live in a country where it would be
foolish not to use Tor as a matter of course. Large CDNs like
Cloudflare are guilty of this and this exascerbates the problem
because it prevents access to a very large set of resources and not
just a single web site. It's not nice. It has the effect of turning
the privacy-conscious into second-class netizens.

Rachel Greenstadt is presenting some research tomorrow at the CCC on
the effect this has on excluding contributions to common goods such as
Wikipedia:

    https://events.ccc.de/congress/2015/Fahrplan/events/7324.html


--
William Waites <wwaites at tardis.ed.ac.uk>  |  School of Informatics
   https://tardis.ed.ac.uk/~wwaites/      | University of Edinburgh
         https://hubs.net.uk/             |      HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

From mark.tinka at seacom.mu  Sat Dec 26 18:56:15 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 26 Dec 2015 20:56:15 +0200
Subject: IPv4 shutdown in mobile
In-Reply-To: <alpine.DEB.2.02.1512260822380.29581@uplift.swm.pp.se>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
 <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>
 <567E3E62.7020407@seacom.mu>
 <alpine.DEB.2.02.1512260822380.29581@uplift.swm.pp.se>
Message-ID: <567EE2CF.6010605@seacom.mu>



On 26/Dec/15 09:38, Mikael Abrahamsson wrote:

>  
>
> I guess there are major differences across the continent as to what
> network gear is used, but I know some operators who shipped their 10
> year old 2G basestations to African providers, and if these are still
> in use, potentially even without a support contract, then these will
> never support IPv6 properly. Networks built like this will be laggards
> just the same way people running old routers won't have the right
> features to support IPv6 properly.

In eastern and southern Africa, there is a reasonable average 3G and
4G/LTE coverage.

One network in southern Africa have upgraded 70% of their network to 4G
as part of an enhancement exercise in the last 16x months, and provide
98% 3G coverage across their country of operation. But not a peep re: IPv6.

In general, in the progressive African countries, one would be
hard-pressed to get anything less than 3G coverage in major business
districts/cities.

Mark.

From owen at delong.com  Sat Dec 26 20:28:07 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 26 Dec 2015 12:28:07 -0800
Subject: de-peering for security sake
In-Reply-To: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
Message-ID: <CC75F7FF-E4B5-4763-93F1-3F02B28C2670@delong.com>

I think as granular as practicable. In some cases, that will be a /32 or /128. In some cases, that will be a /24 or /64.

In some cases, it may be an entire ASN.

Each network will need to decide for themselves based on the constraints of the time they have to address the issue, the level of automation for addressing these things, memory in their routing platform(s), etc.

There is no one-size-fits all answer.

Owen

> On Dec 26, 2015, at 06:19 , Mike Hammett <nanog at ics-il.net> wrote:
> 
> How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix? 
> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> ----- Original Message -----
> 
> From: "Owen DeLong" <owen at delong.com> 
> To: "Dan Hollis" <goemon at anime.net> 
> Cc: "Mike Hammett" <nanog at ics-il.net>, "NANOG" <nanog at nanog.org> 
> Sent: Saturday, December 26, 2015 1:00:35 AM 
> Subject: Re: de-peering for security sake 
> 
> 
>> On Dec 25, 2015, at 22:16 , Dan Hollis <goemon at anime.net> wrote: 
>> 
>> On Fri, 25 Dec 2015, Owen DeLong wrote: 
>>> Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position. 
>> 
>> At what point do you cut the wire? How abusive is acceptable? 
> 
> IMHO, you never cut the wire. You may filter selectively, but cutting the wire comes with far more collateral damage than actual useful effect. 
> 
> Owen 
> 


From owen at delong.com  Sat Dec 26 20:34:11 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 26 Dec 2015 12:34:11 -0800
Subject: de-peering for security sake
In-Reply-To: <-1680641458761921693@unknownmsgid>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
Message-ID: <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>


> On Dec 26, 2015, at 08:14 , Joe Abley <jabley at hopcount.ca> wrote:
> 
> On Dec 26, 2015, at 10:09, Stephen Satchell <list at satchell.net> wrote:
> 
>> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from a /32, I block the /32.
> 
> ... without any knowledge of how many end systems are going to be affected.
> 
> A significant campus or provider user base behind a NAT is likely to
> have more infections in absolute terms, which means more observed bad
> behaviour. It also means more end-systems (again, in absolute terms)
> that represent collateral damage.

Living with IPv4 sucks. It?s only going to get worse. This not news.
There are no good IPv4 answers.

> 
>> When I get lots of SSH probes across a range of a /24, I block the /24.
> 
> [...]
> 
>> When I see that the bad traffic has caused me to block multiple /24s, I will block the entire allocation.
> 
> Your network, your rules. But that's not the way I would manage things
> if I thought my job was to optimise and maximise connectivity between
> my users and the Internet.

So what is your approach?

> With respect to ssh scans in particular -- disable all forms of
> password authentication and insist upon public key authentication
> instead. If the password scan log lines still upset you, stop logging
> them.

This isn?t a bad idea, per se, but it?s not always possible for the guy running the server
to dictate usage to the people using the accounts.

Also, note that the only difference between a good long passphrase and a private key is,
uh, wait, um, come to think of it, really not much.

The primary difference is that nobody expects to have to remember a private key so we don?t
get fussed when they contain lots of entropy. Users aren?t good at choosing good long secure
passphrases and the automated mechanisms that attempt to enforce strong passwords just
serve to increase user confusion and actually reduce the entropy in passwords overall.

Owen


From swmike at swm.pp.se  Sat Dec 26 20:42:45 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 26 Dec 2015 21:42:45 +0100 (CET)
Subject: IPv4 shutdown in mobile
In-Reply-To: <567EE2CF.6010605@seacom.mu>
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
 <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>
 <567E3E62.7020407@seacom.mu>
 <alpine.DEB.2.02.1512260822380.29581@uplift.swm.pp.se>
 <567EE2CF.6010605@seacom.mu>
Message-ID: <alpine.DEB.2.02.1512262136370.29581@uplift.swm.pp.se>

On Sat, 26 Dec 2015, Mark Tinka wrote:

> One network in southern Africa have upgraded 70% of their network to 4G 
> as part of an enhancement exercise in the last 16x months, and provide 
> 98% 3G coverage across their country of operation. But not a peep re: 
> IPv6.

Out of the 34 major mobile providers in Sweden, only one has a single peep 
regarding IPv6 for regular customers. All of these have ubiquitus 4G 
coverage and have had this for 4-5 years.

> In general, in the progressive African countries, one would be
> hard-pressed to get anything less than 3G coverage in major business
> districts/cities.

Well, if most providers in Europe can't get this done, I am not surprised 
that the African ones won't get it done either. Remember that the european 
ones operate in an environment where RIPE went into last /8 policy almost 
4 years ago, and still most of them haven't deployed any IPv6 at all yet.

IPv6 only operation for mobile is going to become fairly easy in the next 
few years due to the entire ecosystem maturing in this aspect, so my guess 
is that we'll start to see a lot more IPv6 over the next few years in 
mobile.

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

From mpetach at netflight.com  Sat Dec 26 20:50:27 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 26 Dec 2015 12:50:27 -0800
Subject: de-peering for security sake
In-Reply-To: <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
Message-ID: <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>

On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong <owen at delong.com> wrote:
>> On Dec 26, 2015, at 08:14 , Joe Abley <jabley at hopcount.ca> wrote:
>> On Dec 26, 2015, at 10:09, Stephen Satchell <list at satchell.net> wrote
>>> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from a /32, I block the /32.
[...]
>> With respect to ssh scans in particular -- disable all forms of
>> password authentication and insist upon public key authentication
>> instead. If the password scan log lines still upset you, stop logging
>> them.
>
> This isn?t a bad idea, per se, but it?s not always possible for the guy running the server
> to dictate usage to the people using the accounts.
>
> Also, note that the only difference between a good long passphrase and a private key is,
> uh, wait, um, come to think of it, really not much.
>
> The primary difference is that nobody expects to have to remember a private key so we don?t
> get fussed when they contain lots of entropy. Users aren?t good at choosing good long secure
> passphrases and the automated mechanisms that attempt to enforce strong passwords just
> serve to increase user confusion and actually reduce the entropy in passwords overall.


No, the difference is that a passphrase works
in conjunction with the private key, which is
the "something you have" vs the "something
you know" in two-factor authentication.

With password authentication, there's only a
single solution space for the attacker to
sift through; with private key authentication,
unless you're sloppy about securing your
private key, there's two massive solution spaces
for the attacker to sift through to find the unique
point of intersection.

Massively different solution space volumes
to deal with.  Equating the two only has meaning
in cosmological contexts.

> Owen
>

Matt

From jared at puck.nether.net  Sat Dec 26 21:17:30 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 26 Dec 2015 16:17:30 -0500
Subject: de-peering for security sake 
In-Reply-To: <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <CAPkb-7AZCbj=50pmb_AkT2BGGRAGkvrThhH7goxYKCwsBX8S-g@mail.gmail.com>
 <CAD8GWsvXAz_T7YouEQCaA88wGVyx6aokpCMZAFKwMByDq8suDg@mail.gmail.com>
 <CAPkb-7BdST2pbcrDEeSRmj29oLwP_0w+m8-ya7Ztk1PB071u+w@mail.gmail.com>
 <1E957E27-F8A0-450C-9A51-F497B2EC4155@gt86car.org.uk>
Message-ID: <DE0AFA64-F97C-49C9-86EC-B0AEFAB95CBC@puck.nether.net>


> On Dec 25, 2015, at 3:10 PM, Colin Johnston <colinj at gt86car.org.uk> wrote:
> 
> why do the chinese network folks never reply and action abuse reports, normal slow speed network abuse is tolerated, but not high speed deliberate abuse albeit compromised machines

Biggest reason I?ve seen is the same reason I delete spam in Chinese/Japanese/charset that is foreign to me.

When I know I?m supposed to be reading something I toss it into google translate, when I don?t expect it, it may not even reach my $inbox.  I?d expect writing to people in their non-native language is more likely to result in things being ignored or misclassified[1].

I work for a part of a multinational that doesn?t use the roman alphabet and mails are sometimes missed for this reason between our groups.

This is far more of a two way street than people realize.  When you find that person who speaks both languages it can remove hurdles.

- Jared

1 - Think of the setting ok_languages in spamassassin.


From jared at puck.nether.net  Sat Dec 26 21:21:03 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 26 Dec 2015 16:21:03 -0500
Subject: de-peering for security sake 
In-Reply-To: <-1680641458761921693@unknownmsgid>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
Message-ID: <BC2C9DEA-5089-4C43-A39C-DC9B0D8BA45B@puck.nether.net>


> On Dec 26, 2015, at 11:14 AM, Joe Abley <jabley at hopcount.ca> wrote:
> 
> With respect to ssh scans in particular -- disable all forms of
> password authentication and insist upon public key authentication
> instead. If the password scan log lines still upset you, stop logging
> them.

Or if you can?t get users to use keys (aside from remove the users) consider things like:

example /etc/ssh/sshd_config
Match User root
	PasswordAuthentication no

for users that should not be permitted to fall-back to password authentication.

- Jared



From nanog at ics-il.net  Sat Dec 26 22:42:53 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 26 Dec 2015 16:42:53 -0600 (CST)
Subject: de-peering for security sake
In-Reply-To: <BC2C9DEA-5089-4C43-A39C-DC9B0D8BA45B@puck.nether.net>
Message-ID: <1324426228.5786.1451169845448.JavaMail.mhammett@ThunderFuck>

Different network types will have different abilities to enforce this. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Jared Mauch" <jared at puck.nether.net> 
To: "Joe Abley" <jabley at hopcount.ca> 
Cc: nanog at nanog.org 
Sent: Saturday, December 26, 2015 3:21:03 PM 
Subject: Re: de-peering for security sake 


> On Dec 26, 2015, at 11:14 AM, Joe Abley <jabley at hopcount.ca> wrote: 
> 
> With respect to ssh scans in particular -- disable all forms of 
> password authentication and insist upon public key authentication 
> instead. If the password scan log lines still upset you, stop logging 
> them. 

Or if you can?t get users to use keys (aside from remove the users) consider things like: 

example /etc/ssh/sshd_config 
Match User root 
PasswordAuthentication no 

for users that should not be permitted to fall-back to password authentication. 

- Jared 




From owen at delong.com  Sat Dec 26 23:11:13 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 26 Dec 2015 15:11:13 -0800
Subject: de-peering for security sake
In-Reply-To: <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
Message-ID: <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>


> On Dec 26, 2015, at 12:50 , Matthew Petach <mpetach at netflight.com> wrote:
> 
> On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>>> On Dec 26, 2015, at 08:14 , Joe Abley <jabley at hopcount.ca> wrote:
>>> On Dec 26, 2015, at 10:09, Stephen Satchell <list at satchell.net> wrote
>>>> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from a /32, I block the /32.
> [...]
>>> With respect to ssh scans in particular -- disable all forms of
>>> password authentication and insist upon public key authentication
>>> instead. If the password scan log lines still upset you, stop logging
>>> them.
>> 
>> This isn?t a bad idea, per se, but it?s not always possible for the guy running the server
>> to dictate usage to the people using the accounts.
>> 
>> Also, note that the only difference between a good long passphrase and a private key is,
>> uh, wait, um, come to think of it, really not much.
>> 
>> The primary difference is that nobody expects to have to remember a private key so we don?t
>> get fussed when they contain lots of entropy. Users aren?t good at choosing good long secure
>> passphrases and the automated mechanisms that attempt to enforce strong passwords just
>> serve to increase user confusion and actually reduce the entropy in passwords overall.
> 
> 
> No, the difference is that a passphrase works
> in conjunction with the private key, which is
> the "something you have" vs the "something
> you know" in two-factor authentication.

No? You are missing the point. Guessing a private key is roughly equivalent to guessing a really long
pass phrase. There is no way that the server side can enforce password protection of the private key
on the client side, so if you are assuming that public-key authentication is two-factor, then you are
failing miserably.

> With password authentication, there's only a
> single solution space for the attacker to
> sift through; with private key authentication,
> unless you're sloppy about securing your
> private key, there's two massive solution spaces
> for the attacker to sift through to find the unique
> point of intersection.

The point here is that securing the private key is a user task and not under the control of the administrator.
As such, you have to assume sloppy.

> Massively different solution space volumes
> to deal with.  Equating the two only has meaning
> in cosmological contexts.

Or contexts where the user is sloppy about securing their private key, e.g. the real world.

Owen


From Valdis.Kletnieks at vt.edu  Sat Dec 26 23:45:53 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 26 Dec 2015 18:45:53 -0500
Subject: de-peering for security sake
In-Reply-To: <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
Message-ID: <126312.1451173553@turing-police.cc.vt.edu>

On Sat, 26 Dec 2015 12:50:27 -0800, Matthew Petach said:

> No, the difference is that a passphrase works
> in conjunction with the private key, which is
> the "something you have" vs the "something
> you know" in two-factor authentication.
>
> With password authentication, there's only a
> single solution space for the attacker to
> sift through; with private key authentication,
> unless you're sloppy about securing your
> private key, there's two massive solution spaces
> for the attacker to sift through to find the unique
> point of intersection.

Actually, to be pedantic (and this is crypto, where failure to be pedantic
can be fatal), the online attacker still has only one large space to search
through.  The private key you have on disk isn't the private key you
present to the remote server - the passphrase is used to convert from
one to the other.

(Hint: Consider the case of an ssh key generated without a passphrase.
Yes, there's valid reasons for doing this, such as allowing an ssh from
within a cronjob or other place where providing a passphrase is difficult.
And yes, if you do this, you should be securing it at the server end to
only allow that key to invoke the one command it was intended to, by using
the 'command="/your/one/command/here" option in authorized_keys)

> unless you're sloppy about securing your private key, there's two massive
> solution spaces for the attacker to sift through to find the unique point of
> intersection.

Actually, you have that backwards.  The attacker only has 2 solution
spaces if you *have* been sloppy and  your private key is captured.

The passphrase only helps if your private key on disk is captured - the
length of it determines how many possible on-the-wire private keys could
correspond to that on-disk copy.  Just remember that if they captured that,
they almost certainly also captured your known_hosts file - you *did* hash
that, right? :)

And of course, nothing hardens it like an iptables rule that only accepts
inbound port 22 (or whatever you chose) to only address space you *expect*
to see inbound ssh from. :)
-------------- 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/20151226/1f6a9588/attachment.pgp>

From Valdis.Kletnieks at vt.edu  Sat Dec 26 23:47:46 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 26 Dec 2015 18:47:46 -0500
Subject: de-peering for security sake
In-Reply-To: <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
Message-ID: <126495.1451173666@turing-police.cc.vt.edu>

On Sat, 26 Dec 2015 15:11:13 -0800, Owen DeLong said:
> Or contexts where the user is sloppy about securing their private key, e.g. the real world.

I seem to remember that enough people stashed their entire home directory
to github, including their keys, that github had to put in special hacks
to stop that.
-------------- 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/20151226/95ec6577/attachment.pgp>

From baldur.norddahl at gmail.com  Sat Dec 26 23:54:33 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sun, 27 Dec 2015 00:54:33 +0100
Subject: de-peering for security sake
In-Reply-To: <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
Message-ID: <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>

On 27 December 2015 at 00:11, Owen DeLong <owen at delong.com> wrote:

> No? You are missing the point. Guessing a private key is roughly
> equivalent to guessing a really long
> pass phrase. There is no way that the server side can enforce password
> protection of the private key
> on the client side, so if you are assuming that public-key authentication
> is two-factor, then you are
> failing miserably.
>

The key approach is still better. Even if the password is 123456 the
attacker is not going to get in, unless he somehow stole the key file.

Technically it is two-factor even if the user made one of the factors
really easy. And that might save the day if you have users that chooses bad
passwords.

The system is weak in that it is too easy to steal the key file. It is not
unlikely that a user with sloppy passwords is also sloppy with his key file.

Too bad ssh does not generally support a challenge-response protocol to a
write only hardware key device combined with server side passwords that can
be checked against a blacklist.

Regards,

Baldur

From owen at delong.com  Sun Dec 27 02:37:36 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 26 Dec 2015 18:37:36 -0800
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
Message-ID: <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>


> On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> On 27 December 2015 at 00:11, Owen DeLong <owen at delong.com> wrote:
> 
>> No? You are missing the point. Guessing a private key is roughly
>> equivalent to guessing a really long
>> pass phrase. There is no way that the server side can enforce password
>> protection of the private key
>> on the client side, so if you are assuming that public-key authentication
>> is two-factor, then you are
>> failing miserably.
>> 
> 
> The key approach is still better. Even if the password is 123456 the
> attacker is not going to get in, unless he somehow stole the key file.

Incorrect? It is possible the attacker could brute-force the key file.

A 1024 bit key is only as good as a ~256 character passphrase in terms of entropy.

If you are brute force or otherwise synthesizing the private key, you do not need
the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase
for the key file only matters if you already stole the key file.

In terms of guessing the private key vs. guessing a suitably long pass phrase, the
difficulty is roughly equivalent.

> Technically it is two-factor even if the user made one of the factors
> really easy. And that might save the day if you have users that chooses bad
> passwords.

Technically it?s not two-factor and pretending it is is dangerous.

> The system is weak in that it is too easy to steal the key file. It is not
> unlikely that a user with sloppy passwords is also sloppy with his key file.

Right? No matter what you do it is virtually impossible to protect against sloppy
users.

This has been true for decades even before the internet with teenagers given house
keys.

> Too bad ssh does not generally support a challenge-response protocol to a
> write only hardware key device combined with server side passwords that can
> be checked against a blacklist.

There?s no reason that it can?t if you use PAM.

Owen


From baldur.norddahl at gmail.com  Sun Dec 27 04:35:19 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sun, 27 Dec 2015 05:35:19 +0100
Subject: de-peering for security sake
In-Reply-To: <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
Message-ID: <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>

Owen you misunderstood what two factor is about. It is not practical to
brute force the key file. Nor is it practical to brute force a good
passphrase or password. Both have sufficient strength to withstand attack.

But two factor is about having two things that needs to be broken. The key
can be stolen, but the thief needs the password. The password can be
stolen, but the thief needs the key. He needs both.

SSH password + key file is accepted as two factor by PCI DSS auditors, so
yes it is in fact two factor.

But it is weak two factor because the key file is too easily stolen. NOT
because the key file can be brute forced. Nor because hypothetically
someone could memorize the content of the key file.

It is also weak because the key file can be duplicated. Note it does not
stop being two factor because of this, but stronger hardware based two
factor systems usually come with the property that it is very hard to
duplicate the key. Other examples of a two factor system were the key is
easy to duplicate is credit card with magnetic strip + pin. Example where
it is hard to duplicate is credit card with chip + pin. Both are examples
of where the password (the pin) is actually very weak, but it is still two
factor.

Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in
fact have a strength equal to 1024 bits entropy. It was considered equal to
about 128 bit of entropy, but is believed to be weaker now. I am using ECC
ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people
with tin foil hats believe we should stay away from NIST altogether. Unless
someone breaks the crypto, you are NOT going to brute force that key.

Yes I get your argument, you are saying break the key and you won't need
the password, but a) you can't actually break the key before the universe
ends, b) it is still two factor, just a extremely tiny in the academic
sense little bit weaker two factor. All crypto based two factor systems
suffers from the possibility that one could break the crypto and possibly
escape the need to know one or even both factors. But Owen - come one -
this silly argument pales and is so infinite insignificant to the real
problem with the ssh key two factor system, which is that the key is easily
stolen and duplicated and there is no way to check the quality of the
password (users might even change the key password to NO password).

Regards,

Baldur


On 27 December 2015 at 03:37, Owen DeLong <owen at delong.com> wrote:

>
> > On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl at gmail.com>
> wrote:
> >
> > On 27 December 2015 at 00:11, Owen DeLong <owen at delong.com> wrote:
> >
> >> No? You are missing the point. Guessing a private key is roughly
> >> equivalent to guessing a really long
> >> pass phrase. There is no way that the server side can enforce password
> >> protection of the private key
> >> on the client side, so if you are assuming that public-key
> authentication
> >> is two-factor, then you are
> >> failing miserably.
> >>
> >
> > The key approach is still better. Even if the password is 123456 the
> > attacker is not going to get in, unless he somehow stole the key file.
>
> Incorrect? It is possible the attacker could brute-force the key file.
>
> A 1024 bit key is only as good as a ~256 character passphrase in terms of
> entropy.
>
> If you are brute force or otherwise synthesizing the private key, you do
> not need
> the passphrase for the on-disk key. As was pointed out elsewhere, the
> passphrase
> for the key file only matters if you already stole the key file.
>
> In terms of guessing the private key vs. guessing a suitably long pass
> phrase, the
> difficulty is roughly equivalent.
>
> > Technically it is two-factor even if the user made one of the factors
> > really easy. And that might save the day if you have users that chooses
> bad
> > passwords.
>
> Technically it?s not two-factor and pretending it is is dangerous.
>
> > The system is weak in that it is too easy to steal the key file. It is
> not
> > unlikely that a user with sloppy passwords is also sloppy with his key
> file.
>
> Right? No matter what you do it is virtually impossible to protect against
> sloppy
> users.
>
> This has been true for decades even before the internet with teenagers
> given house
> keys.
>
> > Too bad ssh does not generally support a challenge-response protocol to a
> > write only hardware key device combined with server side passwords that
> can
> > be checked against a blacklist.
>
> There?s no reason that it can?t if you use PAM.
>
> Owen
>
>

From mike-nanog at tiedyenetworks.com  Sun Dec 27 05:49:43 2015
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sat, 26 Dec 2015 21:49:43 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
Message-ID: <567F7BF7.9070106@tiedyenetworks.com>

On 12/23/2015 06:49 PM, Lorell Hathcock wrote:
> All:
>
> Not all consumer grade customer premises equipment is created equally.  But end customers sure think it is.  I have retirement aged customers buying the crappiest routers and then blaming my cable network for all their connection woes.  The real problem is that there were plenty of problems on the cable network to deal with, so it was impossible to tell between a problem that a customer was having with their CPE versus a real problem in my network.
>
> Much of that has been cleared up on my side now, but customers were used to blaming us for everything so that they don't even consider that their equipment could be to blame.
>
> I want to be able to point out a third party list of all (most) broadband routers that rates them by performance.  Or that rates them by crappiness that I can send them to so they can look up their own router and determine if other users have had problems with that router and what can be done to fix it.
>
> So far my search has been in vain.
>
> Any thoughts?
>
>

As a service provider with largely residential/small business customers, 
I certainly have some thoughts on broadband routers. Sorry if this is 
overly long.

Firstly, they are all junk. Every last one of them. Period. Broadband 
routers are designed to be cheap and to appeal to people who don't know 
any better, and who respond well (eg: make purchasing decisions) based 
on the shape of the plastic, the color scheme employed, and number of 
mysterious blinking lights that convey 'something important is 
happening'. Further, the price point is $45 - $70 thereabouts, putting 
some definite constraints on the actual quality of the engineering and 
components that go into them. I feel that we, the service provider, 
endure a significantly high and undue burden of cost associated with 
providing ongoing support to customers as a result of the defects 
contained therein.

The laundry list of general operational issues for broadband routers, 
the ones that seem to be universal to every last one of them, goes 
something like this:

     * Device lock ups
     * Lost Settings
     * Abysmal device security
     * Inconsistent forwarding performance

     I will try to describe these:

Device lock up is by far the most damming problem there is. The lights 
are on, the cables are plugged in, but you aren't going anywhere 
therefore the Internet must be down. This condition typically can be 
resolved by powercycling the device, and whaever problem it was 
encountering is magically remedied and all is well again. The concept of 
the device developing 'a problem' that can only be resolved by power 
cycling it, is foreign and completely blows end users minds. And yet, it 
is very common, and leaves end users stranded since they don't have even 
the most basic of troubleshooting abilities. We have had people who wait 
days or even a week or two before calling in to ask for support, because 
they think the problem will fix itself or that we the provider are 
simply down (and, in their eyes, we're frequently down anyways and this 
is just routine...) and so it's out of their hands.

We've noted that there are waves of device lockups that occur nearly 
every time the weather turns, which I attribute to brownouts and other 
variations in the power grid which occur at these times and when coming 
into the office after a stormy weekend we know to expect our phones to 
be lit up all day with enormous numbers of people all screaming about 
being 'down the whole weekend!' and every last one of them being able 
restore themselves via powercycling. We try to counsel these customers 
and educate them that 'power cycling' is always a good "first responder" 
step to try, and secondly, that they always should employ a good quality 
standby UPS in order to avoid these types of issues in the future, but 
they never listen and blame us anyways. Broadband routers are not 
designed with quality robust power supplies, which certainly lowers the 
costs, but contributes substantially to this problem. This particular 
issue, I think, is one of the greatest deficiencies shared by all.

Other times, 'lockup' simply resolves to router software problems, such 
as  a kernel panic, a crashed or bugged system process such as 
pppoe/pppd or dhcp, an overfull nat state table, memory leaks, or other 
purely software related troubles. The recovery procedure is the same, 
eg: power cycle the device, but as before, it doesn't actually "fix" the 
underlaying problem (bugged software), it merely alleviates the current 
symptom...until next time later when it happens again. Many of these 
troubles are simply outstanding bugs in the versions of the opensource 
code that the SDK is built on, which never seems to get updated and 
instead just uses the same old buggy code. Some custom kits also have 
just crap buggy protocol implementations that also just never get fixed. 
And usually, (although this is improving), many of these cheap devices 
never have updated firmware available for them. 3 months after purchase 
the product is discontinued and it's on to the next newest thing so if 
you got bugs, tuff cookies. But even for those devices where firmware 
updates are made available, you would be hard pressed to find any end 
user which regularly reviews and applies same.

I should point out that an exception to the above are the dd-wrt and 
variant firmwares which will work on a subset of cpe devices. Generally 
dd-wrt is maintained much better and usually far superior to stock 
manufacturer firmware. A downside however is that it may not have that 
hot new wireless capability for your particular device or only support 
wireless in a generic way. It also doesn't support any adsl or vdsl 
modems that I know of, which precludes it from being able to be used in 
an integrated modem/router combo, forcing you still to have your cpe in 
bridge mode (and hope at least bridge mode can work well enough for 
you), and a second device at additional expense to be your router / 
wireless access point.

Lost settings is another very common symptom. One minute everything is 
great and fine, but then the next time you go to use the service... your 
wireless network name can't be found (or has been replaced by the 
ubiquitous ssid 'linksys'), and even if you can connect to your router, 
you still can't get on... only 20 minutes later when you are on the 
phone you are told that your device no longer appears to be configured 
for pppoe as it has a blank username / password credential now. And 
sometimes worse, the factory default ip range is different than what you 
use and so now the router is handing out foreign dhcp addresses but your 
printer with it's static IP is now on a different subnet and you can't 
print. This problem is even more devastating because it requires 
black-arts magic to correct; !!! Shudder !! YOU HAVE TO CONFIGURE IT AGAIN!

I have observed there seems to be a strong connection between 
brownouts/blackouts and lost settings (or, more accurately, reset to 
factory defaults). I suspect that the issue is flash memory corruption 
and the device firmware deciding it needs to format the flash (perhaps a 
reasonable assumption). We combat this at least on some of our dsl 
modem/routers by making the 'customer settings' the 'factory default' 
settings, which is stored in another bank of flash. But still it happens 
to other devices with frequent regularity. FURTHERMORE, some customers 
(a majority it seems), seems to be under the impression that 'if it 
don't work, reset it!', which means to use the paperclip in the special 
recessed hole. Usually these people are suffering from the first problem 
above, lockup, but they engage this factory default restore procedure 
not knowing they have just compounded their problem and ensured that it 
won't work now that it's no longer setup appropriately. We also try to 
ensure that every cpe that leaves our office has a red dot sticker over 
the hole to discourage this behavior. Sometimes it helps, sometimes the 
customer swears up and down they didn't touch it but when it's presented 
we see the tell-tell hole thru the sticker (or remnants of removed sticker).

The security of broadband routers is absolutely abysmal and there have 
been many documented cases now of customer home dsl modems having all 
sorts of issues, Secret remote root login exploits, default factory 
passwords. exposed internet facing management interfaces that in the web 
ui are 'turned off' but still reachable anyways, exploitable deamons 
such as dns, ntp and ssdp that are participants in DDoS attacks, and 
more. We have had direct experience with a particular malware that knew 
(when we didn't!) the default manufacturing passwords to our customer 
CPE and would change the dns settings of the device so that the resolver 
IP's handed out would be ones under the control of the bad guys, to 
support phishing attacks and other goals. Recovering from this was 
painful but a very good lesson - on my network, I now (per user), filter 
a list of inbound ports in order to secure by default these devices by 
denying Internet access to the CPEs themselves. I haven't had any 
complaints or requests for the filtering to be removed and I can clearly 
see it's a win. Still however, these kinds of games shouldn't be necessary.

Lastly, the forwarding performance of these devices is wildly 
inconsistent. Some devices slow down the more nat connections they are 
tracking (and keeping old closed connection info in their 
tables...blarf!), sometimes other bugs create situations in which 
pinging the upstream gateway thur the router takes thousands of ms (and 
that number immediately drops back to normal upon, you guessed it...a 
power cycle!), sometimes buffer bloat is a factor.

As I indicated earlier, there is dd-wrt (and other router firmware 
replacements) which are available and which will address some of these 
issues if you need to use consumer hardware. However, some other choices 
do include Mikrotik as well as aftermarket Cisco such as the 2600 
series. But there needs to be a lot more development in this area. The 
google onhub looks to have a great hardware design as far as it's radio 
array goes, but it lacks basic features found in low end linksys 
routers. Im sure it will catch up but for today it's really at 'gee 
heres what we can do' stage and not really a full featured broadband 
router device in the current sense of the term.

I apologize for length.

Mike-

From mpetach at netflight.com  Sun Dec 27 06:06:29 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 26 Dec 2015 22:06:29 -0800
Subject: de-peering for security sake
In-Reply-To: <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
Message-ID: <CAEmG1=ou3ykHUqV4LSsc5AL-Rn1k6GsPK2Rv7Hwj4MaWHuQXTw@mail.gmail.com>

On Sat, Dec 26, 2015 at 6:37 PM, Owen DeLong <owen at delong.com> wrote:
>> On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>>
[...]

>> The key approach is still better. Even if the password is 123456 the
>> attacker is not going to get in, unless he somehow stole the key file.
>
> Incorrect? It is possible the attacker could brute-force the key file.
>
> A 1024 bit key is only as good as a ~256 character passphrase in terms of entropy.
>
> If you are brute force or otherwise synthesizing the private key, you do not need
> the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase
> for the key file only matters if you already stole the key file.
>
> In terms of guessing the private key vs. guessing a suitably long pass phrase, the
> difficulty is roughly equivalent.

Intriguing point.   I was thinking about it
from the end-user perspective; but you're
right, from the bits-on-the-wire perspective,
it's all just a stream of 1's and 0's, whether
it came from a private key + passphrase
run through an algorithm or not.

Thanks for the reminder to look at it from
multiple perspectives.  ^_^


Matt

From damian at google.com  Sun Dec 27 06:17:23 2015
From: damian at google.com (Damian Menscher)
Date: Sat, 26 Dec 2015 22:17:23 -0800
Subject: de-peering for security sake
In-Reply-To: <CAEmG1=ou3ykHUqV4LSsc5AL-Rn1k6GsPK2Rv7Hwj4MaWHuQXTw@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAEmG1=ou3ykHUqV4LSsc5AL-Rn1k6GsPK2Rv7Hwj4MaWHuQXTw@mail.gmail.com>
Message-ID: <CABSP1OcFiW6JQbFrhnUN922jAT6tS9UcOjx7JKrLkKpEAM0pow@mail.gmail.com>

On Sat, Dec 26, 2015 at 10:06 PM, Matthew Petach <mpetach at netflight.com>
wrote:

> Thanks for the reminder to look at it from multiple perspectives.
>

The key attribute missing from the discussion so far is that the factors be
*different*, from the set of:
  - something you know (password / PIN)
  - something you have (keyfob / OTP generator / chip)
  - something you are (fingerprint / retina scan)

Claiming a passphrase and key are two "factors" is missing the point --
they both come from the same set (a secret which could be cloned).  If you
believe those are two factors then a password alone is 10 factors (one for
each character)! ;)

Damian

From hugo at slabnet.com  Sun Dec 27 06:32:20 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Sat, 26 Dec 2015 22:32:20 -0800
Subject: de-peering for security sake
In-Reply-To: <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>
References: <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>
Message-ID: <20151227063220.GG7584@slab-wks-04.int.slabnet.com>

On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian <ops.lists at gmail.com> wrote:

>Hmm, has anyone at all kept count of the number of times such a discussion has started up in just the last year...

Not on an ongoing basis, but I was curious as well, so a quick mailbox 
search for 2015:

http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
subject: Facebook outage?
author: Colin Johnston <colinj at gt86car.org.uk>

http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
subject: AOL Postmaster
author: Colin Johnston <colinj at gt86car.org.uk>

http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
subject: Getting hit hard by CHINANET
author: Colin Johnston <colinj at gt86car.org.uk>

http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
subject: BGP offloading (fixing legacy router BGP scalability issues)
author: Colin Johnston <colinj at gt86car.org.uk>

http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 
24 hours
author: Colin Johnston <colinj at gt86car.org.uk>

http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
subject: de-peering for security sake
author: Colin Johnston <colinj at gt86car.org.uk>

I tried to be pretty wide in the search and filter through a decent chunk 
of false positives manually, though of course I could have missed some.  It 
does skip a few of the "all of their traffic is crap and abuse reports are 
ignored" messages that don't *explicitly* call for wholesale country-level 
blocks or de-peering.

>...and how many more times in the past 16 or so years?

I was curious, but not masochistic ;)

-- 
Hugo

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)


>
>Mind you, back in say 2004, this discussion would have run to 50 or 60 emails at a bare minimum, in no time at all.
>
>--srs
>
>On 25-Dec-2015, at 6:55 AM, Stephen Satchell <list at satchell.net> wrote:
>
>>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>> Let?s just cut off the entirety of the third world instead of having
>>> a tangible mitigation plan in place.
>>
>> While you thing you are making a snarky response, it would be handy for end users to be able to turn on and off access to other countries retail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151226/1379b793/attachment.pgp>

From colinj at gt86car.org.uk  Sun Dec 27 07:12:48 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Sun, 27 Dec 2015 07:12:48 +0000
Subject: de-peering for security sake
In-Reply-To: <20151227063220.GG7584@slab-wks-04.int.slabnet.com>
References: <CAN9qwJ8pWP0SSJFg9e2-9hHsFV16bViQ9_OVQ4wbGXgqtBUBMw@mail.gmail.com>
 <C748156E-8FD9-4338-B951-9C7FD6A2F0E2@hathcock.org>
 <56D2F17E-3D8C-427D-A7D6-A6C354863383@seastrom.com>
 <CAPkb-7AVPVpJqDcB_A4w_VTxnb14Eqh1TnpRWxN8MJaJ5_h2ww@mail.gmail.com>
 <80B5A72F-29E8-4D40-9F0A-D5A32237B581@mtin.net>
 <CAGbD49qqRdt8kU79fC7yS2VWj1MweO8+1R80_NW2oqp9rWzznw@mail.gmail.com>
 <C4E2719E-3BFB-4DA0-A3A6-6C9F2F010D85@gt86car.org.uk>
 <4F954495-338B-451E-928A-4A8855C44EC5@hammerfiber.com>
 <567C9AF3.7070207@satchell.net>
 <D9BA146E-CD8F-45A2-AD5D-2FA9C2177224@gmail.com>
 <20151227063220.GG7584@slab-wks-04.int.slabnet.com>
Message-ID: <1923B9D9-16FC-4E1C-BB49-79FF99CBDC07@gt86car.org.uk>

interesting:)
but useful to make a attempt at cleaning up traffic from china and russia

colin

Sent from my iPhone

> On 27 Dec 2015, at 06:32, Hugo Slabbert <hugo at slabnet.com> wrote:
> 
>> On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian <ops.lists at gmail.com> wrote:
>> 
>> Hmm, has anyone at all kept count of the number of times such a discussion has started up in just the last year...
> 
> Not on an ongoing basis, but I was curious as well, so a quick mailbox search for 2015:
> 
> http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
> subject: Facebook outage?
> author: Colin Johnston <colinj at gt86car.org.uk>
> 
> http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
> subject: AOL Postmaster
> author: Colin Johnston <colinj at gt86car.org.uk>
> 
> http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
> http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
> subject: Getting hit hard by CHINANET
> author: Colin Johnston <colinj at gt86car.org.uk>
> 
> http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
> subject: BGP offloading (fixing legacy router BGP scalability issues)
> author: Colin Johnston <colinj at gt86car.org.uk>
> 
> http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
> subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours
> author: Colin Johnston <colinj at gt86car.org.uk>
> 
> http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
> subject: de-peering for security sake
> author: Colin Johnston <colinj at gt86car.org.uk>
> 
> I tried to be pretty wide in the search and filter through a decent chunk of false positives manually, though of course I could have missed some.  It does skip a few of the "all of their traffic is crap and abuse reports are ignored" messages that don't *explicitly* call for wholesale country-level blocks or de-peering.
> 
>> ...and how many more times in the past 16 or so years?
> 
> I was curious, but not masochistic ;)
> 
> -- 
> Hugo
> 
> hugo at slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
> 
> (also on textsecure & redphone)
> 
> 
>> 
>> Mind you, back in say 2004, this discussion would have run to 50 or 60 emails at a bare minimum, in no time at all.
>> 
>> --srs
>> 
>> On 25-Dec-2015, at 6:55 AM, Stephen Satchell <list at satchell.net> wrote:
>> 
>>>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>>> Let?s just cut off the entirety of the third world instead of having
>>>> a tangible mitigation plan in place.
>>> 
>>> While you thing you are making a snarky response, it would be handy for end users to be able to turn on and off access to other countries retail.

From swmike at swm.pp.se  Sun Dec 27 07:37:25 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 27 Dec 2015 08:37:25 +0100 (CET)
Subject: Broadband Router Comparisons
In-Reply-To: <567F7BF7.9070106@tiedyenetworks.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
Message-ID: <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>

On Sat, 26 Dec 2015, Mike wrote:

> As a service provider with largely residential/small business customers, I 
> certainly have some thoughts on broadband routers. Sorry if this is overly 
> long.
>
> Firstly, they are all junk.

Yes, that's correct. We get what we pay for. If the ISP buys the CPE, 
their procurement department will get bonus for shaving off every cent off 
of the price possible, meaning the device manufacturer also pressures all 
their people to come up a way to checkbox all the features requested.

For the low price CPEs bought in the electronics store, mostly by people 
with no technical expertise, we have a similar situation. Shiny box, list 
of some checkbox features, sell it for 8-12 months until there is a new 
SOC which is slightly more cost reduced, release a new hardware revision 
(completely incompatible with the old one but from a black box of view 
does the same), start selling that rev instead.

Margins in this business are super tight and most of the vendors aren't 
making any money, just like the mobile phone business. Providing security 
updates is just a cost, there is no upside, because these boxes sit in a 
closet, unloved until they stop working, and they're thrown out and 
replaced by a new unloved box that goes into the closet until it stops 
working again.

So the ecosystem is completely broken, and I have no idea how to fix it.

If someone like Consumer Reports or similar agency started testing and 
rating devices on these things like long-time support, automatic updates, 
software quality etc, and not just testing wifi speed as a factor of 
distance, we might get somewhere.

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

From Valdis.Kletnieks at vt.edu  Sun Dec 27 08:19:26 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 27 Dec 2015 03:19:26 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
Message-ID: <162443.1451204366@turing-police.cc.vt.edu>

On Sun, 27 Dec 2015 08:37:25 +0100, Mikael Abrahamsson said:
> If someone like Consumer Reports or similar agency started testing and
> rating devices on these things like long-time support, automatic updates,
> software quality etc, and not just testing wifi speed as a factor of
> distance, we might get somewhere.

As finally we come full circle to the original question "who, if anybody,
has a list of which things are crap and which aren't" :)
-------------- 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/20151227/c188f098/attachment.pgp>

From swmike at swm.pp.se  Sun Dec 27 08:34:58 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 27 Dec 2015 09:34:58 +0100 (CET)
Subject: Broadband Router Comparisons
In-Reply-To: <162443.1451204366@turing-police.cc.vt.edu>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <162443.1451204366@turing-police.cc.vt.edu>
Message-ID: <alpine.DEB.2.02.1512270934250.29581@uplift.swm.pp.se>

On Sun, 27 Dec 2015, Valdis.Kletnieks at vt.edu wrote:

> As finally we come full circle to the original question "who, if 
> anybody, has a list of which things are crap and which aren't" :)

Yep, and as far as I know, this list doesn't exist because people doesn't 
care enough so that someone would put the effort into creating such a 
list.

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

From owen at delong.com  Sun Dec 27 08:38:06 2015
From: owen at delong.com (Owen DeLong)
Date: Sun, 27 Dec 2015 00:38:06 -0800
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
Message-ID: <E74EA965-C470-49B5-969F-237AF33AA79B@delong.com>


> On Dec 26, 2015, at 20:35 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> Owen you misunderstood what two factor is about. It is not practical to
> brute force the key file. Nor is it practical to brute force a good
> passphrase or password. Both have sufficient strength to withstand attack.

This simply isn?t as true as it?s assumed to be, but let?s move on for the moment.

> But two factor is about having two things that needs to be broken. The key
> can be stolen, but the thief needs the password. The password can be
> stolen, but the thief needs the key. He needs both.

If the key file is stolen, you have one search space, the pass phrase to unlock the key.

If the key file is not stolen, you have one search space: the key.

> SSH password + key file is accepted as two factor by PCI DSS auditors, so
> yes it is in fact two factor.

PCI DSS auditors think that NAT is a form of security, so don?t get me started on the
fact that the PCI DSS auditors haven?t a clue about actual security. PCI DSS is more
about security theater than security. In some ways, they?re even less competent than
the TSA.

> But it is weak two factor because the key file is too easily stolen. NOT
> because the key file can be brute forced. Nor because hypothetically
> someone could memorize the content of the key file.

Either way, you only have one search space. If you don?t have the key file, then the
key is your search space. If you have the key file, then the passphrase may be an
easier search space.

> It is also weak because the key file can be duplicated. Note it does not
> stop being two factor because of this, but stronger hardware based two
> factor systems usually come with the property that it is very hard to
> duplicate the key. Other examples of a two factor system were the key is
> easy to duplicate is credit card with magnetic strip + pin. Example where
> it is hard to duplicate is credit card with chip + pin. Both are examples
> of where the password (the pin) is actually very weak, but it is still two
> factor.

To actually be two-factor, it needs to be two of something you have, something
you know, something you are. The strongest combination is something you know
and something you are (e.g. Retina, hand scan, etc. combined with PIN/Password).

SSH Key protected by pass phrase is just two things you know. Admittedly, one
of them is a thing you know because you stored it on disk instead of memorizing
it, but it?s not really something you have because as you pointed out, it can be
easily duplicated and also it can be transported without requiring physical
movement.

Something you have, in order to truly be a second factor, has to be a unique
item that is:
	1.	In your possession
	2.	Cannot be (easily) duplicated without your knowledge
		(The greater the degree of difficulty for duplication, the better this is,
		but a Schlage key, for example, is sufficiently difficult to qualify in most
		cases).
	3.	Theft can be reliably detected by the fact it is no longer in your possession.

An RSA or DSA key does not meet those criteria because it can be copied without
your knowledge and without removing the key from your possession.

> Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in
> fact have a strength equal to 1024 bits entropy. It was considered equal to
> about 128 bit of entropy, but is believed to be weaker now. I am using ECC
> ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people
> with tin foil hats believe we should stay away from NIST altogether. Unless
> someone breaks the crypto, you are NOT going to brute force that key.

I think you?re the first person to bring up 1024 RSA keys here. I only said private
keys. A very large fraction of SSH users are still using 1024 bit DSA keys in the
real world. I am still using 2048 bit DSA keys. ECC would be better.

I also didn?t say that a 1024 bit key had 1024 bits of entropy. I said that a 1024
bit key and a 256-character pass phrase have about the same entropy. There
are about 128 bits of entropy in a good 256 character pass phrase. There are
about 128 bits of entropy in a 1024 bit DSA key.

> Yes I get your argument, you are saying break the key and you won't need
> the password, but a) you can't actually break the key before the universe
> ends, b) it is still two factor, just a extremely tiny in the academic

If you have enough cheap GPUs, you can actually break a 1024 bit key
well before the universe ends. In fact, you can probably break it before
the end of 2016 if you?re willing to put about $30k into the process.

> sense little bit weaker two factor. All crypto based two factor systems

No, it?s not a second factor. See above? It?s two things you know and not
something you have and something you know as you have claimed.

Calling a private key something you have instead of something you know
is the same kind of slight of hand that Wall Street uses when they take
a bunch of bad mortgages and package them up together and call it an
AAA rated bond. (and we all saw how well that worked out). If you don?t
know what I?m talking about, ?The Big Short? is worth a watch.

> suffers from the possibility that one could break the crypto and possibly
> escape the need to know one or even both factors. But Owen - come one -

Nope? Something you have isn?t subject to breaking the crypto, because
it?s strength doesn?t come from crypto, it?s strength comes from unique
physical properties that are difficult to duplicate and can be measured.

Something you are similarly isn?t subject to breaking the crypto, because it?s
strength comes from the unique physical properties of an individual person
which can be measured and are difficult to duplicate.

Yes, both can be broken and there are weaker and stronger choices. For
example, a hand scanner is weaker than a retina scanner is weaker than
a DNA scanner. Many of the finger print scanners are weaker than the
hand scanners, but good ones are almost as strong as a retina scanner.

> this silly argument pales and is so infinite insignificant to the real
> problem with the ssh key two factor system, which is that the key is easily
> stolen and duplicated and there is no way to check the quality of the
> password (users might even change the key password to NO password).

Right? That was, in fact, what I originally said at the end of my initial
message, but you chose to ignore that and focus on this rathole.

Since misinformation and lack of pedantry is fatal to good cryptographic
security (or good security in general), I felt compelled to correct you and
I still stand by what I have said.

Likely, as usual, neither of us is going to convince the other one.

I will say, however, that my understanding of these issues comes from
mentors that work with real security professionals and I would never
cite something as weak as PCI-DSS as an authority.

Most of my mentors in this area work primarily on contracts with three
letter government agencies that may or may not be known to exist publicly.

Owen

> 
> Regards,
> 
> Baldur
> 
> 
> On 27 December 2015 at 03:37, Owen DeLong <owen at delong.com> wrote:
> 
>> 
>>> On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl at gmail.com>
>> wrote:
>>> 
>>> On 27 December 2015 at 00:11, Owen DeLong <owen at delong.com> wrote:
>>> 
>>>> No? You are missing the point. Guessing a private key is roughly
>>>> equivalent to guessing a really long
>>>> pass phrase. There is no way that the server side can enforce password
>>>> protection of the private key
>>>> on the client side, so if you are assuming that public-key
>> authentication
>>>> is two-factor, then you are
>>>> failing miserably.
>>>> 
>>> 
>>> The key approach is still better. Even if the password is 123456 the
>>> attacker is not going to get in, unless he somehow stole the key file.
>> 
>> Incorrect? It is possible the attacker could brute-force the key file.
>> 
>> A 1024 bit key is only as good as a ~256 character passphrase in terms of
>> entropy.
>> 
>> If you are brute force or otherwise synthesizing the private key, you do
>> not need
>> the passphrase for the on-disk key. As was pointed out elsewhere, the
>> passphrase
>> for the key file only matters if you already stole the key file.
>> 
>> In terms of guessing the private key vs. guessing a suitably long pass
>> phrase, the
>> difficulty is roughly equivalent.
>> 
>>> Technically it is two-factor even if the user made one of the factors
>>> really easy. And that might save the day if you have users that chooses
>> bad
>>> passwords.
>> 
>> Technically it?s not two-factor and pretending it is is dangerous.
>> 
>>> The system is weak in that it is too easy to steal the key file. It is
>> not
>>> unlikely that a user with sloppy passwords is also sloppy with his key
>> file.
>> 
>> Right? No matter what you do it is virtually impossible to protect against
>> sloppy
>> users.
>> 
>> This has been true for decades even before the internet with teenagers
>> given house
>> keys.
>> 
>>> Too bad ssh does not generally support a challenge-response protocol to a
>>> write only hardware key device combined with server side passwords that
>> can
>>> be checked against a blacklist.
>> 
>> There?s no reason that it can?t if you use PAM.
>> 
>> Owen
>> 
>> 


From list at satchell.net  Sun Dec 27 15:56:57 2015
From: list at satchell.net (Stephen Satchell)
Date: Sun, 27 Dec 2015 07:56:57 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
Message-ID: <56800A49.7070104@satchell.net>

On 12/26/2015 11:37 PM, Mikael Abrahamsson wrote:
> If someone like Consumer Reports or similar agency started testing and
> rating devices on these things like long-time support, automatic
> updates, software quality etc, and not just testing wifi speed as a
> factor of distance, we might get somewhere.

Just how would a reviewer rate "long-time support" and "software 
quality"?  As for "automatic updates", that's at the whim of the 
manufacturer down the road, so any evaluation of updates would be dated 
the second it's printed.

Testing WiFi speed as a factor of distance is a repeatable test, so that 
the chance of a lawsuit over the result is slimmer.

Consumer Reports, for example, sends out a survey to its readers to 
collect information on long-term ownership experience of cars.  It's a 
large enough investment that people are willing to fill out the survey. 
  Not so broadband routers.

From mike at mtcc.com  Sun Dec 27 16:49:11 2015
From: mike at mtcc.com (Michael Thomas)
Date: Sun, 27 Dec 2015 08:49:11 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
Message-ID: <56801687.2020401@mtcc.com>



On 12/26/2015 11:37 PM, Mikael Abrahamsson wrote:
> Providing security updates is just a cost, there is no upside, because 
> these boxes sit in a closet, unloved until they stop working, and 
> they're thrown out and replaced by a new unloved box that goes into 
> the closet until it stops working again.

IMO, this is the real problem, but there's a real opportunity. Routers 
are for most
people the only things which:

1) are always on
2) have internet connectivity

Which is pretty cool if you need something that is, oh say, a central 
controller
for your home. Put a headless Android in it, allow 3rd party apps, water the
lawn with it. Love ensues.

This is, I imagine, why Google bought Nest: they want to be that home 
central
controller. The home router is more ubiquitous though, IMHO.

Mike

From hugo at slabnet.com  Sun Dec 27 17:43:22 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Sun, 27 Dec 2015 09:43:22 -0800 (PST)
Subject: Broadband Router Comparisons
In-Reply-To: <56801687.2020401@mtcc.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com>
Message-ID: <2411cc39.kqhkiG.151e4899b4c@slabnet.com>



---- From: Michael Thomas <mike at mtcc.com> -- Sent: 2015-12-27 - 08:49 ----

>
>
> On 12/26/2015 11:37 PM, Mikael Abrahamsson wrote:
>> Providing security updates is just a cost, there is no upside, because
>> these boxes sit in a closet, unloved until they stop working, and
>> they're thrown out and replaced by a new unloved box that goes into
>> the closet until it stops working again.
>
> IMO, this is the real problem, but there's a real opportunity. Routers
> are for most
> people the only things which:
>
> 1) are always on
> 2) have internet connectivity
>
> Which is pretty cool if you need something that is, oh say, a central
> controller
> for your home. Put a headless Android in it, allow 3rd party apps, water the
> lawn with it. Love ensues.
>
> This is, I imagine, why Google bought Nest: they want to be that home
> central
> controller. The home router is more ubiquitous though, IMHO.

Hence: https://on.google.com/hub/

> Mike
>

--
Hugo
hugo at slabnet.com: email, xmpp/jabber
also on Signal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: PGP/MIME digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151227/d0a159be/attachment.pgp>

From mike at mtcc.com  Sun Dec 27 17:58:50 2015
From: mike at mtcc.com (Michael Thomas)
Date: Sun, 27 Dec 2015 09:58:50 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com> <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
Message-ID: <568026DA.2020900@mtcc.com>

Nice,  but i want my router to have an android environment itself, not 
just to
be controlled by my phone (which i want as well, of course).

The proximity sensor for app developers would be fun to play with, for 
example.

Mike

On 12/27/2015 09:43 AM, Hugo Slabbert wrote:
>
> ---- From: Michael Thomas <mike at mtcc.com> -- Sent: 2015-12-27 - 08:49 ----
>
>>
>> On 12/26/2015 11:37 PM, Mikael Abrahamsson wrote:
>>> Providing security updates is just a cost, there is no upside, because
>>> these boxes sit in a closet, unloved until they stop working, and
>>> they're thrown out and replaced by a new unloved box that goes into
>>> the closet until it stops working again.
>> IMO, this is the real problem, but there's a real opportunity. Routers
>> are for most
>> people the only things which:
>>
>> 1) are always on
>> 2) have internet connectivity
>>
>> Which is pretty cool if you need something that is, oh say, a central
>> controller
>> for your home. Put a headless Android in it, allow 3rd party apps, water the
>> lawn with it. Love ensues.
>>
>> This is, I imagine, why Google bought Nest: they want to be that home
>> central
>> controller. The home router is more ubiquitous though, IMHO.
> Hence: https://on.google.com/hub/
>
>> Mike
>>
> --
> Hugo
> hugo at slabnet.com: email, xmpp/jabber
> also on Signal
>


From bjorn at mork.no  Sun Dec 27 18:56:20 2015
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Sun, 27 Dec 2015 19:56:20 +0100
Subject: IPv4 shutdown in mobile
In-Reply-To: <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se> (Mikael
 Abrahamsson's message of "Fri, 25 Dec 2015 08:56:25 +0100 (CET)")
References: <CAD6AjGQwyMm3pMRwjU3fVK5r4hm8n0KLFHfQ1k4bd+jfu5mZbw@mail.gmail.com>
 <567CEC09.60609@seacom.mu>
 <alpine.DEB.2.02.1512250851020.29581@uplift.swm.pp.se>
Message-ID: <87ziwvoh4b.fsf@nemi.mork.no>

Mikael Abrahamsson <swmike at swm.pp.se> writes:

> North America is by far the leader in number of IPv6 enabled customers
> which
>
> https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-exhaustion-global-heat-map-network-country-growth-data.html#networks
>
> shows.

On the top ten country list, I see

 6 European countries (Belgium, Germany, Luxembourg, Estonia, France, Norway)
 1 African country (Liberia)
 1 North American country (USA)
 1 Oceanian country (Kiribati)
 1 Asian country (Malaysia)

Looks like Europe is way ahead to me :)


Bj?rn

From Valdis.Kletnieks at vt.edu  Sun Dec 27 18:59:20 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 27 Dec 2015 13:59:20 -0500
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
Message-ID: <204103.1451242760@turing-police.cc.vt.edu>

On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:

> SSH password + key file is accepted as two factor by PCI DSS auditors, so
> yes it is in fact two factor.

They also accept NAT as "security".  If anything, PCI DSS is yet another example
of a money grab masquerading as security theater (not even real security).
I remember seeing a story a while ago that stated that of companies hit
by a data breach on a system that was inside their PCI scope, something
insane like 98% or 99% were in 100% full PCI compliance at the time of
the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
are missing a lot of really crucial things for real security.  (And let's
not forget the competence level of the average PCI auditor, as the ones
I've encountered have all been very nice people, but more suited to checking
boxes based on buzzwords than actual in-deopth security analysis).

So excuse me for not taking "is accepted by PCI auditors" as grounds for
a claim of strong actual security.
-------------- 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/20151227/01ceb583/attachment.pgp>

From morrowc.lists at gmail.com  Sun Dec 27 19:26:20 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 27 Dec 2015 14:26:20 -0500
Subject: de-peering for security sake
In-Reply-To: <204103.1451242760@turing-police.cc.vt.edu>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>

On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>
>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>> yes it is in fact two factor.
>
> They also accept NAT as "security".  If anything, PCI DSS is yet another example
> of a money grab masquerading as security theater (not even real security).

is it that? or is it that once you click the checkboxes on /pci audit/
'no one' ever does the daily due-diligence required to keep their
security processes updated/running/current/etc ?

I'm not a fan of the compliance regimes, but their goal (in a utopian
world where corporations are not people and such) is the equivalent of
the little posterboard person 42" tall before the roller-coaster
rides, right?

"You really, REALLY should have at least these protections/systems/etc
in place before you attempt to process credit-card transactions..."

In the utopian world this list would be sane, useful and would include
daily/etc processes to monitor the security controls for issues... I
don't think there's a process bit in PCI about: "And joey the firewall
admin looks at his logs daily/hourly/everly for evidence of
compromise" (and yes, ideally there's some adaptive/learning/AI-like
system that does the 'joey the firewall admin' step... but let's walk
before running, eh?)

so, it's not really a mystery why failures like this happen.

> I remember seeing a story a while ago that stated that of companies hit
> by a data breach on a system that was inside their PCI scope, something
> insane like 98% or 99% were in 100% full PCI compliance at the time of
> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
> are missing a lot of really crucial things for real security.  (And let's
> not forget the competence level of the average PCI auditor, as the ones
> I've encountered have all been very nice people, but more suited to checking
> boxes based on buzzwords than actual in-deopth security analysis).

people toss pci/sox/etc auditors under the bus 'all the time', and i'm
guilty of this i'm sure as well, but really ... if you put systems on
the tubes and you don't take the same care you would for your
brick/mortar places ... you're gonna have a bad day. 'cyber security'
really isn't a whole lot different from 'lock your damned doors and
windows' brick/mortar security.

> So excuse me for not taking "is accepted by PCI auditors" as grounds for
> a claim of strong actual security.

From eyeronic.design at gmail.com  Sun Dec 27 19:49:15 2015
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sun, 27 Dec 2015 11:49:15 -0800
Subject: de-peering for security sake
In-Reply-To: <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
Message-ID: <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>

"really isn't a whole lot different from 'lock your damned doors and
windows' brick/mortar security."

Except it's *massively* more expensive.

On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>
>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>> yes it is in fact two factor.
>>
>> They also accept NAT as "security".  If anything, PCI DSS is yet another example
>> of a money grab masquerading as security theater (not even real security).
>
> is it that? or is it that once you click the checkboxes on /pci audit/
> 'no one' ever does the daily due-diligence required to keep their
> security processes updated/running/current/etc ?
>
> I'm not a fan of the compliance regimes, but their goal (in a utopian
> world where corporations are not people and such) is the equivalent of
> the little posterboard person 42" tall before the roller-coaster
> rides, right?
>
> "You really, REALLY should have at least these protections/systems/etc
> in place before you attempt to process credit-card transactions..."
>
> In the utopian world this list would be sane, useful and would include
> daily/etc processes to monitor the security controls for issues... I
> don't think there's a process bit in PCI about: "And joey the firewall
> admin looks at his logs daily/hourly/everly for evidence of
> compromise" (and yes, ideally there's some adaptive/learning/AI-like
> system that does the 'joey the firewall admin' step... but let's walk
> before running, eh?)
>
> so, it's not really a mystery why failures like this happen.
>
>> I remember seeing a story a while ago that stated that of companies hit
>> by a data breach on a system that was inside their PCI scope, something
>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
>> are missing a lot of really crucial things for real security.  (And let's
>> not forget the competence level of the average PCI auditor, as the ones
>> I've encountered have all been very nice people, but more suited to checking
>> boxes based on buzzwords than actual in-deopth security analysis).
>
> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
> guilty of this i'm sure as well, but really ... if you put systems on
> the tubes and you don't take the same care you would for your
> brick/mortar places ... you're gonna have a bad day. 'cyber security'
> really isn't a whole lot different from 'lock your damned doors and
> windows' brick/mortar security.
>
>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>> a claim of strong actual security.



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

From surfer at mauigateway.com  Sun Dec 27 19:55:05 2015
From: surfer at mauigateway.com (Scott Weeks)
Date: Sun, 27 Dec 2015 11:55:05 -0800
Subject: IPv4 shutdown in mobile
Message-ID: <20151227115505.974A6D46@m0087791.ppops.net>


---------------------------
> North America is by far the leader in number of IPv6 enabled customers

On the top ten country list, I see

 6 European countries (Belgium, Germany, Luxembourg, Estonia, France, Norway)
 1 African country (Liberia)
 1 North American country (USA)
 1 Oceanian country (Kiribati)
 1 Asian country (Malaysia)
--------------------------------------------

Not a good comparison.  Christian (the Kiribati guy) has a very 
different set of circumstances than, say, EU or NA folks.

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

"The nation comprises 33 atolls and reef islands and one raised coral 
island; Banaba. They have a total land area of 800 square kilometres 
(310 sq mi)[13] and are dispersed over 3.5 million square kilometres 
(1,351,000 square miles). Their spread straddles the equator and the 
International Date Line, although the Date Line is indented to bring 
the Line Islands in the same day as the Kiribati Islands. The 
permanent population is just over 100,000 (2011), half of whom live 
on Tarawa Atoll."

scott

From randy at psg.com  Sun Dec 27 20:14:14 2015
From: randy at psg.com (Randy Bush)
Date: Mon, 28 Dec 2015 05:14:14 +0900
Subject: de-peering for security sake
In-Reply-To: <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
Message-ID: <m24mf3r6nd.wl%randy@psg.com>

> 'cyber security' really isn't a whole lot different from 'lock your
> damned doors and windows' brick/mortar security.

hellofalot more holes to cover.  and the salaries of the guards are a
bit higher for the net; so more incentive for pointy heads to skimp.

randy

From morrowc.lists at gmail.com  Sun Dec 27 20:27:05 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 27 Dec 2015 15:27:05 -0500
Subject: de-peering for security sake
In-Reply-To: <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>
Message-ID: <CAL9jLaa8985B0TEkmQScPa6OAq-f_DL9V=YFnwp=535tuvacTQ@mail.gmail.com>

On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design at gmail.com> wrote:
> "really isn't a whole lot different from 'lock your damned doors and
> windows' brick/mortar security."
>
> Except it's *massively* more expensive.
>

is it? how much does a datacenter pay for people + locks + card-key +
pin-pad + ...

vs

 the requisite bits for security their customer portal/backoffice/etc ?

done right the cost shouldn't be super much more.

-chris

> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>> On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>>
>>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>>> yes it is in fact two factor.
>>>
>>> They also accept NAT as "security".  If anything, PCI DSS is yet another example
>>> of a money grab masquerading as security theater (not even real security).
>>
>> is it that? or is it that once you click the checkboxes on /pci audit/
>> 'no one' ever does the daily due-diligence required to keep their
>> security processes updated/running/current/etc ?
>>
>> I'm not a fan of the compliance regimes, but their goal (in a utopian
>> world where corporations are not people and such) is the equivalent of
>> the little posterboard person 42" tall before the roller-coaster
>> rides, right?
>>
>> "You really, REALLY should have at least these protections/systems/etc
>> in place before you attempt to process credit-card transactions..."
>>
>> In the utopian world this list would be sane, useful and would include
>> daily/etc processes to monitor the security controls for issues... I
>> don't think there's a process bit in PCI about: "And joey the firewall
>> admin looks at his logs daily/hourly/everly for evidence of
>> compromise" (and yes, ideally there's some adaptive/learning/AI-like
>> system that does the 'joey the firewall admin' step... but let's walk
>> before running, eh?)
>>
>> so, it's not really a mystery why failures like this happen.
>>
>>> I remember seeing a story a while ago that stated that of companies hit
>>> by a data breach on a system that was inside their PCI scope, something
>>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>>> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
>>> are missing a lot of really crucial things for real security.  (And let's
>>> not forget the competence level of the average PCI auditor, as the ones
>>> I've encountered have all been very nice people, but more suited to checking
>>> boxes based on buzzwords than actual in-deopth security analysis).
>>
>> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
>> guilty of this i'm sure as well, but really ... if you put systems on
>> the tubes and you don't take the same care you would for your
>> brick/mortar places ... you're gonna have a bad day. 'cyber security'
>> really isn't a whole lot different from 'lock your damned doors and
>> windows' brick/mortar security.
>>
>>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>>> a claim of strong actual security.
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

From eyeronic.design at gmail.com  Sun Dec 27 20:32:14 2015
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sun, 27 Dec 2015 12:32:14 -0800
Subject: de-peering for security sake
In-Reply-To: <CAL9jLaa8985B0TEkmQScPa6OAq-f_DL9V=YFnwp=535tuvacTQ@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>
 <CAL9jLaa8985B0TEkmQScPa6OAq-f_DL9V=YFnwp=535tuvacTQ@mail.gmail.com>
Message-ID: <CAN3um4znnote39PeSo_v3JPZ0Pr2wWBce_GKadZTOkFq3xmFTA@mail.gmail.com>

"done right the cost shouldn't be super much more."
I disagree.  Done wrong, it's not super much more.

Done right, it's massively more.

Like Randy said, compare salaries alone.  A good security employee
will run you, what, 100k or more in the major job markets?  And how
many do you need, full time, to provide acceptable coverage for your
environment?

The costs add up really fast without a corresponding return.



On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design at gmail.com> wrote:
>> "really isn't a whole lot different from 'lock your damned doors and
>> windows' brick/mortar security."
>>
>> Except it's *massively* more expensive.
>>
>
> is it? how much does a datacenter pay for people + locks + card-key +
> pin-pad + ...
>
> vs
>
>  the requisite bits for security their customer portal/backoffice/etc ?
>
> done right the cost shouldn't be super much more.
>
> -chris
>
>> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
>> <morrowc.lists at gmail.com> wrote:
>>> On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>>>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>>>
>>>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>>>> yes it is in fact two factor.
>>>>
>>>> They also accept NAT as "security".  If anything, PCI DSS is yet another example
>>>> of a money grab masquerading as security theater (not even real security).
>>>
>>> is it that? or is it that once you click the checkboxes on /pci audit/
>>> 'no one' ever does the daily due-diligence required to keep their
>>> security processes updated/running/current/etc ?
>>>
>>> I'm not a fan of the compliance regimes, but their goal (in a utopian
>>> world where corporations are not people and such) is the equivalent of
>>> the little posterboard person 42" tall before the roller-coaster
>>> rides, right?
>>>
>>> "You really, REALLY should have at least these protections/systems/etc
>>> in place before you attempt to process credit-card transactions..."
>>>
>>> In the utopian world this list would be sane, useful and would include
>>> daily/etc processes to monitor the security controls for issues... I
>>> don't think there's a process bit in PCI about: "And joey the firewall
>>> admin looks at his logs daily/hourly/everly for evidence of
>>> compromise" (and yes, ideally there's some adaptive/learning/AI-like
>>> system that does the 'joey the firewall admin' step... but let's walk
>>> before running, eh?)
>>>
>>> so, it's not really a mystery why failures like this happen.
>>>
>>>> I remember seeing a story a while ago that stated that of companies hit
>>>> by a data breach on a system that was inside their PCI scope, something
>>>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>>>> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
>>>> are missing a lot of really crucial things for real security.  (And let's
>>>> not forget the competence level of the average PCI auditor, as the ones
>>>> I've encountered have all been very nice people, but more suited to checking
>>>> boxes based on buzzwords than actual in-deopth security analysis).
>>>
>>> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
>>> guilty of this i'm sure as well, but really ... if you put systems on
>>> the tubes and you don't take the same care you would for your
>>> brick/mortar places ... you're gonna have a bad day. 'cyber security'
>>> really isn't a whole lot different from 'lock your damned doors and
>>> windows' brick/mortar security.
>>>
>>>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>>>> a claim of strong actual security.
>>
>>
>>
>> --
>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0



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

From randy at psg.com  Sun Dec 27 20:44:26 2015
From: randy at psg.com (Randy Bush)
Date: Mon, 28 Dec 2015 05:44:26 +0900
Subject: de-peering for security sake
In-Reply-To: <CAN3um4znnote39PeSo_v3JPZ0Pr2wWBce_GKadZTOkFq3xmFTA@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>
 <CAL9jLaa8985B0TEkmQScPa6OAq-f_DL9V=YFnwp=535tuvacTQ@mail.gmail.com>
 <CAN3um4znnote39PeSo_v3JPZ0Pr2wWBce_GKadZTOkFq3xmFTA@mail.gmail.com>
Message-ID: <m2wprzpqol.wl%randy@psg.com>

> The costs add up really fast without a corresponding return.

i think there is a corresponding return, just not one that is perceived
by the pointy heads.  yet.  but that is changing as more and more get
pwned and the public and legal costs become greater and more apparent.
patience.

randy

From morrowc.lists at gmail.com  Sun Dec 27 20:51:17 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 27 Dec 2015 15:51:17 -0500
Subject: de-peering for security sake
In-Reply-To: <CAN3um4znnote39PeSo_v3JPZ0Pr2wWBce_GKadZTOkFq3xmFTA@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>
 <CAL9jLaa8985B0TEkmQScPa6OAq-f_DL9V=YFnwp=535tuvacTQ@mail.gmail.com>
 <CAN3um4znnote39PeSo_v3JPZ0Pr2wWBce_GKadZTOkFq3xmFTA@mail.gmail.com>
Message-ID: <CAL9jLabbcWtgPap3FPnCkKoC6z7J8HUqJoxPw1eETexk2UfnwQ@mail.gmail.com>

On Sun, Dec 27, 2015 at 3:32 PM, Mike Hale <eyeronic.design at gmail.com> wrote:
> "done right the cost shouldn't be super much more."
> I disagree.  Done wrong, it's not super much more.
>
> Done right, it's massively more.

please cite useful numbers... It's not (I think) really all that much
more. Sure it's a new expense (not really, since ... you've always had
security costs) but it's not 'massive'.

> Like Randy said, compare salaries alone.  A good security employee
> will run you, what, 100k or more in the major job markets?  And how
> many do you need, full time, to provide acceptable coverage for your
> environment?
>

ideally you need 2-3 people (for a larger operation, less for small
shops) with a bunch of automation to help things run along. Ideally
your 2-3 experts aren't responding to the pager, almost all of that is
offloaded to your noc/etc staff in a manner that they can actually
deal with problems NOT as pager-spam which gets turned off. 'high
quality alerts' with actionable playbooks.

it'd be great if more of this was COTS-able for the smaller shops... I
bet a bunch of it IS, though the parts aren't quite in place today :(
which is sad.

> The costs add up really fast without a corresponding return.

the return is not having to fend off the WSJ reporters of the world,
and consequent lawsuits from your customers, subscribers, partners,
etc...

-chris

> On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
>> On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design at gmail.com> wrote:
>>> "really isn't a whole lot different from 'lock your damned doors and
>>> windows' brick/mortar security."
>>>
>>> Except it's *massively* more expensive.
>>>
>>
>> is it? how much does a datacenter pay for people + locks + card-key +
>> pin-pad + ...
>>
>> vs
>>
>>  the requisite bits for security their customer portal/backoffice/etc ?
>>
>> done right the cost shouldn't be super much more.
>>
>> -chris
>>
>>> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
>>> <morrowc.lists at gmail.com> wrote:
>>>> On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>>>>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>>>>
>>>>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>>>>> yes it is in fact two factor.
>>>>>
>>>>> They also accept NAT as "security".  If anything, PCI DSS is yet another example
>>>>> of a money grab masquerading as security theater (not even real security).
>>>>
>>>> is it that? or is it that once you click the checkboxes on /pci audit/
>>>> 'no one' ever does the daily due-diligence required to keep their
>>>> security processes updated/running/current/etc ?
>>>>
>>>> I'm not a fan of the compliance regimes, but their goal (in a utopian
>>>> world where corporations are not people and such) is the equivalent of
>>>> the little posterboard person 42" tall before the roller-coaster
>>>> rides, right?
>>>>
>>>> "You really, REALLY should have at least these protections/systems/etc
>>>> in place before you attempt to process credit-card transactions..."
>>>>
>>>> In the utopian world this list would be sane, useful and would include
>>>> daily/etc processes to monitor the security controls for issues... I
>>>> don't think there's a process bit in PCI about: "And joey the firewall
>>>> admin looks at his logs daily/hourly/everly for evidence of
>>>> compromise" (and yes, ideally there's some adaptive/learning/AI-like
>>>> system that does the 'joey the firewall admin' step... but let's walk
>>>> before running, eh?)
>>>>
>>>> so, it's not really a mystery why failures like this happen.
>>>>
>>>>> I remember seeing a story a while ago that stated that of companies hit
>>>>> by a data breach on a system that was inside their PCI scope, something
>>>>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>>>>> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
>>>>> are missing a lot of really crucial things for real security.  (And let's
>>>>> not forget the competence level of the average PCI auditor, as the ones
>>>>> I've encountered have all been very nice people, but more suited to checking
>>>>> boxes based on buzzwords than actual in-deopth security analysis).
>>>>
>>>> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
>>>> guilty of this i'm sure as well, but really ... if you put systems on
>>>> the tubes and you don't take the same care you would for your
>>>> brick/mortar places ... you're gonna have a bad day. 'cyber security'
>>>> really isn't a whole lot different from 'lock your damned doors and
>>>> windows' brick/mortar security.
>>>>
>>>>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>>>>> a claim of strong actual security.
>>>
>>>
>>>
>>> --
>>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

From eyeronic.design at gmail.com  Sun Dec 27 21:08:05 2015
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sun, 27 Dec 2015 13:08:05 -0800
Subject: de-peering for security sake
In-Reply-To: <CAL9jLabbcWtgPap3FPnCkKoC6z7J8HUqJoxPw1eETexk2UfnwQ@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <CAN3um4xT0beWuDBgPA4SfPdfzhBsc=ms7U52Q3-ueHnEbvffbA@mail.gmail.com>
 <CAL9jLaa8985B0TEkmQScPa6OAq-f_DL9V=YFnwp=535tuvacTQ@mail.gmail.com>
 <CAN3um4znnote39PeSo_v3JPZ0Pr2wWBce_GKadZTOkFq3xmFTA@mail.gmail.com>
 <CAL9jLabbcWtgPap3FPnCkKoC6z7J8HUqJoxPw1eETexk2UfnwQ@mail.gmail.com>
Message-ID: <CAN3um4xo6zYYp4K-FTGp1RH6EgBJj1xDyL4XwZqo6EdEtqy5pw@mail.gmail.com>

"please cite useful numbers"

For what?  IDS?  SIEM?  Log aggregation in general?  For companies
that have none of that, spinning up the best practice systems can
easily cost half a mil a year (QRadar is 200k for our sized
environment; a good netflow system is like 50 [100k+ for something
like Lancope], one FTE to support and manage this as and additional
workload on server and network guys in dealing with issues these tools
find).  And that's just the tip of the iceberg.  An additional 500k a
year is tough to justify (and costs way, way more than simply locking
the doors or hiring a team of security guards at 10 an hour).
Simplistic, of course, but one example of the cost difference.

"Sure it's a new expense (not really, since ... you've always had
security costs) but it's not 'massive'."

Depends on the organization.  For those who don't have a
security-specific team, it is new spend.

"ideally you need 2-3 people (for a larger operation, less for small
shops) with a bunch of automation to help things run along."

Absolutely agree.  So we're looking at 200-300k just in pure salary
cost, plus what, 40% extra for various benefits?

That automation piece too is incredibly pricey (either in time and
labor of software).

"though the parts aren't quite in place today :(
which is sad."

One hundred percent in agreement.  This is much, much harder for the
smaller organizations to take.  I wish there were services that made
this way easier.  I think this is where small system integrators could
partner with security services that provide tier one security response
(something like arctic wolf) and provide that needed coverage...but
that's not inexpensive either (though way cheaper than hiring your own
security dudes).

"the return is not having to fend off the WSJ reporters of the world,
and consequent lawsuits from your customers, subscribers, partners,
etc..."

True.  But how do you put that in money terms?

Obviously, I think the spend is absolutely important, and it's
something that is vitally important to the business.  But I've found
it very challenging in making that case in a way that works, precisely
because of that increased amount of spending.

"but that is changing as more and more get
pwned and the public and legal costs become greater and more apparent.
patience."

It is.  Sony and Target were really useful in that regard.

On Sun, Dec 27, 2015 at 12:51 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Sun, Dec 27, 2015 at 3:32 PM, Mike Hale <eyeronic.design at gmail.com> wrote:
>> "done right the cost shouldn't be super much more."
>> I disagree.  Done wrong, it's not super much more.
>>
>> Done right, it's massively more.
>
> please cite useful numbers... It's not (I think) really all that much
> more. Sure it's a new expense (not really, since ... you've always had
> security costs) but it's not 'massive'.
>
>> Like Randy said, compare salaries alone.  A good security employee
>> will run you, what, 100k or more in the major job markets?  And how
>> many do you need, full time, to provide acceptable coverage for your
>> environment?
>>
>
> ideally you need 2-3 people (for a larger operation, less for small
> shops) with a bunch of automation to help things run along. Ideally
> your 2-3 experts aren't responding to the pager, almost all of that is
> offloaded to your noc/etc staff in a manner that they can actually
> deal with problems NOT as pager-spam which gets turned off. 'high
> quality alerts' with actionable playbooks.
>
> it'd be great if more of this was COTS-able for the smaller shops... I
> bet a bunch of it IS, though the parts aren't quite in place today :(
> which is sad.
>
>> The costs add up really fast without a corresponding return.
>
> the return is not having to fend off the WSJ reporters of the world,
> and consequent lawsuits from your customers, subscribers, partners,
> etc...
>
> -chris
>
>> On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow
>> <morrowc.lists at gmail.com> wrote:
>>> On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design at gmail.com> wrote:
>>>> "really isn't a whole lot different from 'lock your damned doors and
>>>> windows' brick/mortar security."
>>>>
>>>> Except it's *massively* more expensive.
>>>>
>>>
>>> is it? how much does a datacenter pay for people + locks + card-key +
>>> pin-pad + ...
>>>
>>> vs
>>>
>>>  the requisite bits for security their customer portal/backoffice/etc ?
>>>
>>> done right the cost shouldn't be super much more.
>>>
>>> -chris
>>>
>>>> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
>>>> <morrowc.lists at gmail.com> wrote:
>>>>> On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>>>>>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>>>>>
>>>>>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>>>>>> yes it is in fact two factor.
>>>>>>
>>>>>> They also accept NAT as "security".  If anything, PCI DSS is yet another example
>>>>>> of a money grab masquerading as security theater (not even real security).
>>>>>
>>>>> is it that? or is it that once you click the checkboxes on /pci audit/
>>>>> 'no one' ever does the daily due-diligence required to keep their
>>>>> security processes updated/running/current/etc ?
>>>>>
>>>>> I'm not a fan of the compliance regimes, but their goal (in a utopian
>>>>> world where corporations are not people and such) is the equivalent of
>>>>> the little posterboard person 42" tall before the roller-coaster
>>>>> rides, right?
>>>>>
>>>>> "You really, REALLY should have at least these protections/systems/etc
>>>>> in place before you attempt to process credit-card transactions..."
>>>>>
>>>>> In the utopian world this list would be sane, useful and would include
>>>>> daily/etc processes to monitor the security controls for issues... I
>>>>> don't think there's a process bit in PCI about: "And joey the firewall
>>>>> admin looks at his logs daily/hourly/everly for evidence of
>>>>> compromise" (and yes, ideally there's some adaptive/learning/AI-like
>>>>> system that does the 'joey the firewall admin' step... but let's walk
>>>>> before running, eh?)
>>>>>
>>>>> so, it's not really a mystery why failures like this happen.
>>>>>
>>>>>> I remember seeing a story a while ago that stated that of companies hit
>>>>>> by a data breach on a system that was inside their PCI scope, something
>>>>>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>>>>>> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
>>>>>> are missing a lot of really crucial things for real security.  (And let's
>>>>>> not forget the competence level of the average PCI auditor, as the ones
>>>>>> I've encountered have all been very nice people, but more suited to checking
>>>>>> boxes based on buzzwords than actual in-deopth security analysis).
>>>>>
>>>>> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
>>>>> guilty of this i'm sure as well, but really ... if you put systems on
>>>>> the tubes and you don't take the same care you would for your
>>>>> brick/mortar places ... you're gonna have a bad day. 'cyber security'
>>>>> really isn't a whole lot different from 'lock your damned doors and
>>>>> windows' brick/mortar security.
>>>>>
>>>>>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>>>>>> a claim of strong actual security.
>>>>
>>>>
>>>>
>>>> --
>>>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>>
>>
>>
>> --
>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0



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

From owen at delong.com  Sun Dec 27 21:08:32 2015
From: owen at delong.com (Owen DeLong)
Date: Sun, 27 Dec 2015 13:08:32 -0800
Subject: de-peering for security sake
In-Reply-To: <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
Message-ID: <D8E60BD7-E428-4663-B629-996CC2DE195B@delong.com>


> On Dec 27, 2015, at 11:26 , Christopher Morrow <morrowc.lists at gmail.com> wrote:
> 
> On Sun, Dec 27, 2015 at 1:59 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>> 
>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>> yes it is in fact two factor.
>> 
>> They also accept NAT as "security".  If anything, PCI DSS is yet another example
>> of a money grab masquerading as security theater (not even real security).
> 
> is it that? or is it that once you click the checkboxes on /pci audit/
> 'no one' ever does the daily due-diligence required to keep their
> security processes updated/running/current/etc ?

You ask this as if those two were mutually exclusive. They are not. I believe
that both are actually true. The PCI-DSS checklist can be completed without
relatively weak security and involves a lot of theatrical requirements that have
nothing to do with actual security.

Beyond that, yes, most organizations survive the audit and then go back to
ignore it until time for the next audit mode.

> I'm not a fan of the compliance regimes, but their goal (in a utopian
> world where corporations are not people and such) is the equivalent of
> the little posterboard person 42" tall before the roller-coaster
> rides, right?
> 
> "You really, REALLY should have at least these protections/systems/etc
> in place before you attempt to process credit-card transactions?"

Right. And that?s a decent goal. Unfortunately, if you read the actual document,
the standards require lots of things that don?t actually improve (and in some
cases can actually degrade) security, such as NAT.

> In the utopian world this list would be sane, useful and would include
> daily/etc processes to monitor the security controls for issues... I
> don't think there's a process bit in PCI about: "And joey the firewall
> admin looks at his logs daily/hourly/everly for evidence of
> compromise" (and yes, ideally there's some adaptive/learning/AI-like
> system that does the 'joey the firewall admin' step... but let's walk
> before running, eh?)

Yeah, it doesn?t actually require anyone or anything to ever really look at
logs at all.

> so, it's not really a mystery why failures like this happen.

This is a bit of a tangent, really. The discussion was about authentication factor
counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
private key authentication as two-factor to bolster his claim that it was, in fact
two-factor, when it clearly isn?t actually two-factor as has been stated previously.

The comments about PCI-DSS being a non-credible standard were primarily
an additional note that his argument was built on thin air.

>> I remember seeing a story a while ago that stated that of companies hit
>> by a data breach on a system that was inside their PCI scope, something
>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
>> are missing a lot of really crucial things for real security.  (And let's
>> not forget the competence level of the average PCI auditor, as the ones
>> I've encountered have all been very nice people, but more suited to checking
>> boxes based on buzzwords than actual in-deopth security analysis).
> 
> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
> guilty of this i'm sure as well, but really ... if you put systems on
> the tubes and you don't take the same care you would for your
> brick/mortar places ... you're gonna have a bad day. 'cyber security'
> really isn't a whole lot different from 'lock your damned doors and
> windows' brick/mortar security.

Conceptually, sure. However, in actual implementation, there?s a plethora of
decent locksmiths and reasonably good security contractors out there to provide
good solutions for physical security.

In the cyber security world, the waters are a lot murkier. There are no good
standards to allow a lay person to identify a good capable contractor vs. a
charlatan with a flashy web site. Most of the widely known standards are
crap. I?ve met some really good CISSPs in my day, but I?ve also met a number
of people touting their CISSP certification who don?t realize that NAT is actually
detrimental to security and a few who even claimed that NAT was good.

Several couldn?t even get the concept of separating NAT from stateful inspection
after repeated attempts to explain it to them in kindergarten terms.

Cyber security is a lot harder to understand well and quite a bit more complicated
than physical security.

Owen



From baldur.norddahl at gmail.com  Sun Dec 27 22:33:17 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sun, 27 Dec 2015 23:33:17 +0100
Subject: de-peering for security sake
In-Reply-To: <D8E60BD7-E428-4663-B629-996CC2DE195B@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <D8E60BD7-E428-4663-B629-996CC2DE195B@delong.com>
Message-ID: <CAPkb-7D23c+07Bk_n4KAQWZ8PWE-ztoQ=cPzHX_w5TqG813adA@mail.gmail.com>

On 27 December 2015 at 22:08, Owen DeLong <owen at delong.com> wrote:

> This is a bit of a tangent, really. The discussion was about
> authentication factor
> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
> private key authentication as two-factor to bolster his claim that it was,
> in fact
> two-factor, when it clearly isn?t actually two-factor as has been stated
> previously.
>

I wanted to stay out of this, but Owen you are full of shit here. I am
pointing out that your homemade definition does not match up with what
others think two factor means. PCI DSS might be utter crap, but they are
still more than "Owen DeLong and his personal opinion".

You are utterly confused about the meaning about two factor. You apparently
believe the magic words "two factor" is a statement about the security of a
system, while it is in fact just a simple property. A property that even an
inherently insecure and weak system can have.

It is not, as you have said, about strengthen the search space of a crypto
key (just double the key length if you need that). In fact, many two factor
systems do not use crypto keys at all. An example of such a non crypto
based system is a credit card with magnetic strip plus pin. The magnetic
strip contains just the card number, which can also be read directly from
the card and even memorized by the owner.

We need two factor because if you have just one factor, say the password,
the hacker will simply call the user and ask him to tell the password. And
the users will happily obligate. Experience shows this. On the other hand,
if you give the users a single factor system with a physical token (a key),
that gets stolen, misplaced or "borrowed" far too easily. Therefore
industry standard is card + pin to enter a building (=two factor). Secure
places require three factor (card + pin + biometric).

SSH keys are two factor because people do not in general memorize the key
file. Because they do not, you can not gain access to the system with only
what you know (=in your mind). Unless the user violated protocols and
changed the passphrase to null, you can not gain access just by possession
of the key file. That is all that is required to name it two factor. That
Owen DeLong believes the system stinks does not change that at all.

Historically the banks used to depend on a system that is the same as ssh
keys: certificate files you have on your computer to access the bank
website. That also is a two factor system. The users did not usually
memorize the content of the certificates. The system is weak because bad
guys used malware to steal the certificate files and install key loggers to
also get the other factor, the password.

In my country (Denmark) they decided hardware keys are still too expensive,
so they developed a two factor system based on paper keys. You will get a
piece of paper with a few hundred random numbers. When you log in, you are
asked to type one of the numbers in to prove that you are in possession of
the key paper. The codes are just 6 digits and infinite weak if you believe
them to be part of any crypto scheme. This system has also been broken
because now bad guys ask the users to take pictures of the key paper to
prove something, and the users happily do just that. Banks are still happy
though, because the loss is less than the cost to ship hardware keys to
everyone.

Only strong two factor systems are really resistant to the users defeating
the system by doing stupid things. That does not mean that only strong two
factor systems are two factor. That would be silly - Owen what would you
then name weak and broken two factor systems? It is a property - nothing
more.

Regards,

Baldur

From larrysheldon at cox.net  Mon Dec 28 00:54:46 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sun, 27 Dec 2015 18:54:46 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <567F7BF7.9070106@tiedyenetworks.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
Message-ID: <56808856.20904@cox.net>

On 12/26/2015 23:49, Mike wrote:
> On 12/23/2015 06:49 PM, Lorell Hathcock wrote:
>> All:
>>
>> Not all consumer grade customer premises equipment is created
>> equally.  But end customers sure think it is.  I have retirement aged
>> customers buying the crappiest routers and then blaming my cable
>> network for all their connection woes.  The real problem is that there
>> were plenty of problems on the cable network to deal with, so it was
>> impossible to tell between a problem that a customer was having with
>> their CPE versus a real problem in my network.

OK, I have resisted, but now I must ask.....

I am coming up on 77 YOA, been un-employed for a long time, have a tiny 
toy network that supports a couple of lap-tops, a couple of desk-tops, a 
couple of net-work-connected printers, and a melange of 
visitor-transported "personal devices" NOS--the latter group, the two 
lap-tops, one of the printers, and one of the desk-tops supported by 3 
wiffy radios (one radio is a port of the "routher").

My network sees the the world via a cable-company provided MODEM (which 
also supports the telephone service in the house) and a WRT54GL 
"router", which I guess is what y'all are talking about (although it 
looks to me more like a 6-port bridge that can do NAT).

I've had one "router" fail and replaced it.  I have myriad network 
failures that go away if I wait long enough (I have called in a few 
times, mostly to confirm that the cable has gone dark and they know it, 
a couple to have them tell me to reboot everything I rebooted before I 
called them.  In some of those incidents the "trouble came clear while 
testing", the rest "came clear while waiting for the repair man to get 
here".

Just what is it that I should be doing better?  And where is this better 
equipment available?

[tl;dr;wrn]

-- 
sed quis custodiet ipsos custodes? (Juvenal)

From larrysheldon at cox.net  Mon Dec 28 00:57:51 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sun, 27 Dec 2015 18:57:51 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <567F7BF7.9070106@tiedyenetworks.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
Message-ID: <5680890F.3070807@cox.net>

On 12/26/2015 23:49, Mike wrote:

[snip]

> Firstly, they are all junk. Every last one of them. Period. Broadband
> routers are designed to be cheap and to appeal to people who don't know
> any better, and who respond well (eg: make purchasing decisions) based
> on the shape of the plastic, the color scheme employed, and number of
> mysterious blinking lights that convey 'something important is
> happening'. Further, the price point is $45 - $70 thereabouts, putting
> some definite constraints on the actual quality of the engineering and
> components that go into them. I feel that we, the service provider,
> endure a significantly high and undue burden of cost associated with
> providing ongoing support to customers as a result of the defects
> contained therein.

Why don't you offer an acceptable (to you) device at a price acceptable 
to me as a part of the service.  I'd buy it.


-- 
sed quis custodiet ipsos custodes? (Juvenal)

From larrysheldon at cox.net  Mon Dec 28 01:04:16 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sun, 27 Dec 2015 19:04:16 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <162443.1451204366@turing-police.cc.vt.edu>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <162443.1451204366@turing-police.cc.vt.edu>
Message-ID: <56808A90.7070001@cox.net>

On 12/27/2015 02:19, Valdis.Kletnieks at vt.edu wrote:
> On Sun, 27 Dec 2015 08:37:25 +0100, Mikael Abrahamsson said:
>> If someone like Consumer Reports or similar agency started testing and
>> rating devices on these things like long-time support, automatic updates,
>> software quality etc, and not just testing wifi speed as a factor of
>> distance, we might get somewhere.
>
> As finally we come full circle to the original question "who, if anybody,
> has a list of which things are crap and which aren't" :)

Indeed.  Interesting how often that has happened here over the years.

Sometimes it seems more like one of those "counseling" cartoons with 
everybody sitting in a circle learning new words for their problem 
description.


-- 
sed quis custodiet ipsos custodes? (Juvenal)

From owen at delong.com  Mon Dec 28 01:08:17 2015
From: owen at delong.com (Owen DeLong)
Date: Sun, 27 Dec 2015 17:08:17 -0800
Subject: de-peering for security sake
In-Reply-To: <CAPkb-7D23c+07Bk_n4KAQWZ8PWE-ztoQ=cPzHX_w5TqG813adA@mail.gmail.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <D8E60BD7-E428-4663-B629-996CC2DE195B@delong.com>
 <CAPkb-7D23c+07Bk_n4KAQWZ8PWE-ztoQ=cPzHX_w5TqG813adA@mail.gmail.com>
Message-ID: <B19C6F9D-E43C-487C-BF26-209618CE3BE7@delong.com>


> On Dec 27, 2015, at 14:33 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> 
> 
> On 27 December 2015 at 22:08, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> This is a bit of a tangent, really. The discussion was about authentication factor
> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
> private key authentication as two-factor to bolster his claim that it was, in fact
> two-factor, when it clearly isn?t actually two-factor as has been stated previously.
> 
> I wanted to stay out of this, but Owen you are full of shit here. I am pointing out that your homemade definition does not match up with what others think two factor means. PCI DSS might be utter crap, but they are still more than "Owen DeLong and his personal opinion?.

Dude? It?s not just my opinion. Virtually every one else who chimed in on the thread other than you backed my position on this.

> You are utterly confused about the meaning about two factor. You apparently believe the magic words "two factor" is a statement about the security of a system, while it is in fact just a simple property. A property that even an inherently insecure and weak system can have. 

No, as I pointed out, you can have very weak security with two weak factors.

However, the property two-factor means something and it?s not what you apparently think.

> It is not, as you have said, about strengthen the search space of a crypto key (just double the key length if you need that). In fact, many two factor systems do not use crypto keys at all. An example of such a non crypto based system is a credit card with magnetic strip plus pin. The magnetic strip contains just the card number, which can also be read directly from the card and even memorized by the owner.

Actually, the magnetic stripe contains quite a bit more than the card number, but that?s another tangent.

I never said you had to have crypto for two-factor, nor did I say that two factor magically made things stronger.

> We need two factor because if you have just one factor, say the password, the hacker will simply call the user and ask him to tell the password. And the users will happily obligate. Experience shows this. On the other hand, if you give the users a single factor system with a physical token (a key), that gets stolen, misplaced or "borrowed" far too easily. Therefore industry standard is card + pin to enter a building (=two factor). Secure places require three factor (card + pin + biometric).

Card+pin is an example of two factors? You _HAVE_ the card and you _KNOW_ the PIN.

Password-encrypted Key, OTOH, is something you _KNOW_ and something else you _KNOW_. It?s not something you _HAVE_ or something you _ARE_.

There are three generally accepted categories of Factors for authentication?

1.	Something you HAVE
2.	Something you KNOW
3.	Something you ARE

In order to qualify as 2-factor, a system must require something from two of the categories. Two things from the same category do not qualify.

> SSH keys are two factor because people do not in general memorize the key file. Because they do not, you can not gain access to the system with only what you know (=in your mind). Unless the user violated protocols and changed the passphrase to null, you can not gain access just by possession of the key file. That is all that is required to name it two factor. That Owen DeLong believes the system stinks does not change that at all.

Something on disk counts as something you know. A private/public key pair is not something you HAVE because it?s not a physical object and it?s certainly not something you ARE.

It?s clearly in the something you KNOW category for all practical purposes, even if you don?t memorize it into your mind.

Now, a private key in black box where you feed it encrypted stuff to be decrypted or decrypted stuff to be encrypted and you cannot extract the private key, that could be something you HAVE.
But at that point, it?s the black box that is the thing you have, not the key itself. The key in the box and the boxes ability to decrypt/encrypt using that key is merely a mechanism for proving
that you have the correct black box.

> Historically the banks used to depend on a system that is the same as ssh keys: certificate files you have on your computer to access the bank website. That also is a two factor system. The users did not usually memorize the content of the certificates. The system is weak because bad guys used malware to steal the certificate files and install key loggers to also get the other factor, the password. 

Again, real two-factor authentication depends on factors from different categories above. The certificate, like it or not, whether you memorize it or not, is something you KNOW, not something you HAVE.

To qualify as something you HAVE, it has to be a unique physical token with some degree of difficulty in duplication. Some physical tokens are easier to duplicate than others. Examples include keys for pin-tumbler locks.
Even those come in varying degrees of difficulty (3, 5, or 7 pins, straight or spool pins, angled pin alignments, etc.)

> In my country (Denmark) they decided hardware keys are still too expensive, so they developed a two factor system based on paper keys. You will get a piece of paper with a few hundred random numbers. When you log in, you are asked to type one of the numbers in to prove that you are in possession of the key paper. The codes are just 6 digits and infinite weak if you believe them to be part of any crypto scheme. This system has also been broken because now bad guys ask the users to take pictures of the key paper to prove something, and the users happily do just that. Banks are still happy though, because the loss is less than the cost to ship hardware keys to everyone.

Why not just use Google Authenticator (free App) with a unique series on people?s smartphones? I?m pretty sure smartphones are quite common in DK by now.

> Only strong two factor systems are really resistant to the users defeating the system by doing stupid things. That does not mean that only strong two factor systems are two factor. That would be silly - Owen what would you then name weak and broken two factor systems? It is a property - nothing more.

Correct. However, calling a system which depends on two ?factors? from the same factor category doesn?t meet the requirements of a two factor system.

Password protected SSH key is all in the something you KNOW category. Especially when you consider that you aren?t presenting the password and the key to the authenticator, you are using the password to unlock the key that is presented to the authenticator.

(yes, I realize the key isn?t actually presented, it?s done differently involving using the key to encrypt a hash which can then be verified as correctly encrypted by decrypting with the public key, but that?s a technicality that isn?t really relevant here).

Owen


From eyeronic.design at gmail.com  Mon Dec 28 01:19:42 2015
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sun, 27 Dec 2015 17:19:42 -0800
Subject: de-peering for security sake
In-Reply-To: <B19C6F9D-E43C-487C-BF26-209618CE3BE7@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
 <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
 <CD736F56-18F5-4466-A393-51098BFFA4D2@delong.com>
 <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
 <2BFCFFB2-9D23-4851-9C5D-F8C66C8D193C@delong.com>
 <CAPkb-7CJ1K-=7k1qM+HEujPP0=qcSY1EPQiKU5SUOQzKGDRLug@mail.gmail.com>
 <204103.1451242760@turing-police.cc.vt.edu>
 <CAL9jLaZR57Nv4jCiY=8jxfGhn-yx=aVLeinznpGJdDmtjr_Zkw@mail.gmail.com>
 <D8E60BD7-E428-4663-B629-996CC2DE195B@delong.com>
 <CAPkb-7D23c+07Bk_n4KAQWZ8PWE-ztoQ=cPzHX_w5TqG813adA@mail.gmail.com>
 <B19C6F9D-E43C-487C-BF26-209618CE3BE7@delong.com>
Message-ID: <CAN3um4yyZDqD0ztnbGtWzhWO0hjJ4K-M06c4utOwpxvakA0iYA@mail.gmail.com>

Also think of it from the perspective of the authenticating host.

That SSH connection relies *only* on the key for authentication.  It
requires nothing else.  How you protect that key is irrelevant.  All
that matters is that the host is accepting a single form of
authentication.  It's clearly single-factor.

You can call pseudo-multi-factor if you want.  It's certainly better
than a shitty password.  But it's not multi-factor by the generally
accepted definition (although I'd place it under 'something you have'
rather than the 'something you know' section).

On Sun, Dec 27, 2015 at 5:08 PM, Owen DeLong <owen at delong.com> wrote:
>
>> On Dec 27, 2015, at 14:33 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>>
>>
>>
>> On 27 December 2015 at 22:08, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> This is a bit of a tangent, really. The discussion was about authentication factor
>> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
>> private key authentication as two-factor to bolster his claim that it was, in fact
>> two-factor, when it clearly isn?t actually two-factor as has been stated previously.
>>
>> I wanted to stay out of this, but Owen you are full of shit here. I am pointing out that your homemade definition does not match up with what others think two factor means. PCI DSS might be utter crap, but they are still more than "Owen DeLong and his personal opinion?.
>
> Dude? It?s not just my opinion. Virtually every one else who chimed in on the thread other than you backed my position on this.
>
>> You are utterly confused about the meaning about two factor. You apparently believe the magic words "two factor" is a statement about the security of a system, while it is in fact just a simple property. A property that even an inherently insecure and weak system can have.
>
> No, as I pointed out, you can have very weak security with two weak factors.
>
> However, the property two-factor means something and it?s not what you apparently think.
>
>> It is not, as you have said, about strengthen the search space of a crypto key (just double the key length if you need that). In fact, many two factor systems do not use crypto keys at all. An example of such a non crypto based system is a credit card with magnetic strip plus pin. The magnetic strip contains just the card number, which can also be read directly from the card and even memorized by the owner.
>
> Actually, the magnetic stripe contains quite a bit more than the card number, but that?s another tangent.
>
> I never said you had to have crypto for two-factor, nor did I say that two factor magically made things stronger.
>
>> We need two factor because if you have just one factor, say the password, the hacker will simply call the user and ask him to tell the password. And the users will happily obligate. Experience shows this. On the other hand, if you give the users a single factor system with a physical token (a key), that gets stolen, misplaced or "borrowed" far too easily. Therefore industry standard is card + pin to enter a building (=two factor). Secure places require three factor (card + pin + biometric).
>
> Card+pin is an example of two factors? You _HAVE_ the card and you _KNOW_ the PIN.
>
> Password-encrypted Key, OTOH, is something you _KNOW_ and something else you _KNOW_. It?s not something you _HAVE_ or something you _ARE_.
>
> There are three generally accepted categories of Factors for authentication?
>
> 1.      Something you HAVE
> 2.      Something you KNOW
> 3.      Something you ARE
>
> In order to qualify as 2-factor, a system must require something from two of the categories. Two things from the same category do not qualify.
>
>> SSH keys are two factor because people do not in general memorize the key file. Because they do not, you can not gain access to the system with only what you know (=in your mind). Unless the user violated protocols and changed the passphrase to null, you can not gain access just by possession of the key file. That is all that is required to name it two factor. That Owen DeLong believes the system stinks does not change that at all.
>
> Something on disk counts as something you know. A private/public key pair is not something you HAVE because it?s not a physical object and it?s certainly not something you ARE.
>
> It?s clearly in the something you KNOW category for all practical purposes, even if you don?t memorize it into your mind.
>
> Now, a private key in black box where you feed it encrypted stuff to be decrypted or decrypted stuff to be encrypted and you cannot extract the private key, that could be something you HAVE.
> But at that point, it?s the black box that is the thing you have, not the key itself. The key in the box and the boxes ability to decrypt/encrypt using that key is merely a mechanism for proving
> that you have the correct black box.
>
>> Historically the banks used to depend on a system that is the same as ssh keys: certificate files you have on your computer to access the bank website. That also is a two factor system. The users did not usually memorize the content of the certificates. The system is weak because bad guys used malware to steal the certificate files and install key loggers to also get the other factor, the password.
>
> Again, real two-factor authentication depends on factors from different categories above. The certificate, like it or not, whether you memorize it or not, is something you KNOW, not something you HAVE.
>
> To qualify as something you HAVE, it has to be a unique physical token with some degree of difficulty in duplication. Some physical tokens are easier to duplicate than others. Examples include keys for pin-tumbler locks.
> Even those come in varying degrees of difficulty (3, 5, or 7 pins, straight or spool pins, angled pin alignments, etc.)
>
>> In my country (Denmark) they decided hardware keys are still too expensive, so they developed a two factor system based on paper keys. You will get a piece of paper with a few hundred random numbers. When you log in, you are asked to type one of the numbers in to prove that you are in possession of the key paper. The codes are just 6 digits and infinite weak if you believe them to be part of any crypto scheme. This system has also been broken because now bad guys ask the users to take pictures of the key paper to prove something, and the users happily do just that. Banks are still happy though, because the loss is less than the cost to ship hardware keys to everyone.
>
> Why not just use Google Authenticator (free App) with a unique series on people?s smartphones? I?m pretty sure smartphones are quite common in DK by now.
>
>> Only strong two factor systems are really resistant to the users defeating the system by doing stupid things. That does not mean that only strong two factor systems are two factor. That would be silly - Owen what would you then name weak and broken two factor systems? It is a property - nothing more.
>
> Correct. However, calling a system which depends on two ?factors? from the same factor category doesn?t meet the requirements of a two factor system.
>
> Password protected SSH key is all in the something you KNOW category. Especially when you consider that you aren?t presenting the password and the key to the authenticator, you are using the password to unlock the key that is presented to the authenticator.
>
> (yes, I realize the key isn?t actually presented, it?s done differently involving using the key to encrypt a hash which can then be verified as correctly encrypted by decrypting with the public key, but that?s a technicality that isn?t really relevant here).
>
> Owen
>



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

From mike-nanog at tiedyenetworks.com  Mon Dec 28 01:56:02 2015
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sun, 27 Dec 2015 17:56:02 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <5680890F.3070807@cox.net>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com> <5680890F.3070807@cox.net>
Message-ID: <568096B2.6000607@tiedyenetworks.com>


On 12/27/15, 4:57 PM, Larry Sheldon wrote:
> On 12/26/2015 23:49, Mike wrote:
>
> [snip]
>
>> Firstly, they are all junk. Every last one of them. Period. Broadband
>> routers are designed to be cheap and to appeal to people who don't know
>> any better, and who respond well (eg: make purchasing decisions) based
>> on the shape of the plastic, the color scheme employed, and number of
>> mysterious blinking lights that convey 'something important is
>> happening'. Further, the price point is $45 - $70 thereabouts, putting
>> some definite constraints on the actual quality of the engineering and
>> components that go into them. I feel that we, the service provider,
>> endure a significantly high and undue burden of cost associated with
>> providing ongoing support to customers as a result of the defects
>> contained therein.
>
> Why don't you offer an acceptable (to you) device at a price 
> acceptable to me as a part of the service.  I'd buy it.
>
>
NO SUCH DEVICE EXISTS, because you can't afford it. If I were to take 
you seriously however - and we're talking about eliminating all excuses 
and simply getting down to it and making a marginally qualified showing 
at expecting uninterrupted service - the entire environment is what has 
to be solved. The device would be cisco or juniper branded, internal 
redundancy / failover features to allow hitless upgrades or module 
failures, have dual (preferably, triple) power supplies, would be 
required to be housed in a locked enclosure with air conditioning and 
online double conversion battery with the addition of an external backup 
generator with its own separate backup fuel supply, which is further 
tested weekly and mantained with inspections and oil changes. The router 
would be under service contract with the manufacturer, would be 
monitoring by my noc, and would receive appropriate software upgrades as 
required, and you would pay for this monthly in addition to your 
internet service. Furthermore, you also would be required to have at 
least two distinct connections to me and make a deposit to provide 
credit in the event you falsely claim 'trouble' where no trouble exists. 
A seperate 'test pc', also in it's own enclosure and normally offlimits 
to you, and connected to said router and backup power and such, would be 
agreed upon as the test fixture that we would monitor TO. It would 
display current network statistics including packet loss and latencies 
to various on and off-net locations, with current time and date logging 
on screen. You would agree that you are to blame each and every time you 
'can't get on', while the test pc clearly shows on it's local screen to 
you otherwise. You would be required to forfeit a portion of your 
deposit each time you called for technical support and were determined 
to be at fault and to blame for your own issue.



From kmedcalf at dessus.com  Mon Dec 28 02:18:20 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 27 Dec 2015 19:18:20 -0700
Subject: Broadband Router Comparisons
In-Reply-To: <5680890F.3070807@cox.net>
Message-ID: <23a4e15e1c74774e9566e3e764a5ba62@mail.dessus.com>


On Sunday, 27 December, 2015 17:58, Larry Sheldon <larrysheldon at cox.net> said:
> On 12/26/2015 23:49, Mike wrote:
> 
> [snip]
> 
> > Firstly, they are all junk. Every last one of them. Period. Broadband
> > routers are designed to be cheap and to appeal to people who don't know
> > any better, and who respond well (eg: make purchasing decisions) based
> > on the shape of the plastic, the color scheme employed, and number of
> > mysterious blinking lights that convey 'something important is
> > happening'. Further, the price point is $45 - $70 thereabouts, putting
> > some definite constraints on the actual quality of the engineering and
> > components that go into them. I feel that we, the service provider,
> > endure a significantly high and undue burden of cost associated with
> > providing ongoing support to customers as a result of the defects
> > contained therein.
 
> Why don't you offer an acceptable (to you) device at a price acceptable
> to me as a part of the service.  I'd buy it.

Cable Companies / Telco's cannot do that.  
If you bought the device you would want control of it.  (PWC do not permit foreign controlled devices on their networks)
This is anti-thetical to their (CableCo/TelCo) business model.

This is why most PWC (People With Clue) have the CableCo/TelCo configure their crap as a pure bridge with all other features disabled and use their own equipment.  The local lan port on the bridge is the Demarc.

If there is "no transport" at the demarc port, the problem lies with the CableCo/TelCo.  If there is, the problem is your own equipment.  

Telling where the problem lies is trivial.





From Valdis.Kletnieks at vt.edu  Mon Dec 28 02:27:59 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 27 Dec 2015 21:27:59 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <568096B2.6000607@tiedyenetworks.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com> <5680890F.3070807@cox.net>
 <568096B2.6000607@tiedyenetworks.com>
Message-ID: <234510.1451269679@turing-police.cc.vt.edu>

On Sun, 27 Dec 2015 17:56:02 -0800, Mike said:

> NO SUCH DEVICE EXISTS, because you can't afford it. If I were to take
> you seriously however - and we're talking about eliminating all excuses
> and simply getting down to it and making a marginally qualified showing
> at expecting uninterrupted service - the entire environment is what has
> to be solved.

OK. Now repeat the process, but specify something that isn't enterprise
quality, but *does* let you do basic diagnostics from the help desk or NOC.
Does it answer ping?  What's the signal quality? Does it need a push of
updated firmware?  What traffic load is it seeing?

That should get you 95% of the way there, at only 0.5% of the cost.
-------------- 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/20151227/3cc45473/attachment.pgp>

From egon at egon.cc  Mon Dec 28 02:38:39 2015
From: egon at egon.cc (James Downs)
Date: Sun, 27 Dec 2015 18:38:39 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <568096B2.6000607@tiedyenetworks.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com> <5680890F.3070807@cox.net>
 <568096B2.6000607@tiedyenetworks.com>
Message-ID: <251631FA-B0D4-4D49-A87D-4A1AB7BCF2B2@egon.cc>


> On Dec 27, 2015, at 17:56, Mike <mike-nanog at tiedyenetworks.com> wrote:

> The device would be cisco or juniper branded, internal redundancy / failover features to allow hitless upgrades or module failures, have dual (preferably, 

After the last week or so, I wouldn?t trust a service provider who insisted on installing juniper at my site.

From egon at egon.cc  Mon Dec 28 02:45:37 2015
From: egon at egon.cc (James Downs)
Date: Sun, 27 Dec 2015 18:45:37 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com> <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
Message-ID: <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>


> On Dec 27, 2015, at 09:43, Hugo Slabbert <hugo at slabnet.com> wrote:

> Hence: https://on.google.com/hub/

The device looks cool, and sounds cool, but what data does google end up with, and what remote management can they do? Their policy pages aren?t exactly clear, and they?ve mishandled personal data a number of times previously.


From josh at kyneticwifi.com  Mon Dec 28 02:58:18 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Sun, 27 Dec 2015 20:58:18 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com>
 <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
 <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>
Message-ID: <CAC6=tfb=SZQYPVzTuAro8N2V_Day+GCeNrxGw55AYeGLF26M0A@mail.gmail.com>

And now that the new bill has passed, they (along with many others) will be
"mishandling" your data often and legally with 3 letter agencies and other
corporations. :(
On Dec 27, 2015 8:48 PM, "James Downs" <egon at egon.cc> wrote:

>
> > On Dec 27, 2015, at 09:43, Hugo Slabbert <hugo at slabnet.com> wrote:
>
> > Hence: https://on.google.com/hub/
>
> The device looks cool, and sounds cool, but what data does google end up
> with, and what remote management can they do? Their policy pages aren?t
> exactly clear, and they?ve mishandled personal data a number of times
> previously.
>
>

From larrysheldon at cox.net  Mon Dec 28 03:32:50 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sun, 27 Dec 2015 21:32:50 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <568096B2.6000607@tiedyenetworks.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com> <5680890F.3070807@cox.net>
 <568096B2.6000607@tiedyenetworks.com>
Message-ID: <5680AD62.30808@cox.net>

On 12/27/2015 19:56, Mike wrote:
>
> On 12/27/15, 4:57 PM, Larry Sheldon wrote:
>> On 12/26/2015 23:49, Mike wrote:
>>
>> [snip]
>>
>>> Firstly, they are all junk. Every last one of them. Period. Broadband
>>> routers are designed to be cheap and to appeal to people who don't know
>>> any better, and who respond well (eg: make purchasing decisions) based
>>> on the shape of the plastic, the color scheme employed, and number of
>>> mysterious blinking lights that convey 'something important is
>>> happening'. Further, the price point is $45 - $70 thereabouts, putting
>>> some definite constraints on the actual quality of the engineering and
>>> components that go into them. I feel that we, the service provider,
>>> endure a significantly high and undue burden of cost associated with
>>> providing ongoing support to customers as a result of the defects
>>> contained therein.
>>
>> Why don't you offer an acceptable (to you) device at a price
>> acceptable to me as a part of the service.  I'd buy it.
>>
>>
> NO SUCH DEVICE EXISTS, because you can't afford it. If I were to take
> you seriously however - and we're talking about eliminating all excuses
> and simply getting down to it and making a marginally qualified showing
> at expecting uninterrupted service - the entire environment is what has
> to be solved. The device would be cisco or juniper branded, internal
> redundancy / failover features to allow hitless upgrades or module
> failures, have dual (preferably, triple) power supplies, would be
> required to be housed in a locked enclosure with air conditioning and
> online double conversion battery with the addition of an external backup
> generator with its own separate backup fuel supply, which is further
> tested weekly and mantained with inspections and oil changes. The router
> would be under service contract with the manufacturer, would be
> monitoring by my noc, and would receive appropriate software upgrades as
> required, and you would pay for this monthly in addition to your
> internet service. Furthermore, you also would be required to have at
> least two distinct connections to me and make a deposit to provide
> credit in the event you falsely claim 'trouble' where no trouble exists.
> A seperate 'test pc', also in it's own enclosure and normally offlimits
> to you, and connected to said router and backup power and such, would be
> agreed upon as the test fixture that we would monitor TO. It would
> display current network statistics including packet loss and latencies
> to various on and off-net locations, with current time and date logging
> on screen. You would agree that you are to blame each and every time you
> 'can't get on', while the test pc clearly shows on it's local screen to
> you otherwise. You would be required to forfeit a portion of your
> deposit each time you called for technical support and were determined
> to be at fault and to blame for your own issue.

I'll accept the challenge and try to be briefer.

If it can't be did at a price I'll accept, then let us stop crying about 
how bad it is.  You don't like it, turn it off.

(For the record, I do not require all of that stuff--if I am "grid off" 
then having a standby power system would be nice to power our CPAPs, but 
commo is going to be down and it might as well be dark and quiet.)

And for the matter of "false" failure reports--there IS a work around 
for you:  From Day ONE, Hour Zero, Minute Zero, Second Zero, supply 
stuff that WORKS the way your sales people said it would.

If you start out peddling crap that does not work, you will establish 
yourself as a peddler of crap and the first place to call.

I used to work for a company that did a pretty good job of doing that so 
when somebody did call they often sounded apologetic and tended to need 
to be convinced that, no this one is ours, but we are on it and we hope 
to be back at  HH:MM.

For people that purchased large quantities of what we sold we provided 
alarm displays or ring downs to tell THEM we broke something.


-- 
sed quis custodiet ipsos custodes? (Juvenal)

From egon at egon.cc  Mon Dec 28 03:40:46 2015
From: egon at egon.cc (James Downs)
Date: Sun, 27 Dec 2015 19:40:46 -0800
Subject: de-peering for security sake 
In-Reply-To: <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
References: <278703070.5666.1451139598778.JavaMail.mhammett@ThunderFuck>
 <567EADA8.2090307@satchell.net> <-1680641458761921693@unknownmsgid>
 <4EEEEFF4-22D0-463A-BD6B-1BF977014B0E@delong.com>
Message-ID: <8CA7A936-3215-4C75-B701-363987EE2424@egon.cc>


> On Dec 26, 2015, at 12:34, Owen DeLong <owen at delong.com> wrote:
> 
> Also, note that the only difference between a good long passphrase and a private key is,
> uh, wait, um, come to think of it, really not much.

Are you equating a long PSK with PKE? They?re quite different.

From kmedcalf at dessus.com  Mon Dec 28 04:00:41 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 27 Dec 2015 21:00:41 -0700
Subject: Broadband Router Comparisons
In-Reply-To: <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>
Message-ID: <e5483bb7be99634598c7462ee93952d0@mail.dessus.com>



On Sunday, 27 December, 2015 19:46, James Downs <egon at egon.cc> said:
> > On Dec 27, 2015, at 09:43, Hugo Slabbert <hugo at slabnet.com> wrote:
 
> > Hence: https://on.google.com/hub/
 
> The device looks cool, and sounds cool, but what data does google end up
> with, and what remote management can they do? Their policy pages aren?t
> exactly clear, and they?ve mishandled personal data a number of times
> previously.

They end up with ALL the data they can capture; they have COMPLETE management control; and, can execute whatever code they want, without your prior approval or choice, on the device at any time they please, including permanent changes in the software and configuration.






From egon at egon.cc  Mon Dec 28 04:04:44 2015
From: egon at egon.cc (James Downs)
Date: Sun, 27 Dec 2015 20:04:44 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <e5483bb7be99634598c7462ee93952d0@mail.dessus.com>
References: <e5483bb7be99634598c7462ee93952d0@mail.dessus.com>
Message-ID: <E25F0126-4AD5-4B49-8190-45B687F34721@egon.cc>


> On Dec 27, 2015, at 20:00, Keith Medcalf <kmedcalf at dessus.com> wrote:

> They end up with ALL the data they can capture; they have COMPLETE management control; and, can execute whatever code they want, without your prior approval or choice, on the device at any time they please, including permanent changes in the software and configuration.

What?s what I assume as well. This makes it, and the nest, and any related devices unwelcome.

From hugo at slabnet.com  Mon Dec 28 04:06:40 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Sun, 27 Dec 2015 20:06:40 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <568026DA.2020900@mtcc.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com>
 <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
 <568026DA.2020900@mtcc.com>
Message-ID: <20151228040640.GA8146@slab-wks-04.int.slabnet.com>

On Sun 2015-Dec-27 09:58:50 -0800, Michael Thomas <mike at mtcc.com> wrote:

>Nice,  but i want my router to have an android environment itself, not 
>just to
>be controlled by my phone (which i want as well, of course).

Sure.  My message was strictly in response to:

>>>This is, I imagine, why Google bought Nest: they want to be that home
>>>central controller. The home router is more ubiquitous though, IMHO.

...and not specifically about:

>>>Which is pretty cool if you need something that is, oh say, a central
>>>controller for your home. Put a headless Android in it, allow 3rd party 
>>>apps, water the lawn with it. Love ensues.

-- 
Hugo

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)

>
>The proximity sensor for app developers would be fun to play with, for 
>example.
>
>Mike
>
>On 12/27/2015 09:43 AM, Hugo Slabbert wrote:
>>
>>---- From: Michael Thomas <mike at mtcc.com> -- Sent: 2015-12-27 - 08:49 ----
>>
>>>
>>>On 12/26/2015 11:37 PM, Mikael Abrahamsson wrote:
>>>>Providing security updates is just a cost, there is no upside, because
>>>>these boxes sit in a closet, unloved until they stop working, and
>>>>they're thrown out and replaced by a new unloved box that goes into
>>>>the closet until it stops working again.
>>>IMO, this is the real problem, but there's a real opportunity. Routers
>>>are for most
>>>people the only things which:
>>>
>>>1) are always on
>>>2) have internet connectivity
>>>
>>>Which is pretty cool if you need something that is, oh say, a central
>>>controller
>>>for your home. Put a headless Android in it, allow 3rd party apps, water the
>>>lawn with it. Love ensues.
>>>
>>>This is, I imagine, why Google bought Nest: they want to be that home
>>>central
>>>controller. The home router is more ubiquitous though, IMHO.
>>Hence: https://on.google.com/hub/
>>
>>>Mike
>>>
>>--
>>Hugo
>>hugo at slabnet.com: email, xmpp/jabber
>>also on Signal
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151227/6de828d2/attachment.pgp>

From hugo at slabnet.com  Mon Dec 28 04:10:53 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Sun, 27 Dec 2015 20:10:53 -0800
Subject: Broadband Router Comparisons
In-Reply-To: <CAC6=tfb=SZQYPVzTuAro8N2V_Day+GCeNrxGw55AYeGLF26M0A@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com>
 <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
 <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>
 <CAC6=tfb=SZQYPVzTuAro8N2V_Day+GCeNrxGw55AYeGLF26M0A@mail.gmail.com>
Message-ID: <20151228041053.GB8146@slab-wks-04.int.slabnet.com>

On Sun 2015-Dec-27 20:58:18 -0600, Josh Reynolds <josh at kyneticwifi.com> wrote:

>And now that the new bill has passed, they (along with many others) will be
>"mishandling" your data often and legally with 3 letter agencies and other
>corporations. :(
>On Dec 27, 2015 8:48 PM, "James Downs" <egon at egon.cc> wrote:
>
>>
>> > On Dec 27, 2015, at 09:43, Hugo Slabbert <hugo at slabnet.com> wrote:
>>
>> > Hence: https://on.google.com/hub/
>>
>> The device looks cool, and sounds cool, but what data does google end up
>> with, and what remote management can they do? Their policy pages aren?t
>> exactly clear, and they?ve mishandled personal data a number of times
>> previously.
>>

Probably wise to be keep the tinfoil hat within arm's reach, I think.  My 
ref was strictly "yep, they appear to be making a play at the home 
controller market via a broadband router trojan horse" and not in any way 
an endorsement or comment on the merits of the device.

-- 
Hugo

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151227/b3f7e80c/attachment.pgp>

From josh at kyneticwifi.com  Mon Dec 28 04:12:25 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Sun, 27 Dec 2015 22:12:25 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <20151228041053.GB8146@slab-wks-04.int.slabnet.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com>
 <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
 <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>
 <CAC6=tfb=SZQYPVzTuAro8N2V_Day+GCeNrxGw55AYeGLF26M0A@mail.gmail.com>
 <20151228041053.GB8146@slab-wks-04.int.slabnet.com>
Message-ID: <CAC6=tfb6K23FQX+vA-_-VA+Lm8QnFmpD9i9J1WP0TJPnc2YzDA@mail.gmail.com>

Based over what has been leaked, announced, or passed as pork barrel since
9/11, its probably time a tin foil hat factory was created to speed up the
issuance of said hats.
On Dec 27, 2015 10:10 PM, "Hugo Slabbert" <hugo at slabnet.com> wrote:

> On Sun 2015-Dec-27 20:58:18 -0600, Josh Reynolds <josh at kyneticwifi.com>
> wrote:
>
> And now that the new bill has passed, they (along with many others) will be
>> "mishandling" your data often and legally with 3 letter agencies and other
>> corporations. :(
>> On Dec 27, 2015 8:48 PM, "James Downs" <egon at egon.cc> wrote:
>>
>>
>>> > On Dec 27, 2015, at 09:43, Hugo Slabbert <hugo at slabnet.com> wrote:
>>>
>>> > Hence: https://on.google.com/hub/
>>>
>>> The device looks cool, and sounds cool, but what data does google end up
>>> with, and what remote management can they do? Their policy pages aren?t
>>> exactly clear, and they?ve mishandled personal data a number of times
>>> previously.
>>>
>>>
> Probably wise to be keep the tinfoil hat within arm's reach, I think.  My
> ref was strictly "yep, they appear to be making a play at the home
> controller market via a broadband router trojan horse" and not in any way
> an endorsement or comment on the merits of the device.
>
> --
> Hugo
>
> hugo at slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
>
> (also on textsecure & redphone)
>

From Valdis.Kletnieks at vt.edu  Mon Dec 28 04:40:50 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 27 Dec 2015 23:40:50 -0500
Subject: Broadband Router Comparisons
In-Reply-To: <CAC6=tfb6K23FQX+vA-_-VA+Lm8QnFmpD9i9J1WP0TJPnc2YzDA@mail.gmail.com>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com>
 <alpine.DEB.2.02.1512270830440.29581@uplift.swm.pp.se>
 <56801687.2020401@mtcc.com> <2411cc39.kqhkiG.151e4899b4c@slabnet.com>
 <8D913C07-CD24-49B0-9155-5DD1D7C86BFA@egon.cc>
 <CAC6=tfb=SZQYPVzTuAro8N2V_Day+GCeNrxGw55AYeGLF26M0A@mail.gmail.com>
 <20151228041053.GB8146@slab-wks-04.int.slabnet.com>
 <CAC6=tfb6K23FQX+vA-_-VA+Lm8QnFmpD9i9J1WP0TJPnc2YzDA@mail.gmail.com>
Message-ID: <4160.1451277650@turing-police.cc.vt.edu>

On Sun, 27 Dec 2015 22:12:25 -0600, Josh Reynolds said:
> Based over what has been leaked, announced, or passed as pork barrel since
> 9/11, its probably time a tin foil hat factory was created to speed up the
> issuance of said hats.

https://www.kickstarter.com/projects/shieldapparel/shield-the-world-s-first-signal-proof-headwear
-------------- 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/20151227/fb96ecbe/attachment.pgp>

From johnl at iecc.com  Mon Dec 28 04:59:05 2015
From: johnl at iecc.com (John Levine)
Date: 28 Dec 2015 04:59:05 -0000
Subject: Broadband Router Comparisons
In-Reply-To: <4160.1451277650@turing-police.cc.vt.edu>
Message-ID: <20151228045905.48438.qmail@ary.lan>

>> Based over what has been leaked, announced, or passed as pork barrel since
>> 9/11, its probably time a tin foil hat factory was created to speed up the
>> issuance of said hats.
>
>https://www.kickstarter.com/projects/shieldapparel/shield-the-world-s-first-signal-proof-headwear

No need to wait, order now:

https://www.etsy.com/listing/55473505/knit-tinfoil-hat-made-to-order

R's,
John

From surfer at mauigateway.com  Mon Dec 28 05:51:45 2015
From: surfer at mauigateway.com (Scott Weeks)
Date: Sun, 27 Dec 2015 21:51:45 -0800
Subject: Broadband Router Comparisons
Message-ID: <20151227215145.974A5274@m0087791.ppops.net>


---------------
>https://www.kickstarter.com/projects/shieldapparel/shield-the-world-s-first-signal-proof-headwear
https://www.etsy.com/listing/55473505/knit-tinfoil-hat-made-to-order
--------------------------


There is just no end to stoopid.  There's apparently an 
infinite quantity available.

scott

From ying.zhang13 at hpe.com  Mon Dec 28 08:25:02 2015
From: ying.zhang13 at hpe.com (Zhang, Ying)
Date: Mon, 28 Dec 2015 08:25:02 +0000
Subject: Survey on Middlebox modeling and troubleshooting
Message-ID: <9FB7CAEB5595194395CF60B36B98FEED1DAC5827@G9W0721.americas.hpqcorp.net>

Dear All,

We are researchers in HP Labs and Duke university. We are currently working on a project related to Middlebox modeling and troubleshooting.
We are currently conducting a survey and gathering feedback from operators.
Can you help us by providing some answers? Please feel free to email us if you have any additional suggestions.
https://www.surveymonkey.com/r/5SFP6G8

Thanks!
-Ying


From crussell at kanren.net  Mon Dec 28 15:36:27 2015
From: crussell at kanren.net (Casey Russell)
Date: Mon, 28 Dec 2015 09:36:27 -0600
Subject: Broadband Router Comparisons
In-Reply-To: <251631FA-B0D4-4D49-A87D-4A1AB7BCF2B2@egon.cc>
References: <7EA71342-A03A-4E50-AD13-4C84664032E4@hathcock.org>
 <567F7BF7.9070106@tiedyenetworks.com> <5680890F.3070807@cox.net>
 <568096B2.6000607@tiedyenetworks.com>
 <251631FA-B0D4-4D49-A87D-4A1AB7BCF2B2@egon.cc>
Message-ID: <CAGLsBOg1eK_by-5xwxWVUOgALPqyXdcGvD4tJs4=EF68wO+43Q@mail.gmail.com>

>
> After the last week or so, I wouldn?t trust a service provider who
> insisted on installing juniper at my site.


Gotta be careful with that attitude.  You can't have Cisco either if you
really mean that.  (or most any other enterprise provider really).


http://arstechnica.com/security/2015/09/malicious-cisco-router-backdoor-found-on-79-more-devices-25-in-the-us/
http://www.infoworld.com/article/2608141/internet-privacy/snowden--the-nsa-planted-backdoors-in-cisco-products.html



Casey Russell
Network Engineer
Kansas Research and Education Network

2029 Becker Drive, Suite 282

Lawrence, KS  66047
(785)856-9820  ext 9809
crussell at kanren.net

From silvertip257 at gmail.com  Mon Dec 28 18:28:02 2015
From: silvertip257 at gmail.com (Mike - st257)
Date: Mon, 28 Dec 2015 13:28:02 -0500
Subject: announcement of freerouter
Message-ID: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>

> Date: Thu, 24 Dec 2015 22:23:24 -0600
> From: Josh Reynolds <josh at kyneticwifi.com>
> To: mate csaba <matecs at niif.hu>
> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
> Subject: Re: announcement of freerouter
> Message-ID:
>         <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
> rsS8T6YQ7Fsg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> RouterOS is an existing product by MikroTik.
>

Mate Csaba's message had nothing to do with MikroTik RouterOS (from Latvia,
which doesn't include IS-IS support). And Mikrotik RouterOS isn't free. ;-)

Why was this response about RouterOS?  (Am I missing something?)

The posted presentations/slides touch upon the feature set of FreeRtr
(which is similiar to MT RouterOS, but which many production-ready Network
OSes have).
http://freerouter.nop.hu/present.html
And CLI output examples:
http://freerouter.nop.hu/present.html


> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>
> > hi,
> > pleased to announce a stable release of freerouter.
>

Neat.


> > this is a routing daemon that does packet handling itself
> > so it can do bridging, routing ipv4/ipv6 unicast/multicast,
> > mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
> > speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
> > babel...
> > does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
> > nvgre...
> > have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
> > tacacs, radius, ssh...
> > it can start external images which could be connected, so various lab
> > topolgies can be easily created.
> > our nren uses if as primary fullbgp rr for more than a year for about
> > hundred routers.
> > here is the homepage: http://freerouter.nop.hu/
> > feel free to try it out and send suggestions/bug reports...:)
> > thanks in advance,
> > csaba mate
> > niif/hungarnet
>


-- 
---~~.~~---
Mike
//  SilverTip257  //

From dougb at dougbarton.us  Tue Dec 29 03:51:12 2015
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 28 Dec 2015 19:51:12 -0800
Subject: NSA/GCHQ Exploits Against Juniper Networking Equipment
Message-ID: <56820330.9060404@dougbarton.us>

The Intercept just published a 2011 GCHQ document outlining their 
exploit capabilities against Juniper networking equipment, including 
routers and NetScreen firewalls as part of this article.

https://www.schneier.com/blog/archives/2015/12/nsagchq_exploit.html

From laszlo at heliacal.net  Mon Dec 28 20:29:20 2015
From: laszlo at heliacal.net (Laszlo Hanyecz)
Date: Mon, 28 Dec 2015 20:29:20 +0000
Subject: announcement of freerouter
In-Reply-To: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
Message-ID: <56819BA0.5060403@heliacal.net>

Mike,

Csaba's front page previously described the software as being a 
'routerOS', like in the very first sentence on the page.  I'm assuming 
that the person who complained about that didn't read past the first 
sentence and just wanted to troll.  It's obvious to me that decades of 
work have gone into this free router software, and the term router OS 
was just being used to describe what the software does - an OS for a 
router.

It looks to me like the author has a deep understanding of networking to 
be able to implement all this from scratch and I think we can learn a 
lot from reading this code.  He's also giving it away for free, which is 
hard to argue with.

-Laszlo

On 2015-12-28 18:28, Mike - st257 wrote:
>> Date: Thu, 24 Dec 2015 22:23:24 -0600
>> From: Josh Reynolds <josh at kyneticwifi.com>
>> To: mate csaba <matecs at niif.hu>
>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
>> Subject: Re: announcement of freerouter
>> Message-ID:
>>          <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
>> rsS8T6YQ7Fsg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> RouterOS is an existing product by MikroTik.
>>
> Mate Csaba's message had nothing to do with MikroTik RouterOS (from Latvia,
> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free. ;-)
>
> Why was this response about RouterOS?  (Am I missing something?)
>
> The posted presentations/slides touch upon the feature set of FreeRtr
> (which is similiar to MT RouterOS, but which many production-ready Network
> OSes have).
> http://freerouter.nop.hu/present.html
> And CLI output examples:
> http://freerouter.nop.hu/present.html
>
>
>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>>
>>> hi,
>>> pleased to announce a stable release of freerouter.
> Neat.
>
>
>>> this is a routing daemon that does packet handling itself
>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
>>> babel...
>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
>>> nvgre...
>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
>>> tacacs, radius, ssh...
>>> it can start external images which could be connected, so various lab
>>> topolgies can be easily created.
>>> our nren uses if as primary fullbgp rr for more than a year for about
>>> hundred routers.
>>> here is the homepage: http://freerouter.nop.hu/
>>> feel free to try it out and send suggestions/bug reports...:)
>>> thanks in advance,
>>> csaba mate
>>> niif/hungarnet
>


From morrowc.lists at gmail.com  Mon Dec 28 20:33:04 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 28 Dec 2015 15:33:04 -0500
Subject: NSA/GCHQ Exploits Against Juniper Networking Equipment
In-Reply-To: <56820330.9060404@dougbarton.us>
References: <56820330.9060404@dougbarton.us>
Message-ID: <CAL9jLaYeHF9wKuUwUQjviR97Q-iPaJPAxCdq8ZUh-Ps3K1Wu4g@mail.gmail.com>

question: why the m320?

On Mon, Dec 28, 2015 at 10:51 PM, Doug Barton <dougb at dougbarton.us> wrote:
> The Intercept just published a 2011 GCHQ document outlining their exploit
> capabilities against Juniper networking equipment, including routers and
> NetScreen firewalls as part of this article.
>
> https://www.schneier.com/blog/archives/2015/12/nsagchq_exploit.html

From silvertip257 at gmail.com  Tue Dec 29 01:01:01 2015
From: silvertip257 at gmail.com (Mike - st257)
Date: Mon, 28 Dec 2015 20:01:01 -0500
Subject: announcement of freerouter
In-Reply-To: <56819BA0.5060403@heliacal.net>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
Message-ID: <CA+W-zopjaHSXZeGaR18n2quP83VaXincAB8NOCSVWOhq+w+LNA@mail.gmail.com>

On Mon, Dec 28, 2015 at 3:29 PM, Laszlo Hanyecz <laszlo at heliacal.net> wrote:

> Mike,
>
> Csaba's front page previously described the software as being a
> 'routerOS', like in the very first sentence on the page.  I'm assuming that
> the person who complained about that didn't read past the first sentence
> and just wanted to troll.  It's obvious to me that decades of work have
> gone into this free router software, and the term router OS was just being
> used to describe what the software does - an OS for a router.
>

Thanks for the clarification.
I did miss that particular sentence with 'router OS'.

But perusal of two or three of freerouter's pages showed it to be more
Cisco-like (much like Quagga's CLI syntax mimics Cisco IOS command syntax)
than Mikrotik RouterOS.

While freerouter != Mikrotik RouterOS,
I can't disagree that Mikrotik RouterOS does deliver quite the bang for the
buck.
:-)


>
> It looks to me like the author has a deep understanding of networking to
> be able to implement all this from scratch and I think we can learn a lot
> from reading this code.  He's also giving it away for free, which is hard
> to argue with.


Yes. Another alternative and a free one at that.


>
>
> -Laszlo
>
>
> On 2015-12-28 18:28, Mike - st257 wrote:
>
>> Date: Thu, 24 Dec 2015 22:23:24 -0600
>>> From: Josh Reynolds <josh at kyneticwifi.com>
>>> To: mate csaba <matecs at niif.hu>
>>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
>>> Subject: Re: announcement of freerouter
>>> Message-ID:
>>>          <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
>>> rsS8T6YQ7Fsg at mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> RouterOS is an existing product by MikroTik.
>>>
>>> Mate Csaba's message had nothing to do with MikroTik RouterOS (from
>> Latvia,
>> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free.
>> ;-)
>>
>> Why was this response about RouterOS?  (Am I missing something?)
>>
>> The posted presentations/slides touch upon the feature set of FreeRtr
>> (which is similiar to MT RouterOS, but which many production-ready Network
>> OSes have).
>> http://freerouter.nop.hu/present.html
>> And CLI output examples:
>> http://freerouter.nop.hu/present.html
>>
>>
>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>>>
>>> hi,
>>>> pleased to announce a stable release of freerouter.
>>>>
>>> Neat.
>>
>>
>> this is a routing daemon that does packet handling itself
>>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
>>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
>>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
>>>> babel...
>>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
>>>> nvgre...
>>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
>>>> tacacs, radius, ssh...
>>>> it can start external images which could be connected, so various lab
>>>> topolgies can be easily created.
>>>> our nren uses if as primary fullbgp rr for more than a year for about
>>>> hundred routers.
>>>> here is the homepage: http://freerouter.nop.hu/
>>>> feel free to try it out and send suggestions/bug reports...:)
>>>> thanks in advance,
>>>> csaba mate
>>>> niif/hungarnet
>>>>
>>>
>>
>


-- 
---~~.~~---
Mike
//  SilverTip257  //

From josh at kyneticwifi.com  Tue Dec 29 09:08:30 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Tue, 29 Dec 2015 03:08:30 -0600
Subject: announcement of freerouter
In-Reply-To: <56819BA0.5060403@heliacal.net>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
Message-ID: <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>

It wasn't about trolling, it was about legitimate prior art and reasonably
so. Also, there's potentially a confusing association between the two.

I'm glad the terminology was removed.
On Dec 28, 2015 2:31 PM, "Laszlo Hanyecz" <laszlo at heliacal.net> wrote:

> Mike,
>
> Csaba's front page previously described the software as being a
> 'routerOS', like in the very first sentence on the page.  I'm assuming that
> the person who complained about that didn't read past the first sentence
> and just wanted to troll.  It's obvious to me that decades of work have
> gone into this free router software, and the term router OS was just being
> used to describe what the software does - an OS for a router.
>
> It looks to me like the author has a deep understanding of networking to
> be able to implement all this from scratch and I think we can learn a lot
> from reading this code.  He's also giving it away for free, which is hard
> to argue with.
>
> -Laszlo
>
> On 2015-12-28 18:28, Mike - st257 wrote:
>
>> Date: Thu, 24 Dec 2015 22:23:24 -0600
>>> From: Josh Reynolds <josh at kyneticwifi.com>
>>> To: mate csaba <matecs at niif.hu>
>>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
>>> Subject: Re: announcement of freerouter
>>> Message-ID:
>>>          <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
>>> rsS8T6YQ7Fsg at mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> RouterOS is an existing product by MikroTik.
>>>
>>> Mate Csaba's message had nothing to do with MikroTik RouterOS (from
>> Latvia,
>> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free.
>> ;-)
>>
>> Why was this response about RouterOS?  (Am I missing something?)
>>
>> The posted presentations/slides touch upon the feature set of FreeRtr
>> (which is similiar to MT RouterOS, but which many production-ready Network
>> OSes have).
>> http://freerouter.nop.hu/present.html
>> And CLI output examples:
>> http://freerouter.nop.hu/present.html
>>
>>
>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>>>
>>> hi,
>>>> pleased to announce a stable release of freerouter.
>>>>
>>> Neat.
>>
>>
>> this is a routing daemon that does packet handling itself
>>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
>>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
>>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
>>>> babel...
>>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
>>>> nvgre...
>>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
>>>> tacacs, radius, ssh...
>>>> it can start external images which could be connected, so various lab
>>>> topolgies can be easily created.
>>>> our nren uses if as primary fullbgp rr for more than a year for about
>>>> hundred routers.
>>>> here is the homepage: http://freerouter.nop.hu/
>>>> feel free to try it out and send suggestions/bug reports...:)
>>>> thanks in advance,
>>>> csaba mate
>>>> niif/hungarnet
>>>>
>>>
>>
>

From rs-lists at seastrom.com  Tue Dec 29 12:51:35 2015
From: rs-lists at seastrom.com (Rob Seastrom)
Date: Tue, 29 Dec 2015 07:51:35 -0500
Subject: announcement of freerouter
In-Reply-To: <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
Message-ID: <8EEBB4A7-407A-4FA5-B453-2203388AD120@seastrom.com>


> On Dec 29, 2015, at 4:08 AM, Josh Reynolds <josh at kyneticwifi.com> wrote:
> 
> It wasn't about trolling, it was about legitimate prior art and reasonably
> so. Also, there's potentially a confusing association between the two.
> 
> I'm glad the terminology was removed.


Since it's an operating system for routing IP, maybe they could call it "IP operating system", styled Ios, to prevent confusion with IOS and iOS.

Lawyers gotta eat too...

-r



From nanog at ics-il.net  Tue Dec 29 14:23:00 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 29 Dec 2015 08:23:00 -0600 (CST)
Subject: announcement of freerouter
In-Reply-To: <56819BA0.5060403@heliacal.net>
Message-ID: <1876421211.711.1451399060782.JavaMail.mhammett@ThunderFuck>

At the time of the announcement, this is what the page looked like (GIF attachment attempted). 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Laszlo Hanyecz" <laszlo at heliacal.net> 
To: "Mike - st257" <silvertip257 at gmail.com>, nanog at nanog.org 
Sent: Monday, December 28, 2015 2:29:20 PM 
Subject: Re: announcement of freerouter 

Mike, 

Csaba's front page previously described the software as being a 
'routerOS', like in the very first sentence on the page. I'm assuming 
that the person who complained about that didn't read past the first 
sentence and just wanted to troll. It's obvious to me that decades of 
work have gone into this free router software, and the term router OS 
was just being used to describe what the software does - an OS for a 
router. 

It looks to me like the author has a deep understanding of networking to 
be able to implement all this from scratch and I think we can learn a 
lot from reading this code. He's also giving it away for free, which is 
hard to argue with. 

-Laszlo 

On 2015-12-28 18:28, Mike - st257 wrote: 
>> Date: Thu, 24 Dec 2015 22:23:24 -0600 
>> From: Josh Reynolds <josh at kyneticwifi.com> 
>> To: mate csaba <matecs at niif.hu> 
>> Cc: cs at nop.hu, NANOG <nanog at nanog.org> 
>> Subject: Re: announcement of freerouter 
>> Message-ID: 
>> <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB= 
>> rsS8T6YQ7Fsg at mail.gmail.com> 
>> Content-Type: text/plain; charset=UTF-8 
>> 
>> RouterOS is an existing product by MikroTik. 
>> 
> Mate Csaba's message had nothing to do with MikroTik RouterOS (from Latvia, 
> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free. ;-) 
> 
> Why was this response about RouterOS? (Am I missing something?) 
> 
> The posted presentations/slides touch upon the feature set of FreeRtr 
> (which is similiar to MT RouterOS, but which many production-ready Network 
> OSes have). 
> http://freerouter.nop.hu/present.html 
> And CLI output examples: 
> http://freerouter.nop.hu/present.html 
> 
> 
>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote: 
>> 
>>> hi, 
>>> pleased to announce a stable release of freerouter. 
> Neat. 
> 
> 
>>> this is a routing daemon that does packet handling itself 
>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast, 
>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on... 
>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp, 
>>> babel... 
>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan, 
>>> nvgre... 
>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet, 
>>> tacacs, radius, ssh... 
>>> it can start external images which could be connected, so various lab 
>>> topolgies can be easily created. 
>>> our nren uses if as primary fullbgp rr for more than a year for about 
>>> hundred routers. 
>>> here is the homepage: http://freerouter.nop.hu/ 
>>> feel free to try it out and send suggestions/bug reports...:) 
>>> thanks in advance, 
>>> csaba mate 
>>> niif/hungarnet 
> 



From jhellenthal at dataix.net  Tue Dec 29 16:16:32 2015
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Tue, 29 Dec 2015 10:16:32 -0600
Subject: 1and1 Clueful Email / DNS Admin Requested
Message-ID: <658A0166-C987-407E-B7A4-CBCFDCEA199F@dataix.net>

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

Would a 1and1 clueful DNS and Email Expert contact me off list. Tech support cannot seem to provide a customer of ours with appropriate help.

Thanks

- -- 
 Jason Hellenthal
 JJH48-ARIN




-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWgrHgAAoJEDLu+wRc4KcIC4sH/1Uo02IRtY5C1WOqZTMzYJcO
Y4W1p2og4AUmf9M4QaENfdR2zvQkorkvJFZ9yg15RGH5icg8adpxs98MbI5QeL/R
8Ylsre3MqvTbWPSqRzWdud2ClYjtlclCXEFNn/gYZP1LXaFu2EUixcoMDdQx4ogY
0FdV3cOT6K1/3czywKb3oWa6NUYSWELsErheq559jmxTNZPpIogJBWuCNR57OH2f
7XigD8kdXgVjIc3sY4ttj+KEZL7BQgw25KFLGmdrCvvb1HZQg3mbGQEq1vo+Tn0S
Cbm5+wYKsc+v5liRwgmA8eapGQb903V/Y/dAGMD9X6Z45hVhXMJG21mYG/L55FY=
=H+9V
-----END PGP SIGNATURE-----

From owen at delong.com  Tue Dec 29 18:29:06 2015
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 Dec 2015 10:29:06 -0800
Subject: announcement of freerouter
In-Reply-To: <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
Message-ID: <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>

In fairness, when I first looked at the page, I was confused too.

It said it ran as a ?Router OS Process? which made me think that it was
somehow a virtual router that ran inside the Mikrotik operating system
known as Router SO and I was scratching my head going:

A: How can that possibly work?
B: Why would you want it to?

Now, realizing that the guy probably made an honest mistake without realizing
he was using someone else?s trade name in the process, it makes much more sense.

Confusing, but in the end, much ado about nothing[1] all around.

Owen

[1] No intent here to misuse any intellectual property of any Bard or other person.


> On Dec 29, 2015, at 01:08 , Josh Reynolds <josh at kyneticwifi.com> wrote:
> 
> It wasn't about trolling, it was about legitimate prior art and reasonably
> so. Also, there's potentially a confusing association between the two.
> 
> I'm glad the terminology was removed.
> On Dec 28, 2015 2:31 PM, "Laszlo Hanyecz" <laszlo at heliacal.net> wrote:
> 
>> Mike,
>> 
>> Csaba's front page previously described the software as being a
>> 'routerOS', like in the very first sentence on the page.  I'm assuming that
>> the person who complained about that didn't read past the first sentence
>> and just wanted to troll.  It's obvious to me that decades of work have
>> gone into this free router software, and the term router OS was just being
>> used to describe what the software does - an OS for a router.
>> 
>> It looks to me like the author has a deep understanding of networking to
>> be able to implement all this from scratch and I think we can learn a lot
>> from reading this code.  He's also giving it away for free, which is hard
>> to argue with.
>> 
>> -Laszlo
>> 
>> On 2015-12-28 18:28, Mike - st257 wrote:
>> 
>>> Date: Thu, 24 Dec 2015 22:23:24 -0600
>>>> From: Josh Reynolds <josh at kyneticwifi.com>
>>>> To: mate csaba <matecs at niif.hu>
>>>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
>>>> Subject: Re: announcement of freerouter
>>>> Message-ID:
>>>>         <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
>>>> rsS8T6YQ7Fsg at mail.gmail.com>
>>>> Content-Type: text/plain; charset=UTF-8
>>>> 
>>>> RouterOS is an existing product by MikroTik.
>>>> 
>>>> Mate Csaba's message had nothing to do with MikroTik RouterOS (from
>>> Latvia,
>>> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free.
>>> ;-)
>>> 
>>> Why was this response about RouterOS?  (Am I missing something?)
>>> 
>>> The posted presentations/slides touch upon the feature set of FreeRtr
>>> (which is similiar to MT RouterOS, but which many production-ready Network
>>> OSes have).
>>> http://freerouter.nop.hu/present.html
>>> And CLI output examples:
>>> http://freerouter.nop.hu/present.html
>>> 
>>> 
>>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>>>> 
>>>> hi,
>>>>> pleased to announce a stable release of freerouter.
>>>>> 
>>>> Neat.
>>> 
>>> 
>>> this is a routing daemon that does packet handling itself
>>>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
>>>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
>>>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
>>>>> babel...
>>>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
>>>>> nvgre...
>>>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
>>>>> tacacs, radius, ssh...
>>>>> it can start external images which could be connected, so various lab
>>>>> topolgies can be easily created.
>>>>> our nren uses if as primary fullbgp rr for more than a year for about
>>>>> hundred routers.
>>>>> here is the homepage: http://freerouter.nop.hu/
>>>>> feel free to try it out and send suggestions/bug reports...:)
>>>>> thanks in advance,
>>>>> csaba mate
>>>>> niif/hungarnet
>>>>> 
>>>> 
>>> 
>> 


From josh at imaginenetworksllc.com  Tue Dec 29 18:38:48 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 29 Dec 2015 13:38:48 -0500
Subject: announcement of freerouter
In-Reply-To: <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
Message-ID: <CAN9qwJ9DA+g2+V=QpK=7HFvz+o=mbxK-feYR1+u=sbaFAgsCQg@mail.gmail.com>

Thanks for clearing it up, I was still confused what Mikrotik's OS had to
do with it.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Dec 29, 2015 at 1:29 PM, Owen DeLong <owen at delong.com> wrote:

> In fairness, when I first looked at the page, I was confused too.
>
> It said it ran as a ?Router OS Process? which made me think that it was
> somehow a virtual router that ran inside the Mikrotik operating system
> known as Router SO and I was scratching my head going:
>
> A: How can that possibly work?
> B: Why would you want it to?
>
> Now, realizing that the guy probably made an honest mistake without
> realizing
> he was using someone else?s trade name in the process, it makes much more
> sense.
>
> Confusing, but in the end, much ado about nothing[1] all around.
>
> Owen
>
> [1] No intent here to misuse any intellectual property of any Bard or
> other person.
>
>
> > On Dec 29, 2015, at 01:08 , Josh Reynolds <josh at kyneticwifi.com> wrote:
> >
> > It wasn't about trolling, it was about legitimate prior art and
> reasonably
> > so. Also, there's potentially a confusing association between the two.
> >
> > I'm glad the terminology was removed.
> > On Dec 28, 2015 2:31 PM, "Laszlo Hanyecz" <laszlo at heliacal.net> wrote:
> >
> >> Mike,
> >>
> >> Csaba's front page previously described the software as being a
> >> 'routerOS', like in the very first sentence on the page.  I'm assuming
> that
> >> the person who complained about that didn't read past the first sentence
> >> and just wanted to troll.  It's obvious to me that decades of work have
> >> gone into this free router software, and the term router OS was just
> being
> >> used to describe what the software does - an OS for a router.
> >>
> >> It looks to me like the author has a deep understanding of networking to
> >> be able to implement all this from scratch and I think we can learn a
> lot
> >> from reading this code.  He's also giving it away for free, which is
> hard
> >> to argue with.
> >>
> >> -Laszlo
> >>
> >> On 2015-12-28 18:28, Mike - st257 wrote:
> >>
> >>> Date: Thu, 24 Dec 2015 22:23:24 -0600
> >>>> From: Josh Reynolds <josh at kyneticwifi.com>
> >>>> To: mate csaba <matecs at niif.hu>
> >>>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
> >>>> Subject: Re: announcement of freerouter
> >>>> Message-ID:
> >>>>         <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
> >>>> rsS8T6YQ7Fsg at mail.gmail.com>
> >>>> Content-Type: text/plain; charset=UTF-8
> >>>>
> >>>> RouterOS is an existing product by MikroTik.
> >>>>
> >>>> Mate Csaba's message had nothing to do with MikroTik RouterOS (from
> >>> Latvia,
> >>> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free.
> >>> ;-)
> >>>
> >>> Why was this response about RouterOS?  (Am I missing something?)
> >>>
> >>> The posted presentations/slides touch upon the feature set of FreeRtr
> >>> (which is similiar to MT RouterOS, but which many production-ready
> Network
> >>> OSes have).
> >>> http://freerouter.nop.hu/present.html
> >>> And CLI output examples:
> >>> http://freerouter.nop.hu/present.html
> >>>
> >>>
> >>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
> >>>>
> >>>> hi,
> >>>>> pleased to announce a stable release of freerouter.
> >>>>>
> >>>> Neat.
> >>>
> >>>
> >>> this is a routing daemon that does packet handling itself
> >>>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
> >>>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
> >>>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
> >>>>> babel...
> >>>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
> >>>>> nvgre...
> >>>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
> >>>>> tacacs, radius, ssh...
> >>>>> it can start external images which could be connected, so various lab
> >>>>> topolgies can be easily created.
> >>>>> our nren uses if as primary fullbgp rr for more than a year for about
> >>>>> hundred routers.
> >>>>> here is the homepage: http://freerouter.nop.hu/
> >>>>> feel free to try it out and send suggestions/bug reports...:)
> >>>>> thanks in advance,
> >>>>> csaba mate
> >>>>> niif/hungarnet
> >>>>>
> >>>>
> >>>
> >>
>
>

From silvertip257 at gmail.com  Tue Dec 29 19:08:05 2015
From: silvertip257 at gmail.com (Mike - st257)
Date: Tue, 29 Dec 2015 14:08:05 -0500
Subject: announcement of freerouter
In-Reply-To: <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
Message-ID: <CA+W-zorquS2Q6kVRZavUX87ZYB_w59uOuknKrEan_aH4kJL0KA@mail.gmail.com>

On Tue, Dec 29, 2015 at 1:29 PM, Owen DeLong <owen at delong.com> wrote:

> In fairness, when I first looked at the page, I was confused too.
>

That content of web page(s) must have been altered between when Josh R. and
I viewed it.


>
> It said it ran as a ?Router OS Process? which made me think that it was
> somehow a virtual router that ran inside the Mikrotik operating system
> known as Router SO and I was scratching my head going:
>
> A: How can that possibly work?
> B: Why would you want it to?
>
> Now, realizing that the guy probably made an honest mistake without
> realizing
> he was using someone else?s trade name in the process, it makes much more
> sense.
>
> Confusing, but in the end, much ado about nothing[1] all around.
>

yep
Keeping us on our toes.
:-)


>
> Owen
>
> [1] No intent here to misuse any intellectual property of any Bard or
> other person.
>
>
> > On Dec 29, 2015, at 01:08 , Josh Reynolds <josh at kyneticwifi.com> wrote:
> >
> > It wasn't about trolling, it was about legitimate prior art and
> reasonably
> > so. Also, there's potentially a confusing association between the two.
> >
> > I'm glad the terminology was removed.
> > On Dec 28, 2015 2:31 PM, "Laszlo Hanyecz" <laszlo at heliacal.net> wrote:
> >
> >> Mike,
> >>
> >> Csaba's front page previously described the software as being a
> >> 'routerOS', like in the very first sentence on the page.  I'm assuming
> that
> >> the person who complained about that didn't read past the first sentence
> >> and just wanted to troll.  It's obvious to me that decades of work have
> >> gone into this free router software, and the term router OS was just
> being
> >> used to describe what the software does - an OS for a router.
> >>
> >> It looks to me like the author has a deep understanding of networking to
> >> be able to implement all this from scratch and I think we can learn a
> lot
> >> from reading this code.  He's also giving it away for free, which is
> hard
> >> to argue with.
> >>
> >> -Laszlo
> >>
> >> On 2015-12-28 18:28, Mike - st257 wrote:
> >>
> >>> Date: Thu, 24 Dec 2015 22:23:24 -0600
> >>>> From: Josh Reynolds <josh at kyneticwifi.com>
> >>>> To: mate csaba <matecs at niif.hu>
> >>>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
> >>>> Subject: Re: announcement of freerouter
> >>>> Message-ID:
> >>>>         <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
> >>>> rsS8T6YQ7Fsg at mail.gmail.com>
> >>>> Content-Type: text/plain; charset=UTF-8
> >>>>
> >>>> RouterOS is an existing product by MikroTik.
> >>>>
> >>>> Mate Csaba's message had nothing to do with MikroTik RouterOS (from
> >>> Latvia,
> >>> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free.
> >>> ;-)
> >>>
> >>> Why was this response about RouterOS?  (Am I missing something?)
> >>>
> >>> The posted presentations/slides touch upon the feature set of FreeRtr
> >>> (which is similiar to MT RouterOS, but which many production-ready
> Network
> >>> OSes have).
> >>> http://freerouter.nop.hu/present.html
> >>> And CLI output examples:
> >>> http://freerouter.nop.hu/present.html
> >>>
> >>>
> >>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
> >>>>
> >>>> hi,
> >>>>> pleased to announce a stable release of freerouter.
> >>>>>
> >>>> Neat.
> >>>
> >>>
> >>> this is a routing daemon that does packet handling itself
> >>>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
> >>>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
> >>>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
> >>>>> babel...
> >>>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
> >>>>> nvgre...
> >>>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
> >>>>> tacacs, radius, ssh...
> >>>>> it can start external images which could be connected, so various lab
> >>>>> topolgies can be easily created.
> >>>>> our nren uses if as primary fullbgp rr for more than a year for about
> >>>>> hundred routers.
> >>>>> here is the homepage: http://freerouter.nop.hu/
> >>>>> feel free to try it out and send suggestions/bug reports...:)
> >>>>> thanks in advance,
> >>>>> csaba mate
> >>>>> niif/hungarnet
> >>>>>
> >>>>
> >>>
> >>
>
>


-- 
---~~.~~---
Mike
//  SilverTip257  //

From mel at beckman.org  Tue Dec 29 19:29:08 2015
From: mel at beckman.org (Mel Beckman)
Date: Tue, 29 Dec 2015 19:29:08 +0000
Subject: announcement of freerouter
In-Reply-To: <CA+W-zorquS2Q6kVRZavUX87ZYB_w59uOuknKrEan_aH4kJL0KA@mail.gmail.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
 <CA+W-zorquS2Q6kVRZavUX87ZYB_w59uOuknKrEan_aH4kJL0KA@mail.gmail.com>
Message-ID: <C2878041-8F48-4A21-8FF0-90716089584D@beckman.org>

Amazing what the proprietary appropriation of a single Word can do :)

 -mel

> On Dec 29, 2015, at 11:08 AM, Mike - st257 <silvertip257 at gmail.com> wrote:
> 
> On Tue, Dec 29, 2015 at 1:29 PM, Owen DeLong <owen at delong.com> wrote:
> 
>> In fairness, when I first looked at the page, I was confused too.
>> 
> 
> That content of web page(s) must have been altered between when Josh R. and
> I viewed it.
> 
> 
>> 
>> It said it ran as a ?Router OS Process? which made me think that it was
>> somehow a virtual router that ran inside the Mikrotik operating system
>> known as Router SO and I was scratching my head going:
>> 
>> A: How can that possibly work?
>> B: Why would you want it to?
>> 
>> Now, realizing that the guy probably made an honest mistake without
>> realizing
>> he was using someone else?s trade name in the process, it makes much more
>> sense.
>> 
>> Confusing, but in the end, much ado about nothing[1] all around.
>> 
> 
> yep
> Keeping us on our toes.
> :-)
> 
> 
>> 
>> Owen
>> 
>> [1] No intent here to misuse any intellectual property of any Bard or
>> other person.
>> 
>> 
>>> On Dec 29, 2015, at 01:08 , Josh Reynolds <josh at kyneticwifi.com> wrote:
>>> 
>>> It wasn't about trolling, it was about legitimate prior art and
>> reasonably
>>> so. Also, there's potentially a confusing association between the two.
>>> 
>>> I'm glad the terminology was removed.
>>> On Dec 28, 2015 2:31 PM, "Laszlo Hanyecz" <laszlo at heliacal.net> wrote:
>>> 
>>>> Mike,
>>>> 
>>>> Csaba's front page previously described the software as being a
>>>> 'routerOS', like in the very first sentence on the page.  I'm assuming
>> that
>>>> the person who complained about that didn't read past the first sentence
>>>> and just wanted to troll.  It's obvious to me that decades of work have
>>>> gone into this free router software, and the term router OS was just
>> being
>>>> used to describe what the software does - an OS for a router.
>>>> 
>>>> It looks to me like the author has a deep understanding of networking to
>>>> be able to implement all this from scratch and I think we can learn a
>> lot
>>>> from reading this code.  He's also giving it away for free, which is
>> hard
>>>> to argue with.
>>>> 
>>>> -Laszlo
>>>> 
>>>> On 2015-12-28 18:28, Mike - st257 wrote:
>>>> 
>>>>> Date: Thu, 24 Dec 2015 22:23:24 -0600
>>>>>> From: Josh Reynolds <josh at kyneticwifi.com>
>>>>>> To: mate csaba <matecs at niif.hu>
>>>>>> Cc: cs at nop.hu, NANOG <nanog at nanog.org>
>>>>>> Subject: Re: announcement of freerouter
>>>>>> Message-ID:
>>>>>>        <CAC6=tfb4=DmpXBgG159NH-p+uTxa+uwf3vOrB=
>>>>>> rsS8T6YQ7Fsg at mail.gmail.com>
>>>>>> Content-Type: text/plain; charset=UTF-8
>>>>>> 
>>>>>> RouterOS is an existing product by MikroTik.
>>>>>> 
>>>>>> Mate Csaba's message had nothing to do with MikroTik RouterOS (from
>>>>> Latvia,
>>>>> which doesn't include IS-IS support). And Mikrotik RouterOS isn't free.
>>>>> ;-)
>>>>> 
>>>>> Why was this response about RouterOS?  (Am I missing something?)
>>>>> 
>>>>> The posted presentations/slides touch upon the feature set of FreeRtr
>>>>> (which is similiar to MT RouterOS, but which many production-ready
>> Network
>>>>> OSes have).
>>>>> http://freerouter.nop.hu/present.html
>>>>> And CLI output examples:
>>>>> http://freerouter.nop.hu/present.html
>>>>> 
>>>>> 
>>>>> On Dec 24, 2015 9:46 PM, "mate csaba" <matecs at niif.hu> wrote:
>>>>>> 
>>>>>> hi,
>>>>>>> pleased to announce a stable release of freerouter.
>>>>>>> 
>>>>>> Neat.
>>>>> 
>>>>> 
>>>>> this is a routing daemon that does packet handling itself
>>>>>>> so it can do bridging, routing ipv4/ipv6 unicast/multicast,
>>>>>>> mpls, vpls, evpn, mpls te, mldp, segment routing, and so on...
>>>>>>> speaks a lot of routing protocols like rip, ospf, isis, eigrp, bgp,
>>>>>>> babel...
>>>>>>> does a lot of tunneling like gre, ipip, ipsec, l2tp, geneve, vxlan,
>>>>>>> nvgre...
>>>>>>> have a lot of built in servers like dns, http(s), smtp, pop3, telnet,
>>>>>>> tacacs, radius, ssh...
>>>>>>> it can start external images which could be connected, so various lab
>>>>>>> topolgies can be easily created.
>>>>>>> our nren uses if as primary fullbgp rr for more than a year for about
>>>>>>> hundred routers.
>>>>>>> here is the homepage: http://freerouter.nop.hu/
>>>>>>> feel free to try it out and send suggestions/bug reports...:)
>>>>>>> thanks in advance,
>>>>>>> csaba mate
>>>>>>> niif/hungarnet
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 
> 
> 
> -- 
> ---~~.~~---
> Mike
> //  SilverTip257  //


From morrowc.lists at gmail.com  Tue Dec 29 20:48:41 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 29 Dec 2015 15:48:41 -0500
Subject: interconnection costs
In-Reply-To: <CAPkb-7AohjKYarF8Y7LjzJ0COB4_eSxMvNggbA=v0a5rhx3fTg@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
 <CAPkb-7Dx7CBemv9L_aE3Kq0K3_K=B9vBQngmRa0zA38AO1Gjxw@mail.gmail.com>
 <CACGuEhHz58T5O6og60iZFCKBXOW0mYa3X9DPaKo_sHU0F-_OOQ@mail.gmail.com>
 <107714.1450922667@turing-police.cc.vt.edu>
 <CAPkb-7AohjKYarF8Y7LjzJ0COB4_eSxMvNggbA=v0a5rhx3fTg@mail.gmail.com>
Message-ID: <CAL9jLaY8O177sQVKJagRwg_RM1Ln8Puh09QWSEGVvZLVmQRMag@mail.gmail.com>

On Wed, Dec 23, 2015 at 9:13 PM, Baldur Norddahl
<baldur.norddahl at gmail.com> wrote:
> On 24 December 2015 at 03:04, <Valdis.Kletnieks at vt.edu> wrote:
>
>> On Wed, 23 Dec 2015 16:39:11 -0800, Reza Motamedi said:
>> > Aren't availability, guaranteed service and remote hands an incentive to
>> do
>> > peering inside a third party colocation?
>>
>> Sure.  But there are places in the US where you have to decide whether the
>> cost of lighting 300 miles of fiber to the colo is worth the benefits, when
>> the other option is lighting fiber to a street cabinet across town.
>>
>
> Also remember that 300 miles of fiber is going to go through a dozen of
> street cabinets to get there.

be sure that you either:
  a) plan for a second path for when the backhoe arrives
  b) understand that you may slosh 'lots' of traffic 'elsewhere' when A happens

if you don't want to ship/install/etc a device in a cage in 'equinix'
but rather use a Xconnect/fiber provider solution you're moving your
failure domains around a bit.

From wwaites at tardis.ed.ac.uk  Wed Dec 30 00:36:53 2015
From: wwaites at tardis.ed.ac.uk (William Waites)
Date: Wed, 30 Dec 2015 00:36:53 +0000 (GMT)
Subject: cloudflare contact
Message-ID: <20151230.003653.305919085820451383.wwaites@tardis.ed.ac.uk>

Could someone from Cloudflare's operations please contact me off-list?

Thanks,
-w


--
William Waites <wwaites at tardis.ed.ac.uk>  |  School of Informatics
   https://tardis.ed.ac.uk/~wwaites/      | University of Edinburgh
         https://hubs.net.uk/             |      HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

From jmaimon at ttec.com  Wed Dec 30 02:13:59 2015
From: jmaimon at ttec.com (Joe Maimon)
Date: Tue, 29 Dec 2015 21:13:59 -0500
Subject: ridiculous problems getting an ATT circuit port mode changed
Message-ID: <56833DE7.5010004@ttec.com>

Apparently there is still raison d'etre for everyone not a giant telco.

We placed the circuit with tagging expected for the service vlan.

We got it delivered without.

We requested it be changed.

Apparently that takes a change order, which when it is finally filed, 
takes 7-10BD to complete.

However, there is another complication. The vlan has to be different or 
the order cant be accepted, since the vlan is in use.

Options presented range from just reconfigure all your equipment, use it 
without the tag, reorder the UNI and expect at least a week of downtime.

This when we all know, and the TAC group flat out confirmed, the change 
is a push of button, a flick of a switch, a twist of a knob, etc, etc..

I view circuits with such change difficulties as liabilities.

Does anyone know anybody over in ATT land who can sort through this 
nonsense?

Thanks and enjoy the holidays!

Joe

From mhoppes at indigowireless.com  Wed Dec 30 02:56:54 2015
From: mhoppes at indigowireless.com (Matt Hoppes)
Date: Tue, 29 Dec 2015 21:56:54 -0500
Subject: Netflix stuffing data on pipe
Message-ID: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>

Has anyone else observed Netflix sessions attempting to come into customer CPE devices at well in excess of the customers throttled plan?

I'm not talking error retries on the line. I'm talking like two to three times in excess of what the customers CPE device can handle. 

I'm observing massive buffer overruns in some of our switches that appear to be directly related to this. And I can't figure out what possible good purpose Netflix would have for attempting to do this. 

Curious if anyone else has seen it?

From josh at kyneticwifi.com  Wed Dec 30 03:10:51 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Tue, 29 Dec 2015 21:10:51 -0600
Subject: Netflix stuffing data on pipe
In-Reply-To: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
Message-ID: <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>

Adaptive bandwidth detection.
On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:

> Has anyone else observed Netflix sessions attempting to come into customer
> CPE devices at well in excess of the customers throttled plan?
>
> I'm not talking error retries on the line. I'm talking like two to three
> times in excess of what the customers CPE device can handle.
>
> I'm observing massive buffer overruns in some of our switches that appear
> to be directly related to this. And I can't figure out what possible good
> purpose Netflix would have for attempting to do this.
>
> Curious if anyone else has seen it?

From mhoppes at indigowireless.com  Wed Dec 30 03:16:15 2015
From: mhoppes at indigowireless.com (Matt Hoppes)
Date: Tue, 29 Dec 2015 22:16:15 -0500
Subject: Netflix stuffing data on pipe
In-Reply-To: <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
Message-ID: <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>

So they are trying to stuff every last bit as an end device modulates up and down?

Or are you saying that's how they determine if they can scale up the resolution "because there is more throughout available now". 

> On Dec 29, 2015, at 22:10, Josh Reynolds <josh at kyneticwifi.com> wrote:
> 
> Adaptive bandwidth detection.
> 
>> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>> Has anyone else observed Netflix sessions attempting to come into customer CPE devices at well in excess of the customers throttled plan?
>> 
>> I'm not talking error retries on the line. I'm talking like two to three times in excess of what the customers CPE device can handle.
>> 
>> I'm observing massive buffer overruns in some of our switches that appear to be directly related to this. And I can't figure out what possible good purpose Netflix would have for attempting to do this.
>> 
>> Curious if anyone else has seen it?

From josh at kyneticwifi.com  Wed Dec 30 03:17:51 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Tue, 29 Dec 2015 21:17:51 -0600
Subject: Netflix stuffing data on pipe
In-Reply-To: <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
 <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
Message-ID: <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>

The second part. Fixed wireless is not even on their radar.
On Dec 29, 2015 9:16 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:

> So they are trying to stuff every last bit as an end device modulates up
> and down?
>
> Or are you saying that's how they determine if they can scale up the
> resolution "because there is more throughout available now".
>
> On Dec 29, 2015, at 22:10, Josh Reynolds <josh at kyneticwifi.com> wrote:
>
> Adaptive bandwidth detection.
> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>
>> Has anyone else observed Netflix sessions attempting to come into
>> customer CPE devices at well in excess of the customers throttled plan?
>>
>> I'm not talking error retries on the line. I'm talking like two to three
>> times in excess of what the customers CPE device can handle.
>>
>> I'm observing massive buffer overruns in some of our switches that appear
>> to be directly related to this. And I can't figure out what possible good
>> purpose Netflix would have for attempting to do this.
>>
>> Curious if anyone else has seen it?
>
>

From mpetach at netflight.com  Wed Dec 30 06:48:48 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 29 Dec 2015 22:48:48 -0800
Subject: announcement of freerouter
In-Reply-To: <8EEBB4A7-407A-4FA5-B453-2203388AD120@seastrom.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <8EEBB4A7-407A-4FA5-B453-2203388AD120@seastrom.com>
Message-ID: <CAEmG1=qpzu=BZv9MgBDWgQ2yfOBL_2a=uNyOQki2B1-exswmJw@mail.gmail.com>

On Tue, Dec 29, 2015 at 4:51 AM, Rob Seastrom <rs-lists at seastrom.com> wrote:
>> On Dec 29, 2015, at 4:08 AM, Josh Reynolds <josh at kyneticwifi.com> wrote:
>>
>> It wasn't about trolling, it was about legitimate prior art and reasonably
>> so. Also, there's potentially a confusing association between the two.
>>
>> I'm glad the terminology was removed.
>
> Since it's an operating system for routing IP, maybe they could call it "IP operating system", styled Ios, to prevent confusion with IOS and iOS.

And not to be confused with IoS,
the Internet of Shit:  ;P

https://youtu.be/soV7-gwxarE


> Lawyers gotta eat too...
>
> -r

From hugo at slabnet.com  Wed Dec 30 07:59:50 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Tue, 29 Dec 2015 23:59:50 -0800
Subject: Netflix stuffing data on pipe
In-Reply-To: <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
 <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
 <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>
Message-ID: <20151230075950.GA32240@slab-wks-04.int.slabnet.com>

On Tue 2015-Dec-29 21:17:51 -0600, Josh Reynolds <josh at kyneticwifi.com> wrote:

>The second part. Fixed wireless is not even on their radar.
>On Dec 29, 2015 9:16 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>
>> So they are trying to stuff every last bit as an end device modulates up
>> and down?
>>
>> Or are you saying that's how they determine if they can scale up the
>> resolution "because there is more throughout available now".
>>
>> On Dec 29, 2015, at 22:10, Josh Reynolds <josh at kyneticwifi.com> wrote:
>>
>> Adaptive bandwidth detection.
>> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>>
>>> Has anyone else observed Netflix sessions attempting to come into
>>> customer CPE devices at well in excess of the customers throttled plan?
>>>
>>> I'm not talking error retries on the line. I'm talking like two to three
>>> times in excess of what the customers CPE device can handle.
>>>
>>> I'm observing massive buffer overruns in some of our switches that appear
>>> to be directly related to this. And I can't figure out what possible good
>>> purpose Netflix would have for attempting to do this.
>>>

Pardon my ignorance of WISP-specific bits here, but how are they supposed 
to know to back off on their bitrate ramp-up if you keep buffering rather 
than dropping packets when the TX rate exceeds the customer's service rate?  
Or what am I missing?

>>> Curious if anyone else has seen it?
>>
>>

-- 
Hugo

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151229/86c24a85/attachment.pgp>

From randy at psg.com  Wed Dec 30 08:06:54 2015
From: randy at psg.com (Randy Bush)
Date: Wed, 30 Dec 2015 17:06:54 +0900
Subject: announcement of freerouter
In-Reply-To: <1876421211.711.1451399060782.JavaMail.mhammett@ThunderFuck>
References: <56819BA0.5060403@heliacal.net>
 <1876421211.711.1451399060782.JavaMail.mhammett@ThunderFuck>
Message-ID: <m2vb7gl5r5.wl%randy@psg.com>

ok kids.  the guy looks to have made a rather hot and unusually complete
contribution.  perhaps picking on his spelling is not productive.

randy

From josh at kyneticwifi.com  Wed Dec 30 08:22:09 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Wed, 30 Dec 2015 02:22:09 -0600
Subject: Netflix stuffing data on pipe
In-Reply-To: <20151230075950.GA32240@slab-wks-04.int.slabnet.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
 <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
 <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>
 <20151230075950.GA32240@slab-wks-04.int.slabnet.com>
Message-ID: <CAC6=tfY3SkidG5CTq8MTKGA043aSpwMSJVtpyTV1mEjQfUpvYQ@mail.gmail.com>

It's a long and ugly story...

1Gbps FD feeds -> switch -> 100Mbps FD radio port -> fluctuating PHY rate
Half Duplex wireless link/CPE (shaped here).

Netflix is microbusting, and its really nasty on his kind of network,
especially with the shaping being toward the end of his network.
On Dec 30, 2015 1:59 AM, "Hugo Slabbert" <hugo at slabnet.com> wrote:

> On Tue 2015-Dec-29 21:17:51 -0600, Josh Reynolds <josh at kyneticwifi.com>
> wrote:
>
> The second part. Fixed wireless is not even on their radar.
>> On Dec 29, 2015 9:16 PM, "Matt Hoppes" <mhoppes at indigowireless.com>
>> wrote:
>>
>> So they are trying to stuff every last bit as an end device modulates up
>>> and down?
>>>
>>> Or are you saying that's how they determine if they can scale up the
>>> resolution "because there is more throughout available now".
>>>
>>> On Dec 29, 2015, at 22:10, Josh Reynolds <josh at kyneticwifi.com> wrote:
>>>
>>> Adaptive bandwidth detection.
>>> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com>
>>> wrote:
>>>
>>> Has anyone else observed Netflix sessions attempting to come into
>>>> customer CPE devices at well in excess of the customers throttled plan?
>>>>
>>>> I'm not talking error retries on the line. I'm talking like two to three
>>>> times in excess of what the customers CPE device can handle.
>>>>
>>>> I'm observing massive buffer overruns in some of our switches that
>>>> appear
>>>> to be directly related to this. And I can't figure out what possible
>>>> good
>>>> purpose Netflix would have for attempting to do this.
>>>>
>>>>
> Pardon my ignorance of WISP-specific bits here, but how are they supposed
> to know to back off on their bitrate ramp-up if you keep buffering rather
> than dropping packets when the TX rate exceeds the customer's service
> rate?  Or what am I missing?
>
> Curious if anyone else has seen it?
>>>>
>>>
>>>
>>>
> --
> Hugo
>
> hugo at slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
>
> (also on Signal)
>
>

From colinj at gt86car.org.uk  Wed Dec 30 09:04:59 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Wed, 30 Dec 2015 09:04:59 +0000
Subject: Fwd: port 123 reflection attacks
References: <tencent_4C830DCB7856BFE463845B8C@qq.com>
Message-ID: <A494E3FF-7D8B-4E27-BAEB-E87B060D8558@gt86car.org.uk>

Where does it say we need to contact home cert instead on your website ?
verification of what ?
HSOFT ranges have been compromised by NTP reflection attacks and the NTP servers hosted by HSOFT need to have a NTP update.

This has been discussed on NANOG and I also sent information in Chinese to aid debug as well.

Have had no response from HSOFT?

Colin


> Begin forwarded message:
> 
> From: "cncertcc" <cncert at cert.org.cn>
> Subject: Re:Fwd: port 123 reflection attacks
> Date: 30 December 2015 at 08:15:28 GMT
> To: "Colin Johnston" <colinj at gt86car.org.uk>
> 
> Greetings,
> Please forward the case to the corresponding CERT you are located in first to have it transferred to CNCERT after verification. Thanks for your understanding.
>  
>  
> 
> 
> 
> 
> ------------------
> 
> Thanks and Regards
> CNCERT/CC
> --------------------------------------------------------
> ?????????
> National Computer network Emergency Response technical Team / Coordination Center of China
> Tel:+8610-82991000 fax:+8610-82990375
> email: cncert at cert.org.cn website:www.cert.org.cn
> Address: A3 Yumin Road, Chaoyang District, Beijing,100029, China 
> --------------------------------------------------------
>  
>  
>  
> ------------------ Original ------------------
> From:  "Colin Johnston"<colinj at gt86car.org.uk>;
> Date:  Fri, Dec 25, 2015 07:31 PM
> To:  "cncertcc"<cncert at cert.org.cn>;
> Cc:  "Colin Johnston"<colinj at gt86car.org.uk>;
> Subject:  Fwd: port 123 reflection attacks
>  
> 
> 
>> Begin forwarded message:
>> 
>> From: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
>> Subject: Fwd: port 123 reflection attacks
>> Date: 25 December 2015 at 11:27:02 GMT
>> To: oversea-support at cnnic.cn <mailto:oversea-support at cnnic.cn>, bdservice at cnnic.cn <mailto:bdservice at cnnic.cn>
>> Cc: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
>> 
>> Can you investigate with priority please
>> 
>> Colin
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
>>> Subject: port 123 reflection attacks
>>> Date: 25 December 2015 at 11:19:26 GMT
>>> To: 16036260 at qq.com <mailto:16036260 at qq.com>, ipas at cnnic.cn <mailto:ipas at cnnic.cn>
>>> Cc: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
>>> 
>>> please stop the port 123 reflection attacks from 115.47.24.220
>>> 
>>> Colin
>>> 
>> 
> 


From nanogml at Mail.DDoS-Mitigator.net  Wed Dec 30 10:11:39 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Wed, 30 Dec 2015 02:11:39 -0800
Subject: Fwd: port 123 reflection attacks
In-Reply-To: <A494E3FF-7D8B-4E27-BAEB-E87B060D8558@gt86car.org.uk>
References: <tencent_4C830DCB7856BFE463845B8C@qq.com>
 <A494E3FF-7D8B-4E27-BAEB-E87B060D8558@gt86car.org.uk>
Message-ID: <20151230101139.GA1721@Mail.DDoS-Mitigator.net>


hi ya colin

On 12/30/15 at 09:04am, Colin Johnston wrote:
> Where does it say we need to contact home cert instead on your website ?

because cncert at cert.org.cn asked ?

> verification of what ?

i'd want to see if it's a simple port scan by a script kidddie vs 
a more serious upcoming DOS attack from attackers with a "evil purpose"

they might just be poking around to find vulnerable ntpd servers ?

since there's been no satisfactory answer in 5 days, 
in the meantime, i'd suggest:
- be sure ntpd is properly configured
- be sure to be running the latest ( no known exploits ) ntpd server
- ntpd servers should only be necessary for your servers ...
  and incoming connections from outside should never reach your ntpd
- use an alternative ntpd server/source on a different wire

> HSOFT ranges have been compromised by NTP reflection attacks 

there's a difference between compromized vs port scanning ( probes )

- compromized... hsoft need to fix it ( upgrade and reconfigure ntpd ) 

- probes/scanners ... nothing much you can do other than limit your 
  outgoing ( 123/udp) replies

- there's thousands of probes occuring constantly on various ports ...

> and the NTP servers hosted by HSOFT need to have a NTP update.

they better get going to update their ntpd and configs ... 

i'd rattle hsoft's cage harder ... :-)

> This has been discussed on NANOG and I also sent information in Chinese to aid debug as well.
> 
> Have had no response from HSOFT?

:-)

i wonder what else is occupying their time

magic pixie dust
alvin
# DDoS-Simulator.net

> > From: "cncertcc" <cncert at cert.org.cn>
> > Subject: Re:Fwd: port 123 reflection attacks
> > Date: 30 December 2015 at 08:15:28 GMT
> > To: "Colin Johnston" <colinj at gt86car.org.uk>
> > 
> > Greetings,
> > Please forward the case to the corresponding CERT you are located in first to have it transferred to CNCERT after verification. Thanks for your understanding.
...
> >>> From: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
> >>> Subject: port 123 reflection attacks
> >>> Date: 25 December 2015 at 11:19:26 GMT
> >>> To: 16036260 at qq.com <mailto:16036260 at qq.com>, ipas at cnnic.cn <mailto:ipas at cnnic.cn>
> >>> Cc: Colin Johnston <colinj at gt86car.org.uk <mailto:colinj at gt86car.org.uk>>
> >>> 
> >>> please stop the port 123 reflection attacks from 115.47.24.220

From mhoppes at indigowireless.com  Wed Dec 30 12:42:33 2015
From: mhoppes at indigowireless.com (Matt Hoppes)
Date: Wed, 30 Dec 2015 07:42:33 -0500
Subject: Netflix stuffing data on pipe
In-Reply-To: <20151230075950.GA32240@slab-wks-04.int.slabnet.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
 <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
 <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>
 <20151230075950.GA32240@slab-wks-04.int.slabnet.com>
Message-ID: <097CDCC9-79BF-4405-A255-A1120B011F47@indigowireless.com>

I'm not buffering. Switches have packet buffers. I'm seeing switch buffers getting overrun by what appears to be Netflix traffic coming in at rates faster than the subscribers throttled speeds. 

> On Dec 30, 2015, at 02:59, Hugo Slabbert <hugo at slabnet.com> wrote:
> 
>> On Tue 2015-Dec-29 21:17:51 -0600, Josh Reynolds <josh at kyneticwifi.com> wrote:
>> 
>> The second part. Fixed wireless is not even on their radar.
>>> On Dec 29, 2015 9:16 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>>> 
>>> So they are trying to stuff every last bit as an end device modulates up
>>> and down?
>>> 
>>> Or are you saying that's how they determine if they can scale up the
>>> resolution "because there is more throughout available now".
>>> 
>>> On Dec 29, 2015, at 22:10, Josh Reynolds <josh at kyneticwifi.com> wrote:
>>> 
>>> Adaptive bandwidth detection.
>>>> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>>>> 
>>>> Has anyone else observed Netflix sessions attempting to come into
>>>> customer CPE devices at well in excess of the customers throttled plan?
>>>> 
>>>> I'm not talking error retries on the line. I'm talking like two to three
>>>> times in excess of what the customers CPE device can handle.
>>>> 
>>>> I'm observing massive buffer overruns in some of our switches that appear
>>>> to be directly related to this. And I can't figure out what possible good
>>>> purpose Netflix would have for attempting to do this.
> 
> Pardon my ignorance of WISP-specific bits here, but how are they supposed to know to back off on their bitrate ramp-up if you keep buffering rather than dropping packets when the TX rate exceeds the customer's service rate?  Or what am I missing?
> 
>>>> Curious if anyone else has seen it?
> 
> -- 
> Hugo
> 
> hugo at slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
> 
> (also on Signal)
> 

From mark.tinka at seacom.mu  Wed Dec 30 13:08:54 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 30 Dec 2015 15:08:54 +0200
Subject: announcement of freerouter
In-Reply-To: <m2vb7gl5r5.wl%randy@psg.com>
References: <56819BA0.5060403@heliacal.net>
 <1876421211.711.1451399060782.JavaMail.mhammett@ThunderFuck>
 <m2vb7gl5r5.wl%randy@psg.com>
Message-ID: <5683D766.90304@seacom.mu>



On 30/Dec/15 10:06, Randy Bush wrote:

> ok kids.  the guy looks to have made a rather hot and unusually complete
> contribution.  perhaps picking on his spelling is not productive.

That's all I keep thinking...

Mark.

From rdobbins at arbor.net  Wed Dec 30 13:21:16 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 30 Dec 2015 20:21:16 +0700
Subject: Netflix stuffing data on pipe
In-Reply-To: <097CDCC9-79BF-4405-A255-A1120B011F47@indigowireless.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
 <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
 <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>
 <20151230075950.GA32240@slab-wks-04.int.slabnet.com>
 <097CDCC9-79BF-4405-A255-A1120B011F47@indigowireless.com>
Message-ID: <EB94AF26-40D8-48E9-8F7B-B041B7634F75@arbor.net>

On 30 Dec 2015, at 19:42, Matt Hoppes wrote:

> I'm seeing switch buffers getting overrun by what appears to be 
> Netflix traffic coming in at rates faster than the subscribers 
> throttled speeds.

By what mechanism is the throttling accomplished?  QoS on routers, or 
some kind of middlebox, or . . . ?

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From swmike at swm.pp.se  Wed Dec 30 13:34:27 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 30 Dec 2015 14:34:27 +0100 (CET)
Subject: Netflix stuffing data on pipe
In-Reply-To: <097CDCC9-79BF-4405-A255-A1120B011F47@indigowireless.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
 <5C87D549-DB76-40B8-BD64-40449C2F84E1@indigowireless.com>
 <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com>
 <20151230075950.GA32240@slab-wks-04.int.slabnet.com>
 <097CDCC9-79BF-4405-A255-A1120B011F47@indigowireless.com>
Message-ID: <alpine.DEB.2.02.1512301432110.29581@uplift.swm.pp.se>

On Wed, 30 Dec 2015, Matt Hoppes wrote:

> I'm not buffering. Switches have packet buffers. I'm seeing switch 
> buffers getting overrun by what appears to be Netflix traffic coming in 
> at rates faster than the subscribers throttled speeds.

How big are your buffers (preferrably answer would be in milliseconds)? 
What access speeds are you providing?

It's standard behavior for network traffic to sometimes be at higher 
speeds than the customer access speeds, the sender only knows about 
congestion if there is an increase in RTT or if there is packet loss (or 
in case of ECN, EC=1 flag), and the only way to find out is to probe (=run 
faster than customer access speed).

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

From nanog at ics-il.net  Wed Dec 30 13:46:48 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Wed, 30 Dec 2015 07:46:48 -0600 (CST)
Subject: Netflix stuffing data on pipe
In-Reply-To: <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
Message-ID: <210325164.2460.1451483299663.JavaMail.mhammett@ThunderFuck>

I believe others have observed a similar situation with at least one other CDN and the situation continued solid for hours, not just occasional capacity detection. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Josh Reynolds" <josh at kyneticwifi.com> 
To: "Matt Hoppes" <mhoppes at indigowireless.com> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Tuesday, December 29, 2015 9:10:51 PM 
Subject: Re: Netflix stuffing data on pipe 

Adaptive bandwidth detection. 
On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote: 

> Has anyone else observed Netflix sessions attempting to come into customer 
> CPE devices at well in excess of the customers throttled plan? 
> 
> I'm not talking error retries on the line. I'm talking like two to three 
> times in excess of what the customers CPE device can handle. 
> 
> I'm observing massive buffer overruns in some of our switches that appear 
> to be directly related to this. And I can't figure out what possible good 
> purpose Netflix would have for attempting to do this. 
> 
> Curious if anyone else has seen it? 


From cb.list6 at gmail.com  Wed Dec 30 15:49:39 2015
From: cb.list6 at gmail.com (Ca By)
Date: Wed, 30 Dec 2015 07:49:39 -0800
Subject: Netflix stuffing data on pipe
In-Reply-To: <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
 <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com>
Message-ID: <CAD6AjGQnfJ6F=8GNmVxcszXLtE9eUGbWRXpRSu0MvPkwjXeweA@mail.gmail.com>

On Tuesday, December 29, 2015, Josh Reynolds <josh at kyneticwifi.com> wrote:

> Adaptive bandwidth detection.


Yes,  ABR video attempts to fill the entire channel

This has been problematic as peak edge speeds have increased and pushed the
statistical multplexing logic / plans.

There is also buffer bloat issues that exacerbate the problem by allowing
elephant flows to be too greedy at the expsense of others on the access
segment


> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com
> <javascript:;>> wrote:
>
> > Has anyone else observed Netflix sessions attempting to come into
> customer
> > CPE devices at well in excess of the customers throttled plan?
> >
> > I'm not talking error retries on the line. I'm talking like two to three
> > times in excess of what the customers CPE device can handle.
> >
> > I'm observing massive buffer overruns in some of our switches that appear
> > to be directly related to this. And I can't figure out what possible good
> > purpose Netflix would have for attempting to do this.
> >
> > Curious if anyone else has seen it?
>

From omonnig at gmail.com  Wed Dec 30 17:07:28 2015
From: omonnig at gmail.com (Otto Monnig)
Date: Wed, 30 Dec 2015 11:07:28 -0600
Subject: Level3 DNS not resolving for our domains
Message-ID: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>

Is anyone seeing issues with domains not resolving at 4.2.2.[1-6]?  All other test DNS servers function correctly.

Thank you,

--
Otto Monnig
CTO
KTG IP, LLC



From josh at imaginenetworksllc.com  Wed Dec 30 17:31:24 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Wed, 30 Dec 2015 12:31:24 -0500
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
Message-ID: <CAN9qwJ9NCtQcL6ehxTuf4UbN6Q1q8dhZTZRynV0mVgMooTCEvA@mail.gmail.com>

Works for me:
>dig google.com @4.2.2.2 +short
216.58.216.238

I expect your IP (either /32 or larger) may have done too many requests
within a finite time window.  Those DNS servers quit responding after too
many inquiries (I don't know the count or time frame).


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Wed, Dec 30, 2015 at 12:07 PM, Otto Monnig <omonnig at gmail.com> wrote:

> Is anyone seeing issues with domains not resolving at 4.2.2.[1-6]?  All
> other test DNS servers function correctly.
>
> Thank you,
>
> --
> Otto Monnig
> CTO
> KTG IP, LLC
>
>
>

From omonnig at gmail.com  Wed Dec 30 21:02:39 2015
From: omonnig at gmail.com (Otto Monnig)
Date: Wed, 30 Dec 2015 15:02:39 -0600
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
Message-ID: <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>

Sorry for not providing domains - I did so intentionally, as I believe this is a policy change at L3, rather than a technical issue.

One of our companies hosts multiple domains and the issue is widespread among those domains at several locations.

--
Otto Monnig



> On Dec 30, 2015, at 11:07 AM, Otto Monnig <omonnig at gmail.com> wrote:
> 
> Is anyone seeing issues with domains not resolving at 4.2.2.[1-6]?  All other test DNS servers function correctly.
> 
> Thank you,
> 
> --
> Otto Monnig
> CTO
> KTG IP, LLC
> 
> 


From bortzmeyer at nic.fr  Wed Dec 30 21:18:58 2015
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 30 Dec 2015 22:18:58 +0100
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
 <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
Message-ID: <20151230211858.GA2879@nic.fr>

On Wed, Dec 30, 2015 at 03:02:39PM -0600,
 Otto Monnig <omonnig at gmail.com> wrote 
 a message of 24 lines which said:

> Sorry for not providing domains - I did so intentionally, as I
> believe this is a policy change at L3, rather than a technical
> issue.

And how are we supposed to debug, without even one domain name?

Level 3 public DNS resolvers work fine for me (tested with several
names, both DNSSEC and not DNSSEC).


From omonnig at gmail.com  Wed Dec 30 21:48:26 2015
From: omonnig at gmail.com (Otto Monnig)
Date: Wed, 30 Dec 2015 15:48:26 -0600
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <20151230211858.GA2879@nic.fr>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
 <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
 <20151230211858.GA2879@nic.fr>
Message-ID: <E8197590-8759-4444-AC9E-FC44F4A5CDDC@gmail.com>

rocketktg.com <http://rocketktg.com/>


--
Otto Monnig



> On Dec 30, 2015, at 3:18 PM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> 
> On Wed, Dec 30, 2015 at 03:02:39PM -0600,
> Otto Monnig <omonnig at gmail.com> wrote 
> a message of 24 lines which said:
> 
>> Sorry for not providing domains - I did so intentionally, as I
>> believe this is a policy change at L3, rather than a technical
>> issue.
> 
> And how are we supposed to debug, without even one domain name?
> 
> Level 3 public DNS resolvers work fine for me (tested with several
> names, both DNSSEC and not DNSSEC).
> 


From alarig at swordarmor.fr  Wed Dec 30 22:12:29 2015
From: alarig at swordarmor.fr (Alarig Le Lay)
Date: Wed, 30 Dec 2015 23:12:29 +0100
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <E8197590-8759-4444-AC9E-FC44F4A5CDDC@gmail.com>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
 <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
 <20151230211858.GA2879@nic.fr>
 <E8197590-8759-4444-AC9E-FC44F4A5CDDC@gmail.com>
Message-ID: <20151230221228.GB12070@drscott.swordarmor.fr>

On Wed Dec 30 15:48:26 2015, Otto Monnig wrote:
> rocketktg.com <http://rocketktg.com/>

;; ADDITIONAL SECTION:
ns1.rocketktg.com.	244	IN	A	68.235.47.109
ns2.rocketktg.com.	244	IN	A	68.235.47.110

Both are in the same AS, perhaps a routing issue?

-- 
Alarig Le Lay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151230/8915c0b2/attachment.pgp>

From jared at puck.nether.net  Wed Dec 30 22:14:45 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 30 Dec 2015 17:14:45 -0500
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <20151230221228.GB12070@drscott.swordarmor.fr>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
 <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
 <20151230211858.GA2879@nic.fr>
 <E8197590-8759-4444-AC9E-FC44F4A5CDDC@gmail.com>
 <20151230221228.GB12070@drscott.swordarmor.fr>
Message-ID: <B09169A8-123A-4661-8FA5-4DCACF1F8126@puck.nether.net>


> On Dec 30, 2015, at 5:12 PM, Alarig Le Lay <alarig at swordarmor.fr> wrote:
> 
> On Wed Dec 30 15:48:26 2015, Otto Monnig wrote:
>> rocketktg.com <http://rocketktg.com/>
> 
> ;; ADDITIONAL SECTION:
> ns1.rocketktg.com.	244	IN	A	68.235.47.109
> ns2.rocketktg.com.	244	IN	A	68.235.47.110
> 
> Both are in the same AS, perhaps a routing issue?

Seems like a good candidate for reading http://www.rfc-editor.org/rfc/rfc2182.txt

- jared


From bortzmeyer at nic.fr  Wed Dec 30 22:44:00 2015
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 30 Dec 2015 23:44:00 +0100
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <20151230221228.GB12070@drscott.swordarmor.fr>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
 <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
 <20151230211858.GA2879@nic.fr>
 <E8197590-8759-4444-AC9E-FC44F4A5CDDC@gmail.com>
 <20151230221228.GB12070@drscott.swordarmor.fr>
Message-ID: <20151230224400.GA8584@nic.fr>

On Wed, Dec 30, 2015 at 11:12:29PM +0100,
 Alarig Le Lay <alarig at swordarmor.fr> wrote 
 a message of 35 lines which said:

> Both are in the same AS, perhaps a routing issue?

Indeed. This is a warning in ZoneMaster
<https://zonemaster.net/test/b9c2efd5a10f2eb8> and I observe also that
10-15 % of the RIPE Atlas probes cannot resolve this name (so it is
not just Level 3). The name servers unfortunately do not reply to ICMP
echo so it is hard to debug.




From ryan at finnesey.com  Wed Dec 30 23:49:51 2015
From: ryan at finnesey.com (Ryan Finnesey)
Date: Wed, 30 Dec 2015 23:49:51 +0000
Subject: list of .org domain names?
Message-ID: <BLUPR05MB595BD4865FC256F4C26B8CCB4FD0@BLUPR05MB595.namprd05.prod.outlook.com>

Is it possible to get a complete list of .org domain names that have been registered?

Cheers
Ryan


From jabley at hopcount.ca  Wed Dec 30 23:55:41 2015
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 30 Dec 2015 18:55:41 -0500
Subject: list of .org domain names?
In-Reply-To: <BLUPR05MB595BD4865FC256F4C26B8CCB4FD0@BLUPR05MB595.namprd05.prod.outlook.com>
References: <BLUPR05MB595BD4865FC256F4C26B8CCB4FD0@BLUPR05MB595.namprd05.prod.outlook.com>
Message-ID: <-5851110090598251924@unknownmsgid>

On Dec 30, 2015, at 18:50, Ryan Finnesey <ryan at finnesey.com> wrote:

> Is it possible to get a complete list of .org domain names that have been registered?

If you can satisfy the terms of the sone file access agreement, you
can get a copy of the org zone which will give you a list of delegated
domain names (not quite the same as the list of registered domain
names, but similar).

http://pir.org/resources/file-zone-access/


Joe

From mysidia at gmail.com  Thu Dec 31 00:54:00 2015
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 30 Dec 2015 18:54:00 -0600
Subject: announcement of freerouter
In-Reply-To: <C2878041-8F48-4A21-8FF0-90716089584D@beckman.org>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
 <CA+W-zorquS2Q6kVRZavUX87ZYB_w59uOuknKrEan_aH4kJL0KA@mail.gmail.com>
 <C2878041-8F48-4A21-8FF0-90716089584D@beckman.org>
Message-ID: <CAAAwwbWZD-DvE3OG3CvE_VyRHMLDsvymvGkMiy7Hv3mye248mg@mail.gmail.com>

On Tue, Dec 29, 2015 at 1:29 PM, Mel Beckman <mel at beckman.org> wrote:
> Amazing what the proprietary appropriation of a single Word can do :)

Yes.... I'm quite bothered by that.   As far as I'm concerned  "Router
OS"  refers to whatever operating system drives a router.

Just like "Computer OS"  is not referring to a specific piece of
software,  but it's a description of a software's role within a
system.

To suggest "Router OS"  refers to a specific product,  is like
suggesting  "Bottled Water"  refers to  a specific brand of packaged
liquid.


>  -mel
--
-JH

From lukasz at bromirski.net  Thu Dec 31 01:55:15 2015
From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=)
Date: Thu, 31 Dec 2015 02:55:15 +0100
Subject: announcement of freerouter
In-Reply-To: <CAAAwwbWZD-DvE3OG3CvE_VyRHMLDsvymvGkMiy7Hv3mye248mg@mail.gmail.com>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
 <CA+W-zorquS2Q6kVRZavUX87ZYB_w59uOuknKrEan_aH4kJL0KA@mail.gmail.com>
 <C2878041-8F48-4A21-8FF0-90716089584D@beckman.org>
 <CAAAwwbWZD-DvE3OG3CvE_VyRHMLDsvymvGkMiy7Hv3mye248mg@mail.gmail.com>
Message-ID: <83F97E97-3439-4ECC-913F-B36B33A76F84@bromirski.net>


> On 31 Dec 2015, at 01:54, Jimmy Hess <mysidia at gmail.com> wrote:
> 
>> On Tue, Dec 29, 2015 at 1:29 PM, Mel Beckman <mel at beckman.org> wrote:
>> Amazing what the proprietary appropriation of a single Word can do :)
> 
> Yes.... I'm quite bothered by that.   As far as I'm concerned  "Router
> OS"  refers to whatever operating system drives a router.

I believe Mikrotik is using "RouterOS" and "RouterBOARD" as registered trademarks, not generic "router os".

The problem however is, that according to google search (I may be wrong here), the trademark was eventually never registered:

https://trademarks.justia.com/771/58/routeros-77158105.html

Anyway, let's concentrate on the source code and solution provided (further referred as "meat"), and let parties involved sort out the trademarks, copyrights and other issues (further referred as to "slack" ;)) themselves.

-- 
./

From josh at kyneticwifi.com  Thu Dec 31 02:07:46 2015
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Wed, 30 Dec 2015 20:07:46 -0600
Subject: announcement of freerouter
In-Reply-To: <83F97E97-3439-4ECC-913F-B36B33A76F84@bromirski.net>
References: <CA+W-zorYqiYQbHQQv-H5-PAKxkjzew9aP+dXhbcFwjDpe-xdHg@mail.gmail.com>
 <56819BA0.5060403@heliacal.net>
 <CAC6=tfY5bpO0oES70wJ4Y9JQc__UNLOxXmceh2nx6qKM1P_zbQ@mail.gmail.com>
 <591A95F1-7B92-42F1-8F80-DAD31333746D@delong.com>
 <CA+W-zorquS2Q6kVRZavUX87ZYB_w59uOuknKrEan_aH4kJL0KA@mail.gmail.com>
 <C2878041-8F48-4A21-8FF0-90716089584D@beckman.org>
 <CAAAwwbWZD-DvE3OG3CvE_VyRHMLDsvymvGkMiy7Hv3mye248mg@mail.gmail.com>
 <83F97E97-3439-4ECC-913F-B36B33A76F84@bromirski.net>
Message-ID: <CAC6=tfZD1U1GjifWd0rDEm-84sc1yKUCCQ=yz5n5R6-rVszitg@mail.gmail.com>

Hence, my statement of "prior art" and not TM, as they never followed up on
it :)
On Dec 30, 2015 7:57 PM, "?ukasz Bromirski" <lukasz at bromirski.net> wrote:

>
> > On 31 Dec 2015, at 01:54, Jimmy Hess <mysidia at gmail.com> wrote:
> >
> >> On Tue, Dec 29, 2015 at 1:29 PM, Mel Beckman <mel at beckman.org> wrote:
> >> Amazing what the proprietary appropriation of a single Word can do :)
> >
> > Yes.... I'm quite bothered by that.   As far as I'm concerned  "Router
> > OS"  refers to whatever operating system drives a router.
>
> I believe Mikrotik is using "RouterOS" and "RouterBOARD" as registered
> trademarks, not generic "router os".
>
> The problem however is, that according to google search (I may be wrong
> here), the trademark was eventually never registered:
>
> https://trademarks.justia.com/771/58/routeros-77158105.html
>
> Anyway, let's concentrate on the source code and solution provided
> (further referred as "meat"), and let parties involved sort out the
> trademarks, copyrights and other issues (further referred as to "slack" ;))
> themselves.
>
> --
> ./
>

From randy at psg.com  Thu Dec 31 02:16:07 2015
From: randy at psg.com (Randy Bush)
Date: Thu, 31 Dec 2015 11:16:07 +0900
Subject: Fwd: port 123 reflection attacks
In-Reply-To: <20151230101139.GA1721@Mail.DDoS-Mitigator.net>
References: <tencent_4C830DCB7856BFE463845B8C@qq.com>
 <A494E3FF-7D8B-4E27-BAEB-E87B060D8558@gt86car.org.uk>
 <20151230101139.GA1721@Mail.DDoS-Mitigator.net>
Message-ID: <m2mvsrjrbs.wl%randy@psg.com>

> - be sure ntpd is properly configured

to be explicit, test it

     % ntpdc -n -c monlist psg.com    
     psg.com: timed out, nothing received
     ***Request timed out

this is the desired result.  any real response means the host is open
to be a reflector

fwiw, i got caught last week.  a debien vm had been brought up using
dhcp, and the /var/lib/ntp/ntp.conf.dhcp was still there after the host
was reconfigured to static.  took me a while to find it.  embarrassing.
my ntp.yml playbook now has as it's first task

    - name: remove dhcpd artifact
      file: path=/var/lib/ntp/ntp.conf.dhcp state=absent

randy

From randy at psg.com  Thu Dec 31 02:18:08 2015
From: randy at psg.com (Randy Bush)
Date: Thu, 31 Dec 2015 11:18:08 +0900
Subject: Level3 DNS not resolving for our domains
In-Reply-To: <20151230221228.GB12070@drscott.swordarmor.fr>
References: <72DC9F5C-9583-4DD4-9AE0-65A508B85B1C@gmail.com>
 <49440AA1-A30A-475F-9C02-64BAA8EDD0B5@gmail.com>
 <20151230211858.GA2879@nic.fr>
 <E8197590-8759-4444-AC9E-FC44F4A5CDDC@gmail.com>
 <20151230221228.GB12070@drscott.swordarmor.fr>
Message-ID: <m2lh8bjr8f.wl%randy@psg.com>

>> rocketktg.com <http://rocketktg.com/>
> 
> ;; ADDITIONAL SECTION:
> ns1.rocketktg.com.	244	IN	A	68.235.47.109
> ns2.rocketktg.com.	244	IN	A	68.235.47.110

rfc2182 section 6

From awentzell at gmail.com  Thu Dec 31 01:57:40 2015
From: awentzell at gmail.com (Andrew Wentzell)
Date: Wed, 30 Dec 2015 20:57:40 -0500
Subject: ridiculous problems getting an ATT circuit port mode changed
In-Reply-To: <56833DE7.5010004@ttec.com>
References: <56833DE7.5010004@ttec.com>
Message-ID: <CADBpUxUeisBDwZfZ064gmeX8UePLR93p3kMqhaed2G_Fzv=5QQ@mail.gmail.com>

On Tue, Dec 29, 2015 at 9:13 PM, Joe Maimon <jmaimon at ttec.com> wrote:
> Apparently there is still raison d'etre for everyone not a giant telco.
>
> We placed the circuit with tagging expected for the service vlan.
>
> We got it delivered without.
>
> We requested it be changed.
>
> Apparently that takes a change order, which when it is finally filed, takes
> 7-10BD to complete.
>
> However, there is another complication. The vlan has to be different or the
> order cant be accepted, since the vlan is in use.
>
> Options presented range from just reconfigure all your equipment, use it
> without the tag, reorder the UNI and expect at least a week of downtime.
>
> This when we all know, and the TAC group flat out confirmed, the change is a
> push of button, a flick of a switch, a twist of a knob, etc, etc..
>
> I view circuits with such change difficulties as liabilities.
>
> Does anyone know anybody over in ATT land who can sort through this
> nonsense?

Did you already accept delivery? If not, call whatever number you have
for "test and turn up" and request the tech to make these changes.
This will be a different group than the one that handles changes to
existing circuits.

If you accepted, then you're out of luck and in for a wait. It doesn't
matter how trivial the change is, or how big a customer you are. Of
course, you'll be billed for the service in the meantime.

> Thanks and enjoy the holidays!
>
> Joe

From jwbensley at gmail.com  Thu Dec 31 15:30:56 2015
From: jwbensley at gmail.com (James Bensley)
Date: Thu, 31 Dec 2015 15:30:56 +0000
Subject: interconnection costs
In-Reply-To: <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
References: <CACGuEhE1ZBWpvxm=uweriBtSMD5vrKk1u63bcB8_S5k1qiuu-w@mail.gmail.com>
 <CAAWx_pXqGLgR4BZfSEJz7S21=daUZ0dG-GGtX+unnm0VkxYufQ@mail.gmail.com>
 <CACGuEhHMgP7WDGqOVGpX9L+KuihUMHBDwTAR78jhnsLD3itx9w@mail.gmail.com>
 <CAAWx_pXG0RY1ULkTsdonueSntpaU83t6RiDX6OD8PhPHgJwKPg@mail.gmail.com>
 <CACGuEhE-9dWtEc9=10D7jq-n_U8Dw_RCop7_A__2o2=UOob8gQ@mail.gmail.com>
Message-ID: <CAAWx_pU56XTrQvL9WW4U=U7LnrcE8dT+kxedyQqapznxdODQbQ@mail.gmail.com>

On 23 Dec 2015 20:06, "Reza Motamedi" <motamedi at cs.uoregon.edu> wrote:
>
> All the costs of HW, SW, personnel, administration, and perhaps
transmission between colos (including remote peering, being waved to
another location, tethering) would be the same, right?

Usually yes but with transit you are paying for global
connectivity/reachability, for an extreme comparison, I only need to
exchange 50mbps of data with Facebook before they will peering with me
(last time I checked), I'm not going to put a 100Mbps link into a port that
can do 10G. So a direct transit feed is more commercially viable for me as
a consumer than private or public peering unless a particular business
demand can cover the cost risk of peering.

James.

From marco at paesani.it  Thu Dec 31 16:46:39 2015
From: marco at paesani.it (Marco Paesani)
Date: Thu, 31 Dec 2015 17:46:39 +0100
Subject: Whatsapp issue ?
Message-ID: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>

Hi,
here in Italy WA don't working, anybody know why ?
Thanks !
Ciao,
-- 

Marco Paesani
MPAE Srl

Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: marco at paesani.it

From dovid at telecurve.com  Thu Dec 31 16:53:29 2015
From: dovid at telecurve.com (Dovid Bender)
Date: Thu, 31 Dec 2015 16:53:29 +0000
Subject: Whatsapp issue ?
Message-ID: <1079676325-1451580809-cardhu_decombobulator_blackberry.rim.net-511267422-@b11.c1.bise6.blackberry>

Just came up here in NJ.


------Original Message------
From: Marco Paesani
Sender: NANOG
To: nanog
ReplyTo: marco at paesani.it
Subject: Whatsapp issue ?
Sent: Dec 31, 2015 11:46

Hi,
here in Italy WA don't working, anybody know why ?
Thanks !
Ciao,
-- 

Marco Paesani
MPAE Srl

Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: marco at paesani.it

Regards,

Dovid

From marco at paesani.it  Thu Dec 31 17:09:29 2015
From: marco at paesani.it (Marco Paesani)
Date: Thu, 31 Dec 2015 18:09:29 +0100
Subject: Whatsapp issue ?
In-Reply-To: <1079676325-1451580809-cardhu_decombobulator_blackberry.rim.net-511267422-@b11.c1.bise6.blackberry>
References: <1079676325-1451580809-cardhu_decombobulator_blackberry.rim.net-511267422-@b11.c1.bise6.blackberry>
Message-ID: <CAOAnmEikOB7yWoLPyTYGTuhMvac8LkEhhV9siMQjb_LEEJjGkQ@mail.gmail.com>

Now WA is UP again in Italy
Ciao,
Marco

2015-12-31 17:53 GMT+01:00 Dovid Bender <dovid at telecurve.com>:
> Just came up here in NJ.
>
>
> ------Original Message------
> From: Marco Paesani
> Sender: NANOG
> To: nanog
> ReplyTo: marco at paesani.it
> Subject: Whatsapp issue ?
> Sent: Dec 31, 2015 11:46
>
> Hi,
> here in Italy WA don't working, anybody know why ?
> Thanks !
> Ciao,
> --
>
> Marco Paesani
> MPAE Srl
>
> Skype: mpaesani
> Mobile: +39 348 6019349
> Success depends on the right choice !
> Email: marco at paesani.it
>
> Regards,
>
> Dovid



-- 

Marco Paesani
MPAE Srl

Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: marco at paesani.it

From evelio at thousandeyes.com  Thu Dec 31 18:39:38 2015
From: evelio at thousandeyes.com (Evelio Vila)
Date: Thu, 31 Dec 2015 10:39:38 -0800
Subject: Netflix stuffing data on pipe
In-Reply-To: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
References: <6317C965-2A8D-4806-B146-B137AC6ED7B3@indigowireless.com>
Message-ID: <CA+78=sHojjzm3uWmG00GQ9UnFu1h4PGYyLf7HE6cdooSSRBAJw@mail.gmail.com>

It is actually buffer-based, as it picks the video rate as a function of
the current buffer occupancy.

See here http://yuba.stanford.edu/~nickm/papers/sigcomm2014-video.pdf

--
evelio

On Tue, Dec 29, 2015 at 6:56 PM, Matt Hoppes <mhoppes at indigowireless.com>
wrote:

> Has anyone else observed Netflix sessions attempting to come into customer
> CPE devices at well in excess of the customers throttled plan?
>
> I'm not talking error retries on the line. I'm talking like two to three
> times in excess of what the customers CPE device can handle.
>
> I'm observing massive buffer overruns in some of our switches that appear
> to be directly related to this. And I can't figure out what possible good
> purpose Netflix would have for attempting to do this.
>
> Curious if anyone else has seen it?

From linoan at hotmail.com  Thu Dec 31 17:01:12 2015
From: linoan at hotmail.com (Emanuel Linoan)
Date: Thu, 31 Dec 2015 14:01:12 -0300
Subject: Whatsapp issue ?
In-Reply-To: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>
References: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>
Message-ID: <BLU405-EAS253EEB682EE7F360F9F5977C4FE0@phx.gbl>

Whatsapp down in SE-Brazil too.

Enviado do meu iPhone

> Em 31/12/2015, ?s 13:48, Marco Paesani <marco at paesani.it> escreveu:
> 
> Hi,
> here in Italy WA don't working, anybody know why ?
> Thanks !
> Ciao,
> -- 
> 
> Marco Paesani
> MPAE Srl
> 
> Skype: mpaesani
> Mobile: +39 348 6019349
> Success depends on the right choice !
> Email: marco at paesani.it

From idafe.houghton at gmail.com  Thu Dec 31 18:49:33 2015
From: idafe.houghton at gmail.com (Idafe Houghton)
Date: Thu, 31 Dec 2015 19:49:33 +0100
Subject: Whatsapp issue ?
In-Reply-To: <BLU405-EAS253EEB682EE7F360F9F5977C4FE0@phx.gbl>
References: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>
 <BLU405-EAS253EEB682EE7F360F9F5977C4FE0@phx.gbl>
Message-ID: <1451587773.2712.2@smtp.gmail.com>

Somebody has told me if I knew that WA it's down.

I knew, but not that it also affected Barcelona, Spain.

Well, kind of expected. No surprise.

On jue, dic 31, 2015 at 6:01 , Emanuel Linoan <linoan at hotmail.com> 
wrote:
> Whatsapp down in SE-Brazil too.
> 
> Enviado do meu iPhone
> 
>>  Em 31/12/2015, ?s 13:48, Marco Paesani <marco at paesani.it> escreveu:
>> 
>>  Hi,
>>  here in Italy WA don't working, anybody know why ?
>>  Thanks !
>>  Ciao,
>>  --
>> 
>>  Marco Paesani
>>  MPAE Srl
>> 
>>  Skype: mpaesani
>>  Mobile: +39 348 6019349
>>  Success depends on the right choice !
>>  Email: marco at paesani.it

From baconzombie at gmail.com  Thu Dec 31 23:33:11 2015
From: baconzombie at gmail.com (Bacon Zombie)
Date: Fri, 1 Jan 2016 00:33:11 +0100
Subject: Whatsapp issue ?
In-Reply-To: <1451587773.2712.2@smtp.gmail.com>
References: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>
 <BLU405-EAS253EEB682EE7F360F9F5977C4FE0@phx.gbl>
 <1451587773.2712.2@smtp.gmail.com>
Message-ID: <CAPz7E52cq2K3aPTgNpOo-O7rLNaLFtpzx-ysCD8ggJYSsQG=WA@mail.gmail.com>

Its kinda working in Berlin.

Probably due to everyone messaging "Happy New 0xB33r".
On 31 Dec 2015 7:53 pm, "Idafe Houghton" <idafe.houghton at gmail.com> wrote:

> Somebody has told me if I knew that WA it's down.
>
> I knew, but not that it also affected Barcelona, Spain.
>
> Well, kind of expected. No surprise.
>
> On jue, dic 31, 2015 at 6:01 , Emanuel Linoan <linoan at hotmail.com> wrote:
>
>> Whatsapp down in SE-Brazil too.
>>
>> Enviado do meu iPhone
>>
>>  Em 31/12/2015, ?s 13:48, Marco Paesani <marco at paesani.it> escreveu:
>>>
>>>  Hi,
>>>  here in Italy WA don't working, anybody know why ?
>>>  Thanks !
>>>  Ciao,
>>>  --
>>>
>>>  Marco Paesani
>>>  MPAE Srl
>>>
>>>  Skype: mpaesani
>>>  Mobile: +39 348 6019349
>>>  Success depends on the right choice !
>>>  Email: marco at paesani.it
>>>
>>

From nelson.oseh at uniben.edu  Thu Dec 31 19:59:37 2015
From: nelson.oseh at uniben.edu (Nelson Oseh)
Date: Thu, 31 Dec 2015 20:59:37 +0100
Subject: Whatsapp issue ?
In-Reply-To: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>
References: <CAOAnmEjz7q7pAqaOJ1XqyeXgYnXrUN5WDJ4ypE60-hk5UfDxCQ@mail.gmail.com>
Message-ID: <CAEQ-NDzc+Y5Psf26jiTOBH+tCxPYg=_A+tBpSYzdCVE5_5+Asg@mail.gmail.com>

Likewise here in Nigeria. WA has been down for a couple of hours now.
On Dec 31, 2015 5:46 PM, "Marco Paesani" <marco at paesani.it> wrote:

> Hi,
> here in Italy WA don't working, anybody know why ?
> Thanks !
> Ciao,
> --
>
> Marco Paesani
> MPAE Srl
>
> Skype: mpaesani
> Mobile: +39 348 6019349
> Success depends on the right choice !
> Email: marco at paesani.it
>

-- 
"Disclaimer"
??This communication is intended for the above named person and is 
confidential and / or legally privileged. Any opinion(s) expressed in this 
communication are not necessarily those of UniBen (University of Benin). If 
it has come to you in error you must take no action based upon it, nor must 
you print it, copy it, forward it, or show it to anyone. Please delete and 
destroy the e-mail and any attachments and inform the sender immediately. 
Thank you.
UniBen is not responsible for the political, religious, racial or partisan 
opinion in any correspondence conducted by its domain users. Therefore, any 
such opinion expressed, whether explicitly or implicitly, in any said 
correspondence is not to be interpreted as that of UniBen.
UniBen may monitor all incoming and outgoing e-mails in line with UniBen 
business practice. Although UniBen has taken steps to ensure that e-mails 
and attachments are free from any virus, we advise that, in keeping with 
best business practice, the recipient must ensure they are actually virus 
free.

From cburwell at gmail.com  Thu Dec 31 20:55:24 2015
From: cburwell at gmail.com (Chris Burwell)
Date: Thu, 31 Dec 2015 15:55:24 -0500
Subject: VPLS Providers
Message-ID: <CAC8zsjOxLt0emrrt=6voeasfO1DXZZ1VVB6AmL4HcBS2Gj-GhA@mail.gmail.com>

Hi NANOG,

I'm looking to solicit feedback on VPLS providers. The requirement is for
connectivity among about ten sites in North America, however feedback for
providers that also extend service to EMEA and APAC would also be welcome.

All types of feedback are appreciated (good, bad, and anything in between).

Thanks,

- Chris