RE: IPv6 - real vs theoretical problems

[Deepak Jain <deepak () ai net>]

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 concerns about en masse deployment and the vulnerabilities we open our hardware to.

Which is why I was talking about reserving the larger block, but only allowing 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 IPv6 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 comfortable 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 about. 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 part) with 
their own /48, and other than autoconfiguration, there is no particular 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 (routers, etc) and other things that live in POPs 
and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many 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 reversible, it's a reasonable step forward 
and the only "operational" loss is 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 autoconfig to work, and have some way of dealing 
with all of the dead space, more power 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