Marc van Selm wrote:
Which companies? According to the stats* Leo gave only 6 requests where ever denied based on this. Can these companies please come forward and explain what they exactly want? [..] Now NATO can work around the 200-rule because NATO has its own service
On Wednesday 07 December 2005 15:52, Jeroen Massar wrote: [..] provider and we decided to consider NATO as an alliance of organizations. That is actually how NATO works so it is not bending the truth at all. So there are 200+ customers.
Larger companies and organizations have an IT department, which most of the times even is an officially registered separate branch of such an organization. Branches of larger organization are also separately registered organizations, especially when crossing country borders this becomes very obvious for tax reasons and country law. The IT department or even special Networking department is effectively the "ISP" for the organization. That they only service customers of their mother company is not the question here: they service 200 customers. Another point with the 200 rule is that any employee making a vpn connection towards the network can already be consider to be a different endsite.
But it is a bit artificial. I don't expect RIPE will reject a request but it illustrates the hoops that a large org with a large network that is part of their strategic assets will have to go through.
Which hoop? Any construct of the above will have no problem in getting address space from any of the RIR's. If they do try and get rejected they should explain their situation here, if possible, and explain what they are missing so that the policy can be amended or a special policy be created for these cases.
Again, I think we have a solid work around but looking at the controversy that this discussion has caused, a non ISP-centric policy would be useful.
The only complains I have seen so far, from people who don't fit the magic 200 rule, is from sites that are real end-sites, sites that don't have any/much infrastructure except towards the IX or interconnect point with their upstream(s) and appear to not provide any/much connectivity to other organizations. For those sites a /32 would also be way too much address space, they would suffice with either a /40 or /48 already. For these sites there should come a separate policy so that they can request this address space, preferably allocated from a single global prefix for filtering reasons. Note very well that RIR's provide "Address Space", not "Routability", the latter is what you and your upstreams agree on. As a side note, any large organization using multiple access providers to connect to the Internet will budge into a hard problem, though this is mostly a routing issue: One has a /32, say 2001:db8::/32, which is the allocation for your organization. 2001:db8:1000::/48 is Amsterdam, 2001:db8:f000::/48 is Singapore. An employee from Singapore accesses a website in London. Traffic thus flows Singapore -> .sg ISP -> $inet -> London, the return traffic though flows London -> .nl ISP -> Amsterdam... oops. Indeed even though one gets a /32 allocated one will have to announce the /48's separately, or use some weird VPN tricks, when one doesn't have their own internal transit network. The problem here is again the filtering of >/32 which is taking place, though getting less in most places it still can cause a problem. Another more policy-wise issue with the above is that the idea and advantage of "Provider Aggregated" and thus less routes in the routing tables is mostly gone as most sites, the ones who effectively don't have their own transit networks, will have to announce the more specifics anyway. When the routing tables become $too_large there will have to be something to solve this issue and IMHO the PA idea will be great then, but will require that end-sites do some a double-NAT trick ala shim6 to/from the /48 which they got from their provider, that is the one with a global network.... Greets, Jeroen BTW: Everybody can of course use their IPv4 space to create IPv6 space: 2002:<aa.bb>:<cc.dd>::/48 or even bigger if you use your /24. Traffic engineering and everything works for that, one will have to rely on having working 6to4 relays though. But that is the same as having to rely on a working transit provider at the other end.