From bmanning at vacation.karoshi.com Tue Sep 25 22:29:34 2001 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 26 Sep 2001 02:29:34 +0000 (UCT) Subject: RFC 3177 Message-ID: <200109260229.CAA00799@vacation.karoshi.com> is now available... ...................... The official RFC announcement will be sent to the public distribution list in one working day from this posting. RFC 3177 Title: IAB/IESG Recommendations on IPv6 Address Allocations to Sites Author(s): IAB, IESG Status: Informational Date: September 2001 Mailbox: iab at iab.org, iesg at ietf.org Pages: 10 Characters: 23178 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-iesg-ipv6-addressing-recommendations-03.txt pathname: ftp://ftp.rfc-editor.org/in-notes/rfc3177.txt ....................... --bill From memsvcs at arin.net Wed Sep 26 11:24:08 2001 From: memsvcs at arin.net (Member Services) Date: Wed, 26 Sep 2001 11:24:08 -0400 (EDT) Subject: Policy Proposal 2001-4 Message-ID: ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. The three RIRs have compiled the proposal document provided below using feedback received from the RIR communities since the publishing of the provisional IPv6 document in 1999. In the interest of maintaining global IPv6 policies, the IPv6 policy discussion in the ARIN region will be held in conjunction with discussions taking place in the APNIC and RIPE NCC regions. When formulating this framework document, the RIRs took the following feedback into account: * The allocation criteria should be such that it is easy to obtain IPv6 address space. * The size of the initial allocation should be large enough to allow flexibility in addressing infrastructure and customer sites. This results in the following proposed IPv6 allocation criteria considerations: 1. recognize existing infrastructure (both IPv4 and IPv6) where it exists and calculate IPv6 address needs based on existing networks. 2. apply the slow start mechanism only for 'IPv6 only' networks without existing IPv4 infrastructure 3. reduce the minimum allocation size for those IPv6 only networks (unless larger requirements are shown) 4. measure the utilization rate with the HD ratio rather than percentages 5. make subsequent allocations when the HD ratio is reached The full text of the proposal document is provided below. This policy proposal discussion will take place on the IPv6 working group mailing list (v6wg at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers *** Proposal Document *** 1. Abstract This document provides a set of proposed policies for the management of IPv6 address space, specifically concerning the allocation of address space allocated by Regional Internet Registries (RIRs) to organisations operating IPv6 networks. 2. Overview Under the current system of management of global IP address space, Regional Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions. In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy document for IPv6, which has been in operation since then. Since 2000, this document has been under review and discussion, and through this process many issues have been raised. It is the aim of this document to propose a new policy framework for IPv6 address space management which takes into account the operational experience of the past 3 years, and addresses most if not all of the major issues raised through the open review process. This document does not attempt to provide details of policy implementation, procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here. 3. Address Space Requirement for Initial Allocation It is proposed to recognise existing network infrastructure and address utilisation (both IPv4 and IPv6). New IPv6 address needs are then based on these existing networks. In assessing a request for an initial allocation, there are 3 possible cases to consider: 3.1. the requesting organisation has an existing IPv4 network which will be addressed by the new IPv6 allocation 3.2. the requesting organisation has an existing IPv6 network 3.3. the requesting organisation has no network at all 3.1. Case 1 - Existing IPv4 services Where IPv6 address space is requested for addressing an existing IPv4 network, the address requirement is determined according to the structure and customer base of the existing IPv4 network. This only relates to the part of the network that will be migrated to IPv6. Additional policies may require the return of IPv4 address space to the RIR or upstream ISP, in the case the existing network is renumbered to the new IPv6 space in future. 3.2. Case 2 - Existing IPv6 services Where an IPv6 allocation is requested by an organisation to address infrastructure which is already addressed by IPv6 addresses from an upstream provider (or from the 6BONE), the address requirement is determined from the number of site addresses assigned by the organisation (as registered in the appropriate whois database). Where existing address space is no longer used, it must be returned. 3.3. Case 3 - No existing IPv4 or IPv6 services Where IPv6 address space is required by an organisation which has no existing infrastructure, the address requirement will be assessed according to network architecture plans and other documentation provided to the RIR within the request process. Such documentation be thorough enough to satisfy the RIR that the network deployment is genuine, however the specific details of documentation requirements will be defined separately. 4. Size of Initial Allocation The amount of addresses allocated to an existing network, will be determined based on the existing infrastructure and address utilisation of that network. For new networks without existing infrastructure, it is proposed to establish a minimum allocation for IPv6 address space. It is suggested to keep the size of the initial allocation relatively small (a /35 or smaller) and to determine the size of subsequent allocations based on the utilisation rate of the initial allocation (this is called slow start mechanism). This will allow easy access to IPv6 allocations for newcomers. At the same time possible wastage of address space and routing table growth will be limited. 5. Qualification for Subsequent Allocation An organisation which has already received address space from an RIR may receive a subsequent allocation providing that its existing address space is utilised in accordance with these policies. As explained below, the HD-Ratio will be used to measure utilisation of the existing address space. An organisation which is deploying substantial new network infrastructure may receive a subsequent allocation before it has reached the required utilisation threshold, providing that the address requirement would immediate cause the organisation to exceed the utilisation threshold. In such cases, the new network infrastructure will be examined by the RIR as if it is a request for a new network, and the RIR may require the same level of documentation detail, in order to approve the allocation. 6. Address Space Requirement for Subsequent Allocation For subsequent allocations, the RIR should assess the address requirement according to the organisation's history of IP address usage, as well as its stated requirements for future development. In general, the RIR should provide address space for a fixed time period of 2 years. The above recommendation should be followed in cases where the organisation concerned has complied with all relevant address management policies. In other cases, the RIR may allocate for a shorter future timeframe, and require that identified problems be rectified before larger allocations are made. 7. IPv6 Utilisation Metric: the HD-Ratio In IPv4, currently, a "utilisation threshold" of 80% is applied consistently in determining whether an IPv4 address pool is to be considered utilised, regardless of the size of that block. Consequently, an organisation which holds IP address space may not receive additional addresses until it has utilised at least 80% of the address space held. For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" rather than by a simple percentage. The HD-Ratio was proposed by Durand in "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the original H-Ratio defined by Huitema in RFC-1715). Using the HD-ratio we can establish a utilisation metric which allows percentage utilisation to decrease as the address space grows large. This is appropriate for management of the much larger blocks of address space under IPv6, and the likelihood of complex routing and allocation hierarchies within those address blocks. More details about the HD ratio can be found in Appendix A. Appendix A: In the general case, where individual objects are allocated out of an arbitrary address space, the HD-Ratio is calculated as follows: log(number of allocated objects) HD = -------------------------------------------- log(maximum number of allocatable objects) Where the objects being allocated are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P, we can restate this formula as follows (where A is the number of /48 prefixes actually assigned): log(A) log(A) In other words, the utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as: ((48-P)*HD) T = 2 In accordance with the recommendations of draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations. The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 3 45 35184372088832 68719476736 0.2% 2 46 70368744177664 119647558364 0.2% 1 47 140737488355328 208318498661 0.1% 0 48 281474976710656 362703572709 0.1% From memsvcs at arin.net Wed Sep 26 11:17:21 2001 From: memsvcs at arin.net (Member Services) Date: Wed, 26 Sep 2001 11:17:21 -0400 (EDT) Subject: Policy Proposal 2001-3 Message-ID: ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. Proposal: Extend the existing IPv4 micro-allocation policy for exchange points, gTLDs, ccTLDs, RIRs, and ICANN to include IPv6 micro-allocations. ARIN's current IPv4 micro-allocation policy is documented at: http://www.arin.net/regserv/ip-assignment.html This policy proposal discussion will take place on the IPv6 working group mailing list (v6wg at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers From huberman at gblx.net Wed Sep 26 11:56:43 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 26 Sep 2001 08:56:43 -0700 (MST) Subject: Policy Proposal 2001-3 In-Reply-To: Message-ID: > Proposal: Extend the existing IPv4 micro-allocation policy for > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > include IPv6 micro-allocations. ARIN's current IPv4 > micro-allocation policy is documented at: > > http://www.arin.net/regserv/ip-assignment.html I hope folks will see this is a no-brainer. ARIN is the only RIR that has a working, *useful* micro-allocation policy for "golden" networks. As I believe the IPv4 guidelines have served both ARIN and the community well, I feel extending these guidelines to IPv6 is, again, a no-brainer. /david From randy at psg.com Wed Sep 26 13:13:08 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 10:13:08 -0700 Subject: Policy Proposal 2001-3 References: Message-ID: > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy and Members > meetings in Miami, scheduled for October 28 - 31, 2001. All feedback > received on the mailing lists about this policy proposal will be > included in the discussions that will take place in Miami. > > Proposal: Extend the existing IPv4 micro-allocation policy for > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > include IPv6 micro-allocations. ARIN's current IPv4 > micro-allocation policy is documented at: > > http://www.arin.net/regserv/ip-assignment.html as, imiho, all this stuff except for IXen is absolutely useless, i see no need to extend it to v6. the dns protocols provide the redundancy to handle the dns servers as well as a 'golden' space. if you think otherwise, please describe your failure model. why the heck do rirs need special address space? they can justify it like the rest of us. eat your own dog food. and why does icann need any address space at all? after all, they have usa today! :-)/2 but i do see micro-allocations for ixen as very useful. randy From markk at netsol.com Wed Sep 26 13:44:23 2001 From: markk at netsol.com (Mark Kosters) Date: Wed, 26 Sep 2001 13:44:23 -0400 Subject: Policy Proposal 2001-3 In-Reply-To: ; from randy@psg.com on Wed, Sep 26, 2001 at 10:13:08AM -0700 References: Message-ID: <20010926134423.K1105@slam.admin.cto.netsol.com> On Wed, Sep 26, 2001 at 10:13:08AM -0700, Randy Bush wrote: > as, imiho, all this stuff except for IXen is absolutely useless, i see no > need to extend it to v6. What about the root servers? Mark -- Mark Kosters markk at netsol.com Verisign Applied Research From bmanning at vacation.karoshi.com Wed Sep 26 14:20:02 2001 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 26 Sep 2001 18:20:02 +0000 (UCT) Subject: Policy Proposal 2001-3 In-Reply-To: from "Member Services" at Sep 26, 2001 11:17:21 AM Message-ID: <200109261820.SAA01526@vacation.karoshi.com> > > > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy and Members > meetings in Miami, scheduled for October 28 - 31, 2001. All feedback > received on the mailing lists about this policy proposal will be > included in the discussions that will take place in Miami. > > Proposal: Extend the existing IPv4 micro-allocation policy for > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > include IPv6 micro-allocations. ARIN's current IPv4 > micro-allocation policy is documented at: > > http://www.arin.net/regserv/ip-assignment.html > > This policy proposal discussion will take place on the IPv6 working > group mailing list (v6wg at arin.net). Subscription information is > available at http://www.arin.net/members/mailing.htm > > Richard Jimmerson > Director of Operations > American Registry for Internet Numbers > Its not clear that IXen will need to have micro-allocations, at least in the long term. http://www.ietf.org/internet-drafts/draft-kato-bgp-ipv6-link-local-00.txt describes how use of IPv6 link-local addresses, which are not RIR managed, can be used to address IXen that need IPv6 for BGP. other than that, Friend Bush is, as usual, persuasive in his arguments that [*]TLD's, RIRs, and ICANN should use the same processes/procedures as the rest of us. --bill From randy at psg.com Wed Sep 26 13:53:32 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 10:53:32 -0700 Subject: Policy Proposal 2001-3 References: <20010926134423.K1105@slam.admin.cto.netsol.com> Message-ID: >> as, imiho, all this stuff except for IXen is absolutely useless, i see no >> need to extend it to v6. > What about the root servers? what about them? what good is it for them to be in special address space? again, tell me the failure model this is supposed to address. randy From ahp at hilander.com Wed Sep 26 13:56:57 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 11:56:57 -0600 Subject: Policy Proposal 2001-3 References: Message-ID: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Member Services" Cc: ; Sent: Wednesday, September 26, 2001 11:13 Subject: Re: Policy Proposal 2001-3 > > as, imiho, all this stuff except for IXen is absolutely useless, i see no > need to extend it to v6. > > the dns protocols provide the redundancy to handle the dns servers as well > as a 'golden' space. if you think otherwise, please describe your failure > model. If you call waiting for timeouts an acceptable method of failover then I suppose you're right. I however don't agree. Alec From randy at psg.com Wed Sep 26 13:58:33 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 10:58:33 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: >> the dns protocols provide the redundancy to handle the dns servers as well >> as a 'golden' space. if you think otherwise, please describe your failure >> model. > If you call waiting for timeouts an acceptable method of failover then I > suppose you're right. I however don't agree. and how does using some specified address space change this? From ahp at hilander.com Wed Sep 26 13:59:25 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 11:59:25 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: <0f5901c146b4$facf6d00$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: "Member Services" ; ; Sent: Wednesday, September 26, 2001 11:58 Subject: Re: Policy Proposal 2001-3 > and how does using some specified address space change this? Because it makes multi-homing on a small block of address space feasible. Alec From randy at psg.com Wed Sep 26 14:03:44 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 11:03:44 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: >>> the dns protocols provide the redundancy to handle the dns servers as >>> well as a 'golden' space. if you think otherwise, please describe your >>> failure model. >> If you call waiting for timeouts an acceptable method of failover then I >> suppose you're right. I however don't agree. > Because it makes multi-homing on a small block of address space feasible. and how is it infeasible now? you may want to look at the address space the roots and gtlds are in now before answering. and how does being multi-homed mean that one will not time out on the server if the deamon is dead but the box is up and reachable? and do note that the long timeout is not relevant if the box is not reachable. the golden space snake oil has been available to roots for some years. how many use it? perhaps root operators have actually studied the issues and voted with their feet? randy From markk at netsol.com Wed Sep 26 14:09:50 2001 From: markk at netsol.com (Mark Kosters) Date: Wed, 26 Sep 2001 14:09:50 -0400 Subject: Policy Proposal 2001-3 In-Reply-To: ; from randy@psg.com on Wed, Sep 26, 2001 at 11:03:44AM -0700 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: <20010926140950.P1105@slam.admin.cto.netsol.com> On Wed, Sep 26, 2001 at 11:03:44AM -0700, Randy Bush wrote: > the golden space snake oil has been available to roots for some years. how > many use it? perhaps root operators have actually studied the issues and > voted with their feet? Cause all the roots got their snake oil before it was termed golden space. Bigger question is before we throw all this out, we need to closely look the number of unique addresses we want to have active to bootstrap the system query. Mark -- Mark Kosters markk at netsol.com Verisign Applied Research From ahp at hilander.com Wed Sep 26 14:09:57 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 12:09:57 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 12:03 Subject: Re: Policy Proposal 2001-3 > > and how is it infeasible now? you may want to look at the address space the > roots and gtlds are in now before answering. Are you suggesting that new gTLD servers are never going to be deployed, or that existing ones will not change? > > and how does being multi-homed mean that one will not time out on the server > if the deamon is dead but the box is up and reachable? It doesn't. However, ARIN cannot address issues of operator error on a server. If you would like ARIN to be able to do this, I suggest you lobby the AC. > > and do note that the long timeout is not relevant if the box is not > reachable. True, but if the appropriate internet connection is down then it is very relevant, and I see the type of errors you describe above as being relatively few. > > the golden space snake oil has been available to roots for some years. how > many use it? perhaps root operators have actually studied the issues and > voted with their feet? *shrug*, perhaps. I'd like to see your data on this instead changing a ratified AC proposal based on your straw-man. Alec From randy at psg.com Wed Sep 26 14:45:34 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 11:45:34 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <20010926140950.P1105@slam.admin.cto.netsol.com> Message-ID: > Bigger question is before we throw all this out, we need to closely look > the number of unique addresses we want to have active to bootstrap the > system query. it seems to me that richness of diversity in this is good. i.e. i find the roots's address space diversity more apprealing than the gtlds. though i admit i can not easily expresss why. for a new rathole, the prepends don't cheer me. am i off in this? randy --- a.root-servers.net 198.41.0.0/24 7018 10913 10913 10913 10913 19836 2914 10913 10913 10913 10913 10913 10913 19836 b.root-servers.net 128.9.0.0/16 2914 226 7018 2914 226 c.root-servers.net 192.33.4.0/24 2914 174 174 174 174 2149 7018 174 2149 d.root-servers.net 128.8.0.0/16 2914 209 27 7018 209 27 e.root-servers.net 192.203.230.0/24 7018 297 2914 297 f.root-servers.net 192.5.4.0/23 2914 6461 3557 7018 701 3557 g.root-servers.net 192.112.36.0/24 7018 209 568 5927 2914 209 568 5927 h.root-servers.net 128.63.0.0/16 2914 7170 13 7018 7170 13 i.root-servers.net 192.36.148.0/24 2914 1239 1880 8674 7018 1239 1880 8674 j.root-servers.net 198.41.0.0/24 7018 10913 10913 10913 10913 19836 2914 10913 10913 10913 10913 10913 10913 19836 k.root-servers.net 193.0.14.0/24 7018 3561 5378 5459 2914 5413 5413 5459 l.root-servers.net 198.32.64.0/24 2914 20144 7018 2914 20144 m.root-servers.net 202.12.27.0/24 2914 2516 7500 7018 3549 2518 7500 a.gtld-servers.net 192.5.6.0/24 7018 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 2914 10913 10913 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 b.gtld-servers.net 192.33.14.0/24 2914 209 1668 6992 7018 209 1668 6992 c.gtld-servers.net 192.26.92.0/24 2914 6461 1668 10593 7018 1668 10593 d.gtld-servers.net 192.31.80.0/24 7018 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 2914 10913 10913 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 e.gtld-servers.net 192.12.94.0/24 2914 2516 7018 209 2516 f.gtld-servers.net 192.35.51.0/24 2914 701 14744 7018 14744 14744 14744 14744 g.gtld-servers.net 192.42.93.0/24 2914 701 7342 7018 7342 h.gtld-servers.net 192.54.112.0/24 2914 1239 1755 13214 7018 1239 1755 13214 i.gtld-servers.net 192.36.144.0/24 2914 1239 1880 8674 7018 1239 1880 8674 j.gtld-servers.net 210.132.96.0/19 2914 2516 7018 701 2516 k.gtld-servers.net 213.177.192.0/21 2914 1239 1755 13214 7018 1239 1755 13214 l.gtld-servers.net 192.41.162.0/24 2914 701 14745 7018 14745 14745 14745 14745 m.gtld-servers.net 202.153.112.0/20 2914 4637 9925 7018 701 4637 9925 -30- From randy at psg.com Wed Sep 26 14:47:22 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 11:47:22 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> Message-ID: > *shrug*, perhaps. I'd like to see your data on this instead changing a > ratified AC proposal based on your straw-man. let's just say that, imiho, ac proposals have been varied, to be polite. so i try to stick with the technical engineering, not the social. randy From ahp at hilander.com Wed Sep 26 14:58:11 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 12:58:11 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> Message-ID: <107001c146bd$305c6790$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 12:47 Subject: Re: Policy Proposal 2001-3 > > let's just say that, imiho, ac proposals have been varied, to be polite. > so i try to stick with the technical engineering, not the social. Well the discussion has proceeded over a rather long period of time, to be sure. However to my knowledge gTLD servers have always been part of all of the proposals. Alec From randy at psg.com Wed Sep 26 15:11:59 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:11:59 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> Message-ID: > Well the discussion has proceeded over a rather long period of time a process improvement, indeed. as is this public discussion. thanks arin. > gTLD servers have always been part of all of the proposals. if having servers in 'special' space has yet to be shown to improve use, why is not not appropriate to treat them just as we do all others? they can get routable space from theu upstreams or justify space if their needs are large enough. and, if the above does not work, then maybe the whole model is broken for many many people. and you may not want to go there. randy --- # grep \"..\" /etc/named.conf | wc 21 153 975 From ahp at hilander.com Wed Sep 26 15:38:13 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:38:13 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com> Message-ID: <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:11 Subject: Re: Policy Proposal 2001-3 > > > gTLD servers have always been part of all of the proposals. > > if having servers in 'special' space has yet to be shown to improve use, > why is not not appropriate to treat them just as we do all others? they > can get routable space from theu upstreams or justify space if their needs > are large enough. What do you mean by use? The whole idea behind the micro-allocations from the beginning was the notion that some pieces of infrastructure: a) Really do need their own PI blocks b) don't consume enough IP addresses to meet standard requirements. The goal was to put guidelines around which infrastructure met these requirements. Alec From randy at psg.com Wed Sep 26 15:43:25 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:43:25 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> Message-ID: >> if having servers in 'special' space has yet to be shown to improve use, >> why is not not appropriate to treat them just as we do all others? they >> can get routable space from theu upstreams or justify space if their needs >> are large enough. > What do you mean by use? reasonable results when querying the servers using the dns protocols. > The whole idea behind the micro-allocations from the beginning was the notion > that some pieces of infrastructure: > a) Really do need their own PI blocks and i have yet to see this assertion supported technically for anything but IXen randy From ahp at hilander.com Wed Sep 26 15:44:30 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:44:30 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com> Message-ID: <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:43 Subject: Re: Policy Proposal 2001-3 > > > The whole idea behind the micro-allocations from the beginning was the notion > > that some pieces of infrastructure: > > a) Really do need their own PI blocks > > and i have yet to see this assertion supported technically for anything but > IXen Well it looks like we've gotten back to the beginning, with you asserting that DNS's ability to handle failures is sufficient, and my assertion that said ability is not acceptable. Alec From randy at psg.com Wed Sep 26 15:46:30 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:46:30 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> Message-ID: > Well it looks like we've gotten back to the beginning, with you asserting > that DNS's ability to handle failures is sufficient, and my assertion that > said ability is not acceptable. as the rfcs support my argument, please state yours in similar technical terms. randy From ahp at hilander.com Wed Sep 26 15:47:42 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:47:42 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> Message-ID: <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:46 Subject: Re: Policy Proposal 2001-3 > > as the rfcs support my argument, please state yours in similar technical > terms. It's pretty simple. Waiting for requests to timeout is not an optimal solution for failover. Alec From ahp at hilander.com Wed Sep 26 15:49:54 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:49:54 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> Message-ID: <112201c146c4$69e05b50$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:46 Subject: Re: Policy Proposal 2001-3 > > as the rfcs support my argument, please state yours in similar technical > terms. And just because that's how it is done now does not qualify as an argument. Alec From randy at psg.com Wed Sep 26 15:50:47 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:50:47 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> Message-ID: > Waiting for requests to timeout is not an optimal solution for failover. maybe you missed the following message, critical parts flagged From: Randy Bush To: "Alec H. Peterson" Cc: v6wg at arin.net, ppml at arin.net Subject: Re: Policy Proposal 2001-3 Date: Wed, 26 Sep 2001 11:03:44 -0700 >>> the dns protocols provide the redundancy to handle the dns servers >>> as well as a 'golden' space. if you think otherwise, please >>> describe your failure model. >> If you call waiting for timeouts an acceptable method of failover >> then I suppose you're right. I however don't agree. > Because it makes multi-homing on a small block of address space > feasible. and how is it infeasible now? you may want to look at the address space the roots and gtlds are in now before answering. ** and how does being multi-homed mean that one will not time out on the ** server if the deamon is dead but the box is up and reachable? ** and do note that the long timeout is not relevant if the box is not ** reachable. the golden space snake oil has been available to roots for some years. how many use it? perhaps root operators have actually studied the issues and voted with their feet? randy From ahp at hilander.com Wed Sep 26 15:55:28 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:55:28 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com><111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> Message-ID: <112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:50 Subject: Re: Policy Proposal 2001-3 > > Waiting for requests to timeout is not an optimal solution for failover. > > maybe you missed the following message, critical parts flagged Randy, I've always thought you were good at making solid arguments, but this is just hilarious. Your assertion that DNS timeouts work fine in 'some failure modes' is nothing short of laughable, especially since being able to multi-home effectively will work fine in the failure modes you describe, plus the ones where a single service provider causes an otherwise single-homed address to be unreachable. Furthermore, your apparent intentional ignorance of these points that I have mentioned in other messages is also rather amusing. Unless you actually have something new to add to this discussion I think we're done here. Alec From randy at psg.com Wed Sep 26 16:05:04 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 13:05:04 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> <112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> Message-ID: > Your assertion that DNS timeouts work fine in 'some failure modes' alex, i suspect that you have a problem with your mail user agent. i never said any such thing, at least not in today's mail. i just grepped it. other things also make me suspect you have a problem with your mail reading agent. have a great day. randy From ahp at hilander.com Wed Sep 26 16:12:40 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 14:12:40 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com><111801c146c4$1af73ef0$3220f1d8@windows.hilander.com><112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> Message-ID: <118401c146c7$b531f1b0$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 14:05 Subject: Re: Policy Proposal 2001-3 > > alex, Since you can't even get my name right I suspect it is you who is having the literacy problem. > i suspect that you have a problem with your mail user agent. i > never said any such thing, at least not in today's mail. i just grepped > it. other things also make me suspect you have a problem with your > mail reading agent. Perhaps 'working fine' was not an accurate paraphrasing, however: [snip] and how does being multi-homed mean that one will not time out on the server if the deamon is dead but the box is up and reachable? and do note that the long timeout is not relevant if the box is not reachable. [snip] Which to my mind was your assertion that there are some things PI space won't fix. You will also note I did not dispute your assertions, but rather pointed out that they were beyond the scope of the discussion. Just to remind everybody (and you Randy since apparently you have forgotten) the discussion at hand is whether to modify ARIN allocation policy to allow critical DNS server (gTLD, ccTLD, etc) to get small, PI blocks of address space directly from ARIN. From my standpoint, the main reason to do this is to allow such servers to multi-home effectively, to improve reliability. Randy has asserted that is not necessary, since DNS timeouts accomplish the same thing with respect to reliablity. I would agree, if we changed it to mean 'eventual reliability'. However, I personally feel we can do better than eventual reliability, and since we can we very well should. Allowing critical DNS servers to multi-home makes it so it is less likely that clients querying these servers will need to resort to waiting for queries to timeout. Instead, those queries are more likely to be answered on the first try, since the network connectivity for the server can be provided by multiple providers easily. But then, I must be wrong, because the RFCs say so, and we know they're always right. Alec From randy at psg.com Wed Sep 26 16:17:25 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 13:17:25 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> <112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> <118401c146c7$b531f1b0$3220f1d8@windows.hilander.com> Message-ID: > Just to remind everybody (and you Randy since apparently you have > forgotten) the discussion at hand is whether to modify ARIN allocation > policy to allow critical DNS server (gTLD, ccTLD, etc) to get small, PI > blocks of address space directly from ARIN. Date: Wed, 26 Sep 2001 11:17:21 -0400 (EDT) From: Member Services To: arin-announce at arin.net, v6wg at arin.net Subject: Policy Proposal 2001-3 ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. Proposal: Extend the existing IPv4 micro-allocation policy for exchange points, gTLDs, ccTLDs, RIRs, and ICANN to include IPv6 micro-allocations. ARIN's current IPv4 micro-allocation policy is documented at: http://www.arin.net/regserv/ip-assignment.html This policy proposal discussion will take place on the IPv6 working group mailing list (v6wg at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers From hinden at iprg.nokia.com Wed Sep 26 19:46:17 2001 From: hinden at iprg.nokia.com (Bob Hinden) Date: Wed, 26 Sep 2001 16:46:17 -0700 Subject: Policy Proposal 2001-3 In-Reply-To: Message-ID: <4.3.2.7.2.20010926163036.02471938@mailhost.iprg.nokia.com> > Proposal: Extend the existing IPv4 micro-allocation policy for > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > include IPv6 micro-allocations. ARIN's current IPv4 > micro-allocation policy is documented at: > > http://www.arin.net/regserv/ip-assignment.html Some questions: What would the specific IPv6 allocation be under this proposal? The current policy text (copied below) talks about a [IPv4] prefix no longer than /24 that will not be announced on the Internet. Is the proposal for an IPv6 prefix of /64, /48, sometime else? Why is a "micro-allocation" needed for IPv6? IPv6 has unicast addresses of different scope (i.e., link-local and site-local). These might provide the desired functionality if global reachability is not desired. Perhaps the proposal could be fleshed out a bit. Bob p.s. I will be out tomorrow for Yom Kippur so won't be reading email until Friday. -------------------------------------------------------------------------- Micro-allocations ARIN makes micro-allocations to infrastructures including public exchange points, gTLDs, ccTLDs, RIRs, and ICANN, as well as all named servers of the domain. A micro-allocation will be no longer than a /24 and will not be announced on the public Internet. Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two), ASN, and contact information. Endusers receiving these micro-allocations will be charged according to ARIN's Fee Schedule under the section titled Individual Address Space Assignment. This policy does not preclude exchange point operators from requesting address space under other policies.