[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Brian Dickson wrote:
> 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
> doing.
> Period.

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?

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

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.

[..]
> I am advocating policies applicable only to PA space.
> 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?

> We use /48's because they are announced directly to the DFZ, and the
> 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.

> - PA blocks are intended to be announced only as the PA block
> - deaggregating PA blocks is at best naive and at worst anti-social

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

> - multihomed networks who are sufficiently justified in getting PI
> blocks (by whatever rationale is generally accepted), *should* use PA or
> PI blocks

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?

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

But why?

> If you have two TLDs whose topology of anycast is different, they must,
> 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?

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

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.

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


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

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
> archives of dnsop).

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


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

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


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

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

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

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?

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

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.

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

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.

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

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

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

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

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

But you are complaining about the PA blocks. Funny.

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

And why is that an issue?

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

Again, WHY is that?

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

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

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

Greets,
 Jeroen

Attachment: signature.asc
Description: OpenPGP digital signature