Search RPD Archives
رد: [policy-wg] IPV6 PI space
Hytham EL Nakhal
hytham at mcit.gov.eg
Mon Jan 1 08:17:49 UTC 2007
Hi All,
I'm new here, But in brief I'm agree with Andrew ... /48 is more than enough for IXP , /32 for LIR , and /48 for P.I. prefix's out of /30 v6 block.
and regarding the following :
> Which approach are we taking here while coming up with a solution:
>
> Is it:
> (a) looking at what other RIR's are doing
> (b) considering the needs of the AfriNIC community
> (c) both
I'd prefer (c) choice as we can get the "benefits of all"... see what others have done & choose what are suitable for us and then tune it to fit with African LIR's.
Thanks,
Haitham El Nakhal
ICT Technical Affairs Advisor
________________________________
من: policy-wg-bounces at afrinic.net بالنيابة عن Andrew Alston
تاريخ الإرسال: الخميس 12/14/2006 3:34 م
إلى: 'AfriNIC Policy Working Group List'
الموضوع: RE: [policy-wg] IPV6 PI space
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.
--
. . ___. .__ 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
_______________________________________________
policy-wg mailing list
policy-wg at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/policy-wg
_______________________________________________
policy-wg mailing list
policy-wg at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/policy-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20070101/7caafcc5/attachment.html>
More information about the RPD
mailing list