[address-policy-wg] Policy Proposal 2006-02 (IPv6 Address Allocation and Assignment Policy)

Hi Jeroen,

See below in-line.

Regards,
Jordi




> De: Jeroen Massar <jeroen at unfix.org>
> Organización: Unfix
> Responder a: <address-policy-wg-admin at ripe.net>
> Fecha: Sun, 18 Mar 2007 21:01:43 +0000
> Para: <jordi.palet at consulintel.es>
> CC: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net>
> Asunto: Re: [address-policy-wg] Policy Proposal 2006-02 (IPv6 Address
> Allocation and Assignment Policy)
> 
> JORDI PALET MARTINEZ wrote:
> [..]
>>> "The assigned prefixes must be longer than the one allocated by RIPE
>>> NCC." is useless as the LIR can't pass a shorter prefix down as they
>>> don't have been assigned that portion.
>> 
>> The goal of this part of the text is to avoid that a prefix is received and
>> assigned totally to the same customer.
> 
> So you want to avoid a /48 to be allocated to an organization who can
> then use it at their own site? What is the use of changing that then?

No, I want to avoid if an LIR get a /32 (minimum allocation as per existing
policy) that it allocates the complete /32 to a single customer.

> 
> 
>> So yes, can't pass a shorter prefix,
>> but could pass the same one and this will not be good as it can be a kind of
>> "bypass" of the rule in order to provide an alternative way for doing PI to
>> customer, which is not the intend of this proposal.
> 
> You want to avoid "PI" but you also state in the proposal to make the
> policies the same as other RIRs. Bit strange as they don't have these
> changes, they have a separate PI policy.

Out of context. What I'm saying is that other RIRs (LACNIC and AfriNIC)
don't have already the requirement for 200 /48s, and I think is ridiculous
for us to be more strict, especially when this is an artificial limit.

> 
> So for whom exactly are these changes that are proposed in this
> proposal? I don't see anyone really being helped by it and especially
> not the people who have actually been complaining.

Any LIR that want to do service, but doesn't have a plan for 200 sites and
don't want to lie when requesting the prefix.

> 
>>> The "must be advertised" part causes any non-internet usage to be 'illegal'.
>> 
>> Yes, this has been already raised before.
> 
> You stated that all the previous discussion was nullified and that all
> arguments should be raised again.

No. What is not useful here is the "yes I'm in favor" or "I'm against" for
the previous version of the proposal. Discussion is always useful, and in
fact, this version tried to accommodate all the discussions in the previous
version.

> 
>> In my opinion is difficult to
>> explain why an ISP could have a need to get a prefix and not use it in
>> Internet. If that's the need (customer demand), then he has three possible
>> alternatives (I'm not saying all are valid, but for sure one among these 3
>> will fit each possible case):
>> 
>> - Use of link-local addresses
> 
> Useless for this purpose as it only works on one link and is far from
> globally unique.

I clearly stated that I'm not saying all are valid, but one among these 3
...

> 
>> - Use of ULA
>> - Use of ULA-central (I know this is still not done, but I'm trying to
>> revive it already and you will see soon a new policy proposal on this
>> regards)
> 
> Neither of these can be globally routed. A company might today want to
> move to IPv6 and not have their network routed, ULA will then be fine
> indeed. But what if the user want to change to public addresses? Then
> they would have to renumber, while they can better get a public
> registered address space first, not announce it, and then announce it
> anyway later on.

No need to renumber, they just need to use one more prefix (a global one),
and keep using the existing ULA addressing if they still need it for
internal routing, keeping separate overlay networks, or whatever.

I think that somebody who plans adequately, will perfectly know if they need
a global prefix in one year term, and they can announce it even if they
decide not to allow incoming/outgoing traffic to the rest of the network.
The proposal is not asking to explicitly make all the internal network to be
visible, just to announce the prefix.

Also we are not asking RIPE to verify to every RIR every detail that they
need complain with every policy at every minute. Some flexibility is
reasonable, and that provides in most of the cases, extra time to comply
with the policy, without any impact in the community.

> 
> Most networks will end up being connected to the Internet or to another
> network one day or another, being able to globally route it is thus a
> requirement for quite some organizations. ULA's thus don't cut it.
> Unless you want to see those popping up in a BGP near you.

Filter them, in fact this should be a strong rule already in place in every
router, same as per link-locals, etc.

> 
>>> Also the "must advertise.. single..prefix" part is currently already not
>>> being honored; also you cannot require this and there is currently no
>>> way to stop that.
>> 
>> There are many details in may policies that are not being enforced by RIRs.
> 
> Then don't include them. It's like saying that jaywalking is illegal
> while everybody does it and nobody will actually care. Don't make it too
> difficult, don't try to bury things in words.
> 
>> That's debatable I think. Most of the LIRs follow the rules, some others
>> not. I'm not arguing here if this is good or bad, as this part of the text
>> is the same as in the existing proposal (may be different wording but
>> exactly the same meaning).
> 
> It is in the original one with different words and they are not enforced
> either.

So what is the problem then ?

If we actually have a problem on this, let's take it step by step, with
another policy proposal. I learn the lesson that trying to make very complex
changes in policy proposals is a "no way".

> 
>> As explained in previous emails, if we want to change that, it will be
>> better to do in a different policy proposal and have a different discussion
>> about that, otherwise it may become difficult to achieve consensus in the
>> main change here (removing the 200 /48).
> 
> This proposal changes the wording, you can then just as well also
> completely take out that part instead of fumbling with words.

I will be happy with that, but the consensus that I perceived is that the
community don't like that. They want to have at least a plan, and I think is
fair. I think we must rely on RIPE NCC staff to accept the plan or ask for
further justification if its fuzzy.

> 
>>> A way to stop it would be requiring S-BGP but that will not be done for
>>> the coming years. Also most likely S-BGP will still allow the owner of
>>> the certificate to announce more specifics.
>> 
>> Yes, this is a possibility, but I think there is a more realistic one. Let
>> market decide, if you break aggregation and as a consequence this cost money
>> to the rest of the ISPs, some of them may decide to filter strictly on
>> allocations and not accept more specifics. This already happens today.
> 
> If "let the market decide" is the answer then there is a MUCH easier
> one: just take 8000::/3 and start picking random blocks from there. No
> need for RIRs to be involved, saves a lot of hassle, and as long as you
> are large enough (content wise, user wise, money wise) you can get that
> prefix to be accepted anyway. Same goes for DNS and all other internet
> resources, they are just numbers. The biggest one wins.

I think you are being too extreme. What I'm saying is something already
happening and not being a chaos. What you propose, will be a chaos :-(

> 
>>> The whole more-specifics business depends on one factor: Money
>>> If you pay people enough or it is important enough one can announce it
>>> anyway and no RIR is going to stop that.
>>> 
>>> Including that portion is just a lousy way of trying to inhibit routing
>>> table growth which will not work; as can be seen by the multitude of
>>> longer prefixes being announced into the global IPv6 routing tables
>>> already. (*)
>> 
>> Having the text in the policy helps to take measures if needed.
> 
> What can a RIR do against it? Say that the LIR can't use the prefix
> anymore? How will a RIR do that exactly? Tell them they are bad and

SBGP is not enough ? Some (just a few) LIRs filtering the prefix will make
it unusable.

> evil? Come on, 3ffe::/24 is also still announced and that is now IANA's
> block again and in effect 'illegal' to be in use.

I don't see those prefixes, are filtered out, and many people do the same, I
guess. So not an issue, not useful for who is using those prefixes. I think
right now only 1 entity in the world in just 7.5 months since released, not
bad, actually it took less than 3 months as I recall, to get only 1 entity
announcing it.

> 
> [Bill, did you see the black helicopters around your house already? :) ]
> 
>> Not having
>> that text will not help at all, while keeping the text provide a possible
>> way for the community to take actions, if required, and meanwhile doesn't
>> hurt.
> 
> ISP's are already doing it and nothing is being done against it.
> They will and are creating their own PI without the 'community' being
> able to do anything about it: except filtering, which is not happening (yet)

I can tell you that some are getting filtered. Even people receiving /48 PI
from ARIN has issues, as they told me two weeks ago. May be they will be
lucky and will get sorted out, but filtering works.

> 
>>> Lastly "# have a plan for making assignments within two years.",
>>> everybody has a PLAN to do something, actually doing it something else.
>>> As the number of assignments is removed, there is no way to check up on
>>> this, next to there not being any requirement of actually registering
>>> these assignments in the RIPE db, thus there is no way to check.
>> 
>> The point is not asking LIRs to lie about the "size" of the plan. Some LIRs
>> could have a plan for just a few customer, and actually if they say the
>> true, they will not get an allocation because they don't have a plan for 200
>> customers. So they could tell to RIPE that they have a plan for 200
>> customers and get the allocation. This is completely artificial.
> 
> If it is artificial then why is it included?

I'm not sure what text are you reading. No longer 200 included. That was
artificial and we need to get rid off it.

> 
> If they only have a plan for a few customers then they should say "we
> only need a /40" to RIPE and should be able to get that /40.

Not under existing policy. And if we agree on that, it will need to be in a
different policy proposal offering different allocation lengths depending on
the number of possible customers, or whatever. I'm not saying yes or not,
just take each thing step by step if we want to move after so many years and
so many failures and work of so many people to remove this artificial
barrier.

> 
> Then again, address-space wise there is not much wasted in giving a /32
> to everybody who wants it. (16^2 is a lot :)
> 
>> I don't believe anyone NOT willing to provide services will ask for an
>> allocation.
> 
> Why not? Maybe some company just wants address space to be able to say
> they have it. Just check the current allocations which are allocated but
> have not been announced in the last couple of years.

People is getting ready, it takes time, and priorities change, but they will
use it. If not, following policy, could be reclaimed, if the community
decides to do so.

> 
> Maybe they just want to secure their address space for later, how can
> you know, it is their company not yours.

I don't think this is a general rule, and actually I think it is easier for
small ISPs to start providing the service than for bigger ones. Smaller ones
tend to me much more "agile".

> 
> 
>> RIPE can check that at any time by asking customer contracts.
> 
> And then they show 2x /33, one for their games department and one for
> their work department. Doesn't really help does it?

No, existing policy ask for justification if you assign more than /48 to a
single customer, so it will not work, even they will be in troubles before
doing the assignment because RIPE NCC will not accept a justification for a
/33 for their games department unless they demonstrate that a /48 is not
enough.

> 
> As mentioned even if RIPE then finds out that it does not qualify, then
> what are they going to do?
> 

Reclaim the space, check with the community, whatever. We should be doing
the same with IPv4, and may be sooner or later we will end up doing so. But
if we don't have a way to "secure" it in the policy, if time arrives could
never do that.

>> However I think is wrong to set-up an artificial barrier and say if you are
>> a small ISP and don't have 200 customers, you can't have access to an IPv6
>> block.
> 
> That is why I say: take it out completely. Don't make it more confusing
> than it already is. Especially not with artificial 'we are going to take
> it back' which is never going to happen.

See my previous comment, I will agree with that, but inputs received are
that the people to prefer to make sure that there is a plan at least.

> 
>> I thought all the /48s assignments need to be registered (I may be wrong).
>> So this is not changed by this policy proposal.
> 
> Clearly not as there are enough allocations that don't have a single
> assignment but they are announcing the whole block.

Ok, but then take it as a different issue, and as a member of the community,
ask why LIRs don't do that, and if there is no need for it remove that part
of the policy, etc. As said, let's work step by step.

> 
> Please check BGP before you try to make up a policy.

:-)

> 
> Greets,
>  Jeroen
> 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.