[ppml] 2005-1:Business Need for PI Assignments

[Michael.Dillon at radianz.com]

> > The question of waste has to do with the environment you are in, the 
sources
> > of supply, and the difficulty of obtaining a resource. IPv6 addresses 
may
> 
> Your analogy here holds more water than you might think.
> 
> Water, like IPv6 addresses, is abundant.
> Drinkable water, like usable IPv6 addresses, is not.

That's because the RIRs are hording the vast supply
of fresh clean water in their reservoir.

> Using a /64 for a "LAN" is like dumping raw sewage into the water
> and then wondering why it's contaminated. 

Now you are mixing metaphors. Using addresses is like using
water. It's not like adding something to the water. And using
a /64 for a single LAN subnet is just good practice in compliance
with the IPv6 RFCs.

Again, your thinking is stuck in the old-fashioned world of
IPv4. We cannot make good IPv6 policy if we insist on treating
the IPv6 address space just like the IPv4 address space. We have
to learn from our IPv4 experience and move on. Learning implies
that we have gained understanding and that we can make new decisions
rather than slavishly imitating the past. 

I know this is hard to do and requires some innovative and
creative thinking, but that is what must be done to create a 
sensible IPv6 policy.

> Now, I'll be the first to
> admit I'd like to not have to use 1918 space for the 650 subnets I
> have at home behind my 3Mbps cable modem, but giving me 100 times
> that again prevents someone else from using the space who might
> actually need it.

This is quite simply, wrong! If your ISP were to give you a /48
for a single home subnet with 2 computers, that would not preven
anyone else from getting IPv6 address space until sometime after
your natural death from old age. Of course, at that point we can
reuse your /48, your house and any other possessions that you may
have left behind. With IPv4 we were worried about whether there 
would be any addresses left for our kids to use. With IPv6 we
know that the address space will last longer than any human currently
living on this planet.

> We have people who are talking about allocating IPv6 addresses to
> serve a 60 year need.  Well, that's all well and good, but it's
> only 40 years after the doorknob quote and the reality is quite
> different.  Ideas that seem far fetched today like colonizing mars,
> or faster than light travel, or nanomachines that have IP stacks
> may be so common place in 60 years time that no one gives them a
> second thought.

Seriously, if we discover 60 years from now, that we have made a
mistake with IPv6, then we will also have the knowledge and the
ability to create a replacement for IPv6. Or to recover unused
addresses. Or something else. RIR policy does not have to be good
enough forever. It just has to be good enough for today, and for the
foreseeable future. We don't want to penalize today in order to
support the unforeseeable future because in doing so, we may never
be able to reach that unforeseeable future.

> What's most absurd about things like a /48 for cable modem users
> is that it only promotes waste. 

No, the absurd thing is calling unused addresses "waste". Unused
addresses are inherent in the notion of IP, whether v4 or v6.
It has to do with the hierarchichal addressing system that allows
ranges of addresses to be treated in aggregate by IP routers. 
It is fundamental to the concept of IP and we must live with that.
Given this fact, it is unwise to call this "waste".

In IPv4, there is such a thing as "waste" when an address range is
oversized. But in IPv6, everybody gets a /48, every subnet gets a
/64. Where is the waste?

This is not where we make our policies. The RIRs really should
only be deciding the criteria for handing out a /32 or larger
block of IPv6 addresses. And if an organization is going to announce
their addreses in the global routing table, then I think that justifies
giving out a /32. If there is a concern about who should and should 
not announce addresses in the global routing table, then that should
be dealt with in AS number policy.

--Michael Dillon