[ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction
briand at ca.afilias.info
Tue Oct 30 14:41:16 EDT 2007
Jeroen Massar wrote:
> Brian Dickson wrote:
>> We use /48's because they are announced directly to the DFZ, and the
>> following are (IMHO) applicable:
> What about that those 2x /45, that /47 and that /46 you have now?
> Are you going to announce those as /48's?
The prefixes that we are announcing currently, from those blocks, are
announce already as /48's.
All such allocations are going to be announced only as /48's.
>> - The smallest PI block assigned by RIRs is /48
> The main reason is because a /48 is considered to be a single site.
> You are apparently proposing to change this boundary to a /120 for the
> PA blocks that are being allocated by ISPs to their users.
No, I am proposed a policy whereby the ISPs reassign space from PA
blocks to their users,
based on the users' own plans. The proposed policy has *suggested* sizes
and neither requires */120* use, nor specifies that any specific sizes
It does, however, suggest *permitting* allocation of blocks longer than
/64, and provide guidance on when
different specific sizes of allocation might be "ideal" for the end-site.
>> Because each TLD needs to be anycast from a topologically unique *set*
>> of servers.
> But why?
Routing follows policy, not the other way round.
Policy dictates what goes where.
And because each TLD is subject to different policy based on a variety
of factors, it is mandatory
that TLDs be de-coupled so as to permit implementation of non-congruent
If two TLDs, ".foo" and ".bar" are served from a site in a country
Fakeland, and the supreme court
of Fakeland decrees that ".bar" must not exist in Fakeland, having both
".foo" and ".bar" on the same
anycaset prefix would mean that ".foo" would be effectively banned from
Fakeland as well.
(I'm aware that removing or changing NS "glue" can achieve similar
results, but that ignores the problems
of caching resolvers and TTLs. The latter preclude solutions that do not
have near-instantaneous effectiveness.)
>> If you have two TLDs whose topology of anycast is different, they must,
>> by definition of anycast, have unique prefixes.
> Why are they going to be different? Are you going to locate the .info
> server in one datacenter but not in another? Why?
Yes. For policy reasons
See the above example for one policy that could require such a difference.
> There is nothing special about a TLD server. Their addresses are not
> hardcoded in any configuration files that are distributed around the
> world. The root-server addresses are hardcoded. TLD servers though can
> be found by asking those rootservers. As such they are not more special
> than having google.com NS's.
The TLDs are delegation-only zones. And their addresses are effectively
hard-coded in resolver's
caches, for the duration of $TTL seconds. That itself is reason enough
for them to be "special".
> You are using a routing slot per nameserver, that is apparently 2 slots
> per TLD. Now who is being wasteful? Them or you?
The rate of growth of TLDs is constrained by ICANN. *Every* TLD is
chartered by ICANN.
You can see how often they approve a new TLD, no more than a small
number per year, and often
much less than that.
None of this has anything to do with "waste", it has to do with
management of scarce resources.
There is no such fundamental upper bound, currently, on PA allocations.
Rate limiting PA allocations can be done by edict ("thou shalt not have
Or, PA allocations can be limited by the law of big numbers ("You can
have another PA block when you have assigned 2^87 customer prefixes").
(Hint - the universe is less than 2^88 seconds old.)
Or, PA allocations can be completely uncapped, with no guarantees on the
rate of growth or timeline of exponential growth.
I should be clear here. I do not think there is an extraordinarily high
probability of PA explosive growth in the short term.
I am concerned that it can't be guaranteed that it won't happen.
My proposal is attempting to address this concern, at little or no cost
to the community.
It is reducing a *risk*, the consequences of which are harmful to
everyone (to a greater or lesser degree).
Opposing the proposal, is advocating for taking risks. (I just want to
make you aware of that.)
> But I really don't see why you need to force those PA holders to force
> their customers to do /120's
I'm not suggesting *forcing* anyone to do anything.
I'm proposing *allowing* longer assignments, and *suggesting* suitable
Currently, no one is *allowed* to give out anything longer than a /64,
although lots of
smart folks use longer prefixes for things like point-to-point links on
>> Companies doing internal stuff, whether they get a reassignment *from* a
>> PA block, or via a PI block, generally
>> have much more predictable usage.
> Again, WHY is that?
> Stating things is easy, but please add an explanation about why you are
> stating it.
The explanation is not difficult.
When you are in control of the plan and the usage, it is more
predictable. Internal use is generally
a function of capital expenditure, which is for most companies well
understood and has a long lead
When you are not in control, e.g. when the assignments are to customers
(and thus a function of "sales"),
it is less predictable. (If you doubt me, ask any sales person about
predictability of sales.)
The lead time between a sale, and the request for an address block, is
considerably shorter than
the planning time for network expansion. And *that* makes the latter
More information about the ARIN-PPML