IPv6 PI request is turned down for my multihomed hosting facility - Why?
Hi, A have made a request for a IPv6 PI / 48 allocation for my hosting facility. I am mostly hosting shared services, but I also have a lot of Co-located services for my customers. I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434). My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option. The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers). Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services. At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc. There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services. Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only.... So what should I do? What are my options? // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05
The way to go is for you to establish as an LIR. (Small or Extra Small). http://www.ripe.net/lir-services/member-support/become-a-member regards, --nvieira ----- Original Message -----
Hi,
A have made a request for a IPv6 PI / 48 allocation for my hosting facility.
I am mostly hosting shared services, but I also have a lot of Co-located services for my customers.
I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434).
My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option.
The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers).
Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services.
At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc.
There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg
I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services.
Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only....
So what should I do? What are my options?
// Janne
On 30 March 2011 09:25, Jan Tuomi <tuomi@ventiro.se> wrote:
So what should I do? What are my options?
Join RIPE as an LIR, get your own /32 PA space that you can then provide to your customers J -- James Blessing 07989 039 476
On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote:
So what should I do? What are my options?
// Janne
If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32. I'm a sponsoring LIR, and I turned down several times some of my customers asking for PI ressources because I knew that their request would not fit the RIPE policies and that their only way was PA from my space or become LIR. Mainly it's because the cannot justify the space their requesting (for IPv4) or they want to do end-user-assignement (for IPv4/IPv6) which is your case here. I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6. Regards, -- Pierre-Yves Maunier AS8218 IP/Project Engineer pymaunier@neotelecoms.com Neotelecoms 21 rue La Boétie, 75008 Paris, France
W dniu 2011-03-30 10:43, Pierre-Yves Maunier pisze:
I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6.
And 1.5k € invoice to pay, yearly. Regards -- Adrian
On 30 Mar 2011, at 10:43, Pierre-Yves Maunier wrote:
On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote:
So what should I do? What are my options?
// Janne
If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32.
.... I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6.
this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation). Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot"). If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both. Would it be time to revisit the coherency of this whole thing as a whole? Joao
On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote:
On 30 Mar 2011, at 10:43, Pierre-Yves Maunier wrote:
On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote:
So what should I do? What are my options?
// Janne
If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32.
.... I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6.
this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation).
Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot").
If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both.
Would it be time to revisit the coherency of this whole thing as a whole?
Joao
I agree with you but on my side, I only help customers to become LIR when they plan to have a good usage of their IPS. For example : I definitly won't help any customer to have a /21 PA based only on their multihoming needs and if they can only justify only a /27. I agree again, it's weird. It's not possible to have a /24 PI for your own needs if you can only justify a /27 but you can get a /21 PA becoming a LIR. -- Pierre-Yves Maunier AS8218 IP/Project Engineer pymaunier@neotelecoms.com Neotelecoms 21 rue La Boétie, 75008 Paris, France
Hi, On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote:
this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation).
Conservation is not one of the primary goals for IPv6. Routing table size (=aggregation) *is* - which is why the consensus of this group, some years ago, was "be restrictive on PI". Now, this particular problem ("datacenter business") has been showing up a few times in the last 1.5 years, and in the end, it boils down to a number of considerations that are NOT easily solved. - the distinction between PA and PI is, conceptually, "PA is for ISPs that want to number (their) customers" "PI is for customers that want to number their own(!) network in an independent way" --> and this is why the chunk size is much bigger for PA, because it's meant to give an ISP a chunk that is so large that they will not need to come back for more space in the near future (-> which is good for routing aggregation), even taking lots of customers with a /48-each into account. PI is a /48, because "that's enough for one customer". - PI has been positioned as "cheap", so it's not a major hurdle for small "non-isp" companies that want/need independent address space - PA is "expensive", because it's only given to LIRs, and all the LIRs around share the expense of having the RIPE NCC do their job --> so, if a large number of ISPs change to run their IPv6 business on PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* (the NCC's expenses pretty much stay the same, and get distributed to less paying members). So from a fairness point of view, there's good reason to ask everybody who is running an ISP-like business to become a LIR, and pay their share, staggered by "ISP size". - there's another twist to it: we want to encourage access providers (DSL, cable, ...) to give their customers a /56 or /48 - which the current PA policy permits just fine. Now if they could get a PI block to number their 5 million DSL users, these customers would end up with single-IPv6-assignments and IPv6 NAT... (We see this in IPv4 today, access ISPs that run all of their DSL network on PI space, as the IPv4 policy has a clause that permits doing so [transit networks to the customer are considered "part of the PI", and if all you give the customer is a single IP for their router...]) ... so, given this, "just open PI space and give everbody who asks their /48" is not without risks and costs - talking about good stewardship, and such :-)
Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot").
You don't get the IPv4 space unless you demonstrate need. It's not like the IPv4 PA allocation is automatic.
If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both.
Well - the PI policies are *exactly* what the community(!) made them...
Would it be time to revisit the coherency of this whole thing as a whole?
Definitely. There's a "change the PI policy" proposal coming up, and Sander and I are trying to come up with good ideas to get the whole complex better "balanced out". Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hello, On 30 mar 2011, at 11.44, Gert Doering wrote:
Hi,
On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote:
this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation).
Conservation is not one of the primary goals for IPv6.
Routing table size (=aggregation) *is* - which is why the consensus of this group, some years ago, was "be restrictive on PI".
What is the difference in allocating one /48 PI-block or one /32 PA-block from a routing table size view? there still is one route in both cases because I need multihoming....
Now, this particular problem ("datacenter business") has been showing up a few times in the last 1.5 years, and in the end, it boils down to a number of considerations that are NOT easily solved.
- the distinction between PA and PI is, conceptually,
"PA is for ISPs that want to number (their) customers"
"PI is for customers that want to number their own(!) network in an independent way"
Should I consider myself as an ISP? I am not selling internet access to my customers locations, the customers is running their servers in my facility, in my rack, on my switches, firewalls and routers, they dont have physical access without me or someone from my staff being present. From my point of view, it is MY OWN network, not theirs.
- PI has been positioned as "cheap", so it's not a major hurdle for small "non-isp" companies that want/need independent address space
- PA is "expensive", because it's only given to LIRs, and all the LIRs around share the expense of having the RIPE NCC do their job
--> so, if a large number of ISPs change to run their IPv6 business on PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* (the NCC's expenses pretty much stay the same, and get distributed to less paying members). So from a fairness point of view, there's good reason to ask everybody who is running an ISP-like business to become a LIR, and pay their share, staggered by "ISP size".
But the price is the same... EXTRA SMALL, LIR: Sign-up Fee (€ 2000) + Service Fee (€ 1,300) EXTRA SMALL, Direct Assignment User: Administration Fee (€ 2000) + Service Fee (€ 1,300) So it would be any difference, I got the question of becoming a DAU and pay directly to RIPE or set up a contract with one of my ISPs. I choosed the last one because it was a little bit cheaper (not much), seemed easier to get a swedish invoice from a swedish company, and not to bug RIPE with more end user administration than necesary... Is it about that? Did I make the wrong choice in not becoming a DUA directly against RIPE? // Janne
Hi, On Wed, Mar 30, 2011 at 12:21:54PM +0200, Jan Tuomi wrote:
Conservation is not one of the primary goals for IPv6.
Routing table size (=aggregation) *is* - which is why the consensus of this group, some years ago, was "be restrictive on PI".
What is the difference in allocating one /48 PI-block or one /32 PA-block from a routing table size view? there still is one route in both cases because I need multihoming....
Sure, and the PI policy requires "multihoming" for that reason - to permit PI for the cases that were clearly understood at that time: if someone wants/needs to do BGP-based multihoming, they will consume a routing table slot anyway. Now *this* discussion didn't start with "the multihoming requirement" but with "what can I use PI for" - which is a different restriction, and I tried to explain that these are interconnected and it is not that easy to untangle things in a way that the end result is better than what we have now.
Now, this particular problem ("datacenter business") has been showing up a few times in the last 1.5 years, and in the end, it boils down to a number of considerations that are NOT easily solved.
- the distinction between PA and PI is, conceptually,
"PA is for ISPs that want to number (their) customers"
"PI is for customers that want to number their own(!) network in an independent way"
Should I consider myself as an ISP? I am not selling internet access to my customers locations, the customers is running their servers in my facility, in my rack, on my switches, firewalls and routers, they dont have physical access without me or someone from my staff being present. From my point of view, it is MY OWN network, not theirs.
Sounds like you're providing "Internet Services" to your customers - you make sure that their web presence can be reached from "the Internet". As I have tried to explain - this is where the distinction PA/PI came from, and indeed, you seem to match a loose definition of "ISP" quite well - an ISP isn't only "runs DSL lines to folks". We know that datacenter is problematic, as the boundaries between "this is MY NETWORK and MY SERVERS" and "this is MY NETWORK and THEIR servers" and "this is MY NETWORK connecting to THEIR firewall, and THEIR network behind the firewall" is floating.
- PI has been positioned as "cheap", so it's not a major hurdle for small "non-isp" companies that want/need independent address space
- PA is "expensive", because it's only given to LIRs, and all the LIRs around share the expense of having the RIPE NCC do their job
--> so, if a large number of ISPs change to run their IPv6 business on PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* (the NCC's expenses pretty much stay the same, and get distributed to less paying members). So from a fairness point of view, there's good reason to ask everybody who is running an ISP-like business to become a LIR, and pay their share, staggered by "ISP size".
But the price is the same... EXTRA SMALL, LIR: Sign-up Fee (? 2000) + Service Fee (? 1,300) EXTRA SMALL, Direct Assignment User: Administration Fee (? 2000) + Service Fee (? 1,300)
PI costs 50 EUR/year per assignment if you go through a sponsoring LIR (which is the recommended way of doing it) in RIPE fees, plus some extra that the sponsoring LIR is usually adding as a handling fee. If you intend on becoming a Direct Assignment User, go for "LIR", and stop worrying on PA vs. PI and sub-assignments.
Is it about that? Did I make the wrong choice in not becoming a DUA directly against RIPE?
Well, if you're a hosting provider, and the question is "DUA or LIR", go for LIR. If the question is "PI via a local LIR" vs. "become a LIR yourself", there's a larger monetary difference, and some argue that this is too expensive and will drive them out of business. We *are* listening to that, but have no easy answer yet. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, As far as I'm concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time finding such terms. ____________________________________ Tero Toikkanen Nebula Oy From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: 30. maaliskuuta 2011 11:25 To: address-policy-wg@ripe.net Subject: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? Hi, A have made a request for a IPv6 PI / 48 allocation for my hosting facility. I am mostly hosting shared services, but I also have a lot of Co-located services for my customers. I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434). My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option. The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers). Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services. At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc. There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services. Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only.... So what should I do? What are my options? // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05
W dniu 2011-03-30 10:58, Tero Toikkanen pisze:
Hi,
As far as I’m concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I’m having a hard time finding such terms.
http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider Most important is the last sentence: The PI assignment cannot be further assigned to other organisations. And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. Regards -- Adrian
* Adrian Czapek:
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
With that interpretation, isn't it impossible to use IPv6 PI space to provide addresses to personal computers? But seriously---does the working group think that IPv6 PI space should not be used for hosting customer web sites, and that the current policy does not allow this? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
With that interpretation, isn't it impossible to use IPv6 PI space to provide addresses to personal computers?
But seriously---does the working group think that IPv6 PI space should not be used for hosting customer web sites, and that the current policy does not allow this?
http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space "PI space cannot be re-assigned or further assigned to other parties." The text is the same for IPv4 PI and IPv6 PI, but you still can't get both for the same use. Why not? In my opinion the policy is the same for both, but it seems it's not interpreted in the same way. ____________________________________ Tero Toikkanen Nebula Oy
On 30 Mar 2011, at 11:17, Tero Toikkanen wrote:
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
With that interpretation, isn't it impossible to use IPv6 PI space to provide addresses to personal computers?
But seriously---does the working group think that IPv6 PI space should not be used for hosting customer web sites, and that the current policy does not allow this?
http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space
"PI space cannot be re-assigned or further assigned to other parties."
Even that is seemingly subject to weird and unclear interpretation. For instance if you rent/lease equipment for others to use (but remain the owner of such equipment as what you are selling is the service), according to IPRAs at the RIPE NCC it is OK to use PI space if the equipment is reachable via a LAN but not if the site is remote (e.g. using DSL), even if from a network point of view it is all the same net. Apparently, in some cases, policy application may be subject to the color of the physical cable used. See presentation during AOB at the APWG at the last RIPE Meeting. Joao
Hi, On Wed, Mar 30, 2011 at 09:17:31AM +0000, Tero Toikkanen wrote:
http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space
"PI space cannot be re-assigned or further assigned to other parties."
The text is the same for IPv4 PI and IPv6 PI, but you still can't get both for the same use. Why not? In my opinion the policy is the same for both, but it seems it's not interpreted in the same way.
Actually, there's a significant difference and that has been pointed out a number of times on the list and at the last RIPE meetings. The IPv4 policy has this sentence: http://www.ripe.net/ripe/docs/ripe-509#----network-infrastructure-and-end-us... 6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. ... and this specific clause is not in the IPv6 policy, so "networks used to number end customers" are considered "part of the assignment to this end customer". (Which makes sense for DSL and cable etc. networks, where you really want to assign a /56 or /48 anyway, and not start tricking around with single-address-assignment from PI blocks) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
The IPv4 policy has this sentence:
http://www.ripe.net/ripe/docs/ripe-509#----network-infrastructure-and- end-user-networks
6.2 Network Infrastructure and End User Networks
IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User.
... and this specific clause is not in the IPv6 policy, so "networks used to number end customers" are considered "part of the assignment to this end customer".
(Which makes sense for DSL and cable etc. networks, where you really want to assign a /56 or /48 anyway, and not start tricking around with single- address-assignment from PI blocks)
Right. Thanks for clearing this up Gert. In any case, this should be clearer in the policies as it is easy to get confused because IPv4 PI != IPv6 PI in terms of what you can do with it. Also, policy interpretation within RIPE NCC should be sorted out (unless it already is), as I distinctly remember getting IPv6 PI for a customer for hosting purposes a year ago. ____________________________________ Tero Toikkanen Nebula Oy
Hi, On Wed, Mar 30, 2011 at 10:28:19AM +0000, Tero Toikkanen wrote:
Also, policy interpretation within RIPE NCC should be sorted out (unless it already is), as I distinctly remember getting IPv6 PI for a customer for hosting purposes a year ago.
Nothing wrong with "I run my own datacenter and host my own servers there, and want to number them with my own IPv6 PI space". The bit where you provide services "to other parties" is where things get problematic, when the policy has a "no sub-allocations / sub-assignments to 3rd parties" clause. (No need to enumerate the large amount of different possible ways to run "a hosting business" here) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 30 mar 2011, at 11.08, Adrian Czapek wrote:
W dniu 2011-03-30 10:58, Tero Toikkanen pisze:
Hi,
As far as I’m concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I’m having a hard time finding such terms.
http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider
Most important is the last sentence: The PI assignment cannot be further assigned to other organisations.
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
Regards -- Adrian
So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05
Hi Jan, If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don't provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP's, that is acceptable for PI is my experience with the IPRA's. If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn't multi-homed (I assume) and that is (still) another requirement for IPv6 PI. I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. Regards, Erik Bais From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? On 30 mar 2011, at 11.08, Adrian Czapek wrote:
W dniu 2011-03-30 10:58, Tero Toikkanen pisze:
Hi,
As far as I'm concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time finding such terms.
http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider
Most important is the last sentence: The PI assignment cannot be further assigned to other organisations.
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
Regards -- Adrian
So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11
Hi Erik, Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider? My problem is that I actually am multi-homed, therefor I need IPv6-PI.... And if my customers have their servers in my facility they also are multihomed? So they could request for their own PI? that really doesnt make sensee, that would really clog down the routing tables.... The hosting network is today set up so each customer get their own IPv4 /29 of Private addresses, then I NAT a public IP on a first come-first served basis. The reason they have an own IPv4 Net on the inside is to gain some security between servers in the facility... With IPv6 I obviously dont want to use NAT, so I will set up a small IPv6 Network for each server, just as i do with IPv4, but without the NAT-part.. So instead of setting up a singe IP to the server I set up a network, but basically its the same... so the change request about removing multi-homing requirement doesnt make sense in my case.... I think the requirement is a good thing because i dont see ANy reason to get PI-space if you are not multihomed. // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 On 30 mar 2011, at 12.32, Erik Bais wrote:
Hi Jan,
If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don’t provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP’s, that is acceptable for PI is my experience with the IPRA’s.
If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn’t multi-homed (I assume) and that is (still) another requirement for IPv6 PI.
I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon.
Regards,
Erik Bais
From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?
On 30 mar 2011, at 11.08, Adrian Czapek wrote:
W dniu 2011-03-30 10:58, Tero Toikkanen pisze:
Hi,
As far as I’m concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I’m having a hard time finding such terms.
http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider
Most important is the last sentence: The PI assignment cannot be further assigned to other organisations.
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
Regards -- Adrian
So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database?
Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly?
hmm.. seems that I have to forget about IPv6 and continue running IPv4 only....
// Janne
_______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05
No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11
Hi Jan, I come across customers who want to get into IPv6 and have their own IP addresses. However they don't want to multi-home (yet), they want to have the flexibility to change providers if needed without having to re-number their complete infrastructure / vpn devices / dns servers etc etc The only way for those customers to help them currently is to tell them to: A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR's who are not multi-homed or just have some other company run their IP space under another AS. B: Request PI IPv6, invest in multi-homing equipment and knowledge, connect to a competitor and proceed. As LIR's don't have the requirement to multihome their IP space, means that the community is in agreement that this PI IPv6 space required a hurdle in order to stop a wild-growth on the IPv6 routing table growth, however if someone pays their way into the community (become a LIR), nobody cares anymore about the routing table growth and we gladly take your money and proceed. Having said that, this is a financial decision and not a technical routing table growth mediation rule. And it should be treated as such. The proposal change I've done is to remove the multi-homing requirement, and ask the GM meeting to increase the cost for PI IPv6 from 50 euro to 250 euro to keep all things equal. That would still allow customers who want their own PI IPv6 to be able to request it for their own infrastructure, without having them to force them into my competitors arms or having them to shell-out 3300 euro to become a LIR, if they don't want to become a LIR for their specific reasons. There is no difference for those kind of customers in the routing table if you would receive a /32 (new LIR) or a /48 (new PI IPv6 without multi-homing). On the part of colocation services as what you are doing / describing (your customer financially OWNS their servers), that is against the intention of PI (both IPv4 and IPv6) space. And as such your request got denied is my guess. Regards, Erik Bais From: Jan Tuomi [mailto:tuomi@ventiro.se] Sent: Wednesday, March 30, 2011 1:02 PM To: Erik Bais Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? Hi Erik, Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider? My problem is that I actually am multi-homed, therefor I need IPv6-PI.... And if my customers have their servers in my facility they also are multihomed? So they could request for their own PI? that really doesnt make sensee, that would really clog down the routing tables.... The hosting network is today set up so each customer get their own IPv4 /29 of Private addresses, then I NAT a public IP on a first come-first served basis. The reason they have an own IPv4 Net on the inside is to gain some security between servers in the facility... With IPv6 I obviously dont want to use NAT, so I will set up a small IPv6 Network for each server, just as i do with IPv4, but without the NAT-part.. So instead of setting up a singe IP to the server I set up a network, but basically its the same... so the change request about removing multi-homing requirement doesnt make sense in my case.... I think the requirement is a good thing because i dont see ANy reason to get PI-space if you are not multihomed. // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 On 30 mar 2011, at 12.32, Erik Bais wrote: Hi Jan, If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don't provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP's, that is acceptable for PI is my experience with the IPRA's. If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn't multi-homed (I assume) and that is (still) another requirement for IPv6 PI. I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. Regards, Erik Bais From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? On 30 mar 2011, at 11.08, Adrian Czapek wrote:
W dniu 2011-03-30 10:58, Tero Toikkanen pisze:
Hi,
As far as I'm concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time finding such terms.
http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider
Most important is the last sentence: The PI assignment cannot be further assigned to other organisations.
And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.
Regards -- Adrian
So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 _____ No virus found in this message. Checked by AVG - www.avg.com <http://www.avg.com/> Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11
Hi, On Wed, Mar 30, 2011 at 01:18:44PM +0200, Erik Bais wrote:
As LIR's don't have the requirement to multihome their IP space, means that the community is in agreement that this PI IPv6 space required a hurdle in order to stop a wild-growth on the IPv6 routing table growth, however if someone pays their way into the community (become a LIR), nobody cares anymore about the routing table growth and we gladly take your money and proceed.
That (money) is not the specific point why there is no multihoming requirement for a LIR. Consider a LIR with 4000 customers that wants to change upstream - they not only have to renumber their own network, but also renumber 4000 customers, which is roughly 4001 times the amount of work compared to "one end customer needs to renumber". This community has decided that the burden of renumbering every now and then is considered acceptable for an end customer (given that we need to balance with the routing table, and there are MANY MORE end customers than LIRs - the routing system will not be able to handle "every end customer is using PI space"), but that LIRs are to be "the aggregation points" in the routing system, and the routing system will handle "1 route per LIR" just fine. Earlier proposals saw a strict limitation to "at maximum 8192 Top Level Aggregates are permitted into the routing system", but nobody has ever been able to define "who is an important-enough ISP to get a TLA and who is not, and has to closely tie their business to a competitor" - so we changed that to "every LIR is considered equally important and can get their own address block" (with an implied "to number their customers"). I'm not saying that we can't change the way it is now, mainly trying to explain how things came to be. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi,
A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR’s who are not multi-homed or just have some other company run their IP space under another AS.
They do have to provide IPv6 services to other organizations though: "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years." - Sander
On Mar 30, 2011, at 5:46 AM, Sander Steffann wrote:
A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR’s who are not multi-homed or just have some other company run their IP space under another AS.
They do have to provide IPv6 services to other organizations though: "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years."
A plan isn a plan and not a commitment, though. No-one's going to take the LIR's space away if they miss the target. On that basis, we know that this requirements is purely a form of words and has no real value. Regards, Leo
Hi Leo,
They do have to provide IPv6 services to other organizations though: "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years."
A plan isn a plan and not a commitment, though.
No-one's going to take the LIR's space away if they miss the target. On that basis, we know that this requirements is purely a form of words and has no real value.
I don't agree with you here. If you run a grocery store (or other non ISP business) it might be hard to show believable plan for making sub-allocations or assignments... And there is no target anymore, so there is nothing to miss ;-) - Sander
On 30 Mar 2011, at 13:02, Jan Tuomi wrote:
Hi Erik,
Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider?
I guess it is because, as IPv6 moves from using Powerpoint as its main transport to using Ethernet, people are finding out that renumbering is just as hard in IPv4 as it is in IPv6, so people want to be *Provider Independent* Joao
Hi, On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote:
So what this means is that if a customer puts their server in my facility I am sub-allocating?
Yes.
To sub-allocate I have to be an LIR and request an own PA-space?
Yes. As the definition of PI is "this is for you, and for you alone". (See the other long mail I've sent why this is not such a trivial matter)
For each customer I have to assign their own /64 and register it in the ripe-database?
You have to document it in a way that you can show the documentation to the RIPE IPRAs, but it does not have to be in the RIPE-DB (for IPv6). Whether you assign a /64 or a /60 (think "customer with a firewall and a load balancer and a backend network for the database") is a matter of local taste. If you run multiple customers in a shared network, you can of course give every customer just a single IPv6 address (not going into technicalities on cross-customer protection here).
Setting up an SSL-webhost is also sub-allocating?
This is very grey area. Technically, it's "giving an address to a 3rd party", but personally I'd see this is as "it's still the same machine under *your* control". But we already know that datacenter has all the range from "very obviously *not* sub-allocation" to "very obviously this *is* sub-allocation", and as such, distinction between "what is OK" and "what is not" is tricky at best. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 30 Mar 2011, at 13:14, Gert Doering wrote:
Hi,
On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote:
So what this means is that if a customer puts their server in my facility I am sub-allocating?
Yes.
No, you said before the addresses were for your own network, and the network remains yours independently of what hosts you connect to you. Hosting customers are not expecting to carry their individual server IP addresses with them when they change colo because they are part of the colo, so no, you are no sub-alloacting.
Setting up an SSL-webhost is also sub-allocating?
This is very grey area. Technically, it's "giving an address to a 3rd party",
not quite, as you remain the address holder. Do you charge each customer for their quota of airco in the facility explicitly?
but personally I'd see this is as "it's still the same machine under *your* control".
it definitely is the same network, at least as long as the customer does not have a router between your net and their equipment. Joao
Hi, On Wed, Mar 30, 2011 at 7:14 AM, Gert Doering <gert@space.net> wrote:
On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote:
Setting up an SSL-webhost is also sub-allocating?
This is very grey area. Technically, it's "giving an address to a 3rd party", but personally I'd see this is as "it's still the same machine under *your* control".
Right. I want to take this further by revisiting some core networking principles with a touch of v6: Control of usage of addresses, even in times of /64 v6 SLAAC-enabled LANs, remains with the party that switches and routes them, normally but not necessarily, to and on the Internet. This is the reality. Consider this for a while. APWG is fooling itself in thinking that it can control what addresses anyone configures on a host. Influence (in only a small way), yes. Control, no. The core registry function of RIPE *is* to facilitate Internetworking by avoiding addressing collisions. Put different, RIPE concerns itself primarily with assisting in organizing addressing, allowing networks to communicate, *not* specific hosts. The networks concern themselves with making hosts communicate. A host can have any address configured, free of consequence, until it is connected to a network. Much of the pain from APWGs policies comes, IMO, from the distance of the disconnect a policy has with reality. The further the disconnect, the greater the resulting pain and lies. Close the gap, reduce the pain and lies. PIv6 has a very big disconnect with reality right now IMO, which lately has become very evident. Tieing the "user" of addresses (in RIR sense) closer to the party that routes and switches them(*), ie the network, and away from the ones who configures them on a host stack, is 100% in line with RIPE's role as a registry. In IPv6 with SLAAC, this is particularly true. * For administrative reasons, it becomes at some point very burdensome to track usage (in RIR sense) at the RIR level of individual end-users (ie, home users) which is why a lower threshold of "allocations" in IPv4 of /30 was established long time ago. I believe the equivalent value in IPv6 is /48, which in itself probably is subject to considerations w.r.t BCP157 now. Conceptually, each organizational level in the addressing hierarchy should (for abuse- and law-enforcement purposes, I suppose..) be able to provide a pointer, a next-hop to the next entity in charge of something. In theory, RIPE's only pointer to resources delegated to a LIR could be to the LIR itself (who of course is free to keep its record in a public database such as RIPE's).
But we already know that datacenter has all the range from "very obviously *not* sub-allocation" to "very obviously this *is* sub-allocation", and as such, distinction between "what is OK" and "what is not" is tricky at best.
So let's substitute it for something that is clear, logical and consequential. :) Regards, Martin
So what should I do? What are my options?
Best option: take /48 from your LIR and deaggregate it (announce to the world under your ASN) Regards -- Adrian
Adrian, see the RIPE-510 document. You probably will have a connectivity problem. Wednesday, March 30, 2011, 10:59:58 AM, you wrote:
So what should I do? What are my options? AC> Best option: take /48 from your LIR and deaggregate it (announce to the AC> world under your ASN)
-- Sergey
On Wed, Mar 30, 2011 at 10:59:58AM +0200, Adrian Czapek wrote:
So what should I do? What are my options?
Best option: take /48 from your LIR and deaggregate it (announce to the world under your ASN)
Not the best for me. I think a couple of people are filtering /48s which are not in a PI reserved space (like 2001:678::/29), so this is not the best option for multihoming. Some LIRs also don't want their PA space to be announced by other ASes. -- Pierre-Yves Maunier AS8218 IP/Project Engineer pymaunier@neotelecoms.com Neotelecoms 21 rue La Boétie, 75008 Paris, France
participants (14)
-
Adrian Czapek
-
Erik Bais
-
Florian Weimer
-
Gert Doering
-
James Blessing
-
Jan Tuomi
-
Joao Damas
-
Leo Vegoda
-
Martin Millnert
-
Nuno Vieira - nfsi telecom
-
Pierre-Yves Maunier
-
Sander Steffann
-
Sergey Myasoedov
-
Tero Toikkanen