2008-02 Moved to Review Phase (Assigning IPv6 PA to Every LIR)
PDP Number: 2008-02 Assigning IPv6 PA to Every LIR Dear Colleagues, The impact analysis for the proposal described in 2008-02 has been published and the proposal is moved to the Review Phase. If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-02.html We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
Assigning IPv6 PA to Every LIR
If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation.
Yes, go for it.
One can expect to see 4,715 new more entries on the routing system. However, all these entries would be on the minimum allocation size, so significant fragmentation/aggregation impact can be expected.
I assume the expected fragmentation aspect is due to future requests having to be made since the original assignment to the LIR was only a /32 when something larger would have been useful. Simply keeping the existing system of spacing assignments such that they can be expanded up to a /29 in future if required should avoid this problem. You could probably space assignments for larger members such that they can expand to greater than a /29 in future if needed. Regards James
* James A. T. Rice wrote:
You could probably space assignments for larger members such that they can expand to greater than a /29 in future if needed.
That was part of the proposal.
On Wed, 19 Mar 2008, Filiz Yilmaz wrote:
The impact analysis for the proposal described in 2008-02 has been published and the proposal is moved to the Review Phase.
If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation.
You can find the full proposal at:
It is not obvious how this would modify the existing IPv6 policy. As an example, I'm concerned whether these assignees would be bound by section 5.1.1b) of policy, specifically "advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet". Apart from that procedural issue, while this could be argued to be a good move from simplification point of view (less paperwork, maybe RIPE NCC could lay off 5 hostmasters as a result :-), I don't think the current allocation criteria for /32 are prohibitive for ISPs. I'd like to hear feedback on experiences to the countrary. As a result, it's not obvious which problem this is trying to solve except granting /32's to enterprises. So I'm opposed to this policy proposal. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
* Pekka Savola wrote:
I don't think the current allocation criteria for /32 are prohibitive for ISPs. I'd like to hear feedback on experiences to the countrary.
As a result, it's not obvious which problem this is trying to solve
The current procedere is not prohibitive, but requires an extra effort and mostly LIR internal approvments from the financial and legal departments as well as interaction with the company leaders directly. Technicans who want to play with or deploy IPv6 are asked: a) is this really necessary, b) who will be responsibile, c) what's the bussiness case and d) where is the ROI timetable. 2008-2 reverses the situation for the technical department.
[ Did I mention that I totally object against this proposal, well here again: I fully object against 2008-02 ] Lutz Donnerhacke wrote:
* Pekka Savola wrote:
I don't think the current allocation criteria for /32 are prohibitive for ISPs. I'd like to hear feedback on experiences to the countrary.
As a result, it's not obvious which problem this is trying to solve
The current procedere is not prohibitive, but requires an extra effort and mostly LIR internal approvments from the financial and legal departments as well as interaction with the company leaders directly.
If the company is not backing it, then they are never going to really use it. Then what is the point of providing the address space to them? So that they can play with it a bit, and then neglect it and cause issues for other ISPs? Really, we have been trying to clean up a lot of mess already, don't add even more cruft. Layer 8 issues like those should not be resolved at the RIR level, it should be resolved inside the LIR that has them. I like to see a lot of organizations doing IPv6 and try and help them out wherever I can, but if Layer 8 doesn't want it, then just forget about it, you've done your job by trying, document it properly and laugh in their faces when they come "we need it yesterday" by doing your bureaucratic trick of showing them the documentation.
Technicans who want to play with or deploy IPv6 are asked: a) is this really necessary, b) who will be responsibile, c) what's the bussiness case and d) where is the ROI timetable.
If the company is not backing it, then nobody is responsible, we can't have that. If the techies still can't describe why they need this and what the business case is, then IMNSHO they should be looking for a new job. They might also try and actually get involved in the community called "Internet Operations" (RIPE, ARIN, APNIC, NANOG etc etc etc) [Oh and yes I know how companies think about this, but if your company doesn't support it, move on, too bad, you tried, next!] Sorry, but that really is a BAD argument for even going in this direction. Currently there are already enough ISP's who have simply requested a /32, even though they have a customer base well over the 100.000 mark, which would thus mean they need much more than the /32 they get, but clearly because they are not interested at all in actually providing actual IPv6 connectivity to their customers, they didn't even look at the request form they filled in and thought "/32, that is a lot", but it is only 65.535 /48's, thus you can only serve 60k customers. Funny thing is then that people do 'complain' when some ISP gets a /20 with comments like "that is a lot", till they realize it is only a few million /48's and that the customer base of that ISP is really huge. The target for IPv6 allocations should be: 1 allocation per ISP*. If we are going to auto allocate a /32 or something else to everybody that creates a huge explosion in the allocation table, next to that, most of those prefixes don't even fit the organization, what should a multi-million customer organization do with a /32? As such it will only create a very fragmented allocation, some used, some not, many not returned, or even more fun, that they need to renumber out of it at a certain point and might want to keep it as they "can't", thus causing multiple prefixes for that ISP et voila we are back to mess we have in IPv4. Please don't let it go into that direction. Greets, Jeroen (*1) = clearly this is already 1 allocation per ISP per RIR region, seeing that several organizations have requested a /48 or a /32 at the more prominent RIRs.
I support this proposal 'cause this operation eliminates minimum one problem (for me) - IPv6 request :-))) Best regards, Dmitry Menzulskiy (DM3740-RIPE) address-policy-wg-admin@ripe.net написано 19.03.2008 17:58:00:
PDP Number: 2008-02 Assigning IPv6 PA to Every LIR
Dear Colleagues,
The impact analysis for the proposal described in 2008-02 has been published and the proposal is moved to the Review Phase.
If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2008-02.html
We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008.
Regards
Filiz Yilmaz RIPE NCC Policy Development Officer
On 19 mrt 2008, at 15:58, Filiz Yilmaz wrote:
If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation.
Although I don't see much harm in the proposal from a technical perspective, I don't expect this to have much impact in de the actual deployment. And it might even be a waist of address space, because by the time IPv6 has finally made it to the edge some of those LIR's probably don't even exist anymore, maybe causing some swamp leftovers from experiments. Anybody who want's to run IPv6 can do so by requesting an assignment, it's not that hard and we might even get some documentation which if anonymized and aggregated could give some valuable insights on where IPv6 really stands. The whole idea seems more of a political statement "it's not are fault IPv4 has ran out" as it will be a solution to what we really try to solve, the fact that IPv6 isn't rolling the way we hoped it would do. I can tell from experience this isn't the lack of address space or the procedure to get it assigned and/or routed. v6 ain't rolling because there still are some gaps on the edge, it's hard to find the 40 USD dsl-modem which runs IPv6 and does it in a way it will work on multiple aggregation platforms so you as an ISP won't get vendorlocked and the customer who wants/needs another CPE can simply buy one around the corner, knowing for sure it will work. That's where the pressure needs to be and we should focus on, RFC 4241 is a nice starting point for it. If you want to market IPv6, print some brochure and make it a nice powerpoint presentation, if you want politics and show you really care, let's show the industry can act as a whole and this week all call our favorite salesrep from our favorite vendor and ask them for the stuff _you_ need to get _your_ part working. Groet, MarcoH
If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation.
my experience with ipv6 first allocations is that they take 24 hours, start to finish. Or maybe less. All in all, it's a pretty painless procedure. And if the future of your business depends on provisioning ipv6 related services, the pain:gain ratio is very low indeed. I'm not sure what purpose 2008-02 really serves other than to remove a very small amount of (due) process. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
On 19/03/2008 15:58, "Filiz Yilmaz" <filiz@ripe.net> wrote: [...]
If this proposal reaches consensus, RIPE NCC will conduct a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 allocation.
I have some concerns with allocating people resources they did not request and might not need or want. On the whole, I think that if there is a problem with the way the RIPE NCC's processes IPv6 allocation requests, then that should be fixed. There doesn't appear to be a problem, though. Is it really likely that someone who is not prepared to use a fairly simple web page to request an IPv6 allocation will deploy the protocol if it is dropped in their lap? If an LIR gets an IPv6 allocation this way but does not want one they should be able to effortlessly reject it. I see no advantage in giving responsibilities to people that do not want them. If an LIR gets an IPv6 allocation this way and does not want it or use it, might their annual fee rise as a result? It's important not to move someone from the 'extra small' to the 'small' billing category because they received an IPv6 allocation they did not request. Regards, Leo
On 20/03/2008 17:57, "Leo Vegoda" <leo.vegoda@icann.org> wrote: [...]
If an LIR gets an IPv6 allocation this way and does not want it or use it, might their annual fee rise as a result? It's important not to move someone from the 'extra small' to the 'small' billing category because they received an IPv6 allocation they did not request.
It looks like I missed the statement about this in the analysis the RIPE NCC provided and the answer is "probably not". Leo
Hello, On Wed, Mar 19, 2008 at 03:58:00PM +0100, Filiz Yilmaz wrote:
PDP Number: 2008-02 Assigning IPv6 PA to Every LIR
I am opposing to this PDP. I have already seen that customers of a LIR announce the LIRs /32 because the LIR isnt interested in deploying IPv6. One may describe this as a (probably illegal) transfer of resources. Fulfilling the PDP will open a whole new can of worms if there arent some other prerequisites met. MfG/regards, -- Rico Gloeckner System Engineer team(ix) GmbH Suedwestpark 35 90449 Nuernberg Amtsgericht Nuernberg, HRB 18320 Geschaeftsfuehrer: Oliver Kuegow, Richard Mueller
On Mar 19, Filiz Yilmaz <filiz@ripe.net> wrote:
PDP Number: 2008-02 Assigning IPv6 PA to Every LIR I oppose this proposal on the grounds that it is already easy enough (almost automatic actually) for LIRs to receive an IPv6 allocation. I do not believe that it would remove real-world impediments to IPv6 deployment in a significant-enough number of LIRs to justify the risks associated with automatic one-size-fits-all allocations.
The eventuality of a LIR to move to a more expensive billing category as the result of an unsolicited allocation should be enough in itself to consider this proposal unacceptable. -- ciao, Marco
On Wed, Mar 19, 2008 at 03:58:00PM +0100, Filiz Yilmaz wrote:
We encourage you to send your comments to address-policy-wg@ripe.net before 16 April 2008.
I do oppose this proposal. Reasons: - No real problem solved, the allocation request procedure is trivial and doesn't usually (or even often) require support from legal folks and "company leaders" as far as I'm aware. - Possible billing category upgrades - Allocation of non-insignificant resources not requested by the LIR - Possibly insufficient allocation sizes being allocated, with limited space to grow (/29) into without renumbering. LIRs should make up their mind how much space they need _before_ requesting resources - If policy implemented, less empirical insight into how many organizations actually start to care about IPv6 (step 1: allocation assigned, step 2: announcement of prefix in BGP) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (12)
-
Daniel Roesen -
Dmitriy V Menzulskiy -
Filiz Yilmaz -
James A. T. Rice -
Jeroen Massar -
Leo Vegoda -
Lutz Donnerhacke -
Marco Hogewoning -
md＠Linux.IT -
Nick Hilliard -
Pekka Savola -
Rico Gloeckner