On Jan 6, 2011, at 2:00 PM, Deepak Jain 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?
>
No... A single perceived problem would go away and we would reacquire many many
more problems that IPv6 is intended to leave behind.
So far, IPv6 scans have been few and far between. The ones we have seen have
been short lived and haven't even scanned a single
network (Perhaps some time in the next 500+ years we will see one that does,
but, I have my doubts).
I think that targeted or hinted scanning will be the more likely approach in
the IPv6 world. We haven't yet seen what will happen in that
realm.
As to what we lose if we eliminate large sparse end networks, we lose the
following advantages:
+ Ability to just add machines to a network without having to worry about
resizing the network or
renumbering everything or worst of all adding yet another prefix to
hold the new machines.
+ Sparse address density and privacy addressing capabilities
+ SLAAC
+ Simplified "network of things" capabilities
There are probably other things as well, but, those 4 are what I can think of
off the top of my head.
Only the first one applies to server environments, but, it's a HUGE win for
server environments, so, I think it's worth preserving for
that reason alone. However, if you're willing to abandon that for your server
farm, then, nobody is stopping you, actually. IPv6
fully supports statically configured networks of any size down to /127. Knock
yourself out.
> 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.
>
I'm not sure what you mean by "crippling" of the address space. It seems to be
working just fine in a number of production
environments around the world, including both my work and home environments.
> 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?
>
I don't imagine anyone will give every host a /64. What is currently proposed
is giving every network a /64. Most networks
contain at least two hosts to be minimally useful (router + end system), and
the vast majority of those contain more than
one end system (3+ hosts).
Owen
