v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

Iljitsch van Beijnum iljitsch at muada.com
Thu Feb 5 22:42:27 UTC 2009


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.




More information about the NANOG mailing list