[policy-wg] IPv6 PI policy

Fri May 19 11:28:28 SAST 2006

Hi Jordi,

I am not asking for a specific filter for each /48, I am suggesting that 
if the P.I space comes out of a single superblock (/30, /31, whatever 
the size of the superblock is that afrinic decides to allocate the P.I 
out of), that an exception be made singularly for the superblock to 
allow /48 routes from that superblock.

Andrew

JORDI PALET MARTINEZ wrote:
> 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.
>
>
>
> _______________________________________________
> policy-wg mailing list
> policy-wg at afrinic.net
> http://lists.afrinic.net/mailman/listinfo.cgi/policy-wg
>   