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

Tim Streater wrote:
> At 17:00 17/11/2005, Jeroen Massar wrote:
>> Tim Streater wrote:
>>
>>> It should go. We manage a transit network connecting Middle-eastern
>>> and North African national research networks (NRENs).
>>> The aim is that this grouping go independent of us at some point
>>> and manage everything themselves.
>> So in say 10 years you are not managing it anymore? Most NREN's already
>> have plenty of address space, so why not use that address space?
> 
> We are an LIR and we already have a /32 for the European NREN transit
> network that we also manage (GEANT).
> You don't use customer address space to address your transit network.

Hold on here. *You* are the LIR, have already a /32 and are already
using it for management, but won't use it yourself? Or do you mean that
you want multiple /32's because you have multiple projects which should
actually be separate? If I understand correctly you see your own network
GEANT, for which you have the /32 already, as a customer and you expect
it to go away?

Can you elaborate on this (again, as I recall that this came up before)
maybe this time in ASCII or Visio style? That might better illustrate
what exact problem you are having and what then the solutions might be.
It seems to be a really strange construct, at least doesn't seem to make
any sense to me. Could very well be me of course.

> What happens if that customer goes bankrupt or wants the space back
> or takes their custom elsewhere? And it's intended to be a couple of
> years, not 10.

Couple, thus 2 or 3? If you only plan to use it for a 'couple' of years,
then you can also use other address space from other entities. Doesn't
really matter if you change after X years or directly, you already
planned to change anyway, thus if they go bankrupt, belly up, zapped to
another dimension, you are changing anyway.

>>> I was able to get v4 PI space for
>>> this from RIPE, but the 200 rule appears to rule out these guys using
>> v6. Oh well.
>>
>> Do you need a /32 full of address space or do you want PI?
>> If you only need a single /48, then requesting a /32 is quite silly
>> don't you think? And also quite a waste.
> 
> We don't need a /32 obviously. Can we get a /48? And can we get it routed?

One can get anything routed. Use ULA to generate your own random prefix
and use it. I am quite sure that it will reach quite far. You only want
to use it for management (and transit?) for your own network anyway and
the ones who participate in your organisations can surely be persuaded
to receive the route.

>> Do note, that this is nothing against you, but if you get a /32 because
>> you want PI, then a lot of other small organisations (read: individuals)
>> may want one.
>>
>> Constructive part, same style as to the NATO one:
>> - You have 50 PoPs.
>> - You have say 150 employees
>>
>> (both can be a plan, you might fail but hell.. it still is a plan)
> 
> So you're saying we should lie to RIPE when necessary?

Why is that a lie? Unless you actually are a homeuser (which you are
not) or some very small ISP who doesn't want customers (which isn't the
case either). I really can't see why you can't get address space under
the current policy. For that matter: did you ever try? Or even simpler,
did you ask RIPE NCC? Instead of just saying "we can't, change the policy"

> Seems to me much better to adjust the policies to fit reality.

Reality looks more that you want PI space, or actually a slot in the
routing tables. As ULA's already provide PI space, they just don't
directly give a slot in the routing tables.


Sidestep note: one can also use 2002::/16. You will have to run a 6to4
relay then, but this will give you "PI IPv6 space". You can then
announce a more specific to your friendly neighbors. People who filter
will use 2002::/16 to reach you.

Greets,
 Jeroen

-------------- 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/20051117/7f976352/attachment.sig>