[address-policy-wg] Re: 200 customer requirements for IPv6

Marc van Selm wrote:
> On Wednesday 07 December 2005 15:52, Jeroen Massar 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 
> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20060104/6bfde39e/attachment.sig>