From bicknell at ufp.org Thu Mar 3 16:51:10 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 3 Mar 2005 16:51:10 -0500 Subject: [ppml] Proposed Policy: Lame Delegations in IN-ADDR.ARPA In-Reply-To: References: Message-ID: <20050303215110.GA73991@ussenterprise.ufp.org> In a message written on Thu, Feb 17, 2005 at 01:10:41PM -0500, Member Services wrote: > ARIN will actively identify lame DNS name server(s) for in-addr.arpa This should be generic to all reverse DNS, including in-addr.arpa, ipv6.int, ip6.arpa, and/or anything that comes along in the future. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From memsvcs at arin.net Mon Mar 7 14:24:53 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 7 Mar 2005 14:24:53 -0500 Subject: [ppml] AC Initial Review Message-ID: <20050307192506.957331FE8E@mercury.arin.net> On March 3, 2005, the ARIN Advisory Council (AC) concluded their initial review of three proposed policies. The AC supported moving the following proposals forward for discussion: Lame Delegations in IN-ADDR.ARPA http://www.arin.net/mailing_lists/ppml/3176.html Directory Services Overhaul http://www.arin.net/mailing_lists/ppml/3166.html These proposals will be numbered and formally posted by March 19, 2005 (the posting deadline for the upcoming meeting). The AC abandoned the following proposal: Adding an HD ratio choice for new IPv4 allocations http://www.arin.net/mailing_lists/ppml/3175.htm The AC stated that in the past a similar proposal had been discussed and was rejected by the community. In accordance with the ARIN Internet Resource Policy Evaluation Process the author may elect to use the petition process to attempt to advance their proposal. The deadline for the author to initiate a petition is 2400 Eastern Time, March 9, 2005. For petition details see the section called "Petition Process" at http://www.arin.net/policy/ipep.html. Regards, Member Services Department American Registry for Internet Numbers =================================================================== Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL http://www.arin.net/ARIN-XV/ E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net =================================================================== From Michael.Dillon at radianz.com Wed Mar 9 06:05:38 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 9 Mar 2005 11:05:38 +0000 Subject: [ppml] Petition Request for HD Ratio proposal Message-ID: This is a formal petition to advance the policy proposal entitled "Adding an HD ratio choice for new IPv4 allocations". The full text of the proposal is posted on the ARIN website at this URL: http://www.arin.net/mailing_lists/ppml/3175.html This policy proposal incorporates changes to address the objections raised the last time a similar proposal was before the members. I believe that we should all support discussing and EVOLVING policy in the open forum of the meetings. According to the Internet Resource Policy Evaluation Process, people who wish to document their support for the petition must do the following within the next five (5) days: 1) post a response to the Public Policy Mailing List stating their support for the proposal, and 2) send email to petition at arin.net with full point of contact information, including their telephone number and organizational affiliation. The ARIN President will verify whether people from at least four different organizations support the petitioned policy proposal. If you have any questions about this process you may wish to refer to the ARIN website at http://www.arin.net/policy/ipep.html for the full text explaining the petition process. --Michael Dillon From memsvcs at arin.net Wed Mar 9 12:07:26 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 09 Mar 2005 12:07:26 -0500 Subject: [ppml] Petition Request for HD Ratio proposal In-Reply-To: References: Message-ID: <422F2D4E.8000105@arin.net> The deadline for issuing statements of support for this petition is 2400 Eastern Time, March 16, 2005. If the petition is successful, the policy proposal will be numbered, posted online for discussion, and presented at the upcoming Public Policy Meeting in Orlando. If the petition is not successful, the policy proposal will be considered closed. Regards, Member Services Department American Registry for Internet Numbers ====================================================================== Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL http://www.arin.net/ARIN-XV/ E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net ====================================================================== Michael.Dillon at radianz.com wrote: > This is a formal petition to advance the policy proposal entitled > "Adding an HD ratio choice for new IPv4 allocations". The full > text of the proposal is posted on the ARIN website at this URL: > http://www.arin.net/mailing_lists/ppml/3175.html > This policy proposal incorporates changes to address the > objections raised the last time a similar proposal was > before the members. I believe that we should all support > discussing and EVOLVING policy in the open forum of > the meetings. > > According to the Internet Resource Policy Evaluation Process, > people who wish to document their support for the petition > must do the following within the next five (5) days: > > 1) post a response to the Public Policy Mailing List > stating their support for the proposal, and > 2) send email to petition at arin.net with full point of > contact information, including their telephone number > and organizational affiliation. > > The ARIN President will verify whether people from at > least four different organizations support the petitioned > policy proposal. > > If you have any questions about this process you may wish to refer > to the ARIN website at http://www.arin.net/policy/ipep.html for the > full text explaining the petition process. > > --Michael Dillon > > From memsvcs at arin.net Wed Mar 9 16:13:23 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 09 Mar 2005 16:13:23 -0500 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul Message-ID: <422F66F3.3090606@arin.net> ARIN welcomes feedback and discussion about this policy proposal in the weeks leading to the ARIN Public Policy Meeting in Orlando, Florida, scheduled for April 18-20, 2005. The policy proposal text is below and can be found at http://www.arin.net/policy/2005_2.html. According to the ARIN Internet Resource Policy Evaluation Process the ARIN Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List can be found at http://www.arin.net/mailing_lists/index.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. ARIN's Policy Proposal Archive can be found at http://www.arin.net/policy/proposal_archive.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-2: Directory Services Overhaul Author: Leo Bicknell Policy term: permanent Policy statement: Replace all of section three with the following rewrite. 3 Directory Services 3.1 ARIN Directory Services Databases The ARIN Public Information Database (APID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed public information and decided to publish. The ARIN Confidential Information Database (ACID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed is confidential information that should be kept under a strict privacy policy. 3.2 Directory Information Made Public ARIN shall publish verified contact information and the resource(s) allocated (including identification for that allocation, like date of allocation or other information identified by ARIN) in the APID in the following cases: - All resources delegated by ARIN. - If allowed by the parent delegation, and requested by the contact listed with the parent, a subdelegation of a resource. ARIN shall insure all contact information in the APID is verified from time to time and is correct to the best of ARIN's ability. ARIN staff shall maintain verification criteria and post it on the ARIN web site. 3.2.1 Non-Responsive Contacts If ARIN is unable to verify contact information via the normal verification procedure ARIN shall attempt to notify the parent of the resource to have the information updated. If there is no parent, or if the data is not corrected in a reasonable amount of time the resource shall be SUSPENDED. Once the resource is suspended ARIN shall make one more request of all contacts listed with the resource and the parent resource (if available), and if no response is received in a reasonable amount of time the resource shall be reclaimed. Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the contact verification procedure for that contact immediately. If a response is received, ARIN should document that a problem occurred, and the response from the resource holder. Offenders who fail to respond to third parties more than 4 times per month for three months may have their resources reclaimed at the discretion of ARIN staff. If a third party submits reports of the inability to make contact that are subsequently disproven, ARIN may choose to ignore reports from specific companies, people, e-mail addresses, or any other classification means as appropriate. The ARIN staff shall publish the time thresholds and procedural details to implement this policy on the ARIN web site. If a resource is reclaimed under no circumstances shall the holder of that resource be entitled to a refund of any fees. 3.3 Data Distribution 3.3.1 Methods of Access ARIN shall publish the APID in the following methods using industry standard practices: - Via the WHOIS protocol. - Via a query form accessible via the HTTP protocol. - Via FTP to users who complete the bulk data form. - Via CDROM to users who complete the bulk data form. - Via the RWHOIS protocol. 3.3.1.1 Outside Sources ARIN may refer a query to a outside source (for instance via RWHOIS or HTTP redirect). Outside sources must: 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. 2 Meet the requirements in section 3.3.3. 3 Support the applications in section 3.3.1. 4 Prohibit the applications in section 3.3.2. 3.3.2 Acceptable Usage Policy All data provided shall be subject to an AUP. The AUP shall be written by ARIN staff and legal and posted on the ARIN website. ARIN may require a signed copy of the AUP before providing bulk data. 3.3.3 Requirements for Internet Accessible Services For any method of access which is provided in real time via the Internet the following requirements must be met: * The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. * The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. * The distributed information service must return current information. 3.4 Distribution of the ARIN Public Information Database 3.4.1 Supported Uses ARIN shall make the APID available for the following uses (supported uses): 1 ARIN's use in implementing ARIN policies and other business. 2 Community verification, allowing members of the community to confirm the proper users of the various resources ARIN controls. 3 Statistic gathering by ARIN and third parties on resource utilization. 4 As a contact database to facilitate communication with the person or entity responsible for a particular resource. 3.4.2 Prohibited Uses ARIN prohibits the use of the APID for the following uses: 1 Sending any unsolicited commercial correspondence advertising a product or service to any address (physical or electronic) listed in the APID. 2 Using data in the APID to facilitate violating any state, federal, or local law. 3.4.3 Other Uses ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list. 3.5 Distribution of the ARIN Confidential Information Database ARIN Staff shall use industry standard procedures to prevent the distribution of any data in the ARIN Confidential Information Database. 3.6 Implementation Details ARIN Staff shall document all implementation specific details for directory services in a single document available on the web site. The document must contain, but is not limited to: - Database field definitions. - Update procedures. - Templates. - Points of contact. - Copies of the AUP. - Verification procedures. 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. Section 4.2.3.7.4: Replace with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation. Section 4.2.3.7.6: Strike. 8. Rationale: Various proposals affecting directory services have come and gone in the last 5 years leaving the policy affecting directory services fragemented. Also during that time deployments and laws have changed. Several large DSL and cable providers now offer subnets to residential customers that may require them to be registered with ARIN. Several laws have been passed that may restrict the personal information that can be published. This proposal attempts to provide a unified policy that is easier to understand, and is updated to deal with these new issues. Timetable for implementation: 6-18 months, depending on staff impact. From kloch at hotnic.net Mon Mar 14 19:08:38 2005 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 14 Mar 2005 19:08:38 -0500 Subject: [ppml] /48 vs /32 micro allocations Message-ID: <42362786.90008@hotnic.net> Is there any benefit at all to allocating a /48 to name servers and exchange points instead of a /32? There is no shortage of /32's, with 536 million of them in 2000::/3. Even when you consider /29's being reserved for each ISP /32 there is no chance of running out of space by allocating /32's for any direct allocation, and "no chance" is understaded by several orders of magnitude. Yet there may be a big problem with RIR allocated prefixes longer than /32. Many operators are now only filtering prefixes longer than /48. I suspect that the RIR allocated /48's are contributing to this, regardless of how trivial it is to filter around them. An interesting example of this is /48 allocations for exchange points. These are explicitly not supposed to be routable yet they are in many networks. RIR filter suggestions do not seem to matter, but allocation sizes do. In other words, The minimum allocation from any RIR may eventually determine the Minimum Routable Unit (MRU) across the board. Market forces, technology limitations and end site assignment sizes are also factors but there is a real risk that RIR allocations will result in a smaller MRU than these factors otherwise would. I'm not saying that using /32's for special allocations will prevent a /48 MRU, but it is irresponsible to ignore the effects that these /48 allocations may have. So, to be on the safe and responsible side, should ARIN set a minimum allocation size of /32 for *any* direct allocation regardless of type? and, Should existing /48's be replaced with /32's to eliminate any RIR issued /48's in the global table? For the RIR /48 delegates on this list, how do you feel about renumbering? Kevin Loch From bmanning at vacation.karoshi.com Mon Mar 14 19:38:07 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 15 Mar 2005 00:38:07 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <42362786.90008@hotnic.net> References: <42362786.90008@hotnic.net> Message-ID: <20050315003807.GA22022@vacation.karoshi.com.> On Mon, Mar 14, 2005 at 07:08:38PM -0500, Kevin Loch wrote: > Is there any benefit at all to allocating a /48 to name servers and > exchange points instead of a /32? yes. > There is no shortage of /32's, with 536 million of them in 2000::/3. > Even when you consider /29's being reserved for each ISP /32 there is > no chance of running out of space by allocating /32's for any > direct allocation, and "no chance" is understaded by several orders of > magnitude. it does -seem- pretty large, doesn't it? > Yet there may be a big problem with RIR allocated prefixes longer > than /32. Many operators are now only filtering prefixes longer than > /48. I suspect that the RIR allocated /48's are contributing to this, > regardless of how trivial it is to filter around them. ISPs are free to filter on any boundar(y/ies) that they see fit to. Many (most?) filter on published RIR allocation boundaries, some based on IETF recommendations, and SOME based on customer demand. > An interesting example of this is /48 allocations for exchange points. > These are explicitly not supposed to be routable yet they are in many > networks. RIR filter suggestions do not seem to matter, but allocation > sizes do. Sort of. No RIR delegation is explicitly routable. Routability is not an attribute of RIR delegations. Routability is up to the respective ISP's. > In other words, The minimum allocation from any RIR may eventually > determine the Minimum Routable Unit (MRU) across the board. Not in my lifetime. :) > Market forces, technology limitations and end site assignment sizes are > also factors but there is a real risk that RIR allocations will result > in a smaller MRU than these factors otherwise would. I'm not saying > that using /32's for special allocations will prevent a /48 MRU, but it > is irresponsible to ignore the effects that these /48 allocations may > have. There are other effects associated w/ large delegations that remain sparsely populated. > So, to be on the safe and responsible side, should ARIN set a minimum > allocation size of /32 for *any* direct allocation regardless of type? That would be bad - on many different levels. > > and, > > Should existing /48's be replaced with /32's to eliminate any > RIR issued /48's in the global table? For the RIR /48 delegates > on this list, how do you feel about renumbering? > > Kevin Loch From kloch at hotnic.net Mon Mar 14 21:54:43 2005 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 14 Mar 2005 21:54:43 -0500 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050315003807.GA22022@vacation.karoshi.com.> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> Message-ID: <42364E73.60509@hotnic.net> bmanning at vacation.karoshi.com wrote: > On Mon, Mar 14, 2005 at 07:08:38PM -0500, Kevin Loch wrote: > >> Is there any benefit at all to allocating a /48 to name servers and >> exchange points instead of a /32? > > yes. For example? > >> There is no shortage of /32's, with 536 million of them in 2000::/3. > > > it does -seem- pretty large, doesn't it? I would argue that it is too large. Do you really want 67 million possible routes? Keep in mind that this is for "Aggregatable Global Unicast Address Format". It's very likely that if we relly did want 67 millions routes we would be using a different address format outside of 2000::/3 since 67 million does not seem congruent with "Aggregatable". > ISPs are free to filter on any boundar(y/ies) that they > see fit to. Many (most?) filter on published RIR allocation > boundaries, some based on IETF recommendations, and SOME > based on customer demand. I agree but In IPv6 right now most appear to be filtering /49 and longer. Is the micro allocation policy having an affect on this? This is not about how you or I filter on our own network, it's about the de-facto minimums that result from RIR policy, intentional or not. >> RIR filter suggestions do not seem to matter, but allocation >> sizes do. > > > Sort of. No RIR delegation is explicitly routable. Routability > is not an attribute of RIR delegations. Routability is up to > the respective ISP's. And most ISP's eventually filter to the lowest common denominator, and that determines the de-facto MRU. RIR delegations have a substantial effect on that. >> Market forces, technology limitations and end site assignment sizes are >> also factors but there is a real risk that RIR allocations will result >> in a smaller MRU than these factors otherwise would. I'm not saying >> that using /32's for special allocations will prevent a /48 MRU, but it >> is irresponsible to ignore the effects that these /48 allocations may >> have. > > There are other effects associated w/ large delegations that > remain sparsely populated. Are there any allocations in IPv6 that will not be sparseley populated? Even in bits 0-48 I would argue that most will remain sparsely populated. Only 56% of IPv6 allocations are even announced right now. > >> So, to be on the safe and responsible side, should ARIN set a minimum >> allocation size of /32 for *any* direct allocation regardless of type? > > That would be bad - on many different levels. Please explain. Even if consensus is that this is a bad idea we should have the reasons clearly stated. Kevin Loch From Ed.Lewis at neustar.biz Mon Mar 14 22:07:26 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 14 Mar 2005 22:07:26 -0500 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul In-Reply-To: <422F66F3.3090606@arin.net> References: <422F66F3.3090606@arin.net> Message-ID: At 16:13 -0500 3/9/05, Member Services wrote: >ARIN welcomes feedback and discussion about this policy proposal in the >weeks leading to the ARIN Public Policy Meeting in Orlando, Florida, >scheduled for April 18-20, 2005. ... > >Policy Proposal 2005-2: Directory Services Overhaul >3 Directory Services > > 3.3 Data Distribution > > 3.3.1 Methods of Access > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. I'd like to see IRIS on this list, or at least a plan to adopt it. (http://ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-10.txt) Is there any interest in retiring RWhoIs? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. From bmanning at vacation.karoshi.com Tue Mar 15 00:03:24 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 15 Mar 2005 05:03:24 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <42364E73.60509@hotnic.net> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> Message-ID: <20050315050324.GA23032@vacation.karoshi.com.> On Mon, Mar 14, 2005 at 09:54:43PM -0500, Kevin Loch wrote: > bmanning at vacation.karoshi.com wrote: > > > On Mon, Mar 14, 2005 at 07:08:38PM -0500, Kevin Loch wrote: > > > >> Is there any benefit at all to allocating a /48 to name servers and > >> exchange points instead of a /32? > > > > yes. > > For example? let me answer with some questions. how much of your ipv4 /20 that is your minimal delegation from ARIN is populated? 5 hosts? 20 hosts? 150 or even 300? how many addresses are you advertizing reachability to that have no hosts/applications active? do you consider this a problem? if not, why not? > >> There is no shortage of /32's, with 536 million of them in 2000::/3. > > > > it does -seem- pretty large, doesn't it? > > I would argue that it is too large. Do you really want > 67 million possible routes? Keep in mind that this > is for "Aggregatable Global Unicast Address Format". > It's very likely that if we relly did want 67 millions routes > we would be using a different address format outside of 2000::/3 > since 67 million does not seem congruent with "Aggregatable". aggregatable is i n the eye of the beholder. IPv4 looked pretty huge back in the day. trying to equate addressing potential over the next 20-30 years with todays routing techniques/technologies is short-sighted at best. and yes, i could conceive of wanting/needing more than 67 million routes - back when we were first considering CIDR, i postulated to the BGP experts of the day that we should plan for host routes in IPv4... which is exactly where we are now with IPv6. different address formats woudl be useful, but the inertia in the IETF is considerable. so we live with what we have. IMHO, the 64bit boundary is silly and a number of proposals treat the lower 64 as cidr-able space. > > ISPs are free to filter on any boundar(y/ies) that they > > see fit to. Many (most?) filter on published RIR allocation > > boundaries, some based on IETF recommendations, and SOME > > based on customer demand. > > I agree but In IPv6 right now most appear to be filtering /49 and > longer. Is the micro allocation policy having an affect on this? > This is not about how you or I filter on our own network, it's about > the de-facto minimums that result from RIR policy, intentional > or not. i'd like to see actual data to back these assertions. at the end of the day i don't really care what "most" people are doing, i care that my peers and my transit providers carry my routes as I instruct them. > >> RIR filter suggestions do not seem to matter, but allocation > >> sizes do. > > > > Sort of. No RIR delegation is explicitly routable. Routability > > is not an attribute of RIR delegations. Routability is up to > > the respective ISP's. > > And most ISP's eventually filter to the lowest common denominator, > and that determines the de-facto MRU. RIR delegations have a > substantial effect on that. again, i really don't care about most ISPs, just the folks i peer with and those i pay for transit. those agreements set the MRU for the prefixes i care about. those i don't, i'll drop from my edge routers if i'm having troubles. why should you know or care about what i do in my network and with /between my peers. if you want to have an opinion that matters, set up peering with me and we can talk about what prefixes are of interest to you from me and what prefixes i wish to hear from you. end of the day it is the routing slots in the routers that count... not some random ISP in Norway. > >> Market forces, technology limitations and end site assignment sizes are > >> also factors but there is a real risk that RIR allocations will result > >> in a smaller MRU than these factors otherwise would. I'm not saying > >> that using /32's for special allocations will prevent a /48 MRU, but it > >> is irresponsible to ignore the effects that these /48 allocations may > >> have. > > > > There are other effects associated w/ large delegations that > > remain sparsely populated. > > Are there any allocations in IPv6 that will not be sparseley populated? > Even in bits 0-48 I would argue that most will remain sparsely > populated. Only 56% of IPv6 allocations are even announced right now. Yes... but you may never see them since you insist on filtering at a much higher degree of aggregation than is desired by the prefix injector... you may even have quasi-rational arguments about ` hardware/software limitations in those legacy routing protocols that everyone uses... :) (anyone willing to listen to some /96 or /112 entries? didn't think so... :) > >> So, to be on the safe and responsible side, should ARIN set a minimum > >> allocation size of /32 for *any* direct allocation regardless of type? > > > > That would be bad - on many different levels. > > Please explain. Even if consensus is that this is a bad idea we should > have the reasons clearly stated. please answer the questions I posed above and then we can continue this conversation. > > Kevin Loch From kloch at hotnic.net Tue Mar 15 02:07:40 2005 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 15 Mar 2005 02:07:40 -0500 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050315050324.GA23032@vacation.karoshi.com.> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> Message-ID: <423689BC.40901@hotnic.net> bmanning at vacation.karoshi.com wrote: > let me answer with some questions. No, please don't. Especially questions about IPv4 utilization in a discussion about IPv6 policy. Trying to blindly map IPv4 policy into IPv6 no sense at all. *Especially* questions about advertising reachability to hosts that aren't listening. That can't possibly be relevant to IPv6. C'mon Bill, If there are benefits to /48 vs /32 allocations state them plainly. I'm not doubting that there are, I just can't think of any myself, and so far you haven't presented any. > i'd like to see actual data to back these assertions. The routes are in plain view. There are several looking glasses that show /48's transiting many networks. That's not to say that everyone is, but enough are that it is a worrying trend. > (anyone willing to listen to some /96 or /112 entries? didn't > think so... :) I sure hope not! :) Then again, I would hope that nobody would carry deaggregated /48's either! Kevin Loch From owen at delong.com Tue Mar 15 02:52:05 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Mar 2005 23:52:05 -0800 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <423689BC.40901@hotnic.net> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> Message-ID: <2147483647.1110844324@[172.17.1.152]> I can think of at least one... The greater the sparsity of address utilization, the easier it is to hijack portions of the address space. That, in and of itself, to me seems like a good reason NOT to pursue a sparse allocation policy. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Tue Mar 15 05:16:15 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 15 Mar 2005 10:16:15 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <2147483647.1110844324@[172.17.1.152]> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> <2147483647.1110844324@[172.17.1.152]> Message-ID: <20050315101615.GB24177@vacation.karoshi.com.> On Mon, Mar 14, 2005 at 11:52:05PM -0800, Owen DeLong wrote: > I can think of at least one... > The greater the sparsity of address utilization, the easier > it is to hijack portions of the address space. That, in and of itself, > to me seems like a good reason NOT to pursue a sparse allocation policy. > > Owen > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. thanks Owen. one down, two to go. any other takers? --bill From bmanning at vacation.karoshi.com Tue Mar 15 05:50:25 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 15 Mar 2005 10:50:25 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <423689BC.40901@hotnic.net> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> Message-ID: <20050315105025.GD24177@vacation.karoshi.com.> On Tue, Mar 15, 2005 at 02:07:40AM -0500, Kevin Loch wrote: > bmanning at vacation.karoshi.com wrote: > > > let me answer with some questions. > > No, please don't. Especially questions about IPv4 > utilization in a discussion about IPv6 policy. Trying to > blindly map IPv4 policy into IPv6 no sense at all. not being blind at all. learning from history. if you can't see that IPv4 is fundamentally identical to IPv6, then we are not on common ground and will talk past each other. > *Especially* questions about advertising reachability > to hosts that aren't listening. That can't possibly be > relevant to IPv6. ok... your universe. > C'mon Bill, If there are benefits to /48 vs /32 allocations > state them plainly. I'm not doubting that there are, I > just can't think of any myself, and so far you haven't > presented any. there are benefits to /48 delegations, to /32 delegations, to /96 delegations, and /112 delegations. The delegation, IMHO, should be the closest fit to the actual requirement. presenting more "shadow" space than is being used is an atractive target for abuse. I was hoping you'd at least -TRY- to work past your fixations on current hardware/routing software limitations and take the longer view, but you seem to want affirmation of your existing ideas. > > i'd like to see actual data to back these assertions. > > The routes are in plain view. There are several looking glasses > that show /48's transiting many networks. That's not to say > that everyone is, but enough are that it is a worrying trend. plain view to -whom-? from my perspective, i see /48s as well as some longer prefixes. you think I should only see /32s? and if so, why do you think that? > > (anyone willing to listen to some /96 or /112 entries? didn't > > think so... :) > I sure hope not! :) > Then again, I would hope that nobody would carry deaggregated /48's > either! i see, we are talking past each other. Well then. To conserve routing table slots in 2005 era routers, with 1990's based EGP protocols, it should be incumbent on the RIR's, who have ZERO to say about how ISPs perform routing to only release IPv6 address space in /32 blocks in the (vain) hope that: ) there will be enough IPv6 space to last for the next 30 years ) no one would -ever- dare treat IPv6 space as anything useful in less than /32 chunks ) no harm will insue if folks advertise routes to space that has no endsystem attached. ) we understand all there is to know about how applications and services will develop over the next two decades to presume a steady, consistant "burn-rate" of space. ) no fundamental technological changes will occur on our watch and if it does, it can be solved by new talent. ) that the IETF leaves routing development alone. If this is the basis of your argument, then i'll agree that its a good proposal, if all my points are accepted and ISPs agree to never announce anything smaller than what there RIR gives them. Of course the IETF had better start in -RIGHT NOW- to work on the next generation IP. for IPv6 will be dead. As usual, YMMV. > > Kevin Loch --bill From ppml at rs.seastrom.com Tue Mar 15 07:40:56 2005 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Tue, 15 Mar 2005 07:40:56 -0500 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050315101615.GB24177@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Tue, 15 Mar 2005 10:16:15 +0000") References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> <2147483647.1110844324@[172.17.1.152]> <20050315101615.GB24177@vacation.karoshi.com.> Message-ID: <87ll8p13qf.fsf@valhalla.seastrom.com> bmanning at vacation.karoshi.com writes: > Thanks Owen. one down, two to go. any other takers? Sure, I'll bite... How about: History is rife with examples (species hunted to extinction, rivers polluted beyond the point at which they would sustain marine life, regional deforestation) where lax stewardship and out-and-out profligate waste came about because of the contemporaneous perception among stakeholders that a particular resource was inexhaustible. I fear we are headed the same way with v6. Those who do not understand history are doomed to repeat it. ---Rob From billd at cait.wustl.edu Tue Mar 15 08:05:41 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 15 Mar 2005 07:05:41 -0600 Subject: [ppml] /48 vs /32 micro allocations Message-ID: Hear wild cheering and applause from this corner.... Bill Darte > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Robert E.Seastrom > Sent: Tuesday, March 15, 2005 6:41 AM > To: bmanning at vacation.karoshi.com > Cc: Owen DeLong; Kevin Loch; ppml at arin.net > Subject: Re: [ppml] /48 vs /32 micro allocations > > > > bmanning at vacation.karoshi.com writes: > > > Thanks Owen. one down, two to go. any other takers? > > Sure, I'll bite... How about: > > History is rife with examples (species hunted to extinction, rivers > polluted beyond the point at which they would sustain marine life, > regional deforestation) where lax stewardship and out-and-out > profligate waste came about because of the contemporaneous > perception > among stakeholders that a particular resource was inexhaustible. > > I fear we are headed the same way with v6. Those who do not > understand history are doomed to repeat it. > > ---Rob > From Michael.Dillon at radianz.com Tue Mar 15 08:15:32 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 15 Mar 2005 13:15:32 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <87ll8p13qf.fsf@valhalla.seastrom.com> Message-ID: > History is rife with examples (species hunted to extinction, rivers > polluted beyond the point at which they would sustain marine life, > regional deforestation) where lax stewardship and out-and-out > profligate waste came about because of the contemporaneous perception > among stakeholders that a particular resource was inexhaustible. > > I fear we are headed the same way with v6. Those who do not > understand history are doomed to repeat it. IPv6 is different. Like IPv4, IPv6 is an imaginary resource. It is not real. IPv4 and v6 were created by the human imagination and if IPv6 addresses ever come close to exhaustion, a newer IP can be created from the same source to replace IPv6. So the real question is not, "Will IPv6 ever run out?". It is, "Does our policy provide enough early warning of exhaustion of IPv6 addresses so that a replacement for IPv6 can be dreamt up and deployed?". I think that a world in which the RIRs only allocate /32 and shorter prefixes could easily answer "Yes" to that second question. If IPv6 can be made to last to the end of the 21st century, then that is good enought. Perhaps the IANA and the RIRs should show some sort of runout plan up to the year 2100 based on the best current estimates of technology deployment. We can update such plans every year or so, and monitor how accurate our initial assumptions were. This is an area where we should not be making policy without scenario analysis and actual hard numbers calculated correctly based on various different sets of initial assumptions. There is currently too much guesswork and ego that goes into policy making. In the real world, policies evolve, they are not engineered in advance to be perfect. The fact that ARIN, as an organization, is dying, doesn't really help matters. The Internet continues to grow larger every year and yet the set of people interested in dealing with these issues seems to grow smaller. The same gang of old boys makes the same tired arguments. They may be right, they may be wrong, but without a real test of those arguments in a real broad-based discussion, we'll never know whose argument is the most correct. --Michael Dillon From randy at psg.com Tue Mar 15 08:18:59 2005 From: randy at psg.com (Randy Bush) Date: Tue, 15 Mar 2005 05:18:59 -0800 Subject: [ppml] /48 vs /32 micro allocations References: <87ll8p13qf.fsf@valhalla.seastrom.com> Message-ID: <16950.57539.888231.32737@roam.psg.com> > This is an area where we should not be making policy without > scenario analysis and actual hard numbers calculated correctly > based on various different sets of initial assumptions. talk is cheap. send analyses and hard numbers. randy From billd at cait.wustl.edu Tue Mar 15 08:31:38 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 15 Mar 2005 07:31:38 -0600 Subject: [ppml] /48 vs /32 micro allocations Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Tuesday, March 15, 2005 7:16 AM > To: ppml at arin.net > Subject: Re: [ppml] /48 vs /32 micro allocations > > > > History is rife with examples (species hunted to > extinction, rivers > > polluted beyond the point at which they would sustain > marine life, > > regional deforestation) where lax stewardship and out-and-out > > profligate waste came about because of the > contemporaneous perception > > among stakeholders that a particular resource was inexhaustible. > > > > I fear we are headed the same way with v6. Those who do not > > understand history are doomed to repeat it. > > IPv6 is different. IPv6 IS different. The difference is that it has the potential to 'solidify' the operations of the Internet and to 'cement' itself in place FOREVER. The ULTIMATE legacy system. Witness the difficulty in migrating to v6 from the legacy v4. If v4 hadn't been so good and extensible, then it would have petered out long ago, but once a critical mass of users and system deployments existed and this exacerabted by economic systems being built upon that foundation, it is now nearly impossible to migrate let alone replace. Only the fact that we run the risk of exhaustion of space and new arenas of communication still abound will likely FORCE the introduction and eventual dominance of v6. I suggest that v6 will never be replaced because migration will simply be to risky and costly....so, my advice is get it right and do it well (conservation) now and then let it ride. Bill Darte From paul at vix.com Tue Mar 15 09:17:48 2005 From: paul at vix.com (Paul Vixie) Date: Tue, 15 Mar 2005 14:17:48 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: Message from Owen DeLong of "Mon, 14 Mar 2005 23:52:05 PST." <2147483647.1110844324@[172.17.1.152]> Message-ID: <20050315141748.6AD7C13E3F@sa.vix.com> > I can think of at least one... > The greater the sparsity of address utilization, the easier > it is to hijack portions of the address space. That, in and of itself, > to me seems like a good reason NOT to pursue a sparse allocation policy. this is nonsequitur. ipv4 is a lot smaller and denser than ipv6, and yet spammers routinely advertise ipv4 blocks, spam from them for a few minutes, and then withdraw the route before most folks get around to traceroute'ing. we're going to need some form of end to end bgp authentication no matter whether we move to ipv6 or not, or do so with sparse allocations or dense. From andrew.dul at quark.net Tue Mar 15 11:02:13 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 15 Mar 2005 16:02:13 +0000 Subject: [ppml] /48 vs /32 micro allocations Message-ID: <20050315160213.10707.qmail@hoster908.com> -------Original Message------- > From: "Owen DeLong" > Subject: Re: [ppml] /48 vs /32 micro allocations > Sent: 14 Mar 2005 23:52:05 > > I can think of at least one... > The greater the sparsity of address utilization, the easier > it is to hijack portions of the address space. That, in and of itself, > to me seems like a good reason NOT to pursue a sparse allocation policy. > > Owen > -- True, however... I'm hoping that the IETF rpsec working group is able to come up with a solution to authenticate & authorize BGP announcements. Having those in place would make hijacking more difficult. Andrew From kloch at hotnic.net Tue Mar 15 12:15:51 2005 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 15 Mar 2005 12:15:51 -0500 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050315105025.GD24177@vacation.karoshi.com.> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> <20050315105025.GD24177@vacation.karoshi.com.> Message-ID: <42371847.9040002@hotnic.net> bmanning at vacation.karoshi.com wrote: > ) there will be enough IPv6 space to last for the next > 30 years Increasing the minimum allocation size for a few hundred micro allocations to 1 / 4billionth of the total address space is not wasteful. If you are concerned with relative waste you might want to look at the HD ratio of 0.8 (!) that is resulting in /19 allocations (that's 8192 /32's right there). > ) no one would -ever- dare treat IPv6 space as anything > useful in less than /32 chunks This isn't about /33-/47 it's about /48 (see below). > ) no harm will insue if folks advertise routes to space > that has no endsystem attached. Others have addressed authentication but I think maintaining the MRU above /48 would help. The larger prefix an abuser has to announce the more likely it is to be noticed. The presense of end systems doesn't help at all in IPv6 (host density is impossibly low) though I can see problems if the micro allocation is larger than the effective MRU (abuser announces more specifics). There's nothing to stop you from announcing the more specifics yourself, at least then the larger RIR allocation won't encourage looser filters. If /32 micro allocations are so harmful, then why is that the policy of the other RIR's? K, I and M root all have /32's allocated. > ) we understand all there is to know about how applications > and services will develop over the next two decades to > presume a steady, consistant "burn-rate" of space. Right now we are talking about a few hundred micro allocations. When (not if) we start talking about end site allocations we could consider smaller sizes than /32 but even then not /48 unless the intent is that all /48's (directly assigned or not) be globally routable. > ) no fundamental technological changes will occur on our > watch and if it does, it can be solved by new talent. > ) that the IETF leaves routing development alone. Allocation policy is not set in stone. RIR's can and do change policy as conditions change. What is the right thing to do right now? > > If this is the basis of your argument, then i'll agree that its > a good proposal, if all my points are accepted and ISPs agree to > never announce anything smaller than what there RIR gives them. Of course they will. I'm not suggesting we could maintain an MRU of /32. With the quantumn nature of current address quidelines, there is all the difference in the world between an MRU of /48 and /47. Would you agree that: - There is a benefit to increasing micro allocations above /48 WRT MRU - There is some value between /32 and /47 where the benefits outweigh the risks? Considering that allocation policy can always be revised in the future. (we're only talking about critical infrastructure at this point). Kevin From bmanning at vacation.karoshi.com Tue Mar 15 12:28:11 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 15 Mar 2005 17:28:11 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050315160213.10707.qmail@hoster908.com> References: <20050315160213.10707.qmail@hoster908.com> Message-ID: <20050315172811.GA25597@vacation.karoshi.com.> On Tue, Mar 15, 2005 at 04:02:13PM +0000, Andrew Dul wrote: > -------Original Message------- > > From: "Owen DeLong" > > Subject: Re: [ppml] /48 vs /32 micro allocations > > Sent: 14 Mar 2005 23:52:05 > > > > I can think of at least one... > > The greater the sparsity of address utilization, the easier > > it is to hijack portions of the address space. That, in and of itself, > > to me seems like a good reason NOT to pursue a sparse allocation policy. > > > > Owen > > -- > > True, however... I'm hoping that the IETF rpsec working group is able to come up with a solution to authenticate & authorize BGP announcements. Having those in place would make hijacking more difficult. Annie Lenox did a fine cover of "Train in Vain"... I hope that your hope will not be in vain... rpsec has -miles- to go before its operationaly feasable. IMHO of course. --bill > > Andrew From jimmy.kyriannis at nyu.edu Tue Mar 15 12:43:00 2005 From: jimmy.kyriannis at nyu.edu (Jimmy Kyriannis) Date: Tue, 15 Mar 2005 12:43:00 -0500 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050315141748.6AD7C13E3F@sa.vix.com> References: <20050315141748.6AD7C13E3F@sa.vix.com> Message-ID: <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> Yes. One might also view that the sparsity of routing entries would constitute an environment in which would be "harder to get away with" hijacking, since filtering longer length prefixes creates a population of much more visible/impactful prefix targets to hijack. In that vein, if a longer prefix were to "sneak into" the routing tables, it would also be rather visible. Either way, IMO, the fundamental problem of route hijacking won't be solved here, since it doesn't lie within the filtering of routes, but rather hardening the protocols which make this possible for disreputable or unaware providers. Jimmy At 09:17 AM 3/15/2005, Paul Vixie wrote: > > I can think of at least one... > > The greater the sparsity of address utilization, the easier > > it is to hijack portions of the address space. That, in and of itself, > > to me seems like a good reason NOT to pursue a sparse allocation policy. > >this is nonsequitur. ipv4 is a lot smaller and denser than ipv6, and yet >spammers routinely advertise ipv4 blocks, spam from them for a few minutes, >and then withdraw the route before most folks get around to traceroute'ing. > >we're going to need some form of end to end bgp authentication no matter >whether we move to ipv6 or not, or do so with sparse allocations or dense. From bmanning at vacation.karoshi.com Tue Mar 15 12:57:53 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 15 Mar 2005 17:57:53 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <42371847.9040002@hotnic.net> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> <20050315105025.GD24177@vacation.karoshi.com.> <42371847.9040002@hotnic.net> Message-ID: <20050315175753.GB25597@vacation.karoshi.com.> > Others have addressed authentication but I think maintaining the MRU > above /48 would help. crux of the issue... the "MRU" you continually refer to is strictly between you and your peers. It has or should have no relationship to the "MRU" between me and my peers. RIR delegation policy may impact how -YOU- set your own routing policies and it -MIGHT- impact mine... but there can't be any inference on RIR delegation/assignment policy wrt routing.... since RIRs don't route. > Would you agree that: > > - There is a benefit to increasing micro allocations above /48 WRT MRU in some twisted universe... sure - but not very much so in my particular circle of hell. > - There is some value between /32 and /47 where the benefits outweigh > the risks? yes... but those same arguments hold for delegations between /96 and /112 .... > > Considering that allocation policy can always be revised in the future. > (we're only talking about critical infrastructure at this point). policies can be revised. recovering old delegations is difficult and painful. and for that matter, what IS critical infrastructure anyway? if its a single IP address, then critical infrastructure should be delegated a /127 ... or at most a /126. and you should be happy to carry it. as the small number of exceptions to your own MRU that otherwise forbids anything (else) greater than a /32. Keep your hands off my MRU thank you very much. And I'll reciprocate and keep my hands off your MRU. Feel free to set what ever policy you desire on your border. And remember, there is no such thing as the "Global" Internet or the one, true, routing table. It all depends on when and where you look. Expunge this fiction of a global routing table from your mind and you will be much happier. Focus on getting & delivering the bits your customer(s) want/need/are willing to pay for. The rest of the folks in the loose mesh that passes for the Internet will thank you for tending that part of the garden. > Kevin --bill (still being grumpy - it was a long night) From owen at delong.com Tue Mar 15 14:33:24 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Mar 2005 11:33:24 -0800 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <42371847.9040002@hotnic.net> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> <20050315105025.GD24177@vacation.karoshi.com.> <42371847.9040002@hotnic.net> Message-ID: <2147483647.1110886404@imac-en0.delong.sj.ca.us> --On Tuesday, March 15, 2005 12:15 PM -0500 Kevin Loch wrote: > bmanning at vacation.karoshi.com wrote: >> ) there will be enough IPv6 space to last for the next >> 30 years > > Increasing the minimum allocation size for a few hundred micro > allocations to 1 / 4billionth of the total address space is not > wasteful. If you are concerned with relative waste you might want > to look at the HD ratio of 0.8 (!) that is resulting in /19 allocations > (that's 8192 /32's right there). > Do you have any evidence to support that the number of microallocations would remain so small? I tend to expect that it would not. >> ) no one would -ever- dare treat IPv6 space as anything >> useful in less than /32 chunks > > This isn't about /33-/47 it's about /48 (see below). > In that case, why aren't you asking to shift /48s to /47s instead of /32s? What's the point of addressing /48s without addressing /33-/47 if you're going to move /48s all the way to /32? That seems very illogical to me. >> ) no harm will insue if folks advertise routes to space >> that has no endsystem attached. > > Others have addressed authentication but I think maintaining the MRU > above /48 would help. The larger prefix an abuser has to announce the > more likely it is to be noticed. The presence of end systems doesn't > help at all in IPv6 (host density is impossibly low) though I can see > problems if the micro allocation is larger than the effective MRU > (abuser announces more specifics). There's nothing to stop you from > announcing the more specifics yourself, at least then the larger RIR > allocation won't encourage looser filters. If /32 micro allocations are > so harmful, then why is that the policy of the other RIR's? K, I and M > root all have /32's allocated. > If you advertise the more specifics yourself, then, you have guaranteed the problem you were claiming this was an attempt to avoid. You can't have your cake and eat it too. Agreed that IPv6 is hopelessly broken when it comes to allocation density. However, making it 65,536 times less dense will not improve the situation. >> ) we understand all there is to know about how applications >> and services will develop over the next two decades to >> presume a steady, consistant "burn-rate" of space. > > Right now we are talking about a few hundred micro allocations. When > (not if) we start talking about end site allocations we could consider > smaller sizes than /32 but even then not /48 unless the intent is that > all /48's (directly assigned or not) be globally routable. > There is already an end-site policy proposal in ARIN. Thus, we _ARE_ already talking about end-site allocations. Next. >> ) no fundamental technological changes will occur on our >> watch and if it does, it can be solved by new talent. >> ) that the IETF leaves routing development alone. > > Allocation policy is not set in stone. RIR's can and do change policy > as conditions change. What is the right thing to do right now? > Ignore IPv6 as it isn't quite ready for the general public yet. A number of problems IPv6 needs to solve to be really worth migration are not yet solved: Address portability or completely easy renumbering + Including ACLs * ACLs within the organization * Related ACLs outside the organization which may or may not be known to the organization + Including statically configured end hosts etc. How to handle a routing table of the size likely when IPv6 does become popular and NAT is no longer an issue. Mobile IP Route Authentication/Authorization Prefix Authentication/Authorization To name but a few. >> >> If this is the basis of your argument, then i'll agree that its >> a good proposal, if all my points are accepted and ISPs agree to >> never announce anything smaller than what there RIR gives them. > > Of course they will. I'm not suggesting we could maintain an MRU of > /32. With the quantumn nature of current address quidelines, there is > all the difference in the world between an MRU of /48 and /47. > ISPs rarely agree on anything, and, the MRU is no exception. ISPs do one of two things: 1. What their main techie thinks is the right thing because he has the ability to set the policy on the routers and management/sales haven't noticed yet. or 2. What management/sales have dictated will be the policy on the routers because they see revenue behind it. If there's revenue in advertising somebody's more specific, it will get advertised. > Would you agree that: > > - There is a benefit to increasing micro allocations above /48 WRT MRU No. > - There is some value between /32 and /47 where the benefits outweigh > the risks? > No. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Mar 15 14:35:43 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Mar 2005 11:35:43 -0800 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> References: <20050315141748.6AD7C13E3F@sa.vix.com> <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> Message-ID: <2147483647.1110886543@imac-en0.delong.sj.ca.us> I agree this isn't a solution to hijacking. I still believe that issuing /32s to people who would get /48s under current policy will exacerbate the problem, not improve it. I propose we avoid exacerbating the hijacking problem. Owen --On Tuesday, March 15, 2005 12:43 PM -0500 Jimmy Kyriannis wrote: > > Yes. One might also view that the sparsity of routing entries would > constitute an environment in which would be "harder to get away with" > hijacking, since filtering longer length prefixes creates a population of > much more visible/impactful prefix targets to hijack. In that vein, if a > longer prefix were to "sneak into" the routing tables, it would also be > rather visible. > > Either way, IMO, the fundamental problem of route hijacking won't be > solved here, since it doesn't lie within the filtering of routes, but > rather hardening the protocols which make this possible for disreputable > or unaware providers. > > > Jimmy > > At 09:17 AM 3/15/2005, Paul Vixie wrote: >> > I can think of at least one... >> > The greater the sparsity of address utilization, the easier >> > it is to hijack portions of the address space. That, in and of itself, >> > to me seems like a good reason NOT to pursue a sparse allocation >> > policy. >> >> this is nonsequitur. ipv4 is a lot smaller and denser than ipv6, and yet >> spammers routinely advertise ipv4 blocks, spam from them for a few >> minutes, and then withdraw the route before most folks get around to >> traceroute'ing. >> >> we're going to need some form of end to end bgp authentication no matter >> whether we move to ipv6 or not, or do so with sparse allocations or >> dense. > > > -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Tue Mar 15 17:35:04 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 15 Mar 2005 16:35:04 -0600 Subject: [ppml] /48 vs /32 micro allocations References: <20050315141748.6AD7C13E3F@sa.vix.com> <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> Message-ID: <034d01c529af$3c670fd0$690016ac@ssprunk> Thus spake "Jimmy Kyriannis" > Yes. One might also view that the sparsity of routing entries would > constitute an environment in which would be "harder to get away with" > hijacking, since filtering longer length prefixes creates a population of > much more visible/impactful prefix targets to hijack. In that vein, if a > longer prefix were to "sneak into" the routing tables, it would also be > rather visible. If hijacking a /48 turns out to make folks more visible or easier to track, why wouldn't they just hijack /32s instead? There's lots and lots of unused IPv6 space to pick from. > Either way, IMO, the fundamental problem of route hijacking won't be > solved here, since it doesn't lie within the filtering of routes, but rather > hardening the protocols which make this possible for disreputable or > unaware providers. Indeed. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From paul at vix.com Tue Mar 15 17:39:30 2005 From: paul at vix.com (Paul Vixie) Date: Tue, 15 Mar 2005 22:39:30 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: Message from "Stephen Sprunk" of "Tue, 15 Mar 2005 16:35:04 CST." <034d01c529af$3c670fd0$690016ac@ssprunk> Message-ID: <20050315223930.4F73413E3F@sa.vix.com> > If hijacking a /48 turns out to make folks more visible or easier to track, > why wouldn't they just hijack /32s instead? There's lots and lots of unused > IPv6 space to pick from. :-} From jimmy.kyriannis at nyu.edu Wed Mar 16 02:01:38 2005 From: jimmy.kyriannis at nyu.edu (Jimmy Kyriannis) Date: Wed, 16 Mar 2005 02:01:38 -0500 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <034d01c529af$3c670fd0$690016ac@ssprunk> References: <20050315141748.6AD7C13E3F@sa.vix.com> <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> <034d01c529af$3c670fd0$690016ac@ssprunk> Message-ID: <6.2.1.2.2.20050316015422.08c79d90@nomad.ns.nyu.edu> At 05:35 PM 3/15/2005, Stephen Sprunk wrote: >Thus spake "Jimmy Kyriannis" > > Yes. One might also view that the sparsity of routing entries would > > constitute an environment in which would be "harder to get away with" > > hijacking, since filtering longer length prefixes creates a population of > > much more visible/impactful prefix targets to hijack. In that vein, if a > > longer prefix were to "sneak into" the routing tables, it would also be > > rather visible. > >If hijacking a /48 turns out to make folks more visible or easier to track, >why wouldn't they just hijack /32s instead? There's lots and lots of unused >IPv6 space to pick from. My point there was that a /32 represents a sizable address block, which if hijacked would presumably get a large number of folks' (and possibly service providers') attention, and might be a bit harder to get away with than ripping off something substantially smaller, like a /48. This is all in the context of the discussion thread on SPAM activity: a scam which benefits more from hijacking active blocks for sourcing forged mail, rather than unused ones. Jimmy From jwkckid1 at ix.netcom.com Wed Mar 16 04:13:22 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 16 Mar 2005 01:13:22 -0800 Subject: [ppml] /48 vs /32 micro allocations References: <20050315141748.6AD7C13E3F@sa.vix.com> Message-ID: <4237F8B1.D5156374@ix.netcom.com> Paul and all, Finnally a voice of reason. I agree with you on this one Paul. Size matters in some things, but not here.. >;) Paul Vixie wrote: > > I can think of at least one... > > The greater the sparsity of address utilization, the easier > > it is to hijack portions of the address space. That, in and of itself, > > to me seems like a good reason NOT to pursue a sparse allocation policy. > > this is nonsequitur. ipv4 is a lot smaller and denser than ipv6, and yet > spammers routinely advertise ipv4 blocks, spam from them for a few minutes, > and then withdraw the route before most folks get around to traceroute'ing. > > we're going to need some form of end to end bgp authentication no matter > whether we move to ipv6 or not, or do so with sparse allocations or dense. -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From jwkckid1 at ix.netcom.com Wed Mar 16 04:34:08 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 16 Mar 2005 01:34:08 -0800 Subject: [ppml] /48 vs /32 micro allocations References: <20050315141748.6AD7C13E3F@sa.vix.com> <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> Message-ID: <4237FD8E.1A563F84@ix.netcom.com> Jimmy and all, I didn't get from Paul's remarks he was eluding to filtering. I agree also that hardening of Protocols is also a very good idea. I believe Paul has been moving in that direction as well... Jimmy Kyriannis wrote: > Yes. One might also view that the sparsity of routing entries would > constitute an environment in which would be "harder to get away with" > hijacking, since filtering longer length prefixes creates a population of > much more visible/impactful prefix targets to hijack. In that vein, if a > longer prefix were to "sneak into" the routing tables, it would also be > rather visible. > > Either way, IMO, the fundamental problem of route hijacking won't be solved > here, since it doesn't lie within the filtering of routes, but rather > hardening the protocols which make this possible for disreputable or > unaware providers. > > Jimmy > > At 09:17 AM 3/15/2005, Paul Vixie wrote: > > > I can think of at least one... > > > The greater the sparsity of address utilization, the easier > > > it is to hijack portions of the address space. That, in and of itself, > > > to me seems like a good reason NOT to pursue a sparse allocation policy. > > > >this is nonsequitur. ipv4 is a lot smaller and denser than ipv6, and yet > >spammers routinely advertise ipv4 blocks, spam from them for a few minutes, > >and then withdraw the route before most folks get around to traceroute'ing. > > > >we're going to need some form of end to end bgp authentication no matter > >whether we move to ipv6 or not, or do so with sparse allocations or dense. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From hannigan at verisign.com Wed Mar 16 02:51:31 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Wed, 16 Mar 2005 02:51:31 -0500 Subject: [ppml] /48 vs /32 micro allocations Message-ID: As someone who is coming up to speed on IPV6, I am somewhat understanding where the WG is coming from and I find myself tending to agree - and looking forward to Orlando. I think Bill nailed it. To me it translated to it's better to drop what I don't want than to not get what I do want, which has been a theme to live by over the years. Cheers, -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan at verisign.com > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Jeff > Williams > Sent: Wednesday, March 16, 2005 4:34 AM > To: Jimmy Kyriannis > Cc: Paul Vixie; ppml at arin.net > Subject: Re: [ppml] /48 vs /32 micro allocations > > > Jimmy and all, > > I didn't get from Paul's remarks he was eluding to > filtering. I agree > also that hardening of Protocols is also a very good idea. I believe > Paul has been moving in that direction as well... > > Jimmy Kyriannis wrote: > > > Yes. One might also view that the sparsity of routing entries would > > constitute an environment in which would be "harder to get > away with" > > hijacking, since filtering longer length prefixes creates a > population of > > much more visible/impactful prefix targets to hijack. In > that vein, if a > > longer prefix were to "sneak into" the routing tables, it > would also be > > rather visible. > > > > Either way, IMO, the fundamental problem of route hijacking > won't be solved > > here, since it doesn't lie within the filtering of routes, > but rather > > hardening the protocols which make this possible for disreputable or > > unaware providers. > > > > Jimmy > > > > At 09:17 AM 3/15/2005, Paul Vixie wrote: > > > > I can think of at least one... > > > > The greater the sparsity of address utilization, > the easier > > > > it is to hijack portions of the address space. That, > in and of itself, > > > > to me seems like a good reason NOT to pursue a sparse > allocation policy. > > > > > >this is nonsequitur. ipv4 is a lot smaller and denser > than ipv6, and yet > > >spammers routinely advertise ipv4 blocks, spam from them > for a few minutes, > > >and then withdraw the route before most folks get around > to traceroute'ing. > > > > > >we're going to need some form of end to end bgp > authentication no matter > > >whether we move to ipv6 or not, or do so with sparse > allocations or dense. > > Regards, > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1 at ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 > > > From Michael.Dillon at radianz.com Wed Mar 16 05:20:51 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 16 Mar 2005 10:20:51 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <6.2.1.2.2.20050315114221.0b641700@nomad.ns.nyu.edu> Message-ID: > Either way, IMO, the fundamental problem of route hijacking won't be solved > here, since it doesn't lie within the filtering of routes, but rather > hardening the protocols which make this possible for disreputable or > unaware providers. Not necessarily! It could lie within an alternate (non-BGP) way for AS holders to publish the possible set of valid routes so that people can do non-BGP validation of what has been published as well as BGP filtering of what has not been published. There's more than one way to skin a cat. Perhaps it's time to take another look at what can be done to improve route registries rather than trying to dump all the requirements into the BGP protocol and the router hardware. I would think that an RIR would be a key player in any such routing registry web of trust. --Michael Dillon From paul at vix.com Wed Mar 16 11:10:31 2005 From: paul at vix.com (Paul Vixie) Date: Wed, 16 Mar 2005 16:10:31 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: Message from Jimmy Kyriannis of "Wed, 16 Mar 2005 02:01:38 EST." <6.2.1.2.2.20050316015422.08c79d90@nomad.ns.nyu.edu> Message-ID: <20050316161031.C234213971@sa.vix.com> > > If hijacking a /48 turns out to make folks more visible or easier to > > track, why wouldn't they just hijack /32s instead? There's lots and > > lots of unused IPv6 space to pick from. > > My point there was that a /32 represents a sizable address block, > which if hijacked would presumably get a large number of folks' (and > possibly service providers') attention, and might be a bit harder to > get away with than ripping off something substantially smaller, like a > /48. i don't see it. either the routing table is going to have enough things in it to make isp and enterprise multihoming possible, which is to say "hundreds of thousands," or the routing table is going to be for tier-1 and early adopters, which is to say "hundreds." in the former case another /32 won't be noticed. in the latter, even a /48 would be noticed. without end to end bgp authentication, the routing table is insecure, and block size isn't a factor. > This is all in the context of the discussion thread on SPAM activity: > a scam which benefits more from hijacking active blocks for sourcing > forged mail, rather than unused ones. without end to end bgp authentication, spammers will find "pink" ISP's who will allow temporary injection of a route (probably never the same one twice), spam like hell for about ten minutes, and then withdraw the route before the "traceroute-bots" can do their work. block size won't be a factor other than that if it's a /48 it'll likely be inside some existing /32 rather than standalone, just to be able to hide better. block size is just not a factor. From bmanning at vacation.karoshi.com Wed Mar 16 11:58:39 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 16 Mar 2005 16:58:39 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: <20050316161031.C234213971@sa.vix.com> References: <6.2.1.2.2.20050316015422.08c79d90@nomad.ns.nyu.edu> <20050316161031.C234213971@sa.vix.com> Message-ID: <20050316165839.GB31656@vacation.karoshi.com.> > be a factor other than that if it's a /48 it'll likely be inside some > existing /32 rather than standalone, just to be able to hide better. > > block size is just not a factor. all too true - an entry in the RIB/FIB is an entry. the "size" represented by the entry is immaterial as far as the routing system goes. but consider this: so for that /48 that your are injecting into the routing system do you mind if i "spam like hell for 10 minutes" and forge the source addresses as a random spread from within your /48? you get to eat all the bounces and complaints - right? hope your bandwidth is big enough to swallow the fallout. :) in this context, size does matter... --bill From paul at vix.com Wed Mar 16 12:16:26 2005 From: paul at vix.com (Paul Vixie) Date: Wed, 16 Mar 2005 17:16:26 +0000 Subject: [ppml] /48 vs /32 micro allocations In-Reply-To: Message from bmanning@vacation.karoshi.com of "Wed, 16 Mar 2005 16:58:39 GMT." <20050316165839.GB31656@vacation.karoshi.com.> Message-ID: <20050316171626.8B76913E4A@sa.vix.com> > > block size is just not a factor. > > ... but consider this: > > so for that /48 that your are injecting into the routing system > do you mind if i "spam like hell for 10 minutes" and forge the source > addresses as a random spread from within your /48? you won't be forging source ipv6 addresses in a random spread unless you're going to stand there with the route pointing at yourself so that you can speak tcp. (saints be praised, TCP-ISS is now a random-enough number!) > you get to eat all the bounces and complaints - right? hope your > bandwidth is big enough to swallow the fallout. :) in this context, > size does matter... either you're there to be your half of the tcp state machine, or not, and in that sense it's likely to be safer to carve an unused /48 out of someone else's advertised /32 and "look like a traffic engineering route" then it would be to grab a /32 or /48 out of the tundra. i predict that the world's appetite for historical bgp announce/withdraws is going to go through the roof now that this method of spamming has reached a kind of "tipping point" and there's no end-to-end bgp authentication on the horizon. From kloch at hotnic.net Wed Mar 16 16:03:13 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 16 Mar 2005 16:03:13 -0500 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: <2147483647.1110886404@imac-en0.delong.sj.ca.us> References: <42362786.90008@hotnic.net> <20050315003807.GA22022@vacation.karoshi.com.> <42364E73.60509@hotnic.net> <20050315050324.GA23032@vacation.karoshi.com.> <423689BC.40901@hotnic.net> <20050315105025.GD24177@vacation.karoshi.com.> <42371847.9040002@hotnic.net> <2147483647.1110886404@imac-en0.delong.sj.ca.us> Message-ID: <42389F11.70504@hotnic.net> Owen DeLong wrote: >> Increasing the minimum allocation size for a few hundred micro >> allocations to 1 / 4billionth of the total address space is not >> wasteful. If you are concerned with relative waste you might want >> to look at the HD ratio of 0.8 (!) that is resulting in /19 allocations >> (that's 8192 /32's right there). >> > Do you have any evidence to support that the number of microallocations > would remain so small? I tend to expect that it would not. > Had I read 2005-1 before the original post I would have suggested a much smaller size (/44) or maybe not have posted it at all considering the political implications. I hope nobody saw this as an attempt to poison 2005-1 as I strongly support it even with my concerns about the allocation size. I really was only considering the few hundred name server and exchange point microallocs at the time. In any case there seems to be a strong consensus that /48's are ok for microallocations. Kevin From paul at vix.com Wed Mar 16 19:40:17 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 17 Mar 2005 00:40:17 +0000 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: Message from Kevin Loch of "Wed, 16 Mar 2005 16:03:13 EST." <42389F11.70504@hotnic.net> Message-ID: <20050317004017.2CBD113971@sa.vix.com> > In any case there seems to be a strong consensus that /48's are ok for > microallocations. not from me. RIRs should allocate only /32's and /128's, and the latter only to critical infrastructure like root name servers. the dominant cost is "routing table slot" and this cost should not be paid unless there is a universal benefit. critical infrastructure is one such benefit. "enough stuff to warrant a /32" is another such benefit. where's the unique yet universal benefit of a /48? From kloch at hotnic.net Wed Mar 16 20:21:16 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 16 Mar 2005 20:21:16 -0500 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: <20050317004017.2CBD113971@sa.vix.com> References: <20050317004017.2CBD113971@sa.vix.com> Message-ID: <4238DB8C.6000202@hotnic.net> Paul Vixie wrote: >>In any case there seems to be a strong consensus that /48's are ok for >>microallocations. > > > not from me. RIRs should allocate only /32's and /128's, and the latter > only to critical infrastructure like root name servers. the dominant cost > is "routing table slot" and this cost should not be paid unless there is > a universal benefit. critical infrastructure is one such benefit. "enough > stuff to warrant a /32" is another such benefit. where's the unique yet > universal benefit of a /48? The universal benefit for 2005-1 allocations is "deployment". I would also put TLD servers in the same category as root servers for criticality (perhaps even more so since the root zone is easy to locally mirror in an emergency but tld's are not). Kevin From paul at vix.com Wed Mar 16 20:31:41 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 17 Mar 2005 01:31:41 +0000 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: Message from Kevin Loch of "Wed, 16 Mar 2005 20:21:16 EST." <4238DB8C.6000202@hotnic.net> Message-ID: <20050317013141.24B4113E3F@sa.vix.com> > >>In any case there seems to be a strong consensus that /48's are ok for > >>microallocations. > > not from me. ... where's the unique yet universal benefit of a /48? > The universal benefit for 2005-1 allocations is "deployment". and i'd agree with that statement, which differs from a general endorsement of /48's as you appeared to be making earlier. > I would also put TLD servers in the same category as root servers for > criticality (perhaps even more so since the root zone is easy to > locally mirror in an emergency but tld's are not). so if i run a server that was ever authoritative for a TLD, i could get a microallocation? i'm not sure that scales well. one of the ways you can know that some infrastructure is critical is if there's a very small number of them. From kloch at hotnic.net Wed Mar 16 23:39:38 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 16 Mar 2005 23:39:38 -0500 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: <20050317013141.24B4113E3F@sa.vix.com> References: <20050317013141.24B4113E3F@sa.vix.com> Message-ID: <42390A0A.8030106@hotnic.net> Paul Vixie wrote: > and i'd agree with that statement, which differs from a general > endorsement of /48's as you appeared to be making earlier. Not a personal endorsement, just a summary of the responses so far to the question: "Should we allocate something larger than /48 for microallocs in case they have bad side effects?" All the responses so far have been emphatically "No!" I am still concerned about possible side effects that are unique to /48: Having to accept millions of deaggregated /48's to get the best/only route to sites with traffic engineered/orphaned routes. I'm not saying that larger microallocs will prevent that, because there certainly are other forces at work, only that they *might* reduce/delay/prevent it. Kevin From jwkckid1 at ix.netcom.com Thu Mar 17 02:40:17 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 16 Mar 2005 23:40:17 -0800 Subject: [ppml] /48 vs /32 micro allocations References: Message-ID: <4239345F.D38F623C@ix.netcom.com> Michael and all, "Webs of Trust" don't work or don't work for long. Hence the direction you are suggesting is more of creating one problem to indadquately solve another. Michael.Dillon at radianz.com wrote: > > Either way, IMO, the fundamental problem of route hijacking won't be > solved > > here, since it doesn't lie within the filtering of routes, but rather > > hardening the protocols which make this possible for disreputable or > > unaware providers. > > Not necessarily! > It could lie within an alternate (non-BGP) way for > AS holders to publish the possible set of valid routes > so that people can do non-BGP validation of what has > been published as well as BGP filtering of what has not > been published. > > There's more than one way to skin a cat. Perhaps it's > time to take another look at what can be done > to improve route registries rather than trying to > dump all the requirements into the BGP protocol > and the router hardware. > > I would think that an RIR would be a key player in > any such routing registry web of trust. > > --Michael Dillon Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From L.Howard at stanleyassociates.com Thu Mar 17 09:50:33 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 17 Mar 2005 09:50:33 -0500 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Paul Vixie > Sent: Wednesday, March 16, 2005 7:40 PM > To: ppml at arin.net > Subject: Re: [ppml] /48 vs /32 micro allocations, answer: /48 > > > > In any case there seems to be a strong consensus that /48's > are ok for > > microallocations. > > not from me. RIRs should allocate only /32's and /128's, and Would it be possible to allocate /128s? I'd sleep better if we could allocate off the tail end of the 128 bits, knowing that every 10-20 years we'd have to add a bit. > the latter only to critical infrastructure like root name > servers. Note that "critical infrastructure" is used more broadly in current policies, section 4.4 http://www.arin.net/policy/index.html ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. So we may need to have a conversation around that definition for IPv6. Of course, there are other questions within the narrow "root operator" definition. Does each IPv4 anycast root get its own IPv6 allocations? > the dominant cost is "routing table slot" and this > cost should not be paid unless there is a universal benefit. > critical infrastructure is one such benefit. "enough stuff > to warrant a /32" is another such benefit. where's the > unique yet universal benefit of a /48? Proponents of the current policy argued that a /48 is a nice round bit boundary, and large enough that an LIR (or RIR in cases) could say, "Fine, whatever, here's your /48, now go away and don't bother me again." I'm glad to see general use of "routing table slot" as an economic concern. large-but-finite = scarce Lee From paul at vix.com Thu Mar 17 09:51:39 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 17 Mar 2005 14:51:39 +0000 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: Message from Kevin Loch of "Wed, 16 Mar 2005 23:39:38 EST." <42390A0A.8030106@hotnic.net> Message-ID: <20050317145139.76C5513E4A@sa.vix.com> > > ... i'd agree with that statement, which differs from a general > > endorsement of /48's as you appeared to be making earlier. > > Not a personal endorsement, just a summary of the responses > so far to the question: "Should we allocate something larger > than /48 for microallocs in case they have bad side effects?" > All the responses so far have been emphatically "No!" which is another statement i'd agree with that's different from the one i challenged. > I am still concerned about possible side effects that are > unique to /48: Having to accept millions of deaggregated > /48's to get the best/only route to sites with traffic > engineered/orphaned routes. I'm not saying that larger > microallocs will prevent that, because there certainly > are other forces at work, only that they *might* > reduce/delay/prevent it. the policy under consideration amounts to: we're not going to get deployment in V6 without a swamp. but, let's try to give this swamp a boundary smaller than V4's swamp. and, let's not give early adopters full sized blocks unless they qualify. so, for now, let's do /48's. to me this has all the earmarks of good policy. From paul at vix.com Thu Mar 17 11:55:00 2005 From: paul at vix.com (Paul Vixie) Date: Thu, 17 Mar 2005 16:55:00 +0000 Subject: [ppml] /48 vs /32 micro allocations, answer: /48 In-Reply-To: Message from "Howard, W. Lee" of "Thu, 17 Mar 2005 09:50:33 EST." Message-ID: <20050317165500.1BC3013E3F@sa.vix.com> > So we may need to have a conversation around that definition for IPv6. yes. in particular, an exchange point would actually need a /48 not a /128. (a /64 won't do, since exchange points now mostly use multiple VLANs to segregate things like multicast from things like unicast.) > Of course, there are other questions within the narrow "root > operator" definition. Does each IPv4 anycast root get its own IPv6 > allocations? according to www.root-servers.org, that is indeed what's happening today. > I'm glad to see general use of "routing table slot" as an > economic concern. large-but-finite = scarce the thing is, in ipv4 there was an equilibrium to be established, and it's moved several times. the minimum allocation size was raised when there were too many routes, then lowered when there were too many multihomers who couldn't qualify for the larger size. in ipv6 there is no equilibrium, the smallest block we can imagine allocating is large enough for almost anybody except perhaps some multinationals. From memsvcs at arin.net Thu Mar 17 15:19:24 2005 From: memsvcs at arin.net (Member Services) Date: Thu, 17 Mar 2005 15:19:24 -0500 Subject: [ppml] The Open Policy Hour Message-ID: <4239E64C.3090306@arin.net> Do you have an idea about how ARIN should manage Internet Number Resources? Do you think that a current policy should be enhanced or changed, or even retired? Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? Are you new to the Policy Development Process? If the answer to any of these questions is yes, then you should attend THE OPEN POLICY HOUR! What is THE OPEN POLICY HOUR? Quite simply, it is your opportunity to discuss your ideas in an open, informal forum and receive feedback. It is not a review session of the policies that will be discussed during the ARIN XV Public Policy meeting, nor is it a requirement for a policy to be considered in the ARIN Internet Resource Policy Evaluation Process. There are no minutes of this meeting. How can you participate? Bring your ideas and questions. If you have a policy proposal for which you would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. If you have a short (3-minute) presentation prepared you can do it at this session, in fact you will be given the first opportunity to present it. To sign up please send an e-mail to policy at arin.net by April 12, 2005, with your name, organization, and a general description of your policy subject. Come join your colleagues in this informal setting; light refreshments will be available. The Open Policy Hour for ARIN XV will be held on Sunday, April 17, from 5:00 - 5:30 PM. IMPORTANT REMINDER: If you haven't already registered for ARIN XV and NAv6TF Summit, do so right away. If you reserve your hotel room before March 25, you can take advantage of the ARIN XV/NAv6TF special room rates. The number of rooms available at this rate is limited, so don't delay! Registration is simple. Registration and hotel details are at: http://www.arin.net/ARIN-XV/ Agenda details are at: http://www.arin.net/ARIN-XV/agenda.html Contact Member Services at memsvcs at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers ====================================================================== Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL http://www.arin.net/ARIN-XV/ E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net ====================================================================== From memsvcs at arin.net Fri Mar 18 10:46:28 2005 From: memsvcs at arin.net (Member Services) Date: Fri, 18 Mar 2005 10:46:28 -0500 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations Message-ID: <423AF7D4.9010803@arin.net> ARIN welcomes feedback and discussion about this policy proposal in the weeks leading to the ARIN Public Policy Meeting in Orlando, Florida, scheduled for April 18-20, 2005. The policy proposal text is below and can be found at http://www.arin.net/policy/2005_3.html. Note that the author revised the text so that it is not specific to a single protocol. According to the ARIN Internet Resource Policy Evaluation Process the ARIN Advisory Council will evaluate policy proposals after the Public Policy Meeting. The feedback and discussion of policy proposals on the Public Policy Mailing List will be included in the AC's evaluation. Subscription information for the ARIN Public Policy Mailing List can be found at http://www.arin.net/mailing_lists/index.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. ARIN's Policy Proposal Archive can be found at http://www.arin.net/policy/proposal_archive.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-3: Lame Delegations Author name: Paul Andersen on behalf of the ARIN AC Policy term: permanent Policy statement: This policy proposal replaces section 7.2 of the ARIN NRPM. ARIN will actively identify lame DNS name server(s) for reverse address delegations associated with address blocks allocated, assigned or administered by ARIN. Upon identification of a lame delegation, ARIN shall attempt to contact the POC for that resource and resolve the issue. If, following due diligence, ARIN is unable to resolve the lame delegation, ARIN will update the WHOIS database records resulting in the removal of lame servers. Rationale: The policy as stated could not be implemented without placing an undue burden on ARIN staff resources. The procedures mandated in the policy require a shifting of registration service resources from such activities as IP Analyst support for on-going registration actions as well as the telephonic and email help desks. Removing the procedures from the policy allows the Director of Registration Services the flexibility of meeting all registration services needs and managing the identification, notification, and removal of lame delegations. Timetable for implementation: 90 days after adoption From randy at psg.com Fri Mar 18 11:19:55 2005 From: randy at psg.com (Randy Bush) Date: Fri, 18 Mar 2005 08:19:55 -0800 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations References: <423AF7D4.9010803@arin.net> Message-ID: <16954.65451.574944.696087@roam.psg.com> > ARIN will actively identify lame DNS name server(s) for reverse address > delegations associated with address blocks allocated, assigned or > administered by ARIN. Upon identification of a lame delegation, ARIN > shall attempt to contact the POC for that resource and resolve the > issue. If, following due diligence, ARIN is unable to resolve the lame > delegation, ARIN will update the WHOIS database records resulting in the > removal of lame servers. and, o if no servers remain, the delegation is removed? o and if only one server remains? randy From memsvcs at arin.net Fri Mar 18 11:56:31 2005 From: memsvcs at arin.net (Member Services) Date: Fri, 18 Mar 2005 11:56:31 -0500 Subject: [ppml] Petition Request for HD Ratio proposal In-Reply-To: <422F2D4E.8000105@arin.net> References: <422F2D4E.8000105@arin.net> Message-ID: <423B083F.7060002@arin.net> The author's petition of the proposed policy, "Adding an HD ratio choice for new IPv4 allocations", was unsuccessful. The proposed policy text may be found at: http://www.arin.net/mailing_lists/ppml/3175.html The proposed policy, Adding an HD ratio choice for new IPv4 allocations, was posted to the ARIN Public Policy Mailing List (PPML) on February 17, 2005. The ARIN Advisory Council conducted an initial review and decided not to support moving the proposal forward in the evaluation process. The author elected to petition and posted to PPML on March 9 in order to advance the proposal in the evaluation process. The deadline for submitting support for the petition ended on March 16, 2005. The following process, as described in the Internet Resource Policy Evaluation Process and excerpted below, was then carried out. In accordance with the ARIN Internet Resource Policy Evaluation Process, the President of ARIN will verify whether people from at least four different organizations support a petitioned policy proposal. * If a petition receives the required support, the policy proposal will be considered formal and will follow the remainder of the evaluation process. * If a petition fails to receive the required support within five days, the policy proposal will be considered closed. Based upon an unsuccessful petition, the policy proposal is now closed. Regards, Raymond A. Plzak President & CEO ARIN Member Services wrote: > The deadline for issuing statements of support for this petition is 2400 > Eastern Time, March 16, 2005. > > If the petition is successful, the policy proposal will be numbered, > posted online for discussion, and presented at the upcoming Public > Policy Meeting in Orlando. > > If the petition is not successful, the policy proposal will be > considered closed. > > Regards, > > Member Services Department > American Registry for Internet Numbers > > ====================================================================== > Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL > > http://www.arin.net/ARIN-XV/ > > E-mail memsvcs at arin.net > FTP ftp.arin.net > WHOIS whois.arin.net > Website http://www.arin.net > ====================================================================== > > > > Michael.Dillon at radianz.com wrote: > >> This is a formal petition to advance the policy proposal entitled >> "Adding an HD ratio choice for new IPv4 allocations". The full text of >> the proposal is posted on the ARIN website at this URL: >> http://www.arin.net/mailing_lists/ppml/3175.html >> This policy proposal incorporates changes to address the >> objections raised the last time a similar proposal was >> before the members. I believe that we should all support >> discussing and EVOLVING policy in the open forum of >> the meetings. >> >> According to the Internet Resource Policy Evaluation Process, people >> who wish to document their support for the petition must do the >> following within the next five (5) days: >> 1) post a response to the Public Policy Mailing List stating their >> support for the proposal, and 2) send email to petition at arin.net with >> full point of contact information, including their telephone number >> and organizational affiliation. >> The ARIN President will verify whether people from at least four >> different organizations support the petitioned policy proposal. >> If you have any questions about this process you may wish to refer to >> the ARIN website at http://www.arin.net/policy/ipep.html for the full >> text explaining the petition process. >> --Michael Dillon >> >> > > From owen at delong.com Fri Mar 18 15:59:06 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Mar 2005 12:59:06 -0800 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <423AF7D4.9010803@arin.net> References: <423AF7D4.9010803@arin.net> Message-ID: <2147483647.1111150746@imac-en0.delong.sj.ca.us> In general, I think this is a good policy. However, I think that the WHOIS data should retain the server records and flag them as LAME. I think that ARIN should, in addition, remove the delegating NS records pointing to the lame servers. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Sat Mar 19 11:40:22 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sat, 19 Mar 2005 11:40:22 -0500 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <16954.65451.574944.696087@roam.psg.com> References: <423AF7D4.9010803@arin.net> <16954.65451.574944.696087@roam.psg.com> Message-ID: At 8:19 -0800 3/18/05, Randy Bush wrote: >> ARIN will actively identify lame DNS name server(s) for reverse address >> delegations associated with address blocks allocated, assigned or >> administered by ARIN. Upon identification of a lame delegation, ARIN >> shall attempt to contact the POC for that resource and resolve the >> issue. If, following due diligence, ARIN is unable to resolve the lame >> delegation, ARIN will update the WHOIS database records resulting in the >> removal of lame servers. > >and, > o if no servers remain, the delegation is removed? > o and if only one server remains? Following along this path... What if: o if a server for one zone out of "many" for an address range is lame but the rest are okay, is the one zone "delisted?" Is the goal of this to protect the global DNS via the removal of bad references or is the goal to enact a clean up of the ARIN database? This distinction determines the gravity of the proposal. If the goal is to protect the global DNS, then: Finding a lame server for a zone leads to the removal of the server from the DNS. This doesn't change the WhoIs entry, nor what is in the ARIN database. I could imagine the implementation of this as a "filter" on zone file production, i.e., lame NS records are simply dropped from the files before hitting the DNS. (Said for imagination's sake only.) If the goal is to enact a clean up of the ARIN database, then: Finding a lame server for a zone would put the registrant on notice that if registration creating the resource record leading to the lameness is not corrected, the registration will be "fixed" by ARIN. If so, then this like cleaning contact information, etc. Does the policy cover legacy space that is now registered in ARIN? IMHO, I'd assume that the purpose of this proposal is to protect the global DNS. If that is the case, I'm more comfortable with a shorter-term contact period and automated deletion and replacement of delegation records. There is an issue with DNS servers that don't answer. One accepted remedy to the trouble of testing these is repeated and distributed testing. Repeating tests is simple, distributed tests is a pain. I mention this because of the requirement of a 90 day implementation. If we want to go after non-responsive servers as lame, which I think is part of the goal of protecting the global DNS, 90 days is too short of a time period to include sufficient testing. Prior to moving to production, it would be good for a test to be run for a realistic duration - which IMHO is a month. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. From owen at delong.com Sun Mar 20 03:04:34 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 20 Mar 2005 00:04:34 -0800 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: References: <423AF7D4.9010803@arin.net> <16954.65451.574944.696087@roam.psg.com> Message-ID: <2147483647.1111277074@imac-en0.delong.sj.ca.us> > What if: > o if a server for one zone out of "many" for an address range is lame > but the rest are okay, is the one zone "delisted?" [snip] If the server to which ARIN delegates answers with either referrals for more specifics (2317 or /24 from /16, etc.) or Zone Data (SOA, PTR, etc.), then, that server is not LAME. Servers to which that server delegates are not and should not be part of what is considered in this proposal. The entity running the delegating server should develop and implement their own policy towards their downstreams. Hopefully this would be consistent with BCP and standards. [summary:] Question of Purpose: o Global DNS Protect o WHOIS Cleanup [snip] I do not see this proposal as targeted specifically at either of these concerns, and, I don't see them as mutually exclusive. I would like to see this as a start towards both issues. I think that leaving the NS information in WHOIS with a "LAME" marker on it, and, removing it from the DNS is the ideal solution if contact and resolution cannot be achieved. Again, I do not think that ARIN should take any action in regards to data or DNS entries which are not delgated by ARIN (e.g. LAME SWIPs should not be modified by ARIN, although it would be good if ARIN contacted the upstream supplying the SWIP under the first part of this policy). Anyway, just my $0.02. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Sun Mar 20 09:26:45 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sun, 20 Mar 2005 09:26:45 -0500 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <2147483647.1111277074@imac-en0.delong.sj.ca.us> References: <423AF7D4.9010803@arin.net> <16954.65451.574944.696087@roam.psg.com> <2147483647.1111277074@imac-en0.delong.sj.ca.us> Message-ID: At 0:04 -0800 3/20/05, Owen DeLong wrote: >> What if: >> o if a server for one zone out of "many" for an address range is lame >> but the rest are okay, is the one zone "delisted?" >[snip] > >If the server to which ARIN delegates answers with either referrals for >more specifics (2317 or /24 from /16, etc.) or Zone Data (SOA, PTR, etc.), >then, that server is not LAME. Servers to which that server delegates are >not and should not be part of what is considered in this proposal. The >entity running the delegating server should develop and implement their >own policy towards their downstreams. Hopefully this would be consistent >with BCP and standards. There's a misunderstanding here. To try to clear this up, I'll use a fictional example. Let's say I, an ISP, am allocated 365.29.0.0-365.29.31.255, which is equivalent to 365.29.0/19, and I register "ns0.example". as my name server for this range. (I'm using one name server to keep the example simple.) ARIN's 365.in-addr.arpa zone will then that the following records for me: 0.29.365.in-addr.arpa. NS ns0.example. 1.29.365.in-addr.arpa. NS ns0.example. 2.29.365.in-addr.arpa. NS ns0.example. ... 31.29.365.in-addr.arpa. NS ns0.example. The question is: What happens if, after a few months, I've "reassigned-simple" the first 10 "/24's" worth of space and set up reverse for them, but haven't set up reverse for the the remaining zones? I.e., [0,1,2,3,4,5,6,7,8,9].29.365.in-addr.arpa are configured and running on ns0.example. The zones from [10..31.29.365].in-addr.arpa are not configured. (The proper action is to set up all 32 zones, even though there are no entries in the "unused" zones.) The question I posed has nothing to do with any delegation record not published by ARIN. If my ISP had a /16, there would be just one NS record to my server. I think it would be out of bounds for ARIN to test whether referrals issued by my machine referenced lame servers. >[summary:] >Question of Purpose: > o Global DNS Protect > o WHOIS Cleanup >[snip] > >I do not see this proposal as targeted specifically at either of these >concerns, and, I don't see them as mutually exclusive. I would like to >see this as a start towards both issues. I think that leaving the NS >information in WHOIS with a "LAME" marker on it, and, removing it from >the DNS is the ideal solution if contact and resolution cannot be achieved. I think this proposal ought to be targeted at something, it makes a difference when trying to engineers a solution. ARIN staff is to be given the latitude in making implementation decisions, but the membership ought to given the staff an indication of "what to optimize for." I agree with you that leaving lame servers marked as such in WhoIs. But look at my example above. What happens if I get an answer for dig -x 365.29.4.138 and a lame response (which looks like a referral "up" the DNS tree) for dig -x 365.29.14.138? Is this server marked a lame in WhoIs or not? >Again, I do not think that ARIN should take any action in regards to >data or DNS entries which are not delgated by ARIN (e.g. LAME SWIPs >should not be modified by ARIN, although it would be good if ARIN >contacted the upstream supplying the SWIP under the first part of >this policy). That's a good bounding for the policy. On the one hand, such lameness is also a problem and ARIN has the data to test for it, on the other hand, this would be unmanageable. Maybe in the future, but definitely not now. And maybe not even in the future. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. From owen at delong.com Sun Mar 20 15:12:27 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 20 Mar 2005 12:12:27 -0800 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: References: <423AF7D4.9010803@arin.net> <16954.65451.574944.696087@roam.psg.com> <2147483647.1111277074@imac-en0.delong.sj.ca.us> Message-ID: <2147483647.1111320747@imac-en0.delong.sj.ca.us> > Let's say I, an ISP, am allocated 365.29.0.0-365.29.31.255, which is > equivalent to 365.29.0/19, and I register "ns0.example". as my name > server for this range. (I'm using one name server to keep the example > simple.) [snip] > The question is: What happens if, after a few months, I've > "reassigned-simple" the first 10 "/24's" worth of space and set up > reverse for them, but haven't set up reverse for the the remaining zones? > > I.e., [0,1,2,3,4,5,6,7,8,9].29.365.in-addr.arpa are configured and > running on ns0.example. The zones from [10..31.29.365].in-addr.arpa are > not configured. > [snip] Got it. In this case, I think that ARIN contacting the ISP and educating them will work 99+% of the time. In that 1% case, I think there are a few options, and, frankly, I'm not sure which is best: + ARIN record boundaries are somewhat independent of actual allocation size. For example, I have a /23 which, due to historical reasons, is recorded in ARIN databases as two /24s. As a result, ARIN could split the allocation into: 365.29.0.0-365.29.9.255 and 365.29.10.0-365.29.31.255 This would allow my originally proposed solution to work just fine. Of course, then the ISP has to correct things prior to being able to make in-addrs work for any new assignments they issue from the block. This is not necessarily a bad thing in my opinion. (And yes, the ARIN database is capable of non-bit-aligned allocations, several such blocks exist already) + ARIN could mark the whole record lame, and remove the delegations from DNS, but, I think that would violate the "First, do no harm." principle. + ARIN could flag the whois record as partially lame. The lame portions could be removed from DNS. Again, this has the same tradeoff listed in the first option. > I think this proposal ought to be targeted at something, it makes a > difference when trying to engineers a solution. ARIN staff is to be > given the latitude in making implementation decisions, but the membership > ought to given the staff an indication of "what to optimize for." > OK... On that we can agree to disagree. I think both are worthwhile goals, and, I think both can be accomplished. In general, I expect the need to flag and/or remove delegation to be the exception and not the rule. Especially for blocks like you describe. I think when it does come up, it will mostly relate to legacy allocations and assignments, not recent ones. Recent issues, ARIN will usually be able to contact the recipient and educate them. [snip] >> Again, I do not think that ARIN should take any action in regards to >> data or DNS entries which are not delgated by ARIN (e.g. LAME SWIPs >> should not be modified by ARIN, although it would be good if ARIN >> contacted the upstream supplying the SWIP under the first part of >> this policy). > > That's a good bounding for the policy. On the one hand, such lameness is > also a problem and ARIN has the data to test for it, on the other hand, > this would be unmanageable. Maybe in the future, but definitely not now. > And maybe not even in the future. > Even in the future, I don't think ARIN should take action beyond that first degree of separation. ARIN should contact the ORG which received the resource from ARIN. That ORG should be responsible for contacting their downstream or otherwise mitigating the problem. Regardless of what ARIN can do, drawing the boundary here simplifies a number of legal issues and other potential pitfalls. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Sun Mar 20 21:27:34 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sun, 20 Mar 2005 21:27:34 -0500 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <2147483647.1111320747@imac-en0.delong.sj.ca.us> References: <423AF7D4.9010803@arin.net> <16954.65451.574944.696087@roam.psg.com> <2147483647.1111277074@imac-en0.delong.sj.ca.us> <2147483647.1111320747@imac-en0.delong.sj.ca.us> Message-ID: At 12:12 -0800 3/20/05, Owen DeLong wrote: >Got it. In this case, I think that ARIN contacting the ISP and educating >them will work 99+% of the time. In that 1% case, I think there are a >few options, and, frankly, I'm not sure which is best: I've been assuming (assuming!) that the percentages would be reversed, but you could be right. Not arguing, just pointing out where I had been coming from. > + ARIN record boundaries are somewhat independent of > actual allocation size. For example, I have a /23 > which, due to historical reasons, is recorded in > ARIN databases as two /24s. As a result, ARIN could > split the allocation into: > > 365.29.0.0-365.29.9.255 and 365.29.10.0-365.29.31.255 This is a step in the right direction. There's a tangential issue on the horizon though that might feed into this. The tangential issue is DNSSEC - and I don't mean to start a discussion on that here, this is a future topic. The reason I mention it is that for DNSSEC, *if* it becomes a reality, there is a need to store data per DNS zone, something ARIN does not do up to now. To cut to the chase, splitting the allocation's zones into lame and not lame might be a "degenerate case" of having to store unique data (public keys for DNSSEC) per zone within an allocation. > This would allow my originally proposed solution to > work just fine. Of course, then the ISP has to correct > things prior to being able to make in-addrs work for > any new assignments they issue from the block. This > is not necessarily a bad thing in my opinion. > > (And yes, the ARIN database is capable of non-bit-aligned > allocations, several such blocks exist already) Yes, the database demonstrates the capability of handling arbitrary ranges of addresses, CIDR is not a prerequisite. The capability that is needed for lame delegation and potentially DNSSEC is the ability to store per zone. What I'm saying is that we should seek an engineering opinion on what you are suggesting, with some assessment of what *would be* needed for DNSSEC and future trends in DNS. > + ARIN could mark the whole record lame, and remove the > delegations from DNS, but, I think that would violate > the "First, do no harm." principle. > > + ARIN could flag the whois record as partially lame. The > lame portions could be removed from DNS. Again, this has > the same tradeoff listed in the first option. What membership should consider is an estimate of the engineering to achieve the latter, or just treating allocations that are completely lame. (The latter is a lower hanging fruit that would beneficial to solve for probably a lot less effort.) As you say about the prior bullet, violating "do no harm" you are right and I would not recommend throwing out good zones with the bad. >> I think this proposal ought to be targeted at something, it makes a ... >OK... On that we can agree to disagree. I think both are worthwhile goals, >and, I think both can be accomplished. In general, I expect the need ... I don't think that we will wind up disagreeing. (That's so not "consensus." ;)) I mention these goals for consideration, but if the membership decides it's not important to pick one, both, or others, then I will consider this a learning experience. As in - trying to adjust the detail with which we document policies. >Even in the future, I don't think ARIN should take action beyond that >first degree of separation. ARIN should contact the ORG which received Ack. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. From owen at delong.com Mon Mar 21 01:57:08 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 20 Mar 2005 22:57:08 -0800 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: References: <423AF7D4.9010803@arin.net> <16954.65451.574944.696087@roam.psg.com> <2147483647.1111277074@imac-en0.delong.sj.ca.us> <2147483647.1111320747@imac-en0.delong.sj.ca.us> Message-ID: <2147483647.1111359428@[172.17.1.152]> [Attn: Richard Jimmerson About the middle of this message there is a question where I think we need some feedback from ARIN staff about what is/isn't possible and what is easiest. We've got a few different tradeoffs to consider, and, we'd like staff feedback on the implementation of each. Thanks, Owen] --On Sunday, March 20, 2005 21:27 -0500 Edward Lewis wrote: > At 12:12 -0800 3/20/05, Owen DeLong wrote: > >> Got it. In this case, I think that ARIN contacting the ISP and educating >> them will work 99+% of the time. In that 1% case, I think there are a >> few options, and, frankly, I'm not sure which is best: > > I've been assuming (assuming!) that the percentages would be reversed, > but you could be right. Not arguing, just pointing out where I had been > coming from. > Well... Not sure. For legacy delegations, you're probably right, contact will probably be a challenge. However, for these, the likelihood of your issue for partial lameness is also smaller. For more recent delegations, the contact data is more likely to be correct and workable, so, the likelihood that the ORG receiving the delegation will correct the server upon notification and training (it's not really hard, afterall), is, IMHO, relatively high. >> + ARIN record boundaries are somewhat independent of >> actual allocation size. For example, I have a /23 >> which, due to historical reasons, is recorded in >> ARIN databases as two /24s. As a result, ARIN could >> split the allocation into: >> >> 365.29.0.0-365.29.9.255 and 365.29.10.0-365.29.31.255 > > This is a step in the right direction. > > There's a tangential issue on the horizon though that might feed into > this. The tangential issue is DNSSEC - and I don't mean to start a > discussion on that here, this is a future topic. The reason I mention it > is that for DNSSEC, *if* it becomes a reality, there is a need to store > data per DNS zone, something ARIN does not do up to now. > Well, since ARIN doesn't really have any convenient way to determine what the boundaries of a DNS Zone are, that's going to be pretty hard for ARIN to do. > To cut to the chase, splitting the allocation's zones into lame and not > lame might be a "degenerate case" of having to store unique data (public > keys for DNSSEC) per zone within an allocation. > So it is expected that ARIN will store the public keys for zones not delegated by ARIN? That seems like a flaw in the DNSSEC design if it is the case. I don't see any reason ARIN would want to get involved in that. >> This would allow my originally proposed solution to >> work just fine. Of course, then the ISP has to correct >> things prior to being able to make in-addrs work for >> any new assignments they issue from the block. This >> is not necessarily a bad thing in my opinion. >> >> (And yes, the ARIN database is capable of non-bit-aligned >> allocations, several such blocks exist already) > > Yes, the database demonstrates the capability of handling arbitrary > ranges of addresses, CIDR is not a prerequisite. The capability that is > needed for lame delegation and potentially DNSSEC is the ability to store > per zone. > Well, a "Zone" is an arbitrarily bounded range of addresses when talking about reverse, so, that's possible, but, I'm still not sure how ARIN gets involved in determining "Zones" where ARIN doesn't delegate the zone. > What I'm saying is that we should seek an engineering opinion on what you > are suggesting, with some assessment of what *would be* needed for DNSSEC > and future trends in DNS. > I think I understand where you're coming from, but, I remain unconvinced that ARIN should base policy on an assumption that a working group will heap a responsibility on ARIN that it has not yet had any discussion about accepting. If this policy needs modification to accommodate DNSSEC public key storage by ARIN, then, that modification should be part of the policy proposal that implements ARIN doing public key storage for DNSSEC. Until then, policy should be based on what we know and not what we think might happen in an IETF working group. >> + ARIN could mark the whole record lame, and remove the >> delegations from DNS, but, I think that would violate >> the "First, do no harm." principle. >> >> + ARIN could flag the whois record as partially lame. The >> lame portions could be removed from DNS. Again, this has >> the same tradeoff listed in the first option. > > What membership should consider is an estimate of the engineering to > achieve the latter, or just treating allocations that are completely > lame. (The latter is a lower hanging fruit that would beneficial to > solve for probably a lot less effort.) As you say about the prior > bullet, violating "do no harm" you are right and I would not recommend > throwing out good zones with the bad. > I'm not sure whether the first or third option is the lower hanging fruit. I'd need to get an assessment from ARIN staff on that. Perhaps Richard is watching the list and will ask staff based on this message and post something to the list (Richard?). Otherwise, I'm sure it will be part of the discussion in Orlando, and, staff will follow up on it. (actually, I'm CCing richardj on this to call it to his attention. >>> I think this proposal ought to be targeted at something, it makes a > ... >> OK... On that we can agree to disagree. I think both are worthwhile >> goals, and, I think both can be accomplished. In general, I expect the >> need > > ... > > I don't think that we will wind up disagreeing. (That's so not > "consensus." ;)) I mention these goals for consideration, but if the > membership decides it's not important to pick one, both, or others, then > I will consider this a learning experience. As in - trying to adjust the > detail with which we document policies. > OK... Well, if it's important to pick, I pick both. If it's not important to pick, then, it doesn't matter. :-) Others, I'd need to know what they were to evaluate. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From memsvcs at arin.net Mon Mar 21 10:04:44 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 21 Mar 2005 10:04:44 -0500 Subject: [ppml] ARIN XV Policy Proposals and Hotel Room Reminder Message-ID: <423EE28C.6010104@arin.net> ARIN will hold its next Public Policy Meeting, April 18-20, 2005, in Orlando, Florida. Meeting and registration details can be found at: http://www.arin.net/ARIN-XV/ Policy discussions at this meeting will be centered on policy proposals recently introduced to the Public Policy Mailing List (PPML), and those carried over from the previous Public Policy Meeting. Policy Proposals recently introduced on PPML: 2005-1 Provider Independent IPv6 Assignments for End-sites 2005-2 Directory Services Overhaul 2005-3 Lame Delegations Policy Proposals carried over from previous Public Policy Meetings: 2004-3 Global Addresses for Private Network Inter-Connectivity 2004-8 Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries Leading up to the meeting, policy proposals are open for discussion on PPML. Each of the policy proposals has been previously posted to this mailing list as an independent thread to facilitate discussion. A summary of the active policy proposals under discussion can be found at: http://www.arin.net/policy/proposal_archive.html The entire Internet community is invited and encouraged to participate in these policy discussions. Your active participation in these discussions is vital to the process and will help to form policies that are beneficial to all. Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html --------------------------------------------------------------------- Hotel Room Reminder Please be advised that the special conference hotel rate expires this Friday, March 25, 2005. If you have not already done so, use the following link to reserve your room: http://www.arin.net/ARIN-XV/hotel.html Regards, Member Services Department American Registry for Internet Numbers ====================================================================== Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL http://www.arin.net/ARIN-XV/ E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net ====================================================================== From richardj at arin.net Mon Mar 21 14:55:27 2005 From: richardj at arin.net (Richard Jimmerson) Date: Mon, 21 Mar 2005 14:55:27 -0500 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <2147483647.1111359428@[172.17.1.152]> Message-ID: <20050321195540.DC32A1FED1@mercury.arin.net> Owen, Message received. We can consider these options in the staff impact analysis that is conducted for each new policy proposal. I'll contact you off list for clarification about which options you are asking be considered. Richard Jimmerson Director of External Relations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, March 21, 2005 1:57 AM > To: Edward Lewis > Cc: ppml at arin.net; richardj at arin.net > Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations > Importance: High > > > [Attn: Richard Jimmerson > About the middle of this message there is a question where > I think we > need some feedback from ARIN staff about what is/isn't > possible and what > is easiest. We've got a few different tradeoffs to > consider, and, we'd > like staff feedback on the implementation of each. > > Thanks, > > Owen] > > > --On Sunday, March 20, 2005 21:27 -0500 Edward Lewis > > wrote: > > > At 12:12 -0800 3/20/05, Owen DeLong wrote: > > > >> Got it. In this case, I think that ARIN contacting the ISP and > >> educating them will work 99+% of the time. In that 1% > case, I think > >> there are a few options, and, frankly, I'm not sure which is best: > > > > I've been assuming (assuming!) that the percentages would > be reversed, > > but you could be right. Not arguing, just pointing out where I had > > been coming from. > > > Well... Not sure. For legacy delegations, you're probably > right, contact will probably be a challenge. However, for > these, the likelihood of your issue for partial lameness is > also smaller. For more recent delegations, the contact data > is more likely to be correct and workable, so, the likelihood > that the ORG receiving the delegation will correct the server > upon notification and training (it's not really hard, > afterall), is, IMHO, relatively high. > > >> + ARIN record boundaries are somewhat independent of > >> actual allocation size. For example, I have a /23 > >> which, due to historical reasons, is recorded in > >> ARIN databases as two /24s. As a result, ARIN could > >> split the allocation into: > >> > >> 365.29.0.0-365.29.9.255 and 365.29.10.0-365.29.31.255 > > > > This is a step in the right direction. > > > > There's a tangential issue on the horizon though that might > feed into > > this. The tangential issue is DNSSEC - and I don't mean to start a > > discussion on that here, this is a future topic. The > reason I mention > > it is that for DNSSEC, *if* it becomes a reality, there is > a need to > > store data per DNS zone, something ARIN does not do up to now. > > > Well, since ARIN doesn't really have any convenient way to > determine what the boundaries of a DNS Zone are, that's going > to be pretty hard for ARIN to do. > > > To cut to the chase, splitting the allocation's zones into lame and > > not lame might be a "degenerate case" of having to store > unique data > > (public keys for DNSSEC) per zone within an allocation. > > > So it is expected that ARIN will store the public keys for > zones not delegated by ARIN? That seems like a flaw in the > DNSSEC design if it is the case. I don't see any reason ARIN > would want to get involved in that. > > >> This would allow my originally proposed solution to > >> work just fine. Of course, then the ISP has to correct > >> things prior to being able to make in-addrs work for > >> any new assignments they issue from the block. This > >> is not necessarily a bad thing in my opinion. > >> > >> (And yes, the ARIN database is capable of > non-bit-aligned > >> allocations, several such blocks exist already) > > > > Yes, the database demonstrates the capability of handling arbitrary > > ranges of addresses, CIDR is not a prerequisite. The > capability that > > is needed for lame delegation and potentially DNSSEC is the > ability to > > store per zone. > > > Well, a "Zone" is an arbitrarily bounded range of addresses > when talking about reverse, so, that's possible, but, I'm > still not sure how ARIN gets involved in determining "Zones" > where ARIN doesn't delegate the zone. > > > What I'm saying is that we should seek an engineering > opinion on what > > you are suggesting, with some assessment of what *would be* > needed for > > DNSSEC and future trends in DNS. > > > I think I understand where you're coming from, but, I remain > unconvinced that ARIN should base policy on an assumption > that a working group will heap a responsibility on ARIN that > it has not yet had any discussion about accepting. If this > policy needs modification to accommodate DNSSEC public key > storage by ARIN, then, that modification should be part of > the policy proposal that implements ARIN doing public key > storage for DNSSEC. Until then, policy should be based on > what we know and not what we think might happen in an IETF > working group. > > >> + ARIN could mark the whole record lame, and remove the > >> delegations from DNS, but, I think that would violate > >> the "First, do no harm." principle. > >> > >> + ARIN could flag the whois record as partially lame. The > >> lame portions could be removed from DNS. > Again, this has > >> the same tradeoff listed in the first option. > > > > What membership should consider is an estimate of the > engineering to > > achieve the latter, or just treating allocations that are > completely > > lame. (The latter is a lower hanging fruit that would > beneficial to > > solve for probably a lot less effort.) As you say about the prior > > bullet, violating "do no harm" you are right and I would > not recommend > > throwing out good zones with the bad. > > > I'm not sure whether the first or third option is the lower > hanging fruit. > I'd need to get an assessment from ARIN staff on that. > Perhaps Richard is watching the list and will ask staff based > on this message and post something to the list (Richard?). > Otherwise, I'm sure it will be part of the discussion in > Orlando, and, staff will follow up on it. > (actually, I'm CCing richardj on this to call it to his attention. > > >>> I think this proposal ought to be targeted at something, > it makes a > > ... > >> OK... On that we can agree to disagree. I think both are > worthwhile > >> goals, and, I think both can be accomplished. In general, > I expect > >> the need > > > > ... > > > > I don't think that we will wind up disagreeing. (That's so not > > "consensus." ;)) I mention these goals for consideration, > but if the > > membership decides it's not important to pick one, both, or others, > > then I will consider this a learning experience. As in - trying to > > adjust the detail with which we document policies. > > > OK... Well, if it's important to pick, I pick both. If it's > not important to pick, then, it doesn't matter. :-) Others, > I'd need to know what they were to evaluate. > > > Owen > From Ed.Lewis at neustar.biz Thu Mar 24 10:34:38 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 24 Mar 2005 10:34:38 -0500 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations In-Reply-To: <20050321195540.DC32A1FED1@mercury.arin.net> References: <20050321195540.DC32A1FED1@mercury.arin.net> Message-ID: Richard, In case this is otherwise missed, I had a few other requests buried in my messages. If there are slides given during a discussion on this in Orlando, could URLs be shown for lame delegation policies at the other RIRs? (Assuming there is something available.) I know that lame delegation work is on-going in places, I'm curious whether there is policy work or results for comparison. I'd also like to know if the 90 day requirement is something the staff can reasonably commit to, given that testing should consider: 1) repeatedly trying "downed" servers to avoid network disruptions 2) allowing time for an allocation of space to "hit the street" (Clarifying #2 - when a request for space is made, name servers are added. As soon as the request is allocated, the delegations appear in the DNS. There is a time lag then until the requester is notified and the engineering cycle can add the zones to a server. Unlike "forward" situations, the requester can't really anticipate the zone name until the space is allocated.) My other requests mirror those by Owen - basically other work estimates. At 14:55 -0500 3/21/05, Richard Jimmerson wrote: >Owen, > >Message received. > >We can consider these options in the staff impact analysis that is conducted >for each new policy proposal. > >I'll contact you off list for clarification about which options you are >asking be considered. > >Richard Jimmerson >Director of External Relations >American Registry for Internet Numbers (ARIN) > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Monday, March 21, 2005 1:57 AM >> To: Edward Lewis >> Cc: ppml at arin.net; richardj at arin.net >> Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations >> Importance: High >> >> >> [Attn: Richard Jimmerson >> About the middle of this message there is a question where >> I think we >> need some feedback from ARIN staff about what is/isn't >> possible and what >> is easiest. We've got a few different tradeoffs to >> consider, and, we'd >> like staff feedback on the implementation of each. >> >> Thanks, >> >> Owen] >> >> >> --On Sunday, March 20, 2005 21:27 -0500 Edward Lewis >> >> wrote: >> >> > At 12:12 -0800 3/20/05, Owen DeLong wrote: >> > >> >> Got it. In this case, I think that ARIN contacting the ISP and >> >> educating them will work 99+% of the time. In that 1% >> case, I think >> >> there are a few options, and, frankly, I'm not sure which is best: >> > >> > I've been assuming (assuming!) that the percentages would >> be reversed, >> > but you could be right. Not arguing, just pointing out where I had >> > been coming from. >> > >> Well... Not sure. For legacy delegations, you're probably >> right, contact will probably be a challenge. However, for >> these, the likelihood of your issue for partial lameness is >> also smaller. For more recent delegations, the contact data >> is more likely to be correct and workable, so, the likelihood >> that the ORG receiving the delegation will correct the server >> upon notification and training (it's not really hard, >> afterall), is, IMHO, relatively high. >> >> >> + ARIN record boundaries are somewhat independent of >> >> actual allocation size. For example, I have a /23 >> >> which, due to historical reasons, is recorded in >> >> ARIN databases as two /24s. As a result, ARIN could >> >> split the allocation into: >> >> >> >> 365.29.0.0-365.29.9.255 and 365.29.10.0-365.29.31.255 >> > >> > This is a step in the right direction. >> > >> > There's a tangential issue on the horizon though that might >> feed into >> > this. The tangential issue is DNSSEC - and I don't mean to start a >> > discussion on that here, this is a future topic. The >> reason I mention >> > it is that for DNSSEC, *if* it becomes a reality, there is >> a need to >> > store data per DNS zone, something ARIN does not do up to now. >> > >> Well, since ARIN doesn't really have any convenient way to >> determine what the boundaries of a DNS Zone are, that's going >> to be pretty hard for ARIN to do. >> >> > To cut to the chase, splitting the allocation's zones into lame and >> > not lame might be a "degenerate case" of having to store >> unique data >> > (public keys for DNSSEC) per zone within an allocation. >> > >> So it is expected that ARIN will store the public keys for >> zones not delegated by ARIN? That seems like a flaw in the >> DNSSEC design if it is the case. I don't see any reason ARIN >> would want to get involved in that. >> >> >> This would allow my originally proposed solution to >> >> work just fine. Of course, then the ISP has to correct >> >> things prior to being able to make in-addrs work for >> >> any new assignments they issue from the block. This >> >> is not necessarily a bad thing in my opinion. >> >> >> >> (And yes, the ARIN database is capable of >> non-bit-aligned >> >> allocations, several such blocks exist already) >> > >> > Yes, the database demonstrates the capability of handling arbitrary >> > ranges of addresses, CIDR is not a prerequisite. The >> capability that >> > is needed for lame delegation and potentially DNSSEC is the >> ability to >> > store per zone. >> > >> Well, a "Zone" is an arbitrarily bounded range of addresses >> when talking about reverse, so, that's possible, but, I'm >> still not sure how ARIN gets involved in determining "Zones" >> where ARIN doesn't delegate the zone. >> >> > What I'm saying is that we should seek an engineering >> opinion on what >> > you are suggesting, with some assessment of what *would be* >> needed for >> > DNSSEC and future trends in DNS. >> > >> I think I understand where you're coming from, but, I remain >> unconvinced that ARIN should base policy on an assumption >> that a working group will heap a responsibility on ARIN that >> it has not yet had any discussion about accepting. If this >> policy needs modification to accommodate DNSSEC public key >> storage by ARIN, then, that modification should be part of >> the policy proposal that implements ARIN doing public key >> storage for DNSSEC. Until then, policy should be based on >> what we know and not what we think might happen in an IETF >> working group. >> >> >> + ARIN could mark the whole record lame, and remove the >> >> delegations from DNS, but, I think that would violate >> >> the "First, do no harm." principle. >> >> >> >> + ARIN could flag the whois record as partially lame. The >> >> lame portions could be removed from DNS. >> Again, this has >> >> the same tradeoff listed in the first option. >> > >> > What membership should consider is an estimate of the >> engineering to >> > achieve the latter, or just treating allocations that are >> completely >> > lame. (The latter is a lower hanging fruit that would >> beneficial to >> > solve for probably a lot less effort.) As you say about the prior >> > bullet, violating "do no harm" you are right and I would >> not recommend >> > throwing out good zones with the bad. >> > >> I'm not sure whether the first or third option is the lower >> hanging fruit. >> I'd need to get an assessment from ARIN staff on that. >> Perhaps Richard is watching the list and will ask staff based >> on this message and post something to the list (Richard?). >> Otherwise, I'm sure it will be part of the discussion in >> Orlando, and, staff will follow up on it. >> (actually, I'm CCing richardj on this to call it to his attention. >> >> >>> I think this proposal ought to be targeted at something, >> it makes a >> > ... >> >> OK... On that we can agree to disagree. I think both are >> worthwhile >> >> goals, and, I think both can be accomplished. In general, >> I expect >> >> the need >> > >> > ... >> > >> > I don't think that we will wind up disagreeing. (That's so not >> > "consensus." ;)) I mention these goals for consideration, >> but if the >> > membership decides it's not important to pick one, both, or others, >> > then I will consider this a learning experience. As in - trying to >> > adjust the detail with which we document policies. >> > >> OK... Well, if it's important to pick, I pick both. If it's >> not important to pick, then, it doesn't matter. :-) Others, >> I'd need to know what they were to evaluate. >> >> >> Owen >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. From andrew.dul at quark.net Tue Mar 29 10:48:18 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 29 Mar 2005 15:48:18 +0000 Subject: [ppml] The U.N. thinks about tomorrow's cyberspace Message-ID: <20050329154818.17758.qmail@hoster908.com> The following articles & linked reports should be of interest to the ARIN community. :) http://news.com.com/The+U.N.+thinks+about+tomorrows+cyberspace/2008-1028_3-5643972.html?tag=nefd.lede