[ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction

[Brian Dickson]

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 
for examples,
and neither requires  */120* use, nor specifies that any specific sizes 
is *mandatory*.

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 
policies.

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 
another PA").

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 
sizes.

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 
their infrastructure.
>> 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
time.

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 predictable.

Brian