This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?
- Previous message (by thread): [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?
- Next message (by thread): [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Tuomi
tuomi at ventiro.se
Wed Mar 30 12:21:54 CEST 2011
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4697 bytes Desc: not available URL: </ripe/mail/archives/address-policy-wg/attachments/20110330/96cee0eb/attachment.p7s>
- Previous message (by thread): [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?
- Next message (by thread): [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]