Hi Thomas, A quick update on the status of 2011-02 policy. I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal. So to everyone on the list, let's hear it. I've done a presentation on RIPE62 on the proposal for those not familiar with 2011-02 and you can find the PPT here : http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt You can read the policy proposal itself here: http://www.ripe.net/ripe/policies/proposals/2011-02 In short, the policy proposal is to remove the multi-homing requirement for PI IPv6. Currently, companies can become a LIR and get IPv6, with no multi-home requirement, same with requesting IPv4 PI. And companies that don't want to or (legally) can't become a LIR but do want to have their own IPv6 addresses are required to be multi-homed. The only change in text in the RIPE-512 is: Remove the line: a) demonstrate that it will be multihomed For those that agree with the policy and everything is clear, express your support on the AP-WG-mailing list your support. Kind regards, Erik Bais Co-author of 2011-02

On 8/7/11 2:29 PM, Jasper Jans wrote:

I support this proposal.

+1 This just means we remove the need to lie anymore to IPRAs about multihoming, if small/medium organization wants their IPv6 block and do not plan to actually be multihomed. :) Actually, with this we remove the only reason why NAT66 could exist :) Get your PI and don't translate addresses, if you change provider you are still good. Cheers, Jan Zorz

I support this proposal.

+1 ____________________________________ Tero Toikkanen Network Engineer Nebula Oy Heikkiläntie 2, FI-00210 Helsinki, Finland E-mail tero.toikkanen@nebula.fi tel +358-9-6818 3810 - fax +358-9-6818 3830 www.nebula.fi

So to everyone on the list, let's hear it. I also support that proposal!

Reasons for me (my company): we have a small IPv4 PI space and want to deploy IPv6. Of course it should also be PI and not PA [the same reasony apply for v6 as for v4]. Our provider has several conections to the Internet hubs, so our current v4 uplink _IS_ already redundant. The same will be the case for IPv6. To have our IPv6 space be explicitly multihomed, we have to * apply for an AS for proper BGP announcement * change fom cheap Internet uplink to expensive transit That will * unnecessarily burn away the last of the remaining 16 Bit AS numbers with additional RIPE fees for us * more than tripple the costs of our Internet connection (simple uplink is cheap, transit is expensive) but without gaining any benefit (that I can see). regards, Thomas

On 8/8/11 10:36 AM, DI. Thomas Schallar wrote:

...

To have our IPv6 space be explicitly multihomed, we have to

* apply for an AS for proper BGP announcement * change fom cheap Internet uplink to expensive transit

that does not change with removing the multihoming requirement. PI is still PI and you need to announce it via BGP and your ASN.

Why? We (as a multihomed ISP) announce both our own PA blocks and one of our customers PI block in v4 - why wouldn't that work/be allowed in v6? There's no need for an ASN or BGP capable router at the customer. Paul.

This is in 95% of the cases also how we run things.

...

Why? We (as a multihomed ISP) announce both our own PA blocks and one of our customers PI block in v4 - why wouldn't that work/be allowed in v6? There's no need for an ASN or BGP capable router at the customer.

True. Not very "clean" way, but definitely possible. It would be nice to have some data on "how common" is this way of announcing PI space. Probably we could find out how many PI allocations don't have their own ASN.

Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer

On 8/8/11 11:32 AM, Erik Bais wrote:

Hi Paul,

That is indeed a very common setup and removing the multi-home requirement for v6 will allow us to do the same for those PI customers.

So, to me then this looks like we are just tuning the policy to be in sync with real world. +1 Cheers, Jan

Dear All, I agree with removing the multi-homing requirement for IPv6 PI. Its pretty awkward to send your customers to a competitor because to deploy IPv6 PI space he or she needs to be multi-homed. Also, rising technologies such as LISP allow end-users to be multi-homed in a way that is transparent to the DFZ, so why bother restricting people to BGP multi-homing. Kind regards, Job Snijders On 6 aug. 2011, at 12:42, Erik Bais wrote:

Hi Thomas,

A quick update on the status of 2011-02 policy.

I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal.

So to everyone on the list, let's hear it.

I've done a presentation on RIPE62 on the proposal for those not familiar with 2011-02 and you can find the PPT here : http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt

You can read the policy proposal itself here: http://www.ripe.net/ripe/policies/proposals/2011-02

In short, the policy proposal is to remove the multi-homing requirement for PI IPv6. Currently, companies can become a LIR and get IPv6, with no multi-home requirement, same with requesting IPv4 PI. And companies that don't want to or (legally) can't become a LIR but do want to have their own IPv6 addresses are required to be multi-homed.

The only change in text in the RIPE-512 is:

Remove the line:

a) demonstrate that it will be multihomed

For those that agree with the policy and everything is clear, express your support on the AP-WG-mailing list your support.

Kind regards, Erik Bais Co-author of 2011-02

Hi Cagri,

I think multi-homing requirement is a good disincentive to get a PI space purely for portability and carrier independence reasons.

From what I see in our customer base, having portable IP space is a seen as an insurance if you like. Customers that apply for PI for different reasons, like building a VPN structure for a car dealer-ship with 200+ outlets or an Iphone app delivery system + apple sandbox that is linked to a specific subnet. Having to renumber those kind of setups are a pain to renumber after the initial setup and companies are hand-cuffed to the IP addresses and the LIR that holds

This is where I have to disagree with you. Having portable IP space has nothing to do with being multi-homed imho. them hostage to it. As long as everything works fine and the ISP is performing as required, everything is ok, however if that changes and other factors like network performance, packetloss, price or constant downtime because other customer(s) of their hoster is having DoS attacks, come into play, it is a different discussion. The requirement for being multi-homed is a discussion about uptime requirement. Sometimes this is driven by the end-customers business regulation and in other situations it is because they want to be-able to manage their own faith in regards of uptime. The question of 'what is being multi-homed' is another discussion. There are plenty of ISP's that provide fully redundant network setups from within their own AS, however as the term 'being multi-homed' in itself isn't clearly defined by this community, it is open for debate. For argument sake, I personally refer to being multi-homed as being connected to more than 1 AS, using BGP. That leaves open, could the originating AS of the PI v6 be the AS of a hoster or does the end-customer requires their own AS ?

If this change goes ahead everyone can simply go for PI and this is likely to have route aggregation utilized less and less.

If the change is approved, it allows end-customers to request PI for v6 (same as they could today apply for PI for v4.) Today, if they can't apply for PI v6, because they are not planning to be multi-homed, they could apply for a LIR membership, request v6, no questions asked. Result: No multi-homing requirement and also the same growth of DFZ as if the end-customer would request PI v6 without multi-homing.

I don't want to start another "millions of routes vs router memory discussion" by any means however I believe we should encourage aggregation whenever possible for practical reasons.

The majority of the de-aggregation doesn't come from PI, but from PA space, only a very small part of the PI IPv4 space is actually de-aggregated. And yes, I fully agree with you that aggregation should be done where possible.

Reading recent postings;

1. End-users making false multi-homing declarations to get PI. I think removing requirement is not the solution. Another option is to ask for an evidence to ensure there is a good justification for PI use.

There is no evidence to get for something that is not there yet. If an end-customer doesn't have PI, how could one provide proof that it is multi-homed ? It is the chicken and the egg problem. They don't have an AS yet as they don't have PI yet. And checking after the fact, is that what we want ? And what if some prefix isn't seen twice in the DFZ ? Are you planning to have RIPE NCC revoke it ? All RIPE NCC can do currently is ask for the intention, but enforcing it is just not possible. There are also a number of networks that are fully functioning on actual unique IP's, but are not advertized into the DFZ, but they are still multi-homed.

2. Sending end-users to competitor? Why should this happen? I would expect an ISP to be able to offer direct feeds from different providers (this is an actual requirement if they would like to offer highly available services anyhow).

If an ISP only holds 1 AS and they have a customer who likes their service, but that end-customer wants to run on PI IPv6, today, they would have to get another AS involved to be able to meet the PI v6 requirement. I've asked other ISP's and they stated that they have a secondary AS running for this particular reason. People are creative and very protective on their revenue, so why send customers to competitor X if you don't have to ?

3. End-users paying for LIR to just to get PI space; again if there is a problem with LIR requirements justification, or RIPE membership is being used for a purpose which has not been intended for, removing multi-homing requirement is not the solution. We should rather look into relevant policies to ensure end-users become LIR when they actually need to further assign IPs to their customers.

I've seen end-customers in The Netherlands, apply for a LIR membership, because they didn't receive the required IP addresses from their Telco. The current discussion on XXS & XS sized LIR's on the membership mailing list will only speed that up. I'm personally in favor for an increase in the yearly cost (upkeep) for PI. (Both for IPv4 and v6) As this whole discussion in reality is already a financial discussion and not a technical one. There are also legal issues for some end-customers that won't allow them to become a LIR, but they have, at the same time, still the requirement to have their own IP unique addresses. The policy proposal by itself is not technical, as the reality is already providing 'creative' solutions for customers that really want to move ahead. The policy is to make PI IPv6 the same as PI for IPv4. Regards, Erik Bais

Hello all! I don't believe that "making it complicated" will change anything in the demand and applications for PI address space. Home Users or small companies with just 1-8 IPv4 addresses resp. one /64 prefix don't need PI now and won't need it in the future. Whatever they need to change is done rather quickly. Big companies however, with several networks and several sites, do need PI. We need PI address space for our infrastructure. No matter how complicated it will get - we already did it resp. will do everything necessary it in the future, to have and keep it. The same for our major customers. When they need PI space they will do whatever is necessary to get it. So as long as there is PI available, you need technological solutions to make it work. Of course I see the problems with growing routing tables. But customers do need PI so they will apply for PI and therefore the routing tables are growing. So you need a solution. And - sorry - it's no solution to just make it complicated/expensive and save the real solution for later. To implement PI you need a provider. A provider is multihomed. So when the provider adds your v4/v6 PI space to his AS, it definitely is multihomed. You won't need your own AS to tell that to the world. :-) More important: I don't believe that I am a great prophet by saying, that the demand of PI space in IPv6 is much greater than it ever was in IPv4! Think of a regular company with several internal networks for DMZ, server-LAN, PC-LAN, VoIP LAN, VPN, development departments and with a couple of firewalls and routers between them. With IPv4 it's no big deal to change the provider. One just has to change the external IP address(es), make DNS adjustments and some tweeks in the firewalls of remote sites (subsidiaries) and within 0.5 to 4 hours the task is complete. Everything internal will stay the same with NAT-ed addresses. But think of a provider change for such a setup with IPv6 on all networks! All routers, machines, servers and - that's the biggest issue - all firewalls are set up for the IPv6 addresses used. Changing them - with no major service disruption during working hours = on the weekend = dozens of hours at the most expensive time rates = several thousand Euros - will cost much much more, than to comply with the "artificially" complcated and unnecessary cost-expensive PI requirements today. So every bigger company WILL REQUEST v6 PI SPACE. At least after their first provider change... ;-) Provider changes are not so rare as one might think! Many small providers offer good packages or features, that big providers won't/can't offer. The customer chooses the small provider and gets PA space. Some years later, the small provider will be absorbed by a bigger provider and the need for change is there. On average, we have one provider change per month with the customers we support. So in my opinion: either if you remove the demand of being multihomed or not: you have to work out technical solutions for the many, many IPv6 PIs that WILL be requested within the next years! Making it complicated or expensive won't change that. It will only add unneccessary workload on all ends. Yes I *DO* support the proposal to remove the multihomed requirement for IPv6 PI. regards, Thoma

Hi, I'm not sure I agree with the proposed policy.

I've done a presentation on RIPE62 on the proposal for those not familiar with 2011-02 and you can find the PPT here: http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt

I find the justification given in "where does it come from" on slide 7 to be a bit weak. Specifically, as noted elsewhere in the slide deck, it's not just the LIR fee to get IPv6 PA space which acts as a pushback. So therefore I think the conclusion which says that the community does not care or does not need to worry about the IPv6 DFZ size, or that there are no technical issues, to be weakly founded. So by removing the requirement for multi-homing to get IPv6 PI space yet one more part of the dike to stem the flood into the DFZ is whittled away. Who is willing to predict whether IPv6 PI after this policy is passed is going to be the modern-day equivalent of the old "swamp" in the 192.0.0.0/8 space, where route aggregation is impossible and ownership of address blocks is scattered far and wide. Underlying, and unstated seems to be an assumption that "everyone has a birthgiven right to a non-changing IPv6 address when one changes provider". Is that really a given? Best regards, - Håvard

On 06/08/2011 11:42, Erik Bais wrote:

In short, the policy proposal is to remove the multi-homing requirement for PI IPv6. Currently, companies can become a LIR and get IPv6, with no multi-home requirement, same with requesting IPv4 PI.

I don't support this policy as it stands, because it makes it too easy to get PI space instead of PA space. This will cause deaggregation in the ipv6 DFZ. Deaggregation is a serious operational issue which gets monotonically worse over time. It never improves, and 2011-02 will simply aggravate the problem. This is important because we are designing constraints for a protocol which is expected to last for a very long time. We've had 30 years of IPv4 so far, and there's no reason to expect that ipv6 won't last several times that length. If we start off with too liberal a policy, then it will create a nasty mess which will blight DFZ routing in future years. If the policy were changed to add in a clause that the end-user was explicitly required to provide evidence that they needed PI space instead of PA, then I would support it. This change would raise the bar slightly but significantly, and would also align the proposed IPv4 PI policy (2006-05) with the proposed IPv6 PI policy (2011-02) in this particular respect. I believe that there is merit in both of these things. Nick

Hi Nick,

I don't support this policy as it stands, because it makes it too easy to get PI space instead of PA space. This will cause deaggregation in the ipv6 DFZ.

I don't think it would cause de-aggregation (for definition how I see it, announcing a single allocation into smaller subnets), but it might bring more prefixes in the DFZ. However a PI IPv6 subnet or a PA IPv6 subnet for a new LIR that isn't multi-homed could be seen as equal. So from that perspective, this policy proposal doesn't change anything. What I did already see is v6 PA space being handed out to customers and being announced in smaller prefixes under another AS than the /32 PA that it came from.

If the policy were changed to add in a clause that the end-user was explicitly required to provide evidence that they needed PI space instead of PA, then I would support it. This change would raise the bar slightly but significantly, and would also align the proposed IPv4 PI policy (2006-05) with the proposed IPv6 PI policy (2011-02) in this particular respect. I believe that there is merit in both of these things.

Personally I think that providing evidence is open for motivational discussions. If one can motivate why he/she requires PI, they should get it. I rather don't see such a arguable line taken up in the policy, but much rather see an increase in the (financial) cost for becoming a LIR AND specifically the cost for PI. Along the same line as 2006-05 is, stop BS'ing to the IPRA's, tell them what you / your customer require, without inflating the story. What is the ONLY reason why an end-customer would return their IP addresses ? A financial reason. I dare to say that a lot of space is not returned, because the end-customer or the LIR doesn't feel the pain (the upkeep cost) for it. Increasing the cost for PI will be the way to make sure that end-customers are going to think twice. Do I really need this, or is it just cool to have. However, the RIPE community can't dictate the cost for PI, as that is to be decided in the AGM meeting by the member votes. The initial draft (before publishing) had in fact an increase in the cost for PI, however as these are 2 separate paths to be taken, it was decided not included it in 2011-02. Regards, Erik Bais

[beware: slightly off-topic maybe, but imho fundamentally important] Nick Hilliard wrote:

Hi Eric, [...]

...

However, the RIPE community can't dictate the cost for PI, as that is to be decided in the AGM meeting by the member votes.

This is "just" procedural, but...

It's more difficult than this. Because of the sheer numbers of PI assignments, increasing the "wholesale" cost even by a small amount will have a significant impact on the RIPE NCC's budget. That would create... awkward bureaucratic problems for the RIPE NCC.

This line of thinking would be even more than "difficult" to maintain: it would simply turn the funding and charging model for the RIPE NCC's services upside-down. The fundamental assumption is that the charging model provides the money to allow the RIPE NCC to execute the annual activity-plan (as agreed by the AGM), and to maintain a certain level of safety-belt funds to guarantee the stability of the NCC itself. The Service Charges are to be set according to cost and effort *within the NCC* to provide the services (plus the overhead, according to the activity plan). The NCC, for good reasons imho, is a not-for-profit entity and is *not* mandated (nor formally allowed, I presume) to collect money for and/or redistribute to any third party, which is not directly involved or necessary in the management of Number Resources.

Nick

I think it is pretty important to keep this in mind, in general. Wilfried.

Hi,

...

I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal.

I'm still of the opinion that removing the dual homing requirement for PI is a mistake.

Having done some work on renumbering on IPv6, its much easier than v4 (assuming that you design the addressing to be portable) and not the barrier that people believe that it is with v4.

Please feel free to correct my thinking but PA space is for LIRs to give to customers for their use, PI space is for those customers who require a separate block because they need to be 'independent' of their LIR. The only time this is required (afaict) is when the block *needs* to be routed by a third party for resilience and therefore needs to be multi-homed.

By removing that requirement we are 'encouraging' the requisition of additional resources where non is required and increasing the size of the routing table unnecessarily.

If there is another problem we are trying to solve (as in PI space not being suitable for sub-allocation) then we are trying to solve it the wrong way...

this is a repeat for the 68060th time so i try to be brief: there wasn't a multihoming requirement in the IPv4 PI world lately, or was it? there is no IPv4 PI problem (rather a IPv4 PA deaggregation problem), so there certainly won't be any with IPv6 PI - by design ("one prefix only, usually") there is a problem with this difference between IPv4 and IPv6 PI policies which hinders IPv6 deployment right now This policy change is about NOTHING else than aligning the IPv6 PI policy with the IPv4 PI policy we have for ages. It will not end the world or encourage more IPv6 PI usage than IPv4 PI usage. All other requirements are still the same (roughly). This policy change does not try to solve any other problem than allowing IPv4 PI holders who don't multi-home to be able to get IPv6 PI and do the right thing - getting IPv6 deployment started. If there is a problem with this policy in 5-10 years due to some reasons, we can change the policy again, it's not written in stone. Things change, policies can, too. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

Hi Jim, without a direct replay to your last message, let me explain why I am in favour of 2011-02. Jim Reid wrote: [...]

I'm neither for or against 2011-02: just trying to better understand the rationale and motivation behind it.

I am in contact with organisations who want (or are pushed :-) ) to deploy IPv6. Some of them have a very credible reason to use PI addresses, although they do not configure dual-homing *for IPv6* for the very beginning. Still, using PA is a bad choice for them. Possible reactions to this have either been becoming an LIR (potentially a waste of address space, plus additional cost, but option has been selected), or to delay the introduction of IPv6 for the moment; has been done, too :-) Hth, Wilfried.

Hi, It is very easy to soften the rules, however, it is always difficult to keep them clear and sharp. Most of the IPv4 PI address space allocation comes from the pre-CIDR period of time. I am pretty sure that all the examples hinted by Wilfried are early allocations, may be even pre-RIPE allocations. On Tue, Aug 9, 2011 at 10:35 PM, João Damas <joao@bondis.org> wrote:

On 9 Aug 2011, at 18:25, Jim Reid wrote:

Small intermission.

...

Please explain Sascha. I just don't get it. IPv6 deployment isn't

hindered by the availability of PI space. At least not in the general case. Can you give some actual examples where a problem getting PI IPv6 space has (or is) a showstopper for IPv6 deployment?

There are people who clearly sustain the opposite so this is not a statement that has been without challenges which mostly seem to be grounded on the needs of enterprises. Particularly because they can get this in IPv4 and how do you sell anyone a technology that gives you "less" than the previous one?

...

...

This policy change is about NOTHING else than aligning the IPv6 PI

policy with

...

...

the IPv4 PI policy we have for ages.

That's all very well. However it may be the answer to the wrong question. Suppose we didn't have IPv4 PI space at all. Would we invent this concept for IPv6? If so, why? If not, why not?

Problem is, Jim, we do have IPv4 PI, and people compare fruits.

Joao

The address akkocation liberty of the early Internet can not kept any more, because it does not scale!!! CIDR (and PA!) was introduced exactly to limit the growth of the routing table! The real problem for a hosting company is load balancing and not the Provider Aggregated IPv6 address space! Renumbering in IPv6 is not painless, however it can be done, even for a hosting company in case if it would be realy needed in the future... Thanks, Geza

On 10 August 2011 10:33, Jasper Jans <Jasper.Jans@espritxb.nl> wrote:

I am all for learning from our mistakes - but we cannot deploy policy that excludes a group of people when it comes to IPv6 that already qualified for ipv4 PI. If we really have to do the dual-homing requirement (I'm of the opinion we don't) then at the very least make it so that the clause states that you need to be dual-homed for any new IPv6 PI, or must already own IPv4 PI. This way you can prevent people from getting it that do not have it yet but allow the ones that already run IPv4 PI to get IPv6 PI.

That would be an option, adding the requirement for Dual Homing or existing IPv4 PI would seem to solve the issue - it might even increase the number of v4 PI requests and speed depletion which some would see as a good thing. J -- James Blessing 07989 039 476

On 8/10/11 12:24 PM, Jasper Jans wrote:

| That would be an option, adding the requirement for Dual Homing or | existing IPv4 PI would seem to solve the issue - it might even | increase the number of v4 PI requests and speed depletion which some | would see as a good thing.

Indeed - the backdoor into IPv6 PI is getting IPv4 PI. This is a limited time only kind of deal since IPv4 is nearly depleted so we know this change will not let too much new PI space slip in for people that not have it today, but will allow organisations to move forward with IPv6 deployments that have IPv4 PI today already.

This is getting complicated. Why bonding IPv4 policy to IPv6 policy? Independent Resources costs money - X EUR/Year. If you are multihomed, IPv6 PI space would cost X EUR/Year If you are not multihomed, IPv6 PI space would automatically cost X x 2 EUR/Year. Now suit yourself and make a decision, what's gonna be. This would probably fix all the fears expressed here in this thread. And in my opinion independent resources are too cheap, but that's just my view and out of scope of this discussion. Cheers, Jan

Hi Jasper, On Wed, Aug 10, 2011 at 11:33 AM, Jasper Jans <Jasper.Jans@espritxb.nl>wrote:

I am all for learning from our mistakes - but we cannot deploy policy that excludes a group of people when it comes to IPv6 that already qualified for ipv4 PI. If we really have to do the dual-homing requirement (I'm of the opinion we don't)

then at the very least make it so that the clause states that you need to be dual-homed for any new IPv6 PI, or must already own IPv4 PI. This way you can prevent people from getting it that do not have it yet but allow the ones that already run IPv4 PI to get IPv6 PI.

Jasper

This is an argument what many people might support -- even me ;-) , --- but I would also add some review period to all PI allocations. Like this: The policy allowing Provider Independent allocation might be revoked later on and if it is revoked then ALL PI holder not fullfilling the new policy will be requested to return their PI address space and renumber to PA address space within 2 years. What do you think about this? Thanks, Géza

Turchanyi Geza wrote:

Hi Jasper, [...] The policy allowing Provider Independent allocation might be revoked later on and if it is revoked then ALL PI holder not fullfilling the new policy will be requested to return their PI address space and renumber to PA address space within 2 years.

What do you think about this?

Maybe easy in some (tech-savvy playground) pockets of the net, but certainly not going to fly in some (many?) pretty stable and/or complex environments. One example: health services area. I'd even venture to say that it would actually be completely contrary to why many organisations opt(ed) for PI...

Thanks,

Géza

Wilfried PS: maybe slightly OT, but why was number portability introduced and has become quite popular in the telephone system? Renumbering a phone is "easy", isn't it ;-)

James Blessing wrote:

Since with IPv6 you are unlikely to be using the IP addresses for anything in day to day use (unlike v4 where you still see lots of manual configuration)

The reality is that stateless auto configuration is not really stateless and no better than DHCP.

and there are explicit functions from an end device to use multiple IP addresses it makes sense to change end user configuration to an automated function.

As is proven by hosts with an IPv4 and an IPv6 addresses, IPv6 does not support hosts with multiple addresses better than IPv4. Masataka Ohta

Dear Wilfried, On Aug 10, 2011, at 12:23, Wilfried Woeber, UniVie/ACOnet wrote:

Without wanting to imply anything, just providing us with real figures -

iirc NCC Registration Services has given a very nice report recently (at 61 or 62? a recent NRO report?), listing the number of PI assignmenet vs the number of PA allocations, and the percentage of space given out for the 2 categories.

Unfortunately, I cannot find this/those presentation/s on short notice right now. Maybe the NCC can help?

At RIPE62 I presented the following: http://ripe62.ripe.net/presentations/209-apwg.pdf (PI section starts at slide 9, numbers from 25 onwards) Adding the IPv4 PI vs the IPv4 ALLOCATED blocks the RIPE NCC has on file at the moment, we see that 3.5% of all IPv4 IPs handed out were assigned/allocated as PI. Best regards, Alex Le Heux

Turchani, On Wed, Aug 17, 2011 at 7:41 PM, Turchanyi Geza <turchanyi.geza@gmail.com> wrote:

Hi Alex,

May I interpret your slide29 in this way:

3,5% off the address space had been allocated as PI in the RIPE NCC service region and this PI address space is responsible for 21% of the BGP prefixes (originated in this region).

So 3,5% AND 21%....

In IPv6 PI this ratio probably will be even worse...

But is that ratio actually such a useful metric for IPv6? I think you overlooked page 30, which IMO is much more useful: 15417 PA allocations => 59126 prefixes in the DFZ, a ratio of 3.8. 16340 PI assignments => 17468 prefizes in the DFZ, a ratio of 1.1. Add to this that many operators have multiple assignments in IPv4, which I must say has to be much less likely to happen in IPv6 than it is in IPv4. I believe there's already been research done to try and determine how they would perform if they had a single assignment large enough for their entire network, e.g. how much is TE, poor design or just simply due to having had to return to RIR iteratively over the years to get more space. If not, someone should look into that. :) Best Regards, Martin

W dniu 18.08.2011 23:42, Turchanyi Geza pisze:

Second point: if ALL IPv4 PI holder would request IPv6 PI then you might expect another 17K prefixes in the routing table just from the RIPE Region! And this is just the start! Most ipv4 PI holders have more than one prefix - when first was not enought - they get another. Few ISP in poland get 3-4 prefixes when they weren't LIR.

For ipv6 one prefix is always enought - so 17k is much to much :) Regards, Andrzej

Hi Andrzej & Turchanyi, That is a difference in that respect between IPv4 and IPv6. End-customers that request IPv4 PI might find themselves after a while in a situation where the initial request allocation isn't big enough and they can and will request another prefix. For IPv6 that isn't likely and I've heard that some people are a bit concerned about this. One of the things we might want to put into the IPv6 PI limitations is that an end-customer can only request a single IPv6 PI Prefix and to a maximum of a certain size. ( say a /34 ) Anything beyond that should be considered LIR sized and the end-customer should become a LIR and turn in their PI prefix. Regards, Erik Bais From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Turchanyi Geza Sent: Friday, August 19, 2011 5:41 AM To: Andrzej Dopierała Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PI for IPv6 == PI for IPv4? Hello Andrzej, Good point. You said that some ISPs are using IPv4 PI address space just because they asked it in their very small ISP status, as being pre-LIR. It would have been much better to change back these addresses to PA already long time. Is there anybody who can suggest a cleaning policy? Of course, vleaning is very difficult whan almost all IPv4 address space have gone... ;-(( Anyhow, the danger og creating too many routing table entries by allocating Provider Independent (IPv6) addresses is still exist and should not be overlooked. Best, Géza 2011/8/18 Andrzej Dopierała <undefine@aramin.net> W dniu 18.08.2011 23:42, Turchanyi Geza pisze: Second point: if ALL IPv4 PI holder would request IPv6 PI then you might expect another 17K prefixes in the routing table just from the RIPE Region! And this is just the start! Most ipv4 PI holders have more than one prefix - when first was not enought - they get another. Few ISP in poland get 3-4 prefixes when they weren't LIR. For ipv6 one prefix is always enought - so 17k is much to much :) Regards, Andrzej _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3843 - Release Date: 08/18/11

W dniu 19.08.2011 15:05, Turchanyi Geza pisze:

Hi Erik,

2011/8/19 Erik Bais <ebais@a2b-internet.com <mailto:ebais@a2b-internet.com>>

Hi Andrzej & Turchanyi,

That is a difference in that respect between IPv4 and IPv6.

End-customers that request IPv4 PI might find themselves after a while in a situation where the initial request allocation isn't big enough and they can and will request another prefix.

It would have been better and still would be better even in that case to use only one prefix and return the original one to the RIR. It's not always so simple. When we have dns servers hardcoded in thousands machines, or when we have hosting where clients puts their domains (and we have no control on client's domains) - return any ip class is not easy.

On ipv6 - there is problem with renumbering too - but there is no need to get another class - we have just one class which is big enough to end of our life ;) Regards, Andrzej

Please explain Sascha. I just don't get it. IPv6 deployment isn't hindered by the availability of PI space. At least not in the general case. Can you give some actual examples where a problem getting PI IPv6 space has (or is) a showstopper for IPv6 deployment?

I have an example - hosting companies can't get PI IPv6, and they are forced to become LIRs in order to get one. Discussed proposal changes nothing for them, thus, you wanted an example where getting PI IPv6 space is stopping IPv6 deployment.

Maybe, but why does someone need IPv6 PI space to start deploying IPv6?

Because someone don't want to, or need to, to become LIR and get their PA allocation (see example above). Regards -- Adrian

Erik Bais wrote:

Hi Adrian,

They can't get IPv6 PI for hosting business.. But would they to enable IPv6 for their own infrastructure ? If they wouldn't give addresses to other entities, they would still fit within the same rules as any other end-customer.

yeap, and recently such cases were sent to "hell" with the reason "IPv6 PI is only available with direct agreement Customer-RIPE" Regards, Marcin

On Aug 26, 2011, at 9:20 AM, DI. Thomas Schallar wrote:

Hello!

I'm back with the same question I made a month ago: what ist the current status on the multihomed v6 PI topic? The "current" phase on the proposal ended three days ago (August 23rd) and the status is "Awaiting Decision from Working Group Chair".

http://www.ripe.net/ripe/policies/proposals/2011-02

What now?

regards, Thomas

The current state is what it says, it is awaiting a decision from the WG chair(s) together with the proposer on how to move forward. This decision is based on the feedback received on the mailing list during the last round. Usually this can go two ways: - There is rough consensus on the proposal and the suggested text, which will mean the proposal can move to last call - People have suggested changes which need to be included or there seem to be a need for further discussion, in which case the current period will be extended or revised documents will be published together with a new call for feedback More information on the Policy Development Process, including all the phases can be found at http://www.ripe.net/ripe/policies/policy-development-process-glossary and is described in document ripe-500 which can be found in the document store at http://www.ripe.net/ripe/docs/ripe-500 Regards, Marco

Hi Thomas, I just called one of the AP WG chairs and gave him a gentle nudge on the topic. I’m pretty sure they will get back to us on this pretty soon. ( My guess is within 2 weeks.) Erik From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of DI. Thomas Schallar Sent: Wednesday, September 07, 2011 11:05 AM To: RIPE Address Policy Working Group Subject: Re: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? Hello! I was more interested about the TIMEFRAME one could expect. :-) The current status "Awaiting Decision from Working Group Chair" is two weeks old now (August 23rd). Please don't get me wrong: I am completely unfamiliar with RIPE decision findigs. I just like to know, how soon one can expect a decision - to finaly decide about that matter or to continue discussion again. regards, Thomas Marco Hogewoning schrieb am 26.08.2011 10:18: On Aug 26, 2011, at 9:20 AM, DI. Thomas Schallar wrote: Hello! I'm back with the same question I made a month ago: what ist the current status on the multihomed v6 PI topic? The "current" phase on the proposal ended three days ago (August 23rd) and the status is "Awaiting Decision from Working Group Chair". http://www.ripe.net/ripe/policies/proposals/2011-02 What now? regards, Thomas The current state is what it says, it is awaiting a decision from the WG chair(s) together with the proposer on how to move forward. This decision is based on the feedback received on the mailing list during the last round. Usually this can go two ways: - There is rough consensus on the proposal and the suggested text, which will mean the proposal can move to last call - People have suggested changes which need to be included or there seem to be a need for further discussion, in which case the current period will be extended or revised documents will be published together with a new call for feedback More information on the Policy Development Process, including all the phases can be found at http://www.ripe.net/ripe/policies/policy-development-process-glossary and is described in document ripe-500 which can be found in the document store at http://www.ripe.net/ripe/docs/ripe-500 Regards, Marco _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3882 - Release Date: 09/07/11

Nudge received :-)  We are still going through the whole mailing list archive to see which concerns were raised and how they were addressed. Quite a lot of messages were sent about this proposal over the last months! We're working on it.

Good to hear that. I (as many other IPv4 PI "owners") can't wait to geht my IPv6 PI. regards, Dan -- danrl / Dan Luedtke http://www.danrl.de

Hi Dan, nothing stops th IPv4 PI owners to use IPv6 PA.... Good luck, Géza On Mon, Sep 19, 2011 at 12:30 PM, Dan Luedtke <maildanrl@googlemail.com>wrote:

...

Nudge received :-) We are still going through the whole mailing list archive to see which concerns were raised and how they were addressed. Quite a lot of messages were sent about this proposal over the last months! We're working on it.

Good to hear that. I (as many other IPv4 PI "owners") can't wait to geht my IPv6 PI.

regards,

Dan

-- danrl / Dan Luedtke http://www.danrl.de

Hello, I do see it differently. PI address space is easy to use, however, this allocation mechanism does not scale. Therefore was invented CIDR and PA allocation, if you do remember... I do not want to say that there is no room for exceptional cases and PI allocations. However, these must be limited in numbers (of allocations) and perhaps even in time. (you might receive it just for a couple of years.) PI allocation is not a privilage which will be inherited in time... When I checked the RIPE website and learned that all the working group chairs will decide weather the 2011-02 policy proposal got concensus I was happy. I still think that it would be dangerous to "release the djin" from the bottle, without any capability to control "the djin" in the future. I also recommend to study http://www.ietf.org/rfc/rfc4984.txt. I do not object to allow a few exceptional PI allocations, however, a well defined and understandable safeguarding limit should be implemented immediately. Later it could be too late. My proposal was and is to include immediately in 2011-2: If the number of allocated IPv6 PI slots reaches the number of LIRs in the region then the PI allocation should be stopped and the PI allocation policy must be reviewed. The number of LIRs is a sociological-political term and not a technical one, but at least clearly understandable by politicians and managers, and it is reasonably not too high not too low. AND this way the same rule could be applied in all RIRs. Applying the same rule everywhere I consider as a very important aspect. The other RIRs could easily accept the same. Anyhow, the number of entries in the global routing tables is just a global issue. Any related policy should be made at global level, and a faire manner. Best, Géza . On Mon, Nov 7, 2011 at 11:10 AM, DI. Thomas Schallar <t.schallar@avalon.at>wrote:

** Hello!

Turchanyi Geza schrieb am 07.11.2011 10:02:

nothing stops th IPv4 PI owners to use IPv6 PA....

Nothing stops anybody of using PA, neither in IPv4 nor in v6. That's not the question.

But any reasons, why somebody wants/needs IPv4 PI space will usually fully apply to IPv6 also. It would seem stupid to me, to have IPv4 ("the past") as PI but IPv6 ("the future") as PA. That won't make sense. What changed between my v4 PI application and my v6 PI application? If I won't need PI on v6 any more, I probably won't need it on v4 any longer.

Siple question: do I need my machines to have provider independend IP addresses or not? If yes, then I need *ANY* address (IPv4, IPv6, IPvSomething) to be PI and not PA.

So, if somebody already has IPv4 PI space, he/she should more or less automatically receive v6 PI under the same conditions as for v4. He/she just has to reason, why some default /48 won't be enough. Thats my opinion.

regards, Thomas

Dan,

On Wed, Nov 9, 2011 at 9:05 AM, Dan Luedtke <maildanrl@googlemail.com>wrote:

> On Mon, Nov 7, 2011 at 10:02 AM, Turchanyi Geza
> <turchanyi.geza@gmail.com> wrote:
> > nothing stops th IPv4 PI owners to use IPv6 PA....
> - except that one has to renumber the whole network when finally (if
> ever) receiving PIv6
> - which leads to about double costs
>

I am happy to hear that you made the transition and you are using IPv6 PA.


> In fact, I have a mixed network (PIv4, PAv6) at the moment, but I am
> still wondering why I cannot get assigned PIv6. What changed?
>

PI does not scale! We regret this, however, we can not forget this!

There is only one way to keep the routing table in  a handable status:
massive PA use.

I hope, you will be glad with your current provider and do not need to
renumber in the near future. Anyhow, renumbering is not so hard if your
network was designed with the requirement of renumbering in mind...

Best,

Géza


>
> regards,
>   Dan
>
> --
> Dan Luedtke
> http://www.danrl.de
>