[ppml] Fwd: 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 at ca.afilias.info

RNOCHandle: JAB328-ARIN
RNOCName:   Abley, Joe
RNOCPhone:  +1-519-670-9327
RNOCEmail:  jabley at ca.afilias.info

RTechHandle: JAB328-ARIN
RTechName:   Abley, Joe
RTechPhone:  +1-519-670-9327
RTechEmail:  jabley at ca.afilias.info

OrgTechHandle: JAB328-ARIN
OrgTechName:   Abley, Joe
OrgTechPhone:  +1-519-670-9327
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::
route6:         2001:500:E::/48
descr:          Afilias Canada, Corp.
origin:         AS12041
mnt-by:         MAINT-AFILIAS
changed:        jabley at 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 at ca.afilias.info 20070921
changed:        jabley at 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