2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment)
PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-04.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 5 May 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC
PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment
Dear Colleagues,
A new RIPE Policy Proposal has been made and is now available for discussion.
I think I have a feeling what the meaning of this proposal should be, but the actual words used to write it are saying something completely different for me. For a start: I can't really tell if the new policy text should replace the old IPv4 address allocation and assignment policy. The new policy only talks about address space given out to ISPs for transition techniques, so I assume that an ISP with a lot of free (i.e. not assigned/unused) IPv4 address space can also get another allocation under this policy? Then the minimum size of /27. Obviously it would be a brilliant test to see if routers will be able to hold all the IPv6 PI prefixes that will come to life once we allow them to be handed out. And it would be a very handy way to tear down the v4 internet, so it's in full compliance with some IPv6 implementation plans. But to be serious for a minute: if all those /27 would be announced a IPv4 full table would nearly triple in size (or in other words: all those /27 are twice the size of a full IPv4 table today). This can't possibly end well, so I'm not in favor for this proposal in its current form. Marcus
Marcus Stoegbauer wrote:
But to be serious for a minute: if all those /27 would be announced a IPv4 full table would nearly triple in size (or in other words: all those /27 are twice the size of a full IPv4 table today). This can't possibly end well, so I'm not in favor for this proposal in its current form.
When the price for IPv4 will be much higher, we will see even a lot of /32 in the table ;) Seriously, in that time hardware will become capable of carrying that easy. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Tue, 7 Apr 2009, Max Tulyev wrote:
Seriously, in that time hardware will become capable of carrying that easy.
What timeframe is that? 10 years ago, the state of the art core routing platforms were capable of a few hundreds of thousands of FIB routes, today it seems to be 1-2M for the more expensive platforms. If you're talking about 2020 then by then 3-4M might be working well, but you'd still spend a lot more than than needed in converging a network with that many prefixes. For the good of the Internet, let's not put more prefixes in DFZ than needed. -- Mikael Abrahamsson email: swmike@swm.pp.se
I hear from Juniper they was capable of 5M routes an year ago. I think, 2020 year hardware should be capable about 500M prefixes easy. Mikael Abrahamsson wrote:
On Tue, 7 Apr 2009, Max Tulyev wrote:
Seriously, in that time hardware will become capable of carrying that easy.
What timeframe is that?
10 years ago, the state of the art core routing platforms were capable of a few hundreds of thousands of FIB routes, today it seems to be 1-2M for the more expensive platforms. If you're talking about 2020 then by then 3-4M might be working well, but you'd still spend a lot more than than needed in converging a network with that many prefixes.
For the good of the Internet, let's not put more prefixes in DFZ than needed.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
I hear from Juniper they was capable of 5M routes an year ago.
I think, 2020 year hardware should be capable about 500M prefixes easy. You keep missing the point. Even if we junk the Sup720-3BXL then the
On Apr 07, Max Tulyev <president@ukraine.su> wrote: problem will be processing the updates without resorting again to dampening. -- ciao, Marco
On Tue, 7 Apr 2009, Max Tulyev wrote:
I hear from Juniper they was capable of 5M routes an year ago.
Yes, 5M routes in RIB, not in FIB. State of the art platforms today do 1-2M FIB entries.
I think, 2020 year hardware should be capable about 500M prefixes easy.
Why do you think so? If we increased ten times in the last ten years, why would we increase hundreds of times the next ten years? -- Mikael Abrahamsson email: swmike@swm.pp.se
I hear from Juniper they was capable of 5M routes an year ago.
as we say in my family, "do i smell cows?" randy
But to be serious for a minute: if all those /27 would be announced a IPv4 full table would nearly triple in size
this policy is analogous to one in apnic, except apnic's says "the then current minimum allocation." and we expect that, some day, it will be sub-/24. remember the goal, multi-homed sites using nat64 etc. so the size of the routing table will be propotional to multi-homing, a fact of life that this proposal will not significantly change. randy
* Filiz Yilmaz <filiz@ripe.net> [2009-04-07 12:48]:
PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment
Dear Colleagues,
A new RIPE Policy Proposal has been made and is now available for discussion.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2009-04.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 5 May 2009.
Hi, if I understand this proposal correctly, you want to give a /27 to an LIR or end user so that they can do NAT-PT or something like that? First: It won't work. Most people I know filter prefixes smaller than /24 in the DFZ. They will not see these allocations. You can't assume that they will change their filters for this. I would estimate that most of them won't. Many can't do this because it will not fit in their RIB/FIB. So if you do this you would have to give out a /24 at least. Second: We do want to facilitate deployment of IPv6. I think this proposal could be counterproductive. You're splitting up the remaining space in smaller peaces so that more people can use IPv4 for a longer timespan. And if you have to give out /24s you can bet that people will use it for other things besides NAT-PT etc. Third: Is it necessary? You already have to demonstrate a need for address space if you want a new allocation. If an LIR already has an allocation I assume that they can spare an /27 for IPv6 transition. If you have a new LIR you allocate them a /21 if they can demonstrate the need for it, no change there. Kind Regards, Sebastian -- GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Hi All, I think it is a good proposal, but only with IPv6 PI support. Now a number of our IPv4 PI clients wants IPv6 PI, but can't get it... Filiz Yilmaz wrote:
PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment
Dear Colleagues,
A new RIPE Policy Proposal has been made and is now available for discussion.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2009-04.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 5 May 2009.
Regards
Filiz Yilmaz Policy Development Officer RIPE NCC
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On 7 Apr 2009, at 11:46, Filiz Yilmaz wrote:
I don't know if it's entirely fair and just to hold v4 to ransom in order to drive v6 adoption, but as someone who has done v6 rollouts on his own network already, and is paid to roll v6 out onto others' networks, I appreciate the sentiment and think that healthy to set our minds wandering and get conversation started. If it's good to restrict the allocation and assignment of v4 resources to organisations who have a stated v6 deployment policy, then why do we need to wait until the final /8 has been allocated to the NCC before we begin such a policy ? Perhaps we should have a phased process that asks organisations how they are deploying v6 on the PA and PI request forms, and then future requests from that organisation, or related organisations are refused if the deployment has not started. Why was /27 selected rather than /26 or /25 ? Since most deployments have multiple, separate infrastructure assignments, and services/user assignments, it seems that a /27 as a minimum allocation is far to small to promote any degree of aggregation whatsoever. This policy is therefore counter to one of RIPE's regularly stated aims - to promote route aggregation. The counter argument to this is that I might as well accept that we the side of common sense has lost the v4 aggregation debate, and v4 after-market sales will drive deagg further, so why should we care ? On the other hand, perhaps this policy will be seen as an ipv4 life extension policy. We do not want to muddy the message that we send to the community. V4's free pool will soon be gone. Do not gamble your company on policies designed to extend the availability of a very scarce resource. Maybe we can pool some of the ideas in 2009-03 and -04, and the community response, and build a solid run down policy that encourages v6 adoption, but doesn't pretend to be able to extend the life of v4. Andy
Greetings! First I do not like the /27 minimum allocation and assignment. I do not belive that people will adapt their filtering policies for this single /8. And I do not belive in RFC5211 at all. Here in the Czech Republic I know about some ISPs which just stopped all IPv6 deployment activites probably due to crisis-related budget cuts. So I do not like any policy which gives existing ISPs a chance to obtain some addresses from the last /8. In my opinion they have plenty of time to deploy IPv6 transition mechanisms and are able to obtain addresses for NAT(-PT|...) under current policies before the End. I would rather reserve the last /8 purely for newcomers and I would set some maximum allocation and assignment boundary in order to make sure that it will sustain for at least X newcomers which are expected to come in Y years. I do not try to argue that this is more "fair" than the 2009-04 and I do not want to punish existing ISPs. I just want to support more newcomers instead of handing out some portion of the last /8 to companies which have (in case of LIRs) at least /21 and are likely able to pick addresses for IPv6 transition mechanisms from their old allocations. Best regards, Tomas Filiz Yilmaz wrote:
PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment
-- Tomáš Hlaváček <tomas.hlavacek@elfove.cz>
participants (9)
-
Andy Davidson -
Filiz Yilmaz -
Marcus Stoegbauer -
Max Tulyev -
md＠Linux.IT -
Mikael Abrahamsson -
Randy Bush -
Sebastian Wiesinger -
Tomas Hlavacek