[ppml] Proposed Policy: PI assignments for V6 (and v6 fees)

[Paul Vixie]

> The way to stop this is to create ULAs and also
> create geographically agregatable addresses.

geo-agg makes sense inside dense networks like isp's but it's not the right
model to capture the hairball nature of other networks.  note that ITU-T
has proposed political-agg, largely because they think that'll be the same
as geo-agg and because they don't know how isp's are interconnected -- the
idea seems to be a derivative of "let's keep local traffic local" but with
no understanding of the non-hierarchical placement of exchange points.  we
COULD try to make geo-agg (or pol-agg) work, but it would be a new economy
and infrastructure compared to the one we're trying to upgrade using ipv6.

> In IPv6, the household is the basic unit
> of measure, better known as the /48.

that's obscene on so many levels.  given that ietf chose a fixed-length
addressing scheme for "IPng" based on the needs of low-level hardware, it
was inevitable that certain fixed patterns would emerge in allocations --
for example, the /64-per-LAN idea used by EUI64.  very few LANs in this
century will have more than 65536 devices attached to them and the vast
majority will have fewer than 256.  however, EUI64 fits 18446744073709551616.
some people (me, for example) call this wasteful, and wish that the EUI64
spec had used a denser hash function on the MAC rather than this sparse one.
but if you buy into the EUI64 madness, it's really "8+8" in a way, and the
"network part" of an address only has 64 bits in it.

on the assumption that bits we don't use are wasted since not using them
means they didn't need to be there and nobody wants to be wasteful, how do
we "use" these other 64 bits?  why, by allowing every household to have
65536 networks, even though most will have only one and very few will ever
have more than 16.

so ok, now we have the /48 as the basic unit of measure.  however, if we
allow these "microallocations" to be the general PI allocation to small
and medium enterprise, then the routing table might someday have to contain
281474976710656 routes, and not even moore himself would say that's reasonable
in our lifetimes, at least with distance-vector routing protocols like BGP.
so it's clear that we still need hierarchical routing and that paths will
follow addressing.  it's also clear that political and geographical
aggregation won't work unless the political/geographical "units of measure"
become traffic carriers, traffic sources, traffic sinks, and traffic
exchangers.  that's not going to happen in our lifetimes, either.

> > and transform all ULA arguments to date into "PI reform" arguments,
> > and then restore "site local" addressing, which was valuable
> > precisely because it was dangerous and self-limiting.
> 
> Personally, I'm not that bothered by ULA addressing. And I expect that
> any address range set aside for site local will end up being used as
> ULA addresses because the random prefix idea is too good to go
> away. In fact, if ULAs don't make it through the IETF, then people
> will do this anyway.

let me tell you a story.  due to an accident of history, my name and phone
number and e-mail address comes up when you do a "whois" on the network that
contains the nameservers for the RFC1918 PTR zones, like 10.IN-ADDR.ARPA.
when the AS112 (see www.as112.net) project first began, my phone started
ringing, and a week never goes by without at least one call of the form:

them:	"hello, mr. vixie, why are you attacking my windows server?"
me:	"what do you mean?  what are you talking about?"
them:	"PRISONER.IANA.ORG shows up in my 'netstat', and that's you, right?"
me:	"well, sort of, i mean, i guess it's me.  did you read www.as112.net?"
them:	"yes, but i didn't understand it.  why are you attacking my server?"
me:	"let me as you a couple of questions, ok?"
them:	"sure."
me:	"do you use 192.168.0.0 as your local network?"
them:	"yes."
me:	"do you use DHCP and is your DHCP server a windows machine?"
them:	"uh, yeah."
me:	"and do you have some number of windows desktops and laptops?"
them:	"yes."
me:	"can you grab one and check your 'network properties' and tell me
	if the box for 'update the dns' is checked in the 'advanced' tab?"
them:	"let me look.  <click> <clickity> <click>.  yes, it is."
me:	"ok, you have to uncheck that box."
them:	"um, ok."
me:	"on every desktop and laptop you have."
them:	"ALL OF THEM?"
me:	"yes, all of them.  plus any new ones you get."
them:	"and that'll remove PRISONER.IANA.ORG from my 'netstat'?"
me:	"yup."
them:	"uh, well, thanks, i guess."

now, i'm not complaining.  only about one in seven of these callers is rude
and obnoxious and threatens to call the FBI and report my activities.  but it
gives me what i think is a very special perspective on your assertion that:

> ... site local will end up being used as ULA addresses because the
> random prefix idea is too good to go away.

i do not expect the average v6 site-local user, or their vendors, to be any
higher on the clue totem than the average RFC1918 user, or their vendors.
that means i don't expect most of them to even become aware of the random
prefix idea, and those that become aware of it will either find it too
complex, too cumbersome, too ugly ("all those extra hex digits, ick"), or
whatever.  this is a plug-and-play world now.

> The box is open, we now have to deal with it.

if by "deal with" you mean enable and predict digital data market behaviour
then i agree.  sadly, a lot of people think they can "control" it -- ouch.