[policy-wg] IPV6 PI space

[Rob Blokzijl]

Hi there too :-) ,

   it seems to me that your arguments all boil down to 'address 
conservation'. However as far as I understand in IPv6 conservation is not 
the most important driver for address allocation policy. It is route 
conservation. So, arguments like /nnn should be enough address space for a 
specific purpose is far less important then the aggregation and routing 
aspects.

   I think, but then I may be wrong of course :-)

Greetings,

   Rob

On Thu, 14 Dec 2006, Andrew Alston wrote:

> Hi There,
> 
> Unfortunately I was unable to attend the AfriNIC meeting in Mauritius due to
> other commitments, however, having been involved in the P.I debate for a
> while and having kept a close watch on the developments in this regard
> around the world, I tend to take a different view on this.
> 
> I firmly believe that with regards P.I space, a /48 allocation is enough.
> Firstly, for IXP space, there is a trend to move towards /126 networks on
> point to point allocations (do not use /127's, there are a variety of
> reasons for this), therefore, IXP's could operate off a single /48,
> utilizing /64's per IXP, and utilizing /126 networks for the actual peering
> requirements.
> 
> Secondly, with regards to end user networks, for AfriNIC to allocate /32's
> in P.I space would again run contrary to what the global trends are, ARIN
> has agreed to /48 P.I space, and (someone correct me if I 'm wrong here),
> APNIC is about to ratify their /48 P.I policy.  
> 
> Considering that /48 amounts to 2^16 (65536) /64's, each of which can be an
> end point network, a /48 should be more than sufficient for P.I allocations
> to individual companies.  ISP's should qualify for /32s and become LIR's if
> they want the /32s and are allocating onwards.
> 
> I would prefer therefore that as per global trends, AfriNIC allocates a set
> block out of which to assign /48 P.I prefix's (possibly a /30 or a /31), and
> assigns the /48s outta that prefix for all P.I space.  That block can then
> be made public, so that those of us that update filters to filter /48
> deaggregated announcements can add exceptions for the specified prefix.
> 
> I would say that where companies have more than one physical location there
> could potentially be an exception to this policy, so that a company that has
> multiple physically diverse branches, might for example qualify for multiple
> /48s, purely for the purpose of better routing aggregation, but again, these
> /48s out of the same block referred to earlier.
> 
> The above would be more in line with what is done globally, and would avoid
> the complications of BGP filters that were different for different regions!
> 
> Thanks
> 
> Andrew Alston
> TENET - Chief Technology Officer
> 
> -----Original Message-----
> From: policy-wg-bounces at afrinic.net [mailto:policy-wg-bounces at afrinic.net]
> On Behalf Of Mark J Elkins
> Sent: Thursday, December 14, 2006 2:41 PM
> To: AfriNIC Policy Working Group List
> Subject: [policy-wg] IPV6 PI space
> 
> Firstly - the training and knowledge received in Mauritius was great 
> with respect to IPV6. This has allowed me to better understand the needs 
> and concerns of others. However - I am by no means the expert and 
> expected to be corrected when incorrect.
> 
> I believe there needs to be some sort of PI policy. I do not believe 
> that is is very healthy for Exchange Points (IXP's) to use the address 
> space of a particular ISP. I also believe that its unhealthy for some 
> organisations (eg - CCTLD's) that currently have IPV4 PI space and who 
> are Multi-Homed to also have space from any particular ISP.
> 
> I believe that AfriNIC needs two different PI allocation policies for 
> these two different areas:
> 
> For Exchange Points
> ---------------------------
> 
> These need a small, non-wasteful, low maintenance allocation - for 
> example, an allocation of a /44 would allow for 16 "networks" (each of 
> /48) to be established. A /48 is more than suitable for a single (even 
> geographically dispersed) IXP, thus a /44 should be sufficient for a 
> country or a countries ISPA. (By this - I'm thinking of South Africa 
> with currently only one active peering point, but with potential 
> expansion to a total of three points - but all managed by a single ISPA 
> type organisation). 
> I'd like to see AfriNIC allocate these /44's out of a single /32, which 
> means there are 4096 of these allocations available. These should be 
> only used for IXP's and should (I'd like to suggest) have no 
> re-occurring charge associated with them.
> The allocation could be made to the ISPA type organisation - so that 
> there is no need for ongoing maintenance of the allocation (or at least 
> greatly reduce the maintenance burden on AfriNIC).
> I see this as promoting the use of IPV6 and also of IXP's (and ISPA's) 
> within the AfriNIC region.
> By allocating a /44, the Reverse DNS responsibilities (and hence - usage 
> of AfriNIC resources) is minimalised and filtering could also be done on 
> /44's. The allocations should be made on /40 boundaries so when there is 
> a need to allocate a particular country (or ISPA) with additional space, 
> to do so from the same /40. This allows for 256 different "countries".
> Technically - IXP allocations do not need to be globally route-able - so 
> this type of allocation should be fine.
> The other assumption here is that the IXP (or ISPA - whatever) is a 
> non-commercial (non-profit) organisation - in order to be exempt from 
> re-occurring fees.
> (By extension, maybe even allocate a /32 to AfrISPA - and let them 
> delegate onwards? - but I'm trying to not have options)
> 
> For other existing holders of IPV4 PI Space
> ---------------------------------------------------------
> 
> For all organisations that currently have IPV4 PI space within the 
> AfriNIC region, they should be allowed to obtain full /32's of IPV6 
> space. Prerequisites should be: Holding AfriNIC IPV4 PI space, an 
> AfriNIC ASN and Proof of Multi-Homing within the AfriNIC region - or 
> proof that it has been requested and is impending.
> (kiss - Keeping It Simple)
> 
> 
> 
> No policy is exempt from changes in the future. The above policy 
> suggestions are to tackle todays requirements whilst keeping them 
> flexible enough that they may serve the AfriNIC regions needs for the 
> next few years.
> 
>