[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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