From jason at lixfeld.ca  Mon Apr  1 01:36:03 2013
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Sun, 31 Mar 2013 21:36:03 -0400
Subject: BCP38 tester?
In-Reply-To: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
Message-ID: <84AB044A-F56D-40F6-990C-938F2DD65514@lixfeld.ca>


On 2013-03-31, at 10:48 AM, Jay Ashworth <jra at baylink.com> wrote:

> Is there a program which users can run on an end-site workstation which
> would test whether they are being some link which is doing BCP38, or some
> related type of source-address ingress filtering?
> 
> I'm hoping for something that could be downloaded by users and run, and
> try to forge a few packets to somewhere useful, which could be logged 
> somehow in conjunction with some unforged packets containing a traceroute, 
> so we could build up a database of leaky networks.
> 
> On a related topic, while I know GRC Research's Steve Gibson is a bit of
> a polarizing personality, he does have a fairly sizable consumer audience,
> and might be a great distribution venue for such a thing.
> 
> Or, perhaps, is there someone on here from Ookla?
> 
> Patrick?  Could Akamai be persuaded to take an interest in this as a 
> research project?


From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period.  Most network operators are probably either too inexperienced to understand or too lazy to care.

I believe that most everyone has a CPE of some sort, whether their service is resi or commercial.  So, what about shifting the focus to the CPE manufacturers?  They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever.  Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?

From jared at puck.nether.net  Mon Apr  1 01:46:36 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Sun, 31 Mar 2013 21:46:36 -0400
Subject: Open Resolver Problems
In-Reply-To: <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
Message-ID: <70CE39F8-0981-4EAB-BB40-61F56489177A@puck.nether.net>


On Mar 31, 2013, at 5:09 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On 3/29/13, Scott Noel-Hemming <frogstarr78 at gmail.com> wrote:
>>> Some of us have both publicly-facing authoritative DNS, and inward
>>> facing recursive servers that may be open resolvers but can't be
>>> found via NS entries (so the IP addresses of those aren't exactly
>>> publicly available info).
>> Sounds like your making the faulty assumption that an attacker would use
>> normal means to find your servers.
> 
> A distributed scan of the entire IPv4 space for all internet IPs
> running open DNS servers is fairly doable;  actually a long term scan
> taking 100 to 200 days of continuous DNS scanning  is completely
> trivial.

I updated the openresolverproject.org data in less than 8 hours.

The system would scan 1.0.0.0 , 1.0.0.1 ? in sequence.

Next time it runs, it's going to use a slightly different method which may expose a few more servers.

The 2013-Mar-31 data showed:

2,471,484  servers returned refused. (369k change downward)
20,675,738 with correct answer in packet.

If I extrapolate 369k/week closing, everything will be closed in about a year.

(Compared to 2.1 mil refused the week before; compared to 21.4 Million with correct answer in packet the week before).

I know many people are working on their respective hosts and/or network to close things down.

Many thanks to everyone that is treating this as a critical issue to close these hosts.

- jared

From jason at lixfeld.ca  Mon Apr  1 01:50:52 2013
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Sun, 31 Mar 2013 21:50:52 -0400
Subject: BCP38 tester?
In-Reply-To: <CAM91edgocU_EGUx8V_viX7RbfBA9bWgGyeBC6e-PdrsN9bDLUA@mail.gmail.com>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
 <84AB044A-F56D-40F6-990C-938F2DD65514@lixfeld.ca>
 <CAM91edig3KiAcTzG+F=iS9mh6FVUMNvvskeeyE9rF-cf-iGwQA@mail.gmail.com>
 <CAM91edgocU_EGUx8V_viX7RbfBA9bWgGyeBC6e-PdrsN9bDLUA@mail.gmail.com>
Message-ID: <4FB22BAD-0943-488A-8451-FC7DE6601839@lixfeld.ca>


On 2013-03-31, at 9:43 PM, Peter Baldridge <petebaldridge at gmail.com> wrote:

> I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial.  So it's questionable how useful this is.  It seems like it just adds cost to for customers that can't spoof a packet to save their lives.

Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets.

> On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason at lixfeld.ca> wrote:
> 
> On 2013-03-31, at 10:48 AM, Jay Ashworth <jra at baylink.com> wrote:
> 
> > Is there a program which users can run on an end-site workstation which
> > would test whether they are being some link which is doing BCP38, or some
> > related type of source-address ingress filtering?
> >
> > I'm hoping for something that could be downloaded by users and run, and
> > try to forge a few packets to somewhere useful, which could be logged
> > somehow in conjunction with some unforged packets containing a traceroute,
> > so we could build up a database of leaky networks.
> >
> > On a related topic, while I know GRC Research's Steve Gibson is a bit of
> > a polarizing personality, he does have a fairly sizable consumer audience,
> > and might be a great distribution venue for such a thing.
> >
> > Or, perhaps, is there someone on here from Ookla?
> >
> > Patrick?  Could Akamai be persuaded to take an interest in this as a
> > research project?
> 
> 
> From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period.  Most network operators are probably either too inexperienced to understand or too lazy to care.
> 
> I believe that most everyone has a CPE of some sort, whether their service is resi or commercial.  So, what about shifting the focus to the CPE manufacturers?  They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever.  Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?



From jlewis at lewis.org  Mon Apr  1 01:52:30 2013
From: jlewis at lewis.org (Jon Lewis)
Date: Sun, 31 Mar 2013 21:52:30 -0400 (EDT)
Subject: BCP38 tester?
In-Reply-To: <Pine.LNX.4.61.1303311330210.26706@soloth.lewis.org>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
 <CANQy6FaNdYTfCzWi2V2S39ps6a8rHBxw--0srDAHZh-dLr5vmQ@mail.gmail.com>
 <Pine.LNX.4.61.1303311330210.26706@soloth.lewis.org>
Message-ID: <Pine.LNX.4.61.1303312150450.26706@soloth.lewis.org>

Someone privately emailed me asking about the problems I had.  When I 
looked at it some more, I found the autoconf error was just very 
misleading, and my build environment was incomplete.  With all the right 
tools installed, it built just fine on the Ubuntu 12.04 64-bit machine I 
was playing on.

On Sun, 31 Mar 2013, Jon Lewis wrote:

> They should updated their autoconf.  It fails on modern 64-bit Linux.
>
> On Sun, 31 Mar 2013, Paul Ferguson wrote:
>
>> You mean like this? :-)
>> 
>> http://spoofer.csail.mit.edu/
>> 
>> - ferg
>> 
>> 
>> On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth <jra at baylink.com> wrote:
>> 
>>> Is there a program which users can run on an end-site workstation which
>>> would test whether they are being some link which is doing BCP38, or some
>>> related type of source-address ingress filtering?
>>> 
>>> I'm hoping for something that could be downloaded by users and run, and
>>> try to forge a few packets to somewhere useful, which could be logged
>>> somehow in conjunction with some unforged packets containing a traceroute,
>>> so we could build up a database of leaky networks.
>>> 
>>> On a related topic, while I know GRC Research's Steve Gibson is a bit of
>>> a polarizing personality, he does have a fairly sizable consumer audience,
>>> and might be a great distribution venue for such a thing.
>>> 
>>> Or, perhaps, is there someone on here from Ookla?
>>> 
>>> Patrick?  Could Akamai be persuaded to take an interest in this as a
>>> research project?
>>> 
>>> Cheers,
>>> -- jra
>>> --
>>> Jay R. Ashworth                  Baylink 
>>> jra at baylink.com
>>> Designer                     The Things I Think                       RFC 
>>> 2100
>>> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover 
>>> DII
>>> St Petersburg FL USA               #natog                      +1 727 647 
>>> 1274
>>> 
>> 
>> 
>> 
>> --
>> "Fergie", a.k.a. Paul Ferguson
>> fergdawgster(at)gmail.com
>> 
>
> ----------------------------------------------------------------------
> Jon Lewis, MCP :)           |  I route
>                             |  therefore you are
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>

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


From ahebert at pubnix.net  Mon Apr  1 02:03:43 2013
From: ahebert at pubnix.net (Alain Hebert)
Date: Sun, 31 Mar 2013 22:03:43 -0400
Subject: BCP38 tester?
In-Reply-To: <4FB22BAD-0943-488A-8451-FC7DE6601839@lixfeld.ca>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
 <84AB044A-F56D-40F6-990C-938F2DD65514@lixfeld.ca>
 <CAM91edig3KiAcTzG+F=iS9mh6FVUMNvvskeeyE9rF-cf-iGwQA@mail.gmail.com>
 <CAM91edgocU_EGUx8V_viX7RbfBA9bWgGyeBC6e-PdrsN9bDLUA@mail.gmail.com>
 <4FB22BAD-0943-488A-8451-FC7DE6601839@lixfeld.ca>
Message-ID: <5158EAFF.30503@pubnix.net>

  On 03/31/13 21:50, Jason Lixfeld wrote:
> On 2013-03-31, at 9:43 PM, Peter Baldridge <petebaldridge at gmail.com> wrote:
>
>> I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial.  So it's questionable how useful this is.  It seems like it just adds cost to for customers that can't spoof a packet to save their lives.
> Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets.
>
>> On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason at lixfeld.ca> wrote:
>>
>> On 2013-03-31, at 10:48 AM, Jay Ashworth <jra at baylink.com> wrote:
>>
>>> Is there a program which users can run on an end-site workstation which
>>> would test whether they are being some link which is doing BCP38, or some
>>> related type of source-address ingress filtering?
>>>
>>> I'm hoping for something that could be downloaded by users and run, and
>>> try to forge a few packets to somewhere useful, which could be logged
>>> somehow in conjunction with some unforged packets containing a traceroute,
>>> so we could build up a database of leaky networks.
>>>
>>> On a related topic, while I know GRC Research's Steve Gibson is a bit of
>>> a polarizing personality, he does have a fairly sizable consumer audience,
>>> and might be a great distribution venue for such a thing.
>>>
>>> Or, perhaps, is there someone on here from Ookla?
>>>
>>> Patrick?  Could Akamai be persuaded to take an interest in this as a
>>> research project?
>>
>> From my perspective, 99% of end-users probably don't understand (or care) that their provider might be responsible for initiating or precipitating a DDoS attacks, period.  Most network operators are probably either too inexperienced to understand or too lazy to care.
>>
>> I believe that most everyone has a CPE of some sort, whether their service is resi or commercial.  So, what about shifting the focus to the CPE manufacturers?  They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever.  Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?
>>

    An easy target would be anti-virus/trojan/security software
providers that could add a BCP38 check to their software =D

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443



From bill at herrin.us  Mon Apr  1 02:19:44 2013
From: bill at herrin.us (William Herrin)
Date: Sun, 31 Mar 2013 22:19:44 -0400
Subject: Tier 2 ingress filtering
In-Reply-To: <CAOmxzdwOqvf5L-t8pMKaMma154h94XpSfu=J1WjeWzF2hDAOmg@mail.gmail.com>
References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com>
 <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no>
 <CAP-guGVRYmqVU7edMSW=M-wJOQSoPOJq9V0MEtgk7bMQo1YJ6w@mail.gmail.com>
 <20130330030415.GS14491@haller.ws>
 <CAOmxzdzG_z75rQ6Ut=yp7VXwz_U7DbxRAYnnvZ9T_O8hh5NK9w@mail.gmail.com>
 <CAP-guGUrRzQb+GHwZRcM+LZs_2ZXfqfuR7t3MTjiBUhXxDnTCA@mail.gmail.com>
 <CAOmxzdwOqvf5L-t8pMKaMma154h94XpSfu=J1WjeWzF2hDAOmg@mail.gmail.com>
Message-ID: <CAP-guGVzxZ81zpM0zY2Ok4PGqVreZ4hyCW7_7vOYCjgeXVwOvA@mail.gmail.com>

Hi Alejandro,

Also inline.

On Sat, Mar 30, 2013 at 10:17 PM, Alejandro Acosta
<alejandroacostaalamo at gmail.com> wrote:
> Hi William,
>   Thanks for your response, my comments below:
>
> On 3/30/13, William Herrin <bill at herrin.us> wrote:
> > On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta
> > <alejandroacostaalamo at gmail.com> wrote:
> >> On 3/29/13, Patrick <nanog at haller.ws> wrote:
> >>> On 2013-03-29 14:49, William Herrin wrote:
> >>>> I've long thought router vendors should introduce a configuration
> >>>> option to specify the IP address from which ICMP errors are emitted
> >>>> rather than taking the interface address from which the packet causing
> >>>> the error was received.
> >>>
> >>> Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip
> >>> unnumbered loop0' everywhere. ;)
> >>
> >> Why do you think it will be better?, can you explain?
> >
> > Hi Alejandro,
> >
> > Consider the alternatives:
> >
> > 1. Provide a router configuration option (per router and/or per
> > interface) to emit ICMP error messages from a specified IP address
> > rather than the interface address.
>
> I imagine that and it sounds terrific. I guess at least this option
> should come disabled by default.
>
> > 2. At every border, kick packets without an Internet-legitimate source
> > address up to the slow path for network address translation to a
> > source address which is valid.
>
> IMHO this can be achieved with the current behaviour.

If you don't mind the router crashing. There's too much trash traffic
with bad source addresses, even when no one is under attack. You kick
it up to the main CPU, you overwhelm the router.


> > 3. Design your network so that any router with at least one network
> > interface whose IP address is not valid on the Internet has exactly
> > the same MTU on every interface, and at least an MTU of 1500 on all of
> > them, guaranteeing that the router will never emit a
> > fragmentation-needed message. And do this consistently. Every time.
>
> If you have pmtud enabled you won't need this every time

Clients effectively always enable path MTU discovery.  If the ICMP
error message your router generates when it discovers the MTU problem
comes from an IP address that can't leave your system without being
filtered then path MTU discovery fails absolutely. That path is a
black hole that mysteriously swallows TCP connections.

If you can't prevent mis-addressed ICMP error messages from leaving
your system then you must prevent the conditions under which path MTU
discovery would cause an ICMP error message to be generated.
Practically speaking, that means you guarantee an MTU of at least 1500
bytes on every link and no endpoint MTU over 1500 bytes.


> > 4. Redesign TCP so it doesn't rely on ICMP destination unreachable
> > messages to determine path MTU and get your new design deployed into
> > every piece of software on the Internet.
>
> You will have the same problem using only one output interface for
> ICMP error/messages. Of course based in your comments you mean you
> will need to troubleshoot this interface only once.

With #4, path mtu discovery no longer relies on ICMP error messages.
The endpoint client would have to reduce the MSS on retransmission and
use the pattern of lost packets to acknowledgements to find path MTU
on paths with an ICMP black hole.

For the sake of robustness, this is something we probably should think
seriously about adding to the TCP protocol. However, that's a long
plan, two decades at least. It isn't something that could deliver a
complete mitigation in the next release of the software, the way
option 1 does.


> > 5. Accept that TCP will break unexpectedly due to lost
> > fragmentation-needed messages, presenting as a particularly nasty and
> > intermittent failure that's hard to track and harder to fix.
>
> Same answer as in 3.

See me response to #3.

Regards,
Bill Herrin



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


From jra at baylink.com  Mon Apr  1 02:34:49 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 31 Mar 2013 22:34:49 -0400 (EDT)
Subject: BCP38 tester?
In-Reply-To: <5158EAFF.30503@pubnix.net>
Message-ID: <10659463.391.1364783689622.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Alain Hebert" <ahebert at pubnix.net>

> An easy target would be anti-virus/trojan/security software
> providers that could add a BCP38 check to their software =D

Yes, but penetration is a problem, which is why I was thinking about
people like YouTube, Ookla, and the like.

Any Flash app that lots of people run frequently.  Assuming those apps
could generate the packets, which, on reflection, I would bet they can't.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From jra at baylink.com  Mon Apr  1 02:32:28 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 31 Mar 2013 22:32:28 -0400 (EDT)
Subject: BCP38 tester?
In-Reply-To: <84AB044A-F56D-40F6-990C-938F2DD65514@lixfeld.ca>
Message-ID: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jason Lixfeld" <jason at lixfeld.ca>

> I believe that most everyone has a CPE of some sort, whether their
> service is resi or commercial. So, what about shifting the focus to
> the CPE manufacturers? They bend to technology and/or market pressures
> by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE,
> RFC1483, etc. to their respective products in to satisfy technology
> limitations or security concerns or whatever. Why can't they help the
> cause by implementing some sort of RFC'ified BCP38 thing?

This thought crossed my mind earlier today, when I asked Jeff if IP-forged
packets would make it through a NAT, outbound.  He said no (I think), but 
I'm not entirely sure that's right.

While that would be egress filtering, from the POV of the home-LAN, it
would still help in the trojan-horse-bot situation, as long as it couldn't
be opened up via something like PPTP, and would thus still be useful,
to some extent, sure.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From Valdis.Kletnieks at vt.edu  Mon Apr  1 03:16:20 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 31 Mar 2013 23:16:20 -0400
Subject: Open Resolver Problems
In-Reply-To: Your message of "Sun, 31 Mar 2013 16:09:35 -0500."
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
Message-ID: <128114.1364786180@turing-police.cc.vt.edu>

On Sun, 31 Mar 2013 16:09:35 -0500, Jimmy Hess said:
> On 3/29/13, Scott Noel-Hemming <frogstarr78 at gmail.com> wrote:
> >> Some of us have both publicly-facing authoritative DNS, and inward
> >> facing recursive servers that may be open resolvers but can't be
> >> found via NS entries (so the IP addresses of those aren't exactly
> >> publicly available info).
> > Sounds like your making the faulty assumption that an attacker would use
> > normal means to find your servers.
>
> A distributed scan of the entire IPv4 <SNIP>

Stop right there.

Anybody who is looking at this as an IPv4 issue is woefully misinformed
about the nature of the problem.


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

From kauer at biplane.com.au  Mon Apr  1 03:44:11 2013
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 01 Apr 2013 14:44:11 +1100
Subject: BCP38 tester?
In-Reply-To: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
Message-ID: <1364787851.2136.7.camel@karl>

On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
> This thought crossed my mind earlier today, when I asked Jeff if IP-forged
> packets would make it through a NAT, outbound.  He said no (I think), but 
> I'm not entirely sure that's right.

Welll - the packets might make it out, and be transmitted into the
Internet, but they would have a legitimate source address, namely an
outside address of the NAT router. A side effect of NAT is to clamp the
source address range of outbound packets to the configured NAT outside
address range.

Regards, K.

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

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017



From marka at isc.org  Mon Apr  1 04:07:54 2013
From: marka at isc.org (Mark Andrews)
Date: Mon, 01 Apr 2013 15:07:54 +1100
Subject: BCP38 tester?
In-Reply-To: Your message of "Mon, 01 Apr 2013 14:44:11 +1100."
 <1364787851.2136.7.camel@karl>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
Message-ID: <20130401040755.3032931B72A5@drugs.dv.isc.org>


In message <1364787851.2136.7.camel at karl>, Karl Auer writes:
> On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
> > This thought crossed my mind earlier today, when I asked Jeff if IP-forged
> > packets would make it through a NAT, outbound.  He said no (I think), but 
> > I'm not entirely sure that's right.
> 
> Welll - the packets might make it out, and be transmitted into the
> Internet, but they would have a legitimate source address, namely an
> outside address of the NAT router. A side effect of NAT is to clamp the
> source address range of outbound packets to the configured NAT outside
> address range.
> 
> Regards, K.

It depends on how the nat is configured.

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


From kauer at biplane.com.au  Mon Apr  1 04:54:51 2013
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 01 Apr 2013 15:54:51 +1100
Subject: BCP38 tester?
In-Reply-To: <20130401040755.3032931B72A5@drugs.dv.isc.org>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
 <20130401040755.3032931B72A5@drugs.dv.isc.org>
Message-ID: <1364792091.2136.15.camel@karl>

On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote:
> In message <1364787851.2136.7.camel at karl>, Karl Auer writes:
> > A side effect of NAT is to clamp the source address range
> > of outbound packets to the configured NAT outside address
> > range.
> It depends on how the nat is configured.

OK - how does one configure NAT so that the source addresses of outbound
packets are NOT clamped to a configured range on the outside of the NAT
device? Given this general scenario, of course:

   Inside                                      Outside
   Nasty spoofing scum ----> NAT ---> helpless victims
                          Outbound --->

Honest question - just 'because I don't see it doesn't mean it isn't
possible :-) My NAT configs have generally been pretty plain vanilla.

Regards, K.

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

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017



From mysidia at gmail.com  Mon Apr  1 06:31:41 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 1 Apr 2013 01:31:41 -0500
Subject: BCP38 tester?
In-Reply-To: <1364792091.2136.15.camel@karl>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
 <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
Message-ID: <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>

On 3/31/13, Karl Auer <kauer at biplane.com.au> wrote:
> On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote:
>> In message <1364787851.2136.7.camel at karl>, Karl Auer writes:
>> > A side effect of NAT is to clamp the source address range

>> It depends on how the nat is configured.
> OK - how does one configure NAT so that the source addresses of outbound
> packets are NOT clamped to a configured range on the outside of the NAT
> device? Given this general scenario, of course:

He said it depends on how NAT is configured;  but really, before it
depends on that -- it first depends on what kind of device is used,
and what kind of NAT is being implemented.

In some implementations, only certain ranges of source IP addresses
are subject to translation.    They might be NAT'ing based on network,
interface, or access-list.

>    Inside                                      Outside
>    Nasty spoofing scum ----> NAT ---> helpless victims
>                           Outbound --->


It occurs that if the CPE are /truly/  clamping the Source address
space,  then essence,
BCP38  is essentially happening at the CPE.

If your packet source address is clamped, then, by definition a host
can't spoof a packet, right;  so maybe that's not a host that needs to
be tested further  (the upstream provider might still have no BCP38,
it's just not exposed to that particular host).

Unless, of course, there are protocols your NAT device passes
unaltered such as possibly ICMP,  or  ICMPv6,   in case   NAT only
applies to IPv4,  a host behind the NAT might still be able to spoof
IPv6  source addresses.

--
-JH


From rdobbins at arbor.net  Mon Apr  1 07:24:07 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 1 Apr 2013 07:24:07 +0000
Subject: BCP38 tester?
In-Reply-To: <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
 <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
Message-ID: <265EF1F6-3F46-46A6-BFFD-E997296FEFF1@arbor.net>


On Apr 1, 2013, at 1:31 PM, Jimmy Hess wrote:

> If your packet source address is clamped, then, by definition a host can't spoof a packet, right;  so maybe that's not a host that needs to
> be tested further  (the upstream provider might still have no BCP38, it's just not exposed to that particular host).

Folks should implement anti-spoofing southbound of their NATs, using uRPF, ACLs, IP Source Guard, Cable IP Source Verify, or whatever, in order to keep botted hosts attempting to launch outbound/crossbound spoofed DDoS attacks (such as spoofed SYN-floods) from filling up the NAT translation-table and making it fall over, thus creating an outage for everything behind the NAT.  I've seen this happen many times, especially in the mobile/fixed wireless space.

Likewise, they should implement anti-spoofing northbound, eastbound, and westbound of the NAT (eastbound and westbound assume it's a network of some scope), so that nothing else on their networks can send spoofed packets to external networks.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From kauer at biplane.com.au  Mon Apr  1 08:02:40 2013
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 01 Apr 2013 19:02:40 +1100
Subject: BCP38 tester?
In-Reply-To: <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
 <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
Message-ID: <1364803360.2136.54.camel@karl>

On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote:
> On 3/31/13, Karl Auer <kauer at biplane.com.au> wrote:
> > OK - how does one configure NAT so that the source addresses of outbound
> > packets are NOT clamped to a configured range on the outside of the NAT
> > device? Given this general scenario, of course:
> 
> He said it depends on how NAT is configured
> [...]
> In some implementations, only certain ranges of source IP addresses
> are subject to translation.

Um - if no address translation takes place, then, by definition, NAT has
not taken place.

So it may well be that a particular device, capable of doing NAT and
other things, of NATting some packets but not others, may permit
spoofed-because-not-NATted outbound packets, but I remain unconvinced
that a spoofed packet can make it through a NAT process and head
outbound without getting its source address clamped to a configured
range of outside addresses.

Now I'm imagining a NAT process that translates only *destination*
addresses - hm, is there such a beast?

Continuing to seek enlightenment...

Regards, K.

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

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017



From rdobbins at arbor.net  Mon Apr  1 08:34:04 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 1 Apr 2013 08:34:04 +0000
Subject: BCP38 tester?
In-Reply-To: <1364803360.2136.54.camel@karl>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
 <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
 <1364803360.2136.54.camel@karl>
Message-ID: <BA1E66AB-E1E8-49F4-87F9-9ECA4F6F1051@arbor.net>


On Apr 1, 2013, at 3:02 PM, Karl Auer wrote:

> Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast?

Sure - you just have rules in place which map the destination IPs of incoming packets, based upon classification criteria expressed in the NAT config, to the destination address(es) of choice.

Those who ill-advisedly run servers behind NATs use this functionality.

You can also turn a NAT with this type of configuration 'upside-down', so that the 'public' side is nearest the traffic sources, if desired.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From mysidia at gmail.com  Mon Apr  1 09:37:21 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 1 Apr 2013 04:37:21 -0500
Subject: BCP38 tester?
In-Reply-To: <1364803360.2136.54.camel@karl>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl>
 <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
 <1364803360.2136.54.camel@karl>
Message-ID: <CAAAwwbWMSoWBvPnD5_tJhV67hcjnsa=Grij-k2PgUOn19Ac0=A@mail.gmail.com>

On 4/1/13, Karl Auer <kauer at biplane.com.au> wrote:
> So it may well be that a particular device, capable of doing NAT and
> other things, of NATting some packets but not others, may permit

Yes.  Many NAT devices of reasonable quality are fully capable of such things.

And  skipping NAT or NAT'ing the source IP address on the outgoing
interface to the same as the source IP address the packet had on the
incoming interface,    is the likely default,  when  NAT has been
configured based on source IP address range,  on some devices.

> spoofed-because-not-NATted outbound packets, but I remain unconvinced
> that a spoofed packet can make it through a NAT process and head
> outbound without getting its source address clamped to a configured
> range of outside addresses.

Ah, but did you actually test your guess on a reasonably large variety
of NAT platforms?
It just takes 1 instance of the right platform to be in significant
use for something to be different than expected.

I remain unconvinced that all CPEs in all common configurations will
clamp the source address to a legitimate one in all cases.

It would just be way too much luck and convenience for that to happen
by coincidence.


> Now I'm imagining a NAT process that translates only *destination*
> addresses - hm, is there such a beast?

Of course there is...  in some implementations  you may need two NAT
rules to define a 1:1; a source NAT rule, and a destination NAT rule;
if you define only   the Source NAT rule, you just translate the
source IP address ranges selected to the translation IP address
range(s) selected for outgoing connections, and new incoming
connections are not translated;  if you define only the DNAT rule, you
translate only the WAN interface destination IP for incoming
connections,  and outgoing connections are not translated.


In various implementations
 you can have full-cone NAT, address-restricted cone NAT,
port-restricted cone NAT,  symmetric NAT,  and various combinations
and variations  (even different kinds of NAT in different directions),
 for each of source and destination address,  with or without storage
of a mapping for return traffic.

Different source or destination IP ranges or TCP/UDP ports might be
NAT'ed differently or not at all.

Not all implementations allow all possible useful NAT configurations.




> Continuing to seek enlightenment...
>
> Regards, K.
--
-JH


From ahebert at pubnix.net  Mon Apr  1 13:34:31 2013
From: ahebert at pubnix.net (Alain Hebert)
Date: Mon, 01 Apr 2013 09:34:31 -0400
Subject: BCP38 tester?
In-Reply-To: <1364803360.2136.54.camel@karl>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl> <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
 <1364803360.2136.54.camel@karl>
Message-ID: <51598CE7.2050008@pubnix.net>

On 04/01/13 04:02, Karl Auer wrote:
> On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote:
>> On 3/31/13, Karl Auer <kauer at biplane.com.au> wrote:
>>> OK - how does one configure NAT so that the source addresses of outbound
>>> packets are NOT clamped to a configured range on the outside of the NAT
>>> device? Given this general scenario, of course:
>> He said it depends on how NAT is configured
>> [...]
>> In some implementations, only certain ranges of source IP addresses
>> are subject to translation.
> Um - if no address translation takes place, then, by definition, NAT has
> not taken place.
>
> So it may well be that a particular device, capable of doing NAT and
> other things, of NATting some packets but not others, may permit
> spoofed-because-not-NATted outbound packets, but I remain unconvinced
> that a spoofed packet can make it through a NAT process and head
> outbound without getting its source address clamped to a configured
> range of outside addresses.
>
> Now I'm imagining a NAT process that translates only *destination*
> addresses - hm, is there such a beast?
>
> Continuing to seek enlightenment...
>
> Regards, K.
    While I was reading this... thinking that a NAT is a NAT is a NAT...
    ( I spend "some" time writing/porting NAT code in my youth )

    I'm sad to confirm that my spoof test was successful with a:

        . SageMCom modem+router, which is used by a big TelCo around my
part, for both their residential and commercial ADSL2+, VDSL customers.

        . 4 well know Tier-2(?) provider :( why I'm wasting time filling
up "paper" LoA if its only going to be used for BGP.

    But on the other hand... it failed on a:

        . Cisco (*cought* LinkSys) WRT54G loaded with DD-WRT v2.4-sp2
micro (2010/10/09);

        . SonicWall 2040 with 4.2.1.3;

        . Thompson SpeedTouch 516;

        ( I'm looking around for more CPE I could "use", for testing =D )

    PS: I'm not promoting the listed vendor, products.  Its only a quick
test with what I had on my hand during breakfast.

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443




From petebaldridge at gmail.com  Mon Apr  1 01:43:12 2013
From: petebaldridge at gmail.com (Peter Baldridge)
Date: Sun, 31 Mar 2013 18:43:12 -0700
Subject: BCP38 tester?
In-Reply-To: <CAM91edig3KiAcTzG+F=iS9mh6FVUMNvvskeeyE9rF-cf-iGwQA@mail.gmail.com>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
 <84AB044A-F56D-40F6-990C-938F2DD65514@lixfeld.ca>
 <CAM91edig3KiAcTzG+F=iS9mh6FVUMNvvskeeyE9rF-cf-iGwQA@mail.gmail.com>
Message-ID: <CAM91edgocU_EGUx8V_viX7RbfBA9bWgGyeBC6e-PdrsN9bDLUA@mail.gmail.com>

I can assume that If you are spoofing packets, resetting passwords on cpe
and replacing the box would be trivial.  So it's questionable how useful
this is.  It seems like it just adds cost to for customers that can't spoof
a packet to save their lives.
On Mar 31, 2013 6:37 PM, "Jason Lixfeld" <jason at lixfeld.ca> wrote:


On 2013-03-31, at 10:48 AM, Jay Ashworth <jra at baylink.com> wrote:

> Is there a program which users can run on an end-site workstation which
> would test whether they are being some link which is doing BCP38, or some
> related type of source-address ingress filtering?
>
> I'm hoping for something that could be downloaded by users and run, and
> try to forge a few packets to somewhere useful, which could be logged
> somehow in conjunction with some unforged packets containing a traceroute,
> so we could build up a database of leaky networks.
>
> On a related topic, while I know GRC Research's Steve Gibson is a bit of
> a polarizing personality, he does have a fairly sizable consumer audience,
> and might be a great distribution venue for such a thing.
>
> Or, perhaps, is there someone on here from Ookla?
>
> Patrick?  Could Akamai be persuaded to take an interest in this as a
> research project?


>From my perspective, 99% of end-users probably don't understand (or care)
that their provider might be responsible for initiating or precipitating a
DDoS attacks, period.  Most network operators are probably either too
inexperienced to understand or too lazy to care.

I believe that most everyone has a CPE of some sort, whether their service
is resi or commercial.  So, what about shifting the focus to the CPE
manufacturers?  They bend to technology and/or market pressures by bringing
things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to
their respective products in to satisfy technology limitations or security
concerns or whatever.  Why can't they help the cause by implementing some
sort of RFC'ified BCP38 thing?

From petebaldridge at gmail.com  Mon Apr  1 02:18:25 2013
From: petebaldridge at gmail.com (Peter Baldridge)
Date: Sun, 31 Mar 2013 19:18:25 -0700
Subject: BCP38 tester?
In-Reply-To: <4FB22BAD-0943-488A-8451-FC7DE6601839@lixfeld.ca>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
 <84AB044A-F56D-40F6-990C-938F2DD65514@lixfeld.ca>
 <CAM91edig3KiAcTzG+F=iS9mh6FVUMNvvskeeyE9rF-cf-iGwQA@mail.gmail.com>
 <CAM91edgocU_EGUx8V_viX7RbfBA9bWgGyeBC6e-PdrsN9bDLUA@mail.gmail.com>
 <4FB22BAD-0943-488A-8451-FC7DE6601839@lixfeld.ca>
Message-ID: <CAM91edgHj=vswkGUt1sWUwkULSQEZjYaHdidH8qVQ8nf=bBZrw@mail.gmail.com>

On Sun, Mar 31, 2013 at 6:50 PM, Jason Lixfeld <jason at lixfeld.ca> wrote:


> Maybe it's useful for the people who have no idea that their computers are
> infected by bots that spoof packets.
>

I guess I can see that.  You then have a question of implementation.
 Wouldn't a majority of those customers have a bridged connection with the
providers CPE being a transparent bridged modem.  So either a customer's
cheap router (good luck getting those guys to add a feature) would have to
do the check, or the modem would have to check with the router for ip and
then do packet inspection.

I'm not debating that this would be a good fix and eliminate the effect of
botnets, but the home router market isn't going to be influenced by
providers.  If it sells at a big box electronics store, it will be
in circulation.   It seems that the only people who would care at the home
networking level aren't likely to be contributing to the botnets.

On the other hand, any ISP that would want this as a feature in their
modems, would find it easier to implement on commercial hardware.

It would work and it's a good idea, I just don't see it gaining traction in
the right places to be effective.  The answer still rests with providers.

From nanog at jima.us  Mon Apr  1 04:36:17 2013
From: nanog at jima.us (Jima)
Date: Sun, 31 Mar 2013 22:36:17 -0600
Subject: BCP38 tester?
In-Reply-To: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
Message-ID: <51590EC1.2020506@jima.us>

On 2013-03-31 08:48, Jay Ashworth wrote:
> Is there a program which users can run on an end-site workstation which
> would test whether they are being some link which is doing BCP38, or some
> related type of source-address ingress filtering?

  I don't have a canned solution, but I've had good luck testing with 
nmap (-S and -e are relevant) while running tcpdump (and filtering for 
the protocols/ports) on a remote host.  I can happily report that 
someplace upstream of my home connection is doing some filtering -- 
nice.  I still need to test at work.

      Jima


From jared at puck.nether.net  Mon Apr  1 13:44:41 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 1 Apr 2013 09:44:41 -0400
Subject: Open Resolver Problems
In-Reply-To: <128114.1364786180@turing-police.cc.vt.edu>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
 <128114.1364786180@turing-police.cc.vt.edu>
Message-ID: <27AC6071-0CF2-491F-9B8F-0E04C732A6C2@puck.nether.net>


On Mar 31, 2013, at 11:16 PM, Valdis.Kletnieks at vt.edu wrote:

> On Sun, 31 Mar 2013 16:09:35 -0500, Jimmy Hess said:
>> On 3/29/13, Scott Noel-Hemming <frogstarr78 at gmail.com> wrote:
>>>> Some of us have both publicly-facing authoritative DNS, and inward
>>>> facing recursive servers that may be open resolvers but can't be
>>>> found via NS entries (so the IP addresses of those aren't exactly
>>>> publicly available info).
>>> Sounds like your making the faulty assumption that an attacker would use
>>> normal means to find your servers.
>> 
>> A distributed scan of the entire IPv4 <SNIP>
> 
> Stop right there.
> 
> Anybody who is looking at this as an IPv4 issue is woefully misinformed
> about the nature of the problem.

:)

IPv4 it's easy to collect an inventory (the math works).  IPv6, not nearly as easy.

- Jared

From ahebert at pubnix.net  Mon Apr  1 14:07:30 2013
From: ahebert at pubnix.net (Alain Hebert)
Date: Mon, 01 Apr 2013 10:07:30 -0400
Subject: BCP38 tester?
In-Reply-To: <51590EC1.2020506@jima.us>
References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com>
 <51590EC1.2020506@jima.us>
Message-ID: <515994A2.90205@pubnix.net>

    Hi,

    http://spoofer.csail.mit.edu/ is really the best place to certify
for BCP38.

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 04/01/13 00:36, Jima wrote:
> On 2013-03-31 08:48, Jay Ashworth wrote:
>> Is there a program which users can run on an end-site workstation which
>> would test whether they are being some link which is doing BCP38, or
>> some
>> related type of source-address ingress filtering?
>
>  I don't have a canned solution, but I've had good luck testing with
> nmap (-S and -e are relevant) while running tcpdump (and filtering for
> the protocols/ports) on a remote host.  I can happily report that
> someplace upstream of my home connection is doing some filtering --
> nice.  I still need to test at work.
>
>      Jima
>
>
>



From Valdis.Kletnieks at vt.edu  Mon Apr  1 14:09:20 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 01 Apr 2013 10:09:20 -0400
Subject: BCP38 tester?
In-Reply-To: Your message of "Mon, 01 Apr 2013 09:34:31 -0400."
 <51598CE7.2050008@pubnix.net>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl> <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
 <136480360.2136.54.camel@karl> <51598CE7.2050008@pubnix.net>
Message-ID: <156760.1364825360@turing-police.cc.vt.edu>

On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said:

>     I'm sad to confirm that my spoof test was successful with a:
>
>         . SageMCom modem+router, which is used by a big TelCo around my
> part, for both their residential and commercial ADSL2+, VDSL customers.

You might want to check more carefully exactly what the failure mode
was.  I'm willing to bet that the router has been configured to assign
addresses inside a specific RFC 1918 /24, and will do Something Terrible
to spoofed packets in that range, but will figure you know what you're
doing and pass them if you source a packet from outside that /24.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130401/dfc9024b/attachment.bin>

From cboyd at gizmopartners.com  Mon Apr  1 14:35:34 2013
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Mon, 1 Apr 2013 09:35:34 -0500
Subject: Open Resolver Problems
In-Reply-To: <70CE39F8-0981-4EAB-BB40-61F56489177A@puck.nether.net>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
 <70CE39F8-0981-4EAB-BB40-61F56489177A@puck.nether.net>
Message-ID: <FE1D689F-FEF3-4C3B-8002-B876FAF431A2@gizmopartners.com>


On Mar 31, 2013, at 8:46 PM, Jared Mauch wrote:

> Many thanks to everyone that is treating this as a critical issue to close these hosts.

Just back to the office, and started checking my networks.  Found one of the resolvers is a Netgear SOHO NAT box.  EoL'd, no new firmware available.  Anyone have any feeling for what percentage are these types of boxes?

--Chris

From ahebert at pubnix.net  Mon Apr  1 15:04:51 2013
From: ahebert at pubnix.net (Alain Hebert)
Date: Mon, 01 Apr 2013 11:04:51 -0400
Subject: BCP38 tester?
In-Reply-To: <156760.1364825360@turing-police.cc.vt.edu>
References: <27642435.389.1364783548545.JavaMail.root@benjamin.baylink.com>
 <1364787851.2136.7.camel@karl> <20130401040755.3032931B72A5@drugs.dv.isc.org>
 <1364792091.2136.15.camel@karl>
 <CAAAwwbUB-8G==ZzCtn_C5Yncd_t2==KNT_POZFdVPHW9BLS55g@mail.gmail.com>
 <136480360.2136.54.camel@karl> <51598CE7.2050008@pubnix.net>
 <156760.1364825360@turing-police.cc.vt.edu>
Message-ID: <5159A213.5000203@pubnix.net>

On 04/01/13 10:09, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said:
>
>>     I'm sad to confirm that my spoof test was successful with a:
>>
>>         . SageMCom modem+router, which is used by a big TelCo around my
>> part, for both their residential and commercial ADSL2+, VDSL customers.
> You might want to check more carefully exactly what the failure mode
> was.  I'm willing to bet that the router has been configured to assign
> addresses inside a specific RFC 1918 /24, and will do Something Terrible
> to spoofed packets in that range, but will figure you know what you're
> doing and pass them if you source a packet from outside that /24.

    My test script is very very very basic... but passes.

    And as per spoofer.csail, which is way more comprehensive in its
testing.

CPE tested with spoofer this morning.

    For the SageMCom 2864 with FAST2864_v6740S firmware:

        Received (at MIT AS3):

            1.2.3.4 | x.x.x.x | The IANA unalloced source was
successfully received.
            6.1.2.3 | x,x,x,x | The spoofed packets were successfully
received. There is no ingress or egress source filtering on your network
for this IP address.

        Your host can spoof 16777215 neighboring addresses (within your
/8 prefix)

    For the SpeedTouch 516:

        Received (at MIT AS3):

            1.2.3.4 | x.x.x.x | Source address rewrite. The source
address of the probe packets we received differs from the original
address. It appears that a Network Address Translation (NAT) device is
rewriting your packet headers.
            6.1.2.3 | x.x.x.x | <same>
            172.16.1.100 | x.x.x.x | <same>
 
        Your host can spoof 0 neighboring addresses (within your /32 prefix)

        ^ the /32 is a bit confusing.

    PS: This was just a few empirical tests and is in no way, shape, or
form, a judgement about the quality of the devices tested.

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443




From jason at lixfeld.ca  Mon Apr  1 15:35:24 2013
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Mon, 1 Apr 2013 11:35:24 -0400
Subject: AS1239 & AS701 IP Transit sales folks
Message-ID: <8676D3A1-66C2-4219-9EEA-B1A35FF5CAC5@lixfeld.ca>

If there are any IP Transit sales folks[1] listening form Sprint or Verizon, please drop me a line off-list.

Thanks.

[1] No resellers, please.

From fergdawgster at gmail.com  Mon Apr  1 15:44:17 2013
From: fergdawgster at gmail.com (Paul Ferguson)
Date: Mon, 1 Apr 2013 08:44:17 -0700
Subject: Open Resolver Problems
In-Reply-To: <FE1D689F-FEF3-4C3B-8002-B876FAF431A2@gizmopartners.com>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org>
 <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
 <70CE39F8-0981-4EAB-BB40-61F56489177A@puck.nether.net>
 <FE1D689F-FEF3-4C3B-8002-B876FAF431A2@gizmopartners.com>
Message-ID: <CANQy6Fb5tJbVcNKxwhO4_yL5D2NGzcdxix8uzwbTJsXe0FMs0A@mail.gmail.com>

On Mon, Apr 1, 2013 at 7:35 AM, Chris Boyd <cboyd at gizmopartners.com> wrote:

>
> On Mar 31, 2013, at 8:46 PM, Jared Mauch wrote:
>
>> Many thanks to everyone that is treating this as a critical issue to close these hosts.
>
> Just back to the office, and started checking my networks.  Found one of the resolvers is a Netgear SOHO NAT box.  EoL'd, no new firmware available.  Anyone have any feeling for what percentage are these types of boxes?
>

A lot?  :-/

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 fergdawgster(at)gmail.com


From swmike at swm.pp.se  Mon Apr  1 15:51:01 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 1 Apr 2013 17:51:01 +0200 (CEST)
Subject: Open Resolver Problems
In-Reply-To: <FE1D689F-FEF3-4C3B-8002-B876FAF431A2@gizmopartners.com>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
 <70CE39F8-0981-4EAB-BB40-61F56489177A@puck.nether.net>
 <FE1D689F-FEF3-4C3B-8002-B876FAF431A2@gizmopartners.com>
Message-ID: <alpine.DEB.2.00.1304011748010.23668@uplift.swm.pp.se>

On Mon, 1 Apr 2013, Chris Boyd wrote:

> Just back to the office, and started checking my networks.  Found one of 
> the resolvers is a Netgear SOHO NAT box.  EoL'd, no new firmware 
> available.  Anyone have any feeling for what percentage are these types 
> of boxes?

If you buy "type of box" mean "small SOHO NAT router which does DNS 
resolving on the WAN interface" then I'd say "a lot". Someone does a 
rollout of new software and configuration and happens to mess up the 
config file (or the vendor just happens to enable global dns resolving in 
the new software) and this slips through testing, then you're there. I 
believe this happens all the time.

That's why the publication of these lists are important, in a lot of cases 
there are a lot of people who are simply not aware of these devices doing 
this, and they need to be poked to notice.

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


From milt at net2atlanta.com  Mon Apr  1 15:55:34 2013
From: milt at net2atlanta.com (Milt Aitken)
Date: Mon, 1 Apr 2013 11:55:34 -0400
Subject: FW: Open Resolver Problems
Message-ID: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>

Most of our DSL customers have modem/routers that resolve DNS
externally.
And most of those have no configuration option to stop it.
So, we took the unfortunate step of ACL blocking DNS requests to & from
the DSL network unless the requests are to our DNS servers.

Suboptimal, but it stopped the DNS amplification attacks.

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
Sent: Monday, April 01, 2013 11:51 AM
To: Chris Boyd
Cc: nanog at nanog.org
Subject: Re: Open Resolver Problems

On Mon, 1 Apr 2013, Chris Boyd wrote:

> Just back to the office, and started checking my networks.  Found one
of 
> the resolvers is a Netgear SOHO NAT box.  EoL'd, no new firmware 
> available.  Anyone have any feeling for what percentage are these
types 
> of boxes?

If you buy "type of box" mean "small SOHO NAT router which does DNS 
resolving on the WAN interface" then I'd say "a lot". Someone does a 
rollout of new software and configuration and happens to mess up the 
config file (or the vendor just happens to enable global dns resolving
in 
the new software) and this slips through testing, then you're there. I 
believe this happens all the time.

That's why the publication of these lists are important, in a lot of
cases 
there are a lot of people who are simply not aware of these devices
doing 
this, and they need to be poked to notice.

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



From patrick at ianai.net  Mon Apr  1 16:03:53 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 1 Apr 2013 12:03:53 -0400
Subject: Open Resolver Problems
In-Reply-To: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
Message-ID: <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>

On Apr 01, 2013, at 11:55 , "Milt Aitken" <milt at net2atlanta.com> wrote:

> Most of our DSL customers have modem/routers that resolve DNS
> externally.
> And most of those have no configuration option to stop it.
> So, we took the unfortunate step of ACL blocking DNS requests to & from
> the DSL network unless the requests are to our DNS servers.
> 
> Suboptimal, but it stopped the DNS amplification attacks.

I was going to suggest exactly this.

Don't most broadband networks have a line in their AUP about running servers? Wouldn't a DNS server count as 'a server'? Then wouldn't running one violate the AUP?

This gives the provider a hammer to hit the user over the head. Although that is quite unlikely, so the better point is that it also gives the provider cover in case some user complains about the provider filtering.

You can always make an exception if the user is extremely loud.

-- 
TTFN,
patrick


> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
> Sent: Monday, April 01, 2013 11:51 AM
> To: Chris Boyd
> Cc: nanog at nanog.org
> Subject: Re: Open Resolver Problems
> 
> On Mon, 1 Apr 2013, Chris Boyd wrote:
> 
>> Just back to the office, and started checking my networks.  Found one
> of 
>> the resolvers is a Netgear SOHO NAT box.  EoL'd, no new firmware 
>> available.  Anyone have any feeling for what percentage are these
> types 
>> of boxes?
> 
> If you buy "type of box" mean "small SOHO NAT router which does DNS 
> resolving on the WAN interface" then I'd say "a lot". Someone does a 
> rollout of new software and configuration and happens to mess up the 
> config file (or the vendor just happens to enable global dns resolving
> in 
> the new software) and this slips through testing, then you're there. I 
> believe this happens all the time.
> 
> That's why the publication of these lists are important, in a lot of
> cases 
> there are a lot of people who are simply not aware of these devices
> doing 
> this, and they need to be poked to notice.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
> 
> 



From rdobbins at arbor.net  Mon Apr  1 16:09:51 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 1 Apr 2013 16:09:51 +0000
Subject: Open Resolver Problems
In-Reply-To: <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
Message-ID: <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>


On Apr 1, 2013, at 11:03 PM, Patrick W. Gilmore wrote:

> You can always make an exception if the user is extremely loud.

It might be a good idea to make pinholes for the Google and OpenDNS recursors, as they're fairly popular.

I agree that this is a good idea, similar to the same sort of network access policy as relates to SMTP.  

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From patrick at ianai.net  Mon Apr  1 16:18:18 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 1 Apr 2013 12:18:18 -0400
Subject: Open Resolver Problems
In-Reply-To: <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
Message-ID: <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>

On Apr 01, 2013, at 12:09 , "Dobbins, Roland" <rdobbins at arbor.net> wrote:
> On Apr 1, 2013, at 11:03 PM, Patrick W. Gilmore wrote:
> 
>> You can always make an exception if the user is extremely loud.
> 
> It might be a good idea to make pinholes for the Google and OpenDNS recursors, as they're fairly popular.
> 
> I agree that this is a good idea, similar to the same sort of network access policy as relates to SMTP.  

Ahhh, silly of me, I read the post form Milt too quickly.

I was going to suggest queries _into_ the broadband user space, not out of. If you only block into, OpenDNS, GoogleDNS, etc. are not an issue.

Blocking could be done with DPI. It can also be done by blocking UDP port 53. (Don't need to block TCP53 since that removes the amplification problem.) However, there are some (idiotic) name servers that do 53<>53. Not sure how to handle those, or more importantly, how many broadband customers legitimately use an off-net _and_ brain-dead name server? And even if they do, will they fall back to TCP?

Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :)

-- 
TTFN,
patrick



From jra at baylink.com  Mon Apr  1 16:23:35 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 1 Apr 2013 12:23:35 -0400 (EDT)
Subject: BCP38 tester?
In-Reply-To: <1364787851.2136.7.camel@karl>
Message-ID: <9602014.444.1364833415226.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Karl Auer" <kauer at biplane.com.au>

> On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
> > This thought crossed my mind earlier today, when I asked Jeff if
> > IP-forged
> > packets would make it through a NAT, outbound. He said no (I think),
> > but
> > I'm not entirely sure that's right.
> 
> Welll - the packets might make it out, and be transmitted into the
> Internet, but they would have a legitimate source address, namely an
> outside address of the NAT router. A side effect of NAT is to clamp the
> source address range of outbound packets to the configured NAT outside
> address range.

D'oh.  Of course.

Hmmm.  That says things about the penetration of NAT routers at consumer
eyeball connections vs. directly connected PCs that surprise me.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From jra at baylink.com  Mon Apr  1 16:31:05 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 1 Apr 2013 12:31:05 -0400 (EDT)
Subject: BCP38 tester?
In-Reply-To: <CAAAwwbWMSoWBvPnD5_tJhV67hcjnsa=Grij-k2PgUOn19Ac0=A@mail.gmail.com>
Message-ID: <27877536.446.1364833865691.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jimmy Hess" <mysidia at gmail.com>

> Ah, but did you actually test your guess on a reasonably large variety
> of NAT platforms?

He may not have, but now that I'm thinking (caffeine is a wonder drug),
I have: I've worked on, for customers, nearly every brand of consumer
router on the market, and all of them do outbound NAT the same way:

Pick up a DHCP address from the carrier, and use that as the source IP
on all translated outbound packets.

I have never found anything for which that's *not* the default config.

Upscale things like Snapgears, and routers running -WRT or Tomato, etc,
can be configured to do other things, but even on those, that's the 
default config for outbound NAT.

> It just takes 1 instance of the right platform to be in significant
> use for something to be different than expected.

Sure, but the question here is "is it reasonable to think that the 
*magnitude* of the problem is substantially reduced because consumer
NAT routers are doing much of the work for us" and that answer is
decidedly "yes, it is".

Sure, it's egress filtering, and a bad actor can get around it, if only
by *not using a router*.  But a *trojan* likely cannot, and that helps
us a lot too; 4-6 orders of magnitude, depending on your opinion of
the penetration of consumer edge routers.

> I remain unconvinced that all CPEs in all common configurations will
> clamp the source address to a legitimate one in all cases.

"All"?  Yeah, probably not.  But I think we're getting 99%, and you know
what?  I'll take that.

> It would just be way too much luck and convenience for that to happen
> by coincidence.

Once in a while, you win.

> > Now I'm imagining a NAT process that translates only *destination*
> > addresses - hm, is there such a beast?
> 
> Of course there is... in some implementations you may need two NAT
> rules to define a 1:1; a source NAT rule, and a destination NAT rule;
> if you define only the Source NAT rule, you just translate the
> source IP address ranges selected to the translation IP address
> range(s) selected for outgoing connections, and new incoming
> connections are not translated; if you define only the DNAT rule, you
> translate only the WAN interface destination IP for incoming
> connections, and outgoing connections are not translated.
> 
> In various implementations
> you can have full-cone NAT, address-restricted cone NAT,
> port-restricted cone NAT, symmetric NAT, and various combinations
> and variations (even different kinds of NAT in different directions),
> for each of source and destination address, with or without storage
> of a mapping for return traffic.
> 
> Different source or destination IP ranges or TCP/UDP ports might be
> NAT'ed differently or not at all.
> 
> Not all implementations allow all possible useful NAT configurations.

And the majority, by implementation count, don't allow *any* of those.

They allow outbound-SNAT, and configurable inbound-DNAT, maybe.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From brian.peter.dickson at gmail.com  Mon Apr  1 16:42:13 2013
From: brian.peter.dickson at gmail.com (Brian Dickson)
Date: Mon, 1 Apr 2013 12:42:13 -0400
Subject: Open Resolver Problems
Message-ID: <CAH1iCioGnwiOBd1hAQO=y_KiuviAU6aijHhXGUVU=ZN+h8Gbng@mail.gmail.com>

For filtering to/from "client-only" networks, here's the filtering rules
(in pseudo-code, convert to appropriate code for whatever devices you
operate), for DNS.

The objective here is:
- prevent spoofed-source DNS reflection attacks from your customers, from
leaving your network
- prevent your customers' open DNS servers (regardless of what they are)
from being used in reflection attacks
- permit normal DNS usage by clients, regardless of whether they are
talking to an external DNS resolver, or doing their own local resolution
(e.g. local DNS resolver on a host, or SOHO router)

from client:
permit source=client-subnet dest=any port=53 proto=TCP (TCP only works if
reaches "established", i.e. spoofing is irrelevant, but we stop spoofed SYN
here)
permit source=client-subnet dest=any port=53 proto=UDP QR=0 (first/highest
bit of 3rd octet of DNS packet payload of UDP)
deny port=53 (regardless of source/dest - either spoofed source, or QR=1,
if reached this rule)

to client:
permit dest=any source=any port=53 proto=TCP
permit dest=any source=any port=53 QR=1 (first/highest bit of 3rd octet of
DNS packet payload of UDP)
deny port=53 proto=UDP (QR=0 which is what we want to avoid)
(We don't have to check dest==client-subnet, since routing handles this
requirement)

If you have "eyeball" networks, please apply liberally.

Brian

From rdobbins at arbor.net  Mon Apr  1 16:50:30 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 1 Apr 2013 16:50:30 +0000
Subject: Open Resolver Problems
In-Reply-To: <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
 <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
Message-ID: <92D1E3F0-72A6-4DD3-BE8E-B3B8B0C7FE7C@arbor.net>


On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:

> Of course, since users shouldn't be using off-net name servers anyway, this isn't really a problem! :)

;>

It's easy enough to construct ACLs to restrict the broadband consumer access networks from doing so.  Additional egress filtering would catch any reflected attacks, per your previous comments.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From woody at pch.net  Mon Apr  1 16:55:43 2013
From: woody at pch.net (Bill Woodcock)
Date: Mon, 1 Apr 2013 09:55:43 -0700
Subject: alexandria cable cutters?
In-Reply-To: <CD79FC16.871D%wbailey@satelliteintelligencegroup.com>
References: <CD79FC16.871D%wbailey@satelliteintelligencegroup.com>
Message-ID: <959BE5BC-9C2A-463A-8EC4-917CF59DC553@pch.net>


On Mar 28, 2013, at 2:17 PM, Warren Bailey <wbailey at satelliteintelligencegroup.com> wrote:
> - Welding Gear is expensive, underwater gear is insanely expensive.
> - Welding is pretty difficult..
> - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water.
> ...going after a specific cable with a welder sounds like someone had a real reason. 
> ...the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant 

Warren:  

I think I missed a step here.  Where is the reference to the welding equipment coming from?

The photos show three scuba tanks and a float.  I don't see any mention of welding equipment in the NYT or Guardian pieces, or in the Egyptian Navy's statement or photos.

                                -Bill







From wbailey at satelliteintelligencegroup.com  Mon Apr  1 17:04:17 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Mon, 1 Apr 2013 17:04:17 +0000
Subject: alexandria cable cutters?
In-Reply-To: <959BE5BC-9C2A-463A-8EC4-917CF59DC553@pch.net>
Message-ID: <CD7F0BD1.880B%wbailey@satelliteintelligencegroup.com>

This was in reply to a posting that brought up the possible usage of a
Thermal Lance. 

On 4/1/13 9:55 AM, "Bill Woodcock" <woody at pch.net> wrote:

>
>On Mar 28, 2013, at 2:17 PM, Warren Bailey
><wbailey at satelliteintelligencegroup.com> wrote:
>> - Welding Gear is expensive, underwater gear is insanely expensive.
>> - Welding is pretty difficult..
>> - Underwater welding requires knowledge of SCUBA *AND* welding
>>techniques under water.
>> ...going after a specific cable with a welder sounds like someone had a
>>real reason. 
>> ...the fact that they were using a welder, underwater, on a 15kV -48VDC
>>fiber optic plant
>
>Warren:  
>
>I think I missed a step here.  Where is the reference to the welding
>equipment coming from?
>
>The photos show three scuba tanks and a float.  I don't see any mention
>of welding equipment in the NYT or Guardian pieces, or in the Egyptian
>Navy's statement or photos.
>
>                                -Bill
>
>
>
>
>
>




From lathama at gmail.com  Mon Apr  1 17:08:48 2013
From: lathama at gmail.com (Andrew Latham)
Date: Mon, 1 Apr 2013 13:08:48 -0400
Subject: alexandria cable cutters?
In-Reply-To: <CD7F0BD1.880B%wbailey@satelliteintelligencegroup.com>
References: <959BE5BC-9C2A-463A-8EC4-917CF59DC553@pch.net>
 <CD7F0BD1.880B%wbailey@satelliteintelligencegroup.com>
Message-ID: <CA+qj4S-jkQTMBCkrTdN4V9zuVvVoTQBhcjE21V+sRzO27z10HQ@mail.gmail.com>

Thermal Lances can be started with various heat sources. Some are self
contained for emergency use.

On Mon, Apr 1, 2013 at 1:04 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> This was in reply to a posting that brought up the possible usage of a
> Thermal Lance.
>
> On 4/1/13 9:55 AM, "Bill Woodcock" <woody at pch.net> wrote:
>
>>
>>On Mar 28, 2013, at 2:17 PM, Warren Bailey
>><wbailey at satelliteintelligencegroup.com> wrote:
>>> - Welding Gear is expensive, underwater gear is insanely expensive.
>>> - Welding is pretty difficult..
>>> - Underwater welding requires knowledge of SCUBA *AND* welding
>>>techniques under water.
>>> ...going after a specific cable with a welder sounds like someone had a
>>>real reason.
>>> ...the fact that they were using a welder, underwater, on a 15kV -48VDC
>>>fiber optic plant
>>
>>Warren:
>>
>>I think I missed a step here.  Where is the reference to the welding
>>equipment coming from?
>>
>>The photos show three scuba tanks and a float.  I don't see any mention
>>of welding equipment in the NYT or Guardian pieces, or in the Egyptian
>>Navy's statement or photos.
>>
>>                                -Bill
>>
>>
>>
>>
>>
>>
>
>
>



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


From listas at esds.com.br  Mon Apr  1 18:06:54 2013
From: listas at esds.com.br (Eduardo Schoedler)
Date: Mon, 1 Apr 2013 15:06:54 -0300
Subject: GlobalCrossing looking glass problem
Message-ID: <CAHf3uWw3QrxmDRxpiiyJS6L3PMkx+_D7dLsEdPx06XokYeMj=g@mail.gmail.com>

Hi all,

Someone is getting access to the GlobalCrossing the looking glass?

# telnet route-server.gblx.net
Trying 67.17.81.28...
telnet: connect to address 67.17.81.28: Connection refused

Thanks.

-- 
Eduardo Schoedler

From jra at baylink.com  Mon Apr  1 18:19:16 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 1 Apr 2013 14:19:16 -0400 (EDT)
Subject: Open Resolver Problems
In-Reply-To: <13505129.460.1364840336312.JavaMail.root@benjamin.baylink.com>
Message-ID: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Roland Dobbins" <rdobbins at arbor.net>

> On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:
> > Of course, since users shouldn't be using off-net name servers
> > anyway, this isn't really a problem! :)
> 
> ;>
> 
> It's easy enough to construct ACLs to restrict the broadband consumer
> access networks from doing so. Additional egress filtering would catch
> any reflected attacks, per your previous comments.

So, how would Patrick's caveat affect me, whose recursive resolver *is 
on my Linux laptop*?  Would not that recursor be making queries he 
advocates blocking?

Or don't I remember DNS well enough?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From Valdis.Kletnieks at vt.edu  Mon Apr  1 18:27:56 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 01 Apr 2013 14:27:56 -0400
Subject: Open Resolver Problems
In-Reply-To: Your message of "Mon, 01 Apr 2013 14:19:16 -0400."
 <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
Message-ID: <8720.1364840876@turing-police.cc.vt.edu>

On Mon, 01 Apr 2013 14:19:16 -0400, Jay Ashworth said:

> So, how would Patrick's caveat affect me, whose recursive resolver *is
> on my Linux laptop*?  Would not that recursor be making queries he
> advocates blocking?

You're sending queries, not replies.  That's why DPI is needed to do the
blocking, rather than just by port.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130401/a2790bee/attachment.bin>

From David.Siegel at Level3.com  Mon Apr  1 18:28:39 2013
From: David.Siegel at Level3.com (Siegel, David)
Date: Mon, 1 Apr 2013 18:28:39 +0000
Subject: GlobalCrossing looking glass problem
In-Reply-To: <CAHf3uWw3QrxmDRxpiiyJS6L3PMkx+_D7dLsEdPx06XokYeMj=g@mail.gmail.com>
References: <CAHf3uWw3QrxmDRxpiiyJS6L3PMkx+_D7dLsEdPx06XokYeMj=g@mail.gmail.com>
Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0C2D729@USIDCWVEMBX10.corp.global.level3.com>

The route-server is accessible again.  Sorry for the inconvenience.

Dave


-----Original Message-----
From: Eduardo Schoedler [mailto:listas at esds.com.br] 
Sent: Monday, April 01, 2013 12:07 PM
To: NANOG
Subject: GlobalCrossing looking glass problem

Hi all,

Someone is getting access to the GlobalCrossing the looking glass?

# telnet route-server.gblx.net
Trying 67.17.81.28...
telnet: connect to address 67.17.81.28: Connection refused

Thanks.

-- 
Eduardo Schoedler


From jra at baylink.com  Mon Apr  1 18:29:40 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 1 Apr 2013 14:29:40 -0400 (EDT)
Subject: Open Resolver Problems
In-Reply-To: <8720.1364840876@turing-police.cc.vt.edu>
Message-ID: <18245136.464.1364840980275.JavaMail.root@benjamin.baylink.com>

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

> On Mon, 01 Apr 2013 14:19:16 -0400, Jay Ashworth said:
> > So, how would Patrick's caveat affect me, whose recursive resolver *is
> > on my Linux laptop*? Would not that recursor be making queries he
> > advocates blocking?
> 
> You're sending queries, not replies. That's why DPI is needed to do
> the blocking, rather than just by port.

Aha.  Right.  Got it.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From swmike at swm.pp.se  Mon Apr  1 18:33:36 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 1 Apr 2013 20:33:36 +0200 (CEST)
Subject: Open Resolver Problems
In-Reply-To: <8720.1364840876@turing-police.cc.vt.edu>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
 <8720.1364840876@turing-police.cc.vt.edu>
Message-ID: <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>

On Mon, 1 Apr 2013, Valdis.Kletnieks at vt.edu wrote:

> You're sending queries, not replies.  That's why DPI is needed to do the 
> blocking, rather than just by port.

What queries are sourced from port 53 nowadays?

I'd imagine it's pretty safe to block Internet->customer UDP/53 packets.

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


From jabley at hopcount.ca  Mon Apr  1 18:33:57 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 1 Apr 2013 14:33:57 -0400
Subject: Open Resolver Problems
In-Reply-To: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
Message-ID: <0754FE2B-E986-4B69-B9CB-874138C64673@hopcount.ca>


On 2013-04-01, at 14:19, Jay Ashworth <jra at baylink.com> wrote:

>> From: "Roland Dobbins" <rdobbins at arbor.net>
> 
>> On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:
>>> Of course, since users shouldn't be using off-net name servers
>>> anyway, this isn't really a problem! :)
>> 
>> ;>
>> 
>> It's easy enough to construct ACLs to restrict the broadband consumer
>> access networks from doing so. Additional egress filtering would catch
>> any reflected attacks, per your previous comments.
> 
> So, how would Patrick's caveat affect me, whose recursive resolver *is 
> on my Linux laptop*?  Would not that recursor be making queries he 
> advocates blocking?

The badness that Patrick is talking about blocking are DNS responses being sent from consumer devices to the Internet, answering DNS queries being sent from the Internet towards consumer devices. (I think. This thread is sufficiently circular that I feel a bit dizzy, and could be mistaken.) The DNS traffic outbound from your laptop will be DNS queries (not responses) and the inbound traffic will be DNS responses (not queries). The traffic profiles are different.

The case where infected consumer devices originate source-spoofed queries towards open resolvers, feeding a query stream to an amplifier for delivery to a victim, is mitigated by preventing those consumer devices from spoofing their source address, so BCP38.

The case where infected consumer devices originate non-source-spoofed queries towards DNS servers in order to overwhelm the servers themselves with perfectly legitimate-looking queries is a harder problem to solve at the edge, and is most easily mitigated for DNS server operators by the approach "ensure great headroom".


Joe



From dot at dotat.at  Mon Apr  1 18:40:03 2013
From: dot at dotat.at (Tony Finch)
Date: Mon, 1 Apr 2013 19:40:03 +0100
Subject: Open Resolver Problems
In-Reply-To: <27AC6071-0CF2-491F-9B8F-0E04C732A6C2@puck.nether.net>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
 <128114.1364786180@turing-police.cc.vt.edu>
 <27AC6071-0CF2-491F-9B8F-0E04C732A6C2@puck.nether.net>
Message-ID: <28E62B39-8102-413A-A11F-62D8BC6CEF65@dotat.at>

On 1 Apr 2013, at 14:44, Jared Mauch <jared at puck.nether.net> wrote:
> On Mar 31, 2013, at 11:16 PM, Valdis.Kletnieks at vt.edu wrote:
>> 
>> Anybody who is looking at this as an IPv4 issue is woefully misinformed
>> about the nature of the problem.
> 
> :)
> 
> IPv4 it's easy to collect an inventory (the math works).  IPv6, not nearly as easy.

You should be able to get a reasonable sample of IPv6 resolvers from the query logs of a popular authoritative server.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/

From frnkblk at iname.com  Mon Apr  1 18:50:11 2013
From: frnkblk at iname.com (Frank Bulk (iname.com))
Date: Mon, 1 Apr 2013 13:50:11 -0500
Subject: BCP38 tester?
In-Reply-To: <10659463.391.1364783689622.JavaMail.root@benjamin.baylink.com>
References: <5158EAFF.30503@pubnix.net>
 <10659463.391.1364783689622.JavaMail.root@benjamin.baylink.com>
Message-ID: <015501ce2f09$e3b5d9c0$ab218d40$@iname.com>

The good news is that source address spoofing does seem to fail with most CPE's NAT.  

At the end of the day, just turn on uRPF and/or use ACLs.  It's amazing how much destination 192.168.0.0/24 and 192.168.1.0/24 our ACLs also block.

Frank

-----Original Message-----
From: Jay Ashworth [mailto:jra at baylink.com] 
Sent: Sunday, March 31, 2013 9:35 PM
To: NANOG
Subject: Re: BCP38 tester?

----- Original Message -----
> From: "Alain Hebert" <ahebert at pubnix.net>

> An easy target would be anti-virus/trojan/security software
> providers that could add a BCP38 check to their software =D

Yes, but penetration is a problem, which is why I was thinking about
people like YouTube, Ookla, and the like.

Any Flash app that lots of people run frequently.  Assuming those apps
could generate the packets, which, on reflection, I would bet they can't.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274





From Valdis.Kletnieks at vt.edu  Mon Apr  1 18:59:35 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 01 Apr 2013 14:59:35 -0400
Subject: Open Resolver Problems
In-Reply-To: Your message of "Mon, 01 Apr 2013 19:40:03 +0100."
 <28E62B39-8102-413A-A11F-62D8BC6CEF65@dotat.at>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQnz1h19agbGLg@mail.gmail.com>
 <128114.1364786180@turing-police.cc.vt.edu>
 <27AC6071-0CF2-491F-9B8F-0E04C732A6C2@puck.nether.net>
 <28E62B39-8102-413A-A11F-62D8BC6CEF65@dotat.at>
Message-ID: <10309.1364842775@turing-police.cc.vt.edu>

On Mon, 01 Apr 2013 19:40:03 +0100, Tony Finch said:

> You should be able to get a reasonable sample of IPv6 resolvers from the query
> logs of a popular authoritative server.

Hopefully, said logs are not easily accessible to the miscreants.

(I still expect the most feasible method for the miscreants is to start a
botnet and see what boxes get handed an IPv6 DNS via dhcp6).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130401/2c32a11c/attachment.bin>

From morrowc.lists at gmail.com  Mon Apr  1 19:09:06 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 1 Apr 2013 15:09:06 -0400
Subject: alexandria cable cutters?
In-Reply-To: <CA+qj4S-jkQTMBCkrTdN4V9zuVvVoTQBhcjE21V+sRzO27z10HQ@mail.gmail.com>
References: <959BE5BC-9C2A-463A-8EC4-917CF59DC553@pch.net>
 <CD7F0BD1.880B%wbailey@satelliteintelligencegroup.com>
 <CA+qj4S-jkQTMBCkrTdN4V9zuVvVoTQBhcjE21V+sRzO27z10HQ@mail.gmail.com>
Message-ID: <CAL9jLabDpRtDYQpNhTD=J9V0-h_NuUvx_EXz7eBp_0sLz3BFtQ@mail.gmail.com>

On Mon, Apr 1, 2013 at 1:08 PM, Andrew Latham <lathama at gmail.com> wrote:

> Thermal Lances can be started with various heat sources. Some are self
> contained for emergency use.
>
>
either way, there's no mention of such a device in the reporting... or
picts.

right?


> On Mon, Apr 1, 2013 at 1:04 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
> > This was in reply to a posting that brought up the possible usage of a
> > Thermal Lance.
> >
> > On 4/1/13 9:55 AM, "Bill Woodcock" <woody at pch.net> wrote:
> >
> >>
> >>On Mar 28, 2013, at 2:17 PM, Warren Bailey
> >><wbailey at satelliteintelligencegroup.com> wrote:
> >>> - Welding Gear is expensive, underwater gear is insanely expensive.
> >>> - Welding is pretty difficult..
> >>> - Underwater welding requires knowledge of SCUBA *AND* welding
> >>>techniques under water.
> >>> ...going after a specific cable with a welder sounds like someone had a
> >>>real reason.
> >>> ...the fact that they were using a welder, underwater, on a 15kV -48VDC
> >>>fiber optic plant
> >>
> >>Warren:
> >>
> >>I think I missed a step here.  Where is the reference to the welding
> >>equipment coming from?
> >>
> >>The photos show three scuba tanks and a float.  I don't see any mention
> >>of welding equipment in the NYT or Guardian pieces, or in the Egyptian
> >>Navy's statement or photos.
> >>
> >>                                -Bill
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
> --
> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~
>
>

From joelja at bogus.com  Mon Apr  1 19:40:57 2013
From: joelja at bogus.com (joel jaeggli)
Date: Mon, 01 Apr 2013 12:40:57 -0700
Subject: Open Resolver Problems
In-Reply-To: <10309.1364842775@turing-police.cc.vt.edu>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQnz1h19agbGLg@mail.gmail.com>
 <128114.1364786180@turing-police.cc.vt.edu>
 <27AC6071-0CF2-491F-9B8F-0E04C732A6C2@puck.nether.net>
 <28E62B39-8102-413A-A11F-62D8BC6CEF65@dotat.at>
 <10309.1364842775@turing-police.cc.vt.edu>
Message-ID: <5159E2C9.4010503@bogus.com>

On 4/1/13 11:59 AM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 01 Apr 2013 19:40:03 +0100, Tony Finch said:
>
>> You should be able to get a reasonable sample of IPv6 resolvers from the query
>> logs of a popular authoritative server.
> Hopefully, said logs are not easily accessible to the miscreants.
Miscreants with popular zones clearly can do that.

Reverse-lookups for spam originating machines might for example be a 
sufficient source of queries if you control the reverse zone.

The DNS makes it's own gravy.
> (I still expect the most feasible method for the miscreants is to start a
> botnet and see what boxes get handed an IPv6 DNS via dhcp6).



From niels=nanog at bakker.net  Mon Apr  1 20:19:31 2013
From: niels=nanog at bakker.net (Niels Bakker)
Date: Mon, 1 Apr 2013 22:19:31 +0200
Subject: Open Resolver Problems
In-Reply-To: <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
Message-ID: <20130401201931.GT55976@burnout.tpb.net>

>On Apr 01, 2013, at 11:55 , "Milt Aitken" <milt at net2atlanta.com> wrote:
>>Most of our DSL customers have modem/routers that resolve DNS 
>>externally.
>>And most of those have no configuration option to stop it.
>>So, we took the unfortunate step of ACL blocking DNS requests to & from 
>>the DSL network unless the requests are to our DNS servers.
>>
>> Suboptimal, but it stopped the DNS amplification attacks.

Wow.  Glad I'm not a customer of yours.


* patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:04 CEST]:
>I was going to suggest exactly this.
>
>Don't most broadband networks have a line in their AUP about running 
>servers?

Huh?  No.  Thankfully.  Not all of us are mindless consumers.


	-- Niels.


From niels=nanog at bakker.net  Mon Apr  1 20:21:42 2013
From: niels=nanog at bakker.net (Niels Bakker)
Date: Mon, 1 Apr 2013 22:21:42 +0200
Subject: Open Resolver Problems
In-Reply-To: <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
 <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
Message-ID: <20130401202142.GU55976@burnout.tpb.net>

* patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]:
>Of course, since users shouldn't be using off-net name servers 
>anyway, this isn't really a problem! :)

You're joking, right?  Should they also use only the telco-approved 
search engine, via the telco-hosted portal?


	-- Niels.


From jared at puck.nether.net  Mon Apr  1 20:23:57 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 1 Apr 2013 16:23:57 -0400
Subject: Open Resolver Problems
In-Reply-To: <20130401201931.GT55976@burnout.tpb.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130401201931.GT55976@burnout.tpb.net>
Message-ID: <3116CAEA-4C8A-4069-9D4D-3422DEB909E6@puck.nether.net>


On Apr 1, 2013, at 4:19 PM, Niels Bakker <niels=nanog at bakker.net> wrote:

>> On Apr 01, 2013, at 11:55 , "Milt Aitken" <milt at net2atlanta.com> wrote:
>>> Most of our DSL customers have modem/routers that resolve DNS externally.
>>> And most of those have no configuration option to stop it.
>>> So, we took the unfortunate step of ACL blocking DNS requests to & from the DSL network unless the requests are to our DNS servers.
>>> 
>>> Suboptimal, but it stopped the DNS amplification attacks.
> 
> Wow.  Glad I'm not a customer of yours.

I would say this is the wrong solution.  Prevent your customers from spoofing is the first step, then ask them to fix their broken CPE.

If NETGEAR is listening on the WAN side vs the LAN/INSIDE they need to step up and issue fixed firmware, even if the device is older.  Should be a simple fix.


> * patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:04 CEST]:
>> I was going to suggest exactly this.
>> 
>> Don't most broadband networks have a line in their AUP about running servers?
> 
> Huh?  No.  Thankfully.  Not all of us are mindless consumers.

I think it's easier to just classify an open-resolver similar to an open-relay without having to invoke the consumer mindset.

- Jared

From niels=nanog at bakker.net  Mon Apr  1 20:32:25 2013
From: niels=nanog at bakker.net (Niels Bakker)
Date: Mon, 1 Apr 2013 22:32:25 +0200
Subject: Open Resolver Problems
In-Reply-To: <3116CAEA-4C8A-4069-9D4D-3422DEB909E6@puck.nether.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130401201931.GT55976@burnout.tpb.net>
 <3116CAEA-4C8A-4069-9D4D-3422DEB909E6@puck.nether.net>
Message-ID: <20130401203225.GV55976@burnout.tpb.net>

* jared at puck.nether.net (Jared Mauch) [Mon 01 Apr 2013, 22:24 CEST]:
>I would say this is the wrong solution.  Prevent your customers from 
>spoofing is the first step, then ask them to fix their broken CPE.

I daresay that after ten years of discussion NANOG has reached 
consensus that implementing BCP38 is a good thing and that all 
networks should be encouraged to do so.

Net neutrality has not been discussed completely to death yet but I'm 
pretty confident in stating that squeezing consumer connections 
further down each time some blog hypes up yet another "The Internet is 
melting!" threat won't scale.


>If NETGEAR is listening on the WAN side vs the LAN/INSIDE they need 
>to step up and issue fixed firmware, even if the device is older.  
>Should be a simple fix.

I don't think anybody would disagree with this statement.  Netgear did 
get into action when they DDoS'ed a university's NTP servers; perhaps 
similar sticks can be shaken in this case.

(Is Netgear one of the brands involved?  Usually they're better.
  Pardon me for not reading the whole thread and the other five)


>I think it's easier to just classify an open-resolver similar to an 
>open-relay without having to invoke the consumer mindset.

Two posts up in this thread we were talking about net-wide blocks 
without individual proof of open relay or equivalent status.


	-- Niels.


From lorell at hathcock.org  Mon Apr  1 21:39:16 2013
From: lorell at hathcock.org (Lorell Hathcock)
Date: Mon, 1 Apr 2013 16:39:16 -0500
Subject: Eastern Canadian Wireless ISP Resources
Message-ID: <028101ce2f21$5c39a130$14ace390$@hathcock.org>

All:

 

I am seeking a wireless internet service provider to help with an off-shore
project on the eastern coast of Canada.  

 

I am seeking to pump up to 400 GB per day back to shore from vessels at sea.

 

Are there any wireless operators on this list that may be able to steer me
in the right direction?

 

Sincerely,

 

Lorell Hathcock

 

 


From pfunix at gmail.com  Mon Apr  1 21:41:36 2013
From: pfunix at gmail.com (Beavis)
Date: Mon, 1 Apr 2013 15:41:36 -0600
Subject: NAPA link from Latin America
Message-ID: <CAMvhC_7Lk8VF8ESoK6uNbPgxWoFcDRZATzLtR0Lvw9UMhtngew@mail.gmail.com>

hello all, would like to politely ask if there are any folks from the
NAPA here. Would you be so kind as to contact me off-list.


many thanks,
-Beavis

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/


From mike.lyon at gmail.com  Mon Apr  1 21:43:32 2013
From: mike.lyon at gmail.com (Mike Lyon)
Date: Mon, 1 Apr 2013 14:43:32 -0700
Subject: Eastern Canadian Wireless ISP Resources
In-Reply-To: <028101ce2f21$5c39a130$14ace390$@hathcock.org>
References: <028101ce2f21$5c39a130$14ace390$@hathcock.org>
Message-ID: <CAFFgAjBpdu+NzA_-qgXgNnf574kAewFfx+FzGy9GyPoy00Vb7w@mail.gmail.com>

Lorell,

Try wispa.org. They also have a mailing list you can join (like NANOG) and
you can post there to see if there are any operators over in those neck of
the woods.

How far off of the coast are the stations?

-Mike Lyon


On Mon, Apr 1, 2013 at 2:39 PM, Lorell Hathcock <lorell at hathcock.org> wrote:

> All:
>
>
>
> I am seeking a wireless internet service provider to help with an off-shore
> project on the eastern coast of Canada.
>
>
>
> I am seeking to pump up to 400 GB per day back to shore from vessels at
> sea.
>
>
>
> Are there any wireless operators on this list that may be able to steer me
> in the right direction?
>
>
>
> Sincerely,
>
>
>
> Lorell Hathcock
>
>
>
>
>
>


-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon

From robt at cymru.com  Mon Apr  1 22:07:38 2013
From: robt at cymru.com (Rabbi Rob Thomas)
Date: Mon, 01 Apr 2013 18:07:38 -0400
Subject: Providers with RTBH capability?
Message-ID: <515A052A.4040707@cymru.com>

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

Hi, team.

Apologies to those of you seeing this in multiple forums.

I'm looking for a list of transit providers who have well-supported,
customer-enabled (not "ring the NOC") RTBH [0][1] capability.  I'm not
yet looking for sales calls, just the facts, please.  If you are one of
those providers, or you've had a good experience with providers with
RTBH capability, please let me know.

Off-list replies are fine, and I'm happy to summarize once I've
assembled the list.

[0]
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd80313fac.pdf
[1] http://tools.ietf.org/html/rfc5635

Thank you!
Rob.
- --
Rabbi Rob Thomas
Team Cymru
https://www.team-cymru.org/
"Say little and do much." M Avot 1:15

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUVoFKlkX3QAo5sgJAQLzWAP+KnDgvSQo9iXkKOpEE190DRqIu0CDP8Kh
8Lkj0Mt37vo1oIiANMVNt+JJh5g5dJSNp1vTrC4mAcFMCDEZ+ZIKDoH8aGadhbTZ
IlPvODQ+ig1V94f2bD/07/hcMTbjhlFMA0nxZX3uzmVFrYTpAn1351FDOorpx2eG
jlkbBZscUv4=
=dxnH
-----END PGP SIGNATURE-----


From kmedcalf at dessus.com  Mon Apr  1 22:30:54 2013
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Mon, 01 Apr 2013 16:30:54 -0600
Subject: Open Resolver Problems
In-Reply-To: <20130401202142.GU55976@burnout.tpb.net>
Message-ID: <495b87fd4017164a8c5aa86d198e5f2f@mail.dessus.com>


And only the telco approved web sites are accessible, and the only protocol supported is the telco approved http and then only to port 80 ...


---
()  ascii ribbon campaign against html e-mail
/\  www.asciiribbon.org


> -----Original Message-----
> From: Niels Bakker [mailto:niels=nanog at bakker.net]
> Sent: Monday, 01 April, 2013 14:22
> To: nanog at nanog.org
> Subject: Re: Open Resolver Problems
> 
> * patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]:
> >Of course, since users shouldn't be using off-net name servers
> >anyway, this isn't really a problem! :)
> 
> You're joking, right?  Should they also use only the telco-approved
> search engine, via the telco-hosted portal?
> 
> 
> 	-- Niels.






From mpalmer at hezmatt.org  Mon Apr  1 20:33:45 2013
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Tue, 2 Apr 2013 07:33:45 +1100
Subject: BCP38 tester?
In-Reply-To: <27877536.446.1364833865691.JavaMail.root@benjamin.baylink.com>
References: <CAAAwwbWMSoWBvPnD5_tJhV67hcjnsa=Grij-k2PgUOn19Ac0=A@mail.gmail.com>
 <27877536.446.1364833865691.JavaMail.root@benjamin.baylink.com>
Message-ID: <20130401203345.GJ4906@hezmatt.org>

On Mon, Apr 01, 2013 at 12:31:05PM -0400, Jay Ashworth wrote:
> From: "Jimmy Hess" <mysidia at gmail.com>
> 
> > Ah, but did you actually test your guess on a reasonably large variety
> > of NAT platforms?
> 
> He may not have, but now that I'm thinking (caffeine is a wonder drug),
> I have: I've worked on, for customers, nearly every brand of consumer
> router on the market, and all of them do outbound NAT the same way:
> 
> Pick up a DHCP address from the carrier, and use that as the source IP
> on all translated outbound packets.

The key issue at hand (I believe; please correct me if I'm wrong) is that
"all translated outbound packets" may not equal "all outbound packets". 
Depending on how a NAT device is configured, it may pass some packets
*untranslated*, and that allows a malicious actor behind the NAT device to
still get their spoofed traffic out.

To relate it back to something concrete, imagine this iptables rule in an
otherwise "fully open" configuration:

    iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wan -j MASQUERADE

Now, spoof a packet from behind this NAT box as coming from 192.0.2.12...
what happens?  It gets passed through the NAT box, *without* being NATed. 
Oops.

Of course, it isn't hard to stop this sort of thing...

    iptables -A INPUT ! -s 192.168.1.0/24 -i lan -j DROP

(or any number of other equivalent rules)  The question is, how many
in-common-use CPEs have considered this attack vector and are actually doing
something functionally equivalent to the DROP rule above?

I don't know, because I haven't tried it, but I'd only be surprised if the
answer was "none" or "all of them".

- Matt



From j at 2600hz.com  Mon Apr  1 23:09:01 2013
From: j at 2600hz.com (Joshua Goldbard)
Date: Mon, 1 Apr 2013 23:09:01 +0000
Subject: New Product Launch from 2600hz
Message-ID: <FD4A91ABAD370D4383186A56320046BE084703DF@mbx022-w1-ca-9.exch022.domain.local>

Hello,

Normally I wouldn't bother the respected members of NANOG with a product launch email, but this is such a unique application that I felt it was necessary.

2600hz is saying goodbye to SMS, Voice and even Video. Today we're launching a service we'd like to call BrainRTC. It's going to completely revolutionize communications.

Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-video-are-dead-heres-the-future

Cheers,
Joshua

Joshua Goldbard
VP of Marketing, 2600hz

116 Natoma Street, Floor 2
San Francisco, CA, 94104
415.886.7923 | j at 2600hz.com<mailto:j at 2600hz.com>


From mansaxel at besserwisser.org  Mon Apr  1 23:14:13 2013
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Tue, 2 Apr 2013 01:14:13 +0200
Subject: Open Resolver Problems
In-Reply-To: <20130401202142.GU55976@burnout.tpb.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
 <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
 <20130401202142.GU55976@burnout.tpb.net>
Message-ID: <20130401231413.GA2136@besserwisser.org>

Subject: Re: Open Resolver Problems Date: Mon, Apr 01, 2013 at 10:21:42PM +0200 Quoting Niels Bakker (niels=nanog at bakker.net):
> * patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Apr 2013, 18:18 CEST]:
> >Of course, since users shouldn't be using off-net name servers
> >anyway, this isn't really a problem! :)
> 
> You're joking, right?  Should they also use only the telco-approved
> search engine, via the telco-hosted portal?

Far too many (perhaps not Patrick) in this thread are not joking. Laughter
gets stuck in my throat, as we say in Sweden. Having proper Internet
access is more and more a privilege for the Internet gentry that are
clued and able to pay for a box in a colo or similar.

The unwashed masses are left with "broadband" We can't call it "Internet"
because there are a few raving graybeards that claim they invented it
and intended it to be two-way instead of stuffing .flv down peoples
facebook-viewing devices while also supplanting cable TV with demand 
streaming.

</rant>

What percentage of the SOHO NAT boxes actually are full-service
resolvers? I was under the impression that most were mere forwarders; just
pushing queries on toward the DHCP'd full service resolvers of the ISP.


-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Everywhere I look I see NEGATIVITY and ASPHALT ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130402/9b37e768/attachment.bin>

From surfer at mauigateway.com  Tue Apr  2 00:11:39 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 1 Apr 2013 17:11:39 -0700
Subject: New Product Launch from 2600hz
Message-ID: <20130401171139.A9FBD7FB@resin11.mta.everyone.net>



--- j at 2600hz.com wrote:
From: Joshua Goldbard <j at 2600hz.com>

It's going to completely revolutionize communications.
-------------------------------------------


Ummm, yeah.  Lemme know how that goes for you...


scott
(but not on NANOG)


From owen at delong.com  Tue Apr  2 00:06:58 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Apr 2013 17:06:58 -0700
Subject: New Product Launch from 2600hz
In-Reply-To: <FD4A91ABAD370D4383186A56320046BE084703DF@mbx022-w1-ca-9.exch022.domain.local>
References: <FD4A91ABAD370D4383186A56320046BE084703DF@mbx022-w1-ca-9.exch022.domain.local>
Message-ID: <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>

Goes in the same category as this bit of news:


IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly announced that IPv4 would no longer be supported on the global internet after 1/1/2014. Those wishing to continue using the internet in 2014 and beyond
should move to IPv6.


Owen

On Apr 1, 2013, at 4:09 PM, Joshua Goldbard <j at 2600hz.com> wrote:

> Hello,
> 
> Normally I wouldn't bother the respected members of NANOG with a product launch email, but this is such a unique application that I felt it was necessary.
> 
> 2600hz is saying goodbye to SMS, Voice and even Video. Today we're launching a service we'd like to call BrainRTC. It's going to completely revolutionize communications.
> 
> Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-video-are-dead-heres-the-future
> 
> Cheers,
> Joshua
> 
> Joshua Goldbard
> VP of Marketing, 2600hz
> 
> 116 Natoma Street, Floor 2
> San Francisco, CA, 94104
> 415.886.7923 | j at 2600hz.com<mailto:j at 2600hz.com>



From lorell at hathcock.org  Tue Apr  2 00:19:15 2013
From: lorell at hathcock.org (Lorell Hathcock)
Date: Mon, 1 Apr 2013 19:19:15 -0500
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
Message-ID: <02d401ce2f37$b63b4f10$22b1ed30$@hathcock.org>

All:

 

I am having some speedtest results that are difficult to interpret.

 

I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX.  I am
running BGP with each with 100 Mbps+ on each link.

 

Some of my customers have begun complaining that they are not getting the
proper speeds.  They are using speedtest.net and/or speakeasy.net to test
the results.

 

My network is Mikrotik based and as such, I have access to Mikrotik's
built-in bandwidth testing.

 

With a laptop on site, running against speedtest.net (which kicked me over
to the Comcast speedtest server instance) I can only get 4 Mbps up and 1.5
Mbps down.  That is consistent on their desktops too.  We eliminated their
routing equipment and other consumers of the bandwidth and tested and got
similar results.

 

But when  we run the Mikrotik bandwidth tests (even to off-net Mikrotik
devices in Hawaii and Mission, TX) we get 25+ Mbps synchronous.

 

We have run traceroutes to various traceroute servers and they go through
Cogent and/or Level 3.  For the most part it does not seem to matter which
path it takes, the bandwidth seems to be about the same going both routes.

 

When we run the laptop-based btest.exe against Mikrotik bandwidth test
servers, the laptop got significantly better results (14 Mbps) , but not 25+
Mbps.

 

It is almost like there is a Java based problem with speedtest.net.

 

Thoughts?

 

Thanks,

 

Lorell Hathcock

 


From streiner at cluebyfour.org  Tue Apr  2 00:27:18 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 1 Apr 2013 20:27:18 -0400 (EDT)
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <02d401ce2f37$b63b4f10$22b1ed30$@hathcock.org>
References: <02d401ce2f37$b63b4f10$22b1ed30$@hathcock.org>
Message-ID: <Pine.LNX.4.64.1304012023450.15085@whammy.cluebyfour.org>

On Mon, 1 Apr 2013, Lorell Hathcock wrote:

> I am having some speedtest results that are difficult to interpret.
>
> Some of my customers have begun complaining that they are not getting the
> proper speeds.  They are using speedtest.net and/or speakeasy.net to test
> the results.

Take the speedtest results with a grain of salt.  Once traffic leaves your 
network, you no longer have (much) control over how packets flow across 
the 'rest of the internet'.

Did the customers report when the issue started?
Are they seeing other performance problems (latency/jitter/packet loss)?
Are you sure no internal links/routers are being saturated, even for brief 
periods of time?

jms


From contact at nullivex.com  Tue Apr  2 00:38:11 2013
From: contact at nullivex.com (Bryan Tong)
Date: Mon, 1 Apr 2013 18:38:11 -0600
Subject: New Product Launch from 2600hz
In-Reply-To: <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>
References: <FD4A91ABAD370D4383186A56320046BE084703DF@mbx022-w1-ca-9.exch022.domain.local>
 <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>
Message-ID: <CAAARkvKtoyS6qa5zV0DznSa8V_EeUO9G5_AGGafBFOtzQQfqdQ@mail.gmail.com>

Haha, strange this comes out on April 1st


On Mon, Apr 1, 2013 at 6:06 PM, Owen DeLong <owen at delong.com> wrote:

> Goes in the same category as this bit of news:
>
>
> IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly
> announced that IPv4 would no longer be supported on the global internet
> after 1/1/2014. Those wishing to continue using the internet in 2014 and
> beyond
> should move to IPv6.
>
>
> Owen
>
> On Apr 1, 2013, at 4:09 PM, Joshua Goldbard <j at 2600hz.com> wrote:
>
> > Hello,
> >
> > Normally I wouldn't bother the respected members of NANOG with a product
> launch email, but this is such a unique application that I felt it was
> necessary.
> >
> > 2600hz is saying goodbye to SMS, Voice and even Video. Today we're
> launching a service we'd like to call BrainRTC. It's going to completely
> revolutionize communications.
> >
> > Check it out here:
> http://blog.2600hz.com/post/46886639094/voice-and-video-are-dead-heres-the-future
> >
> > Cheers,
> > Joshua
> >
> > Joshua Goldbard
> > VP of Marketing, 2600hz
> >
> > 116 Natoma Street, Floor 2
> > San Francisco, CA, 94104
> > 415.886.7923 | j at 2600hz.com<mailto:j at 2600hz.com>
>
>
>


-- 
--------------------
Bryan Tong
Nullivex LLC | eSited LLC
(507) 298-1624

From eschwei at comcast.net  Tue Apr  2 00:42:51 2013
From: eschwei at comcast.net (Ed Schweitzer)
Date: Mon, 1 Apr 2013 20:42:51 -0400
Subject: RFC 1149
Message-ID: <001801ce2f3b$0161b6c0$04252440$@net>

Given we are moving into the hurricanes season in a few months, I was
wondering if this is now an accepted standard. I haven't seen many updates -
it appears to be complete as is. 

 

Thanks,

 

 


From mureninc at gmail.com  Tue Apr  2 00:49:22 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Mon, 1 Apr 2013 17:49:22 -0700
Subject: New Product Launch from 2600hz
In-Reply-To: <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>
References: <FD4A91ABAD370D4383186A56320046BE084703DF@mbx022-w1-ca-9.exch022.domain.local>
 <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>
Message-ID: <CAPKkNb4fay2LL2hJ0-ciBqgCVYejEJ9Dmi9bFeN+w4kSC=fbzg@mail.gmail.com>

On 1 April 2013 17:06, Owen DeLong <owen at delong.com> wrote:
> Goes in the same category as this bit of news:
>
>
> IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly announced that IPv4 would no longer be supported on the global internet after 1/1/2014. Those wishing to continue using the internet in 2014 and beyond
> should move to IPv6.


Also same as the http://BXR.SU/ announcement on FreeBSD-hackers@ earlier today.

We've declared 2013-04-04 as an IPv4 day.  We'll publish some A
records temporarily on April 4; permanently on April 14; and we will
finally publish IPv4 glue records for bxr.su on 2013-04-24.

  http://lists.freebsd.org/pipermail/freebsd-hackers/2013-April/042334.html

We're concerned that some systems have misconfigured NAT or other
infrastructure, so, we're delaying IPv4 rollout in order to make sure
that our IPv6 customers are not affected by any kind of IPv4 mishaps.

C.


From marka at isc.org  Tue Apr  2 00:53:03 2013
From: marka at isc.org (Mark Andrews)
Date: Tue, 02 Apr 2013 11:53:03 +1100
Subject: Open Resolver Problems
In-Reply-To: Your message of "Mon, 01 Apr 2013 12:03:53 EDT."
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
Message-ID: <20130402005303.6D57831BAA8B@drugs.dv.isc.org>


In message <44ECD7B5-D9A4-408B-A132-29241DE3A867 at ianai.net>, "Patrick W. Gilmore" writes:
> On Apr 01, 2013, at 11:55 , "Milt Aitken" <milt at net2atlanta.com> wrote:
> 
> > Most of our DSL customers have modem/routers that resolve DNS
> > externally.
> > And most of those have no configuration option to stop it.
> > So, we took the unfortunate step of ACL blocking DNS requests to & from
> > the DSL network unless the requests are to our DNS servers.
> > 
> > Suboptimal, but it stopped the DNS amplification attacks.
> 
> I was going to suggest exactly this.
> 
> Don't most broadband networks have a line in their AUP about running 
> servers? Wouldn't a DNS server count as 'a server'? Then wouldn't running 
> one violate the AUP?
> 
> This gives the provider a hammer to hit the user over the head. Although 
> that is quite unlikely, so the better point is that it also gives the 
> provider cover in case some user complains about the provider filtering.
> 
> You can always make an exception if the user is extremely loud.
> 
> -- 
> TTFN,
> patrick

Actually a lot don't have such a line.  Such lines are tantamount
to extortion especially if the ISP supplies commercial grade lines.

That said blocking by default with the option to open it up on
request, the same as smtp is opened on request, might be viable.

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


From rdobbins at arbor.net  Tue Apr  2 01:06:41 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 01:06:41 +0000
Subject: Open Resolver Problems
In-Reply-To: <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
Message-ID: <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>


On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote:

>  Such lines are tantamount to extortion especially if the ISP supplies commercial grade lines.

Patrick's talking about consumer broadband access.  Such AUP stipulations are quite common.

This is in no way 'tantamount to extortion'.  Folks can either accept the AUP, or choose not to enter into a contract for the service in question under those conditions; there is no compulsion or coercion to do so.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From marka at isc.org  Tue Apr  2 01:21:51 2013
From: marka at isc.org (Mark Andrews)
Date: Tue, 02 Apr 2013 12:21:51 +1100
Subject: Open Resolver Problems
In-Reply-To: Your message of "Tue, 02 Apr 2013 01:06:41 -0000."
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
Message-ID: <20130402012151.2CA8331BAF67@drugs.dv.isc.org>


In message <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4 at arbor.net>, "Dobbins, Roland" writes:
> 
> On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote:
> 
> >  Such lines are tantamount to extortion especially if the ISP supplies 
> commercial grade lines.
> 
> Patrick's talking about consumer broadband access.  Such AUP stipulations 
> are quite common.

I know and I would still argue that they are tantamount to extortion.

> This is in no way 'tantamount to extortion'.  Folks can either accept the 
> AUP, or choose not to enter into a contract for the service in question 
> under those conditions; there is no compulsion or coercion to do so.

So the home user that want to run a server now has to pay for COLO
or pay the ISP for it commercial line that is delivered over the
same physical circuit for extra dollars which gets what?  Maybe a
upgraded SLA and maybe some static addresses.

> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
> 
> 	  Luck is the residue of opportunity and design.
> 
> 		       -- John Milton
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From rdobbins at arbor.net  Tue Apr  2 01:38:09 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 01:38:09 +0000
Subject: Open Resolver Problems
In-Reply-To: <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
Message-ID: <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>


On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote:

> I know and I would still argue that they are tantamount to extortion.

There is no coercion involved, so, by definition, it can't be called 'extortion'.  If you don't like the AUP, don't sign up for the service - simple as that.

Hyperbole isn't generally helpful.

;>

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From owen at delong.com  Tue Apr  2 01:45:22 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Apr 2013 18:45:22 -0700
Subject: Open Resolver Problems
In-Reply-To: <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
Message-ID: <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>


On Apr 1, 2013, at 6:38 PM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:

> 
> On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote:
> 
>> I know and I would still argue that they are tantamount to extortion.
> 
> There is no coercion involved, so, by definition, it can't be called 'extortion'.  If you don't like the AUP, don't sign up for the service - simple as that.
> 
> Hyperbole isn't generally helpful.
> 

In an oligopoly situation, that's hardly a valid set of choices and is tantamount to extortion.

Owen



From fergdawgster at gmail.com  Tue Apr  2 01:52:43 2013
From: fergdawgster at gmail.com (Paul Ferguson)
Date: Mon, 1 Apr 2013 18:52:43 -0700
Subject: Open Resolver Problems
In-Reply-To: <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
Message-ID: <CANQy6FZmFfOTMXawgAM+xm9gb0Hs4TViK=k1-MLnhPJoD7uzSw@mail.gmail.com>

On Mon, Apr 1, 2013 at 6:45 PM, Owen DeLong <owen at delong.com> wrote:

>
> On Apr 1, 2013, at 6:38 PM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
>
>>
>> On Apr 2, 2013, at 8:21 AM, Mark Andrews wrote:
>>
>>> I know and I would still argue that they are tantamount to extortion.
>>
>> There is no coercion involved, so, by definition, it can't be called 'extortion'.  If you don't like the AUP, don't sign up for the service - simple as that.
>>
>> Hyperbole isn't generally helpful.
>>
>
> In an oligopoly situation, that's hardly a valid set of choices and is tantamount to extortion.
>

Yeah, I thought so, too, but apparently the FCC and the SEC hasn't
seen it that way for the past 20 years. Go figure.  :-)

- ferg


--
"Fergie", a.k.a. Paul Ferguson
 fergdawgster(at)gmail.com


From rdobbins at arbor.net  Tue Apr  2 01:54:38 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 01:54:38 +0000
Subject: Open Resolver Problems
In-Reply-To: <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
Message-ID: <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>


On Apr 2, 2013, at 8:45 AM, Owen DeLong wrote:

> In an oligopoly situation, that's hardly a valid set of choices 

There's enough choice in most US markets (not all) to provide for a variety of services offered, AUPs, and price points.  Wireless has brought an additional option to many previously underserved areas.

> and is tantamount to extortion.

Again, hyperbole doesn't help.

Another solution is to move to an area with more/better connectivity options, as some folks move in order to be zoned within a particular school district.

;>

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From rdobbins at arbor.net  Tue Apr  2 01:56:02 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 01:56:02 +0000
Subject: Open Resolver Problems
In-Reply-To: <CANQy6FZmFfOTMXawgAM+xm9gb0Hs4TViK=k1-MLnhPJoD7uzSw@mail.gmail.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <CANQy6FZmFfOTMXawgAM+xm9gb0Hs4TViK=k1-MLnhPJoD7uzSw@mail.gmail.com>
Message-ID: <4F8EA07C-7028-4FD9-B87E-D8ACEC81D6C8@arbor.net>


On Apr 2, 2013, at 8:52 AM, Paul Ferguson wrote:

> Yeah, I thought so, too, but apparently the FCC and the SEC hasn't seen it that way for the past 20 years. Go figure.  :-)

The situation is gradually getting better, not worse - and that's progress, even if it isn't as fast as we'd all like.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From surfer at mauigateway.com  Tue Apr  2 02:18:56 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 1 Apr 2013 19:18:56 -0700
Subject: RFC 1149
Message-ID: <20130401191856.A9FBC877@resin11.mta.everyone.net>



--- eschwei at comcast.net wrote:
From: "Ed Schweitzer" <eschwei at comcast.net>

Given we are moving into the hurricanes season in a few months, I was
wondering if this is now an accepted standard. I haven't seen many updates -
it appears to be complete as is. 
----------------------------------------


Itty bitty rocket motors.  One on each wing tip.  Just have 
to make sure they're balanced, so they don't go into routing 
loops. WMAP (wing motor aggregation protocol? :)

scott


From owen at delong.com  Tue Apr  2 01:58:22 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Apr 2013 18:58:22 -0700
Subject: Open Resolver Problems
In-Reply-To: <CANQy6FZmFfOTMXawgAM+xm9gb0Hs4TViK=k1-MLnhPJoD7uzSw@mail.gmail.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <CANQy6FZmFfOTMXawgAM+xm9gb0Hs4TViK=k1-MLnhPJoD7uzSw@mail.gmail.com>
Message-ID: <9D854674-5BD8-4927-B9EA-77D8AF86988D@delong.com>

> Yeah, I thought so, too, but apparently the FCC and the SEC hasn't
> seen it that way for the past 20 years. Go figure.  :-)
> 

The FCC doesn't understand that 4Mbps customer-facing speed on the tail circuit alone does NOT define broadband in a meaningful way.

The SEC does not understand that IPv4 risk and the lack of an IPv6 strategy should be a required risk consideration in a Sarbanes Oxley filing.

I have little hope that these particular federal agencies will ever agree with me about such nuanced issues.

Owen



From owen at delong.com  Tue Apr  2 02:09:37 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Apr 2013 19:09:37 -0700
Subject: Open Resolver Problems
In-Reply-To: <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>
Message-ID: <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>


On Apr 1, 2013, at 6:54 PM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:

> 
> On Apr 2, 2013, at 8:45 AM, Owen DeLong wrote:
> 
>> In an oligopoly situation, that's hardly a valid set of choices 
> 
> There's enough choice in most US markets (not all) to provide for a variety of services offered, AUPs, and price points.  Wireless has brought an additional option to many previously underserved areas.

With all due respect, sir, you are mistaken.

Even in such populous areas as San Jose, there is a limited selection to a majority of the customers, especially if they want more than 1.5Mbps. In the majority of the US where it is rural, there is even less choice.

Even where there are multiple providers, they often all provide the same limitations in their AUP unless you go to higher priced services.

>> and is tantamount to extortion.
> 
> Again, hyperbole doesn't help.
> 

If all of the choices to eliminate unreasonable restrictions on how you use the bandwidth you pay for involve paying more money for roughly the same service, then that is not hyperbole. Such is the case for a very large fraction of subscribers in the US.

> Another solution is to move to an area with more/better connectivity options, as some folks move in order to be zoned within a particular school district.

It is an option when you live in a neighborhood with a protection racket operating to move out of the neighborhood as well. This does not change the fact that a protection racket is extortion.

Owen



From eaptech at gmail.com  Tue Apr  2 02:15:25 2013
From: eaptech at gmail.com (Eric Adler)
Date: Mon, 1 Apr 2013 22:15:25 -0400
Subject: RFC 1149
In-Reply-To: <001801ce2f3b$0161b6c0$04252440$@net>
References: <001801ce2f3b$0161b6c0$04252440$@net>
Message-ID: <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>

Make sure you don't miss the QoS implementation of RFC 2549 (and make sure
that you're ready to implement RFC 6214).  You'll be highly satisfied with
the results (presuming you and your packets end up in one of the higher
quality classes).
I'd also suggest a RFC 2322 compliant DHCP server for devices inside the
hurricane zone, but modified by implementing zip ties such that the C47s
aren't released under heavy (wind or water) loads.

- Eric

From jeff-kell at utc.edu  Tue Apr  2 02:19:22 2013
From: jeff-kell at utc.edu (Jeff Kell)
Date: Mon, 1 Apr 2013 22:19:22 -0400
Subject: RFC 1149
In-Reply-To: <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
Message-ID: <515A402A.1040001@utc.edu>

On 4/1/2013 10:15 PM, Eric Adler wrote:
> Make sure you don't miss the QoS implementation of RFC 2549 (and make sure
> that you're ready to implement RFC 6214).  You'll be highly satisfied with
> the results (presuming you and your packets end up in one of the higher
> quality classes).
> I'd also suggest a RFC 2322 compliant DHCP server for devices inside the
> hurricane zone, but modified by implementing zip ties such that the C47s
> aren't released under heavy (wind or water) loads.

Actually, given recent events, I'd emphasize and advocate RFC3514
(http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue for
adoption.  The implementation would forego most of the currently debated
topics as related to network abuse or misuse :)

Jeff



From george.herbert at gmail.com  Tue Apr  2 02:37:12 2013
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 1 Apr 2013 19:37:12 -0700
Subject: RFC 1149
In-Reply-To: <515A402A.1040001@utc.edu>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
Message-ID: <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>

Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
routing protocol extension hasn't been experimentally validated yet.

Whoever you are who keeps flying pigeons between my test towers, you can't
deliver packets without proper routing updates!  Knock it off long enough
for me to converge the #@$#$@ routing table...



On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell <jeff-kell at utc.edu> wrote:

> On 4/1/2013 10:15 PM, Eric Adler wrote:
> > Make sure you don't miss the QoS implementation of RFC 2549 (and make
> sure
> > that you're ready to implement RFC 6214).  You'll be highly satisfied
> with
> > the results (presuming you and your packets end up in one of the higher
> > quality classes).
> > I'd also suggest a RFC 2322 compliant DHCP server for devices inside the
> > hurricane zone, but modified by implementing zip ties such that the C47s
> > aren't released under heavy (wind or water) loads.
>
> Actually, given recent events, I'd emphasize and advocate RFC3514
> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue for
> adoption.  The implementation would forego most of the currently debated
> topics as related to network abuse or misuse :)
>
> Jeff
>
>
>


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

From rdobbins at arbor.net  Tue Apr  2 02:38:00 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 02:38:00 +0000
Subject: Open Resolver Problems
In-Reply-To: <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>
 <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>
Message-ID: <B9E5FA01-5FA4-4314-8B96-A31060FE50DC@arbor.net>


On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote:

> With all due respect, sir, you are mistaken.
> 
> Even in such populous areas as San Jose, there is a limited selection to a majority of the customers, especially if they want more than 1.5Mbps.

I lived in San Jose for several years, and had several choices for broadband - the one I chose was much faster than 1mb/sec, had an AUP which specifically allowed me to run a server, and didn't try to cap my bandwidth, or disable the use of p2p apps, or whatever.

I moved away from San Jose in at the tail-end of 2007.  It seems likely that at least the same level of choice prevails there today . . .

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From rdobbins at arbor.net  Tue Apr  2 02:44:49 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 02:44:49 +0000
Subject: Open Resolver Problems
In-Reply-To: <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>
 <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>
Message-ID: <E3E9D90E-14CE-450F-91D2-E57E0558DB65@arbor.net>


On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote:

> In the majority of the US where it is rural, there is even less choice.

Largest in geography <> largest in population.

> Even where there are multiple providers, they often all provide the same limitations in their AUP unless you go to higher priced services.

If you don't like the pricing, that's quite different from claiming extortion.  

Look, I'm no fan of semi-monopolies, 'unlimited' capacity which isn't, and so forth.  But there *are* choices in most US broadband markets; maybe not the choices which we'd find ideal, maybe at a price-point higher than we think is fair, but the point is that there are choices, and nobody is forcing anyone to spend money for services he doesn't wish to purchase.

I'd like to see UK-style structural separation in the US, as that would greatly increase opportunities to compete.  I doubt it will ever happen, though.  

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From fergdawgster at gmail.com  Tue Apr  2 02:48:43 2013
From: fergdawgster at gmail.com (Paul Ferguson)
Date: Mon, 1 Apr 2013 19:48:43 -0700
Subject: Open Resolver Problems
In-Reply-To: <B9E5FA01-5FA4-4314-8B96-A31060FE50DC@arbor.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>
 <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>
 <B9E5FA01-5FA4-4314-8B96-A31060FE50DC@arbor.net>
Message-ID: <CANQy6FYG0MbtTFXRUMgb0sR57ppOjLuS8t3J4p8ug+KGW_k+aA@mail.gmail.com>

On Mon, Apr 1, 2013 at 7:38 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Apr 2, 2013, at 9:09 AM, Owen DeLong wrote:
>
>> Even in such populous areas as San Jose, there is a limited selection to a majority of the customers, especially if they want more than 1.5Mbps.
>
> I lived in San Jose for several years, and had several choices for broadband - the one I chose was much faster than 1mb/sec, had an AUP which specifically allowed me to run a server, and didn't try to cap my bandwidth, or disable the use of p2p apps, or whatever.
>
> I moved away from San Jose in at the tail-end of 2007.  It seems likely that at least the same level of choice prevails there today . . .
>

So, I lived in San Jose, too, for many years, and I had fewer choices
there than I do here now in the Pacific Northwest.

In any event, depending on where you are in the U.S., many consumers
have a choice between bad and worse. :-)

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 fergdawgster(at)gmail.com


From rdobbins at arbor.net  Tue Apr  2 02:54:48 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 2 Apr 2013 02:54:48 +0000
Subject: Open Resolver Problems
In-Reply-To: <CANQy6FYG0MbtTFXRUMgb0sR57ppOjLuS8t3J4p8ug+KGW_k+aA@mail.gmail.com>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
 <20130402012151.2CA8331BAF67@drugs.dv.isc.org>
 <AE5F10FF-B83B-4199-9A9B-1FB0CEA34C8E@arbor.net>
 <A63EAFFB-B874-4E18-9727-8ED8B370376D@delong.com>
 <11A3B40B-535A-4F42-ABBB-45E949576E5B@arbor.net>
 <C55A659F-6F2A-4DA2-A713-6B128C44267A@delong.com>
 <B9E5FA01-5FA4-4314-8B96-A31060FE50DC@arbor.net>
 <CANQy6FYG0MbtTFXRUMgb0sR57ppOjLuS8t3J4p8ug+KGW_k+aA@mail.gmail.com>
Message-ID: <78F7DB78-692C-486F-859E-BFCE0CA78D47@arbor.net>


On Apr 2, 2013, at 9:48 AM, Paul Ferguson wrote:

> In any event, depending on where you are in the U.S., many consumers have a choice between bad and worse. :-)

I certainly do agree with that general sentiment.  Living abroad, I have more choices in terms of both wired broadband and wireless.  And 'unlimited' really means unlimited.

If I ever moved back to the US, one of the things I would miss the most is complete freedom in terms of wireless network choice, service level, and traffic tiering.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From swmike at swm.pp.se  Tue Apr  2 03:25:53 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 2 Apr 2013 05:25:53 +0200 (CEST)
Subject: Open Resolver Problems
In-Reply-To: <20130401231413.GA2136@besserwisser.org>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
 <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
 <20130401202142.GU55976@burnout.tpb.net>
 <20130401231413.GA2136@besserwisser.org>
Message-ID: <alpine.DEB.2.00.1304020522390.23668@uplift.swm.pp.se>

On Tue, 2 Apr 2013, M?ns Nilsson wrote:

> What percentage of the SOHO NAT boxes actually are full-service 
> resolvers? I was under the impression that most were mere forwarders; 
> just pushing queries on toward the DHCP'd full service resolvers of the 
> ISP.

What does that help? They can still be amplifiers, it's just that now the 
ISP resolver will see the resolving load as well.

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

From mysidia at gmail.com  Tue Apr  2 08:33:37 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 2 Apr 2013 03:33:37 -0500
Subject: BCP38 tester?
In-Reply-To: <27877536.446.1364833865691.JavaMail.root@benjamin.baylink.com>
References: <CAAAwwbWMSoWBvPnD5_tJhV67hcjnsa=Grij-k2PgUOn19Ac0=A@mail.gmail.com>
 <27877536.446.1364833865691.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAAAwwbXX7wg--_y297Q5KFOypwL7L5oGMpDZMfYsT4632mqVog@mail.gmail.com>

On 4/1/13, Jay Ashworth <jra at baylink.com> wrote:
>> It would just be way too much luck and convenience for that to happen
>> by coincidence.
>
> Once in a while, you win.

The trouble with winning by coincidence or winning as a side-effect...
Do you keep winning?

What happens with IPv6 CPE devices,  when there is no NAT?
No translation occurs, so possibly  rogue source IP packets get
through,  unless the device specifically applies uRPF  or clamping
source addresses to the LAN interface subnet.

It would be nice if the RFCs specified Ingress filtering by default in
router requirements for IPv4 and IPv6, as a MUST requirement;  instead
of  some   2nd class citizen, optional  best practices document.

By specifying ingress as the default, it then becomes an implementor
responsibility to understand when and where in their network they have
to override the default for things to work properly,  when it is safe
to,   and where the filtering is required.

--
-JH


From mansaxel at besserwisser.org  Tue Apr  2 08:55:34 2013
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Tue, 2 Apr 2013 10:55:34 +0200
Subject: Open Resolver Problems
In-Reply-To: <alpine.DEB.2.00.1304020522390.23668@uplift.swm.pp.se>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <5C89A2B7-5832-4055-A41A-6529059C7F7C@arbor.net>
 <6E2EB923-428B-4DBD-9AE6-5E2D670ED5D4@ianai.net>
 <20130401202142.GU55976@burnout.tpb.net>
 <20130401231413.GA2136@besserwisser.org>
 <alpine.DEB.2.00.1304020522390.23668@uplift.swm.pp.se>
Message-ID: <20130402085534.GB2136@besserwisser.org>

Subject: Re: Open Resolver Problems Date: Tue, Apr 02, 2013 at 05:25:53AM +0200 Quoting Mikael Abrahamsson (swmike at swm.pp.se):
> On Tue, 2 Apr 2013, M?ns Nilsson wrote:
> 
> >What percentage of the SOHO NAT boxes actually are full-service
> >resolvers? I was under the impression that most were mere
> >forwarders; just pushing queries on toward the DHCP'd full service
> >resolvers of the ISP.
> 
> What does that help? They can still be amplifiers, it's just that
> now the ISP resolver will see the resolving load as well.

But, yes, of course. Nobody would be so stupid so ast o accept queries
on the WAN side and answer them? Would they? </innocent>

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
My vaseline is RUNNING...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130402/e9f66441/attachment.bin>

From jamie at photon.com  Tue Apr  2 11:28:23 2013
From: jamie at photon.com (Jamie Bowden)
Date: Tue, 2 Apr 2013 11:28:23 +0000
Subject: Open Resolver Problems
In-Reply-To: <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
References: <A7B8F84D333A7948AB7F860A8A68E25D0137BFCE@terminator.net2atlanta.local>
 <44ECD7B5-D9A4-408B-A132-29241DE3A867@ianai.net>
 <20130402005303.6D57831BAA8B@drugs.dv.isc.org>
 <CF4E9F59-4A9E-4E03-8EB4-469C3DB15FF4@arbor.net>
Message-ID: <465966A5F5B867419F604CD3E604C1E53B09B3A1@PRA-DCA-MAIL.pra.ray.com>

> From: Dobbins, Roland [mailto:rdobbins at arbor.net]
> On Apr 2, 2013, at 7:53 AM, Mark Andrews wrote:


> >  Such lines are tantamount to extortion especially if the ISP supplies
> commercial grade lines.


> Patrick's talking about consumer broadband access.  Such AUP stipulations
> are quite common.


> This is in no way 'tantamount to extortion'.  Folks can either accept the AUP,
> or choose not to enter into a contract for the service in question under those
> conditions; there is no compulsion or coercion to do so.

And that would be a valid response if we actually lived in a place where I, or anyone else, had more than two choices, both offering roughly the same terms and pricing.  In my little corner of Fairfax Co, we have Cox or FiOS.  Across the Potomac in Montgomery, they can pick between Comcast and FiOS.  I hear that in other bits of the US, your cable and telco might be different, but other than the label, nothing else is.

Jamie


From jared at puck.nether.net  Tue Apr  2 12:55:46 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 2 Apr 2013 08:55:46 -0400
Subject: RFC 1149
In-Reply-To: <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
Message-ID: <0E238B7A-3509-43FC-B792-9284CB76ACC8@puck.nether.net>


On Apr 1, 2013, at 10:37 PM, George Herbert <george.herbert at gmail.com> wrote:

> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
> routing protocol extension hasn't been experimentally validated yet.
> 
> Whoever you are who keeps flying pigeons between my test towers, you can't
> deliver packets without proper routing updates!  Knock it off long enough
> for me to converge the #@$#$@ routing table...

I'm working to make our network comply with the latest standards in rfc6919

- Jared


From jra at baylink.com  Tue Apr  2 14:37:22 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 2 Apr 2013 10:37:22 -0400 (EDT)
Subject: BCP38 tester?
In-Reply-To: <CAAAwwbXX7wg--_y297Q5KFOypwL7L5oGMpDZMfYsT4632mqVog@mail.gmail.com>
Message-ID: <9195033.538.1364913442890.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jimmy Hess" <mysidia at gmail.com>

> On 4/1/13, Jay Ashworth <jra at baylink.com> wrote:
> >> It would just be way too much luck and convenience for that to
> >> happen
> >> by coincidence.
> >
> > Once in a while, you win.
> 
> The trouble with winning by coincidence or winning as a side-effect...
> Do you keep winning?

Depends on how you won.

> What happens with IPv6 CPE devices, when there is no NAT?

Well, that's going to be an interesting question in general: 
will v6 edge routers a) exist, b) handle the addressing, c) handle
DHCP, d) actually not do NAT, or e) NAT a v4 home network to a v6
address/network?

> No translation occurs, so possibly rogue source IP packets get
> through, unless the device specifically applies uRPF or clamping
> source addresses to the LAN interface subnet.
> 
> It would be nice if the RFCs specified Ingress filtering by default in
> router requirements for IPv4 and IPv6, as a MUST requirement; instead
> of some 2nd class citizen, optional best practices document.

Nah.  That's *not* ingress filtering, for all practical purposes; it's 
*egress* filtering -- filtering that's under control of the network 
operating entity, and thus semi-useless for the purposes at hand.

(On re-reading that, I see I'm not entirely clear: any filtering has to
be done on the upsptream end of the link, so that it is *not* in control
of the entity which might be originating the bad packets; John Carmack
illustrated why in his piece about Quake cheating.  What; you haven't 
read that piece?  And you run networks?  :-)

Cheers,
-- jra

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From bjohnson at drtel.com  Tue Apr  2 15:38:22 2013
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 2 Apr 2013 15:38:22 +0000
Subject: New Product Launch from 2600hz
In-Reply-To: <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>
References: <FD4A91ABAD370D4383186A56320046BE084703DF@mbx022-w1-ca-9.exch022.domain.local>
 <451FFCEF-F1EB-4F9B-B790-05DA22F4A7AB@delong.com>
Message-ID: <F05D77A9631CAE4097F7B69095F1B06FD63B7524@EX02.drtel.lan>

Owen,

Was this actually posted anywhere. I'm pretty sure it's a joke, but I would like to send it to a vendor who keeps asking when we will need IPv6 support :)

Thanks.

Brian Johnson
Converged Network Engineer
CCNP, CCNP Security & MEF-CECP Certified

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Monday, April 01, 2013 7:07 PM
> To: Joshua Goldbard
> Cc: <nanog at nanog.org>
> Subject: Re: New Product Launch from 2600hz
> 
> Goes in the same category as this bit of news:
> 
> 
> IETF Announces IPv4 flag day for 1/1/2014. Today, IETF and IESG jointly
> announced that IPv4 would no longer be supported on the global internet
> after 1/1/2014. Those wishing to continue using the internet in 2014 and
> beyond
> should move to IPv6.
> 
> 
> Owen
> 
> On Apr 1, 2013, at 4:09 PM, Joshua Goldbard <j at 2600hz.com> wrote:
> 
> > Hello,
> >
> > Normally I wouldn't bother the respected members of NANOG with a
> product launch email, but this is such a unique application that I felt it was
> necessary.
> >
> > 2600hz is saying goodbye to SMS, Voice and even Video. Today we're
> launching a service we'd like to call BrainRTC. It's going to completely
> revolutionize communications.
> >
> > Check it out here: http://blog.2600hz.com/post/46886639094/voice-and-
> video-are-dead-heres-the-future
> >
> > Cheers,
> > Joshua
> >
> > Joshua Goldbard
> > VP of Marketing, 2600hz
> >
> > 116 Natoma Street, Floor 2
> > San Francisco, CA, 94104
> > 415.886.7923 | j at 2600hz.com<mailto:j at 2600hz.com>
> 



From scott at sberkman.net  Tue Apr  2 18:31:41 2013
From: scott at sberkman.net (Scott Berkman)
Date: Tue, 2 Apr 2013 14:31:41 -0400
Subject: RFC 1149
In-Reply-To: <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
Message-ID: <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>

Hey careful, Pigeons have won this fight before:

http://news.bbc.co.uk/2/hi/8248056.stm

-----Original Message-----
From: George Herbert [mailto:george.herbert at gmail.com] 
Sent: Monday, April 01, 2013 10:37 PM
To: Jeff Kell
Cc: NANOG
Subject: Re: RFC 1149

Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
routing protocol extension hasn't been experimentally validated yet.

Whoever you are who keeps flying pigeons between my test towers, you can't
deliver packets without proper routing updates!  Knock it off long enough
for me to converge the #@$#$@ routing table...



On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell <jeff-kell at utc.edu> wrote:

> On 4/1/2013 10:15 PM, Eric Adler wrote:
> > Make sure you don't miss the QoS implementation of RFC 2549 (and 
> > make
> sure
> > that you're ready to implement RFC 6214).  You'll be highly 
> > satisfied
> with
> > the results (presuming you and your packets end up in one of the 
> > higher quality classes).
> > I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
> > the hurricane zone, but modified by implementing zip ties such that 
> > the C47s aren't released under heavy (wind or water) loads.
>
> Actually, given recent events, I'd emphasize and advocate RFC3514
> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
> for adoption.  The implementation would forego most of the currently 
> debated topics as related to network abuse or misuse :)
>
> Jeff
>
>
>


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



From owen at delong.com  Tue Apr  2 19:41:06 2013
From: owen at delong.com (Owen DeLong)
Date: Tue, 2 Apr 2013 12:41:06 -0700
Subject: RFC 1149
In-Reply-To: <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
 <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
Message-ID: <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>

"Never underestimate the bandwidth of a 747 full of DLT cartridges."

Owen

On Apr 2, 2013, at 11:31 , "Scott Berkman" <scott at sberkman.net> wrote:

> Hey careful, Pigeons have won this fight before:
> 
> http://news.bbc.co.uk/2/hi/8248056.stm
> 
> -----Original Message-----
> From: George Herbert [mailto:george.herbert at gmail.com] 
> Sent: Monday, April 01, 2013 10:37 PM
> To: Jeff Kell
> Cc: NANOG
> Subject: Re: RFC 1149
> 
> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
> routing protocol extension hasn't been experimentally validated yet.
> 
> Whoever you are who keeps flying pigeons between my test towers, you can't
> deliver packets without proper routing updates!  Knock it off long enough
> for me to converge the #@$#$@ routing table...
> 
> 
> 
> On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
> 
>> On 4/1/2013 10:15 PM, Eric Adler wrote:
>>> Make sure you don't miss the QoS implementation of RFC 2549 (and 
>>> make
>> sure
>>> that you're ready to implement RFC 6214).  You'll be highly 
>>> satisfied
>> with
>>> the results (presuming you and your packets end up in one of the 
>>> higher quality classes).
>>> I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
>>> the hurricane zone, but modified by implementing zip ties such that 
>>> the C47s aren't released under heavy (wind or water) loads.
>> 
>> Actually, given recent events, I'd emphasize and advocate RFC3514
>> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
>> for adoption.  The implementation would forego most of the currently 
>> debated topics as related to network abuse or misuse :)
>> 
>> Jeff
>> 
>> 
>> 
> 
> 
> --
> -george william herbert
> george.herbert at gmail.com
> 



From trejrco at gmail.com  Tue Apr  2 19:53:43 2013
From: trejrco at gmail.com (TJ)
Date: Tue, 2 Apr 2013 15:53:43 -0400
Subject: RFC 1149
In-Reply-To: <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
 <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
 <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
Message-ID: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>

On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong <owen at delong.com> wrote:

> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
>
> Owen


XKCD is all over this: http://what-if.xkcd.com/31/
:)

/TJ

From lorell at hathcock.org  Tue Apr  2 19:54:48 2013
From: lorell at hathcock.org (Lorell Hathcock)
Date: Tue, 2 Apr 2013 14:54:48 -0500
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <Pine.LNX.4.64.1304012023450.15085@whammy.cluebyfour.org>
References: <02d401ce2f37$b63b4f10$22b1ed30$@hathcock.org>
 <Pine.LNX.4.64.1304012023450.15085@whammy.cluebyfour.org>
Message-ID: <043401ce2fdb$eed14b00$cc73e100$@hathcock.org>

Thanks for the many helpful suggestions I received offline.

One thing that I was able to deduce was that one of the radios along the
path had Ethernet auto negotiate turned on.  I turned it off and the TCP
speeds went way up.  It seems that UDP was not affected by this setting
while TCP was.

Thanks again!

Lorell



-----Original Message-----
From: Justin M. Streiner [mailto:streiner at cluebyfour.org] 
Sent: Monday, April 01, 2013 7:27 PM
To: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

On Mon, 1 Apr 2013, Lorell Hathcock wrote:

> I am having some speedtest results that are difficult to interpret.
>
> Some of my customers have begun complaining that they are not getting 
> the proper speeds.  They are using speedtest.net and/or speakeasy.net 
> to test the results.

Take the speedtest results with a grain of salt.  Once traffic leaves your
network, you no longer have (much) control over how packets flow across the
'rest of the internet'.

Did the customers report when the issue started?
Are they seeing other performance problems (latency/jitter/packet loss)?
Are you sure no internal links/routers are being saturated, even for brief
periods of time?

jms



From jra at baylink.com  Tue Apr  2 21:19:53 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 2 Apr 2013 17:19:53 -0400 (EDT)
Subject: RFC 1149
In-Reply-To: <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
Message-ID: <8281025.636.1364937593238.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Owen DeLong" <owen at delong.com>

> "Never underestimate the bandwidth of a 747 full of DLT cartridges."

Aww.... you remembered.

  http://baylink.pitas.com/20110516.html#747F

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From jra at baylink.com  Tue Apr  2 21:21:09 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 2 Apr 2013 17:21:09 -0400 (EDT)
Subject: RFC 1149
In-Reply-To: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>
Message-ID: <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "TJ" <trejrco at gmail.com>

> On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong <owen at delong.com> wrote:
> 
> > "Never underestimate the bandwidth of a 747 full of DLT cartridges."
> 
> XKCD is all over this: http://what-if.xkcd.com/31/
> :)

I have always wondered what kind of station wagon Andy had in mind; the
SRT-8 Magnum didn't exist when he said that...

Cheers,
-- jr 'hurtling?' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From carlos at race.com  Tue Apr  2 21:24:43 2013
From: carlos at race.com (Carlos Alcantar)
Date: Tue, 2 Apr 2013 21:24:43 +0000
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <043401ce2fdb$eed14b00$cc73e100$@hathcock.org>
Message-ID: <CD8099F0.8E687%carlos@race.com>

You might want to consider putting up a speedtest server internal to your
network.  I know there is a fee but well worth it I believe.  You will
still need to take the results with a grain a salt but you will have the
best results as well.

Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Lorell Hathcock <lorell at hathcock.org>
Date: Tuesday, April 2, 2013 12:54 PM
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: RE: Speedtest Results speedtest.net vs Mikrotik bandwidth test

Thanks for the many helpful suggestions I received offline.

One thing that I was able to deduce was that one of the radios along the
path had Ethernet auto negotiate turned on.  I turned it off and the TCP
speeds went way up.  It seems that UDP was not affected by this setting
while TCP was.

Thanks again!

Lorell



-----Original Message-----
From: Justin M. Streiner [mailto:streiner at cluebyfour.org]
Sent: Monday, April 01, 2013 7:27 PM
To: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

On Mon, 1 Apr 2013, Lorell Hathcock wrote:

> I am having some speedtest results that are difficult to interpret.
>
> Some of my customers have begun complaining that they are not getting
> the proper speeds.  They are using speedtest.net and/or speakeasy.net
> to test the results.

Take the speedtest results with a grain of salt.  Once traffic leaves your
network, you no longer have (much) control over how packets flow across the
'rest of the internet'.

Did the customers report when the issue started?
Are they seeing other performance problems (latency/jitter/packet loss)?
Are you sure no internal links/routers are being saturated, even for brief
periods of time?

jms






From pfunix at gmail.com  Tue Apr  2 21:55:40 2013
From: pfunix at gmail.com (Beavis)
Date: Tue, 2 Apr 2013 15:55:40 -0600
Subject: Mikrotik visibility
Message-ID: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>

Hello All,

I would like to ask if there are any folks out there that use any
specific tool (OpenSource/Closed) that is used for mikrotik routers. I
need packet visibility (ala netflow) or anything similar to that
effect.


any suggestions are greatly appreciated.


cheers,
-Beavis

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/


From surfer at mauigateway.com  Tue Apr  2 22:37:46 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 2 Apr 2013 15:37:46 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
Message-ID: <20130402153746.A9FAF887@resin11.mta.everyone.net>



------------------------
You might want to consider putting up a speedtest server internal to your
network.  I know there is a fee but well worth it I believe.  You will
------------------------


I would consider NDT as well: www.internet2.edu/performance/ndt

Last I checked, about 3 years ago, speedtest sent only latin text in
large packets.  NDT tests much more.  The customers just use a web
browser and the only caveat is they need to have Java working.

Here's one to get a feeling of what your customers will see:
http://ndt.anl.gov:7123

scott


From jtk at cymru.com  Tue Apr  2 22:18:08 2013
From: jtk at cymru.com (John Kristoff)
Date: Tue, 2 Apr 2013 17:18:08 -0500
Subject: Open Resolver Problems
In-Reply-To: <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
 <8720.1364840876@turing-police.cc.vt.edu>
 <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>
Message-ID: <20130402171808.24503d94@localhost>

On Mon, 1 Apr 2013 20:33:36 +0200 (CEST)
Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> > You're sending queries, not replies.  That's why DPI is needed to
> > do the blocking, rather than just by port.
> 
> What queries are sourced from port 53 nowadays?

I would expect from stubs this will be close enough to zero to be
effectively zero.  At least I would hope so.  I don't have a great
source of insight for a resolver of this type of source data that I
can easily look at the moment, but if someone does I'd be interested
to hear otherwise.

On the authoritative side, which is easier for me to examine however,
when I've looked at this before, and the last time was a year ago it
was about 1% of all queries came from resolvers using source port 53.  I
just now checked another server and the percentage is practically the
same.  Before anyone dismisses 1% of queries as insignificant, keep in
mind that if all remaining queries from all other possible source port
values were equally distributed, that 1% (1 out of 100) is easily more
common than any other.

John


From jtk at cymru.com  Tue Apr  2 22:29:00 2013
From: jtk at cymru.com (John Kristoff)
Date: Tue, 2 Apr 2013 17:29:00 -0500
Subject: Open Resolver Problems
In-Reply-To: <28E62B39-8102-413A-A11F-62D8BC6CEF65@dotat.at>
References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net>
 <alpine.DEB.2.00.1303251530280.2309@uplift.swm.pp.se>
 <51506F59.7080101@foobar.org>
 <13438.1364226293@turing-police.cc.vt.edu>
 <5156624B.7030708@gmail.com>
 <CAAAwwbVHfGYN824_R_zeiYbRU9aFytG=zbmiQjnz1h19agbGLg@mail.gmail.com>
 <128114.1364786180@turing-police.cc.vt.edu>
 <27AC6071-0CF2-491F-9B8F-0E04C732A6C2@puck.nether.net>
 <28E62B39-8102-413A-A11F-62D8BC6CEF65@dotat.at>
Message-ID: <20130402172900.433639d6@localhost>

On Mon, 1 Apr 2013 19:40:03 +0100
Tony Finch <dot at dotat.at> wrote:

> You should be able to get a reasonable sample of IPv6 resolvers from
> the query logs of a popular authoritative server.

When I tried this in the past for IPv4, I missed the majority of
potential open resolvers / open forwarders on the net compared to just
searching the entire address space.  And I was examining this from
the perspective of what a very large TLD was seeing.

I think it is likely that there are going to be a significant number of
IPv6-based resolvers that are aren't as easily knowable. This of course
is potentially good too, since if they are really that hard to find,
then it makes them less likely to be as easily abused.

So, in addition to BCP 38 (and don't forget to mention BCP 84 in the
same breath), RRL for auth servers and hardening/closing resolvers... we
should be advocating the migration to DNS over IPv6-only?  :-)

John


From the.lists at mgm51.com  Tue Apr  2 22:33:40 2013
From: the.lists at mgm51.com (Mike.)
Date: Tue, 02 Apr 2013 18:33:40 -0400
Subject: RFC 1149
In-Reply-To: <8281025.636.1364937593238.JavaMail.root@benjamin.baylink.com>
References: <8281025.636.1364937593238.JavaMail.root@benjamin.baylink.com>
Message-ID: <201304021833400763.022A184B@sentry.24cl.com>


On 4/2/2013 at 5:19 PM Jay Ashworth wrote:

|----- Original Message -----
|> From: "Owen DeLong" <owen at delong.com>
|
|> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
|
|Aww.... you remembered.
|
|  http://baylink.pitas.com/20110516.html#747F
 =============

Staying more in the realm of what most on this list can afford... what
is the bandwidth of the following, when loaded with DLT carts - USPS
11" x 8-1/2" x 5-1/2" box, $40, 2 day delivery in the US










From jabley at hopcount.ca  Tue Apr  2 22:41:17 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 2 Apr 2013 18:41:17 -0400
Subject: Open Resolver Problems
In-Reply-To: <20130402171808.24503d94@localhost>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
 <8720.1364840876@turing-police.cc.vt.edu>
 <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>
 <20130402171808.24503d94@localhost>
Message-ID: <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>


On 2013-04-02, at 18:18, John Kristoff <jtk at cymru.com> wrote:

> I would expect from stubs this will be close enough to zero to be
> effectively zero.  At least I would hope so.

This (below) is one of four resolvers, together providing service for two recursive DNS servers used by residential DSL and cable internet users at a medium-sized ISP in Canada. These resolvers are running unbound, which will never choose a source port of 53 on an outbound query; hence anything we see here with src port = dst port = 53 is one of those effective zeros.

[dns1-p1:~]% sudo tcpdump -i em0 -n -c 10000 -w sample.pcap udp port 53   
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
10000 packets captured
10267 packets received by filter
0 packets dropped by kernel
[dns1-p1:~]% tcpdump -r sample.pcap -q udp src port 53 and udp dst port 53 | wc -l
reading from file sample.pcap, link-type EN10MB (Ethernet)
      26
[dns1-p1:~]% 

26/1000 is more than zero but still quite small. Subsequent samples with bigger sizes give 332/100000, 3017/1000000.

No science here, but 2% - 3% is what it looks like, which is big enough to be a noticeable support cost for a medium-scale provider if the customer damage is not robo-mediated in some way (e.g. whitelist known offenders to avoid the support phone glowing red when you first turn it on).


Joe

From smb at cs.columbia.edu  Tue Apr  2 22:44:57 2013
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Tue, 2 Apr 2013 18:44:57 -0400
Subject: RFC 1149 
In-Reply-To: <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
 <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
 <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
Message-ID: <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>

DLT?  I first heard it as a station wagon full of (9-track, 1600 bpi,
that having been the state of the art) mag tapes on the Taconic Parkway,
circa 1970.  I suspect, though, that Herman Hollerith expressed the idea 
about a stage coach full of punchcards, back in the 1880s.


On Apr 2, 2013, at 3:41 PM, Owen DeLong <owen at delong.com> wrote:

> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
> 
> Owen
> 
> On Apr 2, 2013, at 11:31 , "Scott Berkman" <scott at sberkman.net> wrote:
> 
>> Hey careful, Pigeons have won this fight before:
>> 
>> http://news.bbc.co.uk/2/hi/8248056.stm
>> 
>> -----Original Message-----
>> From: George Herbert [mailto:george.herbert at gmail.com] 
>> Sent: Monday, April 01, 2013 10:37 PM
>> To: Jeff Kell
>> Cc: NANOG
>> Subject: Re: RFC 1149
>> 
>> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
>> routing protocol extension hasn't been experimentally validated yet.
>> 
>> Whoever you are who keeps flying pigeons between my test towers, you can't
>> deliver packets without proper routing updates!  Knock it off long enough
>> for me to converge the #@$#$@ routing table...
>> 
>> 
>> 
>> On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
>> 
>>> On 4/1/2013 10:15 PM, Eric Adler wrote:
>>>> Make sure you don't miss the QoS implementation of RFC 2549 (and 
>>>> make
>>> sure
>>>> that you're ready to implement RFC 6214).  You'll be highly 
>>>> satisfied
>>> with
>>>> the results (presuming you and your packets end up in one of the 
>>>> higher quality classes).
>>>> I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
>>>> the hurricane zone, but modified by implementing zip ties such that 
>>>> the C47s aren't released under heavy (wind or water) loads.
>>> 
>>> Actually, given recent events, I'd emphasize and advocate RFC3514
>>> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
>>> for adoption.  The implementation would forego most of the currently 
>>> debated topics as related to network abuse or misuse :)
>>> 
>>> Jeff
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> -george william herbert
>> george.herbert at gmail.com
>> 
> 
> 
> 


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







From the.lists at mgm51.com  Tue Apr  2 23:00:35 2013
From: the.lists at mgm51.com (Mike.)
Date: Tue, 02 Apr 2013 19:00:35 -0400
Subject: RFC 1149
In-Reply-To: <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
 <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
 <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
 <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>
Message-ID: <201304021900350661.0242BC77@sentry.24cl.com>

On 4/2/2013 at 6:44 PM Steven Bellovin wrote:

|DLT?  I first heard it as a station wagon full of (9-track, 1600 bpi,
|that having been the state of the art) mag tapes on the Taconic
Parkway,
|circa 1970.  I suspect, though, that Herman Hollerith expressed the
idea 
|about a stage coach full of punchcards, back in the 1880s.
================


Oddly, prehaps, those punchcards on the stagecoaches probably will
outlast any magnetic media we have at our disposal today....



From frnkblk at iname.com  Tue Apr  2 23:15:19 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 2 Apr 2013 18:15:19 -0500
Subject: 80 km BiDi XFPs
Message-ID: <000101ce2ff7$f17446c0$d45cd440$@iname.com>

Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
supplier of generics doesn't have an option for us, but I would really like
to avoid leasing additional fibers.

Frank



From jtk at cymru.com  Tue Apr  2 23:16:23 2013
From: jtk at cymru.com (John Kristoff)
Date: Tue, 2 Apr 2013 18:16:23 -0500
Subject: Open Resolver Problems
In-Reply-To: <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
 <8720.1364840876@turing-police.cc.vt.edu>
 <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>
 <20130402171808.24503d94@localhost>
 <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>
Message-ID: <20130402181623.7c92b485@localhost>

On Tue, 2 Apr 2013 18:41:17 -0400
Joe Abley <jabley at hopcount.ca> wrote:

> 26/1000 is more than zero but still quite small. Subsequent samples
> with bigger sizes give 332/100000, 3017/1000000.
> 
> No science here, but 2% - 3% is what it looks like, which is big
> enough to be a noticeable support cost for a medium-scale provider if
> the customer damage is not robo-mediated in some way (e.g. whitelist
> known offenders to avoid the support phone glowing red when you first
> turn it on).

Thanks Joe.  That is interesting.

I can only imagine that on the customer side there are queries coming
from something other than typical OS stub resolvers on unix and
Windows based hosts.  I suppose some sort of NAT/PAT box could account
for some of it, maybe more likely could be some common CPE forwarder
that uses that port by default.  If the latter, that might be
considered a serious enough risk that the vendor should address it if
they haven't already.

If no one else does, another side project I'll add to my list of things
to do on a rainy day.

John


From alex.presse at gmail.com  Wed Apr  3 00:40:57 2013
From: alex.presse at gmail.com (=?ISO-8859-1?Q?Alex_Press=E9?=)
Date: Tue, 2 Apr 2013 18:40:57 -0600
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <20130402153746.A9FAF887@resin11.mta.everyone.net>
References: <20130402153746.A9FAF887@resin11.mta.everyone.net>
Message-ID: <CAHsQCrvfm9WDbZdAW27qUcBPm09UMmZ_8pkJYRNEgfe_+ibWSQ@mail.gmail.com>

The speedtest.net site has a free mini edition
(http://www.speedtest.net/mini.php) you can download and extract to
some http available path (asp, php, jsp all supported). It's a flash
applet, easy to wrap into your own page. Transfers one of ten large
JPG files of random noise (largest is 31MB). IIRC, it somehow does a
pretest to select a file that should take > 10 seconds.

If you're connected at >100Mbit to the hosting server then the results
are rather bogus (not enough time in flight to get any meaningful
averages).

Demos (found via google): https://test.kems.net/
http://speedtest.qualitynet.net/ http://speedtest.fsr.com/

Pros: not a java applet
Cons: adobe flash applet

On Tue, Apr 2, 2013 at 4:37 PM, Scott Weeks <surfer at mauigateway.com> wrote:
>
>
> ------------------------
> You might want to consider putting up a speedtest server internal to your
> network.  I know there is a fee but well worth it I believe.  You will
> ------------------------
>
>
> I would consider NDT as well: www.internet2.edu/performance/ndt
>
> Last I checked, about 3 years ago, speedtest sent only latin text in
> large packets.  NDT tests much more.  The customers just use a web
> browser and the only caveat is they need to have Java working.
>
> Here's one to get a feeling of what your customers will see:
> http://ndt.anl.gov:7123
>
> scott
>



-- 
Alex Presse
"How much net work could a network work if a network could net work?"


From owen at delong.com  Wed Apr  3 00:41:12 2013
From: owen at delong.com (Owen DeLong)
Date: Tue, 2 Apr 2013 17:41:12 -0700
Subject: RFC 1149 
In-Reply-To: <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
 <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
 <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
 <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>
Message-ID: <D28E1290-D81C-404A-BF53-0613DF26B7C0@delong.com>

Things get upgraded over time.

Owen

On Apr 2, 2013, at 15:44 , Steven Bellovin <smb at cs.columbia.edu> wrote:

> DLT?  I first heard it as a station wagon full of (9-track, 1600 bpi,
> that having been the state of the art) mag tapes on the Taconic Parkway,
> circa 1970.  I suspect, though, that Herman Hollerith expressed the idea 
> about a stage coach full of punchcards, back in the 1880s.
> 
> 
> On Apr 2, 2013, at 3:41 PM, Owen DeLong <owen at delong.com> wrote:
> 
>> "Never underestimate the bandwidth of a 747 full of DLT cartridges."
>> 
>> Owen
>> 
>> On Apr 2, 2013, at 11:31 , "Scott Berkman" <scott at sberkman.net> wrote:
>> 
>>> Hey careful, Pigeons have won this fight before:
>>> 
>>> http://news.bbc.co.uk/2/hi/8248056.stm
>>> 
>>> -----Original Message-----
>>> From: George Herbert [mailto:george.herbert at gmail.com] 
>>> Sent: Monday, April 01, 2013 10:37 PM
>>> To: Jeff Kell
>>> Cc: NANOG
>>> Subject: Re: RFC 1149
>>> 
>>> Packets, shmackets.  I'm just upset that my BGP over Semaphore Towers
>>> routing protocol extension hasn't been experimentally validated yet.
>>> 
>>> Whoever you are who keeps flying pigeons between my test towers, you can't
>>> deliver packets without proper routing updates!  Knock it off long enough
>>> for me to converge the #@$#$@ routing table...
>>> 
>>> 
>>> 
>>> On Mon, Apr 1, 2013 at 7:19 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
>>> 
>>>> On 4/1/2013 10:15 PM, Eric Adler wrote:
>>>>> Make sure you don't miss the QoS implementation of RFC 2549 (and 
>>>>> make
>>>> sure
>>>>> that you're ready to implement RFC 6214).  You'll be highly 
>>>>> satisfied
>>>> with
>>>>> the results (presuming you and your packets end up in one of the 
>>>>> higher quality classes).
>>>>> I'd also suggest a RFC 2322 compliant DHCP server for devices inside 
>>>>> the hurricane zone, but modified by implementing zip ties such that 
>>>>> the C47s aren't released under heavy (wind or water) loads.
>>>> 
>>>> Actually, given recent events, I'd emphasize and advocate RFC3514
>>>> (http://www.ietf.org/rfc/rfc3514.txt) which I think is LONG overdue 
>>>> for adoption.  The implementation would forego most of the currently 
>>>> debated topics as related to network abuse or misuse :)
>>>> 
>>>> Jeff
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> -george william herbert
>>> george.herbert at gmail.com
>>> 
>> 
>> 
>> 
> 
> 
> 		--Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 



From jra at baylink.com  Wed Apr  3 01:16:08 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 2 Apr 2013 21:16:08 -0400 (EDT)
Subject: RFC 1149
In-Reply-To: <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>
Message-ID: <23415990.646.1364951768781.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Steven Bellovin" <smb at cs.columbia.edu>

> DLT? I first heard it as a station wagon full of (9-track, 1600 bpi,
> that having been the state of the art) mag tapes on the Taconic Parkway,
> circa 1970. I suspect, though, that Herman Hollerith expressed the idea
> about a stage coach full of punchcards, back in the 1880s.

The earliest reference to this I've been able to pin down is Andy Tanenbaum's,
and TTBOMK -- and you of all people should know this, Steve -- he was talking
about Usenet, which a few sites actually *got feeds of on magtape*, in the
very early 80s.  Some of those tapes, in addition to UTZoo's backups of their
spool, constituted the very earliest material given to Dejagoo.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From yang.yu.list at gmail.com  Wed Apr  3 02:22:52 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Tue, 2 Apr 2013 22:22:52 -0400
Subject: Mikrotik visibility
In-Reply-To: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>
References: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>
Message-ID: <CAFwKRnQf7ZgNyTPpqFdjFDZT-HmQYFXtnkpibPA+iWDphVc7+A@mail.gmail.com>

I am using Plixer Scrutinizer Flow Analyzer with RouterOS. It does
have cool looking web panel. But some interfaces (instance 0, instance
1 etc.) reported doesn't exactly match up with interfaces in RouterOS.
I haven't figured out what exactly those are.

Yang


From pfunix at gmail.com  Wed Apr  3 03:56:39 2013
From: pfunix at gmail.com (Beavis)
Date: Tue, 2 Apr 2013 21:56:39 -0600
Subject: Mikrotik visibility
In-Reply-To: <CAFwKRnQf7ZgNyTPpqFdjFDZT-HmQYFXtnkpibPA+iWDphVc7+A@mail.gmail.com>
References: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>
 <CAFwKRnQf7ZgNyTPpqFdjFDZT-HmQYFXtnkpibPA+iWDphVc7+A@mail.gmail.com>
Message-ID: <CAMvhC_5wMGHRwouTJarXy+SGxmWEiRAThB0d2ZkjP_hatvyenQ@mail.gmail.com>

thanks all this is a good start.


regards,
-Beavis

On Tue, Apr 2, 2013 at 8:22 PM, Yang Yu <yang.yu.list at gmail.com> wrote:
> I am using Plixer Scrutinizer Flow Analyzer with RouterOS. It does
> have cool looking web panel. But some interfaces (instance 0, instance
> 1 etc.) reported doesn't exactly match up with interfaces in RouterOS.
> I haven't figured out what exactly those are.
>
> Yang



-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/


From sethm at rollernet.us  Wed Apr  3 05:13:45 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 02 Apr 2013 22:13:45 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <CD8099F0.8E687%carlos@race.com>
References: <CD8099F0.8E687%carlos@race.com>
Message-ID: <515BBA89.5080000@rollernet.us>

On 4/2/13 2:24 PM, Carlos Alcantar wrote:
> You might want to consider putting up a speedtest server internal to your
> network.  I know there is a fee but well worth it I believe.  You will
> still need to take the results with a grain a salt but you will have the
> best results as well.
> 

The speedtest.net mini version is free. Same test methodology and brand
recognition for the customers to be satisfied. Paid version if you need
branding or whatever.

~Seth


From Valdis.Kletnieks at vt.edu  Wed Apr  3 06:24:36 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 03 Apr 2013 02:24:36 -0400
Subject: RFC 1149
In-Reply-To: Your message of "Tue, 02 Apr 2013 19:00:35 -0400."
 <201304021900350661.0242BC77@sentry.24cl.com>
References: <001801ce2f3b$0161b6c0$04252440$@net>
 <CAMdF1xWmsH6TXL9HesVV4CZD3Yte5tXdDkHOJWQsbCr7vwsWVg@mail.gmail.com>
 <515A402A.1040001@utc.edu>
 <CAK__KzszTVyGLKhJNP9GHSVc0wm5EPGHova=9F16O2BrSPxZqQ@mail.gmail.com>
 <032b01ce2fd0$53045920$f90d0b60$@sberkman.net>
 <55A3CE6F-6688-47A4-94B9-E0B7A2DF9B77@delong.com>
 <A4ED4AF5-98B5-4837-9806-0AFC0DDB6B18@cs.columbia.edu>
 <201304021900350661.0242BC77@sentry.24cl.com>
Message-ID: <86349.1364970276@turing-police.cc.vt.edu>

On Tue, 02 Apr 2013 19:00:35 -0400, "Mike." said:

> Oddly, prehaps, those punchcards on the stagecoaches probably will
> outlast any magnetic media we have at our disposal today....

Here's a picture of an estimated 4.3G of data on punch cards:

http://en.wikipedia.org/wiki/File:IBM_card_storage.NARA.jpg

20 rows of pallets, each row is 15 pallets, stacked 2 high, 45 boxes
of 2,000 to the pallet.

One has to wonder if those pallets are still there....


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

From jamie at photon.com  Wed Apr  3 11:40:29 2013
From: jamie at photon.com (Jamie Bowden)
Date: Wed, 3 Apr 2013 11:40:29 +0000
Subject: RFC 1149
In-Reply-To: <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>
References: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>
 <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>
Message-ID: <465966A5F5B867419F604CD3E604C1E53B09D964@PRA-DCA-MAIL.pra.ray.com>

> From: Jay Ashworth [mailto:jra at baylink.com]
> ----- Original Message -----
> > From: "TJ" <trejrco at gmail.com>

> > On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong <owen at delong.com>
> wrote:

> > > "Never underestimate the bandwidth of a 747 full of DLT cartridges."

> > XKCD is all over this: http://what-if.xkcd.com/31/
> > :)

> I have always wondered what kind of station wagon Andy had in mind; the
> SRT-8 Magnum didn't exist when he said that...

No, but the Caprice Classic wagon was very common at the time.

Jamie

From straterra at fuhell.com  Wed Apr  3 13:55:31 2013
From: straterra at fuhell.com (Thomas York)
Date: Wed, 3 Apr 2013 09:55:31 -0400
Subject: MikroTik + EAP-TLS + Non-Channel 1 / Apple iOS issues
Message-ID: <007101ce3072$e9410300$bbc30900$@fuhell.com>

I know a few of you guys are using MikroTik offerings in the enterprise, so
I hope to pick your brain(s). I have many, many RB433UAH's deployed
worldwide as simple WAPs. I've been looking to move to 802.1x EAP-TLS via an
external FreeRadius server. I have our HP Procurves using the FreeRadius
server without issue. Infact, the only devices that seem to have issues are
the MikroTik devices. 

For one, only channel 1 seems to work with 802.1x. If I change the channel
to ANYTHING else, clients refuse to auth. Secondly, newer iOS devices (iOS 5
and newer, I believe) refuse to auth entirely. I have an older iPod touch
that is on iOS4 that can authenticate on channel 1. 

Have any of you guys seen issues like this? Thanks.

-- Thomas York

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

From jabley at hopcount.ca  Wed Apr  3 14:11:13 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 3 Apr 2013 10:11:13 -0400
Subject: public consultation on root zone KSK rollover
Message-ID: <CA6E03E2-B3C0-4FBB-B71C-B3D94D1A9ED7@hopcount.ca>

Hi all,

As advised a month or so ago, the following public comment period is open:

  http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm

We have received a small number of responses which are accessible from that page.

The topic at hand and the specific questions that have been asked as part of the consultation are important ones; the decisions taken will have operational consequences to any user of the Internet who validates DNS responses with DNSSEC.

If you have experience, opinions or expertise to contribute, it would be greatly appreciated. The window for being able to submit comments closes on 12 April 2013 at 23:59 UTC.

Many thanks,


Joe



From effinjdent at gmail.com  Wed Apr  3 15:25:26 2013
From: effinjdent at gmail.com (Jerry Dent)
Date: Wed, 3 Apr 2013 10:25:26 -0500
Subject: Open Resolver Problems
In-Reply-To: <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
 <8720.1364840876@turing-police.cc.vt.edu>
 <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>
 <20130402171808.24503d94@localhost>
 <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>
Message-ID: <CADUFW=VWZVNkLpwmp3QcSdPN6hp9nCSr4btxUo8qx_7C0UFeWw@mail.gmail.com>

I think that is .2% - .3%, no?


On Tue, Apr 2, 2013 at 5:41 PM, Joe Abley <jabley at hopcount.ca> wrote:

>
> On 2013-04-02, at 18:18, John Kristoff <jtk at cymru.com> wrote:
>
> > I would expect from stubs this will be close enough to zero to be
> > effectively zero.  At least I would hope so.
>
> This (below) is one of four resolvers, together providing service for two
> recursive DNS servers used by residential DSL and cable internet users at a
> medium-sized ISP in Canada. These resolvers are running unbound, which will
> never choose a source port of 53 on an outbound query; hence anything we
> see here with src port = dst port = 53 is one of those effective zeros.
>
> [dns1-p1:~]% sudo tcpdump -i em0 -n -c 10000 -w sample.pcap udp port 53
> tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 10000 packets captured
> 10267 packets received by filter
> 0 packets dropped by kernel
> [dns1-p1:~]% tcpdump -r sample.pcap -q udp src port 53 and udp dst port 53
> | wc -l
> reading from file sample.pcap, link-type EN10MB (Ethernet)
>       26
> [dns1-p1:~]%
>
> 26/1000 is more than zero but still quite small. Subsequent samples with
> bigger sizes give 332/100000, 3017/1000000.
>
> No science here, but 2% - 3% is what it looks like, which is big enough to
> be a noticeable support cost for a medium-scale provider if the customer
> damage is not robo-mediated in some way (e.g. whitelist known offenders to
> avoid the support phone glowing red when you first turn it on).
>
>
> Joe
>

From jabley at hopcount.ca  Wed Apr  3 16:40:03 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 3 Apr 2013 12:40:03 -0400
Subject: Open Resolver Problems
In-Reply-To: <CADUFW=VWZVNkLpwmp3QcSdPN6hp9nCSr4btxUo8qx_7C0UFeWw@mail.gmail.com>
References: <1452969.462.1364840356835.JavaMail.root@benjamin.baylink.com>
 <8720.1364840876@turing-police.cc.vt.edu>
 <alpine.DEB.2.00.1304012032280.23668@uplift.swm.pp.se>
 <20130402171808.24503d94@localhost>
 <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>
 <CADUFW=VWZVNkLpwmp3QcSdPN6hp9nCSr4btxUo8qx_7C0UFeWw@mail.gmail.com>
Message-ID: <986E0971-24E5-45C4-9313-093E7EDDF745@hopcount.ca>


On 2013-04-03, at 11:25, Jerry Dent <effinjdent at gmail.com> wrote:

> I think that is .2% - .3%, no?

Oh, you're right -- it does seem substantially closer to zero when you put the decimal point in the right place :-)


Joe



From jra at baylink.com  Wed Apr  3 16:52:17 2013
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 3 Apr 2013 12:52:17 -0400 (EDT)
Subject: Open Resolver Problems
In-Reply-To: <986E0971-24E5-45C4-9313-093E7EDDF745@hopcount.ca>
Message-ID: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Joe Abley" <jabley at hopcount.ca>

> On 2013-04-03, at 11:25, Jerry Dent <effinjdent at gmail.com> wrote:
> 
> > I think that is .2% - .3%, no?
> 
> Oh, you're right -- it does seem substantially closer to zero when you
> put the decimal point in the right place :-)

Huh?

23 in 1000 is in fact 2.3%.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From network.ipdog at gmail.com  Wed Apr  3 16:55:29 2013
From: network.ipdog at gmail.com (Network IPdog)
Date: Wed, 3 Apr 2013 09:55:29 -0700
Subject: Mikrotik visibility
In-Reply-To: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>
References: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>
Message-ID: <515c5f02.03f2440a.7b84.ffffe7cc@mx.google.com>

Mikrotik... 'The Dude'
http://www.mikrotik.com/thedude


Ruff, Ruff...!

Network IPdog

Ephesians 4:32  &  Cheers!!!

A password is like a... toothbrush  ;^) 
Choose a good one, change it regularly and don't share it.

-----Original Message-----
From: Beavis [mailto:pfunix at gmail.com] 
Sent: Tuesday, April 02, 2013 2:56 PM
To: nanog at nanog.org
Subject: Mikrotik visibility

Hello All,

I would like to ask if there are any folks out there that use any specific
tool (OpenSource/Closed) that is used for mikrotik routers. I need packet
visibility (ala netflow) or anything similar to that effect.


any suggestions are greatly appreciated.


cheers,
-Beavis

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/



From brandon at rd.bbc.co.uk  Wed Apr  3 16:59:17 2013
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Wed, 3 Apr 2013 17:59:17 +0100 (BST)
Subject: public consultation on root zone KSK rollover
Message-ID: <201304031659.RAA21506@sunf10.rd.bbc.co.uk>

> The topic at hand and the specific questions that have been
> asked as part of the consultation are important ones;

Do it when you feel like, nobody should notice. Anything
this important should be routine procedure, make it daily.

> the decisions taken will have operational consequences to any
> user of the Internet who validates DNS responses with DNSSEC.

That will not motivate people to deploy it

brandon


From jabley at hopcount.ca  Wed Apr  3 17:15:07 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 3 Apr 2013 13:15:07 -0400
Subject: Open Resolver Problems
In-Reply-To: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com>
References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com>
Message-ID: <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca>


On 2013-04-03, at 12:52, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
>> From: "Joe Abley" <jabley at hopcount.ca>
> 
>> On 2013-04-03, at 11:25, Jerry Dent <effinjdent at gmail.com> wrote:
>> 
>>> I think that is .2% - .3%, no?
>> 
>> Oh, you're right -- it does seem substantially closer to zero when you
>> put the decimal point in the right place :-)
> 
> Huh?
> 
> 23 in 1000 is in fact 2.3%.

That's it, no more e-mail for me today.


Joe


From effinjdent at gmail.com  Wed Apr  3 17:28:25 2013
From: effinjdent at gmail.com (Jerry Dent)
Date: Wed, 3 Apr 2013 12:28:25 -0500
Subject: Open Resolver Problems
In-Reply-To: <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca>
References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com>
 <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca>
Message-ID: <CADUFW=WXSUiyrNtk9OZYFDYqwOAySPYcgHACthz8V6OC2DhGZQ@mail.gmail.com>

His sample was 10K not 1000. Look higher.


On Wed, Apr 3, 2013 at 12:15 PM, Joe Abley <jabley at hopcount.ca> wrote:

>
> On 2013-04-03, at 12:52, Jay Ashworth <jra at baylink.com> wrote:
>
> > ----- Original Message -----
> >> From: "Joe Abley" <jabley at hopcount.ca>
> >
> >> On 2013-04-03, at 11:25, Jerry Dent <effinjdent at gmail.com> wrote:
> >>
> >>> I think that is .2% - .3%, no?
> >>
> >> Oh, you're right -- it does seem substantially closer to zero when you
> >> put the decimal point in the right place :-)
> >
> > Huh?
> >
> > 23 in 1000 is in fact 2.3%.
>
> That's it, no more e-mail for me today.
>
>
> Joe
>
>

From owen at delong.com  Wed Apr  3 18:52:00 2013
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Apr 2013 11:52:00 -0700
Subject: Mikrotik visibility
In-Reply-To: <515c5f02.03f2440a.7b84.ffffe7cc@mx.google.com>
References: <CAMvhC_5ZtQ8vsS5uqV7mNNX+fkxkcgm+HopzW2c72jw-FD8tnQ@mail.gmail.com>
 <515c5f02.03f2440a.7b84.ffffe7cc@mx.google.com>
Message-ID: <75A58AAF-046D-4B90-AA79-7901E01FE832@delong.com>

The problem with 'The Dude' is that won't run on any of the platforms I have.

Owen

On Apr 3, 2013, at 09:55 , Network IPdog <network.ipdog at gmail.com> wrote:

> Mikrotik... 'The Dude'
> http://www.mikrotik.com/thedude
> 
> 
> Ruff, Ruff...!
> 
> Network IPdog
> 
> Ephesians 4:32  &  Cheers!!!
> 
> A password is like a... toothbrush  ;^) 
> Choose a good one, change it regularly and don't share it.
> 
> -----Original Message-----
> From: Beavis [mailto:pfunix at gmail.com] 
> Sent: Tuesday, April 02, 2013 2:56 PM
> To: nanog at nanog.org
> Subject: Mikrotik visibility
> 
> Hello All,
> 
> I would like to ask if there are any folks out there that use any specific
> tool (OpenSource/Closed) that is used for mikrotik routers. I need packet
> visibility (ala netflow) or anything similar to that effect.
> 
> 
> any suggestions are greatly appreciated.
> 
> 
> cheers,
> -Beavis
> 
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
> 
> Disclaimer:
> http://goldmark.org/jeff/stupid-disclaimers/
> 



From george.herbert at gmail.com  Wed Apr  3 18:58:10 2013
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 3 Apr 2013 11:58:10 -0700
Subject: RFC 1149
In-Reply-To: <465966A5F5B867419F604CD3E604C1E53B09D964@PRA-DCA-MAIL.pra.ray.com>
References: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>
 <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>
 <465966A5F5B867419F604CD3E604C1E53B09D964@PRA-DCA-MAIL.pra.ray.com>
Message-ID: <CAK__KzsiGuFgAQFUOZsHjLrEewj0pRXY2vaUN4r5yZsve8oUQw@mail.gmail.com>

In europe?  He probably was thinking of a Volvo 245...


On Wed, Apr 3, 2013 at 4:40 AM, Jamie Bowden <jamie at photon.com> wrote:

> > From: Jay Ashworth [mailto:jra at baylink.com]
> > ----- Original Message -----
> > > From: "TJ" <trejrco at gmail.com>
>
> > > On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong <owen at delong.com>
> > wrote:
>
> > > > "Never underestimate the bandwidth of a 747 full of DLT cartridges."
>
> > > XKCD is all over this: http://what-if.xkcd.com/31/
> > > :)
>
> > I have always wondered what kind of station wagon Andy had in mind; the
> > SRT-8 Magnum didn't exist when he said that...
>
> No, but the Caprice Classic wagon was very common at the time.
>
> Jamie
>



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

From jra at baylink.com  Wed Apr  3 18:59:47 2013
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 03 Apr 2013 14:59:47 -0400
Subject: RFC 1149
In-Reply-To: <CAK__KzsiGuFgAQFUOZsHjLrEewj0pRXY2vaUN4r5yZsve8oUQw@mail.gmail.com>
References: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>
 <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>
 <465966A5F5B867419F604CD3E604C1E53B09D964@PRA-DCA-MAIL.pra.ray.com>
 <CAK__KzsiGuFgAQFUOZsHjLrEewj0pRXY2vaUN4r5yZsve8oUQw@mail.gmail.com>
Message-ID: <d420892b-e166-494e-aa73-5a00b4962392@email.android.com>

I don't /think/ Andy was over there that far back.

George Herbert <george.herbert at gmail.com> wrote:

>In europe?  He probably was thinking of a Volvo 245...
>
>
>On Wed, Apr 3, 2013 at 4:40 AM, Jamie Bowden <jamie at photon.com> wrote:
>
>> > From: Jay Ashworth [mailto:jra at baylink.com]
>> > ----- Original Message -----
>> > > From: "TJ" <trejrco at gmail.com>
>>
>> > > On Tue, Apr 2, 2013 at 3:41 PM, Owen DeLong <owen at delong.com>
>> > wrote:
>>
>> > > > "Never underestimate the bandwidth of a 747 full of DLT
>cartridges."
>>
>> > > XKCD is all over this: http://what-if.xkcd.com/31/
>> > > :)
>>
>> > I have always wondered what kind of station wagon Andy had in mind;
>the
>> > SRT-8 Magnum didn't exist when he said that...
>>
>> No, but the Caprice Classic wagon was very common at the time.
>>
>> Jamie
>>
>
>
>
>-- 
>-george william herbert
>george.herbert at gmail.com

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

From duncan at e-simple.co.nz  Wed Apr  3 20:20:47 2013
From: duncan at e-simple.co.nz (Duncan Turnbull)
Date: Thu, 4 Apr 2013 09:20:47 +1300
Subject: MikroTik + EAP-TLS + Non-Channel 1 / Apple iOS issues
In-Reply-To: <007101ce3072$e9410300$bbc30900$@fuhell.com>
References: <007101ce3072$e9410300$bbc30900$@fuhell.com>
Message-ID: <8A21B94D-9641-4D7B-A24E-44DB4AE8457A@e-simple.co.nz>

We had some issues with apple devices recently on a new MT using WPA2 and preshared key - might not be the same but...

The preamble mode was important plus the auth types needed to drop any older auth options types as apple seems to only accept the latest versions

We had iphones, macbook airs and some macs not connect 

These were the settings that made everything spring to life as best I recall

ht-basic-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7 ht-guard-interval=any ht-rxchains=0,1 ht-txchains=0,1
preamble-mode=long proprietary-extensions=post-2.9.25
eap-methods=passthrough group-ciphers=aes-ccm 
unicast-ciphers=aes-ccm 

Cheers Duncan

On 4/04/2013, at 2:55 AM, "Thomas York" <straterra at fuhell.com> wrote:

> I know a few of you guys are using MikroTik offerings in the enterprise, so
> I hope to pick your brain(s). I have many, many RB433UAH's deployed
> worldwide as simple WAPs. I've been looking to move to 802.1x EAP-TLS via an
> external FreeRadius server. I have our HP Procurves using the FreeRadius
> server without issue. Infact, the only devices that seem to have issues are
> the MikroTik devices. 
> 
> For one, only channel 1 seems to work with 802.1x. If I change the channel
> to ANYTHING else, clients refuse to auth. Secondly, newer iOS devices (iOS 5
> and newer, I believe) refuse to auth entirely. I have an older iPod touch
> that is on iOS4 that can authenticate on channel 1. 
> 
> Have any of you guys seen issues like this? Thanks.
> 
> -- Thomas York
> 



From mike-nanog at tiedyenetworks.com  Wed Apr  3 21:07:48 2013
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Wed, 03 Apr 2013 14:07:48 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <515BBA89.5080000@rollernet.us>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
Message-ID: <515C9A24.8010809@tiedyenetworks.com>

On 04/02/2013 10:13 PM, Seth Mattinen wrote:
> On 4/2/13 2:24 PM, Carlos Alcantar wrote:
>> You might want to consider putting up a speedtest server internal to your
>> network.  I know there is a fee but well worth it I believe.  You will
>> still need to take the results with a grain a salt but you will have the
>> best results as well.
>>
>
> The speedtest.net mini version is free. Same test methodology and brand
> recognition for the customers to be satisfied. Paid version if you need
> branding or whatever.
>
> ~Seth
>



These speedtests are pure unscientific bs and I'd love to see them 
called out on the carpet for it.

Mike-


From Valdis.Kletnieks at vt.edu  Wed Apr  3 21:48:00 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 03 Apr 2013 17:48:00 -0400
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: Your message of "Wed, 03 Apr 2013 14:07:48 -0700."
 <515C9A24.8010809@tiedyenetworks.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
Message-ID: <49250.1365025680@turing-police.cc.vt.edu>

On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:

> These speedtests are pure unscientific bs and I'd love to see them
> called out on the carpet for it.

As far as I know, it's possible for the end-to-end reported values to be
lower than your immediate upstream due to issues further upstream.

But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is
able to go *at least* that fast.

(If anybody's got evidence of it reporting more than the link is technically
capable of, feel free to correct me...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130403/ee67ca86/attachment.bin>

From paul at paulstewart.org  Wed Apr  3 21:52:25 2013
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 3 Apr 2013 17:52:25 -0400
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <49250.1365025680@turing-police.cc.vt.edu>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
Message-ID: <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>

We host one of the gazillion speed test sites and for networks that are
close to us we find it "reasonably accurate" .. a good benchmark at least ..


Even our installers in the field use it as a "reference point"....  YMMV
obviously....

Paul


-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: April-03-13 5:48 PM
To: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:

> These speedtests are pure unscientific bs and I'd love to see them 
> called out on the carpet for it.

As far as I know, it's possible for the end-to-end reported values to be
lower than your immediate upstream due to issues further upstream.

But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able
to go *at least* that fast.

(If anybody's got evidence of it reporting more than the link is technically
capable of, feel free to correct me...)



From ben at meh.net.nz  Wed Apr  3 21:54:58 2013
From: ben at meh.net.nz (Ben Aitchison)
Date: Thu, 4 Apr 2013 10:54:58 +1300
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <49250.1365025680@turing-police.cc.vt.edu>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
Message-ID: <20130403215458.GB26823@meh.net.nz>

On Wed, Apr 03, 2013 at 05:48:00PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
> 
> > These speedtests are pure unscientific bs and I'd love to see them
> > called out on the carpet for it.
> 
> As far as I know, it's possible for the end-to-end reported values to be
> lower than your immediate upstream due to issues further upstream.
> 
> But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is
> able to go *at least* that fast.
> 
> (If anybody's got evidence of it reporting more than the link is technically
> capable of, feel free to correct me...)

I've had speedtest.net report above ADSL sync rate on ADSL connection.  

Also from my testing, speedtest.net usually under-represents upload speed on fast
upload connections.  And for some reason ping shows higher in chrome than in internet
explorer.

It also tends to underrepresent far away connections by using too small file sizes. If
you use curl on the speedtest random.jpg files and grab the 4000x4000.jpg it'll give a
more representive test of download speed.

Ben.


From nick at foobar.org  Wed Apr  3 22:02:17 2013
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 3 Apr 2013 23:02:17 +0100
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <49250.1365025680@turing-police.cc.vt.edu>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
Message-ID: <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>

On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
> (If anybody's got evidence of it reporting more than the link is technically
> capable of, feel free to correct me...)

I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.

Nick



From wbailey at satelliteintelligencegroup.com  Wed Apr  3 22:20:02 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 3 Apr 2013 22:20:02 +0000
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>,
 <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
Message-ID: <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>

Try it with upwards of 900ms of variable latency.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Nick Hilliard <nick at foobar.org>
Date: 04/03/2013 3:04 PM (GMT-08:00)
To: Valdis.Kletnieks at vt.edu
Cc: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test


On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
> (If anybody's got evidence of it reporting more than the link is technically
> capable of, feel free to correct me...)

I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.

Nick




From nick at foobar.org  Wed Apr  3 22:35:33 2013
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 3 Apr 2013 23:35:33 +0100
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
 <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>
Message-ID: <08364720-4D2B-4150-8116-97382FEE9836@foobar.org>

On 3 Apr 2013, at 23:20, Warren Bailey <wbailey at satelliteintelligencegroup.com> wrote:
> Try it with upwards of 900ms of variable latency. 

The last crazy result I got was 146mbit/s on a hardwired 100 mbit link  and 1-2ms latency to the speedtest.net server I was using at the time (same data centre).  Testing this sort of thing with high latency and jitter is understandably hard, but I didn't see a good reason at the time why it should have been so badly out with good underlying network characteristics.

Nick



> 
> 
> Sent from my T-Mobile 4G LTE Device
> 
> 
> 
> -------- Original message --------
> From: Nick Hilliard <nick at foobar.org> 
> Date: 04/03/2013 3:04 PM (GMT-08:00) 
> To: Valdis.Kletnieks at vt.edu 
> Cc: nanog at nanog.org 
> Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test 
> 
> 
> On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
> > (If anybody's got evidence of it reporting more than the link is technically
> > capable of, feel free to correct me...)
> 
> I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
> 
> Nick
> 
> 
> 

From wbailey at satelliteintelligencegroup.com  Wed Apr  3 22:41:05 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Wed, 3 Apr 2013 22:41:05 +0000
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <08364720-4D2B-4150-8116-97382FEE9836@foobar.org>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
 <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>,
 <08364720-4D2B-4150-8116-97382FEE9836@foobar.org>
Message-ID: <hjnah8b3g5m3186qk8ckp4s5.1365028863298@email.android.com>

They may do some magic with bandwidth delay products.. If that was the case, they may have written it for a standard latency versus something that is unreasonable by interweb standards.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Nick Hilliard <nick at foobar.org>
Date: 04/03/2013 3:35 PM (GMT-08:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Valdis.Kletnieks at vt.edu,nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test


On 3 Apr 2013, at 23:20, Warren Bailey <wbailey at satelliteintelligencegroup.com<mailto:wbailey at satelliteintelligencegroup.com>> wrote:
Try it with upwards of 900ms of variable latency.

The last crazy result I got was 146mbit/s on a hardwired 100 mbit link  and 1-2ms latency to the speedtest.net<http://speedtest.net> server I was using at the time (same data centre).  Testing this sort of thing with high latency and jitter is understandably hard, but I didn't see a good reason at the time why it should have been so badly out with good underlying network characteristics.

Nick





Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Nick Hilliard <nick at foobar.org<mailto:nick at foobar.org>>
Date: 04/03/2013 3:04 PM (GMT-08:00)
To: Valdis.Kletnieks at vt.edu<mailto:Valdis.Kletnieks at vt.edu>
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: Speedtest Results speedtest.net<http://speedtest.net> vs Mikrotik bandwidth test


On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu<mailto:Valdis.Kletnieks at vt.edu> wrote:
> (If anybody's got evidence of it reporting more than the link is technically
> capable of, feel free to correct me...)

I've seen speedtest.net<http://speedtest.net> give results significantly greater than the physical bw of the client's network link.

Nick




From kemp at network-services.uoregon.edu  Wed Apr  3 22:52:45 2013
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Wed, 03 Apr 2013 15:52:45 -0700
Subject: route for linx.net in Level3?
Message-ID: <515CB2BD.20601@network-services.uoregon.edu>


Having trouble reaching route-views.linx.routeviews.org from AS3582.

I'm assuming that some folks stopped carrying
this particular linx.net address prefix
as of this morning. ?!?

$ whois -h whois.cymru.com " -v 195.66.241.146"
AS      | IP               | BGP Prefix          | CC | Registry |
Allocated  | AS Name
5459    | 195.66.241.146   | 195.66.240.0/22     | GB | ripencc  |
1997-12-01 | LINX-AS London Internet Exchange Ltd.

$ dig +short 146.241.66.195.peer.asn.cymru.com TXT
"1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"

-- 
John Kemp (kemp at routeviews.org)
RouteViews Engineer
NOC: noc at routeviews.org
MAIL: help at routeviews.org
WWW: http://www.routeviews.org


From job.snijders at atrato.com  Wed Apr  3 22:59:55 2013
From: job.snijders at atrato.com (Job Snijders)
Date: Thu, 4 Apr 2013 00:59:55 +0200
Subject: route for linx.net in Level3?
In-Reply-To: <515CB2BD.20601@network-services.uoregon.edu>
References: <515CB2BD.20601@network-services.uoregon.edu>
Message-ID: <D4F9F802-DB6C-499B-94BF-E912451D1D8F@atrato.com>

Hi John,

On Apr 4, 2013, at 12:52 AM, John Kemp <kemp at network-services.uoregon.edu> wrote:

> Having trouble reaching route-views.linx.routeviews.org from AS3582.
> 
> I'm assuming that some folks stopped carrying
> this particular linx.net address prefix
> as of this morning. ?!?

Indeed LINX has taken steps recently to reduce the scope and reach of their peering LAN 
prefix to partially mitigate some types of attack. 

I'd be happy to help you off-list to get some permanent connectivity back to the machine. 

Kind regards,

Job

From nick at foobar.org  Wed Apr  3 23:12:49 2013
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 4 Apr 2013 00:12:49 +0100
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <hjnah8b3g5m3186qk8ckp4s5.1365028863298@email.android.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
 <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>
 <08364720-4D2B-4150-8116-97382FEE9836@foobar.org>
 <hjnah8b3g5m3186qk8ckp4s5.1365028863298@email.android.com>
Message-ID: <EF7E2D33-1E47-4C40-97DC-0E6562C02D6C@foobar.org>

On 3 Apr 2013, at 23:41, Warren Bailey <wbailey at satelliteintelligencegroup.com> wrote:
> They may do some magic with bandwidth delay products.. If that was the case, they may have written it for a standard latency versus something that is unreasonable by interweb standards. 

I don't know how they calculate bandwidth, but I was surprised that their system gave such wrong results under what were effectively lab conditions. 

Nick

> 
> 
> Sent from my T-Mobile 4G LTE Device
> 
> 
> 
> -------- Original message --------
> From: Nick Hilliard <nick at foobar.org> 
> Date: 04/03/2013 3:35 PM (GMT-08:00) 
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com> 
> Cc: Valdis.Kletnieks at vt.edu,nanog at nanog.org 
> Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test 
> 
> 
> On 3 Apr 2013, at 23:20, Warren Bailey <wbailey at satelliteintelligencegroup.com> wrote:
>> Try it with upwards of 900ms of variable latency. 
> 
> The last crazy result I got was 146mbit/s on a hardwired 100 mbit link  and 1-2ms latency to the speedtest.net server I was using at the time (same data centre).  Testing this sort of thing with high latency and jitter is understandably hard, but I didn't see a good reason at the time why it should have been so badly out with good underlying network characteristics.
> 
> Nick
> 
> 
> 
>> 
>> 
>> Sent from my T-Mobile 4G LTE Device
>> 
>> 
>> 
>> -------- Original message --------
>> From: Nick Hilliard <nick at foobar.org> 
>> Date: 04/03/2013 3:04 PM (GMT-08:00) 
>> To: Valdis.Kletnieks at vt.edu 
>> Cc: nanog at nanog.org 
>> Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test 
>> 
>> 
>> On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
>> > (If anybody's got evidence of it reporting more than the link is technically
>> > capable of, feel free to correct me...)
>> 
>> I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
>> 
>> Nick

From yang.yu.list at gmail.com  Wed Apr  3 23:20:44 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Wed, 3 Apr 2013 19:20:44 -0400
Subject: route for linx.net in Level3?
In-Reply-To: <515CB2BD.20601@network-services.uoregon.edu>
References: <515CB2BD.20601@network-services.uoregon.edu>
Message-ID: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>

I noticed it too this morning from a AS3549 customer. Level 3 LG shows
no route for 195.66.232.0/22 on North American sites.

On Wed, Apr 3, 2013 at 6:52 PM, John Kemp
<kemp at network-services.uoregon.edu> wrote:
>
> Having trouble reaching route-views.linx.routeviews.org from AS3582.
>
> I'm assuming that some folks stopped carrying
> this particular linx.net address prefix
> as of this morning. ?!?
>
> $ whois -h whois.cymru.com " -v 195.66.241.146"
> AS      | IP               | BGP Prefix          | CC | Registry |
> Allocated  | AS Name
> 5459    | 195.66.241.146   | 195.66.240.0/22     | GB | ripencc  |
> 1997-12-01 | LINX-AS London Internet Exchange Ltd.
>
> $ dig +short 146.241.66.195.peer.asn.cymru.com TXT
> "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"
>
> --
> John Kemp (kemp at routeviews.org)
> RouteViews Engineer
> NOC: noc at routeviews.org
> MAIL: help at routeviews.org
> WWW: http://www.routeviews.org
>


From chindy at lwpca.net  Thu Apr  4 00:20:29 2013
From: chindy at lwpca.net (Chris Hindy)
Date: Thu, 4 Apr 2013 00:20:29 +0000
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
Message-ID: <CD823EA7.127B%chindy@lwpca.net>

I can run two speedtest.net session side by side on my home network on one
laptop, and over VPN to my employer's Long Island locale on a second,
pointed at the same speedtest server, over the same wifi and ADSL and have
the VPN connection report speeds that are (a) 50% better on VPN than not;
and, (b) exceed my ADSL's hard cap by 10+ mbps.  That smells a bit fishy
to me, all in all.

-c

On 03-04-2013 18:02 , "Nick Hilliard" <nick at foobar.org> wrote:

>On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
>> (If anybody's got evidence of it reporting more than the link is
>>technically
>> capable of, feel free to correct me...)
>
>I've seen speedtest.net give results significantly greater than the
>physical bw of the client's network link.
>
>Nick
>
>



From surfer at mauigateway.com  Thu Apr  4 00:28:22 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 3 Apr 2013 17:28:22 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
Message-ID: <20130403172822.CE160597@m0005311.ppops.net>



--- nick at foobar.org wrote:
From: Nick Hilliard <nick at foobar.org>

>> They may do some magic with bandwidth delay products.. If that was the case, 
>> they may have written it for a standard latency versus something that is 
>> unreasonable by interweb standards. 

I don't know how they calculate bandwidth, but I was surprised that their system 
gave such wrong results under what were effectively lab conditions. 
------------------------------------------


It'd be nice to know if NDT was not accurate as well.  Anyone tested it?

scott


From sethm at rollernet.us  Thu Apr  4 01:12:10 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 03 Apr 2013 18:12:10 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>
Message-ID: <515CD36A.1000603@rollernet.us>

On 4/3/13 2:52 PM, Paul Stewart wrote:
> We host one of the gazillion speed test sites and for networks that are
> close to us we find it "reasonably accurate" .. a good benchmark at least ..
> 


The speedtest.net that's hosted on one of my directly connected transits
is consistently wrong, which is always fun. But the customers cling to
those results like it's the word of God.

~Seth


From owen at delong.com  Thu Apr  4 01:05:42 2013
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Apr 2013 18:05:42 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <CD823EA7.127B%chindy@lwpca.net>
References: <CD823EA7.127B%chindy@lwpca.net>
Message-ID: <9B8B06C8-1800-47E7-87C1-C5ABB143B5D6@delong.com>

(a) may be valid.
(b) is fishy

(a) may be valid because it may be that your ISP has a better set of peering
relationships towards your VPN server and your company's ISP has better
peering relationships towards the Speedtest server than your ISP has
towards the Speedtest server.

I'm not saying that IS the case, but I have seen instances where such results
were, in fact, perfectly legitimate for such reasons.

Owen

On Apr 3, 2013, at 17:20 , Chris Hindy <chindy at lwpca.net> wrote:

> I can run two speedtest.net session side by side on my home network on one
> laptop, and over VPN to my employer's Long Island locale on a second,
> pointed at the same speedtest server, over the same wifi and ADSL and have
> the VPN connection report speeds that are (a) 50% better on VPN than not;
> and, (b) exceed my ADSL's hard cap by 10+ mbps.  That smells a bit fishy
> to me, all in all.
> 
> -c
> 
> On 03-04-2013 18:02 , "Nick Hilliard" <nick at foobar.org> wrote:
> 
>> On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
>>> (If anybody's got evidence of it reporting more than the link is
>>> technically
>>> capable of, feel free to correct me...)
>> 
>> I've seen speedtest.net give results significantly greater than the
>> physical bw of the client's network link.
>> 
>> Nick
>> 
>> 
> 



From wbailey at satelliteintelligencegroup.com  Thu Apr  4 01:25:38 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Thu, 4 Apr 2013 01:25:38 +0000
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <515CD36A.1000603@rollernet.us>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
Message-ID: <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>

I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are the root of most complaints. Your link is congested (oversubed) and you then attempt to completely saturate your bandwidth to tell your provider what a suck job they are doing. I can't imagine wireless isps or those with limited  bandwidth haven't black holed those kind of performance tools. My world (satellite) is plagued by people who are speed testing very narrow band connections and expecting 15mbps down. They don't realize Speedtest is not an accurate representation of your connection as you cannot influence your bandwidth upstream. Ds3 from you to your 56k modem type of scenario comes to mind. It may *not* be your provider who is responsible for your issues (some people Speedtest just to call their provider to complain for service credits etc).


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Seth Mattinen <sethm at rollernet.us>
Date: 04/03/2013 6:13 PM (GMT-08:00)
To: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test


On 4/3/13 2:52 PM, Paul Stewart wrote:
> We host one of the gazillion speed test sites and for networks that are
> close to us we find it "reasonably accurate" .. a good benchmark at least ..
>


The speedtest.net that's hosted on one of my directly connected transits
is consistently wrong, which is always fun. But the customers cling to
those results like it's the word of God.

~Seth



From sethm at rollernet.us  Thu Apr  4 01:34:07 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 03 Apr 2013 18:34:07 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>
Message-ID: <515CD88F.4010409@rollernet.us>

On 4/3/13 6:25 PM, Warren Bailey wrote:
> I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are
> the root of most complaints. Your link is congested (oversubed) and you
> then attempt to completely saturate your bandwidth to tell your provider
> what a suck job they are doing. I can't imagine wireless isps or those
> with limited  bandwidth haven't black holed those kind of performance
> tools. My world (satellite) is plagued by people who are speed testing
> very narrow band connections and expecting 15mbps down. They don't
> realize Speedtest is not an accurate representation of your connection
> as you cannot influence your bandwidth upstream. Ds3 from you to your
> 56k modem type of scenario comes to mind. It may *not* be your provider
> who is responsible for your issues (some people Speedtest just to call
> their provider to complain for service credits etc). 
> 

In my case I know the gig connection between me and that transit is
nowhere near saturated and works OK, so I have to assume the server
they're hosting speedtest.net on is either constantly hosed or uses a
10Base-T interface, possibly token ring.

~Seth


From smb at cs.columbia.edu  Thu Apr  4 02:50:50 2013
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Wed, 3 Apr 2013 22:50:50 -0400
Subject: RFC 1149 
In-Reply-To: <23415990.646.1364951768781.JavaMail.root@benjamin.baylink.com>
References: <23415990.646.1364951768781.JavaMail.root@benjamin.baylink.com>
Message-ID: <FD28157F-18B4-4180-8152-2385CD45A3A0@cs.columbia.edu>


On Apr 2, 2013, at 9:16 PM, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
>> From: "Steven Bellovin" <smb at cs.columbia.edu>
> 
>> DLT? I first heard it as a station wagon full of (9-track, 1600 bpi,
>> that having been the state of the art) mag tapes on the Taconic Parkway,
>> circa 1970. I suspect, though, that Herman Hollerith expressed the idea
>> about a stage coach full of punchcards, back in the 1880s.
> 
> The earliest reference to this I've been able to pin down is Andy Tanenbaum's,
> and TTBOMK -- and you of all people should know this, Steve -- he was talking
> about Usenet, which a few sites actually *got feeds of on magtape*, in the
> very early 80s.  Some of those tapes, in addition to UTZoo's backups of their
> spool, constituted the very earliest material given to Dejagoo.
> 
Yes, I know that story.  I'm talking what was said to me personally -- not
hearsay, earwitness evidence.  The road mentioned was the Taconic Parkway, part
of the direct route between where I was working at the time (IBM Watson Lab #2,
http://www.columbia.edu/cu/computinghistory/watsonlab.html) and IBM
Yorktown -- https://maps.google.com/maps?saddr=612+West+115th+Street,+New+York,+NY&daddr=ibm+watson+labs,+yorktown,+ny&hl=en&ll=41.027571,-73.66745&spn=0.872312,0.95993&sll=40.807717,-73.965464&sspn=0.013675,0.014999&geocode=FSWtbgIdaGCX-ylpY-dMOfbCiTEUPDIPtH_nMw%3BFfTUdAIdCtuZ-yF0j-k3CpyMSikvG-JPT7jCiTF0j-k3CpyMSg&mra=ls&t=m&z=10
The context was the speed of an RJE link between the IBM 1130 I was running
(http://www.columbia.edu/cu/computinghistory/1130.html) and a mainframe
in Yorktown.  (If memory serves, it was a 2400 bps half-duplex link, probably
via a Bell 201 "data set".  I don't remember for sure, though.  Anyway, that
was my first contact with networking, though I worried more about the
host part of it.  I did learn bisync rather thoroughly in my next gig,
at City College of New York Computer Center, at that time the central
computing hub for the entire City University system.)


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







From wbailey at satelliteintelligencegroup.com  Thu Apr  4 03:02:41 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Thu, 4 Apr 2013 03:02:41 +0000
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <515CD88F.4010409@rollernet.us>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>,
 <515CD88F.4010409@rollernet.us>
Message-ID: <rajktibyenold6n1ulb4t74x.1365044557114@email.android.com>

I guess the Speedtest servers near metro areas do probably get pretty beat up. Has anyone paid the Ookla ransom for their own public server? I'd be really curious to see what they peak at.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Seth Mattinen <sethm at rollernet.us>
Date: 04/03/2013 6:36 PM (GMT-08:00)
To: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test


On 4/3/13 6:25 PM, Warren Bailey wrote:
> I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are
> the root of most complaints. Your link is congested (oversubed) and you
> then attempt to completely saturate your bandwidth to tell your provider
> what a suck job they are doing. I can't imagine wireless isps or those
> with limited  bandwidth haven't black holed those kind of performance
> tools. My world (satellite) is plagued by people who are speed testing
> very narrow band connections and expecting 15mbps down. They don't
> realize Speedtest is not an accurate representation of your connection
> as you cannot influence your bandwidth upstream. Ds3 from you to your
> 56k modem type of scenario comes to mind. It may *not* be your provider
> who is responsible for your issues (some people Speedtest just to call
> their provider to complain for service credits etc).
>

In my case I know the gig connection between me and that transit is
nowhere near saturated and works OK, so I have to assume the server
they're hosting speedtest.net on is either constantly hosed or uses a
10Base-T interface, possibly token ring.

~Seth



From jra at baylink.com  Thu Apr  4 03:20:07 2013
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 03 Apr 2013 23:20:07 -0400
Subject: RFC 1149
In-Reply-To: <FD28157F-18B4-4180-8152-2385CD45A3A0@cs.columbia.edu>
References: <23415990.646.1364951768781.JavaMail.root@benjamin.baylink.com>
 <FD28157F-18B4-4180-8152-2385CD45A3A0@cs.columbia.edu>
Message-ID: <3ed23c32-457e-436d-b61d-1db5835e88d0@email.android.com>

Steve, would you post that on a webpage somewhere? :-)
- jra

Steven Bellovin <smb at cs.columbia.edu> wrote:

>
>On Apr 2, 2013, at 9:16 PM, Jay Ashworth <jra at baylink.com> wrote:
>
>> ----- Original Message -----
>>> From: "Steven Bellovin" <smb at cs.columbia.edu>
>> 
>>> DLT? I first heard it as a station wagon full of (9-track, 1600 bpi,
>>> that having been the state of the art) mag tapes on the Taconic
>Parkway,
>>> circa 1970. I suspect, though, that Herman Hollerith expressed the
>idea
>>> about a stage coach full of punchcards, back in the 1880s.
>> 
>> The earliest reference to this I've been able to pin down is Andy
>Tanenbaum's,
>> and TTBOMK -- and you of all people should know this, Steve -- he was
>talking
>> about Usenet, which a few sites actually *got feeds of on magtape*,
>in the
>> very early 80s.  Some of those tapes, in addition to UTZoo's backups
>of their
>> spool, constituted the very earliest material given to Dejagoo.
>> 
>Yes, I know that story.  I'm talking what was said to me personally --
>not
>hearsay, earwitness evidence.  The road mentioned was the Taconic
>Parkway, part
>of the direct route between where I was working at the time (IBM Watson
>Lab #2,
>http://www.columbia.edu/cu/computinghistory/watsonlab.html) and IBM
>Yorktown --
>https://maps.google.com/maps?saddr=612+West+115th+Street,+New+York,+NY&daddr=ibm+watson+labs,+yorktown,+ny&hl=en&ll=41.027571,-73.66745&spn=0.872312,0.95993&sll=40.807717,-73.965464&sspn=0.013675,0.014999&geocode=FSWtbgIdaGCX-ylpY-dMOfbCiTEUPDIPtH_nMw%3BFfTUdAIdCtuZ-yF0j-k3CpyMSikvG-JPT7jCiTF0j-k3CpyMSg&mra=ls&t=m&z=10
>The context was the speed of an RJE link between the IBM 1130 I was
>running
>(http://www.columbia.edu/cu/computinghistory/1130.html) and a mainframe
>in Yorktown.  (If memory serves, it was a 2400 bps half-duplex link,
>probably
>via a Bell 201 "data set".  I don't remember for sure, though.  Anyway,
>that
>was my first contact with networking, though I worried more about the
>host part of it.  I did learn bisync rather thoroughly in my next gig,
>at City College of New York Computer Center, at that time the central
>computing hub for the entire City University system.)
>
>
>		--Steve Bellovin, https://www.cs.columbia.edu/~smb

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

From joelja at bogus.com  Thu Apr  4 04:06:17 2013
From: joelja at bogus.com (joel jaeggli)
Date: Wed, 03 Apr 2013 21:06:17 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>
Message-ID: <515CFC39.6010803@bogus.com>

On 4/3/13 6:25 PM, Warren Bailey wrote:
> I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are the root of most complaints. Your link is congested (oversubed) and you then attempt to completely saturate your bandwidth to tell your provider what a suck job they are doing. I can't imagine wireless isps or those with limited  bandwidth haven't black holed those kind of performance tools. My world (satellite) is plagued by people who are speed testing very narrow band connections and expecting 15mbps down. They don't realize Speedtest is not an accurate representation of your connection as you cannot influence your bandwidth upstream. Ds3 from you to your 56k modem type of scenario comes to mind. It may *not* be your provider who is responsible for your issues (some people Speedtest just to call their provider to complain for service credits etc).
>
Telling people to get by with even less instrumentation then they have 
already doesn't win you any friends. The solution to bad instruments is 
better instruments not breaking flow meter off the well.
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Seth Mattinen <sethm at rollernet.us>
> Date: 04/03/2013 6:13 PM (GMT-08:00)
> To: nanog at nanog.org
> Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
>
>
> On 4/3/13 2:52 PM, Paul Stewart wrote:
>> We host one of the gazillion speed test sites and for networks that are
>> close to us we find it "reasonably accurate" .. a good benchmark at least ..
>>
>
> The speedtest.net that's hosted on one of my directly connected transits
> is consistently wrong, which is always fun. But the customers cling to
> those results like it's the word of God.
>
> ~Seth
>
>
>



From joelja at bogus.com  Thu Apr  4 04:14:52 2013
From: joelja at bogus.com (joel jaeggli)
Date: Wed, 03 Apr 2013 21:14:52 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>,
 <98EBD33E-46B1-4B6A-9459-99800BFFBCBA@foobar.org>
 <we7dqr3gi43yngkq8ymvfiit.1365027524628@email.android.com>
Message-ID: <515CFE3C.7070903@bogus.com>

On 4/3/13 3:20 PM, Warren Bailey wrote:
> Try it with upwards of 900ms of variable latency.
on linux

tc qdisc add dev eth0 root netem delay 900ms 150msdistribution normal

and then you can slowly test the internet to your hearts content.
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Nick Hilliard <nick at foobar.org>
> Date: 04/03/2013 3:04 PM (GMT-08:00)
> To: Valdis.Kletnieks at vt.edu
> Cc: nanog at nanog.org
> Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
>
>
> On 3 Apr 2013, at 22:48, Valdis.Kletnieks at vt.edu wrote:
>> (If anybody's got evidence of it reporting more than the link is technically
>> capable of, feel free to correct me...)
> I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
>
> Nick
>
>
>
>



From swmike at swm.pp.se  Thu Apr  4 04:18:34 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 4 Apr 2013 06:18:34 +0200 (CEST)
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <515CFC39.6010803@bogus.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>
 <515CFC39.6010803@bogus.com>
Message-ID: <alpine.DEB.2.00.1304040616500.23668@uplift.swm.pp.se>

On Wed, 3 Apr 2013, joel jaeggli wrote:

> Telling people to get by with even less instrumentation then they have 
> already doesn't win you any friends. The solution to bad instruments is 
> better instruments not breaking flow meter off the well.

I have pitched the idea in the IETF to have TCP stacks themselves report 
IP performance indicators (aggregate) and that a standard for this to be 
standardised. No takers so far.

I hate test traffic, I want to know how the real traffic is doing instead. 
In my opinion, people are way too happy to inject a lot of "useless" test 
traffic.

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


From crosevear at skytap.com  Thu Apr  4 04:20:11 2013
From: crosevear at skytap.com (Carl Rosevear)
Date: Wed, 3 Apr 2013 21:20:11 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <rajktibyenold6n1ulb4t74x.1365044557114@email.android.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1un18k.1365038735461@email.android.com>
 <515CD88F.4010409@rollernet.us>
 <rajktibyenold6n1ulb4t74x.1365044557114@email.android.com>
Message-ID: <CANZz31ZFeQQ3WoxgJUMGuwFzgxQHr7ERo_C1XcCcwGsxtWJGAQ@mail.gmail.com>

I have paid the ransom.  Actually we pay it on a recurring basis even.  ;)
As for what it peaks at, good question.  The infrastructure we run it on is
going to be the problem at some point, although currently has not proven to
be a limiting factor to the best of my knowledge.  Our customers see valid
results...  I mean obviously it's not showing their link speed, it is
showing the characteristics of their connectivity to our speed test server.
 We use a couple of threads on the download test and if I take results,
divide by number of threads, look at the connection characteristics and do
the math to estimate throughput, there is at least usable parity there.
 But it's really useful for our support team when a customer is complaining
about some kind of bandwidth/latency issue into our cloud.  We have some
people in far places with 300+ms latency and 30+ms jitter, etc, trying to
use interactive sessions.  Oh and to be more correct, we actually have the
whole Ookla Line Quality package.  Very useful for us.  Also, customers
seem to love the whole flash animation thing.  Its what web users expect
these days...  it's really been a great experience for everyone... no
complaints on our end, aside from price, but I am always complaining about
that.  For those trying to just jam bits through a pipe to see if their
last mile is performing, slightly less useful unless there is one at their
ISP, but that is not our use case.

-Carl



On Wed, Apr 3, 2013 at 8:02 PM, Warren Bailey <
wbailey at satelliteintelligencegroup.com> wrote:

> I guess the Speedtest servers near metro areas do probably get pretty beat
> up. Has anyone paid the Ookla ransom for their own public server? I'd be
> really curious to see what they peak at.
>
>
> Sent from my T-Mobile 4G LTE Device
>

-- 
*Carl Rosevear*
Manager of Operations
*Skytap, Inc. | The Intuitive Enterprise Cloud*

crosevear at skytap.com | O: 206-588-8899 | F: 206-624-2214

Follow us: Blog <http://blog.skytap.com/> |
Twitter<http://twitter.com/#!/skytap>
 | LinkedIn <http://www.linkedin.com/company/skytap>

From andy at andy.net  Thu Apr  4 05:01:59 2013
From: andy at andy.net (Andy Warner)
Date: Thu, 4 Apr 2013 13:01:59 +0800
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <20130403172822.CE160597@m0005311.ppops.net>
References: <20130403172822.CE160597@m0005311.ppops.net>
Message-ID: <CAL4ZOFhvNXNziDRp2UffZxea+d7pEQuQQZvQcXioPWjrP90Ojg@mail.gmail.com>

The only reliable way to really test performance is to saturate the
pipe (Iperf) and have a sufficiently well provisioned target. NDT does
a good job using short non-saturation tests, but it is susceptible to
slow start and other challenges. In general, NDT results will be more
conservative than best case, whereas a lot of other tests are very
optimistic best cases.

FWIW, the actively maintained code has moved to:
https://code.google.com/p/ndt/ and 3.6.4 is a bit more stable and
flexible on some platforms than 3.6.5.

You can either standup your own test server or point at the public
sites run by a few universities and MeasurementLab
(http://www.measurementlab.net/mlab_sites), which are not as widely
distributed as the Ookla / speedtest.net targets, but they tend to be
better provisioned and the result data for the Mlab targets is made
available to the public.

Once you've compiled the client, you can run again the closest host via:
$ web100clt -n ndt.iupui.donar.measurement-lab.org

(default install will put the test client in /usr/local/bin)

If anybody want to host Mlab collection servers, they're always
looking for more hosts (http://measurementlab.net/getinvolved).

--
Andy

On Thu, Apr 4, 2013 at 8:28 AM, Scott Weeks <surfer at mauigateway.com> wrote:
>
>
> --- nick at foobar.org wrote:
> From: Nick Hilliard <nick at foobar.org>
>
>>> They may do some magic with bandwidth delay products.. If that was the case,
>>> they may have written it for a standard latency versus something that is
>>> unreasonable by interweb standards.
>
> I don't know how they calculate bandwidth, but I was surprised that their system
> gave such wrong results under what were effectively lab conditions.
> ------------------------------------------
>
>
> It'd be nice to know if NDT was not accurate as well.  Anyone tested it?
>
> scott
>


From mansaxel at besserwisser.org  Thu Apr  4 08:05:34 2013
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Thu, 4 Apr 2013 10:05:34 +0200
Subject: RFC 1149
In-Reply-To: <d420892b-e166-494e-aa73-5a00b4962392@email.android.com>
References: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>
 <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>
 <465966A5F5B867419F604CD3E604C1E53B09D964@PRA-DCA-MAIL.pra.ray.com>
 <CAK__KzsiGuFgAQFUOZsHjLrEewj0pRXY2vaUN4r5yZsve8oUQw@mail.gmail.com>
 <d420892b-e166-494e-aa73-5a00b4962392@email.android.com>
Message-ID: <20130404080534.GD2136@besserwisser.org>

Subject: Re: RFC 1149 Date: Wed, Apr 03, 2013 at 02:59:47PM -0400 Quoting Jay Ashworth (jra at baylink.com):
> George Herbert <george.herbert at gmail.com> wrote:
> 
> >In europe?  He probably was thinking of a Volvo 245...
> 
> I don't /think/ Andy was over there that far back.

"that far back"? The 245 still rolls, and probably will, for another 30 years. 

/M?ns, drove 245 in youth. 
-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
The SAME WAVE keeps coming in and COLLAPSING like a rayon MUU-MUU ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130404/a95c1851/attachment.bin>

From mike-nanog at tiedyenetworks.com  Thu Apr  4 08:14:09 2013
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Thu, 04 Apr 2013 01:14:09 -0700
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <49250.1365025680@turing-police.cc.vt.edu>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
Message-ID: <515D3651.7050600@tiedyenetworks.com>

On 04/03/2013 02:48 PM, Valdis.Kletnieks at vt.edu wrote:
> On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
>
>> These speedtests are pure unscientific bs and I'd love to see them
>> called out on the carpet for it.
>
> As far as I know, it's possible for the end-to-end reported values to be
> lower than your immediate upstream due to issues further upstream.
>
> But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is
> able to go *at least* that fast.
>
> (If anybody's got evidence of it reporting more than the link is technically
> capable of, feel free to correct me...)



Yeah, I do... I've had T1 lines reported at 4.7mbps down and 2.8mbps up.

These tests are hogwash.

Mike-


From jhellenthal at dataix.net  Thu Apr  4 08:35:13 2013
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Thu, 4 Apr 2013 04:35:13 -0400
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <515D3651.7050600@tiedyenetworks.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <515D3651.7050600@tiedyenetworks.com>
Message-ID: <FB900DF7-19CF-4CBC-A173-8EB9D0A3D061@DataIX.net>

When is speed ever ensured past someone else's edge/border ?

You may pass through your upstream that fast but once you are out in the open range you are free game to all the lions, tigers & bears..,

There is always going to be something eating you. Best off letting it be the Spanish queasiness from the night before than the results from speedtest.net

 

-- 

 Jason Hellenthal
 JJH448-ARIN
 - (2^(N-1))


On Apr 4, 2013, at 4:14, Mike <mike-nanog at tiedyenetworks.com> wrote:

> On 04/03/2013 02:48 PM, Valdis.Kletnieks at vt.edu wrote:
>> On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
>> 
>>> These speedtests are pure unscientific bs and I'd love to see them
>>> called out on the carpet for it.
>> 
>> As far as I know, it's possible for the end-to-end reported values to be
>> lower than your immediate upstream due to issues further upstream.
>> 
>> But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is
>> able to go *at least* that fast.
>> 
>> (If anybody's got evidence of it reporting more than the link is technically
>> capable of, feel free to correct me...)
> 
> 
> 
> Yeah, I do... I've had T1 lines reported at 4.7mbps down and 2.8mbps up.
> 
> These tests are hogwash.
> 
> Mike-
> 


From drc at virtualized.org  Thu Apr  4 09:16:30 2013
From: drc at virtualized.org (David Conrad)
Date: Thu, 4 Apr 2013 17:16:30 +0800
Subject: public consultation on root zone KSK rollover
In-Reply-To: <201304031659.RAA21506@sunf10.rd.bbc.co.uk>
References: <201304031659.RAA21506@sunf10.rd.bbc.co.uk>
Message-ID: <E16014CF-6FB9-4A3D-B0F1-181F45B58983@virtualized.org>

On Apr 4, 2013, at 12:59 AM, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote:
>> The topic at hand and the specific questions that have been
>> asked as part of the consultation are important ones;
> 
> Do it when you feel like, nobody should notice. Anything
> this important should be routine procedure, make it daily.

You do realize this requires changing validating resolver configuration data, right?

Regards,
-drc



From brandon at rd.bbc.co.uk  Thu Apr  4 09:35:32 2013
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Thu, 4 Apr 2013 10:35:32 +0100 (BST)
Subject: public consultation on root zone KSK rollover
Message-ID: <201304040935.KAA15823@sunf10.rd.bbc.co.uk>

> >> The topic at hand and the specific questions that have been
> >> asked as part of the consultation are important ones;
> > 
> > Do it when you feel like, nobody should notice. Anything
> > this important should be routine procedure, make it daily.
> 
> You do realize this requires changing validating resolver
> configuration data, right?

Yes. How hard can it be (answer not required).

While it's quaint that the elders of the internet meet and bless each
new key I don't think this scales.

I know it's not easy but it needs to be simple and automatic
for wide deployment.

brandon


From randy at psg.com  Thu Apr  4 09:53:38 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 04 Apr 2013 18:53:38 +0900
Subject: RFC 1149
In-Reply-To: <CAK__KzsiGuFgAQFUOZsHjLrEewj0pRXY2vaUN4r5yZsve8oUQw@mail.gmail.com>
References: <CALOgxGbSGs-R5NdRd2J1FTpzbDxM-n5LpAophd3sWBJAixuF1g@mail.gmail.com>
 <6103682.638.1364937669528.JavaMail.root@benjamin.baylink.com>
 <465966A5F5B867419F604CD3E604C1E53B09D964@PRA-DCA-MAIL.pra.ray.com>
 <CAK__KzsiGuFgAQFUOZsHjLrEewj0pRXY2vaUN4r5yZsve8oUQw@mail.gmail.com>
Message-ID: <m238v6fwpp.wl%randy@psg.com>

> He probably was thinking of a Volvo 245...

Duett PV445


From randy at psg.com  Thu Apr  4 09:57:45 2013
From: randy at psg.com (Randy Bush)
Date: Thu, 04 Apr 2013 18:57:45 +0900
Subject: route for linx.net in Level3?
In-Reply-To: <515CB2BD.20601@network-services.uoregon.edu>
References: <515CB2BD.20601@network-services.uoregon.edu>
Message-ID: <m2zjxeehye.wl%randy@psg.com>

oops!  i have a host directly on the linx on which i can give you
shell access


From shaavik at soc.lib.md.us  Thu Apr  4 10:45:45 2013
From: shaavik at soc.lib.md.us (Steve Haavik)
Date: Thu, 4 Apr 2013 06:45:45 -0400 (EDT)
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <20130403172822.CE160597@m0005311.ppops.net>
References: <20130403172822.CE160597@m0005311.ppops.net>
Message-ID: <alpine.DEB.2.00.1304040559530.2194@clipper.soc.lib.md.us>

> It'd be nice to know if NDT was not accurate as well.  Anyone tested it?

We've been using it for a few years. On my laptop that runs linux I get 
fairly consistent results (around 935Mb/s up and down right now) over a 
1Gig routed link (a couple routers and a firewall in between.) On the Windows 
boxes I usually see a 100 to 200 Mb/s drop on the upload side. The last 
time I checked, you can compile a commandline version of the client. I 
seem to remember the commandline client not taking quite as bad a hit on 
the tests compared to running it on linux, but it's been a while since I 
tried it.

For us it's been way more accurate than the various speedtest servers our 
customers insist on trying. A while back I switched from compiling my own 
kernel and NDT to using perfSONAR-PS (http://psps.perfsonar.net/). I like 
that they've got live-cd and net-install versions. If nothing else it's 
useful for pointing out the difference between a local network issue and 
Internet Suckage.



From Valdis.Kletnieks at vt.edu  Thu Apr  4 15:16:10 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 04 Apr 2013 11:16:10 -0400
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: Your message of "Thu, 04 Apr 2013 06:18:34 +0200."
 <alpine.DEB.2.00.1304040616500.23668@uplift.swm.pp.se>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1n18k.1365038735461@email.android.com>
 <515CFC39.6010803@bogus.com>
 <alpine.DEB.2.00.1304040616500.23668@uplift.swm.pp.se>
Message-ID: <27897.1365088570@turing-police.cc.vt.edu>

On Thu, 04 Apr 2013 06:18:34 +0200, Mikael Abrahamsson said:

> I have pitched the idea in the IETF to have TCP stacks themselves report
> IP performance indicators (aggregate) and that a standard for this to be
> standardised. No takers so far.

RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R.
     Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED
     STANDARD)

Looks like a taker to me.  Also, see the work the Web10G group is doing for
Linux: http://www.web10g.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130404/78dad9d6/attachment.bin>

From swmike at swm.pp.se  Thu Apr  4 15:29:40 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 4 Apr 2013 17:29:40 +0200 (CEST)
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <27897.1365088570@turing-police.cc.vt.edu>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it1n18k.1365038735461@email.android.com>
 <515CFC39.6010803@bogus.com>
 <alpine.DEB.2.00.1304040616500.23668@uplift.swm.pp.se>
 <27897.1365088570@turing-police.cc.vt.edu>
Message-ID: <alpine.DEB.2.00.1304041722450.23668@uplift.swm.pp.se>

On Thu, 4 Apr 2013, Valdis.Kletnieks at vt.edu wrote:

> RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R.
>     Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED
>     STANDARD)
>
> Looks like a taker to me.  Also, see the work the Web10G group is doing for
> Linux: http://www.web10g.org

RFC 4989 doesn't seem to officially exist. Ah, it's 4898.

Yes, RFC4898 seems to contain a lot of interesting information, question 
is how to destill this down to something the user can understand and that 
is of interest for a support engineer who might be trying to diagnose the 
customer problem.

I agree web10g seems to be of interest as well. I'm going to read through 
their documents tomorrow.

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


From dmburgess at linktechs.net  Thu Apr  4 15:30:17 2013
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Thu, 4 Apr 2013 10:30:17 -0500
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
References: <02d401ce2f37$b63b4f10$22b1ed30$@hathcock.org>
Message-ID: <50710E9A7E64454C974049FC998EB6558F99BB@03-exchange.lti.local>

The MT speed test is a multi-connection test, think 20 streams or connections at once.    Most web based tests are single stream.  Now you get into 802.11N speedtests where they are optimized for many connections MIMO operations, hence, a single connection don't show good results, where a MT test at 20 streams would.  

Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? 
?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? 
?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? 
?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? 


-----Original Message-----
From: Lorell Hathcock [mailto:lorell at hathcock.org] 
Sent: Monday, April 1, 2013 7:19 PM
To: nanog at nanog.org
Cc: Nathan Hathcock
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test

All:

 

I am having some speedtest results that are difficult to interpret.

 

I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX.  I am running BGP with each with 100 Mbps+ on each link.

 

Some of my customers have begun complaining that they are not getting the proper speeds.  They are using speedtest.net and/or speakeasy.net to test the results.

 

My network is Mikrotik based and as such, I have access to Mikrotik's built-in bandwidth testing.

 

With a laptop on site, running against speedtest.net (which kicked me over to the Comcast speedtest server instance) I can only get 4 Mbps up and 1.5 Mbps down.  That is consistent on their desktops too.  We eliminated their routing equipment and other consumers of the bandwidth and tested and got similar results.

 

But when  we run the Mikrotik bandwidth tests (even to off-net Mikrotik devices in Hawaii and Mission, TX) we get 25+ Mbps synchronous.

 

We have run traceroutes to various traceroute servers and they go through Cogent and/or Level 3.  For the most part it does not seem to matter which path it takes, the bandwidth seems to be about the same going both routes.

 

When we run the laptop-based btest.exe against Mikrotik bandwidth test servers, the laptop got significantly better results (14 Mbps) , but not 25+ Mbps.

 

It is almost like there is a Java based problem with speedtest.net.

 

Thoughts?

 

Thanks,

 

Lorell Hathcock

 



From Valdis.Kletnieks at vt.edu  Thu Apr  4 15:43:52 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 04 Apr 2013 11:43:52 -0400
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: Your message of "Thu, 04 Apr 2013 17:29:40 +0200."
 <alpine.DEB.2.00.1304041722450.23668@uplift.swm.pp.se>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
 <49250.1365025680@turing-police.cc.vt.edu>
 <002e01ce30b5$88f69bc0$9ae3d340$@paulstewart.org>,
 <515CD36A.1000603@rollernet.us>
 <m7ixphqf7dv49cb0it118k.1365038735461@email.android.com>
 <515CFC39.6010803@bogus.com>
 <alpine.DEB.2.00.1304040616500.23668@uplift.swm.pp.se>
 <27897.1365088570@turing-police.cc.vt.edu>
 <alpine.DEB.2.00.1304041722450.23668@uplift.swm.pp.se>
Message-ID: <31260.1365090232@turing-police.cc.vt.edu>

On Thu, 04 Apr 2013 17:29:40 +0200, Mikael Abrahamsson said:
> On Thu, 4 Apr 2013, Valdis.Kletnieks at vt.edu wrote:
>
> > RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R.
> >     Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED
> >     STANDARD)
> >
> > Looks like a taker to me.  Also, see the work the Web10G group is doing for
> > Linux: http://www.web10g.org
>
> RFC 4989 doesn't seem to officially exist. Ah, it's 4898.

Bargh. How did I get a typo in there? :)

> Yes, RFC4898 seems to contain a lot of interesting information, question
> is how to destill this down to something the user can understand and that
> is of interest for a support engineer who might be trying to diagnose the
> customer problem.
>
> I agree web10g seems to be of interest as well. I'm going to read through
> their documents tomorrow.

I recently got the web10g folks and the Linux kernel and networking folks
talking to each other, it may get upstreamed in the reasonably near future.
I'll make sure somebody keeps this list informed....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130404/c5175629/attachment.bin>

From srikanth at gatech.edu  Thu Apr  4 18:07:19 2013
From: srikanth at gatech.edu (Srikanth Sundaresan)
Date: Thu, 04 Apr 2013 14:07:19 -0400
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <alpine.DEB.2.00.1304040559530.2194@clipper.soc.lib.md.us>
References: <20130403172822.CE160597@m0005311.ppops.net>
 <alpine.DEB.2.00.1304040559530.2194@clipper.soc.lib.md.us>
Message-ID: <515DC157.2070109@gatech.edu>

[Plug alert]

For longer term monitoring, Project BISmark provides an easy-to-use
system. It's an open source, customizable OpenWRT-based home router that
runs periodic network measurements (latency, throughput, packetloss,
jitter, etc) to nearby MLab servers.

It uses netperf (single and multiple TCP threads), and shaperprobe,
(UDP) for throughput measurements.

Although its original target audience is home users, it can also be used
as a monitoring tool in bigger networks.

More information here:
http://projectbismark.net/

Slides from the talk at NANOG 53:
https://www.nanog.org/meetings/nanog53/presentations/Monday/Sundaresan.pdf

- Srikanth

On 04/04/2013 06:45 AM, Steve Haavik wrote:
>> It'd be nice to know if NDT was not accurate as well.  Anyone tested it?
> 
> We've been using it for a few years. On my laptop that runs linux I get
> fairly consistent results (around 935Mb/s up and down right now) over a
> 1Gig routed link (a couple routers and a firewall in between.) On the
> Windows boxes I usually see a 100 to 200 Mb/s drop on the upload side.
> The last time I checked, you can compile a commandline version of the
> client. I seem to remember the commandline client not taking quite as
> bad a hit on the tests compared to running it on linux, but it's been a
> while since I tried it.
> 
> For us it's been way more accurate than the various speedtest servers
> our customers insist on trying. A while back I switched from compiling
> my own kernel and NDT to using perfSONAR-PS
> (http://psps.perfsonar.net/). I like that they've got live-cd and
> net-install versions. If nothing else it's useful for pointing out the
> difference between a local network issue and Internet Suckage.
> 
> 


From jra at baylink.com  Thu Apr  4 18:57:11 2013
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 4 Apr 2013 14:57:11 -0400 (EDT)
Subject: route for linx.net in Level3?
In-Reply-To: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
Message-ID: <9353667.934.1365101831315.JavaMail.root@benjamin.baylink.com>

Yes.  In the fallout from the Cloudflare attack of last week it was
announced that several IXs were going to stop advertising the 
address space of their peering lan, which properly does not need to
be advertised anyway.

Yes, that will cause some minor problems for those who work for and
with the companies that peer there, but they are *clients*, and should
be able to have other similar arrangements made for them.

Cheers,
-- jra

----- Original Message -----
> From: "Yang Yu" <yang.yu.list at gmail.com>
> To: kemp at network-services.uoregon.edu
> Cc: "NANOG list" <nanog at nanog.org>
> Sent: Wednesday, April 3, 2013 7:20:44 PM
> Subject: Re: route for linx.net in Level3?
> I noticed it too this morning from a AS3549 customer. Level 3 LG shows
> no route for 195.66.232.0/22 on North American sites.
> 
> On Wed, Apr 3, 2013 at 6:52 PM, John Kemp
> <kemp at network-services.uoregon.edu> wrote:
> >
> > Having trouble reaching route-views.linx.routeviews.org from AS3582.
> >
> > I'm assuming that some folks stopped carrying
> > this particular linx.net address prefix
> > as of this morning. ?!?
> >
> > $ whois -h whois.cymru.com " -v 195.66.241.146"
> > AS | IP | BGP Prefix | CC | Registry |
> > Allocated | AS Name
> > 5459 | 195.66.241.146 | 195.66.240.0/22 | GB | ripencc |
> > 1997-12-01 | LINX-AS London Internet Exchange Ltd.
> >
> > $ dig +short 146.241.66.195.peer.asn.cymru.com TXT
> > "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"
> >
> > --
> > John Kemp (kemp at routeviews.org)
> > RouteViews Engineer
> > NOC: noc at routeviews.org
> > MAIL: help at routeviews.org
> > WWW: http://www.routeviews.org
> >

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From bicknell at ufp.org  Thu Apr  4 19:29:03 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 4 Apr 2013 12:29:03 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <9353667.934.1365101831315.JavaMail.root@benjamin.baylink.com>
References: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
 <9353667.934.1365101831315.JavaMail.root@benjamin.baylink.com>
Message-ID: <20130404192903.GA51151@ussenterprise.ufp.org>

In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth wrote:
> Yes.  In the fallout from the Cloudflare attack of last week it was
> announced that several IXs were going to stop advertising the 
> address space of their peering lan, which properly does not need to
> be advertised anyway.

Well, now that's a big maybe.  I was a big advocate for the peering
exchanges each having their own ASN and announcing the peering block
back in the day, and it seems people may have forgotten some of the
issues with unadvertised peering exchange blocks.

It breaks traceroute for many people:

  The ICMP TTL Unreachable will come from a non-routed network (the
  exchange LAN).  If it crosses another network boundary doing uRPF,
  even in loose mode, those unreachables will be dropped.

  It also reduces the utility of a tool like MTR.  Without the ICMP
  responese it won't know where to ping, and even if it receives
  the ICMP it's likely packets towards the LAN IP's will be dropped
  with no route to host.

It has the potential to break PMTU discovery for many people:

  If a router is connected to the exchange and a lower MTU link a
  packet coming in with DF set will get an ICMP would-fragment
  reply.  Most vendors source from the input interface, e.g. the
  exchange IP.  Like the traceorute case, if crosses another network
  boundary doing uRPF,   even in loose mode, those ICMP messages
  will be lost, resulting in a PMTU black hole.

  Some vendors have knobs to force the ICMP to be emitted from a
  loopback, but not all.  People would have to turn it on.

But hey, this is a good thing because a DDOS caused issues, right?
Well, not so much.  Even if the exchange does not advertise the
exchange LAN, it's probably the case that it is in the IGP (or at
least IBGP) of everyone connected to it, and by extension all of
their customers with a default route pointed at them.  For the most
popular exchanges (AMS-IX, for instance) I suspect the percentage
of end users who can reach the exchange LAN without it being
explicitly routed to be well over 80%, perhaps into the upper 90%
range.  So when those boxes DDOS, they are going to all DDOS the
LAN anyway.

Security through obscurity does not work.  This is going to annoy some
people just trying to do their day job, and not make a statistical
difference to the attackers trying to take out infrastructure.

How about we all properly implement BCP 38 instead?

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

From tom at cloudflare.com  Thu Apr  4 19:38:12 2013
From: tom at cloudflare.com (Tom Paseka)
Date: Thu, 4 Apr 2013 12:38:12 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <20130404192903.GA51151@ussenterprise.ufp.org>
References: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
 <9353667.934.1365101831315.JavaMail.root@benjamin.baylink.com>
 <20130404192903.GA51151@ussenterprise.ufp.org>
Message-ID: <CAL89SgJZ8m3TfZmp9TcDBNzmp73J_T-dauPfwph-gAguRzuLhw@mail.gmail.com>

On Thu, Apr 4, 2013 at 12:29 PM, Leo Bicknell <bicknell at ufp.org> wrote:
>
> But hey, this is a good thing because a DDOS caused issues, right?
> Well, not so much.  Even if the exchange does not advertise the
> exchange LAN, it's probably the case that it is in the IGP (or at
> least IBGP) of everyone connected to it, and by extension all of
> their customers with a default route pointed at them.  For the most
> popular exchanges (AMS-IX, for instance) I suspect the percentage
> of end users who can reach the exchange LAN without it being
> explicitly routed to be well over 80%, perhaps into the upper 90%
> range.  So when those boxes DDOS, they are going to all DDOS the
> LAN anyway.


Yes, thats why everyone needs to set up some sanity in their networks.

This was presented at an APNIC conference a little while back:
http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf

hundreds of networks are improperly set up and are being abused (and
abusing) to the IXP LANs.

>
> Security through obscurity does not work.  This is going to annoy some
> people just trying to do their day job, and not make a statistical
> difference to the attackers trying to take out infrastructure.


This isn't security through obscurity. This is saving the IXP from
getting 100's of G's over transit, which should just be for their
corporate network.

>
> How about we all properly implement BCP 38 instead?


Agree.


From brian.peter.dickson at gmail.com  Thu Apr  4 19:53:39 2013
From: brian.peter.dickson at gmail.com (Brian Dickson)
Date: Thu, 4 Apr 2013 15:53:39 -0400
Subject: route for linx.net in Level3?
Message-ID: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>

Leo Bicknell wrote:

Even if the exchange does not advertise the

exchange LAN, it's probably the case that it is in the IGP (or at

least IBGP) of everyone connected to it, and by extension all of

their customers with a default route pointed at them.

Actually, that may not be the case, and probably *should* not be the case.

Here's why, in a nutshell:

If two regional ISPs on either side of the planet, point default to the
same Global ISP,
even if they do not peer with that ISP, by using the IX next-hop at IX A
(for ISP A),
and IX B (for ISP B), then the Global ISP is now giving free on-net transit
to A and B.

So, it turns out that pretty much the only way to prevent this at a routing
level,
is to not carry IXP networks (in IGP or IBGP), but rather to do
next-hop-self.

The other way is to filter at a packet level on ingress, based on Layer 2
information,
which on many kinds of IX-capable hardware, is actually impossible.

So, when it comes to IXPs: Next-Hop-Self.

(BCP 38 actually doesn't even enter into it, oddly enough.)

Brian

From jabley at hopcount.ca  Thu Apr  4 20:10:45 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 4 Apr 2013 16:10:45 -0400
Subject: route for linx.net in Level3?
In-Reply-To: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
Message-ID: <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>


On 2013-04-04, at 15:53, Brian Dickson <brian.peter.dickson at gmail.com> wrote:

> Leo Bicknell wrote:
> 
> Even if the exchange does not advertise the
> exchange LAN, it's probably the case that it is in the IGP (or at
> least IBGP) of everyone connected to it,

I have experience of several networks where that is not the case. IGP carries routes for loopback and internal-facing interfaces; external-facing interface routes are only known to the local router; pervasive next-hop-self for IBGP.

So, no great survey, but don't assume that everybody does things the same way.


Joe



From adam.vitkovsky at swan.sk  Thu Apr  4 20:26:13 2013
From: adam.vitkovsky at swan.sk (Adam Vitkovsky)
Date: Thu, 4 Apr 2013 22:26:13 +0200
Subject: route for linx.net in Level3?
In-Reply-To: <20130404192903.GA51151@ussenterprise.ufp.org>
References: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
 <9353667.934.1365101831315.JavaMail.root@benjamin.baylink.com>
 <20130404192903.GA51151@ussenterprise.ufp.org>
Message-ID: <03df01ce3172$a6f83440$f4e89cc0$@swan.sk>

First of all I agree with Leo that not advertising IX prefixes permanently
causes more problems than it solves. 

> Even if the exchange does not advertise the exchange LAN, it's probably
the case that it is in the IGP (or at least IBGP) of everyone connected to
it 
 Well if I would peer with such an ISP at London and Frankfurt I could
create a GRE tunnel from London to Frankfurt via the other ISP and use it to
transport packets that would otherwise have to traverse my backbone. 
 Or if my peer has a router at IX that happens to have full routing view I
can just point a static default toward it and have a free transit. 


Check out: http://www.bcp38.info
adam
-----Original Message-----
From: Leo Bicknell [mailto:bicknell at ufp.org] 
Sent: Thursday, April 04, 2013 9:29 PM
To: NANOG
Subject: Re: route for linx.net in Level3?

In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth
wrote:
> Yes.  In the fallout from the Cloudflare attack of last week it was 
> announced that several IXs were going to stop advertising the address 
> space of their peering lan, which properly does not need to be 
> advertised anyway.

Well, now that's a big maybe.  I was a big advocate for the peering
exchanges each having their own ASN and announcing the peering block back in
the day, and it seems people may have forgotten some of the issues with
unadvertised peering exchange blocks.

It breaks traceroute for many people:

  The ICMP TTL Unreachable will come from a non-routed network (the
  exchange LAN).  If it crosses another network boundary doing uRPF,
  even in loose mode, those unreachables will be dropped.

  It also reduces the utility of a tool like MTR.  Without the ICMP
  responese it won't know where to ping, and even if it receives
  the ICMP it's likely packets towards the LAN IP's will be dropped
  with no route to host.

It has the potential to break PMTU discovery for many people:

  If a router is connected to the exchange and a lower MTU link a
  packet coming in with DF set will get an ICMP would-fragment
  reply.  Most vendors source from the input interface, e.g. the
  exchange IP.  Like the traceorute case, if crosses another network
  boundary doing uRPF,   even in loose mode, those ICMP messages
  will be lost, resulting in a PMTU black hole.

  Some vendors have knobs to force the ICMP to be emitted from a
  loopback, but not all.  People would have to turn it on.

But hey, this is a good thing because a DDOS caused issues, right?
Well, not so much.  Even if the exchange does not advertise the exchange
LAN, it's probably the case that it is in the IGP (or at least IBGP) of
everyone connected to it, and by extension all of their customers with a
default route pointed at them.  For the most popular exchanges (AMS-IX, for
instance) I suspect the percentage of end users who can reach the exchange
LAN without it being explicitly routed to be well over 80%, perhaps into the
upper 90% range.  So when those boxes DDOS, they are going to all DDOS the
LAN anyway.

Security through obscurity does not work.  This is going to annoy some
people just trying to do their day job, and not make a statistical
difference to the attackers trying to take out infrastructure.

How about we all properly implement BCP 38 instead?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/



From randy at psg.com  Thu Apr  4 20:43:44 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 05 Apr 2013 05:43:44 +0900
Subject: route for linx.net in Level3?
In-Reply-To: <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
 <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
Message-ID: <m2k3oido1r.wl%randy@psg.com>

>> Even if the exchange does not advertise the exchange LAN, it's
>> probably the case that it is in the IGP (or at least IBGP) of
>> everyone connected to it,

yikes!  this is quite ill-advised and i don't know anyone who does
this, but i think all my competitors should.

> I have experience of several networks where that is not the case. IGP
> carries routes for loopback and internal-facing interfaces;

i have seen some carry external because, for some reason, they do not
want to re-write next-hop at the border.

randy


From fergdawgster at gmail.com  Thu Apr  4 20:47:22 2013
From: fergdawgster at gmail.com (Paul Ferguson)
Date: Thu, 4 Apr 2013 13:47:22 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <03df01ce3172$a6f83440$f4e89cc0$@swan.sk>
References: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
 <9353667.934.1365101831315.JavaMail.root@benjamin.baylink.com>
 <20130404192903.GA51151@ussenterprise.ufp.org>
 <03df01ce3172$a6f83440$f4e89cc0$@swan.sk>
Message-ID: <CANQy6FYGPPRo8uFp=CcSpWw4=PqiC4nd+HwxgYbP-GbHFta-ZQ@mail.gmail.com>

On Thu, Apr 4, 2013 at 1:26 PM, Adam Vitkovsky <adam.vitkovsky at swan.sk> wrote:

> Check out: http://www.bcp38.info

Right on. :-)

- ferg


--
"Fergie", a.k.a. Paul Ferguson
 fergdawgster(at)gmail.com


From jaydesh9 at gmail.com  Thu Apr  4 20:37:52 2013
From: jaydesh9 at gmail.com (=?UTF-8?B?SmF5cmFtIETDqXNocGFuZMOp?=)
Date: Thu, 4 Apr 2013 13:37:52 -0700
Subject: Wells Fargo getting DDoSed ?
Message-ID: <CAGj4CucHje+Xmce+0xp0FTJDi=yjU2cZp7crZiYsngqCzNfJNA@mail.gmail.com>

I observed that since morning Wells Fargo web services are either not
reachable or are really slow.
I think they are getting DDoSed again. Any official information yet ?

Regards,
-Jay.



--
"Subvert the paradigm." - C.K. Prahlad


From codygrosskopf at gmail.com  Thu Apr  4 21:21:07 2013
From: codygrosskopf at gmail.com (Cody Grosskopf)
Date: Thu, 4 Apr 2013 14:21:07 -0700
Subject: Microsoft Email Admin
Message-ID: <CABJRgnXvTXpYvO=jdc2cZvELZ8PSYFgxbF+-LkLi1aHA2pDSGA@mail.gmail.com>

Can a Microsoft email admin contact me off list in regards to issues
emailing a few of our domains?

Thanks,
Cody

From kemp at network-services.uoregon.edu  Thu Apr  4 22:06:03 2013
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Thu, 04 Apr 2013 15:06:03 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
References: <515CB2BD.20601@network-services.uoregon.edu>
 <CAFwKRnRngdxrYKQDbx8SMeFecC2jXo-mvgK6ZGeaB5RDeDnXhw@mail.gmail.com>
Message-ID: <515DF94B.5040501@network-services.uoregon.edu>


Yeah, you wouldn't think that one should fall out.
It is possible that my 195.66.241.146 really should
be something sitting within: 195.66.232.0/22.

I'll have to talk with some of the LINX folks to
understand whether they are intending that 195.66.240.0/22
and 195.66.232.0/22 are treated differently.  If that's the
case, I may need to move off of 195.66.240.0/22.

Thanks,
John Kemp (kemp at routeviews.org)

On 4/3/13 4:20 PM, Yang Yu wrote:
> I noticed it too this morning from a AS3549 customer. Level 3 LG shows
> no route for 195.66.232.0/22 on North American sites.
> 
> On Wed, Apr 3, 2013 at 6:52 PM, John Kemp
> <kemp at network-services.uoregon.edu> wrote:
>>
>> Having trouble reaching route-views.linx.routeviews.org from AS3582.
>>
>> I'm assuming that some folks stopped carrying
>> this particular linx.net address prefix
>> as of this morning. ?!?
>>
>> $ whois -h whois.cymru.com " -v 195.66.241.146"
>> AS      | IP               | BGP Prefix          | CC | Registry |
>> Allocated  | AS Name
>> 5459    | 195.66.241.146   | 195.66.240.0/22     | GB | ripencc  |
>> 1997-12-01 | LINX-AS London Internet Exchange Ltd.
>>
>> $ dig +short 146.241.66.195.peer.asn.cymru.com TXT
>> "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"
>>
>> --
>> John Kemp (kemp at routeviews.org)
>> RouteViews Engineer
>> NOC: noc at routeviews.org
>> MAIL: help at routeviews.org
>> WWW: http://www.routeviews.org
>>


From tom at cloudflare.com  Thu Apr  4 22:11:24 2013
From: tom at cloudflare.com (Tom Paseka)
Date: Thu, 4 Apr 2013 15:11:24 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <m2k3oido1r.wl%randy@psg.com>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
 <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
 <m2k3oido1r.wl%randy@psg.com>
Message-ID: <CAL89SgJDG77Ey2rRUKXYHbwY2Y4QfnucDhUrsqKrXnXXeH68+Q@mail.gmail.com>

On Thu, Apr 4, 2013 at 1:43 PM, Randy Bush <randy at psg.com> wrote:
>>> Even if the exchange does not advertise the exchange LAN, it's
>>> probably the case that it is in the IGP (or at least IBGP) of
>>> everyone connected to it,
>
> yikes!  this is quite ill-advised and i don't know anyone who does
> this, but i think all my competitors should.
>

Its more common than uncommon.

At WIX (Wellington), 64 out of 93 members will carry packets destined
to APE (Auckland Exchange).  (source:
http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf)
 and this is just New Zealand!

Just checked a few exchanges, not just are the IXP ranges being
carried, they're being leaked:

Equinix SG:

$ bgpctl show rib 202.79.197.0/24
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination          gateway          lpref   med aspath origin
      202.79.197.0/24              100     0 13335 23947 23947 ?
      202.79.197.0/24              100     0 13335 10026 i

Any2 LA:

bgpctl show rib 206.223.143.0/24
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination          gateway          lpref   med aspath origin
      206.223.143.0/24             100     0 13335 9304 i
      206.223.143.0/24             100     0 13335 9304 i
      206.223.143.0/24             100     0 13335 4635 9304 i
      206.223.143.0/24             100     0 13335 9304 i


>> I have experience of several networks where that is not the case. IGP
>> carries routes for loopback and internal-facing interfaces;
>
> i have seen some carry external because, for some reason, they do not
> want to re-write next-hop at the border.
>
> randy
>


From randy at psg.com  Fri Apr  5 01:01:34 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 05 Apr 2013 10:01:34 +0900
Subject: route for linx.net in Level3?
In-Reply-To: <CAL89SgJDG77Ey2rRUKXYHbwY2Y4QfnucDhUrsqKrXnXXeH68+Q@mail.gmail.com>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
 <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
 <m2k3oido1r.wl%randy@psg.com>
 <CAL89SgJDG77Ey2rRUKXYHbwY2Y4QfnucDhUrsqKrXnXXeH68+Q@mail.gmail.com>
Message-ID: <m2fvz5eqoh.wl%randy@psg.com>

> On Thu, Apr 4, 2013 at 1:43 PM, Randy Bush <randy at psg.com> wrote:
>>>> Even if the exchange does not advertise the exchange LAN, it's
>>>> probably the case that it is in the IGP (or at least IBGP) of
>>>> everyone connected to it,
>>
>> yikes!  this is quite ill-advised and i don't know anyone who does
>> this, but i think all my competitors should.
>>
> 
> Its more common than uncommon.
> 
> At WIX (Wellington), 64 out of 93 members will carry packets destined
> to APE (Auckland Exchange).  (source:
> http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf)
>  and this is just New Zealand!
> 
> Just checked a few exchanges, not just are the IXP ranges being
> carried, they're being leaked:

i am not unhappy by the exchange mesh being carried within a member and
being propagated to their customer cone, see my nanog preso of feb 1997
and leo's recent post.

it's putting such things in one's igp that disgusts me.  as joe said,
igp is just for the loopbacks and other interfaces it takes to make your
ibgp work.

randy


From bicknell at ufp.org  Fri Apr  5 01:26:57 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 4 Apr 2013 18:26:57 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <m2fvz5eqoh.wl%randy@psg.com>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
 <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
 <m2k3oido1r.wl%randy@psg.com>
 <CAL89SgJDG77Ey2rRUKXYHbwY2Y4QfnucDhUrsqKrXnXXeH68+Q@mail.gmail.com>
 <m2fvz5eqoh.wl%randy@psg.com>
Message-ID: <20130405012657.GA65513@ussenterprise.ufp.org>

In a message written on Fri, Apr 05, 2013 at 10:01:34AM +0900, Randy Bush wrote:
> it's putting such things in one's igp that disgusts me.  as joe said,
> igp is just for the loopbacks and other interfaces it takes to make your
> ibgp work.

While your method is correct for probably 80-90% of the ISP networks,
the _why_ people do that has almost been lost to the mysts of time.
I'm sure Randy knows what I'm about to type, but for the rest of
the list...

The older school of thought was to put all of the edge interfaces
into the IGP, and then carry all of the external routes in BGP.
This caused a one level recursion in the routers:
  eBGP Route->IXP w/IGP Next Hop->Output Interface

The Internet then became a thing, and there started to be a lot of
BGP speaking customers (woohoo! T1's for everyone!), and thus lots
of edge /30's in the IGP.  The IGP convergence time quickly got
very, very bad.  I think a network or two may have even broken an
IGP.

The "solution" was to take edge interfaces (really "redistribute
connected" for most people) and move it from the IGP to BGP, and
to make that work BGP had to set "next-hop-self" on the routes.
The exchange /24 would now appear in BGP with a next hop of the
router loopback, the router itself knew it was directly connected.
A side effect is that this caused a two-step lookup in BGP:
  eBGP-Route->IXP w/Router Loopback Next Hop->Loopback w/IGP Next Hop->Output Interface

IGP's went from O(bgp_customers) routes to O(router) routes, and
stopped falling over and converged much faster.  On the flip side,
every RIB->FIB operation now has to go through an extra step of
recursion for every route, taking BGP resolution from O(routes) to
O(routes * 1.1ish).

Since all this happened, CPU's have gotten much faster, RAM has
gotten much larger.  Most people have never revisited the problem,
the scaling of IGP's, or what hardware can do today.

There are plenty of scenarios where the "old way" works just spiffy,
and can have some advantages.  For a network with a very low number of
BGP speakers the faster convergence of the IGP may be desireable.

Not every network is built the same, or has the same scaling
properties.  What's good for a CDN may not be good for an access
ISP, and vice versa, for example.

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

From brobare at noanet.net  Fri Apr  5 05:40:16 2013
From: brobare at noanet.net (Brandon Robare)
Date: Fri, 5 Apr 2013 05:40:16 +0000
Subject: 80 km BiDi XFPs
In-Reply-To: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
Message-ID: <CD83B15A.2BA3D%brobare@noanet.microsoftonline.com>

Closest I've seen is 60km. I would be interested to hear if someone knows
of an 80km option.

http://www.fiberstore.com/new-xfp-bidi-10gbps-single-mode-60km-1330nmtx-127
0nmrx-transceiver-module-p-13175.html


-- 
Brandon Robare
Network Engineer, NoaNet
c: 503.798.1515
noc: 866.662.6380 | noc at noanet.net





On 4/2/13 4:15 PM, "Frank Bulk" <frnkblk at iname.com> wrote:

>Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
>supplier of generics doesn't have an option for us, but I would really
>like
>to avoid leasing additional fibers.
>
>Frank
>
>
>




From ryan at finnesey.com  Fri Apr  5 06:33:22 2013
From: ryan at finnesey.com (Ryan Finnesey)
Date: Fri, 5 Apr 2013 06:33:22 +0000
Subject: Wells Fargo getting DDoSed ?
In-Reply-To: <CAGj4CucHje+Xmce+0xp0FTJDi=yjU2cZp7crZiYsngqCzNfJNA@mail.gmail.com>
References: <CAGj4CucHje+Xmce+0xp0FTJDi=yjU2cZp7crZiYsngqCzNfJNA@mail.gmail.com>
Message-ID: <3CD5C9B8E677CE45AF0E1EB95AA4EF583D193255@BY2PRD0510MB376.namprd05.prod.outlook.com>

I have been having issues with their iPad App all day 

-----Original Message-----
From: Jayram D?shpand? [mailto:jaydesh9 at gmail.com] 
Sent: Thursday, April 4, 2013 4:38 PM
To: nanog at nanog.org
Subject: Wells Fargo getting DDoSed ?

I observed that since morning Wells Fargo web services are either not reachable or are really slow.
I think they are getting DDoSed again. Any official information yet ?

Regards,
-Jay.



--
"Subvert the paradigm." - C.K. Prahlad



From adam.vitkovsky at swan.sk  Fri Apr  5 07:32:52 2013
From: adam.vitkovsky at swan.sk (Adam Vitkovsky)
Date: Fri, 5 Apr 2013 09:32:52 +0200
Subject: route for linx.net in Level3?
In-Reply-To: <20130405012657.GA65513@ussenterprise.ufp.org>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
 <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
 <m2k3oido1r.wl%randy@psg.com>
 <CAL89SgJDG77Ey2rRUKXYHbwY2Y4QfnucDhUrsqKrXnXXeH68+Q@mail.gmail.com>
 <m2fvz5eqoh.wl%randy@psg.com> <20130405012657.GA65513@ussenterprise.ufp.org>
Message-ID: <03f801ce31cf$c84a8000$58df8000$@swan.sk>

> The older school of thought was to put all of the edge interfaces into the
IGP, and then carry all of the external routes in BGP. 
I thought people where doing it because IGP converged faster than iBGP and
in case of an external link failure the ingress PE was informed via IGP that
it has to find an alternate next-hop. 
Though now with the advent of BGP PIC this is not an argument anymore. 

adam



From bicknell at ufp.org  Fri Apr  5 13:14:01 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 5 Apr 2013 06:14:01 -0700
Subject: route for linx.net in Level3?
In-Reply-To: <03f801ce31cf$c84a8000$58df8000$@swan.sk>
References: <CAH1iCiriKczJcjZbirLhmdPqjqoJ_TO+UrQqeKwu1WjFYLa6YQ@mail.gmail.com>
 <93BEDCB3-BBC0-4388-9BB1-22B3BBDB29C0@hopcount.ca>
 <m2k3oido1r.wl%randy@psg.com>
 <CAL89SgJDG77Ey2rRUKXYHbwY2Y4QfnucDhUrsqKrXnXXeH68+Q@mail.gmail.com>
 <m2fvz5eqoh.wl%randy@psg.com> <20130405012657.GA65513@ussenterprise.ufp.org>
 <03f801ce31cf$c84a8000$58df8000$@swan.sk>
Message-ID: <20130405131401.GA91666@ussenterprise.ufp.org>

In a message written on Fri, Apr 05, 2013 at 09:32:52AM +0200, Adam Vitkovsky wrote:
> I thought people where doing it because IGP converged faster than iBGP and
> in case of an external link failure the ingress PE was informed via IGP that
> it has to find an alternate next-hop. 
> Though now with the advent of BGP PIC this is not an argument anymore. 

You're talking about stuff that's all 7-10 years after the decisions
were made that I described in my previous e-mail.  Tag switching
(now MPLS) had not yet been invented/deployed when the first
"next-hop-self" wave occured it was all about scaling both the IGP
and BGP.

In some MPLS topologies it may speed re-routing to have edge interfaces
in the IGP due to the faster convergence of IGP's.  YMMV, Batteries not
Included, Some Assembly Required.

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

From morrowc.lists at gmail.com  Fri Apr  5 13:36:49 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 5 Apr 2013 09:36:49 -0400
Subject: Wells Fargo getting DDoSed ?
In-Reply-To: <3CD5C9B8E677CE45AF0E1EB95AA4EF583D193255@BY2PRD0510MB376.namprd05.prod.outlook.com>
References: <CAGj4CucHje+Xmce+0xp0FTJDi=yjU2cZp7crZiYsngqCzNfJNA@mail.gmail.com>
 <3CD5C9B8E677CE45AF0E1EB95AA4EF583D193255@BY2PRD0510MB376.namprd05.prod.outlook.com>
Message-ID: <CAL9jLaYXWzGhGWmOS9uKycBzBwK=Pas1iMROuotoqNeeEmKe5Q@mail.gmail.com>

On Fri, Apr 5, 2013 at 2:33 AM, Ryan Finnesey <ryan at finnesey.com> wrote:

> I have been having issues with their iPad App all day
>
>
the boneheads doing the attacking keep calling their shots on pastebin...

http://www.reuters.com/article/2013/03/26/net-us-wellsfargo-website-attacks-idUSBRE92P14320130326

which is from the 26th, but I suspect some judicious searching on
webcrawler would get you results as well.


> -----Original Message-----
> From: Jayram D?shpand? [mailto:jaydesh9 at gmail.com]
> Sent: Thursday, April 4, 2013 4:38 PM
> To: nanog at nanog.org
> Subject: Wells Fargo getting DDoSed ?
>
> I observed that since morning Wells Fargo web services are either not
> reachable or are really slow.
> I think they are getting DDoSed again. Any official information yet ?
>
> Regards,
> -Jay.
>
>
>
> --
> "Subvert the paradigm." - C.K. Prahlad
>
>
>

From jcole at tularosa.net  Fri Apr  5 14:50:05 2013
From: jcole at tularosa.net (Jerimiah Cole)
Date: Fri, 05 Apr 2013 08:50:05 -0600
Subject: 80 km BiDi XFPs
In-Reply-To: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
Message-ID: <515EE49D.8070508@tularosa.net>

On 04/02/2013 05:15 PM, Frank Bulk wrote:
> Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
> supplier of generics doesn't have an option for us, but I would really like
> to avoid leasing additional fibers.

I'm looking at a data sheet from Transition Networks that lists 80 km
(24 dB) and longer.  I've used some of their SFPs and media converters
without trouble, but not these in particular.

http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=TN-SFP-xxx-Simplex


From mihai at ploiesti.rdsnet.ro  Fri Apr  5 14:58:30 2013
From: mihai at ploiesti.rdsnet.ro (Mihai Necsa)
Date: Fri, 05 Apr 2013 17:58:30 +0300
Subject: 80 km BiDi XFPs
In-Reply-To: <515EE49D.8070508@tularosa.net>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <515EE49D.8070508@tularosa.net>
Message-ID: <515EE696.3010907@ploiesti.rdsnet.ro>

http://www.fiberworks.eu/Webshop/Optical-transceivers/SFP-Bi-Di-/-GPON/Gbit-Ethernet-Bi-Di-1310/1550/SFP-BiDi--125-Gbps-GigE--DDM--SM--80km-Tx-Rx1310-1550nm--26dB--LC-SFP-GE-BX80D-35-p0000018066.aspx

already in production for 2 links

On 04/05/2013 05:50 PM, Jerimiah Cole wrote:
> On 04/02/2013 05:15 PM, Frank Bulk wrote:
>> Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
>> supplier of generics doesn't have an option for us, but I would really like
>> to avoid leasing additional fibers.
>
> I'm looking at a data sheet from Transition Networks that lists 80 km
> (24 dB) and longer.  I've used some of their SFPs and media converters
> without trouble, but not these in particular.
>
> http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=TN-SFP-xxx-Simplex
>
>
>

-- 
Mihai



From jra at baylink.com  Fri Apr  5 16:25:10 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 5 Apr 2013 12:25:10 -0400 (EDT)
Subject: BCP38.info
Message-ID: <19616011.1052.1365179110498.JavaMail.root@benjamin.baylink.com>

Ok; I've got a Main Page up at BCP38.info, as well as some supporting
Glossary articles, and the first of a series of writeups on 38 for audiences
of different sizes and types:

  http://www.bcp38.info/index.php/Information_for_end-users

I invite comments, contributions, editing, and people telling me politely
that I'm out of my mind.  :-)

If you wanna write the articles for larger sites, that'd be great too, yeah.

Cheers,
-- jra  
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From rcarpen at network1.net  Fri Apr  5 16:39:57 2013
From: rcarpen at network1.net (Randy Carpenter)
Date: Fri, 5 Apr 2013 12:39:57 -0400 (EDT)
Subject: 80 km BiDi XFPs
In-Reply-To: <515EE696.3010907@ploiesti.rdsnet.ro>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <515EE49D.8070508@tularosa.net> <515EE696.3010907@ploiesti.rdsnet.ro>
Message-ID: <798926481.95954.1365179997836.JavaMail.root@network1.net>


I'm going to guess that this is not going to meet the OP's request for an XFP, which would be 10GbE (and not an SFP).


thanks,
-Randy


----- Original Message -----
> http://www.fiberworks.eu/Webshop/Optical-transceivers/SFP-Bi-Di-/-GPON/Gbit-Ethernet-Bi-Di-1310/1550/SFP-BiDi--125-Gbps-GigE--DDM--SM--80km-Tx-Rx1310-1550nm--26dB--LC-SFP-GE-BX80D-35-p0000018066.aspx
> 
> already in production for 2 links
> 
> On 04/05/2013 05:50 PM, Jerimiah Cole wrote:
> > On 04/02/2013 05:15 PM, Frank Bulk wrote:
> >> Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
> >> supplier of generics doesn't have an option for us, but I would really
> >> like
> >> to avoid leasing additional fibers.
> >
> > I'm looking at a data sheet from Transition Networks that lists 80 km
> > (24 dB) and longer.  I've used some of their SFPs and media converters
> > without trouble, but not these in particular.
> >
> > http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=TN-SFP-xxx-Simplex
> >
> >
> >
> 
> --
> Mihai
> 
> 
> 
> 


From matt.addison at lists.evilgeni.us  Fri Apr  5 16:45:31 2013
From: matt.addison at lists.evilgeni.us (Matt Addison)
Date: Fri, 5 Apr 2013 12:45:31 -0400
Subject: 80 km BiDi XFPs
In-Reply-To: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
Message-ID: <7774244507336980754@unknownmsgid>

How much spare margin do you have? Could you roll your own with a pair
of mismatched (C|D)WDM XFPs and a mux on each end?

Sent from my mobile device, so please excuse any horrible misspellings.

On Apr 2, 2013, at 19:16, Frank Bulk <frnkblk at iname.com> wrote:

> Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
> supplier of generics doesn't have an option for us, but I would really like
> to avoid leasing additional fibers.
>
> Frank
>
>


From drc at virtualized.org  Fri Apr  5 16:53:09 2013
From: drc at virtualized.org (David Conrad)
Date: Sat, 6 Apr 2013 00:53:09 +0800
Subject: public consultation on root zone KSK rollover
In-Reply-To: <201304040935.KAA15823@sunf10.rd.bbc.co.uk>
References: <201304040935.KAA15823@sunf10.rd.bbc.co.uk>
Message-ID: <97EF19E7-AB4B-4472-9F1D-3FE3BA176A0E@virtualized.org>

Brandon,

On Apr 4, 2013, at 5:35 PM, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote:
>> You do realize this requires changing validating resolver
>> configuration data, right?
> 
> Yes. How hard can it be (answer not required).
> 
> While it's quaint that the elders of the internet meet and bless each
> new key I don't think this scales.

The point of the wildly over-engineered root key signing ceremony is to build trust by publicly demonstrating at every step there is no opportunity for intentional or accidental badness to occur without being noticed.  Compare this to the processes used by commercial X.509CAs when they roll their root keys (you might also want to look at how often they roll their keys).

> I know it's not easy but it needs to be simple and automatic for wide deployment.

Even with RFC 5011 support in every validating resolver on the planet (not holding my breath), this requires all of those validating resolvers to accept a directive from the "outside" which instructs software to write something to permanent storage.  I can easily imagine some folks being a bit nervous about this. Particularly given it would seem some CPE developers can't figure out how to write DNS resolvers that can be configured to not respond to arbitrary external queries.

Frequency of root key rolling is actually a fairly complicated risk/benefit tradeoff. Frequently rolling means its more likely that the roll will be successful globally. However, it also increases the risk of (a) breaking DNS resolution for some percentage of the Internet and (b) catastrophically failing such that RFC 5011-style rollover will no longer work necessitating a manual reconfiguration of every validating resolver on the Internet. "Choose wisely".

In any event, if you haven't already I would encourage you to provide comments at the URL Joe referenced.

Regards,
-drc



From jcole at tularosa.net  Fri Apr  5 16:58:49 2013
From: jcole at tularosa.net (Jerimiah Cole)
Date: Fri, 05 Apr 2013 10:58:49 -0600
Subject: 80 km BiDi XFPs
In-Reply-To: <798926481.95954.1365179997836.JavaMail.root@network1.net>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <515EE49D.8070508@tularosa.net> <515EE696.3010907@ploiesti.rdsnet.ro>
 <798926481.95954.1365179997836.JavaMail.root@network1.net>
Message-ID: <515F02C9.8080401@tularosa.net>

On 04/05/2013 10:39 AM, Randy Carpenter wrote:
> 
> I'm going to guess that this is not going to meet the OP's request
> for an XFP, which would be 10GbE (and not an SFP).

Probably a safe guess.  Mea culpa.


From cra at WPI.EDU  Fri Apr  5 17:15:08 2013
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 5 Apr 2013 13:15:08 -0400
Subject: 80 km BiDi XFPs
In-Reply-To: <515F02C9.8080401@tularosa.net>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <515EE49D.8070508@tularosa.net>
 <515EE696.3010907@ploiesti.rdsnet.ro>
 <798926481.95954.1365179997836.JavaMail.root@network1.net>
 <515F02C9.8080401@tularosa.net>
Message-ID: <20130405171507.GP3010@angus.ind.WPI.EDU>

On Fri, Apr 05, 2013 at 10:58:49AM -0600, Jerimiah Cole wrote:
> On 04/05/2013 10:39 AM, Randy Carpenter wrote:
> > 
> > I'm going to guess that this is not going to meet the OP's request
> > for an XFP, which would be 10GbE (and not an SFP).
> 
> Probably a safe guess.  Mea culpa.

Check out Integra Networks.  Their catalog lists a 10G XFP Bi-Dir
80km:

http://integranetworks.net/wp-content/uploads/2012/06/Integra-Networks-Catalog-20122.pdf

XFP-CXX-80-D (CWDM)
XFP-DXX-80-D (DWDM)


From cscora at apnic.net  Fri Apr  5 18:33:12 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 6 Apr 2013 04:33:12 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201304051833.r35IXCFG031615@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 06 Apr, 2013

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

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

BGP routing table entries examined:                              449057
    Prefixes after maximum aggregation:                          184025
    Deaggregation factor:                                          2.44
    Unique aggregates announced to Internet:                     221630
Total ASes present in the Internet Routing Table:                 43748
    Prefixes per ASN:                                             10.26
Origin-only ASes present in the Internet Routing Table:           34414
Origin ASes announcing only one prefix:                           16061
Transit ASes present in the Internet Routing Table:                5792
Transit-only ASes present in the Internet Routing Table:            139
Average AS path length visible in the Internet Routing Table:       4.7
    Max AS path length visible:                                      29
    Max AS path prepend of ASN ( 28730)                              25
Prefixes from unregistered ASNs in the Routing Table:               368
    Unregistered ASNs in the Routing Table:                         137
Number of 32-bit ASNs allocated by the RIRs:                       4688
Number of 32-bit ASNs visible in the Routing Table:                3542
Prefixes from 32-bit ASNs in the Routing Table:                   10367
Special use prefixes present in the Routing Table:                   18
Prefixes being announced from unallocated address space:            217
Number of addresses announced to Internet:                   2628059756
    Equivalent to 156 /8s, 165 /16s and 2 /24s
    Percentage of available address space announced:               71.0
    Percentage of allocated address space announced:               71.0
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               94.4
Total number of prefixes smaller than registry allocations:      158789

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

Prefixes being announced by APNIC Region ASes:                   107913
    Total APNIC prefixes after maximum aggregation:               33314
    APNIC Deaggregation factor:                                    3.24
Prefixes being announced from the APNIC address blocks:          109122
    Unique aggregates announced from the APNIC address blocks:    44393
APNIC Region origin ASes present in the Internet Routing Table:    4823
    APNIC Prefixes per ASN:                                       22.63
APNIC Region origin ASes announcing only one prefix:               1227
APNIC Region transit ASes present in the Internet Routing Table:    819
Average APNIC Region AS path length visible:                        4.8
    Max APNIC Region AS path length visible:                         23
Number of APNIC region 32-bit ASNs visible in the Routing Table:    486
Number of APNIC addresses announced to Internet:              720399840
    Equivalent to 42 /8s, 240 /16s and 109 /24s
    Percentage of available APNIC address space announced:         84.2

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 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:                    157436
    Total ARIN prefixes after maximum aggregation:                79453
    ARIN Deaggregation factor:                                     1.98
Prefixes being announced from the ARIN address blocks:           158125
    Unique aggregates announced from the ARIN address blocks:     72365
ARIN Region origin ASes present in the Internet Routing Table:    15598
    ARIN Prefixes per ASN:                                        10.14
ARIN Region origin ASes announcing only one prefix:                5935
ARIN Region transit ASes present in the Internet Routing Table:    1611
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:      18
Number of ARIN addresses announced to Internet:              1078792832
    Equivalent to 64 /8s, 77 /16s and 18 /24s
    Percentage of available ARIN address space announced:          57.1

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 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:                    115684
    Total RIPE prefixes after maximum aggregation:                59313
    RIPE Deaggregation factor:                                     1.95
Prefixes being announced from the RIPE address blocks:           119410
    Unique aggregates announced from the RIPE address blocks:     76882
RIPE Region origin ASes present in the Internet Routing Table:    17117
    RIPE Prefixes per ASN:                                         6.98
RIPE Region origin ASes announcing only one prefix:                8148
RIPE Region transit ASes present in the Internet Routing Table:    2801
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                          29
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2276
Number of RIPE addresses announced to Internet:               656040676
    Equivalent to 39 /8s, 26 /16s and 98 /24s
    Percentage of available RIPE address space announced:          95.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 196608-199679
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:                   47491
    Total LACNIC prefixes after maximum aggregation:               9422
    LACNIC Deaggregation factor:                                   5.04
Prefixes being announced from the LACNIC address blocks:          51537
    Unique aggregates announced from the LACNIC address blocks:   23997
LACNIC Region origin ASes present in the Internet Routing Table:   1889
    LACNIC Prefixes per ASN:                                      27.28
LACNIC Region origin ASes announcing only one prefix:               564
LACNIC Region transit ASes present in the Internet Routing Table:   349
Average LACNIC Region AS path length visible:                       4.9
    Max LACNIC Region AS path length visible:                        29
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   755
Number of LACNIC addresses announced to Internet:             126168872
    Equivalent to 7 /8s, 133 /16s and 47 /24s
    Percentage of available LACNIC address space announced:        75.2

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

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

Prefixes being announced by AfriNIC Region ASes:                  10033
    Total AfriNIC prefixes after maximum aggregation:              2474
    AfriNIC Deaggregation factor:                                  4.06
Prefixes being announced from the AfriNIC address blocks:         10646
    Unique aggregates announced from the AfriNIC address blocks:   3791
AfriNIC Region origin ASes present in the Internet Routing Table:   611
    AfriNIC Prefixes per ASN:                                     17.42
AfriNIC Region origin ASes announcing only one prefix:              187
AfriNIC Region transit ASes present in the Internet Routing Table:  127
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    7
Number of AfriNIC addresses announced to Internet:             46211584
    Equivalent to 2 /8s, 193 /16s and 34 /24s
    Percentage of available AfriNIC address space announced:       45.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
 4766     2955      11558         923   Korea Telecom (KIX)
17974     2510        840          86   PT TELEKOMUNIKASI INDONESIA
 7545     1862        302          94   TPG Internet Pty Ltd
 4755     1732        392         198   TATA Communications formerly 
 9829     1500       1205          40   BSNL National Internet Backbo
 9583     1278         97         535   Sify Limited
 4808     1122       2109         326   CNCGROUP IP network: China169
 7552     1121       1063          21   Vietel Corporation
 9498     1065        310          73   BHARTI Airtel Ltd.
24560     1060        385         164   Bharti Airtel Ltd., Telemedia

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3038       3694          88   bellsouth.net, inc. 
 7029     2151       1266         213   Windstream Communications Inc
18566     2068        382         184   Covad Communications 
22773     2008       2929         125   Cox Communications, Inc.
 1785     1973        677         123   PaeTec Communications, Inc.
20115     1668       1610         610   Charter Communications 
 4323     1607       1139         397   Time Warner Telecom
30036     1338        296         657   Mediacom Communications Corp 
 7018     1312      10805         853   AT&T WorldNet Services
11492     1216        223         331   Cable One 

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1830        544          16   Corbina telecom
34984     1131        234         207   BILISIM TELEKOM
 2118     1116         97          13   EUnet/RELCOM Autonomous Syste
12479      844        786          66   Uni2 Autonomous System
13188      837         99          33   Educational Network
20940      813        283         646   Akamai Technologies European 
31148      790         41          20   FreeNet ISP
 8551      745        370          43   Bezeq International
 6830      734       2314         435   UPC Distribution Services
58113      666         74         386   LIR DATACENTER TELECOM SRL

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
28573     2561       1418          94   NET Servicos de Comunicao S.A
10620     2355        408         227   TVCABLE BOGOTA 
 7303     1673       1152         210   Telecom Argentina Stet-France
 8151     1222       2666         400   UniNet S.A. de C.V. 
 6503     1184        435          68   AVANTEL, S.A. 
14754      951        131          89   Telgua S. A. 
18881      850        716          18   Global Village Telecom 
27947      802         87          95   Telconet S.A
11830      725        364          14   Instituto Costarricense de El
 3816      693        306          85   Empresa Nacional de Telecomun

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
36998     1137         80           4   MOBITEL
24863      671        274          33   LINKdotNET AS number
 6713      541        617          25   Itissalat Al-MAGHRIB
 8452      356        958          13   TEDATA
24835      275         80           8   RAYA Telecom - Egypt
 3741      262        906         220   The Internet Solution 
12258      193         28          67   Vodacom Internet Company 
29975      191        667          21   Vodacom
16637      187        698          88   MTN Network Solutions
33776      178         12          18   Starcomms Nigeria Limited

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

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3038       3694          88   bellsouth.net, inc. 
 4766     2955      11558         923   Korea Telecom (KIX)
28573     2561       1418          94   NET Servicos de Comunicao S.A
17974     2510        840          86   PT TELEKOMUNIKASI INDONESIA
10620     2355        408         227   TVCABLE BOGOTA 
 7029     2151       1266         213   Windstream Communications Inc
18566     2068        382         184   Covad Communications 
22773     2008       2929         125   Cox Communications, Inc.
 1785     1973        677         123   PaeTec Communications, Inc.
 7545     1862        302          94   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
28573      2561        2467      NET Servicos de Comunicao S.A
17974      2510        2424      PT TELEKOMUNIKASI INDONESIA
10620      2355        2128      TVCABLE BOGOTA 
 4766      2955        2032      Korea Telecom (KIX)
 7029      2151        1938      Windstream Communications Inc
18566      2068        1884      Covad Communications 
22773      2008        1883      Cox Communications, Inc.
 1785      1973        1850      PaeTec Communications, Inc.
 8402      1830        1814      Corbina telecom
 7545      1862        1768      TPG Internet Pty Ltd

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

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

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
30031   UNALLOCATED  12.27.122.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24         209       Qwest 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic
33649   UNALLOCATED  12.111.112.0/24      19029       New Edge Networks 
26064   UNALLOCATED  12.149.37.0/24        7018       AT&T WorldNet Servic

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

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

Prefix             Origin AS  Description
128.0.0.0/24          2876     Jump Management SRL
128.0.16.0/21        43568     RIPE Network Coordination Cen
128.0.24.0/21        41794     Altline LLC
128.0.55.0/24        48571     SC efectRO SRL
128.0.58.0/23         9050     RTD-ROMTELECOM Autonomous Sys
128.0.72.0/21        23456     32-bit ASN transition
128.0.80.0/20        52041     Timer LTD
128.0.96.0/21        12886     LEWTelNet GmbH
128.0.104.0/23       51848     FOP Gabidullina Ludmila Nikol
128.0.106.0/24       23456     32-bit ASN transition

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

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

Network            Origin AS  Description
41.222.80.0/21       37110     Moztel LDA
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 
64.185.224.0/24      27431     JTL Networks Inc.
64.185.225.0/24      27431     JTL Networks Inc.
64.185.226.0/24      27431     JTL Networks Inc.
64.185.227.0/24      27431     JTL Networks Inc.
64.185.228.0/24      27431     JTL Networks Inc.
64.185.229.0/24      27431     JTL Networks Inc.
64.185.230.0/24      27431     JTL Networks 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:17       /9:13      /10:29      /11:88      /12:248     
/13:485     /14:875     /15:1557    /16:12685   /17:6615    /18:10898   
/19:21781   /20:31876   /21:33682   /22:46513   /23:41693   /24:235817  
/25:1398    /26:1781    /27:862     /28:43      /29:64      /30:18      
/31:0       /32:19      

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

  ASN   No of nets  Total ann.   Description
18566     2019          2068      Covad Communications 
 6389     1742          3038      bellsouth.net, inc. 
 7029     1597          2151      Windstream Communications Inc
 8402     1527          1830      Corbina telecom
22773     1314          2008      Cox Communications, Inc.
30036     1215          1338      Mediacom Communications Corp 
11492     1178          1216      Cable One 
36998     1131          1137      MOBITEL
 1785     1045          1973      PaeTec Communications, Inc.
 6983      929          1043      ITC^Deltacom 

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

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

   1:752       2:786       3:3         4:13        5:841       6:4      
   8:519      12:1918     13:3        14:770      15:11       16:3      
  17:9        20:19       23:255      24:1773     27:1433     31:1192   
  32:42       33:2        34:5        36:43       37:1675     38:862    
  39:2        40:164      41:2701     42:185      44:6        46:1786   
  47:2        49:616      50:676      52:12       54:29       55:8      
  57:27       58:1106     59:586      60:304      61:1445     62:992    
  63:2036     64:4289     65:2181     66:4282     67:2060     68:1117   
  69:3254     70:873      71:526      72:1890     74:2551     75:407    
  76:287      77:1088     78:1033     79:583      80:1247     81:978    
  82:609      83:581      84:569      85:1159     86:466      87:962    
  88:526      89:1789     90:281      91:5458     92:618      93:1707   
  94:1873     95:1536     96:502      97:340      98:1048     99:41     
 100:29      101:309     103:2375    105:488     106:126     107:207    
 108:514     109:1812    110:877     111:1045    112:491     113:768    
 114:688     115:1019    116:875     117:795     118:1015    119:1268   
 120:382     121:815     122:1740    123:1187    124:1331    125:1314   
 128:634     129:224     130:331     131:655     132:339     133:148    
 134:258     135:62      136:221     137:246     138:343     139:184    
 140:200     141:314     142:544     143:365     144:481     145:93     
 146:509     147:380     148:697     149:365     150:162     151:554    
 152:415     153:194     154:43      155:382     156:260     157:392    
 158:270     159:713     160:334     161:424     162:373     163:202    
 164:574     165:452     166:331     167:578     168:1018    169:133    
 170:1021    171:174     172:4       173:1591    174:579     175:442    
 176:1140    177:1887    178:2027    179:2       180:1383    181:304    
 182:1123    183:379     184:661     185:335     186:2381    187:1258   
 188:1986    189:1394    190:6646    192:6476    193:5659    194:4518   
 195:3465    196:1311    197:777     198:4313    199:5269    200:6024   
 201:2367    202:8854    203:8790    204:4507    205:2549    206:2788   
 207:2825    208:4060    209:3547    210:2923    211:1566    212:2012   
 213:1942    214:925     215:94      216:5186    217:1571    218:607    
 219:348     220:1271    221:544     222:319     223:499    

End of report


From cidr-report at potaroo.net  Fri Apr  5 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 5 Apr 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201304052200.r35M00NK083754@wattle.apnic.net>

This report has been generated at Fri Apr  5 21:13:17 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        29-03-13    449781      257239
        30-03-13    449770      257289
        31-03-13    449591      257894
        01-04-13    450130      258509
        02-04-13    450695      258668
        03-04-13    450581      258807
        04-04-13    450741      259286
        05-04-13    451091      259553


AS Summary
         43856  Number of ASes in routing system
         18179  Number of ASes announcing only one prefix
          3038  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      116943584  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

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

Table     451468   259555   191913    42.5%   All ASes

AS6389      3038       92     2946    97.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2955      939     2016    68.2%   KIXS-AS-KR Korea Telecom
AS17974     2510      547     1963    78.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS22773     2008      154     1854    92.3%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS28573     2566      727     1839    71.7%   NET Servi?os de Comunica??o
                                               S.A.
AS18566     2068      473     1595    77.1%   COVAD - Covad Communications
                                               Co.
AS7303      1673      447     1226    73.3%   Telecom Argentina S.A.
AS4323      1610      401     1209    75.1%   TWTC - tw telecom holdings,
                                               inc.
AS10620     2356     1243     1113    47.2%   Telmex Colombia S.A.
AS4755      1732      633     1099    63.5%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS2118      1116       83     1033    92.6%   RELCOM-AS OOO "NPO Relcom"
AS7552      1138      172      966    84.9%   VIETEL-AS-AP Vietel
                                               Corporation
AS7029      2139     1221      918    42.9%   WINDSTREAM - Windstream
                                               Communications Inc
AS18881      850       20      830    97.6%   Global Village Telecom
AS18101     1001      172      829    82.8%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS14754      952      146      806    84.7%   Telgua
AS1785      1973     1200      773    39.2%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4808      1122      362      760    67.7%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS36998     1137      382      755    66.4%   SDN-MOBITEL
AS13977      835      125      710    85.0%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS855        724       50      674    93.1%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS8151      1227      574      653    53.2%   Uninet S.A. de C.V.
AS22561     1082      452      630    58.2%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      733      108      625    85.3%   GIGAINFRA Softbank BB Corp.
AS24560     1060      446      614    57.9%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS3549      1054      444      610    57.9%   GBLX Global Crossing Ltd.
AS17908      793      198      595    75.0%   TCISL Tata Communications
AS3356      1088      495      593    54.5%   LEVEL3 Level 3 Communications
AS19262      990      403      587    59.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS11830      725      147      578    79.7%   Instituto Costarricense de
                                               Electricidad y Telecom.

Total      44255    12856    31399    71.0%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.80.0/21       AS37110 moztel-as
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.187.208.0/24      AS174   COGENT Cogent/PSI
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.165.92.0/24       AS20077 IPNETZONE-ASN - IPNetZone
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS30097 NUWAVE - NuWave
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        81.22.64.0/20        AS5511  OPENTRANSIT France Telecom S.A.
        82.101.160.0/19      AS5511  OPENTRANSIT France Telecom S.A.
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        185.22.248.0/22      AS8678  ANKARA-NET Ankara Universitesi Rektorlugu
        185.23.20.0/22       AS31229 PL-BEYOND-AS E24 sp. z o.o.
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.52.192.0/24      AS27919 
        190.52.193.0/24      AS27919 
        190.52.194.0/24      AS27919 
        190.52.195.0/24      AS27919 
        190.52.196.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.197.0/24      AS27919 
        190.52.198.0/24      AS27919 
        190.52.199.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.200.0/24      AS27947 Telconet S.A
        190.52.201.0/24      AS27947 Telconet S.A
        190.52.202.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.203.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.205.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.206.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.207.0/24      AS3549  GBLX Global Crossing Ltd.
        190.111.96.0/20      AS27589 MOJOHOST - MOJOHOST
        190.111.128.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.144.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.160.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.176.0/20     AS27589 MOJOHOST - MOJOHOST
        190.115.64.0/20      AS27589 MOJOHOST - MOJOHOST
        190.115.80.0/20      AS27589 MOJOHOST - MOJOHOST
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.53.0.0/19        AS13878 UOL DIVEO S.A.
        200.58.248.0/21      AS27849 
        200.107.248.0/24     AS27919 
        200.107.249.0/24     AS27919 
        200.107.250.0/24     AS27919 
        200.107.251.0/24     AS27919 
        200.107.252.0/24     AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
        201.71.16.0/20       AS28638 
        201.77.96.0/20       AS28639 
        201.222.32.0/20      AS27821 
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.58.113.0/24      AS19161 
        202.65.96.0/20       AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.73.240.0/20      AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.10.112.0/21      AS27027 ANBELL ASN-ANBELL
        204.11.112.0/22      AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.91.72.0/24       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        213.150.204.0/24     AS29338 AFOL-AS Used by Africaonline Operations
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Apr  5 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 5 Apr 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201304052200.r35M02Zi083768@wattle.apnic.net>

BGP Update Report
Interval: 28-Mar-13 -to- 04-Apr-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            50576  2.7%      41.6 -- BSNL-NIB National Internet Backbone
 2 - AS8402            46715  2.5%      38.5 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS10091           28716  1.5%      80.7 -- SCV-AS-AP StarHub Cable Vision Ltd
 4 - AS14754           27759  1.5%      31.8 -- Telgua
 5 - AS17974           23145  1.2%      23.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 6 - AS3909            22559  1.2%    7519.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC
 7 - AS28573           19947  1.1%       7.6 -- NET Servi?os de Comunica??o S.A.
 8 - AS45271           18144  1.0%      58.5 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road
 9 - AS7552            17599  0.9%      17.5 -- VIETEL-AS-AP Vietel Corporation
10 - AS8452            16646  0.9%      13.8 -- TE-AS TE-AS
11 - AS10620           15720  0.8%       7.6 -- Telmex Colombia S.A.
12 - AS27947           15712  0.8%      19.8 -- Telconet S.A
13 - AS2708            15405  0.8%     107.7 -- Universidad de Guanajuato
14 - AS21826           14902  0.8%      53.6 -- Corporaci?n Telemic C.A.
15 - AS2697            14053  0.7%      72.1 -- ERX-ERNET-AS Education and Research Network
16 - AS6713            13660  0.7%      29.1 -- IAM-AS
17 - AS7029            13582  0.7%       7.4 -- WINDSTREAM - Windstream Communications Inc
18 - AS33776           13408  0.7%      72.9 -- STARCOMMS-ASN
19 - AS4538            12308  0.7%      23.4 -- ERX-CERNET-BKB China Education and Research Network Center
20 - AS55430           12008  0.6%      80.6 -- STARHUBINTERNET-AS-NGNBN Starhub Internet Pte Ltd


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6629             7685  0.4%    7685.0 -- NOAA-AS - NOAA
 2 - AS3909            22559  1.2%    7519.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC
 3 - AS19406            4122  0.2%    4122.0 -- TWRS-MA - Towerstream I, Inc.
 4 - AS37367            3717  0.2%    3717.0 -- CALLKEY
 5 - AS6174             5722  0.3%    2861.0 -- SPRINTLINK8 - Sprint
 6 - AS5074             4504  0.2%    2252.0 -- ASN-ATTELS - AT&T BMGS
 7 - AS14680            6505  0.3%    2168.3 -- REALE-6 - Auction.com
 8 - AS13897            4196  0.2%    2098.0 -- CDC1 - Internet Brands Inc.
 9 - AS4467             2047  0.1%    2047.0 -- EASYLINK3 - AT&T Services, Inc.
10 - AS17293            5379  0.3%    1793.0 -- VTXC - VTX Communications
11 - AS9950             3351  0.2%    1675.5 -- PUBNETPLUS2-AS-KR DACOM
12 - AS36529            2492  0.1%    1246.0 -- AXXA-RACKCO - Rackco.com
13 - AS41023            3397  0.2%    1132.3 -- ARREKS-AS Agencja Rozwoju Regionalnego ARREKS S.A.
14 - AS19886            2263  0.1%    1131.5 -- BOFABROKERDEALERSVCS - Bank of America
15 - AS46105             783  0.0%     783.0 -- HMLP-ASN - HealthCor Management, L.P.
16 - AS10445            3742  0.2%     748.4 -- HTG - Huntleigh Telcom
17 - AS32955            5852  0.3%     731.5 -- MURCOM - MURCOM, LLC
18 - AS52358             673  0.0%     673.0 -- Y&V Ingenier?a y Construcci?n, C.A.
19 - AS57013            3972  0.2%     662.0 -- EURASIA-STAR-AS Eurasia Star Ltd.
20 - AS22688             645  0.0%     645.0 -- DOLGENCORP - Dollar General Corporation


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.41.70.0/24    10026  0.5%   AS2697  -- ERX-ERNET-AS Education and Research Network
 2 - 112.110.82.0/23    7688  0.4%   AS45271 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road
 3 - 112.110.84.0/22    7686  0.4%   AS45271 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road
 4 - 192.58.232.0/24    7685  0.4%   AS6629  -- NOAA-AS - NOAA
 5 - 151.118.18.0/24    7543  0.4%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 6 - 151.118.255.0/24   7508  0.4%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 7 - 151.118.254.0/24   7508  0.4%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 8 - 12.139.133.0/24    5379  0.3%   AS14680 -- REALE-6 - Auction.com
 9 - 194.63.9.0/24      4217  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
10 - 216.183.32.0/19    4146  0.2%   AS17293 -- VTXC - VTX Communications
11 - 69.38.178.0/24     4122  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
12 - 41.75.40.0/21      3717  0.2%   AS37367 -- CALLKEY
13 - 58.184.229.0/24    3347  0.2%   AS9950  -- PUBNETPLUS2-AS-KR DACOM
14 - 206.105.75.0/24    2861  0.1%   AS6174  -- SPRINTLINK8 - Sprint
15 - 208.16.110.0/24    2861  0.1%   AS6174  -- SPRINTLINK8 - Sprint
16 - 115.170.128.0/17   2762  0.1%   AS4847  -- CNIX-AP China Networks Inter-Exchange
17 - 2.93.235.0/24      2636  0.1%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"
18 - 12.79.224.0/19     2325  0.1%   AS5074  -- ASN-ATTELS - AT&T BMGS
19 - 205.65.128.0/22    2318  0.1%   AS647   -- DNIC-ASBLK-00616-00665 - DoD Network Information Center
20 - 84.205.66.0/24     2314  0.1%   AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC)

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From randy at psg.com  Fri Apr  5 23:10:19 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 06 Apr 2013 08:10:19 +0900
Subject: public consultation on root zone KSK rollover
In-Reply-To: <97EF19E7-AB4B-4472-9F1D-3FE3BA176A0E@virtualized.org>
References: <201304040935.KAA15823@sunf10.rd.bbc.co.uk>
 <97EF19E7-AB4B-4472-9F1D-3FE3BA176A0E@virtualized.org>
Message-ID: <m2k3ogbmlg.wl%randy@psg.com>

< rant >

> The point of the wildly over-engineered root key signing ceremony is
> to build trust by publicly demonstrating at every step there is no
> opportunity for intentional or accidental badness to occur without
> being noticed.

at some point, long passed, the more pomp, the less safe i feel.  there
is protecting against technical/engineering threats and protecting
against layer 8 through 11.  through complexity, it compromises the
technical protection to go overboard on the lawyer defense.

from this bottom feeder's pov, icann, verisign, doc, ... are too often
the layer 8 through 11 threat than part of the engineering solution.

> In any event, if you haven't already I would encourage you to provide
> comments at the URL Joe referenced.

definitely.  after all, commenting on icann insanities has had such
serious beneficial effect for the good of the internet in the past.

randy


From drc at virtualized.org  Sat Apr  6 00:52:06 2013
From: drc at virtualized.org (David Conrad)
Date: Sat, 6 Apr 2013 08:52:06 +0800
Subject: public consultation on root zone KSK rollover
In-Reply-To: <m2k3ogbmlg.wl%randy@psg.com>
References: <201304040935.KAA15823@sunf10.rd.bbc.co.uk>
 <97EF19E7-AB4B-4472-9F1D-3FE3BA176A0E@virtualized.org>
 <m2k3ogbmlg.wl%randy@psg.com>
Message-ID: <D555AF40-0C36-431F-B6F9-0889324CA5BF@virtualized.org>

Randy,

On Apr 6, 2013, at 7:10 AM, Randy Bush <randy at psg.com> wrote:
> at some point, long passed, the more pomp, the less safe i feel.  

Have you actually watched/participated in a root key signing ceremony?  Pomp is not the term I would use. 

> there
> is protecting against technical/engineering threats and protecting
> against layer 8 through 11.  through complexity, it compromises the
> technical protection to go overboard on the lawyer defense.

Technical protection like those that protected Diginotar's customers?  The elaborate root key signing ceremony is designed to ensure all aspects of root key management are open, transparent, and can be audited by anyone. While I'd agree that it is non-technical, the technical/engineering part is the easy bit. Protecting against insiders, laziness, and stupidity is _far_ harder.

>> In any event, if you haven't already I would encourage you to provide
>> comments at the URL Joe referenced.
> 
> definitely.  after all, commenting on icann insanities has had such
> serious beneficial effect for the good of the internet in the past.

I can guarantee that providing comments are infinitely more likely to have an impact than stomping off in a huff :)

Regards,
-drc



From mureninc at gmail.com  Sat Apr  6 01:32:54 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Fri, 5 Apr 2013 18:32:54 -0700
Subject: 30% packet loss between cox.net and hetzner.de, possibly at tinet.net
Message-ID: <20130406013254.GA24063@lxr.su>

Hello,

There has been at least a 25% packet loss between hetzner.de and cox.net 
in the last couple of hours.

Tried contacting hetzner.de, but they said it's not on their network.  
This has already happened a couple of days ago, too (strangely, on April 1), 
but then was good for the rest of the week -- no problems whatsoever.

I wouldn't really care about this, if not for ssh:  
it just doesn't work on such huge loss.

No other routes or networks seem affected.

Any advice?


# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" ip68-97-XX-XXX.ok.ok.cox.net ; date
HOST: xxxxxxxxxx                                  Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  1.|-- static.33.203.4.46.clients.your-server.de    60    60  0.0%    0.5   1.1   1.5   3.8   1.1
  2.|-- hos-tr3.juniper2.rz13.hetzner.de             60    60  0.0%    0.2   0.4   3.4  46.2   9.8
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   3.0   3.6  38.1   4.8
  4.|-- r1nue1.core.init7.net                        60    60  0.0%    2.8   4.9   6.0  13.3   3.9
  5.|-- r1nue2.core.init7.net                        60    60  0.0%    2.9   3.9   4.6  13.8   3.1
  6.|-- r1fra2.core.init7.net                        60    60  0.0%    5.7   7.6   8.2  17.3   3.8
  7.|-- r1fra1.core.init7.net                        60    60  0.0%    5.9   8.2   8.9  17.1   3.9
  8.|-- xe-4-2-2.fra23.ip4.tinet.net                 60    60  0.0%    5.9   6.4   7.1  38.2   5.2
  9.|-- xe-3-0-0.dal33.ip4.tinet.net                 60    39 35.0%  165.8 169.7 170.1 226.3  13.1
 10.|-- cox-communications-gw.ip4.tinet.net          60    47 21.7%  159.0 162.3 162.6 207.9  10.4
 11.|-- mtc3dsrj01-ae1.0.rd.ok.cox.net               60    46 23.3%  163.1 166.1 166.3 196.3   8.0
 12.|-- 68.12.14.1                                   60    49 18.3%  161.3 161.6 161.6 161.9   0.1
 13.|-- COX-68-12-10-114-static.coxinet.net          60    40 33.3%  162.5 162.8 162.8 163.1   0.1
 14.|-- COX-68-12-10-114-static.coxinet.net          60    44 26.7%  162.5 162.8 162.8 163.2   0.1
 15.|-- ip68-97-XX-XXX.ok.ok.cox.net                 60    43 28.3%  170.9 173.5 173.5 179.5   1.5
Fri Apr  5 16:21:56 PDT 2013

% mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" static.88-198-xx-xx.clients.your-server.de ; date
HOST: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx           Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  1.|-- 192.168.xxxx                                  60    60  0.0%    1.0   1.9   2.5  14.0   2.5
  2.|-- 10.0.x.x                                      60    60  0.0%    1.3   2.3   2.6   7.6   1.6
  3.|-- 10.6.0.1                                      60    60  0.0%    8.9  13.7  14.3  38.6   5.1
  4.|-- COX-68-12-10-113-static.coxinet.net           60    60  0.0%    9.6  14.1  15.6  97.2  11.9
  5.|-- COX-68-12-10-2-static.coxinet.net             60    60  0.0%   10.1  14.9  15.4  31.2   4.3
  6.|-- 68.1.5.161                                    60    60  0.0%   55.8  61.8  62.1  93.1   6.6
  7.|-- nyk-s2-rou-1001.US.eurorings.net              60    60  0.0%   55.7  63.6  64.8 162.4  16.7
  8.|-- nntr-s1-rou-1101.FR.eurorings.net             60    60  0.0%  149.5 168.7 169.7 213.1  19.3
  9.|-- kehl-s2-rou-1103.DE.eurorings.net             60    47 21.7%  147.2 151.6 151.6 161.6   3.3
 10.|-- ffm-s1-rou-1102.DE.eurorings.net              60    60  0.0%  144.1 148.9 149.1 174.2   6.4
 11.|-- nbg-s1-rou-1001.DE.eurorings.net              60    60  0.0%  147.1 156.2 157.3 290.9  22.4
 12.|-- kpn-gw.hetzner.de                             60    48 20.0%  173.8 178.9 179.0 198.2   5.1
 13.|-- hos-bb2.juniper2.rz13.hetzner.de              60    43 28.3%  173.4 179.6 179.9 230.1  11.8
 14.|-- hos-tr4.ex3k11.rz13.hetzner.de                60    48 20.0%  176.9 181.9 181.9 198.9   4.4
 15.|-- static.88-198-xx-xx.clients.your-server.de    60    37 38.3%  173.2 177.0 177.0 186.6   3.4
Fri  5 Apr 2013 16:22:51 PDT



The huge packet loss even extends to the regular cox.net web-site, it seems:

# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" cox.net ; date
HOST: xxxxxxxxxx                                  Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  1.|-- static.33.203.4.46.clients.your-server.de    60    60  0.0%    0.5   1.2   1.7   5.6   1.4
  2.|-- hos-tr1.juniper1.rz13.hetzner.de             60    60  0.0%    0.2   0.3   2.1  29.3   6.0
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   3.5   5.8  62.5  10.1
  4.|-- r1nue1.core.init7.net                        60    60  0.0%    2.8   4.2   5.2  13.5   3.8
  5.|-- r1nue2.core.init7.net                        60    60  0.0%    2.9   4.7   6.0  28.7   5.0
  6.|-- r1fra2.core.init7.net                        60    60  0.0%    5.7   7.4   8.1  15.9   3.6
  7.|-- r1fra1.core.init7.net                        60    60  0.0%    5.9   7.6   8.1  16.8   3.2
  8.|-- xe-4-2-2.fra23.ip4.tinet.net                 60    60  0.0%    5.9   6.4   7.1  36.2   5.6
  9.|-- xe-9-0-0.was14.ip4.tinet.net                 60    43 28.3%  142.3 145.0 145.2 190.0   9.6
 10.|-- cox-communications-gw.ip4.tinet.net          60    48 20.0%  124.8 129.6 130.2 176.6  13.2
 11.|-- dukedsrj02-ge210.0.rd.at.cox.net             60    45 25.0%  137.7 141.2 141.6 194.7  11.6
 12.|-- 68.1.15.238                                  60    49 18.3%  138.1 138.7 138.7 140.0   0.4
 13.|-- 68.99.123.4                                  60    36 40.0%  140.4 140.9 140.9 141.6   0.3
 14.|-- ww2.cox.com                                  60    44 26.7%  140.6 140.9 140.9 141.8   0.3
Fri Apr  5 18:19:21 PDT 2013


Best regards,
Constantine.


From denys at visp.net.lb  Sat Apr  6 02:04:51 2013
From: denys at visp.net.lb (Denys Fedoryshchenko)
Date: Sat, 06 Apr 2013 05:04:51 +0300
Subject: 30% packet loss between cox.net and hetzner.de, possibly at
 tinet.net
In-Reply-To: <20130406013254.GA24063@lxr.su>
References: <20130406013254.GA24063@lxr.su>
Message-ID: <0a7591e6725fe9c7806207e3ac0e9f22@visp.net.lb>

On 2013-04-06 04:32, Constantine A. Murenin wrote:
> Hello,
> 
> There has been at least a 25% packet loss between hetzner.de and 
> cox.net
> in the last couple of hours.
> 
> Tried contacting hetzner.de, but they said it's not on their network.
> This has already happened a couple of days ago, too (strangely, on 
> April 1),
> but then was good for the rest of the week -- no problems whatsoever.
> 
> I wouldn't really care about this, if not for ssh:
> it just doesn't work on such huge loss.
> 
> No other routes or networks seem affected.
> 
> Any advice?
> 
Doesnt looks like tinet for me.
I have colo in Europe and it is connected over tinet and mtr to 
static.33.203.4.46.clients.your-server.de is clean
visp-probe ~ # mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" 
static.33.203.4.46.clients.your-server.de
HOST: visp-probe                                  Snt   Rcv Loss%   
Best Gmean   Avg  Wrst StDev
   1.|-- X.X.X.X                                      60    60  0.0%    
0.1   0.9   6.1  50.7  11.7
   2.|-- r1fra1.core.init7.net                        60    60  0.0%    
1.0   2.6   3.9  12.8   3.6
   3.|-- r1fra3.core.init7.net                        60    60  0.0%    
1.0   2.2   3.2  12.0   3.2
   4.|-- r1nue2.core.init7.net                        60    60  0.0%    
3.7   5.3   6.0  15.5   3.7
   5.|-- r1nue1.core.init7.net                        60    60  0.0%    
3.9   5.8   6.5  15.3   3.6
   6.|-- gw-hetzner.init7.net                         60    60  0.0%    
3.9   5.1   8.1  89.6  15.2
   7.|-- hos-bb2.juniper2.rz13.hetzner.de             60    60  0.0%    
6.1   7.7  10.4  74.9  14.8
   8.|-- static.33.203.4.46.clients.your-server.de    60    60  0.0%    
6.5   7.7   7.8  13.1   1.4



---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.


From frnkblk at iname.com  Sat Apr  6 02:44:54 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 5 Apr 2013 21:44:54 -0500
Subject: 80 km BiDi XFPs
In-Reply-To: <20130405171507.GP3010@angus.ind.WPI.EDU>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <515EE49D.8070508@tularosa.net> <515EE696.3010907@ploiesti.rdsnet.ro>
 <798926481.95954.1365179997836.JavaMail.root@network1.net>
 <515F02C9.8080401@tularosa.net> <20130405171507.GP3010@angus.ind.WPI.EDU>
Message-ID: <007301ce3270$b805d900$28118b00$@iname.com>

Thank you -- this is the first hit I've received.  Thanks for all the others
who offered help, but all the other pointers led to 40 km or 60 km products,
1G SFPs, or stand-alone passive muxes.

Frank

-----Original Message-----
From: Chuck Anderson [mailto:cra at WPI.EDU] 
Sent: Friday, April 05, 2013 12:15 PM
To: nanog at nanog.org
Subject: Re: 80 km BiDi XFPs

On Fri, Apr 05, 2013 at 10:58:49AM -0600, Jerimiah Cole wrote:
> On 04/05/2013 10:39 AM, Randy Carpenter wrote:
> > 
> > I'm going to guess that this is not going to meet the OP's request
> > for an XFP, which would be 10GbE (and not an SFP).
> 
> Probably a safe guess.  Mea culpa.

Check out Integra Networks.  Their catalog lists a 10G XFP Bi-Dir
80km:

http://integranetworks.net/wp-content/uploads/2012/06/Integra-Networks-Catal
og-20122.pdf

XFP-CXX-80-D (CWDM)
XFP-DXX-80-D (DWDM)





From frnkblk at iname.com  Sat Apr  6 03:25:10 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 5 Apr 2013 22:25:10 -0500
Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test
In-Reply-To: <515C9A24.8010809@tiedyenetworks.com>
References: <CD8099F0.8E687%carlos@race.com> <515BBA89.5080000@rollernet.us>
 <515C9A24.8010809@tiedyenetworks.com>
Message-ID: <008c01ce3276$585a5d90$090f18b0$@iname.com>

Here's a 39-page report that might differ with your perspective: http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurements.pdf

And another report: http://www.netforecast.com/Reports/NFR5103_comScore_ISP_Speed_Test_Accuracy.pdf

Frank

-----Original Message-----
From: Mike [mailto:mike-nanog at tiedyenetworks.com] 
Sent: Wednesday, April 03, 2013 4:08 PM
To: nanog at nanog.org
Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test

<snip>

These speedtests are pure unscientific bs and I'd love to see them 
called out on the carpet for it.

Mike-





From mureninc at gmail.com  Sat Apr  6 04:27:24 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Fri, 5 Apr 2013 21:27:24 -0700
Subject: 30% packet loss between cox.net and hetzner.de, possibly at
 tinet.net
In-Reply-To: <0a7591e6725fe9c7806207e3ac0e9f22@visp.net.lb>
References: <20130406013254.GA24063@lxr.su>
 <0a7591e6725fe9c7806207e3ac0e9f22@visp.net.lb>
Message-ID: <20130406042724.GA24109@lxr.su>

On 2013-W14-6 05:04 +0300, Denys Fedoryshchenko wrote:
> On 2013-04-06 04:32, Constantine A. Murenin wrote:
> >Hello,
> >
> >There has been at least a 25% packet loss between hetzner.de and
> >cox.net
> >in the last couple of hours.
> >
> >Tried contacting hetzner.de, but they said it's not on their network.
> >This has already happened a couple of days ago, too (strangely, on
> >April 1),
> >but then was good for the rest of the week -- no problems whatsoever.
> >
> >I wouldn't really care about this, if not for ssh:
> >it just doesn't work on such huge loss.
> >
> >No other routes or networks seem affected.
> >
> >Any advice?
> >
> Doesnt looks like tinet for me.

Might have been eurorings.net, as your Amazon EC2 to Hetzner 
traceroute seemed to suggest?


This loss was apparent even with their own main websites:


cox.net from a hetzner.de node:

# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" cox.net ; date
...
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   3.5   5.8  62.5  10.1
  4.|-- r1nue1.core.init7.net                        60    60  0.0%    2.8   4.2   5.2  13.5   3.8
  5.|-- r1nue2.core.init7.net                        60    60  0.0%    2.9   4.7   6.0  28.7   5.0
  6.|-- r1fra2.core.init7.net                        60    60  0.0%    5.7   7.4   8.1  15.9   3.6
  7.|-- r1fra1.core.init7.net                        60    60  0.0%    5.9   7.6   8.1  16.8   3.2
  8.|-- xe-4-2-2.fra23.ip4.tinet.net                 60    60  0.0%    5.9   6.4   7.1  36.2   5.6
  9.|-- xe-9-0-0.was14.ip4.tinet.net                 60    43 28.3%  142.3 145.0 145.2 190.0   9.6
 10.|-- cox-communications-gw.ip4.tinet.net          60    48 20.0%  124.8 129.6 130.2 176.6  13.2
 11.|-- dukedsrj02-ge210.0.rd.at.cox.net             60    45 25.0%  137.7 141.2 141.6 194.7  11.6
 12.|-- 68.1.15.238                                  60    49 18.3%  138.1 138.7 138.7 140.0   0.4
 13.|-- 68.99.123.4                                  60    36 40.0%  140.4 140.9 140.9 141.6   0.3
 14.|-- ww2.cox.com                                  60    44 26.7%  140.6 140.9 140.9 141.8   0.3
Fri Apr  5 18:19:21 PDT 2013


hetzner.de from a cox.net node:

...
  5.|-- COX-68-12-8-132-static.coxinet.net     60    60  0.0%   11.6  15.3  15.8  35.1   4.9
  6.|-- 68.1.5.161                             60    60  0.0%   55.7  59.8  60.0  95.8   5.3
  7.|-- nyk-s2-rou-1001.US.eurorings.net       60    60  0.0%   55.8  63.8  64.9 139.4  14.7
  8.|-- nntr-s1-rou-1101.FR.eurorings.net      60    60  0.0%  149.8 154.1 154.1 171.9   4.3
  9.|-- kehl-s2-rou-1103.DE.eurorings.net      60    60  0.0%  147.2 152.8 153.1 206.1   8.7
 10.|-- ffm-s1-rou-1102.DE.eurorings.net       60    60  0.0%  143.3 147.7 147.7 177.2   5.0
 11.|-- nbg-s1-rou-1001.DE.eurorings.net       60    60  0.0%  147.3 153.8 154.0 211.1  10.0
 12.|-- kpn-gw.hetzner.de                      60    44 26.7%  173.3 177.6 177.6 184.5   2.7
 13.|-- hos-bb2.juniper3.rz2.hetzner.de        60    42 30.0%  170.3 175.1 175.2 203.1   5.6
 14.|-- hos-tr4.ms-ex3k2.rz1.hetzner.de        60    44 26.7%  171.9 175.9 175.9 185.4   2.8
 15.|-- www.hetzner.de                         60    42 30.0%  170.4 175.1 175.2 187.0   4.1
Fri  5 Apr 2013 17:38:11 PDT

...
  5.|-- COX-68-12-8-132-static.coxinet.net     60    60  0.0%   11.3  14.2  14.5  33.6   3.3
  6.|-- 68.1.5.161                             60    60  0.0%   56.2  61.1  61.8 135.6  11.6
  7.|-- nyk-s2-rou-1001.US.eurorings.net       60    60  0.0%   56.0  60.6  61.0 121.1   8.7
  8.|-- nntr-s1-rou-1101.FR.eurorings.net      60    58  3.3%  150.1 153.5 153.5 166.3   2.8
  9.|-- kehl-s2-rou-1103.DE.eurorings.net      60    29 51.7%  147.5 152.0 152.1 170.8   5.3
 10.|-- ffm-s1-rou-1102.DE.eurorings.net       60    28 53.3%  143.7 148.4 148.6 186.7   8.0
 11.|-- nbg-s1-rou-1001.DE.eurorings.net       60    60  0.0%  147.2 151.8 151.9 178.2   4.7
 12.|-- kpn-gw.hetzner.de                      60    45 25.0%  172.7 177.0 177.0 197.4   4.0
 13.|-- hos-bb2.juniper3.rz2.hetzner.de        60    41 31.7%  170.4 176.5 176.6 190.9   6.2
 14.|-- hos-tr4.ms-ex3k2.rz1.hetzner.de        60    50 16.7%  171.8 175.6 175.6 183.1   2.8
 15.|-- www.hetzner.de                         60    47 21.7%  170.5 174.2 174.3 188.8   3.2
Fri  5 Apr 2013 19:22:36 PDT



But it has since subsided:

...
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   2.9   3.4  41.4   5.0
  4.|-- r1nue1.core.init7.net                        60    60  0.0%    2.8   5.2   6.3  12.4   3.8
  5.|-- r1nue2.core.init7.net                        60    60  0.0%    2.9   4.0   4.7  14.0   3.2
  6.|-- r1fra2.core.init7.net                        60    60  0.0%    5.7   7.7   8.4  17.0   3.9
  7.|-- r1fra1.core.init7.net                        60    60  0.0%    5.9   8.7   9.3  17.1   3.7
  8.|-- xe-4-2-2.fra23.ip4.tinet.net                 60    60  0.0%    5.9   6.1   6.2  15.0   1.3
  9.|-- xe-9-0-0.was14.ip4.tinet.net                 60    60  0.0%   95.9  99.4  99.8 134.3   8.9
 10.|-- cox-communications-gw.ip4.tinet.net          60    60  0.0%  100.0 100.5 100.5 104.0   0.6
 11.|-- dukedsrj02-ge210.0.rd.at.cox.net             60    60  0.0%  113.2 116.7 117.1 163.6  10.9
 12.|-- 68.1.15.238                                  60    60  0.0%  113.4 113.8 113.8 116.0   0.4
 13.|-- 68.99.123.4                                  60    50 16.7%  115.6 115.9 115.9 116.6   0.2
 14.|-- ww2.cox.com                                  60    59  1.7%  115.7 116.1 116.1 117.2   0.3
Fri Apr  5 19:46:48 PDT 2013

...
  5.|-- COX-68-12-8-132-static.coxinet.net     60    60  0.0%   11.5  16.2  16.8  57.0   6.1
  6.|-- 68.1.5.161                             60    60  0.0%   56.3  61.5  61.8 105.1   6.5
  7.|-- nyk-s2-rou-1001.US.eurorings.net       60    60  0.0%   56.6  63.9  64.6 122.2  11.0
  8.|-- nntr-s1-rou-1101.FR.eurorings.net      60    60  0.0%  150.4 157.6 158.0 226.0  11.8
  9.|-- kehl-s2-rou-1103.DE.eurorings.net      60    60  0.0%  147.7 152.5 152.7 206.0   7.7
 10.|-- ffm-s1-rou-1102.DE.eurorings.net       60    60  0.0%  143.6 150.4 150.5 184.4   7.6
 11.|-- nbg-s1-rou-1001.DE.eurorings.net       60    60  0.0%  147.7 154.6 155.2 261.1  15.2
 12.|-- kpn-gw.hetzner.de                      60    60  0.0%  148.0 153.1 153.2 175.2   4.2
 13.|-- hos-bb2.juniper3.rz2.hetzner.de        60    60  0.0%  145.0 164.8 166.2 220.6  22.2
 14.|-- hos-tr4.ms-ex3k2.rz1.hetzner.de        60    59  1.7%  145.8 152.5 152.6 166.7   4.4
 15.|-- www.hetzner.de                         60    58  3.3%  144.5 149.7 149.7 161.3   3.9
Fri  5 Apr 2013 20:53:59 PDT


With the end-to-end working, too.


Cheers,
Constantine.


From sh.vahabzadeh at gmail.com  Sat Apr  6 05:36:14 2013
From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh)
Date: Sat, 6 Apr 2013 10:06:14 +0430
Subject: ICMP Redirect on Resolvers
Message-ID: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>

Hello everybody,
I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in
console messages like this:

icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254

and lots of messages like this, mostly ip addresses not belong to me, and
some times these resolvers stop working.
My question is what are these messages? why they only shown in console of
these servers not others? And are they cause the problems like stopping
working for server/services?
Thanks

-- 
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

Cell Phone: +1 (415) 871 0742
PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

From dot at dotat.at  Sat Apr  6 05:58:03 2013
From: dot at dotat.at (Tony Finch)
Date: Sat, 6 Apr 2013 06:58:03 +0100
Subject: ICMP Redirect on Resolvers
In-Reply-To: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
Message-ID: <3238AA0E-A7A3-4194-A62A-8F86AE028B2B@dotat.at>

On 6 Apr 2013, at 06:36, Shahab Vahabzadeh <sh.vahabzadeh at gmail.com> wrote:

> I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in
> console messages like this:
> 
> icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254

You probably configured the wrong default router address or netmask.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/


From kmedcalf at dessus.com  Sat Apr  6 06:20:48 2013
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 06 Apr 2013 00:20:48 -0600
Subject: ICMP Redirect on Resolvers
In-Reply-To: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
Message-ID: <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>


> icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254

The host attempted to send a packet to 192.168.179.80 via 192.168.140.36.  192.168.140.36 forwarded the packet to 192.168.140.254 according to its routing table, but is advising you (and the kernel has added to the routing table) that in the future you reach 192.148.179.80 via 192.168.140.254, not via 192.168.140.36.

---
()  ascii ribbon campaign against html e-mail
/\  www.asciiribbon.org


> -----Original Message-----
> From: Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com]
> Sent: Friday, 05 April, 2013 23:36
> To: nanog at nanog.org
> Subject: ICMP Redirect on Resolvers
> 
> Hello everybody,
> I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in
> console messages like this:
> 
> icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
> 
> and lots of messages like this, mostly ip addresses not belong to me, and
> some times these resolvers stop working.
> My question is what are these messages? why they only shown in console of
> these servers not others? And are they cause the problems like stopping
> working for server/services?
> Thanks
> 
> --
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
> 
> Cell Phone: +1 (415) 871 0742
> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90





From mysidia at gmail.com  Sat Apr  6 07:12:01 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 6 Apr 2013 02:12:01 -0500
Subject: ICMP Redirect on Resolvers
In-Reply-To: <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
Message-ID: <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>

On 4/6/13, Keith Medcalf <kmedcalf at dessus.com> wrote:
>

Although spoofed ICMP redirects mightalso  be abused to
intercept/quietly sniff traffic
on a switched LAN;
The default gateway responding with a redirect in that situation
 is the normal case where you expect to receive an ICMP redirect. ; in
that particular case ICMP redirect improves matters,  by  directing
clients to send their packets directly to that other router on that
LAN,  thus eliminating one router hop for future packets to that
destination IP address  (until the destination IP address' redirect
entry gets aged out in the sending host's route cache),
which is the whole point of ICMP redirects.

However...  routes  are better than redirects.

An ICMP redirect applies to only one IP address that is redirected, so
if you made heavy use of that functionality (eg Large LANs, with this)
-- many table entries could be spent on the redirects;  an actual
route on the host is much better than relying on ICMP redirects for
providing more deterministic behavior while still avoiding suboptimal
routing,   because only a small number of table entries are required
on the hosts (entry per network).

It's not an ideal situation, to have a large number of hosts reached
through an ICMP redirect;  in the ideal situation, you  design
networks so that you don't  route traffic across a LAN network to a
next hop IP address that also contains end hosts,  instead, give
routers dedicated 'links' or 'LANs', where the other endpoints are
routers only  (and route to next hops on those networks, instead of
end-host LANs), or else: at least populate the routing tables of end
hosts on  any LAN you route through (using static routes, or a routing
protocol on the servers),  so that you aren't carrying around ICMP
redirects.

Failing all that, if the LANs are large, and a large number of ICMP
redirects would occur,  it may be preferrable to turn ICMP redirects
off for those LANs on their routers




>> icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
>
> The host attempted to send a packet to 192.168.179.80 via 192.168.140.36.
> 192.168.140.36 forwarded the packet to 192.168.140.254 according to its
> routing table, but is advising you (and the kernel has added to the routing
> table) that in the future you reach 192.148.179.80 via 192.168.140.254, not
> via 192.168.140.36.


--
-JH


From Thomas.Weible at flexoptix.net  Sat Apr  6 10:50:58 2013
From: Thomas.Weible at flexoptix.net (Thomas Weible - FLEXOPTIX)
Date: Sat, 6 Apr 2013 10:50:58 +0000
Subject: AW: 80 km BiDi XFPs
In-Reply-To: <7774244507336980754@unknownmsgid>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <7774244507336980754@unknownmsgid>
Message-ID: <3C73F7533E17CE4BA3558C3026772EC83FC93F95@postman.intranet.flexoptix.net>

Matt Addison [mailto:matt.addison at lists.evilgeni.us] wrote:
> 
> How much spare margin do you have? Could you roll your own with a pair
> of mismatched (C|D)WDM XFPs and a mux on each end?
Typically you have 23dB powerbudget for the ZR (CWDM or DWDM) - maybe +2 dB through selection of TOSA. A CWDM Mux will take 2dB and a small DWDM Mux approx. 4dB  - you need two of them. This will drag your overall link-powerbudget below 20dB.

It might work if you add a FEC (either on the linecard or the XFP itself). This will add approx. 5dB to your powerbudget of 23dB. Take a CWDM Mux and fire x-crossed on 1550 and 1570 (maybe 1530) and you will face an attenuation of approx. 0,2 - 0,25dB/km. This could work and you should be able to transmit 80km to 90km. It's worth a test - also to figure out if dispersion will have an impact or not.

Thomas
> On Apr 2, 2013, at 19:16, Frank Bulk <frnkblk at iname.com> wrote:
> 
> > Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
> > supplier of generics doesn't have an option for us, but I would really like
> > to avoid leasing additional fibers.
> >
> > Frank
> >
> >
> 
> 



From nanog at studio442.com.au  Sat Apr  6 11:14:03 2013
From: nanog at studio442.com.au (Julien Goodwin)
Date: Sat, 06 Apr 2013 22:14:03 +1100
Subject: AW: 80 km BiDi XFPs
In-Reply-To: <3C73F7533E17CE4BA3558C3026772EC83FC93F95@postman.intranet.flexoptix.net>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <7774244507336980754@unknownmsgid>
 <3C73F7533E17CE4BA3558C3026772EC83FC93F95@postman.intranet.flexoptix.net>
Message-ID: <5160037B.5090604@studio442.com.au>

On 06/04/13 21:50, Thomas Weible - FLEXOPTIX wrote:
> Matt Addison [mailto:matt.addison at lists.evilgeni.us] wrote:
>>
>> How much spare margin do you have? Could you roll your own with a pair
>> of mismatched (C|D)WDM XFPs and a mux on each end?
> Typically you have 23dB powerbudget for the ZR (CWDM or DWDM) - maybe +2 dB through selection of TOSA. A CWDM Mux will take 2dB and a small DWDM Mux approx. 4dB  - you need two of them. This will drag your overall link-powerbudget below 20dB.
> 
> It might work if you add a FEC (either on the linecard or the XFP itself). This will add approx. 5dB to your powerbudget of 23dB. Take a CWDM Mux and fire x-crossed on 1550 and 1570 (maybe 1530) and you will face an attenuation of approx. 0,2 - 0,25dB/km. This could work and you should be able to transmit 80km to 90km. It's worth a test - also to figure out if dispersion will have an impact or not.

If you're going to that effort buy a mux with an amp, and use short-haul
SFP's with FEC.

A choice I found particularly neat (I got a hold of some of their HW
architecture docs but haven't actually tried it) is the SmartOptics
"m:series", an 4/8/16/32ch PTP metro DWDM system in a 1ru box (or 2ru
for 8/32ch)

http://www.smartoptics.com/products/mseries/

MRV, BTI and others make more modular options if you want just the EDFA's.


From ag4ve.us at gmail.com  Sat Apr  6 14:38:06 2013
From: ag4ve.us at gmail.com (shawn wilson)
Date: Sat, 6 Apr 2013 10:38:06 -0400
Subject: ICMP Redirect on Resolvers
In-Reply-To: <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
 <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
Message-ID: <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmail.com>

On Apr 6, 2013 3:13 AM, "Jimmy Hess" <mysidia at gmail.com> wrote:
>

> Failing all that, if the LANs are large, and a large number of ICMP
> redirects would occur,  it may be preferrable to turn ICMP redirects
> off for those LANs on their routers
>

What would break if u dropped all ICMP packets with redirects on public
facing boxes?

From jra at baylink.com  Sat Apr  6 15:49:52 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 06 Apr 2013 11:49:52 -0400
Subject: WW: UN to recognize Garbage Patch
Message-ID: <e7da2d77-79bf-4130-b9e7-9eb628a964ec@email.android.com>

We are told this week, by NPR*, that the UN will next week declare 'Garbage Patch' - the 5 large vortices of trash in the world's oceans - a recognized nation state.

Anyone know anybody in the ISO 3166 Secretariat?

Cheers,
-- jra

* Ok, ok, it was Wait Wait.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From frnkblk at iname.com  Sat Apr  6 18:50:34 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Sat, 6 Apr 2013 13:50:34 -0500
Subject: 80 km BiDi XFPs
In-Reply-To: <3C73F7533E17CE4BA3558C3026772EC83FC93F95@postman.intranet.flexoptix.net>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <7774244507336980754@unknownmsgid>
 <3C73F7533E17CE4BA3558C3026772EC83FC93F95@postman.intranet.flexoptix.net>
Message-ID: <00ab01ce32f7$9edd57a0$dc9806e0$@iname.com>

Thanks, using an external CWDM mux is an option we're explorering.

Frank

-----Original Message-----
From: Thomas Weible - FLEXOPTIX [mailto:Thomas.Weible at flexoptix.net] 
Sent: Saturday, April 06, 2013 5:51 AM
To: Matt Addison; Frank Bulk
Cc: nanog at nanog.org
Subject: AW: 80 km BiDi XFPs

Matt Addison [mailto:matt.addison at lists.evilgeni.us] wrote:
> 
> How much spare margin do you have? Could you roll your own with a pair
> of mismatched (C|D)WDM XFPs and a mux on each end?

Typically you have 23dB powerbudget for the ZR (CWDM or DWDM) - maybe +2 dB
through selection of TOSA. A CWDM Mux will take 2dB and a small DWDM Mux
approx. 4dB  - you need two of them. This will drag your overall
link-powerbudget below 20dB.

It might work if you add a FEC (either on the linecard or the XFP itself).
This will add approx. 5dB to your powerbudget of 23dB. Take a CWDM Mux and
fire x-crossed on 1550 and 1570 (maybe 1530) and you will face an
attenuation of approx. 0,2 - 0,25dB/km. This could work and you should be
able to transmit 80km to 90km. It's worth a test - also to figure out if
dispersion will have an impact or not.

Thomas
> On Apr 2, 2013, at 19:16, Frank Bulk <frnkblk at iname.com> wrote:
> 
> > Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
> > supplier of generics doesn't have an option for us, but I would really
like
> > to avoid leasing additional fibers.
> >
> > Frank
> >
> >
> 
> 





From jeff-kell at utc.edu  Sat Apr  6 19:17:09 2013
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sat, 6 Apr 2013 15:17:09 -0400
Subject: Fiber plant APC vs UPC... once again...
Message-ID: <516074B5.2020406@utc.edu>

We are looking into doing cableTV/HFC distribution on campus, and fiber
runs for HFC typically run APC connectors to avoid reflectance on the
analog HFC signal where it is significant.  We we're looking at
converting some existing data UPC to APC for existing runs, and on the
new ones either do a parallel split (UPC and APC) or just stay uniform
(research seems to indicate APC is the winner).

In asking some other groups (EDU LAN managers) I've heard both
extremes... stick with all APC (and jumper APC-to-UPS on gear to data
terminations), and I've heard the exact opposite (UPC is fine, just
jumper UPC to APC at the terminations).  The last time I asked here, the
consensus seemed to be APC was ok, or else do parallel splits.

My best understanding is that going APC across the board, and just using
jumpers (APC to UPC) at the data ends should be fine, and I'm leaning in
that direction.  Are there any significant issues there?  Do APC
terminations "confuse" a data OTDR since you're now missing the expected
reflections?  Other issues?

Before the RFQs go out on the fiber expansion, I'd like to have a clear
goal in mind here :)  Any reason NOT to go APC for the installed fiber
plant and just adjust the terminating jumpers based on the endpoint targets?

Thanks (again),

Jeff



From Valdis.Kletnieks at vt.edu  Sat Apr  6 23:03:23 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 06 Apr 2013 19:03:23 -0400
Subject: ICMP Redirect on Resolvers
In-Reply-To: Your message of "Sat, 06 Apr 2013 10:38:06 -0400."
 <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmail.com>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
 <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
 <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmail.com>
Message-ID: <56427.1365289403@turing-police.cc.vt.edu>

On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:

> What would break if u dropped all ICMP packets with redirects on public
> facing boxes?

Presumably nothing, as long as you guaranteed that your IP address, netmask,
and routes actually match the reality of your network configuration.  In that
case, you shouldn't see any valid ICMP redirects.  They're there mostly so
things kind-of-sort-of work even if you botch it (so for instance, even if you
whiff your default route accidentally, you can still ssh in from Tokyo and fix
it).

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

From mureninc at gmail.com  Sat Apr  6 23:20:42 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Sat, 6 Apr 2013 16:20:42 -0700
Subject: 30% packet loss between cox.net and hetzner.de, possibly at
 tinet.net
In-Reply-To: <20130406042724.GA24109@lxr.su>
References: <20130406013254.GA24063@lxr.su>
 <0a7591e6725fe9c7806207e3ac0e9f22@visp.net.lb>
 <20130406042724.GA24109@lxr.su>
Message-ID: <20130406232041.GA31315@lxr.su>

On 2013-W14-5 21:27 -0700, Constantine A. Murenin wrote:
> On 2013-W14-6 05:04 +0300, Denys Fedoryshchenko wrote:
> > On 2013-04-06 04:32, Constantine A. Murenin wrote:
> > >Hello,
> > >
> > >There has been at least a 25% packet loss between hetzner.de and
> > >cox.net
> > >in the last couple of hours.
> > >
> > >Tried contacting hetzner.de, but they said it's not on their network.
> > >This has already happened a couple of days ago, too (strangely, on
> > >April 1),
> > >but then was good for the rest of the week -- no problems whatsoever.
> > >
> > >I wouldn't really care about this, if not for ssh:
> > >it just doesn't work on such huge loss.
> > >
> > >No other routes or networks seem affected.
> > >
> > >Any advice?
> > >
> > Doesnt looks like tinet for me.
> 
> Might have been eurorings.net, as your Amazon EC2 to Hetzner 
> traceroute seemed to suggest?
> 
> 
> This loss was apparent even with their own main websites:


This is now happening again today, in a similar timeframe:


% mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" hetzner.de ; date
HOST: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX    Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  4.|-- COX-68-12-10-121-static.coxinet.net    60    60  0.0%    8.8  12.3  12.9  43.4   5.4
  5.|-- COX-68-12-8-132-static.coxinet.net     60    60  0.0%   11.4  14.5  14.6  27.0   2.5
  6.|-- 68.1.5.161                             60    60  0.0%   56.1  60.4  60.5  74.0   4.0
  7.|-- nyk-s2-rou-1001.US.eurorings.net       60    60  0.0%   55.9  60.5  60.7  93.3   5.4
  8.|-- nntr-s1-rou-1101.FR.eurorings.net      60    60  0.0%  150.1 154.0 154.1 167.0   2.9
  9.|-- kehl-s2-rou-1103.DE.eurorings.net      60    60  0.0%  147.8 152.3 152.5 201.1   7.1
 10.|-- ffm-s1-rou-1102.DE.eurorings.net       60    60  0.0%  143.9 148.0 148.1 174.0   4.6
 11.|-- nbg-s1-rou-1001.DE.eurorings.net       60    60  0.0%  147.4 160.6 163.4 336.0  36.2
 12.|-- kpn-gw.hetzner.de                      60    51 15.0%  167.3 172.5 172.5 184.3   3.5
 13.|-- hos-bb2.juniper3.rz2.hetzner.de        60    60  0.0%  144.4 148.2 148.2 159.0   2.5
 14.|-- hos-tr4.ms-ex3k2.rz1.hetzner.de        60    59  1.7%  145.5 150.1 150.1 157.8   3.0
 15.|-- www.hetzner.de                         60    47 21.7%  167.0 173.2 173.3 203.2   7.1
Sat  6 Apr 2013 15:14:00 PDT

% traceroute -w2 -I hetzner.de; date
traceroute to hetzner.de (213.133.107.227), 64 hops max, 60 byte packets
 4  COX-68-12-10-121-static.coxinet.net (68.12.10.121)  22.012 ms  14.112 ms  11.230 ms
 5  COX-68-12-8-132-static.coxinet.net (68.12.8.132)  23.021 ms  13.239 ms  12.400 ms
 6  68.1.5.161 (68.1.5.161)  60.956 ms  59.738 ms  57.743 ms
 7  nyk-s2-rou-1001.US.eurorings.net (134.222.248.13)  58.906 ms  60.571 ms  70.399 ms
 8  nntr-s1-rou-1101.FR.eurorings.net (134.222.226.162)  152.597 ms  153.552 ms  150.250 ms
 9  kehl-s2-rou-1103.DE.eurorings.net (134.222.227.121)  152.905 ms  149.469 ms  150.648 ms
10  ffm-s1-rou-1102.DE.eurorings.net (134.222.227.177)  148.114 ms  144.579 ms  147.114 ms
11  nbg-s1-rou-1001.DE.eurorings.net (134.222.227.118)  148.728 ms  150.950 ms  148.117 ms
12  kpn-gw.hetzner.de (134.222.107.21)  170.385 ms *  167.488 ms
13  hos-bb2.juniper3.rz2.hetzner.de (213.239.240.129)  147.476 ms  149.074 ms  144.824 ms
14  hos-tr4.ms-ex3k2.rz1.hetzner.de (213.239.193.243)  161.621 ms  148.504 ms  147.931 ms
15  * www.hetzner.de (213.133.107.227)  169.137 ms  176.884 ms
Sat  6 Apr 2013 15:28:32 PDT


Cns# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" cox.net ; date
HOST: XXXXXXXXXX                                  Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  1.|-- static.33.203.4.46.clients.your-server.de    60    60  0.0%    0.6   1.2   1.5   3.8   1.1
  2.|-- hos-tr1.juniper1.rz13.hetzner.de             60    60  0.0%    0.2   0.3   1.8  34.6   5.8
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   3.2   5.2  77.2  10.9
  4.|-- r1nue1.core.init7.net                        60    60  0.0%    2.8   4.6   5.7  13.3   3.9
  5.|-- r1nue2.core.init7.net                        60    60  0.0%    2.9   4.1   4.7  13.9   2.9
  6.|-- r1fra2.core.init7.net                        60    60  0.0%    5.7   7.9   8.6  17.8   3.8
  7.|-- r1fra1.core.init7.net                        60    60  0.0%    5.9   8.9   9.8  17.1   4.3
  8.|-- xe-4-2-2.fra23.ip4.tinet.net                 60    60  0.0%    5.9   6.2   6.9  59.5   7.0
  9.|-- xe-10-2-2.was14.ip4.tinet.net                60    52 13.3%  115.3 119.8 120.1 163.4   9.1
 10.|-- cox-communications-gw.ip4.tinet.net          60    51 15.0%  119.5 123.7 124.0 175.8  10.3
 11.|-- dukedsrj02-ge210.0.rd.at.cox.net             60    48 20.0%  132.4 135.6 135.7 165.3   5.8
 12.|-- 68.1.15.238                                  60    47 21.7%  132.9 135.0 135.1 146.5   2.0
 13.|-- 68.99.123.4                                  60    33 45.0%  135.1 136.7 136.7 139.1   1.1
 14.|-- ww2.cox.com                                  60    50 16.7%  135.1 136.8 136.8 139.2   1.1
Sat Apr  6 15:13:49 PDT 2013

Cns# traceroute -w2 -I cox.net; date
traceroute to cox.net (68.99.123.161), 64 hops max, 60 byte packets
 1  static.33.203.4.46.clients.your-server.de (46.4.203.33)  0.790 ms  3.658 ms  0.486 ms
 2  hos-tr1.juniper1.rz13.hetzner.de (213.239.224.1)  0.244 ms  0.241 ms  0.251 ms
 3  hos-bb2.juniper4.rz2.hetzner.de (213.239.240.138)  2.735 ms  2.772 ms  2.752 ms
 4  r1nue1.core.init7.net (77.109.135.101)  2.811 ms  2.833 ms  2.769 ms
 5  r1nue2.core.init7.net (77.109.140.154)  2.955 ms  2.928 ms  2.896 ms
 6  r1fra2.core.init7.net (77.109.140.49)  14.891 ms  5.720 ms  13.291 ms
 7  r1fra1.core.init7.net (77.109.128.137)  5.935 ms  7.804 ms  5.905 ms
 8  xe-4-2-2.fra23.ip4.tinet.net (77.67.76.237)  5.885 ms  5.920 ms  5.912 ms
 9  xe-10-2-2.was14.ip4.tinet.net (141.136.110.18)  115.127 ms  121.543 ms *
10  cox-communications-gw.ip4.tinet.net (77.67.79.234)  119.574 ms  119.245 ms  119.170 ms
11  dukedsrj02-ge210.0.rd.at.cox.net (68.1.1.123)  132.619 ms  132.431 ms  132.363 ms
12  68.1.15.238 (68.1.15.238)  132.718 ms  132.689 ms  132.599 ms
13  68.99.123.4 (68.99.123.4)  134.947 ms *  134.671 ms
14  * ww2.cox.com (68.99.123.161)  135.139 ms  135 ms
Sat Apr  6 15:44:12 PDT 2013



It seems like hetzner.de <-> Amazon EC2 connectivity is indeed 
also affected, in addition to hetzner.de <-> cox.net:


Cns# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" www.tarsnap.com ; date
  2.|-- hos-tr3.juniper2.rz13.hetzner.de             60    60  0.0%    0.2   0.3   2.8  50.1   9.6
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   3.5   5.9  51.2  10.4
  4.|-- r1nue1.core.init7.net                        60    60  0.0%    2.8   4.7   5.6  14.2   3.5
  5.|-- r1nue2.core.init7.net                        60    60  0.0%    2.9   4.3   5.2  13.2   3.8
  6.|-- r1fra2.core.init7.net                        60    60  0.0%    5.7   8.8   9.7  18.4   4.6
  7.|-- r1fra1.core.init7.net                        60    60  0.0%    5.9   8.2   9.0  24.7   4.3
  8.|-- xe-4-2-2.fra23.ip4.tinet.net                 60    60  0.0%    5.9   6.4   7.0  43.7   5.4
  9.|-- xe-4-1-1.was14.ip4.tinet.net                 60    45 25.0%  115.1 117.3 117.6 173.2   9.6
 10.|-- vadata-gw.ip4.tinet.net                      60    50 16.7%  117.0 117.6 117.7 130.0   2.1
 11.|-- 72.21.220.31                                 60    50 16.7%  118.1 120.2 120.2 140.4   4.6
 12.|-- 205.251.245.55                               60    49 18.3%  120.2 121.1 121.1 132.0   2.1
 13.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
 16.|-- 216.182.224.129                              60    54 10.0%  118.2 118.9 118.9 130.3   1.7
 17.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
 18.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
 19.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
 20.|-- ec2-23-21-149-109.compute-1.amazonaws.com    59    53 10.2%  118.6 119.4 119.4 139.8   2.9
Sat Apr  6 15:21:06 PDT 2013



On the other hand, comcast.net is not affected, att.net not affected, 
he.net not affected, lots of other routes not affected.


Cns# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" comcast.net ; date
  2.|-- hos-tr3.juniper2.rz13.hetzner.de                      60    60  0.0%    0.2   0.3   3.9  56.6  11.6
  3.|-- hos-bb2.juniper8.rz1.hetzner.de                       60    60  0.0%    2.8   2.9   3.1  24.9   2.9
  4.|-- nbg-s1-rou-1001.DE.eurorings.net                      60    60  0.0%    3.0   3.6   7.3 177.0  24.2
  5.|-- mchn-s1-rou-1021.DE.eurorings.net                     60    60  0.0%    6.9   7.6   8.0  24.1   3.8
  6.|-- mchn-s1-rou-1103.DE.eurorings.net                     60    60  0.0%   91.8  93.7  93.9 133.0   6.7
  7.|-- kehl-s2-rou-1103.DE.eurorings.net                     60    60  0.0%   93.9  95.8  96.1 134.2   7.3
  8.|-- nntr-s1-rou-1101.FR.eurorings.net                     60    60  0.0%   91.8  94.2  94.3 127.6   5.3
  9.|-- nyk-s2-rou-1021.US.eurorings.net                      60    60  0.0%   92.1  95.7  96.0 128.3   8.2
 10.|-- nyk-s2-rou-1001.US.eurorings.net                      60    60  0.0%   91.7  93.2  93.7 188.9  12.6
 11.|-- te-1-10-0-4-pe01.111eighthave.ny.ibone.comcast.net    60    60  0.0%   91.7  92.3  92.3  93.7   0.3
 12.|-- pos-1-6-0-0-cr01.newyork.ny.ibone.comcast.net         60    60  0.0%   92.2  94.0  94.0  95.8   1.1
 13.|-- he-0-0-0-0-cr01.350ecermak.il.ibone.comcast.net       60    60  0.0%  111.5 117.1 117.2 123.3   3.6
 14.|-- pos-0-3-0-0-ar02.northlake.il.ndcchgo.comcast.net     60    60  0.0%  112.8 113.0 113.0 113.5   0.1
 15.|-- te-0-3-0-0-ur04.northlake.il.ndcchgo.comcast.net      60    60  0.0%  112.8 113.0 113.0 113.3   0.1
 16.|-- ge-0-1-0-0-ur03.northlake.il.ndcchgo.comcast.net      60    60  0.0%  112.9 113.0 113.0 113.3   0.1
 17.|-- ???                                                   60     0 100.0    0.0   0.0   0.0   0.0   0.0
Sat Apr  6 15:47:41 PDT 2013


Cns# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" att.net ; date
  2.|-- hos-tr3.juniper2.rz13.hetzner.de             60    60  0.0%    0.2   0.2   1.0  45.2   5.8
  3.|-- hos-bb2.juniper4.rz2.hetzner.de              60    60  0.0%    2.7   3.7   8.0  86.2  17.5
  4.|-- ae55.edge7.Frankfurt1.Level3.net             60    60  0.0%    7.2   7.9   8.9  57.8   7.9
  5.|-- ???                                          60     0 100.0    0.0   0.0   0.0   0.0   0.0
  6.|-- ae-62-62.ebr2.Frankfurt1.Level3.net          60    60  0.0%   85.3  85.3  85.3  87.2   0.3
  7.|-- ae-23-23.ebr2.London1.Level3.net             60    60  0.0%   85.3  85.3  85.3  85.4   0.0
  8.|-- ae-43-43.ebr1.NewYork1.Level3.net            60    60  0.0%   85.4  85.5  85.5  88.6   0.4
  9.|-- ae-71-71.csw2.NewYork1.Level3.net            60    60  0.0%   85.4  87.6  87.7  97.7   3.9
 10.|-- ae-2-70.edge3.NewYork1.Level3.net            60    60  0.0%   85.5  87.5  88.0 154.7  10.9
 11.|-- att-level3.newyork1.level3.net               60    60  0.0%   86.5  88.3  88.3  91.8   1.2
 12.|-- cr2.n54ny.ip.att.net                         60    60  0.0%  111.5 116.7 116.8 124.9   4.9
 13.|-- cr2.wswdc.ip.att.net                         60    60  0.0%  110.1 115.4 115.5 123.9   5.1
 14.|-- cr1.attga.ip.att.net                         60    60  0.0%  111.3 116.7 116.8 124.9   4.8
...
Sat Apr  6 15:36:40 PDT 2013


Cns# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" he.net ; date
  2.|-- hos-tr3.juniper2.rz13.hetzner.de             60    60  0.0%    0.2   0.3   4.2  71.3  13.9
  3.|-- hos-bb2.juniper4.ffm.hetzner.de              60    60  0.0%    5.8   5.9   6.0   9.9   0.7
  4.|-- 30gigabitethernet4-3.core1.fra1.he.net       60    60  0.0%    5.7   8.3   8.8  17.6   3.3
  5.|-- 10gigabitethernet1-4.core1.par2.he.net       60    60  0.0%   15.1  18.1  18.5  26.0   3.7
  6.|-- 10gigabitethernet7-1.core1.ash1.he.net       60    60  0.0%   93.1  95.9  95.9 105.7   3.5
  7.|-- 10gigabitethernet11-1.core1.pao1.he.net      60    60  0.0%  163.4 167.5 167.6 177.0   4.1
  8.|-- 10gigabitethernet1-2.core1.fmt1.he.net       60    60  0.0%  164.5 170.2 170.5 248.5  12.6
  9.|-- he.net                                       60    59  1.7%  164.0 164.6 164.6 165.2   0.2
Sat Apr  6 15:52:46 PDT 2013



Although hetzner.de claims that this whole loss is outside of their own 
network, I'm inclined to deduce that the loss might actually be 
concentrated on their own KPN / eurorings.net router -- 
kpn-gw.hetzner.de (134.222.107.21), and perhaps occurs only 
in one direction.

Although there is no traffic loss from he.net if you try to traceroute 
the router itself (I'm not sure what that means, though, other than a 
potential attack vector from exposing a router globally like that):

# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" -4 134.222.107.21 ; date
HOST: XXXXXXXXX                                Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  1. router1-fmt.linode.com                    60    60  0.0%    0.5   1.5   4.8  70.2  10.6
  2. 10gigabitethernet2-3.core1.fmt1.he.net    60    60  0.0%    0.6   1.0   3.5  72.1  11.9
  3. 10gigabitethernet1-1.core1.pao1.he.net    60    60  0.0%    1.0   1.2   1.4  12.4   1.5
  4. eqix-sv8.kpn.com                          60    60  0.0%    1.8   2.5   5.9  77.9  15.2
  5. chg-s1-rou-1041.US.eurorings.net          60    60  0.0%  161.5 167.1 167.3 197.9   7.5
  6. ahbn-s1-rou-1041.US.eurorings.net         60    60  0.0%   71.5  74.0  74.3 108.9   7.5
  7. nyk-s2-rou-1021.US.eurorings.net          60    60  0.0%   71.6  75.7  76.2 131.7  10.3
  8. nntr-s1-rou-1101.FR.eurorings.net         60    60  0.0%  161.6 164.5 164.6 188.8   6.8
  9. kehl-s2-rou-1103.DE.eurorings.net         60    60  0.0%  161.5 162.9 163.0 206.3   6.0
 10. ffm-s1-rou-1102.DE.eurorings.net          60    60  0.0%  157.9 166.9 167.1 193.8   9.4
 11. nbg-s1-rou-1001.DE.eurorings.net          60    60  0.0%  161.6 163.6 163.9 235.2  10.3
 12. kpn-gw.hetzner.de                         60    59  1.7%  161.3 161.9 161.9 167.5   1.0
Sat Apr  6 15:58:04 PDT 2013

li163-159:~# mtr --report{,-wide,-cycles=60} --order "SRL BGAWV" -4 hetzner.de ; date
HOST: xxxxxxxxx                                Snt   Rcv Loss%   Best Gmean   Avg  Wrst StDev
  1. router1-fmt.linode.com                    60    60  0.0%    0.5   8.6  34.8 396.6  66.0
  2. 10gigabitethernet2-3.core1.fmt1.he.net    60    60  0.0%    0.6   2.7   6.7  75.1  12.2
  3. 10gigabitethernet1-1.core1.pao1.he.net    60    60  0.0%    0.9   2.2   3.8  22.1   4.3
  4. 10gigabitethernet9-3.core1.ash1.he.net    60    60  0.0%   71.2  74.9  75.1  88.7   4.9
  5. 10gigabitethernet1-2.core1.par2.he.net    60    60  0.0%  149.0 151.9 152.0 159.8   3.5
  6. 10gigabitethernet4-4.core1.fra1.he.net    60    60  0.0%  158.2 161.3 161.4 169.1   3.8
  7. decix-gw.hetzner.de                       60    60  0.0%  158.6 161.2 161.4 209.3   8.9
  8. hos-bb1.juniper3.rz2.hetzner.de           60    60  0.0%  161.8 173.2 174.0 220.2  18.4
  9. hos-tr3.ms-ex3k2.rz1.hetzner.de           60    60  0.0%  162.6 163.7 163.7 166.0   1.1
 10. www.hetzner.de                            60    59  1.7%  161.8 162.4 162.4 163.1   0.3
Sat Apr  6 16:14:48 PDT 2013



I've been a fan of hetzner.de, but I think it's staggering that 
they won't do anything about this huge and persistent packet loss.


Best regards,
Constantine.


From denys at visp.net.lb  Sun Apr  7 00:09:00 2013
From: denys at visp.net.lb (Denys Fedoryshchenko)
Date: Sun, 07 Apr 2013 03:09:00 +0300
Subject: 30% packet loss between cox.net and hetzner.de, possibly at
 tinet.net
In-Reply-To: <20130406232041.GA31315@lxr.su>
References: <20130406013254.GA24063@lxr.su>
 <0a7591e6725fe9c7806207e3ac0e9f22@visp.net.lb>
 <20130406042724.GA24109@lxr.su> <20130406232041.GA31315@lxr.su>
Message-ID: <d453f32ec9779702cd8bc18dd6f9ead4@visp.net.lb>

On 2013-04-07 02:20, Constantine A. Murenin wrote:

> 
> Although hetzner.de claims that this whole loss is outside of their 
> own
> network, I'm inclined to deduce that the loss might actually be
> concentrated on their own KPN / eurorings.net router --
> kpn-gw.hetzner.de (134.222.107.21), and perhaps occurs only
> in one direction.
I think too. Btw as i said, have host on tinet, and it is 100% clear 
from EC2.
So seems tinet is fine for sure.

HOST: ip-10-203-61-X                                Snt   Rcv Loss%   
Best Gmean   Avg  Wrst StDev
   1.|-- ip-10-203-60-2.ec2.internal                 60    60  0.0%    
0.3   0.6   1.1  19.1   2.7
   2.|-- ip-10-1-36-21.ec2.internal                  60    60  0.0%    
0.4   0.6   0.8   9.3   1.3
   3.|-- ip-10-1-34-0.ec2.internal                   60    60  0.0%    
0.4   0.7   1.0  14.5   2.0
   4.|-- 100.64.20.43                                60    60  0.0%    
0.4   0.6   0.6   2.0   0.2
   5.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
   6.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
   7.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
   8.|-- 100.64.16.157                               60    60  0.0%    
0.5   2.4   9.7  68.8  16.1
   9.|-- 72.21.222.154                               60    60  0.0%    
1.5   1.9   2.6  36.4   4.8
  10.|-- 72.21.220.46                                60    60  0.0%    
1.5   2.1   3.3  59.2   7.6
  11.|-- xe-7-2-0.was10.ip4.tinet.net                60    60  0.0%    
1.6   2.1   2.6  17.2   3.1
  12.|-- xe-0-1-0.fra23.ip4.tinet.net                60    60  0.0%   
92.2  92.8  92.8 104.3   1.9
  13.|-- ge-1-1-0.pr1.g310.fra.de.eurotransit.net    60    60  0.0%   
92.2  93.1  93.2 112.8   3.3
  14.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
last hop icmp blocked, it is my host


> 
> Although there is no traffic loss from he.net if you try to traceroute
> the router itself (I'm not sure what that means, though, other than a
> potential attack vector from exposing a router globally like that):
I don't think there is attack vector, proper control plane ACL will 
make them safe.

> I've been a fan of hetzner.de, but I think it's staggering that
> they won't do anything about this huge and persistent packet loss.
Indeed, i noticed that transfers from EC2 are terrible last days to 
Hetzner.

Maybe worth to open topic at www.webhostingtalk.com ?

> 
> 
> Best regards,
> Constantine.

---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.


From cb.list6 at gmail.com  Sun Apr  7 01:24:10 2013
From: cb.list6 at gmail.com (cb.list6)
Date: Sat, 6 Apr 2013 18:24:10 -0700
Subject: Verizon DSL moving to CGN
Message-ID: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>

Interesting.

http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

From juicewvu at gmail.com  Sun Apr  7 01:32:47 2013
From: juicewvu at gmail.com (Joshua Smith)
Date: Sat, 6 Apr 2013 21:32:47 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
Message-ID: <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>

Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. 

-- 
Josh Smith
kD8HRX

email/jabber: juicewvu at gmail.com
Phone: 304.237.9369(c)

Sent from my iPad


On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:

> Interesting.
> 
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm


From oliver at g.garraux.net  Sun Apr  7 01:41:43 2013
From: oliver at g.garraux.net (Oliver Garraux)
Date: Sat, 6 Apr 2013 21:41:43 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
Message-ID: <CAD_uLpO5CyGCrOUdk5WRbYRnMUf4K9PFeWi6ZSWmzwJDTxTBhA@mail.gmail.com>

Good to see that they are providing a way for users to opt out.  I'm hoping
that other ISP's will do the same when they implement CGN.

Oliver

-------------------------------------

Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux


On Sat, Apr 6, 2013 at 9:32 PM, Joshua Smith <juicewvu at gmail.com> wrote:

> Very interesting indeed. Way to do the right thing here Verizon. This may
> be the first time I've been happy to be a Comcast customer.
>
> --
> Josh Smith
> kD8HRX
>
> email/jabber: juicewvu at gmail.com
> Phone: 304.237.9369(c)
>
> Sent from my iPad
>
>
> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>
> > Interesting.
> >
> >
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
>
>

From mysidia at gmail.com  Sun Apr  7 01:43:34 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 6 Apr 2013 20:43:34 -0500
Subject: ICMP Redirect on Resolvers
In-Reply-To: <56427.1365289403@turing-police.cc.vt.edu>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
 <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
 <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmail.com>
 <56427.1365289403@turing-police.cc.vt.edu>
Message-ID: <CAAAwwbWNvMsPb_h-cfxDWYUSC2i1_3pFfJfK7Kx_cN3ajBnn5Q@mail.gmail.com>

On 4/6/13, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> wrote:
> On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:

 case, you shouldn't see any valid ICMP redirects.  They're there mostly so
> things kind-of-sort-of work even if you botch it (so for instance, even if
> you whiff your default route accidentally, you can still ssh in from Tokyo and
> fix  > it).

For ICMP redirects to do anything useful,  a valid route has to
actually be there already, on the default gateway....

Perhaps you are thinking of proxy arp? :)


-- 
-JH


From derek at derekivey.com  Sun Apr  7 01:42:00 2013
From: derek at derekivey.com (Derek Ivey)
Date: Sat, 06 Apr 2013 21:42:00 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
Message-ID: <5160CEE8.6010404@derekivey.com>

It would be nice to get an update from them regarding their IPv6 plans. 
Their IPv6 support page still says they will start deploying "3Q12" :(.

On 4/6/2013 9:32 PM, Joshua Smith wrote:
> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4249 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130406/03a6630f/attachment.bin>

From mureninc at gmail.com  Sun Apr  7 02:11:14 2013
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Sat, 6 Apr 2013 19:11:14 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
Message-ID: <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>

On 6 April 2013 18:24, cb.list6 <cb.list6 at gmail.com> wrote:
> Interesting.
>
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

<blockquote>

> What is  CGN - and How to opt-out The number and types of devices using the Internet have increased dramatically in recent years and, as a result, address space for these devices is being rapidly exhausted. Today?s technology for IP addresses is referred to as IPv4 (Internet Protocol version 4). The IP addresses aligned with IPv4 are expected to be depleted at some point in the near future. The next generation of IP address space is IPv6, which will enable far more addresses to be assigned than IPv4. Unfortunately, most servers and other Internet devices will not be speaking IPv6 for a while, so IPv4 will remain standard for some time to come.
>
> During this transitional period, in select areas for High Speed Internet residential customers, Verizon will be implementing Carrier Grade Network Address Translation (CGN or Carrier Grade NAT). Verizon FiOS and Verizon Business customers are not impacted at this time by the change. This transition will enable Verizon to continue serving customers with IPv4 internet addresses. CGN will not impact the access, reliability, speed, or security of Verizon?s broadband services. However, there are some applications such as online gaming, VPN access, FTP service, surveillance cameras, etc., that may not work when broadband service is provided via a CGN.
>
> For our customers utilizing these types of applications, Verizon provides the ability to "opt out ?of CGN. To "opt out" you must:
>
>     Be a Residential customer with High Speed Internet Service. There is no need to ?opt-out? if you are a FiOS or Business customer.
>     Have already been transitioned to the Carrier Grade Network by Verizon. If you are a Residential High Speed Internet customer and are unable to opt-out, it is likely that you have not yet been transitioned to CGN.
>
>
> To "opt out" of CGN sign onto your My Verizon account and select "Opt out of Carrier Grade Network".

</blockquote>


I like how, according to the document, Verizon must first break your
connectivity, prior to you being able to opt-out. :-)

Also:

> select "Opt out of Carrier Grade Network"

Smart wording. :-)

Frankly, I'm surprised to see this news.  I thought Verizon had better
things to do that plan any kind of upgrades or changes to something
that everyone thought they consider dead anyways.

C.


From matthew at matthew.at  Sun Apr  7 02:29:04 2013
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 06 Apr 2013 19:29:04 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
Message-ID: <5160D9F0.8010503@matthew.at>

On 4/6/2013 6:24 PM, cb.list6 wrote:
> Interesting.
>
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

I'd love to see a CGN box that is cheaper than IPv4 addresses currently 
are on the transfer market.

Matthew Kaufman


From jra at baylink.com  Sun Apr  7 02:38:51 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sat, 6 Apr 2013 22:38:51 -0400 (EDT)
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
Message-ID: <28122109.1236.1365302331310.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "cb.list6" <cb.list6 at gmail.com>

> Interesting.
> 
http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

What I find amusing is how they call it "Carrier Grade NAT" one time, and
then switch to calling it "Carrier Grade Network", thereby making it sound
all cool and better and stuff...

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From swmike at swm.pp.se  Sun Apr  7 03:29:49 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 7 Apr 2013 05:29:49 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <5160D9F0.8010503@matthew.at>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5160D9F0.8010503@matthew.at>
Message-ID: <alpine.DEB.2.00.1304070526520.23668@uplift.swm.pp.se>

On Sat, 6 Apr 2013, Matthew Kaufman wrote:

> I'd love to see a CGN box that is cheaper than IPv4 addresses currently 
> are on the transfer market.

That depends on what you think the prices are for IPv4 addresses and what 
you think the prices are for CGN boxes. At the prices I'm hearing, it's 
cheaper to CGN 50k users (or more) than to purchase IPv4 addresses.

Otoh, ARIN isn't exhausted yet so getting IPv4 addresses there should 
still be a lot cheaper than doing CGN?

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


From mysidia at gmail.com  Sun Apr  7 04:37:09 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 6 Apr 2013 23:37:09 -0500
Subject: Verizon DSL moving to CGN
In-Reply-To: <5160D9F0.8010503@matthew.at>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5160D9F0.8010503@matthew.at>
Message-ID: <CAAAwwbV733O1yMgYjtNCVg+_n7jZqMEgJLW7ekzrGZDEiZTU9A@mail.gmail.com>

On 4/6/13, Matthew Kaufman <matthew at matthew.at> wrote:
> On 4/6/2013 6:24 PM, cb.list6 wrote:
>
> I'd love to see a CGN box that is cheaper than IPv4 addresses currently
> are on the transfer market.

You mean like a few linux servers running iptables  nat-masquerade?

You think the "Carrier Grade"  in "Carrier Grade NAT"  isn't just a
rhetorically constructed distraction,  from the fact that  simple NAT
may  be implemented,  and yeah, end users are certain to experience
annoyances, either way...


>
> Matthew Kaufman
--
-JH


From nanog at studio442.com.au  Sun Apr  7 05:22:49 2013
From: nanog at studio442.com.au (Julien Goodwin)
Date: Sun, 07 Apr 2013 15:22:49 +1000
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
Message-ID: <516102A9.2040301@studio442.com.au>

On 07/04/13 12:11, Constantine A. Murenin wrote:
> On 6 April 2013 18:24, cb.list6 <cb.list6 at gmail.com> wrote:
>> Interesting.
>>
>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
> 
> <blockquote>
...
>> ...CGN will not impact the access,
>> reliability, speed, or security of Verizon?s broadband services. ...
...
> </blockquote>

Good luck with that, pretty much by definition it has to do all four
(albeit at levels that shouldn't be detectable to the end user)


> I like how, according to the document, Verizon must first break your
> connectivity, prior to you being able to opt-out. :-)

If you look at it from their side this makes a lot of sense, helps to
ensure that only those who actually get breakage from the CGN opt out,
otherwise you'd never know to request it.



From morrowc.lists at gmail.com  Sun Apr  7 05:40:09 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 7 Apr 2013 01:40:09 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <516102A9.2040301@studio442.com.au>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
Message-ID: <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>

On Sun, Apr 7, 2013 at 1:22 AM, Julien Goodwin <nanog at studio442.com.au>wrote:

> >> ...CGN will not impact the access,
> >> reliability, speed, or security of Verizon?s broadband services. ...
> ...
> > </blockquote>
>
> Good luck with that, pretty much by definition it has to do all four
> (albeit at levels that shouldn't be detectable to the end user)
>


I wonder how much more painful just upgrading the dsl plant to support v6
would be vs deploying the cgn equipment and funneling users through that :(

From Valdis.Kletnieks at vt.edu  Sun Apr  7 06:40:35 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 07 Apr 2013 02:40:35 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: Your message of "Sun, 07 Apr 2013 01:40:09 -0400."
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
Message-ID: <74375.1365316835@turing-police.cc.vt.edu>

On Sun, 07 Apr 2013 01:40:09 -0400, Christopher Morrow said:

> I wonder how much more painful just upgrading the dsl plant to support v6
> would be vs deploying the cgn equipment and funneling users through that :(

The answer depends on whether the person making the decision thinks they'll
have left the company before the IPv6 birds come home to roost. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130407/cc1edba3/attachment.bin>

From swmike at swm.pp.se  Sun Apr  7 06:42:01 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 7 Apr 2013 08:42:01 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>

On Sun, 7 Apr 2013, Christopher Morrow wrote:

> I wonder how much more painful just upgrading the dsl plant to support 
> v6 would be vs deploying the cgn equipment and funneling users through 
> that :(

IPv6 deployment is not a short term solution to IPv4 address depletion. 
Would you be less upset if there was IPv6 access and CPE based DS Lite (ie 
your IPv4 is still CGN:ed, just in a different way)?

CGN is here to stay for IPv4. The solution for long term Internet growth 
is IPv6.

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


From fdelmotte1 at mac.com  Sun Apr  7 07:12:24 2013
From: fdelmotte1 at mac.com (Fabien Delmotte)
Date: Sun, 07 Apr 2013 09:12:24 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
Message-ID: <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>

CGN is just a solution to save time, it is not a transition mechanism through IPv6
At the end (IPv6 at home) you will need at list :
Dual stack or NAT64/ DNS64

My 2 cents

On Apr 7, 2013, at 8:42 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Sun, 7 Apr 2013, Christopher Morrow wrote:
> 
>> I wonder how much more painful just upgrading the dsl plant to support v6 would be vs deploying the cgn equipment and funneling users through that :(
> 
> IPv6 deployment is not a short term solution to IPv4 address depletion. Would you be less upset if there was IPv6 access and CPE based DS Lite (ie your IPv4 is still CGN:ed, just in a different way)?
> 
> CGN is here to stay for IPv4. The solution for long term Internet growth is IPv6.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
> 


From swmike at swm.pp.se  Sun Apr  7 07:31:22 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 7 Apr 2013 09:31:22 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
Message-ID: <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>

On Sun, 7 Apr 2013, Fabien Delmotte wrote:

> CGN is just a solution to save time, it is not a transition mechanism through IPv6
> At the end (IPv6 at home) you will need at list :
> Dual stack or NAT64/ DNS64

CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the 
water without other mechanisms (464XLAT or alike).

My point is that people seem to scoff at CGN. There is nothing stopping 
anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address 
exhaustion), then giving dual stack for end users can be done at any time.

Face it, we're running out of IPv4 addresses. For basic Internet 
subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a 
completely different problem that has little bearing on CGN or not for 
IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. 
MAP is also CGN.

I'm ok with people complaining about lack of IPv6 deployment, but I don't 
understand people complaining about CGN. What's the alternative?

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


From dreamwaverfx at yahoo.com  Sun Apr  7 10:54:04 2013
From: dreamwaverfx at yahoo.com (Alex)
Date: Sun, 07 Apr 2013 13:54:04 +0300
Subject: Verizon DSL moving to CGN
In-Reply-To: <28122109.1236.1365302331310.JavaMail.root@benjamin.baylink.com>
References: <28122109.1236.1365302331310.JavaMail.root@benjamin.baylink.com>
Message-ID: <5161504C.5030704@yahoo.com>

Well if the RFCs would just be set in stone already like Moses's 10 
commandments
and if the programmers would actually start writing code for v6
and if the web site hosting servers would at least have dual stack 
enabled on them
it would be great.

But till then we just change a RFC here, band-aid IPv4 there and wait 
till everything reaches critical mass and comes crashing on our heads.

On 4/7/2013 5:38 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "cb.list6" <cb.list6 at gmail.com>
>> Interesting.
>>
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
>
> What I find amusing is how they call it "Carrier Grade NAT" one time, and
> then switch to calling it "Carrier Grade Network", thereby making it sound
> all cool and better and stuff...
>
> Cheers,
> -- jra



From rs at seastrom.com  Sun Apr  7 12:39:16 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Sun, 07 Apr 2013 08:39:16 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAAAwwbV733O1yMgYjtNCVg+_n7jZqMEgJLW7ekzrGZDEiZTU9A@mail.gmail.com> (Jimmy
 Hess's message of "Sat, 6 Apr 2013 23:37:09 -0500")
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5160D9F0.8010503@matthew.at>
 <CAAAwwbV733O1yMgYjtNCVg+_n7jZqMEgJLW7ekzrGZDEiZTU9A@mail.gmail.com>
Message-ID: <86wqsezf9n.fsf@valhalla.seastrom.com>


Jimmy Hess <mysidia at gmail.com> writes:

> On 4/6/13, Matthew Kaufman <matthew at matthew.at> wrote:
>> On 4/6/2013 6:24 PM, cb.list6 wrote:
>>
>> I'd love to see a CGN box that is cheaper than IPv4 addresses currently
>> are on the transfer market.
>
> You mean like a few linux servers running iptables  nat-masquerade?
>
> You think the "Carrier Grade"  in "Carrier Grade NAT"  isn't just a
> rhetorically constructed distraction,  from the fact that  simple NAT
> may  be implemented,  and yeah, end users are certain to experience
> annoyances, either way...

Forget about the "annoying users" part; the "carrier-grade" part of
CGN is all about not annoying the service provider.  As far as I'm
aware, iptables does not include deterministic port translation based
on source address, nor easy-to-configure hooks for CALEA [*].  It may
well turn out that once one factors in support your costs are higher
with large scale NAT-on-Linux than if you'd sucked it up and coughed
up a quarter mil for an appliance.

-r

[*] I'd love to hear that I'm wrong on this count, but a how-to
document that explains how one can lovingly handcraft such a thing as
opposed to a special refactored distro that's ready to plug-and-chug
appliance style will only serve to reinforce my assertion.


From Valdis.Kletnieks at vt.edu  Sun Apr  7 15:26:38 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 07 Apr 2013 11:26:38 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: Your message of "Sun, 07 Apr 2013 13:54:04 +0300."
 <5161504C.5030704@yahoo.com>
References: <28122109.1236.1365302331310.JavaMail.root@benjamin.baylink.com>
 <5161504C.5030704@yahoo.com>
Message-ID: <95654.1365348398@turing-police.cc.vt.edu>

On Sun, 07 Apr 2013 13:54:04 +0300, Alex said:
> Well if the RFCs would just be set in stone already like Moses's 10 commandments
> and if the programmers would actually start writing code for v6
> and if the web site hosting servers would at least have dual stack
> enabled on them
> it would be great.
>
> But till then we just change a RFC here, band-aid IPv4 there and wait
> till everything reaches critical mass and comes crashing on our heads.

I find it interesting that you complain about a 15 year old protocol
not being set in stone, and cite that as a reason for no code getting
done.

But the solution is to take advantage of the fact that the 30 year old
predecessor isn't set in stone either...

(And there's no reason that programmers can't be writing code - RFC3542
came out in May 2003)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130407/635c4598/attachment.bin>

From tore at fud.no  Sun Apr  7 08:15:10 2013
From: tore at fud.no (Tore Anderson)
Date: Sun, 07 Apr 2013 10:15:10 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
Message-ID: <51612B0E.70405@fud.no>

* Mikael Abrahamsson

> My point is that people seem to scoff at CGN. There is nothing stopping
> anyone putting in CGN for IPv4 (that has to be done to handle IPv4
> address exhaustion), then giving dual stack for end users can be done at
> any time.
> 
> Face it, we're running out of IPv4 addresses. For basic Internet
> subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a
> completely different problem that has little bearing on CGN or not for
> IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access.
> MAP is also CGN.
> 
> I'm ok with people complaining about lack of IPv6 deployment, but I
> don't understand people complaining about CGN. What's the alternative?

Technically I agree with all of the above. However, going for the NAT444
flavour of CGN might well delay or lower the perceived importance of
IPv6 deployment within an ISP. The immediate problem is IPv4 service
continuity, and if that is to be accomplished without IPv6 being part of
it, it's easy to postpone doing anything about IPv6.

I went to an interesting presentation from Kabel Deutschland last month,
who have deployed DS-Lite to their residential subscribers. One of the
messages was that once the decision was made to implement DS-Lite to
deal with IPv4 exhaustion, there was no problem getting the necessary
support to deploy IPv6 - it was no longer a separate and
non-revenue-generating problem, but an essential building block needed
for their IPv4 service continuity. (MAP and 464XLAT would yield the same
effect, of course.)

To answer your earlier question - yes, I'd very much prefer to have
DS-Lite over NAT444, because only the former will ensure that I get
native IPv6 once my native IPv4 gets taken away. With NAT444, I'm no
closer to having IPv6 than I was before NAT444.

That said, there are of course some things that may make anything except
NAT444 undeployable. Verizon might have old DSLAMs that cannot deal with
IPv6, or customer-controlled/owned (layer-3) HGWs. If so, their hands
are tied.

-- 
Tore Anderson


From ramcharan007 at gmail.com  Sun Apr  7 02:27:37 2013
From: ramcharan007 at gmail.com (ramcharan007 at gmail.com)
Date: Sun, 7 Apr 2013 02:27:37 +0000
Subject: NANOG Digest, Vol 63, Issue 29
In-Reply-To: <mailman.22022.1365300681.12739.nanog@nanog.org>
References: <mailman.22022.1365300681.12739.nanog@nanog.org>
Message-ID: <25778165-1365301658-cardhu_decombobulator_blackberry.rim.net-1893603881-@b5.c4.bise3.blackberry>


In MPLS network when we speak of utilization is 50% between 2 points in a circuit , What does it mean and how can I measure it ?


Sent from my BlackBerry? via Smartfren EVDO Network

-----Original Message-----
From: nanog-request at nanog.org
Date: Sun, 07 Apr 2013 02:11:21 
To: <nanog at nanog.org>
Reply-To: nanog at nanog.org
Subject: NANOG Digest, Vol 63, Issue 29

Send NANOG mailing list submissions to
	nanog at nanog.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
	nanog-request at nanog.org

You can reach the person managing the list at
	nanog-owner at nanog.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

   1. Re: 30% packet loss between cox.net and hetzner.de, possibly
      at tinet.net (Denys Fedoryshchenko)
   2. Verizon DSL moving to CGN (cb.list6)
   3. Re: Verizon DSL moving to CGN (Joshua Smith)
   4. Re: Verizon DSL moving to CGN (Oliver Garraux)
   5. Re: ICMP Redirect on Resolvers (Jimmy Hess)
   6. Re: Verizon DSL moving to CGN (Derek Ivey)
   7. Re: Verizon DSL moving to CGN (Constantine A. Murenin)


----------------------------------------------------------------------

Message: 1
Date: Sun, 07 Apr 2013 03:09:00 +0300
From: Denys Fedoryshchenko <denys at visp.net.lb>
To: "Constantine A. Murenin" <mureninc at gmail.com>
Cc: nanog at nanog.org
Subject: Re: 30% packet loss between cox.net and hetzner.de, possibly
	at tinet.net
Message-ID: <d453f32ec9779702cd8bc18dd6f9ead4 at visp.net.lb>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 2013-04-07 02:20, Constantine A. Murenin wrote:

> 
> Although hetzner.de claims that this whole loss is outside of their 
> own
> network, I'm inclined to deduce that the loss might actually be
> concentrated on their own KPN / eurorings.net router --
> kpn-gw.hetzner.de (134.222.107.21), and perhaps occurs only
> in one direction.
I think too. Btw as i said, have host on tinet, and it is 100% clear 
from EC2.
So seems tinet is fine for sure.

HOST: ip-10-203-61-X                                Snt   Rcv Loss%   
Best Gmean   Avg  Wrst StDev
   1.|-- ip-10-203-60-2.ec2.internal                 60    60  0.0%    
0.3   0.6   1.1  19.1   2.7
   2.|-- ip-10-1-36-21.ec2.internal                  60    60  0.0%    
0.4   0.6   0.8   9.3   1.3
   3.|-- ip-10-1-34-0.ec2.internal                   60    60  0.0%    
0.4   0.7   1.0  14.5   2.0
   4.|-- 100.64.20.43                                60    60  0.0%    
0.4   0.6   0.6   2.0   0.2
   5.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
   6.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
   7.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
   8.|-- 100.64.16.157                               60    60  0.0%    
0.5   2.4   9.7  68.8  16.1
   9.|-- 72.21.222.154                               60    60  0.0%    
1.5   1.9   2.6  36.4   4.8
  10.|-- 72.21.220.46                                60    60  0.0%    
1.5   2.1   3.3  59.2   7.6
  11.|-- xe-7-2-0.was10.ip4.tinet.net                60    60  0.0%    
1.6   2.1   2.6  17.2   3.1
  12.|-- xe-0-1-0.fra23.ip4.tinet.net                60    60  0.0%   
92.2  92.8  92.8 104.3   1.9
  13.|-- ge-1-1-0.pr1.g310.fra.de.eurotransit.net    60    60  0.0%   
92.2  93.1  93.2 112.8   3.3
  14.|-- ???                                         60     0 100.0    
0.0   0.0   0.0   0.0   0.0
last hop icmp blocked, it is my host


> 
> Although there is no traffic loss from he.net if you try to traceroute
> the router itself (I'm not sure what that means, though, other than a
> potential attack vector from exposing a router globally like that):
I don't think there is attack vector, proper control plane ACL will 
make them safe.

> I've been a fan of hetzner.de, but I think it's staggering that
> they won't do anything about this huge and persistent packet loss.
Indeed, i noticed that transfers from EC2 are terrible last days to 
Hetzner.

Maybe worth to open topic at www.webhostingtalk.com ?

> 
> 
> Best regards,
> Constantine.

---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.



------------------------------

Message: 2
Date: Sat, 6 Apr 2013 18:24:10 -0700
From: "cb.list6" <cb.list6 at gmail.com>
To: nanog at nanog.org
Subject: Verizon DSL moving to CGN
Message-ID:
	<CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Interesting.

http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm


------------------------------

Message: 3
Date: Sat, 6 Apr 2013 21:32:47 -0400
From: Joshua Smith <juicewvu at gmail.com>
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN
Message-ID: <5C944EFC-CD47-4569-9452-5133B5F780E9 at gmail.com>
Content-Type: text/plain;	charset=us-ascii

Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. 

-- 
Josh Smith
kD8HRX

email/jabber: juicewvu at gmail.com
Phone: 304.237.9369(c)

Sent from my iPad


On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:

> Interesting.
> 
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm



------------------------------

Message: 4
Date: Sat, 6 Apr 2013 21:41:43 -0400
From: Oliver Garraux <oliver at g.garraux.net>
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN
Message-ID:
	<CAD_uLpO5CyGCrOUdk5WRbYRnMUf4K9PFeWi6ZSWmzwJDTxTBhA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Good to see that they are providing a way for users to opt out.  I'm hoping
that other ISP's will do the same when they implement CGN.

Oliver

-------------------------------------

Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux


On Sat, Apr 6, 2013 at 9:32 PM, Joshua Smith <juicewvu at gmail.com> wrote:

> Very interesting indeed. Way to do the right thing here Verizon. This may
> be the first time I've been happy to be a Comcast customer.
>
> --
> Josh Smith
> kD8HRX
>
> email/jabber: juicewvu at gmail.com
> Phone: 304.237.9369(c)
>
> Sent from my iPad
>
>
> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>
> > Interesting.
> >
> >
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
>
>


------------------------------

Message: 5
Date: Sat, 6 Apr 2013 20:43:34 -0500
From: Jimmy Hess <mysidia at gmail.com>
To: Valdis.Kletnieks at vt.edu
Cc: North American Network Operators Group <nanog at nanog.org>
Subject: Re: ICMP Redirect on Resolvers
Message-ID:
	<CAAAwwbWNvMsPb_h-cfxDWYUSC2i1_3pFfJfK7Kx_cN3ajBnn5Q at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 4/6/13, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> wrote:
> On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:

 case, you shouldn't see any valid ICMP redirects.  They're there mostly so
> things kind-of-sort-of work even if you botch it (so for instance, even if
> you whiff your default route accidentally, you can still ssh in from Tokyo and
> fix  > it).

For ICMP redirects to do anything useful,  a valid route has to
actually be there already, on the default gateway....

Perhaps you are thinking of proxy arp? :)


-- 
-JH



------------------------------

Message: 6
Date: Sat, 06 Apr 2013 21:42:00 -0400
From: Derek Ivey <derek at derekivey.com>
To: nanog at nanog.org
Subject: Re: Verizon DSL moving to CGN
Message-ID: <5160CEE8.6010404 at derekivey.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

It would be nice to get an update from them regarding their IPv6 plans. 
Their IPv6 support page still says they will start deploying "3Q12" :(.

On 4/6/2013 9:32 PM, Joshua Smith wrote:
> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4249 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130406/03a6630f/attachment-0001.bin>

------------------------------

Message: 7
Date: Sat, 6 Apr 2013 19:11:14 -0700
From: "Constantine A. Murenin" <mureninc at gmail.com>
To: "cb.list6" <cb.list6 at gmail.com>
Cc: nanog at nanog.org
Subject: Re: Verizon DSL moving to CGN
Message-ID:
	<CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

On 6 April 2013 18:24, cb.list6 <cb.list6 at gmail.com> wrote:
> Interesting.
>
> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

<blockquote>

> What is  CGN - and How to opt-out The number and types of devices using the Internet have increased dramatically in recent years and, as a result, address space for these devices is being rapidly exhausted. Today?s technology for IP addresses is referred to as IPv4 (Internet Protocol version 4). The IP addresses aligned with IPv4 are expected to be depleted at some point in the near future. The next generation of IP address space is IPv6, which will enable far more addresses to be assigned than IPv4. Unfortunately, most servers and other Internet devices will not be speaking IPv6 for a while, so IPv4 will remain standard for some time to come.
>
> During this transitional period, in select areas for High Speed Internet residential customers, Verizon will be implementing Carrier Grade Network Address Translation (CGN or Carrier Grade NAT). Verizon FiOS and Verizon Business customers are not impacted at this time by the change. This transition will enable Verizon to continue serving customers with IPv4 internet addresses. CGN will not impact the access, reliability, speed, or security of Verizon?s broadband services. However, there are some applications such as online gaming, VPN access, FTP service, surveillance cameras, etc., that may not work when broadband service is provided via a CGN.
>
> For our customers utilizing these types of applications, Verizon provides the ability to "opt out ?of CGN. To "opt out" you must:
>
>     Be a Residential customer with High Speed Internet Service. There is no need to ?opt-out? if you are a FiOS or Business customer.
>     Have already been transitioned to the Carrier Grade Network by Verizon. If you are a Residential High Speed Internet customer and are unable to opt-out, it is likely that you have not yet been transitioned to CGN.
>
>
> To "opt out" of CGN sign onto your My Verizon account and select "Opt out of Carrier Grade Network".

</blockquote>


I like how, according to the document, Verizon must first break your
connectivity, prior to you being able to opt-out. :-)

Also:

> select "Opt out of Carrier Grade Network"

Smart wording. :-)

Frankly, I'm surprised to see this news.  I thought Verizon had better
things to do that plan any kind of upgrades or changes to something
that everyone thought they consider dead anyways.

C.



End of NANOG Digest, Vol 63, Issue 29
*************************************

From huasong at kalorama.com  Sun Apr  7 03:33:02 2013
From: huasong at kalorama.com (Huasong Zhou)
Date: Sun, 7 Apr 2013 03:33:02 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>,
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
Message-ID: <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>

I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.

Joe

Sent from my iPhone

On Apr 6, 2013, at 9:33 PM, "Joshua Smith" <juicewvu at gmail.com> wrote:

> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. 
> 
> -- 
> Josh Smith
> kD8HRX
> 
> email/jabber: juicewvu at gmail.com
> Phone: 304.237.9369(c)
> 
> Sent from my iPad
> 
> 
> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
> 
>> Interesting.
>> 
>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
> 


From tore at fud.no  Sun Apr  7 08:48:31 2013
From: tore at fud.no (Tore Anderson)
Date: Sun, 07 Apr 2013 10:48:31 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304070526520.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5160D9F0.8010503@matthew.at>
 <alpine.DEB.2.00.1304070526520.23668@uplift.swm.pp.se>
Message-ID: <516132DF.3040304@fud.no>

* Mikael Abrahamsson

> Otoh, ARIN isn't exhausted yet so getting IPv4 addresses there should
> still be a lot cheaper than doing CGN?

>From what I hear several ISPs in the ARIN region prefer to obtain
second-hand IPv4 addresses (or deploy CGN boxes) over requesting
addresses directly from ARIN, and the reason is that ARIN, per policy,
will only give its members addresses to cover three months' worth of
consumption, and that this period is simply too short for the allocation
to be operationally useful, especially for large organisations.

I have an anecdote to share here: A while back, a techie from a large
organisation in the RIPE region told me that from their point of view,
the RIPE NCC was effectively depleted once they implemented the
three-month period for allocations on the 1st of July 2011, because they
needed more than three months to actually put a new allocation in
production - hence they couldn't justify anything any longer.

When transferring, on the other hand, ARIN's policies allows for
obtaining up to 24 months' worth of space. This gives longer-term
operational predictability, which may easily justify the cost of the
addresses themselves. Same thing goes for deploying CGNs instead - the
organisation is then free to plan as far ahead as it feels like, without
being constrained by ARIN policies. That has a value, possibly more than
the cost of the CGN boxes themselves.

Tore


From streiner at cluebyfour.org  Sun Apr  7 15:43:38 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sun, 7 Apr 2013 11:43:38 -0400 (EDT)
Subject: Verizon DSL moving to CGN
In-Reply-To: <5160CEE8.6010404@derekivey.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
 <5160CEE8.6010404@derekivey.com>
Message-ID: <Pine.LNX.4.64.1304071142460.25482@whammy.cluebyfour.org>

On Sat, 6 Apr 2013, Derek Ivey wrote:

> It would be nice to get an update from them regarding their IPv6 plans. Their 
> IPv6 support page still says they will start deploying "3Q12" :(.

I've been trying to get some information from internal contacts, but so 
far, no go.

jms


From jared at puck.nether.net  Sun Apr  7 17:46:14 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Sun, 7 Apr 2013 13:46:14 -0400
Subject: Open Resolver Dataset Update
Message-ID: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>

I've continued to update my dataset originally posted about two weeks ago.  Please take a moment and review your CIDRs which may be running an open resolver.

I've exposed one additional bit in the user-interface that may be helpful.  Some DNS servers will respond with RCODE=0 (OK) but not provide recursion.  nearly 90% of the servers in the database provide recursion.

Some raw stats are also available via the 'breakdown' link on the main site.

If you operate a DNS server, or have an internal group that does, please take a moment and review your networks.

If you email me in private from a corporate address for your ASN, I can give you access to a per-ASN report.

Due to a change in methodology, I have increased the number of servers observed from 27.2 million to 30.2 million hosts.

2013-04-07 results

30269218 servers responded to our udp/53 probe
731040 servers responded from a different IP than probed
25298074 gave the 'correct' answer to my A? for the DNS name queried.
13840790 responded from a source port other than udp/53
27145699 responses had recursion-available bit set.
2761869 returned REFUSED

In addition, please do continue to deploy BCP-38 to prevent spoofing wherever possible.  I know at $dayjob we have been auditing this and increased the number of customer interfaces that can not spoof.

- Jared

From randy at psg.com  Sun Apr  7 19:00:37 2013
From: randy at psg.com (Randy Bush)
Date: Mon, 08 Apr 2013 04:00:37 +0900
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
Message-ID: <m2y5cu5foq.wl%randy@psg.com>

> Would you be less upset if there was IPv6 access and CPE based DS Lite

ds lite, nat in the core and cpe forklift.  one of the worst mechanisms.

randy


From owen at delong.com  Sun Apr  7 19:25:30 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 7 Apr 2013 12:25:30 -0700
Subject: ICMP Redirect on Resolvers
In-Reply-To: <56427.1365289403@turing-police.cc.vt.edu>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
 <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
 <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmail.com>
 <56427.1365289403@turing-police.cc.vt.edu>
Message-ID: <9377770B-6E4D-4533-A0EB-704BFFF652B4@delong.com>


On Apr 6, 2013, at 16:03 , Valdis.Kletnieks at vt.edu wrote:

> On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:
> 
>> What would break if u dropped all ICMP packets with redirects on public
>> facing boxes?
> 
> Presumably nothing, as long as you guaranteed that your IP address, netmask,
> and routes actually match the reality of your network configuration.  In that
> case, you shouldn't see any valid ICMP redirects.  They're there mostly so
> things kind-of-sort-of work even if you botch it (so for instance, even if you
> whiff your default route accidentally, you can still ssh in from Tokyo and fix
> it).
> 

Not entirely true.

They also cover the case where there are two (or more) routers on the
network and you don't want to have to configure more specific routes
on all your workstations.

For example, network B has routers [A] and [C]. Router [A] leads
to the internet. Router [C] leads to networks R, S,  T, and U.

Hosts on network B can be configured with default->[A] and
as long as [A] and [C] have proper routing information via
IGP, BGP, and/or static routing including all of the more specifics,
then [A] can send back redirects to hosts on network B when they
try to reach networks {R,S,T,U}.

If you block ICMP redirects, then you won't break anything, but you
will increase the traffic load on network B and router [A] as it will
hairpin all of the traffic from those hosts to {R,S,T,U}.

Owen



From owen at delong.com  Sun Apr  7 20:06:54 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 7 Apr 2013 13:06:54 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
Message-ID: <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>


On Apr 7, 2013, at 00:31 , Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Sun, 7 Apr 2013, Fabien Delmotte wrote:
> 
>> CGN is just a solution to save time, it is not a transition mechanism through IPv6
>> At the end (IPv6 at home) you will need at list :
>> Dual stack or NAT64/ DNS64
> 
> CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike).
> 

True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken away from IPv6 deployment.

> My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time.
> 

Not really...

> Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN.
> 

No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with optional injector), USB, or other.

> I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative?

IPv6 deployment _IS_ the alternative. They are not orthogonal.

Owen



From oliver at g.garraux.net  Sun Apr  7 22:43:25 2013
From: oliver at g.garraux.net (Oliver Garraux)
Date: Sun, 7 Apr 2013 18:43:25 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
Message-ID: <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>

If I'm an ISP deploying a network for users today, I effectively have to
provide some mechanism to allow those users to get to IPv4 only content.
 There is way too much stuff out there that is IPv4 only today.

Yes, content providers should provide IPv6 access....but if I'm an ISP, I
can't really control that aspect.  If I provide users with a service that
isn't able to connect to 80% of websites (to say nothing of VPN's,
corporate email services, etc, that people may need), I'm not going to have
a whole lot of business.

Now - I completely agree that ISP's must start deploying IPv6 natively.
 Legacy equipment that doesn't support IPv6 is not an acceptable
excuse....its just evidence of poor decision making and short-sighed
purchasing decisions.  CGN clearly isn't ideal and doesn't mitigate the
need for native IPv6 connectivity.  But right now, native IPv6 connectivity
is still not a substitute for some level of IPv4 connectivity, even if its
CGN'ed.

Oliver

-------------------------------------

Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux


On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong <owen at delong.com> wrote:

>
> On Apr 7, 2013, at 00:31 , Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>
> > On Sun, 7 Apr 2013, Fabien Delmotte wrote:
> >
> >> CGN is just a solution to save time, it is not a transition mechanism
> through IPv6
> >> At the end (IPv6 at home) you will need at list :
> >> Dual stack or NAT64/ DNS64
> >
> > CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the
> water without other mechanisms (464XLAT or alike).
> >
>
> True... But... Resources deploying/maintaining all of these keep
> IPv4-limping along technologies are resources taken away from IPv6
> deployment.
>
> > My point is that people seem to scoff at CGN. There is nothing stopping
> anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address
> exhaustion), then giving dual stack for end users can be done at any time.
> >
>
> Not really...
>
> > Face it, we're running out of IPv4 addresses. For basic Internet
> subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a
> completely different problem that has little bearing on CGN or not for
> IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP
> is also CGN.
> >
>
> No, it really isn't. Sufficient IPv6 deployment at the content side would
> actually allow the subscriber side to be IPv4 or dual-stack for existing
> customers with new customers receiving IPv6-only. The missing piece there
> is actually the set-top coversion unit for IPv4-only devices. (Ideally, a
> dongle which can be plugged into the back of an IPv4-only device with an
> IPv6-only jack on the other side. Power could be done a number of ways,
> including POE (with optional injector), USB, or other.
>
> > I'm ok with people complaining about lack of IPv6 deployment, but I
> don't understand people complaining about CGN. What's the alternative?
>
> IPv6 deployment _IS_ the alternative. They are not orthogonal.
>
> Owen
>
>
>

From wwarren at emmanuelcomputerconsulting.com  Sun Apr  7 22:28:49 2013
From: wwarren at emmanuelcomputerconsulting.com (William Warren)
Date: Sun, 07 Apr 2013 18:28:49 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>,
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>
Message-ID: <5161F321.2000101@emmanuelcomputerconsulting.com>

On 4/6/2013 11:33 PM, Huasong Zhou wrote:
> I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.
>
> Joe
>
> Sent from my iPhone
>
> On Apr 6, 2013, at 9:33 PM, "Joshua Smith" <juicewvu at gmail.com> wrote:
>
>> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer.
>>
>> -- 
>> Josh Smith
>> kD8HRX
>>
>> email/jabber: juicewvu at gmail.com
>> Phone: 304.237.9369(c)
>>
>> Sent from my iPad
>>
>>
>> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>>
>>> Interesting.
>>>
>>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
if you are a business customer your modem is actually a business grade 
NAT router.  If they are using CGN(which doesn't make sense as i can 
pull an ipv6 addy here on dhcp) it's either a misconfiguration or 
something else going on.


From rajiva at cisco.com  Mon Apr  8 01:11:42 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 01:11:42 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>, 
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>,
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>
Message-ID: <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>

Nope. Comcast is not using any CGN, as much as I know.

Is your MacBook directly connected to the modem or a router? I presume the latter.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 11:47 AM, "Huasong Zhou" <huasong at kalorama.com> wrote:

> I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.
> 
> Joe
> 
> Sent from my iPhone
> 
> On Apr 6, 2013, at 9:33 PM, "Joshua Smith" <juicewvu at gmail.com> wrote:
> 
>> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. 
>> 
>> -- 
>> Josh Smith
>> kD8HRX
>> 
>> email/jabber: juicewvu at gmail.com
>> Phone: 304.237.9369(c)
>> 
>> Sent from my iPad
>> 
>> 
>> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>> 
>>> Interesting.
>>> 
>>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
> 


From rajiva at cisco.com  Mon Apr  8 01:18:07 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 01:18:07 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
Message-ID: <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>

> DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN.

Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP doesn't require any CGN that causes the SP network to put up with the NAT state. This means that all the subsequent issues of CGN/DS-Lite no longer apply. 

MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 3:33 AM, "Mikael Abrahamsson" <swmike at swm.pp.se> wrote:

> On Sun, 7 Apr 2013, Fabien Delmotte wrote:
> 
>> CGN is just a solution to save time, it is not a transition mechanism through IPv6
>> At the end (IPv6 at home) you will need at list :
>> Dual stack or NAT64/ DNS64
> 
> CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike).
> 
> My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time.
> 
> Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN.
> 
> I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative?
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
> 


From rajiva at cisco.com  Mon Apr  8 01:21:26 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 01:21:26 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>,
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
Message-ID: <D32862E0-A3AB-4E41-94F8-1939A9B84CF5@cisco.com>

Dual-stack in the home networks will stay with us for a long time (beyond 2020!) until v4-only user devices and v4-only apps get refreshed.

Of course, this doesn't mean that the ISP access needs to stay dual-stack, thanks to MAP, 464XLAT etc.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 3:15 AM, "Fabien Delmotte" <fdelmotte1 at mac.com> wrote:

> CGN is just a solution to save time, it is not a transition mechanism through IPv6
> At the end (IPv6 at home) you will need at list :
> Dual stack or NAT64/ DNS64
> 
> My 2 cents
> 
> On Apr 7, 2013, at 8:42 AM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
>> On Sun, 7 Apr 2013, Christopher Morrow wrote:
>> 
>>> I wonder how much more painful just upgrading the dsl plant to support v6 would be vs deploying the cgn equipment and funneling users through that :(
>> 
>> IPv6 deployment is not a short term solution to IPv4 address depletion. Would you be less upset if there was IPv6 access and CPE based DS Lite (ie your IPv4 is still CGN:ed, just in a different way)?
>> 
>> CGN is here to stay for IPv4. The solution for long term Internet growth is IPv6.
>> 
>> -- 
>> Mikael Abrahamsson    email: swmike at swm.pp.se
> 


From rajiva at cisco.com  Mon Apr  8 01:38:13 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 01:38:13 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>,
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
Message-ID: <8E93DDA1-FCC2-4D4B-9194-B8E45514DE5C@cisco.com>

In all fairness, upgrading the legacy last-mile e.g. DSL infrastructure to support native IPv6 may be too expensive to make any economic sense.

Note that Vz FiOS users are not affected by this. And noting that Vz has ~5.5M FiOS HSI customers and ~3M DSL customers (per the last earning report), and noting that DSL network is not getting any new investment (in fact, customers are being moved from DSL to FiOS), the CGN usage for DSL customers isn't quite surprising.
http://stopthecap.com/2012/08/20/verizon-declares-copper-dead-quietly-moving-copper-customers-to-fios-network/


Many ISPs around the world are choosing to not to invest in the DSL network the way they used to.

Cheers,
Rajiv

Sent from my Phone

On Apr 6, 2013, at 10:13 PM, "Constantine A. Murenin" <mureninc at gmail.com<mailto:mureninc at gmail.com>> wrote:

On 6 April 2013 18:24, cb.list6 <cb.list6 at gmail.com<mailto:cb.list6 at gmail.com>> wrote:
Interesting.

http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm

<blockquote>

What is  CGN - and How to opt-out The number and types of devices using the Internet have increased dramatically in recent years and, as a result, address space for these devices is being rapidly exhausted. Today?s technology for IP addresses is referred to as IPv4 (Internet Protocol version 4). The IP addresses aligned with IPv4 are expected to be depleted at some point in the near future. The next generation of IP address space is IPv6, which will enable far more addresses to be assigned than IPv4. Unfortunately, most servers and other Internet devices will not be speaking IPv6 for a while, so IPv4 will remain standard for some time to come.

During this transitional period, in select areas for High Speed Internet residential customers, Verizon will be implementing Carrier Grade Network Address Translation (CGN or Carrier Grade NAT). Verizon FiOS and Verizon Business customers are not impacted at this time by the change. This transition will enable Verizon to continue serving customers with IPv4 internet addresses. CGN will not impact the access, reliability, speed, or security of Verizon?s broadband services. However, there are some applications such as online gaming, VPN access, FTP service, surveillance cameras, etc., that may not work when broadband service is provided via a CGN.

For our customers utilizing these types of applications, Verizon provides the ability to "opt out ?of CGN. To "opt out" you must:

   Be a Residential customer with High Speed Internet Service. There is no need to ?opt-out? if you are a FiOS or Business customer.
   Have already been transitioned to the Carrier Grade Network by Verizon. If you are a Residential High Speed Internet customer and are unable to opt-out, it is likely that you have not yet been transitioned to CGN.


To "opt out" of CGN sign onto your My Verizon account and select "Opt out of Carrier Grade Network".

</blockquote>


I like how, according to the document, Verizon must first break your
connectivity, prior to you being able to opt-out. :-)

Also:

select "Opt out of Carrier Grade Network"

Smart wording. :-)

Frankly, I'm surprised to see this news.  I thought Verizon had better
things to do that plan any kind of upgrades or changes to something
that everyone thought they consider dead anyways.

C.


From Valdis.Kletnieks at vt.edu  Mon Apr  8 01:47:24 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 07 Apr 2013 21:47:24 -0400
Subject: ICMP Redirect on Resolvers
In-Reply-To: Your message of "Sun, 07 Apr 2013 12:25:30 -0700."
 <9377770B-6E4D-4533-A0EB-704BFFF652B4@delong.com>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
 <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
 <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmai.com>
 <56427.1365289403@turing-police.cc.vt.edu>
 <9377770B-6E4D-4533-A0EB-704BFFF652B4@delong.com>
Message-ID: <121192.1365385644@turing-police.cc.vt.edu>

On Sun, 07 Apr 2013 12:25:30 -0700, Owen DeLong said:

> > Presumably nothing, as long as you guaranteed that your IP address, netmask,
> > and routes actually match the reality of your network configuration.

> They also cover the case where there are two (or more) routers on the
> network and you don't want to have to configure more specific routes
> on all your workstations.

As I said - if your config (including routes) matches your network reality.
Note that the rest of your comment addresses the case where your initial config
doesn't match reality...

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

From jra at baylink.com  Mon Apr  8 02:05:35 2013
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 7 Apr 2013 22:05:35 -0400 (EDT)
Subject: Verizon DSL moving to CGN
In-Reply-To: <8E93DDA1-FCC2-4D4B-9194-B8E45514DE5C@cisco.com>
Message-ID: <5183059.1298.1365386735432.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Rajiv Asati (rajiva)" <rajiva at cisco.com>

> Note that Vz FiOS users are not affected by this. And noting that Vz
> has ~5.5M FiOS HSI customers and ~3M DSL customers (per the last
> earning report), and noting that DSL network is not getting any new
> investment (in fact, customers are being moved from DSL to FiOS), the
> CGN usage for DSL customers isn't quite surprising.

> http://stopthecap.com/2012/08/20/verizon-declares-copper-dead-quietly-moving-copper-customers-to-fios-network/

Well, that's as may be, but since Vzn has also declared *on the record, at
least 2 years ago* that they're done with FiOS -- they ain't building no
more of it, if you don't have it, sorry for your luck (except maybe in KC
and Austin) -- I don't know if that helps them any.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From John_Brzozowski at Cable.Comcast.com  Mon Apr  8 02:12:27 2013
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Mon, 8 Apr 2013 02:12:27 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>, 
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>,
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>,
 <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
Message-ID: <BD87928F6BFAEF4EBEB883E1C4F587723417887D@PACDCEXMB01.cable.comcast.com>

I can confirm CGN has not been deployed for Comcast customers.

=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
e) mailto:john_brzozowski at cable.comcast.com
o) 484-962-0060
w) http://www.comcast6.net
=========================================

________________________________________
From: Rajiv Asati (rajiva) [rajiva at cisco.com]
Sent: Sunday, April 07, 2013 21:11
To: Huasong Zhou
Cc: Joshua Smith; nanog at nanog.org
Subject: Re: Verizon DSL moving to CGN

Nope. Comcast is not using any CGN, as much as I know.

Is your MacBook directly connected to the modem or a router? I presume the latter.

Cheers,
Rajiv

Sent from my Phone

On Apr 7, 2013, at 11:47 AM, "Huasong Zhou" <huasong at kalorama.com> wrote:

> I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.
>
> Joe
>
> Sent from my iPhone
>
> On Apr 6, 2013, at 9:33 PM, "Joshua Smith" <juicewvu at gmail.com> wrote:
>
>> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer.
>>
>> --
>> Josh Smith
>> kD8HRX
>>
>> email/jabber: juicewvu at gmail.com
>> Phone: 304.237.9369(c)
>>
>> Sent from my iPad
>>
>>
>> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>>
>>> Interesting.
>>>
>>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
>


From sam at themerritts.org  Mon Apr  8 02:56:40 2013
From: sam at themerritts.org (Sam Hayes Merritt, III)
Date: Sun, 7 Apr 2013 21:56:40 -0500 (CDT)
Subject: Verizon DSL moving to CGN
In-Reply-To: <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
Message-ID: <alpine.DEB.2.02.1304072149280.26083@sam>


> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled 
> access. MAP makes much more sense in any SP network having its internet 
> customers do IPv4 address sharing and embrace IPv6.

What may make 'much more sense' in one network, doesn't necessarily make 
as much since in another network. As I understand it, MAP requires at 
least a software change on existing CPE, if not wholesale CPE change. 
Some providers may prefer to implement CGN instead if the capital outlay 
is less (and providing new CPE to customers through walkins or truck rolls 
can be problematic).

Our plan for my company at this time is to deploy native IPv4+IPv6 to 
all customers. While we are doing that, continue discussions and testing 
with CGN providers so that when we are unable to obtain anymore IPv4 
addresses, we can then deploy CGN. Our hope is that we never get to the 
point of having to go CGN but we have to be ready in case that day comes 
and have our implementation and opt-out (if available) processes ready.


What devices does Cisco support MAP on? Specifically, does the DPC3827 
support it?


sam


From owen at delong.com  Mon Apr  8 05:32:48 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 7 Apr 2013 22:32:48 -0700
Subject: ICMP Redirect on Resolvers
In-Reply-To: <121192.1365385644@turing-police.cc.vt.edu>
References: <CAGqGmqZS9fPpDjb_+yc0yF2gs2DxdpFo-cjYsbWVjc5diFmetg@mail.gmail.com>
 <14e63cd0c8c87949baf00597335cc9ac@mail.dessus.com>
 <CAAAwwbXKePOGTnWpGEfHYubJ5ef9_Fb0K-F3BB8yu9xETb8HKw@mail.gmail.com>
 <CAH_OBid59G4_MXvJ06uG7=y13woPf1hJYRPOywBW__aZ5j3S7Q@mail.gmai.com>
 <56427.1365289403@turing-police.cc.vt.edu>
 <9377770B-6E4D-4533-A0EB-704BFFF652B4@delong.com>
 <121192.1365385644@turing-police.cc.vt.edu>
Message-ID: <B4B3E8B4-B384-47E7-BAD7-F535E9E81586@delong.com>


On Apr 7, 2013, at 18:47 , Valdis.Kletnieks at vt.edu wrote:

> On Sun, 07 Apr 2013 12:25:30 -0700, Owen DeLong said:
> 
>>> Presumably nothing, as long as you guaranteed that your IP address, netmask,
>>> and routes actually match the reality of your network configuration.
> 
>> They also cover the case where there are two (or more) routers on the
>> network and you don't want to have to configure more specific routes
>> on all your workstations.
> 
> As I said - if your config (including routes) matches your network reality.
> Note that the rest of your comment addresses the case where your initial config
> doesn't match reality...
> 

Not true. Reality is that the default router configured on the hosts is capable
of getting the packets delivered. It's not optimal, but it is reality.

Owen



From owen at delong.com  Mon Apr  8 05:38:42 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 7 Apr 2013 22:38:42 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <D32862E0-A3AB-4E41-94F8-1939A9B84CF5@cisco.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>,
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <D32862E0-A3AB-4E41-94F8-1939A9B84CF5@cisco.com>
Message-ID: <9C7612FD-15A2-4B63-A1B5-0957C0D34ECE@delong.com>


On Apr 7, 2013, at 18:21 , Rajiv Asati (rajiva) <rajiva at cisco.com> wrote:

> Dual-stack in the home networks will stay with us for a long time (beyond 2020!) until v4-only user devices and v4-only apps get refreshed.

I disagree. I think that v4-only apps and devices will get relegated to being connected through v4-v6 adapter appliances until they are fixed.

IPv4 is simply going to become far too expensive to maintain to be able to deliver it for residential pricing.

> Of course, this doesn't mean that the ISP access needs to stay dual-stack, thanks to MAP, 464XLAT etc.
> 

Right... Those are some of the ways that maintaining IPv4 will become so expensive. ;-)

Owen



From owen at delong.com  Mon Apr  8 05:36:01 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 7 Apr 2013 22:36:01 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
Message-ID: <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com>


On Apr 7, 2013, at 15:43 , Oliver Garraux <oliver at g.garraux.net> wrote:

> If I'm an ISP deploying a network for users today, I effectively have to provide some mechanism to allow those users to get to IPv4 only content.  There is way too much stuff out there that is IPv4 only today.
> 

Agreed... However...

> Yes, content providers should provide IPv6 access....but if I'm an ISP, I can't really control that aspect.  If I provide users with a service that isn't able to connect to 80% of websites (to say nothing of VPN's, corporate email services, etc, that people may need), I'm not going to have a whole lot of business.
> 

I was responding to Mikael's claim that pushing content providers to deploy IPv6 was orthogonal to the need for CGN.

Clearly your statement here indicates that you see my point that it is NOT orthogonal, but, in fact the failure of content providers to deploy IPv6 _IS_ the driving cause for CGN.

> Now - I completely agree that ISP's must start deploying IPv6 natively.  Legacy equipment that doesn't support IPv6 is not an acceptable excuse....its just evidence of poor decision making and short-sighed purchasing decisions.  CGN clearly isn't ideal and doesn't mitigate the need for native IPv6 connectivity.  But right now, native IPv6 connectivity is still not a substitute for some level of IPv4 connectivity, even if its CGN'ed.

I don't disagree. You are actually making the exact point I was attempting to make. The need for CGN is not divorced from the failure to deploy IPv6, it is caused by it.

Owen

> 
> Oliver
> 
> -------------------------------------
> 
> Oliver Garraux
> Check out my blog:  blog.garraux.net
> Follow me on Twitter:  twitter.com/olivergarraux
> 
> 
> On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong <owen at delong.com> wrote:
> 
> On Apr 7, 2013, at 00:31 , Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
> > On Sun, 7 Apr 2013, Fabien Delmotte wrote:
> >
> >> CGN is just a solution to save time, it is not a transition mechanism through IPv6
> >> At the end (IPv6 at home) you will need at list :
> >> Dual stack or NAT64/ DNS64
> >
> > CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike).
> >
> 
> True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken away from IPv6 deployment.
> 
> > My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time.
> >
> 
> Not really...
> 
> > Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN.
> >
> 
> No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with optional injector), USB, or other.
> 
> > I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative?
> 
> IPv6 deployment _IS_ the alternative. They are not orthogonal.
> 
> Owen
> 
> 
> 


From swmike at swm.pp.se  Mon Apr  8 06:24:08 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 8 Apr 2013 08:24:08 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com>
Message-ID: <alpine.DEB.2.00.1304080815491.23668@uplift.swm.pp.se>

On Sun, 7 Apr 2013, Owen DeLong wrote:

> I don't disagree. You are actually making the exact point I was 
> attempting to make. The need for CGN is not divorced from the failure to 
> deploy IPv6, it is caused by it.

Absolutely. That doesn't mean that any individual ISP right now can choose 
to *not* implement CGN and deploy IPv6. That won't solve IPv4 address 
depletion *for that ISP*.

This is an industry-wide failure that no individual part of the industry 
can work around. For most ISPs, deploying some kind of CGN is the only 
rational decision at this time.

We can discuss what could have should have happened earlier, but now we're 
here. Yes, ISPs should deploy IPv6. Everybody should deploy IPv6.

But I still believe that CGN is mostly orthogonal to IPv6 deployment. 
Saying ISPs today are wrong to deploy CGN and that they should deploy IPv6 
(the word "instead" is usually not there, but it still seems to be 
implied), I just don't understand that argument.

Is it just that the ISP in question hasn't announced their IPv6 plans in 
the same announcement that is the problem? So that people believe CGN is 
part of a future-proof strategy?

So if the ISP says "we're going to deploy CGN for select customers during 
2H-2013 due to IPv4 run-out, and at the same time we're planning to start 
rolling out IPv6 for customers who have upgradable equipment", does that 
help? If the ISP has been around for a while, it's still a huge part of 
the customer base that won't be upgradable, and those customers will be 
stuck behind NAT444 until they do something.

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


From tore at fud.no  Mon Apr  8 06:27:17 2013
From: tore at fud.no (Tore Anderson)
Date: Mon, 08 Apr 2013 08:27:17 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com>
Message-ID: <51626345.40106@fud.no>

* Owen DeLong

> The need for CGN is not divorced from the failure to deploy IPv6, it
> is caused by it.

In a historical context, this is true enough. If we had accomplished
ubiquitous IPv6 deployment ten years ago, there would be no IPv4
depletion, and there would be no CGN. However, that ship has sailed long
ago. You're using present tense where you should have used past.

> I was responding to Mikael's claim that pushing content providers to
> deploy IPv6 was orthogonal to the need for CGN.

If we put down the history books and focus on today's operational
realities, it *is* orthogonal. If you're an ISP fresh out of IPv4
addresses today, "pushing content providers to deploy IPv6" is simply
not a realistic strategy to deal with it. CGN is.

> Clearly your statement here indicates that you see my point that it
> is NOT orthogonal, but, in fact the failure of content providers to
> deploy IPv6 _IS_ the driving cause for CGN.

I'm not sure why you are singling out content providers, BTW. There are
no shortage of other things out there that have an absolute hard
requirement on IPv4 to function properly. Gaming consoles, Android
phones and tables, iOS phones and tablets[1], home gateways, software
and apps, embedded devices, ... - the list goes on and on.

If the only missing piece of the puzzle was the lack of IPv6 support at
the content providers' side, IPv6+NAT64 would constitute a perfectly
viable residential/cellular internet service. As far as I know, however,
not a single provider is seriously considering this strategy going
forward. That's telling.

Tore

[1] From what I hear, anyway. They used to work fine on IPv6-only
wireless networks, I've seen it myself, but I've been told that it's
taken a turn for the worse over the course of the last year.


From tom.laermans at phyxia.net  Mon Apr  8 07:08:41 2013
From: tom.laermans at phyxia.net (Tom Laermans)
Date: Mon, 08 Apr 2013 09:08:41 +0200
Subject: Open Resolver Dataset Update
In-Reply-To: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
Message-ID: <51626CF9.1040109@phyxia.net>

On 7/04/2013 19:46, Jared Mauch wrote:
> I've continued to update my dataset originally posted about two weeks ago.  Please take a moment and review your CIDRs which may be running an open resolver.
>
> I've exposed one additional bit in the user-interface that may be helpful.  Some DNS servers will respond with RCODE=0 (OK) but not provide recursion.  nearly 90% of the servers in the database provide recursion.
What is the rationale behind listing servers not providing recursion on 
a list of open resolvers?

As far as I know, responding either NOERROR or REFUSED produces packets 
of the same size.

Tom


From marka at isc.org  Mon Apr  8 07:55:52 2013
From: marka at isc.org (Mark Andrews)
Date: Mon, 08 Apr 2013 17:55:52 +1000
Subject: Open Resolver Dataset Update
In-Reply-To: Your message of "Mon, 08 Apr 2013 09:08:41 +0200."
 <51626CF9.1040109@phyxia.net>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
 <51626CF9.1040109@phyxia.net>
Message-ID: <20130408075552.7D9403219EB1@drugs.dv.isc.org>


In message <51626CF9.1040109 at phyxia.net>, Tom Laermans writes:
> On 7/04/2013 19:46, Jared Mauch wrote:
> > I've continued to update my dataset originally posted about two weeks ago.  Please take a moment
>  and review your CIDRs which may be running an open resolver.
> >
> > I've exposed one additional bit in the user-interface that may be helpful.  Some DNS servers wil
> l respond with RCODE=0 (OK) but not provide recursion.  nearly 90% of the servers in the database 
> provide recursion.
> What is the rationale behind listing servers not providing recursion on 
> a list of open resolvers?
> 
> As far as I know, responding either NOERROR or REFUSED produces packets 
> of the same size.
> 
> Tom

NOERROR can be a referral.
-- 
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 Apr  8 08:41:34 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Apr 2013 01:41:34 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <51626345.40106@fud.no>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com> <51626345.40106@fud.no>
Message-ID: <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>


On Apr 7, 2013, at 23:27 , Tore Anderson <tore at fud.no> wrote:

> * Owen DeLong
> 
>> The need for CGN is not divorced from the failure to deploy IPv6, it
>> is caused by it.
> 
> In a historical context, this is true enough. If we had accomplished
> ubiquitous IPv6 deployment ten years ago, there would be no IPv4
> depletion, and there would be no CGN. However, that ship has sailed long
> ago. You're using present tense where you should have used past.
> 

Respectfully, I disagree. If the major content providers were to deploy
IPv6 within the next 6 months (pretty achievable even now), then the
need for CGN would at least be very much reduced, if not virtually
eliminated.

>> I was responding to Mikael's claim that pushing content providers to
>> deploy IPv6 was orthogonal to the need for CGN.
> 
> If we put down the history books and focus on today's operational
> realities, it *is* orthogonal. If you're an ISP fresh out of IPv4
> addresses today, "pushing content providers to deploy IPv6" is simply
> not a realistic strategy to deal with it. CGN is.
> 

This does not represent a reason to stop pushing content providers. While
CGN may be a necessary stop-gap measure today for some, there are
many more who aren't facing that decision for a few months. Even for those
that do have to deploy it, the reality is that CGN is fragile, unwieldy, expensive,
and high-maintenance. Further, it provides a lousy customer experience.

The less you have to depend on CGN as an ISP, the better your life will be.

As such, it is even more vital today than it was in history to keep the pressure
for IPv6 content strong.

>> Clearly your statement here indicates that you see my point that it
>> is NOT orthogonal, but, in fact the failure of content providers to
>> deploy IPv6 _IS_ the driving cause for CGN.
> 
> I'm not sure why you are singling out content providers, BTW. There are
> no shortage of other things out there that have an absolute hard
> requirement on IPv4 to function properly. Gaming consoles, Android
> phones and tables, iOS phones and tablets[1], home gateways, software
> and apps, embedded devices, ... - the list goes on and on.

All of those things are actually driven primarily by content. iOS phones and
tables are perfectly capable of IPv6 where IPv6 is available over WiFi.
iPhone 5 can do IPv6 over the carrier network. I know, my iPhone 5 works
great with IPv6 on its network. Home gateways are going to need to be
replaced. There are plenty of them that do support IPv6.

Gaming consoles are entirely under the control of content providers.
Most of the embedded devices are either going to need to be replaced
over time, upgraded, or we're going to need some form of set-top box
to deal with them in the future.

Bottom line, content providers are the low-hanging fruit in terms of the
easiest and fastest way to have the biggest impact in reducing the need
for and load on CGN deployments.

> If the only missing piece of the puzzle was the lack of IPv6 support at
> the content providers' side, IPv6+NAT64 would constitute a perfectly
> viable residential/cellular internet service. As far as I know, however,
> not a single provider is seriously considering this strategy going
> forward. That's telling.

It's not the only piece, just the easiest one to solve immediately with the
biggest payoff.

> 
> Tore
> 
> [1] From what I hear, anyway. They used to work fine on IPv6-only
> wireless networks, I've seen it myself, but I've been told that it's
> taken a turn for the worse over the course of the last year.

Actually it took a brief turn for the worse due to a bug which has now
been (partially) resolved. Apparently the phones used to prefer
IPv6 over carrier if they were on a wireless v4-only network which
ran up some (startling) data charges for some users.

Now they've made it so that if you have a wifi connection, you simply
won't use the cellular network no matter what. This unfortunately means
that you cannot surf an IPv6-only site while you are connected to an
IPv4-only wifi network even if you have dual-stack carrier connectivity,
but I think that's a reasonable tradeoff for now.

Prior to this latest software/carrier settings update, they had simply turned
off IPv6 on the carrier side, but the wifi side has always worked since
one of the later versions of IOS4 or one of the earlier versions of IOS5,
I forget which.

Owen



From simon at slimey.org  Mon Apr  8 08:53:20 2013
From: simon at slimey.org (Simon Lockhart)
Date: Mon, 8 Apr 2013 09:53:20 +0100
Subject: Verizon DSL moving to CGN
In-Reply-To: <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
References: <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com> <51626345.40106@fud.no>
 <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
Message-ID: <20130408085319.GA21281@virtual.bogons.net>

On Mon Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong wrote:
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.

Surely the case is that you've still got the same number of users who need an
IPv4 address to be able to access "legacy" IPv4 sites on the Internet - until
100% of content is accessible via IPv6.

What it does, however, change is the amount of traffic which would need to 
flow through a CGN box.

Unfortunately, CGN is here until either everything is available over IPv6, or
a better version of NAT64 which doesn't depend on DNS rewriting is designed
and deployed.

Simon


From arturo.servin at gmail.com  Mon Apr  8 09:54:14 2013
From: arturo.servin at gmail.com (Arturo Servin)
Date: Mon, 08 Apr 2013 10:54:14 +0100
Subject: Verizon DSL moving to CGN
In-Reply-To: <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com> <51626345.40106@fud.no>
 <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
Message-ID: <516293C6.3080507@gmail.com>



On 4/8/13 9:41 AM, Owen DeLong wrote:
> On Apr 7, 2013, at 23:27 , Tore Anderson <tore at fud.no> wrote:
> 
>> > * Owen DeLong
>> > 
>>> >> The need for CGN is not divorced from the failure to deploy IPv6, it
>>> >> is caused by it.
>> > 
>> > In a historical context, this is true enough. If we had accomplished
>> > ubiquitous IPv6 deployment ten years ago, there would be no IPv4
>> > depletion, and there would be no CGN. However, that ship has sailed long
>> > ago. You're using present tense where you should have used past.
>> > 
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.
> 


	I though that they have done it last year around June 8th.  ;-)

	In fact, the need for CGN has been reduced if you count that 30-40% of
your traffic would go to those places. Although CGN is going to be a
necessary evil, deploying CGN without IPv6 would be a mistake IMHO.

/as


From swmike at swm.pp.se  Mon Apr  8 10:01:24 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 8 Apr 2013 12:01:24 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
Message-ID: <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>

On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:

> Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP 
> doesn't require any CGN that causes the SP network to put up with the 
> NAT state. This means that all the subsequent issues of CGN/DS-Lite no 
> longer apply.

For me as an operator, MAP is most likely going to be implemented in a 
CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow 
traffic through a dedicated box because MAP won't be implemented in my 
regular routers (if you know otherwise, please speak up).

> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled 
> access. MAP makes much more sense in any SP network having its internet 
> customers do IPv4 address sharing and embrace IPv6.

It's still NAT.

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


From tore at fud.no  Mon Apr  8 10:29:31 2013
From: tore at fud.no (Tore Anderson)
Date: Mon, 08 Apr 2013 12:29:31 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
Message-ID: <51629C0B.30801@fud.no>

* Mikael Abrahamsson

> On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
> 
>> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
>> access. MAP makes much more sense in any SP network having its
>> internet customers do IPv4 address sharing and embrace IPv6.
> 
> It's still NAT.

AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
tunneling, pure encap/decap plus a clever way to calculate the outer
IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
inner IPv4 packets are not modified by the centralised MAP tunneling
routers, so there is no "Network Address Translation" being performed.

The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
component though, so there is some NAT involved in the overall solution,
but it's pretty much the same as what we have in today's CPEs/HGWs. The
only significant difference is that a MAP CPE must be prepared to not
being able to use all the 65536 source ports.

Tore



From tore at fud.no  Mon Apr  8 10:59:32 2013
From: tore at fud.no (Tore Anderson)
Date: Mon, 08 Apr 2013 12:59:32 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com> <51626345.40106@fud.no>
 <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
Message-ID: <5162A314.4010904@fud.no>

* Owen DeLong

> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.

I agree with "very much reduced". However, and IMHO, "virtually
eliminated" is completely unrealistic.

> The less you have to depend on CGN as an ISP, the better your life will be.
> 
> As such, it is even more vital today than it was in history to keep the pressure
> for IPv6 content strong.
[...]
> Bottom line, content providers are the low-hanging fruit in terms of the
> easiest and fastest way to have the biggest impact in reducing the need
> for and load on CGN deployments.
> 
>> If the only missing piece of the puzzle was the lack of IPv6 support at
>> the content providers' side, IPv6+NAT64 would constitute a perfectly
>> viable residential/cellular internet service. As far as I know, however,
>> not a single provider is seriously considering this strategy going
>> forward. That's telling.
> 
> It's not the only piece, just the easiest one to solve immediately with the
> biggest payoff.

I agree fully that the continued deployment of IPv6 on the content side
and all other places is a benefit to any ISP that is providing IPv6 to
their subscribers alongside CGN. The payoff is reduced customer
unhappiness due to the effects of CGN, and reducing the amount of
investment in CGN necessary.

But the payoff is not going to be avoiding to have to implement CGN (or
similar IPv4 life-support mechanisms, including MAP) in the first place,
no matter how hard one pushes for IPv6. In order for that that to be the
case, *all* the missing pieces must fall in place, not only the
biggest/easiest ones -  and there's simply too many small and tricky
ones left, and too little time. I cannot see any realistic outcome of
the ordeal we're currently in that does not include CGN or similar stuff
to handle the long tail of IPv4-only stuff. It's simply too late for
IPv6 to prevent CGN.

I'd be absolutely delighted, though, if I'm wrong and you're able to say
to me a few years from now ?I told you so?! :-)

Tore


From swmike at swm.pp.se  Mon Apr  8 11:00:38 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 8 Apr 2013 13:00:38 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <51629C0B.30801@fud.no>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no>
Message-ID: <alpine.DEB.2.00.1304081254100.23668@uplift.swm.pp.se>

On Mon, 8 Apr 2013, Tore Anderson wrote:

> * Mikael Abrahamsson
>
>> On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
>>
>>> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
>>> access. MAP makes much more sense in any SP network having its
>>> internet customers do IPv4 address sharing and embrace IPv6.
>>
>> It's still NAT.
>
> AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
> tunneling, pure encap/decap plus a clever way to calculate the outer
> IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
> inner IPv4 packets are not modified by the centralised MAP tunneling
> routers, so there is no "Network Address Translation" being performed.

This is all splitting hairs. Yes, the outside port addresses do not change 
but however the src/dst addresses change (=translated), right? Does anyone 
see MAP-E being implemented on regular linecards or is it going to be 
implemented on processor based dedicated hardware? At least initially, I 
would just assume it's going to be some kind of CGN blade.

> The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 
> component though, so there is some NAT involved in the overall solution, 
> but it's pretty much the same as what we have in today's CPEs/HGWs. The 
> only significant difference is that a MAP CPE must be prepared to not 
> being able to use all the 65536 source ports.

Yes, MAP-E needs CPE support, thus hard to deploy short term. Long term, 
yes, really nice. Perfect for long tail IPv4 reachability over IPv6 access 
networks.

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


From jared at puck.nether.net  Mon Apr  8 11:05:20 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 8 Apr 2013 07:05:20 -0400
Subject: Open Resolver Dataset Update
In-Reply-To: <51626CF9.1040109@phyxia.net>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
 <51626CF9.1040109@phyxia.net>
Message-ID: <BCCE3736-E0D5-4F52-9A09-87D79F0CD156@puck.nether.net>

The referral, including a referral to root can be quite large. Even larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. 

Jared Mauch

On Apr 8, 2013, at 3:08 AM, Tom Laermans <tom.laermans at phyxia.net> wrote:

> As far as I know, responding either NOERROR or REFUSED produces packets of the same size.


From tore at fud.no  Mon Apr  8 11:40:25 2013
From: tore at fud.no (Tore Anderson)
Date: Mon, 08 Apr 2013 13:40:25 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304081254100.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no>
 <alpine.DEB.2.00.1304081254100.23668@uplift.swm.pp.se>
Message-ID: <5162ACA9.1050508@fud.no>

* Mikael Abrahamsson

> On Mon, 8 Apr 2013, Tore Anderson wrote:
> 
>> AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
>> tunneling, pure encap/decap plus a clever way to calculate the outer
>> IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
>> inner IPv4 packets are not modified by the centralised MAP tunneling
>> routers, so there is no "Network Address Translation" being performed.
> 
> This is all splitting hairs. Yes, the outside port addresses do not
> change but however the src/dst addresses change (=translated), right?

There is no outside port addresses. The Next Header field in the outside
IPv6 header is set to 4 (i.e., what follows next is an IPv4 header).
This inner IPv4 header (and the payload following it) is the original
one and completely unmodified and not translated/rewritten in any way by
the ISP's MAP gateway. AIUI, anyway.

So unless you mean that the src/dst address "change" or "are translated"
due to the addresses in the outer IPv6 header are not the same as in the
inner IPv4 header, there is simply is no translation happening here.

If this is to be called "translation", then any tunneling mechanism that
works by stacking layer-3 headers, including GRE, IPIP, ESP, and
proto-41, must be also called "translation".

> Does anyone see MAP-E being implemented on regular linecards or is it
> going to be implemented on processor based dedicated hardware? At least
> initially, I would just assume it's going to be some kind of CGN blade.

No idea, sorry.

Tore


From tore at fud.no  Mon Apr  8 11:56:34 2013
From: tore at fud.no (Tore Anderson)
Date: Mon, 08 Apr 2013 13:56:34 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162ACA9.1050508@fud.no>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no>
 <alpine.DEB.2.00.1304081254100.23668@uplift.swm.pp.se>
 <5162ACA9.1050508@fud.no>
Message-ID: <5162B072.5070009@fud.no>

* Tore Anderson

>> Does anyone see MAP-E being implemented on regular linecards or is it
>> going to be implemented on processor based dedicated hardware? At least
>> initially, I would just assume it's going to be some kind of CGN blade.
> 
> No idea, sorry.

https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf
slide 15:

?Processed inline with normal IP traffic (at least on Cisco?s ASR9K)?

Tore


From swmike at swm.pp.se  Mon Apr  8 12:02:34 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 8 Apr 2013 14:02:34 +0200 (CEST)
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162ACA9.1050508@fud.no>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no> <alpine.DEB.2.00.1304081254100.23668@uplift.swm.pp.se>
 <5162ACA9.1050508@fud.no>
Message-ID: <alpine.DEB.2.00.1304081357500.23668@uplift.swm.pp.se>

On Mon, 8 Apr 2013, Tore Anderson wrote:

> If this is to be called "translation", then any tunneling mechanism that 
> works by stacking layer-3 headers, including GRE, IPIP, ESP, and 
> proto-41, must be also called "translation".

Oki, my bad. I read 
https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf 
and obviously didn't understand. I thought only the payload was 
encapsulated, not the complete IPv4 packet. It said "replace IPv4 header 
with IPv6 header" and I missed that this was for MAP-T, not MAP-E).

Thanks for explaining. I understand why MAP-E is not translation now.

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


From tore at fud.no  Mon Apr  8 12:20:51 2013
From: tore at fud.no (Tore Anderson)
Date: Mon, 08 Apr 2013 14:20:51 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <51629C0B.30801@fud.no>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no>
Message-ID: <5162B623.5030301@fud.no>

* Tore Anderson

> The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
> component though, so there is some NAT involved in the overall solution,
> but it's pretty much the same as what we have in today's CPEs/HGWs. The
> only significant difference is that a MAP CPE must be prepared to not
> being able to use all the 65536 source ports.

BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.

I find that the easiest way to visualise MAP is to take the 16 bits of
TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4
address space, for a total of 48 "routable" bits. So while the primary
use case for MAP is to provision less than 32 bits to the individual
customers (say a "/34" -> 4 subscribers per IPv4 address w/16k ports
each), you can also give out a "whole" /32 or a /24 or whatever -
perhaps only to the customers that are willing to pay for the privilege.

I haven't tested, but I believe that if you were to hook up a standard
Linux box to a ISP that provides /32 or shorter over MAP, you don't
really need any special MAP support in the IP stack to make it go -
you'd have to calculate the addresses to be used yourself, but once
you've got them, you could just configure everything using standard "ip
tunnel/address" commands.

It's quite neat, I think. :-)

Tore


From jbates at brightok.net  Mon Apr  8 14:23:03 2013
From: jbates at brightok.net (Jack Bates)
Date: Mon, 08 Apr 2013 09:23:03 -0500
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162B623.5030301@fud.no>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no> <5162B623.5030301@fud.no>
Message-ID: <5162D2C7.5020907@brightok.net>

On 4/8/2013 7:20 AM, Tore Anderson wrote:
> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
> address or even a prefix to the subscriber, thus also taking away the
> need for [srcport-restricted] NAPT44 in the CPE.

The problem is NAPT44 in the CPE isn't enough. We are reaching the point 
that 1 IPv4 Address per customer won't accommodate user bases.

The larger issue I think with MAP is CPE support requirements. There are 
ISP layouts that use bridging instead of CPE routers (which was a long 
term design to support IPv6 without CPE replacements years later). CGN 
will handle the IPv4 issues in this setup just fine. Then there are 
those who have already deployed IPv6 capable CPEs with PPP or DHCP in a 
router configuration which does not have MAP support. Given the variety 
of CPE vendors that end up getting deployed over a longer period of 
time, it is easier and more cost effective to deploy CGN than try and 
replace all the CPEs.

Given US$35/CPE, cost for replacements (not including deployment costs) 
for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.

The only way I see it justifiable is if you haven't had IPv6 deployment 
in mind yet and you are having to replace every CPE for IPv6 support 
anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays 
for if they wish IPv6 connectivity(or during whatever slow trickle 
replacement methods you utilize). While waiting for the slow rollout, 
CGN would be an interim cost that would be acceptable. I'm not sure 
there is a reason for MAPS if you've already deployed CGN, though.

I am sure Verizon did a lot of cost analysis.

Jack


From randy at psg.com  Mon Apr  8 14:24:12 2013
From: randy at psg.com (Randy Bush)
Date: Mon, 08 Apr 2013 23:24:12 +0900
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304081357500.23668@uplift.swm.pp.se>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
Message-ID: <m2txnhgkxf.wl%randy@psg.com>

> I understand why MAP-E is not translation now.

so far, the sexiest implementation of statless a+p to date.

randy


From bicknell at ufp.org  Mon Apr  8 14:47:22 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 8 Apr 2013 07:47:22 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
References: <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <91386916-584B-417C-9B7A-0A60EC5A262A@delong.com>
 <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
 <67C4F544-624E-4614-A62D-08E0E06796D1@delong.com> <51626345.40106@fud.no>
 <FA803B67-47DB-4374-AED0-E0E9E5F5A2D3@delong.com>
Message-ID: <20130408144722.GA38118@ussenterprise.ufp.org>

In a message written on Mon, Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong wrote:
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.

I'm going to disagree, because the tail here I think is quite long.

Owen is spot on when looking at the percentage of bits moved across
the network.  I suspect if the top 20 CDN's were to IPv6 enable
_everything_ that 50-90% of the bits in most networks would be moved
over native IPv6, depending on the exact mix of traffic in the
network.

However, CDN's are a _very_ small part of the address space.  I'd
be surprised if the top 20 CDN's had 0.01% of all IPv4 space.  That
leaves a lot of hosts that need to be upgraded.  There's a lot of
people who buy a $9.95/month VPS to host their personal blog read
by 20 people who don't know anything about IPv4 or IPv6 but want
to be able to reach their site.  The traffic level may be
non-interesting, but they will be quite unhappy without a CGN
solution.

Moving the CDN's to IPv6 native has the potential to save the access
providers a TON of money on CGN hardware, due to the bandwidth
involved.  However those access providers still have to do CGN,
otherwise their NOC's will be innondated with complaints about the
inability to reach a bunch of small sites for a long period of time.

If I were deploying CGN, I would be exerting any leverage I had on CDN's
to go native IPv6.

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

From joelja at bogus.com  Mon Apr  8 14:58:18 2013
From: joelja at bogus.com (joel jaeggli)
Date: Mon, 08 Apr 2013 07:58:18 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162D2C7.5020907@brightok.net>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no> <5162B623.5030301@fud.no>
 <5162D2C7.5020907@brightok.net>
Message-ID: <5162DB0A.2000908@bogus.com>

On 4/8/13 7:23 AM, Jack Bates wrote:
> On 4/8/2013 7:20 AM, Tore Anderson wrote:
>> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>> address or even a prefix to the subscriber, thus also taking away the
>> need for [srcport-restricted] NAPT44 in the CPE.
>
> The problem is NAPT44 in the CPE isn't enough. We are reaching the 
> point that 1 IPv4 Address per customer won't accommodate user bases.
>
That happened a long time ago. I realize the people like to think of 
wireless providers as different, they really aren't. A big chuck of our 
mobile gaming customers come to us via carrier operated nat translators. 
Some of them now come to us via ipv6, most do not.
> The larger issue I think with MAP is CPE support requirements. There 
> are ISP layouts that use bridging instead of CPE routers (which was a 
> long term design to support IPv6 without CPE replacements years 
> later). CGN will handle the IPv4 issues in this setup just fine. Then 
> there are those who have already deployed IPv6 capable CPEs with PPP 
> or DHCP in a router configuration which does not have MAP support. 
> Given the variety of CPE vendors that end up getting deployed over a 
> longer period of time, it is easier and more cost effective to deploy 
> CGN than try and replace all the CPEs.
>
> Given US$35/CPE, cost for replacements (not including deployment 
> costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so 
> costly.
>
> The only way I see it justifiable is if you haven't had IPv6 
> deployment in mind yet and you are having to replace every CPE for 
> IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which 
> the customer pays for if they wish IPv6 connectivity(or during 
> whatever slow trickle replacement methods you utilize). While waiting 
> for the slow rollout, CGN would be an interim cost that would be 
> acceptable. I'm not sure there is a reason for MAPS if you've already 
> deployed CGN, though.
>
> I am sure Verizon did a lot of cost analysis.
>
> Jack
>



From jbates at brightok.net  Mon Apr  8 15:06:49 2013
From: jbates at brightok.net (Jack Bates)
Date: Mon, 08 Apr 2013 10:06:49 -0500
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162DB0A.2000908@bogus.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no> <5162B623.5030301@fud.no>
 <5162D2C7.5020907@brightok.net> <5162DB0A.2000908@bogus.com>
Message-ID: <5162DD09.6040208@brightok.net>

On 4/8/2013 9:58 AM, joel jaeggli wrote:
> That happened a long time ago. I realize the people like to think of 
> wireless providers as different, they really aren't. A big chuck of 
> our mobile gaming customers come to us via carrier operated nat 
> translators. Some of them now come to us via ipv6, most do not.

Yeah, forgive me. I have a tendency to forget the mobile carriers, 
probably because some of them started with CGN. One of my customers just 
started a new cell network. He's burning through /20's like they are 
nothing in a short time frame (and it's a small geographic area). 
They're deploying CGN so we don't run out of addresses and can recover 
what we've already burned through. IPv6 for their cellular didn't seem 
high priority either.


Jack


From shtsuchi at cisco.com  Mon Apr  8 15:30:19 2013
From: shtsuchi at cisco.com (Shishio Tsuchiya)
Date: Tue, 09 Apr 2013 00:30:19 +0900
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162D2C7.5020907@brightok.net>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no> <5162B623.5030301@fud.no>
 <5162D2C7.5020907@brightok.net>
Message-ID: <5162E28B.3090906@cisco.com>

Indeed MAP-E requires CPE replacement/upgrade cost.
But I would like to share JANOG Softwire WG Activity.
http://conference.apnic.net/__data/assets/pdf_file/0005/58856/apnic35-janog-softwire_1361559276.pdf

MAP-E already supported by 6 vendors,7 implementations.
It includes 2 open source(OpenWRT and ASAMAP) and 2 kernel(Linux 2.6.18 and NetBSD 4.0.1).

Regards,
Shishio

(2013/04/08 23:23), Jack Bates wrote:
> On 4/8/2013 7:20 AM, Tore Anderson wrote:
>> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>> address or even a prefix to the subscriber, thus also taking away the
>> need for [srcport-restricted] NAPT44 in the CPE.
> 
> The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases.
> 
> The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs.
> 
> Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.
> 
> The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though.
> 
> I am sure Verizon did a lot of cost analysis.
> 
> Jack
> 
> .
> 



From mstaudinger at corp.earthlink.com  Mon Apr  8 17:53:06 2013
From: mstaudinger at corp.earthlink.com (Staudinger, Malcolm)
Date: Mon, 8 Apr 2013 10:53:06 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
Message-ID: <B03F861163A36F41801FE0919EB9ADC805B294FD@jarjar.ad.newedgenetworks.com>

Can anyone from Verizon comment on what IP space that's being used for
this? Or perhaps what the rDNS mask will look like?
>From an abuse perspective, knowing that an IP is being used for this can
make the difference between traffic looking like abuse and traffic
looking like multiple legitimate users.

Malcolm Staudinger
Information Security Analyst | EIS
EarthLink

-----Original Message-----
From: cb.list6 [mailto:cb.list6 at gmail.com] 
Sent: Saturday, April 06, 2013 6:24 PM
To: nanog at nanog.org
Subject: Verizon DSL moving to CGN

Interesting.

http://www22.verizon.com/support/residential/internet/highspeedinternet/
networking/troubleshooting/portforwarding/123897.htm


From rajiva at cisco.com  Mon Apr  8 18:19:59 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 18:19:59 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CA5E@xmb-rcd-x06.cisco.com>



> CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow
> traffic through a dedicated box because MAP won't be implemented in my
> regular routers (if you know otherwise, please speak up).

Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
routers that I know of - ASR9K and ASR1K. Without that, you are right that
MAP wouldn't have been as beneficial as claimed.

> It's still NAT.

Yes, assuming MAP-T.
No, assuming, MAP-E




Cheers,
Rajiv

-----Original Message-----
From: Mikael Abrahamsson <swmike at swm.pp.se>
Organization: People's Front Against WWW
Date: Monday, April 8, 2013 6:01 AM
To: Rajiv Asati <rajiva at cisco.com>
Cc: nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
>
>> Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP
>> doesn't require any CGN that causes the SP network to put up with the
>> NAT state. This means that all the subsequent issues of CGN/DS-Lite no
>> longer apply.
>
>For me as an operator, MAP is most likely going to be implemented in a
>CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow
>traffic through a dedicated box because MAP won't be implemented in my
>regular routers (if you know otherwise, please speak up).
>
>> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
>> access. MAP makes much more sense in any SP network having its internet
>> customers do IPv4 address sharing and embrace IPv6.
>
>It's still NAT.
>
>-- 
>Mikael Abrahamsson    email: swmike at swm.pp.se



From morrowc.lists at gmail.com  Mon Apr  8 18:28:53 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 8 Apr 2013 14:28:53 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CA5E@xmb-rcd-x06.cisco.com>
References: <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CA5E@xmb-rcd-x06.cisco.com>
Message-ID: <CAL9jLaZ-Axcx7fDk4XZbyWaQU0oyheb+5JjTvVWYLdKC2zAxiw@mail.gmail.com>

On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) <rajiva at cisco.com>wrote:

> Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
> routers that I know of - ASR9K and ASR1K. Without that, you are right that
> MAP wouldn't have been as beneficial as claimed.
>

glad it's cross platform... is it also IP encumbered so it'll remain just
as 'cross platform' ?

From rajiva at cisco.com  Mon Apr  8 18:45:24 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 18:45:24 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <51629C0B.30801@fud.no>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CBE3@xmb-rcd-x06.cisco.com>


Tore is spot on. With MAP, you can use your regular routers, whether it is
the Encap mode or Translation mode.

One can decide between Encap mode and Translation mode of MAP per his/her
environment/requirements. I do find -T mode preferable since it requires
no changes to the transparent caching infrastructure or LI infrastructure
or QOS policies (if used between CE and Border routers).

One may refer to additional details here -

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_pap
er_c11-558744-00.html#wp9000119

http://www.ciscoknowledgenetwork.com/files/300_11-06-2012-NGN-IPv4-Exhaust-
IPv6-Strategy.pdf 

Cheers,
Rajiv


-----Original Message-----
From: Tore Anderson <tore at fud.no>
Date: Monday, April 8, 2013 6:29 AM
To: Mikael Abrahamsson <swmike at swm.pp.se>
Cc: Rajiv Asati <rajiva at cisco.com>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>* Mikael Abrahamsson
>
>> On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
>> 
>>> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
>>> access. MAP makes much more sense in any SP network having its
>>> internet customers do IPv4 address sharing and embrace IPv6.
>> 
>> It's still NAT.
>
>AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
>tunneling, pure encap/decap plus a clever way to calculate the outer
>IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
>inner IPv4 packets are not modified by the centralised MAP tunneling
>routers, so there is no "Network Address Translation" being performed.
>
>The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
>component though, so there is some NAT involved in the overall solution,
>but it's pretty much the same as what we have in today's CPEs/HGWs. The
>only significant difference is that a MAP CPE must be prepared to not
>being able to use all the 65536 source ports.
>
>Tore
>



From rajiva at cisco.com  Mon Apr  8 18:50:00 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 18:50:00 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <alpine.DEB.2.02.1304072149280.26083@sam>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CC32@xmb-rcd-x06.cisco.com>

Sam,

> What may make 'much more sense' in one network, doesn't necessarily make
> as much since in another network. As I understand it, MAP requires at
> least a software change on existing CPE, if not wholesale CPE change.
> Some providers may prefer to implement CGN instead if the capital outlay
> is less (and providing new CPE to customers through walkins or truck
>rolls
> can be problematic).

I agree with you. Having said that, the way many ISPs are approaching the
MAP deployment is by letting the new customers get the MAP capable CPE
from the get go, while letting the existing customers' get their CPE
routers upgraded when/if they need a truck roll or through regular S&H
(much like how Vonage does it).


It is certainly very much possible to get MAP functionality by software
upgrades, though the mileage may vary.


> What devices does Cisco support MAP on? Specifically, does the DPC3827
> support it?

MAP BR function is supported on ASR9K and ASR1K.

I am not aware of MAP CE function support on DPC3827 CPE router.


Cheers,
Rajiv

-----Original Message-----
From: "<Sam Hayes Merritt>", III <sam at themerritts.org>
Date: Sunday, April 7, 2013 10:56 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
>> access. MAP makes much more sense in any SP network having its internet
>> customers do IPv4 address sharing and embrace IPv6.
>
>What may make 'much more sense' in one network, doesn't necessarily make
>as much since in another network. As I understand it, MAP requires at
>least a software change on existing CPE, if not wholesale CPE change.
>Some providers may prefer to implement CGN instead if the capital outlay
>is less (and providing new CPE to customers through walkins or truck
>rolls 
>can be problematic).
>
>Our plan for my company at this time is to deploy native IPv4+IPv6 to
>all customers. While we are doing that, continue discussions and testing
>with CGN providers so that when we are unable to obtain anymore IPv4
>addresses, we can then deploy CGN. Our hope is that we never get to the
>point of having to go CGN but we have to be ready in case that day comes
>and have our implementation and opt-out (if available) processes ready.
>
>
>What devices does Cisco support MAP on? Specifically, does the DPC3827
>support it?
>
>
>sam



From rajiva at cisco.com  Mon Apr  8 18:54:23 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 18:54:23 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <9C7612FD-15A2-4B63-A1B5-0957C0D34ECE@delong.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CC8D@xmb-rcd-x06.cisco.com>


Like you, I would like to be optimistic about many v4-only apps and
v4-only devices becoming dual-stack sooner than later.

But knowing that a significant (50%+) of android devices may not support
IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
the weekend) being v4-only) and may not be upgraded by their users to the
right software, and that Skype etc. apps are out there, my optimism fades
away.

Cheers,
Rajiv

-----Original Message-----
From: Owen DeLong <owen at delong.com>
Date: Monday, April 8, 2013 1:38 AM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Fabien Delmotte <fdelmotte1 at mac.com>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>On Apr 7, 2013, at 18:21 , Rajiv Asati (rajiva) <rajiva at cisco.com> wrote:
>
>> Dual-stack in the home networks will stay with us for a long time
>>(beyond 2020!) until v4-only user devices and v4-only apps get refreshed.
>
>I disagree. I think that v4-only apps and devices will get relegated to
>being connected through v4-v6 adapter appliances until they are fixed.
>
>IPv4 is simply going to become far too expensive to maintain to be able
>to deliver it for residential pricing.
>
>> Of course, this doesn't mean that the ISP access needs to stay
>>dual-stack, thanks to MAP, 464XLAT etc.
>> 
>
>Right... Those are some of the ways that maintaining IPv4 will become so
>expensive. ;-)
>
>Owen
>



From rajiva at cisco.com  Mon Apr  8 19:11:02 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 19:11:02 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162D2C7.5020907@brightok.net>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CD1E@xmb-rcd-x06.cisco.com>

Jack,

I am assuming that you meant MAP, when you wrote MAPS.

> The larger issue I think with MAP is CPE support requirements. There are
> ISP layouts that use bridging instead of CPE routers (which was a long
> term design to support IPv6 without CPE replacements years later). CGN
> will handle the IPv4 issues in this setup just fine. Then there are

I agree. Good point, btw.

This is the classical ISP deployment model, in which the ISP would usually
provide the layer2 modem, and let the customer get the retail CPE.

> those who have already deployed IPv6 capable CPEs with PPP or DHCP in a
> router configuration which does not have MAP support. Given the variety
> of CPE vendors that end up getting deployed over a longer period of
> time, it is easier and more cost effective to deploy CGN than try and
> replace all the CPEs.

Seemingly so, until we start adding up the cost of

	- Logging infrastructure (setup & mtc)
	- Static NAT & Port forwarding (gaming, camera, etc.)
	- CGN redundancy & load-sharing
	- design complexity (to maintain symmetry)
	- ..

> Given US$35/CPE, cost for replacements (not including deployment costs)
> for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.

Let's throw some numbers of the above costs and then we can do the
apple-to-apple comparison. Else, you are right that CGN cost could be a
lot less.


Cheers,
Rajiv

-----Original Message-----
From: Jack Bates <jbates at brightok.net>
Date: Monday, April 8, 2013 10:23 AM
To: Tore Anderson <tore at fud.no>
Cc: nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>On 4/8/2013 7:20 AM, Tore Anderson wrote:
>> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>> address or even a prefix to the subscriber, thus also taking away the
>> need for [srcport-restricted] NAPT44 in the CPE.
>
>The problem is NAPT44 in the CPE isn't enough. We are reaching the point
>that 1 IPv4 Address per customer won't accommodate user bases.
>
>The larger issue I think with MAP is CPE support requirements. There are
>ISP layouts that use bridging instead of CPE routers (which was a long
>term design to support IPv6 without CPE replacements years later). CGN
>will handle the IPv4 issues in this setup just fine. Then there are
>those who have already deployed IPv6 capable CPEs with PPP or DHCP in a
>router configuration which does not have MAP support. Given the variety
>of CPE vendors that end up getting deployed over a longer period of
>time, it is easier and more cost effective to deploy CGN than try and
>replace all the CPEs.
>
>Given US$35/CPE, cost for replacements (not including deployment costs)
>for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.
>
>The only way I see it justifiable is if you haven't had IPv6 deployment
>in mind yet and you are having to replace every CPE for IPv6 support
>anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays
>for if they wish IPv6 connectivity(or during whatever slow trickle
>replacement methods you utilize). While waiting for the slow rollout,
>CGN would be an interim cost that would be acceptable. I'm not sure
>there is a reason for MAPS if you've already deployed CGN, though.
>
>I am sure Verizon did a lot of cost analysis.
>
>Jack
>



From rajiva at cisco.com  Mon Apr  8 19:13:11 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 19:13:11 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAL9jLaZ-Axcx7fDk4XZbyWaQU0oyheb+5JjTvVWYLdKC2zAxiw@mail.gmail.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CD2F@xmb-rcd-x06.cisco.com>

Chris,

Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
encumbered?

If so, the answer is Yes. v6 addressing doesn't need to change to
accommodate this IPv4 A+P encoding.


Cheers,
Rajiv

-----Original Message-----
From: Christopher Morrow <morrowc.lists at gmail.com>
Date: Monday, April 8, 2013 2:28 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
><rajiva at cisco.com> wrote:
>
>Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
>routers that I know of - ASR9K and ASR1K. Without that, you are right that
>MAP wouldn't have been as beneficial as claimed.
>
>
>
>
>
>glad it's cross platform... is it also IP encumbered so it'll remain just
>as 'cross platform' ?
>



From cra at WPI.EDU  Mon Apr  8 19:18:10 2013
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Apr 2013 15:18:10 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CD2F@xmb-rcd-x06.cisco.com>
References: <CAL9jLaZ-Axcx7fDk4XZbyWaQU0oyheb+5JjTvVWYLdKC2zAxiw@mail.gmail.com>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CD2F@xmb-rcd-x06.cisco.com>
Message-ID: <20130408191809.GY3010@angus.ind.WPI.EDU>

I think he means patent encumbered.

On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
> Chris,
> 
> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
> encumbered?
> 
> If so, the answer is Yes. v6 addressing doesn't need to change to
> accommodate this IPv4 A+P encoding.
> 
> 
> Cheers,
> Rajiv
> 
> -----Original Message-----
> From: Christopher Morrow <morrowc.lists at gmail.com>
> Date: Monday, April 8, 2013 2:28 PM
> To: Rajiv Asati <rajiva at cisco.com>
> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
> Subject: Re: Verizon DSL moving to CGN
> 
> >
> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
> ><rajiva at cisco.com> wrote:
> >
> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
> >routers that I know of - ASR9K and ASR1K. Without that, you are right that
> >MAP wouldn't have been as beneficial as claimed.
> >
> >
> >
> >
> >
> >glad it's cross platform... is it also IP encumbered so it'll remain just
> >as 'cross platform' ?


From rajiva at cisco.com  Mon Apr  8 19:21:30 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 19:21:30 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <20130408191809.GY3010@angus.ind.WPI.EDU>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CE01@xmb-rcd-x06.cisco.com>

Oh, it certainly is (per the IETF IPR rules).

Thanks for the clarity, Chuck.

Cheers,
Rajiv

-----Original Message-----
From: Chuck Anderson <cra at WPI.EDU>
Date: Monday, April 8, 2013 3:18 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Christopher Morrow <morrowc.lists at gmail.com>, nanog list
<nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>I think he means patent encumbered.
>
>On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
>> Chris,
>> 
>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
>> encumbered?
>> 
>> If so, the answer is Yes. v6 addressing doesn't need to change to
>> accommodate this IPv4 A+P encoding.
>> 
>> 
>> Cheers,
>> Rajiv
>> 
>> -----Original Message-----
>> From: Christopher Morrow <morrowc.lists at gmail.com>
>> Date: Monday, April 8, 2013 2:28 PM
>> To: Rajiv Asati <rajiva at cisco.com>
>> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
>> Subject: Re: Verizon DSL moving to CGN
>> 
>> >
>> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
>> ><rajiva at cisco.com> wrote:
>> >
>> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
>> >routers that I know of - ASR9K and ASR1K. Without that, you are right
>>that
>> >MAP wouldn't have been as beneficial as claimed.
>> >
>> >
>> >
>> >
>> >
>> >glad it's cross platform... is it also IP encumbered so it'll remain
>>just
>> >as 'cross platform' ?



From rajiva at cisco.com  Mon Apr  8 19:36:03 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 19:36:03 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162B623.5030301@fud.no>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CF09@xmb-rcd-x06.cisco.com>

Tore,

> I haven't tested, but I believe that if you were to hook up a standard
> Linux box to a ISP that provides /32 or shorter over MAP, you don't

Yes, indeed. 

In fact, almost all of the MAP CE implementations (that I am aware of) are
open source/linux based -


http://enog.jp/~masakazu/vyatta/map/
http://mapt.ivi2.org:8039/readme.txt


Cheers,
Rajiv


-----Original Message-----
From: Tore Anderson <tore at fud.no>
Date: Monday, April 8, 2013 8:20 AM
To: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
Cc: Rajiv Asati <rajiva at cisco.com>
Subject: Re: Verizon DSL moving to CGN

>* Tore Anderson
>
>> The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
>> component though, so there is some NAT involved in the overall solution,
>> but it's pretty much the same as what we have in today's CPEs/HGWs. The
>> only significant difference is that a MAP CPE must be prepared to not
>> being able to use all the 65536 source ports.
>
>BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>address or even a prefix to the subscriber, thus also taking away the
>need for [srcport-restricted] NAPT44 in the CPE.
>
>I find that the easiest way to visualise MAP is to take the 16 bits of
>TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4
>address space, for a total of 48 "routable" bits. So while the primary
>use case for MAP is to provision less than 32 bits to the individual
>customers (say a "/34" -> 4 subscribers per IPv4 address w/16k ports
>each), you can also give out a "whole" /32 or a /24 or whatever -
>perhaps only to the customers that are willing to pay for the privilege.
>
>I haven't tested, but I believe that if you were to hook up a standard
>Linux box to a ISP that provides /32 or shorter over MAP, you don't
>really need any special MAP support in the IP stack to make it go -
>you'd have to calculate the addresses to be used yourself, but once
>you've got them, you could just configure everything using standard "ip
>tunnel/address" commands.
>
>It's quite neat, I think. :-)
>
>Tore



From morrowc.lists at gmail.com  Mon Apr  8 19:41:54 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 8 Apr 2013 15:41:54 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CE01@xmb-rcd-x06.cisco.com>
References: <20130408191809.GY3010@angus.ind.WPI.EDU>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CE01@xmb-rcd-x06.cisco.com>
Message-ID: <CAL9jLab6=wU3_1snrc_si+Fyhg0tpGz9s4mL3CMo3GN2k7BMvQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) <rajiva at cisco.com>wrote:

> Oh, it certainly is (per the IETF IPR rules).
>
>
which rfcs? I can find a draft in softwire:
   http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01

and a reference to this in wikipedia:
  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP

which says: "...(MAP) is a Cisco IPv6 transition proposal..."

so.. err, we won't see this in juniper gear since:
  1) not a standard
  2) encumbered by IPR issues

weee!


> Thanks for the clarity, Chuck.
>
> Cheers,
> Rajiv
>
> -----Original Message-----
> From: Chuck Anderson <cra at WPI.EDU>
> Date: Monday, April 8, 2013 3:18 PM
> To: Rajiv Asati <rajiva at cisco.com>
> Cc: Christopher Morrow <morrowc.lists at gmail.com>, nanog list
> <nanog at nanog.org>
> Subject: Re: Verizon DSL moving to CGN
>
> >I think he means patent encumbered.
> >
> >On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
> >> Chris,
> >>
> >> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
> >> encumbered?
> >>
> >> If so, the answer is Yes. v6 addressing doesn't need to change to
> >> accommodate this IPv4 A+P encoding.
> >>
> >>
> >> Cheers,
> >> Rajiv
> >>
> >> -----Original Message-----
> >> From: Christopher Morrow <morrowc.lists at gmail.com>
> >> Date: Monday, April 8, 2013 2:28 PM
> >> To: Rajiv Asati <rajiva at cisco.com>
> >> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
> >> Subject: Re: Verizon DSL moving to CGN
> >>
> >> >
> >> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
> >> ><rajiva at cisco.com> wrote:
> >> >
> >> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
> >> >routers that I know of - ASR9K and ASR1K. Without that, you are right
> >>that
> >> >MAP wouldn't have been as beneficial as claimed.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >glad it's cross platform... is it also IP encumbered so it'll remain
> >>just
> >> >as 'cross platform' ?
>
>

From cra at WPI.EDU  Mon Apr  8 19:43:40 2013
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 8 Apr 2013 15:43:40 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAL9jLab6=wU3_1snrc_si+Fyhg0tpGz9s4mL3CMo3GN2k7BMvQ@mail.gmail.com>
References: <20130408191809.GY3010@angus.ind.WPI.EDU>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CE01@xmb-rcd-x06.cisco.com>
 <CAL9jLab6=wU3_1snrc_si+Fyhg0tpGz9s4mL3CMo3GN2k7BMvQ@mail.gmail.com>
Message-ID: <20130408194340.GZ3010@angus.ind.WPI.EDU>

http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-softwire-map

http://datatracker.ietf.org/doc/draft-ietf-softwire-map/?include_text=1

On Mon, Apr 08, 2013 at 03:41:54PM -0400, Christopher Morrow wrote:
> On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) <rajiva at cisco.com>wrote:
> 
> > Oh, it certainly is (per the IETF IPR rules).
> >
> >
> which rfcs? I can find a draft in softwire:
>    http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
> 
> and a reference to this in wikipedia:
>   http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP
> 
> which says: "...(MAP) is a Cisco IPv6 transition proposal..."
> 
> so.. err, we won't see this in juniper gear since:
>   1) not a standard
>   2) encumbered by IPR issues
> 
> weee!
> 
> 
> > Thanks for the clarity, Chuck.
> >
> > Cheers,
> > Rajiv
> >
> > -----Original Message-----
> > From: Chuck Anderson <cra at WPI.EDU>
> > Date: Monday, April 8, 2013 3:18 PM
> > To: Rajiv Asati <rajiva at cisco.com>
> > Cc: Christopher Morrow <morrowc.lists at gmail.com>, nanog list
> > <nanog at nanog.org>
> > Subject: Re: Verizon DSL moving to CGN
> >
> > >I think he means patent encumbered.
> > >
> > >On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
> > >> Chris,
> > >>
> > >> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
> > >> encumbered?
> > >>
> > >> If so, the answer is Yes. v6 addressing doesn't need to change to
> > >> accommodate this IPv4 A+P encoding.
> > >>
> > >>
> > >> Cheers,
> > >> Rajiv
> > >>
> > >> -----Original Message-----
> > >> From: Christopher Morrow <morrowc.lists at gmail.com>
> > >> Date: Monday, April 8, 2013 2:28 PM
> > >> To: Rajiv Asati <rajiva at cisco.com>
> > >> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
> > >> Subject: Re: Verizon DSL moving to CGN
> > >>
> > >> >
> > >> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
> > >> ><rajiva at cisco.com> wrote:
> > >> >
> > >> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
> > >> >routers that I know of - ASR9K and ASR1K. Without that, you are right
> > >>that
> > >> >MAP wouldn't have been as beneficial as claimed.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >glad it's cross platform... is it also IP encumbered so it'll remain
> > >>just
> > >> >as 'cross platform' ?


From rajiva at cisco.com  Mon Apr  8 19:48:41 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 19:48:41 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAL9jLab6=wU3_1snrc_si+Fyhg0tpGz9s4mL3CMo3GN2k7BMvQ@mail.gmail.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D063@xmb-rcd-x06.cisco.com>

Chris,

That's an incorrect draft pointer. Here is the correct one -

http://tools.ietf.org/html/draft-ietf-softwire-map
tools.ietf.org/html/draft-ietf-softwire-map-t
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp

And no, Cisco has no IPR on MAP wrt the above drafts.

Cheers,
Rajiv

PS: Please do note that the IPRs mostly get nullified once they are
through the IETF standards process.




-----Original Message-----
From: Christopher Morrow <morrowc.lists at gmail.com>
Date: Monday, April 8, 2013 3:41 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Chuck Anderson <cra at WPI.EDU>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>
>
>On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
><rajiva at cisco.com> wrote:
>
>Oh, it certainly is (per the IETF IPR rules).
>
>
>
>
>
>which rfcs? I can find a draft in softwire:
>   http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
>
>
>and a reference to this in wikipedia:
>  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP
>
>
>which says: "...(MAP) is a Cisco IPv6 transition proposal..."
>
>
>so.. err, we won't see this in juniper gear since:
>  1) not a standard
>  2) encumbered by IPR issues
>
>
>weee!
> 
>
>Thanks for the clarity, Chuck.
>
>Cheers,
>Rajiv
>
>-----Original Message-----
>From: Chuck Anderson <cra at WPI.EDU>
>Date: Monday, April 8, 2013 3:18 PM
>To: Rajiv Asati <rajiva at cisco.com>
>
>Cc: Christopher Morrow <morrowc.lists at gmail.com>, nanog list
><nanog at nanog.org>
>Subject: Re: Verizon DSL moving to CGN
>
>>I think he means patent encumbered.
>>
>>On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
>>> Chris,
>>>
>>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
>>> encumbered?
>>>
>>> If so, the answer is Yes. v6 addressing doesn't need to change to
>>> accommodate this IPv4 A+P encoding.
>>>
>>>
>>> Cheers,
>>> Rajiv
>>>
>>> -----Original Message-----
>>> From: Christopher Morrow <morrowc.lists at gmail.com>
>>> Date: Monday, April 8, 2013 2:28 PM
>>> To: Rajiv Asati <rajiva at cisco.com>
>>> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org>
>>> Subject: Re: Verizon DSL moving to CGN
>>>
>>> >
>>> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
>>> ><rajiva at cisco.com> wrote:
>>> >
>>> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
>>> >routers that I know of - ASR9K and ASR1K. Without that, you are right
>>>that
>>> >MAP wouldn't have been as beneficial as claimed.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >glad it's cross platform... is it also IP encumbered so it'll remain
>>>just
>>> >as 'cross platform' ?
>
>
>
>
>
>
>
>
>



From tom.taylor.stds at gmail.com  Mon Apr  8 19:48:43 2013
From: tom.taylor.stds at gmail.com (Tom Taylor)
Date: Mon, 08 Apr 2013 15:48:43 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CD2F@xmb-rcd-x06.cisco.com>
References: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CD2F@xmb-rcd-x06.cisco.com>
Message-ID: <51631F1B.2060106@gmail.com>

In what sense do you mean that? The end-user IPv6 prefix certainly ties 
IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over 
IPv6 alternative.

Tom

On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:
> Chris,
>
> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
> encumbered?
>
> If so, the answer is Yes. v6 addressing doesn't need to change to
> accommodate this IPv4 A+P encoding.
>
>
> Cheers,
> Rajiv
>
...


From deric.kwok2000 at gmail.com  Mon Apr  8 19:51:05 2013
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Mon, 8 Apr 2013 15:51:05 -0400
Subject: need help about free bandwidth graph program
Message-ID: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>

Hi all

Do you know any opensource program bandwidthgraph by ipaddess?

Thank you

From morrowc.lists at gmail.com  Mon Apr  8 19:57:08 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 8 Apr 2013 15:57:08 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D063@xmb-rcd-x06.cisco.com>
References: <CAL9jLab6=wU3_1snrc_si+Fyhg0tpGz9s4mL3CMo3GN2k7BMvQ@mail.gmail.com>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D063@xmb-rcd-x06.cisco.com>
Message-ID: <CAL9jLaZ+Oindzm_qwTMPQ2pQDKondD8KVu8ZfMcF54ZW9bH9ww@mail.gmail.com>

On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva) <rajiva at cisco.com>wrote:

> Chris,
>
> That's an incorrect draft pointer. Here is the correct one -
>
> http://tools.ietf.org/html/draft-ietf-softwire-map
> tools.ietf.org/html/draft-ietf-softwire-map-t
> http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp
>
>
great, but still a draft, not an official standard.


> And no, Cisco has no IPR on MAP wrt the above drafts.
>
>
'yet'... they don't have to officially declare until WGLC... and REALLY not
until the draft is sent up to the IESG, but doing it early is certainly
nice so that the WG has an opportunity to say: "yea, IPR here is going to
cause a problem with interop/etc".


> Cheers,
> Rajiv
>
> PS: Please do note that the IPRs mostly get nullified once they are
> through the IETF standards process.
>
>
that's not been my experience.. see flow-spec for a great example. 'mostly
nullified' is .. disingenuous at best.


>
>
>
> -----Original Message-----
> From: Christopher Morrow <morrowc.lists at gmail.com>
> Date: Monday, April 8, 2013 3:41 PM
> To: Rajiv Asati <rajiva at cisco.com>
> Cc: Chuck Anderson <cra at WPI.EDU>, nanog list <nanog at nanog.org>
> Subject: Re: Verizon DSL moving to CGN
>
> >
> >
> >
> >On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
> ><rajiva at cisco.com> wrote:
> >
> >Oh, it certainly is (per the IETF IPR rules).
> >
> >
> >
> >
> >
> >which rfcs? I can find a draft in softwire:
> >   http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
> >
> >
> >and a reference to this in wikipedia:
> >  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP
> >
> >
> >which says: "...(MAP) is a Cisco IPv6 transition proposal..."
> >
> >
> >so.. err, we won't see this in juniper gear since:
> >  1) not a standard
> >  2) encumbered by IPR issues
> >
> >
> >weee!
> >
> >
> >Thanks for the clarity, Chuck.
> >
> >Cheers,
> >Rajiv
> >
> >-----Original Message-----
> >From: Chuck Anderson <cra at WPI.EDU>
> >Date: Monday, April 8, 2013 3:18 PM
> >To: Rajiv Asati <rajiva at cisco.com>
> >
> >Cc: Christopher Morrow <morrowc.lists at gmail.com>, nanog list
> ><nanog at nanog.org>
> >Subject: Re: Verizon DSL moving to CGN
> >
> >>I think he means patent encumbered.
> >>
> >>On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
> >>> Chris,
> >>>
> >>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
> >>> encumbered?
> >>>
> >>> If so, the answer is Yes. v6 addressing doesn't need to change to
> >>> accommodate this IPv4 A+P encoding.
> >>>
> >>>
> >>> Cheers,
> >>> Rajiv
> >>>
> >>> -----Original Message-----
> >>> From: Christopher Morrow <morrowc.lists at gmail.com>
> >>> Date: Monday, April 8, 2013 2:28 PM
> >>> To: Rajiv Asati <rajiva at cisco.com>
> >>> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list <nanog at nanog.org
> >
> >>> Subject: Re: Verizon DSL moving to CGN
> >>>
> >>> >
> >>> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
> >>> ><rajiva at cisco.com> wrote:
> >>> >
> >>> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
> >>> >routers that I know of - ASR9K and ASR1K. Without that, you are right
> >>>that
> >>> >MAP wouldn't have been as beneficial as claimed.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >glad it's cross platform... is it also IP encumbered so it'll remain
> >>>just
> >>> >as 'cross platform' ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

From lathama at gmail.com  Mon Apr  8 20:05:36 2013
From: lathama at gmail.com (Andrew Latham)
Date: Mon, 8 Apr 2013 16:05:36 -0400
Subject: need help about free bandwidth graph program
In-Reply-To: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
Message-ID: <CA+qj4S9wNgMyzWWkZKmRt+a96Sf3OKkqQdsH8JbDnMjXaP65bA@mail.gmail.com>

Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want.

www: http://www.cacti.net/index.php



On Mon, Apr 8, 2013 at 3:51 PM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:
> Hi all
>
> Do you know any opensource program bandwidthgraph by ipaddess?
>
> Thank you



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


From wbailey at satelliteintelligencegroup.com  Mon Apr  8 20:15:41 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Mon, 8 Apr 2013 20:15:41 +0000
Subject: need help about free bandwidth graph program
In-Reply-To: <CA+qj4S9wNgMyzWWkZKmRt+a96Sf3OKkqQdsH8JbDnMjXaP65bA@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>,
 <CA+qj4S9wNgMyzWWkZKmRt+a96Sf3OKkqQdsH8JbDnMjXaP65bA@mail.gmail.com>
Message-ID: <1511cqdwmm9bpwjboaem1fwb.1365452135961@email.android.com>

Ntop has my vote. Nprobe is a great bolt on for sans NetFlow environments.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Andrew Latham <lathama at gmail.com>
Date: 04/08/2013 1:07 PM (GMT-08:00)
To: Deric Kwok <deric.kwok2000 at gmail.com>
Cc: nanog list <nanog at nanog.org>
Subject: Re: need help about free bandwidth graph program


Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want.

www: http://www.cacti.net/index.php



On Mon, Apr 8, 2013 at 3:51 PM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:
> Hi all
>
> Do you know any opensource program bandwidthgraph by ipaddess?
>
> Thank you



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



From jof at thejof.com  Mon Apr  8 20:21:57 2013
From: jof at thejof.com (Jonathan Lassoff)
Date: Mon, 8 Apr 2013 13:21:57 -0700
Subject: need help about free bandwidth graph program
In-Reply-To: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
Message-ID: <CAHsqw9susWt2SpvzpUPowsdcEXWV4NedPF2sOuWocNO1cCWr3Q@mail.gmail.com>

I'm not sure of your specific application, but it sounds to me like
netflow/sflow exports would be the most scalable way to do this.

For small applications, ntop or bandwidthd can do this.
http://www.ntop.org/products/ntop/
http://bandwidthd.sourceforge.net/

Cheers,
jof

On Mon, Apr 8, 2013 at 12:51 PM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:
> Hi all
>
> Do you know any opensource program bandwidthgraph by ipaddess?
>
> Thank you


From cmadams at hiwaay.net  Mon Apr  8 20:38:39 2013
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 8 Apr 2013 15:38:39 -0500
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CC8D@xmb-rcd-x06.cisco.com>
References: <9C7612FD-15A2-4B63-A1B5-0957C0D34ECE@delong.com>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CC8D@xmb-rcd-x06.cisco.com>
Message-ID: <20130408203839.GA4520@hiwaay.net>

Once upon a time, Rajiv Asati (rajiva) <rajiva at cisco.com> said:
> But knowing that a significant (50%+) of android devices may not support
> IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
> the weekend) being v4-only) and may not be upgraded by their users to the
> right software, and that Skype etc. apps are out there, my optimism fades
> away.

Yeah, Samsung is screwy on Android+IPv6.  My (less than 6 month old)
Samsung phone with Android 4.0 gets an IPv6 address (autoconfigured) but
does not add an IPv6 default route, so it can't reach the IPv6 Internet
over wi-fi.  IIRC when I enabled T-Mobile's IPv6 APN, it did handle IPv6
over the cell network okay.

My generic Chinese import Android 4.0 tablet works just fine with IPv6,
as did my old HTC/T-Mobile G2 (wi-fi only).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From oliver.borchert at nist.gov  Mon Apr  8 20:44:00 2013
From: oliver.borchert at nist.gov (Borchert, Oliver)
Date: Mon, 8 Apr 2013 16:44:00 -0400
Subject: Announcing BGP-SRx 0.3.0 service release
Message-ID: <D7A0423E5E193F40BE6E94126930C4930BFE5168D7@MBCLUSTER.xchange.nist.gov>

This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3 Prototype Implementation.
This release includes extensive performance and robustness improvements,
multi router support, re-design/re-write of the Quagga integration,
and many bug fixes.

BGP-SRx is an open source reference implementation and research platform
for investigating emerging BGP security extensions and supporting protocols.
The BGP-SRx suite consists of three parts:
(1) SRx Server, (2) SRx API, and (3) Quagga-SRx (which integrates the SRx API
into the Quagga router).
The focus is on origin validation, although it is designed to be extended to
path validation. Stub functionality for path validation is included in this
version.

Additionally, this release contains an SRx client/server test harnesses and a
simple RPKI validation cache simulator (VCS). The VCS allows to manually
feed ROA information into BGP-SRx server using the RPKI to Router protocol (rfc6810)
as well as WireShark modules for debugging.

For more information on BGP-SRx, and to download the prototype and tools, see:
http://www-x.antd.nist.gov/bgpsrx/

Comments and feedback about BGP-SRx are welcome. See the project page for details.

Thanks,
Oliver Borchert
-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238



-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238


From chip at 2bithacker.net  Mon Apr  8 20:46:12 2013
From: chip at 2bithacker.net (Chip Marshall)
Date: Mon, 8 Apr 2013 16:46:12 -0400
Subject: need help about free bandwidth graph program
In-Reply-To: <CA+qj4S9wNgMyzWWkZKmRt+a96Sf3OKkqQdsH8JbDnMjXaP65bA@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
 <CA+qj4S9wNgMyzWWkZKmRt+a96Sf3OKkqQdsH8JbDnMjXaP65bA@mail.gmail.com>
Message-ID: <20130408204612.GD34962@2bithacker.net>

On 2013-04-08, Andrew Latham <lathama at gmail.com> sent:
> Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want.
> 
> www: http://www.cacti.net/index.php

If we're talking SNMP counters, Observium might be worth a look.

http://www.observium.org/

-- 
Chip Marshall <chip at 2bithacker.net>
http://2bithacker.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130408/4d5815fa/attachment.bin>

From sam at themerritts.org  Mon Apr  8 20:50:00 2013
From: sam at themerritts.org (Sam Hayes Merritt, III)
Date: Mon, 8 Apr 2013 15:50:00 -0500 (CDT)
Subject: need help about free bandwidth graph program
In-Reply-To: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1304081549480.13095@sam>


> Do you know any opensource program bandwidthgraph by ipaddess?

What are you trying to accomplish?

sam


From jloiacon at csc.com  Mon Apr  8 21:17:37 2013
From: jloiacon at csc.com (Joe Loiacono)
Date: Mon, 8 Apr 2013 17:17:37 -0400
Subject: need help about free bandwidth graph program
In-Reply-To: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
Message-ID: <OFBDD017D4.F1C2A2C7-ON85257B47.00749EF5-85257B47.0074F859@csc.com>

If you can export netflow you can use the FlowViewer / flow-tools / SiLK 
open-source toolset. It can track bandwidth over time according to any 
filter you provide it, including IP address. User interface includes an 
updating dashboard.

http://sourceforge.net/projects/flowviewer

Joe



From:   Deric Kwok <deric.kwok2000 at gmail.com>
To:     nanog list <nanog at nanog.org>
Date:   04/08/2013 03:57 PM
Subject:        need help about free bandwidth graph program



Hi all

Do you know any opensource program bandwidthgraph by ipaddess?

Thank you


From huasong at kalorama.com  Mon Apr  8 01:45:28 2013
From: huasong at kalorama.com (Huasong Zhou)
Date: Mon, 8 Apr 2013 01:45:28 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>, 
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>,
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>,
 <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
Message-ID: <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>

We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers.

Joe

Sent from my iPhone

On Apr 7, 2013, at 9:11 PM, "Rajiv Asati (rajiva)" <rajiva at cisco.com> wrote:

> Nope. Comcast is not using any CGN, as much as I know.
> 
> Is your MacBook directly connected to the modem or a router? I presume the latter.
> 
> Cheers,
> Rajiv
> 
> Sent from my Phone
> 
> On Apr 7, 2013, at 11:47 AM, "Huasong Zhou" <huasong at kalorama.com> wrote:
> 
>> I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.
>> 
>> Joe
>> 
>> Sent from my iPhone
>> 
>> On Apr 6, 2013, at 9:33 PM, "Joshua Smith" <juicewvu at gmail.com> wrote:
>> 
>>> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. 
>>> 
>>> -- 
>>> Josh Smith
>>> kD8HRX
>>> 
>>> email/jabber: juicewvu at gmail.com
>>> Phone: 304.237.9369(c)
>>> 
>>> Sent from my iPad
>>> 
>>> 
>>> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>>> 
>>>> Interesting.
>>>> 
>>>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
>> 


From rajiva at cisco.com  Mon Apr  8 21:38:15 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 21:38:15 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <51631F1B.2060106@gmail.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D5FE@xmb-rcd-x06.cisco.com>

Hi Tom,

Good question. 

The End-user IPv6 prefix can be constructed using whatever techniques
independent of MAP etc. in any deployment requiring IPv4 address sharing.

What is interesting is that the MAP enabled CPE could parse certain bits
of that IPv6 prefix to mean something for MAP. That's it. Attached is a
screenshot to illustrate this very point.

Cheers,
Rajiv

-----Original Message-----
From: Tom Taylor <tom.taylor.stds at gmail.com>
Date: Monday, April 8, 2013 3:48 PM
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>In what sense do you mean that? The end-user IPv6 prefix certainly ties
>IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over
>IPv6 alternative.
>
>Tom
>
>On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:
>> Chris,
>>
>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
>> encumbered?
>>
>> If so, the answer is Yes. v6 addressing doesn't need to change to
>> accommodate this IPv4 A+P encoding.
>>
>>
>> Cheers,
>> Rajiv
>>
>...
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.jpg
Type: image/jpeg
Size: 87785 bytes
Desc: default.jpg
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130408/3023314c/attachment-0001.jpg>

From rajiva at cisco.com  Mon Apr  8 22:03:49 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Mon, 8 Apr 2013 22:03:49 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <CAL9jLaZ+Oindzm_qwTMPQ2pQDKondD8KVu8ZfMcF54ZW9bH9ww@mail.gmail.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D86C@xmb-rcd-x06.cisco.com>

Chris,

Your points are well taken.


Cheers,
Rajiv

-----Original Message-----
From: Christopher Morrow <morrowc.lists at gmail.com>
Date: Monday, April 8, 2013 3:57 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Chuck Anderson <cra at WPI.EDU>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>
>
>On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva)
><rajiva at cisco.com> wrote:
>
>Chris,
>
>That's an incorrect draft pointer. Here is the correct one -
>
>http://tools.ietf.org/html/draft-ietf-softwire-map
>tools.ietf.org/html/draft-ietf-softwire-map-t
><http://tools.ietf.org/html/draft-ietf-softwire-map-t>
>http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp
>
>
>
>
>
>great, but still a draft, not an official standard.
> 
>
>And no, Cisco has no IPR on MAP wrt the above drafts.
>
>
>
>
>
>'yet'... they don't have to officially declare until WGLC... and REALLY
>not until the draft is sent up to the IESG, but doing it early is
>certainly nice so that the WG has an opportunity to say: "yea, IPR here
>is going to cause a problem with
> interop/etc".
> 
>
>Cheers,
>Rajiv
>
>PS: Please do note that the IPRs mostly get nullified once they are
>through the IETF standards process.
>
>
>
>
>
>
>that's not been my experience.. see flow-spec for a great example.
>'mostly nullified' is .. disingenuous at best.
> 
>
>
>
>
>-----Original Message-----
>From: Christopher Morrow <morrowc.lists at gmail.com>
>
>Date: Monday, April 8, 2013 3:41 PM
>To: Rajiv Asati <rajiva at cisco.com>
>
>Cc: Chuck Anderson <cra at WPI.EDU>, nanog list <nanog at nanog.org>
>Subject: Re: Verizon DSL moving to CGN
>
>>
>>
>>
>>On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
>><rajiva at cisco.com> wrote:
>>
>>Oh, it certainly is (per the IETF IPR rules).
>>
>>
>>
>>
>>
>>which rfcs? I can find a draft in softwire:
>>   
>http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
><http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01>
>>
>>
>>and a reference to this in wikipedia:
>>  http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP
>>
>>
>>which says: "...(MAP) is a Cisco IPv6 transition proposal..."
>>
>>
>>so.. err, we won't see this in juniper gear since:
>>  1) not a standard
>>  2) encumbered by IPR issues
>>
>>
>>weee!
>>
>>
>>Thanks for the clarity, Chuck.
>>
>>Cheers,
>>Rajiv
>>
>>-----Original Message-----
>>From: Chuck Anderson <cra at WPI.EDU>
>>Date: Monday, April 8, 2013 3:18 PM
>>To: Rajiv Asati <rajiva at cisco.com>
>>
>>Cc: Christopher Morrow <morrowc.lists at gmail.com>, nanog list
>><nanog at nanog.org>
>>Subject: Re: Verizon DSL moving to CGN
>>
>>>I think he means patent encumbered.
>>>
>>>On Mon, Apr 08, 2013 at 07:13:11PM +0000, Rajiv Asati (rajiva) wrote:
>>>> Chris,
>>>>
>>>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
>>>> encumbered?
>>>>
>>>> If so, the answer is Yes. v6 addressing doesn't need to change to
>>>> accommodate this IPv4 A+P encoding.
>>>>
>>>>
>>>> Cheers,
>>>> Rajiv
>>>>
>>>> -----Original Message-----
>>>> From: Christopher Morrow <morrowc.lists at gmail.com>
>>>> Date: Monday, April 8, 2013 2:28 PM
>>>> To: Rajiv Asati <rajiva at cisco.com>
>>>> Cc: Mikael Abrahamsson <swmike at swm.pp.se>, nanog list
>>>><nanog at nanog.org>
>>>> Subject: Re: Verizon DSL moving to CGN
>>>>
>>>> >
>>>> >On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva)
>>>> ><rajiva at cisco.com> wrote:
>>>> >
>>>> >Yes, MAP (T-Translation or E-Encap mode) is implemented on two
>>>>regular
>>>> >routers that I know of - ASR9K and ASR1K. Without that, you are right
>>>>that
>>>> >MAP wouldn't have been as beneficial as claimed.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >glad it's cross platform... is it also IP encumbered so it'll remain
>>>>just
>>>> >as 'cross platform' ?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>
>



From jra at baylink.com  Mon Apr  8 23:10:38 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 8 Apr 2013 19:10:38 -0400 (EDT)
Subject: Verizon DSL moving to CGN
In-Reply-To: <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>
Message-ID: <25927166.1364.1365462638376.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Huasong Zhou" <huasong at kalorama.com>

> We got this modem and router all in one box from Comcast directly. And
> by the way, home use routers don't assign 10.0.0.0 numbers.

I have seen consumer NAT routers assign addresses in all three RFC1918
blocks, though I couldn't cite particular models for you.  10./ is less
common than 172./, but not impossible.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From owen at delong.com  Tue Apr  9 00:49:35 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Apr 2013 17:49:35 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <5162DB0A.2000908@bogus.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <CAPKkNb5QLynunmMkcLusMgDHGb9C1RhH0Hv+YWt+SigvWdowtA@mail.gmail.com>
 <516102A9.2040301@studio442.com.au>
 <CAL9jLaa63gKOxCKaqiJ6ebDEQEbNB7dr-P-z+kiA-Kctv8i-Yg@mail.gmail.com>
 <alpine.DEB.2.00.1304070839110.23668@uplift.swm.pp.se>
 <CA16D726-8B13-4DAE-94C1-6AB609002712@mac.com>,
 <alpine.DEB.2.00.1304070925230.23668@uplift.swm.pp.se>
 <8BEC0BF0-D130-46F6-8C2E-A5E982588555@cisco.com>
 <alpine.DEB.2.00.1304081159420.23668@uplift.swm.pp.se>
 <51629C0B.30801@fud.no> <5162B623.5030301@fud.no>
 <5162D2C7.5020907@brightok.net> <5162DB0A.2000908@bogus.com>
Message-ID: <C15C05AE-0573-4162-899B-A4404445122C@delong.com>


On Apr 8, 2013, at 07:58 , joel jaeggli <joelja at bogus.com> wrote:

> On 4/8/13 7:23 AM, Jack Bates wrote:
>> On 4/8/2013 7:20 AM, Tore Anderson wrote:
>>> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>>> address or even a prefix to the subscriber, thus also taking away the
>>> need for [srcport-restricted] NAPT44 in the CPE.
>> 
>> The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases.
>> 
> That happened a long time ago. I realize the people like to think of wireless providers as different, they really aren't. A big chuck of our mobile gaming customers come to us via carrier operated nat translators. Some of them now come to us via ipv6, most do not.
>> The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs.
>> 
>> Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly.
>> 
>> The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though.
>> 
>> I am sure Verizon did a lot of cost analysis.
>> 
>> Jack
>> 
> 

There is actually a key difference. In the US, at least, everyone is used to the cellular networks mostly sucking.

They are willing to put up with far more degraded service over wireless than they will tolerate on a wired connection.

You and I and everyone else on this list realize that this is complete BS, but the majority of the general public tolerates it, so it persists.

Owen



From tom.taylor.stds at gmail.com  Tue Apr  9 00:51:22 2013
From: tom.taylor.stds at gmail.com (Tom Taylor)
Date: Mon, 08 Apr 2013 20:51:22 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D5FE@xmb-rcd-x06.cisco.com>
References: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160D5FE@xmb-rcd-x06.cisco.com>
Message-ID: <5163660A.6090006@gmail.com>

I think what that screenshot is saying is that after you deploy MAP, 
then if you stop using it the IPv6 addresses don't need to change. I 
would assume you're not saying that you can take your IPv6 addresses as 
you find them and interpret them as MAP End-user prefixes.

Tom

On 08/04/2013 5:38 PM, Rajiv Asati (rajiva) wrote:
> Hi Tom,
>
> Good question.
>
> The End-user IPv6 prefix can be constructed using whatever techniques
> independent of MAP etc. in any deployment requiring IPv4 address sharing.
>
> What is interesting is that the MAP enabled CPE could parse certain bits
> of that IPv6 prefix to mean something for MAP. That's it. Attached is a
> screenshot to illustrate this very point.
>
> Cheers,
> Rajiv
>
> -----Original Message-----
> From: Tom Taylor <tom.taylor.stds at gmail.com>
> Date: Monday, April 8, 2013 3:48 PM
> To: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: Verizon DSL moving to CGN
>
>> In what sense do you mean that? The end-user IPv6 prefix certainly ties
>> IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over
>> IPv6 alternative.
>>
>> Tom
>>
>> On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:
>>> Chris,
>>>
>>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
>>> encumbered?
>>>
>>> If so, the answer is Yes. v6 addressing doesn't need to change to
>>> accommodate this IPv4 A+P encoding.
>>>
>>>
>>> Cheers,
>>> Rajiv
>>>
>> ...
>>
>


From owen at delong.com  Tue Apr  9 00:52:12 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Apr 2013 17:52:12 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CC8D@xmb-rcd-x06.cisco.com>
References: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160CC8D@xmb-rcd-x06.cisco.com>
Message-ID: <31C45ACC-076B-4DBD-BE8F-B848A26006F1@delong.com>


On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) <rajiva at cisco.com> wrote:

> 
> Like you, I would like to be optimistic about many v4-only apps and
> v4-only devices becoming dual-stack sooner than later.
> 
> But knowing that a significant (50%+) of android devices may not support
> IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
> the weekend) being v4-only) and may not be upgraded by their users to the
> right software, and that Skype etc. apps are out there, my optimism fades
> away.

The upgrade problem isn't that hard to solve. As soon as users want to use
something that doesn't work without the upgrade, the upgrades get installed.

Apple does a great job of this...

Every time they release an iOS upgrade I really don't want, they manage to
also release an update to software that I do care about. That software update
inherently requires me to accept the iOS upgrade.

Owen



From owen at delong.com  Tue Apr  9 00:55:44 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Apr 2013 17:55:44 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>,
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>,
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>,
 <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
 <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>
Message-ID: <7DBEFFF3-E58A-4FC4-A872-0E74FCC8276E@delong.com>


On Apr 7, 2013, at 18:45 , Huasong Zhou <huasong at kalorama.com> wrote:

> We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers.
> 

Some do.

Owen

> Joe
> 
> Sent from my iPhone
> 
> On Apr 7, 2013, at 9:11 PM, "Rajiv Asati (rajiva)" <rajiva at cisco.com> wrote:
> 
>> Nope. Comcast is not using any CGN, as much as I know.
>> 
>> Is your MacBook directly connected to the modem or a router? I presume the latter.
>> 
>> Cheers,
>> Rajiv
>> 
>> Sent from my Phone
>> 
>> On Apr 7, 2013, at 11:47 AM, "Huasong Zhou" <huasong at kalorama.com> wrote:
>> 
>>> I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either.
>>> 
>>> Joe
>>> 
>>> Sent from my iPhone
>>> 
>>> On Apr 6, 2013, at 9:33 PM, "Joshua Smith" <juicewvu at gmail.com> wrote:
>>> 
>>>> Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. 
>>>> 
>>>> -- 
>>>> Josh Smith
>>>> kD8HRX
>>>> 
>>>> email/jabber: juicewvu at gmail.com
>>>> Phone: 304.237.9369(c)
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> 
>>>> On Apr 6, 2013, at 9:24 PM, "cb.list6" <cb.list6 at gmail.com> wrote:
>>>> 
>>>>> Interesting.
>>>>> 
>>>>> http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
>>> 



From sethm at rollernet.us  Tue Apr  9 01:23:51 2013
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 08 Apr 2013 18:23:51 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <7DBEFFF3-E58A-4FC4-A872-0E74FCC8276E@delong.com>
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>,
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>,
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>,
 <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
 <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>
 <7DBEFFF3-E58A-4FC4-A872-0E74FCC8276E@delong.com>
Message-ID: <51636DA7.5040207@rollernet.us>

On 4/8/13 5:55 PM, Owen DeLong wrote:
> 
> On Apr 7, 2013, at 18:45 , Huasong Zhou <huasong at kalorama.com> wrote:
> 
>> We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers.
>>
> 
> Some do.
> 

AT&T U-verse used to have 10.0.0.0/8 as an option until a firmware
update removed that capability. My bet is on CGN prep work.

~Seth


From rajiva at cisco.com  Tue Apr  9 03:19:55 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Tue, 9 Apr 2013 03:19:55 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <5163660A.6090006@gmail.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160E99F@xmb-rcd-x06.cisco.com>

Hi Tom,

The key take-away is that MAP doesn't _necessarily_ require IPv6 prefix to
be constructed in a special way (so as to encode the IPv4 address inside
it).
 

Please see more inline,

> I think what that screenshot is saying is that after you deploy MAP,
> then if you stop using it the IPv6 addresses don't need to change.

Yes. 

> I would assume you're not saying that you can take your IPv6 addresses as
> you find them and interpret them as MAP End-user prefixes.

It can work even in that realm as well (IPv6 PD assumed). There are pros &
cons of doing this, suffice to say.

Cheers,

Rajiv


-----Original Message-----
From: Tom Taylor <tom.taylor.stds at gmail.com>
Date: Monday, April 8, 2013 8:51 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>I think what that screenshot is saying is that after you deploy MAP,
>then if you stop using it the IPv6 addresses don't need to change. I
>would assume you're not saying that you can take your IPv6 addresses as
>you find them and interpret them as MAP End-user prefixes.
>
>Tom
>
>On 08/04/2013 5:38 PM, Rajiv Asati (rajiva) wrote:
>> Hi Tom,
>>
>> Good question.
>>
>> The End-user IPv6 prefix can be constructed using whatever techniques
>> independent of MAP etc. in any deployment requiring IPv4 address
>>sharing.
>>
>> What is interesting is that the MAP enabled CPE could parse certain bits
>> of that IPv6 prefix to mean something for MAP. That's it. Attached is a
>> screenshot to illustrate this very point.
>>
>> Cheers,
>> Rajiv
>>
>> -----Original Message-----
>> From: Tom Taylor <tom.taylor.stds at gmail.com>
>> Date: Monday, April 8, 2013 3:48 PM
>> To: "nanog at nanog.org" <nanog at nanog.org>
>> Subject: Re: Verizon DSL moving to CGN
>>
>>> In what sense do you mean that? The end-user IPv6 prefix certainly ties
>>> IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4
>>>over
>>> IPv6 alternative.
>>>
>>> Tom
>>>
>>> On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:
>>>> Chris,
>>>>
>>>> Ummm? you mean the IPv6 and IPv4 inter-dependency when you say IP
>>>> encumbered?
>>>>
>>>> If so, the answer is Yes. v6 addressing doesn't need to change to
>>>> accommodate this IPv4 A+P encoding.
>>>>
>>>>
>>>> Cheers,
>>>> Rajiv
>>>>
>>> ...
>>>
>>



From rajiva at cisco.com  Tue Apr  9 03:23:16 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Tue, 9 Apr 2013 03:23:16 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <31C45ACC-076B-4DBD-BE8F-B848A26006F1@delong.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160E9C5@xmb-rcd-x06.cisco.com>

I agree. Apple does it really well, no doubt about it. This is because
they control both the software and hardware.

Google/Android ?an not do it well enough, since the Android OS version
compatibility with the hardware is somewhat dictated by the hardware
manufacturer. This isn't always helpful. :-(

	For ex, there are numerous android apps that are not supported
	on many android devices. :=(

Anyway, this is why I think that dual-stack home networks (and UEs) will
be with us for a long time.

Cheers,
Rajiv



-----Original Message-----
From: Owen DeLong <owen at delong.com>
Date: Monday, April 8, 2013 8:52 PM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Fabien Delmotte <fdelmotte1 at mac.com>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) <rajiva at cisco.com> wrote:
>
>> 
>> Like you, I would like to be optimistic about many v4-only apps and
>> v4-only devices becoming dual-stack sooner than later.
>> 
>> But knowing that a significant (50%+) of android devices may not support
>> IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
>> the weekend) being v4-only) and may not be upgraded by their users to
>>the
>> right software, and that Skype etc. apps are out there, my optimism
>>fades
>> away.
>
>The upgrade problem isn't that hard to solve. As soon as users want to use
>something that doesn't work without the upgrade, the upgrades get
>installed.
>
>Apple does a great job of this...
>
>Every time they release an iOS upgrade I really don't want, they manage to
>also release an update to software that I do care about. That software
>update
>inherently requires me to accept the iOS upgrade.
>
>Owen
>



From owen at delong.com  Tue Apr  9 04:01:08 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Apr 2013 21:01:08 -0700
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160E9C5@xmb-rcd-x06.cisco.com>
References: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160E9C5@xmb-rcd-x06.cisco.com>
Message-ID: <834C9CDF-AB1C-47C3-92EB-4B430B3B8FD1@delong.com>


On Apr 8, 2013, at 20:23 , "Rajiv Asati (rajiva)" <rajiva at cisco.com> wrote:

> I agree. Apple does it really well, no doubt about it. This is because
> they control both the software and hardware.
> 
> Google/Android ?an not do it well enough, since the Android OS version
> compatibility with the hardware is somewhat dictated by the hardware
> manufacturer. This isn't always helpful. :-(
> 

But they can actually push pretty well if they had some killer app. that everyone
used and could supply some update that nobody could live without on said
killer app.

Then you just need to flag said update as "requires Android version X" and
poof... All the pressure you need to get everyone running droid up to X.
(Including all the pressure needed to get consumers to push the device
maker.)

> 	For ex, there are numerous android apps that are not supported
> 	on many android devices. :=(
> 

They must not be very important to the bulk of the android users.

> Anyway, this is why I think that dual-stack home networks (and UEs) will
> be with us for a long time.
> 

I don't doubt that dual-stack home networks will be with us for a long time.
What won't be with us for very long is routing IPv4 across service providers.
It can't. It will become far too expensive to do so. The economics aren't going
to work much past about 5 years, maybe 10 if we're really unlucky.


Owen

> Cheers,
> Rajiv
> 
> 
> 
> -----Original Message-----
> From: Owen DeLong <owen at delong.com>
> Date: Monday, April 8, 2013 8:52 PM
> To: Rajiv Asati <rajiva at cisco.com>
> Cc: Fabien Delmotte <fdelmotte1 at mac.com>, nanog list <nanog at nanog.org>
> Subject: Re: Verizon DSL moving to CGN
> 
>> 
>> On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) <rajiva at cisco.com> wrote:
>> 
>>> 
>>> Like you, I would like to be optimistic about many v4-only apps and
>>> v4-only devices becoming dual-stack sooner than later.
>>> 
>>> But knowing that a significant (50%+) of android devices may not support
>>> IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
>>> the weekend) being v4-only) and may not be upgraded by their users to
>>> the
>>> right software, and that Skype etc. apps are out there, my optimism
>>> fades
>>> away.
>> 
>> The upgrade problem isn't that hard to solve. As soon as users want to use
>> something that doesn't work without the upgrade, the upgrades get
>> installed.
>> 
>> Apple does a great job of this...
>> 
>> Every time they release an iOS upgrade I really don't want, they manage to
>> also release an update to software that I do care about. That software
>> update
>> inherently requires me to accept the iOS upgrade.
>> 
>> Owen
>> 



From morrowc.lists at gmail.com  Tue Apr  9 04:10:00 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 9 Apr 2013 00:10:00 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160E9C5@xmb-rcd-x06.cisco.com>
References: <31C45ACC-076B-4DBD-BE8F-B848A26006F1@delong.com>
 <B14A62A57AB87D45BB6DD7D9D2B78F0B1160E9C5@xmb-rcd-x06.cisco.com>
Message-ID: <CAL9jLab3XBX2F=XsQGcU1MkQAxObem_Gdvh1VCt91an3phoXqQ@mail.gmail.com>

On Mon, Apr 8, 2013 at 11:23 PM, Rajiv Asati (rajiva) <rajiva at cisco.com>wrote:

> For ex, there are numerous android apps that are not supported
>         on many android devices. :=(
>

I think this is actually up to the developer of the APP not the hardware
nor OS manufacturer.

From rajiva at cisco.com  Tue Apr  9 04:24:30 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Tue, 9 Apr 2013 04:24:30 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <834C9CDF-AB1C-47C3-92EB-4B430B3B8FD1@delong.com>
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B1160EEF8@xmb-rcd-x06.cisco.com>


> I don't doubt that dual-stack home networks will be with us for a long
>time.
> What won't be with us for very long is routing IPv4 across service
>providers.
> It can't. It will become far too expensive to do so. The economics
>aren't going
> to work much past about 5 years, maybe 10 if we're really unlucky.

Of course. :)

Cheers,

Rajiv

-----Original Message-----
From: Owen DeLong <owen at delong.com>
Date: Tuesday, April 9, 2013 12:01 AM
To: Rajiv Asati <rajiva at cisco.com>
Cc: Fabien Delmotte <fdelmotte1 at mac.com>, nanog list <nanog at nanog.org>
Subject: Re: Verizon DSL moving to CGN

>
>On Apr 8, 2013, at 20:23 , "Rajiv Asati (rajiva)" <rajiva at cisco.com>
>wrote:
>
>> I agree. Apple does it really well, no doubt about it. This is because
>> they control both the software and hardware.
>> 
>> Google/Android ?an not do it well enough, since the Android OS version
>> compatibility with the hardware is somewhat dictated by the hardware
>> manufacturer. This isn't always helpful. :-(
>> 
>
>But they can actually push pretty well if they had some killer app. that
>everyone
>used and could supply some update that nobody could live without on said
>killer app.
>
>Then you just need to flag said update as "requires Android version X" and
>poof... All the pressure you need to get everyone running droid up to X.
>(Including all the pressure needed to get consumers to push the device
>maker.)
>
>> 	For ex, there are numerous android apps that are not supported
>> 	on many android devices. :=(
>> 
>
>They must not be very important to the bulk of the android users.
>
>> Anyway, this is why I think that dual-stack home networks (and UEs) will
>> be with us for a long time.
>> 
>
>I don't doubt that dual-stack home networks will be with us for a long
>time.
>What won't be with us for very long is routing IPv4 across service
>providers.
>It can't. It will become far too expensive to do so. The economics aren't
>going
>to work much past about 5 years, maybe 10 if we're really unlucky.
>
>
>Owen
>
>> Cheers,
>> Rajiv
>> 
>> 
>> 
>> -----Original Message-----
>> From: Owen DeLong <owen at delong.com>
>> Date: Monday, April 8, 2013 8:52 PM
>> To: Rajiv Asati <rajiva at cisco.com>
>> Cc: Fabien Delmotte <fdelmotte1 at mac.com>, nanog list <nanog at nanog.org>
>> Subject: Re: Verizon DSL moving to CGN
>> 
>>> 
>>> On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) <rajiva at cisco.com>
>>>wrote:
>>> 
>>>> 
>>>> Like you, I would like to be optimistic about many v4-only apps and
>>>> v4-only devices becoming dual-stack sooner than later.
>>>> 
>>>> But knowing that a significant (50%+) of android devices may not
>>>>support
>>>> IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought
>>>>over
>>>> the weekend) being v4-only) and may not be upgraded by their users to
>>>> the
>>>> right software, and that Skype etc. apps are out there, my optimism
>>>> fades
>>>> away.
>>> 
>>> The upgrade problem isn't that hard to solve. As soon as users want to
>>>use
>>> something that doesn't work without the upgrade, the upgrades get
>>> installed.
>>> 
>>> Apple does a great job of this...
>>> 
>>> Every time they release an iOS upgrade I really don't want, they
>>>manage to
>>> also release an update to software that I do care about. That software
>>> update
>>> inherently requires me to accept the iOS upgrade.
>>> 
>>> Owen
>>> 
>



From rs at seastrom.com  Tue Apr  9 10:45:34 2013
From: rs at seastrom.com (Rob Seastrom)
Date: Tue, 09 Apr 2013 06:45:34 -0400
Subject: Verizon DSL moving to CGN
In-Reply-To: <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com> (Huasong
 Zhou's message of "Mon, 8 Apr 2013 01:45:28 +0000")
References: <CAD6AjGTMz-rpx8UOX7QNpqr8x3ESQEo34m+6EpNquumnzDLRdA@mail.gmail.com>
 <5C944EFC-CD47-4569-9452-5133B5F780E9@gmail.com>
 <41AFA410-8A46-40D4-89F6-161C65275AE7@kalorama.com>
 <D135230D-BE9A-4818-BC44-0C0365261AA3@cisco.com>
 <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>
Message-ID: <86fvz0j835.fsf@valhalla.seastrom.com>


Huasong Zhou <huasong at kalorama.com> writes:

> We got this modem and router all in one box from Comcast directly.

OK, so the NAT is taking place in the router you got from Comcast, not
in Carrier Grade NAT in Comcast's network.  A fine distinction but an
important one.  The external address of your router is (a) globally
unique, and (b) not shared with any other customer.

> And by the way, home use routers don't assign 10.0.0.0 numbers.

Who told you that?

I offer you as a counterexample (all?  maybe just every one I've
owned?) the Airports from Apple.  Default LAN address is 10.0.1.1.

-r




From seth.mos at dds.nl  Tue Apr  9 11:28:30 2013
From: seth.mos at dds.nl (Seth Mos)
Date: Tue, 09 Apr 2013 13:28:30 +0200
Subject: Verizon DSL moving to CGN
In-Reply-To: <25927166.1364.1365462638376.JavaMail.root@benjamin.baylink.com>
References: <25927166.1364.1365462638376.JavaMail.root@benjamin.baylink.com>
Message-ID: <5163FB5E.5090701@dds.nl>

On 9-4-2013 1:10, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Huasong Zhou" <huasong at kalorama.com>
> 
>> We got this modem and router all in one box from Comcast directly. And
>> by the way, home use routers don't assign 10.0.0.0 numbers.
> 
> I have seen consumer NAT routers assign addresses in all three RFC1918
> blocks, though I couldn't cite particular models for you.  10./ is less
> common than 172./, but not impossible.

Early Alcatel/Lucent Speedtouch modems assigned 10/8 to the LAN,
effectively breaking all VPN networking to our office. No fun to be had
in that one. Luckily all these shipped without Wifi and have now all
been replaced by Thomson wifi models that use 192.168.[01]/24

Some of the AlliedData Copperjet modems use 172.x

Regards,

Seth


From kpospisek at bigpond.com  Tue Apr  9 12:11:48 2013
From: kpospisek at bigpond.com (kpospisek at bigpond.com)
Date: Tue, 09 Apr 2013 22:11:48 +1000
Subject: Verizon DSL moving to CGN
Message-ID: <op.wu9v5yvyhnppdy@soprano.home>

Quoting:

> Date: Sun, 7 Apr 2013 09:31:22 +0200 (CEST)
> From: Mikael Abrahamsson <swmike at swm.pp.se>
> To: nanog list <nanog at nanog.org>
> Subject: Re: Verizon DSL moving to CGN

> On Sun, 7 Apr 2013, Fabien Delmotte wrote:

>> CGN is just a solution to save time, it is not a transition mechanism  
>> through IPv6
>> At the end (IPv6 at home) you will need at list :
>> Dual stack or NAT64/ DNS64

> CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the 
> water without other mechanisms (464XLAT or alike).

Defusing the "dead-in-the-water" phrase:
An IPv4 solution with NAT64/DNS64 will still enable pure IPv6 SS devices
without built-in NAT46 to still access the majority of the IPV4 world.
(There are few IPV4-over-IPv6 technologies that can make a similar claim
so thats already one step ahead of the competition on the IPv4 sunset path)

XLAT464 (CLAT46+PLAT64) is now published as RFC6877. It is the most mature
sunset technology - Is a single vendor offering out there that either does
not already have a NAT64 function or doesn't have it in their roadmaps ?

Greets Karl Pospisek from Melbourne AU.


From tom.laermans at phyxia.net  Tue Apr  9 12:59:37 2013
From: tom.laermans at phyxia.net (Tom Laermans)
Date: Tue, 09 Apr 2013 14:59:37 +0200
Subject: Open Resolver Dataset Update
In-Reply-To: <BCCE3736-E0D5-4F52-9A09-87D79F0CD156@puck.nether.net>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
 <51626CF9.1040109@phyxia.net>
 <BCCE3736-E0D5-4F52-9A09-87D79F0CD156@puck.nether.net>
Message-ID: <1365512377.22965.76.camel@galaxy>

Jared,

If you mean there can be a referral with RCODE=0 and Recursion Available
= 0, you'll need a third column actually documenting if there is a
referral.

This server is listed in ORP:

$ dig www.google.be @195.160.166.139

; <<>> DiG 9.7.3 <<>> www.google.be @195.160.166.139
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 615
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.google.be.                 IN      A

;; Query time: 6 msec
;; SERVER: 195.160.166.139#53(195.160.166.139)
;; WHEN: Tue Apr  9 14:58:21 2013
;; MSG SIZE  rcvd: 31

RCODE=0, Recursion available=0:
	
http://openresolverproject.org/search.cgi?mode=search6&search_for=195.160.166.0%2F24

Hence my question, what is it doing wrong?

Tom

On Mon, 2013-04-08 at 07:05 -0400, Jared Mauch wrote:
> The referral, including a referral to root can be quite large. Even larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. 
> 
> Jared Mauch
> 
> On Apr 8, 2013, at 3:08 AM, Tom Laermans <tom.laermans at phyxia.net> wrote:
> 
> > As far as I know, responding either NOERROR or REFUSED produces packets of the same size.




From eugen at leitl.org  Tue Apr  9 13:09:34 2013
From: eugen at leitl.org (Eugen Leitl)
Date: Tue, 9 Apr 2013 15:09:34 +0200
Subject: Closing the gap to improve the capacity of existing fiber optic
 networks
Message-ID: <20130409130934.GS6172@leitl.org>


http://www.gizmag.com/cudos-fiber-optic-network-capacity/26969/

Closing the gap to improve the capacity of existing fiber optic networks

By Darren Quick

April 7, 2013

Researchers claim to have increased the data capacity of optical networks to
the point that all of the world?s internet traffic could be transmitted via a
single fiber (Photo: Shutterstock)

A team of researchers working through Australia?s Centre for Ultrahigh
Bandwidth Devices for Optical Systems (CUDOS) has developed data encoding
technology that increases the efficiency of existing fiber optic cable
networks. The researchers claim their invention increases the data capacity
of optical networks to the point that all of the world?s internet traffic
could be transmitted via a single fiber.

Compatible with existing networks, the data encoding technology involves
making more efficient use of available data channels. Where existing networks
transmit data with gaps between the channels, the new approach packs the data
channels closer together, thereby allowing more lanes on the same
super-highway.

To demonstrate the system, the researchers re-programmed a LCoS (liquid
crystal on silicon) Wavelength Selective Switch (WSS) to make more efficient
use of available data channels. A WWS is a network component that uses
different wavelengths of laser light to combine (or multiplex) multiple
digital data streams onto a single optical fiber.

The research team, which included Professor Arthur Lowery and Dr Liang Du of
the Monash Department of Electrical and Computer Systems Engineering and
Jochen Schroeder, Joel Carpenter and Ben Eggleton from the University of
Sydney, managed to transmit a signal of 10 terabits per second (Tb/s) more
than 850 km (528 miles) using the new technology.

That?s still well short of the 26 Tb/s data transmission speeds achieved by
scientists at Germany's Karlsruhe Institute of Technology (KIT), but is over
a far greater distance than the 50 km (31 miles) that team achieved.

Professor Lowry said that the switch could be used to squeeze signals into
the gaps in data traffic that flows around large optical-ring networks
between cities. "Importantly, new traffic can be squeezed into the fiber at
any location and added to any ?lane? of the fiber freeway even between
existing lanes,? he said. "Rather than laying hundreds of new parallel
optical fibers to boost network capacity, we can make more efficient use of
the existing network by tweaking the way data is transmitted over long
distances."

?Our approach is so flexible, network operators could adjust capacity to
respond to increased demand, for example from people following big sport
events like the Olympics," added Dr Schr?der.

The team believes the technology would allow existing infrastructure to cope
with the rising demand for internet, which is expected to increase 1,000 fold
over the coming decade, with minimal investment.

"Because we are have made use of equipment that is already on the market,
this technology could be translated to the consumer quite quickly,? said Dr
Du.

The team?s findings were presented last month at the Optical Fiber
Communication Conference in California. It was presented as a postdeadline
paper, which are intended to give attendees the opportunity to hear
breakthrough results in rapidly advancing areas.

Source: CUDOS


From m.hotze at hotze.com  Tue Apr  9 14:24:17 2013
From: m.hotze at hotze.com (Martin Hotze)
Date: Tue, 9 Apr 2013 14:24:17 +0000
Subject: cloudmark?
Message-ID: <F02A0931E2E6254680832D6A24940C2DEC5989@hx01.srv.hotze.com>

Hi,

<rant>
it seems that many large providers are using cloudmark services. As far as I can tell: their policy is unclear, they can hardly be reached, mails to support are bouncing (delayed, then bounce).

yes, the mailserver from one of our customers was blocked and this was OK and rightful, because they had a problem (cracked account). After the problem was resolved we started removing their IPv4 address from blacklists and almost all lists removed the ban immediately.

cloudmark CSI service (reset request form) wants a form to be filled ... and they claim that they send out an email ... but it doesn't make its way to my inbox (no, no filters ...)

and support can't be reached.

Where are the good old times when the 'net was controlled by techs and not by lawyers?

I can't recommend cloudmark.
</rant>

greetings, martin




From saku at ytti.fi  Tue Apr  9 14:28:34 2013
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 9 Apr 2013 17:28:34 +0300
Subject: ipfix analyzers
Message-ID: <20130409142834.GA13334@pob.ytti.fi>

Can someone point me to IPFIX analysers that do automatic learning of
traffic patterns, raise events as suspected dos, and when operator marked
as false positive, won't trigger that pattern anymore?

This should be without configuring any explicit network ranges anywhere. So
when I do get new customer, I don't have to teach the system about it.

At simplest, maybe it could be static n pps / n Mbps per IP, then keep
hitting false positive button, until they disappear.


Other thing I'm missing from Arbor, is as far as I can see, it does not
really like IXP. I don't know how you can ask via webUI to show traffic
from ASNX in IXP port Y.
I can ask traffic in port X or traffic in ASNX, but not traffic in ASNX in
port X. You can dig this out of IPFIX data really easily.


Both of these seem really trivial issues, frankly not much more than full
work day to produce in homegrown IPFIX analyzer if you don't have to
worry about bigdata/scaling (which I do).
But is there product I can buy, which satisfies these requirements?


-- 
  ++ytti


From cconn at b2b2c.ca  Tue Apr  9 14:31:08 2013
From: cconn at b2b2c.ca (Chris Conn)
Date: Tue, 09 Apr 2013 10:31:08 -0400
Subject: cloudmark?
In-Reply-To: <BC9F9D596E830D42A82E033F335210771906D584@SBS.B2B2Cinc.local>
References: <BC9F9D596E830D42A82E033F335210771906D584@SBS.B2B2Cinc.local>
Message-ID: <5164262C.3070806@b2b2c.ca>

On 2013-04-09 10:27, Chris Conn wrote:
>
> Hi,
>
> <rant>
> it seems that many large providers are using cloudmark services. As far as I can tell: their policy is unclear, they can hardly be reached, mails to support are bouncing (delayed, then bounce).
>
> yes, the mailserver from one of our customers was blocked and this was OK and rightful, because they had a problem (cracked account). After the problem was resolved we started removing their IPv4 address from blacklists and almost all lists removed the ban immediately.
>
> cloudmark CSI service (reset request form) wants a form to be filled ... and they claim that they send out an email ... but it doesn't make its way to my inbox (no, no filters ...)
>
> and support can't be reached.
>
> Where are the good old times when the 'net was controlled by techs and not by lawyers?
>
> I can't recommend cloudmark.
> </rant>
>
>

Your experience does not mirror mine at all.  I have less than 30 
minutes of wait time for any support case, and they are few and far 
between.  Reliability is high and FP rate is low.   I have no idea what 
your reference to lawyers pertains to, however the only issue we have 
ever had was for them to take our money when we renewed for the 
umpteenth time.

Maybe they cater to smaller providers more efficiently.

Chris



From Jason_Livingood at cable.comcast.com  Tue Apr  9 14:41:49 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 9 Apr 2013 14:41:49 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <51636DA7.5040207@rollernet.us>
Message-ID: <10229F86C86EB444898E629583FD41717F2F30A1@PACDCEXMB06.cable.comcast.com>

On 4/8/13 9:23 PM, "Seth Mattinen" <sethm at rollernet.us> wrote:


>On 4/8/13 5:55 PM, Owen DeLong wrote:
>> 
>> On Apr 7, 2013, at 18:45 , Huasong Zhou <huasong at kalorama.com> wrote:
>> 
>>> We got this modem and router all in one box from Comcast directly. And
>>>by the way, home use routers don't assign 10.0.0.0 numbers.
>>>
>> 
>> Some do.
>> 
>
>AT&T U-verse used to have 10.0.0.0/8 as an option until a firmware
>update removed that capability. My bet is on CGN prep work.

No, we (Comcast) are not doing CGN prep work.

Jason Livingood
Comcast



From Jason_Livingood at cable.comcast.com  Tue Apr  9 14:50:00 2013
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Tue, 9 Apr 2013 14:50:00 +0000
Subject: Verizon DSL moving to CGN
In-Reply-To: <FAEB0553-352C-43C1-8B63-107321B1402E@kalorama.com>
Message-ID: <10229F86C86EB444898E629583FD41717F2F310D@PACDCEXMB06.cable.comcast.com>

On 4/7/13 9:45 PM, "Huasong Zhou" <huasong at kalorama.com> wrote:


>We got this modem and router all in one box from Comcast directly. And by
>the way, home use routers don't assign 10.0.0.0 numbers.

Sure they can. And I'm sure if you checked the WAN interface of the device
it has a public IPv4 address.

- Jason




From dave at temk.in  Tue Apr  9 16:38:00 2013
From: dave at temk.in (David Temkin)
Date: Tue, 9 Apr 2013 09:38:00 -0700
Subject: NANOG 58 - New Orleans - Call For Presentations is open!
In-Reply-To: <CAFJiuFpKxKWYk=PxMkTqjUJ-oTRWUJ2pWxmkwAsNq=GxP=nQ_Q@mail.gmail.com>
References: <CAFJiuFpVeKp0m2Sb2dLe3+CqUVgrdSc=ZH3ipCfQaZ38WmftfA@mail.gmail.com>
 <CAFJiuFpKxKWYk=PxMkTqjUJ-oTRWUJ2pWxmkwAsNq=GxP=nQ_Q@mail.gmail.com>
Message-ID: <CAFJiuFq-cQDB_qJ5ULsZ4vj6c3iyWvUQQVsFnYb_O9kYFR63TA@mail.gmail.com>

Reminder-  the RFP closed yesterday but we will continue to accept
submissions through the end of the week.

Regards,
-Dave

On Mon, Mar 25, 2013 at 9:47 AM, David Temkin <dave at temk.in> wrote:

> Just a reminder that the RFP is still open for NANOG 58!
>
> Regards,
> -Dave
>
> On Fri, Mar 1, 2013 at 12:02 PM, David Temkin <dave at temk.in> wrote:
>
>> *Fresh off of a great NANOG 57 in Orlando, your program committee is
>> already working hard to provide a world-class program for NANOG 58 in NOLA
>> - New Orleans, Louisiana - one of my favorite destinations in the world.*
>> *
>> *
>> *As a reminder, we will be following the same Monday-Wednesday program
>> that we started at NANOG 57, with Tutorials beginning Monday morning and
>> closing with the Peering Track (and potentially a social) on Wednesday
>> evening. *
>> *
>> *
>> *We look forward to seeing everyone in The Big Easy!*
>> *
>>
>> --------------------
>>
>> The North American Network Operators' Group (NANOG) will hold its 58th
>> meeting in New Orleans on June 3rd - 5th, 2013  Verizon Terremark will
>> host NANOG 58. The NANOG Program Committee is now seeking proposals for
>> presentations, panels, tutorials, tracks sessions, keynote materials, and
>> the NOGLab experience for the NANOG 58 program. We invite presentations
>> highlighting issues relating to technology already deployed or soon-to-be
>> deployed in the Internet. Vendors are encouraged to work with operators to
>> present real-world deployment experiences with the vendor's products and
>> interoperability via the program and as part of the NOGLab.   NANOG 58
>> submissions are welcome at http://pc.nanog.org.
>>
>> About NANOG
>> NANOG is the premier meeting for network operators in North America.
>> Meetings provide a forum for information exchange among network operators,
>> engineers, and researchers. NANOG meets three times each year, and includes
>> panels, presentations, tutorial sessions, tracks, informal BOFs, and a
>> NOGLab which features interoperability demonstrations. NANOG attendees
>> include operators from networks of all sizes, enterprise operators, peering
>> coordinators, transport and switching equipment vendors, and network
>> researchers. NANOG attendees will share ideas and interact with leaders in
>> the field of network operations, discuss current operational events and
>> issues, and learn about state-of-the-art operational techniques.
>>
>> Materials from NANOG 58 will be archived at:
>> http://www.nanog.org/meetings/nanog58/<http://www.nanog.org/meetings/nanog55/>
>>  <http://www.nanog.org/meetings/nanog55/>
>> Key Dates for NANOG 58
>>
>> ? CFP Opens for NANOG 58: 25-February-2013
>> ? CFP Deadline #1: Presentation Abstracts Due: 8-April-2013
>> ? CFP Deadline #2: Presentation Slides Due: 29-April-2013
>> ? NANOG Highlights Page Posted: 22-April-2013
>> ? Preliminary Topic List Posted: 26-April-2013
>> ? Meeting Agenda Published: 13-May-2013
>> ? Meeting Agenda Final sent to printer: 20-May-2013
>> ? Lightning Talk Submissions Open (Abstracts Only): 2-June-2013
>> ? Speaker FINAL presentations to PCTool or speaker-support: 31-May-2013
>> ? On-Site Registration: 31-May-2013
>>
>> The NANOG Program Committee seeks proposals for presentations, panels,
>> tutorial sessions, tracks, and BOFs in all areas of network operations,
>> including (but not limited to):
>>
>>    - Power and facilities - Topics may include power reliability and
>>    engineering, green power, power efficiency, cooling, and facilities
>>    management.
>>    - Interconnections - Topics may include IXes, intra-building, MMR,
>>    metro-wide connections, peering, and transit purchasing tactics and
>>    strategies.
>>    - Security - Topics may include routing security, route filtering of
>>    large peers/customers, and inter-AS security and cooperation.
>>    - DNS - Topics may include using DNS data for network metrics, botnet
>>    discovery, and geolocation.
>>    - IPv6 - Topics may include real-world deployment challenges, Carrier
>>    Grade NAT, NAT-PT implementations that work and scale, and allocation
>>    strategies.
>>    - Content - Topics may include Distribution (p2p, IPTV), content
>>    payment models, content distribution technologies and networks, and
>>    storage/archiving.
>>    - Disaster recovery - Topics may include risk analysis, training,
>>    agencies, planning methods, hardware portability, key tools, transport
>>    audits, and other lessons learned.
>>
>> In general, presentations are being sought by and for network operators
>> of all sizes. Presentations about difficult problems (and interesting
>> solutions) that you encounter in the course of your job are encouraged.
>>
>> In addition, the Program Committee, through participation with other
>> organizations and vendor?s, will be programming a NOGLab experience.
>>  The topic of the NOGLab will be timely and feature real-world experiences
>> faced by operators of today?s Internet.
>>
>> If you think you have an interesting topic but want some feedback or
>> assistance working it into a presentation, please email the Program
>> Committee chair (chair at pc.nanog.org), and a representative on the
>> Program Committee will give you the feedback needed to work it into a
>> presentation. Otherwise, don't delay in submitting your talk, keynote,
>> track, or panel into the NANOG Program Committee tool, located at
>> http://pc.nanog.org. For more information about talk types and format,
>> please see http://nanog.org/presentations/guidelines/talktips.php<http://www.nanog.org/presentations/guidelines/talktips.php>
>>  <http://www.nanog.org/presentations/guidelines/talktips.php>
>> How to Present
>> The deadline for accepting abstracts and slides is April 8, 2013 . While
>> the majority of speaking slots may be filled by that date, a limited number
>> of slots may be available after that date for topics that are exceptionally
>> timely, important, or critical to the operations of the Internet.
>>
>> Complete Presentation Guidelines can be found at
>> http://nanog.org/presentations/ <http://www.nanog.org/presentations/>
>>  <http://www.nanog.org/presentations/>
>> The primary speaker, moderator, or author should submit presentation
>> information and an abstract online at: http://pc.nanog.org once you have
>> done this, you will receive instructions for submitting your draft slides.
>>
>>    - Author's name(s)
>>    - Preferred contact email address
>>    - A preferred phone number for contact
>>    - Submission category (General Session, Panel, Tutorial, or Research
>>    Forum)
>>    - Presentation title
>>    - Abstract
>>    - Slides (attachment or URL), in PDF (preferred) or PowerPoint format.
>>
>> We look forward to reviewing your submission.
>>
>> Talks
>> Keynote Presentation: The Program Committee invites speakers to submit
>> materials for up to one-hour keynote presentations. Speakers should
>> indicate that their submission is for a keynote in their abstracts. Speaker
>> must submit slides for a Keynote Presentation.
>>
>> General Session Talk: A General Session presentation should be on a
>> topic of interest to the general NANOG audience, and may be up to
>> 30-minutes long (including time for Q&A). Speakers must submit slides for a
>> General Session presentation.
>>
>> General Session Panel: Panels are 60-90-minute discussion sessions
>> between a moderator and a team of panelists. The panel moderator should
>> submit an abstract on the panel topic, a list of panelists, and how the
>> panel will be organized. Panel selection will be based on the importance,
>> originality, focus and timeliness of the topic, expertise of proposed
>> panelists, as well as the potential for informative and controversial
>> discussion. After acceptance the panel leader will be given the option to
>> invite panel authors to submit their presentations to the NANOG program
>> Committee for review. Until then authors should not submit their individual
>> presentations for the panel.
>>
>> Tracks: Tracks are 90-minute informal agenda blocks on topics, which are
>> of interest to a portion of the NANOG community. The 90-minute block can be
>> subdivided into a number of smaller, highly related presentations, panels
>> or open discussion. A moderator coordinates content within the 90-minute
>> block of time, and must submit a detailed outline to the Program Committee,
>> including sub-topics and presenters
>> Peering
>> ISP Security
>> Tools
>> Typically two tracks or three tracks will be run concurrently.
>>
>> Tutorials: Tutorials are 90-minute sessions. A presentation from the
>> introductory through advanced level on all related topics, including:
>> Disaster Recovery Planning
>> Troubleshooting BGP
>> Best Practices for Determining Traffic Matrices
>> Options for Blackhole and Discard Routing
>> BGP/MPLS Layer 3 VPNs
>> Peering business and engineering basics
>> A tutorial submission should include an abstract and slides.
>>
>> BOFs: BOFs (Birds of a Feather sessions) are informal sessions on
>> topics, which are of interest to a portion of the NANOG community. BOFs may
>> be held in the hallways, breakout areas or in an unscheduled tutorial room.
>> Requests for scheduled BOFs will be take place on site at the meeting.
>>
>> A typical BOF session may include some structure or presentations, but
>> usually is focused on community discussion and interaction.
>>
>> Frequent BOF topics include:
>> R&D collaboration
>> Hot-topics in the media
>> The less structured nature of BOF sessions allows for the greatest
>> flexibility from a timing perspective.
>>
>> Lightning Talks: A lightning talk is a very short presentation or speech
>> by any attendee on any topic relevant to the NANOG audience. These are
>> limited to ten minutes; this will be strictly enforced.
>>
>> If you have a topic that's timely, interesting, or even a crackpot idea
>> you want to share, we encourage you to consider presenting it. The Program
>> Committee will vote on all Lightning Talk submissions onsite at the
>> meeting, and a submitter will be notified about his or her submission one
>> day prior to the scheduled talk time.
>>
>> Submit your lightning talk proposal at http://pc.nanog.org starting June
>> 2, 2013.
>>
>> Research Forum: Researchers are invited to present short (10-minute)
>> summaries of their work for operator feedback. Topics include routing,
>> network performance, statistical measurement and analysis, and protocol
>> development and implementation. Studies presented may be works in progress.
>> Researchers from academia, government, and industry are encouraged to
>> present.
>>
>> The NANOG registration fee is waived for:
>>
>>    - For General Session presentations, the registration fee will be
>>    waived for a maximum of one speaker.
>>    - For General Session panels, fees will be waived for one panel
>>    moderator and all panelists.
>>    - For Tracks, fees will be waived for one moderator.
>>    - For Research Forum presentations, fees will be waived for one
>>    speaker.
>>    - For Tutorials, fees will be waived for one instructor.
>>
>> *
>
>
>

From oscar.vives at gmail.com  Tue Apr  9 16:45:13 2013
From: oscar.vives at gmail.com ( .)
Date: Tue, 9 Apr 2013 18:45:13 +0200
Subject: Closing the gap to improve the capacity of existing fiber optic
 networks
In-Reply-To: <20130409130934.GS6172@leitl.org>
References: <20130409130934.GS6172@leitl.org>
Message-ID: <CACg3zYHZx9arOF2T9PL0CdLX31FQZ3+L7vLp-BqHmy3gvCWUVQ@mail.gmail.com>

On 9 April 2013 15:09, Eugen Leitl <eugen at leitl.org> wrote:
...

> ?Our approach is so flexible, network operators could adjust capacity to
> respond to increased demand, for example from people following big sport
> events like the Olympics," added Dr Schr?der.
>

As a Internet user:  We want more bandwidth every second and every minute
of the day.   We don't want to wait for youtube videos to stream,  games to
download,   we don't want lag in our videogames while other member of the
family is streaming a movie.   Give me 2 tera/s, and I will have lag in my
mmorpg game while my dad watch 4K video from Netflix. It will not be
enough. Never enough is enough. Theres only one answer More, and is all the
time 365 days every year. +1 a leap year.
I suppose the line is to try to explain it to no-internet users. But is
still weird.

-- 
--
?in del ?ensaje.

From jra at baylink.com  Tue Apr  9 16:54:45 2013
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 9 Apr 2013 12:54:45 -0400 (EDT)
Subject: Hazmat at 400 N Tampa
Message-ID: <4525455.1474.1365526485176.JavaMail.root@benjamin.baylink.com>

WFLA TV reports that Tampa Fire is working a hazmat call at 400 N Tampa.

  http://www.wfla.com/story/21920646/hazmat-situation-in-downtown-tampa

Park Tower is the carrier hotel for Tampa Bay; there are about 13 carriers
in that building, at least 9 of which have major POPs and xconn there.

Depending on what the actual problem is, Tampa Bay, Florida, or the
Southeast may see repercussions from this.

Followups to outages-discussion at outages.org, please (except for actual
further outage data).  (I would set followups, but Zimbra 6 sucks.)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From m.hotze at hotze.com  Tue Apr  9 17:16:55 2013
From: m.hotze at hotze.com (Martin Hotze)
Date: Tue, 9 Apr 2013 17:16:55 +0000
Subject: cloudmark?
Message-ID: <F02A0931E2E6254680832D6A24940C2DEC5B50@hx01.srv.hotze.com>

> Date: Tue, 09 Apr 2013 10:31:08 -0400
> From: Chris Conn <cconn at b2b2c.ca>
> To: nanog at nanog.org
> Subject: Re: cloudmark?
> Message-ID: <5164262C.3070806 at b2b2c.ca>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 2013-04-09 10:27, Chris Conn wrote:
> >
(...)
> Your experience does not mirror mine at all.  I have less than 30

good for you. :-)

> minutes of wait time for any support case, and they are few and far
> between.  Reliability is high and FP rate is low.   I have no idea what
> your reference to lawyers pertains to, however the only issue we have
> ever had was for them to take our money when we renewed for the
> umpteenth time.

We are not a paying cloudmark customer.
We just want to get one of our IPv4 address off of their list.

 #m



From alejandroacostaalamo at gmail.com  Tue Apr  9 18:42:23 2013
From: alejandroacostaalamo at gmail.com (Alejandro Acosta)
Date: Tue, 9 Apr 2013 14:12:23 -0430
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <4F734D5F.9030902@gmail.com>
References: <4F734D5F.9030902@gmail.com>
Message-ID: <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>

Hi Carlos, list,
  Today I entered to networksolutions.com and I remembered this
thread. I had to administer a domain name and I sadly found they have
done nothing in IPv6 during the last 12 month.

Regards,

^Ao$

On 3/28/12, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote:
> Hello all,
>
> I just received a heads-up from a friend telling me that Network
> Solutions is unable/unwilling to configure AAAA's for .com/.net domains.
> He works for a large media outlet who will be enabling IPv6 on their
> sites for World IPv6 Launch Day.
>
> I hope it's just a misunderstanding.  If it's not, I would love to know
> if there is a reason for this, and if they have a timeline for
> supporting AAAA's.
>
> It's ok to contact me privately.
>
> regards
>
> Carlos
>
>


From ahebert at pubnix.net  Tue Apr  9 18:47:25 2013
From: ahebert at pubnix.net (Alain Hebert)
Date: Tue, 09 Apr 2013 14:47:25 -0400
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
Message-ID: <5164623D.8050109@pubnix.net>

    Hi,

    At least I know the infrastructure is not ready to accept IPv6 for
NS registration.

    I tried with NetSol and GoD.

    Which remind me... I'm still waiting on my NSx.BCP38.ORG from GoD?

    Grr...  (hate when someone is right)

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 04/09/13 14:42, Alejandro Acosta wrote:
> Hi Carlos, list,
>   Today I entered to networksolutions.com and I remembered this
> thread. I had to administer a domain name and I sadly found they have
> done nothing in IPv6 during the last 12 month.
>
> Regards,
>
> ^Ao$
>
> On 3/28/12, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote:
>> Hello all,
>>
>> I just received a heads-up from a friend telling me that Network
>> Solutions is unable/unwilling to configure AAAA's for .com/.net domains.
>> He works for a large media outlet who will be enabling IPv6 on their
>> sites for World IPv6 Launch Day.
>>
>> I hope it's just a misunderstanding.  If it's not, I would love to know
>> if there is a reason for this, and if they have a timeline for
>> supporting AAAA's.
>>
>> It's ok to contact me privately.
>>
>> regards
>>
>> Carlos
>>
>>
>
>



From jabley at hopcount.ca  Tue Apr  9 18:55:05 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 10 Apr 2013 02:55:05 +0800
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
Message-ID: <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>

You have a choice of registrars. If you don't like the one you are using right now, choose a different one. There are lots to choose from.

http://www.icann.org/registrar-reports/accredited-list.html


Joe

Sent from my Ono-Sendai Cyberspace 7

On 2013-04-10, at 2:42, Alejandro Acosta <alejandroacostaalamo at gmail.com> wrote:

> Hi Carlos, list,
>  Today I entered to networksolutions.com and I remembered this
> thread. I had to administer a domain name and I sadly found they have
> done nothing in IPv6 during the last 12 month.
> 
> Regards,
> 
> ^Ao$
> 
> On 3/28/12, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote:
>> Hello all,
>> 
>> I just received a heads-up from a friend telling me that Network
>> Solutions is unable/unwilling to configure AAAA's for .com/.net domains.
>> He works for a large media outlet who will be enabling IPv6 on their
>> sites for World IPv6 Launch Day.
>> 
>> I hope it's just a misunderstanding.  If it's not, I would love to know
>> if there is a reason for this, and if they have a timeline for
>> supporting AAAA's.
>> 
>> It's ok to contact me privately.
>> 
>> regards
>> 
>> Carlos
> 

From jared at puck.nether.net  Tue Apr  9 20:15:39 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 9 Apr 2013 16:15:39 -0400
Subject: Open Resolver Dataset Update
In-Reply-To: <1365512377.22965.76.camel@galaxy>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
 <51626CF9.1040109@phyxia.net>
 <BCCE3736-E0D5-4F52-9A09-87D79F0CD156@puck.nether.net>
 <1365512377.22965.76.camel@galaxy>
Message-ID: <E719A2C5-2EB1-425B-8756-605BCD4DED8C@puck.nether.net>

Tom,

The main criteria is the RCODE=0 vs RCODE=5 refused.

I exposed the Recursion Available bit this last week to cover more of the use cases, but many servers provide a very large referral to root.

You are correct in that your system doesn't provide that so should be less "visible" as a result.  I haven't coded everything to pull out that level of data from the responses.

Of the responding IPs, a fair percentage 89% respond with the RA bit set.  I'm working to close the gap on exposing the direct data of those last 11% in a more detailed bit of information, including if it provides a root referral or otherwise.

Hope this helps,

- Jared

On Apr 9, 2013, at 8:59 AM, Tom Laermans <tom.laermans at phyxia.net> wrote:

> Jared,
> 
> If you mean there can be a referral with RCODE=0 and Recursion Available
> = 0, you'll need a third column actually documenting if there is a
> referral.
> 
> This server is listed in ORP:
> 
> $ dig www.google.be @195.160.166.139
> 
> ; <<>> DiG 9.7.3 <<>> www.google.be @195.160.166.139
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 615
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;www.google.be.                 IN      A
> 
> ;; Query time: 6 msec
> ;; SERVER: 195.160.166.139#53(195.160.166.139)
> ;; WHEN: Tue Apr  9 14:58:21 2013
> ;; MSG SIZE  rcvd: 31
> 
> RCODE=0, Recursion available=0:
> 	
> http://openresolverproject.org/search.cgi?mode=search6&search_for=195.160.166.0%2F24
> 
> Hence my question, what is it doing wrong?
> 
> Tom
> 
> On Mon, 2013-04-08 at 07:05 -0400, Jared Mauch wrote:
>> The referral, including a referral to root can be quite large. Even larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. 
>> 
>> Jared Mauch
>> 
>> On Apr 8, 2013, at 3:08 AM, Tom Laermans <tom.laermans at phyxia.net> wrote:
>> 
>>> As far as I know, responding either NOERROR or REFUSED produces packets of the same size.
> 



From apishdadi at gmail.com  Tue Apr  9 20:55:00 2013
From: apishdadi at gmail.com (A. Pishdadi)
Date: Tue, 9 Apr 2013 15:55:00 -0500
Subject: Open Resolver Dataset Update
In-Reply-To: <E719A2C5-2EB1-425B-8756-605BCD4DED8C@puck.nether.net>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
 <51626CF9.1040109@phyxia.net>
 <BCCE3736-E0D5-4F52-9A09-87D79F0CD156@puck.nether.net>
 <1365512377.22965.76.camel@galaxy>
 <E719A2C5-2EB1-425B-8756-605BCD4DED8C@puck.nether.net>
Message-ID: <CAHGyo+-zKv2hwcK4=Yod5TPnahEEMQthVWr31pqErpyoNhgPvg@mail.gmail.com>

In the last 2 weeks we have seen double the amount of ddos attacks, and way
bigger then normal. All of them being amplification attacks. I think the
media whoring done during the spamhaus debacle motivated more people to
invest time building up there openresolver list, since really no one has
disclosed attacks of that size and gave the blueprints of how to do it. Now
we know the attack has been around for awhile but no one really knew how
big they could take it until a couple weeks ago..

Now I know your openresolver DB is meant to get them closed but it would
take only a small amount of someones day to write a script to crawl your
database.. You go to fixedorbit.com or something of the sort, look up the
as's of the biggest hosting companies, plop there list of ip allocaitons in
to a text file, run the script and boom i now have the biggest open
resolver list to feed my botnet.. Maybe you should require some sort of
CAPTCHA or registration to view that database. While im sure people have
other ways of gathering up the open resolvers , you just took away all the
work and handed it to them on a silver platter. While i am and others
surely are greatful for the data, i think a little more thought should be
put in how you are going to deliver the data to who should have it, and
that would be the network / AS they are hanging off of.

just my 2 cents..

P.S. I would like to get a list for our AS off list if you can reply back
directly.




On Tue, Apr 9, 2013 at 3:15 PM, Jared Mauch <jared at puck.nether.net> wrote:

> Tom,
>
> The main criteria is the RCODE=0 vs RCODE=5 refused.
>
> I exposed the Recursion Available bit this last week to cover more of the
> use cases, but many servers provide a very large referral to root.
>
> You are correct in that your system doesn't provide that so should be less
> "visible" as a result.  I haven't coded everything to pull out that level
> of data from the responses.
>
> Of the responding IPs, a fair percentage 89% respond with the RA bit set.
>  I'm working to close the gap on exposing the direct data of those last 11%
> in a more detailed bit of information, including if it provides a root
> referral or otherwise.
>
> Hope this helps,
>
> - Jared
>
> On Apr 9, 2013, at 8:59 AM, Tom Laermans <tom.laermans at phyxia.net> wrote:
>
> > Jared,
> >
> > If you mean there can be a referral with RCODE=0 and Recursion Available
> > = 0, you'll need a third column actually documenting if there is a
> > referral.
> >
> > This server is listed in ORP:
> >
> > $ dig www.google.be @195.160.166.139
> >
> > ; <<>> DiG 9.7.3 <<>> www.google.be @195.160.166.139
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 615
> > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> > ;; WARNING: recursion requested but not available
> >
> > ;; QUESTION SECTION:
> > ;www.google.be.                 IN      A
> >
> > ;; Query time: 6 msec
> > ;; SERVER: 195.160.166.139#53(195.160.166.139)
> > ;; WHEN: Tue Apr  9 14:58:21 2013
> > ;; MSG SIZE  rcvd: 31
> >
> > RCODE=0, Recursion available=0:
> >
> >
> http://openresolverproject.org/search.cgi?mode=search6&search_for=195.160.166.0%2F24
> >
> > Hence my question, what is it doing wrong?
> >
> > Tom
> >
> > On Mon, 2013-04-08 at 07:05 -0400, Jared Mauch wrote:
> >> The referral, including a referral to root can be quite large. Even
> larger than answering a normal query. I have broken the data out for the
> purpose of letting people identify the IPs that provide that.
> >>
> >> Jared Mauch
> >>
> >> On Apr 8, 2013, at 3:08 AM, Tom Laermans <tom.laermans at phyxia.net>
> wrote:
> >>
> >>> As far as I know, responding either NOERROR or REFUSED produces
> packets of the same size.
> >
>
>
>

From marka at isc.org  Tue Apr  9 23:23:34 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 10 Apr 2013 09:23:34 +1000
Subject: Quad-A records in Network Solutions ?
In-Reply-To: Your message of "Wed, 10 Apr 2013 02:55:05 +0800."
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
Message-ID: <20130409232335.44152322F977@drugs.dv.isc.org>


Not accepting AAAA is just about as bad as not accepting A records.
You wouldn't certify a registrar if they couldn't update A records.
It's about time certification was lost for failure to handle AAAA
records.  The same should also apply for DS records.

In message <6D7961E1-F0FE-4674-8F8E-49CB5226DC35 at hopcount.ca>, Joe Abley writes
:
> You have a choice of registrars. If you don't like the one you are using rig=
> ht now, choose a different one. There are lots to choose from.
> 
> http://www.icann.org/registrar-reports/accredited-list.html
> 
> 
> Joe
> 
> Sent from my Ono-Sendai Cyberspace 7
> 
> On 2013-04-10, at 2:42, Alejandro Acosta <alejandroacostaalamo at gmail.com> wr=
> ote:
> 
> > Hi Carlos, list,
> >  Today I entered to networksolutions.com and I remembered this
> > thread. I had to administer a domain name and I sadly found they have
> > done nothing in IPv6 during the last 12 month.
> >=20
> > Regards,
> >=20
> > ^Ao$
> >=20
> > On 3/28/12, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote:
> >> Hello all,
> >>=20
> >> I just received a heads-up from a friend telling me that Network
> >> Solutions is unable/unwilling to configure AAAA's for .com/.net domains.
> >> He works for a large media outlet who will be enabling IPv6 on their
> >> sites for World IPv6 Launch Day.
> >>=20
> >> I hope it's just a misunderstanding.  If it's not, I would love to know
> >> if there is a reason for this, and if they have a timeline for
> >> supporting AAAA's.
> >>=20
> >> It's ok to contact me privately.
> >>=20
> >> regards
> >>=20
> >> Carlos
> >=20
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From gem at rellim.com  Tue Apr  9 23:40:04 2013
From: gem at rellim.com (Gary E. Miller)
Date: Tue, 9 Apr 2013 16:40:04 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <20130409232335.44152322F977@drugs.dv.isc.org>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org>
Message-ID: <20130409164004.0f4c310b.gem@rellim.com>

Yo Mark!

On Wed, 10 Apr 2013 09:23:34 +1000
Mark Andrews <marka at isc.org> wrote:

> 
> Not accepting AAAA is just about as bad as not accepting A records.
> You wouldn't certify a registrar if they couldn't update A records.
> It's about time certification was lost for failure to handle AAAA
> records.  The same should also apply for DS records.

+1

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

From brunner at nic-naa.net  Tue Apr  9 23:48:36 2013
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Tue, 09 Apr 2013 16:48:36 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <20130409232335.44152322F977@drugs.dv.isc.org>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org>
Message-ID: <5164A8D4.7090802@nic-naa.net>

On 4/9/13 4:23 PM, Mark Andrews wrote:
> It's about time certification was lost for failure to handle AAAA
> records.  The same should also apply for DS records.

You can suggest this to the compliance team. It seems to me (registrar
hat == "on") that in 2.5 years time, when Staff next conducts a
registrar audit, that this is a reasonable expectation of an
accreditation holding contracted party. It simply needs to be added to
the base RAA agreement.

Joe _may_ be in a position to encourage the compliance team to develop
a metric and a test mechanism, but at present, the compliance team
appears to be capable of WHOIS:43 harvesting (via Kent's boxen) and
occasional WHOIS:80 scraping, and little else beyond records
reconciliation for a limited sample. NB, investing equal oversight
labor in all current (and former) RAA holders is (a) a significant
duplication of effort for little possible benefit where shell
registrars are concerned, and (b) treats registrars (and their
registrants' interests in fair dealing) with a few hundreds of domains
and registrars (and their registrants' interests) with 10% or more of
the total gTLD registry market indifferently by policy and enforcement
tool design. The latter means most registrants (those with performance
contracts from registrars with 10% market share) receive several
orders of magnitude less contractual oversight protections than
registrants using registrars with a few hundred "names under management".

IMHO, that's a problem that could be fixed.

Eric


From selina.harrington at icann.org  Tue Apr  9 21:29:37 2013
From: selina.harrington at icann.org (Selina Harrington)
Date: Tue, 9 Apr 2013 14:29:37 -0700
Subject: IANA AS Numbers registry update
Message-ID: <CD89D651.1376B%selina.harrington@icann.org>

The IANA AS Numbers registry has been updated to reflect the allocation
of 1 block to LACNIC in 2013-04-08:

61440-62463

You can find the IANA AS Numbers registry at:

http://www.iana.org/assignments/as-numbers/as-numbers.xml

Regards,



Selina Harrington

IANA Request Specialist

ICANN

From hunveesy at gmail.com  Tue Apr  9 21:29:56 2013
From: hunveesy at gmail.com (Hunveesy)
Date: Wed, 10 Apr 2013 06:29:56 +0900
Subject: need help about free bandwidth graph program
In-Reply-To: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
References: <CAAiP320a30U2Sww_gz8AmdHbZQvx2uqEgnznb06Y47BvCADYYw@mail.gmail.com>
Message-ID: <F1080B03-0E48-450C-A1CB-72DB847C4FFE@gmail.com>

There's also bandwidthd which can be added to the list. Nfsen is the front end for nfdump (much like SiLK) with graphs and it has plugins to graph port usage, etc. 

On Apr 9, 2013, at 4:51 AM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:

> Hi all
> 
> Do you know any opensource program bandwidthgraph by ipaddess?
> 
> Thank you


From owen at delong.com  Wed Apr 10 00:39:31 2013
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Apr 2013 17:39:31 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <5164A8D4.7090802@nic-naa.net>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
Message-ID: <E5DE7113-1DBF-455D-9DFC-0594388F7802@delong.com>

I said all of this years ago as a suggestion for the next round of contract
renewals (since I was told that it had to be added to the contracts first).

Best of luck. Personally, I think it should have been a requirement at least
5 years ago.

Owen

On Apr 9, 2013, at 16:48 , Eric Brunner-Williams <brunner at nic-naa.net> wrote:

> On 4/9/13 4:23 PM, Mark Andrews wrote:
>> It's about time certification was lost for failure to handle AAAA
>> records.  The same should also apply for DS records.
> 
> You can suggest this to the compliance team. It seems to me (registrar
> hat == "on") that in 2.5 years time, when Staff next conducts a
> registrar audit, that this is a reasonable expectation of an
> accreditation holding contracted party. It simply needs to be added to
> the base RAA agreement.
> 
> Joe _may_ be in a position to encourage the compliance team to develop
> a metric and a test mechanism, but at present, the compliance team
> appears to be capable of WHOIS:43 harvesting (via Kent's boxen) and
> occasional WHOIS:80 scraping, and little else beyond records
> reconciliation for a limited sample. NB, investing equal oversight
> labor in all current (and former) RAA holders is (a) a significant
> duplication of effort for little possible benefit where shell
> registrars are concerned, and (b) treats registrars (and their
> registrants' interests in fair dealing) with a few hundreds of domains
> and registrars (and their registrants' interests) with 10% or more of
> the total gTLD registry market indifferently by policy and enforcement
> tool design. The latter means most registrants (those with performance
> contracts from registrars with 10% market share) receive several
> orders of magnitude less contractual oversight protections than
> registrants using registrars with a few hundred "names under management".
> 
> IMHO, that's a problem that could be fixed.
> 
> Eric



From jared at puck.nether.net  Wed Apr 10 00:47:22 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 9 Apr 2013 20:47:22 -0400
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <5164A8D4.7090802@nic-naa.net>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
Message-ID: <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>

Can you point is at the right address or form to submit regarding this? Seems like its time for both on AAAA and DS. 

Jared Mauch

On Apr 9, 2013, at 7:48 PM, Eric Brunner-Williams <brunner at nic-naa.net> wrote:

> On 4/9/13 4:23 PM, Mark Andrews wrote:
>> It's about time certification was lost for failure to handle AAAA
>> records.  The same should also apply for DS records.
> 
> You can suggest this to the compliance team. It seems to me (registrar
> hat == "on") that in 2.5 years time, when Staff next conducts a
> registrar audit, that this is a reasonable expectation of an
> accreditation holding contracted party. It simply needs to be added to
> the base RAA agreement.


From bwilliams at cloudmark.com  Wed Apr 10 02:41:42 2013
From: bwilliams at cloudmark.com (Bryan Williams)
Date: Wed, 10 Apr 2013 02:41:42 +0000
Subject: NANOG - csi reset request
In-Reply-To: <CD89C103.62C64%bwilliams@cloudmark.com>
Message-ID: <CD8A4959.62CFA%bwilliams@cloudmark.com>

Martin,

I sent you this email from our corporate email, and haven't heard back. Did you receive this?

Regards,
Bryan Williams
Sr. Solutions Architect
Cloudmark, Inc

From: Bryan Williams <bwilliams at cloudmark.com<mailto:bwilliams at cloudmark.com>>
Date: Tuesday, April 9, 2013 12:58 PM
To: "m.hotze at hotze.com<mailto:m.hotze at hotze.com>" <m.hotze at hotze.com<mailto:m.hotze at hotze.com>>
Subject: NANOG - csi reset request

I searched through the recent requests, and couldn't find any with your email address as the contact email. Can you give me the IP you tried to unblock?

Or, try it again and let us know that you did it so we can watch. If there's a bug, we'd like to fix it.

Regards,
Bryan Williams
Sr. Solutions Architect

Message: 4
Date: Tue, 9 Apr 2013 14:24:17 +0000
From: Martin Hotze <m.hotze at hotze.com<mailto:m.hotze at hotze.com>>
To: "nanog at nanog.org<mailto:nanog at nanog.org>" <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: cloudmark?
Message-ID:
<F02A0931E2E6254680832D6A24940C2DEC5989 at hx01.srv.hotze.com<mailto:F02A0931E2E6254680832D6A24940C2DEC5989 at hx01.srv.hotze.com>>
Content-Type: text/plain; charset="us-ascii"

Hi,

<rant>
it seems that many large providers are using cloudmark services. As far as I can tell: their policy is unclear, they can hardly be reached, mails to support are bouncing (delayed, then bounce).

yes, the mailserver from one of our customers was blocked and this was OK and rightful, because they had a problem (cracked account). After the problem was resolved we started removing their IPv4 address from blacklists and almost all lists removed the ban immediately.

cloudmark CSI service (reset request form) wants a form to be filled ... and they claim that they send out an email ... but it doesn't make its way to my inbox (no, no filters ...)

and support can't be reached.

Where are the good old times when the 'net was controlled by techs and not by lawyers?

I can't recommend cloudmark.
</rant>

greetings, martin


From ebw at abenaki.wabanaki.net  Wed Apr 10 02:51:52 2013
From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams)
Date: Tue, 09 Apr 2013 19:51:52 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <E5DE7113-1DBF-455D-9DFC-0594388F7802@delong.com>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
 <E5DE7113-1DBF-455D-9DFC-0594388F7802@delong.com>
Message-ID: <5164D3C8.8060701@abenaki.wabanaki.net>

On 4/9/13 5:39 PM, Owen DeLong wrote:
> I said all of this years ago as a suggestion for the next round of contract
> renewals (since I was told that it had to be added to the contracts first).
> 
> Best of luck. Personally, I think it should have been a requirement at least
> 5 years ago.

And exactly where were you in ICANN process and politics in 2008?


From ebw at abenaki.wabanaki.net  Wed Apr 10 03:13:49 2013
From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams)
Date: Tue, 09 Apr 2013 20:13:49 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
Message-ID: <5164D8ED.5010608@abenaki.wabanaki.net>

On 4/9/13 5:47 PM, Jared Mauch wrote:
> Can you point is at the right address or form to submit regarding this? Seems like its time for both on AAAA and DS. 

Jared,

Joe is an employee of the corporation, a rather high ranking one. As I
mentioned in my response to Mark, he _may_ be in a position to
encourage both legal to develop new language for future addition to
the RAA, and the Registrar Liaison to socialize the issue to those RAA
parties who are members of the Registrar Stakeholder Group within the
Contracted Parties House of the GNSO, and the Compliance team.

As a matter of policy development you should expect that Registrars
(recall hat) have been presented with ... proposed new terms and
conditions that ... are not universally appreciated, and so one must
either (a) impose new conditions unilaterally upon counter-parties,
arguing some theory of necessity, or (b) negotiate a mutually
agreeable modification.

There is a lot of heat lost in the ICANN system, so to re-purpose the
off-hand observation of John Curran made recently, operators having
some rough consensus on desirable features of RRSet editors may be a
necessary predicate to policy intervention. As I observed to John, the
ISP Constituency within the ICANN GNSO has been an effective advocate
of trademark policy, and no other policy area, since the Montevideo
General meeting, in 2001.

Eric

P.S. I may be turning in my Registrar hat in the near future.


From leo.vegoda at icann.org  Wed Apr 10 03:27:21 2013
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 9 Apr 2013 20:27:21 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <5164D8ED.5010608@abenaki.wabanaki.net>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org>
 <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
 <5164D8ED.5010608@abenaki.wabanaki.net>
Message-ID: <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF@EXVPMBX100-1.exc.icann.org>

Eric Brunner-Williams wrote:

[...]

> Joe is an employee of the corporation, a rather high ranking one. As I
> mentioned in my response to Mark, he _may_ be in a position to
> encourage both legal to develop new language for future addition to
> the RAA, and the Registrar Liaison to socialize the issue to those RAA
> parties who are members of the Registrar Stakeholder Group within the
> Contracted Parties House of the GNSO, and the Compliance team.
> 
> As a matter of policy development you should expect that Registrars
> (recall hat) have been presented with ... proposed new terms and
> conditions that ... are not universally appreciated, and so one must
> either (a) impose new conditions unilaterally upon counter-parties,
> arguing some theory of necessity, or (b) negotiate a mutually
> agreeable modification.

IPv6 was on the table from the start of the RAA negotiations, as I
understand it. When I scanned the draft RAA posted a few weeks back I
noticed language like:

"3.3.1 At its expense, Registrar shall provide an interactive web page
and a port 43 Whois service (each accessible via both IPv4 and IPv6)
[...]"

and

"2. IPv6  - To the extent that Registrar offers registrants the ability
to register nameserver addresses, Registrar must allow both IPv4
addresses and IPv6 addresses to be specified."

There are multiple documents to read and you can find them all here.

https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm

If anyone has specific questions about the draft RAA, they should
contact Samantha Eisner, whose contact details are on that page.

Regards,

Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5475 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130409/99f7b756/attachment-0001.bin>

From m.hotze at hotze.com  Wed Apr 10 03:43:57 2013
From: m.hotze at hotze.com (Martin Hotze)
Date: Wed, 10 Apr 2013 03:43:57 +0000
Subject: NANOG Digest, Vol 63, Issue 45
Message-ID: <F02A0931E2E6254680832D6A24940C2DED1964@hx01.srv.hotze.com>

Bryan,

nope, it didn't make it through to my inbox . I try to contact you through other channels.


Martin

> Date: Wed, 10 Apr 2013 02:41:42 +0000
> From: Bryan Williams <bwilliams at cloudmark.com>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Subject: NANOG - csi reset request
> Message-ID: <CD8A4959.62CFA%bwilliams at cloudmark.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Martin,
> 
> I sent you this email from our corporate email, and haven't heard back. Did
> you receive this?
> 
> Regards,
> Bryan Williams
> Sr. Solutions Architect
> Cloudmark, Inc
> 
> From: Bryan Williams
> <bwilliams at cloudmark.com<mailto:bwilliams at cloudmark.com>>
> Date: Tuesday, April 9, 2013 12:58 PM
> To: "m.hotze at hotze.com<mailto:m.hotze at hotze.com>"
> <m.hotze at hotze.com<mailto:m.hotze at hotze.com>>
> Subject: NANOG - csi reset request
> 
> I searched through the recent requests, and couldn't find any with your email
> address as the contact email. Can you give me the IP you tried to unblock?
> 
> Or, try it again and let us know that you did it so we can watch. If there's a
> bug, we'd like to fix it.
> 
> Regards,
> Bryan Williams
> Sr. Solutions Architect



From marka at isc.org  Wed Apr 10 03:56:15 2013
From: marka at isc.org (Mark Andrews)
Date: Wed, 10 Apr 2013 13:56:15 +1000
Subject: Quad-A records in Network Solutions ?
In-Reply-To: Your message of "Tue, 09 Apr 2013 20:27:21 -0700."
 <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF@EXVPMBX100-1.exc.icann.org>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
 <5164D8ED.5010608@abenaki.wabanaki.net>
 <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF@EXVPMBX100-1.exc.icann.org>
Message-ID: <20130410035615.4CD4E3232B40@drugs.dv.isc.org>


In message <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF at EXVPMBX100-1.exc.icann.o
rg>, Leo Vegoda writes:
> 
> Eric Brunner-Williams wrote:
> 
> [...]
> 
> > Joe is an employee of the corporation, a rather high ranking one. As I
> > mentioned in my response to Mark, he _may_ be in a position to
> > encourage both legal to develop new language for future addition to
> > the RAA, and the Registrar Liaison to socialize the issue to those RAA
> > parties who are members of the Registrar Stakeholder Group within the
> > Contracted Parties House of the GNSO, and the Compliance team.
> > 
> > As a matter of policy development you should expect that Registrars
> > (recall hat) have been presented with ... proposed new terms and
> > conditions that ... are not universally appreciated, and so one must
> > either (a) impose new conditions unilaterally upon counter-parties,
> > arguing some theory of necessity, or (b) negotiate a mutually
> > agreeable modification.
> 
> IPv6 was on the table from the start of the RAA negotiations, as I
> understand it. When I scanned the draft RAA posted a few weeks back I
> noticed language like:
> 
> "3.3.1 At its expense, Registrar shall provide an interactive web page
> and a port 43 Whois service (each accessible via both IPv4 and IPv6)
> [...]"
> 
> and
> 
> "2. IPv6  - To the extent that Registrar offers registrants the ability
> to register nameserver addresses, Registrar must allow both IPv4
> addresses and IPv6 addresses to be specified."
> 
> There are multiple documents to read and you can find them all here.
> 
> https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm
> 
> If anyone has specific questions about the draft RAA, they should
> contact Samantha Eisner, whose contact details are on that page.
> 
> Regards,
> 
> Leo

Looking at
https://www.icann.org/en/resources/registrars/raa/proposed-additional-operation-07mar13-en.pdf
there is nothing which requires registrars to support AAAA on the web
pages when A records are supported on web pages.

AAAA and DS updates currently often required registrants to jump through
all sorts of hoops compared to adding A and NS records.

Maintenance of A, AAAA, NS and DS records are core functionality and
need to be treated as such.

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


From leo.vegoda at icann.org  Wed Apr 10 04:11:10 2013
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 9 Apr 2013 21:11:10 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <20130410035615.4CD4E3232B40@drugs.dv.isc.org>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org>
 <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
 <5164D8ED.5010608@abenaki.wabanaki.net>
 <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF@EXVPMBX100-1.exc.icann.org>
 <20130410035615.4CD4E3232B40@drugs.dv.isc.org>
Message-ID: <6E0713EA-0E68-44C6-807E-AD7AB63F229B@icann.org>

On Apr 9, 2013, at 8:56 pm, Mark Andrews <marka at isc.org> wrote:

[?]

>> There are multiple documents to read and you can find them all here.
>> 
>> https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm
>> 
>> If anyone has specific questions about the draft RAA, they should
>> contact Samantha Eisner, whose contact details are on that page.
>> 
>> Regards,
>> 
>> Leo
> 
> Looking at
> https://www.icann.org/en/resources/registrars/raa/proposed-additional-operation-07mar13-en.pdf
> there is nothing which requires registrars to support AAAA on the web
> pages when A records are supported on web pages.
> 
> AAAA and DS updates currently often required registrants to jump through
> all sorts of hoops compared to adding A and NS records.
> 
> Maintenance of A, AAAA, NS and DS records are core functionality and
> need to be treated as such.

That is exactly the kind of input that is valuable to the consultation. I encourage you to submit it there so it is considered.

Regards,

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

From bmanning at vacation.karoshi.com  Wed Apr 10 07:42:39 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 10 Apr 2013 07:42:39 +0000
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <5164D8ED.5010608@abenaki.wabanaki.net>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
 <5164D8ED.5010608@abenaki.wabanaki.net>
Message-ID: <20130410074239.GA9550@vacation.karoshi.com.>

On Tue, Apr 09, 2013 at 08:13:49PM -0700, Eric Brunner-Williams wrote:
> On 4/9/13 5:47 PM, Jared Mauch wrote:
> > Can you point is at the right address or form to submit regarding this? Seems like its time for both on AAAA and DS. 
> 
> Jared,
> 
> Joe is an employee of the corporation, a rather high ranking one. As I
> mentioned in my response to Mark, he _may_ be in a position to
> encourage both legal to develop new language for future addition to
> the RAA, and the Registrar Liaison to socialize the issue to those RAA
> parties who are members of the Registrar Stakeholder Group within the
> Contracted Parties House of the GNSO, and the Compliance team.
> 
> As a matter of policy development you should expect that Registrars
> (recall hat) have been presented with ... proposed new terms and
> conditions that ... are not universally appreciated, and so one must
> either (a) impose new conditions unilaterally upon counter-parties,
> arguing some theory of necessity, or (b) negotiate a mutually
> agreeable modification.
> 
> There is a lot of heat lost in the ICANN system, so to re-purpose the
> off-hand observation of John Curran made recently, operators having
> some rough consensus on desirable features of RRSet editors may be a
> necessary predicate to policy intervention. As I observed to John, the
> ISP Constituency within the ICANN GNSO has been an effective advocate
> of trademark policy, and no other policy area, since the Montevideo
> General meeting, in 2001.
> 
> Eric
> 
> P.S. I may be turning in my Registrar hat in the near future.

	From the Beijing mtg of ICANN - There is a real concern about the 
	disparity of requirement;

	the pre 2009 contracts,
	the 2009 contracts,
	the proposed 2013 contracts.

	unfortunately the 2013 contract language is pretty much baked
	and the only wiggle room is bringing the old contracts into compliance 
	with the 2013 text.  The trigger for the change now is the introduction
	of new TLDs. 

	the one other avenue is to take this ti the ATRT2 folks and get this 
	included as a matter of ICANN perfomance.


	OR - just move to a registrar who gives you what you want and not
	empower ICANN with the ability to set/control operational choice.


	YMMV of course.

/bill


From jared at puck.nether.net  Wed Apr 10 11:42:06 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 10 Apr 2013 07:42:06 -0400
Subject: Open Resolver Dataset Update
In-Reply-To: <CAHGyo+-zKv2hwcK4=Yod5TPnahEEMQthVWr31pqErpyoNhgPvg@mail.gmail.com>
References: <B8A475BA-F131-4A14-AB08-16FBE64858FE@puck.nether.net>
 <51626CF9.1040109@phyxia.net>
 <BCCE3736-E0D5-4F52-9A09-87D79F0CD156@puck.nether.net>
 <1365512377.22965.76.camel@galaxy>
 <E719A2C5-2EB1-425B-8756-605BCD4DED8C@puck.nether.net>
 <CAHGyo+-zKv2hwcK4=Yod5TPnahEEMQthVWr31pqErpyoNhgPvg@mail.gmail.com>
Message-ID: <426BB2D1-D04F-4D43-8F3B-FD7303610C37@puck.nether.net>

I sent you a private reply, but also posting publicly?


On Apr 9, 2013, at 4:55 PM, "A. Pishdadi" <apishdadi at gmail.com> wrote:

> In the last 2 weeks we have seen double the amount of ddos attacks, and way bigger then normal. All of them being amplification attacks. I think the media whoring done during the spamhaus debacle motivated more people to invest time building up there openresolver list, since really no one has disclosed attacks of that size and gave the blueprints of how to do it. Now we know the attack has been around for awhile but no one really knew how big they could take it until a couple weeks ago.. 
> 
> Now I know your openresolver DB is meant to get them closed but it would take only a small amount of someones day to write a script to crawl your database.. You go to fixedorbit.com or something of the sort, look up the as's of the biggest hosting companies, plop there list of ip allocaitons in to a text file, run the script and boom i now have the biggest open resolver list to feed my botnet.. Maybe you should require some sort of CAPTCHA or registration to view that database. While im sure people have other ways of gathering up the open resolvers , you just took away all the work and handed it to them on a silver platter. While i am and others surely are greatful for the data, i think a little more thought should be put in how you are going to deliver the data to who should have it, and that would be the network / AS they are hanging off of.

Both systems that return a referral to root and that do full recursion are being abused in attacks.

Honestly, if you send 100kpps to 2^32 IPs it would take ~12 hours.  If you have 10 hosts to scan at a lower rate and skip all the 'unused' space, e.g.: 0/8 10/8 127/8 224/4 you cut down the time as well.

I won't say exactly how long my weekly process takes, but it doesn't take long if you wanted to replicate the data.

About 1:122 hosts responds in some fashion.

That means for any given /24, expect there to be about 2 responses.  While that may not be the case for some blocks, there's a good chance something is responding nearby.  At some point the lack of scoping your response will result in a real problem for the person being attacked.  Your hosts will get used in an attack.  It's not really an IF question anymore.

- jared

From m.hotze at hotze.com  Wed Apr 10 12:08:31 2013
From: m.hotze at hotze.com (Martin Hotze)
Date: Wed, 10 Apr 2013 12:08:31 +0000
Subject: NANOG - csi reset request (was: RE: NANOG Digest, Vol 63, Issue 45)
Message-ID: <F02A0931E2E6254680832D6A24940C2DEDA372@hx01.srv.hotze.com>


to be fair: cloudmark did its best to contact me and it seems that we've been able to resolve the issue. thanks!

as a side note: it might be a good idea to have some sort of lookup-tool on the website or an email notification to the netblock owner.

thanks again (and also to the people off-list), martin



> Date: Wed, 10 Apr 2013 03:43:57 +0000
> From: Martin Hotze <m.hotze at hotze.com>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Cc: "bwilliams at cloudmark.com" <bwilliams at cloudmark.com>
> Subject: RE: NANOG Digest, Vol 63, Issue 45
> Message-ID:
> 	<F02A0931E2E6254680832D6A24940C2DED1964 at hx01.srv.hotze.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Bryan,
> 
> nope, it didn't make it through to my inbox . I try to contact you through
> other channels.
> 
> 
> Martin
> 
> > Date: Wed, 10 Apr 2013 02:41:42 +0000
> > From: Bryan Williams <bwilliams at cloudmark.com>
> > To: "nanog at nanog.org" <nanog at nanog.org>
> > Subject: NANOG - csi reset request
> > Message-ID: <CD8A4959.62CFA%bwilliams at cloudmark.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Martin,
> >
> > I sent you this email from our corporate email, and haven't heard back.
> Did
> > you receive this?
> >
> > Regards,
> > Bryan Williams
> > Sr. Solutions Architect
> > Cloudmark, Inc
> >
> > From: Bryan Williams
> > <bwilliams at cloudmark.com<mailto:bwilliams at cloudmark.com>>
> > Date: Tuesday, April 9, 2013 12:58 PM
> > To: "m.hotze at hotze.com<mailto:m.hotze at hotze.com>"
> > <m.hotze at hotze.com<mailto:m.hotze at hotze.com>>
> > Subject: NANOG - csi reset request
> >
> > I searched through the recent requests, and couldn't find any with your
> email
> > address as the contact email. Can you give me the IP you tried to
> unblock?
> >
> > Or, try it again and let us know that you did it so we can watch. If
> there's a
> > bug, we'd like to fix it.
> >
> > Regards,
> > Bryan Williams
> > Sr. Solutions Architect



From carlosm3011 at gmail.com  Wed Apr 10 12:56:39 2013
From: carlosm3011 at gmail.com (Carlos M. martinez)
Date: Wed, 10 Apr 2013 08:56:39 -0400
Subject: RPKI Support on the Juniper SRX line
Message-ID: <51656187.4080307@gmail.com>

Hello all,

I'm working with a Juniper partner in Colombia on a possible RPKI
deployment.

As far as I understand Juniper's website, only the T, M and MX lines
support RPKI, yet the partner insists that Junos 12.3 / 13.1 supports
RPKI on the SRX line.

I cannot find any document or reference confirming this.

Any comments would be appreciated.

regards,

~Carlos


From tore at fud.no  Wed Apr 10 13:09:56 2013
From: tore at fud.no (Tore Anderson)
Date: Wed, 10 Apr 2013 15:09:56 +0200
Subject: RPKI Support on the Juniper SRX line
In-Reply-To: <51656187.4080307@gmail.com>
References: <51656187.4080307@gmail.com>
Message-ID: <516564A4.4050003@fud.no>

* Carlos M. martinez

> the partner insists that Junos 12.3 / 13.1 supports RPKI on the SRX
> line.

JUNOS 12.3 and 13.1 aren't supported on SRX at all.

>From e.g. http://www.juniper.net/support/downloads/?p=srx5600 :

?High: Junos OS Release 12.2, 12.3 and 13.1 are not supported On SRX
Series, J Series, LN1000 and WXC-ISM-200( PSN-2012-09-707).?

Tore



From brunner at nic-naa.net  Wed Apr 10 17:20:30 2013
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 10 Apr 2013 10:20:30 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <5164D8ED.5010608@abenaki.wabanaki.net>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org> <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
 <5164D8ED.5010608@abenaki.wabanaki.net>
Message-ID: <51659F5E.5010000@nic-naa.net>

In time of response order:

There is Leo's reference to the not yet concluded RAA process, in
which a para contains possibly relevant "registrar shall" terms.

This is forward looking (the proposed RAA is not yet required by the
Corporation) and may apply only to parties contracting with the
Corporation for the right to provide "registrar services" to some, not
all, registries, operated under some contract with the Corporation.

It may, if read creatively, solve the problem for a "new registrar"
offering registration services for one or more "new gTLD(s)", but that
may be the extent of its applicability. If the creative reading fails,
AAAA and DS may fall outside of these "registrar shall" terms.

Next, there is Mark's observation, citing the same proposed RAA, that
if the registrar provides a web interface (note well the "if"), and
this web interface provides a means to edit A and NS records, there is
no additional functional requirement for AAAA and/or DS.

Mark observes that AAAA and DS updates require more from the
registrant (also the registrar, when software, testing, staff
(technical, support desk, and legal) training are not abstracted by a
magic wand), and then observes that:
 > Maintenance of A, AAAA, NS and DS records are core functionality and
> need to be treated as such.

Here I personally differ. For those not paying attention to my
slightest utterance over the past 15 years of NEWDOM policy and
technology...

I am sure that v6 matters to some, but not all, at least not in the
manditory-to-implement-yesterday sense advocated by the v6
evangelicals (who have captured the Corporation on this issue).

I'm also sure that DNSSEC matters to some, but not all, at least not
in the manditory-to-implement-yesterday sense advocated by the DNSSEC
evangelicals (who have captured the Corporation on this issue).

Some 80% of the available-by-contract names in the namespace published
by the US DoC through its contractors, Verisign and the Corporation
lie in one zone, which became signed as recently as March 31, 2011
(see Matt Larson's note to the DNSSEC deployment list). Of those a
very small minority are signed.

v6 availability statistics for North America, where over half of the
registrars possessing the accreditation of the Corporation to offer
registration services for this namespace are domiciled, and by
inference, a substantial fraction of the registrant domains are
hosted, are similarly a very small minority.

It seems to me, and I don't suggest that anyone else hold this view,
least of all the v6/DNSSEC evangelicals, that it is possible for one
or more registrants to exist who desire neither to sign their domains,
nor to ensure their availability via v6. This registrant, or these
registrants, would be well served by a registrar which did not offer
AAAA and/or DS record editing services. It also seems to me, and
again, I don't suggest that anyone else hold this view, that the
number of such registrants could be sufficient to support a cost
recovery operator of a namespace which is not signed, and for which no
AAAA record, in the namespace published by the US Doc (through its
contractors, blah blah) exists.

Obviously, the converse view carried the day, though not (yet) for
namespaces not operated under contract with the Corporation. Leo's
follow-up on input valuable to the consultation would, I think, have
scope limited only to "new registrars" offering registry services to
"new registries". See the "very small minority" observations, supra.

Finally, Bill points out that there are several contracts still
applicable, and the rather turgid nature of the policy and
implementation dialog(s) of the opposing parties around the proposed
2013 contracts. There are registrars operating under the pre-2009 and
the 2009 contracts looking at forming distinct legal entities to enter
into the eventual post-2012 contract, a reasonable scenario is
trademark exploitation and exit, iterated across a series of unlikely
to be sustainable product launches, and there are registrars that
simply won't bother with future "landrush" sales any more than they
bother with current "expiry" sales. The point being the "trigger" Bill
mentioned isn't universal, it really is limited to those who's
registrar business interest in the Corporation is brand extension, or
are applicants for vertically integrated registries.

Bill observes that the ATRT2 is a possible venue.

This may be, but on the whole, the interest of the United States
Government in the capture of its delegated rule maker by the regulated
businesses is limited. There was one mention "... a group of
participants that engage in [Corporation]'s processes to a greater
extent than ..." in the AoC of September 2009. Subsequent public
communications of the Government concerning Notice and Comment
obligations, usually referred to as "accountability and transparency"
by the Corporation, are not evident to me.

Bill closes with an obvious recommendation -- pick a registrar that
works for your definition of "work".

Of course this is the only useful act in the continuous present, as
the Corporation adopted ab initio, and retains, a de minimus and
reactive approach to contracted party oversight (see Sightfinder,
tasting, ...) and "caveat emptor" (aka "registrant choice") exercised
through initial selection, and transfer (when possible), are the means
for "regulation through the market" of the registrar function.

Basically, its "good luck with that" for any notion of MAY or MUST
language on functionality, sort of like the fate of BCP38 and similar.

My mileage is zero.
Eric






From cconn at b2b2c.ca  Wed Apr 10 21:14:45 2013
From: cconn at b2b2c.ca (Chris Conn)
Date: Wed, 10 Apr 2013 17:14:45 -0400
Subject: IPv6 Cogent customers
Message-ID: <5165D645.5020304@b2b2c.ca>

Hello,

Any single-homed or more IPv6 AS174  customers willing to take a 5 
minute test for me?  Please contact me off-list.  We are not single 
homed to them but we have a particular destination that is having 
issues, and the funky part is that any outbound traffic over the Cogent 
transit is just bezerk.  TCP SYN packets never reach the remote end.  
Return traffic, even when forced over Cogent however, is fine.  I can 
force outbound traffic to flow over two other transit providers, and all 
is kosher so long as I never use AS174 to try and _get_ there.

Cogent is blaming Level3 just because they appear in the traceroute, 
therefore I would like if possible a third party to help me since Cogent 
doesn't seem inclined to do anything other than ping.

Thanks in advance and sorry for the noise,

Chris



From rayw at rayw.net  Wed Apr 10 21:30:52 2013
From: rayw at rayw.net (Ray Wong)
Date: Wed, 10 Apr 2013 14:30:52 -0700
Subject: Noction?
Message-ID: <CAM8Fm=5oBAhNUw5FX4NukhOrpv4X=qaCWDtgqgo403fk3-GOvw@mail.gmail.com>

gotten a few cold calls from Noction. All I see is some PR about BGP
happiness and good feelings with no technical hints about what they
actually have to offer. They haven't even hit me directly, rather seem
to be chasing us down via corporate listings, so are giving me
not-confident feelings I should even return a call to them. Anyone
know anything about them?

-R>


From copraphage at gmail.com  Wed Apr 10 21:33:15 2013
From: copraphage at gmail.com (Chris McDonald)
Date: Wed, 10 Apr 2013 21:33:15 +0000
Subject: Noction?
Message-ID: <873307853-1365629597-cardhu_decombobulator_blackberry.rim.net-1899517606-@b17.c1.bise6.blackberry>

I think you answered your own question


------Original Message------
From: Ray Wong
To: nanog list
Subject: Noction?
Sent: Apr 10, 2013 5:30 PM

gotten a few cold calls from Noction. All I see is some PR about BGP
happiness and good feelings with no technical hints about what they
actually have to offer. They haven't even hit me directly, rather seem
to be chasing us down via corporate listings, so are giving me
not-confident feelings I should even return a call to them. Anyone
know anything about them?

-R>





From aaron at wholesaleinternet.net  Wed Apr 10 21:56:51 2013
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Wed, 10 Apr 2013 16:56:51 -0500
Subject: Noction?
In-Reply-To: <CAM8Fm=5oBAhNUw5FX4NukhOrpv4X=qaCWDtgqgo403fk3-GOvw@mail.gmail.com>
References: <CAM8Fm=5oBAhNUw5FX4NukhOrpv4X=qaCWDtgqgo403fk3-GOvw@mail.gmail.com>
Message-ID: <5165E023.2080009@wholesaleinternet.net>

It's like the Internap FCP.  I think it's been on the market about a year.

They're a nice group of guys and the product does what they say it does.

Aaron



On 4/10/2013 4:30 PM, Ray Wong wrote:
> gotten a few cold calls from Noction. All I see is some PR about BGP
> happiness and good feelings with no technical hints about what they
> actually have to offer. They haven't even hit me directly, rather seem
> to be chasing us down via corporate listings, so are giving me
> not-confident feelings I should even return a call to them. Anyone
> know anything about them?
>
> -R>
>



From paul at gtcomm.net  Wed Apr 10 22:38:27 2013
From: paul at gtcomm.net (Paul)
Date: Wed, 10 Apr 2013 18:38:27 -0400
Subject: Noction?
In-Reply-To: <5165E023.2080009@wholesaleinternet.net>
References: <CAM8Fm=5oBAhNUw5FX4NukhOrpv4X=qaCWDtgqgo403fk3-GOvw@mail.gmail.com>
 <5165E023.2080009@wholesaleinternet.net>
Message-ID: <5165E9E3.8000801@gtcomm.net>

We are using the product. It works fairly well although the code is 
still slightly immature at the moment.
Started using it about a year ago in beta and it has greatly improved 
over time (due to a lot of input from us beta testing it in the process :> )


On 4/10/2013 5:56 PM, Aaron Wendel wrote:
> It's like the Internap FCP.  I think it's been on the market about a 
> year.
>
> They're a nice group of guys and the product does what they say it does.
>
> Aaron
>
>
>
> On 4/10/2013 4:30 PM, Ray Wong wrote:
>> gotten a few cold calls from Noction. All I see is some PR about BGP
>> happiness and good feelings with no technical hints about what they
>> actually have to offer. They haven't even hit me directly, rather seem
>> to be chasing us down via corporate listings, so are giving me
>> not-confident feelings I should even return a call to them. Anyone
>> know anything about them?
>>
>> -R>
>>
>
>
>

-- 
GloboTech Communications
Phone: 1-514-907-0050 x 215
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
paul at gtcomm.net
http://www.gtcomm.net



From lord2y at gmail.com  Wed Apr 10 22:05:40 2013
From: lord2y at gmail.com (Alessandro Ratti)
Date: Thu, 11 Apr 2013 00:05:40 +0200
Subject: IPv6 Cogent customers
In-Reply-To: <5165D645.5020304@b2b2c.ca>
References: <5165D645.5020304@b2b2c.ca>
Message-ID: <CAE3Ey0-+vEQb2OcQhPoj9+Yfd7smhyKVPy8JezuqsAj30gq6_g@mail.gmail.com>

I try to write to you but I receive this error:

Delivery to the following recipient failed permanently:

     CConn at b2b2c.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for
the recipient domain b2b2c.com bysmtp.cidc.net. [66.158.128.32].



On Wed, Apr 10, 2013 at 11:14 PM, Chris Conn <cconn at b2b2c.ca> wrote:

> Hello,
>
> Any single-homed or more IPv6 AS174  customers willing to take a 5 minute
> test for me?  Please contact me off-list.  We are not single homed to them
> but we have a particular destination that is having issues, and the funky
> part is that any outbound traffic over the Cogent transit is just bezerk.
>  TCP SYN packets never reach the remote end.  Return traffic, even when
> forced over Cogent however, is fine.  I can force outbound traffic to flow
> over two other transit providers, and all is kosher so long as I never use
> AS174 to try and _get_ there.
>
> Cogent is blaming Level3 just because they appear in the traceroute,
> therefore I would like if possible a third party to help me since Cogent
> doesn't seem inclined to do anything other than ping.
>
> Thanks in advance and sorry for the noise,
>
> Chris
>
>
>


-- 
Alessandro Ratti
http://about.me/alessandroratti

NOTICE
This message is for the named person's use only and it's confidential.
If you receive this message in error, please immediately delete it and
and notify the sender. Thank you.

From lstewart at superb.net  Wed Apr 10 22:57:36 2013
From: lstewart at superb.net (Landon Stewart)
Date: Wed, 10 Apr 2013 16:57:36 -0600
Subject: Noction?
In-Reply-To: <CAM8Fm=5oBAhNUw5FX4NukhOrpv4X=qaCWDtgqgo403fk3-GOvw@mail.gmail.com>
References: <CAM8Fm=5oBAhNUw5FX4NukhOrpv4X=qaCWDtgqgo403fk3-GOvw@mail.gmail.com>
Message-ID: <20130410225736.GA11481@prometheus.brandlesshosting.net>

If you run a multi-homed network calling them back can't hurt.  Apparently they provide route optimization like Internap but is available for smaller networks.  

On Wed, Apr 10, 2013 at 02:30:52PM -0700, Ray Wong wrote:
> gotten a few cold calls from Noction. All I see is some PR about BGP
> happiness and good feelings with no technical hints about what they
> actually have to offer. They haven't even hit me directly, rather seem
> to be chasing us down via corporate listings, so are giving me
> not-confident feelings I should even return a call to them. Anyone
> know anything about them?
> 
> -R>
> 


From wbailey at satelliteintelligencegroup.com  Thu Apr 11 17:11:25 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Thu, 11 Apr 2013 17:11:25 +0000
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
Message-ID: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>

I try not to flood Nanog with articles, but I thought I'd ask for some opinions on this. For the moment, most browsers treat a single line with no tld as a search request, why have a tld-less tld? Would this not open the door for others to claim they need a word as a tld (cisco = http://routers or Al Gore http://internets), and how would that be handled by most modern(ish) browsers and devices?


http://m.gizmodo.com/5994354/google-wants-to-create-a-dotless-domain-called-search



Sent from my T-Mobile 4G LTE Device

From j at 2600hz.com  Thu Apr 11 17:29:28 2013
From: j at 2600hz.com (Joshua Goldbard)
Date: Thu, 11 Apr 2013 17:29:28 +0000
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>
References: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>
Message-ID: <6CCBBA2E-DB1E-4DF8-90D5-7239CBD345B3@2600hz.com>

I'm hoping google is doing this for m2m and not human interaction, but I could be wrong.

I just envision years of re-educating grandparents and less technical users and I'm dreading it.

Cheers,
Joshua

Sent from my iPhone

On Apr 11, 2013, at 10:14 AM, "Warren Bailey" <wbailey at satelliteintelligencegroup.com> wrote:

> I try not to flood Nanog with articles, but I thought I'd ask for some opinions on this. For the moment, most browsers treat a single line with no tld as a search request, why have a tld-less tld? Would this not open the door for others to claim they need a word as a tld (cisco = http://routers or Al Gore http://internets), and how would that be handled by most modern(ish) browsers and devices?
> 
> 
> http://m.gizmodo.com/5994354/google-wants-to-create-a-dotless-domain-called-search
> 
> 
> 
> Sent from my T-Mobile 4G LTE Device


From oliver at g.garraux.net  Thu Apr 11 19:56:29 2013
From: oliver at g.garraux.net (Oliver Garraux)
Date: Thu, 11 Apr 2013 15:56:29 -0400
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <6CCBBA2E-DB1E-4DF8-90D5-7239CBD345B3@2600hz.com>
References: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>
 <6CCBBA2E-DB1E-4DF8-90D5-7239CBD345B3@2600hz.com>
Message-ID: <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>

The whole custom TLD thing is just a truly awful, awful idea.

Oliver

-------------------------------------

Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux


On Thu, Apr 11, 2013 at 1:29 PM, Joshua Goldbard <j at 2600hz.com> wrote:

> I'm hoping google is doing this for m2m and not human interaction, but I
> could be wrong.
>
> I just envision years of re-educating grandparents and less technical
> users and I'm dreading it.
>
> Cheers,
> Joshua
>
> Sent from my iPhone
>
> On Apr 11, 2013, at 10:14 AM, "Warren Bailey" <
> wbailey at satelliteintelligencegroup.com> wrote:
>
> > I try not to flood Nanog with articles, but I thought I'd ask for some
> opinions on this. For the moment, most browsers treat a single line with no
> tld as a search request, why have a tld-less tld? Would this not open the
> door for others to claim they need a word as a tld (cisco = http://routersor Al Gore
> http://internets), and how would that be handled by most modern(ish)
> browsers and devices?
> >
> >
> >
> http://m.gizmodo.com/5994354/google-wants-to-create-a-dotless-domain-called-search
> >
> >
> >
> > Sent from my T-Mobile 4G LTE Device
>
>

From ask at develooper.com  Thu Apr 11 20:53:49 2013
From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Thu, 11 Apr 2013 13:53:49 -0700
Subject: Why are there no GeoDNS solutions anywhere in sight?
In-Reply-To: <CAPKkNb63hqpT4CLcQ-TiMfYZtrqqT=1TRouKkQGn-QwdHCJO3g@mail.gmail.com>
References: <CAPKkNb63hqpT4CLcQ-TiMfYZtrqqT=1TRouKkQGn-QwdHCJO3g@mail.gmail.com>
Message-ID: <2A386FA3-EF00-42B3-93CF-D18975AAE58E@develooper.com>


On Mar 20, 2013, at 20:28, Constantine A. Murenin <mureninc at gmail.com> wrote:

> [...] but what other alternatives could be configured in 5 or 15 minutes?

You got a lot of answers telling you to not even try, and I don't know that you can configure any of them in 5 minutes.

That being said there are lots of options that might be "good enough":

 - PowerDNS has a Geo backend - http://doc.powerdns.com/html/geo.html
 - There are various patches for Bind
 - Gdnsd - https://github.com/blblack/gdnsd
 - GeoDNS - https://github.com/abh/geodns

I use the latter for the www.pool.ntp.org service where it sends users to one of about 4000 local servers ("pops") in about 100 countries about 15 billion times a month.



Ask

From lstewart at superb.net  Thu Apr 11 23:04:07 2013
From: lstewart at superb.net (Landon Stewart)
Date: Thu, 11 Apr 2013 17:04:07 -0600
Subject: Why are there no GeoDNS solutions anywhere in sight?
In-Reply-To: <2A386FA3-EF00-42B3-93CF-D18975AAE58E@develooper.com>
References: <CAPKkNb63hqpT4CLcQ-TiMfYZtrqqT=1TRouKkQGn-QwdHCJO3g@mail.gmail.com>
 <2A386FA3-EF00-42B3-93CF-D18975AAE58E@develooper.com>
Message-ID: <20130411230407.GA6079@prometheus.brandlesshosting.net>

On Thu, Apr 11, 2013 at 01:53:49PM -0700, Ask Bj?rn Hansen wrote:
> That being said there are lots of options that might be "good enough":
> 
>  - PowerDNS has a Geo backend - http://doc.powerdns.com/html/geo.html
>  - There are various patches for Bind
>  - Gdnsd - https://github.com/blblack/gdnsd
>  - GeoDNS - https://github.com/abh/geodns
> 
> I use the latter for the www.pool.ntp.org service where it sends users
> to one of about 4000 local servers ("pops") in about 100 countries
> about 15 billion times a month.

I haven't done it yet but gdnsd appeared to be the one to use when I
tested some stuff out.  The idea was to deligate a geo.domainname.com
zone to gdnsd and have it perform the GEO DNS lookups.  The PowerDNS
one, while testing it, gave me problems trying to figure out how to get
the geographical data since the readme I was using was out of date and a
lot of the information lead to non-existent links etc.


From yang.yu.list at gmail.com  Thu Apr 11 23:13:40 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Thu, 11 Apr 2013 19:13:40 -0400
Subject: Google incorrect IPv6 GeoIP
Message-ID: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>

For some reason Google redirects requests from Dreamhost's IPv6 block
2607:f298::/32 to google.com.hk

$ wget http://www.google.com
--2013-04-11 16:06:45--  http://www.google.com/
Resolving www.google.com... 2607:f8b0:400c:c01::93, 173.194.75.99,
173.194.75.147, ...
Connecting to www.google.com|2607:f8b0:400c:c01::93|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
[following]
--2013-04-11 16:06:46--
http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
Resolving www.google.com.hk... 2607:f8b0:400c:c01::6a, 173.194.75.105,
173.194.75.99, ...
Connecting to www.google.com.hk|2607:f8b0:400c:c01::6a|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.com.hk/ [following]
--2013-04-11 16:06:46--  http://www.google.com.hk/
Reusing existing connection to www.google.com.hk:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ?index.html?


The report IP problem form
(https://support.google.com/websearch/contact/ip?rd=1) does not think
IPv6 addresses are valid.

Can someone help with this issue?

Thanks.

Yang


From randy at psg.com  Fri Apr 12 05:52:00 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 12 Apr 2013 14:52:00 +0900
Subject: spam scraper?
Message-ID: <m2r4ig47pb.wl%randy@psg.com>

anyone else being spammed by noxious slime Doina Chiorescu
<sales at noction.com> selling bgp snake oil?

randy


From edward.dore at freethought-internet.co.uk  Fri Apr 12 06:18:49 2013
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Fri, 12 Apr 2013 07:18:49 +0100
Subject: spam scraper?
In-Reply-To: <m2r4ig47pb.wl%randy@psg.com>
References: <m2r4ig47pb.wl%randy@psg.com>
Message-ID: <DC38EF8A-A9D9-49DF-AD91-0EB74D54F308@freethought-internet.co.uk>

We've had multiple e-mails from them to myself and another member of staff directly. They don't seem to give up if you ignore them either, they keep sending follow up e-mails saying that they haven't had any response!

Given the addresses that they contacted, I suspect that they are mining details from PeeringDB.

Edward Dore 
Freethought Internet 

On 12 Apr 2013, at 06:52, Randy Bush wrote:

> anyone else being spammed by noxious slime Doina Chiorescu
> <sales at noction.com> selling bgp snake oil?
> 
> randy
> 


From hschiller at google.com  Fri Apr 12 14:53:06 2013
From: hschiller at google.com (Heather Schiller)
Date: Fri, 12 Apr 2013 10:53:06 -0400
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
Message-ID: <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>

Forwarded to folks I think should be able to help..

 --Heather


On Thu, Apr 11, 2013 at 7:13 PM, Yang Yu <yang.yu.list at gmail.com> wrote:

> For some reason Google redirects requests from Dreamhost's IPv6 block
> 2607:f298::/32 to google.com.hk
>
> $ wget http://www.google.com
> --2013-04-11 16:06:45--  http://www.google.com/
> Resolving www.google.com... 2607:f8b0:400c:c01::93, 173.194.75.99,
> 173.194.75.147, ...
> Connecting to www.google.com|2607:f8b0:400c:c01::93|:80... connected.
> HTTP request sent, awaiting response... 302 Found
> Location:
> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
> [following]
> --2013-04-11 16:06:46--
>
> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
> Resolving www.google.com.hk... 2607:f8b0:400c:c01::6a, 173.194.75.105,
> 173.194.75.99, ...
> Connecting to www.google.com.hk|2607:f8b0:400c:c01::6a|:80... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: http://www.google.com.hk/ [following]
> --2013-04-11 16:06:46--  http://www.google.com.hk/
> Reusing existing connection to www.google.com.hk:80.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> Saving to: ?index.html?
>
>
> The report IP problem form
> (https://support.google.com/websearch/contact/ip?rd=1) does not think
> IPv6 addresses are valid.
>
> Can someone help with this issue?
>
> Thanks.
>
> Yang
>
>

From cb.list6 at gmail.com  Fri Apr 12 15:06:02 2013
From: cb.list6 at gmail.com (cb.list6)
Date: Fri, 12 Apr 2013 08:06:02 -0700
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
Message-ID: <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>

Heather,

I see the same thing from my arpnetworks vps

[cbyrne at chair6 ~]$ traceroute6 www.google.com
traceroute6 to www.google.com (2404:6800:4003:801::1010) from
2607:f2f8:a8e0::2, 64 hops                   max, 12 byte packets
 1  2607:f2f8:a8e0::1  1.657 ms  0.976 ms  0.750 ms
 2  2001:504:13::1a  1.728 ms  10.591 ms  0.756 ms
 3  2001:4860:1:1:0:1b1b:0:19  0.873 ms  0.907 ms  0.833 ms
 4  2001:4860::1:0:29b3  1.195 ms  138.964 ms
    2001:4860::1:0:991  1.633 ms
 5  2001:4860::8:0:2996  1.645 ms
    2001:4860::8:0:2995  1.929 ms  1.484 ms
 6  2001:4860::1:0:47  99.059 ms  99.272 ms
    2001:4860::1:0:75  99.079 ms
 7  2001:4860::1:0:298  99.372 ms  111.549 ms  99.972 ms
 8  2001:4860::1:0:26ff  103.146 ms  103.317 ms  103.029 ms
 9  2001:4860::1:0:337f  166.821 ms  203.479 ms  166.468 ms
10  2001:4860:0:1::18f  167.021 ms  167.378 ms  166.896 ms
11  2404:6800:8000:4::e  167.039 ms  167.099 ms  167.254 ms
[cbyrne at chair6 ~]$ dig www.google.com aaaa

; <<>> DiG 9.6.-ESV-R3 <<>> www.google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50127
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.                        IN      AAAA

;; ANSWER SECTION:
www.google.com.         15      IN      AAAA    2404:6800:4003:801::1010

;; AUTHORITY SECTION:
google.com.             271198  IN      NS      ns1.google.com.
google.com.             271198  IN      NS      ns3.google.com.
google.com.             271198  IN      NS      ns2.google.com.
google.com.             271198  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         61968   IN      A       216.239.32.10
ns3.google.com.         61968   IN      A       216.239.36.10
ns4.google.com.         61968   IN      A       216.239.38.10
ns2.google.com.         61968   IN      A       216.239.34.10

;; Query time: 1 msec
;; SERVER: 208.79.88.7#53(208.79.88.7)
;; WHEN: Fri Apr 12 08:04:59 2013
;; MSG SIZE  rcvd: 196

[cbyrne at chair6 ~]$

On Fri, Apr 12, 2013 at 7:53 AM, Heather Schiller <hschiller at google.com> wrote:
> Forwarded to folks I think should be able to help..
>
>  --Heather
>
>
> On Thu, Apr 11, 2013 at 7:13 PM, Yang Yu <yang.yu.list at gmail.com> wrote:
>
>> For some reason Google redirects requests from Dreamhost's IPv6 block
>> 2607:f298::/32 to google.com.hk
>>
>> $ wget http://www.google.com
>> --2013-04-11 16:06:45--  http://www.google.com/
>> Resolving www.google.com... 2607:f8b0:400c:c01::93, 173.194.75.99,
>> 173.194.75.147, ...
>> Connecting to www.google.com|2607:f8b0:400c:c01::93|:80... connected.
>> HTTP request sent, awaiting response... 302 Found
>> Location:
>> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
>> [following]
>> --2013-04-11 16:06:46--
>>
>> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
>> Resolving www.google.com.hk... 2607:f8b0:400c:c01::6a, 173.194.75.105,
>> 173.194.75.99, ...
>> Connecting to www.google.com.hk|2607:f8b0:400c:c01::6a|:80... connected.
>> HTTP request sent, awaiting response... 302 Found
>> Location: http://www.google.com.hk/ [following]
>> --2013-04-11 16:06:46--  http://www.google.com.hk/
>> Reusing existing connection to www.google.com.hk:80.
>> HTTP request sent, awaiting response... 200 OK
>> Length: unspecified [text/html]
>> Saving to: ?index.html?
>>
>>
>> The report IP problem form
>> (https://support.google.com/websearch/contact/ip?rd=1) does not think
>> IPv6 addresses are valid.
>>
>> Can someone help with this issue?
>>
>> Thanks.
>>
>> Yang
>>
>>


From tfritz at novia.net  Fri Apr 12 17:14:19 2013
From: tfritz at novia.net (Tom Fritz)
Date: Fri, 12 Apr 2013 12:14:19 -0500 (CDT)
Subject: spam scraper?
In-Reply-To: <DC38EF8A-A9D9-49DF-AD91-0EB74D54F308@freethought-internet.co.uk>
References: <m2r4ig47pb.wl%randy@psg.com>
 <DC38EF8A-A9D9-49DF-AD91-0EB74D54F308@freethought-internet.co.uk>
Message-ID: <alpine.BSF.2.10.1304121210190.8975@oasis.novia.net>



> We've had multiple e-mails from them to myself and another member of staff directly. They don't seem to give up if you ignore them either, they keep sending follow up e-mails saying that they haven't had any response!
>
> Given the addresses that they contacted, I suspect that they are mining details from PeeringDB.
>
> Edward Dore
> Freethought Internet
>
> On 12 Apr 2013, at 06:52, Randy Bush wrote:
>
>> anyone else being spammed by noxious slime Doina Chiorescu
>> <sales at noction.com> selling bgp snake oil?
>>
>> randy


 	We have also seen multiple emails and now voicemails from them. 
Based on the address they sent the email to and numbeds they are calling 
they scraped the info from some online DB's..

Tom.


From cscora at apnic.net  Fri Apr 12 18:34:15 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 13 Apr 2013 04:34:15 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201304121834.r3CIYFOP003457@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 13 Apr, 2013

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

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

BGP routing table entries examined:                              450537
    Prefixes after maximum aggregation:                          184360
    Deaggregation factor:                                          2.44
    Unique aggregates announced to Internet:                     222129
Total ASes present in the Internet Routing Table:                 43823
    Prefixes per ASN:                                             10.28
Origin-only ASes present in the Internet Routing Table:           34458
Origin ASes announcing only one prefix:                           16077
Transit ASes present in the Internet Routing Table:                5796
Transit-only ASes present in the Internet Routing Table:            140
Average AS path length visible in the Internet Routing Table:       4.7
    Max AS path length visible:                                      29
    Max AS path prepend of ASN ( 19037)                              22
Prefixes from unregistered ASNs in the Routing Table:               375
    Unregistered ASNs in the Routing Table:                         138
Number of 32-bit ASNs allocated by the RIRs:                       4720
Number of 32-bit ASNs visible in the Routing Table:                3569
Prefixes from 32-bit ASNs in the Routing Table:                   10153
Special use prefixes present in the Routing Table:                   19
Prefixes being announced from unallocated address space:            212
Number of addresses announced to Internet:                   2612870220
    Equivalent to 155 /8s, 189 /16s and 60 /24s
    Percentage of available address space announced:               70.6
    Percentage of allocated address space announced:               70.6
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               94.4
Total number of prefixes smaller than registry allocations:      159211

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

Prefixes being announced by APNIC Region ASes:                   108096
    Total APNIC prefixes after maximum aggregation:               33356
    APNIC Deaggregation factor:                                    3.24
Prefixes being announced from the APNIC address blocks:          109305
    Unique aggregates announced from the APNIC address blocks:    44363
APNIC Region origin ASes present in the Internet Routing Table:    4819
    APNIC Prefixes per ASN:                                       22.68
APNIC Region origin ASes announcing only one prefix:               1225
APNIC Region transit ASes present in the Internet Routing Table:    813
Average APNIC Region AS path length visible:                        4.8
    Max APNIC Region AS path length visible:                         21
Number of APNIC region 32-bit ASNs visible in the Routing Table:    493
Number of APNIC addresses announced to Internet:              720693952
    Equivalent to 42 /8s, 244 /16s and 234 /24s
    Percentage of available APNIC address space announced:         84.2

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 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:                    157854
    Total ARIN prefixes after maximum aggregation:                79682
    ARIN Deaggregation factor:                                     1.98
Prefixes being announced from the ARIN address blocks:           158545
    Unique aggregates announced from the ARIN address blocks:     72575
ARIN Region origin ASes present in the Internet Routing Table:    15633
    ARIN Prefixes per ASN:                                        10.14
ARIN Region origin ASes announcing only one prefix:                5945
ARIN Region transit ASes present in the Internet Routing Table:    1614
Average ARIN Region AS path length visible:                         4.2
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:      18
Number of ARIN addresses announced to Internet:              1062493824
    Equivalent to 63 /8s, 84 /16s and 94 /24s
    Percentage of available ARIN address space announced:          56.2

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 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:                    116555
    Total RIPE prefixes after maximum aggregation:                59393
    RIPE Deaggregation factor:                                     1.96
Prefixes being announced from the RIPE address blocks:           120091
    Unique aggregates announced from the RIPE address blocks:     77021
RIPE Region origin ASes present in the Internet Routing Table:    17131
    RIPE Prefixes per ASN:                                         7.01
RIPE Region origin ASes announcing only one prefix:                8159
RIPE Region transit ASes present in the Internet Routing Table:    2805
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                          29
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2294
Number of RIPE addresses announced to Internet:               656281316
    Equivalent to 39 /8s, 30 /16s and 14 /24s
    Percentage of available RIPE address space announced:          95.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 196608-199679
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:                   47674
    Total LACNIC prefixes after maximum aggregation:               9391
    LACNIC Deaggregation factor:                                   5.08
Prefixes being announced from the LACNIC address blocks:          51709
    Unique aggregates announced from the LACNIC address blocks:   24114
LACNIC Region origin ASes present in the Internet Routing Table:   1889
    LACNIC Prefixes per ASN:                                      27.37
LACNIC Region origin ASes announcing only one prefix:               561
LACNIC Region transit ASes present in the Internet Routing Table:   351
Average LACNIC Region AS path length visible:                       4.9
    Max LACNIC Region AS path length visible:                        29
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   757
Number of LACNIC addresses announced to Internet:             126775336
    Equivalent to 7 /8s, 142 /16s and 112 /24s
    Percentage of available LACNIC address space announced:        75.6

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

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

Prefixes being announced by AfriNIC Region ASes:                  10065
    Total AfriNIC prefixes after maximum aggregation:              2490
    AfriNIC Deaggregation factor:                                  4.04
Prefixes being announced from the AfriNIC address blocks:         10675
    Unique aggregates announced from the AfriNIC address blocks:   3859
AfriNIC Region origin ASes present in the Internet Routing Table:   614
    AfriNIC Prefixes per ASN:                                     17.39
AfriNIC Region origin ASes announcing only one prefix:              187
AfriNIC Region transit ASes present in the Internet Routing Table:  127
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    7
Number of AfriNIC addresses announced to Internet:             46187264
    Equivalent to 2 /8s, 192 /16s and 195 /24s
    Percentage of available AfriNIC address space announced:       45.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
 4766     2957      11557         923   Korea Telecom (KIX)
17974     2510        840          86   PT TELEKOMUNIKASI INDONESIA
 7545     1884        320         109   TPG Internet Pty Ltd
 4755     1734        392         198   TATA Communications formerly 
 9829     1511       1205          40   BSNL National Internet Backbo
 9583     1283         98         538   Sify Limited
 7552     1171       1066          12   Vietel Corporation
 4808     1121       2109         325   CNCGROUP IP network: China169
 9498     1070        310          73   BHARTI Airtel Ltd.
24560     1066        385         163   Bharti Airtel Ltd., Telemedia

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3037       3694          87   bellsouth.net, inc. 
 7029     2174       1265         212   Windstream Communications Inc
18566     2068        382         184   Covad Communications 
22773     2013       2929         125   Cox Communications, Inc.
 1785     1974        677         122   PaeTec Communications, Inc.
20115     1669       1611         611   Charter Communications 
 4323     1608       1139         397   Time Warner Telecom
30036     1340        296         658   Mediacom Communications Corp 
 7018     1316      10807         856   AT&T WorldNet Services
11492     1218        224         333   Cable One 

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1840        544          16   Corbina telecom
 2118     1430         97          13   EUnet/RELCOM Autonomous Syste
34984     1145        234         207   BILISIM TELEKOM
12479      844        786          66   Uni2 Autonomous System
13188      837         99          33   Educational Network
20940      822        288         652   Akamai Technologies European 
31148      793         41          21   FreeNet ISP
 6830      752       2318         442   UPC Distribution Services
 8551      734        368          56   Bezeq International
58113      666         74         386   LIR DATACENTER TELECOM SRL

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
28573     2601       1433          98   NET Servicos de Comunicao S.A
10620     2361        409         223   TVCABLE BOGOTA 
 7303     1674       1153         211   Telecom Argentina Stet-France
 8151     1228       2684         404   UniNet S.A. de C.V. 
 6503     1151        435          68   AVANTEL, S.A. 
14754     1119        153          37   Telgua S. A. 
18881      850        716          18   Global Village Telecom 
27947      809         88          97   Telconet S.A
11830      725        364          14   Instituto Costarricense de El
 3816      695        306          85   Empresa Nacional de Telecomun

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
36998     1137         80           4   MOBITEL
24863      691        274          33   LINKdotNET AS number
 6713      543        617          25   Itissalat Al-MAGHRIB
 8452      353        956           9   TEDATA
24835      275         80           8   RAYA Telecom - Egypt
 3741      262        906         220   The Internet Solution 
12258      193         28          67   Vodacom Internet Company 
29975      191        667          21   Vodacom
16637      184        696          90   MTN Network Solutions
33776      167         11          18   Starcomms Nigeria Limited

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

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3037       3694          87   bellsouth.net, inc. 
 4766     2957      11557         923   Korea Telecom (KIX)
28573     2601       1433          98   NET Servicos de Comunicao S.A
17974     2510        840          86   PT TELEKOMUNIKASI INDONESIA
10620     2361        409         223   TVCABLE BOGOTA 
 7029     2174       1265         212   Windstream Communications Inc
18566     2068        382         184   Covad Communications 
22773     2013       2929         125   Cox Communications, Inc.
 1785     1974        677         122   PaeTec Communications, Inc.
 7545     1884        320         109   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
28573      2601        2503      NET Servicos de Comunicao S.A
17974      2510        2424      PT TELEKOMUNIKASI INDONESIA
10620      2361        2138      TVCABLE BOGOTA 
 4766      2957        2034      Korea Telecom (KIX)
 7029      2174        1962      Windstream Communications Inc
22773      2013        1888      Cox Communications, Inc.
18566      2068        1884      Covad Communications 
 1785      1974        1852      PaeTec Communications, Inc.
 8402      1840        1824      Corbina telecom
 7545      1884        1775      TPG Internet Pty Ltd

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

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

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
30031   UNALLOCATED  12.27.122.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24         209       Qwest 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic
33649   UNALLOCATED  12.111.112.0/24      19029       New Edge Networks 
26064   UNALLOCATED  12.149.37.0/24        7018       AT&T WorldNet Servic

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

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

Prefix             Origin AS  Description
128.0.0.0/24          2876     Jump Management SRL
128.0.16.0/21        43568     RIPE Network Coordination Cen
128.0.24.0/21        41794     Altline LLC
128.0.55.0/24        48571     SC efectRO SRL
128.0.56.0/24        60996     Visionware SRL
128.0.58.0/23         9050     RTD-ROMTELECOM Autonomous Sys
128.0.72.0/21        23456     32-bit ASN transition
128.0.80.0/20        52041     Timer LTD
128.0.96.0/21        12886     LEWTelNet GmbH
128.0.104.0/23       51848     FOP Gabidullina Ludmila Nikol

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

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

Network            Origin AS  Description
41.222.80.0/21       37110     Moztel LDA
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 
64.185.224.0/24      27431     JTL Networks Inc.
64.185.225.0/24      27431     JTL Networks Inc.
64.185.226.0/24      27431     JTL Networks Inc.
64.185.227.0/24      27431     JTL Networks Inc.
64.185.228.0/24      27431     JTL Networks Inc.
64.185.229.0/24      27431     JTL Networks Inc.
64.185.230.0/24      27431     JTL Networks 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:29      /11:88      /12:248     
/13:485     /14:884     /15:1558    /16:12677   /17:6608    /18:10914   
/19:21813   /20:31911   /21:33781   /22:46684   /23:41774   /24:236885  
/25:1390    /26:1771    /27:862     /28:45      /29:67      /30:15      
/31:0       /32:19      

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

  ASN   No of nets  Total ann.   Description
18566     2019          2068      Covad Communications 
 6389     1742          3037      bellsouth.net, inc. 
 7029     1613          2174      Windstream Communications Inc
 8402     1537          1840      Corbina telecom
22773     1318          2013      Cox Communications, Inc.
30036     1217          1340      Mediacom Communications Corp 
11492     1179          1218      Cable One 
36998     1131          1137      MOBITEL
 1785     1047          1974      PaeTec Communications, Inc.
 6983     1006          1134      ITC^Deltacom 

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

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

   1:767       2:796       3:3         4:15        5:861       6:4      
   8:542      12:1920     13:3        14:769      15:11       16:3      
  17:9        20:19       23:257      24:1776     27:1451     31:1207   
  32:42       33:2        34:5        36:43       37:1798     38:861    
  39:2        40:169      41:2626     42:185      44:6        46:1789   
  47:2        49:619      50:676      52:12       54:30       55:9      
  57:27       58:1108     59:588      60:305      61:1446     62:992    
  63:2033     64:4287     65:2183     66:4294     67:2066     68:1119   
  69:3252     70:876      71:529      72:1917     74:2565     75:411    
  76:294      77:1096     78:1040     79:590      80:1235     81:976    
  82:613      83:579      84:589      85:1165     86:471      87:964    
  88:527      89:1806     90:281      91:5489     92:614      93:1718   
  94:1871     95:1610     96:503      97:340      98:1050     99:41     
 100:29      101:311     103:2412    105:488     106:135     107:207    
 108:515     109:1783    110:851     111:1046    112:501     113:783    
 114:689     115:1014    116:876     117:778     118:1016    119:1249   
 120:389     121:817     122:1730    123:1176    124:1332    125:1328   
 128:635     129:226     130:332     131:654     132:336     133:148    
 134:258     135:62      136:222     137:248     138:344     139:185    
 140:199     141:317     142:542     143:372     144:485     145:93     
 146:510     147:384     148:697     149:366     150:163     151:528    
 152:419     153:194     154:44      155:395     156:259     157:394    
 158:267     159:717     160:337     161:424     162:379     163:202    
 164:575     165:450     166:336     167:578     168:1026    169:133    
 170:1025    171:174     172:5       173:1609    174:580     175:445    
 176:1233    177:1842    178:1808    179:2       180:1394    181:378    
 182:1130    183:374     184:662     185:354     186:2449    187:1255   
 188:2007    189:1361    190:6606    192:6488    193:5833    194:4646   
 195:3643    196:1333    197:826     198:4322    199:5280    200:6034   
 201:2373    202:8860    203:8755    204:4518    205:2553    206:2822   
 207:2833    208:4065    209:3561    210:2928    211:1565    212:2025   
 213:1917    214:943     215:98      216:5212    217:1575    218:624    
 219:347     220:1270    221:547     222:314     223:443    

End of report


From cidr-report at potaroo.net  Fri Apr 12 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 12 Apr 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201304122200.r3CM00pg097931@wattle.apnic.net>

This report has been generated at Fri Apr 12 21:13:18 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        05-04-13    451091      259574
        06-04-13    451411      259542
        07-04-13    451419      259733
        08-04-13    451504      259558
        09-04-13    451113      259685
        10-04-13    451462      259694
        11-04-13    451345      259947
        12-04-13    452468      259746


AS Summary
         43924  Number of ASes in routing system
         18224  Number of ASes announcing only one prefix
          3037  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      116992736  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 12Apr13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     452668   259832   192836    42.6%   All ASes

AS6389      3037       91     2946    97.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2957      939     2018    68.2%   KIXS-AS-KR Korea Telecom
AS17974     2510      569     1941    77.3%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS28573     2602      759     1843    70.8%   NET Servi?os de Comunica??o
                                               S.A.
AS22773     2013      174     1839    91.4%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS18566     2068      473     1595    77.1%   COVAD - Covad Communications
                                               Co.
AS2118      1430       49     1381    96.6%   RELCOM-AS OOO "NPO Relcom"
AS7303      1674      448     1226    73.2%   Telecom Argentina S.A.
AS4323      1611      401     1210    75.1%   TWTC - tw telecom holdings,
                                               inc.
AS10620     2361     1244     1117    47.3%   Telmex Colombia S.A.
AS4755      1734      638     1096    63.2%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS14754     1131      107     1024    90.5%   Telgua
AS7029      2174     1243      931    42.8%   WINDSTREAM - Windstream
                                               Communications Inc
AS7552      1171      241      930    79.4%   VIETEL-AS-AP Vietel
                                               Corporation
AS18881      850       20      830    97.6%   Global Village Telecom
AS18101     1001      180      821    82.0%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS1785      1974     1209      765    38.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4808      1121      361      760    67.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS36998     1137      382      755    66.4%   SDN-MOBITEL
AS13977      837      129      708    84.6%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS855        724       50      674    93.1%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS8151      1237      579      658    53.2%   Uninet S.A. de C.V.
AS6983      1133      481      652    57.5%   ITCDELTA - ITC^Deltacom
AS22561     1085      453      632    58.2%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      734      108      626    85.3%   GIGAINFRA Softbank BB Corp.
AS3549      1050      443      607    57.8%   GBLX Global Crossing Ltd.
AS17908      793      198      595    75.0%   TCISL Tata Communications
AS3356      1089      495      594    54.5%   LEVEL3 Level 3 Communications
AS19262      991      403      588    59.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS24560     1066      478      588    55.2%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services

Total      45295    13345    31950    70.5%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.80.0/21       AS37110 moztel-as
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.187.208.0/24      AS174   COGENT Cogent/PSI
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS30097 NUWAVE - NuWave
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        81.22.64.0/20        AS5511  OPENTRANSIT France Telecom S.A.
        82.101.160.0/19      AS5511  OPENTRANSIT France Telecom S.A.
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.52.192.0/24      AS27919 
        190.52.193.0/24      AS27919 
        190.52.194.0/24      AS27919 
        190.52.195.0/24      AS27919 
        190.52.196.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.197.0/24      AS27919 
        190.52.198.0/24      AS27919 
        190.52.199.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.200.0/24      AS27947 Telconet S.A
        190.52.201.0/24      AS27947 Telconet S.A
        190.52.202.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.203.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.205.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.206.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.207.0/24      AS3549  GBLX Global Crossing Ltd.
        190.111.96.0/20      AS27589 MOJOHOST - MOJOHOST
        190.111.128.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.144.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.160.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.176.0/20     AS27589 MOJOHOST - MOJOHOST
        190.115.64.0/20      AS27589 MOJOHOST - MOJOHOST
        190.115.80.0/20      AS27589 MOJOHOST - MOJOHOST
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        191.255.0.0/16       AS6983  ITCDELTA - ITC^Deltacom
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.53.0.0/19        AS13878 UOL DIVEO S.A.
        200.58.248.0/21      AS27849 
        200.107.248.0/24     AS27919 
        200.107.249.0/24     AS27919 
        200.107.250.0/24     AS27919 
        200.107.251.0/24     AS27919 
        200.107.252.0/24     AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
        201.71.16.0/20       AS28638 
        201.77.96.0/20       AS28639 
        201.222.32.0/20      AS27821 
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.58.113.0/24      AS19161 
        202.65.96.0/20       AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.73.240.0/20      AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.10.112.0/21      AS27027 ANBELL ASN-ANBELL
        204.11.112.0/22      AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.91.72.0/24       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        213.150.204.0/24     AS29338 AFOL-AS Used by Africaonline Operations
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Apr 12 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 12 Apr 2013 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201304122200.r3CM01P1097945@wattle.apnic.net>

BGP Update Report
Interval: 04-Apr-13 -to- 11-Apr-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS47331          187185  7.9%      86.9 -- TTNET TTNet A.S.
 2 - AS58113           70417  3.0%     105.7 -- LIR-AS LIR DATACENTER TELECOM SRL
 3 - AS4538            49555  2.1%     104.8 -- ERX-CERNET-BKB China Education and Research Network Center
 4 - AS9829            45795  1.9%      45.0 -- BSNL-NIB National Internet Backbone
 5 - AS8402            40069  1.7%      47.1 -- CORBINA-AS OJSC "Vimpelcom"
 6 - AS2708            35747  1.5%     244.8 -- Universidad de Guanajuato
 7 - AS27947           32399  1.4%      84.6 -- Telconet S.A
 8 - AS33776           26384  1.1%     212.8 -- STARCOMMS-ASN
 9 - AS8551            25842  1.1%      33.8 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone
10 - AS9121            24919  1.1%      33.5 -- TTNET Turk Telekomunikasyon Anonim Sirketi
11 - AS3909            22217  0.9%    3173.9 -- QWEST-AS-3908 - Qwest Communications Company, LLC
12 - AS34984           22121  0.9%      29.4 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.
13 - AS2118            21417  0.9%      15.0 -- RELCOM-AS OOO "NPO Relcom"
14 - AS7552            19478  0.8%      17.7 -- VIETEL-AS-AP Vietel Corporation
15 - AS14754           16995  0.7%      20.5 -- Telgua
16 - AS23216           15083  0.6%     150.8 -- MEGADATOS S.A.
17 - AS55714           15023  0.6%      59.9 -- APNIC-FIBERLINK-PK Fiberlink Pvt.Ltd
18 - AS647             14808  0.6%     120.4 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center
19 - AS2697            14109  0.6%     127.1 -- ERX-ERNET-AS Education and Research Network
20 - AS50710           13653  0.6%      27.7 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS19406            4256  0.2%    4256.0 -- TWRS-MA - Towerstream I, Inc.
 2 - AS3909            22217  0.9%    3173.9 -- QWEST-AS-3908 - Qwest Communications Company, LLC
 3 - AS6174             5864  0.2%    2932.0 -- SPRINTLINK8 - Sprint
 4 - AS6629             7438  0.3%    2479.3 -- NOAA-AS - NOAA
 5 - AS14680            6595  0.3%    2198.3 -- REALE-6 - Auction.com
 6 - AS5074             3931  0.2%    1965.5 -- ASN-ATTELS - AT&T BMGS
 7 - AS4467             1846  0.1%    1846.0 -- EASYLINK3 - AT&T Services, Inc.
 8 - AS37367            3667  0.1%    1833.5 -- CALLKEY
 9 - AS42860            1475  0.1%    1475.0 -- EFT Energy Financing Team (Switzerland) AG
10 - AS17293            5300  0.2%    1325.0 -- VTXC - VTX Communications
11 - AS9950             3356  0.1%    1118.7 -- PUBNETPLUS2-AS-KR DACOM
12 - AS19886            2188  0.1%    1094.0 -- BOFABROKERDEALERSVCS - Bank of America
13 - AS41023            4156  0.2%    1039.0 -- ARREKS-AS Agencja Rozwoju Regionalnego ARREKS S.A.
14 - AS45344             907  0.0%     907.0 -- IIUM-MY International Islamic University Of Malaysia
15 - AS40028             873  0.0%     873.0 -- SPD-NETWORK-1 - SPD NETWORK
16 - AS15322             867  0.0%     867.0 -- WDNCOM-ASN - WDN Communications S.A.
17 - AS23295             802  0.0%     802.0 -- EA-01 - Extend America
18 - AS31598             777  0.0%     777.0 -- TELECOMAX-AS FOP Savostin Oleg Lubobisch
19 - AS33521             712  0.0%     712.0 -- MSLA-SCHOOLS - Missoula County Public Schools
20 - AS23139             656  0.0%     656.0 -- IHI - Intelligent Holdings, Inc.


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.41.70.0/24     9405  0.4%   AS2697  -- ERX-ERNET-AS Education and Research Network
 2 - 192.58.232.0/24    7434  0.3%   AS6629  -- NOAA-AS - NOAA
 3 - 151.118.18.0/24    7291  0.3%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 4 - 151.118.254.0/24   7249  0.3%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 5 - 151.118.255.0/24   7248  0.3%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 6 - 92.246.207.0/24    7201  0.3%   AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
 7 - 209.142.140.0/24   7103  0.3%   AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc.
 8 - 12.139.133.0/24    5397  0.2%   AS14680 -- REALE-6 - Auction.com
 9 - 194.63.9.0/24      4536  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
10 - 64.194.229.0/24    4471  0.2%   AS3356  -- LEVEL3 Level 3 Communications
11 - 69.38.178.0/24     4256  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
12 - 216.183.32.0/19    3999  0.2%   AS17293 -- VTXC - VTX Communications
13 - 41.75.40.0/21      3666  0.1%   AS37367 -- CALLKEY
14 - 58.184.229.0/24    3347  0.1%   AS9950  -- PUBNETPLUS2-AS-KR DACOM
15 - 205.65.128.0/22    3085  0.1%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
                                     AS647   -- DNIC-ASBLK-00616-00665 - DoD Network Information Center
16 - 206.105.75.0/24    2932  0.1%   AS6174  -- SPRINTLINK8 - Sprint
17 - 208.16.110.0/24    2932  0.1%   AS6174  -- SPRINTLINK8 - Sprint
18 - 193.19.90.0/23     2776  0.1%   AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet
19 - 115.170.128.0/17   2749  0.1%   AS4847  -- CNIX-AP China Networks Inter-Exchange
20 - 2.93.235.0/24      2738  0.1%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From jmkeller at houseofzen.org  Fri Apr 12 22:17:20 2013
From: jmkeller at houseofzen.org (James M Keller)
Date: Fri, 12 Apr 2013 18:17:20 -0400
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>
References: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>
 <6CCBBA2E-DB1E-4DF8-90D5-7239CBD345B3@2600hz.com>
 <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>
Message-ID: <516887F0.2070607@houseofzen.org>

On 4/11/2013 3:56 PM, Oliver Garraux wrote:
> The whole custom TLD thing is just a truly awful, awful idea.
>
> Oliver
>
> -------------------------------------
>
> Oliver Garraux
> Check out my blog:  blog.garraux.net
> Follow me on Twitter:  twitter.com/olivergarraux
>
>

AOL 'go' words were cool the firs time around - now with the interwebs!

-- 
---
James M Keller



From mysidia at gmail.com  Fri Apr 12 22:41:38 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 12 Apr 2013 17:41:38 -0500
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>
References: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>
 <6CCBBA2E-DB1E-4DF8-90D5-7239CBD345B3@2600hz.com>
 <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>
Message-ID: <CAAAwwbVWWSr36pjw+LjDPRiGJFSfVivj6S4DvSWZdMi_7bpbkQ@mail.gmail.com>

On 4/11/13, Oliver Garraux <oliver at g.garraux.net> wrote:

Agreed;  but it would seem that unstoppable forces have been set into
motion by ICANN, to cause it to happen, regardless of whether it is
beneficial to the community, and regardless of any objections from the
public...

Yes...  let a single organization own http://search
No intrinsic bias here... no unfairness,  for a single organization to
hold that name...

Right...


> The whole custom TLD thing is just a truly awful, awful idea.
>
> Oliver
>
> -------------------------------------

--
-JH


From surfer at mauigateway.com  Fri Apr 12 23:10:49 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 12 Apr 2013 16:10:49 -0700
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
Message-ID: <20130412161049.D651F7AA@resin11.mta.everyone.net>


On 4/11/13, Oliver Garraux <oliver at g.garraux.net> wrote:

> The whole custom TLD thing is just a truly awful, awful idea.
--------------------------------------------------

--------- mysidia at gmail.com wrote: -------------------
From: Jimmy Hess <mysidia at gmail.com>

Agreed;  but it would seem that unstoppable forces have been set into
motion by ICANN, to cause it to happen, regardless of whether it is
beneficial to the community, and regardless of any objections from the
public...
----------------------------------------------


I believe that unstoppable force is called the want of money. 

scott


From joelja at bogus.com  Fri Apr 12 22:53:11 2013
From: joelja at bogus.com (joel jaeggli)
Date: Fri, 12 Apr 2013 15:53:11 -0700
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <CAAAwwbVWWSr36pjw+LjDPRiGJFSfVivj6S4DvSWZdMi_7bpbkQ@mail.gmail.com>
References: <ac9i5h1yh6vqjkplum7urfbf.1365700281865@email.android.com>
 <6CCBBA2E-DB1E-4DF8-90D5-7239CBD345B3@2600hz.com>
 <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>
 <CAAAwwbVWWSr36pjw+LjDPRiGJFSfVivj6S4DvSWZdMi_7bpbkQ@mail.gmail.com>
Message-ID: <51689057.9040007@bogus.com>

On 4/12/13 3:41 PM, Jimmy Hess wrote:
> On 4/11/13, Oliver Garraux <oliver at g.garraux.net> wrote:
>
> Agreed;  but it would seem that unstoppable forces have been set into
> motion by ICANN, to cause it to happen, regardless of whether it is
> beneficial to the community, and regardless of any objections from the
> public...
>
> Yes...  let a single organization own http://search
> No intrinsic bias here... no unfairness,  for a single organization to
> hold that name...
>
> Right...
Still riding high from their success with .mobi (disclaimer, I worked 
for Nokia at the time, it was a bad idea then, it's still a bad idea)...

It's entirely plausible that you're overselling the value of a gtld a bit.
>> The whole custom TLD thing is just a truly awful, awful idea.
>>
>> Oliver
>>
>> -------------------------------------
> --
> -JH
>



From jra at baylink.com  Sat Apr 13 00:42:48 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 12 Apr 2013 20:42:48 -0400 (EDT)
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <CAD_uLpMQqdMDvFNmRZ0gqjvjvJ9q7BcMEULSprEME_4RhJi-jQ@mail.gmail.com>
Message-ID: <24608431.2051.1365813768327.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Oliver Garraux" <oliver at g.garraux.net>

> Subject: Re: Google Wants to Create a Dotless Domain Called "Search"..?
> The whole custom TLD thing is just a truly awful, awful idea.

Whether gTLD expansion is a good or bad idea (protip: good) is orthogonal
to whether anyone who has such a gTLD should be permitted to put A records 
in the DNS for the TLD proper (protip: bad, and they'd find
out the hard way, since most things would break).

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From morrowc.lists at gmail.com  Sat Apr 13 00:58:09 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 12 Apr 2013 20:58:09 -0400
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
 <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
Message-ID: <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>

On Fri, Apr 12, 2013 at 11:06 AM, cb.list6 <cb.list6 at gmail.com> wrote:

> Heather,
>
> I see the same thing from my arpnetworks vps
>
>
no you don't... the dreamhost example used the google ARIN allocation
2607:: .... this example uses the 2404 APNIC allocation.

note that this may still be 'wrong', but .. it's a different wrong. :)


> [cbyrne at chair6 ~]$ traceroute6 www.google.com
> traceroute6 to www.google.com (2404:6800:4003:801::1010) from
> 2607:f2f8:a8e0::2, 64 hops                   max, 12 byte packets
>  1  2607:f2f8:a8e0::1  1.657 ms  0.976 ms  0.750 ms
>  2  2001:504:13::1a  1.728 ms  10.591 ms  0.756 ms
>  3  2001:4860:1:1:0:1b1b:0:19  0.873 ms  0.907 ms  0.833 ms
>  4  2001:4860::1:0:29b3  1.195 ms  138.964 ms
>     2001:4860::1:0:991  1.633 ms
>  5  2001:4860::8:0:2996  1.645 ms
>     2001:4860::8:0:2995  1.929 ms  1.484 ms
>  6  2001:4860::1:0:47  99.059 ms  99.272 ms
>     2001:4860::1:0:75  99.079 ms
>  7  2001:4860::1:0:298  99.372 ms  111.549 ms  99.972 ms
>  8  2001:4860::1:0:26ff  103.146 ms  103.317 ms  103.029 ms
>  9  2001:4860::1:0:337f  166.821 ms  203.479 ms  166.468 ms
> 10  2001:4860:0:1::18f  167.021 ms  167.378 ms  166.896 ms
> 11  2404:6800:8000:4::e  167.039 ms  167.099 ms  167.254 ms
> [cbyrne at chair6 ~]$ dig www.google.com aaaa
>
> ; <<>> DiG 9.6.-ESV-R3 <<>> www.google.com aaaa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50127
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
>
> ;; QUESTION SECTION:
> ;www.google.com.                        IN      AAAA
>
> ;; ANSWER SECTION:
> www.google.com.         15      IN      AAAA    2404:6800:4003:801::1010
>
> ;; AUTHORITY SECTION:
> google.com.             271198  IN      NS      ns1.google.com.
> google.com.             271198  IN      NS      ns3.google.com.
> google.com.             271198  IN      NS      ns2.google.com.
> google.com.             271198  IN      NS      ns4.google.com.
>
> ;; ADDITIONAL SECTION:
> ns1.google.com.         61968   IN      A       216.239.32.10
> ns3.google.com.         61968   IN      A       216.239.36.10
> ns4.google.com.         61968   IN      A       216.239.38.10
> ns2.google.com.         61968   IN      A       216.239.34.10
>
> ;; Query time: 1 msec
> ;; SERVER: 208.79.88.7#53(208.79.88.7)
> ;; WHEN: Fri Apr 12 08:04:59 2013
> ;; MSG SIZE  rcvd: 196
>
> [cbyrne at chair6 ~]$
>
> On Fri, Apr 12, 2013 at 7:53 AM, Heather Schiller <hschiller at google.com>
> wrote:
> > Forwarded to folks I think should be able to help..
> >
> >  --Heather
> >
> >
> > On Thu, Apr 11, 2013 at 7:13 PM, Yang Yu <yang.yu.list at gmail.com> wrote:
> >
> >> For some reason Google redirects requests from Dreamhost's IPv6 block
> >> 2607:f298::/32 to google.com.hk
> >>
> >> $ wget http://www.google.com
> >> --2013-04-11 16:06:45--  http://www.google.com/
> >> Resolving www.google.com... 2607:f8b0:400c:c01::93, 173.194.75.99,
> >> 173.194.75.147, ...
> >> Connecting to www.google.com|2607:f8b0:400c:c01::93|:80... connected.
> >> HTTP request sent, awaiting response... 302 Found
> >> Location:
> >>
> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
> >> [following]
> >> --2013-04-11 16:06:46--
> >>
> >>
> http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1365721636015681&usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww
> >> Resolving www.google.com.hk... 2607:f8b0:400c:c01::6a, 173.194.75.105,
> >> 173.194.75.99, ...
> >> Connecting to www.google.com.hk|2607:f8b0:400c:c01::6a|:80...
> connected.
> >> HTTP request sent, awaiting response... 302 Found
> >> Location: http://www.google.com.hk/ [following]
> >> --2013-04-11 16:06:46--  http://www.google.com.hk/
> >> Reusing existing connection to www.google.com.hk:80.
> >> HTTP request sent, awaiting response... 200 OK
> >> Length: unspecified [text/html]
> >> Saving to: ?index.html?
> >>
> >>
> >> The report IP problem form
> >> (https://support.google.com/websearch/contact/ip?rd=1) does not think
> >> IPv6 addresses are valid.
> >>
> >> Can someone help with this issue?
> >>
> >> Thanks.
> >>
> >> Yang
> >>
> >>
>
>

From scott at doc.net.au  Sat Apr 13 01:48:23 2013
From: scott at doc.net.au (Scott Howard)
Date: Fri, 12 Apr 2013 18:48:23 -0700
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
 <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
 <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>
Message-ID: <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>

On Fri, Apr 12, 2013 at 5:58 PM, Christopher Morrow <morrowc.lists at gmail.com
> wrote:

> no you don't... the dreamhost example used the google ARIN allocation
> 2607:: .... this example uses the 2404 APNIC allocation.
>
> note that this may still be 'wrong', but .. it's a different wrong. :)
>

But likely caused by exactly the same problem - with the distinction
between between GeoIP of the DNS server and GeoIP of the client itself.

(Keeping in mind that the DNS lookup could be occurring over IPv4,
especially in the first example)

  Scott

From morrowc.lists at gmail.com  Sat Apr 13 02:04:33 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 12 Apr 2013 22:04:33 -0400
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
 <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
 <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>
 <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>
Message-ID: <CAL9jLaZ=VR_x6x4DrNXPsZHEmeAeD2xz0K1ThKuzaVUY7WrFSA@mail.gmail.com>

On Fri, Apr 12, 2013 at 9:48 PM, Scott Howard <scott at doc.net.au> wrote:

> On Fri, Apr 12, 2013 at 5:58 PM, Christopher Morrow <
> morrowc.lists at gmail.com> wrote:
>
>> no you don't... the dreamhost example used the google ARIN allocation
>> 2607:: .... this example uses the 2404 APNIC allocation.
>>
>> note that this may still be 'wrong', but .. it's a different wrong. :)
>>
>
> But likely caused by exactly the same problem - with the distinction
> between between GeoIP of the DNS server and GeoIP of the client itself.
>
> (Keeping in mind that the DNS lookup could be occurring over IPv4,
> especially in the first example)
>


except that the dreamhost example actually looked correct to me? (dreamhost
is in phx / lax or something similar... so a US answer seems on the ball)

From jra at baylink.com  Sat Apr 13 03:02:51 2013
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 12 Apr 2013 23:02:51 -0400 (EDT)
Subject: Fwd: [ PRIVACY Forum ] Huge attack on WordPress sites could spawn
 never-before-seen super botnet
In-Reply-To: <20130413013121.GB9298@vortex.com>
Message-ID: <9063421.2055.1365822171886.JavaMail.root@benjamin.baylink.com>

FYI.  Am I the only person just hearing about this?

----- Forwarded Message -----
> From: "PRIVACY Forum mailing list" <privacy at vortex.com>

> Huge attack on WordPress sites could spawn never-before-seen super
> botnet
> 
> http://j.mp/ZRZksL (ars technica)
> 
> "The unknown people behind the highly distributed attack are using
> more
> than 90,000 IP addresses to brute-force crack administrative
> credentials of vulnerable WordPress systems, researchers from at least
> three Web hosting services reported. At least one company warned that
> the attackers may be in the process of building a "botnet" of infected
> computers that's vastly stronger and more destructive than those
> available today. That's because the servers have bandwidth connections
> that that are typically tens, hundreds, or even thousands of times
> faster than botnets made of infected machines in homes and small
> businesses."
> 
> - - -
> 
> Up in the Net! It's a bug! It's a phish! It's SUPER-botnet!
> 
> --Lauren--
> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren
> Co-Founder: People For Internet Responsibility:
> http://www.pfir.org/pfir-info
> Founder:
> - Network Neutrality Squad: http://www.nnsquad.org
> - PRIVACY Forum: http://www.vortex.com/privacy-info
> - Data Wisdom Explorers League: http://www.dwel.org
> - Global Coalition for Transparent Internet Performance:
> http://www.gctip.org
> Member: ACM Committee on Computers and Public Policy
> Lauren's Blog: http://lauren.vortex.com
> Google+: http://vortex.com/g+lauren / Twitter:
> http://vortex.com/t-lauren
> Tel: +1 (818) 225-2800 / Skype: vortex.com
> 
> _______________________________________________
> privacy mailing list
> http://lists.vortex.com/mailman/listinfo/privacy

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From cody at hawkhost.com  Sat Apr 13 03:11:08 2013
From: cody at hawkhost.com (Cody Robertson)
Date: Fri, 12 Apr 2013 23:11:08 -0400
Subject: Fwd: [ PRIVACY Forum ] Huge attack on WordPress sites could spawn
 never-before-seen super botnet
In-Reply-To: <9063421.2055.1365822171886.JavaMail.root@benjamin.baylink.com>
References: <9063421.2055.1365822171886.JavaMail.root@benjamin.baylink.com>
Message-ID: <5168CCCB.6050504@hawkhost.com>

We're seeing heavy amounts of traffic / attacks as well - it's 
definitely not isolated to a single provider / range.

There are articles from HostGator, CloudFlare, Techcrunch and several 
others.

http://blog.hostgator.com/2013/04/11/global-wordpress-brute-force-flood/
http://blog.cloudflare.com/patching-the-internet-fixing-the-wordpress-br
http://techcrunch.com/2013/04/12/hackers-point-large-botnet-at-wordpress-sites-to-steal-admin-passwords-and-gain-server-access/

On 04/12/2013 11:02 PM, Jay Ashworth wrote:
> FYI.  Am I the only person just hearing about this?
>
> ----- Forwarded Message -----
>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>> Huge attack on WordPress sites could spawn never-before-seen super
>> botnet
>>
>> http://j.mp/ZRZksL (ars technica)
>>
>> "The unknown people behind the highly distributed attack are using
>> more
>> than 90,000 IP addresses to brute-force crack administrative
>> credentials of vulnerable WordPress systems, researchers from at least
>> three Web hosting services reported. At least one company warned that
>> the attackers may be in the process of building a "botnet" of infected
>> computers that's vastly stronger and more destructive than those
>> available today. That's because the servers have bandwidth connections
>> that that are typically tens, hundreds, or even thousands of times
>> faster than botnets made of infected machines in homes and small
>> businesses."
>>
>> - - -
>>
>> Up in the Net! It's a bug! It's a phish! It's SUPER-botnet!
>>
>> --Lauren--
>> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren
>> Co-Founder: People For Internet Responsibility:
>> http://www.pfir.org/pfir-info
>> Founder:
>> - Network Neutrality Squad: http://www.nnsquad.org
>> - PRIVACY Forum: http://www.vortex.com/privacy-info
>> - Data Wisdom Explorers League: http://www.dwel.org
>> - Global Coalition for Transparent Internet Performance:
>> http://www.gctip.org
>> Member: ACM Committee on Computers and Public Policy
>> Lauren's Blog: http://lauren.vortex.com
>> Google+: http://vortex.com/g+lauren / Twitter:
>> http://vortex.com/t-lauren
>> Tel: +1 (818) 225-2800 / Skype: vortex.com
>>
>> _______________________________________________
>> privacy mailing list
>> http://lists.vortex.com/mailman/listinfo/privacy



From eyeronic.design at gmail.com  Sat Apr 13 03:16:26 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Fri, 12 Apr 2013 20:16:26 -0700
Subject: Fwd: [ PRIVACY Forum ] Huge attack on WordPress sites could spawn
 never-before-seen super botnet
In-Reply-To: <5168CCCB.6050504@hawkhost.com>
References: <9063421.2055.1365822171886.JavaMail.root@benjamin.baylink.com>
 <5168CCCB.6050504@hawkhost.com>
Message-ID: <CAN3um4zY3CwbdbBeS1oEfLA_bcnt7hJFY8kOdFzxaLqdFYVTyw@mail.gmail.com>

I don't know if it's related, but Linode sent out an email earlier
that all account passwords (for all customers) must be reset.
Apparently one of their customers was succesfully exploited, and out
of an abundance of caution, they acting as if the attackers got the
Linode password hashes.

On Fri, Apr 12, 2013 at 8:11 PM, Cody Robertson <cody at hawkhost.com> wrote:
> We're seeing heavy amounts of traffic / attacks as well - it's definitely
> not isolated to a single provider / range.
>
> There are articles from HostGator, CloudFlare, Techcrunch and several
> others.
>
> http://blog.hostgator.com/2013/04/11/global-wordpress-brute-force-flood/
> http://blog.cloudflare.com/patching-the-internet-fixing-the-wordpress-br
> http://techcrunch.com/2013/04/12/hackers-point-large-botnet-at-wordpress-sites-to-steal-admin-passwords-and-gain-server-access/
>
>
> On 04/12/2013 11:02 PM, Jay Ashworth wrote:
>>
>> FYI.  Am I the only person just hearing about this?
>>
>> ----- Forwarded Message -----
>>>
>>> From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>>> Huge attack on WordPress sites could spawn never-before-seen super
>>> botnet
>>>
>>> http://j.mp/ZRZksL (ars technica)
>>>
>>> "The unknown people behind the highly distributed attack are using
>>> more
>>> than 90,000 IP addresses to brute-force crack administrative
>>> credentials of vulnerable WordPress systems, researchers from at least
>>> three Web hosting services reported. At least one company warned that
>>> the attackers may be in the process of building a "botnet" of infected
>>> computers that's vastly stronger and more destructive than those
>>> available today. That's because the servers have bandwidth connections
>>> that that are typically tens, hundreds, or even thousands of times
>>> faster than botnets made of infected machines in homes and small
>>> businesses."
>>>
>>> - - -
>>>
>>> Up in the Net! It's a bug! It's a phish! It's SUPER-botnet!
>>>
>>> --Lauren--
>>> Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren
>>> Co-Founder: People For Internet Responsibility:
>>> http://www.pfir.org/pfir-info
>>> Founder:
>>> - Network Neutrality Squad: http://www.nnsquad.org
>>> - PRIVACY Forum: http://www.vortex.com/privacy-info
>>> - Data Wisdom Explorers League: http://www.dwel.org
>>> - Global Coalition for Transparent Internet Performance:
>>> http://www.gctip.org
>>> Member: ACM Committee on Computers and Public Policy
>>> Lauren's Blog: http://lauren.vortex.com
>>> Google+: http://vortex.com/g+lauren / Twitter:
>>> http://vortex.com/t-lauren
>>> Tel: +1 (818) 225-2800 / Skype: vortex.com
>>>
>>> _______________________________________________
>>> privacy mailing list
>>> http://lists.vortex.com/mailman/listinfo/privacy
>
>
>



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


From yang.yu.list at gmail.com  Sat Apr 13 03:37:17 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Fri, 12 Apr 2013 23:37:17 -0400
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
 <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
 <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>
 <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>
Message-ID: <CAFwKRnSFB+X+e2jO8pExsCFsB8Mnxzz9eO3+V_V=Amy2_KjcPw@mail.gmail.com>

DNS is actually working correctly I think.
1) The outputs are from Dreamhost Ashburn, but I saw the same result
over IPv6 at Dreamhost LAX. Different DNS servers.
2) ping and ping6 times are pretty much the same. I suppose they are
served by the same Google cluster/CDN.
3) No redirect over IPv4



$dig www.google.com AAAA

; <<>> DiG 9.7.3 <<>> www.google.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30269
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      AAAA

;; ANSWER SECTION:
www.google.com.         209     IN      AAAA    2607:f8b0:400c:c04::63

;; Query time: 0 msec
;; SERVER: 208.113.157.201#53(208.113.157.201)
;; WHEN: Fri Apr 12 20:25:24 2013
;; MSG SIZE  rcvd: 60




$ traceroute 2607:f8b0:400c:c04::63
traceroute to 2607:f8b0:400c:c04::63 (2607:f8b0:400c:c04::63), 30 hops
max, 80 byte packets

 4  2607:f298:5:0:208:113:156:1 (2607:f298:5:0:208:113:156:1)  0.175
ms  0.179 ms  0.156 ms
 5  2001:438:fffe::5c5 (2001:438:fffe::5c5)  0.197 ms  0.186 ms  0.183 ms
 6  2001:438:ffff::407d:1882 (2001:438:ffff::407d:1882)  0.233 ms
0.231 ms  0.361 ms
 7  2001:438:ffff::407d:c52 (2001:438:ffff::407d:c52)  0.309 ms  0.288
ms  0.288 ms
 8  2001:4860::1:0:9ff (2001:4860::1:0:9ff)  1.529 ms  1.533 ms  1.601 ms
 9  2001:4860::8:0:3cda (2001:4860::8:0:3cda)  2.177 ms  0.968 ms
2001:4860::8:0:3cd9 (2001:4860::8:0:3cd9)  1.381 ms
10  2001:4860::8:0:33b2 (2001:4860::8:0:33b2)  12.431 ms
2001:4860::8:0:33b3 (2001:4860::8:0:33b3)  44.297 ms
2001:4860::8:0:33b2 (2001:4860::8:0:33b2)  12.371 ms
11  2001:4860::2:0:33b1 (2001:4860::2:0:33b1)  12.406 ms
2001:4860::2:0:33b0 (2001:4860::2:0:33b0)  13.059 ms
2001:4860::2:0:33b1 (2001:4860::2:0:33b1)  12.343 ms
12  vh-in-x63.1e100.net (2607:f8b0:400c:c04::63)  12.872 ms  12.845 ms
 12.899 ms




$ dig www.google.com

; <<>> DiG 9.7.3 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63365
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         244     IN      A       74.125.26.99
www.google.com.         244     IN      A       74.125.26.105
www.google.com.         244     IN      A       74.125.26.104
www.google.com.         244     IN      A       74.125.26.147
www.google.com.         244     IN      A       74.125.26.106
www.google.com.         244     IN      A       74.125.26.103

;; Query time: 0 msec
;; SERVER: 208.113.157.201#53(208.113.157.201)
;; WHEN: Fri Apr 12 20:24:49 2013
;; MSG SIZE  rcvd: 128




wget -4 http://www.google.com
--2013-04-12 20:29:26--  http://www.google.com/
Resolving www.google.com... 74.125.26.103, 74.125.26.99, 74.125.26.104, ...
Connecting to www.google.com|74.125.26.103|:80... connected.
HTTP request sent, awaiting response... 200 OK



Yang

On Fri, Apr 12, 2013 at 9:48 PM, Scott Howard <scott at doc.net.au> wrote:
> On Fri, Apr 12, 2013 at 5:58 PM, Christopher Morrow <morrowc.lists at gmail.com
>> wrote:
>
>> no you don't... the dreamhost example used the google ARIN allocation
>> 2607:: .... this example uses the 2404 APNIC allocation.
>>
>> note that this may still be 'wrong', but .. it's a different wrong. :)
>>
>
> But likely caused by exactly the same problem - with the distinction
> between between GeoIP of the DNS server and GeoIP of the client itself.
>
> (Keeping in mind that the DNS lookup could be occurring over IPv4,
> especially in the first example)
>
>   Scott


From jgstewart at gmail.com  Sat Apr 13 03:57:33 2013
From: jgstewart at gmail.com (Greg Stewart)
Date: Fri, 12 Apr 2013 23:57:33 -0400
Subject: [ PRIVACY Forum ] Huge attack on WordPress sites could spawn
 never-before-seen super botnet
In-Reply-To: <9063421.2055.1365822171886.JavaMail.root@benjamin.baylink.com>
References: <20130413013121.GB9298@vortex.com>
 <9063421.2055.1365822171886.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAETzoH673jPBttU3JHA_2_nz=NCqBJFoAAcJpjP_ze=Qbd8f3w@mail.gmail.com>

The WordPress mailing lists have been rather active discussing it.

A couple of hardening tips if you're running WP, or run a host providing it:

http://ma.tt/2013/04/passwords-and-brute-force/
http://codex.wordpress.org/Brute_Force_Attacks



On Fri, Apr 12, 2013 at 11:02 PM, Jay Ashworth <jra at baylink.com> wrote:

> FYI.  Am I the only person just hearing about this?
>
> ----- Forwarded Message -----
> > From: "PRIVACY Forum mailing list" <privacy at vortex.com>
>
> > Huge attack on WordPress sites could spawn never-before-seen super
> > botnet
> >
> > http://j.mp/ZRZksL (ars technica)
> >
> > "The unknown people behind the highly distributed attack are using
> > more
> > than 90,000 IP addresses to brute-force crack administrative
> > credentials of vulnerable WordPress systems, researchers from at least
> > three Web hosting services reported. At least one company warned that
> > the attackers may be in the process of building a "botnet" of infected
> > computers that's vastly stronger and more destructive than those
> > available today. That's because the servers have bandwidth connections
> > that that are typically tens, hundreds, or even thousands of times
> > faster than botnets made of infected machines in homes and small
> > businesses."
> >
> > - - -
> >
> > Up in the Net! It's a bug! It's a phish! It's SUPER-botnet!
> >
> > --Lauren--
> > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren
> > Co-Founder: People For Internet Responsibility:
> > http://www.pfir.org/pfir-info
> > Founder:
> > - Network Neutrality Squad: http://www.nnsquad.org
> > - PRIVACY Forum: http://www.vortex.com/privacy-info
> > - Data Wisdom Explorers League: http://www.dwel.org
> > - Global Coalition for Transparent Internet Performance:
> > http://www.gctip.org
> > Member: ACM Committee on Computers and Public Policy
> > Lauren's Blog: http://lauren.vortex.com
> > Google+: http://vortex.com/g+lauren / Twitter:
> > http://vortex.com/t-lauren
> > Tel: +1 (818) 225-2800 / Skype: vortex.com
> >
> > _______________________________________________
> > privacy mailing list
> > http://lists.vortex.com/mailman/listinfo/privacy
>
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA               #natog                      +1 727 647
> 1274
>
>

From dougb at dougbarton.us  Sat Apr 13 04:29:42 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 12 Apr 2013 21:29:42 -0700
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <20130412161049.D651F7AA@resin11.mta.everyone.net>
References: <20130412161049.D651F7AA@resin11.mta.everyone.net>
Message-ID: <5168DF36.9030003@dougbarton.us>

On 04/12/2013 04:10 PM, Scott Weeks wrote:
>
> On 4/11/13, Oliver Garraux <oliver at g.garraux.net> wrote:
>
>> The whole custom TLD thing is just a truly awful, awful idea.
> --------------------------------------------------
>
> --------- mysidia at gmail.com wrote: -------------------
> From: Jimmy Hess <mysidia at gmail.com>
>
> Agreed;  but it would seem that unstoppable forces have been set into
> motion by ICANN, to cause it to happen, regardless of whether it is
> beneficial to the community, and regardless of any objections from the
> public...
> ----------------------------------------------
>
>
> I believe that unstoppable force is called the want of money.

The ICANN board, and to some extent the staff, rather vigorously opposed 
the further expansion of the TLD space after what can only charitably be 
described as the modest success of the 2000 round names (of which INFO 
was the only standout of the seven, and the only one which continues to 
hold its own).

However, the pressure from the community was overwhelming to open up the 
process again, and continued unabated from a time even before the 2000 
round was closed. Whatever criticisms you can lay at the feet of ICANN, 
especially in recent years, "greed for new TLDs" is not one of them.

Disclaimer, I followed the ICANN process closely from the beginning, and 
was a founding member of the SSAC from 2001 until I joined the staff in 
2003. I left the ICANN staff in 2005, but remain deeply interested in 
what it does, and how it does it.

Doug



From surfer at mauigateway.com  Sat Apr 13 06:28:20 2013
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 12 Apr 2013 23:28:20 -0700
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
Message-ID: <20130412232820.D651835A@resin11.mta.everyone.net>



--------------------------------------------
> I believe that unstoppable force is called the want of money.

However, the pressure from the community was overwhelming to open up the 
process again, and continued unabated from a time even before the 2000 
round was closed. Whatever criticisms you can lay at the feet of ICANN, 
especially in recent years, "greed for new TLDs" is not one of them.

Disclaimer, I followed the ICANN process closely from the beginning, and 
was a founding member of the SSAC from 2001 until I joined the staff in 
2003. I left the ICANN staff in 2005, but remain deeply interested in 
what it does, and how it does it.
----------------------------------------------


Ok, I'll take some of that back as I have not followed it as closely as 
I should to make a statement like that.  And I'm not looking to troll
because I'm as tired of that as anyone here.  I need to find out what 
community it was you speak of that produced the overwhelming pressure.  
Why I said it:

http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf

The gTLD evaluation fee is required from all applicants. This fee is in 
the amount of USD 185,000"

"The fee for a three-member RSTEP review team is anticipated to be USD 
50,000."  

"adjudication fees for a proceeding involving a fixed amount could range 
from USD 2,000 to USD 8,000 (or more) per proceeding. ICANN further 
estimates that an hourly rate based proceeding with a one-member panel 
could range from USD 32,000 to USD 56,000 (or more) and with a three-member 
panel it could range from USD 70,000 to USD 122,000 (or more)."

etc.

Seems a lot to someone like me.  Hopefully my explanation won't light 
flame throwers.  I just want to explain my statement.

scott


From angst1974 at yahoo.com  Sat Apr 13 12:39:49 2013
From: angst1974 at yahoo.com (Steve)
Date: Sat, 13 Apr 2013 08:39:49 -0400
Subject: Fwd: [ PRIVACY Forum ] Huge attack on WordPress sites
In-Reply-To: <mailman.1.1365854400.27611.nanog@nanog.org>
References: <mailman.1.1365854400.27611.nanog@nanog.org>
Message-ID: <F853CF46-2756-45B7-BE38-41426C64C7A3@yahoo.com>

This is pretty old news , this "super bot-net" of compromised Wordpress sites ( and others) has been attacking since September 

Sent from my iPhone

ONANOG Digest, 
> *************************************


From eaptech at gmail.com  Sun Apr 14 16:26:36 2013
From: eaptech at gmail.com (Eric Adler)
Date: Sun, 14 Apr 2013 12:26:36 -0400
Subject: Why are there no GeoDNS solutions anywhere in sight?
In-Reply-To: <CAPKkNb63hqpT4CLcQ-TiMfYZtrqqT=1TRouKkQGn-QwdHCJO3g@mail.gmail.com>
References: <CAPKkNb63hqpT4CLcQ-TiMfYZtrqqT=1TRouKkQGn-QwdHCJO3g@mail.gmail.com>
Message-ID: <CAMdF1xWEJ=NvvfjQmKMcBoRgOcjDWgLftvr875x8QVKmQuQJAg@mail.gmail.com>

If this is for http and similar user-accessed (not machine accessed)
traffic, you could do what some large manufacturers and shipping companies
do: Provide a (relatively) low-bandwidth "Select where you are in the
world" global landing page which then redirects to a different
domain/subdomain for each region.  This also lets them direct relatively
localized content easily. For example, panasonic.com can list items sold
mass-market for the US, panasonic.nl for the Netherlands, and
panasonic.com.au for Australia.  Yes, you may well run into times that a
user in the US goes to the .au site because s/he wants to research an .au
product that isn't detailed on the US page but this is not the bulk of your
traffic (and, if through stats, you find it becomes so, you can work on
your design so that it isn't).

- Eric


On Wed, Mar 20, 2013 at 11:28 PM, Constantine A. Murenin <mureninc at gmail.com
> wrote:

> Dear NANOG@,
>
> Not every operator has the ability to setup their own anycast.
>
> Not every operator is big enough to be paying 25 USD/month for a
> managed GeoDNS solution, just to get their hands on GeoDNS.  (Hey, for
> 25$/mo, I might as well have an extra POP or two!)
>
> Why so many years after the concept has been introduced and has been
> found useful, can one not setup GeoDNS in under 5 minutes on one's own
> infrastructure, or use GeoDNS from any of the plentiful free or
> complementary DNS solutions that are offered by providers like he.net,
> xname.org, linode.com and others?
>
> I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the
> easiest (and only) solution I see right now is, on both servers,
> running two copies of `nsd` on distinct sockets, and redirecting
> incoming DNS traffic through a firewall based on IPv4 /8 address
> allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files
> with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the
> rest of /8 allocations -- an `A` record for NA), with zone replication
> managed through git.  Yeap, it's rough, and quite ugly, and
> unmaintainable, and will give optimal results only in 80 to 95 per
> cent of actual cases, and will not benefit from the extra webapp
> redundancy one otherwise might have had, but what other alternatives
> could be configured in 5 or 15 minutes?
>
> Any plans to make DNS itself GeoDNS-friendly?
>
> When editing a zone file in `emacs`, why can one not say that one has
> 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure
> and/or the web-browser figure out the rest?
>
> Why even stop there:  all modern browsers usually know the exact
> location of the user, often with street-level accuracy.  It should be
> possible to say that you have a server in Fremont, CA and Toronto, ON
> or Beauharnois, QC, and automatically have all East Coast users go to
> Toronto, and West Coast to Fremont.  Why is there no way to do any of
> this?
>
> Cheers,
> Constantine.
>
>

From mysidia at gmail.com  Sun Apr 14 22:07:10 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 14 Apr 2013 17:07:10 -0500
Subject: Why are there no GeoDNS solutions anywhere in sight?
In-Reply-To: <CAPKkNb6icYwWeXGZM=L_xpp-0hxO2aowzLB_xsRV5AhhKKB0wg@mail.gmail.com>
References: <CAPKkNb63hqpT4CLcQ-TiMfYZtrqqT=1TRouKkQGn-QwdHCJO3g@mail.gmail.com>
 <20130321034350.GB1143@dyn.com>
 <CAPKkNb6icYwWeXGZM=L_xpp-0hxO2aowzLB_xsRV5AhhKKB0wg@mail.gmail.com>
Message-ID: <CAAAwwbWaPs_7usjnJ4Qvo27hnzTDb87NnTSTFu-OyZ6nEJu7gg@mail.gmail.com>

On 3/21/13, Constantine A. Murenin <mureninc at gmail.com> wrote:
> Does it sound too complicated and pointy?  Yes, it's not exactly
> trivial, and not as good as BGP, but better than having 300ms latency
> from a simple round-robin.

It sounds like you are asking about Geolocation, when what you really
want is latency-based selection.  Latency is more complicated, and
influenced by factors other than purely Geographic location.
Furthermore,  distance  doesn't work all that well as a measure of
latency:  it only defines the latency, in the best case scenario for a
link between the geo locations.

Why not just have the browser send a SYN packet to every IP  in the
A/AAAA   RRSET?

Whichever webserver's response to the connection handshake is received
first wins (lowest RTT latency);  the other two or three connections
are  just dropped,  so there is some minor waste,  in exchange  for
picking the lowest RTT destination.



Now another alternative would be for the local network operator to
offer some sort of  "latency lookup service";

Based on implementing packet inspection,  and gathering statistical
information RTT and average throughput and retransmit rates
experienced during  network users' TCP handshakes to remote prefixes,
aggregated at an AS level.

So the browser could query  the latency lookup service  for the
hostname,   and receive a DNS reply  annotated  with an estimated
historical average latency, drop rate, throughput for  the IP prefix
inquired about.

Or in fact... have the lookup service re-order or filter the query
result,  so the responses with higher than a certain cutoff latency
are placed last in the response,  or filtered/deleted from the
response,  when there are at least 3 better choices.


> C.
--
-JH


From berni at birkenwald.de  Sun Apr 14 22:09:59 2013
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Sun, 14 Apr 2013 22:09:59 +0000 (UTC)
Subject: Contact for BGP at nic.mil (AS721 AS27064)
Message-ID: <kkf9fn$gb1$1@ger.gmane.org>

Hello,

if someone from nic.mil (AS721 and/or AS27064) is present please contact
me off-list. I have a persistent routing issue from your network to one
of my prefixes at AS29259 that I can't get cleared, even by bouncing the
prefix. whois-contact (hostmaster at nic.mil) did not answer.

Thanks,
Bernhard



From lists at tigertech.com  Mon Apr 15 06:19:47 2013
From: lists at tigertech.com (Robert L Mathews)
Date: Sun, 14 Apr 2013 23:19:47 -0700
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <5168DF36.9030003@dougbarton.us>
References: <20130412161049.D651F7AA@resin11.mta.everyone.net>
 <5168DF36.9030003@dougbarton.us>
Message-ID: <516B9C03.1000801@tigertech.com>

On 4/12/13 9:29 PM, Doug Barton wrote:

> Whatever criticisms you can lay at the feet of ICANN,
> especially in recent years, "greed for new TLDs" is not one of them.

Hmmm. Many people would disagree with that, based on episodes like this:

 http://domainincite.com/5212-calls-to-fix-new-gtld-revolving-door-at-icann

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/


From damian at google.com  Mon Apr 15 11:16:36 2013
From: damian at google.com (Damian Menscher)
Date: Mon, 15 Apr 2013 04:16:36 -0700
Subject: [ PRIVACY Forum ] Huge attack on WordPress sites
In-Reply-To: <F853CF46-2756-45B7-BE38-41426C64C7A3@yahoo.com>
References: <mailman.1.1365854400.27611.nanog@nanog.org>
 <F853CF46-2756-45B7-BE38-41426C64C7A3@yahoo.com>
Message-ID: <CABSP1OevC5bXUeCa6yVK47pLXEGBGW5xgQL=TpDOXMYKZ1TKDQ@mail.gmail.com>

FYI, the "new" part of this news is that the current botnet is 10x larger
than the one you're thinking of.

Damian


On Sat, Apr 13, 2013 at 5:39 AM, Steve <angst1974 at yahoo.com> wrote:

> This is pretty old news , this "super bot-net" of compromised Wordpress
> sites ( and others) has been attacking since September
>
> Sent from my iPhone
>
> ONANOG Digest,
> > *************************************
>
>

From oscar.vives at gmail.com  Mon Apr 15 11:58:34 2013
From: oscar.vives at gmail.com ( .)
Date: Mon, 15 Apr 2013 13:58:34 +0200
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <516B9C03.1000801@tigertech.com>
References: <20130412161049.D651F7AA@resin11.mta.everyone.net>
 <5168DF36.9030003@dougbarton.us> <516B9C03.1000801@tigertech.com>
Message-ID: <CACg3zYGb=g28dB--f2AjJTPYUr+fh1gAi3UGEzCFF5HDEpiBAw@mail.gmail.com>

The Internet already have a problem with "one of everything" where a single
provider is much more popular than the other ones. Amazon, Google,  Reddit,
Wikipedia...    The 2th cooperative encyclopedia editing website is much
less popular than Wikipedia.

This is not a good thing, is a bad thing since we are at the infancy of
everything, there are a million things to try, learn, invent and explore.
The average user visit the same 4 websites again and again every day..  not
knowing the next door has something cool to offer, and really need
visitors.

What is the problem that people is trying to solve here? is this the
correct place to solve it?,  If is a usability problem in the browser,
maybe the solution is more how browsers are build and how to function.
Maybe browsers creators need to be more creative!.  Maybe the current
browser implementation and UI standards are shit.
Do we need a internet-wide solution?,  maybe just making the protocol
"search://"  redirect to a default search engine passing the term will
solve the same problem (   search://tabacco  =>
http://www.google.com/?q=tabacco )




-- 
--
?in del ?ensaje.

From johnl at iecc.com  Mon Apr 15 13:10:17 2013
From: johnl at iecc.com (John Levine)
Date: 15 Apr 2013 13:10:17 -0000
Subject: What do people use public suffix for?
Message-ID: <20130415131017.9047.qmail@joyce.lan>

The public suffix list contains points in the DNS where (roughly
speaking) names below that point are under different management from
each other and from that name.  It's here: http://publicsuffix.org/

The idea is that abc.foo.com and xyz.foo.com have the same management,
but abc.co.uk and xyz.co.uk do not.

You don't have to tell me that it's a gross crock, but it seems to
be a useful one.  What do people use it for?  Here's what I know of:

* Web browsers use it to manage cookies to keep a site from putting
cookies that will affect other sites, e.g. abc.foo.co.uk can set a
cookie for foo.co.uk but not for co.uk.

* DMARC (www.dmarc.org) uses it to find a policy record in the DNS
that describes a subtree, e.g., if you get mail that purports to be
from eBay at reply1.ebay.com it checks the policy at ebay.com.

What other current applications are there?

R's,
John

PS: Really, you don't have to tell me what a crock it is.


From matthias at leisi.net  Mon Apr 15 13:55:43 2013
From: matthias at leisi.net (Matthias Leisi)
Date: Mon, 15 Apr 2013 15:55:43 +0200
Subject: What do people use public suffix for?
In-Reply-To: <20130415131017.9047.qmail@joyce.lan>
References: <20130415131017.9047.qmail@joyce.lan>
Message-ID: <CALgnk9o2AaoxJDUti4TN_T67FQvB=0Z2XUGiCe3tbMxVewxWiw@mail.gmail.com>

On Mon, Apr 15, 2013 at 3:10 PM, John Levine <johnl at iecc.com> wrote:


> You don't have to tell me that it's a gross crock, but it seems to
> be a useful one.  What do people use it for?  Here's what I know of:
>

At dnswl.org, we use a heuristic (and manual checks) to derive different
"levels" of management (ie, foo.example.org may or may not be under the
same operational responsibility as bar.example.org). Using
publicsuffix.orgdata would allow us to automate some of that work (I
just have not yet got
around to implement it).

--  Matthias

From dhubbard at dino.hostasaurus.com  Mon Apr 15 14:29:03 2013
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Mon, 15 Apr 2013 10:29:03 -0400
Subject: [ PRIVACY Forum ] Huge attack on WordPress sites
References: <mailman.1.1365854400.27611.nanog@nanog.org>
 <F853CF46-2756-45B7-BE38-41426C64C7A3@yahoo.com>
 <CABSP1OevC5bXUeCa6yVK47pLXEGBGW5xgQL=TpDOXMYKZ1TKDQ@mail.gmail.com>
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0F3CB@dino.ad.hostasaurus.com>

apache's mod_security comes in pretty handy for reducing the
cpu load caused by these attacks; we've seen many sites we
host getting hammered on the wp-login.php page from these
bots.

Here's the rules that block the bad requests:

https://docs.google.com/document/d/1wCpp7U5uOw_krEkQrm9NXFf2LjpGvlZ7uoOK
0Ok4LGM/pub

David 

> -----Original Message-----
> From: Damian Menscher [mailto:damian at google.com] 
> Sent: Monday, April 15, 2013 7:17 AM
> To: Steve
> Cc: nanog at nanog.org
> Subject: Re: [ PRIVACY Forum ] Huge attack on WordPress sites
> 
> FYI, the "new" part of this news is that the current botnet 
> is 10x larger
> than the one you're thinking of.
> 
> Damian
> 
> 
> On Sat, Apr 13, 2013 at 5:39 AM, Steve <angst1974 at yahoo.com> wrote:
> 
> > This is pretty old news , this "super bot-net" of 
> compromised Wordpress
> > sites ( and others) has been attacking since September
> >
> > Sent from my iPhone
> >
> > ONANOG Digest,
> > > *************************************
> >
> >
> 
> 


From Derek.Andrew at usask.ca  Mon Apr 15 15:10:27 2013
From: Derek.Andrew at usask.ca (Derek Andrew)
Date: Mon, 15 Apr 2013 09:10:27 -0600
Subject: What do people use public suffix for?
In-Reply-To: <a9b3891e7c874a5e9b6e0c91eee34b55@CAMPUSCAS3.usask.ca>
References: <20130415131017.9047.qmail@joyce.lan>
 <a9b3891e7c874a5e9b6e0c91eee34b55@CAMPUSCAS3.usask.ca>
Message-ID: <CAAf7UokQzpU-L4CTBbpcqtRQp1f4_h_zc36HA_TGi1uS1ty6Uw@mail.gmail.com>

dnswl.org should look at publicsuffix.org to correct errors.


On Mon, Apr 15, 2013 at 7:55 AM, Matthias Leisi <matthias at leisi.net> wrote:

> On Mon, Apr 15, 2013 at 3:10 PM, John Levine <johnl at iecc.com> wrote:
>
>
> > You don't have to tell me that it's a gross crock, but it seems to
> > be a useful one.  What do people use it for?  Here's what I know of:
> >
>
> At dnswl.org, we use a heuristic (and manual checks) to derive different
> "levels" of management (ie, foo.example.org may or may not be under the
> same operational responsibility as bar.example.org). Using
> publicsuffix.orgdata would allow us to automate some of that work (I
> just have not yet got
> around to implement it).
>
> --  Matthias
>



-- 
Copyright 2013 Derek Andrew (excluding quotations)

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

Typed but not read.

From jra at baylink.com  Mon Apr 15 16:00:23 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 15 Apr 2013 12:00:23 -0400 (EDT)
Subject: What do people use public suffix for?
In-Reply-To: <20130415131017.9047.qmail@joyce.lan>
Message-ID: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "John Levine" <johnl at iecc.com>

> The public suffix list contains points in the DNS where (roughly
> speaking) names below that point are under different management from
> each other and from that name. It's here: http://publicsuffix.org/
> 
> The idea is that abc.foo.com and xyz.foo.com have the same management,
> but abc.co.uk and xyz.co.uk do not.
> 
> You don't have to tell me that it's a gross crock, but it seems to
> be a useful one. What do people use it for? Here's what I know of:
> 
> * Web browsers use it to manage cookies to keep a site from putting
> cookies that will affect other sites, e.g. abc.foo.co.uk can set a
> cookie for foo.co.uk but not for co.uk.
> 
> * DMARC (www.dmarc.org) uses it to find a policy record in the DNS
> that describes a subtree, e.g., if you get mail that purports to be
> from eBay at reply1.ebay.com it checks the policy at ebay.com.
> 
> What other current applications are there?

Seems to me that it's a crock because *it should be in the DNS*.

I should be able to retrieve the AS (administrative split) record 
for .co.uk, and there should be one that says, "yup, there's an
administrative split below me; nothing under there is mine unless 
you also get an exception record for a subdomain".

The people who know authoritatively that their subdomains are within
someone else's administrative span of control *are the people who own
those domains*.

No?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From jra at baylink.com  Mon Apr 15 16:03:58 2013
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 15 Apr 2013 12:03:58 -0400 (EDT)
Subject: Google Wants to Create a Dotless Domain Called "Search"..?
In-Reply-To: <CACg3zYGb=g28dB--f2AjJTPYUr+fh1gAi3UGEzCFF5HDEpiBAw@mail.gmail.com>
Message-ID: <27957502.2277.1366041838764.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "." <oscar.vives at gmail.com>

> What is the problem that people is trying to solve here? is this the
> correct place to solve it?

Wow; really?

The problem is "Google isn't *quite* a monopoly, yet, and we'd like to be, 
even though that's evil".

And the answer is "no, it's not".

In general: no, no one should be allowed to operate a registry for a 
public domain for "internal" use, and no one should be allowed to put an A
record on a one-element gTLD.

Cheers,
-- jr 'what, me? opinionated?' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From jabley at hopcount.ca  Mon Apr 15 16:30:59 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 15 Apr 2013 12:30:59 -0400
Subject: What do people use public suffix for?
In-Reply-To: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
Message-ID: <36448A77-92D1-49D8-816B-E5A969C68E0D@hopcount.ca>


On 2013-04-15, at 12:00, Jay Ashworth <jra at baylink.com> wrote:

> Seems to me that it's a crock because *it should be in the DNS*.
> 
> I should be able to retrieve the AS (administrative split) record 
> for .co.uk, and there should be one that says, "yup, there's an
> administrative split below me; nothing under there is mine unless 
> you also get an exception record for a subdomain".

I've always quite liked that idea (if we accept for the point of discussion that there are use-cases like cookie naming that make identifying this kind of boundary useful).

There's a concern though that there are multiple ways to spoof such a DNS response, and do so in a distributed fashion that might not be easy to detect by an individual client application. If the AS (or whatever) record was signed, that would make things better. But only if you could rely upon clients to validate those responses (or have a sufficiently clean DNS path out that validation was even possible).

There's also the question of what to do with a TLD (or other part of the namespace) that doesn't include this record. Some of the zones we're talking about are generated by registry machinery with long software development lifecycles.

If your starting point is (a) the records might not be there, (b) we might not be able to find them even if they are there, and (c) if we get them we can't always be sure they are genuine, then the natural conclusion is that you can't rely on the mechanism to work and you look for another answer.

If you need the mechanism to work (say you're say a browser vendor who is going to get heat if cookie-leakage causes widespread privacy violations) then I can see why fetching and caching a browser list over SSL (and perhaps shipping with a baseline version of it) seems attractive.

And that I guess takes us back to where we are.


Joe



From morrowc.lists at gmail.com  Mon Apr 15 17:27:20 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 15 Apr 2013 13:27:20 -0400
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CAFwKRnSFB+X+e2jO8pExsCFsB8Mnxzz9eO3+V_V=Amy2_KjcPw@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
 <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
 <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>
 <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>
 <CAFwKRnSFB+X+e2jO8pExsCFsB8Mnxzz9eO3+V_V=Amy2_KjcPw@mail.gmail.com>
Message-ID: <CAL9jLaayt0R1zFURWFacwne5_ke_K164Gj3NcgV_kHEZnjNcxA@mail.gmail.com>

On Fri, Apr 12, 2013 at 11:37 PM, Yang Yu <yang.yu.list at gmail.com> wrote:

> DNS is actually working correctly I think.
> 1) The outputs are from Dreamhost Ashburn, but I saw the same result
> over IPv6 at Dreamhost LAX. Different DNS servers.
>

over ipv6 there might not be enough distinction between locations ...


> 2) ping and ping6 times are pretty much the same. I suppose they are
> served by the same Google cluster/CDN.
> 3) No redirect over IPv4
>
>
ok, so today I'm not seeing a redirect happening... want to try again?
maybe things got worked out? or my testing tool is busted :)

From drc at virtualized.org  Mon Apr 15 18:13:58 2013
From: drc at virtualized.org (David Conrad)
Date: Mon, 15 Apr 2013 11:13:58 -0700
Subject: What do people use public suffix for?
In-Reply-To: <36448A77-92D1-49D8-816B-E5A969C68E0D@hopcount.ca>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <36448A77-92D1-49D8-816B-E5A969C68E0D@hopcount.ca>
Message-ID: <9FAA3086-FA76-417E-B280-A121ECB184CF@virtualized.org>

On Apr 15, 2013, at 9:30 AM, Joe Abley <jabley at hopcount.ca> wrote:
> [...]
> If you need the mechanism to work (...) then I can see why fetching and caching a browser list over SSL (and perhaps shipping with a baseline version of it) seems attractive.

Sounds like this could've been good logic for the use of HOSTS.TXT :)

Regards,
-drc



From yang.yu.list at gmail.com  Mon Apr 15 20:24:15 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Mon, 15 Apr 2013 16:24:15 -0400
Subject: Google incorrect IPv6 GeoIP
In-Reply-To: <CAL9jLaayt0R1zFURWFacwne5_ke_K164Gj3NcgV_kHEZnjNcxA@mail.gmail.com>
References: <CAFwKRnRT58LFsH=ypSYBoHbL_KgHFv_s24HGFR8Zs0iDxmWKUw@mail.gmail.com>
 <CAEabp552w7PW7KdiTHOCyxBQJzgHm_U+ugApwCwPWzA09ZrhNQ@mail.gmail.com>
 <CAD6AjGS0a3-9v7wANhmDUJ3N3F4UrT0y3sfL0EOhKL_Ay1-DWA@mail.gmail.com>
 <CAL9jLabvpg=91DxGYqQMf95BGEYinDF8-YywPTgMxU3MFcBO=A@mail.gmail.com>
 <CACnPsNWCTZi1_GXMeyKeQtfea-9a4Kq1y=nuutrNi55Vh91pjQ@mail.gmail.com>
 <CAFwKRnSFB+X+e2jO8pExsCFsB8Mnxzz9eO3+V_V=Amy2_KjcPw@mail.gmail.com>
 <CAL9jLaayt0R1zFURWFacwne5_ke_K164Gj3NcgV_kHEZnjNcxA@mail.gmail.com>
Message-ID: <CAFwKRnTWxMVakTkLe2qTnTX7jp8=FuLzJr20e+Cte7x2VmRA=A@mail.gmail.com>

Still getting redirected

Resolving www.google.com... 2607:f8b0:400c:c04::69, 74.125.26.104,
74.125.26.99, ...
Connecting to www.google.com|2607:f8b0:400c:c04::69|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1366057169806151&usg=AFQjCNEQcW1Bg7ROZRYzpFJC-f99YXGF8Q
[following]
--2013-04-15 13:18:59--
http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1366057169806151&usg=AFQjCNEQcW1Bg7ROZRYzpFJC-f99YXGF8Q
Resolving www.google.com.hk... 2607:f8b0:400c:c04::69, 74.125.26.103,
74.125.26.106, ...


From johnl at iecc.com  Mon Apr 15 22:16:55 2013
From: johnl at iecc.com (John R. Levine)
Date: 16 Apr 2013 00:16:55 +0200
Subject: What do people use public suffix for?
In-Reply-To: <m24nf7sckn.fsf@localhost.localdomain>
References: <20130415131017.9047.qmail@joyce.lan>
 <m24nf7sckn.fsf@localhost.localdomain>
Message-ID: <alpine.BSF.2.00.1304160016310.4257@joyce.lan>

> They'd really like to have a process which is less ad-hoc.  For
> example, it'd be great if these points were annotated in the DNS
> itself, perhaps with a record which points to the corresponding
> whois server.

I've been thinking about a way to do that, but I want to understand the 
use cases first.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2500 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130416/718db507/attachment.bin>

From geoffk at geoffk.org  Mon Apr 15 21:34:16 2013
From: geoffk at geoffk.org (Geoffrey Keating)
Date: 15 Apr 2013 14:34:16 -0700
Subject: What do people use public suffix for?
In-Reply-To: <20130415131017.9047.qmail@joyce.lan>
References: <20130415131017.9047.qmail@joyce.lan>
Message-ID: <m24nf7sckn.fsf@localhost.localdomain>

"John Levine" <johnl at iecc.com> writes:

> The public suffix list contains points in the DNS where (roughly
> speaking) names below that point are under different management from
> each other and from that name.  It's here: http://publicsuffix.org/
> 
> The idea is that abc.foo.com and xyz.foo.com have the same management,
> but abc.co.uk and xyz.co.uk do not.
> 
> You don't have to tell me that it's a gross crock, but it seems to
> be a useful one.  What do people use it for?
...

CAs use it as part of a procedure to determine whether it's safe to
issue a wildcard domain (as in, if it's on the list, it's not safe).  See
<https://www.cabforum.org/Baseline_Requirements_V1_1_3.pdf>, section 11.1.3.

They'd really like to have a process which is less ad-hoc.  For
example, it'd be great if these points were annotated in the DNS
itself, perhaps with a record which points to the corresponding
whois server.


From ristic.sasa at gmail.com  Mon Apr 15 22:57:46 2013
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Tue, 16 Apr 2013 00:57:46 +0200
Subject: IPv6 6rd BR setup on Linux
Message-ID: <CAPVpXLz-ZAHJ-vzbNpASPN2grKCF1_TAMK+kJQMWNDywU3wypQ@mail.gmail.com>

hello all,

can someone please share any info regarding a ipv6 6rd BR setup on linux
(debian specific preferably)... goo.gl search didn't turn up much...

thanks!



-- 
Pozdrav,--
Sasa Ristic
Department for network
Senior network administrator


VeratNet
37 Vojvode Misica Boulevard, Belgrade, Serbia

From johnlacour at gmail.com  Tue Apr 16 01:16:53 2013
From: johnlacour at gmail.com (John LaCour)
Date: Mon, 15 Apr 2013 21:16:53 -0400
Subject: DNS issue with regions.com
Message-ID: <CAEsOGDpGHZv=94UbFP5qG_Ztm6FY+xLwx4DkSngmROGai4Ds8A@mail.gmail.com>

Folks,

Regions Bank, a large US bank, had a DNS issue today.    As a result,
some RRs ended up pointing at the wrong place with 48 hour TTLs and
customers can't access online banking.

If you manage caching nameserver infrastructure for consumer or
business Internet users, the bank would be grateful if you could flush
any records associated with regions.com.

If you want to check for problems, you should see www.regions.com
point to a v4 address in the 205.255.0.0/16 space.

Thanks in advance for any help.
John

N.B.    I am not a Regions employee, but have been asked to help.


From shtsuchi at cisco.com  Tue Apr 16 01:44:54 2013
From: shtsuchi at cisco.com (Shishio Tsuchiya)
Date: Tue, 16 Apr 2013 10:44:54 +0900
Subject: IPv6 6rd BR setup on Linux
In-Reply-To: <CAPVpXLz-ZAHJ-vzbNpASPN2grKCF1_TAMK+kJQMWNDywU3wypQ@mail.gmail.com>
References: <CAPVpXLz-ZAHJ-vzbNpASPN2grKCF1_TAMK+kJQMWNDywU3wypQ@mail.gmail.com>
Message-ID: <516CAD16.7010602@cisco.com>

Sasa
Sakura internet,datacentor provider of JAPAN,is providing 6rd BR(ASR1K),IPv6 internet and 6rd configuration information for their customer.
We published the information as informational draft.
Debian 6.0's linux kernel is 2.6.32.So you might need upgrade kernel.
Basically information is 6rd CE configuration for host,but I think this would be useful for you.
http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04#appendix-A.1.2.3
http://research.sakura.ad.jp/6rd-trial/6rd-trial-debian60/
(Japanese)

Regards,
-Shishio

(2013/04/16 7:57), Sasa Ristic wrote:
> hello all,
> 
> can someone please share any info regarding a ipv6 6rd BR setup on linux
> (debian specific preferably)... goo.gl search didn't turn up much...
> 
> thanks!
> 
> 
> 




From steve.bertrand at amayagaming.com  Tue Apr 16 03:46:41 2013
From: steve.bertrand at amayagaming.com (Steve Bertrand)
Date: Tue, 16 Apr 2013 03:46:41 +0000
Subject: ScopServ questions
Message-ID: <780A28F50E2834489278DD3B512FE7163ECBA0@CAQCCOHVEX01.corp.amayagaming.com>

Hi all,

This isn't a NANOG problem, but I'm out of my league on this and am wondering if anyone can contact me off-list or point me in a direction if they can help me resolve an expensive exploit against a branch office asterisk box.

Thanks,

Steve

--
Steve Bertrand
AMAYA?| Senior Network & Systems Admin
Direct Line: +1 403 537-9627
Mobile:      +1 403 831-4611
Skype:       stevie.bertrand

Twitter - Facebook - LinkedIn - YouTube
www.amayagaming.com



From eyeronic.design at gmail.com  Tue Apr 16 05:32:50 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Mon, 15 Apr 2013 22:32:50 -0700
Subject: ScopServ questions
In-Reply-To: <780A28F50E2834489278DD3B512FE7163ECBA0@CAQCCOHVEX01.corp.amayagaming.com>
References: <780A28F50E2834489278DD3B512FE7163ECBA0@CAQCCOHVEX01.corp.amayagaming.com>
Message-ID: <CAN3um4wpyQhqUE-ERFA76cDQTf+qhXJ6GVkGEkg4UySKYrj6-A@mail.gmail.com>

If you're looking to hire someone to fix your asterisk install, your
best bet would be the Asterisk User or Asterisk Business list.

http://www.asterisk.org/community/discuss

If this is an 0-day type scenario, you'd probably want to reach out to
Digium directly.

Can you expand a bit more on the details?

On Mon, Apr 15, 2013 at 8:46 PM, Steve Bertrand
<steve.bertrand at amayagaming.com> wrote:
> Hi all,
>
> This isn't a NANOG problem, but I'm out of my league on this and am wondering if anyone can contact me off-list or point me in a direction if they can help me resolve an expensive exploit against a branch office asterisk box.
>
> Thanks,
>
> Steve
>
> --
> Steve Bertrand
> AMAYA | Senior Network & Systems Admin
> Direct Line: +1 403 537-9627
> Mobile:      +1 403 831-4611
> Skype:       stevie.bertrand
>
> Twitter - Facebook - LinkedIn - YouTube
> www.amayagaming.com
>
>



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


From ristic.sasa at gmail.com  Tue Apr 16 07:33:55 2013
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Tue, 16 Apr 2013 09:33:55 +0200
Subject: IPv6 6rd BR setup on Linux
In-Reply-To: <516CAD16.7010602@cisco.com>
References: <CAPVpXLz-ZAHJ-vzbNpASPN2grKCF1_TAMK+kJQMWNDywU3wypQ@mail.gmail.com>
 <516CAD16.7010602@cisco.com>
Message-ID: <CAPVpXLyRedrb=SWTnmDdMq1GQUJhweDmpZMiEZ_rnnbnuc7_tA@mail.gmail.com>

OK, I found this information too, but, if I'm not mistaken, this is all
regarding 6rd "client" setup on *nix, while the BR is on Cisco ASR1K.
I'm trying to setup BR on (any kind) Linux, but either there is no
possibility or information on this topic, or I'm unable to find it.


On Tue, Apr 16, 2013 at 3:44 AM, Shishio Tsuchiya <shtsuchi at cisco.com>wrote:

> Sasa
> Sakura internet,datacentor provider of JAPAN,is providing 6rd
> BR(ASR1K),IPv6 internet and 6rd configuration information for their
> customer.
> We published the information as informational draft.
> Debian 6.0's linux kernel is 2.6.32.So you might need upgrade kernel.
> Basically information is 6rd CE configuration for host,but I think this
> would be useful for you.
> http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04#appendix-A.1.2.3
> http://research.sakura.ad.jp/6rd-trial/6rd-trial-debian60/
> (Japanese)
>
> Regards,
> -Shishio
>
> (2013/04/16 7:57), Sasa Ristic wrote:
> > hello all,
> >
> > can someone please share any info regarding a ipv6 6rd BR setup on linux
> > (debian specific preferably)... goo.gl search didn't turn up much...
> >
> > thanks!
> >
> >
> >
>
>
>
>


-- 
ricky

From shtsuchi at cisco.com  Tue Apr 16 09:23:49 2013
From: shtsuchi at cisco.com (Shishio Tsuchiya)
Date: Tue, 16 Apr 2013 18:23:49 +0900
Subject: IPv6 6rd BR setup on Linux
In-Reply-To: <CAPVpXLyRedrb=SWTnmDdMq1GQUJhweDmpZMiEZ_rnnbnuc7_tA@mail.gmail.com>
References: <CAPVpXLz-ZAHJ-vzbNpASPN2grKCF1_TAMK+kJQMWNDywU3wypQ@mail.gmail.com>
 <516CAD16.7010602@cisco.com>
 <CAPVpXLyRedrb=SWTnmDdMq1GQUJhweDmpZMiEZ_rnnbnuc7_tA@mail.gmail.com>
Message-ID: <516D18A5.6030706@cisco.com>

Sasa
Ohkubo-san tested Linux as BR,too.
You need to change default route to IPv6 internet and enable IPv6 fowarding.
/etc/sysctl.conf
net.ipv6.conf.all.forwarding=1

Regards,
-Shishio


(2013/04/16 16:33), Sasa Ristic wrote:
> OK, I found this information too, but, if I'm not mistaken, this is all regarding 6rd "client" setup on *nix, while the BR is on Cisco ASR1K.
> I'm trying to setup BR on (any kind) Linux, but either there is no possibility or information on this topic, or I'm unable to find it.
> 
> 
> On Tue, Apr 16, 2013 at 3:44 AM, Shishio Tsuchiya <shtsuchi at cisco.com <mailto:shtsuchi at cisco.com>> wrote:
> 
>     Sasa
>     Sakura internet,datacentor provider of JAPAN,is providing 6rd BR(ASR1K),IPv6 internet and 6rd configuration information for their customer.
>     We published the information as informational draft.
>     Debian 6.0's linux kernel is 2.6.32.So <http://2.6.32.So> you might need upgrade kernel.
>     Basically information is 6rd CE configuration for host,but I think this would be useful for you.
>     http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04#appendix-A.1.2.3
>     http://research.sakura.ad.jp/6rd-trial/6rd-trial-debian60/
>     (Japanese)
> 
>     Regards,
>     -Shishio
> 
>     (2013/04/16 7:57), Sasa Ristic wrote:
>      > hello all,
>      >
>      > can someone please share any info regarding a ipv6 6rd BR setup on linux
>      > (debian specific preferably)... goo.gl <http://goo.gl> search didn't turn up much...
>      >
>      > thanks!
>      >
>      >
>      >
> 
> 
> 
> 
> 
> 
> -- 
> ricky




From robertg at garlic.com  Tue Apr 16 15:45:44 2013
From: robertg at garlic.com (Robert Glover)
Date: Tue, 16 Apr 2013 08:45:44 -0700
Subject: Fiber cut in SF Bay Area?
Message-ID: <516D7228.5080200@garlic.com>

Hello,

I'm only posting this here because the Outages list appears to be broken.

I've got confirmed reports (from Cogent and Megapath) that there is a 
fiber cut affecting service through the South Bay.

We have Cogent fiber circuits down in Campbell and San Martin.   In San 
Martin, AT&T cell phones have no service whatsoever, DSL service is 
spotty.  Landline and DSL service in Gilroy is almost completely gone.  
We know of a Cogent fiber link in Campbell that is down as well.

Anyone have any additional info?

-Robert


Anyone have any further details?   The issue seems to have started 
around 1:00am PDT or so.

-Robert



From jared at puck.nether.net  Tue Apr 16 15:51:28 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 16 Apr 2013 11:51:28 -0400
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <516D7228.5080200@garlic.com>
References: <516D7228.5080200@garlic.com>
Message-ID: <B6597210-8434-4FF8-9413-55F1B4CA2B97@puck.nether.net>


On Apr 16, 2013, at 11:45 AM, Robert Glover <robertg at garlic.com> wrote:

> Hello,
> 
> I'm only posting this here because the Outages list appears to be broken.

I'll look into that.

> I've got confirmed reports (from Cogent and Megapath) that there is a fiber cut affecting service through the South Bay.
> 
> We have Cogent fiber circuits down in Campbell and San Martin.   In San Martin, AT&T cell phones have no service whatsoever, DSL service is spotty.  Landline and DSL service in Gilroy is almost completely gone.  We know of a Cogent fiber link in Campbell that is down as well.

I've heard about a number of circuits down with splice crew on the way.

- jared

From ios.run at gmail.com  Tue Apr 16 15:55:56 2013
From: ios.run at gmail.com (Raul Rodriguez)
Date: Tue, 16 Apr 2013 08:55:56 -0700
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <516D7228.5080200@garlic.com>
References: <516D7228.5080200@garlic.com>
Message-ID: <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>

Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.

-RR

On 4/16/13, Robert Glover <robertg at garlic.com> wrote:
> Hello,
>
> I'm only posting this here because the Outages list appears to be broken.
>
> I've got confirmed reports (from Cogent and Megapath) that there is a
> fiber cut affecting service through the South Bay.
>
> We have Cogent fiber circuits down in Campbell and San Martin.   In San
> Martin, AT&T cell phones have no service whatsoever, DSL service is
> spotty.  Landline and DSL service in Gilroy is almost completely gone.
> We know of a Cogent fiber link in Campbell that is down as well.
>
> Anyone have any additional info?
>
> -Robert
>
>
> Anyone have any further details?   The issue seems to have started
> around 1:00am PDT or so.
>
> -Robert
>
>
>

-- 
Sent from my mobile device


From j at 2600hz.com  Tue Apr 16 16:26:41 2013
From: j at 2600hz.com (Joshua Goldbard)
Date: Tue, 16 Apr 2013 16:26:41 +0000
Subject: Q&A for Telecom Nerds
Message-ID: <FD4A91ABAD370D4383186A56320046BE084C1D00@mbx022-w1-ca-10.exch022.domain.local>

Hello,

We're starting a series of Q&A Webinar sessions for those that love Telecom. The first topic we're going to touch on is Virtualization vs Bare Metal (http://2600hzqa1.eventbrite.com/) this Friday, 4/19, at 10am Pacific. Two fridays after that, on May 3rd, we'll be covering faxing (http://2600hzqa2.eventbrite.com/), also at 10am Pacific. We hope you'll join us.

This is intended to be a non-marketing event, you won't hear sales pitches on these calls, but you will get insight from companies and individuals that have built large telecom infrastructures. We are an open-source company and this is part of giving back to the community of giants on whose shoulders we stand. I hope you'll join us, and if anyone has any questions prior to the event, please don't hesitate to ask.

Cheers,
Joshua

Joshua Goldbard
VP of Marketing, 2600hz

116 Natoma Street, Floor 2
San Francisco, CA, 94104
415.886.7923 | j at 2600hz.com<mailto:j at 2600hz.com>


From ravi at cow.org  Tue Apr 16 16:51:16 2013
From: ravi at cow.org (Ravi Pina)
Date: Tue, 16 Apr 2013 12:51:16 -0400
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
Message-ID: <20130416165116.GN60767@neu.cow.org>

Our Zayo provided ETR is 11:00 - 11:30 PDT.

XO is one of the impacted providers as well.

-r

On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
> Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.
> 
> -RR
> 


From zaid at zaidali.com  Tue Apr 16 17:26:53 2013
From: zaid at zaidali.com (Zaid Ali Kahn)
Date: Tue, 16 Apr 2013 13:26:53 -0400
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <20130416165116.GN60767@neu.cow.org>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
 <20130416165116.GN60767@neu.cow.org>
Message-ID: <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>

Level3 is also impacted. This cut seems to be vandalism but only heard this from one source.

Zaid

Sent from my iPhone

On Apr 16, 2013, at 12:51 PM, Ravi Pina <ravi at cow.org> wrote:

> Our Zayo provided ETR is 11:00 - 11:30 PDT.
> 
> XO is one of the impacted providers as well.
> 
> -r
> 
> On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
>> Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.
>> 
>> -RR
> 


From nanog at dm0.org  Tue Apr 16 17:48:32 2013
From: nanog at dm0.org (Ryan Bonnell)
Date: Tue, 16 Apr 2013 10:48:32 -0700
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <516D7228.5080200@garlic.com>
References: <516D7228.5080200@garlic.com>
Message-ID: <CAEvrtvDtMmH93+-+yBbqgePVw8q91_2_b7pRu6AF9AdP7gWcyA@mail.gmail.com>

MegaPath reports no service disruptions for DSL services. My latency graph
says otherwise...

http://i.imgur.com/pwC2oX2.png

These graphs are for 2 Megapath DSL serviced locations in NorCal from a
SoCal perspective.

-Ryan


On Tue, Apr 16, 2013 at 8:45 AM, Robert Glover <robertg at garlic.com> wrote:

> Hello,
>
> I'm only posting this here because the Outages list appears to be broken.
>
> I've got confirmed reports (from Cogent and Megapath) that there is a
> fiber cut affecting service through the South Bay.
>
> We have Cogent fiber circuits down in Campbell and San Martin.   In San
> Martin, AT&T cell phones have no service whatsoever, DSL service is spotty.
>  Landline and DSL service in Gilroy is almost completely gone.  We know of
> a Cogent fiber link in Campbell that is down as well.
>
> Anyone have any additional info?
>
> -Robert
>
>
> Anyone have any further details?   The issue seems to have started around
> 1:00am PDT or so.
>
> -Robert
>
>
>

From morrowc.lists at gmail.com  Tue Apr 16 17:57:59 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 16 Apr 2013 13:57:59 -0400
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <CAEvrtvDtMmH93+-+yBbqgePVw8q91_2_b7pRu6AF9AdP7gWcyA@mail.gmail.com>
References: <516D7228.5080200@garlic.com>
 <CAEvrtvDtMmH93+-+yBbqgePVw8q91_2_b7pRu6AF9AdP7gWcyA@mail.gmail.com>
Message-ID: <CAL9jLaZ+RKgk7bYzG3gpbXZg9vq2uU8u=t+dwG2NGo4KgXHG1A@mail.gmail.com>

On Tue, Apr 16, 2013 at 1:48 PM, Ryan Bonnell <nanog at dm0.org> wrote:

> MegaPath reports no service disruptions for DSL services. My latency graph
> says otherwise...
>

that's not a service 'disruption'... that's just longer latency.


>
> http://i.imgur.com/pwC2oX2.png


looks like your packets took the east-coast path up the west-coast.

-chris

From ravi at cow.org  Tue Apr 16 17:59:27 2013
From: ravi at cow.org (Ravi Pina)
Date: Tue, 16 Apr 2013 13:59:27 -0400
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <20130416165116.GN60767@neu.cow.org>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
 <20130416165116.GN60767@neu.cow.org>
Message-ID: <20130416175927.GO60767@neu.cow.org>

We saw service restoration start at or about 1026 PDT.

-r

On Tue, Apr 16, 2013 at 12:51:16PM -0400, Ravi Pina wrote:
> Our Zayo provided ETR is 11:00 - 11:30 PDT.
> 
> XO is one of the impacted providers as well.
> 
> -r
> 
> On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
> > Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.
> > 
> > -RR
> > 


From alex-lists-nanog at yuriev.com  Tue Apr 16 18:03:17 2013
From: alex-lists-nanog at yuriev.com (alex-lists-nanog at yuriev.com)
Date: Tue, 16 Apr 2013 14:03:17 -0400
Subject: Need multipe 10Gs at 111 8th ave in under 30 days
Message-ID: <20130416180317.GD26922@tickets1.zubrcom.net>


Site doing between 4G/sec and 27G/sec out of 111 8th Ave and another
90-120G/sec via CDNs is looking to change distribution of its traffic by
taking more traffic off CDNs

Looking for the following:

- Handoffs - 10G (multiple 10G preferred) in TelX or Internap at 111 8th per
  provider.
- Good european connectivity 
- BGP with communities 
- Low CIR + low
- IPv6 capability over the same path preferred but not required
- Quick turn up

Spam me.

Alex



From jlsparks at gmail.com  Tue Apr 16 17:52:46 2013
From: jlsparks at gmail.com (Jason L. Sparks)
Date: Tue, 16 Apr 2013 10:52:46 -0700 (PDT)
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <CAEvrtvDtMmH93+-+yBbqgePVw8q91_2_b7pRu6AF9AdP7gWcyA@mail.gmail.com>
References: <CAEvrtvDtMmH93+-+yBbqgePVw8q91_2_b7pRu6AF9AdP7gWcyA@mail.gmail.com>
Message-ID: <1366134766061.842d5846@Nodemailer>

This might be related:?http://www.reuters.com/article/2013/04/16/california-electricity-siliconvalley-idUKL2N0D31MO20130416
?
Sent from Mailbox for iPhone

On Tue, Apr 16, 2013 at 1:50 PM, Ryan Bonnell <nanog at dm0.org> wrote:

> MegaPath reports no service disruptions for DSL services. My latency graph
> says otherwise...
> http://i.imgur.com/pwC2oX2.png
> These graphs are for 2 Megapath DSL serviced locations in NorCal from a
> SoCal perspective.
> -Ryan
> On Tue, Apr 16, 2013 at 8:45 AM, Robert Glover <robertg at garlic.com> wrote:
>> Hello,
>>
>> I'm only posting this here because the Outages list appears to be broken.
>>
>> I've got confirmed reports (from Cogent and Megapath) that there is a
>> fiber cut affecting service through the South Bay.
>>
>> We have Cogent fiber circuits down in Campbell and San Martin.   In San
>> Martin, AT&T cell phones have no service whatsoever, DSL service is spotty.
>>  Landline and DSL service in Gilroy is almost completely gone.  We know of
>> a Cogent fiber link in Campbell that is down as well.
>>
>> Anyone have any additional info?
>>
>> -Robert
>>
>>
>> Anyone have any further details?   The issue seems to have started around
>> 1:00am PDT or so.
>>
>> -Robert
>>
>>
>>

From rodrick.brown at gmail.com  Tue Apr 16 18:13:33 2013
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Tue, 16 Apr 2013 14:13:33 -0400
Subject: Need multipe 10Gs at 111 8th ave in under 30 dayside
In-Reply-To: <20130416180317.GD26922@tickets1.zubrcom.net>
References: <20130416180317.GD26922@tickets1.zubrcom.net>
Message-ID: <-2821098045170701995@unknownmsgid>

U u 5

Sent from my iPhone

On Apr 16, 2013, at 2:06 PM, "alex-lists-nanog at yuriev.com"
<alex-lists-nanog at yuriev.com> wrote:

>
> Site doing between 4G/sec and 27G/sec out of 111 8th Ave and another
> 90-120G/sec via CDNs is looking to change distribution of its traffic by
> taking more traffic off CDNs
>
> Looking for the following:
>
> - Handoffs - 10G (multiple 10G preferred) in TelX or Internap at 111 8th per
>  provider.
> - Good european connectivity
> - BGP with communities
> - Low CIR + low
> - IPv6 capability over the same path preferred but not required
> - Quick turn up
>
> Spam me.
>
> Alex
>
>


From markjr at easydns.com  Tue Apr 16 18:27:18 2013
From: markjr at easydns.com (Mark Jeftovic)
Date: Tue, 16 Apr 2013 14:27:18 -0400
Subject: looking for a clue at gc.ca 
Message-ID: <516D9806.9040504@easydns.com>

(No, this isn't a setup for a joke.)

We need to find a clueful P.O.C at the Government of Canada NOC, more 
precisely, a DNS administrator for the parl.gc.ca zone or the
82.197.192.in-addr.arpa netblock.

Thx.

- mark

-- 
Mark Jeftovic <markjr at easydns.com>
Founder & CEO, easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225
Read my blog: http://markable.com



From woody at pch.net  Tue Apr 16 18:32:59 2013
From: woody at pch.net (Bill Woodcock)
Date: Tue, 16 Apr 2013 11:32:59 -0700
Subject: looking for a clue at gc.ca 
In-Reply-To: <516D9806.9040504@easydns.com>
References: <516D9806.9040504@easydns.com>
Message-ID: <EC410FE3-6589-4E74-B8F2-167E05B51D96@pch.net>


On Apr 16, 2013, at 11:27 AM, Mark Jeftovic <markjr at easydns.com> wrote:
> We need to find a clueful P.O.C at the Government of Canada NOC, 

Introductions made off-list.

                                -Bill







From elouie at yahoo.com  Tue Apr 16 18:50:22 2013
From: elouie at yahoo.com (Eric A Louie)
Date: Tue, 16 Apr 2013 11:50:22 -0700 (PDT)
Subject: Colo recommendations
Message-ID: <1366138222.6884.YahooMailRC@web181601.mail.ne1.yahoo.com>

I'm investigating colocation space in the following cities
Irvine, CA
San Francisco, CA
Las Vegas, NV
Phoenix, AZ

Does anyone have recommendations for (or against) any specific colo?  I'll need 
1/3 rack, 16 amp power (or 8 amp 220V), fiber cross to 1GB ISP upstream (haven't 
chosen the ISP yet, either), roof or tower access to mount an antenna.

Private replies are welcome, as are replies to the list.

thanks
Eric

From r.engehausen at gmail.com  Tue Apr 16 18:58:36 2013
From: r.engehausen at gmail.com (Roy)
Date: Tue, 16 Apr 2013 11:58:36 -0700
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
 <20130416165116.GN60767@neu.cow.org>
 <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>
Message-ID: <516D9F5C.8020000@gmail.com>



I heard of a fiber cut in Texas where the thieves thought it was copper :-)

On 4/16/2013 10:26 AM, Zaid Ali Kahn wrote:
> Level3 is also impacted. This cut seems to be vandalism but only heard this from one source.
>
> Zaid
>
> Sent from my iPhone
>
> On Apr 16, 2013, at 12:51 PM, Ravi Pina <ravi at cow.org> wrote:
>
>> Our Zayo provided ETR is 11:00 - 11:30 PDT.
>>
>> XO is one of the impacted providers as well.
>>
>> -r
>>
>> On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
>>> Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.
>>>
>>> -RR
> .
>



From sean-list at head-net.com  Tue Apr 16 19:00:11 2013
From: sean-list at head-net.com (Sean Head)
Date: Tue, 16 Apr 2013 12:00:11 -0700
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <1366134766061.842d5846@Nodemailer>
References: <CAEvrtvDtMmH93+-+yBbqgePVw8q91_2_b7pRu6AF9AdP7gWcyA@mail.gmail.com>
 <1366134766061.842d5846@Nodemailer>
Message-ID: <516D9FBB.6090604@head-net.com>

That wouldn't surprise me at all. The substation they're talking about
is actually quite large ( http://goo.gl/maps/2FuO4 ) and is right next
to a NG power plant.

http://en.wikipedia.org/wiki/Metcalf_Energy_Center
http://en.wikipedia.org/wiki/Path_15


On 2013.04.16 10:52:46, Jason L. Sparks wrote:
> This might be related: http://www.reuters.com/article/2013/04/16/california-electricity-siliconvalley-idUKL2N0D31MO20130416
> ?
> Sent from Mailbox for iPhone
> 
> On Tue, Apr 16, 2013 at 1:50 PM, Ryan Bonnell <nanog at dm0.org> wrote:
> 
>> MegaPath reports no service disruptions for DSL services. My latency graph
>> says otherwise...
>> http://i.imgur.com/pwC2oX2.png
>> These graphs are for 2 Megapath DSL serviced locations in NorCal from a
>> SoCal perspective.
>> -Ryan
>> On Tue, Apr 16, 2013 at 8:45 AM, Robert Glover <robertg at garlic.com> wrote:
>>> Hello,
>>>
>>> I'm only posting this here because the Outages list appears to be broken.
>>>
>>> I've got confirmed reports (from Cogent and Megapath) that there is a
>>> fiber cut affecting service through the South Bay.
>>>
>>> We have Cogent fiber circuits down in Campbell and San Martin.   In San
>>> Martin, AT&T cell phones have no service whatsoever, DSL service is spotty.
>>>  Landline and DSL service in Gilroy is almost completely gone.  We know of
>>> a Cogent fiber link in Campbell that is down as well.
>>>
>>> Anyone have any additional info?
>>>
>>> -Robert
>>>
>>>
>>> Anyone have any further details?   The issue seems to have started around
>>> 1:00am PDT or so.
>>>
>>> -Robert
>>>
>>>
>>>



From matthias at leisi.net  Tue Apr 16 19:00:15 2013
From: matthias at leisi.net (Matthias Leisi)
Date: Tue, 16 Apr 2013 21:00:15 +0200
Subject: What do people use public suffix for?
In-Reply-To: <m24nf7sckn.fsf@localhost.localdomain>
References: <20130415131017.9047.qmail@joyce.lan>
 <m24nf7sckn.fsf@localhost.localdomain>
Message-ID: <CALgnk9onHoLAD-c+WT_Wm8mXe3TfUQ3L3Z=qw8FAJVdRjXbbNw@mail.gmail.com>

On Mon, Apr 15, 2013 at 11:34 PM, Geoffrey Keating <geoffk at geoffk.org>wrote:


> They'd really like to have a process which is less ad-hoc.  For
> example, it'd be great if these points were annotated in the DNS
> itself, perhaps with a record which points to the corresponding
> whois server
>

Btw., this would similarly apply to reverse DNS. Having a well-defined way
to identify administrative control (maybe some better wording would be
required) could be helpful in defining boundaries for reputation systems
(eg "all IPs in this IPv6-/32 belong to the same ISP, but the adjacent /32
is someone else.").

-- Matthias

From David.Siegel at Level3.com  Tue Apr 16 19:18:49 2013
From: David.Siegel at Level3.com (Siegel, David)
Date: Tue, 16 Apr 2013 19:18:49 +0000
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
 <20130416165116.GN60767@neu.cow.org>
 <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>
Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0C7562E@USIDCWVEMBX10.corp.global.level3.com>

The information that I have is consistent with that...the cut appears to be vandalism related.  

Splicing has been under way for several hours and is expected to be completed within the next 30 minutes.

Dave


-----Original Message-----
From: Zaid Ali Kahn [mailto:zaid at zaidali.com] 
Sent: Tuesday, April 16, 2013 11:27 AM
To: Ravi Pina
Cc: nanog at nanog.org
Subject: Re: Fiber cut in SF Bay Area?

Level3 is also impacted. This cut seems to be vandalism but only heard this from one source.

Zaid

Sent from my iPhone

On Apr 16, 2013, at 12:51 PM, Ravi Pina <ravi at cow.org> wrote:

> Our Zayo provided ETR is 11:00 - 11:30 PDT.
> 
> XO is one of the impacted providers as well.
> 
> -r
> 
> On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
>> Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.
>> 
>> -RR
> 



From robertg at garlic.com  Tue Apr 16 19:21:43 2013
From: robertg at garlic.com (Robert Glover)
Date: Tue, 16 Apr 2013 12:21:43 -0700
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0C7562E@USIDCWVEMBX10.corp.global.level3.com>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
 <20130416165116.GN60767@neu.cow.org>
 <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>
 <970945E55BFD8C4EA4CAD74B647A9DC0C7562E@USIDCWVEMBX10.corp.global.level3.com>
Message-ID: <516DA4C7.9080907@garlic.com>

I just spoke to Cogent about 10 minutes ago.  They confirmed with AT&T 
that it was vandalism, but AT&T gave them an ETR of 4:00PM PDT.

On 4/16/2013 12:18 PM, Siegel, David wrote:
> The information that I have is consistent with that...the cut appears to be vandalism related.
>
> Splicing has been under way for several hours and is expected to be completed within the next 30 minutes.
>
> Dave
>
>
> -----Original Message-----
> From: Zaid Ali Kahn [mailto:zaid at zaidali.com]
> Sent: Tuesday, April 16, 2013 11:27 AM
> To: Ravi Pina
> Cc: nanog at nanog.org
> Subject: Re: Fiber cut in SF Bay Area?
>
> Level3 is also impacted. This cut seems to be vandalism but only heard this from one source.
>
> Zaid
>
> Sent from my iPhone
>
> On Apr 16, 2013, at 12:51 PM, Ravi Pina <ravi at cow.org> wrote:
>
>> Our Zayo provided ETR is 11:00 - 11:30 PDT.
>>
>> XO is one of the impacted providers as well.
>>
>> -r
>>
>> On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
>>> Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 11AM PDT.
>>>
>>> -RR
>



From davediaz at gmail.com  Tue Apr 16 22:27:54 2013
From: davediaz at gmail.com (David Diaz)
Date: Tue, 16 Apr 2013 18:27:54 -0400
Subject: Need multipe 10Gs at 111 8th ave in under 30 days
In-Reply-To: <20130416180317.GD26922@tickets1.zubrcom.net>
References: <20130416180317.GD26922@tickets1.zubrcom.net>
Message-ID: <2E26F7A4-A24C-47AF-9E05-BA874D94A2BD@gmail.com>

Wow a 'spam me' request haha

I referred Chris I to a contact, Jeff Flam, I've known forever that might be able to help you get good pricing from several carriers. Looks like ur solution needs a several carriers.

Maybe Chris can chime if he found Jeff helpful

Let me know if u want the contact info

David



On Apr 16, 2013, at 14:03, alex-lists-nanog at yuriev.com wrote:

> 
> Site doing between 4G/sec and 27G/sec out of 111 8th Ave and another
> 90-120G/sec via CDNs is looking to change distribution of its traffic by
> taking more traffic off CDNs
> 
> Looking for the following:
> 
> - Handoffs - 10G (multiple 10G preferred) in TelX or Internap at 111 8th per
>  provider.
> - Good european connectivity 
> - BGP with communities 
> - Low CIR + low
> - IPv6 capability over the same path preferred but not required
> - Quick turn up
> 
> Spam me.
> 
> Alex
> 
> 


From robertg at garlic.com  Tue Apr 16 22:51:47 2013
From: robertg at garlic.com (Robert Glover)
Date: Tue, 16 Apr 2013 15:51:47 -0700
Subject: Fiber cut in SF Bay Area?
In-Reply-To: <516DA4C7.9080907@garlic.com>
References: <516D7228.5080200@garlic.com>
 <CAHnk2Ojybv8p3KULkKqUiAvKZGvfkcS9TdVnMzqeTpuiA=H1OQ@mail.gmail.com>
 <20130416165116.GN60767@neu.cow.org>
 <142C44A7-848E-4F6B-915A-A539BD0D5C81@zaidali.com>
 <970945E55BFD8C4EA4CAD74B647A9DC0C7562E@USIDCWVEMBX10.corp.global.level3.com>
 <516DA4C7.9080907@garlic.com>
Message-ID: <516DD603.1040509@garlic.com>

All,

Just got off the horn with Cogent.  They called AT&T while they had me 
on hold, AT&T told them they have extracted the fiber, which was, 
according to them, "very heavily damaged".  They have brought a new 
cable in, and are in the process of splicing.

-Robert

On 4/16/2013 12:21 PM, Robert Glover wrote:
> I just spoke to Cogent about 10 minutes ago.  They confirmed with AT&T 
> that it was vandalism, but AT&T gave them an ETR of 4:00PM PDT.
>
> On 4/16/2013 12:18 PM, Siegel, David wrote:
>> The information that I have is consistent with that...the cut appears 
>> to be vandalism related.
>>
>> Splicing has been under way for several hours and is expected to be 
>> completed within the next 30 minutes.
>>
>> Dave
>>
>>
>> -----Original Message-----
>> From: Zaid Ali Kahn [mailto:zaid at zaidali.com]
>> Sent: Tuesday, April 16, 2013 11:27 AM
>> To: Ravi Pina
>> Cc: nanog at nanog.org
>> Subject: Re: Fiber cut in SF Bay Area?
>>
>> Level3 is also impacted. This cut seems to be vandalism but only 
>> heard this from one source.
>>
>> Zaid
>>
>> Sent from my iPhone
>>
>> On Apr 16, 2013, at 12:51 PM, Ravi Pina <ravi at cow.org> wrote:
>>
>>> Our Zayo provided ETR is 11:00 - 11:30 PDT.
>>>
>>> XO is one of the impacted providers as well.
>>>
>>> -r
>>>
>>> On Tue, Apr 16, 2013 at 08:55:56AM -0700, Raul Rodriguez wrote:
>>>> Lost a Zayo circuit from Palo Alto to Los Angeles. ETR was given as 
>>>> 11AM PDT.
>>>>
>>>> -RR
>>
>
>



From danny at tcb.net  Wed Apr 17 02:19:21 2013
From: danny at tcb.net (Danny McPherson)
Date: Tue, 16 Apr 2013 22:19:21 -0400
Subject: What do people use public suffix for?
In-Reply-To: <m24nf7sckn.fsf@localhost.localdomain>
References: <20130415131017.9047.qmail@joyce.lan>
 <m24nf7sckn.fsf@localhost.localdomain>
Message-ID: <1A639718-F42E-4218-A2D9-96780794431E@tcb.net>


On Apr 15, 2013, at 5:34 PM, Geoffrey Keating wrote:
> 
> CAs use it as part of a procedure to determine whether it's safe to
> issue a wildcard domain (as in, if it's on the list, it's not safe).  See
> <https://www.cabforum.org/Baseline_Requirements_V1_1_3.pdf>, section 11.1.3.
> 
> They'd really like to have a process which is less ad-hoc.  For
> example, it'd be great if these points were annotated in the DNS
> itself, perhaps with a record which points to the corresponding
> whois server.


Concur - I think codifying DNS's dynamic structure in an outside medium is only going to cause problems down the road (e.g., especially with namespace diffusion from the likes of new gTLDs, etc..).

While an unfortunate naming collision here (i.e., the "SOPA" RR), I think an approach such as [1] has some merit - but much work needs to be done.  

-danny

[1] http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02





From masakazu.asama at gmail.com  Wed Apr 17 08:11:15 2013
From: masakazu.asama at gmail.com (Masakazu Asama)
Date: Wed, 17 Apr 2013 17:11:15 +0900
Subject: IPv6 6rd BR setup on Linux
In-Reply-To: <516D18A5.6030706@cisco.com>
References: <CAPVpXLz-ZAHJ-vzbNpASPN2grKCF1_TAMK+kJQMWNDywU3wypQ@mail.gmail.com>
 <516CAD16.7010602@cisco.com>
 <CAPVpXLyRedrb=SWTnmDdMq1GQUJhweDmpZMiEZ_rnnbnuc7_tA@mail.gmail.com>
 <516D18A5.6030706@cisco.com>
Message-ID: <CAP8M2pF96NjTn6FPdcdUKqaf9RZpw5WtC1phsxNXa7q3jwEJnA@mail.gmail.com>

Sasa

Distribution that supports 6rd feature is limited.
I was confirmed that it works on debian wheezy.
(squeeze's kernel does not support 6rd.)

(1) edit /etc/sysctl.conf and set net.ipv6.conf.all.forwarding=1
(2) edit /etc/network/interfaces like following
===
auto eth0
iface eth0 inet static
    address 172.16.1.1
    netmask 255.255.255.0
    gateway 172.16.1.123
iface eth0 inet6 static
    address 2001:xxxx:xxxx:xxxx::1
    netmask 64
    gateway 2001:xxxx:xxxx:xxxx::1234

auto tun6rd
iface tun6rd inet6 v4tunnel
    address 2001:db8:ac10:101::
    netmask 32
    local 172.16.1.1
    endpoint any
    ttl 64
    up ip tunnel 6rd dev tun6rd 6rd-prefix 2001:db8::/32
    up ip link set mtu 1280 dev tun6rd
===
(3) reboot

This example assumes that 6rd-prefix = 2001:db8::/32 and BR has
172.16.1.1(0xac100101).

Regards.



2013/4/16 Shishio Tsuchiya <shtsuchi at cisco.com>

> Sasa
> Ohkubo-san tested Linux as BR,too.
> You need to change default route to IPv6 internet and enable IPv6
> fowarding.
> /etc/sysctl.conf
> net.ipv6.conf.all.forwarding=1
>
> Regards,
> -Shishio
>
>
> (2013/04/16 16:33), Sasa Ristic wrote:
> > OK, I found this information too, but, if I'm not mistaken, this is all
> regarding 6rd "client" setup on *nix, while the BR is on Cisco ASR1K.
> > I'm trying to setup BR on (any kind) Linux, but either there is no
> possibility or information on this topic, or I'm unable to find it.
> >
> >
> > On Tue, Apr 16, 2013 at 3:44 AM, Shishio Tsuchiya <shtsuchi at cisco.com<mailto:
> shtsuchi at cisco.com>> wrote:
> >
> >     Sasa
> >     Sakura internet,datacentor provider of JAPAN,is providing 6rd
> BR(ASR1K),IPv6 internet and 6rd configuration information for their
> customer.
> >     We published the information as informational draft.
> >     Debian 6.0's linux kernel is 2.6.32.So <http://2.6.32.So> you might
> need upgrade kernel.
> >     Basically information is 6rd CE configuration for host,but I think
> this would be useful for you.
> >
> http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04#appendix-A.1.2.3
> >     http://research.sakura.ad.jp/6rd-trial/6rd-trial-debian60/
> >     (Japanese)
> >
> >     Regards,
> >     -Shishio
> >
> >     (2013/04/16 7:57), Sasa Ristic wrote:
> >      > hello all,
> >      >
> >      > can someone please share any info regarding a ipv6 6rd BR setup
> on linux
> >      > (debian specific preferably)... goo.gl <http://goo.gl> search
> didn't turn up much...
> >      >
> >      > thanks!
> >      >
> >      >
> >      >
> >
> >
> >
> >
> >
> >
> > --
> > ricky
>
>
>
>

From caioalves.eng at gmail.com  Wed Apr 17 12:28:42 2013
From: caioalves.eng at gmail.com (Caio Alves)
Date: Wed, 17 Apr 2013 09:28:42 -0300
Subject: GMAIL?
Message-ID: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>

Someone has access problems in GMAIL? Here in Brazil, many complaints about
the service.

From kalbfleischl at interstatecargo.com  Wed Apr 17 16:00:50 2013
From: kalbfleischl at interstatecargo.com (Lucius Kalbfleisch)
Date: Wed, 17 Apr 2013 10:00:50 -0600
Subject: GMAIL?
In-Reply-To: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>
References: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>
Message-ID: <CACz6FL1FL9h-jDGcOmXH+NOFDKWO4zRg5gML0-+X5BXeQe4WFw@mail.gmail.com>

There are a few  known issues affecting Google products right now:
http://www.google.com/appsstatus


On Wed, Apr 17, 2013 at 6:28 AM, Caio Alves <caioalves.eng at gmail.com> wrote:

> Someone has access problems in GMAIL? Here in Brazil, many complaints about
> the service.
>



-- 

[image: Interstate_TP_Logo]*Lucius Kalbfleisch*  *IT -* Systems and Network
Administrator
(208) 442-7683 Direct
(208) 284-7194 Mobile
kalbfleischl at interstatecargo.com
www.TrailersPlus.com <http://www.trailersplus.com/>
[image: Facebook]
Facebook.com/Trailersplus<http://www.facebook.com/Trailersplus>

*TrailersPlus / Interstate Group*
3800 Airport Rd
Nampa, ID 83687

From lathama at gmail.com  Wed Apr 17 16:02:45 2013
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 17 Apr 2013 12:02:45 -0400
Subject: GMAIL?
In-Reply-To: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>
References: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>
Message-ID: <CA+qj4S9Rzwr-Km7YKVT8ScWJ0Xxwq0NJNYbj4ascSzXBj=7=Hg@mail.gmail.com>

On Wed, Apr 17, 2013 at 8:28 AM, Caio Alves <caioalves.eng at gmail.com> wrote:
> Someone has access problems in GMAIL? Here in Brazil, many complaints about
> the service.

Try http://www.google.com/appsstatus

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


From eric at roxanne.org  Wed Apr 17 17:04:44 2013
From: eric at roxanne.org (Eric)
Date: Wed, 17 Apr 2013 13:04:44 -0400
Subject: Berlin ISP
Message-ID: <8DCE03EB-1849-4E91-9ABC-F34285AEACAC@roxanne.org>

Hello,

I'm looking for about a 10-20mbps ISP circuit for our Berlin office.  Any recommendations on who provides access there and might be able to deal with us in English?

Eric

From universe at truemetal.org  Wed Apr 17 17:55:10 2013
From: universe at truemetal.org (Markus)
Date: Wed, 17 Apr 2013 19:55:10 +0200
Subject: Berlin ISP
In-Reply-To: <8DCE03EB-1849-4E91-9ABC-F34285AEACAC@roxanne.org>
References: <8DCE03EB-1849-4E91-9ABC-F34285AEACAC@roxanne.org>
Message-ID: <516EE1FE.7000902@truemetal.org>

Am 17.04.2013 19:04, schrieb Eric:
> Hello,
>
> I'm looking for about a 10-20mbps ISP circuit for our Berlin office.  Any recommendations on who provides access there and might be able to deal with us in English?
>
> Eric

These two are reliable:

http://www.ipb.de
kontakt at ipb.de

http://www.dns-net.de
sales at dns-net.de




From ristic.sasa at gmail.com  Wed Apr 17 20:16:39 2013
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Wed, 17 Apr 2013 22:16:39 +0200
Subject: Berlin ISP
In-Reply-To: <516EE1FE.7000902@truemetal.org>
References: <8DCE03EB-1849-4E91-9ABC-F34285AEACAC@roxanne.org>
 <516EE1FE.7000902@truemetal.org>
Message-ID: <CAPVpXLxwQcGkeUC6bmk8QcQkzSF0BKLw8m-X31ha=nB7UY2xWw@mail.gmail.com>

I can also recommend from personal business experience: www.kgtnewmedia.de
very good prices, and excellent service quality.





On Wed, Apr 17, 2013 at 7:55 PM, Markus <universe at truemetal.org> wrote:

> Am 17.04.2013 19:04, schrieb Eric:
>
>  Hello,
>>
>> I'm looking for about a 10-20mbps ISP circuit for our Berlin office.  Any
>> recommendations on who provides access there and might be able to deal with
>> us in English?
>>
>> Eric
>>
>
> These two are reliable:
>
> http://www.ipb.de
> kontakt at ipb.de
>
> http://www.dns-net.de
> sales at dns-net.de
>
>
>
>


-- 
ricky

From mmata at intercom.com.sv  Wed Apr 17 20:38:47 2013
From: mmata at intercom.com.sv (Miguel Mata)
Date: Wed, 17 Apr 2013 14:38:47 -0600
Subject: someone from Sprint
Message-ID: <516F0857.28275.25501190@mmata.intercom.com.sv>

Hi,

we are having some problems reaching some of the sprint.com sites. If someone around that 
can help us, it'll be very appreciated. We are AS16592.

Please off list.


-- 
Miguel Mata
Gerente de Operaciones
Comunicaciones IBW El Salvador
tel.: ++(503) 2278-5068
fax: ++(503) 2207-1310
mmata at ibw.com

"La confianza es la mejor conexion"





From bmanning at vacation.karoshi.com  Wed Apr 17 20:51:29 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 17 Apr 2013 20:51:29 +0000
Subject: someone from Sprint
In-Reply-To: <516F0857.28275.25501190@mmata.intercom.com.sv>
References: <516F0857.28275.25501190@mmata.intercom.com.sv>
Message-ID: <20130417205129.GA24183@vacation.karoshi.com.>

 your not alone...  (Sprint is the upstream for this email)

The original message was received at Wed, 17 Apr 2013 14:21:10 GMT
from localhost.localdomain [127.0.0.1]
  
   ----- The following addresses had permanent fatal errors -----
<Tom.A.Schiel at sprint.com>
    (reason: 501 5.5.4 Invalid domain name)

/bill


On Wed, Apr 17, 2013 at 02:38:47PM -0600, Miguel Mata wrote:
> Hi,
> 
> we are having some problems reaching some of the sprint.com sites. If someone around that 
> can help us, it'll be very appreciated. We are AS16592.
> 
> Please off list.
> 
> 
> -- 
> Miguel Mata
> Gerente de Operaciones
> Comunicaciones IBW El Salvador
> tel.: ++(503) 2278-5068
> fax: ++(503) 2207-1310
> mmata at ibw.com
> 
> "La confianza es la mejor conexion"
> 
> 
> 


From deniz.aydin at turknet.net.tr  Thu Apr 18 07:17:27 2013
From: deniz.aydin at turknet.net.tr (Deniz Aydin)
Date: Thu, 18 Apr 2013 07:17:27 +0000
Subject: Ethernet CFM & LMI vs EBGP between PE-CE
In-Reply-To: <CAN3um4wpyQhqUE-ERFA76cDQTf+qhXJ6GVkGEkg4UySKYrj6-A@mail.gmail.com>
References: <780A28F50E2834489278DD3B512FE7163ECBA0@CAQCCOHVEX01.corp.amayagaming.com>
 <CAN3um4wpyQhqUE-ERFA76cDQTf+qhXJ6GVkGEkg4UySKYrj6-A@mail.gmail.com>
Message-ID: <540AE58F-9D7A-4B30-82B7-11E884D2C989@turknet.net.tr>

Hi,

What is the pros and cons using Ethernet CFM&LMI or EBGP between PE-CE for link protection on ethernet based circuits. Currently, we are using EBGP when metro ethernet customers who want a backup link. But we are thinking about using CFM/E-LMI for fault management as CPE'es are more expensive  and reaction time depends on the BGP timers. With CFM/LMI it'is much more better but this time it results in another control plane protocol in the network. What are the current applications in your network?

Deniz AYDIN

________________________________

Bu elektronik posta ve onunla iletilen b?t?n dosyalar sadece g?ndericisi taraf?ndan almas? ama?lanan yetkili ger?ek ya da t?zel ki?inin kullan?m? i?indir. E?er s?z konusu yetkili al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? derhal silmeniz gerekmektedir. TurkNet bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan ve saklanmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler yaln?zca g?nderen ki?iye aittir ve TurkNet'in g?r??lerini yans?tmayabilir. Bu e-posta bilinen b?t?n bilgisayar vir?slerine kar?? taranm??t?r.
________________________________________
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TurkNet makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TurkNet. This e-mail has been scanned for all known computer viruses.

From jra at baylink.com  Thu Apr 18 15:50:57 2013
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 18 Apr 2013 11:50:57 -0400 (EDT)
Subject: someone from Sprint
In-Reply-To: <20130417205129.GA24183@vacation.karoshi.com.>
Message-ID: <24183712.2865.1366300257296.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: bmanning at vacation.karoshi.com

> your not alone... (Sprint is the upstream for this email)
> 
> The original message was received at Wed, 17 Apr 2013 14:21:10 GMT
> from localhost.localdomain [127.0.0.1]
> 
> ----- The following addresses had permanent fatal errors -----
> <Tom.A.Schiel at sprint.com>
> (reason: 501 5.5.4 Invalid domain name)

And that wasn't all; Sprint transparent proxies for their WiMAX 4g service 
were horking connections to Google and eBay (probably among others) for 
about half an hour, about an hour ago.

It was fun to get "No service configured at this address" from Google.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From bmanning at vacation.karoshi.com  Thu Apr 18 16:05:23 2013
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 18 Apr 2013 16:05:23 +0000
Subject: someone from Sprint
In-Reply-To: <24183712.2865.1366300257296.JavaMail.root@benjamin.baylink.com>
References: <20130417205129.GA24183@vacation.karoshi.com.>
 <24183712.2865.1366300257296.JavaMail.root@benjamin.baylink.com>
Message-ID: <20130418160523.GA31613@vacation.karoshi.com.>



 paging Softbank/Sony.....

/bill

On Thu, Apr 18, 2013 at 11:50:57AM -0400, Jay Ashworth wrote:
> ----- Original Message -----
> > From: bmanning at vacation.karoshi.com
> 
> > your not alone... (Sprint is the upstream for this email)
> > 
> > The original message was received at Wed, 17 Apr 2013 14:21:10 GMT
> > from localhost.localdomain [127.0.0.1]
> > 
> > ----- The following addresses had permanent fatal errors -----
> > <Tom.A.Schiel at sprint.com>
> > (reason: 501 5.5.4 Invalid domain name)
> 
> And that wasn't all; Sprint transparent proxies for their WiMAX 4g service 
> were horking connections to Google and eBay (probably among others) for 
> about half an hour, about an hour ago.
> 
> It was fun to get "No service configured at this address" from Google.  :-)
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA               #natog                      +1 727 647 1274


From Petter.Bruland at allegiantair.com  Thu Apr 18 16:20:18 2013
From: Petter.Bruland at allegiantair.com (Petter Bruland)
Date: Thu, 18 Apr 2013 16:20:18 +0000
Subject: Cross country point to point link question
Message-ID: <DC864220297BE047821E58CF67B23F6E6C03BAF8@SVIEXCMB01.allegiantair.com>

Question for someone with some experience with long haul links (Las Vegas -- New Jersey)

[Cisco 4510 - SVI-VLAN x]---trunk---[Nexus5K LH optic]===fiber==={carriers across country}===fiber===[Nexus5K LH optic]---trunk---[Cisco 4510 - SVI-VLAN x]

We have two circuits, one that is the same vendor from east to west, and the other circuit is a two vendor deal. Both circuits are 1 Gbps with around 67-70 ms delay.

As soon as we had the links turned up, our SAN guy started complaining about poor throughput, asking us to throw in a couple of wan accelerators.
He was seeing a max throughput of around ~200 Mbps.

Question: For a long haul 1 Gbps link with 67-70 ms delay, would  installing a pair of wan accelerators make a big difference? 

Thanks,
-Petter Bruland



From morrowc.lists at gmail.com  Thu Apr 18 16:26:17 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 18 Apr 2013 12:26:17 -0400
Subject: someone from Sprint
In-Reply-To: <51701a3b.0282320a.1ad9.ffff8f43SMTPIN_ADDED_BROKEN@mx.google.com>
References: <20130417205129.GA24183@vacation.karoshi.com.>
 <24183712.2865.1366300257296.JavaMail.root@benjamin.baylink.com>
 <51701a3b.0282320a.1ad9.ffff8f43SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAL9jLaYqWykW9J2SBUULvaNDjS_aujPH39-9-2fOLrf6OETxGQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 12:05 PM, <bmanning at vacation.karoshi.com> wrote:

>
>
>  paging Softbank/Sony.....
>

don't you mean ericsson? :)


>
> /bill
>
> On Thu, Apr 18, 2013 at 11:50:57AM -0400, Jay Ashworth wrote:
> > ----- Original Message -----
> > > From: bmanning at vacation.karoshi.com
> >
> > > your not alone... (Sprint is the upstream for this email)
> > >
> > > The original message was received at Wed, 17 Apr 2013 14:21:10 GMT
> > > from localhost.localdomain [127.0.0.1]
> > >
> > > ----- The following addresses had permanent fatal errors -----
> > > <Tom.A.Schiel at sprint.com>
> > > (reason: 501 5.5.4 Invalid domain name)
> >
> > And that wasn't all; Sprint transparent proxies for their WiMAX 4g
> service
> > were horking connections to Google and eBay (probably among others) for
> > about half an hour, about an hour ago.
> >
> > It was fun to get "No service configured at this address" from Google.
>  :-)
> >
> > Cheers,
> > -- jra
> > --
> > Jay R. Ashworth                  Baylink
> jra at baylink.com
> > Designer                     The Things I Think
> RFC 2100
> > Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> > St Petersburg FL USA               #natog                      +1 727
> 647 1274
>
>

From Vinny_Abello at Dell.com  Thu Apr 18 17:34:45 2013
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Thu, 18 Apr 2013 17:34:45 +0000
Subject: Cross country point to point link question
In-Reply-To: <DC864220297BE047821E58CF67B23F6E6C03BAF8@SVIEXCMB01.allegiantair.com>
References: <DC864220297BE047821E58CF67B23F6E6C03BAF8@SVIEXCMB01.allegiantair.com>
Message-ID: <FD9B2CB2B33E394FAE3B7466954760571D4FDD1E@DFWX10HMPTC01.AMER.DELL.COM>

Assuming you're doing FCoE or just iSCSI, you REALLY need to make sure your SAN vendor blesses something messing with packet headers on the SAN traffic. I don't think the caching mechanisms on the typical accelerator would help at all either. I somehow doubt they would support that unless they have their own solution. 

If you're just doing SMB or NFS or something similar then yes it would probably help overcome performance issues tied to latency quite a bit. But again, the magic is usually all tied to compression, TCP header modification and caching algorithms to local storage on each device.

-Vinny

-----Original Message-----
From: Petter Bruland [mailto:Petter.Bruland at allegiantair.com] 
Sent: Thursday, April 18, 2013 12:20 PM
To: nanog at nanog.org
Subject: Cross country point to point link question

Question for someone with some experience with long haul links (Las Vegas -- New Jersey)

[Cisco 4510 - SVI-VLAN x]---trunk---[Nexus5K LH optic]===fiber==={carriers across country}===fiber===[Nexus5K LH optic]---trunk---[Cisco 4510 - SVI-VLAN x]

We have two circuits, one that is the same vendor from east to west, and the other circuit is a two vendor deal. Both circuits are 1 Gbps with around 67-70 ms delay.

As soon as we had the links turned up, our SAN guy started complaining about poor throughput, asking us to throw in a couple of wan accelerators.
He was seeing a max throughput of around ~200 Mbps.

Question: For a long haul 1 Gbps link with 67-70 ms delay, would  installing a pair of wan accelerators make a big difference? 

Thanks,
-Petter Bruland




From drohan at gmail.com  Thu Apr 18 17:51:38 2013
From: drohan at gmail.com (Daniel Rohan)
Date: Thu, 18 Apr 2013 20:51:38 +0300
Subject: Cross country point to point link question
In-Reply-To: <DC864220297BE047821E58CF67B23F6E6C03BAF8@SVIEXCMB01.allegiantair.com>
References: <DC864220297BE047821E58CF67B23F6E6C03BAF8@SVIEXCMB01.allegiantair.com>
Message-ID: <CAJXc8RLDm7jcxE+VKRjQ_AGw781FNsAMzS7cFn4CU=meAB3CXw@mail.gmail.com>

Hi Petter,

Do you know if your SAN guy has already done the appropriate TCP window
size modifications to fill the pipe up?

Regardless, I am using WAN optimizers to do iSCSI storage replication
across a 230-320 ms 300 Mb shared pipe and have been extremely pleased with
the results. And the compression and caching works great. Of course, YMMV
depending on the nature of the payloads.

I wouldn't go as far as saying you need permission from your storage vendor
to do it, but you should at least ask if the data is encrypted or
compressed during native replication sessions. If yes (and if there is no
way to turn that off), then a WOC won't do you much good at all, as the
only major trick they'd have left is some TCP optimization, which of course
you can mostly do for free.

Feel free to contact me off list if you want to discuss particulars.

Best,

Dan



On Thu, Apr 18, 2013 at 7:20 PM, Petter Bruland <
Petter.Bruland at allegiantair.com> wrote:

> Question for someone with some experience with long haul links (Las Vegas
> -- New Jersey)
>
> [Cisco 4510 - SVI-VLAN x]---trunk---[Nexus5K LH optic]===fiber==={carriers
> across country}===fiber===[Nexus5K LH optic]---trunk---[Cisco 4510 -
> SVI-VLAN x]
>
> We have two circuits, one that is the same vendor from east to west, and
> the other circuit is a two vendor deal. Both circuits are 1 Gbps with
> around 67-70 ms delay.
>
> As soon as we had the links turned up, our SAN guy started complaining
> about poor throughput, asking us to throw in a couple of wan accelerators.
> He was seeing a max throughput of around ~200 Mbps.
>
> Question: For a long haul 1 Gbps link with 67-70 ms delay, would
>  installing a pair of wan accelerators make a big difference?
>
> Thanks,
> -Petter Bruland
>
>
>

From Petter.Bruland at allegiantair.com  Thu Apr 18 18:16:31 2013
From: Petter.Bruland at allegiantair.com (Petter Bruland)
Date: Thu, 18 Apr 2013 18:16:31 +0000
Subject: Cross country point to point link question :: THANKS
Message-ID: <DC864220297BE047821E58CF67B23F6E6C03BCE5@SVIEXCMB01.allegiantair.com>

Thanks everyone, I've gotten a lot of pointers off-list, and I have a good idea of our next few steps of verification.

-Petter

-----Original Message-----
From: Petter Bruland [mailto:Petter.Bruland at allegiantair.com] 
Sent: Thursday, April 18, 2013 9:20 AM
To: nanog at nanog.org
Subject: Cross country point to point link question

Question for someone with some experience with long haul links (Las Vegas -- New Jersey)

[Cisco 4510 - SVI-VLAN x]---trunk---[Nexus5K LH optic]===fiber==={carriers across country}===fiber===[Nexus5K LH optic]---trunk---[Cisco 4510 - SVI-VLAN x]

We have two circuits, one that is the same vendor from east to west, and the other circuit is a two vendor deal. Both circuits are 1 Gbps with around 67-70 ms delay.

As soon as we had the links turned up, our SAN guy started complaining about poor throughput, asking us to throw in a couple of wan accelerators.
He was seeing a max throughput of around ~200 Mbps.

Question: For a long haul 1 Gbps link with 67-70 ms delay, would  installing a pair of wan accelerators make a big difference? 

Thanks,
-Petter Bruland




From mehmet at akcin.net  Thu Apr 18 19:15:18 2013
From: mehmet at akcin.net (Mehmet Akcin)
Date: Thu, 18 Apr 2013 12:15:18 -0700
Subject: DNS Track at NANOG 58
Message-ID: <7CD727AC-DA98-498C-BB0B-6F5A9D9D7B91@akcin.net>

Greetings folks

Once again we will have DNS Track in NANOG.

There has been lots of recent DNS related discussions going on in many e-mail lists and I am quite sure there will be many great DNS talks in NANOG 58 just like in previous NANOGs.

DNS Track's goal is to bring together the audience who doesn't necessarily want to know all the details of a topic but would like to spend 90 mins listening quick updates from various DNS related subjects and get some crucial information and updates.

If you are interested in talking/presenting in the DNS Track and/or want to help me organize this Track in any way, please contact me off-list. Hopefully we can inform those who do NOT spend much time dealing with DNS about some topics they were not aware.

Once I know the details of the agenda such as time and date of the track, topics that will be covered, i will share this with you.

Mehmet




From fernando at gont.com.ar  Thu Apr 18 20:36:39 2013
From: fernando at gont.com.ar (Fernando Gont)
Date: Thu, 18 Apr 2013 15:36:39 -0500
Subject: SI6 Networks' IPv6 Toolkit v1.3.4 released!
Message-ID: <51705957.7030804@gont.com.ar>

Folks,

We have just released SI6 Networks' IPv6 Toolkit v1.3.4: a
security assessment and troubleshooting toolkit for the IPv6 protocol
suite.

The toolkit is available at:
<http://www.si6networks.com/tools/ipv6toolkit>, where you can find a
the usual tarball, a GPG-signed version of it, a link to the toolkit's
GIT repository, etc.

This release features:

   * IPv6-host tracking support in the scan6 tool.

   * A new tool, address6, to analyze IPv6 addresses

   * Minor bug fixes

The toolkit runs on (at least) the latest versions of Linux, FreeBSD,
NetBSD, OpenBSD, and MacOS.

Please send any bug reports and/or feature requests to
<fgont at si6networks.com>.

As always, you can get the latest news on IPv6 security research and
tools by following us on Twitter: @SI6Networks.

And if you're into IPv6 hacking, please consider joining the
ipv6hackers mailing list:
<http://www.si6networks.com/community/mailing-lists.html>.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From jrhett at netconsonance.com  Thu Apr 18 21:58:35 2013
From: jrhett at netconsonance.com (Jo Rhett)
Date: Thu, 18 Apr 2013 14:58:35 -0700
Subject: clueful colo hands in Cincinnati 
Message-ID: <844F05AB-39B9-4AF2-A644-548E96902F12@netconsonance.com>

$DAYJOB is in need of some clueful hands at a colocation in Cincinnati to regain IPMI access to some boxes there. Colo firm has no hands of any sort. Any clueful hands we can hire?

Respond offline, please.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

Author of Instant Puppet 3 Starter: http://www.netconsonance.com/instant-puppet-3-starter-book/


From pvg4w8r4 at gmail.com  Wed Apr 17 21:26:53 2013
From: pvg4w8r4 at gmail.com (Robert Yoder)
Date: Wed, 17 Apr 2013 15:26:53 -0600
Subject: GMAIL?
In-Reply-To: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>
References: <CAPWOC2nwpBz0quDt_wbMEeAjyHDmTgHJgG_MinbRb7tLekaVHw@mail.gmail.com>
Message-ID: <516F139D.6080705@gmail.com>

On 4/17/13 6:28 AM, Caio Alves wrote:
> Someone has access problems in GMAIL? Here in Brazil, many complaints about
> the service.
>

Google made a change so that the user account name must be just 
<MAILBOX>, and not <MAILBOX>@gmail.com.

Deleting the domain name fixed my account this morning.


ry
--


From bjorn at mork.no  Fri Apr 19 18:17:38 2013
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Fri, 19 Apr 2013 20:17:38 +0200
Subject: What do people use public suffix for?
In-Reply-To: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 (Jay Ashworth's message of "Mon, 15 Apr 2013 12:00:23 -0400 (EDT)")
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
Message-ID: <8738umqta5.fsf@nemi.mork.no>

Jay Ashworth <jra at baylink.com> writes:

> ----- Original Message -----
>> From: "John Levine" <johnl at iecc.com>
>
>> The public suffix list contains points in the DNS where (roughly
>> speaking) names below that point are under different management from
>> each other and from that name. It's here: http://publicsuffix.org/
>> 
>> The idea is that abc.foo.com and xyz.foo.com have the same management,
>> but abc.co.uk and xyz.co.uk do not.
>> 
>> You don't have to tell me that it's a gross crock, but it seems to
>> be a useful one. What do people use it for? Here's what I know of:
>> 
>> * Web browsers use it to manage cookies to keep a site from putting
>> cookies that will affect other sites, e.g. abc.foo.co.uk can set a
>> cookie for foo.co.uk but not for co.uk.
>> 
>> * DMARC (www.dmarc.org) uses it to find a policy record in the DNS
>> that describes a subtree, e.g., if you get mail that purports to be
>> from eBay at reply1.ebay.com it checks the policy at ebay.com.
>> 
>> What other current applications are there?
>
> Seems to me that it's a crock because *it should be in the DNS*.

It is already, isn't it?  The NS and SOA records will tell you all there
is to know about zone splits and cross zone relations.

> I should be able to retrieve the AS (administrative split) record 
> for .co.uk, and there should be one that says, "yup, there's an
> administrative split below me; nothing under there is mine unless 
> you also get an exception record for a subdomain".

Use the SOA record.  If it is identical for two zones, then the
adminstrative authority for those zones is the same.

For example, "microsoft.co.uk" and "microsoft.com" can be considered
under the same administration:

 bjorn at nemi:~$ dig +short soa microsoft.co.uk 
 ns1.msft.net. msnhst.microsoft.com. 2013032601 1800 900 2419200 3600
 bjorn at nemi:~$ dig +short soa microsoft.com
 ns1.msft.net. msnhst.microsoft.com. 2013041803 300 600 2419200 3600

While "apple.co.uk" and "apple.com" may be, depending on how strict you
are going to be when comparing:

 bjorn at nemi:~$ dig +short soa apple.co.uk 
 nserver.euro.apple.com. hostmaster.apple.com. 10 1800 900 2592000 1800
 bjorn at nemi:~$ dig +short soa apple.com
 gridmaster-ib.apple.com. hostmaster.apple.com. 2010086586 1800 900 2016000 86500


etc.


Bj?rn


From cscora at apnic.net  Fri Apr 19 18:33:20 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 20 Apr 2013 04:33:20 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201304191833.r3JIXKeL012301@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 20 Apr, 2013

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

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

BGP routing table entries examined:                              450189
    Prefixes after maximum aggregation:                          184599
    Deaggregation factor:                                          2.44
    Unique aggregates announced to Internet:                     222556
Total ASes present in the Internet Routing Table:                 43876
    Prefixes per ASN:                                             10.26
Origin-only ASes present in the Internet Routing Table:           34506
Origin ASes announcing only one prefix:                           16073
Transit ASes present in the Internet Routing Table:                5787
Transit-only ASes present in the Internet Routing Table:            142
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      29
    Max AS path prepend of ASN ( 19037)                              22
Prefixes from unregistered ASNs in the Routing Table:               358
    Unregistered ASNs in the Routing Table:                         132
Number of 32-bit ASNs allocated by the RIRs:                       4729
Number of 32-bit ASNs visible in the Routing Table:                3583
Prefixes from 32-bit ASNs in the Routing Table:                   10155
Special use prefixes present in the Routing Table:                   22
Prefixes being announced from unallocated address space:            220
Number of addresses announced to Internet:                   2613629004
    Equivalent to 155 /8s, 200 /16s and 208 /24s
    Percentage of available address space announced:               70.6
    Percentage of allocated address space announced:               70.6
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               94.4
Total number of prefixes smaller than registry allocations:      158679

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

Prefixes being announced by APNIC Region ASes:                   108086
    Total APNIC prefixes after maximum aggregation:               33445
    APNIC Deaggregation factor:                                    3.23
Prefixes being announced from the APNIC address blocks:          109312
    Unique aggregates announced from the APNIC address blocks:    44563
APNIC Region origin ASes present in the Internet Routing Table:    4821
    APNIC Prefixes per ASN:                                       22.67
APNIC Region origin ASes announcing only one prefix:               1215
APNIC Region transit ASes present in the Internet Routing Table:    818
Average APNIC Region AS path length visible:                        4.8
    Max APNIC Region AS path length visible:                         22
Number of APNIC region 32-bit ASNs visible in the Routing Table:    500
Number of APNIC addresses announced to Internet:              720782272
    Equivalent to 42 /8s, 246 /16s and 67 /24s
    Percentage of available APNIC address space announced:         84.2

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 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:                    158276
    Total ARIN prefixes after maximum aggregation:                79767
    ARIN Deaggregation factor:                                     1.98
Prefixes being announced from the ARIN address blocks:           158919
    Unique aggregates announced from the ARIN address blocks:     72644
ARIN Region origin ASes present in the Internet Routing Table:    15649
    ARIN Prefixes per ASN:                                        10.16
ARIN Region origin ASes announcing only one prefix:                5959
ARIN Region transit ASes present in the Internet Routing Table:    1615
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:      18
Number of ARIN addresses announced to Internet:              1062822272
    Equivalent to 63 /8s, 89 /16s and 97 /24s
    Percentage of available ARIN address space announced:          56.2

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 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:                    116470
    Total RIPE prefixes after maximum aggregation:                59453
    RIPE Deaggregation factor:                                     1.96
Prefixes being announced from the RIPE address blocks:           120053
    Unique aggregates announced from the RIPE address blocks:     77159
RIPE Region origin ASes present in the Internet Routing Table:    17133
    RIPE Prefixes per ASN:                                         7.01
RIPE Region origin ASes announcing only one prefix:                8152
RIPE Region transit ASes present in the Internet Routing Table:    2788
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          29
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2302
Number of RIPE addresses announced to Internet:               656501988
    Equivalent to 39 /8s, 33 /16s and 108 /24s
    Percentage of available RIPE address space announced:          95.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 196608-199679
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:                   46912
    Total LACNIC prefixes after maximum aggregation:               9395
    LACNIC Deaggregation factor:                                   4.99
Prefixes being announced from the LACNIC address blocks:          50936
    Unique aggregates announced from the LACNIC address blocks:   24154
LACNIC Region origin ASes present in the Internet Routing Table:   1903
    LACNIC Prefixes per ASN:                                      26.77
LACNIC Region origin ASes announcing only one prefix:               561
LACNIC Region transit ASes present in the Internet Routing Table:   355
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        29
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   756
Number of LACNIC addresses announced to Internet:             126871336
    Equivalent to 7 /8s, 143 /16s and 231 /24s
    Percentage of available LACNIC address space announced:        75.6

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

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

Prefixes being announced by AfriNIC Region ASes:                  10162
    Total AfriNIC prefixes after maximum aggregation:              2491
    AfriNIC Deaggregation factor:                                  4.08
Prefixes being announced from the AfriNIC address blocks:         10749
    Unique aggregates announced from the AfriNIC address blocks:   3831
AfriNIC Region origin ASes present in the Internet Routing Table:   617
    AfriNIC Prefixes per ASN:                                     17.42
AfriNIC Region origin ASes announcing only one prefix:              186
AfriNIC Region transit ASes present in the Internet Routing Table:  129
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    7
Number of AfriNIC addresses announced to Internet:             46191872
    Equivalent to 2 /8s, 192 /16s and 213 /24s
    Percentage of available AfriNIC address space announced:       45.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
 4766     2952      11557         922   Korea Telecom (KIX)
17974     2514        839          90   PT TELEKOMUNIKASI INDONESIA
 7545     1887        320         109   TPG Internet Pty Ltd
 4755     1738        392         198   TATA Communications formerly 
 9829     1509       1205          40   BSNL National Internet Backbo
 9583     1285         98         538   Sify Limited
 7552     1170       1064          12   Vietel Corporation
 4808     1107       2109         325   CNCGROUP IP network: China169
 9498     1078        310          73   BHARTI Airtel Ltd.
24560     1067        385         164   Bharti Airtel Ltd., Telemedia

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3037       3694          87   bellsouth.net, inc. 
 7029     2173       1265         212   Windstream Communications Inc
18566     2067        382         184   Covad Communications 
22773     1983       2929         125   Cox Communications, Inc.
 1785     1974        677         122   PaeTec Communications, Inc.
20115     1669       1612         612   Charter Communications 
 4323     1609       1139         398   Time Warner Telecom
30036     1344        297         657   Mediacom Communications Corp 
 7018     1315      10807         854   AT&T WorldNet Services
11492     1239        228         330   Cable One 

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1793        544          16   Corbina telecom
 2118     1430         97          13   EUnet/RELCOM Autonomous Syste
34984     1152        235         206   BILISIM TELEKOM
13188      875         99          39   Educational Network
12479      844        786          66   Uni2 Autonomous System
20940      819        286         652   Akamai Technologies European 
31148      794         41          22   FreeNet ISP
 6830      753       2318         440   UPC Distribution Services
 8551      676        370          43   Bezeq International
58113      666         74         386   LIR DATACENTER TELECOM SRL

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
28573     2620       1451          99   NET Servicos de Comunicao S.A
10620     2374        411         217   TVCABLE BOGOTA 
 7303     1676       1153         211   Telecom Argentina Stet-France
 8151     1234       2690         394   UniNet S.A. de C.V. 
 6503     1067        435          68   AVANTEL, S.A. 
18881      859        717          19   Global Village Telecom 
27947      808         88          96   Telconet S.A
11830      725        364          14   Instituto Costarricense de El
 3816      696        306          85   Empresa Nacional de Telecomun
 7738      650       1306          35   Telecomunicacoes da Bahia 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
36998     1137         80           4   MOBITEL
24863      695        274          33   LINKdotNET AS number
 6713      542        617          25   Itissalat Al-MAGHRIB
 8452      361        956           9   TEDATA
24835      275         80           8   RAYA Telecom - Egypt
 3741      261        906         220   The Internet Solution 
12258      193         28          67   Vodacom Internet Company 
29975      191        667          21   Vodacom
16637      187        697          91   MTN Network Solutions
33776      182         12          19   Starcomms Nigeria Limited

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

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3037       3694          87   bellsouth.net, inc. 
 4766     2952      11557         922   Korea Telecom (KIX)
28573     2620       1451          99   NET Servicos de Comunicao S.A
17974     2514        839          90   PT TELEKOMUNIKASI INDONESIA
10620     2374        411         217   TVCABLE BOGOTA 
 7029     2173       1265         212   Windstream Communications Inc
18566     2067        382         184   Covad Communications 
22773     1983       2929         125   Cox Communications, Inc.
 1785     1974        677         122   PaeTec Communications, Inc.
 7545     1887        320         109   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
28573      2620        2521      NET Servicos de Comunicao S.A
17974      2514        2424      PT TELEKOMUNIKASI INDONESIA
10620      2374        2157      TVCABLE BOGOTA 
 4766      2952        2030      Korea Telecom (KIX)
 7029      2173        1961      Windstream Communications Inc
18566      2067        1883      Covad Communications 
22773      1983        1858      Cox Communications, Inc.
 1785      1974        1852      PaeTec Communications, Inc.
 7545      1887        1778      TPG Internet Pty Ltd
 8402      1793        1777      Corbina telecom

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

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

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
30031   UNALLOCATED  12.27.122.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24         209       Qwest 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic
33649   UNALLOCATED  12.111.112.0/24      19029       New Edge Networks 
26064   UNALLOCATED  12.149.37.0/24        7018       AT&T WorldNet Servic

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

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

Prefix             Origin AS  Description
128.0.0.0/24          2876     Jump Management SRL
128.0.16.0/21        43568     RIPE Network Coordination Cen
128.0.24.0/21        41794     Altline LLC
128.0.55.0/24        48571     SC efectRO SRL
128.0.58.0/23         9050     RTD-ROMTELECOM Autonomous Sys
128.0.60.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.61.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.62.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.63.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.72.0/21        23456     32-bit ASN transition

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

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

Network            Origin AS  Description
41.222.80.0/21       37110     Moztel LDA
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 
64.185.224.0/24      27431     JTL Networks Inc.
64.185.225.0/24      27431     JTL Networks Inc.
64.185.226.0/24      27431     JTL Networks Inc.
64.185.227.0/24      27431     JTL Networks Inc.
64.185.228.0/24      27431     JTL Networks Inc.
64.185.229.0/24      27431     JTL Networks Inc.
64.185.230.0/24      27431     JTL Networks 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:29      /11:88      /12:249     
/13:485     /14:884     /15:1562    /16:12691   /17:6597    /18:10920   
/19:21837   /20:31936   /21:33796   /22:46730   /23:41690   /24:236619  
/25:1366    /26:1666    /27:861     /28:44      /29:69      /30:22      
/31:0       /32:19      

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

  ASN   No of nets  Total ann.   Description
18566     2018          2067      Covad Communications 
 6389     1741          3037      bellsouth.net, inc. 
 7029     1611          2173      Windstream Communications Inc
 8402     1497          1793      Corbina telecom
22773     1291          1983      Cox Communications, Inc.
30036     1219          1344      Mediacom Communications Corp 
11492     1198          1239      Cable One 
36998     1131          1137      MOBITEL
 1785     1047          1974      PaeTec Communications, Inc.
 6983     1006          1134      ITC^Deltacom 

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

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

   1:774       2:750       3:3         4:15        5:863       6:5      
   8:542      12:1916     13:3        14:772      15:11       16:3      
  17:9        20:18       23:271      24:1769     27:1468     31:1214   
  32:43       33:2        34:5        36:44       37:1816     38:862    
  39:2        40:169      41:2683     42:178      44:6        46:1797   
  47:2        49:625      50:676      52:12       54:30       55:6      
  57:27       58:1140     59:589      60:306      61:1458     62:1037   
  63:2054     64:4309     65:2182     66:4327     67:2076     68:1127   
  69:3243     70:872      71:532      72:1956     74:2575     75:414    
  76:295      77:1103     78:1057     79:571      80:1233     81:983    
  82:606      83:569      84:515      85:1162     86:464      87:972    
  88:527      89:1798     90:281      91:5481     92:622      93:1712   
  94:1846     95:1726     96:517      97:342      98:1053     99:41     
 100:29      101:315     103:2476    105:488     106:143     107:206    
 108:515     109:1832    110:861     111:1053    112:505     113:785    
 114:694     115:1014    116:877     117:799     118:1026    119:1273   
 120:397     121:824     122:1741    123:1195    124:1333    125:1269   
 128:632     129:223     130:323     131:653     132:340     133:149    
 134:260     135:64      136:223     137:247     138:343     139:186    
 140:199     141:317     142:542     143:374     144:486     145:91     
 146:503     147:384     148:695     149:369     150:163     151:527    
 152:419     153:194     154:44      155:391     156:262     157:394    
 158:269     159:722     160:338     161:425     162:385     163:202    
 164:584     165:448     166:335     167:577     168:1030    169:133    
 170:1024    171:174     172:5       173:1608    174:589     175:455    
 176:1248    177:1858    178:1824    179:3       180:1402    181:386    
 182:1138    183:372     184:665     185:378     186:2310    187:1270   
 188:2019    189:1310    190:6098    192:6520    193:5830    194:4655   
 195:3484    196:1327    197:831     198:4333    199:5292    200:5919   
 201:2370    202:8870    203:8758    204:4523    205:2554    206:2822   
 207:2834    208:4073    209:3580    210:2943    211:1566    212:2027   
 213:1899    214:919     215:98      216:5192    217:1558    218:619    
 219:346     220:1273    221:548     222:313     223:448    

End of report


From jabley at hopcount.ca  Fri Apr 19 18:58:19 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Fri, 19 Apr 2013 14:58:19 -0400
Subject: What do people use public suffix for?
In-Reply-To: <8738umqta5.fsf@nemi.mork.no>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
Message-ID: <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>


On 2013-04-19, at 14:17, Bj?rn Mork <bjorn at mork.no> wrote:

> It is already, isn't it?  The NS and SOA records will tell you all there
> is to know about zone splits and cross zone relations.

Not really.

In general, just because a zone is served by the same nameservers as another zone doesn't mean that they are administratively equivalent (e.g. for cookie hygiene purposes).

Just because two zones are served on different nameservers doesn't mean they are administratively separate. Lots of administratively-separate domains share the same nameservers.

Drawing related conclusions from similarity of SOA RDATA between zones, or the number of zone cuts between a particular zone and the root, or the number of labels in a domain name is similarly flawed.

If the rule was just "the nameservers need to be the same and the SOA RDATA needs to be the same, for some well-documented meaning of 'same'" then gaming that rule (e.g. for purposes of cookie injection) as a miscreant is unpleasantly straightforward.


Joe



From dot at dotat.at  Fri Apr 19 19:57:36 2013
From: dot at dotat.at (Tony Finch)
Date: Fri, 19 Apr 2013 20:57:36 +0100
Subject: What do people use public suffix for?
In-Reply-To: <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
Message-ID: <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>

Joe Abley <jabley at hopcount.ca> wrote:
>
> If the rule was just "the nameservers need to be the same and the SOA
> RDATA needs to be the same, for some well-documented meaning of 'same'"
> then gaming that rule (e.g. for purposes of cookie injection) as a
> miscreant is unpleasantly straightforward.

To reinforce Joe's point, there doesn't even need to be a zone cut for
there to be an administrative cut. There are various ISPs and dynamic DNS
providers that put all their users in the same zone, and the common suffix
of a zone like this should be treated as public suffix even though there
is no zone cut.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.


From dhc2 at dcrocker.net  Fri Apr 19 20:49:33 2013
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Fri, 19 Apr 2013 13:49:33 -0700
Subject: What do people use public suffix for?
In-Reply-To: <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
 <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
Message-ID: <5171ADDD.8070205@dcrocker.net>



On 4/19/2013 12:57 PM, Tony Finch wrote:
> To reinforce Joe's point, there doesn't even need to be a zone cut for
> there to be an administrative cut. There are various ISPs and dynamic DNS
> providers that put all their users in the same zone, and the common suffix
> of a zone like this should be treated as public suffix even though there
> is no zone cut.


Zones are nice constructs for partitioning operational management of DNS 
data, but I believe they were not intended to impart semantics about 
organizational boundaries.

The fact that they often correlate moderately well makes it easy to miss 
the facts that a) that's not their job, and b) the correlation isn't 
perfect.  And the imperfections matter.

That is why there is the current interest in developing a cheap, 
accurate method that /is/ intended to define organizational boundaries.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


From cidr-report at potaroo.net  Fri Apr 19 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 19 Apr 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201304192200.r3JM00xb090311@wattle.apnic.net>

This report has been generated at Fri Apr 19 21:13:18 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        12-04-13    452468      259891
        13-04-13    452722      260158
        14-04-13    452855      259735
        15-04-13    452981      259914
        16-04-13    453089      260043
        17-04-13    452364      260094
        18-04-13    452245      260759
        19-04-13    452740      260944


AS Summary
         44002  Number of ASes in routing system
         18232  Number of ASes announcing only one prefix
          3037  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      116992736  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 19Apr13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     452863   260867   191996    42.4%   All ASes

AS6389      3037       91     2946    97.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2952      938     2014    68.2%   KIXS-AS-KR Korea Telecom
AS17974     2514      570     1944    77.3%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS28573     2629      787     1842    70.1%   NET Servi?os de Comunica??o
                                               S.A.
AS22773     1984      197     1787    90.1%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS18566     2067      473     1594    77.1%   COVAD - Covad Communications
                                               Co.
AS2118      1430       49     1381    96.6%   RELCOM-AS OOO "NPO Relcom"
AS7303      1676      449     1227    73.2%   Telecom Argentina S.A.
AS4323      1612      402     1210    75.1%   TWTC - tw telecom holdings,
                                               inc.
AS10620     2374     1252     1122    47.3%   Telmex Colombia S.A.
AS4755      1738      643     1095    63.0%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1170      198      972    83.1%   VIETEL-AS-AP Vietel
                                               Corporation
AS7029      2173     1240      933    42.9%   WINDSTREAM - Windstream
                                               Communications Inc
AS18881      859       21      838    97.6%   Global Village Telecom
AS18101     1001      179      822    82.1%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS36998     1137      382      755    66.4%   SDN-MOBITEL
AS1785      1974     1226      748    37.9%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4808      1107      367      740    66.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS13977      839      130      709    84.5%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS855        737       54      683    92.7%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS6983      1134      482      652    57.5%   ITCDELTA - ITC^Deltacom
AS8151      1243      607      636    51.2%   Uninet S.A. de C.V.
AS22561     1085      454      631    58.2%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      730      108      622    85.2%   GIGAINFRA Softbank BB Corp.
AS24560     1067      447      620    58.1%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS3549      1055      446      609    57.7%   GBLX Global Crossing Ltd.
AS34744      656       51      605    92.2%   GVM S.C. GVM SISTEM 2003
                                               S.R.L.
AS3356      1090      494      596    54.7%   LEVEL3 Level 3 Communications
AS17908      793      197      596    75.2%   TCISL Tata Communications
AS19262      999      403      596    59.7%   VZGNI-TRANSIT - Verizon Online
                                               LLC

Total      44862    13337    31525    70.3%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.80.0/21       AS37110 moztel-as
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.187.208.0/24      AS174   COGENT Cogent/PSI
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS30097 NUWAVE - NuWave
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.91.48.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.49.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.50.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.51.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.52.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.53.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.54.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.55.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.56.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.57.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.58.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.59.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.60.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.61.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.62.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.91.63.0/24        AS30137 SEA-BROADBAND - Sea Broadband, LLC
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        81.22.64.0/20        AS5511  OPENTRANSIT France Telecom S.A.
        82.101.160.0/19      AS5511  OPENTRANSIT France Telecom S.A.
        91.197.36.0/22       AS43359 
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        164.138.97.0/24      AS58101 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        177.67.69.0/24       AS26251 FUNDACAO JOAO PAULO II
        185.24.112.0/22      AS38917 KOMTEL-AS INTERCOMTEL Limited Company
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.52.192.0/24      AS27919 
        190.52.193.0/24      AS27919 
        190.52.194.0/24      AS27919 
        190.52.195.0/24      AS27919 
        190.52.196.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.197.0/24      AS27919 
        190.52.198.0/24      AS27919 
        190.52.199.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.200.0/24      AS27947 Telconet S.A
        190.52.201.0/24      AS27947 Telconet S.A
        190.52.202.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.203.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.205.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.206.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.207.0/24      AS3549  GBLX Global Crossing Ltd.
        190.111.96.0/20      AS27589 MOJOHOST - MOJOHOST
        190.111.128.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.144.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.160.0/20     AS27589 MOJOHOST - MOJOHOST
        190.111.176.0/20     AS27589 MOJOHOST - MOJOHOST
        190.115.64.0/20      AS27589 MOJOHOST - MOJOHOST
        190.115.80.0/20      AS27589 MOJOHOST - MOJOHOST
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        191.255.0.0/16       AS6983  ITCDELTA - ITC^Deltacom
        195.177.244.0/23     AS29444 
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.53.0.0/19        AS22011 Metro Net, S.A.P.I. de C.V.
        200.58.248.0/21      AS27849 
        200.107.248.0/24     AS27919 
        200.107.249.0/24     AS27919 
        200.107.250.0/24     AS27919 
        200.107.251.0/24     AS27919 
        200.107.252.0/24     AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
        201.71.16.0/20       AS28638 
        201.77.96.0/20       AS28639 
        201.222.32.0/20      AS27821 
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.58.113.0/24      AS19161 
        202.65.96.0/20       AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.73.240.0/20      AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.10.112.0/21      AS27027 ANBELL ASN-ANBELL
        204.11.112.0/22      AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.91.72.0/24       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        213.150.204.0/24     AS29338 AFOL-AS Used by Africaonline Operations
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Apr 19 22:00:01 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 19 Apr 2013 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201304192200.r3JM01uK090330@wattle.apnic.net>

BGP Update Report
Interval: 11-Apr-13 -to- 18-Apr-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS47331           72724  3.2%      35.3 -- TTNET TTNet A.S.
 2 - AS58113           67954  3.0%     102.0 -- LIR-AS LIR DATACENTER TELECOM SRL
 3 - AS9829            61658  2.8%      74.6 -- BSNL-NIB National Internet Backbone
 4 - AS8402            39683  1.8%      35.6 -- CORBINA-AS OJSC "Vimpelcom"
 5 - AS3909            25132  1.1%    6283.0 -- QWEST-AS-3908 - Qwest Communications Company, LLC
 6 - AS2708            18314  0.8%     231.8 -- Universidad de Guanajuato
 7 - AS36998           16814  0.8%      24.2 -- SDN-MOBITEL
 8 - AS24863           15868  0.7%      27.5 -- LINKdotNET-AS
 9 - AS28573           15560  0.7%      10.3 -- NET Servi?os de Comunica??o S.A.
10 - AS34984           15326  0.7%      21.1 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.
11 - AS33776           14457  0.7%     116.6 -- STARCOMMS-ASN
12 - AS21947           13698  0.6%    1956.9 -- TRANSARIA - TransAria, Inc.
13 - AS17974           13486  0.6%      10.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
14 - AS6713            13478  0.6%      25.3 -- IAM-AS
15 - AS8551            13196  0.6%      17.0 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone
16 - AS4538            12952  0.6%      27.6 -- ERX-CERNET-BKB China Education and Research Network Center
17 - AS27738           12662  0.6%      22.3 -- Ecuadortelecom S.A.
18 - AS2118            12473  0.6%       8.8 -- RELCOM-AS OOO "NPO Relcom"
19 - AS29049           11133  0.5%      32.9 -- DELTA-TELECOM-AS Delta Telecom LTD.
20 - AS22561           10874  0.5%      57.5 -- DIGITAL-TELEPORT - Digital Teleport Inc.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6629             7384  0.3%    7384.0 -- NOAA-AS - NOAA
 2 - AS10987            6953  0.3%    6953.0 -- PLUMCREEK-AS - Plum Creek Marketing, Inc.
 3 - AS33521            6660  0.3%    6660.0 -- MSLA-SCHOOLS - Missoula County Public Schools
 4 - AS3909            25132  1.1%    6283.0 -- QWEST-AS-3908 - Qwest Communications Company, LLC
 5 - AS19406            4161  0.2%    4161.0 -- TWRS-MA - Towerstream I, Inc.
 6 - AS53168            4066  0.2%    4066.0 -- CIA ESTADUAL DE GERA??O E TRANSMISS?O DE ENERGIA E
 7 - AS6174             5682  0.2%    2841.0 -- SPRINTLINK8 - Sprint
 8 - AS14680            6894  0.3%    2298.0 -- REALE-6 - Auction.com
 9 - AS21947           13698  0.6%    1956.9 -- TRANSARIA - TransAria, Inc.
10 - AS48612            8605  0.4%    1229.3 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
11 - AS37367            2377  0.1%    1188.5 -- CALLKEY
12 - AS5074             2376  0.1%    1188.0 -- ASN-ATTELS - AT&T BMGS
13 - AS9950             3468  0.2%    1156.0 -- PUBNETPLUS2-AS-KR DACOM
14 - AS4467             1122  0.1%    1122.0 -- EASYLINK3 - AT&T Services, Inc.
15 - AS42860            1021  0.1%    1021.0 -- EFT Energy Financing Team (Switzerland) AG
16 - AS55062             991  0.0%     991.0 -- GSC-MINNEAPOLISMN - Gannett Supply Corp. - Minneapolis, MN
17 - AS22216            7505  0.3%     750.5 -- SIEMENS-PLM - Siemens Corporation
18 - AS23295             750  0.0%     750.0 -- EA-01 - Extend America
19 - AS17293            2933  0.1%     733.2 -- VTXC - VTX Communications
20 - AS17783             961  0.0%     480.5 -- SRILRPG-AS SRIL RPG Autonomous System


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 209.142.140.0/24   9691  0.4%   AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc.
 2 - 92.246.207.0/24    8589  0.4%   AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
 3 - 193.19.90.0/23     8448  0.3%   AS25233 -- AWALNET-ASN Arab Company For Internet & Communications Services (AwalNet)LLC
                                     AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet
 4 - 151.118.18.0/24    7549  0.3%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 5 - 151.118.255.0/24   7520  0.3%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 6 - 151.118.254.0/24   7520  0.3%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 7 - 192.58.232.0/24    7384  0.3%   AS6629  -- NOAA-AS - NOAA
 8 - 209.200.208.0/24   6987  0.3%   AS21947 -- TRANSARIA - TransAria, Inc.
 9 - 199.0.244.0/22     6953  0.3%   AS10987 -- PLUMCREEK-AS - Plum Creek Marketing, Inc.
10 - 69.165.112.0/20    6676  0.3%   AS21947 -- TRANSARIA - TransAria, Inc.
11 - 64.25.130.0/24     6660  0.3%   AS33521 -- MSLA-SCHOOLS - Missoula County Public Schools
12 - 12.139.133.0/24    5612  0.2%   AS14680 -- REALE-6 - Auction.com
13 - 202.41.70.0/24     5004  0.2%   AS2697  -- ERX-ERNET-AS Education and Research Network
14 - 194.63.9.0/24      4682  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
15 - 69.38.178.0/24     4161  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
16 - 186.219.192.0/20   4066  0.2%   AS53168 -- CIA ESTADUAL DE GERA??O E TRANSMISS?O DE ENERGIA E
17 - 58.184.229.0/24    3392  0.1%   AS9950  -- PUBNETPLUS2-AS-KR DACOM
18 - 2.93.235.0/24      2858  0.1%   AS8402  -- CORBINA-AS OJSC "Vimpelcom"
19 - 206.105.75.0/24    2841  0.1%   AS6174  -- SPRINTLINK8 - Sprint
20 - 208.16.110.0/24    2841  0.1%   AS6174  -- SPRINTLINK8 - Sprint

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From mysidia at gmail.com  Fri Apr 19 23:33:25 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 19 Apr 2013 18:33:25 -0500
Subject: What do people use public suffix for?
In-Reply-To: <5171ADDD.8070205@dcrocker.net>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
 <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
 <5171ADDD.8070205@dcrocker.net>
Message-ID: <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>

On 4/19/13, Dave Crocker <dhc2 at dcrocker.net> wrote:
> On 4/19/2013 12:57 PM, Tony Finch wrote:
>> To reinforce Joe's point, there doesn't even need to be a zone cut for
>> there to be an administrative cut. There are various ISPs and dynamic DNS
>> providers that put all their users in the same zone, and the common
[snip]

In this case, there really is no administrative cut though... the
provider administers the DNS record.

> The fact that they often correlate moderately well makes it easy to miss
> the facts that a) that's not their job, and b) the correlation isn't
> perfect.  And the imperfections matter.

> That is why there is the current interest in developing a cheap,
> accurate method that /is/ intended to define organizational boundaries.


It seems this is more about providing a security function to DNS, to
inform the public, about where the responsible parties change.

The right place for this, is clearly the  DNSSEC extensions....

If  the DS record identifies a different signer, then you have an
administrative split,
or if the e-mail address field in the SOA fields of the parent zone
are different, then you have an administrative split, OR if one of the
two zones has  RP (responsible party records),  and the list of RP
records are different for the two zones, then you have an
administrative split.


If the DS record identifies the same signer, AND    the    e-mail
address in the SOA records is the same;  or the  list of e-mail
addresses in the two zones'   RP records are identical,
then you don't have an administrative split.


--
-JH


From johnl at iecc.com  Sat Apr 20 01:09:21 2013
From: johnl at iecc.com (John Levine)
Date: 20 Apr 2013 01:09:21 -0000
Subject: What do people use public suffix for?
In-Reply-To: <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>
Message-ID: <20130420010921.90573.qmail@joyce.lan>

>If  the DS record identifies a different signer, then you have an
>administrative split,
>or if the e-mail address field in the SOA fields of the parent zone
>are different, then you have an administrative split, OR if one of the
>two zones has  RP (responsible party records),  and the list of RP
>records are different for the two zones, then you have an
>administrative split.

Sigh.  See messages from about an hour ago about why zone cuts aren't
the same as management boundaries.  Sprinking DNSSEC pixie dust on the
zone cuts doesn't change that.



From dhc2 at dcrocker.net  Sat Apr 20 01:17:14 2013
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Fri, 19 Apr 2013 18:17:14 -0700
Subject: What do people use public suffix for?
In-Reply-To: <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
 <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
 <5171ADDD.8070205@dcrocker.net>
 <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>
Message-ID: <5171EC9A.9080404@dcrocker.net>


On 4/19/2013 4:33 PM, Jimmy Hess wrote:
> It seems this is more about providing a security function to DNS, to
> inform the public, about where the responsible parties change.


Absent a view that somehow says all metadata is a security function, I 
don't see how the marking of administrative boundaries qualifies as a 
security function.

It's easy to imagine security functions that are 'in support of' the 
enforcement of the boundaries, but that's quite different from having an 
annotation mechanism to assert the boundaries.

Let's be careful not to overload functions here.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


From mysidia at gmail.com  Sat Apr 20 02:58:44 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 19 Apr 2013 21:58:44 -0500
Subject: What do people use public suffix for?
In-Reply-To: <5171EC9A.9080404@dcrocker.net>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
 <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
 <5171ADDD.8070205@dcrocker.net>
 <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>
 <5171EC9A.9080404@dcrocker.net>
Message-ID: <CAAAwwbWmGEeYEVF5mqS3HzU81VgKXF8eYE+CR8pXcM0XCrE7sw@mail.gmail.com>

On 4/19/13, Dave Crocker <dhc2 at dcrocker.net> wrote:
> On 4/19/2013 4:33 PM, Jimmy Hess wrote:
[snip]
> Absent a view that somehow says all metadata is a security function, I
> don't see how the marking of administrative boundaries qualifies as a
> security function.

The security function comes in immediately, when you consider any
actual uses for said kind of metadata.

The issues are alleviated only by assuming that an administrative
division always exists, unless you can show otherwise,   and showing
that the records are in the same zone is one way of showing otherwise.


When you come to rely on it, there are new security issues.

It becomes such that;   It   is perfectly safe to assume that there is
an administrative division when there is not   (in the worst case, you
break some desired function, such as the sharing of cookies  across
subdomains within the same administrative boundary).

But if you assume no administrative division exists, when there is
supposed to be one -- you have some kind of access control permit
leakage or data leaking through permissions that are supposed to block
operations across the administrative boundaries.


Only a zone signed with DNSSEC can really be trusted not to be
tampered with;  therefore,  any declaration of an administrative
division cannot be proven, and should not be relied upon,  if   any
parent zone up the tree is not signed with delegation validated using
signed records.



> Let's be careful not to overload functions here.

The function becomes pretty useless,  if you cannot safely rely on it
in the real world.
Because tampering can occur through lack of integrity validation,

Or by a child domain claiming to not be administratively divided (when
actually, there is supposed to be an administrative division).


In those cases,  a static list is safer.



> d/
--
-JH


From dhc2 at dcrocker.net  Sat Apr 20 03:19:04 2013
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Fri, 19 Apr 2013 20:19:04 -0700
Subject: What do people use public suffix for?
In-Reply-To: <CAAAwwbWmGEeYEVF5mqS3HzU81VgKXF8eYE+CR8pXcM0XCrE7sw@mail.gmail.com>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
 <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
 <5171ADDD.8070205@dcrocker.net>
 <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>
 <5171EC9A.9080404@dcrocker.net>
 <CAAAwwbWmGEeYEVF5mqS3HzU81VgKXF8eYE+CR8pXcM0XCrE7sw@mail.gmail.com>
Message-ID: <51720928.2010507@dcrocker.net>

1. Explicitly marking an administrative boundary is not inherently a 
'security' function, although properly authorizing and protecting the 
marking no doubt would be.

2. Defining a marking mechanism that is built into a security mechanism 
that is designed for other purposes is overloading functionality, as 
well as setting up a problematic critical dependency.  That's not just 
asking for trouble, it's guaranteeing it.

3. Since you made reference to assumptions a couple of times: the goal 
here is an explicit marking mechanisms.  No assumptions involved.

d/

On 4/19/2013 7:58 PM, Jimmy Hess wrote:
> On 4/19/13, Dave Crocker <dhc2 at dcrocker.net> wrote:
>> On 4/19/2013 4:33 PM, Jimmy Hess wrote:
> [snip]
>> Absent a view that somehow says all metadata is a security function, I
>> don't see how the marking of administrative boundaries qualifies as a
>> security function.
>
> The security function comes in immediately, when you consider any
> actual uses for said kind of metadata.
>
> The issues are alleviated only by assuming that an administrative
> division always exists, unless you can show otherwise,   and showing
> that the records are in the same zone is one way of showing otherwise.
>
>
> When you come to rely on it, there are new security issues.
>
> It becomes such that;   It   is perfectly safe to assume that there is
> an administrative division when there is not

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


From mysidia at gmail.com  Sat Apr 20 05:36:49 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 20 Apr 2013 00:36:49 -0500
Subject: What do people use public suffix for?
In-Reply-To: <51720928.2010507@dcrocker.net>
References: <31546939.2275.1366041623873.JavaMail.root@benjamin.baylink.com>
 <8738umqta5.fsf@nemi.mork.no>
 <44D9A3C6-1523-4898-94B4-5B88C4233A6E@hopcount.ca>
 <alpine.LSU.2.00.1304192054140.28595@hermes-2.csi.cam.ac.uk>
 <5171ADDD.8070205@dcrocker.net>
 <CAAAwwbWu_Zo1uyPnGtOW6S8vTTNkOdk9ABU+53kr4877Ri7Uwg@mail.gmail.com>
 <5171EC9A.9080404@dcrocker.net>
 <CAAAwwbWmGEeYEVF5mqS3HzU81VgKXF8eYE+CR8pXcM0XCrE7sw@mail.gmail.com>
 <51720928.2010507@dcrocker.net>
Message-ID: <CAAAwwbVeW=hng70xkHpkJn3X4hpJh3PaJw0cfKJw0zFS+r4tWA@mail.gmail.com>

On 4/19/13, Dave Crocker <dhc2 at dcrocker.net> wrote:

That is only theoretically possible, if every boundary keeper participates.
In reality, you  would wind up with some zones having explicit marking,
and most zones not having any marking at all,  just because the admin
didn't bother to pick up on the new idea  and implement it.

> 3. Since you made reference to assumptions a couple of times: the goal
> here is an explicit marking mechanisms.  No assumptions involved.
>
> d/

--
-JH


From ahobach at cyberlynk.net  Sat Apr 20 16:10:33 2013
From: ahobach at cyberlynk.net (Adam Hobach)
Date: Sat, 20 Apr 2013 11:10:33 -0500
Subject: ATT Network Security Team
Message-ID: <000001ce3de1$967cf2b0$c376d810$@cyberlynk.net>

Anyone from the ATT Network Security Team on the list able to help with a
single IP that ATT has blackholed?

Emails to my account reps, noc at att.com, netsec at att.com and tickets go
un-responded too. MIS Helpdesk states they have no way to contact the
Network Security team to get this IP delisted.

Let me know...

Thanks,

Adam


------------------------------------------------
Adam Hobach
CyberLynk Sales/Support - 414-858-9335
support at cyberlynk.net or sales at cyberlynk.net
http://www.CyberLynk.net
https://secure.CyberLynk.net





From meirea at charterschoolit.com  Mon Apr 22 16:10:49 2013
From: meirea at charterschoolit.com (Mario Eirea)
Date: Mon, 22 Apr 2013 16:10:49 +0000
Subject: Broward County Public Schools
Message-ID: <C95B38A68C80744C8B371447DB6EE98C0A1AAC44@CSIT-SRV-MBX-03.charterschoolit.local>

Can someone with  a clue over at Broward County Public Schools IT department please contact me off list?

Thanks,

Mario Eirea
IT Department
Charter School IT
20803 Johnson Street
Pembroke Pines, FL  33029
Ph: 954-435-7827
Cell: 305-742-6524
Fax: 954-442-1762


From jared at puck.nether.net  Tue Apr 23 00:33:47 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 22 Apr 2013 20:33:47 -0400
Subject: joker.com contact?
Message-ID: <AB64B868-1BF8-47A9-9430-1BDEB776AEB2@puck.nether.net>

Can someone at Joker or someone who knows someone at Joker reach out to me?

- Jared


From yang.yu.list at gmail.com  Tue Apr 23 02:48:33 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Mon, 22 Apr 2013 22:48:33 -0400
Subject: AboveNet Atlanta to DC route
Message-ID: <CAFwKRnT9kuofxAfvR712v6BV28qVrCs-xBVqHYV4fp+1B6J+wA@mail.gmail.com>

>From 21:15 EDT the RTT from ATL to IAD jumped from 15ms to 80ms. Is
there any maintenance going on?


6  xe-1-0-0.mpr3.atl6.us.above.net (64.125.31.45)  22.813 ms  16.716
ms  16.679 ms
 7  xe-2-1-0.cr2.iah1.us.above.net (64.125.31.50)  91.618 ms  66.028
ms  66.042 ms
 8  xe-0-0-0.cr1.iah1.us.above.net (64.125.30.65)  66.036 ms  66.039
ms  66.015 ms
 9  xe-1-2-0.cr1.dfw2.us.above.net (64.125.26.129)  66.528 ms  66.542
ms  66.523 ms
10  xe-2-1-0.cr1.ord2.us.above.net (64.125.30.62)  72.045 ms  72.059
ms  72.058 ms
11  xe-3-0-0.cr1.lga5.us.above.net (64.125.24.37)  83.509 ms  83.520
ms  83.480 ms
12  xe-1-1-0.mpr3.phl2.us.above.net (64.125.31.33)  156.272 ms
121.225 ms  89.677 ms
13  xe-1-0-0.mpr4.phl2.us.above.net (64.125.31.30)  80.308 ms  80.003
ms  80.470 ms
14  xe-0-2-0.cr2.dca2.us.above.net (64.125.31.38)  79.252 ms  79.252 ms *
15  xe-1-0-1.er2.iad10.us.above.net (64.125.26.242)  111.178 ms
79.919 ms  80.016 ms
16  xe-1-0-1.er5.iad10.us.above.net (64.125.24.141)  79.647 ms  78.290
ms  78.253 ms

AboveNet LG

Router: mpr3.atl6.us.above.net
Command: show route protocol bgp table inet.0 64.125.24.141 terse

inet.0: 450455 destinations, 1696045 routes (450337 active, 104
holddown, 327 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
  64.125.24.140/30   B 170        230             64.125.31.50    I
                                                 >64.125.31.50
                     B 170        230             64.125.31.50    I
                                                 >64.125.31.50


From mloftis at wgops.com  Tue Apr 23 05:35:27 2013
From: mloftis at wgops.com (Michael Loftis)
Date: Mon, 22 Apr 2013 22:35:27 -0700
Subject: Comcast NOC - issues to/from AS13331 (Seattle)
Message-ID: <CAHDg04tGvXUpKXGesc4RhC6dfd+XD3miSUERP1uswJf5z8FyUA@mail.gmail.com>

Comcast doesn't appear to have any usable NOC contacts via whois, and
this issue is apparently very widespread.  Comcast obviously has
multiple saturated paths out in this area, so if you're seeing issues
getting to your customers on Comcast...well, it's probably Comcast.
Sort of an ongoing/me too on last months thread about same...


Outbound traffic to Comcast via basically any of our (AS13331)
upstreams except Spectrum (AS11404) is experiencing very high packet
loss once inside Comcast's network, we suspect a router or link very
near to us in Seattle is failing.  I've marked out the destination
customer IPs but they're available to Comcast engineers if they get in
touch with me directly or as noc at metapeer.com -- TIA  -- and again,
sorry to the list.

Below are three failing/high loss traces, and then same three traces
from our other DC which is routing out via spectrum.  The loss is
present on Cogent and L3 outgoing paths at the least, maybe others.
As of now I've routed around the problem point for via the good path.

fission:~# mtr -s 900 --report --report-cycles 30 1.2.3.4
fission.myfreecams.com            Snt: 30    Loss%  Last   Avg  Best  Wrst StDev
ve75-gw1-xmr.metapeer.com                     0.0%   0.4   1.4   0.3  11.8   2.9
te0-7-0-15.ccr21.sea02.atlas.cogentco.com     0.0%   0.9   0.6   0.5   0.9   0.1
te-0-5-0-3-pe03.seattle.wa.ibone.comcast.net  6.7%  43.7  42.3  38.8  43.7   1.4
be-13-cr01.seattle.wa.ibone.comcast.net       3.3%  47.7  44.6  41.3  47.7   1.8
pos-0-7-0-0-cr01.denver.co.ibone.comcast.net  3.3%  69.4  68.7  65.0  71.3   1.5
he-5-15-0-0-cr01.350ecermak.il.ibone.comcast  6.7%  92.6  97.3  91.4 102.0   3.8
he-3-15-0-0-ar01.woburn.ma.boston.comcast.ne 10.0% 120.3 119.8 116.3 122.0   1.8
pos-0-1-0-0-ar01.needham.ma.boston.comcast.n  0.0% 122.0 120.5 117.1 123.9   1.8
po-80-ur01.deering.nh.boston.comcast.net      0.0% 121.4 121.3 118.3 133.8   2.8
po-21-ur01.concord.nh.boston.comcast.net      6.7% 119.6 130.1 119.3 272.8  31.8
te-1-0-0-ten01.concord.nh.boston.comcast.net  6.7% 118.7 120.0 117.6 121.4   1.3
???                                          100.0   0.0   0.0   0.0   0.0   0.0
You have new mail in /var/spool/mail/root
fission:~# mtr -s 900 --report --report-cycles 30 5.6.7.8
fission.myfreecams.com            Snt: 30    Loss%  Last   Avg  Best  Wrst StDev
ve75-gw1-xmr.metapeer.com                     0.0%   0.3   0.6   0.3   5.2   0.9
te0-7-0-15.ccr21.sea02.atlas.cogentco.com     0.0%   0.8   0.6   0.5   0.8   0.1
te-0-5-0-3-pe03.seattle.wa.ibone.comcast.net  0.0%  41.4  42.6  38.5  43.8   1.3
be-13-cr01.seattle.wa.ibone.comcast.net       0.0%  45.6  44.1  40.4  46.7   1.8
pos-0-8-0-0-cr01.denver.co.ibone.comcast.net  6.7%  71.2  69.0  65.0  72.1   1.9
he-5-12-0-0-cr01.350ecermak.il.ibone.comcast  3.3%  98.1  96.3  86.4 101.2   3.9
he-0-15-0-0-ar01.pontiac.mi.michigan.comcast 10.0%  93.5  97.3  93.5 100.6   2.3
xe-11-0-0-0-sur01.rochestrhlls.mi.michigan.c  0.0%  97.2  99.1  92.9 141.8  10.4
te-17-10-cdn05.rochestrhlls.mi.michigan.comc  3.3% 118.9 113.2 104.6 118.9   3.5
???                                          100.0   0.0   0.0   0.0   0.0   0.0
fission:~# mtr -s 900 --report --report-cycles 30 a.b.c.d
fission.myfreecams.com            Snt: 30    Loss%  Last   Avg  Best  Wrst StDev
ve75-gw1-xmr.metapeer.com                     0.0%   0.3   2.1   0.3  47.1   8.6
te0-7-0-15.ccr21.sea02.atlas.cogentco.com     0.0%   0.7   0.6   0.5   0.8   0.1
te-0-5-0-3-pe03.seattle.wa.ibone.comcast.net  6.7%  40.6  42.4  39.7  45.2   1.3
be-15-cr01.seattle.wa.ibone.comcast.net       0.0%  47.3  48.2  41.3  54.8   4.3
68.86.92.34                                   3.3%  43.7  45.5  39.5 101.7  11.6
be-18-ur06.bellevue.wa.seattle.comcast.net    0.0%  43.8  43.0  40.2  44.3   1.4
te-3-0-0-ten15.bellevue.wa.seattle.comcast.n  6.7%  42.7  44.1  42.1  45.7   1.1
???                                          100.0   0.0   0.0   0.0   0.0   0.0








mloftis at phobos:~$ mtr -s 900 --report --report-wide --report-cycles 30 1.2.3.4
HOST: phobos                                           Loss%   Snt
Last   Avg  Best  Wrst StDev
  1. 207.229.74.1                                      0.0%    30
0.4   5.1   0.3 132.4  24.1
  2. agg1-sea-t7-8.bb.spectrumnet.us                   0.0%    30
1.5  14.0   1.5 206.4  39.8
  3. 23.30.206.33                                      0.0%    30
1.8   2.0   1.7   3.5   0.3
  4. be-17-cr01.seattle.wa.ibone.comcast.net           0.0%    30
12.6   5.3   2.1  12.6   2.7
  5. pos-0-4-0-0-cr01.denver.co.ibone.comcast.net      0.0%    30
28.5  29.2  27.2  31.4   1.3
  6. he-5-12-0-0-cr01.350ecermak.il.ibone.comcast.net  0.0%    30
49.9  52.2  49.9  56.7   2.8
  7. he-3-5-0-0-ar01.woburn.ma.boston.comcast.net      0.0%    30
78.5  79.5  78.3  81.0   1.0
  8. pos-1-12-0-0-ar01.needham.ma.boston.comcast.net   0.0%    30
80.2  80.1  78.2  81.7   1.1
  9. po-80-ur01.deering.nh.boston.comcast.net          0.0%    30
80.0  80.1  79.9  80.4   0.1
 10. po-21-ur01.concord.nh.boston.comcast.net          0.0%    30
80.7  85.1  80.7 199.3  21.6
 11. te-1-0-0-ten01.concord.nh.boston.comcast.net      0.0%    30
80.5  80.5  80.5  80.7   0.0
 12. ???                                              100.0    30
0.0   0.0   0.0   0.0   0.0
mloftis at phobos:~$ mtr -s 900 --report --report-wide --report-cycles 30 5.6.7.8
HOST: phobos                                                 Loss%
Snt   Last   Avg  Best  Wrst StDev
  1. 207.229.74.1                                            0.0%
30    0.3   3.6   0.3  96.3  17.5
  2. agg1-sea-t7-8.bb.spectrumnet.us                         0.0%
30   10.2  10.4   1.5  58.5  15.1
  3. 23.30.206.33                                            0.0%
30    2.4   2.0   1.8   2.4   0.1
  4. be-14-cr01.seattle.wa.ibone.comcast.net                 0.0%
30    3.6   4.4   1.7  10.6   2.4
  5. pos-0-3-0-0-cr01.denver.co.ibone.comcast.net            0.0%
30   31.1  29.5  27.2  31.6   1.3
  6. he-5-12-0-0-cr01.350ecermak.il.ibone.comcast.net        0.0%
30   52.3  55.4  50.3  61.5   3.6
  7. he-0-14-0-0-ar01.pontiac.mi.michigan.comcast.net        0.0%
30   58.9  58.0  56.1  60.1   1.2
  8. xe-11-0-0-0-sur01.rochestrhlls.mi.michigan.comcast.net  0.0%
30   71.2  58.9  56.6  83.6   6.4
  9. te-17-10-cdn05.rochestrhlls.mi.michigan.comcast.net     0.0%
30   71.2  72.6  67.6  78.0   3.2
 10. ???                                                    100.0
30    0.0   0.0   0.0   0.0   0.0
mloftis at phobos:~$ mtr -s 900 --report --report-wide --report-cycles 30 a.b.c.d
HOST: phobos                                         Loss%   Snt
Last   Avg  Best  Wrst StDev
  1. 207.229.74.1                                    0.0%    30    0.7
  5.1   0.3 143.4  26.1
  2. agg1-sea-t7-8.bb.spectrumnet.us                 0.0%    30    1.5
  3.1   1.5  30.1   5.6
  3. 23.30.206.33                                    0.0%    30    1.9
  2.0   1.9   2.2   0.1
  4. be-12-cr01.seattle.wa.ibone.comcast.net         0.0%    30    6.9
  5.1   1.7  12.3   3.1
  5. 68.86.94.70                                     0.0%    30    1.8
  2.4   1.8  17.3   2.8
  6. be-18-ur06.bellevue.wa.seattle.comcast.net      0.0%    30    3.5
  3.4   3.3   3.5   0.1
  7. te-3-0-0-ten15.bellevue.wa.seattle.comcast.net  0.0%    30    3.3
  3.2   3.2   3.4   0.0
  8. ???                                            100.0    30    0.0
  0.0   0.0   0.0   0.0
mloftis at phobos:~$

--

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler


From leo.vegoda at icann.org  Tue Apr 23 16:58:13 2013
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 23 Apr 2013 09:58:13 -0700
Subject: Quad-A records in Network Solutions ?
In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF@EXVPMBX100-1.exc.icann.org>
References: <4F734D5F.9030902@gmail.com>
 <CAOmxzdzTxQq3boB7HBPXUiHXNaVMf8OD=RC4zhFbtBpyPb30tg@mail.gmail.com>
 <6D7961E1-F0FE-4674-8F8E-49CB5226DC35@hopcount.ca>
 <20130409232335.44152322F977@drugs.dv.isc.org>
 <5164A8D4.7090802@nic-naa.net>
 <A2C797F8-FF27-4F52-A3D5-6CD62BDD0257@puck.nether.net>
 <5164D8ED.5010608@abenaki.wabanaki.net>
 <5648A8908CCB564EBF46E2BC904A75B15FF1684ABF@EXVPMBX100-1.exc.icann.org>
Message-ID: <5648A8908CCB564EBF46E2BC904A75B15FF1684F71@EXVPMBX100-1.exc.icann.org>

I wrote:

> There are multiple documents to read and you can find them all here.
> 
>
https://www.icann.org/en/news/public-comment/proposed-raa-07mar13-en.htm

An update has just been published. There's an announcement here:

http://www.icann.org/en/news/announcements/announcement-22apr13-en.htm

Regards,

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

From ag4ve.us at gmail.com  Tue Apr 23 21:36:37 2013
From: ag4ve.us at gmail.com (shawn wilson)
Date: Tue, 23 Apr 2013 17:36:37 -0400
Subject: KVM
Message-ID: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>

I'm looking at an IP-KVM. I don't need anything high res as I only
need to see Linux consoles, BIOS, and RAID. What I am looking for:
Non-Java client that runs on Linux (or a WebUI that will deploy a
decent RDP or VNC session over SSL).
Decent/configurable key mappings (ie, I've had a KVM a while ago where
you had to pull down a menu for F-keys - not cool).
Decently priced dongles (say ~$100?)

I started looking at the Raritan devices (which can be found really
cheap on ebay) but I only see a Java client and no mention of
installing a client on Linux.


From jared at puck.nether.net  Tue Apr 23 21:40:32 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 23 Apr 2013 17:40:32 -0400
Subject: KVM
In-Reply-To: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
Message-ID: <C6B156A1-FBA8-47E6-99D4-22FF3B06DEF5@puck.nether.net>


On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:

> I'm looking at an IP-KVM. I don't need anything high res as I only
> need to see Linux consoles, BIOS, and RAID. What I am looking for:
> Non-Java client that runs on Linux (or a WebUI that will deploy a
> decent RDP or VNC session over SSL).
> Decent/configurable key mappings (ie, I've had a KVM a while ago where
> you had to pull down a menu for F-keys - not cool).
> Decently priced dongles (say ~$100?)
> 
> I started looking at the Raritan devices (which can be found really
> cheap on ebay) but I only see a Java client and no mention of
> installing a client on Linux.

I've used the star tech devices in the past.  Most modern systems have some sort of RDP or Java thing on the IPMI that mostly work.

- Jared

From Valdis.Kletnieks at vt.edu  Tue Apr 23 21:41:40 2013
From: Valdis.Kletnieks at vt.edu (Valdis Kletnieks)
Date: Tue, 23 Apr 2013 17:41:40 -0400
Subject: "It's the end of the world as we know it" -- REM
Message-ID: <45779.1366753300@turing-police.cc.vt.edu>

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

Are you ready?

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

From nanog at lacutt.com  Tue Apr 23 22:01:42 2013
From: nanog at lacutt.com (Derrick H.)
Date: Tue, 23 Apr 2013 17:01:42 -0500
Subject: KVM
In-Reply-To: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
Message-ID: <20130423220142.GD4769@nm.lacutt.com>

On Tue, Apr 23, 2013 at 05:36:37PM -0400, shawn wilson wrote:
> I'm looking at an IP-KVM. I don't need anything high res as I only
> need to see Linux consoles, BIOS, and RAID. What I am looking for:
> Non-Java client that runs on Linux (or a WebUI that will deploy a
> decent RDP or VNC session over SSL).
> Decent/configurable key mappings (ie, I've had a KVM a while ago where
> you had to pull down a menu for F-keys - not cool).
> Decently priced dongles (say ~$100?)

I've never used this but saw it mentioned on a mailing list and wished
we hadn't already purchased something else:
http://us.adder.com/products/adderlink-ipeps  It uses the VNC protocol.

We'd already purchased the SpiderDuo from Lantronix which is reliant
upon a Java Webstart client (unfortunately) but works well:
http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html


Derrick


From cblecker at gmail.com  Tue Apr 23 22:02:31 2013
From: cblecker at gmail.com (Christoph Blecker)
Date: Tue, 23 Apr 2013 17:02:31 -0500
Subject: Fibre patches in the Downtown Chicago area
Message-ID: <CADx2oGGhSpQ0mHs6szUgyrut5soN9NCUc3id3W7582z1n_0Yaw@mail.gmail.com>

Hello NANOG,
Wondering if anyone knows of a supplier/warehouse that might have LC/LC
single mode fibre patches (2meter or 6feet) in the Chicago area (60661)?
Here doing work in a remote office, and the patches shipped were too short.

Off-list replies appreciated!

Cheers,
Christoph

From bicknell at ufp.org  Tue Apr 23 22:04:23 2013
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 23 Apr 2013 15:04:23 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <45779.1366753300@turing-police.cc.vt.edu>
References: <45779.1366753300@turing-police.cc.vt.edu>
Message-ID: <20130423220423.GA98069@ussenterprise.ufp.org>

In a message written on Tue, Apr 23, 2013 at 05:41:40PM -0400, Valdis Kletnieks wrote:
> I didn't see any mention of this Tony Hain paper:
> 
> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
> 
> tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

Here's a Geoff Houston report from 2005:
https://www.arin.net/participate/meetings/reports/ARIN_XVI/PDF/wednesday/huston_ipv4_roundtable.pdf

I point to page 8, and the prediction "RIR Pool Exhaustion, 4 June
2013".

Those of us who paid attention are well prepared.

tl;dr: Real statistical models properly executed in 2005 were remarkably
       close to the reality 8 years later.

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

From lathama at gmail.com  Tue Apr 23 22:10:30 2013
From: lathama at gmail.com (Andrew Latham)
Date: Tue, 23 Apr 2013 18:10:30 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <45779.1366753300@turing-police.cc.vt.edu>
References: <45779.1366753300@turing-police.cc.vt.edu>
Message-ID: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
<Valdis.Kletnieks at vt.edu> wrote:
> I didn't see any mention of this Tony Hain paper:
>
> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>
> tl;dr: ARIN predicted to run out of IP space to allocate in August this year.
>
> Are you ready?

I have sadly witnessed a growing number of businesses with /24s moving
to colocation/aws networks and not giving up their unused network
space. I assume this will come into play soon. I have already read the
news of blackmarket sales of network allocations in Europe.

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


From jabley at hopcount.ca  Tue Apr 23 22:11:31 2013
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 23 Apr 2013 18:11:31 -0400
Subject: KVM
In-Reply-To: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
Message-ID: <EF6A4F21-9139-4755-87EF-42E38664C3B7@hopcount.ca>


On 2013-04-23, at 17:36, shawn wilson <ag4ve.us at gmail.com> wrote:

> I'm looking at an IP-KVM.

I have heard only good things about opengear.


Joe



From ssaner at hubris.net  Tue Apr 23 22:13:27 2013
From: ssaner at hubris.net (Steven Saner)
Date: Tue, 23 Apr 2013 17:13:27 -0500
Subject: KVM
In-Reply-To: <20130423220142.GD4769@nm.lacutt.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <20130423220142.GD4769@nm.lacutt.com>
Message-ID: <51770787.4070505@hubris.net>

On 04/23/2013 05:01 PM, Derrick H. wrote:
> On Tue, Apr 23, 2013 at 05:36:37PM -0400, shawn wilson wrote:
>> I'm looking at an IP-KVM. I don't need anything high res as I only
>> need to see Linux consoles, BIOS, and RAID. What I am looking for:
>> Non-Java client that runs on Linux (or a WebUI that will deploy a
>> decent RDP or VNC session over SSL).
>> Decent/configurable key mappings (ie, I've had a KVM a while ago where
>> you had to pull down a menu for F-keys - not cool).
>> Decently priced dongles (say ~$100?)
> 
> I've never used this but saw it mentioned on a mailing list and wished
> we hadn't already purchased something else:
> http://us.adder.com/products/adderlink-ipeps  It uses the VNC protocol.

We have used a couple of the Adderlink devices and they work pretty
well. One model is kind of handy in that in addition to the IP/VNC
console, you can also connect a keyboard and monitor to it so you have a
"local" console as well. We have had success connecting the Adderlink to
standard KVM switches so we effectively have access to multiple consoles
through the one device.

Steve

-- 
--------------------------------------------------------------------------
Steven Saner <ssaner at hubris.net>                      Voice:  316-858-3000
Director of Network Operations                          Fax:  316-858-3001
Hubris Communications                                http://www.hubris.net


From lathama at gmail.com  Tue Apr 23 22:17:40 2013
From: lathama at gmail.com (Andrew Latham)
Date: Tue, 23 Apr 2013 18:17:40 -0400
Subject: KVM
In-Reply-To: <20130423220142.GD4769@nm.lacutt.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <20130423220142.GD4769@nm.lacutt.com>
Message-ID: <CA+qj4S-AqYgcosZCZyV2WZ1pkWhiCM6Q9Sq4oye_XqV388O4Uw@mail.gmail.com>

On Tue, Apr 23, 2013 at 6:01 PM, Derrick H. <nanog at lacutt.com> wrote:
> On Tue, Apr 23, 2013 at 05:36:37PM -0400, shawn wilson wrote:
>> I'm looking at an IP-KVM. I don't need anything high res as I only
>> need to see Linux consoles, BIOS, and RAID. What I am looking for:
>> Non-Java client that runs on Linux (or a WebUI that will deploy a
>> decent RDP or VNC session over SSL).
>> Decent/configurable key mappings (ie, I've had a KVM a while ago where
>> you had to pull down a menu for F-keys - not cool).
>> Decently priced dongles (say ~$100?)
>
> I've never used this but saw it mentioned on a mailing list and wished
> we hadn't already purchased something else:
> http://us.adder.com/products/adderlink-ipeps  It uses the VNC protocol.
>
> We'd already purchased the SpiderDuo from Lantronix which is reliant
> upon a Java Webstart client (unfortunately) but works well:
> http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html
>
>
> Derrick

Lantronix has some tools for enterprise management of the IP-KVMs.
Look at http://www.lantronix.com/it-management/management-platform/vslm.html

FYI: Most newish IPMI or IP-KVM have limited to full TLS/SSL and IPv6
support. Enable TLS/SSL to secure console access to your servers.

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


From lists at quux.de  Tue Apr 23 22:28:04 2013
From: lists at quux.de (Jens Link)
Date: Wed, 24 Apr 2013 00:28:04 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <45779.1366753300@turing-police.cc.vt.edu> (Valdis Kletnieks's
 message of "Tue, 23 Apr 2013 17:41:40 -0400")
References: <45779.1366753300@turing-police.cc.vt.edu>
Message-ID: <87a9oo3mrv.fsf@pc8.berlin.quux.de>

Valdis Kletnieks <Valdis.Kletnieks at vt.edu> writes:

and I feel fine

> I didn't see any mention of this Tony Hain paper:
>
> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>
> tl;dr: ARIN predicted to run out of IP space to allocate in August this
> year.
>
> Are you ready?

Personally? Yes! Customer side? No! Well expect for some.

But at least here in Germany some companies (!= ISPs) noticed this IPv6
thing and now are looking for people to support them. Problem is: They
don't want to pay for it (e.g. less or equal to the usual hourly rate
or any other kind of project).

Two weeks ago: 

"We need someone for a two day IPv6 workshop in two weeks!"

Yesterday: 

"We need someone for a two day IPv6 workshop this week!"

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany    | +49-151-18721264     |
| http://blog.quux.de | jabber: jenslink at guug.de | -------------------  | 
-------------------------------------------------------------------------


From jared at puck.nether.net  Tue Apr 23 22:35:53 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 23 Apr 2013 18:35:53 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <45779.1366753300@turing-police.cc.vt.edu>
References: <45779.1366753300@turing-police.cc.vt.edu>
Message-ID: <15048B59-540C-467C-91A3-EBB5BB795069@puck.nether.net>


On Apr 23, 2013, at 5:41 PM, Valdis Kletnieks <Valdis.Kletnieks at vt.edu> wrote:

> Are you ready?

I think what's very interesting for me is watching the consumer edge getting more IPv6 in north america.

It's important for everyone to talk to their vendors (now is a good day to call/write them) about what their IPv6-Only roadmap is.  While folks may still have some IPv4-glue holding things together, getting that IPv6 to your customer and datacenter edge.

At minimum: It doesn't hurt to ask.

- Jared



From dougb at dougbarton.us  Tue Apr 23 22:38:45 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 23 Apr 2013 15:38:45 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <45779.1366753300@turing-police.cc.vt.edu>
References: <45779.1366753300@turing-police.cc.vt.edu>
Message-ID: <51770D75.4060800@dougbarton.us>

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

On 04/23/2013 02:41 PM, Valdis Kletnieks wrote:
| I didn't see any mention of this Tony Hain paper:
|
| http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
|
| tl;dr: ARIN predicted to run out of IP space to allocate in August
this year.

I haven't seen discussion of how the policy of RIRs being able to
transfer space between themselves is going to affect the "end of the
world" numbers. Have I missed something?

And FWIW, Tony brought some of his early work on this topic to me when I
was at IANA in 2004, and even those initial projections were scarily
accurate. :)

Doug

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJRdw11AAoJEFzGhvEaGryEyU0IAJ0De/zvrSQL2JnLFVaSfEUV
jeUsS3+DThplcFvoCN2wXIOxHgbU0O2HqpgFFdTVYf4pDtumtF0rIhnZYmn7F5L9
FLG3DARjtArc1EPwq/EEmA7WH9r5tJRny15IDjPAtpVmi9ScHu/2zMnHrVBXRUxP
sNDji7D2fULyqxIAJy4G+095ou4fYNcTekeO38E201wCs9P8MMj1SuDYDrLcTJMW
Ru/Lr7DPU8iHlLLh2vlyfoVndXQtWka0MTlFUku48SRGGEOLDyRDxMqX4cO57loL
561s2A7pkaWqONYI9hC6N5M5xCXwTlQiV2cS3PURpF0yXdGIe0PKUwn7zr5zkK4=
=HQS/
-----END PGP SIGNATURE-----


From chris at keybridge.net  Wed Apr 24 02:36:22 2013
From: chris at keybridge.net (Chris McDonald)
Date: Tue, 23 Apr 2013 22:36:22 -0400
Subject: UN Secretariat building in nyc
Message-ID: <CAJsED6H3XtHsnd2d=fOmYgA_XkKRnDopuKdH7kjRecvxPEaRMQ@mail.gmail.com>

Hi all:

Does anyone have a creative (read - fast) way of getting from the mmr there
to 60 Hudson ?

TIA,

Chris @ PCCW

From swmike at swm.pp.se  Wed Apr 24 04:27:42 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 24 Apr 2013 06:27:42 +0200 (CEST)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1304240622400.26743@uplift.swm.pp.se>

On Tue, 23 Apr 2013, Andrew Latham wrote:

>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>>
>> tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

http://www.potaroo.net/tools/ipv4/ says April 2014. That page worked well 
for the RIPE region.

> I assume this will come into play soon. I have already read the news of 
> blackmarket sales of network allocations in Europe.

It's not black market anymore, it's official. RIPE even has a web site 
where one can advertise that one wants to buy or sell.

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


From tore at fud.no  Wed Apr 24 05:46:27 2013
From: tore at fud.no (Tore Anderson)
Date: Wed, 24 Apr 2013 07:46:27 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <517771B3.5010008@fud.no>

* Andrew Latham

> I have sadly witnessed a growing number of businesses with /24s
> moving to colocation/aws networks and not giving up their unused
> network space. I assume this will come into play soon.

A couple of /24s being returned wouldn't make a significant difference
when it comes to IPv4 depletion. Heck, not even a couple of /8s would.
Trying to reclaim and redistribute unused space would be a tremendous
waste of effort.

> I have already read the news of blackmarket sales of network
> allocations in Europe.

Interesting. Do you have a link or some other kind of reference?

Tore


From swmike at swm.pp.se  Wed Apr 24 07:28:38 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 24 Apr 2013 09:28:38 +0200 (CEST)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517771B3.5010008@fud.no>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
Message-ID: <alpine.DEB.2.00.1304240927250.26743@uplift.swm.pp.se>

On Wed, 24 Apr 2013, Tore Anderson wrote:

>> I have already read the news of blackmarket sales of network
>> allocations in Europe.
>
> Interesting. Do you have a link or some other kind of reference?

<http://www.ripe.net/lir-services/resource-management/listing> is a "white 
market sales" place. Perhaps that's what the previous poster meant.

Searching for "IPv4 broker" yields a lot of results as well, that might be 
the "black market" though.

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


From brandon at bitradius.com  Wed Apr 24 00:10:03 2013
From: brandon at bitradius.com (Brandon Lehmann)
Date: Wed, 24 Apr 2013 00:10:03 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <15AE4040AA24964AAE3DA9F2DE04C4F5C05F22C4@W2K8-EX.corp.bitradius.com>

I find it more entertaining that I recognized no less than three organizations 
on that list that we've seen come up a lot recently in our spam scanning 
systems.



> -----Original Message-----
> From: Andrew Latham [mailto:lathama at gmail.com]
> Sent: Tuesday, April 23, 2013 6:11 PM
> To: Valdis Kletnieks
> Cc: nanog at nanog.org
> Subject: Re: "It's the end of the world as we know it" -- REM
>
> On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
> <Valdis.Kletnieks at vt.edu> wrote:
> > I didn't see any mention of this Tony Hain paper:
> >
> > http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
> >
> > tl;dr: ARIN predicted to run out of IP space to allocate in August
> this year.
> >
> > Are you ready?
>
> I have sadly witnessed a growing number of businesses with /24s moving
> to colocation/aws networks and not giving up their unused network
> space. I assume this will come into play soon. I have already read the
> news of blackmarket sales of network allocations in Europe.
>
> --
> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6328 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130424/04f3051f/attachment-0001.bin>

From ops.lists at gmail.com  Wed Apr 24 01:05:17 2013
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 24 Apr 2013 06:35:17 +0530
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <CAArzuosw19PjkaBkNYeq-UCoOwN32XRVSQorAPWEnYVYDveVgA@mail.gmail.com>

Black market sales, handing out /15s to Romanian spammers like candy ..
Europe has had a lot of IP allocation fun

On Wednesday, April 24, 2013, Andrew Latham wrote:

> On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
> <Valdis.Kletnieks at vt.edu <javascript:;>> wrote:
> > I didn't see any mention of this Tony Hain paper:
> >
> > http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
> >
> > tl;dr: ARIN predicted to run out of IP space to allocate in August this
> year.
> >
> > Are you ready?
>
> I have sadly witnessed a growing number of businesses with /24s moving
> to colocation/aws networks and not giving up their unused network
> space. I assume this will come into play soon. I have already read the
> news of blackmarket sales of network allocations in Europe.
>
> --
> ~ Andrew "lathama" Latham lathama at gmail.com <javascript:;>
> http://lathama.net ~
>
>

-- 
--srs (iPad)

From vinod408 at hotmail.com  Wed Apr 24 00:50:45 2013
From: vinod408 at hotmail.com (Vinod K)
Date: Wed, 24 Apr 2013 00:50:45 +0000
Subject: Fibre patches in the Downtown Chicago area
In-Reply-To: <CADx2oGGhSpQ0mHs6szUgyrut5soN9NCUc3id3W7582z1n_0Yaw@mail.gmail.com>
References: <CADx2oGGhSpQ0mHs6szUgyrut5soN9NCUc3id3W7582z1n_0Yaw@mail.gmail.com>
Message-ID: <BLU166-W5D744B8BFE5ADBB314AE189B50@phx.gbl>

Not a supplier but check with Server Central... they are in the Equinix there and have a lot of spare parts to help u out.

Vinod

> Date: Tue, 23 Apr 2013 17:02:31 -0500
> Subject: Fibre patches in the Downtown Chicago area
> From: cblecker at gmail.com
> To: nanog at nanog.org
> 
> Hello NANOG,
> Wondering if anyone knows of a supplier/warehouse that might have LC/LC
> single mode fibre patches (2meter or 6feet) in the Chicago area (60661)?
> Here doing work in a remote office, and the patches shipped were too short.
> 
> Off-list replies appreciated!
> 
> Cheers,
> Christoph
 		 	   		  

From adam.vitkovsky at swan.sk  Wed Apr 24 08:19:57 2013
From: adam.vitkovsky at swan.sk (Adam Vitkovsky)
Date: Wed, 24 Apr 2013 10:19:57 +0200
Subject: Ethernet CFM & LMI vs EBGP between PE-CE
In-Reply-To: <540AE58F-9D7A-4B30-82B7-11E884D2C989@turknet.net.tr>
References: <780A28F50E2834489278DD3B512FE7163ECBA0@CAQCCOHVEX01.corp.amayagaming.com>
 <CAN3um4wpyQhqUE-ERFA76cDQTf+qhXJ6GVkGEkg4UySKYrj6-A@mail.gmail.com>
 <540AE58F-9D7A-4B30-82B7-11E884D2C989@turknet.net.tr>
Message-ID: <00e401ce40c4$81e4db70$85ae9250$@swan.sk>

Well CFM and Ethernet LMI is great help in L2VPN services to pin point the failed portion of the L2 circuit. 
For L3VPN services I rather relay on BFD over PE-CE link and BGP PIC Edge in the backbone to achieve fast convergence. 

adam




From vinod408 at hotmail.com  Wed Apr 24 00:41:17 2013
From: vinod408 at hotmail.com (Vinod K)
Date: Wed, 24 Apr 2013 00:41:17 +0000
Subject: Comcast NOC - issues to/from AS13331 (Seattle)
In-Reply-To: <CAHDg04tGvXUpKXGesc4RhC6dfd+XD3miSUERP1uswJf5z8FyUA@mail.gmail.com>
References: <CAHDg04tGvXUpKXGesc4RhC6dfd+XD3miSUERP1uswJf5z8FyUA@mail.gmail.com>
Message-ID: <BLU166-W48F57EA545B361A434E8F289B50@phx.gbl>

We have same problem.  Cogent noc says use another provider, Comcast will not upgrade unless they pay for the traffic b/c they send more then they take in.  I attach Ren Provo for official statement.

Vinod

> Date: Mon, 22 Apr 2013 22:35:27 -0700
> Subject: Comcast NOC - issues to/from AS13331 (Seattle)
> From: mloftis at wgops.com
> To: nanog at nanog.org
> 
> Comcast doesn't appear to have any usable NOC contacts via whois, and
> this issue is apparently very widespread.  Comcast obviously has
> multiple saturated paths out in this area, so if you're seeing issues
> getting to your customers on Comcast...well, it's probably Comcast.
> Sort of an ongoing/me too on last months thread about same...
> 
> 
> Outbound traffic to Comcast via basically any of our (AS13331)
> upstreams except Spectrum (AS11404) is experiencing very high packet
> loss once inside Comcast's network, we suspect a router or link very
> near to us in Seattle is failing.  I've marked out the destination
> customer IPs but they're available to Comcast engineers if they get in
> touch with me directly or as noc at metapeer.com -- TIA  -- and again,
> sorry to the list.
> 
> Below are three failing/high loss traces, and then same three traces
> from our other DC which is routing out via spectrum.  The loss is
> present on Cogent and L3 outgoing paths at the least, maybe others.
> As of now I've routed around the problem point for via the good path.
> 
> fission:~# mtr -s 900 --report --report-cycles 30 1.2.3.4
> fission.myfreecams.com            Snt: 30    Loss%  Last   Avg  Best  Wrst StDev
> ve75-gw1-xmr.metapeer.com                     0.0%   0.4   1.4   0.3  11.8   2.9
> te0-7-0-15.ccr21.sea02.atlas.cogentco.com     0.0%   0.9   0.6   0.5   0.9   0.1
> te-0-5-0-3-pe03.seattle.wa.ibone.comcast.net  6.7%  43.7  42.3  38.8  43.7   1.4
> be-13-cr01.seattle.wa.ibone.comcast.net       3.3%  47.7  44.6  41.3  47.7   1.8
> pos-0-7-0-0-cr01.denver.co.ibone.comcast.net  3.3%  69.4  68.7  65.0  71.3   1.5
> he-5-15-0-0-cr01.350ecermak.il.ibone.comcast  6.7%  92.6  97.3  91.4 102.0   3.8
> he-3-15-0-0-ar01.woburn.ma.boston.comcast.ne 10.0% 120.3 119.8 116.3 122.0   1.8
> pos-0-1-0-0-ar01.needham.ma.boston.comcast.n  0.0% 122.0 120.5 117.1 123.9   1.8
> po-80-ur01.deering.nh.boston.comcast.net      0.0% 121.4 121.3 118.3 133.8   2.8
> po-21-ur01.concord.nh.boston.comcast.net      6.7% 119.6 130.1 119.3 272.8  31.8
> te-1-0-0-ten01.concord.nh.boston.comcast.net  6.7% 118.7 120.0 117.6 121.4   1.3
> ???                                          100.0   0.0   0.0   0.0   0.0   0.0
> You have new mail in /var/spool/mail/root
> fission:~# mtr -s 900 --report --report-cycles 30 5.6.7.8
> fission.myfreecams.com            Snt: 30    Loss%  Last   Avg  Best  Wrst StDev
> ve75-gw1-xmr.metapeer.com                     0.0%   0.3   0.6   0.3   5.2   0.9
> te0-7-0-15.ccr21.sea02.atlas.cogentco.com     0.0%   0.8   0.6   0.5   0.8   0.1
> te-0-5-0-3-pe03.seattle.wa.ibone.comcast.net  0.0%  41.4  42.6  38.5  43.8   1.3
> be-13-cr01.seattle.wa.ibone.comcast.net       0.0%  45.6  44.1  40.4  46.7   1.8
> pos-0-8-0-0-cr01.denver.co.ibone.comcast.net  6.7%  71.2  69.0  65.0  72.1   1.9
> he-5-12-0-0-cr01.350ecermak.il.ibone.comcast  3.3%  98.1  96.3  86.4 101.2   3.9
> he-0-15-0-0-ar01.pontiac.mi.michigan.comcast 10.0%  93.5  97.3  93.5 100.6   2.3
> xe-11-0-0-0-sur01.rochestrhlls.mi.michigan.c  0.0%  97.2  99.1  92.9 141.8  10.4
> te-17-10-cdn05.rochestrhlls.mi.michigan.comc  3.3% 118.9 113.2 104.6 118.9   3.5
> ???                                          100.0   0.0   0.0   0.0   0.0   0.0
> fission:~# mtr -s 900 --report --report-cycles 30 a.b.c.d
> fission.myfreecams.com            Snt: 30    Loss%  Last   Avg  Best  Wrst StDev
> ve75-gw1-xmr.metapeer.com                     0.0%   0.3   2.1   0.3  47.1   8.6
> te0-7-0-15.ccr21.sea02.atlas.cogentco.com     0.0%   0.7   0.6   0.5   0.8   0.1
> te-0-5-0-3-pe03.seattle.wa.ibone.comcast.net  6.7%  40.6  42.4  39.7  45.2   1.3
> be-15-cr01.seattle.wa.ibone.comcast.net       0.0%  47.3  48.2  41.3  54.8   4.3
> 68.86.92.34                                   3.3%  43.7  45.5  39.5 101.7  11.6
> be-18-ur06.bellevue.wa.seattle.comcast.net    0.0%  43.8  43.0  40.2  44.3   1.4
> te-3-0-0-ten15.bellevue.wa.seattle.comcast.n  6.7%  42.7  44.1  42.1  45.7   1.1
> ???                                          100.0   0.0   0.0   0.0   0.0   0.0
> 
> 
> 
> 
> 
> 
> 
> 
> mloftis at phobos:~$ mtr -s 900 --report --report-wide --report-cycles 30 1.2.3.4
> HOST: phobos                                           Loss%   Snt
> Last   Avg  Best  Wrst StDev
>   1. 207.229.74.1                                      0.0%    30
> 0.4   5.1   0.3 132.4  24.1
>   2. agg1-sea-t7-8.bb.spectrumnet.us                   0.0%    30
> 1.5  14.0   1.5 206.4  39.8
>   3. 23.30.206.33                                      0.0%    30
> 1.8   2.0   1.7   3.5   0.3
>   4. be-17-cr01.seattle.wa.ibone.comcast.net           0.0%    30
> 12.6   5.3   2.1  12.6   2.7
>   5. pos-0-4-0-0-cr01.denver.co.ibone.comcast.net      0.0%    30
> 28.5  29.2  27.2  31.4   1.3
>   6. he-5-12-0-0-cr01.350ecermak.il.ibone.comcast.net  0.0%    30
> 49.9  52.2  49.9  56.7   2.8
>   7. he-3-5-0-0-ar01.woburn.ma.boston.comcast.net      0.0%    30
> 78.5  79.5  78.3  81.0   1.0
>   8. pos-1-12-0-0-ar01.needham.ma.boston.comcast.net   0.0%    30
> 80.2  80.1  78.2  81.7   1.1
>   9. po-80-ur01.deering.nh.boston.comcast.net          0.0%    30
> 80.0  80.1  79.9  80.4   0.1
>  10. po-21-ur01.concord.nh.boston.comcast.net          0.0%    30
> 80.7  85.1  80.7 199.3  21.6
>  11. te-1-0-0-ten01.concord.nh.boston.comcast.net      0.0%    30
> 80.5  80.5  80.5  80.7   0.0
>  12. ???                                              100.0    30
> 0.0   0.0   0.0   0.0   0.0
> mloftis at phobos:~$ mtr -s 900 --report --report-wide --report-cycles 30 5.6.7.8
> HOST: phobos                                                 Loss%
> Snt   Last   Avg  Best  Wrst StDev
>   1. 207.229.74.1                                            0.0%
> 30    0.3   3.6   0.3  96.3  17.5
>   2. agg1-sea-t7-8.bb.spectrumnet.us                         0.0%
> 30   10.2  10.4   1.5  58.5  15.1
>   3. 23.30.206.33                                            0.0%
> 30    2.4   2.0   1.8   2.4   0.1
>   4. be-14-cr01.seattle.wa.ibone.comcast.net                 0.0%
> 30    3.6   4.4   1.7  10.6   2.4
>   5. pos-0-3-0-0-cr01.denver.co.ibone.comcast.net            0.0%
> 30   31.1  29.5  27.2  31.6   1.3
>   6. he-5-12-0-0-cr01.350ecermak.il.ibone.comcast.net        0.0%
> 30   52.3  55.4  50.3  61.5   3.6
>   7. he-0-14-0-0-ar01.pontiac.mi.michigan.comcast.net        0.0%
> 30   58.9  58.0  56.1  60.1   1.2
>   8. xe-11-0-0-0-sur01.rochestrhlls.mi.michigan.comcast.net  0.0%
> 30   71.2  58.9  56.6  83.6   6.4
>   9. te-17-10-cdn05.rochestrhlls.mi.michigan.comcast.net     0.0%
> 30   71.2  72.6  67.6  78.0   3.2
>  10. ???                                                    100.0
> 30    0.0   0.0   0.0   0.0   0.0
> mloftis at phobos:~$ mtr -s 900 --report --report-wide --report-cycles 30 a.b.c.d
> HOST: phobos                                         Loss%   Snt
> Last   Avg  Best  Wrst StDev
>   1. 207.229.74.1                                    0.0%    30    0.7
>   5.1   0.3 143.4  26.1
>   2. agg1-sea-t7-8.bb.spectrumnet.us                 0.0%    30    1.5
>   3.1   1.5  30.1   5.6
>   3. 23.30.206.33                                    0.0%    30    1.9
>   2.0   1.9   2.2   0.1
>   4. be-12-cr01.seattle.wa.ibone.comcast.net         0.0%    30    6.9
>   5.1   1.7  12.3   3.1
>   5. 68.86.94.70                                     0.0%    30    1.8
>   2.4   1.8  17.3   2.8
>   6. be-18-ur06.bellevue.wa.seattle.comcast.net      0.0%    30    3.5
>   3.4   3.3   3.5   0.1
>   7. te-3-0-0-ten15.bellevue.wa.seattle.comcast.net  0.0%    30    3.3
>   3.2   3.2   3.4   0.0
>   8. ???                                            100.0    30    0.0
>   0.0   0.0   0.0   0.0
> mloftis at phobos:~$
> 
> --
> 
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
> 
 		 	   		  

From gih at apnic.net  Tue Apr 23 23:44:09 2013
From: gih at apnic.net (Geoff Huston)
Date: Wed, 24 Apr 2013 09:44:09 +1000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>

On 24/04/2013, at 8:10 AM, Andrew Latham <lathama at gmail.com> wrote:

> On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
> <Valdis.Kletnieks at vt.edu> wrote:
>> I didn't see any mention of this Tony Hain paper:
>> 
>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>> 
>> ARIN predicted to run out of IP space to allocate in August this year.
>> 
>> Are you ready?
> 

The prediction of runout business is extremely hard. All of these predictions are based on the basic premise that what happened yesterday will most likely happen tomorrow. And in a world of very large populations this is highly likely - the larger the population its often the case that the smaller the impact of individual variations in behaviour. That means that once you get a very large population you'd expect a relatively low level of uncertainty in trend-based predictive models.

But the world of addresses is not so well behaved. For some years now we've seen the address world bifurcate into a small number of very large actors and a large number of much smaller actors. In the address world it was observed that less than 1% (its closer to around 0.5%)  individual allocations account for more than half of the number of allocated addresses. This becomes a problem in the predictive models, as the dominant factor in address consumption is now the actions of some 20 or so very large entities. If they all fronted at the registry's front doors and asked for a three month allocation, and do so again in 90 days, and so on, then its pretty obvious that ARIN's remaining 40M addresses would not last more than one or two iterations of this cycle.

But what has been apparent in the ARIN region since the IANA runout of February 2011 has not been panic, but restraint. If you look at the run-down' of the address pool in ARIN over time (http://www.potaroo.net/tools/ipv4/arin-pool.png), you could certainly make the case that there was a pronounced run on address resources in ARIN in the last quarter of 2010, but it all changed in 2011. The ensuing 14 months following IANA runout, through 2011 and early 2012, saw a pronounced change in the region, and ARIN's address consumption in that period slowed down to a consumption rate that got as low as 1M addresses per month. This coincided in a change in the address allocation policy to reduce the time horizon of "demonstrated need" from 12 months to 3 months, but that factor alone would not account for the entirety of this slow down in the address consumption rates over this 14 month period. 

Following a single largish allocation in early 2012 we've seen the ARIN address consumption rate increase somewhat, and the average rate of address consumption is currently around 2M addresses per month. If this rate of address consumption continues, the ARIN will reach its last /8 in early 2014, and if this rate persists, then the registry will exhaust its pool around the end of that year, or early 2015.

But given the uncertainty factors here as they relate to the distribution of large and small consumers in this area and changing sentiment about whether or not panic is a factor in address demands, I'd have to comment that the uncertainty factor of any prediction is high. Its quite plausible that exhaustion could occur some 6 - 9 months earlier than these dates. 

However, personally I find it a little hard to place a high probability on Tony's projected exhaustion date of August this year. I also have to qualify that by noting that while I think that a runout of the remaining 40 M addresses within 4 months is improbable, its by no means impossible. If we saw a re-run of the address consumption rates that ARIN experienced in 2010, then it's not outside the bounds of plausibility that ARIN will be handing out its last address later this year. 

thanks,

Geoff




From chk at pobox.com  Tue Apr 23 23:10:02 2013
From: chk at pobox.com (Harald Koch)
Date: Tue, 23 Apr 2013 19:10:02 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <CAPYK2_z_1j3uTuBh4W9MKP0XBhvj=jW4J8VrbnJ3KWD4yCZmkQ@mail.gmail.com>

Meanwhile, consumer-grade IPv6 still sucks, at "I have to turn off IPv6 to
watch YouTube videos" levels of suck...

From copraphage at gmail.com  Wed Apr 24 00:13:20 2013
From: copraphage at gmail.com (Chris McDonald)
Date: Tue, 23 Apr 2013 20:13:20 -0400
Subject: UN Secretariat building in nyc
Message-ID: <C17FBD32-4AAA-48E4-BDB1-F1FC6C183B41@gmail.com>

Hi all:

Does anyone have a creative (read - fast) way of getting from the mmr there to 60 Hudson ?

TIA,

Chris @ PCCW

From brent at brentrjones.com  Tue Apr 23 23:54:44 2013
From: brent at brentrjones.com (Brent Jones)
Date: Tue, 23 Apr 2013 16:54:44 -0700
Subject: KVM
In-Reply-To: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
Message-ID: <CAOC=LuUj83fqux7eCyhNKRunavimbxXGLnnBN-JXGhFnd_hisA@mail.gmail.com>

Raritan makes good IP KVM (VGA, USB/PS2).
For serial, I would go OpenGear.


On Tue, Apr 23, 2013 at 2:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:

> I'm looking at an IP-KVM. I don't need anything high res as I only
> need to see Linux consoles, BIOS, and RAID. What I am looking for:
> Non-Java client that runs on Linux (or a WebUI that will deploy a
> decent RDP or VNC session over SSL).
> Decent/configurable key mappings (ie, I've had a KVM a while ago where
> you had to pull down a menu for F-keys - not cool).
> Decently priced dongles (say ~$100?)
>
> I started looking at the Raritan devices (which can be found really
> cheap on ebay) but I only see a Java client and no mention of
> installing a client on Linux.
>
>


-- 
Brent Jones
brent at brentrjones.com

From swmike at swm.pp.se  Wed Apr 24 08:55:51 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 24 Apr 2013 10:55:51 +0200 (CEST)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
Message-ID: <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>

On Wed, 24 Apr 2013, Geoff Huston wrote:

> However, personally I find it a little hard to place a high probability 
> on Tony's projected exhaustion date of August this year. I also have to 
> qualify that by noting that while I think that a runout of the remaining 
> 40 M addresses within 4 months is improbable, its by no means 
> impossible. If we saw a re-run of the address consumption rates that 
> ARIN experienced in 2010, then it's not outside the bounds of 
> plausibility that ARIN will be handing out its last address later this 
> year.

I also find it a bit strange that the runout in APNIC and RIPE was very 
different. APNIC address allocation rate accelerated at the end, whereas 
RIPE exhaustion date kept creeping forward in time instead of closer in 
time, giving me the impression that there wasn't any panic there.

Has anyone done any detailed analysis of the last year of allocation 
behaviour for each of these regions, trying to understand the difference 
in behaviour? I'd be very interested in this.

My belief (not well founded) is that ARIN runout will look more like RIPE 
region than APNIC...

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


From eugen at leitl.org  Wed Apr 24 09:52:48 2013
From: eugen at leitl.org (Eugen Leitl)
Date: Wed, 24 Apr 2013 11:52:48 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
Message-ID: <20130424095248.GI15179@leitl.org>

On Tue, Apr 23, 2013 at 06:10:30PM -0400, Andrew Latham wrote:

> > tl;dr: ARIN predicted to run out of IP space to allocate in August this year.
> >
> > Are you ready?
> 
> I have sadly witnessed a growing number of businesses with /24s moving
> to colocation/aws networks and not giving up their unused network
> space. I assume this will come into play soon. I have already read the
> news of blackmarket sales of network allocations in Europe.

One of the immediate results of RIPE NCC exhaustion was that ISPs
and colo now ask for monthly IPv4 space rental to end users, starting 
with 1 EUR/IPv4 address per month, trend is up.


From dr at cluenet.de  Wed Apr 24 10:12:29 2013
From: dr at cluenet.de (Daniel Roesen)
Date: Wed, 24 Apr 2013 12:12:29 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
Message-ID: <20130424101229.GA13561@srv03.cluenet.de>

On Wed, Apr 24, 2013 at 10:55:51AM +0200, Mikael Abrahamsson wrote:
> I also find it a bit strange that the runout in APNIC and RIPE was very 
> different. APNIC address allocation rate accelerated at the end, whereas 
> RIPE exhaustion date kept creeping forward in time instead of closer in 
> time, giving me the impression that there wasn't any panic there.

RIPE had shrinking allocation windows (12/9/6/3 months) and increasingly
strict scrutining of requests. Even in 3 months window period, people
showing need for >55k of IPs for that 3 months only got /17+/18 (48k)
instead of /16 one would expect - so in fact the windows were even
shorter in practise.

Geoff pointed out the large alloc players having a huge impact in the
end game scenario - this was effectively neutralized by this "soft
landing" policy, I'd say.

I'm not aware that APNIC also had such a "soft landing" policy in
effect, but I didn't monitor closely.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From gih at apnic.net  Wed Apr 24 10:37:45 2013
From: gih at apnic.net (Geoff Huston)
Date: Wed, 24 Apr 2013 20:37:45 +1000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
Message-ID: <6C133B91-4A01-48EC-B3A5-81F9967EBF02@apnic.net>


On 24/04/2013, at 6:55 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> I also find it a bit strange that the runout in APNIC and RIPE was very different. APNIC address allocation rate accelerated at the end, whereas RIPE exhaustion date kept creeping forward in time instead of closer in time, giving me the impression that there wasn't any panic there.
> 
> Has anyone done any detailed analysis of the last year of allocation behaviour for each of these regions, trying to understand the difference in behaviour? I'd be very interested in this.
> 
> My belief (not well founded) is that ARIN runout will look more like RIPE region than APNIC...
> 

I suspect that the extent of communication of expectations, the economic climate, the prevailing allocation window at the time (RIPE was working on 3 months whereas APNIC still had the 12 month window in place right up to the last /8) all play a part in such things. 

The fast/slow nature of ARIN's address consumption profile over the last 30 months is certainly a new factor here - again there is likely to be some interplay between economics, the saturation of the wired market in that region, and the  existing CGN deployments in some (much) of the mobile IPv4 space in North America which also give some credibility to a prediction of a more measured approach to exhaustion rather than a massive paniced run on what's left.

But then again APNIC and RIPE NCC both had last /8 policies in place, which has mitigated some of the impacts of address pool exhaustion. For smaller actors there is still a source of addresses in these regions, albeit a very limited trickle of addresses, but there is still some.  As I understand it, ARIN will continue allocating right to the end of their IPv4 address pool and not hold back any addresses for this "last chance" trickle feed, or have I missed something crucial in ARIN's policy handbook?


Geoff



From cgrundemann at gmail.com  Wed Apr 24 11:40:05 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 24 Apr 2013 07:40:05 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <6C133B91-4A01-48EC-B3A5-81F9967EBF02@apnic.net>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
 <6C133B91-4A01-48EC-B3A5-81F9967EBF02@apnic.net>
Message-ID: <CAC1-dtnog=v6zTAcjnn4p6nsSLmzgxRyzbFUwmnpZeffPCix-g@mail.gmail.com>

On Wed, Apr 24, 2013 at 6:37 AM, Geoff Huston <gih at apnic.net> wrote:

> But then again APNIC and RIPE NCC both had last /8 policies in place, which has mitigated some of the impacts of address pool exhaustion. For smaller actors there is still a source of addresses in these regions, albeit a very limited trickle of addresses, but there is still some.  As I understand it, ARIN will continue allocating right to the end of their IPv4 address pool and not hold back any addresses for this "last chance" trickle feed, or have I missed something crucial in ARIN's policy handbook?
>

Nope, you are correct Geoff. There is a /10 reserved for transition
technologies (e.g. outside addresses on a CGN) and there is a
"critical infrastructure" reserve, but no general purpose reserve like
in RIPE and APNIC.

~Chris

> Geoff
>

--
@ChrisGrundemann
http://chrisgrundemann.com


From tore at fud.no  Wed Apr 24 11:59:42 2013
From: tore at fud.no (Tore Anderson)
Date: Wed, 24 Apr 2013 13:59:42 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <alpine.DEB.2.00.1304240927250.26743@uplift.swm.pp.se>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <alpine.DEB.2.00.1304240927250.26743@uplift.swm.pp.se>
Message-ID: <5177C92E.9040809@fud.no>

* Mikael Abrahamsson

> On Wed, 24 Apr 2013, Tore Anderson wrote:
> 
>>> I have already read the news of blackmarket sales of network
>>> allocations in Europe.
>>
>> Interesting. Do you have a link or some other kind of reference?
> 
> <http://www.ripe.net/lir-services/resource-management/listing> is a
> "white market sales" place. Perhaps that's what the previous poster meant.
> 
> Searching for "IPv4 broker" yields a lot of results as well, that might
> be the "black market" though.

"White market" transfers has been allowed in the RIPE region since late
2008, cf. http://www.ripe.net/ripe/policies/proposals/2007-08. There's
no requirement that the transferred space is put on the NCC's listing
service first - you can use a broker to arrange it if you want, or do it
completely in private.

For a transfer not to be "white", the transaction would need happen
without the NCC's knowing and blessing. This implies validations of the
receiver's operational need for the allocation, and updating the
registry/database to reflect the new holder. I'm genuinely interested in
reading articles or other research documenting that such "black market"
transfers are happening (or not).

Tore





From tore at fud.no  Wed Apr 24 12:07:40 2013
From: tore at fud.no (Tore Anderson)
Date: Wed, 24 Apr 2013 14:07:40 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CAC1-dtnog=v6zTAcjnn4p6nsSLmzgxRyzbFUwmnpZeffPCix-g@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
 <6C133B91-4A01-48EC-B3A5-81F9967EBF02@apnic.net>
 <CAC1-dtnog=v6zTAcjnn4p6nsSLmzgxRyzbFUwmnpZeffPCix-g@mail.gmail.com>
Message-ID: <5177CB0C.7050905@fud.no>

* Chris Grundemann

> Nope, you are correct Geoff. There is a /10 reserved for transition
> technologies (e.g. outside addresses on a CGN) and there is a
> "critical infrastructure" reserve, but no general purpose reserve like
> in RIPE and APNIC.

One interesting thing is that this is dedicated specifically for
transition/deployment of *IPv6*. So the way I understand it, you won't
get any space from this block to number the outside of a NAT444-style
CGN, while you would for a NAT64-style CGN.

https://www.arin.net/policy/nrpm.html#four10

Tore


From cgrundemann at gmail.com  Wed Apr 24 12:14:13 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 24 Apr 2013 08:14:13 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <5177CB0C.7050905@fud.no>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
 <6C133B91-4A01-48EC-B3A5-81F9967EBF02@apnic.net>
 <CAC1-dtnog=v6zTAcjnn4p6nsSLmzgxRyzbFUwmnpZeffPCix-g@mail.gmail.com>
 <5177CB0C.7050905@fud.no>
Message-ID: <CAC1-dt=BayhUVkZppyQCekMfvVZUUWR35fAQbLAX_k+bw5MMyA@mail.gmail.com>

On Wed, Apr 24, 2013 at 8:07 AM, Tore Anderson <tore at fud.no> wrote:
> * Chris Grundemann
>
>> Nope, you are correct Geoff. There is a /10 reserved for transition
>> technologies (e.g. outside addresses on a CGN) and there is a
>> "critical infrastructure" reserve, but no general purpose reserve like
>> in RIPE and APNIC.
>
> One interesting thing is that this is dedicated specifically for
> transition/deployment of *IPv6*. So the way I understand it, you won't
> get any space from this block to number the outside of a NAT444-style
> CGN, while you would for a NAT64-style CGN.
>
> https://www.arin.net/policy/nrpm.html#four10

That's a very good clarification, thanks Tore.

> Tore



--
@ChrisGrundemann
http://chrisgrundemann.com


From copraphage at gmail.com  Wed Apr 24 12:47:11 2013
From: copraphage at gmail.com (Chris McDonald)
Date: Wed, 24 Apr 2013 08:47:11 -0400
Subject: UN Secretariat building in nyc
Message-ID: <CAJsED6GiUw8XkF-HFSm1xP-NOgqsGhfcoZOeW_Owg_8+kg3Ocg@mail.gmail.com>

Hi all:

Does anyone have a creative (read - fast) way of getting from the mmr there
to 60 Hudson ?

TIA,

Chris @ PCCW

From EWieling at nyigc.com  Wed Apr 24 12:52:04 2013
From: EWieling at nyigc.com (Eric Wieling)
Date: Wed, 24 Apr 2013 08:52:04 -0400
Subject: KVM
In-Reply-To: <20130423220142.GD4769@nm.lacutt.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <20130423220142.GD4769@nm.lacutt.com>
Message-ID: <616B4ECE1290D441AD56124FEBB03D081713F8EB8F@mailserver2007.nyigc.globe>

We have an Adderlink box.   It sometimessssssssssssssss doesnnnnnnnnnnnt see kkkkkkkkkkkkey up events.


-----Original Message-----
From: Derrick H. [mailto:nanog at lacutt.com] 
Sent: Tuesday, April 23, 2013 6:02 PM
To: nanog at nanog.org
Subject: Re: KVM

On Tue, Apr 23, 2013 at 05:36:37PM -0400, shawn wilson wrote:
> I'm looking at an IP-KVM. I don't need anything high res as I only 
> need to see Linux consoles, BIOS, and RAID. What I am looking for:
> Non-Java client that runs on Linux (or a WebUI that will deploy a 
> decent RDP or VNC session over SSL).
> Decent/configurable key mappings (ie, I've had a KVM a while ago where 
> you had to pull down a menu for F-keys - not cool).
> Decently priced dongles (say ~$100?)

I've never used this but saw it mentioned on a mailing list and wished we hadn't already purchased something else:
http://us.adder.com/products/adderlink-ipeps  It uses the VNC protocol.

We'd already purchased the SpiderDuo from Lantronix which is reliant upon a Java Webstart client (unfortunately) but works well:
http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html


Derrick



From lathama at gmail.com  Wed Apr 24 14:18:25 2013
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 24 Apr 2013 10:18:25 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517771B3.5010008@fud.no>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
Message-ID: <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>

* Tore

On Wed, Apr 24, 2013 at 1:46 AM, Tore Anderson <tore at fud.no> wrote:
> * Andrew Latham
>
>> I have sadly witnessed a growing number of businesses with /24s
>> moving to colocation/aws networks and not giving up their unused
>> network space. I assume this will come into play soon.
>
> A couple of /24s being returned wouldn't make a significant difference
> when it comes to IPv4 depletion. Heck, not even a couple of /8s would.
> Trying to reclaim and redistribute unused space would be a tremendous
> waste of effort.

If I can walk around a smallish town and point at 5 businesses like
this its a possible solution.  I am not claiming a few /24s will do, I
am claiming that there are many (for larger values of many) companies
like this.

>> I have already read the news of blackmarket sales of network
>> allocations in Europe.
>
> Interesting. Do you have a link or some other kind of reference?

I did a quick search and they are easy to find. Many news articles
about Microsoft buying network allocations at auction to set a price
of ~$11USD per IP. One tangent article that I liked was
http://www.datacenterknowledge.com/archives/2012/07/16/ipv4-addresses-now-driving-hosting-deals/

> Tore

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


From me at staticsafe.ca  Tue Apr 23 22:36:20 2013
From: me at staticsafe.ca (staticsafe)
Date: Tue, 23 Apr 2013 18:36:20 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <20130423220423.GA98069@ussenterprise.ufp.org>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <20130423220423.GA98069@ussenterprise.ufp.org>
Message-ID: <51770CE4.3070305@staticsafe.ca>

On 4/23/2013 18:04, Leo Bicknell wrote:
> In a message written on Tue, Apr 23, 2013 at 05:41:40PM -0400,
> Valdis Kletnieks wrote:
>> I didn't see any mention of this Tony Hain paper:
>> 
>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>> 
>> tl;dr: ARIN predicted to run out of IP space to allocate in
>> August this year.
> 
> Here's a Geoff Houston report from 2005: 
> https://www.arin.net/participate/meetings/reports/ARIN_XVI/PDF/wednesday/huston_ipv4_roundtable.pdf
>
>  I point to page 8, and the prediction "RIR Pool Exhaustion, 4
> June 2013".
> 
> Those of us who paid attention are well prepared.
> 
> tl;dr: Real statistical models properly executed in 2005 were
> remarkably close to the reality 8 years later.
> 
On that note, something Mr. Huston wrote more recently:

"A Primer on IPv4, IPv6 and Transition"
http://www.potaroo.net/ispcol/2013-04/primer.html

Discussion:
https://news.ycombinator.com/item?id=5586519

-- 
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post - http://goo.gl/YrmAb
Don't CC me! I'm subscribed to whatever list I just posted on.


From silvertip257 at gmail.com  Wed Apr 24 00:31:36 2013
From: silvertip257 at gmail.com (SilverTip257)
Date: Tue, 23 Apr 2013 20:31:36 -0400
Subject: KVM
Message-ID: <CA+W-zopQGMv4qtEB-eX84ULrw+Hai_khATvSM=gKaeA8actDFA@mail.gmail.com>

> Date: Tue, 23 Apr 2013 17:40:32 -0400
> From: Jared Mauch <jared at puck.nether.net>
> To: shawn wilson <ag4ve.us at gmail.com>
> Cc: North American Network Operators Group <nanog at nanog.org>
> Subject: Re: KVM
> Message-ID: <C6B156A1-FBA8-47E6-99D4-22FF3B06DEF5 at puck.nether.net>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:
>
> > I'm looking at an IP-KVM. I don't need anything high res as I only
> > need to see Linux consoles, BIOS, and RAID. What I am looking for:
> > Non-Java client that runs on Linux (or a WebUI that will deploy a
> > decent RDP or VNC session over SSL).
> > Decent/configurable key mappings (ie, I've had a KVM a while ago where
> > you had to pull down a menu for F-keys - not cool).
> > Decently priced dongles (say ~$100?)
> >
> > I started looking at the Raritan devices (which can be found really
> > cheap on ebay) but I only see a Java client and no mention of
> > installing a client on Linux.
>
> I've used the star tech devices in the past.  Most modern systems have
> some sort of RDP or Java thing on the IPMI that mostly work.
>

If your hardware has a Baseboard Management Controller (BMC) or Integrated
Lights Out Management (iLOM) that supports IPMI v2 or later use it.  IPMI
v2 allows for Serial over LAN access [0].  I use SoL with Linux on Dell
hardware (BMC) using OpenIPMI tools.  You set the BMC to attach to a serial
port and have a getty listen on the port as well.  On my hardware there's
one virtual and one physical serial port so I configure the SoL set up on
ttyS1 (second serial) so I don't tie up the physical serial port.

You could create similar set ups with serial consoles/terminal servers and
servers that have serial ports on them ... have a getty listen on the
serial interface.

If a terminal/console is enough and you don't need VGA/X-Windows access
then SoL or a physical serial connection would suffice.

An IP-KVM is not worthless, but why buy more hardware if you have other
options? (SoL capability especially)


>
> - Jared
>
>
>
[0]
http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-specifications.html


-- 
---~~.~~---
Mike
//  SilverTip257  //

From toddunder at gmail.com  Wed Apr 24 14:55:58 2013
From: toddunder at gmail.com (Todd Underwood)
Date: Wed, 24 Apr 2013 07:55:58 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51770CE4.3070305@staticsafe.ca>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <20130423220423.GA98069@ussenterprise.ufp.org>
 <51770CE4.3070305@staticsafe.ca>
Message-ID: <CAB2RJyg8tyu5=vKiSXMt0vYDPYKZfoB80sYyvMKB17pXAVDULA@mail.gmail.com>

this is still my favorite post on this subject:

http://mailman.nanog.org/pipermail/nanog/2011-February/031737.html

t


On Tue, Apr 23, 2013 at 3:36 PM, staticsafe <me at staticsafe.ca> wrote:

> On 4/23/2013 18:04, Leo Bicknell wrote:
> > In a message written on Tue, Apr 23, 2013 at 05:41:40PM -0400,
> > Valdis Kletnieks wrote:
> >> I didn't see any mention of this Tony Hain paper:
> >>
> >> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
> >>
> >> tl;dr: ARIN predicted to run out of IP space to allocate in
> >> August this year.
> >
> > Here's a Geoff Houston report from 2005:
> >
> https://www.arin.net/participate/meetings/reports/ARIN_XVI/PDF/wednesday/huston_ipv4_roundtable.pdf
> >
> >  I point to page 8, and the prediction "RIR Pool Exhaustion, 4
> > June 2013".
> >
> > Those of us who paid attention are well prepared.
> >
> > tl;dr: Real statistical models properly executed in 2005 were
> > remarkably close to the reality 8 years later.
> >
> On that note, something Mr. Huston wrote more recently:
>
> "A Primer on IPv4, IPv6 and Transition"
> http://www.potaroo.net/ispcol/2013-04/primer.html
>
> Discussion:
> https://news.ycombinator.com/item?id=5586519
>
> --
> staticsafe
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
> Please don't top post - http://goo.gl/YrmAb
> Don't CC me! I'm subscribed to whatever list I just posted on.
>
>

From ikiris at gmail.com  Wed Apr 24 15:26:56 2013
From: ikiris at gmail.com (Blake Dunlap)
Date: Wed, 24 Apr 2013 10:26:56 -0500
Subject: Comcast NOC - issues to/from AS13331 (Seattle)
In-Reply-To: <BLU166-W48F57EA545B361A434E8F289B50@phx.gbl>
References: <CAHDg04tGvXUpKXGesc4RhC6dfd+XD3miSUERP1uswJf5z8FyUA@mail.gmail.com>
 <BLU166-W48F57EA545B361A434E8F289B50@phx.gbl>
Message-ID: <CAJvB4t=0RCxrXtH_=KUa5xZryQTnz2bddGETFVXEyPdEY983iA@mail.gmail.com>

If you search the nanog archives for Comcast, you'll see a long history of
discussions like this one, and the suspected/supposed reasons for their
behavior in relation to the rest of the net.

-Blake

From Lee at asgard.org  Wed Apr 24 16:19:40 2013
From: Lee at asgard.org (Lee Howard)
Date: Wed, 24 Apr 2013 12:19:40 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
Message-ID: <CD9D7504.1BA1A%Lee@asgard.org>



On 4/23/13 7:44 PM, "Geoff Huston" <gih at apnic.net> wrote:

>On 24/04/2013, at 8:10 AM, Andrew Latham <lathama at gmail.com> wrote:
>
>> On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
>> <Valdis.Kletnieks at vt.edu> wrote:
>>> I didn't see any mention of this Tony Hain paper:
>>> 
>>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>>> 
>>> ARIN predicted to run out of IP space to allocate in August this year.
>>> 
>>> Are you ready?
>> 
>
>The prediction of runout business is extremely hard. All of these
>predictions are based on the basic premise that what happened yesterday
>will most likely happen tomorrow.

If I were any good at predicting things, I would use my powers for evil.
Your model and Tony's differ largely on how many "yesterdays" are
considered; and, Tony's new model weights yesterday more heavily than
yesteryear, on the guess that recent history is more predictive than
distant past history.

Meanwhile. . . 


>actors. In the address world it was observed that less than 1% (its
>closer to around 0.5%)  individual allocations account for more than half
>of the number of allocated addresses. This becomes a problem in the
>predictive models, as the dominant factor in address consumption is now
>the actions of some 20 or so very large entities.

Fortunately, very large companies are slow to change.
Also, John Curran said during discussion at PPML of extra-regional
allocations: "At the current rate, this is the majority of allocations
we're making."  So, a different 0.5% than most people are probably
thinking of.

I believe he said this growth trend "Leads to a runout Q4-2013 or Q1-2014,
with certainty." 




>
>Following a single largish allocation in early 2012 we've seen the ARIN
>address consumption rate increase somewhat, and the average rate of
>address consumption is currently around 2M addresses per month. If this
>rate of address consumption continues, the ARIN will reach its last /8 in
>early 2014, and if this rate persists, then the registry will exhaust its
>pool around the end of that year, or early 2015.


Sorry, is this to say, "If this rate of consumption continues" or "If this
rate of increase continues"?  I believe the difference is that several
organizations are rapidly progressing through ARIN slow start, using their
space in significantly less than three months.


>
>However, personally I find it a little hard to place a high probability
>on Tony's projected exhaustion date of August this year. I also have to
>qualify that by noting that while I think that a runout of the remaining
>40 M addresses within 4 months is improbable, its by no means impossible.
>If we saw a re-run of the address consumption rates that ARIN experienced
>in 2010, then it's not outside the bounds of plausibility that ARIN will
>be handing out its last address later this year.

It largely depends on whether the new organizations getting address space
hit a growth ceiling (or plateau).  If they do so soon, we return to the
nearly linear Potaroo Projection.  If they continue to grow (especially if
they represent a new business model and others follow suit) then the Hain
Hypothesis holds.

Lee


> 
>
>thanks,
>
>Geoff
>
>
>
>




From Lee at asgard.org  Wed Apr 24 16:55:24 2013
From: Lee at asgard.org (Lee Howard)
Date: Wed, 24 Apr 2013 12:55:24 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
Message-ID: <CD9D7E89.1BA4F%Lee@asgard.org>



On 4/24/13 10:18 AM, "Andrew Latham" <lathama at gmail.com> wrote:

>* Tore
>
>On Wed, Apr 24, 2013 at 1:46 AM, Tore Anderson <tore at fud.no> wrote:
>> * Andrew Latham
>>
>>> I have sadly witnessed a growing number of businesses with /24s
>>> moving to colocation/aws networks and not giving up their unused
>>> network space. I assume this will come into play soon.
>>
>> A couple of /24s being returned wouldn't make a significant difference
>> when it comes to IPv4 depletion. Heck, not even a couple of /8s would.
>> Trying to reclaim and redistribute unused space would be a tremendous
>> waste of effort.
>
>If I can walk around a smallish town and point at 5 businesses like
>this its a possible solution.  I am not claiming a few /24s will do, I
>am claiming that there are many (for larger values of many) companies
>like this.

Look at NRO statistics prior to APNIC and RIPE final /8 (runout).  It's
pretty linear growth. Is that the real demand for IPv4 addresses?  In the
last couple of years it was 10-15 /8 equivalents.

How many addresses do you think can be released (whether reclaimed or, as
is more likely, brought into the market)?  A /8?  Five /8s?  Say it's a
billion addresses made available to a market.  That only feeds demand for
18-30 months.  

A demand curve would show that as prices increase, there is demand for
fewer IPv4 addresses.  However, nobody knows the slope of the curve (other
than my speculation about cost of IPv6 and TCO of CGN as points where the
demand shifts).  A supply curve would show that as prices increase, more
addresses become available (transfers, renumbering, eventually
substitution).  I'm working on ideas about that slope.

Lee




From lathama at gmail.com  Wed Apr 24 16:59:50 2013
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 24 Apr 2013 12:59:50 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CD9D7E89.1BA4F%Lee@asgard.org>
References: <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <CD9D7E89.1BA4F%Lee@asgard.org>
Message-ID: <CA+qj4S_KoSeEyM3Tnr-pQp0R09f-eftH27MJuv6SfygMhuhvzw@mail.gmail.com>

On Wed, Apr 24, 2013 at 12:55 PM, Lee Howard <Lee at asgard.org> wrote:
>
>
> On 4/24/13 10:18 AM, "Andrew Latham" <lathama at gmail.com> wrote:
>
>>* Tore
>>
>>On Wed, Apr 24, 2013 at 1:46 AM, Tore Anderson <tore at fud.no> wrote:
>>> * Andrew Latham
>>>
>>>> I have sadly witnessed a growing number of businesses with /24s
>>>> moving to colocation/aws networks and not giving up their unused
>>>> network space. I assume this will come into play soon.
>>>
>>> A couple of /24s being returned wouldn't make a significant difference
>>> when it comes to IPv4 depletion. Heck, not even a couple of /8s would.
>>> Trying to reclaim and redistribute unused space would be a tremendous
>>> waste of effort.
>>
>>If I can walk around a smallish town and point at 5 businesses like
>>this its a possible solution.  I am not claiming a few /24s will do, I
>>am claiming that there are many (for larger values of many) companies
>>like this.
>
> Look at NRO statistics prior to APNIC and RIPE final /8 (runout).  It's
> pretty linear growth. Is that the real demand for IPv4 addresses?  In the
> last couple of years it was 10-15 /8 equivalents.
>
> How many addresses do you think can be released (whether reclaimed or, as
> is more likely, brought into the market)?  A /8?  Five /8s?  Say it's a
> billion addresses made available to a market.  That only feeds demand for
> 18-30 months.
>
> A demand curve would show that as prices increase, there is demand for
> fewer IPv4 addresses.  However, nobody knows the slope of the curve (other
> than my speculation about cost of IPv6 and TCO of CGN as points where the
> demand shifts).  A supply curve would show that as prices increase, more
> addresses become available (transfers, renumbering, eventually
> substitution).  I'm working on ideas about that slope.
>
> Lee


Lee

Totally agree, your point is the larger issue at hand, just pointing
out and ugly issue that I witnessed recently.  Corporate networks and
ASNs totally off and not in use.  But don't worry, they will use them
if someone tries to take them away.



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


From drc at virtualized.org  Wed Apr 24 17:26:49 2013
From: drc at virtualized.org (David Conrad)
Date: Wed, 24 Apr 2013 10:26:49 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S_KoSeEyM3Tnr-pQp0R09f-eftH27MJuv6SfygMhuhvzw@mail.gmail.com>
References: <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <CD9D7E89.1BA4F%Lee@asgard.org>
 <CA+qj4S_KoSeEyM3Tnr-pQp0R09f-eftH27MJuv6SfygMhuhvzw@mail.gmail.com>
Message-ID: <EEDF1F2A-4A0F-42B3-9460-BD0805503288@virtualized.org>

On Apr 24, 2013, at 9:59 AM, Andrew Latham <lathama at gmail.com> wrote:
>> A demand curve would show that as prices increase, there is demand for fewer IPv4 addresses.

And the other side of the coin: where there is demand and excess supply (e.g., allocated but unused addresses), the price increase would create an incentive to sell off the excess (i.e., what we're seeing in the IPv4 trading markets).

> Totally agree, your point is the larger issue at hand, just pointing
> out and ugly issue that I witnessed recently.  Corporate networks and
> ASNs totally off and not in use.  But don't worry, they will use them
> if someone tries to take them away.

Or they'll sell/lease them. The prospective address consumer then can figure out whether paying the buy/rent price for new IPv4 addresses makes sense compared to moving to IPv6+translation or buying (more) CGN.

Regards,
-drc



From tore at fud.no  Wed Apr 24 17:33:16 2013
From: tore at fud.no (Tore Anderson)
Date: Wed, 24 Apr 2013 19:33:16 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
Message-ID: <5178175C.2050103@fud.no>

* Andrew Latham

> If I can walk around a smallish town and point at 5 businesses like
> this its a possible solution.  I am not claiming a few /24s will do, I
> am claiming that there are many (for larger values of many) companies
> like this.

There are certainly several thousands or even millions of unused IPv4
addresses in existence. But reclaiming and redistributing it, which
would be a colossal undertaking, would only push back IPv4 depletion by
a few months. It's simply not worth the effort.

>>> I have already read the news of blackmarket sales of network
>>> allocations in Europe.
>>
>> Interesting. Do you have a link or some other kind of reference?
> 
> I did a quick search and they are easy to find. Many news articles
> about Microsoft buying network allocations at auction to set a price
> of ~$11USD per IP. One tangent article that I liked was

Sure, there's a market all right. However, the well publicised
Microsoft/Nortel transfer wasn't a "black market" transfer, it was done
in accordance with the ARIN community's policies. Straight from the
horse's mouth:

https://www.arin.net/about_us/media/releases/20110415.html

Such transfers are also permitted by the community's policies in the
RIPE region, and the NCC maintains a public list of all such
legit/"white" transfers that have taken place:

https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers

>
http://www.datacenterknowledge.com/archives/2012/07/16/ipv4-addresses-now-driving-hosting-deals/

This article mentions a "black market", but it falls short of providing
any tangible evidence that it really exists, or to what extent - it
appears to me to be more speculation and conjecture than anything else.

That said - such speculation may well turn out to be correct, of course,
and being involved in the RIPE community I'm genuinely interested in the
topic. Therefore I was hoping you'd point me in the direction of "the
news of blackmarket sales of network allocations in Europe" you
mentioned you have read.

Tore


From lathama at gmail.com  Wed Apr 24 17:35:42 2013
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 24 Apr 2013 13:35:42 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <5178175C.2050103@fud.no>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <5178175C.2050103@fud.no>
Message-ID: <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>

*Tore

<snip>

> That said - such speculation may well turn out to be correct, of course,
> and being involved in the RIPE community I'm genuinely interested in the
> topic. Therefore I was hoping you'd point me in the direction of "the
> news of blackmarket sales of network allocations in Europe" you
> mentioned you have read.
>
> Tore

I am digging though the some old posts.  I seam to remember the
article was not in English and I posted it with a link/via Google
Translate. Sorry for being so slow.

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


From lathama at gmail.com  Wed Apr 24 17:42:00 2013
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 24 Apr 2013 13:42:00 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <5178175C.2050103@fud.no>
 <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>
Message-ID: <CA+qj4S-K4MN6qgT7oWwWZyuUJLpArV6C=Woem2wXWVxm1LDaUw@mail.gmail.com>

FYI, What can ARIN, RIPE et al do to reclaim
http://www.spamhaus.org/drop/drop.txt networks?

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


From morrowc.lists at gmail.com  Wed Apr 24 17:53:17 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 24 Apr 2013 13:53:17 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S-K4MN6qgT7oWwWZyuUJLpArV6C=Woem2wXWVxm1LDaUw@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <5178175C.2050103@fud.no>
 <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>
 <CA+qj4S-K4MN6qgT7oWwWZyuUJLpArV6C=Woem2wXWVxm1LDaUw@mail.gmail.com>
Message-ID: <CAL9jLaZy28xr+ygJru4Q9jGMdU8HCipdXh2=q1FFaiHhNtS6aQ@mail.gmail.com>

On Wed, Apr 24, 2013 at 1:42 PM, Andrew Latham <lathama at gmail.com> wrote:

> FYI, What can ARIN, RIPE et al do to reclaim
> http://www.spamhaus.org/drop/drop.txt networks?
>


nothing since they don't control routability of the prefixes in question?

From lathama at gmail.com  Wed Apr 24 17:53:13 2013
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 24 Apr 2013 13:53:13 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <5178175C.2050103@fud.no>
 <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>
Message-ID: <CA+qj4S_3Kfrhj8fpaD2h+=8hBHOOr9nDoYpyCFz6t78Tvqcuvg@mail.gmail.com>

Black market is probably not the best phrase for the sources I have
dug up today but here goes.

Market Places
http://addrex.net/
http://www.hilcostreambank.com/IPv4.asp
http://www.kalorama.com/en/IPv4-IPv6-Advisory/IPv4-Acquisition-and-Divestiture/

News
http://www.networkworld.com/news/2011/041411-apnic-ipv4-gone.html
http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in-possession-of-169-million-unused-ipv4-addresses
http://www.networkworld.com/news/2011/042511-ipv4-sales.html
http://www.forbes.com/sites/ciocentral/2011/09/15/pssst-rare-ipv4-addresses-for-sale-get-them-while-you-can/
http://www.internetgovernance.org/2012/02/14/a-whole-8-for-sale/
http://www.prweb.com/releases/ipv4-ip-address/sale/prweb9552646.htm
http://isc.sans.edu/diary/What's+Your+(IP)+Address+Worth%3F++/10765

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


From Valdis.Kletnieks at vt.edu  Wed Apr 24 17:58:50 2013
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 24 Apr 2013 13:58:50 -0400
Subject: UN Secretariat building in nyc
In-Reply-To: Your message of "Tue, 23 Apr 2013 20:13:20 -0400."
 <C17FBD32-4AAA-48E4-BDB1-F1FC6C183B41@gmail.com>
References: <C17FBD32-4AAA-48E4-BDB1-F1FC6C183B41@gmail.com>
Message-ID: <6439.1366826330@turing-police.cc.vt.edu>

On Tue, 23 Apr 2013 20:13:20 -0400, Chris McDonald said:
> Does anyone have a creative (read - fast) way of getting from the mmr there to 60 Hudson ?

Taxi? :)

Would help if you told us what exactly you were trying to get from
point A to point B, and in what quantities.  What will work well for
megabits may not work for gigabits, and dark fiber/ATM/whatever may
matter as well...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130424/dfd5a95f/attachment.bin>

From copraphage at gmail.com  Wed Apr 24 18:08:18 2013
From: copraphage at gmail.com (Chris McDonald)
Date: Wed, 24 Apr 2013 14:08:18 -0400
Subject: UN Secretariat building in nyc
In-Reply-To: <6439.1366826330@turing-police.cc.vt.edu>
References: <C17FBD32-4AAA-48E4-BDB1-F1FC6C183B41@gmail.com>
 <6439.1366826330@turing-police.cc.vt.edu>
Message-ID: <D95DEE66-E1D4-47F6-B2BF-4D1A2E91BD56@gmail.com>

:)

long story short-- we've got a customer ptp ds3 in there now that we're attempting to relocate but it's become a cluster.

really willing to look at just about anything now that can happen quickly-- including plain old ip at the UN building.

thanks
chris




On Apr 24, 2013, at 1:58 PM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 23 Apr 2013 20:13:20 -0400, Chris McDonald said:
>> Does anyone have a creative (read - fast) way of getting from the mmr there to 60 Hudson ?
> 
> Taxi? :)
> 
> Would help if you told us what exactly you were trying to get from
> point A to point B, and in what quantities.  What will work well for
> megabits may not work for gigabits, and dark fiber/ATM/whatever may
> matter as well...



From ml at kenweb.org  Wed Apr 24 18:45:04 2013
From: ml at kenweb.org (ML)
Date: Wed, 24 Apr 2013 14:45:04 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <45779.1366753300@turing-police.cc.vt.edu>
References: <45779.1366753300@turing-police.cc.vt.edu>
Message-ID: <51782830.6010706@kenweb.org>

On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:
> I didn't see any mention of this Tony Hain paper:
>
> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>
> tl;dr: ARIN predicted to run out of IP space to allocate in August this year.
>
> Are you ready?
>


Where do the startup ISPs whom didn't qualify for PI IPv4 in the past
fit into a post-run out world where they would qualify?
I am speaking in generics but also about a real ISP that is in this
situation today. 

In my example This ISP could show need for a /22 but wasn't multihoming
at the time and likely will not until after run-out. 
How does such an ISP begin to address their backbone and customers
facing interfaces without tying themselves to an ISP and their PA space?

I don't imagine they will be open to paying extortion prices for IPs
that other people never bothered to use.


From owen at delong.com  Wed Apr 24 18:49:08 2013
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Apr 2013 14:49:08 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51782830.6010706@kenweb.org>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <51782830.6010706@kenweb.org>
Message-ID: <BAB242D8-33F9-4E49-9B26-411F6349C910@delong.com>


On Apr 24, 2013, at 2:45 PM, ML <ml at kenweb.org> wrote:

> On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:
>> I didn't see any mention of this Tony Hain paper:
>> 
>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>> 
>> tl;dr: ARIN predicted to run out of IP space to allocate in August this year.
>> 
>> Are you ready?
>> 
> 
> 
> Where do the startup ISPs whom didn't qualify for PI IPv4 in the past
> fit into a post-run out world where they would qualify?
> I am speaking in generics but also about a real ISP that is in this
> situation today. 
> 
> In my example This ISP could show need for a /22 but wasn't multihoming
> at the time and likely will not until after run-out. 
> How does such an ISP begin to address their backbone and customers
> facing interfaces without tying themselves to an ISP and their PA space?
> 
> I don't imagine they will be open to paying extortion prices for IPs
> that other people never bothered to use.

As it currently stands in the ARIN region, the qualifications for transfer and for
obtaining space from the free pool are identical. Currently, the only difference
is that they could obtain 24 months worth of address space via transfer and
only 3 months from the free pool.

Bottom line, anyone building a business today depending on the continued
availability of an IPv4 free pool from an RIR is taking on a very high degree
of risk. IMHO, such a business plan would be ill-advised, to say the least.

Owen




From Lee at asgard.org  Wed Apr 24 19:35:09 2013
From: Lee at asgard.org (Lee Howard)
Date: Wed, 24 Apr 2013 15:35:09 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51782830.6010706@kenweb.org>
Message-ID: <CD9DABA9.1BAE4%Lee@asgard.org>



On 4/24/13 2:45 PM, "ML" <ml at kenweb.org> wrote:

>On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:
>> I didn't see any mention of this Tony Hain paper:
>>
>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>>
>> tl;dr: ARIN predicted to run out of IP space to allocate in August this
>>year.
>>
>> Are you ready?
>>
>
>
>Where do the startup ISPs whom didn't qualify for PI IPv4 in the past
>fit into a post-run out world where they would qualify?
>I am speaking in generics but also about a real ISP that is in this
>situation today. 
>
>In my example This ISP could show need for a /22 but wasn't multihoming
>at the time and likely will not until after run-out.
>How does such an ISP begin to address their backbone and customers
>facing interfaces without tying themselves to an ISP and their PA space?
>
>I don't imagine they will be open to paying extortion prices for IPs
>that other people never bothered to use.


Once ARIN is unable to meet an organization's justified need, they can't
get addresses from ARIN.  They can beg, borrow or buy addresses from
someone else.  They can try AfriNIC's or LACNIC's policies.  They can do
CGN.  They can do IPv6.

Lee




From johnl at iecc.com  Wed Apr 24 19:54:31 2013
From: johnl at iecc.com (John Levine)
Date: 24 Apr 2013 19:54:31 -0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51782830.6010706@kenweb.org>
Message-ID: <20130424195431.35513.qmail@joyce.lan>

>I don't imagine they will be open to paying extortion prices for IPs
>that other people never bothered to use.

You know, sometimes life is just unfair.  If they need the space,
they'll have to figure out how to buy it.








From alh-ietf at tndh.net  Wed Apr 24 20:08:34 2013
From: alh-ietf at tndh.net (Tony Hain)
Date: Wed, 24 Apr 2013 13:08:34 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CD9D7504.1BA1A%Lee@asgard.org>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org>
Message-ID: <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>

Lee Howard wrote:
> On 4/23/13 7:44 PM, "Geoff Huston" <gih at apnic.net> wrote:
> 
> >On 24/04/2013, at 8:10 AM, Andrew Latham <lathama at gmail.com> wrote:
> >
> >> On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks
> >> <Valdis.Kletnieks at vt.edu> wrote:
> >>> I didn't see any mention of this Tony Hain paper:
> >>>
> >>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
> >>>
> >>> ARIN predicted to run out of IP space to allocate in August this year.
> >>>
> >>> Are you ready?
> >>
> >
> >The prediction of runout business is extremely hard. All of these
> >predictions are based on the basic premise that what happened yesterday
> >will most likely happen tomorrow.
> 
> If I were any good at predicting things, I would use my powers for evil.
> Your model and Tony's differ largely on how many "yesterdays" are
> considered; and, Tony's new model weights yesterday more heavily than
> yesteryear, on the guess that recent history is more predictive than
distant
> past history.

Indeed, the current set of actors appears to be different than the
historical set, with a very different deployment-model/demand-curve. 

> 
> Meanwhile. . .
> 
> 
> >actors. In the address world it was observed that less than 1% (its
> >closer to around 0.5%)  individual allocations account for more than
> >half of the number of allocated addresses. This becomes a problem in
> >the predictive models, as the dominant factor in address consumption is
> >now the actions of some 20 or so very large entities.
> 
> Fortunately, very large companies are slow to change.
> Also, John Curran said during discussion at PPML of extra-regional
> allocations: "At the current rate, this is the majority of allocations
we're
> making."  So, a different 0.5% than most people are probably thinking of.
> 
> I believe he said this growth trend "Leads to a runout Q4-2013 or Q1-2014,
> with certainty."
> 
> 
> 
> 
> >
> >Following a single largish allocation in early 2012 we've seen the ARIN
> >address consumption rate increase somewhat, and the average rate of
> >address consumption is currently around 2M addresses per month. If this
> >rate of address consumption continues, the ARIN will reach its last /8
> >in early 2014, and if this rate persists, then the registry will
> >exhaust its pool around the end of that year, or early 2015.
> 
> 
> Sorry, is this to say, "If this rate of consumption continues" or "If this
rate of
> increase continues"?  I believe the difference is that several
organizations are
> rapidly progressing through ARIN slow start, using their space in
significantly
> less than three months.

I only looked at organizations that had multiple allocations larger than a
/20 in the last 9 months. There may well be as many, or more that have had
multiple /22,/21,/20 sequences in that window, but if they are that small at
this point, they might never get to a /16 before the pool runs out if the
larger ones keep going. 

> 
> 
> >
> >However, personally I find it a little hard to place a high probability
> >on Tony's projected exhaustion date of August this year.

I was not trying to place any probability on the outcome, and would tend to
agree with you that August 2013 is not particularly likely, but would say it
much more likely than having anything left by August 2014. That said, a new
set of players showing compound growth in short timeframes is not what the
historical-model projections are based on, so we do need to look more at
current behavior than the distant past.

> > I also have to
> >qualify that by noting that while I think that a runout of the
> >remaining
> >40 M addresses within 4 months is improbable, its by no means impossible.
> >If we saw a re-run of the address consumption rates that ARIN
> >experienced in 2010, then it's not outside the bounds of plausibility
> >that ARIN will be handing out its last address later this year.
> 
> It largely depends on whether the new organizations getting address space
> hit a growth ceiling (or plateau).  If they do so soon, we return to the
nearly
> linear Potaroo Projection.  If they continue to grow (especially if they
> represent a new business model and others follow suit) then the Hain
> Hypothesis holds.

There is another open question about the growth rate in the number of new
players showing compound growth in deployments. It may not be that any of
them individually gets large enough to make a significant dent on their own,
but if there is compound growth in the number of new slow-start actors, you
still have compound growth in demand, but you may not be looking in the
right place to see why the numbers are large enough to matter.


The really troubling thing that I don't get is why RR got a pile of little
blocks rather than a /12 up front. I don't know if that is an impact of
broken policy, internal deployment decisions about 'right size' allocations
rather than intentional deaggregation, or trying to 'fly under the radar'.
If it is a policy problem it might be worth trying to understand and maybe
fix any long term impact on market transfers. 

Tony


> 
> Lee
> 
> 
> >
> >
> >thanks,
> >
> >Geoff
> >
> >
> >
> >
> 




From m.hallgren at free.fr  Wed Apr 24 21:12:43 2013
From: m.hallgren at free.fr (Michael Hallgren)
Date: Wed, 24 Apr 2013 23:12:43 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CD9DABA9.1BAE4%Lee@asgard.org>
References: <CD9DABA9.1BAE4%Lee@asgard.org>
Message-ID: <51784ACB.1090204@free.fr>

Le 24/04/2013 21:35, Lee Howard a ?crit :
>
> On 4/24/13 2:45 PM, "ML" <ml at kenweb.org> wrote:
>
>> On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:
>>> I didn't see any mention of this Tony Hain paper:
>>>
>>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>>>
>>> tl;dr: ARIN predicted to run out of IP space to allocate in August this
>>> year.
>>>
>>> Are you ready?
>>>
>>
>> Where do the startup ISPs whom didn't qualify for PI IPv4 in the past
>> fit into a post-run out world where they would qualify?
>> I am speaking in generics but also about a real ISP that is in this
>> situation today. 
>>
>> In my example This ISP could show need for a /22 but wasn't multihoming
>> at the time and likely will not until after run-out.
>> How does such an ISP begin to address their backbone and customers
>> facing interfaces without tying themselves to an ISP and their PA space?
>>
>> I don't imagine they will be open to paying extortion prices for IPs
>> that other people never bothered to use.
>
> Once ARIN is unable to meet an organization's justified need, they can't
> get addresses from ARIN.  They can beg, borrow or buy addresses from
> someone else.  They can try AfriNIC's or LACNIC's policies.  They can do
> CGN.  They can do IPv6.

Might be that IPv6would be their currently best bet... ;)
mh

>
> Lee
>
>
>



From fred at cisco.com  Wed Apr 24 22:26:09 2013
From: fred at cisco.com (Fred Baker (fred))
Date: Wed, 24 Apr 2013 22:26:09 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
Message-ID: <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>

I guess my question is what the difference is between the sharp-demand curve (Tony's latest, which perhaps mirrors APNIC's final few months of IPv4) and the straight-line curve. My read is that we're arguing about the difference between "late 2013" and "some time in 2014". I suspect that what most ISPs are going to find necessary is some combination of keeping the lights burning in IPv4-land, by whatever means, and deploying the next generation.

Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.

http://www.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Support/Top+Questions/QuestionsOne/ATLAS8742.htm
http://www.worldipv6launch.org/measurements/

Where we're having trouble is in enterprise and residential deployments. Enterprise tends to view the address space run-out as Somebody Else's Problem - behind their NATs, they generally have enough address space to work with. On the residential side, the X-Box is still IPv4-only, Skype is still IPv4-only, the vast majority of residential gateways used by broadband subscribers are IPv4-only.

Some broadband ISPs are taking steps toward a managed service offering, by selling their customers a replacement router. If the router is IPv6-capable, that helps.

If we really want to help the cause, I suspect that focusing attention on enterprise, and finding ways to convince them that address shortages are also their problem, will help the most.

From streiner at cluebyfour.org  Wed Apr 24 22:48:45 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 24 Apr 2013 18:48:45 -0400 (EDT)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
Message-ID: <Pine.LNX.4.64.1304241847270.28792@whammy.cluebyfour.org>

On Wed, 24 Apr 2013, Fred Baker (fred) wrote:

> http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Support/Top+Questions/QuestionsOne/ATLAS8742.htm

One minor typo in this one, that I've emailed Verizon's webmasters about 
in the past.

A /56 does not give you 56 LANs...

jms


From mike at mtcc.com  Wed Apr 24 23:50:10 2013
From: mike at mtcc.com (Michael Thomas)
Date: Wed, 24 Apr 2013 16:50:10 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
Message-ID: <51786FB2.3090505@mtcc.com>

On 04/24/2013 03:26 PM, Fred Baker (fred) wrote:
>
> Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.
>
>

Fred, isn't the larger problem those enterprise's outward facing web presence,
etc? As great as it is that vzw is deploying on handsets, don't they also need
to dual-stack and by inference cgn (eventually) so that their customers can get
at the long tail of non-v6 sites?

Mike


From fred at cisco.com  Thu Apr 25 00:34:36 2013
From: fred at cisco.com (Fred Baker (fred))
Date: Thu, 25 Apr 2013 00:34:36 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51786FB2.3090505@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <51786FB2.3090505@mtcc.com>
Message-ID: <8C48B86A895913448548E6D15DA7553B8213BC@xmb-rcd-x09.cisco.com>


On Apr 24, 2013, at 4:50 PM, Michael Thomas <mike at mtcc.com>
 wrote:

> On 04/24/2013 03:26 PM, Fred Baker (fred) wrote:
>> 
>> Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.
> 
> Fred, isn't the larger problem those enterprise's outward facing web presence,
> etc? As great as it is that vzw is deploying on handsets, don't they also need
> to dual-stack and by inference cgn (eventually) so that their customers can get
> at the long tail of non-v6 sites?

Kind of my point. I hear a lot of complaining of the form "I don't need to deploy IPv6 because there is relatively little traffic out there." Well, surprise surprise. That's a little like me saying that I don't need to learn Chinese because nobody speaks to me in Chinese. There are a lot of Chinese speakers; they don't speak to me in Chinese, which they often prefer to speak among themselves, because I wouldn't have a clue what they were saying.

The Verizon Wireless numbers, and a list of others on the same page, tell me that if offered a AAAA record, networks and the equipment that use them will in fact use IPv6. What is in the way is the residential gateway, which is often IPv4-only, and the enterprise web and email service, which is often IPv4 only. You want to fix that, fix the residential gateway, the enterprise load balancer, and the connectivity between them and their respective upstreams.

From mike at mtcc.com  Thu Apr 25 00:41:52 2013
From: mike at mtcc.com (Michael Thomas)
Date: Wed, 24 Apr 2013 17:41:52 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8C48B86A895913448548E6D15DA7553B8213BC@xmb-rcd-x09.cisco.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <51786FB2.3090505@mtcc.com>
 <8C48B86A895913448548E6D15DA7553B8213BC@xmb-rcd-x09.cisco.com>
Message-ID: <51787BD0.5010207@mtcc.com>

On 04/24/2013 05:34 PM, Fred Baker (fred) wrote:
> On Apr 24, 2013, at 4:50 PM, Michael Thomas <mike at mtcc.com>
>   wrote:
>
>> On 04/24/2013 03:26 PM, Fred Baker (fred) wrote:
>>> Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.
>> Fred, isn't the larger problem those enterprise's outward facing web presence,
>> etc? As great as it is that vzw is deploying on handsets, don't they also need
>> to dual-stack and by inference cgn (eventually) so that their customers can get
>> at the long tail of non-v6 sites?
> Kind of my point. I hear a lot of complaining of the form "I don't need to deploy IPv6 because there is relatively little traffic out there." Well, surprise surprise. That's a little like me saying that I don't need to learn Chinese because nobody speaks to me in Chinese. There are a lot of Chinese speakers; they don't speak to me in Chinese, which they often prefer to speak among themselves, because I wouldn't have a clue what they were saying.
>
> The Verizon Wireless numbers, and a list of others on the same page, tell me that if offered a AAAA record, networks and the equipment that use them will in fact use IPv6. What is in the way is the residential gateway, which is often IPv4-only, and the enterprise web and email service, which is often IPv4 only. You want to fix that, fix the residential gateway, the enterprise load balancer, and the connectivity between them and their respective upstreams.

It's a pity that it's probably not realistic for a VZW or other large-enough carrier
to say "We have deployed ipv6, we will not deploy CGN" and let the chips fall
where they may. Basically the ipv4 death penalty. Of course VZW-wireless probably
couldn't even do that because they'd be waging war on VZW-wireline. Sigh.

Mike


From sfrost at snowman.net  Wed Apr 24 23:08:10 2013
From: sfrost at snowman.net (Stephen Frost)
Date: Wed, 24 Apr 2013 19:08:10 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <Pine.LNX.4.64.1304241847270.28792@whammy.cluebyfour.org>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org>
 <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <Pine.LNX.4.64.1304241847270.28792@whammy.cluebyfour.org>
Message-ID: <20130424230810.GN4361@tamriel.snowman.net>

* Justin M. Streiner (streiner at cluebyfour.org) wrote:
> On Wed, 24 Apr 2013, Fred Baker (fred) wrote:
> >http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Support/Top+Questions/QuestionsOne/ATLAS8742.htm
> 
> One minor typo in this one, that I've emailed Verizon's webmasters
> about in the past.
> 
> A /56 does not give you 56 LANs...

Calling Verizon and asking them for IPv6 for your Business FIOS
connection doesn't get you IPv6 either, sadly.  I'll likely give it
another shot next week, but I've been trying every month or two since
that article came out with no results.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130424/5ccb3e67/attachment.bin>

From owen at delong.com  Thu Apr 25 13:09:08 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 25 Apr 2013 09:09:08 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
Message-ID: <B1924603-5F7C-4B1C-B242-3FAB2D4D6858@delong.com>

> The really troubling thing that I don't get is why RR got a pile of little
> blocks rather than a /12 up front. I don't know if that is an impact of
> broken policy, internal deployment decisions about 'right size' allocations
> rather than intentional deaggregation, or trying to 'fly under the radar'.
> If it is a policy problem it might be worth trying to understand and maybe
> fix any long term impact on market transfers. 

IMHO, the transfer market is utterly and completely unlikely to aggregate pre-existing blocks.

If you can come up with an idea of how policy could better enable doing so, I would be very interested. However, I suspect there's nothing that can be done to policy at this point which will positively impact this problem.

In terms of a proposal to help the free pool, I suspect the time it would take to get such a policy through the process would exceed the duration of the free pool. (Especially if your (Mr. Hain) projections are at all accurate).

Bottom line:

Since we started deploying NAT, IPv4 has become progressively more painful.
That pain is going to continue to increase. The rate of increase is going to accelerate.
IPv6 is relatively painless.
IPv6 provides a host of new opportunities.
It's time to do IPv6.

Owen



From owen at delong.com  Thu Apr 25 13:25:33 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 25 Apr 2013 09:25:33 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
Message-ID: <136DC15E-BE36-446E-A849-9B38A3B2F1C6@delong.com>

> Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.
> 
> http://www.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
> http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Support/Top+Questions/QuestionsOne/ATLAS8742.htm
> http://www.worldipv6launch.org/measurements/
> 

As an iPhone 5 user on VZW, I can say that they have done a really good job of deploying IPv6 on both 3GPP and LTE networks. My phone runs dual-stack everywhere I'm not roaming so far. Performance over IPv6 has been at least as good as performance over IPv4.

While I'm not a huge VZW fan, they really have done this well and other carriers should look to them as a model for IPv6 deployment on cellular.

The one unfortunate aspect is that if you are on an IPv4-only WiFi network, you will be unable to access any IPv6 sites via the carrier network and they will, instead, fail. For the moment, while there are not many IPv6-only websites, this is probably not a significant drawback. It's probably intended as a workaround for the "IPv6 Unexpected Data Bill" problem.

> Where we're having trouble is in enterprise and residential deployments. Enterprise tends to view the address space run-out as Somebody Else's Problem - behind their NATs, they generally have enough address space to work with. On the residential side, the X-Box is still IPv4-only, Skype is still IPv4-only, the vast majority of residential gateways used by broadband subscribers are IPv4-only.

"We have enough address space" doesn't really take into account the fact that you probably aren't on the internet only to talk to yourself. If you want the users behind your NAT to be able to talk to the InterNET and not just the IPv4 InterNAT, then you're going to need to give them some form of IPv6 capability.

The residential side is a problem which I believe will solve itself relatively quickly over the next 5-7 years. The cost of maintaining residential IPv4 service beyond that point (indeed, even to that point) is going to result in costs per subscriber that exceed current billing rates. Just to break even, most providers will have to convince their subscribers to pay approximately double what they currently pay while accepting progressively more degraded IPv4 service.

Indeed, there are some models emerging that show that the cost of lost customers by switching residential to IPv6-only is likely less than the cost of maintaining customers on IPv4.

> Some broadband ISPs are taking steps toward a managed service offering, by selling their customers a replacement router. If the router is IPv6-capable, that helps.

This is becoming more popular. Other ISPs are also specifying IPv6-compatible equipment that their customers can upgrade to.

> If we really want to help the cause, I suspect that focusing attention on enterprise, and finding ways to convince them that address shortages are also their problem, will help the most.

Actually, if you want to have the biggest and best impact, it's getting the rest of the Alexa 1,000 onto IPv6.

Eyeball and Enterprise conversion will happen soon enough out of necessity. However, if content is still not available on IPv6 at that point, it will drive strange contortions to attempt to keep IPv4 on progressively more complex and delicate forms of life support. If the content is all available on IPv6, then it will be mostly a non-event to start turning up IPv6-only end-users.

Owen



From owen at delong.com  Thu Apr 25 13:26:39 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 25 Apr 2013 09:26:39 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <Pine.LNX.4.64.1304241847270.28792@whammy.cluebyfour.org>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <Pine.LNX.4.64.1304241847270.28792@whammy.cluebyfour.org>
Message-ID: <B1938F66-EBC6-4C08-A258-B4BCDB270109@delong.com>


On Apr 24, 2013, at 6:48 PM, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:

> On Wed, 24 Apr 2013, Fred Baker (fred) wrote:
> 
>> http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Support/Top+Questions/QuestionsOne/ATLAS8742.htm
> 
> One minor typo in this one, that I've emailed Verizon's webmasters about in the past.
> 
> A /56 does not give you 56 LANs?
> 

LOL? No, it's 256 LANs.

I think that's the first time I've ever seen VZ under promise. ;-)

Owen




From aservin at lacnic.net  Thu Apr 25 14:12:33 2013
From: aservin at lacnic.net (Arturo Servin)
Date: Thu, 25 Apr 2013 10:12:33 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
Message-ID: <517939D1.3050302@lacnic.net>


	Yes.

	We figured this out and we are starting a program (or a set of
activities) to promote the deployment of IPv6 in what we call "End-users
organizations" (basically enterprises, universities). We are seeing much
lower adoption numbers than our ISP's categories.

	One basic problem that we have found when talking with enterprises is
that the perceived value of deploy v6 is near to zero as they have v4
addresses (universities) or NAT.

Regards,
as

On 4/24/13 6:26 PM, Fred Baker (fred) wrote:
> If we really want to help the cause, I suspect that focusing attention on enterprise, and finding ways to convince them that address shortages are also their problem, will help the most.


From mike at mtcc.com  Thu Apr 25 15:24:47 2013
From: mike at mtcc.com (Michael Thomas)
Date: Thu, 25 Apr 2013 08:24:47 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517939D1.3050302@lacnic.net>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net>
Message-ID: <51794ABF.5040209@mtcc.com>

So here is the question I have: when we run out, is there *anything* that
will reasonably allow an ISP to *not* deploy carrier grade NAT? Assuming
that it's death for the ISP to just say no to the long tail of legacy v4-only
sites?

One thing that occurs to me though is that it's sort of in an ISP's interest
to deploy v6 on the client side because each new v6 site that lights up on
the internet side is less traffic forced through the CGN gear which is ultimately
a cost down. So maybe an alternative to a death penalty is a molasses penalty:
make the CGN experience operable but bad/congested/slow :)

Mike

On 04/25/2013 07:12 AM, Arturo Servin wrote:
> 	Yes.
>
> 	We figured this out and we are starting a program (or a set of
> activities) to promote the deployment of IPv6 in what we call "End-users
> organizations" (basically enterprises, universities). We are seeing much
> lower adoption numbers than our ISP's categories.
>
> 	One basic problem that we have found when talking with enterprises is
> that the perceived value of deploy v6 is near to zero as they have v4
> addresses (universities) or NAT.
>
> Regards,
> as
>
> On 4/24/13 6:26 PM, Fred Baker (fred) wrote:
>> If we really want to help the cause, I suspect that focusing attention on enterprise, and finding ways to convince them that address shortages are also their problem, will help the most.



From johnl at iecc.com  Thu Apr 25 15:56:21 2013
From: johnl at iecc.com (John Levine)
Date: 25 Apr 2013 15:56:21 -0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51794ABF.5040209@mtcc.com>
Message-ID: <20130425155621.65531.qmail@joyce.lan>

In article <51794ABF.5040209 at mtcc.com> you write:
>So here is the question I have: when we run out, is there *anything* that
>will reasonably allow an ISP to *not* deploy carrier grade NAT? Assuming
>that it's death for the ISP to just say no to the long tail of legacy v4-only
>sites?

Sure.  Enough money to buy the v4 space it needs.

Once people realize that there's no more free v4 space to be had, or
only little bits, that the market will develop and a lot of space will
appear for sale.  For example, there's an educational insitution near
Boston that's sitting on a /8.  If the price for a clean /12 turns out
to be $5M, which I don't think is implausible, it'll be mighty
tempting for them to renumber into one /12 and sell off the others for
a quick $75 million.

If you think I'm dreaming, look at what happened to Nortel's /8.

I entirely realize that the sound of people yelling that it's totally
unfair that other people got their space for free and now they have to
pay will be deafening.  Too bad.  Back in the early 90s I missed the
cutoff to get my own unjustified /24 by about six months, but I've
been able to deal with it.

R's,
John


From swmike at swm.pp.se  Thu Apr 25 16:11:27 2013
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 25 Apr 2013 18:11:27 +0200 (CEST)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <20130425155621.65531.qmail@joyce.lan>
References: <20130425155621.65531.qmail@joyce.lan>
Message-ID: <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>

On Thu, 25 Apr 2013, John Levine wrote:

> Once people realize that there's no more free v4 space to be had, or 
> only little bits, that the market will develop and a lot of space will 
> appear for sale.  For example, there's an educational insitution near 
> Boston that's sitting on a /8.  If the price for a clean /12 turns out 
> to be $5M, which I don't think is implausible, it'll be mighty tempting 
> for them to renumber into one /12 and sell off the others for a quick 
> $75 million.

There is a lot of speculation what IPv4 addresses are worth, I've been 
hearing everything from a few USD to 20 EUR per address.

If it's 20 EUR per address, then I agree with you that there will be a lot 
of addresses available for sale because it'll now all of a sudden be 
worthwile to renumber, start using IPv6 with NAT64, or something else, and 
get rid of your now excess IPv4 addresses. Most organisations will 
probably be able to do this with costs ranging in 0.1 - a few million 
dollars.

I like this because it makes the incentive to move to IPv6 so much higher. 
IPv4 is a dead end, the stone is bled dry, the earlier people realise this 
and move on, the better.

> I entirely realize that the sound of people yelling that it's totally 
> unfair that other people got their space for free and now they have to 
> pay will be deafening.  Too bad.  Back in the early 90s I missed the 
> cutoff to get my own unjustified /24 by about six months, but I've been 
> able to deal with it.

If there is no upside for people holding addresses to spend time/money to 
free them up, these addresses won't get freed up and transferred.

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


From bross at pobox.com  Thu Apr 25 17:10:31 2013
From: bross at pobox.com (Brandon Ross)
Date: Thu, 25 Apr 2013 13:10:31 -0400 (EDT)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51794ABF.5040209@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
Message-ID: <alpine.OSX.2.02.1304251306460.72441@brugal.local>

On Thu, 25 Apr 2013, Michael Thomas wrote:

> So here is the question I have: when we run out, is there *anything* that
> will reasonably allow an ISP to *not* deploy carrier grade NAT?

Do you count NAT64 or MAP as carrier grade NAT?

> One thing that occurs to me though is that it's sort of in an ISP's interest
> to deploy v6 on the client side because each new v6 site that lights up on
> the internet side is less traffic forced through the CGN gear which is 
> ultimately
> a cost down. So maybe an alternative to a death penalty is a molasses 
> penalty:
> make the CGN experience operable but bad/congested/slow :)

Hm, sounds like NAT64 or MAP to me (although, honestly, we may end up 
making MAP "too good".)

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
Schedule a meeting:  https://doodle.com/bross            Skype:  brandonross


From mike at mtcc.com  Thu Apr 25 17:29:45 2013
From: mike at mtcc.com (Michael Thomas)
Date: Thu, 25 Apr 2013 10:29:45 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <alpine.OSX.2.02.1304251306460.72441@brugal.local>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <alpine.OSX.2.02.1304251306460.72441@brugal.local>
Message-ID: <51796809.4010103@mtcc.com>

On 04/25/2013 10:10 AM, Brandon Ross wrote:
> On Thu, 25 Apr 2013, Michael Thomas wrote:
>
>> So here is the question I have: when we run out, is there *anything* that
>> will reasonably allow an ISP to *not* deploy carrier grade NAT?
>
> Do you count NAT64 or MAP as carrier grade NAT?

I suppose that the way to frame this as: does it require the ISP to
carry flow statefulness in their network in places where they didn't
have to before. That to my mind is the big hit.

>
>> One thing that occurs to me though is that it's sort of in an ISP's interest
>> to deploy v6 on the client side because each new v6 site that lights up on
>> the internet side is less traffic forced through the CGN gear which is ultimately
>> a cost down. So maybe an alternative to a death penalty is a molasses penalty:
>> make the CGN experience operable but bad/congested/slow :)
>
> Hm, sounds like NAT64 or MAP to me (although, honestly, we may end up making MAP "too good".)
>

I was going to say that NAT64 could be helpful, but thought better of it
because it may have its own set of issues. For example, are all of the resources
*within* the ISP v6 available? They may be a part of the problem as well as a
part of the solution too. I would think that just the prospect of having a less
expensive/complex infrastructure would be appealing as v6 adoption ramps up,
and gives ISP's an incentive to give the laggards an incentive.

Mike


From bross at pobox.com  Thu Apr 25 17:36:38 2013
From: bross at pobox.com (Brandon Ross)
Date: Thu, 25 Apr 2013 13:36:38 -0400 (EDT)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51796809.4010103@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <alpine.OSX.2.02.1304251306460.72441@brugal.local> <51796809.4010103@mtcc.com>
Message-ID: <alpine.OSX.2.02.1304251334340.72441@brugal.local>

On Thu, 25 Apr 2013, Michael Thomas wrote:

> On 04/25/2013 10:10 AM, Brandon Ross wrote:
>> On Thu, 25 Apr 2013, Michael Thomas wrote:
>> 
>>> So here is the question I have: when we run out, is there *anything* that
>>> will reasonably allow an ISP to *not* deploy carrier grade NAT?
>> 
>> Do you count NAT64 or MAP as carrier grade NAT?
>
> I suppose that the way to frame this as: does it require the ISP to
> carry flow statefulness in their network in places where they didn't
> have to before. That to my mind is the big hit.

NAT64 sure does.  Take a look at MAP and be your own judge of weather it 
counts or not.

> I was going to say that NAT64 could be helpful, but thought better of it 
> because it may have its own set of issues. For example, are all of the 
> resources *within* the ISP v6 available?

Um, yes, why wouldn't they be?

> They may be a part of the problem as well as a part of the solution too. 
> I would think that just the prospect of having a less expensive/complex 
> infrastructure would be appealing as v6 adoption ramps up, and gives 
> ISP's an incentive to give the laggards an incentive.

It's no longer clear to me what your problem statement is.  If the problem 
is that you want something that does NATish things so that v4 still works, 
but v6 works better, I think NAT64 is worthy of your scrutiny.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
Schedule a meeting:  https://doodle.com/bross            Skype:  brandonross


From owen at delong.com  Thu Apr 25 18:09:41 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 25 Apr 2013 14:09:41 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51794ABF.5040209@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
Message-ID: <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com>


On Apr 25, 2013, at 11:24 AM, Michael Thomas <mike at mtcc.com> wrote:

> So here is the question I have: when we run out, is there *anything* that
> will reasonably allow an ISP to *not* deploy carrier grade NAT? Assuming
> that it's death for the ISP to just say no to the long tail of legacy v4-only
> sites?

This assumes facts not in evidence. However, given that assumption, it's
not so much a question of whether to CGN, but how. It looks like it may
be far better, for example, to do something like 464xlat with an all IPv6
network than to run dual-stack with NAT444 or DS-LITE.

There's no shortage of possible ways to run IPv4 life support, but they're
all life support. You have all the same risks as human life support?

Intracranial pressure, diverse intravascular coagulopathy (DIC),
stroke (CVA), embolisms, etc. In the network, we refer to these
as router instability, state table overflow, packet loss, bottlenecks,
etc.

Other options include NAT64/DNS64, A+P, etc.

Bottom line? The more IPv6 gets deployed on the content side, the less
this is going to hurt. Eyeballs will be forced to deploy soon enough. It's
content and consumer electronics that are going to be the most painful
laggards.

> One thing that occurs to me though is that it's sort of in an ISP's interest
> to deploy v6 on the client side because each new v6 site that lights up on
> the internet side is less traffic forced through the CGN gear which is ultimately
> a cost down. So maybe an alternative to a death penalty is a molasses penalty:
> make the CGN experience operable but bad/congested/slow :)

That latter requires no additional effort beyond merely deploying CGN. ;-)

Owen



From mike at mtcc.com  Thu Apr 25 20:09:16 2013
From: mike at mtcc.com (Michael Thomas)
Date: Thu, 25 Apr 2013 13:09:16 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com>
Message-ID: <51798D6C.70907@mtcc.com>

On 04/25/2013 11:09 AM, Owen DeLong wrote:
> On Apr 25, 2013, at 11:24 AM, Michael Thomas <mike at mtcc.com> wrote:
>
>> So here is the question I have: when we run out, is there *anything* that
>> will reasonably allow an ISP to *not* deploy carrier grade NAT? Assuming
>> that it's death for the ISP to just say no to the long tail of legacy v4-only
>> sites?
> This assumes facts not in evidence. However, given that assumption, it's
> not so much a question of whether to CGN, but how. It looks like it may
> be far better, for example, to do something like 464xlat with an all IPv6
> network than to run dual-stack with NAT444 or DS-LITE.
>
> There's no shortage of possible ways to run IPv4 life support, but they're
> all life support. You have all the same risks as human life support?
>
> Intracranial pressure, diverse intravascular coagulopathy (DIC),
> stroke (CVA), embolisms, etc. In the network, we refer to these
> as router instability, state table overflow, packet loss, bottlenecks,
> etc.
>
> Other options include NAT64/DNS64, A+P, etc.
>
> Bottom line? The more IPv6 gets deployed on the content side, the less
> this is going to hurt. Eyeballs will be forced to deploy soon enough. It's
> content and consumer electronics that are going to be the most painful
> laggards.

At some level, I wonder how much the feedback loop of "providers
won't deploy ipv6 because everybody says they won't deploy ipv6"
has caused this self-fulfilling prophecy :/

On the other hand, there is The Cloud. I assume that aws and all of the
other major vm farms have native v6 networks by now (?). I hooked up
v6 support on linode in, oh, less than an hour for my site. Maybe part
of this just evangelizing with the Cloud folks to get the word out that
v6 is both supported *and* beneficial for your site? And it might give them
a leg up with "legacy" web infrastructure data centers to lure them? "Oh,
your corpro IT guys won't light up v6? let me show you how easy it is on
$MEGACLOUD".

Mike


From cgrundemann at gmail.com  Thu Apr 25 21:03:09 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 25 Apr 2013 17:03:09 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
Message-ID: <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>

On Thu, Apr 25, 2013 at 12:11 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> There is a lot of speculation what IPv4 addresses are worth, I've been
> hearing everything from a few USD to 20 EUR per address.

There was some good information shared at the recent INET Denver on
value vs. price and how to determine value of an IPv4 address, you can
watch the panel discussion on YouTube: http://youtu.be/v43CGqq70rM.

The panel included John Curran (ARIN), Charles Lee (Addrex), Lee
Howard (TWC), and Louis Sterchi.

~Chris

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

--
@ChrisGrundemann
http://chrisgrundemann.com


From randy at psg.com  Thu Apr 25 21:24:35 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Apr 2013 06:24:35 +0900
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
 <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
Message-ID: <m2d2til2wc.wl%randy@psg.com>

> There was some good information shared at the recent INET Denver on
> value vs. price and how to determine value of an IPv4 address, you can
> watch the panel discussion on YouTube: http://youtu.be/v43CGqq70rM.

amusing how much curran is interested in asserting his/arin's power and
rights and how little he speaks to the interest of the internet and the
isps.

randy


From frnkblk at iname.com  Thu Apr 25 23:22:08 2013
From: frnkblk at iname.com (Frank Bulk (iname.com))
Date: Thu, 25 Apr 2013 18:22:08 -0500
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <EEDF1F2A-4A0F-42B3-9460-BD0805503288@virtualized.org>
References: <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <CD9D7E89.1BA4F%Lee@asgard.org>
 <CA+qj4S_KoSeEyM3Tnr-pQp0R09f-eftH27MJuv6SfygMhuhvzw@mail.gmail.com>
 <EEDF1F2A-4A0F-42B3-9460-BD0805503288@virtualized.org>
Message-ID: <001201ce420b$bae16450$30a42cf0$@iname.com>

CGN "works" for eyeball networks, but not for hosting.  From the remarks at
this week's ARIN meeting, that's where ARIN has seen an uptick in requests.
So those who sell virtual machines, IPv4 addresses are critical if they want
make their offering viable in the near-term.

Frank

-----Original Message-----
From: David Conrad [mailto:drc at virtualized.org] 
Sent: Wednesday, April 24, 2013 12:27 PM
To: Andrew Latham
Cc: nanog at nanog.org
Subject: Re: "It's the end of the world as we know it" -- REM

On Apr 24, 2013, at 9:59 AM, Andrew Latham <lathama at gmail.com> wrote:
>> A demand curve would show that as prices increase, there is demand for
fewer IPv4 addresses.

And the other side of the coin: where there is demand and excess supply
(e.g., allocated but unused addresses), the price increase would create an
incentive to sell off the excess (i.e., what we're seeing in the IPv4
trading markets).

> Totally agree, your point is the larger issue at hand, just pointing
> out and ugly issue that I witnessed recently.  Corporate networks and
> ASNs totally off and not in use.  But don't worry, they will use them
> if someone tries to take them away.

Or they'll sell/lease them. The prospective address consumer then can figure
out whether paying the buy/rent price for new IPv4 addresses makes sense
compared to moving to IPv6+translation or buying (more) CGN.

Regards,
-drc






From jra at baylink.com  Fri Apr 26 01:24:52 2013
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 25 Apr 2013 21:24:52 -0400 (EDT)
Subject: IPv6 and HTTPS
Message-ID: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>

Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger
networks:

Does anyone know how much IPv4 space is allocated *specifically* to cater 
to the fact that HTTPS requires a dedicated IP per DNS name?

Is that a statistically significant percentage of all the IPs in use?

Wasn't there something going on to make HTTPS IP muxable?  How's that coming?

How fast could it be deployed?

Cheers,
-- jra

[1] Ok, five questions.
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From cmadams at hiwaay.net  Fri Apr 26 01:36:13 2013
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 25 Apr 2013 20:36:13 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
Message-ID: <20130426013613.GC20036@hiwaay.net>

Once upon a time, Jay Ashworth <jra at baylink.com> said:
> Does anyone know how much IPv4 space is allocated *specifically* to cater 
> to the fact that HTTPS requires a dedicated IP per DNS name?
> 
> Is that a statistically significant percentage of all the IPs in use?

I have no numbers, but my gut feeling is that there are a lot more
eyeballs than web servers with lots of IPs.

> Wasn't there something going on to make HTTPS IP muxable?  How's that coming?

SNI; RFC 3546

> How fast could it be deployed?

The RFC is just shy of 10 years old, so that's like a baby compared to
IPv6.

It is mostly deployed, but there's still a fair number of old clients
that don't support it.  WinXP+IE is probably the biggest fail, followed
by Android < 3.0 and BlackBerry.

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


From hhoffman at ip-solutions.net  Fri Apr 26 01:38:05 2013
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Thu, 25 Apr 2013 21:38:05 -0400
Subject: IPv6 and HTTPS
Message-ID: <3pqcd570bre47jaduat35dg4.1366940285364@email.android.com>


From dhubbard at dino.hostasaurus.com  Fri Apr 26 01:37:59 2013
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Thu, 25 Apr 2013 21:37:59 -0400
Subject: IPv6 and HTTPS
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0F3F1@dino.ad.hostasaurus.com>

We're a host catering to just ecommerce sites and consume an
IPv4 address for each site specifically because of SSL certs.
SNI (Server Name Indication) is what you're thinking of to let
SSL send the hostname as the handshake process begins and
does indeed eliminate the need for an exclusive IP (although
there will always be a high rate of people who avoid shared
IP's for SEO reasons since the search engines are doing nothing
to eliminate that concern).  The problem with SNI is many
older, but still commonly used, browsers don't support it,
such as IE on Windows XP, which certainly won't disappear long
before address run-out is a distant memory.

My guess is amongst hosting providers, SSL is the cause for
much of the usage; I have no feel for how may IP addresses
are allocated towards hosts versus anything else though.

David

> -----Original Message-----
> From: Jay Ashworth [mailto:jra at baylink.com] 
> Sent: Thursday, April 25, 2013 9:25 PM
> To: NANOG
> Subject: IPv6 and HTTPS
> 
> Ok, here's a stupid question[1], which I'd know the answer to 
> if I ran bigger
> networks:
> 
> Does anyone know how much IPv4 space is allocated 
> *specifically* to cater 
> to the fact that HTTPS requires a dedicated IP per DNS name?
> 
> Is that a statistically significant percentage of all the IPs in use?
> 
> Wasn't there something going on to make HTTPS IP muxable?  
> How's that coming?
> 
> How fast could it be deployed?
> 
> Cheers,
> -- jra
> 
> [1] Ok, five questions.
> -- 
> Jay R. Ashworth                  Baylink                      
>  jra at baylink.com
> Designer                     The Things I Think               
>         RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         
> 2000 Land Rover DII
> St Petersburg FL USA               #natog                     
>  +1 727 647 1274
> 
> 
> 


From jra at baylink.com  Fri Apr 26 01:47:29 2013
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 25 Apr 2013 21:47:29 -0400 (EDT)
Subject: IPv6 and HTTPS
In-Reply-To: <20130426013613.GC20036@hiwaay.net>
Message-ID: <30600519.4050.1366940849217.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Chris Adams" <cmadams at hiwaay.net>

> Once upon a time, Jay Ashworth <jra at baylink.com> said:
> > Does anyone know how much IPv4 space is allocated *specifically* to cater
> > to the fact that HTTPS requires a dedicated IP per DNS name?
> >
> > Is that a statistically significant percentage of all the IPs in use?
> 
> I have no numbers, but my gut feeling is that there are a lot more
> eyeballs than web servers with lots of IPs.

Fair point.  Though those are choked behind carriers who may well CGN
them whether the eyeballs like it or not.

> > Wasn't there something going on to make HTTPS IP muxable? How's that
> > coming?
> 
> SNI; RFC 3546
> 
> > How fast could it be deployed?
> 
> The RFC is just shy of 10 years old, so that's like a baby compared to
> IPv6.
> 
> It is mostly deployed, but there's still a fair number of old clients
> that don't support it. WinXP+IE is probably the biggest fail, followed
> by Android < 3.0 and BlackBerry.

When you say "it is mostly deployed", what exactly do you mean?  Is it 
layer 7 or 4?  Does it live in libraries that can be upgraded behind
users' backs?  Or is it actually in the browser proper?  Or are you just 
talking about the server-side of the equation?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From dhubbard at dino.hostasaurus.com  Fri Apr 26 02:11:35 2013
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Thu, 25 Apr 2013 22:11:35 -0400
Subject: IPv6 and HTTPS
References: <30600519.4050.1366940849217.JavaMail.root@benjamin.baylink.com>
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0F3F2@dino.ad.hostasaurus.com>

From: Jay Ashworth [mailto:jra at baylink.com] 
> Sent: Thursday, April 25, 2013 9:47 PM
> To: NANOG
> Subject: Re: IPv6 and HTTPS
> 
> 
> When you say "it is mostly deployed", what exactly do you 
> mean?  Is it 
> layer 7 or 4?  Does it live in libraries that can be upgraded behind
> users' backs?  Or is it actually in the browser proper?  Or 
> are you just 
> talking about the server-side of the equation?
> 

I'm guessing the browser may depend on some OS goodies based
on the fact that supposedly MS has said XP will never support
SNI.

The web server has to support it too, which means compiling
apache with SNI support and there are of course plenty of
hosts running old apache.

David


From owen at delong.com  Fri Apr 26 02:27:28 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 25 Apr 2013 22:27:28 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <51798D6C.70907@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
Message-ID: <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com>

> At some level, I wonder how much the feedback loop of "providers
> won't deploy ipv6 because everybody says they won't deploy ipv6"
> has caused this self-fulfilling prophecy :/

It's a definite issue. The bigger issue is the financial incentives are all in the
wrong direction.

Eyeball networks have an incentive not to deploy IPv6 until content providers
have done so or until they have no other choice.

Content providers have an incentive not to deploy IPv6 until there are many
IPv6 eyeballs to serve. To a certain extent, they have an incentive to avoid
deploying IPv6 until there are IPv6-only eyeballs.

> On the other hand, there is The Cloud. I assume that aws and all of the
> other major vm farms have native v6 networks by now (?). I hooked up

You again assume facts not in evidence. Many cloud providers have done
IPv6. Rackspace stands out as exemplary in this regard. Linode has done
some good work in this space.

AWS stands out as a complete laggard in this area. 

> v6 support on linode in, oh, less than an hour for my site. Maybe part
> of this just evangelizing with the Cloud folks to get the word out that
> v6 is both supported *and* beneficial for your site? And it might give them
> a leg up with "legacy" web infrastructure data centers to lure them? "Oh,
> your corpro IT guys won't light up v6? let me show you how easy it is on
> $MEGACLOUD".

+1 -- I encourage people to seek providers that support IPv6.

Owen



From jra at baylink.com  Fri Apr 26 02:32:16 2013
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 25 Apr 2013 22:32:16 -0400 (EDT)
Subject: IPv6 and HTTPS
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A17304E0F3F2@dino.ad.hostasaurus.com>
Message-ID: <26869859.4060.1366943536751.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "David Hubbard" <dhubbard at dino.hostasaurus.com>

> The web server has to support it too, which means compiling
> apache with SNI support and there are of course plenty of
> hosts running old apache.

Well, sure, but for the hoster, it's a direct benefit, not an externality;
they have motive to fix it.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274


From owen at delong.com  Fri Apr 26 02:32:10 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 25 Apr 2013 22:32:10 -0400
Subject: IPv6 and HTTPS
In-Reply-To: <30600519.4050.1366940849217.JavaMail.root@benjamin.baylink.com>
References: <30600519.4050.1366940849217.JavaMail.root@benjamin.baylink.com>
Message-ID: <126D3E18-C98B-4D30-B585-DAF1B6849C65@delong.com>


On Apr 25, 2013, at 9:47 PM, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
>> From: "Chris Adams" <cmadams at hiwaay.net>
> 
>> Once upon a time, Jay Ashworth <jra at baylink.com> said:
>>> Does anyone know how much IPv4 space is allocated *specifically* to cater
>>> to the fact that HTTPS requires a dedicated IP per DNS name?
>>> 
>>> Is that a statistically significant percentage of all the IPs in use?
>> 
>> I have no numbers, but my gut feeling is that there are a lot more
>> eyeballs than web servers with lots of IPs.
> 
> Fair point.  Though those are choked behind carriers who may well CGN
> them whether the eyeballs like it or not.
> 

That won't reduce the number of IPs they are consuming, it will just increase
the number of customers using them.

>>> Wasn't there something going on to make HTTPS IP muxable? How's that
>>> coming?
>> 
>> SNI; RFC 3546
>> 
>>> How fast could it be deployed?
>> 
>> The RFC is just shy of 10 years old, so that's like a baby compared to
>> IPv6.
>> 
>> It is mostly deployed, but there's still a fair number of old clients
>> that don't support it. WinXP+IE is probably the biggest fail, followed
>> by Android < 3.0 and BlackBerry.
> 
> When you say "it is mostly deployed", what exactly do you mean?  Is it 
> layer 7 or 4?  Does it live in libraries that can be upgraded behind
> users' backs?  Or is it actually in the browser proper?  Or are you just 
> talking about the server-side of the equation?

Browsers are the long-tail here. There are also some privacy concerns.

The good news is that most things which fully support IPv6 also support SNI.
The bad new is that most things that don't support IPv6 don't support SNI.

Guess what that means. ;-)

Owen



From mike at mtcc.com  Fri Apr 26 02:49:03 2013
From: mike at mtcc.com (Michael Thomas)
Date: Thu, 25 Apr 2013 19:49:03 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com>
Message-ID: <5179EB1F.8070302@mtcc.com>

On 04/25/2013 07:27 PM, Owen DeLong wrote:
>> At some level, I wonder how much the feedback loop of "providers
>> won't deploy ipv6 because everybody says they won't deploy ipv6"
>> has caused this self-fulfilling prophecy :/
> It's a definite issue. The bigger issue is the financial incentives are all in the
> wrong direction.
>
> Eyeball networks have an incentive not to deploy IPv6 until content providers
> have done so or until they have no other choice.

Yet, eyeball networks are the ones being asked to pony up all of the
cost to put in place the hacks to keep v4 running so they don't get
support center calls. That's a pretty asymmetric, and a potential opportunity.

>
>> On the other hand, there is The Cloud. I assume that aws and all of the
>> other major vm farms have native v6 networks by now (?). I hooked up
> You again assume facts not in evidence. Many cloud providers have done
> IPv6. Rackspace stands out as exemplary in this regard. Linode has done
> some good work in this space.
>
> AWS stands out as a complete laggard in this area.

Heh... that's why I put all kinds of question marks and hedges :)
That's disappointing about aws. On the other hand, if aws lights
up v6, a huge amount of content will be v6 capable in one swell-foop.
Which is a different problem of death by a thousand cuts of corpro
data centers, and racked up servers in no-name cages.

>
>> v6 support on linode in, oh, less than an hour for my site. Maybe part
>> of this just evangelizing with the Cloud folks to get the word out that
>> v6 is both supported *and* beneficial for your site? And it might give them
>> a leg up with "legacy" web infrastructure data centers to lure them? "Oh,
>> your corpro IT guys won't light up v6? let me show you how easy it is on
>> $MEGACLOUD".
> +1 -- I encourage people to seek providers that support IPv6.
>

Name. and. shame. At some level, some amount of bs is probably useful
to scare the suits: "OMG, VZW'S PHONES SUPPORT V6, DO WE DO THAT????".
Roll your eyes, but, well, remember they're suits.

Mike


From jeff.adams at bancvue.com  Fri Apr 26 02:46:15 2013
From: jeff.adams at bancvue.com (jeff adams)
Date: Thu, 25 Apr 2013 21:46:15 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <26869859.4060.1366943536751.JavaMail.root@benjamin.baylink.com>
References: <26869859.4060.1366943536751.JavaMail.root@benjamin.baylink.com>
Message-ID: <5179EA77.9010705@bancvue.com>

On 04/25/2013 09:32 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "David Hubbard"<dhubbard at dino.hostasaurus.com>
>
>> The web server has to support it too, which means compiling
>> apache with SNI support and there are of course plenty of
>> hosts running old apache.
>
> Well, sure, but for the hoster, it's a direct benefit, not an externality;
> they have motive to fix it.

Sort of. Consider though that any clients of an SNI configured website
which don't support SNI will likely experience cert name mismatch
warnings, which is usually construed as a Bad Thing.

So in practice, there's not a lot of benefit/motive to support SNI
server side...

> Cheers,
> -- jra

This message and any attached files contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or without error as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.


From joelja at bogus.com  Fri Apr 26 04:19:54 2013
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 25 Apr 2013 21:19:54 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
Message-ID: <517A006A.5020003@bogus.com>

On 4/25/13 6:24 PM, Jay Ashworth wrote:
> Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger
> networks:
>
> Does anyone know how much IPv4 space is allocated *specifically* to cater
> to the fact that HTTPS requires a dedicated IP per DNS name?
It doesn't, or doesn't if if your clients are not stuck in the past.

TLS SNI has existed for a rather long time.
> Is that a statistically significant percentage of all the IPs in use?
>
> Wasn't there something going on to make HTTPS IP muxable?  How's that coming?
there are stuborn legacy hosts.
> How fast could it be deployed?
you can use it now.
> Cheers,
> -- jra
>
> [1] Ok, five questions.



From patrick at ianai.net  Fri Apr 26 04:27:22 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Fri, 26 Apr 2013 00:27:22 -0400
Subject: IPv6 and HTTPS
In-Reply-To: <517A006A.5020003@bogus.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A006A.5020003@bogus.com>
Message-ID: <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>

On Apr 26, 2013, at 00:19 , joel jaeggli <joelja at bogus.com> wrote:
> On 4/25/13 6:24 PM, Jay Ashworth wrote:

>> Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger
>> networks:
>> 
>> Does anyone know how much IPv4 space is allocated *specifically* to cater
>> to the fact that HTTPS requires a dedicated IP per DNS name?
> It doesn't, or doesn't if if your clients are not stuck in the past.
> 
> TLS SNI has existed for a rather long time.
>> Is that a statistically significant percentage of all the IPs in use?
>> 
>> Wasn't there something going on to make HTTPS IP muxable?  How's that coming?
> there are stuborn legacy hosts.
>> How fast could it be deployed?
> you can use it now.

Sure, you "can".

But no one will. No one (especially someone doing SSL content) wants 99% connectivity. And there's a lot more than 1% XP out there. (Hrm, that explanation works to explain why to a couple decimal places 0% of the Internet is on v6 only today.)

-- 
TTFN,
patrick




From himileanmedia at gmail.com  Fri Apr 26 04:56:55 2013
From: himileanmedia at gmail.com (Himilean Media)
Date: Thu, 25 Apr 2013 21:56:55 -0700
Subject: Alleged BTOP/NTIA Fraud - $25M lawsuit filed over BTOP/NTIA funds in
 Florida
Message-ID: <CAEa6hyazdy-4wp36e4w0Q1016+mS9JuDEK8GcG-ZBr_SSFjPcQ@mail.gmail.com>

Wondering if this lawsuit has or will  potentially affect any other NANOG
operators?

My understanding is that anyone that was counting (planning) on this
infrastructure in rural Florida for middle-mile or long-haul transport
should now seek alternative options?

-HM/DAK


On Thu, Apr 25, 2013 at 9:52 PM, FierceTelecom wrote:

>
> Rapid Systems Seeks $25 Million From FRBA With Lawsuit Filing
>
> Tampa, Florida based Rapid Systems, Inc. announced April 19 it filed a $25
> Million suit against the Florida Rural Broadband Alliance (FRBA) along with
> several co-defendants.
>
> Rapid Systems is a wireless broadband Internet service provider that
> entered an agreement with FRBA and others to provide broadband network
> support for a project developed with Broadband Opportunities Grants awarded
> in Florida as part of a government economic stimulus program. The grant
> totaled $23 Million. Rapid Systems allege in the complaint that after
> providing the agreed services, equipment and in-kind contributions totaling
> $2 Million, the FRBA and several co-defendants failed to pay Rapid Systems
> for any of the services or expenses rendered under the agreement. Rapid
> Systems is seeking to recover not only its own investment but also fees,
> costs and lost revenue as a result of FRBA's actions.
>
> The grant money FRBA received is intended to develop the infrastructure
> needed for wireless Internet service in rural Florida counties. The program
> is intended to bridge the gap between large public service providers and
> small and often poor rural communities without the economic impact to
> attract private investment for wireless broadband connectivity networks.
>
> A similar program was already funded as the North Florida Broadband
> Authority and has seen similar litigation and various towns and counties
> pulling out of the program. After three years and over $28 Million federal
> dollars invested in the NFBA, there are a confirmed 60 customers using the
> services. Both the NFBA and RFBA are currently under federal investigation.
> Questions of mismanagement, fraud, misinformation and misappropriating
> funds have dogged the grant recipients almost since their inception early
> in the Obama administration?s economic recovery efforts.
>
> Rapid Systems has also included some public official in its complaint
> alleging a coordinated effort with the FRBA to defame the plaintiff in an
> effort to justify not paying the outstanding balances. The lawsuit filed in
> Hardee County Circuit Court details a complicated ?fraud scheme?
> perpetrated by FRBA?s management to keep from paying out various invoices
> and accounts. Rapid Systems has told the court all contracted work was
> performed to agreed standards and payment is now due.
>
> There was no immediate word from the court or federal authorities if the
> Rapid Systems suit will, in any way, affect the ongoing investigation into
> the FRBA or NFBA. Also, federal authorities have offered no confirmed time
> frame for completing their investigation. Whether the federal investigation
> could impact Rapid Systems and their alleged claims remains unclear.
>
> Source Lawsuit:
> http://cdn.l2net.com/dl/BTOP_NTIA_FRBA_Lawsuit_KraigBeahnCopy_FSReduced.pdf
>
> FierceTelecom:
> http://www.fiercetelecom.com/story/florida-provider-rapid-systems-inc-sues-frba-25-million-alleging-fraud-misc/2013-04-25
>
>
>

From mpalmer at hezmatt.org  Fri Apr 26 05:16:50 2013
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Fri, 26 Apr 2013 15:16:50 +1000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <5179EB1F.8070302@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org>
 <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com>
 <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com>
 <5179EB1F.8070302@mtcc.com>
Message-ID: <20130426051650.GC26847@hezmatt.org>

On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote:
> On 04/25/2013 07:27 PM, Owen DeLong wrote:
> >AWS stands out as a complete laggard in this area.
> 
> Heh... that's why I put all kinds of question marks and hedges :)
> That's disappointing about aws. On the other hand, if aws lights
> up v6, a huge amount of content will be v6 capable in one swell-foop.

Even if the only thing that supported IPv6 was ELB, and everything else was
still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly, and
ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN, AWS
takes care of resolution and proxies a TCP connection to your instance).

- Matt

-- 
"Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering their
time inventing and implementing new, exciting ways for software to suck."
		-- Toni Lassila, in the Monastery



From joelja at bogus.com  Fri Apr 26 05:22:02 2013
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 25 Apr 2013 22:22:02 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A006A.5020003@bogus.com> <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>
Message-ID: <517A0EFA.5040108@bogus.com>

On 4/25/13 9:27 PM, Patrick W. Gilmore wrote:
> On Apr 26, 2013, at 00:19 , joel jaeggli <joelja at bogus.com> wrote:
>> On 4/25/13 6:24 PM, Jay Ashworth wrote:
>>> Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger
>>> networks:
>>>
>>> Does anyone know how much IPv4 space is allocated *specifically* to cater
>>> to the fact that HTTPS requires a dedicated IP per DNS name?
>> It doesn't, or doesn't if if your clients are not stuck in the past.
>>
>> TLS SNI has existed for a rather long time.
>>> Is that a statistically significant percentage of all the IPs in use?
>>>
>>> Wasn't there something going on to make HTTPS IP muxable?  How's that coming?
>> there are stuborn legacy hosts.
>>> How fast could it be deployed?
>> you can use it now.
> Sure, you "can".
>
> But no one will. No one (especially someone doing SSL content) wants 99% connectivity. And there's a lot more than 1% XP out there. (Hrm, that explanation works to explain why to a couple decimal places 0% of the Internet is on v6 only today.)
Well there are certainly people who no longer support ie6  e.g. google 
facebook and so on, IE doesn't support it unless you run vista or later. 
and it will work on xp if you use firefox.

we use it with api's and non-browser-based html5 applications with 
essentially no issues.

The market-share of some of the more problematic devices is in fact 
getting to the point where it is possible.
>



From joelja at bogus.com  Fri Apr 26 05:27:19 2013
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 25 Apr 2013 22:27:19 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <20130426051650.GC26847@hezmatt.org>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
 <20130426051650.GC26847@hezmatt.org>
Message-ID: <517A1037.8050801@bogus.com>

On 4/25/13 10:16 PM, Matt Palmer wrote:
> On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote:
>> On 04/25/2013 07:27 PM, Owen DeLong wrote:
>>> AWS stands out as a complete laggard in this area.
>> Heh... that's why I put all kinds of question marks and hedges :)
>> That's disappointing about aws. On the other hand, if aws lights
>> up v6, a huge amount of content will be v6 capable in one swell-foop.
> Even if the only thing that supported IPv6 was ELB, and everything else was
> still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly, and
> ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN, AWS
> takes care of resolution and proxies a TCP connection to your instance).
elb ipv6 support has been in place for some time (may 2011 for us east 
and ireland)

"IPv6 support is currently available in the following Amazon EC2 
regions: US East (Northern Virginia), US West (Northern California), US 
West (Oregon), EU (Ireland), Asia Pacific (Tokyo), and Asia Pacific 
(Singapore).?
>
> - Matt
>



From ag4ve.us at gmail.com  Fri Apr 26 05:46:52 2013
From: ag4ve.us at gmail.com (shawn wilson)
Date: Fri, 26 Apr 2013 01:46:52 -0400
Subject: IPv6 and HTTPS
In-Reply-To: <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A006A.5020003@bogus.com>
 <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>
Message-ID: <CAH_OBideLRHOccwEZSy0nSsMDAYdgmphH0unVu1i-4eTNMn+fQ@mail.gmail.com>

On Apr 26, 2013 12:29 AM, "Patrick W. Gilmore" <patrick at ianai.net> wrote:
>
> On Apr 26, 2013, at 00:19 , joel jaeggli <joelja at bogus.com> wrote:
> > On 4/25/13 6:24 PM, Jay Ashworth wrote:
>
> >> Ok, here's a stupid question[1], which I'd know the answer to if I ran
bigger
> >> networks:
> >>
> >> Does anyone know how much IPv4 space is allocated *specifically* to
cater
> >> to the fact that HTTPS requires a dedicated IP per DNS name?
> > It doesn't, or doesn't if if your clients are not stuck in the past.
> >
> > TLS SNI has existed for a rather long time.
> >> Is that a statistically significant percentage of all the IPs in use?
> >>
> >> Wasn't there something going on to make HTTPS IP muxable?  How's that
coming?
> > there are stuborn legacy hosts.
> >> How fast could it be deployed?
> > you can use it now.
>
> Sure, you "can".
>
> But no one will. No one (especially someone doing SSL content) wants 99%
connectivity. And there's a lot more than 1% XP out there. (Hrm, that
explanation works to explain why to a couple decimal places 0% of the
Internet is on v6 only today.)
>

You like fuzzy math. OK.

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

From randy at psg.com  Fri Apr 26 06:12:46 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Apr 2013 15:12:46 +0900
Subject: skype shoots self in foot
Message-ID: <m2fvydkeg1.wl%randy@psg.com>

skype seems to have made the latest 6.x incompatible with 2.8 (which
folk who care about screen real estate run) in that video no longer
works between them.

until widespread availability of webrtc, a bunch of us are using
jitsi for video, https://jitsi.org/ 
  o uses open standard protocols
  o free, open source, apple pie, ...
  o supports opus codec which has really good performance across a
    wide range of bandwidth http://www.opus-codec.org/comparison/
  o multi-participant video on xmpp-based videobridge, also open
    source
  o does xmpp, sip, aim, icq, yahoo, ...

i have an ejabberd+videobridge up if folk want test/use accounts.
and it's easy to put up your own, of course.

and while you are looking at escaping other big company servers,
check out http://labs.bittorrent.com/experiments/sync.html, real
peer to peer dropbox.

randy


From bernhard at ICSI.Berkeley.EDU  Fri Apr 26 05:30:57 2013
From: bernhard at ICSI.Berkeley.EDU (Bernhard Amann)
Date: Thu, 25 Apr 2013 22:30:57 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A006A.5020003@bogus.com> <7C8838A3-70FA-478A-97E3-3F1F09FC4E15@ianai.net>
Message-ID: <452435E5-35C5-4C14-A26E-2C75DDE88779@icsi.berkeley.edu>


On Apr 25, 2013, at 9:27 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:

> On Apr 26, 2013, at 00:19 , joel jaeggli <joelja at bogus.com> wrote:
>> On 4/25/13 6:24 PM, Jay Ashworth wrote:
> 
>>> Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger
>>> networks:
>>> 
>>> Does anyone know how much IPv4 space is allocated *specifically* to cater
>>> to the fact that HTTPS requires a dedicated IP per DNS name?
>> It doesn't, or doesn't if if your clients are not stuck in the past.
>> 
>> TLS SNI has existed for a rather long time.
>>> Is that a statistically significant percentage of all the IPs in use?
>>> 
>>> Wasn't there something going on to make HTTPS IP muxable?  How's that coming?
>> there are stuborn legacy hosts.
>>> How fast could it be deployed?
>> you can use it now.
> 
> Sure, you "can".
> 
> But no one will. No one (especially someone doing SSL content) wants 99% connectivity. And there's a lot more than 1% XP out there. (Hrm, that explanation works to explain why to a couple decimal places 0% of the Internet is on v6 only today.)

Just to give a numbers, in case anyone is interested - we have been passively
monitoring SSL traffic of ~300k users for more than a year (project description at 
http://notary.icsi.berkeley.edu).

All in all, we see about 71% of the connections on port 443 using SNI.

And the only site I am aware of that uses SNI quite extensively is google - their servers
give different certificates to clients that do not support SNI and clients that support it.

Bernhard



From tvhawaii at shaka.com  Fri Apr 26 06:26:02 2013
From: tvhawaii at shaka.com (Michael Painter)
Date: Thu, 25 Apr 2013 20:26:02 -1000
Subject: It's Friday
Message-ID: <B106217254F743538CB53EAC48F05310@owner59e1f1502>

http://www.technologyreview.com/news/514066/what-happened-when-one-man-pinged-the-whole-internet/?utm_campaign=newsletters&utm_source=newsletter-daily-all&utm_medium=email&utm_content=20130426 



From joelja at bogus.com  Fri Apr 26 06:27:08 2013
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 25 Apr 2013 23:27:08 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
Message-ID: <517A1E3C.3040102@bogus.com>

On 4/24/13 1:55 AM, Mikael Abrahamsson wrote:
> On Wed, 24 Apr 2013, Geoff Huston wrote:
>
>> However, personally I find it a little hard to place a high 
>> probability on Tony's projected exhaustion date of August this year. 
>> I also have to qualify that by noting that while I think that a 
>> runout of the remaining 40 M addresses within 4 months is improbable, 
>> its by no means impossible. If we saw a re-run of the address 
>> consumption rates that ARIN experienced in 2010, then it's not 
>> outside the bounds of plausibility that ARIN will be handing out its 
>> last address later this year.
>
> I also find it a bit strange that the runout in APNIC and RIPE was 
> very different. APNIC address allocation rate accelerated at the end, 
> whereas RIPE exhaustion date kept creeping forward in time instead of 
> closer in time, giving me the impression that there wasn't any panic 
> there.
>
apnic allocation reserved  the final /8 for /22 maximal allocations. 
Couple that with some qualifying very large assignments towards the end 
of stage two e.g between feb 1 and april 14 2011 7 provider assignments 
combined soaked up more than 2 /8s and you get rapid runout towards the 
endgame.
> Has anyone done any detailed analysis of the last year of allocation 
> behaviour for each of these regions, trying to understand the 
> difference in behaviour? I'd be very interested in this.
>
> My belief (not well founded) is that ARIN runout will look more like 
> RIPE region than APNIC...
>



From froztbyte at froztbyte.net  Fri Apr 26 06:33:01 2013
From: froztbyte at froztbyte.net (JP)
Date: Fri, 26 Apr 2013 08:33:01 +0200
Subject: skype shoots self in foot
In-Reply-To: <m2fvydkeg1.wl%randy@psg.com>
References: <m2fvydkeg1.wl%randy@psg.com>
Message-ID: <20130426063301.GA3276@elegua.za.net>

On Fri, Apr 26, 2013 at 03:12:46PM +0900, Randy Bush wrote:
> skype seems to have made the latest 6.x incompatible with 2.8 (which
> folk who care about screen real estate run) in that video no longer
> works between them.
> 
> until widespread availability of webrtc, a bunch of us are using
> jitsi for video, https://jitsi.org/ 
>   o uses open standard protocols
>   o free, open source, apple pie, ...
>   o supports opus codec which has really good performance across a
>     wide range of bandwidth http://www.opus-codec.org/comparison/
>   o multi-participant video on xmpp-based videobridge, also open
>     source
>   o does xmpp, sip, aim, icq, yahoo, ...

And last I tried it, it kept segfaulting on something dumb ;)
Nice to see it supports opus though. And I really wish the FOSS software
in this space didn't suck so much.

> i have an ejabberd+videobridge up if folk want test/use accounts.
> and it's easy to put up your own, of course.
> 
> and while you are looking at escaping other big company servers,
> check out http://labs.bittorrent.com/experiments/sync.html, real
> peer to peer dropbox.

Since you've already done the legwork on that, maybe share some comments
so people can see how they could do it in their own env?

-J


From gih at apnic.net  Fri Apr 26 07:12:33 2013
From: gih at apnic.net (Geoff Huston)
Date: Fri, 26 Apr 2013 17:12:33 +1000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517A1E3C.3040102@bogus.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
 <517A1E3C.3040102@bogus.com>
Message-ID: <23500EB3-79B5-4992-9E50-6A19FCB3A472@apnic.net>


On 26/04/2013, at 4:27 PM, joel jaeggli <joelja at bogus.com> wrote:

>> 
>> I also find it a bit strange that the runout in APNIC and RIPE was very different. APNIC address allocation rate accelerated at the end, whereas RIPE exhaustion date kept creeping forward in time instead of closer in time, giving me the impression that there wasn't any panic there.
>> 
> apnic allocation reserved  the final /8 for /22 maximal allocations. Couple that with some qualifying very large assignments towards the end of stage two e.g between feb 1 and april 14 2011 7 provider assignments combined soaked up more than 2 /8s and you get rapid runout towards the endgame.
> 


APNIC used a 12 month allocation window right up to the point of exhaustion, while RIPE was operating on a 3 month window, as is ARIN. That may be a contributing factor in explaining the differences in behaviour in the final months / weeks.

But its not just that. 

Other factors include large developing countries with massive DSL deployments underway (China, India) mean that in the APNIC region we were not looking at a wired infrastructure market sector that was already saturated. Quite the opposite. Similarly the wireless market in Asia was / is expanding rapidly for much the same reason (wireless is cheaper to deploy than wired if you have absolutely no pre-installed wireless infrastructure). i.e. the unmet demand overhang as compared to the available address pools was massive in Asia. Now that does not imply that Europe and the Middle East has no demand overhang, but perhaps not on the same scale as was experienced by APNIC in early 2011.

Also in September last year the European financial situation was still impacting on the problems of the service industry (and still is in many countries). So the underlying capital-driven demand factors were different between Europe and Asia. Perhaps it was more challenging for European entities to demonstrate an expansion of their Internet service infrastructure over rolling 3 months windows due to a slow down in consumer demand in parts of Europe.

What factors will play out in the North American market? It might be interesting to look at address allocations by country by year. One such table of the top 10 countries in terms of IPv4 allocations since 2007 is at http://www.potaroo.net/ispcol/2013-01/2012.html, table 3.The peak US year was 2007 with 48M addresses. in 2011 ARIN introduced the 3 month allocation window, and allocating that year halved from the previous year. Last year they were a little higher at 28M addresses. What drove last year's numbers in ARIN was a total of 16M addresses allocated to Canadian entities. So to what extent is this a saturated market already in terms of the deployment of service infrastructure? To what extent are new devices simply replacing old, and to what extent are the dynamics of the market in that region driven by provider churn as distinct from greenfields expansion? Obviously the answers to such questions have a strong impact on the underlying model of overall demand for more addresses in the region.

And of course one of the hardest factors of all: Panic is extremely difficult to model. Most forms of predictive modelling reach back in time and then use that date to push forward. but panic is of course different. It does not drive off past behaviour but feeds off itself. The APNIC runout was exceptionally hard to model at the time because the incidence of large allocations rose very quickly in March. Yes, I'd ascribe that to panic. That reaction was not so evident in RIPE in August / September last year. So it appears that panic, or the level of panic, is not a constant factor. Different regions at different times appear to elicit different responses to impending exhaustion.


Geoff









From randy at psg.com  Fri Apr 26 07:24:01 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Apr 2013 16:24:01 +0900
Subject: skype shoots self in foot
In-Reply-To: <20130426063301.GA3276@elegua.za.net>
References: <m2fvydkeg1.wl%randy@psg.com> <20130426063301.GA3276@elegua.za.net>
Message-ID: <m2ehdxkb5a.wl%randy@psg.com>

>> until widespread availability of webrtc, a bunch of us are using
>> jitsi for video, https://jitsi.org/ 
> And last I tried it, it kept segfaulting on something dumb ;)

try the nightlies

>> and while you are looking at escaping other big company servers,
>> check out http://labs.bittorrent.com/experiments/sync.html, real
>> peer to peer dropbox.
> Since you've already done the legwork on that, maybe share some
> comments so people can see how they could do it in their own env?

only issue we have hit so far is nat punching, and that could be our
mistake.

randy


From don at bowenvale.co.nz  Fri Apr 26 07:29:28 2013
From: don at bowenvale.co.nz (Don Gould)
Date: Fri, 26 Apr 2013 19:29:28 +1200
Subject: IPv6 and HTTPS
In-Reply-To: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
Message-ID: <517A2CD8.3040301@bowenvale.co.nz>

Hi Jay,

The DTC hosting control panel team had a chat about this issue earlier 
in the year.

http://gplhost.sg/lists/dtcdev/msg03482.html - Interesting reading.

I followed a little, but decided that SNI just isn't worth our time.

In my personal view, an hour spent on SNI is an hour wasted that I 
should be spending on IPv6.

There's still more than enough IPv4 space about, it's just going to get 
more and more expensive.

http://www.geekzone.co.nz/forums.asp?forumid=49&topicid=116328

I'm happy to put IP space costs on my customers to help fund my IPv6 
progress where I can.

I agree with others that there is still way to much XP and other non 
supporting platforms and I suspect that by the time we get those out of 
the system we'll be most of the way there for IPv6 access.

I feel a bit like it's a case of "am I committed to IPv6 or not?".

D


On 26/04/2013 1:24 p.m., Jay Ashworth wrote:
> Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger
> networks:
>
> Does anyone know how much IPv4 space is allocated *specifically* to cater
> to the fact that HTTPS requires a dedicated IP per DNS name?
>
> Is that a statistically significant percentage of all the IPs in use?
>
> Wasn't there something going on to make HTTPS IP muxable?  How's that coming?
>
> How fast could it be deployed?
>
> Cheers,
> -- jra
>
> [1] Ok, five questions.
>
> -- 
> Don Gould
> 31 Acheson Ave
> Mairehau
> Christchurch, New Zealand
> Ph: + 64 3 348 7235
> Mobile: + 64 21 114 0699
>


From randy at psg.com  Fri Apr 26 09:16:32 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Apr 2013 18:16:32 +0900
Subject: lag testbed needed
Message-ID: <m27gjpk5xr.wl%randy@psg.com>

a small gaggle of researchers are looking at some measurements over 
a setup like this

  .----------.                                     .----------.
  |  source  |------- RTR ============== RTR ------|  target  |
  |   host   |              LAG Bundle             |   host   |
  `----------'                >= 30ms              `----------'

where we run code on the source host pinging and paris tracrouting
to the target and collecting the data.

we have the results from a friendly isp.  we would like to be feel more
comfortable that our results are not unique to that isp's network and/or
router configurations.  so we would very much apprecuiate some LAG user
who can run the code for us on their network.  it takes approx ten hours
and presents a very light load to the hosts.

thanks

randy


From owen at delong.com  Fri Apr 26 11:31:02 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 26 Apr 2013 07:31:02 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <5179EB1F.8070302@mtcc.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
Message-ID: <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com>


On Apr 25, 2013, at 10:49 PM, Michael Thomas <mike at mtcc.com> wrote:

> On 04/25/2013 07:27 PM, Owen DeLong wrote:
>>> At some level, I wonder how much the feedback loop of "providers
>>> won't deploy ipv6 because everybody says they won't deploy ipv6"
>>> has caused this self-fulfilling prophecy :/
>> It's a definite issue. The bigger issue is the financial incentives are all in the
>> wrong direction.
>> 
>> Eyeball networks have an incentive not to deploy IPv6 until content providers
>> have done so or until they have no other choice.
> 
> Yet, eyeball networks are the ones being asked to pony up all of the
> cost to put in place the hacks to keep v4 running so they don't get
> support center calls. That's a pretty asymmetric, and a potential opportunity.

Quite the contrary? I personally think that the abysmal rate of IPv6 adoption among
some content providers (Are you listening, Amazon, Xbox, BING?) is just plain shameful.

I applaud Yahoo, Google, Facebook, and others who have adopted IPv6. I'd like
to applaud Netflix here, but they keep going back and forth on their IPv6 support,
so they get a one-handed clap for the moment.

I'm trying to encourage people to push on the content providers to deploy IPv6
to avoid the need for eyeball networks to pony up all these bizarre hacks.

Lee Howard has some rather interesting research showing that for eyeball
networks, the most cost effective thing up to about (IIRC) $15/address is to
simply keep buying IPv4 addresses on the transfer market. Beyond that, it
actually becomes cheaper to simply go IPv6-only and accept the loss of
customers that won't accept that solution.

>>> On the other hand, there is The Cloud. I assume that aws and all of the
>>> other major vm farms have native v6 networks by now (?). I hooked up
>> You again assume facts not in evidence. Many cloud providers have done
>> IPv6. Rackspace stands out as exemplary in this regard. Linode has done
>> some good work in this space.
>> 
>> AWS stands out as a complete laggard in this area.
> 
> Heh... that's why I put all kinds of question marks and hedges :)
> That's disappointing about aws. On the other hand, if aws lights
> up v6, a huge amount of content will be v6 capable in one swell-foop.
> Which is a different problem of death by a thousand cuts of corpro
> data centers, and racked up servers in no-name cages.

Actually, if Amazon.com lit up IPv6, it would dramatically change the IPv6-only
client landscape. I believe they are the single largest IPv4-only content provider
remaining. IIRC from Lee's statistics, Amazon + any 2 other members of the
Alexa 100 would make it possible for 70% or more of web traffic to go over
IPv6.

>>> v6 support on linode in, oh, less than an hour for my site. Maybe part
>>> of this just evangelizing with the Cloud folks to get the word out that
>>> v6 is both supported *and* beneficial for your site? And it might give them
>>> a leg up with "legacy" web infrastructure data centers to lure them? "Oh,
>>> your corpro IT guys won't light up v6? let me show you how easy it is on
>>> $MEGACLOUD".
>> +1 -- I encourage people to seek providers that support IPv6.
>> 
> 
> Name. and. shame. At some level, some amount of bs is probably useful
> to scare the suits: "OMG, VZW'S PHONES SUPPORT V6, DO WE DO THAT????".
> Roll your eyes, but, well, remember they're suits.

I've been doing just that. Interestingly, I got a great deal of criticism for doing
so recently.

Owen



From tore at fud.no  Fri Apr 26 12:37:05 2013
From: tore at fud.no (Tore Anderson)
Date: Fri, 26 Apr 2013 14:37:05 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
 <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com>
Message-ID: <517A74F1.2060808@fud.no>

* Owen DeLong

> Quite the contrary? I personally think that the abysmal rate of IPv6
> adoption among some content providers (Are you listening, Amazon,
> Xbox, BING?) is just plain shameful.

FWIW, www.bing.com resolves to IPv6 addresses from where I'm sitting
(Oslo), and the page seems to load over IPv6 as well.

Also, Amazon provides some form of IPv6 (I believe it's based on 6RD or
something similar though). At least, the NLNOG RING has six
Amazon-hosted nodes, all with IPv6 enabled
(amazon0{1..6}.ring.nlnog.net). All of them respond to ICMPv6 pings from
here. Whether or not the average Amazon customer chooses to enable IPv6
or not is another story, though..

Tore


From rajiva at cisco.com  Fri Apr 26 12:45:35 2013
From: rajiva at cisco.com (Rajiv Asati (rajiva))
Date: Fri, 26 Apr 2013 12:45:35 +0000
Subject: skype shoots self in foot
In-Reply-To: <m2fvydkeg1.wl%randy@psg.com>
References: <m2fvydkeg1.wl%randy@psg.com>
Message-ID: <E0075793-FDA4-4289-BB2B-A432EF9A0E51@cisco.com>

> and while you are looking at escaping other big company servers,
> check out http://labs.bittorrent.com/experiments/sync.html, real
> peer to peer dropbox.

This looks very useful. Would love to see mobile devices (e.g. Tablets) supporting it. 

I dislike having to put my stuff on servers just for sharing among my devices. 

Cheers,
Rajiv

Sent from my Phone

On Apr 26, 2013, at 2:15 AM, "Randy Bush" <randy at psg.com> wrote:

> skype seems to have made the latest 6.x incompatible with 2.8 (which
> folk who care about screen real estate run) in that video no longer
> works between them.
> 
> until widespread availability of webrtc, a bunch of us are using
> jitsi for video, https://jitsi.org/ 
>  o uses open standard protocols
>  o free, open source, apple pie, ...
>  o supports opus codec which has really good performance across a
>    wide range of bandwidth http://www.opus-codec.org/comparison/
>  o multi-participant video on xmpp-based videobridge, also open
>    source
>  o does xmpp, sip, aim, icq, yahoo, ...
> 
> i have an ejabberd+videobridge up if folk want test/use accounts.
> and it's easy to put up your own, of course.
> 
> and while you are looking at escaping other big company servers,
> check out http://labs.bittorrent.com/experiments/sync.html, real
> peer to peer dropbox.
> 
> randy
> 


From randy at psg.com  Fri Apr 26 12:47:17 2013
From: randy at psg.com (Randy Bush)
Date: Fri, 26 Apr 2013 21:47:17 +0900
Subject: skype shoots self in foot
In-Reply-To: <E0075793-FDA4-4289-BB2B-A432EF9A0E51@cisco.com>
References: <m2fvydkeg1.wl%randy@psg.com>
 <E0075793-FDA4-4289-BB2B-A432EF9A0E51@cisco.com>
Message-ID: <m2ppxhihm2.wl%randy@psg.com>

> This looks very useful. Would love to see mobile devices (e.g.
> Tablets) supporting it.

<aol>

> I dislike having to put my stuff on servers just for sharing among my
> devices.

or for sharing between friends/co-workers.  i just don't like putting my
stuff on other people's servers, period.

randy


From maillist at webjogger.net  Fri Apr 26 13:12:25 2013
From: maillist at webjogger.net (Adam Greene)
Date: Fri, 26 Apr 2013 09:12:25 -0400
Subject: UN Secretariat building in nyc
In-Reply-To: <D95DEE66-E1D4-47F6-B2BF-4D1A2E91BD56@gmail.com>
References: <C17FBD32-4AAA-48E4-BDB1-F1FC6C183B41@gmail.com>
 <6439.1366826330@turing-police.cc.vt.edu>
 <D95DEE66-E1D4-47F6-B2BF-4D1A2E91BD56@gmail.com>
Message-ID: <018001ce427f$b22370f0$166a52d0$@webjogger.net>

Is PTP wireless an option?


--
Adam Greene
Webjogger
www.webjogger.net
845-757-4000



-----Original Message-----
From: Chris McDonald [mailto:copraphage at gmail.com] 
Sent: Wednesday, April 24, 2013 2:08 PM
To: Valdis.Kletnieks at vt.edu
Cc: nanog at nanog.org
Subject: Re: UN Secretariat building in nyc

:)

long story short-- we've got a customer ptp ds3 in there now that we're
attempting to relocate but it's become a cluster.

really willing to look at just about anything now that can happen quickly--
including plain old ip at the UN building.

thanks
chris




On Apr 24, 2013, at 1:58 PM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 23 Apr 2013 20:13:20 -0400, Chris McDonald said:
>> Does anyone have a creative (read - fast) way of getting from the mmr
there to 60 Hudson ?
> 
> Taxi? :)
> 
> Would help if you told us what exactly you were trying to get from 
> point A to point B, and in what quantities.  What will work well for 
> megabits may not work for gigabits, and dark fiber/ATM/whatever may 
> matter as well...





From yang.yu.list at gmail.com  Fri Apr 26 13:42:49 2013
From: yang.yu.list at gmail.com (Yang Yu)
Date: Fri, 26 Apr 2013 09:42:49 -0400
Subject: IPv6 and HTTPS
In-Reply-To: <26869859.4060.1366943536751.JavaMail.root@benjamin.baylink.com>
References: <FCD26398C5EDE746BFC47F43EA52A17304E0F3F2@dino.ad.hostasaurus.com>
 <26869859.4060.1366943536751.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAFwKRnSXUC5VPanLi09LfjYq7D+Eb0zpMrGAu=zPj4FvYAcJjg@mail.gmail.com>

If the hosting provider can still charge for IPv4 addresses, why would
they support SNI or IPv6 SSL ;)

I have seen a CDN using certificates with tons of domain names in
subject alternative name. Old Symbian phones don't support SAN......


On Thu, Apr 25, 2013 at 10:32 PM, Jay Ashworth <jra at baylink.com> wrote:
> ----- Original Message -----
>> From: "David Hubbard" <dhubbard at dino.hostasaurus.com>
>
>> The web server has to support it too, which means compiling
>> apache with SNI support and there are of course plenty of
>> hosts running old apache.
>
> Well, sure, but for the hoster, it's a direct benefit, not an externality;
> they have motive to fix it.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA               #natog                      +1 727 647 1274
>


From tony at lavanauts.org  Fri Apr 26 13:58:37 2013
From: tony at lavanauts.org (Antonio Querubin)
Date: Fri, 26 Apr 2013 03:58:37 -1000 (HST)
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517A1037.8050801@bogus.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
 <20130426051650.GC26847@hezmatt.org> <517A1037.8050801@bogus.com>
Message-ID: <alpine.LRH.2.03.1304260351170.6172@lavanauts.org>

On Thu, 25 Apr 2013, joel jaeggli wrote:

> On 4/25/13 10:16 PM, Matt Palmer wrote:
>> On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote:

>> Even if the only thing that supported IPv6 was ELB, and everything else was
>> still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly, 
>> and
>> ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN, 
>> AWS
>> takes care of resolution and proxies a TCP connection to your instance).

> elb ipv6 support has been in place for some time (may 2011 for us east and 
> ireland)
>
> "IPv6 support is currently available in the following Amazon EC2 regions: US 
> East (Northern Virginia), US West (Northern California), US West (Oregon), EU 
> (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Singapore).?

That use of CNAMES by AWS ELB poses a problem for websites setup as 
domainname.tld and also have MX records for the domain.  I ran into this 
problem recently with an organization that moved their website to AWS and 
found they had to use the Amazon real servers' IP address in their DNS 
instead of the ELB hostname.  Unfortunately we were told the real server 
doesn't have an IPv6 address.  Only the load balancer does.

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


From cgrundemann at gmail.com  Fri Apr 26 14:23:41 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 26 Apr 2013 10:23:41 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <23500EB3-79B5-4992-9E50-6A19FCB3A472@apnic.net>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
 <517A1E3C.3040102@bogus.com>
 <23500EB3-79B5-4992-9E50-6A19FCB3A472@apnic.net>
Message-ID: <CAC1-dtn6oiGWVyWO1hBL3byancopt2Wza_Cvnp09y6hYAdA8vQ@mail.gmail.com>

On Fri, Apr 26, 2013 at 3:12 AM, Geoff Huston <gih at apnic.net> wrote:
>
> On 26/04/2013, at 4:27 PM, joel jaeggli <joelja at bogus.com> wrote:
>
>>>
>>> I also find it a bit strange that the runout in APNIC and RIPE was very different. APNIC address allocation rate accelerated at the end, whereas RIPE exhaustion date kept creeping forward in time instead of closer in time, giving me the impression that there wasn't any panic there.
>>>
>> apnic allocation reserved  the final /8 for /22 maximal allocations. Couple that with some qualifying very large assignments towards the end of stage two e.g between feb 1 and april 14 2011 7 provider assignments combined soaked up more than 2 /8s and you get rapid runout towards the endgame.
>>
>
>
> APNIC used a 12 month allocation window right up to the point of exhaustion, while RIPE was operating on a 3 month window, as is ARIN. That may be a contributing factor in explaining the differences in behaviour in the final months / weeks.
>
> But its not just that.
>
> Other factors include large developing countries with massive DSL deployments underway (China, India) mean that in the APNIC region we were not looking at a wired infrastructure market sector that was already saturated. Quite the opposite. Similarly the wireless market in Asia was / is expanding rapidly for much the same reason (wireless is cheaper to deploy than wired if you have absolutely no pre-installed wireless infrastructure). i.e. the unmet demand overhang as compared to the available address pools was massive in Asia. Now that does not imply that Europe and the Middle East has no demand overhang, but perhaps not on the same scale as was experienced by APNIC in early 2011.
>
> Also in September last year the European financial situation was still impacting on the problems of the service industry (and still is in many countries). So the underlying capital-driven demand factors were different between Europe and Asia. Perhaps it was more challenging for European entities to demonstrate an expansion of their Internet service infrastructure over rolling 3 months windows due to a slow down in consumer demand in parts of Europe.
>
> What factors will play out in the North American market? It might be interesting to look at address allocations by country by year. One such table of the top 10 countries in terms of IPv4 allocations since 2007 is at http://www.potaroo.net/ispcol/2013-01/2012.html, table 3.The peak US year was 2007 with 48M addresses. in 2011 ARIN introduced the 3 month allocation window, and allocating that year halved from the previous year. Last year they were a little higher at 28M addresses. What drove last year's numbers in ARIN was a total of 16M addresses allocated to Canadian entities. So to what extent is this a saturated market already in terms of the deployment of service infrastructure? To what extent are new devices simply replacing old, and to what extent are the dynamics of the market in that region driven by provider churn as distinct from greenfields expansion? Obviously the answers to such questions have a strong impact on the underlying model of overall demand for more addresses in the region.

One interesting twist in all of this is that several of these new
"slow-start" players in the ARIN region seem to be servicing customers
outside of the region with equipment and services hosted here inside
the ARIN region (see slide 12 on the ARIN 31 "Policy Implementation
and Experience Report"
https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf).
This fact may negate the market saturation affect completely.

Cheers,
~Chris

> And of course one of the hardest factors of all: Panic is extremely difficult to model. Most forms of predictive modelling reach back in time and then use that date to push forward. but panic is of course different. It does not drive off past behaviour but feeds off itself. The APNIC runout was exceptionally hard to model at the time because the incidence of large allocations rose very quickly in March. Yes, I'd ascribe that to panic. That reaction was not so evident in RIPE in August / September last year. So it appears that panic, or the level of panic, is not a constant factor. Different regions at different times appear to elicit different responses to impending exhaustion.
>
>
> Geoff
>

--
@ChrisGrundemann
http://chrisgrundemann.com


From jcurran at arin.net  Fri Apr 26 14:43:51 2013
From: jcurran at arin.net (John Curran)
Date: Fri, 26 Apr 2013 14:43:51 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CAC1-dtn6oiGWVyWO1hBL3byancopt2Wza_Cvnp09y6hYAdA8vQ@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <alpine.DEB.2.00.1304241053120.26743@uplift.swm.pp.se>
 <517A1E3C.3040102@bogus.com>
 <23500EB3-79B5-4992-9E50-6A19FCB3A472@apnic.net>
 <CAC1-dtn6oiGWVyWO1hBL3byancopt2Wza_Cvnp09y6hYAdA8vQ@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC4C2A7@CHAXCH01.corp.arin.net>

On Apr 26, 2013, at 10:23 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> 
> One interesting twist in all of this is that several of these new
> "slow-start" players in the ARIN region seem to be servicing customers
> outside of the region with equipment and services hosted here inside
> the ARIN region (see slide 12 on the ARIN 31 "Policy Implementation
> and Experience Report"
> https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf).

NANOG Folks - 

Please read this slide deck, section noted by Chris.  It explains the
"situation"...  (I would not call the sudden acceleration in IP address 
issuance a problem, per se, as that is an judgement for the community 
either way.)

FYI,
/John

John Curran
President and CEO
ARIN



From morrowc.lists at gmail.com  Fri Apr 26 14:47:41 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 26 Apr 2013 10:47:41 -0400
Subject: lag testbed needed
In-Reply-To: <m27gjpk5xr.wl%randy@psg.com>
References: <m27gjpk5xr.wl%randy@psg.com>
Message-ID: <CAL9jLaZSZxAK1MK62P9bh2moYNBAfqtJSnej3O_M407Adv+LTA@mail.gmail.com>

what platform and what requirements for the network bits? is multiple lag
hops good? bad? other?


On Fri, Apr 26, 2013 at 5:16 AM, Randy Bush <randy at psg.com> wrote:

> a small gaggle of researchers are looking at some measurements over
> a setup like this
>
>   .----------.                                     .----------.
>   |  source  |------- RTR ============== RTR ------|  target  |
>   |   host   |              LAG Bundle             |   host   |
>   `----------'                >= 30ms              `----------'
>
> where we run code on the source host pinging and paris tracrouting
> to the target and collecting the data.
>
> we have the results from a friendly isp.  we would like to be feel more
> comfortable that our results are not unique to that isp's network and/or
> router configurations.  so we would very much apprecuiate some LAG user
> who can run the code for us on their network.  it takes approx ten hours
> and presents a very light load to the hosts.
>
> thanks
>
> randy
>
>

From cb.list6 at gmail.com  Fri Apr 26 15:01:45 2013
From: cb.list6 at gmail.com (cb.list6)
Date: Fri, 26 Apr 2013 08:01:45 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517A1037.8050801@bogus.com>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org>
 <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com>
 <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com>
 <5179EB1F.8070302@mtcc.com> <20130426051650.GC26847@hezmatt.org>
 <517A1037.8050801@bogus.com>
Message-ID: <CAD6AjGRSZm0dEVN3TwU7473peuntx4AVqBWSNxJNRk0Djhd-zQ@mail.gmail.com>

On Apr 25, 2013 10:29 PM, "joel jaeggli" <joelja at bogus.com> wrote:
>
> On 4/25/13 10:16 PM, Matt Palmer wrote:
>>
>> On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote:
>>>
>>> On 04/25/2013 07:27 PM, Owen DeLong wrote:
>>>>
>>>> AWS stands out as a complete laggard in this area.
>>>
>>> Heh... that's why I put all kinds of question marks and hedges :)
>>> That's disappointing about aws. On the other hand, if aws lights
>>> up v6, a huge amount of content will be v6 capable in one swell-foop.
>>
>> Even if the only thing that supported IPv6 was ELB, and everything else
was
>> still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly,
and
>> ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN,
AWS
>> takes care of resolution and proxies a TCP connection to your instance).
>
> elb ipv6 support has been in place for some time (may 2011 for us east
and ireland)
>
> "IPv6 support is currently available in the following Amazon EC2 regions:
US East (Northern Virginia), US West (Northern California), US West
(Oregon), EU (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Singapore).?

Yeah, I thought AWS ELB supported ipv6 too.

But if your ELB is tied to a VPC, that is NOT supported. I learned that one
the hard way, and now that is one less site that would be ipv6 but is not.

CB.
>>
>>
>> - Matt
>>
>
>

From Lee at asgard.org  Fri Apr 26 15:32:58 2013
From: Lee at asgard.org (Lee Howard)
Date: Fri, 26 Apr 2013 11:32:58 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com>
Message-ID: <CD9FFE76.1BEB3%Lee@asgard.org>



On 4/26/13 7:31 AM, "Owen DeLong" <owen at delong.com> wrote:

>
>On Apr 25, 2013, at 10:49 PM, Michael Thomas <mike at mtcc.com> wrote:
>
>> On 04/25/2013 07:27 PM, Owen DeLong wrote:
>>>> At some level, I wonder how much the feedback loop of "providers
>>>> won't deploy ipv6 because everybody says they won't deploy ipv6"
>>>> has caused this self-fulfilling prophecy :/
>>> It's a definite issue. The bigger issue is the financial incentives
>>>are all in the
>>> wrong direction.
>>> 
>>> Eyeball networks have an incentive not to deploy IPv6 until content
>>>providers
>>> have done so or until they have no other choice.
>> 
>> Yet, eyeball networks are the ones being asked to pony up all of the
>> cost to put in place the hacks to keep v4 running so they don't get
>> support center calls. That's a pretty asymmetric, and a potential
>>opportunity.
>
>Quite the contrary? I personally think that the abysmal rate of IPv6
>adoption among
>some content providers (Are you listening, Amazon, Xbox, BING?) is just
>plain shameful.

Bing supports IPv6: http://www.worldipv6launch.org/
The site www.xbox.com supports IPv6 (ditto), but the Xbox device does not.
My favorite place to see what content supports IPv6 is Eric Vyncke's site:
http://www.vyncke.org/ipv6status/detailed.php?country=us
Thus, credit to Microsoft for Bing, but points off for live.com, msn.com,
microsoft.com, etc.

Similarly, partial credit to Amazon for ELB on AWS [1], but points off for
amazon.com, ebay.com, and for pity's sake, aws.amazon.com and
amazonaws.com.


[1] 
http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-secu
ritygroups/

>
>I applaud Yahoo, Google, Facebook, and others who have adopted IPv6. I'd
>like
>to applaud Netflix here, but they keep going back and forth on their IPv6
>support,
>so they get a one-handed clap for the moment.
>
>I'm trying to encourage people to push on the content providers to deploy
>IPv6
>to avoid the need for eyeball networks to pony up all these bizarre hacks.
>
>Lee Howard has some rather interesting research showing that for eyeball
>networks, the most cost effective thing up to about (IIRC) $15/address is
>to
>simply keep buying IPv4 addresses on the transfer market. Beyond that, it
>actually becomes cheaper to simply go IPv6-only and accept the loss of
>customers that won't accept that solution.

See 
http://www.nanog.org/meetings/nanog56/presentations/Wednesday/wed.general.h
oward.24.wmv
and 
http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.cost-ipv4-i
pv6-dual-stack.howard.wmv
(and for dollar signs on the second one, see TCO of IPv6 at
http://new.livestream.com/internetsociety/INETDenver2013/videos/16668823  )

But to see the rest, you have come to NANOG58 in New Orleans!



>
>>>> On the other hand, there is The Cloud. I assume that aws and all of
>>>>the
>>>> other major vm farms have native v6 networks by now (?). I hooked up
>>> You again assume facts not in evidence. Many cloud providers have done
>>> IPv6. Rackspace stands out as exemplary in this regard. Linode has done
>>> some good work in this space.
>>> 
>>> AWS stands out as a complete laggard in this area.
>> 
>> Heh... that's why I put all kinds of question marks and hedges :)
>> That's disappointing about aws. On the other hand, if aws lights
>> up v6, a huge amount of content will be v6 capable in one swell-foop.
>> Which is a different problem of death by a thousand cuts of corpro
>> data centers, and racked up servers in no-name cages.
>
>Actually, if Amazon.com lit up IPv6, it would dramatically change the
>IPv6-only
>client landscape. I believe they are the single largest IPv4-only content
>provider
>remaining. IIRC from Lee's statistics, Amazon + any 2 other members of the
>Alexa 100 would make it possible for 70% or more of web traffic to go over
>IPv6.

Not mine; Alain Fiocco's numbers  at http://6lab.cisco.com/stats/
It's not quite that positive, either, but you can see in the Information
page of that site that there's a very sharp bend in which sites get the
most hits.  The top 15-20 are disproportionate; after that, in many cases
substitute web sites are available.



>
>>>> v6 support on linode in, oh, less than an hour for my site. Maybe part
>>>> of this just evangelizing with the Cloud folks to get the word out
>>>>that
>>>> v6 is both supported *and* beneficial for your site? And it might
>>>>give them
>>>> a leg up with "legacy" web infrastructure data centers to lure them?
>>>>"Oh,
>>>> your corpro IT guys won't light up v6? let me show you how easy it is
>>>>on
>>>> $MEGACLOUD".
>>> +1 -- I encourage people to seek providers that support IPv6.
>>> 
>> 
>> Name. and. shame. At some level, some amount of bs is probably useful
>> to scare the suits: "OMG, VZW'S PHONES SUPPORT V6, DO WE DO THAT????".
>> Roll your eyes, but, well, remember they're suits.
>
>I've been doing just that. Interestingly, I got a great deal of criticism
>for doing
>so recently.

Where do you name and shame suits?  Hint: it isn't NANOG.

Lee, who has been known to wear a suit




From dave at temk.in  Fri Apr 26 17:14:33 2013
From: dave at temk.in (David Temkin)
Date: Fri, 26 Apr 2013 13:14:33 -0400
Subject: "Open IX" - Seeking to improve IX usefulness in the US
Message-ID: <CAFJiuForm1WA1AAmqbrkv4CvinaiOaOr2fp4VLRD0QYFZVFX8A@mail.gmail.com>

All,

A cross-functional group representing content providers, data center
providers, and NSPs are working together to provide alternative
interconnection options in various markets in the US by working to foster a
more neutral environment for interconnectivity.

We are seeking input as to what markets are the most challenging for
networks and what kind of services people would desire in those markets.

If you represent a network in the US and could fill out this survey:
http://www.surveymonkey.com/s/GD92PM8 , it would be appreciated.

Regards,
-Dave Temkin

From owen at delong.com  Fri Apr 26 17:35:15 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 26 Apr 2013 13:35:15 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517A74F1.2060808@fud.no>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
 <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com> <517A74F1.2060808@fud.no>
Message-ID: <AE5F99CA-C33F-4D65-B0C9-EE84B1478395@delong.com>

As I understand it you can get some funky level of IPv6 on some of the older
AWS products. I'm glad to hear that BING is now on IPv6. Guess they were
getting scroogled for that failure. ;-)

At least so far, this remains a problem:

Owens-MacBook-Pro:blink-cocoa owendelong$ dig aaaa amazon.com

; <<>> DiG 9.8.3-P1 <<>> aaaa amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10309
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;amazon.com.			IN	AAAA

;; AUTHORITY SECTION:
amazon.com.		60	IN	SOA	dns-external-master.amazon.com. root.amazon.com. 2010111966 180 60 3024000 60

;; Query time: 215 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Apr 26 13:34:21 2013
;; MSG SIZE  rcvd: 89


(IMHO, the above is  bigger problem than the AWS failures to implement
IPv6).

Owen

On Apr 26, 2013, at 8:37 AM, Tore Anderson <tore at fud.no> wrote:

> * Owen DeLong
> 
>> Quite the contrary? I personally think that the abysmal rate of IPv6
>> adoption among some content providers (Are you listening, Amazon,
>> Xbox, BING?) is just plain shameful.
> 
> FWIW, www.bing.com resolves to IPv6 addresses from where I'm sitting
> (Oslo), and the page seems to load over IPv6 as well.
> 
> Also, Amazon provides some form of IPv6 (I believe it's based on 6RD or
> something similar though). At least, the NLNOG RING has six
> Amazon-hosted nodes, all with IPv6 enabled
> (amazon0{1..6}.ring.nlnog.net). All of them respond to ICMPv6 pings from
> here. Whether or not the average Amazon customer chooses to enable IPv6
> or not is another story, though..
> 
> Tore



From cmadams at hiwaay.net  Fri Apr 26 17:46:00 2013
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 26 Apr 2013 12:46:00 -0500
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <AE5F99CA-C33F-4D65-B0C9-EE84B1478395@delong.com>
References: <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
 <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com> <517A74F1.2060808@fud.no>
 <AE5F99CA-C33F-4D65-B0C9-EE84B1478395@delong.com>
Message-ID: <20130426174600.GF30978@hiwaay.net>

Once upon a time, Owen DeLong <owen at delong.com> said:
> As I understand it you can get some funky level of IPv6 on some of the older
> AWS products. I'm glad to hear that BING is now on IPv6. Guess they were
> getting scroogled for that failure. ;-)

I believe Bing is Akamaized (it is for me anyway), so whether you see
Bing on IPv6 is based on whether the Akamai cluster you are pointed to
has IPv6 (it does for me).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From owen at delong.com  Fri Apr 26 17:41:04 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 26 Apr 2013 13:41:04 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CD9FFE76.1BEB3%Lee@asgard.org>
References: <CD9FFE76.1BEB3%Lee@asgard.org>
Message-ID: <42C88B30-6737-4D0C-B5CE-7DDDFD144A90@delong.com>

> Bing supports IPv6: http://www.worldipv6launch.org/

Noted.

> The site www.xbox.com supports IPv6 (ditto), but the Xbox device does not.

Noted.

> My favorite place to see what content supports IPv6 is Eric Vyncke's site:
> http://www.vyncke.org/ipv6status/detailed.php?country=us

An excellent resource.

> Thus, Microsoft points off for live.com, msn.com,
> microsoft.com, etc.
> 
> Similarly, partial credit to Amazon for ELB on AWS [1], but points off for
> amazon.com, ebay.com, and for pity's sake, aws.amazon.com and
> amazonaws.com.
> 
> 
> [1] 
> http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-secu
> ritygroups/
> 

> But to see the rest, you have come to NANOG58 in New Orleans!

Thanks for providing those links, Lee. Definitely worth watching.

>> Actually, if Amazon.com lit up IPv6, it would dramatically change the
>> IPv6-only
>> client landscape. I believe they are the single largest IPv4-only content
>> provider
>> remaining. IIRC from Lee's statistics, Amazon + any 2 other members of the
>> Alexa 100 would make it possible for 70% or more of web traffic to go over
>> IPv6.
> 
> Not mine; Alain Fiocco's numbers  at http://6lab.cisco.com/stats/
> It's not quite that positive, either, but you can see in the Information
> page of that site that there's a very sharp bend in which sites get the
> most hits.  The top 15-20 are disproportionate; after that, in many cases
> substitute web sites are available.

Thanks? Thanks for the reference as well.

>> I've been doing just that. Interestingly, I got a great deal of criticism
>> for doing
>> so recently.
> 
> Where do you name and shame suits?  Hint: it isn't NANOG.

In the case to which I refer, it was Facebook.

> Lee, who has been known to wear a suit

And who I occasionally attempt to shame for the slow pace of IPv6 deployment at TW Cable. ;-)

Owen



From cscora at apnic.net  Fri Apr 26 18:34:46 2013
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 27 Apr 2013 04:34:46 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201304261834.r3QIYkBN003413@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

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

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

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

Routing Table Report   04:00 +10GMT Sat 27 Apr, 2013

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

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

BGP routing table entries examined:                              452463
    Prefixes after maximum aggregation:                          184927
    Deaggregation factor:                                          2.45
    Unique aggregates announced to Internet:                     223134
Total ASes present in the Internet Routing Table:                 43963
    Prefixes per ASN:                                             10.29
Origin-only ASes present in the Internet Routing Table:           34555
Origin ASes announcing only one prefix:                           16096
Transit ASes present in the Internet Routing Table:                5809
Transit-only ASes present in the Internet Routing Table:            147
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      29
    Max AS path prepend of ASN ( 19037)                              22
Prefixes from unregistered ASNs in the Routing Table:               316
    Unregistered ASNs in the Routing Table:                         133
Number of 32-bit ASNs allocated by the RIRs:                       4742
Number of 32-bit ASNs visible in the Routing Table:                3599
Prefixes from 32-bit ASNs in the Routing Table:                   10189
Special use prefixes present in the Routing Table:                   22
Prefixes being announced from unallocated address space:            199
Number of addresses announced to Internet:                   2615429996
    Equivalent to 155 /8s, 228 /16s and 75 /24s
    Percentage of available address space announced:               70.6
    Percentage of allocated address space announced:               70.6
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               94.4
Total number of prefixes smaller than registry allocations:      159320

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

Prefixes being announced by APNIC Region ASes:                   108746
    Total APNIC prefixes after maximum aggregation:               33420
    APNIC Deaggregation factor:                                    3.25
Prefixes being announced from the APNIC address blocks:          109994
    Unique aggregates announced from the APNIC address blocks:    44571
APNIC Region origin ASes present in the Internet Routing Table:    4837
    APNIC Prefixes per ASN:                                       22.74
APNIC Region origin ASes announcing only one prefix:               1228
APNIC Region transit ASes present in the Internet Routing Table:    818
Average APNIC Region AS path length visible:                        4.8
    Max APNIC Region AS path length visible:                         19
Number of APNIC region 32-bit ASNs visible in the Routing Table:    509
Number of APNIC addresses announced to Internet:              720942304
    Equivalent to 42 /8s, 248 /16s and 180 /24s
    Percentage of available APNIC address space announced:         84.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, 131072-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 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:                    158813
    Total ARIN prefixes after maximum aggregation:                79935
    ARIN Deaggregation factor:                                     1.99
Prefixes being announced from the ARIN address blocks:           159458
    Unique aggregates announced from the ARIN address blocks:     72851
ARIN Region origin ASes present in the Internet Routing Table:    15671
    ARIN Prefixes per ASN:                                        10.18
ARIN Region origin ASes announcing only one prefix:                5971
ARIN Region transit ASes present in the Internet Routing Table:    1626
Average ARIN Region AS path length visible:                         4.1
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:      18
Number of ARIN addresses announced to Internet:              1063168896
    Equivalent to 63 /8s, 94 /16s and 171 /24s
    Percentage of available ARIN address space announced:          56.2

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 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:                    116767
    Total RIPE prefixes after maximum aggregation:                59562
    RIPE Deaggregation factor:                                     1.96
Prefixes being announced from the RIPE address blocks:           120320
    Unique aggregates announced from the RIPE address blocks:     77310
RIPE Region origin ASes present in the Internet Routing Table:    17150
    RIPE Prefixes per ASN:                                         7.02
RIPE Region origin ASes announcing only one prefix:                8143
RIPE Region transit ASes present in the Internet Routing Table:    2794
Average RIPE Region AS path length visible:                         5.1
    Max RIPE Region AS path length visible:                          29
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2308
Number of RIPE addresses announced to Internet:               656946660
    Equivalent to 39 /8s, 40 /16s and 53 /24s
    Percentage of available RIPE address space announced:          95.5

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 196608-199679
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:                   47383
    Total LACNIC prefixes after maximum aggregation:               9451
    LACNIC Deaggregation factor:                                   5.01
Prefixes being announced from the LACNIC address blocks:          51423
    Unique aggregates announced from the LACNIC address blocks:   24391
LACNIC Region origin ASes present in the Internet Routing Table:   1912
    LACNIC Prefixes per ASN:                                      26.89
LACNIC Region origin ASes announcing only one prefix:               568
LACNIC Region transit ASes present in the Internet Routing Table:   354
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        29
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   758
Number of LACNIC addresses announced to Internet:             127623720
    Equivalent to 7 /8s, 155 /16s and 98 /24s
    Percentage of available LACNIC address space announced:        76.1

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

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

Prefixes being announced by AfriNIC Region ASes:                  10481
    Total AfriNIC prefixes after maximum aggregation:              2518
    AfriNIC Deaggregation factor:                                  4.16
Prefixes being announced from the AfriNIC address blocks:         11069
    Unique aggregates announced from the AfriNIC address blocks:   3827
AfriNIC Region origin ASes present in the Internet Routing Table:   619
    AfriNIC Prefixes per ASN:                                     17.88
AfriNIC Region origin ASes announcing only one prefix:              186
AfriNIC Region transit ASes present in the Internet Routing Table:  130
Average AfriNIC Region AS path length visible:                      4.8
    Max AfriNIC Region AS path length visible:                       18
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    6
Number of AfriNIC addresses announced to Internet:             46315264
    Equivalent to 2 /8s, 194 /16s and 183 /24s
    Percentage of available AfriNIC address space announced:       46.0

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2950      11558         922   Korea Telecom (KIX)
17974     2512        839          90   PT TELEKOMUNIKASI INDONESIA
 7545     1888        320         109   TPG Internet Pty Ltd
 4755     1739        392         198   TATA Communications formerly 
 9829     1504       1205          40   BSNL National Internet Backbo
 9583     1285         98         538   Sify Limited
 7552     1172       1064          12   Vietel Corporation
 4808     1117       2110         326   CNCGROUP IP network: China169
 9498     1088        310          73   BHARTI Airtel Ltd.
24560     1071        385         164   Bharti Airtel Ltd., Telemedia

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3033       3694          86   bellsouth.net, inc. 
 7029     2174       1265         212   Windstream Communications Inc
18566     2067        382         184   Covad Communications 
 1785     1989        677         124   PaeTec Communications, Inc.
22773     1970       2929         125   Cox Communications, Inc.
20115     1669       1610         613   Charter Communications 
 4323     1609       1139         398   Time Warner Telecom
30036     1342        298         652   Mediacom Communications Corp 
 7018     1314      10805         850   AT&T WorldNet Services
11492     1239        228         330   Cable One 

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1802        544          16   Corbina telecom
 2118     1430         97          13   EUnet/RELCOM Autonomous Syste
34984     1149        235         206   BILISIM TELEKOM
12479      839        785          66   Uni2 Autonomous System
13188      834         99          70   Educational Network
20940      815        285         650   Akamai Technologies European 
31148      797         41          21   FreeNet ISP
 6830      775       2376         446   UPC Distribution Services
 8551      764        370          43   Bezeq International
58113      666         74         386   LIR DATACENTER TELECOM SRL

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
28573     2700       1468         102   NET Servicos de Comunicao S.A
10620     2383        413         215   TVCABLE BOGOTA 
 7303     1681       1154         214   Telecom Argentina Stet-France
 8151     1236       2692         395   UniNet S.A. de C.V. 
 6503     1065        435          68   AVANTEL, S.A. 
18881      906        780          19   Global Village Telecom 
27947      815         88          94   Telconet S.A
11830      716        364          14   Instituto Costarricense de El
 3816      696        306          85   Empresa Nacional de Telecomun
 7738      650       1306          35   Telecomunicacoes da Bahia 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
36998     1286         80           4   MOBITEL
24863      702        274          33   LINKdotNET AS number
 6713      542        617          25   Itissalat Al-MAGHRIB
 8452      404        956           9   TEDATA
24835      274         80           8   RAYA Telecom - Egypt
 3741      262        906         220   The Internet Solution 
15706      222         32           6   Sudatel Internet Exchange Aut
12258      193         28          67   Vodacom Internet Company 
29975      191        667          21   Vodacom
33776      181         12          19   Starcomms Nigeria Limited

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

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3033       3694          86   bellsouth.net, inc. 
 4766     2950      11558         922   Korea Telecom (KIX)
28573     2700       1468         102   NET Servicos de Comunicao S.A
17974     2512        839          90   PT TELEKOMUNIKASI INDONESIA
10620     2383        413         215   TVCABLE BOGOTA 
 7029     2174       1265         212   Windstream Communications Inc
18566     2067        382         184   Covad Communications 
 1785     1989        677         124   PaeTec Communications, Inc.
22773     1970       2929         125   Cox Communications, Inc.
 7545     1888        320         109   TPG Internet Pty Ltd

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

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

  ASN   No of nets  Net Savings Description
28573      2700        2598      NET Servicos de Comunicao S.A
17974      2512        2422      PT TELEKOMUNIKASI INDONESIA
10620      2383        2168      TVCABLE BOGOTA 
 4766      2950        2028      Korea Telecom (KIX)
 7029      2174        1962      Windstream Communications Inc
18566      2067        1883      Covad Communications 
 1785      1989        1865      PaeTec Communications, Inc.
22773      1970        1845      Cox Communications, Inc.
 8402      1802        1786      Corbina telecom
 7545      1888        1779      TPG Internet Pty Ltd

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

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

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
30031   UNALLOCATED  12.27.122.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24         209       Qwest 
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
14764   UNALLOCATED  12.108.237.0/24       7018       AT&T WorldNet Servic
33649   UNALLOCATED  12.111.112.0/24      19029       New Edge Networks 
26064   UNALLOCATED  12.149.37.0/24        7018       AT&T WorldNet Servic

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

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

Prefix             Origin AS  Description
128.0.0.0/24          2876     Jump Management SRL
128.0.16.0/21        43568     RIPE Network Coordination Cen
128.0.24.0/21        41794     Altline LLC
128.0.55.0/24        48571     SC efectRO SRL
128.0.58.0/23         9050     RTD-ROMTELECOM Autonomous Sys
128.0.60.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.61.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.62.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.63.0/24         9050     RTD-ROMTELECOM Autonomous Sys
128.0.72.0/21        23456     32-bit ASN transition

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

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

Network            Origin AS  Description
41.222.80.0/21       37110     Moztel LDA
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 
64.185.224.0/24      27431     JTL Networks Inc.
64.185.225.0/24      27431     JTL Networks Inc.
64.185.226.0/24      27431     JTL Networks Inc.
64.185.227.0/24      27431     JTL Networks Inc.
64.185.228.0/24      27431     JTL Networks Inc.
64.185.229.0/24      27431     JTL Networks Inc.
64.185.230.0/24      27431     JTL Networks 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:29      /11:88      /12:249     
/13:486     /14:885     /15:1566    /16:12687   /17:6635    /18:11105   
/19:21997   /20:32039   /21:33962   /22:47079   /23:41918   /24:237699  
/25:1343    /26:1662    /27:857     /28:45      /29:66      /30:18      
/31:0       /32:19      

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

  ASN   No of nets  Total ann.   Description
18566     2018          2067      Covad Communications 
 6389     1738          3033      bellsouth.net, inc. 
 7029     1611          2174      Windstream Communications Inc
 8402     1500          1802      Corbina telecom
22773     1280          1970      Cox Communications, Inc.
36998     1280          1286      MOBITEL
30036     1216          1342      Mediacom Communications Corp 
11492     1198          1239      Cable One 
 1785     1060          1989      PaeTec Communications, Inc.
 6983     1006          1133      ITC^Deltacom 

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

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

   1:781       2:757       3:3         4:15        5:876       6:5      
   8:550      12:1918     13:3        14:773      15:11       16:3      
  17:9        20:18       23:273      24:1763     27:1489     31:1249   
  32:43       33:2        34:5        36:44       37:1801     38:867    
  39:2        40:171      41:2767     42:186      44:6        46:1874   
  47:2        49:629      50:685      52:12       54:32       55:9      
  57:27       58:1139     59:588      60:308      61:1453     62:1032   
  63:2040     64:4314     65:2178     66:4312     67:2058     68:1118   
  69:3248     70:873      71:536      72:1956     74:2550     75:416    
  76:289      77:1112     78:1052     79:583      80:1242     81:984    
  82:618      83:569      84:523      85:1169     86:463      87:978    
  88:526      89:1807     90:280      91:5504     92:618      93:1730   
  94:1837     95:1542     96:521      97:343      98:1051     99:41     
 100:29      101:318     103:2509    105:520     106:143     107:209    
 108:517     109:1839    110:864     111:1046    112:503     113:785    
 114:699     115:1012    116:890     117:798     118:1058    119:1268   
 120:404     121:826     122:1757    123:1231    124:1334    125:1331   
 128:638     129:223     130:324     131:654     132:340     133:149    
 134:254     135:64      136:224     137:249     138:346     139:197    
 140:206     141:322     142:546     143:377     144:488     145:92     
 146:507     147:389     148:694     149:370     150:166     151:533    
 152:419     153:195     154:39      155:394     156:265     157:394    
 158:275     159:722     160:337     161:423     162:406     163:207    
 164:587     165:450     166:334     167:580     168:1032    169:133    
 170:1026    171:177     172:5       173:1603    174:589     175:462    
 176:1277    177:1856    178:1834    179:4       180:1412    181:409    
 182:1144    183:373     184:672     185:395     186:2295    187:1326   
 188:2047    189:1376    190:6164    192:6547    193:5838    194:4650   
 195:3492    196:1316    197:941     198:4391    199:5280    200:5899   
 201:2407    202:8882    203:8790    204:4518    205:2559    206:2843   
 207:2857    208:4053    209:3613    210:2953    211:1552    212:2043   
 213:1900    214:914     215:98      216:5199    217:1572    218:617    
 219:347     220:1273    221:554     222:317     223:443    

End of report


From dougb at dougbarton.us  Fri Apr 26 19:54:10 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 26 Apr 2013 12:54:10 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517A74F1.2060808@fud.no>
References: <C1570310-896E-4458-82AB-2EDAC04242E7@apnic.net>
 <CD9D7504.1BA1A%Lee@asgard.org> <01e301ce4127$7fcf11d0$7f6d3570$@tndh.net>
 <8C48B86A895913448548E6D15DA7553B821172@xmb-rcd-x09.cisco.com>
 <517939D1.3050302@lacnic.net> <51794ABF.5040209@mtcc.com>
 <9EEE406D-7C0E-42F0-A963-CFB9FF5CDC4C@delong.com> <51798D6C.70907@mtcc.com>
 <2D73D0AD-1980-4201-9307-438DC39AF82F@delong.com> <5179EB1F.8070302@mtcc.com>
 <3F27C6EE-FBCF-4CB1-BC83-B034634DE8B7@delong.com> <517A74F1.2060808@fud.no>
Message-ID: <517ADB62.7070905@dougbarton.us>

On 04/26/2013 05:37 AM, Tore Anderson wrote:
> * Owen DeLong
>
>> Quite the contrary? I personally think that the abysmal rate of IPv6
>> adoption among some content providers (Are you listening, Amazon,
>> Xbox, BING?) is just plain shameful.
>
> FWIW, www.bing.com resolves to IPv6 addresses from where I'm sitting
> (Oslo), and the page seems to load over IPv6 as well.

If you use firefox, the sixornot plugin will tell you that for sure. 
About 10 of the resources loaded are over IPv6, about 9 are not.

Doug




From smb at cs.columbia.edu  Fri Apr 26 19:59:32 2013
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 26 Apr 2013 15:59:32 -0400
Subject: skype shoots self in foot
In-Reply-To: <m2ehdxkb5a.wl%randy@psg.com>
References: <m2fvydkeg1.wl%randy@psg.com>
 <20130426063301.GA3276@elegua.za.net> <m2ehdxkb5a.wl%randy@psg.com>
Message-ID: <B98F9107-2991-4BBB-833D-2289CAB05EFD@cs.columbia.edu>


On Apr 26, 2013, at 3:24 AM, Randy Bush <randy at psg.com> wrote:

>>> until widespread availability of webrtc, a bunch of us are using
>>> jitsi for video, https://jitsi.org/ 
>> And last I tried it, it kept segfaulting on something dumb ;)
> 
> try the nightlies
> 
I'm trying the latest two nightlies -- two annoying bugs so far, and I haven't even tried contacting anyone yet with it.
> 


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







From randy at psg.com  Fri Apr 26 20:06:53 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 27 Apr 2013 05:06:53 +0900
Subject: skype shoots self in foot
In-Reply-To: <B98F9107-2991-4BBB-833D-2289CAB05EFD@cs.columbia.edu>
References: <m2fvydkeg1.wl%randy@psg.com> <20130426063301.GA3276@elegua.za.net>
 <m2ehdxkb5a.wl%randy@psg.com>
 <B98F9107-2991-4BBB-833D-2289CAB05EFD@cs.columbia.edu>
Message-ID: <m2ehdxgioy.wl%randy@psg.com>

report bugs.  they're great about fixes

randy


From warren at kumari.net  Fri Apr 26 20:49:10 2013
From: warren at kumari.net (Warren Kumari)
Date: Fri, 26 Apr 2013 16:49:10 -0400
Subject: KVM
In-Reply-To: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
Message-ID: <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>


On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:

> I'm looking at an IP-KVM. I don't need anything high res as I only
> need to see Linux consoles, BIOS, and RAID. What I am looking for:
> Non-Java client that runs on Linux (or a WebUI that will deploy a
> decent RDP or VNC session over SSL).
> Decent/configurable key mappings (ie, I've had a KVM a while ago where
> you had to pull down a menu for F-keys - not cool).
> Decently priced dongles (say ~$100?)
> 
> I started looking at the Raritan devices (which can be found really
> cheap on ebay) but I only see a Java client and no mention of
> installing a client on Linux.
> 

Related -- kinda.

A while back someone used to sell a cable / thingie that would allow you to use your laptop as a keyboard and monitor. Basically it had a VGA / HDMI and PS/2 port on one side, and a USB port on the other -- you'd plug the USB into your laptop (and run some client) and the VGA / PS/2 into a server, machine, whatever. Whatever the server sent would show up on the laptop -- basically this means you can avoid having a crash cart. I've done a crappy job of explaining it, but does anyone know what I'm on about? Who made this? It is still available?

W


--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett





From joelja at bogus.com  Fri Apr 26 20:57:45 2013
From: joelja at bogus.com (joel jaeggli)
Date: Fri, 26 Apr 2013 13:57:45 -0700
Subject: KVM
In-Reply-To: <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
Message-ID: <517AEA49.4040601@bogus.com>

On 4/26/13 1:49 PM, Warren Kumari wrote:
> On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:
>
>> I'm looking at an IP-KVM. I don't need anything high res as I only
>> need to see Linux consoles, BIOS, and RAID. What I am looking for:
>> Non-Java client that runs on Linux (or a WebUI that will deploy a
>> decent RDP or VNC session over SSL).
>> Decent/configurable key mappings (ie, I've had a KVM a while ago where
>> you had to pull down a menu for F-keys - not cool).
>> Decently priced dongles (say ~$100?)
>>
>> I started looking at the Raritan devices (which can be found really
>> cheap on ebay) but I only see a Java client and no mention of
>> installing a client on Linux.
>>
> Related -- kinda.
>
> A while back someone used to sell a cable / thingie that would allow you to use your laptop as a keyboard and monitor. Basically it had a VGA / HDMI and PS/2 port on one side, and a USB port on the other -- you'd plug the USB into your laptop (and run some client) and the VGA / PS/2 into a server, machine, whatever. Whatever the server sent would show up on the laptop -- basically this means you can avoid having a crash cart. I've done a crappy job of explaining it, but does anyone know what I'm on about? Who made this? It is still available?
http://www.epiphan.com/products/frame-grabbers/kvm2usb/

I thought about doing it this way and went with the lantronix spider 
instead.
> W
>
>
> --
> "Have you got any previous convictions?"
>
> "Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
> -- Terry Pratchett
>
>
>
>
>



From randy at psg.com  Fri Apr 26 21:13:38 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 27 Apr 2013 06:13:38 +0900
Subject: KVM
In-Reply-To: <517AEA49.4040601@bogus.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
 <517AEA49.4040601@bogus.com>
Message-ID: <m238udgflp.wl%randy@psg.com>

> I thought about doing it this way and went with the lantronix spider 
> instead.

the lantronix is expensive but rocks

randy


From warren at kumari.net  Fri Apr 26 21:34:26 2013
From: warren at kumari.net (Warren Kumari)
Date: Fri, 26 Apr 2013 17:34:26 -0400
Subject: KVM
In-Reply-To: <CAFv=aaunVe9DLhN6gfVGE4Uxm6vLSWOsNKgqgPkGftkVgsutNw@mail.gmail.com>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
 <CAFv=aaunVe9DLhN6gfVGE4Uxm6vLSWOsNKgqgPkGftkVgsutNw@mail.gmail.com>
Message-ID: <A4782CC3-6E81-41CA-A072-3F69638EC420@kumari.net>


On Apr 26, 2013, at 4:52 PM, John Mason <john.mason.jr at gmail.com> wrote:

> http://www.startech.com/Server-Management/KVM-Switches/Portable-USB-PS-2-KVM-Console-Adapter-for-Notebook-PCs~NOTECONS01
> 

Oh yeah, that's the one? $470.. Now I remember why I didn't buy one when I first saw it?

W

> 
> On Fri, Apr 26, 2013 at 4:49 PM, Warren Kumari <warren at kumari.net> wrote:
> 
> On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:
> 
> > I'm looking at an IP-KVM. I don't need anything high res as I only
> > need to see Linux consoles, BIOS, and RAID. What I am looking for:
> > Non-Java client that runs on Linux (or a WebUI that will deploy a
> > decent RDP or VNC session over SSL).
> > Decent/configurable key mappings (ie, I've had a KVM a while ago where
> > you had to pull down a menu for F-keys - not cool).
> > Decently priced dongles (say ~$100?)
> >
> > I started looking at the Raritan devices (which can be found really
> > cheap on ebay) but I only see a Java client and no mention of
> > installing a client on Linux.
> >
> 
> Related -- kinda.
> 
> A while back someone used to sell a cable / thingie that would allow you to use your laptop as a keyboard and monitor. Basically it had a VGA / HDMI and PS/2 port on one side, and a USB port on the other -- you'd plug the USB into your laptop (and run some client) and the VGA / PS/2 into a server, machine, whatever. Whatever the server sent would show up on the laptop -- basically this means you can avoid having a crash cart. I've done a crappy job of explaining it, but does anyone know what I'm on about? Who made this? It is still available?
> 
> W
> 
> 
> --
> "Have you got any previous convictions?"
> 
> "Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
> -- Terry Pratchett
> 
> 
> 
> 
> 

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett




From ecwnetworking at gmail.com  Fri Apr 26 15:19:54 2013
From: ecwnetworking at gmail.com (Eric Williams)
Date: Fri, 26 Apr 2013 10:19:54 -0500
Subject: Op USA - DDoS
Message-ID: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>

Does anybody have anymore information about the possible upcoming DDoS
attack (called Op USA) from the Mauritania HaCker Team besides the
information listed below on May 7th?  Any suggestions on preventing or
deflecting this type of attack and exactly what US companies or industries
they might be targeting?

http://pastebin.com/6biF9ST3

After Op Israel , Mauritania Attacker founder of  Mauritania HaCker Team ,
Ex Member in ZHC , Founder of Teamr00t and AnonGhost Team has decided to
Launch another Op wich he called "Op Usa" also same day like Op Israel but
the next month 07/05/2013.
He said that The Op Usa there will be more damage than Op Israel !

From nickguy at noanet.net  Fri Apr 26 17:54:19 2013
From: nickguy at noanet.net (Nick Guy)
Date: Fri, 26 Apr 2013 17:54:19 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <20130426174600.GF30978@hiwaay.net>
Message-ID: <CDA00D43.5A19C%nickguy@noanet.microsoftonline.com>

I can be available feel free to call.

On 4/26/13 10:46 AM, "Chris Adams" <cmadams at hiwaay.net> wrote:

>Once upon a time, Owen DeLong <owen at delong.com> said:
>> As I understand it you can get some funky level of IPv6 on some of the
>>older
>> AWS products. I'm glad to hear that BING is now on IPv6. Guess they were
>> getting scroogled for that failure. ;-)
>
>I believe Bing is Akamaized (it is for me anyway), so whether you see
>Bing on IPv6 is based on whether the Akamai cluster you are pointed to
>has IPv6 (it does for me).
>-- 
>Chris Adams <cmadams at hiwaay.net>
>Systems and Network Administrator - HiWAAY Internet Services
>I don't speak for anybody but myself - that's enough trouble.
>
>




From john.mason.jr at gmail.com  Fri Apr 26 20:52:21 2013
From: john.mason.jr at gmail.com (John Mason)
Date: Fri, 26 Apr 2013 16:52:21 -0400
Subject: KVM
In-Reply-To: <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
Message-ID: <CAFv=aaunVe9DLhN6gfVGE4Uxm6vLSWOsNKgqgPkGftkVgsutNw@mail.gmail.com>

http://www.startech.com/Server-Management/KVM-Switches/Portable-USB-PS-2-KVM-Console-Adapter-for-Notebook-PCs~NOTECONS01


On Fri, Apr 26, 2013 at 4:49 PM, Warren Kumari <warren at kumari.net> wrote:

>
> On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:
>
> > I'm looking at an IP-KVM. I don't need anything high res as I only
> > need to see Linux consoles, BIOS, and RAID. What I am looking for:
> > Non-Java client that runs on Linux (or a WebUI that will deploy a
> > decent RDP or VNC session over SSL).
> > Decent/configurable key mappings (ie, I've had a KVM a while ago where
> > you had to pull down a menu for F-keys - not cool).
> > Decently priced dongles (say ~$100?)
> >
> > I started looking at the Raritan devices (which can be found really
> > cheap on ebay) but I only see a Java client and no mention of
> > installing a client on Linux.
> >
>
> Related -- kinda.
>
> A while back someone used to sell a cable / thingie that would allow you
> to use your laptop as a keyboard and monitor. Basically it had a VGA / HDMI
> and PS/2 port on one side, and a USB port on the other -- you'd plug the
> USB into your laptop (and run some client) and the VGA / PS/2 into a
> server, machine, whatever. Whatever the server sent would show up on the
> laptop -- basically this means you can avoid having a crash cart. I've done
> a crappy job of explaining it, but does anyone know what I'm on about? Who
> made this? It is still available?
>
> W
>
>
> --
> "Have you got any previous convictions?"
>
> "Well, I dunno... I suppose I used to believe very firmly that a penny
> saved is a penny earned--"
> -- Terry Pratchett
>
>
>
>
>

From john.mason.jr at gmail.com  Fri Apr 26 21:45:10 2013
From: john.mason.jr at gmail.com (John Mason Jr)
Date: Fri, 26 Apr 2013 17:45:10 -0400
Subject: KVM
In-Reply-To: <A4782CC3-6E81-41CA-A072-3F69638EC420@kumari.net>
References: <CAH_OBicP1bxZ=zzBvZbBFKVfvNPoq2W6XHdg8WQiGiWgUa31sA@mail.gmail.com>
 <55BDA5A5-8EA8-47E6-8269-CE2C80159566@kumari.net>
 <CAFv=aaunVe9DLhN6gfVGE4Uxm6vLSWOsNKgqgPkGftkVgsutNw@mail.gmail.com>
 <A4782CC3-6E81-41CA-A072-3F69638EC420@kumari.net>
Message-ID: <68247C21-56F6-4E13-981A-DB0D9539EED4@Gmail.com>

They are cheaper at CDW

On Apr 26, 2013, at 5:34 PM, Warren Kumari <warren at kumari.net> wrote:

> 
> On Apr 26, 2013, at 4:52 PM, John Mason <john.mason.jr at gmail.com> wrote:
> 
>> http://www.startech.com/Server-Management/KVM-Switches/Portable-USB-PS-2-KVM-Console-Adapter-for-Notebook-PCs~NOTECONS01
>> 
> 
> Oh yeah, that's the one? $470.. Now I remember why I didn't buy one when I first saw it?
> 
> W
> 
>> 
>> On Fri, Apr 26, 2013 at 4:49 PM, Warren Kumari <warren at kumari.net> wrote:
>> 
>> On Apr 23, 2013, at 5:36 PM, shawn wilson <ag4ve.us at gmail.com> wrote:
>> 
>>> I'm looking at an IP-KVM. I don't need anything high res as I only
>>> need to see Linux consoles, BIOS, and RAID. What I am looking for:
>>> Non-Java client that runs on Linux (or a WebUI that will deploy a
>>> decent RDP or VNC session over SSL).
>>> Decent/configurable key mappings (ie, I've had a KVM a while ago where
>>> you had to pull down a menu for F-keys - not cool).
>>> Decently priced dongles (say ~$100?)
>>> 
>>> I started looking at the Raritan devices (which can be found really
>>> cheap on ebay) but I only see a Java client and no mention of
>>> installing a client on Linux.
>>> 
>> 
>> Related -- kinda.
>> 
>> A while back someone used to sell a cable / thingie that would allow you to use your laptop as a keyboard and monitor. Basically it had a VGA / HDMI and PS/2 port on one side, and a USB port on the other -- you'd plug the USB into your laptop (and run some client) and the VGA / PS/2 into a server, machine, whatever. Whatever the server sent would show up on the laptop -- basically this means you can avoid having a crash cart. I've done a crappy job of explaining it, but does anyone know what I'm on about? Who made this? It is still available?
>> 
>> W
>> 
>> 
>> --
>> "Have you got any previous convictions?"
>> 
>> "Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
>> -- Terry Pratchett
>> 
>> 
>> 
>> 
>> 
> 
> --
> It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett
> 
> 


From cidr-report at potaroo.net  Fri Apr 26 22:00:00 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 26 Apr 2013 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201304262200.r3QM00fk015201@wattle.apnic.net>

This report has been generated at Fri Apr 26 21:13:19 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        19-04-13    452740      260843
        20-04-13    452750      260908
        21-04-13    453181      260896
        22-04-13    452989      259783
        23-04-13    453016      260110
        24-04-13    453698      260020
        25-04-13    453821      259148
        26-04-13    453190      260026


AS Summary
         44063  Number of ASes in routing system
         18248  Number of ASes announcing only one prefix
          3033  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      116984544  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 26Apr13 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     454781   259915   194866    42.8%   All ASes

AS6389      3033       90     2943    97.0%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4766      2950      938     2012    68.2%   KIXS-AS-KR Korea Telecom
AS28573     2697      744     1953    72.4%   NET Servi?os de Comunica??o
                                               S.A.
AS17974     2510      576     1934    77.1%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS22773     1970      134     1836    93.2%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS10620     2384      701     1683    70.6%   Telmex Colombia S.A.
AS18566     2067      473     1594    77.1%   COVAD - Covad Communications
                                               Co.
AS2118      1430       49     1381    96.6%   RELCOM-AS OOO "NPO Relcom"
AS7303      1684      453     1231    73.1%   Telecom Argentina S.A.
AS4323      1612      402     1210    75.1%   TWTC - tw telecom holdings,
                                               inc.
AS4755      1739      626     1113    64.0%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1172      169     1003    85.6%   VIETEL-AS-AP Vietel
                                               Corporation
AS7029      2173     1238      935    43.0%   WINDSTREAM - Windstream
                                               Communications Inc
AS36998     1286      381      905    70.4%   SDN-MOBITEL
AS18881      908       26      882    97.1%   Global Village Telecom
AS18101     1003      179      824    82.2%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS1785      1990     1239      751    37.7%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS4808      1117      368      749    67.1%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS13977      845      133      712    84.3%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS855        736       54      682    92.7%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS8151      1244      582      662    53.2%   Uninet S.A. de C.V.
AS6983      1133      481      652    57.5%   ITCDELTA - ITC^Deltacom
AS24560     1070      426      644    60.2%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS22561     1081      449      632    58.5%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS17676      734      111      623    84.9%   GIGAINFRA Softbank BB Corp.
AS3549      1054      441      613    58.2%   GBLX Global Crossing Ltd.
AS3356      1095      498      597    54.5%   LEVEL3 Level 3 Communications
AS17908      793      197      596    75.2%   TCISL Tata Communications
AS19262      999      403      596    59.7%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS34744      654       59      595    91.0%   GVM S.C. GVM SISTEM 2003
                                               S.R.L.

Total      45163    12620    32543    72.1%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.80.0/21       AS37110 moztel-as
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.187.208.0/24      AS174   COGENT Cogent/PSI
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.229.0/24       AS30188 TELEVERGENCE - Televergence Solutions Inc.
        72.35.232.0/21       AS30097 NUWAVE - NuWave
        72.44.16.0/20        AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        81.22.64.0/20        AS5511  OPENTRANSIT France Telecom S.A.
        82.101.160.0/19      AS5511  OPENTRANSIT France Telecom S.A.
        91.197.36.0/22       AS43359 
        100.100.0.0/24       AS4847  CNIX-AP China Networks Inter-Exchange
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services LP
        164.138.97.0/24      AS58101 
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        177.67.69.0/24       AS26251 FUNDACAO JOAO PAULO II
        177.129.79.0/24      AS52886 Fundacao CPqD - Centro Pesq.Desenv.Telecom.
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA LTDA
        190.52.192.0/24      AS27919 
        190.52.193.0/24      AS27919 
        190.52.194.0/24      AS27919 
        190.52.195.0/24      AS27919 
        190.52.196.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.197.0/24      AS27919 
        190.52.198.0/24      AS27919 
        190.52.199.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.200.0/24      AS27947 Telconet S.A
        190.52.201.0/24      AS27947 Telconet S.A
        190.52.202.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.203.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.205.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.206.0/24      AS3549  GBLX Global Crossing Ltd.
        190.52.207.0/24      AS3549  GBLX Global Crossing Ltd.
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        191.255.0.0/16       AS6983  ITCDELTA - ITC^Deltacom
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.53.0.0/19        AS22011 Metro Net, S.A.P.I. de C.V.
        200.58.248.0/21      AS27849 
        200.107.248.0/24     AS27919 
        200.107.249.0/24     AS27919 
        200.107.250.0/24     AS27919 
        200.107.251.0/24     AS27919 
        200.107.252.0/24     AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
        201.71.16.0/20       AS28638 
        201.77.96.0/20       AS28639 
        201.222.32.0/20      AS27821 
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.58.113.0/24      AS19161 
        202.65.96.0/20       AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.73.240.0/20      AS2706  PI-HK Pacnet Internet (Hong Kong) Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.142.219.0/24     AS45149 
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.10.112.0/21      AS27027 ANBELL ASN-ANBELL
        204.11.112.0/22      AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation
        204.14.0.0/24        AS30693 EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS22659 
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.91.72.0/24       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        213.150.204.0/24     AS29338 AFOL-AS Used by Africaonline Operations
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.234.128.0/22     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Apr 26 22:00:02 2013
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 26 Apr 2013 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201304262200.r3QM02Bf015216@wattle.apnic.net>

BGP Update Report
Interval: 18-Apr-13 -to- 25-Apr-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            58496  1.9%      38.7 -- BSNL-NIB National Internet Backbone
 2 - AS8402            44219  1.5%      20.3 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS10620           27966  0.9%      11.7 -- Telmex Colombia S.A.
 4 - AS28573           22850  0.8%       8.4 -- NET Servi?os de Comunica??o S.A.
 5 - AS3909            22822  0.8%     691.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC
 6 - AS7552            21686  0.7%      18.2 -- VIETEL-AS-AP Vietel Corporation
 7 - AS17974           20026  0.7%       7.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 8 - AS4538            19751  0.7%      37.5 -- ERX-CERNET-BKB China Education and Research Network Center
 9 - AS33776           18144  0.6%      98.6 -- STARCOMMS-ASN
10 - AS13999           17364  0.6%      24.8 -- Mega Cable, S.A. de C.V.
11 - AS22216           16878  0.6%     324.6 -- SIEMENS-PLM - Siemens Corporation
12 - AS13188           16546  0.6%      18.0 -- BANKINFORM-AS TOV "Bank-Inform"
13 - AS22561           16161  0.5%      14.8 -- DIGITAL-TELEPORT - Digital Teleport Inc.
14 - AS6389            12184  0.4%       4.0 -- BELLSOUTH-NET-BLK - BellSouth.net Inc.
15 - AS15003           12013  0.4%      16.0 -- NOBIS-TECH - Nobis Technology Group, LLC
16 - AS4657            11896  0.4%      30.4 -- STARHUBINTERNET-AS StarHub Internet Exchange
17 - AS12880           11842  0.4%      87.7 -- DCI-AS Information Technology Company (ITC)
18 - AS647             11194  0.4%      90.3 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center
19 - AS7011            11170  0.4%       9.5 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc.
20 - AS6713            10986  0.4%      20.2 -- IAM-AS


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS6174             5830  0.2%    2915.0 -- SPRINTLINK8 - Sprint
 2 - AS35905            2915  0.1%    2915.0 -- TELX-NYC - Telx
 3 - AS38868           10532  0.3%    2633.0 -- UPM-AS-AP Universiti Putra Malaysia AS
 4 - AS14680            7147  0.2%    2382.3 -- REALE-6 - Auction.com
 5 - AS51250            1538  0.1%    1538.0 -- ITE-PROTON-AS "Information technologies enterprise "Proton" LTD
 6 - AS15957            2692  0.1%    1346.0 -- WTG-AS Web Technology Group
 7 - AS52617            1274  0.0%    1274.0 -- WF COMERCIO DE SUPRIMENTOS DE INFORMATICA LTDA
 8 - AS42531            1071  0.0%    1071.0 -- KASKADA-AS Kaskada Network
 9 - AS37367            1662  0.1%     831.0 -- CALLKEY
10 - AS50453             730  0.0%     730.0 -- EMBRIA FotoStrana Ltd
11 - AS4                 707  0.0%     286.0 -- COMUNICALO DE MEXICO S.A. DE C.V
12 - AS48359            2781  0.1%     695.2 -- HESABGAR-AS Hesabgar Pardaz Gharb Co. Private J.S.
13 - AS3909            22822  0.8%     691.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC
14 - AS32955            5028  0.2%     628.5 -- MURCOM - MURCOM, LLC
15 - AS48612            9376  0.3%     586.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
16 - AS46105             531  0.0%     531.0 -- HMLP-ASN - HealthCor Management, L.P.
17 - AS14633            3666  0.1%     523.7 -- GLOBAL-DATA-LINK - Global Data Link, Inc
18 - AS37412             443  0.0%     443.0 -- PACKET-HUB
19 - AS3                 435  0.0%    2333.0 -- CMED-AS Cmed Technology Ltd
20 - AS56678             432  0.0%     432.0 -- GYDROZO-AS LLC "Gydrozo"


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 209.142.140.0/24   9361  0.3%   AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc.
 2 - 92.246.207.0/24    9268  0.3%   AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions"
 3 - 193.19.90.0/23     8824  0.2%   AS25233 -- AWALNET-ASN Arab Company For Internet & Communications Services (AwalNet)LLC
                                     AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet
 4 - 192.58.232.0/24    7616  0.2%   AS6629  -- NOAA-AS - NOAA
 5 - 151.118.254.0/24   7575  0.2%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 6 - 151.118.255.0/24   7575  0.2%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 7 - 151.118.18.0/24    7552  0.2%   AS3909  -- QWEST-AS-3908 - Qwest Communications Company, LLC
 8 - 12.139.133.0/24    5729  0.2%   AS14680 -- REALE-6 - Auction.com
 9 - 194.63.9.0/24      4769  0.1%   AS1273  -- CW Cable and Wireless Worldwide plc
10 - 69.38.178.0/24     4273  0.1%   AS19406 -- TWRS-MA - Towerstream I, Inc.
11 - 62.84.76.0/24      3757  0.1%   AS42334 -- BBP-AS Broadband Plus s.a.l.
12 - 58.184.229.0/24    3666  0.1%   AS9950  -- PUBNETPLUS2-AS-KR DACOM
13 - 134.244.113.0/24   3338  0.1%   AS22216 -- SIEMENS-PLM - Siemens Corporation
14 - 134.244.111.0/24   3338  0.1%   AS22216 -- SIEMENS-PLM - Siemens Corporation
15 - 134.244.115.0/24   3338  0.1%   AS22216 -- SIEMENS-PLM - Siemens Corporation
16 - 134.244.119.0/24   3338  0.1%   AS22216 -- SIEMENS-PLM - Siemens Corporation
17 - 134.244.114.0/24   3338  0.1%   AS22216 -- SIEMENS-PLM - Siemens Corporation
18 - 188.123.160.0/19   3141  0.1%   AS47887 -- NEU-AS NEU Telecom & Technologies
19 - 208.64.180.0/24    2915  0.1%   AS35905 -- TELX-NYC - Telx
20 - 206.105.75.0/24    2915  0.1%   AS6174  -- SPRINTLINK8 - Sprint

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From randy at psg.com  Fri Apr 26 22:01:04 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 27 Apr 2013 07:01:04 +0900
Subject: Op USA - DDoS
In-Reply-To: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>
References: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>
Message-ID: <m2y5c5eyu7.wl%randy@psg.com>

end of net predicted.  news at eleven.


From jcurran at arin.net  Sat Apr 27 02:48:40 2013
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Apr 2013 02:48:40 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <m2d2til2wc.wl%randy@psg.com>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
 <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
 <m2d2til2wc.wl%randy@psg.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC4D939@CHAXCH01.corp.arin.net>

On Apr 25, 2013, at 5:24 PM, Randy Bush <randy at psg.com> wrote:

> amusing how much curran is interested in asserting his/arin's power and
> rights and how little he speaks to the interest of the internet and the
> isps.

The power is in the hands of this community; they get to set whatever 
policies are used for management of number resources.  ARIN has to 
defend the ability of this community to self-govern, but it is up to
them as to how much/little policy they feel is actually necessary and 
in the best interest of them and the Internet.  Note that the very same
thing occurs with the IETF or W3C having to defend the ability of that 
community to decide what is/isn't in a technical standard.

FYI,
/John



From randy at psg.com  Sat Apr 27 02:49:55 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 27 Apr 2013 11:49:55 +0900
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC4D939@CHAXCH01.corp.arin.net>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
 <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
 <m2d2til2wc.wl%randy@psg.com>
 <8DA1853CE466B041B104C1CAEE00B3748FC4D939@CHAXCH01.corp.arin.net>
Message-ID: <m2ip38g018.wl%randy@psg.com>

>> amusing how much curran is interested in asserting his/arin's power and
>> rights and how little he speaks to the interest of the internet and the
>> isps.
> The power is in the hands of this community

what bollocks


From jcurran at arin.net  Sat Apr 27 03:04:53 2013
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Apr 2013 03:04:53 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <m2ip38g018.wl%randy@psg.com>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
 <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
 <m2d2til2wc.wl%randy@psg.com>
 <8DA1853CE466B041B104C1CAEE00B3748FC4D939@CHAXCH01.corp.arin.net>
 <m2ip38g018.wl%randy@psg.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC4DAD6@CHAXCH01.corp.arin.net>

On Apr 26, 2013, at 10:49 PM, Randy Bush <randy at psg.com> wrote:

>>> amusing how much curran is interested in asserting his/arin's power and
>>> rights and how little he speaks to the interest of the internet and the
>>> isps.
>> The power is in the hands of this community
> 
> what bollocks

Well, given that anyone can participate in the policy process (including via
remote participation and still be counted), and policies are generally supported 
by an average of about 50 participants, it's actually in the hands of nearly any
group of folks that gets organized towards an outcome and wants to participate. 
I guess it's presumptuous to assume that it would be this community participating,
but frankly as long as that opportunity is readily available, then self-governance
is occurring.

FYI,
/John




From jcurran at arin.net  Sat Apr 27 03:06:15 2013
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Apr 2013 03:06:15 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CA+qj4S-K4MN6qgT7oWwWZyuUJLpArV6C=Woem2wXWVxm1LDaUw@mail.gmail.com>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
 <CA+qj4S9TV6XXdoxqZt42pAuHa_SEpWG7gr3DSn4dsZRHP9rk6w@mail.gmail.com>
 <5178175C.2050103@fud.no>
 <CA+qj4S8V17KqDjTJPMxraLA0dSHegM-3oHLrTdkPRioS3WLwYg@mail.gmail.com>
 <CA+qj4S-K4MN6qgT7oWwWZyuUJLpArV6C=Woem2wXWVxm1LDaUw@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC4DAF1@CHAXCH01.corp.arin.net>

On Apr 24, 2013, at 1:42 PM, Andrew Latham <lathama at gmail.com> wrote:

> FYI, What can ARIN, RIPE et al do to reclaim
> http://www.spamhaus.org/drop/drop.txt networks?

If you know that one of these blocks has been hijacked at ARIN, and 
can provide some supporting information, then please report it here:
<https://www.arin.net/resources/fraud/index.html>  We do investigate 
each report and if someone filled out a fraudulent request to ARIN
in the process, we can reclaim/correct the relevant address block.

Thanks!
/John

John Curran
President and CEO
ARIN



From randy at psg.com  Sat Apr 27 03:10:03 2013
From: randy at psg.com (Randy Bush)
Date: Sat, 27 Apr 2013 12:10:03 +0900
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC4DAD6@CHAXCH01.corp.arin.net>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
 <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
 <m2d2til2wc.wl%randy@psg.com>
 <8DA1853CE466B041B104C1CAEE00B3748FC4D939@CHAXCH01.corp.arin.net>
 <m2ip38g018.wl%randy@psg.com>
 <8DA1853CE466B041B104C1CAEE00B3748FC4DAD6@CHAXCH01.corp.arin.net>
Message-ID: <m2haisfz3o.wl%randy@psg.com>

sorry, bug in .procmailrc.  bye.


From jcurran at arin.net  Sat Apr 27 03:11:44 2013
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Apr 2013 03:11:44 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <m2ip38g018.wl%randy@psg.com>
References: <20130425155621.65531.qmail@joyce.lan>
 <alpine.DEB.2.00.1304251806420.26743@uplift.swm.pp.se>
 <CAC1-dtmeFj=moY+SHYQ8iY-QaNPZ2z8cyrSqMj1qDptoHQS2Ww@mail.gmail.com>
 <m2d2til2wc.wl%randy@psg.com>
 <8DA1853CE466B041B104C1CAEE00B3748FC4D939@CHAXCH01.corp.arin.net>
 <m2ip38g018.wl%randy@psg.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC4DB12@CHAXCH01.corp.arin.net>

On Apr 26, 2013, at 10:49 PM, Randy Bush <randy at psg.com> wrote:

>>> amusing how much curran is interested in asserting his/arin's power and
>>> rights and how little he speaks to the interest of the internet and the
>>> isps.
>> The power is in the hands of this community
> 
> what bollocks

Well, given that anyone can participate in the policy process (including via
remote participation and still be counted), and policies are generally supported 
by an average of about 50 participants, it's actually in the hands of nearly any
group of folks that gets organized towards an outcome and wants to participate. 
I guess it's presumptuous to assume that it would be this community participating,
but frankly as long as that opportunity is readily available, then self-governance
is occurring.

FYI,
/John




From nanog at jima.us  Sat Apr 27 04:55:44 2013
From: nanog at jima.us (Jima)
Date: Fri, 26 Apr 2013 22:55:44 -0600
Subject: IPv6 and HTTPS
In-Reply-To: <517A2CD8.3040301@bowenvale.co.nz>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz>
Message-ID: <517B5A50.5050509@jima.us>

On 2013-04-26 01:29, Don Gould wrote:
> I agree with others that there is still way to much XP and other non
> supporting platforms and I suspect that by the time we get those out of
> the system we'll be most of the way there for IPv6 access.

  And heck, you don't even need to get rid of XP for IPv6 -- just enable 
the stack.  (It's not the greatest implementation, but `ipv6 install` is 
still an easier sell than "replace your computer.")

      Jima


From ag4ve.us at gmail.com  Sat Apr 27 05:08:47 2013
From: ag4ve.us at gmail.com (shawn wilson)
Date: Sat, 27 Apr 2013 01:08:47 -0400
Subject: IPv6 and HTTPS
In-Reply-To: <517B5A50.5050509@jima.us>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
Message-ID: <CAH_OBidQZEyb=BDUrfmP+A1p5iGvoXX7WMUQ9utxJAgRLqabeA@mail.gmail.com>

There's ways around it for most software but old jetdirect stuff, switches,
routers, ip control systems. Things are going to be 6to4 for a while. In
fact I won't be surprised to see little hardware boxes that do it for $30
or so (probably late with this idea but have no need to know).
On Apr 27, 2013 12:57 AM, "Jima" <nanog at jima.us> wrote:

> On 2013-04-26 01:29, Don Gould wrote:
>
>> I agree with others that there is still way to much XP and other non
>> supporting platforms and I suspect that by the time we get those out of
>> the system we'll be most of the way there for IPv6 access.
>>
>
>  And heck, you don't even need to get rid of XP for IPv6 -- just enable
> the stack.  (It's not the greatest implementation, but `ipv6 install` is
> still an easier sell than "replace your computer.")
>
>      Jima
>
>

From nanog at jima.us  Sat Apr 27 05:22:18 2013
From: nanog at jima.us (Jima)
Date: Fri, 26 Apr 2013 23:22:18 -0600
Subject: IPv6 and HTTPS
In-Reply-To: <CAH_OBidQZEyb=BDUrfmP+A1p5iGvoXX7WMUQ9utxJAgRLqabeA@mail.gmail.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <CAH_OBidQZEyb=BDUrfmP+A1p5iGvoXX7WMUQ9utxJAgRLqabeA@mail.gmail.com>
Message-ID: <517B608A.9060101@jima.us>

On 2013-04-26 23:08, shawn wilson wrote:
> There's ways around it for most software but old jetdirect stuff,
> switches, routers, ip control systems. Things are going to be 6to4 for a
> while. In fact I won't be surprised to see little hardware boxes that do
> it for $30 or so (probably late with this idea but have no need to know).

  I hope you mean NAT64; 6to4 is, at best, iffy to support.  I do like 
the $30 hardware device idea, though -- I haven't seen anything like 
that yet.

  The majority of what I think of when you say "control systems" 
shouldn't be directly connected to the internet anyway, even with ACLs 
-- or so I gleaned from the nice folks from DHS. ;-)

      Jima


From marka at isc.org  Sat Apr 27 08:31:31 2013
From: marka at isc.org (Mark Andrews)
Date: Sat, 27 Apr 2013 18:31:31 +1000
Subject: IPv6 and HTTPS
In-Reply-To: Your message of "Fri, 26 Apr 2013 23:22:18 -0600."
 <517B608A.9060101@jima.us>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <CAH_OBidQZEyb=BDUrfmP+A1p5iGvoXX7WMUQ9utxJAgRLqabeA@mail.gmail.com>
 <517B608A.9060101@jima.us>
Message-ID: <20130427083131.9026C3317022@drugs.dv.isc.org>


In message <517B608A.9060101 at jima.us>, Jima writes:
> On 2013-04-26 23:08, shawn wilson wrote:
> > There's ways around it for most software but old jetdirect stuff,
> > switches, routers, ip control systems. Things are going to be 6to4 for a
> > while. In fact I won't be surprised to see little hardware boxes that do
> > it for $30 or so (probably late with this idea but have no need to know).
> 
>   I hope you mean NAT64; 6to4 is, at best, iffy to support.  I do like 
> the $30 hardware device idea, though -- I haven't seen anything like 
> that yet.

I saw adds for such a device a couple of years ago.
 
>   The majority of what I think of when you say "control systems" 
> shouldn't be directly connected to the internet anyway, even with ACLs 
> -- or so I gleaned from the nice folks from DHS. ;-)
> 
>       Jima
> 
-- 
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  Sat Apr 27 17:01:07 2013
From: owen at delong.com (Owen DeLong)
Date: Sat, 27 Apr 2013 10:01:07 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <517B5A50.5050509@jima.us>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
Message-ID: <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>


On Apr 26, 2013, at 9:55 PM, Jima <nanog at jima.us> wrote:

> On 2013-04-26 01:29, Don Gould wrote:
>> I agree with others that there is still way to much XP and other non
>> supporting platforms and I suspect that by the time we get those out of
>> the system we'll be most of the way there for IPv6 access.
> 
> And heck, you don't even need to get rid of XP for IPv6 -- just enable the stack.  (It's not the greatest implementation, but `ipv6 install` is still an easier sell than "replace your computer.")
> 
>     Jima

This will work until you no longer have an IPv4 resolver available for DNS. After that, XP fails miserably.

Owen



From ecwnetworking at gmail.com  Sat Apr 27 20:25:46 2013
From: ecwnetworking at gmail.com (Eric Williams)
Date: Sat, 27 Apr 2013 15:25:46 -0500
Subject: Op USA - DDoS
In-Reply-To: <m2y5c5eyu7.wl%randy@psg.com>
References: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>
 <m2y5c5eyu7.wl%randy@psg.com>
Message-ID: <D51A311A-3EF2-4516-A324-B0BD3500E3C1@gmail.com>

Absolutely hilarious... except I work for a medium size MSP and have financial and utility customers that have concerns about this.

This should be a forum for knowledge gathering from other American network engineer peers.  Hence why I posed the question about an upcoming DDoS against American industries.

If anybody has more information, please share as any insight you might have on this topic.



On Apr 26, 2013, at 5:01 PM, Randy Bush <randy at psg.com> wrote:

> end of net predicted.  news at eleven.


From erikm at buh.org  Sun Apr 28 02:21:43 2013
From: erikm at buh.org (Erik Muller)
Date: Sat, 27 Apr 2013 22:21:43 -0400
Subject: IPv6 and HTTPS
In-Reply-To: <517B608A.9060101@jima.us>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <CAH_OBidQZEyb=BDUrfmP+A1p5iGvoXX7WMUQ9utxJAgRLqabeA@mail.gmail.com>
 <517B608A.9060101@jima.us>
Message-ID: <517C87B7.2010305@buh.org>

On 4/27/13 1:22 , Jima wrote:
> On 2013-04-26 23:08, shawn wilson wrote:
>> There's ways around it for most software but old jetdirect stuff,
>> switches, routers, ip control systems. Things are going to be 6to4 for a
>> while. In fact I won't be surprised to see little hardware boxes that do
>> it for $30 or so (probably late with this idea but have no need to know).
>
>   I hope you mean NAT64; 6to4 is, at best, iffy to support.  I do like the
> $30 hardware device idea, though -- I haven't seen anything like that yet.

The idea's been done, eg http://www.gogo6.com/gogoware/gogocpe.
Not quite down to $30 there, but it'd be fairly easy to roll custom 
firmware to do 6rd or similar on a raspberry pi or beaglebone black at 
about that price point.  Finding the business case and figuring out how to 
support it is the part that gets tricky.

-e




From nanog at haller.ws  Sun Apr 28 04:39:37 2013
From: nanog at haller.ws (Patrick)
Date: Sun, 28 Apr 2013 12:39:37 +0800
Subject: Op USA - DDoS
In-Reply-To: <D51A311A-3EF2-4516-A324-B0BD3500E3C1@gmail.com>
References: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>
 <m2y5c5eyu7.wl%randy@psg.com>
 <D51A311A-3EF2-4516-A324-B0BD3500E3C1@gmail.com>
Message-ID: <20130428043936.GD14452@haller.ws>

On 2013-04-27 15:25, Eric Williams wrote:
> If anybody has more information, please share as any insight you might have on this topic.

Best Current Practices for targets appear to be:

1) Nag your upstreams to
 a) support RFC4778's automated source filtering
 b) setup an emergency filter for critical packet flows, deny the rest
2) Start detecting and feeding unwanted packets into (1a)
3) Plan what can be distributed out via CDN or other services
4) Run a DDoS fire drill and see what breaks

As attacks will change over time, start working with a security firm to
periodically review, plan, and test your mitigation techniques.


Please critique and enhance,
Patrick


From nanog at jima.us  Sun Apr 28 05:55:41 2013
From: nanog at jima.us (Jima)
Date: Sat, 27 Apr 2013 23:55:41 -0600
Subject: IPv6 and HTTPS
In-Reply-To: <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
Message-ID: <517CB9DD.9090402@jima.us>

On 2013-04-27 11:01, Owen DeLong wrote:
> On Apr 26, 2013, at 9:55 PM, Jima wrote:
>> On 2013-04-26 01:29, Don Gould wrote:
>>> I agree with others that there is still way to much XP and other non
>>> supporting platforms and I suspect that by the time we get those out of
>>> the system we'll be most of the way there for IPv6 access.
>>
>> And heck, you don't even need to get rid of XP for IPv6 -- just enable the stack.  (It's not the greatest implementation, but `ipv6 install` is still an easier sell than "replace your computer.")
>
> This will work until you no longer have an IPv4 resolver available for DNS. After that, XP fails miserably.

  I could only wish the biggest software barrier to disabling IPv4 on 
local networks was XP's DNS resolver path.

  Doing away with IPv4 isn't a sane short-term goal for anyone carrying 
along software as old as XP anyway; I'd focus on getting IPv6 to all of 
the things and marginalizing IPv4 destinations to the point that CGN is 
of reduced impact and concern.

  Oh, and a pony.

      Jima


From marka at isc.org  Sun Apr 28 07:14:07 2013
From: marka at isc.org (Mark Andrews)
Date: Sun, 28 Apr 2013 17:14:07 +1000
Subject: IPv6 and HTTPS
In-Reply-To: Your message of "Sat, 27 Apr 2013 10:01:07 -0700."
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
Message-ID: <20130428071407.B607D331CB70@drugs.dv.isc.org>


In message <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E at delong.com>, Owen DeLong writes:
>
> On Apr 26, 2013, at 9:55 PM, Jima <nanog at jima.us> wrote:
>
> > On 2013-04-26 01:29, Don Gould wrote:
> >> I agree with others that there is still way to much XP and other non
> >> supporting platforms and I suspect that by the time we get those out of
> >> the system we'll be most of the way there for IPv6 access.
> >
> > And heck, you don't even need to get rid of XP for IPv6 -- just enable
> the stack.  (It's not the greatest implementation, but `ipv6 install` is
> still an easier sell than "replace your computer.")
> >
> >     Jima
>
> This will work until you no longer have an IPv4 resolver available for
> DNS. After that, XP fails miserably.

No.  You just need to install a caching nameserver or a simple v4/v6 relay.

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


From davidianwalker at gmail.com  Sun Apr 28 15:23:24 2013
From: davidianwalker at gmail.com (David Walker)
Date: Mon, 29 Apr 2013 00:53:24 +0930
Subject: Op USA - DDoS
In-Reply-To: <20130428043936.GD14452@haller.ws>
References: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>
 <m2y5c5eyu7.wl%randy@psg.com>
 <D51A311A-3EF2-4516-A324-B0BD3500E3C1@gmail.com>
 <20130428043936.GD14452@haller.ws>
Message-ID: <CABE=bRN3D3UnA1mYdD3=-phn5Mo59sO-EZ2YT3wEc9F49vX3CA@mail.gmail.com>

>From Wikipedia:
Ultimately, #OpIsrael caused virtually no damage and was assessed by
the Israeli Government's National Cyber Bureau and by numerous
security experts and journalists to have been a failure.
http://en.wikipedia.org/wiki/OpIsrael


From wbailey at satelliteintelligencegroup.com  Sun Apr 28 16:04:22 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Sun, 28 Apr 2013 16:04:22 +0000
Subject: Op USA - DDoS
In-Reply-To: <CABE=bRN3D3UnA1mYdD3=-phn5Mo59sO-EZ2YT3wEc9F49vX3CA@mail.gmail.com>
References: <CANiTeFFc+QzFFZHgXUySPr+Z6Z23u8CwHi7FK3_xqfcY8h5OZg@mail.gmail.com>
 <m2y5c5eyu7.wl%randy@psg.com>
 <D51A311A-3EF2-4516-A324-B0BD3500E3C1@gmail.com>
 <20130428043936.GD14452@haller.ws>,
 <CABE=bRN3D3UnA1mYdD3=-phn5Mo59sO-EZ2YT3wEc9F49vX3CA@mail.gmail.com>
Message-ID: <02yjg4rrk61187kgup9ye9p9.1367165056255@email.android.com>

The last thing I would think anyone would do is tell a person the job they did last time was sub par. Imagine telling a teenager the pipe bomb they built was just not effective enough. As someone who has been on both sides of the fence, I would give you a small bit of advice.. Don't anger it. An angry high school student can be pretty damned resourceful.

Just my two cents.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: David Walker <davidianwalker at gmail.com>
Date: 04/28/2013 8:25 AM (GMT-08:00)
To: Patrick <nanog at haller.ws>
Cc: nanog at nanog.org
Subject: Re: Op USA - DDoS


>From Wikipedia:
Ultimately, #OpIsrael caused virtually no damage and was assessed by
the Israeli Government's National Cyber Bureau and by numerous
security experts and journalists to have been a failure.
http://en.wikipedia.org/wiki/OpIsrael



From randy at psg.com  Sun Apr 28 21:48:33 2013
From: randy at psg.com (Randy Bush)
Date: Sun, 28 Apr 2013 14:48:33 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <517CB9DD.9090402@jima.us>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
 <517CB9DD.9090402@jima.us>
Message-ID: <m2haiqba32.wl%randy@psg.com>

> Doing away with IPv4 isn't a sane short-term goal for anyone 

who wants global internet connectivity/reachability, period.

folk who advocate disconnecting from ipv4 should lead by example or
stfu.  either way, it would reduce the drivel level.

randy


From mysidia at gmail.com  Sun Apr 28 22:34:48 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 28 Apr 2013 17:34:48 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <m2haiqba32.wl%randy@psg.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
 <517CB9DD.9090402@jima.us> <m2haiqba32.wl%randy@psg.com>
Message-ID: <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>

On 4/28/13, Randy Bush <randy at psg.com> wrote:
>> Doing away with IPv4 isn't a sane short-term goal for anyone
> who wants global internet connectivity/reachability, period.

Breaking global connectivity is bad.   I  don't see networks turning off ipv4.

I would favor differentiation of network characteristics -- eg
Make IPv4 a service just for bulk transfer applications.
make IPv6  the best choice for interactive applications.

-- for example: large Cable providers getting together and agreeing to
 implement a 100ms RTT latency penalty for IPv4;  in other words,
heavy buffering of IPv4 traffic,  and heavy oversubscription
(Resulting in greater total performance throughput for data transfers
over Bittorrent or microtransport, but less perception of performance
for interactive applications).

This is probably what they already have,  just stop trying to throttle
IPv4 users,  so to encourage IPv6 adoption -- they just need to make
have some high capacity IPv6 only links, and make it an uncongested
service,  that will provide additional benefits to application
developers to favor it.


Under these conditions,  IPv6 service can be higher.   Don't give it
away for free;
the IPv6  Cable/DSL service should have twice the cost for the end
user as the IPv4 service does,  so that they feel the IPv6 service is
of value,   and  should include all the assistance to achieve the
greater performance.


The exhaustion of IPv4 address space also creates an inertia against
users switching around IPv4 providers (due to insufficient IP address
space available to accommodate build out of new infrastructure);
therefore,  content providers would be incentivized to get people
accessing their site over IPv6.

E.g.
 dedicated higher-capacity links for IPv6,  and less buffering to
minimize latency,  that  way  web sites initially get an incentive to
become IPv6-enabled destinations,  in the form of  perceived
improvements in performance;
without breaking connectivity.

etc. etc.

> folk who advocate disconnecting from ipv4 should lead by example or
> stfu.  either way, it would reduce the drivel level.

> randy

--
-JH


From randy at psg.com  Sun Apr 28 22:46:26 2013
From: randy at psg.com (Randy Bush)
Date: Sun, 28 Apr 2013 15:46:26 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
 <517CB9DD.9090402@jima.us> <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
Message-ID: <m2d2teb7el.wl%randy@psg.com>

> -- for example: large Cable providers getting together and agreeing to
>  implement a 100ms RTT latency penalty for IPv4

we do not see intentionally damaging our customers as a big sales
feature.  but we think all our competitors should do so.

randy


From mysidia at gmail.com  Sun Apr 28 23:32:23 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 28 Apr 2013 18:32:23 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <m2d2teb7el.wl%randy@psg.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
 <517CB9DD.9090402@jima.us> <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
Message-ID: <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>

On 4/28/13, Randy Bush <randy at psg.com> wrote:
>> -- for example: large Cable providers getting together and agreeing to
>>  implement a 100ms RTT latency penalty for IPv4
> we do not see intentionally damaging our customers as a big sales
> feature.  but we think all our competitors should do so.

Yes,  I do realize,  that because IPv6 is an external benefit
situation,  where on the whole the public avoids pain and then
benefits on the whole, with IPv6 adoption,  but for the benefits to be
obtained,  an internal cost is required  with no individual benefit
for a network user (or provider),  the actors that would need to
participate:  no individual ISP should currently see it as a big sales
feature to make their IPv4 service worse,  and no end user should see
IPv6  as something they need to jump on.

But nonetheless, there are ISPs that have undergone the cost to become
IPv6-enabled.
So at least,  there is  (at some level),  in some cases,  a potential
willingness  of providers
to make some sacrifices that ultimately provide greater benefit  to
the network community.


So something like penalize IPv4,  or disconnect from IPv4,  or
government mandated IPv6,  begin to sound like a good idea,  only
because there aren't better options,  to persuade end users to  ignore
short-term pains, adopt IPv6,   and  let  everyone  derive the
long-term benefits of IPv6.


> randy
-- 
-JH


From owen at delong.com  Sun Apr 28 23:53:50 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 28 Apr 2013 16:53:50 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
Message-ID: <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>

I don't see turning IPv4 off as a short-term goal for anyone.

OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years.

Lee Howard sees roughly the same thing. (He has fancier math and better statistics than I used).

Bottom line, it is unlikely that $residential_price will be sufficient to sustain residential IPv4 service(s) beyond about 2018. The biggest question in that equation will be what percentage of residential users are behind the unmaintainable CGN solutions and what percentage retain service similar to the current (sad) state of affairs. For the customers in the latter category, they might be able to continue until their addresses are needed for more profitable services.

Owen



From mysidia at gmail.com  Mon Apr 29 01:37:47 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 28 Apr 2013 20:37:47 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>
 <517CB9DD.9090402@jima.us> <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
Message-ID: <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>

On 4/28/13, Owen DeLong <owen at delong.com> wrote:
> I don't see turning IPv4 off as a short-term goal for anyone.
> OTOH, I do see the cost of maintaining residential IPv4 service escalating
> over about the next 5-7 years.

Yes...   Which I interpret to result in an outcome of  less service,
for more cost, for residential users, eventually,   as long  as  IPv4
addresses remain demanded in a quantity greater than the number
available.
Either  (a) CGN, or   (b) Fewer IPv4 subscriptions at higher price per
subscription,  than would otherwise occured (if IPv4 addresses were
not scarce).

Is there another possible outcome for residential IPv4 experience that
you see as likely?



(Either of those two scenarios is most likely to result in less
connectivity, fewer network users, higher cost,  and worst service per
user..)


On the other hand...   price tag $X  for  IPv6+IPv4,  no option for
just IPv4,  and   price tag   $X / 2      for just IPv6.

Could provide motivation for the residential users (and their
destinations) to move towards IPv6.    Once a large enough quantity
had moved towards IPv6 only,  the price could return to $X for IPv6
only.

And the price difference could be structured in other forms  (not
necessarily as a subscription price difference),   it could take a
non-monetary form,  such as increased privilege,  or more bandwidth
(greater throughput, higher cap) for IPv6 only users, etc.


--
-JH


From jerome at ceriz.fr  Mon Apr 29 05:03:54 2013
From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=)
Date: Mon, 29 Apr 2013 07:03:54 +0200
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517771B3.5010008@fud.no>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no>
Message-ID: <517DFF3A.6080005@ceriz.fr>

Le 24/04/2013 07:46, Tore Anderson a ?crit :
> Trying to reclaim and redistribute unused space would be a tremendous
> waste of effort.

It is necessary to keep an acceptable churn and still allocate small
blocks to newcomers, merely to deploy CGNs.

Not doing so would end up in courts for entry barrier enforced by a
monopoly (the RIRs).

Therefore it is inevitable to reclaim unused address space as long as
there's a demand for IPv4, wich will still be strong as long as major
players refuse to do their jobs.

Moreover, I think it's necessary for all responsible LIR and RIRs to
take a stand and vote policies to reclaim address space from networks
who are still not deploying IPv6 as those obviously don't want to be a
part of the Internet anymore.

-- 
J?r?me Nicolle



From jerome at ceriz.fr  Mon Apr 29 05:28:45 2013
From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=)
Date: Mon, 29 Apr 2013 07:28:45 +0200
Subject: 80 km BiDi XFPs
In-Reply-To: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
Message-ID: <517E050D.90402@ceriz.fr>

Le 03/04/2013 01:15, Frank Bulk a ?crit :
> BiDi XFPs

Why not using a duplex 120km and a circulator[1] ? This could be far
more reliable if you avoid PC connectors on the way.

You may also mux several DWDM waves using this and a low-loss mux (found
<1.5dB for 8 channels).

Of course, for such lenghts, you may need a chromatic dispersion
compensator.

[1] http://www.thorlabs.de/newgrouppage9.cfm?objectgroup_id=373
-- 
J?r?me Nicolle
06 19 31 27 14


From mysidia at gmail.com  Mon Apr 29 05:55:09 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 29 Apr 2013 00:55:09 -0500
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517DFF3A.6080005@ceriz.fr>
References: <45779.1366753300@turing-police.cc.vt.edu>
 <CA+qj4S_Pwfc_sh_rcJFDn5kCxwSB8X4yoJGPQwa9wraTnqw+HA@mail.gmail.com>
 <517771B3.5010008@fud.no> <517DFF3A.6080005@ceriz.fr>
Message-ID: <CAAAwwbUHKkEF2_qS38YmGUXA8rOU2rE4+NQSZQwUxEDr4tFj5g@mail.gmail.com>

On 4/29/13, J?r?me Nicolle <jerome at ceriz.fr> wrote:
> Therefore it is inevitable to reclaim unused address space as long as
> there's a demand for IPv4, wich will still be strong as long as major
> players refuse to do their jobs.

The RIRs are very limited in what unused resources they could seek to
reclaim; therefore, even if there are efforts, there are not likely to
be a large number of resources reclaimed for the forseeable future --
not within 12 months.

Such policy methods as transfer to specified recipient rules, and the
ARIN STLS, for example,   are the most likely path towards address
"reclamation".

The addresses that cannot be reclaimed in that manner, are probably
uneconomical to reclaim,  due to the resources, and long amount of
time it would take a RIR to implement.


> Moreover, I think it's necessary for all responsible LIR and RIRs to
> take a stand and vote policies to reclaim address space from networks
> who are still not deploying IPv6 as those obviously don't want to be a
> part of the Internet anymore.

The RIRs policy making authority is limited by certain contractual
obligations, to resource holders, and to the community, and the RIRs
cannot arbitrarily reclaim resources.

They also cannot force a holder of a resource to release or abandon
it, and attempts to do so for lack of V6 deployment,  would only serve
to reduce the legitimacy of the RIR, and result in network
instability.

The registration services agreements, at least in North American
region say that the RIRs cannot revoke resources solely for lack of
use.    And some effort of the sort would more likely wind up in the
courts.

Tthe RIRs are not permitted or don't have authority to reclaim any
IPv4 resources based on solely non-deployment of IPv6,  even if there
was some policy to that effect.


> J?r?me Nicolle
--
-JH


From jakob.heitz at ericsson.com  Mon Apr 29 06:45:25 2013
From: jakob.heitz at ericsson.com (Jakob Heitz)
Date: Mon, 29 Apr 2013 06:45:25 +0000
Subject: IPv6 and HTTPS
In-Reply-To: <mailman.518.1367213378.91371.nanog@nanog.org>
References: <mailman.518.1367213378.91371.nanog@nanog.org>
Message-ID: <28B0BBE9-5CEA-44ED-B9AA-BD63E503CEE1@ericsson.com>

That's evil.

Charge what it costs to provide each service.
If and when it costs more to provide IPv4 service (and only then), then charge more for it.

I imagine in a few years the tradeoff: IPv6 has less connectivity (IPv4 clients can't reach you), but IPv4 is more expensive (pay for the address). Then the tide might turn.


> Date: Sun, 28 Apr 2013 17:34:48 -0500
> From: Jimmy Hess <mysidia at gmail.com>
> To: Randy Bush <randy at psg.com>
> Cc: North American Network Operators Group <nanog at nanog.org>
> Subject: Re: IPv6 and HTTPS
> Message-ID:
>    <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 4/28/13, Randy Bush <randy at psg.com> wrote:
>>> Doing away with IPv4 isn't a sane short-term goal for anyone
>> who wants global internet connectivity/reachability, period.
> 
> Breaking global connectivity is bad.   I  don't see networks turning off ipv4.
> 
> I would favor differentiation of network characteristics -- eg
> Make IPv4 a service just for bulk transfer applications.
> make IPv6  the best choice for interactive applications.
> 
> -- for example: large Cable providers getting together and agreeing to
> implement a 100ms RTT latency penalty for IPv4;  in other words,
> heavy buffering of IPv4 traffic,  and heavy oversubscription
> (Resulting in greater total performance throughput for data transfers
> over Bittorrent or microtransport, but less perception of performance
> for interactive applications).
> 
> This is probably what they already have,  just stop trying to throttle
> IPv4 users,  so to encourage IPv6 adoption -- they just need to make
> have some high capacity IPv6 only links, and make it an uncongested
> service,  that will provide additional benefits to application
> developers to favor it.
> 
> 
> Under these conditions,  IPv6 service can be higher.   Don't give it
> away for free;
> the IPv6  Cable/DSL service should have twice the cost for the end
> user as the IPv4 service does,  so that they feel the IPv6 service is
> of value,   and  should include all the assistance to achieve the
> greater performance.
> 
> 
> The exhaustion of IPv4 address space also creates an inertia against
> users switching around IPv4 providers (due to insufficient IP address
> space available to accommodate build out of new infrastructure);
> therefore,  content providers would be incentivized to get people
> accessing their site over IPv6.
> 
> E.g.
> dedicated higher-capacity links for IPv6,  and less buffering to
> minimize latency,  that  way  web sites initially get an incentive to
> become IPv6-enabled destinations,  in the form of  perceived
> improvements in performance;
> without breaking connectivity.


From joelja at bogus.com  Mon Apr 29 07:23:43 2013
From: joelja at bogus.com (joel jaeggli)
Date: Mon, 29 Apr 2013 00:23:43 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <m2d2teb7el.wl%randy@psg.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
Message-ID: <517E1FFF.6060107@bogus.com>

On 4/28/13 3:46 PM, Randy Bush wrote:
>> -- for example: large Cable providers getting together and agreeing to
>>   implement a 100ms RTT latency penalty for IPv4
> we do not see intentionally damaging our customers as a big sales
> feature.  but we think all our competitors should do so.
This business is hard enough without deliberately breaking the customers.
> randy
>



From mysidia at gmail.com  Mon Apr 29 07:29:09 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 29 Apr 2013 02:29:09 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <28B0BBE9-5CEA-44ED-B9AA-BD63E503CEE1@ericsson.com>
References: <mailman.518.1367213378.91371.nanog@nanog.org>
 <28B0BBE9-5CEA-44ED-B9AA-BD63E503CEE1@ericsson.com>
Message-ID: <CAAAwwbVjdSgqX-dbZL_vBcvyqftGm8k_OXeF8ksuBHtkAAyffQ@mail.gmail.com>

On 4/29/13, Jakob Heitz <jakob.heitz at ericsson.com> wrote:
> That's evil.
> Charge what it costs to provide each service.
> If and when it costs more to provide IPv4 service (and only then), then charge more for it.

Which of the below do you suggest is evil? Offering an IPv6 only
service and charging a lower price for it?  Charging more for a
service than it costs?  Or attempting to use pricing to manipulate
consumer behavior?

Just to be clear...  using pricing, discounts, and such to manipulate
consumer behavior is pretty standard,  and such topics are complex and
messy... we should therefore only be concerned with likely
effectiveness and operational aspects, for IPv6 and v4 exhaustion, in
that regard..  on an operators list.


Most  residential providers are for-profit entities, and therefore,
do not charge what each service costs, as the price:  there is always
bound to be some margin,  and they are supposed to be pricing
services,  to achieve their business objectives,  which could include
directing customers towards products that have a greater likelihood of
being viable and highest revenue in the future.

It falls within their free will to select or adjust their pricing, so
no, discounting an IPv6 or seeking more for a service combining IPv4
and v6 won't be evil in and of itself.


If a service provider is intending to charge exactly what each service
costs,  then they should either not be in that business due to poor
performance, doing something differently,  or  management is
suppressing  their  company's revenue,  failing in their fiduciary
duties to shareholders,  which is evil,
(but ultimately represents opportunity for a competitor).

> I imagine in a few years the tradeoff: IPv6 has less connectivity (IPv4
> clients can't reach you), but IPv4 is more expensive (pay for the address).
> Then the tide might turn.

I'm more concerned about all the pain exhaustion causes in the interim;
which is definitely not mitigated through every operator just sitting
and waiting.

--
-JH


From owen at delong.com  Mon Apr 29 08:19:32 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 29 Apr 2013 01:19:32 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
Message-ID: <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>


On Apr 28, 2013, at 6:37 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On 4/28/13, Owen DeLong <owen at delong.com> wrote:
>> I don't see turning IPv4 off as a short-term goal for anyone.
>> OTOH, I do see the cost of maintaining residential IPv4 service escalating
>> over about the next 5-7 years.
> 
> Yes...   Which I interpret to result in an outcome of  less service,
> for more cost, for residential users, eventually,   as long  as  IPv4
> addresses remain demanded in a quantity greater than the number
> available.

The math says that won't work out well. Looks like it is far more economical
for residential providers to simply stop providing IPv4 to any customer that
chooses not to pay a premium for it (steep premium at that).

> Either  (a) CGN, or   (b) Fewer IPv4 subscriptions at higher price per
> subscription,  than would otherwise occured (if IPv4 addresses were
> not scarce).

Yep.

> Is there another possible outcome for residential IPv4 experience that
> you see as likely?

Depends. Unless there is sufficient mass of residential subscribers willing
to pay the premium for CGN (unlikely in my estimation), it'll make the most
sense for residential providers to simply turn off IPv4 services and tell laggard
web sites like Amazon that they are SOL in terms of getting further business
from those customers.

> (Either of those two scenarios is most likely to result in less
> connectivity, fewer network users, higher cost,  and worst service per
> user..)

Briefly? Shortly thereafter, it will result in a mad dash by the afflicted content
providers to get their act together with IPv6.

> On the other hand...   price tag $X  for  IPv6+IPv4,  no option for
> just IPv4,  and   price tag   $X / 2      for just IPv6.

Well, either way you look at it (I think in terms of $X for IPv6, $X*2 for
dual-stack) where $X is close to what you pay today. The math works
out the same, roughly.

> Could provide motivation for the residential users (and their
> destinations) to move towards IPv6.    Once a large enough quantity
> had moved towards IPv6 only,  the price could return to $X for IPv6
> only.

The destinations are the actual problem. The residential users don't care
all that much as long as they can reach their destinations. The only remaining
problem once the destinations are addressed are the consumer electronics
that lack IPv6 support. That's a much easier problem to work around.

> And the price difference could be structured in other forms  (not
> necessarily as a subscription price difference),   it could take a
> non-monetary form,  such as increased privilege,  or more bandwidth
> (greater throughput, higher cap) for IPv6 only users, etc.

Probably not. It's the cost of providing IPv4 services that will escalate. As
such, to do what you are suggesting, they'd have to raise everyone's
subscription prices at the same time as well.

Owen



From jbates at brightok.net  Mon Apr 29 14:28:10 2013
From: jbates at brightok.net (Jack Bates)
Date: Mon, 29 Apr 2013 09:28:10 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
 <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
Message-ID: <517E837A.8040402@brightok.net>

On 4/29/2013 3:19 AM, Owen DeLong wrote:
> Depends. Unless there is sufficient mass of residential subscribers 
> willing to pay the premium for CGN (unlikely in my estimation), it'll 
> make the most sense for residential providers to simply turn off IPv4 
> services and tell laggard web sites like Amazon that they are SOL in 
> terms of getting further business from those customers.

CGN isn't that bad, and if you set up an acceptable opt-out method, it 
should work fine. Some things haven't changed much. A majority of my 
customers have no need for services that NAT44 or NAT444 break in a 
noticeable way. In the same regard, I can cut their number of 
simultaneous connections drastically if need be(but 16k gains me 4:1). 
As long as their Facebook apps work, they most likely won't notice to 
opt out.

If I get 25% on CGN, I gain years of IPv4 reuse. If I succeed at 50%+, I 
suspect I'll survive the cutover.

Of course, I don't believe anyone should consider CGN without IPv6 
support. It has the potential of keeping people from noticing the CGN as 
p2p apps support IPv6.

The only thing I haven't liked is that it looks like I'll have to have 
the customer reboot after the opt-out for their IPv4 address 
reassignment (or wait it out). One CGN deployment method I'm considering 
is flow analysis of the customer traffic and automatically opting out 
customers which analysis shows will definitely not work. This analysis 
works best post dual stack deployment which isn't a problem for me.

I'm extremely happy with deterministic port block allocation(based on 
http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05?). 
Thankfully, I won't have to keep a log of every connection. I don't mind 
exporting flows for analysis, but I don't want to keep 1-2 years of them.

Jack


From owen at delong.com  Mon Apr 29 16:11:13 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 29 Apr 2013 09:11:13 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <517E837A.8040402@brightok.net>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
 <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
 <517E837A.8040402@brightok.net>
Message-ID: <CDFC1032-95D3-4056-B837-2635A846A0E1@delong.com>


On Apr 29, 2013, at 7:28 AM, Jack Bates <jbates at brightok.net> wrote:

> On 4/29/2013 3:19 AM, Owen DeLong wrote:
>> Depends. Unless there is sufficient mass of residential subscribers willing to pay the premium for CGN (unlikely in my estimation), it'll make the most sense for residential providers to simply turn off IPv4 services and tell laggard web sites like Amazon that they are SOL in terms of getting further business from those customers.
> 
> CGN isn't that bad, and if you set up an acceptable opt-out method, it should work fine. Some things haven't changed much. A majority of my customers have no need for services that NAT44 or NAT444 break in a noticeable way. In the same regard, I can cut their number of simultaneous connections drastically if need be(but 16k gains me 4:1). As long as their Facebook apps work, they most likely won't notice to opt out.

It's not a question of how bad it is (I think it actually is, but that's another discussion altogether). It's a matter of how much it costs to maintain it on an ongoing basis. The real world numbers, especially when you count up the technical support calls that are expected are pretty nasty from a "we want to make a profit selling this" perspective.

When you say a majority of customers, I think you are mistaken. The majority of services do not break. However, the vast majority of customers use at least one thing today that does break. Play Station Network, for example, doesn't do well with CGN. Yelp, for example, won't do well with CGN in terms of its geolocation proclivities. Depending on where you live and where you get CGN'd you may get interesting results with some banking institutions, Netflix, and some other things as a result of their geolocation proclivities. Google maps may or may not break in interesting ways depending on load on the CGN server and other factors. The list goes on.

A single tech support call from a customer cancels out the margin for approximately 5 months of service, so even if you only break 20% of the customers to the point of creating a tech support call each month, you lose.

> If I get 25% on CGN, I gain years of IPv4 reuse. If I succeed at 50%+, I suspect I'll survive the cutover.

Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses.

> Of course, I don't believe anyone should consider CGN without IPv6 support. It has the potential of keeping people from noticing the CGN as p2p apps support IPv6.

The more things support IPv6, the less painful CGN will be. This is certain.

> The only thing I haven't liked is that it looks like I'll have to have the customer reboot after the opt-out for their IPv4 address reassignment (or wait it out). One CGN deployment method I'm considering is flow analysis of the customer traffic and automatically opting out customers which analysis shows will definitely not work. This analysis works best post dual stack deployment which isn't a problem for me.

Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers).

> I'm extremely happy with deterministic port block allocation(based on http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05?). Thankfully, I won't have to keep a log of every connection. I don't mind exporting flows for analysis, but I don't want to keep 1-2 years of them.

Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways.

Owen



From jbates at brightok.net  Mon Apr 29 17:29:07 2013
From: jbates at brightok.net (Jack Bates)
Date: Mon, 29 Apr 2013 12:29:07 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <CDFC1032-95D3-4056-B837-2635A846A0E1@delong.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
 <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
 <517E837A.8040402@brightok.net>
 <CDFC1032-95D3-4056-B837-2635A846A0E1@delong.com>
Message-ID: <517EADE3.1010401@brightok.net>

On 4/29/2013 11:11 AM, Owen DeLong wrote:
> Best of luck with that strategy. I think this ignores the growing IPv4 
> demand that will be coming from your business customers and assumes 
> that your residential customers are all that you have to stack onto 
> these addresses. 

The residential currently eats up a majority of my addresses, so the 
more I can recover from them for business customers, the better.

> Telling a customer to reboot a router (or a single host) isn't all 
> that bad. After all, they probably did that at least 5 times at the 
> behest of your front-line support folks before they reached someone 
> that understood the problem anyway. (At least that's been my general 
> experience with most residential providers). 

Perhaps my viewpoint is different, given that I only have two lines of 
support folk, and talking to me is a rarity for a customer. :)

> Or 7, as required by CALEA. The problem with draft-donely is that 
> customers that exceed the expected number of ports run into issues (or 
> additional logging required), so you either don't get the best 
> efficiency out of your addresses, or you get problems in other ways. Owen 

That problem was mentioned on v6ops, and the general lesson that I took 
from it is to not exceed 16:1 ratio if it can be helped. 4k ports should 
be fine. 64:1 is probably sustainable for a lot of customers with 1k 
ports, but there will be a percentage that will have issues. Luckily, 
most of those with issues are usually running services that require 
opt-out anyways.

If I calculate correctly, even at 20% of my residential(70% of total 
allocated) on CGN, I'm regaining 18% of my residential assignments with 
a 16:1 ratio. I could conservatively figure a years worth of my usual 
allocation has been saved. If I can push better numbers, I'll get more 
years.

Jack


From owen at delong.com  Mon Apr 29 17:40:26 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 29 Apr 2013 10:40:26 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <517EADE3.1010401@brightok.net>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
 <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
 <517E837A.8040402@brightok.net>
 <CDFC1032-95D3-4056-B837-2635A846A0E1@delong.com>
 <517EADE3.1010401@brightok.net>
Message-ID: <E061AD1F-5CE9-48BF-BFFB-ABB985148113@delong.com>


On Apr 29, 2013, at 10:29 AM, Jack Bates <jbates at brightok.net> wrote:

> On 4/29/2013 11:11 AM, Owen DeLong wrote:
>> Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses. 
> 
> The residential currently eats up a majority of my addresses, so the more I can recover from them for business customers, the better.
> 

Point is that your business customers probably won't be so CGN tolerant and growth there will reduce the ability to multiply residential customers on recovered addresses.

>> Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers). 
> 
> Perhaps my viewpoint is different, given that I only have two lines of support folk, and talking to me is a rarity for a customer. :)
> 

I was speaking from the customer perspective. In addition to working for an ISP, I'm also a customer of multiple residential providers and have experience with a number of former providers as well.

>> Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways. Owen 
> 
> That problem was mentioned on v6ops, and the general lesson that I took from it is to not exceed 16:1 ratio if it can be helped. 4k ports should be fine. 64:1 is probably sustainable for a lot of customers with 1k ports, but there will be a percentage that will have issues. Luckily, most of those with issues are usually running services that require opt-out anyways.

Hmmm? Thinking just about my active usage, 4k ports divvied up among the 15 or so IP-speaking hosts in my house works out to just under 300 ports per host.

That's probably sufficient for relatively light usage. It would probably suck pretty bad on days when I'm doing a lot.

> If I calculate correctly, even at 20% of my residential(70% of total allocated) on CGN, I'm regaining 18% of my residential assignments with a 16:1 ratio. I could conservatively figure a years worth of my usual allocation has been saved. If I can push better numbers, I'll get more years.

What does the CGN cost you per subscriber (equipment, additional staff, etc.?)

Owen



From jbates at brightok.net  Mon Apr 29 18:00:50 2013
From: jbates at brightok.net (Jack Bates)
Date: Mon, 29 Apr 2013 13:00:50 -0500
Subject: IPv6 and HTTPS
In-Reply-To: <E061AD1F-5CE9-48BF-BFFB-ABB985148113@delong.com>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
 <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
 <517E837A.8040402@brightok.net>
 <CDFC1032-95D3-4056-B837-2635A846A0E1@delong.com>
 <517EADE3.1010401@brightok.net>
 <E061AD1F-5CE9-48BF-BFFB-ABB985148113@delong.com>
Message-ID: <517EB552.5070004@brightok.net>

On 4/29/2013 12:40 PM, Owen DeLong wrote:
>
> What does the CGN cost you per subscriber (equipment, additional staff, etc.?)
>
>

In my case, very little. Equipment was covered by bandwidth usage which 
mandated upgrading to higher end routers that support more than I need. 
It looks like my trios handle NAT with their logical services, though I 
haven't checked on if it will hit me for licensing. A services blade 
wouldn't be that bad for our load levels, though. Our front line support 
have brains and use them. We have a fair margin to play in for 
additional support time without adding new personnel. It was more costly 
dealing with people being sick, on vacation, taking lunch, etc.

Of course, we maintain 8 people in the helpdesk for only 30k 
residential. Scale does matter. I just happen to be in what I'd consider 
a sweet spot. I'm just over the point where I had to dish out money for 
an upgrade that will likely last me 10+ years minus 
EOL/software/technology issues but was cost factored for the standard 5 
years.

If the existing cards handle CGN without additional licensing, then the 
only real cost is personal, my sanity, and the company need/will not 
factor that in.


Jack


From mike at mtcc.com  Mon Apr 29 18:22:30 2013
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 29 Apr 2013 11:22:30 -0700
Subject: IPv6 and HTTPS
In-Reply-To: <517EB552.5070004@brightok.net>
References: <29592519.4046.1366939492949.JavaMail.root@benjamin.baylink.com>
 <517A2CD8.3040301@bowenvale.co.nz> <517B5A50.5050509@jima.us>
 <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com> <517CB9DD.9090402@jima.us>
 <m2haiqba32.wl%randy@psg.com>
 <CAAAwwbWyrT4dbqoXwQ-QKhGou15voeNBtr8qBbkLchX90t87Lg@mail.gmail.com>
 <m2d2teb7el.wl%randy@psg.com>
 <CAAAwwbXS-rQ0xWmQhFAs07gfNR8SAhrD1k4EHMvgh49cpg+w5Q@mail.gmail.com>
 <E013CE5C-1800-4328-9438-43F3431D83AD@delong.com>
 <CAAAwwbUejj1-5Rip2_KwY9egOOXcZj6G7qzSO1wAkGPF8v-uuA@mail.gmail.com>
 <6408EC39-BCC4-48B5-BC1C-21409F35A2DE@delong.com>
 <517E837A.8040402@brightok.net>
 <CDFC1032-95D3-4056-B837-2635A846A0E1@delong.com>
 <517EADE3.1010401@brightok.net>
 <E061AD1F-5CE9-48BF-BFFB-ABB985148113@delong.com>
 <517EB552.5070004@brightok.net>
Message-ID: <517EBA66.6050308@mtcc.com>

On 04/29/2013 11:00 AM, Jack Bates wrote:
>
> If the existing cards handle CGN without additional licensing, then the only real cost is personal, my sanity, and the company need/will not factor that in.

One thing to consider is what the new support load will be from issues dealing
with CGN causing new breakage. That might be baked into your support already,
but at larger scale it probably isn't. Maybe it's marginal, but it's worth asking.

Mike


From repstein at hostleasing.net  Mon Apr 29 18:28:03 2013
From: repstein at hostleasing.net (Randy Epstein)
Date: Mon, 29 Apr 2013 14:28:03 -0400
Subject: [NANOG-announce] New NANOG website launching tomorrow evening -
 Maintenance Notice
In-Reply-To: <CDA3E9D5.8C7D1%repstein@hostleasing.net>
Message-ID: <CDA43286.8CAB6%repstein@hostleasing.net>

Greetings NANOG community,

We have great news to report!  The redeveloped NANOG website is now ready to
go live.

Thanks to the input from the community, as well as all the volunteers that
assisted from concept to completion and every step in between.

One of the primary goals of the redesign was to present a clean, yet
functional and up to date website, improving delivery of information to
NANOG members and sponsors, as
well as providing attraction to potential new members and sponsors.  We feel
we have more than achieved this goal and hope the community feels the same.

The plan is to launch the new website on Tuesday, April 30th at 10 PM
PDT/Wednesday, May 1st at 1 AM EDT.  During this time you may experience a
brief disruption of service.

If you have any questions regarding this maintenance, please feel free to
contact me.  If you experience any issues once the new website is launched,
you may always email webmaster at nanog.org.

Thank you,

Randy Epstein
On behalf of the Website Redesign Team



-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From Lee at asgard.org  Mon Apr 29 18:46:42 2013
From: Lee at asgard.org (Lee Howard)
Date: Mon, 29 Apr 2013 14:46:42 -0400
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <517DFF3A.6080005@ceriz.fr>
Message-ID: <CDA43587.1C1A5%Lee@asgard.org>



On 4/29/13 1:03 AM, "J?r?me Nicolle" <jerome at ceriz.fr> wrote:

>Le 24/04/2013 07:46, Tore Anderson a ?crit :
>> Trying to reclaim and redistribute unused space would be a tremendous
>> waste of effort.
>
>It is necessary to keep an acceptable churn and still allocate small
>blocks to newcomers, merely to deploy CGNs.
>
>Not doing so would end up in courts for entry barrier enforced by a
>monopoly (the RIRs).

There is a /10 reserved to facilitate IPv6 deployment:
https://www.arin.net/policy/nrpm.html#four10

"Reclamation" is facilitated by offering a financial benefit, i.e.,
selling underused addresses.

>
>Therefore it is inevitable to reclaim unused address space as long as
>there's a demand for IPv4, wich will still be strong as long as major
>players refuse to do their jobs.
>
>Moreover, I think it's necessary for all responsible LIR and RIRs to
>take a stand and vote policies to reclaim address space from networks
>who are still not deploying IPv6 as those obviously don't want to be a
>part of the Internet anymore.

I encourage you to propose such a policy:
https://www.arin.net/participate/how_to_participate.html
Please make sure the proposal includes clear metrics for when to reclaim,
so ARIN staff isn't forced to rely on what may be inconsistent judgement
calls.

Lee




From jcurran at arin.net  Mon Apr 29 19:19:00 2013
From: jcurran at arin.net (John Curran)
Date: Mon, 29 Apr 2013 19:19:00 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CDA43587.1C1A5%Lee@asgard.org>
References: <CDA43587.1C1A5%Lee@asgard.org>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net>

On Apr 29, 2013, at 2:46 PM, Lee Howard <lee at asgard.org> wrote:

> On 4/29/13 1:03 AM, "J?r?me Nicolle" <jerome at ceriz.fr> wrote:
> 
>> It is necessary to keep an acceptable churn and still allocate small
>> blocks to newcomers, merely to deploy CGNs.
>> 
>> Not doing so would end up in courts for entry barrier enforced by a
>> monopoly (the RIRs).
> 
> There is a /10 reserved to facilitate IPv6 deployment:
> https://www.arin.net/policy/nrpm.html#four10
> "Reclamation" is facilitated by offering a financial benefit, i.e.,
> selling underused addresses.

Note that under the "slow start" IPv4 address allocation policies, 
small ISPs do not qualify for an initial allocation from ARIN until 
they have utilized a provider-assigned block of the minimum size
specified (based on being singly-homed or multi-homed.)  These same 
criteria now apply to receipt of an address block via transfer, so at 
regional IPv4 free pool depletion may be _very_ difficult to satisfy. 

There are a number of ways of addressing this (changing initial ISP 
allocation policy, changing dependence on allocation policies for 
transfer approvals, establishing a reserved block for new entrants,
etc.) but if left unaddressed will leave circumstances such that new 
entrants are precluded from participating in the transfer market as 
a recipient.  This is the type of outcome that is generally frowned
upon by governments for obvious reasons, and should be very carefully
considered by the community.

FYI,
/John

John Curran
President and CEO
ARIN






From pfunix at gmail.com  Mon Apr 29 20:37:07 2013
From: pfunix at gmail.com (Beavis)
Date: Mon, 29 Apr 2013 14:37:07 -0600
Subject: Need someone from telia NOC Ops
Message-ID: <CAMvhC_4h+hrfL60pd=okrH1eu+ijmr7732DYQaSe0-dOu2KcTg@mail.gmail.com>

Hi, Can someone from telia.net ops contact me offlist please.


thank you,
Beavis.



$ traceroute www.cnn.com
traceroute to www.cnn.com (157.166.249.11), 30 hops max, 60 byte packets
 1  190.106.69.113 (190.106.69.113)  16.792 ms  17.686 ms  18.049 ms
 2  186.32.189.69 (186.32.189.69)  103.475 ms  103.676 ms  103.796 ms
 3  mai-noa-I1-link.telia.net (213.248.72.161)  101.505 ms  101.635 ms
 106.750 ms
 4  atl-bb1-link.telia.net (80.91.251.28)  106.466 ms
atl-bb1-link.telia.net (80.91.245.43)  103.891 ms
atl-bb1-link.telia.net (80.91.251.28)  106.578 ms
 5  level3-ic-149649-atl-bb1.c.telia.net (80.239.167.74)  88.384 ms
88.397 ms  88.628 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Disclaimer:
http://goldmark.org/jeff/stupid-disclaimers/


From John_Brzozowski at Cable.Comcast.com  Mon Apr 29 22:38:53 2013
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Mon, 29 Apr 2013 22:38:53 +0000
Subject: Comcast Launches IPv6 for Business Customers
Message-ID: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>

FYI for folks that are interested:

http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-business-customers

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski at cable.comcast.com
w)
http://www.comcast6.net =========================================

From owen at delong.com  Mon Apr 29 23:52:01 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 29 Apr 2013 16:52:01 -0700
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net>
References: <CDA43587.1C1A5%Lee@asgard.org>
 <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net>
Message-ID: <EC120AD0-8364-4D84-AAE0-AC2E45812C3F@delong.com>

Other AC members and I are in the process of crafting a proposal to address this issue.

Please stay tuned. I hope to have something ready to post to PPML in the next few weeks.

Owen

On Apr 29, 2013, at 12:19 PM, John Curran <jcurran at arin.net> wrote:

> On Apr 29, 2013, at 2:46 PM, Lee Howard <lee at asgard.org> wrote:
> 
>> On 4/29/13 1:03 AM, "J?r?me Nicolle" <jerome at ceriz.fr> wrote:
>> 
>>> It is necessary to keep an acceptable churn and still allocate small
>>> blocks to newcomers, merely to deploy CGNs.
>>> 
>>> Not doing so would end up in courts for entry barrier enforced by a
>>> monopoly (the RIRs).
>> 
>> There is a /10 reserved to facilitate IPv6 deployment:
>> https://www.arin.net/policy/nrpm.html#four10
>> "Reclamation" is facilitated by offering a financial benefit, i.e.,
>> selling underused addresses.
> 
> Note that under the "slow start" IPv4 address allocation policies, 
> small ISPs do not qualify for an initial allocation from ARIN until 
> they have utilized a provider-assigned block of the minimum size
> specified (based on being singly-homed or multi-homed.)  These same 
> criteria now apply to receipt of an address block via transfer, so at 
> regional IPv4 free pool depletion may be _very_ difficult to satisfy. 
> 
> There are a number of ways of addressing this (changing initial ISP 
> allocation policy, changing dependence on allocation policies for 
> transfer approvals, establishing a reserved block for new entrants,
> etc.) but if left unaddressed will leave circumstances such that new 
> entrants are precluded from participating in the transfer market as 
> a recipient.  This is the type of outcome that is generally frowned
> upon by governments for obvious reasons, and should be very carefully
> considered by the community.
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
> 



From morrowc.lists at gmail.com  Tue Apr 30 02:06:30 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 29 Apr 2013 22:06:30 -0400
Subject: Comcast Launches IPv6 for Business Customers
In-Reply-To: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
Message-ID: <CAL9jLaZAKOFi=ndR=bSVykKNPVHSrzF0Q6gxYQFB=Bk1jQcBmw@mail.gmail.com>

On Mon, Apr 29, 2013 at 6:38 PM, Brzozowski, John <
John_Brzozowski at cable.comcast.com> wrote:

> FYI for folks that are interested:
>
>
> http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-business-customers
>
>
>
hurray! how long until VZ puts out a PR note for Fios Business customers?
come on folks, let's cheer them on! (seriously, someone cheer on John...
but if we cheer some for vz maybe they'll also awake from their long
slumber and start deploying v6 to business and later consumer Fios?)

From derek at derekivey.com  Tue Apr 30 02:15:03 2013
From: derek at derekivey.com (Derek Ivey)
Date: Mon, 29 Apr 2013 22:15:03 -0400
Subject: Comcast Launches IPv6 for Business Customers
In-Reply-To: <CAL9jLaZAKOFi=ndR=bSVykKNPVHSrzF0Q6gxYQFB=Bk1jQcBmw@mail.gmail.com>
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
 <CAL9jLaZAKOFi=ndR=bSVykKNPVHSrzF0Q6gxYQFB=Bk1jQcBmw@mail.gmail.com>
Message-ID: <517F2927.2050709@derekivey.com>

Thanks for all the hard work getting IPv6 deployed! I signed my company 
up for the trials. Can't wait to test it out :).

I agree, I wish Verizon would wake up and announce something. It's 
pretty sad that their IPv6 support page still says 3Q12 and they've yet 
to say any more about their plans. I'm currently using a Hurricane 
Electric tunnel, which has worked well, but I'd love to have native IPv6 
on my home FiOS connection.

On 4/29/2013 10:06 PM, Christopher Morrow wrote:
> On Mon, Apr 29, 2013 at 6:38 PM, Brzozowski, John <
> John_Brzozowski at cable.comcast.com> wrote:
>
>> FYI for folks that are interested:
>>
>>
>> http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-business-customers
>>
>>
>>
> hurray! how long until VZ puts out a PR note for Fios Business customers?
> come on folks, let's cheer them on! (seriously, someone cheer on John...
> but if we cheer some for vz maybe they'll also awake from their long
> slumber and start deploying v6 to business and later consumer Fios?)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4249 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130429/c202ed3f/attachment.bin>

From streiner at cluebyfour.org  Tue Apr 30 03:33:23 2013
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 29 Apr 2013 23:33:23 -0400 (EDT)
Subject: Comcast Launches IPv6 for Business Customers
In-Reply-To: <517F2927.2050709@derekivey.com>
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
 <CAL9jLaZAKOFi=ndR=bSVykKNPVHSrzF0Q6gxYQFB=Bk1jQcBmw@mail.gmail.com>
 <517F2927.2050709@derekivey.com>
Message-ID: <Pine.LNX.4.64.1304292332590.29314@whammy.cluebyfour.org>

On Mon, 29 Apr 2013, Derek Ivey wrote:

> Thanks for all the hard work getting IPv6 deployed! I signed my company up 
> for the trials. Can't wait to test it out :).
>
> I agree, I wish Verizon would wake up and announce something. It's pretty sad 
> that their IPv6 support page still says 3Q12 and they've yet to say any more 
> about their plans. I'm currently using a Hurricane Electric tunnel, which has 
> worked well, but I'd love to have native IPv6 on my home FiOS connection.

+1 on both counts.

jms


From dhubbard at dino.hostasaurus.com  Tue Apr 30 03:44:48 2013
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Mon, 29 Apr 2013 23:44:48 -0400
Subject: Comcast Launches IPv6 for Business Customers
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
 <CAL9jLaZAKOFi=ndR=bSVykKNPVHSrzF0Q6gxYQFB=Bk1jQcBmw@mail.gmail.com>
 <517F2927.2050709@derekivey.com>
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0F3F4@dino.ad.hostasaurus.com>

From: Derek Ivey [mailto:derek at derekivey.com] 
> 
> Thanks for all the hard work getting IPv6 deployed! I signed 
> my company up for the trials. Can't wait to test it out :).
> 
> I agree, I wish Verizon would wake up and announce something.
> It's pretty sad that their IPv6 support page still says 3Q12
> and they've yet to say any more about their plans. I'm
> currently using a Hurricane Electric tunnel, which has
> worked well, but I'd love to have native IPv6 on my home
> FiOS connection.

We just deployed Fios to a remote office; sales person had
been quite responsive on everything until I asked about
IPv6; haven't heard from him since...  If there were 
another option that did offer it we'd have taken it.  We're
using a Hurricane tunnel for the time being.

David


From nanog at bitfreak.org  Tue Apr 30 04:05:20 2013
From: nanog at bitfreak.org (Darren Pilgrim)
Date: Mon, 29 Apr 2013 21:05:20 -0700
Subject: Comcast Launches IPv6 for Business Customers
In-Reply-To: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
Message-ID: <517F4300.3070808@bitfreak.org>

On 2013-04-29 15:38, Brzozowski, John wrote:
> FYI for folks that are interested:
>
> http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-business-customers

I hope opening up IPv6 support to Comcast's higher-end customers is an 
indicator Comcast really is close to enabling IPv6 on their Cisco 
CMTSes.  Those of us on Cisco-fed nodes have had to wait too long for 
the native IPv6 enjoyed by our Arris-fed neighbors.



From morrowc.lists at gmail.com  Tue Apr 30 04:26:56 2013
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 30 Apr 2013 00:26:56 -0400
Subject: Comcast Launches IPv6 for Business Customers
In-Reply-To: <517F4300.3070808@bitfreak.org>
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
 <517F4300.3070808@bitfreak.org>
Message-ID: <CAL9jLaZAGjKqdawHmv-iM5FNLBRMPmj10TY9CGvo5XU0cT7xmw@mail.gmail.com>

On Tue, Apr 30, 2013 at 12:05 AM, Darren Pilgrim <nanog at bitfreak.org> wrote:

> On 2013-04-29 15:38, Brzozowski, John wrote:
>
>> FYI for folks that are interested:
>>
>> http://corporate.comcast.com/**comcast-voices/comcast-**
>> launches-ipv6-for-business-**customers<http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-business-customers>
>>
>
> I hope opening up IPv6 support to Comcast's higher-end customers is an
> indicator Comcast really is close to enabling IPv6 on their Cisco CMTSes.
>  Those of us on Cisco-fed nodes have had to wait too long for the native
> IPv6 enjoyed by our Arris-fed neighbors.
>


we have always been at war with your cisco-ians...

From frnkblk at iname.com  Tue Apr 30 05:05:52 2013
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 30 Apr 2013 00:05:52 -0500
Subject: 80 km BiDi XFPs
In-Reply-To: <517E050D.90402@ceriz.fr>
References: <000101ce2ff7$f17446c0$d45cd440$@iname.com>
 <517E050D.90402@ceriz.fr>
Message-ID: <003601ce4560$63abe630$2b03b290$@iname.com>

You're the first person to suggest that kind of configuration, so thanks.

We ended up purchasing an 8-wave DWDM from our transport vendor, as it
solved the problem and gives us a path to future growth.

Frank

-----Original Message-----
From: J?r?me Nicolle [mailto:jerome at ceriz.fr] 
Sent: Monday, April 29, 2013 12:29 AM
To: nanog at nanog.org
Subject: Re: 80 km BiDi XFPs

Le 03/04/2013 01:15, Frank Bulk a ?crit :
> BiDi XFPs

Why not using a duplex 120km and a circulator[1] ? This could be far
more reliable if you avoid PC connectors on the way.

You may also mux several DWDM waves using this and a low-loss mux (found
<1.5dB for 8 channels).

Of course, for such lenghts, you may need a chromatic dispersion
compensator.

[1] http://www.thorlabs.de/newgrouppage9.cfm?objectgroup_id=373
-- 
J?r?me Nicolle
06 19 31 27 14





From nanog at bitfreak.org  Tue Apr 30 05:45:49 2013
From: nanog at bitfreak.org (Darren Pilgrim)
Date: Mon, 29 Apr 2013 22:45:49 -0700
Subject: Comcast Launches IPv6 for Business Customers
In-Reply-To: <CAL9jLaZAGjKqdawHmv-iM5FNLBRMPmj10TY9CGvo5XU0cT7xmw@mail.gmail.com>
References: <BD87928F6BFAEF4EBEB883E1C4F58772341EE060@PACDCEXMB01.cable.comcast.com>
 <517F4300.3070808@bitfreak.org>
 <CAL9jLaZAGjKqdawHmv-iM5FNLBRMPmj10TY9CGvo5XU0cT7xmw@mail.gmail.com>
Message-ID: <517F5A8D.4070007@bitfreak.org>

On 2013-04-29 21:26, Christopher Morrow wrote:
> we have always been at war with your cisco-ians...

No worries, the good folks at Hurricane Electric helped me dig a tunnel 
to freedom long ago. :)



From mysidia at gmail.com  Tue Apr 30 05:46:36 2013
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 30 Apr 2013 00:46:36 -0500
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net>
References: <CDA43587.1C1A5%Lee@asgard.org>
 <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net>
Message-ID: <CAAAwwbXDvktwQjoeRKq2BtMmX=iK8bjexqiOqNtHirksoyE41A@mail.gmail.com>

On 4/29/13, John Curran <jcurran at arin.net> wrote:
> On Apr 29, 2013, at 2:46 PM, Lee Howard <lee at asgard.org> wrote:
>> On 4/29/13 1:03 AM, "J?r?me Nicolle" <jerome at ceriz.fr> wrote:
> specified (based on being singly-homed or multi-homed.)  These same
> criteria now apply to receipt of an address block via transfer, so at
> regional IPv4 free pool depletion may be _very_ difficult to satisfy.

Huh?  Where did that concept come from?    There is no slow start
criterion in the transfer rule, and a transfer is by definition  not
an initial allocation or assignment activity, even if the ISP is new,
4.2 is not shown to apply;  there is a movement of an existing
allocation, assignment, or part of one;  between organizations,  a
movement of resources  due to merger or acquisition or  due to
specified transfer does not create an initial allocation;

And the transfer policy both 8.2 and 8.3  are very clear in that the
minimum size is /24,  and  not the standard minimums  for allocations
with  or without multihoming.

Would you expect ARIN to ask the ISP to receive their first /24 by
specified transfer,  to show how they will use a /20 in 3 months too?

Should there be any ambiguity,  the transfer applicant will certainly
demand the straightforward interpretation of the transfer rule,  that
does not require their first receipt of IPv4 resources to require slow
start or holding a /20,  prior to receiving their /24 through
specified transfer,  or their  initial /16   or whatever through  8.3
merger & acquisition.

Such restrictions would very obviously defeat the intent of 8.3; that
resources may be transferred.

But since conditions are listed on the recipiient of transfer, any
conditions not listed are clearly excluded...



--
-JH


From jcurran at arin.net  Tue Apr 30 10:29:21 2013
From: jcurran at arin.net (John Curran)
Date: Tue, 30 Apr 2013 10:29:21 +0000
Subject: "It's the end of the world as we know it" -- REM
In-Reply-To: <CAAAwwbXDvktwQjoeRKq2BtMmX=iK8bjexqiOqNtHirksoyE41A@mail.gmail.com>
References: <CDA43587.1C1A5%Lee@asgard.org>
 <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net>
 <CAAAwwbXDvktwQjoeRKq2BtMmX=iK8bjexqiOqNtHirksoyE41A@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net>

On Apr 30, 2013, at 1:46 AM, Jimmy Hess <mysidia at gmail.com> wrote:

> On 4/29/13, John Curran <jcurran at arin.net> wrote:
>> On Apr 29, 2013, at 2:46 PM, Lee Howard <lee at asgard.org> wrote:
>>> On 4/29/13 1:03 AM, "J?r?me Nicolle" <jerome at ceriz.fr> wrote:
>> specified (based on being singly-homed or multi-homed.)  These same
>> criteria now apply to receipt of an address block via transfer, so at
>> regional IPv4 free pool depletion may be _very_ difficult to satisfy.
> 
> Huh?  Where did that concept come from?  

Alas, NRPM 8.3 requires that "the recipient must demonstrate the need for up 
to a 24-month supply of IP address resources _under current ARIN policies_ ..."
which requires that transfer recipients be able demonstrate need per current 
IPv4 allocation or allocation policies.  If you could not qualify for any IPv4
assignment or allocation from ARIN, then you are not a valid recipient.  This
language (or very similar) has been in the 8.3 transfer policy since inception
in 2009 <https://www.arin.net/policy/proposals/2009_1.html> and effectively
links transfers to same needs-determination language as used for assignments
(only allowing for a much larger block to be transferred at 24-months than 
the ISP 3-month allocation size.)

FYI,
/John

John Curran
President and CEO
ARIN




From nick at foobar.org  Tue Apr 30 10:33:41 2013
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 30 Apr 2013 11:33:41 +0100
Subject: Office 365 broken on ipv6
Message-ID: <517F9E05.9050401@foobar.org>

https://outlook.office365.com does not work on ipv6; looks like this has
been broken for some while.

Can someone from Microsoft please fix?

> crumpet:/Users/nick% telnet -6 outlook.office365.com 443
> Trying 2a01:111:f400:1000::9...
> telnet: connect to address 2a01:111:f400:1000::9: Connection refused
> Trying 2a01:111:f400:8000::2...
> telnet: connect to address 2a01:111:f400:8000::2: Connection refused
> Trying 2a01:111:f400:9800::6...
> telnet: connect to address 2a01:111:f400:9800::6: Connection refused
> Trying 2a01:111:f400:9814::12...
> telnet: connect to address 2a01:111:f400:9814::12: Connection refused
> telnet: Unable to connect to remote host
> crumpet:/Users/nick% 

Nick


From ristic.sasa at gmail.com  Tue Apr 30 11:35:57 2013
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Tue, 30 Apr 2013 13:35:57 +0200
Subject: Office 365 broken on ipv6
In-Reply-To: <517F9E05.9050401@foobar.org>
References: <517F9E05.9050401@foobar.org>
Message-ID: <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>

from Europe, using ipv6, it seems to be working:
---
<Zarko.Kecic at rnids.rs>master:~$  telnet -6 outlook.office365.com 443
Trying 2a01:111:f400:800::6...
Connected to ipv6.exchangelabs.com.
Escape character is '^]'.
---




On Tue, Apr 30, 2013 at 12:33 PM, Nick Hilliard <nick at foobar.org> wrote:

> https://outlook.office365.com does not work on ipv6; looks like this has
> been broken for some while.
>
> Can someone from Microsoft please fix?
>
> > crumpet:/Users/nick% telnet -6 outlook.office365.com 443
> > Trying 2a01:111:f400:1000::9...
> > telnet: connect to address 2a01:111:f400:1000::9: Connection refused
> > Trying 2a01:111:f400:8000::2...
> > telnet: connect to address 2a01:111:f400:8000::2: Connection refused
> > Trying 2a01:111:f400:9800::6...
> > telnet: connect to address 2a01:111:f400:9800::6: Connection refused
> > Trying 2a01:111:f400:9814::12...
> > telnet: connect to address 2a01:111:f400:9814::12: Connection refused
> > telnet: Unable to connect to remote host
> > crumpet:/Users/nick%
>
> Nick
>
>


-- 
ricky

From aftab.siddiqui at gmail.com  Tue Apr 30 11:45:20 2013
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Tue, 30 Apr 2013 16:45:20 +0500
Subject: Office 365 broken on ipv6
In-Reply-To: <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
References: <517F9E05.9050401@foobar.org>
 <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
Message-ID: <CAK5YLgf-Y_8jCLZKSxH+E22WY92G=TpcaKexHMVZEsc__MHyyw@mail.gmail.com>

Quite Interesting...

from Europe, using ipv6, it seems to be working:
> ---
> <Zarko.Kecic at rnids.rs>master:~$  telnet -6 outlook.office365.com 443
> Trying 2a01:111:f400:800::6...
> Connected to ipv6.exchangelabs.com.
> Escape character is '^]'.
> ---
>

The IP address you have mentioned is working fine.

[root at stingray ~]# telnet 2a01:111:f400:800::6 443
Trying 2a01:111:f400:800::6...
Connected to 2a01:111:f400:800::6.
Escape character is '^]'.

but outlook.office365.com is not resolving to the above address google n he
dns.

Regards,
Aftab A. Siddiqui

From ristic.sasa at gmail.com  Tue Apr 30 11:58:23 2013
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Tue, 30 Apr 2013 13:58:23 +0200
Subject: Office 365 broken on ipv6
In-Reply-To: <CAK5YLgf-Y_8jCLZKSxH+E22WY92G=TpcaKexHMVZEsc__MHyyw@mail.gmail.com>
References: <517F9E05.9050401@foobar.org>
 <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
 <CAK5YLgf-Y_8jCLZKSxH+E22WY92G=TpcaKexHMVZEsc__MHyyw@mail.gmail.com>
Message-ID: <CAPVpXLwNzLm1bHCqCL4_pVAd2KmOdpzVY2k1vKqFZQ1ACvP1ww@mail.gmail.com>

yes, you are correct... resolved at my local dns:

master:~$ host outlook.office365.com
outlook.office365.com is an alias for
outlook.office365.com.glbdns.microsoft.com.
outlook.office365.com.glbdns.microsoft.com is an alias for
outlook-latam.office365.com.
outlook-latam.office365.com has IPv6 address 2a01:111:f400:2c00::6
outlook-latam.office365.com has IPv6 address 2a01:111:f400:800::6
outlook-latam.office365.com has IPv6 address 2a01:111:f400:c00::6
outlook-latam.office365.com has IPv6 address 2a01:111:f400:1800::6

2a01:111:f400:c00::6 and 2a01:111:f400:1800::6 are not responding to
queries on port 443, the other two (2a01:111:f400:2c00::6 and
2a01:111:f400:800::6) are working...


MS should fix this...




On Tue, Apr 30, 2013 at 1:45 PM, Aftab Siddiqui <aftab.siddiqui at gmail.com>wrote:

>
>
> Quite Interesting...
>
>  from Europe, using ipv6, it seems to be working:
>> ---
>> <Zarko.Kecic at rnids.rs>master:~$  telnet -6 outlook.office365.com 443
>>
>> Trying 2a01:111:f400:800::6...
>> Connected to ipv6.exchangelabs.com.
>> Escape character is '^]'.
>> ---
>>
>
> The IP address you have mentioned is working fine.
>
> [root at stingray ~]# telnet 2a01:111:f400:800::6 443
>
> Trying 2a01:111:f400:800::6...
> Connected to 2a01:111:f400:800::6.
>
> Escape character is '^]'.
>
> but outlook.office365.com is not resolving to the above address google n
> he dns.
>
> Regards,
> Aftab A. Siddiqui
>



-- 
ricky

From jared at puck.nether.net  Tue Apr 30 12:05:23 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 30 Apr 2013 08:05:23 -0400
Subject: Office 365 broken on ipv6
In-Reply-To: <CAPVpXLwNzLm1bHCqCL4_pVAd2KmOdpzVY2k1vKqFZQ1ACvP1ww@mail.gmail.com>
References: <517F9E05.9050401@foobar.org>
 <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
 <CAK5YLgf-Y_8jCLZKSxH+E22WY92G=TpcaKexHMVZEsc__MHyyw@mail.gmail.com>
 <CAPVpXLwNzLm1bHCqCL4_pVAd2KmOdpzVY2k1vKqFZQ1ACvP1ww@mail.gmail.com>
Message-ID: <CD6E7096-4203-45FF-B4E4-6678964DA583@puck.nether.net>

FYI: Here's what I'm seeing:

puck:~$ curl -v https://outlook.office365.com/
* About to connect() to outlook.office365.com port 443 (#0)
*   Trying 2a01:111:f400:400::2...
* Connection refused
*   Trying 2a01:111:f400:2c16::2...
* Connection refused
*   Trying 2a01:111:f400:2c2a::12...
* Connection refused
*   Trying 2a01:111:f400:83e::2...
* Connection refused
*   Trying 2a01:111:f400:c04::9...
* Connection refused
*   Trying 2a01:111:f400:16::6...
* Connection refused
*   Trying 157.56.239.18...
* connected
* Connected to outlook.office365.com (157.56.239.18) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_SHA
* Server certificate:
* 	subject: CN=outlook.com,OU=Exchange,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US
* 	start date: Sep 18 18:53:09 2012 GMT
* 	expire date: Sep 18 18:53:09 2014 GMT
* 	common name: outlook.com
* 	issuer: CN=MSIT Machine Auth CA 2,DC=redmond,DC=corp,DC=microsoft,DC=com
> GET / HTTP/1.1
> User-Agent: curl/7.27.0
> Host: outlook.office365.com
> Accept: */*


On Apr 30, 2013, at 7:58 AM, Sasa Ristic <ristic.sasa at gmail.com> wrote:

> yes, you are correct... resolved at my local dns:
> 
> master:~$ host outlook.office365.com
> outlook.office365.com is an alias for
> outlook.office365.com.glbdns.microsoft.com.
> outlook.office365.com.glbdns.microsoft.com is an alias for
> outlook-latam.office365.com.
> outlook-latam.office365.com has IPv6 address 2a01:111:f400:2c00::6
> outlook-latam.office365.com has IPv6 address 2a01:111:f400:800::6
> outlook-latam.office365.com has IPv6 address 2a01:111:f400:c00::6
> outlook-latam.office365.com has IPv6 address 2a01:111:f400:1800::6
> 
> 2a01:111:f400:c00::6 and 2a01:111:f400:1800::6 are not responding to
> queries on port 443, the other two (2a01:111:f400:2c00::6 and
> 2a01:111:f400:800::6) are working...
> 
> 
> MS should fix this...
> 
> 
> 
> 
> On Tue, Apr 30, 2013 at 1:45 PM, Aftab Siddiqui <aftab.siddiqui at gmail.com>wrote:
> 
>> 
>> 
>> Quite Interesting...
>> 
>> from Europe, using ipv6, it seems to be working:
>>> ---
>>> <Zarko.Kecic at rnids.rs>master:~$  telnet -6 outlook.office365.com 443
>>> 
>>> Trying 2a01:111:f400:800::6...
>>> Connected to ipv6.exchangelabs.com.
>>> Escape character is '^]'.
>>> ---
>>> 
>> 
>> The IP address you have mentioned is working fine.
>> 
>> [root at stingray ~]# telnet 2a01:111:f400:800::6 443
>> 
>> Trying 2a01:111:f400:800::6...
>> Connected to 2a01:111:f400:800::6.
>> 
>> Escape character is '^]'.
>> 
>> but outlook.office365.com is not resolving to the above address google n
>> he dns.
>> 
>> Regards,
>> Aftab A. Siddiqui
>> 
> 
> 
> 
> -- 
> ricky



From charlie at playlouder.com  Tue Apr 30 12:13:47 2013
From: charlie at playlouder.com (Charlie Allom)
Date: Tue, 30 Apr 2013 13:13:47 +0100
Subject: Office 365 broken on ipv6
In-Reply-To: <517F9E05.9050401@foobar.org>
References: <517F9E05.9050401@foobar.org>
Message-ID: <20130430121347.GF10147@spodder.com>


On Tue, Apr 30, 2013 at 11:33:41AM +0100, Nick Hilliard <nick at foobar.org> wrote:
> https://outlook.office365.com does not work on ipv6; looks like this has
> been broken for some while.

Not one host in the RING says it is up:
https://spodder.com/p/ByYYcAomOxawsZRPme74X9pG

via https://ring.nlnog.net/

  C.

--
 +442077294797 (Office)
 +442031379505 (DDI)
 http://mediasp.com/


From schmid at dfn.de  Tue Apr 30 14:31:57 2013
From: schmid at dfn.de (Thomas Schmid)
Date: Tue, 30 Apr 2013 16:31:57 +0200
Subject: Tier1 blackholing policy?
Message-ID: <517FD5DD.9020305@dfn.de>

Greetings,

I know Tier1s are blackholing traffic all the time :) (de-peering, 
congestion etc.)
but did it became a new role for Tier1s to go from transit provider to
transit blocker?

We received recently customer complaints stating they can't reach 
certain websites.
Investigation showed that the sites were not reachable via Tier1-T, but 
fine via
Tier1-L. I contacted Tier1-T and the answer was something like "yeah, 
this is a known phishing
site and to protect our customers we blackhole that IP" (btw - it was 2 
ASes away from Tier1-T).

Huh? If I want to block something there, it should me my decision or 
that of my country's legal
entities by court order and not being decided by some Tier1's 
intransparent security department.
(Not even mentioning  words like 'CGN', 'legal', 'net neutrality' or 
'censorship') This might be
an acceptable policy for a cable provider but not for a Tier1.

Haven't seen something like this in many years. Did I miss a 
pardigm-shift here and has this
become a common "service" at Tier1s?

    Thomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130430/b7412865/attachment.bin>

From nanog at jima.us  Tue Apr 30 14:40:19 2013
From: nanog at jima.us (Jima)
Date: Tue, 30 Apr 2013 14:40:19 -0000 (UTC)
Subject: Office 365 broken on ipv6
In-Reply-To: <517F9E05.9050401@foobar.org>
References: <517F9E05.9050401@foobar.org>
Message-ID: <58205.2001:470:4917:0:5054:ff:fead:107.1367332819.squirrel@laughton.us>

On Tue, April 30, 2013 10:33 am, Nick Hilliard wrote:
> https://outlook.office365.com does not work on ipv6; looks like this has
> been broken for some while.
>
> Can someone from Microsoft please fix?
>
>> crumpet:/Users/nick% telnet -6 outlook.office365.com 443
>> Trying 2a01:111:f400:1000::9...
>> telnet: connect to address 2a01:111:f400:1000::9: Connection refused
>> Trying 2a01:111:f400:8000::2...
>> telnet: connect to address 2a01:111:f400:8000::2: Connection refused
>> Trying 2a01:111:f400:9800::6...
>> telnet: connect to address 2a01:111:f400:9800::6: Connection refused
>> Trying 2a01:111:f400:9814::12...
>> telnet: connect to address 2a01:111:f400:9814::12: Connection refused
>> telnet: Unable to connect to remote host
>> crumpet:/Users/nick%

 I brought this up to a contact at Microsoft on 2013-04-03; the
appropriate team was notified, but I guess someone dropped the ball. 
Oops.

     Jima



From florian.hibler at kaiaglobal.com  Tue Apr 30 11:38:17 2013
From: florian.hibler at kaiaglobal.com (Hibler, Florian)
Date: Tue, 30 Apr 2013 13:38:17 +0200
Subject: Office 365 broken on ipv6
In-Reply-To: <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
References: <517F9E05.9050401@foobar.org>
 <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
Message-ID: <517FAD29.1070901@kaiaglobal.com>

Hi,
seems at least one box got fixed:

dyn-10-0-2-50:~ local_fhibler$ telnet -6 outlook.office365.com 443
Trying 2a01:111:f400:400::6...
telnet: connect to address 2a01:111:f400:400::6: Connection refused
Trying 2a01:111:f400:83e::6...
telnet: connect to address 2a01:111:f400:83e::6: Connection refused
Trying 2a01:111:f400:c04::2...
telnet: connect to address 2a01:111:f400:c04::2: Connection refused
Trying 2a01:111:f400:1014::2...
telnet: connect to address 2a01:111:f400:1014::2: Connection refused
Trying 2a01:111:f400:2c16::6...
Connected to outlook-namwest.office365.com.
Escape character is '^]'.

Best regards,
Florian

-- 
Florian Hibler
Chief Technical Officer
eMail: florian.hibler at kaiaglobal.com

Kaia Global Networks Limited
Internet: http://www.kaiaglobal.com
Company No. 08257877
Registered Office: High Wycombe, UK

Notice: This transmittal and/or attachments may be privileged or 
confidential. If you are not the intended recipient, you are hereby 
notified that you have received this transmittal in error; any review, 
dissemination, or copying is strictly prohibited. If you received this 
transmittal in error, please notify us immediately by reply and 
immediately delete this message and all its attachments. Thank you.


From Christopher.Palmer at microsoft.com  Tue Apr 30 14:51:30 2013
From: Christopher.Palmer at microsoft.com (Christopher Palmer)
Date: Tue, 30 Apr 2013 14:51:30 +0000
Subject: Office 365 broken on ipv6
In-Reply-To: <517FAD29.1070901@kaiaglobal.com>
References: <517F9E05.9050401@foobar.org>
 <CAPVpXLz1C-HBO7QSFZQ+8iSth7EimQzF05mHJWFi7YmccL5JfA@mail.gmail.com>
 <517FAD29.1070901@kaiaglobal.com>
Message-ID: <c5f9f27b2ecb41848753bedcb6ad86f3@BN1PR03MB171.namprd03.prod.outlook.com>

This is being esclated.

-----Original Message-----
From: Hibler, Florian [mailto:florian.hibler at kaiaglobal.com] 
Sent: Tuesday, April 30, 2013 4:38 AM
To: nanog at nanog.org
Subject: Re: Office 365 broken on ipv6

Hi,
seems at least one box got fixed:

dyn-10-0-2-50:~ local_fhibler$ telnet -6 outlook.office365.com 443 Trying 2a01:111:f400:400::6...
telnet: connect to address 2a01:111:f400:400::6: Connection refused Trying 2a01:111:f400:83e::6...
telnet: connect to address 2a01:111:f400:83e::6: Connection refused Trying 2a01:111:f400:c04::2...
telnet: connect to address 2a01:111:f400:c04::2: Connection refused Trying 2a01:111:f400:1014::2...
telnet: connect to address 2a01:111:f400:1014::2: Connection refused Trying 2a01:111:f400:2c16::6...
Connected to outlook-namwest.office365.com.
Escape character is '^]'.

Best regards,
Florian

--
Florian Hibler
Chief Technical Officer
eMail: florian.hibler at kaiaglobal.com

Kaia Global Networks Limited
Internet: http://www.kaiaglobal.com
Company No. 08257877
Registered Office: High Wycombe, UK

Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.




From ml at kenweb.org  Tue Apr 30 14:59:24 2013
From: ml at kenweb.org (ML)
Date: Tue, 30 Apr 2013 10:59:24 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <517FD5DD.9020305@dfn.de>
References: <517FD5DD.9020305@dfn.de>
Message-ID: <517FDC4C.9060104@kenweb.org>

On 4/30/2013 10:31 AM, Thomas Schmid wrote:
> Greetings,
>
> I know Tier1s are blackholing traffic all the time :) (de-peering,
> congestion etc.)
> but did it became a new role for Tier1s to go from transit provider to
> transit blocker?
>
> We received recently customer complaints stating they can't reach
> certain websites.
> Investigation showed that the sites were not reachable via Tier1-T,
> but fine via
> Tier1-L. I contacted Tier1-T and the answer was something like "yeah,
> this is a known phishing
> site and to protect our customers we blackhole that IP" (btw - it was
> 2 ASes away from Tier1-T).
>
> Huh? If I want to block something there, it should me my decision or
> that of my country's legal
> entities by court order and not being decided by some Tier1's
> intransparent security department.
> (Not even mentioning  words like 'CGN', 'legal', 'net neutrality' or
> 'censorship') This might be
> an acceptable policy for a cable provider but not for a Tier1.
>
> Haven't seen something like this in many years. Did I miss a
> pardigm-shift here and has this
> become a common "service" at Tier1s?
>
>    Thomas


Ideally what should a Tier 1 or default-free network do in this
situation[1]?

1) Do nothing - They're supposed deliver any and all bits (Disregarding
a DoS or similiar situation which impedes said network)
2) Prefix filter - Don't be a party (at least in one direction) to the
bad actors traffic.
3) ?

[1] Assuming there is some sort of security and/or wrongdoing event that
isn't getting resolved via contact with their peer.


From cboyd at gizmopartners.com  Tue Apr 30 15:07:27 2013
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Tue, 30 Apr 2013 10:07:27 -0500
Subject: Tier1 blackholing policy?
In-Reply-To: <517FDC4C.9060104@kenweb.org>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
Message-ID: <1367334447.31455.5.camel@hounddog>

On Tue, 2013-04-30 at 10:59 -0400, ML wrote:
> 1) Do nothing - They're supposed deliver any and all bits
> (Disregarding
> a DoS or similiar situation which impedes said network)
> 2) Prefix filter - Don't be a party (at least in one direction) to the
> bad actors traffic. 

3 - Deliver all packets unless I've signed up for an enhanced security
offering?

--Chris



From jared at puck.nether.net  Tue Apr 30 15:11:32 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 30 Apr 2013 11:11:32 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <1367334447.31455.5.camel@hounddog>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
Message-ID: <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net>

Sounds like a no win situation. Either you let the bad guys do things or get complaints you blocked the bad guys. 

Jared Mauch

On Apr 30, 2013, at 11:07 AM, Chris Boyd <cboyd at gizmopartners.com> wrote:

> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:
>> 1) Do nothing - They're supposed deliver any and all bits
>> (Disregarding
>> a DoS or similiar situation which impedes said network)
>> 2) Prefix filter - Don't be a party (at least in one direction) to the
>> bad actors traffic.
> 
> 3 - Deliver all packets unless I've signed up for an enhanced security
> offering?
> 
> --Chris
> 


From patrick at ianai.net  Tue Apr 30 15:12:12 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 30 Apr 2013 11:12:12 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <1367334447.31455.5.camel@hounddog>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
Message-ID: <AC688DEF-0F59-44F7-8DEE-0D30D8E1EAC1@ianai.net>

On Apr 30, 2013, at 11:07 , Chris Boyd <cboyd at gizmopartners.com> wrote:
> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:

>> 1) Do nothing - They're supposed deliver any and all bits
>> (Disregarding
>> a DoS or similiar situation which impedes said network)
>> 2) Prefix filter - Don't be a party (at least in one direction) to the
>> bad actors traffic. 
> 
> 3 - Deliver all packets unless I've signed up for an enhanced security
> offering?

While I like that plan, there are a LOT more people who will scream about not being "protected" than those who will bitch they can't get to a phishing site.

Since networks are for-profit companies, they'll lower their costs (e.g. support calls), as long as it lowers their cost more than the "cost" of losing a customer or two (and let's be honest, that is about all they _might_ lose) who are religious about the whole "transit means everywhere" thing.

-- 
TTFN,
patrick



From jlewis at lewis.org  Tue Apr 30 15:16:22 2013
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 30 Apr 2013 11:16:22 -0400 (EDT)
Subject: Tier1 blackholing policy?
In-Reply-To: <517FD5DD.9020305@dfn.de>
References: <517FD5DD.9020305@dfn.de>
Message-ID: <Pine.LNX.4.61.1304301110000.26706@soloth.lewis.org>

On Tue, 30 Apr 2013, Thomas Schmid wrote:

> I know Tier1s are blackholing traffic all the time :) (de-peering, 
> congestion etc.) but did it became a new role for Tier1s to go from 
> transit provider to transit blocker?
>
> We received recently customer complaints stating they can't reach 
> certain websites. Investigation showed that the sites were not reachable 
> via Tier1-T, but fine via Tier1-L. I contacted Tier1-T and the answer 
> was something like "yeah, this is a known phishing site and to protect 
> our customers we blackhole that IP" (btw - it was 2 ASes away from 
> Tier1-T).
>
> Huh? If I want to block something there, it should me my decision or 
> that of my country's legal entities by court order and not being decided 
> by some Tier1's intransparent security department. (Not even mentioning 
> words like 'CGN', 'legal', 'net neutrality' or 'censorship') This might 
> be an acceptable policy for a cable provider but not for a Tier1.
>
> Haven't seen something like this in many years. Did I miss a 
> pardigm-shift here and has this become a common "service" at Tier1s?

I vaguely recall having the same sort of problem many years ago with 
Above.net transit.  IIRC, the sentiment back then was similarly that this 
was inappropriate behavior for a Tier1/2 transit provider.  If you're 
going to propagate the routes, deliver the traffic.  I suppose an argument 
could be made though that if there's phishing or malicious traffic 
targeting your customers from a single IP, it could be appropriate to 
blackhole the IP rather than reject the advertisement for an entire CIDR.

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


From rdobbins at arbor.net  Tue Apr 30 15:17:32 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 30 Apr 2013 15:17:32 +0000
Subject: Tier1 blackholing policy?
In-Reply-To: <1367334447.31455.5.camel@hounddog>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
Message-ID: <CF850F33-C2E8-418B-96C1-A70B38E7E0DC@arbor.net>


On Apr 30, 2013, at 10:07 PM, Chris Boyd wrote:

> 3 - Deliver all packets unless I've signed up for an enhanced security offering?

Even if said packets from an obviously compromised server on a high-speed link are attack packets causing problems for the ISP itself as well as for its customers?  

Trust me, large transit ISPs don't *want* to be in the blackholing business.  They only do so when they're forced into it by necessity (operational, legal, regulatory).

Also note that in the case of the server(s) you can't access, they may well be on shared hosting with thousands of sites/accounts on a single IP, one or more of which may be compromised.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From achatz at forthnetgroup.gr  Tue Apr 30 15:22:14 2013
From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou)
Date: Tue, 30 Apr 2013 18:22:14 +0300
Subject: Tier1 blackholing policy?
In-Reply-To: <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
 <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net>
Message-ID: <517FE1A6.3030609@forthnetgroup.gr>

I think blocking phishing sites vs blocking ddos require a different approach.


--
Tassos

Jared Mauch wrote on 30/04/2013 18:11:
> Sounds like a no win situation. Either you let the bad guys do things or get complaints you blocked the bad guys. 
>
> Jared Mauch
>
> On Apr 30, 2013, at 11:07 AM, Chris Boyd <cboyd at gizmopartners.com> wrote:
>
>> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:
>>> 1) Do nothing - They're supposed deliver any and all bits
>>> (Disregarding
>>> a DoS or similiar situation which impedes said network)
>>> 2) Prefix filter - Don't be a party (at least in one direction) to the
>>> bad actors traffic.
>> 3 - Deliver all packets unless I've signed up for an enhanced security
>> offering?
>>
>> --Chris
>>
>
>



From schmid at dfn.de  Tue Apr 30 15:23:50 2013
From: schmid at dfn.de (Thomas Schmid)
Date: Tue, 30 Apr 2013 17:23:50 +0200
Subject: Tier1 blackholing policy?
In-Reply-To: <1367334447.31455.5.camel@hounddog>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
Message-ID: <517FE206.5070306@dfn.de>

On 30.04.2013 17:07, Chris Boyd wrote:
> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:
>> 1) Do nothing - They're supposed deliver any and all bits
>> (Disregarding
>> a DoS or similiar situation which impedes said network)
>> 2) Prefix filter - Don't be a party (at least in one direction) to the
>> bad actors traffic.
>
> 3 - Deliver all packets unless I've signed up for an enhanced security
> offering?
>

right - I see this really as something that should be decided at the edge
of the internet (Tier2+) and not in the core.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130430/8a62a74f/attachment.bin>

From berni at birkenwald.de  Tue Apr 30 15:28:46 2013
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Tue, 30 Apr 2013 15:28:46 +0000 (UTC)
Subject: Office 365 broken on ipv6
References: <517F9E05.9050401@foobar.org>
Message-ID: <klonve$40t$1@ger.gmane.org>

Nick Hilliard <nick at foobar.org> wrote:

> https://outlook.office365.com does not work on ipv6; looks like this has
> been broken for some while.
>
> Can someone from Microsoft please fix?
>
>> crumpet:/Users/nick% telnet -6 outlook.office365.com 443
>> Trying 2a01:111:f400:1000::9...
>> telnet: connect to address 2a01:111:f400:1000::9: Connection refused
>> Trying 2a01:111:f400:8000::2...
>> telnet: connect to address 2a01:111:f400:8000::2: Connection refused
>> Trying 2a01:111:f400:9800::6...
>> telnet: connect to address 2a01:111:f400:9800::6: Connection refused
>> Trying 2a01:111:f400:9814::12...
>> telnet: connect to address 2a01:111:f400:9814::12: Connection refused
>> telnet: Unable to connect to remote host
>> crumpet:/Users/nick% 

JFYI, it has been like that for weeks now. Sometimes one of the hosts
connects but mostly all IPv6 addresses don't work.

Bernhard



From patrick at ianai.net  Tue Apr 30 15:53:54 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 30 Apr 2013 11:53:54 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <517FE206.5070306@dfn.de>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de>
Message-ID: <556CAA7D-DBB6-4F28-A5C1-E20FED59AC48@ianai.net>

On Apr 30, 2013, at 11:23 , Thomas Schmid <schmid at dfn.de> wrote:
> On 30.04.2013 17:07, Chris Boyd wrote:
>> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:

>>> 1) Do nothing - They're supposed deliver any and all bits
>>> (Disregarding
>>> a DoS or similiar situation which impedes said network)
>>> 2) Prefix filter - Don't be a party (at least in one direction) to the
>>> bad actors traffic.
>> 
>> 3 - Deliver all packets unless I've signed up for an enhanced security
>> offering?
> 
> right - I see this really as something that should be decided at the edge
> of the internet (Tier2+) and not in the core.

"Core"? Seriously?

Which of these statements are true:

A) Is it impossible for an end user or business (i.e. non-ISP) to get a direct connection to a "Tier 1" (whatever the hell that means) provider.
B) Most traffic on the Internet traverses Tier 1s today.
C) A Tier 1 has a different profit motive than a Tier 2 (whatever the hell that means) providers.
D) All Tier 1 providers are larger than all Tier 2 providers.

We'll just skip over the E) all of the above.

-- 
TTFN,
patrick

P.S. Hint: If you answered A, B, C, or D, you aren't paying attention.



From joelja at bogus.com  Tue Apr 30 16:00:08 2013
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 30 Apr 2013 09:00:08 -0700
Subject: Tier1 blackholing policy?
In-Reply-To: <517FE206.5070306@dfn.de>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de>
Message-ID: <517FEA88.5030605@bogus.com>

On 4/30/13 8:23 AM, Thomas Schmid wrote:
> On 30.04.2013 17:07, Chris Boyd wrote:
>> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:
>>> 1) Do nothing - They're supposed deliver any and all bits
>>> (Disregarding
>>> a DoS or similiar situation which impedes said network)
>>> 2) Prefix filter - Don't be a party (at least in one direction) to the
>>> bad actors traffic.
>>
>> 3 - Deliver all packets unless I've signed up for an enhanced security
>> offering?
>>
>
> right - I see this really as something that should be decided at the edge
> of the internet (Tier2+) and not in the core.
You seem to have odd ideas about what it means to be a settlement free 
provider. Most of their customers are not smaller internet service 
providers.
>
>



From schmid at dfn.de  Tue Apr 30 16:32:15 2013
From: schmid at dfn.de (Thomas Schmid)
Date: Tue, 30 Apr 2013 18:32:15 +0200
Subject: Tier1 blackholing policy?
In-Reply-To: <556CAA7D-DBB6-4F28-A5C1-E20FED59AC48@ianai.net>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de>
 <556CAA7D-DBB6-4F28-A5C1-E20FED59AC48@ianai.net>
Message-ID: <517FF20F.90203@dfn.de>

Am 30.04.2013 17:53, schrieb Patrick W. Gilmore:
> "Core"? Seriously? Which of these statements are true: A) Is it 
> impossible for an end user or business (i.e. non-ISP) to get a direct 
> connection to a "Tier 1" (whatever the hell that means) provider. B) 
> Most traffic on the Internet traverses Tier 1s today. C) A Tier 1 has 
> a different profit motive than a Tier 2 (whatever the hell that means) 
> providers. D) All Tier 1 providers are larger than all Tier 2 
> providers. We'll just skip over the E) all of the above. 

agree - I oversimplified, but I think you got the idea ...

    Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130430/b50c430f/attachment.bin>

From patrick at ianai.net  Tue Apr 30 16:41:19 2013
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 30 Apr 2013 12:41:19 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <517FF20F.90203@dfn.de>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de>
 <556CAA7D-DBB6-4F28-A5C1-E20FED59AC48@ianai.net> <517FF20F.90203@dfn.de>
Message-ID: <90B6B348-5340-46D3-8D0D-2D0C3275DE85@ianai.net>



Composed on a virtual keyboard, please forgive typos. 

On Apr 30, 2013, at 12:32, Thomas Schmid <schmid at dfn.de> wrote:
> Am 30.04.2013 17:53, schrieb Patrick W. Gilmore:

>> "Core"? Seriously? Which of these statements are true: A) Is it impossible for an end user or business (i.e. non-ISP) to get a direct connection to a "Tier 1" (whatever the hell that means) provider. B) Most traffic on the Internet traverses Tier 1s today. C) A Tier 1 has a different profit motive than a Tier 2 (whatever the hell that means) providers. D) All Tier 1 providers are larger than all Tier 2 providers. We'll just skip over the E) all of the above.
> 
> agree - I oversimplified, but I think you got the idea ...

No, I did not get the point. 

I am not trolling. I just do not understand what you meant. Probably because there is no "core", so your statement did not make sense.

-- 
TTFN,
patrick



From djahandarie at gmail.com  Tue Apr 30 16:43:39 2013
From: djahandarie at gmail.com (Darius Jahandarie)
Date: Tue, 30 Apr 2013 12:43:39 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <517FE1A6.3030609@forthnetgroup.gr>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
 <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net>
 <517FE1A6.3030609@forthnetgroup.gr>
Message-ID: <CAFANWtW+vhf0GuiRBGzFWFT6uaPK19VmRq=kCNVairma2dvs9w@mail.gmail.com>

On Tue, Apr 30, 2013 at 11:22 AM, Tassos Chatzithomaoglou
<achatz at forthnetgroup.gr> wrote:
> I think blocking phishing sites vs blocking ddos require a different approach.

I think I agree with this, and I think it can help draw a useful line.

Large DDoS attacks can and do directly affect the service that the
"tier 1" is providing to its customers (namely, moving their bits), so
filtering such attacks seems like a reasonably agreeable thing by
really anyone I think.

Phishing on the other hand will not really stop bits from moving
(except perhaps through rather long chain of unlikely things that'd
have to happen).

The last-mile consumer ISPs don't just "move bits" for their customers
really, its more about providing "internet" (which is a different
concept to normal users) -- and this is where filtering phishing sites
and blocking port 25 and such makes much more sense, because these
users will have a highly degraded experience if they become a botnet
drone or some such thing.



Granted, as Patrick says, "tier 1" isn't really a thing, and they have
a mix of customers, but I think its safe to say that these "tier 1"
providers should apply different policies for different types of
customers, because they are providering different services (even if
the underlying technology is the same/similar).

--
Darius Jahandarie


From jared at puck.nether.net  Tue Apr 30 16:47:40 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 30 Apr 2013 12:47:40 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <CAFANWtW+vhf0GuiRBGzFWFT6uaPK19VmRq=kCNVairma2dvs9w@mail.gmail.com>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
 <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net>
 <517FE1A6.3030609@forthnetgroup.gr>
 <CAFANWtW+vhf0GuiRBGzFWFT6uaPK19VmRq=kCNVairma2dvs9w@mail.gmail.com>
Message-ID: <6C023FA3-1159-4516-B593-43957425FD37@puck.nether.net>


On Apr 30, 2013, at 12:43 PM, Darius Jahandarie <djahandarie at gmail.com> wrote:

> I think I agree with this, and I think it can help draw a useful line.
> 
> Large DDoS attacks can and do directly affect the service that the
> "tier 1" is providing to its customers (namely, moving their bits), so
> filtering such attacks seems like a reasonably agreeable thing by
> really anyone I think.
> 
> Phishing on the other hand will not really stop bits from moving
> (except perhaps through rather long chain of unlikely things that'd
> have to happen).
> 
> The last-mile consumer ISPs don't just "move bits" for their customers
> really, its more about providing "internet" (which is a different
> concept to normal users) -- and this is where filtering phishing sites
> and blocking port 25 and such makes much more sense, because these
> users will have a highly degraded experience if they become a botnet
> drone or some such thing.

If the phishing attack is against an enterprise that is also an ISP, surely you can imagine a case where they might block traffic to prevent folks from being phished.

i think it's great that someone is blocking folks from being infected with either malware or giving up their private details improperly.

Typically these sites are hacked anyways or something else.  I think that keeping the broadest set of people from being phished or compromised is a good thing(tm).  Typically a site is cleaned up in a few hours or day or two without trouble.  If your communication is that urgent, there are other methods like phone to communicate with the other party.  not ideal, but they do exist.

- jared

From schmid at dfn.de  Tue Apr 30 17:22:53 2013
From: schmid at dfn.de (Thomas Schmid)
Date: Tue, 30 Apr 2013 19:22:53 +0200
Subject: Tier1 blackholing policy?
In-Reply-To: <90B6B348-5340-46D3-8D0D-2D0C3275DE85@ianai.net>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de>
 <556CAA7D-DBB6-4F28-A5C1-E20FED59AC48@ianai.net> <517FF20F.90203@dfn.de>
 <90B6B348-5340-46D3-8D0D-2D0C3275DE85@ianai.net>
Message-ID: <517FFDED.8090005@dfn.de>

Am 30.04.2013 18:41, schrieb Patrick W. Gilmore:
>
> Composed on a virtual keyboard, please forgive typos.
>
> On Apr 30, 2013, at 12:32, Thomas Schmid <schmid at dfn.de> wrote:
>> Am 30.04.2013 17:53, schrieb Patrick W. Gilmore:
>>> "Core"? Seriously? Which of these statements are true: A) Is it impossible for an end user or business (i.e. non-ISP) to get a direct connection to a "Tier 1" (whatever the hell that means) provider. B) Most traffic on the Internet traverses Tier 1s today. C) A Tier 1 has a different profit motive than a Tier 2 (whatever the hell that means) providers. D) All Tier 1 providers are larger than all Tier 2 providers. We'll just skip over the E) all of the above.
>> agree - I oversimplified, but I think you got the idea ...
> No, I did not get the point.
>
> I am not trolling. I just do not understand what you meant. Probably because there is no "core", so your statement did not make sense.
>

Patrick, what I mean is that someone that I pay money for providing me 
access to
the guys I don't peer with,  decides for me what's good (according to 
his criteria) for
me and my customers or even my customer's customers etc. If one of my peers
blackholes his customers, it's his business and not mine and I don't care.

While I eventually could vote with my wallet if I don't like that 
policy, my question was more,
if that behavior is already that common at 'Tier1s' (definition omitted) 
that it would not make
a difference anyway.

    Thomas







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130430/c91c21c2/attachment-0001.bin>

From aaron at heyaaron.com  Tue Apr 30 20:28:14 2013
From: aaron at heyaaron.com (Aaron C. de Bruyn)
Date: Tue, 30 Apr 2013 13:28:14 -0700
Subject: Andros Island Connectivity?
Message-ID: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>

I just had a client drop an interesting requirement on me.

They are on Andros Island (Bahamas) for about a year.  I'm working on
getting an exact address from the adminisphere above me, but all I've been
told so far is they are 'near the naval base'.

They just called and said "We need internet access yesterday".

None of the people on-site are technical, and all their data is accessed
via RDP on a server in the United States.

Having never been there, I have no idea if it's like downtown San Francisco
where the internet grows on trees, or if it's like the Sahara desert which
might require dragging your own fiber in on camelback...

Does anyone have pointers on who to talk to or how I can get them internet
access?

-A

From mike.lyon at gmail.com  Tue Apr 30 20:33:22 2013
From: mike.lyon at gmail.com (Mike Lyon)
Date: Tue, 30 Apr 2013 13:33:22 -0700
Subject: Andros Island Connectivity?
In-Reply-To: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
Message-ID: <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>

Aaron,

Cross-posting this over to the WISPA list to see if there are any Wireless
ISPs over there that can help you.

-Mike



On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn <aaron at heyaaron.com>wrote:

> I just had a client drop an interesting requirement on me.
>
> They are on Andros Island (Bahamas) for about a year.  I'm working on
> getting an exact address from the adminisphere above me, but all I've been
> told so far is they are 'near the naval base'.
>
> They just called and said "We need internet access yesterday".
>
> None of the people on-site are technical, and all their data is accessed
> via RDP on a server in the United States.
>
> Having never been there, I have no idea if it's like downtown San Francisco
> where the internet grows on trees, or if it's like the Sahara desert which
> might require dragging your own fiber in on camelback...
>
> Does anyone have pointers on who to talk to or how I can get them internet
> access?
>
> -A
>



-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon

From tshaw at oitc.com  Tue Apr 30 20:47:57 2013
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 30 Apr 2013 16:47:57 -0400
Subject: Andros Island Connectivity?
In-Reply-To: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
Message-ID: <8DAE6568-23F4-4D8A-B32A-CAE44ACD33E8@oitc.com>

Aaron are they supporting the range? If so there are options.

On Apr 30, 2013, at 4:28 PM, Aaron C. de Bruyn wrote:

> I just had a client drop an interesting requirement on me.
> 
> They are on Andros Island (Bahamas) for about a year.  I'm working on
> getting an exact address from the adminisphere above me, but all I've been
> told so far is they are 'near the naval base'.
> 
> They just called and said "We need internet access yesterday".
> 
> None of the people on-site are technical, and all their data is accessed
> via RDP on a server in the United States.
> 
> Having never been there, I have no idea if it's like downtown San Francisco
> where the internet grows on trees, or if it's like the Sahara desert which
> might require dragging your own fiber in on camelback...
> 
> Does anyone have pointers on who to talk to or how I can get them internet
> access?
> 
> -A



From wbailey at satelliteintelligencegroup.com  Tue Apr 30 20:56:15 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 20:56:15 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>,
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
Message-ID: <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>

I suggested VSAT. Probably the quickest and cheapest.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Mike Lyon <mike.lyon at gmail.com>
Date: 04/30/2013 1:35 PM (GMT-08:00)
To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
Cc: NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


Aaron,

Cross-posting this over to the WISPA list to see if there are any Wireless
ISPs over there that can help you.

-Mike



On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn <aaron at heyaaron.com>wrote:

> I just had a client drop an interesting requirement on me.
>
> They are on Andros Island (Bahamas) for about a year.  I'm working on
> getting an exact address from the adminisphere above me, but all I've been
> told so far is they are 'near the naval base'.
>
> They just called and said "We need internet access yesterday".
>
> None of the people on-site are technical, and all their data is accessed
> via RDP on a server in the United States.
>
> Having never been there, I have no idea if it's like downtown San Francisco
> where the internet grows on trees, or if it's like the Sahara desert which
> might require dragging your own fiber in on camelback...
>
> Does anyone have pointers on who to talk to or how I can get them internet
> access?
>
> -A
>



--
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon


From bill at herrin.us  Tue Apr 30 21:05:13 2013
From: bill at herrin.us (William Herrin)
Date: Tue, 30 Apr 2013 17:05:13 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <517FD5DD.9020305@dfn.de>
References: <517FD5DD.9020305@dfn.de>
Message-ID: <CAP-guGW9aHEjsHPO5BixWW12-EwPnfCp0gF7rZToUs04UnmFRg@mail.gmail.com>

On Tue, Apr 30, 2013 at 10:31 AM, Thomas Schmid <schmid at dfn.de> wrote:
> We received recently customer complaints stating they can't reach certain
> websites.
> Investigation showed that the sites were not reachable via Tier1-T, but fine
> via
> Tier1-L. I contacted Tier1-T and the answer was something like "yeah, this
> is a known phishing
> site and to protect our customers we blackhole that IP" (btw - it was 2 ASes
> away from Tier1-T).

Hi Thomas,

On the one hand, companies providing Internet transit are not
generally compelled by law to pass packets for any other given company
on the Internet.

On the other hand, announcing via BGP that you will carry particular
packets and then intentionally dropping them on the floor could easily
be construed as tortious interference.

The middle ground... propagating a BGP announcement but blocking a
small piece within it... I think I'd want to cover my backside by
setting a BGP community on that route which advised my peers that a
portion of it is dead-routed within my network so that they may
discard or deprioritize it if they choose.

Regards,
Bill Herrin

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


From eyeronic.design at gmail.com  Tue Apr 30 21:19:39 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Tue, 30 Apr 2013 14:19:39 -0700
Subject: Andros Island Connectivity?
In-Reply-To: <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
Message-ID: <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>

It's the quickest but certainly not the cheapest.

On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> I suggested VSAT. Probably the quickest and cheapest.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Lyon <mike.lyon at gmail.com>
> Date: 04/30/2013 1:35 PM (GMT-08:00)
> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
> Cc: NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> Aaron,
>
> Cross-posting this over to the WISPA list to see if there are any Wireless
> ISPs over there that can help you.
>
> -Mike
>
>
>
> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn <aaron at heyaaron.com>wrote:
>
>> I just had a client drop an interesting requirement on me.
>>
>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>> getting an exact address from the adminisphere above me, but all I've been
>> told so far is they are 'near the naval base'.
>>
>> They just called and said "We need internet access yesterday".
>>
>> None of the people on-site are technical, and all their data is accessed
>> via RDP on a server in the United States.
>>
>> Having never been there, I have no idea if it's like downtown San Francisco
>> where the internet grows on trees, or if it's like the Sahara desert which
>> might require dragging your own fiber in on camelback...
>>
>> Does anyone have pointers on who to talk to or how I can get them internet
>> access?
>>
>> -A
>>
>
>
>
> --
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
>
> http://www.linkedin.com/in/mlyon
>



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


From jared at puck.nether.net  Tue Apr 30 21:20:04 2013
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 30 Apr 2013 17:20:04 -0400
Subject: Tier1 blackholing policy?
In-Reply-To: <20130430185009.GA3750@vacation.karoshi.com.>
References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org>
 <1367334447.31455.5.camel@hounddog>
 <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net>
 <517FE1A6.3030609@forthnetgroup.gr>
 <CAFANWtW+vhf0GuiRBGzFWFT6uaPK19VmRq=kCNVairma2dvs9w@mail.gmail.com>
 <6C023FA3-1159-4516-B593-43957425FD37@puck.nether.net>
 <20130430185009.GA3750@vacation.karoshi.com.>
Message-ID: <44D4918F-C7CF-44C8-9A85-46A15D0FBBE9@puck.nether.net>


On Apr 30, 2013, at 2:50 PM, bmanning at vacation.karoshi.com wrote:

> 	Phone?  You mean like Jitsi or Skype?
> 	Fax?   
> 
> 	I'd like to see some numbers to back your assertion of "Typical" restoration
>        times of days.

my vendors deliver software fixes for "BGP" doesn't work in weeks, so I think that the following timeline and process I'm going to outline exceeds their BGP problems.

0 hour - Issue Reported
0-24 hours - triage; send to customer/internal customer to mitigate/remediate
25-48 hours - Customer responds, host taken down if hacked, etc..
48-96 hours+ - If no response, IP null0'ed per AUP as network security risk
48-96 hours is also where the customer freaks out and quickly fixes their problem to come in compliance with AUP.

This is a natural process.  Null0 or ACLs don't stay up for days or weeks on end.  That doesn't mean this catches 100% of all cases, but many ISPs get a daily report of phishing sites and malware hosted on their network each morning.  You can get one too!

http://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwork

You can get a daily ATLAS report from Arbor as well: http://atlas.arbor.net/ (Although I can't get anyone to fix a problem with it, so anyone there can email me if you have the power to fix it).

There are other aggregators of data as well, such as SIE.  If you don't know the health of your network, take a look.  Many folks will email you these reports automatically, or provide you a direct feed (some in realtime, such as SIE).

- Jared

From wbailey at satelliteintelligencegroup.com  Tue Apr 30 21:20:17 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 21:20:17 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>,
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
Message-ID: <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>

Says.. Who?


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Mike Hale <eyeronic.design at gmail.com>
Date: 04/30/2013 2:19 PM (GMT-08:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


It's the quickest but certainly not the cheapest.

On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> I suggested VSAT. Probably the quickest and cheapest.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Lyon <mike.lyon at gmail.com>
> Date: 04/30/2013 1:35 PM (GMT-08:00)
> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
> Cc: NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> Aaron,
>
> Cross-posting this over to the WISPA list to see if there are any Wireless
> ISPs over there that can help you.
>
> -Mike
>
>
>
> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn <aaron at heyaaron.com>wrote:
>
>> I just had a client drop an interesting requirement on me.
>>
>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>> getting an exact address from the adminisphere above me, but all I've been
>> told so far is they are 'near the naval base'.
>>
>> They just called and said "We need internet access yesterday".
>>
>> None of the people on-site are technical, and all their data is accessed
>> via RDP on a server in the United States.
>>
>> Having never been there, I have no idea if it's like downtown San Francisco
>> where the internet grows on trees, or if it's like the Sahara desert which
>> might require dragging your own fiber in on camelback...
>>
>> Does anyone have pointers on who to talk to or how I can get them internet
>> access?
>>
>> -A
>>
>
>
>
> --
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
>
> http://www.linkedin.com/in/mlyon
>



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


From eyeronic.design at gmail.com  Tue Apr 30 21:22:09 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Tue, 30 Apr 2013 14:22:09 -0700
Subject: Andros Island Connectivity?
In-Reply-To: <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>
Message-ID: <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>

Yeah, how many thousands is it per meg of space segment?

On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> Says.. Who?
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Hale <eyeronic.design at gmail.com>
> Date: 04/30/2013 2:19 PM (GMT-08:00)
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> It's the quickest but certainly not the cheapest.
>
> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> I suggested VSAT. Probably the quickest and cheapest.
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>
>> -------- Original message --------
>> From: Mike Lyon <mike.lyon at gmail.com>
>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>> Cc: NANOG mailing list <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>>
>>
>> Aaron,
>>
>> Cross-posting this over to the WISPA list to see if there are any Wireless
>> ISPs over there that can help you.
>>
>> -Mike
>>
>>
>>
>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>> <aaron at heyaaron.com>wrote:
>>
>>> I just had a client drop an interesting requirement on me.
>>>
>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>> getting an exact address from the adminisphere above me, but all I've
>>> been
>>> told so far is they are 'near the naval base'.
>>>
>>> They just called and said "We need internet access yesterday".
>>>
>>> None of the people on-site are technical, and all their data is accessed
>>> via RDP on a server in the United States.
>>>
>>> Having never been there, I have no idea if it's like downtown San
>>> Francisco
>>> where the internet grows on trees, or if it's like the Sahara desert
>>> which
>>> might require dragging your own fiber in on camelback...
>>>
>>> Does anyone have pointers on who to talk to or how I can get them
>>> internet
>>> access?
>>>
>>> -A
>>>
>>
>>
>>
>> --
>> Mike Lyon
>> 408-621-4826
>> mike.lyon at gmail.com
>>
>> http://www.linkedin.com/in/mlyon
>>
>
>
>
> --
> 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 wbailey at satelliteintelligencegroup.com  Tue Apr 30 21:22:32 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 21:22:32 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>,
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
Message-ID: <eehemg0cgpsfbiofw65hhapa.1367356950041@email.android.com>

Not that I'll argue it isn't costly, but how else can you rail in up to 100mbps in an afternoon..? I would imagine this type of inquiry comes in after it has been established that there is little to no connectivity.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Mike Hale <eyeronic.design at gmail.com>
Date: 04/30/2013 2:19 PM (GMT-08:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


It's the quickest but certainly not the cheapest.

On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> I suggested VSAT. Probably the quickest and cheapest.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Lyon <mike.lyon at gmail.com>
> Date: 04/30/2013 1:35 PM (GMT-08:00)
> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
> Cc: NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> Aaron,
>
> Cross-posting this over to the WISPA list to see if there are any Wireless
> ISPs over there that can help you.
>
> -Mike
>
>
>
> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn <aaron at heyaaron.com>wrote:
>
>> I just had a client drop an interesting requirement on me.
>>
>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>> getting an exact address from the adminisphere above me, but all I've been
>> told so far is they are 'near the naval base'.
>>
>> They just called and said "We need internet access yesterday".
>>
>> None of the people on-site are technical, and all their data is accessed
>> via RDP on a server in the United States.
>>
>> Having never been there, I have no idea if it's like downtown San Francisco
>> where the internet grows on trees, or if it's like the Sahara desert which
>> might require dragging your own fiber in on camelback...
>>
>> Does anyone have pointers on who to talk to or how I can get them internet
>> access?
>>
>> -A
>>
>
>
>
> --
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
>
> http://www.linkedin.com/in/mlyon
>



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


From wbailey at satelliteintelligencegroup.com  Tue Apr 30 21:23:44 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 21:23:44 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>,
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
Message-ID: <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>

Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k a month a mhz for hard to get weird stuff. We oversub to make the economics work often.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Mike Hale <eyeronic.design at gmail.com>
Date: 04/30/2013 2:22 PM (GMT-08:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


Yeah, how many thousands is it per meg of space segment?

On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> Says.. Who?
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Hale <eyeronic.design at gmail.com>
> Date: 04/30/2013 2:19 PM (GMT-08:00)
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> It's the quickest but certainly not the cheapest.
>
> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> I suggested VSAT. Probably the quickest and cheapest.
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>
>> -------- Original message --------
>> From: Mike Lyon <mike.lyon at gmail.com>
>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>> Cc: NANOG mailing list <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>>
>>
>> Aaron,
>>
>> Cross-posting this over to the WISPA list to see if there are any Wireless
>> ISPs over there that can help you.
>>
>> -Mike
>>
>>
>>
>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>> <aaron at heyaaron.com>wrote:
>>
>>> I just had a client drop an interesting requirement on me.
>>>
>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>> getting an exact address from the adminisphere above me, but all I've
>>> been
>>> told so far is they are 'near the naval base'.
>>>
>>> They just called and said "We need internet access yesterday".
>>>
>>> None of the people on-site are technical, and all their data is accessed
>>> via RDP on a server in the United States.
>>>
>>> Having never been there, I have no idea if it's like downtown San
>>> Francisco
>>> where the internet grows on trees, or if it's like the Sahara desert
>>> which
>>> might require dragging your own fiber in on camelback...
>>>
>>> Does anyone have pointers on who to talk to or how I can get them
>>> internet
>>> access?
>>>
>>> -A
>>>
>>
>>
>>
>> --
>> Mike Lyon
>> 408-621-4826
>> mike.lyon at gmail.com
>>
>> http://www.linkedin.com/in/mlyon
>>
>
>
>
> --
> 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  Tue Apr 30 21:24:53 2013
From: eyeronic.design at gmail.com (Mike Hale)
Date: Tue, 30 Apr 2013 14:24:53 -0700
Subject: Andros Island Connectivity?
In-Reply-To: <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
 <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>
Message-ID: <CAN3um4wbC9tFU6sOX1q4ZMG4qwoOYS64ng7eVrSG4wrDDCsPAA@mail.gmail.com>

Bingo.  And you're absolutely right in that setting it up can be really fast.

But cheap?  Not for a quality connection.

On Tue, Apr 30, 2013 at 2:23 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k
> a month a mhz for hard to get weird stuff. We oversub to make the economics
> work often.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Hale <eyeronic.design at gmail.com>
> Date: 04/30/2013 2:22 PM (GMT-08:00)
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> Yeah, how many thousands is it per meg of space segment?
>
> On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> Says.. Who?
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>
>> -------- Original message --------
>> From: Mike Hale <eyeronic.design at gmail.com>
>> Date: 04/30/2013 2:19 PM (GMT-08:00)
>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list
>> <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>>
>>
>> It's the quickest but certainly not the cheapest.
>>
>> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
>> <wbailey at satelliteintelligencegroup.com> wrote:
>>> I suggested VSAT. Probably the quickest and cheapest.
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>
>>> -------- Original message --------
>>> From: Mike Lyon <mike.lyon at gmail.com>
>>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>>> Cc: NANOG mailing list <nanog at nanog.org>
>>> Subject: Re: Andros Island Connectivity?
>>>
>>>
>>> Aaron,
>>>
>>> Cross-posting this over to the WISPA list to see if there are any
>>> Wireless
>>> ISPs over there that can help you.
>>>
>>> -Mike
>>>
>>>
>>>
>>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>>> <aaron at heyaaron.com>wrote:
>>>
>>>> I just had a client drop an interesting requirement on me.
>>>>
>>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>>> getting an exact address from the adminisphere above me, but all I've
>>>> been
>>>> told so far is they are 'near the naval base'.
>>>>
>>>> They just called and said "We need internet access yesterday".
>>>>
>>>> None of the people on-site are technical, and all their data is accessed
>>>> via RDP on a server in the United States.
>>>>
>>>> Having never been there, I have no idea if it's like downtown San
>>>> Francisco
>>>> where the internet grows on trees, or if it's like the Sahara desert
>>>> which
>>>> might require dragging your own fiber in on camelback...
>>>>
>>>> Does anyone have pointers on who to talk to or how I can get them
>>>> internet
>>>> access?
>>>>
>>>> -A
>>>>
>>>
>>>
>>>
>>> --
>>> Mike Lyon
>>> 408-621-4826
>>> mike.lyon at gmail.com
>>>
>>> http://www.linkedin.com/in/mlyon
>>>
>>
>>
>>
>> --
>> 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 wbailey at satelliteintelligencegroup.com  Tue Apr 30 21:28:04 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 21:28:04 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <CAN3um4wbC9tFU6sOX1q4ZMG4qwoOYS64ng7eVrSG4wrDDCsPAA@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
 <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>,
 <CAN3um4wbC9tFU6sOX1q4ZMG4qwoOYS64ng7eVrSG4wrDDCsPAA@mail.gmail.com>
Message-ID: <36yda9wilm68yxpm8ajml4m4.1367357277753@email.android.com>

We can make it work usually. An Hd TV channel takes something like 3mhz now. Things have improved greatly in our industry. Not to say there isn't the occasional weird situation. But when you come in to a site and it's up within an hour you are usually elevated to rockstar status. It takes longer to demarc a loop at the niu than it does to point an antenna.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Mike Hale <eyeronic.design at gmail.com>
Date: 04/30/2013 2:25 PM (GMT-08:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


Bingo.  And you're absolutely right in that setting it up can be really fast.

But cheap?  Not for a quality connection.

On Tue, Apr 30, 2013 at 2:23 PM, Warren Bailey
<wbailey at satelliteintelligencegroup.com> wrote:
> Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k
> a month a mhz for hard to get weird stuff. We oversub to make the economics
> work often.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Hale <eyeronic.design at gmail.com>
> Date: 04/30/2013 2:22 PM (GMT-08:00)
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> Yeah, how many thousands is it per meg of space segment?
>
> On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> Says.. Who?
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>
>> -------- Original message --------
>> From: Mike Hale <eyeronic.design at gmail.com>
>> Date: 04/30/2013 2:19 PM (GMT-08:00)
>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list
>> <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>>
>>
>> It's the quickest but certainly not the cheapest.
>>
>> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
>> <wbailey at satelliteintelligencegroup.com> wrote:
>>> I suggested VSAT. Probably the quickest and cheapest.
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>
>>> -------- Original message --------
>>> From: Mike Lyon <mike.lyon at gmail.com>
>>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>>> Cc: NANOG mailing list <nanog at nanog.org>
>>> Subject: Re: Andros Island Connectivity?
>>>
>>>
>>> Aaron,
>>>
>>> Cross-posting this over to the WISPA list to see if there are any
>>> Wireless
>>> ISPs over there that can help you.
>>>
>>> -Mike
>>>
>>>
>>>
>>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>>> <aaron at heyaaron.com>wrote:
>>>
>>>> I just had a client drop an interesting requirement on me.
>>>>
>>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>>> getting an exact address from the adminisphere above me, but all I've
>>>> been
>>>> told so far is they are 'near the naval base'.
>>>>
>>>> They just called and said "We need internet access yesterday".
>>>>
>>>> None of the people on-site are technical, and all their data is accessed
>>>> via RDP on a server in the United States.
>>>>
>>>> Having never been there, I have no idea if it's like downtown San
>>>> Francisco
>>>> where the internet grows on trees, or if it's like the Sahara desert
>>>> which
>>>> might require dragging your own fiber in on camelback...
>>>>
>>>> Does anyone have pointers on who to talk to or how I can get them
>>>> internet
>>>> access?
>>>>
>>>> -A
>>>>
>>>
>>>
>>>
>>> --
>>> Mike Lyon
>>> 408-621-4826
>>> mike.lyon at gmail.com
>>>
>>> http://www.linkedin.com/in/mlyon
>>>
>>
>>
>>
>> --
>> 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 tshaw at oitc.com  Tue Apr 30 21:45:28 2013
From: tshaw at oitc.com (TR Shaw)
Date: Tue, 30 Apr 2013 17:45:28 -0400
Subject: Andros Island Connectivity?
In-Reply-To: <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>,
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
 <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>
Message-ID: <668807B5-9316-4FCE-B041-4698C398B41F@oitc.com>

Harris/CAPROCK, http://www.harriscaprock.com, provides VSAT worldwide to shipping, offshore platforms and remote islands.

Additionally, Andros has quite a bit of undersea fiber going to it.  The USAF Eastern Test Range and the Naval base there was the forcing function.  The range contractor, http://computersciencesraytheon.com, could probably give you a heads up or if I can help I can call some friends there.

Tom

On Apr 30, 2013, at 5:23 PM, Warren Bailey wrote:

> Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k a month a mhz for hard to get weird stuff. We oversub to make the economics work often.
> 
> 
> Sent from my T-Mobile 4G LTE Device
> 
> 
> 
> -------- Original message --------
> From: Mike Hale <eyeronic.design at gmail.com>
> Date: 04/30/2013 2:22 PM (GMT-08:00)
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
> 
> 
> Yeah, how many thousands is it per meg of space segment?
> 
> On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> Says.. Who?
>> 
>> 
>> Sent from my T-Mobile 4G LTE Device
>> 
>> 
>> 
>> -------- Original message --------
>> From: Mike Hale <eyeronic.design at gmail.com>
>> Date: 04/30/2013 2:19 PM (GMT-08:00)
>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>> 
>> 
>> It's the quickest but certainly not the cheapest.
>> 
>> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
>> <wbailey at satelliteintelligencegroup.com> wrote:
>>> I suggested VSAT. Probably the quickest and cheapest.
>>> 
>>> 
>>> Sent from my T-Mobile 4G LTE Device
>>> 
>>> 
>>> 
>>> -------- Original message --------
>>> From: Mike Lyon <mike.lyon at gmail.com>
>>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>>> Cc: NANOG mailing list <nanog at nanog.org>
>>> Subject: Re: Andros Island Connectivity?
>>> 
>>> 
>>> Aaron,
>>> 
>>> Cross-posting this over to the WISPA list to see if there are any Wireless
>>> ISPs over there that can help you.
>>> 
>>> -Mike
>>> 
>>> 
>>> 
>>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>>> <aaron at heyaaron.com>wrote:
>>> 
>>>> I just had a client drop an interesting requirement on me.
>>>> 
>>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>>> getting an exact address from the adminisphere above me, but all I've
>>>> been
>>>> told so far is they are 'near the naval base'.
>>>> 
>>>> They just called and said "We need internet access yesterday".
>>>> 
>>>> None of the people on-site are technical, and all their data is accessed
>>>> via RDP on a server in the United States.
>>>> 
>>>> Having never been there, I have no idea if it's like downtown San
>>>> Francisco
>>>> where the internet grows on trees, or if it's like the Sahara desert
>>>> which
>>>> might require dragging your own fiber in on camelback...
>>>> 
>>>> Does anyone have pointers on who to talk to or how I can get them
>>>> internet
>>>> access?
>>>> 
>>>> -A
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Mike Lyon
>>> 408-621-4826
>>> mike.lyon at gmail.com
>>> 
>>> http://www.linkedin.com/in/mlyon
>>> 
>> 
>> 
>> 
>> --
>> 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 wbailey at satelliteintelligencegroup.com  Tue Apr 30 22:03:38 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 22:03:38 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <668807B5-9316-4FCE-B041-4698C398B41F@oitc.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>,
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
 <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>,
 <668807B5-9316-4FCE-B041-4698C398B41F@oitc.com>
Message-ID: <24yxu4o3ellnr9mj742s9tjt.1367359413224@email.android.com>

Or you could just use my networks?


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: TR Shaw <tshaw at oitc.com>
Date: 04/30/2013 2:45 PM (GMT-08:00)
To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
Cc: Mike Hale <eyeronic.design at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


Harris/CAPROCK, http://www.harriscaprock.com, provides VSAT worldwide to shipping, offshore platforms and remote islands.

Additionally, Andros has quite a bit of undersea fiber going to it.  The USAF Eastern Test Range and the Naval base there was the forcing function.  The range contractor, http://computersciencesraytheon.com, could probably give you a heads up or if I can help I can call some friends there.

Tom

On Apr 30, 2013, at 5:23 PM, Warren Bailey wrote:

> Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k a month a mhz for hard to get weird stuff. We oversub to make the economics work often.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
> -------- Original message --------
> From: Mike Hale <eyeronic.design at gmail.com>
> Date: 04/30/2013 2:22 PM (GMT-08:00)
> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
> Subject: Re: Andros Island Connectivity?
>
>
> Yeah, how many thousands is it per meg of space segment?
>
> On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> Says.. Who?
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>
>> -------- Original message --------
>> From: Mike Hale <eyeronic.design at gmail.com>
>> Date: 04/30/2013 2:19 PM (GMT-08:00)
>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>>
>>
>> It's the quickest but certainly not the cheapest.
>>
>> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
>> <wbailey at satelliteintelligencegroup.com> wrote:
>>> I suggested VSAT. Probably the quickest and cheapest.
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>
>>> -------- Original message --------
>>> From: Mike Lyon <mike.lyon at gmail.com>
>>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>>> Cc: NANOG mailing list <nanog at nanog.org>
>>> Subject: Re: Andros Island Connectivity?
>>>
>>>
>>> Aaron,
>>>
>>> Cross-posting this over to the WISPA list to see if there are any Wireless
>>> ISPs over there that can help you.
>>>
>>> -Mike
>>>
>>>
>>>
>>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>>> <aaron at heyaaron.com>wrote:
>>>
>>>> I just had a client drop an interesting requirement on me.
>>>>
>>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>>> getting an exact address from the adminisphere above me, but all I've
>>>> been
>>>> told so far is they are 'near the naval base'.
>>>>
>>>> They just called and said "We need internet access yesterday".
>>>>
>>>> None of the people on-site are technical, and all their data is accessed
>>>> via RDP on a server in the United States.
>>>>
>>>> Having never been there, I have no idea if it's like downtown San
>>>> Francisco
>>>> where the internet grows on trees, or if it's like the Sahara desert
>>>> which
>>>> might require dragging your own fiber in on camelback...
>>>>
>>>> Does anyone have pointers on who to talk to or how I can get them
>>>> internet
>>>> access?
>>>>
>>>> -A
>>>>
>>>
>>>
>>>
>>> --
>>> Mike Lyon
>>> 408-621-4826
>>> mike.lyon at gmail.com
>>>
>>> http://www.linkedin.com/in/mlyon
>>>
>>
>>
>>
>> --
>> 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 ryan at deadfrog.net  Tue Apr 30 22:16:23 2013
From: ryan at deadfrog.net (Ryan Wilkins)
Date: Tue, 30 Apr 2013 18:16:23 -0400
Subject: Andros Island Connectivity?
In-Reply-To: <CAN3um4wbC9tFU6sOX1q4ZMG4qwoOYS64ng7eVrSG4wrDDCsPAA@mail.gmail.com>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
 <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>
 <CAN3um4wbC9tFU6sOX1q4ZMG4qwoOYS64ng7eVrSG4wrDDCsPAA@mail.gmail.com>
Message-ID: <75A936E0-CE6F-497A-B9C1-D182F6C69F34@deadfrog.net>

If you need more than a megabit, don't forget to factor in the link budget and the resulting power and hardware requirements to support larger bandwidths.  Then you're looking at something that is probably not available today on the island.  If the connection needs to be up 24/7, even in heavy rains, then you're looking at something in C-band which then requires a larger antenna.  You'll be hard pressed to do any real bandwidth at Ku-band with anything less than a 1.2m antenna.  C-band, you're looking at 3.7m or so minimum.

The Ku-band iDirect system I manage for the City of Chicago runs 3 Mbps up and 3 Mbps down at Ku-band.  There are 6 remotes on the system, 5 are vehicles.  The vehicle antennas are 1.2m but they require 25 Watt amplifiers to reliably close the link all the time.  Clear day is fine on much less power.  Heavy rains, forget it.  25 Watts isn't enough.

On Apr 30, 2013, at 5:24 PM, Mike Hale <eyeronic.design at gmail.com> wrote:

> Bingo.  And you're absolutely right in that setting it up can be really fast.
> 
> But cheap?  Not for a quality connection.
> 
> On Tue, Apr 30, 2013 at 2:23 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k
>> a month a mhz for hard to get weird stuff. We oversub to make the economics
>> work often.
>> 
>> 
>> Sent from my T-Mobile 4G LTE Device
>> 
>> 
>> 
>> -------- Original message --------
>> From: Mike Hale <eyeronic.design at gmail.com>
>> Date: 04/30/2013 2:22 PM (GMT-08:00)
>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>> 
>> 
>> Yeah, how many thousands is it per meg of space segment?
>> 
>> On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
>> <wbailey at satelliteintelligencegroup.com> wrote:
>>> Says.. Who?
>>> 
>>> 
>>> Sent from my T-Mobile 4G LTE Device
>>> 
>>> 
>>> 
>>> -------- Original message --------
>>> From: Mike Hale <eyeronic.design at gmail.com>
>>> Date: 04/30/2013 2:19 PM (GMT-08:00)
>>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list
>>> <nanog at nanog.org>
>>> Subject: Re: Andros Island Connectivity?
>>> 
>>> 
>>> It's the quickest but certainly not the cheapest.
>>> 
>>> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
>>> <wbailey at satelliteintelligencegroup.com> wrote:
>>>> I suggested VSAT. Probably the quickest and cheapest.
>>>> 
>>>> 
>>>> Sent from my T-Mobile 4G LTE Device
>>>> 
>>>> 
>>>> 
>>>> -------- Original message --------
>>>> From: Mike Lyon <mike.lyon at gmail.com>
>>>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>>>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>>>> Cc: NANOG mailing list <nanog at nanog.org>
>>>> Subject: Re: Andros Island Connectivity?
>>>> 
>>>> 
>>>> Aaron,
>>>> 
>>>> Cross-posting this over to the WISPA list to see if there are any
>>>> Wireless
>>>> ISPs over there that can help you.
>>>> 
>>>> -Mike
>>>> 
>>>> 
>>>> 
>>>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>>>> <aaron at heyaaron.com>wrote:
>>>> 
>>>>> I just had a client drop an interesting requirement on me.
>>>>> 
>>>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>>>> getting an exact address from the adminisphere above me, but all I've
>>>>> been
>>>>> told so far is they are 'near the naval base'.
>>>>> 
>>>>> They just called and said "We need internet access yesterday".
>>>>> 
>>>>> None of the people on-site are technical, and all their data is accessed
>>>>> via RDP on a server in the United States.
>>>>> 
>>>>> Having never been there, I have no idea if it's like downtown San
>>>>> Francisco
>>>>> where the internet grows on trees, or if it's like the Sahara desert
>>>>> which
>>>>> might require dragging your own fiber in on camelback...
>>>>> 
>>>>> Does anyone have pointers on who to talk to or how I can get them
>>>>> internet
>>>>> access?
>>>>> 
>>>>> -A
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Mike Lyon
>>>> 408-621-4826
>>>> mike.lyon at gmail.com
>>>> 
>>>> http://www.linkedin.com/in/mlyon
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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 wbailey at satelliteintelligencegroup.com  Tue Apr 30 23:27:33 2013
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 30 Apr 2013 23:27:33 +0000
Subject: Andros Island Connectivity?
In-Reply-To: <75A936E0-CE6F-497A-B9C1-D182F6C69F34@deadfrog.net>
References: <CAEE+rGpxMPxYUT7MgZqJ2HZ4txHFRQdikgHrBo5DQcN3tNJovw@mail.gmail.com>
 <CAFFgAjD63Ce5p3LpsQH8FDS=wZkKBe6AuUKfk85cXO3s_N+Lqg@mail.gmail.com>
 <cqddduf09ohbbt1kvdtshbpl.1367355370713@email.android.com>
 <CAN3um4wfqLtrYCWMJSchyJwtTHMfhvPFoTU9n6hJ=kw-UHJ5dw@mail.gmail.com>
 <6oe1o7h7a9pnhqjqkvww6co8.1367356811133@email.android.com>
 <CAN3um4wH-Yg3OA+MKrXo44wki5KSxGsXokwvZBbnCPmLpPTj0Q@mail.gmail.com>
 <vctbcg646k09k6f8u702vut2.1367357019671@email.android.com>
 <CAN3um4wbC9tFU6sOX1q4ZMG4qwoOYS64ng7eVrSG4wrDDCsPAA@mail.gmail.com>,
 <75A936E0-CE6F-497A-B9C1-D182F6C69F34@deadfrog.net>
Message-ID: <q9x83ja91es0bu0hkji022c1.1367364449024@email.android.com>

Now we are partying! Let me get on my computer so I can respond.


Sent from my T-Mobile 4G LTE Device



-------- Original message --------
From: Ryan Wilkins <ryan at deadfrog.net>
Date: 04/30/2013 3:16 PM (GMT-08:00)
To: Mike Hale <eyeronic.design at gmail.com>
Cc: Warren Bailey <wbailey at satelliteintelligencegroup.com>,"Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
Subject: Re: Andros Island Connectivity?


If you need more than a megabit, don't forget to factor in the link budget and the resulting power and hardware requirements to support larger bandwidths.  Then you're looking at something that is probably not available today on the island.  If the connection needs to be up 24/7, even in heavy rains, then you're looking at something in C-band which then requires a larger antenna.  You'll be hard pressed to do any real bandwidth at Ku-band with anything less than a 1.2m antenna.  C-band, you're looking at 3.7m or so minimum.

The Ku-band iDirect system I manage for the City of Chicago runs 3 Mbps up and 3 Mbps down at Ku-band.  There are 6 remotes on the system, 5 are vehicles.  The vehicle antennas are 1.2m but they require 25 Watt amplifiers to reliably close the link all the time.  Clear day is fine on much less power.  Heavy rains, forget it.  25 Watts isn't enough.

On Apr 30, 2013, at 5:24 PM, Mike Hale <eyeronic.design at gmail.com> wrote:

> Bingo.  And you're absolutely right in that setting it up can be really fast.
>
> But cheap?  Not for a quality connection.
>
> On Tue, Apr 30, 2013 at 2:23 PM, Warren Bailey
> <wbailey at satelliteintelligencegroup.com> wrote:
>> Depends.. Space segment runs from 1300 a mhz for inclined all the way to 6k
>> a month a mhz for hard to get weird stuff. We oversub to make the economics
>> work often.
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>
>> -------- Original message --------
>> From: Mike Hale <eyeronic.design at gmail.com>
>> Date: 04/30/2013 2:22 PM (GMT-08:00)
>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list <nanog at nanog.org>
>> Subject: Re: Andros Island Connectivity?
>>
>>
>> Yeah, how many thousands is it per meg of space segment?
>>
>> On Tue, Apr 30, 2013 at 2:20 PM, Warren Bailey
>> <wbailey at satelliteintelligencegroup.com> wrote:
>>> Says.. Who?
>>>
>>>
>>> Sent from my T-Mobile 4G LTE Device
>>>
>>>
>>>
>>> -------- Original message --------
>>> From: Mike Hale <eyeronic.design at gmail.com>
>>> Date: 04/30/2013 2:19 PM (GMT-08:00)
>>> To: Warren Bailey <wbailey at satelliteintelligencegroup.com>
>>> Cc: Mike Lyon <mike.lyon at gmail.com>,"Aaron C. de Bruyn"
>>> <aaron at heyaaron.com>,members at wispa.org,NANOG mailing list
>>> <nanog at nanog.org>
>>> Subject: Re: Andros Island Connectivity?
>>>
>>>
>>> It's the quickest but certainly not the cheapest.
>>>
>>> On Tue, Apr 30, 2013 at 1:56 PM, Warren Bailey
>>> <wbailey at satelliteintelligencegroup.com> wrote:
>>>> I suggested VSAT. Probably the quickest and cheapest.
>>>>
>>>>
>>>> Sent from my T-Mobile 4G LTE Device
>>>>
>>>>
>>>>
>>>> -------- Original message --------
>>>> From: Mike Lyon <mike.lyon at gmail.com>
>>>> Date: 04/30/2013 1:35 PM (GMT-08:00)
>>>> To: "Aaron C. de Bruyn" <aaron at heyaaron.com>,members at wispa.org
>>>> Cc: NANOG mailing list <nanog at nanog.org>
>>>> Subject: Re: Andros Island Connectivity?
>>>>
>>>>
>>>> Aaron,
>>>>
>>>> Cross-posting this over to the WISPA list to see if there are any
>>>> Wireless
>>>> ISPs over there that can help you.
>>>>
>>>> -Mike
>>>>
>>>>
>>>>
>>>> On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn
>>>> <aaron at heyaaron.com>wrote:
>>>>
>>>>> I just had a client drop an interesting requirement on me.
>>>>>
>>>>> They are on Andros Island (Bahamas) for about a year.  I'm working on
>>>>> getting an exact address from the adminisphere above me, but all I've
>>>>> been
>>>>> told so far is they are 'near the naval base'.
>>>>>
>>>>> They just called and said "We need internet access yesterday".
>>>>>
>>>>> None of the people on-site are technical, and all their data is accessed
>>>>> via RDP on a server in the United States.
>>>>>
>>>>> Having never been there, I have no idea if it's like downtown San
>>>>> Francisco
>>>>> where the internet grows on trees, or if it's like the Sahara desert
>>>>> which
>>>>> might require dragging your own fiber in on camelback...
>>>>>
>>>>> Does anyone have pointers on who to talk to or how I can get them
>>>>> internet
>>>>> access?
>>>>>
>>>>> -A
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mike Lyon
>>>> 408-621-4826
>>>> mike.lyon at gmail.com
>>>>
>>>> http://www.linkedin.com/in/mlyon
>>>>
>>>
>>>
>>>
>>> --
>>> 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 simon at darkmere.gen.nz  Tue Apr 30 23:40:17 2013
From: simon at darkmere.gen.nz (Simon Lyall)
Date: Wed, 1 May 2013 11:40:17 +1200 (NZST)
Subject: "Network Engineering" Stack Exchange site  in Area51 (fwd)
Message-ID: <alpine.DEB.2.00.1305011135260.24847@green.darkmere.gen.nz>


The proposal currently needs just 13 more committers with 200+ SE points on any site...

http://area51.stackexchange.com/proposals/52519/network-engineering

The SE site proposal for 'network engineering' is so close to going into Beta. It's up to
441 committers, and is currently 7th overall, (of 800+ proposals,) on the 
"hottest proposal list.

-- 
Simon Lyall  |  Very Busy  |  Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.



From tstpierre at iweb.com  Tue Apr 30 23:43:18 2013
From: tstpierre at iweb.com (Thomas St-Pierre)
Date: Tue, 30 Apr 2013 23:43:18 +0000
Subject: Mitigating DNS amplification attacks
Message-ID: <CDA5CF54.10D9A%tstpierre@iweb.com>

Hi!

I was wondering if anyone had any experience with dealing with open resolvers as a web hoster? We currently have some 40,000 ip's that respond to DNS in our AS, the majority of which are not "open" but do reply with a referral to the root zones. We've been sending emails to our clients but as the servers are not managed by us, there's not much we can do at that level.

Recently we've seen a large increase in the number and volume of DNS amplification DDOS's that are being reflected off of our AS. Just today we've seen at least 6 different attacks with between 4 and 10gbps leaving our AS each time. It's not really causing us issues at the moment because we have the capacity, but I'd hate to be on the receiving side. (and indeed, have been on the receiving side in the past, so I know how much it can suck)

Has anyone ever tried mitigating/rate-limiting/etc these attacks in the network before? (vs at the server/application level)

We have an Arbor peakflow device, but it's not really geared for this scenario I find. It will detect the outgoing attack via the flows, but all we can really do is null-route the victims ip in our AS. Ideally we would need a way to rate-limit DNS packets based on source ip. Maybe a linux box that handles dropping packets from the same source-ip over 1000/sec with some policy-based routing sending the DNS traffic to it? Does such a box exist already?

If anyone has any ideas or suggestions, then by all means! There must be a better way to do this, and I'd really like to avoid re-inventing the wheel if it's been invented already. :)

Thanks!
Thomas

From rdobbins at arbor.net  Tue Apr 30 23:57:38 2013
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 30 Apr 2013 23:57:38 +0000
Subject: Mitigating DNS amplification attacks
In-Reply-To: <CDA5CF54.10D9A%tstpierre@iweb.com>
References: <CDA5CF54.10D9A%tstpierre@iweb.com>
Message-ID: <579A1E1F-9DBA-4EC3-80FD-4CAAF2D1F533@arbor.net>


On May 1, 2013, at 6:43 AM, Thomas St-Pierre wrote:

>  We've been sending emails to our clients but as the servers are not managed by us, there's not much we can do at that level.

Sure, there is - shut them down if they don't comply.  Most ISPs have AUP verbiage which would apply to a situation of this type.

> Has anyone ever tried mitigating/rate-limiting/etc these attacks in the network before? (vs at the server/application level)

QoS doesn't work, as the programmatically-generated attack traffic 'crowds out' legitimate requests.

> We have an Arbor peakflow device, but it's not really geared for this scenario I find.

Peakflow SP is a NetFlow-based anomaly-detection system which performs attack detection/classification/traceback.  Please feel free to ping me offlist about additional system elements which perform attack mitigation.

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

	  Luck is the residue of opportunity and design.

		       -- John Milton



From cfp at ruxcon.org.au  Tue Apr 30 21:57:28 2013
From: cfp at ruxcon.org.au (cfp at ruxcon.org.au)
Date: Wed,  1 May 2013 07:57:28 +1000 (EST)
Subject: Breakpoint 2013 Call For Papers
Message-ID: <20130430215728.94C1B6CC2F@ruxcon.org.au>

Breakpoint 2013 Call For Papers
Melbourne, Australia, October 24th-25th
Intercontinental Rialto
http://www.ruxconbreakpoint.com


.[x]. Introduction .[x].

 The Ruxcon team is pleased to announce Call For Papers for Breakpoint 2013.

 Breakpoint showcases the work of expert security researchers from around the
 world on a wide range of topics. This conference is organised by the Ruxcon 
 team and offers a specialised security conference to complement and lead into 
 the larger and more casual Ruxcon weekend conference. Breakpoint caters 
 towards security researchers and industry professionals alike, with a focus on 
 cutting edge security research.

 Breakpoint presents a great opportunity for our selected speakers to receive a
 complimentary trip to Australia and experience both the Breakpoint and Ruxcon 
 conferences, not to mention the great weather, awesome parties, and friendly 
 people. Melbourne is a city of many subcultures, personalities and styles. 
 Melbourne has a vibrant arts and music scene, eccentric cafes, intimate bars 
 and restaurants, and is known as Australia's cultural capital.


.[x]. Important Dates .[x].

 May 1  - Call For Presentations Open
 August 23  - Call For Presentations Close
 October 22-23	- Breakpoint Training
 October 24-25	- Breakpoint Conference
 October 26-27	- Ruxcon Conference


.[x]. Topic Scope .[x].

Topics of interest include, but are not limited to:

 o Mobile Device Security
 o Exploitation Techniques
 o Reverse Engineering
 o Vulnerability Discovery
 o Rootkit Development
 o Malware Analysis
 o Code Analysis
 o Virtualisation, Hypervisor Security
 o Cloud Security
 o Embedded Device Security
 o Hardware Security
 o Telecommunications Security
 o Wireless Network Security
 o Web Application Security
 o Law Enforcement Activities
 o Forensics
 o Threat Intelligence
 o You get the idea


.[x]. Submission Guidelines .[x].

 In order for us to process your submission we will require the following 
 information:

 1. Presentation title
 2. Detailed summary of your presentation material
 3. Name/Nickname
 4. Mobile phone number
 5. Brief personal biography
 6. Description of any demonstrations involved in presentation
 7. Information on where the presentation material has or will be presented 
    before Breakpoint

 * Preference will be given to presentations that contain original research 
   that will be first presented at Breakpoint. 
 * As a general guideline, Breakpoint presentations are between 
   45 and 60 minutes, including question time. 

 If you have any questions about submissions, or would like to make a 
 submission, please send an email to bpx at ruxconbreakpoint.com


.[x]. Speaker Benefits .[x].

 Speakers at Breakpoint will be entitled to the following benefits:                                                

 - A return economy airfare to Melbourne (total cost limit applies)
 - Three nights accommodation at the Intercontinental Rialto
 - Complimentary registration for Breakpoint and Ruxcon conferences
 - Invitation to all Breakpoint and Ruxcon parties
 - Unlock 'Presented on world's smallest continent' achievement

 * All speaker benefits apply to a single speaker per submission. 


.[x]. Contact .[x]. 

 If you have any questions or inqueries, contact us at:

 * Email:	bpx at ruxconbreakpoint.com
 * Twitter:	@ruxconbpx