[149655] in North American Network Operators' Group
Re: couple of questions regarding 'lifeline' and large scale nat...
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Fri Feb 10 16:44:37 2012
Date: Fri, 10 Feb 2012 13:43:41 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: "'nanog@nanog.org'" <nanog@nanog.org>
Mail-Followup-To: "'nanog@nanog.org'" <nanog@nanog.org>
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--yNb1oOkm5a9FJOVX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Feb 10, 2012 at 03:19:24PM -0600, Eric J Essli=
nger wrote:
> First question, if you happen to be doing something like this, what bit r=
ates are you providing.
Comcast has a program with some of the best marketing around it right
now, their Internet Essentials service: http://www.internetessentials.com/
$9.95/month, 1.5Mbps down, 384kbps up.
> Second question, though 'real' internet customers all get real IP's, what=
would you think of doing something like this with 'large scale' nat instea=
d.
Carriers do not want to run NAT's. You can go read the archives of the
CGN (Carrier Grade NAT) discussions where folks are looking at moving
the NAT into the service provider due to IPv4 exhaustion.
UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
passthrough), combined with the problems of some applications that
make thousands of TCP connections in a short order eating up ports
makes it a nightmare to manage and debug. Of course, if they are
doing illegal things you'd better keep some detailed records of who did
what when a LEO comes knocking.
The key to a low cost service is making it as low cost as possible,
moving the NAT inside the carrier will had a huge amount of headache and
support costs, not what you want.
A possibly relevant question with IPv4 exhaustion coming is could you
make this service IPv6 only so you don't have to find IPv4 addresses for
it.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--yNb1oOkm5a9FJOVX
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBTzWPjbN3O8aJIdTMAQIpZRAAnulIqokPGHPiIsF7R25fgytx0SbKz7/1
yCMt+SMO+liwIQ5gYM2TyrWmklGWKFZScPWGDupdhitUHPWPgfGXKBxWyrGf3SJ4
983c2vBB6FdLhfaYL0sG2unh9OyivzdKQuVXvipdG1ANILizb80F8ESnSUBseQiR
Kz5SJe3s1SxI0JUvtGgYv9T6+XkIxs9AZn502E4kXvMQ8lbVG0f2leF3rvfGV4IR
ff4FZQtauJ36UOaC/B5RjJw6tmeC4Ks7am4l6um8WcoeOlz+3hWR2ZugKQ1cnCPY
6X1oe316puRqT6SoobrkW5CJNi+xyooa/h5A6up0Xb6Vm6hVG0aCPTGv1fT/QRND
/jaYIwZP3FzhzvPndw33DkBaEWWz7cUY5Bk7CsI2FjyFphf3GtKjY9CtNPmcsK0t
2gI1+I29xLDHc54byjVN1d5yz7ffR6BO8sr0HSaT+mqjb8P5konFslftRVRpPDKF
JcjT3m4Df5tnY1tVj7sGsXNa+f5KRlAaO3BRlk74X8JcEUm06J0PF/IrNvy8sMQJ
wBZWbtP5Hp4wv4SzK+SSeOJRZo142QXYXB1Lhzpvvh/9IZjpV8rfEAuO/fKt2Ib5
wnqtqo0R+vaErxGktlIU4/soXYcC2jCfKSK4/ofqGylhScCPI6nllfDg+iBLwdsF
l6403bYZc+4=
=k87Y
-----END PGP SIGNATURE-----
--yNb1oOkm5a9FJOVX--
