[ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction
briand at ca.afilias.info
Tue Oct 30 10:58:28 EDT 2007
Jeroen Massar wrote:
> Now the fun part of this, these 5 de-aggregated blocks which where just
> allocated by ARIN to a certain company called Affilias, the same company
(Presumably you meant to spell it "Afilias"...)
> that he is working for, is using his email address from and which name
> is also on the draft:
Uh, Jeroen, the affiliation with companies, as you well know, is
Pointing to what employers do when regarding proposals, is *way* off
base, in the realm of
ad-hominem attacks - something specifically against the mailing list
*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...
If you had bothered to look at the registrations, or IRR, or anywhere,
that would be obvious.
Even the web site www.afilias.info, makes it very clear we do DNS
E.g. Take a look at the *previous* ARIN assignment:
mail:bind-9.4.1 (bash)$ whois -h whois.arin.net 2001:500:e::
OrgName: Afilias Canada, Corp.
Address: 4141 Yonge Street
Address: Suite 204
NetRange: 2001:0500:0006:0000:0000:0000:0000:0000 -
NetType: Direct Assignment
RAbuseName: Abley, Joe
RAbuseEmail: jabley at ca.afilias.info
RNOCName: Abley, Joe
RNOCEmail: jabley at ca.afilias.info
RTechName: Abley, Joe
RTechEmail: jabley at ca.afilias.info
OrgTechName: Abley, Joe
OrgTechEmail: jabley at ca.afilias.info
# ARIN WHOIS database, last updated 2007-10-29 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.
mail:bind-9.4.1 (bash)$ whois -h whois.ra.net 2001:500:e::
descr: Afilias Canada, Corp.
changed: jabley at ca.afilias.info 20061109
mail:bind-9.4.1 (bash)$ whois -h whois.ra.net AS12041
descr: Afilias Limited
descr: Prefixes announced from this origin AS are
descr: anycast from several places. See RFC 4787.
export: to AS12041:AS-TRANSIT announce AS12041:AS-AFILIAS
export: to AS12041:AS-PEERS announce AS12041:AS-AFILIAS
export: to AS112 announce ANY
import: from AS12041:AS-TRANSIT accept ANY
import: from AS12041:AS-PEERS accept AS12041:AS-SET:PeerAS
import: from AS112 accept AS112
changed: jabley at ca.afilias.info 20070921
changed: jabley at ca.afilias.info 20070922
These are all Direct Assignments, and are anycast for DNS services. It
even says so right there.
> So one has to wonder, if they already got their own de-aggregated
> prefixes, why do they want to block others from doing so.
Why do you interpret "let's all avoid polluting the DFZ" to mean "If you
see someone else polluting, it is okay to pollute"?
We (Afilias) have /48's as direct assignments, specifically because each
DNS TLD needs to operate independently.
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.
Clearly, root servers and TLD servers need to be globally reachable.
(*Those* router slots are an example of very good return on the usage,
IMHO. The Internet is not usable without them.)
> If it would happen in the first place that is, remember that a /32
> actually comes out of a reserved block of afaik a /29, as such those
> blocks can grow without any problems and de-aggregation. Any ISP who
> needs more than that definitely has grown a lot or have really
> misplanned how much space they will need. Most ISPs will do fine with a
> /64 though.
The whole point of my proposal at ARIN, is actually orthogonal to the
IETF proposal, although
anchored from the same rationale:
Let's adopt policies and IPv6 implementations, which ensure as long a
life for IPv6, at as low
an operational cost as is practical, for as long as possible.
The initial "growth" curve for IPv6 won't be a true growth curve, it
will be an adoption curve.
It will have the same shape as that of a disease affecting a population:
the rate of adoption will
be N(x)(1-x) where N is a scaling factor, and x is the percentage of the
networks who are IPv6.
Once the vast majority of networks have IPv6 deployed, the curve
*should* flatten out to a rate
very close to zero.
The question is, after *that* point, the real growth curve will show up.
Wouldn't it be better to ensure that the rate of router slot
consumption, is low enough to match up
with natural router amortization and replacement periods (3-5 years)
instead of causing another
round of ISP bankruptcies?
> As for the draft/proposal itself: why try to move the bits on the right
> side (the /64 portion) when ISPs can already shove the bits on the left
> side by simply justifying more address space?
More address space (by getting new PA blocks) means more router slots
Better allocation policies means no need for router slots being eaten.
And, if you look in the details of the IETF proposal, there are examples
of benefits of scaling
when internal aggregation is not only possible (at all), but done well -
internal router slots get
used in a very conservative fashion, even for the very biggest of ISPs.
More information about the ARIN-PPML