[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: <jeroen at unfix.org>
> Fecha: Sun, 18 Mar 2007 20:05:53 +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:
>> To make it easier, I'm talking about "IPv6 Address Allocation and Assignment
>> Policy" ... Here is the link to the proposal:
>> 
>> http://www.ripe.net/ripe/policies/proposals/2006-02.html
> 
> 8<------------------------------------
>    2. plan to provide IPv6 connectivity to other organisations or to its
> own/related departments/entities/sites, to which it will make
> assignments. The assigned prefixes must be longer than the one allocated
> by RIPE NCC. The LIR must advertise the allocated address block through
> a single aggregated prefix. This prefix must be advertised within one
> year of the allocation being made;
> ----------------------------->8
> 
> "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 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.

> 
> The "must be advertised" part causes any non-internet usage to be 'illegal'.

Yes, this has been already raised before. 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
- 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)

> 
> 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.
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).

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).

> 
> 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.

> 
> 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. 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.

> 
> 
> 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.

I don't believe anyone NOT willing to provide services will ask for an
allocation. RIPE can check that at any time by asking customer contracts.
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.

I thought all the /48s assignments need to be registered (I may be wrong).
So this is not changed by this policy proposal.

> 
> Greets,
>  Jeroen
> 
> * = see  http://ris.ripe.net and http://www.sixxs.net/tools/grh/ ;)
> 




**********************************************
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.