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

[policy-wg] IPv6 PI policy

Thu May 18 22:49:51 UTC 2006

Hi Frank, all,

See my reply below, in-line.


> De: Frank Habicht <geier-lists-afrinic-policywg at>
> Responder a: AfriNIC Policy Working Group List <policy-wg at>
> Fecha: Thu, 18 May 2006 09:00:26 +0300
> Para: <policy-wg at>
> 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

The IPv6 Portal:

Barcelona 2005 Global IPv6 Summit
Slides available at:

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