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.