sig-policy August 2005

sig-policy@lists.apnic.net

8 participants
7 discussions

IPv6 Policy Proposal - prop-030-v001
by Geoff Huston 01 Sep '05

01 Sep '05

Attached are text, pdf and word versions of a IPv6 policy proposal for consideration at APNIC-20 regards, Geoff Huston Stephan Millet

5 6

Re: [sig-policy] prop-029-v001: Proposal for Discrete Networks and National Peering
by Anne Lord 26 Aug '05

26 Aug '05

Hi Uchenna, Many thanks for your proposal. I have just a couple of questions to assist me in my understanding. At APNIC17 a similar proposal to this one was presented by Norman Hoy of MCI on behalf of Dawn Martin: (http://www.apnic.net/docs/policy/proposals/prop-013-v001.html). The minutes from that meeting document a recommendation to look at the HD ratio proposal as a possible solution to the problems that were raised. Although this is not in your proposal, I would be interested to know if you looked at this at all? For more details see: http://www.apnic.net/docs/policy/proposals/prop-020-v001.html One clarification w.r.t item 4: >>4. This proposal does not conflict with current APNIC policy; This is not in fact quite right. Current policy does not support the allocation of large blocks of address space in the way that you describe. The policies under the suspended 'confederation' membership did operate in this way in the past, but today they are very different and in fact are now in line with the way the rest of the membership receives its resources. The parent company does not get a super-block to 'manage' and sub-allocate. Each 'discrete' network is handled directly by APNIC hostmasters in terms of the their resource requests and assignment window requests. I hope this clarifies things for you (and please dont hesitate to ask if not!) Best wishes, Anne -- > >Here is the proposal for review and comments. > >---------------------------------------------------------------------------- > >Proposal to permit large ISPs to manage multiple country accounts under a >single APNIC membership using discrete network concept. >---------------------------------------------------------------------------- > > >Summary >---------------------------------------------------------------------------- > >This Proposal is intended to simplify the management of multiple country >accounts hereby each country account would be considered a discrete >network. > >This proposal will support Global/Continental-Regional/National peering >policies and would be vital for the implementation of the IPv6 routing >policies. > >Benefits >---------------------------------------------------------------------------- > > >1. Simplify management of multiple country accounts; > > Currently large ISPs such as MCI with multiple APNIC accounts (one >per country) using the concept of discrete network can simplify their >procedures by combining their membership accounts under a single account, while >managing each country IP allocation as separate discrete networks. > >2. Simplify Billing; > > This concept will simplify the billing requirement for APNIC, hereby >reducing the number of member accounts per ISP and unify the billing >cycles. > >3. Peering; > Most large ISPs with International networks spanning multiple >continent and regions have peering policies implemented on their network. >Currently, MCI has 3 levels of peering, namely global-peering, >continental-regional peering and National peering. In order to make >national peering work in IPv6, we will need to advertise a single aggregate >per country. This will typically a /32, each country /32 should be able to >be aggregate into a single aggregate so that a single announcement could be >made to customers and continental-regional peers. > > In some countries, it is required by law that we peer with other ISPs >or interconnect at NAP (Network Access Point). In this case, the issue of >peering is required and this can only be done using aggregated IPv6 >addresses which will be based on the level of peering (It can be >Global/Continental-regional/National peering). > >4. This proposal does not conflict with current APNIC policy; only seeks to >simplify current APNIC operational requirements, frameworks for management >and allocation of IPv6/IPv4 addresses. This policy will be vital to >integration of implantation of IPv6 into an Asia Pacific region. > >Case Study >---------------------------------------------------------------------------- > >Some organizations have requirements for multiple discrete networks that >need individual address allocations. Discrete networks must often have >separate unique globally routable address space and will often grow at >different rates. In order for organizations with multiple discrete networks >to request additional address space under a single maintainer ID, the >organization must use the following criteria: > >* The organization should be a single entity, and not a consortium of >smaller independent entities. > >* This policy applies only to organizations that have been previously >granted address space by an RIR. This policy does not apply to >organizations with only legacy address space. > >* The organization must have multiple (at least two) discrete multi-homed >networks. > >* The organization must have compelling criteria for creating discrete >networks. Examples: > >o regulatory restrictions for data transmission > >o geographic distance and diversity between networks > > o autonomous multi-homed discrete networks > > * The organization must apply for this policy to be applied to their > account. > > Other APNIC IP allocation policies for IPv6/IPv4 would apply to this > proposal. > > Proposal > ---------------------------------------------------------------------------- > > > 4.1 When applying for additional address space from an RIR for new > Networks or additional space for existing networks the > organization must show greater than 50% utilization for the last > block granted by the RIR and their allocations as a whole. > > 4.2 The organization must not issue additional IP address space to a > discrete network unless all the blocks sub-allocated to that > network show utilization greater than 80% individually and as a > whole. > > 4.3 The organization must not sub-allocate a CIDR block larger than > the current minimum allocation size of the RIR (currently > /21-IPv4, /32-IPv6 for APNIC region) to a new network. > > 4.4 The organization must not sub-allocate an additional CIDR block > larger than the current minimum allocation size of the RIR > (currently /21-IPv4, /32-IPv6 for APNIC 's region) to an existing > network, unless previous growth rates for that network indicate > that it is > likely to utilize a larger CIDR block before the time the > organization will be requesting an additional block from the RIR. > > 4.5 When sub-allocating a block larger than the minimum allocation > size to an existing network the ISPs should use the smallest > allocation possible out of a larger reserved block. This > requirement is to reduce the number of routes the ISPs will > announce from that autonomous system. > > 4.6 The ISPs must follow guidelines of RFC 2050 (or its replacement) > and the policy of the granting RIR for allocations that are > assigned or sub-allocated to downstream networks. This includes > record keeping of IP address requests and network utilization > documents for audits by the RIR. > > 4.7 ISPs with 'multiple membership accounts' should request that this > policy apply to them, their existing allocations be merged, and that > additional allocations will fall under this policy. > > 4.8 The ISPs must record sub-allocations or assignments down to the > current RIR bit boundary and record them in an approved RIR public > database. > > 4.9 The ISPs must keep detailed records of how it has sub-allocated > space to each discrete network. This should include the block > sub-allocated, any reserved blocks, and date of allocation/ > reservation. The discrete network allocation information should > also be present in a public database. > > 4.10 An assignment window will be assigned to the ISPs and will need to > be followed for their entire network. Second opinion requests will > need to be sent to APNIC for review. This is to include blocks of > addresses that are assigned to new or existing pools within the ISPs > network. > > > Fees > ---------------------------------------------------------------------------- > > > The IP addresses from all combined resources would be taken into account > when assessing the membership tier for the organization upon the renewal of > their membership. > > > References > ---------------------------------------------------------------------------- > > > http://www.arin.net/policy/index.html#four5 > > http://www.arin.net/policy/proposals/2004_5.html > > Policy Proposal 2004-5: Address Space for Multiple Discrete Networks > > http://www.arin.net/policy/proposals/2001_6.html > > Policy 2001-6: Multiple Discrete Networks - Single Maintainer ID > > > Uchenna N Ibekwe > MCI Inc. > Phone +1-703-886-2650 > uchenna.ibekwe(a)mci.com > > "All I have seen teaches me to trust the Creator for all I have not seen." > Ralph Waldo Emerson > > "Confidence comes not from always being right, but from not fearing to be > wrong." --Peter T. McIntyre > > > * sig-policy: APNIC SIG on resource management > policy * > _______________________________________________ > sig-policy mailing list > sig-policy(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy

2 2

Re: sig-policy Digest, Vol 16, Issue 6
by Uchenna Ibekwe 25 Aug '05

25 Aug '05

Per policy: 4. This proposal does not conflict with current APNIC policy: If I understand your statement correctly, My idea is for APNIC to assign the allocations for the discrete Networks as is currently done with each country account. Discrete networks can be placed in categories: - Per country - Per Service Networks We are aware of the prop-013-v001.html presented at APNIC17 which was withdrawn, this is a different policy and a more explicit one. The fundamental goal as stated is to have one account per organization while managing allocations by APNIC through disrcrete networks; which can be defined as Country-discrete or Service-discrete to mentiona few. Therefore the HD ratios and alocations policies will be applied to the discrete network level while the billing will only apply at the organizational level. I see no conflicts only a realignment of policies to include the discrete networks. Uchenna N Ibekwe Manager MCI Inc. (Latin America, Asia-Pacific, Backhauls and Business Partners) Hours: 9:00AM Eastern US - 6:00PM Eastern US (Mon. & Fri.) 3:00PM Eastern US - 11:00PM Eastern US (Tues.- Thurs.) US & Latin America +1-703-886-2650, v806-2650 Group Alias: isd_ip(a)lists.mci.com Group Phone: 703-886-7840 US, 612-94345537 Australia, 852-2236-8985 Hong Kong, 81-3-53653740 Japan, 65-6248-6928 Singapore, 82-2-6281-7950 S.Korea, 886-2-2794-7769 Taiwan. uchenna.ibekwe(a)mci.com On Thu, 25 Aug 2005 sig-policy-request(a)lists.apnic.net wrote: > Send sig-policy mailing list submissions to > sig-policy(a)lists.apnic.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.apnic.net/mailman/listinfo/sig-policy > or, via email, send a message with subject or body 'help' to > sig-policy-request(a)lists.apnic.net > > You can reach the person managing the list at > sig-policy-owner(a)lists.apnic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sig-policy digest..." > > > Today's Topics: > > 1. Re: prop-029-v001: Proposal for Discrete Networks and > National Peering (Anne Lord) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Aug 2005 11:58:29 +1000 > From: Anne Lord <anne(a)apnic.net> > Subject: Re: [sig-policy] prop-029-v001: Proposal for Discrete > Networks and National Peering > To: uchenna.ibekwe(a)mci.com > Cc: sig-policy(a)lists.apnic.net > Message-ID: <430D25C5.3020709(a)apnic.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Uchenna, > > Many thanks for your proposal. I have just a couple of questions to > assist me in my understanding. > > At APNIC17 a similar proposal to this one was presented by Norman Hoy of > MCI on behalf of Dawn Martin: > (http://www.apnic.net/docs/policy/proposals/prop-013-v001.html). > > The minutes from that meeting document a recommendation to look at the > HD ratio proposal as a possible solution to the problems that were > raised. Although this is not in your proposal, I would be interested to > know if you looked at this at all? > > For more details see: > http://www.apnic.net/docs/policy/proposals/prop-020-v001.html > > One clarification w.r.t item 4: > > >>4. This proposal does not conflict with current APNIC policy; > > This is not in fact quite right. Current policy does not support the > allocation of large blocks of address space in the way that you > describe. The policies under the suspended 'confederation' membership > did operate in this way in the past, but today they are very different > and in fact are now in line with the way the rest of the membership > receives its resources. The parent company does not get a super-block to > 'manage' and sub-allocate. Each 'discrete' network is handled directly > by APNIC hostmasters in terms of the their resource requests and > assignment window requests. > > I hope this clarifies things for you (and please dont hesitate to ask if > not!) > > Best wishes, > Anne > -- > > > > >Here is the proposal for review and comments. > > > >---------------------------------------------------------------------------- > > > >Proposal to permit large ISPs to manage multiple country accounts under a > >single APNIC membership using discrete network concept. > >---------------------------------------------------------------------------- > > > > > >Summary > >---------------------------------------------------------------------------- > > > >This Proposal is intended to simplify the management of multiple country > >accounts hereby each country account would be considered a discrete > >network. > > > >This proposal will support Global/Continental-Regional/National peering > >policies and would be vital for the implementation of the IPv6 routing > >policies. > > > >Benefits > >---------------------------------------------------------------------------- > > > > > >1. Simplify management of multiple country accounts; > > > > Currently large ISPs such as MCI with multiple APNIC accounts (one > >per country) using the concept of discrete network can simplify their > >procedures by combining their membership accounts under a single account, while > >managing each country IP allocation as separate discrete networks. > > > >2. Simplify Billing; > > > > This concept will simplify the billing requirement for APNIC, hereby > >reducing the number of member accounts per ISP and unify the billing > >cycles. > > > >3. Peering; > > Most large ISPs with International networks spanning multiple > >continent and regions have peering policies implemented on their network. > >Currently, MCI has 3 levels of peering, namely global-peering, > >continental-regional peering and National peering. In order to make > >national peering work in IPv6, we will need to advertise a single aggregate > >per country. This will typically a /32, each country /32 should be able to > >be aggregate into a single aggregate so that a single announcement could be > >made to customers and continental-regional peers. > > > > In some countries, it is required by law that we peer with other ISPs > >or interconnect at NAP (Network Access Point). In this case, the issue of > >peering is required and this can only be done using aggregated IPv6 > >addresses which will be based on the level of peering (It can be > >Global/Continental-regional/National peering). > > > >4. This proposal does not conflict with current APNIC policy; only seeks to > >simplify current APNIC operational requirements, frameworks for management > >and allocation of IPv6/IPv4 addresses. This policy will be vital to > >integration of implantation of IPv6 into an Asia Pacific region. > > > >Case Study > >---------------------------------------------------------------------------- > > > >Some organizations have requirements for multiple discrete networks that > >need individual address allocations. Discrete networks must often have > >separate unique globally routable address space and will often grow at > >different rates. In order for organizations with multiple discrete networks > >to request additional address space under a single maintainer ID, the > >organization must use the following criteria: > > > >* The organization should be a single entity, and not a consortium of > >smaller independent entities. > > > >* This policy applies only to organizations that have been previously > >granted address space by an RIR. This policy does not apply to > >organizations with only legacy address space. > > > >* The organization must have multiple (at least two) discrete multi-homed > >networks. > > > >* The organization must have compelling criteria for creating discrete > >networks. Examples: > > > >o regulatory restrictions for data transmission > > > >o geographic distance and diversity between networks > > > > o autonomous multi-homed discrete networks > > > > * The organization must apply for this policy to be applied to their > > account. > > > > Other APNIC IP allocation policies for IPv6/IPv4 would apply to this > > proposal. > > > > Proposal > > ---------------------------------------------------------------------------- > > > > > > 4.1 When applying for additional address space from an RIR for new > > Networks or additional space for existing networks the > > organization must show greater than 50% utilization for the last > > block granted by the RIR and their allocations as a whole. > > > > 4.2 The organization must not issue additional IP address space to a > > discrete network unless all the blocks sub-allocated to that > > network show utilization greater than 80% individually and as a > > whole. > > > > 4.3 The organization must not sub-allocate a CIDR block larger than > > the current minimum allocation size of the RIR (currently > > /21-IPv4, /32-IPv6 for APNIC region) to a new network. > > > > 4.4 The organization must not sub-allocate an additional CIDR block > > larger than the current minimum allocation size of the RIR > > (currently /21-IPv4, /32-IPv6 for APNIC 's region) to an existing > > network, unless previous growth rates for that network indicate > > that it is > > likely to utilize a larger CIDR block before the time the > > organization will be requesting an additional block from the RIR. > > > > 4.5 When sub-allocating a block larger than the minimum allocation > > size to an existing network the ISPs should use the smallest > > allocation possible out of a larger reserved block. This > > requirement is to reduce the number of routes the ISPs will > > announce from that autonomous system. > > > > 4.6 The ISPs must follow guidelines of RFC 2050 (or its replacement) > > and the policy of the granting RIR for allocations that are > > assigned or sub-allocated to downstream networks. This includes > > record keeping of IP address requests and network utilization > > documents for audits by the RIR. > > > > 4.7 ISPs with 'multiple membership accounts' should request that this > > policy apply to them, their existing allocations be merged, and that > > additional allocations will fall under this policy. > > > > 4.8 The ISPs must record sub-allocations or assignments down to the > > current RIR bit boundary and record them in an approved RIR public > > database. > > > > 4.9 The ISPs must keep detailed records of how it has sub-allocated > > space to each discrete network. This should include the block > > sub-allocated, any reserved blocks, and date of allocation/ > > reservation. The discrete network allocation information should > > also be present in a public database. > > > > 4.10 An assignment window will be assigned to the ISPs and will need to > > be followed for their entire network. Second opinion requests will > > need to be sent to APNIC for review. This is to include blocks of > > addresses that are assigned to new or existing pools within the ISPs > > network. > > > > > > Fees > > ---------------------------------------------------------------------------- > > > > > > The IP addresses from all combined resources would be taken into account > > when assessing the membership tier for the organization upon the renewal of > > their membership. > > > > > > References > > ---------------------------------------------------------------------------- > > > > > > http://www.arin.net/policy/index.html#four5 > > > > http://www.arin.net/policy/proposals/2004_5.html > > > > Policy Proposal 2004-5: Address Space for Multiple Discrete Networks > > > > http://www.arin.net/policy/proposals/2001_6.html > > > > Policy 2001-6: Multiple Discrete Networks - Single Maintainer ID > > > > > > Uchenna N Ibekwe > > MCI Inc. > > Phone +1-703-886-2650 > > uchenna.ibekwe(a)mci.com > > > > "All I have seen teaches me to trust the Creator for all I have not seen." > > Ralph Waldo Emerson > > > > "Confidence comes not from always being right, but from not fearing to be > > wrong." --Peter T. McIntyre > > > > > > * sig-policy: APNIC SIG on resource management > > policy * > > _______________________________________________ > > sig-policy mailing list > > sig-policy(a)lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/sig-policy > > > ------------------------------ > > _______________________________________________ > sig-policy mailing list > sig-policy(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy > > > End of sig-policy Digest, Vol 16, Issue 6 > ***************************************** >

1 0

Re: [sig-policy] IPv6 Policy Proposal - changed proposal number
by APNIC Secretariat 11 Aug '05

11 Aug '05

Dear colleagues The official proposal number of "Proposal to amend APNIC IPv6 assignment and utilisation requirement policy" has been amended to: prop-031-v001 You can find the re-numbered Word, PDF and text versions of this proposal at: http://www.apnic.net/docs/policy/proposals/prop-031-v001.html Regards APNIC Secretariat ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 ----------------------------------------------------------------------

1 0

Proposal for Information Sharing on Transfer of IPv4 Address Space Allocation Between Taiwan LIRs
by Gene 10 Aug '05

10 Aug '05

Dear APNIC Policy SIG chairs, I am Ching-Heng Ku from TWNIC. I would like to have a Informational proposal which is regarding IP address space transfer between existing LIRs. It will take around 15 mins. Please find the following for the brief. Could you please spare me a timeslot for the presentation. Thank you very much! Best regards, Ching-Heng Ku TWNIC TEL: 886-2-23411313#300 FAX: 886-2-23968871 Topic: -------------------- Proposal for Information Sharing on Transfer of IPv4 Address Space Allocation Between Taiwan LIRs Summary: -------------- This proposal aims to describe some situations while unique requests may be occurred during the IPv4 allocation transfer processes between LIRs. APNIC IPv4 Address Policy DID provide guidelines of the address space management for the special conditions, such as mergers, acquisitions, and takeovers of LIRs. For example, the Policy mentions that all of the address space assigned to the eliminated LIR previously must be reviewed or returned back to APNIC after those transformations completed. However, with our experience, there were cases may need different solutions/extra guidelines to resolve some problems attached. For instance, it may not be sufficient to utilize the same approaches to handle requests occurred due to the changes of some services or subsidiary, instead of the whole company, shifted from ISP A to ISP B. Moreover, an idea of customers would like to keep the same IP resource (e.g. fixed IP) during any transfers occurred between LIRs or ISPs, may be need to take into consideration of policy making. On the other hand, if the partial IPv4 allocation transfer between LIRs are permitted, some suggested guidelines must be considered. For example, the size of the minimal unit, ie. the minimal allocation, is needed be claimed for the partial allocated address space transfer. This proposal does not conflict with current APNIC policy, and it’s proposed only to seek for advises or suggestion on the APNIC procedure for management and allocation of IPv4 addresses. Benefit: ------------- 1. Increase the IP address usability: The customer within the fixed IP service can use the original IP address even though the internet service provider (ISP) changed. 2. Increase the flexibility of IP address management The partial IP allocation transfer will be handled by the management of the internet registry. --------------

2 2

prop-005-v005: Proposal for IANA policy for allocation of IPv6 blocks to RIRs
by Save Vocea 10 Aug '05

10 Aug '05

Dear colleagues, prop-005-v004 was approved and endorsed by the APNIC EC in Nov 04. As the proposal required global consensus, the text has now been updated to be aligned with text that has reached consensus in the ARIN, RIPE and LACNIC communities. AfriNIC will be discussing the same text at their upcoming meeting. The proposal below has been updated to prop-005-v005. This will be presented as a proposal at APNIC 20. Feedback and comments are welcome on this list and at the meetng. Best regards, APNIC secretariat. ______________________________________________________________ prop-005-v005: Proposal for IANA policy for allocation of IPv6 blocks to Regional Internet Registries ______________________________________________________________ Proposed by: APNIC secretariat Version: 5.0 Date: 10 August 2005 Policy statement This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. 1. Allocation Principles The unit of IPv6 allocation (and therefore the minimum IPv6 allocation) from IANA to an RIR is a /12 The IANA will allocate sufficient IPv6 address space to the RIRs to support their registration needs for at least an 18 month period. The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work. 2. Initial Allocations On inception of this policy, each current RIR with less than a /12 unallocated address space, shall receive an IPv6 allocation from IANA Any new RIR shall, on recognition by ICANN receive an IPv6 allocation from the IANA 3. Additional Allocations A RIR is eligible to receive additional IPv6 address space from the IANA when either of the following conditions are met. The RIR's AVAILABLE SPACE of IPv6 addresses is less than 50% of a /12. The RIR's AVAILABLE SPACE of IPv6 addresses is less than its established NECESSARY SPACE for the following 9 months. In either case, IANA shall make a single IPv6 allocation, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period. 3.1 Calculation of AVAILABLE SPACE The AVAILABLE SPACE of IPv6 addresses of a RIR shall be determined as follows: AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR's minimum allocation size within the RIR's currently available stock. 3.2 Calculation of NECESSARY SPACE If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows: NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be different from the previous 6 months, it may determine its NECESSARY SPACE as follows: Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs. Submit a clear and detailed justification of the above mentioned projection (Item A). If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed. If the justification is based on the application of one or more of the Regional Internet Registry's new allocation policies, an impact analysis of the new policy/policies must be enclosed. If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data. If IANA does not have elements that clearly question the Regional Internet Registry's projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid. 4. Announcement of IANA Allocations The IANA, the NRO, and the RIRs will make announcements and update their respective web sites regarding an allocation made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. -- Savenaca Vocea, Policy Development Manager, APNIC <save(a)apnic.net> http:// www.apnic.net ph/fx +61 7 3858 3100/99 ------------------------------------------------------------------------ ------------------------------- See you at APNIC 20! Hanoi, Vietnam, 6-9 Sep 2005 http://www.apnic.net/meetings

1 0

prop-029-v001: Proposal for Discrete Networks and National Peering
by Uchenna Ibekwe 10 Aug '05

10 Aug '05

Here is the proposal for review and comments. ---------------------------------------------------------------------------- Proposal to permit large ISPs to manage multiple country accounts under a single APNIC membership using discrete network concept. ---------------------------------------------------------------------------- Summary ---------------------------------------------------------------------------- This Proposal is intended to simplify the management of multiple country accounts hereby each country account would be considered a discrete network. This proposal will support Global/Continental-Regional/National peering policies and would be vital for the implementation of the IPv6 routing policies. Benefits ---------------------------------------------------------------------------- 1. Simplify management of multiple country accounts; Currently large ISPs such as MCI with multiple APNIC accounts (one per country) using the concept of discrete network can simplify their procedures by combining their membership accounts under a single account, while managing each country IP allocation as separate discrete networks. 2. Simplify Billing; This concept will simplify the billing requirement for APNIC, hereby reducing the number of member accounts per ISP and unify the billing cycles. 3. Peering; Most large ISPs with International networks spanning multiple continent and regions have peering policies implemented on their network. Currently, MCI has 3 levels of peering, namely global-peering, continental-regional peering and National peering. In order to make national peering work in IPv6, we will need to advertise a single aggregate per country. This will typically a /32, each country /32 should be able to be aggregate into a single aggregate so that a single announcement could be made to customers and continental-regional peers. In some countries, it is required by law that we peer with other ISPs or interconnect at NAP (Network Access Point). In this case, the issue of peering is required and this can only be done using aggregated IPv6 addresses which will be based on the level of peering (It can be Global/Continental-regional/National peering). 4. This proposal does not conflict with current APNIC policy; only seeks to simplify current APNIC operational requirements, frameworks for management and allocation of IPv6/IPv4 addresses. This policy will be vital to integration of implantation of IPv6 into an Asia Pacific region. Case Study ---------------------------------------------------------------------------- Some organizations have requirements for multiple discrete networks that need individual address allocations. Discrete networks must often have separate unique globally routable address space and will often grow at different rates. In order for organizations with multiple discrete networks to request additional address space under a single maintainer ID, the organization must use the following criteria: * The organization should be a single entity, and not a consortium of smaller independent entities. * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization must have compelling criteria for creating discrete networks. Examples: o regulatory restrictions for data transmission o geographic distance and diversity between networks o autonomous multi-homed discrete networks * The organization must apply for this policy to be applied to their account. Other APNIC IP allocation policies for IPv6/IPv4 would apply to this proposal. Proposal ---------------------------------------------------------------------------- 4.1 When applying for additional address space from an RIR for new Networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. 4.2 The organization must not issue additional IP address space to a discrete network unless all the blocks sub-allocated to that network show utilization greater than 80% individually and as a whole. 4.3 The organization must not sub-allocate a CIDR block larger than the current minimum allocation size of the RIR (currently /21-IPv4, /32-IPv6 for APNIC region) to a new network. 4.4 The organization must not sub-allocate an additional CIDR block larger than the current minimum allocation size of the RIR (currently /21-IPv4, /32-IPv6 for APNIC 's region) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. 4.5 When sub-allocating a block larger than the minimum allocation size to an existing network the ISPs should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the ISPs will announce from that autonomous system. 4.6 The ISPs must follow guidelines of RFC 2050 (or its replacement) and the policy of the granting RIR for allocations that are assigned or sub-allocated to downstream networks. This includes record keeping of IP address requests and network utilization documents for audits by the RIR. 4.7 ISPs with 'multiple membership accounts' should request that this policy apply to them, their existing allocations be merged, and that additional allocations will fall under this policy. 4.8 The ISPs must record sub-allocations or assignments down to the current RIR bit boundary and record them in an approved RIR public database. 4.9 The ISPs must keep detailed records of how it has sub-allocated space to each discrete network. This should include the block sub-allocated, any reserved blocks, and date of allocation/ reservation. The discrete network allocation information should also be present in a public database. 4.10 An assignment window will be assigned to the ISPs and will need to be followed for their entire network. Second opinion requests will need to be sent to APNIC for review. This is to include blocks of addresses that are assigned to new or existing pools within the ISPs network. Fees ---------------------------------------------------------------------------- The IP addresses from all combined resources would be taken into account when assessing the membership tier for the organization upon the renewal of their membership. References ---------------------------------------------------------------------------- http://www.arin.net/policy/index.html#four5 http://www.arin.net/policy/proposals/2004_5.html Policy Proposal 2004-5: Address Space for Multiple Discrete Networks http://www.arin.net/policy/proposals/2001_6.html Policy 2001-6: Multiple Discrete Networks - Single Maintainer ID Uchenna N Ibekwe MCI Inc. Phone +1-703-886-2650 uchenna.ibekwe(a)mci.com "All I have seen teaches me to trust the Creator for all I have not seen." Ralph Waldo Emerson "Confidence comes not from always being right, but from not fearing to be wrong." --Peter T. McIntyre

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy August 2005