Search RPD Archives
[AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy Proposal:IPv6ProviderIndependent (PI) Assignment for End-Sites
Vincent Ngundi
vincent at kenic.or.ke
Fri Mar 16 08:23:34 UTC 2007
Hi All,
Useful statistics:
http://www.afrinic.net/statistics/ipv4_resources.htm
In particular:
http://www.afrinic.net/statistics/ipv4_resources.htm#03
http://www.afrinic.net/statistics/ipv4_resources.htm#05
http://www.afrinic.net/statistics/ipv4_resources.htm#08
-v
On Mar 14, 2007, at 12:17 PM, Andrew Alston wrote:
> Vincent,
>
>
>
> I see your point possibly about the waste of IPv6 space, and while
> I *DO* agree that we should not be over enthusiastic about the
> allocation of V6 space which could cause us to run out, we need to
> think of this as a balance, a balance between the size of
> allocations and the effect on the routing table.
>
>
>
> Yes, potentially there is a waste of space allocating /48s on /44
> boundaries out of a /28 block, however, considering the size of the
> V6 space and the fact that Deutsche Telecomms managed to get their
> own /19 worth of IPv6 space, I really do NOT believe this is a
> problem considering the effect it has on stopping the growth in the
> routing table.
>
>
>
> The entire reason that the IPv4 routing table is sitting at over
> 200 thousand routes today and growing so fast is in my opinion
> about the size of allocations and the boundaries on which they are
> done.
>
>
>
> At the moment (in IPv4)
>
>
>
> Company A starts, they want to multihome, and they go and get some
> P.I space, a /24
>
> Tomorrow they grow, they go and get another /24, maybe a /23 this time
>
> A few months from now, they grow some more, they ask for ANOTHER
> allocation, now they are advertising 3 prefix’s because there was
> no boundary to expand to stop this happening.
>
>
>
> The future I envisage:
>
>
>
> Company A starts, and gets a /48 prefix
>
> Tomorrow they grow, open a new office, they contact afrinic and go
> “We need more space”, AfriNIC replies “Sure, take your /48 and make
> it a /47”
>
> Company A goes into their router, replaces the mask on the BGP
> announcement, routing table doesn’t grow, problem solved.
>
>
>
> The reason for doing it out of a /28 or a /26 is purely so that
> there can be filtering of the smaller segments, in line with what
> ARIN is doing.
>
>
>
> To do /48s out of a /32 block is to repeat a chronic mistake made
> in the past that will lead to the very growth in the routing table
> that people are so scared of with regards P.I IPv6 Space. What I’m
> proposing I believe is the middle ground between space preservation
> and routing table growth. It’s also almost identical to what ARIN
> has done and keeps up in line with the other regions.
>
>
>
> I think we’d be foolish to assume as well that 65536 /48s will ever
> be enough, it might be today, it might be next year, and the year
> after, but there are more than 800 million people on the African
> continent, that makes for a LOT of companies, and today, in Africa
> internet access is expensive, technology is expensive, technical
> know-how is limited, however, we cannot use that as a reason to not
> plan for tomorrow. I strongly believe that Africa needs to move
> forward with a vision of what we can be tomorrow, where Internet
> penetration rates are the same as they are in Europe and the
> States, where the technology is the same and the pricing is the
> same. In that future, multi-homing and P.I is a necessity, and
> 65k /48s will not cut it. Lets avoid yet ANOTHER mistake I so
> often see, and not underestimate the capacity for growth on the
> African continent!
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On
> Behalf Of Vincent Ngundi
> Sent: Wednesday, March 14, 2007 10:24 AM
> To: AfriNIC Resource Policy Discussion List
> Subject: Re: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy
> Proposal:IPv6ProviderIndependent (PI) Assignment for End-Sites
>
>
>
> Hi Andrew,
>
>
>
> Thanks for your comments/input.
>
>
>
> On Mar 13, 2007, at 8:31 PM, Andrew Alston wrote:
>
>
>
>
> As I’ve stated in previous emails, I still believe that we should
> probably stay in line with what the other regions are doing here in
> order to avoid complications and different filtering systems
> globally to make the P.I space work.
>
>
>
> That is, a single block out of which allocations of /48 are made as
> a minimum. That way, a single prefix list could be applied on an
> ISP’s bgp peers that basically says (cisco syntax here, though its
> simply an illustration of principle)
>
> I agree with you.
>
>
>
> Permit aaaa:aaaa::/yy le 48
>
> permit xxxx:xxxx::/yy le 48
>
> permit zzzz:zzzz::/yy le 48
>
> permit ::/0 le 32
>
>
>
> Where A X and Z are the pre-defined P.I blocks from the various
> regions, everything else that’s in the tables that smaller in size
> than a /32 gets dumped.
>
>
>
> If we then decide to allocate these /48s on /44 boundaries so that
> organizations can grow (/44 being what I would consider a
> reasonable boundary for growth of individual companies) it would
> allow for companies to grow and add more /48s without growing the
> routing table because the blocks would be contiguous. If AfriNIC
> were to allocate a /28 for this purpose it allows for 2^16 (65536)
> P.I /44 blocks, which should last a fairly long time, and if it
> becomes necessary to grow this, its just a matter of adding
> another /28 prefix to the prefix list to expand the P.I space. We
> could even allocate that /28 on a /26 boundary for safety!
>
> If we take this approach, we may end up with a lot of wasted
> (unallocatable) space. For instance, how many organisations may
> expand such that they require an additional /48 (I'm being
> realistic here, not pessimistic)
>
>
>
> IMHO, I think a /48 = ( 2^16 (65536) /64's) from a reserved /32
> will do unless we intend to silently get rid of the IPv6 Allocation
> Policy.
>
>
>
> -v
>
>
>
> This at the end of the day covers most of the aspects,
>
>
>
> A.) It provides P.I space (which there seems to be consensus on
> from what I’m reading)
>
> B.) It provides enough space that the blocks can be expanded for
> institutions who have P.I space up to a /44, which, providing
> institutions are using a /48 per physical site would give them up
> to 16 physical sites (as an example, they could break /48s across
> multiple physical sites as well)
>
> C.) It provides enough space for the allocations of these P.I
> blocks without needing extensive filter lists on routers for the
> P.I prefix blocks and allows for the differentiation of P.I blocks
> versus P.A blocks by simply looking at the block the space was
> assigned out of. (This becomes even more obvious an advantage if
> the P.I allocation block is initially published on a /28 boundary
> but with a /26 reserved by AfriNIC incase of need)
>
> D.) In the case of point B.) due to the fact that sites can grow
> their blocks on a contiguous basis, it prevents massive growth in
> the routing table
>
>
>
> Just my thoughts, curious to hear what the disagreements with this
> are.
>
>
>
> Thanks
>
>
>
> Andrew Alston
>
> TENET – Chief Technology Officer
>
>
>
> From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On
> Behalf Of Hytham EL Nakhal
> Sent: Tuesday, March 13, 2007 6:55 PM
> To: AfriNIC Resource Policy Discussion List
> Subject: RE: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy
> Proposal: IPv6ProviderIndependent (PI) Assignment for End-Sites
>
>
>
>
>
> Dear Vincent,
>
> I'd like to discuss something may be get benefits of all
> suggestions regarding PI assignment, What about dedicating a /32
> for PI assignments, and each PI is /48 , so we have 2 to the power
> 16 PI assignments (i.e. 65536 /48 PI blocks). AfriNIC provide
> services for Africa Continent which contains about 55 countries. So
> if we divide PI blocks equally over countries we find that each
> country will have more than 1190 PI blocks, "Is it enough for each
> country" ? to know the answer we can have a look on the number of
> IPv4 PI assignments for each country in database (keeping in mind
> that /48 IPv6 block has addresses more more than /24 IPv4).
>
> Then we can make all /48 PI assignments from a dedicated /32 block
> and in same time we can arrange for a serial /48 blocks for each
> country and inside each country we can keep a guard band for each
> PI assignment in case of future growth.
>
>
>
> Thanks,
>
> Haitham..
>
>
>
> From: rpd-bounces at afrinic.net on behalf of Vincent Ngundi
> Sent: Tue 3/13/2007 3:51 PM
> To: Resource Policy Discussion List
> Cc: AfriNIC Policy Working Group List
> Subject: [AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy
> Proposal: IPv6ProviderIndependent (PI) Assignment for End-Sites
>
> Hi All,
>
>
>
> Below is a summary of the above policy as per the discussions we
> have had so far.
>
>
>
> So far, we have the following arguments:
>
>
>
> (a) Andrew Levin (30.01.2007)
>
> proposed that we should not assign prefixes < /48 due to concerns
> about the global routing table
>
>
>
> (b) Frank Habitcht (30.01.2007)
>
> was in agreement that there was need for PI assignments < /48
> especially in the case of IXP's since the prefix would not appear
> in the global routing table.
>
>
>
> (c) Mark Elkins (01.02.2007)
>
> Suggested that each /48 assignment should be made from a unique /32
> (which should be preserved to accommodate growth)
>
>
>
>
>
> From the above points:
>
>
>
> (b) above seems to have outweighed (a) above and as such we should
> allow for the assignment prefixes < /48 as per the draft.
>
>
>
> as for (c) above, organisations which require >= /32 should become
> an LIR.
>
>
>
> In conclusion, it seems that the draft policy should remain as it is.
>
>
>
>
>
> Currently statistics:
>
>
>
> * Yea (those in support of the policy) : 6
>
> * Nay (those _not in support of the policy) : 1
>
>
>
> Finally, I wish to encourage more members of the community to give
> their views on this policy, or at least indicate whether they are
> in favour of it or not.
>
>
>
> Abuja is only 5 weeks away!
>
>
>
> -v
>
>
>
> On Jan 30, 2007, at 11:22 AM, Andrew Alston wrote:
>
>
>
>
>
> Hi Vincent,
>
>
>
> I’m ok with all of this except for the following:
>
>
>
> * The intial provider independent assignment size to an end-site
> should be a /48, or a shorter/longer prefix if the end-site can
> justify it.
>
>
>
> I’m happy with /48s, I’m even happier with bigger blocks, but there
> should *NEVER* be a situation where the block is smaller than this
> in the global routing tables. If the blocks can ever be smaller
> than /48 in size it is going to create major BGP filtering headaches.
>
>
>
> Can this wording be clarified?
>
>
>
> Many Thanks
>
>
>
> Andrew Alston
>
> TENET – Chief Technology Officer
>
> _______________________________________________
>
> resource-policy mailing list
>
> resource-policy at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo.cgi/resource-policy
>
>
>
> _______________________________________________
>
> rpd mailing list
>
> rpd at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
>
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20070316/e1711fa9/attachment.html>
More information about the RPD
mailing list