[ppml] IPv6>>32

[Paul Vixie]

> ...
> To preserve the good, and eliminate the bad, I propose a simple
> change.  Shift all of the current policies to the right by 32 bits.
> That is, the host portion becomes a 32 bit quantity.  EUI-64's
> would no longer be used, all hosts would simply randomly generate
> addresses for autoconfiguration.  This is already the direction the
> privacy work is going.  32 bits is more than enough to allow random
> address selection on extremely large lans (10-50,000 addresses)
> with minimal collisions.

i like this.

>                          The host portion would still be fixed,
> allowing for easy renumbering, autoconfiguration, and similar features.

but not this.  i already have some /124 subnets here.  noone outside
a subnet should ever make any assumptions of where the boundaries are
between my isp (if any), my site/campus, my subnet, and my host.

> All other boundaries move down as well:
> 
> - A /64 subnet becomes a /96 subnet.
> - A /48 assignment becomes a /80 assignment.
> - A /32 ISP allocation becomes a /64 ISP allocation.

as recommended boundaries, these are good.  as vendor defaults, these
are good.  but as protocol invariants, they would be very, very bad.

> The largest down side I can find is the unknowns listed above.  It
> appears some people are thinking of applications that require the
> host portion to be globally unique, and/or applications that depend
> on being able to imbed a prefix in the host portion, or a host
> portion in the prefix portion.  I have been unable to find any hard
> documentation on either of these applications, and I would be
> extremely interested in any defined uses of these behaviors.

so would i.  if we're going to go back to 8+8 then we should also go back
to TLA's and pTLA's.  there's no need for all the complexity we've built
into the allocation system if the bottom 64 bits are going to be universal.

> Obviously, there are a few down sides:
> 
> - The specification and code to do autoconfiguration will have to be
>   changed.

EUI-64 is on its way to "dead" in any case.  not because of address space
shortage but because autoconfiguration doesn't provide enough auditing of
host come/go events.

> - ISP's that have already received a /32 (or larger) have made a
>   successful land grab if those addresses are not reclaimed.

i don't see a way to get address space back, but since we know we can't
hand a /32 to every multihomer and still fit the routing table into
available hardware (or fit the route churn into the available network),
most existing /32's are already destined to be considered "land grabs"
by future generations.

> This is why PPML is involved.  I think the community needs to think
> about this issue and if it is worth discussing.  I'm not sure my
> proposal is "the best" or even good, but without a straw man to
> dissect the discussion will not be complete.

i agree that this is an RIR issue rather than an IETF one.  the IETF is
where proposals like 8+8 and TLA/pTLA come from.  "how to carve it up"
is not a decision that most protocol designers are qualified for or
interested in.

and i think this is a good proposal, with the exceptions noted above.