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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/resource-policy
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
