On 5 feb 2009, at 22:44, Ricky Beam wrote:
A single /64 isn't enough for a home user, because their gateway is
a router and needs a different prefix at both sides. Users may also
want to subnet their own network. So they need at least something
like a /60.
Mr. van B, your comments would be laughable if they weren't so
absurdly horrific.
That doesn't change the fact that users would be quite constrained by
only having a /64 for their internal network.
I've lived quite productively behind a single IPv4 address for
nearly 15 years.
So you were already doing NAT in 1994? Then you were ahead of the curve.
I've run 1000 user networks that only used one IPv4 address for all
of them.
But how is that relevant for the discussion at hand? Is your point
that if 1000 users can share an IPv4 address, 1000 users should share
an IPv6 address?
How would that make sense? Sharing addresses comes with significant
downsides. (Like having to port map services running on hosts on the
inside.) Sharing one address with 1000 active users comes with even
more downsides. (There are applications that need more than 64 ports
so the port number space becomes a limitation.) IPv6 was specifically
designed to provide an enormous amount of address space, so accepting
the limitation of using one address for a large number of users means
foregoing a prime feature of IPv6--for no reason that I can see.
Yet, in the new order, you're telling me I need 18 billion, billion
addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an
access point?
The logic is like this.
1. You need more than one.
2. You don't want to change the number often (or at all)
3. What is a number that is so large that it will always be enough?
Answer: the size of a MAC address.
4. How large are MAC addresses?
Answer: we have technologies that have 64-bit MAC addresses. So we use
64 bits to number subnets.
Now of course that seems wasteful, but those 128-bit addresses are
carried in all packets anyway, and at least with 64-bit subnet sizes
you get some use out of them because you know subnets are always large
enough and you get to generate an address from a prefix through a
function that gives you the same address without requiring anyone to
remember that address, which is also useful.
Now if you want to argue that IPv6 should have had 48, 53 or 64 bit
addresses, that's fine. But I have to warn you that that ship sailed
almost 15 years ago. (My take: they should have been variable length.)
This is the exact same bull**** as the /8 allocations in the early
days of IPv4.
Oh no. A /8 is only 16777216 addresses. A /48 for an end-user
organization is 1208925819614629174706176 addresses.
Or, more relavant: a /8 is almost 0.5% of the IPv4 address space. A /
48 is 0.000000000003% of the currently defined global unicast IPv6
address space.
The idea of the "connected home" is still nowhere near *that*
connected;
It took us 15 years to get this far with IPv6. There is no IPv7 on the
horizon currently, so even if we start that tomorrow we'll have to get
by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be
*that* connected by that time.
no matter how many toys you have in your bathroom, it doesn't need
a /96 of it's own. (which is an entire IPv4 of it's own.)
Like I explained, we count "0, 1, many" where the IPv6 definition of
"many" happens to be 2^64. This is obviously not the single answer
that is right in all cases. But the point is that there are reasons
why it was a bad idea to make it less than that and no reasons that
reasonably required it to be less.
Why do people avoid and resist IPv6... because it was designed with
blind ignorance of the history of IPv4's mistakes (and how we *all*
run our IPv4 networks.) Dooming us to repeating ALL those mistakes
again.
IPv6 changes too much but it doesn't fix enough. It would be good if
it didn't change much but fixed a lot, but unfortunately, that wasn't
to be.
Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent
pending), you don't need DHCP. *face plant* The IPv4 mistake you've
NOT learned from here is "rarp". DCHP does far more than tell a
host was address it should use.
An IPv4 DHCP server gives me five things: an address, a prefix length,
a default gateway, DNS addresses and a domain. A DHCPv6 server _can_
give me an address but I don't need it because I can generate it
myself (with a little help from my friends the routers), it can't give
me a prefix length or default gateway, so I still need router
advertisements for those (may as well hardcode that /64 now because
there is no reasonable way to get something else to work) and I don't
need the domain because it's always muada.com anyway. So the only
thing missing is the DNS addresses, but RFC 5006 specifies how to add
this information to router advertisements.
So I have no need for DHCPv6*.
If someone else has, good for them and good luck with that. As long as
I don't have to run a DHCPv6 server just to suck up all the broadcasts
from DHCPv6 clients that are looking for DHCPv6 servers in my network.
Please pick up after your dog.
* except for prefix delegation to routers.
