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

Brian Dickson briand at ca.afilias.info
Tue Oct 30 12:10:27 EDT 2007

Jeroen Massar wrote:
> I am not coming forward as any
> company, I am coming forward as an individual user of the internet and I
> have huge concerns with what you are trying to propose and what you are
> actually doing yourself/company.
I do not care what you think of what I am doing, or what my employer is 

However, you are saying you have "huge concerns with what I am trying to 

Would you care to instantiate those concerns, and elaborate on why you 
think they are a problem?
>> *However*, since you bring up the question:
>> These are used specifically, and explicitly, for DNS anycast services
>> for Afilias, as operator
>> of numerous TLDs (Top Level Domains), such as ".org", ".info", ".mobi",
>> ".aero", ".asia", etc...
> Thus you are advocating on one side (according to your private opinion
> while pushing the name of your company) that companies should only get a
> small amount of address space (eg a /48) and only provide a /120 to end
> user while your company burns through a /47, 2x /45, a /46 and a /48?
I am advocating policies applicable only to PA space.
PA space is blocks given to ISPs to assign to their customers.

PI space (direct assignments by RIRs) are not affected by my proposals.

We use /48's because they are announced directly to the DFZ, and the 
following are (IMHO) applicable:
- The smallest PI block assigned by RIRs is /48
- PA blocks are intended to be announced only as the PA block
- deaggregating PA blocks is at best naive and at worst anti-social
- multihomed networks who are sufficiently justified in getting PI 
blocks (by whatever rationale is generally accepted), *should* use PA or 
PI blocks
> And that because you host some nameservers and are going to anycast
> those? If you are going to anycast them, why do you need more than a
> single /48?
Because each TLD needs to be anycast from a topologically unique *set* 
of servers.

If you have two TLDs whose topology of anycast is different, they must, 
by definition of anycast, have unique prefixes.

We use unique prefixes for each TLD or country-code TLD (such as .ag, 
.mn, .in, etc.) as well as the
afore-mentioned three- and four-letter TLDs.

> You do expect that a huge ISP will only announce one single /20 and thus
> receives all their traffic in that one spot, but for your own purposes
> suddenly you are special and you are going to announce separate prefixes?
Yes. Just the way root servers are special. All 13 of them. Anycast in a 
few hundred locations.

There is one "root". Each of those 13 instances of "root" are anycast, 
and use one /48.

There is more than one TLD, many more than one. Each of *those* need at 
*least* two /48's, since
the minimum number of nameservers for any zone is two.

And yes, root servers and TLD servers are *very* special.

They are very much *not* DNS hosting. (I humbly suggest you review the 
archives of dnsop).
> But just in case you do not want to read what I write, I'll state it
> again: Why are you proposing that ISP's should have only one single
> block and instead of them asking for one huge prefix have the end-user
> receive a lot less space, this while you are requesting several large
> blocks, are going to announce those blocks separately and are most
> likely only going to use a few number of IP addresses in those blocks?
> See the big problem with what you are proposing and what you are
> actually doing?
I see that you can't make the distinction between PA and PI blocks.

The reason for suggesting policies where smaller allocations to end 
sites is done in PA space,
is specifically because nobody knows who will be a lot bigger in 5 or 10 

We know who is big now. We don't know who (of all the ISPs that exist, 
or will be started
in the next 5-10 years) will be big later.

The flaw in the logic of "give a huge prefix to large ISPs now" is that 
it presumes that only
currently-large ISPs will use up lots of allocations. Even if it may be 
true, we don't know
for sure that it will be true.
> For a nice technical question. Will those blocks you are going to
> announce all be announced over physically different mediums or are you
> going to announce them over the same paths? If it is the latter, then
> why again did you request multiple blocks and are you going to pollute
> the DFZ with that?
Different mediums. There will be overlap by site, but definitely, and by 
design, not 100%.
It is also fluid, changing as circumstances require, and on a per-prefix 
(i.e. per TLD) basis.
>> And even though we only use a single IP address from the anycast blocks,
>> the smallest direct assignment possible under ARIN policy is a /48.
> And thus you request and receive:
> 2001:500:16::/47
> 2001:500:18::/45
> 2001:500:20::/45
> 2001:500:28::/46
> 2001:500:2c::/48
> Except for the latter one, they are all larger than a single /48. Can
> you elaborate on that? Are you still going to stick a single box in that
> huge /48?
ARIN is allocating blocks all at one time. It is more convenient for 
ARIN to handle the allocations
as a "set". These are in fact all used (and registered) as discrete /48's.
> If you are so confident about the proposed /120 for home user, why not
> request a /120 for your DNS servers?
PI direct assignments are not available as /120 (currently). If they 
were, that would be what we request.
(Trust me, we do not need more than that.)

The size of PI allocations, however, is not an issue at all. A PI block 
uses one router slot, without any
consideration of its size.

The only issue with PA blocks is the fact that they are reassigned, and 
consumed, in an unpredictable fashion.

Companies doing internal stuff, whether they get a reassignment *from* a 
PA block, or via a PI block, generally
have much more predictable usage.

> One last thing to summarize it all: Eat your own dog food.
How do you know I have dogs?

I do - and feed them very well. They get only the best, and yes, I do 
share some of what they get.
Filet mignon, or chateau-briand on occassion. :-)

Brian D

More information about the ARIN-PPML mailing list