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

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Oct 2007 22:31:10 +0100

I thought this would be interesting reading for the working group.

Note that this is just one individual proposing a new policy, which is  
about the same thing as writing an individual submission draft in the  
IETF.

Begin forwarded message:

> From: Member Services <[email-masked]>
> Date: 22 oktober 2007 17:23:21 GMT+02:00
> To: [email-masked]
> Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction
>
> ARIN received the following policy proposal. In accordance with the  
> ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being  
> placed on
> ARIN's website.
>
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
>
>    1. Accept the proposal as a formal policy proposal as written. If  
> the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
>
>    2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The  
> AC
> will work with the author to clarify, combine or divide the  
> proposal. At
> their following meeting the AC will accept or not accept the proposal.
>
>    3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted,  
> then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
>
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
>
> In the meantime, the AC invites everyone to comment on this proposal  
> on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their  
> deliberations.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal Name: IPv6 Assignment Size Reduction
>
> Author: Brian Dickson
>
> Proposal Version: 1
>
> Submission Date: Oct 18, 2007
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> 6.5.4.1. Assignment address space size
>
> End-users are assigned an end site assignment from their LIR or ISP.  
> The
> exact size of the assignment is a local decision for the LIR or ISP to
> make, using a minimum value of a /120 (when only one subnet is
> anticipated for the end site) up to the normal maximum of /48,  
> except in
> cases of extra large end sites where a larger assignment can be  
> justified.
>
> The following guidelines may be useful (but they are only guidelines):
>
>     * /120 for a very small customer with one subnet, using static
> assignments or DHCPv6
>     * /116 for a small customer with a few subnets, using static
> assignments or DHCPv6
>     * /112 for a medium size customer with a significant total number
> of hosts and/or subnets, using static assignments and/or DHCPv6
>     * /96 for large customers
>     * /80 for very large customers, or for customers using a proposed
> modified version of V6-autoconf (which uses EUI-48 instead of EUI-64)
>     * /72 for customers with several subnets using modified V6- 
> autoconf
> (which uses EUI-48 instead of EUI-64)
>     * /64 when it is known that one and only one subnet is needed, for
> a customer that absolutely requires either traditional IPv6
> autoconfiguration, or IPv6 host Interface Identifier cryptographic
> generation
>     * /60 for sites where a mix of IPv6-autoconfiguration and other
> address assignment techiques are required
>     * /56 for very large sites
>     * /52 for very, very large sites
>     * /48 for extremely large sites
>
> For end sites to whom reverse DNS will be delegated, the LIR/ISP  
> should
> consider making an assignment on a nibble (4-bit) boundary to simplify
> reverse lookup delegation.
>
> Rationale:
>
> The intent is to provide more current guidance, to both ARIN members,
> and to ARIN staff, based on available IPv6 technology, and for the
> encouragement of efficient assignment of IPv6 address space.
>
> IPv6 supports numerous methods for address assignments to end nodes.
> Those include autoconfiguration, static assignment, and DHCPv6.
> Of those, only autoconfiguration requires use of /64 as the prefix  
> size.
>
> Efficient use of IPv6 space should discourage widespread use of /64's,
> or for use of autoconfiguration as the sole justification for
> allocations of large address space.
>
> In particular, the effective lifetime of PA assignments to ISPs/ 
> LIRs, is
> largely a factor of internal aggregation, and the size of end  
> assignments.
>
> Rather than meeting ISP needs by assigning very large IPv6 PA  
> blocks, it
> would be wiser to encourage assignments that to not significantly  
> use up
> available PA space for the ISP, even for very large customers.
>
> The overall intent is to minimize the need for any PA recipient, to
> return to ARIN for subsequent assignments, thus reducing the need for
> additional globally routable prefixes using up slots in routers in the
> DFZ - something that affects the long-term ability for all ISPs to
> continue to scale in a cost-effective manner.
>
> Timetable for implementation: Immediate
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List ([email-masked]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at [email-masked] if you experience any issues.

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Oct 2007 23:05:21 +1030

On Mon, 29 Oct 2007 22:31:10 +0100

> I thought this would be interesting reading for the working group.

I think the best thing to do is ignore it. If it gets any traction in
ARIN, then we might have to do something.

(I'm embarrassed to be listed in the acknowledgements section of the
related draft, because it can imply I agree with it - and my position is
the complete opposite - I'm even fairly strongly anti-/56.)

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 30 Oct 2007 12:52:54 +0000

> the complete opposite - I'm even fairly strongly anti-/56.)

And the even funnier portion of that draft is that he (Brian Dickson) is
basically asking the IETF (first, but there it was already heavily
commented on in a negative way), now the RIRs to change the policies
they have in place.

He basically wants to change the lower /64 and enable a different EUI-64
concept (thus not remove it, which would really be silly).

The main reason he has for this is that ISP's are now getting /32's and
when they *misplan* their address space they would go back to the RIR
and get more address space, which, according to him, would lead to the
point that multiple de-aggregated prefixes would leak into the routing
tables.

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
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

So one has to wonder, if they already got their own de-aggregated
prefixes, why do they want to block others from doing so.

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.

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?

A proposal for changing the /48 boundary for *home users* to /56 though
might at a certain point be a good idea. Companies should be getting a
/48 IMHO.

Greets,
 Jeroen

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Oct 2007 10:58:28 -0400

> 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
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:  [email-masked]

RNOCHandle: JAB328-ARIN
RNOCName:   Abley, Joe
RNOCPhone:  +1-519-670-9327
RNOCEmail:  [email-masked]

RTechHandle: JAB328-ARIN
RTechName:   Abley, Joe
RTechPhone:  +1-519-670-9327
RTechEmail:  [email-masked]

OrgTechHandle: JAB328-ARIN
OrgTechName:   Abley, Joe
OrgTechPhone:  +1-519-670-9327
OrgTechEmail:  [email-masked]

# 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:        [email-masked] 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:        [email-masked] 20070921
changed:        [email-masked] 20070922
source:         RIPE

These are all Direct Assignments, and are anycast for DNS services. It 
even says so right there.
> 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.)
> misplanned how much space they will need. Most ISPs will do fine with a
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?
> 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

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 30 Oct 2007 15:27:35 +0000

> Uh, Jeroen, the affiliation with companies, as you well know, is

If you don't want to be seen as speaking as your company then don't use
your companies email address and also do not state your company
affiliation in the documents you submit.

Clearly you do seem to answer for that same company without taking of
hats as such the only conclusion that I can make is that you are
actually still speaking for that company. I really can't see it any
differently.

> base, in the realm of ad-hominem attacks - something specifically
> against the mailing list charter.

Why is that off-base? It clearly shows that not even your own company
supports your proposal. Also where else would one raise that issue?

As for calling everything which is a argument against your proposals
"ad-hominem" attacks, please try to come up with something else.
I know it is fun to try and discredit people, but that really won't
scare me off in any way.

That I am raising this issue directly to you should be seen as being
nice from your end. As a lot of other people are also saying similar
things but are not able to say so. 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.

> of numerous TLDs (Top Level Domains), such as ".org", ".info", ".mobi",

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?

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?

Now if you where really trying to make a good stance on your proposed
changes with which you are requesting to change how IPv6 works in every
host around the world, you might want to start working on it a little
bit closer at home.

Also, if you are really trying to propose those changes to the various
communities and are set on pushing them through and lowering the amount
of routes in the routing tables, why did you not ask for a single /128
as that is what you need for that purpose, nothing more, nothing less.

> If you had bothered to look at the registrations, or IRR, or anywhere,

As you clearly do not know I am one of the few people who look at every
registration made. And they are not in any IRR yet, not at least in the
ones I know of, thus can you care to share which one it actually is in?

They also only just now popped up in the stats file thus finding them
"anywhere else" is not possible.

> Even the web site www.afilias.info, makes it very clear we do DNS

And? There are a lot of companies doing exactly that. Still they only
requested a single /48 for that or are using PA space.

> E.g. Take a look at the *previous* ARIN assignment:
[..]

Again, why do you need so many disjunct blocks?

Especially in the light that your draft mentions that it is meant to
lower the amount of routes that other companies will be announcing.

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?

> see someone else polluting, it is okay to pollute"?

I never stated that anywhere. I wonder why you think I stated that.
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?

But as you can't seem to agree with yourself on your own statements, it
is not so odd that you can't seem to understand what I am stating.

> DNS TLD needs to operate independently.

And a lot of companies will, at one point, want to have separate blocks
for similar reasons. But your draft goes against this. And clearly you
don't even agree with yourself.

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?

> 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?

If you are so confident about the proposed /120 for home user, why not
request a /120 for your DNS servers?

> IMHO. The Internet is not usable without them.)

A lot of people can live without .cn but would require
google.com/cnn.com/playboy.com/kink.com to work. As such do these sites
then suddenly also require special treatment because they are unusable
otherwise?

Also, I require my own private home site to be globally reachable. As
such, can I also get a /48 + router slot for that?

See the issue you are trying to debate while not keeping up on that same
issue yourself?

[..]
> round of ISP bankruptcies?

Why not start doing the lower router slot consumption rate with yourself
or at least trying to convince your own company to do so?

> More address space (by getting new PA blocks) means more router slots

You clearly do not understand the current way that blocks are being
allocated. They justify address space need as predicted for several
years in the future, and they have space to grow on the RIR side. As
such when the do run out of a /32 they can grow it to a /29.

One last thing to summarize it all: Eat your own dog food.

Greets,
 Jeroen

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Oct 2007 12:10:27 -0400

Jeroen Massar wrote:
> I am not coming forward as any
I do not care what you think of what I am doing, or what my employer is 
doing.
Period.

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

Would you care to instantiate those concerns, and elaborate on why you 
think they are a problem?
> 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
> those? If you are going to anycast them, why do you need more than a
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.

> 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).
> See the big problem with what you are proposing and what you are
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 
years.

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.
> why again did you request multiple blocks and are you going to pollute
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 thus you request and receive:
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.
> 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

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 30 Oct 2007 11:39:28 -0500

Thus spake "Mark Smith" <[email-masked]>
> ARIN, then we might have to do something.

It doesn't appear to have much support at the present time.  OTOH, those of 
us active in the ARIN community would appreciate pointers to RFCs that say 
this idea is or isn't valid so that we have as much guidance from the IETF 
as possible.  So far, we've unearthed a bunch of RFCs that make 
recommendations, many of which obsolete or contradict each other and none of 
which seem to give absolute rules.  This was, I believe, the motivation for 
Michael Dillon's recent message with the subject "An example of what is 
wrong with the IETF's IPv6 documentation".  It's hard for the RIRs to figure 
out what exactly what the IETF's authoritative direction is, and we do try 
to follow that when it makes reasonable sense.

> the complete opposite - I'm even fairly strongly anti-/56.)

If you object to it, please ask the author to remove you.  I agree that an 
acknowledgement implies support; a reference would not.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 30 Oct 2007 16:51:47 +0000

> I do not care what you think of what I am doing, or what my employer is

That you don't care actually about doing one thing yourself (PI-holders)
while trying to restrict what others do (PA-holders) is apparent.

You do realize that the PA-holders are the ones who are already being
nice to the routing table slots by requesting one big block and thus
only taking up one slot. While the PI holders are the ones requesting
small blocks do you?

> think they are a problem?

I've already gone into detail about this on the IETF list. Clearly you
already forgotten about those. I can only assume that has to do with
your no-care factor.

[..]
> PA space is blocks given to ISPs to assign to their customers.

Who are thus already aggregating all the blocks for their several
millions of customers and end-users.

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

Because those people are already special you would say? And thus they
need to be more special?

> 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 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.

> - deaggregating PA blocks is at best naive and at worst anti-social

Filters can easily resolve that problem. No need to change policies here.

> blocks (by whatever rationale is generally accepted), *should* use PA or

They are already.

What is your point in writing the above, unless you want to try and
explain that you understand the concepts called PI and PA?

> Because each TLD needs to be anycast from a topologically unique *set*

But why?

> 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?

> afore-mentioned three- and four-letter TLDs.

But again, why. That you are going to do it is clear. But that does not
answer the WHY question.

Why can't those servers, which will all be operated by one single
instance, not be simply using 1 single anycast block.

> There is one "root". Each of those 13 instances of "root" are anycast,

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 minimum number of nameservers for any zone is two.

Again:
 - why do these TLD's each need a *separate* nameserver?
 - why can't they simply share the same nameserver set?
 - are they going to be hosted with different physical links?

etc. You are simply trying to make an argument on something you want to
happen. Not on something that is actually going to happen. You are
simply making yourself special, but you are not special.

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

As I mention in the paragraph above there is NOTHING special about a TLD
server. They are just a subdomain of the root. Just like google.com is,
just like disney.com is.

That some people have made them look special is something completely
different. They still are not.

> They are very much *not* DNS hosting. (I humbly suggest you review the

"Please google for this" "Please check the archives of that"

For what part? What is the actual explanation you are trying to refer
to. Can you at least try to come up with a URL that actually shows the
information you are referring to instead of trying to state "hey clearly
you don't know, go read a book about it"?

> I see that you can't make the distinction between PA and PI blocks.

Thank you, but I very well understand the distinction between the two.

> is specifically because nobody knows who will be a lot bigger in 5 or 10

And? Just if a company getting a PI block might not be bigger in 5 or 10
years? Ebay got a /41, are you saying that they might not need more
address space in 10 years? Or maybe a better one, Northrup Grumman,
Force10 , Seagate and the rest of the "PI Blocks" in the ARIN list.
They of course will never need more address space than that. Or for that
matter have the need to get an additional /48 because they open up an
office on the other side of the country/world and also require PI space
in that place, thus creating a need for 2 slots. Something that you are
willing to want to avoid for the PA-holders but clearly don't want to
avoid for the PI-holders.

(I'll remind you that I maintain, as a hobby and for the fun of it, that
little list at http://www.sixxs.net/tools/grh/dfp/arin/ which contain
all of these, but of course I don't understand the difference between PI
and PA....)

> or will be started in the next 5-10 years) will be big later.

Does it matter? They get a /32 per default now, that can grow to a /29.
If they really get bigger, does it matter that they occupy another
routing slot for another million people they are serving by that single
slot?

You are using a routing slot per nameserver, that is apparently 2 slots
per TLD. Now who is being wasteful? Them or you?

> 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.

And you can assume this for PI apparently. I like to see your crystal
ball please. Seriously as mentioned, if they grow, they will grow, they
will be able to justify their address space and they can keep on
growing. There will be no problem there. Also if an ISP has got a /32
grows it to a /29, and then gets a /20 they can always very slowly
renumber the /29 into the /20 and returning the /29.

But I really don't see why you need to force those PA holders to force
their customers to do /120's when you are abusing multiple /48's and
larger blocks for 1 single box.

> It is also fluid, changing as circumstances require, and on a per-prefix

Is it really needed to serve .mobi over a different place than .info?
Wow, I really would like to see that document with the arguments for that.

> as a "set". These are in fact all used (and registered) as discrete /48's.

So you are going to announce 20 or so /48's while only using 1 IP in
each /48. And then you are complaining about ISP's who *might* one day
come back for more address space for a couple of million of their
customers!?

> (Trust me, we do not need more than that.)

Then why did you not propose a policy change in that direction?

> consideration of its size.

But you are complaining about the PA blocks. Funny.

> consumed, in an unpredictable fashion.

And why is that an issue?

> have much more predictable usage.

Again, WHY is that?

Stating things is easy, but please add an explanation about why you are
stating it.

> Filet mignon, or chateau-briand on occassion. :-)

You might try treating the internet like you treat your dogs. Equals.

Greets,
 Jeroen

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Oct 2007 13:12:00 -0400

Stephen Sprunk wrote:
> Thus spake "Mark Smith" 
> <[email-masked]>
>
> If you object to it, please ask the author to remove you.  I agree 
> that an acknowledgement implies support; a reference would not.
If I receive a request from someone to remove their name, I will, certainly.

As to why Mark is listed (as well as a few others who may feel similarly)?

Simple. Those who challenge us or question our work, make that work 
stronger.

So, even those who do not agree with me, if they helped me produce what 
I think is better work, deserve credit.

(Mark's help was in answering questions about usage of autoconfiguration 
in IPv6, and on the history of EUI-64 thread on [email-masked]).

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Oct 2007 14:41:16 -0400

> 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.
> 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*
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.)
> 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.

> 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".

> 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.)

> 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.
> Stating things is easy, but please add an explanation about why you are
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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2007 09:45:08 +1300

On 2007-10-31 05:39, Stephen Sprunk wrote:
> It doesn't appear to have much support at the present time.  OTOH, those 
> of us active in the ARIN community would appreciate pointers to RFCs 
> that say this idea is or isn't valid so that we have as much guidance 
> from the IETF as possible.  

I don't think there is anything that black and white. I think
the best discussion of the issues is in
http://tools.ietf.org/id/draft-narten-ipv6-3177bis-48boundary-02.txt
which is unfortunately expired. Maybe its authors would care to
update it?

IMNSHO Brian Dickson's case doesn't hold water. If ISPs are using
careless allocation techniques and thereby wasting space, I don't think
that should be fixed by depriving IPv6 users of their normal /48 or
possibly /56 assignments for small sites. We didn't expand the address
space to allow ISPs to become sloppy at the expense of users. We expanded
it to relieve pressure on both ISPs and users.

Let's not forget basics. /48 is 65536 times bigger than the raw IPv4
address space. Just how *bad* at allocation do we have to be to run
out of /48s???

    Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2007 07:28:05 +1030

On Tue, 30 Oct 2007 12:52:54 +0000

> > the complete opposite - I'm even fairly strongly anti-/56.)
<snip>
> might at a certain point be a good idea. Companies should be getting a

(Note to ARIN people who might receive this, below is written for the
V6OPS list, which is where this issue was brought up. I'm not addressing ARIN
policy, and I'm not effected by it either, as I'm in the APNIC region. Thanks.)

As an operator, my objection to /56 is that I like the simplicity of
being able to always assume an end customer has a /48, regardless of
what type of customer they are. The moment there are /48s or /56s, that
means every single time I'm talking about customer address space, I'd
have make sure or be sure it's clear to the other person or people that
it's a /48 or a /56, meaning that every time I discuss it, I have to
state it. It's a small cost, but one repeated many many times. It also
creates an opportunity for error. /48s everywhere means one less thing
to break.

If customers were to get a /56, I'd probably be reserving the /48
that the /56 falls within to allow for that customer to grow without
having to renumber. At some point in the future they might call me up
and say I want to grow my /56, and I'd be saying, just shorten your
prefix length. I figure since I'd be reserving the /48 for them anyway,
I can even eliminate that cost of dealing with that query, and give
them the /48 from the outset. I should never hear from the again, at
least about addressing issues.

I'm fairly strongly against /56s just because fundamentally it is extra
complexity for which I can't see much practical benefit. I'm
not absolutely against it though - it's something I'd compromise on
because in the big picture, the increased complexity costs aren't all
that significant, and if, over time, it helps people get used to giving
enough address space for convenience, not for necessary funcationality,
then I'll wear those costs.

More than two boundaries though is something I'm absolutely against.
That's unnecessary complexity.

Regards,
Mark.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Oct 2007 17:53:58 -0400

Brian E Carpenter wrote:
>> It doesn't appear to have much support at the present time.  OTOH, 
>> those of us active in the ARIN community would appreciate pointers to 
>> RFCs that say this idea is or isn't valid so that we have as much 
>> guidance from the IETF as possible.  
>
Thanks for the pointer, that's a well balanced summary.

There are a few salient points in that however, that I think should be 
emphasized.
(I'll try to avoid context issues, while balancing the need to keep 
thing brief.)

   [...] A key
   goal, however, is to avoid the need for a site to renumber into a
   smaller number of subnet bits when adding a new prefix. This could be
   achieved, for instance, by having it be easy for an end site to
   obtain an address block of the same size (or larger) as any existing
   assignments it already has.

The main thing is finding some way to provide assurances to end-sites, 
that their subnetting plan,
will survive renumbering. This is something the RIRs could do with 
policy, IMHO. Recommend
to ISPs that they accept customer requests that are consistent with 
current policy at the RIR, and
which were approved by previous ISPs.

And, an observation here is, the likelihood of a new ISP giving a site a 
prefix compatible with their
existing usage, is *greater* when their existing usage is a *longer* prefix.

This itself is an argument in *favor* of permitting assignments of 
longer prefixes.

   [...] Thus, it
   remains highly desirable to provide end sites with enough space (on
   both initial and subsequent assignments) to last several years.
   Fortunately, this goal can be achieved in a number of ways and does
   not require that all end sites receive the same default size
   assignment.

And my observation is - no one knows better than the end site what its 
needs for several years will be.
Having the end site suggest an allocation, and how it will be used, is 
the most sensible approach.

Making a larger number of choices available for the end site to select 
from, encourages thoughtful
approaches to networking plan.

> address space. Just how *bad* at allocation do we have to be to run

I've never argued that end sites are likely to return to ISPs for 
address space.

I have, however, argued that ISPs returning to RIRs for PA blocks, is 
bad for the Internet.

And bad for *other* ISPs.

It's like "Other People's Money" - easier to spend than your own. When 
banks go under,
it's the bank's customers, not their shareholders, who tend to suffer most.

When ISPs use up router slots, it's mostly *other* ISPs they hurt, i.e. 
their competitors.

The ones who have the most to lose, are the ones most likely to behave well.
(It is similar to the nuclear doctrine of Mutual Assured Destruction. 
Nobody wins.)

It's the ISPs whose equipment *isn't* in jeopardy, who are more likely 
to behave irresponsibly.

In fact, behaving badly is actually rewarded, by reducing competition.

Avoiding repeat PA assignments to ISPs, is the *primary* motivation for 
the proposals, both at the IETF (6man) and ARIN (ppml).

Brian

---

From: David Conrad <[email-masked]>
Date: Tue, 30 Oct 2007 17:16:05 -0700

> I have, however, argued that ISPs returning to RIRs for PA blocks, is

Only if those new PA blocks can't be aggregated.

> the proposals, both at the IETF (6man) and ARIN (ppml).

The simplest way to do reduce the impact of multiple PA assignments would be
for the RIRs to assign address space in a sparse fashion such that
additional allocations could be done by simply subtracting a bit from the
allocated prefix length.  In fact, the RIRs promised to do this when the
/12s were allocated by IANA (last I checked, however, only APNIC was doing
it).

Regards,
-drc

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 30 Oct 2007 21:57:56 -0500

Thus spake "David Conrad" <[email-masked]>
> Only if those new PA blocks can't be aggregated.

... and only if there's a non-trivial number of them.

Realistically, if LIRs are handing out /48s (or /56s, grr) to every 
customer, there's only a handful in each region that would run out of space 
in a /32 and would need to come back for more -- which was the point, IIRC. 
Plus, those are the exact same folks that are asking for (and getting) more 
than a /32 to start with.

>> Avoiding repeat PA assignments to ISPs, is the *primary*
>> motivation for the proposals, both at the IETF (6man) and ARIN
>> (ppml).
>
> The simplest way to do reduce the impact of multiple PA assignments
> would be for the RIRs to assign address space in a sparse fashion
> such that additional allocations could be done by simply subtracting
> a bit from the allocated prefix length.  In fact, the RIRs promised to
> do this when the /12s were allocated by IANA (last I checked,
> however, only APNIC was doing it).

Yes, allocating via bisection would help with that quite a bit.  Currently, 
it appears ARIN is allocating /32s out of a reserved /29 for each LIR, which 
allows 3 bits of growth for each before a second prefix hits the DFZ.  That 
doesn't seem to be enough at first glance.

However, the few mega-ISPs out there are asking for blocks larger than a /32 
(e.g. /27 and /29), and those larger blocks appear to be coming out of 
reserved /21s (in ARIN's region).  That's a lot of bits for growth for the 
folks that indicate they don't expect a /32 to be sufficient in the long 
run.  If that still turns out to be insufficient, I'm not so worried about 
AT&T, VZB, et al announcing two or three aggregates as I am them announcing 
hundreds to thousands of intentional (e.g. TE) deaggregates.

Are we trying to solve the right problem here?

S

---

From: Steve Bertrand <[email-masked]>
Date: Wed, 31 Oct 2007 08:17:33 -0400

>> "The following guidelines may be useful (but they are only guidelines)"
>>
> These specific guidelines, as either guidelines or rules, in the
> context of IPv6's dramatically larger address space, compared to
> IPv4's, are rediculous.
> 
> My concern about suggested guidelines like these are that people who
> are stuck in an IPv4 "address space is precious" mindset will grab onto
> them and then make IPv6 significantly harder and more costly to manage and
> deploy than it was designed to be. Letting that happen would be doing a great
> disservice to the future users of the IPv6 Internet.

I agree. It's taken me quite some time and several people reminding me
to free myself of the IPv4 way of doing things due to the lack of number
space. Since I've been able to do that, it doesn't make sense to go back
to that way of thinking.

Now, I have no doubt whatsoever that there are architects and engineers
out there where these particular suggested guidelines will make sense.
However, one would think that in most situations, having 10 or so
different addressing block sizes will make it a nightmare to implement,
document, maintain and in particular, move a clients PA space about the
network.

I'm not particularly arguing against the idea as it will make sense to
some, I just don't agree with it being implemented into policy. I'd much
rather see something like this in a draft BCP RFC or similar. I feel
that people associate policy with rules, and even though it's clearly
documented in the policy proposal that it's just a set of guidelines, it
will make murky the current actual policy of the 16-bit boundary rules.

Steve

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2007 20:17:39 +1030

On Tue, 30 Oct 2007 18:37:17 -0400 (EDT)

<snip>

> This thread started with someone proposing a 'policy' as to how an ISP
> slice up their address space to assign to clients. One of the first
> few sentences of said policy proposal was thus:
> 

You're right, guidelines aren't hard and fast rules, but they are
supposed to be "if you don't know any better, or don't have a specific
constraint that you're aware of, then if you follow these statements,
the results should cater to the majority of cases, and you won't have
any significant and unexpected problems." In other words, they're
supposed to be realistic and considered recommendations, applyable to
most and the majority of common situations.

> Now, I will be happy when someone can explain how this should not be
> drafted into a Best Common Practice or other similar document instead
> of a proposal for policy.
> 
> Two issues I have here (the way I see it):
> 
> - guidelines, no matter how tightly written can not be enforced as
> policy, as they are just that...guidelines
> 
> - if a policy is 'enforced' on me, I am going to squeeze the
> 'guidelines' to the limit as best I see fit
> 
> Is there not too much gray area when composing a draft policy that
> even includes the word guidelines?
> 
> An ISP no matter what their size will be directed by the path of least
> resistance if there are only 'guidelines' in place. This is a recipe
> for disaster.
> 
> What works for one will not work for all, and the term 'guidelines' in
> a policy proposal should sidetrack this entire conversation to
> something worthy of a policy proposal that we can perhaps adapt before
> more people turn to IPv6.
> 
> DNS infrastructure, the assignment of blocks to operate said
> infrastructure for .tld's and the persecution of persons for
> mentioning they should not be mentioned in a draft proposal do nothing
> for the people who are counting on the more experienced people here,
> and the policy they help create. (I'm speaking for myself, as someone
> who follows ARIN PPML to the best of my ability, with the resources I
> have).
> 
> 'Guidelines' should not be introduced at all into how an ISP should
> assign blocks of IP's to their clients via policy. If policy changes,
> it should be documented in a way that is clear, concise and followed
> as closely by ARIN as possible to the letter.
> 
> Put guidelines into a BCP. Put enforcible rules into policy. No matter
> what, if even a policy is too convoluted, too ambiguous or hard to
> work with, it won't be followed anyway.
> 
> Steve
>