[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: [ppml] Policy Proposal: IPv6 Assignment Size Reduction
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:
2001:500:16::/47
2001:500:18::/45
2001:500:20::/45
2001:500:28::/46
2001:500:2c::/48
Uh, Jeroen, the affiliation with companies, as you well know, is
informative only.
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
charter.
*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
registries.
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.
OrgID: ACC-308
Address: 4141 Yonge Street
Address: Suite 204
City: Toronto
StateProv: ON
PostalCode: M2P-2A8
Country: CA
NetRange: 2001:0500:0006:0000:0000:0000:0000:0000 -
2001:0500:000F:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR: 2001:0500:0006:0000:0000:0000:0000:0000/47,
2001:0500:0008:0000:0000:0000:0000:0000/45
NetName: AFILIAS-NET2
NetHandle: NET6-2001-500-6-1
Parent: NET6-2001-400-0
NetType: Direct Assignment
NameServer: NS1.AMS1.AFILIAS-NST.INFO
NameServer: NS1.MIA1.AFILIAS-NST.INFO
NameServer: NS1.SEA1.AFILIAS-NST.INFO
NameServer: NS1.YYZ1.AFILIAS-NST.INFO
Comment:
RegDate: 2006-10-19
Updated: 2007-09-26
RAbuseHandle: JAB328-ARIN
RAbuseName: Abley, Joe
RAbusePhone: +1-519-670-9327
RAbuseEmail: jabley@ca.afilias.info
RNOCHandle: JAB328-ARIN
RNOCName: Abley, Joe
RNOCPhone: +1-519-670-9327
RNOCEmail: jabley@ca.afilias.info
RTechHandle: JAB328-ARIN
RTechName: Abley, Joe
RTechPhone: +1-519-670-9327
RTechEmail: jabley@ca.afilias.info
OrgTechHandle: JAB328-ARIN
OrgTechName: Abley, Joe
OrgTechPhone: +1-519-670-9327
OrgTechEmail: jabley@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::
route6: 2001:500:E::/48
descr: Afilias Canada, Corp.
origin: AS12041
mnt-by: MAINT-AFILIAS
changed: jabley@ca.afilias.info 20061109
source: RIPE
mail:bind-9.4.1 (bash)$ whois -h whois.ra.net AS12041
aut-num: AS12041
as-name: AFILIAS-NST
descr: Afilias Limited
descr: ------------------------------------------
descr: Prefixes announced from this origin AS are
descr: anycast from several places. See RFC 4787.
descr: ------------------------------------------
admin-c: JA856-RIPE
tech-c: JA856-RIPE
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
mnt-by: MAINT-AFILIAS
changed: jabley@ca.afilias.info 20070921
changed: jabley@ca.afilias.info 20070922
source: RIPE
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
being eaten.
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.
Brian