This is very intersting because
I was having the same exact discussion
with izumi-san. A discussion about
the situations that "critical infrastructures"
will face after the final /8 seems important.
o in the final days, a v4 ixp will need a /24 or /25 or so
/24 /25 seemed pretty generous at first glance
considering that there should be less IPv4
traffic and thus less peering activity
on IPv4 if LIRs can't get new IPv4 space.
But if CGNatting becomes popular that may not
be the case. This is hard math.
<chair hat = off>
but my memory is that, like the size of the prefix to be handed out,
the policy for qualification is actually a reference to then current
qualification policy.
sam whacked me to point out that the christchurch discussion did not go
with the loose interpretation of 'allocation' to mean allocation or
assignment. so i recant, it is probably easier to change that blurring
in 62 than in base policy. i am not sure i care deeply about allocation
vs assignment, i have always thought the distinction of little use.
folk need space, for use or redisribution or both. big deal.
in this case, if 62 is taken formally, one can receive an allocation,
which an isp can then chop up and give to its customers, but an end site
can not receive an assignment for its own use.
i suspect the math on the likely number of end sites is rather different
than the math on the number of isps. this is likely why 62 is worded as
it is. this would then lead us into a discussion of stuff such as
o in the final days, a v4 ixp will need a /24 or /25 or so
o a multi-homed end site should not get more than a /29 (remember,
they may want more than a /29, but we're out of v4 space, so tough
patooties)
o critical infrastructure [0] does not need more than a /29
i am not against having such a discussion. but i think it needs to be
had before just blythely allowing assignments from the last /8.
randy
[0] and i never beleievd that dns servers other than root servers were
in critical need of fixed addres space
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkuHI0QACgkQcrhTYfxyMkKJKwCfQ4yXdZ9Otdwy+p6m9O1DBz5r
QzUAn3kXpN2zflKBZgdxbokB7dx0AgXj
=bZ+3
-----END PGP SIGNATURE-----