Search RPD Archives
[policy-wg] IPv6 PI policy
Mark J Elkins
mje at posix.co.za
Mon May 22 16:38:18 UTC 2006
JORDI PALET MARTINEZ wrote:
> Hi Andrew,
>
> Yes, I got that already, but in general people don't necessarily setup a
> single filter for all the prefix. Doing so, still allows, for example,
> spammers to use pieces of the superblock (i.e., /44 or /48).
>
> At the end, unfortunately, there is not a clear set of strict rules for
> routing/filtering, so whatever we decide may or may not work. However, as
> the general accepted practice is for <=/32, this ensures a higher level of
> general "routability".
>
> Regards,
> Jordi
>
I´m not really sure how many people are going to acquire PI space
anyway. I was the only person at the meeting asking for it. I´d probably
end up asking for two blocks - one for UniForum SA (The co.za
administrators) and one for myself (Posix Systems). I just think it
makes sense for UniForum SA to have a block. I know its not essential in
order to stick IPV6 addresses into the co.za zone file - but I think its
appropriate to offer IPV6 connectivity if we also have IPV6 addresses in
the registry (Who knows what glorious checks we can devise
(tounge-in-cheek)).
Disclaimer - None of this implies that IPV6 in the co.za zone is in any
form of planning - or indeed will ever happen.
For myself... (Posix - an ISP) I have historical IPV4 address space -
so to go and get an IPV4 address so I can get a (for now) free IPV6
seems stupid.. so some PI IPV6 for now seems sensible - and the
allocated size is just right... and can one day become PA.
I have some IPV6 - this machine shows...
eth0 Link encap:Ethernet HWaddr 00:0E:0C:3E:99:CA
inet addr:160.124.48.1 Bcast:160.124.48.255 Mask:255.255.255.0
inet6 addr: 3ffe:b00:4016:aaef:20e:cff:fe3e:99ca/64 Scope:Global
inet6 addr: fe80::20e:cff:fe3e:99ca/64 Scope:Link
...but this is test space and about to become non-routable... so I need
the replacement :-)
(OK - purely selfish reasoning) ... but would help me get CO.ZA up and
running... when I can bend the arms of some of the other directors.
Speaking only for myself.
(Try ping6 me !)
>
>
>
>> De: Andrew Alston <aa at tenet.ac.za>
>> Responder a: <aa at tenet.ac.za>
>> Fecha: Fri, 19 May 2006 11:28:28 +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,
>>
>> 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
>>>
>>>
>
>
>
>
> **********************************************
> 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
>
--
. . ___. .__ Posix Systems - Sth Africa
/| /| / /__ mje at posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
More information about the RPD
mailing list