[address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy)

Hi Jordi,

On 25 Jun 2007, at 4:34pm, JORDI PALET MARTINEZ wrote:

[...]

>> It looks like you want an end site to qualify for a /32 IPv6
>> allocation if it needs to make *any* size of assignment to multiple
>> internal sites. But the text doesn't actually define what one of
>> these internal sites is. That creates a problem for anyone that wants
>> one of these /32 allocations because they can't work out if they
>> qualify for it or ought to try and get a /47 (or whatever) under the
>> IPv6 PI policy.
>
> We can't base this policy proposal in the existence of the IPv6 PI  
> one,
> because it is not the case.

We can't base one on the other but if both proposals make it through  
the PDP and become policies it would be a shame if they didn't work  
well together.

[...]

>> If the policy text is confusing it's going to create lots of extra
>> work for the requesters and the RIPE NCC.
>
> I don't really think it is the case. It will be the same right now for
> anyone, requesting space because "plan for 200 sites" is basically  
> a lie. We
> have removed this in other regions, I don't see why we are still  
> willing to
> set a new barrier, which may become artificial again.

I see lots of extra work because I find the proposed policy text  
confusing. The definitions are vague and that makes it difficult to  
work out how to apply the conditions. Each requester needs to  
understand the policy so that they can decide if they qualify and  
then send in a request. If they find the policy text confusing the  
RIPE NCC needs to produce an explanation in training material, in e- 
mail or over the telephone. But wouldn't it be better if the policy  
text didn't need explanation?

I agree that the current policy is flawed but is this proposal an  
improvement? It seems to maintain the form of the current policy  
while removing its context. If the intention is to ensure that all  
LIRs can have a /32 then why not just say that RIPE NCC membership  
qualifies an LIR for a /32?

If RIPE NCC membership alone if not enough then I think you need to  
work on the definition of a site because I find the recursive nature  
of your proposed text difficult to understand.

[...]

>> If it should not then how does this policy text ensure that? Because
>> as far as I can tell there isn't a good definition of what one of
>> these 'final' sites is, so anyone can claim that every /64 in their
>> internal network is a site and get a /32 allocation.
>
> Same as today. I still believe we should move ahead, and if  
> required improve
> it in following cycles, not be stuck forever.

I'm not opposed to making IPv6 address space available to all the  
networks that need it. I just think basing the policy for doing so on  
a concept that is so slippery we can't really define it is fatally  
flawed. If the net effect of your proposal would be that more than  
95% of members would qualify for a /32 allocation it is probably  
simpler to just make the qualifying criterion being a RIPE NCC member.

That way we can get rid of impossible to define concepts like "End  
Site" and near-but-not-quite restrictions, like the requirement for a  
plan to make more than one assignment to an end site within two years.

[slightly reordered]

>>> I think the issue still remains: 2006-01 and 2006-02 need to work
>>> together closely. Presumably, a network that does not qualify for  
>>> a /
>>> 47 should not qualify to receive a /32. Or should it?
>>
>> It is not a matter of the size of the prefix. It is a matter of
>> understanding if we are talking about an ISP or something  
>> different. An ISP,
>> even if it is an ISP for a specific organization (one that has  
>> several sites
>> and consequently need to assign space to them), requires PA. The  
>> other cases
>> requires PI.

So if an organisation planned to connect eight internal sites through  
a single external connection they should receive a /32 and not a /45  
or /44?

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison