[134597] in North American Network Operators' Group
RE: IPv6 - real vs theoretical problems
daemon@ATHENA.MIT.EDU (Deepak Jain)
Fri Jan 7 14:55:56 2011
From: Deepak Jain <deepak@ai.net>
To: Grant Phillips <grant.phillips@gwtp.id.au>
Date: Fri, 7 Jan 2011 14:53:49 -0500
In-Reply-To: <AANLkTi=_dh9GDSToHJy14dqqxvJ9vexzig7BTs-4MxVm@mail.gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Thanks Grant, I've already read this. :)
I have no problem with enabling /64s for everyone/everything in the future,=
as the equipment capability increases, but right now there are real concer=
ns about en masse deployment and the vulnerabilities we open our hardware t=
o.
Which is why I was talking about reserving the larger block, but only allow=
ing folks to have as much space as they can manage successfully and with a =
similar risk profile as they have today. Obviously it doesn't take too many=
people leaving their networks wide to cause a problem for the rest of us.
Best,
Deepak
From: Grant Phillips [mailto:grant.phillips@gwtp.id.au]
Sent: Thursday, January 06, 2011 5:47 PM
To: Deepak Jain
Cc: NANOG list
Subject: Re: IPv6 - real vs theoretical problems
Hi Deepak,
I acknowledge and see the point made. There is a lot of dead space in the I=
Pv6 world. Are we allowing history to repeat it self? Well i'm swaying more=
to no.
Have you read this RFC? This is pretty satisfying in making me feel more co=
mfortable assigning out /48 and /64's. I can sleep at night now! :P
http://tools.ietf.org/html//rfc3177<http://tools.ietf.org/html/rfc3177>
Cheers,
Grant Phillips
On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain <deepak@ai.net<mailto:deepak@ai=
.net>> wrote:
Please, before you flame out, recognize I know a bit of what I am talking a=
bout. You can verify this by doing a search on NANOG archives. My point is =
to actually engage in an operational discussion on this and not insult (or =
be insulted).
While I understand the theoretical advantages of /64s and /56s and /48s for=
all kinds of purposes, *TODAY* there are very few folks that are actually =
using any of them. No typical customer knows what do to do (for the most pa=
rt) with their own /48, and other than autoconfiguration, there is no parti=
cular advantage to a /64 block for a single server -- yet. The left side of=
the prefix I think people and routers are reasonably comfortable with, it'=
s the "host" side that presents the most challenge.
My interest is principally in servers and high availability equipment (rout=
ers, etc) and other things that live in POPs and datacenters, so autoconfig=
uration doesn't even remotely appeal to me for anything. In a datacenter, m=
any of these concerns about having routers fall over exist (high bandwidth =
links, high power equipment trying to do as many things as it can, etc).
Wouldn't a number of problems go away if we just, for now, follow the IPv4 =
lessons/practices like allocating the number of addresses a customer needs =
--- say /122s or /120s that current router architectures know how to handle=
-- to these boxes/interfaces today, while just reserving /64 or /56 spaces=
for each of them for whenever the magic day comes along where they can be =
used safely?
As far as I can tell, this "crippling" of the address space is completely r=
eversible, it's a reasonable step forward and the only "operational" loss i=
s you can't do all the address jumping and obfuscation people like to talk =
about... which I'm not sure is a loss.
In your enterprise, behind your firewall, whatever, where you want autoconf=
ig to work, and have some way of dealing with all of the dead space, more p=
ower to you. But operationally, is *anything* gained today by giving every =
host a /64 to screw around in that isn't accomplished by a /120 or so?
Thanks,
DJ
