hi sander: thanks very much for replying. but if there is no policy for that, is that means people can announce their address in us or region outside ripe region(as i know some people do for their us cdn network for example)., is this also accepted in the policy? On Wed, May 23, 2012 at 7:53 AM, Sander Steffann <sander@steffann.nl> wrote:

Hello Lu,

...

Sorry for disturbing. I have one question which I didn't find answer in the policy document.

The RIPE policies cover allocation and assignment. How you announce the addresses (and what other people/companies will accept from you) is out of scope for RIPE policies. The RIPE Routing WG has a recommendations on that (http://www.ripe.net/ripe/docs/ripe-399), but there is no policy.

Sander

-- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received.

Hi Tore: Thanks for replying. Almost every hosting company here in EU has customer from outside of region, they rent server from EU company for whatever reasons(for making their EU website for example), but they are outside of region. If "end customer from outside of region can not assign IP addresses", then all EU hosting company can not sell any hosting package to a person in US for example, but that is not the case. So where is the limit? On Wed, May 23, 2012 at 9:40 AM, Tore Anderson <tore.anderson@redpill-linpro.com> wrote:

* Lu Heng

...

but if there is no policy for that, is that means people can announce their address in us or region outside ripe region(as i know some people do for their us cdn network for example)., is this also accepted in the policy?

You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region.

-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

-- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received.

Tore,

However, if I build a data center in China I cannot use RIPE region address space to number it. (Even if the customers hosted in that were all incorporated in the RIPE region.)

I wonder if this might actually be true. Could you show a pointer into the relevant document? Elmar (Actually doing exactly this. In China.)

On 5/23/12 10:59 AM, Tore Anderson wrote:

If on the other hand out-of-region assignments are valid and allowed, I cannot fathom why those fast growing ISPs in China, India, Vietnam and so on that were allocating IPv4 addresses from APNIC at an incredible rate right up until the day APNIC hit the /8 have not simply set up legal organisations in the RIPE region, joined the NCC, and continued allocating from here in more or less the same rate as before APNIC ran out.

Maybe those IPv4-hungry operators are just not aware of this "option" ;) Jan

* Milton L Mueller

Can you provide any reason to maintain territorial exclusivity of assignments in this way?

No. I wasn't advocating any particular policy, really, just stating what I understood current RIR practise to be (based on how I interpreted the answers given to me by the RIR panel at RIPE61). Ingrid has clarified that my understanding was incorrect, at least when it comes to the RIPE NCC's practises. I have to admit that I do still find it hard to accept that there are no such territorial exclusivity, based on what has happened since APNIC hit their last /8 policy. The high allocation rate seen in the APNIC region didn't shift to other regions, it just vanished overnight. If all it takes for an organisation to allocate addresses from out-of-region RIRs to in-region end-users is to incorporate in that RIRs region, become a LIR there, and peer at an IX there...those are trivial requirements to meet, really, especially if you're desperate of IPv4 addresses. For example, China Telecom had been allocating huge amounts of IPv4 addresses from APNIC up until the day they hit the last /8 policy. As far as I can tell, China Telecom is incorporated in the UK, they are a RIPE NCC member, and are peering on LINX. If that is all it takes to allocated addresses from the RIPE NCC for use anywhere in the world, I find it very hard to understand why China Telecom hasn't simply continued allocating IPv4 addresses from the RIPE NCC in the same rate as they did from from APNIC before they hit the last /8.

What benefit to the internet or its users is accomplished?

My current personal opinion is that it would be best if all regions exhausted more or less at the same time, but admittedly, I haven't given this very much thought. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/

On May 23, 2012, at 4:32 AM, Tore Anderson wrote:

* Lu Heng

...

Almost every hosting company here in EU has customer from outside of region, they rent server from EU company for whatever reasons(for making their EU website for example), but they are outside of region.

If "end customer from outside of region can not assign IP addresses", then all EU hosting company can not sell any hosting package to a person in US for example, but that is not the case.

They can, if the hosted service is in the RIPE service region.

For example: You (assuming you're located in China) can come to me and purchase a virtual machine hosted in my data center located in Norway. It will be numbered using RIPE region address space. No problems. I could also announce this address space to peers on a Chinese internet exchange and backhaul the traffic to Norway myself, if I wanted to. Still no problems there.

However, if I build a data center in China I cannot use RIPE region address space to number it. (Even if the customers hosted in that were all incorporated in the RIPE region.) If this had been permitted, I doubt there would still be available IPv4 address space in the RIPE region at this point, as organisations in the APNIC region in need of IPv4 address space could just have set up LIRs in the RIPE region and allocate away.

Apologies in advance for being pedantic, but unless some non-Chinese operator can attest that they have actually done one of those things -- i.e., use non-CNNIC(any) assigned IP resources to interconnect at a China-based IXP, and/or to provide (or even consume) data center services within China, may I suggest that we choose a different country for our hypothetical examples? To my knowledge, none of those things has actually been permissible, at least for the last 10-12 years. Would love to hear that things have now changed, if they have in fact changed -- but unless/until that can be established it would probably be best not to leave false breadcrumb trails that might easily mislead future address-policy-wg readers. Just a thought, TV (who has walked down many such false trails in the past)

* Randy Bush

...

You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region.

really? so i have a /16 from ncc and i spread it over pops in ams, lon, and nyc, but i can not have bgp-speaking customers in that address space in nyc? if true, that is soooo broken.

That is my understanding, at least. I asked this question to the RIR panel at the mic in Rome, whether and APNIC region ISP could (post APNIC depletion) set up a LIR in the RIPE region (or any other region), and allocate addresses from there and assign them to end users in their home region. The answer (which came from Geoff Huston IIRC) was something along the lines of «no, you have to assign the addresses in the service region from which they were allocated». If this was not the case, I would not have expected the APNIC depletion from significantly slow down the global rate of IPv4 delegations, only that it would simply shift from the APNIC region to other regions as IPv4-hungry Asian providers started allocating from other regions. But looking at http://www.potaroo.net/tools/ipv4/fig09.png for example, this does not appear to have happened. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

On 23/05/2012, at 11:12 AM, Tore Anderson wrote:

* Tore Anderson

...

That is my understanding, at least. I asked this question to the RIR panel at the mic in Rome, whether and APNIC region ISP could (post APNIC depletion) set up a LIR in the RIPE region (or any other region), and allocate addresses from there and assign them to end users in their home region. The answer (which came from Geoff Huston IIRC) was something along the lines of «no, you have to assign the addresses in the service region from which they were allocated».

Found it: http://ripe61.ripe.net/archives/video/18/ @ 22:03

I think I said "we expect some alignment to these regions, but this is an expectation not a hard and fast rule", but I seem to have taken a few hundred words to do so! And I made some reference to human inventiveness that may be used to circumvent any such conventional expectations. :-) regards, Geoff

On 23/05/2012, at 10:41 AM, Tore Anderson wrote:

* Randy Bush

...

...

You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region.

really? so i have a /16 from ncc and i spread it over pops in ams, lon, and nyc, but i can not have bgp-speaking customers in that address space in nyc? if true, that is soooo broken.

That is my understanding, at least. I asked this question to the RIR panel at the mic in Rome, whether and APNIC region ISP could (post APNIC depletion) set up a LIR in the RIPE region (or any other region), and allocate addresses from there and assign them to end users in their home region. The answer (which came from Geoff Huston IIRC) was something along the lines of «no, you have to assign the addresses in the service region from which they were allocated».

no - I don't think it was me (unless of course someone pops up with a video recording of me saying exactly that RIPE meeting! :-) ) I am personally of the school of thought that believes that addresses can be used anywhere on or off the planet, irrespective of which RIR provided the original block allocation or assignment. I don't think any other address management regime makes efficient use of either our common routing system or the underlying address plant.

If this was not the case, I would not have expected the APNIC depletion from significantly slow down the global rate of IPv4 delegations, only that it would simply shift from the APNIC region to other regions as IPv4-hungry Asian providers started allocating from other regions. But looking at http://www.potaroo.net/tools/ipv4/fig09.png for example, this does not appear to have happened.

I was anticipating such a shift in demand myself, and I too am slightly surprised it has not happened. On the other hand I understand that if APNIC sees a member request from an organization with a home address from outside of the APNIC region there is a typical exchange of "have you considered using <xxx> as your RIR, as you appear to be outside of our regional service zone?" A typical response may be along the lines of "ah yes, but we intended to deploy these addresses in our in-region network". So I suspect that there is a defacto assumption made by many folk about the regional constraints of the use of addresses, but as far as I am aware it is not a rule that is applied by the routing system itself. regards, Geoff (speaking personally in this case, and I'm probably wrong anyway!)

-----Original Message----- My guess is that the accelerated consumption we saw at the end of the APNIC pool was a 'run on the bank' with folks requesting more space than they actually needed.

[Milton L Mueller] What?!?! Do you mean to imply that "needs assessment" does not work as advertised? I am shocked, shocked!

On 5/25/12 6:12 AM, Geoff Huston wrote:

I was anticipating such a shift in demand myself, and I too am slightly surprised it has not happened.

here we go :) Jan

Hi Tore,

You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region.

This is not limited in policy. The LIR can assign resources to whoever their customers are. Thanks - Sander

Tore Anderson wrote:

* Lu Heng

...

but if there is no policy for that, is that means people can announce their address in us or region outside ripe region(as i know some people do for their us cdn network for example)., is this also accepted in the policy?

You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region.

I am not aware of such a limitation in the RIPE Region's policies. Wilfried.

...replying to myself now, must be the heat here in my room, sending out E-Mails before i thought about the contents properly...

Hi all,

...

Tore Anderson wrote:

...

* Lu Heng

...

but if there is no policy for that, is that means people can announce their address in us or region outside ripe region(as i know some people do for their us cdn network for example)., is this also accepted in the policy?

You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region.

I am not aware of such a limitation in the RIPE Region's policies. Wilfried.

me neither - and it would contradict common practice, and probably even common sense. So i hope that's just a misunderstanding/-interpretation.

..on a second thought, i can't (or at least could not in the past) get a PI(!) assignment for a customer NOT registered in RIPE NCC service region, so... hm interesting question/problem indeed, somehow. Might the NCC elaborate on this perhaps? :-) Maybe something is in the LIR contracts about this i'm not aware of right now? -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

* Ingrid Wijte

I would like to give some further clarification on this.

The RIPE NCC allocates/assigns address space to organisations who have a need in the RIPE NCC service region. The address space must be originated from the RIPE NCC service region. Due to the diverse nature of businesses, in addition to this there can be announcements from other regions.

Just to make 110% certain, you're saying here that it is the *need* that must be in the RIPE region, not the *organisation*, correct? Example 1: China Unicom sets up a legal organisation in the Netherlands, joins the NCC, and requests an allocation from which they intend to assign addresses to broadband customers in China. They intend to advertise the allocated prefix(es) to peers at AMS-IX (as well as from other exchange points around the world). Example 2: I, representing an existing LIR in the RIPE region, build a data center in Australia and set up a server hosting business there. I want to make an assignment to a new customer in this data center from my IPv4 allocation received from the RIPE NCC, and request that from the NCC hostmater using a ripe-488 form. Assuming all the documentation is otherwise in order and the need is real, will these requests be granted or denied? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

* Ingrid Wijte

...

I would like to give some further clarification on this.

The RIPE NCC allocates/assigns address space to organisations who have a need in the RIPE NCC service region. The address space must be originated from the RIPE NCC service region. Due to the diverse nature of businesses, in addition to this there can be announcements from other regions. Just to make 110% certain, you're saying here that it is the *need* that must be in the RIPE region, not the *organisation*, correct? The need and the route origination must be in the RIPE NCC service region.

Example 1: China Unicom sets up a legal organisation in the Netherlands, joins the NCC, and requests an allocation from which they intend to assign addresses to broadband customers in China. They intend to advertise the allocated prefix(es) to peers at AMS-IX (as well as from other exchange points around the world). This example would be ok for several reasons: The requestor is a RIPE NCC member. They have infrastructure in the region and the address space will originate from the RIPE NCC service region. Other similar examples would be VPN Providers but also Satellite

Hi Tore, On 5/23/12 12:01 PM, Tore Anderson wrote: providers that are based in the region and have customers globally.

Example 2: I, representing an existing LIR in the RIPE region, build a data center in Australia and set up a server hosting business there. I want to make an assignment to a new customer in this data center from my IPv4 allocation received from the RIPE NCC, and request that from the NCC hostmater using a ripe-488 form.

As long as the prefix is originated in the RIPE NCC service region, this would be approved. The LIR has an allocation, is announcing it in the RIPE NCC service region, and is making PA assignments to its customers. Regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

Assuming all the documentation is otherwise in order and the need is real, will these requests be granted or denied?

Best regards,

Randy, On Thursday, 2012-05-24 07:32:02 +0900, Randy Bush <randy@psg.com> wrote:

...

The need and the route origination must be in the RIPE NCC service region.

ahem! the ncc has repeatedly said over many years that it has nothing to do with routing.

I don't think this is true. For example, I remember the requirements for IPv4 PI space have included peering. I think a more accurate claim is that the RIPE NCC has always said that they don't guarantee that any resource you are issued can be routed. This makes sense, because that is between you and your peers (and the rest of the Internet). So, you may need to meet certain routing requirements to qualify for resources. But once you get them it's up to you to make them work. Cheers, -- Shane

David, On Thursday, 2012-05-24 09:12:38 -0700, David Conrad <drc@virtualized.org> wrote:

On May 23, 2012, at 11:34 PM, Shane Kerr wrote:

...

On Thursday, 2012-05-24 07:32:02 +0900, Randy Bush <randy@psg.com> wrote:

...

...

The need and the route origination must be in the RIPE NCC service region.

ahem! the ncc has repeatedly said over many years that it has nothing to do with routing. I don't think this is true.

Actually, all the RIRs have said this.

I'm pretty sure that the RIPE NCC has said that it can't guarantee route-ability, not that it has nothing to do with routing. Because, frankly, that would be insane considering the whole point of maintaining these databases of who can use which numbers is to allow people to connect computers together on the Internet! Plus the RIPE NCC runs the ROUTING Information Service (RIS), a ROUTING Registry Database (RRD), a ROUTING Public Key Infrastructure (RPKI) effort, attempts ROUTE de-bogonizing, and so on. My understanding is that the RIRs don't want to get involved with peering relationships between LIRs. I assume that the LIRs are also quite happy with the RIRs staying out of their business.

...

So, you may need to meet certain routing requirements to qualify for resources.

Historically, this was _not_ the case. Long, long ago, there was a bit of a dust up between the IAB and (at least some) RIR folks that resulted in RFC 1814. However, that was long ago and policies might have changed.

In the very first IPv6 allocation policy, we see the following: a. The requesting organization's IPv6 network must have exterior routing protocol peering relationships with the IPv6 networks of at least three other orga- nizations that have a sub-TLA allocated to them. That's RIPE 196, from the late 20th century. I'm not sure if that counts as "historically" or not. ;) Additionally, the AS number form, the IPv6 PI form, and the temporary PI assignment form in the RIPE region *currently* all request information about peering relationships. (I think, but am not sure, that only the AS number assignment actually requires peering though.) -- Shane

Shane, On May 29, 2012, at 2:12 AM, Shane Kerr wrote:

I'm pretty sure that the RIPE NCC has said that it can't guarantee route-ability, not that it has nothing to do with routing. Because, frankly, that would be insane considering the whole point of maintaining these databases of who can use which numbers is to allow people to connect computers together on the Internet!

I thought the whole point of maintaining the databases was to ensure uniqueness and provide contact information in the event of network-related issues. That is a necessary but not sufficient requirement for connecting computers together or the Internet. The point of the statement "RIRs have nothing to do with routing" is to emphasize that the other requirements for connecting computers to the Internet are outside of the RIRs' control. Regards, -drc

John, On May 29, 2012, at 8:42 AM, John Curran wrote:

...

The point of the statement "RIRs have nothing to do with routing" is to emphasize that the other requirements for connecting computers to the Internet are outside of the RIRs' control. It is possible that the goals in RFC 2050 are worth reevaluating (in light of IPv4 runout, the nature of IPv6, etc.) but the community has yet to perform

On May 29, 2012, at 10:05 AM, David Conrad wrote: that task and so it should not be surprising in the meantime that some policy discussions in the regions may take into consideration more than simply the single goal of ensuring uniqueness.

I was, of course, speaking of the historical RIRs that focused on being registries. As I stated, policies change. Regards, -drc

John, On May 29, 2012, at 11:36 AM, John Curran wrote:

I believe that both presently and historically the RIR communities have considered the goals of "conservation" and "routability" in addition to uniqueness.

Sigh. As much as I might enjoy challenging the hairsplitting and revisionism you wish to engage in, I'll pass this time. Perhaps we can just agree to disagree that historically, the RIRs stated that they "have nothing to do with routing" (since I'm sure you'll just continue to ignore the use of the active verb as opposed to the noun "routability"). Enjoy! Regards, -drc

On 5/29/12 4:05 PM, David Conrad wrote:

Shane,

On May 29, 2012, at 2:12 AM, Shane Kerr wrote:

...

I'm pretty sure that the RIPE NCC has said that it can't guarantee route-ability, not that it has nothing to do with routing. Because, frankly, that would be insane considering the whole point of maintaining these databases of who can use which numbers is to allow people to connect computers together on the Internet!

I thought the whole point of maintaining the databases was to ensure uniqueness and provide contact information in the event of network-related issues. That is a necessary but not sufficient requirement for connecting computers together or the Internet. The point of the statement "RIRs have nothing to do with routing" is to emphasize that the other requirements for connecting computers to the Internet are outside of the RIRs' control.

The true point is that routing policy was successfully kept out of IETF, because it has no place there (IETF is protocol re-inventing task force). ...and routing policy was successfully kept out of RIPE (and other RIRs communities), because apparently it does not belong there. Do we need another entity, maybe called "routing police"? I'm taking this to extremes with such a naming suggestion, just to make us think about if we need it and if yes, what would be the purpose. Cheers, Jan

Hi Daniel, The IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region state that ' These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.' In addition, RFC 2050 says: "This document makes a distinction between the allocation of IP addresses and the assignment of IP addresses. Addresses are allocated to ISPs by regional registries to assign to its customer base. ISPs who exchange routing information with other ISPs at multiple locations and operate without default routing may request space directly from the regional registry in its geographical area. ISPs with no designated regional registry may contact any regional registry and the regional registry may either handle the request or refer the request to an appropriate registry." The RIPE NCC interprets these statements as we explained on the mailing list. If the RIPE community feels this interpretation is not correct, do let us know. Regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 5/24/12 9:09 AM, Daniel Roesen wrote:

On Wed, May 23, 2012 at 11:13:15AM +0200, Ingrid Wijte wrote:

...

The address space must be originated from the RIPE NCC service region. Due to the diverse nature of businesses, in addition to this there can be announcements from other regions. Could you please point us to the policy requiring such routing requirements?

Best regards, Daniel

good morning ingrid,

...

ISPs who exchange routing information with other ISPs at multiple locations and operate without default routing may request space directly from the regional registry in its geographical area.

it has been fairly well measured that 70% of ASs have some form of default. so kiss a whole bunch of member LIRs goodbye and recover some precious IPv4 address space or fix that wording. i recommend the latter.

to be really clear on this one, see my preso from ripe/praha http://archive.psg.com/100505.ripe-visibility.pdf and the paper R Bush, O Maennel, M Roughan, S Uhlig, "Internet Optometry: Assessing the Broken Glasses in Internet Reachability", ACM SIGCOMM Internet Measurement Conference, November 2009. <http://archive.psg.com/optometry.pdf> "operate without default routing" is just not what's happening. randy