[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
Thomas,
Comments are below:
From: Thomas Narten <narten@us.ibm.com>
Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment
>>Global Policy
I wasn't at the RIPE meeting, but I do have at least one big concern
based on what I heard.
> To be precise, I proposed the following:
> - any LIR that is established (has done all the paperwork, paid their
> fees, and whatnot) and can document the need for one IPv6 address
> can get a /32. No further justification required.
Does this mean end sites, those that are not transit providers become
eligible for a /32? In other words, what is to prevent a land grab on
what will largely be perceived as PI IPv6 address blocks? (I heard
from someone who was at the meeting that the answer was a clear yes,
end sites will be eligible.)
I think we would be sending entirely the wrong message if end sites
are able to get /32s.
I was at the RIPE meeting. The consensus was that anyone willing
to become an LIR and pay the fees could get a /32. Certainly
within RIPE there are requirements for becoming an LIR, but
I don't believe those requirements distinguish between being
and end site or whatever. We certainly discussed this at the
meeting. There is nothing to prevent an end user from becoming
an LIR and getting a /32.
Note also that my main concern has much less to do with utilization or
how much address space we have (we do have a lot). It has much more to
do with having registry policies that are supportive of aggregation of
routing information in the long term. This will only happen if most
end sites get address space from their providers.
Allowing end sites to get big allocations now, will cause nothing but
problems later. It risks replaying some of the bad history of IPv4.
That's right.
> - to avoid a horrible mistake, every region is permitted to allow only
> assigment of 2000 /32s per region. So the maximum wastage is 6000
> /32s (out of 500 million /32s in the 1/8th of the space we're talking
> about), and 6000 additional routes.
> After that, we're going to reconsider policy.
And once we have 6000 such /32s allocated, then what? We replay the
haves vs. the have nots? Won't there be a lot of pressure then to
continue giving out /32s freely, since current router technology
supports more than 6K routes, etc.? What makes you think we'll be able
to put in more conservative policies at this point?
This is definitely an issue. One that folks at the meeting didn't
want to hear
> - why are we putting criteria there? To keep out "some that we do not
> want". Conservation is not an issue. Routing table growth might
> be influenced by this, or might be not, we don't know.
Having RIR policies that make it harder to have good aggregatability
of routes should not be done rashly. It is far easier to take steps
now that limit potential problems, than try to reverse poor decisions
after the fact.
Yup.
> - do we want major national research networks connecting something like
> "50 universities"? YES
So, can we come up with alternate criteria that support giving /32s to
such entities that doesn't also allow just anyone to get a /32? This
desire seems reasonable to me. But the proposed solution seems to gone
way beyond what was needed, and has some real down sides.
That was attempted to be proposed. I'd like to see this group come
up with something more than just pay the fee and get a block. A portable
no aggregatable block. Further, the way blocks are being handed out now
they aren't geographically aggregatable either. So each registry just peels
off the next block. There aren't blocks per registry.
> Who are the ones that we want to keep out anyway? Why? To achieve
what?
End sites. If every end site gets its own /32, we will have another
routing disaster. So much for IPv6 learning from the IPv4 experience.
Well the argument is that they'll never come back for more. This means
(believe me this isn't my argument) that the routing table should
be smaller because everyone will only have one prefix. There are
only as many multi-homed sites as there are ASNs, right? Anyway,
this is an argument that I have heard proposed. Please remember
it isn't my argument.
----CJ
-
- This list (global-v6) is handled by majordomo@lists.apnic.net