From owner-apnic-talk@lists.apnic.net Mon Sep 4 17:05:27 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id RAA111789; Mon, 4 Sep 2000 17:05:26 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id RAA111761; Mon, 4 Sep 2000 17:05:23 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id RAA111755 for ; Mon, 4 Sep 2000 17:05:22 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id RAA13089 for ; Mon, 4 Sep 2000 17:05:20 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma013087; Mon, 4 Sep 00 17:05:17 +1000 Date: Mon, 4 Sep 2000 17:05:15 +1000 (EST) From: APNIC Secretariat X-Sender: bc@julubu.staff.apnic.net To: apnic-announce@lists.apnic.net Subject: [apnic-talk] [apnic-announce] APNIC EXECUTIVE COUNCIL ELECTIONS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] CALL FOR NOMINATIONS TO APNIC EXECUTIVE COUNCIL One position on the APNIC Executive Council will be opened for election at the APNIC Members Meeting on 27 October 2000, in Brisbane Australia. The member whose position is up for re-election is Kazunori Konishi, who was appointed by the APNIC EC to a casual vacancy in March 2000. Nominations are due by COB Friday 13 October 2000 at the latest. Nominees do not have to be representatives of APNIC members; however, only APNIC members may make nominations. Members are welcome to nominate a representative of their own organisation. Nominations must be made using the online nomination form available at: http://www.apnic.net/meetings/ Details of all nominees will be posted on the web site and will be distributed at the meeting. Nominees should note that positions on the APNIC Executive Council are currently voluntary and that APNIC may not be able to reimburse EC members all expenses associated with EC meetings. Where possible, however, APNIC will reimburse actual expenses for attendance to APNIC meetings, providing that these fall within budget and cashflow constraints. Nominees should also make themselves familiar with the responsibilities of EC membership before nominating. These are contained in the APNIC By-Laws at: http://www.apnic.net/corpdocs/Bylaws.htm If you have any questions, please free to contact APNIC Business Manager, Kyoko Day at + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Tue Sep 5 14:01:09 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id OAA67339; Tue, 5 Sep 2000 14:01:08 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id OAA67310 for ; Tue, 5 Sep 2000 14:01:05 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id OAA05026 for ; Tue, 5 Sep 2000 14:01:03 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma005017; Tue, 5 Sep 00 14:00:44 +1000 Received: from wilson (wilson.staff.apnic.net [192.168.1.36]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id OAA22202 for ; Tue, 5 Sep 2000 14:00:41 +1000 (EST) From: "Paul Wilson" To: Subject: [apnic-talk] FW: IAB/IESG Recommendations on IPv6 Address Delegation Date: Tue, 5 Sep 2000 14:00:19 +1000 Message-ID: <002301c016ed$ce4480b0$2401a8c0@staff.apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk Date: Fri, 01 Sep 2000 12:40:48 -0700 To: lir-wg@ripe.net (RIPE), policy@arin.net (ARIN), apnic-talk@apnic.net (APNIC) From: Fred Baker Subject: IAB/IESG Recommendations on IPv6 Address Delegation Cc: ipv6-directorate@sunroof.eng.sun.com, iesg@ietf.org, iab@ISI.EDU, ipv6-wg@ripe.net (RIPE), sig-ipv6@lists.apnic.net (APNIC) Folks: The RIR community asked the IETF community for advice regarding the assignment of IPv6 prefixes to service providers and edge networks, both with a view to topological address assignment and to multihomed networks. The IPv6 Directorate prepared a statement, which the IESG and IAB have reviewed and approved. This is attached. I trust that this answers the questions you asked, and serves as a basis for IPv6 deployment in the near term. If you have questions or issues concerning it, I would suggest that you address them to the IPv6 Directorate copying the IESG and IAB. We intend to publish an Informational RFC in the near future documenting the contents of this note. Fred Baker ----------------------------------------------------------------------- IAB/IESG Recommendations on IPv6 Address Allocations September 1, 2000 Introduction During a discussion between IETF and RIR experts at the Adelaide IETF, a suggestion was made that it might be appropriate to allocate /56 prefixes instead of /48 for homes and small businesses. However, subsequent analysis has revealed significant advantages in using /48 uniformly. This note is an update following further discussions at the Pittsburgh IETF. This document was developed by the IPv6 Directorate, IAB and IESG, and is a recommendation from the IAB and IESG to the RIRs. Background The technical principles that apply to address allocation seek to balance healthy conservation practices and wisdom with a certain ease of access. On the one hand, when managing the use of a potentially limited resource, one must conserve wisely to prevent exhaustion within an expected lifetime. On the other hand, the IPv6 address space is in no sense as precious a resource as the IPv4 address space, and unwarranted conservatism acts as a disincentive in a marketplace already dampened by other factors. So from a market development perspective, we would like to see it be very easy for a user or an ISP to obtain as many IPv6 addresses as they really need without a prospect of immediate renumbering or of scaling inefficiencies. The IETF makes no comment on business issues or relationships. However, in general, we observe that technical delegation policy can have strong business impacts. A strong requirement of the address delegation plan is that it not be predicated on or unduly bias business relationships or models. The IPv6 address, as currently defined, consists of 64 bits of "network number" and 64 bits of "host number". The technical reasons for this are several. The requirements for IPv6 agreed to in 1993 included a plan to be able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split effectively accomplishes this. Procedures used in host address assignment, such as the router advertisement of a network's prefix to hosts [RFC 2462], which in turn place a locally unique number in the host portion, depend on this split. Examples of obvious choices of host number (IEEE Mac Address, E.164 number, E.214 IMSI, etc) suggest that no assumption should be made that bits may be stolen from that range for subnet numbering; current generation MAC layers and E.164 numbers specify up to 64 bit objects. Therefore, subnet numbers must be assumed to come from the network part. This is not to preclude routing protocols such as IS-IS level 1 (intra-area) routing, which routes individual host addresses, but says that it may not be depended upon in the world outside that zone. The IETF has also gone to a great deal of effort to minimize the impacts of network renumbering. None-the-less, renumbering of IPv6 networks is neither invisible nor completely painless. Therefore, renumbering should be considered an acceptable event, but to be avoided if reasonably avoidable. The IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48 bit prefix. This gives each such network 2^16 subnet numbers to use in routing, and a very large number of unique host numbers within each network. This is deemed to be large enough for most enterprises, and to leave plenty of room for delegation of address blocks to aggregating entities. It is not obvious, however, that all edge networks are likely to be recursively subnetted; an individual PC in a home, or a single cell in a mobile telephone network, for example, may or may not be further subnetted (depending whether they are acting as, e.g., gateways to personal, home, or vehicular networks). When a network number is delegated to a place that will not require subnetting, therefore, it might be acceptable for an ISP to give a single 64 bit prefix - perhaps shared among the dial-in connections to the same ISP router. However this decision may be taken in the knowledge that there is objectively no shortage of /48s, and the expectation that personal, home and vehicle networks will become the norm. Indeed, it is widely expected that all IPv6 subscribers, whether domestic (homes), mobile (vehicles or individuals), or enterprises of any size, will eventually possess multiple always-on hosts, at least one subnet with the potential for additional subnetting, and therefore some internal routing capability. Note that in the mobile environment, the device connecting a mobile site to the network may in fact be a third generation cellular telephone. In other words the subscriber allocation unit is not always a host; it is always potentially a site. Address Delegation Recommendations The RIR communities, with the IAB, have determined that reasonable address prefixes delegated to service providers for initial allocations should be on the order of 29 to 35 bits in length, giving individual delegations support for 2^13 (8K) to 2^19 (512K) subscriber networks. Allocations are to be given in a manner such that an initial prefix may be subsumed by subsequent larger allocations without forcing existing subscriber networks to renumber. We concur that this meets the technical requirement for manageable and scalable backbone routing while simultaneously allowing for managed growth of individual delegations. The same type of rule could be used in the allocation of addresses in edge networks; if there is doubt whether an edge network will in turn be subnetted, the edge network might be encouraged to allocate the first 64 bit prefix out of a block of 8..256, preserving room for growth of that allocation without renumbering up to a point. However, for the reasons described below, we recommend use of a fixed boundary at /48 for all subscribers except the very largest (who could receive multiple /48's), and those clearly transient or otherwise have no interest in subnetting (who could receive a /64). Note that there seems to be little benefit in not giving a /48 if future growth is anticipated. In the following, we give the arguments for a uniform use of /48 and then demonstrate that it is entirely compatible with responsible stewardship of the total IPv6 address space. The arguments for the fixed boundary are: - only by having an ISP-independent boundary can we guarantee that a change of ISP will not require a costly internal restructuring or consolidation of subnets. - to enable straightforward site renumbering, i.e., when a site renumbers from one prefix to another, the whole process, including parallel running of the two prefixes, would be greatly complicated if the prefixes had different lengths (depending of course on the size and complexity of the site). - there are various possible approaches to multihoming for IPv6 sites, including the techniques already used for IPv4 multihoming. The main open issue is finding solutions that scale massively without unduly damaging route aggregation and/or optimal route selection. Much more work remains to be done in this area, but it seems likely that several approaches will be deployed in practice, each with their own advantages and disadvantages. Some (but not all) will work better with a fixed prefix boundary. (Multihoming is discussed in more detail below.) - to allow easy growth of the subscribers' networks -- no need to keep going back to ISPs for more space (except for that relatively small number of subscribers for which a /48 is not enough). - remove the burden from the ISPs and registries of judging sites' needs for address space, unless the site requests more space than a /48, with several advantages: - ISPs no longer need to ask for details of their customers' network architecture and growth plans - ISPs and registries no longer have to judge rates of address consumption by customer type - registry operations will be made more efficient by reducing the need for evaluations and judgements - address space will no longer be a precious resource for customers, removing the major incentive for subscribers to install v6/v6 NATs, which would defeat the ability of IPv6 to restore address transparency. - to allow the site to maintain a single reverse-DNS zone covering all prefixes. - If and only if a site can use the same subnetting structure under each of its prefixes, then it can use the same zone file for the address-to-name mapping of all of them. And, using the conventions of RFC 2874, it can roll the reverse mapping data into the "forward" (name-keyed) zone. Specific advantages of the fixed boundary being at /48 include - to leave open the technical option of retro-fitting the GSE (Global, Site and End-System Designator, a.k.a "8+8") proposal for separating locators and identifiers, which assumes a fixed boundary between global and site addressing at /48. Although the GSE technique was deferred a couple of years ago, it still has strong proponents. Also, the IRTF Namespace Research Group is actively looking into topics closely related to GSE. It is still possible that GSE or a derivative of GSE will be used with IPv6 in the future. - since the site local prefix is fec0::/48, global site prefixes of /48 will allow sites to easily maintain a simple 1 to 1 mapping between the global topology and the site local topology in the SLA field. - similarly, if the 6to4 proposal is standardized, migration from a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix will be simplified if the native prefix is /48. Note that none of these reasons imply an expectation that homes, vehicles, etc. will intrinsically require 16 bits of subnet space. Conservation of Address Space The question naturally arises whether giving a /48 to every subscriber represents a profligate waste of address space. Objective analysis shows that this is not the case. A /48 prefix under the Aggregatable Global Unicast Address (TLA) format prefix actually contains 45 variable bits, i.e., the number of available prefixes is 2**45 or about 35 trillion (35,184,372,088,832). If we take the limiting case of assigning one prefix per human, then the utilization of the TLA space appears to be limited to approximately 0.03% on reasonable assumptions. More precisely, - RFC 1715 defines an "H ratio" based on experience in address space assignment in various networks. Applied to a 45 bit address space, and projecting a world population of 10.7 billion by 2050 (see http://www.popin.org/pop1998/), the required assignment efficiency is log_10(1.07*10^10) / 45 = 0.22. This is less than the efficiencies of telephone numbers and DECnetIV or IPv4 addresses shown in RFC 1715, i.e., gives no grounds for concern. - We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, we have reserved more than 85% of the address space (i.e., the bulk of the space not under the Aggregatable Global Unicast Address (TLA) format prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. - For transient use by non-routing hosts (e.g., for stand-alone dial-up users who prefer transient addresses for privacy reasons), a prefix of /64 might be OK. But a subscriber who wants "static" IPv6 address space, or who has or plans to have multiple subnets, ought to be provided with a /48, for the reasons given above, even if it is a transiently provided /48. To summarize, we argue that although careful stewardship of IPv6 address space is essential, this is completely compatible with the convenience and simplicity of a uniform prefix size for IPv6 sites of any size. The numbers are such that there seems to be no objective risk of running out of space, giving an unfair amount of space to early customers, or of getting back into the over-constrained IPv4 situation where address conservation and route aggregation damage each other. Multihoming Issues In the realm of multi-homed networks, the techniques used in IPv4 can all be applied, but they have known scaling problems. Specifically, if the same prefix is advertised by multiple ISPs, the routing tables will grow as a function of the number of multihomed sites. To go beyond this for IPv6, we only have initial proposals on the table at this time, and active work is under way in the IETF IPNG working group. Until existing or new proposals become more fully developed, existing techniques known to work in IPv4 will continue to be used in IPv6. Key characteristics of an ideal multi-homing proposal include (at minimum) that it provides routing connectivity to any multi-homed network globally, conserves address space, produces high quality routes at least as well as the single-homed host case previously discussed via any of the network's providers, enables a multi-homed network to connect to multiple ISPs, does not inherently bias routing to use any proper subset of those networks, does not unduly damage route aggregation, and scales to very large numbers of multi-homed networks. One class of solution being considered amounts to permanent parallel running of two (or more) prefixes per site. In the absence of a fixed prefix boundary, such a site might be required to have multiple different internal subnet numbering strategies, (one for each prefix length) or, if it only wanted one, be forced to use the most restrictive one as defined by the longest prefix it received from any of its ISPs. In this approach, a multi-homed network would have an address block from each of its upstream providers. Each host would either have exactly one address picked from the set of upstream providers, or one address per host from each of the upstream providers. The first case is essentially a variant on RFC 2260, with known scaling limits. In the second case (multiple addresses per host), if two multi-homed networks communicate, having respectively m and n upstream providers, then the one initiating the connection will select one address pair from the n*m potential address pairs to connect from and to, and in so doing will select the providers, and therefore the applicable route, for the life of the connection. Given that each path will have a different ambient bit rate, loss rate, and delay, if neither host is in possession of any routing or metric information, the initiating host has only a 1/(m*n) probability of selecting the optimal address pair. Work on better-than-random address selection is in progress in the IETF, but is incomplete. An existence proof exists in the existing IPv4 Internet that a network whose address is distinct from and globally advertised to all upstream providers permits the routing network to select a reasonably good path within the applicable policy. Present-day routing policies are not QoS policies but reachability policies, which means that they will not necessarily select the optimal delay, bit rate, or loss rate, but the route will be the best within the metrics that are indeed in use. One may therefore conclude that this would work correctly for IPv6 networks as well, apart from scaling issues. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Fred Baker | 519 Lado Drive IETF Chair | Santa Barbara California 93111 www.ietf.org | Desk: +1-408-526-4257 | Mobile: +1-805-886-3873 | FAX: +1-413-473-2403 * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Fri Sep 8 16:06:34 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id QAA118486; Fri, 8 Sep 2000 16:06:33 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id QAA118452; Fri, 8 Sep 2000 16:06:27 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id QAA118447 for ; Fri, 8 Sep 2000 16:06:25 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id QAA03068; Fri, 8 Sep 2000 16:05:11 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma003059; Fri, 8 Sep 00 16:05:00 +1000 Received: from localhost (champika@localhost) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id QAA13423; Fri, 8 Sep 2000 16:05:00 +1000 (EST) Date: Fri, 8 Sep 2000 16:05:00 +1000 (EST) From: APNIC Training X-Sender: champika@hadrian To: apnic-announce@lists.apnic.net cc: training@apnic.net Subject: [apnic-talk] [apnic-announce] APNIC Member Training in Thailand - September 21, 2000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] Dear APNIC Member, APNIC is pleased to invite you to attend a one-day training course titled 'Effective IP Address Management: Asia Pacific Policies and Procedures'. The course will be held in Thailand on Thursday 21st September, 9am - 5pm, at the following location. Room 1506 Department of Computer Engineering - Building 1 Faculty of Engineering, Kasetsart University Paholyothin Road, Chatuchak Bangkok 10900. Phone: +66 2 9428555 Ext 1401 Fax: +66 2 5796245 APNIC members are invited to attend this tutorial, which will be an important presentation of the current APNIC policies, a guide to completing APNIC request forms successfully and covers important issues such as network plan preparation, APNIC database procedures, AS procedures, reverse DNS, and IPv6. As a membership benefit, APNIC subsidises this course, however it is necessary to charge a fee of Thai Baht 1000 (US$25) per attendee to cover the basic costs incurred. The non-member fee is Thai Baht 2000 (US$50). The fees should be paid in cash on the day of the course. Training materials, Certificate of Participation on completion of the course, Lunch and refreshments will be provided. Who should attend? The target audience is technical personnel who have responsibility for allocating and/or assigning IP addresses. For example, hostmaster employees of network information centres or ISPs, network planners, designers, and network installation engineers. If you or your colleagues are interested in attending the course, Please complete the online Registration Form available from http://www.apnic.net/training. Please note that places are limited and the registration will be based on first come first serve basis. If you have any further queries, please contact . Warmest regards _____________________________________________________________________ Champika Wijayatunga, Training Manager Asia Pacific Network Information Centre phone: +61 7 3367 0490 http://www.apnic.net fax: +61 7 3367 0482 Please send the training queries to _____________________________________________________________________ See you at the APNIC Meeting - Brisbane, Australia 24-27 October 2000 * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Mon Sep 11 14:06:00 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id OAA92306; Mon, 11 Sep 2000 14:06:00 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id OAA92288; Mon, 11 Sep 2000 14:05:55 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id OAA92284 for ; Mon, 11 Sep 2000 14:05:54 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id OAA21501 for ; Mon, 11 Sep 2000 14:05:49 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma021489; Mon, 11 Sep 00 14:05:33 +1000 Received: from localhost (champika@localhost) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id OAA18021; Mon, 11 Sep 2000 14:05:32 +1000 (EST) Date: Mon, 11 Sep 2000 14:05:32 +1000 (EST) From: APNIC Training X-Sender: champika@hadrian To: training@apnic.net cc: apnic-announce@lists.apnic.net Subject: [apnic-talk] [apnic-announce] APNIC Member Training in Vietnam - September 18, 2000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] Dear APNIC Member, APNIC is pleased to invite you to attend a one-day training course titled 'Effective IP Address Management: Asia Pacific Policies and Procedures' on Monday 18 September 2000, 9am-5pm and a half-day Open seminar on Tuesday 19 September 2000, 9am-12noon. These courses will be held at the following location. Hanoi International Asean Hotel No. 41 Chua boc street, Hanoi Vietnam Tel. 84-4-8529108 Fax: 84-4-8529122 APNIC members are invited to attend this tutorial, which will be an important presentation of the current APNIC policies, a guide to completing APNIC request forms successfully and covers important issues such as network plan preparation, APNIC database procedures, AS procedures, reverse DNS, and IPv6. The training course fee is US$30 per participant and the open seminar is free of charge. Lunch and refreshments will be provided. Who should attend? The target audience is technical personnel who have responsibility for allocating and/or assigning IP addresses. For example, hostmaster employees of network information centres or ISPs, network planners, designers, and network installation engineers. If you or your colleagues are interested in attending the course, Please complete the online Registration Form available from http://www.apnic.net/training. Please note that places are limited and the registration will be based on first come first serve basis. If you have any further queries, please contact . Warmest regards, champika. _____________________________________________________________________ Champika Wijayatunga, Training Manager Asia Pacific Network Information Centre phone: +61 7 3367 0490 http://www.apnic.net fax: +61 7 3367 0482 Please send the training queries to _____________________________________________________________________ See you at the APNIC Meeting - Brisbane, Australia 24-27 October 2000 * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Mon Sep 11 15:32:03 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id PAA101355; Mon, 11 Sep 2000 15:32:02 +1000 (EST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id PAA101338; Mon, 11 Sep 2000 15:31:59 +1000 (EST) Received: from ix.netcom.com (user-33qsehl.dialup.mindspring.com [199.174.58.53]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id BAA18132; Mon, 11 Sep 2000 01:31:55 -0400 (EDT) Message-ID: <39BC8E9C.117C8732@ix.netcom.com> Date: Mon, 11 Sep 2000 00:49:49 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: apnic-talk@apnic.net CC: training@apnic.net, apnic-announce@lists.apnic.net Subject: Re: [apnic-talk] [apnic-announce] APNIC Member Training in Vietnam - September 18, 2000 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk All, I would love to attend, but the Hanoi government still has a price on my head, from the war days in their country. Hence I will not be able to attend. APNIC Training wrote: > [Note "reply-to:" field] > > Dear APNIC Member, > > APNIC is pleased to invite you to attend a one-day training course titled > 'Effective IP Address Management: Asia Pacific Policies and Procedures' > on Monday 18 September 2000, 9am-5pm and a half-day Open seminar on > Tuesday 19 September 2000, 9am-12noon. These courses will be held at the > following location. > > Hanoi International Asean Hotel > No. 41 Chua boc street, Hanoi > Vietnam > Tel. 84-4-8529108 > Fax: 84-4-8529122 > > APNIC members are invited to attend this tutorial, which will be an > important presentation of the current APNIC policies, a guide to > completing APNIC request forms successfully and covers important issues > such as network plan preparation, APNIC database procedures, > AS procedures, reverse DNS, and IPv6. > > The training course fee is US$30 per participant and the open seminar is > free of charge. Lunch and refreshments will be provided. > > Who should attend? > > The target audience is technical personnel who have responsibility for > allocating and/or assigning IP addresses. For example, hostmaster > employees of network information centres or ISPs, network planners, > designers, and network installation engineers. > > If you or your colleagues are interested in attending the course, > Please complete the online Registration Form available from > http://www.apnic.net/training. > Please note that places are limited and the registration will be based on > first come first serve basis. > > If you have any further queries, please contact . > > Warmest regards, > champika. > _____________________________________________________________________ > > Champika Wijayatunga, Training Manager > Asia Pacific Network Information Centre phone: +61 7 3367 0490 > http://www.apnic.net fax: +61 7 3367 0482 > > Please send the training queries to > _____________________________________________________________________ > See you at the APNIC Meeting - Brisbane, Australia 24-27 October 2000 > > * APNIC-ANNOUNCE: Announcements concerning APNIC * > * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * > * APNIC-TALK: General APNIC Discussion List * > * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Wed Sep 13 13:16:04 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id NAA101727; Wed, 13 Sep 2000 13:16:03 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id NAA101701; Wed, 13 Sep 2000 13:15:57 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id NAA101660; Wed, 13 Sep 2000 13:15:50 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id NAA12716; Wed, 13 Sep 2000 13:15:49 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma012712; Wed, 13 Sep 00 13:15:34 +1000 Received: from wilson (wilson.staff.apnic.net [192.168.1.36]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id NAA06516; Wed, 13 Sep 2000 13:15:31 +1000 (EST) From: "Paul Wilson" To: Subject: [apnic-talk] [apnic-announce] APNIC Open Policy Meeting - Update Date: Wed, 13 Sep 2000 13:15:30 +1000 Message-ID: <016f01c01d30$df742360$2401a8c0@staff.apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] [with apologies for duplicates] Dear Friend, The APNIC Open Policy Meeting is coming up soon, and here is a brief update on preparations for this important event. For more information and up to the minute news, be sure to visit the meeting website at: http://www.apnic.net/meetings EARLY-BIRD REGISTRATION ENDS SOON!!! Although the meeting is now only 6 weeks away, we have still not received many registrations. We know that many of you are intending to attend the meeting, but have been too busy to register. Please note that the discounted early-bird registration fee is available only until 15 September (only 2 days from now!!!). After that time, registration will cost extra for APNIC members and non-members. Please also remember that due to current high demand for flights to and from Australia, you should be sure to make travel arrangements as soon as possible. MEETING SCHEDULE You will be glad to hear that preparations for the meeting are now well advanced, and the meeting schedule is close to final. At the end of this email, we have attached the latest programme overview, but please come to the meeting website for all the details. We are currently working with the Chairs of the Special Interest Group (SIG) sessions to finalise agendas and papers, which will also be published soon. OPENING RECEPTION AND SOCIAL EVENT Please remember that although the meeting runs from 25 to 27 October, the Opening Reception is in the evening of Tuesday 24 October. This will be an enjoyable social event with cultural entertainment featuring traditional Australian Aboriginal performers who will soon appear at the Sydney Olympics, and which will give everyone the chance to meet and mingle with other attendees. You will also want to know about the special Social Event of the meeting - an evening river cruise on the picturesque Brisbane River (cost USD$30 per person, including dinner). This will be held on Wednesday 25 October. OTHER ACTIVITIES As you may know, Brisbane is a modern city with many recreational activities, including golf and casinos as well as an unspoilt natural environment. It is also very close to the Gold Coast, and a short flight away from Cairns and the Great Barrier Reef, all popular international tourist destinations. If you allocate a few extra days for sightseeing while you are here, you will be sure to have a great time. I hope you can see that the meeting will be an interesting and enjoyable event for all. Please join us in Brisbane! Paul Wilson Director General. ================== APNIC Open Policy Meeting 25-27 October 2000, Brisbane, Australia. DRAFT MEETING SCHEDULE Tuesday 24 9:00 APNIC Training Course 17:30 Finish 18:00 APNIC Orientation 19:00 Opening Reception --- Wednesday 25 8:30 Registration/Breakfast 9:00 Opening Plenary 10:30 Break Track 1 Track 2 11:00 Tutorial: IPv6 Tutorial: IRR 12:30 Lunch 14:00 Tutorial: IPv6 Tutorial: IRR 15:30 Break 16:00 SIG: IPv6 SIG: Whois database 17:30 Break 18:00 BOF: Exchange Points BOF: Membership Agreement 19:00 Social Event - River Cruise --- Thursday 26 8:30 Registration/Breakfast Track 1 Track 2 9:00 Tutorial: Reverse DNS SIG: Routing 10:30 Break 11:00 SIG: Address Policy --- 12:30 Lunch 14:00 SIG: Address Policy --- 15:30 Break 16:00 SIG: Address Policy --- 17:30 Break 18:00 BOF: Multi-homing BOF: CA --- Friday 27 8:30 Registration/Breakfast 9:00 SIG: Policy (AC Election) 10:30 Break 11:00 APNIC Member Meeting 12:30 Lunch 13:30 APNIC Member Meeting 15:30 Break 16:00 APNIC Member Meeting 17:30 Finish === * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Fri Sep 15 18:35:36 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id SAA91207; Fri, 15 Sep 2000 18:35:35 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id SAA91181; Fri, 15 Sep 2000 18:35:31 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id SAA91171 for ; Fri, 15 Sep 2000 18:35:29 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id SAA15732 for ; Fri, 15 Sep 2000 18:35:27 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma015724; Fri, 15 Sep 00 18:35:17 +1000 Received: from wilson (wilson.staff.apnic.net [192.168.1.36]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id SAA26306 for ; Fri, 15 Sep 2000 18:35:14 +1000 (EST) From: "Paul Wilson" To: Subject: [apnic-talk] [apnic-announce] APNIC Member Meeting - Important Information Date: Fri, 15 Sep 2000 18:35:13 +1000 Message-ID: <00ce01c01eef$de27ef30$2401a8c0@staff.apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] Dear APNIC Member, As you probably know, the next APNIC Member Meeting will be held as part of the coming APNIC Open Policy Meeting, to be held in Brisbane, Australia on Friday 27 October 2000. This meeting will be open to members of APNIC and to the general public, via registration at the Open Policy Meeting. For APNIC members in particular, it is important to be aware of this meeting, and to attend if possible. Following are some important details. * Draft Agenda A draft agenda for the Member Meeting is online now at: http://www.apnic.net/meetings/programme/docs/members_meeting_agenda.html Comments and suggestions on this agenda are welcome, by email to or * Executive Council Nominations An important part of the meeting will be the election of one member of the APNIC Executive Council, who will serve for a one-year term, replacing current EC member Mr Kazunori Konishi. Nominations for this election are open until 13 October, and may be made by any APNIC Member. For more information, and access to the online nomination form, please visit: http://www.apnic.net/meetings/programme/ec-2000-2.html * Proxy Voting As usual, APNIC Members who are not attending this meeting may be represented through proxies appointed in advance. The form for appointment of a proxy must be submitted by 9am on 25 October, and is available at: http://www.apnic.net/meetings/programme/docs/proxy2000.html Note that this form must be submitted to APNIC by fax, and signed by a representative of a current APNIC Member. * Meeting Registration Registration for the Open Policy Meeting is available now, at a discounted rate for online "early-bird" registrations. This discount period has just been extended to 30 September 2000, so please be sure to register soon! http://www.apnic.net/meetings/registration Also, we urge you to make travel arrangements as soon as possible, because of current high demand for air tickets to and from Australia. * Hostmaster Clinics Throughout the Open Policy meeting (25-27 October) APNIC Members will have access to our regular "Hostmaster Clinics", where issues relating to APNIC policies and procedures can be discussed directly with APNIC's Internet Resource Analysts (Hostmasters). Advance booking of these sessions is essential, and may be made by email to . * Member Training On Wednesday 24 October, APNIC will be presenting its member training course, "Effective IP Address Management: Asia-Pacific Policies and Procedures". All are welcome to register for this course, however numbers are strictly limited. If you wish to attend, please be sure to sign up soon, through the registration form mentioned above. Further details of this training are available at: http://www.apnic.net/training/ * APNIC Open Policy Meeting Of course, the APNIC Member Meeting is being held within the 3-day programme of the APNIC Open Policy Meeting, which will provide further opportunities for education and networking. For up to date information, please visit: http://www.apnic.net/meetings Be sure to check the details of social activities planned for the meeting, and other nearby activities which are listed at: http://www.apnic.net/meetings/info I am sure that by attending these meetings, you will receive exceptional value as an APNIC member, or as a member of the wider Internet community. See you in Brisbane! Paul Wilson Director General. * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Thu Sep 21 16:28:28 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA76682; Thu, 21 Sep 2000 16:28:28 +1000 (EST) Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA76664; Thu, 21 Sep 2000 16:28:23 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id QAA76659 for ; Thu, 21 Sep 2000 16:28:22 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id QAA03110 for ; Thu, 21 Sep 2000 16:28:19 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma003106; Thu, 21 Sep 00 16:28:17 +1000 Date: Thu, 21 Sep 2000 16:28:18 +1000 (EST) From: APNIC Secretariat X-Sender: bc@julubu.staff.apnic.net To: apnic-announce@lists.apnic.net Subject: [apnic-talk] [apnic-announce] APNIC Open Policy Meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] APNIC is holding an "Open Policy" meeting in Brisbane from October 25-27th. During the meeting, there will be a number of "Special Interest Group" (SIG) sessions to discuss matters relating to the management of address space in the Asia Pacific region. Over the next few weeks, in preparation for the meeting, presentation papers will be sent to this list to promote discussion and to give time for translation. They will also be archived on the APNIC web site under the 'programme' and 'documents' links at: http://www.apnic.net/meetings All those with an interest are warmly encouraged to attend and participate in the meeting. Registration details are available at the URL given above. We look forward to your participation and feedback. See you there! + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Fri Sep 22 14:57:40 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id OAA74455; Fri, 22 Sep 2000 14:57:39 +1000 (EST) Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id OAA74435; Fri, 22 Sep 2000 14:57:36 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id OAA74428 for ; Fri, 22 Sep 2000 14:57:34 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id OAA29818 for ; Fri, 22 Sep 2000 14:57:30 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma029808; Fri, 22 Sep 00 14:57:21 +1000 Date: Fri, 22 Sep 2000 14:57:21 +1000 (EST) From: APNIC Secretariat X-Sender: bc@julubu.staff.apnic.net To: apnic-announce@lists.apnic.net Subject: [apnic-talk] [apnic-announce] APNIC software release - testers wanted Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] APNIC software development: Parsing and Validation Tool - test version available APNIC is pleased to announce a pre-release version of the Parsing and Validation tool for the ISP Address Request form (APNIC-065) is now available for testing. This software application supports both e-mail and web interfaces to provide you with with real time, on-line feedback when submitting ISP Address Request forms. The tool performs tests that reflect APNIC's current policy requirements for ISP Address Requests, providing you with instant feedback on your request. The main functions of the tool are to check for syntax of the request and consistency with APNIC whois database requirements. We are currently seeking members to perform usability tests on the parser and provide us with feedback. If you would like to be involved, please contact . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Fri Sep 22 15:44:53 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id PAA76653; Fri, 22 Sep 2000 15:44:52 +1000 (EST) Received: from mail.nic.or.kr (mail.nic.or.kr [202.30.50.115]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id PAA76646 for ; Fri, 22 Sep 2000 15:44:49 +1000 (EST) Received: from nystyle ([203.255.208.131]) by mail.nic.or.kr (8.11.0/8.11.0) with SMTP id e8M5eNa29558; Fri, 22 Sep 2000 14:40:24 +0900 (KST) Message-ID: <00ab01c02458$699b95e0$83d0ffcb@nic.or.kr> From: =?ks_c_5601-1987?B?wMy9wrnO?= To: , References: Subject: [apnic-talk] Re: [apnic-announce] APNIC software release - testers wanted Date: Fri, 22 Sep 2000 14:46:11 +0900 Organization: KRNIC MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk KRNIC is not the ISP but, we want to test it with our members. Can we get the program for testing? Seung-Min Lee / Manager at Korea Network Information Center E-mail : seungmin@nic.or.kr Company Homepage : http://www.nic.or.kr Personal Homepage : http://www.nystyle.pe.kr ----- ¿øº» ¸Þ½ÃÁö ----- º¸³½ »ç¶÷: APNIC Secretariat ¹Þ´Â »ç¶÷: º¸³½ ³¯Â¥: 2000³â 9¿ù 22ÀÏ ±Ý¿äÀÏ ¿ÀÈÄ 1:57 Á¦¸ñ: [apnic-announce] APNIC software release - testers wanted > [Note "reply-to:" field] > > > APNIC software development: > > Parsing and Validation Tool - test version available > > APNIC is pleased to announce a pre-release version of the Parsing and > Validation tool for the ISP Address Request form (APNIC-065) is now > available for testing. > > This software application supports both e-mail and web interfaces to > provide you with with real time, on-line feedback when submitting ISP > Address Request forms. > > The tool performs tests that reflect APNIC's current policy requirements > for ISP Address Requests, providing you with instant feedback on your > request. The main functions of the tool are to check for syntax of the > request and consistency with APNIC whois database requirements. > > We are currently seeking members to perform usability tests on the parser > and provide us with feedback. If you would like to be involved, please > contact . > > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > APNIC Secretariat > > Tel: +61-7-3367-0490 > Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > > * APNIC-ANNOUNCE: Announcements concerning APNIC * > * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Tue Sep 26 09:08:08 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id JAA124094; Tue, 26 Sep 2000 09:08:08 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id JAA124090 for ; Tue, 26 Sep 2000 09:08:07 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id JAA03421 for ; Tue, 26 Sep 2000 09:08:05 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma003410; Tue, 26 Sep 00 09:07:53 +1000 Received: from localhost (anne@localhost) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id JAA27341 for ; Tue, 26 Sep 2000 09:07:49 +1000 (EST) Date: Tue, 26 Sep 2000 09:07:49 +1000 (EST) From: Anne Lord X-Sender: anne@hadrian To: apnic-talk@lists.apnic.net Subject: [apnic-talk] APNIC Address Policy SIG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk Attached below is a draft paper in preparation for the upcoming Address Policy SIG at the APNIC meeting. This paper will shortly be available on the APNIC meeting web site, along with all other meeting documents at: http://www.apnic.net/meetings Comments and discussion on this list are very welcome. Regards, Anne Manager, Member Services APNIC _____________________________________________________________________ DRAFT Problem Definition A proposal for an amended PI assignment policy 1. Motivation APNIC is frequently approached by organisations stating that they require an assignment of provider independent (PI) address space. The reasons most frequently cited include lack of IP address space available from upstream providers; plans to multihome; and a perception that PI space will provide redundancy and resilience for their site. APNIC currently makes PI assignments to end users in one of two ways: - Through the non-member assignment policy, which is open to any applicant (and involves a one-time fee payment of US$8,192). - Through a request submitted by a current APNIC member on behalf of the applicant (in which case there is no direct charge to the member or applicant; however, any PI address space assigned is added to the member's total pool of address space from which membership categories are calculated). This is an informal policy. Clearly there is a significant inconsistency between these two mechanisms for dealing with PI requests. So, in February 2000, at the APNIC meeting in Korea, APNIC presented the need for a clearer policy framework for this issue (http://www.apnic.net/amm2000/sigs/present/PI-assignments/index.htm). At that time there was no specific input from the community, but there was consensus that a change in policy was needed. Therefore, this proposal is submitted for discussion at the October meeting in Brisbane. 2. Background CIDR promotes a hierarchical routing structure through provider aggregatable (PA) assignments to end-sites, which reduces pressure on the global routing table size. Excessive use of PI assignments where providers are asked to announce and route prefixes from outside their own PA allocated ranges has the opposite effect, increasing the size of the global routing table. More than 50% of today's routing table comprises /24 announcements and, contrary to expectation, this percentage appears to be increasing not decreasing. Currently, there are more than 50,000 /24 routes in the routing table compared to 5,840 /19s and 3,575 /20s. Furthermore, in recent months, the rate of growth in the size of the routing table has increased. The number of entries has increased from 73,648 in February 2000 to 87,480 during September 2000. By comparison, in October 1999, the routing table held 64,019 prefixes (source: Philip Smith BGP Routing Analysis at http://www.apnic.net/stats/bgp and Tony Bates' CIDR report). These figures represent a 36% increase in one year. It is clearly the ISPs who determine what to route and how they choose to it. Allocation and assignment policies are not the only determinant of these routing statistics, but they do have a significant impact. The response from APNIC members in 1997 was to recommend the non-member PI assignment policy be priced sufficiently high as to discourage applications. Since the time of that decision, policy b) has been introduced, borrowed largely from the RIPE NCC. 3. Current status - RIR Policies APNIC As above. A member can request a PI assignment on behalf of a customer. The organisation must give a technical reason for the request, such as multihoming. Alternatively, an organisation can request a PI assignment directly from APNIC once they have paid the non-member fee of US$8,192. RIPE NCC RIPE NCC only makes PI assignments through members on behalf of customers. The requesting organisation must give specific reasons to the member explaining why PI is required. There is no minimum assignment size and no cost to the member or end-user. More information about this policy is available at http://www.ripe.net/ripe/docs/ripe-185.html ARIN The requesting organisation can apply to ARIN directly. The organisation must be multihomed and should have already efficiently utilised a /21 and demonstrate the need for /20 to be used within 3 months. The requesting organisation must agree to renumber from prior address space. No sub-assignments are permitted. It is worth noting here that these conditions are very similar to the conditions imposed on ARIN members in order to qualify for an allocation directly from ARIN. An allocation to members is effectively a portable address block that will appear in the global routing table, as will the PI assignment under this policy. ARIN has also defined exceptions to the policy in that they make assignments to "essential infrastructure", classified as gTLDs, ccTLDs, RIRs, and ICANN. Assignments are also made for exchange point infrastructure. However, in these exceptional cases, the assignment comes with terms and conditions, and must not be publicly routed on the Internet. ARIN makes no PI assignments smaller than a /24. All PI assignments attract a fee and recipients are required to sign a 'Registration Services Agreement' More information on ARIN policies is available at http://www.arin.net/regserv/ip-assignment.html 4. Discussion and recommendations This issue requires consideration on technical, administrative, and financial grounds. 4.1 Technical considerations i) Does the size of site matter? If yes, - Should PI assignments be available for end-user sites which are sufficiently large? - If yes, what size should be considered large enough? APNIC proposes that PI assignments should be available, but in order to discourage growth in the /24 range, end-sites should be sufficiently large. "Sufficiently large" is defined as sites that having utilised a /21 from their upstream ISP or be able to demonstrate that they plan to use a /21 immediately (up to 3 months). It is proposed that the "minimum" assignment should be related to APNIC's "minimum allocation". In routing terms, there is no practical difference between a /20 assignment and a /20 allocation. Therefore sites that qualify under this policy should be able to demonstrate utilisation of a /20 in a year. ii) Does the type of connectivity matter? - Should it be mandatory that the organisation is multihomed and running BGP to at least two different upstream ISPs? APNIC proposes that organisations must be multihomed or plan to multihome within 3 months in order to qualify for a PI assignment. Singly-homed organisations should use address space from their upstream ISP. Organisations that are multihomed will inject prefixes into the global routing tables. 4.2 Administrative considerations Currently, in the case of non-member resource assignments, there is no formal relationship or contract with APNIC, with the result that it is impossible to apply changes in resource management policies to historical assignments. Furthermore, although APNIC has no formal link to the requesting organisation, APNIC is still required to provide services to them free of charge in the form of in-addr.arpa service and whois maintenance. It is therefore recommended that the informal procedures of requesting PI address space through members is discontinued and that APNIC establishes a direct contractual relationship with end-users who request PI assignments. 4.3 Financial considerations It is proposed that requesting organisations are charged a fee consistent with APNIC's existing fee structure, which has a minimum fee US$2,500 and an administration fee of US$1,000. However, under APNIC's taxation arrangements, fees from organisations that are not APNIC members are treated as taxable company income. Therefore, the non-member fee should include provision for taxation, which is estimated at 34%. A maintenance fee of 10% of the annual fee will also be charged. In summary, the proposed fees are as follows: Amount of address space Fee Up to and including a /19 US$2,500 + 34% Greater than a /19 and including a /16 US$5,000 + 34% Greater than a /16 US$10,000 + 34% An administration fee of US$1,000 will be applied to all categories. GST of +10% is charged for AU requestors. All assignments will be subject to a 10% maintenance fee. 5. Recommendations APNIC is seeking feedback from the community in the development of a more consistent and equitable framework to address these issues. Based on the issues discussed in this paper, and drawing on the policy developed by ARIN, APNIC proposes that in order to receive a PI assignment, an organisation must meet all of the following criteria: - to receive a PI assignment an organisation must be multihomed or have plans to multihome within 3 months - the PI assignment should not be further assigned to other organisations if they are not administratively related to that organisation. Furthermore, there is a requirement that the assignment will be routed as one aggregate - the requesting organisation must have used a /21 from its upstream provider or, if not yet multihomed, plan to use a /21 and demonstrate a detailed plan to multihome within 3 months - the minimum assignment size is /20 (the address space will be assigned from 202/7) - a maintenance fee of 10% of the assignment fee will be payable each year 6. Implementation Proposal 6.1 Implementation date It is proposed that APNIC implement a new policy 3 months after consensus has been reached. At that time, the existing 'non-member' IP address assignment procedures, both formal and informal, will be deprecated. All necessary supporting documents will be prepared by APNIC before the implementation date. These will include a PI contract and a fee structure document. The existing 'end-user' address request form will be reviewed and modified accordingly. Every effort will be made to inform the community of the changes in advance of the changeover date through the APNIC web site and related mailing lists. 6.2 NIRs There is an expectation that NIRs will implement the criteria for multihomed assignments outlined in this policy proposal. However, as only APNIC is authorised to make PI assignments from the APNIC address ranges (see section 7.12.1 of the APNIC policy document 'Policies for address space management in the Asia Pacific region'), NIRs will forward approved requests to APNIC for actual assignment from the 202/7 address ranges. It is expected that where NIRs offer this service contractual relationships will be established between the NIR and the requesting organisation. * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Tue Sep 26 09:31:42 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id JAA124583; Tue, 26 Sep 2000 09:31:41 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id JAA124579 for ; Tue, 26 Sep 2000 09:31:40 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id JAA04048 for ; Tue, 26 Sep 2000 09:31:38 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma004044; Tue, 26 Sep 00 09:31:19 +1000 Date: Tue, 26 Sep 2000 09:31:18 +1000 (EST) From: APNIC Secretariat X-Sender: bc@julubu.staff.apnic.net To: apnic-talk@lists.apnic.net Subject: [apnic-talk] Address Policy Meeting - discussion paper Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk The following paper is being sent to apnic-talk@apnic.net in preparation for the upcoming Address Policy SIG at the APNIC Open Policy meeting. Discussion and feedback on this list is welcome. Title: "Separate Assignment Policies for ISPs and End-Users" Author: Izumi Okutani, JPNIC ------------------------------------------------------------------------- Separate Assignment Policies for End-Users and ISPs Background Currently, there are two types of network which global addresses are assigned: ISPs' network and end-users' network. As you can see from the definition below, they are used for quite different purposes. -End-users' network: Network constructed for the end-users' own use -ISPs' network: Network constructed to provide service to end-user's customers As a result of the difference in their purpose, the attributes are also quite different: Attributes of End users' network -In most cases, requires global address for their servers: their number is unlikely to change drastically within a year. -It will be used for their own network: easier to make a realistic and accurate estimation. -Doesn't require a large number of global addresses: even for a very large company, the number of network equipment that requires a global address can only be so much. Attributes of ISPs' network -ISP's network is constructed for their end users' and not for their own use: network topology depends on the number of end-users they have. -Requires a large number at once: at least two digits However, under the current policy, the same assignment policy of "assignments based on 1 year's estimation" applies to both end users' and ISPs' and networks despite the difference in their purpose and attributes. Having the same policy for these two different types of network leads to the problems described in the next section. Therefore, I would like to propose making a separate assignment policy for ISPs' networks, i.e. assess their needs on the actual usage rather than one year's estimate, Problems with the current assignment policy It is not realistic to make assignments on one-year's needs for ISPs' networks for the following reasons: -From the fast changing nature of the internet business, there a higher chance of actual needs not matching the initial estimation: You never know if the services they are providing will still be on the market after a year, and it is difficult to make an accurate estimation of the needs for ISP's network, even for those who are doing the business themselves -The numbers they request are large; a greater number of global addresses will be wasted if the needs were overestimated. -Consistency between ISPs: ISPs which request for allocation will have their needs assessed on approximately three months basis, while those which request for address assignment will have their needs assessed on one year span. Proposal Make a separate policy for assignments for ISPs' networks: do not assess its needs on 1 year's estimation, but on the actual usage. Here is the current practice at JPNIC: Assignment for existing services We make assessments based on the needs they had in past one year, and approve what a hostmaster considers appropriate. This may not necessarily be the amount of address expected to be required in one year. The information that we base our judgment varies depends on the service and the details are listed below: Dial-up services We make assessments based on the following information: -The increase in the number of equipment and PRI: 3months/6 months/1 year -User: address ratios -The number of customers for the past one-year on monthly basis -The number of customers estimated for the next one year on monthly basis By asking for monthly record and estimate, we are able to see the trend in the increase of customers and see if their estimate is realistic. Furthermore, the monthly estimate allows us to make more fine judgment to meet its needs for a particular duration. Cable services We make assessments based on the following information: -User: address ratios -The number of customers for the past one-year on monthly basis -The number of customers estimated for the next one year on monthly basis -List of current customers Hosting services -User: address ratios -The number of customers for the past one-year on monthly basis -The number of customers estimated for the next one year on monthly basis -List of current customers Please note that there may be other source of reference if the information listed above is not appropriate to see the needs of that particular network. Assignment for new services For new services, we do ask for the monthly estimate for one-year, but since it has no past records, it is difficult to see if their estimation is realistic. Therefore, we approve the amount of address to meet their immediate needs, and then ask them to make a request again when their needs exceeds this block. We judge the "immediate needs" by looking at various references such as their monthly estimate, asking what they consider is reasonable and in the case of dial-up services, by the equipment they would have purchased at the time of the start-up, etc. This depends on the case, so it is difficult to give a reference that applies to all cases. By the time they make the second request, they would be able to provide us with more information on the number of customers for the service, so we would have more evidence to base our judgment, and may give approval for more long term needs. Pros and Cons Pros -Assignment based on the actual use, not estimation. -Allows more fine assessment. Cons -May be difficult to draw the line between ISPs and end-users' networks in some special cases Conclusion Having a separate policy for ISP assignments based on the actual usage, and not on 1 year's estimate will lead to more efficient use of the address, and match the current practice. Izumi Okutani, JPNIC ------------------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Tue Sep 26 16:06:06 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id QAA76080; Tue, 26 Sep 2000 16:06:06 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id QAA76076 for ; Tue, 26 Sep 2000 16:06:05 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id QAA17073 for ; Tue, 26 Sep 2000 16:06:01 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma017065; Tue, 26 Sep 00 16:05:51 +1000 Received: from localhost (anne@localhost) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id QAA15841 for ; Tue, 26 Sep 2000 16:05:50 +1000 (EST) Date: Tue, 26 Sep 2000 16:05:50 +1000 (EST) From: Anne Lord X-Sender: anne@hadrian To: apnic-talk@lists.apnic.net Subject: [apnic-talk] Address Policy SIG paper Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk Attached below is a draft paper on "The future of ISP confederations - a proposal to permanently suspend the formation of new ISP confederations". This paper is being circulated in preparation for the upcoming Address Policy SIG at the APNIC meeting. This paper will shortly be available on the APNIC meeting web site, along with all other meeting documents at: http://www.apnic.net/meetings Comments and discussion on this list are very welcome. Regards, Anne Manager, Member Services APNIC ---- DRAFT Problem definition The future of ISP confederations - a proposal to permanently suspend the formation of new ISP confederations This proposal in this paper is twofold. First, that new procedures are applied to the management framework for existing ISP confederations; and second, that no new ISP confederations be created (in other words, this paper proposes that the suspension of new confederations memberships should be extended indefinitely for ISP confederations). 1. Background The ISP confederation structure arose in response to the globalisation of ISP networks through mergers and acquisitions - where an ISP network may span many countries. The resulting very large ISPs demonstrated a need to maintain independent network address allocation pools, and they were allowed to do this through the adoption of confederation memberships (which were originally designed to serve National NICs, now known as NIRs). ISP confederations have operated along the same administrative lines as NIR confederations, even though the specific characteristics of the NIR and ISP confederations are actually very different. Multiple independent allocations within a single APNIC membership are not ordinarily permitted due to significant additional administrative complexity which they impose. Normal APNIC members are therefore required to manage their allocated address space as a single pool, and only request more addresses when 80% of their allocation has been consumed. If independent allocations are required, the organisation is now advised to take out multiple memberships, which clearly delineates the separate allocations. 2. Motivation In practice, the current ISP confederation framework does not consistently apply APNIC policies across the APNIC membership, resulting in a lack of accountability by the ISP confederations. Moreover there are also different implementations of the model across the ISP confederation membership which significantly increase the complexity of management. In December 1998 the APNIC Executive Council supported the decision to suspend the formation of any new confederations. Almost two years has elapsed from the time of that decision and APNIC is now seeking feedback from the community on a specific proposal to resolve this issue. Note: At the time of the EC decision, the term 'confederation' applied both to the National Internet Registries (organisations that serve the ISP community within a particular country), and to ISP Confederations (whose 'membership' is defined by the structure of the ISP itself). This document is concerned only with the case of the ISP confederations. 3. Current status (including other RIRs) The following summary analysis compares the procedural framework applied to ordinary LIR APNIC members and members of ISP confederations and highlights the significant differences. Other RIRs (RIPE NCC and ARIN) have no confederation category within their membership structures, so their policies are not detailed here. 3.1 ISP Address Request Form Each direct LIR APNIC member must complete an 'ISP Address Request' form (APNIC-065) in detail when requesting an address allocation. This is evaluated carefully by the APNIC hostmasters. Under the current model for ISP confederations, the head office of the confederation is intended to assume the role of the registry, similar to that of APNIC. However there is no formal requirement for the confederation members to complete APNIC-065 when requesting address space, and moreover infrastructure descriptions are not required on the current APNIC Confederation request form. As a result infrastructure requirements go largely undocumented throughout the entire allocation process. 3.2 Assignment and Allocation Windows APNIC applies an 'assignment window' mechanism and second-opinion process to LIR members, in order to objectively measure the understanding and application of assignment policies and procedures by the member. For new members the assignment window starts at zero (and therefore applies to all customer assignments), and it is increased progressively as experience is gained. APNIC is also currently developing a corresponding "allocation window" mechanism by which NIR allocations to NIR members may also be subject to second-opinion approval by APNIC. This has been agreed by all NIR members, and is being progressively introduced. The ISP confederation model today does not involve a second-opinion process of any kind, which allows no objective measure or verification of policy adherance by the confederation. In any case this process by its nature assumes that the requestor is independent from the registry, and that the registry is neutral and impartial. Neither is the case for ISP confederations. 3.3 Establishing new memberships ISP confederations are currently able to establish new memberships as they please, and with each membership the ability to create an additional independently managed address pool. New memberships of the ISP confederations should be established under the same criteria as those applied to APNIC LIR members. 3.4 Initial allocations to members Initial allocations to new members should be consistent with policies decided by the APNIC community. APNIC applies the 'slow start' policy whereby new members receive the minimum practical allocation. Currently this is a /20. 4. Discussion APNIC is currently discussing the above policy issues with ISP confederation members, with a view to implementing changes. However, there are currently five ISP confederations, each with different topological considerations, which make the consistent and equitable application of policies and procedures a complex management task. While the ISP confederation model allows each ISP confederation to obtain independent address allocations for each member, this can also be easily achieved by establishing separate memberships with APNIC. 5. Recommendations APNIC recommends that the ISP confederation membership category be suspended, but that the existing ISP confederations be given the choice to either convert to multiple memberships or to remain as they are. If they choose to remain as ISP confederations, they will be asked to work with APNIC to modify their procedures to implement the assignment and allocation window systems with the objective of ensuring a more consistent and fair application of APNIC policies. This will be done on a case by case basis, but with an eventual aim to bring all confederations into line with a consistent policy framework. * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Wed Sep 27 12:08:15 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id MAA117282; Wed, 27 Sep 2000 12:08:15 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id MAA117278 for ; Wed, 27 Sep 2000 12:08:13 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id MAA06255 for ; Wed, 27 Sep 2000 12:08:11 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma006217; Wed, 27 Sep 00 12:07:36 +1000 Received: from localhost (anne@localhost) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id MAA10495 for ; Wed, 27 Sep 2000 12:07:32 +1000 (EST) Date: Wed, 27 Sep 2000 12:07:32 +1000 (EST) From: Anne Lord X-Sender: anne@hadrian To: apnic-talk@lists.apnic.net Subject: [apnic-talk] Address Policy SIG paper Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk Attached below is a draft paper titled "A proposal for establishing minimum criterial for a first allocation of address space by APNIC" This paper is being circulated in preparation for the upcoming Address Policy SIG at the APNIC meeting. This paper is now available on the APNIC meeting web site, along with all other meeting documents at: http://www.apnic.net/meetings Comments and discussion on this list are very welcome. Regards, Anne Manager, Member Services, APNIC -- DRAFT Problem definition A proposal for establishing minimum criteria for a first allocation of address space by APNIC 1. Motivation APNIC operates on an open membership basis, allowing any organisation to become a member. It is often assumed, however, that IP address space is automatically granted by APNIC to new members following their successful membership application. APNIC does not currently have well defined criteria for making the initial allocation of address space to a new member. However, such a set of criteria would help to ensure consistent service to new members, clarity, and transparency. 2. Background Hierarchical routing, otherwise known as CIDR, as described in RFC1519, controls of the growth of the global routing table and is essential for effectively scaling the Internet. Under the auspices of IANA and ICANN, APNIC allocates PA address space to its member ISPs (either directly or through an NIR). A goal of the system of delegated RIR responsibility is to provide a framework for the sustainable growth of the Internet. APNIC allocation policies are, therefore, required to support 'provider based' allocations as required by CIDR. All APNIC documentation stresses that potential members should be aware that applying for membership does not guarantee an allocation of resources. However, many organisations appear to be unclear about the meaning of APNIC's policies and the criteria for initial allocations, requesting membership from APNIC even though their address space requirements are low. These organisations are sent an information and membership package; of these 13% do not return to APNIC. APNIC spends considerable hostmaster and administrative resources in entering into ongoing discussion with such organisations. In applying, the applicant also experiences frustration at going through the membership application process and then being told to request the resources from their upstream provider. 3. Current status - RIR policies APNIC APNIC operates an open membership policy, such that any organisation can become an APNIC member and can apply for allocations of Internet Resources. This framework was derived from RIPE NCC. Applicants for membership who apply to become members with the intention of obtaining IP addresses are required to complete a pre-membership questionnaire. This requires an outline of future network deployment plans so that APNIC is able to obtain an understanding of their requirements. Applicants that are very small and singly homed are advised to contact their upstream providers for address space before their membership application is processed. The pre-membership process is aimed at discouraging potential members from becoming LIRs if they are in the very small and singly-homed category. However, as explained above, in many cases, as there are no fixed criteria, membership is granted to organisations which would not qualify for address space under the policies of ARIN. From membership application data collected over the month until 25 September, of 34 membership applicants, 13 were asked to send more information clarifying their requirements. Such clarifications took the form of network diagrams and equipment listings. Three of these applicants had requirements that amounted to less than a /24 and five planned to use less than a /22. In total eight (23%) were rejected immediately and 13 (38%) were approved, with the remainder ongoing. RIPE NCC RIPE NCC also operates an open membership policy with no strictly defined minimum first allocation criteria. This process is very similar to the APNIC process described above. ARIN ARIN operates an open membership policy but does not link allocations to membership. A separate "Registration Services Agreement" is undertaken with organisations requiring IP address space and membership is extended free of charge to ISP organisations receiving allocations from ARIN. Minimum allocations (/20) are made to ISPs who are able to meet strict allocation criteria. These criteria require that the organisation must be multihomed and able to demonstrate that they have used a /21 from their upstream provider. On receipt of an allocation from ARIN, the organisation must agree to renumber from prior address space. 4. Proposal 4.1 Allocation criteria APNIC proposes the following policy. First allocations of address space will be made to members who are: 1) Multi-homed. AND 2) Have used a /22 from their upstream provider and can demonstrate a detailed plan for use of a /21 within a year. If the organisation is singly-homed or not yet connected to the Internet then: 1) They must demonstrate a detailed plan for immediate use of a /22 for infrastructure (within three months) and a /21 within one year. In this case, documentary evidence may be required, including purchase receipts or orders. AND 2) They must demonstrate a detailed plan to become multi-homed within three months, with such plans to include peer AS numbers, contact names at the connecting organisation, and a planned connection date. Note that allocations under this policy will be subject to the terms and conditions of the APNIC leasing policy, and subject to revocation if the conditions are not met. In either of the above cases, organisations renumbering must agree to do so within one year of receiving their allocation. 4.2 Refund If a member does not meet the first allocation criteria and is denied address space within 6 months of their membership approval, they will be able to receive a pro-rata refund (minus the start-up fee) in accordance with the Membership Agreement clause, 25(see http://www.apnic.net/corpdocs/MembAgree.htm) 5. Discussion APNIC proposes to establish clear criteria for making an initial allocation, as detailed above. 5.1 Advantages By providing a clear framework in which a first allocation is made to a member, both applicants and APNIC will save considerable resources. Organisations seeking address space will also have more certainty in the membership process. The allocation policy will promote the aggregation and hierarchy necessary to ensure scalable growth of the Internet. 5.2 Disadvantages The networking characteristics of the region show that there are a large number of small ISPs in the region. Analysis of APNIC membership categories (which are determined by resources held) shows that out of a total of 550 members in August 2000, 406 (73%) members are in the small category which is defined as holding less than or equivalent to a /19. The economic downturn in the region is showing signs of abating, nevertheless there are many ISPs that approach APNIC with very small requirements. While some may be accepted under current policies, more may be turned away under the new criteria. In the region, there are also countries which may be disadvantaged due to very limited (if any) Internet infrastructure. For these reasons, APNIC has proposed that the requirement for immediate utilisation of address space be set at /22 (relatively small when compared with ARIN's requirement for ISPs to have used a /21 from their upstream provider). 6. Conclusion It is recommended that clearly defined criteria for the first allocation are established as proposed above, taking into account regional and topological considerations. To ensure consistency in the region, there is also an expectation that the NIRs will implement this proposal in accordance with their own policy processes. 7. Implementation It is proposed that APNIC implement this new policy three months after consensus has been reached. All necessary supporting documents will be prepared by APNIC before the implementation date. These will include updating any necessary documentation, including request and membership application forms. The community will be informed of the changes in policy through the APNIC website and related mailing lists. * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Fri Sep 29 17:53:44 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id RAA81102; Fri, 29 Sep 2000 17:53:44 +1000 (EST) Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id RAA81087; Fri, 29 Sep 2000 17:53:41 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id RAA81068 for ; Fri, 29 Sep 2000 17:53:40 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id RAA06267 for ; Fri, 29 Sep 2000 17:53:38 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma006265; Fri, 29 Sep 00 17:53:33 +1000 Date: Fri, 29 Sep 2000 17:53:33 +1000 (EST) From: APNIC Secretariat X-Sender: bc@julubu.staff.apnic.net To: apnic-announce@lists.apnic.net Subject: [apnic-talk] [apnic-announce] Hostmaster Consultation Sessions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] We are pleased to announce that Hostmaster Consultation Sessions will be available during the APNIC Open Policy Meeting, 25 October-27 October 2000. The session is an opportunity to meet and discuss Internet Resource related matters with APNIC Hostmaster staff. If you would like to attend one of the sessions, then please register your details at the following web site: http://www.apnic.net/apnic-bin/register/register.pl If you are interested, we would recommend that you register as soon as possible as there are a limited number of sessions. If you have any questions, please email . We look forward to seeing you at our meeting. Best Regards, APNIC Hostmaster Team -- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@lists.apnic.net Fri Sep 29 17:54:14 2000 Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id RAA81204; Fri, 29 Sep 2000 17:54:14 +1000 (EST) Received: (from majordom@localhost) by ns.apnic.net (8.9.3/8.9.3) id RAA81191; Fri, 29 Sep 2000 17:54:11 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.3/8.9.3) with ESMTP id RAA81171 for ; Fri, 29 Sep 2000 17:54:10 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id RAA06278 for ; Fri, 29 Sep 2000 17:54:08 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma006272; Fri, 29 Sep 00 17:53:59 +1000 Date: Fri, 29 Sep 2000 17:53:58 +1000 (EST) From: APNIC Secretariat X-Sender: bc@julubu.staff.apnic.net To: apnic-announce@lists.apnic.net Subject: [apnic-talk] [apnic-announce] IP addresses for mobile phones Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@lists.apnic.net Precedence: bulk [Note "reply-to:" field] APNIC Open Policy Meeting Update: IP ADDRESSES FOR MOBILE PHONES The discussion paper "Tackling the Mobile Addressing Problem" examines the issues faced in developing a scalable solution for assigning IP addresses to mobile phones. This paper was prepared by Kim Fullbrook on behalf of the GSM Association and will be presented by Linh Duong at the Address Policy SIG at the APNIC meeting on 26 October. APNIC now seeks your thoughts and suggestions on this issue. The discussion paper (along with other meeting documents) is available from the meeting web site at: http://www.apnic.net/meetings/ From the navigation menu just follow the links: Programme -> Documents We look forward to receiving your comments on the mailing list and at the meeting. ********************* + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net *