Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[policy-wg] IPv6 PI policy

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Fri May 19 09:03:24 UTC 2006


Hi Andrew,

I disagree, anyway, is something that its up to each operator, and what is
sure is that they don't filter anything shorter than 32 ...

Let me put an example that shows and <=32 works, others not.

APNIC has its own infrastructure in two locations, and they decided to split
the /32 in 2x/33. From time to time, they become not reachable from
different locations. Some operators only accept the /32.

How do you feel about that ?

Let me insist that /32 is not a waste under the consideration of: 1) is an
alternative to allow the current allocation policy to be modified for those
that may sub-assign to the same organization (instead to others); 2) is
temporary. However the cost for a different prefix is very unpredictable in
terms of asking everyone to make a specific filter for each /48 (or /44) and
consequently is not a good solution because is going to be against the
proposal of the policy itself (becoming a barrier to the existing barrier
!).

Regards,
Jordi




> De: Andrew Alston <aa at tenet.ac.za>
> Responder a: <aa at tenet.ac.za>
> Fecha: Fri, 19 May 2006 10:45:59 +0200
> Para: <jordi.palet at consulintel.es>, AfriNIC Policy Working Group List
> <policy-wg at afrinic.net>
> Asunto: Re: [policy-wg] IPv6 PI policy
> 
> Hi Jordi/Frank
> 
> I've been looking at this, and Jordi states that the current policy is
> to filter <= /32, I actually disagree with this.
> 
> I've been looking around at various route servers, and checking various
> networks, as well as speaking to a *LOT* of network admins, currently
> the actual ACTIVE practice is to filter <= /48, I have yet to actually
> find anyone who is filtering on a <= /32 basis.  While I'm sure they may
> exist, if they do they are in my opinion probably the vast minority.
> 
> Again I reiterate, P.I space of /48 with an option for /44 upon serious
> motivation.
> 
> Other than that, I support the policy
> 
> Thanks
> 
> Andrew Alston
> TENET - Chief Technical Officer
> 
> 
> JORDI PALET MARTINEZ wrote:
>> Hi Frank, all,
>> 
>> See my reply below, in-line.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>   
>>> De: Frank Habicht <geier-lists-afrinic-policywg at tih.co.tz>
>>> Responder a: AfriNIC Policy Working Group List <policy-wg at afrinic.net>
>>> Fecha: Thu, 18 May 2006 09:00:26 +0300
>>> Para: <policy-wg at afrinic.net>
>>> Asunto: [policy-wg] IPv6 PI policy
>>> 
>>> Hi all,
>>> 
>>> sorry I didn't speak up in the meeting.
>>> Regarding Jordi's IPv6 PI policy proposal afpol-v60604.
>>> 
>>> I was in the third group who didn't want to reject/defer/stall the
>>> policy but also not accept as it was.
>>> The only problem in my opinion is the question of size of the assigned
>>> blocks.
>>> 
>>> Main concern of contributors like Uniforum was that the assigned PI
>>> blocks be routable in practise (which AfriNIC won't guarantee, but might
>>> "influence"). I trust that operators of ipv6 routers will make the
>>> necessary exception for the supernet from with PI blocks are assigned.
>>> That other RIRs do same supports this expectation but if possible I'd
>>> like to hear from the router operators.
>>> 
>>> I would like to see a change to a smaller default assignment size to
>>> conserve address space. I would like to maintain the provision to use
>>> bigger blocks when justified. /48 as default should be fine. If filters
>>> of <48 are expected rather than <=48, then /44 might be a good option.
>>>     
>> 
>> The actual practice is to filter <=32, so even /44 will not work.
>> 
>> An alternative solution could be to understand that if we use /48 from a
>> special /32 block, then they may not be filtered (hopefully), but this only
>> works if an "allow" filter is placed on the complete /32.
>> 
>> The disadvantage of that, is the malicious usage of other /48 within that
>> /32 which are still not allocated. This already happens with non-allocated
>> IPv4 space, for example being used for spam. I think this is bad in general,
>> so a good reason for avoiding it.
>> 
>> Another disadvantage is that using a /32 allows a non-issue transition
>> (avoiding renumbering) if the PI holder later on becomes an LIR. Obviously
>> this is a very important advantage. May be I didn't stressed it enough
>> during the meeting.
>> 
>> I really think the advantages of the /32 versus the "perceived" waste are of
>> a much much much heavy way in the balance. Remember after all that this is a
>> temporary policy, so we are not wasting space forever.
>> 
>> As said in the meeting, the alternative will be to modify the existing PA
>> allocation to allow organizations to receive a PA prefix even if they don't
>> subassign to *other* organizations. In this case, is clear that they will
>> also get a /32. So what makes the difference ?.
>> 
>>   
>>> Since a rapid uptake of PI usage would or could increase the routing
>>> table size, and since I assume the fees attached to PI assignments will
>>> influence the number, those can be part of the discussion. I suggest
>>> fees should _not_ be waived.
>>>     
>> 
>> I'm of the opinion that the fees should be waived only when the PA fees are
>> waived, but this may imply that there is some type of charge for having a
>> contractual relationship/membership with AfriNIC. I mean, right now LIRs
>> that have IPv4 get the fees for IPv6 waived, but I'm not sure if this is
>> also true if a new LIR only needs IPv6 ?
>> 
>>   
>>> I would like to see the proposal succeed even if the above is not
>>> agreeable. As the numbers of hands in the meeting indicated, it is
>>> important to have this policy with or without change of assignment size.
>>> I hope we can use the 15 days last call period to find the best solution
>>> to the mentioned details.
>>> 
>>> Regards,
>>> Frank
>>> 
>>> 
>>> _______________________________________________
>>> policy-wg mailing list
>>> policy-wg at afrinic.net
>>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg
>>>     
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>> 
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> policy-wg mailing list
>> policy-wg at afrinic.net
>> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg
>>   




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

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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.






More information about the RPD mailing list