Re: Device specifically made for high capacity GRE tunnels for dozens of sites

[Julien Goodwin]

Another (somewhat cheaper) Juniper option if you meet its limits is the
EX[34]200's which now do GRE in hardware:

http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/gre-tunnel-services.html

On 19/01/13 05:36, PC wrote:
> mx80 (or similar) or ASR.  The MX would probably be my preference for just
> pushing huge amounts of GRE packets and scales nicely in a single box
> solution.
> 
> 
> On Fri, Jan 18, 2013 at 11:21 AM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
> 
>> On Fri, Jan 18, 2013 at 12:51 PM, A. Pishdadi  wrote:
>>> Hello,
>>>
>>> Can anyone recommend a device that will allow for multiple gigabit gre
>>> tunnels with ability to handle up to a million pps?
>>> I know it can be done on a bsd or nix box , or something running junos
>> but
>>> Im looking for something specifically made and tailored for GRE tunnels.
>>
>> dedicate an MPC on an MX box? 10gbps of gre, weee!
>>
>>

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Mike Jones]

On 19 January 2013 04:48, Doug Barton  wrote:
> No, because NAT-like solutions to perpetuate v4 only handle the client side
> of the transaction. At some point there will not be any more v4 address to
> assign/allocate to content provider networks. They have seen the writing on
> the wall, and many of the largest (both by traffic and market share) have
> already moved to providing their content over v6.

Potentially another source of IPv4 addresses - every content network
(/hosting provider/etc) that decides they don't want to give their
customers IPv6 reachability is a future bankrupt ISP with a load of
IPv4 to sell off :)

- Mike

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Doug Barton]

On 01/18/2013 02:07 PM, Jean-Francois Mezei wrote:

OSI and X.400 never gained much of a foothole and the millenium
generation probably never heard of them.


Is it possible that the same fate awaits IPv6 ? There is pressure to go
to IPv6, but if solutions are found for IPv4 which are simpler and more
easily deployed, won't that kill any/all efforts to move to IPv6 ?


No, because NAT-like solutions to perpetuate v4 only handle the client 
side of the transaction. At some point there will not be any more v4 
address to assign/allocate to content provider networks. They have seen 
the writing on the wall, and many of the largest (both by traffic and 
market share) have already moved to providing their content over v6.


Doug

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[David Swafford]

There is no "suckerage" to V6.   Really, it's not that hard.  While
CGN is the reality, we need to keep focused on the ultimate goal -- a
single long term solution.  Imagine a day where there is no dual
stack, no IPv4, and no more band-aids.   It will be amazing.

david.

On Fri, Jan 18, 2013 at 9:48 AM, Joe Maimon  wrote:
>
>
> Lee Howard wrote:
>
>> You are welcome to deploy it if you choose to.
>> Part of the reason I'm arguing against it is that if everyone deploys it,
>> then everyone has to deploy it.  If it is seen as an alternative to IPv6
>> by some, then others' deployment of IPv6 is made less useful: network
>> effect.  Also, spending money on CGN seems misguided; if you agree that
>> you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
>> also* for CGN?
>>
>>
>> Lee
>>
>
> Suppose a provider fully deploys v6, they will still need CGN so long as
> they have customers who want to access the v4 internet.
>
> Unfortunately, that may have the side effect of undercutting some portion of
> v6's value proposition, inversely related to its suckage.
>
> Joe
>

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Cameron Byrne]

Constantine,

On Fri, Jan 18, 2013 at 6:56 PM, Constantine A. Murenin
 wrote:
> On 16 January 2013 08:12, fredrik danerklint  wrote:
>> From the article:
>>
>> "Faced with the shortage of IPv4 addresses and the failure of IPv6 to take
>> off, British ISP PlusNet is testing carrier-grade network address
>> translation CG-NAT, where potentially all the ISP's customers could be
>> sharing one IP address, through a gateway. The move is controversial as it
>> could make some Internet services fail, but PlusNet says it is inevitable,
>> and only a test at this stage."
>>
>> http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6
>>
>> I'm only here to bring you the news. So don't complain to me...
>
> It is obvious that implementing CGN requires a lot of extra resources
> and a lot of hardware/firmware support for both CPE and operator
> equipment (the latter from both technical and legal-compliance
> reasons, and both the former and the latter in order to implement some
> kind of UPnP-compatible support to still allow some kind of p2p apps
> to somehow function).
>
> And this is at a time when a lot of the world internet traffic has
> already moved to IPv6, and all major content providers that account
> for most of the traffic today already support native IPv6: Google,
> YouTube and FB.
>
> Wouldn't it be better instead of the untested, unscalable and dead-end
> IPv4 CGN to massively start implementing single-stacked IPv6 with
> NAT64 at the ISP and *464XLAT* within the CPE RG?  (With 464XLAT, you
> wouldn't even need a potentially troublesome DNS64.)  This way,
> instead of having to account for subscriber growth presenting
> scalability issues on your limited IPv4 resources and CGN-related
> concerns, you can instead account for the content growth of
> IPv6-enabled sites, and, basically, have to plan for just about no
> extra IPv4 scaling budget whatsoever, since with every X subscribers
> that still need IPv4, you'll have every XX old subscribers that will
> be moving closer to being IPv6-only.  And with every year, a single
> IPv4 address used for NAT64 will be perfectly able to scale up to
> serve more and more customers, since fewer and fewer people will need
> IPv4 connections.
>
>
> So:
>
> With CGN, we get to the same old chicken-and-egg story:  lack of IPv6
> deployment and content/app support, yet an even more imminent shortage
> of IPv4 addresses (and with every new customer you'll be so much more
> closer to it) and the scalability and legal issues.
>
> With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get
> all the benefits of CGN (namely, all non-p2p IPv4-only apps and
> services will still work perfectly fine), but only a couple of the
> drawbacks.  And it'll actually put the correct pressure for both
> content and application developers to immediately switch to IPv6, and
> avoid you, the operator, from having to be spending the extra
> resources and having extra headaches on the IPv4 address shortage.  It
> really makes no sense that any company would still want to invest a
> single dime into CGN when instead they could be investing in IPv6 with
> NAT64 and CPE RGs with 464XLAT.
>

Brilliant so far ...

> I honestly think that 464XLAT can potentially solve all the chicken
> and egg problems that the big players have been having.  Supposedly,
> that's how T-Mobile USA is planning to move their network forward.
> (I'm certainly looking towards the day when I could finally enable
> IPv6 on a Google Nexus on T-Mo.)
>

OK... i am wading into dangerous territory now:  Why are you waiting?

This page has the 464XLAT software and procedure for Nexus S, Galaxy
Nexus, as well as apk for any rooted Android that can handle IPv6 on
cellular http://dan.drown.org/android/clat/

Or for the more pure IPv6-only NAT64/DNS64 out-of-the-box experience
https://sites.google.com/site/tmoipv6/lg-mytouch

> On the other hand, it's really strange that 464XLAT is so brand bloody
> new when IPv6 itself, as well as even NAT64 and DNS64, have been there
> for ages.  The idea of 464XLAT is just so ingeniously straight and
> simple!  Somewhat similar to 6rd, I guess.
>

Well, i certainly fought it as long as i could.  I was really drinking
the Kool-Aid that apps that could not support IPv6 would be
de-selected since they were unfit for the internet.  I figured
evolution would win, but inertia was certainly making things too slow,
thus we needed a way to make IPv4-apps (cough cough Skype, Netflix
Android App, ...) work on IPv6.

> I think that instead of any kind of CGN, all residential (and mobile)
> broadband connections should be IPv6-only with NAT64 and 464XLAT.
> That'll basically solve all the actual problems with one stone: lack
> of IPv6 deployment from content publishers and IPv6 application
> support (from app developers with no IPv6), and the immediate shortage
> of the IPv4 addresses.
>
> Cheers,
> Constantine.
>

Rock on.  I have been on IPv6-only + NA

Re: Fwd: Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has died at 56

[Jeroen van Aart]

On 01/08/2013 08:36 AM, Rich Kulawiec wrote:

- Forwarded message from Lauren Weinstein  -


Date: Mon, 7 Jan 2013 10:35:59 -0800
From: Lauren Weinstein
To: nnsq...@nnsquad.org
Subject: [ NNSquad ] Mark Crispin - MRC - Inventor of IMAP and a friend for
decades, has died at 56

Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has
died at 56


Lauren was also kind enough to provide a link to a posting on Google+
which provides more information:

https://plus.google.com/114753028665775786510/posts/4YvWfnneTyN

Mark did an awful, awful lot for all of us and for huge numbers of
people who'll never know his name.


Thanks for that, only just read it now...

I fully agree and am saddened by his death. I enjoyed reading his 
insightful emails (and occasional email exchanges with him). He wasn't 
afraid of expressing a strong opinion, supported by valid arguments and 
facts.


I will miss that.

Jeroen

--
Earthquake Magnitude: 4.6
Date: Friday, January 18, 2013 14:05:53 UTC
Location: Unimak Island region, Alaska
Latitude: 53.9296; Longitude: -163.2348
Depth: 11.60 km

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Constantine A. Murenin]

On 16 January 2013 08:12, fredrik danerklint  wrote:
> From the article:
>
> "Faced with the shortage of IPv4 addresses and the failure of IPv6 to take
> off, British ISP PlusNet is testing carrier-grade network address
> translation CG-NAT, where potentially all the ISP's customers could be
> sharing one IP address, through a gateway. The move is controversial as it
> could make some Internet services fail, but PlusNet says it is inevitable,
> and only a test at this stage."
>
> http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6
>
> I'm only here to bring you the news. So don't complain to me...

It is obvious that implementing CGN requires a lot of extra resources
and a lot of hardware/firmware support for both CPE and operator
equipment (the latter from both technical and legal-compliance
reasons, and both the former and the latter in order to implement some
kind of UPnP-compatible support to still allow some kind of p2p apps
to somehow function).

And this is at a time when a lot of the world internet traffic has
already moved to IPv6, and all major content providers that account
for most of the traffic today already support native IPv6: Google,
YouTube and FB.

Wouldn't it be better instead of the untested, unscalable and dead-end
IPv4 CGN to massively start implementing single-stacked IPv6 with
NAT64 at the ISP and *464XLAT* within the CPE RG?  (With 464XLAT, you
wouldn't even need a potentially troublesome DNS64.)  This way,
instead of having to account for subscriber growth presenting
scalability issues on your limited IPv4 resources and CGN-related
concerns, you can instead account for the content growth of
IPv6-enabled sites, and, basically, have to plan for just about no
extra IPv4 scaling budget whatsoever, since with every X subscribers
that still need IPv4, you'll have every XX old subscribers that will
be moving closer to being IPv6-only.  And with every year, a single
IPv4 address used for NAT64 will be perfectly able to scale up to
serve more and more customers, since fewer and fewer people will need
IPv4 connections.


So:

With CGN, we get to the same old chicken-and-egg story:  lack of IPv6
deployment and content/app support, yet an even more imminent shortage
of IPv4 addresses (and with every new customer you'll be so much more
closer to it) and the scalability and legal issues.

With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get
all the benefits of CGN (namely, all non-p2p IPv4-only apps and
services will still work perfectly fine), but only a couple of the
drawbacks.  And it'll actually put the correct pressure for both
content and application developers to immediately switch to IPv6, and
avoid you, the operator, from having to be spending the extra
resources and having extra headaches on the IPv4 address shortage.  It
really makes no sense that any company would still want to invest a
single dime into CGN when instead they could be investing in IPv6 with
NAT64 and CPE RGs with 464XLAT.

I honestly think that 464XLAT can potentially solve all the chicken
and egg problems that the big players have been having.  Supposedly,
that's how T-Mobile USA is planning to move their network forward.
(I'm certainly looking towards the day when I could finally enable
IPv6 on a Google Nexus on T-Mo.)

On the other hand, it's really strange that 464XLAT is so brand bloody
new when IPv6 itself, as well as even NAT64 and DNS64, have been there
for ages.  The idea of 464XLAT is just so ingeniously straight and
simple!  Somewhat similar to 6rd, I guess.

I think that instead of any kind of CGN, all residential (and mobile)
broadband connections should be IPv6-only with NAT64 and 464XLAT.
That'll basically solve all the actual problems with one stone: lack
of IPv6 deployment from content publishers and IPv6 application
support (from app developers with no IPv6), and the immediate shortage
of the IPv4 addresses.

Cheers,
Constantine.

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Constantine A. Murenin]

On 18 January 2013 14:00, William Herrin  wrote:
> On Fri, Jan 18, 2013 at 4:46 PM, Jean-Francois Mezei
>  wrote:
>> Should NAT become prevalent and prevent innovation because of its
>> limitations, this means that innovation will happen only with IPv6 which
>> means the next "must have" viral applications will require IPv6 and this
>> may spur the move away from an IPv4 that has been crippled by NAT
>> everywhere.
>
> It won't happen and I'll tell you why not.
>
> Client to client communication block diagrams:
>
> Without NAT:
> Client->Router->Router->Router->Router->Router->Client
>
> With NAT:
> Client->Router->Router->Relay->Router->Router->Client
>
> At a high level, the two communication diagrams are virtually identical.
>
> Add killer app. By it's nature, a killer app is something folks will
> pay good money for. This means that 100% of killer apps have
> sufficient funding to install those specialty relays.
>
> Odds of a killer app where one router can't be replaced with a
> specialty relay while maintaining the intended function: not bloody
> likely.
>
> Regards,
> Bill Herrin

The killer app of the internet is called p2p.

Don't we already have a shortage of IPv4 addresses to start abandoning
p2p, and requiring every service to be server-based, wasting extra
precious IPv4 addresses?

Where's the logic behind this:  make it impossible for two computers
to community directly because we have a shortage of addresses, yet
introduce a third machine with, again, rather limited resources, to
waste another IPv4 address?  Wasting all kinds of extra resources and
adding extra latency?  That's not a killer app, that's the
inefficiency of capitalism.

C.

Re: Intermittent incorrect DNS resolution?

[Andrei Ivanov]

Jay Ashworth wrote:
>
>Microsoft broke the Internet just to make their internal networking
>work properly?
>
>I'm shocked; *shocked* I tell... yes, just put the money right over there;
>*shocked* I say.
>
>You can't imagine how much time that lost me in diagnoses when it first
>came out, until we finally located it somewhere on the Internet.


Yeah, SUNW did it even before MSFT. Ever heard about 'nscd'?!
It gets installed [but disabled by default] in any Linux distro derived
from Red Hat Linux as well. If activated, will keep resolved records
in an in-memory cache for an hour with all default settings.

-- 

andrei

Re: Intermittent incorrect DNS resolution?

[Vinny Abello]

On 1/18/2013 5:46 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Vinny Abello" 
> 
>> Just an FYI...
>>
>> Every version of Windows since Windows 2000 (sans Windows Me) has had
>> the DNS Client service which maintained this caching function. This
>> was by design due to the massive dependency on DNS resolution which
>> Active Directory has had since its creation. It greatly reduced the
>> amount of repetitive lookups required thereby speeding up AD based
>> functions and lessening the load on DNS servers. It still exists today
>> up through Windows 8. You can disable the service, but it will also
>> break DDNS updates unless your DHCP server registers hostnames on
>> behalf of your clients.
> 
> Microsoft broke the Internet just to make their internal networking
> work properly?
> 
> I'm shocked; *shocked* I tell... yes, just put the money right over there;
> *shocked* I say.
> 
> You can't imagine how much time that lost me in diagnoses when it first
> came out, until we finally located it somewhere on the Internet.

LOL... I don't know that they so much broke anything other than people's sanity 
and expectations. I can't say this with certainty, but I was always under the 
assumption that the DNS Client also respected TTL's of all RR's it cached. 
Maybe that was an incorrect assumption, but if that was correct then at most 
all they did was give everyone a caching stub resolver built into their OS. I 
don't feel this is much different than many *nix distributions installing BIND 
with a default recursive configuration and /etc/resolv.conf pointing to ::1 or 
127.0.0.1... other than the obvious differences that it's doing recursion and 
you can *ASK* BIND what it's doing in a myriad of ways. That's always been my 
biggest gripe with the DNS Client. Either way, I wonder what the load on 
various DNS infrastructure throughout the world would look like if this 
mechanism didn't exist. I take it most recursive servers would just be 
answering a lot more queries from cache and burning cycles.

For the record, Mac OS X also caches DNS queries. You can flush with the cache 
with "dscacheutil -flushcache" up through Snow Leopard, or using "killall -HUP 
mDNSResponder" via sudo or equivalent root rights on Lion and Mountain Lion.

-Vinny

Re: Intermittent incorrect DNS resolution?

[Jay Ashworth]

- Original Message -
> From: "Vinny Abello" 

> Just an FYI...
> 
> Every version of Windows since Windows 2000 (sans Windows Me) has had
> the DNS Client service which maintained this caching function. This
> was by design due to the massive dependency on DNS resolution which
> Active Directory has had since its creation. It greatly reduced the
> amount of repetitive lookups required thereby speeding up AD based
> functions and lessening the load on DNS servers. It still exists today
> up through Windows 8. You can disable the service, but it will also
> break DDNS updates unless your DHCP server registers hostnames on
> behalf of your clients.

Microsoft broke the Internet just to make their internal networking
work properly?

I'm shocked; *shocked* I tell... yes, just put the money right over there;
*shocked* I say.

You can't imagine how much time that lost me in diagnoses when it first
came out, until we finally located it somewhere on the Internet.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@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

Re: Intermittent incorrect DNS resolution?

[Vinny Abello]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/16/2013 7:16 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Erik Levinson" 
> 
>> I'm having an unusual DNS problem and would appreciate feedback.
>>
>> For the zones in question, primary DNS is provided by GoDaddy and
>> secondary DNS by DNS Made Easy. Over a week ago we made changes to
>> several A records (including wildcards on two different zones), all
>> already having a TTL no greater than one hour.
>>
>> The new IPs on those A records have taken many millions of requests
>> since the changes. Occasionally, a small amount of traffic appears at
>> the old IPs that those A records had. This is HTTP traffic. Packet
>> captures of this traffic show various Host headers.
> 
> I'm a touch surprised to find that no one has mentioned the facet of
> Windows OSs that requires "ipconfig /flushdns" in some such circumstances...
> 
> Not only may *browsers* be caching DNS lookups without regard to TTLs,
> the *OS* might be doing it to you too, in circumstances I was never quite
> able to get a handle on.
> 
> XP was known to do this, as late as SP3; I'm not sure about V or 7.

Just an FYI...

Every version of Windows since Windows 2000 (sans Windows Me) has had the DNS 
Client service which maintained this caching function. This was by design due 
to the massive dependency on DNS resolution which Active Directory has had 
since its creation. It greatly reduced the amount of repetitive lookups 
required thereby speeding up AD based functions and lessening the load on DNS 
servers. It still exists today up through Windows 8. You can disable the 
service, but it will also break DDNS updates unless your DHCP server registers 
hostnames on behalf of your clients.

- -Vinny

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlD5z5QACgkQUyX7ywEAl3q4BACgtzaKz1U2+kWn9ExJoQaNy7+s
+mIAoLUjActGoFIKNUqzDDpdx14p/X/x
=4qXs
-END PGP SIGNATURE-

Re: Intermittent incorrect DNS resolution?

[Vinny Abello]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/16/2013 7:16 PM, Jay Ashworth wrote:


Just an FYI...

Every version of Windows since Windows 2000 (sans Windows Me) has had the DNS 
Client service which maintained this caching function. This was by design due 
to the massive dependency on DNS resolution which Active Directory has had 
since its creation. It greatly reduced the amount of repetitive lookups 
required thereby speeding up AD based functions and lessening the load on DNS 
servers. It still exists today up through Windows 8. You can disable the 
service, but it will also break DDNS updates unless your DHCP server registers 
hostnames on behalf of your clients.

- -Vinny

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlD5z4wACgkQUyX7ywEAl3ojggCfb/ad2MZ9wp31M3g9zM89mHUo
ODcAnjbgTCNV4Qr2fX8thhsj5jXIOiCu
=xN4+
-END PGP SIGNATURE-

Re: For those who may use a projector in the NOC

[Michael Painter]

- Original Message - 
  From: Eric Adler 
  To: Michael Painter 
  Cc: nanog@nanog.org 
  Sent: Thursday, January 17, 2013 4:19 PM
  Subject: Re: For those who may use a projector in the NOC


  This appears to be an Epson / 3LCD marketing campaign.  

  snip

  - Eric Adler
  Broadcast Engineer

Hi Eric

In case you didn't see it at the avs forum:

"Obviously brightness is only one metric, but a useful one if there is any 
ambient light or if you're going after a large screen.

You might recognize my name.it's the one on the four page document highlighted 
above and available at www.colorlightoutput.com I'm a product manager for 3LCD.

I'm a little surprised by the comments suggesting we were trying to hide the 
identity of 3LCD behind the site. Clearly the site doesn't scream3LCD.it wasn't 
supposed to. The "Hero" of the site is Color Light Output. The purpose is to 
provide information about this new measurement methodology.not present the 
technical details of 3LCD. I thought the 'feedback' page fairly well spells out 
who was behind it. That said, I will take these comments and make adjustment so 
that's it's clearer who is supporting the site.

Regarding the projectors selected for testing in table 2 of the document. It is 
true that all of these projectors are single chip models with color wheels. Why 
is that? As Scott points out above, an RGB 3-path projector will always have 
equal parts of WLO and CLO. I know already how an NEC LCD projectors is going 
to perform. Only single chip projectors were tested in order to better 
understand how each Color Wheel design impacted CLO. I do admit that the list 
is heavily leaning towards the biz/ed side of the projection market.that's due 
to the makeup of sales volumes; only about 10% of projectors are sold into home 
theater.

I hope, regardless of the company on my business card, that you'll agree with 
me that providing the customer this additional data is a good thing. My aim 
here is to get all manufacturers to list CLO as a supported metric."

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Jean-Francois Mezei]

On 13-01-18 17:00, William Herrin wrote:

> Odds of a killer app where one router can't be replaced with a
> specialty relay while maintaining the intended function: not bloody
> likely.

Back in the late 1980s, large computer manufacturers such as Digital,
HP, IBM were pressured to adopt the future in networking: OSI as
transport and X.400 for emails.

These stacks were eventually developped and implemented.

However, the much simpler and more cost effective "Internet" ended up
winning and it didn't take that long for governments to remove the
requirements to be "OSI compliant" and accepted IPv4 and SMTP as the new
standard.

OSI and X.400 never gained much of a foothole and the millenium
generation probably never heard of them.


Is it possible that the same fate awaits IPv6 ? There is pressure to go
to IPv6, but if solutions are found for IPv4 which are simpler and more
easily deployed, won't that kill any/all efforts to move to IPv6 ?

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[William Herrin]

On Fri, Jan 18, 2013 at 4:46 PM, Jean-Francois Mezei
 wrote:
> Should NAT become prevalent and prevent innovation because of its
> limitations, this means that innovation will happen only with IPv6 which
> means the next "must have" viral applications will require IPv6 and this
> may spur the move away from an IPv4 that has been crippled by NAT
> everywhere.

It won't happen and I'll tell you why not.

Client to client communication block diagrams:

Without NAT:
Client->Router->Router->Router->Router->Router->Client

With NAT:
Client->Router->Router->Relay->Router->Router->Client

At a high level, the two communication diagrams are virtually identical.

Add killer app. By it's nature, a killer app is something folks will
pay good money for. This means that 100% of killer apps have
sufficient funding to install those specialty relays.

Odds of a killer app where one router can't be replaced with a
specialty relay while maintaining the intended function: not bloody
likely.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 10-Jan-13 -to- 17-Jan-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS982954752  3.5%  64.5 -- BSNL-NIB National Internet 
Backbone
 2 - AS840248237  3.1%  30.1 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS390941757  2.7%2783.8 -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
 4 - AS462335104  2.2%   11701.3 -- CHEVALIER-AS01 Chevalier 
(Internet) Limited autonomous system #1
 5 - AS755228799  1.8%  31.2 -- VIETEL-AS-AP Vietel Corporation
 6 - AS29256   27702  1.8% 839.5 -- INT-PDN-STE-AS Syrian 
Telecommunications Establishment
 7 - AS163724934  1.6% 194.8 -- DNIC-AS-01637 - Headquarters, 
USAISC
 8 - AS474822935  1.5%7645.0 -- RESOLINK-AS-AP Resources Link 
Network Limited
 9 - AS17974   13524  0.9%   6.6 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
10 - AS27594   13181  0.8%6590.5 -- UTSA - University of Texas at 
San Antonio
11 - AS269711146  0.7% 105.2 -- ERX-ERNET-AS Education and 
Research Network
12 - AS671310941  0.7%  22.5 -- IAM-AS
13 - AS28573   10646  0.7%   9.8 -- NET Servicos de Comunicao S.A.
14 - AS845210543  0.7%  21.4 -- TE-AS TE-AS
15 - AS10620   10298  0.7%   8.0 -- Telmex Colombia S.A.
16 - AS4847 9793  0.6%  13.0 -- CNIX-AP China Networks 
Inter-Exchange
17 - AS7029 9146  0.6%   4.4 -- WINDSTREAM - Windstream 
Communications Inc
18 - AS5800 8311  0.5%  32.8 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
19 - AS2708 7484  0.5%  99.8 -- Universidad de Guanajuato
20 - AS6629 7434  0.5%7434.0 -- NOAA-AS - NOAA


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS462335104  2.2%   11701.3 -- CHEVALIER-AS01 Chevalier 
(Internet) Limited autonomous system #1
 2 - AS474822935  1.5%7645.0 -- RESOLINK-AS-AP Resources Link 
Network Limited
 3 - AS6629 7434  0.5%7434.0 -- NOAA-AS - NOAA
 4 - AS2033 7245  0.5%7245.0 -- PANIX - Panix Network 
Information Center
 5 - AS27594   13181  0.8%6590.5 -- UTSA - University of Texas at 
San Antonio
 6 - AS579182875  0.2%2875.0 -- ACOD-AS ACOD CJSC
 7 - AS6174 5701  0.4%2850.5 -- SPRINTLINK8 - Sprint
 8 - AS390941757  2.7%2783.8 -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
 9 - AS194064090  0.3%2045.0 -- TWRS-MA - Towerstream I, Inc.
10 - AS172933896  0.2%1948.0 -- VTXC - VTX Communications
11 - AS146805031  0.3%1677.0 -- REALE-6 - Auction.com
12 - AS6197 1463  0.1%1463.0 -- BATI-ATL - BellSouth Network 
Solutions, Inc
13 - AS9950 4011  0.3%1337.0 -- PUBNETPLUS2-AS-KR DACOM
14 - AS1562 1005  0.1%1005.0 -- DNIC-ASBLK-01550-01601 - DoD 
Network Information Center
15 - AS47316 924  0.1% 924.0 -- ENGINE-NETWORKS-AS Engine 
Networks S.R.L.
16 - AS53700 845  0.1% 845.0 -- DRANGRID - DRAN Grid Networks, 
LLC
17 - AS29256   27702  1.8% 839.5 -- INT-PDN-STE-AS Syrian 
Telecommunications Establishment
18 - AS33976 759  0.1% 759.0 -- AFTONBLADET-SE aftonbladet.se
19 - AS32753 734  0.1% 734.0 -- GLOBEOP-FINANCIAL-SERVICES-NYC1 
- GlobeOp Financial Services
20 - AS2 714  0.1% 207.0 -- ORPL-AS-AP OrionVM Retail Pty 
Ltd


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 151.118.255.0/24  13855  0.8%   AS3909  -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
 2 - 151.118.254.0/24  13855  0.8%   AS3909  -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
 3 - 151.118.18.0/24   13801  0.8%   AS3909  -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
 4 - 202.77.0.0/24 11702  0.7%   AS4623  -- CHEVALIER-AS01 Chevalier 
(Internet) Limited autonomous system #1
 5 - 202.77.1.0/24 11701  0.7%   AS4623  -- CHEVALIER-AS01 Chevalier 
(Internet) Limited autonomous system #1
 6 - 202.77.2.0/24 11701  0.7%   AS4623  -- CHEVALIER-AS01 Chevalier 
(Internet) Limited autonomous system #1
 7 - 203.161.4.0/22 9932  0.6%   AS4748  -- RESOLINK-AS-AP Resources Link 
Network Limited
 8 - 203.84.0.0/18  9930  0.6%   AS4748  -- RESOLINK-AS-AP Resources Link 
Network Limited
 9 - 202.41.70.0/24 8445  0.5%   AS2697  -- ERX-ERNET-AS Education and 
Research Network
10 - 202.86.252.0/228290  0.5%   AS4748  -- RESOLINK-AS-AP Resources Link 
Network Limited
 AS9304  -- HUTCHISON-AS-AP Hutchison 
Global Communications
11 - 192.58.232.0/247434  0.4%   AS6629  -- NOAA-AS - NOAA
12 -

The Cidr Report

[cidr-report]

This report has been generated at Fri Jan 18 21:13:11 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  PrefixesCIDR Agg
11-01-13440154  253400
12-01-13440403  253197
13-01-13440389  253276
14-01-13440516  253616
15-01-13440137  253644
16-01-13439836  253072
17-01-13439489  253809
18-01-13441174  253980


AS Summary
 43157  Number of ASes in routing system
 17954  Number of ASes announcing only one prefix
  3104  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  115815136  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').

 --- 18Jan13 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 441433   253908   18752542.5%   All ASes

AS6389  3104  126 297895.9%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS28573 2267   79 218896.5%   NET Servicos de Comunicao S.A.
AS4766  2939  937 200268.1%   KIXS-AS-KR Korea Telecom
AS17974 2474  481 199380.6%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS22773 1960  228 173288.4%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS18566 2081  423 165879.7%   COVAD - Covad Communications
   Co.
AS10620 2290  673 161770.6%   Telmex Colombia S.A.
AS2118  1432   49 138396.6%   RELCOM-AS OOO "NPO Relcom"
AS7303  1670  400 127076.0%   Telecom Argentina S.A.
AS4323  1605  400 120575.1%   TWTC - tw telecom holdings,
   inc.
AS4755  1668  555 111366.7%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS7029  2286 1275 101144.2%   WINDSTREAM - Windstream
   Communications Inc
AS7552  1149  172  97785.0%   VIETEL-AS-AP Vietel
   Corporation
AS18101 1016  170  84683.3%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS8151  1540  719  82153.3%   Uninet S.A. de C.V.
AS1785  1947 1163  78440.3%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS4808  1125  352  77368.7%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS13977  844  118  72686.0%   CTELCO - FAIRPOINT
   COMMUNICATIONS, INC.
AS18881  741   26  71596.5%   Global Village Telecom
AS855718   52  66692.8%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS35908  906  258  64871.5%   VPLSNET - Krypt Technologies
AS17676  715   95  62086.7%   GIGAINFRA Softbank BB Corp.
AS3356  1105  498  60754.9%   LEVEL3 Level 3 Communications
AS22561 1048  445  60357.5%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS24560 1037  437  60057.9%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS3549  1038  439  59957.7%   GBLX Global Crossing Ltd.
AS19262 1001  405  59659.5%   VZGNI-TRANSIT - Verizon Online
   LLC
AS9808   609   38  57193.8%   CMNET-GD Guangdong Mobile
   Communication Co.Ltd.
AS36998  774  221  55371.4%   SDN-MOBITEL
AS22047  583   31  55294.7%   VTR BANDA ANCHA S.A.

Total  43672112653240774.2%   Top 30 total


Possible Bogus Routes

10.86.64.32/30   AS65530 -Pri

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[William Herrin]

On Fri, Jan 18, 2013 at 1:28 PM, Lee Howard  wrote:
> Years ago, I asked, "Why are we stuck with NAT?"  I still ask that.  I
> believe that the reason we're stuck with it is that so many of us believe
> we're stuck with it--we're resigned to failure, so we don't do anything
> about it.

Hi Lee,

We're stuck with NAT because -enterprise- network security folks
universally accept NAT's efficacy as a lynchpin component in their
system security architecture. They accept it because the reasoning in
support of the proposition makes sense and they consider the fact of
its efficacy to have been satisfactorily demonstrated in practice.

You can chase any other reasons for using NAT to the ends of the Earth
and you'll never achieve a network where NAT's use can be
discontinued.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Jean-Francois Mezei]

Should NAT become prevalent and prevent innovation because of its
limitations, this means that innovation will happen only with IPv6 which
means the next "must have" viral applications will require IPv6 and this
may spur the move away from an IPv4 that has been crippled by NAT
everywhere.

Re: Zero-Touch Deployment Remote Office solution?

[Warren Bailey]

I wrote to him privately.. But will post on the list too.. Meraki is pretty rad 
for doing just this.


>From my Android phone on T-Mobile. The first nationwide 4G network.



 Original message 
From: PC 
Date: 01/18/2013 11:34 AM (GMT-08:00)
To: Matthew Craig 
Cc: nanog@nanog.org
Subject: Re: Zero-Touch Deployment Remote Office solution?


I handle this a different way.  I'm not saying it's the easiest solution,
but its very scalable to many thousands of endpoints.

I take a small router and I set the "WAN" side to DHCP.  I use
client-intiated L2TP tunnels w/ ipsec protection to build a tunnel to the
head end.

The beauty of this is:
1) It works on any internet connection.  NAT and dynamic IPs are not a
problem.  Since it's all UDP encapsulated and client intiated, they just
need to supply internet access via DHCP.
2) It's stateful.  The username/password defined on the remote client
decides what IP block is routed to the client.  All configuration is done
from the head end based on the radius file.  Routed IP blocks.  Access
lists.  DNS settings.  You name it.  A report off the IP list data file
builds the radius file.  If PPP/IPCP and virtual-templating can do it, you
are good.
4) It supports all your standard routing protocols, and multicast, if
desired.
5) The only thing needing provisioning on the remote side is
username/password.  Configs are pre-seeded with a "special"
username/password that provides enough access for the head office to login,
change it to the final value, and reload.

Now, I know there's several more mainstream solutions than this, and while
this removes technical complexity from the branch office, it does add some
to the headquarters.

If you're looking for a more out of the box solution, Cisco has an EZ-VPN
solution, amongst others.


On Fri, Jan 18, 2013 at 10:41 AM, Matthew Craig  wrote:

> We have a bunch of small remote offices where we deploy cheap routers with
> VPN tunnels back to the central office.  This is a very static process with
> high overhead… we have to manage each remote router separately, and the
> offices do not have tech personnel that can handle local office issues.
>
> We're looking for a more centrally managed and automated "zero-touch"
> remote office solution, like the Cisco Virtual Office, where the local
> non-clueful people don't have to do much.
>
> http://www.cisco.com/en/US/netsol/ns855/index.html
>
>
>
> Does anyone have any experience / feeback for this Cisco Virtual Office
> solution or have recommendations for alternative solutions.
>
>
>
> - Matt
>
>

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Valdis . Kletnieks]

On Fri, 18 Jan 2013 09:03:31 -0500, William Herrin said:

> On the technical side, enterprises have been doing large-scale NAT for
> more than a decade now without any doomsday consequences. CGN is not
> different.

Corporate enterprises have been pushing GPO to the desktop for more
than a decade as well.  Feel free to try to push GPO to Joe Sixpack's PC,
let me know how that works out for you.


pgp81csYx_pei.pgp
Description: PGP signature

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Valdis . Kletnieks]

On Thu, 17 Jan 2013 18:21:28 -0500, William Herrin said:

> Then it's a firewall that mildly enhances protection by obstructing
> 90% of the port scanning attacks which happen against your computer.
> It's a free country so you're welcome to believe that the presence or
> absence of NAT has no impact on the probability of a given machine
> being compromised. Of course, you're also welcome to join the flat
> earth society. As for me, the causative relationship between the rise
> of the "DSL router" implementing negligible security except NAT and
> the fall of port scanning as a credible attack vector seems blatant
> enough.

Oddly enough, the drop in portscanning attacks maps even more closely
to the shipping of XP SP2, which turned on the onboard firewall by
default.  Remember that some of the really big worm hits were when
they managed to get loose inside corporate networks behind the NAT...

Also, a NAT doesn't stop a Java or Adobe exploit in the least, as anybody
with security clue will tell you



pgpvpOLTHF9Gk.pgp
Description: PGP signature

Re: Zero-Touch Deployment Remote Office solution?

[PC]

I handle this a different way.  I'm not saying it's the easiest solution,
but its very scalable to many thousands of endpoints.

I take a small router and I set the "WAN" side to DHCP.  I use
client-intiated L2TP tunnels w/ ipsec protection to build a tunnel to the
head end.

The beauty of this is:
1) It works on any internet connection.  NAT and dynamic IPs are not a
problem.  Since it's all UDP encapsulated and client intiated, they just
need to supply internet access via DHCP.
2) It's stateful.  The username/password defined on the remote client
decides what IP block is routed to the client.  All configuration is done
from the head end based on the radius file.  Routed IP blocks.  Access
lists.  DNS settings.  You name it.  A report off the IP list data file
builds the radius file.  If PPP/IPCP and virtual-templating can do it, you
are good.
4) It supports all your standard routing protocols, and multicast, if
desired.
5) The only thing needing provisioning on the remote side is
username/password.  Configs are pre-seeded with a "special"
username/password that provides enough access for the head office to login,
change it to the final value, and reload.

Now, I know there's several more mainstream solutions than this, and while
this removes technical complexity from the branch office, it does add some
to the headquarters.

If you're looking for a more out of the box solution, Cisco has an EZ-VPN
solution, amongst others.


On Fri, Jan 18, 2013 at 10:41 AM, Matthew Craig  wrote:

> We have a bunch of small remote offices where we deploy cheap routers with
> VPN tunnels back to the central office.  This is a very static process with
> high overhead… we have to manage each remote router separately, and the
> offices do not have tech personnel that can handle local office issues.
>
> We're looking for a more centrally managed and automated "zero-touch"
> remote office solution, like the Cisco Virtual Office, where the local
> non-clueful people don't have to do much.
>
> http://www.cisco.com/en/US/netsol/ns855/index.html
>
>
>
> Does anyone have any experience / feeback for this Cisco Virtual Office
> solution or have recommendations for alternative solutions.
>
>
>
> - Matt
>
>

Re: Device specifically made for high capacity GRE tunnels for dozens of sites

[PC]

mx80 (or similar) or ASR.  The MX would probably be my preference for just
pushing huge amounts of GRE packets and scales nicely in a single box
solution.


On Fri, Jan 18, 2013 at 11:21 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> On Fri, Jan 18, 2013 at 12:51 PM, A. Pishdadi  wrote:
> > Hello,
> >
> > Can anyone recommend a device that will allow for multiple gigabit gre
> > tunnels with ability to handle up to a million pps?
> > I know it can be done on a bsd or nix box , or something running junos
> but
> > Im looking for something specifically made and tailored for GRE tunnels.
>
> dedicate an MPC on an MX box? 10gbps of gre, weee!
>
>

Weekly Routing Table Report

[Routing Analysis Role Account]

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-st...@lists.apnic.net

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

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 19 Jan, 2013

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

Analysis Summary


BGP routing table entries examined:  438891
Prefixes after maximum aggregation:  181575
Deaggregation factor:  2.42
Unique aggregates announced to Internet: 216035
Total ASes present in the Internet Routing Table: 43066
Prefixes per ASN: 10.19
Origin-only ASes present in the Internet Routing Table:   34033
Origin ASes announcing only one prefix:   15897
Transit ASes present in the Internet Routing Table:5730
Transit-only ASes present in the Internet Routing Table:135
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  32
Max AS path prepend of ASN ( 28730)  25
Prefixes from unregistered ASNs in the Routing Table:   378
Unregistered ASNs in the Routing Table: 127
Number of 32-bit ASNs allocated by the RIRs:   3668
Number of 32-bit ASNs visible in the Routing Table:3303
Prefixes from 32-bit ASNs in the Routing Table:9072
Special use prefixes present in the Routing Table:   16
Prefixes being announced from unallocated address space:190
Number of addresses announced to Internet:   2628231852
Equivalent to 156 /8s, 167 /16s and 162 /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.1
Total number of prefixes smaller than registry allocations:  154509

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   105723
Total APNIC prefixes after maximum aggregation:   32993
APNIC Deaggregation factor:3.20
Prefixes being announced from the APNIC address blocks:  106736
Unique aggregates announced from the APNIC address blocks:43694
APNIC Region origin ASes present in the Internet Routing Table:4816
APNIC Prefixes per ASN:   22.16
APNIC Region origin ASes announcing only one prefix:   1244
APNIC Region transit ASes present in the Internet Routing Table:811
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 23
Number of APNIC region 32-bit ASNs visible in the Routing Table:411
Number of APNIC addresses announced to Internet:  717390240
Equivalent to 42 /8s, 194 /16s and 129 /24s
Percentage of available APNIC address space announced: 83.8

APNIC AS Blocks4608-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:155380
Total ARIN prefixes after maximum aggregation:78597
ARIN Deaggregation factor: 1.98
Prefixes being announced from the ARIN address blocks:   156021
Unique aggregates announced from the ARIN address blocks: 70747
ARIN Region origin ASes present in the Internet Routing Table:15392
ARIN Prefixes per ASN:10.14
ARIN Region origin ASes announcing only

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Lee Howard]

On 1/18/13 1:03 PM, "Joe Maimon"  wrote:

>
>
>Lee Howard wrote:
>
>> If an ISP is so close to running out of addresses that they need CGN,
>> let's say they have 1 year of addresses remaining.  Given how many ports
>> apps use, recommendations are running to 10:1 user:address (but I could
>> well imagine that increasing to 50:1).  That means that for every user
>>you
>> NAT, you get 1/10 of an address.
>> Example:  An 10,000-user ISP is growing at 10% annually.  They have
>>1,000
>> addresses left, so they implement CGN.  You say to assuming 90% of them
>> can be NATted, so next year, 100 get a unique IPv4 address, the other
>>900
>> share 90 addresses.  At 190 addresses per year, CGN bought you five
>>years.
>>
>> I think your 90% is high.  If it's 70%, you burn 370 per year.
>> That doesn't include the fact the increased support costs, or alienated
>> customer cancellations, or any of the stuff I talked about in TCO of
>>CGN.
>>
>> Lee
>
>2-5 years from a currently one year supply?
>Factor in the current base and growth for at least another decade is
>assured.
>If it works for the new subscribers, it will work for the existing ones.

It is difficult to change an existing customer's service.  Good luck.


>
>Does anybody doubt that successful CGN deployment easily translates into
>many years more of v4?

Yes, I doubt it.  Although if you define "successful" as "many more years
of IPv4" my doubts vanish solipsistically.


>We understand that there are hosts of theoretical and practical impacts.
>What we do not yet know is how the public and providers at large will
>react or adapt to these impacts.
>
>If just the right balance of CGN negativity and resulting v6 adoption is
>the result, then we will all muddle through more or less ok.
>
>Otherwise we will be seeing either frantic v6 migration everywhere or
>even slower pace then what we have now.

Fear, uncertainty, doubt.  Possible frantic migration.
These sound bad to me.

Lee



>
>Joe
>

Re: Device specifically made for high capacity GRE tunnels for dozens of sites

[Phil Bedard]

I don't think you are going to find something made just for terminating
GRE tunnels but the Cisco ASR1000 and the Juniper MX5-MX80 or SRX line can
do what you want. 


-Phil






On 1/18/13 12:51 PM, "A. Pishdadi"  wrote:

>Hello,
>
>Can anyone recommend a device that will allow for multiple gigabit gre
>tunnels with ability to handle up to a million pps?
>I know it can be done on a bsd or nix box , or something running junos but
>Im looking for something specifically made and tailored for GRE tunnels.
>
>Thanks,
>Ameen

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Lee Howard]

On 1/18/13 12:48 PM, "Joe Maimon"  wrote:

>
>
>Lee Howard wrote:
>
>> You are welcome to deploy it if you choose to.
>> Part of the reason I'm arguing against it is that if everyone deploys
>>it,
>> then everyone has to deploy it.  If it is seen as an alternative to IPv6
>> by some, then others' deployment of IPv6 is made less useful: network
>> effect.  Also, spending money on CGN seems misguided; if you agree that
>> you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
>> also* for CGN?
>>
>>
>> Lee
>>
>
>Suppose a provider fully deploys v6, they will still need CGN so long as
>they have customers who want to access the v4 internet.

Not necessarily.  Maybe they need CGN, but they need NAT64, not NAT44.  Or
IVI.
Or maybe they should just hold their noses and buy addresses for a year or
a few.
What they need a transition strategy; it doesn't necessarily have to be
CGN.

Years ago, I asked, "Why are we stuck with NAT?"  I still ask that.  I
believe that the reason we're stuck with it is that so many of us believe
we're stuck with it--we're resigned to failure, so we don't do anything
about it.
One of the largest problems we have with this transition is that no one
believes they have any influence on it:  "I'm stuck with IPv4 until every
single other host on the Internet is using IPv6, and maybe for a while
after that, depending on happy eyeballs."
There are many levers of influence, but the most important ones to use are
those that shift externalities.  The cost in transition, either in IPv6 or
in CGN (or both) will be incurred disproportionately by ISPs.  Content
providers who care most about quality experience (and usefulness of IP
address information) now support IPv6.  If you think creatively, you might
come up with several levers that could shift the expense from "it's up to
ISPs to translate" to "content and devices manufacturer businesses are at
risk if they don't support IPv6."

Then there's the question--how do you know when you're done?  Every single
host on the Internet is running IPv6?  All but 100?  A million? A billion?
Probably somewhere in between, but each operator has to decide.  Everyone
else has to decide when to support IPv6--and hope it's before operators
call the transition complete, because then it's too late, because
consumers will choose the competitor's product or service that works (on
IPv6).  If Wordpress doesn't work because there's no IPv6, but Blogspot
and Blogger do, maybe consumers just switch.

Lee

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Owen DeLong]

Sent from my iPad

On Jan 18, 2013, at 8:06 AM, William Herrin  wrote:

> On Fri, Jan 18, 2013 at 12:20 PM, Lee Howard  wrote:
>> On 1/17/13 6:21 PM, "William Herrin"  wrote:
>>> Then it's a firewall that mildly enhances protection by obstructing
>>> 90% of the port scanning attacks which happen against your computer.
>>> It's a free country so you're welcome to believe that the presence or
>>> absence of NAT has no impact on the probability of a given machine
>>> being compromised. Of course, you're also welcome to join the flat
>>> earth society. As for me, the causative relationship between the rise
>>> of the "DSL router" implementing negligible security except NAT and
>>> the fall of port scanning as a credible attack vector seems blatant
>>> enough.
>> 
>> CGNs are not identical to home NAT functionality.
> 
> Didn't say they were. What I said was that claiming NAT has no
> security impact was false on its face.
> 

Even I have never claimed that. I think everyone pretty well understands at 
this point just how injurious NAT is to actual security.
> CGNs are most certainly not full cone NATs. Full cone NATs guarantee
> that any traffic which arrives at the external address is mapped to
> the internal address at the same port, functionality which requires a
> 1:1 mapping between external addresses and active internal addresses.
> Were they full-cone, with a 1:1 IP address mapping, CGNs would be
> completely useless for the stated purpose of reducing consumption of
> global addresses.
> 
> I'm given to understand that they do try to restrict a given internal
> address to emitting packets on a particular range of ports on a
> particular external address but that's functionality on top of a
> restricted-port cone NAT, not a fundamentally different kind of NAT.
> 
Actually, as I understand it, it's a hybrid. It's full cone (sort of) in that 
any packet that arrives within the port range will be translated to the 
corresponding internal address. It's restricted cone in that it's a port range 
instead of all ports. I'm not sure how the interior device is constrained to 
emitting only within the port range unless they are customizing all of the CPE 
in order to support that.

>>> I assume that fewer than 1 in 10 eyeballs would find Internet service
>>> behind a NAT unsatisfactory. Eyeballs are the consumers of content,
>>> the modem, cable modem, residential DSL customers. Some few of them
>>> are running game servers, web servers, etc. but 9 in 10 are the email,
>>> vonage and netflix variety who are basically not impacted by NAT.
>> 
>> Netflix seems to have some funny interactions with some gateways and CGN.
>> [nat444-impacts]
> 
> Some NATs have serious bugs that aren't obvious until you try to stack them.
> 

Which in itself is a pretty strong argument against CGN.

>> What about p2p?
> 
> If it worked with CGNs there'd be a whole lot less than 1 in 10 folks
> needing to opt out.
> 

So you are assuming <10% of the internet currently uses any p2p technology? 
Interesting.

>> You're going with linear growth?  See nro.net/statistics.
> 
> I'm guessing sublinear given the major backpressure from having to
> purchase or transfer IP addresses from other uses instead of getting
> fresh ones from a registry but the evidence isn't in yet so I'll
> conservatively estimate it at linear.

I don't think that backpressure really works against having new subscribers or 
towards reducing churn in the market place where there is competition. As such, 
I don't see how that would apply.

>>> Is it more like 1 in 5 customers would cough up
>>> an extra $5 rather than use a NAT address? The nearest comparable
>>> would be your ratio of dynamic to static IP assignments. Does your
>>> data support that being higher than 1 in 10? I'd bet the broad data
>>> sets don't.
>> 
>> If an ISP is so close to running out of addresses that they need CGN,
>> let's say they have 1 year of addresses remaining.  Given how many ports
>> apps use, recommendations are running to 10:1 user:address (but I could
>> well imagine that increasing to 50:1).  That means that for every user you
>> NAT, you get 1/10 of an address.
> 
> So at 10:1 you get 9/10ths of an address back from each of the 9 in 10
> eyeballs who converts to NAT. At a more likely ratio of 30:1 you get
> 29/30ths back. I'd have to rerun my numbers but that shaves something
> on the order of 1 year off my 37 year estimate.

Actually, at 10:1, you get back 10/11ths, not 9/10ths.

However, if CGN's limitations pick up some bad press in the early days, that 
ratio may well convert to more like 1:10 where you get back 1/11th instead of 
10/11ths. This all remains to be seen. Remember, the public will go much more 
with the emotional reaction to the first press accounts than it will go with 
rational or well thought out technical argument.


Owen

Re: Device specifically made for high capacity GRE tunnels for dozens of sites

[Christopher Morrow]

On Fri, Jan 18, 2013 at 12:51 PM, A. Pishdadi  wrote:
> Hello,
>
> Can anyone recommend a device that will allow for multiple gigabit gre
> tunnels with ability to handle up to a million pps?
> I know it can be done on a bsd or nix box , or something running junos but
> Im looking for something specifically made and tailored for GRE tunnels.

dedicate an MPC on an MX box? 10gbps of gre, weee!

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[William Herrin]

On Fri, Jan 18, 2013 at 12:20 PM, Lee Howard  wrote:
> On 1/17/13 6:21 PM, "William Herrin"  wrote:
>>Then it's a firewall that mildly enhances protection by obstructing
>>90% of the port scanning attacks which happen against your computer.
>>It's a free country so you're welcome to believe that the presence or
>>absence of NAT has no impact on the probability of a given machine
>>being compromised. Of course, you're also welcome to join the flat
>>earth society. As for me, the causative relationship between the rise
>>of the "DSL router" implementing negligible security except NAT and
>>the fall of port scanning as a credible attack vector seems blatant
>>enough.
>
> CGNs are not identical to home NAT functionality.

Didn't say they were. What I said was that claiming NAT has no
security impact was false on its face.


>  Home NATs are
> frequently restricted cone NATs, which is why uPNP or manual
> port-forwarding are required.  CGNs for residential deployments are full
> cone NATs,

CGNs are most certainly not full cone NATs. Full cone NATs guarantee
that any traffic which arrives at the external address is mapped to
the internal address at the same port, functionality which requires a
1:1 mapping between external addresses and active internal addresses.
Were they full-cone, with a 1:1 IP address mapping, CGNs would be
completely useless for the stated purpose of reducing consumption of
global addresses.

I'm given to understand that they do try to restrict a given internal
address to emitting packets on a particular range of ports on a
particular external address but that's functionality on top of a
restricted-port cone NAT, not a fundamentally different kind of NAT.




>>I assume that fewer than 1 in 10 eyeballs would find Internet service
>>behind a NAT unsatisfactory. Eyeballs are the consumers of content,
>>the modem, cable modem, residential DSL customers. Some few of them
>>are running game servers, web servers, etc. but 9 in 10 are the email,
>>vonage and netflix variety who are basically not impacted by NAT.
>
> Netflix seems to have some funny interactions with some gateways and CGN.
> [nat444-impacts]

Some NATs have serious bugs that aren't obvious until you try to stack them.


> What about p2p?

If it worked with CGNs there'd be a whole lot less than 1 in 10 folks
needing to opt out.


> How'd you get 75%?

It's a SWAG, hence an assumption.


> You're going with linear growth?  See nro.net/statistics.

I'm guessing sublinear given the major backpressure from having to
purchase or transfer IP addresses from other uses instead of getting
fresh ones from a registry but the evidence isn't in yet so I'll
conservatively estimate it at linear.


>>Is it more like 1 in 5 customers would cough up
>>an extra $5 rather than use a NAT address? The nearest comparable
>>would be your ratio of dynamic to static IP assignments. Does your
>>data support that being higher than 1 in 10? I'd bet the broad data
>>sets don't.
>
> If an ISP is so close to running out of addresses that they need CGN,
> let's say they have 1 year of addresses remaining.  Given how many ports
> apps use, recommendations are running to 10:1 user:address (but I could
> well imagine that increasing to 50:1).  That means that for every user you
> NAT, you get 1/10 of an address.

So at 10:1 you get 9/10ths of an address back from each of the 9 in 10
eyeballs who converts to NAT. At a more likely ratio of 30:1 you get
29/30ths back. I'd have to rerun my numbers but that shaves something
on the order of 1 year off my 37 year estimate.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Joe Maimon]

Lee Howard wrote:


If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining.  Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1).  That means that for every user you
NAT, you get 1/10 of an address.
Example:  An 10,000-user ISP is growing at 10% annually.  They have 1,000
addresses left, so they implement CGN.  You say to assuming 90% of them
can be NATted, so next year, 100 get a unique IPv4 address, the other 900
share 90 addresses.  At 190 addresses per year, CGN bought you five years.

I think your 90% is high.  If it's 70%, you burn 370 per year.
That doesn't include the fact the increased support costs, or alienated
customer cancellations, or any of the stuff I talked about in TCO of CGN.

Lee


2-5 years from a currently one year supply?

Factor in the current base and growth for at least another decade is 
assured.


If it works for the new subscribers, it will work for the existing ones.

Does anybody doubt that successful CGN deployment easily translates into 
many years more of v4?


We understand that there are hosts of theoretical and practical impacts. 
What we do not yet know is how the public and providers at large will 
react or adapt to these impacts.


If just the right balance of CGN negativity and resulting v6 adoption is 
the result, then we will all muddle through more or less ok.


Otherwise we will be seeing either frantic v6 migration everywhere or 
even slower pace then what we have now.


Joe

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Owen DeLong]

Sent from my iPad

On Jan 18, 2013, at 7:48 AM, Joe Maimon  wrote:

> 
> 
> Lee Howard wrote:
> 
>> You are welcome to deploy it if you choose to.
>> Part of the reason I'm arguing against it is that if everyone deploys it,
>> then everyone has to deploy it.  If it is seen as an alternative to IPv6
>> by some, then others' deployment of IPv6 is made less useful: network
>> effect.  Also, spending money on CGN seems misguided; if you agree that
>> you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
>> also* for CGN?
>> 
>> 
>> Lee
> 
> Suppose a provider fully deploys v6, they will still need CGN so long as they 
> have customers who want to access the v4 internet.
> 

Actually, NAT64/DNS64 is a much better alternative in that situation. The 
bigger issue is customers who still have v4-only devices and some reasonable 
expectation that those will
continue to be supported.

> Unfortunately, that may have the side effect of undercutting some portion of 
> v6's value proposition, inversely related to its suckage.

Which is why I consider the consumer electronics industry to be the important 
frontier in getting IPv6 support at this point. All of these smart TVs, DVD 
players, receivers, etc. that don't support IPv6 are going to be the real 
problem in deploying non-IPv4 service to residential customers in the coming 
years.

Owen

Re: Device specifically made for high capacity GRE tunnels for dozens of sites

[Faisal Imtiaz]

The new Cloud Core routers from Mikrotik might be able to handle this...
Granted they are new, and the ROS (6.0) is not fully baked,
But based on the Specs, these may have enough  CPU & Ram oumph to handle 
what you are asking for.


YMMV.

Regards.

Faisal Imtiaz
Snappy Internet & Telecom

On 1/18/2013 12:51 PM, A. Pishdadi wrote:

Hello,

Can anyone recommend a device that will allow for multiple gigabit gre
tunnels with ability to handle up to a million pps?
I know it can be done on a bsd or nix box , or something running junos but
Im looking for something specifically made and tailored for GRE tunnels.

Thanks,
Ameen

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Owen DeLong]

Sent from my iPad

On Jan 18, 2013, at 5:57 AM, Joe Maimon  wrote:

> 
> 
> Owen DeLong wrote:
> 
> 
>>> Clearly we have run out of trickery as multiple layers of NAT stumps even 
>>> the finest of our tricksters.
>> 
>> Yes, we can dedicate thousands more developer hours to making yet more 
>> extensions to code to work around yet more NAT and maybe make it sort of 
>> kind of work almost as poorly as it does now. Or we could pour a fraction of 
>> those developer hours into implementing IPv6 in those same applications and 
>> have the problem solved in perpetuity.
> 
> There is no "we"
> 
> People will follow their personal motivations. If that includes improving 
> their application experience in the face of prevalent CGN technology, I 
> expect many of them to decide to put in the effort no matter what either your 
> or I have to say about it.
> 

There most certainly is a "WE". "WE" may not get to make the decision about how 
any of this turns out, but "WE" will suffer the consequences of those 
collective decisions.

>> My hope is that we will realize at some point that this is a badly loosing 
>> proposition, but, my fear is that we will actually find ways to make it work 
>> and worse yet, dedicate resources to doing so.
>> 
>> IMHO, having it fail miserably is the best case scenario. The alternatives 
>> are far worse.
> 
> See above. The internet is not top down. It is a potpourri of interacting 
> influences. Nobody takes marching orders from either of us.
> 

Right, but everybody suffers the consequences of the decisions made by those 
interacting influences. As such, I am at least attempting to educate as many of 
the decision makers along the way in the hopes of getting some reasonable 
outcome somewhere down the road rather than watching the internet fall to 
pieces in NAT hell.

>> I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above 
>> for a partial list of the various things I expect they are doing with those 
>> addresses.
> 
> So a provider to have a one to one relationship between infrastructure 
> addresses and subscribers is somehow plausible to you? Anyone else?
> 

Subscribers, no, subscriber addresses in a wireless environment, yeah.

> Not to me. Not even if you count every single employees and every single 
> corporate server and device, of which the vast majority are not even using 
> globally unique addresses. Which is what we are discussing.
> 
> And suppose they are. A corporation like that can re-use 50% of their IPv4 by 
> converting internally to NAT (and IPv6 we hope).

There are many ways we can sabotage our infrastructure in order to squeeze more 
NAT out of many places. Personally, I would not advocate putting that effort 
into such an obviously losing proposition, but obviously I may well be in the 
minority there.

>>> How about much simpler math. Assume 75% IP in any provider organization are 
>>> for subscribers. Assume an average 5-10 subscribers per CGN IP.
>> 
>> I don't believe the first assumption and I think that more than about 3 is 
>> rather optimistic for the second one, actually. Especially in the face of 
>> dedicated port range CGN proposed by most of the ISPs I know have real plans 
>> to implement CGN rather than just a "yeah, we'll do that when we have to" 
>> approach.
> 
> Most NAT44 implementations have absolutely no issue scaling to low hundreds 
> of users with ONE IP address.
> 

We're not talking NAT44... We're talking NAT444 and you don't get nearly the 
multiplier at the second layer that you can get at the first level. You've 
already concentrated those low hundreds of users into the port range of a 
single address at the first level. Now you're inflicting a second level where 
you can't get nearly that level of compression.

> 3 is absolutely ridiculously low. 3 of the above, maybe.
> 
> However, even at 3, that means that they can double their subscriber base 
> with their existing addresses. So unless their existing base took 2 months to 
> acquire, that is a deal more than 4 month stop gap you claim.

Or not. At 3 they can double their subscriber base if they don't need any 
additional external facing infrastructure to support all of this and get a 100% 
efficient conversion of users from their existing connectivity to CGN.

> And since you believe that it is plausible for such an organization to have a 
> one to one infrastructure/subscriber relationship, going private (and we hope 
> ipv6) internally, gives them another 3x subscriber base.
> 
> Clearly, CGN can provide enough address re-use to stave off exhausting in a 
> provider's subscriber base for years.
> 
> But only if the technology scales and is not immediately rejected by 30-60% 
> of the subscriber base.

Which assumes many facts not in evidence and is contrary to the research and 
testing that has been done so far.

> This is why we view the testing of CGN as newsworthy.
> 

draft-donnely anyone?

>> 
>> 
>>> Clearly, that organization's subscri

Device specifically made for high capacity GRE tunnels for dozens of sites

[A. Pishdadi]

Hello,

Can anyone recommend a device that will allow for multiple gigabit gre
tunnels with ability to handle up to a million pps?
I know it can be done on a bsd or nix box , or something running junos but
Im looking for something specifically made and tailored for GRE tunnels.

Thanks,
Ameen

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Joe Maimon]

Lee Howard wrote:


You are welcome to deploy it if you choose to.
Part of the reason I'm arguing against it is that if everyone deploys it,
then everyone has to deploy it.  If it is seen as an alternative to IPv6
by some, then others' deployment of IPv6 is made less useful: network
effect.  Also, spending money on CGN seems misguided; if you agree that
you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
also* for CGN?


Lee



Suppose a provider fully deploys v6, they will still need CGN so long as 
they have customers who want to access the v4 internet.


Unfortunately, that may have the side effect of undercutting some 
portion of v6's value proposition, inversely related to its suckage.


Joe

Zero-Touch Deployment Remote Office solution?

[Matthew Craig]

We have a bunch of small remote offices where we deploy cheap routers with VPN 
tunnels back to the central office.  This is a very static process with high 
overhead… we have to manage each remote router separately, and the offices do 
not have tech personnel that can handle local office issues.

We're looking for a more centrally managed and automated "zero-touch" remote 
office solution, like the Cisco Virtual Office, where the local non-clueful 
people don't have to do much.

http://www.cisco.com/en/US/netsol/ns855/index.html



Does anyone have any experience / feeback for this Cisco Virtual Office 
solution or have recommendations for alternative solutions.



- Matt

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Owen DeLong]

Sent from my iPad

On Jan 18, 2013, at 4:03 AM, William Herrin  wrote:

> On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin
>  wrote:
>> IPv6 is obviously the solution, but I think CGN poses more
>> technological and legal problems for the carriers as opposed to their
>> clients or the general-purpose non-server non-p2p application
>> developers.
> 
> Correct. The most significant challenges to CGN are legal compliance
> issues. NAT complicates the process of determining who did what using
> the public IP at this timestamp. CGN developers have designed some
> novel solutions to that problem, such as dedicating port ranges to
> particular interior addresses and logging the range once instead of
> trying to log every connection. So, don't expect it to be a show
> stopper for long.
> 
> On the technical side, enterprises have been doing large-scale NAT for
> more than a decade now without any doomsday consequences. CGN is not
> different.
> 

Yes it is... In the enterprise, whatever the security team decides isn't 
supposed to
be supported on the enterprise LAN, the end-users just sort of have to accept.

In the residential ISP world, unless every ISP in a given service area degrades 
all
of their customers in the exact same way, you have a very different situation.

>> CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever.
> 
> Also correct. The primary impacts from CGN are folks who want to host
> a game server, folks running bit torrent and folks who want to use
> Skype. Skype's not stupid and voip relays are easy so after minor
> growing pains that'll cease to be an issue too.
> 
> Make opting out of CGN simple and cheap. The relatively few folks who
> would be impacted will opt out with no particular animus towards you
> and you'll recover the IP addresses you had dedicated to the rest.

An interesting theory, but I don't think it will be so few.

Owen

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Lee Howard]

On 1/18/13 9:03 AM, "William Herrin"  wrote:

>On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin
> wrote:
>> IPv6 is obviously the solution, but I think CGN poses more
>> technological and legal problems for the carriers as opposed to their
>> clients or the general-purpose non-server non-p2p application
>> developers.
>
>Correct. The most significant challenges to CGN are legal compliance
>issues. NAT complicates the process of determining who did what using
>the public IP at this timestamp. CGN developers have designed some
>novel solutions to that problem, such as dedicating port ranges to
>particular interior addresses and logging the range once instead of
>trying to log every connection. So, don't expect it to be a show
>stopper for long.

Many servers don't log source port.  Doesn't matter if the CGN operator
has a log, if you can't provide enough data to find the right entry in the
log.

>
>On the technical side, enterprises have been doing large-scale NAT for
>more than a decade now without any doomsday consequences. CGN is not
>different.

Even if the implementation was the same (it's not), that doesn't mean the
operation is the same in a a different environment.  Residential users
have different applications and expectations than enterprise users (not a
lot of game consoles or BitTorrent on corporate networks).  The legal
issue is different, too: a different level of response is appropriate from
a corporate net admin than an ISP.

>
>
>> CGN breaks the internet, but it doesn't break non-p2p VoIP at all
>>whatsoever.
>
>Also correct. The primary impacts from CGN are folks who want to host
>a game server, folks running bit torrent and folks who want to use
>Skype. Skype's not stupid and voip relays are easy so after minor
>growing pains that'll cease to be an issue too.

"voip relays are easy"?  To what scale, for a free service?

>
>Make opting out of CGN simple and cheap. The relatively few folks who
>would be impacted will opt out with no particular animus towards you
>and you'll recover the IP addresses you had dedicated to the rest.

You are welcome to deploy it if you choose to.
Part of the reason I'm arguing against it is that if everyone deploys it,
then everyone has to deploy it.  If it is seen as an alternative to IPv6
by some, then others' deployment of IPv6 is made less useful: network
effect.  Also, spending money on CGN seems misguided; if you agree that
you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
also* for CGN?


Lee

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Lee Howard]

On 1/17/13 6:21 PM, "William Herrin"  wrote:

>On Thu, Jan 17, 2013 at 11:01 AM, Lee Howard  wrote:
>> On 1/17/13 9:54 AM, "William Herrin"  wrote:
>>>On Thu, Jan 17, 2013 at 5:06 AM, .  wrote:
 The people on this list have a influence in how the Internet run, hope
 somebody smart can figure how we can avoid going there, because there
 is frustrating and unfun.
>>>
>>>"Free network-based firewall to be installed next month. OPT OUT HERE
>>>if you don't want it."
>>
>> I haven't heard anyone talking about carrier-grade firewalls.  To make
>>CGN
>> work a little, you have to enable full-cone NAT, which means as long as
>> you're connected to anything on IPv4, anyone can reach you (and for a
>> timeout period after that).  And most CGN wireline deployments will have
>> some kind of bulk port assignment, so the same ports always go to the
>>same
>> users.  NAT != security, and if you try to make it, you will lose more
>> customers than I predicted.
>
>Hi Lee,
>
>Then it's a firewall that mildly enhances protection by obstructing
>90% of the port scanning attacks which happen against your computer.
>It's a free country so you're welcome to believe that the presence or
>absence of NAT has no impact on the probability of a given machine
>being compromised. Of course, you're also welcome to join the flat
>earth society. As for me, the causative relationship between the rise
>of the "DSL router" implementing negligible security except NAT and
>the fall of port scanning as a credible attack vector seems blatant
>enough.

CGNs are not identical to home NAT functionality.  Home NATs are
frequently restricted cone NATs, which is why uPNP or manual
port-forwarding are required.  CGNs for residential deployments are full
cone NATs, so that this problematic applications are less problematic.
See http://en.wikipedia.org/wiki/Network_address_translation  and
draft-donley-nat444-impacts.


>
>
>>>It's not a hard problem. There are yet plenty of IPv4 addresses to go
>>>around for all the people who actually care whether or not they're
>>>behind a NAT.
>>
>> I doubt that very much, and look forward to your analysis supporting
>>that
>> statement.
>
>If you have the data I'll be happy to crunch it but I'm afraid I'll
>have to leave the data collection to someone who is paid to do that
>very exhaustive work.

I don't have any data that might support your assertion, which is why I'm
calling you on it.

>
>Nevertheless, I'll be happy to document my assumptions and show you
>where they lead.
>
>I assume that fewer than 1 in 10 eyeballs would find Internet service
>behind a NAT unsatisfactory. Eyeballs are the consumers of content,
>the modem, cable modem, residential DSL customers. Some few of them
>are running game servers, web servers, etc. but 9 in 10 are the email,
>vonage and netflix variety who are basically not impacted by NAT.


Netflix seems to have some funny interactions with some gateways and CGN.
[nat444-impacts]
What about p2p?


>
>I assume that 75% or more of the IPv4 addresses which are employed in
>any use (not sitting idle) are employed by eyeball customers. Verizon
>Wireless has - remind me - how many /8's compared to, say, Google?

The same number: 0.
I don't know how many addresses VZW has, but I could look it up in Whois
if I knew the orgID.
How'd you get 75%?

>
>If you count from the explosion of interest in the Internet in 1995 to
>now, it took 18 years to consume all the IPv4 addresses. Call it
>consumption of 1/18th of the address space per year.

You're going with linear growth?  See nro.net/statistics.


>Is it more like 1 in 5 customers would cough up
>an extra $5 rather than use a NAT address? The nearest comparable
>would be your ratio of dynamic to static IP assignments. Does your
>data support that being higher than 1 in 10? I'd bet the broad data
>sets don't.

If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining.  Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1).  That means that for every user you
NAT, you get 1/10 of an address.
Example:  An 10,000-user ISP is growing at 10% annually.  They have 1,000
addresses left, so they implement CGN.  You say to assuming 90% of them
can be NATted, so next year, 100 get a unique IPv4 address, the other 900
share 90 addresses.  At 190 addresses per year, CGN bought you five years.
 
I think your 90% is high.  If it's 70%, you burn 370 per year.
That doesn't include the fact the increased support costs, or alienated
customer cancellations, or any of the stuff I talked about in TCO of CGN.

Lee

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Joe Maimon]

Owen DeLong wrote:



Clearly we have run out of trickery as multiple layers of NAT stumps even the 
finest of our tricksters.


Yes, we can dedicate thousands more developer hours to making yet more 
extensions to code to work around yet more NAT and maybe make it sort of kind 
of work almost as poorly as it does now. Or we could pour a fraction of those 
developer hours into implementing IPv6 in those same applications and have the 
problem solved in perpetuity.


There is no "we"

People will follow their personal motivations. If that includes 
improving their application experience in the face of prevalent CGN 
technology, I expect many of them to decide to put in the effort no 
matter what either your or I have to say about it.





My hope is that we will realize at some point that this is a badly loosing 
proposition, but, my fear is that we will actually find ways to make it work 
and worse yet, dedicate resources to doing so.

IMHO, having it fail miserably is the best case scenario. The alternatives are 
far worse.


See above. The internet is not top down. It is a potpourri of 
interacting influences. Nobody takes marching orders from either of us.





I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above for 
a partial list of the various things I expect they are doing with those 
addresses.


So a provider to have a one to one relationship between infrastructure 
addresses and subscribers is somehow plausible to you? Anyone else?


Not to me. Not even if you count every single employees and every single 
corporate server and device, of which the vast majority are not even 
using globally unique addresses. Which is what we are discussing.


And suppose they are. A corporation like that can re-use 50% of their 
IPv4 by converting internally to NAT (and IPv6 we hope).



How about much simpler math. Assume 75% IP in any provider organization are for 
subscribers. Assume an average 5-10 subscribers per CGN IP.


I don't believe the first assumption and I think that more than about 3 is rather 
optimistic for the second one, actually. Especially in the face of dedicated port range 
CGN proposed by most of the ISPs I know have real plans to implement CGN rather than just 
a "yeah, we'll do that when we have to" approach.


Most NAT44 implementations have absolutely no issue scaling to low 
hundreds of users with ONE IP address.


3 is absolutely ridiculously low. 3 of the above, maybe.

However, even at 3, that means that they can double their subscriber 
base with their existing addresses. So unless their existing base took 2 
months to acquire, that is a deal more than 4 month stop gap you claim.


And since you believe that it is plausible for such an organization to 
have a one to one infrastructure/subscriber relationship, going private 
(and we hope ipv6) internally, gives them another 3x subscriber base.


Clearly, CGN can provide enough address re-use to stave off exhausting 
in a provider's subscriber base for years.


But only if the technology scales and is not immediately rejected by 
30-60% of the subscriber base.


This is why we view the testing of CGN as newsworthy.





Clearly, that organization's subscriber growth will be limited by CGN 
technology, not by address scarcity.


Why? Does it not scale linearly? If not, why not?


I dont particularly like a multilayered NAT internet any more than you.

However it is coming and will stay for as long as it is needed and 
useful for those who operate it. Which is likely to be far longer then 
either of us like.


We only differ in one point. You believe it will be so bad that it will 
immediately drive ipv6 adoption and be viewed as a short term expensive 
boondoggle of a misguided experiment. I am not so confident in its failure.


I think we are heading toward a new norm.





Think locally for a bit. Addresses are not instantaneously fungible across the 
internet. Any provider who can pull this off will have far more then a 4-month 
stop-gap. They may even have enough to peddle on the market.


I think that's very optimistic.


With your numbers, a provider can double or triple (actually quadruple 
or sextuple using your ratio) their subscriber base by converting to 
CGN. Were you being overly optimistic?


Or were my estimates, starting at quadrupling or more, overly optimistic?


I'm not sure why you say they are not instantaneously fungible.

>
> Owen

Because nobody deploying CGN is going to flag day convert entire 
subscriber bases. Because the addresses they free up will be reused 
internally. Because if you are not one of these entities with low 
hanging fruit such as easily convertible to CGN subscriber bases, you 
are NOT going to directly benefit from the efforts of those who do.


Unless they peddle it (or return it).


Joe

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Andre Tomt]

(resending with nanog-approved address..)

On 18. jan. 2013 01:30, Jeff Kell wrote:

On 1/17/2013 6:50 PM, Owen DeLong wrote:

Vonage will, in most cases fail through CGN as will Skype, Xbox-360,
and many of the other IM clients.


Not sure about Vonage, but Skype, Xbox, and just about everything else
imaginable (other than hosting a server) works just fine over NAT with
default-deny inbound here, and we have several thousand students in the
dorms that bang the heck out of those services.  Most applications have
adapted to the SOHO NATing router that is prevalent today on broadband
internet. And if it didn't work, believe me, I'd hear about it :)


Your users must have fairly low expectations :-)

That snide comment aside, a single level of NAT44 works OK now for most 
current consumer level applications. But this is about multiple levels 
of NAT, where the usual "hacks" with UPNP IGD/NAT-PMP to get inbound 
ports are not likely to work. Even if you dont support these tricks on 
your end today, its likely that it is supported at the other side. Most 
"p2p" traffic like Skype only needs the mapping to work at one end, as 
they have to signal/negotiate addresses and portnumbers through some 
third party anyway.


So currently, even double NAT at one end, it is likely to work out 
(within the current expectations of users.)


When CGN gets to critical mass, where both ends of a connection is 
likely to be even more crippled than today*, things change. Now you have 
to bounce all the data of some third party, like a DC, maybe not even on 
the same continent.


When Skype fails to map ports at both ends today the experience is 
pretty horrible actually, at least over here, even with the backing of 
Microsofts infrastructure. Also makes me wonder how expensive running 
such services will become (Only feasable for Google and Microsoft?)


* Some support for mapping ports at CGN is in development, but requires 
new or updated CPE/home gateways, software support/awareness and support 
for it in the CGN (riiight.)

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Seth Mos]

On 18-1-2013 15:03, William Herrin wrote:
> On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin
>  wrote:

> On the technical side, enterprises have been doing large-scale NAT for
> more than a decade now without any doomsday consequences. CGN is not
> different.

Well yeah, but everything is under control of the IT department to setup
rules and forwards. That's not the same as a end user that wants a port
forward to host a xbox 360 game on their fiber connection and can't set
it up.

I've tried getting the firewall disabled that denies "ALL" incoming
traffic on my 3G stick and it's simply not possible, that is the sort of
flexibility that the market is selling.

Most of the ISPs I have personally and professionally worked with have
the flexibility of a piece of mahogany.

I'm pretty sure that some of the dedicated online game hosters are
looking forward to this. Those investments should turn out great.

Regards,

Seth

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[William Herrin]

On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin
 wrote:
> IPv6 is obviously the solution, but I think CGN poses more
> technological and legal problems for the carriers as opposed to their
> clients or the general-purpose non-server non-p2p application
> developers.

Correct. The most significant challenges to CGN are legal compliance
issues. NAT complicates the process of determining who did what using
the public IP at this timestamp. CGN developers have designed some
novel solutions to that problem, such as dedicating port ranges to
particular interior addresses and logging the range once instead of
trying to log every connection. So, don't expect it to be a show
stopper for long.

On the technical side, enterprises have been doing large-scale NAT for
more than a decade now without any doomsday consequences. CGN is not
different.


> CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever.

Also correct. The primary impacts from CGN are folks who want to host
a game server, folks running bit torrent and folks who want to use
Skype. Skype's not stupid and voip relays are easy so after minor
growing pains that'll cease to be an issue too.

Make opting out of CGN simple and cheap. The relatively few folks who
would be impacted will opt out with no particular animus towards you
and you'll recover the IP addresses you had dedicated to the rest.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

[NANOG-announce] NANOG 57 Agenda and Meeting Registration Reminder

[Betty Burke]

Hi Everyone:

A final reminder.

You will not want to miss out... the NANOG 57 program is going to great.
 We have Monday morning Tutorials, Monday afternoon Keynote, Welcome
Social, great content for 3 days!
Check-out the NANOG 57
agendaas it
continues to be updated.

The Renaissance Orlando at Seaworld, *NANOG
block
Group
Rate Expires Saturday, January 19, 2013, do not delay in make your
reservation.*

Last chance to save on your registration fee!  *The current registration
rate will expire on Friday, January 18, 2013.*  You can register, manage
your registration, and retrieve receipts from the NANOGportal
(ARO)
.
To create a new account, or recover your password, click
here
.

Be sure to Join NANOG  today and
receive a $25 discount on standard registration fees for any NANOG conference
as well as  have a voice in guiding future NANOG activities.

See you Orlando!

Should you have any questions, please send them along to nanog-support@nanog
.org.

All best.
Betty

-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Tel: +1 510 492 4030
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)

[.]

On 17 January 2013 23:38, Matt Palmer  wrote:
..
> By the way, if anyone *does* know of a good and reliable way to prevent CSRF
> without the need for any cookies or persistent server-side session state,
> I'd love to know how.  Ten minutes with Google hasn't provided any useful
> information.

I think many people create  with a secret code that is
different and hopefully can't be predicted by the attackers.








The easy way to do this is to generate secret from the md5 if time in
miliseconds + a salt string, and store the secret generated
serverside. But if you don't want to store this secret key anywhere in
the server, you can relie in security by obscurity, and generate it by
a predictible algorithm, like  md5( year + "_SALT_" + id_user
+day_of_year).  A attacker can figure out the algorithm, or it can be
leaked, but if your site is small, and don't protect anything
important, it will stop the 100% of the attackers anyway.


--
--
ℱin del ℳensaje.

Re: EQUINIX

[Chris Rogers]

Here's the list pricing we received about a year ago for 60 Hudson/111 8th
in NYC: (24 month contract)
Single cab: $800/mo + $1000 setup
20A @ 208V: $605/mo + $500 setup
XC - Coax: $225/mo + $500 setup
XC - Fiber: $325/mo + $500 setup
XC - POTS: $25/mo + $100 setup
XC - T1/E1: $225/mo + $500 setup
PAIX 1gig: $1000/mo + $2000 setup
PAIX 10gig: $2500/mo + $4000 setup

Obviously, much negotiation was in order.

As others have said, the cab, and even power, is somewhat reasonable. But
the cross connects kill the whole thing.

-Chris


On Thu, Jan 17, 2013 at 10:55 AM, PC  wrote:

> My experience has been that the monthly rack rental fee will be a
> comparative bargain to basic power and a couple in-building cross connects,
> which will often more than double the cost.  When shopping for any
> provider, make sure you price out all the options you need in addition to
> the rack space itself.
>
>
> On Thu, Jan 17, 2013 at 8:04 AM, Rodrick Brown  >wrote:
>
> > On Thu, Jan 17, 2013 at 8:39 AM, ML  wrote:
> >
> > > On 1/17/2013 4:49 AM, Ryan Finnesey wrote:
> > >
> > >> What's the going rate now a days for a rack within EQUINIX?
> > >>
> > >> Cheers
> > >> Ryan
> > >>
> > >>
> > > I would imagine this varies greatly by market and maybe even suite
> within
> > > the building
> >
> >
> > And also power/cooling requirements.
> >
> >
> > >
> > >
> >
>



-- 

Regards,
Chris Rogers
CEO, Inerail
+1.302.357.3696 x2110
http://inerail.net/